ZFSデータ損失シナリオ

大規模なZFSプール（150TB +）の構築を検討しています。ハードウェアの故障によるデータ損失シナリオについて、特に、一部のデータが失われたインスタンスとファイルシステム全体を区別する人々の体験を聞きたいです（ ZFSにそのような違いがある場合でも）。

たとえば、外部ドライブエンクロージャの電源が切れたり、コントローラカードに障害が発生したりしたために、vdevが失われたとします。私が読んだものからプールはフォールトモードになりますが、vdevが返された場合、プールは回復するはずですか？か否か？または、vdevが部分的に破損している場合、プール全体や一部のファイルなどが失われますか？

ZILデバイスに障害が発生するとどうなりますか？または、いくつかのZILの1つだけですか？

深い技術的知識に裏打ちされた、ありとあらゆる逸話や仮説シナリオを歓迎します！

ありがとう！

更新：

私たちは中小企業（9人程度）なので安価でこれを行っていますが、かなりの量の画像データを生成します。

データは大部分が小さなファイルであり、TBあたり約50万ファイルとカウントしています。

データは重要ですが、非常に重要ではありません。ZFSプールを使用して48TBの「ライブ」データアレイをミラーリングし（3年程度使用中）、残りのストレージを「アーカイブされた」データに使用する予定です。

プールはNFSを使用して共有されます。

ラックはおそらく建物のバックアップ発電機ライン上にあり、5分間程度全負荷でラックに電力を供給できる2つのAPC UPSがあります。

適切な方法で設計すれば、ZFSのデータ損失の可能性を最小限に抑えることができます。ただし、プールに保存しているものについては説明していません。私のアプリケーションでは、主にVMWare VMDKを提供し、iSCSI経由でzvolをエクスポートしています。150TBは些細な量ではないため、スケーリングのアドバイスについては専門家に頼ります。

ZFSでデータを失ったことはありません。

私は他のすべてを経験しました：

• 多数のSSD障害（一部はL2ARCの義務）
• 複数の故障したプールディスク
• ニアラインSASディスクとの最終的な交換を必要とする予測不能なSATAドライブエラー
• 誤って設定された重複排除の取り組みによるフォールアウト
• 破損または障害のあるzpoolのセーフモードからの回復
• 不良な10GbE NICポート/ケーブル
• 頻繁なOSクラッシュ
• 落雷 ...

しかし、そのすべてを通じて、目に見えるほどのデータの損失はありませんでした。ただのダウンタイム。VMWare VMDKがこのストレージの上にある場合、イベントの後にfsckまたはリブートが必要になることがよくありましたが、他のサーバークラッシュよりも悪くはありませんでした。

ZILデバイスの損失に関しては、それは設計、保存しているもの、I / Oおよび書き込みパターンに依存します。私が使用するZILデバイスは比較的小さく（4GB〜8GB）、書き込みキャッシュのように機能します。ZILデバイスをミラーリングする人もいます。ハイエンドのSTEC SSDデバイスを使用すると、ミラーリングのコストが高くなります。代わりに単一のDDRDrive PCIeカードを使用します。バッテリー/ UPS保護を計画し、スーパーキャパシターバックアップを備えたSSDまたはPCIeカードを使用します（RAIDコントローラーBBWCおよびFBWC実装と同様）。

私の経験のほとんどは、Solaris / OpenSolarisとNexentaStorの側面にあります。FreeBSDで人々がZFSを使用していることは知っていますが、zpoolバージョンや他の機能がどれほど遅れているかはわかりません。純粋なストレージ展開の場合、専用のOSであり、FreeBSDよりもSolaris派生物で実行される重要な展開があるため、Nexentastorルートに進むこと（および経験豊富なパートナーに相談すること）をお勧めします。

OpenSolarisの最後のバージョンで両方のZILを誤って上書きしたため、プール全体が取り返しのつかないほど失われました。（私にとって本当に悪い間違いです！ZILを失うとプールを失うことになることを理解していませんでした。幸いなことに、ダウンタイムでバックアップから回復しました。）

ただし、バージョン151a（ZPoolのバージョンの意味がわからない）から、この問題は修正されました。そして、私はそれが機能することを証明できます。

それ以外に、20tbサーバー上のZEROデータを失いました。これには、ユーザーエラー、複数の電源障害、ディスクの誤管理、構成の誤り、多数の障害ディスクなどが含まれます。 Solarisの構成インターフェイスはバージョンごとに頻繁に変更され、大幅に変化するスキルターゲットを提示しますが、依然としてZFSの最適なオプションです。

ZFSでデータを失ったことがない（ひどい間違いの後）だけでなく、常に私を保護しています。私はもうデータの破損を経験していません-これは過去20年間、私がしていることで、任意の数のサーバーとワークステーションで悩まされてきました。サイレント（または「かなり静かな」）データ破損は、データがバックアップローテーションからロールオフするときに何度も殺されましたが、実際にはディスク上で破損しています。または、バックアップが破損したバージョンをバックアップした他のシナリオ。これは、データを一度に大量に失うことよりもはるかに大きな問題であり、ほとんどの場合、とにかくバックアップされます。このため、私はZFSが大好きであり、チェックサムと自動ヒーリングが10年間ファイルシステムの標準機能でなかった理由を理解することはできません。（付与された真の生死のシステムには、通常、整合性を保証する他の方法があり、

賢明なことですが、ACL-hellに降りたくない場合は、ZFSに組み込まれているCIFSサーバーを使用しないでください。Sambaを使用します。（ただし、NFSを使用すると言いました。）

SAS対SATAの議論には同意しません。少なくともZFSでは、SASはSATAよりも常に好まれるという提案です。そのコメントがプラッタの回転速度、推定された信頼性、インターフェイス速度、またはその他の属性を参照していたかどうかはわかりません。（または単に「コストが高く、一般に消費者に使用されないため、優れている」。最近リリースされた業界調査（まだニュースでは確か）で、SATAは実際に少なくともSAS調査の重要なサンプルサイズ（確かに驚いた）。それがSATAの「エンタープライズ」バージョンであるか、コンシューマーであるか、またはどのような速度であったかは思い出せませんが、私のかなりの経験では、エンタープライズモデルとコンシューマーモデルは同時に失敗します統計的に有意な割合。（しかし、企業では間違いなく重要であるが、消費者のドライブが失敗時にタイムアウトするのに時間がかかりすぎるという問題があります-しかし、それは私をかみませんでしたし、ボリュームがオフラインの場合はそうですが、これはSAS vs SATAの問題ではなく、ZFSで失敗することはありませんでした。その経験の結果、今では1/3のエンタープライズSATAドライブと2/3のコンシューマSATAドライブを使用しています。）さらに、適切に構成すると（たとえば、3面ミラーのストライプ）、このSATAの組み合わせで大きなパフォーマンスヒットは見られませんでしたが、IOPSの需要が低いため、お店の大きさと典型的なユースケース、YMMV。私のユースケースでは、ディスクごとのビルトインキャッシュサイズが、プラッタの回転速度よりもレイテンシの問題に重要であることは間違いなく気付きました。

つまり、コスト、スループット、IOPS、データの種類、ユーザー数、管理帯域幅、一般的なユースケースなど、複数のパラメーターを持つエンベロープです。SASが常に正しい解決策であると言うことは、これらの要因の順列の大きな宇宙を無視することです。

しかし、いずれにせよ、ZFSは絶対に揺れ動きます。