LVS keepalived jako alternatywa dla sprzętowych loadbalancerów
Podziel się

Wysoka dostępność systemów oraz utylizacja zasobów to „Święty Gral” zarządzających infrastrukturą. Jeszcze nie widziałem środowiska produkcyjnego które jest w pełni odporne na awarie, nie mówiąc o świadomych ingerencjach w strukturę serwerów np. poprzez aktualizację aplikacji czy rozbudowy bazy serwerowej bez przerywania świadczenia usług. O ile warstwa serwerów aplikacyjnych jak np. JBoss EAP zazwyczaj działa w clustrze HA to im wyżej tym gorzej np. pojedynczy Apache HTTPd jako proxy. Taką wisienką na torcie jest pojedynczy sprzętowy load balancer (LB). Zaciekawiony tym obszarem zacząłem poszukiwać najlepszego rozwiązania dostępnego na mojego ulubionego linuxa.

Większość zapytań do googla o LB kierowała mnie na HAProxy. To rozwiązanie operuje w warstwie 7 OSI, jest wstanie analizować nagłówki HTTP oraz poprzez identyfikator sesji kierować do odpowiedniego tego samego serwera. Ta opcja nie dotyczy połączeń szyfrowanych, tutaj przypisanie odbywa się poprzez stick-table. HA jak najbardziej jest możliwe jest typu multi-master wraz z replikacją synchroniczną tablicy przypisań.

HAproxy zrobił na mnie wrażenie. Jednak to nie to czego szukam, cała komunikacja ma przechodzić przez serwera LB , a gdzie wirtualne IP. Potrzebowałem czegoś wydajniejszego.

LVS + keepalived jako para produktów zazwyczaj pojawiała się jako zamiennik HAProxy. Opisu możliwości pokrywa się z tymi zawartymi z sprzętowych LB.

Linux virtual server (LVS) to LB warstwy 4 OSI nadaje się do wszystkiego co komunikuje się po TCP lub UDP z tym wyjątkiem, że nie „zagląda” w pakiety tylko przekierowuje do serwera docelowego. LVS działa w trzech tybach: NAT, Tunneling i direct routing. Jedyne czego LVS nie potrafi to nadzorowania stanu usług w konsekwencji może kierować klienta do serwera który nie działa. Właśnie keepalived zapełnia tą lukę dostarczając mechanizmu monitorowania stanu serwerów wraz z automatyczną zmianą konfiguracji LVS oraz mechanizmu Virtualnego IP.

Jeśli chodzi o wysoką dostępność to LVS + keepalived dostarczają mechanizmu active-pasive tj. z zapasowymi LB. Jako że LVS swoją tablicę przypisań klientów przekazuje do instancji zapasowych ewentualna awaria LB nie wpływa na aktualnie przeprowadzaną komunikację z serwerem docelowym. Nie jest aż tak różowo, o ile HAProxy sam realizuje połączenie do serwerów i jest wstanie wykryć nie działanie usługi, to w LVS nie ma takiej opcji. Keepalived nadzoruje wprawdzie działanie usług jednak czas reakcji LB na awarię zależy od czasu pomiędzy wywołaniem funkcji sprawdzających.

Na potwierdzenie mojej fascynacji LVSem musiałem przeprowadzić parę okrutnych eksperymentów w konfiguracji  LB + Apache Httpd. Dokładnie chodzi o sprawdzenie jak dalece można się posunąć do ingerencji w poszczególne warstwy infrastruktury bez przerywania świadczenia usług.

Środowisko testów

Do testów wykorzystałem: Red Hat Enterprise Linux 7.0 – zarówno jako LB i serwer Apache HTTPd. Narzędziem testującym/generującym ruch został JMeter. Zawarłem opis konfiguracji byście mogli podobne środowisko wytworzyć u siebie.

LVS + keepalived

Siecią na świat będzie 192.168.123.0/24, narzędzia testujące będą poza tą siecią. Ruch będzie musiał przechodzić przez gatewaya z IP 192.168.123.1. Klienci będą się odpytywać usługę WWW poprzez wirtualny adres ip (VIP) 192.168.123.10 . LVS przekaże połączenia do konkretnych serwerów które bezpośrednio odpowiedzą klientowi via gateway z pominięciem LB.

Instalacja:

Zaczynamy od konfiguracji serwera LB/LVS. Podstawowe pakiety do instalacji to keepalived i ipvsadm

yum install keepalived ipvsadm -y systemctl disable ipvsadm

Pakiet ipvsadm jest tylko do manualnej ingerencji w LVS oraz do podglądania statystyk.

Przydało by się dodać adres (192.168.123.2) do zdalnej administracji.

nmcli con mod eth0 ipv4.dns "192.168.123.1" ipv4.addresses "192.168.123.2/24 
192.168.123.1" ipv4.method manual nmcli c down eth0; nmcli c up eth0

Zostaje konfiguracja keepalived poprzez plik /etc/keepalived/keepalived.conf gdzie w moim przypadku wygląda to tak:

global_defs {
 router_id LVS_DEVEL
}
vrrp_instance VI_1 {
 state MASTER
 interface eth0
 virtual_router_id 10
 priority 100
 advert_int 1
 authentication {
 auth_type PASS
 auth_pass 1111
 }
 virtual_ipaddress {
 192.168.123.10/24 label vip0
 }
}
virtual_server 192.168.123.10 80 {
 delay_loop 6
 lb_algo rr
 lb_kind DR
 persistence_timeout 50
 protocol TCP
 real_server 192.168.123.11 80 {
 weight 1
 HTTP_GET {
 url {
 path /
 status_code 200
 }
 connect_timeout 3
 nb_get_retry 3
 delay_before_retry 3
 }
 }
 real_server 192.168.123.12 80 {
 weight 1
 HTTP_GET {
 url {
 path /
 status_code 200
 }
 connect_timeout 3
 nb_get_retry 3
 delay_before_retry 3
 }
 }
}

Kończąc warto uruchomić usługę keepalived wraz otworzeniem portów na firewallu dla protokołu HTTP.

systemctl restart keepalived
systemctl enable keepalived
firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --zone=public --add-service=http

Jeśli zostało wszystko wykonane prawidłowo na interfejsie eth0 powinien być widoczny adres 192.168.123.10

Następnym krokiem jest konfiguracja serwerów z usługą WWW, na niej będziemy wykonywać testy. Na obu serwerach należy zainstalować Apache httpd

yum install httpd

systemctl restart httpd
systemctl enable httpd

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --zone=public --add-service=http

Tym sposobem podpinamy VIP pod każdy z serwerów WWW. Jak widać prefix tego adresu to 32 to znaczy, adres będzie mógł być używany tylko wewnątrz serwera. Za pomocą tej sztuczki sprawiamy, że serwer będzie odbierał pakiety przekierowywane z LB. Przypisanie tego samego adresu do wielu serwerów powoduje konflikty, zapytania ARP o MAC adres będą wysyłane z wielu serwerów, a tylko LB może posiadać faktycznie działający adres VIP, reszta serwerów powinna ignorować „ARPy”

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

Tym sposobem włączymy rozgłaszanie ARPów. Dla bardziej skomplikowanych konfiguracji sieciowy trzeba stosować inne sposoby zapobiegania wysyłania „arpów”.

Yupi! To już koniec! By sprawdzenie czy to działa, to po prostu należy otworzyć w przeglądarce adresu wirtualnego adresu IP tj. 192.168.123.10/ .

W kolejna artykuł umieszczę testy na wysoką dostępność z wykorzystaniem tej konfiguracji. Serdecznie zapraszam.

Ocena (5 / 1)

Dodaj komentarz

avatar
2000
  Subscribe  
Powiadom o

Skontaktuj się z nami