Seseorang akan segera jatuhKarena SHD menyimpan data maha kudus. Jika data tidak lagi tersedia, itu akan segera digoreng. Atau jika tiba-tiba tempat itu selesai - juga kejutan yang tidak menyenangkan. Karena itu, pemantauan harus bersifat wajib, dan harus mencakup sistem penyimpanan.
Ada dua pendekatan utama untuk
memantau penyimpanan . Baik menggunakan sistem pemantauan universal seperti Nagios, Icinga, yang akan mengumpulkan informasi melalui SNMP, atau membeli perangkat lunak yang sangat khusus dari produsen sistem penyimpanan itu sendiri. Tentu saja, opsi kedua menyediakan analisis yang lebih dalam tentang kondisi besi, menunjukkan hal-hal spesifik seperti keadaan cache, iops, hit rate, memuat pengontrol, dll. Ini adalah opsi yang paling sering dipilih oleh pelanggan kami, yang memiliki array besar dan mahal dalam layanan. .
Namun omong-omong, tidak semuanya lancar dengan perangkat lunak pemantauan komersial. Secara lebih rinci saya akan menceritakan lebih lanjut. Jadi, bisa dikatakan, pengalaman langsung. Pada suatu waktu, selama hampir 2 tahun saya menyelesaikan satu sistem seperti itu untuk ribuan kertas hijau dari vendor terkenal. Dan dia mengambilnya sehingga bahkan dukungan dari vendor mulai berkonsultasi dengan saya. Tetapi beberapa masalah perangkat lunak digantikan oleh yang lain, sama seperti beberapa orang India dari dukungan digantikan oleh orang-orang India yang baru - dan saat itulah saya mendapat ide, jika tidak bertindak radikal sama sekali ... Secara umum, semuanya dimulai dengan ini.
Apa yang salah dengan perangkat lunak vendor?
Seperti yang saya katakan, pemantauan dari pabrikan dengan sempurna memonitor sistem penyimpanan dari pabrikan yang sama. Inilah keunggulan utamanya. Kerugian tumbuh dari sini: susunan pabrikan lain didukung secara terbatas atau tidak sama sekali. Ternyata jika Anda memiliki beberapa larik berbeda di tambak, maka Anda memerlukan beberapa alat pemantauan yang berbeda. Ya, dan jangan lupa yang mana dan kapan Anda perlu melihatnya lain kali. Idealnya, umumnya oleh admin untuk setiap larik.
Bukan rahasia lagi bahwa alat dari produsen vendor membutuhkan biaya, dan cukup besar. Dan perpanjangan dukungan itu juga membutuhkan biaya yang sangat kecil. Dan beberapa vendor telah menguasai fokus baru: mereka mengumumkan akhir dari siklus hidup perangkat lunak mereka dan menawarkan hanya untuk membeli produk lain, tanpa migrasi lisensi. Pengaturan seperti itu yang baru saja terjadi beberapa bulan yang lalu dengan salah satu pelanggan kami. Tidak ada opsi: jika Anda ingin terus memantau perangkat keras - lakukan pembelian baru.
Jika Anda menggali perangkat lunak vendor lebih dalam, fitur-fitur tidak menyenangkan lainnya akan muncul. Misalnya, dalam sejumlah produk Anda dapat melihat gambar status saat ini, tetapi Anda tidak dapat melihat riwayat untuk periode sebelumnya. Atau cerita terbatas: log ditulis ulang setiap 3 hari sekali. Sama sekali tidak perlu berbicara tentang akumulasi statistik. Dan seringkali sejarah peristiwa diperlukan untuk prakiraan, misalnya, pembelian suku cadang, dan untuk pelaporan, dan untuk menyelidiki insiden. Misalnya, rem di beberapa sistem bisnis dapat dimasukkan ke sistem penyimpanan dan, jika tidak ada data aktual, tidak ada yang disembunyikan di belakang.
Dan akhirnya, orang tidak bisa tidak mengeluh tentang kecepatan pembaruan dan perubahan dalam perangkat lunak vendor. Oh, betapa sering saya menemukan masalah ini untuk latihan panjang saya! Model-model array baru keluar, firmware baru keluar, pengaturan baru muncul. Semua ini dengan mudah mematahkan pemantauan kerja: entah semacam infa berhenti dikumpulkan, atau array umumnya jatuh. Dalam mikrokode baru, pabrikan mematikan dukungan untuk versi SSL lama, dan perangkat lunak pemantauan belum mendukung protokol TLS. Dan pada awalnya tidak ada yang bisa menemukan alasannya. Setelah penyelidikan saya sendiri, saya mengirim input ini ke pabrik, dan mereka sudah memperbarui perpustakaan kuno. Namun, semua birokrasi ini berlangsung tanpa batas.
Dan begitu kami gagal pilot di pelanggan. Diusulkan untuk menggunakan perangkat lunak vendor, dan pelanggan menyukai semuanya dalam hal fungsionalitas dan antarmuka. Namun sayangnya, sistem produktif utama mereka tidak didukung. Mereka bahkan siap menunggu satu atau dua bulan, tetapi vendor mengatakan bahwa tidak ada rencana untuk memasukkan sistem ini dalam dukungan dalam waktu dekat (dan ini hanya pembaruan dari garis AMS Hitachi pada HUS).
Secara umum, cukup banyak ketidaknyamanan dan untuk beberapa alasan banyak uang.
Dahulu kala saya tidak mengambil catur ...
Frustrasi oleh keadaan ini, saya sering berpikir tentang bagaimana menerapkan pemantauan saya sendiri untuk penyimpanan. Jika Anda mengetahui array dengan baik dan memiliki CLI-nya, maka Anda dapat dengan cepat mendapatkan informasi yang Anda butuhkan tentang keadaan atau sampai ke bagian bawah masalah. Tentu saja, sebelum ini, perlu menyekop banyak dermaga, forum asap dan basis pengetahuan vendor, sedikit demi sedikit informasi yang berbeda. Tetapi ketika Anda tahu perintah mana yang harus diketik dengan kunci apa dan apa artinya setiap kolom output, Anda sudah menjadi seorang guru. Tetap membangun pengetahuan ini menjadi antarmuka yang nyaman, yang akan terus melakukan segalanya untuk Anda.
Saya akui bahwa pada awalnya saya berencana untuk menulis antarmuka dari awal juga, tetapi kemudian saya menemukan Zabbix - alat yang matang dengan komunitas besar, yang juga mudah diperluas. Itu memiliki semua yang saya butuhkan: antarmuka, model peran, pemberitahuan, sistem pemicu, agen klien proxy. Hanya tetap untuk penggabungan ini untuk memberikan informasi yang benar tentang sistem penyimpanan dan nilai ambang batas dari berbagai parameter. Kasingnya mulai mendidih. Kami memiliki tim spesialis dalam array. Tentu saja, tidak mungkin mengetahui semua array oleh satu orang, jadi kami dibagi berdasarkan model dan pabrikan.
Kesulitan lain dalam mengembangkan pemantauan Anda sendiri adalah kemampuan untuk mengakses potongan-potongan besi itu sendiri dan sehingga mereka masih tidak takut untuk memuat, menghancurkan, dan melakukan semua jenis eksperimen. Untungnya, sumber daya laboratorium kami memungkinkan semua ini.
Hal pertama yang harus dipantau adalah kesehatan semua komponen perangkat keras. Sesuatu dapat diambil melalui SNMP, tetapi dalam kebanyakan kasus ini adalah survei menggunakan protokol khusus (SMI-S, REST API, SOAP API, dan lainnya). Saya harus mengatakan bahwa array itu sendiri memungkinkan Anda untuk mengkonfigurasi notifikasi tentang gangguan pada mereka. Dan setidaknya semua pelanggan menggunakan ini. Tetapi apa yang terjadi jika notifikasi itu sendiri pada array rusak? Ini terjadi, dan lebih dari sekali, ketika array diam selama berminggu-minggu dan bagi semua orang tampaknya semuanya beres, itu diam. Dan kemudian tiba-tiba menjadi jelas bahwa sejumlah disk kritis terbang di atasnya, tetapi sudah terlambat.
Poin penting kedua untuk memantau adalah kinerja. Karena ketika kinerja mengacu pada sistem penyimpanan dengan penundaan rekaman beberapa detik, Oracle dapat naik dan turun. Tidak tahu Ini adalah kinerja dalam infrastruktur besar dengan banyak sistem penyimpanan yang paling buruk dikendalikan. Dan Zabbix memiliki analisis prediktif yang sangat nyaman: berdasarkan perkiraan, Anda dapat mengatur nilai metrik, yang akan menjadi di masa depan. Misalnya, kami membuat pemicu yang akan berfungsi jika ada perkiraan bahwa hanya akan tersisa 3 bulan untuk pembuangan saat ini. Atau, misalnya, bahwa waktu respons menurut perkiraan dalam 2 minggu akan lebih dari 50 milidetik. Pemantauan memberi kita waktu untuk belajar tentang masalah yang akan datang di muka dan untuk melakukan sesuatu.
Pada titik tertentu, kami menyadari bahwa mengetahui keadaan penyimpanan itu baik, tentu saja, tetapi jauh lebih baik untuk memahami apa lagi yang terjadi di jaringan dan di sisi server. Akibatnya, setelah beberapa bulan bekerja, menjadi mungkin untuk melihat server, jaringan, dan sistem penyimpanan dalam satu antarmuka. Tidak hanya plug-in dan konektor untuk penyimpanan muncul, tetapi juga ikatan yang berguna dalam bentuk peta topologi jaringan. Sejauh ini, tentu saja, plugin memperhitungkan pengalaman dan kebutuhan kami, tetapi jika Anda memberi tahu kami apa yang perlu Anda lihat di dalamnya, kami akan mengubahnya.
Topologi End-to-End untuk VMware Cluster: Dari Mesin Virtual ke Volume Penyimpanan
PerformaPada grafik kinerja array, kita melihat bahwa sistem sangat kelebihan beban. Pemanfaatan tinggi grup disk menunjukkan bahwa disk kelebihan beban. Ada banyak operasi I / O pada port penyimpanan, yang berarti bahwa sistem TI memuat array untuk bagian mereka. Nah, grafik karakteristik waktu respons, serta pemanfaatan prosesor di atas nilai yang disarankan. Putusan - terlalu banyak tugas diletakkan pada array, beberapa dari mereka harus dimigrasi.
Peta Jaringan Penyimpanan: Menemukan KemacetanRingkasan
Apa yang kita dapatkan? Kami telah melengkapi sistem pemantauan Zabbix yang populer dan sangat umum dengan fitur-fitur baru, termasuk:
- Pengumpulan informasi tentang status semua perangkat keras dan komponen logis dari larik disk dan sakelar jaringan penyimpanan.
- Statistik kinerja untuk mutlak semua sistem yang kami buatkan pengaya (vendor memiliki celah dalam hal ini).
- Peta topologi dari kedua jaringan penyimpanan bersama dan ujung ke ujung dari mesin virtual ke volume pada sistem penyimpanan (sejauh ini hanya untuk VMware).
- Pengumpulan semua informasi inventaris.
- Jumlah ruang disk.
Zabbix sendiri memungkinkan Anda untuk membuat notifikasi yang sangat keren, menetapkan ambang batas, mengirim surat informatif tentang masalah tersebut. Misalnya, jika port pada sakelar jatuh (atau lalu lintas pada port menjadi sangat besar), pesan tidak hanya akan berisi nama sakelar dengan nomor port, tetapi juga informasi tentang perangkat yang terhubung.
Sistem apa yang saat ini kami dukung? Banyak perbedaan:
- Semua array Hitachi (AMS, HUS, VSP, VSP G).
- Array Dell-EMC CLARiiON, VNX, Unity, ISILON, Compellent.
- Array HPE 3PAR, P9500, XP7.
- Susunan IBM Storwize, DS5000.
- Mengatur NetApp FAS (7-mode, c-mode).
- HPE StoreOnce, Perpustakaan Disk DataDomain EMC.
- Saklar Ulat Sutra Brocade, Cisco MDS.
Kami juga memiliki ekstensi untuk beberapa sistem operasi (Windows, ESX), yang dengannya kami mengumpulkan data tentang FC HBA untuk menggambar peta topologi di masa depan. Mengembangkan plugin untuk OpenStack dan sistem virtualisasi secara aktif.
Saat mengembangkan plug-in, keahlian teknisi kami diperhitungkan, di belakangnya ada banyak kasus untuk memecahkan masalah pada array - baik perangkat keras maupun kinerja. Plugin baru dikembangkan berdasarkan permintaan dalam waktu singkat karena banyaknya perpustakaan yang sudah jadi.
Beberapa pelanggan kami mengonfigurasi sistem sebagai berikut: pemberitahuan dengan nomor kontrak, orang yang dapat dihubungi dan semua parameter komponen yang salah secara otomatis dikirim ke email kami. Ini mengurangi waktu reaksi dan memesan suku cadang yang diperlukan, karena insinyur tugas tidak perlu menelepon dan mengklarifikasi banyak informasi - bahkan di malam hari. Aplikasi langsung berfungsi.
Bagaimana Anda mengatasi masalah pemantauan infrastruktur Anda, khususnya penyimpanan? Ceritakan pada kami di komentar atau di surat ke mail VRyzhevsky@croc.ru