web-dev-qa-db-ja.com

ZFSデータ損失シナリオ

大まかなZFSプール（150TB +）の構築を目指しています。特に、一部のデータのみが失われた場合とファイルシステム全体（例： ZFSにそのような違いがあるかどうか）。

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

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

深い技術知識に裏打ちされた逸話や架空のシナリオが本当にありがたいです。

ありがとう！

更新：

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

データは主に小さなファイルで、TBあたり約500kファイルです。

データは重要ですが、非常に重要ではありません。 ZFSプールを使用して48TBの「ライブ」データアレイ（3年ほど使用中）をミラーリングし、残りのストレージを「アーカイブ」データに使用することを計画しています。

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

ラックは建物のバックアップジェネレーターライン上にあると思われます。ラックに最大負荷で5分間ほど電力を供給できるAPC UPSが2つあります。

backupfilesystemsstoragezfs
27
Cyclone

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

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

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

しかし、これらすべてを通じて、目に見えるほどのデータの損失はありませんでした。ちょうどダウンタイム。このストレージの上にある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のバージョンやその他の機能がどれほど遅れているかはわかりません。純粋なストレージデプロイメントの場合、Nexentastorルートに行く（そして 経験豊富なパートナー と話す）ことをお勧めします。これは、専用のOSであり、Solarisの派生物でFreeBSDよりも重要なデプロイメントが実行されているためです。

22
ewwhite

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

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

それ以外は、20 TBサーバーでZEROデータを失いました。これには、ユーザーエラー、複数の電源障害、ディスクの誤った管理、構成の誤り、多数のディスクの故障などが含まれます。管理とSolarisの構成インターフェースはバージョン間で頻繁に、そして意地悪に変化し、常に変化する重要なスキルの目標を提示しますが、これは依然としてZFSの最良のオプションです。

（ひどいミスの後で）ZFSのデータを失わなかっただけでなく、それは常に私を守っています。データの破損はもう発生していません。過去20年間、どのような数のサーバーやワークステーションでも問題がありました。サイレント（または単に「かなり静か」）なデータ破損は、データがバックアップローテーションをロールオフするときに何度も私を殺しましたが、実際にはディスク上で破損しています。または、バックアップが破損したバージョンをバックアップした他のシナリオ。これは、一度に大規模な方法でデータを失うだけでなく、ほとんど常にバックアップされているよりもはるかに大きな問題でした。このため、私はZFSが大好きで、チェックサムと自動修復が10年間ファイルシステムの標準機能でなかった理由を理解できません。 （許可された、真に生死にかかわるシステムには、通常、整合性を保証する他の方法がありますが、それでも-企業データの整合性も重要です！）

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

SAS対SATAの引数、少なくともSASはZFSの場合は常にSATAよりも優先されるという提案に同意しません。そのかどうかはわかりません。コメントは、プラッターの回転速度、推定される信頼性、インターフェースの速度、またはその他の属性を参照していました（または「単にコストが高く、一般に消費者が使用していないため、優れている」と最近発表された業界）。調査（まだ確かにニュースにあります）により、SATAは実際には平均してSASで、少なくとも調査の重要なサンプルサイズで）存続していることが明らかになりました（確かにショックを受けました）。それがSATAの「エンタープライズ」バージョンか、コンシューマか、またはどのような速度であるかを思い出してください-しかし、私のかなりの経験では、エンタープライズモデルとコンシューマモデルは同じ統計的に有意な速度で失敗します（コンシューマドライブの時間がかかりすぎるという問題があります） -しかし、障害が発生した場合、これは企業では間違いなく重要です-しかし、それは私を悩ませていません。それはハードウェアの共同にもっと関連していると思いますそのような場合にボリューム全体をオフラインにすることができるntroller。しかし、それはSAS vs SATAの問題ではありません。ZFSが私を失敗させたことは一度もありません。その経験の結果として、現在、1/3エンタープライズと2/3コンシューマSATAの混合を使用していますさらに、適切に構成されている場合（たとえば、3方向ミラーのストライプ）、このSATAの組み合わせによる大きなパフォーマンスヒットは見られませんが、ここでもIOPSの需要が低いため、ショップの規模によって異なります。そして典型的なユースケース、YMMV。私のユースケースでは、ディスクごとの組み込みキャッシュサイズの方が、Platterの回転速度よりもレイテンシの問題にとって重要であることをはっきりと認識しました。

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

しかし、どちらにしても、ZFSは完全に優れています。

11
bubbles