Jaki Load Balancer wybrać?

Kiedy Microsoft uruchomił stronę microsoft.com w 1991 roku, mieściła ona się na komputerze developera strony. Z czasem wraz ze wzrostem ruchu została ona przeniesiona na dedykowaną maszynę. Strona się rozrastała i ruch na niej znacząco rósł. Wymieniano więc serwer na szybszy, a kiedy brakowało mocy, dokładano procesorów i RAM-u. Tego typu działanie nazywamy skalowaniem pionowym. Niestety możliwości każdej maszyny się kiedyś kończą i musiano znaleźć lepsze rozwiązanie – dokładano nowe serwery. To rozwiązanie nazywamy skalowaniem poziomym. 

Żeby rozłożyć ruch na wiele serwerów, zastosowano prostą sztuczkę. Zamiast jednego rekordu A w systemie DNS było ich tyle, ile serwerów obsługujących domenę. W ten sposób serwer DNS podaje kolejne adresy IP ze swojego zakresu odwiedzającym stronę. Takie rozwiązanie możemy stosować również dzisiaj i nazywa się to Round-Robin DNS. Obarczone jest ono jednak sporą wadą – jeżeli z jakiegoś powodu (awaria sprzętowa, restart spowodowany aktualizacją) serwer będzie niedostępny, część użytkowników zostanie przekierowana na niedostępny serwer i zobaczy błąd zamiast oczekiwanej treści. Oczywiście możemy chwilowo usunąć IP z zakresu domeny, ale będzie to działać z opóźnieniem do 24h, co najczęściej mija się z celem, ponieważ szybciej naprawimy wadliwy serwer.

Niestety tutaj wady się nie kończą. Ruch jest rozkładany wg zapytań od jednego klienta. Wyobraźmy sobie sytuację, że ten sam klient będzie przeglądał stronę długo i odwiedzał wiele podstron. Będzie on pytał ciągle ten sam serwer. W tym samym czasie inni klienci będą pytać kolejne serwery o pojedynczą stronę. Jeżeli sobie to przemnożymy przez setki osób, zauważymy, że serwer nr 1 będzie bardzo przeciążony, kiedy kolejne będą miały wolne zasoby. Dołożenie kolejnych serwerów nie sprawi, że w sytuacji, gdy poszczególne serwery będą przeciążone inne w tym samym czasie przejmą z nich ruch.  Obecnie do tego dochodzą problemy czasów współczesnych - strony są dynamiczne i obciążają serwer zapytaniami bardziej i nie mniej przewidywalny sposób niż zwykłe pliki statyczne.

Dlaczego powstały Load Balancery

Aby rozwiązać powyższe problemy, stworzono nowy rodzaj oprogramowania, a co za tym idzie i dedykowany sprzęt – Load Balancer. Oczywiście poszczególne produkty różnią się od siebie sposobem działania i wydajnością. Od prostego rozdzielania ruchu wg Round-Robin dysponujemy rozwiązaniami potrafiącymi badać stan serwerów backendowych, aż do tworzenia nowych instancji serwerów aplikacyjnych w przypadku zwiększonego ruchu. 

W obecnych czasach niewiele zostało z myślenia o hostowaniu dużej strony na jednym serwerze. Mimo tego, że obecnie sprzęt potrafi wytrzymać duży ruch, zmieniło się podejście do projektowania całej infrastruktury wymuszone wysoką dostępnością strony, jak i globalizacją (jedna strona na cały świat powinna działać szybko na całym świecie). Rozłożono działanie pojedynczego serwera na poszczególne klocki, które współpracują z sobą w ramach sieci prywatnych. Zamiast strony na jednym serwerze mamy serwery aplikacyjne, serwery bazodanowe, serwery cache i dane składowane są na macierzy zamiast na lokalnych dyskach. Load Balancer nie służy nam już tylko jako dispatcher ruchu z internetu, ale także rozkłada ruch między poszczególnymi serwerami w sieci lokalnej, czyniąc ją mniej podatną na awarie i przeciążenia.

Który lepszy - programowy czy sprzętowy?

Czym zatem powinniśmy się kierować, wybierając Load Balancer dla siebie? Mamy szeroki wybór rozwiązań darmowych (np. HAProxy), ale także rozwiązania sprzętowe znanych firm jak F5 czy Cisco. Z powodu rozwiązań chmurowych, producenci dotychczas kojarzeni ze sprzętem wypuścili także wersje softwarowe. Nawet największa firma, kojarzona z wirtualizacją VMWare, wkroczyła w rynek sieciowy i oferuje wirtualne Load Balancery.

Najważniejsze, o czym należy pamiętać przy wyborze, jest to, że niezależnie od tego, czy rozważamy rozwiązanie programowe, czy sprzętowe to i tak uruchomione jest to na jakimś konkretnych fizycznym sprzęcie i niezawodność zależy w dużej mierze od tego sprzętu. Jeżeli wybierzemy rozwiązanie softwarowe, sami odpowiadamy za dobór sprzętu i jego niezawodność. W przypadku rozwiązań sprzętowych przekazujemy taką odpowiedzialność na producenta. Dodatkowo wsparcie producenta w przypadku sprzętu jest czasami dość istotne, szczególnie w  przypadku rozwiązywania problemów wydajnościowych. Budowanie klastrów sprzętowych także jest o tyle prostsze, że używamy do tego narzędzi producenta.

Oczywiście wybór Load Balancera sprzętowego to nie same zalety. Rozwiązania sprzętowe, co oczywiste, ograniczają nas do tego, co zaproponuje producent. Często cena takiego urządzenia jest nieproporcjonalna do zakupu serwera dedykowanego, podobnego pod względem wydajności. Zazwyczaj możemy rozbudować Load Balancer o dodatkowe moduły, ale kiedy skończy się miejsce na nie, jesteśmy zmuszeni do kupna lepszego modelu. Oczywiście w przypadku własnego sprzętu też dochodzimy do granicy możliwości sprzętu, ale serwer jest dużo bardziej modularny i gdy zdecydujemy się go zastąpić nowym, to starego możemy użyć do innego celu. W przypadku, kiedy chcemy np. zwiększyć prędkość interfacu w rozwiązaniu sprzętowym, może to oznaczać kupno nowego modelu. W przypadku własnego sprzętu po prostu dokupujemy kartę sieciową. 

Jak widać, pod względem sprzętowym nie jest to taki prosty wybór, bo nie ma jednoznacznej przewagi którejś ze stron. A co jeżeli chcemy podejść do tematu od strony możliwości oprogramowania? Tutaj może nas spotkać niespodzianka. Między innymi w przypadku rozwiązań firmy F5. Oferuje ona zarówno rozwiązania sprzętowe, jak i programowe. Oczywiście w przypadku wersji programowej nie możemy zarządzać sprzętem, ale funkcjonalność jest dokładnie taka sama. Drobne różnice są na poziomie licencji. Ograniczenia rozwiązania sprzętowego zazwyczaj wynikają z samej wydajności sprzętu (choć i tutaj często możemy spotkać limity licencyjne), natomiast rozwiązanie programowe (o ile rozwiązanie nie jest darmowe) zawsze jest ograniczone poprzez licencje (na ilość połączeń, na ilość vCPU, RAMu, prędkości interfacu etc. ).

Wybór między sprzętowym a programowym Load Balcerem znika, kiedy wybierzemy rozwiązania chmurowe. Wtedy to albo dostawca chmury oferuje nam sprzętowy Load Balancer, zarządzany przez niego, albo programowy zarządzany przez nas. Działa on wtedy jako instancja jak każda inna usługa w chmurze.

Możliwości Load Balancerów

Przejdźmy zatem z ogółu do szczegółu. Co zatem, poza oczywiście rozłożeniem ruchu, oferuje nam Load Balancer:

1. Jest pierwszym oprogramowaniem/sprzętemz którym połączy się klient i jedynym, który jest widoczny dla niego (zabezpiecza serwery w backendzie)
2. Może (bo nie musi, zależy to od naszej konfiguracji) przejąć na siebie obsługę HTTPS. Certyfikat domeny znajduje się wtedy na Load Balancerze, a nie serwerze aplikacyjnym. Przekazuje wtedy zapytania do serwerów aplikacyjnych po HTTP. Dzięki temu możemy wpiąć IPS skanujący ruch oraz odciążamy serwery webowe.
3. Może monitorować serwery w backendzie przez stworzony check. Pozwala to na bieżąco wyłączać z ruchu serwery niedostępne
4. Zapewnia łatwy maintenance serwerów poprzez sprawdzenie ustawionej zdefiniowanej przez nas flagi niedostępności(np. poprzez stworzenie pliku statycznego na pojedynczym serwerze backendowym)
5. Może rozłożyć ruch wg wielu dużo lepiej dopasowanych metod niż Round-Robin, które zostały opisane w dalszej części tego artykułu
6. Może połączyć wiele połączeń TCP w jedną sesję, dzięki czemu oszczędzamy serwery w backendzie
7. Umożliwia zaawansowane zarządzanie domeną wg zasad m.in. użycie wielu grup backendowych w zależności od reguły. Dzięki temu możemy nie używać subdomen (domena.tld/a i domena.tld/b mogą prowadzić do innych grup backendowych)
8. Poprzez mechanizmy chmury wzbudza nam kolejne instancje serwerów

Warte bliższego przybliżenia są dostępne mechanizmy rozdzielania ruchu na serwery backendowe. Bardzo ważną opcją przy rozdzielaniu ruchu jest opcja przypisania konkretnej sesji do pierwotnie wybranego serwera. W przypadku plików statycznych nieistotne jest, który serwer nam odpowie. Możemy dostawać np. każdy obrazek na stronie z innego serwera w backendzie i nie będzie to problemem. Inaczej jest w przypadku treści dynamicznych, gdzie używamy sesji i tylko serwer aplikacyjny, z którym nawiązaliśmy sesje zna wartości w ramach tejże sesji. Jeżeli będziemy rozdzielać treści dynamiczne, używające sesji, na losowe serwery w backendzie, skończy się to błędem o nieznalezionej sesji i w efekcie będzie to wyglądało, jakby klient się wylogował.

Możemy skorzystać z takich algorytmów rozdzielania jak:

1. Round-Robin– najprostszy mechanizm, rozdziela po kolei zapytania do serwerów z listy. 
2. Czas odpowiedzi backendu– Load Balancer monitoruje czas odpowiedzi poszczególnych serwerów backendowych i wysyła zapytanie do tego, który najszybciej odpowie 
3. Ilość połączeń– zapytanie jest wysyłane do serwera, który ma najmniej aktywnych połączeń
4. Ratio– rozwiązanie bazujące na Round-Robin, ale wprowadza metrykę dla poszczególnych serwerów. Można przez to ustawić ręcznie, który serwer ma otrzymywać więcej zapytań w stosunku do innych.

Przykładowe rozwiązanie

Zapewne lista możliwości się na tym nie kończy, ale jak można łatwo zauważyć są to bardzo rozbudowane mechanizmy. Przyjrzymy się zatem przykładowej implementacji. Dla uproszczenia schematu pomijamy tutaj warstwę 2 (przełączniki) oraz redundancję na poziomie routerów. Zakładamy, że wszystkie urządzenia w jednym rzędzie są połączone. Do tego przyjmujemy najprostszy wariant, bez dodatkowych serwerów takich jak redis, elasticsearch itd.

 

Powyższy schemat pozwoli nam uzyskać HA na każdym poziomie. Load Balancer dla serwerów aplikacyjnych i bazodanowych oczywiście może być fizycznie tym samym Load Balancerem. Ważne jest to, aby istniały 2 niezależnie fizycznie instancje. Istotne jest to szczególnie przy wirtualizacji, aby serwery wirtualne znajdowały się na fizycznie innej maszynie i osobnej macierzy. Bazy danych muszą się znajdować w trybie master-master. 

Ruch przychodzący z internetu jest kierowany na aktywny Load Balacer (w tym przypadku mamy ustawiony tryb active/passive). Działa to na zasadzie pływającego IP (floating IP zwany też failoverem) – urządzenia ustalają między sobą, które jest aktywne. Load Balancer ma w swojej konfiguracji certyfikat domeny i to on się bezpośrednio łączy się z klientem. Następnie Load Balancer tworzy nowe połączenie do jednego z serwerów aplikacyjnych wg wybranego algorytmu. Serwer aplikacyjny, jeżeli potrzebuje się połączyć z bazą danych, także odpytuje Load Balancer (inny fizycznie lub inny VIP). Drugi Load Balancer wybiera jeden z serwerów bazodanowych i wysyła tam zapytanie od serwera aplikacyjnego. 

Dzięki takiemu podwójnemu użyciu Load Balancera zapewniamy sobie dobrze rozłożenie ruchu, zarówno po stronie serwerów aplikacyjnych, jak i baz danych. Dodatkowo dobrze dobrany monitoring usług, zapewni nam wyeliminowanie niesprawnych serwerów, unikając przestojów.

Podsumowanie

Świat oszalał na punkcie wysokiej dostępności i Load Balancery, trochę ponad swoją nazwę, stały się bardzo ważnym aspektem HA, czyniąc usługi dostępne niemalże w 100% (niestety zdarzają się awarie, które pomimo starań potrafią przerwać usługi  z dobrą architekturą). Z pewnością sama rola rozdzielania ruchu jest bardzo istotna, stała się też bardzo dobrym pretekstem do uzyskania przy okazji wysokiej dostępności.