Сайн уу. Би OK-д системийн тэргүүлэх администратороор ажилладаг бөгөөд порталын тогтвортой ажиллагааг хариуцдаг. Бид дискийг автоматаар солих процессыг хэрхэн бүтээсэн, дараа нь администраторыг энэ процессоос хэрхэн хасч, түүнийг роботоор сольсон тухай ярихыг хүсч байна.
Энэ нийтлэл нь нэг төрлийн галиглал юм HighLoad+ 2018 дээр
Диск солих процессыг бий болгох
Эхлээд хэдэн тоо
OK бол сая сая хүмүүсийн ашигладаг аварга үйлчилгээ юм. Энэ нь 7 өөр дата төвд байрладаг 4 мянга орчим серверээр үйлчилдэг. Серверүүд нь 70 мянга гаруй диск агуулдаг. Хэрэв та тэдгээрийг давхарлан байрлуулбал 1 км-ээс дээш өндөртэй цамхаг гарч ирнэ.
Хатуу диск нь ихэвчлэн бүтэлгүйтдэг серверийн бүрэлдэхүүн хэсэг юм. Ийм эзэлхүүнтэй бол бид долоо хоногт 30 орчим диск солих шаардлагатай болдог бөгөөд энэ журам нь тийм ч таатай бус хэвшил болжээ.
Үйл явдал
Манай компани ослын менежментийг бүрэн нэвтрүүлсэн. Бид Жира дахь үйл явдал бүрийг тэмдэглэж, дараа нь шийдэж, цэгцэлдэг. Хэрэв ямар нэгэн үйл явдал хэрэглэгчдэд нөлөөлсөн бол бид хамтдаа цугларч, ийм тохиолдолд хэрхэн хурдан хариу арга хэмжээ авах, үр нөлөөг хэрхэн бууруулах, мэдээжийн хэрэг дахин гарахаас хэрхэн сэргийлэх талаар бодож үздэг.
Хадгалах төхөөрөмжүүд нь үл хамаарах зүйл биш юм. Тэдний статусыг Zabbix хянадаг. Бид Syslog дахь мессежийг бичих/унших алдааг хянаж, HW/SW довтолгооны байдалд дүн шинжилгээ хийж, SMART-д хяналт тавьж, SSD-ийн элэгдлийг тооцдог.
Өмнө нь дискийг хэрхэн өөрчилсөн
Zabbix-д гох тохиолдох үед 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 диск бүтэлгүйтсэнийг илрүүлж, гох асаж, Jira-д тасалбар үүсгэсэн. Администратор үүнийг хараад, энэ нь давхардсан биш, худал эерэг биш, өөрөөр хэлбэл дискийг өөрчлөх шаардлагатай байгааг ойлгож, тасалбарыг "Явц" руу шилжүүлэв.
Python хэл дээр бичигдсэн DiskoBot програм нь Жирагаас шинэ тасалбар авахын тулд үе үе санал асуулга явуулдаг. Энэ нь "Явцаагүй" гэсэн шинэ тасалбар гарч ирэн, харгалзах утсыг ажиллуулж, Ansible дээр тоглуулах номыг ажиллуулж байгааг анзаарав (энэ нь Jira дахь статус бүрийн хувьд хийгддэг). Энэ тохиолдолд Prepare2change-г эхлүүлнэ.
Ansible нь хост руу илгээгдэж, дискийг эргүүлэхээс зайлуулж, дуудлагын тусламжтайгаар програмын статусыг мэдээлдэг.
Үр дүнд үндэслэн бот тасалбарыг өөрчлөхөд бэлэн рүү автоматаар шилжүүлдэг. Инженер мэдэгдэл хүлээн аваад дискээ солихоор явж, дараа нь тасалбарыг Өөрчлөгдсөн рүү шилжүүлнэ.
Дээр дурдсан схемийн дагуу тасалбар нь өөр тоглоомын номыг ажиллуулж, хост руу очиж, дискийг эргүүлэх горимд оруулдаг bot руу буцаж очдог. Бот тасалбарыг хаадаг. Өө!
Одоо системийн зарим бүрэлдэхүүн хэсгүүдийн талаар ярилцъя.
Дискобот
Энэ програмыг Python дээр бичсэн. Энэ нь 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
Жишээлбэл, "Явц" төлөвт байгаа тасалбаруудаас зөвхөн Дискний хэмжээ болон Төхөөрөмжийн нэрийн талбарыг бөглөсөн тасалбаруудыг сонгоно. Төхөөрөмжийн нэр нь тоглоомын номыг гүйцэтгэхэд шаардлагатай блок төхөөрөмжийн нэр юм. Дискний хэмжээ шаардлагатай бөгөөд ингэснээр инженер ямар хэмжээтэй диск хэрэгтэйг мэддэг.
Бэлэн статустай тасалбаруудын дунд dbot_ignore шошготой тасалбаруудыг шүүдэг. Дашрамд хэлэхэд, бид Jira шошгыг ийм шүүлтүүр, давхардсан тасалбарыг тэмдэглэх, статистик цуглуулахад ашигладаг.
Хэрэв тоглоомын ном бүтэлгүйтвэл Жира дараа нь цэгцлэхийн тулд dbot_failed шошгыг оноож өгдөг.
Ansible-тай хамтран ажиллах чадвар
Уг програм нь Ansible-тай дамжуулан холбогддог . Playbook_executor руу бид файлын нэр болон хувьсагчийн багцыг дамжуулдаг. Энэ нь Ansible төслийг Python кодоор тайлбарлахын оронд ердийн yml файл хэлбэрээр хадгалах боломжийг танд олгоно.
Мөн Ansible-д *extra_vars*-ээр дамжуулан блоклох төхөөрөмжийн нэр, тасалбарын статус, мөн асуудлын түлхүүрийг агуулсан callback_url - энэ нь HTTP дээр буцааж залгахад хэрэглэгддэг.
Ажиллуулах бүрт нэг хост болон энэ хост хамаарах бүлгээс бүрдсэн түр бүртгэл үүсгэгддэг бөгөөд ингэснээр group_vars-г ашигладаг.
HTTP буцаан дуудлагыг хэрэгжүүлдэг даалгаврын жишээ энд байна.
Бид callaback(s) ашиглан тоглоомын номыг гүйцэтгэсний үр дүнг авдаг. Тэд хоёр төрөлтэй:
- , энэ нь тоглоомын номын гүйцэтгэлийн үр дүнгийн талаархи мэдээллийг өгдөг. Энэ нь эхлүүлсэн, амжилттай эсвэл бүтэлгүйтсэн ажлуудыг тайлбарладаг. Тоглуулах ном тоглуулж дуусахад энэ дуудлагыг дуудна.
- Тоглуулах номыг тоглуулж байх үед мэдээлэл хүлээн авахын тулд 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
Энэ даалгавар нь Жира тасалбарыг "Өөрчлөхөд бэлэн" төлөв рүү шилжүүлж, тайлбар нэмнэ. Мөн mdam_data хувьсагч нь дискийг устгасан md төхөөрөмжүүдийн жагсаалтыг, parted_info нь parted-аас хуваалтын дампыг хадгалдаг.
Инженер шинэ диск оруулах үед бид эдгээр хувьсагчдыг ашиглан хуваалтын дампыг сэргээхээс гадна дискийг устгасан md төхөөрөмжид оруулах боломжтой.
Ухаалаг шалгах горим
Автоматжуулалтыг асаахад аймшигтай байсан. Тиймээс бид бүх тоглоомын номыг горимд ажиллуулахаар шийдсэн
, үүнд Ansible нь серверүүд дээр ямар ч үйлдэл хийдэггүй, зөвхөн тэдгээрийг дуурайдаг.
Ийм хөөргөлтийг тусдаа дуудлагын модулиар ажиллуулдаг бөгөөд тоглуулах номын гүйцэтгэлийн үр дүнг тайлбар болгон Жира дээр хадгалдаг.
Нэгдүгээрт, энэ нь bot болон тоглоомын дэвтрийн ажлыг баталгаажуулах боломжтой болсон. Хоёрдугаарт, энэ нь администраторуудын роботод итгэх итгэлийг нэмэгдүүлсэн.
Баталгаажуулалтыг давж, та Ansible-г зөвхөн хуурай горимд ажиллуулж болно гэдгийг ойлгосон үед бид Жира дээр Run Diskobot товчийг хийж, ижил хост дээр ижил хувьсагчтай, гэхдээ ердийн горимд ижил тоглоомын номыг ажиллуулсан.
Нэмж дурдахад энэ товчлуур нь тоглоомын ном эвдэрсэн тохиолдолд дахин эхлүүлэхэд ашиглагддаг.
Тоглоомын номын бүтэц
Жира тасалбарын статусаас хамааран бот өөр өөр тоглоомын номуудыг ажиллуулдаг гэдгийг би аль хэдийн дурдсан.
Нэгдүгээрт, орох хаалгыг зохион байгуулах нь илүү хялбар байдаг.
Хоёрдугаарт, зарим тохиолдолд энэ нь зүгээр л шаардлагатай байдаг.
Жишээлбэл, системийн дискийг солихдоо та эхлээд байршуулах систем рүү очиж, даалгавар үүсгэх хэрэгтэй бөгөөд зөв байршуулсны дараа сервер ssh-ээр дамжуулан хандах боломжтой болох бөгөөд та програмыг түүн дээр байрлуулж болно. Хэрэв бид энэ бүгдийг нэг тоглоомын дэвтэрт хийсэн бол Ansible хост ажиллахгүй байгаа тул үүнийг дуусгах боломжгүй болно.
Бид серверийн бүлэг бүрт Ansible үүргийг ашигладаг. Эндээс та тэдгээрийн аль нэгэнд тоглоомын дэвтэр (үүд) хэрхэн зохион байгуулагдсаныг харж болно.
Энэ нь тохиромжтой, учир нь аль ажил хаана байрладаг нь шууд тодорхой болно. Ansible дүрд зориулсан оролт болох main.yml-д бид зүгээр л тасалбарын статус эсвэл хүн бүрт шаардлагатай ерөнхий даалгавруудыг, тухайлбал таних тэмдэг дамжуулах, жетон хүлээн авах зэргээр оруулж болно.
мөрдөн байцаалт.yml
Мөрдөн байцаалтын болон нээлттэй төлөвт байгаа тасалбарын төлөө ажилладаг. Энэ тоглоомын номын хамгийн чухал зүйл бол блок төхөөрөмжийн нэр юм. Энэ мэдээлэл үргэлж байдаггүй.
Үүнийг олж авахын тулд бид Zabbix триггерийн сүүлчийн утга болох Jira хураангуйд дүн шинжилгээ хийнэ. Энэ нь блок төхөөрөмжийн нэрийг агуулж болно - азтай. Эсвэл энэ нь холбох цэг агуулсан байж магадгүй, дараа нь та сервер рүү очиж, задлан шинжилж, шаардлагатай дискийг тооцоолох хэрэгтэй. Триггер нь scsi хаяг эсвэл бусад мэдээллийг дамжуулж болно. Гэхдээ ямар ч сэжүүр байхгүй тул дүн шинжилгээ хийх хэрэгтэй болдог.
Блок төхөөрөмжийн нэрийг олж мэдээд бид Жира дахь талбаруудыг бөглөхийн тулд дискний төрөл, хэмжээсийн талаархи мэдээллийг цуглуулдаг. Бид мөн борлуулагч, загвар, програм хангамж, ID, SMART-ийн талаарх мэдээллийг устгаж, Jira тасалбарын тайлбарт энэ бүгдийг оруулдаг. Администратор болон инженер энэ өгөгдлийг хайх шаардлагагүй болсон. 🙂
бэлтгэх2change.yml
Дискийг эргүүлэхээс салгаж, солиход бэлтгэж байна. Хамгийн хэцүү, чухал үе шат. Эндээс та програмыг зогсоох шаардлагагүй үед зогсоож болно. Эсвэл хангалттай хуулбаргүй дискийг гаргаж, улмаар хэрэглэгчдэд нөлөөлж, зарим өгөгдлийг алддаг. Энд бид чат дахь хамгийн олон шалгалт, мэдэгдэлтэй байна.
Хамгийн энгийн тохиолдолд бид HW/MD RAID-ээс дискийг устгах тухай ярьж байна.
Илүү төвөгтэй нөхцөлд (манай хадгалах системд) нөөцлөлтийг програмын түвшинд гүйцэтгэх үед та API-ээр дамжуулан програм руу очиж, дискний гаралтыг мэдээлэх, идэвхгүй болгож, сэргээх ажиллагааг эхлүүлэх хэрэгтэй.
Бид одоо бөөнөөрөө нүүж байна , хэрэв сервер нь үүлд суурилсан бол Diskobot үүлэн API-г дуудаж, энэ минион буюу контейнер ажиллуулж байгаа сервертэй ажиллах болно гэж хэлээд "энэ минионоос бүх контейнерийг шилжүүлэх" гэж асууна. Үүний зэрэгцээ дискний арын гэрлийг асааснаар инженер алийг нь татах шаардлагатайг шууд харах боломжтой болно.
өөрчлөгдсөн.yml
Дискийг сольсны дараа бид эхлээд түүний бэлэн байдлыг шалгана.
Инженерүүд үргэлж шинэ хөтчүүдийг суулгадаггүй тул бид сэтгэл хангалуун байгаа SMART утгыг шалгасан.
Бид ямар шинж чанаруудыг харж байна вэ?Дахин хуваарилагдсан салбаруудын тоо (5) < 100
Одоогийн хүлээгдэж буй салбарын тоо (107) == 0
Хэрэв хөтөч шалгалтанд тэнцээгүй бол түүнийг дахин солихыг инженерт мэдэгдэнэ. Хэрэв бүх зүйл эмх цэгцтэй байвал арын гэрэлтүүлэг унтарч, тэмдэглэгээ хийж, дискийг эргүүлнэ.
бэлэн.yml
Хамгийн энгийн тохиолдол: HW/SW raid синхрончлолыг шалгах эсвэл программ дахь өгөгдлийн синхрончлолыг дуусгах.
Хэрэглээний 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 нь thread-д аюулгүй биш юм. Бид бүх тоглоомын номоо нэг урсгалтай ажиллуулдаг.
Үүний үр дүнд бид дискний 80 орчим хувийг автоматаар солих боломжтой болсон. Ерөнхийдөө солих хувь хэмжээ хоёр дахин нэмэгдсэн. Өнөөдөр администратор зүгээр л болсон явдлыг хараад дискийг өөрчлөх шаардлагатай эсэхийг шийдээд дараа нь нэг товшилт хийдэг.
Гэхдээ одоо бид өөр асуудалтай тулгараад байна: зарим шинэ администраторууд хөтчүүдийг хэрхэн өөрчлөхөө мэдэхгүй байна. 🙂
Эх сурвалж: www.habr.com