Salute à tutti. U travagliu cum'è un amministratore di sistema di punta à OK è sò rispunsevuli di l'operazione stabile di u portale. Vogliu parlà di cumu avemu custruitu un prucessu per rimpiazzà automaticamente i dischi, è poi cumu escludemu l'amministratore da stu prucessu è rimpiazzatu cù un bot.
Questu articulu hè un tipu di traslitterazione à HighLoad+ 2018
Custruì un prucessu di sustituzione di discu
Prima alcuni numeri
OK hè un serviziu gigante utilizatu da milioni di persone. Hè servutu da circa 7 mila servitori, chì si trovanu in 4 centri di dati diffirenti. I servitori cuntenenu più di 70 mila dischi. Se li stack l'un à l'altru, avete una torre alta più di 1 km.
I discu duru sò u cumpunente di u servitore chì falla più spessu. Cù tali volumi, avemu da cambià circa 30 discu à settimana, è sta prucedura hè diventata una rutina micca assai piacevule.
Incidenti
A nostra cumpagnia hà introduttu una gestione di incidenti cumpleta. Registramu ogni incidente in Jira, è poi risolvemu è sorte. Se un incidente hà avutu un effettu nantu à l'utilizatori, allora avemu definitu riunite è pensemu à cumu per risponde più veloce in questi casi, cumu per riduce l'effettu è, sicuru, cumu per prevene una recurrenza.
I dispusitivi di almacenamiento ùn sò micca eccezzioni. U so statutu hè monitoratu da Zabbix. Monitoremu i missaghji in Syslog per l'errore di scrittura / lettura, analizemu u statutu di i raids HW / SW, monitoremu SMART, è calculemu l'usura per i SSD.
Cumu i dischi eranu cambiati prima
Quandu si verifica un trigger in Zabbix, un incidente hè creatu in Jira è automaticamente assignatu à l'ingegneri appropritati in i centri di dati. Facemu questu cù tutti l'incidenti HW, vale à dì quelli chì necessitanu ogni travagliu fisicu cù l'equipaggiu in u centru di dati.
Un ingegnere di u centru di dati hè una persona chì risolve i prublemi ligati à u hardware è hè rispunsevuli di installà, mantene è dismantling servers. Dopu avè ricevutu u bigliettu, l'ingegnere si mette à u travagliu. In i scaffali di discu cambia i discu indipindente. Ma s'ellu ùn hà micca accessu à u dispusitivu necessariu, l'ingegnere si rivolge à l'amministratori di u sistema di turnu per aiutu. Prima di tuttu, avete bisognu di caccià u discu da a rotazione. Per fà questu, avete bisognu di fà i cambiamenti necessarii nantu à u servitore, piantà l'applicazioni è unmount u discu.
L'amministratore di u sistema in turnu hè rispunsevule per u funziunamentu di tuttu u portale durante u turnu di travagliu. Ellu investiga incidenti, ripara, è aiuta i sviluppatori à compie picculi travaglii. Ùn si tratta micca solu di discu duru.
In precedenza, l'ingegneri di u centru di dati cumunicavanu cù l'amministratore di u sistema via chat. L'ingegneri anu mandatu ligami à i biglietti di Jira, l'amministratore li hà seguitu, hà guardatu un logu di u travagliu in un bloccu note. Ma i chats sò inconvenienti per tali compiti: l'infurmazione ùn hè micca strutturata è si perde rapidamente. È l'amministratore puderia simpricimenti alluntanassi da l'urdinatore è ùn risponde micca à e dumande per qualchì tempu, mentre chì l'ingegnere stava à u servitore cù una pila di dischi è aspittava.
Ma u peghju era chì l'amministratori ùn anu micca vistu tuttu u ritrattu: chì incidenti di discu esistenu, induve un prublema puderia esse. Questu hè duvuta à u fattu chì avemu delegatu tutti l'incidenti HW à l'ingegneri. Iè, era pussibule di vede tutti l'incidentali nantu à u dashboard di l'amministratore. Ma ci sò assai di elli, è l'amministratore era implicatu solu per alcuni d'elli.
Inoltre, l'ingegnere ùn puderia micca stabilisce e priorità currettamente, perchè ùn sapi nunda di u scopu di i servitori specifichi o a distribuzione di l'infurmazioni trà e unità.
Nova prucedura di rimpiazzamentu
A prima cosa chì avemu fattu era spustà tutti i incidenti di discu in un tipu separatu "discu HW" è aghjunghjenu i campi "nome di u dispositivu di bloccu", "taglia" è "tipu di discu" in modu chì sta informazione sia guardata in u bigliettu è avissi ùn deve micca scambià constantemente in chat.
Avemu ancu accunsentutu chì durante un incidente cambiassi solu un discu. Questu hà simplificatu significativamente u prucessu d'automatizazione, a cullizzioni di statistiche è u travagliu in u futuru.
Inoltre, avemu aghjustatu u campu "amministratore rispunsevule". L'amministratore di u sistema di turnu hè automaticamente inseritu quì. Questu hè assai cunvenutu, perchè avà l'ingegnere vede sempre quale hè rispunsevule. Ùn ci hè bisognu di andà à u calendariu è di ricerca. Hè stu campu chì hà permessu di vede i biglietti nantu à u dashboard di l'amministratore chì puderia esse bisognu di u so aiutu.
Per assicurà chì tutti i participanti anu ricivutu u massimu benefiziu da l'innuvazioni, avemu creatu filtri è dashboards è hà dettu à i picciotti nantu à elli. Quandu a ghjente capisce i cambiamenti, ùn si alluntananu micca da elli cum'è qualcosa innecessariu. Hè impurtante per un ingegnere cunnosce u numeru di rack induve u servitore hè situatu, a dimensione è u tipu di discu. L'amministratore hà bisognu, prima di tuttu, di capisce chì tipu di gruppu di servitori hè questu è ciò chì l'effettu puderia esse quandu rimpiazzà un discu.
A prisenza di campi è a so visualizazione hè cunvene, ma ùn ci hà micca salvatu da a necessità di utilizà chats. Per fà questu, avemu avutu à cambià u flussu di travagliu.
Prima era cusì:
Hè cusì chì l'ingegneri cuntinuanu à travaglià oghje quandu ùn anu micca bisognu di l'aiutu di l'amministratore.
A prima cosa chì avemu fattu era intruduce un novu statutu Sapemu. U bigliettu hè in questu statutu quandu l'ingegnere ùn hà ancu decisu s'ellu hà bisognu di un amministratore o micca. Per mezu di stu statutu, l'ingegnere pò trasfiriri u bigliettu à l'amministratore. Inoltre, usemu stu statutu per marcà i biglietti quandu un discu deve esse rimpiazzatu, ma u discu stessu ùn hè micca in situ. Questu succede in u casu di CDN è siti remoti.
Avemu ancu aghjustatu statutu Animu. U bigliettu hè trasferitu à questu dopu à rimpiazzà u discu. Questu hè, tuttu hè digià fattu, ma u RAID HW / SW hè sincronizatu nantu à u servitore. Questu pò piglià assai tempu.
Se un amministratore hè implicatu in u travagliu, u schema diventa un pocu più cumplicatu.
Da u statutu Open U bigliettu pò esse traduttu da l'amministratore di u sistema è l'ingegnere. In statu In corsu l'amministratore sguassate u discu da a rotazione in modu chì l'ingegnere pò solu tirà fora: accende a retroilluminazione, unmounts u discu, ferma l'applicazioni, secondu u gruppu specificu di servitori.
U bigliettu hè dopu trasferitu à Pronta à cambià: Questu hè un signalu à l'ingegnere chì u discu pò esse tiratu fora. Tutti i campi in Jira sò digià cumpletu, l'ingegnere sapi quale tipu è dimensione di u discu. Queste dati sò inseriti automaticamente in u statu precedente o da l'amministratore.
Dopu avè rimpiazzatu u discu, u statutu di u bigliettu hè cambiatu à cambiatu. Hè verificatu chì u discu currettu hè statu inseritu, u particionamentu hè fattu, l'applicazione hè lanciata è alcuni travaglii di ricuperazione di dati sò lanciati. U bigliettu pò ancu esse trasferitu à u statutu Animu, in questu casu, l'amministratore serà rispunsevuli, perchè mette u discu in rotazione. U diagramma cumpletu pare cusì.
L'aghjunzione di novi campi facia a nostra vita assai più faciule. I picciotti cuminciaru à travaglià cù l'infurmazioni strutturate, hè diventatu chjaru ciò chì deve esse fattu è in quale stadiu. E priorità sò diventate assai più pertinenti, postu chì sò avà stabilite da l'amministratore.
Ùn ci hè bisognu di chats. Di sicuru, l'amministratore pò scrive à l'ingegnere "questu deve esse rimpiazzatu più veloce", o "hè digià sera, averà u tempu di rimpiazzà?" Ma ùn avemu più cumunicà ogni ghjornu in chats nantu à sti prublemi.
I dischi cuminciaru à esse cambiati in batch. Se l'amministratore hè ghjuntu à travaglià un pocu prima, hà u tempu liberu, è nunda ùn hè accadutu ancu, pò preparà una quantità di servitori per rimpiazzà: riempie i campi, sguassate i dischi da a rotazione è trasfiriu u compitu à un ingegnere. L'ingegnere vene à u centru di dati un pocu dopu, vede u compitu, piglia l'unità necessarii da u magazzinu è i rimpiazza immediatamente. In u risultatu, a tarifa di rimpiazzamentu hè aumentata.
Lezioni amparate quandu custruisce u flussu di travagliu
- Quandu custruisce una prucedura, avete bisognu di cullà infurmazioni da diverse fonti.
Qualchidunu di i nostri amministratori ùn sapianu micca chì l'ingegnere cambia u discu stessu. Certi pirsuni pensanu chì a sincronizazione MD RAID hè stata trattata da l'ingegneri, ancu s'è alcuni di elli ùn anu mancu accessu per fà. Certi ingegneri principali anu fattu questu, ma micca sempre perchè u prucessu ùn era micca scrittu in ogni locu. - A prucedura deve esse simplice è comprensibile.
Hè difficiuli per una persona di mantene parechji passi in mente. I statuti vicini più impurtanti in Jira deve esse postu nantu à a pantalla principale. Pudete rinominà elli, per esempiu, chjamemu In progress Ready to change. È altri stati ponu esse ammucciati in un menu drop-down in modu chì ùn sò micca un ochju. Ma hè megliu micca limità a ghjente, per dà l'uppurtunità di fà a transizione.
Spiegà u valore di l'innuvazione. Quandu a ghjente capisce, sò più accettate di a nova prucedura. Era assai impurtante per noi chì a ghjente ùn cliccà micca in tuttu u prucessu, ma seguitate. Allora avemu custruitu l'automatizazione nantu à questu. - Aspetta, analizà, capisce.
Ci hà pigliatu circa un mese per custruisce a prucedura, implementazione tecnica, riunioni è discussioni. È l'implementazione dura più di trè mesi. Aghju vistu cumu a ghjente hà cuminciatu lentamente à aduprà l'innuvazione. Ci era assai negatività in i primi tempi. Ma era completamente indipendente da a prucedura stessa è a so implementazione tecnica. Per esempiu, un amministratore ùn hà micca usatu Jira, ma u plugin Jira in Confluence, è certi cose ùn eranu micca dispunibili per ellu. L'avemu dimustratu Jira, è a produtividade di l'amministratore hà aumentatu per i travaglii generale è per rimpiazzà i dischi.
Automatizazione di rimpiazzamentu di discu
Avemu avvicinatu l'automatizazione di a sustituzione di discu parechje volte. Avemu digià avutu sviluppi è scripts, ma tutti anu travagliatu in modu interattivu o manualmente è necessitanu u lanciamentu. È solu dopu avè introduttu a nova prucedura avemu capitu chì questu era esattamente ciò chì ci mancava.
Dapoi avà u nostru prucessu di sustituzione hè divisu in tappe, ognuna di quali hà un performer specificu è una lista di azzioni, pudemu attivà l'automatizazione in tappe, è micca tutte in una volta. Per esempiu, u stadiu più simplice - Ready (verificà a sincronizazione RAID / dati) pò esse facilmente delegata à un bot. Quandu u bot hà amparatu un pocu, pudete dà un compitu più impurtante - mette u discu in rotazione, etc.
Configurazioni di u zoo
Prima di parlà di u bot, facemu una breve escursione in u nostru zoo di installazioni. Prima di tuttu, hè duvuta à a dimensione gigantesca di a nostra infrastruttura. Siconda, pruvemu di selezziunà a cunfigurazione hardware ottima per ogni serviziu. Avemu circa 20 mudelli RAID di hardware, soprattuttu LSI è Adaptec, ma ci sò ancu HP è DELL di diverse versioni. Ogni controller RAID hà a so propria utilità di gestione. U settore di cumandamenti è l'emissione di elli pò differisce da versione à versione per ogni controller RAID. Induve HW-RAID ùn hè micca usatu, mdraid pò esse usatu.
Facemu quasi tutte e novi installazioni senza salvezza di discu. Pruvemu di ùn aduprà più hardware è software RAID, cum'è avemu una copia di salvezza di i nostri sistemi à u livellu di u centru di dati, micca i servitori. Ma di sicuru, ci sò parechji servitori legacy chì deve esse supportatu.
In qualchì locu i discu in i cuntrolli RAID sò trasferiti à i dispositi crudi, in un locu JBODs sò usati. Ci sò cunfigurazioni cù un discu di u sistema in u servore, è s'ellu ci vole à esse rimpiazzatu, allora avete da reinstallà u servitore cù a stallazione di u SO è l'applicazioni, di e listesse versioni, dopu aghjunghje i schedarii di cunfigurazione, lanciate applicazioni. Ci hè ancu assai gruppi di servitori induve a copia di salvezza hè realizata micca à u livellu di u sottosistema di discu, ma direttamente in l'applicazioni stessi.
In totale, avemu più di 400 gruppi di servitori unichi chì gestiscenu quasi 100 applicazioni diverse. Per copre un numeru cusì grande di opzioni, avemu bisognu di un strumentu d'automatizazione multifunzionale. Preferibile cù un DSL simplice, perchè micca solu a persona chì l'hà scrittu pò sustene.
Avemu sceltu Ansible perchè hè senza agenti: ùn ci era micca bisognu di preparà l'infrastruttura, un principiu rapidu. Inoltre, hè scrittu in Python, chì hè accettatu cum'è standard in a squadra.
Schema generale
Fighjemu u schema di automatizazione generale utilizendu un incidente cum'è un esempiu. Zabbix detecta chì u discu sdb hà fiascatu, u trigger si accende, è un bigliettu hè creatu in Jira. L'amministratore l'hà guardatu, hà capitu chì ùn era micca un duplicatu è micca un falsu pusitivu, vale à dì chì u discu avia da esse cambiatu, è trasfirìu u bigliettu à In progress.
L'applicazione DiskoBot, scritta in Python, sonda periodicamente Jira per novi biglietti. Nota chì un novu bigliettu In progress hè apparsu, u filu currispundente hè attivatu, chì lancia u playbook in Ansible (questu hè fattu per ogni statutu in Jira). In questu casu, Prepare2change hè lanciatu.
Ansible hè mandatu à l'ospite, sguassate u discu da a rotazione è informa u statutu à l'applicazione via Callbacks.
Basatu nantu à i risultati, u bot trasferisce automaticamente u bigliettu à Ready to change. L'ingegnere riceve una notificazione è va à cambià u discu, dopu chì trasferisce u bigliettu à Cambiatu.
Sicondu u schema descrittu sopra, u bigliettu torna à u bot, chì lancia un altru playbook, va à l'ospite è mette u discu in rotazione. U bot chjude u bigliettu. Eura!
Avà parlemu di certi cumpunenti di u sistema.
Diskobot
Questa applicazione hè scritta in Python. Selezziunate i biglietti da Jira secondu JQL. Sicondu u statutu di u bigliettu, l'ultime va à u gestore currispundente, chì à u turnu lancia u Ansible playbook currispundenti à u statutu.
JQL è intervalli di polling sò definiti in u schedariu di cunfigurazione di l'applicazione.
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
Per esempiu, trà i biglietti in u statu In prugressu, sò selezziunati solu quelli cù i campi di dimensione di u discu è di u nome di u dispositivu. U nome di u dispusitivu hè u nome di u dispusitivu di bloccu necessariu per eseguisce u playbook. A dimensione di u discu hè necessariu per chì l'ingegnere sapi ciò chì u discu hè necessariu.
È trà i biglietti cù u statutu Ready, i biglietti cù l'etichetta dbot_ignore sò filtrati. A propositu, usemu l'etichette Jira sia per tali filtri è per marcà i biglietti duplicati è raccoglie statistiche.
Se un playbook falla, Jira assigna l'etichetta dbot_failed per pudè esse risolta dopu.
Interoperabilità cù Ansible
L'applicazione comunica cù Ansible via . À playbook_executor passemu u nome di u schedariu è un inseme di variàbili. Questu permette di mantene u prughjettu Ansible in a forma di schedarii regulari yml, piuttostu cà di discrive in codice Python.
Ancu in Ansible, via * extra_vars *, u nome di u dispositivu di bloccu, u statutu di u bigliettu, è ancu u callback_url, chì cuntene a chjave di emissione - hè utilizatu per callback in HTTP.
Per ogni lanciamentu, hè generatu un inventariu temporale, custituitu da un òspite è u gruppu à quale appartene stu òspite, cusì chì group_vars sò applicati.
Eccu un esempiu di un compitu chì implementa HTTP callback.
Avemu u risultatu di eseguisce playbooks cù callaback (s). Sò di dui tipi:
- , furnisce dati nantu à i risultati di l'esekzione di playbook. Descrive i travaglii chì sò stati lanciati, cumpleti cù successu o senza successu. Stu callback hè chjamatu quandu u playbook hà finitu di ghjucà.
- Callback HTTP per riceve informazioni mentre ghjucate un playbook. In u compitu Ansible eseguimu una dumanda POST / GET à a nostra applicazione.
I variàbili sò passati attraversu HTTP callback(s) chì sò stati definiti durante l'esekzione di u playbook è chì vulemu salvà è aduprà in eseguite successive. Scrivemu questi dati in sqlite.
Lascemu ancu cumenti è cambiate u statutu di u bigliettu via HTTP callback.
HTTP callback
# 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
Cum'è parechji travaglii di u listessu tipu, l'avemu messi in un schedariu cumuni separatu è l'includemu se ne necessariu, per ùn ripetiri constantemente in playbooks. Questu include u callback_ url, chì cuntene a chjave di prublema è u nome di l'ospitu. Quandu Ansible eseguisce sta dumanda POST, u bot capisce chì hè vinutu cum'è parte di tali incidenti.
È quì hè un esempiu da u playbook, in quale avemu un discu da un dispositivu MD:
# Save mdadm configuration
- include: common/callback.yml
vars:
callback_post_body:
status: 'Ready to change'
msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
data:
mdadm_data: "{{ mdadm_remove_disk.removed }}"
parted_info: "{{ parted_info | default() }}"
when:
- mdadm_remove_disk | changed
- mdadm_remove_disk.removed
Stu compitu trasferisce u bigliettu Jira à u statutu "Pronta à cambià" è aghjunghje un cumentu. Inoltre, a variàbile mdam_data guarda una lista di i dispositi md da quale u discu hè statu sguassatu, è parted_info guarda una partizione dump da parted.
Quandu l'ingegnere inserisce un novu discu, pudemu usà sti variàbili per restaurà u dump di partizione, è ancu inserisce u discu in i dispositi md da quale hè stata eliminata.
Modu di cuntrollu Ansible
Era paura di accende l'automatizazione. Dunque, avemu decisu di eseguisce tutti i playbooks in u modu
, in quale Ansible ùn eseguisce micca azzione nantu à i servitori, ma solu l'emulate.
Un tali lanciamentu hè gestitu attraversu un modulu di callback separatu, è u risultatu di l'esekzione di u playbook hè salvatu in Jira cum'è un cumentu.
Prima, questu hà permessu di cunvalidà u travagliu di u bot è i playbooks. Siconda, hà aumentatu a fiducia di l'amministratori in u bot.
Quandu avemu passatu a validazione è hà realizatu chì pudete eseguisce Ansible micca solu in u modu di corsa secca, avemu fattu un buttone Run Diskobot in Jira per lancià u listessu playbook cù e stesse variabili nantu à u stessu òspite, ma in modu normale.
Inoltre, u buttone hè utilizatu per riavvia u playbook s'ellu si falla.
Struttura di playbooks
Aghju digià dettu chì sicondu u statutu di u bigliettu Jira, u bot lancia diversi playbooks.
Prima, hè assai più faciule d'urganizà l'entrata.
Siconda, in certi casi hè solu necessariu.
Per esempiu, quandu si rimpiazza un discu di u sistema, prima avete bisognu à andà à u sistema di implementazione, creanu un compitu, è dopu a implementazione curretta, u servitore diventerà accessibile via ssh, è pudete sparghje l'applicazione nantu à questu. Se avemu fattu tuttu questu in un libru di ghjocu, allora Ansible ùn puderia micca compie perchè l'ospite ùn hè micca dispunibule.
Utilizemu roli Ansible per ogni gruppu di servitori. Quì pudete vede cumu u playbook (s) sò urganizati in unu di elli.
Questu hè cunvenutu perchè hè immediatamente chjaru induve si trovanu i travaglii. In main.yml, chì hè l'input per u rolu Ansible, pudemu simpricimenti includenu da u statutu di u bigliettu o compiti generali necessarii per tutti, per esempiu, passendu identificazione o riceve un token.
investigazione.yml
Corsa per i biglietti in u Statu di Investigazione è Apertu. A cosa più impurtante per questu playbook hè u nome di u dispositivu di bloccu. Sta infurmazione ùn hè micca sempre dispunibule.
Per uttene, analizemu u summariu di Jira, l'ultimu valore da u trigger Zabbix. Si pò cuntene u nome di u dispusitivu bluccatu - furtunatu. O pò cuntene un puntu di muntagna, allora avete bisognu à andà à u servitore, analizà è calculà u discu necessariu. U trigger pò ancu trasmette un indirizzu scsi o qualchì altra infurmazione. Ma succede ancu chì ùn ci hè micca indizi, è avete da analizà.
Dopu avè scupertu u nome di u dispositivu di bloccu, raccogliemu infurmazioni nantu à u tipu è a dimensione di u discu da ellu per riempie i campi in Jira. Avemu ancu sguassate l'infurmazioni nantu à u venditore, mudellu, firmware, ID, SMART, è inserisce tuttu questu in un cumentu in u bigliettu Jira. L'amministratore è l'ingegneru ùn anu più bisognu di circà sta dati. 🙂
prepare2change.yml
Eliminazione di u discu da a rotazione, preparanu per a sustituzione. U stadiu più difficiule è impurtante. Questu hè induve pudete piantà l'applicazione quandu ùn deve esse fermata. O caccià un discu chì ùn hà micca abbastanza rèpliche, è cusì avè un effettu nantu à l'utilizatori, perdendu qualchi dati. Quì avemu a maiò parte di cuntrolli è notificazioni in u chat.
In u casu più simplice, parlemu di sguassà un discu da un RAID HW / MD.
In situazioni più cumplessi (in i nostri sistemi di almacenamento), quandu a copia di salvezza hè realizata à u livellu di l'applicazione, avete bisognu à andà à l'applicazione per via di l'API, rappurtate l'output di u discu, disattivà è cuminciate a ricuperazione.
Avà migremu in massa , è se u servitore hè basatu in nuvola, allora Diskobot chjama l'API di nuvola, dice chì hà da travaglià cù questu minion - u servitore chì esegue cuntenituri - è dumanda "migrate tutti i cuntenituri da questu minion". È à u stessu tempu, accende a retroilluminazione di u discu per chì l'ingegnere pò immediatamente vede quale deve esse tiratu fora.
cambiatu.yml
Dopu avè rimpiazzatu un discu, avemu prima verificatu a so dispunibilità.
L'ingegneri ùn sò micca sempre installati novi unità, cusì avemu aghjustatu un cuntrollu per i valori SMART chì ci soddisfanu.
Chì attributi guardemu?Conte di Settori Riallocati (5) < 100
Conte attuale di u settore pendente (107) == 0
Se l'unità falla a prova, l'ingegnere hè notificatu per rimpiazzà di novu. Se tuttu hè in ordine, a retroilluminazione si spegne, i marcati sò appiicati è u discu hè messu in rotazione.
prontu.yml
U casu più simplice: cuntrollà a sincronizazione di raid HW / SW o finisce a sincronizazione di dati in l'applicazione.
API di l'applicazione
Aghju citatu parechje volte chì u bot accede spessu à l'API di l'applicazione. Di sicuru, micca tutte l'applicazioni avianu i metudi necessarii, per quessa, anu da esse mudificate. Eccu i metudi più impurtanti chì usemu:
- Status. Status di un cluster o discu per capisce s'ellu pò esse travagliatu;
- Start / stop. Attivazione / disattivazione di u discu;
- Migrate / risturà. Migrazione di dati è ricuperazione durante è dopu a sustituzione.
Lezioni amparate da Ansible
Amu veramente Ansible. Ma spessu, quandu mi fighjulà diversi prughjetti opensource è vede cumu a ghjente scrive libri di ghjocu, aghju un pocu paura. Intrecciamenti logici cumplessi di quandu / loop, mancanza di flessibilità è idempotenza per l'usu frequente di shell / cumanda.
Avemu decisu di simplificà tuttu u più pussibule, apprufittannu di u vantaghju di Ansible - modularità. À u più altu livellu ci sò playbooks; ponu esse scritti da qualsiasi amministratore, sviluppatore di terzu chì cunnosci un pocu Ansible.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Se una certa logica hè difficiuli di implementà in i playbooks, u movemu in un modulu o filtru Ansible. I script ponu esse scritti in Python o qualsiasi altra lingua.
Sò faciuli è veloci à scrive. Per esempiu, u modulu di retroilluminazione di discu, un esempiu di quale hè mostratu sopra, hè custituitu da 265 linee.
À u livellu più bassu hè a biblioteca. Per stu prughjettu, avemu scrittu una applicazione separata, un tipu di astrazione nantu à i RAID di hardware è software chì realizanu e dumande currispondenti.
I più grandi punti di forza di Ansible sò a so simplicità è i playbooks chjaru. Credu chì avete bisognu di utilizà questu è micca generà fugliali yaml spaventosi è un gran numaru di cundizioni, codice di shell è loops.
Se vulete ripetiri a nostra sperienza cù l'API Ansible, tenete in mente duie cose:
- Playbook_executor è playbooks in generale ùn pò micca esse datu un timeout. Ci hè un timeout in a sessione ssh, ma ùn ci hè micca timeout in u playbook. Se pruvemu di smontà un discu chì ùn esiste più in u sistema, u playbook correrà senza fine, per quessa, avemu avutu à imballà u so lanciamentu in un wrapper separatu è tumbà cù un timeout.
- Ansible corre nantu à i prucessi forked, cusì a so API ùn hè micca sicura. Eseguimu tutti i nostri playbooks single-threaded.
In u risultatu, pudemu automatizà a sustituzione di circa 80% di dischi. In generale, a tarifa di rimpiazzamentu hè radduppiata. Oghje, l'amministratore solu guarda l'incidentu è decide se u discu deve esse cambiatu o micca, è poi face un clic.
Ma avà avemu principiatu à curriri in un altru prublema: certi novi amministratori ùn sanu micca cumu cambià unità. 🙂
Source: www.habr.com