Што рабіць, калі магутнасці аднаго сервера бракуе для апрацоўкі ўсіх запытаў, а вытворцам ПА не прадугледжана балансаванне нагрузкі? Ёсць шмат варыянтаў - ад куплі балансавальніка нагрузкі да абмежавання колькасці запытаў. Які з іх правільны, трэба глядзець па сітуацыі, прымаючы да ўвагі існуючыя ўмовы. У гэтым артыкуле мы раскажам, што можна зрабіць, калі бюджэт абмежаваны, а ў наяўнасці маецца свабодны сервер.
У якасці сістэмы, для якой неабходна было зменшыць нагрузку на адзін з сервераў, мы абралі DLP (сістэма прадухілення ўцечкі інфармацыі) ад InfoWatch. Асаблівасцю рэалізацыі стала размяшчэнне функцыі балансавальніка на адным з "баявых" сервераў.
Адна з праблем, з якой мы сутыкнуліся, - немагчымасць выкарыстання Source NAT (SNAT). Для чаго гэта было патрэбна і як праблема была вырашана, мы раскажам далей.
Такім чынам, першапачаткова лагічная схема існуючай сістэмы выглядала наступным чынам:
Трафік ICAP, SMTP, падзеі з кампутараў карыстальнікаў апрацоўваліся на сэрвэры Traffic Monitor (TM). Пры гэтым сервер базы даных лёгка спраўляўся з нагрузкай пасля апрацоўкі падзей на TM, а вось нагрузка на сам TM была вялікай. Гэта было відаць па ўзнікненні чаргі паведамленняў на серверы Device Monitor (DM), а таксама па загрузцы працэсара і памяці на TM.
На першы погляд, калі ў гэтую схему дадаць яшчэ адзін сервер TM, то на яго можна было б пераключыць альбо ICAP, альбо DM, але такі спосаб мы вырашылі не выкарыстоўваць, т. к. змяншалася адмоваўстойлівасць.
Апісанне рашэння
У працэсе пошуку прыдатнага рашэння мы спыніліся на свабодна распаўсюджваемым ПЗ сумесна з . Паколькі keepalived вырашае задачу стварэння адмоваўстойлівага кластара, а таксама можа кіраваць балансавальніка LVS.
Тое, да чаго мы хацелі прыйсці (знізіць нагрузку на TM і захаваць бягучы ўзровень адмоваўстойлівасці), павінна было працаваць па наступнай схеме:
Пры праверцы працаздольнасці высветлілася, што ўсталяваная на серверах кастамная зборка RedHat не падтрымлівае SNAT. У нашым выпадку мы планавалі выкарыстоўваць SNAT для таго, каб уваходныя пакеты і адказы на іх адпраўляліся з аднаго і таго ж IP-адрасы, інакш мы б атрымалі наступную карціну:
Гэта непрымальна. Напрыклад, проксі-сервер, даслаўшы пакеты на Virtual IP (VIP) адрас, будзе чакаць адказ з VIP, але ў дадзеным выпадку ён прыйдзе з IP2 для сесій, адпраўленых на backup. Рашэнне было знойдзена: запатрабавалася стварыць яшчэ адну табліцу маршрутызацыі на backup і злучыць два сервера TM асобнай сеткай, як паказана ніжэй:
Налады
Рэалізуем схему з двух сервераў з сэрвісамі ICAP, SMTP, TCP 9100 і ўсталяваным на адным з іх балансавальнікам нагрузкі.
Мы маем два серверы RHEL6, з якіх выдалены стандартныя рэпазітары і частка пакетаў.
Сэрвісы, якія нам неабходна балансаваць:
• ICAP - tcp 1344;
• SMTP - tcp 25.
Сэрвіс перадачы трафіку ад DM - TCP 9100.
Для пачатку нам трэба спланаваць сетку.
Віртуальны IP-адрас (VIP):
• IP: 10.20.20.105.
Сервер TM6_1:
• External IP: 10.20.20.101;
• Internal IP: 192.168.1.101.
Сервер TM6_2:
• External IP: 10.20.20.102;
• Internal IP: 192.168.1.102.
Затым уключаем IP forwarding на двух серверах TM. Як гэта зрабіць на RedHat апісана .
Вырашаем, які з сервераў у нас будзе галоўны, а які - рэзервовы. Хай master - гэта TM6_1, backup - TM6_2.
На backup ствараем новую табліцу маршрутызацыі balancer і правілы маршрутызацыі:
[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 прызначаем адзін з сервераў 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
}
}Усталеўваны на master 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:
А на backup няма VIP:
З дапамогай каманды ping праверым даступнасць VIP:
Цяпер можна выключыць master і зноў запусціць каманду ping.
Вынік павінен застацца такім жа, а на backup мы ўбачым VIP:
Праверка балансавання сэрвісаў
Возьмем, напрыклад, SMTP. Запусцім адначасова два падлучэнні да 10.20.20.105:
telnet 10.20.20.105 25На master мы павінны ўбачыць, што абодва падлучэння актыўныя і злучаныя на розныя серверы:
[root@tm6_1 ~]#watch ipvsadm –Ln
Такім чынам, мы рэалізавалі адмоваўстойлівасць канфігурацыю сэрвісаў TM c усталёўкай балансавальніка на адзін з сервераў TM. Для нашай сістэмы гэта знізіла нагрузку на TM у два разы, што дазволіла вырашыць праблему адсутнасці гарызантальнага маштабавання сродкамі сістэмы.
Дадзенае рашэнне ў большасці выпадкаў рэалізуецца хутка і без дадатковых выдаткаў, але часам існуе шэраг абмежаванняў і складанасцяў у наладзе, напрыклад пры балансаванні UDP-трафіку.
Крыніца: habr.com