ماذا علي أن أفعل إذا كانت قوة خادم واحد لا تكفي لمعالجة جميع الطلبات ، ولم توفر الشركة المصنعة للبرنامج موازنة التحميل؟ هناك العديد من الخيارات - من شراء موازن التحميل إلى الحد من عدد الطلبات. ما هو الصحيح ، تحتاج إلى إلقاء نظرة على الوضع ، مع مراعاة الظروف الحالية. سنخبرك في هذه المقالة بما يمكن القيام به إذا كانت الميزانية محدودة وكان هناك خادم متاح مجانًا.
نظرًا لأن النظام كان ضروريًا لتقليل الحمل على أحد الخوادم ، فقد اخترنا InfoWatch DLP (نظام منع تسرب المعلومات). كانت إحدى ميزات التنفيذ هي وضع وظيفة الموازن على أحد الخوادم "القتالية".
إحدى المشكلات التي واجهناها هي عدم القدرة على استخدام Source NAT (SNAT). لما كانت هناك حاجة وكيف تم حل المشكلة ، سنقوم بوصف أكثر.
لذلك ، كان المخطط المنطقي الأولي للنظام الحالي كما يلي:
تمت معالجة حركة مرور ICAP و SMTP والأحداث من أجهزة كمبيوتر المستخدمين على خادم Traffic Monitor (TM). في الوقت نفسه ، تعامل خادم قاعدة البيانات بسهولة مع الحمل بعد معالجة الأحداث على TM ، لكن التحميل على TM نفسه كان كبيرًا. كان هذا واضحًا عند حدوث قائمة انتظار الرسائل على خادم Device Monitor (DM) ، وكذلك عن طريق تحميل المعالج والذاكرة على TM.
للوهلة الأولى ، إذا أضفنا خادم 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 - برنامج التعاون الفني 25.
خدمة مرور بلدية دبي - برنامج التعاون الفني 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 هو موضح هنا .
نقرر أي من الخوادم سيكون لدينا الرئيسي ، وأيهما - النسخ الاحتياطي. اجعل Master هو 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 على الماجستير:
وليس هناك VIP على النسخ الاحتياطي:
باستخدام الأمر ping ، تحقق من توفر VIP:
يمكنك الآن إيقاف التشغيل الرئيسي وتشغيل الأمر ping مرة أخرى.
يجب أن تظل النتيجة كما هي ، وعند النسخ الاحتياطي سنرى VIP:
تحقق خدمة موازنة
خذ SMTP ، على سبيل المثال. قم بتشغيل اتصالين إلى 10.20.20.105 في نفس الوقت:
telnet 10.20.20.105 25
على الرئيسي ، يجب أن نرى أن كلا الاتصالين نشطان ومتصلان بخوادم مختلفة:
[root@tm6_1 ~]#watch ipvsadm –Ln
وبالتالي ، قمنا بتطبيق تكوين آمن للفشل لخدمات TM مع تثبيت موازن على أحد خوادم TM. بالنسبة لنظامنا ، قلل هذا الحمل على TM بمقدار النصف ، مما سمح لنا بحل مشكلة عدم وجود مقياس أفقي باستخدام النظام.
في معظم الحالات ، يتم تنفيذ هذا الحل بسرعة وبدون تكاليف إضافية ، ولكن في بعض الأحيان يكون هناك عدد من القيود والصعوبات في الإعداد ، على سبيل المثال ، عند موازنة حركة مرور UDP.