Versi firmware manakah yang paling “benar” dan “berfungsi”? Jika sistem penyimpanan menjamin toleransi kesalahan sebesar 99,9999%, apakah itu berarti sistem tersebut akan berfungsi tanpa gangguan bahkan tanpa pembaruan perangkat lunak? Atau sebaliknya, untuk mendapatkan toleransi kesalahan yang maksimal, Anda harus selalu menginstal firmware terbaru? Kami akan mencoba menjawab pertanyaan-pertanyaan ini berdasarkan pengalaman kami.
Pengenalan kecil
Kita semua memahami bahwa setiap versi perangkat lunak, baik itu sistem operasi atau driver untuk suatu perangkat, sering kali mengandung cacat/bug dan “fitur” lainnya yang mungkin tidak “muncul” hingga akhir masa pakai peralatan, atau “terbuka”. hanya dalam kondisi tertentu. Jumlah dan signifikansi nuansa tersebut bergantung pada kompleksitas (fungsionalitas) perangkat lunak dan kualitas pengujian selama pengembangannya.
Seringkali, pengguna tetap menggunakan "firmware dari pabrik" ("yang terkenal" berfungsi, jadi jangan main-main") atau selalu menginstal versi terbaru (dalam pemahaman mereka, yang terbaru berarti yang paling berfungsi). Kami menggunakan pendekatan yang berbeda - kami melihat catatan rilis untuk semua yang digunakan peralatan dan dengan hati-hati memilih firmware yang sesuai untuk setiap peralatan.
Kami sampai pada kesimpulan ini, seperti yang mereka katakan, berdasarkan pengalaman. Dengan menggunakan contoh pengoperasian kami, kami akan memberi tahu Anda mengapa keandalan sistem penyimpanan 99,9999% yang dijanjikan tidak berarti apa-apa jika Anda tidak segera memantau pembaruan dan deskripsi perangkat lunak. Kasing kami cocok untuk pengguna sistem penyimpanan dari vendor mana pun, karena situasi serupa dapat terjadi pada perangkat keras dari pabrikan mana pun.
Memilih Sistem Penyimpanan Baru
Pada akhir tahun lalu, sistem penyimpanan data yang menarik ditambahkan ke infrastruktur kami: model junior dari lini IBM FlashSystem 5000, yang pada saat pembelian disebut Storwize V5010e. Sekarang dijual dengan nama FlashSystem 5010, tetapi sebenarnya basis perangkat kerasnya sama dengan Spectrum Virtualize yang sama di dalamnya.
Kehadiran sistem manajemen terpadu merupakan perbedaan utama antara IBM FlashSystem. Untuk model seri yang lebih muda, praktis tidak ada bedanya dengan model yang lebih produktif. Pemilihan model tertentu hanya menyediakan basis perangkat keras yang sesuai, yang karakteristiknya memungkinkan penggunaan fungsi tertentu atau memberikan tingkat skalabilitas yang lebih tinggi. Perangkat lunak mengidentifikasi perangkat keras dan menyediakan fungsionalitas yang diperlukan dan memadai untuk platform ini.
IBM FlashSystem 5010
Secara singkat tentang model kami 5010. Ini adalah sistem penyimpanan blok pengontrol ganda tingkat pemula. Ini dapat menampung disk NLSAS, SAS, SSD. Penempatan NVMe tidak tersedia di dalamnya, karena model penyimpanan ini diposisikan untuk menyelesaikan masalah yang tidak memerlukan kinerja drive NVMe.
Sistem penyimpanan tersebut dibeli untuk menampung informasi arsip atau data yang jarang diakses. Oleh karena itu, rangkaian standar fungsinya sudah cukup bagi kami: Tiering (Easy Tier), Thin Provision. Performa pada disk NLSAS pada level 1000-2000 IOPS juga cukup memuaskan bagi kami.
Pengalaman kami - bagaimana kami tidak memperbarui firmware tepat waktu
Sekarang tentang pembaruan perangkat lunak itu sendiri. Pada saat pembelian, sistem sudah memiliki versi perangkat lunak Spectrum Virtualize yang agak ketinggalan jaman, yaitu, 8.2.1.3.
Kami mempelajari deskripsi firmware dan merencanakan pembaruan 8.2.1.9. Jika kami sedikit lebih efisien, artikel ini tidak akan ada - bug tidak akan terjadi pada firmware yang lebih baru. Namun karena alasan tertentu, pembaruan sistem ini ditunda.
Akibatnya, sedikit penundaan pembaruan menghasilkan gambaran yang sangat tidak menyenangkan, seperti dalam deskripsi di tautan: .
Ya, dalam firmware versi itu, apa yang disebut APAR (Laporan Analisis Program Resmi) HU02104 relevan. Nampaknya sebagai berikut. Saat dimuat, dalam keadaan tertentu, cache mulai meluap, kemudian sistem masuk ke mode perlindungan, yang menonaktifkan I/O untuk kumpulan. Dalam kasus kami, sepertinya melepaskan 3 disk untuk grup RAID dalam mode RAID 6. Pemutusan hubungan terjadi selama 6 menit. Selanjutnya, akses ke Volume di Pool dipulihkan.
Jika ada yang belum familiar dengan struktur dan penamaan entitas logis dalam konteks IBM Spectrum Virtualize, sekarang saya akan menjelaskannya secara singkat.
Struktur elemen logis sistem penyimpanan
Disk dikumpulkan ke dalam grup yang disebut MDisk (Disk Terkelola). MDisk dapat berupa RAID klasik (0,1,10,5,6) atau yang tervirtualisasi - DRAID (Distributed RAID). Menggunakan DRAID memungkinkan Anda meningkatkan kinerja array, karena... Semua disk dalam grup akan digunakan, dan waktu pembangunan kembali akan berkurang, karena hanya blok tertentu yang perlu dipulihkan, dan tidak semua data dari disk yang gagal.
Distribusi blok data di seluruh disk saat menggunakan RAID Terdistribusi (DRAID) dalam mode RAID-5.
Dan diagram ini menunjukkan logika cara kerja pembangunan kembali DRAID jika terjadi kegagalan satu disk:
Logika pembangunan kembali DRAID ketika satu disk gagal
Selanjutnya, satu atau lebih MDisk membentuk apa yang disebut Pool. Dalam kumpulan yang sama, tidak disarankan untuk menggunakan MDisk dengan tingkat RAID/DRAID berbeda pada disk dengan jenis yang sama. Kami tidak akan membahasnya terlalu dalam, karena... kami berencana untuk membahasnya di salah satu artikel berikut. Faktanya, Pool dibagi menjadi Volume, yang disajikan menggunakan satu atau beberapa protokol akses blok ke host.
Jadi, kita, sebagai akibat dari situasi yang dijelaskan dalam APAR HU02104, karena kegagalan logis dari tiga disk, MDisk tidak lagi berfungsi, yang, pada gilirannya, mengakibatkan kegagalan Kumpulan dan Volume terkait.
Karena sistem ini cukup pintar, maka dapat dihubungkan ke sistem pemantauan berbasis cloud IBM Storage Insights, yang secara otomatis mengirimkan permintaan layanan ke dukungan IBM jika terjadi masalah. Aplikasi dibuat dan spesialis IBM melakukan diagnosa dari jarak jauh dan menghubungi pengguna sistem.
Berkat ini, masalah ini teratasi dengan cukup cepat dan rekomendasi cepat diterima dari layanan dukungan untuk memperbarui sistem kami ke firmware yang dipilih sebelumnya 8.2.1.9, yang pada saat itu telah diperbaiki. Ini menegaskan .
Hasil dan rekomendasi kami
Seperti kata pepatah: “semuanya baik-baik saja, itu berakhir dengan baik.” Bug pada firmware tidak menyebabkan masalah serius - server dipulihkan sesegera mungkin dan tanpa kehilangan data. Beberapa klien harus memulai ulang mesin virtual, namun secara umum kami siap menghadapi konsekuensi yang lebih negatif, karena kami membuat cadangan harian untuk semua elemen infrastruktur dan mesin klien.
Kami telah menerima konfirmasi bahwa bahkan sistem yang andal dengan ketersediaan yang dijanjikan 99,9999% memerlukan perhatian dan pemeliharaan tepat waktu. Berdasarkan situasinya, kami telah menarik sejumlah kesimpulan dan membagikan rekomendasi kami:
-
Sangat penting untuk memantau rilis pembaruan, mempelajari Catatan Rilis untuk koreksi potensi masalah kritis, dan melaksanakan pembaruan terencana pada waktu yang tepat.
Ini adalah masalah organisasi dan bahkan cukup jelas, yang tampaknya tidak layak untuk difokuskan. Namun, pada “dataran datar” ini Anda dapat tersandung dengan mudah. Sebenarnya momen inilah yang menambah masalah yang dijelaskan di atas. Berhati-hatilah saat menyusun peraturan pembaruan dan pantau kepatuhannya dengan cermat. Poin ini lebih berkaitan dengan konsep “disiplin”.
-
Itu selalu lebih baik untuk menjaga sistem dengan versi perangkat lunak terbaru. Selain itu, yang sekarang bukanlah yang memiliki sebutan numerik lebih besar, melainkan yang memiliki tanggal rilis lebih lambat.
Misalnya, IBM selalu memperbarui setidaknya dua rilis perangkat lunak untuk sistem penyimpanannya. Pada saat penulisan ini, ini adalah 8.2 dan 8.3. Pembaruan untuk 8.2 keluar lebih awal. Pembaruan serupa untuk 8.3 biasanya dirilis dengan sedikit penundaan.
Rilis 8.3 memiliki sejumlah keunggulan fungsional, misalnya kemampuan untuk memperluas MDisk (dalam mode DRAID) dengan menambahkan satu atau lebih disk baru (fitur ini telah muncul sejak versi 8.3.1). Ini adalah fungsionalitas yang cukup mendasar, tetapi sayangnya di 8.2, tidak ada fitur seperti itu.
-
Jika pembaruan tidak dapat dilakukan karena alasan tertentu, maka untuk versi perangkat lunak Spectrum Virtualize sebelum versi 8.2.1.9 dan 8.3.1.0 (jika bug yang dijelaskan di atas relevan), untuk mengurangi risiko kemunculannya, dukungan teknis IBM merekomendasikan membatasi kinerja sistem di tingkat kumpulan, seperti yang ditunjukkan pada gambar di bawah (gambar diambil dalam GUI versi Russified). Nilai 10000 IOPS ditampilkan sebagai contoh dan dipilih sesuai dengan karakteristik sistem Anda.
Membatasi kinerja penyimpanan IBM
-
Penting untuk menghitung beban pada sistem penyimpanan dengan benar dan menghindari kelebihan beban. Untuk melakukan ini, Anda dapat menggunakan sizer IBM (jika Anda memiliki akses ke sana), atau bantuan mitra, atau sumber daya pihak ketiga. Sangat penting untuk memahami profil beban pada sistem penyimpanan, karena Performa dalam MB/s dan IOPS sangat bervariasi bergantung pada setidaknya parameter berikut:
-
jenis operasi: baca atau tulis,
-
ukuran blok operasi,
-
persentase operasi baca dan tulis dalam total aliran I/O.
Selain itu, kecepatan operasi dipengaruhi oleh cara blok data dibaca: secara berurutan atau acak. Saat melakukan beberapa operasi akses data di sisi aplikasi, terdapat konsep operasi dependen. Dianjurkan juga untuk mempertimbangkan hal ini. Semua ini dapat membantu untuk melihat totalitas data dari penghitung kinerja OS, sistem penyimpanan, server/hypervisor, serta pemahaman tentang fitur pengoperasian aplikasi, DBMS, dan “konsumen” sumber daya disk lainnya.
-
-
Dan terakhir, pastikan cadangan Anda mutakhir dan berfungsi. Jadwal pencadangan harus dikonfigurasi berdasarkan nilai RPO yang dapat diterima untuk bisnis, dan pemeriksaan integritas berkala atas pencadangan harus diverifikasi (beberapa vendor perangkat lunak pencadangan menerapkan verifikasi otomatis di produk mereka) untuk memastikan nilai RTO yang dapat diterima.
Terima kasih telah membaca sampai akhir.
Kami siap menjawab pertanyaan dan komentar Anda di kolom komentar. Juga, di mana kami mengadakan promosi rutin (diskon IaaS dan hadiah kode promosi hingga 100% di VPS), menulis berita menarik dan mengumumkan artikel baru di blog Habr.
Sumber: www.habr.com