DRBDの実験と仮想化
これは私の心の奥底をくすぐっていたそれらの考えの1つでした。
私は、ストレージ用のSANまたはNAS、必要に応じて」ではなく、コンピューターのみで構成される高可用性クラスターのホームテストベッドに取り組んでいます。ハードウェアに障害が発生し、それを実行するための古いマシンがいくつかあった場合でも使用可能なサーバーを1つか2つ使用できますか？」.
Linuxディストリビューションをインストールし、Pacemaker/STONITHを使用してプライマリ/プライマリモードでDRBDをインストールし、次にXenをインストールして、実際に複製するシステムを提供するサーバーを仮想化することで、それを実行しようと考えていました。
VMWare ESXiで動作する最近のセットアップでは、代わりにESXiを使用して2台のマシンにLinux VMをインストールし、DRBDとPacemaker/STONITHを使用して2台のVMWareESXi上の仮想マシン間でサーバーサービスを複製することに何らかの利点があるのではないかと考えました。システム（および他のVMを起動できるため、Xenを方程式から削除します）。
当時、私はVM側でパフォーマンス、ディスク使用量などに関する統計を提供する管理インターフェイスの多かれ少なかれ簡単な方法が好きだったと思いますが、の管理に関しては何も見ていませんコマンドライン以外のXenまたはDRBD（ただし、VMWareサーバーを監視するためにWindowsシステムを使用する必要はありません）。
専用ハードウェアを使用してLinux/DRBDレプリケーションをより簡単に実行できる可能性があるため、2番目の考えから、複雑さが増し、ネットワークが困難になる可能性があることがわかりました（各マシンに1つのNICスイッチの場合、1つNICディスクI/O用に相互にクロスオーバーする）そして「無料」でそのようなクラスターを作成するために何ができるかを知りたいと思いました... ESXi以外のソリューションは間違いなく安くはありません。
ベアメタルハードウェアの代わりにVMでDRBDを実行しているマシンを仮想化して、この構成のようなものを試した人はいますか？無料のvSphereクライアント（または「無料」の仮想化を選択）によるパフォーマンス/管理の監視だけでなく、これに構成上の利点はありますか？
少なくともXenの場合、私の経験では、Dom0にブロックデバイスを処理させる方がよいということです。私はDRDBを扱っていませんが、iSCSIでは、Dom0をiSCSIイニシエーターにしてから、DomUに結果のブロックデバイスを使用させる方がよいでしょう。
DRBDは、ボリューム上で実行されているファイルシステムを気にしないので、これはおそらくDomOで行うのが最適だと思います。これにより、DRBDバックアップウィンドウDomUを使用することもできます。
また、VMでのハートビートの実行に関するいくつかの質問に対応しているので、 この質問 を確認することもできます。
私はあなたが説明する多くの方法でこれを設定することに取り組んできました、そしてそれはうまくいきます！（XenServer）
古いが機能のあるサーバーをプライマリホストとしてセットアップしました。これはコンソールのみを実行しますVM DRBDの場合。これVMその後、「SharedDRBD」SRを提供します。 NFS経由のXenホスト。サービスを提供する残りの動作中のVMはSharedDRBDSRで実行されます。VMのDRBD開発はMDADMRAID1上の独自のVDI上にあります。このSharedDRBDSRは、ローカルでさまざまなサービスの残りのVMをホストします。バルクファイルストレージ用のより大きなRAID10アレイ。
すべてのMDADM作業はホストによって実行されますが、DRBDの片側はVM内にあります。
VMで実行されたDRBDは、ファイルバックアップサーバーで実行されているDRBDサービスと同期されます。ファイルバックアップサーバーは意図的に仮想化されていないため、XenServerが最大であるため、すべてのファイルにベアメタルアクセスできます。私たちが一般的に扱っている癖。
仮想化されているが、ホストに必要なものを除いてローカルストレージを持たないセカンダリサーバーがあります。このサーバーは、フェイルオーバーを簡素化するためにプライマリサーバーを備えたXenプールの一部です。フェイルオーバーは現在手動ですが、高速で簡単です。
まず、セカンダリXenServerホストの電源がオンになっている間、SharedDRBDSR上のすべてのVMがシャットダウンされます。ファイルバックアップサーバー上のDRBDがプライマリになり、必要に応じてマウントされます。次に、SharedDRBD SRがファイルバックアップサーバーをポイントし、VMがセカンダリサーバーで起動されます。 XenCenterは、同じデータを持つ同じSRを確認するため、新しい場所からVMにサービスを提供していることすら認識しません。 VMが再起動され、動作が再開されます。
構成、アレイ、ネットワークトポロジなどに関しては、さらに多くのことがあります。しかし、要点はDRBDはVM独自のホストに戻るで提供されます。
全体として、SMB /家庭での使用には十分なHAです。プライマリサーバーの壊滅的な障害時のダウンタイムは、完全にオンラインに戻り、データが失われることなく、10〜20分以内です。DRBDとはVMは最新です！さらに、かなり堅牢なプライマリサーバーの外部には、全体的な冗長性が大量にあります。プライマリサーバーのほとんどは、それ自体が冗長であるため、かなり考えられるほぼすべてのハードウェアに対して、3倍以上の冗長性が得られます（PS、RAM、CPU、HDD、コントローラー、NICなど）2倍の冗長性しかないマザーボード（プライマリ/セカンダリXenホスト）。
はい、XenCenterは悲しいことにWindowsにインストールされ、残りはすべてLinuxです。
わかっています、このQは8歳です。