تكوين موازنة الحمل على InfoWatch Traffic Monitor

تكوين موازنة الحمل على InfoWatch Traffic Monitor

ماذا تفعل إذا كانت سعة خادم واحد غير كافية لمعالجة جميع الطلبات ، ولم توفر الشركة المصنعة للبرنامج موازنة الأحمال؟ هناك العديد من الخيارات ، من شراء موازن التحميل إلى الحد من عدد الطلبات. أيهما صحيح ، تحتاج إلى إلقاء نظرة على الموقف ، مع مراعاة الظروف الحالية. في هذه المقالة ، سنخبرك بما يمكن فعله إذا كانت الميزانية محدودة وكان هناك خادم مجاني متاح.

كنظام كان من الضروري تقليل الحمل على أحد الخوادم ، اخترنا DLP (نظام منع تسرب المعلومات) من InfoWatch. كانت إحدى سمات التنفيذ هي وضع وظيفة الموازن على أحد الخوادم "القتالية".

إحدى المشاكل التي واجهناها هي عدم القدرة على استخدام Source NAT (SNAT). سنقول المزيد لماذا كان هذا ضروريًا وكيف تم حل المشكلة.

لذلك ، بدا المخطط المنطقي للنظام الحالي كما يلي:

تكوين موازنة الحمل على InfoWatch Traffic Monitor

تمت معالجة ICAP ، وحركة مرور SMTP ، والأحداث من أجهزة كمبيوتر المستخدم على خادم Traffic Monitor (TM). في الوقت نفسه ، تعامل خادم قاعدة البيانات بسهولة مع الحمل بعد معالجة الأحداث على ذاكرة الترجمة ، لكن الحمل على ذاكرة الترجمة نفسها كان كبيرًا. كان هذا مرئيًا في مظهر قائمة انتظار الرسائل على خادم Device Monitor (DM) ، وكذلك في استخدام المعالج والذاكرة على TM.

للوهلة الأولى ، إذا تمت إضافة خادم TM واحد إلى هذا المخطط ، فيمكن تحويل ICAP أو DM إليه ، لكننا قررنا عدم استخدام هذه الطريقة ، نظرًا لتقليل التسامح مع الخطأ.

وصف الحل

في عملية إيجاد حل مناسب ، قررنا البرمجيات الحرة حافظ على الحياة مع LVS. نظرًا لأن Keepalived يحل مشكلة إنشاء مجموعة تجاوز الفشل ، ويمكنه أيضًا إدارة موازن LVS.

ما أردنا تحقيقه (تقليل الحمل على TM والحفاظ على المستوى الحالي للتسامح مع الخطأ) يجب أن يعمل على النحو التالي:

تكوين موازنة الحمل على InfoWatch Traffic Monitor

أثناء الفحص الصحي ، اتضح أن مجموعة RedHat المخصصة المثبتة على الخوادم لا تدعم SNAT. في حالتنا ، خططنا لاستخدام SNAT بحيث يتم إرسال الحزم الواردة والردود عليها من نفس عنوان IP ، وإلا فسنحصل على الصورة التالية:

تكوين موازنة الحمل على InfoWatch Traffic Monitor

هذا غير مقبول. على سبيل المثال ، خادم وكيل ، يرسل حزمًا إلى عنوان IP ظاهري (VIP) ، يتوقع استجابة من VIP ، ولكن في هذه الحالة سيأتي من IP2 للجلسات المرسلة إلى النسخ الاحتياطي. تم العثور على الحل: كان من الضروري إنشاء جدول توجيه آخر على النسخ الاحتياطي وتوصيل خادمين TM بشبكة منفصلة ، كما هو موضح أدناه:

تكوين موازنة الحمل على InfoWatch Traffic Monitor

إعدادات

نقوم بتنفيذ مخطط من خادمين مع خدمات ICAP و SMTP و TCP 9100 وموازن تحميل مثبت على أحدهما.

لدينا خادمان RHEL6 ، تمت إزالة المستودعات القياسية وبعض الحزم منه.

الخدمات التي نحتاجها لتحقيق التوازن:

• ICAP - tcp 1344؛

• SMTP - tcp 25.

خدمة نقل حركة المرور من DM - tcp 9100.

نحتاج أولاً إلى تخطيط الشبكة.

عنوان IP الظاهري (VIP):

• آي بي: 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 على خادمي TM. كيفية القيام بذلك على 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

في إعدادات 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 
        } 
}

قم بالتثبيت على Master 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 على درجة الماجستير:

تكوين موازنة الحمل على InfoWatch Traffic Monitor

ولا يوجد VIP على النسخ الاحتياطي:

تكوين موازنة الحمل على InfoWatch Traffic Monitor

باستخدام الأمر ping ، تحقق من توفر VIP:

تكوين موازنة الحمل على InfoWatch Traffic Monitor

يمكنك الآن إيقاف تشغيل الأمر الرئيسي وتشغيل الأمر مرة أخرى ping.

يجب أن تظل النتيجة كما هي ، وفي النسخة الاحتياطية سنرى VIP:

تكوين موازنة الحمل على InfoWatch Traffic Monitor

فحص موازنة الخدمة

لنأخذ SMTP كمثال. لنبدأ اتصالين بـ 10.20.20.105 في نفس الوقت:

telnet 10.20.20.105 25

على المستوى الرئيسي ، يجب أن نرى أن كلا الاتصالين نشطين ومتصلين بخوادم مختلفة:

[root@tm6_1 ~]#watch ipvsadm –Ln

تكوين موازنة الحمل على InfoWatch Traffic Monitor

وبالتالي ، قمنا بتنفيذ تكوين متسامح مع الأخطاء لخدمات TM مع تثبيت موازن على أحد خوادم TM. بالنسبة لنظامنا ، أدى ذلك إلى تقليل الحمل على TM بمقدار النصف ، مما جعل من الممكن حل مشكلة نقص القياس الأفقي عن طريق النظام.

في معظم الحالات ، يتم تنفيذ هذا الحل بسرعة وبدون تكلفة إضافية ، ولكن في بعض الأحيان يكون هناك عدد من القيود والصعوبات في الإعداد ، على سبيل المثال ، عند موازنة حركة مرور UDP.

المصدر: www.habr.com

إضافة تعليق