Zapewnienie wysokiej dostępności wymaga zaprojektowania odpowiedniej architektury – jednym z jej elementów jest równoważenie obciążenia pomiędzy wieloma serwerami obsługującymi tę samą witrynę lub aplikację.

Witryna lub aplikacja, która nie generuje zbyt dużego ruchu, może rezydować na jednym serwerze. Architektura rozwiązania zmienia się diametralnie, gdy głównymi celami staje się osiągnięcie wysokiej dostępności oraz przygotowanie usługi do przyjęcia dużej ilości użytkowników. Wtedy pojawia się potrzeba uruchomienia load balancera, który będzie rozdzielał żądania pomiędzy większą liczbę serwerów pracujących równolegle.

> Między węzłami

Istnieje wiele produktów do równoważenia obciążenia. Do wyboru są między innymi sprzętowe load balancery oraz płatne i darmowe oprogramowanie. Load balancing to także jedna z funkcji opcjonalnych, którą można uruchomić w najpopularniejszym serwerze webowym – Apache.

Zastosowanie load balancera rozrzucającego żądania pomiędzy węzłami pozwala na osiągnięcie wielu istotnych celów:

• ukrycie serwerów aplikacyjnych za serwerem proxy/load balancerem. Klient, wysyłając żądania, nie poznaje rzeczywistej architektury systemu. Nie wie, że komunikuje się z serwerem, który tylko przekazuje żądania pomiędzy klientem a węzłami. Klient nie wie także, jakiego rodzaju serwery i jaka ich ilość tworzy backend;

• zwiększenie liczby możliwych do obsłużenia jednoczesnych połączeń. Stosowanie pojedynczego serwera niesie swoje ograniczenia wydajnościowe – rozbudowa o dodatkowe procesory i zwiększanie pamięci nie może odbywać się w nieskończoność. Zaangażowanie drugiego i  kolejnych węzłów serwujących tę samą stronę/aplikację pozwala na  obsłużenie większej liczby połączeń oraz sprawniejsze rozładowanie kolejki w chwilach wzmożonego obciążenia;

• load balancer monitoruje dostępność węzłów. Gdy któryś z nich staje się niedostępny, żądania nie są do niego kierowane. Jest to mechanizm, który uwalnia od niedostępności strony ze względu na awarię pojedynczego serwera. Połączenia są kierowane do serwerów aktualnie dostępnych. Gdy serwer backend staje się znów dostępny, load balancer wznawia przekazywanie połączeń do niego;

• możliwość reagowania na zwiększające się obciążenie, wynikające z coraz większej liczby odwiedzin. Dołożenie kolejnego serwera typu backend nie wymaga przestoju całego środowiska. Nowy serwer zostaje dopisany do listy węzłów w konfiguracji load balancera i praktycznie od razu zaczyna obsługiwać przychodzące żądania. Rozbudowa środowiska odbywa się zatem w trybie online;
• możliwość planowania przestojów poszczególnych węzłów przy jednoczesnym zachowaniu dostępności aplikacji. Pozwala to na wykonanie prac naprawczych lub serwisowych, instalację aktualizacji, podnoszenie wersji serwerów backend bez zatrzymywania całego środowiska;
• load balancer pozwala na sterowanie liczbą połączeń kierowanych do poszczególnych serwerów. Dzięki temu można wykorzystywać serwery o lepszych i gorszych parametrach cpu/ram oraz o różnych komponentach sprzętowych do obsługi żądań tej samej aplikacji. Poprzez stosowanie wag można zdecydować, że wydajniejsze serwery obsłużą większą liczbę połączeń, a słabsze mniejszą;
• stosowanie load balancera to jedno z rozwiązań na uczynienie aplikacji odporną na awarie serwerowni. Jeżeli firma posiada dwa ośrodki, podstawowy i zapasowy, to ulokowanie serwerów typu backend w obu chroni przed niedostępnością aplikacji ze względu na awarię jednego z data center. W takim przypadku mechanizm wysokiej dostępności musi być gotowy także dla load balancera.

> Algorytmy i wagi

Serwer Apache obsługuje cztery różne algorytmy do rozrzucania ruchu pomiędzy węzłami. Użycie dowolnego z nich oznacza potrzebę instalacji dodatkowego modułu, po czym wystarczy wskazać jego nazwę w pliku konfiguracyjnym. Moduły te nie oferują żadnych dodatkowych opcji, które można byłoby wykorzystać. Domyślnie stosowanym algorytmem jest by request. Implementuje go moduł mod_lbmethod_byrequest.
Jest to algorytm typu round-robin, który w podstawowej konfiguracji równomiernie rozrzuca przychodzące żądania pomiędzy węzłami. Obciążeniem poszczególnych serwerów można jednak sterować poprzez stosowanie wag. Wtedy żądania nie są przesyłane przez load balancer do serwerów backend w stopniu równym. Waga to liczba w zakresie od 1 do 100, która przypisywana jest serwerom backend. Im większa, tym większą pracę wykona dany serwer. Jeżeli serwer nr 1 będzie posiadał wagę równą 1, a serwer nr 2 wagę równą 2, to drugi z nich wykona dwukrotnie większą pracę niż pierwszy. Jeśli skonfigurowane zostaną trzy serwery typu backend i każdy otrzyma wagę równą 1, to każdy z nich wykona 1/3 pracy. Serwery o większej wadze dostają więcej żądań do obsłużenia. Analogicznie serwery o mniejszej wadze obsługują mniej żądań.

Podobnym algorytmem do powyższego jest by traffic, którego użycie wymaga instalacji modułu mod_lbmethod_bytraffic. Algorytm ten rozdziela żądania na podstawie ruchu, który wygenerowały poszczególne węzły, aby obsłużyć żądania. W przeciwieństwie do algorytmu by request nie bierze pod uwagę ilości obsłużonych żądań. Trzeci algorytm wspierany przez Apache’a to by business. Rozdzielanie pracy odbywa się na podstawie liczby żądań obsługiwanych w danym momencie. Nowe żądanie trafia do serwera, który zajmuje się aktualnie najmniejszą liczbą żądań. Taki sposób poprowadzenia klientów do serwerów backend pozwala kierować żądania tam, gdzie będą one obsłużone, bez długiego oczekiwania w kolejce. Ostatnim algorytmem jest mod_lbmethod_heartbeat, w którym serwery backend informują load balancera o swoim aktualnym stanie (liczbie obsługiwanych połączeń). Na tej podstawie load balancer podejmuje decyzje o wyborze serwera do obsłużenia kolejnego żądania. Użycie tego modułu oznacza zaangażowanie do pracy kolejnych kilku modułów. Serwery backend wysyłają swój status poprzez moduł mod_heartbeat. Te dane load balancer odbiera dzięki modułowi mod_heartmonitor.

[...]

Specjalista ds. utrzymania infrastruktury i operacji. Zajmuje się problematyką budowy i utrzymania centrów przetwarzania danych oraz zarządzania nimi i koordynowaniem zmian dotyczących krytycznej infrastruktury IT.