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

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

هذه المقالة هي نوع من كتابة الحروف للأداء في HighLoad + 2018

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

أول عدد قليل من الأرقام

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

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

حوادث

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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


اليوم ، يواصل المهندسون العمل بهذا الشكل عندما لا يحتاجون إلى مساعدة المسؤول.

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

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

إذا كان المسؤول متورطًا ، يكون المخطط أكثر تعقيدًا.


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

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

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


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

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

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

الدروس المستفادة في بناء سير العمل

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

استبدال محرك الأتمتة

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

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

حديقة الحيوان الاجهزة

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

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

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

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

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

مخطط عام

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


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

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


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


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


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

Diskobot

هو مكتوب هذا التطبيق في بيثون. إنه يختار التذاكر من جيرا وفقًا لجيه كيو إل . بناءً على حالة التذكرة ، يحصل الأخير على المعالج المقابل ، والذي يقوم بدوره بتشغيل حالة كتاب 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 

على سبيل المثال ، من بين التذاكر في حالة "قيد التقدم" ، يتم ملء البطاقات التي تحتوي على حجم القرص واسم الجهاز فقط اسم الجهاز هو اسم جهاز الكتلة المطلوب لتشغيل playbook. حجم القرص مطلوب حتى يعرف المهندس حجم القرص المطلوب.

ومن بين التذاكر ذات الحالة "جاهز" ، يتم تصفية التذاكر التي تحمل ملصق dbot_ignore. بالمناسبة ، نحن نستخدم علامات جيرا لكل من التصفية ، ولتمييز التذاكر المكررة ، وجمع الإحصاءات.

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

التفاعل مع Ansible

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

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

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

فيما يلي مثال لمهمة يتم فيها تطبيق رد الاتصال HTTP.

نتيجة playbooks نحصل على callaback (ق). هم من نوعين:

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

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

أيضًا من خلال رد اتصال HTTP نترك التعليقات ونغير حالة التذكرة.


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

وإليك مثال من playbook ، حيث قمنا بعرض قرص من جهاز 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_ لقسم مفصول في parted_info.

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

وضع الاختيار غير مرئي

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

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



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

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

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

هيكل قواعد اللعبة

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

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

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

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



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

Investigation.yml

يعمل على التذاكر في حالة التحقيق وفتح. الشيء الأكثر أهمية في هذا playbook هو اسم الجهاز كتلة. هذه المعلومات غير متوفرة دائمًا.

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

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

prepare2change.yml

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

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

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

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

changed.yml

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

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


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

ready.yml

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

API التطبيق

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

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

الدروس المستفادة من Ansible

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

قررنا تبسيط كل شيء قدر الإمكان ، مع الاستفادة من 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 مخيفة وعدد كبير من الشروط ، رمز قذيفة والحلقات.

إذا كنت ترغب في تكرار تجربتنا مع Ansible API ، ضع في اعتبارك أمرين:

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

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

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