web-dev-qa-db-ja.com

ZFSホットスペアとより多くのパリティ

私はZFSに少し慣れていませんが、12台の物理ドライブを備えた新しいストレージプールを起動します。

私の現在の計画は、10台のドライブと2つのホットスペアにRAIDZ2を配置することです。

しかし、12台のドライブすべてでRAIDZ3を使用し、ホットスペアがないほうがよいのではないでしょうか。

その理由は、ホットスペアは基本的に電源が投入されたアイドル状態のドライブであるためです。彼らが召喚されるまでには数ヶ月から数年かかる場合があり、そのとき私はそれらが実行可能でないことを知るかもしれません。それらがRAIDストライプの一部だった場合、少なくともそれらが良かったかどうかについてフィードバックを得ることができました。

私はこれについてウェブ上であまり議論していません。誰かアドバイスはありますか?

7
AlanObject

ホットスペアについて

ホットスペアは固有のプールに設定されますが、障害が発生した場合、プールの任意の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面ミラーはますます魅力的になり始めています。

つまり、あなたの場合、次のオプションがあります:

  1. 使用可能な9ディスク:(Z3 with 9 + 3)
  2. 8つのディスクが使用可能:(Z2 with 4 + 2)++(Z2 with 4 + 2)
  3. 使用可能なディスク5枚:(2ミラー)* 5 ++(ホットスペア)* 2
  4. 4枚のディスクが使用可能:(3ミラー)* 4

私はそれらを(降順で)次のようにランク付けします:

  • 使用可能スペースに関して:1、2、3、4
  • 安全性の面で:1、2/4、3
  • 速度に関して:4、3、2、1
  • ドライブの拡張/追加機能に関して:3、4、2、1

サイズに関係なくRAIDZ1を使用しません。後でそれらをより大きなディスクに交換したい場合、問題が表示されます(つまり、この方法でアップグレードしないと、ディスクを追加しないとストレージスペースを拡張できない可能性があります)。 )。

9
user121391

私は、パフォーマンスに関するこの質問に答えるために、テスト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ファイルシステム)について:

そして警告:

BOTTOM LINE(他の応答ですでに述べられていることの確認)

  • (ストライピング)小さいVDEV-データディスクが少ない-大きいVDEVよりもパフォーマンスが優れています。パリティの計算/検証は明らかにコストのかかる操作であり、データディスクの量に対して線形よりも悪化します(8d <-> 2 * 4dの場合を参照)。

  • パリティディスクの数が多い同じサイズのVDEVは、パリティディスクとホットスペアの数が少ない場合よりもパフォーマンスが向上しますandより優れたデータ保護を提供します

  • パリティディスクを優先した後もスペアディスクがまだある場合は、ホットスペアを使用して、「真夜中に起こさないでください」という問題に対処してください。[警告!編集2を参照]

POST SCRIPTUM

私の最終的なユースケースは、(長期的な)時系列データベース(安定した中規模の書き込みと潜在的に非常に大きな散発的な読み取り)をホストしているため、I/Oパターンに関する詳細なドキュメントはほとんどありません(「 SSD」の推奨)、私は個人的に1 * RAIDz2(8d + 3p + 1s)を使用します:最大のセキュリティ、少し少ない容量、(2番目)最高のパフォーマンス

4
Cédric Dufour

私の推奨は:

2 x 5ディスクRAIDZ1 + 2つのスペア

または

3 x 3ディスクRAIDZ1 +スペア

または

10ディスクRAIDミラー

またはスペア付きまたはなしの5または6ディスクのRAIDZ2 x 2

これは、使用しているディスクタイプによって異なります。 7200 RPMが2TBを超えるドライブの場合、RAIDZ2を使用します。 2TBでユーザーであれば、RAIDZ1で問題ありません。

3
ewwhite