高可用性仮想マシン
Hyper-VまたはVMWareのいずれかを介した、高可用性仮想化について多くのことを読んでいます。そのコンテキストでは、本質的に高可用性とは、VMが物理サーバー（ノード）のクラスターによってホストされていることを意味します。したがって、物理サーバーの1つがダウンした場合、VMは、他の物理サーバーからもサービスを提供できます。これまでのところ、物理クラスターとVM自体は高可用性です。
ただし、提供されているサービス、たとえばSQLサーバー、MSDTC、またはその他のサービスが実際にはVMイメージと仮想化されたオペレーティングシステムによって提供されている場合、まだ存在していると思います。考慮されていない仮想レイヤーでの障害のポイント。仮想マシン自体の中で、物理クラスターが説明できない何かが発生する可能性があります。正しいですか？その場合、物理フェイルオーバークラスター（Hyper-V）またはVMWareホストは次のことができます。問題は物理クラスター内のサーバーの1つにあるのではないため、フェイルオーバーしないでください。物理ノードのフェイルオーバーは効果がありません。
これには、物理クラスターの上に仮想フェールオーバークラスターを構築する必要がありますか、それとも必要ありませんか？
または、物理的なクラスタリングをスキップして、仮想レイヤーでクラスター化することもできます（子ベースのフェールオーバークラスタリング）。これは、物理的な障害に耐えられるはずだからです。
親ベース（左）、子ベース（右）、および組み合わせ（中央）を示す下の画像を参照してください。あなたが行く必要がある限り親ベースですか、それとも子供ベースがより適切ですか？
答えはそれが依存するということです。
クラスタリングソリューションは通常、アプリケーション層以上のことを行います。従来、クラスター依存関係グラフには、次のようなものが含まれます。
- ネットワーク/ IPの可用性チェック
- ストレージ/共有ボリュームの可用性。
VM内でこれらのチェックの一部を実行することは非常に困難です。たとえば、Windows 2003クラスターでは、リソースの所有者であることを確認するために、SCSIロックを使用するクォーラムドライブが必要です。 。障害が発生すると、そのロックを取得するために「ポイズンパケット」も送信します。これらの機能はすべて、LUNへのRDMなしで実装することはほぼ不可能です。
これらの「ハードウェア検出」コンポーネントはすべて、VM内で大きなオーバーヘッドが発生します（VMのパフォーマンスはユーザーアプリにとって常に優れていますが、カーネルベースでは常にさまざまな程度のオーバーヘッドが発生します）。
したがって、Microsoft Windows 2003クラスターの場合（仮想化する必要がありましたが、「子」アプローチを使用します）。
努力するのに理想的な場所は、
- ハードウェア障害検出用のVMwareHA。
- vSphereアプリケーションの監視
に続く、
- VMware HA
- アプリケーションのみモニター（ハードウェアの依存関係なし）
- DRS、HAが同じホスト上のノードを再起動しないように、ペアのVMに対してアンチアフィニティがオンになっていることを確認してください。
最後に
- 子のクラスタリング
物理クラスターは、仮想ハードウェアの高可用性を実現します。つまり、物理サーバーの障害が特定の仮想マシンに影響を与えることはありません。ただし、仮想マシン自体に障害が発生する可能性があるため（OSのクラッシュ、誰かが仮想サーバーをシャットダウンするなど）、仮想マシン上で実行されているサービスは、ある時点で障害が発生する可能性があります（ただし、発生する可能性は低くなります）。スタンドアロンの物理ハードウェアで実行されている同じサービス用である）。このリスクを軽減するには、クラスター化されたサービスを作成して、仮想サーバーに障害が発生した場合でもサービスが影響を受けないようにします。もちろん、クラスター化されたサービスを物理サーバー上に直接構築した場合は、ほぼ同じ結果を達成できます。
クラスター化されたサービスを物理サーバーで実行するか、クラスター化された仮想化プラットフォーム上で実行するかは、要件によって異なります。他に仮想化プラットフォームが必要ない場合、またはクラスター化されたサービスに多くのシステムリソースが必要な場合は、物理ハードウェア上にクラスターを構築することをお勧めします。ただし、物理ハードウェアに余裕のあるリソースがある場合、または仮想化クラスターが既にある場合は、仮想マシンでクラスター化サービスを実行します。これにより、（仮想）ハードウェアの管理がはるかに簡単になります。
ただし、途中でリアリティピルを服用することを忘れないでください。
アプリケーションに必要な稼働時間を理解する必要があります。さらに重要なのは、アプリケーションが失敗したときにアプリケーションを使用できなくなる最大時間です。そしてそれはそうなるでしょう。
この2番目のポイントは重要です。 「ファイブナイン」アプリケーションが、高可用性を維持するために使用されているテクノロジーの複雑さのために、ほぼ1日オフラインであった大規模なシステムインテグレーターによって管理されているのを見てきました。日々の運用の可用性については、テクノロジーがチェックボックスをオンにしましたが、構成に問題が発生した場合、前述の会社の人々は適切に立ち往生していました。
誤解しないでください、クラスタリング、SANスナップショット、VMスナップショット、オフサイトレプリケーション、HAロックステップ仮想化など） 、ただし、見栄えが良く光沢のあるものではなく、必要なものを選択するようにしてください。
今から石鹸箱から降ります;-)
これには、物理クラスターの上に仮想フェールオーバークラスターを構築する必要がありますか、それとも必要ありませんか？
はい、そうです。
まず、高可用性システム（SQL、OSなど）を構築する必要があります。つまり、複数の物理コンピューターまたは仮想コンピューターが必要であり、高可用性をサポートできるソフトウェアを使用する必要があります。
これが完了すると、ハードウェア障害から「のみ」保護する高可用性仮想化システムを使用できます。
高可用性の第2レベルには、2台（またはそれ以上）の物理コンピューターが必要です。
つまり、最初のレベルの高可用性が2台のコンピューターで行われているとしましょう。2番目のレベルについては、何も改善されないため、気にする必要はありません。
可用性に関するアイデアの本質を理解していると思います。 Hyper-vとVMwareHAの両方の機能は、ゲストにHAを提供せず、仮想化サービスのHAのみを提供します。ゲストサービスの可用性要件に基づいて、ゲストレベルでのHAも必要です（関連するテクノロジーによっては、クラスタリングを意味する場合があります）。必要な稼働時間を提供する方法の詳細について、各サービスを評価する必要があります。たとえば、SQLサーバーは、トランザクションミラーリングまたはサーバークラスタリングのいずれかを使用できます。多くの場合、仮想サービスでのクラスタリングにおける追加のオーバーヘッドと課題は、提供されるメリットを上回り、サービスが代わりに専用ハードウェアで提供されることを意味する場合があります。 （SQLサーバーを少し選ぶ）SQLサーバーは通常、ネットワーク、IO、CPU、メモリの使用率が高く、冗長性が必要なため、物理的な状態を維持する可能性があります。