Mi a teendő, ha egy szerver teljesítménye nem elegendő az összes kérés feldolgozásához, és a szoftver gyártója nem biztosítja a terheléselosztást? Számos lehetőség van, a terheléselosztó vásárlásától a kérések számának korlátozásáig. Hogy melyik a helyes, azt a helyzetnek kell meghatároznia, figyelembe véve a fennálló körülményeket. Ebben a cikkben elmondjuk, mit tehet, ha korlátozott a költségvetése, és ingyenes szervere van.
Olyan rendszerként, amelynél csökkenteni kellett az egyik szerver terhelését, az InfoWatch DLP-t (information leakage protection system) választottuk. A megvalósítás jellemzője volt, hogy az egyensúlyozó funkciót az egyik „harci” szerveren helyezték el.
Az egyik probléma, amellyel találkoztunk, a Source NAT (SNAT) használatának képtelensége volt. Hogy miért volt erre szükség, és hogyan oldották meg a problémát, a továbbiakban leírjuk.
Tehát kezdetben a meglévő rendszer logikai diagramja így nézett ki:
Az ICAP-forgalmat, SMTP-t és a felhasználói számítógépekről érkező eseményeket a Traffic Monitor (TM) szerveren dolgozták fel. Ugyanakkor az adatbázis-kiszolgáló könnyen megbirkózott a TM-en történt események feldolgozása utáni terheléssel, de magának a TM-nek a terhelése nagy volt. Ez nyilvánvaló volt az Eszközfigyelő (DM) szerveren megjelenő üzenetsorból, valamint a TM CPU- és memóriaterheléséből.
Első pillantásra, ha ehhez a sémához adunk egy másik TM szervert, akkor akár ICAP, akár DM váltható rá, de úgy döntöttünk, hogy ezt a módszert nem használjuk, mivel a hibatűrés csökkent.
A megoldás leírása
A megfelelő megoldás keresése során a szabadon terjesztett szoftverek mellett döntöttünk együtt . Mert a keepalived megoldja a feladatátvételi fürt létrehozásának problémáját, és képes kezelni az LVS-kiegyenlítőt is.
То, к чему мы хотели прийти (снизить нагрузку на TM и сохранить текущий уровень отказоустойчивости), должно было работать по следующей схеме:
A funkcionalitás ellenőrzésekor kiderült, hogy a szerverekre telepített egyedi RedHat szerelvény nem támogatja a SNAT-ot. Esetünkben azt terveztük, hogy SNAT használatával biztosítjuk, hogy a bejövő csomagok és az azokra adott válaszok ugyanarról az IP-címről érkezzenek, ellenkező esetben a következő képet kapjuk:
Ez elfogadhatatlan. Például egy proxyszerver, miután virtuális IP (VIP) címre küldte a csomagokat, választ vár a VIP-től, de ebben az esetben az IP2-ről érkezik a biztonsági mentésre küldött munkamenetekre. Megoldást találtunk: létre kellett hozni egy másik útválasztó táblát a biztonsági másolaton, és két TM-szervert külön hálózattal összekapcsolni, az alábbiak szerint:
beállítások
Két szerverből álló sémát fogunk megvalósítani ICAP, SMTP, TCP 9100 szolgáltatásokkal és az egyikre telepített terheléselosztóval.
Két RHEL6 szerverünk van, amelyekről eltávolították a szabványos tárolókat és néhány csomagot.
Szolgáltatások, amelyeket ki kell egyensúlyoznunk:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Forgalom átviteli szolgáltatás a DM-től – tcp 9100.
Először is meg kell terveznünk a hálózatot.
Virtuális IP-cím (VIP):
• IP: 10.20.20.105.
Сервер TM6_1:
• Külső IP: 10.20.20.101;
• Belső IP: 192.168.1.101.
Сервер TM6_2:
• Külső IP: 10.20.20.102;
• Belső IP: 192.168.1.102.
Ezután engedélyezzük az IP továbbítást két TM szerveren. Ennek módját a RedHat ismerteti .
Eldöntjük, hogy melyik szerverünk lesz a fő és melyik a tartalék szerver. Legyen a master TM6_1, a tartalék pedig a TM6_2.
A biztonsági mentés során létrehozunk egy új egyensúlyozó útválasztási táblát és útválasztási szabályokat:
[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 balancerA fenti parancsok a rendszer újraindításáig működnek. Annak érdekében, hogy az útvonalak az újraindítás után is megmaradjanak, megadhatja azokat /etc/rc.d/rc.local, de jobb a beállítási fájlon keresztül /etc/sysconfig/network-scripts/route-eth1 (Megjegyzés: itt más szintaxist használunk).
Telepítse a Keepalivedet mindkét TM-kiszolgálón. Az rpmfind.net-et használtuk terjesztési forrásként:
[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.rpmA Keepalived beállításokban az egyik szervert masternek, a másikat tartaléknak rendeljük. Ezután beállítjuk a VIP-t és a szolgáltatásokat a terheléselosztáshoz. A beállítási fájl általában itt található: /etc/keepalived/keepalived.conf.
A TM1 szerver beállításai
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
}
}
}A TM2 szerver beállításai
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
}
}A masterre LVS-t telepítünk, ami kiegyenlíti a forgalmat. Nincs értelme kiegyensúlyozót telepíteni a második szerverre, mivel csak két szerverünk van a konfigurációban.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmA kiegyensúlyozót a keepalived fogja kezelni, amelyet már konfiguráltunk.
A kép teljessé tételéhez adjuk hozzá a Keepalivedet az automatikus indításhoz mindkét szerveren:
[root@tm6_1 ~]#chkconfig keepalived onKövetkeztetés
Az eredmények ellenőrzése
Запустим keepalived на обоих серверах:
service keepalived startVRRP virtuális cím elérhetőségének ellenőrzése
Győződjünk meg arról, hogy a VIP mesteren van:
És nincs VIP a tartalékban:
A ping paranccsal ellenőrizzük a VIP elérhetőségét:
Most leállíthatja a mestert, és újra futtathatja a parancsot ping.
Az eredménynek változatlannak kell maradnia, és biztonsági mentéskor VIP-t fogunk látni:
A szolgáltatás egyensúlyának ellenőrzése
Vegyük például az SMTP-t. Indítsunk el egyszerre két kapcsolatot a 10.20.20.105-höz:
telnet 10.20.20.105 25A masteren látnunk kell, hogy mindkét kapcsolat aktív és különböző szerverekhez csatlakozik:
[root@tm6_1 ~]#watch ipvsadm –Ln
Így a TM-szolgáltatások hibatűrő konfigurációját valósítottuk meg úgy, hogy az egyik TM-szerverre kiegyenlítőt telepítettünk. A mi rendszerünknél ez a felére csökkentette a TM terhelését, ami lehetővé tette a vízszintes méretezés hiányának a megoldását a rendszer segítségével.
A legtöbb esetben ez a megoldás gyorsan és további költségek nélkül valósul meg, de néha számos korlátozás és nehézség adódik a konfigurációban, például az UDP-forgalom kiegyensúlyozásakor.
Forrás: will.com