Halo kabeh! Kanthi artikel iki, AERODISK mbukak blog ing Habré. Hore, kanca-kanca!
Artikel sadurunge ing Habré ngrembug pitakonan babagan arsitektur lan konfigurasi dhasar sistem panyimpenan. Ing artikel iki, kita bakal nimbang pitakonan sing durung dibahas sadurunge, nanging asring ditakoni - babagan toleransi kesalahan sistem panyimpenan AERODISK ENGINE. Tim kita bakal nindakake kabeh kanggo mesthekake yen sistem panyimpenan AERODISK mandheg digunakake, i.e. rusak iku.
Kedadeyan manawa artikel babagan sejarah perusahaan kita, babagan produk kita, uga conto implementasine sukses wis digantung ing Habré, sing Matur nuwun kanthi sanget kanggo mitra - TS Solution lan perusahaan Softline.
Mula, aku ora bakal nglatih katrampilan manajemen copy-paste ing kene, nanging mung bakal menehi tautan menyang artikel asli:
Aku uga pengin nuduhake kabar apik. Nanging aku bakal miwiti, mesthi, karo masalah. Kita, minangka vendor enom, ing antarane biaya liyane, terus-terusan ngadhepi kasunyatan manawa akeh insinyur lan pangurus mung ora ngerti cara ngoperasikake sistem panyimpenan kanthi bener.
Cetha yen ngatur paling sistem panyimpenan katon kira-kira padha saka sudut pandang administrator, nanging saben pabrikan nduweni ciri dhewe. Lan kita ora istiméwa ing kene.
Mulane, kanggo nyederhanakake tugas nglatih spesialis IT, kita mutusake kanggo nyedhiyakake pendidikan gratis ing taun iki. Kanggo nindakake iki, ing pirang-pirang kutha gedhe ing Rusia, kita mbukak jaringan Pusat Kompetensi AERODISK, ing ngendi spesialis teknis sing kasengsem bisa njupuk kursus kanthi gratis lan nampa sertifikat kanggo ngatur sistem panyimpenan AERODISK ENGINE.
Ing saben Pusat Kompetensi kita bakal nginstal stand demo lengkap saka sistem panyimpenan AERODISK lan server fisik, ing ngendi guru bakal nganakake latihan adhep-adhepan. Kita bakal nerbitake jadwal kerja Pusat Kompetensi nalika katon, nanging kita wis mbukak pusat ing Nizhny Novgorod lan kutha Krasnodar sabanjure. Sampeyan bisa ndhaptar latihan nggunakake tautan ing ngisor iki. Mangkene informasi saiki babagan kutha lan tanggal:
- Nizhny Novgorod (Wis BUKA - sampeyan bisa ndhaptar ing kene );
Nganti 16 April 2019, sampeyan bisa ngunjungi pusat kasebut ing sembarang wektu kerja, lan ing 16 April 2019, kursus pelatihan gedhe bakal dianakake. - Krasnodar (OPENING SOON - sampeyan bisa ndaftar ing kene );
Saka 9 April nganti 25 April 2019, sampeyan bisa ngunjungi pusat kasebut ing sembarang wektu kerja, lan ing tanggal 25 April 2019, kursus pelatihan gedhe bakal dianakake. - Екатеринбург (OPENING SOON, tindakake informasi ing situs web kita utawa ing Habré);
Mei-Juni 2019. - Новосибирск (Tututi informasi ing situs web kita utawa ing Habré);
Oktober 2019. - Красноярск (Tututi informasi ing situs web kita utawa ing Habré);
November 2019.
Lan, mesthi, yen Moskow ora adoh saka sampeyan, mula kapan wae sampeyan bisa ngunjungi kantor kita ing Moskow lan ngalami latihan sing padha.
Kabeh. Kita wis rampung karo marketing, ayo pindhah menyang teknologi!
Ing Habré, kita bakal nerbitake artikel teknis babagan produk, tes muatan, perbandingan, fitur panggunaan lan implementasi sing menarik.
Tes kacilakan sistem panyimpenan AERODISK ENGINE N2, tes kekuatan
PÈNGET! Sawise maca artikel kasebut, sampeyan bisa ngomong: mesthine, vendor bakal mriksa awake dhewe supaya kabeh bisa "kanthi bang", kahanan omah kaca, lsp. Aku bakal mangsuli: ora ana sing kaya ngono! Ora kaya pesaing manca, kita dumunung ing kene, cedhak karo sampeyan, lan sampeyan bisa tansah teka menyang kita (ing Moskow utawa Komite Pusat) lan nyoba sistem panyimpenan kanthi cara apa wae. Mangkono, iku ora nggawe akeh pangertèn kanggo kita nyetel asil kanggo gambaran becik saka donya, amarga Kita gampang banget kanggo mriksa. Kanggo sing kesed lunga lan ora duwe wektu, kita bisa ngatur tes jarak jauh. Kita duwe lab khusus kanggo iki. Hubungi kita.
ACHTUNG-2! Tes iki dudu tes beban, amarga kene kita mung Care babagan toleransi fault. Ing sawetara minggu, kita bakal nyiapake stand sing luwih kuat lan nganakake tes beban sistem panyimpenan, nerbitake asil ing kene (kanthi cara, panjaluk tes ditampa).
Dadi, ayo padha bubar.
bangku test
Stand kita kasusun saka hardware ing ngisor iki:
- 1 x Sistem panyimpenan Aerodisk Engine N2 (2 pengontrol, 64GB cache, 8xFC port 8Gb/s, 4xEthernet port 10Gb/s SFP+, 4xEthernet port 1Gb/s); Disk ing ngisor iki diinstal ing sistem panyimpenan:
- 4 x SAS SSD disk 900 GB;
- 12 x SAS 10k disk 1,2 TB;
- 1 x Server fisik karo Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xFC port 8Gb/s, 2xEthernet port 10Gb/s SFP+);
- 2 x SAN 8G ngalih;
- 2 x LAN 10G switch;
Kita nyambungake server menyang sistem panyimpenan liwat switch liwat FC lan 10G Ethernet. Diagram ngadeg ing ngisor iki.
Komponen sing dibutuhake, kayata MPIO lan iSCSI inisiator, diinstal ing Windows Server.
Zona dikonfigurasi ing switch FC, VLAN sing cocog dikonfigurasi ing switch LAN, lan MTU 9000 diinstal ing port panyimpenan, switch, lan host (carane nindakake kabeh iki diterangake ing dokumentasi kita, supaya kita ora bakal njlèntrèhaké. proses iki ing kene).
Metodologi Tes
Rencana tes kacilakan kaya ing ngisor iki:
- Priksa kegagalan port FC lan Ethernet.
- Priksa gagal daya.
- Kontrol gagal mriksa.
- Priksa gagal disk ing grup / blumbang.
Kabeh tes bakal ditindakake ing kahanan beban sintetik, sing bakal digawe dening program IOMETER. Ing podo karo, kita bakal nindakake tes sing padha, nanging ing kondisi nyalin file gedhe menyang sistem panyimpenan.
Konfigurasi IOmeter kaya ing ngisor iki:
- Maca / Nulis - 70/30
- Blok - 128k (kita mutusake kanggo ngumbah sistem panyimpenan ing blok gedhe)
- Jumlah utas - 128 (sing meh padha karo beban produktif)
- Random Lengkap
- Jumlah Pekerja - 4 (2 kanggo FC, 2 kanggo iSCSI)
Tes kasebut nduweni tujuan ing ngisor iki:
- Priksa manawa proses muat lan salinan sintetis ora bakal ngganggu utawa nyebabake kesalahan ing macem-macem skenario kegagalan.
- Priksa manawa proses ngoper port, pengontrol, lan liya-liyane cukup otomatis lan ora mbutuhake tumindak administrator yen gagal (yaiku, nalika gagal, kita ora ngomong babagan kegagalan, mesthi).
- Priksa manawa informasi ing log ditampilake kanthi bener.
Nyiyapake sistem inang lan panyimpenan
Kita ngatur akses pemblokiran ing sistem panyimpenan nggunakake port FC lan Ethernet (FC lan iSCSI, mungguh). Wong lanang saka TS Solution diterangake kanthi rinci babagan carane nindakake iki ing artikel sadurunge (). Lan, mesthi, ora ana sing mbatalake manual lan kursus.
Kita nyiyapake grup hibrida nggunakake kabeh drive sing ana. 2 SSD disk ditambahake menyang cache, 2 SSD disk ditambahake minangka undakan panyimpenan tambahan (Online-undakan). We diklompokaké 12 SAS10k drive menyang RAID-60P (paritas telung) kanggo mriksa Gagal telung drive ing grup bebarengan. Siji disk ditinggalake kanggo autoreplacement.
Kita nyambungake loro LUN (siji liwat FC, siji liwat iSCSI).
Pemilik loro LUN yaiku pengontrol Engine-0
Ayo miwiti tes
Kita ngaktifake IOMETER kanthi konfigurasi ing ndhuwur.
Kita ngrekam throughput 1.8 GB / s lan latensi 3 milliseconds. Ora ana kesalahan (Total Error Count).
Ing wektu sing padha, saka drive lokal "C" saka inang kita, kita podo miwiti nyalin loro file 100GB gedhe kanggo FC lan iSCSI panyimpenan LUNs (drive E lan G ing Windows), nggunakake antarmuka liyane.
Ndhuwur proses nyalin menyang LUN FC, ing ngisor iki kanggo iSCSI.
Test # 1: Mateni port I/O
Kita nyedhaki sistem panyimpenan saka mburi))) lan kanthi gerakan tangan sing sithik, kita narik kabeh kabel FC lan Ethernet 10G saka pengontrol Engine-0. Kaya-kaya ana wanita reresik sing mlaku-mlaku lan mutusake kanggo ngumbah lantai ing endi snot ana lan kabel-kabele ana (yaiku, pengontrol isih bisa digunakake, nanging port I / O wis mati).
Ayo goleki IOMETER lan nyalin file. Throughput dropped kanggo 0,5 GB / s, nanging cepet bali menyang tingkat sadurungé (ing bab 4-5 detik). Ora ana kesalahan.
Nyalin file wis ora mandheg, ana gulung ing kacepetan, nanging ora kritis (saka 840 MB / s mudhun kanggo 720 MB / s). Nyalin ora mandheg.
Kita ndeleng log sistem panyimpenan lan ndeleng pesen babagan ora kasedhiyan port lan relokasi otomatis grup.
Panel informasi uga ngandhani yen kabeh ora apik banget karo port FC.
Sistem panyimpenan slamet saka Gagal I / O bandar kasil.
Test No.. 2. Mateni controller panyimpenan
Meh langsung (sawise dipasang kabel bali menyang sistem panyimpenan) kita mutusaké kanggo ngrampungake sistem panyimpenan kanthi narik controller metu saka sasis.
Maneh nyedhaki sistem panyimpenan saka mburi (kita seneng))) lan wektu iki kita narik pengontrol Engine-1, sing saiki dadi pemilik RDG (sing dipindhah klompok).
Kahanan ing IOmeter kaya ing ngisor iki. I/O mandheg watara 5 detik. Kasalahan ora nglumpukake.
Sawise 5 detik, I/O diterusake kanthi throughput sing padha, nanging kanthi latensi 35 milidetik (latensi didandani sawise sawetara menit). Kaya sing bisa dideleng saka gambar, total nilai count kesalahan yaiku 0, yaiku, ora ana kesalahan nulis utawa maca.
Ayo ndeleng nyalin file kita. Nalika sampeyan bisa ndeleng, iku ora diselani, ana tepak sethitik ing kinerja, nanging sakabèhé kabeh bali menyang padha ~ 800 MB / s.
We menyang sistem panyimpenan lan ndeleng ipat ing panel informasi sing Engine-1 controller ora kasedhiya (mesthi, kita matèni iku).
Kita uga ndeleng entri sing padha ing log.
Kontroler panyimpenan uga slamet saka kegagalan kasil.
Test No.. 3: Medhot sumber daya.
Ing kasus, kita miwiti nyalin file maneh, nanging ora mandheg IOMETER.
Kita narik unit sumber daya.
Tandha liyane wis ditambahake menyang sistem panyimpenan ing panel informasi.
Uga ing menu sensor kita weruh manawa sensor sing ana gandhengane karo sumber daya sing ditarik wis dadi abang.
Sistem panyimpenan terus bisa digunakake. Gagal unit sumber daya ora mengaruhi operasi sistem panyimpenan; saka sudut pandang host, kacepetan salinan lan indikator IOMETER tetep ora owah.
Test gagal daya lulus kasil.
Sadurunge tes pungkasan, kita mutusake supaya sistem panyimpenan urip maneh sethithik, sijine maneh controller lan unit sumber daya, lan uga sijine kabel supaya, kang sistem panyimpenan seneng informed kita bab karo lambang ijo ing panel kesehatan. .
Test No.. 4. Gagal telung disk ing grup
Sadurunge tes iki, kita nindakake langkah persiapan tambahan. Kasunyatane yaiku sistem panyimpenan ENGINE nyedhiyakake barang sing migunani banget - different rebuild policy . TS Solution nulis babagan fitur iki sadurunge, nanging ayo ngelingi esensie. Administrator panyimpenan bisa nemtokake prioritas kanggo alokasi sumber daya sajrone mbangun maneh. Ing arah kinerja I / O, yaiku, mbangun maneh luwih suwe, nanging ora ana penurunan kinerja. Utawa ing arah kacepetan mbangun maneh, nanging produktivitas bakal suda. Utawa pilihan imbang. Amarga kinerja panyimpenan sajrone mbangun maneh grup disk tansah dadi sirah admin, kita bakal nyoba kabijakan kanthi bias menyang kinerja I / O lan kanthi biaya mbangun maneh.
Saiki ayo priksa manawa disk gagal. Kita uga ngaktifake rekaman menyang LUNs (file lan IOMETER). Amarga kita duwe klompok kanthi paritas telu (RAID-60P), iki tegese sistem kasebut kudu tahan kegagalan telung disk, lan sawise gagal, panggantos otomatis kudu bisa digunakake, siji disk kudu ngganti salah sawijining sing gagal. ing RDG, lan mbangun maneh kudu diwiwiti.
miwiti. Pisanan, liwat antarmuka panyimpenan, ayo nyorot disk sing pengin ditarik (supaya ora kantun lan narik disk autochange).
Kita mriksa pratondo ing hardware. Kabeh iku OK, kita ndeleng telung disk disorot.
Lan kita narik metu telung disk iki.
Ayo ndeleng apa sing ana ing host. Lan ana ... boten khusus kedaden.
Indikator nyalin (luwih dhuwur tinimbang ing wiwitan, amarga cache wis anget) lan IOMETER ora owah akeh nalika mbusak disk lan miwiti mbangun maneh (ing 5-10%).
Ayo goleki apa sing ana ing sistem panyimpenan.
Ing status grup, kita weruh yen proses restrukturisasi wis diwiwiti lan wis cedhak rampung.
Ing balung RDG sampeyan bisa ndeleng sing 2 disk ing status abang, lan siji wis diganti. Disk autoreplacement ora ana maneh; iku ngganti disk gagal kaping 3. Mbangun maneh njupuk sawetara menit, nulis file nalika 3 disk gagal ora diselani, lan I / O kinerja ora owah akeh.
Tes gagal disk mesthi lulus kasil.
kesimpulan
Ing wektu iki, kita mutusake kanggo mungkasi kekerasan marang sistem panyimpenan. Ayo ngringkes:
- Priksa kegagalan port FC - sukses
- Priksa gagal port Ethernet - sukses
- Kontrol gagal mriksa - sukses
- Test Gagal Daya - Sukses
- Priksa gagal disk ing grouppool - sukses
Ora ana kegagalan sing mandheg ngrekam utawa nyebabake kesalahan ing beban sintetik; mesthi ana kinerja hit (lan kita ngerti carane ngatasi, sing bakal ditindakake kanthi cepet), nanging amarga iki sawetara detik, cukup ditrima. Kesimpulan: toleransi kesalahan kabeh komponen sistem panyimpenan AERODISK makarya ing tingkat, ora ana titik kegagalan.
Temenan, ing siji artikel, kita ora bisa nyoba kabeh skenario kegagalan, nanging kita nyoba nutupi sing paling populer. Mula, kirim komentar, saran kanggo publikasi sabanjure lan, mesthi, kritik sing cukup. Kita bakal seneng ngrembug (utawa luwih apik, teka ing latihan, aku duplikat jadwal mung ing kasus)! Nganti tes anyar!
- Nizhny Novgorod (Wis BUKA - sampeyan bisa ndhaptar ing kene );
Nganti 16 April 2019, sampeyan bisa ngunjungi pusat kasebut ing sembarang wektu kerja, lan ing 16 April 2019, kursus pelatihan gedhe bakal dianakake. - Krasnodar (OPENING SOON - sampeyan bisa ndaftar ing kene );
Saka 9 April nganti 25 April 2019, sampeyan bisa ngunjungi pusat kasebut ing sembarang wektu kerja, lan ing tanggal 25 April 2019, kursus pelatihan gedhe bakal dianakake. - Екатеринбург (OPENING SOON, tindakake informasi ing situs web kita utawa ing Habré);
Mei-Juni 2019. - Новосибирск (Tututi informasi ing situs web kita utawa ing Habré);
Oktober 2019. - Красноярск (Tututi informasi ing situs web kita utawa ing Habré);
November 2019.
Source: www.habr.com