Versi perangkat kukuh sing paling "bener" lan "makarya"? Yen sistem panyimpenan njamin toleransi fault 99,9999%, tegese bakal bisa tanpa gangguan sanajan tanpa nganyari piranti lunak? Utawa, ing nalisir, diwenehi toleransi fault maksimum, sampeyan kudu tansah nginstal perangkat kukuh paling anyar? Kita bakal nyoba njawab pitakonan kasebut adhedhasar pengalaman kita.
Pambuka cilik
Kita kabeh ngerti manawa saben versi piranti lunak, dadi sistem operasi utawa driver kanggo piranti, asring ngemot cacat / bug lan "fitur" liyane sing bisa uga ora "katon" nganti pungkasan umur layanan peralatan, utawa "mbukak" mung ing kahanan tartamtu. Jumlah lan pinunjul saka nuansa kasebut gumantung saka kerumitan (fungsi) piranti lunak lan kualitas tes sajrone pangembangane.
Asring, pangguna tetep ing "firmware saka pabrik" (sing misuwur "kerjane, supaya ora kekacoan karo") utawa tansah nginstal versi paling anyar (ing pangerten, paling anyar tegese paling digunakake). Kita nggunakake pendekatan sing beda - kita ndeleng cathetan rilis kanggo kabeh sing digunakake peralatan lan kasebut kanthi teliti, pilih perangkat kukuh cocok kanggo saben Piece saka peralatan.
Kita teka ing kesimpulan iki, kaya sing dikandhakake, kanthi pengalaman. Nggunakake conto operasi kita, kita bakal menehi pitutur marang kowe kenapa 99,9999% linuwih sistem panyimpenan sing dijanjekake ora ana gunane yen sampeyan ora langsung ngawasi nganyari lan deskripsi piranti lunak. Kasus kita cocog kanggo pangguna sistem panyimpenan saka vendor apa wae, amarga kahanan sing padha bisa kedadeyan karo hardware saka pabrikan apa wae.
Milih Sistem Panyimpenan Anyar
Ing pungkasan taun kepungkur, sistem panyimpenan data sing menarik ditambahake ing infrastruktur kita: model junior saka garis IBM FlashSystem 5000, sing nalika tuku diarani Storwize V5010e. Saiki didol kanthi jeneng FlashSystem 5010, nanging nyatane minangka basis hardware sing padha karo Spectrum Virtualize ing njero.
Anane sistem manajemen terpadu, kanthi cara, prabédan utama ing antarane IBM FlashSystem. Kanggo model seri sing luwih enom, praktis ora beda karo model sing luwih produktif. Milih model tartamtu mung nyedhiyakake basis hardware sing cocog, karakteristik sing bisa nggunakake siji utawa fungsi liyane utawa nyedhiyakake skalabilitas sing luwih dhuwur. Piranti lunak ngenali hardware lan nyedhiyakake fungsi sing dibutuhake lan cukup kanggo platform iki.
IBM FlashSystem 5010
Sedhela babagan model kita 5010. Iki minangka sistem panyimpenan blok kontrol dual-entry level. Bisa nampung disk NLSAS, SAS, SSD. Panggonan NVMe ora kasedhiya, amarga model panyimpenan iki dipanggonke kanggo ngatasi masalah sing ora mbutuhake kinerja drive NVMe.
Sistem panyimpenan dituku kanggo nampung informasi arsip utawa data sing ora kerep diakses. Mulane, pesawat standar saka sawijining fungsi wis cukup kanggo kita: Tiering (Tier Gampang), Lancip Pranata. Kinerja ing disk NLSAS ing tingkat 1000-2000 IOPS uga cukup marem kanggo kita.
Pengalaman kita - carane kita ora nganyari perangkat kukuh ing wektu
Saiki babagan nganyari piranti lunak dhewe. Nalika tuku, sistem kasebut wis duwe versi piranti lunak Spectrum Virtualize sing rada ketinggalan jaman, yaiku, 8.2.1.3.
We sinau gambaran perangkat kukuh lan ngrancang nganyari kanggo 8.2.1.9. Yen kita wis rada efisien, artikel iki ora bakal ana - bug ora bakal kedadeyan ing perangkat kukuh sing luwih anyar. Nanging, amarga alasan tartamtu, nganyari sistem iki ditundha.
Akibaté, wektu tundha nganyari sing sithik nyebabake gambar sing ora nyenengake, kaya ing katrangan ing tautan: .
Ya, ing perangkat kukuh versi kasebut, sing diarani APAR (Laporan Analisis Program Sah) HU02104 cocog. Katon kaya ing ngisor iki. Ing beban, ing kahanan tartamtu, cache wiwit kebanjiran, banjur sistem dadi menyang mode protèktif, kang mateni I / O kanggo blumbang. Ing kasus kita, katon kaya medhot 3 disk kanggo grup RAID ing mode RAID 6. Pedhot ana 6 menit. Sabanjure, akses menyang Volumes ing Pool dibalèkaké.
Yen ana sing ora ngerti struktur lan jeneng entitas logis ing konteks IBM Spectrum Virtualize, saiki aku bakal nerangake kanthi ringkes.
Struktur unsur logis sistem panyimpenan
Disk diklumpukake dadi klompok sing diarani MDisk (Disk Ngatur). MDisk bisa dadi RAID klasik (0,1,10,5,6) utawa virtualisasi - DRAID (Distributed RAID). Nggunakake DRAID ngidini sampeyan nambah kinerja array, amarga ... Kabeh disk ing grup bakal digunakake, lan mbangun maneh wektu bakal suda, amarga kasunyatan sing mung pamblokiran tartamtu kudu dibalèkaké, lan ora kabeh data saka disk gagal.
Distribusi pamblokiran data ing disk nalika nggunakake RAID Distribusi (DRAID) ing mode RAID-5.
Lan diagram iki nuduhake logika carane DRAID mbangun maneh yen ana kegagalan disk:
Logika DRAID mbangun maneh nalika siji disk gagal
Sabanjure, siji utawa luwih MDisks mbentuk sing disebut Pool. Ing blumbang sing padha, ora dianjurake kanggo nggunakake MDisk kanthi tingkat RAID / DRAID sing beda ing disk saka jinis sing padha. Kita ora bakal ngrembug babagan iki, amarga ... kita rencana kanggo nutupi iki ing salah siji saka artikel ing ngisor iki. Inggih, nyatane, Pool dipérang dadi Volumes, sing ditampilake nggunakake siji utawa protokol akses blok liyane menyang host.
Dadi, kita, minangka asil saka kahanan sing diterangake ing APAR HU02104, amarga Gagal logis saka telung disk, MDisk mandhek kanggo fungsi, kang, siji, nyebabake Gagal Pool lan Volume cocog.
Amarga sistem iki cukup pinter, padha bisa disambungake menyang IBM Storage Insights sistem ngawasi basis maya, kang kanthi otomatis ngirim panjalukan layanan kanggo support IBM yen ana masalah. Aplikasi digawe lan spesialis IBM nindakake diagnostik saka jarak jauh lan hubungi pangguna sistem.
Thanks kanggo iki, masalah iki ditanggulangi kanthi cepet lan rekomendasi cepet ditampa saka layanan dhukungan kanggo nganyari sistem kita menyang perangkat kukuh sing dipilih sadurunge 8.2.1.9, sing ing wektu kasebut wis didandani. Iku konfirmasi .
Asil lan Rekomendasi kita
Kaya sing dicritakake: "Kabeh apik sing pungkasane apik." Bug ing perangkat kukuh ora nyebabake masalah serius - server dibalekake sanalika bisa lan tanpa mundhut data. Sawetara klien kudu miwiti maneh mesin virtual, nanging umume kita wis siyap kanggo akibat sing luwih negatif, amarga kita nggawe serep saben dina kabeh unsur infrastruktur lan mesin klien.
Kita wis nampa konfirmasi sing malah sistem dipercaya karo 99,9999% kasedhiyan janji mbutuhake manungsa waé lan pangopènan pas wektune. Adhedhasar kahanan kasebut, kita wis nggawe sawetara kesimpulan kanggo awake dhewe lan nuduhake rekomendasi:
-
Penting kanggo ngawasi rilis nganyari, sinau Cathetan Rilis kanggo koreksi masalah sing bisa kritis, lan nindakake nganyari sing direncanakake kanthi pas wektune.
Iki minangka titik organisasi lan malah cukup jelas, sing, mesthine, ora kudu fokus. Nanging, ing "lemah tingkat" iki sampeyan bisa kesandhung cukup gampang. Bener, wayahe iki nambahake masalah sing diterangake ing ndhuwur. Ati-ati banget nalika nggawe peraturan nganyari lan ngawasi kepatuhan kasebut kanthi ati-ati. Titik iki luwih gegayutan karo konsep "disiplin".
-
Iku tansah luwih apik kanggo njaga sistem karo versi piranti lunak paling anyar. Kajaba iku, sing saiki dudu sing duwe sebutan angka sing luwih gedhe, nanging sing tanggal rilis mengko.
Contone, IBM tetep paling ora rong rilis piranti lunak kanggo sistem panyimpenan. Ing wektu nulis iki, iki 8.2 lan 8.3. Nganyari kanggo 8.2 metu sadurungé. Nganyari sing padha kanggo 8.3 biasane dirilis kanthi wektu tundha sithik.
Rilis 8.3 nduweni sawetara kaluwihan fungsional, contone, kemampuan kanggo nggedhekake MDisk (ing mode DRAID) kanthi nambahake siji utawa luwih disk anyar (fitur iki wis muncul wiwit versi 8.3.1). Iki minangka fungsi sing cukup dhasar, nanging ing 8.2, sayangé, ora ana fitur kasebut.
-
Yen ora bisa nganyari sakperangan alesan, banjur kanggo versi piranti lunak Spectrum Virtualize sadurunge versi 8.2.1.9 lan 8.3.1.0 (ngendi bug sing diterangake ing ndhuwur relevan), kanggo nyuda resiko kedadeyane, dhukungan teknis IBM nyaranake. matesi kinerja sistem ing tingkat blumbang, minangka ditampilake ing tokoh ngisor (gambar dijupuk ing versi Russified saka GUI). Nilai 10000 IOPS ditampilake minangka conto lan dipilih miturut karakteristik sistem sampeyan.
Matesi kinerja panyimpenan IBM
-
Sampeyan kudu ngetung beban ing sistem panyimpenan kanthi bener lan supaya ora kakehan. Kanggo nindakake iki, sampeyan bisa nggunakake salah siji ukuran IBM (yen sampeyan duwe akses menyang), utawa bantuan saka partners, utawa sumber daya pihak katelu. Penting kanggo ngerti profil beban ing sistem panyimpenan, amarga Kinerja ing MB/s lan IOPS beda-beda gumantung paling ora paramèter ing ngisor iki:
-
jinis operasi: maca utawa nulis,
-
ukuran blok operasi,
-
persentasi saka operasi maca lan nulis ing total I / O stream.
Uga, kacepetan operasi kena pengaruh carane pamblokiran data diwaca: kanthi urutan utawa kanthi acak. Nalika nindakake sawetara operasi akses data ing sisih aplikasi, ana konsep operasi gumantung. Sampeyan uga dianjurake kanggo njupuk iki menyang akun. Kabeh iki bisa bantuan kanggo ndeleng total data saka counter kinerja OS, sistem panyimpenan, server / hypervisor, uga pangerten fitur operasi aplikasi, DBMS lan "konsumen" sumber disk liyane.
-
-
Lan pungkasane, manawa sampeyan duwe serep sing paling anyar lan bisa digunakake. Jadwal serep kudu dikonfigurasi adhedhasar nilai RPO sing bisa ditampa kanggo bisnis kasebut, lan priksa integritas serep berkala kudu diverifikasi (cukup sawetara vendor piranti lunak serep sing wis verifikasi otomatis ing produke) kanggo njamin nilai RTO sing bisa ditampa.
Matur nuwun kanggo maca nganti pungkasan.
Kita siyap mangsuli pitakon lan komentar sampeyan ing komentar. ugi, ing ngendi kita nganakake promosi reguler (diskon ing IaaS lan hadiah kanggo kode promosi nganti 100% ing VPS), nulis warta menarik lan ngumumake artikel anyar ing blog Habr.
Source: www.habr.com