🥇यांडेक्स.क्लाउड में नेटवर्क लोड बैलेंसर का आर्किटेक्चर

नमस्ते, मैं सर्गेई एलांत्सेव हूं, मैं विकास करता हूं नेटवर्क लोड बैलेंसर यांडेक्स.क्लाउड में। पहले, मैंने यांडेक्स पोर्टल के लिए एल7 बैलेंसर के विकास का नेतृत्व किया था - सहकर्मी मजाक करते हैं कि मैं जो भी करता हूं, वह बैलेंसर बन जाता है। मैं हैबर पाठकों को बताऊंगा कि क्लाउड प्लेटफ़ॉर्म में लोड को कैसे प्रबंधित किया जाए, हम इस लक्ष्य को प्राप्त करने के लिए आदर्श उपकरण के रूप में क्या देखते हैं, और हम इस उपकरण के निर्माण की दिशा में कैसे आगे बढ़ रहे हैं।

सबसे पहले, आइए कुछ शर्तों का परिचय दें:

वीआईपी (वर्चुअल आईपी) - बैलेंसर आईपी एड्रेस
सर्वर, बैकएंड, इंस्टेंस - एक एप्लिकेशन चलाने वाली वर्चुअल मशीन
आरआईपी (वास्तविक आईपी) - सर्वर आईपी पता
स्वास्थ्य जांच - सर्वर की तैयारी की जांच करना
उपलब्धता क्षेत्र, AZ - डेटा सेंटर में पृथक बुनियादी ढाँचा
क्षेत्र - विभिन्न AZs का एक संघ

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

एक लोड बैलेंसर को अक्सर ओएसआई मॉडल से प्रोटोकॉल परत द्वारा वर्गीकृत किया जाता है जिस पर यह चलता है। क्लाउड बैलेंसर टीसीपी स्तर पर काम करता है, जो चौथी परत, एल4 से मेल खाता है।

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

डेटा प्लेन

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

ट्रैफ़िक को ECMP पर प्रसारित किया जाता है - यह एक रूटिंग रणनीति है जिसके अनुसार लक्ष्य के लिए कई समान रूप से अच्छे मार्ग हो सकते हैं (हमारे मामले में, लक्ष्य गंतव्य आईपी पता होगा) और उनमें से किसी के साथ पैकेट भेजे जा सकते हैं। हम निम्नलिखित योजना के अनुसार कई उपलब्धता क्षेत्रों में काम का भी समर्थन करते हैं: हम प्रत्येक क्षेत्र में एक पते का विज्ञापन करते हैं, ट्रैफ़िक निकटतम तक जाता है और उसकी सीमा से आगे नहीं जाता है। बाद में पोस्ट में हम अधिक विस्तार से देखेंगे कि ट्रैफ़िक का क्या होता है।

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

कॉन्फिग प्लेन का मुख्य घटक एपीआई है, जिसके माध्यम से बैलेंसर्स के साथ बुनियादी संचालन किया जाता है: उदाहरणों की संरचना बनाना, हटाना, बदलना, स्वास्थ्य जांच परिणाम प्राप्त करना आदि। एक ओर, यह एक REST API है, और दूसरी ओर अन्य, हम क्लाउड में अक्सर फ्रेमवर्क gRPC का उपयोग करते हैं, इसलिए हम REST को gRPC में "अनुवाद" करते हैं और फिर केवल gRPC का उपयोग करते हैं। कोई भी अनुरोध अतुल्यकालिक निष्क्रिय कार्यों की एक श्रृंखला के निर्माण की ओर ले जाता है जो Yandex.Cloud श्रमिकों के एक सामान्य पूल पर निष्पादित होते हैं। कार्य इस प्रकार लिखे जाते हैं कि उन्हें किसी भी समय निलंबित किया जा सकता है और फिर से शुरू किया जा सकता है। यह संचालन की स्केलेबिलिटी, दोहराव और लॉगिंग सुनिश्चित करता है।

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

सेवा अपनी स्थिति को यैंडेक्स डेटाबेस में संग्रहीत करती है, एक वितरित प्रबंधित डेटाबेस जिसे आप जल्द ही उपयोग करने में सक्षम होंगे। Yandex.Cloud में, जैसा कि हम पहले से ही कर रहे हैं बताया, कुत्ते के भोजन की अवधारणा लागू होती है: यदि हम स्वयं अपनी सेवाओं का उपयोग करते हैं, तो हमारे ग्राहक भी उनका उपयोग करने में प्रसन्न होंगे। यांडेक्स डेटाबेस ऐसी अवधारणा के कार्यान्वयन का एक उदाहरण है। हम अपना सारा डेटा YDB में संग्रहीत करते हैं, और हमें डेटाबेस को बनाए रखने और स्केल करने के बारे में सोचने की ज़रूरत नहीं है: ये समस्याएं हमारे लिए हल हो गई हैं, हम डेटाबेस को एक सेवा के रूप में उपयोग करते हैं।

चलिए बैलेंसर कंट्रोलर पर वापस लौटते हैं। इसका कार्य बैलेंसर के बारे में जानकारी सहेजना और हेल्थचेक नियंत्रक को वर्चुअल मशीन की तैयारी की जांच करने के लिए एक कार्य भेजना है।

स्वास्थ्य जांच नियंत्रक

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

आइए स्वास्थ्य जांच के बारे में अधिक बात करें। इन्हें कई वर्गों में विभाजित किया जा सकता है. ऑडिट के अलग-अलग सफलता मानदंड होते हैं। टीसीपी जांच के लिए एक निश्चित समय के भीतर सफलतापूर्वक कनेक्शन स्थापित करने की आवश्यकता होती है। HTTP जांच के लिए सफल कनेक्शन और 200 स्टेटस कोड के साथ प्रतिक्रिया दोनों की आवश्यकता होती है।

इसके अलावा, चेक कार्रवाई की श्रेणी में भिन्न होते हैं - वे सक्रिय और निष्क्रिय होते हैं। निष्क्रिय जाँच बिना कोई विशेष कार्रवाई किए केवल यह निगरानी करती है कि यातायात के साथ क्या हो रहा है। यह L4 पर बहुत अच्छी तरह से काम नहीं करता है क्योंकि यह उच्च-स्तरीय प्रोटोकॉल के तर्क पर निर्भर करता है: L4 पर इस बारे में कोई जानकारी नहीं है कि ऑपरेशन में कितना समय लगा या कनेक्शन पूरा होना अच्छा था या बुरा। सक्रिय जांच के लिए बैलेंसर को प्रत्येक सर्वर इंस्टेंस पर अनुरोध भेजने की आवश्यकता होती है।

अधिकांश लोड बैलेंसर स्वयं जीवंतता जांच करते हैं। क्लाउड में, हमने स्केलेबिलिटी बढ़ाने के लिए सिस्टम के इन हिस्सों को अलग करने का निर्णय लिया। यह दृष्टिकोण हमें सेवा में स्वास्थ्य जांच अनुरोधों की संख्या को बनाए रखते हुए बैलेंसर्स की संख्या बढ़ाने की अनुमति देगा। जांचें अलग-अलग स्वास्थ्य जांच नोड्स द्वारा की जाती हैं, जिनमें जांच लक्ष्यों को साझा किया जाता है और दोहराया जाता है। आप एक होस्ट से जांच नहीं कर सकते, क्योंकि यह विफल हो सकता है। तब हमें उसके द्वारा जाँचे गए उदाहरणों की स्थिति नहीं मिलेगी। हम कम से कम तीन स्वास्थ्य जांच नोड्स से किसी भी उदाहरण पर जांच करते हैं। हम सुसंगत हैशिंग एल्गोरिदम का उपयोग करके नोड्स के बीच जांच के उद्देश्यों को तेज करते हैं।

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

अंतर यह है कि ग्राहक वीआईपी से अनुरोध करते हैं, जबकि स्वास्थ्य जांच प्रत्येक व्यक्तिगत आरआईपी से अनुरोध करते हैं। यहां एक दिलचस्प समस्या उत्पन्न होती है: हम अपने उपयोगकर्ताओं को ग्रे आईपी नेटवर्क में संसाधन बनाने का अवसर देते हैं। आइए कल्पना करें कि दो अलग-अलग क्लाउड मालिक हैं जिन्होंने अपनी सेवाओं को बैलेंसर्स के पीछे छिपा दिया है। उनमें से प्रत्येक के पास समान पते के साथ 10.0.0.1/24 सबनेट में संसाधन हैं। आपको किसी तरह उन्हें अलग करने में सक्षम होने की आवश्यकता है, और यहां आपको Yandex.Cloud वर्चुअल नेटवर्क की संरचना में गोता लगाने की आवश्यकता है। इसमें अधिक विवरण प्राप्त करना बेहतर है वीडियो अबाउट:क्लाउड इवेंट से, अब हमारे लिए यह महत्वपूर्ण है कि नेटवर्क बहुस्तरीय है और इसमें सुरंगें हैं जिन्हें सबनेट आईडी द्वारा पहचाना जा सकता है।

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

रिवर्स ट्रैफ़िक उसी तरह से चलता है: बैलेंसर देखता है कि गंतव्य हेल्थचेकर्स से एक ग्रे नेटवर्क है, और IPv4 को IPv6 में परिवर्तित करता है।

वीपीपी - डेटा प्लेन का दिल

बैलेंसर को वेक्टर पैकेट प्रोसेसिंग (वीपीपी) तकनीक का उपयोग करके कार्यान्वित किया जाता है, जो नेटवर्क ट्रैफ़िक के बैच प्रोसेसिंग के लिए सिस्को का एक ढांचा है। हमारे मामले में, फ्रेमवर्क यूजर-स्पेस नेटवर्क डिवाइस मैनेजमेंट लाइब्रेरी - डेटा प्लेन डेवलपमेंट किट (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 नोड पर भेजा जाता है, जो वास्तव में गंतव्य पते को बदल देता है और चेकसम की पुनर्गणना करता है। जैसा कि आप देख सकते हैं, हम वीपीपी के नियमों का पालन करते हैं - प्रोसेसर कैश की दक्षता बढ़ाने के लिए समान गणनाओं को समूहीकृत करना पसंद करते हैं।

लगातार हैशिंग

हमने इसे क्यों चुना और यह क्या है? सबसे पहले, आइए पिछले कार्य पर विचार करें - सूची से एक संसाधन का चयन करना।

असंगत हैशिंग के साथ, आने वाले पैकेट के हैश की गणना की जाती है, और इस हैश को संसाधनों की संख्या से विभाजित करने के शेष भाग द्वारा सूची से एक संसाधन का चयन किया जाता है। जब तक सूची अपरिवर्तित रहती है, यह योजना अच्छी तरह से काम करती है: हम हमेशा समान उदाहरण के लिए समान 5-ट्यूपल के साथ पैकेट भेजते हैं। यदि, उदाहरण के लिए, कुछ संसाधनों ने स्वास्थ्य जांच पर प्रतिक्रिया देना बंद कर दिया है, तो हैश के एक महत्वपूर्ण हिस्से के लिए विकल्प बदल जाएगा। क्लाइंट का टीसीपी कनेक्शन टूट जाएगा: एक पैकेट जो पहले उदाहरण ए तक पहुंच गया था, वह उदाहरण बी तक पहुंचना शुरू कर सकता है, जो इस पैकेट के सत्र से परिचित नहीं है।

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

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

हमने देखा कि बैलेंसर और संसाधनों के बीच प्रत्यक्ष यातायात का क्या होता है। अब आइए रिटर्न ट्रैफिक पर नजर डालें। यह चेक ट्रैफ़िक के समान पैटर्न का अनुसरण करता है - एल्गोरिथम NAT के माध्यम से, यानी क्लाइंट ट्रैफ़िक के लिए रिवर्स NAT 44 के माध्यम से और हेल्थचेक ट्रैफ़िक के लिए NAT 46 के माध्यम से। हम अपनी योजना का पालन करते हैं: हम स्वास्थ्य जांच ट्रैफ़िक और वास्तविक उपयोगकर्ता ट्रैफ़िक को एकीकृत करते हैं।

लोडबैलेंसर-नोड और इकट्ठे घटक

वीपीपी में बैलेंसर्स और संसाधनों की संरचना स्थानीय सेवा - लोडबैलेंसर-नोड द्वारा रिपोर्ट की जाती है। यह लोडबैलेंसर-नियंत्रक से घटनाओं की धारा की सदस्यता लेता है और वर्तमान वीपीपी स्थिति और नियंत्रक से प्राप्त लक्ष्य स्थिति के बीच अंतर को प्लॉट करने में सक्षम है। हमें एक बंद प्रणाली मिलती है: एपीआई से घटनाएं बैलेंसर नियंत्रक के पास आती हैं, जो संसाधनों की "लाइवनेस" की जांच करने के लिए स्वास्थ्य जांच नियंत्रक को कार्य सौंपती है। बदले में, वह हेल्थचेक-नोड को कार्य सौंपता है और परिणामों को एकत्रित करता है, जिसके बाद यह उन्हें बैलेंसर नियंत्रक को वापस भेजता है। लोडबैलेंसर-नोड नियंत्रक से घटनाओं की सदस्यता लेता है और वीपीपी की स्थिति को बदलता है। ऐसी प्रणाली में, प्रत्येक सेवा केवल वही जानती है जो पड़ोसी सेवाओं के बारे में आवश्यक है। कनेक्शनों की संख्या सीमित है और हमारे पास विभिन्न खंडों को स्वतंत्र रूप से संचालित करने और स्केल करने की क्षमता है।

किन मुद्दों से बचा गया?

नियंत्रण विमान में हमारी सभी सेवाएँ गो में लिखी गई हैं और उनमें अच्छी स्केलिंग और विश्वसनीयता विशेषताएँ हैं। वितरित सिस्टम के निर्माण के लिए गो के पास कई ओपन सोर्स लाइब्रेरी हैं। हम सक्रिय रूप से जीआरपीसी का उपयोग करते हैं, सभी घटकों में सेवा खोज का एक खुला स्रोत कार्यान्वयन होता है - हमारी सेवाएं एक-दूसरे के प्रदर्शन की निगरानी करती हैं, उनकी संरचना को गतिशील रूप से बदल सकती हैं, और हमने इसे जीआरपीसी संतुलन के साथ जोड़ा है। मेट्रिक्स के लिए, हम एक ओपन सोर्स समाधान का भी उपयोग करते हैं। डेटा प्लेन में, हमें अच्छा प्रदर्शन और एक बड़ा संसाधन रिजर्व मिला: एक स्टैंड को इकट्ठा करना बहुत मुश्किल हो गया, जिस पर हम लोहे के नेटवर्क कार्ड के बजाय वीपीपी के प्रदर्शन पर भरोसा कर सकते थे।

समस्याएं और समाधान

क्या इतना अच्छा काम नहीं किया? गो में स्वचालित मेमोरी प्रबंधन है, लेकिन मेमोरी लीक अभी भी होती है। उनसे निपटने का सबसे आसान तरीका गोरोइन चलाना और उन्हें समाप्त करना याद रखना है। टेकअवे: अपने गो प्रोग्राम की मेमोरी खपत पर नजर रखें। अक्सर एक अच्छा संकेतक गोरोइन की संख्या होती है। इस कहानी में एक प्लस है: गो में रनटाइम डेटा प्राप्त करना आसान है - मेमोरी खपत, रनिंग गोरोइन की संख्या और कई अन्य पैरामीटर।

साथ ही, कार्यात्मक परीक्षणों के लिए गो सर्वोत्तम विकल्प नहीं हो सकता है। वे काफी वाचाल हैं, और "सीआई में सब कुछ एक बैच में चलाने" का मानक दृष्टिकोण उनके लिए बहुत उपयुक्त नहीं है। तथ्य यह है कि कार्यात्मक परीक्षण अधिक संसाधन-मांग वाले होते हैं और वास्तविक समयबाह्य का कारण बनते हैं। इस वजह से, परीक्षण विफल हो सकते हैं क्योंकि सीपीयू यूनिट परीक्षणों में व्यस्त है। निष्कर्ष: यदि संभव हो, तो यूनिट परीक्षणों से अलग "भारी" परीक्षण करें।

माइक्रोसर्विस इवेंट आर्किटेक्चर एक मोनोलिथ की तुलना में अधिक जटिल है: दर्जनों विभिन्न मशीनों पर लॉग एकत्र करना बहुत सुविधाजनक नहीं है। निष्कर्ष: यदि आप माइक्रोसर्विसेज बनाते हैं, तो तुरंत ट्रेसिंग के बारे में सोचें।

हमारी योजनाएँ

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

हाल ही में, यांडेक्स लोड बैलेंसर की सार्वजनिक रिलीज हुई। अन्वेषण करना प्रलेखन सेवा के लिए, आपके लिए सुविधाजनक तरीके से बैलेंसर्स का प्रबंधन करें और अपनी परियोजनाओं की दोष सहनशीलता बढ़ाएं!

स्रोत: www.habr.com

Yandex.Cloud में नेटवर्क लोड बैलेंसर का आर्किटेक्चर