सिलेक्ट का एक्सीडेंट हो गया

03 मार्च को लगभग 22:50 मास्को समय पर कार ने एक नए बादल में प्रतिक्रिया करना बंद कर दिया।

मैं लोड अनुसूची देखने में कामयाब रहा - इस पर पिछले 15 मिनट में शून्य प्रोसेसर गतिविधि थी।

रिबूट करने के 2 प्रयास किए गए और 2 जबरन बंद किए गए - विफल रहे।
वर्तमान में क्लाउड प्रबंधन बिल्कुल अक्षम है।

सिस्टम इंजीनियर ने टिकट का जवाब दिया:

नमस्ते दरअसल, हमारे क्लाउड में कई सर्वर क्रैश हो गए हैं। हमारे विशेषज्ञ इस समस्या पर काम कर रहे हैं।
हम आपसे क्षमा चाहते हैं।

मैं समुदाय को सूचित करने और तकनीकी सहायता पर लोड को कम करने के लिए एक विषय बना रहा हूं।

दुर्भाग्य से, दुर्घटना अधिक गंभीर थी।

कालक्रम

22:50 समस्याएं शुरू हुईं। सर्वर पर शून्य गतिविधि, प्रबंधन काम नहीं करता है।
01:25 कारें उठना शुरू हुईं।
02:05 ऐसा लगता है कि यह वापस गिर गया - कार ने उसी तरह से जवाब देना बंद कर दिया। ख़ुशी से झूम उठे।
04:00 अमाराओ :

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

05:10 डेल्स्की ने पाया कि "कुछ भी काम नहीं करता है", ग्राफ़ द्वारा कार को लगभग 4x नीचे काट दिया गया था
05:25 डेल्स्की ने क्लाउड कंट्रोल पैनल को बंद कर दिया, समर्थन में 0.5-3 घंटे की वसूली के समय के बारे में बात की
07:08 amarao :

अभी भी समस्या से जूझ रहे हैं और समाधान के तरीकों के बारे में सोच रहे हैं। किसी भी अपेक्षाकृत उच्च डिस्क गतिविधि से आईओ पक्षाघात होता है।

10:00 कोई परिवर्तन नहीं। हालांकि नहीं, उन्होंने कर्म को लीक कर दिया। यदि यह 8 तक गिरता है - मैं ड्राफ्ट में विषय को हटा देता हूं।
11:12

बस टिकट का जवाब दिया:
"विशेषज्ञों द्वारा प्रारंभिक अनुमानों के अनुसार, काम दो घंटे के भीतर पूरा हो जाएगा।"

14:00 स्थिति में कोई विशेष परिवर्तन नहीं हैं। लेकिन कर्म सामान्य लोगों के लिए वापस आ गया, अच्छे लोगों के लिए धन्यवाद!
14:15 कंट्रोल पैनल में संदेश:

हम कार स्टार्ट करते हैं।

मेरा उठना और काम करना है, लेकिन अब मैं खुशी के लिए इंतजार कर रहा हूं।
15:00 मेरा टाइप सर्वर काम कर रहा है, रिसोर्स की खपत शेड्यूल सामान्य है, यह प्रतिक्रिया करता है, लेकिन एक साइट या ssh एक्सेस काम नहीं करता है। या तो काम अभी तक पूरा नहीं हुआ है, या वहां सब कुछ मर गया है। Fsck को लॉन्च किया गया था। सर्वर में जान आ गई।
15:04 अमरो :

दुर्घटना के अंतिम निशान को समाप्त कर दिया गया है।

क्षमा करें लोग।

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

फिर से क्षमा करें।

अमरौ से स्थिति की आधिकारिक व्याख्या

तो क्या हुआ

यदि संक्षेप में - बदले में (10 मिनट के अंतराल के साथ), दोनों सर्वर पर raid10 सरणियों कि भंडारण क्लस्टर प्रदान बंद कर दिया। इन सरणियों के शीर्ष पर हमारे पास Flashcache (कैशिंग परत) और drbd है, C प्रोटोकॉल (सिंक्रोनस रिकॉर्डिंग मोड) पर काम कर रहा है।

सिस्टम को निम्न एल्गोरिथम के अनुसार कॉन्फ़िगर किया गया था: यदि कोई स्टोरेज क्रैश हो जाता है, तो दूसरा काम करना जारी रखता है। कौन सा स्टोरेज जीवंत है, जो नहीं है, यह वर्चुअलाइजेशन मेजबानों पर मल्टीपाथ का उपयोग करके निर्धारित किया जाता है।

लॉन्च से पहले हमने जो मूल परीक्षण चलाए उनमें शामिल हैं: नोड्स (क्रैश) में से एक को क्रैश करना, बिजली खोना, बाहर निकालना (मरना) raid10 से अधिक डिस्क बच सकती है, कैश ssd छापे की मौत (भी raid10), यादृच्छिक व्यवस्थापक, टाइपिंग ' रिबूट ', नेटवर्क केबल को हटाकर उसे वहां / बैक (स्प्लिट ब्रेन से सुरक्षा) के लिए पोक करना। ये सभी परीक्षण पास हो गए और (I) को यह विश्वास हो गया कि प्रणाली हमारी आवश्यकताओं के लिए पर्याप्त थी।

उस रात सामान्य छापेमारी की जाँच शुरू हुई। एक निर्दोष प्रक्रिया जो पृष्ठभूमि में छापे की अखंडता की जांच करती है। पहले पूल में भंडारण और अब धीरे-धीरे यह प्रक्रिया जारी है (लगभग 2-5mb / s)। कर्नेल मॉड्यूल जो चेक करता है, यह सुनिश्चित करता है कि विलंबता बहुत अधिक न बढ़े, इसलिए क्लाइंट को सामान्य मोड में इस प्रक्रिया को नोटिस नहीं करना चाहिए।

हालाँकि, एक समस्या उत्पन्न हुई (हमारी वर्तमान परिकल्पना कर्नेल मॉड्यूल में एक बग है) - और आक्रामक IO (लगभग 25 IOPS प्रति डिस्क सरणी) की उपस्थिति के साथ सत्यापन प्रक्रिया के साथ सरणी पर IO को रोक दिया गया। पूरी तरह से। इतना कि dd if = / dev / md10 of = / dev / null bs = 512 count = 1 सिर्फ "त्रिशंकु"। उसी समय, सभी अंतर्निहित डिस्क से पढ़ना सीधे सफल रहा और सामान्य गति से हुआ। इस तथ्य के कारण कि ioi पर iscsi लक्ष्य (और उनके बाद श्रृंखला में अन्य सभी) को न तो सफलता मिली और न ही प्रतिक्रिया। इसके अलावा, स्थिति इस तथ्य से जटिल थी कि सामान्य "चेकर" मल्टीप्थ पठनीयता के लिए डिस्क के पहले 512 बाइट्स की जांच करता है। मान लें कि इन 512 बाइट्स को फ्लैशेक में कैश किया गया था या नहीं ... स्थिति इस तथ्य से भी भ्रमित थी कि अनुरोधों का हिस्सा (जो कि एसएसडी कैश में थे) को सामान्य रूप से सेवा दी गई थी, और कुछ समय के लिए अनुरोध भी समस्याओं के बिना पहुंचे। कुछ बिंदु पर, ssd कैश भरा हुआ था और इसे छोड़ने की समस्या थी। सिंक्रोनस ड्रब मोड के कारण, एक स्टॉप (एक त्रुटि नहीं, अर्थात् एक स्टॉप) दोनों साथियों के एक स्टॉप का कारण बना। सिद्धांत रूप में, समस्या को केवल "बीमार" दावत (जो हमने शुरुआत में किया था) को बंद करके हल किया जा सकता था। यह लंबे समय तक मदद नहीं करता था, जिसके बाद दूसरे पर समस्या दोहराई गई (जो एक बार फिर से कर्नेल मॉड्यूल में समस्या की बात करता है, और हार्डवेयर में नहीं)। यह इस बिंदु पर था कि अधिकांश ग्राहकों ने एक समस्या पर ध्यान दिया। चूंकि रिकॉर्डिंग पूरी तरह से पंगु थी, हम पिछली दावत की जगह पर नहीं लौट सकते थे, जो इस समय तक बढ़ गया था (और डिस्क की जांच करना जारी रखा जैसे कि कुछ भी नहीं हुआ था)। पहला "वैश्विक रिबूट।" हमारे पास कारों की एक अनुमानित उठाने की गति लगभग 2-3s प्रति कार है (कार लंबे समय तक शुरू होती है, स्टार्ट ऑपरेशन समानांतर में चला जाता है)। कहीं 300 मशीनों पर, तुल्यकालन की गति तेजी से कम होने लगी (वास्तव में, यह पहले से ही 0 था, और "औसत में कमी" केवल एक यादृच्छिक प्रभाव था)। लगभग समकालिक रूप से, दूसरी सहकर्मी पर समस्या दोहराई गई (जो इस समय तक भी रिबूट हो गई थी)। कर्नेल को अपडेट करने का प्रयास करने का निर्णय लिया गया, इससे स्थिति ठीक नहीं हुई। "मैनुअल रिकवरी" की योजनाएँ तैयार की जाने लगीं। इस समय, मेरे सहायक ने सुझाव दिया "मुझे फिर से बनाने दो।" डाली (350 मिनट)। इस समय के दौरान, मैं थोड़ा झपकी लेने में भी कामयाब रहा (क्योंकि समय पहले ही सुबह 7 बजे तक कम हो गया था)। बस मामले में, यह डिस्क विफलता के मामले में "पुनर्निर्माण" के बारे में नहीं है, लेकिन "मासिक" सरणी में सभी डिस्क की जांच कर रहा है। यह प्रक्रिया सभी 10 छापों पर हुई, जिसमें से लगभग 200-250Mb / s की गति से भंडारण एकत्र किया गया था (एक बार में दोनों भंडारण पर)।

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

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

क्षमा याचना:

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

मुआवजा:

मुआवजे में, प्रभावित आभासी मशीनों पर खर्च किए गए धन का 100% वापस करने का निर्णय लिया गया था।