इस्तियो सर्किट ब्रेकर: दोषपूर्ण कंटेनरों को अक्षम करना

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

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

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

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

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

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

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

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

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

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

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

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

पूल इजेक्शन करने से पहले, आपको एक इस्तियो रूटिंग नियम बनाना होगा। मान लीजिए कि हम पॉड्स के बीच अनुरोधों को 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 सेकंड के बाद यह अपने आप पूल में वापस आ जाएगा। दरअसल, हमने अभी दिखाया कि पूल इजेक्शन कैसे काम करता है।

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

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

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

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

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

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

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

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

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

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

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

ऐसा करने के लिए, हम धीमे कंटेनरों पर कॉल को खत्म करने के लिए इस्तियो का उपयोग करेंगे। सर्किट ब्रेकर का उपयोग करने पर संबंधित कॉन्फ़िगरेशन इस तरह दिखता है:

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

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

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

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

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

स्रोत: www.habr.com