Автоматизация на замяната на дисковете с помощта на Ansible

Здравейте. Работя като водещ системен администратор в ОК и отговарям за стабилната работа на портала. Искам да разкажа за това, как изградихме процеса за автоматична замяна на дисковете и как изключихме администратора от този процес, заменяйки го с бот.

Тази статия е своеобразна транслитерация изказването на HighLoad+ 2018

Изграждане на процеса за замяна на дискове

Първо малко цифри

ОК — това е гигантски сервис, който се използва от милиони хора. Поддържа се от около 7 хиляди сървъра, разположени в 4 различни дата центрове. В сървърите има повече от 70 хиляди диска. Ако ги нагръдим един върху друг, ще получим кула с височина над 1 км.

Хард дисковете са компонент на сървъра, който най-често се поврежда. При такива обеми ни се налага да сменяме около 30 диска седмично, а тази процедура стана не особено приятна рутина.

Инциденти

В компанията ни е внедрена пълноценна инцидент-мениджмънт система. Всеки инцидент се записва в Jira, след което го решаваме и разглеждаме. Ако инцидентът е имал ефект за потребителите, задължително се събираме и обсъждаме как да реагираме по-бързо в такива случаи, как да намалим ефекта и разбира се как да предотвратим повторението.

Накопителите не са изключение. За тяхното състояние следи Zabbix. Наблюдаваме съобщения в Syslog за грешки при запис/чете, анализираме състоянието на HW/SW RAID, следим SMART, за SSD изчисляваме износването.

Как се сменяха дисковете преди

Когато в Zabbix се задейства някакъв тригер, в Jira се създава инцидент и автоматично се назначава на съответните инженери в дата центровете. Правим това с всички HW инциденти, тоест такива, които изискват физическа работа с оборудването в дата центъра.
Инженерът в дата центъра е човекът, който решава въпросите, свързани с хардуера, отговаря за инсталацията, обслужването и демонтажа на сървъри. Получавайки тикет, инженерът започва работа. В дисковите клетки той самостоятелно сменя дисковете. Но ако няма достъп до нужното устройство, инженерът се обръща към дежурните системни администратори за помощ. Първо е необходимо да се изключи диска от ротацията. За целта са необходими промени на сървера, спиране на приложенията и демонтиране на диска.

Дежурният системен администратор по време на работната смяна отговаря за функционирането на целия портал. Той разследва инциденти, извършва ремонти и помага на разработчиците с по-малки задачи. Не се занимава само с твърдите дискове.

По-рано инженерите на центровете за данни общуваха с системния администратор в чата. Инженерите пращаха линкове към тикети в Jira, администраторът минаваше през тях и водеше лог на работата в някакъв бележник. Но за такива задачи чатът не е удобен: информацията там не е структурирана и бързо се губи. А и администраторът можеше просто да се отдалечи от компютъра и да не отговаря на запитванията, докато инженерът стоеше до сървъра с куп диск и чакаше.

Но най-лошото беше, че администраторите не виждаха картината в цялост: какви дискови инциденти съществуват и къде потенциално може да възникне проблем. Това е свързано с факта, че всички HW-инциденти предаваме на инженерите. Да, можеше да се визуализират всички инциденти на дашборда на администратора, но те са твърде много и администраторът се включваше само при някои от тях.

Освен това инженерът не можеше да зададе приоритети коректно, защото не знаеше нищо за предназначението на конкретните сървъри и разпределението на информацията по носителите.

Нова процедура за замяна

Първото, което направихме, беше да изведем всички дискови инциденти в отделен тип "HW-диск" и да добавим полета "име на блочно устройство", "размер" и "тип диск", за да се запази тази информация в тикета и да не е необходимо да я обменяме постоянно в чата.

Също така се договорихме, че в рамките на един инцидент ще сменяме само един диск. Това значително опрости по-късно процеса на автоматизация, събиране на статистика и работа.

В допълнение добавихме поле "отговорен администратор". Там автоматично се вписва дежурният системен администратор. Това е много удобно, защото сега инженерът винаги вижда кой е отговорният. Не е необходимо да се отива в календара и да се търси. Именно това поле позволи да изведем на дашборда на администратора тикетите, в които вероятно ще е необходима помощта му.

За да получат всички участници максимални ползи от нововъведенията, създадохме филтри и табла за управление и информирахме колегите за тях. Когато хората разбират промените, не се дистанцират от тях, както от нещо ненужно. Инженерът е важно да знае номера на рафта, където се намира сървърът, размера и типа на диска. Администратору му е необходимо, преди всичко, да разбере каква е групата сървъри и какъв може да бъде ефектът от подмяната на диска.

Наличието на полета и тяхното показване е удобно, но не ни освободи от необходимостта да използваме чатовете. За това се наложи да променим работния процес.

Преди това работеше така:

Днес инженери все още работят по такъв начин, когато не им е нужна помощ от администратора.

Първото, което направихме, е да въведем нов статус Investigate. В този статус тикетът остава, когато инженерът все още не е решил дали има нужда от администратор или не. През този статус инженерът може да предаде тикета на администратора. Освен това с този статус маркираме тикетите, когато е необходима подмяна на диска, но самият диск не е наличен на площадката. Това се случва при CDN и отдалечени площадки.

Също така добавихме статус Готово. Тикетът преминава в него след подмяна на диска. Тоест всичко вече е направено, но на сървъра синхронизирано HW/SW RAID. Това може да отнеме доста време.

Ако администратора е привлечен за работа, схемата малко се усложнява.

От статус Open тикетът може да бъде преместен от системен администратор или инженер. В статус In progress администраторът извежда диска от ротация, за да може инженерът да го изтегли: включва подсветката, демонтира диска, спира приложенията, в зависимост от конкретната група сървъри.

След това тикетът се премества в Ready to change: това е сигнал за инженера, че диска може да бъде изваден. Всички полета в Jira вече са попълнени, инженерът знае какъв тип и размер е диска. Тези данни се въвеждат или автоматично на предходния статус, или от администратора.

След подмяната на диска тикетът се премества в статус Changed. Проверява се, че е поставен нужния диск, прави се разметка, стартира се приложението и се извършват задачи по възстановяване на данни. Също така тикетът може да бъде преместен в статус Готово, в този случай отговорността остава на администратора, защото той е въвел диска в ротация. Цялата схема изглежда така.

Добавянето на нови полета значително улесни живота ни. Ребята започнаха да работят със структурирана информация, стана ясно какво и на кой етап трябва да се направи. Приоритетите станаха много по-релевантни, тъй като сега ги поставя администраторът.

Не е необходимо да разговаряме в чатовете. Разбира се, администраторът може да напише на инженера "тук трябва да замениш по-бързо" или "вече е вечер, ще успееш ли да замениш?". Но вече не се комуникираме ежедневно в чатовете по тези въпроси.

Дисковете започнаха да се заменят на партиди. Ако администраторът дойде на работа малко по-рано, има свободно време и още нищо не се е случило, той може да подготви редица сървъри за замяна: да постави полета, да изключи дисковете от ротация и да предаде задачата на инженера. Инженерът идва малко по-късно в дата центъра, вижда задачата, взима нужните дискове от склада и веднага ги заменя. В резултат скоростта на замяна се увеличи.

Изнесен опит при изграждане на Workflow

• При изграждането на процедурата е необходимо да се събира информация от различни източници.
  Някои от нашите администратори не знаеха, че инженерът самостоятелно сменя дисковете. Някои от тях смятаха, че за синхронизацията на MD RAID следят инженерите, докато някои от тях дори нямат достъп за това. Някои водещи инженери го правят, но не винаги, защото процесът не е описан никъде.
• Процедурата трябва да бъде проста и ясна.
  Човекът има трудност да запомни много стъпки. Най-важните съседни статуси в Jira трябва да бъдат изнесени на главния екран. Могат да бъдат преименувани, например, "In progress" го наричаме "Готов за смяна". А останалите статуси могат да бъдат скрити в падащо меню, за да не дразнят очите. Но е по-добре да не ограничавате хората, а да им дадете възможност да направят преход.
  Изяснявайте стойността на нововъведенията. Когато хората разбират, те по-добре приемат новата процедура. За нас беше много важно хората да не кликват само на целия процес, а да минат през него. След това изграждахме автоматизация на базата на това.
• Чакайте, анализирайте, разбирайте.
  Отне ни месец за разработка на процедурата, техническа реализация, срещи и обсъждания. А за внедряване — повече от три месеца. Видях как хората постепенно започват да ползват нововъведението. На първите етапи имаше много негативизъм. Но той въобще не зависеше от самата процедура, и нейна техническа реализация. Например, един администратор ползваше не Jira, а Jira плъгин в Confluence, и някои неща не му бяха достъпни. Показахме му Jira, при администратора нарасна продуктивността както по общите задачи, така и по замяна на дискове.

Автоматизация на замяната на дискове

Към автоматизацията на замяната на дискове подхождахме няколко пъти. Вече сме имали разработки, скриптове, но всички те работеха или в интерактивен, или в ръчен режим, и изискваха стартиране. И едва след внедряването на новата процедура разбрахме, че точно нея ни липсваше.

Тъй като сега процесът на замяна е разбит на етапи, с определен изпълнител и списък действия за всеки от тях, можем да включваме автоматизацията поетапно, а не наведнъж. Например, най-простият етап — Ready (проверка за синхронизация на RAID/данни) може лесно да бъде делегиран на бот. Когато ботът се обучи малко, можем да му дадем по-отговорна задача — въвеждане на диска в ротация и т.н.

Зоопарк от сетапи

Преди да разкажа за бота, ще направим малък екскурс в нашия зоопарк от инсталации. В първоначален ред той е обусловен от гигантския размер на нашата инфраструктура. На второ място, за всяка услуга се опитваме да подберем оптимална конфигурация на хардуера. Имаме около 20 модели хардуерни RAID, основно LSI и Adaptec, но се срещат и HP и DELL от различни версии. Всеки RAID контролер има своя утилита за управление. Наборът команди и резултатите от тях могат да се различават от версия на версия за всеки RAID контролер. Там, където не се използват HW-RAID, може да бъде mdraid.

Почти всички нови инсталации правим без дисково резервиране. Опитваме се вече да не използваме хардуерни и софтуерни RAID, тъй като резервираме нашите системи на ниво дата-центрове, а не на ниво сървъри. Но разбира се има много legacy-сървъри, които трябва да поддържаме.

Някои дискове в RAID контролери се подават като raw устройства, а на други места се използва JBOD. Има конфигурации с един системен диск в сървъра, и ако трябва да бъде заменен, се налага да се преинсталира сървъра с операционната система и приложенията, включително същите версии, след което да се добавят конфигурационни файлове и да се стартират приложения. Съществуват много групи сървъри, при които резервирането не се извършва на ниво дискова подсистема, а непосредствено в самите приложения.

Общо имаме над 400 уникални групи сървъри, на които работят около 100 различни приложения. За да обхванем това огромно количество опции, ни беше необходим многофункционален инструмент за автоматизация. Предпочитано с прост DSL, за да може да го поддържа не само този, който го е написал.

Избрахме Ansible, защото е без клиент: не се налагаше да подготвяме инфраструктура, бързо стартиране. Освен това е написан на Python, който е приет за стандарт в екипа.

Общая схема

Нека да разгледаме общата схема на автоматизация на примера на един инцидент. Zabbix открива, че диск sdb е повреден, задейства се тригер, създава се тикет в Jira. Администраторът го преглежда, разбира, че не е дубликат и не е false positive, т.е. необходимо е да се смени диска, и превежда тикета в In progress.

Приложението DiskoBot, написано на Python, периодично проверява Jira за нови тикети. То забелязва, че е имало нов тикет In progress, задейства се съответният поток, който стартира playbook в Ansible (това се прави за всеки статус в Jira). В този случай се стартира Prepare2change.

Ansible се изпраща на хоста, извежда диска от ротация и докладва статуса на приложението чрез Callbacks.

В резултат на това ботът автоматично прехвърля тикета в Ready to change. Инженерът получава уведомление и се отправя да смени диска, след което прехвърля тикета в Changed.

По описаната схема тикетът отново попада при бота, който стартира друг playbook, отива на хоста и въвежда диска в ротация. Ботът затваря тикета. Ура!

Сега нека поговорим за някои компоненти на системата.

Diskobot

Това приложение е написано на Python. То избира тикети от Jira в съответствие с JQL. В зависимост от статуса на тикета, последният попада при съответния обработчик, който от своя страна стартира съответния Ansible playbook, свързан с текущия статус.

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

Например, сред тикетите в статус In progress, се избират само тези, при които полетата Disk size и Device name са попълнени. Device name е името на блоковото устройство, необходимо за изпълнение на playbook’а. Disk size е нужен за инженерите, за да знаят какъв размер диск е необходим.

А сред тикетите със статус Ready се филтрират тикетите с етикет dbot_ignore. Между другото, в Jira етикетите използваме както за подобна филтрация, така и за маркиране на дубликати на тикети и събиране на статистика.

В случай на неуспех на playbook’а, Jira присвоява етикет dbot_failed, за да може по-късно да се разгледа.

Взаимодействие с Ansible

Приложението взаимодейства с Ansible чрез Ansible Python API. В playbook_executor предаваме името на файла и набор от променливи. Това позволява да запазим Ansible проекта под формата на обикновени yml файлове, а не да го описваме в Python код.

Също така в Ansible чрез *extra_vars* се предават името на блоковото устройство, статусът на тикета, както и callback_url, в който е вграденият ключ на проблема — той се използва за callback в HTTP.

За всяко изпълнение се генерира временен inventory, състоящ се от един хост и група, в която влиза този хост, за да се приложат group_vars.

Ето пример за задача, в която е реализиран HTTP callback.

Резултатите от изпълнението на playbook’ите получаваме чрез callback(-ове). Те са от два типа:

• Ansible callback plugin, предоставящ данни за резултатите от изпълнението на playbook’а. Там са описани задачите, които са били стартирани, успешно или неуспешно изпълнени. Този callback се извиква в края на изпълнението на playbook’а.
• HTTP callback за получаване на информация по време на изпълнението на playbook’а. В Ansible задачата извършва POST/GET заявка към нашето приложение.

Чрез HTTP callback(-и) се предават променливите, които са определени по време на изпълнението на playbook’а и които искаме да запазим и използваме при последващи пускания. Тези данни записваме в sqlite.

Също така чрез HTTP callback оставяме коментари и променяме статуса на тикета.

HTTP callback

# 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

Как и много други подобни задачи, ние го изнесохме в отделен общ файл и го включваме при необходимост, за да не повтаряме постоянно в playbooks. Тук фигурира callback_url, в който са вградени issue key и host name. Когато 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 — дамп на партицията от parted.

Когато инженерът постави нов диск, ще можем да използваме тези променливи, за да възстановим дампа на партициите, както и да регистрираме диска в същите md-устройства, от които е бил премахнат.

Ansible режим на проверка

Включването на автоматизацията беше страшно. Затова решихме да стартираме всичките playbook в режим
dry run, в който Ansible не извършва действия на сървърите, а само ги еймулира.

Този стартиращ режим преминава през отделен callback модул, а резултатът от изпълнението на playbook-а се запазва в Jira под формата на коментар.

Първо, това позволи да валидинираме работата на бота и playbook-ите. Второ, повиши доверието на администраторите към бота.

Когато минахме валидиране и разбрахме, че можем да стартираме Ansible не само в режим dry run, добавихме в Jira бутон Run Diskobot за стартиране на същия playbook с едни и същи променливи на същия хост, но в обикновен режим.

Освен това, бутонът се използва за повторно стартиране на playbook-а в случай на негов провал.

Структура на Playbooks

Вече споменах, че в зависимост от статуса на Jira тикета, ботът стартира различни playbook-и.

Първо, така много по-лесно се организира входът.
Второ, в някои случаи това е просто необходимо.

Например, при смяна на системния диск, трябва първо да отидем в системата за разгръщане, да създадем задача, и след успешното разгръщане сървърът ще стане достъпен по ssh, и можем да инсталираме приложението. Ако правехме всичко това в един playbook, Ansible нямаше да може да го изпълни заради недостъпността на хоста.

Използваме Ansible роли за всяка група сървъри. Тук се вижда как са организирани playbook-ите в една от тях.

Това е удобно, защото веднага е ясно къде какви задачи са разположени. В main.yml, който е входен файл за Ansible ролята, можем просто да включим извикване по статуса на тикета или общи задачи, необходими за всички, например, преминаване на идентификация или получаване на токен.

Investigation.yml

Стартира се за тикети в статус Investigation и Open. Най-важното за този playbook е името на блочното устройство. Тази информация не винаги е налична.

За да я получим, анализираме резюмето в Jira, последната стойност от Zabbix тригера. Там може да е посочено името на блочното устройство — може да имаме късмет. Или може да съдържа точката на монтиране, — в такъв случай трябва да отидем на сървъра, да я парснем и да изчислим нужния диск. Тригерът също може да предаде SCSI адрес или друга информация. Но понякога няма улики и се налага да анализираме.

След като разберем името на блочното устройство, събираме информация за типа и размера на диска, за да запълним полетата в Jira. Също така извличаме информация за производителя, модела, фърмуера, ID, SMART, и всичко това го вмъкваме в коментара в Jira тикета. Администраторът и инженерът вече не трябва да търсят тези данни. 🙂

prepare2change.yml

Изваждане на диска от ротация, подготовка за замяна. Най-сложният, отговорен етап. Тук може да спрем приложението, когато не бива да се спира. Или да извадим диск, на който не достигат реплики, и така да повлияем на потребителите, да загубим данни. Тук имаме най-много проверки и известия в чата.

В най-простия случай става въпрос за изтегляне на диска от HW/MD RAID.

В по-сложни ситуации (в нашите системи за съхранение), когато резервирането се извършва на ниво приложение, трябва да отидем в приложението по API, да съобщим за изваждането на диска, да го деактивираме и да инициираме възстановяването.

В момента масово мигрираме в облак, и ако сървърът е облачен, то Diskobot се обръща към API на облака, казва, че ще работи с този миньон — сървър, на който са стартирани контейнерите — и моли 'мигрирай всички контейнери от този миньон'. И се включва подсветката на диска, за да може инженерът веднага да види кой трябва да изважда.

changed.yml

След замяната на диска първо проверяваме неговата наличност.

Инженерите не винаги поставят нови дискове, затова добавихме проверка за удовлетворяващи ни стойности SMART.

Кои атрибути разглеждамеБрой на преразпределените сектора (5) < 100
Брой на текущите изчакващи сектори (107) == 0

Ако дискът не премине проверка, инженерът ще бъде информиран за необходимостта от повторна смяна. Ако всичко е наред, осветлението изгасва, нанася се маркировка и дискът се въвежда в ротация.

ready.yml

Най-простият случай: проверка на синхронизацията на HW/SW raid или приключване на синхронизацията на данните в приложението.

API на приложенията

Няколко пъти споменавам, че често ботът се обръща към API на приложенията. Разбира се, не всички приложения разполагаха с необходимите методи, затова трябваше да ги доразвием. Ето най-важните методи, които използваме:

• Status. Статус на клъстера или диска, за да разберем дали можем да работим с него;
• Start/stop. Активиране-деактивиране на диска;
• Migrate/restore. Миграция и възстановяване на данни по време и след замяна.

Извлечен опит от Ansible

Много обичам Ansible. Но често, когато гледам различни opensource проекти и виждам как хората пишат playbook-и, ми става леко страшно. Сложни логически заплитания от when/loop, липса на гъвкавост и идемпотентност поради често използване на shell/command.

Решихме да опростим максимално всичко, като се възползвахме от предимствата на Ansible — модулността. На най-високо ниво са playbook-ите, които може да пише всеки администратор, външен разработчик, който малко разбира от Ansible.

- 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 са простотата и разбираемите playbook-и. Считам, че трябва да се използват и да не се генерират страшни yaml-файлове и огромно количество условия, shell код и цикли.

Ако решите да повторите нашия опит с Ansible API, имайте предвид две неща:

• Playbook_executor и самият playbook не могат да получат таймаут. Има таймаут за ssh-сесии, но няма таймаут за playbook. Ако се опитаме да отмонтираме диск, който вече не съществува в системата, playbook ще се изпълнява безкрайно, затова трябваше да обвием неговото стартиране в отделен wrapper и да го убиваме по таймаут.
• Ansible работи на базата на fork-процеси, затова неговото API не е потокобезопасно. Изпълняваме всичките ни playbook-ове еднопоточно.

В крайна сметка успяхме да автоматизираме замената на около 80 % от дисковете. Общо взето, скоростта на замяна се увеличи два пъти. Днес администраторът само наблюдава инцидента и взема решение дали да замени диска или не, а след това прави един клик.

Но сега започваме да се сблъскваме с друг проблем: някои нови администратори не знаят как да сменят дисковете. 🙂

Източник: habr.com