Zer egin zerbitzari baten boterea eskaera guztiak prozesatzeko nahikoa ez bada eta softwarearen fabrikatzaileak karga orekatzea ematen ez badu? Aukera asko daude, karga-orekatzailea erostetik eskaera kopurua mugatzeraino. Zein den zuzena egoeraren arabera zehaztu behar da, dauden baldintzak kontuan hartuta. Artikulu honetan zer egin dezakezun esango dizugu zure aurrekontua mugatua bada eta doako zerbitzari bat baduzu.
Zerbitzarietako batean karga murriztea beharrezkoa zen sistema gisa, InfoWatch-en DLP (informazio-isurien prebentziorako sistema) aukeratu genuen. Inplementazioaren ezaugarri bat orekatzeko funtzioa "borroka" zerbitzarietako batean jartzea izan zen.
Aurkitu genuen arazoetako bat Source NAT (SNAT) erabiltzeko ezintasuna izan zen. Zergatik behar zen hau eta arazoa nola konpondu zen, gehiago deskribatuko dugu.
Beraz, hasiera batean lehendik zegoen sistemaren diagrama logikoa honelakoa zen:
ICAP trafikoa, SMTP, erabiltzaileen ordenagailuetako gertaerak Traffic Monitor (TM) zerbitzarian prozesatu dira. Aldi berean, datu-basearen zerbitzariak erraz aurre egin zion kargari TM-ko gertaerak prozesatu ondoren, baina TM-aren karga astuna zen. Hori nabaria zen Device Monitor (DM) zerbitzarian mezu-ilara baten agerpenetik, baita TM-ko CPU eta memoria-kargatik ere.
Lehen begiratuan, eskema honi beste TM zerbitzari bat gehitzen badiogu, ICAP edo DM horretara alda liteke, baina metodo hau ez erabiltzea erabaki genuen, akatsen tolerantzia murriztu baitzen.
Irtenbidearen deskribapena
Irtenbide egoki bat bilatzeko prozesuan, libreki banatutako softwarea ezarri genuen batera . Keepalived-ek hutsegite-kluster bat sortzeko arazoa konpontzen duelako eta LVS orekatzailea ere kudea dezakeelako.
Lortu nahi genuenak (TMren karga murriztea eta akatsen tolerantzia maila mantentzea) eskema honen arabera funtzionatu behar zuen:
Funtzionalitatea egiaztatzean, zerbitzarietan instalatutako RedHat muntaia pertsonalizatuak ez duela SNAT onartzen ikusi zen. Gure kasuan, SNAT erabiltzea aurreikusi genuen sarrerako paketeak eta haiei erantzunak IP helbide beretik bidaltzen direla ziurtatzeko, bestela argazki hau lortuko genuke:
Hau onartezina da. Adibidez, proxy zerbitzari batek, paketeak IP birtual batera (VIP) helbide batera bidalita, VIP-en erantzuna esperoko du, baina kasu honetan IP2tik etorriko da babeskopiara bidalitako saioetarako. Irtenbide bat aurkitu zen: beharrezkoa zen beste bideratze-taula bat sortzea babeskopian eta bi TM zerbitzari sare bereizi batekin konektatzea, behean erakusten den moduan:
Ezarpenak
ICAP, SMTP, TCP 9100 zerbitzuak eta horietako batean instalatutako karga-orekatzailea duten bi zerbitzariren eskema ezarriko dugu.
Bi RHEL6 zerbitzari ditugu, eta horietatik biltegi estandarrak eta pakete batzuk kendu dira.
Orekatu behar ditugun zerbitzuak:
β’ ICAP - tcp 1344;
β’ SMTP β tcp 25.
Trafiko transmisio zerbitzua DMtik - tcp 9100.
Lehenik eta behin, sarea planifikatu behar dugu.
IP helbide birtuala (VIP):
β’ IP: 10.20.20.105.
TM6_1 zerbitzaria:
β’ Kanpoko IPa: 10.20.20.101;
β’ Barne IP: 192.168.1.101.
TM6_2 zerbitzaria:
β’ Kanpoko IPa: 10.20.20.102;
β’ Barne IP: 192.168.1.102.
Ondoren, IP birbidaltzea gaituko dugu bi TM zerbitzarietan. Nola egin RedHat-en deskribatzen da .
Guk erabakiko dugu zerbitzarietatik zein den nagusia eta zein izango den babeskopia. Izan bedi maisua TM6_1, eta babeskopia TM6_2.
Babeskopia egiteko orekatzaileen bideratze-taula eta bideratze-arau berriak sortzen ditugu:
[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 balancerGoiko komandoek funtzionatzen dute sistema berrabiarazi arte. Berrabiarazi ondoren ibilbideak mantentzen direla ziurtatzeko, sartu dezakezu /etc/rc.d/rc.local, baina hobe ezarpen fitxategiaren bidez /etc/sysconfig/network-scripts/route-eth1 (oharra: sintaxi ezberdina erabiltzen da hemen).
Instalatu keepalived bi TM zerbitzarietan. Banaketa iturri gisa rpmfind.net erabili dugu:
[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.rpmKeepalived ezarpenetan, zerbitzarietako bat maisu gisa esleitzen dugu, bestea babeskopia gisa. Ondoren, VIP eta zerbitzuak ezarri ditugu karga orekatzeko. Ezarpen fitxategia hemen kokatu ohi da: /etc/keepalived/keepalived.conf.
TM1 zerbitzariaren ezarpenak
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
}
}
}TM2 zerbitzariaren ezarpenak
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
}
}LVS maisuan instalatzen dugu, trafikoa orekatuko duena. Ez du zentzurik bigarren zerbitzarirako orekatzailea instalatzeak, konfigurazioan bi zerbitzari baino ez ditugu eta.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmBalantzailea keepalived-ek kudeatuko du, dagoeneko konfiguratuta duguna.
Irudia osatzeko, gehi dezagun keepalived bi zerbitzarietan abiarazteko automatikoki:
[root@tm6_1 ~]#chkconfig keepalived onOndorioa
Emaitzak egiaztatzea
Exekutatu dezagun keepalived bi zerbitzarietan:
service keepalived startVRRP helbide birtual baten erabilgarritasuna egiaztatzea
Ziurta dezagun VIP-a maisuan dagoela:
Eta ez dago VIP babeskopian:
Ping komandoa erabiliz, VIP-aren erabilgarritasuna egiaztatuko dugu:
Orain maisua itzal dezakezu eta komandoa berriro exekutatu dezakezu ping.
Emaitza berdina izan beharko litzateke, eta babeskopian VIP ikusiko dugu:
Zerbitzuaren balantzea egiaztatzea
Har dezagun SMTP adibidez. Abiarazi ditzagun bi konexio 10.20.20.105 aldi berean:
telnet 10.20.20.105 25Masterrean ikusi beharko genuke bi konexioak aktibo daudela eta zerbitzari desberdinetara konektatuta daudela:
[root@tm6_1 ~]#watch ipvsadm βLn
Horrela, TM zerbitzuen akatsekiko tolerantzia-konfigurazioa ezarri dugu TM zerbitzarietako batean orekatzailea instalatuz. Gure sistemarentzat, horrek TM-ko karga erdira murriztu zuen, eta horri esker, sistema erabiliz eskalatze horizontalaren faltaren arazoa konpontzea posible zen.
Kasu gehienetan, irtenbide hau azkar eta kostu gehigarririk gabe ezartzen da, baina batzuetan hainbat muga eta zailtasun daude konfigurazioan, adibidez, UDP trafikoa orekatzean.
Iturria: www.habr.com