Баарына салам. Мен ОКтун алдыңкы системалык администратору болуп иштейм жана порталдын туруктуу иштеши үчүн жооптуумун. Мен дисктерди автоматтык түрдө алмаштыруу процессин кантип курганыбыз, анан кантип администраторду бул процесстен чыгарып салганыбыз жана аны бот менен алмаштырганыбыз жөнүндө айткым келет.
Бул макала транслитерациянын бир түрү болуп саналат HighLoad+ 2018де
Дискти алмаштыруу процессин куруу
Алгач кээ бир сандар
OK миллиондогон адамдар колдонгон ири кызмат болуп саналат. Аны 7 түрдүү маалымат борборлорунда жайгашкан 4 миңге жакын сервер тейлейт. Серверлерде 70 миңден ашык диск бар. Аларды бири-биринин үстүнө тизип койсоңуз, бийиктиги 1 кмден ашкан мунара пайда болот.
Катуу дисктер көбүнчө иштебей турган сервер компоненти болуп саналат. Мындай көлөмдө биз жумасына 30га жакын дискти алмаштырууга туура келет жана бул жол-жобосу анча деле жагымдуу эмес көрүнүш болуп калды.
Окуялар
Биздин компания толук кандуу инциденттерди башкарууну киргизди. Ар бир окуяны Жирага жазып алып, анан чечип, иреттейбиз. Эгерде кандайдыр бир окуя колдонуучуларга таасирин тийгизген болсо, анда биз сөзсүз чогулуп, мындай учурларда кантип тезирээк жооп кайтаруу, эффектти кантип азайтуу жана, албетте, кайталануунун алдын алуу жөнүндө ойлонобуз.
Сактагыч түзмөктөр да четте калбайт. Алардын абалын Zabbix көзөмөлдөйт. Биз Syslog ичиндеги билдирүүлөрдү жазуу/окуу каталары үчүн көзөмөлдөйбүз, HW/SW рейддеринин абалын талдап, SMART мониторингин жүргүзүп, SSD дисктеринин эскиришин эсептейбиз.
Мурда дисктер кантип өзгөртүлгөн
Zabbix'те триггер пайда болгондо, Jira'да инцидент түзүлөт жана автоматтык түрдө маалымат борборлорунун тиешелүү инженерлерине дайындалат. Биз муну бардык HW инциденттери менен жасайбыз, башкача айтканда, маалымат борборундагы жабдуулар менен физикалык иштөөнү талап кылгандар.
Маалымат борборунун инженери - бул аппараттык камсыздоого байланыштуу маселелерди чечүүчү жана серверлерди орнотуу, тейлөө жана демонтаждоо үчүн жооптуу адам. Билет алгандан кийин инженер ишке киришет. Диск текчелеринде ал дисктерди өз алдынча алмаштырат. Ал эми талап кылынган аппаратка мүмкүнчүлүгү жок болсо, инженер жардам сурап нөөмөттөгү системалык администраторлорго кайрылат. Биринчиден, сиз дискти айлантуудан алып салышыңыз керек. Бул үчүн серверге керектүү өзгөртүүлөрдү киргизип, тиркемелерди токтотуп, дискти ажыратышыңыз керек.
Системанын нөөмөтчү администратору жумушчу нөөмөт учурунда бүткүл порталдын иштеши үчүн жоопкерчилик тартат. Ал инциденттерди иликтейт, оңдоо иштерин жүргүзөт жана иштеп чыгуучуларга кичинекей тапшырмаларды аткарууга жардам берет. Ал катуу дисктер менен гана алектенбейт.
Буга чейин маалымат борборунун инженерлери системанын администратору менен чат аркылуу байланышып турушкан. Инженерлер Jira билеттерине шилтемелерди жөнөтүштү, администратор аларды ээрчип, кээ бир блокнотто иш журналын жүргүздү. Бирок чаттар мындай тапшырмалар үчүн ыңгайсыз: андагы маалымат структураланган эмес жана тез эле жоголот. Ал эми администратор жөн гана компьютерден алыстап, суроо-талаптарга бир нече убакытка чейин жооп бербестен, инженер серверде дисктердин үймөгү менен туруп, күтүп турган.
Бирок эң жаманы, администраторлор бүт сүрөттү көрүшкөн жок: дискте кандай инциденттер бар, кайсы жерде көйгөй келип чыгышы мүмкүн. Бул биз бардык HW инциденттерин инженерлерге тапшырганыбызга байланыштуу. Ооба, бардык инциденттерди администратордун тактасында көрсөтүүгө болот. Бирок алар көп, администратор алардын айрымдарына гана тартылган.
Мындан тышкары, инженер приоритеттерди туура коё алган жок, анткени ал конкреттүү серверлердин максаты же дисктер арасында маалыматты бөлүштүрүү жөнүндө эч нерсе билбейт.
Жаңы алмаштыруу процедурасы
Биз кылган биринчи нерсе, бардык диск инциденттерин өзүнчө түрдөгү "HW дискине" жылдырдык жана ага "блок түзмөгүнүн аталышы", "өлчөмү" жана "диск түрү" деген талааларды коштук, бул маалымат билетте сакталып калат жана чатта дайыма алмашуунун кереги жок.
Биз ошондой эле бир окуя учурунда бир гана дискти алмаштырабыз деп макулдаштык. Бул келечекте автоматташтыруу процессин, статистикалык маалыматтарды чогултууну жана ишти бир кыйла жөнөкөйлөттү.
Мындан тышкары, биз "жооптуу администратор" талаасын коштук. Ал жерге дежур системалык администратор автоматтык түрдө киргизилет. Бул абдан ыңгайлуу, анткени азыр инженер ар дайым ким жооптуу экенин көрүп турат. Календарга барып издөөнүн кереги жок. Дал ушул талаа администратордун тактасында анын жардамын талап кылган билеттерди көрсөтүүгө мүмкүндүк берген.
Бардык катышуучулар инновациялардан максималдуу пайда алышын камсыз кылуу үчүн биз фильтрлерди жана такталарды түзүп, алар жөнүндө балдарга айтып бердик. Адамдар өзгөрүүлөрдү түшүнгөндө, алардан керексиз нерсе катары алысташпайт. Инженер үчүн сервер жайгашкан стеллаждын номерин, дисктин өлчөмүн жана түрүн билүү маанилүү. Администратор, биринчи кезекте, бул кандай серверлер тобу экенин жана дискти алмаштырууда кандай эффект болорун түшүнүшү керек.
Талаалардын болушу жана алардын дисплейи ыңгайлуу, бирок бул бизди чаттарды колдонуу зарылдыгынан куткарган жок. Бул үчүн биз иш тартибин өзгөртүүгө туура келди.
Мурда мындай болгон:
Администратордун жардамына муктаж болбогондо, инженерлер бүгүн да ушинтип иштей беришет.
Биз биринчи кылган жаңы статусту киргиздик изилдөө. Инженер ага администратор керекпи же жокпу чече элек кезде билет ушул статуста болот. Бул статус аркылуу инженер билетти администраторго өткөрүп бере алат. Мындан тышкары, биз бул статусту дискти алмаштыруу керек болгондо билеттерди белгилөө үчүн колдонобуз, бирок дисктин өзү сайтта жок. Бул CDN жана алыскы сайттарда болот.
Биз дагы статусун коштук даяр. Билет ага дискти алмаштыргандан кийин өткөрүлүп берилет. Башкача айтканда, бардыгы жасалган, бирок HW/SW RAID серверде синхрондоштурулган. Бул бир топ убакыт талап кылынышы мүмкүн.
Ишке администратор тартылса, схема бир аз татаалдашат.
Статустан ачык Билетти системанын администратору да, инженер да которо алат. Статусунда Прогрессте администратор дискти айлануудан алып салат, ошондуктан инженер аны жөн эле чыгарып алат: арткы жарыкты күйгүзөт, дискти ажыратат, серверлердин белгилүү бир тобуна жараша тиркемелерди токтотот.
Андан кийин билет которулат өзгөртүүгө даяр: Бул инженерге дискти сууруп алса болот деген сигнал. Жирадагы бардык талаалар толтурулган, инженер дисктин кандай түрүн жана көлөмүн билет. Бул маалымат автоматтык түрдө мурунку статуска же администратор тарабынан киргизилет.
Дискти алмаштыргандан кийин, билеттин абалы өзгөрөт өзгөртүлдү:. Ал туура диск салынганын, бөлүү аткарылганын, тиркеменин иштетилгенин жана айрым маалыматтарды калыбына келтирүү тапшырмаларынын ишке ашырылганын текшерет. Билет статусуна да которулушу мүмкүн даяр, бул учурда администратор жооптуу бойдон калат, анткени ал дискти айлантууга койду. Толук диаграмма ушундай көрүнөт.
Жаңы талааларды кошуу жашообузду бир топ жеңилдетти. Жигиттер структураланган маалымат менен иштей башташты, эмне кылуу керек жана кайсы этапта белгилүү болду. Приоритеттер кыйла актуалдуу болуп калды, анткени алар азыр администратор тарабынан белгиленет.
Чаттын кереги жок. Албетте, администратор инженерге "буну тезирээк алмаштыруу керек" же "кеч болуп калды, аны алмаштырууга убактың барбы?" деп жаза алат. Бирок биз бул маселелер боюнча чатта күн сайын баарлашпайбыз.
Дисктер партиялар менен алмаштырыла баштады. Эгерде администратор жумушка бир аз эрте келсе, анын бош убактысы бар жана али эч нерсе боло элек болсо, ал бир катар серверлерди алмаштырууга даярдай алат: талааларды толтуруп, дисктерди ротациядан алып салыңыз жана тапшырманы инженерге өткөрүп бериңиз. Инженер маалымат борборуна бир аз кечирээк келип, тапшырманы көрүп, кампадан керектүү дисктерди алып, дароо алмаштырат. Натыйжада алмаштыруу коэффи-циенти жогорулады.
Иш процессин курууда алынган сабактар
- Процедураны курууда ар кандай булактардан маалымат чогултуу керек.
Биздин кээ бир администраторлор инженер дисктерди өзү алмаштырып жатканын билишчү эмес. Кээ бир адамдар MD RAID синхрондоштурууну инженерлер ишке ашырат деп ойлошкон, бирок алардын айрымдарынын буга мүмкүнчүлүгү жок. Кээ бир алдыңкы инженерлер муну жасашкан, бирок бул процесс эч жерде сүрөттөлбөгөндүктөн дайыма эмес. - Процедура жөнөкөй жана түшүнүктүү болушу керек.
Адамдын көп кадамдарын эсинде сактап калуу кыйын. Жирадагы эң маанилүү кошуна статустар башкы экранга жайгаштырылышы керек. Сиз алардын атын өзгөртсөңүз болот, мисалы, биз Процессте деп чакырабыз өзгөртүүгө даяр. Жана башка статустар ачылуучу менюда жашырылышы мүмкүн, ошондуктан алар көздүн жоосун албайт. Бирок адамдарды чектебей, аларга өтүү мүмкүнчүлүгүн берген жакшы.
Инновациянын баалуулугун түшүндүрүңүз. Адамдар түшүнгөндө жаңы процедураны көбүрөөк кабыл алышат. Биз үчүн адамдардын бүт процессти басып өтпөстөн, аны ээрчигени абдан маанилүү болду. Андан кийин биз бул боюнча автоматташтырылган. - Күтө туруңуз, анализдеп көрүңүз.
Процедураны, техникалык ишке ашырууну, жолугушууларды жана талкууларды курууга бир айга жакын убакыт кетти. Ал эми ишке ашыруу үч айдан ашык убакытты талап кылат. Адамдар акырындык менен инновацияны колдоно баштаганын көрдүм. Алгачкы этапта терс көрүнүштөр көп болгон. Бирок ал процедуранын өзүнөн жана анын техникалык ишке ашырылышынан толугу менен көз карандысыз болгон. Мисалы, бир администратор Jira колдонгон эмес, бирок Confluenceдеги Jira плагини жана кээ бир нерселер ага жеткиликтүү болгон эмес. Биз ага Жираны көрсөттүк жана администратордун өндүрүмдүүлүгү жалпы тапшырмалар үчүн дагы, дисктерди алмаштыруу үчүн дагы жогорулады.
Дискти алмаштырууну автоматташтыруу
Биз дискти алмаштырууну автоматташтырууга бир нече жолу кайрылдык. Бизде буга чейин иштеп чыгуулар жана сценарийлер бар болчу, бирок алардын бардыгы интерактивдүү же кол менен иштеген жана ишке киргизүүнү талап кылган. Жана жаңы процедураны киргизгенден кийин гана бул бизге жетишпей жаткан нерсе экенин түшүндүк.
Азыр биздин алмаштыруу процессибиз этаптарга бөлүнгөндүктөн, алардын ар биринде белгилүү бир аткаруучу жана иш-аракеттердин тизмеси бар, биз автоматташтырууну дароо эмес, этап менен иштете алабыз. Мисалы, эң жөнөкөй этап - Даяр (RAID/маалымат синхронизациясын текшерүү) ботко оңой эле тапшырылышы мүмкүн. Бот бир аз үйрөнгөндө, сиз ага маанилүү тапшырма бере аласыз - дискти айлантууну ж.б.
Зоопарк орнотуулары
Бот жөнүндө сөз кылуудан мурун, келгиле, биздин зоопаркка кыскача экскурсия жасайлы. Биринчиден, бул биздин инфраструктурабыздын гиганттык көлөмүнө байланыштуу. Экинчиден, биз ар бир кызмат үчүн оптималдуу аппараттык конфигурацияны тандоого аракет кылабыз. Бизде 20га жакын аппараттык RAID моделдери бар, негизинен LSI жана Adaptec, бирок HP жана DELL ар кандай версиялары да бар. Ар бир RAID контроллерунун өзүнүн башкаруу программасы бар. Буйруктардын топтому жана аларды чыгаруу ар бир RAID контроллери үчүн версиядан версияга жараша айырмаланышы мүмкүн. HW-RAID колдонулбаган жерде, mdraid колдонулушу мүмкүн.
Биз дээрлик бардык жаңы орнотууларды дисктин камдык көчүрмөсү жок жасайбыз. Биз RAID аппараттык жана программалык камсыздоону мындан ары колдонбоого аракет кылабыз, анткени системаларыбызды серверлерде эмес, маалымат борборунун деңгээлинде сактайбыз. Бирок, албетте, колдоого алынышы керек болгон көптөгөн эски серверлер бар.
Бир жерде RAID контроллерлорундагы дисктер чийки түзмөктөргө өткөрүлүп берилет, бир жерде JBOD колдонулат. Серверде бир системалык диск менен конфигурациялар бар жана аны алмаштыруу керек болсо, серверди ОС жана тиркемелерди орнотуу менен кайра орнотуу керек, ошол эле версиялар, андан кийин конфигурация файлдарын кошуп, тиркемелерди ишке киргизүү керек. Резервдик көчүрүү дисктин подсистемасынын деңгээлинде эмес, түздөн-түз тиркемелердин өзүндө жүзөгө ашырылган көптөгөн сервердик топтор бар.
Жалпысынан бизде 400гө жакын ар кандай тиркемелерди иштеткен 100дөн ашык уникалдуу сервер топтору бар. Мынчалык көп сандагы варианттарды камтуу үчүн бизге көп функциялуу автоматташтыруу куралы керек болчу. Жөнөкөй DSL менен жакшыраак, аны жазган адам гана эмес, аны колдой алат.
Биз Ansibleди тандадык, анткени ал агентсиз: инфраструктураны даярдоонун кереги жок болчу, тез баштоо. Кошумчалай кетсек, ал команданын ичинде стандарт катары кабыл алынган Python тилинде жазылган.
жалпы схемалык
Мисал катары бир окуяны колдонуу менен жалпы автоматташтыруу схемасын карап көрөлү. Zabbix sdb диски иштебей калганын аныктайт, триггер күйөт жана Жирада билет түзүлөт. Администратор аны карап, анын дубликат эмес жана жалган позитив эмес экенин, башкача айтканда, дискти алмаштыруу керек экендигин түшүнүп, билетти Процесске өткөрүп берди.
Python тилинде жазылган DiskoBot тиркемеси маал-маалы менен Jiraдан жаңы билеттерди сурайт. Ал жаңы "Алып жатат" билети пайда болгонун байкайт, тиешелүү жип ишке киргизилди, ал Ansibleде оюн китебин ишке киргизет (бул Jiraдагы ар бир статус үчүн жасалат). Бул учурда, Prepare2change ишке киргизилет.
Ansible хостко жөнөтүлөт, дискти айлануудан алып салат жана Callbacks аркылуу тиркемеге статусун билдирет.
Натыйжалардын негизинде бот билетти автоматтык түрдө өзгөртүүгө даяр дегенге өткөрөт. Инженер эскертме алат жана дискти алмаштырууга барат, андан кийин билетти Changed дегенге өткөрүп берет.
Жогоруда сүрөттөлгөн схемага ылайык, билет ботко кайтып келет, ал башка оюн китебин ишке киргизет, хостко барат жана дискти айлантууга коёт. Бот билетти жабат. Жашасын!
Эми системанын кээ бир компоненттери жөнүндө сүйлөшөлү.
Diskobot
Бул колдонмо Python тилинде жазылган. Ал JQL боюнча Jiraдан билеттерди тандайт. Билеттин абалына жараша, экинчиси тиешелүү иштетүүчүгө барат, ал өз кезегинде статуска ылайыктуу Ansible ойнотуу китебин ишке киргизет.
JQL жана шайлоо интервалдары колдонмо конфигурация файлында аныкталган.
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
Мисалы, "Алып жатат" абалындагы билеттердин ичинен Дисктин өлчөмү жана Түзмөктүн аталышы талаалары толтурулгандары гана тандалат. Түзмөктүн аталышы – ойнотуу китебин аткаруу үчүн керектүү блок түзмөгүнүн аталышы. Дисктин көлөмү инженерге кандай өлчөмдө диск керек экенин билиши үчүн керек.
Жана Даяр статусу бар билеттердин ичинен dbot_ignore энбелгиси бар билеттер чыпкадан чыгарылат. Баса, биз Jira энбелгилерин ушундай чыпкалоо үчүн да, кайталанма билеттерди белгилөө жана статистиканы чогултуу үчүн да колдонобуз.
Ойнотуу китеби иштебей калса, Jira кийинчерээк иреттөө үчүн dbot_failed энбелгини дайындайт.
Ansible менен өз ара аракеттенүү
Колдонмо Ansible аркылуу байланышат . playbook_executor үчүн биз файлдын атын жана өзгөрмөлөр топтомун өткөрүп беребиз. Бул Ansible долбоорун Python кодунда сүрөттөгөндүн ордуна, кадимки yml файлдары түрүндө сактоого мүмкүндүк берет.
Ошондой эле Ansibleде *extra_vars* аркылуу блок түзмөгүнүн аталышы, билеттин статусу, ошондой эле маселе ачкычын камтыган callback_url - ал HTTPде кайра чалуу үчүн колдонулат.
Ар бир ишке киргизүү үчүн убактылуу инвентаризация түзүлөт, ал бир хосттон жана бул хост таандык болгон топтон турат, ошондуктан group_vars колдонулат.
Бул жерде HTTP кайра чалууну ишке ашырган тапшырманын мисалы.
Чалууларды колдонуу менен ойнотуу китептерин аткаруунун натыйжасын алабыз. Алар эки түрү бар:
- , ал оюн китебинин аткарылышынын натыйжалары жөнүндө маалыматтарды берет. Ал ишке киргизилген, ийгиликтүү же ийгиликсиз аяктаган милдеттерди сүрөттөйт. Бул кайра чалуу оюн китеби ойноп бүткөндө чакырылат.
- Оюн китебин ойноп жатканда маалымат алуу үчүн HTTP кайра чалуу. Ansible тапшырмасында биз колдонмобузга POST/GET өтүнүчүн аткарабыз.
Өзгөрмөлөр ойнотуу китебинин аткарылышы учурунда аныкталган жана биз сактап жана кийинки иштетүүдө колдонгубуз келген HTTP кайра чалуу(лар) аркылуу өткөрүлөт. Биз бул маалыматтарды sqlite менен жазабыз.
Биз ошондой эле комментарий калтырабыз жана HTTP кайра чалуу аркылуу билеттин абалын өзгөртөбүз.
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
Бир эле типтеги көптөгөн тапшырмалар сыяктуу эле, биз аны өзүнчө жалпы файлга салып, керек болсо, аны дайыма ойноо китептеринде кайталабоо үчүн киргизебиз. Бул маселе ачкычын жана хосттун атын камтыган callback_ url'ди камтыйт. Ansible бул POST өтүнүчүн аткарганда, бот анын баланча окуянын бир бөлүгү катары келгенин түшүнөт.
Бул жерде биз 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
Бул тапшырма Jira билетин "Өзгөртүүгө даяр" статусуна өткөрүп, комментарий кошот. Ошондой эле, mdam_data өзгөрмөсү диск алынып салынган md түзмөктөрүнүн тизмесин сактайт, ал эми parted_info partedден бөлүү таштандысын сактайт.
Инженер жаңы дискти киргизгенде, биз бул өзгөрмөлөрдү бөлүмдүн таштандысын калыбына келтирүү үчүн колдоно алабыз, ошондой эле дискти ал алынып салынган md түзмөктөрүнө кыстара алабыз.
Ansible текшерүү режими
Автоматиканы иштетүү коркунучтуу эле. Ошондуктан, биз бардык оюн китептерин режимде иштетүүнү чечтик
, анда Ansible серверлерде эч кандай иш-аракеттерди жасабайт, бирок аларды туурайт.
Мындай ишке киргизүү өзүнчө кайра чалуу модулу аркылуу ишке ашырылат жана оюн китебинин аткарылышынын натыйжасы комментарий катары Жирада сакталат.
Биринчиден, бул боттун жана оюн китептеринин ишин текшерүүгө мүмкүндүк берди. Экинчиден, администраторлордун ботко болгон ишенимин арттырды.
Биз валидациядан өтүп, Ansibleди кургак иштетүү режиминде гана иштете албасыңызды түшүнгөндө, биз Жирада Run Diskobot баскычын жасап, ошол эле хостто бирдей өзгөрмөлөр менен бир эле оюн китебин, бирок кадимки режимде ишке киргиздик.
Кошумчалай кетсек, баскыч бузулуп калса, ойнотуу китебин кайра баштоо үчүн колдонулат.
Оюн китептеринин түзүмү
Мен буга чейин Jira билетинин абалына жараша бот ар кандай ойноо китептерин ишке киргизерин айтып өттүм.
Биринчиден, кире беришин уюштуруу бир топ жеңил болот.
Экинчиден, кээ бир учурларда жөн эле зарыл.
Мисалы, тутумдук дискти алмаштырууда, адегенде жайылтуу тутумуна өтүп, тапшырма түзүшүңүз керек жана туура жайгаштыруудан кийин сервер ssh аркылуу жеткиликтүү болуп калат жана ага тиркемени чыгара аласыз. Эгерде биз мунун баарын бир оюн китебинде жасасак, анда Ansible аны бүтүрө албайт, анткени хост жеткиликтүү эмес.
Биз серверлердин ар бир тобу үчүн Ansible ролдорун колдонобуз. Бул жерден сиз алардын биринде оюн китепчеси(лер) кандай уюштурулганын көрө аласыз.
Бул ыңгайлуу, анткени кайсыл милдеттер кайсы жерде жайгашканы дароо айкын болот. Ansible ролунун киргизүүсү болгон main.yml ичинде биз жөн гана билеттин статусу же ар бир адам үчүн талап кылынган жалпы тапшырмаларды, мисалы, идентификациядан өтүү же белгини алуу менен кошо алабыз.
тергөө.yml
Тергөө жана Ачык абалында билеттер үчүн иштейт. Бул оюн китеби үчүн эң маанилүү нерсе - блок түзмөгүнүн аталышы. Бул маалымат дайыма эле жеткиликтүү боло бербейт.
Аны алуу үчүн, биз Jira корутундусун, Zabbix триггеринин акыркы маанисин талдайбыз. Ал блок аппараттын атын камтышы мүмкүн - бактылуу. Же ал орнотуу чекитин камтышы мүмкүн, андан кийин серверге барып, аны талдап, керектүү дискти эсептөө керек. Триггер ошондой эле scsi дарегин же башка маалыматты бере алат. Бирок, ошондой эле эч кандай илинчектер жок болот, жана талдоо керек.
Блок түзмөгүнүн атын билип, биз Жирадагы талааларды толтуруу үчүн андан дисктин түрү жана өлчөмү жөнүндө маалымат чогултабыз. Биз ошондой эле сатуучу, модель, микропрограмма, ID, SMART жөнүндө маалыматты алып салабыз жана мунун баарын Jira билетиндеги комментарийге киргизебиз. Администратор жана инженер мындан ары бул маалыматтарды издөөнүн кереги жок. 🙂
даярдоо2change.yml
Дискти айлануудан алып салуу, алмаштырууга даярдоо. Эң татаал жана маанилүү этап. Бул жерде сиз колдонмону токтотпосоңуз болот. Же репликалары жетишсиз болгон дискти алып салыңыз жана ошону менен айрым маалыматтарды жоготуп, колдонуучуларга таасирин тийгизет. Бул жерде бизде чатта эң көп текшерүүлөр жана эскертмелер бар.
Эң жөнөкөй учурда, биз дискти HW/MD RAIDден алып салуу жөнүндө сөз болуп жатат.
Татаал кырдаалдарда (биздин сактоо тутумдарыбызда), камдык көчүрмө тиркеме деңгээлинде аткарылганда, API аркылуу тиркемеге өтүп, дисктин чыгышы жөнүндө кабарлап, аны өчүрүп, калыбына келтирүүнү баштоо керек.
Биз азыр массалык түрдө көчүп жатабыз , жана эгерде сервер булутка негизделген болсо, анда Diskobot булут API'син чакырып, бул минион менен - контейнерлерди иштеткен сервер менен иштей турганын айтып, "бул миниондон бардык контейнерлерди көчүрүүнү" суранат. Ошол эле учурда, инженер кайсынысын сууруп алуу керектигин дароо көрө алышы үчүн, дисктин арткы жарыгын күйгүзөт.
change.yml
Дискти алмаштыргандан кийин, биз алгач анын жеткиликтүүлүгүн текшеребиз.
Инженерлер ар дайым жаңы дисктерди орното бербейт, ошондуктан бизди канааттандырган SMART баалуулуктарын текшерүүнү коштук.
Биз кандай атрибуттарды карап жатабыз?Кайра бөлүштүрүлгөн секторлордун саны (5) < 100
Учурдагы Күтүүдөгү секторлордун саны (107) == 0
Эгерде диск сыноодон өтпөй калса, инженерге аны кайра алмаштыруу жөнүндө кабар берилет. Эгерде баары өз нугунда болсо, арткы жарык өчөт, белгилер коюлат жана диск айланууга коюлат.
даяр.yml
Эң жөнөкөй учур: HW/SW рейддик синхрондоштурууну текшерүү же колдонмодогу маалыматтарды синхрондоштурууну бүтүрүү.
Колдонмо API
Мен бот көп учурда колдонмо API'лерине кирерин бир нече жолу айттым. Албетте, бардык тиркемелерде керектүү ыкмалар болгон эмес, ошондуктан аларды өзгөртүүгө туура келген. Бул жерде биз колдонгон эң маанилүү ыкмалар:
- Статус. Кластердин же дисктин абалы, аны менен иштөөгө болорун түшүнүү;
- Start/stop. Дискти активдештирүү/өчүрүү;
- Көчүрүү/калыбына келтирүү. Алмаштыруу учурунда жана андан кийин маалыматтарды көчүрүү жана калыбына келтирүү.
Ansibleден алынган сабактар
Мен чындап эле Ansible сүйөм. Бирок көп учурда мен ар кандай ачык булак долбоорлорун карап, адамдардын оюн китептерин кантип жазганын көргөндө, мен бир аз коркуп кетем. Качан/укуруктун татаал логикалык аралашуусу, кабыктын/буйруктун тез-тез колдонулушунан улам ийкемдүүлүктүн жана идемпотенттүүлүктүн жоктугу.
Биз Ansible - модулдуктун артыкчылыгынан пайдаланып, баарын мүмкүн болушунча жөнөкөйлөштүрүү чечимине келдик. Эң жогорку деңгээлде ойноо китептери бар; аларды бир аз Ansible билген каалаган администратор, үчүнчү тараптын иштеп чыгуучусу жазса болот.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Эгерде кээ бир логиканы оюн китептеринде ишке ашыруу кыйын болсо, биз аны Ansible модулуна же чыпкасына жылдырабыз. Скрипттерди Python же башка тилде жазса болот.
Алар жазуу үчүн жеңил жана тез. Мисалы, дисктин арткы жарык модулу, мисалы, жогоруда көрсөтүлгөн, 265 саптан турат.
Эң төмөнкү деңгээлде китепкана жайгашкан. Бул долбоор үчүн биз өзүнчө тиркемени жаздык, тиешелүү суроо-талаптарды аткарган аппараттык жана программалык RAIDтерге абстракциянын бир түрү.
Ansible эң күчтүү жактары анын жөнөкөйлүгү жана түшүнүктүү окуу китептери. Мен муну колдонуп, коркунучтуу yaml файлдарын жана көптөгөн шарттарды, кабык кодун жана циклдерди жаратпашыңар керек деп эсептейм.
Эгерде сиз Ansible API менен болгон тажрыйбабызды кайталагыңыз келсе, эки нерсени эстен чыгарбаңыз:
- Playbook_executor жана жалпысынан ойнотуу китептерине тайм-аут берилбейт. ssh сессиясында тайм-аут бар, бирок оюн китебинде тайм-аут жок. Эгерде биз тутумда жок болгон дискти ажыратууга аракет кылсак, ойнотуу китеби чексиз иштейт, андыктан аны ишке киргизүүнү өзүнчө орогучка ороп, тайм-аут менен жок кылышыбыз керек болчу.
- Ansible айры процесстерде иштейт, андыктан анын API жип коопсуз эмес. Биз бардык окуу китептерибизди бир жип менен иштетебиз.
Натыйжада биз дисктердин 80%ке жакынын алмаштырууну автоматташтыра алдык. Жалпысынан, алмаштыруу көрсөткүчү эки эсеге өстү. Бүгүн, администратор жөн гана окуяны карап, дискти өзгөртүү керекпи же жокпу, чечет, андан кийин бир чыкылдатуу.
Бирок азыр биз дагы бир көйгөйгө туш болуп жатабыз: кээ бир жаңы администраторлор дисктерди кантип алмаштырууну билишпейт. 🙂
Source: www.habr.com