ZFSは突然の電力損失に対処できますか？ （ディスク自体に障害が発生していないか、信頼性が低下していない場合、どのイベントによってプールが回復不能になるか）
すべてのリソースによると、ZFSにはfsckやリカバリツールがなく、ZILにはバッテリーバックアップSSDを使用しています。
プラグが突然引っ張られた場合（UPSなどにもかかわらず、完全な電力損失が発生しますが、物理的な損傷やヘッドクラッシュなどはないと想定）、SSDはキャッシュをnvramに書き込んでから、静かになります。
再起動時に、ZFSが一貫した状態になり（一部のデータが失われた場合でも）、プールが使用可能/読み取り可能になる可能性はどのくらいありますか？
更新
私は実際にもっと近いことを尋ねるつもりだと思います。データが基本的に無傷であるにもかかわらず、ZFSがプールを読み取ることができなくなる状況につながるイベントは何ですか？ ZFSが何から回復できるか（または適切なハードウェアがあれば回復できるか）、何が回復できないか（または適切なハードウェアがないと回復できないか）は明確ではありません。これは、内部で自己チェックと修正を行うためです。明らかに不十分な冗長性+ディスク障害（または他の主要なハードウェアの問題）は1つのケースであり、ファームウェア/ソフトウェアのバグによる完全なワイプ/上書きは別のケースです。しかし、ストレージメディア、ハードウェア、およびソフトウェアがまだ確実に/適切に機能していると仮定すると、他に何がうまくいかなかったのか、結果としてプール？プールの修正に関する制限はどこにありますか？それができない前にどのような状況が発生しなければならず、それらを引き起こすために何が起こらなければなりませんか？
再起動時に、ZFSが一貫した状態になり（一部のデータが失われた場合でも）、プールが使用可能/読み取り可能になる可能性はどのくらいありますか？
ZFSはトランザクションのように動作します データベース管理システム 従来のファイルシステムのように、更新時に古いデータがその場で上書きされないという点で。代わりに、新しいデータがディスクの他の場所に書き込まれ、ファイルシステムのメタデータ構造が更新されて新しいデータを指すようになります。その後、古いデータのブロックが解放され、ファイルシステムで再利用できるようになります。このように、新しいデータの更新が永続ストレージに100％コミットされていない場合、突然の電力損失により、データの古いコピーがそのまま残ります。ブロックの半分などが置き換えられないため、データが破損します。
さらに、ZFSは 高度なチェックサムスキーム を使用して、ファイルシステムが誤って書き込まれたデータや破損したデータを検出できるようにします。
冗長ストレージでZFSを使用している場合、この同じスキームにより、ファイルシステムは、ファイルシステムを修復するときにデータの2つ以上の冗長コピーから選択できます。つまり、特定のブロックのコピーが2つあり、そのうちの1つだけが保存されているチェックサムと一致する場合、ファイルシステムは不良コピー/コピーをクリーンなもので修復する必要があることを認識しています。
これらの修復は、データを読み取ったり変更したりしようとしたときに、要求されたブロックが完全にコーシャではないことをファイルシステムが認識した場合、または zfs scrub 操作。ファイルシステムは通常の操作過程でハードウェアデータの損失を検出しないため、ほとんどアクセスされないファイルがあるZFSプールで定期的に実行するようにスクラブをスケジュールするのが一般的です。危険なハードウェアで実行されているZFSプールでは、スクラブのたびにいくつかの固定ブロックが表示されるのが一般的です。
スクラビングは、他のUnixタイプのファイルシステムのfsckに似ていますが、ファイルシステムがマウントされて使用可能であるときにオンラインで行われる点が異なります。これはバックグラウンドで発生し、プールがアイドル状態の場合にのみ発生します。また、fsck実装は通常、データではなくメタデータのみをチェックしますが、ZFSは両方をチェックサムするため、両方のエラーを検出できます。これらの整合性メカニズムが、ブロックの1つを置き換える必要があると判断した場合、チェックサムを使用して、破損したコピーを置き換えるコピーを決定できます。
ストレージメディア、ハードウェア、およびソフトウェアが引き続き確実に/適切に機能していると仮定すると、プールが失われるためには、他に何が問題になっている必要がありますか？
私の知る限り、そのようなケースはありません。あなたが言及した3つの事柄のいずれかが失敗したか、ZFSがプールをマウントしてそこから読み取ります。
明らかに不十分な冗長性+ディスク障害（または他の主要なハードウェアの問題）は1つのケースです
はい、それはあなたが考えているよりも微妙な場合に起こる可能性があります。
単純な2面ミラーを取ります。ディスクの1つがコンピューターから物理的に取り外されているか、少なくとも何らかの理由でアクセスできないことを考えていると思います。しかし、セクター12345が両方のディスクで破損していると想像してください。次に、ZFSのすべての巧妙なチェックサムと冗長性は役に立ちません。両方のコピーが破損しているため、そのセクターを含むブロック全体を読み取ることができません。
しかし、ここに巧妙な点があります。ZFSはファイルシステムとボリュームマネージャーの両方であるため、ハードウェアRAID + ext4 または LVM2 + ext4のようなラッシュアップとは対照的です— zpool statusコマンドは、どのファイルが回復不能に損傷しているかを示します。そのファイルを削除すると、プールはすぐに損傷のない状態に戻ります。問題は削除されました。ファイルシステムをRAIDおよびLVM部分から分離するラッシュアップはそれを行うことができません。
それができない前にどのような状況が発生しなければならず、それらを引き起こすために何が起こらなければなりませんか？
私が知っている唯一のケースは、上記の例のようなものです。データの破損により、キーファイルシステムメタデータの冗長コピーが十分に損傷し、ZFSが読み取ることができなくなりました。
そのため、今日の非常に大きなディスクでは、100兆ビットになります。 —少なくともデュアル冗長性を備えたZFS（またはその他のRAIDまたはLVMシステム）を構成することをお勧めします。 ZFSの用語では、これは raidz2 、3ウェイミラー、またはそれ以上を意味します。
とはいえ、ZFSは通常、通常のファイルデータに使用される通常の冗長性レベルを超えて、すべてのファイルシステムメタデータの追加コピーを格納します。たとえば、2面ミラーは、通常のユーザーデータの2つのコピーを保存しますが、すべてのメタデータの4つのコピーを保存します。パフォーマンスのためにこれをダイヤルバックすることはできますが、完全にオフにすることはできません。
ZFSマニュアルには、 ZFS障害モード に関する章があります。
私のコメントが長くなっているので、この答えは役に立つようです。 Warren Youngは、彼の回答ですべての基本的な考慮事項をすでに正しく概説しているので、「SLOGデバイスをミラーリングするかどうか」という部分に焦点を当てます。
状況は次のとおりです。
私はZFSシステムに近づき、警告なしにトリップして、非常に重い着信データセッションの途中で誤ってP3500 ZILをヤンクアウトすると、システムがすぐにフリーズします。優れたPSUとMBのおかげで、他のHDD/SSDは電気的過渡現象の影響を受けません。 ZILを除いて、他のすべてのディスク/ボリュームは冗長でした。最近のデータ、プール全体、または「依存する」を失ったばかりで、依存する場合は何に依存しますか？ ）
考えてみると、通常、ZILはすべてのプールディスクに保存されているため、プールと同じ冗長性を享受できます。速度を上げるために別のデバイスの外部に移動する場合、冗長性が必要な場合は、自分で別のミラーを確立する必要があります。ただし、それがない場合でも、ZIL内のごく少量のデータが失われ（バックアップからの復元が必要になるのは、同期書き込みが必要で、アプリケーションデータが破損している場合のみ）、プール全体の一貫性が失われることはありません（すべての場合にバックアップから復元されます）。
さて、何を選ぶべきかについての質問のために：
ある時点で、ハードウェア仕様全体にお金を分散させるときに、何に対して設計するかを選択する必要があります。
それはあなたの状況に依存します（いつものように）：
- プレーンなデータストレージ（クラシックファイルサーバー）しかない場合、SMBは非同期であり、突然の電力を処理できるため、ZILをSLOGデバイスに移動してもほとんど（または何も）得られません。 NFSの場合、それは選択/ソフトウェアに依存すると思いますが、最近ではほとんどの人が3つの主要なシステムすべてでSMBを使用しています。
- 速度と整合性が必要な場合（主にデータベースとVMストレージ））、
sync=alwaysで実行する必要があり、ZIL用のSLOGデバイスが必要になります。非常に遅い。このような場合、SLOGデバイスをミラーリングするか、「SSD /コントローラーのハードウェアの突然の障害または取り外しと突然の電力損失」というイベントが発生することはほとんどなく、それなしで実行できると判断できます。次に、コストが妥当かどうかを判断できます。そうではありません（ほとんどの場合、残りのハードウェアは非常に高価ですが、それでも商用製品よりもはるかに安価です）。 - 安心したいが予算が限られている場合は、Intel SSD 730をお勧めします。「ゲーマー」または「マニア」製品として販売されていますが、データシートを比較すると、内部的には小さい3700ラインと非常によく似ています。 。また、Web状態のいくつかのソースとして、スーパーキャパシタも備えています。もちろん、公式にはIntelはそれを認めません。なぜなら、そうすれば誰も高価なものを買わないからです。
編集：あなたのコメントに関して：
NFS/ESXi/syncが主要なユースケースになります。コストとリスクが私の肩にかかっているので、推奨されるアプローチを取得するのではなく、リスクを理解しようとしています-個別のZILが停電の一部として失敗した場合（冗長で、損失が保護されることを意図していたかどうかにかかわらず、など）、ただし他に影響はありませんが、ZILによって受信され、まだプールに書き込まれていないデータ（最悪の場合、最後の数秒間のデータ）に限定され、回復可能な損失/破損の可能性があります。または、突然のZIL +電源障害（同時に他の種類の障害がないと仮定すると）プールが回復不能になる可能性がありますか？
すべてのポイントは、例を想定した場合にのみ有効であり、（a）ZFSのバグ、（b）すべてのプールディスクの完全なハードウェア障害、（c）人的エラー/悪意のいずれも当てはまりません。
- プールデータは安全であり、保存されているデータの整合性が維持されます。つまり、プールをインポートでき、ZFSの観点からは破損しません。これは、ZFSおよびその設計の一部における電力損失の通常の動作です。
- 電源が復旧した後、通常はZILが読み取られ、失われたトランザクションがやり直されます（RDBMSと同様）。これで、次のことが可能になります。
- SLOGデバイスが破損していないか、破損したパーツをSLOGミラーから復元できます。すべてが通常どおりに機能するため（最終的な再シルバー化後）、最後の5秒間がプールに書き戻されます。
- SLOGデバイスが破損しています：ZILを正しくロールバックできません。部分的なロールバックが試行されるかどうかはわかりませんが、（すべてのトランザクションが必要なため）あなたの観点からはそれほど重要ではないため、最後の5秒間は破棄されると思います。
プールの観点からは、この最悪の場合でもかなり良好です-5秒が失われますが、プールはインポート可能です（バージョンが 少なくとも19 の場合）。しかし、アプリケーションの観点からは、これは重大なエラーである可能性があります。アプリケーションは5秒間の同期データを書き込んだだけで、正常に書き込まれたことを確認し、再起動後にデータが欠落していますが、アプリケーションはこれを認識していません。正確なエラーはアプリケーションによって異なります。 DBMSに一貫性がなく、修復が必要な場合、大きなデータファイルが読み取れない場合、システムファイルによってクラッシュを見つけるのが困難な場合、暗号化されたストレージパーティションが完全に回復できない場合があります。これらはすべて、一部が欠落しているか間違っているためです。
あまり言及されていないもう1つのポイントは、SSDが予期せず停止する可能性があるため、HDDよりもミラーリングの方が重要になりますが、工場出荷時に新品の2つの同一のSSDをシステムに挿入すると、同時に障害が発生する可能性があります。
Solaris ZFS、同期書き込み、およびZILの説明 に関する適切な要約と、 ZFS ZIL SLOGデバイスを失った場合の影響）に関する詳細を読むことができます。それらを理解する 。 Oracleのドキュメント は少し短いですが、通常の操作では、SLOGに障害が発生するとZILがSLOGからプールデバイスに自動的に移動することにも言及しています（もちろん、5秒間の脆弱性があります）。
マニュアルページには、ZILを使用せずにプールをインポートする方法に関する情報も記載されています。
zpool import -a [-DfmN] [-F [-n]] [-c cachefile|-d dir] [-o mntopts] [-o
property=value]... [-R root]
-m Allows a pool to import when there is a missing log
device. Recent transactions can be lost because the log
device will be discarded.
私は4台のサーバーとラップトップで5年以上ZFSを使用しています。書き込みの多いサーバーで電源障害がほとんど発生せず（UPSファームウェアが壊れて誤ったデータを報告）、気づかなかったANY *データエラー/プールマウントの問題（これは、最新のトランザクションによるデータ損失がなかったことを意味するわけではありません）前に説明したように書き終えていなかった/ CoW）
* ZFSマニュアルから逸脱したときの1つのイベントを除く：1つのディスクにZFSがありました（iSCIS SAN LUNはホストにマップされています））KVMゲストと最初のデータコピー後、キャッシュモードをWriteBackからWriteThroughに変更するのを忘れました。プール（5TB）は読み取り可能でしたが、20k以上のエラーが報告されました。バックアップサーバーからのデータを使用してプールを再作成する必要がありました-zfsスナップショットとzfs send/receive2分のデータのみが失われました（つまり、はるかに悪化する可能性があります）ECCメモリを使用し、すべての書き込みバッファリングを無効にします（少なくともBBU / FBUなし–別のストーリーの対象）、= RTFMそしてZFSは堅実です。