Versi perisian tegar yang manakah paling "betul" dan "berfungsi"? Jika sistem storan menjamin toleransi kesalahan sebanyak 99,9999%, adakah ini bermakna ia akan berfungsi tanpa gangguan walaupun tanpa kemas kini perisian? Atau, sebaliknya, untuk mendapatkan toleransi kesalahan maksimum, anda harus sentiasa memasang perisian tegar terkini? Kami akan cuba menjawab soalan-soalan ini berdasarkan pengalaman kami.
Pengenalan kecil
Kita semua faham bahawa setiap versi perisian, sama ada sistem pengendalian atau pemacu untuk peranti, selalunya mengandungi kecacatan/pepijat dan "ciri" lain yang mungkin tidak "muncul" sehingga tamat hayat perkhidmatan peralatan, atau "terbuka" hanya dalam keadaan tertentu. Bilangan dan kepentingan nuansa tersebut bergantung pada kerumitan (fungsi) perisian dan pada kualiti ujian semasa pembangunannya.
Selalunya, pengguna kekal pada "perisian tegar dari kilang" (yang terkenal "ia berfungsi, jadi jangan main-main dengannya") atau sentiasa memasang versi terkini (dalam pemahaman mereka, yang terkini bermakna paling berkesan). Kami menggunakan pendekatan yang berbeza - kami melihat nota keluaran untuk semua yang digunakan peralatan dan berhati-hati memilih perisian tegar yang sesuai untuk setiap peralatan.
Kami sampai pada kesimpulan ini, seperti yang mereka katakan, dengan pengalaman. Menggunakan contoh operasi kami, kami akan memberitahu anda mengapa 99,9999% kebolehpercayaan sistem storan yang dijanjikan tidak bermakna jika anda tidak memantau kemas kini perisian dan penerangan dengan segera. Kes kami sesuai untuk pengguna sistem storan daripada mana-mana vendor, kerana situasi yang sama boleh berlaku dengan perkakasan daripada mana-mana pengeluar.
Memilih Sistem Storan Baharu
Pada penghujung tahun lepas, sistem storan data yang menarik telah ditambahkan pada infrastruktur kami: model junior daripada barisan IBM FlashSystem 5000, yang pada masa pembelian dipanggil Storwize V5010e. Kini ia dijual di bawah nama FlashSystem 5010, tetapi sebenarnya ia adalah pangkalan perkakasan yang sama dengan Spectrum Virtualize yang sama di dalamnya.
Kehadiran sistem pengurusan bersatu, dengan cara ini, perbezaan utama antara IBM FlashSystem. Untuk model siri yang lebih muda, ia boleh dikatakan tidak berbeza dengan model yang lebih produktif. Memilih model tertentu hanya menyediakan asas perkakasan yang sesuai, ciri-ciri yang membolehkan untuk menggunakan satu atau fungsi lain atau menyediakan tahap kebolehskalaan yang lebih tinggi. Perisian ini mengenal pasti perkakasan dan menyediakan fungsi yang diperlukan dan mencukupi untuk platform ini.
IBM FlashSystem 5010
Secara ringkas tentang model 5010 kami. Ini ialah sistem storan blok dwi-pengawal peringkat permulaan. Ia boleh memuatkan cakera NLSAS, SAS, SSD. Peletakan NVMe tidak tersedia di dalamnya, kerana model storan ini diletakkan untuk menyelesaikan masalah yang tidak memerlukan prestasi pemacu NVMe.
Sistem storan telah dibeli untuk menampung maklumat arkib atau data yang tidak diakses dengan kerap. Oleh itu, set standard fungsinya sudah memadai untuk kami: Tiering (Tier Mudah), Peruntukan Nipis. Prestasi pada cakera NLSAS pada tahap 1000-2000 IOPS juga agak memuaskan bagi kami.
Pengalaman kami - bagaimana kami tidak mengemas kini perisian tegar tepat pada masanya
Sekarang mengenai kemas kini perisian itu sendiri. Pada masa pembelian, sistem telah mempunyai versi perisian Spectrum Virtualize yang agak ketinggalan zaman, iaitu, 8.2.1.3.
Kami mengkaji perihalan perisian tegar dan merancang kemas kini kepada 8.2.1.9. Jika kami lebih cekap sedikit, artikel ini tidak akan wujud - pepijat tidak akan berlaku pada perisian tegar yang lebih terkini. Walau bagaimanapun, atas sebab-sebab tertentu, kemas kini sistem ini telah ditangguhkan.
Akibatnya, kelewatan kemas kini yang sedikit membawa kepada gambar yang sangat tidak menyenangkan, seperti dalam keterangan pada pautan: .
Ya, dalam perisian tegar versi itu apa yang dipanggil APAR (Laporan Analisis Program Dibenarkan) HU02104 adalah berkaitan. Ia kelihatan seperti berikut. Di bawah beban, dalam keadaan tertentu, cache mula melimpah, kemudian sistem masuk ke mod perlindungan, di mana ia melumpuhkan I/O untuk kolam. Dalam kes kami, ia kelihatan seperti memutuskan sambungan 3 cakera untuk kumpulan RAID dalam mod RAID 6. Pemutusan sambungan berlaku selama 6 minit. Seterusnya, akses kepada Jilid dalam Kolam dipulihkan.
Jika sesiapa yang tidak biasa dengan struktur dan penamaan entiti logik dalam konteks IBM Spectrum Virtualize, saya kini akan menerangkan secara ringkas.
Struktur elemen logik sistem storan
Cakera dikumpulkan ke dalam kumpulan yang dipanggil MDisk (Cakera Terurus). MDisk boleh menjadi RAID klasik (0,1,10,5,6) atau maya - DRAID (Distributed RAID). Menggunakan DRAID membolehkan anda meningkatkan prestasi tatasusunan, kerana... Semua cakera dalam kumpulan akan digunakan, dan masa membina semula akan dikurangkan, disebabkan fakta bahawa hanya blok tertentu perlu dipulihkan, dan bukan semua data dari cakera yang gagal.
Pengedaran blok data merentas cakera apabila menggunakan RAID Teragih (DRAID) dalam mod RAID-5.
Dan rajah ini menunjukkan logik bagaimana DRAID membina semula berfungsi sekiranya berlaku satu kegagalan cakera:
Logik DRAID membina semula apabila satu cakera gagal
Seterusnya, satu atau lebih MDisks membentuk apa yang dipanggil Pool. Dalam kumpulan yang sama, tidak disyorkan untuk menggunakan MDisk dengan tahap RAID/DRAID yang berbeza pada cakera jenis yang sama. Kami tidak akan membincangkan perkara ini secara mendalam, kerana... kami merancang untuk membincangkan perkara ini dalam salah satu artikel berikut. Sebenarnya, Pool dibahagikan kepada Jilid, yang dibentangkan menggunakan satu atau satu lagi protokol akses blok kepada hos.
Jadi, kami, akibat daripada situasi yang diterangkan dalam APAR HU02104, disebabkan oleh kegagalan logik tiga cakera, MDisk tidak lagi berfungsi, yang seterusnya, mengakibatkan kegagalan Pool dan Volume yang sepadan.
Oleh kerana sistem ini agak pintar, ia boleh disambungkan kepada sistem pemantauan berasaskan awan IBM Storage Insights, yang secara automatik menghantar permintaan perkhidmatan kepada sokongan IBM jika masalah berlaku. Aplikasi dibuat dan pakar IBM menjalankan diagnostik dari jauh dan menghubungi pengguna sistem.
Terima kasih kepada ini, isu ini telah diselesaikan dengan agak cepat dan pengesyoran segera diterima daripada perkhidmatan sokongan untuk mengemas kini sistem kami kepada perisian tegar 8.2.1.9 yang dipilih sebelum ini, yang pada masa itu telah pun dibetulkan. Ia mengesahkan .
Keputusan dan cadangan kami
Seperti kata pepatah: "semua baik yang berakhir dengan baik." Pepijat dalam perisian tegar tidak menyebabkan masalah serius - pelayan telah dipulihkan secepat mungkin dan tanpa kehilangan data. Sesetengah pelanggan terpaksa memulakan semula mesin maya, tetapi secara amnya kami bersedia untuk lebih banyak akibat negatif, kerana kami membuat sandaran harian semua elemen infrastruktur dan mesin pelanggan.
Kami telah menerima pengesahan bahawa sistem yang boleh dipercayai dengan 99,9999% ketersediaan yang dijanjikan memerlukan perhatian dan penyelenggaraan yang tepat pada masanya. Berdasarkan situasi itu, kami telah membuat beberapa kesimpulan untuk diri kami sendiri dan berkongsi cadangan kami:
-
Adalah penting untuk memantau keluaran kemas kini, mengkaji Nota Keluaran untuk pembetulan isu yang berpotensi kritikal dan melaksanakan kemas kini yang dirancang tepat pada masanya.
Ini adalah titik organisasi dan juga agak jelas, yang, nampaknya, tidak patut diberi tumpuan. Walau bagaimanapun, di "tanah rata" ini anda boleh tersandung dengan mudah. Sebenarnya, detik inilah yang menambahkan masalah yang diterangkan di atas. Berhati-hati semasa merangka peraturan kemas kini dan memantau pematuhannya dengan tidak kurang berhati-hati. Perkara ini lebih berkaitan dengan konsep "disiplin".
-
Adalah lebih baik untuk mengekalkan sistem dengan versi perisian terkini. Lebih-lebih lagi, yang semasa bukanlah yang mempunyai sebutan berangka yang lebih besar, tetapi yang mempunyai tarikh keluaran kemudian.
Sebagai contoh, IBM memastikan sekurang-kurangnya dua keluaran perisian dikemas kini untuk sistem storannya. Pada masa penulisan ini, ini adalah 8.2 dan 8.3. Kemas kini untuk 8.2 keluar lebih awal. Kemas kini serupa untuk 8.3 biasanya dikeluarkan dengan sedikit kelewatan.
Keluaran 8.3 mempunyai beberapa kelebihan fungsi, contohnya, keupayaan untuk mengembangkan MDisk (dalam mod DRAID) dengan menambah satu atau lebih cakera baharu (ciri ini telah muncul sejak versi 8.3.1). Ini adalah fungsi yang agak asas, tetapi dalam 8.2, malangnya, tiada ciri sedemikian.
-
Jika tidak mungkin untuk mengemas kini atas sebab tertentu, maka untuk versi perisian Spectrum Virtualize sebelum versi 8.2.1.9 dan 8.3.1.0 (di mana pepijat yang diterangkan di atas adalah berkaitan), untuk mengurangkan risiko kejadiannya, sokongan teknikal IBM mengesyorkan mengehadkan prestasi sistem pada peringkat kumpulan, seperti yang ditunjukkan dalam rajah di bawah (gambar diambil dalam versi Russified GUI). Nilai 10000 IOPS ditunjukkan sebagai contoh dan dipilih mengikut ciri sistem anda.
Mengehadkan prestasi storan IBM
-
Ia adalah perlu untuk mengira beban pada sistem storan dengan betul dan mengelakkan beban berlebihan. Untuk melakukan ini, anda boleh menggunakan sama ada saiz IBM (jika anda mempunyai akses kepadanya), atau bantuan rakan kongsi atau sumber pihak ketiga. Adalah penting untuk memahami profil beban pada sistem storan, kerana Prestasi dalam MB/s dan IOPS sangat berbeza bergantung pada sekurang-kurangnya parameter berikut:
-
jenis operasi: baca atau tulis,
-
saiz blok operasi,
-
peratusan operasi baca dan tulis dalam jumlah aliran I/O.
Selain itu, kelajuan operasi dipengaruhi oleh cara blok data dibaca: secara berurutan atau dalam susunan rawak. Apabila melakukan operasi capaian data berbilang pada bahagian aplikasi, terdapat konsep operasi bergantung. Ia juga dinasihatkan untuk mengambil kira perkara ini. Semua ini boleh membantu untuk melihat keseluruhan data daripada kaunter prestasi OS, sistem storan, pelayan/hypervisor, serta pemahaman tentang ciri pengendalian aplikasi, DBMS dan "pengguna" sumber cakera yang lain.
-
-
Dan akhirnya, pastikan anda mempunyai sandaran yang terkini dan berfungsi. Jadual sandaran hendaklah dikonfigurasikan berdasarkan nilai RPO yang boleh diterima untuk perniagaan, dan semakan integriti berkala bagi sandaran harus disahkan (sebilangan besar vendor perisian sandaran telah melaksanakan pengesahan automatik dalam produk mereka) untuk memastikan nilai RTO yang boleh diterima.
Terima kasih kerana membaca sehingga habis.
Kami bersedia untuk menjawab soalan dan komen anda dalam komen. Juga, di mana kami mengadakan promosi tetap (diskaun pada IaaS dan hadiah untuk kod promosi sehingga 100% pada VPS), tulis berita menarik dan umumkan artikel baharu di blog Habr.
Sumber: www.habr.com