Yandex.Cloud मधील नेटवर्क लोड बॅलन्सरचे आर्किटेक्चर

हॅलो, मी सेर्गेई एलंट्सेव्ह आहे, मी विकास करतो नेटवर्क लोड बॅलन्सर Yandex.Cloud मध्ये. पूर्वी, मी यांडेक्स पोर्टलसाठी एल 7 बॅलेंसरच्या विकासाचे नेतृत्व केले - सहकारी विनोद करतात की मी काहीही केले तरी ते बॅलन्सर असल्याचे दिसून येते. मी Habr वाचकांना क्लाउड प्लॅटफॉर्मवर लोड कसे व्यवस्थापित करावे, हे लक्ष्य साध्य करण्यासाठी आम्ही काय आदर्श साधन म्हणून पाहतो आणि हे साधन तयार करण्याच्या दिशेने आम्ही कसे वाटचाल करत आहोत हे सांगेन.

प्रथम, काही संज्ञा सादर करूया:

• व्हीआयपी (व्हर्च्युअल आयपी) - बॅलन्सर आयपी पत्ता
• सर्व्हर, बॅकएंड, उदाहरण - अॅप्लिकेशन चालवणारे व्हर्च्युअल मशीन
• आरआयपी (रिअल आयपी) - सर्व्हरचा आयपी पत्ता
• आरोग्य तपासणी - सर्व्हरची तयारी तपासत आहे
• उपलब्धता झोन, AZ - डेटा सेंटरमध्ये वेगळ्या पायाभूत सुविधा
• प्रदेश - वेगवेगळ्या AZ चे संघ

लोड बॅलन्सर्स तीन मुख्य कार्ये सोडवतात: ते स्वतःच बॅलन्सिंग करतात, सेवेची दोष सहनशीलता सुधारतात आणि त्याचे स्केलिंग सुलभ करतात. स्वयंचलित रहदारी व्यवस्थापनाद्वारे दोष सहिष्णुता सुनिश्चित केली जाते: बॅलन्सर ऍप्लिकेशनच्या स्थितीवर लक्ष ठेवतो आणि समतोलपणाची उदाहरणे वगळतो जी जिवंतपणा तपासणी पास करत नाहीत. सर्व उदाहरणांमध्ये लोड समान रीतीने वितरीत करून, तसेच फ्लायवरील उदाहरणांची सूची अद्यतनित करून स्केलिंग सुनिश्चित केले जाते. समतोल पुरेसा एकसमान नसल्यास, काही उदाहरणांना त्यांच्या क्षमतेच्या मर्यादेपेक्षा जास्त भार प्राप्त होईल आणि सेवा कमी विश्वासार्ह होईल.

लोड बॅलन्सरचे अनेकदा OSI मॉडेलच्या प्रोटोकॉल लेयरद्वारे वर्गीकरण केले जाते ज्यावर ते चालते. क्लाउड बॅलन्सर TCP स्तरावर कार्यरत आहे, जो चौथ्या स्तराशी संबंधित आहे, L4.

क्लाउड बॅलन्सर आर्किटेक्चरच्या विहंगावलोकनकडे वळू. आम्ही हळूहळू तपशील पातळी वाढवू. आम्ही बॅलन्सर घटकांना तीन वर्गांमध्ये विभागतो. कॉन्फिगरेशन प्लेन क्लास वापरकर्त्याच्या परस्परसंवादासाठी जबाबदार आहे आणि सिस्टमची लक्ष्य स्थिती संग्रहित करतो. कंट्रोल प्लेन सिस्टमची सद्य स्थिती संग्रहित करते आणि डेटा प्लेन क्लासमधून सिस्टम व्यवस्थापित करते, जे क्लायंटकडून तुमच्या घटनांपर्यंत रहदारी पोहोचवण्यासाठी थेट जबाबदार असतात.

डेटा प्लेन

बॉर्डर राउटर नावाच्या महागड्या उपकरणांवर रहदारी संपते. दोष सहिष्णुता वाढवण्यासाठी, अशी अनेक उपकरणे एकाच डेटा सेंटरमध्ये कार्य करतात. पुढे, ट्रॅफिक बॅलन्सर्सकडे जाते, जे ग्राहकांसाठी BGP द्वारे सर्व AZs ला कोणत्याही कास्ट IP पत्ते घोषित करतात. 

रहदारी ECMP वरून प्रसारित केली जाते - ही एक राउटिंग रणनीती आहे ज्यानुसार लक्ष्यापर्यंत अनेक समान चांगले मार्ग असू शकतात (आमच्या बाबतीत, लक्ष्य गंतव्य IP पत्ता असेल) आणि त्यापैकी कोणत्याही बाजूने पॅकेट पाठवले जाऊ शकतात. आम्ही खालील योजनेनुसार अनेक उपलब्धता झोनमध्ये कामास देखील समर्थन देतो: आम्ही प्रत्येक झोनमध्ये पत्त्याची जाहिरात करतो, रहदारी जवळच्या ठिकाणी जाते आणि त्याच्या मर्यादेपलीकडे जात नाही. नंतर पोस्टमध्ये आम्ही ट्रॅफिकचे काय होते ते अधिक तपशीलवार पाहू.

कॉन्फिग विमान

 
कॉन्फिगरेशन प्लेनचा मुख्य घटक API आहे, ज्याद्वारे बॅलन्सरसह मूलभूत ऑपरेशन्स केले जातात: उदाहरणे तयार करणे, हटवणे, घटनांची रचना बदलणे, आरोग्य तपासणी परिणाम प्राप्त करणे इ. एकीकडे, हे REST API आहे आणि दुसरीकडे इतर, आम्ही क्लाउडमध्ये बरेचदा फ्रेमवर्क gRPC वापरतो, म्हणून आम्ही REST ला gRPC मध्ये "अनुवाद" करतो आणि नंतर फक्त gRPC वापरतो. कोणतीही विनंती यॅन्डेक्स.क्लाउड कामगारांच्या सामान्य पूलवर कार्यान्वित केलेल्या असिंक्रोनस इडम्पोटंट टास्कची मालिका तयार करते. कार्ये अशा प्रकारे लिहिली जातात की ते कधीही निलंबित केले जाऊ शकतात आणि नंतर पुन्हा सुरू केले जाऊ शकतात. हे स्केलेबिलिटी, रिपीटेबिलिटी आणि ऑपरेशन्सचे लॉगिंग सुनिश्चित करते.

परिणामी, एपीआयचे कार्य बॅलेंसर सर्व्हिस कंट्रोलरला विनंती करेल, जे गो मध्ये लिहिलेले आहे. हे बॅलन्सर जोडू आणि काढू शकते, बॅकएंड आणि सेटिंग्जची रचना बदलू शकते. 

सेवा तिची स्थिती Yandex Database मध्ये संग्रहित करते, एक वितरित व्यवस्थापित डेटाबेस जो तुम्ही लवकरच वापरण्यास सक्षम असाल. Yandex.Cloud मध्ये, जसे आम्ही आधीच सांगितले, डॉग फूड संकल्पना लागू होते: जर आपण स्वतः आमच्या सेवा वापरत असाल, तर आमच्या ग्राहकांना देखील त्या वापरण्यास आनंद होईल. यांडेक्स डेटाबेस हे अशा संकल्पनेच्या अंमलबजावणीचे उदाहरण आहे. आम्ही आमचा सर्व डेटा YDB मध्ये संग्रहित करतो आणि आम्हाला डेटाबेस राखण्यासाठी आणि स्केल करण्याचा विचार करण्याची गरज नाही: या समस्या आमच्यासाठी सोडवल्या जातात, आम्ही डेटाबेसचा वापर सेवा म्हणून करतो.

चला बॅलेंसर कंट्रोलरकडे परत जाऊया. बॅलन्सरबद्दल माहिती जतन करणे आणि हेल्थचेक कंट्रोलरला वर्च्युअल मशीनची तयारी तपासण्यासाठी एक कार्य पाठवणे हे त्याचे कार्य आहे.

आरोग्य तपासणी नियंत्रक

ते चेकचे नियम बदलण्याच्या विनंत्या प्राप्त करतात, त्यांना YDB मध्ये सेव्ह करते, हेल्थचेक नोड्समध्ये कार्ये वितरीत करते आणि परिणाम एकत्रित करते, जे नंतर डेटाबेसमध्ये सेव्ह केले जातात आणि लोडबॅलेंसर कंट्रोलरला पाठवले जातात. ते, यामधून, डेटा प्लेनमधील क्लस्टरची रचना लोडबॅलेंसर-नोडवर बदलण्याची विनंती पाठवते, ज्याची मी खाली चर्चा करेन.

चला आरोग्य तपासणीबद्दल अधिक बोलूया. ते अनेक वर्गांमध्ये विभागले जाऊ शकतात. ऑडिटचे यशाचे निकष वेगळे असतात. TCP तपासण्यांना निश्चित वेळेत यशस्वीरित्या कनेक्शन स्थापित करणे आवश्यक आहे. HTTP तपासण्यांसाठी यशस्वी कनेक्शन आणि 200 स्टेटस कोडसह प्रतिसाद दोन्ही आवश्यक आहेत.

तसेच, चेक क्रियेच्या वर्गात भिन्न असतात - ते सक्रिय आणि निष्क्रिय असतात. कोणतीही विशेष कारवाई न करता निष्क्रीय तपासणी फक्त ट्रॅफिकमध्ये काय घडत आहे याचे निरीक्षण करते. हे L4 वर फार चांगले कार्य करत नाही कारण ते उच्च-स्तरीय प्रोटोकॉलच्या तर्कावर अवलंबून असते: L4 वर ऑपरेशनला किती वेळ लागला किंवा कनेक्शन पूर्ण करणे चांगले किंवा वाईट होते याबद्दल कोणतीही माहिती नाही. सक्रिय तपासण्यांसाठी बॅलन्सरला प्रत्येक सर्व्हर उदाहरणावर विनंत्या पाठवण्याची आवश्यकता असते.

बहुतेक लोड बॅलन्सर्स स्वतः जिवंतपणा तपासतात. क्लाउडमध्ये, आम्ही स्केलेबिलिटी वाढवण्यासाठी सिस्टमचे हे भाग वेगळे करण्याचा निर्णय घेतला. हा दृष्टीकोन आम्हाला सेवेसाठी आरोग्य तपासणी विनंत्यांची संख्या कायम ठेवताना बॅलन्सर्सची संख्या वाढविण्यास अनुमती देईल. तपासण्या वेगळ्या हेल्थचेक नोड्सद्वारे केल्या जातात, ज्यामध्ये चेक टार्गेट्स शार्ड केले जातात आणि त्याची प्रतिकृती तयार केली जाते. तुम्ही एका होस्टकडून तपासण्या करू शकत नाही, कारण ते अयशस्वी होऊ शकते. मग त्याने तपासलेल्या उदाहरणांची स्थिती आपल्याला मिळणार नाही. आम्ही किमान तीन हेल्थचेक नोड्समधून कोणत्याही उदाहरणांवर तपासणी करतो. आम्ही सातत्यपूर्ण हॅशिंग अल्गोरिदम वापरून नोड्स दरम्यान तपासण्याचे उद्दिष्ट कमी करतो.

संतुलन आणि आरोग्य तपासणी वेगळे केल्याने समस्या उद्भवू शकतात. जर हेल्थचेक नोडने बॅलन्सर (जे सध्या रहदारीची सेवा देत नाही) बायपास करून, उदाहरणासाठी विनंती करत असेल, तर एक विचित्र परिस्थिती उद्भवते: संसाधन जिवंत असल्याचे दिसते, परंतु रहदारी त्याच्यापर्यंत पोहोचणार नाही. आम्ही ही समस्या अशा प्रकारे सोडवतो: आम्ही बॅलन्सरद्वारे आरोग्य तपासणी वाहतूक सुरू करण्याची हमी देतो. दुस-या शब्दात, क्लायंट आणि हेल्थ चेकमधून ट्रॅफिकसह पॅकेट हलवण्याची योजना कमीत कमी भिन्न आहे: दोन्ही प्रकरणांमध्ये, पॅकेट बॅलन्सर्सपर्यंत पोहोचतील, जे त्यांना लक्ष्यित स्त्रोतांपर्यंत पोहोचवतील.

फरक असा आहे की ग्राहक VIP ला विनंती करतात, तर आरोग्य तपासणी प्रत्येक वैयक्तिक RIP ला विनंती करतात. येथे एक मनोरंजक समस्या उद्भवते: आम्ही आमच्या वापरकर्त्यांना राखाडी IP नेटवर्कमध्ये संसाधने तयार करण्याची संधी देतो. चला कल्पना करूया की दोन भिन्न क्लाउड मालक आहेत ज्यांनी त्यांच्या सेवा बॅलन्सर्सच्या मागे लपवल्या आहेत. त्यांच्यापैकी प्रत्येकाकडे समान पत्त्यांसह 10.0.0.1/24 सबनेटमध्ये संसाधने आहेत. आपल्याला ते कसे तरी वेगळे करण्यास सक्षम असणे आवश्यक आहे आणि येथे आपल्याला Yandex.Cloud आभासी नेटवर्कच्या संरचनेत जाण्याची आवश्यकता आहे. मध्ये अधिक तपशील शोधणे चांगले बद्दलचा व्हिडिओ:क्लाउड इव्हेंट, आमच्यासाठी आता हे महत्त्वाचे आहे की नेटवर्क बहुस्तरीय आहे आणि त्यात बोगदे आहेत जे सबनेट आयडीद्वारे ओळखले जाऊ शकतात.

हेल्थचेक नोड्स तथाकथित अर्ध-IPv6 पत्ते वापरून बॅलन्सरशी संपर्क साधतात. अर्ध-पत्ता हा IPv6 पत्ता असतो ज्यामध्ये IPv4 पत्ता आणि वापरकर्ता सबनेट आयडी अंतर्भूत असतो. ट्रॅफिक बॅलन्सरपर्यंत पोहोचते, जो त्यातून IPv4 स्त्रोत पत्ता काढतो, IPv6 ला IPv4 ने बदलतो आणि वापरकर्त्याच्या नेटवर्कवर पॅकेट पाठवतो.

रिव्हर्स ट्रॅफिक त्याच मार्गाने जातो: बॅलन्सर पाहतो की हेल्थचेकर्सकडून गंतव्यस्थान राखाडी नेटवर्क आहे आणि IPv4 मध्ये IPv6 रूपांतरित करते.

व्हीपीपी - डेटा प्लेनचे हृदय

बॅलन्सरची अंमलबजावणी व्हेक्टर पॅकेट प्रोसेसिंग (VPP) तंत्रज्ञान वापरून केली जाते, नेटवर्क ट्रॅफिकच्या बॅच प्रक्रियेसाठी Cisco चे फ्रेमवर्क. आमच्या बाबतीत, फ्रेमवर्क वापरकर्ता-स्पेस नेटवर्क डिव्हाइस व्यवस्थापन लायब्ररी - डेटा प्लेन डेव्हलपमेंट किट (DPDK) वर कार्य करते. हे उच्च पॅकेट प्रक्रिया कार्यप्रदर्शन सुनिश्चित करते: कर्नलमध्ये बरेच कमी व्यत्यय उद्भवतात, आणि कर्नल स्पेस आणि वापरकर्ता जागा दरम्यान कोणतेही संदर्भ स्विच नाहीत. 

व्हीपीपी आणखी पुढे जाते आणि बॅचमध्ये पॅकेजेस एकत्र करून सिस्टममधून आणखी कार्यप्रदर्शन पिळून काढते. आधुनिक प्रोसेसरवरील कॅशेच्या आक्रमक वापरामुळे कार्यक्षमतेत फायदा होतो. दोन्ही डेटा कॅशे वापरल्या जातात (पॅकेट "व्हेक्टर" मध्ये प्रक्रिया केल्या जातात, डेटा एकमेकांच्या जवळ असतो) आणि सूचना कॅशे: व्हीपीपीमध्ये, पॅकेट प्रक्रिया आलेखाचे अनुसरण करते, ज्याच्या नोड्समध्ये समान कार्य करणारी कार्ये असतात.

उदाहरणार्थ, व्हीपीपीमध्ये आयपी पॅकेट्सची प्रक्रिया खालील क्रमाने होते: प्रथम, पॅकेट शीर्षलेख पार्सिंग नोडमध्ये पार्स केले जातात आणि नंतर ते नोडवर पाठवले जातात, जे राउटिंग टेबल्सनुसार पॅकेट्स पुढे पाठवले जातात.

थोडे हार्डकोर. व्हीपीपीचे लेखक प्रोसेसर कॅशेच्या वापरामध्ये तडजोड सहन करत नाहीत, म्हणून पॅकेट्सच्या वेक्टरवर प्रक्रिया करण्यासाठी सामान्य कोडमध्ये मॅन्युअल वेक्टरायझेशन असते: एक प्रोसेसिंग लूप आहे ज्यामध्ये "आमच्याकडे रांगेत चार पॅकेट आहेत" सारखी परिस्थिती प्रक्रिया केली जाते, मग दोनसाठी समान, नंतर - एकासाठी. प्रीफेच सूचनांचा वापर बर्‍याचदा कॅशेमध्‍ये डेटा लोड करण्‍यासाठी केला जातो आणि त्यानंतरच्या पुनरावृत्तीमध्‍ये त्‍यांच्‍या अ‍ॅक्सेसचा वेग वाढवण्‍यात येतो.

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

त्यामुळे, हेल्थचेक्स IPv6 वर VPP ला बोलतात, ज्यामुळे त्यांचे IPv4 मध्ये रूपांतर होते. हे ग्राफमधील नोडद्वारे केले जाते, ज्याला आपण अल्गोरिदमिक NAT म्हणतो. रिव्हर्स ट्रॅफिकसाठी (आणि IPv6 वरून IPv4 मध्ये रूपांतरण) समान अल्गोरिदमिक NAT नोड आहे.

बॅलन्सर क्लायंटकडून थेट रहदारी आलेख नोड्समधून जाते, जे स्वतःच बॅलन्सिंग करतात. 

पहिला नोड चिकट सत्र आहे. हे हॅश संचयित करते 5-टपल स्थापित सत्रांसाठी. 5-ट्यूपलमध्ये क्लायंटचा पत्ता आणि पोर्ट समाविष्ट आहे ज्यावरून माहिती प्रसारित केली जाते, रहदारी प्राप्त करण्यासाठी उपलब्ध स्त्रोतांचे पत्ता आणि पोर्ट तसेच नेटवर्क प्रोटोकॉल. 

5-ट्यूपल हॅश आम्हाला त्यानंतरच्या सातत्यपूर्ण हॅशिंग नोडमध्ये कमी गणना करण्यास मदत करते, तसेच बॅलन्सरच्या मागे संसाधन सूचीतील बदल चांगल्या प्रकारे हाताळण्यास मदत करते. जेव्हा एखादे पॅकेट ज्यासाठी कोणतेही सत्र नसते ते बॅलन्सरवर येते, तेव्हा ते सातत्यपूर्ण हॅशिंग नोडवर पाठवले जाते. येथे सातत्यपूर्ण हॅशिंग वापरून समतोल साधला जातो: आम्ही उपलब्ध "लाइव्ह" संसाधनांच्या सूचीमधून एक संसाधन निवडतो. पुढे, पॅकेट NAT नोडला पाठवले जातात, जे प्रत्यक्षात गंतव्य पत्त्याची जागा घेतात आणि चेकसमची पुनर्गणना करतात. जसे तुम्ही बघू शकता, आम्ही VPP च्या नियमांचे पालन करतो - लाइक करणे, प्रोसेसर कॅशेची कार्यक्षमता वाढवण्यासाठी समान गणना गटबद्ध करणे.

सातत्यपूर्ण हॅशिंग

आम्ही ते का निवडले आणि ते काय आहे? प्रथम, मागील कार्याचा विचार करूया - सूचीमधून संसाधन निवडणे. 

विसंगत हॅशिंगसह, येणार्‍या पॅकेटच्या हॅशची गणना केली जाते आणि या हॅशला संसाधनांच्या संख्येने विभाजित करून उर्वरित सूचीमधून संसाधन निवडले जाते. जोपर्यंत यादी अपरिवर्तित राहते, तोपर्यंत ही योजना चांगली कार्य करते: आम्ही नेहमी समान 5-ट्यूपल असलेली पॅकेट समान उदाहरणावर पाठवतो. जर, उदाहरणार्थ, काही संसाधनांनी आरोग्य तपासणीस प्रतिसाद देणे थांबवले, तर हॅशच्या महत्त्वपूर्ण भागासाठी निवड बदलेल. क्लायंटचे TCP कनेक्शन तुटले जातील: एक पॅकेट जे पूर्वी उदाहरण A पर्यंत पोहोचले आहे ते उदाहरण B पर्यंत पोहोचू शकते, जे या पॅकेटच्या सत्राशी परिचित नाही.

सातत्यपूर्ण हॅशिंग वर्णन केलेल्या समस्येचे निराकरण करते. ही संकल्पना स्पष्ट करण्याचा सर्वात सोपा मार्ग आहे: कल्पना करा की तुमच्याकडे एक रिंग आहे ज्यामध्ये तुम्ही हॅशद्वारे संसाधने वितरीत करता (उदाहरणार्थ, IP:पोर्टद्वारे). संसाधन निवडणे म्हणजे चाक एका कोनाने फिरवणे, जे पॅकेटच्या हॅशद्वारे निर्धारित केले जाते.

जेव्हा संसाधनांची रचना बदलते तेव्हा हे रहदारीचे पुनर्वितरण कमी करते. संसाधन हटवल्याने केवळ सातत्यपूर्ण हॅशिंग रिंगच्या भागावर परिणाम होईल ज्यामध्ये संसाधन स्थित होते. संसाधन जोडल्याने वितरण देखील बदलते, परंतु आमच्याकडे एक चिकट सत्र नोड आहे, जो आम्हाला आधीच स्थापित सत्रांना नवीन संसाधनांवर स्विच करू देत नाही.

बॅलन्सर आणि संसाधनांमधील थेट रहदारीचे काय होते ते आम्ही पाहिले. आता परतीच्या वाहतुकीकडे पाहू. हे चेक ट्रॅफिक प्रमाणेच पॅटर्न फॉलो करते - अल्गोरिदमिक NAT द्वारे, म्हणजे क्लायंट ट्रॅफिकसाठी रिव्हर्स NAT 44 द्वारे आणि हेल्थ चेक ट्रॅफिकसाठी NAT 46 द्वारे. आम्ही आमच्या स्वतःच्या योजनेचे पालन करतो: आम्ही आरोग्य तपासणी रहदारी आणि वास्तविक वापरकर्ता रहदारी एकत्र करतो.

लोडबॅलेंसर-नोड आणि एकत्र केलेले घटक

व्हीपीपी मधील बॅलन्सर आणि संसाधनांची रचना स्थानिक सेवेद्वारे नोंदवली जाते - लोडबॅलेंसर-नोड. हे लोडबॅलेंसर-कंट्रोलरच्या इव्हेंटच्या प्रवाहाचे सदस्यत्व घेते आणि सध्याच्या VPP स्थिती आणि कंट्रोलरकडून मिळालेल्या लक्ष्य स्थितीमधील फरक प्लॉट करण्यास सक्षम आहे. आम्हाला एक बंद प्रणाली मिळते: API मधील इव्हेंट बॅलन्सर कंट्रोलरकडे येतात, जे हेल्थचेक कंट्रोलरला संसाधनांची "लाइव्हनेस" तपासण्यासाठी टास्क नियुक्त करतात. ते, यामधून, हेल्थचेक-नोडला कार्ये नियुक्त करते आणि परिणाम एकत्रित करते, त्यानंतर ते बॅलेंसर कंट्रोलरकडे परत पाठवते. Loadbalancer-node कंट्रोलरच्या इव्हेंटचे सदस्यत्व घेते आणि VPP ची स्थिती बदलते. अशा प्रणालीमध्ये, प्रत्येक सेवेला फक्त शेजारच्या सेवांबद्दल काय आवश्यक आहे हे माहित असते. कनेक्शनची संख्या मर्यादित आहे आणि आमच्याकडे वेगवेगळ्या विभागांना स्वतंत्रपणे ऑपरेट करण्याची आणि मोजण्याची क्षमता आहे.

कोणते मुद्दे टाळले गेले?

कंट्रोल प्लेनमधील आमच्या सर्व सेवा Go मध्ये लिहिलेल्या आहेत आणि त्यांच्यात चांगले स्केलिंग आणि विश्वासार्हता वैशिष्ट्ये आहेत. Go मध्ये वितरित प्रणाली तयार करण्यासाठी अनेक मुक्त स्रोत लायब्ररी आहेत. आम्ही सक्रियपणे GRPC वापरतो, सर्व घटकांमध्ये सेवा शोधाची मुक्त स्रोत अंमलबजावणी असते - आमच्या सेवा एकमेकांच्या कार्यक्षमतेवर लक्ष ठेवतात, त्यांची रचना गतिशीलपणे बदलू शकतात आणि आम्ही याचा संबंध GRPC संतुलनाशी जोडला आहे. मेट्रिक्ससाठी, आम्ही ओपन सोर्स सोल्यूशन देखील वापरतो. डेटा प्लेनमध्ये, आम्हाला सभ्य कार्यप्रदर्शन आणि मोठ्या प्रमाणात रिसोर्स रिझर्व्ह मिळाले: स्टँड एकत्र करणे खूप कठीण होते ज्यावर आम्ही लोखंडी नेटवर्क कार्डऐवजी व्हीपीपीच्या कामगिरीवर अवलंबून राहू शकतो.

समस्या आणि उपाय

काय इतके चांगले काम केले नाही? गो मध्ये स्वयंचलित मेमरी व्यवस्थापन आहे, परंतु मेमरी लीक अजूनही होते. त्यांच्याशी सामना करण्याचा सर्वात सोपा मार्ग म्हणजे गोरोटीन चालवणे आणि त्यांना समाप्त करणे लक्षात ठेवा. टेकअवे: तुमच्या गो प्रोग्राम्सचा मेमरी वापर पहा. बर्‍याचदा चांगला सूचक म्हणजे गोरोटीनची संख्या. या कथेमध्ये एक प्लस आहे: Go मध्ये रनटाइम डेटा मिळवणे सोपे आहे - मेमरी वापर, चालू असलेल्या गोरटीनची संख्या आणि इतर अनेक पॅरामीटर्स.

तसेच, कार्यात्मक चाचण्यांसाठी गो हा सर्वोत्तम पर्याय असू शकत नाही. ते बर्‍यापैकी शब्दशः आहेत आणि “सीआयमध्ये सर्व काही बॅचमध्ये चालवणे” हा मानक दृष्टीकोन त्यांच्यासाठी फारसा योग्य नाही. वस्तुस्थिती अशी आहे की कार्यात्मक चाचण्या अधिक संसाधनांची मागणी करतात आणि वास्तविक कालबाह्य होतात. यामुळे, चाचण्या अयशस्वी होऊ शकतात कारण CPU युनिट चाचण्यांमध्ये व्यस्त आहे. निष्कर्ष: शक्य असल्यास, युनिट चाचण्यांपासून वेगळ्या "जड" चाचण्या करा. 

मायक्रोसर्व्हिस इव्हेंट आर्किटेक्चर मोनोलिथपेक्षा अधिक जटिल आहे: डझनभर वेगवेगळ्या मशीनवर लॉग गोळा करणे फार सोयीचे नाही. निष्कर्ष: जर तुम्ही मायक्रोसर्व्हिसेस करत असाल तर लगेच ट्रेसिंगबद्दल विचार करा.

आमच्या योजना

आम्ही अंतर्गत बॅलन्सर, IPv6 बॅलन्सर लाँच करू, Kubernetes स्क्रिप्टसाठी समर्थन जोडू, आमच्या सेवा शार्ड करणे सुरू ठेवू (सध्या फक्त हेल्थचेक-नोड आणि हेल्थचेक-ctrl शार्ड केलेले आहेत), नवीन आरोग्य तपासणी जोडू आणि चेकचे स्मार्ट एकत्रीकरण देखील लागू करू. आम्ही आमच्या सेवा आणखी स्वतंत्र करण्याच्या शक्यतेचा विचार करत आहोत - जेणेकरून ते एकमेकांशी थेट संवाद साधू शकत नाहीत, परंतु संदेश रांग वापरून. एक SQS-सुसंगत सेवा नुकतीच क्लाउडमध्ये आली आहे यांडेक्स संदेश रांग.

अलीकडे, यांडेक्स लोड बॅलन्सरचे सार्वजनिक प्रकाशन झाले. अन्वेषण दस्तऐवजीकरण सेवेसाठी, तुमच्यासाठी सोयीस्कर पद्धतीने बॅलन्सर व्यवस्थापित करा आणि तुमच्या प्रोजेक्टची फॉल्ट टॉलरन्स वाढवा!

स्त्रोत: www.habr.com