Co zrobić, jeśli moc jednego serwera nie wystarczy do obsługi wszystkich żądań, a producent oprogramowania nie zapewnia równoważenia obciążenia? Opcji jest wiele, od zakupu modułu równoważenia obciążenia po ograniczenie liczby żądań. To, który z nich jest poprawny, należy określić na podstawie sytuacji, biorąc pod uwagę istniejące warunki. W tym artykule dowiesz się, co możesz zrobić, jeśli Twój budżet jest ograniczony i masz darmowy serwer.
Jako system dla którego konieczne było zmniejszenie obciążenia jednego z serwerów wybraliśmy DLP (system zapobiegania wyciekom informacji) firmy InfoWatch. Cechą wdrożenia było umieszczenie funkcji balansu na jednym z serwerów „bojowych”.
Jednym z problemów, jaki napotkaliśmy, była niemożność użycia Source NAT (SNAT). Dlaczego było to potrzebne i jak rozwiązano problem, opiszemy dalej.
Zatem początkowo schemat logiczny istniejącego systemu wyglądał następująco:
Ruch ICAP, SMTP i zdarzenia z komputerów użytkowników były przetwarzane na serwerze Traffic Monitor (TM). Jednocześnie serwer bazy danych bez problemu poradził sobie z obciążeniem po przetworzeniu zdarzeń na TM, jednak obciążenie samej TM było duże. Było to widoczne po pojawieniu się kolejki komunikatów na serwerze Device Monitor (DM), a także po obciążeniu procesora i pamięci TM.
Na pierwszy rzut oka, jeśli dodamy do tego schematu kolejny serwer TM, wówczas można będzie na niego przełączyć albo ICAP, albo DM, jednak zdecydowaliśmy się nie stosować tej metody, ponieważ zmniejszono odporność na błędy.
Opis rozwiązania
W procesie poszukiwania odpowiedniego rozwiązania zdecydowaliśmy się na oprogramowanie swobodnie dystrybuowane wraz z . Ponieważ keepalived rozwiązuje problem tworzenia klastra awaryjnego i może także zarządzać balanserem LVS.
To, co chcieliśmy osiągnąć (zmniejszyć obciążenie TM i utrzymać obecny poziom odporności na uszkodzenia), powinno działać według następującego schematu:
Podczas sprawdzania funkcjonalności okazało się, że zainstalowany na serwerach niestandardowy montaż RedHat nie obsługuje SNAT. W naszym przypadku planowaliśmy zastosować SNAT, aby mieć pewność, że przychodzące pakiety i odpowiedzi na nie będą wysyłane z tego samego adresu IP, w przeciwnym razie otrzymalibyśmy następujący obraz:
To jest niedopuszczalne. Na przykład serwer proxy po wysłaniu pakietów na wirtualny adres IP (VIP) będzie oczekiwał odpowiedzi od VIP-a, ale w tym przypadku będzie ona pochodzić z protokołu IP2 w przypadku sesji wysłanych do kopii zapasowej. Znaleziono rozwiązanie: konieczne było utworzenie kolejnej tablicy routingu na kopii zapasowej i połączenie dwóch serwerów TM oddzielną siecią, jak pokazano poniżej:
Ustawienia
Wdrożymy schemat dwóch serwerów z usługami ICAP, SMTP, TCP 9100 i zainstalowanym na jednym z nich modułem równoważenia obciążenia.
Mamy dwa serwery RHEL6, z których usunięto standardowe repozytoria i część pakietów.
Usługi, które musimy zrównoważyć:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Usługa transmisji ruchu z DM – tcp 9100.
Najpierw musimy zaplanować sieć.
Wirtualny adres IP (VIP):
• IP: 10.20.20.105.
Serwer TM6_1:
• Zewnętrzny adres IP: 10.20.20.101;
• Wewnętrzny adres IP: 192.168.1.101.
Serwer TM6_2:
• Zewnętrzny adres IP: 10.20.20.102;
• Wewnętrzny adres IP: 192.168.1.102.
Następnie włączamy przekazywanie IP na dwóch serwerach TM. Jak to zrobić opisano w RedHat .
Decydujemy, który z serwerów będziemy posiadać, będzie serwerem głównym, a który zapasowym. Niech master będzie TM6_1, kopia zapasowa będzie TM6_2.
Podczas tworzenia kopii zapasowej tworzymy nową tabelę routingu modułu równoważącego i reguły routingu:
[root@tm6_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[root@tm6_2 ~]ip rule add from 192.168.1.102 table balancer
[root@tm6_2 ~]ip route add default via 192.168.1.101 table balancerPowyższe polecenia działają do momentu ponownego uruchomienia systemu. Aby mieć pewność, że trasy zostaną zachowane po ponownym uruchomieniu, możesz je wprowadzić /etc/rc.d/rc.local, ale lepiej poprzez plik ustawień /etc/sysconfig/network-scripts/route-eth1 (uwaga: zastosowano tu inną składnię).
Zainstaluj Keepalive na obu serwerach TM. Jako źródło dystrybucji wykorzystaliśmy stronępmfind.net:
[root@tm6_1 ~]#yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/keepalived-1.2.13-5.el6_6.x86_64.rpmW ustawieniach keepalived jeden z serwerów przypisujemy jako master, drugi jako zapasowy. Następnie ustawiamy VIP i usługi do równoważenia obciążenia. Plik ustawień zwykle znajduje się tutaj: /etc/keepalived/keepalived.conf.
Ustawienia serwera TM1
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state MASTER
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 151
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}
virtual_server 10.20.20.105 1344 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 25 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 9100 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
}Ustawienia serwera TM2
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}Instalujemy LVS na masterze, który zrównoważy ruch. Nie ma sensu instalować balansera dla drugiego serwera, skoro w konfiguracji mamy tylko dwa serwery.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmBalanserem będzie zarządzał program keepalived, który już skonfigurowaliśmy.
Aby dopełnić obraz, dodajmy keepalive do autostartu na obu serwerach:
[root@tm6_1 ~]#chkconfig keepalived onwniosek
Sprawdzanie wyników
Uruchommy keepalive na obu serwerach:
service keepalived startSprawdzanie dostępności adresu wirtualnego VRRP
Upewnijmy się, że VIP jest na masterze:
I nie ma VIP-a na kopii zapasowej:
Za pomocą polecenia ping sprawdzimy dostępność VIP-a:
Teraz możesz zamknąć master i ponownie uruchomić polecenie ping.
Wynik powinien pozostać taki sam, a na kopii zapasowej zobaczymy VIP:
Sprawdzanie bilansowania usług
Weźmy na przykład SMTP. Uruchommy jednocześnie dwa połączenia do 10.20.20.105:
telnet 10.20.20.105 25Na masterze powinniśmy zobaczyć, że oba połączenia są aktywne i połączone z różnymi serwerami:
[root@tm6_1 ~]#watch ipvsadm –Ln
Tym samym wdrożyliśmy odporną na awarie konfigurację usług TM instalując balanser na jednym z serwerów TM. W naszym systemie zmniejszyło to obciążenie TM o połowę, co pozwoliło rozwiązać problem braku skalowania poziomego za pomocą systemu.
W większości przypadków rozwiązanie to wdraża się szybko i bez dodatkowych kosztów, czasem jednak pojawia się szereg ograniczeń i trudności w konfiguracji, np. przy równoważeniu ruchu UDP.
Źródło: www.habr.com