🌹 🎢 🐹 Yandex.Cloud में नेटवर्क लोड बैलेंसर की वास्तुकला 🧝🏽 💞 🦕

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

सबसे पहले, हम कुछ शब्द प्रस्तुत करते हैं:

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

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

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

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

डाटा प्लेन

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

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

समतल विमान

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

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

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

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

स्वास्थ्य परीक्षण नियंत्रक

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

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

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

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

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

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

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

रिवर्स ट्रैफिक उसी तरह जाता है: बैलेंसर देखता है कि गंतव्य हेल्थकेयर से एक ग्रे नेटवर्क है, और आईपीवी 4 को आईपीवी 6 में परिवर्तित करता है।

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

बैलेंसर वेक्टर पैकेट प्रोसेसिंग (VPP) की तकनीक पर लागू किया गया है - नेटवर्क ट्रैफिक के पैकेट प्रसंस्करण के लिए सिस्को से एक रूपरेखा। हमारे मामले में, नेटवर्क उपकरणों के उपयोगकर्ता-अंतरिक्ष-प्रबंधन के पुस्तकालय के ऊपर ढांचा चलता है - डेटा प्लेन डेवलपमेंट किट (DPDK)। यह उच्च पैकेट प्रसंस्करण प्रदर्शन प्रदान करता है: कर्नेल में बहुत कम रुकावटें हैं, कर्नेल स्थान और उपयोगकर्ता स्थान के बीच कोई संदर्भ स्विच नहीं हैं।

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

उदाहरण के लिए, VPP में IP पैकेटों का प्रसंस्करण निम्नलिखित क्रम में होता है: पहले, पैकेट हेडर्स को पार्सिंग नोड में पार्स किया जाता है, और फिर उन्हें नोड में भेजा जाता है, जो रूट टेबल के अनुसार आगे की तरफ बढ़ते हैं।

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

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); }

इसलिए, Healthchecks IPv6 को VPP में बदल रहे हैं, जो उन्हें IPv4 में बदल देता है। यह ग्राफ नोड द्वारा किया जाता है, जिसे हम एल्गोरिदम एनएटी कहते हैं। रिवर्स ट्रैफ़िक (और IPv6 से IPv4 में रूपांतरण) के लिए एल्गोरिथम NAT का समान नोड है।

बैलेंसर क्लाइंट का सीधा ट्रैफिक ग्राफ के नोड्स से होकर गुजरता है, जो बैलेंसिंग का प्रदर्शन करता है।

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

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

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

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

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

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

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

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

लोडबेलेंसर-नोड और घटक असेंबली

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

किन सवालों को टाला गया

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

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

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

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

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

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

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

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

Yandex.Cloud में नेटवर्क लोड बैलेंसर की वास्तुकला