Agar bitta serverning kuchi barcha so'rovlarni qayta ishlash uchun etarli bo'lmasa va dasturiy ta'minot ishlab chiqaruvchisi yuk balansini ta'minlamasa nima qilish kerak? Yuk balanslagichni sotib olishdan tortib so'rovlar sonini cheklashgacha ko'p variantlar mavjud. Qaysi biri to'g'ri, mavjud sharoitlarni hisobga olgan holda vaziyatga qarab aniqlanishi kerak. Agar sizning byudjetingiz cheklangan bo'lsa va bepul serveringiz bo'lsa, nima qilishingiz mumkinligini ushbu maqolada aytib beramiz.
Serverlardan biriga yukni kamaytirish kerak bo'lgan tizim sifatida biz InfoWatch-dan DLP (axborot oqishini oldini olish tizimi) ni tanladik. Amalga oshirishning o'ziga xos xususiyati balanslash funktsiyasini "jangovar" serverlardan biriga joylashtirish edi.
Biz duch kelgan muammolardan biri bu Source NAT (SNAT) dan foydalana olmaslik edi. Nima uchun bu kerak edi va muammo qanday hal qilindi, biz batafsilroq tasvirlab beramiz.
Shunday qilib, dastlab mavjud tizimning mantiqiy diagrammasi quyidagicha ko'rinadi:
ICAP trafigi, SMTP, foydalanuvchi kompyuterlari hodisalari Traffic Monitor (TM) serverida qayta ishlandi. Shu bilan birga, ma'lumotlar bazasi serveri TMdagi voqealarni qayta ishlagandan so'ng yukni osonlikcha engib chiqdi, ammo TM ning o'zida yuk og'ir edi. Bu Device Monitor (DM) serverida xabarlar navbatining paydo bo'lishidan, shuningdek, TM dagi protsessor va xotira yukidan yaqqol ko'rindi.
Bir qarashda, agar biz ushbu sxemaga boshqa TM-serverni qo'shsak, u holda ICAP yoki DM-ni unga o'tkazish mumkin edi, ammo biz bu usuldan foydalanmaslikka qaror qildik, chunki nosozlikka chidamlilik pasaygan.
Yechim tavsifi
Tegishli echimni izlash jarayonida biz erkin tarqatilgan dasturiy ta'minotga qaror qildik bilan birga . Chunki keepalived muvaffaqiyatsiz klaster yaratish muammosini hal qiladi va LVS balanslagichini ham boshqarishi mumkin.
Biz erishmoqchi bo'lgan narsa (TM ga yukni kamaytirish va nosozliklarga chidamlilik darajasini saqlab qolish) quyidagi sxema bo'yicha ishlashi kerak edi:
Funktsionallikni tekshirishda serverlarda o'rnatilgan maxsus RedHat yig'ilishi SNAT-ni qo'llab-quvvatlamasligi ma'lum bo'ldi. Bizning holatda, biz kiruvchi paketlar va ularga javoblar bir xil IP manzildan yuborilishini ta'minlash uchun SNAT-dan foydalanishni rejalashtirgan edik, aks holda biz quyidagi rasmni olamiz:
Bu qabul qilinishi mumkin emas. Masalan, virtual IP (VIP) manziliga paketlarni yuborgan proksi-server VIP-dan javob kutadi, ammo bu holda u IP2-dan zahiraga yuborilgan seanslar uchun keladi. Yechim topildi: zaxirada boshqa marshrutlash jadvalini yaratish va quyida ko'rsatilganidek, ikkita TM serverini alohida tarmoq bilan ulash kerak edi:
Sozlamalar
Biz ICAP, SMTP, TCP 9100 xizmatlariga ega ikkita server sxemasini va ulardan birida o'rnatilgan yuk balansini amalga oshiramiz.
Bizda ikkita RHEL6 serveri bor, ulardan standart omborlar va ba'zi paketlar olib tashlangan.
Biz muvozanatlashimiz kerak bo'lgan xizmatlar:
β’ ICAP β tcp 1344;
β’ SMTP β tcp 25.
DM - tcp 9100 dan trafikni uzatish xizmati.
Birinchidan, biz tarmoqni rejalashtirishimiz kerak.
Virtual IP manzil (VIP):
β’ IP: 10.20.20.105.
Server TM6_1:
β’ Tashqi IP: 10.20.20.101;
β’ Ichki IP: 192.168.1.101.
Server TM6_2:
β’ Tashqi IP: 10.20.20.102;
β’ Ichki IP: 192.168.1.102.
Keyin ikkita TM serverida IP-ni yo'naltirishni yoqamiz. Buni qanday qilish RedHat-da tasvirlangan .
Biz serverlardan qaysi biri asosiy va qaysi biri zaxira bo'lishini hal qilamiz. Master TM6_1, zaxira TM6_2 boβlsin.
Zaxirada biz yangi balanslashtiruvchi marshrutlash jadvalini va marshrutlash qoidalarini yaratamiz:
[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 balancerYuqoridagi buyruqlar tizim qayta ishga tushirilgunga qadar ishlaydi. Qayta ishga tushirilgandan so'ng marshrutlar saqlanib qolishiga ishonch hosil qilish uchun ularni kiritishingiz mumkin /etc/rc.d/rc.local, lekin sozlamalar fayli orqali yaxshiroq /etc/sysconfig/network-scripts/route-eth1 (eslatma: bu erda turli sintaksis qo'llaniladi).
Keepalived-ni ikkala TM serveriga o'rnating. Biz tarqatish manbai sifatida rpmfind.net dan foydalandik:
[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.rpmSaqlash sozlamalarida biz serverlardan birini master, ikkinchisini zaxira sifatida tayinlaymiz. Keyin yuklarni muvozanatlash uchun VIP va xizmatlarni o'rnatamiz. Sozlamalar fayli odatda bu erda joylashgan: /etc/keepalived/keepalived.conf.
TM1 Server sozlamalari
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 Server sozlamalari
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
}
}Biz magistralga LVSni o'rnatamiz, bu esa trafikni muvozanatlashtiradi. Ikkinchi server uchun balanserni o'rnatishning ma'nosi yo'q, chunki bizda konfiguratsiyada faqat ikkita server mavjud.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmBalanslashtiruvchi biz allaqachon sozlagan keepalived tomonidan boshqariladi.
Rasmni yakunlash uchun ikkala serverda avtomatik ishga tushirishga keepalived qo'shamiz:
[root@tm6_1 ~]#chkconfig keepalived onxulosa
Natijalarni tekshirish
Keling, ikkala serverda keepalived ishga tushamiz:
service keepalived startVRRP virtual manzili mavjudligini tekshirish
Keling, VIP masterda ekanligiga ishonch hosil qilaylik:
Va zaxirada VIP yo'q:
Ping buyrug'idan foydalanib, biz VIP mavjudligini tekshiramiz:
Endi siz masterni o'chirib, buyruqni qayta ishga tushirishingiz mumkin ping.
Natija bir xil bo'lishi kerak va zaxirada biz VIP-ni ko'ramiz:
Xizmat balansini tekshirish
Masalan, SMTP ni olaylik. 10.20.20.105 ga bir vaqtning o'zida ikkita ulanishni ishga tushiramiz:
telnet 10.20.20.105 25Master-da ikkala ulanish ham faol va turli serverlarga ulanganligini ko'rishimiz kerak:
[root@tm6_1 ~]#watch ipvsadm βLn
Shunday qilib, biz TM serverlaridan birida muvozanatlashtiruvchini o'rnatish orqali TM xizmatlarining xatoga chidamli konfiguratsiyasini amalga oshirdik. Bizning tizimimiz uchun bu TM ga yukni ikki baravar kamaytirdi, bu tizim yordamida gorizontal o'lchov etishmasligi muammosini hal qilishga imkon berdi.
Ko'pgina hollarda, bu yechim tez va qo'shimcha xarajatlarsiz amalga oshiriladi, lekin ba'zida konfiguratsiyada bir qator cheklovlar va qiyinchiliklar mavjud, masalan, UDP trafigini muvozanatlashda.
Manba: www.habr.com