جایگزینی خودکار دیسک با Ansible

سلام به همه. من به عنوان یک مدیر پیشرو سیستم در OK کار می کنم و مسئول عملکرد پایدار پورتال هستم. من می خواهم در مورد اینکه چگونه یک فرآیند برای جایگزینی خودکار دیسک ها ایجاد کردیم و سپس چگونه مدیر را از این فرآیند حذف کردیم و او را با یک ربات جایگزین کردیم صحبت کنم.

این مقاله نوعی نویسه‌گردانی است اجراها در HighLoad+ 2018

ایجاد فرآیند تعویض دیسک

ابتدا تعدادی اعداد

OK یک سرویس غول پیکر است که میلیون ها نفر از آن استفاده می کنند. حدود 7 هزار سرور به آن سرویس می دهند که در 4 مرکز داده مختلف قرار دارند. سرورها شامل بیش از 70 هزار دیسک هستند. اگر آنها را روی هم قرار دهید، برجی به ارتفاع بیش از 1 کیلومتر خواهید داشت.

هارد دیسک جزء سروری است که اغلب از کار می افتد. با چنین حجم هایی باید حدود 30 دیسک در هفته عوض کنیم و این رویه به یک روال نه چندان خوشایند تبدیل شده است.

حوادث

شرکت ما مدیریت حوادث تمام عیار را معرفی کرده است. ما هر حادثه را در جیرا ضبط می کنیم و سپس آن را حل و فصل می کنیم. اگر اتفاقی روی کاربران تاثیر داشت، قطعا دور هم جمع می‌شویم و به این فکر می‌کنیم که چگونه در چنین مواقعی سریع‌تر پاسخ دهیم، چگونه اثر را کاهش دهیم و البته چگونه از تکرار آن جلوگیری کنیم.

دستگاه های ذخیره سازی نیز از این قاعده مستثنی نیستند. وضعیت آنها توسط Zabbix نظارت می شود. ما پیام‌ها را در Syslog برای خطاهای نوشتن/خواندن کنترل می‌کنیم، وضعیت حملات HW/SW را تجزیه و تحلیل می‌کنیم، SMART را نظارت می‌کنیم و سایش SSD را محاسبه می‌کنیم.

نحوه تغییر دیسک ها قبلا

هنگامی که یک ماشه در Zabbix رخ می دهد، یک حادثه در Jira ایجاد می شود و به طور خودکار به مهندسان مناسب در مراکز داده اختصاص داده می شود. ما این کار را با تمام حوادث HW انجام می دهیم، یعنی مواردی که نیاز به کار فیزیکی با تجهیزات موجود در مرکز داده دارند.
مهندس مرکز داده شخصی است که مسائل مربوط به سخت افزار را حل می کند و مسئولیت نصب، نگهداری و از بین بردن سرورها را بر عهده دارد. پس از دریافت بلیط، مهندس دست به کار می شود. در قفسه های دیسک، او دیسک ها را به طور مستقل تغییر می دهد. اما اگر به دستگاه مورد نیاز دسترسی نداشته باشد، مهندس برای کمک به مدیران سیستم کشیک مراجعه می کند. اول از همه، شما باید دیسک را از چرخش خارج کنید. برای انجام این کار، باید تغییرات لازم را روی سرور انجام دهید، برنامه ها را متوقف کنید و دیسک را از حالت نصب خارج کنید.

مدیر سیستم وظیفه عملکرد کل پورتال را در طول شیفت کاری بر عهده دارد. او حوادث را بررسی می کند، تعمیرات را انجام می دهد و به توسعه دهندگان کمک می کند کارهای کوچک را انجام دهند. او فقط با هارد دیسک کار نمی کند.

پیش از این، مهندسان مرکز داده از طریق چت با مدیر سیستم در ارتباط بودند. مهندسان پیوندهایی را به بلیط های جیرا فرستادند، مدیر آنها را دنبال کرد، گزارش کار را در یک دفترچه یادداشت نگه داشت. اما چت ها برای چنین کارهایی ناخوشایند هستند: اطلاعات در آنجا ساختارمند نیستند و به سرعت از بین می روند. و مدیر به سادگی می توانست از رایانه دور شود و برای مدتی به درخواست ها پاسخ ندهد، در حالی که مهندس با پشته ای از دیسک ها در سرور ایستاده بود و منتظر بود.

اما بدترین چیز این بود که مدیران کل تصویر را ندیدند: چه اتفاقاتی در دیسک وجود داشت، که به طور بالقوه ممکن است مشکل ایجاد شود. این به دلیل این واقعیت است که ما تمام حوادث HW را به مهندسان واگذار می کنیم. بله، امکان نمایش تمام اتفاقات در داشبورد مدیر وجود داشت. اما تعداد زیادی از آنها وجود دارد و مدیر فقط برای برخی از آنها درگیر بود.

علاوه بر این، مهندس نمی تواند اولویت ها را به درستی تعیین کند، زیرا او چیزی در مورد هدف سرورهای خاص یا توزیع اطلاعات بین درایوها نمی داند.

روش جدید جایگزینی

اولین کاری که انجام دادیم این بود که همه حوادث دیسک را به یک نوع جداگانه "HW disk" منتقل کردیم و فیلدهای "block name device"، "size" و "disk type" را به آن اضافه کردیم تا این اطلاعات در بلیط ذخیره شود و نیازی به تبادل مداوم در چت نیست.

ما همچنین توافق کردیم که در طول یک حادثه فقط یک دیسک را تغییر دهیم. این به طور قابل توجهی فرآیند اتوماسیون، جمع آوری آمار و کار در آینده را ساده کرد.

علاوه بر این، قسمت "مدیر مسئول" را اضافه کردیم. مدیر وظیفه سیستم به طور خودکار در آنجا درج می شود. این بسیار راحت است، زیرا اکنون مهندس همیشه می بیند که چه کسی مسئول است. نیازی به رفتن به تقویم و جستجو نیست. این فیلد بود که امکان نمایش بلیط‌ها را در داشبورد مدیر فراهم کرد که ممکن است به کمک او نیاز داشته باشد.

برای اطمینان از اینکه همه شرکت‌کنندگان حداکثر سود را از نوآوری‌ها دریافت می‌کنند، فیلترها و داشبوردهایی ایجاد کردیم و در مورد آنها به بچه‌ها گفتیم. وقتی مردم تغییرات را درک می کنند، از آنها به عنوان چیزی غیر ضروری فاصله نمی گیرند. برای یک مهندس مهم است که شماره رک که سرور در آن قرار دارد، اندازه و نوع دیسک را بداند. مدیر اول از همه باید بفهمد که این چه نوع گروهی از سرورها است و چه تأثیری ممکن است هنگام جایگزینی دیسک داشته باشد.

وجود فیلدها و نمایش آنها راحت است، اما ما را از نیاز به استفاده از چت نجات نداد. برای این کار باید گردش کار را تغییر می دادیم.

قبلا اینجوری بود:

اینگونه است که مهندسان امروز در حالی که نیازی به کمک مدیر ندارند به کار خود ادامه می دهند.

اولین کاری که انجام دادیم معرفی وضعیت جدید بود تحقیق کردن. بلیط در این وضعیت زمانی است که مهندس هنوز تصمیم نگرفته است که آیا به مدیر نیاز دارد یا خیر. از طریق این وضعیت، مهندس می تواند بلیط را به مدیر منتقل کند. علاوه بر این، ما از این وضعیت برای علامت گذاری بلیط ها در زمانی که دیسکی نیاز به تعویض دارد استفاده می کنیم، اما خود دیسک در سایت نیست. این در مورد CDN ها و سایت های راه دور اتفاق می افتد.

وضعیت را نیز اضافه کردیم آماده تحویل. بلیط پس از تعویض دیسک به آن منتقل می شود. یعنی همه چیز قبلا انجام شده است، اما RAID HW/SW روی سرور همگام شده است. این می تواند مدت زیادی طول بکشد.

اگر یک مدیر در کار باشد، طرح کمی پیچیده تر می شود.

از وضعیت باز کن بلیط را هم مدیر سیستم و هم مهندس می توانند ترجمه کنند. در وضعیت در حال پیشرفت مدیر دیسک را از چرخش خارج می کند تا مهندس بتواند به سادگی آن را بیرون بکشد: بسته به گروه خاصی از سرورها، نور پس زمینه را روشن می کند، دیسک را جدا می کند، برنامه ها را متوقف می کند.

سپس بلیط به آماده تغییر است: این یک سیگنال به مهندس است که دیسک را می توان بیرون کشید. همه فیلدها در Jira قبلاً پر شده اند، مهندس می داند نوع و اندازه دیسک چیست. این داده ها یا به صورت خودکار در وضعیت قبلی یا توسط مدیر وارد می شوند.

پس از تعویض دیسک، وضعیت بلیط به تغییر می یابد تغییر کرد. بررسی می کند که دیسک صحیح درج شده است، پارتیشن بندی انجام شده است، برنامه راه اندازی شده است و برخی از وظایف بازیابی اطلاعات راه اندازی می شوند. بلیط همچنین می تواند به وضعیت منتقل شود آماده تحویل، در این صورت مدیر مسئول باقی می ماند، زیرا دیسک را در چرخش قرار داده است. نمودار کامل به این شکل است.

افزودن فیلدهای جدید زندگی ما را بسیار آسان تر کرد. بچه ها شروع به کار با اطلاعات ساختاریافته کردند، مشخص شد که چه کاری باید انجام شود و در چه مرحله ای. اولویت ها بسیار مرتبط تر شده اند، زیرا اکنون توسط مدیر تعیین می شوند.

نیازی به چت نیست. البته، مدیر می‌تواند به مهندس بنویسد: «این باید سریع‌تر تعویض شود» یا «از قبل عصر است، آیا وقت دارید آن را تعویض کنید؟» اما ما دیگر در چت های روزانه در مورد این مسائل ارتباط برقرار نمی کنیم.

دیسک ها به صورت دسته ای تغییر کردند. اگر مدیر کمی زودتر سر کار بیاید، وقت آزاد دارد و هنوز هیچ اتفاقی نیفتاده است، می تواند تعدادی سرور را برای جایگزینی آماده کند: فیلدها را پر کنید، دیسک ها را از چرخش خارج کنید و کار را به یک مهندس منتقل کنید. مهندس کمی دیرتر به مرکز داده می آید، کار را می بیند، درایوهای لازم را از انبار می گیرد و بلافاصله آنها را جایگزین می کند. در نتیجه نرخ جایگزینی افزایش یافته است.

درس هایی که هنگام ایجاد گردش کار آموخته می شود

• هنگام ساخت یک رویه، باید اطلاعات را از منابع مختلف جمع آوری کنید.
  برخی از مدیران ما نمی دانستند که مهندس خودش دیسک ها را تغییر می دهد. برخی از مردم فکر می کردند که هماهنگ سازی MD RAID توسط مهندسان انجام می شود، حتی اگر برخی از آنها حتی به این کار دسترسی نداشتند. برخی از مهندسان برجسته این کار را انجام دادند، اما نه همیشه به این دلیل که این فرآیند در جایی توضیح داده نشده بود.
• روش باید ساده و قابل درک باشد.
  برای یک فرد سخت است که مراحل زیادی را در ذهن داشته باشد. مهمترین وضعیت های همسایه در جیرا باید در صفحه اصلی قرار گیرند. می‌توانید نام آن‌ها را تغییر دهید، برای مثال، ما در حال آماده‌سازی را برای تغییر صدا می‌زنیم. و وضعیت‌های دیگر را می‌توان در یک منوی کشویی پنهان کرد تا مشکلی برای آنها ایجاد نشود. اما بهتر است افراد را محدود نکنیم و به آنها فرصت دهیم که گذار را انجام دهند.
  ارزش نوآوری را توضیح دهید. وقتی مردم درک کنند، رویه جدید را بیشتر می پذیرند. برای ما بسیار مهم بود که مردم در کل فرآیند کلیک نکنند، بلکه آن را دنبال کنند. سپس ما اتوماسیون را بر این اساس ساختیم.
• صبر کن، تحلیل کن، بفهم.
  حدود یک ماه طول کشید تا رویه، اجرای فنی، جلسات و بحث ها را بسازیم. و اجرای آن بیش از سه ماه طول می کشد. من دیدم که چگونه مردم به آرامی شروع به استفاده از نوآوری می کنند. در مراحل اولیه منفی زیادی وجود داشت. اما کاملاً مستقل از خود رویه و اجرای فنی آن بود. به عنوان مثال، یکی از مدیران از 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 که به زبان پایتون نوشته شده است، به صورت دوره ای از Jira برای بلیط های جدید نظرسنجی می کند. متوجه می شود که یک بلیط جدید در حال پیشرفت ظاهر شده است، رشته مربوطه راه اندازی می شود، که کتاب بازی را در Ansible راه اندازی می کند (این کار برای هر وضعیت در Jira انجام می شود). در این حالت، Prepare2change راه اندازی می شود.

Ansible به میزبان ارسال می شود، دیسک را از چرخش حذف می کند و وضعیت را از طریق Callbacks به برنامه گزارش می دهد.

بر اساس نتایج، ربات به طور خودکار بلیط را برای تغییر به Ready منتقل می کند. مهندس یک اعلان دریافت می کند و برای تغییر دیسک می رود و پس از آن بلیط را به Changed منتقل می کند.

طبق طرحی که در بالا توضیح داده شد، بلیت به ربات برمی‌گردد، که کتاب بازی دیگری را راه‌اندازی می‌کند، به میزبان می‌رود و دیسک را در چرخش قرار می‌دهد. ربات بلیط را می بندد. هورا!

حالا بیایید در مورد برخی از اجزای سیستم صحبت کنیم.

Diskobot

این اپلیکیشن به زبان پایتون نوشته شده است. این بلیط ها را از 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 برچسب dbot_failed را اختصاص می‌دهد تا بعدا بتوان آن را مرتب کرد.

قابلیت همکاری با Ansible

برنامه با Ansible از طریق ارتباط برقرار می کند Ansible Python API. به playbook_executor نام فایل و مجموعه ای از متغیرها را ارسال می کنیم. این به شما امکان می دهد پروژه Ansible را در قالب فایل های yml معمولی نگهداری کنید، نه اینکه آن را در کد پایتون توصیف کنید.

همچنین در Ansible، از طریق *extra_vars*، نام دستگاه بلاک، وضعیت بلیط و همچنین callback_url که حاوی کلید شماره است - برای پاسخ به تماس در HTTP استفاده می شود.

برای هر راه اندازی، یک موجودی موقت ایجاد می شود که شامل یک میزبان و گروهی است که این میزبان به آن تعلق دارد، به طوری که group_vars اعمال می شود.

در اینجا یک مثال از یک کار است که پاسخ تماس HTTP را پیاده سازی می کند.

ما نتیجه اجرای playbooks را با استفاده از callaback (ها) دریافت می کنیم. آنها دو نوع هستند:

• افزونه پاسخ به تماس Ansible، داده هایی را در مورد نتایج اجرای playbook ارائه می دهد. وظایفی را که راه اندازی شده، با موفقیت یا ناموفق انجام شده اند را توصیف می کند. این تماس پس از اتمام پخش کتاب پخش فراخوانی می شود.
• پاسخ تماس HTTP برای دریافت اطلاعات در حین پخش کتاب پخش. در کار Ansible ما یک درخواست POST/GET را برای برنامه خود اجرا می کنیم.

متغیرها از طریق تماس (های) HTTP ارسال می‌شوند که در طول اجرای 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

مانند بسیاری از کارهای مشابه، آن را در یک فایل مشترک جداگانه قرار می دهیم و در صورت لزوم آن را درج می کنیم تا مدام در کتاب های بازی تکرار نشود. این شامل نشانی اینترنتی callback_ است که حاوی کلید شماره و نام میزبان است. هنگامی که 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_info یک پارتیشن dump از parted را ذخیره می‌کند.

هنگامی که مهندس یک دیسک جدید را وارد می کند، می توانیم از این متغیرها برای بازیابی پارتیشن dump و همچنین دیسک را در دستگاه های md که از آن حذف شده است استفاده کنیم.

حالت چک قابل قبول

روشن کردن اتوماسیون ترسناک بود. بنابراین، ما تصمیم گرفتیم که همه کتاب های پخش را در حالت اجرا کنیم
دویدن خشک، که در آن Ansible هیچ عملی را روی سرورها انجام نمی دهد، بلکه فقط آنها را شبیه سازی می کند.

چنین راه اندازی از طریق یک ماژول پاسخ تماس جداگانه اجرا می شود و نتیجه اجرای کتاب پخش در Jira به عنوان یک نظر ذخیره می شود.

اولاً، این امکان اعتبارسنجی کار ربات و کتاب‌های بازی را فراهم کرد. ثانیا، اعتماد مدیران را به ربات افزایش داد.

وقتی اعتبارسنجی را پشت سر گذاشتیم و متوجه شدیم که می‌توانید Ansible را نه تنها در حالت اجرا خشک اجرا کنید، یک دکمه Run Diskobot را در Jira ساختیم تا همان playbook را با متغیرهای مشابه در همان میزبان، اما در حالت عادی، اجرا کنیم.

علاوه بر این، از این دکمه برای راه اندازی مجدد کتاب بازی در صورت خرابی استفاده می شود.

ساختار کتاب های بازی

قبلاً اشاره کردم که بسته به وضعیت بلیط جیرا، ربات کتاب های بازی متفاوتی را راه اندازی می کند.

اولا، سازماندهی ورودی بسیار ساده تر است.
ثانیاً، در برخی موارد به سادگی لازم است.

به عنوان مثال، هنگام تعویض یک دیسک سیستم، ابتدا باید به سیستم استقرار بروید، یک وظیفه ایجاد کنید و پس از استقرار صحیح، سرور از طریق ssh در دسترس قرار می گیرد و می توانید برنامه را روی آن پخش کنید. اگر همه این کارها را در یک کتاب بازی انجام دهیم، Ansible به دلیل در دسترس نبودن هاست قادر به تکمیل آن نخواهد بود.

ما از نقش های Ansible برای هر گروه از سرورها استفاده می کنیم. در اینجا می توانید ببینید که چگونه کتاب(های) بازی در یکی از آنها سازماندهی شده اند.

این راحت است زیرا بلافاصله مشخص است که کدام وظایف در کجا قرار دارند. در main.yml، که ورودی نقش Ansible است، می‌توانیم به سادگی وضعیت بلیط یا وظایف کلی مورد نیاز برای همه را شامل کنیم، به عنوان مثال، پاس کردن شناسه یا دریافت توکن.

Investigation.yml

برای بلیط در وضعیت تحقیق و باز اجرا می شود. مهمترین چیز برای این کتاب بازی نام دستگاه بلوک است. این اطلاعات همیشه در دسترس نیست.

برای به دست آوردن آن، خلاصه Jira، آخرین مقدار از تریگر Zabbix را تجزیه و تحلیل می کنیم. ممکن است حاوی نام دستگاه بلوک باشد - خوش شانس. یا ممکن است حاوی یک نقطه نصب باشد، سپس باید به سرور بروید، آن را تجزیه کنید و دیسک مورد نیاز را محاسبه کنید. ماشه همچنین می تواند یک آدرس scsi یا برخی اطلاعات دیگر را منتقل کند. اما همچنین اتفاق می افتد که هیچ سرنخی وجود ندارد و شما باید تجزیه و تحلیل کنید.

پس از فهمیدن نام دستگاه بلوک، اطلاعات مربوط به نوع و اندازه دیسک را از آن جمع آوری می کنیم تا فیلدهای جیرا را پر کنیم. ما همچنین اطلاعات مربوط به فروشنده، مدل، سیستم عامل، شناسه، SMART را حذف می کنیم و همه اینها را در یک نظر در بلیط Jira درج می کنیم. مدیر و مهندس دیگر نیازی به جستجوی این داده ها ندارند. 🙂

përgatit2change.yml

حذف دیسک از چرخش، آماده سازی برای جایگزینی. سخت ترین و مهم ترین مرحله. این جایی است که می توانید برنامه را در زمانی که نباید متوقف شود متوقف کنید. یا دیسکی را بردارید که به اندازه کافی کپی ندارد و در نتیجه روی کاربران تأثیر بگذارد و برخی از داده ها را از دست بدهد. در اینجا ما بیشترین بررسی ها و اعلان ها را در چت داریم.

در ساده ترین حالت، ما در مورد حذف یک دیسک از HW/MD RAID صحبت می کنیم.

در شرایط پیچیده تر (در سیستم های ذخیره سازی ما)، زمانی که پشتیبان گیری در سطح برنامه انجام می شود، باید از طریق API به برنامه بروید، خروجی دیسک را گزارش دهید، آن را غیرفعال کنید و بازیابی را شروع کنید.

ما در حال حاضر به طور دسته جمعی مهاجرت می کنیم ابرو اگر سرور مبتنی بر ابر باشد، Diskobot API ابری را فراخوانی می‌کند، می‌گوید که قرار است با این مینیون - سروری که کانتینرها را اجرا می‌کند - کار کند و می‌پرسد «همه کانتینرها را از این مینیون منتقل کنید». و در همان زمان، نور پس زمینه دیسک را روشن می کند تا مهندس بلافاصله ببیند کدام یک باید بیرون کشیده شود.

عوض شد.yml

پس از تعویض دیسک، ابتدا در دسترس بودن آن را بررسی می کنیم.

مهندسان همیشه درایوهای جدید نصب نمی کنند، بنابراین ما یک بررسی برای مقادیر SMART اضافه کردیم که ما را راضی می کند.

به چه ویژگی هایی نگاه می کنیم؟تعداد بخش های تخصیص مجدد (5) < 100
تعداد بخش در انتظار فعلی (107) == 0

در صورت عدم موفقیت درایو در تست، به مهندس اطلاع داده می شود که دوباره آن را تعویض کند. اگر همه چیز مرتب باشد، نور پس زمینه خاموش می شود، علامت گذاری اعمال می شود و دیسک در چرخش قرار می گیرد.

آماده.yml

ساده ترین حالت: بررسی همگام سازی حمله HW/SW یا تکمیل همگام سازی داده ها در برنامه.

API APP

من چندین بار اشاره کرده ام که ربات اغلب به 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 هیچ تایم اوتی وجود ندارد. اگر بخواهیم دیسکی را که دیگر در سیستم وجود ندارد از حالت نصب خارج کنیم، playbook بی‌پایان اجرا می‌شود، بنابراین مجبور شدیم راه‌اندازی آن را در یک بسته‌بندی جداگانه بپیچیم و آن را با مهلت زمانی بکشیم.
• Ansible بر روی فرآیندهای فورکی اجرا می شود، بنابراین API آن امن نیست. ما همه کتاب های بازی خود را به صورت تک رشته ای اجرا می کنیم.

در نتیجه، ما توانستیم جایگزینی حدود 80 درصد از دیسک ها را به صورت خودکار انجام دهیم. به طور کلی، نرخ جایگزینی دو برابر شده است. امروز، مدیر فقط به حادثه نگاه می کند و تصمیم می گیرد که آیا دیسک باید تغییر کند یا نه، و سپس یک کلیک می کند.

اما اکنون با مشکل دیگری مواجه می شویم: برخی از مدیران جدید نمی دانند چگونه درایوها را تغییر دهند. 🙂

منبع: www.habr.com