Čo robiť, ak výkon jedného servera nestačí na spracovanie všetkých požiadaviek a výrobca softvéru neposkytuje vyrovnávanie záťaže? Možností je veľa, od zakúpenia load balanceru až po obmedzenie počtu požiadaviek. Ktorý z nich je správny, musí určiť situácia, berúc do úvahy existujúce podmienky. V tomto článku vám povieme, čo môžete urobiť, ak je váš rozpočet obmedzený a máte bezplatný server.
Ako systém, pre ktorý bolo potrebné znížiť zaťaženie jedného zo serverov, sme zvolili DLP (information leakage prevent system) od InfoWatch. Charakteristickým rysom implementácie bolo umiestnenie funkcie balancer na jeden z „bojových“ serverov.
Jedným z problémov, s ktorými sme sa stretli, bola nemožnosť použiť Source NAT (SNAT). Prečo to bolo potrebné a ako sa problém vyriešil, popíšeme ďalej.
Takže pôvodne logický diagram existujúceho systému vyzeral takto:
Komunikácia ICAP, SMTP, udalosti z počítačov používateľov boli spracované na serveri Traffic Monitor (TM). Zároveň sa databázový server ľahko vyrovnal so záťažou po spracovaní udalostí na PP, ale záťaž na PP bola veľká. Bolo to zrejmé z objavenia sa frontu správ na serveri Device Monitor (DM), ako aj zo zaťaženia CPU a pamäte na TM.
Na prvý pohľad, ak do tejto schémy pridáme ďalší TM server, potom by sa naň dalo prepnúť buď ICAP alebo DM, ale rozhodli sme sa túto metódu nepoužiť, pretože sa znížila odolnosť voči chybám.
Popis riešenia
V procese hľadania vhodného riešenia sme sa rozhodli pre voľne distribuovaný softvér spolu s . Keepalived totiž rieši problém vytvorenia klastra prepnutia pri zlyhaní a dokáže spravovať aj balancer LVS.
To, čo sme chceli dosiahnuť (znížiť zaťaženie TM a zachovať súčasnú úroveň tolerancie chýb), by malo fungovať podľa nasledujúcej schémy:
Pri kontrole funkčnosti sa ukázalo, že vlastná zostava RedHat nainštalovaná na serveroch nepodporuje SNAT. V našom prípade sme plánovali použiť SNAT, aby sme zabezpečili, že prichádzajúce pakety a odpovede na ne budú odosielané z rovnakej IP adresy, inak by sme dostali nasledujúci obrázok:
To je neprijateľné. Napríklad proxy server, ktorý odoslal pakety na virtuálnu IP (VIP) adresu, bude očakávať odpoveď od VIP, ale v tomto prípade príde z IP2 pre relácie odoslané na zálohovanie. Našlo sa riešenie: bolo potrebné vytvoriť ďalšiu smerovaciu tabuľku na zálohe a spojiť dva servery TM so samostatnou sieťou, ako je znázornené nižšie:
Nastavenie
Implementujeme schému dvoch serverov so službami ICAP, SMTP, TCP 9100 a na jednom z nich je nainštalovaný load balancer.
Máme dva servery RHEL6, z ktorých boli odstránené štandardné úložiská a niektoré balíčky.
Služby, ktoré potrebujeme vyvážiť:
• ICAP – TCP 1344;
• SMTP – tcp 25.
Služba prenosu dopravy od DM – tcp 9100.
Najprv musíme naplánovať sieť.
Virtuálna IP adresa (VIP):
• IP: 10.20.20.105.
Server TM6_1:
• Externá IP: 10.20.20.101;
• Interná IP: 192.168.1.101.
Server TM6_2:
• Externá IP: 10.20.20.102;
• Interná IP: 192.168.1.102.
Potom povolíme presmerovanie IP na dvoch serveroch TM. Ako to urobiť, je popísané na RedHat .
Rozhodneme sa, ktorý zo serverov budeme mať je hlavný a ktorý bude záložný. Nech je master TM6_1, záloha je TM6_2.
Pri zálohovaní vytvoríme novú smerovaciu tabuľku balancéra a pravidlá smerovania:
[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 balancerVyššie uvedené príkazy fungujú, kým sa systém nereštartuje. Ak chcete zabezpečiť, aby sa trasy po reštarte zachovali, môžete ich zadať /etc/rc.d/rc.local, ale lepšie cez súbor s nastaveniami /etc/sysconfig/network-scripts/route-eth1 (poznámka: tu je použitá iná syntax).
Nainštalujte keepalived na oba servery TM. Ako zdroj distribúcie sme použili rpmfind.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.rpmV nastaveniach keepalived priradíme jeden zo serverov ako hlavný, druhý ako záložný. Potom nastavíme VIP a služby pre load balancing. Súbor nastavení sa zvyčajne nachádza tu: /etc/keepalived/keepalived.conf.
Nastavenia pre server 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
}
}
}Nastavenia pre server 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
}
}Na master inštalujeme LVS, ktoré vyrovná premávku. Nemá zmysel inštalovať balancer pre druhý server, pretože v konfigurácii máme iba dva servery.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmBalancér bude spravovať keepalived, ktorý sme už nakonfigurovali.
Na dokončenie obrázku pridajte keepalived do automatického spustenia na oboch serveroch:
[root@tm6_1 ~]#chkconfig keepalived onZáver
Kontrola výsledkov
Spustíme keepalived na oboch serveroch:
service keepalived startKontrola dostupnosti virtuálnej adresy VRRP
Uistite sa, že VIP je na master:
A v zálohe nie je žiadny VIP:
Pomocou príkazu ping skontrolujeme dostupnosť VIP:
Teraz môžete vypnúť master a spustiť príkaz znova ping.
Výsledok by mal zostať rovnaký a pri zálohovaní uvidíme VIP:
Kontrola vyváženia služieb
Vezmime si napríklad SMTP. Spustíme dve spojenia na 10.20.20.105 súčasne:
telnet 10.20.20.105 25Na master by sme mali vidieť, že obe pripojenia sú aktívne a pripojené k rôznym serverom:
[root@tm6_1 ~]#watch ipvsadm –Ln
Preto sme implementovali konfiguráciu služieb TM odolnú voči chybám inštaláciou balancéra na jeden zo serverov TM. Pre náš systém to znížilo zaťaženie TM na polovicu, čo umožnilo vyriešiť problém nedostatku horizontálneho škálovania pomocou systému.
Vo väčšine prípadov sa toto riešenie implementuje rýchlo a bez dodatočných nákladov, niekedy však existuje množstvo obmedzení a ťažkostí v konfigurácii, napríklad pri vyrovnávaní prenosu UDP.
Zdroj: hab.com