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

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

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

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

Първо малко числа

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

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

Инциденти

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

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

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

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

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

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

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

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

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

Първото нещо, което направихме, беше да преместим всички дискови инциденти в отделен тип „HW disk“ и да добавим полетата „block device name“, „size“ и „disk type“ към него, така че тази информация да се записва в билета и да не трябва постоянно да чатите.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Научен опит при изграждане на работен процес

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

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

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

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

Зоопарк за настройка

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

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

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

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

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

Обща схема

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

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

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

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

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

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

Дискобот

Това приложение е написано на 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

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

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

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

Оперативна съвместимост с Ansible

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

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

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

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

Получаваме резултата от изпълнението на книгата с помощта на callaback(s). Те биват два вида:

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

Чрез обратното извикване(я) на HTTP се предават променливи, които са дефинирани по време на изпълнението на книгата за игра и които искаме да запазим и използваме при следващи изпълнения. Ние записваме тези данни в 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_ url, в който проблемният ключ и името на хоста са защитени. Когато Ansible изпълни тази POST заявка, ботът разбира, че тя е дошла като част от такъв или такъв инцидент.

И ето пример от книга-игра, в която извадихме диск от MD устройство:

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

Тази задача променя състоянието на тикета на Jira на „Готов за промяна“ и добавя коментар. Променливата mdam_data също съдържа списък с md устройства, от които е премахнат дискът, а parted_info съдържа дъмп на дял от parted.

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

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

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

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

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

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

Освен това бутонът се използва за рестартиране на книгата, ако се срине.

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

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

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

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

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

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

Разследване.yml

Пуснат за билети в статуси Разследване и Отворено. Най-важното нещо за тази книга е името на блоковото устройство. Тази информация не винаги е достъпна.

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

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

подготви2change.yml

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

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

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

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

променен.yml

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

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

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

Ако устройството не премине теста, на инженера се казва да го замени отново. Ако всичко е наред, подсветката се изключва, нанасят се маркировки и дискът се върти.

готов.yml

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

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

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

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

Рендиран опит от Ansible

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

Решихме да опростим всичко възможно най-много, възползвайки се от предимството на 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 модул или филтър. Скриптовете могат да бъдат написани на Python или на друг език.

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

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

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

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

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

В резултат на това успяхме да автоматизираме подмяната на около 80% от дисковете. Като цяло процентът на заместване се е удвоил. Днес администраторът само гледа инцидента и решава дали да смени диска или не, след което прави едно кликване.

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

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