背景
DRBD + Proxmox VEに基づいた信頼できる安価なクラスターを作成するための美しいソリューションがあります。 Proxmox Wikiページは2009年9月11日に表示され、CEOのMartin Maurerによって作成されました。
それ以来、このソリューションは非常に人気があり、このソリューションに隠れた落とし穴があると疑う人はいませんでした。 ドキュメントにはこれについて書かれておらず、この問題の結果（たとえば、あるホストから別のホストへのオンライン移行中のマシンクラッシュ）に直面した人は、すべてを「ケース」に起因しました。 誰かがハードウェアに罪を犯し、誰かがProxmoxに、そして誰かが仮想マシン内のドライバーに罪を犯しました。 もちろん、DRBDに問題を報告してもらいたいのですが、どういうわけかあなたは無意識のうちにそれを報告していると信じています。 / proc / drbdを確認すると、「cs：Connected ro：Primary / Primary ds：UpToDate / UpToDate」という行が表示され、DRBDがそれとは無関係であると信じ続けます。
一度、DRBDのドキュメントを注意深く読んで、DRBDの整合性を定期的にチェックすること、つまり 2つのノードが互いに同一であること。 まあ、なぜそうなのか、私は、検証は不要ではないと思った。 そして、1年にわたる物語が始まりました。
毎週新しい非同期ブロックがDRBDに登場したことが判明しました。 つまり 2つのサーバー上のデータは異なっていました。 しかし、なぜ？！
ハードウェアの交換、DRBDバージョンの更新、オフロードとボンディングの無効化はプラスの結果にはならず、新しいブロックがすべて現れて現れました。 どのブロックが非同期であるかを分析した結果、次の結果が得られました。
-多くの場合、Linux仮想マシンのパーティションをスワップします
-まれに-仮想マシンにNTFSパーティションがあるWindows
-決して-Linux仮想マシン上のext4
それは「おもしろい」ですが、「なぜそれができるのか」という質問には答えませんでした。 私はDRBDユーザーのメーリングリスト（http://www.gossamer-threads.com/lists/drbd/users/25227）でのすべての研究について話しましたが、ある日、私は長い間待っていた答えを受け取りました。 DRBDの主要な開発者の1人であるLars Ellenberg氏は、正確に何が起こっているのか、どのようにチェックするのかについて語りました。
DRBDへの書き込み方法
一般的なケース：
1）DRBDは、バッファーからデータを書き込むためのOSからの要求を受信します。
2）DRBDはローカルブロックデバイスにデータを書き込みます。
3）DRBDは、ネットワークを介して2番目のノードにデータを送信します。
4）DRBDは、ローカルブロックデバイスから記録の終了の確認を受信します。
5）DRBDは、2番目のノードからレコードの終了の確認を受け取ります。
6）DRBDは、記録の終了のOS確認を送信します。
ここで、バッファ内のデータが予期せず変更され、次のようになることを想像してください。
1）DRBDは、バッファーからデータを書き込むためのOSからの要求を受信します。
2）DRBDはローカルブロックデバイスにデータを書き込みます。
2.5）バッファデータが変更されました。
3）DRBDは、ネットワークを介して2番目のノードにデータを送信します。
4）DRBDは、ローカルブロックデバイスから記録の終了の確認を受信します。
5）DRBDは、2番目のノードからレコードの終了の確認を受け取ります。
6）DRBDは、記録の終了のOS確認を送信します。
そして、すぐに非同期になります。
これはどうやって起こるのですか？ とても簡単です。 バッファーは、書き込みキャッシュのためにアプリケーションで使用できます（アプリケーションは、仮想マシンプロセスです）。 この場合、アプリケーションは、このデータを物理デバイスまたはコントローラーに書き込む確認を待たずにバッファー内のデータを更新できます。DRBDの場合、これは受け入れられません。
このすべてで最も不快なのは、 データを失うことができるように、電源を切る必要さえないということです。 書き込みキャッシュをオンにするだけです。
確認方法 DRBD設定でdata-integrity-algを有効にして待機する必要があります。 「書き込み中に上位層によって変更されたバッファ」のようなものを取得した場合、これがそれです。 DRBDがデュアルプライマリモードで動作し、「data-integrity-alg」をオンにすると、すぐにスプリットブレインが発生することに注意してください（これはドキュメントには書かれていません）。
QEMU / KVM書き込みキャッシュ
デフォルトでは、Proxmox VEの仮想マシンは仮想ディスクにcache = noneを使用します。 「none」は「何もキャッシュしていません」と言っているという事実にもかかわらず、実際はそうではありません。 この場合、なしは「ホストキャッシュ」を使用しないことを意味しますが、ブロックデバイスへの書き込みキャッシュはまだ使用中です。 そして、ここからDRBDの非同期ブロックに関する問題が発生します。
DRBDで使用する場合、信頼できると見なされるモードは、直接同期とライトスルーの2つだけです。 1つ目は、キャッシュをまったく使用しません。 常にブロックデバイス（RAIDコントローラーの場合もあります）から直接読み取り、ブロックデバイス（RAIDコントローラーの場合もあります）に書き込み、常に記録の確認を待ちます。 2番目のモードは、読み取りに「ホストキャッシュ」を使用します。
したがって、書き込みキャッシュとBBUで物理RAIDを使用しないと、仮想化システムが壊滅的に遅くなる可能性があります。 また、BBUでRAIDを使用する場合、仮想マシンはデータをコントローラーキャッシュに配置した直後にレコードの確認を受け取ります。
ext4で非同期が発生しない理由
cache = directsyncおよびcache = writethroughモードを使用するのが最も信頼性が高いのは、この場合、仮想マシン内で何が起こっているかを心配する必要がないためです。 しかし、これが唯一の方法ではありません。 これは、十分なRAIDパフォーマンスがない場合、またはRAIDがまったくない場合に考慮する必要があります。
仮想マシンのプロセスレベルだけでなく、VM内でもデータが既に記録されていることを確認できます。 ここでは、バリアの概念を理解します。バリアの概念では、ファイルシステム自体がキャッシュから物理デバイスにデータをフラッシュする必要があることを認識しており、この操作が完了するのを待ちます。 そして、man mountは「ext4ファイルシステムはデフォルトで書き込みバリアを有効にします」と言っています。 そのため、バリアを使用しているファイルシステムが配置されているエリアでは、同期がとれません。
便利なリンク：
-ProxmoxおよびDRBD： pve.proxmox.com/wiki/DRBD
- 非同期 ： www.gossamer-threads.com/lists/drbd/users/25227
- 非同期の詳細： forum.proxmox.com/threads/18259-KVM-on-top-of-DRBD-and-out-of-sync-long-term-investigation-results
-kvm / qemuのキャッシュパラメーターの説明： www.suse.com/documentation/sles11/book_kvm/data/sect1_1_chapter_book_kvm.html
-キャッシュの詳細： www.ilsistemista.net/index.php/virtualization/23-kvm-storage-performance-and-cache-settings-on-red-hat-enterprise-linux-62.html?start=2