Sjálfvirk skipting á diskum með Ansible

Hæ allir. Ég starfa sem leiðandi kerfisstjóri hjá OK og ber ábyrgð á stöðugum rekstri gáttarinnar. Mig langar að tala um hvernig við smíðuðum ferli til að skipta um diska sjálfkrafa og síðan hvernig við útilokuðum stjórnandann frá þessu ferli og skiptum honum út fyrir vélmenni.

Þessi grein er eins konar umritun sýningar á HighLoad+ 2018

Að byggja upp diskaskiptaferli

Fyrst nokkrar tölur

OK er risastór þjónusta sem milljónir manna nota. Það er þjónað af um 7 þúsund netþjónum, sem eru staðsettir í 4 mismunandi gagnaverum. Netþjónarnir innihalda meira en 70 þúsund diska. Ef þú staflar þeim hver ofan á annan færðu meira en 1 km háan turn.

Harðir diskar eru sá miðlarahluti sem bilar oftast. Með slíku magni þurfum við að skipta um 30 diska á viku og þessi aðferð er orðin ekki mjög skemmtileg venja.

Atvik

Fyrirtækið okkar hefur tekið upp fullgilda atvikastjórnun. Við skráum hvert atvik í Jira og leysum það síðan og leysum það. Ef atvik hafði áhrif á notendur þá komum við örugglega saman og hugsum um hvernig hægt sé að bregðast hraðar við í slíkum tilfellum, hvernig megi draga úr áhrifum og að sjálfsögðu hvernig eigi að koma í veg fyrir að það endurtaki sig.

Geymslutæki eru engin undantekning. Staða þeirra er fylgst með af Zabbix. Við fylgjumst með skilaboðum í Syslog fyrir skrif-/lesvillur, greinum stöðu HW/SW árása, fylgjumst með SMART og reiknum út slit fyrir SSD.

Hvernig diskum var breytt áður

Þegar kveikja á sér stað í Zabbix er atvik búið til í Jira og sjálfkrafa úthlutað til viðeigandi verkfræðinga í gagnaverunum. Við gerum þetta með öll HW atvik, það er þau sem krefjast líkamlegrar vinnu með búnaði í gagnaverinu.
Gagnaveraverkfræðingur er einstaklingur sem leysir mál sem tengjast vélbúnaði og ber ábyrgð á uppsetningu, viðhaldi og sundri netþjónum. Eftir að hafa fengið miðann fer vélstjórinn til starfa. Í diskahillum skiptir hann um diska sjálfstætt. En ef hann hefur ekki aðgang að tilskildu tæki, leitar verkfræðingurinn til kerfisstjóra á vakt um aðstoð. Fyrst af öllu þarftu að fjarlægja diskinn úr snúningi. Til að gera þetta þarftu að gera nauðsynlegar breytingar á þjóninum, stöðva forrit og aftengja diskinn.

Vakthafandi kerfisstjóri ber ábyrgð á rekstri allrar gáttarinnar á vinnuvaktinni. Hann rannsakar atvik, gerir viðgerðir og hjálpar hönnuðum að klára lítil verkefni. Hann fæst ekki eingöngu við harða diska.

Áður höfðu gagnaversverkfræðingar samskipti við kerfisstjórann í gegnum spjall. Verkfræðingar sendu tengla á Jira miða, stjórnandinn fylgdi þeim, hélt vinnudagbók í einhverju minnisblokk. En spjall er óþægilegt fyrir slík verkefni: upplýsingarnar þar eru ekki skipulagðar og glatast fljótt. Og stjórnandinn gat einfaldlega gengið í burtu frá tölvunni og ekki svarað beiðnum í einhvern tíma, á meðan verkfræðingurinn stóð við netþjóninn með stafla af diskum og beið.

En það versta var að stjórnendur sáu ekki heildarmyndina: hvaða diskatvik voru til, þar sem vandamál gætu hugsanlega komið upp. Þetta er vegna þess að við framseljum öll HW atvik til verkfræðinga. Já, það var hægt að birta öll atvik á mælaborði stjórnanda. En þeir eru margir og stjórnandinn tók aðeins þátt í sumum þeirra.

Auk þess gat verkfræðingur ekki forgangsraðað rétt, vegna þess að hann veit ekkert um tilgang tiltekinna netþjóna eða dreifingu upplýsinga á milli diska.

Ný afleysingaraðferð

Það fyrsta sem við gerðum var að færa öll diskatvik yfir á sérstaka tegund „HW diskur“ og bæta við reitunum „loka heiti tækis“, „stærð“ og „gerð disks“ til þess að þessar upplýsingar yrðu geymdar í miðanum og myndu ekki þurfa stöðugt að skiptast á spjalli.

Við komumst líka að því að við myndum aðeins skipta um einn disk í hvert atvik. Þetta einfaldaði verulega sjálfvirkniferlið, tölfræðisöfnun og vinnu í framtíðinni.

Að auki bættum við við reitnum „ábyrgur stjórnandi“. Þar er kerfisstjóri á vakt sjálfkrafa settur inn. Þetta er mjög þægilegt, því nú sér verkfræðingurinn alltaf hver ber ábyrgðina. Engin þörf á að fara í dagatalið og leita. Það var þessi reitur sem gerði það mögulegt að birta miða á mælaborði stjórnandans sem gæti þurft aðstoð hans.

Til að tryggja að allir þátttakendur fengju hámarks ávinning af nýjungum, bjuggum við til síur og mælaborð og sögðum strákunum frá þeim. Þegar fólk skilur breytingar fjarlægir það sig ekki frá þeim sem eitthvað óþarft. Það er mikilvægt fyrir verkfræðing að vita rekkinúmerið þar sem þjónninn er staðsettur, stærð og gerð disks. Stjórnandinn þarf fyrst og fremst að skilja hvers konar hóp netþjóna þetta er og hver áhrifin gætu verið þegar skipt er um disk.

Tilvist reita og birting þeirra er þægileg, en það bjargaði okkur ekki frá þörfinni á að nota spjall. Til að gera þetta þurftum við að breyta vinnuflæðinu.

Áður var þetta svona:

Svona halda verkfræðingar áfram að vinna í dag þegar þeir þurfa ekki aðstoð stjórnenda.

Það fyrsta sem við gerðum var að kynna nýja stöðu Rannsaka. Miðinn er í þessari stöðu þegar verkfræðingur hefur ekki enn ákveðið hvort hann þurfi stjórnanda eða ekki. Með þessari stöðu getur verkfræðingur flutt miðann til stjórnandans. Auk þess notum við þessa stöðu til að merkja miða þegar skipta þarf um disk en diskurinn sjálfur er ekki á staðnum. Þetta gerist þegar um er að ræða CDN og fjarlægar síður.

Við bættum líka við stöðu Tilbúinn. Miðinn er fluttur á hann eftir að skipt er um disk. Það er, allt hefur þegar verið gert, en HW/SW RAID er samstillt á þjóninum. Þetta getur tekið frekar langan tíma.

Ef stjórnandi tekur þátt í vinnunni verður kerfið aðeins flóknara.

Frá stöðu Opna Miðann er hægt að þýða bæði af kerfisstjóra og verkfræðingi. Í stöðu Í vinnslu stjórnandinn tekur diskinn úr snúningi þannig að verkfræðingurinn getur einfaldlega dregið hann út: kveikir á baklýsingu, tekur diskinn af, stöðvar forrit, allt eftir tilteknum hópi netþjóna.

Miðinn er síðan fluttur á Tilbúinn til að breyta: Þetta er merki til verkfræðingsins um að hægt sé að draga diskinn út. Allir reiti í Jira eru þegar fylltir út, verkfræðingur veit hvaða tegund og stærð disksins er. Þessi gögn eru annaðhvort slegin inn sjálfkrafa á fyrri stöðu eða af stjórnanda.

Eftir að skipt hefur verið um diskinn er miðastöðu breytt í Breytt. Það athugar hvort réttur diskur hafi verið settur í, skipting er lokið, forritið er ræst og sum gagnaendurheimtarverkefni eru ræst. Einnig er hægt að færa miðann á stöðuna Tilbúinn, í þessu tilviki verður stjórnandinn áfram ábyrgur, vegna þess að hann setti diskinn í snúning. Heildar skýringarmyndin lítur svona út.

Að bæta við nýjum sviðum gerði líf okkar miklu auðveldara. Strákarnir fóru að vinna með skipulagðar upplýsingar, það kom í ljós hvað þyrfti að gera og á hvaða stigi. Forgangsröðun hefur orðið mun meira viðeigandi þar sem þau eru nú sett af stjórnanda.

Það er engin þörf á spjalli. Auðvitað getur stjórnandinn skrifað verkfræðingnum „þetta þarf að skipta út hraðar“ eða „það er nú þegar kvöld, hefurðu tíma til að skipta um það?“ En við höfum ekki lengur samskipti daglega í spjalli um þessi mál.

Byrjað var að skipta um diska í lotum. Ef stjórnandinn kom aðeins snemma til vinnu, hann hefur lausan tíma og ekkert hefur gerst enn, getur hann undirbúið fjölda netþjóna fyrir skipti: fyllt út reitina, fjarlægt diska úr snúningi og flutt verkefnið til verkfræðings. Verkfræðingurinn kemur í gagnaverið nokkru síðar, sér verkefnið, tekur nauðsynlega drif úr vöruhúsinu og skiptir þeim strax út. Afleiðingin hefur verið sú að endurnýjunarhlutfallið hefur aukist.

Lærdómur sem dreginn er þegar unnið er að verkflæði

• Þegar þú smíðar verklag þarftu að safna upplýsingum frá mismunandi aðilum.
  Sumir stjórnendur okkar vissu ekki að verkfræðingurinn skipti sjálfur um diskana. Sumir héldu að MD RAID samstilling væri meðhöndluð af verkfræðingum, jafnvel þó að sumir þeirra hefðu ekki einu sinni aðgang að því. Sumir leiðandi verkfræðingar gerðu þetta, en ekki alltaf vegna þess að ferlinu var hvergi lýst.
• Aðferðin ætti að vera einföld og skiljanleg.
  Það er erfitt fyrir mann að hafa mörg skref í huga. Mikilvægustu nágrannastöðurnar í Jira ættu að vera settar á aðalskjáinn. Þú getur endurnefna þau, til dæmis köllum við Í vinnslu Tilbúnir til að breyta. Og aðrar stöður er hægt að fela í fellivalmynd svo að þær séu ekki augnayndi. En það er betra að takmarka fólk ekki, gefa því tækifæri til að gera umskipti.
  Útskýrðu gildi nýsköpunar. Þegar fólk skilur, er það meira að samþykkja nýja aðferðina. Það var mjög mikilvægt fyrir okkur að fólk smelli ekki í gegnum allt ferlið heldur fylgi því. Síðan byggðum við sjálfvirkni á þessu.
• Bíddu, greindu, reiknaðu út það.
  Það tók okkur um mánuð að byggja upp verklag, tæknilega útfærslu, fundi og umræður. Og framkvæmdin tekur meira en þrjá mánuði. Ég sá hvernig fólk er hægt og rólega farið að nota nýjungina. Það var mikil neikvæðni á fyrstu stigum. En það var algjörlega óháð málsmeðferðinni sjálfri og tæknilegri útfærslu hennar. Til dæmis notaði einn stjórnandi ekki Jira heldur Jira viðbótina í Confluence og sumt var honum ekki tiltækt. Við sýndum honum Jira og framleiðni stjórnandans jókst bæði fyrir almenn verkefni og til að skipta um diska.

Sjálfvirkni við að skipta um disk

Við nálguðumst sjálfvirkni við að skipta um disk nokkrum sinnum. Við höfðum þegar þróun og forskriftir, en þau virkuðu öll annað hvort gagnvirkt eða handvirkt og kröfðust ræsingar. Og fyrst eftir innleiðingu á nýju verklaginu áttuðum við okkur á að þetta var einmitt það sem okkur vantaði.

Þar sem skiptaferlinu okkar er skipt í þrep, sem hvert um sig hefur sérstakan flytjanda og lista yfir aðgerðir, getum við virkjað sjálfvirkni í áföngum, en ekki allar í einu. Til dæmis er einfaldasta stigið - Tilbúið (athugaðu RAID/gagnasamstillingu) auðveldlega hægt að framselja til lánmanns. Þegar botninn hefur lært aðeins, geturðu gefið honum mikilvægara verkefni - að setja diskinn í snúning o.s.frv.

Uppsetningar dýragarða

Áður en við tölum um botninn skulum við fara í stutta skoðunarferð inn í dýragarðinn okkar. Í fyrsta lagi er það vegna risastórrar innviða okkar. Í öðru lagi reynum við að velja bestu vélbúnaðarstillingar fyrir hverja þjónustu. Við erum með um 20 vélbúnaðar RAID gerðir, aðallega LSI og Adaptec, en það eru líka HP og DELL af mismunandi útgáfum. Hver RAID stjórnandi hefur sitt eigið stjórnunartól. Skipanirnar og útgáfa þeirra geta verið mismunandi eftir útgáfum fyrir hvern RAID stjórnandi. Þar sem HW-RAID er ekki notað, má nota mdraid.

Við gerum næstum allar nýjar uppsetningar án afritunar á diskum. Við reynum að nota ekki lengur vélbúnaðar- og hugbúnaðar-RAID, þar sem við tökum öryggisafrit af kerfum okkar á gagnamiðstöðvarstigi, ekki netþjónum. En auðvitað eru margir eldri netþjónar sem þarf að styðja.

Einhvers staðar eru diskarnir í RAID stjórnendum fluttir yfir í hrá tæki, einhvers staðar eru JBOD notaðir. Það eru stillingar með einum kerfisdiski á þjóninum, og ef það þarf að skipta um hann, þá þarftu að setja upp þjóninn aftur með uppsetningu á stýrikerfinu og forritum, af sömu útgáfum, bæta síðan við stillingarskrám, ræsa forrit. Það eru líka margir netþjónahópar þar sem öryggisafrit fer ekki fram á undirkerfisstigi disksins heldur beint í forritunum sjálfum.

Alls höfum við yfir 400 einstaka netþjónahópa sem keyra næstum 100 mismunandi forrit. Til að ná yfir svo gríðarlegan fjölda valkosta þurftum við fjölvirkt sjálfvirkniverkfæri. Helst með einföldum DSL, þannig að ekki aðeins sá sem skrifaði það geti stutt það.

Við völdum Ansible vegna þess að það er umboðslaust: það var engin þörf á að undirbúa innviði, fljótleg byrjun. Að auki er það skrifað í Python, sem er viðurkennt sem staðall innan liðsins.

Almenn áætlun

Við skulum skoða almenna sjálfvirknikerfið með því að nota eitt atvik sem dæmi. Zabbix skynjar að sdb diskurinn hefur bilað, kveikjan kviknar og miði er búinn til í Jira. Stjórnandinn horfði á það, áttaði sig á því að þetta var ekki afrit og ekki falskt jákvætt, það er að skipta þurfti um diskinn, og flutti miðann í Í vinnslu.

DiskoBot forritið, skrifað í Python, skoðar Jira reglulega eftir nýjum miðum. Það tekur eftir því að nýr miði í vinnslu hefur birst, samsvarandi þráður er settur af stað, sem ræsir leikbókina í Ansible (þetta er gert fyrir hverja stöðu í Jira). Í þessu tilviki er Prepare2change ræst.

Ansible er sendur til gestgjafans, tekur diskinn úr snúningi og tilkynnir stöðuna til forritsins í gegnum hringingar.

Byggt á niðurstöðunum flytur vélmenni miðann sjálfkrafa yfir á Tilbúinn til að breyta. Vélstjórinn fær tilkynningu og fer að skipta um disk, eftir það flytur hann miðann á Changed.

Samkvæmt áætluninni sem lýst er hér að ofan fer miðinn aftur til vélmannsins, sem setur aðra leikbók, fer til gestgjafans og setur diskinn í snúning. Botninn lokar miðanum. Húrra!

Nú skulum við tala um nokkra þætti kerfisins.

Diskobot

Þetta forrit er skrifað í Python. Það velur miða frá Jira samkvæmt JQL. Það fer eftir stöðu miðans, sá síðarnefndi fer til samsvarandi umsjónarmanns, sem aftur opnar Ansible leikbókina sem samsvarar stöðunni.

JQL og könnunarbil eru skilgreind í stillingarskrá forritsins.

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

Til dæmis, meðal miða í stöðunni Í vinnslu, eru aðeins þeir sem hafa reitina Diskastærð og Tækjaheiti útfylltir valdir. Nafn tækis er nafn blokkartækisins sem þarf til að keyra leikbókina. Diskastærð er nauðsynleg svo að verkfræðingur viti hvaða stærð diskur þarf.

Og meðal miða með tilbúinn stöðu eru miðar með dbot_ignore merkinu síaðir út. Við the vegur, við notum Jira merki bæði fyrir slíka síun og til að merkja afrit miða og safna tölfræði.

Ef leikbók mistekst úthlutar Jira dbot_failed merkimiðanum svo hægt sé að raða því út síðar.

Samvirkni við Ansible

Forritið hefur samskipti við Ansible í gegnum Ansible Python API. Til playbook_executor sendum við skráarnafnið og sett af breytum. Þetta gerir þér kleift að halda Ansible verkefninu í formi venjulegra yml skráa, frekar en að lýsa því í Python kóða.

Einnig í Ansible, í gegnum *extra_vars*, nafn blokkunartækisins, staða miðans, sem og callback_url, sem inniheldur útgáfulykilinn - það er notað fyrir svarhringingu í HTTP.

Fyrir hverja ræsingu er bráðabirgðaskrá búin til, sem samanstendur af einum hýsil og hópnum sem þessi hýsil tilheyrir, þannig að group_vars er beitt.

Hér er dæmi um verkefni sem útfærir HTTP svarhringingu.

Við fáum niðurstöðuna af því að keyra leikrit með því að nota callaback(s). Þau eru tvenns konar:

• Ansible svarhringingarviðbót, það veitir gögn um niðurstöður af framkvæmd leikbókar. Það lýsir þeim verkefnum sem voru sett af stað, unnin með góðum árangri eða án árangurs. Þetta svarhringingu er kallað þegar leikbókin hefur lokið spilun.
• HTTP-tilbakahringing til að fá upplýsingar meðan þú spilar leikbók. Í Ansible verkefninu framkvæmum við POST/GET beiðni í umsókn okkar.

Breytur eru sendar í gegnum HTTP-tilbakahringingu(r) sem voru skilgreindar við framkvæmd leikbókarinnar og sem við viljum vista og nota í síðari keyrslum. Við skrifum þessi gögn í sqlite.

Við skiljum líka eftir athugasemdir og breytum miðastöðu með HTTP-tilbakahringingu.

HTTP svarhringingu

# 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

Eins og mörg verkefni af sömu gerð, setjum við það í sérstaka sameiginlega skrá og látum hana fylgja ef þörf krefur, til að endurtaka það ekki stöðugt í leikbókum. Þetta felur í sér callback_ url, sem inniheldur útgáfulykilinn og hýsilheiti. Þegar Ansible framkvæmir þessa POST beiðni, skilur botninn að hún kom sem hluti af slíku og slíku atviki.

Og hér er dæmi úr leikbókinni, þar sem við sendum út disk úr MD tæki:

  # 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

Þetta verkefni flytur Jira miðann í stöðuna „Tilbúið til að breyta“ og bætir við athugasemd. Einnig geymir mdam_data breytan lista yfir md tæki sem diskurinn var fjarlægður úr, og parted_info geymir skiptingafrit frá parted.

Þegar verkfræðingur setur nýjan disk inn, getum við notað þessar breytur til að endurheimta skiptinguna, auk þess að setja diskinn inn í md tækin sem hann var fjarlægður úr.

Ómögulegur ávísunarhamur

Það var skelfilegt að kveikja á sjálfvirkninni. Þess vegna ákváðum við að keyra allar leikbækur í hamnum
þurrt hlaup, þar sem Ansible framkvæmir engar aðgerðir á netþjónunum heldur líkir aðeins eftir þeim.

Slík ræsing er keyrð í gegnum sérstaka afturkallareiningu og niðurstaðan af framkvæmd leikbókarinnar er vistuð í Jira sem athugasemd.

Í fyrsta lagi gerði þetta mögulegt að sannreyna verk vélmennisins og leikbókanna. Í öðru lagi jók það traust stjórnenda á botninum.

Þegar við stóðumst staðfestinguna og komumst að því að þú getur keyrt Ansible ekki aðeins í þurrkeyrsluham, gerðum við Run Diskobot hnapp í Jira til að ræsa sömu leikbókina með sömu breytum á sama vélinni, en í venjulegum ham.

Að auki er hnappurinn notaður til að endurræsa leikbókina ef hún hrynur.

Uppbygging leikbóka

Ég hef þegar nefnt að eftir stöðu Jira miðans setur vélmenni mismunandi leikbækur.

Í fyrsta lagi er miklu auðveldara að skipuleggja innganginn.
Í öðru lagi, í sumum tilfellum er það einfaldlega nauðsynlegt.

Til dæmis, þegar skipt er um kerfisdisk, þarftu fyrst að fara í dreifingarkerfið, búa til verkefni og eftir rétta dreifingu verður þjónninn aðgengilegur í gegnum ssh og þú getur rúllað forritinu út á það. Ef við gerðum þetta allt í einni leikbók, þá myndi Ansible ekki geta klárað það vegna þess að gestgjafinn væri ekki tiltækur.

Við notum Ansible hlutverk fyrir hvern hóp netþjóna. Hér má sjá hvernig leikbókin/bækurnar eru skipulagðar í einni þeirra.

Þetta er þægilegt vegna þess að það er strax ljóst hvar hvaða verkefni eru staðsett. Í main.yml, sem er inntakið fyrir Ansible hlutverkið, getum við einfaldlega látið fylgja með miðastöðu eða almenn verkefni sem krafist er fyrir alla, til dæmis að gefa skilríki eða fá tákn.

rannsókn.yml

Keyrir um miða í stöðunni Rannsókn og Opið. Það mikilvægasta fyrir þessa leikbók er nafn blokkartækisins. Þessar upplýsingar eru ekki alltaf tiltækar.

Til að fá það greinum við Jira samantektina, síðasta gildið frá Zabbix kveikjunni. Það gæti innihaldið nafn blokkartækisins - heppinn. Eða það gæti innihaldið mount point, þá þarftu að fara á netþjóninn, flokka hann og reikna út nauðsynlegan disk. Kveikjan getur einnig sent scsi heimilisfang eða aðrar upplýsingar. En það kemur líka fyrir að það eru engar vísbendingar, og þú verður að greina.

Eftir að hafa komist að nafni blokkarbúnaðarins söfnum við upplýsingum um gerð og stærð disksins af því til að fylla út reitina í Jira. Við fjarlægjum einnig upplýsingar um seljanda, gerð, fastbúnað, auðkenni, SMART og límum þetta allt í athugasemd í Jira miðanum. Stjórnandi og verkfræðingur þurfa ekki lengur að leita að þessum gögnum. 🙂

prepare2change.yml

Að fjarlægja diskinn úr snúningi, undirbúa skipti. Erfiðasta og mikilvægasta stigið. Þetta er þar sem þú getur stöðvað forritið þegar það ætti ekki að stöðva það. Eða taktu út disk sem var ekki með nógu mörgum eftirlíkingum og hefur þar með áhrif á notendur, tapa einhverjum gögnum. Hér höfum við flestar athuganir og tilkynningar í spjallinu.

Í einfaldasta tilfellinu erum við að tala um að fjarlægja disk úr HW/MD RAID.

Í flóknari aðstæðum (í geymslukerfum okkar), þegar öryggisafrit er framkvæmt á forritastigi, þarftu að fara í forritið í gegnum API, tilkynna um úttak disksins, slökkva á því og hefja endurheimtina.

Við erum nú að flytja í fjöldann til skýið, og ef þjónninn er skýjabundinn, þá kallar Diskobot skýjaforritið, segir að það muni virka með þessum minion - þjóninum sem keyrir gáma - og spyr "flytja alla gáma frá þessum minion." Og kveikir um leið á baklýsingu disksins þannig að verkfræðingur geti strax séð hvern þarf að draga út.

breytt.yml

Eftir að hafa skipt um disk, athugaum við fyrst hvort hann sé tiltækur.

Verkfræðingar setja ekki alltaf upp nýja drif, svo við bættum við ávísun á SMART gildi sem fullnægja okkur.

Hvaða eiginleika erum við að skoða?Fjöldi endurúthlutaðra geira (5) < 100
Núverandi bíður geiratalning (107) == 0

Ef drifið stenst ekki prófið er verkfræðingur tilkynnt um að skipta um það aftur. Ef allt er í lagi slokknar á baklýsingunni, merkingar eru settar á og diskurinn settur í snúning.

tilbúið.yml

Einfaldasta tilvikið: athuga HW/SW raid samstillingu eða klára gagnasamstillingu í forritinu.

Forritaskil forrita

Ég hef nefnt nokkrum sinnum að botninn hefur oft aðgang að forritaskilum. Auðvitað voru ekki allar umsóknir með nauðsynlegar aðferðir og því þurfti að breyta þeim. Hér eru mikilvægustu aðferðirnar sem við notum:

• Staða. Staða klasa eða disks til að skilja hvort hægt sé að vinna með hann;
• Byrja/stöðva. Diskur virkja/afvirkja;
• Flytja/endurheimta. Gagnaflutningur og endurheimt á meðan og eftir skipti.

Lærdómur dreginn af Ansible

Ég elska Ansible virkilega. En oft, þegar ég skoða mismunandi opinn uppspretta verkefni og sé hvernig fólk skrifar leikrit, verð ég svolítið hræddur. Flóknar rökrænar samfléttingar hvenær/lykkja, skortur á sveigjanleika og getuleysi vegna tíðrar notkunar skel/skipunar.

Við ákváðum að einfalda allt eins mikið og hægt er og nýta kostinn við Ansible - mát. Á hæsta stigi eru leikbækur; þær geta verið skrifaðar af hvaða stjórnanda sem er, þriðja aðila verktaki sem kann svolítið Ansible.

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

Ef erfitt er að útfæra einhverja rökfræði í leikbókum flytjum við hana í Ansible einingu eða síu. Forskriftir geta verið skrifaðar á Python eða hvaða öðru tungumáli sem er.

Þau eru auðveld og fljót að skrifa. Til dæmis, baklýsingaeining disksins, sem dæmi um það er sýnt hér að ofan, samanstendur af 265 línum.

Á neðsta hæðinni er bókasafnið. Fyrir þetta verkefni skrifuðum við sérstakt forrit, eins konar abstrakt yfir vélbúnaðar- og hugbúnaðar-RAID sem framkvæma samsvarandi beiðnir.

Stærstu kostir Ansible eru einfaldleikinn og skýrar leikbækur. Ég tel að þú þurfir að nota þetta og búa ekki til ógnvekjandi yaml skrár og mikinn fjölda skilyrða, skeljakóða og lykkjur.

Ef þú vilt endurtaka reynslu okkar af Ansible API skaltu hafa tvennt í huga:

• Ekki er hægt að gefa Playbook_executor og leikbókum almennt tímamörk. Það er tími á ssh lotunni, en það er enginn tími í leikbókinni. Ef við reynum að aftengja disk sem er ekki lengur til í kerfinu mun leikbókin keyra endalaust, þannig að við þurftum að pakka henni inn í sérstakan umbúðir og drepa hana með tímamörkum.
• Ansible keyrir á gaffluðum ferlum, svo API þess er ekki þráðöruggt. Við keyrum allar leikbækur okkar einþráðar.

Fyrir vikið gátum við sjálfvirkt skiptingu á um 80% af diskum. Í heildina hefur endurnýjunarhlutfallið tvöfaldast. Í dag skoðar stjórnandinn bara atvikið og ákveður hvort skipta þurfi um diskinn eða ekki og smellir svo á einn.

En nú erum við farin að lenda í öðru vandamáli: sumir nýir stjórnendur vita ekki hvernig á að skipta um drif. 🙂

Heimild: www.habr.com