यदि किसी गर्मी के दिन आपके उपकरण सहित डेटा सेंटर इस तरह दिखे तो आपको कैसा लगेगा?
नमस्ते! मेरा नाम दिमित्री सैमसनोव है, मैं एक अग्रणी सिस्टम प्रशासक के रूप में काम करता हूं।" फोटो उन चार डेटा केंद्रों में से एक को दिखाता है जहां हमारे प्रोजेक्ट को सेवा प्रदान करने वाले उपकरण स्थापित हैं। इन दीवारों के पीछे लगभग 4 हजार उपकरण हैं: सर्वर, डेटा स्टोरेज सिस्टम, नेटवर्क उपकरण, आदि। - हमारे सभी उपकरणों का लगभग ⅓।
अधिकांश सर्वर Linux हैं. विंडोज़ (एमएस एसक्यूएल) पर भी कई दर्जन सर्वर हैं - हमारी विरासत, जिसे हम कई वर्षों से व्यवस्थित रूप से त्याग रहे हैं।
इसलिए, 5 जून, 2019 को 14:35 बजे, हमारे एक डेटा सेंटर के इंजीनियरों ने आग अलार्म की सूचना दी।
इनकार
14:45. डेटा केंद्रों में धूम्रपान की मामूली घटनाएं आपकी सोच से कहीं अधिक सामान्य हैं। हॉल के अंदर संकेतक सामान्य थे, इसलिए हमारी पहली प्रतिक्रिया अपेक्षाकृत शांत थी: उन्होंने किसी चीज़ को ठीक करने से संबंधित काम को छोड़कर, उत्पादन के साथ काम पर प्रतिबंध लगा दिया, यानी किसी भी कॉन्फ़िगरेशन परिवर्तन, नए संस्करणों को रोल आउट करने आदि पर प्रतिबंध लगा दिया।
कोप
क्या आपने कभी अग्निशामकों से यह पता लगाने की कोशिश की है कि छत पर आग कहाँ लगी थी, या स्थिति का आकलन करने के लिए स्वयं जलती हुई छत पर चढ़ने की कोशिश की है? पांच लोगों के माध्यम से प्राप्त जानकारी में विश्वास की डिग्री क्या होगी?
14: 50। जानकारी मिली है कि आग कूलिंग सिस्टम के करीब पहुंच रही है. लेकिन क्या यह आएगा? ड्यूटी पर तैनात सिस्टम प्रशासक इस डेटा सेंटर के सामने से बाहरी ट्रैफ़िक को हटा देता है।
फिलहाल, हमारी सभी सेवाओं के फ्रंट को तीन डेटा केंद्रों में डुप्लिकेट किया गया है, डीएनएस स्तर पर संतुलन का उपयोग किया जाता है, जो हमें डीएनएस से एक डेटा सेंटर के पते को हटाने की अनुमति देता है, जिससे उपयोगकर्ताओं को सेवाओं तक पहुंच के साथ संभावित समस्याओं से बचाया जा सकता है। . यदि डेटा सेंटर में पहले से ही समस्याएँ उत्पन्न हो चुकी हैं, तो यह स्वचालित रूप से रोटेशन छोड़ देता है। आप यहां और अधिक पढ़ सकते हैं:
आग ने अभी तक हम पर किसी भी तरह का प्रभाव नहीं डाला है - न तो उपयोगकर्ता और न ही उपकरण क्षतिग्रस्त हुए हैं। क्या यह एक दुर्घटना है? दस्तावेज़ का पहला खंड "दुर्घटना कार्य योजना" "दुर्घटना" की अवधारणा को परिभाषित करता है, और यह खंड इस प्रकार समाप्त होता है:
«यदि कोई संदेह हो कि दुर्घटना है या नहीं, तो यह दुर्घटना है!»
14:53. एक आपातकालीन समन्वयक नियुक्त किया जाता है।
समन्वयक वह व्यक्ति होता है जो सभी प्रतिभागियों के बीच संचार को नियंत्रित करता है, दुर्घटना के पैमाने का आकलन करता है, आपातकालीन कार्य योजना का उपयोग करता है, आवश्यक कर्मियों को आकर्षित करता है, मरम्मत के पूरा होने की निगरानी करता है, और सबसे महत्वपूर्ण बात, किसी भी कार्य को सौंपता है। दूसरे शब्दों में, यह वह व्यक्ति है जो संपूर्ण आपातकालीन प्रतिक्रिया प्रक्रिया का प्रबंधन करता है।
नीलाम
15:01. हम उन सर्वरों को अक्षम करना शुरू करते हैं जो उत्पादन से संबंधित नहीं हैं।
15:03. हम सभी आरक्षित सेवाओं को सही ढंग से बंद कर देते हैं।
इसमें न केवल फ्रंट (जिन तक अब उपयोगकर्ता पहुंच नहीं पाते) और उनकी सहायक सेवाएं (व्यावसायिक तर्क, कैश आदि) शामिल हैं, बल्कि प्रतिकृति कारक 2 या अधिक वाले विभिन्न डेटाबेस भी शामिल हैं (, , , वगैरह।)।
15: 06। जानकारी मिली है कि डेटा सेंटर के एक हॉल में आग लगने का खतरा मंडरा रहा है. हमारे पास इस कमरे में उपकरण नहीं हैं, लेकिन यह तथ्य कि आग छत से हॉल तक फैल सकती है, जो हो रहा है उसकी तस्वीर काफी हद तक बदल जाती है।
(बाद में यह पता चला कि हॉल को कोई शारीरिक खतरा नहीं था, क्योंकि इसे छत से भली भांति बंद करके सील कर दिया गया था। खतरा केवल इस हॉल की शीतलन प्रणाली को था।)
15:07. हम अतिरिक्त जांच के बिना त्वरित मोड में सर्वर पर कमांड निष्पादन की अनुमति देते हैं ().
15:08. हॉल में तापमान सामान्य सीमा के भीतर है।
15: 12। हॉलों में तापमान में बढ़ोतरी दर्ज की गई.
15:13. डेटा सेंटर के आधे से ज्यादा सर्वर बंद हैं. आगे है।
15:16. सभी उपकरणों को बंद करने का निर्णय लिया गया।
15:21. हम एप्लिकेशन और ऑपरेटिंग सिस्टम को सही ढंग से बंद किए बिना स्टेटलेस सर्वर की बिजली बंद करना शुरू करते हैं।
15:23. MS SQL के लिए जिम्मेदार लोगों का एक समूह आवंटित किया गया है (उनमें से कुछ हैं, उन पर सेवाओं की निर्भरता बहुत अच्छी नहीं है, लेकिन कार्यक्षमता को बहाल करने की प्रक्रिया में अधिक समय लगता है और उदाहरण के लिए, कैसेंड्रा की तुलना में अधिक जटिल है)।
मंदी
15: 25। 16 में से चार हॉल (नंबर 6, 7, 8, 9) में बिजली बंद होने की जानकारी मिली. हमारा उपकरण हॉल 7 और 8 में स्थित है। हमारे दो हॉल (नंबर 1 और 3) के बारे में कोई जानकारी नहीं है.
आमतौर पर, आग लगने के दौरान, बिजली की आपूर्ति तुरंत बंद कर दी जाती है, लेकिन इस मामले में, अग्निशामकों और डेटा सेंटर के तकनीकी कर्मियों के समन्वित कार्य के लिए धन्यवाद, इसे हर जगह और तुरंत बंद नहीं किया गया, लेकिन आवश्यकतानुसार।
(बाद में पता चला कि हॉल 8 और 9 में बिजली बंद नहीं की गई थी।)
15:28. हम अन्य डेटा केंद्रों में बैकअप से MS SQL डेटाबेस को तैनात करना शुरू कर रहे हैं।
इसमें कितना समय लगेगा? क्या पूरे मार्ग के लिए पर्याप्त नेटवर्क क्षमता है?
15: 37। नेटवर्क के कुछ हिस्सों का शटडाउन दर्ज किया गया।
प्रबंधन और उत्पादन नेटवर्क भौतिक रूप से एक दूसरे से अलग-थलग हैं। यदि उत्पादन नेटवर्क उपलब्ध है, तो आप सर्वर पर जा सकते हैं, एप्लिकेशन बंद कर सकते हैं और ओएस बंद कर सकते हैं। यदि यह उपलब्ध नहीं है, तो आप आईपीएमआई के माध्यम से लॉग इन कर सकते हैं, एप्लिकेशन बंद कर सकते हैं और ओएस बंद कर सकते हैं। यदि कोई नेटवर्क नहीं है, तो आप कुछ नहीं कर सकते। "धन्यवाद, कैप!", आप सोचेंगे।
"और सामान्य तौर पर, बहुत उथल-पुथल है," आप यह भी सोच सकते हैं।
बात यह है कि सर्वर, बिना आग के भी, भारी मात्रा में गर्मी उत्पन्न करते हैं। अधिक सटीक रूप से, जब शीतलन होता है, तो वे गर्मी उत्पन्न करते हैं, और जब शीतलन नहीं होता है, तो वे एक नारकीय नरक का निर्माण करते हैं, जो, सबसे अच्छे रूप में, उपकरण के एक हिस्से को पिघला देगा और दूसरे हिस्से को बंद कर देगा, और सबसे खराब स्थिति में... का कारण बनेगा। हॉल के अंदर आग, जिससे सब कुछ नष्ट होने की लगभग गारंटी है।
15:39. हम कॉन्फ़ डेटाबेस की समस्याओं को ठीक करते हैं।
कॉन्फ़ डेटाबेस उसी नाम की सेवा के लिए बैकएंड है, जिसका उपयोग सभी उत्पादन अनुप्रयोगों द्वारा सेटिंग्स को जल्दी से बदलने के लिए किया जाता है। इस आधार के बिना हम पोर्टल के संचालन को नियंत्रित नहीं कर सकते, लेकिन पोर्टल स्वयं काम कर सकता है।
15:41. कोर नेटवर्क उपकरण पर तापमान सेंसर अधिकतम स्वीकार्य के करीब रीडिंग रिकॉर्ड करते हैं। यह एक बॉक्स है जो पूरे रैक पर कब्जा कर लेता है और डेटा सेंटर के अंदर सभी नेटवर्क के संचालन को सुनिश्चित करता है।
15:42. समस्या ट्रैकर और विकी अनुपलब्ध हैं, स्टैंडबाय पर स्विच करें।
यह उत्पादन नहीं है, लेकिन दुर्घटना की स्थिति में, किसी भी ज्ञान आधार की उपलब्धता महत्वपूर्ण हो सकती है।
15:50. निगरानी प्रणालियों में से एक बंद हो गई है।
उनमें से कई हैं, और वे सेवाओं के विभिन्न पहलुओं के लिए जिम्मेदार हैं। उनमें से कुछ को प्रत्येक डेटा सेंटर के भीतर स्वायत्त रूप से संचालित करने के लिए कॉन्फ़िगर किया गया है (अर्थात, वे केवल अपने स्वयं के डेटा सेंटर की निगरानी करते हैं), अन्य में वितरित घटक शामिल होते हैं जो पारदर्शी रूप से किसी भी डेटा सेंटर के नुकसान से बचे रहते हैं।
ऐसे में इसने काम करना बंद कर दिया , जो मास्टर-स्टैंडबाय मोड में काम करता है। स्टैंडबाय पर स्विच किया गया.
दत्तक ग्रहण
15:51. MS SQL को छोड़कर सभी सर्वर सही ढंग से बंद किए बिना IPMI के माध्यम से बंद कर दिए गए थे।
यदि आवश्यक हो तो क्या आप आईपीएमआई के माध्यम से बड़े पैमाने पर सर्वर प्रबंधन के लिए तैयार हैं?
ठीक उसी क्षण जब इस चरण में डेटा सेंटर में उपकरणों का बचाव पूरा हो जाता है। जो कुछ किया जा सकता था वह किया जा चुका है। कुछ सहकर्मी आराम कर सकते हैं।
16: 13। जानकारी मिली है कि एयर कंडीशनर के फ़्रीऑन पाइप छत पर फट गए हैं - इससे आग ख़त्म होने के बाद डेटा सेंटर के लॉन्च में देरी होगी।
16:19. डेटा सेंटर के तकनीकी कर्मचारियों से प्राप्त आंकड़ों के अनुसार, हॉल में तापमान में वृद्धि रुक गई है।
17:10. कॉन्फ़ डेटाबेस को पुनर्स्थापित कर दिया गया है। अब हम एप्लिकेशन सेटिंग बदल सकते हैं.
यदि सब कुछ दोष-सहिष्णु है और एक डेटा सेंटर के बिना भी काम करता है तो यह इतना महत्वपूर्ण क्यों है?
सबसे पहले, हर चीज़ दोष-सहिष्णु नहीं है। ऐसी कई माध्यमिक सेवाएँ हैं जो अभी तक डेटा सेंटर की विफलता से ठीक से नहीं बच पाई हैं, और मास्टर-स्टैंडबाय मोड में डेटाबेस हैं। सेटिंग्स को प्रबंधित करने की क्षमता आपको कठिन परिस्थितियों में भी उपयोगकर्ताओं पर दुर्घटना के परिणामों के प्रभाव को कम करने के लिए आवश्यक सब कुछ करने की अनुमति देती है।
दूसरे, यह स्पष्ट हो गया कि आने वाले घंटों में डेटा सेंटर का संचालन पूरी तरह से बहाल नहीं किया जाएगा, इसलिए यह सुनिश्चित करने के लिए उपाय करना आवश्यक था कि प्रतिकृतियों की दीर्घकालिक अनुपलब्धता से पूर्ण डिस्क जैसी अतिरिक्त परेशानी न हो। शेष डेटा केंद्र.
17:29. पिज्जा का समय! हम लोगों को रोजगार देते हैं, रोबोट को नहीं।
पुनर्वास
18:02. हॉल नंबर 8 (हमारा), 9, 10 और 11 में तापमान स्थिर हो गया है। उनमें से एक जो ऑफ़लाइन रहता है (नंबर 7) में हमारे उपकरण हैं, और वहां तापमान बढ़ता जा रहा है।
18:31. उन्होंने हॉल नंबर 1 और 3 में उपकरण शुरू करने की अनुमति दे दी - ये हॉल आग से प्रभावित नहीं हुए।
वर्तमान में, सबसे महत्वपूर्ण हॉल नंबर 1, 3, 8 से शुरू करके सर्वर लॉन्च किए जा रहे हैं। सभी चल रही सेवाओं के सही संचालन की जाँच की जाती है। हॉल नंबर 7 को लेकर अभी भी दिक्कतें हैं.
18:44. डेटा सेंटर के तकनीकी कर्मचारियों ने पाया कि कमरा नंबर 7 (जहां केवल हमारे उपकरण स्थित हैं) में कई सर्वर बंद नहीं हैं। हमारे डेटा के मुताबिक वहां 26 सर्वर ऑनलाइन रहते हैं. दूसरी जाँच के बाद, हमें 58 सर्वर मिले।
20:18. डेटा सेंटर तकनीशियन हॉलवे के माध्यम से चलने वाली मोबाइल नलिकाओं के माध्यम से एक गैर-वातानुकूलित कमरे में हवा उड़ाते हैं।
23:08. पहले व्यवस्थापक को घर भेज दिया गया. कल काम जारी रखने के लिए किसी को रात में सोना ज़रूरी है। इसके बाद, हम कुछ और एडमिन और डेवलपर्स जारी करेंगे।
02:56. हमने वह सब कुछ लॉन्च किया जो लॉन्च किया जा सकता था। हम स्वचालित परीक्षणों का उपयोग करके सभी सेवाओं की बहुत अधिक जाँच करते हैं।
03:02. आखिरी, 7वें हॉल में एयर कंडीशनिंग बहाल कर दी गई है।
03:36. हमने डेटा सेंटर में मोर्चों को डीएनएस में रोटेशन में लाया। इसी क्षण से उपयोगकर्ता ट्रैफ़िक आना शुरू हो जाता है।
हम अधिकांश प्रशासनिक टीम को घर भेज रहे हैं।' लेकिन हम कुछ लोगों को पीछे छोड़ देते हैं।
छोटे सामान्य प्रश्न:
प्रश्न: 18:31 से 02:56 तक क्या हुआ?
उत्तर: "आपदा कार्य योजना" का पालन करते हुए, हम सबसे महत्वपूर्ण से लेकर सभी सेवाएं लॉन्च करते हैं। इस मामले में, चैट में समन्वयक एक निःशुल्क व्यवस्थापक को सेवा जारी करता है, जो जांच करता है कि क्या ओएस और एप्लिकेशन शुरू हो गए हैं, क्या कोई त्रुटि है, और क्या संकेतक सामान्य हैं। लॉन्च पूरा होने के बाद, वह चैट पर रिपोर्ट करता है कि वह मुफ़्त है और समन्वयक से एक नई सेवा प्राप्त करता है।
विफल हार्डवेयर के कारण प्रक्रिया और धीमी हो गई है। भले ही ओएस को रोकना और सर्वर को बंद करना सही ढंग से हुआ हो, कुछ सर्वर डिस्क, मेमोरी और चेसिस की अचानक विफलता के कारण वापस नहीं आते हैं। जब बिजली चली जाती है, तो विफलता दर बढ़ जाती है।
प्रश्न: आप सब कुछ एक साथ क्यों नहीं चला सकते, और फिर निगरानी में जो आता है उसे ठीक क्यों नहीं कर सकते?
उत्तर: सब कुछ धीरे-धीरे किया जाना चाहिए, क्योंकि सेवाओं के बीच निर्भरताएँ होती हैं। और निगरानी की प्रतीक्षा किए बिना, हर चीज की तुरंत जांच की जानी चाहिए - क्योंकि समस्याओं के बिगड़ने का इंतजार किए बिना, तुरंत उनसे निपटना बेहतर है।
7:40. अंतिम व्यवस्थापक (समन्वयक) सो गया। पहले दिन का काम पूरा हो चुका है.
8:09. पहले डेवलपर्स, डेटा सेंटर इंजीनियरों और प्रशासकों (नए समन्वयक सहित) ने बहाली का काम शुरू किया।
09:37. हमने हॉल नंबर 7 (आखिरी वाला) को ऊपर उठाना शुरू किया।
साथ ही, हम वह पुनर्स्थापित करना जारी रखते हैं जो अन्य कमरों में तय नहीं किया गया था: डिस्क/मेमोरी/सर्वर को बदलना, निगरानी में "जलने" वाली हर चीज को ठीक करना, मास्टर-स्टैंडबाय योजनाओं में भूमिकाओं को वापस स्विच करना और अन्य छोटी चीजें, जिनमें से हैं फिर भी काफी कुछ।
17:08. हम उत्पादन के साथ सभी नियमित कार्यों की अनुमति देते हैं।
21:45. दूसरे दिन का काम पूरा हो गया है.
09:45. आज शुक्रवार था। मॉनिटरिंग में अभी भी काफी छोटी-मोटी दिक्कतें हैं. सप्ताहांत सामने है, हर कोई आराम करना चाहता है। हम अपनी क्षमतानुसार हर चीज की बड़े पैमाने पर मरम्मत करना जारी रखते हैं। नियमित व्यवस्थापक कार्य जिन्हें स्थगित किया जा सकता था उन्हें स्थगित कर दिया गया। संयोजक नये हैं.
15:40. किसी अन्य डेटा सेंटर में कोर नेटवर्क उपकरण स्टैक का आधा हिस्सा अचानक पुनः प्रारंभ हो गया। जोखिमों को कम करने के लिए मोर्चों को रोटेशन से बाहर कर दिया गया। उपयोगकर्ताओं के लिए कोई प्रभाव नहीं है. बाद में पता चला कि यह एक दोषपूर्ण चेसिस था। समन्वयक एक साथ दो दुर्घटनाओं की मरम्मत पर काम कर रहा है।
17:17. दूसरे डेटा सेंटर में नेटवर्क संचालन बहाल कर दिया गया है, सब कुछ जांच लिया गया है। डेटा सेंटर को रोटेशन में डाल दिया गया है।
18:29. तीसरे दिन का काम और सामान्य तौर पर दुर्घटना के बाद बहाली का काम पूरा हो चुका है।
अंतभाषण
04.04.2013 , "सहपाठी" —तीन दिनों तक पोर्टल पूरी तरह या आंशिक रूप से अनुपलब्ध था। इस पूरे समय के दौरान, अलग-अलग शहरों से, अलग-अलग कंपनियों से (फिर से बहुत-बहुत धन्यवाद!) 100 से अधिक लोगों ने, दूरस्थ रूप से और सीधे डेटा केंद्रों में, मैन्युअल रूप से और स्वचालित रूप से, हजारों सर्वरों की मरम्मत की।
हमने निष्कर्ष निकाल लिया है. ऐसा दोबारा होने से रोकने के लिए, हमने व्यापक कार्य किया है और आज भी जारी रख रहे हैं।
वर्तमान दुर्घटना और 404 के बीच मुख्य अंतर क्या हैं?
- हमारे पास एक "दुर्घटना कार्य योजना" है। तिमाही में एक बार, हम अभ्यास करते हैं - हम एक आपातकालीन स्थिति की भूमिका निभाते हैं, जिसे प्रशासकों के एक समूह (सभी को बारी-बारी से) को "आपातकालीन कार्य योजना" का उपयोग करके समाप्त करना होगा। अग्रणी सिस्टम प्रशासक बारी-बारी से समन्वयक की भूमिका निभाते हैं।
- त्रैमासिक, परीक्षण मोड में, हम LAN और WAN नेटवर्क के माध्यम से डेटा केंद्रों (सभी को बारी-बारी से) को अलग करते हैं, जो हमें तुरंत बाधाओं की पहचान करने की अनुमति देता है।
- कम टूटी हुई डिस्क, क्योंकि हमने मानकों को कड़ा कर दिया है: कम परिचालन घंटे, स्मार्ट के लिए सख्त सीमाएँ,
- हमने बर्कलेडीबी को पूरी तरह से त्याग दिया, एक पुराना और अस्थिर डेटाबेस जिसे सर्वर पुनरारंभ होने के बाद पुनर्प्राप्त करने के लिए बहुत समय की आवश्यकता होती है।
- हमने MS SQL वाले सर्वरों की संख्या कम कर दी और शेष पर निर्भरता कम कर दी।
- हमारा अपना है , जहां हम दो वर्षों से सभी सेवाओं को सक्रिय रूप से स्थानांतरित कर रहे हैं। क्लाउड एप्लिकेशन के साथ काम करने के पूरे चक्र को बहुत सरल बनाता है, और दुर्घटना की स्थिति में यह ऐसे अनूठे उपकरण प्रदान करता है:
- एक क्लिक में सभी एप्लिकेशन का सही स्टॉप;
- विफल सर्वर से अनुप्रयोगों का आसान स्थानांतरण;
- संपूर्ण डेटा सेंटर का स्वचालित रैंक (सेवाओं की प्राथमिकता के क्रम में) लॉन्च।
इस लेख में वर्णित दुर्घटना 404वें दिन के बाद सबसे बड़ी थी। बेशक, सब कुछ सुचारू रूप से नहीं चला। उदाहरण के लिए, किसी अन्य डेटा सेंटर में आग से क्षतिग्रस्त डेटा सेंटर की अनुपलब्धता के दौरान, सर्वरों में से एक पर एक डिस्क विफल हो गई, यानी, कैसेंड्रा क्लस्टर में तीन प्रतिकृतियों में से केवल एक ही पहुंच योग्य रही, यही कारण है कि 4,2% मोबाइल एप्लिकेशन उपयोगकर्ता लॉग इन नहीं कर सके. वहीं, पहले से कनेक्टेड यूजर्स काम करते रहे। कुल मिलाकर, दुर्घटना के परिणामस्वरूप, 30 से अधिक समस्याओं की पहचान की गई - साधारण बग से लेकर सेवा वास्तुकला में कमियों तक।
लेकिन मौजूदा दुर्घटना और 404वीं दुर्घटना के बीच सबसे महत्वपूर्ण अंतर यह है कि जब हम आग के परिणामों को खत्म कर रहे थे, तब भी उपयोगकर्ता संदेश भेज रहे थे और वीडियो कॉल कर रहे थे। , गेम खेले, संगीत सुना, एक-दूसरे को उपहार दिए, वीडियो, टीवी श्रृंखला और टीवी चैनल देखे , और स्ट्रीम भी किया गया .
आपकी दुर्घटनाएँ कैसी होती हैं?
स्रोत: www.habr.com