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

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

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

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

لذا، في البداية كان الرسم التخطيطي المنطقي للنظام الحالي يبدو على النحو التالي:

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

تمت معالجة ICAP وحركة مرور SMTP والأحداث من أجهزة الكمبيوتر الخاصة بالمستخدمين على خادم Traffic Monitor (TM). في الوقت نفسه، تعامل خادم قاعدة البيانات بسهولة مع الحمل بعد معالجة الأحداث على TM، ولكن الحمل على 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):

• 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 على خادمين 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 
        } 
}

نقوم بتثبيت 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