Ko darīt, ja viena servera jauda nav pietiekama, lai apstrādātu visus pieprasījumus, un programmatūras ražotājs nenodrošina slodzes līdzsvarošanu? Ir daudz iespēju, sākot no slodzes balansētāja iegādes līdz pieprasījumu skaita ierobežošanai. Kurš no tiem ir pareizs, ir jānosaka situācijai, ņemot vērā esošos apstākļus. Šajā rakstā mēs jums pateiksim, ko jūs varat darīt, ja jūsu budžets ir ierobežots un jums ir bezmaksas serveris.
Kā sistēmu, kurai bija nepieciešams samazināt slodzi uz vienu no serveriem, mēs izvēlējāmies DLP (informācijas noplūdes novēršanas sistēmu) no InfoWatch. Ieviešanas iezīme bija balansētāja funkcijas izvietošana vienā no “kaujas” serveriem.
Viena no problēmām, ar ko saskārāmies, bija nespēja izmantot Source NAT (SNAT). Kāpēc tas bija vajadzīgs un kā problēma tika atrisināta, mēs aprakstīsim tālāk.
Tātad sākotnēji esošās sistēmas loģiskā diagramma izskatījās šādi:
ICAP trafiks, SMTP, notikumi no lietotāju datoriem tika apstrādāti Traffic Monitor (TM) serverī. Tajā pašā laikā datu bāzes serveris viegli tika galā ar slodzi pēc notikumu apstrādes TM, taču pašas TM slodze bija liela. Tas bija redzams no ziņojumu rindas parādīšanās Device Monitor (DM) serverī, kā arī no CPU un atmiņas slodzes TM.
No pirmā acu uzmetiena, ja šai shēmai pievienojam vēl vienu TM serveri, tad uz to varētu pārslēgties vai nu ICAP, vai DM, taču mēs nolēmām šo metodi neizmantot, jo tika samazināta kļūdu tolerance.
Risinājuma apraksts
Piemērota risinājuma meklēšanas procesā mēs apmetāmies uz brīvi izplatītu programmatūru kopā ar . Jo keepalived atrisina kļūmjpārlēces klastera izveidošanas problēmu un var arī pārvaldīt LVS balansētāju.
Tam, ko mēs vēlējāmies sasniegt (samazināt TM slodzi un saglabāt pašreizējo kļūdu tolerances līmeni), vajadzēja darboties saskaņā ar šādu shēmu:
Pārbaudot funkcionalitāti, izrādījās, ka serveros instalētais pielāgotais RedHat komplekts neatbalsta SNAT. Mūsu gadījumā mēs plānojām izmantot SNAT, lai nodrošinātu, ka ienākošās paketes un atbildes uz tām tiek nosūtītas no vienas IP adreses, pretējā gadījumā mēs iegūtu šādu attēlu:
Tas ir nepieņemami. Piemēram, starpniekserveris, nosūtījis paketes uz virtuālo IP (VIP) adresi, gaidīs atbildi no VIP, bet šajā gadījumā tā nāks no IP2 par sesijām, kas tiek nosūtītas uz rezerves kopiju. Tika atrasts risinājums: rezerves kopijā bija nepieciešams izveidot citu maršrutēšanas tabulu un savienot divus TM serverus ar atsevišķu tīklu, kā parādīts zemāk:
iestatījumi
Ieviesīsim divu serveru shēmu ar ICAP, SMTP, TCP 9100 pakalpojumiem un vienā no tiem uzstādītu slodzes balansētāju.
Mums ir divi RHEL6 serveri, no kuriem ir izņemti standarta krātuves un dažas pakotnes.
Pakalpojumi, kas mums jāsabalansē:
• ICAP – tcp 1344;
• SMTP — tcp 25.
Satiksmes pārraides pakalpojums no DM – tcp 9100.
Pirmkārt, mums ir jāplāno tīkls.
Virtuālā IP adrese (VIP):
• IP: 10.20.20.105.
Serveris TM6_1:
• Ārējais IP: 10.20.20.101;
• Iekšējā IP: 192.168.1.101.
Serveris TM6_2:
• Ārējais IP: 10.20.20.102;
• Iekšējā IP: 192.168.1.102.
Pēc tam mēs iespējojam IP pārsūtīšanu divos TM serveros. Kā to izdarīt, ir aprakstīts vietnē RedHat .
Mēs izlemjam, kurš no mums būs galvenais un kurš būs rezerves serveris. Lai galvenais ir TM6_1, rezerves ir TM6_2.
Dublējot mēs izveidojam jaunu balansētāja maršrutēšanas tabulu un maršrutēšanas noteikumus:
[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 balancerIepriekš minētās komandas darbojas, līdz sistēma tiek restartēta. Lai nodrošinātu, ka maršruti tiek saglabāti pēc atsāknēšanas, varat tos ievadīt /etc/rc.d/rc.local, bet labāk, izmantojot iestatījumu failu /etc/sysconfig/network-scripts/route-eth1 (piezīme: šeit tiek izmantota cita sintakse).
Instalējiet Keepalived abos TM serveros. Mēs izmantojām rpmfind.net kā izplatīšanas avotu:
[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.rpmUzturēšanas iestatījumos mēs piešķiram vienu no serveriem kā galveno, otru kā rezerves. Pēc tam mēs iestatām VIP un pakalpojumus slodzes līdzsvarošanai. Iestatījumu fails parasti atrodas šeit: /etc/keepalived/keepalived.conf.
TM1 servera iestatījumi
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 servera iestatījumi
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
}
}Uzstādām uz master LVS, kas sabalansēs satiksmi. Nav jēgas instalēt balansētāju otrajam serverim, jo mums konfigurācijā ir tikai divi serveri.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmBalansētāju pārvaldīs Keepalived, kuru mēs jau esam konfigurējuši.
Lai pabeigtu attēlu, pievienosim Keepalived automātiskai palaišanai abos serveros:
[root@tm6_1 ~]#chkconfig keepalived onSecinājums
Rezultātu pārbaude
Sāksim darboties abos serveros:
service keepalived startVRRP virtuālās adreses pieejamības pārbaude
Pārliecināsimies, ka VIP ir galvenais:
Un dublējumkopijā nav VIP:
Izmantojot ping komandu, mēs pārbaudīsim VIP pieejamību:
Tagad varat izslēgt galveno un palaist komandu vēlreiz ping.
Rezultātam vajadzētu palikt nemainīgam, un dublējumkopijā mēs redzēsim VIP:
Servisa balansēšanas pārbaude
Ņemsim, piemēram, SMTP. Sāksim vienlaikus divus savienojumus ar 10.20.20.105:
telnet 10.20.20.105 25Pamatprogrammā mums vajadzētu redzēt, ka abi savienojumi ir aktīvi un savienoti ar dažādiem serveriem:
[root@tm6_1 ~]#watch ipvsadm –Ln 
Tādējādi esam ieviesuši kļūdu izturīgu TM pakalpojumu konfigurāciju, vienā no TM serveriem uzstādot balansētāju. Mūsu sistēmai tas uz pusi samazināja TM slodzi, kas ļāva atrisināt horizontālās mērogošanas trūkuma problēmu, izmantojot sistēmu.
Vairumā gadījumu šis risinājums tiek ieviests ātri un bez papildu izmaksām, taču dažkārt rodas vairāki ierobežojumi un sarežģījumi konfigurācijā, piemēram, balansējot UDP trafiku.
Avots: www.habr.com
