Нэг серверийн хүч нь бүх хүсэлтийг боловсруулахад хүрэлцэхгүй, програм хангамж үйлдвэрлэгч ачааллыг тэнцвэржүүлэхгүй бол яах вэ? Ачаалал тэнцвэржүүлэгч худалдаж авахаас эхлээд хүсэлтийн тоог хязгаарлах хүртэл олон сонголт байдаг. Аль нь зөв болохыг одоо байгаа нөхцөл байдлыг харгалзан тухайн нөхцөл байдлаас шалтгаалан тодорхойлох ёстой. Энэ нийтлэлд бид таны төсөв хязгаарлагдмал, үнэгүй сервертэй бол юу хийж болохыг танд хэлэх болно.
Серверүүдийн аль нэгний ачааллыг бууруулах шаардлагатай системийн хувьд бид InfoWatch-аас DLP (мэдээлэл алдагдахаас урьдчилан сэргийлэх систем) -ийг сонгосон. Хэрэгжилтийн нэг онцлог нь тэнцвэржүүлэгч функцийг "байлдааны" серверүүдийн аль нэгэнд байрлуулах явдал байв.
Бидний тулгарсан бэрхшээлүүдийн нэг бол Source NAT (SNAT)-ийг ашиглах боломжгүй байсан явдал юм. Энэ нь яагаад хэрэгтэй байсан, асуудлыг хэрхэн шийдсэн талаар бид цааш нь тайлбарлах болно.
Тиймээс, эхэндээ одоо байгаа системийн логик диаграмм дараах байдалтай байв.
ICAP траффик, SMTP, хэрэглэгчийн компьютерийн үйл явдлуудыг Traffic Monitor (TM) сервер дээр боловсруулсан. Үүний зэрэгцээ мэдээллийн сангийн сервер нь TM дээрх үйл явдлуудыг боловсруулсны дараа ачааллыг амархан даван туулж байсан боловч TM дээрх ачаалал өөрөө хүнд байсан. Энэ нь Device Monitor (DM) сервер дээр мессежийн дараалал үүссэнээс, мөн TM дээрх CPU болон санах ойн ачааллаас тодорхой харагдаж байв.
Эхлээд харахад, хэрэв бид энэ схемд өөр TM сервер нэмбэл ICAP эсвэл DM-ийн аль нэгийг түүн рүү шилжүүлж болох боловч алдааны хүлцэл багассан тул бид энэ аргыг ашиглахгүй байхаар шийдсэн.
Шийдлийн тайлбар
Тохиромжтой шийдлийг хайж олох явцад бид чөлөөтэй тараагдсан програм хангамж дээр сууриллаа хамтдаа . Учир нь keepalived нь бүтэлгүйтлийн кластер үүсгэх асуудлыг шийдэж, LVS тэнцвэржүүлэгчийг удирдах боломжтой.
Бидний хүрэхийг хүссэн зүйл (TM-ийн ачааллыг бууруулж, алдааг тэсвэрлэх чадварын одоогийн түвшинг хадгалах) дараах схемийн дагуу ажиллах ёстой.
Үйл ажиллагааг шалгаж үзэхэд серверүүд дээр суулгасан RedHat-ийн захиалгат угсралт нь SNAT-ийг дэмждэггүй нь тогтоогдсон. Манай тохиолдолд бид ирж буй пакетууд болон тэдгээрт ирсэн хариуг ижил IP хаягаас илгээхийг баталгаажуулахын тулд SNAT-ийг ашиглахаар төлөвлөж байсан, эс тэгвээс бид дараах зургийг авах болно.
Үүнийг хүлээн зөвшөөрөх боломжгүй. Жишээлбэл, Виртуал IP (VIP) хаяг руу пакет илгээсэн прокси сервер нь VIP-ээс хариу хүлээх боловч энэ тохиолдолд IP2-ээс нөөцлөлтөд илгээсэн сешнүүдийн хувьд ирдэг. Шийдэл олдлоо: нөөцлөлт дээр өөр чиглүүлэлтийн хүснэгт үүсгэж, доор үзүүлсэн шиг хоёр TM серверийг тусдаа сүлжээгээр холбох шаардлагатай байв.
Тохиргоо
Бид 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.rpmХадгалах тохиргоонд бид серверүүдийн аль нэгийг мастер, нөгөөг нь нөөцлөлт болгон томилдог. Дараа нь бид ачаалал тэнцвэржүүлэх 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
Тиймээс бид ТМ серверүүдийн аль нэгэнд тэнцвэржүүлэгч суурилуулснаар TM үйлчилгээний алдааг тэсвэрлэх тохиргоог хэрэгжүүлсэн. Манай системийн хувьд энэ нь TM дээрх ачааллыг хоёр дахин бууруулсан бөгөөд энэ нь системийг ашиглан хэвтээ масштабын дутагдалтай асуудлыг шийдвэрлэх боломжтой болсон.
Ихэнх тохиолдолд энэ шийдэл нь хурдан бөгөөд нэмэлт зардалгүйгээр хэрэгждэг боловч заримдаа UDP урсгалыг тэнцвэржүүлэх үед тохиргоонд хэд хэдэн хязгаарлалт, бэрхшээлтэй байдаг.
Эх сурвалж: www.habr.com