इस्तियो सर्किट ब्रेकर: टूटे हुए कंटेनरों को डिस्कनेक्ट करें

छुट्टियां खत्म हो गई हैं और हम अपने दूसरे पोस्ट के साथ इस्तियो सर्विस मेष श्रृंखला में लौट रहे हैं।



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

यह आदर्श रूप से कैसे काम करना चाहिए

जब माइक्रोसेबल्स को कुबरनेट द्वारा प्रबंधित किया जाता है, उदाहरण के लिए, ओपनशिफ्ट प्लेटफॉर्म के हिस्से के रूप में, वे लोड के आधार पर स्वचालित रूप से ऊपर और नीचे स्केल करते हैं। चूँकि microservices फली में काम करते हैं, इसलिए एक समापन बिंदु पर कंटेनरीकृत microservice के कई उदाहरण हो सकते हैं, और Kubernetes अनुरोधों को रूट करेगा और उनके बीच लोड को संतुलित करेगा। और - आदर्श रूप से - यह सब पूरी तरह से काम करना चाहिए।

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

यह वास्तव में कैसे काम करता है

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

इस्तियो में पूल इजेक्शन क्या है

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

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

यह दिखाने के लिए कि OpenShift प्लेटफ़ॉर्म पर कुबेरनेट्स में यह कैसे काम करता है, हम Red Hat डेवलपर डीमोस रिपॉजिटरी में उदाहरण से सामान्य रूप से काम करने वाले माइक्रोसिस्टर्स के स्क्रीनशॉट के साथ शुरू करते हैं। यहां हमारे पास दो पॉड, v1 और v2 हैं, जिनमें से प्रत्येक में एक कंटेनर काम करता है। जब Istio के रूटिंग नियमों का उपयोग नहीं किया जाता है, तो डिफ़ॉल्ट रूप से Kubernetes समान रूप से संतुलित राउंड-रॉबिन रूटिंग लागू करता है:

एक दुर्घटना के लिए तैयार हो रही है

पूल इजेक्शन करने से पहले, आपको एक Istio रूटिंग नियम बनाना होगा। मान लीजिए कि हम फली के बीच अनुरोध 50/50 के संबंध में वितरित करना चाहते हैं। इसके अलावा, हम v2 कंटेनरों की संख्या को एक से दो तक बढ़ाएंगे, जैसे:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial 

अब हम एक रूटिंग नियम को परिभाषित करते हैं ताकि 50/50 के अनुपात में पॉड्स के बीच ट्रैफ़िक वितरित किया जाए।


और यहाँ इस नियम का परिणाम है:


यह शिकायत करना संभव है कि इस स्क्रीन पर यह 50/50 नहीं, 14: 9 है, लेकिन समय के साथ स्थिति में सुधार होगा।

हम एक विफलता की व्यवस्था करते हैं

और अब हम दो v2 कंटेनरों में से एक को निष्क्रिय कर देंगे ताकि हमारे पास एक स्वस्थ कंटेनर v1 हो, एक स्वस्थ कंटेनर v2 और एक असफल v2 कंटेनर:

क्रैश को ठीक करें

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



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

वास्तुकला का निर्माण शुरू करें

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

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

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

इसके अलावा, दूसरे मामले में केवल और अधिक समस्याएं हैं, क्योंकि एक कंटेनर के ब्रेक न केवल इसे पहुंचाने वाली सेवाओं में देरी का एक झरना का कारण बनता है और, परिणामस्वरूप, एक पूरे के रूप में सिस्टम के प्रदर्शन को कम करता है, लेकिन पहले से ही धीमी गति से चलने वाली सेवा के लिए बार-बार अनुरोध का कारण बनता है, जो केवल स्थिति को तेज करता है। ।

सिद्धांत में सर्किट ब्रेकर

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


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

व्यवहार में सर्किट ब्रेकर

उदाहरण के लिए, हम अपनी सिफारिशों के दो संस्करणों ओपनशफ्ट को लॉन्च करेंगे। संस्करण 1 ठीक काम करेगा, लेकिन v2 में हम सर्वर पर ब्रेक का अनुकरण करने में देरी करेंगे। परिणाम देखने के लिए, घेराबंदी उपकरण का उपयोग करें:

 siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io 

सब कुछ काम करने लगता है, लेकिन किस कीमत पर? पहली नज़र में, हमारे पास 100% उपलब्धता है, लेकिन एक करीब से देखें - अधिकतम लेन-देन की अवधि 12 सेकंड जितनी है। यह स्पष्ट रूप से एक अड़चन है और इसे कढ़ाई करने की आवश्यकता है।

ऐसा करने के लिए, हम धीमी गति से कंटेनरों तक पहुंच को खत्म करने के लिए इस्तियो का उपयोग करेंगे। यहां सर्किट ब्रेकर का उपयोग करने के लिए इसी विन्यास जैसा दिखता है:


HttpMaxRequestsPerConnection पैरामीटर सिग्नल के साथ अंतिम पंक्ति यह बताती है कि मौजूदा एक के अलावा एक और कनेक्शन बनाने की कोशिश करते समय कनेक्शन को खोलना चाहिए। चूंकि हमारा कंटेनर एक ब्रेकिंग सेवा की नकल करता है, इसलिए ऐसी स्थितियां समय-समय पर होती रहेंगी, और फिर इस्तियो में 503 त्रुटि होगी, और यहाँ वह है जो घेराबंदी दिखाएगा:

ठीक है, हमारे पास सर्किट ब्रेकर है, आगे क्या है?

इसलिए, हमने स्वयं सेवाओं के स्रोत कोड को छूने के बिना, एक स्वचालित शटडाउन लागू किया। सर्किट ब्रेकर और ऊपर वर्णित पूल इजेक्शन प्रक्रिया का उपयोग करते हुए, हम ब्रेक कंटेनर को रिसोर्स पूल से हटा सकते हैं जब तक कि वे सामान्य नहीं हो जाते, और किसी दिए गए आवृत्ति पर उनकी स्थिति की जांच करें - हमारे उदाहरण में, यह दो मिनट (स्लीपवॉन्ड पैरामीटर) है।

कृपया ध्यान दें कि 503 त्रुटि का जवाब देने के लिए आवेदन की क्षमता अभी भी अपने स्रोत कोड के स्तर पर सेट है। सर्किट ब्रेकर के साथ काम करने के लिए कई रणनीतियाँ हैं, जो स्थिति के आधार पर लागू की जाती हैं।

अगली पोस्ट में: हम ट्रेसिंग और मॉनिटरिंग के बारे में बात करेंगे, जो पहले से ही अंतर्निहित हैं या आसानी से इस्तियो में जोड़ दिए गए हैं, साथ ही सिस्टम में त्रुटियों को जानबूझकर कैसे पेश किया जाए।