बिट्रिक्स24: "जो जल्दी उठ जाता है उसे गिरा हुआ नहीं माना जाता"

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

“हमने 24 साल पहले Bitrix7 को SaaS के रूप में लॉन्च किया था। मुख्य कठिनाई शायद निम्नलिखित थी: SaaS के रूप में सार्वजनिक रूप से लॉन्च होने से पहले, यह उत्पाद केवल एक बॉक्स्ड समाधान के प्रारूप में मौजूद था। ग्राहकों ने इसे हमसे खरीदा, इसे अपने सर्वर पर होस्ट किया, एक कॉर्पोरेट पोर्टल स्थापित किया - कर्मचारी संचार, फ़ाइल भंडारण, कार्य प्रबंधन, सीआरएम, बस इतना ही के लिए एक सामान्य समाधान। और 2012 तक, हमने निर्णय लिया कि हम इसे SaaS के रूप में लॉन्च करना चाहते हैं, इसे स्वयं प्रशासित करना चाहते हैं, दोष सहनशीलता और विश्वसनीयता सुनिश्चित करना चाहते हैं। हमने रास्ते में अनुभव प्राप्त किया, क्योंकि तब तक हमारे पास यह नहीं था - हम केवल सॉफ्टवेयर निर्माता थे, सेवा प्रदाता नहीं।

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

SaaS के रूप में Bitrix.24

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

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

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

हमने विभिन्न क्लाउड ऑब्जेक्ट स्टोरेज के लिए उत्पाद स्तर पर समर्थन बनाया है: गूगल स्टोरेज, अमेज़ॅन एस3, साथ ही ओपन स्टैक स्विफ्ट के लिए समर्थन। इसलिए, यह एक सेवा के रूप में हमारे लिए और पैकेज्ड समाधान के साथ काम करने वाले डेवलपर्स दोनों के लिए सुविधाजनक था: यदि वे सिर्फ काम के लिए हमारे एपीआई का उपयोग करते हैं, तो वे इस बारे में नहीं सोचते हैं कि फ़ाइल अंततः कहाँ सहेजी जाएगी, स्थानीय रूप से फ़ाइल सिस्टम पर या ऑब्जेक्ट फ़ाइल भंडारण में।

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

वे जो चाहते थे वही उन्हें मिला...

सभी बुनियादी चीजें जो हम सुनिश्चित करना चाहते थे - स्वयं सर्वर की दोष सहनशीलता, वेब एप्लिकेशन, डेटाबेस - सब कुछ अच्छी तरह से काम किया। सबसे सरल परिदृश्य: यदि हमारा कोई वेब एप्लिकेशन विफल हो जाता है, तो सब कुछ सरल है - वे संतुलन से बंद हो जाते हैं।

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

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

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

क्या हमने सब कुछ आरक्षित कर लिया है?

हमारे पास संयुक्त राज्य अमेरिका से कई ग्राहक हैं, यूरोप से कई ग्राहक हैं, कई ग्राहक जो पूर्व के करीब हैं - जापान, सिंगापुर इत्यादि। बेशक, ग्राहकों का एक बड़ा हिस्सा रूस में है। यानी काम एक क्षेत्र में नहीं है. उपयोगकर्ता त्वरित प्रतिक्रिया चाहते हैं, विभिन्न स्थानीय कानूनों का अनुपालन करने की आवश्यकताएं हैं, और प्रत्येक क्षेत्र के भीतर हम दो डेटा केंद्र आरक्षित करते हैं, साथ ही कुछ अतिरिक्त सेवाएं भी हैं, जो, फिर से, एक क्षेत्र के भीतर रखने के लिए सुविधाजनक हैं - उन ग्राहकों के लिए जो इसमें हैं इस क्षेत्र में काम कर रहे हैं. REST हैंडलर, प्राधिकरण सर्वर, वे समग्र रूप से क्लाइंट के संचालन के लिए कम महत्वपूर्ण हैं, आप थोड़ी स्वीकार्य देरी के साथ उनके माध्यम से स्विच कर सकते हैं, लेकिन आप उनकी निगरानी कैसे करें और क्या करें, इस पर फिर से विचार नहीं करना चाहते हैं उनके साथ। इसलिए, हम अतिरिक्त उत्पादों में किसी प्रकार की क्षमता विकसित करने के बजाय मौजूदा समाधानों का अधिकतम उपयोग करने का प्रयास कर रहे हैं। और कहीं न कहीं हम DNS स्तर पर स्विचिंग का तुच्छ उपयोग करते हैं, और हम उसी DNS द्वारा सेवा की आजीविका निर्धारित करते हैं। अमेज़ॅन के पास रूट 53 सेवा है, लेकिन यह सिर्फ एक डीएनएस नहीं है जिसमें आप प्रविष्टियां कर सकते हैं और बस इतना ही - यह बहुत अधिक लचीला और सुविधाजनक है। इसके माध्यम से आप जियोलोकेशन के साथ जियो-वितरित सेवाओं का निर्माण कर सकते हैं, जब आप इसका उपयोग यह निर्धारित करने के लिए करते हैं कि ग्राहक कहां से आया है और उसे कुछ रिकॉर्ड देते हैं - इसकी मदद से आप फेलओवर आर्किटेक्चर का निर्माण कर सकते हैं। वही स्वास्थ्य-जाँच रूट 53 में ही कॉन्फ़िगर की गई हैं, आप उन अंतिम बिंदुओं को सेट करते हैं जिनकी निगरानी की जाती है, मेट्रिक्स सेट करते हैं, सेवा की "लाइवनेस" निर्धारित करने के लिए कौन से प्रोटोकॉल सेट करते हैं - टीसीपी, http, https; जांच की आवृत्ति निर्धारित करें जो यह निर्धारित करती है कि सेवा सक्रिय है या नहीं। और डीएनएस में ही आप निर्दिष्ट करते हैं कि क्या प्राथमिक होगा, क्या माध्यमिक होगा, यदि रूट 53 के अंदर स्वास्थ्य-जांच शुरू हो जाती है तो कहां स्विच करना है। यह सब कुछ अन्य उपकरणों के साथ किया जा सकता है, लेकिन यह सुविधाजनक क्यों है - हम इसे सेट करते हैं एक बार उठें और फिर इसके बारे में बिल्कुल भी न सोचें कि हम कैसे जांच करते हैं, हम कैसे स्विच करते हैं: सब कुछ अपने आप काम करता है।

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

दूसरा "लेकिन": इस चित्र में क्या अभी तक आरक्षित नहीं किया गया है? बैलेंसर ही! क्षेत्र के अनुसार ग्राहकों का हमारा वितरण बहुत सरल बना दिया गया है। हमारे पास डोमेन हैं bitrix24.ru, bitrix24.com, .de - अब 13 अलग-अलग हैं, जो विभिन्न क्षेत्रों में काम करते हैं। हम निम्नलिखित पर पहुंचे: प्रत्येक क्षेत्र के अपने स्वयं के बैलेंसर होते हैं। इससे नेटवर्क पर अधिकतम लोड कहां है, इसके आधार पर सभी क्षेत्रों में वितरण करना अधिक सुविधाजनक हो जाता है। यदि यह एकल बैलेंसर के स्तर पर विफलता है, तो इसे बस सेवा से बाहर कर दिया जाता है और डीएनएस से हटा दिया जाता है। यदि बैलेंसर्स के समूह में कुछ समस्या है, तो उन्हें अन्य साइटों पर बैकअप लिया जाता है, और उनके बीच स्विचिंग उसी रूट53 का उपयोग करके की जाती है, क्योंकि छोटे टीटीएल के कारण, स्विचिंग अधिकतम 2, 3, 5 मिनट के भीतर होती है .

तीसरा "लेकिन": क्या अभी तक आरक्षित नहीं है? S3, सही. जब हमने उपयोगकर्ताओं के लिए संग्रहीत फ़ाइलों को s3 में रखा, तो हमें ईमानदारी से विश्वास हुआ कि यह कवच-भेदी है और वहां कुछ भी आरक्षित करने की कोई आवश्यकता नहीं है। लेकिन इतिहास बताता है कि चीजें अलग तरह से होती हैं। सामान्य तौर पर, अमेज़ॅन S3 को एक मौलिक सेवा के रूप में वर्णित करता है, क्योंकि अमेज़ॅन स्वयं मशीन छवियों, कॉन्फ़िगरेशन, एएमआई छवियों, स्नैपशॉट को संग्रहीत करने के लिए S3 का उपयोग करता है... और यदि s3 क्रैश हो जाता है, जैसा कि इन 7 वर्षों के दौरान एक बार हुआ था, जब तक हम इसका उपयोग कर रहे हैं बिट्रिक्स24, यह एक प्रशंसक की तरह इसका अनुसरण करता है, इसमें बहुत सी चीजें सामने आती हैं - वर्चुअल मशीन शुरू करने में असमर्थता, एपीआई विफलता, और इसी तरह।

और S3 गिर सकता है - ऐसा एक बार हुआ था। इसलिए, हम निम्नलिखित योजना पर आए: कुछ साल पहले रूस में कोई गंभीर सार्वजनिक वस्तु भंडारण सुविधाएं नहीं थीं, और हमने अपना खुद का कुछ करने के विकल्प पर विचार किया... सौभाग्य से, हमने ऐसा करना शुरू नहीं किया, क्योंकि हम करेंगे हमने उस विशेषज्ञता को खोज निकाला है जो हमारे पास नहीं है, और संभवतः गड़बड़ हो जाएगी। अब Mail.ru के पास s3-संगत स्टोरेज है, Yandex के पास है, और कई अन्य प्रदाताओं के पास है। अंततः हमें यह विचार आया कि हम, सबसे पहले, बैकअप, और दूसरा, स्थानीय प्रतियों के साथ काम करने की क्षमता चाहते थे। विशेष रूप से रूसी क्षेत्र के लिए, हम Mail.ru Hotbox सेवा का उपयोग करते हैं, जो s3 के साथ API संगत है। हमें एप्लिकेशन के अंदर कोड में किसी बड़े संशोधन की आवश्यकता नहीं थी, और हमने निम्नलिखित तंत्र बनाया: s3 में ट्रिगर हैं जो ऑब्जेक्ट के निर्माण/हटाने को ट्रिगर करते हैं, अमेज़ॅन के पास लैम्ब्डा नामक एक सेवा है - यह कोड का सर्वर रहित लॉन्च है इसे तभी क्रियान्वित किया जाएगा जब कुछ निश्चित ट्रिगर ट्रिगर होंगे।

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

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

ओह, और अमेज़न भाग गया...

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

यदि कंपनी वैश्विक है और रूस उसके लिए एक बहुत छोटा खंड है, 3-5% - ठीक है, किसी भी तरह, आप उनका त्याग कर सकते हैं।

यदि यह एक विशुद्ध रूप से रूसी कंपनी है - मुझे यकीन है कि इसे स्थानीय रूप से स्थित होने की आवश्यकता है - ठीक है, यह उपयोगकर्ताओं के लिए स्वयं सुविधाजनक, आरामदायक होगी, और कम जोखिम होंगे।

क्या होगा यदि यह एक ऐसी कंपनी है जो विश्व स्तर पर काम करती है और जिसके रूस और दुनिया भर में लगभग समान संख्या में ग्राहक हैं? खंडों की कनेक्टिविटी महत्वपूर्ण है, और उन्हें एक या दूसरे तरीके से एक-दूसरे के साथ काम करना चाहिए।

मार्च 2018 के अंत में, रोसकोम्नाडज़ोर ने सबसे बड़े ऑपरेटरों को एक पत्र भेजा जिसमें कहा गया कि उन्होंने ज़ेलो मैसेंजर को ब्लॉक करने के लिए कई मिलियन अमेज़ॅन आईपी को ब्लॉक करने की योजना बनाई है। इन्हीं प्रदाताओं को धन्यवाद - उन्होंने सफलतापूर्वक सभी को पत्र लीक कर दिया, और ऐसी समझ थी कि अमेज़ॅन के साथ संबंध टूट सकता है। शुक्रवार का दिन था, हम घबराहट में अपने साथियों के पास सर्वर्स.आरयू से यह कहते हुए भागे: "दोस्तों, हमें कई सर्वरों की आवश्यकता है जो रूस में नहीं, अमेज़ॅन में नहीं, बल्कि, उदाहरण के लिए, एम्स्टर्डम में कहीं स्थित हों," क्रम में कम से कम किसी तरह से कुछ एंडपॉइंट्स के लिए अपना स्वयं का वीपीएन और प्रॉक्सी स्थापित करने में सक्षम होने के लिए जिन्हें हम किसी भी तरह से प्रभावित नहीं कर सकते हैं, उदाहरण के लिए उसी एस3 के एंडपोंट - हम एक नई सेवा बढ़ाने और एक अलग आईपी प्राप्त करने का प्रयास नहीं कर सकते हैं, हमें आपको अभी भी वहां पहुंचने की जरूरत है। कुछ ही दिनों में, हमने इन सर्वरों को स्थापित किया, उन्हें चालू किया और सामान्य तौर पर, उस क्षण के लिए तैयार किया जब अवरोध शुरू हुआ। मजे की बात है कि आरकेएन ने उपद्रव और घबराहट को देखते हुए कहा: "नहीं, अब हम कुछ भी अवरुद्ध नहीं करेंगे।" (लेकिन यह ठीक उस क्षण तक है जब टेलीग्राम को ब्लॉक किया जाना शुरू हुआ था।) बाईपास क्षमताओं को स्थापित करने और यह महसूस करने के बाद कि ब्लॉकिंग शुरू नहीं की गई थी, हमने, हालांकि, पूरे मामले को सुलझाना शुरू नहीं किया। हाँ, बस मामले में.

और 2019 में भी हम अवरोध की स्थिति में जी रहे हैं। मैंने कल रात देखा: लगभग दस लाख आईपी अभी भी अवरुद्ध हैं। सच है, अमेज़ॅन लगभग पूरी तरह से अनब्लॉक हो गया था, अपने चरम पर यह 20 मिलियन पतों तक पहुंच गया... सामान्य तौर पर, वास्तविकता यह है कि सुसंगतता, अच्छी सुसंगतता नहीं हो सकती है। अचानक। यह तकनीकी कारणों से अस्तित्व में नहीं हो सकता है - आग, उत्खनन, आदि। या, जैसा कि हमने देखा है, पूरी तरह से तकनीकी नहीं है। इसलिए, कोई बड़ा और बड़ा व्यक्ति, अपने स्वयं के एएस के साथ, संभवतः इसे अन्य तरीकों से प्रबंधित कर सकता है - प्रत्यक्ष कनेक्ट और अन्य चीजें पहले से ही एल 2 स्तर पर हैं। लेकिन एक सरल संस्करण में, हमारे जैसे या उससे भी छोटे, आप, बस मामले में, कहीं और उठाए गए सर्वर के स्तर पर अतिरेक कर सकते हैं, अग्रिम वीपीएन, प्रॉक्सी में कॉन्फ़िगर किया गया है, उन सेगमेंट में कॉन्फ़िगरेशन को जल्दी से स्विच करने की क्षमता के साथ जो आपकी कनेक्टिविटी के लिए महत्वपूर्ण हैं। यह हमारे लिए एक से अधिक बार काम आया, जब अमेज़ॅन का अवरोधन शुरू हुआ; सबसे खराब स्थिति में, हमने केवल उनके माध्यम से S3 ट्रैफ़िक की अनुमति दी, लेकिन धीरे-धीरे यह सब हल हो गया।

कैसे आरक्षित करें... एक संपूर्ण प्रदाता?

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

काल्पनिक रूप से, अमेज़ॅन के लिए हम किसी अन्य प्रदाता के स्तर पर आरक्षण की संभावना पर विचार कर रहे हैं; शायद Google, शायद कोई और... लेकिन अब तक हमने व्यवहार में देखा है कि जहां अमेज़ॅन में एक उपलब्धता क्षेत्र के स्तर पर दुर्घटनाएं होती हैं, वहीं पूरे क्षेत्र के स्तर पर दुर्घटनाएं काफी दुर्लभ होती हैं। इसलिए, सैद्धांतिक रूप से हमारा विचार है कि हम "अमेज़ॅन अमेज़ॅन नहीं है" आरक्षण दे सकते हैं, लेकिन व्यवहार में यह अभी तक मामला नहीं है।

स्वचालन के बारे में कुछ शब्द

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

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

निष्कर्ष

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

पूर्णतावाद और वास्तविक प्रयास, समय, धन के बीच एक उचित समझौता जिसे आप उस योजना पर खर्च कर सकते हैं जो अंततः आपके पास होगी।

यह पाठ सम्मेलन में अलेक्जेंडर डेमिडोव की रिपोर्ट का एक अद्यतन और विस्तारित संस्करण है अपटाइम दिन 4.

स्रोत: www.habr.com