ハードウェアRAIDを使用したZFSベストプラクティス

サーバーグレードのハードウェアを自由に使用できる場合、ハードウェアベースのRAID1などの上でZFSを実行することをお勧めしますか？ハードウェアベースのRAIDをオフにしてmirror、raidz zpool代わりにZFSを実行する必要がありますか？

ハードウェアRAID機能をオフにすると、ハードウェアRAIDベースのSATA2およびSASコントローラーは、非ハードウェアRAIDコントローラーよりも読み取りおよび書き込みエラーを隠しやすくなりますか？

カスタマイズ不可能なサーバーに関しては、ハードウェアRAIDコントローラーが実質的にコスト中立である（または、事前に構築されたサーバー製品のコストを下げる状況がある場合、その存在によりホスティング会社が補完的なIPMIを提供する可能性が向上するため）アクセス）、それはまったく避けるべきですか？しかし、それは求められるべきですか？

ZFSのアイデアは、ディスクがどのように動作しているかを可能な限り知らせることです。次に、最悪から改善まで：

• ハードウェアレイド（ZFSには実際のハードウェアに関する手がかりはまったくありません）
• JBODモード（潜在的なエキスパンダーに関する問題：より少ない帯域幅）、
• HBAモードが理想的（ZFSはディスクに関するすべてを知っている）

ZFSはハードウェアについて非常に妄想的であるため、隠れが少ないほど、ハードウェアの問題に対処できます。Sammitchが指摘したように、RAIDコントローラーの構成とZFSは、障害（ハードウェア障害）の場合、復元または再構成が非常に難しい場合があります。

一部のハードウェアRAIDコントローラーを含む標準化されたハードウェアの問題については、ハードウェアコントローラーに実際のパススルーモードまたはJBODモードがあることに注意してください。

Q.サーバーグレードのハードウェアを自由に使用できるようになった場合、ハードウェアベースのRAID1などの上でZFSを実行することをお勧めしますか？

A. ZFSをディスクに対して直接実行し、その間にRAIDの形式を使用しないことを強くお勧めします。RAIDカードを効果的に使用する必要のあるシステムがZFSの使用を妨げるかどうかは、データの復元力よりもZFSのその他の利点に関係しています。基本的に、単一のLUNをZFSに提供する基盤となるRAIDカードがある場合、ZFSはデータの復元力を向上させません。そもそもZFSを使用する唯一の理由がデータ復元力の向上である場合、それを使用するすべての理由を失っただけです。ただし、ZFSは、ARC / L2ARC、圧縮、スナップショット、クローン、およびその他のさまざまな改善も提供しますが、その場合でも、おそらくあなたのファイルシステムが最適です。

Q.ハードウェアベースのRAIDをオフにして、代わりにミラーまたはraidz zpoolでZFSを実行する必要がありますか？

A.はい、可能であれば。一部のRAIDカードはパススルーモードを許可します。それがある場合、これは行うことが望ましいことです。

Q.ハードウェアRAID機能をオフにすると、ハードウェアRAIDベースのSATA2およびSASコントローラーは、非ハードウェアRAIDコントローラーよりも読み取りおよび書き込みエラーを隠蔽する可能性が高くなりますか？

A.これは、問題のRAIDカードに完全に依存しています。マニュアルを確認するか、RAIDカードの製造元/ベンダーに問い合わせて確認する必要があります。はい、特にRAID機能を「オフ」にしても実際に完全にオフにならない場合は、そうです。

Q.カスタマイズできないサーバーに関しては、ハードウェアRAIDコントローラーが実質的にコストニュートラルな状況にある場合（または事前に構築されたサーバー製品のコストを下げる場合があります。補完的なIPMIアクセス）、それはまったく避けるべきですか？しかし、それは求められるべきですか？

A.これは最初の質問とほぼ同じ質問です。繰り返しますが、ZFSの使用のみがデータの復元力の向上であり、選択したハードウェアプラットフォームがZFSに単一のLUNを提供するRAIDカードを必要とする場合（または複数のLUNがありますが、それらにZFSストライプがあります）、あなたはやっていますデータの復元力を向上させるものは何もないため、ZFSの選択は適切でない場合があります。ただし、他のZFS機能のいずれかが有用であることがわかった場合でも、それは役立つ可能性があります。

さらに懸念を加えたいと思います-上記の答えは、ZFSの下でハードウェアRAIDカードを使用しても、データの復元力を改善する能力を削除する以外にZFSに害を及ぼさないという考えに基づいています。真実は、それは灰色の領域に近いということです。ZFSには、rawディスクではなくマルチディスクLUNを渡した場合に必ずしも動作しないさまざまな調整可能な要素や前提条件があります。これのほとんどは適切なチューニングで無効にすることができますが、箱から出してすぐに、個々のスピンドルの上にいた場合のように大きなRAID LUNの上にあるZFSで効率的ではありません。

さらに、ZFSが従来のファイルシステムとは対照的にLUNと非常に異なる方法で通信する方法は、RAIDコントローラーのコードパスと、慣れていないワークロードを呼び出すことが多く、奇妙につながる可能性があることを示唆するいくつかの証拠があります。最も注目すべきは、おそらく、個別のログデバイスも提供していない場合、単一のLUNの上に配置されたプールでZIL機能を完全に無効にすることによって、あなた自身を支持することでしょう。プールに個別のrawログデバイスを提供する（これは、可能な限りRAIDカードのLUNではない）。

HP ProLiant SmartアレイRAID構成の上でZFSをかなり頻繁に実行しています。

どうして？

• ブートパーティションではなく、データパーティションのZFSが好きだからです。
• LinuxとZFSのブートは、おそらく私にとって今のところ十分に簡単ではないからです。
• HP RAIDコントローラーはRAWデバイスのパススルーを許可しないためです。複数のRAID 0ボリュームを構成することは、RAWディスクとは異なります。
• サーバーのバックプレーンは通常、ドライブベイを特定のコントローラー専用にしたり、2つのコントローラー間で業務を分割したりするのに十分な柔軟性がないためです。最近では、8ベイおよび16ベイのセットアップが最も頻繁に見られます。物事がどうあるべきかをセグメント化するのに必ずしも十分ではありません。
• しかし、私はまだZFSのボリューム管理機能が好きです。zpoolを使用すると、物事を動的に切り分け、利用可能なディスク容量を最大限に活用できます。
• 圧縮、ARC、L2ARCはキラー機能です！
• ハードウェアRAID上で適切に設計されたZFSセットアップは、依然として良好な警告と障害警告を提供しますが、ハードウェアのみのソリューションよりも優れています。

例：

RAIDコントローラーの構成。

[root@Hapco ~]# hpacucli ctrl all show config

Smart Array P410i in Slot 0 (Embedded)    (sn: 50014380233859A0)

   array B (Solid State SATA, Unused Space: 250016  MB)
      logicaldrive 3 (325.0 GB, RAID 1+0, OK)

      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, Solid State SATA, 240.0 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, Solid State SATA, 240.0 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, Solid State SATA, 240.0 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, Solid State SATA, 240.0 GB, OK)

ブロックデバイスリスト

[root@Hapco ~]# fdisk  -l /dev/sdc

Disk /dev/sdc: 349.0 GB, 348967140864 bytes
256 heads, 63 sectors/track, 42260 cylinders
Units = cylinders of 16128 * 512 = 8257536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       42261   340788223   ee  GPT

zpool設定

[root@Hapco ~]# zpool  list
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
vol1   324G  84.8G   239G    26%  1.00x  ONLINE  -

zpool詳細

  pool: vol1
 state: ONLINE
  scan: scrub repaired 0 in 0h4m with 0 errors on Sun May 19 08:47:46 2013
config:

        NAME                                      STATE     READ WRITE CKSUM
        vol1                                      ONLINE       0     0     0
          wwn-0x600508b1001cc25fb5d48e3e7c918950  ONLINE       0     0     0

zfsファイルシステムのリスト

[root@Hapco ~]# zfs list
NAME             USED  AVAIL  REFER  MOUNTPOINT
vol1            84.8G   234G    30K  /vol1
vol1/pprovol    84.5G   234G  84.5G  -

通常、RAIDアレイで構成されたディスク上でZFSを実行しないでください。ZFSはRAIDモードで実行する必要がないことに注意してください。個々のディスクを使用できます。ただし、ほぼ99％の人がRAID部分でZFSを実行しています。ディスクを単にストライプモードで実行することもできますが、それはZFSの不十分な使用です。他のポスターが言ったように、ZFSはハードウェアについて多くを知りたいと思っています。ZFSは、JBODモードに設定できるRAIDカードにのみ接続するか、できればHBAに接続する必要があります。IRC Freenodeチャネル#openindianaにジャンプします。チャンネルのZFSエキスパートが同じことを教えてくれます。HBAを提供しない場合は、ホスティングプロバイダーにJBODモードを提供するよう依頼してください。

要するに、ZFSの下でRAIDを使用すると、ZFSを使用するという考えが単純に失われます。どうして？— RAIDではなく、純粋なディスクで動作するように設計されているため。

すべての人にとって...すべてのRAIDに対するZFSは完全な痛みであり、MADの人々によってのみ行われます！...非ECCメモリでZFSを使用するようなものです。

サンプルを使用すると、よりよく理解できます。

• ZFS over Raid1、電源がオフにされていないときに1つのディスクが少し変更されました...知っているすべてをZ索してください、ZFSは読み込まれたディスクに応じていくつかの損傷が表示されるかどうかを確認します）...失敗がVDEV部分にある場合... ZPOOL全体がすべてのデータを永久に失います。
• ZFS over Raid0、1つのディスクの電源がオフになっていないときにビットが変更されています...知っているすべてをこじ開けます（Raidコントローラーはそのビットが変更されたことを認識せず、両方のディスクが正常であると考えていました）...失敗はVDEV部分にあります... ZPOOL全体がすべてのデータを永久に失います。

ZFSが優れているのは、ディスクに電源が供給されていない場合（RAIDコントローラーではできない）、要求されずに何かが変更された場合などに変更されたビットを検出することです。

RAMモジュール内のビットが要求されずに自発的に変化する場合と同じ問題です...メモリがECCの場合、メモリは自己修正します。そうでない場合、そのデータは変更されているため、データは変更されたディスクに送信されます。障害がVDEV部分にある場合、変更がUDEV部分にないことをp索してください... ZPOOL全体がそのすべてのデータを永久に失います。

これはZFSの弱点です... VDEVが失敗すると、すべてのデータが永久に失われます。

ハードウェアRAIDおよびソフトウェアRAIDは、自発的なビット変更を検出できず、チェックサムを持たず、最悪のRaid1レベル（ミラー）であり、すべての部品を読み取って比較するわけではなく、すべての部品が常に同じデータを持っていると思います（つまりそれは大声で）レイドはデータが他のもの/方法によって変更されていないことを疑います...しかし、ディスク（メモリとして）は自発的なビット変更を起こしやすいです。

非ECC RAMでZFSを使用したり、レイドされたディスクでZFSを使用したり、ZFSにすべてのディスクを表示させたり、VDEVやPOOLを台無しにするレイヤーを追加したりしないでください。

そのような失敗をシミュレートする方法... PCの電源を切り、そのRAID1のディスクを1つ取り出して1ビットだけ変更します... RAIDコントローラがそれが変更されたことを認識できないか確認します...チェックサムに対して、一致しない場合、別の部分から読み取ります...失敗（ハードウェア不可能読み取りを除く）のためにRAIDは二度と読み取りません。 ）... RAIDが読み取る場所が「ちょっと、そこから読み取れない、ハードウェア障害」という場合にのみ、別のディスクから読み取ろうとします... ZFSは、チェックサムが読み取り場所と一致しない場合に別のディスクから読み取ります「ねえ、私はそこから読むことができません、ハードウェアが故障します」と言います。

私がそれを非常に明確にしたい...あらゆるレベルのRaidに対するZFSは、痛手であり、データに対するトータルリスクです！非ECCメモリ上のZFSも同様です。

しかし、誰も言うことはありません（私以外）：

• 内部キャッシュを備えたディスク（SHDDだけでなく、8Mibから32MiBのキャッシュを備えたディスクなど）を使用しないでください。そのようなキャッシュには非ECCメモリを使用するディスクもあります。
• SATA NCQ（書き込みをキューに入れる方法）を使用しないでください。電源が切れるとZFSが台無しになる可能性があります。

では、どのディスクを使用するのでしょうか？

• すべてのキューが電源障害の場合にディスクに書き込まれ、内部でECCメモリを使用することを保証する内部バッテリーを備えたディスクは、ごくわずかです（それらのすべてを備えたものは非常に少なく、高価です）。

しかし、ほとんどの人はこのすべてを知らず、問題を抱えたことはありません...私は彼らに言います：ラッキーが消える前に、なんてラッキーか、宝くじを買う。

リスクがあります...そのような不一致が発生する可能性があります...ので、より良い答えは次のとおりです。

• ZFSとデータが実際に保存される場所（RAM、RAID、NCQ、内部ディスクキャッシュなど）の間にレイヤーを配置しないようにしてください...余裕がある限り。

私は個人的に何をしますか？

• いくつかのレイヤーを追加します... USB 3.1 Gen2タイプCエンクロージャーで各2.5インチSATA III 7200 rpmディスクを使用し、一部のエンクロージャーをPCに接続するUSB​​ 3.1 Gen 2タイプAハブに接続し、他は別のハブに接続しますPCの別のルートポートなどに接続する
• システムの場合、不変（LiveCDのような）Linuxシステムを使用しているため、ZFS（Raid0レベル）で内部sataコネクターを使用し、それぞれが内部ディスク上の同一のコンテンツを起動します... （1GiBシステム未満）...また、トリックを使用してシステムをファイルに格納し、起動時にクローンを作成するRAMマップドライブを使用するため、起動後にすべてのシステムがRAMで実行されます... DVDも同じ方法で起動できるので、内蔵ディスクに障害が発生した場合、DVDで起動し、システムが再びオンラインになります... SystemRescueCDと同様のトリックですが、ISOファイルがもう少し複雑になるため、内蔵ZFSまたは単なる本物のDVDであり、2つの異なるバージョンは必要ありません。

Raidに対するZFSに少し光を当てることができれば幸いです、物事がうまくいかないときは本当に痛みです！