Hamıya salam. Mən OK-da aparıcı sistem administratoru kimi çalışıram və portalın stabil işləməsinə cavabdehəm. Disklərin avtomatik dəyişdirilməsi prosesini necə qurduğumuz və sonra administratoru bu prosesdən necə kənarlaşdırıb onu botla əvəz etdiyimiz barədə danışmaq istəyirəm.
Bu məqalə bir növ transliterasiyadır HighLoad+ 2018-də
Disk dəyişdirmə prosesinin qurulması
Əvvəlcə bəzi rəqəmlər
OK milyonlarla insanın istifadə etdiyi nəhəng xidmətdir. Ona 7 müxtəlif məlumat mərkəzində yerləşən 4 minə yaxın server xidmət göstərir. Serverlərdə 70 mindən çox disk var. Onları üst-üstə yığsanız, hündürlüyü 1 km-dən çox olan bir qüllə alırsınız.
Sərt disklər ən çox uğursuz olan server komponentidir. Bu cür həcmlərlə həftədə təxminən 30 disk dəyişdirməliyik və bu prosedur çox xoş olmayan bir işə çevrildi.
Hadisələr
Şirkətimiz insidentlərin tam idarə edilməsini tətbiq etmişdir. Biz Jira-da hər bir hadisəni qeydə alırıq, sonra onu həll edirik və sıralayırıq. Əgər hansısa hadisə istifadəçilərə təsir edibsə, o zaman biz mütləq bir araya gəlib belə hallarda necə daha tez reaksiya verməli, effekti necə azaltmalı və təbii ki, təkrarlanmanın qarşısını necə alacağımızı düşünürük.
Saxlama cihazları istisna deyil. Onların statusuna Zabbix nəzarət edir. Biz Syslog-da yazı/oxu xətaları üçün mesajları izləyirik, HW/SW reydlərinin vəziyyətini təhlil edirik, SMART-a nəzarət edirik və SSD-lərin aşınmasını hesablayırıq.
Əvvəllər disklər necə dəyişdirilib
Zabbix-də tetikleyici baş verdikdə, Jira-da insident yaradılır və avtomatik olaraq məlumat mərkəzlərində müvafiq mühəndislərə təyin edilir. Biz bunu bütün HW insidentləri ilə, yəni məlumat mərkəzində avadanlıqla hər hansı fiziki iş tələb edən hadisələrlə edirik.
Məlumat mərkəzi mühəndisi hardware ilə bağlı məsələləri həll edən və serverlərin quraşdırılması, saxlanması və sökülməsinə cavabdeh olan şəxsdir. Bileti aldıqdan sonra mühəndis işə başlayır. Disk rəflərində diskləri müstəqil olaraq dəyişir. Amma tələb olunan qurğuya çıxışı yoxdursa, mühəndis yardım üçün növbətçi sistem administratorlarına müraciət edir. İlk növbədə, diski fırlanmadan çıxarmaq lazımdır. Bunun üçün serverdə lazımi dəyişiklikləri etməli, proqramları dayandırmalı və diski ayırmalısınız.
Növbətçi sistem inzibatçısı iş növbəsi ərzində bütün portalın işinə cavabdehdir. O, hadisələri araşdırır, təmir edir və tərtibatçılara kiçik tapşırıqları yerinə yetirməyə kömək edir. O, təkcə sərt disklərlə məşğul olmur.
Əvvəllər məlumat mərkəzi mühəndisləri sistem administratoru ilə çat vasitəsilə əlaqə saxlayırdılar. Mühəndislər Jira biletlərinə bağlantılar göndərdilər, administrator onları izlədi, bəzi notepadda iş jurnalını saxladı. Lakin söhbətlər belə tapşırıqlar üçün əlverişsizdir: oradakı məlumatlar strukturlaşdırılmayıb və tez itirilir. Və administrator sadəcə olaraq kompüterdən uzaqlaşa bilər və bir müddət sorğulara cavab verməyə bilər, mühəndis isə serverdə bir yığın disklə dayanıb gözləyirdi.
Ancaq ən pisi o idi ki, idarəçilər bütün mənzərəni görmürdülər: hansı disk insidentləri var, harada problem yarana bilər. Bu, bütün HW hadisələrini mühəndislərə həvalə etməyimizlə bağlıdır. Bəli, administratorun idarə panelində bütün hadisələri göstərmək mümkün idi. Ancaq bunlar çoxdur və administrator yalnız bəziləri üçün cəlb edilmişdir.
Bundan əlavə, mühəndis prioritetləri düzgün təyin edə bilmədi, çünki o, konkret serverlərin məqsədi və ya disklər arasında məlumatın paylanması haqqında heç nə bilmir.
Yeni dəyişdirmə proseduru
Etdiyimiz ilk şey bütün disk insidentlərini ayrıca bir növ “HW disk”ə köçürmək və ona “blok cihaz adı”, “ölçüsü” və “disk növü” sahələrini əlavə etmək oldu ki, bu məlumat biletdə saxlansın və Çatda daim mübadilə etmək lazım deyil.
Biz də razılaşdıq ki, bir hadisə zamanı yalnız bir diski dəyişəcəyik. Bu, avtomatlaşdırma prosesini, statistik məlumatların toplanması və gələcəkdə işi əhəmiyyətli dərəcədə sadələşdirdi.
Bundan əlavə, "məsul administrator" sahəsini əlavə etdik. Növbətçi sistem administratoru avtomatik olaraq ora daxil edilir. Bu çox rahatdır, çünki indi mühəndis kimin məsuliyyət daşıdığını həmişə görür. Təqvimə girib axtarışa ehtiyac yoxdur. Məhz bu sahə idarəçinin tablosunda onun köməyi tələb oluna bilən biletləri göstərməyə imkan verdi.
Bütün iştirakçıların yeniliklərdən maksimum fayda əldə etmələrini təmin etmək üçün biz filtrlər və tablolar yaratdıq və uşaqlara onlar haqqında danışdıq. İnsanlar dəyişiklikləri başa düşdükdə, lazımsız bir şey kimi onlardan uzaqlaşmırlar. Mühəndis üçün serverin yerləşdiyi rack nömrəsini, diskin ölçüsünü və növünü bilməsi vacibdir. Administrator, ilk növbədə, bunun hansı növ serverlər qrupu olduğunu və diski dəyişdirərkən hansı təsirin ola biləcəyini başa düşməlidir.
Sahələrin olması və onların göstərilməsi rahatdır, lakin bu, bizi söhbətlərdən istifadə ehtiyacından xilas etmədi. Bunun üçün iş prosesini dəyişməli olduq.
Əvvəllər belə idi:
Mühəndislər bu gün administrator köməyinə ehtiyac duymadıqları zaman işləməyə davam edirlər.
Etdiyimiz ilk iş yeni status təqdim etmək oldu Araşdırın. Mühəndis inzibatçıya ehtiyacı olub-olmayacağına hələ qərar vermədiyi zaman bilet bu statusda olur. Bu status vasitəsilə mühəndis bileti idarəçiyə ötürə bilər. Bundan əlavə, biz bu statusdan diskin dəyişdirilməsi lazım olduqda biletləri qeyd etmək üçün istifadə edirik, lakin diskin özü saytda deyil. Bu, CDN və uzaq saytlarda baş verir.
Biz də status əlavə etdik Hazır. Disk dəyişdirildikdən sonra bilet ona köçürülür. Yəni hər şey artıq edilib, lakin HW/SW RAID serverdə sinxronlaşdırılıb. Bu kifayət qədər uzun müddət çəkə bilər.
Əgər işə bir idarəçi cəlb olunarsa, sxem bir az daha mürəkkəbləşir.
Statusdan açıq Bilet həm sistem inzibatçısı, həm də mühəndis tərəfindən tərcümə oluna bilər. Vəziyyətdə Davam edir administrator diski fırlanmadan çıxarır ki, mühəndis sadəcə onu çıxara bilsin: arxa işığı yandırır, diski ayırır, xüsusi server qrupundan asılı olaraq proqramları dayandırır.
Bundan sonra bilet köçürülür Dəyişməyə hazırdır: Bu, mühəndisə diskin çıxarıla biləcəyinə dair bir siqnaldır. Jira-da bütün sahələr artıq doldurulmuşdur, mühəndis diskin hansı növü və ölçüsünü bilir. Bu məlumatlar ya avtomatik olaraq əvvəlki statusda, ya da administrator tərəfindən daxil edilir.
Disk dəyişdirildikdən sonra bilet statusu olaraq dəyişdirilir dəyişdi. O, düzgün diskin daxil edildiyini, bölmələrin aparıldığını, proqramın işə salındığını və bəzi məlumatların bərpası tapşırıqlarının işə salındığını yoxlayır. Bilet statusa da köçürülə bilər Hazır, bu halda administrator məsuliyyətdə qalacaq, çünki diski fırlanma vəziyyətinə qoydu. Tam diaqram bu kimi görünür.
Yeni sahələrin əlavə edilməsi həyatımızı xeyli asanlaşdırdı. Uşaqlar strukturlaşdırılmış məlumatlarla işləməyə başladılar, nə etmək lazım olduğu və hansı mərhələdə olduğu aydın oldu. Prioritetlər indi administrator tərəfindən təyin olunduğundan daha çox aktuallaşıb.
Çatlara ehtiyac yoxdur. Təbii ki, administrator mühəndisə “bunu daha tez dəyişdirmək lazımdır” və ya “artıq axşamdır, əvəz etməyə vaxtınız olacaqmı?” deyə yaza bilər. Amma biz artıq bu məsələlərlə bağlı hər gün söhbət etmirik.
Disklər qrup halında dəyişdirilməyə başlandı. Administrator işə bir az tez gəlibsə, onun boş vaxtı var və hələ heç nə baş verməyibsə, o, bir sıra serverləri dəyişdirmək üçün hazırlaya bilər: sahələri doldurun, diskləri fırlanmadan çıxarın və tapşırığı mühəndisə köçürün. Mühəndis bir az sonra məlumat mərkəzinə gəlir, tapşırığı görür, lazımi diskləri anbardan götürür və dərhal dəyişdirir. Nəticədə əvəzetmə nisbəti artıb.
İş axını qurarkən öyrənilən dərslər
- Prosedur qurarkən müxtəlif mənbələrdən məlumat toplamaq lazımdır.
Bizim bəzi idarəçilər bilmirdilər ki, mühəndis diskləri özü dəyişir. Bəzi insanlar MD RAID sinxronizasiyasının mühəndislər tərəfindən idarə olunduğunu düşünürdülər, baxmayaraq ki, bəzilərinin bunu etmək imkanı belə yoxdur. Bəzi aparıcı mühəndislər bunu etdilər, lakin həmişə deyil, çünki proses heç bir yerdə təsvir edilməmişdir. - Prosedur sadə və başa düşülən olmalıdır.
Bir çox addımları ağlında saxlamaq insan üçün çətindir. Jira-da ən vacib qonşu statuslar əsas ekranda yerləşdirilməlidir. Siz onların adını dəyişdirə bilərsiniz, məsələn, biz “Dəyişdirməyə hazırıq” deyirik. Digər statuslar isə açılan menyuda gizlədilə bilər ki, göz yormasın. Ancaq insanları məhdudlaşdırmamaq, onlara keçid etmək imkanı vermək daha yaxşıdır.
Yeniliyin dəyərini izah edin. İnsanlar başa düşəndə yeni proseduru daha çox qəbul edirlər. Bizim üçün çox vacib idi ki, insanlar bütün prosesi klikləməsinlər, amma ona əməl etsinlər. Sonra bunun üzərində avtomatlaşdırma qurduq. - Gözləyin, təhlil edin, anlayın.
Prosedurun qurulması, texniki icrası, görüşləri və müzakirələri bizə təxminən bir ay çəkdi. Və həyata keçirilməsi üç aydan çox vaxt aparır. İnsanların yavaş-yavaş yenilikdən necə istifadə etməyə başladığını gördüm. İlkin mərhələdə çoxlu neqativlik var idi. Lakin o, prosedurun özündən və onun texniki icrasından tamamilə müstəqil idi. Məsələn, bir idarəçi Jiradan istifadə etmədi, lakin Confluence-də Jira plaginindən istifadə etdi və bəzi şeylər onun üçün mövcud deyildi. Biz ona Jiranı göstərdik və adminin məhsuldarlığı həm ümumi tapşırıqlar, həm də disklərin dəyişdirilməsi üçün artdı.
Diskin dəyişdirilməsinin avtomatlaşdırılması
Bir neçə dəfə diskin dəyişdirilməsinin avtomatlaşdırılmasına yaxınlaşdıq. Artıq inkişaflarımız və skriptlərimiz var idi, lakin onların hamısı ya interaktiv, ya da əl ilə işləyirdi və işə salınmağı tələb edirdi. Və yalnız yeni proseduru tətbiq etdikdən sonra anladıq ki, bizdə çatışmayan budur.
İndi dəyişdirmə prosesimiz mərhələlərə bölündüyündən, hər birinin müəyyən bir icraçısı və hərəkətlər siyahısı var, biz avtomatlaşdırmanı bir anda deyil, mərhələlərlə aktivləşdirə bilərik. Məsələn, ən sadə mərhələ - Hazır (RAID/məlumat sinxronizasiyasının yoxlanılması) bota asanlıqla həvalə edilə bilər. Bot bir az öyrəndikdə, ona daha vacib bir tapşırıq verə bilərsiniz - diskin fırlanma vəziyyətinə salınması və s.
Zoopark qurğuları
Bot haqqında danışmazdan əvvəl instalyasiya zooparkımıza qısa bir ekskursiya edək. Bu, ilk növbədə, infrastrukturumuzun nəhəng ölçüsü ilə bağlıdır. İkincisi, hər bir xidmət üçün optimal aparat konfiqurasiyasını seçməyə çalışırıq. Bizdə 20-yə yaxın aparat RAID modelimiz var, əsasən LSI və Adaptec, lakin müxtəlif versiyaların HP və DELL də var. Hər bir RAID nəzarətçisinin öz idarəetmə proqramı var. Əmrlər dəsti və onların verilməsi hər bir RAID nəzarətçisi üçün versiyadan versiyaya fərqli ola bilər. HW-RAID istifadə edilmədikdə, mdraid istifadə edilə bilər.
Demək olar ki, bütün yeni quraşdırmaları disk ehtiyat nüsxəsi olmadan edirik. Sistemlərimizin ehtiyat nüsxəsini serverlərdə deyil, məlumat mərkəzi səviyyəsində apardığımız üçün RAID-dən artıq hardware və proqram təminatından istifadə etməyə çalışırıq. Ancaq əlbəttə ki, dəstəklənməsi lazım olan bir çox köhnə serverlər var.
Haradasa RAID kontrollerlərindəki disklər xam cihazlara ötürülür, haradasa JBOD-lar istifadə olunur. Serverdə bir sistem diski olan konfiqurasiyalar var və onu dəyişdirmək lazımdırsa, serveri OS və eyni versiyaların tətbiqləri ilə yenidən quraşdırmalı, sonra konfiqurasiya faylları əlavə etməli, proqramları işə salmalısınız. Yedəkləmənin disk alt sistemi səviyyəsində deyil, birbaşa tətbiqlərin özlərində aparıldığı bir çox server qrupları da var.
Ümumilikdə, 400-ə yaxın müxtəlif proqramları işlədən 100-dən çox unikal server qrupumuz var. Bu qədər çox sayda variantı əhatə etmək üçün bizə çoxfunksiyalı avtomatlaşdırma vasitəsi lazım idi. Tercihen sadə DSL ilə, belə ki, yalnız onu yazan şəxs dəstəkləyə bilməz.
Biz Ansible-ı seçdik, çünki o, agentsizdir: infrastruktur hazırlamağa ehtiyac yox idi, sürətli başlanğıc. Bundan əlavə, komanda daxilində standart olaraq qəbul edilən Python dilində yazılıb.
Ümumi sxem
Nümunə olaraq bir hadisədən istifadə edərək ümumi avtomatlaşdırma sxeminə baxaq. Zabbix sdb diskinin sıradan çıxdığını aşkar edir, trigger yanır və Jira-da bilet yaradılır. Administrator ona baxdı, bunun dublikat olmadığını və yalan pozitiv olmadığını, yəni diskin dəyişdirilməsinə ehtiyac olduğunu başa düşdü və bileti Davam edənə köçürdü.
Python dilində yazılmış DiskoBot tətbiqi vaxtaşırı Jira-dan yeni biletlər üçün sorğu keçirir. O, yeni Davam etməkdə olan biletin göründüyünü, Ansible-da oyun kitabını işə salan müvafiq mövzunun işə salındığını bildirir (bu, Jira-da hər bir status üçün edilir). Bu halda, Prepare2change işə salınır.
Ansible hosta göndərilir, diski fırlanmadan çıxarır və geri çağırışlar vasitəsilə statusu proqrama bildirir.
Nəticələrə əsasən, bot avtomatik olaraq bileti Dəyişməyə hazır vəziyyətinə köçürür. Mühəndis bildiriş alır və diski dəyişdirməyə gedir, bundan sonra bileti Dəyişdirildi-yə köçürür.
Yuxarıda təsvir edilən sxemə görə, bilet başqa bir oyun kitabını işə salan, hosta gedir və diski fırlanma vəziyyətinə qoyan bota qayıdır. Bot bileti bağlayır. Yaşasın!
İndi sistemin bəzi komponentləri haqqında danışaq.
Diskobot
Bu proqram Python dilində yazılmışdır. O, JQL-ə uyğun olaraq Jira-dan biletləri seçir. Biletin statusundan asılı olaraq, sonuncu müvafiq idarəçiyə gedir, o da öz növbəsində statusa uyğun olan Ansible oyun kitabını işə salır.
JQL və sorğu intervalları proqram konfiqurasiya faylında müəyyən edilir.
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
Məsələn, Davam edir statusunda olan biletlər arasında yalnız Disk ölçüsü və Cihaz adı sahələri doldurulmuş olanlar seçilir. Cihazın adı oyun kitabını yerinə yetirmək üçün lazım olan blok cihazının adıdır. Mühəndisin hansı ölçülü diskin lazım olduğunu bilməsi üçün disk ölçüsü lazımdır.
Hazır statuslu biletlər arasında dbot_ignore etiketli biletlər süzülür. Yeri gəlmişkən, biz Jira etiketlərindən həm bu cür filtrasiya, həm də dublikat biletləri qeyd etmək və statistika toplamaq üçün istifadə edirik.
Oyun kitabı uğursuz olarsa, Jira dbot_failed etiketini təyin edir ki, o, sonradan sıralana bilsin.
Ansible ilə qarşılıqlı əlaqə
Tətbiq Ansible ilə əlaqə qurur . playbook_executor üçün biz fayl adını və dəyişənlər dəstini ötürürük. Bu, Ansible layihəsini Python kodunda təsvir etməkdənsə, onu adi yml faylları şəklində saxlamağa imkan verir.
Həmçinin Ansible-da *extra_vars* vasitəsilə blok cihazının adı, biletin statusu, həmçinin məsələ açarını ehtiva edən callback_url - HTTP-də geri çağırış üçün istifadə olunur.
Hər işə salma üçün bir hostdan və bu hostun aid olduğu qrupdan ibarət müvəqqəti inventar yaradılır ki, group_vars tətbiq edilir.
HTTP geri çağırışını həyata keçirən tapşırıq nümunəsidir.
Callaback(lər)dən istifadə edərək oyun kitablarının icrasının nəticəsini alırıq. Onlar iki növdür:
- , oyun kitabının icrasının nəticələri haqqında məlumat verir. Başlanmış, uğurla və ya uğursuz yerinə yetirilən vəzifələri təsvir edir. Bu geri çağırış oyun kitabı oxunmağı bitirdikdə çağırılır.
- Oyun kitabını oynayarkən məlumat almaq üçün HTTP geri çağırışı. Ansible tapşırığında biz tətbiqimizə POST/GET sorğusunu yerinə yetiririk.
Dəyişənlər oyun kitabının icrası zamanı müəyyən edilmiş və saxlamaq və sonrakı əməliyyatlarda istifadə etmək istədiyimiz HTTP geri çağırış(lar) vasitəsilə ötürülür. Bu məlumatları sqlite-də yazırıq.
Biz həmçinin şərhlər buraxırıq və HTTP geri zəngi vasitəsilə bilet statusunu dəyişdiririk.
HTTP geri çağırışı
# 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
Eyni tipli bir çox tapşırıq kimi, biz onu ayrı bir ümumi fayla qoyuruq və lazım olduqda onu oyun kitablarında daim təkrarlamamaq üçün daxil edirik. Buraya problem açarı və host adını ehtiva edən geri çağırış_ url daxildir. Ansible bu POST sorğusunu yerinə yetirdikdə, bot bunun filan hadisənin bir hissəsi kimi gəldiyini başa düşür.
Və burada bir MD cihazından bir disk çıxardığımız oyun kitabından bir nümunə var:
# 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
Bu tapşırıq Jira biletini “Dəyişməyə hazır” statusuna köçürür və şərh əlavə edir. Həmçinin, mdam_data dəyişəni diskin çıxarıldığı md cihazlarının siyahısını, parted_info isə parted-dən bölmə zibilini saxlayır.
Mühəndis yeni bir disk daxil etdikdə, biz bu dəyişənlərdən istifadə edərək bölmə zibilini bərpa edə bilərik, həmçinin diski onun çıxarıldığı md cihazlarına daxil edə bilərik.
Ansible yoxlama rejimi
Avtomatlaşdırmanı işə salmaq qorxulu idi. Buna görə də, bütün oyun kitablarını rejimdə işlətməyə qərar verdik
, burada Ansible serverlərdə heç bir hərəkət etmir, ancaq onları təqlid edir.
Belə bir işə salınma ayrıca geri çağırış modulu vasitəsilə həyata keçirilir və oyun kitabının icrasının nəticəsi şərh olaraq Jira-da saxlanılır.
Birincisi, bu, botun və oyun kitablarının işini təsdiqləməyə imkan verdi. İkincisi, idarəçilərin bota olan inamını artırdı.
Təsdiqdən keçdik və Ansible-ı yalnız quru rejimdə işlədə bildiyinizi başa düşdükdə, eyni hostda eyni dəyişənlərlə eyni oyun kitabını işə salmaq üçün Jira-da Run Diskobot düyməsini yaratdıq, lakin normal rejimdə.
Bundan əlavə, düymə qəza baş verərsə, oyun kitabını yenidən başlatmaq üçün istifadə olunur.
Oyun kitablarının quruluşu
Artıq qeyd etdim ki, Jira biletinin statusundan asılı olaraq, bot müxtəlif oyun kitablarını işə salır.
Birincisi, girişi təşkil etmək daha asandır.
İkincisi, bəzi hallarda sadəcə zəruridir.
Məsələn, sistem diskini dəyişdirərkən əvvəlcə yerləşdirmə sisteminə keçməlisiniz, tapşırıq yaratmalısınız və düzgün yerləşdirmədən sonra server ssh vasitəsilə əlçatan olacaq və tətbiqi onun üzərinə yaymaq olar. Bütün bunları bir oyun kitabında etsəydik, o zaman Ansible ev sahibinin əlçatmaz olması səbəbindən bunu tamamlaya bilməyəcək.
Hər bir server qrupu üçün Ansible rollarından istifadə edirik. Burada siz onlardan birində oyun dəftərinin(lərin) necə təşkil olunduğunu görə bilərsiniz.
Bu rahatdır, çünki hansı vəzifələrin yerləşdiyi dərhal aydın olur. Ansible rolu üçün giriş olan main.yml-də biz sadəcə olaraq bilet statusu və ya hamı üçün tələb olunan ümumi tapşırıqları daxil edə bilərik, məsələn, şəxsiyyəti təsdiqləmək və ya nişan almaq.
təhqiqat.yml
İstintaq və Açıq statusunda biletlər üçün çalışır. Bu oyun kitabı üçün ən vacib şey blok cihazının adıdır. Bu məlumat həmişə mövcud deyil.
Bunu əldə etmək üçün Zabbix tetikleyicisinin son dəyəri olan Jira xülasəsini təhlil edirik. O, blok cihazının adını ehtiva edə bilər - şanslı. Yaxud orada montaj nöqtəsi ola bilər, onda siz serverə getmək, onu təhlil etmək və lazımi diski hesablamaq lazımdır. Tətik həm də bir scsi ünvanı və ya başqa bir məlumat ötürə bilər. Amma elə də olur ki, heç bir ipucu yoxdur və təhlil etmək lazımdır.
Blok cihazının adını öyrəndikdən sonra Jira-da sahələri doldurmaq üçün ondan diskin növü və ölçüsü haqqında məlumat toplayırıq. Biz həmçinin satıcı, model, proqram təminatı, ID, SMART haqqında məlumatları silirik və bütün bunları Jira biletində şərhə daxil edirik. Administrator və mühəndisin artıq bu məlumatları axtarmağa ehtiyacı yoxdur. 🙂
hazırlamaq2change.yml
Diskin fırlanmadan çıxarılması, dəyişdirilməsinə hazırlıq. Ən çətin və vacib mərhələ. Bu, dayandırılmaması lazım olan zaman tətbiqi dayandıra biləcəyiniz yerdir. Və ya kifayət qədər replikaları olmayan bir diski çıxarın və bununla da bəzi məlumatları itirərək istifadəçilərə təsir göstərin. Burada söhbətdə ən çox yoxlama və bildirişlərimiz var.
Ən sadə halda, diskin HW/MD RAID-dən çıxarılmasından danışırıq.
Daha mürəkkəb vəziyyətlərdə (saxlama sistemlərimizdə) ehtiyat nüsxələmə proqram səviyyəsində həyata keçirildikdə, API vasitəsilə proqrama getmək, diskin çıxışını bildirmək, onu söndürmək və bərpa etməyə başlamaq lazımdır.
İndi biz kütləvi şəkildə köçürük , və əgər server bulud əsaslıdırsa, Diskobot bulud API-yə zəng edir, onun bu minionla - konteynerlərlə işləyən serverlə işləyəcəyini bildirir və "bütün konteynerləri bu miniondan köçürməyi" xahiş edir. Və eyni zamanda, diskin arxa işığını yandırır ki, mühəndis dərhal hansını çıxarmaq lazım olduğunu görə bilsin.
dəyişdirildi.yml
Diski dəyişdirdikdən sonra əvvəlcə onun mövcudluğunu yoxlayırıq.
Mühəndislər həmişə yeni disklər quraşdırmırlar, buna görə də bizi qane edən SMART dəyərləri üçün yoxlama əlavə etdik.
Hansı atributlara baxırıq?Yenidən bölüşdürülmüş sektorların sayı (5) < 100
Cari Gözləyən Sektor Sayı (107) == 0
Sürücü sınaqdan keçsə, mühəndisə onu yenidən dəyişdirmək barədə məlumat verilir. Hər şey qaydasındadırsa, arxa işıq sönür, işarələr tətbiq olunur və disk fırlanma vəziyyətinə gətirilir.
hazır.yml
Ən sadə hal: HW/SW reyd sinxronizasiyasını yoxlamaq və ya proqramda məlumat sinxronizasiyasını bitirmək.
Tətbiq API
Mən bir neçə dəfə qeyd etmişəm ki, bot tez-tez tətbiq API-lərinə daxil olur. Əlbəttə ki, bütün tətbiqlərdə lazımi üsullar yox idi, ona görə də onları dəyişdirmək lazım idi. İstifadə etdiyimiz ən vacib üsullar bunlardır:
- Vəziyyət. Çoxluq və ya diskin vəziyyəti ilə işləyə biləcəyini anlamaq üçün;
- Start/stop. Diskin aktivləşdirilməsi/deaktivasiyası;
- Köçür/bərpa edin. Dəyişdirmə zamanı və sonra məlumatların miqrasiyası və bərpası.
Ansible-dan öyrənilən dərslər
Mən Ansible-ı həqiqətən sevirəm. Ancaq tez-tez müxtəlif açıq mənbəli layihələrə baxanda və insanların oyun kitablarını necə yazdığını görəndə bir az qorxuram. Qabıq/komandanın tez-tez istifadəsi səbəbindən nə zaman/döngü, çeviklik və idempotensiyanın mürəkkəb məntiqi interweavingləri.
Ansible - modulyarlığın üstünlüyündən istifadə edərək, hər şeyi mümkün qədər sadələşdirməyə qərar verdik. Ən yüksək səviyyədə oyun kitabları var, onları bir az Ansible bilən hər hansı bir idarəçi, üçüncü tərəf tərtibatçısı yaza bilər.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Bəzi məntiqi oyun kitablarında tətbiq etmək çətindirsə, biz onu Ansible moduluna və ya filtrinə köçürük. Skriptlər Python və ya hər hansı digər dildə yazıla bilər.
Asan və tez yazırlar. Məsələn, yuxarıda nümunəsi göstərilən diskin arxa işıq modulu 265 sətirdən ibarətdir.
Ən aşağı səviyyədə kitabxanadır. Bu layihə üçün ayrı bir proqram yazdıq, müvafiq sorğuları yerinə yetirən aparat və proqram təminatı RAID-ləri üzərində bir növ abstraksiya.
Ansible-ın ən güclü tərəfləri onun sadəliyi və aydın oyun kitablarıdır. İnanıram ki, bundan istifadə etməli və qorxulu yaml faylları və çoxlu sayda şərtlər, qabıq kodu və döngələr yaratmamalısınız.
Ansible API ilə təcrübəmizi təkrarlamaq istəyirsinizsə, iki şeyi nəzərə alın:
- Playbook_executor və ümumiyyətlə oyun kitablarına fasilə verilə bilməz. ssh sessiyasında fasilə var, lakin oyun kitabında fasilə yoxdur. Sistemdə artıq mövcud olmayan bir diski ayırmağa çalışsaq, oyun kitabı sonsuz işləyəcək, ona görə də onun işə salınmasını ayrı bir sarğıya bükməli və fasilə ilə öldürməli olduq.
- Ansible çəngəlli proseslər üzərində işləyir, ona görə də onun API-si iplik təhlükəsiz deyil. Biz bütün oyun kitablarımızı tək yivli işlədirik.
Nəticədə biz disklərin təxminən 80%-nin dəyişdirilməsini avtomatlaşdıra bildik. Ümumilikdə, əvəzetmə nisbəti iki dəfə artmışdır. Bu gün administrator sadəcə hadisəyə baxır və diskin dəyişdirilməsinin lazım olub-olmamasına qərar verir və sonra bir klik edir.
Ancaq indi başqa problemlə qarşılaşmağa başlayırıq: bəzi yeni idarəçilər sürücülərin necə dəyişdiriləcəyini bilmirlər. 🙂
Mənbə: www.habr.com