Saluton al ĉiuj. Mi laboras kiel gvida sistemadministranto ĉe OK kaj respondecas pri la stabila funkciado de la portalo. Mi volas paroli pri kiel ni konstruis procezon por aŭtomate anstataŭigi diskojn, kaj tiam kiel ni ekskludis la administranton de ĉi tiu procezo kaj anstataŭigis lin per bot.
Ĉi tiu artikolo estas speco de transliterumo ĉe HighLoad+ 2018
Konstruado de disko-anstataŭiga procezo
Unue kelkaj nombroj
OK estas giganta servo uzata de milionoj da homoj. Ĝi estas servata de ĉirkaŭ 7 mil serviloj, kiuj situas en 4 malsamaj datumcentroj. La serviloj enhavas pli ol 70 mil diskojn. Se vi stakigas ilin unu sur la alian, vi ricevas turon pli ol 1 km altan.
Malmolaj diskoj estas la servila komponanto, kiu plej ofte malsukcesas. Je ĉi tiu volumo, ni devas ŝanĝi ĉirkaŭ 30 diskojn semajne, kaj ĉi tiu proceduro fariĝis ne tre agrabla rutino.
Okazaĵoj
Nia firmao enkondukis plenrajtan administradon de incidentoj. Ni registras ĉiun okazaĵon en Jira, kaj poste solvas kaj ordigas ĝin. Se okazaĵo havis efikon al uzantoj, tiam ni certe kuniĝas kaj pripensas kiel respondi pli rapide en tiaj kazoj, kiel redukti la efikon kaj, kompreneble, kiel malhelpi ripetiĝon.
Stokaj aparatoj ne estas escepto. Ilia statuso estas monitorita fare de Zabbix. Ni monitoras mesaĝojn en Syslog por skribaj/legaj eraroj, analizas la staton de HW/SW-atakoj, monitoras SMART kaj kalkulas eluziĝon por SSDoj.
Kiel la diskoj ŝanĝiĝis antaŭe
Kiam ellasilo okazas en Zabbix, okazaĵo estas kreita en Jira kaj aŭtomate asignita al la taŭgaj inĝenieroj en la datumcentroj. Ni faras tion kun ĉiuj HW-okazaĵoj, tio estas, tiuj, kiuj postulas ajnan fizikan laboron kun ekipaĵo en la datumcentro.
Inĝeniero pri datuma centro estas persono, kiu solvas problemojn rilatajn al aparataro kaj respondecas pri instalado, prizorgado kaj malmuntado de serviloj. Ricevinte la bileton, la inĝeniero eklaboras. En diskbretoj li ŝanĝas diskojn sendepende. Sed se li ne havas aliron al la bezonata aparato, la inĝeniero turnas sin al la deĵorantaj sistemadministrantoj por helpo. Antaŭ ĉio, vi devas forigi la diskon de rotacio. Por fari tion, vi devas fari la necesajn ŝanĝojn en la servilo, haltigi aplikojn kaj malmunti la diskon.
La deĵoranta administranto de la sistemo respondecas pri la funkciado de la tuta portalo dum la labordeĵoro. Li esploras incidentojn, faras riparojn, helpas programistojn kun malgrandaj taskoj. Ĝi ne traktas nur malmolajn diskojn.
Antaŭe, datencentraj inĝenieroj komunikis kun la sistemadministranto per babilejo. Inĝenieroj sendis ligilojn al Jira-biletoj, la administranto sekvis ilin, konservis protokolon de laboro en iu notbloko. Sed babilejoj estas maloportunaj por tiaj taskoj: la informoj tie ne estas strukturitaj kaj rapide perdiĝas. Kaj la administranto povis simple foriri de la komputilo kaj ne respondi al petoj dum kelka tempo, dum la inĝeniero staris ĉe la servilo kun stako da diskoj kaj atendis.
Sed la plej malbona afero estis, ke la administrantoj ne vidis la tutan bildon: kiaj diskokazaĵoj ekzistis, kie problemo eble povus ekesti. Ĉi tio estas pro la fakto, ke ni delegas ĉiujn HW-okazaĵojn al inĝenieroj. Jes, eblis montri ĉiujn okazaĵojn sur la panelo de la administranto. Sed ili estas multaj, kaj la administranto okupiĝis nur pri kelkaj el ili.
Krome, la inĝeniero ne povis ĝuste prioritati, ĉar li scias nenion pri la celo de specifaj serviloj, pri la dissendo de informoj inter diskoj.
Nova anstataŭiga proceduro
La unua afero, kiun ni faris, estis movi ĉiujn diskokazaĵojn en apartan tipon "HW-disko" kaj aldoni al ĝi la kampojn "bloki aparaton", "grandeco" kaj "disko-tipo", por ke ĉi tiu informo estu konservita en la bileto kaj ne estu. devas konstante babili.
Ni ankaŭ konsentis, ke kadre de unu okazaĵo ni ŝanĝos nur unu diskon. Ĉi tio multe simpligis la aŭtomatigan procezon, la kolekton de statistiko kaj laboro en la estonteco.
Krome, ni aldonis la kampon "respondeca administranto". La sistemadministranto deĵoranta estas aŭtomate enmetita tie. Ĉi tio estas tre oportuna, ĉar nun la inĝeniero ĉiam vidas, kiu respondecas. Ne necesas iri al la kalendaro kaj serĉi. Ĝuste ĉi tiu kampo ebligis montri biletojn sur la panelo de la administranto, en kiu lia helpo eble estos bezonata.
Por certigi, ke ĉiuj partoprenantoj ricevas maksimumajn profitojn de novigoj, ni kreis filtrilojn kaj panelojn kaj rakontis al la infanoj pri ili. Kiam homoj komprenas ŝanĝojn, ili ne distancigas sin de ili kiel io nenecesa. Gravas, ke inĝeniero konu la raknumeron, kie troviĝas la servilo, la grandecon kaj specon de disko. La administranto bezonas, antaŭ ĉio, kompreni kia grupo de serviloj ĉi tio estas kaj kia efiko povus esti anstataŭante diskon.
La ĉeesto de kampoj kaj ilia montrado estas oportuna, sed ĝi ne savis nin de la bezono uzi babilojn. Por fari tion, ni devis ŝanĝi la laborfluon.
Antaŭe estis jene:
Jen kiel inĝenieroj daŭre laboras hodiaŭ kiam ili ne bezonas administran helpon.
La unua afero, kiun ni faris, estis enkonduki novan statuson Esplori. La bileto estas en ĉi tiu stato kiam la inĝeniero ankoraŭ ne decidis ĉu li bezonos administranton aŭ ne. Per ĉi tiu statuso, la inĝeniero povas transdoni la bileton al la administranto. Krome, ni uzas ĉi tiun staton por marki biletojn kiam disko devas esti anstataŭigita, sed la disko mem ne estas surloke. Ĉi tio okazas en la kazo de CDN-oj kaj foraj retejoj.
Ni ankaŭ aldonis statuson preta. La bileto estas transdonita al ĝi post anstataŭigo de la disko. Tio estas, ĉio jam estas farita, sed la HW/SW RAID estas sinkronigita sur la servilo. Ĉi tio povas daŭri sufiĉe longan tempon.
Se administranto estas implikita en la laboro, la skemo fariĝas iom pli komplika.
El statuso malfermita La bileto povas esti tradukita de kaj la sistemadministranto kaj la inĝeniero. En statuso En progreso la administranto forigas la diskon de rotacio por ke la inĝeniero simple eltiri ĝin: ŝaltas la fonlumon, malmuntas la diskon, haltigas aplikaĵojn, depende de la specifa grupo de serviloj.
La bileto tiam estas tradukita en Preta por ŝanĝi: Ĉi tio estas signalo al la inĝeniero, ke la disko povas esti eltirita. Ĉiuj kampoj en Jira estas jam plenigitaj, la inĝeniero scias kian tipon kaj grandecon de la disko. Ĉi tiuj datumoj estas enmetitaj aŭ aŭtomate en la antaŭa stato aŭ de la administranto.
Post anstataŭigi la diskon, la bileta stato estas ŝanĝita al ŝanĝita. Estas kontrolite, ke la ĝusta disko estas enmetita, dispartigo estas farita, la aplikaĵo estas lanĉita kaj kelkaj datumoj reakiro taskoj estas komencitaj. Ankaŭ, la bileto povas esti translokigita al la statuso preta, en ĉi tiu kazo la administranto restos respondeca, ĉar li metis la diskon en rotacion. La kompleta diagramo aspektas tiel.
Aldoni novajn kampojn multe pli facilas nian vivon. La infanoj komencis labori kun strukturitaj informoj, evidentiĝis, kion oni devas fari kaj en kiu etapo. Prioritatoj fariĝis multe pli gravaj, ĉar ili nun estas fiksitaj de la administranto.
Ne necesas babiloj. Kompreneble, la administranto povas skribi al la inĝeniero "ĉi tio devas esti anstataŭigita pli rapide", aŭ "jam vesperiĝas, ĉu vi havos tempon anstataŭigi ĝin?" Sed ni ne plu komunikas ĉiutage en babilejoj pri ĉi tiuj aferoj.
Diskoj komencis ŝanĝiĝi en aroj. Se la administranto venis labori iom frue, li havas liberan tempon, kaj ankoraŭ nenio okazis, li povas prepari kelkajn servilojn por anstataŭigo: plenigu la kampojn, forigi diskojn de rotacio kaj transdoni la taskon al inĝeniero. Inĝeniero venas al la datumcentro iom poste, vidas la taskon, prenas la necesajn diskojn el la magazeno kaj tuj ŝanĝas ilin. Kiel rezulto, la anstataŭiga indico pliiĝis.
Lernita sperto dum konstruado de Laborfluo
- Konstruante proceduron, vi devas kolekti informojn el malsamaj fontoj.
Kelkaj el niaj administrantoj ne sciis, ke la inĝeniero mem ŝanĝas la diskojn. Kelkaj homoj opiniis, ke MD RAID-sinkronigo estis pritraktita de inĝenieroj, kvankam kelkaj el ili eĉ ne havis aliron por fari tion. Kelkaj ĉefaj inĝenieroj faris tion, sed ne ĉiam ĉar la procezo ne estis priskribita ie ajn. - La proceduro devas esti simpla kaj komprenebla.
Estas malfacile por homo konservi multajn paŝojn en menso. La plej gravaj najbaraj statusoj en Jira devus esti metitaj sur la ĉefa ekrano. Vi povas renomi ilin, ekzemple, ni nomas En progreso Preta por ŝanĝi. Kaj aliaj statusoj povas esti kaŝitaj en falmenuo por ke ili ne estu okulfrapaj. Sed estas pli bone ne limigi homojn, doni al ili la ŝancon fari la transiron.
Klarigu la valoron de novigo. Kiam homoj komprenas, ili pli bone akceptas la novan proceduron. Estis tre grave por ni, ke homoj ne klaku tra la tuta procezo, sed sekvu ĝin. Tiam ni konstruis sur ĉi tiu aŭtomatigo. - Atendu, analizu, eltrovu.
Ni bezonis ĉirkaŭ unu monaton por konstrui la proceduron, teknikan efektivigon, kunvenojn kaj diskutojn. Kaj efektivigo daŭras pli ol tri monatojn. Mi vidis kiel homoj malrapide komencas uzi la novigon. Estis multe da negativeco en la fruaj stadioj. Sed ĝi estis tute sendependa de la proceduro mem kaj ĝia teknika efektivigo. Ekzemple, unu administranto ne uzis Jira, sed la aldonaĵon Jira en Confluence, kaj kelkaj aferoj ne estis disponeblaj por li. Ni montris al li Jira, kaj la produktiveco de la administranto pliiĝis kaj por ĝeneralaj taskoj kaj por anstataŭigi diskojn.
Aŭtomatigo pri anstataŭigo de diskoj
Ni plurfoje alproksimiĝis al aŭtomatigo de anstataŭigo de diskoj. Ni jam havis evoluojn, skriptojn, sed ili ĉiuj funkciis aŭ en interaga aŭ mana reĝimo, ili postulis lanĉon. Kaj nur post la enkonduko de la nova proceduro, ni konstatis, ke ĝi estas ĝuste tio, kion ni bezonis.
Ĉar nun la anstataŭiga procezo estas dividita en etapoj, ĉiu el kiuj havas ekzekutiston kaj liston de agoj, ni povas ebligi aŭtomatigon en etapoj, kaj ne ĉiuj samtempe. Ekzemple, la plej simpla etapo - Preta (kontrolado de RAID / datumsinkronigado) povas esti facile delegita al bot. Kiam la bot lernas iomete, vi povas doni al ĝi pli respondecan taskon - meti la diskon en rotacion ktp.
Zoo-aranĝoj
Antaŭ ol paroli pri la bot, ni faru mallongan viziton de nia instala zoo. Antaŭ ĉio, ĝi estas pro la giganta grandeco de nia infrastrukturo. Due, por ĉiu servo ni provas elekti la optimuman aparataron agordon. Ni havas ĉirkaŭ 20 modelojn de aparataro RAID, ĉefe LSI kaj Adaptec, sed ekzistas ankaŭ HP kaj DELL de malsamaj versioj. Ĉiu RAID-regilo havas sian propran administran ilon. La aro de komandoj kaj ilia eligo povas malsami de versio al versio por ĉiu RAID-regilo. Kie HW-RAID ne estas uzata, povas esti mdraid.
Ni faras preskaŭ ĉiujn novajn instalaĵojn sen diskrezervo. Ni provas ne plu uzi aparataron kaj programaron RAID, ĉar ni rezervas niajn sistemojn ĉe la datencentronivelo, ne servilojn. Sed kompreneble ekzistas multaj heredaj serviloj, kiuj bezonas esti subtenataj.
Ie diskoj en RAID-regiloj estas ĵetitaj krudaj aparatoj, ie JBOD-oj estas uzataj. Estas agordoj kun unu sistema disko en la servilo, kaj se ĝi devas esti anstataŭigita, tiam vi devas re-ruli la servilon kun la instalado de la OS kaj aplikoj, kaj la samaj versioj, tiam aldoni agordajn dosierojn, ruli aplikaĵojn. Ankaŭ ekzistas multaj servilgrupoj, kie redundo efektiviĝas ne ĉe la nivelo de la disksubsistemo, sed rekte en la aplikaĵoj mem.
Entute ni havas pli ol 400 unikajn servilgrupojn prizorgante preskaŭ 100 malsamajn aplikojn. Por kovri tian grandegan nombron da ebloj, ni bezonis multfunkcian aŭtomatigan ilon. Prefere kun simpla DSL, por ke ne nur la homo, kiu skribis ĝin, povu subteni ĝin.
Ni elektis Ansible ĉar ĝi estas senagenta: ne necesis prepari infrastrukturon, rapida komenco. Krome, ĝi estas skribita en Python, kiu estas akceptita kiel normo ene de la teamo.
Ĝenerala skemo
Ni rigardu la ĝeneralan aŭtomatigan skemon uzante unu okazaĵon kiel ekzemplon. Zabbix detektas ke la sdb-disko malsukcesis, la ellasilo pafas, kaj bileto estas kreita en Jira. La administranto rigardis ĝin, rimarkis, ke ĉi tio ne estas duplikato kaj ne falsa pozitivo, tio estas, la disko devas esti ŝanĝita, kaj transdonas la bileton al En progreso.
La aplikaĵo DiskoBot, skribita en Python, periode sondas Jira pri novaj biletoj. Ĝi rimarkas, ke nova En progreso bileto aperis, la responda fadeno estas ekigita, kiu lanĉas la ludlibron en Ansible (ĉi tio estas farita por ĉiu stato en Jira). En ĉi tiu kazo, Prepare2change estas lanĉita.
Ansible estas sendita al la gastiganto, forigas la diskon de rotacio kaj raportas la statuson al la aplikaĵo per Revokoj.
Surbaze de la rezultoj, la roboto aŭtomate ŝanĝas la bileton al Preta por ŝanĝi. La inĝeniero ricevas sciigon kaj iras por ŝanĝi la diskon, post kio li transdonas la bileton al Ŝanĝita.
Laŭ la supra skemo, la bileto revenas al la bot, kiu lanĉas alian ludlibron, iras al la gastiganto kaj metas la diskon en rotacion. La bot fermas la bileton. Hura!
Nun ni parolu pri iuj komponantoj de la sistemo.
Diskobot
Ĉi tiu aplikaĵo estas skribita en Python. Ĝi elektas biletojn de Jira laŭ JQL. Depende de la statuso de la bileto, ĉi-lasta iras al la responda prizorganto, kiu siavice lanĉas la Ansible-ludlibron respondan al la statuso.
JQL kaj balotintervaloj estas difinitaj en la aplika agorda dosiero.
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
Ekzemple, inter biletoj en la En progreso statuso, nur tiuj kun la Diskogrando kaj Aparato nomo kampoj plenigitaj estas elektitaj. Aparato nomo estas la nomo de la bloka aparato necesa por ekzekuti la ludlibron. Diskograndeco estas necesa por ke la inĝeniero sciu kian grandecon disko estas bezonata.
Kaj inter biletoj kun statuso Preta, biletoj kun la etikedo dbot_ignore estas filtritaj. Cetere, ni uzas Jira-etikedojn kaj por tia filtrado kaj por marki duplikatajn biletojn kaj kolekti statistikojn.
Se ludlibro malsukcesas, Jira asignas la dbot_failed etikedon por ke ĝi povas esti ordigita poste.
Interago kun Ansible
La aplikaĵo komunikas kun Ansible per . Al playbook_executor ni pasas la dosiernomon kaj aron da variabloj. Ĉi tio permesas vin konservi la Ansible-projekton en la formo de ordinaraj yml-dosieroj, kaj ne priskribi ĝin en Python-kodo.
Ankaŭ en Ansible, per *extra_vars*, la nomo de la bloka aparato, la statuso de la bileto, same kiel la callback_url, kiu enhavas la eldonŝlosilon - ĝi estas uzata por revoko en HTTP.
Por ĉiu lanĉo, provizora inventaro estas generita, konsistanta el unu gastiganto kaj la grupo al kiu ĉi tiu gastiganto apartenas, tiel ke group_vars estas aplikataj.
Jen ekzemplo de tasko, kiu efektivigas HTTP-revokon.
Ni ricevas la rezulton de ekzekuto de ludlibroj uzante callaback(j). Ili estas de du tipoj:
- , ĝi disponigas datenojn pri la rezultoj de la ekzekuto de la ludlibro. Ĝi priskribas la taskojn kiuj estis lanĉitaj, kompletigitaj sukcese aŭ malsukcese. Ĉi tiu revoko estas vokita kiam la ludlibro finiĝis.
- HTTP-revoko por ricevi informojn dum ludado de ludlibro. En la Ansible-tasko ni plenumas POST/GET peton al nia aplikaĵo.
Per la HTTP-revoko(j) oni pasas variablojn, kiuj estis difinitaj dum la ekzekuto de la ludlibro kaj kiujn ni volas konservi kaj uzi en postaj kuroj. Ni skribas ĉi tiujn datumojn en sqlite.
Ni ankaŭ lasas komentojn kaj ŝanĝas la statuson de bileto per HTTP-revoko.
HTTP-revoko
# 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
Kiel multaj samtipaj taskoj, ni metas ĝin en apartan komunan dosieron kaj enmetas ĝin se necese, por ne konstante ripeti ĝin en ludlibroj. Ĉi tio inkluzivas la callback_ url, kiu enhavas la problemon kaj gastigan nomon. Kiam Ansible plenumas ĉi tiun POST-peton, la bot komprenas, ke ĝi venis kiel parto de tia kaj tia okazaĵo.
Kaj jen ekzemplo el la ludlibro, en kiu ni eligas diskon de MD-aparato:
# 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
Ĉi tiu tasko transdonas la Jira-bileton al la statuso "Preta por ŝanĝi" kaj aldonas komenton. Ankaŭ, la mdam_data variablo konservas liston de md-aparatoj de kiuj la disko estis forigita, kaj parted_info stokas subdiskon de parted.
Kiam la inĝeniero enigas novan diskon, ni povas uzi ĉi tiujn variablojn por restarigi la subdiskon, kaj ankaŭ enmeti la diskon en la md-aparatojn, de kiuj ĝi estis forigita.
Anebla kontrolo-reĝimo
Enŝalti la aŭtomatigon estis timiga. Tial ni decidis ruli ĉiujn ludlibrojn en la reĝimo
, en kiu Ansible ne faras iujn ajn agojn sur la serviloj, sed nur imitas ilin.
Tia lanĉo estas prizorgita per aparta revokmodulo, kaj la rezulto de la ekzekuto de ludlibro estas konservita en Jira kiel komento.
Unue, ĝi permesis validigi la laboron de la bot kaj ludlibroj. Due, ĝi pliigis la fidon de administrantoj en la bot.
Kiam ni pasis la validigon kaj rimarkis, ke eblas ruli Ansible ne nur en seka kurado, ni faris butonon Run Diskobot en Jira por ruli la saman ludlibron kun la samaj variabloj sur la sama gastiganto, sed en normala reĝimo.
Ankaŭ, la butono estas uzata por rekomenci la ludlibron se ĝi kraŝas.
Ludlibroj strukturo
Mi jam menciis, ke depende de la stato de la bileto Jira, la bot lanĉas malsamajn ludlibrojn.
Unue, estas multe pli facile organizi la enirejon.
Due, en iuj kazoj ĝi estas simple necesa.
Ekzemple, kiam vi anstataŭigas la sisteman diskon, vi unue devas iri al la deplojsistemo, krei taskon, kaj post la ĝusta deplojo, la servilo fariĝos disponebla per ssh, kaj vi povas ruli la aplikaĵon sur ĝin. Se ni farus ĉion ĉi en unu ludlibro, tiam Ansible ne povus efektivigi ĝin pro la malhavebleco de la gastiganto.
Ni uzas Ansible-rolojn por ĉiu grupo de serviloj. Ĉi tie vi povas vidi kiel la ludlibro(j) estas organizitaj en unu el ili.
Ĉi tio estas oportuna ĉar tuj estas klare kie kiuj taskoj troviĝas. En main.yml, kiu estas la enigo por la rolo Ansible, ni simple povas inkluzivi laŭ bileta stato aŭ ĝeneralajn taskojn postulatajn por ĉiuj, ekzemple, pasi identigon aŭ ricevi ĵetonon.
Esploro.yml
Kuras por biletoj en la Enketo kaj Malferma statuso. La plej grava afero por ĉi tiu ludlibro estas la bloka aparato nomo. Ĉi tiu informo ne ĉiam disponeblas.
Por akiri ĝin, ni analizas la Jira resumon, la lasta valoro de la Zabbix ellasilo. Ĝi povas enhavi la nomon de la bloka aparato - bonŝanca. Kaj ĝi povas enhavi muntan punkton - tiam vi devas iri al la servilo, analizi kaj kalkuli la bezonatan diskon. Ankaŭ, la ellasilo povas sendi scsi-adreson aŭ iujn aliajn informojn. Sed ankaŭ okazas, ke mankas spuroj, kaj oni devas analizi.
Post ekscii la nomon de la bloka aparato, ni kolektas informojn pri la tipo kaj grandeco de la disko de ĝi por plenigi la kampojn en Jira. Ni ankaŭ forigas informojn pri la vendisto, modelo, firmvaro, ID, SMART, kaj algluas ĉion ĉi en komenton en la Jira-bileto. La administranto kaj inĝeniero ne plu bezonas serĉi ĉi tiujn datumojn. 🙂
prepari2ŝanĝo.yml
Forpelu el rotacio, preparo por anstataŭigo. La plej malfacila, respondeca etapo. Ĉi tie vi povas ĉesigi la aplikaĵon kiam ĝi ne povas esti haltigita. Aŭ eltiri diskon al kiu mankis kopioj, kaj per tio efiki al uzantoj, perdi iujn datumojn. Ĉi tie ni havas la plej multajn kontrolojn kaj sciigojn en la babilejo.
En la plej simpla kazo, ni parolas pri forigo de disko de HW/MD RAID.
En pli kompleksaj situacioj (en niaj stoksistemoj), kiam la sekurkopio estas farita ĉe la aplika nivelo, vi devas iri al la aplikaĵo per la API, raporti la elĵeton de la disko, malaktivigi ĝin kaj komenci la restarigon.
Ni nun amase migras al , kaj se la servilo estas nuba, tiam Diskobot aliras la nuban API, diras ke ĝi funkcios kun ĉi tiu servilo - la servilo sur kiu la ujoj funkcias - kaj demandas "migri ĉiujn ujojn de ĉi tiu servilo". Kaj samtempe ŝaltas la fonlumon de la disko, por ke la inĝeniero tuj vidu, kiun oni devas eltiri.
ŝanĝita.yml
Post anstataŭigi diskon, ni unue kontrolas ĝian haveblecon.
Inĝenieroj ne ĉiam instalas novajn diskojn, do ni aldonis kontrolon por SMART-valoroj, kiuj kontentigas nin.
Kiajn atributojn ni rigardasReasignitaj Sektoroj Nombri (5) < 100
Nuna Pritraktata Sektora Nombro (107) == 0
Se la veturado malsukcesas la teston, la inĝeniero estas sciigita anstataŭigi ĝin denove. Se ĉio estas en ordo, la kontraŭlumo malŝaltas, markoj estas aplikataj kaj la disko estas metita en rotacion.
preta.yml
La plej simpla kazo: kontrolado de HW/SW-atako-sinkronigado aŭ fini datumsinkronigadon en la aplikaĵo.
Aplikaĵo API
Mi menciis plurajn fojojn, ke ofte la bot aliras la aplikaĵon API. Kompreneble, ne ĉiuj aplikaĵoj havis la necesajn metodojn, do ili devis esti finpretigitaj. Jen la plej gravaj metodoj, kiujn ni uzas:
- statuso. La stato de areto aŭ disko por vidi ĉu eblas labori kun ĝi;
- Komencu/haltigi. Aktivigo/malaktivigo de disko;
- Migri/restarigi. Migrado kaj reakiro de datumoj dum kaj post anstataŭigo.
Spertigita de Ansible
Mi vere amas Ansible. Sed ofte, kiam mi rigardas malsamajn malfermfontajn projektojn kaj vidas kiel homoj skribas ludlibrojn, mi iom timas. Kompleksaj logikaj interplektaĵoj de kiam/buklo, manko de fleksebleco kaj idempotenco pro ofta uzo de ŝelo/komando.
Ni decidis simpligi ĉion kiel eble plej multe, profitante la avantaĝon de Ansible - modulareco. Ĉe la plej alta nivelo estas ludlibroj; ili povas esti skribitaj de iu ajn administranto, triapartnera programisto, kiu konas iom Ansible.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Se iu logiko malfacilas efektivigi en ludlibroj, ni movas ĝin en Ansible-modulon aŭ filtrilon. Skriptoj povas esti skribitaj en Python aŭ ajna alia lingvo.
Ili estas facile kaj rapide skribi. Ekzemple, la disko-kontraŭluma modulo, ekzemplo de kiu estas montrita supre, konsistas el 265 linioj.
Sur la plej malalta nivelo estas la biblioteko. Por ĉi tiu projekto, ni skribis apartan aplikaĵon, specon de abstraktado super aparataro kaj programaro RAID-oj, kiuj plenumas la respondajn petojn.
La plej grandaj fortoj de Ansible estas ĝiaj simpleco kaj facile kompreneblaj ludlibroj. Mi pensas, ke vi devas uzi ĉi tion kaj ne generi terurajn yaml-dosierojn kaj grandegan nombron da kondiĉoj, ŝelkodo kaj bukloj.
Se vi volas ripeti nian sperton pri Ansible API, memoru du aferojn:
- Playbook_executor kaj ludlibroj ĝenerale ne povas esti donitaj tempodaŭro. Estas tempodaŭro sur la ssh-sesio, sed ne estas tempodaŭro sur la ludlibro. Se ni provas malmunti diskon, kiu ne plu ekzistas en la sistemo, la ludlibro ruliĝos senfine, do ni devis envolvi ĝian lanĉon en apartan envolvaĵon kaj mortigi ĝin per tempodaŭro.
- Ansible funkcias per forkitaj procezoj, do ĝia API ne estas fadena sekura. Ni prizorgas ĉiujn niajn ludlibrojn unufadenajn.
Kiel rezulto, ni povis aŭtomatigi la anstataŭigon de ĉirkaŭ 80% de la diskoj. Ĝenerale, la anstataŭiga indico duobliĝis. Hodiaŭ, la administranto nur rigardas la okazaĵon kaj decidas ĉu ŝanĝi la diskon aŭ ne, kaj poste faras unu klakon.
Sed nun ni komencas renkonti alian problemon: iuj novaj administrantoj ne scias kiel ŝanĝi diskojn. 🙂
fonto: www.habr.com