Ano ang gagawin kung ang kapangyarihan ng isang server ay hindi sapat upang iproseso ang lahat ng mga kahilingan, at ang tagagawa ng software ay hindi nagbibigay ng pagbalanse ng pagkarga? Maraming opsyon, mula sa pagbili ng load balancer hanggang sa paglilimita sa bilang ng mga kahilingan. Alin ang tama ay dapat matukoy ng sitwasyon, isinasaalang-alang ang mga umiiral na kondisyon. Sa artikulong ito sasabihin namin sa iyo kung ano ang maaari mong gawin kung limitado ang iyong badyet at mayroon kang libreng server.
Bilang isang sistema kung saan kinakailangan upang bawasan ang pagkarga sa isa sa mga server, pinili namin ang DLP (sistema ng pag-iwas sa pagtagas ng impormasyon) mula sa InfoWatch. Ang isang tampok ng pagpapatupad ay ang paglalagay ng function ng balancer sa isa sa mga "combat" server.
Одна из проблем, с которой мы столкнулись, – невозможность использования Source NAT (SNAT). Для чего это было нужно и как проблема была решена, мы расскажем далее.
Kaya, sa una ang lohikal na diagram ng umiiral na sistema ay ganito ang hitsura:
Ang trapiko ng ICAP, SMTP, mga kaganapan mula sa mga computer ng gumagamit ay naproseso sa server ng Traffic Monitor (TM). Kasabay nito, ang database server ay madaling nakayanan ang pag-load pagkatapos ng pagproseso ng mga kaganapan sa TM, ngunit ang pagkarga sa TM mismo ay mabigat. Ito ay maliwanag mula sa paglitaw ng isang queue ng mensahe sa server ng Device Monitor (DM), gayundin mula sa CPU at memory load sa TM.
Sa unang tingin, kung magdaragdag kami ng isa pang TM server sa scheme na ito, maaaring ilipat dito ang alinman sa ICAP o DM, ngunit nagpasya kaming huwag gamitin ang pamamaraang ito, dahil nabawasan ang fault tolerance.
Paglalarawan ng solusyon
Sa proseso ng paghahanap para sa isang angkop na solusyon, kami ay nanirahan sa malayang ipinamamahaging software
Ang gusto naming makamit (bawasan ang load sa TM at panatilihin ang kasalukuyang antas ng fault tolerance) ay dapat na gumana ayon sa sumusunod na pamamaraan:
Kapag sinusuri ang pag-andar, lumabas na ang pasadyang pagpupulong ng RedHat na naka-install sa mga server ay hindi sumusuporta sa SNAT. Sa aming kaso, binalak naming gamitin ang SNAT upang matiyak na ang mga papasok na packet at mga tugon sa kanila ay ipapadala mula sa parehong IP address, kung hindi, makukuha namin ang sumusunod na larawan:
Ito ay hindi katanggap-tanggap. Halimbawa, ang isang proxy server, na nagpadala ng mga packet sa isang Virtual IP (VIP) address, ay aasahan ang isang tugon mula sa VIP, ngunit sa kasong ito manggagaling ito sa IP2 para sa mga session na ipinadala sa backup. May nakitang solusyon: kinailangan na gumawa ng isa pang routing table sa backup at ikonekta ang dalawang TM server na may hiwalay na network, tulad ng ipinapakita sa ibaba:
Mga Setting
Magpapatupad kami ng scheme ng dalawang server na may mga serbisyong ICAP, SMTP, TCP 9100 at isang load balancer na naka-install sa isa sa mga ito.
Mayroon kaming dalawang RHEL6 server, kung saan inalis ang mga karaniwang repositoryo at ilang pakete.
Mga serbisyo na kailangan nating balansehin:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Serbisyo sa paghahatid ng trapiko mula sa DM – tcp 9100.
Una, kailangan nating planuhin ang network.
Virtual IP address (VIP):
• IP: 10.20.20.105.
Server TM6_1:
• Panlabas na IP: 10.20.20.101;
• Panloob na IP: 192.168.1.101.
Server TM6_2:
• Panlabas na IP: 10.20.20.102;
• Panloob na IP: 192.168.1.102.
Pagkatapos ay pinagana namin ang pagpapasa ng IP sa dalawang TM server. Paano ito gagawin ay inilarawan sa RedHat
Kami ang magpapasya kung alin sa mga server ang mayroon kami ang pangunahing isa at kung alin ang magiging backup. Hayaan ang master ay TM6_1, backup ay TM6_2.
Sa backup, lumikha kami ng bagong balancer routing table at mga panuntunan sa pagruruta:
[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
Gumagana ang mga utos sa itaas hanggang sa ma-reboot ang system. Upang matiyak na ang mga ruta ay napanatili pagkatapos ng pag-reboot, maaari mong ipasok ang mga ito /etc/rc.d/rc.local, но лучше через файл настроек /etc/sysconfig/network-scripts/route-eth1 (tandaan: ibang syntax ang ginagamit dito).
I-install ang keepalived sa parehong TM server. Ginamit namin ang rpmfind.net bilang pinagmumulan ng pamamahagi:
[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
В настройках keepalived назначаем один из серверов master, другой – backup. Затем задаем VIP и сервисы для балансировки нагрузки. Файл настроек обычно расположен тут: /etc/keepalived/keepalived.conf.
Настройки для сервера 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
}
}
}
Настройки для сервера 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
}
}
Nag-install kami ng LVS sa master, na magbabalanse sa trapiko. Walang saysay na mag-install ng balancer para sa pangalawang server, dahil dalawa lang ang server namin sa configuration.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpm
Ang balancer ay pamamahalaan ng keepalived, na na-configure na namin.
Upang makumpleto ang larawan, idagdag natin ang keepalived sa autostart sa parehong mga server:
[root@tm6_1 ~]#chkconfig keepalived on
Konklusyon
Sinusuri ang mga resulta
Запустим keepalived на обоих серверах:
service keepalived start
Проверка доступности виртуального адреса VRRP
Siguraduhin natin na ang VIP ay nasa master:
At walang VIP sa backup:
Gamit ang ping command, susuriin namin ang pagkakaroon ng VIP:
Ngayon ay maaari mong isara ang master at patakbuhin muli ang command ping
.
Ang resulta ay dapat manatiling pareho, at sa backup makikita natin ang VIP:
Sinusuri ang pagbabalanse ng serbisyo
Kunin natin ang SMTP bilang halimbawa. Maglunsad tayo ng dalawang koneksyon sa 10.20.20.105 nang sabay-sabay:
telnet 10.20.20.105 25
Sa master dapat nating makita na ang parehong mga koneksyon ay aktibo at konektado sa iba't ibang mga server:
[root@tm6_1 ~]#watch ipvsadm –Ln
Kaya, nagpatupad kami ng fault-tolerant na configuration ng mga serbisyo ng TM sa pamamagitan ng pag-install ng balancer sa isa sa mga TM server. Para sa aming system, binawasan nito ng kalahati ang load sa TM, na naging posible upang malutas ang problema ng kakulangan ng horizontal scaling gamit ang system.
Sa karamihan ng mga kaso, ang solusyon na ito ay ipinatupad nang mabilis at walang karagdagang mga gastos, ngunit kung minsan ay may ilang mga limitasyon at kahirapan sa pagsasaayos, halimbawa, kapag binabalanse ang trapiko ng UDP.
Pinagmulan: www.habr.com