Awtomeiddio Disodli Disod gydag Ansible

Awtomeiddio Disodli Disod gydag Ansible

Helo i gyd. Rwy'n gweithio fel gweinyddwr system blaenllaw yn OK ac rwy'n gyfrifol am weithrediad sefydlog y porth. Rwyf am siarad am sut y gwnaethom adeiladu proses ar gyfer ailosod disgiau'n awtomatig, ac yna sut y gwnaethom wahardd y gweinyddwr o'r broses hon a rhoi bot yn ei le.

Mae'r erthygl hon yn fath o drawslythrennu perfformiadau yn HighLoad+ 2018

Adeiladu proses ailosod disg

Yn gyntaf rhai rhifau

Mae OK yn wasanaeth enfawr a ddefnyddir gan filiynau o bobl. Fe'i gwasanaethir gan tua 7 mil o weinyddion, sydd wedi'u lleoli mewn 4 canolfan ddata wahanol. Mae'r gweinyddwyr yn cynnwys mwy na 70 mil o ddisgiau. Os byddwch yn eu pentyrru ar ben ei gilydd, byddwch yn cael tŵr sy'n fwy nag 1 km o uchder.

Gyriannau caled yw'r elfen gweinydd sy'n methu amlaf. Gyda chyfeintiau o'r fath, mae'n rhaid i ni newid tua 30 disg yr wythnos, ac mae'r weithdrefn hon wedi dod yn drefn nad yw'n ddymunol iawn.

Awtomeiddio Disodli Disod gydag Ansible

Digwyddiadau

Mae ein cwmni wedi cyflwyno rheoli digwyddiadau llawn. Rydyn ni'n cofnodi pob digwyddiad yn Jira, ac yna'n ei ddatrys a'i ddatrys. Pe bai digwyddiad yn cael effaith ar ddefnyddwyr, yna rydym yn bendant yn dod at ein gilydd ac yn meddwl sut i ymateb yn gyflymach mewn achosion o'r fath, sut i leihau'r effaith ac, wrth gwrs, sut i atal hyn rhag digwydd eto.

Nid yw dyfeisiau storio yn eithriad. Mae eu statws yn cael ei fonitro gan Zabbix. Rydym yn monitro negeseuon yn Syslog ar gyfer gwallau ysgrifennu/darllen, dadansoddi statws cyrchoedd HW/SW, monitro SMART, a chyfrifo traul ar gyfer SSDs.

Sut y newidiwyd disgiau o'r blaen

Pan fydd sbardun yn digwydd yn Zabbix, mae digwyddiad yn cael ei greu yn Jira a'i neilltuo'n awtomatig i'r peirianwyr priodol yn y canolfannau data. Rydym yn gwneud hyn gyda phob digwyddiad HW, hynny yw, y rhai sydd angen unrhyw waith corfforol gydag offer yn y ganolfan ddata.
Mae peiriannydd canolfan ddata yn berson sy'n datrys materion sy'n ymwneud â chaledwedd ac sy'n gyfrifol am osod, cynnal a datgymalu gweinyddwyr. Ar ôl derbyn y tocyn, mae'r peiriannydd yn cyrraedd y gwaith. Mewn silffoedd disg mae'n newid disgiau'n annibynnol. Ond os nad oes ganddo fynediad i'r ddyfais ofynnol, mae'r peiriannydd yn troi at weinyddwyr y system sydd ar ddyletswydd am gymorth. Yn gyntaf oll, mae angen i chi gael gwared ar y ddisg o gylchdroi. I wneud hyn, mae angen i chi wneud y newidiadau angenrheidiol ar y gweinydd, atal cymwysiadau, a dadosod y ddisg.

Mae gweinyddwr y system ar ddyletswydd yn gyfrifol am weithrediad y porth cyfan yn ystod y sifft waith. Mae'n ymchwilio i ddigwyddiadau, yn gwneud atgyweiriadau, ac yn helpu datblygwyr i gwblhau tasgau bach. Nid yw'n delio â gyriannau caled yn unig.

Yn flaenorol, roedd peirianwyr canolfannau data yn cyfathrebu â gweinyddwr y system trwy sgwrs. Anfonodd peirianwyr ddolenni i docynnau Jira, dilynodd y gweinyddwr nhw, cadw cofnod o'r gwaith mewn llyfr nodiadau. Ond mae sgyrsiau yn anghyfleus ar gyfer tasgau o'r fath: nid yw'r wybodaeth yno wedi'i strwythuro ac mae'n cael ei cholli'n gyflym. A gallai'r gweinyddwr gerdded i ffwrdd o'r cyfrifiadur a pheidio ag ymateb i geisiadau am beth amser, tra bod y peiriannydd yn sefyll wrth y gweinydd gyda phentwr o ddisgiau ac yn aros.

Ond y peth gwaethaf oedd na welodd y gweinyddwyr y darlun cyfan: pa ddigwyddiadau disg oedd yn bodoli, lle gallai problem godi o bosibl. Mae hyn oherwydd ein bod yn dirprwyo pob digwyddiad HW i beirianwyr. Oedd, roedd yn bosibl arddangos pob digwyddiad ar ddangosfwrdd y gweinyddwr. Ond mae yna lawer ohonyn nhw, ac roedd y gweinyddwr yn ymwneud â rhai ohonyn nhw yn unig.

Yn ogystal, ni allai'r peiriannydd osod blaenoriaethau'n gywir, oherwydd nid yw'n gwybod dim am bwrpas gweinyddwyr penodol na dosbarthiad gwybodaeth ymhlith gyriannau.

Gweithdrefn amnewid newydd

Y peth cyntaf a wnaethom oedd symud pob digwyddiad disg i fath ar wahân “Disg HW” ac ychwanegu'r meysydd “enw dyfais bloc”, “maint” a “math o ddisg” ato fel y byddai'r wybodaeth hon yn cael ei storio yn y tocyn a byddai nid oes rhaid cyfnewid yn gyson mewn sgwrs.

Awtomeiddio Disodli Disod gydag Ansible
Cytunwyd hefyd mai dim ond un ddisg y byddem yn ei newid yn ystod un digwyddiad. Fe wnaeth hyn symleiddio'r broses awtomeiddio, casglu ystadegau a gwaith yn y dyfodol yn sylweddol.

Yn ogystal, fe wnaethom ychwanegu'r maes “gweinyddwr cyfrifol”. Mae gweinyddwr y system ar ddyletswydd yn cael ei fewnosod yn awtomatig yno. Mae hyn yn gyfleus iawn, oherwydd nawr mae'r peiriannydd bob amser yn gweld pwy sy'n gyfrifol. Nid oes angen mynd i'r calendr a chwilio. Y maes hwn a'i gwnaeth yn bosibl arddangos tocynnau ar ddangosfwrdd y gweinyddwr a allai fod angen ei help.

Awtomeiddio Disodli Disod gydag Ansible
Er mwyn sicrhau bod yr holl gyfranogwyr yn cael y buddion mwyaf posibl o arloesiadau, fe wnaethon ni greu hidlwyr a dangosfyrddau a dweud wrth y dynion amdanyn nhw. Pan fydd pobl yn deall newidiadau, nid ydynt yn ymbellhau oddi wrthynt fel rhywbeth diangen. Mae'n bwysig i beiriannydd wybod rhif y rac lle mae'r gweinydd wedi'i leoli, maint a math y ddisg. Mae angen i'r gweinyddwr, yn gyntaf oll, ddeall pa fath o grŵp o weinyddion yw hwn a beth allai'r effaith fod wrth ailosod disg.

Mae presenoldeb caeau a'u harddangos yn gyfleus, ond nid oedd yn ein harbed rhag yr angen i ddefnyddio sgyrsiau. I wneud hyn, roedd yn rhaid i ni newid y llif gwaith.

Yn flaenorol roedd fel hyn:

Awtomeiddio Disodli Disod gydag Ansible
Dyma sut mae peirianwyr yn parhau i weithio heddiw pan nad oes angen cymorth gweinyddwr arnynt.

Y peth cyntaf a wnaethom oedd cyflwyno statws newydd Ymchwiliwch. Mae'r tocyn yn y statws hwn pan nad yw'r peiriannydd wedi penderfynu eto a fydd angen gweinyddwr arno ai peidio. Trwy'r statws hwn, gall y peiriannydd drosglwyddo'r tocyn i'r gweinyddwr. Yn ogystal, rydym yn defnyddio'r statws hwn i farcio tocynnau pan fydd angen disodli disg, ond nid yw'r ddisg ei hun ar y safle. Mae hyn yn digwydd yn achos CDNs a safleoedd anghysbell.

Rydym hefyd wedi ychwanegu statws Yn barod. Trosglwyddir y tocyn iddo ar ôl ailosod y ddisg. Hynny yw, mae popeth wedi'i wneud eisoes, ond mae'r HW / SW RAID wedi'i gydamseru ar y gweinydd. Gall hyn gymryd cryn amser.

Os yw gweinyddwr yn ymwneud â'r gwaith, daw'r cynllun ychydig yn fwy cymhleth.

Awtomeiddio Disodli Disod gydag Ansible
O statws agored Gall gweinyddwr y system a'r peiriannydd gyfieithu'r tocyn. Mewn statws Ar y gweill mae'r gweinyddwr yn tynnu'r ddisg o gylchdroi fel bod y peiriannydd yn gallu ei thynnu allan: yn troi'r backlight ymlaen, yn dadosod y ddisg, yn stopio cymwysiadau, yn dibynnu ar y grŵp penodol o weinyddion.

Yna trosglwyddir y tocyn i Yn barod i newid: Mae hwn yn arwydd i'r peiriannydd y gellir tynnu'r ddisg allan. Mae pob maes yn Jira eisoes wedi'i lenwi, mae'r peiriannydd yn gwybod pa fath a maint y ddisg. Mae'r data hwn yn cael ei fewnbynnu naill ai'n awtomatig ar y statws blaenorol neu gan y gweinyddwr.

Ar ôl amnewid y ddisg, mae statws y tocyn yn cael ei newid i Wedi newid. Mae'n gwirio bod y ddisg gywir wedi'i mewnosod, rhaniad yn cael ei wneud, y cais yn cael ei lansio a rhai tasgau adfer data yn cael eu lansio. Gellir trosglwyddo'r tocyn i'r statws hefyd Yn barod, yn yr achos hwn bydd y gweinyddwr yn parhau i fod yn gyfrifol, oherwydd ei fod yn rhoi'r ddisg yn cylchdroi. Mae'r diagram cyflawn yn edrych fel hyn.

Awtomeiddio Disodli Disod gydag Ansible
Roedd ychwanegu meysydd newydd yn gwneud ein bywyd yn llawer haws. Dechreuodd y dynion weithio gyda gwybodaeth strwythuredig, daeth yn amlwg beth oedd angen ei wneud ac ar ba gam. Mae blaenoriaethau wedi dod yn llawer mwy perthnasol, gan eu bod bellach yn cael eu gosod gan y gweinyddwr.

Nid oes angen sgyrsiau. Wrth gwrs, gall y gweinyddwr ysgrifennu at y peiriannydd “mae angen ailosod hwn yn gyflymach,” neu “mae hi eisoes yn hwyr, a fydd gennych chi amser i'w ddisodli?” Ond nid ydym bellach yn cyfathrebu'n ddyddiol mewn sgyrsiau ar y materion hyn.

Dechreuwyd newid disgiau mewn sypiau. Pe bai'r gweinyddwr yn dod i weithio ychydig yn gynnar, mae ganddo amser rhydd, ac nid oes dim wedi digwydd eto, gall baratoi nifer o weinyddion i'w disodli: llenwi'r meysydd, tynnu'r disgiau o gylchdroi a throsglwyddo'r dasg i beiriannydd. Daw'r peiriannydd i'r ganolfan ddata ychydig yn ddiweddarach, mae'n gweld y dasg, yn cymryd y gyriannau angenrheidiol o'r warws ac yn eu disodli ar unwaith. O ganlyniad, mae'r gyfradd adnewyddu wedi cynyddu.

Gwersi a ddysgwyd wrth adeiladu Llif Gwaith

  • Wrth lunio gweithdrefn, mae angen i chi gasglu gwybodaeth o wahanol ffynonellau.
    Nid oedd rhai o'n gweinyddwyr yn gwybod bod y peiriannydd yn newid y disgiau ei hun. Roedd rhai pobl yn meddwl bod peirianwyr yn ymdrin â chydamseru MD RAID, er nad oedd gan rai ohonynt fynediad i wneud hynny hyd yn oed. Gwnaeth rhai peirianwyr blaenllaw hyn, ond nid bob amser oherwydd na chafodd y broses ei disgrifio yn unman.
  • Dylai'r weithdrefn fod yn syml ac yn ddealladwy.
    Mae'n anodd i berson gadw llawer o gamau mewn cof. Dylid gosod y statws cyfagos pwysicaf yn Jira ar y brif sgrin. Gallwch eu hail-enwi, er enghraifft, rydym yn galw Ar y gweill Yn barod i newid. A gellir cuddio statwsau eraill mewn cwymplen fel nad ydynt yn ddolur llygad. Ond mae'n well peidio â chyfyngu ar bobl, i roi'r cyfle iddynt drosglwyddo.
    Egluro gwerth arloesi. Pan fydd pobl yn deall, maent yn fwy parod i dderbyn y weithdrefn newydd. Roedd yn bwysig iawn i ni nad yw pobl yn clicio drwy’r broses gyfan, ond yn ei dilyn. Yna fe wnaethom adeiladu awtomeiddio ar hyn.
  • Arhoswch, dadansoddwch, cyfrifwch ef.
    Cymerodd tua mis i ni adeiladu'r weithdrefn, gweithredu technegol, cyfarfodydd a thrafodaethau. Ac mae gweithredu yn cymryd mwy na thri mis. Gwelais sut mae pobl yn araf yn dechrau defnyddio'r arloesedd. Roedd llawer o negyddiaeth yn y cyfnodau cynnar. Ond roedd yn gwbl annibynnol ar y weithdrefn ei hun a'i gweithrediad technegol. Er enghraifft, ni ddefnyddiodd un gweinyddwr Jira, ond ategyn Jira yn Confluence, ac nid oedd rhai pethau ar gael iddo. Fe wnaethon ni ddangos Jira iddo, a chynyddodd cynhyrchiant y gweinyddwr ar gyfer tasgau cyffredinol ac ar gyfer ailosod disgiau.

Awtomeiddio ailosod disg

Aethom at awtomeiddio ailosod disg sawl gwaith. Roedd gennym ni ddatblygiadau a sgriptiau eisoes, ond roedden nhw i gyd yn gweithio naill ai'n rhyngweithiol neu â llaw ac roedd angen eu lansio. A dim ond ar ôl cyflwyno'r drefn newydd y sylweddolon ni mai dyma'n union yr oeddem ni ar goll.

Ers nawr mae ein proses ddisodli wedi'i rhannu'n gamau, ac mae gan bob un ohonynt berfformiwr penodol a rhestr o gamau gweithredu, gallwn alluogi awtomeiddio fesul cam, ac nid i gyd ar unwaith. Er enghraifft, mae'n hawdd dirprwyo'r cam symlaf - Ready (gwirio RAID / cydamseru data) i bot. Pan fydd y bot wedi dysgu ychydig, gallwch chi roi tasg bwysicach iddo - rhoi'r ddisg mewn cylchdro, ac ati.

Gosodiadau sw

Cyn i ni siarad am y bot, gadewch i ni fynd ar daith fer i'n sw o osodiadau. Yn gyntaf oll, mae hyn oherwydd maint enfawr ein seilwaith. Yn ail, rydym yn ceisio dewis y cyfluniad caledwedd gorau posibl ar gyfer pob gwasanaeth. Mae gennym tua 20 o fodelau RAID caledwedd, yn bennaf LSI ac Adaptec, ond mae yna hefyd HP a DELL o fersiynau gwahanol. Mae gan bob rheolydd RAID ei ddefnyddioldeb rheoli ei hun. Gall y set o orchmynion a'u cyhoeddi fod yn wahanol o fersiwn i fersiwn ar gyfer pob rheolydd RAID. Lle na ddefnyddir HW-RAID, gellir defnyddio mdraid.

Rydym yn gwneud bron pob gosodiad newydd heb ddisg wrth gefn. Rydym yn ceisio peidio â defnyddio RAID caledwedd a meddalwedd mwyach, wrth i ni wneud copïau wrth gefn o'n systemau ar lefel canolfan ddata, nid gweinyddwyr. Ond wrth gwrs mae yna lawer o weinyddion etifeddiaeth y mae angen eu cefnogi.

Rhywle mae'r disgiau mewn rheolwyr RAID yn cael eu trosglwyddo i ddyfeisiadau amrwd, yn rhywle defnyddir JBODs. Mae yna gyfluniadau gydag un disg system yn y gweinydd, ac os oes angen ei ddisodli, yna mae'n rhaid i chi ailosod y gweinydd gyda gosod yr OS a chymwysiadau, o'r un fersiynau, yna ychwanegu ffeiliau cyfluniad, lansio cymwysiadau. Mae yna hefyd lawer o grwpiau gweinyddwyr lle mae copi wrth gefn yn cael ei wneud nid ar lefel is-system disg, ond yn uniongyrchol yn y cymwysiadau eu hunain.

Yn gyfan gwbl, mae gennym dros 400 o grwpiau gweinyddwyr unigryw sy'n rhedeg bron i 100 o wahanol gymwysiadau. I gwmpasu nifer mor enfawr o opsiynau, roedd angen offeryn awtomeiddio amlswyddogaethol arnom. Yn ddelfrydol gyda DSL syml, fel bod nid yn unig y sawl a'i hysgrifennodd yn gallu ei gefnogi.

Dewisasom Ansible oherwydd ei fod yn ddi-asiant: nid oedd angen paratoi seilwaith, cychwyn cyflym. Yn ogystal, mae wedi'i ysgrifennu yn Python, a dderbynnir fel safon o fewn y tîm.

Cynllun cyffredinol

Gadewch i ni edrych ar y cynllun awtomeiddio cyffredinol gan ddefnyddio un digwyddiad fel enghraifft. Mae Zabbix yn canfod bod y ddisg sdb wedi methu, mae'r sbardun yn goleuo, ac mae tocyn yn cael ei greu yn Jira. Edrychodd y gweinyddwr arno, sylweddoli nad oedd yn ddyblyg ac nid yn bositif ffug, hynny yw, roedd angen newid y ddisg, a throsglwyddo'r tocyn i Ar y gweill.

Awtomeiddio Disodli Disod gydag Ansible
Mae'r cais DiskoBot, a ysgrifennwyd yn Python, o bryd i'w gilydd yn pleidleisio ar Jira am docynnau newydd. Mae'n sylwi bod tocyn Ar y gweill newydd wedi ymddangos, mae'r edefyn cyfatebol yn cael ei sbarduno, sy'n lansio'r llyfr chwarae yn Ansible (gwneir hyn ar gyfer pob statws yn Jira). Yn yr achos hwn, mae Prepare2change yn cael ei lansio.

Mae Ansible yn cael ei anfon at y gwesteiwr, yn tynnu'r ddisg o'r cylchdro ac yn adrodd am y statws i'r cais trwy Alwadau.

Awtomeiddio Disodli Disod gydag Ansible
Yn seiliedig ar y canlyniadau, mae'r bot yn trosglwyddo'r tocyn yn awtomatig i Barod i'w newid. Mae'r peiriannydd yn derbyn hysbysiad ac yn mynd i newid y ddisg, ac ar ôl hynny mae'n trosglwyddo'r tocyn i Changed.

Awtomeiddio Disodli Disod gydag Ansible
Yn ôl y cynllun a ddisgrifir uchod, mae'r tocyn yn mynd yn ôl i'r bot, sy'n lansio llyfr chwarae arall, yn mynd i'r gwesteiwr ac yn rhoi'r ddisg mewn cylchdro. Mae'r bot yn cau'r tocyn. Hwre!

Awtomeiddio Disodli Disod gydag Ansible
Nawr, gadewch i ni siarad am rai cydrannau o'r system.

Disgobot

Mae'r cais hwn wedi'i ysgrifennu yn Python. Mae'n dewis tocynnau o Jira yn ôl JQL. Yn dibynnu ar statws y tocyn, mae'r olaf yn mynd i'r triniwr cyfatebol, sydd yn ei dro yn lansio'r llyfr chwarae Ansible sy'n cyfateb i'r statws.

Diffinnir JQL a chyfnodau pleidleisio yn ffeil ffurfweddu'r cais.

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

Er enghraifft, ymhlith tocynnau yn y statws Ar y gweill, dim ond y rhai sydd â'r meysydd maint Disg ac enw Dyfais wedi'u llenwi sy'n cael eu dewis. Enw dyfais yw enw'r ddyfais bloc sydd ei angen i weithredu'r llyfr chwarae. Mae angen maint disg fel bod y peiriannydd yn gwybod pa faint disg sydd ei angen.

Ac ymhlith tocynnau â statws Parod, mae tocynnau gyda'r label dbot_ignore yn cael eu hidlo allan. Gyda llaw, rydym yn defnyddio labeli Jira ar gyfer hidlo o'r fath ac ar gyfer marcio tocynnau dyblyg a chasglu ystadegau.

Os bydd llyfr chwarae yn methu, mae Jira yn aseinio'r label dbot_failed fel y gellir ei ddatrys yn ddiweddarach.

Rhyngweithredu ag Ansible

Mae'r cais yn cyfathrebu ag Ansible trwy API Python Asible. I playbook_executor rydym yn pasio enw'r ffeil a set o newidynnau. Mae hyn yn caniatáu ichi gadw'r prosiect Ansible ar ffurf ffeiliau yml rheolaidd, yn hytrach na'i ddisgrifio mewn cod Python.

Hefyd yn Ansible, trwy * extra_vars *, enw'r ddyfais bloc, statws y tocyn, yn ogystal â'r callback_url, sy'n cynnwys yr allwedd mater - fe'i defnyddir ar gyfer galw yn ôl yn HTTP.

Ar gyfer pob lansiad, cynhyrchir rhestr eiddo dros dro, sy'n cynnwys un gwesteiwr a'r grŵp y mae'r gwesteiwr hwn yn perthyn iddo, fel bod group_vars yn cael eu cymhwyso.

Dyma enghraifft o dasg sy'n gweithredu galwad yn ôl HTTP.

Rydym yn cael canlyniad gweithredu llyfrau chwarae gan ddefnyddio callaback(s). Maent o ddau fath:

  • Ategyn galw'n ôl addas, mae'n darparu data ar ganlyniadau gweithredu llyfr chwarae. Mae'n disgrifio'r tasgau a lansiwyd, a gwblhawyd yn llwyddiannus neu'n aflwyddiannus. Gelwir yr alwad hon yn ôl pan fydd y llyfr chwarae wedi gorffen chwarae.
  • Galwad HTTP yn ôl i dderbyn gwybodaeth wrth chwarae llyfr chwarae. Yn y dasg Ansible rydym yn gweithredu cais POST/CELWCH i'n cais.

Mae newidynnau'n cael eu trosglwyddo trwy alwad(iau) HTTP a ddiffiniwyd yn ystod gweithredu'r llyfr chwarae ac yr ydym am eu cadw a'u defnyddio mewn rhediadau dilynol. Rydym yn ysgrifennu'r data hwn mewn sqlite.

Rydym hefyd yn gadael sylwadau ac yn newid statws y tocyn trwy alwad yn ôl HTTP.

Galwad yn ôl HTTP

# 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

Fel llawer o dasgau o'r un math, rydyn ni'n ei roi mewn ffeil gyffredin ar wahân a'i gynnwys os oes angen, er mwyn peidio â'i ailadrodd yn gyson mewn llyfrau chwarae. Mae hyn yn cynnwys yr url callback_, sy'n cynnwys yr allwedd cyhoeddi ac enw'r gwesteiwr. Pan fydd Ansible yn gweithredu'r cais POST hwn, mae'r bot yn deall iddo ddod fel rhan o ddigwyddiad o'r fath ac o'r fath.

A dyma enghraifft o'r llyfr chwarae, lle rydyn ni'n allbynnu disg o ddyfais 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

Mae'r dasg hon yn trosglwyddo tocyn Jira i'r statws “Barod i newid” ac yn ychwanegu sylw. Hefyd, mae'r newidyn mdam_data yn storio rhestr o ddyfeisiau md y tynnwyd y ddisg ohonynt, ac mae parted_info yn storio dymp rhaniad o parted.

Pan fydd y peiriannydd yn mewnosod disg newydd, gallwn ddefnyddio'r newidynnau hyn i adfer y dymp rhaniad, yn ogystal â mewnosod y ddisg yn y dyfeisiau md y cafodd ei dynnu oddi yno.

Modd gwirio asible

Roedd yn frawychus troi'r awtomeiddio ymlaen. Felly, fe benderfynon ni redeg pob llyfr chwarae yn y modd
rhediad sych, yn yr hwn nid yw Ansible yn cyflawni unrhyw weithrediadau ar y gweinyddion, ond yn unig yn eu hefelychu.

Mae lansiad o'r fath yn cael ei redeg trwy fodiwl galw'n ôl ar wahân, ac mae canlyniad gweithredu'r llyfr chwarae yn cael ei gadw yn Jira fel sylw.

Awtomeiddio Disodli Disod gydag Ansible

Yn gyntaf, gwnaeth hyn hi'n bosibl dilysu gwaith y bot a'r llyfrau chwarae. Yn ail, cynyddodd hyder gweinyddwyr yn y bot.

Pan wnaethom basio'r dilysiad a sylweddoli y gallwch chi redeg Ansible nid yn unig yn y modd rhedeg sych, gwnaethom fotwm Run Diskobot yn Jira i lansio'r un llyfr chwarae gyda'r un newidynnau ar yr un gwesteiwr, ond yn y modd arferol.

Yn ogystal, defnyddir y botwm i ailgychwyn y llyfr chwarae os bydd yn damwain.

Strwythur llyfrau chwarae

Rwyf eisoes wedi sôn, yn dibynnu ar statws y tocyn Jira, bod y bot yn lansio gwahanol lyfrau chwarae.

Yn gyntaf, mae'n llawer haws trefnu'r fynedfa.
Yn ail, mewn rhai achosion mae'n syml angenrheidiol.

Er enghraifft, wrth ailosod disg system, yn gyntaf mae angen i chi fynd i'r system lleoli, creu tasg, ac ar ôl ei ddefnyddio'n gywir, bydd y gweinydd yn dod yn hygyrch trwy ssh, a gallwch chi gyflwyno'r cais arno. Pe baem yn gwneud hyn i gyd mewn un llyfr chwarae, yna ni fyddai Ansible yn gallu ei gwblhau oherwydd nad oedd y gwesteiwr ar gael.

Rydym yn defnyddio rolau Ansible ar gyfer pob grŵp o weinyddion. Yma gallwch weld sut mae'r llyfr(au) chwarae wedi'u trefnu yn un ohonyn nhw.

Awtomeiddio Disodli Disod gydag Ansible

Mae hyn yn gyfleus oherwydd ei bod yn amlwg ar unwaith ble mae pa dasgau wedi'u lleoli. Yn main.yml, sef y mewnbwn ar gyfer y rôl Ansible, gallwn yn syml gynnwys yn ôl statws tocyn neu dasgau cyffredinol sy'n ofynnol i bawb, er enghraifft, pasio adnabod neu dderbyn tocyn.

ymchwiliad.yml

Yn rhedeg am docynnau yn y statws Ymchwiliad ac Agored. Y peth pwysicaf ar gyfer y llyfr chwarae hwn yw enw'r ddyfais bloc. Nid yw'r wybodaeth hon ar gael bob amser.

Er mwyn ei gael, rydym yn dadansoddi crynodeb Jira, y gwerth olaf o'r sbardun Zabbix. Gall gynnwys enw'r ddyfais bloc - lwcus. Neu gall gynnwys pwynt gosod, yna mae angen i chi fynd at y gweinydd, ei ddosrannu a chyfrifo'r ddisg ofynnol. Gall y sbardun hefyd drosglwyddo cyfeiriad scsi neu ryw wybodaeth arall. Ond mae hefyd yn digwydd nad oes unrhyw gliwiau, a rhaid i chi ddadansoddi.

Ar ôl darganfod enw'r ddyfais bloc, rydym yn casglu gwybodaeth am fath a maint y ddisg ohoni i lenwi'r meysydd yn Jira. Rydym hefyd yn dileu gwybodaeth am y gwerthwr, model, firmware, ID, SMART, a mewnosod hyn i gyd i sylw yn y tocyn Jira. Nid oes angen i'r gweinyddwr a'r peiriannydd chwilio am y data hwn mwyach. 🙂

Awtomeiddio Disodli Disod gydag Ansible

paratoi2change.yml

Tynnu'r ddisg o gylchdroi, paratoi ar gyfer ailosod. Y cam mwyaf anodd a phwysig. Dyma lle gallwch atal y cais pan na ddylid ei atal. Neu tynnwch ddisg nad oedd ganddi ddigon o atgynyrchiadau, a thrwy hynny gael effaith ar ddefnyddwyr, gan golli rhywfaint o ddata. Yma mae gennym y nifer fwyaf o wiriadau a hysbysiadau yn y sgwrs.

Yn yr achos symlaf, rydym yn sôn am dynnu disg o RAID HW/MD.

Mewn sefyllfaoedd mwy cymhleth (yn ein systemau storio), pan fydd y copi wrth gefn yn cael ei berfformio ar lefel y cais, mae angen i chi fynd i'r cais trwy'r API, riportio allbwn y ddisg, ei ddadactifadu a dechrau'r adferiad.

Yr ydym yn awr yn ymfudo en masse i y cwmwl, ac os yw'r gweinydd yn seiliedig ar gwmwl, yna mae Diskobot yn galw'r API cwmwl, yn dweud ei fod yn mynd i weithio gyda'r minion hwn - y gweinydd sy'n rhedeg cynwysyddion - ac yn gofyn “mudo pob cynhwysydd o'r minion hwn.” Ac ar yr un pryd, yn troi ar y backlight y ddisg fel y gall y peiriannydd weld ar unwaith pa un sydd angen ei dynnu allan.

newid.yml

Ar ôl ailosod disg, rydym yn gyntaf yn gwirio ei argaeledd.

Nid yw peirianwyr bob amser yn gosod gyriannau newydd, felly fe wnaethom ychwanegu siec am werthoedd SMART sy'n ein bodloni.

Pa rinweddau rydyn ni'n edrych arnyn nhw?Sectorau a Ailddyrannwyd yn Cyfrif (5) < 100
Cyfrif Cyfredol y Sector Arfaethedig (107) == 0

Os bydd y gyriant yn methu'r prawf, hysbysir y peiriannydd i'w ddisodli eto. Os yw popeth mewn trefn, mae'r backlight yn diffodd, gosodir marciau a rhoddir y disg mewn cylchdro.

parod.yml

Yr achos symlaf: gwirio cydamseriad cyrch HW/SW neu orffen cydamseru data yn y cymhwysiad.

API Cais

Rwyf wedi sôn sawl gwaith bod y bot yn aml yn cyrchu APIs cymwysiadau. Wrth gwrs, nid oedd gan bob cais y dulliau angenrheidiol, felly roedd yn rhaid eu haddasu. Dyma'r dulliau pwysicaf rydyn ni'n eu defnyddio:

  • Statws. Statws clwstwr neu ddisg i ddeall a ellir gweithio ag ef;
  • Dechrau/stopio. Ysgogi/dadactifadu disg;
  • Mudo/adfer. Mudo ac adfer data yn ystod ac ar ôl amnewid.

Gwersi a ddysgwyd o Ansible

Dwi wir yn caru Ansible. Ond yn aml, pan fyddaf yn edrych ar wahanol brosiectau ffynhonnell agored a gweld sut mae pobl yn ysgrifennu llyfrau chwarae, rwy'n cael ychydig o ofn. Cydblethu rhesymegol cymhleth o bryd/dolen, diffyg hyblygrwydd ac analluedd oherwydd defnydd aml o gragen/gorchymyn.

Fe benderfynon ni symleiddio popeth cymaint â phosib, gan fanteisio ar fantais Ansible - modiwlaidd. Ar y lefel uchaf mae yna lyfrau chwarae; gellir eu hysgrifennu gan unrhyw weinyddwr, datblygwr trydydd parti sy'n gwybod ychydig yn Ansible.

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

Os yw rhywfaint o resymeg yn anodd ei gweithredu mewn llyfrau chwarae, byddwn yn ei symud i fodiwl neu hidlydd Ansible. Gellir ysgrifennu sgriptiau mewn Python neu unrhyw iaith arall.

Maent yn hawdd ac yn gyflym i'w hysgrifennu. Er enghraifft, mae'r modiwl backlight disg, y dangosir enghraifft ohono uchod, yn cynnwys 265 llinell.

Awtomeiddio Disodli Disod gydag Ansible

Ar y lefel isaf mae'r llyfrgell. Ar gyfer y prosiect hwn, rydym yn ysgrifennu cais ar wahân, yn fath o dynnu dros caledwedd a meddalwedd RAIDs sy'n cyflawni'r ceisiadau cyfatebol.

Awtomeiddio Disodli Disod gydag Ansible

Cryfderau mwyaf Ansible yw ei symlrwydd a'i lyfrau chwarae clir. Rwy'n credu bod angen i chi ddefnyddio hwn a pheidio â chynhyrchu ffeiliau yaml brawychus a nifer enfawr o amodau, cod cragen a dolenni.

Os ydych chi am ailadrodd ein profiad gyda'r API Ansible, cadwch ddau beth mewn cof:

  • Ni ellir rhoi terfyn amser ar playbook_executor a playbooks yn gyffredinol. Mae goramser ar y sesiwn ssh, ond nid oes terfyn amser ar y llyfr chwarae. Os byddwn yn ceisio dadosod disg nad yw'n bodoli bellach yn y system, bydd y llyfr chwarae yn rhedeg yn ddiddiwedd, felly bu'n rhaid i ni lapio ei lansiad mewn papur lapio ar wahân a'i ladd gyda goramser.
  • Mae Ansible yn rhedeg ar brosesau fforchog, felly nid yw ei API yn edau ddiogel. Rydyn ni'n rhedeg pob un o'n llyfrau chwarae un llinyn.

O ganlyniad, roeddem yn gallu awtomeiddio ailosod tua 80% o ddisgiau. Yn gyffredinol, mae'r gyfradd adnewyddu wedi dyblu. Heddiw, mae'r gweinyddwr yn edrych ar y digwyddiad ac yn penderfynu a oes angen newid y ddisg ai peidio, ac yna'n gwneud un clic.

Ond nawr rydyn ni'n dechrau mynd i broblem arall: nid yw rhai gweinyddwyr newydd yn gwybod sut i newid gyriannau. 🙂

Ffynhonnell: hab.com

Ychwanegu sylw