DRとしてのDRBD：2つのESXIホストのデータストアの同期、vmdkの一貫性？

Question

選択したゲストのディザスタリカバリのために2つのESXiホストのデータストアの一部を同期するためにDRBD（プロトコルC）を使用した経験のある人はいますか？

ホストのハードウェア障害からできるだけ短時間で回復できるはずのゲストが2〜3人いますが、それでも手動で介入し、データをあまり失うことはありません。

私はこのようなものを作りたいです：

1 DRBD VM 2つのesxiホストのそれぞれでローカルSASストレージ（プライマリ/セカンダリ、アクティブ/パッシブ）を同期します。

このミラーリングされたストレージは、ISCSIまたはNFSを介して一度に1つのesxiホストにのみ接続し、それらのゲストがvmdkを2番目の「パッシブ」esxiホストに同期させるために使用する必要があります。ハードウェア障害が発生した場合、2番目のESXiホストはDRBDストレージを接続して、それらのVMの電源を入れる必要があります（もちろん手動で行います）。

ネット上でこれを行うことに関するいくつかの情報を見つけましたが、情報を見つけられなかったのは、vmdkの一貫性です。

もちろん、これはバックアップの代わりになるものではありませんが、ハイパーバイザーのバックアップツールは通常、スナップショットまたはバックアップを作成する前に、ゲストのファイルシステムとデータベースが静止していることを確認します。

ただし、この継続的な同期では、これは不可能です。そういうわけで、これはやる価値さえあるのだろうかと思います。

ハードウェア障害が悪い時期に発生したためにvmdk自体が損傷した場合はどうなりますか。 DRBDが完全ではない書き込みを破棄することは知っていますが、一貫性のある（もちろん、この方法では保証できないゲストファイルシステムの一貫性は別として、esxiの観点から「機能する」ことを意味します）vmdkを作成するには十分ですか？

クラッシュが発生した場合、2番目のESXiで起動されたゲストが、VMが正常にシャットダウンされていないかのように動作することを願っています（これには通常、他の場所で発生する可能性のあるすべての欠点があります）シナリオ）、しかしそれは本当にそうなのだろうか？vmdk全体が損傷することはなかったのだろうか？

読んでいただき、ありがとうございました。

マックス

Halfgaar · Answer

私はあなたが説明するようにscenerioで広範囲のテストをしました。 DRBDを使用してフェイルオーバー機能を備えたストレージサーバーを用意し、iSCSIを使用してそのストレージをXenを実行しているDebianマシンに接続してみました。問題が多すぎたので、すぐに諦めました。しかし、それらの一部は私かもしれません。それらの1つは、 iSCSIブロックデバイスが作成されなかったでした。

次に、2台のDebian Xenマシンを作成し、VMが存在するLVMブロックデバイスをDRBDで複製することを試みました。私はファイルシステムバリアエラーを克服する必要がありました。

その後、パフォーマンスが悪くなり、al-extentsオプションまで追跡しました。私が使用したDRBDのバージョン8.3は、デフォルト値が低すぎました。再同期時間が少し長くなることはあまり気にしないので、3833に上げました。

私はまた、ノードへの殺害力を使ってたくさんの実験をしました。 DRBDはそれで非常に優雅でした。 VMは期待どおりに応答しました。ジャーナルを回復していると言っただけで、他のノードでオンラインにすることは問題ありませんでした。ノードを再起動すると、デバイスが明らかに再同期されました。もちろん、実際のノード障害は、半分機能しているディスクやネットワークトラフィックなどで見苦しいことが多く、予測が困難です。手動でのみスレーブをプロモートするのが賢明です。

私は約2年間セットアップを実行しています。 Nodeはまだ失敗していません:)、DRBDもありません。

私のテストでは、フェイルオーバーを備えた中央ストレージサーバーを使用せずに、DRBDプライマリとセカンダリの両方でXenを実行する方がはるかに便利であることがわかりました。 iSCSIセットアップは再試行したいのですが、すぐには実行されません。

また、私は画像ファイルを扱いませんが、代わりにLVMブロックデバイスを扱います。これは私にとってより堅牢であることが証明されました。たとえば、LVMでのスナップノットが可能です。

注意すべき面白い点の1つは、DRBDには、プライマリノードでディスクレスで実行できるモードがあります。プライマリXenノードでディスク障害が発生し、気付かなかったことがあります（カーネルMDはドライブをキックしませんでしたが、ATAエラーが常に発生していました）。私が知らないうちに何週間も、VMは、他のサーバーをストレージとして使用して、ディスクレスモードで正常に実行されました:)