Beth i'w wneud os nad yw pΕ΅er un gweinydd yn ddigon i brosesu pob cais, ac nad yw'r gwneuthurwr meddalwedd yn darparu cydbwyso llwyth? Mae yna lawer o opsiynau, o brynu cydbwysedd llwyth i gyfyngu ar nifer y ceisiadau. Rhaid i'r sefyllfa benderfynu pa un sy'n gywir, gan ystyried yr amodau presennol. Yn yr erthygl hon byddwn yn dweud wrthych beth allwch chi ei wneud os yw'ch cyllideb yn gyfyngedig a bod gennych weinydd am ddim.
Fel system yr oedd angen lleihau'r llwyth ar un o'r gweinyddwyr ar ei chyfer, fe wnaethom ddewis DLP (system atal gollyngiadau gwybodaeth) gan InfoWatch. Nodwedd o'r gweithredu oedd gosod y swyddogaeth balancer ar un o'r gweinyddwyr βbrwydroβ.
Un o'r problemau y daethom ar ei draws oedd yr anallu i ddefnyddio Source NAT (SNAT). Pam roedd angen hyn a sut y cafodd y broblem ei datrys, byddwn yn disgrifio ymhellach.
Felly, i ddechrau roedd diagram rhesymegol y system bresennol yn edrych fel hyn:
Proseswyd traffig ICAP, SMTP, digwyddiadau o gyfrifiaduron defnyddwyr ar y gweinydd Monitor Traffig (TM). Ar yr un pryd, roedd gweinydd y gronfa ddata yn ymdopi'n hawdd Γ’'r llwyth ar Γ΄l prosesu digwyddiadau ar y TM, ond roedd y llwyth ar y TM ei hun yn drwm. Roedd hyn yn amlwg o ymddangosiad ciw neges ar y gweinydd Device Monitor (DM), yn ogystal ag o'r CPU a'r llwyth cof ar y TM.
Ar yr olwg gyntaf, os byddwn yn ychwanegu gweinydd TM arall i'r cynllun hwn, yna gellid newid naill ai ICAP neu DM iddo, ond penderfynasom beidio Γ’ defnyddio'r dull hwn, gan fod goddefgarwch namau wedi'i leihau.
Disgrifiad o'r datrysiad
Yn y broses o chwilio am ateb addas, fe wnaethom setlo ar feddalwedd a ddosbarthwyd yn rhydd
Dylaiβr hyn yr oeddem am ei gyflawni (lleihauβr llwyth ar TM a chynnal y lefel bresennol o oddefgarwch namau) fod wedi gweithio yn unol Γ’βr cynllun canlynol:
Wrth wirio'r swyddogaeth, daeth i'r amlwg nad yw'r cynulliad RedHat arferol sydd wedi'i osod ar y gweinyddwyr yn cefnogi SNAT. Yn ein hachos ni, roeddem yn bwriadu defnyddio SNAT i sicrhau bod pecynnau sy'n dod i mewn ac ymatebion iddynt yn cael eu hanfon o'r un cyfeiriad IP, fel arall byddem yn cael y llun canlynol:
Mae hyn yn annerbyniol. Er enghraifft, bydd gweinydd dirprwy, ar Γ΄l anfon pecynnau i gyfeiriad IP Rhithwir (VIP), yn disgwyl ymateb gan VIP, ond yn yr achos hwn bydd yn dod o IP2 ar gyfer sesiynau a anfonir i wrth gefn. Cafwyd hyd i ateb: roedd angen creu tabl llwybro arall ar y copi wrth gefn a chysylltu dau weinydd TM Γ’ rhwydwaith ar wahΓ’n, fel y dangosir isod:
Gosodiadau
Byddwn yn gweithredu cynllun o ddau weinydd gyda gwasanaethau ICAP, SMTP, TCP 9100 a chydbwysedd llwyth wedi'i osod ar un ohonynt.
Mae gennym ddau weinydd RHEL6, y mae'r storfeydd safonol a rhai pecynnau wedi'u tynnu ohonynt.
Gwasanaethau y mae angen inni eu cydbwyso:
β’ ICAP β tcp 1344;
β’ SMTP β tcp 25.
Gwasanaeth trawsyrru traffig o DM - tcp 9100.
Yn gyntaf, mae angen inni gynllunio'r rhwydwaith.
Cyfeiriad IP rhithwir (VIP):
β’ IP: 10.20.20.105.
Gweinydd TM6_1:
β’ IP allanol: 10.20.20.101;
β’ IP mewnol: 192.168.1.101.
Gweinydd TM6_2:
β’ IP allanol: 10.20.20.102;
β’ IP mewnol: 192.168.1.102.
Yna rydym yn galluogi anfon IP ymlaen ar ddau weinydd TM. Disgrifir sut i wneud hyn ar RedHat
Rydym yn penderfynu pa un o'r gweinyddwyr fydd gennym yw'r prif un a pha un fydd yr un wrth gefn. Gadewch i'r meistr fod yn TM6_1, bydd copi wrth gefn yn TM6_2.
Wrth wneud copi wrth gefn rydym yn creu tabl llwybro cydbwysedd newydd a rheolau llwybro:
[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 balancer
Mae'r gorchmynion uchod yn gweithio nes bod y system wedi'i ailgychwyn. Er mwyn sicrhau bod y llwybrau'n cael eu cadw ar Γ΄l ailgychwyn, gallwch chi eu nodi /etc/rc.d/rc.local, ond yn well trwy'r ffeil gosodiadau /etc/sysconfig/network-scripts/route-eth1 (sylwer: defnyddir cystrawen wahanol yma).
Gosod yn gadw'n fyw ar y ddau weinydd TM. Fe wnaethom ddefnyddio rpmfind.net fel y ffynhonnell ddosbarthu:
[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
Yn y gosodiadau cadw'n fyw, rydym yn aseinio un o'r gweinyddwyr yn feistr, a'r llall fel copi wrth gefn. Yna rydym yn gosod VIP a gwasanaethau ar gyfer cydbwyso llwyth. Mae'r ffeil gosodiadau fel arfer wedi'i lleoli yma: /etc/keepalived/keepalived.conf.
Gosodiadau ar gyfer Gweinydd TM1
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
}
}
}
Gosodiadau ar gyfer Gweinydd TM2
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
}
}
Rydyn ni'n gosod LVS ar y meistr, a fydd yn cydbwyso'r traffig. Nid yw'n gwneud unrhyw synnwyr gosod cydbwysedd ar gyfer yr ail weinydd, gan mai dim ond dau weinydd sydd gennym yn y ffurfweddiad.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpm
Bydd y balancer yn cael ei reoli gan keepvived, yr ydym eisoes wedi'i ffurfweddu.
I gwblhau'r llun, gadewch i ni ychwanegu cadw'n fyw i gychwyn yn awtomatig ar y ddau weinydd:
[root@tm6_1 ~]#chkconfig keepalived on
Casgliad
Gwirio'r canlyniadau
Gadewch i ni redeg yn gadw'n fyw ar y ddau weinydd:
service keepalived start
Gwirio argaeledd cyfeiriad rhithwir VRRP
Gadewch i ni sicrhau bod y VIP ar feistr:
Ac nid oes VIP wrth gefn:
Gan ddefnyddio'r gorchymyn ping, byddwn yn gwirio argaeledd y VIP:
Nawr gallwch chi gau meistr a rhedeg y gorchymyn eto ping
.
Dylai'r canlyniad aros yr un fath, ac wrth gefn fe welwn VIP:
Gwirio cydbwyso gwasanaeth
Gadewch i ni gymryd SMTP er enghraifft. Gadewch i ni lansio dau gysylltiad i 10.20.20.105 ar yr un pryd:
telnet 10.20.20.105 25
Ar feistr dylem weld bod y ddau gysylltiad yn weithredol ac wedi'u cysylltu Γ’ gweinyddwyr gwahanol:
[root@tm6_1 ~]#watch ipvsadm βLn
Felly, rydym wedi gweithredu cyfluniad sy'n gallu goddef diffygion o wasanaethau TM trwy osod cydbwysedd ar un o'r gweinyddwyr TM. Ar gyfer ein system, roedd hyn yn lleihau'r llwyth ar TM gan hanner, a oedd yn ei gwneud hi'n bosibl datrys y broblem o ddiffyg graddio llorweddol gan ddefnyddio'r system.
Yn y rhan fwyaf o achosion, gweithredir yr ateb hwn yn gyflym a heb gostau ychwanegol, ond weithiau mae yna nifer o gyfyngiadau ac anawsterau o ran cyfluniad, er enghraifft, wrth gydbwyso traffig y CDU.
Ffynhonnell: hab.com