Какво да направите, ако мощността на един сървър не е достатъчна за обработка на всички заявки и производителят на софтуера не осигурява балансиране на натоварването? Има много опции, от закупуване на балансьор на натоварването до ограничаване на броя на заявките. Кой е правилният трябва да се определи от ситуацията, като се вземат предвид съществуващите условия. В тази статия ще ви кажем какво можете да направите, ако бюджетът ви е ограничен и имате безплатен сървър.
Като система, за която беше необходимо да се намали натоварването на един от сървърите, избрахме DLP (система за предотвратяване на изтичане на информация) от InfoWatch. Характеристика на внедряването беше поставянето на функцията за балансиране на един от „бойните“ сървъри.
Един от проблемите, с които се сблъскахме, беше невъзможността да използваме Source NAT (SNAT). Защо е необходимо това и как проблемът е решен, ще опишем по-нататък.
И така, първоначално логическата диаграма на съществуващата система изглеждаше така:
ICAP трафик, SMTP, събития от потребителски компютри бяха обработени на сървъра на Traffic Monitor (TM). В същото време сървърът на базата данни лесно се справи с натоварването след обработка на събития в TM, но натоварването на самия TM беше голямо. Това беше очевидно от появата на опашка от съобщения на сървъра за монитор на устройства (DM), както и от натоварването на процесора и паметта на TM.
На пръв поглед, ако добавим друг TM сървър към тази схема, тогава или ICAP, или DM могат да бъдат превключени към него, но решихме да не използваме този метод, тъй като толерантността към грешки беше намалена.
Описание на решението
В процеса на търсене на подходящо решение се спряхме на свободно разпространяван софтуер заедно с . Тъй като keepalived решава проблема със създаването на отказоустойчив клъстер и може също да управлява LVS балансира.
Това, което искахме да постигнем (намаляване на натоварването на TM и поддържане на текущото ниво на толерантност към грешки), трябваше да работи по следната схема:
При проверка на функционалността се оказа, че персонализираният монтаж на RedHat, инсталиран на сървърите, не поддържа SNAT. В нашия случай планирахме да използваме SNAT, за да гарантираме, че входящите пакети и отговорите към тях се изпращат от същия IP адрес, в противен случай ще получим следната картина:
Това е неприемливо. Например, прокси сървър, който е изпратил пакети до виртуален IP (VIP) адрес, ще очаква отговор от VIP, но в този случай той ще дойде от IP2 за сесии, изпратени за архивиране. Беше намерено решение: беше необходимо да се създаде друга таблица за маршрутизиране на резервното копие и да се свържат два TM сървъра с отделна мрежа, както е показано по-долу:
Настройки
Ще реализираме схема от два сървъра с инсталирани на единия ICAP, SMTP, TCP 9100 услуги и load balancer.
Имаме два RHEL6 сървъра, от които са премахнати стандартните хранилища и някои пакети.
Услуги, които трябва да балансираме:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Услуга за предаване на трафик от DM – tcp 9100.
Първо, трябва да планираме мрежата.
Виртуален IP адрес (VIP):
• 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 присвояваме един от сървърите като главен, а другия като резервен. След това задаваме 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
}
}Инсталираме 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 виртуален адрес
Нека се уверим, че VIP е на master:
И няма VIP при архивиране:
С помощта на командата ping ще проверим наличността на VIP:
Сега можете да изключите master и да изпълните командата отново ping.
Резултатът трябва да остане същият и при архивиране ще видим VIP:
Проверка на балансирането на услугата
Да вземем например SMTP. Нека стартираме две връзки към 10.20.20.105 едновременно:
telnet 10.20.20.105 25На master трябва да видим, че и двете връзки са активни и свързани към различни сървъри:
[root@tm6_1 ~]#watch ipvsadm –Ln
По този начин сме внедрили устойчива на грешки конфигурация на TM услуги чрез инсталиране на балансьор на един от TM сървърите. За нашата система това намали натоварването на TM наполовина, което направи възможно решаването на проблема с липсата на хоризонтално мащабиране с помощта на системата.
В повечето случаи това решение се внедрява бързо и без допълнителни разходи, но понякога има редица ограничения и трудности при конфигурацията, например при балансиране на UDP трафик.
Източник: www.habr.com