Mail.ru क्लाउड सॉल्यूशंस प्लेटफ़ॉर्म में दोष-सहिष्णु वेब आर्किटेक्चर कैसे कार्यान्वित किया जाता है

नमस्ते, हबर! मैं सिस्टम एडमिनिस्ट्रेशन टीम का प्रमुख आर्टेम करामीशेव हूं Mail.Ru क्लाउड सॉल्यूशंस (MCS). पिछले साल हमने कई नए उत्पाद लॉन्च किए हैं। हम यह सुनिश्चित करना चाहते थे कि एपीआई सेवाएं आसानी से स्केलेबल, दोष-सहिष्णु और उपयोगकर्ता भार में तेजी से वृद्धि के लिए तैयार हों। हमारा प्लेटफ़ॉर्म ओपनस्टैक पर लागू किया गया है, और मैं आपको बताना चाहता हूं कि दोष-सहिष्णु प्रणाली प्राप्त करने के लिए हमें कौन से घटक दोष सहिष्णुता समस्याओं को हल करना होगा। मुझे लगता है कि यह उन लोगों के लिए दिलचस्प होगा जो ओपनस्टैक पर भी उत्पाद विकसित करते हैं।

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

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

भौतिक वास्तुकला का लचीलापन

एमसीएस क्लाउड का सार्वजनिक हिस्सा अब दो टियर III डेटा केंद्रों पर आधारित है, उनके बीच अपना स्वयं का डार्क फाइबर है, जो 200 Gbit/s के थ्रूपुट के साथ विभिन्न मार्गों द्वारा भौतिक स्तर पर आरक्षित है। टियर III भौतिक बुनियादी ढांचे के लिए आवश्यक स्तर की दोष सहनशीलता प्रदान करता है।

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

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

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

यदि कोई प्रदाता विफल हो जाता है, तो हम स्वचालित रूप से अगले पर स्विच कर देते हैं। किसी एक डेटा सेंटर के विफल होने की स्थिति में, हमारे पास दूसरे डेटा सेंटर में हमारी सेवाओं की एक मिरर कॉपी होती है, जो पूरा भार अपने ऊपर ले लेती है।

भौतिक बुनियादी ढांचे का लचीलापन

हम एप्लिकेशन-स्तरीय दोष सहनशीलता के लिए क्या उपयोग करते हैं

हमारी सेवा कई ओपनसोर्स घटकों पर बनी है।

ExaBGP एक ऐसी सेवा है जो बीजीपी-आधारित डायनेमिक रूटिंग प्रोटोकॉल का उपयोग करके कई कार्यों को कार्यान्वित करती है। हम सक्रिय रूप से इसका उपयोग अपने श्वेतसूची वाले आईपी पते का विज्ञापन करने के लिए करते हैं जिसके माध्यम से उपयोगकर्ता एपीआई तक पहुंचते हैं।

HAProxy एक उच्च-लोड बैलेंसर है जो आपको OSI मॉडल के विभिन्न स्तरों पर बहुत लचीले ट्रैफ़िक संतुलन नियमों को कॉन्फ़िगर करने की अनुमति देता है। हम इसका उपयोग सभी सेवाओं के सामने संतुलन बनाने के लिए करते हैं: डेटाबेस, संदेश ब्रोकर, एपीआई सेवाएं, वेब सेवाएं, हमारी आंतरिक परियोजनाएं - सब कुछ HAProxy के पीछे है।

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

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

मानक ओपनस्टैक एप्लिकेशन आर्किटेक्चर

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

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

कार्यकर्ता अनुप्रयोगों की संख्या असीमित है, इसलिए प्रदर्शन और दोष सहनशीलता को बढ़ाने के लिए एपीआई आसानी से बैलेंसर्स के पीछे क्षैतिज रूप से स्केल कर सकता है।

जब एपीआई और श्रमिकों के बीच जटिल अनुक्रमिक संचालन होते हैं तो कुछ सेवाओं को सेवा के भीतर समन्वय की आवश्यकता होती है। इस मामले में, एक एकल समन्वय केंद्र का उपयोग किया जाता है, एक क्लस्टर सिस्टम जैसे कि रेडिस, मेमकेचे, आदि, जो एक कार्यकर्ता को दूसरे को यह बताने की अनुमति देता है कि यह कार्य उसे सौंपा गया है ("कृपया इसे न लें")। हम आदि का उपयोग करते हैं। एक नियम के रूप में, कार्यकर्ता सक्रिय रूप से डेटाबेस के साथ संवाद करते हैं, वहां से जानकारी लिखते और पढ़ते हैं। हम mariadb को एक डेटाबेस के रूप में उपयोग करते हैं, जो एक मल्टीमास्टर क्लस्टर में स्थित है।

यह क्लासिक एकल सेवा ओपनस्टैक के लिए आम तौर पर स्वीकृत तरीके से व्यवस्थित की जाती है। इसे एक बंद प्रणाली के रूप में माना जा सकता है, जिसके लिए स्केलिंग और दोष सहनशीलता के तरीके काफी स्पष्ट हैं। उदाहरण के लिए, एपीआई दोष सहनशीलता के लिए, उनके सामने एक बैलेंसर रखना पर्याप्त है। स्केलिंग श्रमिकों की संख्या बढ़ाकर हासिल की जाती है।

पूरी योजना में कमजोर बिंदु RabbitMQ और MariaDB हैं। उनका आर्किटेक्चर एक अलग लेख का हकदार है। इस लेख में मैं एपीआई दोष सहिष्णुता पर ध्यान केंद्रित करना चाहता हूं।

ओपनस्टैक एप्लिकेशन आर्किटेक्चर। क्लाउड प्लेटफ़ॉर्म का संतुलन और दोष सहनशीलता

ExaBGP का उपयोग करके HAProxy बैलेंसर को दोष-सहिष्णु बनाना

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

पहली समस्या जिसे हल करने की आवश्यकता थी वह थी बैलेंसर की दोष सहनशीलता। बस एक बैलेंसर स्थापित करने से भी विफलता का एक बिंदु बन जाता है: बैलेंसर टूट जाता है और सेवा क्रैश हो जाती है। ऐसा होने से रोकने के लिए, हमने ExaBGP के साथ मिलकर HAProxy का उपयोग किया।

ExaBGP आपको किसी सेवा की स्थिति की जाँच के लिए एक तंत्र लागू करने की अनुमति देता है। हमने HAProxy की कार्यक्षमता की जांच करने के लिए इस तंत्र का उपयोग किया और, समस्याओं के मामले में, BGP से HAProxy सेवा को अक्षम कर दिया।

ExaBGP+HAProxy योजना

1. हम तीन सर्वरों पर आवश्यक सॉफ़्टवेयर, ExaBGP और HAProxy स्थापित करते हैं।
2. हम प्रत्येक सर्वर पर एक लूपबैक इंटरफ़ेस बनाते हैं।
3. सभी तीन सर्वरों पर हम इस इंटरफ़ेस को एक ही सफेद आईपी पता निर्दिष्ट करते हैं।
4. ExaBGP के माध्यम से इंटरनेट पर एक सफ़ेद IP पता विज्ञापित किया जाता है।

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

HAProxy के संचालन में समस्या या सर्वर विफलता के मामले में, ExaBGP रूट की घोषणा करना बंद कर देता है, और ट्रैफ़िक आसानी से दूसरे सर्वर पर स्विच हो जाता है।

इस प्रकार, हमने बैलेंसर की दोष सहनशीलता हासिल कर ली।

HAProxy बैलेंसर्स की दोष सहनशीलता

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

डीएनएस प्लस बीजीपी पर आधारित संतुलन

हमारे HAProxy के लिए लोड संतुलन का मुद्दा अनसुलझा है। हालाँकि, इसे काफी सरलता से हल किया जा सकता है, जैसा कि हमने यहां किया।

तीन सर्वरों को संतुलित करने के लिए आपको 3 सफेद आईपी पते और अच्छे पुराने डीएनएस की आवश्यकता होगी। इनमें से प्रत्येक पता प्रत्येक HAProxy के लूपबैक इंटरफ़ेस पर निर्धारित किया जाता है और इंटरनेट पर विज्ञापित किया जाता है।

ओपनस्टैक में, संसाधनों को प्रबंधित करने के लिए, एक सेवा निर्देशिका का उपयोग किया जाता है, जो किसी विशेष सेवा के एंडपॉइंट एपीआई को निर्दिष्ट करता है। इस निर्देशिका में हम एक डोमेन नाम पंजीकृत करते हैं - public.infra.mail.ru, जिसे DNS के माध्यम से तीन अलग-अलग आईपी पतों द्वारा हल किया जाता है। परिणामस्वरूप, हमें DNS के माध्यम से तीन पतों के बीच लोड वितरण मिलता है।

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

हमने विभिन्न मेट्रिक्स के साथ ExaBGP के माध्यम से रूट भेजना शुरू किया। प्रत्येक बैलेंसर सभी तीन सफेद आईपी पते का विज्ञापन करता है, लेकिन उनमें से एक, इस बैलेंसर के लिए मुख्य, न्यूनतम मीट्रिक के साथ विज्ञापित किया जाता है। इसलिए जब सभी तीन बैलेंसर चालू होते हैं, तो पहले आईपी पते पर कॉल पहले बैलेंसर पर जाती है, दूसरे पर कॉल दूसरे पर, और तीसरे पर कॉल तीसरे पर जाती है।

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

DNS + BGP पर आधारित HAProxy को संतुलित करना

ExaBGP और HAProxy के बीच सहभागिता

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

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

ऐसा करने के लिए, आपको ExaBGP कॉन्फ़िगरेशन में एक स्वास्थ्य जांचकर्ता को कॉन्फ़िगर करना होगा, जो HAProxy की स्थिति की जांच कर सकता है। हमारे मामले में, हमने HAProxy में स्वास्थ्य बैकएंड को कॉन्फ़िगर किया है, और ExaBGP की ओर से हम एक साधारण GET अनुरोध के साथ जांच करते हैं। यदि घोषणा होना बंद हो जाती है, तो संभवतः HAProxy काम नहीं कर रहा है और इसका विज्ञापन करने की कोई आवश्यकता नहीं है।

HAProxy स्वास्थ्य जांच

HAProxy पीयर्स: सत्र सिंक्रनाइज़ेशन

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

विभिन्न संतुलन विधियाँ हैं: सरल विधियाँ जैसे राउंड रोबिन, और विस्तारित, जब ग्राहक का सत्र याद किया जाता है, और हर बार वह पहले की तरह उसी सर्वर पर समाप्त होता है। हम दूसरा विकल्प लागू करना चाहते थे.

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

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

उचित संचालन के लिए, बैलेंसर के स्रोत आईपी पते की समस्या जिससे सत्र स्थापित किया गया था, का समाधान किया जाना चाहिए। हमारे मामले में, यह लूपबैक इंटरफ़ेस पर एक गतिशील पता है।

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

IaaS में हमारे पास उसी तकनीक का उपयोग करके निर्मित एक सेवा है। यह ओपनस्टैक के लिए एक सेवा के रूप में लोड बैलेंसर, जिसे ऑक्टेविया कहा जाता है। यह दो HAProxy प्रक्रियाओं पर आधारित है और प्रारंभ में इसमें साथियों के लिए समर्थन शामिल है। उन्होंने इस सेवा में स्वयं को उत्कृष्ट साबित किया है।

चित्र योजनाबद्ध रूप से तीन HAProxy उदाहरणों के बीच सहकर्मी तालिकाओं की गति को दर्शाता है, इसे कैसे कॉन्फ़िगर किया जा सकता है, इस पर एक कॉन्फ़िगरेशन प्रस्तावित है:

HAProxy पीयर्स (सत्र सिंक्रनाइज़ेशन)

यदि आप समान योजना लागू करते हैं, तो इसके संचालन का सावधानीपूर्वक परीक्षण किया जाना चाहिए। यह सच नहीं है कि यह 100% समय उसी तरह काम करेगा। लेकिन जब आपको क्लाइंट के स्रोत आईपी को याद रखने की आवश्यकता होगी तो कम से कम आप स्टिक टेबल नहीं खोएंगे।

एक ही ग्राहक से एक साथ अनुरोधों की संख्या सीमित करना

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

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

ऐसे प्रतिबंधों को लागू करने के लिए, हम समान स्टिक तालिकाओं का उपयोग करके, HAProxy के आधार पर व्यवस्थित दर सीमाओं का उपयोग करते हैं। सीमाएँ निर्धारित करना काफी सरल है और आपको एपीआई के अनुरोधों की संख्या के आधार पर उपयोगकर्ता को सीमित करने की अनुमति देता है। एल्गोरिदम उस स्रोत आईपी को याद रखता है जिससे अनुरोध किए जाते हैं और एक उपयोगकर्ता से एक साथ अनुरोधों की संख्या को सीमित करता है। बेशक, हमने प्रत्येक सेवा के लिए औसत एपीआई लोड प्रोफ़ाइल की गणना की और इस मान से ≈ 10 गुना की सीमा निर्धारित की। हम स्थिति पर बारीकी से नजर रखना जारी रखते हैं और अपनी उंगली नाड़ी पर रखते हैं।

व्यवहार में यह कैसा दिखता है? हमारे पास ऐसे ग्राहक हैं जो हर समय हमारे ऑटोस्केलिंग एपीआई का उपयोग करते हैं। वे सुबह लगभग दो से तीन सौ वर्चुअल मशीनें बनाते हैं और शाम को उन्हें हटा देते हैं। ओपनस्टैक के लिए, PaaS सेवाओं के साथ एक वर्चुअल मशीन बनाने के लिए कम से कम 1000 एपीआई अनुरोधों की आवश्यकता होती है, क्योंकि सेवाओं के बीच बातचीत भी एपीआई के माध्यम से होती है।

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

उपयोगकर्ताओं को ध्यान दिए बिना अपना कोडबेस कैसे अपडेट करें

हम कोड परिनियोजन प्रक्रियाओं के स्तर पर दोष सहनशीलता भी लागू करते हैं। रोलआउट के दौरान गड़बड़ियाँ हो सकती हैं, लेकिन सेवा उपलब्धता पर उनके प्रभाव को कम किया जा सकता है।

हम अपनी सेवाओं को लगातार अपडेट करते हैं और यह सुनिश्चित करना चाहिए कि उपयोगकर्ताओं को प्रभावित किए बिना कोडबेस अपडेट किया जाए। हम HAProxy की प्रबंधन क्षमताओं और अपनी सेवाओं में ग्रेसफुल शटडाउन के कार्यान्वयन का उपयोग करके इस समस्या को हल करने में कामयाब रहे।

इस समस्या को हल करने के लिए, बैलेंसर का नियंत्रण और सेवाओं का "सही" शटडाउन सुनिश्चित करना आवश्यक था:

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

इन दो बिंदुओं के लिए धन्यवाद, हमारी तैनाती के लिए सुरक्षित एल्गोरिदम इस तरह दिखता है।

1. डेवलपर कोड का एक नया पैकेज असेंबल करता है (हमारे लिए यह आरपीएम है), इसे देव वातावरण में परीक्षण करता है, स्टेज में इसका परीक्षण करता है, और इसे स्टेज रिपॉजिटरी में छोड़ देता है।
2. डेवलपर "कलाकृतियों" के सबसे विस्तृत विवरण के साथ तैनाती के लिए कार्य निर्धारित करता है: नए पैकेज का संस्करण, नई कार्यक्षमता का विवरण और यदि आवश्यक हो तो तैनाती के बारे में अन्य विवरण।
3. सिस्टम व्यवस्थापक अद्यतन प्रारंभ करता है. Ansible प्लेबुक लॉन्च करता है, जो बदले में निम्नलिखित कार्य करता है:
   • स्टेज रिपॉजिटरी से एक पैकेज लेता है और उत्पाद रिपॉजिटरी में पैकेज के संस्करण को अपडेट करने के लिए इसका उपयोग करता है।
   • अद्यतन सेवा के बैकएंड की एक सूची संकलित करता है।
   • HAProxy में अद्यतन की जाने वाली पहली सेवा को बंद कर देता है और इसकी प्रक्रियाओं के चलने की प्रतीक्षा करता है। शालीन शटडाउन के लिए धन्यवाद, हमें विश्वास है कि सभी मौजूदा ग्राहक अनुरोध सफलतापूर्वक पूरे हो जाएंगे।
   • एपीआई और वर्कर्स पूरी तरह से बंद होने और HAProxy बंद होने के बाद, कोड अपडेट किया जाता है।
   • अन्सिबल सेवाएँ चलाता है।
   • प्रत्येक सेवा के लिए, कुछ "हैंडल" खींचे जाते हैं, जो कई पूर्व-निर्धारित कुंजी परीक्षणों पर इकाई परीक्षण करते हैं। नए कोड की बुनियादी जांच होती है.
   • यदि पिछले चरण में कोई त्रुटि नहीं पाई गई, तो बैकएंड सक्रिय हो जाता है।
   • चलिए अगले बैकएंड पर चलते हैं।
4. सभी बैकएंड अपडेट होने के बाद, कार्यात्मक परीक्षण लॉन्च किए जाते हैं। यदि वे गायब हैं, तो डेवलपर अपने द्वारा बनाई गई किसी भी नई कार्यक्षमता को देखता है।

यह परिनियोजन पूरा करता है.

सेवा अद्यतन चक्र

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

निष्कर्ष

दोष-सहिष्णु वेब आर्किटेक्चर के बारे में अपने विचार साझा करते हुए, मैं एक बार फिर इसके मुख्य बिंदुओं पर ध्यान देना चाहूंगा:

• शारीरिक दोष सहनशीलता;
• नेटवर्क दोष सहिष्णुता (बैलेंसर, बीजीपी);
• उपयोग किए गए और विकसित किए गए सॉफ़्टवेयर की दोष सहनशीलता।

सभी के लिए स्थिर अपटाइम!

स्रोत: www.habr.com