कैसे बिजली की कहानी अमेज़न बादल को मार डाला

जैसा कि हमारे एक साथी ने ट्वीट किया : "पांच साल पहले लिखो," बिजली गिरने से बादल गिरता है "और आपको एक बेवकूफ माना जाएगा।" लेकिन रविवार शाम को ठीक ऐसा ही हुआ - बिजली ट्रांसफार्मर में लगी , जिसने आयरलैंड के अमेज़ॅन डेटा सेंटर को पूरी तरह से ख़राब कर दिया। दुर्भाग्य से, 1C-Bitrix की साइटें इस डेटा केंद्र में स्थित थीं।



हम ईमानदारी से अपने सभी ग्राहकों और भागीदारों से माफी माँगते हैं जिन्होंने हमारी साइटों की अस्थायी अक्षमता के लिए किसी भी असुविधा का अनुभव किया हो सकता है।

और आज हम आपको इस घटना के बाद किए गए हमारे कार्यों और निष्कर्षों के बारे में "यह कैसा था" के बारे में बताना चाहते हैं।

पूरी कहानी "अमेज़ॅन की आंखों के माध्यम से" एक विशेष साइट पर उपलब्ध है जो आपको सभी अमेज़ॅन सेवाओं की स्थिति की निगरानी करने की अनुमति देती है

11:13 AM PDT हम ईयू-वेस्ट -1 क्षेत्र में कनेक्टिविटी मुद्दों की जांच कर रहे हैं। 11:27 AM EU-WEST-1 क्षेत्र में PDT EC2 API वर्तमान में बिगड़ा हुआ है। हम पूर्ण सेवा को बहाल करने के लिए काम कर रहे हैं। हम ऐसे उदाहरण कनेक्टिविटी की भी जांच कर रहे हैं, जिनका मानना ​​है कि हम एकल उपलब्धता क्षेत्र तक सीमित हैं।

दुर्घटना की रिकॉर्ड की गई शुरुआत 7 अगस्त (रविवार) को 21:13 (मास्को समय) पर हुई थी।

कर्म का पहला माइनस हम है - हमारे हिस्से के लिए, हमने समस्या की निगरानी नहीं की है। ऐसा क्यों हुआ?

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



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

पहला निष्कर्ष: आपको निगरानी की नकल करने की आवश्यकता है, इसके उद्देश्यों के लिए पूरी तरह से बाहरी संसाधनों का उपयोग करें।

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

9:36 PM पीडीटी अब हमने 75% प्रभावित उदाहरणों को वापस पा लिया है।

एक छोटा विषयांतर है कि अमेज़न की पुनर्प्राप्ति प्रक्रिया में इतना समय क्यों लगता है

वर्चुअल मशीन को खुद से उठाना इतनी बड़ी समस्या नहीं है। डिस्क के साथ स्थिति बदतर है। अमेज़ॅन के संदर्भ में, ये ईबीएस (इलास्टिक ब्लॉक स्टोर) हैं , कुछ वर्चुअल ब्लॉक डिवाइस जिन्हें नियमित डिस्क की तरह जोड़ा जा सकता है, उनमें से RAID व्यवस्थित करें आदि।

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

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

एक त्वरित लॉन्च विकल्प एक अलग डेटा सेंटर में एक नई वर्चुअल मशीन को अपग्रेड करना है, लेकिन एक ही उपलब्धता क्षेत्र में ।

ऐसा क्यों है और उपलब्धता क्षेत्र क्या है?

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

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

वहीं, आयरलैंड में तीन डेटा सेंटर हैं। हम उन्हें सशर्त रूप से ए, बी, सी कहते हैं।

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

(ठीक है, अगर हमें पहले ही इसे उठाने का अवसर मिल गया है, तो क्यों न इस पर एक साइट लॉन्च की जाए?)

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

1. हमने डेटा सेंटर B में एक नई मशीन खड़ी की - कॉन्फ़िगरेशन में समान।

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

• डेटा सेंटर ए में पुरानी मशीन से ड्राइव का स्नैपशॉट बनाया गया;
• एक डिस्क (वॉल्यूम) स्नैपशॉट से बनाया गया है, डेटा सेंटर बी में उपलब्ध है;
• नया ड्राइव डेटा सेंटर B में एक नई मशीन पर लगाया गया है।

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

3. अगला चरण मास्टर डेटा (सामग्री, डेटाबेस) का स्थानांतरण है। हमने उन्हें RAID-10 पर रखा है, जो गति और विश्वसनीयता दोनों प्रदान करता है।

और - समस्या। सभी छापे ड्राइव स्नैपशॉट नहीं करते हैं। हम व्यवस्थापक पैनल में छोटे और बहुत अधिक क्षमता वाले नहीं हैं: " आंतरिक त्रुटि "।

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

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

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

ऐसा लगता है कि खुशी पहले से ही निकट है ... हालाँकि, एक नई मशीन पर MySQL डेटा की प्रतिलिपि बनाते समय ... यह वही मशीन अब उपलब्ध नहीं थी।

यह लगभग 13: 00-13: 30 बजे था। विडंबना यह है कि लगभग उसी समय, एक और - काफी सकारात्मक - अमेज़न से अपडेट दिखाई दिया:

2:26 AM पीडीटी हम प्रभावित क्षेत्र में अतिरिक्त ईबीएस क्षमता ऑनलाइन लाए हैं, और हमने फिर से ईबीएस वॉल्यूम और ईबीएस समर्थित ईसी 2 इंस्टेंस को बहाल करना शुरू कर दिया है। हम अतिरिक्त क्षमता ऑनलाइन लाना जारी रख रहे हैं। जैसे ही हमारे पास नई जानकारी आएगी हम अपडेट पोस्ट करते रहेंगे।

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

हमने कभी भी डेटा सेंटर B में एक नई कार नहीं देखी ...

वैसे, वह अभी भी "निलंबित" स्थिति (स्थिति - रोक) के कुछ प्रकार में बनी हुई है:



13:30 बजे वसूली का अगला चरण शुरू हुआ - हमने डेटा सेंटर सी में एक नई कार खड़ी की।

ऊपर वर्णित 1-3 आइटम दोहराए गए थे। बिंदु 4 - सफलतापूर्वक पूरा हुआ।

5. MySQL डेटाबेस को स्लेव मोड से मास्टर मोड में स्विच करें।

6. सभी कॉन्फ़िगरेशन फ़ाइलों को ठीक किया, सभी सेवाओं को शुरू किया।

7. हमने साइट की जाँच की, और फिर एक्सटर्नल इलास्टिक आईपी (वास्तव में, जो पता www.1c-bitrix.ru को हल करता है ) को अमेज़ॅन एडमिन पैनल में नई मशीन पर स्विच कर दिया।

सोमवार दोपहर 3:30 बजे का समय था।

* * *

साइटों की अनुपलब्धता हमेशा अप्रिय होती है। हालाँकि, इस तरह की कष्टप्रद घटना के बावजूद, हमने इससे अधिकतम अनुभव निकालने और कई निष्कर्ष निकालने की कोशिश की।

1. कई लोगों ने सवाल पूछा: “ बादल ने आपकी मदद कैसे की? "

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

यदि हम वास्तविक भौतिक सर्वर पर किसी प्रकार के डेटा सेंटर में स्थित थे:

• यदि यह डेटा केंद्र डी-एनर्जेटिक होता, तो हमारे डेटा तक हमारी पहुंच नहीं होती। आम तौर पर। हम इसके उठने का इंतजार करेंगे।
• यदि आप प्रतीक्षा नहीं करना चाहते हैं, तो आपको बैकअप से डेटा लेना होगा। कौन सा? कैसे और कहाँ करना है? एक और डाटा सेंटर को?
• एक अच्छा सवाल यह है कि एक दुर्घटना के दौरान अन्य डेटा सेंटर को क्या स्थानांतरित करना है। हमारे द्वारा आवश्यक कॉन्फ़िगरेशन का सर्वर ढूंढना सबसे तुच्छ कार्य नहीं है। समय लगता है।
• हम चले गए। DNS को बदलना आवश्यक है। यह फिर से समय है।

हमें "क्लाउड" अवधारणा में कोई निराशा नहीं हुई।

2. एक और सवाल: “ आपके क्लस्टर ने आपकी मदद कैसे की? "

सबसे महत्वपूर्ण लाभ प्रासंगिक डेटा की उपलब्धता है।

उनके बिना, हम अमेज़ॅन में सेवा बहाल होने की प्रतीक्षा करेंगे (19:30 सोमवार तक, सभी सेवाओं का काम बहाल नहीं किया गया था, दूसरे डेटा सेंटर में जाने के लिए समान निर्देश, जो ऊपर वर्णित था, सभी उपयोगकर्ताओं के लिए प्रकाशित किया गया था; इस लेखन के समय तक; स्थिति पर घटना .aws.amazon.com बंद नहीं हुई थी - 39 घंटे बीत गए) या बैकअप से डेटा उठाया, नवीनतम परिवर्तन खो दिया (वे हमारी साइट के लिए महत्वपूर्ण हैं)।

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



इस समाधान के लिए समर्थन की घोषणा पिछले 1 सी-बिट्रिक्स भागीदार सम्मेलन में की गई थी । इसे 1C-बिट्रिक्स 10.5 प्लेटफॉर्म के अगले रिलीज में शामिल किया जाएगा, जो इस गिरावट को जारी करेगा।

तत्वों के रहस्योद्घाटन के लिए तैयार करें और विश्वास करें कि प्रकृति में खराब मौसम नहीं है। :)