2つのホスト(vsphereAとvsphereB)にまたがるHAクラスターでvSphere5を実行しています。アドミッションコントロールを無効にして、ホストモニタリングとデータストアハートビートモニタリング用にHAクラスターを構成しました(データストアハートビートモニタリングにより、管理ネットワークの分離による不注意な不要なHAフェイルオーバーが防止されることを理解しています)。各ホストには、専用のiSCSIネットワークおよびiSCSIターゲット(MPIOなし)への単一の接続があります。すべてのVMのすべてのvmdkがiSCSIデータストアに存在します。 HAのテストとして、vsphereBでiSCSI接続を切断しましたが、vsphereBで実行中のVMがvsphereBで引き続き実行されていることに驚きました。電源がオフになっているVMはアクセス不能と表示されていました(実行されておらず、vsphereBからiSCSIターゲットへの接続が切断されていたために予想されました)実行中のVMは引き続き実行され、vsphereBによって「所有」され続けました。これらのVMでHAフェイルオーバーが発生することを期待し、HAフェイルオーバー(発生しなかった)後にvsphereAによって「所有」されていることを期待していました。これらのVMでHAフェイルオーバーが発生しなかった理由を理解するのに途方に暮れています。どのような場合にHAフェイルオーバーが発生するのか誤解していますか?
異なることを行う異なる機能であるvMotionとHAを混同しているようです。
vMotionは、ダウンタイムを発生させず、サービスの中断を最小限(ミリ秒)にすることなく、仮想マシンを1つの物理ホストから別の物理ホストに移行できるようにする機能です。これは事前にメンテナンスで行われ、VMと、送信元ホストと宛先ホストの両方がすでに正常な状態になっている必要があります。HAは、失敗した仮想を再起動する機能です。マシン(またはホスト分離が構成されている場合はアクセスできない仮想マシン)であり、仮想マシン全体の電源がオフになって再起動されるため、VMのダウンタイムが発生します。
重要なポイント:vMotionはHAフェイルオーバーではありません。 HAフェイルオーバーはHAフェイルオーバーです。
vMotionは、次のことによってトリガーされます。
HAフェイルオーバーは、次のことによってトリガーされます。
結論:vMotionはパフォーマンスイベントが原因で発生し、HAフェイルオーバーは可用性イベントが原因で発生します。
実行中のVMの下からディスクを引き出します。この例では、vSphereおよびほとんどのハイパーバイザーの標準的な動作は、仮想マシンをそのままにし、独自のディスクの問題を処理できるようにすることです。これにはいくつかの理由があります。
一方、多くのワークロード(データベースが頭に浮かぶ)では、破損またはトランザクションの損失が発生する可能性がある場合は、すぐにシャットダウンすることをお勧めします。ただし、最良のシナリオでは、ディスクがないとデータベースをクリーンに静止できないため、とにかく一貫性のない状態になってしまう可能性があります。
最終的には、HAが信頼性の低いストレージに応答するためのいくつかの良い使用例がありますが、今日はそれを実行せず、表示されている動作は完全に正常です。