Hvad skal man gøre, hvis kraften fra én server ikke er nok til at behandle alle anmodninger, og softwareproducenten ikke leverer belastningsbalancering? Der er mange muligheder, lige fra at købe en load balancer til at begrænse antallet af anmodninger. Hvilken der er korrekt, skal afgøres af situationen under hensyntagen til eksisterende forhold. I denne artikel vil vi fortælle dig, hvad du kan gøre, hvis dit budget er begrænset, og du har en gratis server.
Som et system, hvor det var nødvendigt at reducere belastningen på en af serverne, valgte vi DLP (information leakage prevention system) fra InfoWatch. Et træk ved implementeringen var placeringen af balancer-funktionen på en af "combat"-serverne.
Et af de problemer, vi stødte på, var manglende evne til at bruge Source NAT (SNAT). Hvorfor dette var nødvendigt, og hvordan problemet blev løst, vil vi beskrive nærmere.
Så oprindeligt det logiske diagram af det eksisterende system så således ud:
ICAP-trafik, SMTP, hændelser fra brugercomputere blev behandlet på Traffic Monitor (TM)-serveren. Samtidig klarede databaseserveren nemt belastningen efter at have behandlet hændelser på TM'en, men belastningen på selve TM'en var stor. Dette var tydeligt fra fremkomsten af en beskedkø på Device Monitor (DM)-serveren samt fra CPU'en og hukommelsesbelastningen på TM'en.
Ved første øjekast, hvis vi tilføjer en anden TM-server til denne ordning, kan enten ICAP eller DM skiftes til den, men vi besluttede ikke at bruge denne metode, da fejltolerancen blev reduceret.
Beskrivelse af løsningen
I processen med at søge efter en passende løsning valgte vi frit distribueret software sammen med . Fordi keepalived løser problemet med at skabe en failover-klynge og kan også administrere LVS balanceren.
Det, vi ønskede at opnå (reducere belastningen på TM og opretholde det nuværende niveau af fejltolerance) skulle have fungeret i henhold til følgende skema:
Ved kontrol af funktionaliteten viste det sig, at den tilpassede RedHat-samling installeret på serverne ikke understøtter SNAT. I vores tilfælde planlagde vi at bruge SNAT til at sikre, at indgående pakker og svar på dem sendes fra den samme IP-adresse, ellers ville vi få følgende billede:
Dette er uacceptabelt. For eksempel vil en proxyserver, der har sendt pakker til en virtuel IP (VIP) adresse, forvente et svar fra VIP, men i dette tilfælde vil det komme fra IP2 for sessioner sendt til backup. En løsning blev fundet: det var nødvendigt at oprette en anden routingtabel på sikkerhedskopien og forbinde to TM-servere med et separat netværk, som vist nedenfor:
Indstillinger
Vi vil implementere et skema med to servere med ICAP, SMTP, TCP 9100 tjenester og en load balancer installeret på en af dem.
Vi har to RHEL6-servere, hvorfra standardlagrene og nogle pakker er blevet fjernet.
Tjenester, som vi skal balancere:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Trafiktransmissionstjeneste fra DM – tcp 9100.
Først skal vi planlægge netværket.
Virtuel IP-adresse (VIP):
• IP: 10.20.20.105.
Server TM6_1:
• Ekstern IP: 10.20.20.101;
• Intern IP: 192.168.1.101.
Server TM6_2:
• Ekstern IP: 10.20.20.102;
• Intern IP: 192.168.1.102.
Så aktiverer vi IP-videresendelse på to TM-servere. Hvordan man gør dette er beskrevet på RedHat .
Vi beslutter, hvilken af serverne vi skal have er den vigtigste, og hvilken der skal være backup. Lad master være TM6_1, backup være TM6_2.
Ved backup opretter vi en ny balancer routing tabel og routing regler:
[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 balancerOvenstående kommandoer virker, indtil systemet genstartes. For at sikre, at ruterne bevares efter en genstart, kan du indtaste dem /etc/rc.d/rc.local, men bedre gennem indstillingsfilen /etc/sysconfig/network-scripts/route-eth1 (bemærk: anden syntaks er brugt her).
Installer keepalived på begge TM-servere. Vi brugte rpmfind.net som distributionskilde:
[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.rpmI keepalive-indstillingerne tildeler vi en af serverne som master, den anden som backup. Så sætter vi VIP og tjenester til belastningsbalancering. Indstillingsfilen er normalt placeret her: /etc/keepalived/keepalived.conf.
Indstillinger for TM1 Server
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
}
}
}Indstillinger for TM2 Server
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
}
}Vi installerer LVS på masteren, som vil balancere trafikken. Det giver ingen mening at installere en balancer til den anden server, da vi kun har to servere i konfigurationen.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmBalanceren vil blive administreret af Keepalved, som vi allerede har konfigureret.
For at fuldende billedet, lad os tilføje Keepalive til autostart på begge servere:
[root@tm6_1 ~]#chkconfig keepalived onKonklusion
Kontrollerer resultaterne
Lad os køre Keepalive på begge servere:
service keepalived startKontrol af tilgængeligheden af en virtuel VRRP-adresse
Lad os sikre os, at VIP er på master:
Og der er ingen VIP på backup:
Ved at bruge ping-kommandoen kontrollerer vi tilgængeligheden af VIP'en:
Nu kan du lukke master og køre kommandoen igen ping.
Resultatet skulle forblive det samme, og på backup vil vi se VIP:
Kontrol af servicebalance
Lad os tage SMTP for eksempel. Lad os starte to forbindelser til 10.20.20.105 samtidigt:
telnet 10.20.20.105 25På master bør vi se, at begge forbindelser er aktive og forbundet til forskellige servere:
[root@tm6_1 ~]#watch ipvsadm –Ln
Vi har således implementeret en fejltolerant konfiguration af TM-tjenester ved at installere en balancer på en af TM-serverne. For vores system reducerede dette belastningen på TM til det halve, hvilket gjorde det muligt at løse problemet med manglende horisontal skalering ved hjælp af systemet.
I de fleste tilfælde implementeres denne løsning hurtigt og uden ekstra omkostninger, men nogle gange er der en række begrænsninger og vanskeligheder i konfigurationen, for eksempel ved afbalancering af UDP-trafik.
Kilde: www.habr.com