Wprowadzenie
High Availability Proxy (HAProxy), to popularne, otwartoźródłowe rozwiązanie pośredniczące (proxy) oraz TCP/HTTP load balancer, które można uruchomić na systemach Solaris, FreeBSD, oraz Linux. Jest najczęściej używane do zwiększania niezawodności i wydajności środowiska serwerowego poprzez zapewnienie zrównoważonego rozkładu obciążenia pracy na wiele serwerów. Tego typu narzędzie jest używane w wielu znanych środowiskach, takich jak Instagram, GitHub, Twitter i Imgur.
Ten przewodnik wprowadzi Cię w HAProxy, zapozna z terminologią związaną z równoważeniem obciążenia oraz przedstawi przykłady, jak można je wykorzystać do zwiększenia zarówno wydajności, jak i niezawodności środowisk serwerowych.
Kluczowe pojęcia HAProxy
Przed przejściem do szczegółów dotyczących równoważenia obciążenia i pośredniczenia (proxyingu), warto zapoznać się z kilkoma ważnymi pojęciami i koncepcjami. Zaczniemy od ich omówienia w poniższych sekcjach.
ACL (Access Control List)
W kontekście równoważenia obciążenia, listy ACL są wykorzystywane do testowania określonego warunku i podejmowania działań na podstawie wyniku. Daje to możliwość optymalnego przekierowywania ruchu w oparciu o czynniki takie jak połączenia z backendem, dopasowywanie wzorców i wiele innych. Oto przykład użycia ACL:
|
1 |
acl url_blog path_beg /blog |
W tym przypadku reguła ACL jest dopasowana, jeśli ścieżka żądana przez użytkownika zaczyna się od /blog. Na przykład to dopasowane żądanie wskazywałoby na http://yourdomain.com/blog/blog-entry-1. Podręcznik konfiguracji HAProxy zawiera szczegółowy przewodnik po korzystaniu z ACL.
Backend
Przekazywane żądania są odbierane przez zestaw serwerów określany jako backend. Żądania te są definiowane w sekcji backend konfiguracji HAProxy. W najprostszych słowach, backend można zdefiniować poprzez określenie algorytmów równoważenia obciążenia, które mają być użyte, oraz listy portów i serwerów. Backend może składać się z jednego lub wielu serwerów. W miarę dodawania kolejnych serwerów do backendu, potencjalna wydajność wzrasta, a przetwarzanie jest rozdzielane na wiele serwerów. Jeśli niektóre serwery backendu ulegną awarii, pozostałe będą służyć jako zapasowe do przetwarzania żądań.
Przyjrzyjmy się przykładowi konfiguracji dwóch backendów. W tym przypadku są to blog-backend i web-backend. Każdy z nich ma dwa serwery WWW, nasłuchujące na porcie 80:
|
1 2 3 4 5 6 7 8 9 10 |
backend web-backend balance roundrobin server web1 web1.yourdomain.com:80 check server web2 web2.yourdomain.com:80 check backend blog-backend balance roundrobin node http server blog1 blog1.yourdomain.com:80 check server blog2 blog2.yourdomain.com:80 check |
Linia balance roundrobin służy do określenia algorytmu równoważenia obciążenia. Szczegóły można znaleźć w nadchodzącej sekcji Algorytmy równoważenia obciążenia, podczas gdy mode http konfiguruje użycie proxy w warstwie 7. Wyjaśnimy to w sekcji Typy równoważenia obciążenia. Ponadto opcja check po dyrektywie serwerów wskazuje, że na tych konkretnych serwerach backendu będą uruchamiane testy sprawności (health checks).
Frontend
Definicja sposobu przekazywania żądań do backendu jest określana jako frontend. Żądania te są definiowane w sekcji frontend konfiguracji HAProxy. Składają się one z reguł ACL, portu, zestawu adresów IP oraz reguły określającej, których backendów użyć w zależności od spełnionych warunków ACL, zwanej regułą use_backend. Dodatkowo istnieje również reguła default_backend, która obsługuje wszelkie inne przypadki. W następnej sekcji wyjaśnimy, jak można skonfigurować frontend dla różnych typów ruchu sieciowego.
Typy równoważenia obciążenia
Po ustaleniu podstawowych komponentów używanych do równoważenia obciążenia, możemy teraz przejść do podstawowych typów równoważenia obciążenia.
Brak równoważenia obciążenia
W swojej najbardziej podstawowej formie brak równoważenia obciążenia można zilustrować w następujący sposób:
W tym scenariuszu użytkownik łączy się bezpośrednio z serwerem WWW pod adresem yourdomain.com. Nie ma tu żadnego równoważenia obciążenia. Ponieważ istnieje tylko jeden serwer bazy danych, jeśli ulegnie on awarii, dostęp do znajdujących się na nim informacji zostanie całkowicie odcięty. Jeśli wielu użytkowników próbuje połączyć się z jednym serwerem WWW jednocześnie, a ten nie jest w stanie obsłużyć generowanego obciążenia, wszystkie połączenia spowolnią lub w ogóle nie zostaną nawiązane.
Równoważenie obciążenia (warstwa 4)
Jednym z najprostszych i najbardziej pragmatycznych sposobów równoważenia ruchu sieciowego do wielu serwerów jest stosowanie metod równoważenia w warstwie transportowej lub warstwie 4. Ten sposób równoważenia obciążenia kieruje każdego łączącego się użytkownika na podstawie zakresu IP, w którym mieści się jego adres IP, oraz portu. Innymi słowy, jeśli http://yourdomain.com/anything jest miejscem, z którego pochodzi żądanie, backend zdefiniowany do obsługi tych żądań będzie tym, który ostatecznie je obsłuży. Przekaże on te żądania dla yourdomain.com na porcie 80.
Podstawowa struktura równoważenia obciążenia w warstwie 4 wygląda następująco:
Gdy użytkownik uzyskuje dostęp do modułu równoważenia obciążenia, jego żądania są przekazywane do grupy serwerów web-backend. Skonfigurowany serwer backendowy bezpośrednio odpowie na żądanie użytkownika. Aby uniknąć sytuacji, w której użytkownik napotyka niespójne dane, wszystkie serwery web-backend powinny serwować identyczną zawartość. Zgodnie z powyższym schematem, oba serwery WWW ostatecznie łączą się z tą samą bazą danych.
Równoważenie obciążenia (warstwa 7)
Istnieje inna, bardziej złożona metoda równoważenia ruchu sieciowego. Jest nią równoważenie obciążenia w warstwie 7, czyli warstwie aplikacji. Podejście to umożliwia przekazywanie żądań użytkowników do różnych serwerów backendowych w zależności od zawartości tych żądań. Metoda ta pozwala na równoważenie obciążenia na wielu serwerach aplikacji internetowych za pośrednictwem tego samego portu i domeny. Więcej szczegółów na temat tej warstwy można znaleźć w sekcji dotyczącej HTTP w naszym The Nitty Gritty of Networking: Learn about Terminology, Interfaces, and Protocols poradniku.
Poniższy schemat ilustruje równoważenie obciążenia w warstwie 7:
W tym przypadku użytkownik wysyła żądanie do yourdomain.com/blog, a jego żądanie jest przekazywane do backendu bloga. Jest to zestaw serwerów backendowych przeznaczonych specjalnie do uruchamiania aplikacji blogowej. W międzyczasie inne żądania będą przekazywane do backendu WWW (web-backend). Jednak oba backendy ostatecznie korzystają z tego samego serwera bazy danych.
Przykład małego fragmentu konfiguracji frontendowej dla równoważenia obciążenia w warstwie 7 wyglądałby jak poniższe polecenia. Konfigurują one frontend http do obsługi ruchu przychodzącego przez port 80:
|
1 2 3 4 5 6 7 8 |
frontend http bind *:80 node http acl url_blog path_beg /blog use_backend blog.backend if url_blog default_backend web.backend |
Jeśli ścieżka żądania użytkownika zaczyna się od /blog, reguła acl url_blog path_beg /blog dopasuje żądanie.
use_backend blog backend if url_blog przekazuje ruch do blog-backend przy użyciu ACL.
defaut_backen web_backend kieruje cały pozostały ruch do web-backend.
Algorytmy równoważenia obciążenia
Podczas równoważenia obciążenia to algorytm równoważenia obciążenia określa, który serwer backendowy zostanie wybrany do tego celu. HAProxy oferuje kilka opcji algorytmów. Dodatkowo możliwe jest przypisanie parametru wagi do serwerów w celu manipulowania tym, jak często dany serwer jest wybierany w porównaniu do innych. Dostępnych algorytmów jest po prostu zbyt wiele, aby opisać je wszystkie. Dlatego ten przewodnik skupi się tylko na tych najpopularniejszych. Możesz zapoznać się z HAProxy Documentation Converter , aby zobaczyć pełną listę. Do najczęściej używanych należą:
- roundrobin: domyślny algorytm, który wybiera serwery po kolei.
- leastconn: automatycznie wybierany jest serwer z najmniejszą liczbą połączeń. Jednak serwery w ramach tego samego backendu powinny być rotowane metodą round-robin.
- source: algorytm wybiera serwery na podstawie adresu IP, z którego pochodzi żądanie użytkownika. Jest to metoda zapewniająca, że użytkownik zawsze połączy się z tym samym serwerem.
Sticky Sessions
W przypadku niektórych aplikacji wymagane jest, aby łączący się użytkownicy zawsze trafiali na ten sam serwer. Poprzez „lepkie sesje” i użycie parametru appsession w wymagającym tego backendzie można osiągnąć taką trwałość.
Processing Health Checks
HAProxy potrzebuje metody, za pomocą której może określić zdolność serwera backendowego do przetwarzania żądań. Służy to do usuwania serwera z backendu, jeśli przejdzie on w tryb offline. Istnieje domyślna kontrola stanu („health check”), która próbuje nawiązać połączenie TCP. Robi to, nasłuchując na skonfigurowanym adresie IP i porcie.
Jeśli kontrola stanu serwera nie powiedzie się, serwer nie jest w stanie przetwarzać przesyłanych żądań. W tym momencie serwer jest automatycznie wyłączany w backendzie, a ruch nie jest już do niego kierowany, dopóki nie zacznie ponownie działać poprawnie (będzie sprawny). Jednak w niektórych przypadkach określenie stanu serwera za pomocą domyślnej kontroli stanu okazuje się niewystarczające.
Alternate Solutions
HAProxy może okazać się zbyt skomplikowane dla Twoich konkretnych potrzeb. W takim przypadku istnieje kilka dobrych alternatyw, które mogą okazać się bardziej wydajne:
- Nginx: To niezawodny i szybki serwer WWW, który można wykorzystać do równoważenia obciążenia i celów proxy. W rzeczywistości Nginx jest powszechnie używany w tandemie z HAProxy, które wykorzystuje jego możliwości kompresji i buforowania.
- Linux Virtual Servers (LVS): To prosty moduł równoważenia obciążenia warstwy 4, który jest dołączany do wielu systemów Linux.
High Availability
Do tej pory mówiliśmy o równoważeniu obciążenia w warstwie 4 i warstwie 7. W obu przypadkach wykorzystuje się moduł równoważenia obciążenia (load balancer), aby określić, który z wielu serwerów backendowych będzie odpowiedzialny za odpowiedź na żądanie użytkownika. Należy jednak pamiętać o ograniczeniach load balancera. Mianowicie o tym, że stanowi on pojedynczy punkt awarii (single point of failure). Oznacza to, że jeśli ulegnie on awarii lub zostanie przeciążony żądaniami użytkowników, spowoduje to odpowiednio przestój lub opóźnienie w przetwarzaniu żądań. Jednak konfiguracja HA (wysokiej dostępności) przedstawia infrastrukturę pozbawioną jakiegokolwiek pojedynczego punktu awarii. Zapobiega to przestojom spowodowanym awarią serwera poprzez wprowadzenie nadmiarowości (redundancji) na każdym poziomie architektury systemu. Podczas gdy load balancer pomaga ułatwić nadmiarowość backendu, same load balancery również muszą być nadmiarowe.
Poniższy schemat przedstawia podstawową formę konfiguracji wysokiej dostępności:

Ta infrastruktura posiada kilka modułów równoważenia obciążenia (jeden aktywny, pozostałe pasywne) powiązanych ze statycznym adresem IP. Ten adres IP może zostać przypisany do innego serwera, jeśli wymaga tego sytuacja. Żądanie użytkownika przechodzi przez zewnętrzny adres IP do aktualnie aktywnego load balancera. Jeśli load balancer jest w tym czasie offline, mechanizm zabezpieczający wykryje jego stan, przypisując adres IP do serwerów pasywnych.
Conclusion
Podstawowe zrozumienie równoważenia obciążenia i wiedza o niektórych sposobach, w jakie HAProxy może zaspokoić potrzeby Twojego systemu w zakresie równoważenia obciążenia, powinny dać Ci solidne podstawy do rozpoczęcia optymalizacji niezawodności i wydajności Twoich obecnych środowisk serwerowych. Możesz również zapoznać się z naszym samouczkiem Pośredniczenie HTTP, równoważenie obciążenia, buforowanie i pamięć podręczna w Nginx: omówienie , aby dowiedzieć się więcej o właściwościach równoważenia obciążenia Nginx.
Miłego korzystania!



Komentarze
Brak komentarzy. Bądź pierwszy.