Automatizimi i zëvendësimit të diskut me Ansible

Pershendetje te gjitheve. Unë punoj si një administrator sistemi kryesor në OK dhe jam përgjegjës për funksionimin e qëndrueshëm të portalit. Dua të flas se si ndërtuam një proces për zëvendësimin automatik të disqeve, dhe më pas si e përjashtuam administratorin nga ky proces dhe e zëvendësuam atë me një bot.

Ky artikull është një lloj transliterimi shfaqje në HighLoad+ 2018

Ndërtimi i një procesi të zëvendësimit të diskut

Së pari disa numra

OK është një shërbim gjigant i përdorur nga miliona njerëz. Ai shërbehet nga rreth 7 mijë serverë, të cilët ndodhen në 4 qendra të ndryshme të dhënash. Serverët përmbajnë më shumë se 70 mijë disqe. Nëse i vendosni ato njëra mbi tjetrën, ju merrni një kullë më shumë se 1 km të lartë.

Hard disqet janë komponenti i serverit që dështon më shpesh. Me vëllime të tilla duhet të ndryshojmë rreth 30 disqe në javë dhe kjo procedurë është bërë një rutinë jo shumë e këndshme.

Incidentet

Kompania jonë ka prezantuar menaxhimin e plotë të incidenteve. Ne regjistrojmë çdo incident në Jira, dhe më pas e zgjidhim dhe e zgjidhim atë. Nëse një incident ka pasur ndikim tek përdoruesit, atëherë patjetër që mblidhemi dhe mendojmë se si të reagojmë më shpejt në raste të tilla, si të zvogëlojmë efektin dhe, natyrisht, si të parandalojmë një përsëritje.

Pajisjet e ruajtjes nuk bëjnë përjashtim. Statusi i tyre monitorohet nga Zabbix. Ne monitorojmë mesazhet në Syslog për gabime në shkrim/lexim, analizojmë statusin e bastisjeve HW/SW, monitorojmë SMART dhe llogarisim konsumin për SSD.

Si u ndërruan disqet më parë

Kur ndodh një shkas në Zabbix, një incident krijohet në Jira dhe caktohet automatikisht tek inxhinierët e duhur në qendrat e të dhënave. Ne e bëjmë këtë me të gjitha incidentet HW, domethënë ato që kërkojnë ndonjë punë fizike me pajisjet në qendrën e të dhënave.
Një inxhinier i qendrës së të dhënave është një person që zgjidh çështjet që lidhen me harduerin dhe është përgjegjës për instalimin, mirëmbajtjen dhe çmontimin e serverëve. Pasi ka marrë biletën, inxhinieri fillon në punë. Në raftet e diskut ai ndryshon disqet në mënyrë të pavarur. Por nëse ai nuk ka akses në pajisjen e kërkuar, inxhinieri i drejtohet për ndihmë administratorëve të sistemit në detyrë. Para së gjithash, duhet të hiqni diskun nga rrotullimi. Për ta bërë këtë, duhet të bëni ndryshimet e nevojshme në server, të ndaloni aplikacionet dhe të çmontoni diskun.

Administratori i sistemit në detyrë është përgjegjës për funksionimin e të gjithë portalit gjatë turnit të punës. Ai heton incidentet, bën riparime dhe ndihmon zhvilluesit të kryejnë detyra të vogla. Ai nuk merret vetëm me hard disqe.

Më parë, inxhinierët e qendrës së të dhënave komunikonin me administratorin e sistemit nëpërmjet chat-it. Inxhinierët dërguan lidhje me biletat e Jira, administratori i ndoqi ato, mbajti një regjistër të punës në një bllok shënimesh. Por bisedat janë të papërshtatshme për detyra të tilla: informacioni atje nuk është i strukturuar dhe humbet shpejt. Dhe administratori thjesht mund të largohej nga kompjuteri dhe të mos u përgjigjej kërkesave për ca kohë, ndërsa inxhinieri qëndronte në server me një pirg disqesh dhe priste.

Por gjëja më e keqe ishte se administratorët nuk e panë të gjithë pamjen: çfarë incidentesh të diskut ekzistonin, ku mund të lindte një problem. Kjo për faktin se ne i delegojmë të gjitha incidentet e HW tek inxhinierët. Po, ishte e mundur të shfaqeshin të gjitha incidentet në pultin e administratorit. Por ka shumë prej tyre dhe administratori u përfshi vetëm për disa prej tyre.

Për më tepër, inxhinieri nuk mund të vendoste saktë prioritetet, sepse ai nuk di asgjë për qëllimin e serverëve specifikë ose shpërndarjen e informacionit midis disqeve.

Procedura e re e zëvendësimit

Gjëja e parë që bëmë ishte zhvendosja e të gjitha incidenteve të diskut në një tip të veçantë "HW disk" dhe shtuam fushat "blloko emrin e pajisjes", "madhësia" dhe "lloji i diskut" në mënyrë që ky informacion të ruhet në biletë dhe të nuk duhet të shkëmbeni vazhdimisht në chat.

Ne gjithashtu ramë dakord që gjatë një incidenti të ndryshonim vetëm një disk. Kjo thjeshtoi ndjeshëm procesin e automatizimit, mbledhjen e statistikave dhe punën në të ardhmen.

Përveç kësaj, ne shtuam fushën "administratori përgjegjës". Atje futet automatikisht administratori i sistemit në detyrë. Kjo është shumë e përshtatshme, sepse tani inxhinieri sheh gjithmonë kush është përgjegjës. Nuk ka nevojë të shkoni në kalendar dhe të kërkoni. Ishte kjo fushë që bëri të mundur shfaqjen e biletave në pultin e administratorit që mund të kërkonte ndihmën e tij.

Për t'u siguruar që të gjithë pjesëmarrësit të merrnin përfitime maksimale nga risitë, ne krijuam filtra dhe panele kontrolli dhe u treguam djemve për to. Kur njerëzit i kuptojnë ndryshimet, ata nuk distancohen prej tyre si diçka të panevojshme. Është e rëndësishme që një inxhinier të dijë numrin e raftit ku ndodhet serveri, madhësinë dhe llojin e diskut. Administratori duhet, para së gjithash, të kuptojë se çfarë lloj grupi serverësh është ky dhe cili mund të jetë efekti kur zëvendësoni një disk.

Prania e fushave dhe shfaqja e tyre është e përshtatshme, por nuk na shpëtoi nga nevoja për të përdorur biseda. Për ta bërë këtë, na u desh të ndryshonim rrjedhën e punës.

Më parë ishte kështu:

Kështu vazhdojnë të punojnë inxhinierët sot kur nuk kanë nevojë për ndihmën e administratorit.

Gjëja e parë që bëmë ishte futja e një statusi të ri hetoj. Bileta është në këtë status kur inxhinieri nuk ka vendosur ende nëse do të ketë nevojë për një administrator apo jo. Nëpërmjet këtij statusi, inxhinieri mund të transferojë biletën te administratori. Përveç kësaj, ne e përdorim këtë status për të shënuar biletat kur një disk duhet të zëvendësohet, por vetë disku nuk është në vend. Kjo ndodh në rastin e CDN-ve dhe faqeve të largëta.

Ne gjithashtu shtuam statusin Gati. Bileta transferohet në të pas zëvendësimit të diskut. Kjo do të thotë, gjithçka është bërë tashmë, por HW/SW RAID është sinkronizuar në server. Kjo mund të marrë një kohë mjaft të gjatë.

Nëse një administrator përfshihet në punë, skema bëhet pak më e ndërlikuar.

Nga statusi hapur Bileta mund të përkthehet si nga administratori i sistemit ashtu edhe nga inxhinieri. Në status Në progres administratori e heq diskun nga rrotullimi në mënyrë që inxhinieri thjesht ta tërheqë atë: ndez dritën e prapme, çmonton diskun, ndalon aplikacionet, në varësi të grupit specifik të serverëve.

Bileta më pas transferohet në Gati për të ndryshuar: Ky është një sinjal për inxhinierin që disku mund të tërhiqet. Të gjitha fushat në Jira tashmë janë plotësuar, inxhinieri e di se çfarë lloji dhe madhësie të diskut. Këto të dhëna futen ose automatikisht në statusin e mëparshëm ose nga administratori.

Pas zëvendësimit të diskut, statusi i biletës ndryshohet në ndryshuar. Ai kontrollon që disku i saktë është futur, është kryer ndarja, aplikacioni është nisur dhe disa detyra për rikuperimin e të dhënave janë nisur. Bileta gjithashtu mund të transferohet në status Gati, në këtë rast administratori do të mbetet përgjegjës, sepse e ka vënë diskun në rotacion. Diagrami i plotë duket kështu.

Shtimi i fushave të reja e bëri jetën tonë shumë më të lehtë. Djemtë filluan të punojnë me informacion të strukturuar, u bë e qartë se çfarë duhej bërë dhe në cilën fazë. Prioritetet janë bërë shumë më të rëndësishme, pasi ato vendosen tani nga administratori.

Nuk ka nevojë për chat. Sigurisht, administratori mund t'i shkruajë inxhinierit "kjo duhet të zëvendësohet më shpejt" ose "është tashmë mbrëmje, a do të keni kohë ta zëvendësoni?" Por ne nuk komunikojmë më çdo ditë në biseda për këto çështje.

Disqet filluan të ndërroheshin në grupe. Nëse administratori erdhi në punë pak më herët, ai ka kohë të lirë dhe asgjë nuk ka ndodhur ende, ai mund të përgatisë një numër serverësh për zëvendësim: plotësoni fushat, hiqni disqet nga rrotullimi dhe transferoni detyrën te një inxhinier. Inxhinieri vjen pak më vonë në qendrën e të dhënave, sheh detyrën, merr disqet e nevojshme nga magazina dhe i zëvendëson menjëherë. Si rezultat, shkalla e zëvendësimit është rritur.

Mësimet e nxjerra kur ndërtohet Workflow

• Kur ndërtoni një procedurë, duhet të mblidhni informacion nga burime të ndryshme.
  Disa nga administratorët tanë nuk e dinin që inxhinieri i ndryshon vetë disqet. Disa njerëz menduan se sinkronizimi MD RAID u trajtua nga inxhinierë, edhe pse disa prej tyre as nuk kishin akses për ta bërë këtë. Disa inxhinierë kryesorë e bënë këtë, por jo gjithmonë sepse procesi nuk u përshkrua askund.
• Procedura duhet të jetë e thjeshtë dhe e kuptueshme.
  Është e vështirë për një person të mbajë parasysh shumë hapa. Statuset më të rëndësishme fqinje në Jira duhet të vendosen në ekranin kryesor. Mund t'i riemërtoni, për shembull, ne i quajmë Në progres Gati për të ndryshuar. Dhe statuse të tjera mund të fshihen në një meny të lëshimit, në mënyrë që të mos jenë të dhimbshme. Por është më mirë të mos kufizoni njerëzit, t'u jepni atyre mundësinë për të bërë tranzicionin.
  Shpjegoni vlerën e inovacionit. Kur njerëzit e kuptojnë, ata po e pranojnë më shumë procedurën e re. Ishte shumë e rëndësishme për ne që njerëzit të mos klikojnë në të gjithë procesin, por ta ndjekin atë. Pastaj ndërtuam automatizimin mbi këtë.
• Prisni, analizoni, kuptoni.
  Na u desh rreth një muaj për të ndërtuar procedurën, zbatimin teknik, takimet dhe diskutimet. Dhe zbatimi zgjat më shumë se tre muaj. Pashë se si njerëzit po fillojnë ngadalë të përdorin inovacionin. Kishte shumë negativitet në fazat e hershme. Por ajo ishte plotësisht e pavarur nga vetë procedura dhe zbatimi teknik i saj. Për shembull, një administrator nuk përdori Jira, por shtojcën Jira në Confluence, dhe disa gjëra nuk ishin të disponueshme për të. Ne i treguam atij Jira dhe produktiviteti i administratorit u rrit si për detyrat e përgjithshme ashtu edhe për zëvendësimin e disqeve.

Automatizimi i zëvendësimit të diskut

Ne iu afruam automatizimit të zëvendësimit të diskut disa herë. Tashmë kishim zhvillime dhe skripta, por të gjitha funksiononin ose në mënyrë interaktive ose manuale dhe kërkonin nisje. Dhe vetëm pas prezantimit të procedurës së re, kuptuam se kjo ishte pikërisht ajo që na mungonte.

Meqenëse tani procesi ynë i zëvendësimit është i ndarë në faza, secila prej të cilave ka një interpretues të caktuar dhe një listë veprimesh, ne mund të mundësojmë automatizimin në faza, dhe jo të gjitha menjëherë. Për shembull, faza më e thjeshtë - Gati (duke kontrolluar sinkronizimin e RAID/të dhënave) mund t'i delegohet lehtësisht një roboti. Kur roboti të ketë mësuar pak, mund t'i jepni një detyrë më të rëndësishme - vënien e diskut në rrotullim, etj.

Konfigurimet e kopshtit zoologjik

Para se të flasim për robotin, le të bëjmë një ekskursion të shkurtër në kopshtin tonë zoologjik të instalimeve. Para së gjithash, kjo është për shkak të përmasave gjigante të infrastrukturës sonë. Së dyti, ne përpiqemi të zgjedhim konfigurimin optimal të harduerit për çdo shërbim. Kemi rreth 20 modele harduerike RAID, kryesisht LSI dhe Adaptec, por ka edhe HP dhe DELL të versioneve të ndryshme. Çdo kontrollues RAID ka mjetin e vet të menaxhimit. Grupi i komandave dhe lëshimi i tyre mund të ndryshojnë nga versioni në version për çdo kontrollues RAID. Aty ku nuk përdoret HW-RAID, mund të përdoret mdraid.

Ne bëjmë pothuajse të gjitha instalimet e reja pa rezervë të diskut. Ne përpiqemi të mos përdorim më harduer dhe softuer RAID, pasi bëjmë kopje rezervë të sistemeve tona në nivelin e qendrës së të dhënave, jo në nivelin e serverit. Por sigurisht që ka shumë serverë të trashëguar që duhet të mbështeten.

Diku disqet në kontrollorët RAID transferohen në pajisje të papërpunuara, diku përdoren JBOD. Ka konfigurime me një disk sistemi në server, dhe nëse duhet të zëvendësohet, atëherë duhet të riinstaloni serverin me instalimin e OS dhe aplikacioneve, të të njëjtave versione, pastaj shtoni skedarë konfigurimi, nisni aplikacionet. Ekzistojnë gjithashtu shumë grupe serverësh ku kopjimi kryhet jo në nivelin e nënsistemit të diskut, por drejtpërdrejt në vetë aplikacionet.

Në total, ne kemi mbi 400 grupe unike serverësh që drejtojnë afro 100 aplikacione të ndryshme. Për të mbuluar një numër kaq të madh opsionesh, na duhej një mjet automatizimi shumëfunksional. Mundësisht me një DSL të thjeshtë, që jo vetëm ai që e ka shkruar ta mbështesë.

Ne zgjodhëm Ansible sepse është pa agjent: nuk kishte nevojë të përgatitej infrastruktura, një fillim i shpejtë. Përveç kësaj, është shkruar në Python, i cili pranohet si standard brenda ekipit.

Skema e pergjithshme

Le të shohim skemën e përgjithshme të automatizimit duke përdorur një incident si shembull. Zabbix zbulon se disku sdb ka dështuar, këmbëza ndizet dhe krijohet një biletë në Jira. Administratori e shikoi, kuptoi që nuk ishte një dublikatë dhe jo një pozitiv i rremë, domethënë, disku duhej ndryshuar dhe e transferoi biletën në "Në progres".

Aplikacioni DiskoBot, i shkruar në Python, anketon periodikisht Jira për bileta të reja. Ai vëren se është shfaqur një biletë e re Në progres, aktivizohet filli përkatës, i cili hap librin e lojërave në Ansible (kjo bëhet për çdo status në Jira). Në këtë rast, Prepare2change hapet.

Ansible dërgohet te hosti, heq diskun nga rrotullimi dhe raporton statusin tek aplikacioni nëpërmjet Callbacks.

Bazuar në rezultatet, roboti e transferon automatikisht biletën në Ready për të ndryshuar. Inxhinieri merr një njoftim dhe shkon për të ndryshuar diskun, pas së cilës ai transferon biletën në Changed.

Sipas skemës së përshkruar më sipër, bileta kthehet në bot, i cili lëshon një libër tjetër lojërash, shkon te hosti dhe e vë diskun në rrotullim. Bot mbyll biletën. Hora!

Tani le të flasim për disa komponentë të sistemit.

Diskobot

Ky aplikacion është shkruar në Python. Ai zgjedh biletat nga Jira sipas JQL. Në varësi të statusit të biletës, kjo e fundit shkon te mbajtësi përkatës, i cili nga ana e tij lëshon librin e lojërave Ansible që korrespondon me statusin.

JQL dhe intervalet e votimit përcaktohen në skedarin e konfigurimit të aplikacionit.

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

Për shembull, midis biletave në statusin Në progres, zgjidhen vetëm ato me fushat e mbushura me madhësinë e diskut dhe emrin e pajisjes. Emri i pajisjes është emri i pajisjes së bllokut që nevojitet për të ekzekutuar librin e luajtjes. Madhësia e diskut është e nevojshme në mënyrë që inxhinieri të dijë se çfarë madhësie disku nevojitet.

Dhe midis biletave me status Gati, biletat me etiketën dbot_ignore filtrohen. Nga rruga, ne përdorim etiketat Jira si për filtrim të tillë, ashtu edhe për shënimin e biletave të kopjuara dhe mbledhjen e statistikave.

Nëse një libër lojërash dështon, Jira cakton etiketën dbot_failed në mënyrë që të mund të zgjidhet më vonë.

Ndërveprueshmëria me Ansible

Aplikacioni komunikon me Ansible nëpërmjet Ansible Python API. Tek playbook_executor kalojmë emrin e skedarit dhe një grup variablash. Kjo ju lejon të mbani projektin Ansible në formën e skedarëve të rregullt yml, në vend që ta përshkruani atë në kodin Python.

Gjithashtu në Ansible, nëpërmjet *extra_vars*, emri i pajisjes bllok, statusi i biletës, si dhe callback_url, i cili përmban çelësin e çështjes - përdoret për kthimin e thirrjeve në HTTP.

Për çdo nisje, gjenerohet një inventar i përkohshëm, i përbërë nga një host dhe grupi të cilit i përket ky host, në mënyrë që grup_vars të aplikohen.

Këtu është një shembull i një detyre që zbaton kthimin e thirrjes HTTP.

Ne marrim rezultatin e ekzekutimit të librave të luajtjes duke përdorur thirrjen (thirrjet). Ato janë dy llojesh:

• Shtojcë e ansible për kthimin e thirrjes, ofron të dhëna për rezultatet e ekzekutimit të librit të lojërave. Ai përshkruan detyrat që janë nisur, përfunduar me sukses ose pa sukses. Kjo kthim thirret kur libri i luajtjes ka përfunduar së luajturi.
• Thirrja HTTP për të marrë informacion gjatë luajtjes së një libri luajtjeje. Në detyrën Ansible ne ekzekutojmë një kërkesë POST/GET për aplikacionin tonë.

Variablat kalohen përmes kthimit të thirrjeve HTTP që u përcaktuan gjatë ekzekutimit të librit të luajtjes dhe që duam t'i ruajmë dhe përdorim në ekzekutimet pasuese. Ne i shkruajmë këto të dhëna në sqlite.

Ne gjithashtu lëmë komente dhe ndryshojmë statusin e biletës përmes HTTP-së.

Mbështetja e thirrjes 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

Ashtu si shumë detyra të të njëjtit lloj, ne e vendosim atë në një skedar të përbashkët të veçantë dhe e përfshijmë nëse është e nevojshme, në mënyrë që të mos e përsërisim vazhdimisht në libra lojërash. Kjo përfshin url-në callback_, e cila përmban çelësin e problemit dhe emrin e hostit. Kur Ansible ekzekuton këtë kërkesë POST, roboti e kupton se ajo ka ardhur si pjesë e një incidenti të tillë.

Dhe këtu është një shembull nga libri i lojërave, në të cilin nxjerrim një disk nga një pajisje 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

Kjo detyrë e transferon biletën Jira në statusin "Gati për të ndryshuar" dhe shton një koment. Gjithashtu, ndryshorja mdam_data ruan një listë të pajisjeve md nga të cilat është hequr disku dhe parted_info ruan një ndarje të ndarjes nga parted.

Kur inxhinieri fut një disk të ri, ne mund t'i përdorim këto variabla për të rivendosur ndarjen e ndarjes, si dhe për të futur diskun në pajisjet md nga të cilat është hequr.

Modaliteti i kontrollit të pasigurt

Ishte e frikshme të ndizje automatizimin. Prandaj, vendosëm të ekzekutojmë të gjithë librat e lojërave në modalitet
vrapim i thatë, në të cilin Ansible nuk kryen asnjë veprim në serverë, por vetëm i imiton ato.

Një nisje e tillë kryhet përmes një moduli të veçantë të kthimit të thirrjes dhe rezultati i ekzekutimit të librit të luajtjes ruhet në Jira si koment.

Së pari, kjo bëri të mundur vërtetimin e punës së botit dhe librave të lojërave. Së dyti, rriti besimin e administratorëve në bot.

Kur kaluam vërtetimin dhe kuptuam se mund të ekzekutoni Ansible jo vetëm në modalitetin e ekzekutimit të thatë, ne krijuam një buton Run Diskobot në Jira për të nisur të njëjtin libër lojërash me të njëjtat variabla në të njëjtin host, por në modalitetin normal.

Përveç kësaj, butoni përdoret për të rifilluar librin e lojërave nëse ai rrëzohet.

Struktura e librave të lojërave

Unë e kam përmendur tashmë se në varësi të statusit të biletës Jira, bot lëshon libra të ndryshëm lojërash.

Së pari, është shumë më e lehtë të organizosh hyrjen.
Së dyti, në disa raste është thjesht e nevojshme.

Për shembull, kur zëvendësoni një disk të sistemit, së pari duhet të shkoni te sistemi i vendosjes, të krijoni një detyrë dhe pas vendosjes së saktë, serveri do të bëhet i aksesueshëm përmes ssh dhe mund ta hapni aplikacionin në të. Nëse do t'i bënim të gjitha këto në një libër të vetëm, atëherë Ansible nuk do të ishte në gjendje ta plotësonte atë për shkak të mungesës së hostit.

Ne përdorim rolet Ansible për çdo grup serverësh. Këtu mund të shihni se si janë organizuar librat e lojërave në njërën prej tyre.

Kjo është e përshtatshme sepse është menjëherë e qartë se ku ndodhen detyrat. Në main.yml, që është hyrja për rolin Ansible, ne thjesht mund të përfshijmë statusin e biletës ose detyrat e përgjithshme të kërkuara për të gjithë, për shembull, kalimin e identifikimit ose marrjen e një tokeni.

hetim.yml

Vrapon për bileta në statusin Hetim dhe Hapur. Gjëja më e rëndësishme për këtë libër lojërash është emri i pajisjes së bllokut. Ky informacion nuk është gjithmonë i disponueshëm.

Për ta marrë atë, ne analizojmë përmbledhjen Jira, vlerën e fundit nga këmbëza Zabbix. Mund të përmbajë emrin e pajisjes së bllokut - me fat. Ose mund të përmbajë një pikë montimi, atëherë duhet të shkoni te serveri, ta analizoni atë dhe të llogarisni diskun e kërkuar. Shkaku mund të transmetojë gjithashtu një adresë scsi ose ndonjë informacion tjetër. Por gjithashtu ndodh që nuk ka të dhëna, dhe ju duhet të analizoni.

Pasi kemi zbuluar emrin e pajisjes së bllokut, ne mbledhim informacione rreth llojit dhe madhësisë së diskut prej tij për të plotësuar fushat në Jira. Ne gjithashtu heqim informacionin rreth shitësit, modelit, firmware-it, ID-së, SMART-it dhe i fusim të gjitha këto në një koment në biletën Jira. Administratori dhe inxhinieri nuk kanë më nevojë të kërkojnë për këto të dhëna. 🙂

përgatit2ndryshim.yml

Heqja e diskut nga rrotullimi, përgatitja për zëvendësim. Faza më e vështirë dhe më e rëndësishme. Këtu mund ta ndaloni aplikacionin kur nuk duhet të ndalet. Ose hiqni një disk që nuk kishte kopje të mjaftueshme, dhe në këtë mënyrë ndikoni te përdoruesit, duke humbur disa të dhëna. Këtu kemi më shumë kontrolle dhe njoftime në chat.

Në rastin më të thjeshtë, ne po flasim për heqjen e një disku nga një HW/MD RAID.

Në situata më komplekse (në sistemet tona të ruajtjes), kur rezervimi kryhet në nivelin e aplikacionit, duhet të shkoni te aplikacioni përmes API-së, të raportoni daljen e diskut, ta çaktivizoni atë dhe të filloni rikuperimin.

Tani po migrojmë masivisht në re, dhe nëse serveri është i bazuar në renë kompjuterike, atëherë Diskobot thërret API-në e cloud, thotë se do të funksionojë me këtë minion - serveri që drejton kontejnerët - dhe kërkon "migroni të gjithë kontejnerët nga ky minion". Dhe në të njëjtën kohë, ndez dritën e prapme të diskut, në mënyrë që inxhinieri të shohë menjëherë se cili duhet të tërhiqet.

ndryshuar.yml

Pas zëvendësimit të një disku, së pari kontrollojmë disponueshmërinë e tij.

Inxhinierët jo gjithmonë instalojnë disqe të reja, kështu që ne shtuam një kontroll për vlerat SMART që na kënaqin.

Cilat atribute po shikojmë?Numri i sektorëve të rialokuar (5) < 100
Numri aktual i sektorit në pritje (107) == 0

Nëse disku dështon në test, inxhinieri njoftohet për ta zëvendësuar përsëri. Nëse gjithçka është në rregull, drita e prapme fiket, vendosen shenjat dhe disku vihet në rrotullim.

gati.yml

Rasti më i thjeshtë: kontrollimi i sinkronizimit të bastisjes HW/SW ose përfundimi i sinkronizimit të të dhënave në aplikacion.

API e aplikacionit

E kam përmendur disa herë që roboti shpesh akseson API-të e aplikacioneve. Sigurisht, jo të gjitha aplikacionet kishin metodat e nevojshme, kështu që ato duhej të modifikoheshin. Këtu janë metodat më të rëndësishme që përdorim:

• Statusi. Statusi i një grupi ose disku për të kuptuar nëse mund të punohet me të;
• Fillo/ndalo. Aktivizimi/çaktivizimi i diskut;
• Migro/rivendos. Migrimi dhe rikuperimi i të dhënave gjatë dhe pas zëvendësimit.

Mësimet e nxjerra nga Ansible

Më pëlqen shumë Ansible. Por shpesh, kur shikoj projekte të ndryshme me burim të hapur dhe shoh se si njerëzit shkruajnë libra, kam pak frikë. Ndërthurje komplekse logjike e kur/lakut, mungesë fleksibiliteti dhe idempotencës për shkak të përdorimit të shpeshtë të guaskës/komandimit.

Ne vendosëm të thjeshtojmë gjithçka sa më shumë që të jetë e mundur, duke përfituar nga avantazhi i Ansible - modulariteti. Në nivelin më të lartë ka libra lojërash; ato mund të shkruhen nga çdo administrator, zhvillues i palës së tretë që njeh pak Ansible.

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

Nëse një logjikë është e vështirë për t'u zbatuar në librat e lojërave, ne e zhvendosim atë në një modul ose filtër Ansible. Skriptet mund të shkruhen në Python ose në ndonjë gjuhë tjetër.

Shkruhen lehtë dhe shpejt. Për shembull, moduli i dritës së prapme të diskut, një shembull i të cilit tregohet më lart, përbëhet nga 265 rreshta.

Në nivelin më të ulët është biblioteka. Për këtë projekt, ne kemi shkruar një aplikacion të veçantë, një lloj abstraksioni mbi RAID-të e harduerit dhe softuerit që kryejnë kërkesat përkatëse.

Pikat më të forta të Ansible janë thjeshtësia dhe librat e qartë të lojës. Unë besoj se ju duhet ta përdorni këtë dhe të mos gjeneroni skedarë të frikshëm yaml dhe një numër të madh kushtesh, kodesh shell dhe sythe.

Nëse dëshironi të përsërisni përvojën tonë me Ansible API, mbani në mend dy gjëra:

• Playbook_executor dhe playbooks në përgjithësi nuk mund t'u jepet një afat kohor. Ka një afat kohor në seancën ssh, por nuk ka kohë në librin e lojërave. Nëse përpiqemi të çmontojmë një disk që nuk ekziston më në sistem, libri i luajtjes do të funksionojë pafund, kështu që na u desh ta mbështillnim lëshimin e tij në një mbështjellës të veçantë dhe ta mbysim atë me një afat kohor.
• Ansible funksionon në procese të forcuara, kështu që API-ja e tij nuk është e sigurt për temat. Ne i ekzekutojmë të gjithë librat tanë me një fije të vetme.

Si rezultat, ne ishim në gjendje të automatizonim zëvendësimin e rreth 80% të disqeve. Në përgjithësi, shkalla e zëvendësimit është dyfishuar. Sot, administratori thjesht shikon incidentin dhe vendos nëse disku duhet të ndryshohet apo jo, dhe më pas bën një klikim.

Por tani po fillojmë të hasim një problem tjetër: disa administratorë të rinj nuk dinë të ndryshojnë disqet. 🙂

Burimi: www.habr.com