Bok svima. Radim kao vodeći sistem administrator u OK-u i odgovoran sam za stabilan rad portala. Želim govoriti o tome kako smo izgradili proces za automatsku zamjenu diskova, a zatim kako smo isključili administratora iz ovog procesa i zamijenili ga botom.
Ovaj je članak neka vrsta transliteracije na HighLoad+ 2018
Izgradnja procesa zamjene diska
Prvo neke brojke
OK je ogromna usluga koju koriste milijuni ljudi. Opslužuje ga oko 7 tisuća poslužitelja koji se nalaze u 4 različita podatkovna centra. Poslužitelji sadrže više od 70 tisuća diskova. Ako ih složite jednu na drugu, dobit ćete toranj visok više od 1 km.
Tvrdi diskovi su komponente poslužitelja koje najčešće kvare. S takvim količinama moramo promijeniti 30-ak diskova tjedno, a taj je postupak postao ne baš ugodna rutina.
Incidenti
Naša tvrtka je uvela potpuno upravljanje incidentima. Svaki incident bilježimo u Jiri, a zatim ga rješavamo i rješavamo. Ako je neki incident utjecao na korisnike, onda se svakako okupimo i razmislimo kako u takvim slučajevima brže reagirati, kako smanjiti učinak i, naravno, spriječiti ponavljanje.
Uređaji za pohranu nisu iznimka. Njihov status prati Zabbix. Pratimo poruke u Syslogu radi grešaka pisanja/čitanja, analiziramo status HW/SW napada, pratimo SMART i izračunavamo istrošenost SSD-ova.
Kako su se prije mijenjali diskovi
Kada se okidač dogodi u Zabbixu, incident se stvara u Jiri i automatski se dodjeljuje odgovarajućim inženjerima u podatkovnim centrima. To radimo sa svim HW incidentima, odnosno onima koji zahtijevaju bilo kakav fizički rad s opremom u podatkovnom centru.
Inženjer podatkovnog centra je osoba koja rješava probleme vezane uz hardver i odgovorna je za instaliranje, održavanje i demontažu poslužitelja. Nakon što je primio kartu, inženjer se bacio na posao. U policama za diskove samostalno mijenja diskove. No, ako nema pristup potrebnom uređaju, inženjer se za pomoć obraća dežurnim sistem administratorima. Prije svega, morate ukloniti disk iz rotacije. Da biste to učinili, trebate napraviti potrebne promjene na poslužitelju, zaustaviti aplikacije i demontirati disk.
Za rad cijelog portala tijekom radne smjene odgovoran je dežurni administrator sustava. On istražuje incidente, vrši popravke i pomaže programerima da dovrše male zadatke. Ne bavi se samo tvrdim diskovima.
Prethodno su inženjeri podatkovnog centra s administratorom sustava komunicirali putem chata. Inženjeri su slali poveznice na Jira karte, administrator ih je pratio, vodio dnevnik rada u nekom notepadu. Ali chatovi su nezgodni za takve zadatke: informacije tamo nisu strukturirane i brzo se izgube. A administrator je mogao jednostavno otići od računala i neko vrijeme ne odgovarati na zahtjeve, dok je inženjer stajao na poslužitelju s hrpom diskova i čekao.
Ali najgore je što administratori nisu vidjeli cijelu sliku: koji su diskovni incidenti postojali, gdje bi potencijalno mogao nastati problem. To je zbog činjenice da sve HW incidente delegiramo inženjerima. Da, bilo je moguće prikazati sve incidente na administratorskoj nadzornoj ploči. Ali ima ih puno, a administrator je bio uključen samo u neke od njih.
Osim toga, inženjer nije mogao ispravno postaviti prioritete, jer ne zna ništa o namjeni pojedinih poslužitelja ili distribuciji informacija među pogonima.
Novi postupak zamjene
Prvo što smo učinili bilo je premještanje svih diskovnih incidenata u zasebnu vrstu "HW disk" i tome dodali polja "block device name", "size" i "disk type" kako bi te informacije bile pohranjene u ulaznici i ne morate stalno razmjenjivati u chatu.
Također smo se dogovorili da ćemo tijekom jednog incidenta promijeniti samo jedan disk. Time je značajno pojednostavljen proces automatizacije, prikupljanje statistike i rad u budućnosti.
Osim toga, dodali smo polje "odgovorni administrator". Tu se automatski ubacuje dežurni administrator sustava. To je vrlo zgodno, jer sada inženjer uvijek vidi tko je odgovoran. Nema potrebe ići u kalendar i tražiti. Upravo je to polje omogućilo prikaz ulaznica na nadzornoj ploči administratora za koje bi mogla biti potrebna njegova pomoć.
Kako bismo osigurali da svi sudionici imaju maksimalnu korist od inovacija, izradili smo filtre i nadzorne ploče i rekli dečkima o njima. Kada ljudi shvate promjene, ne ograđuju se od njih kao od nečega nepotrebnog. Za inženjera je važno znati broj regala u kojem se nalazi poslužitelj, veličinu i vrstu diska. Administrator prije svega treba razumjeti o kakvoj se skupini poslužitelja radi i kakav bi učinak mogao imati zamjena diska.
Prisutnost polja i njihov prikaz su zgodni, ali nas nisu spasili od potrebe za korištenjem chatova. Da bismo to učinili, morali smo promijeniti tijek rada.
Prije je bilo ovako:
Ovako inženjeri nastavljaju raditi danas kada im nije potrebna pomoć administratora.
Prvo što smo napravili je uvođenje novog statusa Istraga. Tiket je u ovom statusu kada inženjer još nije odlučio hoće li mu trebati administrator ili ne. Preko ovog statusa inženjer može prenijeti kartu administratoru. Osim toga, koristimo ovaj status za označavanje tiketa kada disk treba zamijeniti, ali sam disk nije na licu mjesta. To se događa u slučaju CDN-ova i udaljenih stranica.
Dodali smo i status Spreman. Ulaznica se prenosi na njega nakon zamjene diska. Odnosno, sve je već napravljeno, ali je HW/SW RAID sinkroniziran na serveru. Ovo može potrajati dosta dugo.
Ako je u rad uključen administrator, shema postaje malo kompliciranija.
Od statusa Otvoren Kartu mogu prevesti i administrator sustava i inženjer. U statusu U nastajanju administrator uklanja disk iz rotacije tako da ga inženjer može jednostavno izvući: uključuje pozadinsko osvjetljenje, demontira disk, zaustavlja aplikacije, ovisno o specifičnoj grupi poslužitelja.
Ulaznica se zatim prenosi na Spreman za promjenu: Ovo je signal inženjeru da se disk može izvući. Sva polja u Jiri su već popunjena, inženjer zna koja je vrsta i veličina diska. Ovi podaci se unose ili automatski na prethodnom statusu ili od strane administratora.
Nakon zamjene diska status karte se mijenja u promijenjen. Provjerava je li umetnut ispravan disk, je li napravljeno particioniranje, pokrenuta je aplikacija i pokrenuti su neki zadaci za oporavak podataka. Ulaznica se također može prebaciti u status Spreman, u ovom slučaju će administrator ostati odgovoran, jer je stavio disk u rotaciju. Kompletan dijagram izgleda ovako.
Dodavanje novih polja znatno nam je olakšalo život. Dečki su počeli raditi sa strukturiranim informacijama, postalo je jasno što treba učiniti i u kojoj fazi. Prioriteti su postali puno relevantniji jer ih sada postavlja administrator.
Nema potrebe za razgovorima. Naravno, administrator može napisati inženjeru "ovo treba brže zamijeniti" ili "već je večer, hoćete li imati vremena to zamijeniti?" Ali više ne komuniciramo svakodnevno u chatovima o tim pitanjima.
Diskovi su se počeli mijenjati u serijama. Ako je administrator došao na posao malo ranije, ima slobodnog vremena i još se ništa nije dogodilo, može pripremiti nekoliko poslužitelja za zamjenu: ispuniti polja, ukloniti diskove iz rotacije i prenijeti zadatak inženjeru. Inženjer dolazi nešto kasnije u podatkovni centar, vidi zadatak, uzima potrebne diskove iz skladišta i odmah ih zamjenjuje. Kao rezultat toga, stopa zamjene je porasla.
Lekcije naučene pri izgradnji tijeka rada
- Kada konstruirate postupak, morate prikupiti informacije iz različitih izvora.
Neki naši administratori nisu znali da inženjer sam mijenja diskove. Neki ljudi su mislili da se MD RAID sinkronizacijom bave inženjeri, iako neki od njih nisu ni imali pristup za to. Neki vodeći inženjeri su to učinili, ali ne uvijek jer proces nigdje nije opisan. - Postupak treba biti jednostavan i razumljiv.
Čovjeku je teško zadržati mnoge korake na umu. Najvažnije susjedne statuse u Jiri treba staviti na glavni ekran. Možete ih preimenovati, na primjer, zovemo U tijeku Spremno za promjenu. A ostale statuse možete sakriti u padajućem izborniku da ne budu trn u oku. Ali bolje je ne ograničavati ljude, dati im priliku za prijelaz.
Objasnite vrijednost inovacije. Kad ljudi razumiju, više prihvaćaju novi postupak. Bilo nam je jako važno da ljudi ne klikaju kroz cijeli proces, nego ga prate. Zatim smo na tome izgradili automatizaciju. - Čekaj, analiziraj, shvati.
Trebalo nam je oko mjesec dana za izradu procedure, tehničku implementaciju, sastanke i rasprave. A provedba traje više od tri mjeseca. Vidio sam kako ljudi polako počinju koristiti inovaciju. Bilo je mnogo negativnosti u ranim fazama. Ali to je bilo potpuno neovisno o samom postupku i njegovoj tehničkoj provedbi. Primjerice, jedan administrator nije koristio Jiru, nego Jira plugin u Confluenceu i neke stvari mu nisu bile dostupne. Pokazali smo mu Jira, a produktivnost administratora se povećala i za općenite zadatke i za zamjenu diskova.
Automatizacija zamjene diskova
Automatizaciji zamjene diskova pristupili smo više puta. Već smo imali razvoj i skripte, ali svi su radili ili interaktivno ili ručno i zahtijevali su pokretanje. I tek nakon uvođenja novog postupka shvatili smo da je upravo to ono što nam nedostaje.
Budući da je sada naš proces zamjene podijeljen u faze, od kojih svaka ima određenog izvođača i popis radnji, možemo omogućiti automatizaciju u fazama, a ne sve odjednom. Na primjer, najjednostavnija faza - Ready (provjera RAID/sinkronizacije podataka) može se lako delegirati botu. Kada je bot malo naučio, možete mu dati važniji zadatak - stavljanje diska u rotaciju itd.
Zoološki vrtovi
Prije nego što pričamo o botu, idemo na kratki izlet u naš zoološki vrt instalacija. Prije svega, to je zbog goleme veličine naše infrastrukture. Drugo, nastojimo odabrati optimalnu hardversku konfiguraciju za svaku uslugu. Imamo oko 20 hardverskih RAID modela, uglavnom LSI i Adaptec, ali tu su i HP i DELL različitih verzija. Svaki RAID kontroler ima vlastiti uslužni program za upravljanje. Skup naredbi i njihovo izdavanje može se razlikovati od verzije do verzije za svaki RAID kontroler. Gdje se ne koristi HW-RAID, može se koristiti mdraid.
Gotovo sve nove instalacije radimo bez sigurnosne kopije diska. Trudimo se više ne koristiti hardverski i softverski RAID jer sigurnosno kopiramo svoje sustave na razini podatkovnog centra, a ne poslužitelja. No, naravno, postoji mnogo naslijeđenih poslužitelja koje treba podržati.
Negdje se diskovi u RAID kontrolerima prebacuju na raw uređaje, negdje se koriste JBOD-ovi. Postoje konfiguracije s jednim sistemskim diskom u poslužitelju, a ako ga treba zamijeniti, onda morate reinstalirati poslužitelj s instalacijom OS-a i aplikacija, istih verzija, zatim dodati konfiguracijske datoteke, pokrenuti aplikacije. Također postoji mnogo grupa poslužitelja u kojima se sigurnosna kopija ne izvodi na razini podsustava diska, već izravno u samim aplikacijama.
Ukupno imamo više od 400 jedinstvenih grupa poslužitelja koji pokreću gotovo 100 različitih aplikacija. Kako bismo pokrili tako velik broj opcija, trebao nam je višenamjenski alat za automatizaciju. Po mogućnosti s jednostavnim DSL-om, tako da ga ne može podržati samo osoba koja ga je napisala.
Odabrali smo Ansible jer je bez agenta: nije bilo potrebe za pripremom infrastrukture, brz početak. Osim toga, napisan je u Pythonu, koji je prihvaćen kao standard unutar tima.
Opća shema
Pogledajmo opću shemu automatizacije koristeći jedan incident kao primjer. Zabbix detektira da je sdb disk pokvaren, okidač svijetli i karta se kreira u Jiri. Administrator ga je pogledao, shvatio da nije duplikat i nije lažno pozitivan, odnosno disk treba promijeniti i prebacio tiket u U tijeku.
DiskoBot aplikacija, napisana u Pythonu, povremeno ispituje Jira za nove karte. Primjećuje da se pojavila nova ulaznica U tijeku, pokreće se odgovarajuća nit, koja pokreće playbook u Ansibleu (ovo se radi za svaki status u Jiri). U ovom slučaju pokreće se Prepare2change.
Ansible se šalje glavnom računalu, uklanja disk iz rotacije i prijavljuje status aplikaciji putem povratnih poziva.
Na temelju rezultata, bot automatski prenosi kartu u Ready to change. Inženjer dobiva obavijest i odlazi promijeniti disk, nakon čega prebacuje tiket u Changed.
Prema gore opisanoj shemi, ulaznica se vraća botu, koji pokreće drugu knjigu igranja, odlazi do hosta i stavlja disk u rotaciju. Bot zatvara kartu. hura!
Razgovarajmo sada o nekim komponentama sustava.
Diskobot
Ova aplikacija je napisana u Pythonu. Odabire ulaznice iz Jire prema JQL-u. Ovisno o statusu ulaznice, potonja ide do odgovarajućeg rukovatelja, koji zauzvrat pokreće Ansible playbook koji odgovara statusu.
JQL i intervali prozivanja definirani su u konfiguracijskoj datoteci 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 primjer, među tiketima u statusu U tijeku odabiru se samo oni s popunjenim poljima Veličina diska i Naziv uređaja. Naziv uređaja naziv je blok uređaja potrebnog za izvođenje playbook-a. Veličina diska je potrebna kako bi inženjer znao koja veličina diska je potrebna.
A među ulaznicama sa statusom Ready, ulaznice s oznakom dbot_ignore su filtrirane. Usput, Jira oznake koristimo i za takvo filtriranje i za označavanje duplikata ulaznica i prikupljanje statistike.
Ako igra ne uspije, Jira dodjeljuje oznaku dbot_failed tako da se kasnije može riješiti.
Interoperabilnost s Ansibleom
Aplikacija komunicira s Ansibleom putem . Playbook_executoru prosljeđujemo naziv datoteke i skup varijabli. To vam omogućuje da Ansible projekt zadržite u obliku običnih yml datoteka, umjesto da ga opisujete u Python kodu.
Također u Ansibleu, preko *extra_vars*, naziv blok uređaja, status tiketa, kao i callback_url, koji sadrži ključ problema - koristi se za povratni poziv u HTTP-u.
Za svako pokretanje generira se privremeni inventar koji se sastoji od jednog hosta i grupe kojoj taj host pripada, tako da se primjenjuju group_vars.
Ovdje je primjer zadatka koji implementira HTTP povratni poziv.
Dobivamo rezultat izvršavanja playbooks koristeći callaback(ove). Postoje dvije vrste:
- , pruža podatke o rezultatima izvođenja playbook-a. Opisuje zadatke koji su pokrenuti, uspješno ili neuspješno dovršeni. Ovaj povratni poziv se poziva kada playbook završi reprodukciju.
- HTTP povratni poziv za primanje informacija tijekom igranja knjige. U zadatku Ansible izvršavamo POST/GET zahtjev našoj aplikaciji.
Varijable se prosljeđuju kroz HTTP povratni poziv(e) koji su definirani tijekom izvođenja priručnika i koje želimo spremiti i koristiti u sljedećim izvođenjima. Ove podatke zapisujemo u sqlite.
Također ostavljamo komentare i mijenjamo status tiketa putem HTTP povratnog poziva.
HTTP povratni poziv
# 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
Kao i mnoge zadatke iste vrste, stavljamo ga u zasebnu zajedničku datoteku i uključujemo ako je potrebno, kako se ne bi stalno ponavljali u igrama. Ovo uključuje callback_ url, koji sadrži ključ problema i naziv hosta. Kada Ansible izvrši ovaj POST zahtjev, bot razumije da je došao kao dio tog i tog incidenta.
Evo primjera iz priručnika, u kojem ispisujemo disk iz MD uređaja:
# 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
Ovaj zadatak prenosi Jira kartu u status "Spreman za promjenu" i dodaje komentar. Također, varijabla mdam_data pohranjuje popis md uređaja s kojih je disk uklonjen, a parted_info pohranjuje dump particije iz parteda.
Kada inženjer umetne novi disk, možemo koristiti ove varijable za vraćanje dumpa particije, kao i umetanje diska u md uređaje s kojih je uklonjen.
Anzibilni način provjere
Bilo je zastrašujuće uključiti automatizaciju. Stoga smo odlučili pokrenuti sve knjige igara u načinu rada
, u kojem Ansible ne izvodi nikakve akcije na poslužiteljima, već ih samo emulira.
Takvo se pokretanje izvodi kroz zaseban modul za povratni poziv, a rezultat izvršavanja playbooka sprema se u Jira kao komentar.
Prvo, ovo je omogućilo provjeru valjanosti rada bota i playbooka. Drugo, povećao je povjerenje administratora u bota.
Kada smo prošli provjeru valjanosti i shvatili da možete pokrenuti Ansible ne samo u suhom načinu rada, napravili smo gumb Pokreni Diskobot u Jiri za pokretanje iste knjige s istim varijablama na istom hostu, ali u normalnom načinu rada.
Osim toga, gumb se koristi za ponovno pokretanje playbooka ako se sruši.
Struktura Playbooks
Već sam spomenuo da ovisno o statusu Jira tiketa, bot pokreće različite knjige igranja.
Prvo, puno je lakše organizirati ulaz.
Drugo, u nekim slučajevima jednostavno je potrebno.
Na primjer, kod zamjene sistemskog diska prvo trebate otići u sustav za implementaciju, kreirati zadatak, a nakon pravilne implementacije, server će postati dostupan preko ssh-a i na njemu možete instalirati aplikaciju. Kad bismo sve ovo napravili u jednom playbooku, Ansible to ne bi mogao dovršiti zbog nedostupnosti hosta.
Koristimo Ansible uloge za svaku grupu poslužitelja. Ovdje možete vidjeti kako je knjiga(e) organizirana u jednoj od njih.
Ovo je zgodno jer je odmah jasno gdje se koji zadaci nalaze. U main.yml, koji je ulaz za Ansible ulogu, možemo jednostavno uključiti prema statusu tiketa ili općim zadacima potrebnim svima, na primjer, prosljeđivanje identifikacije ili primanje tokena.
istraga.yml
Trči za ulaznice u statusu Istraživanje i Otvoreno. Najvažnija stvar za ovu knjigu je naziv blok uređaja. Ove informacije nisu uvijek dostupne.
Da bismo ga dobili, analiziramo Jira sažetak, posljednju vrijednost iz Zabbix okidača. Može sadržavati naziv blok uređaja - lucky. Ili može sadržavati točku montiranja, tada trebate otići na poslužitelj, analizirati ga i izračunati potrebni disk. Okidač također može prenijeti scsi adresu ili neku drugu informaciju. Ali također se događa da nema tragova, pa morate analizirati.
Nakon što saznamo naziv blok uređaja, s njega prikupljamo informacije o vrsti i veličini diska za popunjavanje polja u Jiri. Također uklanjamo podatke o dobavljaču, modelu, firmware-u, ID-u, SMART-u i sve to ubacujemo u komentar u Jira tiketu. Administrator i inženjer više ne moraju tražiti te podatke. 🙂
pripremi2promijeni.yml
Uklanjanje diska iz rotacije, priprema za zamjenu. Najteža i najvažnija faza. Ovdje možete zaustaviti aplikaciju kada ne bi trebala biti zaustavljena. Ili izvaditi disk koji nije imao dovoljno replika, i time utjecati na korisnike, izgubiti neke podatke. Ovdje imamo najviše provjera i obavijesti u chatu.
U najjednostavnijem slučaju govorimo o uklanjanju diska iz HW/MD RAID-a.
U složenijim situacijama (u našim sustavima za pohranu), kada se backup radi na razini aplikacije, potrebno je preko API-ja otići u aplikaciju, prijaviti izlaz diska, deaktivirati ga i pokrenuti oporavak.
Mi sada masovno migriramo u , a ako je poslužitelj temeljen na oblaku, tada Diskobot poziva Cloud API, kaže da će raditi s ovim miljenikom - poslužiteljem koji pokreće spremnike - i pita "preselite sve spremnike iz ovog miljenika." I u isto vrijeme uključuje pozadinsko osvjetljenje diska tako da inženjer može odmah vidjeti koji treba izvući.
promijenjeno.yml
Nakon zamjene diska prvo provjeravamo njegovu dostupnost.
Inženjeri ne instaliraju uvijek nove pogone, pa smo dodali provjeru SMART vrijednosti koje nas zadovoljavaju.
Koje atribute gledamo?Broj preraspodijeljenih sektora (5) < 100
Trenutačni broj sektora na čekanju (107) == 0
Ako pogon ne prođe test, inženjer se obavještava da ga ponovno zamijeni. Ako je sve u redu, pozadinsko osvjetljenje se gasi, stavljaju se oznake i disk se stavlja u rotaciju.
spreman.yml
Najjednostavniji slučaj: provjera HW/SW raid sinkronizacije ili završetak sinkronizacije podataka u aplikaciji.
API aplikacije
Nekoliko sam puta spomenuo da bot često pristupa API-jima aplikacije. Naravno, nisu sve aplikacije imale potrebne metode, pa su se morale modificirati. Ovo su najvažnije metode koje koristimo:
- Status. Status klastera ili diska da biste razumjeli može li se s njim raditi;
- Start/stop. Aktivacija/deaktivacija diska;
- Migracija/vraćanje. Migracija podataka i oporavak tijekom i nakon zamjene.
Lekcije naučene od Ansiblea
Stvarno volim Ansible. Ali često se malo uplašim kad pogledam različite opensource projekte i vidim kako ljudi pišu knjige. Složena logička ispreplitanja kada/petlje, nedostatak fleksibilnosti i idempotencija zbog česte upotrebe ljuske/naredbe.
Odlučili smo sve maksimalno pojednostaviti, iskoristivši prednost Ansiblea - modularnost. Na najvišoj razini postoje knjige za igru; može ih napisati bilo koji administrator, programer treće strane koji imalo poznaje Ansible.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Ako je neku logiku teško implementirati u priručnike, mi je premještamo u Ansible modul ili filtar. Skripte se mogu pisati u Pythonu ili bilo kojem drugom jeziku.
Pišu se lako i brzo. Na primjer, modul pozadinskog osvjetljenja diska, čiji je primjer prikazan gore, sastoji se od 265 redaka.
Na najnižoj razini je knjižnica. Za ovaj projekt napisali smo zasebnu aplikaciju, svojevrsnu apstrakciju nad hardverskim i softverskim RAID-ovima koji izvršavaju odgovarajuće zahtjeve.
Najveće prednosti Ansiblea su njegova jednostavnost i jasne knjige. Vjerujem da trebate koristiti ovo, a ne generirati zastrašujuće yaml datoteke i ogroman broj uvjeta, shell koda i petlji.
Ako želite ponoviti naše iskustvo s Ansible API-jem, imajte na umu dvije stvari:
- Playbook_executor i playbooks općenito ne mogu dobiti vremensko ograničenje. Postoji vremensko ograničenje za ssh sesiju, ali nema vremenskog ograničenja za playbook. Ako pokušamo demontirati disk koji više ne postoji u sustavu, playbook će se izvoditi beskrajno, tako da smo morali zamotati njegovo pokretanje u poseban omot i ubiti ga timeoutom.
- Ansible radi na račvastim procesima, tako da njegov API nije niti siguran. Sve naše knjige s igrama izvodimo u jednoj niti.
Kao rezultat, uspjeli smo automatizirati zamjenu oko 80% diskova. Sve u svemu, stopa zamjene se udvostručila. Danas administrator samo pogleda incident i odluči treba li disk mijenjati ili ne, a zatim napravi jedan klik.
Ali sada počinjemo nailaziti na još jedan problem: neki novi administratori ne znaju kako promijeniti pogone. 🙂
Izvor: www.habr.com