Vad ska man göra om kraften hos en server inte räcker till för att behandla alla förfrågningar och mjukvarutillverkaren inte tillhandahåller lastbalansering? Det finns många alternativ, från att köpa en lastbalanserare till att begränsa antalet förfrågningar. Vilken som är korrekt måste avgöras av situationen, med hänsyn till befintliga förhållanden. I den här artikeln kommer vi att berätta vad du kan göra om din budget är begränsad och du har en gratis server.
Som ett system för vilket det var nödvändigt att minska belastningen på en av servrarna valde vi DLP (informationsläckageförebyggande system) från InfoWatch. Ett inslag i implementeringen var placeringen av balanseringsfunktionen på en av "strids"-servrarna.
Ett av problemen vi stötte på var oförmågan att använda Source NAT (SNAT). Varför detta behövdes och hur problemet löstes kommer vi att förklara vidare.
Så initialt såg det logiska diagrammet över det befintliga systemet ut så här:
ICAP-trafik, SMTP, händelser från användardatorer behandlades på Traffic Monitor (TM)-servern. Samtidigt klarade databasservern lätt belastningen efter att ha bearbetat händelser på TM, men belastningen på själva TM:n var stor. Detta framgick av uppkomsten av en meddelandekö på Device Monitor (DM)-servern, såväl som från CPU- och minnesbelastningen på TM.
Vid första anblicken, om vi lägger till en annan TM-server till detta schema, kan antingen ICAP eller DM bytas till det, men vi bestämde oss för att inte använda den här metoden, eftersom feltoleransen minskade.
Beskrivning av lösningen
I processen att leta efter en lämplig lösning bestämde vi oss för fritt distribuerad programvara tillsammans med . Eftersom keepalived löser problemet med att skapa ett failover-kluster och kan även hantera LVS-balanseraren.
Det vi ville uppnå (minska belastningen på TM och bibehålla den nuvarande feltoleransnivån) borde ha fungerat enligt följande schema:
Vid kontroll av funktionaliteten visade det sig att den anpassade RedHat-monteringen installerad på servrarna inte stöder SNAT. I vårt fall planerade vi att använda SNAT för att säkerställa att inkommande paket och svar på dem skickas från samma IP-adress, annars skulle vi få följande bild:
Det här är oacceptabelt. Till exempel kommer en proxyserver som har skickat paket till en virtuell IP-adress (VIP) att förvänta sig ett svar från VIP, men i det här fallet kommer det från IP2 för sessioner som skickas till backup. En lösning hittades: det var nödvändigt att skapa en annan routingtabell på säkerhetskopian och ansluta två TM-servrar med ett separat nätverk, som visas nedan:
Inställningar
Vi kommer att implementera ett schema med två servrar med ICAP, SMTP, TCP 9100-tjänster och en lastbalanserare installerad på en av dem.
Vi har två RHEL6-servrar, från vilka standardförråden och några paket har tagits bort.
Tjänster som vi behöver balansera:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Trafiköverföringstjänst från DM – tcp 9100.
Först måste vi planera nätverket.
Virtuell IP-adress (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.
Sedan aktiverar vi IP-vidarebefordran på två TM-servrar. Hur man gör detta beskrivs på RedHat .
Vi bestämmer vilken av servrarna vi ska ha är den huvudsakliga och vilken som ska vara backup. Låt master vara TM6_1, backup vara TM6_2.
Vid säkerhetskopiering skapar vi en ny balanseringsrutttabell och routingregler:
[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 balancerOvanstående kommandon fungerar tills systemet startas om. För att säkerställa att rutterna bevaras efter en omstart kan du ange dem /etc/rc.d/rc.local, men bättre genom inställningsfilen /etc/sysconfig/network-scripts/route-eth1 (obs: annan syntax används här).
Installera keepalived på båda TM-servrarna. Vi använde rpmfind.net som distributionskälla:
[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-inställningarna tilldelar vi en av servrarna som master, den andra som backup. Sedan ställer vi in VIP och tjänster för lastbalansering. Inställningsfilen finns vanligtvis här: /etc/keepalived/keepalived.conf.
Inställningar för 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
}
}
}Inställningar för 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 installerar LVS på mastern, vilket kommer att balansera trafiken. Det är ingen mening att installera en balanserare för den andra servern, eftersom vi bara har två servrar 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.rpmBalanseraren kommer att hanteras av Keepalved, som vi redan har konfigurerat.
För att slutföra bilden, låt oss lägga till keepalived till autostart på båda servrarna:
[root@tm6_1 ~]#chkconfig keepalived onSlutsats
Kontrollerar resultaten
Låt oss köra Keepalive på båda servrarna:
service keepalived startKontrollera tillgängligheten för en virtuell VRRP-adress
Låt oss se till att VIP är på master:
Och det finns ingen VIP på backup:
Med hjälp av ping-kommandot kommer vi att kontrollera tillgängligheten för VIP:en:
Nu kan du stänga av master och köra kommandot igen ping.
Resultatet bör förbli detsamma, och vid säkerhetskopiering kommer vi att se VIP:
Kontrollera servicebalansering
Låt oss ta SMTP till exempel. Låt oss starta två anslutningar till 10.20.20.105 samtidigt:
telnet 10.20.20.105 25På master bör vi se att båda anslutningarna är aktiva och anslutna till olika servrar:
[root@tm6_1 ~]#watch ipvsadm –Ln
Således har vi implementerat en feltolerant konfiguration av TM-tjänster genom att installera en balanserare på en av TM-servrarna. För vårt system minskade detta belastningen på TM med hälften, vilket gjorde det möjligt att lösa problemet med bristande horisontell skalning med hjälp av systemet.
I de flesta fall implementeras denna lösning snabbt och utan extra kostnader, men ibland finns det ett antal begränsningar och svårigheter i konfigurationen, till exempel vid balansering av UDP-trafik.
Källa: will.com