Herkese selam. OK'de lider sistem yöneticisi olarak çalışıyorum ve portalın istikrarlı işleyişinden sorumluyum. Disklerin otomatik olarak değiştirilmesine yönelik nasıl bir süreç oluşturduğumuzdan ve ardından yöneticiyi bu sürecin dışında bırakıp yerine bir botu nasıl getirdiğimizden bahsetmek istiyorum.
Bu makale bir tür harf çevirisidir HighLoad+ 2018'de
Disk değiştirme süreci oluşturma
İlk önce bazı sayılar
OK, milyonlarca insan tarafından kullanılan dev bir hizmettir. 7 farklı veri merkezinde yer alan yaklaşık 4 bin sunucu ile hizmet verilmektedir. Sunucular 70 binden fazla disk içerir. Bunları üst üste koyarsanız 1 km'den daha yüksek bir kule elde edersiniz.
Sabit sürücüler en sık arızalanan sunucu bileşenidir. Bu tür hacimlerle haftada yaklaşık 30 diski değiştirmek zorunda kalıyoruz ve bu prosedür pek hoş olmayan bir rutin haline geldi.
olaylar
Şirketimiz tam teşekküllü olay yönetimini uygulamaya koymuştur. Jira'daki her olayı kaydediyoruz ve ardından çözüp çözüyoruz. Eğer bir olay kullanıcıları etkilemişse mutlaka bir araya gelip bu tür durumlarda nasıl daha hızlı müdahale edebiliriz, etkiyi nasıl azaltabiliriz ve tabi ki tekrarının nasıl önüne geçebiliriz diye düşünürüz.
Depolama cihazları istisna değildir. Durumları Zabbix tarafından izleniyor. Syslog'daki mesajları yazma/okuma hatalarına karşı izliyoruz, HW/SW baskınlarının durumunu analiz ediyoruz, SMART'ı izliyoruz ve SSD'lerin aşınmasını hesaplıyoruz.
Diskler daha önce nasıl değiştirildi?
Zabbix'te bir tetikleyici meydana geldiğinde Jira'da bir olay oluşturulur ve otomatik olarak veri merkezlerindeki uygun mühendislere atanır. Bunu tüm HW vakalarında, yani veri merkezinde ekipmanla herhangi bir fiziksel çalışma gerektiren vakalarda yapıyoruz.
Veri merkezi mühendisi, donanımla ilgili sorunları çözen ve sunucuların kurulumundan, bakımından ve sökülmesinden sorumlu olan kişidir. Bileti alan mühendis işe koyulur. Disk raflarında diskleri bağımsız olarak değiştirir. Ancak gerekli cihaza erişimi yoksa mühendis, yardım için görevli sistem yöneticilerinden yardım ister. Her şeyden önce, diski rotasyondan çıkarmanız gerekir. Bunu yapmak için sunucuda gerekli değişiklikleri yapmanız, uygulamaları durdurmanız ve diskin bağlantısını kesmeniz gerekir.
Görevli sistem yöneticisi vardiya boyunca tüm portalın işleyişinden sorumludur. Olayları araştırıyor, onarımlar yapıyor ve geliştiricilerin küçük görevleri tamamlamasına yardımcı oluyor. Sadece sabit disklerle ilgilenmiyor.
Daha önce veri merkezi mühendisleri sistem yöneticisiyle sohbet yoluyla iletişim kuruyordu. Mühendisler Jira biletlerine bağlantılar gönderdi, yönetici onları takip etti ve bazı not defterlerinde işlerin kaydını tuttu. Ancak sohbetler bu tür görevler için uygun değildir: oradaki bilgiler yapılandırılmamıştır ve hızla kaybolur. Ve yönetici bilgisayardan uzaklaşıp bir süre isteklere yanıt vermeyebilirken, mühendis bir yığın diskle sunucunun başında durup bekledi.
Ancak en kötüsü yöneticilerin resmin tamamını görememeleriydi: Hangi disk olaylarının mevcut olduğu, potansiyel olarak nerede bir sorunun ortaya çıkabileceği. Bunun nedeni, tüm Donanım olaylarını mühendislere devretmemizdir. Evet, tüm olayları yönetici kontrol panelinde görüntülemek mümkündü. Ancak bunlardan birçoğu var ve yönetici yalnızca bazılarıyla ilgilendi.
Ayrıca mühendis, belirli sunucuların amacı veya sürücüler arasındaki bilgi dağıtımı hakkında hiçbir şey bilmediğinden öncelikleri doğru şekilde belirleyemedi.
Yeni değiştirme prosedürü
Yaptığımız ilk şey, tüm disk olaylarını ayrı bir "HW diski" türüne taşımak ve bu bilgilerin bilette saklanması ve kaydedilmesi için "blok cihaz adı", "boyut" ve "disk türü" alanlarını buna eklemekti. sohbette sürekli alışveriş yapmak zorunda değilsiniz.
Ayrıca bir olay sırasında yalnızca bir diski değiştireceğimiz konusunda da anlaştık. Bu, otomasyon sürecini, istatistik toplamayı ve gelecekteki çalışmayı önemli ölçüde basitleştirdi.
Ayrıca “sorumlu yönetici” alanını da ekledik. Görevli sistem yöneticisi otomatik olarak oraya eklenir. Bu çok kullanışlıdır çünkü artık mühendis her zaman kimin sorumlu olduğunu görmektedir. Takvime gidip arama yapmanıza gerek yok. Yöneticinin kontrol panelinde yardımına ihtiyaç duyabilecek biletlerin görüntülenmesini mümkün kılan da bu alandı.
Tüm katılımcıların yeniliklerden maksimum faydayı elde etmesini sağlamak için filtreler ve gösterge tabloları oluşturduk ve bunları çocuklara anlattık. İnsanlar değişiklikleri anladıklarında gereksiz bir şeymiş gibi onlardan uzaklaşmazlar. Bir mühendisin sunucunun bulunduğu raf numarasını, diskin boyutunu ve türünü bilmesi önemlidir. Yöneticinin öncelikle bunun ne tür bir sunucu grubu olduğunu ve diski değiştirirken etkisinin ne olabileceğini anlaması gerekir.
Alanların varlığı ve görüntülenmesi uygundur ancak bu bizi sohbet kullanma ihtiyacından kurtarmadı. Bunu yapmak için iş akışını değiştirmemiz gerekiyordu.
Daha önce şöyleydi:
Mühendisler bugün yönetici yardımına ihtiyaç duymadıklarında bu şekilde çalışmaya devam ediyorlar.
Yaptığımız ilk şey yeni bir statü tanıtmaktı İncelemek. Mühendis bir yöneticiye ihtiyaç duyup duymayacağına henüz karar vermediğinde bilet bu durumdadır. Bu durum aracılığıyla mühendis, bileti yöneticiye aktarabilir. Ayrıca bu durumu, bir diskin değiştirilmesi gerektiğinde ancak diskin kendisi tesiste olmadığında biletleri işaretlemek için kullanırız. Bu, CDN'ler ve uzak siteler durumunda olur.
Ayrıca durum ekledik Hazır. Bilet, diski değiştirdikten sonra ona aktarılır. Yani, her şey zaten yapılmıştır, ancak HW/SW RAID sunucuda senkronize edilmiştir. Bu oldukça uzun zaman alabilir.
Eğer işe bir yönetici dahil olursa, plan biraz daha karmaşık hale gelir.
Durumdan Açılış Bilet hem sistem yöneticisi hem de mühendis tarafından tercüme edilebilir. Durumda devam etmekte yönetici diski rotasyondan çıkarır, böylece mühendis kolayca dışarı çıkarabilir: belirli sunucu grubuna bağlı olarak arka ışığı açar, diskin bağlantısını keser, uygulamaları durdurur.
Bilet daha sonra şuraya aktarılır: değişmeye hazır: Bu, mühendise diskin çıkarılabileceğine dair bir sinyaldir. Jira'daki tüm alanlar zaten doldurulmuştur, mühendis diskin türünü ve boyutunu bilir. Bu veriler ya önceki duruma otomatik olarak ya da yönetici tarafından girilir.
Diski değiştirdikten sonra bilet durumu şu şekilde değiştirilir: değişmiş. Doğru diskin takılıp takılmadığını, bölümlemenin yapıldığını, uygulamanın başlatıldığını ve bazı veri kurtarma görevlerinin başlatıldığını kontrol eder. Bilet aynı zamanda duruma da aktarılabilir Hazır, bu durumda yönetici diski rotasyona soktuğu için sorumlu kalacaktır. Diyagramın tamamı şuna benziyor.
Yeni alanların eklenmesi hayatımızı çok kolaylaştırdı. Adamlar yapılandırılmış bilgilerle çalışmaya başladılar, neyin hangi aşamada yapılması gerektiği belli oldu. Artık yönetici tarafından belirlendiği için öncelikler çok daha alakalı hale geldi.
Sohbetlere gerek yok. Elbette yönetici mühendise "Bunun daha hızlı değiştirilmesi gerekiyor" veya "Zaten akşam oldu, değiştirmek için zamanınız olacak mı?" Ancak artık bu konularda günlük sohbetlerde iletişim kurmuyoruz.
Diskler toplu olarak değiştirilmeye başlandı. Yönetici işe biraz erken geldiyse, boş zamanı varsa ve henüz hiçbir şey olmadıysa, bir dizi sunucuyu değiştirmeye hazırlayabilir: alanları doldurun, diskleri rotasyondan çıkarın ve görevi bir mühendise aktarın. Mühendis biraz sonra veri merkezine gelir, görevi görür, gerekli sürücüleri depodan alır ve hemen değiştirir. Sonuç olarak, değiştirme oranı arttı.
İş Akışı oluşturulurken öğrenilen dersler
- Bir prosedür oluştururken farklı kaynaklardan bilgi toplamanız gerekir.
Yöneticilerimizden bazıları mühendisin diskleri kendisinin değiştirdiğini bilmiyordu. Bazıları MD RAID senkronizasyonunun mühendisler tarafından yapıldığını düşünüyordu, hatta bazılarının buna erişimi bile yoktu. Bazı önde gelen mühendisler bunu yaptı, ancak her zaman değil çünkü süreç hiçbir yerde tanımlanmadı. - Prosedür basit ve anlaşılır olmalıdır.
Bir kişinin birçok adımı akılda tutması zordur. Jira'daki en önemli komşu durumlar ana ekrana yerleştirilmelidir. Bunları yeniden adlandırabilirsiniz, örneğin Devam Ediyor Değişime hazır diyoruz. Ve diğer durumlar, göze batmaması için açılır menüde gizlenebilir. Ancak insanları sınırlamamak, onlara geçiş yapma fırsatı vermek daha iyidir.
Yeniliğin değerini açıklayın. İnsanlar anladığında yeni prosedürü daha fazla kabul ediyorlar. İnsanların tüm süreci tıklamak yerine takip etmesi bizim için çok önemliydi. Daha sonra bunun üzerine otomasyonu kurduk. - Bekle, analiz et, çöz.
Prosedürü, teknik uygulamayı, toplantıları ve tartışmaları oluşturmak yaklaşık bir ayımızı aldı. Ve uygulama üç aydan fazla sürüyor. İnsanların yavaş yavaş bu yeniliği nasıl kullanmaya başladıklarını gördüm. İlk aşamalarda çok fazla olumsuzluk vardı. Ancak prosedürün kendisinden ve teknik uygulamasından tamamen bağımsızdı. Örneğin bir yönetici Jira'yı değil, Confluence'da Jira eklentisini kullanıyordu ve bazı şeyler onun kullanımına açık değildi. Ona Jira'yı gösterdik ve hem genel görevler hem de diskleri değiştirme konusunda yöneticinin üretkenliği arttı.
Disk değiştirme otomasyonu
Disk değiştirme otomasyonuna birkaç kez yaklaştık. Zaten geliştirmelerimiz ve senaryolarımız vardı, ancak bunların hepsi ya etkileşimli ya da manuel olarak çalışıyordu ve başlatılması gerekiyordu. Ve ancak yeni prosedürü uygulamaya koyduktan sonra, tam olarak kaçırdığımız şeyin bu olduğunu fark ettik.
Artık değiştirme sürecimiz, her biri belirli bir icracıya ve bir eylem listesine sahip olan aşamalara bölünmüş olduğundan, otomasyonu tek seferde değil, aşamalar halinde etkinleştirebiliriz. Örneğin, en basit aşama - Hazır (RAID/veri senkronizasyonunun kontrol edilmesi) kolayca bir bota devredilebilir. Bot biraz öğrendiğinde, ona daha önemli bir görev verebilirsiniz - diski döndürmek vb.
Hayvanat bahçesi kurulumları
Bot hakkında konuşmadan önce, hayvanat bahçemizdeki kurulumlara kısa bir gezi yapalım. Her şeyden önce altyapımızın devasa boyutundan kaynaklanıyor. İkinci olarak her hizmet için en uygun donanım konfigürasyonunu seçmeye çalışıyoruz. Çoğunlukla LSI ve Adaptec olmak üzere yaklaşık 20 donanım RAID modelimiz var, ancak farklı versiyonlarda HP ve DELL de var. Her RAID denetleyicisinin kendi yönetim yardımcı programı vardır. Komut kümesi ve bunların verilmesi, her RAID denetleyicisi için sürümden sürüme farklılık gösterebilir. HW-RAID'in kullanılmadığı durumlarda mdraid kullanılabilir.
Neredeyse tüm yeni kurulumları disk yedekleme olmadan yapıyoruz. Sistemlerimizi sunucular yerine veri merkezi düzeyinde yedeklediğimiz için artık donanım ve yazılım RAID'i kullanmamaya çalışıyoruz. Ancak elbette desteklenmesi gereken birçok eski sunucu var.
Bir yerlerde RAID denetleyicilerindeki diskler ham cihazlara aktarılıyor, bir yerlerde JBOD'lar kullanılıyor. Sunucuda bir sistem diski bulunan yapılandırmalar vardır ve değiştirilmesi gerekiyorsa, aynı sürümlerdeki işletim sistemi ve uygulamaların kurulumuyla sunucuyu yeniden yüklemeniz, ardından yapılandırma dosyalarını eklemeniz, uygulamaları başlatmanız gerekir. Yedeklemenin disk alt sistemi düzeyinde değil, doğrudan uygulamaların kendisinde gerçekleştirildiği birçok sunucu grubu da vardır.
Toplamda 400'e yakın farklı uygulamayı çalıştıran 100'ün üzerinde benzersiz sunucu grubumuz var. Bu kadar çok sayıda seçeneği karşılamak için çok işlevli bir otomasyon aracına ihtiyacımız vardı. Tercihen basit bir DSL ile, böylece yalnızca onu yazan kişi destekleyemez.
Aracısız olduğu için Ansible'ı seçtik: Altyapı hazırlamaya gerek yoktu, hızlı bir başlangıç. Ayrıca ekip içerisinde standart olarak kabul edilen Python ile yazılmıştır.
Genel şema
Örnek olarak bir olayı kullanarak genel otomasyon şemasına bakalım. Zabbix, sdb diskinin arızalandığını tespit eder, tetikleyici yanar ve Jira'da bir bilet oluşturulur. Yönetici ona baktı, bunun bir kopya olmadığını veya hatalı bir pozitif olmadığını, yani diskin değiştirilmesi gerektiğini fark etti ve bileti Devam Ediyor'a aktardı.
Python'da yazılan DiskoBot uygulaması, Jira'ya yeni biletler için periyodik olarak anket yapıyor. Yeni bir Devam Ediyor bildiriminin göründüğünü fark eder, karşılık gelen iş parçacığı tetiklenir ve bu, Ansible'da oyun kitabını başlatır (bu, Jira'daki her durum için yapılır). Bu durumda, Pretty2change başlatılır.
Ansible ana bilgisayara gönderilir, diski rotasyondan çıkarır ve geri aramalar aracılığıyla durumu uygulamaya bildirir.
Sonuçlara göre bot, bileti otomatik olarak Değişime hazır'a aktarır. Mühendis bir bildirim alır ve diski değiştirmeye gider, ardından bileti Değiştirildi'ye aktarır.
Yukarıda açıklanan şemaya göre bilet, başka bir oyun kitabını başlatan bota geri döner, ana bilgisayara gider ve diski döndürmeye başlar. Bot bileti kapatıyor. Yaşasın!
Şimdi sistemin bazı bileşenlerinden bahsedelim.
Diskobot
Bu uygulama Python'da yazılmıştır. JQL'e göre Jira'dan bilet seçiyor. Biletin durumuna bağlı olarak, ikincisi ilgili işleyiciye gider ve bu da duruma karşılık gelen Ansible playbook'unu başlatır.
JQL ve yoklama aralıkları uygulama yapılandırma dosyasında tanımlanır.
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
Örneğin Devam ediyor durumundaki bildirimler arasından yalnızca Disk boyutu ve Cihaz adı alanları doldurulmuş olanlar seçilir. Cihaz adı, oynatma kitabını yürütmek için gereken blok cihazın adıdır. Mühendisin hangi boyutta diske ihtiyaç duyulduğunu bilmesi için disk boyutu gereklidir.
Hazır durumundaki biletler arasında dbot_ignore etiketine sahip olan biletler filtrelenir. Bu arada Jira etiketlerini hem bu filtreleme için hem de mükerrer biletleri işaretlemek ve istatistik toplamak için kullanıyoruz.
Bir taktik kitabı başarısız olursa Jira, daha sonra çözülebilmesi için dbot_failed etiketini atar.
Ansible ile birlikte çalışabilirlik
Uygulama Ansible ile iletişim kurar: . playbook_executor'a dosya adını ve bir dizi değişkeni iletiyoruz. Bu, Ansible projesini Python kodunda tanımlamak yerine normal yml dosyaları biçiminde tutmanıza olanak tanır.
Ayrıca Ansible'da, *extra_vars* aracılığıyla, blok cihazının adı, biletin durumu ve ayrıca sorun anahtarını içeren callback_url, HTTP'de geri arama için kullanılır.
Her başlatma için, bir ana bilgisayar ve bu ana bilgisayarın ait olduğu gruptan oluşan geçici bir envanter oluşturulur, böylece group_vars uygulanır.
Burada HTTP geri aramasını uygulayan bir görev örneği verilmiştir.
Playbook'ları geri çağırma(lar) kullanarak yürütmenin sonucunu alıyoruz. İki türdendirler:
- , başucu kitabı yürütmesinin sonuçlarına ilişkin verileri sağlar. Başlatılan, başarıyla tamamlanan veya başarısız olan görevleri açıklar. Bu geri arama, başucu kitabının oynatılması bittiğinde çağrılır.
- Bir başucu kitabı oynatılırken bilgi almak için HTTP geri araması. Ansible görevinde uygulamamıza bir POST/GET isteği yürütüyoruz.
Değişkenler, oynatma kitabının yürütülmesi sırasında tanımlanan ve sonraki çalıştırmalarda kaydedip kullanmak istediğimiz HTTP geri çağrılarından geçirilir. Bu verileri sqlite'a yazıyoruz.
Ayrıca yorum bırakıyoruz ve HTTP geri arama yoluyla bilet durumunu değiştiriyoruz.
HTTP geri arama
# 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
Aynı türdeki birçok görev gibi, bunu da ayrı bir ortak dosyaya koyuyoruz ve gerektiğinde oyun kitaplarında sürekli tekrarlamamak için dahil ediyoruz. Buna, sorun anahtarını ve ana bilgisayar adını içeren callback_ URL'si de dahildir. Ansible bu POST isteğini yürüttüğünde bot bunun falanca bir olayın parçası olarak geldiğini anlar.
Ve burada bir MD cihazından bir diskin çıktısını aldığımız başucu kitabından bir örnek 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 görev, Jira biletini "Değişime hazır" durumuna aktarır ve bir yorum ekler. Ayrıca mdam_data değişkeni, diskin kaldırıldığı md aygıtlarının bir listesini saklar ve parted_info, parted'den bir bölüm dökümü saklar.
Mühendis yeni bir disk taktığında, bu değişkenleri bölüm dökümünü geri yüklemek için kullanabiliriz, ayrıca diski kaldırıldığı md aygıtlarına yerleştirebiliriz.
Ansible kontrol modu
Otomasyonu açmak korkutucuydu. Bu nedenle tüm oyun kitaplarını bu modda çalıştırmaya karar verdik.
Ansible'ın sunucularda herhangi bir eylem gerçekleştirmediği, yalnızca bunları taklit ettiği.
Böyle bir başlatma, ayrı bir geri çağırma modülü aracılığıyla gerçekleştirilir ve başucu kitabı yürütmesinin sonucu, Jira'da yorum olarak kaydedilir.
İlk olarak bu, botun ve oyun kitaplarının çalışmasının doğrulanmasını mümkün kıldı. İkinci olarak yöneticilerin bota olan güveni arttı.
Doğrulamayı geçtiğimizde ve Ansible'ı yalnızca kuru çalıştırma modunda değil, aynı ana bilgisayarda aynı değişkenlerle aynı oyun kitabını normal modda başlatmak için Jira'da Diskobot'u Çalıştır düğmesi yaptık.
Ayrıca bu düğme, oyun kitabının çökmesi durumunda yeniden başlatmak için kullanılır.
Başucu Kitaplarının yapısı
Jira biletinin durumuna bağlı olarak botun farklı oyun kitapları başlattığını daha önce belirtmiştim.
Öncelikle girişi organize etmek çok daha kolay.
İkincisi, bazı durumlarda bu sadece gereklidir.
Örneğin, bir sistem diskini değiştirirken, önce dağıtım sistemine gitmeniz, bir görev oluşturmanız gerekir ve doğru dağıtımdan sonra sunucuya ssh aracılığıyla erişilebilir hale gelir ve uygulamayı onun üzerine yayınlayabilirsiniz. Tüm bunları tek bir taktik kitabında yapsaydık, Ansible, sunucunun müsait olmaması nedeniyle bunu tamamlayamazdı.
Her sunucu grubu için Ansible rollerini kullanıyoruz. Burada oyun kitaplarının bunlardan birinde nasıl düzenlendiğini görebilirsiniz.
Bu uygundur çünkü hangi görevlerin nerede olduğu hemen belli olur. Ansible rolünün girdisi olan main.yml'de, bilet durumuna göre veya herkes için gereken genel görevleri (örneğin, kimlik doğrulama veya jeton alma) kolayca dahil edebiliriz.
Soruşturma.yml
Soruşturma ve Açık durumundaki biletler için çalışır. Bu oyun kitabı için en önemli şey blok cihazının adıdır. Bu bilgi her zaman mevcut değildir.
Bunu elde etmek için Zabbix tetikleyicisinin son değeri olan Jira özetini analiz ediyoruz. Blok cihazının adını içerebilir - şanslı. Veya bir bağlama noktası içerebilir, o zaman sunucuya gitmeniz, onu ayrıştırmanız ve gerekli diski hesaplamanız gerekir. Tetikleyici ayrıca bir scsi adresini veya başka bir bilgiyi de iletebilir. Ama aynı zamanda hiçbir ipucunun olmadığı ve analiz etmeniz gerektiği de oluyor.
Blok cihazının adını öğrendikten sonra Jira'daki alanları doldurmak için diskin türü ve boyutu hakkında bilgi topluyoruz. Ayrıca satıcı, model, donanım yazılımı, kimlik, SMART hakkındaki bilgileri de kaldırıyoruz ve tüm bunları Jira biletindeki bir yoruma ekliyoruz. Yöneticinin ve mühendisin artık bu verileri aramasına gerek yoktur. 🙂
hazır2change.yml
Diskin rotasyondan çıkarılması, değiştirmeye hazırlanması. En zor ve önemli aşama. Durdurulmaması gerektiğinde uygulamayı durdurabileceğiniz yer burasıdır. Veya yeterli kopyaya sahip olmayan ve dolayısıyla kullanıcılar üzerinde etki yaratarak bazı verileri kaybeden bir diski çıkarın. Sohbette en fazla kontrol ve bildirimi burada görüyoruz.
En basit durumda, bir diski HW/MD RAID'den çıkarmaktan bahsediyoruz.
Daha karmaşık durumlarda (depolama sistemlerimizde), uygulama seviyesinde yedekleme yapıldığında API üzerinden uygulamaya gidip disk çıktısını raporlamanız, devre dışı bırakmanız ve kurtarmayı başlatmanız gerekir.
Artık topluca göç ediyoruz , ve sunucu bulut tabanlıysa, Diskobot bulut API'sini çağırır, bu minionla (konteynerleri çalıştıran sunucu) çalışacağını söyler ve "bu minyondan tüm konteynerleri taşı" diye sorar. Aynı zamanda diskin arka ışığını da açar, böylece mühendis hangisinin çıkarılması gerektiğini hemen görebilir.
değişti.yml
Bir diski değiştirdikten sonra öncelikle kullanılabilirliğini kontrol ederiz.
Mühendisler her zaman yeni sürücüler kurmazlar, bu nedenle bizi tatmin eden SMART değerleri için bir kontrol ekledik.
Hangi niteliklere bakıyoruz?Yeniden Tahsis Edilen Sektör Sayısı (5) < 100
Mevcut Bekleyen Sektör Sayısı (107) == 0
Sürücü testi geçemezse mühendise sürücüyü yeniden değiştirmesi bildirilir. Her şey yolundaysa arka ışık kapanır, işaretler uygulanır ve disk döndürülür.
hazır.yml
En basit durum: HW/SW raid senkronizasyonunun kontrol edilmesi veya uygulamada veri senkronizasyonunun sonlandırılması.
Uygulama API'si
Botun sıklıkla uygulama API'lerine eriştiğinden birkaç kez bahsetmiştim. Elbette tüm uygulamalar gerekli yöntemlere sahip değildi, dolayısıyla bunların değiştirilmesi gerekiyordu. Kullandığımız en önemli yöntemler şunlardır:
- Durum. Üzerinde çalışılıp çalışılamayacağını anlamak için bir kümenin veya diskin durumu;
- Başla dur. Diskin etkinleştirilmesi/devre dışı bırakılması;
- Taşı/geri yükle. Değiştirme sırasında ve sonrasında veri taşıma ve kurtarma.
Ansible'dan öğrenilen dersler
Ansible'ı gerçekten seviyorum. Ancak çoğu zaman farklı açık kaynak projelerine baktığımda ve insanların nasıl taktik kitapları yazdıklarını gördüğümde biraz korkuyorum. Kabuk/komutun sık kullanımı nedeniyle ne zaman/döngünün karmaşık mantıksal iç içe geçmesi, esneklik eksikliği ve eşgüçlülük.
Ansible'ın modülerlik avantajından yararlanarak her şeyi mümkün olduğunca basitleştirmeye karar verdik. En üst düzeyde taktik kitapları var; bunlar Ansible'ı biraz bilen herhangi bir yönetici veya üçüncü taraf geliştirici tarafından yazılabilir.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Eğer bazı mantığın oyun kitaplarında uygulanması zorsa, bunu bir Ansible modülüne veya filtresine taşıyoruz. Komut dosyaları Python'da veya başka bir dilde yazılabilir.
Yazmaları kolay ve hızlıdır. Örneğin yukarıda örneği gösterilen disk arka ışık modülü 265 satırdan oluşmaktadır.
En alt katta ise kütüphane bulunmaktadır. Bu proje için, ilgili istekleri gerçekleştiren donanım ve yazılım RAID'leri üzerinde bir tür soyutlama olan ayrı bir uygulama yazdık.
Ansible'ın en güçlü yönleri basitliği ve net oyun kitaplarıdır. Bunu kullanmanız ve korkunç yaml dosyaları ve çok sayıda koşul, kabuk kodu ve döngü oluşturmamanız gerektiğine inanıyorum.
Ansible API deneyimimizi tekrarlamak istiyorsanız iki şeyi aklınızda bulundurun:
- Playbook_executor ve genel olarak oyun kitaplarına zaman aşımı verilemez. Ssh oturumunda bir zaman aşımı var, ancak oyun kitabında zaman aşımı yok. Artık sistemde bulunmayan bir diskin bağlantısını kesmeye çalışırsak, oyun kitabı sonsuza kadar çalışacaktır, bu nedenle başlatılmasını ayrı bir sarmalayıcıya sarmak ve bir zaman aşımı ile kapatmak zorunda kaldık.
- Ansible, çatallanmış işlemlerde çalıştığından API'si iş parçacığı açısından güvenli değildir. Tüm oyun kitaplarımızı tek iş parçacıklı olarak çalıştırıyoruz.
Sonuç olarak disklerin yaklaşık %80'inin değiştirilmesini otomatikleştirmeyi başardık. Genel olarak, yenileme oranı iki katına çıktı. Bugün yönetici sadece olaya bakıyor ve diskin değiştirilmesi gerekip gerekmediğine karar veriyor ve ardından tek bir tıklama yapıyor.
Ancak şimdi başka bir sorunla karşılaşmaya başlıyoruz: bazı yeni yöneticiler sürücüleri nasıl değiştireceklerini bilmiyor. 🙂
Kaynak: habr.com