Hvað á að gera ef kraftur eins netþjóns er ekki nóg til að vinna úr öllum beiðnum og hugbúnaðarframleiðandinn veitir ekki álagsjafnvægi? Það eru margir möguleikar, allt frá því að kaupa álagsjafnara til að takmarka fjölda beiðna. Hver er réttur verður að ráðast af aðstæðum, að teknu tilliti til núverandi aðstæðna. Í þessari grein munum við segja þér hvað þú getur gert ef fjárhagsáætlun þín er takmörkuð og þú ert með ókeypis netþjón.
Sem kerfi sem nauðsynlegt var að draga úr álagi á einn af netþjónunum völdum við DLP (information leaage prevention system) frá InfoWatch. Einkenni útfærslunnar var staðsetning jafnvægisaðgerðarinnar á einum af „bardaga“ netþjónunum.
Eitt af vandamálunum sem við lentum í var vanhæfni til að nota Source NAT (SNAT). Hvers vegna þetta var þörf og hvernig vandamálið var leyst, munum við lýsa nánar.
Svo í upphafi leit rökrétt skýringarmynd núverandi kerfis svona út:
ICAP umferð, SMTP, atburðir frá notendatölvum voru unnar á Traffic Monitor (TM) þjóninum. Á sama tíma réð gagnagrunnsþjónninn auðveldlega við álagið eftir að hafa unnið atburði á TM, en álagið á TM sjálft var mikið. Þetta var augljóst af útliti skilaboða biðröð á Device Monitor (DM) miðlara, sem og frá CPU og minni álagi á TM.
Við fyrstu sýn, ef við bætum öðrum TM miðlara við þetta kerfi, þá gæti annað hvort ICAP eða DM verið skipt yfir í það, en við ákváðum að nota ekki þessa aðferð, þar sem bilanaþol var minnkað.
Lýsing á lausninni
Í því ferli að leita að hentugri lausn, settumst við á frjálsan dreifðan hugbúnað ásamt . Vegna þess að keepalived leysir vandamálið við að búa til failover þyrping og getur einnig stjórnað LVS jafnvægisbúnaðinum.
Það sem við vildum ná (minnka álag á TM og viðhalda núverandi bilunarþoli) ætti að hafa virkað samkvæmt eftirfarandi kerfi:
Þegar virknin var skoðuð kom í ljós að sérsniðna RedHat samsetningin sem er uppsett á netþjónunum styður ekki SNAT. Í okkar tilviki ætluðum við að nota SNAT til að tryggja að pakkar sem berast og svör við þeim séu send frá sömu IP tölu, annars myndum við fá eftirfarandi mynd:
Þetta er óviðunandi. Til dæmis mun proxy-þjónn, sem hefur sent pakka á Virtual IP (VIP) vistfang, búast við svari frá VIP, en í þessu tilviki mun það koma frá IP2 fyrir lotur sem sendar eru til öryggisafrits. Lausn fannst: það var nauðsynlegt að búa til aðra leiðartöflu á öryggisafritinu og tengja tvo TM netþjóna við sérstakt net, eins og sýnt er hér að neðan:
Stillingar
Við munum innleiða kerfi tveggja netþjóna með ICAP, SMTP, TCP 9100 þjónustu og álagsjafnara uppsett á einum þeirra.
Við erum með tvo RHEL6 netþjóna, sem staðlaðar geymslur og sumir pakkar hafa verið fjarlægðir úr.
Þjónusta sem við þurfum að koma á jafnvægi:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Umferðarflutningsþjónusta frá DM – tcp 9100.
Fyrst þurfum við að skipuleggja netið.
Sýndar IP tölu (VIP):
• IP: 10.20.20.105.
Miðlari TM6_1:
• Ytri IP: 10.20.20.101;
• Innri IP: 192.168.1.101.
Miðlari TM6_2:
• Ytri IP: 10.20.20.102;
• Innri IP: 192.168.1.102.
Þá virkum við IP-framsendingu á tveimur TM netþjónum. Hvernig á að gera þetta er lýst á RedHat .
Við ákveðum hver af netþjónunum sem við munum hafa er aðalþjónninn og hver verður varabúnaðurinn. Látum húsbónda vera TM6_1, afrit vera TM6_2.
Við öryggisafrit búum við til nýja jafnvægisleiðartöflu og leiðarreglur:
[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 balancerOfangreindar skipanir virka þar til kerfið er endurræst. Til að tryggja að leiðirnar séu varðveittar eftir endurræsingu geturðu slegið þær inn /etc/rc.d/rc.local, en betra í gegnum stillingaskrána /etc/sysconfig/network-scripts/route-eth1 (athugið: hér er notuð önnur setningafræði).
Settu upp keepalived á báðum TM netþjónum. Við notuðum rpmfind.net sem dreifingargjafa:
[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.rpmÍ Keepalive stillingunum úthlutum við einum netþjónanna sem meistara, hinum sem öryggisafrit. Síðan setjum við VIP og þjónustu fyrir álagsjafnvægi. Stillingarskráin er venjulega staðsett hér: /etc/keepalived/keepalived.conf.
Stillingar fyrir 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
}
}
}Stillingar fyrir 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ð setjum upp LVS á skipstjóranum, sem mun koma jafnvægi á umferðina. Það þýðir ekkert að setja upp jafnvægisbúnað fyrir seinni netþjóninn þar sem við höfum aðeins tvo netþjóna í uppsetningunni.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmJafnvægisstýringunni verður stjórnað af Keepalved, sem við höfum þegar stillt.
Til að klára myndina skulum við bæta Keepalive við sjálfvirkri ræsingu á báðum netþjónum:
[root@tm6_1 ~]#chkconfig keepalived onÁlyktun
Athugaðu niðurstöðurnar
Við skulum keyra Keepalive á báðum netþjónum:
service keepalived startAthugar framboð á VRRP sýndarvistfangi
Við skulum ganga úr skugga um að VIP sé á master:
Og það er ekkert VIP á öryggisafriti:
Með því að nota ping skipunina munum við athuga hvort VIP sé tiltækt:
Nú geturðu slökkt á master og keyrt skipunina aftur ping.
Niðurstaðan ætti að vera sú sama og við öryggisafrit munum við sjá VIP:
Athugun þjónustujöfnunar
Tökum SMTP sem dæmi. Við skulum ræsa tvær tengingar til 10.20.20.105 samtímis:
telnet 10.20.20.105 25Á master ættum við að sjá að báðar tengingarnar eru virkar og tengdar mismunandi netþjónum:
[root@tm6_1 ~]#watch ipvsadm –Ln
Þannig höfum við innleitt villuþolna uppsetningu á TM þjónustu með því að setja upp jafnvægisbúnað á einum af TM netþjónunum. Fyrir kerfið okkar minnkaði þetta álagið á TM um helming, sem gerði það mögulegt að leysa vandamálið með skort á láréttri skala með því að nota kerfið.
Í flestum tilfellum er þessi lausn innleidd fljótt og án aukakostnaðar, en stundum eru ýmsar takmarkanir og erfiðleikar við uppsetningu, til dæmis þegar jafnvægi er á UDP umferð.
Heimild: www.habr.com