स्वचालित डिस्क प्रतिस्थापन के साथ स्वचालित

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

यह लेख HighLoad + 2018 के प्रदर्शन का एक प्रकार का लिप्यंतरण है

एक डिस्क प्रतिस्थापन प्रक्रिया का निर्माण

पहले कुछ नंबर

ओके एक विशाल सेवा है जिसका उपयोग लाखों लोग करते हैं। यह लगभग 7 हजार सर्वरों द्वारा कार्य किया जाता है, जो 4 विभिन्न डेटा केंद्रों में स्थित हैं। सर्वर की लागत 70 हजार से अधिक ड्राइव है। यदि आप उन्हें एक-दूसरे के ऊपर ढेर करते हैं, तो आपको 1 किमी से अधिक की ऊंचाई वाला एक टॉवर मिलता है।

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

घटनाओं

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

ड्राइव कोई अपवाद नहीं हैं। उनकी स्थिति ज़ैबिक्स द्वारा निगरानी की जाती है। हम लिखने / पढ़ने की त्रुटियों के लिए Syslog में संदेशों की निगरानी करते हैं, HW / SW छापे की स्थिति का विश्लेषण करते हैं, स्मार्ट मॉनिटर करते हैं, और SSDs के लिए पहनने की गणना करते हैं।

कैसे डिस्क पहले बदल गई

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

शिफ्ट के दौरान ड्यूटी पर मौजूद सिस्टम एडमिनिस्ट्रेटर पूरे पोर्टल के संचालन के लिए जिम्मेदार होता है। वह घटनाओं की जांच करता है, मरम्मत करता है, डेवलपर्स को छोटे कार्य करने में मदद करता है। वह केवल हार्ड ड्राइव से नहीं निपटता।

पहले, डाटा सेंटर इंजीनियर सिस्टम एडमिनिस्ट्रेटर से चैट करते थे। इंजीनियरों ने जीरा टिकटों के लिंक भेजे, प्रशासक उनके माध्यम से चले गए, कुछ नोटपैड में काम का एक लॉग रखा। लेकिन ऐसे कार्यों के लिए चैट असुविधाजनक है: वहां की जानकारी संरचित नहीं है और जल्दी से खो जाती है। और व्यवस्थापक केवल कंप्यूटर से दूर जा सकता है और कुछ समय के लिए अनुरोधों का जवाब नहीं देता है, और इंजीनियर सर्वर पर डिस्क के एक झुंड के साथ खड़ा था और इंतजार कर रहा था।

लेकिन सबसे बुरी बात यह थी कि प्रशासक पूरी तस्वीर नहीं देखते थे: डिस्क की घटनाएं क्या होती हैं, जहां समस्या संभावित रूप से उत्पन्न हो सकती है। यह इस तथ्य के कारण है कि हम इंजीनियरों को सभी एचडब्ल्यू घटनाएं देते हैं। हां, व्यवस्थापक डैशबोर्ड पर सभी घटनाओं को प्रदर्शित करना संभव था। लेकिन उनमें से बहुत सारे हैं, और प्रशासक उनमें से कुछ में ही शामिल था।

इसके अलावा, इंजीनियर सही ढंग से प्राथमिकता नहीं दे सकता था, क्योंकि उसे विशिष्ट सर्वरों के उद्देश्य के बारे में कुछ भी नहीं पता था, ड्राइव भर की जानकारी के वितरण के बारे में।

नई प्रतिस्थापन प्रक्रिया

हमने जो पहली चीज़ की वह सभी डिस्क घटनाओं को एक अलग प्रकार की "एचडब्ल्यू-डिस्क" में ले गई और उसमें "ब्लॉक डिवाइस का नाम", "आकार" और "डिस्क प्रकार" को जोड़ दिया ताकि यह जानकारी टिकट में बच जाए और इसे नहीं करना पड़ेगा लगातार चैटिंग।


हम यह भी सहमत थे कि एक घटना के ढांचे के भीतर हम केवल एक डिस्क को बदल देंगे। इसने स्वचालन प्रक्रिया, सांख्यिकी संग्रह और कार्य को बहुत सरल बनाया।

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


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

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

यह इस तरह हुआ करता था:


आज, इंजीनियर इस तरह से काम करना जारी रखते हैं, जब उन्हें व्यवस्थापक सहायता की आवश्यकता नहीं होती है।

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

हमने रेडी स्टेटस भी जोड़ा। डिस्क को बदलने के बाद टिकट को इसमें स्थानांतरित किया जाता है। यही है, सब कुछ पहले से ही किया गया है, लेकिन HW / SW RAID सर्वर पर सिंक्रनाइज़ किया गया है। यह काफी समय लेने वाला हो सकता है।

यदि कोई व्यवस्थापक शामिल है, तो योजना थोड़ी अधिक जटिल है।


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

फिर टिकट को बदलने के लिए रेडी में बदल दिया जाता है : यह इंजीनियर को संकेत है कि डिस्क को बाहर निकाला जा सकता है। जीरा के सभी क्षेत्र पहले से ही भरे हुए हैं, इंजीनियर जानता है कि डिस्क का प्रकार और आकार क्या है। यह डेटा पिछली स्थिति में स्वचालित रूप से या व्यवस्थापक द्वारा चिपका दिया गया है।

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


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

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

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

सबक बिल्डिंग वर्कफ़्लो में सीखा

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

ड्राइव रिप्लेसमेंट ऑटोमेशन

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

चूंकि अब प्रतिस्थापन प्रक्रिया को चरणों में विभाजित किया गया है, जिनमें से प्रत्येक में एक निष्पादक और कार्यों की एक सूची है, हम चरणों में स्वचालन को चालू कर सकते हैं, और सभी को एक बार में नहीं। उदाहरण के लिए, सबसे सरल चरण - रेडी (RAID / डेटा सिंक्रोनाइज़ेशन की जाँच करना) को आसानी से बॉट में रखा जा सकता है। जब बॉट थोड़ा सीखता है, तो आप इसे अधिक जिम्मेदार कार्य दे सकते हैं - डिस्क को रोटेशन में डाल सकते हैं, आदि।

ज़ू सेटअप

बॉट के बारे में बात करने से पहले, हम अपने इंस्टॉलेशन चिड़ियाघर में एक छोटा भ्रमण करेंगे। सबसे पहले, यह हमारे बुनियादी ढांचे के विशाल आकार के कारण है। दूसरे, प्रत्येक सेवा के लिए हम लोहे के इष्टतम विन्यास को चुनने की कोशिश करते हैं। हमारे पास लगभग 20 हार्डवेयर RAID मॉडल हैं, मुख्य रूप से LSI और Adaptec, लेकिन विभिन्न संस्करणों के HP और DELL दोनों हैं। प्रत्येक RAID नियंत्रक की अपनी प्रबंधन उपयोगिता है। आदेशों का सेट और उनमें से जारी करने का संस्करण प्रत्येक RAID नियंत्रक के संस्करण से भिन्न हो सकता है। जहां HW-RAID का उपयोग नहीं किया गया है, वह mdraid हो सकता है।

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

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

कुल में, हमारे पास सर्वरों के 400 से अधिक अद्वितीय समूह हैं जो लगभग 100 विभिन्न अनुप्रयोगों को चलाते हैं। इतनी बड़ी संख्या में विकल्पों को कवर करने के लिए, हमें एक बहुक्रियाशील स्वचालन उपकरण की आवश्यकता थी। यह एक साधारण डीएसएल के साथ सलाह दी जाती है, ताकि न केवल यह लिखने वाले व्यक्ति इसका समर्थन कर सकें।

हमने अन्सिबल को चुना क्योंकि यह एजेंट रहित है: बुनियादी ढाँचे को तैयार करने की कोई आवश्यकता नहीं थी, त्वरित शुरुआत। इसके अलावा, यह पायथन में लिखा गया है, जिसे टीम में मानक के रूप में स्वीकार किया जाता है।

सामान्य योजना

आइए एक उदाहरण के रूप में एक घटना का उपयोग करके एक सामान्य स्वचालन योजना देखें। ज़ैबिक्स यह पता लगाता है कि एसडीबी ड्राइव क्रम से बाहर है, ट्रिगर लाइट्स ऊपर, जीरा में एक टिकट बनाया जाता है। व्यवस्थापक ने इसे देखा, यह महसूस किया कि यह एक डुप्लिकेट नहीं है और न ही झूठी सकारात्मक है, अर्थात, आपको डिस्क को बदलने की आवश्यकता है, और टिकट को प्रगति में अनुवाद करता है।


पायथन में लिखा गया डिस्कोकोबट एप्लिकेशन समय-समय पर नए टिकटों के लिए जीरा को प्रदूषित करता है। यह नोटिस करता है कि एक नया प्रगति टिकट दिखाई दिया है, इसी थ्रेड को ट्रिगर किया गया है, जो कि प्लेबुक को अंसिबल में लॉन्च करता है (यह जीरा में प्रत्येक स्थिति के लिए किया जाता है)। इस स्थिति में, Ready2change प्रारंभ होता है।

होस्ट करने योग्य जाता है, डिस्क को रोटेशन से हटाता है, और कॉलबैक के माध्यम से एप्लिकेशन को स्थिति की रिपोर्ट करता है।


परिणामों के अनुसार, बॉट स्वचालित रूप से टिकट को बदलने के लिए रेडी में स्थानांतरित करता है। इंजीनियर एक अधिसूचना प्राप्त करता है और डिस्क को बदलने के लिए जाता है, जिसके बाद वह टिकट बदलकर बदल देता है।


उपरोक्त योजना के अनुसार, टिकट वापस बॉट में जाता है, यह एक और प्लेबुक लॉन्च करता है, होस्ट में जाता है और डिस्क को रोटेशन में प्रवेश करता है। बॉट टिकट बंद कर देता है। हुर्रे!


अब सिस्टम के कुछ घटकों के बारे में बात करते हैं।

Diskobot

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

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 के माध्यम से Ansible के साथ इंटरैक्ट करता है । Playbook_executor में, हम फ़ाइल नाम और चर का सेट पास करते हैं। यह आपको पायथन कोड में वर्णन करने के बजाय, नियमित वाईएमएल फ़ाइलों के रूप में Ansible परियोजना को रखने की अनुमति देता है।

इसके अलावा Ansible में * extra_vars * ब्लॉक डिवाइस का नाम, टिकट की स्थिति, साथ ही कॉलबैक_url, जिसमें समस्या कुंजी वायर्ड है, का उपयोग किया जाता है - इसका उपयोग HTTP में कॉलबैक के लिए किया जाता है।

प्रत्येक लॉन्च के लिए, एक अस्थायी इन्वेंट्री उत्पन्न की जाती है, जिसमें एक होस्ट और यह होस्ट होता है, ताकि ग्रुप_वार्स लागू हो।

यहां एक कार्य का एक उदाहरण है जिसमें HTTP कॉलबैक लागू किया गया है।

प्लेबुक का परिणाम हमें कॉलबैक (एस) के उपयोग से मिलता है। वे दो प्रकार के होते हैं:

• Ansible कॉलबैक प्लगइन , यह एक प्लेबुक के परिणामों पर डेटा प्रदान करता है। यह उन कार्यों का वर्णन करता है जो सफलतापूर्वक या असफल रूप से लॉन्च किए गए थे। इस कॉलबैक को प्लेबुक के अंत में कहा जाता है।
• Playbook खेलते समय जानकारी प्राप्त करने के लिए HTTP कॉलबैक। Ansible में, हम अपने आवेदन के पक्ष में एक POST / GET अनुरोध करते हैं।

HTTP HTTP कॉलबैक (एस), वे चर जिन्हें प्लेबुक के निष्पादन के दौरान परिभाषित किया गया था और जिन्हें हम बाद के रनों में सहेजना और उपयोग करना चाहते हैं। हम इस डेटा को sqlite में लिखते हैं।

साथ ही HTTP कॉलबैक के माध्यम से हम टिप्पणी छोड़ते हैं और टिकट की स्थिति बदलते हैं।


एक ही प्रकार के कई कार्यों की तरह, हम इसे एक अलग आम फ़ाइल में रखते हैं और यदि आवश्यक हो तो इसे शामिल करते हैं, ताकि प्लेबुक में लगातार दोहराएं नहीं। Callback_ 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 में पार्टेड डंप किया गया था।

जब इंजीनियर एक नई डिस्क सम्मिलित करता है, तो हम विभाजन चर को पुनर्स्थापित करने के लिए इन चरों का उपयोग करने में सक्षम होंगे, साथ ही डिस्क को उन md उपकरणों में डालें जहाँ से इसे हटाया गया था।

अन्सिबल चेक मोड

स्वचालन चालू करना डरावना था। इसलिए, हमने सभी प्लेबुक को मोड में चलाने का निर्णय लिया
ड्राई रन , जिसमें Ansible सर्वरों पर कोई क्रिया नहीं करता है, लेकिन केवल उनका अनुकरण करता है।

इस तरह के लॉन्च को एक अलग कॉलबैक मॉड्यूल के माध्यम से चलाया जाता है, और प्लेबुक के परिणाम को जीरा में एक टिप्पणी के रूप में सहेजा जाता है।



सबसे पहले, इसने बॉट और प्लेबुक के काम को मान्य करने की अनुमति दी। दूसरे, इसने बॉट में प्रशासकों के विश्वास को बढ़ाया।

जब हमने सत्यापन के माध्यम से जाना और महसूस किया कि आप अंसिबल को न केवल ड्राई रन मोड में चला सकते हैं, तो हमने उसी होस्ट पर समान वैरिएबल के साथ, लेकिन सामान्य मोड में समान प्लेबुक शुरू करने के लिए जीरा में रन डिस्कबॉट बटन बनाया।

इसके अलावा, बटन का उपयोग इसकी विफलता की स्थिति में प्लेबुक को पुनरारंभ करने के लिए किया जाता है।

Playbooks संरचना

मैंने पहले ही उल्लेख किया है कि जीरा टिकट की स्थिति के आधार पर, बॉट विभिन्न प्लेबुक लॉन्च करता है।

सबसे पहले, प्रवेश की व्यवस्था करना इतना आसान है।
दूसरे, कुछ मामलों में यह आवश्यक है।

उदाहरण के लिए, सिस्टम डिस्क को प्रतिस्थापित करते समय, आपको पहले परिनियोजन सिस्टम पर जाने की आवश्यकता है, एक कार्य बनाएं, और सही परिनियोजन के बाद, सर्वर ssh के माध्यम से सुलभ होगा, और आप उस पर एप्लिकेशन को रोल कर सकते हैं। यदि हमने यह सब एक प्लेबुक में किया, तो होस्ट की दुर्गमता के कारण एंसिबल इसे निष्पादित नहीं कर पाएगा।

हम प्रत्येक सर्वर समूह के लिए Ansible भूमिकाओं का उपयोग करते हैं। यहां आप देख सकते हैं कि उनमें से एक में प्लेबुक (एस) कैसे व्यवस्थित हैं।



यह सुविधाजनक है, क्योंकि यह तुरंत स्पष्ट है कि कार्य कहाँ स्थित हैं। Main.yml में, जो Ansible भूमिका के लिए इनपुट है, हम बस सभी के लिए आवश्यक टिकट स्थिति या सामान्य कार्यों में शामिल कर सकते हैं, उदाहरण के लिए, पहचान पास करना या टोकन प्राप्त करना।

Investigation.yml

जांच और ओपन की स्थिति में टिकट के लिए दौड़। इस प्लेबुक के लिए सबसे महत्वपूर्ण चीज ब्लॉक डिवाइस का नाम है। यह जानकारी हमेशा उपलब्ध नहीं होती है।

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

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

prepare2change.yml

रोटेशन से डिस्क का आउटपुट, प्रतिस्थापन के लिए तैयारी। सबसे कठिन, महत्वपूर्ण चरण। यह वह जगह है जहां आप एप्लिकेशन को रोक सकते हैं जब इसे रोका नहीं जा सकता है। या एक डिस्क को बाहर निकालें जिसमें पर्याप्त प्रतिकृतियां नहीं थीं, और जिससे उपयोगकर्ताओं पर प्रभाव पड़ता है, कुछ डेटा खो देते हैं। यहां हमारे पास चैट में सबसे अधिक चेक और सूचनाएं हैं।

सरलतम मामले में, हम HW / MD RAID से ड्राइव निकालने की बात कर रहे हैं।

अधिक जटिल परिस्थितियों में (हमारे भंडारण प्रणालियों में), जब बैकअप को एप्लिकेशन स्तर पर किया जाता है, तो आपको एपीआई का उपयोग करके एप्लिकेशन पर जाने की आवश्यकता होती है, डिस्क आउटपुट की रिपोर्ट करें, इसे निष्क्रिय करें और पुनर्प्राप्ति शुरू करें।

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

changed.yml

डिस्क को बदलने के बाद, हम पहले इसकी उपलब्धता की जांच करते हैं।

इंजीनियर हमेशा नई डिस्क में नहीं डालते हैं, इसलिए हमने SMART मानों के लिए एक चेक जोड़ा है जो हमें संतुष्ट करते हैं।


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

ready.yml

सबसे सरल मामला: HW / SW छापे सिंक्रनाइज़ेशन की जाँच करना या एप्लिकेशन में डेटा सिंक्रनाइज़ेशन को समाप्त करना।

एप्लिकेशन एपीआई

मैंने कई बार उल्लेख किया कि बॉट अक्सर एप्लिकेशन एपीआई तक पहुंचता है। बेशक, सभी अनुप्रयोगों में आवश्यक तरीके नहीं थे, इसलिए मुझे उन्हें परिष्कृत करना पड़ा। यहां सबसे महत्वपूर्ण तरीके हैं जिनका हम उपयोग करते हैं:

• स्थिति। एक क्लस्टर या डिस्क की स्थिति यह समझने के लिए कि क्या इसके साथ काम करना संभव है;
  
• शुरू / बंद करो। डिस्क की सक्रियण-निष्क्रियता;
  
• पलायन / पुनर्स्थापन। प्रतिस्थापन के दौरान और बाद में प्रवासन और डेटा रिकवरी।
  

सबक अंसिबल द्वारा सीखा गया

मैं वास्तव में Ansible से प्यार करता हूं। लेकिन अक्सर, जब मैं विभिन्न ओपनसोर्स परियोजनाओं को देखता हूं और देखता हूं कि लोग कैसे प्लेबुक लिखते हैं, तो मुझे थोड़ा डर लगता है। शेल / कमांड के लगातार उपयोग के कारण जब लूप / लूप, लचीलापन और आलस्य की कमी से जटिल तार्किक बुनाई होती है।

हमने यथासंभव हर संभव को सरल बनाने का निर्णय लिया, जिसका लाभ उठाते हुए, आंसिबल - प्रतिरूपकता का लाभ उठाया। उच्चतम स्तर पर प्लेबुक हैं, उन्हें किसी भी व्यवस्थापक द्वारा लिखा जा सकता है, एक तृतीय-पक्ष डेवलपर जो अंसिबल को थोड़ा जानता है।

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

यदि किसी भी तर्क को प्लेबुक में लागू करना मुश्किल है, तो हम इसे एक एंसेबल मॉड्यूल या फिल्टर में रखते हैं। लिपियों को पायथन और किसी अन्य भाषा में लिखा जा सकता है।

वे लिखने में आसान और तेज हैं। उदाहरण के लिए, डिस्क हाइलाइटिंग मॉड्यूल, जिसके उपयोग का एक उदाहरण ऊपर दिया गया है, इसमें 265 लाइनें हैं।



सबसे निचले स्तर पर पुस्तकालय है। इस परियोजना के लिए, हमने एक अलग एप्लिकेशन, हार्डवेयर और सॉफ़्टवेयर RAID पर एक प्रकार का अमूर्त लेखन किया, जो संबंधित अनुरोधों को पूरा करता है।



Ansible की सबसे बड़ी ताकत इसकी सादगी और समझदार प्लेबुक हैं। मेरा मानना ​​है कि आपको इसका उपयोग करने की आवश्यकता है और डरावनी याम्ल फ़ाइलों और बहुत सारी स्थितियों, शेल कोड और लूप को उत्पन्न नहीं करना है।

अगर आप हमारे अनुभव को Ansible API के साथ दोहराना चाहते हैं, तो दो बातों का ध्यान रखें:

• Playbook_executor और आम तौर पर playbook को समयबद्ध नहीं किया जा सकता है। Ssh सत्र पर एक टाइमआउट है, लेकिन प्लेबुक पर कोई टाइमआउट नहीं है। अगर हम ऐसी ड्राइव को अनमाउंट करने की कोशिश करते हैं जो सिस्टम में पहले से मौजूद नहीं है, तो प्लेबुक अनिश्चित काल तक चलेगी, इसलिए हमें इसे एक अलग आवरण में लपेटना होगा और टाइमआउट द्वारा मारना होगा।
  
• Ansible को कांटा जाता है, इसलिए इसका API थ्रेड सुरक्षित नहीं है। हम अपनी सभी प्लेबुक और सिंगल-थ्रेडेड लॉन्च करते हैं।
  

नतीजतन, हम लगभग 80% ड्राइव के प्रतिस्थापन को स्वचालित करने में सक्षम थे। सामान्य तौर पर, प्रतिस्थापन दर दोगुनी हो गई है। आज, व्यवस्थापक केवल घटना को देखता है और यह तय करता है कि डिस्क को बदलना है या नहीं, और फिर एक क्लिक करता है।

लेकिन अब हम एक और समस्या का सामना करना शुरू कर रहे हैं: कुछ नए प्रशासक नहीं जानते कि ड्राइव कैसे बदलें। :)