Diska nomaiņas automatizācija ar Ansible

Diska nomaiņas automatizācija ar Ansible

Sveiki visiem. Strādāju par vadoÅ”o sistēmas administratoru OK un esmu atbildÄ«gs par portāla stabilu darbÄ«bu. Es vēlos runāt par to, kā mēs izveidojām procesu automātiskai disku nomaiņai un kā mēs izslēdzām administratoru no Ŕī procesa un aizstājām viņu ar robotu.

Šis raksts ir sava veida transliterācija izrādes programmā HighLoad+ 2018

Diska nomaiņas procesa izveide

Vispirms daži skaitļi

OK ir milzÄ«gs pakalpojums, ko izmanto miljoniem cilvēku. To apkalpo aptuveni 7 tÅ«kstoÅ”i serveru, kas atrodas 4 dažādos datu centros. Serveros ir vairāk nekā 70 tÅ«kstoÅ”i disku. Ja jÅ«s tos saliekat vienu virs otra, jÅ«s iegÅ«stat torni, kura augstums pārsniedz 1 km.

Cietie diski ir servera komponents, kas visbiežāk neizdodas. Ar Ŕādiem apjomiem mums ir jāmaina apmēram 30 diski nedēļā, un Ŕī procedÅ«ra ir kļuvusi par ne pārāk patÄ«kamu rutÄ«nu.

Diska nomaiņas automatizācija ar Ansible

Starpgadījumi

MÅ«su uzņēmumā ir ieviesta pilnvērtÄ«ga incidentu pārvaldÄ«ba. Mēs ierakstām katru incidentu Jirā un pēc tam to atrisinām un atrisinām. Ja kāds incidents atstājis iespaidu uz lietotājiem, tad noteikti sanākam kopā un domājam, kā Ŕādos gadÄ«jumos ātrāk reaģēt, kā mazināt efektu un, protams, kā novērst recidÄ«vu.

UzglabāŔanas ierÄ«ces nav izņēmums. Viņu statusu uzrauga Zabbix. Mēs pārraugām Syslog ziņojumus, lai atrastu rakstÄ«Å”anas/lasÄ«Å”anas kļūdas, analizējam HW/SW reidu statusu, uzraugām SMART un aprēķinām SSD nodilumu.

Kā diski tika mainīti iepriekŔ

Kad Zabbix notiek trigeris, Jira tiek izveidots incidents un automātiski tiek pieŔķirts attiecÄ«gajiem inženieriem datu centros. Mēs to darām ar visiem HW incidentiem, tas ir, tiem, kas prasa jebkādu fizisku darbu ar iekārtām datu centrā.
Datu centra inženieris ir persona, kas atrisina ar aparatÅ«ru saistÄ«tas problēmas un ir atbildÄ«ga par serveru uzstādÄ«Å”anu, apkopi un demontāžu. Saņēmis biļeti, inženieris Ä·eras pie darba. Disku plauktos viņŔ diskus maina neatkarÄ«gi. Bet, ja viņam nav pieejas vajadzÄ«gajai ierÄ«cei, inženieris vērÅ”as pēc palÄ«dzÄ«bas pie dežurējoÅ”ajiem sistēmas administratoriem. Pirmkārt, disks ir jānoņem no rotācijas. Lai to izdarÄ«tu, serverÄ« ir jāveic nepiecieÅ”amās izmaiņas, jāaptur lietojumprogrammas un jāatvieno disks.

Par visa portāla darbÄ«bu darba maiņas laikā atbild dežurējoÅ”ais sistēmas administrators. ViņŔ izmeklē incidentus, veic remontdarbus un palÄ«dz izstrādātājiem veikt nelielus uzdevumus. ViņŔ nenodarbojas tikai ar cietajiem diskiem.

IepriekÅ” datu centra inženieri ar sistēmas administratoru sazinājās, izmantojot tērzÄ“Å”anu. Inženieri nosÅ«tÄ«ja saites uz Jira biļetēm, administrators tām sekoja, veica darbu žurnālu kādā piezÄ«mju grāmatiņā. Bet tērzÄ“Å”ana ir neērta Ŕādiem uzdevumiem: informācija tur nav strukturēta un ātri tiek zaudēta. Un administrators varēja vienkārÅ”i aiziet no datora un kādu laiku neatbildēt uz pieprasÄ«jumiem, kamēr inženieris stāvēja pie servera ar disku kaudzi un gaidÄ«ja.

Bet sliktākais bija tas, ka administratori neredzēja visu ainu: kādi diska incidenti pastāv, kur potenciāli varētu rasties problēma. Tas ir saistīts ar faktu, ka mēs deleģējam visus HW incidentus inženieriem. Jā, visus incidentus bija iespējams parādīt administratora informācijas panelī. Bet viņu ir daudz, un administrators bija iesaistīts tikai dažiem no tiem.

Turklāt inženieris nevarēja pareizi noteikt prioritātes, jo neko nezina par konkrētu serveru mērķi vai informācijas sadali starp diskdziņiem.

Jauna nomaiņas procedūra

Pirmā lieta, ko mēs izdarÄ«jām, bija pārvietot visus diska incidentus uz atseviŔķa tipa ā€œHW diskā€ un pievienojām tam laukus ā€œbloka ierÄ«ces nosaukumsā€, ā€œizmērsā€ un ā€œdiska tipsā€, lai Ŕī informācija tiktu saglabāta biļetē un nav pastāvÄ«gi jāapmainās tērzÄ“Å”anā.

Diska nomaiņas automatizācija ar Ansible
Tāpat vienojāmies, ka viena incidenta laikā mainÄ«sim tikai vienu disku. Tas bÅ«tiski vienkārÅ”oja automatizācijas procesu, statistikas apkopoÅ”anu un darbu nākotnē.

Turklāt mēs pievienojām lauku ā€œatbildÄ«gais administratorsā€. Tur automātiski tiek ievietots dežurējoÅ”ais sistēmas administrators. Tas ir ļoti ērti, jo tagad inženieris vienmēr redz, kurÅ” ir atbildÄ«gs. Nav nepiecieÅ”ams doties uz kalendāru un meklēt. TieÅ”i Å”is lauks ļāva administratora informācijas panelÄ« parādÄ«t biļetes, kurām varētu bÅ«t nepiecieÅ”ama viņa palÄ«dzÄ«ba.

Diska nomaiņas automatizācija ar Ansible
Lai visi dalÄ«bnieki gÅ«tu maksimālu labumu no jauninājumiem, mēs izveidojām filtrus un informācijas paneļus un pastāstÄ«jām par tiem puiÅ”iem. Kad cilvēki saprot izmaiņas, viņi no tām nedistancējas kā no kaut kā nevajadzÄ«ga. Inženierim ir svarÄ«gi zināt statÄ«va numuru, kurā atrodas serveris, diska izmēru un veidu. Administratoram, pirmkārt, ir jāsaprot, kāda veida serveru grupa tā ir un kāda varētu bÅ«t diska nomaiņas ietekme.

Lauku klātbÅ«tne un to attēloÅ”ana ir ērta, taču tas mÅ«s neglāba no nepiecieÅ”amÄ«bas izmantot tērzÄ“Å”anu. Lai to izdarÄ«tu, mums bija jāmaina darbplÅ«sma.

IepriekŔ tas bija Ŕādi:

Diska nomaiņas automatizācija ar Ansible
Šādi inženieri turpina strādāt arÄ« Å”odien, kad viņiem nav nepiecieÅ”ama administratora palÄ«dzÄ«ba.

Pirmā lieta, ko mēs izdarÄ«jām, bija jauna statusa ievieÅ”ana Izmeklēt. Biļete ir Ŕādā statusā, kad inženieris vēl nav izlēmis, vai viņam bÅ«s nepiecieÅ”ams administrators vai nē. Izmantojot Å”o statusu, inženieris var nodot biļeti administratoram. Turklāt mēs izmantojam Å”o statusu, lai atzÄ«mētu biļetes, kad disks ir jānomaina, bet pats disks nav uz vietas. Tas notiek CDN un attālo vietņu gadÄ«jumā.

Mēs arī pievienojām statusu Gatavs. Biļete tiek pārsūtīta uz to pēc diska nomaiņas. Tas ir, viss jau ir izdarīts, bet HW/SW RAID ir sinhronizēts serverī. Tas var aizņemt diezgan ilgu laiku.

Ja darbā tiek iesaistīts administrators, shēma kļūst nedaudz sarežģītāka.

Diska nomaiņas automatizācija ar Ansible
No statusa atvērts Biļeti var iztulkot gan sistēmas administrators, gan inženieris. Statusā Notiek administrators noņem disku no rotācijas, lai inženieris varētu to vienkārÅ”i izvilkt: ieslēdz fona apgaismojumu, atvieno disku, aptur lietojumprogrammas atkarÄ«bā no konkrētās serveru grupas.

Pēc tam biļete tiek pārsÅ«tÄ«ta uz Gatavs pārmaiņām: Tas ir signāls inženierim, ka disku var izvilkt. Visi lauki Jira jau ir aizpildÄ«ti, inženieris zina, kāda veida un izmēra disks. Å os datus ievada vai nu automātiski iepriekŔējā statusā, vai arÄ« administrators.

Pēc diska nomaiņas biļetes statuss tiek mainÄ«ts uz MainÄ«ts. Tas pārbauda, ā€‹ā€‹vai ir ievietots pareizais disks, tiek veikta sadalÄ«Å”ana, tiek palaista lietojumprogramma un tiek palaisti daži datu atkopÅ”anas uzdevumi. Biļeti var arÄ« pārcelt uz statusu Gatavs, Å”ajā gadÄ«jumā atbildÄ«gs paliks administrators, jo viņŔ ielika disku rotācijā. Pilna diagramma izskatās Ŕādi.

Diska nomaiņas automatizācija ar Ansible
Jaunu lauku pievienoÅ”ana padarÄ«ja mÅ«su dzÄ«vi daudz vieglāku. PuiÅ”i sāka strādāt ar strukturētu informāciju, kļuva skaidrs, kas un kurā posmā ir jādara. Prioritātes ir kļuvuÅ”as daudz aktuālākas, jo tās tagad nosaka administrators.

TērzÄ“Å”ana nav nepiecieÅ”ama. Protams, administrators var rakstÄ«t inženierim ā€œtas ir jānomaina ātrākā€ vai ā€œir jau vakars, vai paspēsi to nomainÄ«t?ā€ Bet mēs vairs nesazināmies katru dienu tērzÄ“Å”anas sarunās par Å”iem jautājumiem.

Diskus sāka mainÄ«t partijās. Ja administrators ieradās darbā nedaudz agri, viņam ir brÄ«vs laiks, un nekas vēl nav noticis, viņŔ var sagatavot vairākus serverus nomaiņai: aizpildÄ«t laukus, noņemt diskus no rotācijas un nodot uzdevumu inženierim. Inženieris ierodas datu centrā nedaudz vēlāk, redz uzdevumu, paņem no noliktavas nepiecieÅ”amos diskus un uzreiz nomaina. Tā rezultātā ir palielinājies aizstāŔanas lÄ«menis.

DarbplÅ«smas veidoÅ”anā gÅ«tās atziņas

  • Veidojot procedÅ«ru, jums ir jāapkopo informācija no dažādiem avotiem.
    Daži mÅ«su administratori nezināja, ka inženieris pats maina diskus. Daži cilvēki domāja, ka MD RAID sinhronizāciju veica inženieri, lai gan dažiem no viņiem pat nebija piekļuves to darÄ«t. Daži vadoÅ”ie inženieri to darÄ«ja, bet ne vienmēr, jo process nekur nebija aprakstÄ«ts.
  • ProcedÅ«rai jābÅ«t vienkārÅ”ai un saprotamai.
    Cilvēkam ir grūti paturēt prātā daudzus soļus. Svarīgākie Jiras kaimiņu statusi ir jānovieto galvenajā ekrānā. Varat tos pārdēvēt, piemēram, mēs saucam Notiek Gatavs mainīt. Un citus statusus var paslēpt nolaižamajā izvēlnē, lai tie netraucētu. Bet labāk neierobežot cilvēkus, dot viņiem iespēju veikt pāreju.
    Izskaidrojiet inovācijas vērtÄ«bu. Kad cilvēki saprot, viņi vairāk pieņem jauno procedÅ«ru. Mums bija ļoti svarÄ«gi, lai cilvēki neklikŔķinātu cauri visam procesam, bet sekotu tam. Pēc tam mēs uz to izveidojām automatizāciju.
  • Pagaidiet, analizējiet, izdomājiet.
    Mums vajadzēja apmēram mēnesi, lai izveidotu procedÅ«ru, tehnisko realizāciju, sanāksmes un diskusijas. Un Ä«stenoÅ”ana aizņem vairāk nekā trÄ«s mēneÅ”us. Es redzēju, kā cilvēki pamazām sāk izmantot jauninājumu. AgrÄ«nā stadijā bija daudz negatÄ«visma. Bet tas bija pilnÄ«gi neatkarÄ«gs no paÅ”as procedÅ«ras un tās tehniskās Ä«stenoÅ”anas. Piemēram, viens administrators neizmantoja Jira, bet gan Jira spraudni Confluence, un dažas lietas viņam nebija pieejamas. Mēs viņam parādÄ«jām Jira, un administratora produktivitāte palielinājās gan vispārÄ«giem uzdevumiem, gan disku nomaiņai.

Diska nomaiņas automatizācija

Vairākas reizes mēs vērsāmies pie diska nomaiņas automatizācijas. Mums jau bija izstrādes un skripti, taču tie visi darbojās vai nu interaktÄ«vi, vai manuāli, un tiem bija nepiecieÅ”ama palaiÅ”ana. Un tikai pēc jaunās kārtÄ«bas ievieÅ”anas sapratām, ka tieÅ”i tā mums pietrÅ«kst.

Tā kā tagad mÅ«su nomaiņas process ir sadalÄ«ts posmos, no kuriem katram ir noteikts izpildÄ«tājs un darbÄ«bu saraksts, mēs varam iespējot automatizāciju pa posmiem, nevis visu uzreiz. Piemēram, vienkārŔāko posmu - Gatavs (pārbauda RAID/datu sinhronizāciju) var viegli deleģēt botam. Kad bots ir nedaudz iemācÄ«jies, varat dot tam svarÄ«gāku uzdevumu - diska ielikÅ”anu rotācijā utt.

Zoodārza iestatījumi

Pirms runājam par robotu, veiksim Ä«su ekskursiju mÅ«su instalāciju zoodārzā. Pirmkārt, tas ir saistÄ«ts ar mÅ«su infrastruktÅ«ras milzÄ«go izmēru. Otrkārt, mēs cenÅ”amies katram pakalpojumam izvēlēties optimālo aparatÅ«ras konfigurāciju. Mums ir aptuveni 20 aparatÅ«ras RAID modeļi, pārsvarā LSI un Adaptec, bet ir arÄ« dažādu versiju HP un DELL. Katram RAID kontrollerim ir sava pārvaldÄ«bas utilÄ«ta. Komandu kopa un to izdoÅ”ana var atŔķirties atkarÄ«bā no versijas katram RAID kontrollerim. Ja netiek izmantots HW-RAID, var izmantot mdraid.

GandrÄ«z visas jaunās instalācijas veicam bez diska dublÄ“Å”anas. Mēs cenÅ”amies vairs neizmantot aparatÅ«ras un programmatÅ«ras RAID, jo mēs dublējam savas sistēmas datu centra, nevis serveru lÄ«menÄ«. Bet, protams, ir jāatbalsta daudzi mantotie serveri.

Kaut kur RAID kontrolleru diski tiek pārsÅ«tÄ«ti uz neapstrādātām ierÄ«cēm, kaut kur tiek izmantoti JBOD. ServerÄ« ir konfigurācijas ar vienu sistēmas disku, un ja tas ir jānomaina, tad ir jāpārinstalē serveris ar OS un aplikāciju instalÄ“Å”anu, vienām un tām paŔām versijām, tad jāpievieno konfigurācijas faili, jāpalaiž aplikācijas. Ir arÄ« daudz serveru grupu, kurās dublÄ“Å”ana tiek veikta nevis diska apakÅ”sistēmas lÄ«menÄ«, bet tieÅ”i paŔās lietojumprogrammās.

Kopumā mums ir vairāk nekā 400 unikālu serveru grupu, kurās darbojas gandrÄ«z 100 dažādas lietojumprogrammas. Lai aptvertu tik milzÄ«gu iespēju skaitu, mums bija nepiecieÅ”ams daudzfunkcionāls automatizācijas rÄ«ks. Vēlams ar vienkārÅ”u DSL, lai ne tikai tas, kurÅ” uzrakstÄ«jis, var atbalstÄ«t.

Mēs izvēlējāmies Ansible, jo tas ir bez aÄ£entiem: nebija nepiecieÅ”ams sagatavot infrastruktÅ«ru, ātrs starts. Turklāt tas ir rakstÄ«ts Python valodā, kas komandā tiek pieņemts kā standarts.

Vispārējā shēma

Apskatīsim vispārējo automatizācijas shēmu, kā piemēru izmantojot vienu incidentu. Zabbix konstatē, ka sdb disks ir atteicies, iedegas sprūda, un Jira tiek izveidota biļete. Administrators to apskatīja, saprata, ka tas nav dublikāts un nav viltus pozitīvs, proti, disks jāmaina, un pārsūtīja biļeti uz Notiek.

Diska nomaiņas automatizācija ar Ansible
DiskoBot lietojumprogramma, kas rakstÄ«ta Python valodā, periodiski aptauj Jira jaunas biļetes. Tas pamana, ka ir parādÄ«jusies jauna biļete Notiek procesā, tiek aktivizēts atbilstoÅ”ais pavediens, kas palaiž rokasgrāmatu Ansible (tas tiek darÄ«ts katram statusam Jira). Å ajā gadÄ«jumā tiek palaists Prepare2change.

Ansible tiek nosūtīts uz resursdatoru, noņem disku no rotācijas un ziņo par statusu lietojumprogrammai, izmantojot Callbacks.

Diska nomaiņas automatizācija ar Ansible
Pamatojoties uz rezultātiem, robots automātiski pārsūta biļeti uz Gatavs mainīt. Inženieris saņem paziņojumu un dodas mainīt disku, pēc tam pārsūta biļeti uz Mainīts.

Diska nomaiņas automatizācija ar Ansible
Saskaņā ar iepriekÅ” aprakstÄ«to shēmu biļete tiek atgriezta robotā, kas palaiž citu rokasgrāmatu, nonāk resursdatorā un ieslēdz disku. Bots aizver biļeti. Urrā!

Diska nomaiņas automatizācija ar Ansible
Tagad parunāsim par dažām sistēmas sastāvdaļām.

Diskobots

Å Ä« lietojumprogramma ir uzrakstÄ«ta Python valodā. Tas izvēlas biļetes no Jira saskaņā ar JQL. AtkarÄ«bā no biļetes statusa, tā nonāk atbilstoÅ”ajam apdarinātājam, kas savukārt palaiž statusam atbilstoÅ”u Ansible rokasgrāmatu.

JQL un aptaujas intervāli ir definēti lietojumprogrammas konfigurācijas failā.

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

Piemēram, no biļetēm statusā Notiek tiek atlasÄ«tas tikai tās, kurās ir aizpildÄ«ti lauki Diska lielums un IerÄ«ces nosaukums. IerÄ«ces nosaukums ir bloka ierÄ«ces nosaukums, kas nepiecieÅ”ams rokasgrāmatas izpildei. Diska izmērs ir nepiecieÅ”ams, lai inženieris zinātu, kāda izmēra disks ir nepiecieÅ”ams.

Un starp biļetēm ar statusu Gatavs tiek filtrētas biļetes ar iezÄ«mi dbot_ignore. Starp citu, mēs izmantojam Jira etiÄ·etes gan Ŕādai filtrÄ“Å”anai, gan biļeÅ”u dublikātu atzÄ«mÄ“Å”anai un statistikas vākÅ”anai.

Ja rokasgrāmata neizdodas, Jira pieŔķir etiÄ·eti dbot_failed, lai to vēlāk varētu sakārtot.

Sadarbspēja ar Ansible

Lietojumprogramma sazinās ar Ansible, izmantojot Ansible Python API. Programmai playbook_executor mēs nododam faila nosaukumu un mainīgo lielumu kopu. Tas ļauj saglabāt Ansible projektu parastu yml failu veidā, nevis aprakstīt to Python kodā.

ArÄ« Ansible, izmantojot *extra_vars*, bloķētās ierÄ«ces nosaukums, biļetes statuss, kā arÄ« callback_url, kurā ir izdoÅ”anas atslēga - to izmanto atzvanÄ«Å”anai HTTP.

Katrai palaiÅ”anai tiek Ä£enerēts pagaidu inventārs, kas sastāv no viena saimniekdatora un grupas, kurai pieder Å”is resursdators, lai tiktu lietoti group_vars.

Å eit ir piemērs uzdevumam, kas ievieÅ” HTTP atzvanÄ«Å”anu.

Mēs iegÅ«stam rezultātu, izpildot rokasgrāmatas, izmantojot atzvanÄ«Å”anu(-as). Tie ir divu veidu:

  • Iespējamais atzvanÄ«Å”anas spraudnis, tas sniedz datus par rokasgrāmatas izpildes rezultātiem. Tajā ir aprakstÄ«ti uzdevumi, kas tika uzsākti, veiksmÄ«gi vai neveiksmÄ«gi pabeigti. Å is atzvans tiek izsaukts, kad rokasgrāmatas atskaņoÅ”ana ir pabeigta.
  • HTTP atzvanÄ«Å”ana, lai saņemtu informāciju, atskaņojot rokasgrāmatu. Ansible uzdevumā mēs izpildām POST/GET pieprasÄ«jumu mÅ«su lietojumprogrammai.

MainÄ«gie tiek nosÅ«tÄ«ti caur HTTP atzvanÄ«Å”anu, kas tika definēti rokasgrāmatas izpildes laikā un kurus mēs vēlamies saglabāt un izmantot turpmākajās izpildēs. Mēs ierakstām Å”os datus sqlite.

Mēs arÄ« atstājam komentārus un mainām biļetes statusu, izmantojot HTTP atzvanÄ«Å”anu.

HTTP atzvanīŔana

# 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

Tāpat kā daudzus viena veida uzdevumus, mēs to ievietojam atseviŔķā kopējā failā un, ja nepiecieÅ”ams, iekļaujam, lai tas nepārtraukti neatkārtotos rokasgrāmatās. Tas ietver atzvanÄ«Å”anas_ url, kurā ir problēmas atslēga un resursdatora nosaukums. Kad Ansible izpilda Å”o POST pieprasÄ«jumu, robots saprot, ka tas notika kā daļa no Ŕāda un tāda incidenta.

Un Å”eit ir piemērs no rokasgrāmatas, kurā mēs izvadām disku no MD ierÄ«ces:

  # 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

Å is uzdevums pārceļ Jira biļeti uz statusu ā€œGatavs mainÄ«tā€ un pievieno komentāru. ArÄ« mainÄ«gais mdam_data saglabā to md ierīču sarakstu, no kurām disks tika noņemts, un parted_info saglabā nodalÄ«juma izdruku no parted.

Kad inženieris ievieto jaunu disku, mēs varam izmantot Å”os mainÄ«gos, lai atjaunotu partition dump, kā arÄ« ievietotu disku tajās md ierÄ«cēs, no kurām tas tika noņemts.

Iespējamais pārbaudes režīms

Bija bail ieslēgt automātiku. Tāpēc mēs nolēmām palaist visas rokasgrāmatas režīmā
sausā gaita, kurā Ansible neveic nekādas darbības serveros, bet tikai emulē tās.

Šāda palaiŔana tiek palaista caur atseviŔķu atzvanīŔanas moduli, un rokasgrāmatas izpildes rezultāts tiek saglabāts Jira kā komentārs.

Diska nomaiņas automatizācija ar Ansible

Pirmkārt, tas ļāva apstiprināt robotprogrammatūras un rokasgrāmatu darbību. Otrkārt, tas palielināja administratoru uzticību robotam.

Kad mēs izturējām validāciju un sapratām, ka Ansible var palaist ne tikai sausās darbÄ«bas režīmā, mēs Jira izveidojām pogu Palaist Diskobot, lai palaistu to paÅ”u rokasgrāmatu ar tiem paÅ”iem mainÄ«gajiem tajā paŔā resursdatorā, bet parastajā režīmā.

Turklāt poga tiek izmantota, lai restartētu rokasgrāmatu, ja tā avarē.

Playbooks struktūra

Es jau minēju, ka atkarībā no Jira biļetes statusa robots palaiž dažādas rokasgrāmatas.

Pirmkārt, ir daudz vieglāk organizēt ieeju.
Otrkārt, dažos gadījumos tas ir vienkārŔi nepiecieŔams.

Piemēram, nomainot sistēmas disku, vispirms ir jādodas uz izvietoÅ”anas sistēmu, jāizveido uzdevums, un pēc pareizas izvietoÅ”anas serveris kļūs pieejams, izmantojot ssh, un tajā varēsiet izvērst lietojumprogrammu. Ja mēs to visu darÄ«tu vienā rokasgrāmatā, Ansible to nevarētu pabeigt, jo saimniekdators nav pieejams.

Katrai serveru grupai mēs izmantojam Ansible lomas. Šeit varat redzēt, kā vienā no tām ir sakārtota(-as) rokasgrāmata(-as).

Diska nomaiņas automatizācija ar Ansible

Tas ir ērti, jo uzreiz ir skaidrs, kur atrodas uzdevumi. Vietnē main.yml, kas ir lomas Ansible ievade, mēs varam vienkārÅ”i iekļaut pēc biļetes statusa vai vispārÄ«gus uzdevumus, kas nepiecieÅ”ami ikvienam, piemēram, identifikācijas nodoÅ”ana vai marÄ·iera saņemÅ”ana.

izmeklēŔana.yml

Darbojas pēc biļetēm statusā IzmeklÄ“Å”ana un Atvērts. VissvarÄ«gākais Å”ajā rokasgrāmatā ir bloka ierÄ«ces nosaukums. Å Ä« informācija ne vienmēr ir pieejama.

Lai to iegÅ«tu, mēs analizējam Jira kopsavilkumu, pēdējo vērtÄ«bu no Zabbix aktivizētāja. Tajā var bÅ«t bloka ierÄ«ces nosaukums - laimÄ«gs. Vai arÄ« tajā var bÅ«t montÄ“Å”anas punkts, tad jums jāiet uz serveri, parsē un jāaprēķina nepiecieÅ”amais disks. SprÅ«da var arÄ« pārsÅ«tÄ«t scsi adresi vai kādu citu informāciju. Bet gadās arÄ« tā, ka nav nekādu pavedienu, un jums ir jāanalizē.

Noskaidrojot blokierÄ«ces nosaukumu, mēs no tā apkopojam informāciju par diska veidu un izmēru, lai aizpildÄ«tu laukus Jira. Mēs arÄ« noņemam informāciju par pārdevēju, modeli, programmaparatÅ«ru, ID, SMART un ievietojam to visu komentārā Jira biļetē. Administratoram un inženierim Å”ie dati vairs nav jāmeklē. šŸ™‚

Diska nomaiņas automatizācija ar Ansible

sagatavot2mainīt.yml

Diska noņemÅ”ana no rotācijas, sagatavoÅ”ana nomaiņai. GrÅ«tākais un svarÄ«gākais posms. Å eit varat apturēt lietojumprogrammu, kad to nevajadzētu apturēt. Vai arÄ« izņemiet disku, kuram nebija pietiekami daudz kopiju, un tādējādi tas ietekmē lietotājus, zaudējot dažus datus. Å eit mums ir visvairāk čeku un paziņojumu tērzÄ“Å”anā.

VienkārŔākajā gadÄ«jumā mēs runājam par diska noņemÅ”anu no HW/MD RAID.

Sarežģītākās situācijās (mÅ«su krātuves sistēmās), kad dublÄ“Å”ana tiek veikta lietojumprogrammas lÄ«menÄ«, ir jādodas uz lietojumprogrammu caur API, jāziņo par diska izvadi, deaktivizējiet to un jāsāk atkopÅ”ana.

Tagad mēs masveidā migrējam uz mākonis, un, ja serveris ir balstÄ«ts uz mākoņiem, Diskobot izsauc mākoņa API, saka, ka tas darbosies ar Å”o minionu ā€” serveri, kurā darbojas konteineri, un prasa ā€œmigrēt visus konteinerus no Ŕī minionaā€. Un tajā paŔā laikā ieslēdz diska fona apgaismojumu, lai inženieris uzreiz redzētu, kurÅ” no tiem ir jāizvelk.

mainīts.yml

Pēc diska nomaiņas mēs vispirms pārbaudām tā pieejamību.

Inženieri ne vienmēr instalē jaunus diskus, tāpēc mēs pārbaudījām SMART vērtības, kas mūs apmierina.

Kādus atribūtus mēs skatāmies?Pārdalīto nozaru skaits (5) < 100
PaÅ”reizējais neapstiprināto sektoru skaits (107) == 0

Ja piedziņas tests neizdodas, inženierim tiek paziņots, ka tas ir jānomaina vēlreiz. Ja viss ir kārtībā, izslēdzas fona apgaismojums, tiek uzlikts marķējums un disks tiek pagriezts.

gatavs.yml

VienkārŔākais gadījums: HW/SW raid sinhronizācijas pārbaude vai datu sinhronizācijas pabeigŔana aplikācijā.

Lietojumprogrammas API

Esmu vairākas reizes minējis, ka robots bieži piekļūst lietojumprogrammu API. Protams, ne visām lietojumprogrammām bija nepiecieÅ”amās metodes, tāpēc tās bija jāmaina. Å eit ir norādÄ«tas vissvarÄ«gākās metodes, kuras mēs izmantojam:

  • Statuss. Klastera vai diska statuss, lai saprastu, vai ar to var strādāt;
  • Sākt/pārtraukt. Diska aktivizÄ“Å”ana/deaktivizÄ“Å”ana;
  • Migrēt/atjaunot. Datu migrācija un atjaunoÅ”ana nomaiņas laikā un pēc tās.

No Ansible gūtās mācības

Man ļoti patÄ«k Ansible. Taču bieži vien, skatoties uz dažādiem atvērtā pirmkoda projektiem un redzot, kā cilvēki raksta rokasgrāmatas, man kļūst mazliet bail. Sarežģītas loÄ£iskās mijiedarbÄ«bas kad/cilpa, elastÄ«bas un idempotences trÅ«kums biežas čaulas/komandas lietoÅ”anas dēļ.

Mēs nolēmām visu pēc iespējas vienkārÅ”ot, izmantojot Ansible priekÅ”rocÄ«bas ā€“ modularitāti. Augstākajā lÄ«menÄ« ir rokasgrāmatas; tās var rakstÄ«t jebkurÅ” administrators, treŔās puses izstrādātājs, kurÅ” nedaudz pārzina Ansible.

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

Ja kādu loģiku ir grūti ieviest rotaļu grāmatās, mēs to pārvietojam uz Ansible moduli vai filtru. Skriptus var rakstīt Python vai jebkurā citā valodā.

Tos ir viegli un ātri rakstÄ«t. Piemēram, diska fona apgaismojuma modulis, kura piemērs ir parādÄ«ts iepriekÅ”, sastāv no 265 rindām.

Diska nomaiņas automatizācija ar Ansible

Zemākajā lÄ«menÄ« ir bibliotēka. Å im projektam mēs uzrakstÄ«jām atseviŔķu lietojumprogrammu, kas ir sava veida abstrakcija pār aparatÅ«ras un programmatÅ«ras RAID, kas veic atbilstoÅ”os pieprasÄ«jumus.

Diska nomaiņas automatizācija ar Ansible

Ansible lielākās priekÅ”rocÄ«bas ir tā vienkārŔība un skaidras rokasgrāmatas. Es uzskatu, ka jums tas ir jāizmanto, nevis jāģenerē biedējoÅ”i yaml faili un milzÄ«gs skaits nosacÄ«jumu, čaulas koda un cilpu.

Ja vēlaties atkārtot mūsu pieredzi ar Ansible API, ņemiet vērā divas lietas:

  • Playbook_executor un playbooks kopumā nevar pieŔķirt taimautu. Ssh sesijā ir noildze, bet rokasgrāmatā nav taimauta. Ja mēģināsim atvienot disku, kas sistēmā vairs nepastāv, rokasgrāmata darbosies bezgalÄ«gi, tāpēc mums bija jāietver tā palaiÅ”ana atseviŔķā iesaiņojumā un jānogalina ar taimautu.
  • Ansible darbojas dakÅ”veida procesos, tāpēc tā API nav droÅ”a pavedienam. Visas mÅ«su rokasgrāmatas tiek izmantotas vienā pavedienā.

Rezultātā mēs varējām automatizēt aptuveni 80% disku nomaiņu. Kopumā aizstāŔanas lÄ«menis ir dubultojies. Å odien administrators vienkārÅ”i apskata incidentu un izlemj, vai disks ir jāmaina vai nē, un pēc tam veic vienu klikŔķi.

Bet tagad mēs sākam saskarties ar citu problēmu: daži jaunie administratori nezina, kā mainÄ«t diskus. šŸ™‚

Avots: www.habr.com

Pievieno komentāru