Аутоматизација замене диска помоћу Ансибле-а

Здраво свима. Радим као водећи систем администратор у ОК и одговоран сам за стабилан рад портала. Желим да причам о томе како смо направили процес за аутоматску замену дискова, а затим како смо искључили администратора из овог процеса и заменили га ботом.

Овај чланак је нека врста транслитерације представе на ХигхЛоад+ 2018

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

Прво неколико бројева

ОК је огромна услуга коју користе милиони људи. Опслужује га око 7 хиљада сервера, који се налазе у 4 различита дата центра. Сервери садрже више од 70 хиљада дискова. Ако их сложите једну на другу, добијате торањ висок више од 1 км.

Чврсти дискови су компонента сервера која најчешће квари. Са оваквим волуменима морамо да мењамо око 30 дискова недељно, а ова процедура је постала не баш пријатна рутина.

Инциденти

Наша компанија је увела потпуно управљање инцидентима. Сваки инцидент снимамо у Ћира, а затим га решавамо и решавамо. Ако је неки инцидент утицао на кориснике, онда се свакако окупљамо и размишљамо како да брже реагујемо у таквим случајевима, како да смањимо ефекат и, наравно, како да спречимо да се понови.

Уређаји за складиштење нису изузетак. Њихов статус прати Заббик. Пратимо поруке у Сислог-у ради грешака у писању/читању, анализирамо статус ХВ/СВ напада, пратимо СМАРТ и израчунавамо хабање ССД-ова.

Како су дискови мењани раније

Када се окидач догоди у Заббик-у, инцидент се креира у Јира и аутоматски се додељује одговарајућим инжењерима у центрима података. То радимо са свим ХВ инцидентима, односно онима који захтевају било какав физички рад са опремом у дата центру.
Инжењер центра података је особа која решава проблеме везане за хардвер и одговорна је за инсталирање, одржавање и демонтажу сервера. Након што је добио карту, инжењер прелази на посао. На полицама дискова мења дискове независно. Али ако нема приступ потребном уређају, инжењер се за помоћ обраћа дежурним систем администраторима. Пре свега, морате уклонити диск из ротације. Да бисте то урадили, потребно је да извршите неопходне промене на серверу, зауставите апликације и искључите диск.

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

Раније су инжењери дата центара комуницирали са администратором система путем ћаскања. Инжењери су слали линкове на Јира тикете, администратор их је пратио, водио евиденцију рада у неком нотепаду. Али ћаскање је незгодно за такве задатке: информације тамо нису структуриране и брзо се губе. А администратор је могао једноставно да оде од рачунара и неко време не одговара на захтеве, док је инжењер стајао на серверу са гомилом дискова и чекао.

Али најгоре је било то што администратори нису видели целу слику: какви су инциденти на диску постојали, где би потенцијално могао настати проблем. То је због чињенице да ми делегирамо све ХВ инциденте на инжењере. Да, било је могуће приказати све инциденте на администраторској контролној табли. Али има их много, а администратор је био укључен само за неке од њих.

Осим тога, инжењер није могао правилно да постави приоритете, јер не зна ништа о сврси одређених сервера или дистрибуцији информација међу дисковима.

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

Прво што смо урадили је да смо све инциденте на диску преместили у посебан тип „ХВ диск“ и додали поља „име уређаја“, „величина“ и „тип диска“ како би ове информације биле сачуване у тикету и не морате стално да размењујете у ћаскању.

Такође смо се договорили да током једног инцидента променимо само један диск. Ово је значајно поједноставило процес аутоматизације, прикупљање статистике и рад у будућности.

Поред тога, додали смо поље „одговорни администратор“. Ту се аутоматски убацује дежурни систем администратор. Ово је веома згодно, јер сада инжењер увек види ко је одговоран. Нема потребе да идете у календар и тражите. Управо ово поље је омогућило приказивање тикета на администраторској контролној табли којима је можда потребна његова помоћ.

Да бисмо осигурали да сви учесници имају максималну корист од иновација, направили смо филтере и контролне табле и рекли момцима о њима. Када људи схвате промене, не дистанцирају се од њих као од нечег непотребног. За инжењера је важно да зна број сталка где се сервер налази, величину и тип диска. Администратор треба, пре свега, да разуме о каквој се групи сервера ради и какав би ефекат могао бити при замени диска.

Присуство поља и њихов приказ је згодно, али нас није спасило потребе да користимо ћаскање. Да бисмо то урадили, морали смо да променимо ток рада.

Раније је било овако:

Овако инжењери настављају да раде и данас када им није потребна помоћ администратора.

Прво што смо урадили је увођење новог статуса Истражити. Карта је у овом статусу када инжењер још није одлучио да ли ће му требати администратор или не. Преко овог статуса, инжењер може да пренесе карту администратору. Поред тога, користимо овај статус да означимо тикете када диск треба да се замени, али сам диск није на лицу места. Ово се дешава у случају ЦДН-ова и удаљених локација.

Додали смо и статус Спреман. Карта се на њега преноси након замене диска. То јест, све је већ урађено, али је ХВ/СВ РАИД синхронизован на серверу. Ово може потрајати доста времена.

Ако је администратор укључен у рад, шема постаје мало компликованија.

Од статуса отворен Улазницу могу превести и администратор система и инжењер. У статусу У току администратор уклања диск из ротације тако да инжењер може једноставно да га извуче: укључује позадинско осветљење, демонтира диск, зауставља апликације, у зависности од специфичне групе сервера.

Карта се затим преноси на Спремни за промену: Ово је сигнал инжењеру да се диск може извући. Сва поља у Јира су већ попуњена, инжењер зна који тип и величину диска. Ови подаци се уносе или аутоматски на претходном статусу или од стране администратора.

Након замене диска, статус тикета се мења у Цхангед. Проверава да ли је исправан диск уметнут, партиционисање је обављено, апликација се покреће и неки задаци опоравка података се покрећу. Карта се такође може пренети у статус Спреман, у овом случају администратор остаје одговоран, јер је ставио диск у ротацију. Комплетан дијаграм изгледа овако.

Додавање нових поља нам је учинило живот много лакшим. Момци су почели да раде са структурираним информацијама, постало је јасно шта треба да се уради и у којој фази. Приоритети су постали много релевантнији, јер их сада поставља администратор.

Нема потребе за разговорима. Наравно, администратор може да напише инжењеру „ово треба брже да се замени“ или „већ је вече, хоћете ли имати времена да га замените?“ Али више не комуницирамо свакодневно у разговорима о овим питањима.

Дискови су почели да се мењају у серијама. Ако је администратор дошао на посао мало раније, има слободног времена, а ништа се још није догодило, може припремити велики број сервера за замену: попунити поља, уклонити дискове из ротације и пренети задатак инжењеру. Инжењер долази у дата центар нешто касније, види задатак, узима потребне дискове из магацина и одмах их замењује. Као резултат тога, стопа замене је повећана.

Научене лекције приликом изградње тока рада

• Када конструишете процедуру, потребно је да прикупите информације из различитих извора.
  Неки од наших администратора нису знали да инжењер сам мења дискове. Неки људи су мислили да су МД РАИД синхронизацијом управљали инжењери, иако неки од њих нису ни имали приступ томе. Неки водећи инжењери су то радили, али не увек јер процес није нигде описан.
• Процедура треба да буде једноставна и разумљива.
  Човеку је тешко да задржи много корака на уму. Најважније суседне статусе у Јира треба поставити на главни екран. Можете их преименовати, на пример, зовемо У току Спреман за промену. И други статуси се могу сакрити у падајућем менију како не би били рана на оку. Али боље је не ограничавати људе, дати им прилику да направе транзицију.
  Објасните вредност иновације. Када људи разумеју, они више прихватају нову процедуру. Било нам је веома важно да људи не кликну кроз цео процес, већ да га прате. Онда смо на овоме изградили аутоматизацију.
• Сачекај, анализирај, схвати.
  Требало нам је око месец дана да изградимо процедуру, техничку имплементацију, састанке и дискусије. А имплементација траје више од три месеца. Видео сам како људи полако почињу да користе иновацију. Било је много негативности у раним фазама. Али то је било потпуно независно од самог поступка и његове техничке имплементације. На пример, један администратор није користио Јира, већ Јира додатак у Цонфлуенце-у и неке ствари му нису биле доступне. Показали смо му Јира, а продуктивност администратора је порасла и за опште задатке и за замену дискова.

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

Више пута смо приступали аутоматизацији замене дискова. Већ смо имали развоје и скрипте, али су сви радили или интерактивно или ручно и захтевали су покретање. И тек након увођења нове процедуре, схватили смо да је управо то оно што нам недостаје.

Пошто је сада наш процес замене подељен на фазе, од којих свака има одређеног извођача и списак радњи, можемо омогућити аутоматизацију у фазама, а не све одједном. На пример, најједноставнија фаза - Реади (провера РАИД/синхронизације података) може се лако делегирати боту. Када је бот мало научио, можете му дати важнији задатак - стављање диска у ротацију итд.

Зоо сетупс

Пре него што причамо о боту, хајде да кренемо на кратак излет у наш зоолошки врт са инсталацијама. Пре свега, то је због гигантске величине наше инфраструктуре. Друго, трудимо се да изаберемо оптималну конфигурацију хардвера за сваку услугу. Имамо око 20 хардверских РАИД модела, углавном ЛСИ и Адаптец, али постоје и ХП и ДЕЛЛ различитих верзија. Сваки РАИД контролер има свој услужни програм за управљање. Скуп команди и њихово издавање могу се разликовати од верзије до верзије за сваки РАИД контролер. Тамо где се ХВ-РАИД не користи, може се користити мдраид.

Готово све нове инсталације радимо без резервне копије диска. Трудимо се да више не користимо хардверски и софтверски РАИД, јер правимо резервне копије наших система на нивоу дата центра, а не сервера. Али наравно постоји много старих сервера које треба подржати.

Негде се дискови у РАИД контролерима преносе на сирове уређаје, негде се користе ЈБОД-ови. У серверу постоје конфигурације са једним системским диском, а ако га треба заменити, онда морате поново инсталирати сервер са инсталацијом ОС-а и апликација, истих верзија, затим додати конфигурационе фајлове, покренути апликације. Такође постоји много група сервера у којима се резервна копија не врши на нивоу подсистема диска, већ директно у самим апликацијама.

Укупно имамо преко 400 јединствених група сервера које покрећу скоро 100 различитих апликација. Да бисмо покрили тако огроман број опција, био нам је потребан мултифункционални алат за аутоматизацију. По могућству са једноставним ДСЛ-ом, тако да га не подржава само особа која га је написала.

Изабрали смо Ансибле јер је без агента: није било потребе да се припрема инфраструктура, брз почетак. Поред тога, написан је на Питхон-у, који је прихваћен као стандард унутар тима.

Општа шема

Хајде да погледамо општу шему аутоматизације користећи један инцидент као пример. Заббик детектује да сдб диск није успео, окидач светли и тикет се креира у Јира. Администратор га је погледао, схватио да није дупликат и да није лажно позитивна, односно да је диск требало да се промени, и пребацио тикет у У току.

Апликација ДискоБот, написана на Питхон-у, периодично испитује Јира за нове карте. Примећује да се појавила нова улазница У току, покреће се одговарајућа нит, која покреће плаибоок у Ансибле-у (ово се ради за сваки статус у Јира). У овом случају се покреће Препаре2цханге.

Ансибле се шаље хосту, уклања диск из ротације и пријављује статус апликацији путем повратних позива.

На основу резултата, бот аутоматски преноси тикет у Реади то цханге. Инжењер добија обавештење и одлази да промени диск, након чега преноси тикет на Цхангед.

Према горе описаној шеми, тикет се враћа до бота, који покреће други плаибоок, иде до хоста и ставља диск у ротацију. Бот затвара тикет. Ура!

Хајде сада да причамо о неким компонентама система.

Дискобот

Ова апликација је написана у Питхон-у. Бира карте из Јира према ЈКЛ-у. У зависности од статуса тикета, овај други иде до одговарајућег руковаоца, који заузврат покреће Ансибле плаибоок који одговара статусу.

ЈКЛ и интервали анкетирања су дефинисани у конфигурационој датотеци апликације.

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

На пример, међу тикетима у статусу У току, изабране су само оне са попуњеним пољима Величина диска и Име уређаја. Име уређаја је име блок уређаја потребног за извршавање књиге. Величина диска је потребна да би инжењер знао која је величина диска потребна.

А међу тикетима са статусом Реади, тикете са ознаком дбот_игноре се филтрирају. Иначе, користимо Јира ознаке и за такво филтрирање и за обележавање дупликата тикета и прикупљање статистике.

Ако књига за игру не успе, Јира додељује ознаку дбот_фаилед тако да се може касније средити.

Интероперабилност са Ансибле-ом

Апликација комуницира са Ансибле-ом преко Ансибле Питхон АПИ. Плаибоок_екецутор-у преносимо име датотеке и скуп променљивих. Ово вам омогућава да задржите Ансибле пројекат у облику обичних имл датотека, уместо да га описујете у Питхон коду.

Такође у Ансибле-у, преко *ектра_варс*, имена блок уређаја, статуса тикета, као и цаллбацк_урл, који садржи кључ проблема - користи се за повратни позив у ХТТП-у.

За свако покретање генерише се привремени инвентар који се састоји од једног хоста и групе којој овај хост припада, тако да се примењују гроуп_варс.

Ево примера задатка који имплементира ХТТП повратни позив.

Добијамо резултат извршавања плаибоок-а користећи цаллабацк(е). Они су два типа:

• Ансибле додатак за повратни позив, даје податке о резултатима извођења плаибоок-а. Описује задатке који су покренути, успешно или неуспешно завршени. Овај повратни позив се позива када се плаибоок заврши са репродукцијом.
• ХТТП повратни позив за примање информација током репродукције књиге. У Ансибле задатку извршавамо ПОСТ/ГЕТ захтев за нашу апликацију.

Променљиве се прослеђују кроз ХТТП повратне позиве који су дефинисани током извршавања приручника и које желимо да сачувамо и користимо у наредним извршавањима. Ове податке записујемо у склиту.

Такође остављамо коментаре и мењамо статус тикета путем ХТТП повратног позива.

ХТТП повратни позив

# 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

Као и многе задатке истог типа, стављамо га у засебну заједничку датотеку и укључујемо ако је потребно, како се не бисмо стално понављали у књигама. Ово укључује цаллбацк_ урл, који садржи кључ проблема и име хоста. Када Ансибле изврши овај ПОСТ захтев, бот разуме да је он дошао као део тог и таквог инцидента.

А ево примера из плаибоок-а, у којем излазимо диск са МД уређаја:

  # 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

Овај задатак преноси Јира карту у статус „Спреман за промену“ и додаје коментар. Такође, променљива мдам_дата чува листу мд уређаја са којих је диск уклоњен, а партед_инфо чува испис партиције из партед.

Када инжењер убаци нови диск, можемо да користимо ове варијабле да вратимо думп партиције, као и да убацимо диск у мд уређаје са којих је уклоњен.

Ансибле режим провере

Било је страшно укључити аутоматизацију. Због тога смо одлучили да покренемо све приручнике у режиму
сува вожња, у којој Ансибле не врши никакве радње на серверима, већ их само емулира.

Такво покретање се покреће кроз посебан модул повратног позива, а резултат извршења плаибоок-а се чува у Јира као коментар.

Прво, ово је омогућило да се валидира рад бота и приручника. Друго, то је повећало поверење администратора у бот.

Када смо прошли проверу и схватили да Ансибле можете покренути не само у режиму рада на суво, направили смо дугме Покрени Дискобот у Јира-и да покренемо исти плаибоок са истим варијаблама на истом хосту, али у нормалном режиму.

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

Структура Плаибоокс

Већ сам поменуо да у зависности од статуса Јира тикета, бот покреће различите плаибоокс.

Прво, много је лакше организовати улаз.
Друго, у неким случајевима то је једноставно неопходно.

На пример, приликом замене системског диска, прво треба да одете у систем за имплементацију, креирате задатак, а након правилног постављања, сервер ће постати доступан преко ссх-а и на њега можете да покренете апликацију. Ако бисмо све ово урадили у једном плаибоок-у, онда Ансибле не би могао да га заврши због недоступности хоста.

Користимо Ансибле улоге за сваку групу сервера. Овде можете видети како су свеске(е) организоване у једној од њих.

Ово је згодно јер је одмах јасно где се који задаци налазе. У маин.имл, који је улаз за улогу Ансибле, можемо једноставно укључити статус тикета или опште задатке који су потребни за свакога, на пример, пролазак идентификације или примање токена.

Инвестигатион.имл

Трчи за улазнице у статусу Истрага и Отворено. Најважнија ствар за ову књигу је назив блок уређаја. Ове информације нису увек доступне.

Да бисмо га добили, анализирамо Јира сажетак, последњу вредност из Заббик окидача. Може да садржи назив блок уређаја - срећан. Или може да садржи тачку монтирања, онда треба да одете на сервер, да га рашчланите и израчунате потребан диск. Окидач такође може пренети сцси адресу или неке друге информације. Али такође се дешава да нема трагова, и морате анализирати.

Након што смо сазнали име блок уређаја, са њега прикупљамо информације о врсти и величини диска да бисмо попунили поља у Јира. Такође уклањамо информације о продавцу, моделу, фирмверу, ИД-у, СМАРТ-у и све ово убацујемо у коментар у Јира тикету. Администратор и инжењер више не морају да траже ове податке. 🙂

реади2цханге.имл

Уклањање диска из ротације, припрема за замену. Најтежа и најважнија фаза. Овде можете зауставити апликацију када је не треба зауставити. Или извадите диск који није имао довољно реплика и тиме утиче на кориснике, губећи неке податке. Овде имамо највише провера и обавештења у ћаскању.

У најједноставнијем случају, говоримо о уклањању диска из ХВ/МД РАИД-а.

У сложенијим ситуацијама (у нашим системима складиштења), када се резервна копија врши на нивоу апликације, потребно је да преко АПИ-ја одете до апликације, пријавите излаз диска, деактивирате га и започнете опоравак.

Сада масовно мигрирамо у облак, а ако је сервер заснован на облаку, онда Дискобот позива АПИ облака, каже да ће радити са овим минијоном – сервером који покреће контејнере – и тражи „мигрира све контејнере из овог миниона“. И истовремено укључује позадинско осветљење диска тако да инжењер може одмах да види који од њих треба да се извуче.

промењено.имл

Након замене диска, прво проверавамо његову доступност.

Инжењери не инсталирају увек нове диск јединице, па смо додали проверу за СМАРТ вредности које нас задовољавају.

Које атрибуте гледамо?Број прераспоређених сектора (5) < 100
Тренутни број сектора на чекању (107) == 0

Ако диск не прође тест, инжењер се обавештава да га поново замени. Ако је све у реду, позадинско осветљење се искључује, постављају се ознаке и диск се ставља у ротацију.

спреман.имл

Најједноставнији случај: провера ХВ/СВ раид синхронизације или завршетак синхронизације података у апликацији.

АПИ апликације

Неколико пута сам поменуо да бот често приступа АПИ-јима апликација. Наравно, нису све апликације имале потребне методе, па су морале бити модификоване. Ево најважнијих метода које користимо:

• Статус. Статус кластера или диска да би се разумело да ли се са њим може радити;
• Старт Стоп. Активација/деактивација диска;
• Мигрирајте/вратите. Миграција података и опоравак током и након замене.

Лекције научене од Ансибле-а

Заиста волим Ансибле. Али често, када погледам различите пројекте отвореног кода и видим како људи пишу књиге, мало се уплашим. Сложена логичка преплитања када/петље, недостатак флексибилности и идемпотенције због честе употребе љуске/команде.

Одлучили смо да поједноставимо све што је више могуће, користећи предност Ансибле-а - модуларност. На највишем нивоу постоје плаибоокс; може их написати било који администратор, програмер треће стране који мало познаје Ансибле.

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

Ако је неку логику тешко имплементирати у плаибоокс, премештамо је у Ансибле модул или филтер. Скрипте могу бити написане на Питхон-у или било ком другом језику.

Лако и брзо се пишу. На пример, модул позадинског осветљења диска, чији је пример приказан изнад, састоји се од 265 линија.

На најнижем нивоу је библиотека. За овај пројекат смо написали посебну апликацију, неку врсту апстракције преко хардверских и софтверских РАИД-ова који извршавају одговарајуће захтеве.

Највеће предности Ансибле-а су његова једноставност и јасна упутства. Верујем да ово треба да користите и да не генеришете страшне иамл датотеке и огроман број услова, схелл кода и петљи.

Ако желите да поновите наше искуство са Ансибле АПИ-јем, имајте на уму две ствари:

• Плаибоок_екецутор и плаибоокс уопште не могу да добију временско ограничење. Постоји временско ограничење на ссх сесији, али нема временско ограничење на плаибоок-у. Ако покушамо да искључимо диск који више не постоји у систему, плаибоок ће радити бесконачно, тако да смо морали да умотамо његово покретање у посебан омот и да га убијемо тимеоутом.
• Ансибле ради на форкираним процесима, тако да његов АПИ није сигуран нити. Покрећемо све наше приручнике у једном нити.

Као резултат тога, успели смо да аутоматизујемо замену око 80% дискова. Све у свему, стопа замене се удвостручила. Данас администратор само погледа инцидент и одлучи да ли треба променити диск или не, а затим направи један клик.

Али сада почињемо да наилазимо на још један проблем: неки нови администратори не знају како да промене дискове. 🙂

Извор: ввв.хабр.цом