Što učiniti ako snaga jednog poslužitelja nije dovoljna za obradu svih zahtjeva, a proizvođač softvera ne osigurava balansiranje opterećenja? Postoji mnogo opcija, od kupnje balansera opterećenja do ograničenja broja zahtjeva. Koji je ispravan mora se odrediti prema situaciji, uzimajući u obzir postojeće uvjete. U ovom članku ćemo vam reći što možete učiniti ako vam je proračun ograničen, a imate besplatan poslužitelj.
Kao sustav za koji je bilo potrebno smanjiti opterećenje jednog od poslužitelja odabrali smo DLP (information leakage prevention system) tvrtke InfoWatch. Značajka implementacije bilo je postavljanje funkcije balansera na jedan od "borbenih" poslužitelja.
Jedan od problema s kojima smo se susreli bila je nemogućnost korištenja izvornog NAT-a (SNAT). Zašto je to bilo potrebno i kako je problem riješen, opisat ćemo dalje.
Dakle, u početku je logički dijagram postojećeg sustava izgledao ovako:
ICAP promet, SMTP, događaji s korisničkih računala obrađeni su na poslužitelju Traffic Monitor (TM). U isto vrijeme, poslužitelj baze podataka lako se nosio s opterećenjem nakon obrade događaja na TM-u, ali je opterećenje samog TM-a bilo veliko. To je bilo vidljivo iz pojavljivanja reda poruka na poslužitelju Device Monitor (DM), kao i iz CPU-a i opterećenja memorije na TM-u.
Na prvi pogled, ako ovoj shemi dodamo još jedan TM poslužitelj, na njega se može prebaciti ili ICAP ili DM, ali smo odlučili ne koristiti ovu metodu, jer je smanjena tolerancija na greške.
Opis rješenja
U procesu traženja odgovarajućeg rješenja, odlučili smo se za besplatno distribuirani softver zajedno s . Jer keepalived rješava problem stvaranja failover klastera i također može upravljati LVS balanserom.
Ono što smo htjeli postići (smanjiti opterećenje TM-a i održati trenutnu razinu tolerancije na pogreške) trebalo je funkcionirati prema sljedećoj shemi:
Prilikom provjere funkcionalnosti pokazalo se da prilagođeni RedHat sklop instaliran na poslužiteljima ne podržava SNAT. U našem slučaju planirali smo koristiti SNAT kako bismo osigurali da se dolazni paketi i odgovori na njih šalju s iste IP adrese, inače bismo dobili sljedeću sliku:
Ovo je neprihvatljivo. Na primjer, proxy poslužitelj, nakon što je poslao pakete na virtualnu IP (VIP) adresu, očekivat će odgovor od VIP-a, ali u ovom slučaju on će doći s IP2 za sesije poslane u backup. Rješenje je pronađeno: bilo je potrebno napraviti još jednu tablicu usmjeravanja na sigurnosnoj kopiji i povezati dva TM poslužitelja s zasebnom mrežom, kao što je prikazano u nastavku:
postavke
Implementirat ćemo shemu od dva poslužitelja s ICAP, SMTP, TCP 9100 uslugama i balanserom opterećenja instaliranim na jednom od njih.
Imamo dva RHEL6 poslužitelja s kojih su uklonjeni standardni repozitoriji i neki paketi.
Usluge koje trebamo uravnotežiti:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Usluga prijenosa prometa od DM – tcp 9100.
Prvo moramo isplanirati mrežu.
Virtualna IP adresa (VIP):
• IP: 10.20.20.105.
Poslužitelj TM6_1:
• Vanjski IP: 10.20.20.101;
• Interni IP: 192.168.1.101.
Poslužitelj TM6_2:
• Vanjski IP: 10.20.20.102;
• Interni IP: 192.168.1.102.
Zatim omogućujemo IP prosljeđivanje na dva TM poslužitelja. Kako to učiniti opisano je na RedHatu .
Odlučujemo koji ćemo od poslužitelja imati glavni, a koji rezervni. Neka glavni bude TM6_1, rezervni TM6_2.
Na sigurnosnoj kopiji stvaramo novu tablicu usmjeravanja balansera i pravila usmjeravanja:
[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 balancerGornje naredbe rade dok se sustav ponovno ne pokrene. Kako biste osigurali očuvanje ruta nakon ponovnog pokretanja, možete ih unijeti u /etc/rc.d/rc.local, ali bolje kroz datoteku postavki /etc/sysconfig/network-scripts/route-eth1 (napomena: ovdje se koristi drugačija sintaksa).
Instalirajte keepalived na oba TM poslužitelja. Koristili smo rpmfind.net kao izvor distribucije:
[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.rpmU postavkama keepalived jedan od poslužitelja dodjeljujemo kao glavni, a drugi kao rezervni. Zatim postavljamo VIP i usluge za balansiranje opterećenja. Datoteka postavki obično se nalazi ovdje: /etc/keepalived/keepalived.conf.
Postavke za TM1 poslužitelj
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
}
}
}Postavke za TM2 poslužitelj
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 postavljamo LVS koji će uravnotežiti promet. Nema smisla instalirati balanser za drugi poslužitelj, jer imamo samo dva poslužitelja u konfiguraciji.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmBalancerom će upravljati keepalived, koji smo već konfigurirali.
Da dovršimo sliku, dodajmo keepalived za automatsko pokretanje na oba poslužitelja:
[root@tm6_1 ~]#chkconfig keepalived onZaključak
Provjera rezultata
Pokrenimo keepalived na oba poslužitelja:
service keepalived startProvjera dostupnosti VRRP virtualne adrese
Uvjerimo se da je VIP na masteru:
I nema VIP-a na sigurnosnoj kopiji:
Pomoću naredbe ping provjerit ćemo dostupnost VIP-a:
Sada možete isključiti master i ponovno pokrenuti naredbu ping.
Rezultat bi trebao ostati isti, a na backupu ćemo vidjeti VIP:
Provjera balansiranja usluge
Uzmimo za primjer SMTP. Pokrenimo dvije veze na 10.20.20.105 istovremeno:
telnet 10.20.20.105 25Na masteru bismo trebali vidjeti da su obje veze aktivne i povezane na različite poslužitelje:
[root@tm6_1 ~]#watch ipvsadm –Ln
Stoga smo implementirali konfiguraciju TM usluga otpornu na pogreške instaliranjem balansera na jednom od TM poslužitelja. Za naš sustav ovo je prepolovilo opterećenje TM-a, što je omogućilo rješavanje problema nedostatka horizontalnog skaliranja pomoću sustava.
U većini slučajeva ovo se rješenje implementira brzo i bez dodatnih troškova, no ponekad postoje brojna ograničenja i poteškoće u konfiguraciji, primjerice, kod balansiranja UDP prometa.
Izvor: www.habr.com