Quay.io अनुपलब्धता पर पोस्टमार्टम

टिप्पणी। अनुवाद।: अगस्त की शुरुआत में, Red Hat ने सार्वजनिक रूप से पहुंच संबंधी समस्याओं को हल करने के बारे में बात की थी, जिसका सामना उसकी सेवा के उपयोगकर्ताओं को पिछले महीनों में करना पड़ा था क्वे.आईओ (यह कंटेनर छवियों के लिए एक रजिस्ट्री पर आधारित है, जिसे कंपनी ने CoreOS की खरीद के साथ प्राप्त किया था)। इस सेवा में आपकी रुचि चाहे जो भी हो, कंपनी के एसआरई इंजीनियरों ने दुर्घटना के कारणों का निदान करने और उन्हें खत्म करने के लिए जो रास्ता अपनाया वह शिक्षाप्रद है।

19 मई को, सुबह-सुबह (ईस्टर्न डेलाइट टाइम, EDT), quay.io सेवा दुर्घटनाग्रस्त हो गई। इस दुर्घटना ने quay.io उपभोक्ताओं और सॉफ्टवेयर के निर्माण और वितरण के लिए एक मंच के रूप में quay.io का उपयोग करने वाले ओपन सोर्स प्रोजेक्ट्स दोनों को प्रभावित किया। रेड हैट दोनों के भरोसे को महत्व देता है।

एसआरई इंजीनियरों की एक टीम तुरंत शामिल हो गई और जितनी जल्दी हो सके क्वे सेवा को स्थिर करने की कोशिश की। हालाँकि, जब वे ऐसा कर रहे थे, तो ग्राहकों ने नई छवियों को पुश करने की क्षमता खो दी, और केवल कभी-कभी ही वे मौजूदा छवियों को खींचने में सक्षम थे। किसी अज्ञात कारण से, सेवा को पूर्ण क्षमता तक बढ़ाने के बाद quay.io डेटाबेस को अवरुद्ध कर दिया गया था।

«क्या बदल गया है?- यह पहला सवाल है जो आमतौर पर ऐसे मामलों में पूछा जाता है। हमने देखा कि समस्या से कुछ समय पहले, ओपनशिफ्ट डेडिकेटेड क्लस्टर (जो quay.io चलाता है) ने संस्करण 4.3.19 में अपडेट करना शुरू कर दिया था। चूँकि quay.io Red Hat OpenShift Dedicated (OSD) पर चलता है, नियमित अपडेट नियमित थे और कभी भी समस्याएँ पैदा नहीं हुईं। इसके अलावा, पिछले छह महीनों में, हमने सेवा में किसी भी रुकावट के बिना क्वे क्लस्टर्स को कई बार अपग्रेड किया है।

जब हम सेवा को बहाल करने की कोशिश कर रहे थे, तो अन्य इंजीनियरों ने सॉफ्टवेयर के पिछले संस्करण के साथ एक नया ओएसडी क्लस्टर तैयार करना शुरू कर दिया, ताकि अगर कुछ हुआ, तो वे उस पर सब कुछ तैनात कर सकें।

मूल कारण विश्लेषण

विफलता का मुख्य लक्षण हजारों डेटाबेस कनेक्शनों का हिमस्खलन था, जिसने MySQL इंस्टेंस को प्रभावी रूप से निष्क्रिय कर दिया। इससे समस्या का निदान करना मुश्किल हो गया। हमने एसआरई टीम को समस्या का मूल्यांकन करने में मदद करने के लिए ग्राहकों से कनेक्शन की अधिकतम संख्या पर एक सीमा निर्धारित की है। हमने डेटाबेस में कोई असामान्य ट्रैफ़िक नहीं देखा: वास्तव में, अधिकांश अनुरोध पढ़े गए थे, और केवल कुछ ही लिखे गए थे।

हमने डेटाबेस ट्रैफ़िक में एक पैटर्न की पहचान करने का भी प्रयास किया जो इस हिमस्खलन का कारण बन सकता है। हालाँकि, हमें लॉग में कोई पैटर्न नहीं मिला। ओएसडी 4.3.18 के साथ नए क्लस्टर के तैयार होने की प्रतीक्षा करते हुए, हमने quay.io पॉड्स लॉन्च करने का प्रयास जारी रखा। हर बार जब क्लस्टर पूरी क्षमता तक पहुँच जाता, तो डेटाबेस फ़्रीज़ हो जाता। इसका मतलब यह था कि सभी quay.io पॉड्स के अलावा RDS इंस्टेंस को पुनः आरंभ करना आवश्यक था।

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

Quay.io ने नए OSD क्लस्टर पर स्थिर रूप से काम किया, इसलिए हम डेटाबेस लॉग पर वापस गए, लेकिन ऐसा कोई सहसंबंध नहीं मिला जो रुकावटों को समझा सके। OpenShift इंजीनियरों ने यह समझने के लिए हमारे साथ काम किया कि क्या Red Hat OpenShift 4.3.19 में परिवर्तन क्वे के साथ समस्याएँ पैदा कर सकता है। हालाँकि, कुछ भी नहीं मिला, और प्रयोगशाला स्थितियों में समस्या को पुन: उत्पन्न करना संभव नहीं था.

दूसरी विफलता

28 मई को, दोपहर EDT से कुछ समय पहले, quay.io उसी लक्षण के साथ फिर से क्रैश हो गया: डेटाबेस अवरुद्ध हो गया था। और फिर से हमने अपने सभी प्रयास जांच में झोंक दिए। सबसे पहले सेवा बहाल करना जरूरी था. तथापि इस बार RDS को रीबूट करने और quay.io पॉड्स को रीस्टार्ट करने से कुछ नहीं हुआ: कनेक्शनों के एक और हिमस्खलन ने आधार को अभिभूत कर दिया है। लेकिन क्यों?

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

क्वे पॉड्स की महत्वपूर्ण संख्या और प्रति सेकंड आने वाले हजारों अनुरोधों को देखते हुए, बड़ी संख्या में डेटाबेस कनेक्शन सैद्धांतिक रूप से MySQL उदाहरण को प्रभावित कर सकते हैं। निगरानी के लिए धन्यवाद, यह ज्ञात हुआ कि क्वे प्रति सेकंड औसतन 5 हजार अनुरोधों को संसाधित करता है। डेटाबेस से कनेक्शन की संख्या लगभग समान थी। 5 हजार कनेक्शन हमारे आरडीएस उदाहरण की क्षमताओं के भीतर थे (जो हजारों के बारे में नहीं कहा जा सकता)। किसी कारण से कनेक्शनों की संख्या में अप्रत्याशित वृद्धि हुईहालाँकि, हमें आने वाले अनुरोधों के साथ कोई संबंध नज़र नहीं आया।

इस बार हम समस्या के स्रोत को खोजने और उसे खत्म करने के लिए दृढ़ थे, न कि खुद को रिबूट तक सीमित रखने के लिए। क्वे कोडबेस के लिए प्रत्येक कार्यकर्ता के लिए डेटाबेस में कनेक्शन की संख्या सीमित करने के लिए परिवर्तन किए गए थे gevent. यह संख्या कॉन्फ़िगरेशन में एक पैरामीटर बन गई: नई कंटेनर छवि बनाए बिना इसे तुरंत बदलना संभव हो गया। यह पता लगाने के लिए कि कितने कनेक्शनों को वास्तविक रूप से संभाला जा सकता है, हमने स्टेजिंग वातावरण में कई परीक्षण चलाए, यह देखने के लिए अलग-अलग मान सेट किए कि यह लोड परीक्षण परिदृश्यों को कैसे प्रभावित करेगा। परिणामस्वरूप, यह पता चला जब कनेक्शन की संख्या 502 हजार से अधिक हो जाती है तो क्वे 10 त्रुटियां देना शुरू कर देता है।

हमने तुरंत इस नए संस्करण को उत्पादन में तैनात किया और डेटाबेस कनेक्शन शेड्यूल की निगरानी शुरू कर दी। पिछले दिनों करीब 20 मिनट बाद बेस को लॉक कर दिया गया था. 30 परेशानी-मुक्त मिनटों के बाद हमें आशा थी, और एक घंटे बाद हमें विश्वास था। हमने साइट पर यातायात बहाल किया और पोस्टमॉर्टम विश्लेषण शुरू किया।

अवरोध पैदा करने वाली समस्या को दूर करने में कामयाब होने के बाद, हमें इसके वास्तविक कारणों का पता नहीं चला है. यह पुष्टि की गई कि यह ओपनशिफ्ट 4.3.19 में किसी भी बदलाव से संबंधित नहीं है, क्योंकि संस्करण 4.3.18 पर भी यही हुआ था, जो पहले क्वे के साथ बिना किसी समस्या के काम करता था।

क्लस्टर में स्पष्ट रूप से कुछ और छिपा हुआ था।

विस्तृत अध्ययन

Quay.io ने बिना किसी समस्या के छह साल तक डेटाबेस से जुड़ने के लिए डिफ़ॉल्ट सेटिंग्स का उपयोग किया। क्या बदल गया? यह स्पष्ट है कि इस समय quay.io पर ट्रैफ़िक लगातार बढ़ रहा है। हमारे मामले में, ऐसा लग रहा था जैसे कुछ सीमा मान तक पहुंच गया है, जो कनेक्शन के हिमस्खलन के लिए ट्रिगर के रूप में कार्य करता है। हमने दूसरी विफलता के बाद डेटाबेस लॉग का अध्ययन करना जारी रखा, लेकिन कोई पैटर्न या स्पष्ट संबंध नहीं मिला।

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

Quay.io ने 9 जून तक ठीक काम किया। आज सुबह (EDT) हमने फिर से डेटाबेस कनेक्शनों की संख्या में उल्लेखनीय वृद्धि देखी। इस बार कोई डाउनटाइम नहीं था, क्योंकि नए पैरामीटर ने उनकी संख्या सीमित कर दी और उन्हें MySQL थ्रूपुट से अधिक होने की अनुमति नहीं दी। हालाँकि, लगभग आधे घंटे तक, कई उपयोगकर्ताओं ने quay.io के धीमे प्रदर्शन पर ध्यान दिया। हमने अतिरिक्त निगरानी उपकरणों का उपयोग करके तुरंत सभी संभावित डेटा एकत्र किया। अचानक एक पैटर्न उभर कर सामने आया.

कनेक्शनों में उछाल से ठीक पहले, ऐप रजिस्ट्री एपीआई के लिए बड़ी संख्या में अनुरोध किए गए थे. ऐप रजिस्ट्री quay.io की एक अल्पज्ञात सुविधा है। यह आपको हेल्म चार्ट और समृद्ध मेटाडेटा वाले कंटेनर जैसी चीज़ों को संग्रहीत करने की अनुमति देता है। अधिकांश quay.io उपयोगकर्ता इस सुविधा के साथ काम नहीं करते हैं, लेकिन Red Hat OpenShift सक्रिय रूप से इसका उपयोग करता है। ओपनशिफ्ट के हिस्से के रूप में ऑपरेटरहब सभी ऑपरेटरों को ऐप रजिस्ट्री में संग्रहीत करता है। ये ऑपरेटर ओपनशिफ्ट वर्कलोड इकोसिस्टम और पार्टनर-केंद्रित ऑपरेटिंग मॉडल (दिन 2 संचालन) के लिए आधार बनाते हैं।

प्रत्येक ओपनशिफ्ट 4 क्लस्टर इंस्टॉलेशन के लिए उपलब्ध ऑपरेटरों की एक सूची प्रकाशित करने और पहले से इंस्टॉल किए गए ऑपरेटरों को अपडेट प्रदान करने के लिए अंतर्निहित ऑपरेटरहब से ऑपरेटरों का उपयोग करता है। ओपनशिफ्ट 4 की बढ़ती लोकप्रियता के साथ, दुनिया भर में इस पर क्लस्टर की संख्या भी बढ़ गई है। इनमें से प्रत्येक क्लस्टर बैकएंड के रूप में quay.io के अंदर ऐप रजिस्ट्री का उपयोग करके, अंतर्निहित ऑपरेटरहब को चलाने के लिए ऑपरेटर सामग्री डाउनलोड करता है। समस्या के स्रोत की खोज में, हम इस तथ्य से चूक गए कि जैसे-जैसे ओपनशिफ्ट की लोकप्रियता धीरे-धीरे बढ़ती गई, शायद ही कभी इस्तेमाल किए जाने वाले quay.io फ़ंक्शंस में से एक पर लोड भी बढ़ गया।.

हमने ऐप रजिस्ट्री अनुरोध ट्रैफ़िक का कुछ विश्लेषण किया और रजिस्ट्री कोड पर एक नज़र डाली। तुरंत ही कमियाँ उजागर हो गईं, जिसके कारण डेटाबेस में क्वेरीज़ का गठन बेहतर ढंग से नहीं हो सका। जब लोड कम था तो उन्हें कोई परेशानी नहीं हुई, लेकिन जब लोड बढ़ गया तो वे परेशानी का सबब बन गए। ऐप रजिस्ट्री में दो समस्याग्रस्त समापन बिंदु निकले जो बढ़ते लोड पर अच्छी प्रतिक्रिया नहीं देते थे: पहले ने रिपॉजिटरी में सभी पैकेजों की एक सूची प्रदान की, दूसरे ने पैकेज के लिए सभी ब्लॉब्स लौटा दिए।

कारणों का उन्मूलन

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

जिन एपीआई अनुरोधों को पहले आधे मिनट तक पूरा होता था, वे अब मिलीसेकंड में पूरे हो जाते हैं. अगले सप्ताह हमने उत्पादन में परिवर्तन लागू किए, और तब से quay.io स्थिर रूप से काम कर रहा है। इस दौरान, ऐप रजिस्ट्री एंडपॉइंट पर ट्रैफ़िक में कई तेज बढ़ोतरी हुई, लेकिन किए गए सुधारों ने डेटाबेस आउटेज को रोक दिया।

हमने क्या सीखा?

यह स्पष्ट है कि कोई भी सेवा डाउनटाइम से बचने का प्रयास करती है। हमारे मामले में, हमारा मानना ​​है कि हालिया रुकावटों ने quay.io को बेहतर बनाने में मदद की है। हमने कुछ प्रमुख सबक सीखे हैं जिन्हें हम साझा करना चाहेंगे:

1. आपकी सेवा का उपयोग कौन और कैसे करता है, इसका डेटा कभी भी अतिश्योक्तिपूर्ण नहीं होता. क्योंकि क्वे ने "बस काम किया", हमें ट्रैफ़िक को अनुकूलित करने और लोड प्रबंधित करने में कभी समय नहीं लगाना पड़ा। इस सबने सुरक्षा की झूठी भावना पैदा की कि सेवा अनिश्चित काल तक बढ़ सकती है।
2. जब सेवा बंद हो जाती है, इसे वापस खड़ा करना और चलाना सर्वोच्च प्राथमिकता है।. चूँकि क्वे पहले आउटेज के दौरान लॉक्ड डेटाबेस से पीड़ित रहा, हमारी मानक प्रक्रियाओं का अपेक्षित प्रभाव नहीं पड़ा और हम उनका उपयोग करके सेवा को बहाल करने में असमर्थ रहे। इससे ऐसी स्थिति पैदा हो गई जहां कार्यक्षमता बहाल करने पर सभी प्रयासों पर ध्यान केंद्रित करने के बजाय मूल कारण खोजने की उम्मीद में डेटा का विश्लेषण और संग्रह करने में समय व्यतीत करना पड़ा।
3. प्रत्येक सेवा सुविधा के प्रभाव का मूल्यांकन करें. ग्राहक शायद ही कभी ऐप रजिस्ट्री का उपयोग करते थे, इसलिए यह हमारी टीम के लिए प्राथमिकता नहीं थी। जब कुछ उत्पाद सुविधाओं का बमुश्किल उपयोग किया जाता है, तो उनके बग शायद ही कभी दिखाई देते हैं, और डेवलपर्स कोड की निगरानी करना बंद कर देते हैं। इस ग़लतफ़हमी का शिकार होना आसान है कि ऐसा ही होना चाहिए - जब तक कि अचानक वह कार्य स्वयं को किसी बड़ी घटना के केंद्र में न पा ले।

आगे क्या है?

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

1. प्राथमिक आरडीएस उदाहरण के साथ समस्याओं की स्थिति में सेवा को उचित ट्रैफ़िक संभालने में मदद करने के लिए रीड-ओनली डेटाबेस प्रतिकृतियां तैनात करें।
2. आरडीएस उदाहरण अद्यतन कर रहा है। वर्तमान संस्करण ही समस्या नहीं है. बल्कि, हम केवल उस झूठे रास्ते को हटाना चाहते हैं (जिसका अनुसरण हमने विफलता के दौरान किया था); सॉफ़्टवेयर को अद्यतन रखने से भविष्य में रुकावटों की स्थिति में एक और कारक समाप्त हो जाएगा।
3. संपूर्ण क्लस्टर में अतिरिक्त कैशिंग. हम उन क्षेत्रों की तलाश जारी रखते हैं जहां कैशिंग डेटाबेस पर लोड को कम कर सकती है।
4. यह देखने के लिए एक वेब एप्लिकेशन फ़ायरवॉल (WAF) जोड़ना कि quay.io से कौन कनेक्ट हो रहा है और क्यों।
5. अगली रिलीज से शुरू होकर, Red Hat OpenShift क्लस्टर quay.io पर उपलब्ध कंटेनर छवियों के आधार पर ऑपरेटर कैटलॉग के पक्ष में ऐप रजिस्ट्री को छोड़ देगा।
6. ऐप रजिस्ट्री के लिए दीर्घकालिक प्रतिस्थापन ओपन कंटेनर इनिशिएटिव (ओसीआई) आर्टिफैक्ट विनिर्देशों के लिए समर्थन हो सकता है। इसे वर्तमान में मूल क्वे कार्यक्षमता के रूप में कार्यान्वित किया गया है और विनिर्देश को अंतिम रूप दिए जाने पर यह उपयोगकर्ताओं के लिए उपलब्ध होगा।

उपरोक्त सभी Red Hat के quay.io में चल रहे निवेश का हिस्सा हैं क्योंकि हम एक छोटी "स्टार्टअप-शैली" टीम से एक परिपक्व SRE-संचालित प्लेटफ़ॉर्म की ओर बढ़ रहे हैं। हम जानते हैं कि हमारे कई ग्राहक अपने दैनिक कार्य (रेड हैट सहित!) में quay.io पर भरोसा करते हैं और हम हाल के आउटेज और सुधार के लिए चल रहे प्रयासों के बारे में यथासंभव पारदर्शी रहने का प्रयास करते हैं।

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «CoreOS कंटेनर छवियों के लिए Red Hat ओपन सोर्स रजिस्ट्री कोड - क्वे";
• «हमारे एसआरई रोजमर्रा की जिंदगी से व्यावहारिक कहानियाँ। भाग 2";
• «कुबेरनेट्स में पॉड प्राथमिकताओं के कारण ग्राफाना लैब्स में डाउनटाइम कैसे हुआ'.

स्रोत: www.habr.com