👥 📛 🤤 24-25 सितंबर सेवाओं के काम में समस्याएं ➕ 🤞🏾 🍋

सबसे पहले, हम Selectel के इतिहास में सबसे बड़ी गिरावट के लिए माफी चाहते हैं। नीचे हम विस्तार से घटनाओं के कालक्रम को पुनर्स्थापित करने का प्रयास करेंगे, इस बारे में बात करेंगे कि भविष्य में ऐसी स्थितियों को रोकने के लिए क्या किया गया है, साथ ही इन खराबी से प्रभावित ग्राहकों के लिए क्षतिपूर्ति के बारे में भी।

पहली गड़बड़

समस्याएं सोमवार शाम को शुरू हुईं, 24 सितंबर ( डाउनटाइम 22:00 - 23:10 )। बाहर से, यह नेटवर्क के सेंट पीटर्सबर्ग खंड के साथ कनेक्टिविटी की हानि की तरह लग रहा था। इस विफलता ने सेंट पीटर्सबर्ग में हमारी सभी इंटरनेट सेवाओं में समस्याएं पैदा कीं; मॉस्को नेटवर्क खंड, साथ ही साथ स्थानीय सर्वर पोर्ट भी काम करते रहे। साथ ही, सेंट पीटर्सबर्ग में स्थित DNS (ns1.selectel.org और ns2.selectel.org) अनुपलब्ध थे, मास्को DNS (ns3.selectel.org) ने इस विफलता को चोट नहीं पहुंचाई। कनेक्टिविटी की कमी के कारण, साइट तक पहुंच और नियंत्रण कक्ष गायब हो गया, मुख्य भार टेलीफोनी पर गिर गया, जिसके संबंध में कई ग्राहक जवाब के लिए इंतजार नहीं कर सकते थे।

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

 24 सितंबर 22:02:02 चेसिस [903]: CM_TSUNAMI: i2c रजिस्टर पर पढ़ा (56 विफल)
 24 सितंबर 22:02:02 चेसिस [903]: cm_read_i2c इरनो: 16, डिवाइस: 292

वास्तव में, एकत्रीकरण स्तर स्विच चेसिस पर सभी ऑप्टिकल 10 जी ईथरनेट बंदरगाहों ने काम करना बंद कर दिया।

 24 सितंबर 22:01:49 चेसिसड [952]: CHASSISD_IFDEV_DETACH_PIC: ifdev_detach_pic (0/3)
 24 सितंबर 22:01:49 craftd [954]: माइनर अलार्म सेट, FPC 0 PEM 0 निकाला गया
 24 सितंबर 22:01:49 craftd [954]: माइनर अलार्म सेट, FPC 0 PEM 1 निकाला गया

रिबूट के बाद, सब कुछ stably काम किया। चूंकि नेटवर्क कॉन्फ़िगरेशन लंबे समय तक नहीं बदला था, और दुर्घटना से पहले कोई काम नहीं किया गया था, इसलिए हमने इसे एक बार की समस्या माना। दुर्भाग्य से, केवल 45 मिनट के बाद, इन समान स्विचों ने फिर से जवाब देना बंद कर दिया, और फिर से रिबूट किया गया ( 23:55 - 00:05 )।

आभासी चेसिस में कम स्विच प्राथमिकता

चूंकि दोनों मामलों में वर्चुअल चेसिस में दो स्विच में से एक फेल होने वाला पहला था, और दूसरे के बाद दूसरे ने काम करना बंद कर दिया, यह माना गया कि समस्या इसमें थी। वर्चुअल चेसिस को फिर से जोड़ा गया ताकि दूसरा स्विच मुख्य हो जाए, और दूसरा केवल एक रिजर्व के रूप में बना रहे। संचालन के बीच, स्विच फिर से रिबूट किए गए ( 00:40 - 00:55 )

वर्चुअल चेसिस को ध्वस्त कर दिया गया है, सभी लिंक एक स्विच में स्थानांतरित किए गए हैं

लगभग एक घंटे के बाद, एक और विफलता से पता चला कि प्रदर्शन किए गए कार्य पर्याप्त नहीं थे। पोर्ट क्षमता का हिस्सा जारी करने और सील करने के बाद, हमने वर्चुअल चेसिस से विफल डिवाइस को पूरी तरह से डिस्कनेक्ट करने और सभी लिंक को "स्वस्थ" स्विच में स्थानांतरित करने का निर्णय लिया। लगभग 4:30 बजे तक यह किया गया था ( 02:28 - 03:01, 03:51 - 04:30 )।

एक स्पेयर के साथ स्विच की जगह

हालांकि, एक घंटे के बाद, इस स्विच ने काम करना भी बंद कर दिया। जब वह अभी भी काम कर रहा था, ठीक उसी तरह से बिल्कुल नया स्विच रिजर्व से लिया गया, स्थापित और कॉन्फ़िगर किया गया। सभी ट्रैफ़िक को इसमें स्थानांतरित कर दिया गया था। कनेक्टिविटी दिखाई दी है - नेटवर्क कमाया है ( 05:30 - 06:05 )

JunOS अपडेट

3 घंटे के बाद, लगभग 9 बजे, सब कुछ फिर से दोहराया। हमने स्विच पर ऑपरेटिंग सिस्टम (JunOS) के एक अलग संस्करण को स्थापित करने का निर्णय लिया। अद्यतन के बाद, सब कुछ काम किया ( 08:44 - 09:01 )

डेटा केंद्रों के बीच तंतुओं का टूटना

12:00 के करीब सभी क्लाउड सर्वर शुरू किए गए थे। लेकिन 12:45 पर, केबल में ऑप्टिकल सिग्नल को नुकसान हुआ, जो विभिन्न डेटा केंद्रों में नेटवर्क सेगमेंट से जुड़ा था। इस बिंदु पर, दो बैकबोन स्विचों में से एक के डिकमिशनिंग के कारण, नेटवर्क ने केवल एक मुख्य मार्ग पर काम किया, बैकअप डिस्कनेक्ट हो गया। इसके कारण होस्ट मशीनों और स्टोरेज सिस्टम (डेटा स्टोरेज नेटवर्क) के बीच क्लाउड में कनेक्टिविटी का नुकसान हुआ, साथ ही सेंट पीटर्सबर्ग के एक डेटा सेंटर में स्थित सर्वरों की दुर्गमता भी।

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

हमारी स्पष्ट कार्रवाई पहले चैनल के माध्यम से तंतुओं की बहाली की प्रतीक्षा किए बिना, दूसरे चैनल पर स्विच कर रही थी। यह जल्दी से पर्याप्त किया गया था, लेकिन यह बस काम किया, क्योंकि स्विच फिर से लटका दिया। ( 12:45 - 13:05 )

ऑप्टिकल एसएफपी + ट्रांससीवर्स

इस बार, JunOS के नए संस्करण में, समझदार संदेश लॉग में दिखाई दिए और SFP + मॉड्यूल में से किसी एक की सेवा जानकारी को पढ़ने में असमर्थता के बारे में एक शिकायत खोजने में कामयाब रहे,

 25 सितंबर 13:01:06 चेसिस [903]: CM_TSUNAMI [FPC: 0 PIC: 0 पोर्ट: 18]: SFP + ID EEPROM पढ़ने में विफल
 सितम्बर 25 13:01:06 हवाई जहाज़ के पहिये [903]: xcvr_cache_eeprom: xcvr_read_eeprom विफल - लिंक: 18 pic_slot: 0

इस मॉड्यूल को हटाने के बाद, नेटवर्क पुनर्प्राप्त हुआ। हमने मान लिया कि समस्या इस ट्रांसीवर और स्विच की तरफ से उस पर प्रतिक्रिया की थी, क्योंकि इस ट्रान्सीवर ने उन 3 स्विचों में से प्रत्येक का दौरा किया था, जिन्हें हमने क्रमिक रूप से पहले बदल दिया था।

हालांकि, 3 घंटे के बाद स्थिति फिर से दोहराई गई। इस बार, संदेशों ने एक विफल मॉड्यूल का संकेत नहीं दिया, हमने तुरंत सभी ट्रांसवर्स को रिजर्व से नए के साथ बदलने का फैसला किया, लेकिन इससे भी मदद नहीं मिली। उन्होंने बदले में सभी ट्रांससीवर्स को देखना शुरू कर दिया, एक समय में एक को खींचना, एक और समस्या ट्रान्सीवर नए बैच से पहले से ही पाया गया था। यह सुनिश्चित करने के बाद कि स्विच के साथ समस्या हल हो गई थी, हमने मुख्य ऑपरेशन योजना ( 16:07 - 16:31, 17:39 - 18:04, 18:22 - 18:27 ) पर स्विच करने के लिए आंतरिक नेटवर्क कनेक्शन को पार किया।

क्लाउड सर्वर रिकवरी

चूंकि समस्या का पैमाना शुरू में अस्पष्ट था, इसलिए हमने क्लाउड सर्वर को बढ़ाने के लिए कई बार कोशिश की। नए स्टोरेज पर स्थित मशीनें (SR: d7e ... और e9f ... के लिए uuids की शुरुआत) इंटरनेट की दुर्गमता के रूप में पहली दुर्घटनाओं से बच गई। पुराने स्टोरेज, क्लाउड, पर क्लाउड सर्वर को डिस्क के लिए I / O त्रुटि मिली। उसी समय, बहुत पुरानी आभासी मशीनों ने केवल मोड पढ़ने के लिए स्विच किया। इस मामले में, एक नई पीढ़ी की मशीनों में त्रुटि होती है = fstab में पैनिक सेटिंग, जो किसी त्रुटि की स्थिति में मशीन को समाप्त कर देती है। कई पुनरारंभों के बाद, दुर्भाग्य से, ऐसी स्थिति थी जहां वीएम लॉन्च के लिए मेजबानों को तैयार करने में एक अस्वीकार्य रूप से लंबा समय लगा (एलवीएम के लिए बड़े पैमाने पर आईओ त्रुटि बहुत अप्रिय है; कुछ मामलों में, एक मरने वाली आभासी मशीन एक ज़ोंबी में बदल जाती है, और हर बार उसे पकड़ने और पूरा करने के लिए मैनुअल काम की आवश्यकता होती है) । पावर होस्ट को फिर से शुरू करने का निर्णय लिया गया। इसने नए रिपॉजिटरी से आभासी मशीनों के लिए एक रिबूट का कारण बना, जो हम वास्तव में नहीं करना चाहते थे, लेकिन इससे अन्य सभी के स्टार्टअप समय को कम करने में महत्वपूर्ण (कम से कम तीन बार) संभव हो गया। उसी समय, स्टोरेज स्वयं नेटवर्क गतिविधि के बिना और बरकरार डेटा के साथ थे।

कार्रवाई की गई

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

परिणामस्वरूप, निम्नलिखित गतिविधियों को करने का निर्णय लिया गया:

एक परीक्षण वातावरण में ऑप्टिकल ट्रांसीवर और नेटवर्क उपकरणों का उन्नत सत्यापन;
गुंबददार कार्यों के परिणामस्वरूप क्षति के जोखिम वाले स्थानों में बख़्तरबंद केवलर फाइबर ऑप्टिक केबल;
क्लाउड सर्वर इन्फ्रास्ट्रक्चर के आधुनिकीकरण को पूरा करने में तेजी लाएं।

ओफ़्सेट

एक सवाल जो सभी को रुचिकर लगे। नीचे दी गई तालिका SLA के अनुसार महीने के लिए प्रदान की गई सेवाओं की लागत के प्रतिशत के रूप में विभिन्न प्रकार की सेवाओं के लिए मुआवजे की राशि को दर्शाती है।

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

सेवा	स्र्कना	मुआवज़ा
वर्चुअल समर्पित सर्वर	11 घंटे	30%
समर्पित सर्वर / मनमाना विन्यास सर्वर	11 घंटे	30%
उपकरण प्लेसमेंट	11 घंटे	30%
सीएमएस होस्टिंग	11 घंटे	30%
क्लाउड सर्वर	24 घंटे	50%
क्लाउड स्टोरेज	11 घंटे	50%

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

24-25 सितंबर सेवाओं के काम में समस्याएं