यदि एक सर्वर की शक्ति सभी अनुरोधों को संसाधित करने के लिए पर्याप्त नहीं है, और सॉफ़्टवेयर निर्माता लोड संतुलन प्रदान नहीं करता है तो क्या करें? लोड बैलेंसर खरीदने से लेकर अनुरोधों की संख्या सीमित करने तक कई विकल्प हैं। इनमें से कौन सा सही है इसका निर्धारण मौजूदा स्थितियों को ध्यान में रखते हुए स्थिति के आधार पर किया जाना चाहिए। इस लेख में हम आपको बताएंगे कि यदि आपका बजट सीमित है और आपके पास मुफ़्त सर्वर है तो आप क्या कर सकते हैं।

एक प्रणाली के रूप में जिसके लिए सर्वरों में से एक पर लोड को कम करना आवश्यक था, हमने इन्फोवॉच से डीएलपी (सूचना रिसाव रोकथाम प्रणाली) को चुना। कार्यान्वयन की एक विशेषता "कॉम्बैट" सर्वरों में से एक पर बैलेंसर फ़ंक्शन की नियुक्ति थी।

हमारे सामने आने वाली समस्याओं में से एक स्रोत NAT (SNAT) का उपयोग करने में असमर्थता थी। इसकी आवश्यकता क्यों पड़ी और समस्या का समाधान कैसे हुआ, इसका वर्णन हम आगे करेंगे।

तो, प्रारंभ में मौजूदा सिस्टम का तार्किक आरेख इस तरह दिखता था:

आईसीएपी ट्रैफिक, एसएमटीपी, उपयोगकर्ता कंप्यूटर से घटनाओं को ट्रैफिक मॉनिटर (टीएम) सर्वर पर संसाधित किया गया था। उसी समय, डेटाबेस सर्वर टीएम पर घटनाओं को संसाधित करने के बाद आसानी से लोड का सामना करता था, लेकिन टीएम पर लोड स्वयं भारी था। यह डिवाइस मॉनिटर (डीएम) सर्वर पर एक संदेश कतार की उपस्थिति के साथ-साथ टीएम पर सीपीयू और मेमोरी लोड से स्पष्ट था।

पहली नज़र में, अगर हम इस योजना में एक और टीएम सर्वर जोड़ते हैं, तो या तो आईसीएपी या डीएम को इसमें स्विच किया जा सकता है, लेकिन हमने इस पद्धति का उपयोग नहीं करने का फैसला किया, क्योंकि गलती सहनशीलता कम हो गई थी।

समाधान का विवरण

उपयुक्त समाधान खोजने की प्रक्रिया में, हमने मुफ़्त सॉफ़्टवेयर पर निर्णय लिया जीवित रखा साथ LVS. क्योंकि कीपअलिव्ड फेलओवर क्लस्टर बनाने की समस्या को हल करता है और एलवीएस बैलेंसर को भी प्रबंधित कर सकता है।

हम जो हासिल करना चाहते थे (टीएम पर भार कम करना और दोष सहनशीलता के मौजूदा स्तर को बनाए रखना) उसे निम्नलिखित योजना के अनुसार काम करना चाहिए था:

कार्यक्षमता की जाँच करते समय, यह पता चला कि सर्वर पर स्थापित कस्टम RedHat असेंबली SNAT का समर्थन नहीं करती है। हमारे मामले में, हमने यह सुनिश्चित करने के लिए एसएनएटी का उपयोग करने की योजना बनाई है कि आने वाले पैकेट और उन पर प्रतिक्रियाएं एक ही आईपी पते से भेजी जाती हैं, अन्यथा हमें निम्नलिखित चित्र मिलेगा:

यह अस्वीकार्य है। उदाहरण के लिए, एक प्रॉक्सी सर्वर, जिसने वर्चुअल आईपी (वीआईपी) पते पर पैकेट भेजा है, वीआईपी से प्रतिक्रिया की उम्मीद करेगा, लेकिन इस मामले में यह बैकअप के लिए भेजे गए सत्रों के लिए आईपी2 से आएगा। एक समाधान पाया गया: बैकअप पर एक और राउटिंग टेबल बनाना और दो टीएम सर्वरों को एक अलग नेटवर्क से जोड़ना आवश्यक था, जैसा कि नीचे दिखाया गया है:

सेटिंग्स

हम ICAP, SMTP, TCP 9100 सेवाओं के साथ दो सर्वरों की एक योजना लागू करेंगे और उनमें से एक पर एक लोड बैलेंसर स्थापित किया जाएगा।

हमारे पास दो RHEL6 सर्वर हैं, जिनमें से मानक रिपॉजिटरी और कुछ पैकेज हटा दिए गए हैं।

सेवाएँ जिन्हें हमें संतुलित करने की आवश्यकता है:

• आईसीएपी - टीसीपी 1344;

• एसएमटीपी - टीसीपी 25।

डीएम से यातायात प्रसारण सेवा - टीसीपी 9100।

सबसे पहले, हमें नेटवर्क की योजना बनाने की आवश्यकता है।

वर्चुअल आईपी एड्रेस (वीआईपी):

• आईपी: 10.20.20.105.

सर्वर TM6_1:

• बाहरी आईपी: 10.20.20.101;

• आंतरिक आईपी: 192.168.1.101.

सर्वर TM6_2:

• बाहरी आईपी: 10.20.20.102;

• आंतरिक आईपी: 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 (नोट: यहां अलग वाक्यविन्यास का उपयोग किया गया है)।

दोनों टीएम सर्वरों पर कीपएलिवेड स्थापित करें। हमने वितरण स्रोत के रूप में 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

कीपअलीव्ड सेटिंग्स में, हम एक सर्वर को मास्टर के रूप में, दूसरे को बैकअप के रूप में असाइन करते हैं। फिर हम लोड संतुलन के लिए वीआईपी और सेवाएं सेट करते हैं। सेटिंग फ़ाइल आमतौर पर यहां स्थित होती है: /etc/keepalived/keepaliviv.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 
        } 
}

हम मास्टर पर एलवीएस स्थापित करते हैं, जो यातायात को संतुलित करेगा। दूसरे सर्वर के लिए बैलेंसर स्थापित करने का कोई मतलब नहीं है, क्योंकि हमारे पास कॉन्फ़िगरेशन में केवल दो सर्वर हैं।

[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpm

बैलेंसर को कीपलिवेड द्वारा प्रबंधित किया जाएगा, जिसे हमने पहले ही कॉन्फ़िगर कर लिया है।

चित्र को पूरा करने के लिए, आइए दोनों सर्वरों पर ऑटोस्टार्ट में कीपलिवेड जोड़ें:

[root@tm6_1 ~]#chkconfig keepalived on

निष्कर्ष

परिणामों की जांच

आइए दोनों सर्वरों पर कीपअलाइव चलाएं:

service keepalived start

VRRP वर्चुअल पते की उपलब्धता की जाँच करना

आइए सुनिश्चित करें कि वीआईपी मास्टर पर है:

और बैकअप पर कोई वीआईपी नहीं है:

पिंग कमांड का उपयोग करके, हम वीआईपी की उपलब्धता की जांच करेंगे:

अब आप मास्टर को बंद कर सकते हैं और कमांड को फिर से चला सकते हैं ping.

परिणाम वही रहना चाहिए, और बैकअप पर हम वीआईपी देखेंगे:

सेवा संतुलन की जाँच करना

आइए उदाहरण के लिए एसएमटीपी लें। आइए 10.20.20.105 पर एक साथ दो कनेक्शन लॉन्च करें:

telnet 10.20.20.105 25

मास्टर पर हमें देखना चाहिए कि दोनों कनेक्शन सक्रिय हैं और विभिन्न सर्वरों से जुड़े हैं:

[root@tm6_1 ~]#watch ipvsadm –Ln

इस प्रकार, हमने टीएम सर्वरों में से एक पर बैलेंसर स्थापित करके टीएम सेवाओं का दोष-सहिष्णु कॉन्फ़िगरेशन लागू किया है। हमारे सिस्टम के लिए, इससे टीएम पर लोड आधा हो गया, जिससे सिस्टम का उपयोग करके क्षैतिज स्केलिंग की कमी की समस्या को हल करना संभव हो गया।

ज्यादातर मामलों में, यह समाधान जल्दी और बिना किसी अतिरिक्त लागत के लागू किया जाता है, लेकिन कभी-कभी कॉन्फ़िगरेशन में कई सीमाएं और कठिनाइयां होती हैं, उदाहरण के लिए, यूडीपी ट्रैफ़िक को संतुलित करते समय।

स्रोत: www.habr.com