ホームNASにおけるライトバックキャッシュのデータリスクの変化について

ライトバックキャッシュは、保護された不揮発性ストレージが書き込みを確保する前に書き込みが確認された場合にのみ、ホームNASのデータリスクを増加させます。

ファイルコピーはディスクが動作し続けていてもすぐに終了しますか？それともVMやデータベースのパフォーマンス向上のためにSSDキャッシュを検討していますか？重要なのは単にライトバックが有効かどうかではなく、どの層が完了確認を送信し、電源、OS、コントローラ、またはキャッシュデバイスが故障した場合に何が残るかです。このガイドはそれらの障害ドメインを分離し、書き込みパス全体がアプリケーションが期待する耐久性を保持する場合にのみ速度の利点を維持できるようにします。

ライトバックキャッシュは実際に何を確認しているのか？

書き込み確認は、ある層が上位層に対して行う約束です。ライトスルーモードでは、書き込みが必要なバックアップストレージに到達するまでキャッシュは完了を報告しません。ライトバックモードでは、キャッシュはまだ遅い階層に移動する必要があるダーティデータを保持しながら完了を報告することがあります。

この区別は、ライトスルーを「安全」、ライトバックを「リスクあり」と呼ぶよりも正確です。保護された不揮発性メディアに支えられたライトバックキャッシュは有効な耐久性の約束をすることができます。ライトスルースタックでも、下位のドライブやコントローラが揮発性メモリからのデータを確認し、永続化を目的としたフラッシュコマンドを無視する場合は安全でないことがあります。

現代のストレージスタックは、各ブロックの後に盲目的に待つのではなく、順序付けと耐久性コマンドを使用します。Linuxブロックレイヤーは強制キャッシュフラッシュとForce Unit Accessを、ファイルシステムがデバイスの揮発性キャッシュを制御するためのメカニズムとして文書化しています。したがって、ライトバックはすべての層がアプリケーションのフラッシュまたは同期書き込み要求を転送し尊重する場合にのみ許容されます。

どこで確認済みデータがまだ失われる可能性があるのか？

揮発性システムまたはコントローラメモリ

システムRAM、保護されていないRAIDコントローラーキャッシュ、または他の揮発性バッファは、電源が失われるとダーティデータを失います。クライアントに同期書き込みが完了したと既に通知されている場合、NASは再起動後にそれらのバイトを再作成できません。その結果、最近のトランザクションの欠落、VMやデータベースレコードの破損、またはアプリケーションレベルの不整合が生じる可能性があります。

ソフトウェアのクラッシュはAC停電と同一ではありません。UPSは電力障害時にハードウェアの電源を維持できますが、カーネルパニック、ウォッチドッグリセット、マザーボードの故障、または誤ったハードリセットによる通常のRAMの保持はできません。脆弱な期間は、ダーティデータが約束された耐久性を満たす次のストレージ層に到達するまで続きます。

電源喪失保護なしのSSDキャッシュ

NANDフラッシュは不揮発性ですが、SSDは一時的にユーザーデータやフラッシュ変換メタデータを揮発性のDRAMに保持することがあります。デバイスの電源が突然失われると、SSDが期待される保護を正しく実装していなければ、ホストがフラッシュ済みと信じていたデータが危険にさらされます。ハードウェアの電源喪失保護は、コントローラーが重要な内部作業を完了できるように予備エネルギーを提供します。KingstonのSSDの電源喪失保護に関する説明は、このデバイスレベルの境界を説明しています。

2台のキャッシュ付きSSDをミラーリングすることで1台のデバイス故障に対して保護されますが、ミラーはどちらのドライブ内にも電源喪失保護を作り出しません。逆に、1台のSSDのPLPはコントローラーやメディアの故障に対する冗長性を提供しません。高価値の書き込みキャッシュは、キャッシュソフトウェアの約束内容と所有者が失うことを許容する確認済みデータ量に応じて、両方が必要になる場合があります。

ドライブ内部書き込みキャッシュ

HDDとSSDは、パフォーマンス向上のために内部の揮発性書き込みキャッシュを有効にしていることが多いです。ドライブとコントローラーがフラッシュおよびFUAコマンドを正しく処理している場合、これは自動的に安全でないわけではありません。ブリッジ、コントローラー、ファームウェア設定、またはドライブがこれらのコマンドを尊重せずに完了を報告すると危険になります。

すべてのドライブキャッシュを無効にすることは、パフォーマンスに大きな影響を与える可能性があり、正しいストレージスタックがあれば不要な場合があるため、デフォルトの対応ではありません。トップレベルのNASキャッシュ設定がすべての下位レイヤーを制御していると仮定せず、コマンドパスと保護動作を確認してください。

なぜUPS、保護されたコントローラーキャッシュ、SSD PLPは異なる故障を解決するのか？

UPSは短時間の電力障害中にNAS全体に電力を供給し続け、バッテリーが切れる前にオペレーティングシステムにデータのフラッシュとシャットダウンを通知できます。Network UPS Toolsは、バッテリー残量が少ないときにオペレーティングシステムをクリーンにシャットダウンするシーケンスを説明しています。通信リンクと自動シャットダウンの設定は、バッテリー自体と同じくらい重要です。

UPSはすべての内部故障をカバーするわけではありません：内部電源障害、コントローラーリセット、カーネルクラッシュ、電源ケーブルの切断、またはキャッシュSSDの故障から揮発性キャッシュを救うことはできません。これらのギャップは、ダーティデータを保持するレイヤーでの保護を必要とします。バッテリーまたはフラッシュバックされたコントローラーキャッシュは、そのコントローラーによって確認された書き込みを保持し、SSDのPLPはドライブの進行中の状態と内部メタデータを保護するためにローカルエネルギーを供給します。

保護は安全に失敗する必要もあります。コントローラーはバッテリー、コンデンサー、またはキャッシュ保護モジュールが不健康な場合、ライトスルーにフォールバックすべきです。その状態を監視し、アラートをテストしてください。ハードウェアを所有していることは、アクティブで回復可能な保護経路を持っていることと同義ではありません。

ファイルシステムと同期書き込みはリスクをどのように変えるのか？

ファイルシステムのジャーナリングとコピーオンライト

ジャーナリングとコピーオンライトは、ファイルシステムが中断後に一貫した構造を回復するのに役立ちますが、永続的なストレージに到達しなかった確認済みのユーザーデータを回復することはできません。これらは、下位レイヤーが書き込み順序、バリア、フラッシュ、またはFUAを尊重することに依存しています。一貫したファイルシステムでも、ファイルやデータベーストランザクションの古いバージョンが含まれている可能性があります。

同期セマンティクスは、データベースや仮想マシンなどのアプリケーションで重要です。 fsync, O_SYNC、またはトランザクションがクラッシュ後も生き残る必要がある場合の同等のネットワークリクエスト。非同期アプリケーションは速度のために最近のデータ損失の定義されたウィンドウを受け入れることがあります。同期ワークロードを強制的に非同期動作させることは、単にキャッシュを調整するのではなく、アプリケーションの耐久性契約を変更することになります。

ZFS ZILとSLOGの境界

ZFSにはすでに同期操作用のZFSインテントログ（ZIL）があり、別のログデバイス、すなわちSLOGはそのログを別のデバイスに移動します。これは一般的な書き込みバックキャッシュではなく、通常の非同期書き込みを同じ方法で加速せず、データの主コピーを恒久的に保存しません。OpenZFSは、機械式プールでfsyncやO_SYNCを使用するワークロードに対してSLOGデバイスを検討することを推奨しています。

SLOGは依然として、ワークロードに必要なレイテンシ、耐久性、フラッシュ動作、および電源喪失保護を提供する必要があります。ミラーリングは、同期書き込みの確認済みの唯一の耐久記録を含む間のログデバイス障害から保護できます。データセットを同期セマンティクスの要求を無視するように設定するとベンチマークは高速になりますが、クラッシュ後に最近の確認済みトランザクションの損失を明示的に受け入れることになります。

どのワークロードが実際に書き込みバックキャッシュの恩恵を受けるのか？

書き込みバックは、入力されるワークロードがバースト的でレイテンシに敏感であり、遅いストレージが後で汚れたデータを排出できる場合に最も有用です。例としては、小さなランダム書き込み、VMストレージ、データベーストランザクション、ビルド成果物、アプリケーション状態、HDDプールに向けられた短時間のマルチクライアントバーストなどがあります。

書き込みバックは、バックエンドのアレイを恒久的に高速なストレージに変えることはできません。許可されたキャッシュ領域が汚れたデータで満たされると、持続的なスループットはHDDプールが書き込みを吸収できる速度に近づきます。リカバリ、スクラブ、読み取り、その他のI/Oは、その排出速度をさらに低下させる可能性があります。

大きな連続コピーは、特にネットワークがすでにアレイより遅い場合、期待したほどの効果が得られないことがあります。Linuxのbcacheドキュメントでは、大きな連続I/Oはキャッシュをバイパスすることがあると説明されています。これはSSDキャッシュが一般的にランダムI/Oに対してより価値があるためです。キャッシュ設計は実装に依存しますが、原則は同じで、すべての10GbEファイルコピーが書き込みバックを必要とするとは限らないため、ワークロードを測定することが重要です。

書き戻しを有効にする前にNASの書き込みパスをどのように監査できますか？

アプリケーション、クライアントOS、ネットワークプロトコル、NASページキャッシュ、ファイルシステム、ソフトウェアキャッシュ、RAIDまたはHBAキャッシュ、SSDまたはHDDファームウェア、物理メディアの全経路を描きます。完了を認識する層、最初にデータを不揮発性にする層、およびそれらの間の保護状態をマークします。

Linuxシステムで直接見えるATAまたはSCSIデバイスの場合、smartctl -g wcache /dev/sdXでサポートされている揮発性書き込みキャッシュ設定を照会できます。smartctl書き込みキャッシュ照会は、ドライブキャッシュがNASレベルのSSDキャッシュと別である理由も示します。RAIDコントローラの背後にあるデバイスはコントローラの管理ユーティリティが必要な場合があります。スタックを完全に理解していない限り、検査は照会のみとし、その後コントローラポリシー、キャッシュ保護の健康状態、SSDのPLP、キャッシュ冗長性、ファイルシステムの同期特性、UPSの稼働時間、通知配信、およびシャットダウン閾値を記録してください。

sudo smartctl -g wcache /dev/sdX
sudo smartctl -x /dev/sdX
sudo hdparm -W /dev/sdX

稼働中の本番プールの電源を切らずにシャットダウンパスをテストします。UPSソフトウェアのサポートされているテストまたはシミュレートされたイベントを使用し、NASがそれを受信することを確認し、サービスが停止しファイルシステムが設定されたバッテリー期限前にアンマウントされることを確認します。RAMやキャッシュより大きい代表的なデータでベンチマークを行い、一時的なメモリバーストが持続可能なストレージ性能と誤認されないようにします。

書き戻しキャッシュをいつ有効化、制限、または無効化すべきか？

測定で意味のあるワークロードの利点が示され、キャッシュが許容する障害を通じて必要なフラッシュを正確に満たせる場合に書き戻しを有効にします。重要な同期データの場合、通常は保護されたキャッシュメディア、検証済みのフラッシュ動作、ヘルスモニタリング、十分な耐久性、テスト済みのリカバリパス、およびもう一つの防御層として通信可能なUPSが必要です。

VM、データベース、またはアプリケーション状態だけが低遅延の恩恵を受ける場合に限り、ライトバックを選択したデータセットに制限してください。リスクドメインが小さいほど検証と回復が容易です。大容量メディア、コールドバックアップ、長い連続転送は恩恵がない場合はより単純なパスに置き、利得が測定されていない場合、キャッシュに保護されていない障害点がある場合、UPSシャットダウンが未検証の場合、コントローラー保護が不健全な場合、または認識された書き込みの損失が許容できない場合はライトスルーまたは読み取り専用キャッシュを使用してください。

キャッシュの冗長性をバックアップとみなさないでください。スナップショット、レプリケーション、オフラインまたはオフサイトコピーは、削除、マルウェア、オペレーターエラー、プールの損失など異なる障害モードを保護します。キャッシュ保護は最近の書き込みの約束が破られる可能性を減らしますが、回復可能なデータコピーの代わりにはなりません。

よくある質問

UPSはライトバックキャッシュを完全に安全にしますか？

いいえ。通信可能なUPSは外部電源喪失のリスクを減らし、NASにフラッシュとシャットダウンの時間を与えますが、PSUの故障、カーネルパニック、コントローラーリセット、キャッシュデバイスの故障、内部ケーブルの切断、または破損したシャットダウン設定はカバーしません。デバイスおよびコントローラーレベルの保護を補完するべきです。

電源喪失保護なしのミラーSSDライトキャッシュは十分ですか？

必ずしもそうではありません。ミラーリングは1つのSSDの故障を防ぎますが、両方のドライブが同じ電源イベント中に揮発性の内部状態を失う可能性があります。キャッシュ層がフラッシュの耐久性に依存する場合は、各SSDがその要件を満たしているかを検証し、NANDだけで十分と仮定せずモデル固有のPLP証拠を使用してください。

読み取り専用キャッシュはライトバックキャッシュより安全ですか？

はい、ダーティキャッシュの損失に関してはそうです。読み取り専用キャッシュはバックプールに既に存在する置き換え可能なデータのコピーを保存するため、それを失っても認識された書き込みが破棄されることはありません。複雑さが増したり失敗する可能性はありますが、キャッシュが唯一の現在のコピーを保持する期間は生じません。

最終的な結論

ライトバックキャッシュには一律のリスクレベルはありません。完了がどこで認識されるか、そのキャッシュが本当に不揮発性かどうか、フラッシュがすべての下位レイヤーに到達するかどうか、保護システムがどの障害に耐えられるかによって、ホームNASのデータリスクは変わります。

書き込みパスをマッピングし、UPSのシャットダウン、コントローラー保護、SSDのPLP、キャッシュの冗長性、ドライブ設定、ファイルシステムのセマンティクスを検証し、その後実際のワークロードでベンチマークを行います。測定された利得が残る障害ウィンドウを正当化する場合にのみライトバックを有効にし、それ以外の場合はライトスルーまたは読み取り専用キャッシュを使用し、より単純な耐久性モデルを維持します。