Pozdravljeni vsi skupaj. Delam kot vodilni sistemski administrator v OK in sem odgovoren za stabilno delovanje portala. Želim govoriti o tem, kako smo zgradili postopek za samodejno zamenjavo diskov in kako smo iz tega procesa izključili skrbnika in ga nadomestili z botom.
Ta članek je neke vrste transliteracija na HighLoad+ 2018
Izdelava postopka zamenjave diska
Najprej nekaj številk
OK je ogromna storitev, ki jo uporablja na milijone ljudi. Oskrbuje ga približno 7 tisoč strežnikov, ki se nahajajo v 4 različnih podatkovnih centrih. Strežniki vsebujejo več kot 70 tisoč diskov. Če jih zložite enega na drugega, dobite več kot 1 km visok stolp.
Trdi diski so komponenta strežnika, ki se najpogosteje okvari. Pri takšnih količinah moramo zamenjati približno 30 diskov na teden in ta postopek je postal ne ravno prijetna rutina.
Incidenti
Naše podjetje je uvedlo popolno obvladovanje incidentov. Vsak incident zabeležimo v Jiri, nato pa ga razrešimo in uredimo. Če je incident vplival na uporabnike, potem se vsekakor dobimo in razmislimo, kako se v takih primerih hitreje odzvati, kako zmanjšati učinek in seveda preprečiti ponovitev.
Naprave za shranjevanje niso izjema. Njihov status spremlja Zabbix. Spremljamo sporočila v Syslogu glede napak pri pisanju/branju, analiziramo stanje HW/SW napadov, spremljamo SMART in izračunavamo obrabo za SSD.
Kako so se menjavali diski prej
Ko pride do sprožilca v Zabbixu, se v Jiri ustvari incident in samodejno dodeli ustreznim inženirjem v podatkovnih centrih. To počnemo pri vseh HW incidentih, torej tistih, ki zahtevajo kakršno koli fizično delo z opremo v podatkovnem centru.
Inženir podatkovnega centra je oseba, ki rešuje težave v zvezi s strojno opremo in je odgovorna za namestitev, vzdrževanje in razstavljanje strežnikov. Po prejemu vstopnice se inženir loti dela. V diskovnih policah samostojno menja diske. Če pa nima dostopa do zahtevane naprave, se inženir za pomoč obrne na dežurne sistemske skrbnike. Najprej morate odstraniti disk iz vrtenja. Če želite to narediti, morate narediti potrebne spremembe na strežniku, ustaviti aplikacije in odklopiti disk.
Za delovanje celotnega portala v delovni izmeni skrbi dežurni sistemski skrbnik. Raziskuje incidente, izvaja popravila in pomaga razvijalcem dokončati manjša opravila. Ne ukvarja se samo s trdimi diski.
Prej so inženirji podatkovnih centrov s sistemskim administratorjem komunicirali prek klepeta. Inženirji so poslali povezave do vstopnic Jira, skrbnik jim je sledil, vodil dnevnik dela v neki beležnici. Toda klepeti so za takšne naloge neprijetni: tam informacije niso strukturirane in se hitro izgubijo. In skrbnik je lahko preprosto odšel od računalnika in se nekaj časa ni odzval na zahteve, medtem ko je inženir stal na strežniku s svežnjem diskov in čakal.
A najslabše je bilo, da skrbniki niso videli celotne slike: kateri diskovni incidenti so obstajali, kje bi se lahko pojavila težava. To je posledica dejstva, da vse HW incidente prenesemo na inženirje. Da, vse dogodke je bilo mogoče prikazati na skrbniški nadzorni plošči. Vendar jih je veliko in skrbnik je sodeloval le pri nekaterih.
Poleg tega inženir ni mogel pravilno določiti prioritet, ker ne ve ničesar o namenu posameznih strežnikov ali distribuciji informacij med pogoni.
Nov postopek zamenjave
Prva stvar, ki smo jo naredili, je bila, da smo vse diskovne incidente premaknili v ločeno vrsto »HW disk« in mu dodali polja »blokiraj ime naprave«, »velikost« in »vrsta diska«, tako da bodo te informacije shranjene v vstopnici in ni treba nenehno izmenjevati v klepetu.
Dogovorili smo se tudi, da ob enem incidentu zamenjamo samo en disk. To je bistveno poenostavilo proces avtomatizacije, zbiranje statistike in delo v prihodnosti.
Poleg tega smo dodali polje »odgovorni skrbnik«. Tam se samodejno vstavi dežurni sistemski administrator. To je zelo priročno, saj zdaj inženir vedno vidi, kdo je odgovoren. Ni vam treba iti v koledar in iskati. Prav to polje je omogočilo prikaz vozovnic na skrbniški nadzorni plošči, ki bi morda potrebovala njegovo pomoč.
Da bi zagotovili, da so vsi udeleženci imeli največ koristi od inovacij, smo ustvarili filtre in nadzorne plošče ter fantom povedali o njih. Ko ljudje spremembe razumejo, se od njih ne distancirajo kot od nepotrebnega. Za inženirja je pomembno, da pozna številko regala, kjer se nahaja strežnik, velikost in vrsto diska. Skrbnik mora najprej razumeti, kakšna skupina strežnikov je to in kakšen je lahko učinek pri zamenjavi diska.
Prisotnost polj in njihov prikaz sta priročna, vendar nas ni rešila potrebe po uporabi klepetov. Da bi to dosegli, smo morali spremeniti potek dela.
Prej je bilo tako:
Tako inženirji delajo še danes, ko ne potrebujejo pomoči skrbnika.
Najprej smo uvedli nov status Raziščite. Tisk je v tem statusu, ko se inženir še ni odločil, ali bo potreboval skrbnika ali ne. S tem statusom lahko inženir prenese vstopnico skrbniku. Poleg tega to stanje uporabljamo za označevanje vstopnic, ko je disk treba zamenjati, samega diska pa ni na mestu. To se zgodi v primeru CDN in oddaljenih spletnih mest.
Dodali smo tudi status Želite. Vstopnica se nanj prenese po zamenjavi diska. Se pravi, vse je že narejeno, vendar je HW/SW RAID sinhroniziran na strežniku. To lahko traja precej dolgo.
Če je v delo vključen skrbnik, postane shema nekoliko bolj zapletena.
Od statusa Odprto Vstopnico lahko prevedeta tako sistemski administrator kot inženir. V statusu V teku skrbnik odstrani disk iz rotacije, tako da ga lahko inženir preprosto izvleče: vklopi osvetlitev ozadja, odklopi disk, zaustavi aplikacije, odvisno od specifične skupine strežnikov.
Vstopnica se nato prenese na Pripravljen na spremembo: To je signal za inženirja, da lahko disk izvleče. Vsa polja v Jiri so že izpolnjena, inženir ve, kakšna je vrsta in velikost diska. Ti podatki se vnesejo bodisi avtomatsko ob prejšnjem statusu bodisi s strani administratorja.
Po zamenjavi diska se status vstopnice spremeni v spremenjeno. Preveri, ali je bil vstavljen pravi disk, ali je particioniranje opravljeno, ali je aplikacija zagnana in zagnana so nekatera opravila za obnovitev podatkov. Vstopnico lahko prenesete tudi v status Želite, v tem primeru ostane skrbnik odgovoren, ker je dal disk v rotacijo. Celoten diagram izgleda takole.
Z dodajanjem novih področij je naše življenje zelo olajšano. Fantje so začeli delati s strukturiranimi informacijami, postalo je jasno, kaj je treba storiti in v kateri fazi. Prioritete so postale veliko bolj aktualne, saj jih sedaj postavlja skrbnik.
Ni potrebe po klepetih. Seveda lahko administrator napiše inženirju "to je treba hitreje zamenjati" ali "je že večer, boš imel čas zamenjati?" Vendar o teh vprašanjih ne komuniciramo več dnevno v klepetalnicah.
Diski so se začeli spreminjati v serijah. Če je skrbnik prišel na delo nekoliko zgodaj, ima prosti čas in se še nič ni zgodilo, lahko pripravi več strežnikov za zamenjavo: izpolni polja, odstrani diske iz rotacije in prenese nalogo na inženirja. Inženir pride v podatkovni center malo kasneje, si ogleda nalogo, vzame potrebne diske iz skladišča in jih takoj zamenja. Posledično se je stopnja zamenjave povečala.
Lekcije, pridobljene pri gradnji poteka dela
- Ko sestavljate postopek, morate zbrati informacije iz različnih virov.
Nekateri naši administratorji niso vedeli, da inženir sam menja diske. Nekateri so mislili, da za sinhronizacijo MD RAID skrbijo inženirji, čeprav nekateri sploh niso imeli dostopa do tega. Nekateri vodilni inženirji so to storili, vendar ne vedno, ker postopek ni bil nikjer opisan. - Postopek mora biti enostaven in razumljiv.
Človek težko obdrži v mislih veliko korakov. Najpomembnejša sosednja stanja v Jiri naj bodo postavljena na glavni zaslon. Lahko jih preimenujete, na primer imenujemo V teku Pripravljeno na spremembo. Ostala stanja pa lahko skrijete v spustnem meniju, da ne bodo moteča. Vendar je bolje, da ljudi ne omejujemo, da jim damo možnost prehoda.
Pojasnite vrednost inovacije. Ko ljudje razumejo, bolj sprejemajo nov postopek. Za nas je bilo zelo pomembno, da ljudje ne klikajo skozi celoten proces, ampak mu sledijo. Nato smo na tem gradili avtomatizacijo. - Počakajte, analizirajte, ugotovite.
Za gradnjo postopka, tehnično izvedbo, sestanke in pogovore smo porabili približno mesec dni. In izvedba traja več kot tri mesece. Videl sem, kako ljudje počasi začenjajo uporabljati novost. V zgodnjih fazah je bilo veliko negativnosti. Bil pa je popolnoma neodvisen od samega postopka in njegove tehnične izvedbe. En administrator na primer ni uporabljal Jire, ampak vtičnik Jira v Confluenceu in mu nekatere stvari niso bile na voljo. Pokazali smo mu Jira in produktivnost skrbnika se je povečala tako pri splošnih opravilih kot pri zamenjavi diskov.
Avtomatizacija zamenjave diska
Večkrat smo pristopili k avtomatizaciji zamenjave diska. Imeli smo že razvoj in skripte, vendar so vsi delovali interaktivno ali ročno in zahtevali zagon. In šele po uvedbi novega postopka smo ugotovili, da je prav to tisto, kar nam manjka.
Ker je zdaj naš postopek zamenjave razdeljen na stopnje, od katerih ima vsaka določenega izvajalca in seznam dejanj, lahko omogočimo avtomatizacijo po stopnjah in ne naenkrat. Na primer, najpreprostejšo stopnjo - Ready (preverjanje RAID/sinhronizacije podatkov) lahko preprosto prenesete na bot. Ko se bot malo nauči, mu lahko dodelite pomembnejšo nalogo - vrtenje diska itd.
Postavitev živalskega vrta
Preden govorimo o botu, se odpravimo na kratek izlet v naš živalski vrt instalacij. Najprej je to posledica ogromne velikosti naše infrastrukture. Drugič, poskušamo izbrati optimalno konfiguracijo strojne opreme za vsako storitev. Imamo približno 20 modelov strojne opreme RAID, večinoma LSI in Adaptec, na voljo pa sta tudi HP in DELL različnih različic. Vsak krmilnik RAID ima svoj pripomoček za upravljanje. Nabor ukazov in njihova izdaja se lahko razlikujejo od različice do različice za vsak krmilnik RAID. Kjer HW-RAID ni uporabljen, se lahko uporabi mdraid.
Skoraj vse nove namestitve izvajamo brez varnostne kopije diska. Trudimo se, da ne uporabljamo več strojne in programske opreme RAID, saj varnostno kopiramo svoje sisteme na ravni podatkovnega centra, ne strežnikov. Seveda pa je treba podpreti veliko podedovanih strežnikov.
Nekje se diski v RAID krmilnikih prenesejo na raw naprave, nekje se uporabljajo JBOD-ji. V strežniku so konfiguracije z enim sistemskim diskom in če ga je treba zamenjati, potem je treba znova namestiti strežnik z namestitvijo OS in aplikacij, istih različic, nato dodati konfiguracijske datoteke, zagnati aplikacije. Obstaja tudi veliko skupin strežnikov, kjer se varnostno kopiranje izvaja ne na ravni diskovnega podsistema, temveč neposredno v samih aplikacijah.
Skupaj imamo več kot 400 edinstvenih skupin strežnikov, ki izvajajo skoraj 100 različnih aplikacij. Za pokritje tako velikega števila možnosti smo potrebovali večnamensko orodje za avtomatizacijo. Po možnosti s preprostim DSL-jem, da ga ne podpira le tisti, ki ga je napisal.
Ansible smo izbrali, ker je brez agentov: ni bilo treba pripravljati infrastrukture, hiter začetek. Poleg tega je napisan v Pythonu, ki je v ekipi sprejet kot standard.
Splošna shema
Oglejmo si splošno shemo avtomatizacije na primeru enega incidenta. Zabbix zazna, da je disk sdb odpovedal, sprožilec zasveti in v Jiri se ustvari vstopnica. Administrator ga je pogledal, ugotovil, da ni dvojnik in ni lažno pozitiven, to je, da je treba zamenjati disk, in vstopnico prenesel v V teku.
Aplikacija DiskoBot, napisana v Pythonu, občasno vpraša Jira za nove vstopnice. Opazi, da se je pojavila nova vstopnica V teku, sproži se ustrezna nit, ki zažene playbook v Ansible (to se naredi za vsako stanje v Jiri). V tem primeru se zažene Prepare2change.
Ansible se pošlje gostitelju, odstrani disk iz rotacije in prijavi status aplikaciji prek povratnih klicev.
Na podlagi rezultatov bot samodejno prenese vstopnico v Ready to change. Inženir prejme obvestilo in gre zamenjat disk, nato pa vstopnico prenese v Changed.
V skladu z zgoraj opisano shemo se vstopnica vrne k botu, ki zažene drugo playbook, gre do gostitelja in postavi disk v rotacijo. Bot zapre vstopnico. Hura!
Zdaj pa se pogovorimo o nekaterih komponentah sistema.
Diskobot
Ta aplikacija je napisana v Pythonu. Izbere vstopnice iz Jira glede na JQL. Odvisno od statusa vozovnice gre ta k ustreznemu upravljavcu, ki nato zažene Ansible playbook, ki ustreza statusu.
JQL in intervali pozivanja so definirani v konfiguracijski datoteki aplikacije.
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
Na primer, med prijavami v statusu V teku so izbrane le tiste z izpolnjenimi polji Velikost diska in Ime naprave. Ime naprave je ime blokovne naprave, potrebne za izvajanje priročnika. Velikost diska je potrebna, da inženir ve, kakšno velikost diska potrebuje.
In med vstopnicami s statusom Ready so vstopnice z oznako dbot_ignore filtrirane. Mimogrede, oznake Jira uporabljamo tako za takšno filtriranje kot za označevanje podvojenih vstopnic in zbiranje statistike.
Če playbook ne uspe, Jira dodeli oznako dbot_failed, tako da se lahko pozneje razvrsti.
Interoperabilnost z Ansible
Aplikacija komunicira z Ansible prek . Playbook_executorju posredujemo ime datoteke in nabor spremenljivk. To vam omogoča, da projekt Ansible obdržite v obliki običajnih datotek yml, namesto da ga opisujete v kodi Python.
Tudi v Ansible, preko *extra_vars*, ime blokovne naprave, status vstopnice, kot tudi callback_url, ki vsebuje ključ težave - uporablja se za povratni klic v HTTP.
Za vsak zagon se ustvari začasni popis, sestavljen iz enega gostitelja in skupine, ki ji ta gostitelj pripada, tako da se uporabijo group_vars.
Tukaj je primer naloge, ki izvaja povratni klic HTTP.
Dobimo rezultat izvajanja playbooks z uporabo povratnih klicev. So dveh vrst:
- , zagotavlja podatke o rezultatih izvajanja playbook. Opisuje naloge, ki so bile sprožene, uspešno ali neuspešno zaključene. Ta povratni klic se prikliče, ko je knjiga predvajanja končana.
- Povratni klic HTTP za prejemanje informacij med igranjem knjige. V opravilu Ansible izvedemo zahtevo POST/GET za našo aplikacijo.
Spremenljivke se posredujejo prek povratnih klicev HTTP, ki so bili definirani med izvajanjem priročnika in jih želimo shraniti ter uporabiti pri naslednjih zagonih. Te podatke zapišemo v sqlite.
Prav tako pustimo komentarje in spremenimo status vstopnice prek povratnega klica HTTP.
HTTP povratni klic
# 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
Tako kot mnoge naloge istega tipa smo jo dali v ločeno skupno datoteko in jo po potrebi vključili, da je ne bi nenehno ponavljali v učbenikih. To vključuje callback_ url, ki vsebuje ključ težave in ime gostitelja. Ko Ansible izvede to POST zahtevo, bot razume, da je prišla kot del takšnega in drugačnega incidenta.
In tukaj je primer iz priročnika, v katerem izpišemo disk iz MD naprave:
# 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
Ta naloga prenese vozovnico Jira v status »Pripravljen za spremembo« in doda komentar. Poleg tega spremenljivka mdam_data shrani seznam naprav md, iz katerih je bil disk odstranjen, parted_info pa shrani izpis particije iz parted.
Ko inženir vstavi nov disk, lahko uporabimo te spremenljivke za obnovitev izpisa particije, pa tudi za vstavljanje diska v naprave md, iz katerih je bil odstranjen.
Ansible način preverjanja
Bilo je strašljivo vklopiti avtomatizacijo. Zato smo se odločili zagnati vse knjige iger v načinu
, pri katerem Ansible na strežnikih ne izvaja nobenih dejanj, ampak jih le emulira.
Takšen zagon poteka prek ločenega modula za povratni klic, rezultat izvedbe playbooka pa se shrani v Jira kot komentar.
Prvič, to je omogočilo potrditev dela bota in playbooks. Drugič, povečalo je zaupanje skrbnikov v bota.
Ko smo prestali preverjanje veljavnosti in ugotovili, da lahko Ansible izvajate ne le v načinu suhega delovanja, smo v Jiri naredili gumb Zaženi Diskobot za zagon istega playbooka z istimi spremenljivkami na istem gostitelju, vendar v običajnem načinu.
Poleg tega se gumb uporablja za ponovni zagon playbooka, če se zruši.
Struktura Playbooks
Omenil sem že, da glede na stanje vozovnice Jira bot zažene različne playbooke.
Prvič, veliko lažje je organizirati vhod.
Drugič, v nekaterih primerih je preprosto potrebno.
Na primer, pri zamenjavi sistemskega diska morate najprej iti v sistem za uvajanje, ustvariti nalogo in po pravilni uvedbi bo strežnik postal dostopen prek ssh in nanj lahko namestite aplikacijo. Če bi vse to naredili v enem playbooku, potem Ansible tega ne bi mogel dokončati, ker gostitelj ni na voljo.
Za vsako skupino strežnikov uporabljamo vloge Ansible. Tukaj si lahko ogledate, kako so zvezki organizirani v enem od njih.
To je priročno, ker je takoj jasno, kje se katera opravila nahajajo. V main.yml, ki je vhod za vlogo Ansible, lahko preprosto vključimo glede na stanje vozovnice ali splošne naloge, potrebne za vse, na primer posredovanje identifikacije ali prejemanje žetona.
Preiskava.yml
Teče za vstopnice v statusu Preiskava in Odprto. Najpomembnejša stvar za to knjižico je ime blokovne naprave. Te informacije niso vedno na voljo.
Da ga pridobimo, analiziramo povzetek Jira, zadnjo vrednost iz sprožilca Zabbix. Lahko vsebuje ime blokovne naprave - sreča. Lahko pa vsebuje točko priklopa, potem morate iti na strežnik, ga razčleniti in izračunati zahtevani disk. Sprožilec lahko posreduje tudi naslov scsi ali kakšno drugo informacijo. Zgodi pa se tudi, da ni namigov in morate analizirati.
Ko ugotovimo ime blokovne naprave, z nje zbiramo podatke o vrsti in velikosti diska, da izpolnimo polja v Jiri. Prav tako odstranimo podatke o prodajalcu, modelu, vdelani programski opremi, ID-ju, SMART-u in vse to vstavimo v komentar v vozovnici Jira. Administratorju in inženirju ni več treba iskati teh podatkov. 🙂
pripravi2sprememba.yml
Odstranjevanje diska iz vrtenja, priprava na zamenjavo. Najtežja in pomembna faza. Tukaj lahko ustavite aplikacijo, ko je ne bi smeli ustaviti. Ali pa odstranite disk, ki ni imel dovolj replik, in s tem vplivate na uporabnike, izgubite nekaj podatkov. Tukaj imamo največ preverjanj in obvestil v klepetu.
V najenostavnejšem primeru govorimo o odstranitvi diska iz HW/MD RAID.
V bolj zapletenih situacijah (v naših sistemih za shranjevanje), ko se varnostno kopiranje izvaja na ravni aplikacije, morate iti v aplikacijo prek API-ja, prijaviti izpis diska, ga deaktivirati in začeti obnovitev.
Zdaj se množično selimo v , in če je strežnik v oblaku, potem Diskobot pokliče API v oblaku, pove, da bo deloval s tem minionom - strežnikom, ki poganja vsebnike - in vpraša "preseli vse vsebnike iz tega miniona." In hkrati vklopi osvetlitev ozadja diska, tako da lahko inženir takoj vidi, katerega je treba izvleči.
spremenjeno.yml
Po zamenjavi diska najprej preverimo njegovo razpoložljivost.
Inženirji ne namestijo vedno novih pogonov, zato smo dodali preverjanje vrednosti SMART, ki nas zadovoljijo.
Katere atribute gledamo?Število prerazporejenih sektorjev (5) < 100
Trenutno število sektorjev v teku (107) == 0
Če pogon ne opravi preizkusa, je inženir obveščen, da ga znova zamenja. Če je vse v redu, se osvetlitev ozadja izklopi, nanesejo se oznake in disk se zavrti.
pripravljeno.yml
Najenostavnejši primer: preverjanje sinhronizacije HW/SW raid ali dokončanje sinhronizacije podatkov v aplikaciji.
API aplikacije
Večkrat sem omenil, da bot pogosto dostopa do aplikacijskih API-jev. Vse aplikacije seveda niso imele potrebnih metod, zato jih je bilo treba spremeniti. Tukaj so najpomembnejše metode, ki jih uporabljamo:
- Stanje. Status gruče ali diska, da bi razumeli, ali je z njim mogoče delati;
- Start/stop. Aktivacija/deaktivacija diska;
- Preseli/obnovi. Selitev in obnovitev podatkov med in po zamenjavi.
Lekcije, pridobljene pri Ansibleu
Res mi je všeč Ansible. Toda ko pogledam različne odprtokodne projekte in vidim, kako ljudje pišejo knjige, me je pogosto malo strah. Zapleteni logični prepleti kdaj/zanke, pomanjkanje prožnosti in idempotence zaradi pogoste uporabe lupine/ukaza.
Odločili smo se, da vse skupaj čim bolj poenostavimo in izkoristimo prednost Ansiblea - modularnost. Na najvišji ravni so knjige iger; lahko jih napiše vsak skrbnik, zunanji razvijalec, ki se malo spozna na Ansible.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Če je neko logiko težko implementirati v priročnike, jo premaknemo v modul ali filter Ansible. Skripte je mogoče napisati v Pythonu ali katerem koli drugem jeziku.
Napišejo se enostavno in hitro. Na primer, modul za osvetlitev ozadja diska, katerega primer je prikazan zgoraj, je sestavljen iz 265 vrstic.
Na najnižjem nivoju je knjižnica. Za ta projekt smo napisali ločeno aplikacijo, nekakšno abstrakcijo nad strojnimi in programskimi RAID-i, ki izvajajo ustrezne zahteve.
Največja prednost Ansiblea sta njegova preprostost in jasne knjige iger. Menim, da morate to uporabiti in ne ustvarjati strašljivih datotek yaml in ogromno pogojev, lupinske kode in zank.
Če želite ponoviti našo izkušnjo z API-jem Ansible, upoštevajte dve stvari:
- Playbook_executor in playbooks na splošno ni mogoče dodeliti časovne omejitve. V seji ssh je časovna omejitev, v priročniku pa ni časovne omejitve. Če poskušamo odklopiti disk, ki ne obstaja več v sistemu, se bo playbook izvajal neskončno, zato smo morali njegov zagon zaviti v ločen ovoj in ga ubiti s časovno omejitvijo.
- Ansible deluje na razcepljenih procesih, zato njegov API ni varen za niti. Vse naše knjige iger izvajamo v eni niti.
Posledično nam je uspelo avtomatizirati zamenjavo približno 80 % diskov. Na splošno se je nadomestitvena stopnja podvojila. Danes administrator samo pogleda incident in se odloči, ali je treba disk zamenjati ali ne, nato pa naredi en klik.
Toda zdaj se začenjamo srečevati z drugo težavo: nekateri novi skrbniki ne vedo, kako zamenjati pogone. 🙂
Vir: www.habr.com