أتمتة استبدال القرص مع Ansible

أهلاً بكم. أعمل كمسؤول نظام رئيسي في OK وأنا مسؤول عن التشغيل المستقر للبوابة. أريد أن أتحدث عن كيفية قيامنا ببناء عملية الاستبدال التلقائي للقرص ، ثم كيف استبعدنا المسؤول من هذه العملية واستبدلناه ببرنامج بوت.

هذه المقالة هي نوع من التحويل الصوتي العروض في HighLoad + 2018

بناء عملية استبدال القرص

أولا بعض الأرقام

OK هي خدمة عملاقة يستخدمها ملايين الأشخاص. يخدمها حوالي 7 آلاف خادم موجود في 4 مراكز بيانات مختلفة. يوجد أكثر من 70 ألف قرص في الخوادم. إذا قمت بتكديسها فوق بعضها البعض ، تحصل على برج يزيد ارتفاعه عن كيلومتر واحد.

محركات الأقراص الصلبة هي مكون الخادم الذي يفشل في أغلب الأحيان. في هذا المجلد ، يتعين علينا تغيير حوالي 30 قرصًا في الأسبوع ، وقد أصبح هذا الإجراء روتينًا غير ممتع للغاية.

الحوادث

لقد قدمنا ​​إدارة كاملة للحوادث في شركتنا. نسجل كل حادثة في جيرا ، ثم نقوم بحلها وتحليلها. إذا كان للحادث تأثير على المستخدمين ، فسنجتمع بالتأكيد ونفكر في كيفية الاستجابة بشكل أسرع في مثل هذه الحالات ، وكيفية تقليل التأثير ، وبالطبع كيفية منع التكرار.

التخزين ليس استثناء. يراقب Zabbix حالتهم. نحن نراقب الرسائل في Syslog بحثًا عن أخطاء الكتابة / القراءة ، ونحلل حالة غارات HW / SW ، ونراقب SMART ، ونحسب تآكل محركات أقراص الحالة الثابتة SSD.

كيف تغيرت الأقراص من قبل

عندما ينطلق أحد المشغلات في Zabbix ، يتم إنشاء حادثة في Jira ويتم تلقائيًا تعيين المهندسين المناسبين في مراكز البيانات. نقوم بذلك مع جميع حوادث المخلفات الخطرة ، أي تلك التي تتطلب نوعًا من العمل المادي على المعدات في مركز البيانات.
مهندس مركز البيانات هو الشخص الذي يحل المشكلات المتعلقة بالأجهزة ، وهو مسؤول عن تثبيت الخوادم وصيانتها وتفكيكها. بعد حصوله على تذكرة ، يبدأ المهندس في العمل. في أرفف الأقراص ، يغير الأقراص من تلقاء نفسه. ولكن في حالة عدم تمكنه من الوصول إلى الجهاز المطلوب ، يلجأ المهندس إلى مسؤولي نظام الخدمة للحصول على المساعدة. بادئ ذي بدء ، تحتاج إلى إخراج القرص من الدوران. للقيام بذلك ، تحتاج إلى إجراء التغييرات اللازمة على الخادم ، وإيقاف التطبيقات ، وإلغاء تحميل القرص.

مسؤول النظام المناوب مسؤول عن تشغيل البوابة بالكامل أثناء نوبة العمل. إنه يحقق في الحوادث ، ويقوم بالإصلاحات ، ويساعد المطورين في المهام الصغيرة. لا يتعامل فقط مع الأقراص الصلبة.

في الماضي ، تحدث مهندسو مركز البيانات مع مسؤول النظام. أرسل المهندسون روابط إلى تذاكر Jira ، وراجعها المسؤول ، واحتفظ بسجل عمل في بعض أجهزة الكمبيوتر المحمولة. ولكن بالنسبة لمثل هذه المهام ، تكون الدردشات غير ملائمة: فالمعلومات الموجودة هناك غير منظمة وتضيع بسرعة. نعم ، ويمكن للمسؤول ببساطة الابتعاد عن الكمبيوتر وعدم الاستجابة للطلبات لبعض الوقت ، ووقف المهندس عند الخادم مع حزمة من الأقراص وانتظر.

لكن أسوأ شيء هو أن المسؤولين لم يروا الصورة كاملة: ما هي حوادث القرص الموجودة ، حيث يمكن أن تنشأ مشكلة. هذا يرجع إلى حقيقة أننا نقدم جميع حوادث المخلفات الخطرة للمهندسين. نعم ، كان من الممكن عرض جميع الحوادث على لوحة تحكم المسؤول. لكن هناك الكثير منهم ، ولم يشارك المسؤول إلا في بعضها.

بالإضافة إلى ذلك ، لم يتمكن المهندس من تحديد الأولويات بشكل صحيح ، لأنه لا يعرف شيئًا عن الغرض من خوادم معينة ، حول توزيع المعلومات بين محركات الأقراص.

إجراء الاستبدال الجديد

أول شيء فعلناه هو نقل جميع حوادث القرص إلى نوع منفصل "قرص HW" وإضافة حقول "اسم الجهاز المحظور" و "الحجم" و "نوع القرص" إليه بحيث يتم حفظ هذه المعلومات في التذكرة ولا يجب أن تكون الدردشة باستمرار.

كما اتفقنا على أنه في إطار حادثة واحدة سنقوم بتغيير قرص واحد فقط. أدى هذا إلى تبسيط عملية الأتمتة إلى حد كبير ، وجمع الإحصائيات والعمل في المستقبل.

بالإضافة إلى ذلك ، تمت إضافة حقل "المسؤول المسؤول". يتم استبدال مسؤول النظام المناوب هناك تلقائيًا. هذا مريح للغاية ، لأن المهندس الآن يرى دائمًا من هو المسؤول. لا حاجة للذهاب إلى التقويم والنظر. كان هذا الحقل هو الذي جعل من الممكن عرض التذاكر على لوحة تحكم المسؤول ، حيث قد تكون هناك حاجة إلى مساعدته.

لكي يحصل جميع المشاركين على أقصى استفادة من الابتكارات ، أنشأنا فلاتر ولوحات معلومات وأخبرنا الرجال عنها. عندما يفهم الناس التغيير ، فإنهم لا ينأون بأنفسهم عنه كشيء غير ضروري. من المهم للمهندس معرفة رقم الحامل حيث يوجد الخادم وحجم ونوع القرص. يحتاج المسؤول ، أولاً وقبل كل شيء ، إلى فهم نوع مجموعة الخوادم ، وما التأثير الذي يمكن أن تحدثه عند استبدال القرص.

وجود الحقول وعرضها ملائم ، لكن هذا لم يحفظنا من الحاجة إلى استخدام الدردشات. للقيام بذلك ، كان علينا تغيير سير العمل.

كان من المعتاد أن يكون مثل هذا:

اليوم ، هذه هي الطريقة التي يستمر بها المهندسون في العمل عندما لا يحتاجون إلى مساعدة المسؤول.

أول شيء فعلناه هو تقديم وضع جديد بحث. تكون التذكرة في هذه الحالة عندما لا يكون المهندس قد قرر بعد ما إذا كان سيحتاج إلى مسؤول أم لا. من خلال هذه الحالة يمكن للمهندس تحويل التذكرة إلى المسؤول. بالإضافة إلى ذلك ، نقوم بتمييز التذاكر بهذه الحالة عند الحاجة إلى استبدال القرص ، ولكن القرص نفسه ليس موجودًا في الموقع. يحدث هذا في حالة CDN والمواقع البعيدة.

لقد أضفنا أيضًا حالة استعداد. يتم نقل التذكرة إليها بعد استبدال القرص. وهذا يعني أن كل شيء قد تم إنجازه بالفعل ، ولكن تتم مزامنة HW / SW RAID على الخادم. قد يستغرق هذا وقتًا طويلاً.

إذا كان المسؤول متورطًا في العمل ، فسيصبح المخطط أكثر تعقيدًا بعض الشيء.

خارج الوضع ساعات العمل يمكن ترجمة التذكرة من قبل كل من مسؤول النظام والمهندس. في الوضع قيد الإنجاز يقوم المسؤول بإزالة القرص من التدوير بحيث يمكن للمهندس ببساطة سحبه للخارج: تشغيل الإضاءة الخلفية ، وإلغاء تثبيت القرص ، وإيقاف التطبيقات ، اعتمادًا على مجموعة معينة من الخوادم.

ثم يتم ترجمة التذكرة إلى جاهز للتغيير: هذه إشارة للمهندس بإمكانية سحب القرص. تم بالفعل ملء جميع الحقول في Jira ، يعرف المهندس نوع القرص وحجمه. يتم إدخال هذه البيانات إما في الحالة السابقة تلقائيًا أو بواسطة المسؤول.

بعد استبدال القرص ، يتم نقل التذكرة إلى الحالة تغير. يتم التحقق من إدخال القرص الصحيح وإتمام التقسيم وبدء تشغيل التطبيق وبدء بعض مهام استعادة البيانات. أيضا ، يمكن نقل التذكرة إلى الحالة استعداد، في هذه الحالة يبقى المسؤول مسؤولاً ، لأنه بدأ القرص بالتناوب. المخطط الكامل يبدو هكذا.

إضافة حقول جديدة جعلت الحياة أسهل بالنسبة لنا. بدأ الرجال في العمل مع المعلومات المنظمة ، وأصبح من الواضح ما يجب القيام به وفي أي مرحلة. أصبحت الأولويات أكثر صلة ، حيث تم تحديدها الآن من قبل المسؤول.

لا حاجة للدردشات. بالطبع ، يمكن للمسؤول أن يكتب للمهندس "هنا تحتاج إلى استبدال أسرع" ، أو "لقد حان المساء بالفعل ، هل سيكون لديك الوقت لاستبداله؟". لكننا لم نعد نتواصل يوميًا في الدردشات حول هذه المشكلات.

بدأت الأقراص تتغير على دفعات. إذا جاء المسؤول للعمل مبكرًا ، فلديه وقت فراغ ، ولم يحدث شيء حتى الآن ، يمكنه إعداد عدد من الخوادم للاستبدال: ملء الحقول ، وإزالة الأقراص من التدوير ، ونقل المهمة إلى مهندس. يأتي مهندس إلى مركز البيانات بعد قليل ، ويرى المهمة ، ويأخذ محركات الأقراص اللازمة من المستودع ويغيرها على الفور. نتيجة لذلك ، زاد معدل الاستبدال.

الخبرة المكتسبة عند بناء سير العمل

• عند بناء إجراء ما ، تحتاج إلى جمع المعلومات من مصادر مختلفة.
  لم يعرف بعض المسؤولين لدينا أن المهندس يغير الأقراص بنفسه. يعتقد بعض الناس أن المهندسون ظلوا متزامنين مع MD RAID ، على الرغم من أن بعضهم لم يكن لديهم حتى إمكانية الوصول إليه. قام بعض المهندسين البارزين بهذا ، ولكن ليس دائمًا ، لأن العملية لم يتم وصفها في أي مكان.
• يجب أن يكون الإجراء بسيطًا ومفهومًا.
  يصعب على الإنسان أن يحافظ على العديد من الخطوات في رأسه. يجب وضع أهم الحالات المجاورة في جيرا على الشاشة الرئيسية. يمكنك إعادة تسميتها ، على سبيل المثال ، قيد التقدم نسميها جاهز للتغيير. ويمكن إخفاء باقي الحالات في القائمة المنسدلة حتى لا تكون قذرة للعين. لكن من الأفضل عدم تقييد الأشخاص ، لمنحهم الفرصة لإجراء الانتقال.
  اشرح قيمة الابتكار. عندما يفهم الناس ، فإنهم يقبلون الإجراء الجديد بشكل أفضل. كان من المهم جدًا بالنسبة لنا ألا ينقر الأشخاص على العملية برمتها ، بل يتابعونها. ثم بنينا على هذه الأتمتة.
• انتظر ، حلل ، افهم.
  لقد استغرقنا حوالي شهر لبناء الإجراءات والتنفيذ الفني والاجتماعات والمناقشات. وللتنفيذ - أكثر من ثلاثة أشهر. رأيت كيف بدأ الناس ببطء في استخدام الابتكار. كان هناك الكثير من السلبية في المراحل الأولى. لكنها كانت مستقلة تمامًا عن الإجراء نفسه ، تنفيذه الفني. على سبيل المثال ، لم يستخدم أحد المسؤولين Jira ، ولكن لم يستخدم مكون Jira الإضافي في Confluence ، ولم تكن بعض الأشياء متاحة له. أظهرنا له Jira ، وزاد المسؤول الإنتاجية من حيث المهام الشائعة واستبدال القرص.

أتمتة استبدال القرص

اقتربنا من أتمتة استبدال الأقراص عدة مرات. لقد كان لدينا بالفعل تطورات ونصوص ، لكنهم جميعًا عملوا إما في الوضع التفاعلي أو اليدوي ، فقد تطلبوا الإطلاق. وفقط بعد إدخال الإجراء الجديد ، أدركنا أنه كان بالضبط ما نحتاجه.

نظرًا لأن عملية الاستبدال الآن مقسمة إلى مراحل ، لكل منها منفذ وقائمة من الإجراءات ، يمكننا تمكين الأتمتة على مراحل ، وليس كلها مرة واحدة. على سبيل المثال ، أبسط مرحلة - جاهزة (التحقق من RAID / مزامنة البيانات) يمكن تفويضها بسهولة إلى الروبوت. عندما يتعلم الروبوت قليلاً ، يمكنك تكليفه بمهمة أكثر مسؤولية - وضع القرص في الدوران ، وما إلى ذلك.

إعداد حديقة الحيوان

قبل الحديث عن الروبوت ، دعنا نأخذ جولة قصيرة في حديقة حيوانات التثبيت الخاصة بنا. بادئ ذي بدء ، يرجع ذلك إلى الحجم الهائل لبنيتنا التحتية. ثانيًا ، نحاول لكل خدمة اختيار التكوين الأمثل للأجهزة. لدينا حوالي 20 طرازًا من أجهزة RAID ، بشكل أساسي LSI و Adaptec ، ولكن هناك أيضًا إصدارات مختلفة من HP و DELL. كل وحدة تحكم RAID لها أداة الإدارة الخاصة بها. قد تختلف مجموعة الأوامر وإخراجها من إصدار لآخر لكل وحدة تحكم RAID. في حالة عدم استخدام HW-RAID ، قد يكون هناك mdraid.

نحن نقوم بجميع عمليات التثبيت الجديدة تقريبًا بدون تكرار القرص. نحن نحاول التوقف عن استخدام RAID للأجهزة والبرامج بعد الآن ، حيث نقوم بعمل نسخة احتياطية من أنظمتنا على مستوى مراكز البيانات ، وليس الخوادم. ولكن بالطبع هناك العديد من الخوادم القديمة التي تحتاج إلى صيانة.

يتم إلقاء الأجهزة الخام في مكان ما في وحدات تحكم RAID ، يتم استخدام JBODs في مكان ما. هناك تكوينات مع قرص نظام واحد في الخادم ، وإذا كان يلزم استبداله ، فيجب عليك إعادة تشغيل الخادم بتثبيت نظام التشغيل والتطبيقات ، ونفس الإصدارات ، ثم إضافة ملفات التكوين ، وتشغيل التطبيقات. هناك أيضًا الكثير من مجموعات الخوادم التي يتم فيها التكرار ليس على مستوى نظام القرص الفرعي ، ولكن مباشرة في التطبيقات نفسها.

في المجموع ، لدينا أكثر من 400 مجموعة خوادم فريدة تعمل على حوالي 100 تطبيق مختلف. لتغطية هذا العدد الهائل من الخيارات ، كنا بحاجة إلى أداة أتمتة غنية بالميزات. يفضل أن يكون ذلك باستخدام DSL بسيط ، بحيث لا يدعمه الشخص الذي كتبه فقط.

اخترنا Ansible لأنه بدون وكيل: لم تكن هناك حاجة لإعداد البنية التحتية ، بداية سريعة. بالإضافة إلى ذلك ، تمت كتابته بلغة Python ، والتي يتم قبولها كمعيار في الفريق.

مخطط عام

لنلقِ نظرة على مخطط الأتمتة العام باستخدام مثال حادثة واحدة. يكتشف Zabbix أن قرص sdb قد فشل ، وانطلق المشغل ، ويتم إنشاء تذكرة في Jira. نظر المدير إليه ، وأدرك أن هذه ليست نسخة مكررة وليست إيجابية خاطئة ، أي أن القرص يحتاج إلى التغيير ، ونقل التذكرة إلى قيد التقدم.

يقوم تطبيق DiskoBot ، المكتوب بلغة Python ، بإجراء تصويت دوري على Jira للحصول على تذاكر جديدة. يلاحظ ظهور بطاقة جديدة قيد التقدم ، ويتم تشغيل سلسلة المحادثات المقابلة ، والتي تقوم بتشغيل كتاب التشغيل في Ansible (يتم ذلك لكل حالة في Jira). في هذه الحالة ، يتم تشغيل Prepare2change.

يذهب Ansible إلى المضيف ، ويزيل القرص من الدوران ويبلغ عن الحالة إلى التطبيق عبر عمليات الاسترجاعات.

بناءً على النتائج ، يقوم الروبوت تلقائيًا بتغيير التذكرة إلى جاهزة للتغيير. يتلقى المهندس إشعارًا ويذهب لتغيير القرص ، وبعد ذلك يقوم بنقل التذكرة إلى تم التغيير.

وفقًا للمخطط أعلاه ، تعود التذكرة إلى الروبوت ، الذي يقوم بتشغيل دفتر تشغيل آخر ، وينتقل إلى المضيف ويضع القرص في وضع الدوران. يقوم الروبوت بإغلاق التذكرة. الصيحة!

الآن دعنا نتحدث عن بعض مكونات النظام.

ديسكوبوت

هذا التطبيق مكتوب بلغة بايثون. تختار التذاكر من Jira وفقًا لـ JQL. اعتمادًا على حالة التذكرة ، يصل الأخير إلى المعالج المقابل ، والذي بدوره يطلق كتاب اللعب Ansible المقابل للحالة.

يتم تحديد 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. بالمناسبة ، نستخدم ملصقات Jira لمثل هذه التصفية ولتمييز التذاكر المكررة وجمع الإحصائيات.

في حالة فشل دليل التشغيل ، تقوم Jira بتعيين التسمية dbot_failed بحيث يمكن فرزها لاحقًا.

التفاعل مع أنسبل

يتفاعل التطبيق مع أنسبل من خلال Ansible بايثون API. في playbook_executor نقوم بتمرير اسم ملف ومجموعة من المتغيرات. يتيح لك هذا الاحتفاظ بمشروع Ansible في شكل ملفات yml عادية ، وعدم وصفه في كود Python.

أيضًا ، يتم إرسال اسم جهاز الحظر ، وحالة التذكرة ، وكذلك callback_url ، حيث يتم ترميز مفتاح المشكلة ، إلى Ansible عبر * extra_vars * - يتم استخدامه لرد الاتصال في HTTP.

لكل عملية تشغيل ، يتم إنشاء مخزون مؤقت ، يتكون من مضيف واحد والمجموعة التي ينتمي إليها هذا المضيف ، بحيث يتم تطبيق Group_vars.

فيما يلي مثال لمهمة تنفذ رد اتصال HTTP.

نحصل على نتيجة تنفيذ قواعد اللعبة باستخدام callaback (s). هم من نوعين:

• أنسبل البرنامج المساعد لرد الاتصاليوفر بيانات عن نتائج تنفيذ قواعد اللعبة. يصف المهام التي تم إطلاقها أو إكمالها بنجاح أو دون جدوى. يتم استدعاء رد الاتصال هذا عندما ينتهي كتاب التشغيل من اللعب.
• رد اتصال HTTP للحصول على معلومات أثناء تشغيل دليل التشغيل. في مهمة Ansible ، نقوم بتنفيذ طلب POST / GET إلى جانب تطبيقنا.

من خلال رد (نداءات) HTTP ، يتم تمرير المتغيرات التي تم تحديدها أثناء تنفيذ كتاب التشغيل والتي نريد حفظها واستخدامها في عمليات التشغيل اللاحقة. نكتب هذه البيانات في سكلايت.

أيضًا عبر رد الاتصال 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_ callback هنا ، حيث يتم حماية مفتاح المشكلة واسم المضيف. عندما ينفذ Ansible طلب POST هذا ، يفهم الروبوت أنه جاء كجزء من حادث كذا وكذا.

وإليك مثال من كتاب التشغيل الذي أخرجنا فيه قرصًا من جهاز MD:

  # 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

تعمل هذه المهمة على تغيير حالة تذكرة Jira إلى "جاهز للتغيير" وإضافة تعليق. يحتوي متغير mdam_data أيضًا على قائمة بأجهزة md التي تمت إزالة القرص منها ، ويحتوي parted_info على تفريغ قسم من مفترق.

عندما يقوم المهندس بإدخال قرص جديد ، يمكننا استخدام هذه المتغيرات لاستعادة تفريغ القسم ، وكذلك إدخال القرص في أجهزة md التي تمت إزالته منها.

وضع الاختيار أنسبل

كان تشغيل الأتمتة مخيفًا. لذلك ، قررنا تشغيل جميع كتيبات اللعبة في الوضع
ركض جاف، حيث لا يقوم Ansible بتنفيذ أي إجراءات على الخوادم ، ولكنه يحاكيها فقط.

يتم تشغيل هذا الإطلاق من خلال وحدة رد اتصال منفصلة ، ويتم حفظ نتيجة تنفيذ دليل التشغيل في Jira كتعليق.

أولاً ، سمح بالتحقق من عمل الروبوت وكتب اللعب. ثانيًا ، زاد من ثقة المسؤولين في الروبوت.

عندما اجتزنا عملية التحقق وأدركنا أنه من الممكن تشغيل Ansible ليس فقط في وضع التشغيل الجاف ، فقد صنعنا زر Run Diskobot في Jira لتشغيل نفس دفتر اللعب مع نفس المتغيرات على نفس المضيف ، ولكن في الوضع العادي.

أيضًا ، يتم استخدام الزر لإعادة تشغيل كتاب التشغيل في حالة تعطله.

هيكل كتيبات التشغيل

لقد ذكرت بالفعل أنه بناءً على حالة تذكرة Jira ، يُطلق الروبوت كتيبات لعب مختلفة.

أولاً ، من الأسهل بكثير تنظيم المدخل.
ثانياً ، في بعض الحالات يكون الأمر ضروريًا ببساطة.

على سبيل المثال ، عند استبدال قرص النظام ، تحتاج أولاً إلى الانتقال إلى نظام النشر ، وإنشاء مهمة ، وبعد النشر الصحيح ، سيصبح الخادم متاحًا عبر ssh ، ويمكنك تشغيل التطبيق عليه. إذا فعلنا كل هذا في دليل واحد ، فلن يتمكن Ansible من تنفيذه بسبب عدم توفر المضيف.

نستخدم أدوار Ansible لكل مجموعة من الخوادم. يمكنك هنا مشاهدة كيفية تنظيم كتيبات التشغيل في أحدها.

هذا مناسب ، لأنه من الواضح على الفور مكان تواجد المهام. في main.yml ، وهي المدخلات لدور Ansible ، يمكننا ببساطة تضمين حالة التذكرة أو المهام العامة الضرورية للجميع ، على سبيل المثال ، تمرير الهوية أو الحصول على رمز مميز.

التحقيق. lyml

تم إطلاقه للحصول على تذاكر في حالتي التحقيق والفتح. أهم شيء في هذا الدليل هو اسم جهاز الكتلة. هذه المعلومات ليست متاحة دائما.

للحصول عليه ، نقوم بتحليل ملخص Jira ، القيمة الأخيرة من مشغل Zabbix. قد يحتوي على اسم جهاز الكتلة - محظوظ. وقد تحتوي على نقطة تحميل - فأنت بحاجة للذهاب إلى الخادم وتحليل القرص المطلوب وحسابه. أيضًا ، يمكن للمشغل إرسال عنوان scsi أو بعض المعلومات الأخرى. ولكن يحدث أيضًا أنه لا توجد أدلة ، وعليك أن تحلل.

بعد معرفة اسم جهاز الكتلة ، نقوم بجمع معلومات حول نوع وحجم القرص منه لملء الحقول في Jira. نقوم أيضًا بإزالة المعلومات حول البائع والطراز والبرامج الثابتة والمعرف و SMART ولصق كل هذا في تعليق في تذكرة Jira. لم يعد المسؤول والمهندس بحاجة للبحث عن هذه البيانات. 🙂

Prepar2change.yml

طرد من الدوران ، والاستعداد للاستبدال. المرحلة الأكثر صعوبة ومسؤولة. هذا هو المكان الذي يمكنك فيه إيقاف التطبيق عندما لا يمكن إيقافه. أو سحب قرص يفتقر إلى النسخ المتماثلة ، وبالتالي يكون له تأثير على المستخدمين ، ويفقد بعض البيانات. هنا لدينا معظم الفحوصات والإشعارات في الدردشة.

في أبسط الحالات ، نحن نتحدث عن إزالة قرص من HW / MD RAID.

في المواقف الأكثر تعقيدًا (في أنظمة التخزين لدينا) ، عند إجراء النسخ الاحتياطي على مستوى التطبيق ، تحتاج إلى الانتقال إلى التطبيق عبر واجهة برمجة التطبيقات ، والإبلاغ عن إخراج القرص ، وإلغاء تنشيطه وبدء الاستعادة.

نحن الآن نهاجر بشكل جماعي إلى السحابة، وإذا كان الخادم غائمًا ، فإن Diskobot يصل إلى واجهة برمجة التطبيقات السحابية ، ويقول إنه سيعمل مع هذا العميل - الخادم الذي تعمل عليه الحاويات - ويطلب "ترحيل جميع الحاويات من هذا العميل". وفي الوقت نفسه ، يتم تشغيل الإضاءة الخلفية للقرص ، بحيث يمكن للمهندس أن يرى على الفور أي واحد يجب سحبه.

تم تغييره

بعد استبدال القرص ، نتحقق أولاً من توفره.

لا يقوم المهندسون دائمًا بتثبيت أقراص جديدة ، لذلك قمنا بإضافة فحص لقيم SMART التي نسعد بها.

ما هي السمات التي ننظر إليهاعدد القطاعات المعاد تخصيصها (5) <100
عدد القطاعات المعلقة الحالية (107) == 0

إذا فشل محرك الأقراص في الاختبار ، يُطلب من المهندس إعادة الاستبدال. إذا كان كل شيء على ما يرام ، يتم إيقاف تشغيل الإضاءة الخلفية ، ويتم وضع العلامات ويتم تدوير القرص.

جاهز

أبسط حالة: التحقق من مزامنة HW / SW raid أو انتهاء مزامنة البيانات في التطبيق.

واجهات برمجة التطبيقات للتطبيق

لقد ذكرت عدة مرات أنه غالبًا ما يصل الروبوت إلى واجهة برمجة تطبيقات التطبيق. بالطبع ، لم يكن لدى جميع الطلبات الأساليب اللازمة ، لذلك كان لا بد من الانتهاء منها. فيما يلي أهم الطرق التي نستخدمها:

• حالة. حالة الكتلة أو القرص لمعرفة ما إذا كان من الممكن العمل معها ؛
• بدء توقف. تنشيط القرص وإلغاء تنشيطه ؛
• الهجرة / الاستعادة. ترحيل واستعادة البيانات أثناء وبعد الاستبدال.

التجربة المقدمة من أنسيبل

أنا حقا أحب أنسبل. لكن في كثير من الأحيان ، عندما أنظر إلى مشاريع مختلفة مفتوحة المصدر وأرى كيف يكتب الناس كتيبات اللعب ، أشعر بالخوف قليلاً. التشابك المنطقي المعقد للوقت / الحلقة ، ونقص المرونة والجهد العاطفي بسبب الاستخدام المتكرر للقذيفة / الأمر.

قررنا تبسيط كل شيء قدر الإمكان ، والاستفادة من ميزة Ansible - النمطية. على أعلى مستوى هي كتب اللعب ، ويمكن كتابتها من قبل أي مسؤول ، مطور تابع لجهة خارجية يعرف القليل عن Ansible.

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

إذا كان من الصعب تنفيذ بعض المنطق في كتيبات اللعبة ، فسننقله إلى وحدة أو مرشح Ansible. يمكن كتابة البرامج النصية بلغة بايثون أو أي لغة أخرى.

إنها سهلة وسريعة الكتابة. على سبيل المثال ، تحتوي وحدة إضاءة القرص الموضحة أعلاه على 265 سطرًا.

في الطابق السفلي توجد المكتبة. بالنسبة لهذا المشروع ، كتبنا تطبيقًا منفصلاً ، وهو نوع من التجريد على RAID للأجهزة والبرامج التي تنفذ الطلبات المقابلة.

تتمثل أعظم نقاط القوة في Ansible في بساطتها وكتيبات اللعب سهلة الفهم. أعتقد أنك بحاجة إلى استخدام هذا وعدم إنشاء ملفات yaml رهيبة وعدد كبير من الشروط ، ورمز shell والحلقات.

إذا كنت ترغب في تكرار تجربة Ansible API الخاصة بنا ، فضع في اعتبارك شيئين:

• لا يمكن تجاوز مهلة Playbook_executor و playbook بشكل عام. هناك مهلة في جلسة ssh ، لكن لا توجد مهلة في دليل التشغيل. إذا حاولنا إلغاء تثبيت قرص لم يعد موجودًا في النظام ، فسيتم تشغيل دليل التشغيل إلى أجل غير مسمى ، لذلك كان علينا أن نلف إطلاقه في غلاف منفصل ونوقفه عند انتهاء المهلة.
• يعمل Ansible على أساس عمليات التفرع ، لذا فإن API الخاص به ليس آمنًا على مؤشر الترابط. نقوم بتشغيل جميع كتيبات اللعب الخاصة بنا في سلسلة واحدة.

نتيجة لذلك ، تمكنا من أتمتة استبدال حوالي 80٪ من الأقراص. بشكل عام ، تضاعف معدل الاستبدال. اليوم ، ينظر المسؤول فقط إلى الحادث ويقرر ما إذا كان سيغير القرص أم لا ، ثم يقوم بنقرة واحدة.

لكننا بدأنا الآن نواجه مشكلة أخرى: بعض المسؤولين الجدد لا يعرفون كيفية تغيير محركات الأقراص. 🙂

المصدر: www.habr.com