本発明は、クラスタシステム、クラスタ制御方法及びクラスタ制御プログラムに関し、特に、ＨＡクラスタを構成するクラスタシステム、クラスタ制御方法及びクラスタ制御プログラムに関する。

複数のホストマシン（コンピュータ）を結合することで冗長化構成を構築するクラスタシステムが知られている。 特に、一部のハードウェアやソフトウェアに障害が発生してもシステム全体で安定して動作するように可用性を高めたシステムは、ＨＡ（High Availability:高可用性）クラスタシステムと呼ばれている。

このＨＡクラスタシステムは、ミッションクリティカルなシステム、すなわち、業務停止時間を極力ゼロに近づけることが求められるシステムに導入されるケースが多い。 そのため、１台のマシンで何か異常が生じた際には別のマシンへ業務を切替えて継続することが使命であり、ＨＡクラスタを構成している全てのサーバが同時に異常となる状態に陥ることを防ぐ必要がある。

また、最近では仮想化環境への移行が加速しており、ミッションクリティカルなシステムも仮想化されるようになってきている。 そして仮想化環境における可用性低下のリスクを軽減するため、仮想化環境でもＨＡクラスタが多く適用されている。

なお、関連する技術として、特許文献１〜３、非特許文献１及び２が知られている。

複数台のホストマシンが存在する仮想化環境において、仮想マシン間でＨＡクラスタ構成を組む場合、ハードウェア障害時にも業務継続を行うという可用性確保の観点から、クラスタを構成する各仮想マシンはそれぞれ別のホストマシン上に常に配置されるべきである。

しかしながら、関連する技術では、例えば計画メンテナンスのための仮想マシンの移行や、仮想化基盤の管理者のオペレーションミス等により、運用開始後に意図せずＨＡクラスタを構成する各仮想マシンが同一ホストマシン上で稼動してしまう事態に陥るリスクがある。 さらに、仮想マシン上にのみクラスタ制御ソフトウェアを導入している場合、ＨＡクラスタを構成する各仮想マシンが同一ホストマシン上で稼動しているかどうかを仮想マシン上からは把握することができない。

したがって、関連する技術では、クラスタを構成する各仮想マシンが同一ホストマシン上で稼働し、さらにそのまま同一ホストマシン上で稼働し続ける恐れがあるため、最適なクラスタを構成することが困難な場合があるという問題があった。

本発明は、このような問題に鑑み、最適なクラスタを簡易に構成することが可能なクラスタシステム、クラスタ制御方法及びクラスタ制御プログラムを提供することを目的とする。

本発明に係るクラスタシステムは、第１の仮想マシンにおいて、前記第１の仮想マシンが稼働中の実マシンを識別する第１の実マシン情報を取得する第１の実マシン情報取得部と、前記第１の仮想マシンとクラスタを構成する第２の仮想マシンにおいて、前記第２の仮想マシンが稼働中の前記実マシンを識別する第２の実マシン情報を取得する第２の実マシン情報取得部と、前記第１または第２の仮想マシンにおいて、前記取得した第１及び第２の実マシン情報を照合する実マシン情報照合部と、前記第１または第２の仮想マシンにおいて、前記照合の結果、第１及び第２の実マシン情報が一致する場合、前記第１または第２の仮想マシンを別の前記実マシンへ移行する移行要求を送信する移行要求部と、を備えるものである。

本発明に係るクラスタ制御方法は、第１の仮想マシンにおいて、前記第１の仮想マシンが稼働中の実マシンを識別する第１の実マシン情報を取得し、前記第１の仮想マシンとクラスタを構成する第２の仮想マシンにおいて、前記第２の仮想マシンが稼働中の前記実マシンを識別する第２の実マシン情報を取得し、前記第１または第２の仮想マシンにおいて、前記取得した第１及び第２の実マシン情報を照合し、前記第１または第２の仮想マシンにおいて、前記照合の結果、第１及び第２の実マシン情報が一致する場合、前記第１または第２の仮想マシンを別の前記実マシンへ移行する移行要求を送信するものである。

本発明に係るクラスタ制御プログラムは、第１の仮想マシンにおいて、前記第１の仮想マシンが稼働中の実マシンを識別する第１の実マシン情報を取得し、前記第１の仮想マシンとクラスタを構成する第２の仮想マシンにおいて、前記第２の仮想マシンが稼働中の前記実マシンを識別する第２の実マシン情報を取得し、前記第１または第２の仮想マシンにおいて、前記取得した第１及び第２の実マシン情報を照合し、前記第１または第２の仮想マシンにおいて、前記照合の結果、第１及び第２の実マシン情報が一致する場合、前記第１または第２の仮想マシンを別の前記実マシンへ移行する移行要求を送信する、クラスタ制御処理をコンピュータに実行させるためのものである。

本発明によれば、最適なクラスタを簡易に構成することが可能なクラスタシステム、クラスタ制御方法及びクラスタ制御プログラムを提供することができる。

参考例のクラスタシステムの動作を説明するための構成図である。

参考例のクラスタシステムの動作を説明するための構成図である。

参考例のクラスタシステムの動作を説明するための構成図である。

参考例のクラスタシステムの動作を説明するための構成図である。

実施の形態に係るクラスタシステムの動作を説明するための構成図である。

実施の形態に係るクラスタシステムの動作を説明するための構成図である。

実施の形態に係るクラスタシステムの動作を説明するための構成図である。

実施の形態１に係るクラスタシステムの構成を示す構成図である。

実施の形態１に係るクラスタシステムの構成を示す構成図である。

実施の形態１に係るクラスタシステムの動作を示すフローチャートである。

実施の形態１に係るクラスタシステムの動作を示すフローチャートである。

実施の形態１に係るクラスタシステムの動作を示すフローチャートである。

実施の形態１に係るクラスタシステムの動作を示すフローチャートである。

実施の形態１に係るクラスタシステムの動作を示すフローチャートである。

実施の形態１に係るクラスタシステムの動作を示すフローチャートである。

実施の形態２に係るクラスタシステムの構成を示す構成図である。

実施の形態３に係るクラスタシステムの構成を示す構成図である。

実施の形態３に係るクラスタシステムの構成を示す構成図である。

実施の形態３に係るクラスタシステムの構成を示す構成図である。

実施の形態３に係るクラスタシステムの構成を示す構成図である。

（実施の形態の概要）
まず、実施の形態適用前の参考例について説明する。 図１に示すように、参考例に係るクラスタシステムは、仮想化基盤管理マシンＭ１、ホストマシンＨＭ１〜ＨＭ４を備えており、ホストマシンＨＭ１〜ＨＭ４の上に仮想マシンＶＭ１〜ＶＭ８が稼働している。

例えば、図１の運用開始時には、ホストマシンＨＭ１の上に仮想マシンＶＭ１及びＶＭ２、ホストマシンＨＭ２の上に仮想マシンＶＭ３及びＶＭ４、ホストマシンＨＭ３の上に仮想マシンＶＭ５及びＶＭ６、ホストマシンＨＭ４の上に仮想マシンＶＭ７及びＶＭ８が稼働している。 そして、仮想マシンＶＭ２及びＶＭ３、仮想マシンＶＭ４及びＶＭ５、仮想マシンＶＭ６及びＶＭ７、がそれぞれＨＡクラスタを構成している。

図１の運用開始の後、ホストマシンＨＭ１でメンテナンスが実施される場合、図２のように、ホストマシンＨＭ１の上の仮想マシンＶＭ１及びＶＭ２が他のホストマシンへ移行する。 このとき、ホストマシンの管理者は仮想化基盤管理マシンＭ１を操作し、特に意識せずに仮想マシンを他のホストマシン上へ移行する。 図２の例では、仮想マシンＶＭ１をホストマシンＨＭ３へ移行し、仮想マシンＶＭ２をホストマシンＨＭ２へ移行する。

このため、１つのホストマシンＨＭ２の上に、ＨＡクラスタを構成する仮想マシンＶＭ２及びＶＭ３が稼働する状態となる。 しかし、通常、仮想マシン側だけを管理している管理者の立場からは、同一ホストマシン上で２つの仮想マシンがＨＡクラスタを構成していることに気づかない場合が多いため、図２の状態で業務が継続される。

そうすると、図２の状態の後、ホストマシンＨＭ２で障害が発生した場合、図３のように、ホストマシンＨＭ２の上の仮想マシンＶＭ４で運用されている業務Ｃは、ＨＡクラスタを構成する他の仮想マシン、すなわち、ホストマシンＨＭ３の上の仮想マシンＶＭ５へフェイルオーバして業務を継続することが可能である。 しかし、仮想マシンＶＭ２及びＶＭ３の業務Ｂについては、同じホストマシンＨＭ２の上で稼働していたため、仮想マシンＶＭ２及びＶＭ３ともにダウンし、業務を継続することができない。

このように、参考例に係る仮想マシン間のＨＡクラスタ構成では、ＨＡクラスタを構成する仮想マシンがいつどのホストマシン上で稼動しているかを確認する仕組みを実装していなかった。 そのため、例え初期配置では各仮想マシンが別々のホストマシン上に起動するように設計していたとしても、運用開始後にいつの間にかＨＡクラスタを構成する各仮想マシンが同一ホストマシン上で稼動してしまっている可能性は十分にあり、対象ホストマシン障害時には現用系／待機系両方の仮想マシンがダウンし、業務継続できない可能性があった。

また、複数台の待機系マシンが存在するクラスタ構成の場合に、ホストマシンの情報を確認した上で、同一ホスト上にいない仮想マシンを優先フェイルオーバ先として動的に判断するといった、クラスタ稼動状態を加味した動作というのは、関連する技術では実現不可能であったため、より柔軟な動作が求められていた。

また、このような課題は物理マシン同士のＨＡクラスタシステムでは生じなかったものであり、近年の急速な仮想化環境導入に伴い、一部で表面化してきたものである。

なお、図４のように、仮想化ソフトの機能により、特定仮想マシン間で排他設定を実施し、同一ホスト上に移行されないように制限することや、仮想化ソフトにより、ホストマシン間で予めクラスタ設定を実施することも可能な場合がある。 例えば、特定の条件下においては、仮想化ソフトウェア側の機能を用いて仮想マシンの排他制御を行ったり、業務アプリケーションごとに特定の分散配置制御を行うことで課題となる状態に陥ることを回避することは可能であったが、それ以外の条件下においては代替となる解決策はなかった。 また、関連する技術は、いずれも仮想化ソフトウェアやクラウド基盤、あるいは特定アプリケーションからの固定的な制御のため、例えば複数台のクラスタマシンが存在する場合に、同一ホスト上にいない仮想マシンを優先フェイルオーバ先として動的に判断するといった、クラスタの構成や稼動状態を加味した動作というのは、関連する技術では実現不可能であったため、より柔軟な動作が求められていた。

すなわち、仮想化ソフトウェアには様々な種類が存在し、ユーザは各ソフトウェアが提供する機能やコスト面、他ソフトウェアとの親和性など様々な条件を元に最適な仮想化ソフトウェアを選択する。 例えば、非特許文献１や２のｖＳｐｈｅｒｅ（ヴイエムウェア社）などが知られている。

ｖＳｐｈｅｒｅでは、図４のような機能は、Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ、またはＥｎｔｅｒｐｒｉｓｅ Ｐｌｕｓ Ｅｄｉｔｉｏｎという条件下でのみ使用可能である。 そのため、上記以外の条件下の構成では、図１〜図３で示した課題を解決する方法がなかった。 つまり、ごく限られた環境でしか解決策となり得なかった。

図４に示した例はあくまで仮想化ソフトウェアの提供する機能であったため、クラスタ構成やクラスタの状態について知る方法がなく、クラスタの状態に応じた最適な処理を柔軟に行なうことができなかった。

そこで実施の形態では、使用範囲を限定することなく幅広い条件下で課題の解決を実現できるシステム／方法を提供可能とし、また、さらにクラスタソフトの既存コンポーネントと密連携することで、クラスタの状態を加味した最適な処理を柔軟に選択／実行できるシステム／方法を提供可能とする。

なお、ホストマシン障害時に仮想マシンを別のホストマシンで再起動させるという、仮想化ソフトウェアの技術が存在する。 しかし、当該技術とＨＡクラスタ技術とでは「業務停止時間」および「検出可能な障害範囲」に明確な差異があるため、特にミッションクリティカルなシステムにおいては、ＨＡクラスタ技術が必要とされる。

このような課題を解決するため、実施の形態では、仮想マシン間でのＨＡクラスタシステム構築おいて、仮想マシン上からホストマシンの情報をリモートで取得し、さらに取得結果に応じて動作要求の指示を送る。 これにより、物理サーバ間のＨＡクラスタシステムにはない、仮想化環境特有の可用性低下のリスクの軽減を可能とする。 また、設定／運用を全て仮想マシン上で動作するクラスタ制御ソフトウェア側で実施することで、関連技術や参考例で生じていた課題を解決し、さらに、ＨＡクラスタの構成や運用状態に応じた柔軟な動作選択といった応用が可能となる。

次に、参考例に実施の形態を適用した例について説明する。 図５に示すように、実施の形態に係るクラスタシステムは、図１の参考例と同様に、仮想化基盤管理マシンＭ１、ホストマシンＨＭ１〜ＨＭ４を備えており、ホストマシンＨＭ１〜ＨＭ４の上に仮想マシンＶＭ１〜ＶＭ８が稼働している。

図１と同じ仮想マシン及びＨＡクラスタ構成により運用開始された後、ホストマシンＨＭ１でメンテナンスが実施される場合、図５のように、ホストマシンＨＭ１の上の仮想マシンＶＭ１及びＶＭ２が移行する。 すなわち、ホストマシンの管理者は特に意識せずに仮想マシンを他のホストマシン上へ移行する。 図５の例では、図２と同様に、仮想マシンＶＭ１をホストマシンＨＭ３へ移行し、仮想マシンＶＭ２をホストマシンＨＭ２へ移行する。

そこで、実施の形態では、仮想マシンＶＭ３から仮想化基盤管理マシンＭ１に対して定期的に対象仮想マシンが稼動するホストマシン情報（仮想マシン位置情報）の問い合わせを行う。 基本的には業務を実行していない低負荷な待機系仮想サーバから問い合わせのためのスクリプト（プログラム）を実行することが好ましい。

そして、図６に示すように、仮想マシンＶＭ２と仮想マシンＶＭ３が稼動するホストマシンとして同一のホストマシン情報（文字列）が返却された場合、業務Ｂ停止のリスクを軽減するため、待機系となっている仮想マシンＶＭ３を正常稼働中の他ホストマシンへ移行するよう、仮想化基盤管理マシンＭ１へ要求を送信する。

そうすると、図７のように、仮想化基盤管理マシンＭ１からの指示により仮想マシンＶＭ３はホストマシンＨＭ４へ移行する。 そのため、ホストマシンＨＭ２がダウンしても、業務Ｂは、ホストマシンＨＭ４の仮想マシンＶＭ３へフェイルオーバし、業務Ｃは、ホストマシンＨＭ３の仮想マシンＶＭ５へフェイルオーバして業務継続が可能となる。

実施の形態では、ＨＡクラスタを構成する各仮想マシンから、定期的に仮想化基盤管理マシンに対して仮想マシンの稼動情報の問い合わせを行う。 そして、各仮想マシンの問い合わせ結果を照合し、同一ホストマシン上で稼動していることが判明した場合には、待機系となっている仮想マシンを別のホストマシン上へライブマイグレーションで移行するよう、仮想化基盤管理マシンに対して要求を送信する。 このように、クラスタ制御ソフトウェア側で仮想マシンの位置情報を保持させることで、ＨＡクラスタを構成する各仮想マシンが同一ホストマシン上で稼動することを防ぎ、ハードウェア障害時にも確実な業務継続を可能とする。

さらに、本実施の形態を用いることで、クラスタの構成や稼動状態に応じた柔軟な動作が可能となり、例えば複数台の待機系マシンが存在する場合には、同一ホストマシン上に存在しない仮想マシンを優先フェイルオーバ先として動的に判断してフェイルオーバするといった、クラスタ制御ソフトウェアならではの動作が可能となる。

なお、特許文献２は、冗長構成の環境へ移行可能な場合にはリソース管理テーブルを参照し同じシステムを構成する仮想マシンを同じ物理サーバに集めないようにするものである。 しかし、ここで示す冗長構成への移行とは異なるホストマシン上に新たに仮想マシンを追加するという処理のため、既にクラスタ構成にある仮想マシンをライブマイグレーションするものではない。

また、特許文献３は、仮想マシンリソーステーブルにおいてＣＰＵ／メモリの使用できる空き容量を示し、仮想サーバ列に「空き」エントリを有するレコードを見つけるものである。 しかし、仮想マシンリソーステーブルに表示されるＣＰＵ／メモリの空き容量は物理サーバの観点で確認したリソース情報であり、アプリケーションが稼働する仮想サーバでＣＰＵ／メモリなどの使用状況を確認し、仮想サーバ観点でのリソース使用状況に応じてアプリケーションのフェイルオーバや負荷分散といった動作を実行するものではない。

（実施の形態１）
以下、図面を参照して実施の形態１について説明する。 図８は、本実施の形態に係るクラスタシステムの構成例を示している。 本実施の形態は、仮想化基盤管理機能をホストマシンとは別の装置に設けた構成、つまり、仮想化基盤管理機能がホストマシンから外出しされている環境において、仮想マシン２台でＨＡクラスタを構成する例である。

図８に示すように、本実施の形態に係るクラスタシステムは、２つの仮想マシン１１０（１１０ａ及び１１０ｂ）、ホストマシン１００、仮想化基盤管理マシン２００を備えている。 クラスタシステムは、物理環境（実環境）として、物理マシン（実マシンン）であるホストマシン１００及び仮想化基盤管理マシン２００を備え、仮想化環境として、仮想マシン１１０ａ及び１１０ｂを備えているともいえる。 また、ホストマシン（コンピュータ、情報処理装置）１００が、仮想マシン１１０ａ及び１１０ｂを備えているともいえる。

ＨＡクラスタは、２台の仮想マシン１１０ａ及び１１０ｂで構成される。 仮想マシン１１０ａ及び１１０ｂの一方が、業務プログラム（アプリケーション）を実行する現用系仮想マシン（例えば１１０ａ）であり、他方が業務プログラムを実行せずに待機する待機系仮想マシン（例えば１１０ｂ）である。 仮想マシン１１０ａ及び１１０ｂは、ホストマシン１００の上で稼動しており、仮想マシン１１０ａ及び１１０ｂとホストマシン１００は、仮想化基盤管理マシン２００にて集中管理されている。

なお、ここでは、図８の各ブロックの構成例を用いて説明するが、後述する本実施の形態に係る動作が実現できれば、その他の構成であってもよい。

仮想マシン１１０（１１０ａ及び１１０ｂ）、ホストマシン１００、仮想化基盤管理マシン２００における各構成は、ハードウェア又はソフトウェア、もしくはその両方によって構成され、１つのハードウェア又はソフトウェアから構成してもよいし、複数のハードウェア又はソフトウェアから構成してもよい。

仮想マシン１１０、ホストマシン１００、仮想化基盤管理マシン２００の各機能（各処理）を、ＣＰＵやメモリ等を有するコンピュータにより実現してもよい。 例えば、ホストマシンの記憶装置に仮想マシンを構成するための仮想マシン構成プログラムやクラスタ制御を行うためのクラスタ制御プログラム（クラスタ制御ソフトウェア）を格納し、仮想化基盤管理マシンの記憶装置に仮想化基盤管理を行うための仮想化基盤管理プログラムを格納して、これらの記憶装置に格納されたプログラムをＣＰＵ（コンピュータ）で実行することにより、図８の各機能を実現してもよい。

これらのプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。 非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。 非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory））を含む。 また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。 一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。 一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

仮想化基盤管理マシン２００は、仮想マシン移行操作実行部２１、仮想マシン移行要求受信部２２、仮想マシン位置情報管理部２３を備えている。

仮想マシン移行要求受信部２２は、仮想マシン１１０から仮想マシン移行要求を受信し、受信した仮想マシン移行要求に基づいて移行指示（移行操作指示）を発行する。 仮想マシン移行操作実行部２１は、仮想マシン移行要求受信部２２から移行指示を受け付け、この移行指示に基づいて、仮想マシン１１０を別のホストマシンへ移行する移行処理（仮想マシン移行操作）を実行する。 仮想マシン移行操作実行部２１は、ライブマイグレーションにより、仮想マシン１１０を停止することなく別のホストマシンへ移行する。 例えば、仮想マシン移行操作実行部２１は、移行元の仮想マシン１１０の環境（メモリやディスクイメージ）を移行先のホストマシンへ転送し（引き渡し）、移行元で仮想マシンをフリーズ（一時停止）するとともに、移行先で仮想マシンのフリーズを解除（復帰）する。

仮想マシン位置情報管理部２３は、仮想マシンが稼働しているホストマシンを示す仮想マシン位置情報（ホストマシン情報）を保持する位置情報保持部でもある。 例えば仮想マシン位置情報は、ホストマシン名であり、仮想マシン位置情報管理部２３は、仮想マシンと該仮想マシンが稼働しているホストマシン名とを関連付けて記憶している。 仮想マシン位置情報管理部２３は、仮想マシン１１０から仮想マシン位置情報問い合わせ（問い合わせ要求）を受信し、保持している位置情報を参照することで、問い合わせの仮想マシンに該当する仮想マシン位置情報を仮想マシン位置情報回答（応答）として仮想マシン１１０へ送信する。

仮想マシン１１０（１１０ａ及び１１０ｂ）には、それぞれクラスタ制御ソフトウェア１１１（１１１ａ及び１１１ｂ）が導入されており、このクラスタ制御ソフトウェア１１１ａ及び１１１ｂによって、仮想マシン１１０ａ及び１１０ｂはＨＡクラスタを構成している。 すなわち、クラスタ制御ソフトウェアは、各仮想マシンにおいて、ＨＡクラスタ構成を制御するためのクラスタ制御部を実現する。

クラスタ制御ソフトウェア（クラスタ制御部）１１１（１１１ａ及び１１１ｂ）は、それぞれアプリケーション制御部１１（１１ａ及び１１ｂ）、リソース監視部１２（１２ａ及び１２ｂ）、クラスタ状態管理部１３（１３ａ及び１３ｂ）、仮想マシン移行要求部１４（１４ａ及び１４ｂ）、仮想マシン位置情報取得部１５（１５ａ及び１５ｂ）、クラスタ間情報照合部１６（１６ａ及び１６ｂ）を備えている。 例えば、仮想マシン移行要求部１４、仮想マシン位置情報取得部１５、クラスタ間情報照合部１６は、新たに追加された本実施の形態を実現するための主要部である。

アプリケーション制御部１１（１１ａ及び１１ｂ）は、それぞれ仮想マシン１１０におけるアプリケーション（業務プログラム）の起動／停止を制御する。 リソース監視部１２は、それぞれ仮想マシン１１０におけるアプリケーションやハードウェアなどの各種リソースを監視する。

仮想マシン位置情報取得部１５（１５ａ及び１５ｂ）は、仮想化基盤管理マシン２００の仮想マシン位置情報管理部２３に対して仮想マシン位置情報の問い合わせ／回答受信を行う。 すなわち、仮想マシン位置情報取得部１５は、それぞれ仮想マシン１１０が、現在、稼働しているホストマシンを問い合わせるための仮想マシン位置情報問い合わせを仮想化基盤管理マシン２００へ定期的に送信し、また、仮想化基盤管理マシン２００から仮想マシン位置情報回答を受信し、仮想マシン位置情報（ホストマシン情報）を取得する。

クラスタ間情報照合部１６（１６ａ及び１６ｂ）は、仮想マシン１１０（１１０ａ及び１１０ｂ）間で仮想マシン位置情報取得部１５（１５ａ及び１５ｂ）がそれぞれ取得した情報を照合する。 すなわち、クラスタ間情報照合部１６は、仮想マシン位置情報取得部１５ａ及び１５ｂが取得した仮想マシン１１０ａ及び１１０ｂの２つの仮想マシン位置情報（ホストマシン情報）を照合（比較）し、一致／不一致を判定する。

クラスタ状態管理部１３（１３ａ及び１３ｂ）は、アプリケーション制御部１１の制御やリソース監視部１２の監視に基づいて、各種リソースやアプリケーションの起動停止状態の推移などを含めクラスタ全体の最新状態を管理している。 例えば、クラスタ状態管理部（移行先決定部）１３は、リソースの状態に基づいて待機系の仮想マシンへのフェイルオーバを要求し、複数の待機系の仮想マシンの中から最適なフェイルオーバ先の決定も行う。 また、クラスタ状態管理部１３は、クラスタ間情報照合部１６が照合した結果に基づいて仮想マシンの移行要求を指示する。 例えば、仮想マシン１１０ａ及び１１０ｂの仮想マシン位置情報が一致している場合、仮想マシン１１０ａまたは１１０ｂを別のホストマシンへ移行させるため、仮想マシン移行要求を仮想マシン移行要求部１４へ指示する。

仮想マシン移行要求部１４（１４ａ及び１４ｂ）は、仮想化基盤管理マシン２００の仮想マシン移行要求受信部２２に対して仮想マシンの移行要求を送信する。 すなわち、仮想マシン移行要求部１４は、クラスタ間情報照合部１６が照合した結果に基づいて、クラスタ状態管理部１３から仮想マシンの移行要求指示を受け、仮想マシン移行要求を仮想化基盤管理マシン２００へ送信する。

アプリケーション１１２は、仮想マシン１１０（１１０ａまたは１１０ｂのいずれか）で実行されて各種業務を提供する業務プログラムである。 アプリケーション１１２は、アプリケーション制御部１１の制御によって、仮想マシン１１０ａ及び１１０ｂ間で切替えて動作可能である。 例えば、現用系の仮想マシン上でアプリケーション１１２を実行することで業務を開始し、現用系の仮想マシンに障害が発生した場合、待機系の仮想マシン上でアプリケーション１１２を実行するように切り替えることで業務を継続する。

例えば、本実施の形態に係るクラスタシステムは、図８の構成のうち、少なくとも図９の構成を備えるものであってもよい。 すなわち、図９に示すように、クラスタシステムは、仮想マシン位置情報取得部１５ａ及び１５ｂ、クラスタ間情報照合部１６、仮想マシン移行要求部１４を備えている。

仮想マシン位置情報取得部（第１の実マシン情報取得部）１５ａは、仮想マシン（第１の仮想マシン）１１０ａにおいて、仮想マシン１１０ａが稼働中のホストマシン（実マシン）を識別する第１の仮想マシン位置情報（実マシン情報）を取得する。 仮想マシン位置情報取得部（第２の実マシン情報取得部）１５ｂは、仮想マシン１１０ａとクラスタを構成する仮想マシン（第２の仮想マシン）１１０ｂにおいて、仮想マシン１１０ｂが稼働中のホストマシンを識別する第２の仮想マシン位置情報を取得する。 クラスタ間情報照合部（実マシン情報照合部）１６は、仮想マシン１１０（１１０ａまたは１１０ｂ）において、取得した第１及び第２の仮想マシン位置情報を照合する。 仮想マシン移行要求部（移行要求部）１４は、仮想マシン１１０（１１０ａまたは１１０ｂ）において、クラスタ間情報照合部１６の照合の結果、第１及び第２の仮想マシン位置情報が一致する場合、仮想マシン１１０（１１０ａまたは１１０ｂ）を別のホストマシンへ移行する移行要求を送信する。

少なくとも、図９の構成により、各仮想マシンから現在稼働しているホストマシンの情報を取得し、同一ホストマシンの場合に仮想マシンを別のホストマシンへ移行することが可能となるため、最適なクラスタを簡易に構成することができる。

次に、図８を参照しつつ、図１０〜図１５を用いて、本実施の形態に係るクラスタシステムの動作について説明する。

図８では、現在、アプリケーション１１２は仮想マシン１１０ａ上で稼動しているため、仮想マシン１１０ａが現用系、仮想マシン１１０ｂが待機系となっている。 また、仮想マシン１１０ａ及び１１０ｂは同一ホストマシン１００上で稼動している状態である。 リソース監視部１２（１２ａ及び１２ｂ）は対象リソースに対して常時監視を実行しており、常に最新の実行状態がクラスタ状態管理部１３（１３ａ及び１３ｂ）に通知されている。

仮想マシン位置情報取得部１５（１５ａ及び１５ｂ）は、図１０に示す仮想マシン位置情報取得処理を実行している。 まず、仮想マシン位置情報取得部１５は、自身(仮想マシン１１０ａまたは１１０ｂ)の稼動するホストマシン名（ホストマシン情報）を取得する（Ｓ１０１）。 すなわち、仮想マシン位置情報取得部１５は、定期的に仮想マシン位置情報管理部２３に対して、自身(仮想マシン１１０ａまたは１１０ｂ)の稼動するホストマシン名の取得要求を送信し、要求を受けた仮想マシン位置情報管理部２３は、仮想マシン位置情報取得部１５に対してホストマシン名を回答する。

次いで、仮想マシン位置情報取得部１５は、自身（仮想マシン１１０ａまたは１１０ｂ）のホストマシン情報を他のクラスタノード（仮想マシン１１０ａまたは１１０ｂ）と共有する（Ｓ１０２）。 すなわち、ホストマシン情報を取得した仮想マシン位置情報取得部１５は、クラスタ間情報照合部１６にホストマシン情報を提供する。 その後、仮想マシン位置情報取得部１５は、Ｓ１０１及びＳ１０２の処理を繰り返す（Ｓ１０３）。

また、クラスタ間情報照合部１６（１６ａ及び１６ｂ）は、図１１に示すホストマシン情報照合処理を実行している。 なお、クラスタ間情報照合部１６のホストマシン情報の照合、クラスタ状態管理部１３の仮想マシン移行要求の指示、仮想マシン移行要求部１４の仮想マシン移行要求の送信の処理は、いずれの仮想マシンで実行してもよいが、仮想マシンの負荷を軽減するため、待機系の仮想マシン１１０（例えば１１０ｂ）で実行することが好ましい。

まず、クラスタ間情報照合部１６は、各仮想マシン１１０（１１０ａ及び１１０ｂ）のホストマシン情報を受信する（Ｓ２０１）。 すなわち、図１０のＳ１０２により、クラスタ間情報照合部１６は、仮想マシン位置情報取得部１５から自身のホストマシン情報を受信し、また、他のクラスタノード（仮想マシン１１０ａまたは１１０ｂ）のクラスタ間情報照合部１６から、他のクラスタノードのホストマシン情報を受信（取得）する。

次いで、クラスタ間情報照合部１６は、各仮想マシン１１０（１１０ａ及び１１０ｂ）のホストマシン情報を照合し（Ｓ２０２）、その照合結果をクラスタ状態管理部１３へ通知する（Ｓ２０３）。 すなわち、クラスタ間情報照合部１６は、受信した仮想マシン１１０ａ及び１１０ｂの稼動するホストマシン名（ホストマシン情報）を比較し、一致／不一致を判定した判定結果を、クラスタ状態管理部１３へ通知する。 その後、クラスタ間情報照合部１６は、Ｓ２０１〜Ｓ２０３の処理を繰り返す（Ｓ２０４）。

また、クラスタ状態管理部１３は、クラスタ間情報照合部１６から受け取った照合結果を判定し（Ｓ２１１）、照合結果が不一致であった場合、何も動作を行わない。 一方、クラスタ状態管理部１３は、受け取った照合結果が一致していた場合は、仮想マシン移行要求部１４に対して、仮想マシン１１０（１１０ａまたは１１０ｂ）の移行要求を送信するよう指示する（Ｓ２１２）。 図８の例では、そのときの待機系である仮想マシン１１０ｂを別のホストマシン上へ移行するために、待機系マシンのクラスタ状態管理部１３ｂが仮想マシン移行要求部１４ｂに対して、仮想マシン１１０ｂの移行要求を送信するよう指示する。

また、仮想マシン移行要求部１４（１４ａ及び１４ｂ）は、図１２に示す仮想マシン移行要求処理を実行している。 仮想マシン移行要求部１４は、図１１のＳ２２２により、クラスタ状態管理部１３から仮想マシン移行要求指示を受信する（Ｓ３０１）。 次いで、仮想マシン移行要求部１４は、仮想マシン移行要求受信部２２へ仮想マシン１１０の移行要求を送信する。 図８の例では、仮想マシン１１０ｂの移行要求指示を受信した仮想マシン移行要求部１４ｂが、仮想マシン移行要求受信部２２に対して、仮想マシン１１０ｂの移行を要求する。 その後、仮想マシン移行要求部１４は、Ｓ３０１及びＳ３０２の処理を繰り返す（Ｓ３０３）。

Ｓ３０２により、要求を受け取った仮想マシン移行要求受信部２２は、仮想マシン移行操作実行部２１に対して移行操作指示を発行し、仮想マシン移行操作実行部２１によって、仮想マシン１１０（例えば１１０ｂ）は別のホストマシン上へ無停止で移行される。

また、リソース監視部１２（１２ａ及び１２ｂ）は、図１３に示すリソース監視処理を実行している。 まず、リソース監視部１２は、対象リソースへの監視を実行し（Ｓ４０１）、その監視結果を判定する（Ｓ４０２）。 リソース監視部１２は、監視の結果が異常状態の場合、異常状態をクラスタ状態管理部１３へ通知する。 その後、リソース監視部１２は、Ｓ４０１〜Ｓ４０３の処理を繰り返す（Ｓ４０４）。

また、クラスタ状態管理部１３（１３ａ及び１３ｂ）は、図１４に示すフェイルオーバ決定処理を実行している。 まず、クラスタ状態管理部１３は、図１３のＳ４０３により、リソース監視部１２からリソース異常検知情報を受信する（Ｓ５０１）。 クラスタ状態管理部１３は、受信したリソース異常検知情報により待機系サーバ（仮想マシン１１０）の数を判定し（Ｓ５０２）、待機系サーバが複数台存在する場合、複数の待機系サーバからフェイルオーバ先を判定する（Ｓ５０３）。

Ｓ５０２またはＳ５０３の後、クラスタ状態管理部１３は、アプリケーションフェイルオーバ要求をアプリケーション制御部１１へ送信する（Ｓ５０４）。 その後、クラスタ状態管理部１３は、Ｓ５０１〜Ｓ５０５の処理を繰り返す。

また、アプリケーション制御部１１（１１ａ及び１１ｂ）は、図１５に示すフェイルオーバ実行処理を実行している。 まず、アプリケーション制御部１１は、図１４のＳ５０４により、クラスタ状態管理部１３からアプリケーションフェイルオーバ要求を受信する（Ｓ６０１）。

続いて、アプリケーション制御部１１は、アプリケーションの停止／起動処理を実行し（Ｓ６０２）、クラスタ状態管理部１３へフェイルオーバ完了通知を送信する。 その後、アプリケーション制御部１１は、Ｓ６０１〜Ｓ６０３の処理を繰り返す（Ｓ６０４）。

以上のような本実施の形態に係るクラスタシステムにより、次のような効果が得られる。 すなわち、仮想マシンが動作するホストマシンの情報を定期的に取得／照合し、最適な復旧動作の指示を出すことで、最適なクラスタを簡易に構成でき、ハードウェア障害時の業務停止リスクを抑止できる。

また、クラスタ制御ソフトウェアの機能としてホストマシンの情報取得/照合を行うことで、関連する技術では実現できなかった、ＨＡクラスタの構成や稼動状態に応じた復旧動作の自動判定が可能となる。 さらに、ホストマシンの障害時だけでなく、仮想マシン内の障害時にも、この復旧動作の自動判定が利用可能である。

また、障害発生時だけでなく、システム高負荷などの障害予兆を検出した際に、待機系マシンのアプリケーションを起動して一時的に負荷分散運用に切替えるなど、アプリケーションの最配置も自動で実行が可能である。

また、クラスタ制御ソフトウェアの機能の一部として提供するため、仮想マシン制御のために運用管理ソフトウェアなどを追加したり、仮想化基盤側で設定を変更したりする必要がないため、あらたな導入コストや設定工数の発生を防ぐことができる。

（実施の形態２）
以下、図面を参照して実施の形態２について説明する。 図１６は、本実施の形態に係るクラスタシステムの構成例を示している。 本実施の形態は、仮想化基盤管理機能をホストマシンの内部に設けた例であり、すなわち、仮想化基盤管理機能がホストマシンに包含されている環境における、仮想マシン２台でＨＡクラスタを構成する例である。

図１６に示すように、本実施の形態に係るクラスタシステムの構成要素および各要素の役割は、「仮想化基盤管理マシン」を除いて全て図８と同じである。 すなわち、本実施の形態においては、仮想マシン１１０ａ及び１１０ｂの構成は図８と同様である。 また、ホストマシン１００およびその上で稼動する仮想マシン１１０ａ及び１１０ｂを管理する仮想化基盤管理機能がホストマシン１００に包含されているため、仮想マシン位置情報管理部２３、仮想マシン移行要求受信部２２、仮想マシン移行操作実行部２１は、全てホストマシン１００の中に構成されている。

なお、仮想化基盤管理マシンの一部をホストマシンに備えてもよい。 例えば、仮想化基盤管理マシンに仮想マシン移行要求受信部２２、仮想マシン移行操作実行部２１を備え、ホストマシンに仮想マシン位置情報管理部２３を備えてもよい。

本実施の形態では、仮想マシン位置情報取得部１５（１５ａ及び１５ｂ）は、ホストマシン１００の仮想マシン位置情報管理部２３に対して仮想マシン位置情報の問い合わせ／回答受信を行う。 また、取得した仮想マシン位置情報（ホストマシン情報）が一致した場合に、仮想マシン移行要求部１４（１４ａ及び１４ｂ）は、ホストマシン１００の仮想マシン移行要求受信部２２に対して仮想マシンの移行要求を送信する。

このように、ホストマシンに仮想化基盤管理マシンの機能を備えた場合でも、実施の形態１と同様の効果を得ることができる。

（実施の形態３）
以下、図面を参照して実施の形態３について説明する。 図１７Ａ〜図１７Ｄは、本実施の形態に係るクラスタシステムの構成例を示している。 本実施の形態は、実施の形態１と同様に、仮想化基盤管理機能をホストマシンとは別の装置に設けた構成、つまり、仮想化基盤管理機能がホストマシンから外出しされている環境において、仮想マシン４台でＨＡクラスタを構成する例である。

図１７Ａ〜図１７Ｄに示すように、本実施の形態に係るクラスタシステムは、４つの仮想マシン１１０（１１０ａ〜１１０ｄ）、３つのホストマシン１００（１００ａ〜１００ｃ）、仮想化基盤管理マシン２００を備えている。 クラスタシステムは、物理環境（実環境）として、物理マシン（実マシンン）であるホストマシン１００ａ〜１００ｃ及び仮想化基盤管理マシン２００を備え、仮想化環境として、仮想マシン１１０ａ〜１１０ｄを備えているともいえる。

ＨＡクラスタは、仮想マシン１１０ａ〜１１０ｄの４台で構成される。 仮想マシン１１０ａ〜１１０ｄは３台のホストマシン１００ａ〜１００ｃの上で稼動しており、仮想マシン１１０ａ〜１１０ｄおよびホストマシン１００ａ〜１００ｃは、仮想化基盤管理マシン２００にて集中管理されている。 仮想化基盤管理マシン２００の構成要素は、実施の形態１の図８と同様である。 例えば、仮想マシン１１０ａはホストマシン１００ａで稼働し、仮想マシン１１０ｂ及び１１０ｃはホストマシン１００ｂで稼働し、仮想マシン１１０ｄはホストマシン１００ｃで稼働している。

また、実施の形態１と同様に、仮想マシン１１０（１１０ａ〜１１０ｄ）には、それぞれクラスタ制御ソフトウェア１１１（１１１ａ〜１１１ｄ）が導入されており、このクラスタ制御ソフトウェア１１１ａ〜１１１ｄによって、仮想マシン１１０ａ〜１１０ｄはＨＡクラスタを構成している。 クラスタ制御ソフトウェア１１１（１１１ａ〜１１１ｄ）の構成要素は、実施の形態１の図８と同様である。

クラスタ間情報照合部１６（１６ａ〜１６ｄ）は、仮想マシン１１０（１１０ａ〜１１０ｄ）間で仮想マシン位置情報取得部１５（１５ａ〜１５ｄ）がそれぞれ取得した情報を照合する。 すなわち、クラスタ間情報照合部１６は、仮想マシン位置情報取得部１５ａ〜１５ｄが取得した仮想マシン１１０ａ〜１１０ｄの４つの仮想マシン位置情報（ホストマシン情報）を照合（比較）し、一致／不一致を判定する。

クラスタ状態管理部１３（１３ａ〜１３ｄ）は、クラスタ間情報照合部１６が照合した結果に基づいて仮想マシンの移行要求を指示する。 例えば、仮想マシン１１０ａ〜１１０ｄの仮想マシン位置情報の中に一致する情報が含まれている場合、仮想マシン位置情報が一致する仮想マシン１１０のいずれかを別のホストマシンへ移行させるため、仮想マシン移行要求を仮想マシン移行要求部１４へ指示する。

アプリケーション１１２ａおよび１１２ｂは、それぞれアプリケーション制御部１１ａ〜１１ｄによって、仮想マシン１１０ａ〜１１０ｂの間で切替え動作が可能である。

次に、図１７Ａ〜図１７Ｄ、図１３〜図１５を参照して、本実施の形態に係るクラスタシステムにおける障害発生時の動作について説明する。

図１７Ａ〜図１７Ｄでは、現在、アプリケーション１１２ａは仮想マシン１１０ａ上、アプリケーション１１２ｂは仮想マシン１１０ｂ上で稼動しており、アプリケーション１１２ａにおいては仮想マシン１１０ａが現用系、仮想マシン１１０ｂ〜１１０ｄが待機系となっており、アプリケーション１１２ｂにおいては仮想マシン１１０ｂが現用系、仮想マシン１１０ａ、１１０ｃ及び１１０ｄが待機系となっている。

また、仮想マシン１１０ｂ及び１１０ｃは同一ホストマシン１００ｂ上で稼動している状態である。 リソース監視部１２（１２ａ〜１２ｄ）は対象リソースに対して常時監視を実行しており、常に最新の実行状態がクラスタ状態管理部１３（１３ａ〜１３ｄ）に通知されている（図１３のＳ４０１）。 また、実施の形態１で示したように、各仮想マシンの稼動するホストマシン情報の照合結果も、常にクラスタ状態管理部１３（１３ａ〜１３ｄ）に通知されている。

この状態で、仮想マシン１１０ｂで障害が発生した場合、リソース監視部１２ｂが異常を検知し（図１３のＳ４０２）、異常を検知した旨をクラスタ状態管理部１３ｂに通知する（図１３のＳ４０３）。 異常検知情報を受信したクラスタ状態管理部１３ｂは（図１４のＳ５０１）、保持しているあらゆる情報(各仮想マシンのホストマシン名、アプリケーション稼動状態、リソース稼動状態、構築時の優先度設定など)を元に、仮想マシン１１０ａ、１１０ｃ及び１１０ｄの中から、最適となるフェイルオーバ先を自動で判断する（図１４のＳ５０３）。

図１７Ａ〜図１７Ｄの構成では、仮想マシン１１０ｃは仮想マシン１１０ｂと同一ホストマシン１００ｂ上で動作しており、仮想マシン１１０ａでは別のアプリケーション１１２ａが動作している。 このため、異なるホストマシン上で動作しており、かつ、他のアプリケーションでリソースを消費していない仮想マシン１１０ｄが最適なフェイルオーバ先と判断される。

そうすると、クラスタ状態管理部１３ｂ及び１３ｄはアプリケーション制御部１１ｂ及び１１ｄに対して、アプリケーション１１２ｂを仮想マシン１１０ｄへフェイルオーバするよう要求を送信する（図１３のＳ５０４）。 要求を受けたアプリケーション制御部１１ｂは（図１５のＳ６０１）、仮想マシン１１０ｂ上でアプリケーション１１２ｂを停止し（図１５のＳ６０２）、そのあとアプリケーション制御部１１ｄが仮想マシン１１０ｄ上でアプリケーション１１２ｂを起動し（図１５のＳ６０２）、フェイルオーバが完了する。

このように、さらに複数の仮想マシンによりＨＡクラスタを構成した場合でも、実施の形態１と同様の効果を得ることができる。 また、複数の待機系の仮想マシンを備えているため、障害発生時に、最適な仮想マシンにフェイルオーバすることができ、業務停止リスクをさらに抑止することができる。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

１１、１１ａ〜１１ｄ アプリケーション制御部１２、１２ａ〜１２ｄ リソース監視部１３、１３ａ〜１３ｄ クラスタ状態管理部１４、１４ａ〜１４ｄ 仮想マシン移行要求部１５、１５ａ〜１５ｄ 仮想マシン位置情報取得部１６、１６ａ〜１６ｄ クラスタ間情報照合部２１ 仮想マシン移行操作実行部２２ 仮想マシン移行要求受信部２３ 仮想マシン位置情報管理部１００、１００ａ〜１００ｃ ホストマシン１１０、１１０ａ〜１１０ｄ 仮想マシン１１１、１１１ａ〜１１１ｄ クラスタ制御ソフトウェア１１２、１１２ａ〜１１２ｂ アプリケーション２００ 仮想化基盤管理マシンＨＭ１〜ＨＭ４ ホストマシンＭ１ 仮想化基盤管理マシンＶＭ１〜ＶＭ８ 仮想マシン