Kubernetes मधील पॉड प्राधान्यक्रमांमुळे Grafana Labs मध्ये डाउनटाइम कसा झाला

नोंद. अनुवाद: Grafana च्या निर्मात्यांनी राखलेल्या क्लाउड सेवेतील अलीकडील डाउनटाइमच्या कारणांबद्दल आम्ही तुमच्या लक्षांत तांत्रिक तपशील सादर करतो. पायाभूत सुविधांची गुणवत्ता सुधारण्यासाठी डिझाइन केलेले एक नवीन आणि वरवर अत्यंत उपयुक्त वैशिष्ट्य कसे आहे याचे हे उत्कृष्ट उदाहरण आहे... आपण उत्पादनाच्या वास्तविकतेमध्ये त्याच्या अनुप्रयोगातील असंख्य बारकावे प्रदान न केल्यास ते नुकसान होऊ शकते. जेव्हा यासारखे साहित्य दिसते जे तुम्हाला केवळ तुमच्या चुकांमधूनच शिकण्याची परवानगी देत ​​​​नाही तेव्हा हे छान आहे. Grafana Labs मधील उत्पादनाच्या उपाध्यक्षांकडून या मजकुराच्या भाषांतरात तपशील आहेत.

शुक्रवारी, 19 जुलै रोजी, ग्राफाना क्लाउडमधील होस्ट केलेल्या प्रोमिथियस सेवेने अंदाजे 30 मिनिटे कार्य करणे थांबवले. आउटेजमुळे प्रभावित झालेल्या सर्व ग्राहकांची मी माफी मागतो. आमचे कार्य तुम्हाला आवश्यक असलेली देखरेख साधने प्रदान करणे आहे आणि आम्ही समजतो की ते उपलब्ध न केल्याने तुमचे जीवन अधिक कठीण होऊ शकते. आम्ही ही घटना अत्यंत गांभीर्याने घेतो. ही नोंद स्पष्ट करते की काय झाले, आम्ही कसा प्रतिसाद दिला आणि ते पुन्हा घडू नये यासाठी आम्ही काय करत आहोत.

prehistory

Grafana क्लाउड होस्ट केलेले Prometheus सेवा आधारित आहे कॉर्टेक्स — CNCF प्रकल्प क्षैतिज स्केलेबल, अत्यंत उपलब्ध, बहु-भाडेकरू प्रोमिथियस सेवा तयार करण्यासाठी. कॉर्टेक्स आर्किटेक्चरमध्ये वैयक्तिक मायक्रोसर्व्हिसेसचा संच असतो, ज्यापैकी प्रत्येक स्वतःचे कार्य करते: प्रतिकृती, स्टोरेज, क्वेरी इ. कॉर्टेक्स सक्रिय विकासाधीन आहे आणि सतत नवीन वैशिष्ट्ये जोडत आहे आणि कार्यप्रदर्शन सुधारत आहे. आम्ही नियमितपणे नवीन कॉर्टेक्स रिलीझ क्लस्टर्समध्ये तैनात करतो जेणेकरून ग्राहक या वैशिष्ट्यांचा लाभ घेऊ शकतील - सुदैवाने, कॉर्टेक्स डाउनटाइमशिवाय अपडेट केले जाऊ शकते.

अखंड अद्यतनांसाठी, Ingester Cortex सेवेला अपडेट प्रक्रियेदरम्यान अतिरिक्त Ingester प्रतिकृती आवश्यक आहे. (नोंद. अनुवाद: इंजेस्टर - कॉर्टेक्सचा मूलभूत घटक. नमुन्यांचा सतत प्रवाह गोळा करणे, त्यांचे प्रोमिथियस भागांमध्ये गट करणे आणि DynamoDB, BigTable किंवा Cassandra सारख्या डेटाबेसमध्ये संग्रहित करणे हे त्याचे कार्य आहे.) हे जुन्या Ingesters ला वर्तमान डेटा नवीन Ingesters ला अग्रेषित करण्यास अनुमती देते. हे लक्षात घेण्यासारखे आहे की Ingesters संसाधन-मागणी आहेत. त्यांना कार्य करण्यासाठी, आपल्याकडे प्रति पॉड 4 कोर आणि 15 जीबी मेमरी असणे आवश्यक आहे, म्हणजे. आमच्या कुबर्नेट्स क्लस्टर्सच्या बाबतीत बेस मशीनची 25% प्रोसेसिंग पॉवर आणि मेमरी. सर्वसाधारणपणे, आमच्याकडे क्लस्टरमध्ये 4 कोर आणि 15 GB मेमरी पेक्षा जास्त न वापरलेली संसाधने असतात, त्यामुळे आम्ही अपग्रेड दरम्यान हे अतिरिक्त इंजेस्टर सहजपणे फिरवू शकतो.

तथापि, असे अनेकदा घडते की सामान्य ऑपरेशन दरम्यान कोणत्याही मशीनमध्ये 25% न वापरलेली संसाधने नसतात. होय, आम्ही प्रयत्नही करत नाही: CPU आणि मेमरी नेहमी इतर प्रक्रियांसाठी उपयुक्त ठरतील. या समस्येचे निराकरण करण्यासाठी, आम्ही वापरण्याचे ठरविले Kubernetes पॉड प्राधान्यक्रम. इतर (स्टेटलेस) मायक्रोसर्व्हिसेसपेक्षा इंजेस्टरना उच्च प्राधान्य देण्याची कल्पना आहे. जेव्हा आम्हाला अतिरिक्त (N+1) इंजेस्टर चालवायचे असते, तेव्हा आम्ही इतर, लहान शेंगा तात्पुरते विस्थापित करतो. या शेंगा इतर मशीनवरील विनामूल्य संसाधनांमध्ये हस्तांतरित केल्या जातात, अतिरिक्त इंजेस्टर चालविण्यासाठी पुरेसे मोठे "छिद्र" सोडतात.

गुरुवार, 18 जुलै रोजी, आम्ही आमच्या क्लस्टरमध्ये चार नवीन प्राधान्य स्तर आणले: गंभीर, उच्च, सरासरी и कमी. सुमारे एक आठवडा क्लायंट रहदारी नसलेल्या अंतर्गत क्लस्टरवर त्यांची चाचणी घेण्यात आली. डीफॉल्टनुसार, निर्दिष्ट प्राधान्याशिवाय पॉड्स प्राप्त झाले सरासरी प्राधान्य, वर्ग Ingesters साठी सेट केले होते उच्च प्राधान्य गंभीर निरीक्षणासाठी राखीव होते (प्रोमेथियस, अलर्ट मॅनेजर, नोड-निर्यातकर्ता, क्यूबे-स्टेट-मेट्रिक्स इ.). आमचे कॉन्फिगरेशन खुले आहे आणि तुम्ही पीआर पाहू शकता येथे.

आपटी

शुक्रवार, 19 जुलै रोजी, एका अभियंत्याने मोठ्या क्लायंटसाठी नवीन समर्पित कॉर्टेक्स क्लस्टर लाँच केले. या क्लस्टरच्या कॉन्फिगरेशनमध्ये नवीन पॉड प्राधान्यक्रम समाविष्ट नाहीत, म्हणून सर्व नवीन पॉड्सना डीफॉल्ट प्राधान्य नियुक्त केले गेले - सरासरी.

नवीन कॉर्टेक्स क्लस्टरसाठी कुबर्नेट्स क्लस्टरकडे पुरेशी संसाधने नव्हती आणि विद्यमान उत्पादन कॉर्टेक्स क्लस्टर अद्यतनित केले गेले नाही (इंजेस्टर्सशिवाय सोडले गेले उच्च प्राधान्य). नवीन क्लस्टरचे Ingesters बाय डीफॉल्ट असल्याने सरासरी प्राधान्य, आणि उत्पादनातील विद्यमान पॉड्स अजिबात प्राधान्य न देता कार्य करतात, नवीन क्लस्टरच्या इंजेस्टर्सने विद्यमान कॉर्टेक्स उत्पादन क्लस्टरमधून इंजेस्टर्सची जागा घेतली.

प्रॉडक्शन क्लस्टरमधील बेदखल केलेल्या इंजेस्टरसाठी प्रतिकृतीसेटने बेदखल पॉड शोधले आणि निर्दिष्ट केलेल्या प्रती राखण्यासाठी एक नवीन तयार केला. नवीन पॉड डीफॉल्टनुसार नियुक्त केले होते सरासरी प्राधान्य, आणि उत्पादनातील आणखी एक "जुने" इंजेस्टरने त्याचे संसाधन गमावले. परिणाम झाला हिमस्खलन प्रक्रिया, ज्यामुळे कॉर्टेक्स उत्पादन क्लस्टरसाठी इंजेस्टरमधील सर्व शेंगा विस्थापित झाल्या.

इंजेस्टर स्टेटफुल असतात आणि मागील 12 तासांचा डेटा संग्रहित करतात. हे आम्हाला दीर्घकालीन स्टोरेजवर लिहिण्यापूर्वी त्यांना अधिक कार्यक्षमतेने संकुचित करण्यास अनुमती देते. हे साध्य करण्यासाठी, कॉर्टेक्स डिस्ट्रिब्युटेड हॅश टेबल (DHT) वापरून संपूर्ण मालिकेतील डेटाचे विभाजन करते आणि डायनॅमो-शैलीतील कोरम सुसंगतता वापरून तीन इंजेस्टरवर प्रत्येक मालिकेची प्रतिकृती बनवते. कॉर्टेक्स अक्षम केलेल्या इंजेस्टरना डेटा लिहित नाही. अशाप्रकारे, जेव्हा मोठ्या संख्येने इंजेस्टर DHT सोडतात, तेव्हा कॉर्टेक्स प्रविष्ट्यांची पुरेशी प्रतिकृती प्रदान करू शकत नाही आणि ते क्रॅश होतात.

शोध आणि उपाय

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

आणखी पाच मिनिटांनंतर, जुन्या इंजेस्टर्सनी त्यांचा डेटा यशस्वीरित्या लिहिला, नवीन सुरू झाले आणि कॉर्टेक्स क्लस्टर्स पुन्हा उपलब्ध झाले.

कॉर्टेक्सच्या समोर असलेल्या ऑथेंटिकेशन रिव्हर्स प्रॉक्सीमधून आउट-ऑफ-मेमरी (OOM) त्रुटींचे निदान करण्यात आणि दुरुस्त करण्यात आणखी 10 मिनिटे गेली. OOM त्रुटी QPS मध्ये दहापट वाढ झाल्यामुळे झाल्या होत्या (क्लायंटच्या प्रोमिथियस सर्व्हरच्या अती आक्रमक विनंत्यांमुळे आम्हाला विश्वास आहे).

परिणाम

एकूण डाउनटाइम 26 मिनिटे होता. कोणताही डेटा गमावला नाही. Ingesters ने सर्व मेमरी डेटा दीर्घकालीन स्टोरेजमध्ये यशस्वीरित्या लोड केला आहे. शटडाउन दरम्यान, क्लायंट प्रोमिथियस सर्व्हर बफर हटवले गेले (दूरस्थ) वापरून रेकॉर्डिंग नवीन API remote_write WAL वर आधारित (लेखक कॅलम स्टयान Grafana Labs कडून) आणि क्रॅश नंतर अयशस्वी लेखनाची पुनरावृत्ती केली.

उत्पादन क्लस्टर लेखन ऑपरेशन्स

निष्कर्ष

या घटनेपासून धडा घेणे आणि त्याची पुनरावृत्ती टाळण्यासाठी आवश्यक पावले उचलणे महत्त्वाचे आहे.

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

आम्ही कोणत्याही अतिरिक्त ऑब्जेक्ट्सच्या उपयोजनावर नियंत्रणाची अतिरिक्त पातळी जोडू ज्यांची कॉन्फिगरेशन क्लस्टरमध्ये जागतिक आहे. आतापासून, अशा बदलांचे मूल्यमापन केले जाईल बीоजास्त लोक. याशिवाय, क्रॅशला कारणीभूत असलेले बदल वेगळ्या प्रकल्प दस्तऐवजासाठी खूपच किरकोळ मानले गेले होते - त्याची चर्चा केवळ GitHub समस्येमध्ये झाली होती. आतापासून, कॉन्फिगमध्ये असे सर्व बदल योग्य प्रकल्प दस्तऐवजीकरणासह असतील.

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

अयशस्वी होण्याचे काही सकारात्मक परिणाम देखील झाले: आवश्यक संसाधने मिळाल्यामुळे, कॉर्टेक्स अतिरिक्त हस्तक्षेपाशिवाय आपोआप बरे झाले. सोबत काम करताना आम्हाला मौल्यवान अनुभवही मिळाला ग्राफना लोकी - आमची नवीन लॉग एग्रीगेशन सिस्टीम - ज्याने अयशस्वी होण्याच्या दरम्यान आणि नंतर सर्व इंजेस्टर योग्यरित्या वागले याची खात्री करण्यात मदत केली.

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

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

• «कुबर्नेट्समध्ये ऑटोस्केलिंग आणि संसाधन व्यवस्थापन (विहंगावलोकन आणि व्हिडिओ अहवाल)";
• «कुबर्नेट्स अॅडव्हेंचर डेलीमोशन: क्लाउड्स + ऑन-प्रिमाइसेसमध्ये पायाभूत सुविधा निर्माण करणे";
• «टिंडरचे कुबर्नेट्समध्ये संक्रमण";
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 10: Reddit».

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