HAProxy

HAProxy to popularne oprogramowanie do równoważenia obciążenia i proxy, wykorzystywane m.in. w infrastrukturze pocztowej.

HAProxy jako warstwa pośrednicząca w ruchu sieciowym

HAProxy jest oprogramowaniem pełniącym funkcję serwera proxy oraz modułu równoważenia obciążenia. Pośredniczy między klientem a jednym lub większą liczbą serwerów zaplecza, przejmując połączenia przychodzące i przekazując je dalej zgodnie z regułami zapisanymi w konfiguracji. Może pracować w trybie HTTP, w którym rozpoznaje elementy protokołu aplikacyjnego, albo w trybie TCP, gdzie przekazuje strumień danych bez interpretowania jego zawartości na poziomie aplikacji.

W typowym układzie klient łączy się z adresem obsługiwanym przez HAProxy, a proxy wybiera serwer backendowy z zdefiniowanej puli. Dzięki temu adres publiczny, port nasłuchu i część odpowiedzialności za obsługę połączeń mogą zostać oddzielone od fizycznego lub wirtualnego serwera aplikacyjnego. HAProxy nie jest samodzielną aplikacją pocztową, bazą danych ani serwerem treści. W infrastrukturze pocztowej może jednak przekazywać połączenia do właściwych usług, na przykład wtedy, gdy kilka instancji danego komponentu ma przyjmować ruch przez wspólny punkt wejścia.

Algorytmy wyboru backendu i kontrola dostępności

Jedną z podstawowych funkcji HAProxy jest wybór serwera, do którego zostanie skierowane nowe połączenie lub żądanie. Konfiguracja może wykorzystywać między innymi rozdzielanie ruchu metodą round robin, wybór serwera według jego wagi albo kierowanie kolejnych połączeń do najmniej obciążonego zaplecza. Wybór odpowiedniej metody zależy od charakterystyki aplikacji, czasu obsługi żądań oraz tego, czy połączenia zachowują stan po stronie konkretnego serwera.

HAProxy może wykonywać aktywne testy zdrowia backendów. Test polega na okresowym nawiązaniu połączenia lub wysłaniu określonego żądania i sprawdzeniu odpowiedzi zgodnie z ustawionymi warunkami. Jeżeli serwer przestaje odpowiadać albo zwraca wynik uznany za nieprawidłowy, może zostać tymczasowo wyłączony z puli. Po pomyślnych testach może zostać do niej ponownie włączony. Takie mechanizmy ograniczają kierowanie nowych połączeń do niedostępnej instancji, ale nie naprawiają samej aplikacji ani nie gwarantują poprawności danych przetwarzanych przez backend.

Ważnym zagadnieniem jest stan sesji. Jeżeli aplikacja przechowuje informacje wyłącznie lokalnie na jednym serwerze, kolejne żądania tego samego klienta mogą wymagać trafienia do tej samej instancji. HAProxy może w takich przypadkach stosować tak zwane sesje lepkie, oparte na wybranym identyfikatorze, adresie lub mechanizmie ciasteczka. Nie zastępuje to jednak poprawnego projektowania aplikacji rozproszonej, ponieważ awaria przypisanego backendu nadal może przerwać sesję.

Reguły ACL, TLS i przekazywanie informacji o kliencie

Konfiguracja HAProxy może podejmować decyzje na podstawie tak zwanych ACL, czyli warunków dostępu i dopasowania. Warunki mogą dotyczyć między innymi metody HTTP, ścieżki żądania, nagłówka, portu, adresu źródłowego, stanu połączenia albo wyniku wcześniejszego testu. Na tej podstawie można kierować różne ścieżki do odmiennych backendów, odrzucać niepasujące żądania, wymuszać przekierowanie lub wybierać odrębne zasady obsługi dla ruchu szyfrowanego i nieszyfrowanego.

HAProxy może uczestniczyć w obsłudze TLS. W zależności od konfiguracji przyjmuje szyfrowane połączenie i kończy szyfrowanie na warstwie proxy, a następnie przekazuje ruch do backendu po zwykłym HTTP albo ponownie szyfruje połączenie do serwera zaplecza. Możliwe jest także przekazywanie połączenia w trybie TCP bez kończenia TLS na HAProxy. Wybór wariantu wpływa na miejsce weryfikacji certyfikatu, widoczność danych aplikacyjnych dla reguł oraz sposób ochrony odcinka między proxy a backendem.

Pośrednik musi również właściwie przekazywać informacje o pierwotnym kliencie. Przy terminacji HTTP stosuje się zwykle odpowiednie nagłówki, takie jak X-Forwarded-For, o ile aplikacja i cała ścieżka sieciowa są skonfigurowane tak, aby ufać tym nagłówkom wyłącznie od znanych proxy. W połączeniach TCP może być używany protokół PROXY, który przenosi metadane dotyczące adresu źródłowego i docelowego przed właściwym strumieniem aplikacyjnym. Backend musi obsługiwać wybrany mechanizm; samo włączenie go w HAProxy bez zgodności po stronie odbiorcy może powodować błędy protokołu.

Diagnostyka konfiguracji, logów i opóźnień

Problemy z HAProxy mogą wynikać zarówno z niedostępności backendu, jak i z błędów w regułach routingu, limitach czasu, certyfikatach lub zgodności protokołu. Podczas analizy należy rozdzielić co najmniej kilka etapów: przyjęcie połączenia przez proxy, wybór backendu, nawiązanie połączenia z serwerem zaplecza, oczekiwanie na odpowiedź oraz przesłanie odpowiedzi do klienta. Długi czas na jednym z tych etapów wskazuje inną klasę problemu niż natychmiastowe odrzucenie połączenia.

Logi HAProxy mogą zawierać informacje o wybranym frontendzie i backendzie, kodzie odpowiedzi HTTP, czasie trwania poszczególnych faz oraz statusie serwera. Interpretacja tych danych wymaga znajomości użytego formatu logowania, ponieważ znaczenie pól zależy od konfiguracji i trybu pracy. Błąd połączenia do backendu nie musi oznaczać awarii samego HAProxy; może wskazywać na zamknięty port, odrzucenie przez zaporę sieciową, niezgodność TLS, przekroczenie limitu czasu lub błędny adres serwera.

Przed wdrożeniem zmian warto sprawdzić składnię konfiguracji poleceniem haproxy -c -f /ścieżka/do/konfiguracji.cfg. Opcja -c uruchamia kontrolę konfiguracji bez startu właściwego procesu, a -f wskazuje plik wejściowy. Sama poprawna składnia nie potwierdza jeszcze poprawności przepływu danych. Konieczne jest także sprawdzenie zgodności portów, adresów, certyfikatów, reguł ACL, testów zdrowia, limitów czasu i obsługi nagłówków lub protokołu PROXY po stronie backendów.