私はZFSに少し慣れていませんが、12台の物理ドライブを備えた新しいストレージプールを起動します。
私の現在の計画は、10台のドライブと2つのホットスペアにRAIDZ2を配置することです。
しかし、12台のドライブすべてでRAIDZ3を使用し、ホットスペアがないほうがよいのではないでしょうか。
その理由は、ホットスペアは基本的に電源が投入されたアイドル状態のドライブであるためです。彼らが召喚されるまでには数ヶ月から数年かかる場合があり、そのとき私はそれらが実行可能でないことを知るかもしれません。それらがRAIDストライプの一部だった場合、少なくともそれらが良かったかどうかについてフィードバックを得ることができました。
私はこれについてウェブ上であまり議論していません。誰かアドバイスはありますか?
ホットスペアは固有のプールに設定されますが、障害が発生した場合、プールの任意のvdevに自動的に接続できます。すべてのディスクで構成される単一のvdevしかない場合は、ディスクを直接組み込むほうがよいです(すでにRAIDZ3があり、スペアのディスクがある場合を除く)。
さらに、再同期には時間がかかり、デバイスをvdevにすでに接続していた場合には発生しなかったであろう脆弱性(RAIDZ1、2ウェイミラー)またはパフォーマンス低下状態(RAIDZ2、RAIDZ3、3ウェイミラー)で発生します。
基本的に、ホットスペアは、大規模なアレイ向けのものです。 27個のディスクがRAIDZ3の9個のディスクの3個のvdevに分割されている場合、3個のホットスペアを追加して、「午前2時で、3個のディスクがクラッシュしました。今、起きてこの混乱を修正する必要があります」という瞬間を減らします(32ドライブベイシステム)。小規模なシステムでは、通常、「2つ以上のvdevとZ2/Z3」の状況にさえ到達するのに十分なディスクがありません。例外はミラー(例:6 x 2)で、クラッシュはプールにとって致命的であることに非常に近い(そして、それらを6 x 3にするのに十分なディスクがない)。
プールのレイアウトに関する Nex7のブログ からのアドバイス:
- サイズが1TB以上のディスクにはraidz1を使用しないでください。
- Raidz1の場合、各vdevで使用するディスクは3つ未満でも7つ以下でもかまいません(また、1 TBサイズで、できれば750 GB未満である必要があります)(5は典型的な平均です)。
- Raidz2の場合、各vdevで使用するディスクは6未満または10を超えないようにしてください(8は一般的な平均です)。
- Raidz3の場合、各vdevで7未満または15を超えるディスクを使用しないでください(13と15は通常の平均です)。
- ミラーはほぼ毎回raidzに勝っています。同じ数のドライブが与えられた場合、ミラープールからのIOPSポテンシャルは、どのraidzプールよりもはるかに高い欠点は冗長性だけです-raidz2/3はより安全ですが、はるかに遅くなります。安全性とパフォーマンスを犠牲にしない唯一の方法は3面ミラーですが、これは大量のスペースを犠牲にします(ただし、お客様がこれを行うのを見てきました。環境で必要な場合は、コストに見合う価値があるかもしれません)。
- 3TB以上のサイズのディスクの場合、3面ミラーはますます魅力的になり始めています。
つまり、あなたの場合、次のオプションがあります:
私はそれらを(降順で)次のようにランク付けします:
サイズに関係なくRAIDZ1を使用しません。後でそれらをより大きなディスクに交換したい場合、問題が表示されます(つまり、この方法でアップグレードしないと、ディスクを追加しないとストレージスペースを拡張できない可能性があります)。 )。
私は、パフォーマンスに関するこの質問に答えるために、テストZFSセットアップのベンチマークを行っています(古いダストサーバーのペアが灰から復活しました)。
私のセットアップは:
2x Intel Xeon L5640 CPU @ 2.27GHz(合計:12コア、HT無効)
96GiB DDR3 RAM @ 1333MHz
Adaptec 5805Zコントローラ、すべてのディスクをJBODとしてエクスポート(コントローラのバッテリバックアップ式NVRAMにより、書き込みキャッシュが有効)
12x 15kRPM 146GB SASディスク(Seagate ST3146356SS)
per-IP-over-Infiniband(20Gb/s Mellanox MT25204)を介したディスクDRBDレプリケーション(プロトコルC)
Debian/Stretch上のZFS 0.7.6
zpool create -o ashift = 12 .../dev/drbd {...}(注:DRBDは4KiBのレプリケーション「ユニット」サイズで機能します)
zfs create -o recordsize = 128k -o atime = off -o compression = off -o primarycache = metadata ...(最後の2つはベンチマーク目的のみ)
RAIDz2とRAIDz3の考えられるすべての組み合わせのbonnie ++の結果の下(5回の実行で平均 12の同期されたbonnie ++プロセスの数):
TEST: # data bandwidth
bonnie++ -p <threads>
for n in $(seq 1 <threads>); do
bonnie++ -r 256 -f -s 1024:1024k -n 0 -q -x 1 -y s &
done
# create/stat/delete operations
bonnie++ -p <threads>
for n in $(seq 1 <threads>); do
bonnie++ -r 256 -f -s 0 -n 128:0:0:16 -q -x 1 -y s &
done
CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
MiB/s: WR=278273, RW=150845, RD=487315
ops/s: SCr=132681, SDl=71022, RCr=133677, RDl=71723
CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
MiB/s: WR=276121, RW=158854, RD=480744
ops/s: SCr=132864, SDl=71848, RCr=127962, RDl=71616
CASE: 1*RAIDz2(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
MiB/s: WR=260164, RW=151531, RD=541470
ops/s: SCr=137148, SDl=71804, RCr=137616, RDl=71360
CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
MiB/s: WR=269130, RW=184821, RD=672185
ops/s: SCr=134619, SDl=75716, RCr=127364, RDl=74545
CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
MiB/s: WR=255257, RW=135808, RD=509976
ops/s: SCr=136218, SDl=74684, RCr=130325, RDl=73915
CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
MiB/s: WR=379814, RW=225399, RD=586771
ops/s: SCr=120843, SDl=69416, RCr=122889, RDl=65736
DATA: WR = Sequential Write
RW = Sequential Rewrite
RD = Sequential Read
SCr = Sequential Create
SDl = Sequential Delete
RCr = Random Create
RDl = Random Delete
パフォーマンスに関する限り:
2 * RAIDz2(4d + 2p + 0s)は、バランスのとれた読み取り/書き込みパフォーマンスの勝者です
1 * RAIDz3(8d + 3p + 1s)で最大の読み取りパフォーマンス(かなり奇妙な)
これらの結果を解釈/説明する方法について。私の1ペニー:
8つのデータディスクが128kのレコードサイズを正確に分割します。これは、なぜそれらが常に9または10のデータディスクよりも優れているかを説明します(?
RAIDz3はRAIDz2よりもパフォーマンスが悪いと思いますが、1 * RAIDz3(8d + 3p + 1s)のケースは非常に奇妙なことにこれと矛盾しています
2 * RAIDz2(4d + 2p + 0s)ケースの大幅に小さいVDEVサイズは、書き込みに対してパフォーマンスが大幅に向上する理由を説明します(?)
EDIT 1
@AndrewHenleのコメントへの回答として、さまざまな「チャンク」サイズの追加のベンチマークを以下に示します。残念ながら、bonnie ++は2の累乗以外のチャンクサイズを許可しません。そのため、ddの(5平均実行)に戻しました:PS:覚えておいてください、ZFS読み取りキャッシュ(ARC)は無効です
TEST: # WR: Sequential Write
rm /zfs/.../dd.*
for n in $(seq 1 <threads>); do
dd if=/dev/zero of=/zfs/.../dd.${n} bs=<chunk> count=<count> &
done
# RD: Sequential Read
for n in $(seq 1 <threads>); do
dd of=/dev/null if=/zfs/.../dd.${n} bs=<chunk> count=<count> &
done
CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
chunk: 1280k 1152k 1024k 128k 4k
count: 1024 (n/a) 1024 10240 327680(32768 for RD)
MiB/s: WR 418.64 (n/a) 434.56 404.44 361.76
RD 413.24 (n/a) 469.70 266.58 15.44
CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
chunk: 1280k 1152k 1024k 128k 4k
count: 1024 1024 1024 10240 327680(32768 for RD)
MiB/s: WR 428.44 421.78 440.76 421.60 362.48
RD 425.76 394.48 486.64 264.74 16.50
CASE: 1*RAIDz3(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
chunk: 1280k 1152k 1024k 128k 4k
count: 1024 1024 1024 10240 327680(32768 for RD)
MiB/s: WR 422.56 431.82 462.14 437.90 399.94
RD 420.66 406.38 476.34 259.04 16.48
CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
chunk: 1280k 1152k 1024k 128k 4k
count: 1024 (n/a) 1024 10240 327680(32768 for RD)
MiB/s: WR 470.42 (n/a) 508.96 476.34 426.08
RD 523.88 (n/a) 586.10 370.58 17.02
CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5
chunk: 1280k 1152k 1024k 128k 4k
count: 1024 (n/a) 1024 10240 327680(32768 for RD)
MiB/s: WR 411.42 (n/a) 450.54 425.38 378.38
RD 399.42 (n/a) 444.24 267.26 16.92
CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
chunk: 1280k 1152k 1024k 128k 4k
count: 1024 (n/a) 1024 10240 327680(32768 for RD)
MiB/s: WR 603.64 (n/a) 643.96 604.02 564.64
RD 481.40 (n/a) 534.80 349.50 18.52
私の1ペニーについて:
ZFSは書き込みをインテリジェントに最適化します(レコードサイズ未満のチャンクサイズでも)and/or(?)Adaptecコントローラー(non-volatile、512MiB)キャッシュは大幅に役立ちますこれに関して
言うまでもなく、ZFS読み取りキャッシュ(ARC)を無効にすると、レコードサイズに近い、またはレコードサイズを下回るチャンクサイズに対して非常に有害です。 Adaptecコントローラキャッシュは(驚くべきことに?)読み取り目的で使用されていないようです。結論:ベンチマークの目的でARCを無効にすると、「生の低レベル」のパフォーマンスに関する洞察を得ることができますが、(大規模なファイルのほとんど使用されないライブラリのような特定のケースは別として)本番用には不適切です。
VDEVのサイズと一致するようにチャンクサイズを調整すると表示されますnot正の役割を果たします[間違った仮定;編集2を参照]
編集2
RAIDzとブロックサイズ(ashift)およびレコードサイズ(ZFSファイルシステム)について:
RAIDzは、ashiftのサイズによって決定されるサイズのデータ/パリティブロックによって、基礎となるデバイスを埋めます
レコードではなく(ブロックではなく)チェックサムおよびコピーオンライト操作の「基本単位」
ideally、ZFSファイルシステムのレコードサイズは、VDEV内のデータディスクの数量(D)で割り切れる必要があります(ただし、2の累乗でなければならないため、達成が難しい場合があります)。
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzHowWritesWork
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzHowWritesWorkII
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSLogicalVsPhysicalBlockSizes
そして警告:
hotスペアが動作する可能性がありますnot非常に注意深く構成して機能を使用しない限り機能しませんtested
https://www.reddit.com/r/zfs/comments/4z19zt/automatic_use_of_hot_spares_does_not_seem_to_work/
BOTTOM LINE(他の応答ですでに述べられていることの確認)
(ストライピング)小さいVDEV-データディスクが少ない-大きいVDEVよりもパフォーマンスが優れています。パリティの計算/検証は明らかにコストのかかる操作であり、データディスクの量に対して線形よりも悪化します(8d <-> 2 * 4dの場合を参照)。
パリティディスクの数が多い同じサイズのVDEVは、パリティディスクとホットスペアの数が少ない場合よりもパフォーマンスが向上しますandより優れたデータ保護を提供します
パリティディスクを優先した後もスペアディスクがまだある場合は、ホットスペアを使用して、「真夜中に起こさないでください」という問題に対処してください。[警告!編集2を参照]
POST SCRIPTUM
私の最終的なユースケースは、(長期的な)時系列データベース(安定した中規模の書き込みと潜在的に非常に大きな散発的な読み取り)をホストしているため、I/Oパターンに関する詳細なドキュメントはほとんどありません(「 SSD」の推奨)、私は個人的に1 * RAIDz2(8d + 3p + 1s)を使用します:最大のセキュリティ、少し少ない容量、(2番目)最高のパフォーマンス
私の推奨は:
2 x 5ディスクRAIDZ1 + 2つのスペア
または
3 x 3ディスクRAIDZ1 +スペア
または
10ディスクRAIDミラー
またはスペア付きまたはなしの5または6ディスクのRAIDZ2 x 2
これは、使用しているディスクタイプによって異なります。 7200 RPMが2TBを超えるドライブの場合、RAIDZ2を使用します。 2TBでユーザーであれば、RAIDZ1で問題ありません。