Бәріңе сәлем. Мен OK-да жетекші жүйелік әкімші болып жұмыс істеймін және порталдың тұрақты жұмысына жауаптымын. Мен дискіні автоматты түрде ауыстыру процесін қалай құрастырғанымыз туралы, содан кейін әкімшіні осы процестен қалай алып тастағанымыз және оны ботпен ауыстырғанымыз туралы айтқым келеді.
Бұл мақала транслитерацияның бір түрі болып табылады HighLoad+ 2018 нұсқасында
Дискіні ауыстыру процесін құру
Алдымен бірнеше сандар
OK — миллиондаған адамдар пайдаланатын алып қызмет. Оған 7 түрлі деректер орталығында орналасқан 4 мыңға жуық сервер қызмет көрсетеді. Серверлерде 70 мыңнан астам дискілер бар. Егер сіз оларды бір-бірінің үстіне қойсаңыз, сіз биіктігі 1 км-ден асатын мұнара аласыз.
Қатты дискілер жиі істен шығатын сервер құрамдас бөлігі болып табылады. Бұл көлемде біз аптасына 30-ға жуық дискіні ауыстыруымыз керек және бұл процедура өте жағымды емес әдетке айналды.
Оқиғалар
Біз компаниямызда толыққанды оқиғаларды басқаруды енгіздік. Біз Жирадағы әрбір оқиғаны жазып аламыз, содан кейін оны шешіп, талдаймыз. Егер оқиға пайдаланушыларға әсер еткен болса, онда біз міндетті түрде жиналып, мұндай жағдайларда қалай тезірек әрекет ету керек, әсерді қалай азайтуға болады және, әрине, қайталанудың алдын алу туралы ойланамыз.
Сақтау да ерекшелік емес. Zabbix олардың күйін бақылайды. Біз Syslog жүйесіндегі хабарламаларды жазу/оқу қателеріне бақылаймыз, HW/SW рейдтерінің күйін талдаймыз, SMART бақылаймыз, SSD дискілерінің тозуын есептейміз.
Бұрын дискілер қалай өзгерді
Zabbix-те триггер іске қосылғанда, Jira-да оқиға жасалады және деректер орталықтарында сәйкес инженерлерді автоматты түрде орналастырады. Біз мұны барлық HW оқиғаларымен, яғни деректер орталығындағы жабдықта қандай да бір физикалық жұмысты қажет ететін оқиғалармен жасаймыз.
Деректер орталығының инженері - аппараттық құралдарға қатысты мәселелерді шешетін, серверлерді орнатуға, жөндеуге және бөлшектеуге жауапты адам. Билет алған инженер жұмысқа кіріседі. Дискілік сөрелерде ол дискілерді өздігінен өзгертеді. Бірақ егер ол қажетті құрылғыға қол жеткізе алмаса, инженер көмек алу үшін кезекші жүйе әкімшілеріне жүгінеді. Ең алдымен, дискіні айналымнан шығару керек. Ол үшін серверде қажетті өзгерістерді енгізу, қолданбаларды тоқтату, дискіні ажырату қажет.
Жүйелік әкімші кезекші жұмыс ауысымы кезінде бүкіл порталдың жұмысына жауап береді. Ол оқиғаларды зерттейді, жөндеу жұмыстарын жүргізеді, әзірлеушілерге шағын тапсырмаларды орындауға көмектеседі. Бұл тек қатты дискілерге қатысты емес.
Бұрын деректер орталығының инженерлері жүйе әкімшісімен сөйлесетін. Инженерлер Jira билеттеріне сілтемелер жіберді, әкімші оларды қарап шықты, кейбір блокнотта жұмыс журналын жүргізді. Бірақ мұндай тапсырмалар үшін чаттар ыңғайсыз: ондағы ақпарат құрылымдалмаған және тез жоғалады. Иә, және әкімші компьютерден алыстап, біраз уақыт сұрауларға жауап бермеуі мүмкін, ал инженер серверде дискілер пакетімен тұрып, күтті.
Бірақ ең сорақысы, әкімшілер бүкіл суретті көрмеді: қандай дискі оқиғалары бар, қай жерде мәселе туындауы мүмкін. Бұл барлық ЖЖ оқиғаларын инженерлерге беретінімізге байланысты. Иә, әкімші бақылау тақтасында барлық оқиғаларды көрсету мүмкін болды. Бірақ олардың саны өте көп, ал әкімші олардың кейбіріне ғана қатысты.
Сонымен қатар, инженер дұрыс басымдық бере алмады, өйткені ол нақты серверлердің мақсаты туралы, дискілер арасында ақпаратты тарату туралы ештеңе білмейді.
Жаңа ауыстыру процедурасы
Біз жасаған бірінші нәрсе - барлық дискідегі оқиғаларды бөлек түрдегі «HW дискісіне» жылжыту және оған «құрылғы атауын бұғаттау», «өлшем» және «диск түрі» өрістерін қосу, осылайша бұл ақпарат билетте сақталады және сақталмайды. үнемі сөйлесу керек.
Біз сондай-ақ бір оқиға аясында бір ғана дискіні ауыстырамыз деп келістік. Бұл автоматтандыру процесін, статистикалық мәліметтерді жинауды және болашақта жұмысты айтарлықтай жеңілдетті.
Сонымен қатар, «жауапты әкімші» өрісі қосылды. Онда кезекші жүйе әкімшісі автоматты түрде ауыстырылады. Бұл өте ыңғайлы, өйткені қазір инженер кімнің жауапты екенін үнемі көреді. Күнтізбеге кіріп, қараудың қажеті жоқ. Дәл осы өріс әкімшінің бақылау тақтасында оның көмегі қажет болуы мүмкін билеттерді көрсетуге мүмкіндік берді.
Барлық қатысушылар инновациялардан барынша пайда алу үшін біз сүзгілер мен бақылау тақталарын жасап, жігіттерге олар туралы айтып бердік. Адамдар өзгерісті түсінгенде, олар қажетсіз нәрсе ретінде одан алыстамайды. Инженер үшін сервердің қай жерде орналасқан сөре нөмірін, дискінің өлшемі мен түрін білу маңызды. Әкімші, ең алдымен, оның қандай серверлер тобы екенін, дискіні ауыстыру кезінде қандай әсер етуі мүмкін екенін түсінуі керек.
Өрістердің болуы және оларды көрсету ыңғайлы, бірақ бұл бізді чаттарды пайдалану қажеттілігінен құтқармады. Ол үшін жұмыс процесін өзгертуге тура келді.
Бұрын былай болған:
Бүгінде инженерлер әкімшінің көмегін қажет етпеген кезде жұмысын осылай жалғастыруда.
Ең бірінші жаңа мәртебені енгіздік Зерттеу. Инженер әкімші қажет пе, жоқ па деген шешім қабылдамаған кезде билет осы күйде болады. Бұл мәртебе арқылы инженер билетті әкімшіге бере алады. Сонымен қатар, дискіні ауыстыру қажет болғанда, бірақ дискінің өзі сайтта болмаған кезде біз билеттерді осы күймен белгілейміз. Бұл CDN және қашықтағы сайттар жағдайында орын алады.
Біз сондай-ақ мәртебені қостық дайын. Билет оған диск ауыстырылғаннан кейін беріледі. Яғни, бәрі қазірдің өзінде жасалды, бірақ HW / SW RAID серверде синхрондалған. Бұл өте ұзақ уақыт алуы мүмкін.
Егер жұмысқа әкімші тартылса, схема біршама күрделене түседі.
Күйден тыс ашық Билетті жүйе әкімшісі де, инженер де аудара алады. күйінде Орындалуда әкімші дискіні айналдырудан алып тастайды, осылайша инженер оны шығарып алады: артқы жарықты қосады, дискіні ажыратады, серверлердің белгілі бір тобына байланысты қолданбаларды тоқтатады.
Содан кейін билет аударылады Өзгеруге дайын: Бұл инженерге дискіні шығарып алуға болатыны туралы сигнал. Jira-дағы барлық өрістер толтырылған, инженер дискінің түрі мен өлшемін біледі. Бұл деректер алдыңғы күйде автоматты түрде немесе әкімші арқылы енгізіледі.
Дискіні ауыстырғаннан кейін билет күйге ауысады Өзгертілді. Дұрыс диск салынғаны, бөлімдердің бөлінгені, қолданбаның іске қосылғаны және кейбір деректерді қалпына келтіру тапсырмаларының басталғаны тексеріледі. Сондай-ақ, билетті мәртебеге ауыстыруға болады дайын, бұл жағдайда әкімші жауапты болып қалады, себебі ол дискіні айналдыруда бастады. Толық схема келесідей көрінеді.
Жаңа кен орындарының қосылуы біз үшін өмірді айтарлықтай жеңілдетті. Жігіттер құрылымдық ақпаратпен жұмыс істей бастады, не істеу керек және қандай кезеңде екені белгілі болды. Басымдықтар әлдеқайда өзекті болды, өйткені оларды қазір әкімші белгілейді.
Чаттар қажет емес. Әрине, әкімші инженерге «мұнда сізге тезірек ауыстыру керек» немесе «кеш болды, оны ауыстыруға уақытыңыз бар ма?» деп жаза алады. Бірақ біз бұдан былай бұл мәселелер бойынша чаттарда күнделікті сөйлеспейміз.
Дискілер топтамамен өзгере бастады. Егер әкімші жұмысқа сәл ертерек келсе, оның бос уақыты бар және әлі ештеңе болмаған жағдайда, ол бірнеше серверлерді ауыстыруға дайындай алады: өрістерді толтырыңыз, дискілерді айналдырудан алып тастаңыз және тапсырманы инженерге тапсырыңыз. Инженер деректер орталығына сәл кейінірек келеді, тапсырманы көреді, қоймадан қажетті дискілерді алып, оларды дереу өзгертеді. Соның нәтижесінде ауыстыру көрсеткіші өсті.
Жұмыс процесін құру кезінде үйренген тәжірибе
- Процедураны құру кезінде әртүрлі көздерден ақпарат жинау керек.
Біздің кейбір әкімшілер инженердің дискілерді өзі ауыстыратынын білмеді. Кейбір адамдар MD RAID-ті инженерлер синхрондауда деп ойлады, бірақ олардың кейбіреулері оған қол жеткізе алмады. Кейбір жетекші инженерлер мұны жасады, бірақ әрқашан емес, өйткені процесс еш жерде сипатталмаған. - Процедура қарапайым және түсінікті болуы керек.
Адамның басында көп қадамдарды сақтау қиын. Жирадағы ең маңызды көрші күйлер негізгі экранда орналасуы керек. Олардың атын өзгертуге болады, мысалы, Орындалуда біз өзгертуге дайын деп атаймыз. Қалған күйлерді ашылмалы мәзірде жасыруға болады, сонда олар көзді ауыртпайды. Бірақ адамдарды шектемей, оларға көшуге мүмкіндік берген дұрыс.
Инновацияның құндылығын түсіндіріңіз. Адамдар түсінгенде, олар жаңа процедураны жақсырақ қабылдайды. Біз үшін адамдардың бүкіл процесті басып емес, оны бақылап отыруы өте маңызды болды. Содан кейін біз осы автоматтандыруға құрдық. - Күтіңіз, талдаңыз, түсініңіз.
Процедураны құруға, техникалық іске асыруға, кездесулер мен талқылауларға бір айға жуық уақыт кетті. Ал жүзеге асыру үшін - үш айдан астам. Адамдардың инновацияны қалай баяу пайдалана бастағанын көрдім. Бастапқы кезеңде келеңсіздіктер көп болды. Бірақ ол процедураның өзінен, оның техникалық орындалуынан толық тәуелсіз болды. Мысалы, бір әкімші Jira емес, Confluence-те Jira плагинін пайдаланды, ал кейбір нәрселер оған қол жетімді болмады. Біз оған Джираны көрсеттік, әкімші жалпы тапсырмаларда да, дискіні ауыстыруда да өнімділікті арттырды.
Дискіні ауыстыруды автоматтандыру
Біз дискілерді ауыстыруды автоматтандыруға бірнеше рет жақындадық. Бізде әзірлемелер, сценарийлер болды, бірақ олардың барлығы интерактивті немесе қолмен режимде жұмыс істеді, олар іске қосуды қажет етті. Ал жаңа процедураны енгізгеннен кейін ғана оның бізге қажет екенін түсіндік.
Енді ауыстыру процесі кезеңдерге бөлінгендіктен, олардың әрқайсысында орындаушы және әрекеттер тізімі бар, біз автоматтандыруды бірден емес, кезең-кезеңімен қоса аламыз. Мысалы, ең қарапайым кезең - Дайын (RAID / деректерді синхрондауды тексеру) ботқа оңай тапсырылуы мүмкін. Бот аздап үйренген кезде, сіз оған неғұрлым жауапты тапсырма бере аласыз - дискіні айналдыруға қою және т.б.
Хайуанаттар бағын орнату
Бот туралы айтпас бұрын, орнату хайуанаттар бағымызға қысқаша шолу жасайық. Бұл, ең алдымен, біздің инфрақұрылымымыздың үлкен көлеміне байланысты. Екіншіден, әрбір қызмет үшін біз оңтайлы аппараттық конфигурацияны таңдауға тырысамыз. Бізде RAID аппараттық құралдарының 20-ға жуық моделі бар, негізінен LSI және Adaptec, бірақ әртүрлі нұсқалардың HP және DELL де бар. Әрбір RAID контроллерінің өзінің басқару утилитасы бар. Әр RAID контроллері үшін пәрмендер жинағы және олардың шығысы нұсқадан нұсқаға қарай әр түрлі болуы мүмкін. HW-RAID пайдаланылмайтын жерде mdraid болуы мүмкін.
Біз барлық дерлік жаңа орнатуларды дискінің артықшылығынсыз жасаймыз. Жүйелердің сақтық көшірмесін серверлер емес, деректер орталықтары деңгейінде жасайтындықтан, біз бұдан былай аппараттық және бағдарламалық RAID пайдалануды тоқтатуға тырысамыз. Бірақ, әрине, қолдауды қажет ететін көптеген ескі серверлер бар.
Бір жерде RAID контроллерлеріндегі дискілер өңделмеген құрылғыларды тастайды, бір жерде JBOD пайдаланылады. Серверде бір жүйелік дискі бар конфигурациялар бар және оны ауыстыру қажет болса, ОЖ мен қолданбаларды орнату арқылы серверді қайта айналдыру керек, сол нұсқалар, содан кейін конфигурация файлдарын қосыңыз, қолданбаларды іске қосыңыз. Сондай-ақ резервтік дискінің ішкі жүйесі деңгейінде емес, тікелей қолданбалардың өзінде жүзеге асырылатын көптеген сервер топтары бар.
Барлығы бізде 400-ге жуық әртүрлі қолданбаларды іске қосатын 100-ден астам бірегей сервер топтары бар. Осындай көптеген опцияларды қамту үшін бізге мүмкіндіктерге бай автоматтандыру құралы қажет болды. Қарапайым DSL-мен жақсырақ, оны жазған адам ғана қолдамайды.
Біз Ansible-ді таңдадық, себебі ол агентсіз: инфрақұрылымды дайындаудың қажеті жоқ, жылдам бастау. Сонымен қатар, ол командада стандарт ретінде қабылданған Python тілінде жазылған.
Бас сызба
Бір оқиғаның мысалын пайдалана отырып, автоматтандырудың жалпы схемасын қарастырайық. Zabbix sdb дискісінің істен шыққанын анықтайды, триггер іске қосылады және Jira-да билет жасалады. Әкімші оған қарап, бұл көшірме емес және жалған позитив емес екенін түсінді, яғни дискіні өзгерту керек және билетті Орындалуда дегенге ауыстырады.
Python тілінде жазылған DiskoBot қосымшасы мезгіл-мезгіл Jira-дан жаңа билеттер үшін сауалнама жүргізеді. Ол жаңа «Орындалуда» билетінің пайда болғанын байқайды, сәйкес ағын іске қосылады, ол Ansible-де ойын кітабын іске қосады (бұл Jira-дағы әрбір күй үшін жасалады). Бұл жағдайда Prepare2change іске қосылады.
Ansible хостқа барады, дискіні айналудан алып тастайды және кері қоңыраулар арқылы бағдарламаға күйді хабарлайды.
Нәтижелердің негізінде бот билетті автоматты түрде өзгертуге дайын күйіне өзгертеді. Инженер хабарлама алады және дискіні өзгертуге барады, содан кейін билетті Өзгертілгенге ауыстырады.
Жоғарыда көрсетілген схемаға сәйкес, билет басқа ойын кітабын іске қосатын, хостқа өтіп, дискіні айналдыруға қоятын ботқа оралады. Бот билетті жабады. Ура!
Енді жүйенің кейбір құрамдас бөліктеріне тоқталайық.
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 файлдары түрінде сақтауға мүмкіндік береді.
Сондай-ақ блоктау құрылғысының атауы, билеттің күйі, сондай-ақ шығару кілті қатты кодталған callback_url *extra_vars* арқылы Ansible-ге жіберіледі - ол 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
Бір типтегі көптеген тапсырмалар сияқты, біз оны жеке жалпы файлға көшірдік және оны ойын кітаптарында үнемі қайталамас үшін қажет болса қосамыз. Бұл жерде кері шақыру_ 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 бөлімнен бөлінген бөлімнің демпін қамтиды.
Инженер жаңа дискіні салған кезде, біз бұл айнымалы мәндерді бөлімнің демпін қалпына келтіру үшін пайдалана аламыз, сондай-ақ дискіні ол жойылған md құрылғыларына аламыз.
Саналы тексеру режимі
Автоматтандыруды қосу қорқынышты болды. Сондықтан біз барлық ойын кітаптарын режимде іске қосуды шештік
, онда Ansible серверлерде ешқандай әрекет жасамайды, тек оларды эмуляциялайды.
Мұндай іске қосу бөлек кері шақыру модулі арқылы іске қосылады және ойын кітабының орындалу нәтижесі Jira-да түсініктеме ретінде сақталады.
Біріншіден, бұл бот пен ойын кітаптарының жұмысын тексеруге мүмкіндік берді. Екіншіден, әкімшілердің ботқа деген сенімін арттырды.
Тексеруден өтіп, Ansible-ді тек құрғақ режимде ғана емес іске қосуға болатынын түсінген кезде, біз Jira-да бірдей айнымалылары бар бір ойын кітабын бір хостта, бірақ қалыпты режимде іске қосу үшін Run Diskobot түймесін жасадық.
Сондай-ақ, түйме бұзылған жағдайда ойын кітабын қайта іске қосу үшін пайдаланылады.
Ойын кітапшаларының құрылымы
Мен Jira билетінің күйіне байланысты бот әртүрлі ойын кітаптарын іске қосатынын айттым.
Біріншіден, кіруді ұйымдастыру әлдеқайда оңай.
Екіншіден, кейбір жағдайларда бұл жай ғана қажет.
Мысалы, жүйелік дискіні ауыстырған кезде алдымен орналастыру жүйесіне өтіп, тапсырма жасау керек және дұрыс орналастырудан кейін сервер ssh арқылы қолжетімді болады және қолданбаны оған айналдыруға болады. Егер біз мұның бәрін бір ойын кітапшасында жасасақ, онда хосттың қолжетімсіздігіне байланысты Ansible оны орындай алмайды.
Біз серверлердің әрбір тобы үшін Ansible рөлдерін қолданамыз. Мұнда сіз олардың бірінде ойын кітапшаларының (лар) қалай ұйымдастырылғанын көре аласыз.
Бұл ыңғайлы, себебі қандай тапсырмалар қай жерде орналасқаны бірден анық болады. Ansible рөлінің кірісі болып табылатын main.yml ішінде біз жай ғана билеттің күйіне немесе барлығына қажет жалпы тапсырмаларды қоса аламыз, мысалы, сәйкестендіруден өту немесе белгіні алу.
тергеу.yml
Тергеу және Ашық күйдегі билеттер үшін іске қосылды. Бұл ойын кітабы үшін ең маңызды нәрсе - блоктық құрылғының атауы. Бұл ақпарат әрқашан қол жетімді емес.
Оны алу үшін біз Jira қорытындысын, Zabbix триггерінің соңғы мәнін талдаймыз. Онда блок құрылғысының атауы болуы мүмкін - сәттілік. Және ол бекіту нүктесін қамтуы мүмкін - содан кейін серверге өтіп, қажетті дискіні талдау және есептеу керек. Сондай-ақ, триггер scsi мекенжайын немесе басқа ақпаратты жібере алады. Бірақ бұл жерде ешқандай анықтамалар жоқ және талдау керек.
Блоктық құрылғының атын білгеннен кейін біз Jira-дағы өрістерді толтыру үшін одан дискінің түрі мен өлшемі туралы ақпаратты жинаймыз. Біз сондай-ақ сатушы, үлгі, микробағдарлама, ID, SMART туралы ақпаратты алып тастаймыз және мұның бәрін Jira билетіндегі түсініктемеге қоямыз. Әкімші мен инженер енді бұл деректерді іздеудің қажеті жоқ. 🙂
Hazır2change.yml
Айналымнан шығару, ауыстыруға дайындық. Ең қиын, жауапты кезең. Бұл жерде қолданбаны тоқтату мүмкін болмаған кезде оны тоқтатуға болады. Немесе көшірмелері жоқ дискіні шығарып алыңыз, осылайша пайдаланушыларға әсер етеді, кейбір деректерді жоғалтады. Мұнда чатта ең көп тексерулер мен хабарландырулар бар.
Ең қарапайым жағдайда біз дискіні HW/MD RAID-тен алып тастау туралы айтып отырмыз.
Неғұрлым күрделі жағдайларда (біздің сақтау жүйелерінде) сақтық көшірме қолданба деңгейінде орындалған кезде, API арқылы қолданбаға өтіп, дискінің шығарылуы туралы хабарлап, оны өшіріп, қалпына келтіруді бастау керек.
Біз қазір жаппай көшіп жатырмыз , ал сервер бұлыңғыр болса, Diskobot бұлттық API интерфейсіне кіріп, ол осы минионмен - контейнерлер жұмыс істейтін сервермен жұмыс істейтінін айтады және «осы минионнан барлық контейнерлерді көшіруді» сұрайды. Сонымен қатар, инженер қайсысын шығару керек екенін бірден көре алатындай етіп дискінің артқы жарығын қосады.
өзгертілді.yml
Дискіні ауыстырғаннан кейін алдымен оның қолжетімділігін тексереміз.
Инженерлер әрқашан жаңа дискілерді орната бермейді, сондықтан біз риза болатын SMART мәндерін тексеруді қостық.
Біз қандай қасиеттерді қарастырамызҚайта бөлінген секторлар саны (5) < 100
Ағымдағы күтудегі сектор саны (107) == 0
Жетек сынақтан өтпесе, инженерге қайта ауыстыру керектігі айтылады. Егер бәрі тәртіпте болса, артқы жарық өшеді, белгілер қолданылады және диск айналдыруға қойылады.
дайын.yml
Ең қарапайым жағдай: HW / SW рейдінің синхрондалуын тексеру немесе қолданбадағы деректерді синхрондаудың аяқталуы.
Қолданбаның API интерфейстері
Мен боттың API қолданбасына жиі кіретінін бірнеше рет айттым. Әрине, барлық өтінімдерде қажетті әдістер болған жоқ, сондықтан оларды пысықтауға тура келді. Міне, біз қолданатын ең маңызды әдістер:
- күй. Кластердің немесе дискінің күйі, онымен жұмыс істеу мүмкіндігін көру;
- бастау/тоқтату. Дискіні белсендіру-ажырату;
- Көшіру/қалпына келтіру. Ауыстыру кезінде және одан кейін деректерді тасымалдау және қалпына келтіру.
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% ауыстыруды автоматтандыруға қол жеткіздік. Жалпы, ауыстыру көрсеткіші екі есеге өсті. Бүгін әкімші тек оқиғаға қарап, дискіні өзгерту немесе өзгерту туралы шешім қабылдайды, содан кейін бір шерту жасайды.
Бірақ қазір біз басқа мәселеге тап болып жатырмыз: кейбір жаңа әкімшілер дискілерді қалай өзгерту керектігін білмейді. 🙂
Ақпарат көзі: www.habr.com