සියලුම ඉල්ලීම් සැකසීමට එක් සේවාදායකයක බලය ප්රමාණවත් නොවේ නම් සහ මෘදුකාංග නිෂ්පාදකයා බර තුලනය ලබා නොදෙන්නේ නම් කුමක් කළ යුතුද? ලෝඩ් බැලන්සර් මිලදී ගැනීමේ සිට ඉල්ලීම් ගණන සීමා කිරීම දක්වා බොහෝ විකල්ප තිබේ. පවතින තත්වයන් සැලකිල්ලට ගනිමින් තත්වය අනුව නිවැරදි කුමක්ද යන්න තීරණය කළ යුතුය. ඔබේ අයවැය සීමිත නම් සහ ඔබට නොමිලේ සේවාදායකයක් තිබේ නම් ඔබට කළ හැකි දේ මෙම ලිපියෙන් අපි ඔබට කියමු.
එක් සේවාදායකයක බර අඩු කිරීමට අවශ්ය පද්ධතියක් ලෙස, අපි InfoWatch වෙතින් DLP (තොරතුරු කාන්දු වීම වැළැක්වීමේ පද්ධතිය) තෝරා ගත්තෙමු. ක්රියාත්මක කිරීමේ ලක්ෂණයක් වූයේ "සටන්" සේවාදායකයක් මත සමතුලිත කාර්යය ස්ථානගත කිරීමයි.
අප මුහුණ දුන් එක් ගැටලුවක් වූයේ Source NAT (SNAT) භාවිතා කිරීමට ඇති නොහැකියාවයි. මෙය අවශ්ය වූයේ ඇයි සහ ගැටලුව විසඳා ගත්තේ කෙසේද, අපි තවදුරටත් විස්තර කරමු.
එබැවින්, මුලින් පවතින පද්ධතියේ තාර්කික රූප සටහන මේ ආකාරයෙන් පෙනුනි:
ICAP ගමනාගමනය, SMTP, පරිශීලක පරිගණක වලින් සිදුවීම් රථවාහන නිරීක්ෂක (TM) සේවාදායකයේ සකසන ලදී. ඒ අතරම, දත්ත සමුදා සේවාදායකය TM හි සිදුවීම් සැකසීමෙන් පසු බර සමඟ පහසුවෙන් කටයුතු කළ නමුත් TM මත බර පැටවීම අධික විය. මෙය Device Monitor (DM) සේවාදායකයේ පණිවිඩ පෝලිමක පෙනුමෙන් මෙන්ම TM හි CPU සහ මතක භාරයෙන් පැහැදිලි විය.
බැලූ බැල්මට, අපි මෙම යෝජනා ක්රමයට වෙනත් TM සේවාදායකයක් එකතු කළහොත්, ICAP හෝ DM එයට මාරු කළ හැකිය, නමුත් දෝෂ ඉවසීම අඩු වූ බැවින් මෙම ක්රමය භාවිතා නොකිරීමට අපි තීරණය කළෙමු.
විසඳුම පිළිබඳ විස්තරය
සුදුසු විසඳුමක් සෙවීමේ ක්රියාවලියේදී, අපි නිදහසේ බෙදා හරින ලද මෘදුකාංග මත පදිංචි විය
අපට සාක්ෂාත් කර ගැනීමට අවශ්ය දේ (ටීඑම් මත බර අඩු කර වත්මන් දෝෂ ඉවසීමේ මට්ටම පවත්වා ගැනීම) පහත යෝජනා ක්රමයට අනුව ක්රියා කළ යුතුය:
ක්රියාකාරීත්වය පරීක්ෂා කිරීමේදී, සේවාදායකයේ ස්ථාපනය කර ඇති අභිරුචි RedHat එකලස් කිරීම SNAT සඳහා සහය නොදක්වන බව පෙනී ගියේය. අපගේ නඩුවේදී, එන පැකට් සහ ඒවාට ලැබෙන ප්රතිචාර එකම IP ලිපිනයෙන් එවන බව සහතික කිරීම සඳහා SNAT භාවිතා කිරීමට අපි සැලසුම් කළෙමු, එසේ නොමැතිනම් අපට පහත පින්තූරය ලැබෙනු ඇත:
මෙය පිළිගත නොහැකි ය. උදාහරණයක් ලෙස, ප්රොක්සි සේවාදායකයක්, අතථ්ය 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 ඉදිරියට යැවීම සක්රීය කරමු. මෙය කරන්නේ කෙසේද යන්න 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 (සටහන: විවිධ වාක්ය ඛණ්ඩ මෙහි භාවිතා වේ).
TM සේවාදායකයන් දෙකෙහිම Keepalived ස්ථාපනය කරන්න. අපි බෙදාහැරීමේ මූලාශ්රය ලෙස 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 මගින් balancer කළමනාකරණය කරනු ලැබේ.
පින්තූරය සම්පූර්ණ කිරීම සඳහා, සේවාදායකයන් දෙකෙහිම ස්වයංක්රීය ආරම්භයට Keepalived එකතු කරමු:
[root@tm6_1 ~]#chkconfig keepalived on
නිගමනය
ප්රතිඵල පරීක්ෂා කිරීම
අපි සේවාදායකයන් දෙකෙහිම පවත්වා ගෙන යමු:
service keepalived start
VRRP අතථ්ය ලිපිනයක් තිබේදැයි පරීක්ෂා කිරීම
VIP මාස්ටර් මත සිටින බව සහතික කර ගනිමු:
උපස්ථ මත VIP නොමැත:
ping විධානය භාවිතා කරමින්, අපි VIP ලබා ගත හැකිදැයි පරීක්ෂා කරන්නෙමු:
දැන් ඔබට master වසා දමා නැවත විධානය ක්රියාත්මක කළ හැක ping
.
ප්රති result ලය එලෙසම පැවතිය යුතු අතර, උපස්ථයේදී අපි VIP දකිනු ඇත:
සේවා තුලනය පරීක්ෂා කිරීම
උදාහරණයක් ලෙස SMTP ගනිමු. අපි 10.20.20.105 වෙත එකවර සම්බන්ධතා දෙකක් දියත් කරමු:
telnet 10.20.20.105 25
මාස්ටර් මත, සම්බන්ධතා දෙකම සක්රිය සහ විවිධ සේවාදායකයන් සමඟ සම්බන්ධ වී ඇති බව අප දැකිය යුතුය:
[root@tm6_1 ~]#watch ipvsadm –Ln
මේ අනුව, අපි එක් ටීඑම් සේවාදායකයක සමතුලිතයක් ස්ථාපනය කිරීමෙන් ටීඑම් සේවාවන්හි දෝෂ-ඉවසන වින්යාසයක් ක්රියාත්මක කර ඇත. අපගේ පද්ධතිය සඳහා, මෙය TM මත බර අඩකින් අඩු කළ අතර එමඟින් පද්ධතිය භාවිතයෙන් තිරස් පරිමාණය නොමැතිකම පිළිබඳ ගැටළුව විසඳීමට හැකි විය.
බොහෝ අවස්ථාවන්හීදී, මෙම විසඳුම ඉක්මනින් සහ අමතර වියදම් නොමැතිව ක්රියාත්මක වේ, නමුත් සමහර විට වින්යාස කිරීමේදී සීමාවන් සහ දුෂ්කරතා ගණනාවක් ඇත, උදාහරණයක් ලෙස, UDP ගමනාගමනය තුලනය කිරීමේදී.
මූලාශ්රය: www.habr.com