Hoi allegearre. Ik wurkje as liedende systeembehearder by OK en bin ferantwurdlik foar de stabile wurking fan it portaal. Ik wol prate oer hoe't wy boud in proses foar automatysk ferfangen skiven, en dan hoe't wy útsletten de behearder fan dit proses en ferfongen him mei in bot.
Dit artikel is in soarte fan transliteraasje op HighLoad+ 2018
It bouwen fan in skiifferfangingsproses
Earst wat sifers
OK is in gigantyske tsjinst brûkt troch miljoenen minsken. It wurdt betsjinne troch sawat 7 tûzen servers, dy't lizze yn 4 ferskillende datasintra. De tsjinners befetsje mear as 70 tûzen skiven. As jo se op elkoar steapje, krije jo in toer fan mear as 1 km heech.
Hurde skiven binne de serverkomponint dy't it meast mislearret. Mei sokke folumes moatte wy sawat 30 skiven per wike feroarje, en dizze proseduere is in net heul noflike routine wurden.
Ynsidinten
Us bedriuw hat folweardich ynsidintbehear yntrodusearre. Wy opnimme elk ynsidint yn Jira, en dan oplosse en sortearje it út. As in ynsidint effekt hie op brûkers, dan komme wy definityf byinoar en tinke oer hoe't jo yn sokke gefallen rapper reagearje kinne, hoe't it effekt te ferminderjen en, fansels, hoe't jo in werhelling kinne foarkomme.
Opslachapparaten binne gjin útsûndering. Har status wurdt kontrolearre troch Zabbix. Wy kontrolearje berjochten yn Syslog foar skriuw- / lêsflaters, analysearje de status fan HW / SW-oerfallen, kontrolearje SMART en berekkenje wear foar SSD's.
Hoe skiven waarden feroare foar
As in trigger foarkomt yn Zabbix, wurdt in ynsidint makke yn Jira en automatysk tawiisd oan de passende yngenieurs yn 'e datasintra. Wy dogge dit mei alle HW-ynsidinten, dat is dejingen dy't fysike wurk nedich binne mei apparatuer yn it datasintrum.
In datacenter-yngenieur is in persoan dy't problemen oplost relatearre oan hardware en ferantwurdlik is foar it ynstallearjen, ûnderhâlden en ûntmanteljen fan servers. Nei't er it kaartsje krigen hat, giet de yngenieur oan it wurk. Yn skiif planken hy feroaret skiven selsstannich. Mar as hy gjin tagong hat ta it fereaske apparaat, wendt de yngenieur om help nei de systeembehearders op plicht. Earst fan alles, jim moatte fuortsmite de skiif út rotaasje. Om dit te dwaan, moatte jo de nedige wizigingen op 'e tsjinner meitsje, applikaasjes stopje en de skiif ûntkoppele.
De systeembehearder yn tsjinst is ferantwurdlik foar de eksploitaasje fan it hiele portaal yn 'e wurkshift. Hy ûndersiket ynsidinten, docht reparaasjes en helpt ûntwikkelders lytse taken te foltôgjen. Hy docht net allinnich mei hurde skiven.
Earder kommunisearren datacenter-yngenieurs mei de systeembehearder fia petear. Yngenieurs stjoerde keppelings nei Jira tickets, de behearder folge se, hâlden in log fan wurk yn guon notepad. Mar petearen binne ûngemaklik foar sokke taken: de ynformaasje dêr is net strukturearre en is gau ferlern. En de behearder koe gewoan fuortgean fan 'e kompjûter en net reagearje op fersiken foar in skoft, wylst de yngenieur stie by de tsjinner mei in steapel skiven en wachte.
Mar it slimste wie dat de behearders it hiele byld net seagen: hokker skiif-ynsidinten wiene der, wêr't mooglik in probleem ûntstean koe. Dit komt troch it feit dat wy alle HW-ynsidinten delegearje oan yngenieurs. Ja, it wie mooglik om alle ynsidinten wer te jaan op it dashboard fan de behearder. Mar der binne in protte fan harren, en de behearder wie belutsen allinnich foar guon fan harren.
Dêrneist koe de yngenieur de prioriteiten net goed ynstelle, om't hy neat wit oer it doel fan spesifike tsjinners of de ferdieling fan ynformaasje tusken stasjons.
Nije ferfangende proseduere
It earste ding dat wy diene wie om alle skiif-ynsidinten yn in apart type "HW-skiif" te ferpleatsen en de fjilden "namme fan apparaat blokkearje", "grutte" en "skiiftype" ta te heakjen, sadat dizze ynformaasje yn it kaartsje opslein wurde soe en soe net moatte hieltyd wikseljen yn petear.
Wy hawwe ek ôfpraat dat wy by ien ynsidint mar ien skiif feroarje soene. Dit ferienfâldige it automatisearringsproses, it sammeljen fan statistiken en it wurk yn 'e takomst signifikant.
Derneist hawwe wy it fjild "ferantwurdlike behearder" tafoege. De systeembehearder yn tsjinst wurdt dêr automatysk ynfoege. Dat is hiel handich, want no sjocht de yngenieur altyd wa't ferantwurdlik is. Gjin needsaak om nei de kalinder te gean en te sykjen. It wie dit fjild dat it mooglik makke om kaartsjes te werjaan op it dashboard fan 'e behearder dy't syn help fereaskje kinne.
Om derfoar te soargjen dat alle dielnimmers maksimale foardielen krigen fan ynnovaasjes, hawwe wy filters en dashboards makke en de jonges der oer ferteld. As minsken feroaringen begripe, distânsje se har net fan har as wat net nedich is. It is wichtich foar in yngenieur te witten it rek nûmer dêr't de tsjinner leit, de grutte en it type skiif. De behearder moat earst begripe hokker soarte fan groep servers dit is en wat it effekt kin wêze by it ferfangen fan in skiif.
De oanwêzigens fan fjilden en har werjefte is handich, mar it rêde ús net fan 'e needsaak om petearen te brûken. Om dit te dwaan, moasten wy de workflow feroarje.
Earder wie it sa:
Dit is hoe't yngenieurs hjoed trochgean te wurkjen as se gjin behearderhelp nedich hawwe.
It earste wat wy diene wie in nije status ynfiere Ûndersykje. It kaartsje is yn dizze status as de yngenieur noch net besletten hat oft hy in behearder nedich hat of net. Troch dizze status kin de yngenieur it kaartsje oerdrage oan de behearder. Dêrneist brûke wy dizze status foar in markearring kaartsjes as in skiif moat wurde ferfongen, mar de skiif sels is net op site. Dit bart yn it gefal fan CDN's en sites op ôfstân.
Wy hawwe ek status tafoege klear. It kaartsje wurdt oerdroegen oan it nei it ferfangen fan de skiif. Dat is, alles is al dien, mar de HW / SW RAID wurdt syngronisearre op de tsjinner. Dit kin nochal lang duorje.
As in behearder belutsen is by it wurk, wurdt de regeling wat yngewikkelder.
Fan status Iepen It kaartsje kin oerset wurde troch sawol de systeembehearder as de yngenieur. Yn status Dwaande de behearder smyt de skiif út rotaasje sadat de yngenieur kin gewoan lûke it út: keart de efterljochting, unmounts de skiif, stopet applikaasjes, ôfhinklik fan de spesifike groep fan tsjinners.
It kaartsje wurdt dan oerdroegen oan Klear om te feroarjen: Dit is in sinjaal foar de yngenieur dat de skiif kin wurde lutsen út. Alle fjilden yn Jira binne al ynfolle, de yngenieur wit hokker type en grutte fan de skiif. Dizze gegevens wurde automatysk ynfierd op 'e foarige status of troch de behearder.
Nei it ferfangen fan de skiif, wurdt de kaartsje status feroare nei feroare. It kontrolearret dat de juste skiif is ynfoege, partitionering is dien, de applikaasje is lansearre en guon gegevenshersteltaken wurde lansearre. It kaartsje kin ek oerdroegen wurde oan de status klear, yn dit gefal sil de behearder ferantwurdlik bliuwe, om't hy de skiif yn rotaasje sette. It folsleine diagram sjocht der sa út.
It tafoegjen fan nije fjilden makke ús libben folle makliker. De jonges begûnen te wurkjen mei strukturearre ynformaasje, it waard dúdlik wat der dien wurde moast en yn hokker stadium. Prioriteiten binne folle relevanter wurden, om't se no ynsteld binne troch de behearder.
D'r is gjin ferlet fan petearen. Fansels kin de behearder nei de yngenieur skriuwe "dit moat rapper ferfongen wurde," of "it is al jûn, sille jo tiid hawwe om it te ferfangen?" Mar wy kommunisearje net mear deistich yn petearen oer dizze problemen.
Disken begon te feroarjen yn batches. As de behearder kaam te wurkjen in bytsje betiid, hy hat frije tiid, en der is noch neat bard, hy kin tariede in oantal tsjinners foar ferfanging: folje de fjilden, fuortsmite de skiven út rotaasje en oerdrage de taak nei in yngenieur. De yngenieur komt in bytsje letter nei it datasintrum, sjocht de taak, nimt de nedige skiven út it pakhús en ferfangt se fuortendaliks. Dêrtroch is it ferfangingsnivo ferhege.
Lessen leard by it bouwen fan Workflow
- By it bouwen fan in proseduere moatte jo ynformaasje sammelje út ferskate boarnen.
Guon fan ús behearders wisten net dat de yngenieur de skiven sels feroaret. Guon minsken tochten dat MD RAID-syngronisaasje waard behannele troch yngenieurs, hoewol guon fan harren net iens tagong hienen om dit te dwaan. Guon foaroansteande yngenieurs diene dit, mar net altyd omdat it proses waard net beskreaun oeral. - De proseduere moat ienfâldich en begryplik wêze.
It is lestich foar in persoan om in protte stappen yn gedachten te hâlden. De wichtichste oanbuorjende statusen yn Jira moatte wurde pleatst op it haadskerm. Jo kinne omneame se, bygelyks, wy neame In progress Ready to change. En oare statusen kinne wurde ferburgen yn in útklapmenu, sadat se gjin eagen binne. Mar it is better om minsken net te beheinen, om har de kâns te jaan om de oergong te meitsjen.
Ferklearje de wearde fan ynnovaasje. As minsken it begripe, akseptearje se de nije proseduere mear. It wie foar ús tige wichtich dat minsken it hiele proses net trochklikke, mar it folgje. Doe bouden wy dêr automatisearring op. - Wachtsje, analysearje, fyn it út.
It hat ús sawat in moanne duorre om de proseduere, technyske útfiering, gearkomsten en diskusjes op te bouwen. En útfiering duorret mear as trije moannen. Ik seach hoe't minsken stadichoan begjinne te brûken de ynnovaasje. D'r wie in protte negativiteit yn 'e iere stadia. Mar it wie folslein ûnôfhinklik fan de proseduere sels en syn technyske útfiering. Bygelyks, ien behearder brûkte Jira net, mar de Jira plugin yn Confluence, en guon dingen wiene net beskikber foar him. Wy lieten him Jira sjen, en de produktiviteit fan 'e admin ferhege sawol foar algemiene taken as foar it ferfangen fan skiven.
Automatisearring fan skiif ferfanging
Wy benadere automatisearring fan skiif ferfanging ferskate kearen. Wy hiene al ûntjouwings en skripts, mar se wurken allegear ynteraktyf of mei de hân en easke lansearring. En pas nei it ynfieren fan de nije proseduere beseften wy dat dit krekt wie wat wy misten.
Sûnt no is ús ferfangingsproses ferdield yn stadia, wêrfan elk in spesifike performer en in list mei aksjes hat, kinne wy automatisearring yn stadia ynskeakelje, en net allegear tagelyk. Bygelyks, de ienfâldichste poadium - Ready (kontrolearje RAID / gegevens syngronisaasje) kin maklik wurde delegearre oan in bot. As de bot in bytsje leard hat, kinne jo it in wichtiger taak jaan - de skiif yn rotaasje sette, ensfh.
Zoo opset
Foardat wy oer de bot prate, litte wy in koarte ekskurzje nimme yn ús bistetún fan ynstallaasjes. As earste komt it troch de gigantyske grutte fan ús ynfrastruktuer. As twadde besykje wy de optimale hardwarekonfiguraasje foar elke tsjinst te selektearjen. We hawwe oer 20 hardware RAID modellen, meast LSI en Adaptec, mar der binne ek HP en DELL fan ferskillende ferzjes. Elke RAID-controller hat in eigen behearprogramma. De set fan kommando's en de útjefte dêrfan kinne ferskille fan ferzje nei ferzje foar elke RAID-controller. Dêr't HW-RAID net brûkt wurdt, kin mdraid brûkt wurde.
Wy dogge hast alle nije ynstallaasjes sûnder skiif backup. Wy besykje gjin hardware- en software-RAID mear te brûken, om't wy ús systemen op it gegevenssintrumnivo meitsje, net op servers. Mar fansels binne d'r in protte legacy-tsjinners dy't moatte wurde stipe.
Earne wurde de skiven yn RAID-controllers oerbrocht nei rau apparaten, earne wurde JBOD's brûkt. D'r binne konfiguraasjes mei ien systeemskiif yn 'e tsjinner, en as it moat wurde ferfongen, dan moatte jo de tsjinner opnij ynstalleare mei de ynstallaasje fan it OS en applikaasjes, fan deselde ferzjes, foegje dan konfiguraasjebestannen ta, start applikaasjes. D'r binne ek in protte servergroepen wêr't reservekopy wurdt útfierd net op it nivo fan it skiifsubsysteem, mar direkt yn 'e applikaasjes sels.
Yn totaal hawwe wy mear as 400 unike servergroepen dy't hast 100 ferskillende applikaasjes útfiere. Om sa'n grut oantal opsjes te dekken, hawwe wy in multyfunksjoneel automatisearringsark nedich. It leafst mei in ienfâldige DSL, sadat net allinnich de persoan dy't it skreaun hat it stypje kin.
Wy hawwe foar Ansible keazen om't it gjin agent is: d'r wie gjin need nedich om ynfrastruktuer te meitsjen, in rappe start. Dêrneist is it skreaun yn Python, dat wurdt akseptearre as standert binnen it team.
Algemiene regeling
Litte wy nei it algemiene automatisearringskema sjen mei ien ynsidint as foarbyld. Zabbix detektearret dat de sdb-skiif is mislearre, de trekker ljochtet op, en in kaartsje wurdt makke yn Jira. De behearder seach dernei, realisearre dat it gjin duplikaat wie en net in falsk posityf, dat is, de skiif moast feroare wurde, en stjoerde it kaartsje oer nei In progress.
De DiskoBot-applikaasje, skreaun yn Python, ûndersiket Jira periodyk foar nije kaartsjes. It merkt op dat in nij In progress ticket is ferskynd, de oerienkommende thread wurdt trigger, dy't it playbook yn Ansible lansearret (dit wurdt dien foar elke status yn Jira). Yn dit gefal wurdt Prepare2change lansearre.
Ansible wurdt stjoerd nei de host, smyt de skiif út rotaasje en rapportearret de status oan de applikaasje fia Callbacks.
Op grûn fan de resultaten draacht de bot it kaartsje automatysk oer nei Ready om te feroarjen. De yngenieur krijt in notifikaasje en giet om de skiif te feroarjen, wêrnei't hy it kaartsje oerstapt nei Changed.
Neffens it hjirboppe beskreaune skema giet it kaartsje werom nei de bot, dy't in oare playbook lanseart, giet nei de host en set de skiif yn rotaasje. De bot slút it kaartsje. Hoera!
No litte wy prate oer guon ûnderdielen fan it systeem.
Diskobot
Dizze applikaasje is skreaun yn Python. It selektearret tickets út Jira neffens JQL. Ofhinklik fan 'e status fan it kaartsje, giet de lêste nei de korrespondearjende handler, dy't op syn beurt it Ansible-spielboek lanseart dat oerienkomt mei de status.
JQL- en polling-yntervallen wurde definieare yn it konfiguraasjetriem fan 'e applikaasje.
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
Bygelyks, ûnder kaartsjes yn 'e status Yn útfiering, wurde allinich de fjilden mei de fjilden Skiifgrutte en Apparaatnamme ynfolle selektearre. Apparaatnamme is de namme fan it blokapparaat dat nedich is om it playbook út te fieren. Skiifgrutte is nedich sadat de yngenieur wit hokker grutte skiif nedich is.
En ûnder kaartsjes mei Ready-status wurde kaartsjes mei it dbot_ignore-label útfilterd. Trouwens, wy brûke Jira-labels sawol foar sa'n filterjen as foar it markearjen fan dûbele kaartsjes en it sammeljen fan statistiken.
As in playbook mislearret, jout Jira it label dbot_failed, sadat it letter kin wurde sorteare.
Ynteroperabiliteit mei Ansible
De applikaasje kommunisearret mei Ansible fia . Om playbook_executor passe wy de triemnamme en in set fan fariabelen. Hjirmei kinne jo it Ansible-projekt yn 'e foarm fan reguliere yml-bestannen hâlde, ynstee fan it te beskriuwen yn Python-koade.
Ek yn Ansible, fia *extra_vars*, de namme fan it blokapparaat, de status fan it kaartsje, lykas de callback_url, dy't de útjeftekaai befettet - it wurdt brûkt foar werombel yn HTTP.
Foar elke lansearring wurdt in tydlike ynventarisaasje oanmakke, besteande út ien host en de groep dêr't dizze host ta heart, sadat group_vars tapast wurde.
Hjir is in foarbyld fan in taak dy't HTTP-oprop ymplementearret.
Wy krije it resultaat fan it útfieren fan playbooks mei callaback(s). Se binne fan twa soarten:
- , It jout gegevens oer de resultaten fan playbook útfiering. It beskriuwt de taken dy't waarden lansearre, foltôge mei súkses of net suksesfol. Dizze callback wurdt neamd as it playbook klear is mei spyljen.
- HTTP-oprop om ynformaasje te ûntfangen by it spieljen fan in playbook. Yn 'e Ansible-taak fiere wy in POST/GET-fersyk út nei ús applikaasje.
Fariabelen wurde trochjûn troch HTTP-oprop(en) dy't waarden definieare tidens de útfiering fan it playbook en dat wy wolle bewarje en brûke yn folgjende runs. Wy skriuwe dizze gegevens yn sqlite.
Wy litte ek opmerkingen en feroarje de ticketstatus fia HTTP-oprop.
HTTP-oprop
# 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
Lykas in protte taken fan itselde type, sette wy it yn in aparte mienskiplike bestân en befetsje it as it nedich is, om it net konstant te werheljen yn playbooks. Dit omfettet de callback_ url, dy't de probleemkaai en hostnamme befettet. As Ansible dit POST-fersyk útfiert, begrypt de bot dat it kaam as ûnderdiel fan sa'n en sa'n ynsidint.
En hjir is in foarbyld út it playbook, wêryn wy in skiif útfiere fan in MD-apparaat:
# 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
Dizze taak bringt it Jira-ticket oer nei de status "Klear om te feroarjen" en foeget in opmerking ta. Ek, de fariabele mdam_data bewarret in list fan md apparaten út dêr't de skiif waard fuortsmiten, en parted_info bewarret in partition dump út parted.
As de yngenieur in nije skiif ynfoet, kinne wy dizze fariabelen brûke om de partition dump te herstellen, en ek de skiif yn te foegjen yn 'e md-apparaten wêrfan it fuorthelle is.
Ansible kontrôle modus
It wie eng om de automatisearring oan te setten. Dêrom hawwe wy besletten om alle playbooks yn 'e modus út te fieren
, wêryn Ansible gjin aksjes op de tsjinners útfiert, mar se allinnich emulearret.
Sa'n lansearring wurdt útfierd troch in aparte callback-module, en it resultaat fan 'e playbook-útfiering wurdt bewarre yn Jira as kommentaar.
As earste makke dit it mooglik om it wurk fan 'e bot en playbooks te falidearjen. Twads ferhege it fertrouwen fan behearders yn 'e bot.
Doe't wy foarby de falidaasje en realisearre dat jo kinne rinne Ansible net allinnich yn droege run modus, wy makken in Run Diskobot knop yn Jira foar in lansearring deselde playbook mei deselde fariabelen op deselde host, mar yn normale modus.
Derneist wurdt de knop brûkt om it playbook opnij te begjinnen as it crasht.
Playbooks struktuer
Ik haw al neamd dat ôfhinklik fan de status fan it Jira-ticket, de bot ferskate playbooks lanseart.
Earst is it folle makliker om de yngong te organisearjen.
Twad, yn guon gefallen is it gewoan needsaaklik.
Bygelyks, by it ferfangen fan in systeemskiif, moatte jo earst nei it ynsetsysteem gean, in taak oanmeitsje, en nei juste ynset sil de tsjinner tagonklik wurde fia ssh, en jo kinne de applikaasje derop útrolje. As wy dit alles yn ien playbook diene, dan soe Ansible it net kinne foltôgje fanwegen de host net beskikber is.
Wy brûke Ansible-rollen foar elke groep servers. Hjir kinne jo sjen hoe't de toanielstik(ken) yn ien fan har organisearre binne.
Dat is handich om't daliks dúdlik is wêr't hokker taken lizze. Yn main.yml, dat is de ynfier foar de Ansible-rol, kinne wy gewoan opnimme troch ticketstatus of algemiene taken dy't nedich binne foar elkenien, bygelyks identifikaasje trochjaan of in token ûntfange.
ûndersyk.yml
Rint foar kaartsjes yn de Undersyk en Iepen status. It wichtichste ding foar dit playbook is de namme fan it blokapparaat. Dizze ynformaasje is net altyd beskikber.
Om it te krijen, analysearje wy de Jira-gearfetting, de lêste wearde fan 'e Zabbix-trigger. It kin befetsje de namme fan it blok apparaat - lucky. Of it kin in berchpunt befetsje, dan moatte jo nei de tsjinner gean, it analysearje en de fereaske skiif berekkenje. De trigger kin ek in scsi-adres of wat oare ynformaasje oerstjoere. Mar it bart ek dat der gjin oanwizings, en jo moatte analysearje.
Nei't wy de namme fan it blokapparaat fûn hawwe, sammelje wy ynformaasje oer it type en grutte fan 'e skiif derfan om de fjilden yn Jira yn te foljen. Wy fuortsmite ek ynformaasje oer de ferkeaper, model, firmware, ID, SMART, en foegje dit alles yn in reaksje yn de Jira ticket. De behearder en yngenieur hoege net mear nei dizze gegevens te sykjen. 🙂
prepare2change.yml
It fuortsmiten fan de skiif út rotaasje, tariede op ferfanging. De dreechste en wichtichste poadium. Dit is wêr jo de applikaasje kinne stopje as it net moat wurde stoppe. Of nim in skiif út dy't net genôch replika's hie, en dêrtroch in effekt hawwe op brûkers, wat gegevens ferlieze. Hjir hawwe wy de measte kontrôles en notifikaasjes yn it petear.
Yn it ienfâldichste gefal, wy prate oer it fuortsmiten fan in skiif út in HW / MD RAID.
Yn mear komplekse situaasjes (yn ús opslachsystemen), as de reservekopy wurdt útfierd op it applikaasjenivo, moatte jo nei de applikaasje gean fia de API, rapportearje de skiifútfier, deaktivearje it en begjinne de hersteltiid.
Wy migrearje no massaal nei , en as de tsjinner wolkbasearre is, dan ropt Diskobot de wolk API, seit dat it sil wurkje mei dizze minion - de tsjinner dy't konteners draait - en freget "migreer alle konteners fan dizze minion." En tagelyk draait it efterljocht fan 'e skiif, sadat de yngenieur kin fuortendaliks sjen hokker men moat wurde lutsen út.
feroare.yml
Nei it ferfangen fan in skiif kontrolearje wy earst syn beskikberens.
Yngenieurs ynstallearje net altyd nije skiven, dus wy hawwe in kontrôle tafoege foar SMART-wearden dy't ús foldwaan.
Hokker attributen sjogge wy nei?Oantal sektoaren weryndield (5) < 100
Aktuele oanwêzige sektortelling (107) == 0
As it stasjon de test net slagget, wurdt de yngenieur op 'e hichte brocht om it opnij te ferfangen. As alles yn oarder is, wurdt de efterljochting útskeakele, markearring wurdt tapast en de skiif wurdt yn rotaasje set.
klear.yml
It ienfâldichste gefal: kontrolearje HW / SW raid syngronisaasje of finish gegevens syngronisaasje yn de applikaasje.
Applikaasje API
Ik haw ferskate kearen neamd dat de bot faak tagong hat ta applikaasje API's. Fansels hienen net alle applikaasjes de nedige metoaden, dus moasten se oanpast wurde. Hjir binne de wichtichste metoaden dy't wy brûke:
- Status. Status fan in kluster of skiif om te begripen oft it kin wurde wurke mei;
- Start / stopje. Skiif aktivearring / deaktivearring;
- Migrearje / weromsette. Gegevensmigraasje en herstel by en nei ferfanging.
Lessen leard fan Ansible
Ik hâld echt fan Ansible. Mar faak, as ik nei ferskate iepenboarne-projekten sjoch en sjoch hoe't minsken spielboeken skriuwe, wurd ik in bytsje bang. Komplekse logyske interweavings fan wannear / loop, gebrek oan fleksibiliteit en idempotinsje troch faak gebrûk fan shell / kommando.
Wy besletten om alles sa folle mooglik te ferienfâldigjen, en profitearje fan it foardiel fan Ansible - modulariteit. Op it heechste nivo binne d'r playbooks; se kinne wurde skreaun troch elke behearder, ûntwikkelder fan tredden dy't in bytsje Ansible wit.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
As guon logika lestich is te ymplementearjen yn playbooks, ferpleatse wy it nei in Ansible-module of filter. Skripten kinne skreaun wurde yn Python of in oare taal.
Se binne maklik en fluch te skriuwen. Bygelyks, de skiif backlight module, in foarbyld fan dat is werjûn hjirboppe, bestiet út 265 rigels.
Op it leechste nivo is de biblioteek. Foar dit projekt hawwe wy in aparte applikaasje skreaun, in soarte fan abstraksje oer hardware en software RAID's dy't de oerienkommende oanfragen útfiere.
De grutste sterke punten fan Ansible binne syn ienfâld en dúdlike playbooks. Ik leau dat jo dit moatte brûke en gjin enge yaml-bestannen generearje en in enoarm oantal betingsten, shellkoade en loops.
As jo ús ûnderfining mei de Ansible API wolle werhelje, hâld dan twa dingen yn gedachten:
- Playbook_executor en playbooks yn it algemien kin net jûn wurde in timeout. D'r is in time-out op 'e ssh-sesje, mar d'r is gjin time-out op it playbook. As wy besykje in skiif te ûntsluten dy't net mear yn it systeem bestiet, sil it playbook einleaze rinne, dus wy moasten har lansearring yn in aparte wrapper ferpakke en it mei in time-out deadzje.
- Ansible rint op forked prosessen, dus syn API is net thread feilich. Wy rinne al ús playbooks single-threaded.
As gefolch koenen wy de ferfanging fan sawat 80% fan skiven automatisearje. Oer it algemien is it ferfangingsnivo ferdûbele. Hjoed sjocht de behearder gewoan nei it ynsidint en beslút oft de skiif feroare wurde moat of net, en makket dan ien klik.
Mar no begjinne wy in oar probleem tsjin te kommen: guon nije behearders witte net hoe't se stasjons feroarje moatte. 🙂
Boarne: www.habr.com