Quay.io अनुपलब्धता वर शवविच्छेदन

नोंद. अनुवाद: ऑगस्टच्या सुरुवातीस, Red Hat ने त्याच्या सेवेच्या वापरकर्त्यांना मागील महिन्यांत आलेल्या प्रवेशयोग्यतेच्या समस्या सोडवण्याबद्दल सार्वजनिकपणे सांगितले. Quay.io (हे कंटेनर प्रतिमांच्या नोंदणीवर आधारित आहे, जे कंपनीने CoreOS च्या खरेदीसह प्राप्त केले होते). या सेवेमध्ये तुमची स्वारस्य कितीही असली तरी, कंपनीच्या SRE अभियंत्यांनी अपघाताची कारणे शोधून काढण्यासाठी जो मार्ग स्वीकारला तो बोधप्रद आहे.

19 मे रोजी, पहाटे (ईस्टर्न डेलाइट टाइम, EDT), quay.io सेवा क्रॅश झाली. या दुर्घटनेमुळे quay.io ग्राहक आणि मुक्त स्रोत प्रकल्प दोन्ही प्रभावित झाले quay.io हे सॉफ्टवेअर तयार करण्यासाठी आणि वितरणासाठी व्यासपीठ म्हणून वापरत आहे. रेड हॅट दोघांच्या विश्वासाला महत्त्व देते.

SRE अभियंत्यांची एक टीम ताबडतोब सामील झाली आणि शक्य तितक्या लवकर क्वे सेवा स्थिर करण्याचा प्रयत्न केला. तथापि, ते हे करत असताना, क्लायंटने नवीन प्रतिमा पुश करण्याची क्षमता गमावली आणि केवळ अधूनमधून ते विद्यमान प्रतिमा खेचण्यास सक्षम होते. काही अज्ञात कारणास्तव, quay.io डेटाबेस पूर्ण क्षमतेने सेवा स्केल केल्यानंतर अवरोधित करण्यात आला.

«काय बदलले आहे?"- हा पहिला प्रश्न आहे जो सहसा अशा प्रकरणांमध्ये विचारला जातो. आमच्या लक्षात आले की इश्यूच्या काही काळापूर्वी, OpenShift समर्पित क्लस्टर (जे quay.io चालवते) आवृत्ती 4.3.19 वर अपडेट होण्यास सुरुवात झाली. quay.io Red Hat OpenShift Dedicated (OSD) वर चालत असल्याने, नियमित अद्यतने नित्याचीच होती आणि कधीही समस्या उद्भवत नाहीत. शिवाय, मागील सहा महिन्यांत, आम्ही सेवेतील कोणत्याही व्यत्ययाशिवाय अनेक वेळा क्वे क्लस्टर्स अपग्रेड केले आहेत.

आम्ही सेवा पुनर्संचयित करण्याचा प्रयत्न करत असताना, इतर अभियंत्यांनी सॉफ्टवेअरच्या मागील आवृत्तीसह एक नवीन OSD क्लस्टर तयार करण्यास सुरुवात केली, जेणेकरुन काही घडल्यास, ते त्यावर सर्वकाही तैनात करू शकतील.

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

अयशस्वी होण्याचे मुख्य लक्षण म्हणजे हजारो डेटाबेस कनेक्शनचे हिमस्खलन, ज्याने MySQL उदाहरण प्रभावीपणे अक्षम केले. त्यामुळे समस्येचे निदान करणे कठीण झाले. SRE टीमला समस्येचे मूल्यांकन करण्यात मदत करण्यासाठी आम्ही क्लायंटकडून जास्तीत जास्त कनेक्शनची मर्यादा सेट केली आहे. आम्हाला डेटाबेसवर कोणतीही असामान्य रहदारी आढळली नाही: खरं तर, बहुतेक विनंत्या वाचल्या गेल्या आणि फक्त काही लिहिल्या गेल्या.

आम्ही डेटाबेस ट्रॅफिकमधील पॅटर्न ओळखण्याचा प्रयत्न केला ज्यामुळे हे हिमस्खलन होऊ शकते. तथापि, आम्हाला नोंदींमध्ये कोणतेही नमुने सापडले नाहीत. OSD 4.3.18 सह नवीन क्लस्टर तयार होण्याची वाट पाहत असताना, आम्ही quay.io पॉड्स लाँच करण्याचा प्रयत्न सुरू ठेवला. प्रत्येक वेळी जेव्हा क्लस्टर पूर्ण क्षमतेने पोहोचेल तेव्हा डेटाबेस गोठवला जाईल. याचा अर्थ सर्व quay.io पॉड्स व्यतिरिक्त RDS इन्स्टन्स रीस्टार्ट करणे आवश्यक होते.

संध्याकाळपर्यंत, आम्ही सेवा केवळ-वाचनीय मोडमध्ये स्थिर केली आणि डेटाबेसवरील भार कमी करण्यासाठी शक्य तितक्या अनावश्यक कार्ये (उदाहरणार्थ, नेमस्पेस कचरा संकलन) अक्षम केली. गोठणे थांबले आहे पण कारण सापडले नाही. नवीन OSD क्लस्टर तयार होता, आणि आम्ही सेवा स्थलांतरित केली, रहदारी जोडली आणि सतत देखरेख ठेवली.

Quay.io ने नवीन OSD क्लस्टरवर स्थिरपणे काम केले, म्हणून आम्ही डेटाबेस लॉगवर परत गेलो, परंतु अवरोधांचे स्पष्टीकरण देणारा परस्परसंबंध सापडला नाही. Red Hat OpenShift 4.3.19 मधील बदल Quay मध्ये समस्या निर्माण करू शकतात की नाही हे समजून घेण्यासाठी OpenShift अभियंत्यांनी आमच्यासोबत काम केले. तथापि, काहीही आढळले नाही, आणि प्रयोगशाळेच्या परिस्थितीत समस्येचे पुनरुत्पादन करणे शक्य नव्हते.

दुसरे अपयश

28 मे रोजी, दुपारच्या काही वेळापूर्वी EDT, quay.io त्याच लक्षणासह पुन्हा क्रॅश झाले: डेटाबेस अवरोधित केला गेला. आणि पुन्हा आम्ही आमचे सर्व प्रयत्न तपासात टाकले. सर्व प्रथम, सेवा पुनर्संचयित करणे आवश्यक होते. तथापि यावेळी RDS रीबूट करून आणि quay.io पॉड्स रीस्टार्ट करून काहीही झाले नाही: कनेक्शनच्या आणखी एका हिमस्खलनाने पाया ओलांडला आहे. पण का?

Quay पायथनमध्ये लिहिलेले आहे आणि प्रत्येक पॉड एकल मोनोलिथिक कंटेनर म्हणून कार्य करते. कंटेनर रनटाइम अनेक समांतर कार्ये एकाच वेळी चालवतो. आम्ही लायब्ररी वापरतो gevent अंतर्गत gunicorn वेब विनंत्यांची प्रक्रिया करण्यासाठी. जेव्हा एखादी विनंती Quay मध्ये येते (आमच्या स्वतःच्या API द्वारे, किंवा Docker's API द्वारे), तेव्हा ती gevent वर्कर नियुक्त केली जाते. सामान्यतः या कामगाराने डेटाबेसशी संपर्क साधावा. पहिल्या अपयशानंतर, आम्हाला आढळले की जेव्हेंट कामगार डीफॉल्ट सेटिंग्ज वापरून डेटाबेसशी कनेक्ट होत आहेत.

क्वे पॉड्सची लक्षणीय संख्या आणि प्रति सेकंद हजारो येणार्‍या विनंत्या लक्षात घेता, मोठ्या संख्येने डेटाबेस कनेक्शन्स सैद्धांतिकदृष्ट्या MySQL उदाहरणावर मात करू शकतात. निरीक्षण केल्याबद्दल धन्यवाद, हे ज्ञात होते की क्वे प्रति सेकंद सरासरी 5 हजार विनंत्यांची प्रक्रिया करते. डेटाबेसमधील कनेक्शनची संख्या अंदाजे समान होती. 5 हजार कनेक्शन आमच्या RDS उदाहरणाच्या क्षमतेमध्ये चांगले होते (ज्याला हजारो बद्दल सांगता येत नाही). काही कारणास्तव कनेक्शनच्या संख्येत अनपेक्षित वाढ झाली, तथापि, आम्हाला येणार्‍या विनंत्यांशी कोणताही संबंध आढळला नाही.

या वेळी आम्ही समस्येचा स्रोत शोधून काढून टाकण्याचा आणि रीबूट करण्यापर्यंत मर्यादित न राहण्याचा निर्धार केला. क्वे कोडबेसला प्रत्येक कामगारासाठी डेटाबेसशी जोडणीची संख्या मर्यादित करण्यासाठी बदल केले गेले gevent हा क्रमांक कॉन्फिगरेशनमध्ये एक पॅरामीटर बनला: नवीन कंटेनर प्रतिमा तयार केल्याशिवाय फ्लायवर बदलणे शक्य झाले. किती कनेक्शन्स वास्तविकपणे हाताळले जाऊ शकतात हे शोधण्यासाठी, आम्ही स्टेजिंग वातावरणात अनेक चाचण्या केल्या, लोड चाचणी परिस्थितींवर याचा कसा परिणाम होईल हे पाहण्यासाठी भिन्न मूल्ये सेट केली. परिणामी, असे आढळून आले जेव्हा कनेक्शनची संख्या 502 हजार पेक्षा जास्त असेल तेव्हा Quay 10 त्रुटी टाकण्यास सुरवात करते.

आम्ही ताबडतोब ही नवीन आवृत्ती उत्पादनासाठी तैनात केली आणि डेटाबेस कनेक्शन शेड्यूलचे निरीक्षण करण्यास सुरुवात केली. पूर्वी, सुमारे 20 मिनिटांनी तळ लॉक केला जात असे. 30 समस्यामुक्त मिनिटांनंतर आम्हाला आशा होती आणि एक तासानंतर आम्हाला आत्मविश्वास मिळाला. आम्ही साइटवर रहदारी पुनर्संचयित केली आणि पोस्टमॉर्टम विश्लेषण सुरू केले.

अवरोधित होण्याच्या समस्येला बायपास करण्यात व्यवस्थापित केल्यामुळे, त्याची खरी कारणे आपल्याला सापडलेली नाहीत. हे OpenShift 4.3.19 मधील कोणत्याही बदलांशी संबंधित नाही याची पुष्टी करण्यात आली, कारण तीच गोष्ट आवृत्ती 4.3.18 वर घडली होती, जी पूर्वी Quay सह कोणत्याही समस्यांशिवाय काम करत होती.

क्लस्टरमध्ये आणखी काहीतरी लपलेले स्पष्टपणे दिसत होते.

तपशीलवार अभ्यास

Quay.io ने कोणत्याही समस्यांशिवाय सहा वर्षांसाठी डेटाबेसशी कनेक्ट होण्यासाठी डीफॉल्ट सेटिंग्ज वापरली. काय बदलले? हे स्पष्ट आहे की या सर्व काळात quay.io वरील रहदारी सतत वाढत आहे. आमच्या बाबतीत, असे दिसते की काही थ्रेशोल्ड मूल्य गाठले आहे, जे कनेक्शनच्या हिमस्खलनासाठी ट्रिगर म्हणून काम करते. दुसऱ्या अपयशानंतर आम्ही डेटाबेस लॉगचा अभ्यास करणे सुरू ठेवले, परंतु कोणतेही नमुने किंवा स्पष्ट संबंध आढळले नाहीत.

यादरम्यान, SRE टीम क्वेच्या विनंती निरीक्षणक्षमता आणि एकूणच सेवा आरोग्यामध्ये सुधारणांवर काम करत आहे. नवीन मेट्रिक्स आणि डॅशबोर्ड तैनात केले गेले आहेत, क्वेच्या कोणत्या भागांना ग्राहकांकडून सर्वाधिक मागणी आहे हे दर्शविते.

Quay.io ने 9 जूनपर्यंत चांगले काम केले. आज सकाळी (EDT) आम्ही पुन्हा डेटाबेस कनेक्शनच्या संख्येत लक्षणीय वाढ पाहिली. यावेळी कुठेही डाउनटाइम नव्हता, कारण नवीन पॅरामीटरने त्यांची संख्या मर्यादित केली आहे आणि त्यांना MySQL थ्रुपुट ओलांडण्याची परवानगी दिली नाही. तथापि, सुमारे अर्धा तास, अनेक वापरकर्त्यांनी quay.io ची संथ कामगिरी नोंदवली. जोडलेल्या मॉनिटरिंग टूल्सचा वापर करून आम्ही सर्व संभाव्य डेटा पटकन गोळा केला. अचानक एक नमुना समोर आला.

कनेक्शनमध्ये वाढ होण्यापूर्वी, अॅप नोंदणी API ला मोठ्या प्रमाणात विनंत्या करण्यात आल्या. अॅप रजिस्ट्री हे quay.io चे थोडेसे ज्ञात वैशिष्ट्य आहे. हे तुम्हाला हेल्म चार्ट आणि समृद्ध मेटाडेटा असलेले कंटेनर यासारख्या गोष्टी संचयित करण्यास अनुमती देते. बहुतेक quay.io वापरकर्ते या वैशिष्ट्यासह कार्य करत नाहीत, परंतु Red Hat OpenShift सक्रियपणे ते वापरतात. OperatorHub OpenShift चा भाग म्हणून अॅप रजिस्ट्रीमध्ये सर्व ऑपरेटर स्टोअर करते. हे ऑपरेटर OpenShift वर्कलोड इकोसिस्टम आणि भागीदार-केंद्रित ऑपरेटिंग मॉडेल (दिवस 2 ऑपरेशन्स) साठी आधार तयार करतात.

प्रत्‍येक OpenShift 4 क्‍लस्‍टर इंस्‍टॉलेशनसाठी उपलब्‍ध असलेल्‍या ऑपरेटरची कॅटलॉग प्रकाशित करण्‍यासाठी अंगभूत ऑपरेटरहबमधील ऑपरेटर वापरतो आणि आधीपासून इन्‍स्‍टॉल केलेल्यांना अपडेट पुरवतो. OpenShift 4 च्या वाढत्या लोकप्रियतेसह, जगभरातील क्लस्टर्सची संख्या देखील वाढली आहे. यातील प्रत्येक क्लस्टर अंगभूत OperatorHub चालविण्यासाठी ऑपरेटर सामग्री डाउनलोड करते, बॅकएंड म्हणून quay.io च्या आत अॅप रजिस्ट्री वापरून. समस्येच्या स्त्रोताच्या शोधात, आम्ही हे तथ्य गमावले की जसजसे OpenShift हळूहळू लोकप्रिय होत गेले, क्वचितच वापरल्या जाणार्‍या quay.io फंक्शन्सपैकी एकावरील लोड देखील वाढला..

आम्ही अॅप रेजिस्ट्री विनंती ट्रॅफिकचे काही विश्लेषण केले आणि रेजिस्ट्री कोडवर एक नजर टाकली. ताबडतोब, उणीवा उघड झाल्या, ज्यामुळे डेटाबेसमधील क्वेरी चांगल्या प्रकारे तयार झाल्या नाहीत. भारनियमन कमी असताना त्यांना कोणताही त्रास झाला नाही, परंतु जेव्हा भार वाढला, तेव्हा ते समस्यांचे कारण बनले. अॅप रेजिस्ट्रीमध्ये दोन समस्याप्रधान एंडपॉइंट्स असल्याचे दिसून आले ज्यांनी वाढत्या लोडला चांगला प्रतिसाद दिला नाही: पहिल्याने रेपॉजिटरीमधील सर्व पॅकेजेसची सूची प्रदान केली, दुसऱ्याने पॅकेजसाठी सर्व ब्लॉब परत केले.

कारणे दूर करणे

पुढील आठवड्यात आम्ही अॅप रजिस्ट्रीचा कोड आणि त्याचे वातावरण ऑप्टिमाइझ करण्यात घालवला. स्पष्टपणे कुचकामी SQL क्वेरी पुन्हा तयार केल्या गेल्या आणि अनावश्यक कमांड कॉल काढून टाकले गेले tar (प्रत्येक वेळी blobs पुनर्प्राप्त केले गेले तेव्हा ते चालवले गेले), जेथे शक्य असेल तेथे कॅशिंग जोडले गेले. त्यानंतर आम्ही व्यापक कामगिरी चाचणी घेतली आणि बदलांपूर्वी आणि नंतर अॅप नोंदणीच्या गतीची तुलना केली.

आधी अर्ध्या मिनिटापर्यंत लागणाऱ्या API विनंत्या आता मिलिसेकंदांमध्ये पूर्ण केल्या जातात. पुढच्या आठवड्यात आम्ही उत्पादनात बदल तैनात केले आणि तेव्हापासून quay.io स्थिरपणे काम करत आहे. या वेळी, अॅप रेजिस्ट्री एंडपॉईंटवर ट्रॅफिकमध्ये अनेक तीक्ष्ण वाढ झाली होती, परंतु केलेल्या सुधारणांमुळे डेटाबेस आउटेज टाळले गेले.

आम्ही काय शिकलो?

हे स्पष्ट आहे की कोणतीही सेवा डाउनटाइम टाळण्याचा प्रयत्न करते. आमच्या बाबतीत, आम्हाला विश्वास आहे की अलीकडील आउटेजमुळे quay.io अधिक चांगले बनण्यास मदत झाली आहे. आम्ही काही महत्त्वाचे धडे शिकलो आहोत जे आम्हाला सामायिक करायचे आहे:

1. तुमची सेवा कोण वापरते आणि कशी वापरते याचा डेटा कधीही अनावश्यक नसतो. क्वेने "फक्त काम केले" म्हणून, आम्हाला रहदारी अनुकूल करण्यात आणि भार व्यवस्थापित करण्यात वेळ घालवावा लागला नाही. या सर्वांमुळे सुरक्षिततेची खोटी भावना निर्माण झाली की सेवा अनिश्चित काळासाठी स्केल होऊ शकते.
2. सेवा बंद झाल्यावर, ते परत मिळवणे आणि चालवणे ही सर्वोच्च प्राथमिकता आहे.. पहिल्या आउटेज दरम्यान Quay ला लॉक केलेल्या डेटाबेसचा त्रास होत असल्यामुळे, आमच्या मानक प्रक्रियेचा अपेक्षित परिणाम झाला नाही आणि आम्ही त्यांचा वापर करून सेवा पुनर्संचयित करण्यात अक्षम होतो. यामुळे अशी परिस्थिती निर्माण झाली जिथे कार्यक्षमता पुनर्संचयित करण्यासाठी सर्व प्रयत्नांवर लक्ष केंद्रित करण्याऐवजी - मूळ कारण शोधण्याच्या आशेने डेटाचे विश्लेषण आणि संकलन करण्यात वेळ घालवावा लागला.
3. प्रत्येक सेवा वैशिष्ट्याच्या प्रभावाचे मूल्यांकन करा. क्लायंट क्वचितच अॅप रजिस्ट्री वापरतात, त्यामुळे आमच्या टीमसाठी ते प्राधान्य नव्हते. जेव्हा काही उत्पादन वैशिष्ट्ये क्वचितच वापरली जातात, तेव्हा त्यांचे बग क्वचितच दिसतात आणि विकासक कोडचे निरीक्षण करणे थांबवतात. हे असेच असावे या गैरसमजाला बळी पडणे सोपे आहे - जोपर्यंत अचानक ते कार्य एखाद्या मोठ्या घटनेच्या केंद्रस्थानी सापडत नाही.

पुढील काय आहे?

सेवेची स्थिरता सुनिश्चित करण्याचे काम कधीही थांबत नाही आणि आम्ही त्यात सातत्याने सुधारणा करत आहोत. quay.io वर ट्रॅफिक व्हॉल्यूम वाढत असल्याने, आम्ही ओळखतो की आमच्या ग्राहकांच्या विश्वासाप्रत राहण्यासाठी आम्ही जे काही करू शकतो ते करण्याची आमची जबाबदारी आहे. म्हणून, आम्ही सध्या खालील कार्यांवर काम करत आहोत:

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

वरील सर्व गोष्टी Red Hat च्या quay.io मध्ये चालू असलेल्या गुंतवणुकीचा भाग आहेत कारण आम्ही एका लहान "स्टार्टअप-शैली" टीममधून प्रौढ SRE-चालित प्लॅटफॉर्मवर जातो. आम्हाला माहित आहे की आमचे बरेच ग्राहक त्यांच्या दैनंदिन कामात (Red Hat!) मध्ये quay.io वर अवलंबून असतात आणि आम्ही अलीकडील आउटेज आणि सुधारण्यासाठी चालू असलेल्या प्रयत्नांबद्दल शक्य तितके पारदर्शक राहण्याचा प्रयत्न करतो.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «CoreOS कंटेनर प्रतिमांसाठी Red Hat ओपन सोर्स रेजिस्ट्री कोड - क्वे";
• «आमच्या SRE दैनंदिन जीवनातील व्यावहारिक कथा. भाग 2";
• «Kubernetes मधील पॉड प्राधान्यक्रमांमुळे Grafana Labs मध्ये डाउनटाइम कसा झाला».

स्त्रोत: www.habr.com