ڇا ڪجي جيڪڏهن هڪ سرور جي طاقت سڀني درخواستن تي عمل ڪرڻ لاءِ ڪافي نه آهي، ۽ سافٽ ويئر ٺاهيندڙ لوڊ بيلنس فراهم نٿو ڪري؟ اتي ڪيترائي اختيار آھن، ھڪڙي لوڊ بيلنس خريد ڪرڻ کان وٺي درخواستن جي تعداد کي محدود ڪرڻ تائين. ڪير صحيح آهي، موجوده حالتن کي نظر ۾ رکندي، صورتحال طرفان طئي ٿيڻ گهرجي. هن آرٽيڪل ۾ اسين توهان کي ٻڌائينداسين ته توهان ڇا ڪري سگهو ٿا جيڪڏهن توهان جي بجيٽ محدود آهي ۽ توهان وٽ مفت سرور آهي.

هڪ سسٽم جي طور تي جنهن لاءِ اهو ضروري هو ته ڪنهن هڪ سرور تي لوڊ گهٽائڻ لاءِ، اسان InfoWatch مان DLP (انفارميشن ليڪيج روڪڻ وارو نظام) چونڊيو. عملدرآمد جي هڪ خصوصيت "جنگ" سرورز مان هڪ تي بيلنسر فنڪشن جي جڳهه هئي.

انهن مسئلن مان هڪ آهي جيڪو اسان کي منهن ڏيڻو آهي ماخذ NAT (SNAT) استعمال ڪرڻ جي ناڪامي هئي. اهو ڇو ضروري هو ۽ اهو مسئلو ڪيئن حل ڪيو ويو، اسان وڌيڪ بيان ڪنداسين.

تنهن ڪري، شروعاتي طور تي موجوده نظام جو منطقي ڊراگرام هن طرح ڏٺو:

ICAP ٽريفڪ، SMTP، يوزر ڪمپيوٽرن مان واقعا ٽريفڪ مانيٽر (TM) سرور تي پروسيس ڪيا ويا. ساڳئي وقت، ڊيٽابيس سرور آساني سان TM تي واقعن جي پروسيسنگ کان پوء لوڊ سان مقابلو ڪيو، پر TM تي لوڊ پاڻ ڳري هئي. اهو ظاهر ٿيو ته پيغام جي قطار جي ظاهر ٿيڻ کان ڊوائيس مانيٽر (DM) سرور تي، انهي سان گڏ سي پي يو ۽ TM تي ميموري لوڊ مان.

پهرين نظر ۾، جيڪڏهن اسان هن اسڪيم ۾ هڪ ٻيو TM سرور شامل ڪريون ٿا، ته پوءِ يا ته ICAP يا DM ان ۾ تبديل ٿي سگهي ٿو، پر اسان اهو طريقو استعمال نه ڪرڻ جو فيصلو ڪيو، ڇاڪاڻ ته غلطي برداشت گهٽجي وئي هئي.

حل جي وضاحت

مناسب حل ڳولڻ جي عمل ۾، اسان آزاديء سان ورهايل سافٽ ويئر تي آباد ٿيا زنده رکيو سان گڏ ايل وي ايس. ڇو ته Keepalived هڪ ناڪامي ڪلستر ٺاهڻ جو مسئلو حل ڪري ٿو ۽ پڻ LVS بيلنس کي منظم ڪري سگهي ٿو.

جيڪو اسان حاصل ڪرڻ چاهيون ٿا (TM تي لوڊ گھٽائڻ ۽ موجوده سطح جي غلطي رواداري کي برقرار رکڻ) ھيٺ ڏنل اسڪيم جي مطابق ڪم ڪرڻ گھرجي:

جڏهن ڪارڪردگي جي جانچ ڪندي، اهو ظاهر ٿيو ته سرور تي نصب ڪيل ڪسٽم ريڊ هٽ اسيمبلي 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 (نوٽ: هتي مختلف نحو استعمال ٿيل آهي).

انسٽال ڪريو 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 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