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

नमस्ते, म Sergey Elantsev हुँ, म विकास गर्छु नेटवर्क लोड ब्यालेन्सर Yandex.Cloud मा। पहिले, मैले यान्डेक्स पोर्टलको लागि L7 ब्यालेन्सरको विकासको नेतृत्व गरेको थिएँ - सहकर्मीहरूले ठट्टा गरे कि मैले जे गरे पनि, यो ब्यालेन्सर हुन जान्छ। म Habr पाठकहरूलाई क्लाउड प्लेटफर्ममा लोड कसरी व्यवस्थापन गर्ने, हामी यो लक्ष्य हासिल गर्नको लागि आदर्श उपकरणको रूपमा के देख्छौं, र हामी कसरी यो उपकरण निर्माण गर्न अगाडि बढिरहेका छौं भनेर बताउनेछु।

पहिले, केही सर्तहरू परिचय गरौं:

• VIP (भर्चुअल आईपी) - ब्यालेन्सर आईपी ठेगाना
• सर्भर, ब्याकइन्ड, उदाहरण - एक भर्चुअल मेसिन एउटा अनुप्रयोग चलिरहेको छ
• RIP (वास्तविक आईपी) - सर्भर आईपी ठेगाना
• स्वास्थ्य जाँच - सर्भर तयारी जाँच गर्दै
• उपलब्धता क्षेत्र, AZ - डाटा केन्द्रमा पृथक पूर्वाधार
• क्षेत्र - विभिन्न AZs को एक संघ

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

लोड ब्यालेन्सर प्रायः OSI मोडेलबाट प्रोटोकल तह द्वारा वर्गीकृत गरिन्छ जसमा यो चल्छ। क्लाउड ब्यालेन्सरले TCP स्तरमा काम गर्छ, जुन चौथो तह, L4 सँग मेल खान्छ।

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

डाटा प्लेन

सीमा राउटर भनिने महँगो उपकरणहरूमा ट्राफिक समाप्त हुन्छ। गल्ती सहिष्णुता बढाउनको लागि, त्यस्ता धेरै उपकरणहरू एकै समयमा एकै डाटा केन्द्रमा सञ्चालन हुन्छन्। अर्को, ट्राफिक ब्यालेन्सरहरूमा जान्छ, जसले ग्राहकहरूको लागि BGP मार्फत सबै AZ हरूमा कुनै पनि कास्ट IP ठेगानाहरू घोषणा गर्दछ। 

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

कन्फिग प्लेन

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

नतिजाको रूपमा, API बाट कार्यले ब्यालेन्सर सेवा नियन्त्रकलाई अनुरोध गर्नेछ, जुन Go मा लेखिएको छ। यसले ब्यालेन्सरहरू थप्न र हटाउन सक्छ, ब्याकएन्ड र सेटिङहरूको संरचना परिवर्तन गर्न सक्छ। 

सेवाले यसको राज्य Yandex Database मा भण्डारण गर्छ, एक वितरित व्यवस्थित डाटाबेस जुन तपाइँ चाँडै प्रयोग गर्न सक्षम हुनुहुनेछ। Yandex.Cloud मा, हामी पहिले नै भन्यो, कुकुर खाना अवधारणा लागू हुन्छ: यदि हामी आफैले हाम्रा सेवाहरू प्रयोग गर्छौं भने, हाम्रा ग्राहकहरू पनि तिनीहरूलाई प्रयोग गर्न खुसी हुनेछन्। Yandex डाटाबेस यस्तो अवधारणा को कार्यान्वयन को एक उदाहरण हो। हामी हाम्रा सबै डाटा 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 - डाटा प्लेन को मुटु

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

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

उदाहरणका लागि, VPP मा IP प्याकेटहरूको प्रशोधन निम्न क्रममा हुन्छ: पहिले, प्याकेट हेडरहरू पार्सिङ नोडमा पार्स गरिन्छ, र त्यसपछि तिनीहरू नोडमा पठाइन्छ, जसले प्याकेटहरूलाई राउटिंग तालिका अनुसार अगाडि बढाउँछ।

अलिकति कट्टर। VPP का लेखकहरूले प्रोसेसर क्यासहरूको प्रयोगमा सम्झौता सहन गर्दैनन्, त्यसैले प्याकेटहरूको भेक्टरलाई प्रशोधन गर्नको लागि सामान्य कोडमा म्यानुअल भेक्टोराइजेसन समावेश हुन्छ: त्यहाँ एउटा प्रशोधन लूप छ जसमा "हामीसँग लाममा चार प्याकेटहरू छन्" जस्ता अवस्था प्रशोधन गरिन्छ, त्यसपछि दुईको लागि समान, त्यसपछि - एकको लागि। प्रिफेच निर्देशनहरू प्राय: क्यासहरूमा डेटा लोड गर्न प्रयोग गरिन्छ ताकि पछिको पुनरावृत्तिहरूमा पहुँचको गति बढाउन।

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-tuple ले ग्राहकको ठेगाना र पोर्ट समावेश गर्दछ जसबाट जानकारी प्रसारण गरिन्छ, ठेगाना र ट्राफिक प्राप्त गर्न उपलब्ध स्रोतहरूको पोर्टहरू, साथै नेटवर्क प्रोटोकल। 

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

लगातार ह्यासिङ

हामीले यसलाई किन रोज्यौं र यो के हो? पहिले, अघिल्लो कार्यलाई विचार गरौं - सूचीबाट स्रोत चयन गर्दै। 

असंगत ह्यासिङको साथमा, आगमन प्याकेटको ह्यास गणना गरिन्छ, र यस ह्यासलाई स्रोतहरूको संख्याद्वारा विभाजित गरेर सूचीबाट स्रोत चयन गरिन्छ। जबसम्म सूची अपरिवर्तित रहन्छ, यो योजनाले राम्रोसँग काम गर्दछ: हामी सधैं समान 5-टपलको साथ प्याकेटहरू उही उदाहरणमा पठाउँछौं। यदि, उदाहरणका लागि, केही स्रोतहरूले स्वास्थ्य जाँचहरूमा प्रतिक्रिया दिन बन्द गरे, तब ह्यासहरूको महत्त्वपूर्ण भागको लागि छनौट परिवर्तन हुनेछ। क्लाइन्टको TCP जडानहरू बिच्छेद हुनेछन्: एक प्याकेट जुन पहिले उदाहरण A मा पुग्यो उदाहरण B मा पुग्न सुरु हुन सक्छ, जुन यस प्याकेटको लागि सत्रसँग परिचित छैन।

लगातार ह्यासिङले वर्णन गरिएको समस्या समाधान गर्छ। यस अवधारणालाई व्याख्या गर्ने सबैभन्दा सजिलो तरिका यो हो: कल्पना गर्नुहोस् कि तपाईंसँग एउटा घण्टी छ जसमा तपाईंले ह्यासद्वारा स्रोतहरू वितरण गर्नुहुन्छ (उदाहरणका लागि, IP: पोर्ट द्वारा)। स्रोत चयन गर्नु भनेको पाङ्ग्रालाई कोणद्वारा घुमाउनु हो, जुन प्याकेटको ह्यासद्वारा निर्धारण गरिन्छ।

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

हामीले ब्यालेन्सर र स्रोतहरू बीच प्रत्यक्ष ट्राफिकमा के हुन्छ भनेर हेर्यौं। अब फिर्ता ट्राफिक हेरौं। यसले एल्गोरिदमिक NAT मार्फत, ग्राहक ट्राफिकको लागि रिभर्स NAT 44 मार्फत र स्वास्थ्य जाँच ट्राफिकको लागि NAT 46 मार्फत - चेक ट्राफिकको रूपमा उही ढाँचा पछ्याउँछ। हामी हाम्रो आफ्नै योजनाको पालना गर्छौं: हामी स्वास्थ्य जाँच ट्राफिक र वास्तविक प्रयोगकर्ता ट्राफिकलाई एकीकृत गर्छौं।

लोडब्यालेन्सर-नोड र एसेम्बल कम्पोनेन्टहरू

VPP मा ब्यालेन्सर र स्रोतहरूको संरचना स्थानीय सेवा - loadbalancer-node द्वारा रिपोर्ट गरिएको छ। यसले लोडब्यालेन्सर-कन्ट्रोलरबाट घटनाहरूको स्ट्रिमको सदस्यता लिन्छ र हालको VPP राज्य र नियन्त्रकबाट प्राप्त लक्ष्य राज्य बीचको भिन्नता प्लट गर्न सक्षम छ। हामीले बन्द प्रणाली पाउँछौं: API बाट घटनाहरू ब्यालेन्सर नियन्त्रकमा आउँछन्, जसले स्वास्थ्य जाँच नियन्त्रकलाई स्रोतहरूको "जीवितता" जाँच गर्न कार्यहरू तोक्छ। त्यसले, फलस्वरूप, हेल्थचेक-नोडमा कार्यहरू तोक्छ र नतिजाहरू जम्मा गर्छ, त्यसपछि यसले तिनीहरूलाई ब्यालेन्सर नियन्त्रकमा फिर्ता पठाउँछ। Loadbalancer-node ले नियन्त्रकबाट घटनाहरूको सदस्यता लिन्छ र VPP को स्थिति परिवर्तन गर्दछ। यस्तो प्रणालीमा, प्रत्येक सेवालाई छिमेकी सेवाहरूको बारेमा के आवश्यक छ भनेर मात्र थाहा हुन्छ। जडानहरूको संख्या सीमित छ र हामीसँग स्वतन्त्र रूपमा विभिन्न खण्डहरू सञ्चालन र मापन गर्ने क्षमता छ।

कस्ता मुद्दाहरू बेवास्ता गरियो?

नियन्त्रण विमानमा हाम्रा सबै सेवाहरू Go मा लेखिएका छन् र राम्रो मापन र विश्वसनीयता विशेषताहरू छन्। Go सँग वितरण प्रणालीहरू निर्माण गर्नका लागि धेरै खुला स्रोत पुस्तकालयहरू छन्। हामी सक्रिय रूपमा GRPC प्रयोग गर्छौं, सबै कम्पोनेन्टहरूमा सेवा खोजको खुला स्रोत कार्यान्वयन हुन्छ - हाम्रा सेवाहरूले एकअर्काको कार्यसम्पादनलाई निगरानी गर्छन्, तिनीहरूको संरचना गतिशील रूपमा परिवर्तन गर्न सक्छन्, र हामीले यसलाई GRPC सन्तुलनसँग जोडेका छौं। मेट्रिक्सका लागि, हामी खुला स्रोत समाधान पनि प्रयोग गर्छौं। डाटा प्लेनमा, हामीले राम्रो प्रदर्शन र ठूलो स्रोत रिजर्भ पायौं: स्ट्यान्ड भेला गर्न धेरै गाह्रो भयो जहाँ हामी फलामको नेटवर्क कार्डको सट्टा VPP को प्रदर्शनमा भर पर्न सक्छौं।

समस्या र समाधान

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

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

माइक्रोसर्भिस घटना वास्तुकला एक मोनोलिथ भन्दा बढी जटिल छ: दर्जनौं विभिन्न मेसिनहरूमा लगहरू सङ्कलन धेरै सुविधाजनक छैन। निष्कर्ष: यदि तपाइँ माइक्रोसेवाहरू बनाउनुहुन्छ भने, तुरुन्तै ट्रेसिङको बारेमा सोच्नुहोस्।

हाम्रा योजनाहरू

हामी एक आन्तरिक ब्यालेन्सर, IPv6 ब्यालेन्सर सुरु गर्नेछौं, Kubernetes स्क्रिप्टहरूको लागि समर्थन थप्नेछौं, हाम्रा सेवाहरू शार्ड गर्न जारी राख्नेछौं (हाल मात्र स्वास्थ्य जाँच-नोड र स्वास्थ्य जाँच-ctrl शार्ड गरिएको छ), नयाँ स्वास्थ्य जाँचहरू थप्नेछौं, र चेकहरूको स्मार्ट एकत्रीकरण पनि लागू गर्नेछौं। हामी हाम्रा सेवाहरूलाई अझ बढी आत्मनिर्भर बनाउने सम्भावनालाई विचार गर्दैछौं - ताकि तिनीहरूले एकअर्कासँग सीधै सञ्चार नहोस्, तर सन्देश लाइन प्रयोग गरेर। एउटा SQS-कम्प्याटिबल सेवा हालै क्लाउडमा देखा परेको छ Yandex सन्देश लाइन.

हालै, Yandex लोड ब्यालेन्सर को सार्वजनिक रिलीज भयो। अन्वेषण गर्नुहोस् कागजात सेवामा, तपाईंको लागि सुविधाजनक तरिकामा ब्यालेन्सरहरू प्रबन्ध गर्नुहोस् र तपाईंको परियोजनाहरूको गल्ती सहिष्णुता बढाउनुहोस्!

स्रोत: www.habr.com