اگر ایک سرور کی طاقت تمام درخواستوں پر کارروائی کرنے کے لیے کافی نہیں ہے، اور سافٹ ویئر بنانے والا لوڈ بیلنس فراہم نہیں کرتا ہے تو کیا کریں؟ لوڈ بیلنسر خریدنے سے لے کر درخواستوں کی تعداد کو محدود کرنے تک بہت سے اختیارات ہیں۔ کون سا درست ہے اس کا تعین موجودہ حالات کو مدنظر رکھتے ہوئے صورت حال سے ہونا چاہیے۔ اس آرٹیکل میں ہم آپ کو بتائیں گے کہ اگر آپ کا بجٹ محدود ہے اور آپ کے پاس مفت سرور ہے تو آپ کیا کر سکتے ہیں۔

ایک نظام کے طور پر جس کے لیے سرورز میں سے کسی ایک پر بوجھ کو کم کرنا ضروری تھا، ہم نے InfoWatch سے DLP (معلومات کے رساو کی روک تھام کا نظام) کا انتخاب کیا۔ نفاذ کی ایک خصوصیت "لڑائی" سرورز میں سے ایک پر بیلنس فنکشن کی جگہ کا تعین کرنا تھا۔

ہمیں جن مسائل کا سامنا کرنا پڑا ان میں سے ایک سورس NAT (SNAT) استعمال کرنے میں ناکامی تھی۔ اس کی ضرورت کیوں تھی اور اس مسئلے کو کیسے حل کیا گیا، ہم آگے بیان کریں گے۔

لہذا، ابتدائی طور پر موجودہ نظام کا منطقی خاکہ اس طرح نظر آیا:

ICAP ٹریفک، SMTP، صارف کے کمپیوٹرز سے ہونے والے واقعات کو ٹریفک مانیٹر (TM) سرور پر پروسیس کیا گیا۔ ایک ہی وقت میں، ڈیٹا بیس سرور نے TM پر واقعات کی کارروائی کے بعد آسانی سے بوجھ کا مقابلہ کیا، لیکن خود TM پر بوجھ بہت زیادہ تھا۔ یہ ڈیوائس مانیٹر (DM) سرور پر پیغام کی قطار کے ساتھ ساتھ TM پر CPU اور میموری بوجھ سے ظاہر ہوتا ہے۔

پہلی نظر میں، اگر ہم اس سکیم میں ایک اور TM سرور شامل کرتے ہیں، تو پھر ICAP یا DM کو اس میں تبدیل کیا جا سکتا ہے، لیکن ہم نے یہ طریقہ استعمال نہ کرنے کا فیصلہ کیا، کیونکہ غلطی کی برداشت کم ہو گئی تھی۔

حل کی تفصیل

ایک مناسب حل تلاش کرنے کے عمل میں، ہم آزادانہ طور پر تقسیم کیے گئے سافٹ ویئر پر آباد ہو گئے۔ زندہ رکھا ساتھ میں ایل وی ایس. کیونکہ Keepalived ایک فیل اوور کلسٹر بنانے کے مسئلے کو حل کرتا ہے اور LVS بیلنسر کا انتظام بھی کر سکتا ہے۔

ہم جو حاصل کرنا چاہتے تھے (TM پر بوجھ کو کم کرنا اور غلطی کی موجودہ سطح کو برقرار رکھنا) اسے درج ذیل اسکیم کے مطابق کام کرنا چاہیے تھا:

فعالیت کو چیک کرنے پر پتہ چلا کہ سرورز پر نصب اپنی مرضی کے مطابق RedHat اسمبلی SNAT کو سپورٹ نہیں کرتی ہے۔ ہمارے معاملے میں، ہم نے اس بات کو یقینی بنانے کے لیے SNAT استعمال کرنے کا منصوبہ بنایا کہ آنے والے پیکٹ اور ان کے جوابات ایک ہی IP ایڈریس سے بھیجے جائیں، بصورت دیگر ہمیں درج ذیل تصویر ملے گی۔

یہ ناقابل قبول ہے۔ مثال کے طور پر، ایک پراکسی سرور، جس نے ورچوئل IP (VIP) ایڈریس پر پیکٹ بھیجے ہیں، VIP سے جواب کی توقع کرے گا، لیکن اس صورت میں یہ IP2 سے بیک اپ پر بھیجے گئے سیشنز کے لیے آئے گا۔ ایک حل مل گیا: بیک اپ پر ایک اور روٹنگ ٹیبل بنانا اور دو ٹی ایم سرورز کو علیحدہ نیٹ ورک کے ساتھ جوڑنا ضروری تھا، جیسا کہ ذیل میں دکھایا گیا ہے:

ترتیبات

ہم آئی سی اے پی، ایس ایم ٹی پی، ٹی سی پی 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۔

پھر ہم دو ٹی ایم سرورز پر آئی پی فارورڈنگ کو فعال کرتے ہیں۔ ایسا کرنے کا طریقہ 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

برقرار رکھنے والی ترتیبات میں، ہم سرورز میں سے ایک کو بطور ماسٹر، دوسرے کو بیک اپ کے طور پر تفویض کرتے ہیں۔ پھر ہم لوڈ بیلنسنگ کے لیے 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

حاصل يہ ہوا

نتائج کی جانچ کر رہا ہے۔

آئیے دونوں سرورز پر Keepalive چلائیں:

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