Halo semua. Saya bekerja sebagai administrator sistem terkemuka di OK dan bertanggung jawab atas stabilitas pengoperasian portal. Saya ingin berbicara tentang bagaimana kami membangun proses penggantian disk secara otomatis, dan kemudian bagaimana kami mengecualikan administrator dari proses ini dan menggantinya dengan bot.
Artikel ini adalah semacam transliterasi di Beban Tinggi+ 2018
Membangun proses penggantian disk
Pertama beberapa angka
OK adalah layanan raksasa yang digunakan oleh jutaan orang. Dilayani oleh sekitar 7 ribu server yang berlokasi di 4 pusat data berbeda. Server berisi lebih dari 70 ribu disk. Jika Anda menumpuknya di atas satu sama lain, Anda akan mendapatkan menara setinggi lebih dari 1 km.
Hard drive adalah komponen server yang paling sering gagal. Dengan volume sebesar itu, kami harus mengganti sekitar 30 disk per minggu, dan prosedur ini menjadi rutinitas yang tidak menyenangkan.
Insiden
Perusahaan kami telah memperkenalkan manajemen insiden yang lengkap. Kami mencatat setiap kejadian di Jira, lalu menyelesaikan dan menyelesaikannya. Jika suatu insiden berdampak pada pengguna, maka kami pasti berkumpul dan memikirkan bagaimana merespons lebih cepat dalam kasus seperti itu, bagaimana mengurangi dampaknya dan, tentu saja, bagaimana mencegah terulangnya kembali.
Perangkat penyimpanan tidak terkecuali. Status mereka dipantau oleh Zabbix. Kami memantau pesan di Syslog untuk kesalahan tulis/baca, menganalisis status serangan HW/SW, memantau SMART, dan menghitung keausan SSD.
Bagaimana disk diubah sebelumnya
Ketika pemicu terjadi di Zabbix, sebuah insiden dibuat di Jira dan secara otomatis ditugaskan ke teknisi yang sesuai di pusat data. Kami melakukan ini pada semua insiden HW, yaitu insiden yang memerlukan pekerjaan fisik dengan peralatan di pusat data.
Insinyur pusat data adalah orang yang menyelesaikan masalah terkait perangkat keras dan bertanggung jawab untuk memasang, memelihara, dan membongkar server. Setelah menerima tiket, insinyur tersebut mulai bekerja. Di rak disk, dia mengganti disk secara mandiri. Tetapi jika dia tidak memiliki akses ke perangkat yang diperlukan, insinyur tersebut meminta bantuan administrator sistem yang bertugas. Pertama-tama, Anda perlu mengeluarkan disk dari rotasi. Untuk melakukan ini, Anda perlu membuat perubahan yang diperlukan pada server, menghentikan aplikasi, dan melepas disk.
Administrator sistem yang bertugas bertanggung jawab atas pengoperasian seluruh portal selama shift kerja. Dia menyelidiki insiden, melakukan perbaikan, dan membantu pengembang menyelesaikan tugas-tugas kecil. Dia tidak hanya berurusan dengan hard drive.
Sebelumnya, teknisi pusat data berkomunikasi dengan administrator sistem melalui obrolan. Insinyur mengirimkan tautan ke tiket Jira, administrator mengikutinya, menyimpan catatan pekerjaan di beberapa buku catatan. Namun obrolan tidak nyaman untuk tugas-tugas seperti itu: informasi di sana tidak terstruktur dan cepat hilang. Dan administrator bisa saja meninggalkan komputer dan tidak menanggapi permintaan selama beberapa waktu, sementara teknisi berdiri di depan server dengan setumpuk disk dan menunggu.
Namun yang terburuk adalah administrator tidak melihat gambaran keseluruhan: insiden disk apa yang terjadi, di mana potensi masalah muncul. Hal ini disebabkan oleh fakta bahwa kami mendelegasikan semua insiden HW kepada para insinyur. Ya, semua insiden dapat ditampilkan di dasbor administrator. Tapi jumlahnya banyak, dan pengelola hanya terlibat beberapa saja.
Selain itu, insinyur tersebut tidak dapat menetapkan prioritas dengan benar, karena dia tidak tahu apa-apa tentang tujuan server tertentu atau distribusi informasi antar drive.
Prosedur penggantian baru
Hal pertama yang kami lakukan adalah memindahkan semua insiden disk ke dalam tipe terpisah "HW disk" dan menambahkan bidang "nama perangkat blok", "ukuran" dan "tipe disk" ke dalamnya sehingga informasi ini akan disimpan di tiket dan akan tidak harus terus-menerus bertukar obrolan.
Kami juga sepakat bahwa dalam satu kejadian kami hanya akan mengganti satu disk. Ini secara signifikan menyederhanakan proses otomatisasi, pengumpulan statistik, dan pekerjaan di masa depan.
Selain itu, kami menambahkan bidang “administrator yang bertanggung jawab”. Administrator sistem yang bertugas secara otomatis dimasukkan di sana. Ini sangat memudahkan, karena sekarang insinyur selalu melihat siapa yang bertanggung jawab. Tidak perlu pergi ke kalender dan mencari. Bidang inilah yang memungkinkan untuk menampilkan tiket di dasbor administrator yang mungkin memerlukan bantuannya.
Untuk memastikan bahwa semua peserta menerima manfaat maksimal dari inovasi, kami membuat filter dan dasbor dan memberi tahu mereka tentang hal tersebut. Ketika orang memahami perubahan, mereka tidak menjauhkan diri dari perubahan tersebut sebagai sesuatu yang tidak perlu. Penting bagi seorang insinyur untuk mengetahui nomor rak tempat server berada, ukuran dan jenis disk. Pertama-tama, administrator perlu memahami jenis grup server apa ini dan apa efeknya saat mengganti disk.
Kehadiran kolom dan tampilannya memang nyaman, tetapi ini tidak menyelamatkan kita dari kebutuhan untuk menggunakan obrolan. Untuk melakukan ini, kami harus mengubah alur kerja.
Sebelumnya seperti ini:
Beginilah cara para insinyur terus bekerja saat ini ketika mereka tidak memerlukan bantuan administrator.
Hal pertama yang kami lakukan adalah memperkenalkan status baru Menyelidiki. Tiket berada dalam status ini ketika teknisi belum memutuskan apakah ia memerlukan administrator atau tidak. Melalui status ini, teknisi dapat mentransfer tiket ke administrator. Selain itu, kami menggunakan status ini untuk menandai tiket ketika disk perlu diganti, namun disk itu sendiri tidak ada di lokasi. Hal ini terjadi pada kasus CDN dan situs jarak jauh.
Kami juga menambahkan status Siap. Tiket ditransfer ke sana setelah mengganti disk. Artinya, semuanya sudah dilakukan, tetapi RAID HW/SW disinkronkan di server. Ini bisa memakan waktu cukup lama.
Jika seorang administrator terlibat dalam pekerjaan tersebut, skemanya menjadi sedikit lebih rumit.
Dari status Open Tiket dapat diterjemahkan oleh administrator sistem dan teknisi. Dalam status Sedang berlangsung administrator mengeluarkan disk dari rotasi sehingga insinyur dapat dengan mudah menariknya keluar: menyalakan lampu latar, melepas disk, menghentikan aplikasi, tergantung pada grup server tertentu.
Tiket kemudian ditransfer ke Siap berubah: Ini merupakan sinyal kepada teknisi bahwa disk dapat ditarik keluar. Semua kolom di Jira sudah terisi, teknisi mengetahui jenis dan ukuran disk. Data ini dimasukkan secara otomatis pada status sebelumnya atau oleh administrator.
Setelah mengganti disk, status tiket diubah menjadi Berubah. Ia memeriksa apakah disk yang benar telah dimasukkan, partisi selesai, aplikasi diluncurkan dan beberapa tugas pemulihan data diluncurkan. Tiket juga dapat ditransfer ke status Siap, dalam hal ini administrator akan tetap bertanggung jawab, karena dia memutar disk tersebut. Diagram lengkapnya terlihat seperti ini.
Menambahkan bidang baru membuat hidup kita lebih mudah. Orang-orang mulai bekerja dengan informasi terstruktur, menjadi jelas apa yang perlu dilakukan dan pada tahap apa. Prioritas menjadi jauh lebih relevan karena kini ditetapkan oleh administrator.
Tidak perlu mengobrol. Tentu saja, administrator dapat menulis kepada teknisi “ini perlu diganti lebih cepat”, atau “ini sudah malam, apakah Anda punya waktu untuk menggantinya?” Namun kami tidak lagi berkomunikasi setiap hari melalui obrolan mengenai masalah ini.
Disk mulai diubah secara bertahap. Jika administrator datang bekerja sedikit lebih awal, dia memiliki waktu luang, dan belum terjadi apa-apa, dia dapat menyiapkan sejumlah server untuk penggantinya: mengisi kolom, mengeluarkan disk dari rotasi dan mentransfer tugas ke insinyur. Insinyur datang ke pusat data beberapa saat kemudian, melihat tugasnya, mengambil drive yang diperlukan dari gudang dan segera menggantinya. Akibatnya, tingkat penggantian meningkat.
Pelajaran yang didapat saat membangun Alur Kerja
- Saat membangun suatu prosedur, Anda perlu mengumpulkan informasi dari berbagai sumber.
Beberapa administrator kami tidak mengetahui bahwa teknisi sendiri yang mengubah disk. Beberapa orang mengira sinkronisasi MD RAID ditangani oleh para insinyur, meskipun beberapa dari mereka bahkan tidak memiliki akses untuk melakukannya. Beberapa insinyur terkemuka melakukan hal ini, tetapi tidak selalu karena prosesnya tidak dijelaskan di mana pun. - Prosedurnya harus sederhana dan mudah dimengerti.
Sulit bagi seseorang untuk mengingat banyak langkah. Status tetangga yang paling penting di Jira harus ditempatkan di layar utama. Anda dapat mengganti namanya, misalnya kami menyebutnya Sedang Berlangsung Siap untuk berubah. Dan status lainnya dapat disembunyikan di menu drop-down agar tidak merusak pemandangan. Namun lebih baik tidak membatasi orang, untuk memberi mereka kesempatan melakukan transisi.
Jelaskan nilai inovasi. Ketika masyarakat memahami, mereka lebih menerima prosedur baru tersebut. Sangat penting bagi kami agar orang-orang tidak mengikuti keseluruhan proses, namun mengikutinya. Lalu kami membangun otomatisasi untuk hal ini. - Tunggu, analisis, cari tahu.
Kami membutuhkan waktu sekitar satu bulan untuk menyusun prosedur, teknis pelaksanaan, pertemuan dan diskusi. Dan implementasinya memakan waktu lebih dari tiga bulan. Saya melihat bagaimana masyarakat secara perlahan mulai menggunakan inovasi tersebut. Ada banyak hal negatif pada tahap awal. Tapi itu sepenuhnya independen dari prosedur itu sendiri dan teknis pelaksanaannya. Misalnya, seorang administrator tidak menggunakan Jira, tetapi plugin Jira di Confluence, dan beberapa hal tidak tersedia untuknya. Kami menunjukkan kepadanya Jira, dan produktivitas admin meningkat baik untuk tugas umum maupun untuk mengganti disk.
Otomatisasi penggantian disk
Kami mendekati otomatisasi penggantian disk beberapa kali. Kami sudah memiliki pengembangan dan skrip, tetapi semuanya bekerja secara interaktif atau manual dan memerlukan peluncuran. Dan hanya setelah memperkenalkan prosedur baru barulah kami menyadari bahwa inilah tepatnya yang kami lewatkan.
Karena sekarang proses penggantian kami dibagi menjadi beberapa tahap, yang masing-masing memiliki pelaku tertentu dan daftar tindakan, kami dapat mengaktifkan otomatisasi secara bertahap, dan tidak sekaligus. Misalnya, tahap paling sederhana - Siap (memeriksa RAID/sinkronisasi data) dapat dengan mudah didelegasikan ke bot. Ketika bot telah belajar sedikit, Anda dapat memberinya tugas yang lebih penting - memutar disk, dll.
Pengaturan kebun binatang
Sebelum kita berbicara tentang bot, mari kita melihat sekilas ke kebun binatang instalasi kita. Pertama-tama, hal ini disebabkan oleh besarnya infrastruktur kita. Kedua, kami mencoba memilih konfigurasi perangkat keras yang optimal untuk setiap layanan. Kami memiliki sekitar 20 model RAID perangkat keras, sebagian besar LSI dan Adaptec, tetapi ada juga HP dan DELL dengan versi berbeda. Setiap pengontrol RAID memiliki utilitas manajemennya sendiri. Kumpulan perintah dan penerbitannya mungkin berbeda dari versi ke versi untuk setiap pengontrol RAID. Jika HW-RAID tidak digunakan, mdraid dapat digunakan.
Kami melakukan hampir semua instalasi baru tanpa cadangan disk. Kami mencoba untuk tidak lagi menggunakan RAID perangkat keras dan perangkat lunak, karena kami mencadangkan sistem kami di tingkat pusat data, bukan di server. Namun tentunya banyak server lawas yang perlu didukung.
Di suatu tempat disk di pengontrol RAID ditransfer ke perangkat mentah, di suatu tempat JBOD digunakan. Ada konfigurasi dengan satu disk sistem di server, dan jika perlu diganti, maka Anda harus menginstal ulang server dengan instalasi OS dan aplikasi, versi yang sama, kemudian menambahkan file konfigurasi, meluncurkan aplikasi. Ada juga banyak grup server di mana pencadangan dilakukan bukan pada tingkat subsistem disk, tetapi langsung di aplikasi itu sendiri.
Secara total, kami memiliki lebih dari 400 grup server unik yang menjalankan hampir 100 aplikasi berbeda. Untuk mencakup begitu banyak pilihan, kami memerlukan alat otomatisasi multifungsi. Sebaiknya dengan DSL yang sederhana, sehingga tidak hanya orang yang menulisnya saja yang dapat mendukungnya.
Kami memilih Ansible karena tidak memiliki agen: tidak perlu menyiapkan infrastruktur, memulai dengan cepat. Selain itu, ditulis dengan Python, yang diterima sebagai standar dalam tim.
Skema umum
Mari kita lihat skema otomasi umum dengan menggunakan satu insiden sebagai contoh. Zabbix mendeteksi bahwa disk sdb telah gagal, pemicunya menyala, dan tiket dibuat di Jira. Administrator melihatnya, menyadari bahwa itu bukan duplikat atau positif palsu, yaitu disk perlu diubah, dan mentransfer tiket ke Sedang Berlangsung.
Aplikasi DiskoBot, yang ditulis dengan Python, secara berkala melakukan polling pada Jira untuk mendapatkan tiket baru. Ia memperhatikan bahwa tiket Sedang berlangsung baru telah muncul, utas terkait dipicu, yang meluncurkan buku pedoman di Ansible (ini dilakukan untuk setiap status di Jira). Dalam hal ini, Prepare2change diluncurkan.
Ansible dikirim ke host, mengeluarkan disk dari rotasi dan melaporkan statusnya ke aplikasi melalui Callback.
Berdasarkan hasilnya, bot secara otomatis mentransfer tiket ke Siap diubah. Insinyur menerima pemberitahuan dan pergi untuk mengganti disk, setelah itu dia mentransfer tiket ke Berubah.
Menurut skema yang dijelaskan di atas, tiket kembali ke bot, yang meluncurkan buku pedoman lain, pergi ke host dan memutar disk. Bot menutup tiket. Hore!
Sekarang mari kita bicara tentang beberapa komponen sistem.
Diskobot
Aplikasi ini ditulis dengan Python. Ia memilih tiket dari Jira menurut JQL. Bergantung pada status tiket, yang terakhir pergi ke pengendali yang sesuai, yang pada gilirannya meluncurkan buku pedoman Ansible yang sesuai dengan status tersebut.
JQL dan interval polling ditentukan dalam file konfigurasi aplikasi.
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
Misalnya, di antara tiket dalam status Sedang diproses, hanya tiket dengan kolom Ukuran disk dan Nama perangkat yang terisi yang dipilih. Nama perangkat adalah nama perangkat blok yang diperlukan untuk menjalankan pedoman. Ukuran disk diperlukan agar teknisi mengetahui berapa ukuran disk yang dibutuhkan.
Dan di antara tiket dengan status Ready, tiket dengan label dbot_ignore disaring. Omong-omong, kami menggunakan label Jira untuk memfilter dan menandai tiket duplikat serta mengumpulkan statistik.
Jika sebuah playbook gagal, Jira memberikan label dbot_failed agar dapat disortir nanti.
Interoperabilitas dengan Ansible
Aplikasi berkomunikasi dengan Ansible melalui . Ke playbook_executor kami meneruskan nama file dan sekumpulan variabel. Hal ini memungkinkan Anda untuk menyimpan proyek Ansible dalam bentuk file yml biasa, daripada mendeskripsikannya dalam kode Python.
Juga di Ansible, melalui *extra_vars*, nama perangkat blok, status tiket, serta callback_url, yang berisi kunci masalah - digunakan untuk panggilan balik dalam HTTP.
Untuk setiap peluncuran, inventaris sementara dibuat, terdiri dari satu host dan grup tempat host tersebut berada, sehingga group_vars diterapkan.
Berikut adalah contoh tugas yang mengimplementasikan panggilan balik HTTP.
Kami mendapatkan hasil dari mengeksekusi playbook menggunakan callaback. Mereka terdiri dari dua jenis:
- , ini menyediakan data tentang hasil eksekusi pedoman. Ini menggambarkan tugas yang diluncurkan, berhasil atau tidak berhasil diselesaikan. Callback ini dipanggil ketika playbook telah selesai diputar.
- Panggilan balik HTTP untuk menerima informasi saat memainkan buku pedoman. Dalam tugas Ansible kami menjalankan permintaan POST/GET ke aplikasi kami.
Variabel diteruskan melalui panggilan balik HTTP yang ditentukan selama eksekusi playbook dan yang ingin kita simpan dan gunakan dalam proses selanjutnya. Kami menulis data ini dalam sqlite.
Kami juga meninggalkan komentar dan mengubah status tiket melalui panggilan balik HTTP.
Panggilan balik 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
Seperti banyak tugas sejenis lainnya, kami memasukkannya ke dalam file umum yang terpisah dan menyertakannya jika perlu, agar tidak terus-menerus mengulanginya di buku pedoman. Ini termasuk url callback_, yang berisi kunci masalah dan nama host. Ketika Ansible menjalankan permintaan POST ini, bot memahami bahwa itu terjadi sebagai bagian dari insiden ini dan itu.
Dan berikut adalah contoh dari playbook, di mana kita mengeluarkan disk dari perangkat 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
Tugas ini mentransfer tiket Jira ke status “Siap berubah” dan menambahkan komentar. Selain itu, variabel mdam_data menyimpan daftar perangkat md yang disknya telah dihapus, dan parted_info menyimpan dump partisi dari parted.
Saat insinyur memasukkan disk baru, kita dapat menggunakan variabel ini untuk memulihkan dump partisi, serta memasukkan disk ke perangkat md yang telah dihapus.
Mode pemeriksaan yang memungkinkan
Mengaktifkan otomatisasi itu menakutkan. Oleh karena itu, kami memutuskan untuk menjalankan semua pedoman dalam mode tersebut
, di mana Ansible tidak melakukan tindakan apa pun di server, tetapi hanya mengemulasikannya.
Peluncuran tersebut dijalankan melalui modul panggilan balik terpisah, dan hasil eksekusi playbook disimpan di Jira sebagai komentar.
Pertama, hal ini memungkinkan untuk memvalidasi kerja bot dan buku pedoman. Kedua, hal ini meningkatkan kepercayaan administrator terhadap bot.
Ketika kami melewati validasi dan menyadari bahwa Anda dapat menjalankan Ansible tidak hanya dalam mode uji coba, kami membuat tombol Jalankan Diskobot di Jira untuk meluncurkan buku pedoman yang sama dengan variabel yang sama pada host yang sama, tetapi dalam mode normal.
Selain itu, tombol tersebut digunakan untuk memulai ulang playbook jika mengalami crash.
Struktur buku pedoman
Saya telah menyebutkan bahwa bergantung pada status tiket Jira, bot meluncurkan buku pedoman yang berbeda.
Pertama, lebih mudah mengatur pintu masuk.
Kedua, dalam beberapa kasus hal ini hanya diperlukan.
Misalnya, saat mengganti disk sistem, pertama-tama Anda harus masuk ke sistem penerapan, membuat tugas, dan setelah penerapan yang benar, server akan dapat diakses melalui ssh, dan Anda dapat meluncurkan aplikasi ke dalamnya. Jika kami melakukan semua ini dalam satu buku pedoman, maka Ansible tidak akan dapat menyelesaikannya karena host tidak tersedia.
Kami menggunakan peran yang mungkin untuk setiap grup server. Di sini Anda dapat melihat bagaimana pedoman disusun dalam salah satu pedoman tersebut.
Ini nyaman karena langsung jelas di mana tugas-tugas tersebut berada. Di main.yml, yang merupakan input untuk peran Ansible, kita cukup memasukkan berdasarkan status tiket atau tugas umum yang diperlukan untuk semua orang, misalnya melewati identifikasi atau menerima token.
investigasi.yml
Berlaku untuk tiket dalam status Investigasi dan Terbuka. Hal terpenting untuk pedoman ini adalah nama perangkat blok. Informasi ini tidak selalu tersedia.
Untuk mendapatkannya, kami menganalisis ringkasan Jira, nilai terakhir dari pemicu Zabbix. Ini mungkin berisi nama perangkat blok - beruntung. Atau mungkin berisi titik pemasangan, maka Anda harus pergi ke server, menguraikannya dan menghitung disk yang diperlukan. Pemicunya juga dapat mengirimkan alamat scsi atau informasi lainnya. Tetapi kebetulan juga tidak ada petunjuk, dan Anda harus menganalisisnya.
Setelah mengetahui nama perangkat blok, kami mengumpulkan informasi tentang jenis dan ukuran disk dari perangkat tersebut untuk mengisi kolom di Jira. Kami juga menghapus informasi tentang vendor, model, firmware, ID, SMART, dan memasukkan semua ini ke dalam komentar di tiket Jira. Administrator dan teknisi tidak perlu lagi mencari data ini. 🙂
persiapkan2perubahan.yml
Melepaskan disk dari rotasi, bersiap untuk penggantian. Tahap yang paling sulit dan penting. Di sinilah Anda dapat menghentikan aplikasi pada saat yang tidak seharusnya dihentikan. Atau mengeluarkan disk yang tidak memiliki cukup replika, sehingga berdampak pada pengguna, kehilangan sebagian data. Di sini kami memiliki pemeriksaan dan notifikasi terbanyak dalam obrolan.
Dalam kasus paling sederhana, kita berbicara tentang menghapus disk dari RAID HW/MD.
Dalam situasi yang lebih kompleks (dalam sistem penyimpanan kami), ketika pencadangan dilakukan di tingkat aplikasi, Anda perlu membuka aplikasi melalui API, melaporkan keluaran disk, menonaktifkannya, dan memulai pemulihan.
Kami sekarang bermigrasi secara massal ke , dan jika servernya berbasis cloud, maka Diskobot akan memanggil API cloud, mengatakan bahwa ia akan bekerja dengan minion ini - server yang menjalankan container - dan meminta "migrasikan semua container dari minion ini". Dan pada saat yang sama, menyalakan lampu latar disk sehingga teknisi dapat segera melihat mana yang perlu ditarik keluar.
berubah.yml
Setelah mengganti disk, kami memeriksa ketersediaannya terlebih dahulu.
Insinyur tidak selalu memasang drive baru, jadi kami menambahkan tanda centang untuk nilai SMART yang memuaskan kami.
Atribut apa yang kita lihat?Jumlah Sektor yang Dialokasikan Kembali (5) < 100
Jumlah Sektor Tertunda Saat Ini (107) == 0
Jika drive gagal dalam pengujian, teknisi akan diberitahu untuk menggantinya lagi. Jika semuanya beres, lampu latar mati, penandaan diterapkan dan disk diputar.
siap.yml
Kasus paling sederhana: memeriksa sinkronisasi serangan HW/SW atau menyelesaikan sinkronisasi data dalam aplikasi.
API Aplikasi
Saya telah menyebutkan beberapa kali bahwa bot sering mengakses API aplikasi. Tentu saja tidak semua aplikasi memiliki metode yang diperlukan, sehingga harus dimodifikasi. Berikut adalah metode terpenting yang kami gunakan:
- Status. Status cluster atau disk untuk memahami apakah dapat digunakan;
- Mulai berhenti. Aktivasi/penonaktifan disk;
- Migrasi/pulihkan. Migrasi dan pemulihan data selama dan setelah penggantian.
Pelajaran dari Ansible
Saya sangat menyukai Ansible. Namun seringkali, ketika saya melihat berbagai proyek sumber terbuka dan melihat bagaimana orang menulis buku pedoman, saya menjadi sedikit takut. Jalinan logis yang kompleks ketika/loop, kurangnya fleksibilitas dan idempotensi karena seringnya penggunaan shell/perintah.
Kami memutuskan untuk menyederhanakan segalanya sebanyak mungkin, memanfaatkan keunggulan Ansible - modularitas. Di tingkat tertinggi ada pedoman; mereka dapat ditulis oleh administrator mana pun, pengembang pihak ketiga yang mengetahui sedikit Ansible.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Jika beberapa logika sulit diterapkan dalam buku pedoman, kami memindahkannya ke modul atau filter Ansible. Skrip dapat ditulis dengan Python atau bahasa lainnya.
Mereka mudah dan cepat untuk ditulis. Misalnya, modul lampu latar disk, contohnya ditunjukkan di atas, terdiri dari 265 baris.
Di tingkat paling bawah adalah perpustakaan. Untuk proyek ini, kami menulis aplikasi terpisah, semacam abstraksi atas RAID perangkat keras dan perangkat lunak yang menjalankan permintaan terkait.
Kekuatan terbesar Ansible adalah kesederhanaan dan pedoman yang jelas. Saya yakin Anda perlu menggunakan ini dan tidak membuat file yaml yang menakutkan dan sejumlah besar kondisi, kode shell, dan loop.
Jika Anda ingin mengulangi pengalaman kami dengan Ansible API, ingatlah dua hal:
- Playbook_executor dan playbook secara umum tidak dapat diberikan batas waktu. Ada batas waktu pada sesi ssh, tetapi tidak ada batas waktu pada playbook. Jika kami mencoba meng-unmount disk yang sudah tidak ada di sistem, playbook akan berjalan tanpa henti, jadi kami harus membungkus peluncurannya dalam pembungkus terpisah dan mematikannya dengan batas waktu.
- Ansible berjalan pada proses bercabang, jadi API-nya tidak aman untuk thread. Kami menjalankan semua pedoman kami secara single-thread.
Hasilnya, kami dapat mengotomatiskan penggantian sekitar 80% disk. Secara keseluruhan, tingkat penggantian meningkat dua kali lipat. Saat ini, administrator hanya melihat kejadian tersebut dan memutuskan apakah disk perlu diubah atau tidak, lalu melakukan satu klik.
Namun sekarang kami mulai mengalami masalah lain: beberapa administrator baru tidak tahu cara mengganti drive. 🙂
Sumber: www.habr.com