memo-x

Berita, komentar, dan fitur terbaru dari The Memo X

OpenZFS 2.1 Dirilis – Mari Bicara Tentang vdevs dRAID Baru

Perbesar / OpenZFS telah menambahkan topologi RAID terdistribusi ke toolkitnya dengan rilis 2.1.0 hari ini.

Oric Lawson

Jumat sore, proyek OpenZFS dada Versi 2.1.0 dari sistem file favorit abadi kami “Ini rumit tetapi sepadan”. Versi baru ini kompatibel dengan FreeBSD 12.2-RELEASE dan yang lebih baru, dan kernel Linux 3.10-5.13. Rilis ini memperkenalkan beberapa peningkatan kinerja umum, serta beberapa fitur yang sama sekali baru – sebagian besar ditujukan untuk organisasi dan kasus penggunaan tingkat lanjut lainnya.

Hari ini, kita akan fokus pada fitur terbesar yang ditambahkan OpenZFS 2.1.0 – topologi vdev dRAID. dRAID telah aktif dalam pengembangan setidaknya sejak 2015, dan mencapai status beta ketika terintegrasi Dalam master OpenZFS pada November 2020. Sejak itu, telah diuji secara berat di beberapa toko pengembangan OpenZFS utama – yang berarti versi hari ini “segar” dalam kondisi produksi, bukan “baru” seperti yang belum diuji.

Ikhtisar RAID Terdistribusi (dRAID)

Jika Anda sudah berpikir bahwa topologi ZFS adalah sebuah file gabungan Subjek, bersiaplah untuk meledakkan pikiran Anda. RAID Terdistribusi (dRAID) adalah topologi vdev yang sama sekali baru yang pertama kali kami temui dalam presentasi di OpenZFS Dev Summit 2016.

Saat membuat vdev dRAID, administrator menentukan jumlah sektor data, paritas, dan hotspare untuk setiap strip. Angka-angka ini tidak tergantung pada jumlah disk fisik di vdev. Kita dapat melihat ini dalam praktik dalam contoh berikut, yang diangkat dari konsep dasar dRAID dokumentasi:

[email protected]:~# zpool create mypool draid2:4d:1s:11c wwn-0 wwn-1 wwn-2 ... wwn-A
[email protected]:~# zpool status mypool

  pool: mypool
 state: ONLINE
config:

        NAME                  STATE     READ WRITE CKSUM
        tank                  ONLINE       0     0     0
          draid2:4d:11c:1s-0  ONLINE       0     0     0
            wwn-0             ONLINE       0     0     0
            wwn-1             ONLINE       0     0     0
            wwn-2             ONLINE       0     0     0
            wwn-3             ONLINE       0     0     0
            wwn-4             ONLINE       0     0     0
            wwn-5             ONLINE       0     0     0
            wwn-6             ONLINE       0     0     0
            wwn-7             ONLINE       0     0     0
            wwn-8             ONLINE       0     0     0
            wwn-9             ONLINE       0     0     0
            wwn-A             ONLINE       0     0     0
        spares
          draid2-0-0          AVAIL

Topologi Dredd

Dalam contoh di atas, kami memiliki sebelas disk: wwn-0 seberang wwn-A. Kami membuat satu draID vdev dengan 2 perangkat paritas, 4 perangkat data, dan 1 perangkat cadangan per pita – dalam bahasa ringkas, draid2:4:1.

Meskipun kami memiliki total sebelas disk dalam satu file draid2:4:1, hanya enam yang digunakan di setiap bilah data — dan satu di setiap bilah fisik – fisik – pita. Di dunia penyedot debu yang sempurna, permukaan tanpa gesekan, dan ayam bola, tata letak pada disk draid2:4:1 Ini akan terlihat seperti ini:

READ  Bagaimana Diggersby menangkap di acara Pokemon Go Spring?
1 2 3 4 5 6 7 8 9 Sebuah
s s s Dr Dr Dr Dr s s Dr Dr
Dr s Dr s s Dr Dr Dr Dr s s
Dr Dr s Dr Dr s s Dr Dr Dr Dr
s s Dr s Dr Dr Dr s s Dr Dr
Dr Dr . . s . . . . . .
. . . . . s . . . . .
. . . . . . s . . . .
. . . . . . . s . . .
. . . . . . . . s . .
. . . . . . . . . s .
. . . . . . . . . . s

Secara efektif, Dredd mengambil konsep RAID “paritas diagonal” selangkah lebih maju. RAID5 bukan topologi paritas RAID pertama – itu adalah RAID3, di mana paritas terletak pada hard drive, daripada didistribusikan ke seluruh array.

RAID5 menghilangkan hard parity drive dan, sebaliknya, mendistribusikan paritas di semua disk array—memberikan penulisan acak yang jauh lebih cepat daripada RAID3 yang secara konseptual lebih sederhana, karena tidak menghalangi setiap penulisan ke hard parity disk.

dRAID mengambil konsep ini – mendistribusikan paritas di semua disk, daripada menggabungkan semuanya pada satu atau dua hard disk – dan memperluasnya ke spares. Jika disk gagal di dRAID vdev, sektor paritas dan data yang hidup di disk mati disalin ke sektor cadangan yang disediakan untuk setiap pita yang terpengaruh.

Mari kita ambil grafik sederhana di atas, dan lihat apa yang terjadi jika kita mengeluarkan disk dari matriks. Kegagalan awal meninggalkan celah di sebagian besar kumpulan data (dalam diagram yang disederhanakan ini, garis):

1 2 4 5 6 7 8 9 Sebuah
s s s Dr Dr Dr s s Dr Dr
Dr s Dr s Dr Dr Dr Dr s s
Dr Dr s Dr s s Dr Dr Dr Dr
s s Dr Dr Dr Dr s s Dr Dr
Dr Dr . s . . . . . .

Tetapi ketika kami menggunakan resilver, kami melakukannya pada kapasitas cadangan yang telah dipesan sebelumnya:

1 2 4 5 6 7 8 9 Sebuah
Dr s s Dr Dr Dr s s Dr Dr
Dr s Dr s Dr Dr Dr Dr s s
Dr Dr Dr Dr s s Dr Dr Dr Dr
s s Dr Dr Dr Dr s s Dr Dr
Dr Dr . s . . . . . .

Harap dicatat bahwa grafik ini adalah disederhanakan. Gambaran lengkapnya mencakup grup, segmen, dan baris yang tidak akan kami coba masuki di sini. Tata letak logis juga diacak secara acak untuk mendistribusikan hal-hal secara merata di seluruh drive berdasarkan offset. Mereka yang tertarik pada detail terkecil didorong untuk melihat detail ini Penangguhan Dalam komit kode asli.

Perlu juga dicatat bahwa dRAID memerlukan lebar strip statis – bukan lebar dinamis yang didukung oleh vdevs RAIDz1 dan RAIDz2 tradisional. Jika kita menggunakan disk 4kn, file draid2:4:1 Sebuah vdev seperti yang ditunjukkan di atas akan membutuhkan 24 KB pada disk per blok metadata, di mana sebuah vdev RAIDz2 enam lebar konvensional hanya membutuhkan 12 KB. Perbedaan ini semakin buruk semakin tinggi nilainya d+p Dapatkan draid2:8:1 Itu akan membutuhkan 40KB kekalahan untuk blok metadata yang sama!

Untuk alasan ini, special Pengalokasi vdev sangat berguna di kumpulan dengan vdev dRAID – ketika ada kumpulan dengannya draid2:8:1 dan lebar tiga special Itu perlu menyimpan blok metadata 4KiB, ia melakukannya hanya dalam 12KB pada file special, alih-alih 40 KB dalam satu file draid2:8:1.

Performa DREAD, Toleransi Kesalahan, dan Pengembalian

Grafik ini menunjukkan waktu kemunculan kembali yang diamati untuk kumpulan 90-cakram.  Garis biru tua di bagian atas adalah waktu filter ulang pada hard disk tetap;  Garis berwarna di bawah menunjukkan waktu likuidasi ulang pada kapasitas cadangan terdistribusi.

Grafik ini menunjukkan waktu kemunculan kembali yang diamati untuk kumpulan 90-cakram. Garis biru tua di bagian atas adalah waktu filter ulang pada hard disk tetap; Garis berwarna di bawah menunjukkan waktu likuidasi ulang pada kapasitas cadangan terdistribusi.

Untuk sebagian besar, dRAID vdev akan bekerja mirip dengan set vdev tradisional yang setara – misalnya, draid1:2:0 Pada sembilan disk itu akan bekerja hampir setara dengan satu set tiga RAIDz1 vdevs dengan lebar 3. Toleransi kesalahan juga serupa – Anda dijamin akan selamat dari satu kegagalan dengan p=1, sama seperti Anda dengan RAIDz1 vdevs.

Perhatikan bahwa kami mengatakan toleransi kesalahan adalah serupa, tidak identik. Satu set tradisional yang terdiri dari tiga RAIDz1 vdev dengan lebar 3 hanya dijamin untuk bertahan dari kegagalan disk tunggal, tetapi kemungkinan akan bertahan dari kegagalan disk tunggal – selama disk kedua yang gagal bukan bagian dari vdev yang sama dengan yang pertama, semuanya baik.

dalam sembilan cakram draid1:2, kegagalan disk kedua hampir pasti akan membunuh vdev (dan bundel dengannya), jika Kegagalan ini terjadi sebelum Anda bertahan. Karena tidak ada set font individual yang tetap, kemungkinan besar kegagalan disk kedua akan menonaktifkan sektor tambahan pada font yang sudah terdegradasi, terlepas dari Yang Disk kedua gagal.

Kurangnya toleransi kesalahan ini agak diimbangi dengan waktu resilver yang lebih cepat secara eksponensial. Pada grafik di bagian atas bagian ini, kita dapat melihat bahwa dalam kumpulan sembilan puluh disk 16TB, Anda menggunakan mesin stasioner konvensional. spare Dibutuhkan sekitar tiga puluh jam tidak peduli bagaimana kami mengonfigurasi dRAID vdev – tetapi muncul kembali pada redundansi terdistribusi dapat memakan waktu kurang dari satu jam.

Ini sebagian besar disebabkan oleh pemformatan ulang pada partisi terdistribusi yang membagi beban tulis di antara semua disk yang tersisa. Saat Anda memakainya dengan gaya tradisional spare, disk cadangan itu sendiri adalah hambatan – pembacaan berasal dari semua disk di vdev, tetapi semua penulisan harus diselesaikan dengan cadangan. Tetapi ketika kapasitas redundan terdistribusi didesain ulang, keduanya terbaca Dan Beban kerja tulis dibagi di antara semua disk yang tersisa.

Resilver terdistribusi juga bisa menjadi resilver serial, bukan prosesor resilver – artinya ZFS dapat dengan mudah menyalin semua sektor yang terpengaruh, tanpa khawatir tentang apa blocks Sektor-sektor ini milik. Sebaliknya, resilver penyembuhan harus memindai seluruh pohon blok – yang menghasilkan beban kerja baca acak, bukan beban kerja baca berurutan.

Ketika penggantian fisik disk yang gagal ditambahkan ke rakitan, penjualan kembali ini this akan Ini skalar, tidak berurutan – dan itu akan mencekik kinerja penulisan disk cadangan individu, daripada kinerja seluruh vdev. Tetapi waktu untuk menyelesaikan proses ini jauh lebih penting, karena vdev bahkan tidak dalam keadaan degradasi.

Kesimpulan

Versi RAID vdevs terdistribusi sering ditujukan untuk server penyimpanan besar – OpenZFS draid Desain dan pengujian sebagian besar berkisar pada sistem 90-cakram. Pada skala yang lebih kecil, file vdevs tradisional dan spares Itu tetap berguna seperti sebelumnya.

Kami terutama memperingatkan pemula dalam penyimpanan untuk berhati-hati dengan mereka draid—Ini adalah tata letak yang jauh lebih kompleks daripada menggabungkan dengan vdev tradisional. Fleksibilitas cepatnya bagus – tapi draid Ini mencapai kesuksesan di kedua tingkat stres dan skenario kinerja tertentu karena garis panjangnya yang pasti.

Sementara disk tradisional terus bertambah ukurannya tanpa meningkatkan kinerja secara signifikan, draid Konfigurasi ulangnya yang cepat mungkin diinginkan bahkan pada sistem yang lebih kecil – tetapi akan membutuhkan waktu untuk mengetahui dengan tepat di mana titik ideal dimulai. Sementara itu, harap diingat bahwa RAID bukan cadangan – ini termasuk draid!