Бір сервердің қуаты барлық сұрауларды өңдеуге жеткіліксіз болса және бағдарламалық жасақтаманы өндіруші жүктемені теңестіруді қамтамасыз етпесе не істеу керек? Жүктеме балансын сатып алудан сұраулар санын шектеуге дейін көптеген нұсқалар бар. Қайсысы дұрыс, қалыптасқан жағдайларды ескере отырып, жағдайды анықтау керек. Бұл мақалада бюджетіңіз шектеулі болса және сізде тегін сервер болса, не істеуге болатынын айтамыз.
Серверлердің біріне жүктемені азайту қажет болатын жүйе ретінде біз InfoWatch-тен DLP (ақпараттың ағып кетуін болдырмау жүйесі) таңдадық. Іске асырудың ерекшелігі баланстық функцияны «жауынгерлік» серверлердің біріне орналастыру болды.
Біз кездестірген мәселелердің бірі Source NAT (SNAT) пайдалану мүмкін еместігі болды. Бұл не үшін қажет болды және мәселе қалай шешілді, біз әрі қарай түсіндіреміз.
Сонымен, бастапқыда қолданыстағы жүйенің логикалық диаграммасы келесідей болды:
ICAP трафигі, SMTP, пайдаланушы компьютерлерінің оқиғалары Traffic Monitor (TM) серверінде өңделді. Сонымен қатар, деректер базасының сервері ТМ оқиғаларын өңдегеннен кейін жүктемені оңай жеңді, бірақ ТМ жүктемесінің өзі ауыр болды. Бұл Device Monitor (DM) серверіндегі хабарлама кезегінің пайда болуынан, сондай-ақ CPU және ТМ-дегі жад жүктемелерінен анық болды.
Бір қарағанда, егер біз осы схемаға басқа ТМ серверін қоссақ, онда оған ICAP немесе DM ауысуы мүмкін, бірақ біз бұл әдісті қолданбауды шештік, өйткені ақауларға төзімділік төмендеді.
Шешімнің сипаттамасы
Тиісті шешімді іздеу процесінде біз еркін таратылатын бағдарламалық қамтамасыз етуді шештік бірге . Себебі keepalived істен шығу кластерін жасау мәселесін шешеді және сонымен қатар LVS балансизаторын басқара алады.
Біз қол жеткізгіміз келген нәрсе (ТМ жүктемесін азайту және ақауларға төзімділіктің ағымдағы деңгейін сақтау) келесі схемаға сәйкес жұмыс істеуі керек:
Функционалдылықты тексеру кезінде серверлерде орнатылған реттелетін RedHat жинағы SNAT-ты қолдамайтыны анықталды. Біздің жағдайда біз кіріс пакеттері мен оларға жауаптар бір IP мекенжайынан жіберілетініне көз жеткізу үшін SNAT пайдалануды жоспарладық, әйтпесе келесі суретті аламыз:
Бұл қабылданбайды. Мысалы, виртуалды IP (VIP) мекенжайына пакеттерді жіберген прокси-сервер VIP-ден жауап күтеді, бірақ бұл жағдайда сақтық көшірмеге жіберілген сеанстар үшін IP2-ден келеді. Шешім табылды: резервтік көшірмеде басқа маршруттау кестесін жасау және төменде көрсетілгендей екі ТМ серверін бөлек желімен қосу қажет болды:
Параметрлер
Біз ICAP, SMTP, TCP 9100 қызметтері бар екі сервердің схемасын және олардың біреуінде орнатылған жүктеме теңестіргішін іске асырамыз.
Бізде стандартты репозиторийлер мен кейбір пакеттер жойылған екі 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.
Содан кейін біз екі TM серверінде IP бағыттауды қосамыз. Мұны қалай істеу керектігі 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.rpmKeepalved параметрлерінде серверлердің бірін басты, екіншісін сақтық көшірме ретінде тағайындаймыз. Содан кейін біз 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 startVRRP виртуалды мекенжайының қолжетімділігін тексеру
VIP мастерде екеніне көз жеткізейік:
Ал сақтық көшірмеде VIP жоқ:
Ping пәрменін қолданып, біз VIP-тің болуын тексереміз:
Енді сіз мастерді өшіріп, пәрменді қайта іске қоса аласыз ping.
Нәтиже өзгеріссіз қалуы керек және сақтық көшірмеде біз VIP көреміз:
Қызмет көрсетудің теңгерімділігін тексеру
Мысалы, SMTP алайық. Бір уақытта 10.20.20.105 екі қосылымды іске қосайық:
telnet 10.20.20.105 25Мастерде екі қосылым да белсенді және әртүрлі серверлерге қосылғанын көруіміз керек:
[root@tm6_1 ~]#watch ipvsadm –Ln
Осылайша, біз ТМ серверлерінің біріне балансизаторды орнату арқылы ТМ қызметтерінің қатеге төзімді конфигурациясын енгіздік. Біздің жүйе үшін бұл ТМ жүктемесін екі есе азайтты, бұл жүйені пайдалана отырып, көлденең масштабтаудың болмауы мәселесін шешуге мүмкіндік берді.
Көп жағдайда бұл шешім тез және қосымша шығындарсыз жүзеге асырылады, бірақ кейде конфигурацияда бірқатар шектеулер мен қиындықтар болады, мысалы, UDP трафигін теңестіру кезінде.
Ақпарат көзі: www.habr.com