Automatisering af diskudskiftning med Ansible

Hej alle. Jeg arbejder som ledende systemadministrator hos OK og er ansvarlig for den stabile drift af portalen. Jeg vil gerne tale om, hvordan vi byggede en proces til automatisk udskiftning af diske, og derefter hvordan vi udelukkede administratoren fra denne proces og erstattede ham med en bot.

Denne artikel er en slags translitteration forestillinger på HighLoad+ 2018

Opbygning af en diskudskiftningsproces

Først nogle tal

OK er en gigantisk tjeneste, der bruges af millioner af mennesker. Det betjenes af omkring 7 tusinde servere, som er placeret i 4 forskellige datacentre. Serverne indeholder mere end 70 tusinde diske. Stabler man dem oven på hinanden, får man et tårn mere end 1 km højt.

Harddiske er den serverkomponent, der oftest fejler. Med sådanne mængder skal vi skifte omkring 30 diske om ugen, og denne procedure er blevet en ikke særlig behagelig rutine.

Hændelser

Vores virksomhed har indført fuldgyldig hændelseshåndtering. Vi registrerer hver hændelse i Jira og løser og ordner det derefter. Hvis en hændelse havde en effekt på brugerne, så tager vi helt sikkert sammen og tænker over, hvordan man reagerer hurtigere i sådanne tilfælde, hvordan man reducerer effekten og selvfølgelig hvordan man forebygger en gentagelse.

Lagerenheder er ingen undtagelse. Deres status overvåges af Zabbix. Vi overvåger meddelelser i Syslog for skrive-/læsefejl, analyserer status for HW/SW-raids, overvåger SMART og beregner slid for SSD'er.

Hvordan diske blev ændret før

Når en trigger opstår i Zabbix, oprettes en hændelse i Jira og tildeles automatisk til de relevante ingeniører i datacentrene. Det gør vi med alle HW-hændelser, det vil sige dem, der kræver noget fysisk arbejde med udstyr i datacentret.
En datacenteringeniør er en person, der løser problemer relateret til hardware og er ansvarlig for at installere, vedligeholde og afmontere servere. Efter at have modtaget billetten går ingeniøren på arbejde. I diskhylder skifter han diske uafhængigt. Men hvis han ikke har adgang til den nødvendige enhed, henvender ingeniøren sig til de vagthavende systemadministratorer for at få hjælp. Først og fremmest skal du fjerne disken fra rotation. For at gøre dette skal du foretage de nødvendige ændringer på serveren, stoppe programmer og afmontere disken.

Vagthavende systemadministrator er ansvarlig for driften af ​​hele portalen i arbejdsvagten. Han efterforsker hændelser, laver reparationer og hjælper udviklere med at udføre små opgaver. Han beskæftiger sig ikke kun med harddiske.

Tidligere kommunikerede datacenteringeniører med systemadministratoren via chat. Ingeniører sendte links til Jira-billetter, administratoren fulgte dem, førte en log over arbejdet i en notesblok. Men chats er ubelejlige til sådanne opgaver: informationen der er ikke struktureret og går hurtigt tabt. Og administratoren kunne simpelthen gå væk fra computeren og ikke svare på forespørgsler i nogen tid, mens ingeniøren stod ved serveren med en stak diske og ventede.

Men det værste var, at administratorerne ikke så hele billedet: hvilke diskhændelser der fandtes, hvor der potentielt kunne opstå et problem. Dette skyldes, at vi uddelegerer alle HW-hændelser til ingeniører. Ja, det var muligt at få vist alle hændelser på administratorens dashboard. Men der er mange af dem, og administratoren var kun involveret for nogle af dem.

Derudover kunne ingeniøren ikke prioritere korrekt, fordi han ikke ved noget om formålet med specifikke servere eller distributionen af ​​information mellem drev.

Ny udskiftningsprocedure

Det første, vi gjorde, var at flytte alle diskhændelser til en separat type "HW-disk" og tilføjede felterne "blok enhedsnavn", "størrelse" og "disktype" til den, så disse oplysninger ville blive gemt i billetten og ville ikke konstant at udveksle i chat.

Vi blev også enige om, at vi under en hændelse kun ville skifte én disk. Dette forenklede automatiseringsprocessen, statistikindsamlingen og arbejdet i fremtiden markant.

Derudover tilføjede vi feltet "ansvarlig administrator". Den vagthavende systemadministrator indsættes automatisk der. Det er meget praktisk, for nu ser ingeniøren altid, hvem der har ansvaret. Ingen grund til at gå til kalenderen og søge. Det var dette felt, der gjorde det muligt at vise billetter på administratorens dashboard, der kunne kræve hans hjælp.

For at sikre, at alle deltagere fik maksimalt udbytte af innovationer, lavede vi filtre og dashboards og fortalte gutterne om dem. Når folk forstår ændringer, tager de ikke afstand fra dem som noget unødvendigt. Det er vigtigt for en tekniker at kende racknummeret, hvor serveren er placeret, størrelsen og typen af ​​disk. Administratoren skal først og fremmest forstå, hvilken slags gruppe af servere dette er, og hvad effekten kan være, når en disk udskiftes.

Tilstedeværelsen af ​​felter og deres visning er praktisk, men det reddede os ikke fra behovet for at bruge chats. For at gøre dette var vi nødt til at ændre arbejdsgangen.

Tidligere var det sådan her:

Sådan fortsætter ingeniører med at arbejde i dag, når de ikke har brug for administratorhjælp.

Det første, vi gjorde, var at indføre en ny status Undersøge. Billetten er i denne status, når ingeniøren endnu ikke har besluttet, om han skal bruge en administrator eller ej. Gennem denne status kan teknikeren overføre billetten til administratoren. Derudover bruger vi denne status til at markere billetter, når en disk skal udskiftes, men selve disken er ikke på stedet. Dette sker i tilfælde af CDN'er og fjerntliggende websteder.

Vi tilføjede også status Ready. Billetten overføres til den efter udskiftning af disken. Det vil sige, at alt allerede er gjort, men HW/SW RAID er synkroniseret på serveren. Dette kan tage ret lang tid.

Hvis en administrator inddrages i arbejdet, bliver ordningen lidt mere kompliceret.

Fra status Åbne Billetten kan oversættes af både systemadministratoren og ingeniøren. I status I gang administratoren fjerner disken fra rotation, så teknikeren blot kan trække den ud: tænder baggrundsbelysningen, afmonterer disken, stopper programmer, afhængigt af den specifikke gruppe af servere.

Billetten oversættes derefter til Klar til at skifte: Dette er et signal til ingeniøren om, at disken kan trækkes ud. Alle felter i Jira er allerede udfyldt, ingeniøren ved hvilken type og størrelse på disken. Disse data indtastes enten automatisk på den tidligere status eller af administratoren.

Efter udskiftning af disken ændres billetstatus til Ændret. Den kontrollerer, at den korrekte disk er blevet indsat, partitionering er udført, applikationen startes, og nogle datagendannelsesopgaver startes. Billetten kan også overføres til status Ready, i dette tilfælde vil administratoren forblive ansvarlig, fordi han satte disken i rotation. Det komplette skema ser således ud.

Tilføjelse af nye felter gjorde vores liv meget lettere. Fyrene begyndte at arbejde med struktureret information, det blev klart, hvad der skulle gøres og på hvilket tidspunkt. Prioriteringer er blevet meget mere relevante, da de nu er fastsat af administratoren.

Der er ikke behov for chats. Selvfølgelig kan administratoren skrive til ingeniøren "dette skal udskiftes hurtigere," eller "det er allerede aften, vil du have tid til at erstatte det?" Men vi kommunikerer ikke længere dagligt i chats om disse spørgsmål.

Diske begyndte at blive skiftet i batches. Hvis administratoren kom på arbejde lidt tidligt, han har fri, og der er ikke sket noget endnu, kan han forberede en række servere til udskiftning: udfyld felterne, fjern diskene fra rotation og overfør opgaven til en ingeniør. Ingeniøren kommer til datacentret lidt senere, ser opgaven, tager de nødvendige drev fra lageret og udskifter dem straks. Som følge heraf er udskiftningsraten steget.

Erfaringer, man har lært, når man bygger Workflow

• Når du konstruerer en procedure, skal du indsamle oplysninger fra forskellige kilder.
  Nogle af vores administratorer vidste ikke, at ingeniøren selv skifter diskene. Nogle mennesker troede, at MD RAID-synkronisering blev håndteret af ingeniører, selvom nogle af dem ikke engang havde adgang til det. Nogle førende ingeniører gjorde dette, men ikke altid, fordi processen ikke blev beskrevet nogen steder.
• Proceduren skal være enkel og forståelig.
  Det er svært for en person at holde mange trin i tankerne. De vigtigste nabostatusser i Jira skal placeres på hovedskærmen. Du kan omdøbe dem, for eksempel kalder vi Igangværende Klar til forandring. Og andre statusser kan skjules i en drop-down menu, så de ikke er en øjenøm. Men det er bedre ikke at begrænse folk, for at give dem mulighed for at foretage overgangen.
  Forklar værdien af ​​innovation. Når folk forstår, accepterer de mere den nye procedure. Det var meget vigtigt for os, at folk ikke klikker sig igennem hele processen, men følger den. Så byggede vi automatisering på dette.
• Vent, analyser, find ud af det.
  Det tog os omkring en måned at opbygge proceduren, den tekniske implementering, møder og diskussioner. Og implementeringen tager mere end tre måneder. Jeg så, hvordan folk langsomt begynder at bruge innovationen. Der var meget negativitet i de tidlige stadier. Men den var fuldstændig uafhængig af selve proceduren og dens tekniske implementering. For eksempel brugte en administrator ikke Jira, men Jira-plugin'et i Confluence, og nogle ting var ikke tilgængelige for ham. Vi viste ham Jira, og administratorens produktivitet steg både til generelle opgaver og til udskiftning af diske.

Automatisering af diskudskiftning

Vi nærmede os automatisering af diskudskiftning flere gange. Vi havde allerede udviklinger og scripts, men de fungerede alle enten interaktivt eller manuelt og krævede lancering. Og først efter at have introduceret den nye procedure, indså vi, at det var præcis det, vi manglede.

Da vores udskiftningsproces nu er opdelt i faser, som hver har en specifik performer og en liste over handlinger, kan vi aktivere automatisering i etaper, og ikke alle på én gang. For eksempel kan det enkleste trin - Ready (kontrol af RAID/datasynkronisering) nemt delegeres til en bot. Når botten har lært lidt, kan du give den en vigtigere opgave - at sætte disken i rotation osv.

Opsætning af Zoo

Før vi taler om botten, lad os tage en kort udflugt til vores zoologiske have af installationer. Først og fremmest skyldes det den gigantiske størrelse af vores infrastruktur. For det andet forsøger vi at vælge den optimale hardwarekonfiguration for hver tjeneste. Vi har omkring 20 hardware RAID-modeller, mest LSI og Adaptec, men der er også HP og DELL af forskellige versioner. Hver RAID-controller har sit eget administrationsværktøj. Sættet af kommandoer og udstedelsen af ​​dem kan variere fra version til version for hver RAID-controller. Hvor HW-RAID ikke bruges, kan mdraid bruges.

Vi laver næsten alle nyinstallationer uden disk backup. Vi forsøger ikke længere at bruge hardware og software RAID, da vi sikkerhedskopierer vores systemer på datacenterniveau, ikke servere. Men der er selvfølgelig mange ældre servere, der skal understøttes.

Et eller andet sted overføres diskene i RAID-controllere til rå enheder, et eller andet sted bruges JBOD'er. Der er konfigurationer med én systemdisk i serveren, og hvis den skal udskiftes, så skal du geninstallere serveren med installation af OS og applikationer af samme versioner, derefter tilføje konfigurationsfiler, starte applikationer. Der er også en masse servergrupper, hvor backup ikke udføres på diskundersystemniveau, men direkte i selve applikationerne.

I alt har vi over 400 unikke servergrupper, der kører næsten 100 forskellige applikationer. For at dække et så stort antal muligheder havde vi brug for et multifunktionelt automatiseringsværktøj. Gerne med en simpel DSL, så ikke kun den, der har skrevet det, kan understøtte det.

Vi valgte Ansible, fordi det er agentløst: der var ingen grund til at forberede infrastruktur, en hurtig start. Derudover er det skrevet i Python, som er accepteret som standard indenfor teamet.

Generel ordning

Lad os se på den generelle automatiseringsordning med en hændelse som eksempel. Zabbix registrerer, at sdb-disken har fejlet, triggeren lyser, og en billet oprettes i Jira. Administratoren kiggede på det, indså, at det ikke var en dublet og ikke en falsk positiv, det vil sige, at disken skulle ændres, og overførte billetten til Igangværende.

DiskoBot-applikationen, skrevet i Python, spørger jævnligt Jira efter nye billetter. Den bemærker, at en ny Igang-billet er dukket op, den tilsvarende tråd udløses, som lancerer spillebogen i Ansible (dette gøres for hver status i Jira). I dette tilfælde lanceres Prepare2change.

Ansible sendes til værten, fjerner disken fra rotation og rapporterer status til applikationen via Callbacks.

Baseret på resultaterne overfører botten automatisk billetten til Klar til ændring. Ingeniøren modtager en notifikation og går for at skifte disken, hvorefter han overfører billetten til Changed.

Ifølge skemaet beskrevet ovenfor går billetten tilbage til botten, som lancerer en anden spillebog, går til værten og sætter disken i rotation. Botten lukker billetten. Hurra!

Lad os nu tale om nogle komponenter i systemet.

Diskobot

Denne applikation er skrevet i Python. Den vælger billetter fra Jira ifølge JQL. Afhængigt af status for billetten, går sidstnævnte til den tilsvarende handler, som igen lancerer Ansible-spillebogen, der svarer til status.

JQL og polling-intervaller er defineret i applikationens konfigurationsfil.

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

Blandt billetter i statussen Igangværende er det f.eks. kun dem, der har udfyldt felterne Diskstørrelse og Enhedsnavn, der er valgt. Enhedsnavn er navnet på den blokenhed, der er nødvendig for at udføre afspilningsbogen. Diskstørrelse er nødvendig, så ingeniøren ved, hvilken størrelse disk der er behov for.

Og blandt billetter med Klar-status filtreres billetter med dbot_ignore-etiketten fra. I øvrigt bruger vi Jira-etiketter både til sådan filtrering og til at markere dubletbilletter og til at indsamle statistik.

Hvis en playbook fejler, tildeler Jira etiketten dbot_failed, så den kan sorteres fra senere.

Interoperabilitet med Ansible

Applikationen kommunikerer med Ansible via Ansible Python API. Til playbook_executor sender vi filnavnet og et sæt variabler. Dette giver dig mulighed for at beholde Ansible-projektet i form af almindelige yml-filer i stedet for at beskrive det i Python-kode.

Også i Ansible, via *extra_vars*, navnet på blokenheden, status på billetten, samt callback_url, som indeholder udstedelsesnøglen - den bruges til tilbagekald i HTTP.

For hver lancering genereres en midlertidig opgørelse, bestående af én vært og den gruppe, som denne vært tilhører, så group_vars anvendes.

Her er et eksempel på en opgave, der implementerer HTTP-tilbagekald.

Vi får resultatet af at udføre playbooks ved hjælp af callaback(s). De er af to typer:

• Ansible callback plugin, giver den data om resultaterne af udførelse af playbook. Den beskriver de opgaver, der blev lanceret, udført med succes eller uden succes. Dette tilbagekald kaldes, når afspilningsbogen er færdig.
• HTTP-tilbagekald for at modtage information, mens du spiller en playbook. I Ansible-opgaven udfører vi en POST/GET-anmodning til vores applikation.

Variabler sendes gennem HTTP-tilbagekald(er), der blev defineret under udførelsen af ​​afspilningsbogen, og som vi ønsker at gemme og bruge i efterfølgende kørsler. Vi skriver disse data i sqlite.

Vi efterlader også kommentarer og ændrer billetstatus via HTTP-tilbagekald.

HTTP tilbagekald

# 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

Som mange opgaver af samme type lægger vi den i en separat fælles fil og inkluderer den om nødvendigt for ikke konstant at gentage den i spillebøger. Dette inkluderer callback_ url, som indeholder problemnøglen og værtsnavnet. Når Ansible udfører denne POST-anmodning, forstår botten, at den kom som en del af en sådan og sådan hændelse.

Og her er et eksempel fra playbook, hvor vi udsender en disk fra en MD-enhed:

  # 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

Denne opgave overfører Jira-billetten til statussen "Klar til at ændre" og tilføjer en kommentar. Variablen mdam_data gemmer også en liste over md-enheder, hvorfra disken blev fjernet, og parted_info gemmer et partitionsdump fra parted.

Når ingeniøren indsætter en ny disk, kan vi bruge disse variabler til at gendanne partitionsdumpet, samt indsætte disken i md-enhederne, hvorfra den blev fjernet.

Ansible check mode

Det var skræmmende at tænde for automatiseringen. Derfor besluttede vi at køre alle playbooks i tilstanden
tørt løb, hvor Ansible ikke udfører nogen handlinger på serverne, men kun emulerer dem.

En sådan lancering køres gennem et separat tilbagekaldsmodul, og resultatet af playbook-udførelsen gemmes i Jira som en kommentar.

For det første gjorde dette det muligt at validere arbejdet i botten og playbooks. For det andet øgede det administratorernes tillid til botten.

Da vi bestod valideringen og indså, at du ikke kun kan køre Ansible i tørløbstilstand, lavede vi en Kør Diskobot-knap i Jira for at starte den samme spillebog med de samme variabler på den samme vært, men i normal tilstand.

Derudover bruges knappen til at genstarte playbook, hvis den går ned.

Playbooks struktur

Jeg har allerede nævnt, at afhængigt af status for Jira-billetten, lancerer botten forskellige spillebøger.

For det første er det meget nemmere at organisere indgangen.
For det andet er det i nogle tilfælde simpelthen nødvendigt.

For eksempel, når du udskifter en systemdisk, skal du først gå til implementeringssystemet, oprette en opgave, og efter korrekt implementering bliver serveren tilgængelig via ssh, og du kan rulle applikationen ud på den. Hvis vi gjorde alt dette i én spillebog, ville Ansible ikke være i stand til at fuldføre det, fordi værten ikke var tilgængelig.

Vi bruger Ansible-roller for hver gruppe af servere. Her kan du se, hvordan spillebogen(erne) er organiseret i en af ​​dem.

Dette er praktisk, fordi det med det samme er tydeligt, hvor hvilke opgaver er placeret. I main.yml, som er input til Ansible-rollen, kan vi blot inkludere efter billetstatus eller generelle opgaver, der kræves for alle, for eksempel at videregive identifikation eller modtage et token.

undersøgelse.yml

Kører om billetter i Efterforskning og Åben status. Det vigtigste for denne playbook er blokenhedens navn. Disse oplysninger er ikke altid tilgængelige.

For at få det analyserer vi Jira-resuméet, den sidste værdi fra Zabbix-udløseren. Det kan indeholde navnet på blokenheden - heldigvis. Eller det kan indeholde et monteringspunkt, så skal du gå til serveren, analysere den og beregne den nødvendige disk. Udløseren kan også sende en scsi-adresse eller anden information. Men det sker også, at der ikke er spor, og man skal analysere.

Efter at have fundet ud af navnet på blokenheden, indsamler vi oplysninger om typen og størrelsen af ​​disken fra den for at udfylde felterne i Jira. Vi fjerner også oplysninger om leverandør, model, firmware, ID, SMART og indsætter alt dette i en kommentar i Jira-billetten. Administratoren og teknikeren behøver ikke længere at søge efter disse data. 🙂

prepare2change.yml

Fjernelse af disken fra rotation, klargøring til udskiftning. Den sværeste og vigtigste fase. Det er her, du kan stoppe applikationen, når den ikke burde stoppes. Eller tag en disk ud, der ikke havde nok replikaer, og derved have en effekt på, at brugerne mister nogle data. Her har vi flest kontroller og notifikationer i chatten.

I det enkleste tilfælde taler vi om at fjerne en disk fra et HW/MD RAID.

I mere komplekse situationer (i vores lagersystemer), når sikkerhedskopieringen udføres på applikationsniveau, skal du gå til applikationen via API'en, rapportere diskoutputtet, deaktivere det og starte gendannelsen.

Vi migrerer nu i massevis til sky, og hvis serveren er cloud-baseret, så kalder Diskobot cloud-API'en, siger, at den kommer til at fungere med denne minion - serveren, der kører containere - og spørger "migrer alle containere fra denne minion." Og tænder samtidig diskens baggrundsbelysning, så ingeniøren med det samme kan se, hvilken der skal trækkes ud.

ændret.yml

Efter at have udskiftet en disk, kontrollerer vi først dens tilgængelighed.

Ingeniører installerer ikke altid nye drev, så vi tilføjede et tjek for SMART-værdier, der tilfredsstiller os.

Hvilke egenskaber ser vi på?Omfordeling af sektorer Antal (5) < 100
Aktuel afventende sektortælling (107) == 0

Hvis drevet ikke består testen, får teknikeren besked om at udskifte det igen. Hvis alt er i orden, slukker baggrundsbelysningen, markeringer påføres, og disken sættes i rotation.

klar.yml

Det enkleste tilfælde: kontrol af HW/SW raid-synkronisering eller færdiggørelse af datasynkronisering i applikationen.

Application API

Jeg har flere gange nævnt, at botten ofte tilgår applikations-API'er. Selvfølgelig havde ikke alle applikationer de nødvendige metoder, så de skulle modificeres. Her er de vigtigste metoder, vi bruger:

• Status. Status for en klynge eller disk for at forstå, om den kan arbejdes med;
• Start/stop. Disk aktivering/deaktivering;
• Migrer/gendan. Datamigrering og gendannelse under og efter udskiftning.

Erfaringer fra Ansible

Jeg elsker virkelig Ansible. Men ofte, når jeg ser på forskellige opensource-projekter og ser, hvordan folk skriver playbooks, bliver jeg lidt bange. Komplekse logiske sammenvævninger af hvornår/løkke, manglende fleksibilitet og idempotens på grund af hyppig brug af shell/kommando.

Vi besluttede at forenkle alt så meget som muligt og udnytte fordelen ved Ansible - modularitet. På højeste niveau er der playbooks; de kan skrives af enhver administrator, tredjepartsudvikler, der kender lidt Ansible.

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

Hvis en eller anden logik er svær at implementere i playbooks, flytter vi den til et Ansible-modul eller filter. Scripts kan skrives i Python eller et hvilket som helst andet sprog.

De er nemme og hurtige at skrive. For eksempel består diskbaggrundsbelysningsmodulet, som et eksempel er vist ovenfor, af 265 linjer.

På det laveste niveau er biblioteket. Til dette projekt skrev vi en separat applikation, en slags abstraktion over hardware- og software-RAID'er, der udfører de tilsvarende anmodninger.

Ansibles største styrker er dens enkelhed og klare spillebøger. Jeg tror, ​​at du skal bruge dette og ikke generere skræmmende yaml-filer og et stort antal betingelser, shell-kode og loops.

Hvis du vil gentage vores erfaring med Ansible API, skal du huske på to ting:

• Playbook_executor og playbooks generelt kan ikke gives en timeout. Der er en timeout på ssh-sessionen, men der er ingen timeout på spillebogen. Hvis vi forsøger at afmontere en disk, der ikke længere eksisterer i systemet, vil playbook køre uendeligt, så vi var nødt til at pakke dens lancering ind i en separat wrapper og dræbe den med en timeout.
• Ansible kører på forked processer, så dens API er ikke trådsikker. Vi kører alle vores spillebøger enkelttrådede.

Som et resultat var vi i stand til at automatisere udskiftningen af ​​omkring 80 % af diskene. Samlet set er erstatningsprocenten fordoblet. I dag kigger administratoren bare på hændelsen og beslutter, om disken skal ændres eller ej, og laver så et klik.

Men nu begynder vi at løbe ind i et andet problem: nogle nye administratorer ved ikke, hvordan man skifter drev. 🙂

Kilde: www.habr.com