Halo semua! Dengan artikel ini, AERODISK membuka blog di Habré. Hore, kawan!
Artikel sebelumnya di Habré membahas pertanyaan tentang arsitektur dan konfigurasi dasar sistem penyimpanan. Pada artikel ini kita akan membahas pertanyaan yang belum pernah dibahas sebelumnya, tetapi sering ditanyakan - tentang toleransi kesalahan sistem penyimpanan AERODISK ENGINE. Tim kami akan melakukan segalanya untuk memastikan bahwa sistem penyimpanan AERODISK berhenti bekerja, mis. hancurkan.
Kebetulan artikel tentang sejarah perusahaan kami, tentang produk kami, serta contoh implementasi yang sukses sudah ada di Habré, yang karenanya Terima kasih banyak kepada mitra kami - perusahaan TS Solution dan Softline.
Oleh karena itu, saya tidak akan melatih keterampilan manajemen copy-paste di sini, tetapi hanya akan memberikan link ke artikel asli berikut ini:
Saya juga ingin berbagi kabar baik. Tapi saya akan mulai, tentu saja, dengan masalahnya. Kami, sebagai vendor muda, antara lain, terus-menerus dihadapkan pada kenyataan bahwa banyak insinyur dan administrator tidak tahu cara mengoperasikan sistem penyimpanan kami dengan benar.
Jelas bahwa pengelolaan sebagian besar sistem penyimpanan terlihat kurang lebih sama dari sudut pandang administrator, namun setiap produsen memiliki karakteristiknya sendiri. Dan kami tidak terkecuali di sini.
Oleh karena itu, untuk menyederhanakan tugas pelatihan spesialis TI, kami memutuskan untuk mengabdikan tahun ini untuk pendidikan gratis. Untuk melakukan ini, di banyak kota besar di Rusia kami membuka jaringan Pusat Kompetensi AERODISK, di mana setiap spesialis teknis yang tertarik dapat mengikuti kursus secara gratis dan menerima sertifikat dalam mengelola sistem penyimpanan AERODISK ENGINE.
Di setiap Pusat Kompetensi kami akan memasang demo stand lengkap dari sistem penyimpanan AERODISK dan server fisik, di mana guru kami akan melakukan pelatihan tatap muka. Kami akan mempublikasikan jadwal kerja Pusat Kompetensi setelah kemunculannya, namun kami telah membuka pusat di Nizhny Novgorod dan kota Krasnodar adalah yang berikutnya. Anda dapat mendaftar untuk pelatihan menggunakan tautan di bawah ini. Berikut adalah informasi yang diketahui saat ini tentang kota dan tanggal:
- Nizhny Novgorod (SUDAH TERBUKA – Anda dapat mendaftar di sini );
Hingga 16 April 2019, Anda dapat mengunjungi pusat tersebut kapan saja waktu kerja, dan pada 16 April 2019, akan diselenggarakan kursus pelatihan besar-besaran. - Krasnodar (SEGERA DIBUKA - Anda dapat mendaftar di sini );
Dari tanggal 9 April hingga 25 April 2019, Anda dapat mengunjungi pusat tersebut kapan saja waktu kerja, dan pada tanggal 25 April 2019, kursus pelatihan besar akan diselenggarakan. - Yekaterinburg (SEGERA DIBUKA, ikuti informasi di website kami atau di Habré);
Mei-Juni 2019. - Novosibirsk (ikuti informasi di situs web kami atau di Habré);
Oktober 2019 - Krasnoyarsk (ikuti informasi di situs web kami atau di Habré);
November 2019.
Dan, tentu saja, jika Moskow tidak jauh dari Anda, kapan saja Anda dapat mengunjungi kantor kami di Moskow dan menjalani pelatihan serupa.
Semua. Kita sudah selesai dengan pemasaran, mari beralih ke teknologi!
Di Habré kami akan secara rutin menerbitkan artikel teknis tentang produk kami, uji beban, perbandingan, fitur penggunaan, dan implementasi menarik.
Uji tabrak sistem penyimpanan AERODISK ENGINE N2, uji kekuatan
PERINGATAN! Setelah membaca artikel tersebut, Anda dapat berkata: ya, tentu saja, vendor akan memeriksa sendiri agar semuanya berjalan “dengan baik”, kondisi rumah kaca, dll. Saya akan menjawab: tidak seperti itu! Tidak seperti pesaing asing kami, kami berlokasi di sini, dekat dengan Anda, dan Anda selalu dapat datang kepada kami (di Moskow atau Komite Sentral mana pun) dan menguji sistem penyimpanan kami dengan cara apa pun. Oleh karena itu, tidak masuk akal bagi kita untuk menyesuaikan hasil dengan gambaran dunia yang ideal, karena Kami sangat mudah untuk memeriksanya. Bagi yang malas berangkat dan tidak punya waktu, kami bisa mengadakan pengujian jarak jauh. Kami memiliki laboratorium khusus untuk ini. Hubungi kami.
ACHTUNG-2! Tes ini bukan tes beban, karena di sini kami hanya peduli pada toleransi kesalahan. Dalam beberapa minggu, kami akan menyiapkan stand yang lebih kuat dan melakukan pengujian beban pada sistem penyimpanan, mempublikasikan hasilnya di sini (omong-omong, permintaan pengujian diterima).
Jadi, ayo kita hancurkan.
Tempat uji coba
Stand kami terdiri dari perangkat keras berikut:
- 1 x sistem penyimpanan Aerodisk Engine N2 (2 pengontrol, cache 64 GB, port 8xFC 8 Gb/s, port 4xEthernet 10 Gb/s SFP+, port 4xEthernet 1 Gb/s); Disk berikut dipasang di sistem penyimpanan:
- 4 x disk SAS SSD 900 GB;
- 12 x disk SAS 10k 1,2 TB;
- 1 x Server fisik dengan Windows Server 2016 (2xXeon E5 2667 v3, RAM 96GB, 2xFC port 8Gb/s, 2xEthernet port 10Gb/s SFP+);
- 2 x sakelar SAN 8G;
- 2 x sakelar LAN 10G;
Kami menghubungkan server ke sistem penyimpanan melalui sakelar melalui FC dan 10G Ethernet. Diagram dudukan ada di bawah.
Komponen yang kita butuhkan, seperti inisiator MPIO dan iSCSI, diinstal pada Windows Server.
Zona dikonfigurasi pada sakelar FC, VLAN terkait dikonfigurasi pada sakelar LAN, dan MTU 9000 diinstal pada port penyimpanan, sakelar, dan host (cara melakukan semua ini dijelaskan dalam dokumentasi kami, jadi kami tidak akan menjelaskannya proses ini di sini).
Metodologi Tes
Rencana uji tabraknya adalah sebagai berikut:
- Memeriksa kegagalan port FC dan Ethernet.
- Pemeriksaan kegagalan daya.
- Pemeriksaan kegagalan pengontrol.
- Memeriksa kegagalan disk di grup/kumpulan.
Semua pengujian akan dilakukan dalam kondisi beban sintetis, yang akan kami hasilkan oleh program IOMETER. Secara paralel, kami akan melakukan tes yang sama, tetapi dalam kondisi menyalin file besar ke sistem penyimpanan.
Konfigurasi IOmeter adalah sebagai berikut:
- Baca/Tulis – 70/30
- Blok – 128k (kami memutuskan untuk mencuci sistem penyimpanan dalam blok besar)
- Jumlah utas – 128 (yang sangat mirip dengan beban produktif)
- Penuh Acak
- Jumlah Pekerja – 4 (2 untuk FC, 2 untuk iSCSI)
Tes ini memiliki tujuan sebagai berikut:
- Pastikan proses pemuatan dan penyalinan sintetis tidak akan mengganggu atau menyebabkan kesalahan dalam berbagai skenario kegagalan.
- Pastikan bahwa proses peralihan port, pengontrol, dll. cukup otomatis dan tidak memerlukan tindakan administrator jika terjadi kegagalan (yaitu, selama failover, tentu saja kita tidak berbicara tentang failback).
- Pastikan informasi dalam log ditampilkan dengan benar.
Mempersiapkan host dan sistem penyimpanan
Kami mengonfigurasi akses blok pada sistem penyimpanan menggunakan port FC dan Ethernet (masing-masing FC dan iSCSI). Orang-orang dari TS Solution menjelaskan secara rinci cara melakukan ini di artikel sebelumnya (). Dan, tentu saja, tidak ada yang membatalkan manual dan kursus tersebut.
Kami menyiapkan grup hybrid menggunakan semua drive yang kami miliki. 2 disk SSD ditambahkan ke cache, 2 disk SSD ditambahkan sebagai tingkat penyimpanan tambahan (Tingkat Online). Kami mengelompokkan 12 drive SAS10k ke dalam RAID-60P (triple parity) untuk memeriksa kegagalan tiga drive dalam grup sekaligus. Satu disk tersisa untuk penggantian otomatis.
Kami menghubungkan dua LUN (satu melalui FC, satu melalui iSCSI).
Pemilik kedua LUN adalah pengontrol Engine-0
Mari kita mulai tesnya
Kami mengaktifkan IOMETER dengan konfigurasi di atas.
Kami mencatat throughput 1.8 GB/s dan latensi 3 milidetik. Tidak ada kesalahan (Jumlah Kesalahan Total).
Pada saat yang sama, dari drive lokal "C" host kami, kami secara paralel mulai menyalin dua file besar 100GB ke LUN penyimpanan FC dan iSCSI (drive E dan G di Windows), menggunakan antarmuka lain.
Di atas adalah proses penyalinan ke LUN FC, di bawah ke iSCSI.
Tes #1: Menonaktifkan port I/O
Kami mendekati sistem penyimpanan dari belakang))) dan dengan sedikit gerakan tangan kami mencabut semua kabel FC dan Ethernet 10G dari pengontrol Engine-0. Seolah-olah seorang wanita pembersih dengan kain pel lewat dan memutuskan untuk mencuci lantai tepat di tempat ingus berada dan kabel-kabel tergeletak (yaitu pengontrol masih berfungsi, tetapi port I/O mati).
Mari kita lihat IOMETER dan menyalin file. Throughput turun menjadi 0,5 GB/dtk, namun dengan cepat kembali ke level sebelumnya (dalam waktu sekitar 4-5 detik). Tidak ada kesalahan.
Menyalin file tidak berhenti, ada penurunan kecepatan, tetapi sama sekali tidak kritis (dari 840 MB/s turun menjadi 720 MB/s). Penyalinan belum berhenti.
Kami melihat log sistem penyimpanan dan melihat pesan tentang tidak tersedianya port dan relokasi otomatis grup.
Panel informasi juga memberi tahu kita bahwa semuanya tidak baik dengan port FC.
Sistem penyimpanan selamat dari kegagalan port I/O berhasil.
Tes No. 2. Menonaktifkan pengontrol penyimpanan
Hampir seketika (setelah memasang kembali kabel ke sistem penyimpanan) kami memutuskan untuk menyelesaikan sistem penyimpanan dengan menarik pengontrol keluar dari sasis.
Sekali lagi kami mendekati sistem penyimpanan dari belakang (kami menyukainya))) dan kali ini kami mengeluarkan pengontrol Engine-1, yang saat ini adalah pemilik RDG (tempat grup dipindahkan).
Situasi di IOmeter adalah sebagai berikut. I/O berhenti sekitar 5 detik. Kesalahan tidak menumpuk.
Setelah 5 detik, I/O dilanjutkan dengan throughput yang kurang lebih sama, namun dengan latensi 35 milidetik (latensi diperbaiki setelah sekitar beberapa menit). Terlihat dari screenshot nilai Total error count adalah 0 artinya tidak ada kesalahan penulisan atau pembacaan.
Mari kita lihat menyalin file kita. Seperti yang Anda lihat, itu tidak terputus, ada sedikit penurunan kinerja, tetapi secara keseluruhan semuanya kembali ke ~ 800 MB/s.
Kami pergi ke sistem penyimpanan dan melihat kutukan di panel informasi bahwa pengontrol Engine-1 tidak tersedia (tentu saja, kami mematikannya).
Kami juga melihat entri serupa di log.
Pengontrol penyimpanan juga selamat dari kegagalan berhasil.
Tes No. 3: Memutuskan sambungan catu daya.
Untuk berjaga-jaga, kami mulai menyalin file lagi, tetapi tidak menghentikan IOMETER.
Kami menarik unit catu daya.
Peringatan lain telah ditambahkan ke sistem penyimpanan di panel informasi.
Juga di menu sensor kita melihat bahwa sensor yang terkait dengan catu daya yang dicabut telah berubah menjadi merah.
Sistem penyimpanan terus bekerja. Kegagalan unit catu daya sama sekali tidak mempengaruhi pengoperasian sistem penyimpanan; dari sudut pandang host, kecepatan penyalinan dan indikator IOMETER tetap tidak berubah.
Tes kegagalan daya lulus berhasil.
Sebelum pengujian terakhir, kami memutuskan untuk menghidupkan kembali sistem penyimpanan, memasang kembali pengontrol dan unit catu daya, dan juga menata kabel-kabel, yang dengan senang hati diberitahukan oleh sistem penyimpanan kepada kami dengan ikon hijau di panel kesehatannya. .
Tes No. 4. Kegagalan tiga disk dalam satu grup
Sebelum tes ini, kami melakukan langkah persiapan tambahan. Faktanya adalah sistem penyimpanan ENGINE menyediakan hal yang sangat berguna - kebijakan pembangunan kembali yang berbeda. TS Solution menulis tentang fitur ini sebelumnya, tapi mari kita ingat esensinya. Administrator penyimpanan dapat menentukan prioritas alokasi sumber daya selama pembangunan kembali. Baik dalam arah kinerja I/O, yaitu pembangunan kembali membutuhkan waktu lebih lama, tetapi tidak ada penurunan kinerja. Atau ke arah kecepatan pembangunan kembali, namun produktivitas akan berkurang. Atau pilihan yang seimbang. Karena kinerja penyimpanan selama pembangunan kembali grup disk selalu membuat pusing admin, kami akan menguji kebijakan dengan bias terhadap kinerja I/O dan dengan mengorbankan kecepatan pembangunan kembali.
Sekarang mari kita periksa kegagalan disk. Kami juga mengaktifkan perekaman ke LUN (file dan IOMETER). Karena kita memiliki grup dengan paritas rangkap tiga (RAID-60P), ini berarti sistem harus tahan terhadap kegagalan tiga disk, dan setelah kegagalan, penggantian otomatis harus berfungsi, satu disk harus menggantikan salah satu disk yang gagal. dalam RDG, dan pembangunan kembali harus dimulai berdasarkan RDG.
Mulai. Pertama, melalui antarmuka penyimpanan, mari kita sorot disk yang ingin kita keluarkan (agar tidak ketinggalan dan menarik disk autochange).
Kami memeriksa indikasi pada perangkat keras. Semuanya baik-baik saja, kami melihat tiga disk menyala.
Dan kami mengeluarkan ketiga disk ini.
Mari kita lihat apa yang ada di host. Dan di sana... tidak ada hal istimewa yang terjadi.
Indikator penyalinan (lebih tinggi dari pada awal, karena cache telah memanas) dan IOMETER tidak banyak berubah saat mengeluarkan disk dan memulai pembangunan kembali (dalam 5-10%).
Mari kita lihat apa yang ada di sistem penyimpanan.
Dari status grup, kami melihat proses restrukturisasi telah dimulai dan hampir selesai.
Dalam kerangka RDG Anda dapat melihat bahwa 2 disk berstatus merah, dan satu sudah diganti. Disk pengganti otomatis sudah tidak ada lagi; ia menggantikan disk ke-3 yang gagal. Pembangunan kembali memakan waktu beberapa menit, penulisan file ketika 3 disk gagal tidak terganggu, dan kinerja I/O tidak banyak berubah.
Tes kegagalan disk pasti lulus berhasil.
Kesimpulan
Pada titik ini, kami memutuskan untuk menghentikan kekerasan terhadap sistem penyimpanan. Mari kita rangkum:
- Pemeriksaan kegagalan port FC - berhasil
- Pemeriksaan kegagalan port Ethernet - berhasil
- Pemeriksaan kegagalan pengontrol - berhasil
- Tes Kegagalan Daya - Berhasil
- Memeriksa kegagalan disk di grouppool - berhasil
Tidak ada kegagalan yang menghentikan perekaman atau menyebabkan kesalahan pada beban sintetis; tentu saja, ada penurunan kinerja (dan kami tahu cara mengatasinya, yang akan segera kami lakukan), tetapi mengingat ini hanya hitungan detik, hal ini cukup dapat diterima. Kesimpulan: toleransi kesalahan seluruh komponen sistem penyimpanan AERODISK bekerja pada level, tidak ada titik kegagalan.
Tentu saja, dalam satu artikel kami tidak dapat menguji semua skenario kegagalan, namun kami mencoba membahas skenario yang paling populer. Oleh karena itu, mohon kirimkan komentar, saran untuk publikasi selanjutnya dan tentunya kritik yang memadai. Kami akan dengan senang hati berdiskusi (atau lebih baik lagi, datang ke pelatihan, saya duplikat jadwalnya untuk berjaga-jaga)! Sampai tes baru!
- Nizhny Novgorod (SUDAH TERBUKA – Anda dapat mendaftar di sini );
Hingga 16 April 2019, Anda dapat mengunjungi pusat tersebut kapan saja waktu kerja, dan pada 16 April 2019, akan diselenggarakan kursus pelatihan besar-besaran. - Krasnodar (SEGERA DIBUKA - Anda dapat mendaftar di sini );
Dari tanggal 9 April hingga 25 April 2019, Anda dapat mengunjungi pusat tersebut kapan saja waktu kerja, dan pada tanggal 25 April 2019, kursus pelatihan besar akan diselenggarakan. - Yekaterinburg (SEGERA DIBUKA, ikuti informasi di website kami atau di Habré);
Mei-Juni 2019. - Novosibirsk (ikuti informasi di situs web kami atau di Habré);
Oktober 2019 - Krasnoyarsk (ikuti informasi di situs web kami atau di Habré);
November 2019.
Sumber: www.habr.com