Սկավառակի փոխարինման ավտոմատացում Ansible-ով

Բարեւ բոլորին. Ես աշխատում եմ որպես առաջատար համակարգի ադմինիստրատոր OK-ում և պատասխանատու եմ պորտալի կայուն աշխատանքի համար: Ես ուզում եմ խոսել այն մասին, թե ինչպես մենք ստեղծեցինք սկավառակների ավտոմատ փոխարինման գործընթաց, և այնուհետև ինչպես բացառեցինք ադմինիստրատորին այս գործընթացից և փոխարինեցինք բոտով։

Այս հոդվածը մի տեսակ տառադարձություն է ներկայացումներ HighLoad+ 2018-ում

Սկավառակի փոխարինման գործընթացի կառուցում

Նախ մի քանի թվեր

OK-ը հսկայական ծառայություն է, որն օգտագործվում է միլիոնավոր մարդկանց կողմից: Այն սպասարկվում է մոտ 7 հազար սերվերով, որոնք տեղակայված են 4 տարբեր տվյալների կենտրոններում։ Սերվերները պարունակում են ավելի քան 70 հազար սկավառակ։ Եթե ​​դրանք իրար վրա դրեք, կստանաք ավելի քան 1 կմ բարձրությամբ աշտարակ։

Կոշտ սկավառակները սերվերի բաղադրիչն են, որն ամենից հաճախ ձախողվում է: Նման ծավալներով մենք պետք է շաբաթական մոտ 30 սկավառակ փոխենք, և այս պրոցեդուրան դարձել է ոչ այնքան հաճելի առօրյա։

Միջադեպեր

Մեր ընկերությունը ներկայացրել է միջադեպերի լիարժեք կառավարում։ Մենք գրանցում ենք Ժիրայում տեղի ունեցած յուրաքանչյուր միջադեպ, այնուհետև լուծում և դասավորում ենք այն: Եթե ​​որևէ միջադեպ ազդել է օգտատերերի վրա, ապա մենք անպայման հավաքվում ենք և մտածում, թե ինչպես ավելի արագ արձագանքել նման դեպքերում, ինչպես նվազեցնել ազդեցությունը և, իհարկե, ինչպես կանխել դրա կրկնությունը։

Պահպանման սարքերը բացառություն չեն: Նրանց կարգավիճակը վերահսկվում է Zabbix-ի կողմից: Մենք վերահսկում ենք հաղորդագրությունները Syslog-ում գրելու/ընթերցելու սխալների համար, վերլուծում ենք HW/SW արշավների կարգավիճակը, վերահսկում ենք SMART-ը և հաշվարկում մաշվածությունը SSD-ների համար:

Ինչպես են նախկինում սկավառակները փոխվել

Երբ Զաբբիքսում գործարկվում է, միջադեպ է ստեղծվում Jira-ում և ավտոմատ կերպով նշանակվում է տվյալների կենտրոնների համապատասխան ինժեներներին: Մենք դա անում ենք բոլոր HW միջադեպերի դեպքում, այսինքն՝ նրանց, որոնք պահանջում են որևէ ֆիզիկական աշխատանք տվյալների կենտրոնի սարքավորումների հետ:
Տվյալների կենտրոնի ինժեներն այն մարդն է, ով լուծում է սարքավորումների հետ կապված խնդիրները և պատասխանատու է սերվերների տեղադրման, պահպանման և ապամոնտաժման համար: Ստանալով տոմսը՝ ինժեները անցնում է աշխատանքի։ Սկավառակների դարակներում նա ինքնուրույն փոխում է սկավառակները։ Բայց եթե նրան հասանելի չէ պահանջվող սարքը, ինժեները դիմում է համակարգի հերթապահ ադմինիստրատորների օգնությանը։ Առաջին հերթին, դուք պետք է հեռացնեք սկավառակը ռոտացիայից: Դա անելու համար անհրաժեշտ է սերվերում կատարել անհրաժեշտ փոփոխությունները, դադարեցնել հավելվածները և ապամոնտաժել սկավառակը:

Համակարգի հերթապահ ադմինիստրատորը պատասխանատու է աշխատանքային հերթափոխի ընթացքում ամբողջ պորտալի աշխատանքի համար: Նա հետաքննում է միջադեպերը, վերանորոգում և օգնում մշակողներին կատարել փոքր առաջադրանքներ: Նա միայն կոշտ սկավառակներով չի զբաղվում։

Նախկինում տվյալների կենտրոնի ինժեներները շփվում էին համակարգի ադմինիստրատորի հետ չաթի միջոցով: Ինժեներները Jira-ի տոմսերի հղումներ էին ուղարկում, ադմինիստրատորը հետևում էր դրանց, ինչ-որ նոթատետրում պահում էր աշխատանքի գրանցամատյանը: Բայց չաթերն անհարմար են նման առաջադրանքների համար. այնտեղ տեղեկատվությունը կառուցվածքային չէ և արագ կորչում է: Եվ ադմինիստրատորը կարող էր պարզապես հեռանալ համակարգչից և որոշ ժամանակ չպատասխանել հարցումներին, մինչդեռ ինժեները կանգնած էր սերվերի մոտ սկավառակների կույտով և սպասում էր:

Բայց ամենավատն այն էր, որ ադմինիստրատորները չտեսան ամբողջ պատկերը. սկավառակի ինչ միջադեպեր կային, որտեղ կարող էր խնդիր առաջանալ: Դա պայմանավորված է նրանով, որ մենք HW-ի բոլոր միջադեպերը պատվիրակում ենք ինժեներներին: Այո, հնարավոր էր բոլոր միջադեպերը ցուցադրել ադմինիստրատորի վահանակում: Բայց դրանք շատ են, և ադմինը ներգրավված է եղել միայն որոշների համար։

Բացի այդ, ինժեները չկարողացավ ճիշտ սահմանել առաջնահերթությունները, քանի որ նա ոչինչ չգիտի կոնկրետ սերվերների նպատակի կամ սկավառակների միջև տեղեկատվության բաշխման մասին:

Փոխարինման նոր ընթացակարգ

Առաջին բանը, որ մենք արեցինք, սկավառակի բոլոր միջադեպերը տեղափոխեցինք առանձին տիպի «HW սկավառակ» և դրան ավելացրինք «արգելափակել սարքի անունը», «չափը» և «սկավառակի տեսակը» դաշտերը, որպեսզի այդ տեղեկատվությունը պահվի տոմսի մեջ և պետք չէ անընդհատ փոխանակվել չաթում:

Մենք նաև պայմանավորվեցինք, որ մեկ միջադեպի ժամանակ փոխելու ենք միայն մեկ սկավառակ։ Սա զգալիորեն պարզեցրեց ավտոմատացման գործընթացը, վիճակագրության հավաքագրումը և ապագայում աշխատանքը:

Բացի այդ, մենք ավելացրել ենք «պատասխանատու ադմինիստրատոր» դաշտը։ Այնտեղ ավտոմատ կերպով տեղադրվում է հերթապահ համակարգի ադմինիստրատորը: Սա շատ հարմար է, քանի որ հիմա ինժեները միշտ տեսնում է, թե ով է պատասխանատու։ Կարիք չկա գնալ օրացույց և որոնել: Հենց այս դաշտն էր, որ հնարավորություն տվեց ցուցադրել տոմսեր ադմինիստրատորի վահանակում, որը կարող էր պահանջել նրա օգնությունը:

Ապահովելու համար, որ բոլոր մասնակիցները առավելագույն օգուտներ ստանան նորարարություններից, մենք ստեղծեցինք զտիչներ և վահանակներ և տղաներին պատմեցինք դրանց մասին: Երբ մարդիկ հասկանում են փոփոխությունները, նրանք չեն հեռանում դրանցից՝ որպես ավելորդ բան: Ինժեների համար կարևոր է իմանալ դարակի համարը, որտեղ գտնվում է սերվերը, սկավառակի չափը և տեսակը: Ադմինիստրատորը նախևառաջ պետք է հասկանա, թե ինչպիսի սերվերների խումբ է սա և ինչպիսի ազդեցություն կարող է ունենալ սկավառակը փոխարինելիս:

Դաշտերի առկայությունը և դրանց ցուցադրումը հարմար է, բայց դա մեզ չփրկեց չաթերից օգտվելու անհրաժեշտությունից։ Դա անելու համար մենք պետք է փոխեինք աշխատանքի ընթացքը:

Նախկինում այսպես էր.

Ահա թե ինչպես են ինժեներները շարունակում աշխատել այսօր, երբ ադմինիստրատորի օգնության կարիքը չունեն:

Առաջին բանը, որ մենք արեցինք, նոր կարգավիճակի ներդրումն էր Հետազոտեք. Տոմսը այս կարգավիճակում է, երբ ինժեները դեռ չի որոշել՝ իրեն ադմինիստրատոր պետք կգա՞, թե՞ ոչ։ Այս կարգավիճակի միջոցով ինժեները կարող է տոմսը փոխանցել ադմինիստրատորին։ Բացի այդ, մենք օգտագործում ենք այս կարգավիճակը տոմսերը նշելու համար, երբ սկավառակը պետք է փոխարինվի, բայց սկավառակն ինքնին տեղում չէ: Դա տեղի է ունենում CDN-ների և հեռավոր կայքերի դեպքում:

Ավելացրինք նաև կարգավիճակ Պատրաստ. Տոմսը փոխանցվում է դրան սկավառակը փոխարինելուց հետո։ Այսինքն՝ ամեն ինչ արդեն արված է, բայց HW/SW RAID-ը սինխրոնիզացված է սերվերի վրա։ Սա կարող է բավականին երկար տևել։

Եթե ​​աշխատանքում ներգրավված է ադմինիստրատոր, ապա սխեման մի փոքր ավելի է բարդանում։

Ստատուսից բաց Տոմսը կարող է թարգմանել և՛ համակարգի ադմինիստրատորը, և՛ ինժեները։ Ստատուսում Ընթացքում ադմինիստրատորը հեռացնում է սկավառակը ռոտացիայից, որպեսզի ինժեները կարողանա այն պարզապես դուրս հանել՝ միացնում է հետին լույսը, ապամոնտաժում է սկավառակը, դադարեցնում հավելվածները՝ կախված սերվերների կոնկրետ խմբից:

Այնուհետև տոմսը փոխանցվում է Պատրաստ է փոխվելՍա ազդանշան է ինժեներին, որ սկավառակը կարող է դուրս հանվել: Jira-ի բոլոր դաշտերն արդեն լրացված են, ինժեները գիտի, թե ինչ տեսակի և չափի սկավառակ է։ Այս տվյալները մուտքագրվում են կամ ավտոմատ կերպով նախորդ կարգավիճակում կամ ադմինիստրատորի կողմից:

Սկավառակը փոխարինելուց հետո տոմսի կարգավիճակը փոխվում է փոխվել է. Այն ստուգում է, որ ճիշտ սկավառակը տեղադրված է, բաժանումն արված է, հավելվածը գործարկված է և տվյալների վերականգնման որոշ առաջադրանքներ գործարկված: Տոմսը կարող է փոխանցվել նաև կարգավիճակին Պատրաստ, այս դեպքում ադմինը կմնա պատասխանատու, քանի որ սկավառակը ռոտացիայի է դրել։ Ամբողջական դիագրամն այսպիսի տեսք ունի.

Նոր դաշտերի ավելացումը շատ ավելի հեշտացրեց մեր կյանքը: Տղաները սկսեցին աշխատել կառուցվածքային տեղեկատվության հետ, պարզ դարձավ, թե ինչ է պետք անել և ինչ փուլում։ Առաջնահերթությունները դարձել են շատ ավելի համապատասխան, քանի որ դրանք այժմ սահմանվում են ադմինիստրատորի կողմից:

Չաթերի կարիք չկա։ Իհարկե, ադմինիստրատորը կարող է գրել ինժեներին «սա պետք է ավելի արագ փոխարինվի», կամ «արդեն երեկո է, ժամանակ կունենա՞ք այն փոխարինելու»: Բայց մենք այլևս ամեն օր չենք շփվում այս հարցերի շուրջ չաթերում:

Սկավառակները սկսեցին խմբաքանակով փոխվել։ Եթե ​​ադմինը մի քիչ շուտ է եկել աշխատանքի, ազատ ժամանակ ունի, և դեռ ոչինչ չի եղել, կարող է փոխարինման պատրաստել մի շարք սերվերներ՝ լրացնել դաշտերը, հեռացնել սկավառակները ռոտացիայից և առաջադրանքը փոխանցել ինժեներին։ Ինժեները մի փոքր ուշ գալիս է տվյալների կենտրոն, տեսնում առաջադրանքը, պահեստից վերցնում է անհրաժեշտ դրայվները և անմիջապես փոխարինում դրանք։ Արդյունքում ավելացել է փոխարինման տոկոսադրույքը։

Քաղված դասեր Workflow կառուցելիս

• Ընթացակարգ կառուցելիս անհրաժեշտ է տեղեկատվություն հավաքել տարբեր աղբյուրներից:
  Մեր որոշ ադմինիստրատորներ չգիտեին, որ ինժեները ինքն է փոխում սկավառակները։ Ոմանք կարծում էին, որ MD RAID-ի համաժամացումը կառավարվում է ինժեներների կողմից, թեև նրանցից ոմանք նույնիսկ դա անելու հնարավորություն չունեին: Որոշ առաջատար ինժեներներ դա արեցին, բայց ոչ միշտ, քանի որ գործընթացը ոչ մի տեղ նկարագրված չէր:
• Ընթացակարգը պետք է լինի պարզ և հասկանալի:
  Մարդու համար դժվար է շատ քայլեր մտքում պահել։ Jira-ի ամենակարևոր հարևան կարգավիճակները պետք է տեղադրվեն հիմնական էկրանին: Դուք կարող եք վերանվանել դրանք, օրինակ, մենք կոչում ենք «Ընթացքում պատրաստ է փոխել»: Իսկ այլ ստատուսները կարող են թաքցվել բացվող ընտրացանկում, որպեսզի դրանք աչքաթող չլինեն: Բայց ավելի լավ է մարդկանց չսահմանափակել, նրանց հնարավորություն տալ անցում կատարել։
  Բացատրեք նորարարության արժեքը: Երբ մարդիկ հասկանում են, նրանք ավելի են ընդունում նոր ընթացակարգը: Մեզ համար շատ կարևոր էր, որ մարդիկ ոչ թե սեղմեն ամբողջ գործընթացը, այլ հետևեն դրան։ Այնուհետև մենք դրա վրա կառուցեցինք ավտոմատացում:
• Սպասեք, վերլուծեք, պարզեք:
  Մեզ մոտ մեկ ամիս պահանջվեց ընթացակարգը, տեխնիկական իրականացումը, հանդիպումներն ու քննարկումները կառուցելու համար: Իսկ իրականացումը տեւում է ավելի քան երեք ամիս։ Ես տեսա, թե ինչպես են մարդիկ սկսում կամաց-կամաց օգտագործել նորարարությունը: Վաղ փուլերում նեգատիվը շատ էր: Բայց դա լիովին անկախ էր բուն ընթացակարգից և դրա տեխնիկական իրականացումից: Օրինակ, մի ադմինիստրատոր չի օգտագործել Jira-ն, այլ Jira plugin-ը Confluence-ում, և որոշ բաներ նրան հասանելի չեն եղել: Մենք նրան ցույց տվեցինք Ժիրային, և ադմինիստրատորի արտադրողականությունը բարձրացավ ինչպես ընդհանուր առաջադրանքների, այնպես էլ սկավառակների փոխարինման համար:

Սկավառակի փոխարինման ավտոմատացում

Մենք մի քանի անգամ մոտեցանք սկավառակի փոխարինման ավտոմատացմանը։ Մենք արդեն ունեինք մշակումներ և սցենարներ, բայց դրանք բոլորն աշխատում էին կամ ինտերակտիվ կամ ձեռքով և պահանջում էին գործարկում: Եվ միայն նոր ընթացակարգը ներդնելուց հետո հասկացանք, որ հենց դա է մեզ պակասում։

Քանի որ այժմ մեր փոխարինման գործընթացը բաժանված է փուլերի, որոնցից յուրաքանչյուրն ունի կոնկրետ կատարող և գործողությունների ցանկ, մենք կարող ենք ավտոմատացումը միացնել փուլերով, և ոչ միանգամից: Օրինակ, ամենապարզ փուլը՝ Ready (ստուգում է RAID/տվյալների համաժամացումը) հեշտությամբ կարող է փոխանցվել բոտին: Երբ բոտը փոքր-ինչ սովորել է, կարող եք նրան ավելի կարևոր խնդիր տալ՝ սկավառակը պտտեցնելու և այլն։

Կենդանաբանական այգու կարգավորումներ

Նախքան բոտի մասին խոսելը, եկեք մի կարճ էքսկուրսիա կատարենք մեր կայանների կենդանաբանական այգի: Առաջին հերթին դա պայմանավորված է մեր ենթակառուցվածքների հսկայական չափերով։ Երկրորդ, մենք փորձում ենք ընտրել յուրաքանչյուր ծառայության համար օպտիմալ ապարատային կոնֆիգուրացիան: Մենք ունենք մոտ 20 ապարատային RAID մոդելներ, հիմնականում LSI և Adaptec, բայց կան նաև տարբեր տարբերակների HP և DELL: Յուրաքանչյուր RAID վերահսկիչ ունի կառավարման իր սեփական ծրագիրը: Հրամանների հավաքածուն և դրանց թողարկումը կարող են տարբերվել տարբերակից տարբերակ յուրաքանչյուր RAID կարգավորիչի համար: Այնտեղ, որտեղ HW-RAID-ը չի օգտագործվում, mdraid-ը կարող է օգտագործվել:

Մենք գրեթե բոլոր նոր տեղադրումները կատարում ենք առանց սկավառակի կրկնօրինակում: Մենք փորձում ենք այլևս չօգտագործել ապարատային և ծրագրային RAID, քանի որ մենք կրկնօրինակում ենք մեր համակարգերը տվյալների կենտրոնի մակարդակով, այլ ոչ թե սերվերների: Բայց, իհարկե, կան բազմաթիվ ժառանգական սերվերներ, որոնք պետք է աջակցվեն:

Ինչ-որ տեղ RAID կարգավորիչների սկավառակները տեղափոխվում են հում սարքեր, ինչ-որ տեղ օգտագործվում են JBOD-ներ: Սերվերում կան մեկ համակարգային սկավառակի կոնֆիգուրացիաներ, և եթե այն պետք է փոխարինվի, ապա պետք է վերատեղադրեք սերվերը ՕՀ-ի և նույն տարբերակների հավելվածների տեղադրմամբ, ապա ավելացնեք կոնֆիգուրացիայի ֆայլեր, գործարկեք հավելվածները: Կան նաև բազմաթիվ սերվերային խմբեր, որտեղ կրկնօրինակումն իրականացվում է ոչ թե սկավառակի ենթահամակարգի մակարդակով, այլ անմիջապես հենց հավելվածներում:

Ընդհանուր առմամբ, մենք ունենք ավելի քան 400 եզակի սերվերային խմբեր, որոնք աշխատում են մոտ 100 տարբեր հավելվածներ: Նման հսկայական թվով տարբերակներ լուսաբանելու համար մեզ անհրաժեշտ էր բազմաֆունկցիոնալ ավտոմատացման գործիք: Ցանկալի է պարզ DSL-ով, որպեսզի ոչ միայն գրողը կարողանա աջակցել:

Մենք ընտրեցինք Ansible-ը, քանի որ այն առանց գործակալի. կարիք չկար ենթակառուցվածքների պատրաստման, արագ մեկնարկի: Բացի այդ, գրված է Python-ով, որն ընդունված է որպես ստանդարտ թիմի ներսում։

Ընդհանուր սխեմա

Եկեք նայենք ընդհանուր ավտոմատացման սխեմային՝ օգտագործելով մեկ միջադեպ որպես օրինակ: Zabbix-ը հայտնաբերում է, որ sdb սկավառակը խափանվել է, գործարկիչը լուսավորվում է, և Jira-ում տոմս է ստեղծվում: Ադմինիստրատորը նայեց, հասկացավ, որ դա կրկնօրինակ չէ և կեղծ պոզիտիվ չէ, այսինքն՝ սկավառակը պետք է փոխվի, և տոմսը փոխանցեց «Ընթացքում»:

DiskoBot հավելվածը, որը գրված է Python-ով, պարբերաբար հարցումներ է անցկացնում Ժիրայի նոր տոմսերի համար: Այն նկատում է, որ նոր «Ընթացքում» տոմս է հայտնվել, գործարկվում է համապատասխան շարանը, որը գործարկում է խաղատախտակը Ansible-ում (սա արվում է Jira-ի յուրաքանչյուր կարգավիճակի համար): Այս դեպքում Prepare2change-ը գործարկվում է:

Ansible-ն ուղարկվում է հոսթին, հեռացնում է սկավառակը ռոտացիայից և կարգավիճակի մասին հաղորդում դիմումին Callbacks-ի միջոցով:

Արդյունքների հիման վրա բոտը ավտոմատ կերպով փոխանցում է տոմսը Ready to change-ին։ Ինժեները ծանուցում է ստանում ու գնում սկավառակը փոխելու, որից հետո տոմսը փոխանցում է Changed։

Համաձայն վերը նկարագրված սխեմայի, տոմսը վերադառնում է բոտին, որը գործարկում է մեկ այլ գրքույկ, գնում դեպի հյուրընկալող և սկավառակը դնում է ռոտացիայի մեջ: Բոտը փակում է տոմսը։ Ուռա՜

Այժմ խոսենք համակարգի որոշ բաղադրիչների մասին:

Diskobot

Այս հավելվածը գրված է Python-ով։ Այն ընտրում է տոմսեր Jira-ից ըստ JQL-ի: Կախված տոմսի կարգավիճակից՝ վերջինս գնում է համապատասխան մշակողին, որն էլ իր հերթին գործարկում է կարգավիճակին համապատասխանող 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

Օրինակ՝ Ընթացքի կարգավիճակի տոմսերից ընտրվում են միայն նրանք, որոնցում լրացված են Սկավառակի չափը և Սարքի անվանումը: Սարքի անունը բլոկային սարքի անունն է, որն անհրաժեշտ է խաղագիրքը գործարկելու համար: Սկավառակի չափը անհրաժեշտ է, որպեսզի ինժեները իմանա, թե ինչ չափի սկավառակ է անհրաժեշտ:

Իսկ Ready կարգավիճակ ունեցող տոմսերի մեջ dbot_ignore պիտակով տոմսերը զտված են: Ի դեպ, մենք օգտագործում ենք Jira պիտակները և՛ նման զտման, և՛ կրկնօրինակ տոմսերը նշելու և վիճակագրություն հավաքելու համար։

Եթե ​​խաղագիրքը ձախողվի, Jira-ն վերագրում է dbot_failed պիտակը, որպեսզի այն հնարավոր լինի ավելի ուշ տեսակավորել:

Փոխգործունակություն Ansible-ի հետ

Հավելվածը Ansible-ի հետ հաղորդակցվում է միջոցով Ansible Python API. Playbook_executor-ին մենք փոխանցում ենք ֆայլի անունը և մի շարք փոփոխականներ: Սա թույլ է տալիս Ձեզ պահել Ansible նախագիծը սովորական yml ֆայլերի տեսքով, այլ ոչ թե նկարագրել այն Python կոդով։

Նաև Ansible-ում, *extra_vars*-ի միջոցով, արգելափակման սարքի անվանումը, տոմսի կարգավիճակը, ինչպես նաև callback_url-ը, որը պարունակում է հարցման բանալին. այն օգտագործվում է HTTP-ում հետ կանչելու համար:

Յուրաքանչյուր գործարկման համար ստեղծվում է ժամանակավոր գույքագրում, որը բաղկացած է մեկ հոսթից և այն խմբից, որին պատկանում է այս հոսթը, որպեսզի կիրառվեն group_vars:

Ահա մի առաջադրանքի օրինակ, որն իրականացնում է HTTP հետադարձ զանգ:

Մենք ստանում ենք խաղային գրքույկների կատարման արդյունքը՝ օգտագործելով զանգ(ներ): Դրանք երկու տեսակի են.

• Ansible հետադարձ կապի հավելված, այն տրամադրում է տվյալներ խաղատախտակի կատարման արդյունքների վերաբերյալ։ Այն նկարագրում է առաջադրանքները, որոնք գործարկվել, հաջողությամբ կամ անհաջող ավարտվել են: Այս հետադարձ զանգը կանչվում է, երբ խաղագիրքն ավարտում է նվագարկումը:
• 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-ն պահում է partition dump-ը parted-ից:

Երբ ինժեները տեղադրում է նոր սկավառակ, մենք կարող ենք օգտագործել այս փոփոխականները՝ վերականգնելու միջնորմային աղբանոցը, ինչպես նաև սկավառակը տեղադրելու md սարքերի մեջ, որտեղից այն հեռացվել է:

Անհուսալի ստուգման ռեժիմ

Սարսափելի էր միացնել ավտոմատացումը։ Հետևաբար, մենք որոշեցինք գործարկել բոլոր գրքույկները ռեժիմով
չոր Վազք, որտեղ Ansible-ը ոչ մի գործողություն չի կատարում սերվերների վրա, այլ միայն ընդօրինակում է դրանք։

Նման գործարկումն իրականացվում է առանձին հետադարձ զանգի մոդուլի միջոցով, և խաղատախտակի կատարման արդյունքը պահվում է Jira-ում՝ որպես մեկնաբանություն:

Նախ, դա հնարավորություն տվեց վավերացնել բոտի և խաղային գրքերի աշխատանքը: Երկրորդ, դա մեծացրեց ադմինիստրատորների վստահությունը բոտի նկատմամբ:

Երբ մենք անցանք վավերացումը և հասկացանք, որ դուք կարող եք գործարկել Ansible-ը ոչ միայն չոր գործարկման ռեժիմում, մենք ստեղծեցինք Run Diskobot կոճակը Jira-ում, որպեսզի գործարկենք նույն գրքույկը նույն փոփոխականներով նույն հոսթում, բայց նորմալ ռեժիմով:

Բացի այդ, կոճակը օգտագործվում է խաղագիրքը վերագործարկելու համար, եթե այն խափանվի:

Playbooks կառուցվածքը

Ես արդեն նշել եմ, որ կախված Jira տոմսի կարգավիճակից, բոտը գործարկում է տարբեր playbooks:

Նախ, մուտքը շատ ավելի հեշտ է կազմակերպել:
Երկրորդ, որոշ դեպքերում դա պարզապես անհրաժեշտ է։

Օրինակ, համակարգի սկավառակը փոխարինելիս նախ պետք է գնալ տեղակայման համակարգ, ստեղծել առաջադրանք, և ճիշտ տեղակայումից հետո սերվերը հասանելի կդառնա ssh-ի միջոցով, և դուք կարող եք հավելվածը տարածել դրա վրա: Եթե ​​մենք այս ամենը անեինք մեկ գրքույկում, ապա Ansible-ը չէր կարողանա լրացնել այն, քանի որ հոսթն անհասանելի է:

Մենք օգտագործում ենք Ansible դերեր սերվերների յուրաքանչյուր խմբի համար: Այստեղ դուք կարող եք տեսնել, թե ինչպես են կազմակերպված խաղագիրք(ներ)ը դրանցից մեկում:

Սա հարմար է, քանի որ անմիջապես պարզ է, թե որտեղ են գտնվում առաջադրանքները: main.yml-ում, որը Ansible դերի մուտքագրումն է, մենք կարող ենք պարզապես ներառել ըստ տոմսի կարգավիճակի կամ ընդհանուր առաջադրանքների, որոնք պահանջվում են բոլորի համար, օրինակ՝ փոխանցել նույնականացում կամ ստանալ նշան:

հետաքննություն.yml

Տոմսերի համար վազում է Հետաքննություն և Բաց կարգավիճակ: Այս գրքույկի համար ամենակարևորը սարքի բլոկի անվանումն է: Այս տեղեկատվությունը միշտ չէ, որ հասանելի է:

Այն ստանալու համար մենք վերլուծում ենք Jira-ի ամփոփագիրը՝ վերջին արժեքը Zabbix ձգանից: Այն կարող է պարունակել արգելափակման սարքի անունը՝ lucky: Կամ այն ​​կարող է պարունակել միացման կետ, ապա դուք պետք է գնաք սերվեր, վերլուծեք այն և հաշվարկեք պահանջվող սկավառակը: Գործարկիչը կարող է նաև փոխանցել scsi հասցե կամ այլ տեղեկություններ: Բայց պատահում է նաև, որ թելեր չկան, և պետք է վերլուծել։

Պարզելով արգելափակման սարքի անունը, մենք դրանից տեղեկատվություն ենք հավաքում սկավառակի տեսակի և չափի մասին՝ Jira-ի դաշտերը լրացնելու համար: Մենք նաև հեռացնում ենք վաճառողի, մոդելի, որոնվածի, ID-ի, SMART-ի մասին տեղեկությունները և այս ամենը տեղադրում ենք Jira տոմսի մեկնաբանության մեջ: Ադմինիստրատորն ու ինժեներն այլևս կարիք չունեն որոնել այս տվյալները: 🙂

պատրաստել2change.yml

Սկավառակի պտտումից հեռացնելը, փոխարինման նախապատրաստումը: Ամենադժվար և կարևոր փուլը. Այստեղ դուք կարող եք դադարեցնել հավելվածը, երբ այն չպետք է դադարեցվի: Կամ հանեք սկավառակ, որը չուներ բավարար կրկնօրինակներ, և դրանով իսկ ազդեք օգտվողների վրա՝ կորցնելով որոշ տվյալներ: Այստեղ մենք ունենք ամենաշատ ստուգումները և ծանուցումները չաթում:

Ամենապարզ դեպքում խոսքը HW/MD RAID-ից սկավառակ հեռացնելու մասին է։

Ավելի բարդ իրավիճակներում (մեր պահեստավորման համակարգերում), երբ կրկնօրինակումն իրականացվում է հավելվածի մակարդակով, դուք պետք է գնաք հավելված API-ի միջոցով, զեկուցեք սկավառակի ելքի մասին, ապաակտիվացնեք այն և սկսեք վերականգնումը:

Այժմ մենք զանգվածաբար գաղթում ենք դեպի ամպը, և եթե սերվերը հիմնված է ամպի վրա, ապա Diskobot-ը կանչում է ամպային API-ն, ասում է, որ այն աշխատելու է այս minion-ի հետ՝ աշխատող բեռնարկղերի սերվերի հետ, և խնդրում է «գաղթել բոլոր բեռնարկղերը այս minion-ից»: Եվ միևնույն ժամանակ, միացնում է սկավառակի հետևի լույսը, որպեսզի ինժեները անմիջապես տեսնի, թե որն է պետք հանել:

փոխվել է.yml

Սկավառակը փոխարինելուց հետո մենք նախ ստուգում ենք դրա առկայությունը:

Ինժեներները միշտ չէ, որ տեղադրում են նոր կրիչներ, ուստի մենք ավելացրել ենք ստուգում SMART արժեքների համար, որոնք բավարարում են մեզ:

Ի՞նչ հատկանիշներ ենք մենք նայում:Վերաբաշխված հատվածների թիվը (5) < 100
Ընթացիկ սպասող հատվածի հաշվարկ (107) == 0

Եթե ​​սկավառակը ձախողում է փորձարկումը, ինժեներին ծանուցվում է այն նորից փոխարինելու համար: Եթե ​​ամեն ինչ կարգին է, հետևի լույսն անջատվում է, գծանշումներ են կիրառվում և սկավառակը պտտվում է:

պատրաստ.yml

Ամենապարզ դեպքը՝ ստուգել HW/SW raid-ի համաժամացումը կամ ավարտել տվյալների համաժամացումը հավելվածում:

Հավելվածի API

Ես մի քանի անգամ նշել եմ, որ բոտը հաճախ է մուտք գործում հավելվածների API-ներ: Իհարկե, ոչ բոլոր հավելվածներն ունեին անհրաժեշտ մեթոդներ, ուստի դրանք պետք է փոփոխվեին։ Ահա ամենակարևոր մեթոդները, որոնք մենք օգտագործում ենք.

• Կարգավիճակ. Կլաստերի կամ սկավառակի կարգավիճակ՝ հասկանալու համար, թե արդյոք դրա հետ կարելի է աշխատել.
• Սկսել/դադարեցնել: Սկավառակի ակտիվացում/անջատում;
• Տեղափոխել/վերականգնել։ Տվյալների տեղափոխում և վերականգնում փոխարինման ընթացքում և հետո:

Ansible-ից քաղված դասեր

Ես իսկապես սիրում եմ Անսիբլին: Բայց հաճախ, երբ ես նայում եմ տարբեր opensource նախագծերին և տեսնում, թե ինչպես են մարդիկ գրում գրքույկներ, ես մի փոքր վախենում եմ: Երբ/հանգույցի բարդ տրամաբանական միահյուսումներ, ճկունության բացակայություն և անզորություն՝ կեղևի/հրամանի հաճախակի օգտագործման պատճառով:

Մենք որոշեցինք հնարավորինս պարզեցնել ամեն ինչ՝ օգտվելով 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 ֆայլեր և հսկայական թվով պայմաններ, shell կոդ և հանգույցներ:

Եթե ​​ցանկանում եք կրկնել մեր փորձը Ansible API-ի հետ, հիշեք երկու բան.

• Playbook_executor-ին և playbooks-ին ընդհանրապես չի կարելի ժամանակի վերջ տալ: Ssh նիստի ժամանակ կա ժամանակ, բայց խաղատախտակի վրա ժամանակ չկա: Եթե ​​մենք փորձենք ապամոնտաժել համակարգում այլևս գոյություն չունեցող սկավառակը, խաղագիրքն անվերջ կաշխատի, ուստի մենք ստիպված եղանք դրա գործարկումը փաթաթել առանձին փաթաթանով և սպանել այն ժամանակացույցով:
• Ansible-ն աշխատում է ճեղքված պրոցեսների վրա, ուստի նրա API-ն անվտանգ չէ թելի վրա: Մենք աշխատում ենք մեր բոլոր գրքույկները մեկ թելերով:

Արդյունքում մենք կարողացանք ավտոմատացնել սկավառակների մոտ 80%-ի փոխարինումը։ Ընդհանուր առմամբ, փոխարինման տոկոսադրույքը կրկնապատկվել է: Այսօր ադմինիստրատորը պարզապես նայում է միջադեպին և որոշում՝ սկավառակը պետք է փոխվի, թե ոչ, և հետո մեկ սեղմում է անում։

Բայց հիմա մենք սկսում ենք հանդիպել մեկ այլ խնդրի. որոշ նոր ադմինիստրատորներ չգիտեն, թե ինչպես փոխել սկավառակները: 🙂

Source: www.habr.com