BBWC：理論上は良い考えですが、データを保存したことはありますか？

私はBBWC（バッテリーバックアップ式書き込みキャッシュ）の目的に精通しています。以前は、UPSが良好であってもサーバーで使用していました。保護を提供しない明らかな障害があります。それが実際に実際の利益をもたらすかどうかを理解したいのですが。

（注：BBWCを使用しており、クラッシュ/障害が発生した人々からの応答、およびBBWCが回復に役立ったかどうかを特に探しています）

更新

ここでのフィードバックの後、私はBBWCが価値を付加するかどうかについてますます懐疑的になりました。

データの完全性について自信を持たせるために、ファイルシステムは、データが不揮発性ストレージ（必ずしもディスクではない-私が戻ってくるポイント）にコミットされたときを知っている必要があります。データがディスクにコミットされた時期について多くのディスクが存在することに注意してください（http://brad.livejournal.com/2116715.html）。ディスク上のキャッシュを無効にするとディスクがより正直になると想定するのは妥当と思われますが、これが当てはまるという保証もありません。

BBWCのバッファは通常非常に大きいため、バリアはディスクにより多くのデータをコミットする必要があるため、書き込みの遅延が発生します。一般的なアドバイスは、不揮発性ライトバックキャッシュを使用する場合はバリアを無効にすることです（そして、ディスクキャッシュ）。ただし、これは書き込み操作の整合性を損なうように見えます-不揮発性ストレージにより多くのデータが保持されているからといって、それがより一貫性があるということにはなりません。実際、論理的なトランザクション間の境界がなければ、一貫性を確保する機会は他の方法よりも少ないようです。

データが（ディスクにコミットされるのではなく）不揮発性ストレージに入る時点でBBWCがバリアを認識した場合、パフォーマンスを低下させることなくデータ整合性要件を満たしているように見えます-バリアを有効にする必要があることを意味します。ただし、これらのデバイスは通常、物理デバイスへのデータのフラッシュと一貫した動作を示し（バリアを使用すると大幅に遅くなります）、バリアを無効にするための広範なアドバイスを示すため、このように動作することはできません。何故なの？

OSのI / Oが一連のストリームとしてモデル化されている場合、書き込みキャッシュがOSによって管理されている場合、書き込みバリアのブロッキング効果を最小限に抑えるスコープがあります-このレベルでは論理トランザクション（単一のストリーム）コミットする必要があります。一方、トランザクションを構成するデータのビットがわからないBBWCでは、キャッシュ全体をディスクにコミットする必要があります。カーネル/ファイルシステムが実際にこれを実際に実装するかどうかは、現時点で投資しようと思っているよりもはるかに多くの努力を必要とします。

コミットされたことと突然の電源喪失をfibsに伝えるディスクの組み合わせは、間違いなく破損につながります。また、ジャーナリングまたはログ構造化ファイルシステムでは、停止後に完全なfsckを実行しないため、破損は言うまでもありませんそれを修復しようとしました。

故障モードに関しては、私の経験では、主電源の喪失（UPSと管理されたシャットダウンで簡単に軽減できる）が原因で、ほとんどの突然の停電が発生します。間違ったケーブルをラックから引き出すと、データセンターの品質が低下します（ラベル付けとケーブル管理）。UPSによって防止されない突然の電力損失イベントにはいくつかのタイプがあります-PSUまたはVRMの障害は、障害のあるBBWCが障害の場合にデータの整合性を提供しますが、そのようなイベントはどれくらい一般的ですか？ここでの回答の不足から判断して非常にまれです。

確かに、スタック内のフォールトトレランスを高くすると、BBWCよりもかなり高価になりますが、サーバーをクラスターとして実装すると、パフォーマンスと可用性に関して他にも多くの利点があります。

突然の電力損失の影響を軽減する別の方法は、SANを実装することです。AoEはこれを実用的な提案にします（iSCSIにはあまり意味がありません）が、やはりコストが高くなります。

はい。バッテリバックアップキャッシュ（BBWC）と、その後のフラッシュバックアップ書き込みキャッシュ（FBWC）により、クラッシュや突然の電力損失に続いて、飛行中のデータを保護しました。

HP ProLiantサーバーでは、典型的なメッセージは次のとおりです。

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

つまり、「ねえ、再起動/電力損失を生き残ったデータが書き込みキャッシュにあります!!今すぐディスクに書き戻します!!」

興味深いケースは、竜巻の間に電源を失ったシステムの事後分析でした。配列の順序は次のとおりです。

POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

1793 POSTエラーは一意です。-システムの使用中に、データがアレイアクセラレータメモリにある間、電源が遮断されました。ただし、これは竜巻であったため、4日以内に電力が回復しなかったため、アレイバッテリーが消耗し、内部のデータが失われました。サーバーには2つのRAIDコントローラーがありました。もう1つのコントローラーにはFBWCユニットがあり、これはバッテリーよりはるかに長持ちします。そのドライブは適切に回復しました。空のバッテリーに支えられたアレイで、データ破損が発生しました。

施設での十分なバッテリー稼働時間にもかかわらず、電力と危険な条件のない4日間は、誰もサーバーを安全にシャットダウンすることを不可能にしました。

はい、その場合がありました。

データセンター内の「UPSなし」サーバー（データセンターにUPSがある）。PDUエラー-システムが激しくクラッシュしました。データ損失なし。

そしてそれは基本的にそれです。BBWCの良いところは、マシンにあることです。UPSを持っている-私を信じて、時には誰かが愚かなことをする（間違ったケーブルを引っ張るなど）。UPSは外付けです。ああ、そのケーブル;）

HW RAIDコントローラーのバッテリーバックアップキャッシュが完全に失敗した2つのケースがありました（2つの別々の会社で）。

BBCは、バッテリーが機能するという驚くべき考えに依存しています。キャッチは、ある時点でコントローラーのバッテリーが故障することであり、壊滅的なことは、多くのHW RAIDコントローラーで静かに故障することです。キャッシュは電力損失から保護されていると考えましたが、そうではありませんでした。

停電時には、RAIDアレイのデータ損失が非常に大きいため、すべてのディスクの内容が回復不能になりました。すべてが失われました。ケースの1つには、完全にテスト専用のマシンが関係していましたが、それでもまだです。

その後、「二度と」と言って、Linuxでソフトウェアベースのディスクミラーリング（mdadm）に切り替え、電力損失（ext4）に対してまともな復元力を持ち、後戻りすることはありませんでした。確かに、非常に高いIO使用率を持たないサーバーで使用しました。

これには、質問に対する2番目の答えが必要なようです...

スタンドアロンのVMware ESXiホストでRAID 5アレイのドライブが失われました。劣化したアレイは、VMおよびアプリケーションレベルのパフォーマンスに影響を与えました。

Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

この会社のIT担当者は、ドライブが故障したことを認識せず、サーバーをハードリセットしました（すべてを改善するためですか？）。

忙しい仮想マシンを実行している侵害されたアレイに対してこれを行うことの興味深い効果は次のとおりです。

キャッシュステータスの詳細：現在のアレイコントローラーには、最後にリセットまたは電源投入されたときに、バッテリー/キャパシターバックアップ書き込みキャッシュに有効なデータが保存されていました。これは、システムが正常にシャットダウンされなかったことを示します。アレイコントローラーは、このデータをドライブに自動的に書き込んだか、書き込みを試みました。このメッセージは、アレイコントローラーの次のリセットまたは電源の再投入まで表示され続けます。

そのため、システムが突然停止した場合でも、飛行中のデータはBBWCによって保護されていました。仮想マシンはすべて正常に回復し、システムは良好な状態になりました。

「データの保存」に加えて、他の目的にも役立ちます。また、ディスクキャッシュキューを低く保つことでIOサブシステムのパフォーマンスを向上させるために、書き込みを（キャッシュに）バッファリングするのにも優れています。これは、Citrix XenAppやWindows Terminal Servicesなど、インタラクティブなパフォーマンスが最重要なサーバーにとって特に重要です。

これは、Webサーバーまたはファイルサーバーにとってはそれほど重要ではありません。あなたは少し遅れに気付かないか、慣れさえするかもしれません。ただし、Officeアプリケーションのアイコンをクリックすると、応答性が期待されます。あなたのCEOもそうです。