Hva skal jeg gjøre hvis kraften til én server ikke er nok til å behandle alle forespørsler, og programvareprodusenten ikke gir lastbalansering? Det er mange alternativer, fra å kjøpe en lastbalanser til å begrense antall forespørsler. Hvilken som er riktig må avgjøres av situasjonen, under hensyntagen til eksisterende forhold. I denne artikkelen vil vi fortelle deg hva du kan gjøre hvis budsjettet ditt er begrenset og du har en gratis server.
Som et system det var nødvendig å redusere belastningen på en av serverne for, valgte vi DLP (informasjonslekkasjeprevensjonssystem) fra InfoWatch. Et trekk ved implementeringen var plasseringen av balanseringsfunksjonen på en av "kamp"-serverne.
Et av problemene vi møtte var manglende evne til å bruke Source NAT (SNAT). Hvorfor dette var nødvendig og hvordan problemet ble løst, vil vi beskrive nærmere.
Så i utgangspunktet så det logiske diagrammet over det eksisterende systemet slik ut:
ICAP-trafikk, SMTP, hendelser fra brukerdatamaskiner ble behandlet på Traffic Monitor (TM)-serveren. Samtidig taklet databaseserveren enkelt belastningen etter å ha behandlet hendelser på TM, men belastningen på selve TM var stor. Dette var tydelig fra utseendet til en meldingskø på Device Monitor (DM)-serveren, samt fra CPU- og minnebelastningen på TM.
Ved første øyekast, hvis vi legger til en annen TM-server til denne ordningen, kan enten ICAP eller DM byttes til den, men vi bestemte oss for ikke å bruke denne metoden, siden feiltoleransen ble redusert.
Beskrivelse av løsningen
I prosessen med å søke etter en passende løsning, slo vi oss til fritt distribuert programvare sammen med . Fordi keepalive løser problemet med å lage en failover-klynge og kan også administrere LVS-balanseren.
Det vi ønsket å oppnå (redusere belastningen på TM og opprettholde gjeldende feiltoleransenivå) burde ha fungert i henhold til følgende skjema:
Når du sjekket funksjonaliteten, viste det seg at den tilpassede RedHat-monteringen installert på serverne ikke støtter SNAT. I vårt tilfelle planla vi å bruke SNAT for å sikre at innkommende pakker og svar på dem sendes fra samme IP-adresse, ellers ville vi få følgende bilde:
Dette er uakseptabelt. For eksempel vil en proxy-server som har sendt pakker til en virtuell IP-adresse (VIP) forvente et svar fra VIP, men i dette tilfellet vil det komme fra IP2 for økter som sendes til backup. En løsning ble funnet: det var nødvendig å lage en annen rutingtabell på sikkerhetskopien og koble to TM-servere med et separat nettverk, som vist nedenfor:
Innstillinger
Vi vil implementere et opplegg med to servere med ICAP, SMTP, TCP 9100 tjenester og en lastbalanser installert på en av dem.
Vi har to RHEL6-servere, som standardlagrene og noen pakker er fjernet fra.
Tjenester som vi trenger å balansere:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Trafikkoverføringstjeneste fra DM – tcp 9100.
Først må vi planlegge nettverket.
Virtuell 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.
Deretter aktiverer vi IP-videresending på to TM-servere. Hvordan du gjør dette er beskrevet på RedHat .
Vi bestemmer hvilken av serverne vi skal ha som er den viktigste og hvilken som skal være backup. La master være TM6_1, backup være TM6_2.
Ved backup lager vi en ny balanserrutingstabell og rutingsregler:
[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 balancerKommandoene ovenfor fungerer til systemet startes på nytt. For å sikre at rutene blir bevart etter en omstart, kan du legge dem inn /etc/rc.d/rc.local, men bedre gjennom innstillingsfilen /etc/sysconfig/network-scripts/route-eth1 (merk: annen syntaks brukes her).
Installer keepalived på begge TM-serverne. Vi brukte rpmfind.net som distribusjonskilden:
[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-innstillingene tildeler vi en av serverne som master, den andre som backup. Da setter vi VIP og tjenester for lastbalansering. Innstillingsfilen er vanligvis plassert her: /etc/keepalived/keepalived.conf.
Innstillinger 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
}
}
}Innstillinger 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 balansere trafikken. Det gir ingen mening å installere en balanserer for den andre serveren, siden vi bare har to servere i konfigurasjonen.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmBalanseringen vil bli administrert av Keepalved, som vi allerede har konfigurert.
For å fullføre bildet, la oss legge til keepalive til autostart på begge serverne:
[root@tm6_1 ~]#chkconfig keepalived onKonklusjon
Sjekker resultatene
La oss kjøre Keepalive på begge serverne:
service keepalived startSjekke tilgjengeligheten til en virtuell VRRP-adresse
La oss sørge for at VIP er på master:
Og det er ingen VIP på backup:
Ved å bruke ping-kommandoen vil vi sjekke tilgjengeligheten til VIP-en:
Nå kan du slå av master og kjøre kommandoen på nytt ping.
Resultatet skal forbli det samme, og ved sikkerhetskopiering vil vi se VIP:
Sjekke tjenestebalansering
La oss ta SMTP for eksempel. La oss starte to tilkoblinger til 10.20.20.105 samtidig:
telnet 10.20.20.105 25På master bør vi se at begge forbindelsene er aktive og koblet til forskjellige servere:
[root@tm6_1 ~]#watch ipvsadm –Ln
Dermed har vi implementert en feiltolerant konfigurasjon av TM-tjenester ved å installere en balanserer på en av TM-serverne. For vårt system reduserte dette belastningen på TM med det halve, noe som gjorde det mulig å løse problemet med manglende horisontal skalering ved hjelp av systemet.
I de fleste tilfeller implementeres denne løsningen raskt og uten ekstra kostnader, men noen ganger er det en rekke begrensninger og vanskeligheter i konfigurasjonen, for eksempel ved balansering av UDP-trafikk.
Kilde: www.habr.com