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

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

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

इस कहानी का एक वीडियो संस्करण, जिसका स्रोत ITSumma द्वारा आयोजित अपटाइम डे 4 सम्मेलन में एक रिपोर्ट था, को Uptime सामुदायिक YouTube चैनल पर देखा जा सकता है।

शारीरिक वास्तुकला का दोष सहिष्णुता

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

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

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

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

प्रदाता की विफलता की स्थिति में, हम स्वचालित रूप से अगले एक पर स्विच करते हैं। डेटा केंद्रों में से एक की विफलता के मामले में, हमारे पास दूसरे डेटा केंद्र में हमारी सेवाओं की मिरर कॉपी होती है, जो खुद पर सारा बोझ उठाती हैं।


भौतिक अवसंरचना लचीलापन

हम एप्लिकेशन-लेवल फॉल्ट टॉलरेंस के लिए क्या उपयोग करते हैं

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

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

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

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

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

स्टैंडर्ड ओपनस्टैक एप्लीकेशन आर्किटेक्चर

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

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

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

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

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

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


ओपनस्टैक एप्लीकेशन आर्किटेक्चर क्लाउड प्लेटफ़ॉर्म बैलेंसिंग और रेजिलेंसी

ExaBGP के साथ HAProxy Balancer Resilient बनाना

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

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

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

ExaBGP + HAProxy योजना

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

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

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

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


HAProxy के balancers के दोष सहिष्णुता

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

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

हमारे HAProxy से पहले लोड संतुलन का मुद्दा अनसुलझा रहा। फिर भी, यह काफी सरल रूप से हल किया जा सकता है, जैसा कि हमने घर पर किया था।

तीन सर्वरों को संतुलित करने के लिए, आपको 3 सफेद आईपी पते और एक अच्छे पुराने DNS की आवश्यकता होगी। इनमें से प्रत्येक पता प्रत्येक HAProxy के लूपबैक इंटरफेस पर परिभाषित किया गया है और इंटरनेट पर घोषित किया गया है।

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

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

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

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


HAProxy संतुलन डीएनएस + बीजीपी पर आधारित है

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

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

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

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


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

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

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

अलग-अलग संतुलन के तरीके हैं: सरल, जैसे कि राउंड-रॉबिन , और उन्नत, जब एक ग्राहक सत्र याद किया जाता है, और हर बार यह पहले के समान सर्वर पर पहुंच जाता है। हम दूसरा विकल्प लागू करना चाहते थे।

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

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

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

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

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

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


HAProxy साथियों (सत्र तुल्यकालन)

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

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

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

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

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

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

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

उपयोगकर्ताओं के लिए कोड आधार को सावधानी से कैसे अपडेट करें

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

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

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

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

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

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

इस पर तैनाती पूरी हो गई है।


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

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

निष्कर्ष

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

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

सभी स्थिर अपटाइम!