څه وکړي که چیرې د یو سرور ځواک د ټولو غوښتنو پروسس کولو لپاره کافي نه وي ، او د سافټویر جوړونکی د بار توازن چمتو نکړي؟ ډیری اختیارونه شتون لري، د بار بیلنسر اخیستلو څخه د غوښتنو شمیر محدودولو پورې. کوم یو سم دی باید د موجوده شرایطو په پام کې نیولو سره د وضعیت له مخې وټاکل شي. پدې مقاله کې به موږ تاسو ته ووایو چې تاسو څه کولی شئ که ستاسو بودیجه محدوده وي او تاسو وړیا سرور ولرئ.

د یو سیسټم په توګه چې د دې لپاره اړین و چې په یو سرور کې بار کم کړي، موږ د InfoWatch څخه DLP (د معلوماتو لیک مخنیوي سیسټم) غوره کړ. د تطبیق یوه ځانګړتیا د "جنګي" سرورونو څخه په یو کې د بیلانس فعالیت ځای پرځای کول وو.

یو له هغو ستونزو څخه چې موږ ورسره مخ شو د سرچینې NAT (SNAT) کارولو نشتوالی و. ولې دې ته اړتیا وه او دا ستونزه څنګه حل شوه، موږ به نور تشریح کړو.

نو، په پیل کې د موجوده سیسټم منطقي ډیاګرام داسې ښکاري:

د ICAP ترافیک، SMTP، د کاروونکو کمپیوټرونو پیښې د ټرافیک مانیټر (TM) سرور کې پروسس شوي. په ورته وخت کې ، د ډیټابیس سرور په TM کې د پیښو پروسس کولو وروسته په اسانۍ سره د بار سره کاپي کوي ، مګر پخپله په TM کې بار دروند و. دا د وسیلې مانیټر (DM) سرور کې د پیغام کتار څرګندیدو څخه څرګند شو ، او همدارنګه په TM کې د CPU او حافظې بار څخه.

په لومړي نظر کې، که موږ په دې سکیم کې بل TM سرور اضافه کړو، نو بیا به ICAP یا DM دې ته واړول شي، مګر موږ پریکړه وکړه چې دا طریقه ونه کاروو، ځکه چې د غلطۍ زغم کم شوی.

د حل توضیحات

د مناسب حل موندلو په پروسه کې، موږ په آزاده توګه ویشل شوي سافټویر کې میشت شو ژوندی ساتل سره یوځای LVS. ځکه چې Keepalived د ناکامۍ کلستر رامینځته کولو ستونزه حل کوي او کولی شي د LVS توازن هم اداره کړي.

هغه څه چې موږ غوښتل ترلاسه کړو (په TM باندې بار کم کړئ او د غلطې زغم اوسنۍ کچې ساتل) باید د لاندې سکیم سره سم کار کړی وي:

کله چې د فعالیت چک کول، دا معلومه شوه چې په سرورونو کې نصب شوي دودیز RedHat مجلس د SNAT ملاتړ نه کوي. زموږ په قضیه کې، موږ پالن درلود چې SNAT وکاروو ترڅو ډاډ ترلاسه کړو چې راتلونکی کڅوړې او دوی ته ځوابونه د ورته IP پتې څخه لیږل کیږي، که نه نو موږ به لاندې انځور ترلاسه کړو:

دا د منلو وړ نه ده. د مثال په توګه، یو پراکسي سرور، چې د مجازی 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 (یادونه: دلته مختلف ترکیب کارول کیږي).

په دواړو 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

پایلې

د پایلو چک کول

راځئ چې په دواړو سرورونو کې ژوندی پاتې شو:

service keepalived start

د VRRP مجازی پتې شتون چک کول

راځئ چې ډاډ ترلاسه کړو چې VIP په ماسټر کې دی:

او په بیک اپ کې هیڅ VIP شتون نلري:

د پینګ کمانډ په کارولو سره، موږ به د VIP شتون وګورو:

اوس تاسو کولی شئ ماسټر بند کړئ او کمانډ بیا پرمخ وړئ ping.

پایله باید ورته پاتې شي، او په بیک اپ کې به موږ VIP وګورو:

د خدماتو توازن چیک کول

راځئ چې د مثال په توګه SMTP واخلو. راځئ چې په ورته وخت کې 10.20.20.105 ته دوه اړیکې پیل کړو:

telnet 10.20.20.105 25

په ماسټر کې موږ باید وګورو چې دواړه اړیکې فعالې دي او د مختلف سرورونو سره وصل دي:

[root@tm6_1 ~]#watch ipvsadm –Ln

په دې توګه، موږ د TM سرورونو څخه په یو کې د بیلانس په نصبولو سره د TM خدماتو د غلطۍ زغمونکي ترتیب پلي کړی. زموږ د سیسټم لپاره، دې په TM کې بار نیمایي ته راټیټ کړ، کوم چې د سیسټم په کارولو سره د افقی اندازه کولو نشتوالي ستونزه حل کول ممکن کړي.

په ډیری مواردو کې، دا حل په چټکۍ سره او پرته له اضافي لګښتونو پلي کیږي، مګر ځینې وختونه په ترتیب کې یو شمیر محدودیتونه او ستونزې شتون لري، د بیلګې په توګه، کله چې د UDP ټرافيک توازن کول.

سرچینه: www.habr.com