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

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

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

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

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

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

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

Инциденти

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

Накопителите не са изключение. За тяхното състояние следи Zabbix. Мониторим съобщенията в Syslog за грешки при запис/четене, анализираме състоянието на HW/SW-ревейдите, следим 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 го наричаме Ready to change. А останалите статуси можем да скрием в падащо меню, за да не дразнят окото. Но по-добре е да не ограничаваме хората, да им дадем възможност да направят прехода.
  Обяснявайте стойността на нововъведенията. Когато хората разбират, те по-добре приемат новата процедура. За нас беше много важно хората да не кликат на целия процес, а да преминават през него. После изградихме автоматизация на базата на това.
• Да се изчаква, да се анализира, да се разбира.
  Ние отделихме около месец за изграждането на процедурата, техническата реализация, срещи и обсъждания. А за внедряването - повече от три месеца. Видях как хората постепенно започнаха да ползват нововъведението. В началните етапи имаше много негативизъм. Но той не зависеше изобщо от самата процедура, нито от техническата й реализация. Например, един администратор използваше не Jira, а Jira-плъгин в Confluence, и някои неща му бяха недостъпни. Показахме му Jira, продуктивността на администратора се увеличи както по общите задачи, така и по подмяната на дискове.

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

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

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

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

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

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

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

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

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

Общата схема

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

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

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

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

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

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

Diskobot

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

JQL и интервалите за запитване са определени в конфигурационния файл на приложението.

jira_states:
  investigate:
    jql: '… статус = Open и "Disk Size" е EMPTY'
    interval: 180

  inprogress:
    jql: '…  и "Disk Size" не е EMPTY и "Device Name" не е EMPTY'
 
  ready:
    jql: '… и (labels не са в ("dbot_ignore") или labels е 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, в който е вграден issue key — той се използва за 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

Както и много сходни задачи, ние я преместихме в отделен общ файл и я включваме при необходимост, за да не я повтаряме постоянно в playbook-ите. Тук фигурира 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

Тази задача променя статусa на 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 ролята, може просто да имаме include по статус на тикета или общи задачи, нужни за всички, например, преминаване през идентификация или получаване на токен.

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