Përshëndetje të gjithëve. Unë punoj si admini kryesor në OK dhe përgjigjem për qëndrueshmërinë e portalit. Dua të flas për mënyrën si e ndërtuam procesin e zëvendësimit 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 në HighLoad+ 2018
Ndërtimi i procesit për zëvendësimin e disqeve
Fillimisht disa numra
OK është një shërbim gjigant që përdoret nga miliona njerëz. Ai mbështetet nga rreth 7,000 serverë, të vendosur në 4 data-qendra të ndryshme. Në serverë ka më shumë se 70,000 disqe. Nëse i vendosim një mbi tjetër, do të formohet një kullë me lartësi më shumë se 1 km.
Disqet e forta janë komponenti i serverit që prishet më shpesh. Me këto vëllime, na duhet të zëvendësojmë rreth 30 disqe në javë, dhe kjo procedurë është bërë një rutinë jo shumë e këndshme.
Incidentet
NĂ« kompaninĂ« tonĂ« Ă«shtĂ« vendosur njĂ« menaxhim i plotĂ« i incidenteve. Ădo incident regjistrohet nĂ« Jira dhe mĂ« pas zgjidhet dhe analizohet. NĂ«se ndodhi njĂ« incident me efekt pĂ«r pĂ«rdoruesit, ne patjetĂ«r mblidhemi dhe mendojmĂ« se si tĂ« reagojmĂ« mĂ« shpejt nĂ« raste tĂ« tilla, si tĂ« reduktojĂ« efektin dhe sigurisht si tĂ« parandalojmĂ« pĂ«rsĂ«ritjen.
Sistemet e ruajtjes nuk përbëjnë përjashtim. Gjendja e tyre monitorohet nga Zabbix. Ne monitorojmë mesazhet në Syslog për gabime në shkarkim/shkarkim, analizojmë gjendjen e HW/SW-raid-eve, monitorojmë SMART, për SSD llogarisim konsumimin.
Si janë ndryshuar disqet më parë
Kur një tregues ndizet në Zabbix, krijohet një incident në Jira dhe autmatikisht caktohet për inxhinierët përkatës në qendrat e të dhënave. Ne e bëjmë këtë për të gjithë incidentet HW, domethënë ato që kërkojnë ndonjë punë fizike me pajisjet në qëndrat e të dhënave.
Inxhinieri i qendrës së të dhënave është personi që zgjidh çështjet e lidhura me harduerin, përgjigjet për instalimin, mirëmbajtjen dhe heqjen e serverëve. Kur merr një biletë, inxhinieri fillon punën. Ai ndërron disqet në raftet e disqeve vetë. Por nëse nuk ka qasje në pajisjen e nevojshme, inxhinieri kërkon ndihmën e administratoreve sistematikë në detyrë. Së pari, duhet të nxirret disku nga rotacioni. Për këtë, nevojiten ndryshime të nevojshme në server, ndalimi i aplikacioneve, dhe shkëputja e disku.
Administratori sistematik në detyrë përgjatë turnit të punës merr përsipër funksionimin e të gjithë portalit. Ai heton incidentet, merret me riparime, ndihmon zhvilluesit të realizojnë detyra të vogla. Ai nuk merret vetëm me disqet e goditura.
Më parë, inxhinierët e qendrës së të dhënave komunikonin me administratorin e sistemit në një bisedë. Inxhinierët dërgonin lidhje për biletat e Jira, administratori i kalonte ato dhe mbante një regjistër pune në një shënim. Por për këto detyra, bisedat janë të paefektshme: informacioni atje nuk është i strukturuar dhe humbet shpejt. Po ashtu, administratori mund të largohej nga kompjuteri dhe për një kohë të caktuar të mos përgjigjej, ndërsa inxhinieri qëndronte pranë serverit me një paketë diskesh dhe prisje.
Por më e keqja ishte se administratorët nuk e shihnin tërë pamjen: cilat incidente diskesh ekzistojnë, ku mund të ndodhte një problem. Kjo vjen si pasojë që ne i japim të gjitha incidente HW inxhinierëve. Po, mund të shfaqeshin të gjitha incidentet në tabelën e administratorit. Por ato janë shumë, dhe administratori angazhohej vetëm për disa prej tyre.
Për më tepër, inxhinieri nuk mund të vendosë prioritetet në mënyrë të saktë, sepse ai nuk di asgjë për qëllimin e serverëve të caktuar, për shpërndarjen e informacionit në mbajtës.
Procedura e re e zëvendësimit
E para që ne bëmë, ishte të spostojmë të gjitha incidentet e diskut në një tip të veçantë "HW-disk" dhe të shtojmë fushat "emri i bllokut të pajisjes", "masa" dhe "tipi i diskut", në mënyrë që kjo informacion të ruhet në biletë dhe të mos jetë e nevojshme të shkëmbehet vazhdimisht në bisedë.
Po ashtu, u ra dakord që brenda një incidenti të qëndrojmë vetëm me një disk. Kjo e thjeshtoi ndjeshëm procesin e automatizimit, mbledhjen e statistikave dhe punën më vonë.
Përveç kësaj, u shtua fusha "administratori përgjegjës". Aty automatikisht vendoset administratori i turnit. Kjo është shumë e përshtatshme, sepse tani inxhinieri gjithmonë sheh se kush është përgjegjës. Nuk është e nevojshme të shkohet në kalendar dhe të kërkohet. Kjo fushë bëri të mundur që biletat ku mund të nevojitet ndihma e tij të dalin në panelin e administratorit.
Për të siguruar që të gjithë pjesëmarrësit të përfitojnë sa më shumë nga inovacionet, krijuam filtrat dhe panelin e kontrollit, dhe ua shpjeguam atyre. Kur njerëzit e kuptojnë ndryshimin, ata nuk e shohin atë si diçka të panevojshme. Për inxhinierin është e rëndësishme të dijë numrin e stendës ku ndodhet serveri, si dhe përmasat dhe tipin e diskut. Administratori duhet, në radhë të parë, të kuptojë se çfarë grupi serverësh është, dhe cilat mund të jenë efektet e zëvendësimit të diskut.
Prania e fushave dhe shfaqja e tyre është e dobishme, por kjo nuk na liron nga nevoja për të përdorur biseda. Për këtë, na duhej të ndryshonim procesin e punës.
Më parë, ai ishte kështu:
Sot inxhinierët vazhdojnë të punojnë kështu, kur nuk u nevojitet ndihma e administratorit.
E para që bëmë ishte të futnim një status të ri Investigate. Në këtë status, tiketi ndodhet kur inxhinieri ende nuk e ka vendosur nëse do t'i nevojitet ndihma e administratorit apo jo. Nëpërmjet këtij statusi, inxhinieri mund t'i kalojë tiketën administratorit. Përveç kësaj, me këtë status i ndajmë tiketët kur kërkohet zëvendësimi i diskut, por disku vetë nuk ndodhet në vend. Kjo ndodh në rastin e CDN-së dhe vendeve të largëta.
Gjithashtu, kemi shtuar një status Gati. Bëhet fjalë për një tiket që kalon pas shkëmbimit të diskut. Kjo do të thotë se gjithçka është bërë, por në server po sinkronizohet HW/SW RAID. Kjo mund të zgjasë mjaft gjatë.
Nëse për punë angazhohet një administrator, skema paksa kompliktohet.
Nga statusi E hapur tiketë mund të kalojë si administrator sistemi, ashtu edhe inxhinier. Në statusin Në proces administratori e nxjerr diskun nga rotacioni, në mënyrë që inxhinieri të mund ta nxjerrë lehtësisht: aktivizon ndriçimin, e demonton diskun, ndalon aplikacionet, varësisht nga grupi konkret i serverëve.
Pastaj tiketë kalon në Gati për të ndryshuar: ky është një sinjal për inxhinierin që disku mund të nxirret. Të gjitha fushat në Jira tashmë janë plotësuar, inxhinieri di se çfarë lloji dhe madhësie disku është. Këto të dhëna plotësohen automatikisht në statusin e mëparshëm ose nga administratori.
Pas shkëmbimit të diskut, tiketë kalon në statusin I ndryshuar. Kontrollohet nëse është vendosur disku i duhur, bëhet skanimi, aktivizohet aplikacioni dhe disa detyra për rikuperimin e të dhënave. Gjithashtu tiketë mund të kalojë në statusin Gati, në këtë rast përgjegjës do të mbetet administratori, sepse ai e futi diskun në rotacion. Skema e plotë duket kështu.
Shtimi i fushave të reja na e bëri jetën shumë më të lehtë. Djemtë filluan të punojnë me informacion të strukturuar, dhe u bë e qartë se çfarë duhet bërë dhe në cilin hap. Prioritetet u bënë shumë më relevante, pasi tani ato caktohen nga administratori.
Nuk ka më nevojë për biseda. Sigurisht, administratori mund t'i shkruajë inxhinierit "këtu duhet ta vendosësh më shpejt" ose "është mbrëmje, do të arrish ta zëvendësosh?". Por nuk komunikojmë më çdo ditë në biseda për këto çështje.
Diskët filluan të zëvendësohen në grupe. Nëse administratori ka ardhur në punë pak më herët, ka pak kohë të lirë, dhe asgjë nuk ka ndodhur, ai mund të përgatisë një sërë serverësh për zëvendësim: të vendosë fushat, të nxjerrë diskët nga rotacioni dhe t'i kalojë detyrën inxhinierit. Inxhinieri vjen më vonë në qendrën e të dhënave, sheh detyrën, merr depozitë të nevojshme dhe e zëvendëson menjëherë. Si rezultat, shpejtësia e zëvendësimit u rrit.
Eksperienca e nxjerrë nga ndërtimi i Workflow.
- Në ndërtimin e procedurës, është e nevojshme të mblidhen informatat nga burime të ndryshme.
Disa nga administratorët tanë nuk e dinin se inxhinieri i ndërron disqet vetë. Disa mendonin se inxhinierët kujdeseshin për sinkronizimin e RAID MD, ndonëse disa prej tyre as kishin akses për këtë. Disa inxhinierë të kryesisë e bënin këtë, por jo gjithmonë, sepse procesi nuk ishte asgjëkund i përshkruar. - Procedura duhet të jetë e thjeshtë dhe e kuptueshme.
Njeriu Ă«shtĂ« i vĂ«shtirĂ« tĂ« mbajĂ« mend shumĂ« hapa. Statuset mĂ« tĂ« rĂ«ndĂ«sishme qĂ« janĂ« ngjitur nĂ« Jira duhet tĂ« shfaqen nĂ« ekranin kryesor. Mund t'i rinovoni, pĂ«r shembull, 'In progress' ne e quajmĂ« 'Gati pĂ«r ndryshim'. Statuset e tjera mund tĂ« fshehen nĂ« njĂ« menĂŒ tĂ« rĂ«nĂ«, nĂ« mĂ«nyrĂ« qĂ« tĂ« mos jenĂ« pengesĂ« pĂ«r sytĂ«. Por Ă«shtĂ« mĂ« mirĂ« tĂ« mos i kufizoni njerĂ«zit, duhet t'u jepni mundĂ«sinĂ« tĂ« bĂ«jnĂ« kalimin.
Shpjegoni vlerën e inovacioneve. Kur njerëzit kuptojnë, ata e pranojnë më mirë procedurën e re. Për ne ishte shumë e rëndësishme që njerëzit të mos kalonin nëpër tërë procesin, por të ecin përmes tij. Më pas ne ndërtuam automatizimin mbi këtë. - Prisni, analizoni, ndihmoni.
Na na u shkoi rreth njĂ« muaji pĂ«r tĂ« ndĂ«rtuar procedurĂ«n, implementimin teknik, takimet dhe diskutimet. Dhe pĂ«r zbatimin â mĂ« shumĂ« se tre muaj. Kam parĂ« si njerĂ«zit filluan ngadalĂ« tĂ« pĂ«rdorin novacionin. NĂ« fazat e para kishte shumĂ« negativizĂ«m. Por kjo nuk varej aspak nga procedura vetĂ«, nga implementimi i saj teknik. PĂ«r shembull, njĂ« administrator vinte nĂ« pĂ«rdorim jo Jira, por njĂ« plugin tĂ« Jira nĂ« Confluence, dhe disa gjĂ«ra nuk ishin tĂ« disponueshme pĂ«r tĂ«. I treguam atij Jira, dhe produktiviteti i administratorit u rrit si nĂ« detyrat e pĂ«rgjithshme, ashtu edhe nĂ« zĂ«vendĂ«simet e disqeve.
Automatizimi i zëvendësimit të disqeve
Për automatizimin e zëvendësimit të disqeve, ne kemi ardhur disa herë. Ne kishim tashmë zhvillime, skenarë, por të gjitha ato punonin ose në mënyrë interaktive, ose në manual, duke kërkuar aktivizimin. Dhe vetëm pas implementimit të procedurës së re, ne kuptuam se pikërisht ajo na kishte munguar.
Tani qĂ« procesi i zĂ«vendĂ«simit Ă«shtĂ« ndarĂ« nĂ« etapa, ku pĂ«r secilĂ«n Ă«shtĂ« caktuar njĂ« ekzekutor dhe njĂ« listĂ« veprimesh, ne mund tĂ« pĂ«rfshijmĂ« automatizimin gradualisht, dhe jo menjĂ«herĂ«. PĂ«r shembull, etapa mĂ« e thjeshtĂ« â Ready (kontrolli i sinkronizimit RAID/ tĂ« dhĂ«nave) mund tĂ« delegohet lehtĂ« tek njĂ« bot. Kur boti tĂ« mĂ«sojĂ« pak mĂ« shumĂ«, mund t'i japim njĂ« detyrĂ« mĂ« tĂ« pĂ«rgjegjshme â futjen e disqeve nĂ« rotacion, etj.
Zoo e konfigurimeve
Para se tĂ« flasim pĂ«r botin, le tĂ« bĂ«jmĂ« njĂ« ekskursion tĂ« vogĂ«l nĂ« zoo-nĂ« e instalimeve tona. SĂ« pari, kjo lidhet me madhĂ«sinĂ« gjigande tĂ« infrastrukturĂ«s sonĂ«. SĂ« dyti, pĂ«r çdo shĂ«rbim pĂ«rpiqemi tĂ« zgjedhim konfigurimin optimal tĂ« pajisjes. Kemi rreth 20 modele tĂ« RAID-it harduerik, kryesisht LSI dhe Adaptec, por ka edhe HP dhe DELL tĂ« versioneve tĂ« ndryshme. Ădo kontrollues RAID ka utilitarin e tij tĂ« menaxhimit. Grupi i komandave dhe rezultati i tyre mund tĂ« ndryshojnĂ« nga versioni nĂ« version pĂ«r çdo kontrollues RAID. Atje ku nuk pĂ«rdoren HW-RAID, mund tĂ« ketĂ« mdraid.
Praktikisht të gjitha instalimet e reja i realizojmë pa rezervim diskesh. Ne përpiqemi të mos përdorim më RAID harduerik dhe softuerik, pasi që rezervojmë sistemet tona në nivelin e qendrave të të dhënave dhe jo të serverëve. Por, natyrisht, ka shumë serverë legacy që duhen mbështetur.
Diku disqet në RAID-kontrollerët kalohen si pajisje raw, diku përdoren JBOD. Ka konfiguracione me një disk sistemik në server, dhe nëse ai duhet të zëvendësohet, atëherë duhet të riparosen serveri me instalimin e OS-së dhe aplikacioneve, madje edhe versionet e tingjuara, pastaj të shtohen skedarët e konfigurimit dhe të fillohen aplikacionet. Po ashtu, ka shumë grupe serverësh, ku rezervimi bëhet jo në nivelin e sistemit të diskut, por direkt në vetë aplikacionet.
Në total, ne kemi më shumë se 400 grupe unike serverësh, ku punojnë rreth 100 aplikacione të ndryshme. Për të mbuluar një numër kaq të madh opsionesh, na duhej një mjet shumë-funksional automatizimi. Preferohet një DSL i thjeshtë, që të mbështesë jo vetëm ata që e shkruan.
Ne zgjodhëm Ansible sepse ai është pa agjent: nuk ishte e nevojshme të përgatitej infrastruktura, fillim i shpejtë. Për më tepër, ai është shkruar në Python, i cili është pranuar si standard në ekip.
Schema e përgjithshme
Le të shqyrtojmë skemën e përgjithshme të automatizimit përmes një incidenti të vetëm. Zabbix e detecton se disku sdb ka dështuar, ndizet një trigger, krijohet një biletë në Jira. Administratorit e sheh atë, e kupton se nuk është një dublikat dhe as një false positive, që do të thotë se duhet të ndryshohet disku dhe e kalon biletën në In progress.
Aplikacioni DiskoBot, i shkruar në Python, pyet periodikisht Jira për bileta të reja. Ai vëren se ka një biletë të re In progress, aktivizohet thread-i përkatës, i cili nis playbook-un në Ansible (kjo bëhet për çdo status në Jira). Në këtë rast, niset Prepare2change.
Ansible dërgohet në host, e nxjerr diskun nga rotacioni dhe raporton statusin aplikacionit përmes Callbacks.
Në përfundim, boti automatikisht e kalon biletën në Ready to change. Inxhinieri merr një njoftim dhe niset për ta ndërruar disku, pas të cilit e kalon biletën në Changed.
Sipas skemës së përshkruar më sipër, tiketi kthehet përsëri te boti, i cili nis një playbook tjetër, shkon në host dhe fut diskun në rotacion. Boti mbyll tiketën. Hurrah!
Tani le të flasim për disa komponente të sistemit.
Diskobot
Ky aplikacion është shkruar në Python. Ai zgjedh tiketë nga Jira në përputhje me JQL. Në varësi të statusit të tiketës, ajo kalon te përpunuesi përkatës, i cili nga ana e tij nis playbook-un Ansible përkatës.
JQL dhe intervalet e sondazhit 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 tiketĂ«ve nĂ« statusin In progress, zgjedhen vetĂ«m ato pĂ«r tĂ« cilat janĂ« plotĂ«suar fushat Disk size dhe Device name. Device name â Ă«shtĂ« emri i pajisjes bllokuese, e nevojshme pĂ«r ekzekutimin e playbook-it. Disk size nevojitet qĂ« inxhinieri tĂ« dijĂ« se sa i madh Ă«shtĂ« disku qĂ« kĂ«rkohet.
Dhe midis tiketëve me statusin Ready filtrohen tiketët me etiketën dbot_ignore. Duke folur, etiketat e Jira i përdorim si për filtrimin e tillë, ashtu edhe për markimin e kopjeve të tiketëve dhe për mbledhjen e statistikave.
Në rast të një dështimi të playbook-it, Jira i jep etiketën dbot_failed për t'u bërë më pas e mundur zgjidhja e problemit.
Interaksioni me Ansible
Aplikacioni ndërvepron me Ansible përmes . Në playbook_executor ne kalojmë emrin e skedarit dhe një grup variablash. Kjo lejon që projekti Ansible të mbahet si skedarë normalë yml dhe të mos përshkruhet në kodin Python.
Gjithashtu nĂ« Ansible pĂ«rmes *extra_vars* kalohen emri i pajisjes bllokuese, statusi i biletĂ«s, si dhe callback_url, ku Ă«shtĂ« i koduar çelĂ«si i problemit â ai pĂ«rdoret pĂ«r callback nĂ« HTTP.
Për çdo ekzekutim krijohet një inventar i përkohshëm, i përbërë nga një host dhe grupi, në të cilin hyn ky host, në mënyrë që të aplikohen group_vars.
Ja një shembull i një detyre, në të cilën realizohet callback HTTP.
Ne marrim rezultatet e ekzekutimit të playbook-eve përmes callback(-eve). Ato janë të dy llojeve:
- , ai ofron të dhëna mbi rezultatet e ekzekutimit të playbook-it. Atje përshkruhen detyrat që janë nisur, ekzekutuar me sukses ose jo. Ky callback thirret pas përfundimit të ekzekutimit të playbook-it.
- HTTP callback për të marrë informacione gjatë ekzekutimit të playbook-it. Në detyrën Ansible kemi ekzekutuar një kërkesë POST/GET drejt aplikacionit tonë.
PĂ«rmes HTTP callback(-eve) transmetohen variablat qĂ« janĂ« pĂ«rcaktuar gjatĂ« ekzekutimit tĂ« playbookâit dhe qĂ« ne duam tâi ruajmĂ« dhe tĂ« pĂ«rdorim nĂ« ekzekutimet e ardhshme. KĂ«to tĂ« dhĂ«na i shkruajmĂ« nĂ« sqlite.
Po ashtu përmes HTTP callback ne lëmë komente dhe ndryshojmë statusin e tiketës.
HTTP callback
# Make callback to Diskobot App
# Variables:
# callback_post_body: # A dict with follow keys. All keys are optional
# msg: If exist it would be posted to Jira as comment
# data: If exist it would be saved in Incident.variables
# desire_state: Set desire_state for incident
# status: If exist Proceed issue to that status
- name: Callback to Diskobot app (jira comment/status)
uri:
url: "{{ callback_url }}/{{ devname }}"
user: "{{ diskobot_user }}"
password: "{{ diskobot_pass }}"
force_basic_auth: True
method: POST
body: "{{ callback_post_body | to_json }}"
body_format: json
delegate_to: 127.0.0.1
Si shumë detyra të ngjashme, ne e nxorrëm këtë në një skedar të përbashkët dhe e përfshimë kur nevojitet, për të mos e përsëritur vazhdimisht në playbook. Këtu figuron callback_url, në të cilin janë koduar çelësi i problemit dhe emri i hostit. Kur Ansible ekzekuton këtë POST kërkesë, boti kupton që ajo ka ardhur në kuadër të një incidenti të caktuar.
Ja një shembull nga playbook, në të cilin ne nxorrëm diskun nga pajisja 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 kalon tiketĂ«n Jira nĂ« statusin 'Ready to change' dhe shton njĂ« koment. Po ashtu nĂ« variablen mdam_data ruhet lista e pajisjeve md nga tĂ« cilat Ă«shtĂ« hequr disku, ndĂ«rsa nĂ« parted_info â dump-i i particionit nga parted.
Kur inxhinieri të vendosë një disk të ri, ne do të mund ta përdorim këto variabla për të rikthyer dump-in e particioneve, si dhe për ta regjistruar diskun në ato pajisje md nga të cilat është hequr.
Reagimi i Ansible
Ishte frikshëm të aktivizohej automatizimi. Prandaj, ne vendosëm të ekzekutonim të gjitha playbook-et në mod.
, në të cilin Ansible nuk bën asnjë veprim në servera, por vetëm i imiton ato.
Një nisje e tillë kalon përmes një moduli të veçantë callback, dhe rezultati i ekzekutimit të playbook-it ruhet në Jira si një koment.
Së pari, kjo e mundësoi të validonim punën e bot-it dhe të playbook-eve. Së dyti, rriti besimin e administratorëve ndaj bot-it.
Kur kaluam validimin dhe kuptuam se mund të nisim Ansible jo vetëm në modalitetin dry run, krijuam në Jira një buton Run Diskobot për të nisur të njëjtin playbook me të njëjtat variabla në të njëjtin host, por në modalitetin normal.
Për më tepër, butoni përdoret për të ripërsëritur nisjen e playbook-it në rast të dështimit të tij.
Struktura e Playbook-eve
Kisha përmendur tashmë se në varësi të statusit të tiketës në Jira, boti nis playbook-e të ndryshme.
Së pari, kështu është shumë më e lehtë të organizohet hyrja.
Së dyti, në disa raste, kjo është thjesht e nevojshme.
Për shembull, kur zëvendësoni diskun e sistemit, së pari duhet të shkoni te sistemi i implementimit, të krijoni një detyrë dhe pas implementimit të suksesshëm, serveri do të bëhet i aksesueshëm përmes ssh, dhe mund të instaloni aplikacionin atje. Po të bënim të gjitha këto në një playbook, Ansible nuk do të ishte në gjendje ta ekzekutonte për shkak të papërshtatshmërisë së hostit.
Ne përdorim role Ansible për çdo grup serverash. Këtu tregohet si janë organizuar playbook-et në një nga to.
Kjo është e përshtatshme, sepse menjëherë shihet ku janë të vendosura detyrat. Në main.yml, i cili është hyrja për rolin Ansible, mund të kemi thjesht përfshirje sipas statusit të biletës ose detyrat e përgjithshme që janë të nevojshme për të gjithë, si identifikimi ose marrja e një tokeni.
Investigation.yml
Niset për biletat në statusin Investigation dhe Open. E rëndësishmja për këtë playbook është emri i pajisjes bllokuese. Kjo informacion nuk është gjithmonë e disponueshme.
PĂ«r ta marrĂ« atĂ«, analizojmĂ« pĂ«rmbledhjet e Jira-s dhe vlerĂ«n e fundit nga Zabbix-trigger. Aty mund tĂ« ketĂ« emrin e njĂ« pajisjeje bllokuese â me fat. Ose mund tĂ« ketĂ« njĂ« pikĂ« bashkĂ«ngjitjeje, â atĂ«herĂ« duhet tĂ« shkojmĂ« nĂ« server, tĂ« analizojmĂ« dhe tĂ« llogarisim diskun e duhur. Gjithashtu, triggeri mund tĂ« transmetojĂ« adresĂ«n scsi ose ndonjĂ« informacion tjetĂ«r. Por ndonjĂ«herĂ« nuk ka asnjĂ« gjurmĂ«, dhe duhet tĂ« bĂ«jmĂ« analiza.
Pasi tĂ« kemi zbuluar emrin e pajisjes bllokuese, mbledhim informacion rreth llojit dhe madhĂ«sisĂ« sĂ« diskut pĂ«r tĂ« plotĂ«suar fushat nĂ« Jira. Po ashtu, ne marrim informacion mbi prodhuesin, modelin, firmware, ID-nĂ«, SMART, dhe gjithĂ« kĂ«tĂ« e fusim nĂ« komentin nĂ« Jira-ticket. Administratorit dhe inxhinierit tani nuk u nevojitet tĂ« kĂ«rkojnĂ« kĂ«to tĂ« dhĂ«na. đ
prepare2change.yml
Nxjerrja e diskut nga rotacioni, pĂ«rgatitja pĂ«r zĂ«vendĂ«sim. ĂshtĂ« faza mĂ« e vĂ«shtirĂ« dhe mĂ« e rĂ«ndĂ«sishme. KĂ«tu mund tĂ« ndaloni aplikacionin, kur nuk mund tĂ« ndalet. Ose tĂ« nxirrni diskun qĂ« kishte mungesĂ« replikash, duke ndikuar kĂ«shtu tek pĂ«rdoruesit, duke humbur ndonjĂ« tĂ« dhĂ«nĂ«. KĂ«tu kemi mĂ« shumĂ« verifikime dhe njoftime nĂ« chat.
Në rastin më të thjeshtë, flitet për heqjen e diskut nga HW/MD RAID.
Në situata më të komplikuara (në sistemet tona të ruajtjes), kur rezervimi kryhet në nivelin e aplikacionit, duhet të hyjmë në aplikacion përmes API-së, të raportojmë për daljen e diskut, ta deaktivizojmë dhe të fillojmë rikuperimin.
Ne tani po migrojmë masivisht në , dhe nëse serveri është në cloud, atëherë Diskobot i drejtohet API-së së cloud-it, i thotë se do të punojë me këtë mini- server, ku janë të hapura kontejnerët, dhe kërkon "migro gjithë kontejnerët nga ky mini-server". Njëherësh aktivizon ndriçimin e diskut, në mënyrë që inxhinieri të shohë menjëherë se cili duhet të zgjidhet.
changed.yml
Pas zëvendësimit të diskut, në radhë të parë kontrollojmë që të jetë i qasshëm.
Inxhinierët nuk i vendosin gjithmonë diskët e rinj, prandaj ne shtuam një kontroll të vlerave SMART që na përmbushin.
Cilat atribute shikojmëReallocated Sectors Count (5) < 100
Current Pending Sector Count (107) == 0
Nëse disku nuk kalon kontrollin, inxhinierit i njoftohet për një zëvendësim të dytë. Nëse gjithçka është në rregull, ndriçimi fiket, shenjat vendosen dhe disku futet në rotacion.
ready.yml
Rasti më i thjeshtë: kontrollimi i sinkronizimit HW/SW raid ose përfundimi i sinkronizimit të të dhënave në aplikacion.
API aplikacionesh
Kam përmendur disa herë se boti shpesh i qaset API-ve të aplikacioneve. Sigurisht, nuk e kanë të gjitha aplikacionet metodat e kërkuara, kështu që duhej të punonim për to. Këtu janë metodat më të rëndësishme që përdorim:
- Statusi. Statusi i klasit ose diskut, për të kuptuar nëse mund të punojmë me të;
- Nis/ndal. Aktivizimi-deaktivizimi i diskut;
- Migroj/rikthe. Migrimi dhe rikthimi i të dhënave gjatë dhe pas zëvendësimit.
Eksperiencë e nxjerrë nga Ansible
E dua shumë Ansible. Por shpesh, kur shoh projekte të ndryshme opensource dhe shoh si njerëzit shkruajnë playbook-e, më bën pak frikë. Ndërthurje të komplikuara logjike nga when/loop, mungesë fleksibiliteti dhe idempotence për shkak të përdorimit të shpeshtë të shell/command.
Ne vendosĂ«m ta thjeshtojmĂ« sa mĂ« shumĂ«, duke shfrytĂ«zuar pĂ«rparĂ«sitĂ« e Ansible â modularitetin. NĂ« nivelin mĂ« tĂ« lartĂ« janĂ« playbook-et, tĂ« cilat mund t'i shkruajĂ« çdo administrator, zhvillues i jashtĂ«m qĂ« di pak pĂ«r 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 ndonjë logjikë është e vështirë të implementohet në playbook-a, ne e transferojmë atë në një modul ose filtrin Ansible. Skriptet mund të shkruhen si në Python, ashtu edhe në ndonjë gjuhë tjetër.
Ata janë të lehtë dhe të shpejtë për t'u shkruar. Për shembull, moduli i ndriçimit të diskut, një shembull përdorimi i të cilit është paraqitur më sipër, përbëhet nga 265 rreshta.
Në nivelin më të ulët ndodhet biblioteka. Për këtë projekt ne shkruam një aplikacion të veçantë, një lloj abstraksioni mbi RAID-in harduerik dhe softuerik, i cili realizon kërkesat përkatëse.
Pikat më të forta të Ansible janë thjeshtësia dhe playbook-at e kuptueshëm. Unë mendoj se duhet të përfitoni prej tyre dhe të mos gjeneroni skedarë yaml të tmerrshëm me një sasi të madhe kushtesh, kodi shell dhe ciklesh.
Nëse dëshironi të përsërisni përvojën tonë me Ansible API, mbani parasysh dy gjëra:
- Playbook_executor dhe në përgjithësi playbook-ut nuk mund t'i kaloni një timeout. Ekziston një timeout në sesionet ssh, por nuk ka timeout për playbook. Nëse përpiqemi të çmontojmë një disk që nuk ekziston më në sistem, playbook do të ekzekutohet pafundësisht, prandaj kemi dashur ta mbështjellim ekzekutimin e tij në një wrapper të veçantë dhe ta ndalojmë sipas timeout-it.
- Ansible funksionon mbi bazën e proceseve fork, prandaj API i tij nuk është i sigurt për përdorim në mënyrë të shumëfishtë. Ne i ekzekutojmë të gjitha playbook-t tona njëkohësisht.
Në fund arritëm të automatizojmë zëvendësimin e rreth 80% të disqeve. Në përgjithësi, shpejtësia e zëvendësimit u rrit me dy herë. Sot administratorët thjesht shikojnë incidentin dhe vendosin nëse duhet të zëvendësojnë diskun apo jo, dhe më pas bëjnë një klik.
Por tani po fillojmĂ« tĂ« pĂ«rballim me njĂ« problem tjetĂ«r: disa administratorĂ« tĂ« rinj nuk dinĂ« si tĂ« zĂ«vendĂ«sojnĂ« diskĂ«t. đ
Burimi: habr.com
