Wat te doen als de kracht van één server niet voldoende is om alle verzoeken te verwerken en de softwarefabrikant geen taakverdeling biedt? Er zijn veel mogelijkheden, van het aanschaffen van een load balancer tot het beperken van het aantal verzoeken. Welke juist is, moet worden bepaald door de situatie, rekening houdend met de bestaande omstandigheden. In dit artikel vertellen we je wat je kunt doen als je budget beperkt is en je een vrije server hebt.
Omdat het nodig was om de belasting op één van de servers te verminderen, hebben wij gekozen voor DLP (information lekkage preventie systeem) van InfoWatch. Een kenmerk van de implementatie was de plaatsing van de balancerfunctie op een van de ‘gevechts’-servers.
Een van de problemen die we tegenkwamen was het onvermogen om Source NAT (SNAT) te gebruiken. Waarom dit nodig was en hoe het probleem werd opgelost, zullen we verder beschrijven.
Dus aanvankelijk zag het logische diagram van het bestaande systeem er als volgt uit:
ICAP-verkeer, SMTP en gebeurtenissen van gebruikerscomputers werden verwerkt op de Traffic Monitor (TM)-server. Tegelijkertijd kon de databaseserver de belasting na het verwerken van gebeurtenissen op het TM gemakkelijk aan, maar de belasting op het TM zelf was zwaar. Dit bleek uit het verschijnen van een berichtenwachtrij op de Device Monitor (DM)-server, maar ook uit de CPU- en geheugenbelasting op de TM.
Als we op het eerste gezicht nog een TM-server aan dit schema toevoegen, kan ICAP of DM ernaar worden overgeschakeld, maar we hebben besloten deze methode niet te gebruiken, omdat de fouttolerantie is verminderd.
Beschrijving van de oplossing
Bij het zoeken naar een geschikte oplossing kwamen we uit op vrij verspreide software samen met . Omdat keepalive het probleem van het creëren van een failovercluster oplost en ook de LVS-balancer kan beheren.
Wat we wilden bereiken (de belasting van TM verminderen en het huidige niveau van fouttolerantie handhaven) had volgens het volgende schema moeten werken:
Bij het controleren van de functionaliteit bleek dat de op de servers geïnstalleerde aangepaste RedHat-assembly geen SNAT ondersteunt. In ons geval waren we van plan om SNAT te gebruiken om ervoor te zorgen dat inkomende pakketten en de reacties daarop vanaf hetzelfde IP-adres worden verzonden, anders zouden we het volgende beeld krijgen:
Dit is niet aanvaardbaar. Een proxyserver die pakketten naar een virtueel IP-adres (VIP) heeft verzonden, verwacht bijvoorbeeld een reactie van VIP, maar in dit geval zal deze afkomstig zijn van IP2 voor sessies die naar de back-up zijn verzonden. Er werd een oplossing gevonden: het was nodig om nog een routeringstabel op de back-up te maken en twee TM-servers met een apart netwerk te verbinden, zoals hieronder weergegeven:
Instellingen
We zullen een schema van twee servers implementeren met ICAP-, SMTP-, TCP 9100-services en een load balancer geïnstalleerd op een ervan.
We hebben twee RHEL6-servers, waarvan de standaard repositories en enkele pakketten zijn verwijderd.
Diensten die we in evenwicht moeten brengen:
• ICAP – tcp 1344;
• SMTP – TCP 25.
Verkeerstransmissiedienst van DM – TCP 9100.
Eerst moeten we het netwerk plannen.
Virtueel IP-adres (VIP):
• IP: 10.20.20.105.
ServerTM6_1:
• Extern IP-adres: 10.20.20.101;
• Intern IP-adres: 192.168.1.101.
ServerTM6_2:
• Extern IP-adres: 10.20.20.102;
• Intern IP-adres: 192.168.1.102.
Vervolgens schakelen we IP-forwarding in op twee TM-servers. Hoe je dit doet, staat beschreven op RedHat .
We beslissen welke van de servers we zullen hebben de belangrijkste is en welke de back-up zal zijn. Laat master TM6_1 zijn, backup TM6_2.
Bij het maken van een back-up maken we een nieuwe balancer-routeringstabel en routeringsregels:
[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 balancerDe bovenstaande opdrachten werken totdat het systeem opnieuw wordt opgestart. Om ervoor te zorgen dat de routes na een herstart behouden blijven, kunt u deze invoeren /etc/rc.d/rc.local, maar beter via het instellingenbestand /etc/sysconfig/network-scripts/route-eth1 (opmerking: hier wordt een andere syntaxis gebruikt).
Installeer keepalived op beide TM-servers. We gebruikten rpmfind.net als distributiebron:
[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.rpmIn de keepalive-instellingen wijzen we een van de servers toe als master en de andere als back-up. Vervolgens stellen we VIP en services in voor taakverdeling. Het instellingenbestand bevindt zich meestal hier: /etc/keepalived/keepalived.conf.
Instellingen voor 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
}
}
}Instellingen voor 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
}
}We installeren LVS op de master, die het verkeer in evenwicht brengt. Het heeft geen zin om een balancer voor de tweede server te installeren, aangezien we maar twee servers in de configuratie hebben.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmDe balancer wordt beheerd door keepalived, dat we al hebben geconfigureerd.
Om het plaatje compleet te maken, voegen we keepalived toe aan autostart op beide servers:
[root@tm6_1 ~]#chkconfig keepalived onConclusie
De resultaten controleren
Laten we keepalived op beide servers uitvoeren:
service keepalived startDe beschikbaarheid van een virtueel VRRP-adres controleren
Laten we ervoor zorgen dat de VIP op master staat:
En er is geen VIP op back-up:
Met behulp van het ping-commando controleren we de beschikbaarheid van de VIP:
Nu kunt u master afsluiten en de opdracht opnieuw uitvoeren ping.
Het resultaat zou hetzelfde moeten blijven, en bij de back-up zullen we VIP zien:
Controle van de servicebalans
Laten we SMTP als voorbeeld nemen. Laten we twee verbindingen met 10.20.20.105 tegelijkertijd lanceren:
telnet 10.20.20.105 25Op master zouden we moeten zien dat beide verbindingen actief zijn en verbonden zijn met verschillende servers:
[root@tm6_1 ~]#watch ipvsadm –Ln
Daarom hebben we een fouttolerante configuratie van TM-services geïmplementeerd door een balancer op een van de TM-servers te installeren. Voor ons systeem verminderde dit de belasting van TM met de helft, waardoor het mogelijk werd om het probleem van het gebrek aan horizontale schaling met behulp van het systeem op te lossen.
In de meeste gevallen wordt deze oplossing snel en zonder extra kosten geïmplementeerd, maar soms zijn er een aantal beperkingen en problemen bij de configuratie, bijvoorbeeld bij het balanceren van UDP-verkeer.
Bron: www.habr.com