Jak zmienić HAProxy na inny back-end, gdy brakuje pierwszego pliku? Potrzebuję errorloctylko przepisania zamiast przekierowania, więc klient nie jest świadomy przekierowania.
Opracowaliśmy aplikację z myślą o NginX, która była zarówno równoważącym obciążenie zwrotnym serwerem proxy, jak i serwerem WWW dla plików statycznych. Aplikacja oparta jest na frameworku Opa , który wymaga lepkich sesji opartych na plikach cookie - obsługiwanych zarówno przez NginX, jak i HAproxy. Problemem z aplikacją jest dynamiczne generowanie treści. Generuje obrazy na żądanie, ale po wygenerowaniu są zapisywane na dysku i można uzyskać do nich dostęp statyczny za pomocą deterministycznej ścieżki.
Problem można łatwo rozwiązać za pomocą NginX - próbuje odczytać plik lokalny i użyć back-endu z równoważeniem obciążenia tylko wtedy, gdy brakuje pliku (jeszcze nie został wygenerowany):
server {
server_name wkaliszu.pl;
location /thumb {
root /path_on_disk/to_cached_content;
expires 7d;
# try to access already generated content
try_files $uri @wkaliszu;
}
location / {
# reverse proxy to the application
[...]
}
location @wkaliszu {
# reverse proxy to the application
[...]
}
}
Serwer został zmigrowany i teraz używa HAPproxy do równoważenia obciążenia, który nie jest serwerem WWW i nie obsługuje tej funkcji. Teraz dynamiczne generowanie oprogramowania jest wykonywane za każdym razem, gdy klient próbuje uzyskać dostęp do zasobu, co jest znacznie wolniejsze i marnuje zasoby. Byłoby dobrze, gdyby mógł użyć następnego zaplecza, gdyby pierwszy (prosty buforujący serwer WWW dla plików statycznych) zawiódł z błędem 404, ale nie mogę znaleźć sposobu, aby to zrobić w prosty sposób. Przekierowanie /thumbdo NginX, które próbuje odczytać plik statyczny i ponownie przepisuje do HAproxy z nowym nagłówkiem HTTP, przychodzi mi na myśl, ale chciałbym znaleźć coś lepszego.
Odpowiedzi:
Backendy HAProxy są albo w górę, albo w dół (lub w drodze do bycia w górę / w dół).
Istnieją różne sposoby sprawdzania kondycji backendu, ale nie znam żadnych, które zapewniają śledzenie na podstawie żądania. Gdy żądanie nie powiedzie się, ten backend zostanie oznaczony jako wyłączony lub zawiedzie (w drodze do uznania go za wyłączony).
Jest to zupełnie inna logika niż konfiguracja Nginx, która kierowała żądania na zasadzie na żądanie.
Widzę tutaj kilka opcji:
Buforowanie proxy
W HAProxy używasz list ACL do kierowania żądań zawartości statycznej do określonego zaplecza. Te węzły zaplecza uruchomiłyby nginx z buforującym proxy. Gdyby nginx miał plik w pamięci podręcznej, po prostu go podałby. Jeśli nie, wywołałoby to backend.
Użyj serwerów aplikacji dla treści statycznych
Jeśli Twoje serwery aplikacji są wydajne w dostarczaniu treści statycznych, może nie być konieczne podzielenie żądania na haproxy. Wystarczy wysłać wszystkie żądania do backendów aplikacji. Zbuduj w nich logikę, aby wyświetlać zawartość statyczną, jeśli jest dostępna, a jeśli nie, wyślij żądanie do zaplecza.
Opcja CDN
Jeśli możesz użyć dedykowanej domeny dla zawartości statycznej, możesz być w stanie użyć CDN. W sieci CDN wystarczy wskazać źródłowy adres URL do węzłów aplikacji. Następnie możesz kontrolować buforowanie na poziomie CDN. Jest to podobne do powyższego buforowania Nginx, z wyjątkiem tego, że dostawca CDN obsługuje go za Ciebie.
źródło