Што да направите ако моќта на еден сервер не е доволна за обработка на сите барања, а производителот на софтверот не обезбедува балансирање на оптоварување? Има многу опции, од купување балансирач до ограничување на бројот на барања. Кој од нив е точен мора да се утврди од ситуацијата, земајќи ги предвид постоечките услови. Во оваа статија ќе ви кажеме што можете да направите ако вашиот буџет е ограничен и имате бесплатен сервер.
Како систем за кој беше неопходно да се намали оптоварувањето на еден од серверите, го избравме DLP (систем за спречување на истекување на информации) од InfoWatch. Карактеристика на имплементацијата беше поставувањето на функцијата за балансирање на еден од „борбените“ сервери.
Еден од проблемите на кои наидовме беше неможноста да се користи Source NAT (SNAT). Зошто беше потребно ова и како проблемот беше решен, ќе опишеме понатаму.
Значи, првично логичкиот дијаграм на постојниот систем изгледаше вака:
ICAP сообраќај, SMTP, настани од кориснички компјутери беа обработени на серверот Traffic Monitor (TM). Во исто време, серверот на базата на податоци лесно се справи со оптоварувањето по обработката на настаните на ТМ, но оптоварувањето на самиот ТМ беше тежок. Ова беше очигледно од појавата на редица пораки на серверот за монитор на уредот (DM), како и од оптоварувањето на процесорот и меморијата на TM.
На прв поглед, ако додадеме друг TM сервер на оваа шема, тогаш или ICAP или DM може да се префрлат на него, но решивме да не го користиме овој метод, бидејќи толеранцијата на грешки беше намалена.
Опис на решението
Во процесот на барање соодветно решение, се населивме на слободно дистрибуиран софтвер заедно со . Бидејќи keepalived го решава проблемот со креирање кластер за отфрлање и може да управува и со балансерот LVS.
Она што сакавме да го постигнеме (намалување на оптоварувањето на ТМ и одржување на сегашното ниво на толеранција на грешки) требаше да функционира според следнава шема:
При проверка на функционалноста, се покажа дека прилагодениот склоп на RedHat инсталиран на серверите не поддржува SNAT. Во нашиот случај, планиравме да користиме SNAT за да се осигураме дека дојдовните пакети и одговорите на нив се испраќаат од истата IP адреса, во спротивно ќе ја добиеме следната слика:
Ова е неприфатливо. На пример, прокси-сервер, кој испратил пакети на виртуелна IP адреса (ВИП), ќе очекува одговор од ВИП, но во овој случај тој ќе дојде од IP2 за сесиите испратени на резервна копија. Беше најдено решение: беше неопходно да се создаде друга рутирачка табела на резервната копија и да се поврзат два ТМ сервери со посебна мрежа, како што е прикажано подолу:
Подесувања
Ќе имплементираме шема од два сервери со ICAP, SMTP, TCP 9100 услуги и load balancer инсталиран на еден од нив.
Имаме два сервери RHEL6, од кои се отстранети стандардните складишта и некои пакети.
Услуги кои ни требаат да ги балансираме:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Сервис за пренос на сообраќај од DM – tcp 9100.
Прво, треба да ја планираме мрежата.
Виртуелна IP адреса (ВИП):
• IP: 10.20.20.105.
Сервер TM6_1:
• Надворешна IP адреса: 10.20.20.101;
• Внатрешна IP адреса: 192.168.1.101.
Сервер TM6_2:
• Надворешна IP адреса: 10.20.20.102;
• Внатрешна IP адреса: 192.168.1.102.
Потоа овозможуваме проследување на IP на два TM сервери. Како да го направите ова е опишано на RedHat .
Ние одлучуваме кој од серверите што ќе ги имаме е главен, а кој ќе биде резервен. Нека господар е TM6_1, резервна копија е TM6_2.
На резервна копија, создаваме нова табела за насочување на балансерот и правила за рутирање:
[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Горенаведените команди работат додека системот не се рестартира. За да се осигурате дека маршрутите се зачувани по рестартирање, можете да ги внесете /etc/rc.d/rc.local, но подобро преку датотеката за поставки /etc/sysconfig/network-scripts/route-eth1 (забелешка: овде се користи различна синтакса).
Инсталирајте го keepalived на двата TM сервери. Го користевме rpmfind.net како извор на дистрибуција:
[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, еден од серверите го доделуваме како главен, а другиот како резервна копија. Потоа поставуваме ВИП и услуги за балансирање на товарот. Датотеката за поставки обично се наоѓа овде: /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
}
}Ние инсталираме LVS на мастерот, кој ќе го балансира сообраќајот. Нема смисла да се инсталира балансер за вториот сервер, бидејќи имаме само два сервери во конфигурацијата.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmБалансерот ќе биде управуван од keepalived, кој веќе го конфигуриравме.
За да ја комплетираме сликата, ајде да додадеме keepalived за автоматско стартување на двата сервери:
[root@tm6_1 ~]#chkconfig keepalived onЗаклучок
Проверка на резултатите
Ајде да работиме keepalived на двата сервери:
service keepalived startПроверка на достапноста на виртуелна адреса VRRP
Ајде да се увериме дека ВИП-то е на мастер:
И нема ВИП на резервна копија:
Користејќи ја командата пинг, ќе ја провериме достапноста на ВИП:
Сега можете да го исклучите master и повторно да ја извршите командата ping.
Резултатот треба да остане ист, а на резервна копија ќе видиме ВИП:
Проверка на балансирање на услугата
Да го земеме SMTP на пример. Ајде да стартуваме две врски на 10.20.20.105 истовремено:
telnet 10.20.20.105 25На мастер треба да видиме дека двете конекции се активни и поврзани со различни сервери:
[root@tm6_1 ~]#watch ipvsadm –Ln 
Така, имплементиравме конфигурација на TM услуги толерантна за грешки со инсталирање на балансер на еден од серверите на TM. За нашиот систем, ова го намали оптоварувањето на ТМ за половина, што овозможи да се реши проблемот со недостаток на хоризонтално скалирање со користење на системот.
Во повеќето случаи, ова решение се спроведува брзо и без дополнителни трошоци, но понекогаш има голем број ограничувања и тешкотии во конфигурацијата, на пример, при балансирање на сообраќајот на UDP.
Извор: www.habr.com
