仮想マシン間でアプリケーションが切り替わるのではなく、仮想マシンそのものが別のESXサーバへ切り替わる（フェイルオーバーする）。そのため、個々の仮想マシンは自分のデータ領域を持つだけでよく、複数の仮想マシンから参照するための共有データ領域は不要である。また、vSphere HAのハートビートにはVMwareの管理ネットワーク（※1）が使用されるため、仮想マシン間HAクラスタのように、個々の仮想マシン間のハートビートは不要である。

※1　vCenterに登録されているESXサーバのホスト名で名前解決されるIPアドレスが属しているネットワーク。

　vSphere HAのハートビートは、ESXサーバのマスター～スレーブ（※2）間で行われる。ハートビート切断時に、ハートビートネットワーク障害なのか、ESXサーバ障害なのかを区別するため、データストアをもう1つのハートビートとして使用する。また、ハートビート切断時に、ネットワーク障害の影響範囲を確認するping確認先のIPアドレスを「隔離アドレス」と呼び、デフォルトの設定ではデフォルトゲートウェイのIPアドレスになっている。

※2　vSphere HAの機能が有効化されると1台のESXサーバがマスターとして選出され、残りのESXサーバはスレーブとなる。マスターは全スレーブの監視や、vSphere HAの構成管理を行う。

　vSphere HAにおけるESXサーバの死活監視は下記の流れで行われる。

1．ESXサーバ間のハートビートが疎通できることを確認
2．データストアハートビートへロックできていることを確認
3．隔離アドレスへpingが到達できることを確認

　ESXサーバ停止障害は分かりやすいが、その他の障害については、障害の箇所や状況によって動作が異なるので、きちんと理解する必要がある。以下に4つのケースについて動作を説明する。図2（各4つの図）のそれぞれのケースにおける右側のESXサーバ（スレーブ2）に着目して、動作を確認していただきたい。

ケース1：ネットワークパーティション状態
ケース2：隔離状態
ケース3：ESXサーバ停止
ケース4：ESXサーバとデータストア間の経路障害　

ケース1：ネットワークパーティション状態

　スイッチ1～スイッチ3間のネットワーク障害が発生すると、下記の流れで確認が行われる。

1．マスター～スレーブ2間のハートビート切断を検知
2．スレーブ2からハートビートデータストアへロックされていることを確認
3．スレーブ2から隔離アドレスへはpingが到達できることを確認

　マスターとのハートビートは切断されるが、スレーブ2から隔離アドレスへpingが到達するため、スレーブ2とその周辺の環境は健全と判断される。すなわち「ネットワークパーティション状態」である。そのため、スレーブ2上の仮想マシンのフェイルオーバーは行われない。

ケース2：隔離状態

　スイッチ2～スレーブ2間のネットワーク障害が発生すると、下記の流れで確認が行われる。

1．マスター～スレーブ2間のハートビート切断を検知
2．スレーブ2からハートビートデータストアへロックされていることを確認
3．スレーブ2から隔離アドレスへはpingが到達できないことを確認

　マスターとのハートビートは切断され、スレーブ2から隔離アドレスへのpingが到達しないため、スレーブ2は孤立したと判断される。すなわち「隔離状態」である。隔離状態で仮想マシンをフェイルオーバーするかは、vSphere HAの「ホスト隔離時の対応」の設定による。デフォルトでは、スレーブ2上の仮想マシンのフェイルオーバーは行われない。

　上記でいう隔離状態はESXサーバの管理ネットワークに関して隔離されているか否かで、仮想マシンがサービスに使用しているネットワークに関してではない。そのため、NIC障害時における仮想マシンのフェイルオーバーのために、安易にフェイルオーバーする設定にすべきではない。ESXサーバの管理ネットワークは隔離されている状態でも、仮想マシンのネットワークに影響が無いケースも十分に考えられるからだ。

ケース3：ESXサーバ停止

　ESXサーバ（スレーブ2）の停止障害が発生すると、下記の流れで確認が行われる。

1．マスター～スレーブ2間のハートビート切断を検知
2．スレーブ2からのハートビートデータストアへロックがされていないことを確認

　マスターとのハートビートは切断される上、スレーブ2からデータストアハートビートがロックされていないため、「ESXサーバ停止」と判断される。そして、スレーブ2上の仮想マシンのフェイルオーバーが行われる。

ケース4：ESXサーバとデータストア間の経路障害

　スレーブ2～データストア間の経路に障害が発生しても、マスター～スレーブ2間のハートビートは正常なため、vSphere HAは障害と判断しない。

　まとめると下記のようになる。

　また、vSphere HAには、「仮想マシンの監視」というオプションがある。デフォルトは「無効」であり、ESXサーバの監視のみを行い、仮想マシンの監視は行われない。そこで、「仮想マシン監視のみ」、または「仮想マシンとアプリケーションの監視」に設定することで仮想マシンを監視することができる。3つ目の「仮想マシンとアプリケーションの監視」については、第4回「VMware環境のHAクラスタ製品の選び方　～vSphere HA＋アプリ監視編」で紹介する。

　仮想マシンの監視は、ゲストOSにインストールされているVMware ToolsからのハートビートおよびI/Oアクティビティ（ディスク、ネットワークへの読み書き）を監視する。ただし、仮想マシンの電源停止は、障害によって起きたのか、管理者が意図的に行ったのか区別ができないため、障害と判断されない。

　デフォルトの設定では、VMware Toolsのハートビートを30秒間受信しないと、I/Oアクティビティを確認する。120秒間I/Oアクティビティが無い場合、該当の仮想マシンを同一ESXサーバ上でリセットする。仮想マシンのリセットは再起動（リブート）ではない。ゲストOSのシャットダウン処理は行われず、アプリの停止も行われないまま電源がオン／オフされる。また、異なるESXサーバへ仮想マシンが切り替わるのではなく、同一のESXサーバ上で仮想マシンが起動する点にも注意が必要だ。

　ここで、ゲストOSのハングアップを「仮想マシンの電源が入っているが、ネットワークI/OもディスクI/Oも行われていない状態」と定義するのであれば、この仮想マシン監視によって、ゲストOSのハングアップを検知できるといえるだろう。

　メーカーのドキュメントによっては、上記の動作の中で行われる仮想マシンのリセットを「仮想マシンの再起動」と記述している場合がある。その他、「仮想マシンの停止」についても、仮想マシンの電源まで停止しているのか、電源が入った状態でWindowsのブルースクリーンで固まっているような状態も指すのかなど、仮想マシンの「停止」「再起動」「ハングアップ」「障害」などの言葉については、定義を明確に確認することで誤解を防ぐことができる。

メリット

　以下、仮想マシン間HAクラスタと比較したメリットである。

• VMwareの標準機能である
• Windows／Linuxを一元管理できる
• 構成がシンプルである
• 待機系用の仮想マシン、仮想マシン間の共有データ領域、ハートビートネットワークのそれぞれが不要となる

デメリット

　以下、仮想マシン間HAクラスタと比較したデメリットである。

• 仮想マシンが使用しているサービス用ネットワークのNIC障害を検知できない
• ESXサーバとデータストア間の経路障害を検知できない
• 仮想マシンの電源停止が検知できない
• 仮想マシン上のアプリケーション障害を検知できない

推奨する設計、運用

　仮想マシン間HAクラスタ対象の仮想マシンはvSphere HAの対象から外し、vSphere HAのデフォルト設定での動作を理解した上で、下記のパラメータ変更を検討する。

• ホスト隔離時の対応
• 隔離アドレス
• アドミッション（※3）
• 仮想マシン監視

※3　フェイルオーバー先のESXサーバの指定やシステムリソースを確保する仕組み。本連載では言及しない。

　ただ、バックアップ製品によっては、vStorage API for Data Protection（VADP）仮想マシンのリストアで仮想マシンの削除を行ってからリストアするものがある。その場合、一旦、仮想マシンがvCenterのインベントリから削除されるため、その仮想マシンに個別に設定していたvSphere HAの設定が、そのクラスタのデフォルト設定になってしまうので注意が必要だ。

---

　今回は、VMwareの標準機能であるvSphere HAの動作について詳しく紹介した。vSphere HAは、仮想マシン上のアプリケーションの監視ができないことは皆さんご存じのことと思う。だが、ハードウェア障害については、もう少し多くのケースで障害を検知でき、仮想マシンのフェイルオーバーが行われると想像されていた方も多かったのではないだろうか。

　vSphere HAの動作を正しく理解した上で、「仮想マシン間HAクラスタ」や、次回紹介する「vSphere HA＋アプリ監視」の方式の併用を検討いただきたい。