Plik konfiguracji HAProxy jest krótki w porównaniu z większością oprogramowania serwerowego, a mimo to decyduje o tym, jak każde żądanie trafia do aplikacji. Jeśli zamierzasz postawić load balancer przed stroną lub API jako krok w stronę konfiguracji serwera wysokiej dostępności albo masz w spadku taki, którego nikt do końca nie rozumie, warto przeczytać plik sekcja po sekcji. Ten przewodnik omawia typową konfigurację HAProxy dla aplikacji WWW w obecnych wydaniach 3.x: co robi każda część, które opcje mają największe znaczenie i jakie błędy powodują awarie.

Cztery sekcje konfiguracji HAProxy

  • global ustawia opcje całego procesu: logowanie, użytkownika, z którego uprawnieniami działa HAProxy, domyślne ustawienia TLS i gniazdo administracyjne używane przez Runtime API.
  • defaults zawiera ustawienia dziedziczone przez wszystko poniżej, przede wszystkim tryb, http lub tcp, oraz limity czasu. Brak limitów czasu to klasyczna przyczyna nawarstwiania się połączeń, a HAProxy ostrzega o tym przy starcie.
  • frontend opisuje, na czym nasłuchuje HAProxy: adresy, porty, certyfikaty i reguły decydujące, który backend dostaje dane żądanie.
  • backend wymienia serwery za balanserem, sposób rozdzielania ruchu między nie i sposób sprawdzania ich stanu.

Po każdej edycji polecenie haproxy -c -f /etc/haproxy/haproxy.cfg sprawdza plik przed przeładowaniem. Przeładowanie przez systemd uruchamia nowe procesy z nową konfiguracją, a istniejące połączenia kończą się na starych.

Przykład konfiguracji HAProxy, opisany słowami

Typowy układ dla firmowej strony z dwoma serwerami aplikacji wygląda tak:

  • Frontend nasłuchuje na porcie 80 i przekierowuje każde żądanie na HTTPS, a na porcie 443 działa z ssl i katalogiem crt z certyfikatami.
  • Reguły we frontendzie kierują żądania, których ścieżka zaczyna się od /api, do backendu API, a całą resztę do backendu WWW.
  • Każdy backend ma linię balance, health check HTTP i dwie linie server, każdą ze słowem kluczowym check.
  • Frontend dodaje nagłówek X-Forwarded-For przez option forwardfor i ustawia X-Forwarded-Proto, dzięki czemu aplikacja zapisuje w logach prawdziwe adresy odwiedzających i wie, że oryginalne żądanie szło przez HTTPS.

Ten ostatni punkt łatwo przeoczyć. Bez tych nagłówków aplikacje za balanserem widzą każdego odwiedzającego jako pochodzącego z adresu samego HAProxy, a niektóre tworzą pętle przekierowań, bo sądzą, że żądanie przyszło zwykłym HTTP.

Wybór algorytmu równoważenia obciążenia

  • roundrobin, domyślny, działa na zasadzie kolejki i uwzględnia wagi serwerów. Dobry do krótkich, podobnych żądań.
  • leastconn kieruje nowe połączenia do serwera z najmniejszą liczbą aktywnych. Lepszy, gdy żądania bardzo różnią się czasem trwania, na przykład raporty, wysyłanie plików lub długotrwałe połączenia.
  • source, albo skrót nagłówka lub adresu URL, utrzymuje tego samego klienta lub zasób na tym samym serwerze. Przydatny dla pamięci podręcznych, mniej do równomiernego rozkładania obciążenia.

Wagi pozwalają większemu serwerowi przejąć większy udział, a waga zero zostawia serwer w konfiguracji, nie wysyłając do niego nowych żądań.

Ustawienia health checku HAProxy, które odzwierciedlają rzeczywistość

Samo słowo kluczowe check sprawdza tylko, czy port TCP odpowiada, a odpowiada też wtedy, gdy aplikacja za działającym serwerem WWW padła. Health check HAProxy po HTTP prosi o prawdziwą stronę: option httpchk razem z http-check send i http-check expect pozwala zażądać ścieżki takiej jak /health i wymagać statusu 200. Dobry endpoint zdrowia dotyka zależności, które mają znaczenie, na przykład bazy danych, a nie jest kosztowny w wykonaniu.

Czas ustawia się dla każdego serwera: inter to odstęp, fall to liczba nieudanych sprawdzeń uznających serwer za niedziałający, a rise to liczba udanych, które go przywracają. Zbyt agresywne sprawdzanie wyłącza zdrowe serwery podczas krótkiego spowolnienia, zbyt powolne wysyła odwiedzających do martwego serwera. Health checki to jedna z pierwszych rzeczy, które przeglądamy w istniejącej konfiguracji load balancera HAProxy.

Sticky sessions HAProxy i terminacja SSL w HAProxy

Jeśli aplikacja trzyma loginy lub koszyki w lokalnych plikach albo w pamięci, odwiedzający, który trafi na inny serwer, traci sesję. Najlepsze rozwiązanie leży po stronie aplikacji: przechowywanie sesji we wspólnym miejscu, na przykład w Redisie lub bazie danych. Tam, gdzie to niemożliwe, sticky sessions HAProxy używają dyrektywy cookie w backendzie, na przykład cookie SERVERID insert indirect nocache, oraz wartości ciasteczka w każdej linii server. HAProxy przypina wtedy każdego odwiedzającego do jednego serwera i przenosi go dopiero, gdy ten serwer padnie.

Terminacja SSL w HAProxy oznacza, że HAProxy obsługuje TLS i przekazuje zwykły HTTP do serwerów przez sieć prywatną. Dzięki temu certyfikaty są w jednym miejscu, a HAProxy może czytać żądania na potrzeby routingu. Jeśli droga między HAProxy a backendami prowadzi przez sieci, których nie kontrolujesz, zaszyfruj również ten odcinek, dodając ssl i weryfikację certyfikatu do linii server.

Drenowanie serwera przez HAProxy Runtime API

Przy wdrożeniu bez przestoju wyłącz jeden serwer z rotacji, zaktualizuj go, sprawdź i włącz z powrotem. HAProxy Runtime API robi to bez edycji pliku. Przez gniazdo administracyjne zdefiniowane w sekcji global polecenie takie jak set server web/app1 state drain powstrzymuje nowych odwiedzających przed trafianiem na app1, podczas gdy istniejące sesje się kończą, a state ready przywraca serwer do pracy. Skrypty wdrożeniowe mogą w ten sposób drenować serwer, poczekać, aż liczba jego połączeń spadnie do zera, i dopiero wtedy kontynuować. Zmiany wprowadzone przez gniazdo nie są zapisywane do pliku konfiguracji, więc zmiany trwałe nadal należą do niego.

To samo gniazdo oraz wbudowana strona statystyk pokazują stan każdego serwera i wyniki health checków; ogranicz dostęp do obu do administratorów. Każda dyrektywa i polecenie są opisane w oficjalnej dokumentacji HAProxy, uporządkowanej według wersji.

Najczęściej zadawane pytania: konfiguracja HAProxy

Czy jeden HAProxy może obsługiwać strony i inne usługi?

Tak. Jedna konfiguracja może równoważyć strony w trybie http oraz usługi takie jak bazy danych czy poczta w HAProxy w trybie TCP, każdą z własnym frontendem i backendem. W trybie TCP HAProxy przepuszcza połączenia, nie czytając ich.

Jakiej wersji HAProxy używać?

Gałęzi z długoterminowym wsparciem, na przykład 3.2, w produkcji. Pakiety dystrybucji często pozostają w tyle za bieżącymi gałęziami, więc sprawdź, jaką wersję faktycznie instaluje Twój serwer; projekt HAProxy podaje listę utrzymywanych gałęzi i wskazuje nowsze pakiety dla Debiana i Ubuntu.

Ile serwerów potrzeba za HAProxy?

Co najmniej dwa dla redundancji, każdy w stanie udźwignąć szczytowy ruch samodzielnie. W przeciwnym razie drenowanie jednego na czas wdrożenia albo utrata jednego w awarii przeciąży drugi w najgorszym możliwym momencie.

Planujesz load balancer albo chcesz, by ktoś drugi spojrzał na istniejącą konfigurację? Nasza usługa instalacji i konfiguracji load balancera HAProxy obejmuje health checki, terminację TLS i failover zaplanowane pod Twoją aplikację, dla firm w Los Angeles i poza nim. Backendy zwykle też wymagają uwagi; zobacz naszą usługę optymalizacji serwera WWW Apache. Skontaktuj się z nami, opisując krótko swoje serwery i ruch.