यदि तपाइँको उपकरणको साथ एक राम्रो गर्मी को दिन डाटा सेन्टर यस्तो देखिन्छ भने तपाइँ कस्तो महसुस गर्नुहुन्छ?
नमस्ते सबै! मेरो नाम दिमित्री सामसोनोभ हो, म एक अग्रणी प्रणाली प्रशासकको रूपमा काम गर्दछु "" तस्बिरले हाम्रो परियोजना सेवा गर्ने उपकरणहरू स्थापना गरिएका चार डेटा केन्द्रहरू मध्ये एउटा देखाउँछ। यी पर्खालहरू पछाडि लगभग 4 हजार उपकरणहरू छन्: सर्भरहरू, डाटा भण्डारण प्रणालीहरू, नेटवर्क उपकरणहरू, इत्यादि। - हाम्रा सबै उपकरणहरूको लगभग ⅓।
धेरै सर्भरहरू लिनक्स हुन्। Windows (MS SQL) मा धेरै दर्जन सर्भरहरू पनि छन् - हाम्रो विरासत, जुन हामीले धेरै वर्षदेखि व्यवस्थित रूपमा त्यागिरहेका छौं।
त्यसोभए, जुन 5, 2019 मा 14:35 मा, हाम्रो डेटा केन्द्रहरू मध्ये एकका इन्जिनियरहरूले फायर अलार्म रिपोर्ट गरे।
नकारात्मक
१४:४५। डाटा सेन्टरहरूमा सानो धुवाँका घटनाहरू तपाईंले सोचेभन्दा बढी सामान्य छन्। हल भित्रका संकेतकहरू सामान्य थिए, त्यसैले हाम्रो पहिलो प्रतिक्रिया अपेक्षाकृत शान्त थियो: तिनीहरूले उत्पादनको साथ काममा प्रतिबन्ध ल्याए, त्यो हो, कुनै पनि कन्फिगरेसन परिवर्तनहरूमा, नयाँ संस्करणहरू रोल आउट गर्न, इत्यादिमा, केहि फिक्स गर्न सम्बन्धित काम बाहेक।
क्रोध
के तपाईंले कहिल्यै छतमा आगो लागेको ठाउँमा अग्निनियन्त्रकहरूबाट पत्ता लगाउने प्रयास गर्नुभएको छ, वा अवस्थाको मूल्याङ्कन गर्न आफै जलिरहेको छतमा पुगेर? पाँच जना मार्फत प्राप्त जानकारीमा विश्वासको स्तर कस्तो हुनेछ?
14: 50। आगो कुलिङ सिस्टम नजिक पुगेको जानकारी प्राप्त भएको छ। तर आउने हो कि ? ड्युटीमा रहेको प्रणाली प्रशासकले यस डेटा केन्द्रको अगाडिबाट बाहिरी ट्राफिक हटाउँछ।
यस समयमा, हाम्रा सबै सेवाहरूको फ्रन्टहरू तीन डेटा केन्द्रहरूमा नक्कल गरिएका छन्, DNS स्तरमा सन्तुलन प्रयोग गरिन्छ, जसले हामीलाई DNS बाट एउटा डेटा केन्द्रको ठेगानाहरू हटाउन अनुमति दिन्छ, जसले गर्दा प्रयोगकर्ताहरूलाई सेवाहरूमा पहुँचको साथ सम्भावित समस्याहरूबाट जोगाउँछ। । यदि डेटा केन्द्रमा समस्याहरू पहिले नै आइसकेको छ भने, यसले स्वचालित रूपमा रोटेशन छोड्छ। तपाईं यहाँ थप पढ्न सक्नुहुन्छ:
आगोले हामीलाई कुनै पनि हिसाबले असर गरेको छैन - न त प्रयोगकर्ताहरू र उपकरणहरू क्षतिग्रस्त भएका छन्। के यो दुर्घटना हो? कागजातको पहिलो खण्ड "दुर्घटना कार्य योजना" ले "दुर्घटना" को अवधारणा परिभाषित गर्दछ, र खण्ड यसरी समाप्त हुन्छ:
«दुर्घटना भएको हो कि होइन भन्ने शंका छ भने त्यो दुर्घटना हो !»
१४:५३। आकस्मिक संयोजक नियुक्त गरिएको छ।
संयोजक भनेको सबै सहभागीहरू बीच सञ्चार नियन्त्रण गर्ने, दुर्घटनाको मापन गर्ने, आपतकालीन कार्य योजना प्रयोग गर्ने, आवश्यक कर्मचारीहरूलाई आकर्षित गर्ने, मर्मतसम्भार पूरा भएको अनुगमन गर्ने, र सबैभन्दा महत्त्वपूर्ण कुरा कुनै पनि कार्यहरू प्रत्यायोजन गर्ने व्यक्ति हो। अन्य शब्दहरूमा, यो व्यक्ति हो जसले सम्पूर्ण आपतकालीन प्रतिक्रिया प्रक्रियाको व्यवस्थापन गर्दछ।
सौदा
१५:०१। हामी उत्पादनसँग सम्बन्धित नभएका सर्भरहरू असक्षम गर्न सुरु गर्छौं।
१५:०३। हामी सबै आरक्षित सेवाहरू सही रूपमा बन्द गर्छौं।
यसले फ्रन्टहरू मात्र समावेश गर्दैन (जसलाई यस बिन्दुमा प्रयोगकर्ताहरूले अब पहुँच गर्दैनन्) र तिनीहरूका सहायक सेवाहरू (व्यापार तर्क, क्यास, आदि), तर प्रतिकृति कारक 2 वा बढी भएका विभिन्न डाटाबेसहरू पनि समावेश छन्।, , , आदि)।
15: 06। डाटा सेन्टरको एउटा हलमा आगलागी हुने खतरा रहेको जानकारी प्राप्त भएको छ । हामीसँग यस कोठामा उपकरणहरू छैनन्, तर आगो छतबाट हलहरूमा फैलिन सक्छ भन्ने तथ्यले के भइरहेको छ भन्ने चित्रलाई धेरै परिवर्तन गर्छ।
(पछि थाहा भयो कि हलको लागि कुनै भौतिक खतरा थिएन, किनकि यसलाई छतबाट हर्मेटिक रूपमा बन्द गरिएको थियो। खतरा केवल यस हलको शीतलन प्रणालीमा थियो।)
१५:०७। हामी सर्भरहरूमा अतिरिक्त जाँचहरू बिना द्रुत मोडमा आदेश कार्यान्वयन अनुमति दिन्छौं ().
१५:०८। हलहरूमा तापक्रम सामान्य सीमा भित्र छ।
15: 12। हलहरूमा तापक्रममा वृद्धि भएको छ।
१५:१३। डाटा सेन्टरका आधाभन्दा बढी सर्भर बन्द छन्। जारी राखौं।
१५:१६। सबै उपकरण बन्द गर्ने निर्णय गरियो।
१५:२१। हामीले एप्लिकेसन र अपरेटिङ सिस्टमलाई सही रूपमा बन्द नगरी स्टेटलेस सर्भरहरूमा पावर बन्द गर्न सुरु गर्छौं।
१५:२३। MS SQL का लागि जिम्मेवार व्यक्तिहरूको समूह आवंटित गरिएको छ (त्यहाँ थोरै छन्, तिनीहरूमा सेवाहरूको निर्भरता ठूलो छैन, तर कार्यक्षमता पुनर्स्थापनाको लागि प्रक्रियाले लामो समय लिन्छ र उदाहरणका लागि, क्यासान्ड्रा भन्दा बढी जटिल छ)।
अवसाद
15: 25। १६ (६, ७, ८, ९) मध्ये चार हलमा विद्युत् बन्द भएको जानकारी प्राप्त भएको थियो । हाम्रो उपकरण हल 7 र 8 मा स्थित छ। हाम्रा दुई हल (नम्बर १ र ३) को बारेमा कुनै जानकारी छैन।
सामान्यतया, आगोको समयमा, बिजुली आपूर्ति तुरुन्तै बन्द हुन्छ, तर यस अवस्थामा, फायर फाइटरहरू र डाटा केन्द्रका प्राविधिक कर्मचारीहरूको समन्वयात्मक कार्यको लागि धन्यवाद, यो जताततै बन्द गरिएको थिएन र तुरुन्तै होइन, तर आवश्यक रूपमा।
(पछि थाहा भयो कि हल 8 र 9 मा बिजुली बन्द गरिएको थिएन।)
१५:२८। हामी अन्य डाटा केन्द्रहरूमा ब्याकअपबाट MS SQL डाटाबेसहरू प्रयोग गर्न सुरु गर्दैछौं।
कति समय लाग्छ? के त्यहाँ सम्पूर्ण मार्गको लागि पर्याप्त नेटवर्क क्षमता छ?
15: 37। नेटवर्क को केहि भागहरु को एक बन्द रेकर्ड गरियो।
व्यवस्थापन र उत्पादन नेटवर्क भौतिक रूपमा एक अर्काबाट अलग छन्। यदि उत्पादन नेटवर्क उपलब्ध छ भने, तपाइँ सर्भरमा जान सक्नुहुन्छ, अनुप्रयोग रोक्न र OS बन्द गर्न सक्नुहुन्छ। यदि यो उपलब्ध छैन भने, तपाइँ IPMI मार्फत लग इन गर्न सक्नुहुन्छ, अनुप्रयोग रोक्न र OS बन्द गर्नुहोस्। यदि त्यहाँ कुनै पनि नेटवर्क छैन भने, त्यसपछि तपाइँ केहि गर्न सक्नुहुन्न। "धन्यवाद, क्याप!", तपाईंले सोच्नुहुनेछ।
"र सामान्यतया, त्यहाँ धेरै उथलपुथल छ," तपाइँ पनि सोच्न सक्नुहुन्छ।
कुरा यो हो कि सर्भरहरू, आगो बिना पनि, ठूलो मात्रामा गर्मी उत्पन्न गर्दछ। अझ स्पष्ट रूपमा, जब चिसो हुन्छ, तिनीहरूले तातो उत्पन्न गर्छन्, र जब त्यहाँ कुनै चिसो छैन, तिनीहरूले नरकको नरक सिर्जना गर्छन्, जसले उपकरणको एक भाग पग्लनेछ र अर्को भाग बन्द गर्नेछ, र नराम्रो रूपमा ... भित्र आगो निम्त्याउँछ। हल, जुन लगभग सबै नष्ट गर्न ग्यारेन्टी छ।
१५:३९। हामी conf डाटाबेसमा समस्याहरू समाधान गर्छौं।
conf डाटाबेस एउटै नामको सेवाको लागि ब्याकइन्ड हो, जुन सबै उत्पादन अनुप्रयोगहरूद्वारा छिटो सेटिङहरू परिवर्तन गर्न प्रयोग गरिन्छ। यो आधार बिना, हामी पोर्टलको सञ्चालन नियन्त्रण गर्न सक्दैनौं, तर पोर्टल आफैले काम गर्न सक्छ।
१५:४१। कोर नेटवर्क उपकरणमा तापक्रम सेन्सरहरू अधिकतम अनुमतिको नजिक रिडिङ रेकर्ड गर्दछ। यो एक बक्स हो जसले सम्पूर्ण र्याक ओगटेको छ र डाटा सेन्टर भित्र सबै नेटवर्कहरूको सञ्चालन सुनिश्चित गर्दछ।
१५:४२। इश्यू ट्र्याकर र विकी उपलब्ध छैनन्, स्ट्यान्डबाइमा स्विच गर्नुहोस्।
यो उत्पादन होइन, तर दुर्घटनाको घटनामा, कुनै पनि ज्ञान आधारको उपलब्धता महत्वपूर्ण हुन सक्छ।
१५:५०। एउटा अनुगमन प्रणाली बन्द भएको छ ।
तिनीहरूमध्ये धेरै छन्, र तिनीहरू सेवाहरूको विभिन्न पक्षहरूको लागि जिम्मेवार छन्। तिनीहरूमध्ये केहीलाई प्रत्येक डाटा केन्द्र भित्र स्वायत्त रूपमा सञ्चालन गर्न कन्फिगर गरिएको छ (अर्थात, तिनीहरूले आफ्नै डाटा केन्द्रको मात्र निगरानी गर्छन्), अरूमा वितरित कम्पोनेन्टहरू हुन्छन् जुन पारदर्शी रूपमा कुनै पनि डाटा केन्द्रको हानिबाट बच्न सकिन्छ।
यस्तो अवस्थामा यसले काम गर्न छोड्यो , जुन मास्टर-स्ट्यान्डबाइ मोडमा सञ्चालन हुन्छ। स्ट्यान्डबाइमा स्विच गरियो।
अंगिकार
१५:५१। MS SQL बाहेक सबै सर्भरहरू IPMI मार्फत सही रूपमा बन्द नगरी बन्द गरियो।
यदि आवश्यक भएमा तपाईं IPMI मार्फत ठूलो सर्भर व्यवस्थापनको लागि तयार हुनुहुन्छ?
धेरै क्षण जब डाटा केन्द्र मा उपकरण को उद्धार यस चरण मा पूरा भयो। गर्न सक्ने सबै काम भइसकेको छ । केही सहकर्मीहरूले आराम गर्न सक्छन्।
16: 13। जानकारी प्राप्त भएको छ कि वातानुकूलितबाट फ्रीओन पाइपहरू छतमा फट्छन् - यसले आगो मेटाएपछि डाटा सेन्टरको सुरुवातमा ढिलाइ हुनेछ।
१६:१९। डाटा सेन्टरका प्राविधिक कर्मचारीबाट प्राप्त तथ्याङ्क अनुसार हलमा तापक्रम बढ्ने क्रम रोकिएको छ ।
१७:१०। conf डाटाबेस पुनर्स्थापित गरिएको छ। अब हामी अनुप्रयोग सेटिङहरू परिवर्तन गर्न सक्छौं।
यदि सबै कुरा दोष-सहिष्णु छ र एउटै डाटा सेन्टर बिना पनि काम गर्दछ भने यो किन महत्त्वपूर्ण छ?
पहिलो, सबै कुरा गल्ती-सहनशील हुँदैन। त्यहाँ विभिन्न माध्यमिक सेवाहरू छन् जुन अहिलेसम्म डाटा सेन्टरको विफलतामा पर्याप्त रूपमा बाँचेका छैनन्, र मास्टर-स्ट्यान्डबाइ मोडमा डेटाबेसहरू छन्। सेटिङहरू व्यवस्थापन गर्ने क्षमताले तपाईंलाई कठिन परिस्थितिहरूमा पनि प्रयोगकर्ताहरूमा दुर्घटनाको परिणामहरूको प्रभावलाई कम गर्न आवश्यक सबै गर्न अनुमति दिन्छ।
दोस्रो, यो स्पष्ट भयो कि डाटा सेन्टरको सञ्चालन आउँदो घण्टाहरूमा पूर्ण रूपमा पुनर्स्थापित हुनेछैन, त्यसैले प्रतिकृतिहरूको दीर्घकालीन अनुपलब्धताले पूर्ण डिस्कहरू जस्ता अतिरिक्त समस्याहरू निम्त्याउने छैन भनेर सुनिश्चित गर्न उपायहरू लिन आवश्यक थियो। बाँकी डाटा केन्द्रहरू।
१७:२९। पिज्जा समय! हामीले मानिसहरूलाई रोजगारी दिन्छौं, रोबोट होइन।
पुनर्वास
१८:०२। हल नं ८ (हाम्रो), ९, १० र ११ मा तापक्रम स्थिर छ । अफलाइन रहने मध्ये एक (नम्बर 18) मा हाम्रो उपकरणहरू राखिएको छ, र त्यहाँको तापक्रम निरन्तर बढिरहेको छ।
१८:३१। उनीहरूले हल नम्बर १ र ३ मा उपकरणहरू सुरु गर्न स्वीकृति दिए - यी हलहरू आगोले प्रभावित भएनन्।
हाल, सर्भरहरू हलहरू नम्बर १, ३, ८ मा सुरु भइरहेका छन्, सबैभन्दा महत्वपूर्णबाट सुरु हुँदै। सबै चलिरहेको सेवाहरूको सही सञ्चालन जाँच गरिएको छ। हल नम्बर ७ मा अझै समस्या छ ।
१८:४४। डाटा सेन्टरका प्राविधिक कर्मचारीहरूले कोठा नम्बर ७ मा (जहाँ हाम्रो उपकरण मात्रै रहेको छ) धेरै सर्भरहरू बन्द गरिएका छैनन् भनी पत्ता लगाए। हाम्रो डाटा अनुसार, 18 सर्भरहरू त्यहाँ अनलाइन रहन्छन्। दोस्रो जाँच पछि, हामी 44 सर्भरहरू फेला पार्छौं।
२०:१८। डाटा सेन्टरका प्राविधिकहरूले हलवेमा चल्ने मोबाइल डक्टहरू मार्फत वातानुकूलित कोठाबाट हावा उडाउँछन्।
२३:०८। पहिलो प्रशासक घर पठाइयो। भोलि काम जारी राख्नको लागि कसैलाई राती सुत्न आवश्यक छ। अर्को, हामी केही थप प्रशासक र विकासकर्ताहरू जारी गर्नेछौं।
०२:५६। हामीले लन्च गर्न सक्ने सबै लन्च गर्यौं। हामी स्वचालित परीक्षणहरू प्रयोग गरेर सबै सेवाहरूको धेरै जाँच गर्छौं।
०३:०२। पछिल्लो सातौं हलमा वातानुकूलित व्यवस्था गरिएको छ।
०३:३६। हामीले डाटा सेन्टरमा भएका फ्रन्टहरूलाई DNS मा रोटेशनमा ल्यायौं। यस क्षणबाट प्रयोगकर्ता ट्राफिक आउन सुरु हुन्छ।
हामीले अधिकांश प्रशासनिक टोलीलाई घर पठाइरहेका छौं। तर हामीले केही मानिसलाई छोड्छौं।
सामान्य प्रश्नहरू:
प्रश्न: १८:३१ देखि ०२:५६ सम्म के भयो?
A: "डिजास्टर एक्शन प्लान" को पालना गर्दै, हामी सबै सेवाहरू सुरु गर्छौं, सबैभन्दा महत्त्वपूर्ण सेवाहरूबाट सुरु गर्दै। यस अवस्थामा, च्याटमा संयोजकले एक नि: शुल्क प्रशासकलाई सेवा जारी गर्दछ, जसले OS र अनुप्रयोग सुरु भएको छ कि छैन, कुनै त्रुटिहरू छन् वा छैनन्, र संकेतकहरू सामान्य छन् कि छैनन् भनेर जाँच गर्दछ। प्रक्षेपण पूरा भएपछि, उसले च्याटमा रिपोर्ट गर्छ कि ऊ नि:शुल्क छ र संयोजकबाट नयाँ सेवा प्राप्त गर्दछ।
असफल हार्डवेयर द्वारा प्रक्रिया थप सुस्त छ। ओएस रोक्न र सर्भर बन्द गर्दा पनि सही तरिकाले गएको भए पनि, डिस्क, मेमोरी, र चेसिसको अचानक विफलताको कारण केही सर्भरहरू फिर्ता हुँदैनन्। जब शक्ति हराउँछ, विफलता दर बढ्छ।
प्रश्न: किन तपाईं एकैचोटि सबै कुरा चलाउन सक्नुहुन्न, र त्यसपछि अनुगमनमा के आउँछ ठीक गर्नुहोस्?
A: सबै कुरा बिस्तारै गर्नुपर्छ, किनभने सेवाहरू बीच निर्भरताहरू छन्। र सबै चीजहरू तुरुन्तै जाँच गरिनु पर्छ, निगरानीको लागि पर्खनु बिना - किनभने समस्याहरू तुरुन्तै सामना गर्न राम्रो छ, तिनीहरूलाई खराब हुनको लागि प्रतीक्षा नगरी।
७:४०। अन्तिम प्रशासक (संयोजक) ओछ्यानमा गए। पहिलो दिनको काम सकिएको छ ।
८:०९। पहिलो विकासकर्ताहरू, डाटा केन्द्र इन्जिनियरहरू र प्रशासकहरू (नयाँ संयोजक सहित) पुनर्स्थापना कार्य सुरु गरे।
०९:३७। हामीले हल नम्बर ७ (अन्तिम) उठाउन थाल्यौं।
एकै समयमा, हामी अन्य कोठाहरूमा ठीक नभएका कुराहरू पुनर्स्थापना गर्न जारी राख्छौं: डिस्क/मेमोरी/सर्भरहरू प्रतिस्थापन गर्ने, अनुगमनमा "बर्न" हुने सबै चीजहरू ठीक गर्ने, मास्टर-स्ट्यान्डबाइ योजनाहरूमा भूमिकाहरू फिर्ता गर्ने र अन्य साना चीजहरू, जसमध्ये त्यहाँ छन्। यद्यपि धेरै धेरै।
१७:०८। हामी उत्पादन संग सबै नियमित काम गर्न अनुमति दिन्छौं।
२१:४५। दोस्रो दिनको काम सकियो ।
०९:४५। अाज शुक्रबार हो। अनुगमनमा अझै पनि सानातिना समस्या छन् । सप्ताहन्त अगाडि छ, सबै आराम गर्न चाहन्छन्। हामीले सकेसम्म व्यापक रूपमा मर्मत गर्न जारी राख्छौं। स्थगित हुन सक्ने नियमित प्रशासकीय कार्यहरू स्थगित गरियो। संयोजक नयाँ छन् ।
१५:४०। अचानक अर्को डाटा केन्द्रमा कोर नेटवर्क उपकरण स्ट्याक को आधा पुन: सुरु भयो। जोखिम न्यूनीकरण गर्न फ्रन्टहरू रोटेशनबाट बाहिर निकालिएको थियो। प्रयोगकर्ताहरूमा कुनै प्रभाव छैन। पछि यो एक दोषपूर्ण चेसिस थियो भनेर बाहिर निस्कियो। संयोजकले एकैपटक दुईवटा दुर्घटना मर्मत गर्ने काम गरिरहेका छन् ।
१७:१७। अर्को डाटा सेन्टरमा नेटवर्क सञ्चालन पुनर्स्थापित गरिएको छ, सबै कुरा जाँच गरिएको छ। डाटा सेन्टर रोटेशन मा राखिएको छ।
१८:२९। तेस्रो दिनको काम र सामान्यतया, दुर्घटना पछि पुनर्निर्माण पूरा भएको छ।
पछिशब्द
२०११ , "सहपाठीहरू" -तीन दिनको लागि पोर्टल पूर्ण वा आंशिक रूपमा अनुपलब्ध थियो। यस सम्पूर्ण अवधिमा, विभिन्न शहरहरूबाट, विभिन्न कम्पनीहरूबाट (धेरै धेरै धन्यवाद!), टाढाबाट र प्रत्यक्ष रूपमा डाटा केन्द्रहरूमा, म्यानुअल रूपमा र स्वचालित रूपमा १०० भन्दा बढी व्यक्तिहरूले हजारौं सर्भरहरू मर्मत गरे।
हामीले निष्कर्ष निकालेका छौं। यो दोहोरी नदोहोरियोस् भन्नका लागि हामीले आजसम्म व्यापक कार्यहरू गरेका छौं र जारी राखेका छौं।
हालको दुर्घटना र 404 बीचको मुख्य भिन्नता के हो?
- हामीसँग "दुर्घटना कार्य योजना" छ। चौथाईमा एक पटक, हामी अभ्यासहरू सञ्चालन गर्छौं - हामी एक आपतकालीन स्थितिको भूमिका खेल्छौं, जुन प्रशासकहरूको समूह (सबैले) "आपतकालीन कार्य योजना" प्रयोग गरेर हटाउनै पर्छ। प्रमुख प्रणाली प्रशासकहरूले संयोजकको भूमिका खेल्दै पालैपालो लिन्छन्।
- त्रैमासिक रूपमा, परीक्षण मोडमा, हामी LAN र WAN नेटवर्कहरू मार्फत डाटा केन्द्रहरू (सबै पालैपालो) अलग गर्छौं, जसले हामीलाई तुरुन्तै अवरोधहरू पहिचान गर्न अनुमति दिन्छ।
- थोरै भाँचिएका डिस्कहरू, किनभने हामीले मापदण्डहरू कडा पारेका छौं: कम सञ्चालन घण्टा, SMART को लागि कडा थ्रेसहोल्डहरू,
- हामीले पूर्णतया बर्कलेडीबीलाई त्याग्यौं, पुरानो र अस्थिर डाटाबेस जसलाई सर्भर पुन: सुरु भएपछि रिकभर गर्न धेरै समय चाहिन्छ।
- हामीले MS SQL को साथ सर्भरहरूको संख्या घटाएका छौं र बाँकीहरूमा निर्भरता कम गर्यौं।
- हाम्रो आफ्नै छ जहाँ हामी दुई वर्षदेखि सक्रिय रूपमा सबै सेवाहरू माइग्रेट गरिरहेका छौं। क्लाउडले एप्लिकेसनसँग काम गर्ने सम्पूर्ण चक्रलाई धेरै सरल बनाउँछ, र दुर्घटनाको घटनामा यसले यस्तो अद्वितीय उपकरणहरू प्रदान गर्दछ:
- एक क्लिकमा सबै अनुप्रयोगहरूको सही स्टप;
- असफल सर्भरहरूबाट अनुप्रयोगहरूको सजिलो माइग्रेसन;
- स्वचालित श्रेणीबद्ध (सेवाहरूको प्राथमिकताको क्रममा) सम्पूर्ण डाटा केन्द्रको सुरुवात।
यस लेखमा वर्णन गरिएको दुर्घटना 404 औं दिन पछि सबैभन्दा ठूलो थियो। निस्सन्देह, सबै कुरा सजिलै संग गएन। उदाहरणका लागि, अर्को डाटा सेन्टरमा आगोले क्षतिग्रस्त डाटा सेन्टरको अनुपलब्धताको बेला, एउटा सर्भरमा रहेको डिस्क असफल भयो, त्यो हो, क्यासान्ड्रा क्लस्टरमा तीनवटा प्रतिकृतिहरू मध्ये एउटा मात्र पहुँचयोग्य रह्यो, जसका कारण 4,2% मोबाइल। अनुप्रयोग प्रयोगकर्ताहरू लगइन गर्न सकेनन्। एकै समयमा, पहिले नै जडान भएका प्रयोगकर्ताहरूले काम गर्न जारी राखे। कुलमा, दुर्घटनाको परिणामको रूपमा, 30 भन्दा बढी समस्याहरू पहिचान गरिएको थियो - साधारण बगहरूबाट सेवा वास्तुकलामा कमजोरीहरू।
तर हालको दुर्घटना र 404 औं बीचको सबैभन्दा महत्त्वपूर्ण भिन्नता यो हो कि हामीले आगोको नतिजाहरू हटाउने क्रममा, प्रयोगकर्ताहरूले अझै पनि सन्देश पठाउँदै र भिडियो कलहरू गरिरहेका थिए। खेल खेले, संगीत सुने, एकअर्कालाई उपहार दिए, भिडियो हेर्यो, टिभि शृङ्खला र टिभि च्यानलहरू , र भित्र पनि स्ट्रिम गरियो .
तपाईका दुर्घटनाहरू कसरी जान्छ?
स्रोत: www.habr.com