🥇 Ansible वापरून स्वयंचलित डिस्क बदलणे

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

हा लेख एक प्रकारचा लिप्यंतरण आहे कामगिरी HighLoad+ 2018 वर

डिस्क बदलण्याची प्रक्रिया तयार करणे

प्रथम काही संख्या

ओके ही लाखो लोक वापरत असलेली विशाल सेवा आहे. हे सुमारे 7 हजार सर्व्हरद्वारे सर्व्ह केले जाते, जे 4 भिन्न डेटा केंद्रांमध्ये स्थित आहेत. सर्व्हरमध्ये 70 हजाराहून अधिक डिस्क असतात. तुम्ही त्यांना एकमेकांच्या वर स्टॅक केल्यास, तुम्हाला 1 किमी पेक्षा जास्त उंच टॉवर मिळेल.

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

घटना

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

स्टोरेज डिव्हाइसेस अपवाद नाहीत. त्यांच्या स्थितीचे परीक्षण Zabbix द्वारे केले जाते. आम्ही लेखन/वाचन त्रुटींसाठी Syslog मधील संदेशांचे निरीक्षण करतो, HW/SW छाप्यांच्या स्थितीचे विश्लेषण करतो, SMART चे निरीक्षण करतो आणि SSD साठी परिधान मोजतो.

आधी डिस्क कशी बदलली गेली

जेव्हा झब्बिक्समध्ये ट्रिगर होतो, तेव्हा जिरामध्ये एक घटना तयार केली जाते आणि डेटा केंद्रांमधील योग्य अभियंत्यांना स्वयंचलितपणे नियुक्त केली जाते. आम्ही हे सर्व HW घटनांसह करतो, म्हणजेच ज्यांना डेटा सेंटरमधील उपकरणांसह कोणतेही शारीरिक काम आवश्यक असते.
Инженер дата-центра — это человек, который решает вопросы, связанные с железом, отвечает за установку, обслуживание, демонтаж серверов. Получив тикет, инженер приступает к работе. В дисковых полках он меняет диски самостоятельно. Но если у него нет доступа к нужному устройству, инженер обращается к дежурным системным администраторам за помощью. В первую очередь нужно вывести диск из ротации. Для этого нужно сделать необходимые изменения на сервере, остановить приложения, отмонтировать диск.

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

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

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

याव्यतिरिक्त, अभियंता योग्यरित्या प्राधान्यक्रम सेट करू शकला नाही, कारण त्याला विशिष्ट सर्व्हरच्या उद्देशाबद्दल किंवा ड्राइव्हमधील माहितीचे वितरण याबद्दल काहीही माहिती नाही.

नवीन बदलण्याची प्रक्रिया

आम्ही पहिली गोष्ट म्हणजे सर्व डिस्क घटना वेगळ्या प्रकारच्या “HW डिस्क” मध्ये हलवल्या आणि त्यात “ब्लॉक डिव्हाइसचे नाव”, “आकार” आणि “डिस्क प्रकार” ही फील्ड जोडली जेणेकरून ही माहिती तिकीटात साठवली जाईल आणि चॅटमध्ये सतत देवाणघेवाण करण्याची गरज नाही.

आम्ही हे देखील मान्य केले की एका घटनेदरम्यान आम्ही फक्त एक डिस्क बदलू. यामुळे ऑटोमेशन प्रक्रिया, आकडेवारी संकलन आणि भविष्यातील काम लक्षणीयरीत्या सुलभ झाले.

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

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

फील्डची उपस्थिती आणि त्यांचे प्रदर्शन सोयीस्कर आहे, परंतु ते आम्हाला चॅट वापरण्याच्या गरजेपासून वाचवू शकले नाही. हे करण्यासाठी, आम्हाला कार्यप्रवाह बदलावा लागला.

पूर्वी हे असे होते:

प्रशासकाच्या मदतीची गरज नसतानाही आज अभियंते अशा प्रकारे काम करत आहेत.

पहिली गोष्ट म्हणजे आम्ही नवीन स्टेटस सादर केला चौकशी. तिकीट या स्थितीत आहे जेव्हा अभियंत्याने अद्याप निर्णय घेतलेला नाही की त्याला प्रशासकाची आवश्यकता आहे की नाही. या स्थितीद्वारे, अभियंता तिकीट प्रशासकाकडे हस्तांतरित करू शकतात. याव्यतिरिक्त, जेव्हा डिस्क बदलण्याची आवश्यकता असते तेव्हा तिकीट चिन्हांकित करण्यासाठी आम्ही ही स्थिती वापरतो, परंतु डिस्क स्वतः साइटवर नसते. हे CDN आणि रिमोट साइट्सच्या बाबतीत घडते.

आम्ही स्थिती देखील जोडली तयार. डिस्क बदलल्यानंतर तिकीट त्यात हस्तांतरित केले जाते. म्हणजेच, सर्वकाही आधीच केले गेले आहे, परंतु HW/SW RAID सर्व्हरवर समक्रमित केले आहे. यास बराच वेळ लागू शकतो.

जर प्रशासक कामात गुंतला असेल तर योजना थोडी अधिक क्लिष्ट होते.

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

त्यानंतर तिकीट हस्तांतरित केले जाते बदलण्यास तयार आहे: это сигнал инженеру, что диск можно вытаскивать. Все поля в Jira уже заполнены, инженер знает, какой тип и размер диска. Эти данные проставляются либо на предыдущем статусе автоматически или администратором.

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

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

गप्पांची गरज नाही. अर्थात, प्रशासक अभियंत्याला "हे जलद बदलण्याची गरज आहे," किंवा "संध्याकाळ झाली आहे, ते बदलण्यासाठी तुम्हाला वेळ मिळेल का?" परंतु आम्ही यापुढे या विषयांवर चॅटमध्ये दररोज संवाद साधत नाही.

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

वर्कफ्लो तयार करताना शिकलेले धडे

कार्यपद्धती तयार करताना, आपल्याला वेगवेगळ्या स्त्रोतांकडून माहिती गोळा करणे आवश्यक आहे.
Некоторые наши администраторы не знали, что инженер меняет диски самостоятельно. Некоторые считали, что за синхронизацией MD RAID следят инженеры, хотя у кого-то из них даже не было доступа для этого. Некоторые ведущие инженеры это делали, но не всегда, потому что процесс нигде не был описан.
Процедура должна быть простой и понятной.
माणसाला अनेक पायऱ्या मनात ठेवणं कठीण असतं. जिरामधील सर्वात महत्त्वाच्या शेजारच्या स्थिती मुख्य स्क्रीनवर ठेवल्या पाहिजेत. तुम्ही त्यांचे नाव बदलू शकता, उदाहरणार्थ, आम्ही बदलण्यास तयार आहे असे म्हणतो. आणि इतर स्थिती ड्रॉप-डाउन मेनूमध्ये लपवल्या जाऊ शकतात जेणेकरून ते डोळे दुखू शकत नाहीत. परंतु लोकांना मर्यादित न करणे, त्यांना संक्रमण करण्याची संधी देणे चांगले आहे.
नवोपक्रमाचे मूल्य समजावून सांगा. जेव्हा लोकांना समजते तेव्हा ते नवीन कार्यपद्धती अधिक स्वीकारतात. आमच्यासाठी हे खूप महत्वाचे होते की लोक संपूर्ण प्रक्रियेवर क्लिक करत नाहीत, परंतु त्याचे अनुसरण करतात. मग आम्ही यावर ऑटोमेशन तयार केले.
प्रतीक्षा करा, विश्लेषण करा, ते शोधून काढा.
प्रक्रिया तयार करण्यासाठी, तांत्रिक अंमलबजावणीसाठी, बैठका आणि चर्चा करण्यासाठी आम्हाला सुमारे एक महिना लागला. आणि अंमलबजावणीसाठी तीन महिन्यांपेक्षा जास्त वेळ लागतो. लोक हळूहळू नावीन्य कसे वापरायला लागले आहेत हे मी पाहिले. सुरुवातीच्या काळात खूप नकारात्मकता होती. परंतु ते स्वतः प्रक्रिया आणि त्याच्या तांत्रिक अंमलबजावणीपासून पूर्णपणे स्वतंत्र होते. उदाहरणार्थ, एका प्रशासकाने जिरा वापरला नाही, परंतु Confluence मधील Jira प्लगइन आणि काही गोष्टी त्याच्यासाठी उपलब्ध नव्हत्या. आम्ही त्याला जिरा दाखवला आणि प्रशासकाची उत्पादकता सामान्य कार्यांसाठी आणि डिस्क बदलण्यासाठी दोन्ही वाढली.

डिस्क बदलण्याचे ऑटोमेशन

К автоматизации замены дисков мы подступались несколько раз. У нас уже были наработки, скрипты, но все они работали либо в интерактивном, либо в ручном режиме, требовали запуска. И только после внедрения новой процедуры мы поняли, что как раз её нам не хватало.

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

प्राणीसंग्रहालय सेटअप

आम्ही बॉटबद्दल बोलण्यापूर्वी, आमच्या प्रतिष्ठानच्या प्राणीसंग्रहालयात एक छोटा भ्रमण करूया. सर्वप्रथम, हे आपल्या पायाभूत सुविधांच्या प्रचंड आकारामुळे आहे. दुसरे म्हणजे, आम्ही प्रत्येक सेवेसाठी इष्टतम हार्डवेअर कॉन्फिगरेशन निवडण्याचा प्रयत्न करतो. आमच्याकडे सुमारे 20 हार्डवेअर RAID मॉडेल्स आहेत, मुख्यतः LSI आणि Adaptec, परंतु HP आणि DELL वेगवेगळ्या आवृत्त्यांचे देखील आहेत. प्रत्येक RAID कंट्रोलरची स्वतःची व्यवस्थापन उपयुक्तता असते. प्रत्येक RAID कंट्रोलरसाठी आदेशांचा संच आणि त्यांचे जारी करणे भिन्न असू शकते. जेथे HW-RAID वापरले जात नाही, तेथे mdraid वापरले जाऊ शकते.

आम्ही डिस्क बॅकअपशिवाय जवळजवळ सर्व नवीन स्थापना करतो. आम्ही यापुढे हार्डवेअर आणि सॉफ्टवेअर RAID न वापरण्याचा प्रयत्न करतो, कारण आम्ही आमच्या सिस्टमचा डेटा सेंटर स्तरावर बॅकअप घेतो, सर्व्हरवर नाही. परंतु अर्थातच असे बरेच लेगेसी सर्व्हर आहेत ज्यांना समर्थन देणे आवश्यक आहे.

कुठेतरी RAID कंट्रोलर्समधील डिस्क्स रॉ डिव्हाइसेसमध्ये हस्तांतरित केल्या जातात, कुठेतरी JBODs वापरल्या जातात. सर्व्हरमध्ये एका सिस्टम डिस्कसह कॉन्फिगरेशन आहेत आणि जर ते बदलण्याची आवश्यकता असेल, तर तुम्हाला त्याच आवृत्त्यांचे ओएस आणि अॅप्लिकेशन्सच्या स्थापनेसह सर्व्हर पुन्हा स्थापित करावे लागेल, नंतर कॉन्फिगरेशन फाइल्स जोडा, अॅप्लिकेशन लॉन्च करा. असे बरेच सर्व्हर गट देखील आहेत जिथे बॅकअप डिस्क सबसिस्टम स्तरावर नाही तर थेट अनुप्रयोगांमध्ये घेतला जातो.

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

आम्ही उत्तरदायी निवडले कारण ते एजंटविरहित आहे: पायाभूत सुविधा तयार करण्याची गरज नव्हती, एक द्रुत सुरुवात. याव्यतिरिक्त, ते पायथनमध्ये लिहिलेले आहे, जे संघात मानक म्हणून स्वीकारले जाते.

सर्वसाधारण योजना

उदाहरण म्हणून एका घटनेचा वापर करून सामान्य ऑटोमेशन योजना पाहू. Zabbix ला आढळले की sdb डिस्क अयशस्वी झाली आहे, ट्रिगर उजळला आहे आणि जिरा मध्ये तिकीट तयार केले आहे. प्रशासकाने ते पाहिले, लक्षात आले की ते डुप्लिकेट नाही आणि खोटे सकारात्मक नाही, म्हणजेच डिस्क बदलणे आवश्यक आहे आणि तिकीट प्रगतीपथावर हस्तांतरित केले.

Python मध्ये लिहिलेले DiskoBot ऍप्लिकेशन, नवीन तिकिटांसाठी वेळोवेळी जिराला मतदान करते. हे लक्षात येते की एक नवीन प्रगतीपथावरील तिकीट दिसले आहे, संबंधित धागा ट्रिगर झाला आहे, जो Ansible मध्ये प्लेबुक लाँच करतो (हे जिरामधील प्रत्येक स्थितीसाठी केले जाते). या प्रकरणात, Prepare2change लाँच केले आहे.

उत्तरदायी होस्टला पाठवले जाते, डिस्कला रोटेशनमधून काढून टाकते आणि कॉलबॅकद्वारे अॅप्लिकेशनला स्थितीचा अहवाल देते.

परिणामांवर आधारित, बॉट आपोआप तिकीट बदलण्यासाठी तयार वर हस्तांतरित करतो. अभियंता एक सूचना प्राप्त करतो आणि डिस्क बदलण्यासाठी जातो, त्यानंतर तो तिकीट चेंज्डमध्ये हस्तांतरित करतो.

वर वर्णन केलेल्या योजनेनुसार, तिकीट बॉटवर परत जाते, जे दुसरे प्लेबुक लॉन्च करते, होस्टकडे जाते आणि डिस्कला रोटेशनमध्ये ठेवते. बॉट तिकीट बंद करतो. हुर्रे!

आता सिस्टमच्या काही घटकांबद्दल बोलूया.

डिस्कोबोट

हा अनुप्रयोग पायथनमध्ये लिहिलेला आहे. ते JQL नुसार जिरा मधून तिकिटे निवडते. तिकिटाच्या स्थितीवर अवलंबून, नंतरचे संबंधित हँडलरकडे जाते, जे त्या बदल्यात स्थितीशी संबंधित उत्तरदायी प्लेबुक लाँच करते.

JQL आणि मतदान अंतराल हे ऍप्लिकेशन कॉन्फिगरेशन फाइलमध्ये परिभाषित केले आहेत.

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

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

आणि तयार स्थिती असलेल्या तिकिटांमध्ये, dbot_ignore लेबल असलेली तिकिटे फिल्टर केली जातात. तसे, आम्ही अशा फिल्टरिंगसाठी आणि डुप्लिकेट तिकिटे चिन्हांकित करण्यासाठी आणि आकडेवारी गोळा करण्यासाठी जिरा लेबले वापरतो.

प्लेबुक अयशस्वी झाल्यास, जिरा dbot_failed लेबल नियुक्त करते जेणेकरून ते नंतर सोडवता येईल.

Ansible सह इंटरऑपरेबिलिटी

अॅप्लिकेशन Ansible द्वारे संप्रेषण करते उत्तरदायी Python API. playbook_executor साठी आम्ही फाईलचे नाव आणि व्हेरिएबल्सचा संच पास करतो. हे तुम्हाला Ansible प्रकल्पाचे Python कोडमध्ये वर्णन करण्याऐवजी नियमित yml फाइल्सच्या स्वरूपात ठेवण्याची परवानगी देते.

तसेच Ansible मध्ये, *extra_vars* द्वारे, ब्लॉक डिव्हाइसचे नाव, तिकिटाची स्थिती, तसेच callback_url, ज्यामध्ये समस्या की आहे - ती HTTP मध्ये कॉलबॅकसाठी वापरली जाते.

प्रत्येक प्रक्षेपणासाठी, एक तात्पुरती इन्व्हेंटरी तयार केली जाते, ज्यामध्ये एक होस्ट आणि हा होस्ट ज्या गटाशी संबंधित आहे, त्यामुळे group_vars लागू केले जातात.

HTTP कॉलबॅक लागू करणार्‍या कार्याचे येथे एक उदाहरण आहे.

कॉलबॅक वापरून प्लेबुक कार्यान्वित केल्याचा परिणाम आम्हाला मिळतो. ते दोन प्रकारचे आहेत:

Ansible callback plugin, он предоставляет данные по результатам выполнения playbook’а. Там описаны задачи, которые были запущены, выполнены удачно или неудачно. Этот callback вызывается по окончанию проигрывания playbook’а.
प्लेबुक प्ले करताना माहिती प्राप्त करण्यासाठी HTTP कॉलबॅक. उत्तरदायी कार्यामध्ये आम्ही आमच्या अर्जावर POST/GET विनंती कार्यान्वित करतो.

Через HTTP callback(-и) передаются переменные, которые были определены при выполнении playbook’а и которые мы хотим сохранить и использовать в последующих запусках. Эти данные мы пишем в sqlite.

आम्ही टिप्पण्या देखील देतो आणि HTTP कॉलबॅकद्वारे तिकीट स्थिती बदलतो.

HTTP कॉलबॅक

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

एकाच प्रकारच्या अनेक कार्यांप्रमाणे, आम्ही ते एका वेगळ्या सामान्य फाईलमध्ये ठेवतो आणि आवश्यक असल्यास ते समाविष्ट करतो, जेणेकरून प्लेबुकमध्ये त्याची सतत पुनरावृत्ती होऊ नये. यामध्ये कॉलबॅक_url समाविष्ट आहे, ज्यामध्ये समस्या की आणि होस्ट नाव आहे. जेव्हा Ansible ही POST विनंती कार्यान्वित करते, तेव्हा बॉटला समजते की ती अशा आणि अशा घटनेचा भाग म्हणून आली आहे.

आणि येथे प्लेबुकमधील एक उदाहरण आहे, ज्यामध्ये आम्ही एमडी डिव्हाइसवरून डिस्क आउटपुट करतो:

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

हे कार्य जिरा तिकीट "रेडी टू चेंज" स्थितीवर हस्तांतरित करते आणि एक टिप्पणी जोडते. तसेच, mdam_data व्हेरिएबल md डिव्हाइसेसची सूची संग्रहित करते ज्यातून डिस्क काढून टाकली होती, आणि parted_info parted पासून विभाजन डंप संग्रहित करते.

जेव्हा अभियंता नवीन डिस्क घालतो, तेव्हा आम्ही विभाजन डंप पुनर्संचयित करण्यासाठी या व्हेरिएबल्सचा वापर करू शकतो, तसेच ज्या md डिव्हाइसेसमधून ती काढून टाकली होती त्यामध्ये डिस्क घालू शकतो.

उत्तरदायी चेक मोड

ऑटोमेशन चालू करणे भितीदायक होते. म्हणून, आम्ही सर्व प्लेबुक मोडमध्ये चालवण्याचा निर्णय घेतला
ड्राय रन, ज्यामध्ये Ansible सर्व्हरवर कोणतीही क्रिया करत नाही, परंतु केवळ त्यांचे अनुकरण करते.

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

प्रथम, यामुळे बॉट आणि प्लेबुकचे कार्य प्रमाणित करणे शक्य झाले. दुसरे म्हणजे, यामुळे बॉटवरील प्रशासकांचा आत्मविश्वास वाढला.

जेव्हा आम्ही प्रमाणीकरण उत्तीर्ण केले आणि लक्षात आले की तुम्ही केवळ ड्राय रन मोडमध्येच नव्हे तर अॅन्सिबल चालवू शकता, आम्ही त्याच होस्टवर समान व्हेरिएबल्ससह समान प्लेबुक लाँच करण्यासाठी जिरामध्ये डिस्कोबोट रन बटण बनवले, परंतु सामान्य मोडमध्ये.

याव्यतिरिक्त, प्लेबुक क्रॅश झाल्यास रीस्टार्ट करण्यासाठी बटण वापरले जाते.

प्लेबुकची रचना

मी आधीच नमूद केले आहे की जिरा तिकिटाच्या स्थितीनुसार, बॉट विविध प्लेबुक लॉन्च करतो.

Во-первых, так намного проще организовать вход.
दुसरे म्हणजे, काही प्रकरणांमध्ये ते फक्त आवश्यक आहे.

उदाहरणार्थ, सिस्टम डिस्क बदलताना, आपल्याला प्रथम उपयोजन प्रणालीवर जाणे आवश्यक आहे, एक कार्य तयार करणे आवश्यक आहे आणि योग्य उपयोजन केल्यानंतर, सर्व्हर ssh द्वारे प्रवेशयोग्य होईल आणि आपण त्यावर अनुप्रयोग रोल आउट करू शकता. जर आम्ही हे सर्व एका प्लेबुकमध्ये केले, तर होस्ट अनुपलब्ध असल्यामुळे Ansible ते पूर्ण करू शकणार नाही.

आम्ही सर्व्हरच्या प्रत्येक गटासाठी उत्तरदायी भूमिका वापरतो. त्यापैकी एकामध्ये प्लेबुक कसे आयोजित केले जातात ते येथे तुम्ही पाहू शकता.

हे सोयीस्कर आहे कारण कोणती कार्ये कुठे आहेत हे त्वरित स्पष्ट होते. main.yml मध्ये, जो उत्तरदायी भूमिकेसाठी इनपुट आहे, आम्ही फक्त तिकीट स्थिती किंवा प्रत्येकासाठी आवश्यक असलेली सामान्य कार्ये समाविष्ट करू शकतो, उदाहरणार्थ, ओळख पास करणे किंवा टोकन प्राप्त करणे.

तपास.yml

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

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

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

ready2change.yml

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

सर्वात सोप्या प्रकरणात, आम्ही HW/MD RAID मधून डिस्क काढून टाकण्याबद्दल बोलत आहोत.

अधिक जटिल परिस्थितींमध्ये (आमच्या स्टोरेज सिस्टममध्ये), जेव्हा बॅकअप ऍप्लिकेशन स्तरावर केला जातो, तेव्हा तुम्हाला API द्वारे ऍप्लिकेशनवर जाणे, डिस्क आउटपुटची तक्रार करणे, ते निष्क्रिय करणे आणि पुनर्प्राप्ती सुरू करणे आवश्यक आहे.

आम्ही आता मोठ्या प्रमाणावर स्थलांतर करत आहोत ढग, आणि जर सर्व्हर क्लाउड-आधारित असेल, तर डिस्कोबॉट क्लाउड API ला कॉल करतो, म्हणतो की ते या मिनियनसह कार्य करणार आहे - सर्व्हर चालवणारे कंटेनर - आणि "या मिनियनमधून सर्व कंटेनर स्थलांतरित करा" असे विचारते. आणि त्याच वेळी, डिस्कचा बॅकलाइट चालू करतो जेणेकरून अभियंता ताबडतोब पाहू शकेल की कोणती बाहेर काढायची आहे.

बदलले.yml

डिस्क बदलल्यानंतर, आम्ही प्रथम त्याची उपलब्धता तपासतो.

अभियंते नेहमी नवीन ड्राइव्ह स्थापित करत नाहीत, म्हणून आम्ही SMART मूल्यांसाठी एक चेक जोडला जे आम्हाला संतुष्ट करतात.

आपण कोणते गुणधर्म पाहत आहोत?पुनर्विलोकित क्षेत्रांची संख्या (५) < १००
वर्तमान प्रलंबित क्षेत्र संख्या (107) == 0

Если диск не проходит проверку, инженеру сообщается о повторной замене. Если всё в порядке, подсветка выключается, наносится разметка и диск вводится в ротацию.

तयार.yml

सर्वात सोपा केस: HW/SW raid सिंक्रोनाइझेशन तपासणे किंवा अनुप्रयोगामध्ये डेटा सिंक्रोनाइझेशन पूर्ण करणे.

अनुप्रयोग API

मी बर्‍याच वेळा नमूद केले आहे की बॉट बर्‍याचदा अनुप्रयोग API मध्ये प्रवेश करतो. अर्थात, सर्व ऍप्लिकेशन्समध्ये आवश्यक पद्धती नाहीत, म्हणून त्यांना सुधारित करावे लागले. आम्ही वापरत असलेल्या सर्वात महत्वाच्या पद्धती येथे आहेत:

स्थिती. क्लस्टर किंवा डिस्कसह कार्य केले जाऊ शकते किंवा नाही हे समजून घेण्यासाठी त्याची स्थिती;
प्रारंभ/थांबा. डिस्क सक्रिय करणे/निष्क्रिय करणे;
स्थलांतर/पुनर्संचयित करा. बदली दरम्यान आणि नंतर डेटा स्थलांतर आणि पुनर्प्राप्ती.

Ansible कडून धडे घेतले

मला खरेच Ansible आवडते. पण अनेकदा, जेव्हा मी वेगवेगळे ओपनसोर्स प्रोजेक्ट पाहतो आणि लोक प्लेबुक कसे लिहितात ते पाहतो तेव्हा मला थोडी भीती वाटते. शेल/कमांडच्या वारंवार वापरामुळे व्हेन/लूप, लवचिकतेचा अभाव आणि इडम्पोटेन्सीचे जटिल तार्किक आंतरविण.

Ansible - modularity चा फायदा घेऊन आम्ही सर्वकाही शक्य तितके सोपे करण्याचा निर्णय घेतला. उच्च स्तरावर प्लेबुक्स आहेत; ते कोणत्याही प्रशासकाद्वारे, थर्ड-पार्टी डेव्हलपरद्वारे लिहिले जाऊ शकतात ज्याला थोडेसे उत्तरदायी माहिती आहे.

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

Если какую-то логику сложно реализовать в playbook’ах, мы выносим её в Ansible-модуль или фильтр. Скрипты могут быть написаны как на Python, так и на любом другом языке.

Их легко и быстро писать. Например, модуль подсветки диска, пример использования которого приведен выше, состоит из 265 строк.

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

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

तुम्हाला उत्तरदायी API सह आमच्या अनुभवाची पुनरावृत्ती करायची असल्यास, दोन गोष्टी लक्षात ठेवा:

प्लेबुक_एक्झिक्युटर आणि प्लेबुक्सना सर्वसाधारणपणे कालबाह्यता दिली जाऊ शकत नाही. ssh सत्रावर कालबाह्य आहे, परंतु प्लेबुकवर कालबाह्य नाही. सिस्टममध्ये यापुढे अस्तित्वात नसलेली डिस्क अनमाउंट करण्याचा प्रयत्न केल्यास, प्लेबुक अविरतपणे चालेल, म्हणून आम्हाला त्याचे लाँच वेगळ्या रॅपरमध्ये गुंडाळावे लागेल आणि कालबाह्यतेसह ते नष्ट करावे लागेल.
Ansible फोर्क केलेल्या प्रक्रियांवर चालते, त्यामुळे त्याचा API थ्रेड सुरक्षित नाही. आम्ही आमची सर्व प्लेबुक सिंगल-थ्रेडेड चालवतो.

परिणामी, आम्ही सुमारे 80% डिस्क्सची पुनर्स्थापना स्वयंचलित करू शकलो. एकूणच, बदली दर दुप्पट झाला आहे. आज, प्रशासक फक्त घटना पाहतो आणि डिस्क बदलण्याची गरज आहे की नाही हे ठरवतो आणि नंतर एक क्लिक करतो.

पण आता आम्ही आणखी एका समस्येचा सामना करू लागलो आहोत: काही नवीन प्रशासकांना ड्राइव्ह कसे बदलावे हे माहित नाही. 🙂

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

Ansible सह स्वयंचलित डिस्क बदलणे