Ciao a tutti. Lavoro come amministratore di sistema senior in OK e sono responsabile del funzionamento stabile del portale. Voglio raccontarvi come abbiamo costruito il processo di sostituzione automatica dei dischi e poi come abbiamo escluso l'amministratore da questo processo, sostituendolo con un bot.
Questo articolo è una sorta di traslitterazione a HighLoad+ 2018
Costruzione del processo di sostituzione dei dischi
Iniziamo con un po' di numeri
OK è un servizio enorme che viene utilizzato da milioni di persone. È sostenuto da circa 7.000 server, situati in 4 diversi data center. Nei server ci sono più di 70.000 dischi. Se li sovrapponiamo, si ottiene una torre alta più di 1 km.
I dischi rigidi sono il componente del server che si guasta più frequentemente. Con questi volumi, ci troviamo a dover cambiare circa 30 dischi a settimana, e questa procedura è diventata una routine piuttosto sgradevole.
Incidenti
Nella nostra azienda è stato implementato un completo gestione degli incidenti. Ogni incidente viene registrato in Jira e poi risolto e analizzato. Se l'incidente ha avuto un impatto sugli utenti, ci riuniamo per discutere come reagire più rapidamente in tali casi, come ridurre l'impatto e, naturalmente, come prevenire il ripetersi.
I dispositivi di memorizzazione non fanno eccezione. La loro condizione è monitorata da Zabbix. Monitoriamo i messaggi in Syslog per errori di scrittura/lettura, analizziamo lo stato dei RAID HW/SW, teniamo d'occhio SMART, calcoliamo l'usura per gli SSD.
Come venivano cambiati i dischi in passato
Quando in Zabbix si attiva un trigger, viene creato un incidente in Jira e assegnato automaticamente agli ingegneri responsabili nei data center. Lo facciamo per tutti gli incidenti HW, cioè quelli che richiedono qualche lavoro fisico con l'hardware nel data center.
L'ingegnere del data center è la persona che gestisce le questioni relative all'hardware, è responsabile dell'installazione, della manutenzione e dello smantellamento dei server. Una volta ricevuto il ticket, l'ingegnere inizia a lavorare. Nelle scaffalature dei dischi, sostituisce i dischi da solo. Ma se non ha accesso all'apparecchiatura necessaria, l'ingegnere si rivolge agli amministratori di sistema di turno per assistenza. Prima di tutto, è necessario escludere il disco dalla rotazione. Per fare ciò, è necessario apportare le modifiche necessarie sul server, fermare le applicazioni e smontare il disco.
L'amministratore di sistema di turno è responsabile del funzionamento dell'intero portale durante il proprio turno di lavoro. Indaga sugli incidenti, esegue riparazioni e assiste gli sviluppatori nell'esecuzione di piccoli compiti. Non si occupa solo dei dischi rigidi.
In passato, gli ingegneri dei data center comunicavano con l'amministratore di sistema tramite chat. Gli ingegneri inviavano link ai ticket di Jira, l'amministratore li esaminava e registrava il lavoro su un taccuino. Tuttavia, per tali compiti le chat risultavano poco pratiche: le informazioni non erano strutturate e si perdevano rapidamente. Inoltre, l'amministratore poteva semplicemente allontanarsi dal computer e non rispondere alle richieste per un certo periodo, mentre l'ingegnere era davanti al server con un pacchetto di dischi e aspettava.
Ma la cosa peggiore era che gli amministratori non vedevano l'intero quadro: quali incidenti riguardavano i dischi esistenti e dove potrebbe sorgere un problema. Questo è dovuto al fatto che tutti gli incidenti hardware vengono gestiti dagli ingegneri. Certo, si potrebbe visualizzare tutti gli incidenti sul dashboard dell'amministratore. Ma ce ne sono davvero troppi e l'amministratore veniva coinvolto solo in alcuni di essi.
Inoltre, l'ingegnere non poteva stabilire correttamente le priorità, poiché non sapeva nulla riguardo allo scopo dei singoli server o alla distribuzione delle informazioni tra i dispositivi di archiviazione.
Nuova procedura di sostituzione
La prima cosa che abbiamo fatto è stata creare un tipo separato di incidente per tutti gli incidenti riguardanti i dischi denominato "HW-disco" e aggiungere ai ticket i campi "nome del dispositivo a blocchi", "dimensione" e "tipo di disco", affinché queste informazioni fossero conservate nel ticket e non dovessimo continuamente scambiarle nella chat.
Abbiamo inoltre concordato che all'interno di un singolo incidente sostituiremo solo un disco. Questo ha semplificato notevolmente il processo di automazione, la raccolta delle statistiche e il lavoro futuro.
Inoltre, abbiamo aggiunto il campo "amministratore responsabile". Qui viene automaticamente inserito l'amministratore di sistema di turno. Questo è molto comodo, perché ora l'ingegnere vede sempre chi è il responsabile. Non è necessario consultare il calendario e cercare. Proprio grazie a questo campo, è stato possibile visualizzare nel dashboard dell'amministratore i ticket in cui potrebbe esserci bisogno del suo aiuto.
Affinché tutti i partecipanti potessero trarne il massimo beneficio dalle novità introdotte, abbiamo creato filtri e dashboard, e abbiamo spiegato loro il funzionamento. Quando le persone comprendono i cambiamenti, non si distaccano da essi come se si trattasse di qualcosa di superfluo. Per un ingegnere è importante conoscere il numero del rack in cui si trova il server, le dimensioni e il tipo di disco. Un amministratore deve, prima di tutto, capire che tipo di gruppo di server ha a che fare e quale potrebbe essere l'effetto della sostituzione del disco.
Avere campi e la loro visualizzazione è conveniente, ma non ci ha liberato dalla necessità di utilizzare le chat. A tale scopo, è stato necessario modificare il processo lavorativo.
Prima era così:
Oggi gli ingegneri continuano a lavorare in questo modo quando non hanno bisogno dell'assistenza di un amministratore.
La prima cosa che abbiamo fatto è stata introdurre un nuovo stato Investigate. In questo stato si trova il ticket quando l'ingegnere non ha ancora deciso se avrà bisogno di un amministratore o meno. Attraverso questo stato, l'ingegnere può trasferire il ticket all'amministratore. Inoltre, utilizziamo questo stato per contrassegnare i ticket in cui è necessaria la sostituzione del disco, ma il disco stesso non è disponibile sul sito. Questo può verificarsi nel caso di CDN e siti remoti.
Abbiamo anche aggiunto lo stato Pronto. In questo stato, il ticket viene trasferito dopo la sostituzione del disco. Ovvero, tutto è già stato fatto, ma sul server HW/SW RAID è in fase di sincronizzazione. Questo può richiedere abbastanza tempo.
Se l'amministratore è coinvolto nel lavoro, lo schema si complica leggermente.
Dallo stato Apri il ticket può essere trasferito sia dall'amministratore di sistema che dall'ingegnere. Nello stato In progress l'amministratore estrae il disco dalla rotazione affinché l'ingegnere possa semplicemente estrarlo: accende la luce, smonta il disco, ferma le applicazioni, a seconda del gruppo specifico di server.
Successivamente, il ticket viene trasferito a Ready to change: questo è un segnale per l'ingegnere che il disco può essere rimosso. Tutti i campi in Jira sono già stati compilati, e l'ingegnere sa quale tipo e dimensione di disco è richiesto. Questi dati vengono inseriti automaticamente nello stato precedente o dall'amministratore.
Dopo la sostituzione del disco, il ticket viene trasferito allo stato Changed. Viene verificato che sia stato inserito il disco giusto, si esegue la configurazione, si avvia l'applicazione e si eseguono alcune operazioni per il recupero dei dati. Inoltre, il ticket può essere trasferito allo stato Pronto, in questo caso la responsabilità rimane all'amministratore, poiché è stato lui a introdurre il disco nella rotazione. Lo schema completo è il seguente.
L'aggiunta di nuovi campi ha notevolmente semplificato la nostra vita. I ragazzi hanno iniziato a lavorare con informazioni strutturate, ed è diventato chiaro cosa e quando deve essere fatto. Le priorità sono diventate molto più pertinenti, poiché ora vengono impostate dall'amministratore.
Non c'è più bisogno di chat. Certo, l'amministratore può scrivere all'ingegnere "qui è necessario sostituire più velocemente", o "è già sera, riuscirai a sostituire?". Ma non comunichiamo più quotidianamente in chat riguardo a queste questioni.
I dischi sono stati cambiati a gruppi. Se l'amministratore arriva al lavoro un po' prima, ha del tempo libero, e non è successo nulla, può preparare una serie di server per la sostituzione: impostare i campi, rimuovere i dischi dalla rotazione e trasferire il compito all'ingegnere. L'ingegnere arriva un po' più tardi nel data center, vede il compito, prende i dischi necessari dal magazzino e li sostituisce immediatamente. Di conseguenza, la velocità di sostituzione è aumentata.
Esperienza acquisita nella costruzione del Workflow
- Nella costruzione della procedura è necessario raccogliere informazioni da diverse fonti.
Alcuni dei nostri amministratori non sapevano che l'ingegnere sostituisce i dischi da solo. Alcuni pensavano che la sincronizzazione del RAID MD fosse gestita da ingegneri, anche se alcuni di loro non avevano accesso per farlo. Alcuni ingegneri senior lo facevano, ma non sempre, perché il processo non era descritto da nessuna parte. - La procedura deve essere semplice e chiara.
È difficile per una persona tenere a mente numerosi passaggi. Gli stati più importanti e vicini in Jira devono essere visualizzati sulla schermata principale. Possono essere rinominati, ad esempio, In progress lo chiamiamo Pronto per cambiare. Altri stati possono essere nascosti nel menu a discesa, in modo che non diano fastidio. Ma è meglio non limitare le persone, dare loro la possibilità di fare la transizione.
Spiega il valore delle novità. Quando le persone capiscono, accettano meglio la nuova procedura. Per noi era molto importante che le persone non cliccassero su tutto il processo, ma lo seguissero. Successivamente abbiamo costruito su questo l'automazione. - Aspettare, analizzare, capire.
Ci sono voluti circa un mese per costruire la procedura, la realizzazione tecnica, incontri e discussioni. E per l'implementazione — più di tre mesi. Ho visto come le persone iniziano gradualmente a utilizzare la novità. Nelle fasi iniziali c'era molto scetticismo. Ma questo non dipendeva affatto dalla procedura in sé, dalla sua realizzazione tecnica. Ad esempio, un amministratore utilizzava non Jira, ma un plugin di Jira in Confluence, e alcune cose non erano per lui disponibili. Gli abbiamo mostrato Jira, e la produttività dell'amministratore è aumentata sia nei compiti generali sia nelle sostituzioni dei dischi.
Automazione della sostituzione dei dischi
Ci siamo avvicinati all'automazione della sostituzione dei dischi più volte. Avevamo già realizzato script, ma tutti funzionavano o in modalità interattiva o manuale, richiedevano un avvio. Solo dopo l'implementazione della nuova procedura abbiamo capito che proprio questo ci mancava.
Ora che il processo di sostituzione è suddiviso in fasi, ognuna con un esecutore designato e un elenco di azioni, possiamo implementare l'automazione progressivamente, invece di farlo tutto in una volta. Ad esempio, la fase più semplice — Ready (verifica della sincronizzazione RAID/dati) può essere facilmente delegata a un bot. Quando il bot avrà acquisito un po' di esperienza, possiamo affidargli compiti più complessi — come l'introduzione del disco in rotazione, ecc.
Zoo di configurazioni
Prima di parlare del bot, facciamo un breve excursus nel nostro zoo di installazioni. Prima di tutto, ciò è dovuto alle dimensioni enormi della nostra infrastruttura. In secondo luogo, cerchiamo di abbinare una configurazione hardware ottimale per ogni servizio. Abbiamo circa 20 modelli di RAID hardware, principalmente LSI e Adaptec, ma ci sono anche HP e DELL di varie versioni. Ogni controller RAID ha il proprio strumento di gestione. Il set di comandi e l'output possono variare da versione a versione per ogni controller RAID. Dove non vengono utilizzati HW-RAID, potrebbe esserci mdraid.
Praticamente tutte le nuove installazioni vengono effettuate senza riserva di disco. Cerchiamo di non utilizzare più RAID hardware e software, poiché riserviamo i nostri sistemi a livello di data center, non di server. Ma ci sono molti server legacy che devono essere supportati.
In alcuni casi, i dischi nei controller RAID vengono utilizzati come dispositivi raw, in altri si utilizza JBOD. Ci sono configurazioni con un singolo disco di sistema nel server, e se deve essere sostituito, è necessario reinstallare il server con il sistema operativo e le applicazioni, inclusi gli stessi versioni, poi aggiungere i file di configurazione e avviare le applicazioni. Ci sono anche molti gruppi di server, in cui il backup avviene non a livello del sottosistema disco, ma direttamente nelle stesse applicazioni.
In totale, abbiamo oltre 400 gruppi unici di server, su cui funzionano circa 100 diverse applicazioni. Per coprire una così vasta gamma di varianti, avevamo bisogno di uno strumento di automazione multifunzionale. Preferibilmente con un DSL semplice, in modo che potesse essere mantenuto anche da chi non l'ha scritto.
Abbiamo scelto Ansible perché è agentless: non era necessario preparare l'infrastruttura, avvio rapido. Inoltre, è scritto in Python, che è considerato uno standard nel team.
Schema generale
Diamo un'occhiata allo schema generale di automazione prendendo come esempio un incidente. Zabbix rileva che il disco sdb è guasto, si attiva un trigger, viene creato un ticket in Jira. L'amministratore lo controlla, capisce che non è un duplicato o un false positive, cioè che il disco deve essere sostituito, e trasferisce il ticket in In progress.
L'applicazione DiskoBot, scritta in Python, interroga periodicamente Jira per nuovi ticket. Nota che è apparso un nuovo ticket In progress, si attiva il thread corrispondente, che avvia il playbook in Ansible (questo viene fatto per ogni stato in Jira). In questo caso viene avviato Prepare2change.
Ansible viene inviato all'host, estrae il disco dalla rotazione e riporta lo stato all'applicazione tramite Callbacks.
In base ai risultati, il bot trasferisce automaticamente il ticket in Ready to change. L'ingegnere riceve una notifica e si prepara a sostituire il disco, dopodiché trasferisce il ticket in Changed.
Secondo lo schema sopra descritto, il ticket torna al bot, che avvia un altro playbook, si connette all'host e reinserisce il disco nella rotazione. Il bot chiude il ticket. Evviva!
Ora parliamo di alcuni componenti del sistema.
Diskobot
Questa applicazione è scritta in Python. Seleziona ticket da Jira in base a JQL. A seconda dello stato del ticket, esso viene inviato al corrispondente gestore, il quale a sua volta avvia il playbook Ansible corrispondente allo stato.
JQL e gli intervalli di interrogazione sono definiti nel file di configurazione dell'applicazione.
jira_states:
investigate:
jql: '… stato = Aperto e "Dimensione Disco" è VUOTO'
interval: 180
inprogress:
jql: '… e "Dimensione Disco" non è VUOTO e "Nome Dispositivo" non è VUOTO'
ready:
jql: '… e (etichette non in ("dbot_ignore") o etichette è VUOTO)'
interval: 7200
Ad esempio, tra i ticket nello stato In progress, vengono selezionati solo quelli in cui sono compilati i campi Dimensione disco e Nome dispositivo. Nome dispositivo è il nome del dispositivo a blocchi necessario per eseguire il playbook. Dimensione disco è necessaria affinché l'ingegnere sappia che dimensione di disco è necessario.
E tra i ticket con stato Ready vengono filtrati i ticket con etichetta dbot_ignore. A proposito, utilizziamo le etichette di Jira sia per tale filtraggio che per contrassegnare i ticket duplicati e raccogliere statistiche.
In caso di errore del playbook, Jira assegna l'etichetta dbot_failed in modo da poter esaminare in seguito.
Interazione con Ansible
L'applicazione interagisce con Ansible tramite . Nel playbook_executor passiamo il nome del file e un insieme di variabili. Questo consente di mantenere il progetto Ansible in forma di normali file yml, invece di descriverlo in codice Python.
Inoltre, in Ansible tramite *extra_vars* vengono passati il nome del dispositivo a blocchi, lo stato del ticket, e anche callback_url, in cui è incorporato il chiave dell'issue — che viene utilizzato per la callback in HTTP.
Per ogni esecuzione viene generato un inventario temporaneo, composto da un singolo host e un gruppo che include questo host, affinché vengano applicati group_vars.
Ecco un esempio di task in cui è implementato il callback HTTP.
I risultati dell'esecuzione dei playbook vengono ottenuti tramite callback(-s). Questi sono di due tipi:
- , fornisce dati sui risultati dell'esecuzione del playbook. Descrive i task che sono stati avviati, completati con successo o meno. Questo callback viene chiamato al termine dell'esecuzione del playbook.
- Callback HTTP per ottenere informazioni durante l'esecuzione del playbook. Nel task Ansible eseguiamo una richiesta POST/GET verso la nostra applicazione.
Tramite i callback HTTP vengono passate le variabili che sono state definite durante l'esecuzione del playbook e che vogliamo conservare e utilizzare nei successivi run. Questi dati vengono scritti in sqlite.
Inoltre, attraverso il callback HTTP lasciamo commenti e cambiamo lo stato del ticket.
Callback HTTP
# 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
Come molte altre attività simili, l'abbiamo estratto in un file comune e lo includiamo se necessario, per non ripeterlo continuamente nei playbook. Qui figura il callback_url, in cui sono incorporati la chiave del problema e il nome dell'host. Quando Ansible esegue questa richiesta POST, il bot comprende che è arrivata nell'ambito di un certo incidente.
Ecco un esempio da un playbook in cui abbiamo espulso un disco dall'unità 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
Questo compito trasforma il ticket Jira nello stato "Pronto per il cambio" e aggiunge un commento. Inoltre, nella variabile mdam_data viene salvato l'elenco dei dispositivi md da cui è stato rimosso il disco, mentre in parted_info si trova il dump della partizione da parted.
Quando l'ingegnere inserisce un nuovo disco, possiamo utilizzare queste variabili per ripristinare il dump delle partizioni e anche per registrare il disco nelle unità md da cui è stato rimosso.
Modalità di controllo Ansible
Era spaventoso attivare l'automazione. Quindi abbiamo deciso di eseguire tutti i playbook in modalità
, in cui Ansible non esegue alcuna azione sui server, ma semplicemente le emula.
Tale esecuzione viene gestita tramite un modulo di callback separato e il risultato dell'esecuzione del playbook viene salvato in Jira sotto forma di commento.
Innanzitutto, questo ha permesso di convalidare il funzionamento del bot e dei playbook. In secondo luogo, ha aumentato la fiducia degli amministratori nel bot.
Una volta che abbiamo superato la convalida e capito che si poteva eseguire Ansible non solo in modalità dry run, abbiamo creato in Jira il pulsante Esegui Diskobot per avviare lo stesso playbook con le stesse variabili sullo stesso host, ma in modalità normale.
Inoltre, il pulsante viene utilizzato per rieseguire il playbook in caso di fallimento.
Struttura dei Playbook
Ho già accennato che a seconda dello stato del ticket Jira, il bot avvia diversi playbook.
In primo luogo, così è molto più semplice organizzare l'ingresso.
In secondo luogo, in alcuni casi è semplicemente necessario.
Ad esempio, durante la sostituzione di un disco di sistema, è necessario prima accedere al sistema di distribuzione, creare un'attività e, dopo una distribuzione corretta, il server diventa accessibile tramite ssh e possiamo installare l'applicazione. Se avessimo fatto tutto ciò in un unico playbook, Ansible non sarebbe riuscito a eseguirlo a causa dell'inaccessibilità dell'host.
Utilizziamo i ruoli Ansible per ogni gruppo di server. Qui si può vedere come sono organizzati i playbook in uno di essi.
È comodo perché è subito chiaro dove sono collocati i vari task. In main.yml, che è l'input per il ruolo Ansible, possiamo avere semplicemente un'include in base allo stato del ticket o task generali necessari per tutti, come l'identificazione o il recupero del token.
Investigation.yml
Viene avviato per i ticket negli stati Investigation e Open. La cosa più importante per questo playbook è il nome del dispositivo di blocco. Questa informazione non è sempre disponibile.
Per ottenerla analizziamo il riassunto di Jira, l'ultimo valore dal trigger di Zabbix. Potrebbe contenere il nome del dispositivo di blocco — fortuna. Potrebbe contenere anche il mount point, in tal caso bisogna andare sul server, analizzarlo e calcolare il disco necessario. Inoltre, il trigger potrebbe fornire l'indirizzo scsi o qualche altra informazione. Ma a volte non ci sono indizi e bisogna analizzare.
Una volta scoperto il nome del dispositivo di blocco, raccogliamo informazioni su tipo e dimensione del disco per riempire i campi in Jira. Recuperiamo inoltre informazioni sul venditore, modello, firmware, ID, SMART e inseriamo tutto ciò nel commento del ticket Jira. L'amministratore e l'ingegnere non devono più cercare questi dati. 🙂
prepare2change.yml
Uscita del disco dalla rotazione, preparazione alla sostituzione. La fase più complessa e delicata. Proprio qui si può fermare un'applicazione quando non dovrebbe essere fermata. Oppure estrarre un disco che non ha abbastanza repliche, influenzando così gli utenti e perdendo alcuni dati. Qui abbiamo il maggior numero di controlli e notifiche in chat.
Nel caso più semplice, si tratta della rimozione del disco da HW/MD RAID.
In situazioni più complesse (nei nostri sistemi di archiviazione), quando la mutua è effettuata a livello applicativo, è necessario andare all'applicazione via API, informare dell'uscita del disco, disattivarlo e avviare il ripristino.
Stiamo attualmente migrando massivamente in , e se il server è nel cloud, Diskobot si rivolge all'API del cloud, comunica che intende lavorare con questo minion — il server su cui sono in esecuzione i container — e chiede "migra tutti i container da questo minion". E accende anche l'illuminazione del disco, così l'ingegnere vede subito quale deve rimuovere.
changed.yml
Dopo la sostituzione del disco, controlliamo innanzitutto la sua disponibilità.
Gli ingegneri non installano sempre nuovi dischi, quindi abbiamo aggiunto un controllo sui valori SMART che ci soddisfano.
Quali attributi stiamo esaminandoConteggio settori riallocati (5) < 100
Conteggio settori in attesa (107) == 0
Se il disco non supera il controllo, l'ingegnere viene informato per una sostituzione. Se tutto è a posto, la luce si spegne, vengono effettuate le marcature e il disco viene inserito in rotazione.
ready.yml
Il caso più semplice: verifica della sincronizzazione tra HW/SW raid o conclusione della sincronizzazione dei dati nell'app.
API delle applicazioni
Ho menzionato più volte che il bot accede frequentemente alle API delle applicazioni. Certamente, non tutte le applicazioni avevano i metodi necessari, quindi è stato necessario svilupparli. Ecco i metodi più importanti che utilizziamo:
- Status. Stato del cluster o del disco, per capire se è possibile lavorare con esso;
- Start/stop. Attivazione/disattivazione del disco;
- Migrate/restore. Migrazione e ripristino dei dati durante e dopo la sostituzione.
Esperienza acquisita su Ansible
Amo molto Ansible. Ma spesso, quando guardo diversi progetti open source e vedo come le persone scrivono playbook, mi sento un po' spaventato. Complessi intrecci logici di when/loop, mancanza di flessibilità e idempotenza a causa del frequente utilizzo di shell/command.
Abbiamo deciso di semplificare tutto il più possibile, sfruttando i vantaggi di Ansible: la modularità. Al livello più alto ci sono i playbook, che possono essere scritti da qualsiasi amministratore, sviluppatore esterno che conosce un po' Ansible.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Se qualche logica è difficile da implementare nei playbook, la spostiamo in un modulo o filtro Ansible. Gli script possono essere scritti sia in Python che in qualsiasi altra lingua.
Sono facili e veloci da scrivere. Ad esempio, il modulo di indicazione del disco, il cui esempio d'uso è stato fornito sopra, consiste di 265 righe.
Al livello più basso c'è la libreria. Per questo progetto abbiamo scritto un'applicazione separata, una sorta di astrazione sopra RAID hardware e software, che esegue le richieste appropriate.
I punti di forza di Ansible sono la semplicità e i playbook chiari. Credo sia utile sfruttarli e non generare terribili file yaml e un'enorme quantità di condizioni, codice shell e loop.
Se desiderate ripetere la nostra esperienza con Ansible API, tenete presente due cose:
- Non è possibile passare un timeout a playbook_executor e in generale al playbook. C'è un timeout per le sessioni SSH, ma non c'è un timeout per il playbook. Se proviamo a smontare un disco che non esiste più nel sistema, il playbook continuerà a essere eseguito all'infinito, quindi è stato necessario racchiudere il suo avvio in un wrapper separato e terminare il tutto in base al timeout.
- Ansible si basa su processi fork, quindi la sua API non è thread-safe. Eseguiamo tutti i nostri playbook in modalità single-thread.
In definitiva, siamo riusciti ad automatizzare la sostituzione di circa l'80% dei dischi. In generale, la velocità di sostituzione è raddoppiata. Oggi l'amministratore deve solo dare un'occhiata all'incidente e decidere se sostituire il disco oppure no, per poi effettuare un clic.
Ma ora stiamo iniziando a incontrare un altro problema: alcuni nuovi amministratori non sanno come sostituire i dischi. 🙂
Fonte: habr.com
