Kaixo guztioi. OK-n sistema administratzaile nagusi gisa lan egiten dut eta atariaren funtzionamendu egonkorraz arduratzen naiz. Diskoak automatikoki ordezkatzeko prozesu bat nola eraiki genuen eta, ondoren, administratzailea prozesu honetatik baztertu eta bot batekin ordeztu genuenari buruz hitz egin nahi dut.
Artikulu hau transliterazio moduko bat da HighLoad+ 2018-n
Diskoa ordezkatzeko prozesu bat eraikitzea
Lehenengo zenbaki batzuk
OK milioika pertsonek erabiltzen duten zerbitzu erraldoia da. 7 mila zerbitzari inguruk zerbitzatzen dute, 4 datu-zentro desberdinetan daudenak. Zerbitzariek 70 mila disko baino gehiago dituzte. Bata bestearen gainean pilatzen badituzu, km 1 baino gehiagoko dorre bat lortuko duzu.
Disko gogorrak gehien huts egiten duen zerbitzariaren osagaia dira. Bolumen horiekin, astean 30 disko inguru aldatu behar ditugu, eta prozedura hau errutina ez oso atsegina bihurtu da.
Gorabeherak
Gure enpresak gertakarien kudeaketa osoa aurkeztu du. Gorabehera bakoitza Jiran grabatzen dugu, eta gero konpontzen eta konpontzen dugu. Gorabeherak erabiltzaileengan eragina izan badu, behin betiko elkartzen gara eta pentsatzen dugu nola erantzun azkarrago horrelako kasuetan, nola murriztu eragina eta, jakina, nola ez errepikatzea.
Biltegiratze gailuak ez dira salbuespena. Zabbixek kontrolatzen du haien egoera. Syslog-en mezuak kontrolatzen ditugu idazketa/irakurketa akatsak ikusteko, HW/SW raid-en egoera aztertzen dugu, SMART kontrolatzen dugu eta SSDen higadura kalkulatzen dugu.
Lehen diskoak nola aldatzen ziren
Zabbixen abiarazle bat gertatzen denean, gertakari bat sortzen da Jiran eta automatikoki esleitzen zaie datu-zentroetako ingeniari egokiei. Hori HWko gorabehera guztiekin egiten dugu, hau da, datu-zentroko ekipoekin edozein lan fisiko behar dutenekin.
Datu-zentroko ingeniaria hardwarearekin lotutako arazoak konpontzen dituen pertsona da eta zerbitzariak instalatu, mantendu eta desegiteaz arduratzen da. Tiketa jasota, ingeniaria lanari ekin dio. Disko-apaletan diskoak modu independentean aldatzen ditu. Baina beharrezkoa den gailurako sarbidea ez badu, ingeniariak guardiako sistema-administratzaileengana jotzen du laguntza eske. Lehenik eta behin, diskoa errotaziotik kendu behar duzu. Horretarako, zerbitzarian beharrezko aldaketak egin, aplikazioak gelditu eta diskoa desmuntatu behar dituzu.
Laneko txandan zehar atari osoaren funtzionamenduaz arduratuko da sistema-administratzailea guardian. Gertaerak ikertzen ditu, konponketak egiten ditu eta garatzaileei lan txikiak egiten laguntzen die. Ez du disko gogorrekin bakarrik jorratzen.
Aurretik, datu-zentroko ingeniariak sistemaren administratzailearekin komunikatzen ziren txat bidez. Ingeniariek Jira txarteletarako estekak bidali zituzten, administratzaileak jarraitu egin zituen, lanaren erregistroa koaderno batzuetan gordetzen zuen. Baina txatak deserosoak dira horrelako zereginetarako: hango informazioa ez dago egituratuta eta azkar galtzen da. Eta administratzaileak ordenagailutik aldendu eta eskaerei erantzun ez diezaiekeen denbora batez, ingeniaria zerbitzarian disko pila batekin zegoen bitartean itxaron.
Baina okerrena izan zen administratzaileek ez zutela argazki osoa ikusten: zer disko-intzidentzia zeuden, non arazo bat sor zitekeen. Hau da, HWko gorabehera guztiak ingeniarien esku uzten ditugulako. Bai, gertakari guztiak administratzailearen panelean bistaratu ahal izan dira. Baina asko dira, eta administratzaileak horietako batzuentzat bakarrik parte hartzen zuen.
Horrez gain, ingeniariak ezin izan ditu lehentasunak behar bezala ezarri, zerbitzari zehatzen helburuaz edo informazioa diskoen artean banatzeaz ez baitaki ezer.
Ordezkatzeko prozedura berria
Egin genuen lehenengo gauza diskoaren gorabehera guztiak "HW disk" mota bereizi batera eramatea izan zen eta "blokeatu gailuaren izena", "tamaina" eta "disko mota" eremuak gehitu zitzaizkion, informazio hori txartelean gordetzeko eta Txatean etengabe trukatu beharrik ez izatea.
Gertakari batean disko bakarra aldatuko genuela ere adostu genuen. Horrek nabarmen erraztu zituen automatizazio prozesua, estatistikak biltzea eta etorkizuneko lana.
Horrez gain, "administratzaile arduratsua" eremua gehitu dugu. Zerbitzuan dagoen sistema-administratzailea automatikoki txertatzen da bertan. Hau oso erosoa da, orain ingeniariak beti ikusten baitu nor den ardura. Ez da egutegira joan eta bilatu beharrik. Eremu hori izan zen bere laguntza behar izan zezakeen administratzailearen aginte-panelean txartelak bistaratzeko aukera eman zuena.
Parte-hartzaile guztiek berrikuntzetatik etekinik handiena jaso zutela ziurtatzeko, iragazkiak eta aginte-panelak sortu genituen eta mutilei horien berri eman genien. Jendeak aldaketak ulertzen dituenean, ez dira haietatik urruntzen alferrikako zerbait bezala. Garrantzitsua da ingeniari batek zerbitzaria dagoen rack-zenbakia, tamaina eta disko mota jakitea. Administratzaileak, lehenik eta behin, ulertu behar du zer-nolako zerbitzari-talde hori eta zer eragin izan dezakeen disko bat ordezkatzean.
Eremuen presentzia eta haien bistaratzea komenigarria da, baina ez gaitu txatak erabiltzeko beharra salbatu. Horretarako, lan-fluxua aldatu behar izan dugu.
Aurretik honela zegoen:
Horrela jarraitzen dute lanean ingeniariek administratzaileen laguntzarik behar ez dutenean.
Egin genuen lehenengo gauza estatus berri bat sartzea izan zen Ikertu. Tiketa egoera horretan dago ingeniariak administratzaile bat beharko duen edo ez erabaki ez duenean oraindik. Egoera honen bidez, ingeniariak txartela administratzaileari transferi diezaioke. Gainera, egoera hori disko bat ordezkatu behar denean txartelak markatzeko erabiltzen dugu, baina diskoa bera ez dago gunean. Hau CDN eta urruneko guneen kasuan gertatzen da.
Egoera ere gehitu dugu Ready. Tiketa bertara transferitzen da diskoa ordezkatu ondoren. Hau da, dena eginda dago jada, baina HW/SW RAID-a zerbitzarian sinkronizatuta dago. Horrek denbora nahiko luzea izan dezake.
Administratzaile batek lanean parte hartzen badu, eskema pixka bat zailagoa da.
Egoeratik Ireki Tiketa sistemaren administratzaileak zein ingeniariak itzul dezakete. Egoeran Aurrera doa administratzaileak diskoa errotaziotik kentzen du, ingeniariak besterik gabe atera dezan: atzeko argia pizten du, diskoa desmuntatzen du, aplikazioak geldiarazten ditu, zerbitzari-talde zehatzaren arabera.
Ondoren, txartela eramango da Aldatzeko prest: Diskoa atera daitekeen seinale da hau ingeniariarentzat. Jirako eremu guztiak beteta daude dagoeneko, ingeniariak badaki zer mota eta tamaina duen diskoa. Datu hauek automatikoki sartzen dira aurreko egoeran edo administratzaileak.
Diskoa ordezkatu ondoren, txartelaren egoera honela aldatzen da aldatuta. Disko egokia sartu dela egiaztatzen du, partizioa egin dela, aplikazioa abiarazten dela eta datuak berreskuratzeko zeregin batzuk abiarazten direla. Tiketa egoerara ere pasa daiteke Ready, kasu honetan administratzaileak ardurapean jarraituko du, diskoa biraka jartzen duelako. Diagrama osoa honelakoa da.
Eremu berriak gehitzeak asko erraztu zuen gure bizitza. Mutilak informazio egituratuarekin lanean hasi ziren, argi geratu zen zer egin behar zen eta zein fasetan. Lehentasunak askoz garrantzitsuago bihurtu dira, orain administratzaileak ezartzen dituenez.
Ez dago txat beharrik. Jakina, administratzaileak ingeniariari idatz diezaioke "hau azkarrago ordezkatu behar da" edo "dagoeneko arratsaldea da, izango al duzu ordezkatzeko denbora?" Baina jada ez gara egunero komunikatzen gai hauei buruzko txatetan.
Diskoak loteka aldatzen hasi ziren. Administratzailea apur bat goiz etorri bada lanera, denbora librea badu eta oraindik ez da ezer gertatu, ordezko zerbitzari batzuk presta ditzake: eremuak bete, diskoak errotaziotik kendu eta zeregina ingeniari bati transferitu. Ingeniaria pixka bat beranduago dator datu-zentrora, zeregina ikusten du, biltegitik beharrezko diskoak hartu eta berehala ordezkatzen ditu. Ondorioz, ordezkapen tasa igo egin da.
Workflow eraikitzean ikasitako ikasgaiak
- Prozedura bat eraikitzerakoan, iturri ezberdinetako informazioa bildu behar duzu.
Gure administratzaile batzuek ez zekiten ingeniariak berak diskoak aldatzen dituela. Batzuek uste zuten MD RAID sinkronizazioa ingeniariek kudeatzen zutela, nahiz eta haietako batzuek ez zuten horretarako sarbiderik izan. Puntako ingeniari batzuek hori egin zuten, baina ez beti prozesua ez zelako inon deskribatu. - Prozedura sinplea eta ulergarria izan behar du.
Zaila da pertsona batek pauso asko gogoan izatea. Jirako aldameneko egoera garrantzitsuenak pantaila nagusian jarri behar dira. Izena aldatu diezaiekezu, adibidez, In progress deitzen dugu Aldatzeko prest. Eta beste egoera batzuk goitibeherako menu batean ezkutatu daitezke, begiak izan ez daitezen. Baina hobe da jendea ez mugatzea, trantsizioa egiteko aukera ematea.
Azaldu berrikuntzaren balioa. Jendeak ulertzen duenean, gehiago onartzen du prozedura berria. Guretzat oso garrantzitsua zen jendeak ez egitea prozesu osoan klik egitea, baizik eta jarraitzea. Ondoren, automatizazioa eraiki genuen. - Itxaron, aztertu, asmatu.
Hilabete inguru behar izan genuen prozedura, ezarpen teknikoa, bilerak eta eztabaidak eraikitzeko. Eta ezarpenak hiru hilabete baino gehiago behar ditu. Ikusi nuen nola jendea poliki-poliki berrikuntza erabiltzen hasten ari den. Hasierako faseetan negatibotasun handia zegoen. Baina prozedura bera eta bere ezarpen teknikotik guztiz independentea zen. Adibidez, administratzaile batek ez zuen Jira erabiltzen, Jira plugina baizik Confluence-n, eta gauza batzuk ez zituen bere eskura. Jira erakutsi genion, eta administratzailearen produktibitatea handitu egin zen bai zeregin orokorretarako bai diskoak ordezkatzeko.
Diskoen ordezkapenaren automatizazioa
Diskoen ordezkapenaren automatizaziora hurbildu ginen hainbat aldiz. Aurretik garapenak eta gidoiak genituen, baina guztiak modu interaktiboan edo eskuz funtzionatzen zuten eta abiarazi behar zuten. Eta prozedura berria aurkeztu ondoren bakarrik konturatu ginen horixe zela falta zitzaiguna.
Orain gure ordezkapen-prozesua fasetan banatuta dagoenez, bakoitzak interpretatzaile zehatz bat eta ekintzen zerrenda bat dituenez, automatizazioa etapaka gaitu dezakegu, eta ez guztiak aldi berean. Adibidez, faserik errazena - Prest (RAID/datuen sinkronizazioa egiaztatzea) bot bati erraz delega daiteke. Botak pixka bat ikasi duenean, zeregin garrantzitsuago bat eman diezaiokezu - diskoa biraka jartzea, etab.
Zoo konfigurazioak
Bot-ari buruz hitz egin aurretik, egin dezagun txango txiki bat gure instalazioen zoora. Lehenik eta behin, gure azpiegituren tamaina erraldoiagatik da. Bigarrenik, zerbitzu bakoitzerako hardware konfigurazio optimoa hautatzen saiatzen gara. 20 hardware RAID eredu inguru ditugu, gehienbat LSI eta Adaptec, baina bertsio ezberdinetako HP eta DELL ere badaude. RAID kontroladore bakoitzak bere kudeaketa-erabilgarritasuna du. Komando-multzoa eta horien igorpena desberdinak izan daitezke RAID kontrolagailu bakoitzeko bertsio batetik bestera. HW-RAID erabiltzen ez den lekuetan, mdraid erabil daiteke.
Ia instalazio berri guztiak diskoaren babeskopiarik gabe egiten ditugu. Hardware eta software RAID gehiago erabiltzen saiatzen gara, gure sistemen babeskopia datu-zentro mailan egiten baitugu, ez zerbitzarietan. Baina, jakina, ondareko zerbitzari asko daude onartu behar direnak.
Nonbait RAID kontrolagailuetako diskoak gailu gordinetara transferitzen dira, nonbait JBODak erabiltzen dira. Zerbitzarian sistema-disko bakarra duten konfigurazioak daude, eta ordezkatu behar bada, zerbitzaria berriro instalatu behar duzu OS eta aplikazioak instalatuta, bertsio berekoak, ondoren konfigurazio fitxategiak gehitu eta aplikazioak abiarazi. Zerbitzari-talde asko ere badaude, non babeskopia diskoaren azpisistema mailan ez, baina aplikazioetan zuzenean egiten den.
Guztira, 400 zerbitzari talde bakar baino gehiago ditugu ia 100 aplikazio ezberdin exekutatzen dituztenak. Hain aukera kopuru handia estaltzeko, funtzio anitzeko automatizazio tresna bat behar genuen. Hobe DSL soil batekin, idatzi duenak ez ezik, hori onar dezan.
Agenterik gabekoa delako aukeratu dugu Ansible: ez zegoen azpiegitura prestatu beharrik, hasiera azkar bat. Horrez gain, Python-en idatzita dago, talde barruan estandar gisa onartzen dena.
Eskema orokorra
Ikus dezagun automatizazio-eskema orokorra gertakari bat adibide gisa erabiliz. Zabbix-ek sdb diskoak huts egin duela detektatzen du, abiarazlea pizten da eta Jira-n txartel bat sortzen da. Administratzaileak begiratu zuen, konturatu zen ez zela bikoiztu bat eta ez positibo faltsu bat, hau da, diskoa aldatu behar zela, eta txartela In progress-era transferitu zuen.
Python-en idatzitako DiskoBot aplikazioak aldian-aldian inkesta egiten dio Jirari sarrera berriak lortzeko. Abian txartel berri bat agertu dela ohartzen da, dagokion haria abiarazten da, eta horrek Ansible-n playbook-a abiarazten du (hau Jira-n egoera bakoitzerako egiten da). Kasu honetan, Prepare2change abiarazten da.
Ansible ostalarira bidaltzen da, diskoa errotaziotik kentzen du eta aplikazioari egoeraren berri ematen dio Callback-en bidez.
Emaitzetan oinarrituta, bot-ak automatikoki transferitzen du txartela aldatzeko prest. Ingeniariak jakinarazpen bat jasotzen du eta diskoa aldatzera joaten da, eta ondoren txartela aldatuko du aldatuta.
Goian azaldutako eskemaren arabera, txartela bot-era itzultzen da, eta honek beste playbook bat abiarazten du, ostalarira joan eta diskoa biraka jartzen du. Botek txartela ixten du. Aupa!
Orain hitz egin dezagun sistemaren osagai batzuei buruz.
Diskobot
Aplikazio hau Python-en idatzita dago. JQLren arabera Jirako txartelak hautatzen ditu. Txartelaren egoeraren arabera, azken hori dagokion kudeatzailera doa, eta honek egoerari dagokion Ansible playbook-a abiarazten du.
JQL eta galdeketa tarteak aplikazioaren konfigurazio fitxategian definitzen dira.
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
Adibidez, Abian egoeran dauden txartelen artean, Diskoaren tamaina eta Gailuaren izena eremuak beteta dituztenak bakarrik hautatzen dira. Gailuaren izena playbook exekutatzeko behar den bloke-gailuaren izena da. Diskoaren tamaina behar da, ingeniariak zein tamainako disko behar den jakin dezan.
Eta Prest egoera duten txartelen artean, dbot_ignore etiketa duten txartelak iragazten dira. Bide batez, Jira etiketak erabiltzen ditugu bai iragazketarako, bai sarrera bikoiztuak markatzeko eta estatistikak biltzeko.
Jolas-liburu batek huts egiten badu, Jirak dbot_failed etiketa esleitzen du geroago konpondu ahal izateko.
Ansiblerekin elkarreragingarritasuna
Aplikazioa Ansible-rekin komunikatzen da . Playbook_executor-era fitxategiaren izena eta aldagai multzo bat pasatzen ditugu. Honi esker, Ansible proiektua yml fitxategi arruntetan gorde dezakezu, Python kodean deskribatu beharrean.
Ansible-n ere, *extra_vars* bidez, blokeo gailuaren izena, txartelaren egoera, baita callback_url-a ere, arazoaren gakoa duen - HTTP-n dei-itzultzeko erabiltzen da.
Abian jartzeko, behin-behineko inbentario bat sortzen da, ostalari batek eta ostalari hori zein taldetakoa den, group_vars aplikatzeko.
Hona hemen HTTP deia inplementatzen duen ataza baten adibidea.
Callaback(k) erabiliz playbooks exekutatzeko emaitza lortzen dugu. Bi motatakoak dira:
- , playbook exekuzioaren emaitzei buruzko datuak eskaintzen ditu. Abian jarri, arrakastaz edo arrakastarik gabe burutu diren zereginak deskribatzen ditu. Erreprodukzio-liburua erreproduzitzen amaitzean deitzen zaio dei-itzulera horri.
- HTTP deia itzultzea playbook bat erreproduzitzen ari zaren bitartean informazioa jasotzeko. Ansible zereginean POST/GET eskaera bat exekutatzen dugu gure aplikaziorako.
Aldagaiak erreprodukzio-liburuaren exekuzioan definitu ziren eta ondorengo exekuzioetan gorde eta erabili nahi ditugun HTTP deien bidez pasatzen dira. Datu hauek sqlite-n idazten ditugu.
Iruzkinak ere uzten ditugu eta txartelaren egoera aldatzen dugu HTTP deiaren bidez.
HTTP deia itzultzea
# 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
Mota bereko zeregin asko bezala, fitxategi komun batean jartzen dugu eta behar izanez gero sartzen dugu, jolas-liburuetan etengabe errepika ez dadin. Honek callback_ url-a barne hartzen du, arazoaren gakoa eta ostalari-izena dituena. Ansiblek POST eskaera hau exekutatzen duenean, bot-ak ulertzen du halako edo halako gertakari baten parte dela.
Eta hona hemen playbook-eko adibide bat, non MD gailu batetik disko bat ateratzen dugun:
# 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
Zeregin honek Jira txartela "Aldatzeko prest" egoerara transferitzen du eta iruzkin bat gehitzen du. Era berean, mdam_data aldagaiak diskoa kendu den md gailuen zerrenda gordetzen du, eta parted_info-k parted-en iraulketa bat gordetzen du.
Ingeniariak disko berri bat sartzen duenean, aldagai hauek erabil ditzakegu partizio-iraulketa leheneratzeko, baita diskoa kendu den md gailuetan txertatzeko ere.
Ansible egiaztapen modua
Beldurgarria zen automatizazioa aktibatzea. Hori dela eta, moduko playbook guztiak exekutatzeko erabaki dugu
, zeinetan Ansiblek ez du inolako ekintzarik egiten zerbitzarietan, baizik eta emulatzen ditu.
Abiarazte hori dei-itzulera modulu bereizi baten bidez exekutatzen da, eta playbook-aren exekuzioaren emaitza Jira-n gordetzen da iruzkin gisa.
Lehenik eta behin, horri esker, bot eta playbook-en lana baliozkotu da. Bigarrenik, administratzaileek botarekiko duten konfiantza areagotu zuen.
Balioztatzea gainditu genuenean konturatu ginenean Ansible exekutatu dezakezula exekuzio lehorrean ez ezik, Exekutatu Diskobot botoia egin genuen Jira-n playbook bera aldagai berdinekin ostalari berean abiarazteko, baina modu normalean.
Gainera, botoia huts egiten badu playbook berrabiarazteko erabiltzen da.
Jolas liburuen egitura
Dagoeneko aipatu dut Jira txartelaren egoeraren arabera, bot-ak jolas-liburu desberdinak abiarazten dituela.
Lehenik eta behin, sarrera antolatzea askoz errazagoa da.
Bigarrenik, kasu batzuetan, besterik gabe, beharrezkoa da.
Adibidez, sistema-disko bat ordezkatzean, lehenik inplementazio-sistemara joan behar duzu, zeregin bat sortu eta behar bezala zabaldu ondoren, zerbitzaria ssh bidez eskuragarri egongo da eta aplikazioa bertan zabaldu dezakezu. Hori guztia jolas-liburu batean egingo bagenu, Ansiblek ezingo luke osatu ostalaria erabilgarri ez dagoelako.
Ansible rolak erabiltzen ditugu zerbitzari talde bakoitzeko. Hemen ikus dezakezu nola antolatzen diren jolas-liburuak horietako batean.
Hau komenigarria da, berehala argi baitago zein zeregin kokatzen diren. Main.yml-en, hau da, Ansible rolaren sarrera, txartelaren egoera edo guztientzako beharrezkoak diren zeregin orokorrak sar ditzakegu, adibidez, identifikazioa pasatzea edo token bat jasotzea.
ikerketa.yml
Ikerkuntza eta Ireki egoeran dauden sarrerak eskuratzeko aukera. Playbook honetarako garrantzitsuena bloke gailuaren izena da. Informazio hori ez dago beti eskuragarri.
Lortzeko, Jira laburpena aztertzen dugu, Zabbix trigger-aren azken balioa. Bloke gailuaren izena eduki dezake - zortea. Edo muntatze puntu bat eduki dezake, orduan zerbitzarira joan, analizatu eta beharrezko diskoa kalkulatu behar duzu. Erabiltzaileak scsi helbide bat edo beste informazioren bat ere transmiti dezake. Baina arrastorik ez dagoela ere gertatzen da, eta aztertu egin behar duzu.
Bloke gailuaren izena jakin ondoren, diskoaren motari eta tamainari buruzko informazioa biltzen dugu bertatik Jirako eremuak betetzeko. Horrez gain, saltzaileari, modeloari, firmwareari, IDari, SMARTari buruzko informazioa kentzen dugu eta hori guztia Jira txartelaren iruzkin batean txertatzen dugu. Administratzaileak eta ingeniariak ez ditu datu hauek bilatu behar. π
prestatu2aldaketa.yml
Diskoa biraketatik kentzea, ordezkatzeko prestatzen. Etaparik zailena eta garrantzitsuena. Hemen geldi dezakezu aplikazioa gelditu behar ez denean. Edo erreplika nahikorik ez zuen disko bat atera eta, ondorioz, erabiltzaileengan eragina izan, datu batzuk galduz. Hemen ditugu txatean egiaztapen eta jakinarazpen gehien.
Kasurik errazenean, HW/MD RAID batetik disko bat kentzeaz ari gara.
Egoera konplexuagoetan (gure biltegiratze sistemetan), babeskopia aplikazio mailan egiten denean, aplikaziora joan behar duzu APIaren bidez, diskoaren irteeraren berri eman, desaktibatu eta berreskuratzeari ekin behar diozu.
Orain masiboki migratzen ari gara , eta zerbitzaria hodeian oinarrituta badago, Diskobot-ek hodeiko APIari deitzen dio, minion honekin funtzionatuko duela dio (edukiontziak exekutatzen dituen zerbitzariak) eta "migratu edukiontzi guztiak minion honetatik". Eta, aldi berean, diskoaren atzeko argia pizten du, ingeniariak berehala ikusi dezan zein atera behar den.
aldatu.yml
Disko bat ordezkatu ondoren, lehenik bere erabilgarritasuna egiaztatzen dugu.
Ingeniariek ez dituzte beti unitate berriak instalatzen, beraz, asetzen gaituzten SMART balioen egiaztapena gehitu dugu.
Zein ezaugarri ikusten ari gara?Biresleitutako sektoreen zenbaketa (5) < 100
Uneko Zain dagoen Sektore Zenbakia (107) == 0
Unitateak proban huts egiten badu, ingeniariari jakinaraziko zaio berriro ordezkatzeko. Dena ondo badago, atzeko argia itzaltzen da, markak jartzen dira eta diskoa biraka jartzen da.
prest.yml
Kasurik errazena: HW/SW raid sinkronizazioa egiaztatzea edo aplikazioan datuen sinkronizazioa amaitzea.
Aplikazioaren APIa
Hainbat aldiz aipatu dut bot-a sarritan sartzen dela aplikazioen APIetara. Noski, aplikazio guztiek ez zituzten beharrezko metodoak, beraz, aldatu egin behar izan ziren. Hona hemen erabiltzen ditugun metodo garrantzitsuenak:
- Egoera. Kluster edo disko baten egoera, lan egin daitekeen ulertzeko;
- Hasi/gelditu. Diskoa aktibatzea/desaktibatzea;
- Migratu/berreskuratu. Datuen migrazioa eta berreskuratzea ordezkapenean eta ondoren.
Ansibleren ikasgaiak
Asko maite dut Ansible. Baina askotan, kode irekiko proiektu desberdinak aztertzen ditudanean eta jendeak jolas-liburuak nola idazten dituen ikusten dudanean, beldur pixka bat hartzen dut. Noiz/begizta, malgutasun eza eta inpotentzia eza, shell/komandoa maiz erabiltzearen ondoriozko elkarketa logiko konplexuak.
Dena ahalik eta gehien sinplifikatzea erabaki genuen, Ansibleren abantailaz - modulartasuna aprobetxatuz. Maila gorenean jolas-liburuak daude; Ansible apur bat ezagutzen duen edozein administratzailek, hirugarren garatzailek idatz ditzake.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Logika batzuk joko-liburuetan ezartzea zaila bada, Ansible modulu edo iragazki batera eramango dugu. Scriptak Python edo beste edozein hizkuntzan idatzi daitezke.
Idazteko errazak eta azkarrak dira. Esate baterako, diskoaren atzeko argiaren modulua, goian erakusten den adibide bat, 265 lerroz osatuta dago.
Mailarik baxuenean liburutegia dago. Proiektu honetarako, aparteko aplikazio bat idatzi dugu, dagozkien eskaerak egiten dituzten hardware eta software RAIDen gaineko abstrakzio moduko bat.
Ansibleren indargune handienak bere sinpletasuna eta liburu argiak dira. Uste dut hori erabili behar duzula eta ez sortu yaml fitxategi beldurgarriak eta baldintza, shell kodea eta begizta kopuru handi bat.
Ansible APIarekin dugun esperientzia errepikatu nahi baduzu, kontuan izan bi gauza:
- Playbook_executor eta playbooks, oro har, ezin zaie denbora-mugarik eman. Ssh saioan denbora-muga bat dago, baina playbook-en ez dago denbora-mugarik. Sisteman jada existitzen ez den disko bat desmuntatzen saiatzen bagara, playbook-a etengabe exekutatzen da, beraz, bere abiaraztearen bilgarri bereizi batean bildu eta denbora-muga batekin hil behar izan dugu.
- Ansible forkatutako prozesuetan exekutatzen da, beraz, bere APIa ez da hari segurua. Gure jolas-liburu guztiak hari bakarrean exekutatzen ditugu.
Ondorioz, diskoen %80 ingururen ordezkapena automatizatu ahal izan genuen. Oro har, ordezkapen tasa bikoiztu egin da. Gaur egun, administratzaileak gertakaria begiratzen du eta diskoa aldatu behar den edo ez erabakitzen du, eta gero klik bat egiten du.
Baina orain beste arazo batekin hasten gara: administratzaile berri batzuek ez dakite diskoak aldatzen. π
Iturria: www.habr.com