JP4809209B2

JP4809209B2 - サーバ仮想化環境における系切り替え方法及び計算機システム

Info

Publication number: JP4809209B2
Application number: JP2006356576A
Authority: JP
Inventors: 恒彦馬場; 雄次對馬; 俊臣森木
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2006-12-28
Filing date: 2006-12-28
Publication date: 2011-11-09
Anticipated expiration: 2026-12-28
Also published as: US20080162983A1; US7617411B2; US20100017643A1; JP2008165637A; US8015431B2

Description

本発明は、本発明は、サーバ仮想化環境においてクラスタ構成を構築する高可用性のあるコンピュータシステムに関し、特に障害の監視と系切り替えとを行う機能を有するプログラムに関する。

サーバ仮想化は、単一の物理計算機上で複数のオペレーティングシステム（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ、以下ＯＳ）を同時に動作させる技術である。論理分割は、物理計算機の資源を複数の論理区画（ＬＰＡＲ）に分割する管理プログラム（サーバ仮想化プログラム）が介在して実現され、各ＬＰＡＲ上で一つずつのＯＳ（ゲストＯＳ）を動作させる。サーバ仮想化プログラムは、ハイパバイザや、物理計算機上でゲストＯＳとは異なるＯＳといったサーバ仮想化層（以下では、ホストＯＳと呼ぶ）で稼動するプログラムである。

このような論理分割を用いた物理計算機（サーバ仮想化環境）では、物理計算機の資源が複数ＬＰＡＲによって共有されるため、物理計算機の資源が障害になった場合に複数のＬＰＡＲに障害が発生する可能性がある。

従って、サーバ仮想化環境において、高可用性のあるコンピュータシステムを構築する場合には、障害発生時にゲストＯＳ上で動いていたアプリケーションプログラム（以下、ＡＰ）の別待機系ゲストＯＳへの引き継ぎ（系切り替え）を行うようなクラスタ構成のコンピュータシステムが用いられる。

非特許文献１では、サーバ仮想化環境におけるクラスタ構成方法として、各ＬＰＡＲ上のゲストＯＳ上に、クラスタプログラムを稼動させ、各ゲストＯＳ間でゲストＯＳとＡＰの障害の監視と、ＡＰの系切り替えが行う方法１と、ホストＯＳ上にクラスタプログラムを稼動させ、ホストＯＳ間でホストＯＳとゲストＯＳの障害監視と、ゲストＯＳの系切り替えを行う方法２とが実現されている。

上記方法１では、ゲストＯＳ間のクラスタプログラムが通信（ハートビート）によって、ゲストＯＳとＡＰの障害監視を行うことで、ＡＰの稼動している実行系の障害が発生した場合に待機系へと系切り替えを行う。この系切り替え方法では、事前に待機系となるゲストＯＳやＡＰの起動が行われているホットスタンバイが実現できる。

一方、上記方法２では、ホストＯＳ上のクラスタプログラムがハートビートによってホストＯＳとゲストＯＳの障害監視を行うことで、実行系の障害が発生した場合には、系切り替え先となる待機系を同一計算機または別計算機上にゲストＯＳのブートから行い、系切り替えを行う。この系切り替え方法では、ゲストＯＳの起動から行うコールドスタンバイが実現できる。
「CLUSTERPRO（登録商標）を利用したVMware（登録商標）Rサーバ統合ソリューション」、[online]、日本電気株式会社発行、[平成１８年1０月３１日検索]、インターネット＜ＵＲＬ：http://www.ace.comp.nec.co.jp/CLUSTERPRO/doc/pp_lin/CLUSTERPRO_VMware.pdf＞

上記非特許文献１の方法１では、各ゲストＯＳ上のクラスタプログラムがアプリケーションとゲストＯＳの障害監視を行うため、ゲストＯＳの数だけ障害監視の通信（ハートビート）が必要であり、ゲストＯＳ数を多くした場合には、複数のゲストＯＳが共有する通信資源、例えば、ＮＩＣ（ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＣａｒｄ）に高い負荷がかかることになる。従って、ハートビートの遅延が生じるという第１の課題がある。

加えて、各ゲストＯＳ上でクラスタプログラムが稼動している必要があるため、待機系となるゲストＯＳ上でのクラスタプログラムが障害監視処理以外ではアイドル状態となり、計算機資源の利用効率が下がり、実行系のパフォーマンスが低下する、という第２の課題がある。

一方、非特許文献１に示される方法２は、上記課題１及び課題２を解決することが可能であるが、新しいＬＰＡＲへのゲストＯＳ及びアプリケーションの割り当てとゲストＯＳのブートを伴うコールドスタンバイであり、ホットスタンバイによる系切り替え方法ではないため、系切り替えの時間がホットスタンバイに比べて増大するという第３の課題を有する。

また、上記方法１と方法２を組み合わせた場合、方法１と方法２が独立して系切り替え処理を行うため、それぞれ別のＬＰＡＲへの系切り替えが実施されることで、複数の実行系ＬＰＡＲが同時にアプリケーションを引き継ぐ可能性があり、このような系切り替えの競合が発生した場合には、複数の実行系によってデータ破壊が生じて、システム停止が生じる恐れがあるという第４の課題がある。

以上に示すように、ホットスタンバイを実現する系切り替え方法において、ゲストＯＳ数が増大した場合に計算機資源の消費量が増大し、ハートビートの遅延や実行系のパフォーマンス低下が生じるという課題がある。

そこで本発明は、上記問題点に鑑みてなされたもので、ゲストＯＳが多数存在する場合でも、サーバの計算機資源の消費を抑制しながら円滑な系切り替えを実現することを目的とする。

本発明は、少なくとも１つ以上の物理計算機で稼動する第１の仮想化部と第２の仮想化部と、前記第１の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第１の系と、前記第２の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第２の系と、前記第２の仮想化部で第1の系を切り替えた場合に新たに稼動することのできる第３の系と、を備え、前記各ゲストＯＳ上で稼動して当該ゲストＯＳ上のアプリケーションを監視し、障害発生時には前記アプリケーションを第１の系と第２の系の間で切り替える第１のクラスタ処理を実行する第１のクラスタ管理部と、前記各仮想化部上で稼動して、当該仮想化部上で稼動するゲストＯＳと他の仮想化部を監視し、障害発生時には前記ゲストＯＳ及びアプリケーションを第３の系へ移動し、前記ゲストＯＳ及びアプリケーションを起動することで第１の系と第３の系の間で切り替える第２のクラスタ処理を第２のクラスタ管理部が実行して、前記第１の系と第２の系または第３の系の間でゲストＯＳまたはアプリケーションを切り替えるクラスタシステムの系切り替え方法であって、前記第１のクラスタ処理が、当該第１のクラスタ処理を実行するゲストＯＳ上のアプリケーションの情報を取得するステップと、前記第１の系の第１のクラスタ処理が、前記取得したアプリケーションの情報を前記第２のクラスタ処理へ通知するステップと、前記第１の仮想化部の第２のクラスタ処理が、前記第１のクラスタ処理から前記アプリケーションの情報を取得するステップと、前記第１の仮想化部の第２のクラスタ処理が、前記各ゲストＯＳ上の第１のクラスタ処理からそれぞれ取得したアプリケーションの情報を集約するステップと、第１の仮想化部の前記第２のクラスタ処理が、前記集約したアプリケーションの情報を、一括して第２の仮想化部の第２のクラスタ処理へ通知するステップと、前記第２の仮想化部の第２のクラスタ処理が、前記アプリケーションの情報をハートビートとして取得し、当該アプリケーションに対応する第２の系のゲストＯＳ上の第１のクラスタ処理へ転送するステップと、前記第２の系の第１のクラスタ処理が、前記第２のクラスタ処理から転送された前記アプリケーションの情報に基づいて、前記第１の系のアプリケーションの障害を監視し、障害を検知したときには前記アプリケーションを第１の系から第２の系へ切り替えるステップと、を含む。

また、前記第１の仮想化部の第２のクラスタ処理が、前記集約したアプリケーションの情報を、一括して第２の仮想化部の第２のクラスタ処理へ通知するステップと、前記第１の仮想化部の第２のクラスタ処理が、第１の系のゲストＯＳの状態を取得するステップは、前記取得したゲストＯＳの状態と、前記取得したアプリケーションの障害状態とを一括して前記第２の仮想化部の第２のクラスタ処理へ通知するステップと、を含む。

また、前記第２の系の第１のクラスタ処理が、前記アプリケーションを起動して待機させるステップと、前記第２の系の第１のクラスタ処理が、前記アプリケーションを待機させたことを第２の仮想化部の第２のクラスタ処理へ通知するステップと、前記第２の仮想化部の第２のクラスタ処理が、前記通知に基づいて前記アプリケーションを待機させたゲストＯＳへのリソースの割当を低減して待機させるステップと、前記第２の仮想化部の第２のクラスタ処理が、前記第１の系のアプリケーションの障害の状態を取得したときには、前記待機させたゲストＯＳへのリソースの割当を増大させた後に、系切り替えを行う。

したがって、本発明は、サーバ仮想化環境におけるクラスタ構成において、ゲストＯＳ／ホストＯＳ（仮想化部）上に第１、第２のクラスタ管理部（スレーブクラスタプログラム、マスタクラスタプログラム）が稼動し、スレーブクラスタプログラムのハートビートをマスタクラスタプログラムが集約して送信することで、ゲストＯＳの数に依存することなく一定量のハートビートによる障害監視を実現する機能を提供することができる。

さらに、マスタクラスタプログラムが、スレーブクラスタプログラムの障害を監視することによって、ゲストＯＳが正常に稼動している場合には、待機系（第２の系）のスレーブクラスタプログラムへの通信を不要にすることで、ゲストＯＳの数に依存することなく、ハートビートを削減することができる機能を提供することができる。また、ゲストＯＳの数が増大しても系切り替えの際に競合が発生するのを防いで、円滑な系切り替えを実現できる。

加えて、マスタクラスタプログラムが、待機系のゲストＯＳに対する計算機資源の割り当てを停止しておき、実行系のゲストＯＳの障害が発生した場合に、系切り替え先となったゲストＯＳへの計算機資源の割り当てを再開することによって系切り替えを行う機能を提供することができる。

さらに、マスタクラスタプログラムが、待機系のゲストＯＳに対する計算機資源の割当量を削減しておき、実行系のゲストＯＳの障害が発生した場合に、計算機資源の割当量の削減を解除し、系切り替えを行う機能を提供することができる。

以上のようにサーバ仮想化環境におけるクラスタ構成において、ゲストＯＳ／ホストＯＳ上にスレーブ／マスタクラスタプログラムが稼動しているクラスタ構成において、ゲストＯＳの数が増大した場合であっても、ハートビートの監視を遅延させることなく、障害の監視が可能である系切り替え方法を提供することができる。

以下、本発明の実施の形態を添付図面に基づいて説明する
＜第１の実施の形態＞
本発明に関する図と説明は、本発明を鮮明に理解するのに適当な要素を示すために簡略化されており、発明を実施するのに支障ない範囲で既知の要素等は省略していることを理解されたい。本技術中で従来技術の中には、本発明を実装するために他の要素が望ましく、かつ／または、必要とされると思われるものが幾つかある。しかし、技術中のこれらの要素は既知であり、本発明の理解を容易にするものではないので、ここでは説明しない。
また、以下の説明では、各プログラムは実行系（または現用系）のモジュール番号で説明している場合もあるが、それらの説明は、待機系の対応したプログラムの説明も兼ねる場合もある。さらに、以降の図に示す符号において、他の図中の数字と同様の番号を用いているものがあるが、それらについては特に説明がない場合、他の図の説明と同様である。

図１から図９は本発明における第１の実施形態について表している。

図１は、第１の実施の形態のサーバ仮想化環境の物理計算機のハードウェア構成を表すブロック図である。

第１の実施の形態の物理計算機Ａは、ＣＰＵ１１と、メモリ１４と、ストレージ１５と、ＮＩＣ（ネットワークインターフェースカード）１６を備える。

ＣＰＵ１１は、メモリ１４に格納されたプログラムを実行することによって、各種処理を実行する。メモリ１４は及びストレージ１５は、ＣＰＵ１１によって実行されるプログラムおよび処理に必要なデータを格納する。ＮＩＣ１６は、ネットワーク（図中ＬＡＮ）を介して、他の計算機（例えば、物理計算機Ｂ）と通信する。なお、ＣＰＵ１１は複数のコア＃１、＃２を備え、複数の処理（例えば、複数のＯＳ）を並列的に実行可能である。

物理計算機Ｂも上記物理計算機Ａと同様に構成され、ＣＰＵ２１と、メモリ２４と、ストレージ２５と、ＮＩＣ２６を備え、ＣＰＵ２１は、メモリ２４に格納されたプログラムを実行することによって、各種処理を実行する。なお、ＣＰＵ２１も複数のコア＃１、＃２を備え、複数の処理を並列的に実行可能である。

本実施形態では、物理計算機Ａが実行系の計算機システムを構成し、物理計算機Ｂが待機系の計算機システムを構成する。

図２は、図１に示した物理計算機におけるサーバ仮想化環境のソフトウェアを主体とした機能ブロック図である。

実行系システムを構成する物理計算機Ａでは、ホストＯＳ＿Ａ（５３０）上に論理区画（以下、ＬＰＡＲ＝Logical PARtitionとする）を構成するサーバ仮想化プログラム５１０が稼動し、ＬＰＡＲ１とＬＰＡＲ２を提供する。また、前記サーバ仮想化プログラム５１０は、前記ＬＰＡＲ１とＬＰＡＲ２と異なる新たなＬＰＡＲ５を提供する。なお、ホストＯＳ５３０とサーバ仮想化プログラム５１０が仮想化部を構成する。ＬＰＡＲ１ではゲストＯＳ１（１３０）が実行され、このゲストＯＳ１上でアプリケーション（ＡＰ１）１１０が稼動し、また、アプリケーションＡＰ１を監視し、実行系と待機系の間で系切り替えを行うスレーブクラスタプログラム１２０（第１のクラスタ管理部）が稼動する。ＬＰＡＲ２ではゲストＯＳ２（２３０）が実行され、このゲストＯＳ２上でアプリケーション（ＡＰ２）２１０が稼動し、また、アプリケーションＡＰ２を監視するスレーブクラスタプログラム２２０が稼動する。ＬＰＡＲ５では、ゲストＯＳやアプリケーションは稼動しておらず、実行系上または待機系上の任意のＬＰＡＲを切り替えた場合に、前記切り替えたＬＰＡＲ上のゲストＯＳやアプリケーション、スレーブクラスタプログラムがＬＰＡＲ５で稼動する。ここで、ＬＰＡＲ５は事前に設定されたＬＰＡＲであってもよいし、前記切り替えが行なわれる場合に、前記サーバ仮想化プログラムが提供する新たなＬＰＡＲであってもよい。また、ホストＯＳ＿Ａ上では、各ＬＰＡＲ１、２のゲストＯＳまたは他の仮想化部を監視し、実行系または待機系のＬＰＡＲと前記新たなＬＰＡＲ５の間でゲストＯＳ及びアプリケーションを切り替え、前記ＬＰＡＲ５、ゲストＯＳとアプリケーションを起動することで、系切り替えを実行するマスタクラスタプログラム５２０（第２のクラスタ管理部）が稼動している。

一方、待機系システムを構成する物理計算機Ｂも、実行系システムの物理計算機Ａと同様の構成のソフトウェアが実行される。つまり、物理計算機Ｂでは、ホストＯＳ＿Ｂ（５３０’）上にＬＰＡＲ３、ＬＰＡＲ４を構成するサーバ仮想化プログラム５１０’が稼動する。また、前記サーバ仮想化プログラム５１０’は、前記ＬＰＡＲ３とＬＰＡＲ４と異なる新たなＬＰＡＲ６を提供する。ＬＰＡＲ３ではゲストＯＳ３（１３０’）が実行され、このゲストＯＳ３上では実行系から切り替えるためのアプリケーション（ＡＰ１）１１０’が稼動し、また、アプリケーションＡＰ１を監視し、実行系と待機系の間で系切り替えを行うスレーブクラスタプログラム１２０’が稼動する。ＬＰＡＲ４ではゲストＯＳ４（２３０’）が実行され、このゲストＯＳ４上で実行系から切り替えるためのアプリケーション（ＡＰ２）２１０’が稼動し、また、アプリケーションＡＰ２を監視するスレーブクラスタプログラム２２０’が稼動する。ＬＰＡＲ６では、ゲストＯＳやアプリケーションは稼動しておらず、実行系上または待機系上の任意のＬＰＡＲを切り替えた場合に、前記切り替えたＬＰＡＲ上のゲストＯＳやアプリケーション、スレーブクラスタプログラムが稼動する。また、ホストＯＳ＿Ｂ上では、各ＬＰＡＲ３、４のゲストＯＳまたは他の仮想化部を監視するマスタクラスタプログラム５２０’が稼動し、実行系または待機系のＬＰＡＲと前記新たなＬＰＡＲ６の間でゲストＯＳ及びアプリケーションを切り替え、ゲストＯＳとアプリケーションを起動することで、系切り替えを実行する。ここで、前記マスタプログラムによって行なわれるゲストＯＳ及びアプリケーションの切り替えは、例えば、ゲストＯＳやアプリケーションを起動するディスク装置を新たなＬＰＡＲが利用することで実現してもよいし、ゲストＯＳやアプリケーションの動作中のスナップショットを利用することで実現してもよい。なお、ＬＰＡＲ５、ＬＰＡＲ６は、コールドスタンバイとして機能する第３の系を構成する。

図３は、実行系の物理計算機Ａで実行されるソフトウェアの詳細な構成を示すブロック図である。上述のように複数の物理計算機Ａ、Ｂは、同様の構成となっているため、図３では、物理計算機Ａのソフトウェア構成のみを説明し、物理計算機Ｂのソフトウェア構成の説明は省略する。また、物理計算機Ａの複数のＬＰＡＲの構成も同様の構成となっているため、ＬＰＡＲ１のみ説明し、他のＬＰＡＲ２の詳細は省略して記載する。

物理計算機Ａは、ＬＰＡＲ１、２を管理するサーバ仮想化プログラム５１０が稼動する論理的なホストノード５００と、前記サーバ仮想化プログラム５１０によって管理されるＬＰＡＲ群１００（ＬＰＡＲ１）、２００（ＬＰＡＲ２）を含む。

ＬＰＡＲ１００は、ＯＳとしてゲストＯＳ１３０が稼動しており、そのゲストＯＳ上で、業務を行なうアプリケーションプログラム（ＡＰ１）１１０と、アプリケーション１１０の状態の監視と、実行系と待機系の間で系切り替えを行うスレーブクラスタプログラム１２０とを含む。

前記スレーブクラスタプログラム１２０は、アプリケーション１１０の状態を監視するアプリケーション監視部１２２と、前記アプリケーション監視部１２２で得られたアプリケーション状態をハートビートとして、ホストＯＳ５３０上の通信部５２１を介して待機系のスレーブクラスタプログラム１２０’に通知を行なう。また、スレーブクラスタプログラム１２０は、待機系のスレーブクラスタプログラム１２０’からの通知を受信するアプリケーション状態通知部１２１と、スレーブクラスタプログラム１２０が待機系として動作する場合に、実行系のアプリケーション１１０、２１０の状態をハートビートによって監視し、実行系のアプリケーションの障害発生時に系切り替えを実施する系切り替え制御部１２３とを有する。なお、アプリケーション１１０の稼動状態を示すハートビートとしては、アプリケーション１１０が実行中に発生する信号の他、アプリケーション１１０が生成したデータやファイルを含めることができ、これらの情報はアプリケーション１１０の稼動状態を示す稼動情報を構成する。そして、ハートビートの検出は、アプリケーション１１０の稼動情報を検知することで行うことができる。

ここで、前記系切り替え制御部１２３が系切り替えを実行する契機として、例えば、ハートビートに含まれるアプリケーションの状態が異常である場合、あるいは、クラスタプログラム１２０やゲストＯＳ１３０、あるいはホストノード５００の障害によってハートビートが途絶する場合などがある。また、前記通知部１２１によるアプリケーション状態の通知は、ホストＯＳ５３０上の通信部５２１を介さず、直接ＮＩＣ１６へアクセスすることで、行なわれても良い。

また、前記ゲストＯＳ１３０は、ホストＯＳ５３０上のクラスタプログラム（マスタクラスタプログラム）５２０に対して、ゲストＯＳ１３０の状態を教えるＯＳ状態通知部１３１を持つ。

次に、ホストノード５００は、ホストＯＳ５３０（ＯＳ＿Ａ）が稼動しており、そのホストＯＳ５３０上で、前記ＬＰＡＲ１、２を管理するサーバ仮想化プログラム５１０と、マスタクラスタプログラム５２０とを含む。

サーバ仮想化プログラム５１０は、前記ゲストＯＳ１３０に図１で示した物理的な計算機資源（ハードウェア）の割当を行うゲストＯＳ制御部５１１と、ゲストＯＳ１３０から得たゲストＯＳの稼動状態を管理するゲストＯＳ監視部５１２を有する。前記ゲストＯＳ監視部５１２は、図６に示すようなゲストＯＳ状態管理表５１３を有する。図６に示すゲストＯＳ状態管理表５１３は、サーバ仮想化プログラム５１０が管理するゲストＯＳ１３０、２３０の識別子３００１と、前記識別子を有するゲストＯＳの状態３００２と、ゲストＯＳ５３０状態の情報を更新した更新時刻３００３を含む。図６のゲストＯＳ状態管理表５１３は、実行系のサーバノード５００で稼動しているゲストＯＳ１、ゲストＯＳ２の状態を示し、ゲストＯＳ１（１３０）は時刻ｔ３の時点で状態が正常であることを示し、ゲストＯＳ２（２３０）は時刻ｔ４の時点で状態が正常であることを示す。

さらに、実行系のマスタクラスタプログラム５２０は他の物理計算機Ｂや、前記ホストＯＳ５３０上のスレーブクラスタプログラム１２０、２２０との通信を行うことのできる通信部５２１と、ホストＯＳ５３０の稼動状態を記録するホストＯＳ状態管理表５２５を有し、ホストＯＳ５３０の稼動状態を監視するホストＯＳ監視部５２４と、ホストＯＳ５３０やゲストＯＳ１３０、２３０の障害発生時に系切替先となるスレーブクラスタプログラム１２０、２２０に対して系切り替えを指示する系切り替え制御部５２２とを有する。

前記マスタクラスタプログラム５２０は、前記通信部５２１を通じて、待機系など他のマスタクラスタプログラム５２０’とハートビートによる監視を行うことで、他のホストＯＳやゲストＯＳの障害を監視することができる。

前記系切り替え制御部５２２は、前記ゲストＯＳ５３０上のスレーブクラスタプログラム１２０、２２０によって構成されるクラスタ構成を記録するゲストＯＳ系切り替え対応表５２３を有しており、前記ホストＯＳ５３０上のゲストＯＳ監視部５１２やホストＯＳ監視部５２４からゲストＯＳ１３０、２３０とホストＯＳ５３０の状態を得ることで、自計物理算機上のホストＯＳとゲストＯＳの障害を監視することができる。

前記ホストＯＳ状態管理表５２５は、図５に示されるように、ホストＯＳの識別子２００１と、ホストＯＳが管理するゲストＯＳの識別子群２００２と、そのホストＯＳの稼動状態２００３と、稼動状態の更新時刻２００４を有する。図示の例では、実行系のホストＯＳ＿Ａの状態が良好であり、実行系にはゲストＯＳ１、２が稼動していることを示し、また、待機系のホストＯＳ＿Ｂの状態が良好であり、待機系にはゲストＯＳ３、４が稼動していることを示している。

また、前記ゲストＯＳ系切り替え対応表５２３は、図４に示されるように、前記スレーブクラスタプログラム１２０、２２０によって構成されるゲストＯＳ間のクラスタ構成に基づいて、監視対象となるアプリケーションＡＰ１、ＡＰ２の識別子１００１、そのクラスタを構成するＯＳ群（ホストＯＳとゲストＯＳ）の識別子１０１０、１０２０とを有する。また、前記識別子１０１０、１０２０は、アプリケーション識別子１００１毎に、アプリケーションが稼動するホストＯＳ毎に設定され、アプリケーションが稼動するゲストＯＳの識別子１０１２、１０２２と、これらのゲストＯＳが稼動するＬＰＡＲを管理するホストＯＳの識別子１０１１、１０２１とを含む。図４の例では、実行系の計算機システムのホストＯＳ＿Ａと、待機系の計算機システムのホストＯＳ＿Ｂでクラスタを構成する例を示し、アプリケーションＡＰ１は、実行系システムのホストＯＳ＿ＡのゲストＯＳ１と、待機系システムのホストＯＳ＿ＢのゲストＯＳ３で系切替を行うクラスタを構成し、アプリケーションＡＰ２は、実行系システムのホストＯＳ＿ＡのゲストＯＳ２と、待機系システムのホストＯＳ＿ＢのゲストＯＳ４で系切替を行うクラスタを構成する例を示している。

図７〜図９は、第１の実施の形態の動作を表すフローチャートである。

以下、同様のフローチャートでは、図中の符号Ａ／Ｂ（１Ａ、３Ａ、３Ｂ）はそれぞれ、実行系及び待機系のマスタクラスタプログラム５２０、５２０’の動作を、Ｃ／Ｄ（２Ｃ、２Ｄ、３Ｄ）は実行系／待機系のスレーブクラスタプログラムの動作を、１Ｅは実行系のゲストＯＳの動作を表す。なお、各動作には、各クラスタプログラム外のモジュールと連携した動作を含む。

図７は、実行系のゲストＯＳ１３０、２３０の状態（ゲストＯＳ状態）を実行系のマスタクラスタプログラム５２０が検知する処理の一例を示すフローチャートである。なお、以下の説明では、実行系のゲストＯＳ１（１３０）についての処理を説明するが、他のゲストＯＳ２及び待機系の処理も同様である。

まず、実行系のゲストＯＳ１３０上のＯＳ状態通知部１３１は、ゲストＯＳ１の所定の監視時間が経過したかを判断し（Ｓ１８１）、経過していなければ再び判断を継続する。一方、所定の監視時間が経過している場合には、自ゲストＯＳ１３０の状態を取得し（Ｓ１８２）、ホストＯＳ５３０上のサーバ仮想化プログラム５１０のゲストＯＳ監視部５１２に対して、ゲストＯＳ１３０の状態を通知する（Ｓ１８３、通知Ｔ１１）。

次に、実行系のサーバ仮想化プログラム５１０では、前記ゲストＯＳ監視部５１２が、前記通知Ｔ１１を受信しているかを判断し（Ｓ１０１）、受信している場合には、受信した内容に従い、ゲストＯＳ状態管理表５１３を更新する（Ｓ１０２）。一方、前記通知Ｔ１１を受信していない場合には、ゲストＯＳ監視部５１２はゲストＯＳを障害と見なす一定の監視時間の間、ゲストＯＳ状態管理表５１３が更新されていないかを判断する（Ｓ１０３）。ゲストＯＳ状態管理表５１３が更新されていない場合は、ゲストＯＳ１３０が障害状態にあると判定し、前記処理Ｓ１０２でゲストＯＳ状態管理表５１３を更新する。一方、ゲストＯＳ状態管理表５１３が更新されている場合には、ゲストＯＳ監視部５１２は、上記処理Ｓ１０１に戻り、ゲストＯＳからのハートビートを待つ。

図８は、スレーブクラスタプログラム１２０、１２０’間のハートビートによる系切り替えを実施するフローチャートである。まず、実行系のスレーブクラスタプログラム１２０上のアプリケーション監視部１２２は、アプリケーションＡＰ１（１１０）の所定の監視時間が経過したかを判断し（Ｓ２４１）、経過していなければ再び判断を継続する。一方、所定の監視時間が経過している場合には、アプリケーション監視部１２２は、自ゲストＯＳ１３０上のアプリケーション１１０の状態を取得し（Ｓ２４２）、待機系ゲストＯＳ１３０’上のスレーブクラスタプログラム１２０’に対して、アプリケーション状態通知部１２１がアプリケーション状態を通知する（Ｓ２４３、通知Ｔ１２）。ここで、前記アプリケーション状態は、アプリケーションＡＰ１の稼動状態を表す以外の情報、例えば、アプリケーションＡＰ１の処理内容等を含んでも良い。なお、アプリケーション状態通知部１２１は、マスタクラスタプログラム５２０の通信部５２１を介して、待機系のスレーブクラスタプログラム１２０’に上記アプリケーション状態を通知Ｔ１２として送信する。

次に、待機系のスレーブクラスタプログラム１２０’では、アプリケーション状態通知部１２１が、前記実行系のアプリケーションＡＰ１の状態を示す通知Ｔ１２を受信しているかを判断する（Ｓ２６１）。前記通知Ｔ１２を受信している場合には、アプリケーション状態通知部１２１が、実行系のアプリケーションＡＰ１（１１０）の障害発生の通知かどうかを判断し（Ｓ２６２）。障害が発生している場合には、アプリケーションＡＰ１（１１０）の系切り替え処理を実施する（Ｓ２６３）。すなわち、待機系のスレーブクラスタプログラム１２０’が待機系のゲストＯＳ１３０’上のアプリケーション１１０’、（ＡＰ１）を機能させる。

一方、障害が発生していない場合には、待機系のスレーブクラスタプログラム１２０’は、上記Ｓ２６１へ戻って、再びアプリケーション状態の通知Ｔ１２を待つ。前記処理Ｓ２６１において、前記通知Ｔ１２を受信していない場合には、スレーブクラスタプログラム１２０’は、実行系のアプリケーション１１０（ＡＰ１）を障害と見なす一定の監視時間の間、通知Ｔ１２が更新されていないかを判断する（Ｓ２６４）。通知Ｔ１２が更新されていない場合は、実行系のゲストＯＳ１３０が障害状態にあるため、待機系のスレーブクラスタプログラム１２０’は系切り替えを実施する（Ｓ２６３）。待機系のスレーブクラスタプログラム１２０’は、系切り替え完了後に、実行系のスレーブクラスタプログラムとしての処理２Ｃを実行する。一方、通知Ｔ１２が更新されている場合には、処理Ｓ２６１に戻り、待機系のスレーブクラスタプログラム１２０’は実行系のアプリケーション状態の監視を行う。

図９は、マスタクラスタプログラム５２０、５２０’間のハートビートによるゲストＯＳの系切り替えを実施するフローチャートである。まず、実行系のマスタクラスタプログラム５２０は、図９の処理３Ａを実行し、自ホストＯＳ５３０の所定の監視間隔が経過したかどうかを判断し（Ｓ３０１）、経過していなければ判断を継続する。一方、所定の監視間隔が経過している場合には、ホストＯＳ状態管理表５２５の自ホストＯＳの状態と、ゲストＯＳ状態管理表５１３のゲストＯＳ状態を、マスタクラスタプログラム５２０が待機系のマスタクラスタプログラム５２０’へハートビートとして通信部５２１を介して送信する（処理Ｓ３０２、通知Ｔ１３）。この通知Ｔ１３は、ホストＯＳ５３０の状態とゲストＯＳ１３０、２３０の状態を集約したものである。

次に、待機系のマスタクラスタプログラム５２０’は、図９の処理３Ｂを実行し、ハートビートとしての前記通知Ｔ１３の受信の監視を行う（Ｓ３４１）。実行系のマスタクラスタプログラム５２０からハートビートを受信しなかった場合は、前回のハートビートによって通知された実行系のホストＯＳ５３０の更新時刻２００４を参照し、実行系のホストＯＳ５３０を障害と見なす一定の監視時間の間、前記通知Ｔ１３が無かったかどうかを判断し、通知Ｔ１３がなかった場合には、待機系のマスタクラスタプログラム５２０’は、実行系のホストＯＳ５３０が障害状態にあると判定し、Ｓ３４３の処理へ進む（Ｓ３４２）。なお、上記更新時刻２００４は、マスタクラスタプログラム５２０’のホストＯＳ状態管理表５２５から参照することができる。

実行系のホストＯＳ５３０の障害を検知したＳ３４３では、待機系のマスタクラスタプログラム５２０’が系切り替え対応表５２３を参照し、障害ホストＯＳ上のゲストＯＳを抽出する（Ｓ３４３）。

待機系のマスタクラスタプログラム５２０’は、前記処理Ｓ３４３で抽出されたゲストＯＳと、前記処理Ｓ３４２で通知がなかったホストＯＳとを障害状態と判定して、それぞれのゲストＯＳ状態管理表５１３とホストＯＳ状態管理表５２５を更新し（処理Ｓ３４４）、処理Ｓ３４７の処理へ進む。一方、前記連通Ｔ１３の通知があった場合には、処理Ｓ３４１に戻り、実行系のマスタクラスタプログラム５２０から実行系のホストＯＳ５３０のハートビートを待つ。

次に、前記処理Ｓ３４１で、待機系のマスタクラスタプログラム５２０’がハートビートを受信した場合には、受信した内容に従い、ホストＯＳ状態管理表５２５と、ゲストＯＳ状態管理表５１３を更新する（Ｓ３４５）。次に、前記管理表５１３を参照し、ゲストＯＳ障害が発生したかを判断し（Ｓ３４６）、障害が発生していなかった場合には、待機系のマスタクラスタプログラム５２０’は、再び処理Ｓ３４１に戻り、実行系のホストＯＳからのハートビートを待つ。

一方、実行系システムのホストＯＳに障害が発生していた場合には、処理Ｓ３４７を実行する。

処理Ｓ３４７では、ゲストＯＳ系切り替え対応表５２３を参照することで、前記処理Ｓ３４３や前記処理Ｓ３４６で抽出された障害となっているゲストＯＳが、自ホストＯＳ上に存在するかを判断する。障害が発生したゲストＯＳが自ホストＯＳ上に存在しない場合は、系切り替え処理は必要ないため、マスタクラスタプログラム５２０’は、再び処理Ｓ３４１に戻ってホストＯＳからのハートビートを待つ。

一方、障害が発生したゲストＯＳが自ホストＯＳ５３０’上に存在する場合は、スレーブクラスタプログラム１２０’、２２０’による系切り替えが必要となるため、抽出されたゲストＯＳに対して、マスタクラスタプログラム５２０’は系切り替えをスレーブクラスタプログラム１２０’、（２２０’）に指示する（Ｓ３４８、通知Ｔ１４）。通知Ｔ１４を送信するとマスタクラスタプログラム５２０’は、再び処理Ｓ３４１に戻り、実行系のホストＯＳ５３０のハートビートを待つ。ここで、前記処理Ｓ３４９及び、通知Ｔ１４は、明示的な系切り替えの指示ではなく、ゲストＯＳの障害の通知であっても良い。

一方、待機系のスレーブクラスタプログラム１２０’、（または２２０’）は、アプリケーション状態通知部１２１が前記通知Ｔ１４を受信すると（Ｓ３６１）、系切り替えが必要であるかどうかを判断する（Ｓ３６２）。ここで、系切り替えが必要であると判断された場合には、待機系のスレーブクラスタプログラム１２０’が系切り替え処理Ｓ３６３を実施する。つまり、実行系のゲストＯＳ１３０及びアプリケーション１１０を、待機系に切り替える。系切り替え完了後は、待機系のスレーブクラスタプログラム１２０’が実行系のスレーブクラスタプログラムとしての処理２Ｃ（図８）を実行する。一方で、系切り替えが必要でない場合には、待機系のスレーブクラスタプログラム１２０’は何も行わない。例えば、系切り替えが必要でない場合は、その障害をスレーブクラスタプログラム間のハートビートで事前に検知し、図８に示した系切り替え処理Ｓ２６３を実施済みである場合がある。

ここで、系切り替えが完了した場合には、検出された障害に対して系切り替えが実施された状態であるため、ゲストＯＳ１３０（２３０）、ホストＯＳ５３０の障害状態を変更してもよい。この場合、変更の契機は、スレーブクラスタプログラム１２０（２２０）によって系切り替えの完了をマスタクラスタプログラム５２０に通知する形であってもよいし、障害から回復したホストＯＳ、ゲストＯＳが正常状態であることを監視する形であってもよいし、加えて、マスタクラスタプログラム５２０の管理者が明示的に変更を指示する形であってもよい。

なお、上記Ｓ２６３、Ｓ３６３における系切り替え処理は、スレーブクラスタプログラム１２０（１２０’）が管理する系状態に基づいて系切り替えが実施される。

また、第１の実施形態においては、図４の系切り替え対応表５２３において、実行系と待機系のホストＯＳ／ゲストＯＳの対応関係を示す識別子としてアプリケーションの識別子を示したが、ユニークな数字を識別子として用いても良い。

また、実行系のゲストＯＳ１３０（または２３０）とアプリケーション１１０（または２１０）及びスレーブクラスタプログラム１２０（または２２０）を、待機系でコールドスタンバイとなっているＬＰＡＲ６へ切り替える場合では、上記図８と同様に処理を行うことができる。

例えば、図８の処理２Ｃを実行系のマスタクラスタプログラム５２０が実行し、同じく図８の処理２Ｄを待機系のマスタクラスタプログラム５２０’が実行すると見なし、図８のアプリケーション状態をゲストＯＳ状態あるいはホストＯＳ状態に置き換えることで、マスタクラスタプログラム５２０が実行系のゲストＯＳ１３０、２３０とホストＯＳ５３０の監視を行う。そして、実行系で障害が発生した時には、待機系のマスタクラスタプログラム５２０’が系切り替えを行なう（図８のＳ２６３）。この場合、図８のＳ２６３の系切り替え処理をコールドスタンバイの系切り替えに置き換えて、待機系のマスタクラスタプログラム５２０’が、実行系のゲストＯＳ１３０をＬＰＡＲ６で起動し、さらにアプリケーションＡＰ１とスレーブクラスタプログラム１２０を起動することで、実行系から待機系のＬＰＡＲ６へゲストＯＳを引き継ぐことが出来る。このようにコールドスタンバイの系であるＬＰＡＲ６への系切り替えを実行することができる。このとき、マスタクラスタプログラム５２０、５２０’は、上記と同様に各管理表を更新することができる。

以上、図３〜図９に示した一連の処理を行うことで、待機系のホストＯＳ５３０上のマスタクラスタプログラムによって実行系のホストＯＳ５３０の障害が検出された場合には、ゲストＯＳの系切り替えを行なうことができる。これにより、ホストＯＳ上とゲストＯＳ上にマスタ／スレーブクラスタプログラムを有しながら、一つの障害に対して、同時に異なる複数の系切り替えを実施することのないホットスタンバイによる系切り替え方法を実現することができ、前述の第３、第４の課題を解決することができる。これにより、ゲストＯＳが多数存在する場合でも、系切り替えの際に競合が発生するのを防いで、円滑な系切り替えを実現実現することが可能となる。

＜第２の実施の形態＞
図１０は、第２の実施形態を示すフローチャートで、前記第１の実施の形態の図９の一部を変更したものである。その他の構成は前記第１実施形態と同様である。

図１０では、実行系のマスタクラスタプログラム５２０は、図１０の処理４Ａを実行し、前記図９のＳ３０１、Ｓ３０２と同様に、図１０の処理Ｓ４０１、Ｓ４０２を実施し、ゲストＯＳ状態の通知Ｔ１３を送信する。

待機系のマスタクラスタプログラム５２０’は、図１０の処理３Ｂを実行し、前記処理Ｓ３４１と同様に、実行系のマスタクラスタプログラム５２０から前記通知Ｔ１３を受信した否かの判断を行なう（Ｓ４４１）。前記通知Ｔ１３を受信した場合には、受信した内容に従い、前記図９の処理Ｓ３４５と同様に、待機系のマスタクラスタプログラム５２０’は、各管理表５２５、５１３を更新し（Ｓ４４４）、再び処理Ｓ４４１に戻り、ホストＯＳからのハートビートを待つ。

一方、処理Ｓ４４１で実行系のマスタクラスタプログラム５２０からハートビートとしての通知Ｔ１３を受信しなかった場合には、待機系のマスタクラスタプログラム５２０’は前記図９の処理Ｓ３４２、処理Ｓ３４３と同様の処理Ｓ４４２、Ｓ４４３を実施する。処理Ｓ４４２において、通知Ｔ１３を受信できない期間が一定時間に満たない場合には、処理Ｓ４４１に戻り、ホストＯＳ５３０からのハートビートを待つ。一方、通知Ｔ１３が受信できない期間が一定時間を超える場合には、実行系のホストＯＳ５３０に障害が発生したと判定して前記図９のＳ３４３と同様に、障害が発生したホストＯＳ５３０上のゲストＯＳ１３０（２３０）を抽出する。処理Ｓ４４３終了後は、実行系のホストＯＳ５３０が障害状態にあるため、処理Ｓ３４４と同様に、抽出されたゲストＯＳと、通知がなかったホストＯＳとを障害状態として、それぞれの管理表５１３と５２５を更新する処理Ｓ４４４を実行する。

次に、待機系のスレーブクラスタプログラム１２０’、（２２０’）は、図１０の処理４Ｄを実行し、ゲストＯＳ（またはアプリケーション）の監視時間が経過したかを判断し（Ｓ４６１）、経過していなければ再び監視を継続する。一方、所定の監視時間を経過している場合には、系切り替え制御部１２３は、マスタクラスタプログラム上のゲストＯＳ状態管理表５１３を参照する（処理Ｓ４６２）。待機系のスレーブクラスタプログラム１２０’は、この処理Ｓ４６２で取得したゲストＯＳの状態から、実行系のスレーブクラスタプログラム１２０（２２０）が稼動するゲストＯＳに障害が発生したか否かを判断し（Ｓ４６３）、障害が発生していない場合には、再び処理Ｓ４６１に戻り、ゲストＯＳの監視を継続する。一方、実行系のゲストＯＳ１３０、２３０に障害が発生した場合には、前記図９の処理Ｓ３６３と同様に系切り替え処理Ｓ４６４を実施する。待機系のスレーブクラスタプログラム１２０’は、系切り替えを完了した後には、実行系のスレーブクラスタプログラムとしての処理２Ｃ（図８）を実施する。

以上、図１０のフローチャートを前記第１実施形態の図９と置き換えることにより、待機系のスレーブクラスタプログラム１２０’が、マスタクラスタプログラム５２０’のハートビートを介して、実行系のホストＯＳに障害が発生したときのゲストＯＳの障害を監視することが可能である。従って、障害が発生した場合にのみ、物理計算機間を跨ったハートビートを実施するだけで障害監視が可能である。これにより、前記第１の実施形態と同様に、ホストＯＳ上とゲストＯＳ上にマスタ／スレーブクラスタプログラムを有しながら、一つの障害に対して、同時に異なる複数の系切り替えを実施することのないホットスタンバイによる系切り替え方法を実現することができ、前述の第３、第４の課題を解決することができる。

また、第２の実施形態のように、ゲストＯＳの監視はホストＯＳが実行し、ゲストＯＳに障害が発生したときのみ、実行系のホストＯＳのハートビートに障害の発生したゲストＯＳの情報を待機系に通知することで、実行系と待機系が共に正常な場合では、ホストＯＳ間で通知するゲストＯＳまたはアプリケーションの情報を削減することができる。

また、障害が発生した場合にのみ、物理計算機間を跨ったハートビートを実施すれば良いので、ホットスタンバイを実現する系切り替え環境において、ゲストＯＳの数が増大した場合でも、ハートビートの遅延や実行系のパフォーマンスの低下を抑制することが可能となるのである。

＜第３の実施の形態＞
図１１から図１５は、第３の実施の形態を示す。図１１は、本発明の第３の実施形態を表した物理計算機Ａの機能ブロック図である。

図１１では、前記第１実施形態の図３に加えて、前記マスタクラスタプログラム５２０は、スレーブクラスタプログラム１２０からアプリケーション状態を取得し、アプリケーション状態を監視するアプリケーション状態管理部５２６を有する。なお、待機系も実行系と同様に構成されるので待機系の図示は省略する。

前記アプリケーション状態管理部５２６は、図１２に示すようなアプリケーション状態管理表５２７を有する。前記アプリケーション状態管理表５２７は、図１２において、スレーブクラスタプログラム１２０が監視対象としているアプリケーションの識別子４００１と、アプリケーション識別子４００１のクラスタにおける役割として、実行系か待機系なのかを示す系状態４００２と、どのホストＯＳとゲストＯＳで動作しているかを表す識別子４００３、４００４と、アプリケーションの稼動状態を示す稼動状態４００５と、さらに前記アプリケーション稼動状態が更新された時刻４００６を有する。

系状態４００２は、アプリケーションの識別子４００１毎に、実行系（ＯＮＬ）と待機系（ＳＢＹ）が設定される。アプリケーションの稼動状態４００５は、稼動状態が良好であれば「ＯＫ」が設定され、障害発生時などでは「ＮＧ」が設定される。

ここで、系状態４００２では、待機系（ＳＢＹ）の場合、どの待機系に優先的に系切り替えするかを示す情報を含んでもよい。

ホストＯＳ５３０上のマスタクラスタプログラム５２０の系切り替え制御部５２２は、前記アプリケーション状態管理表５２７を参照し、定期的にマスタクラスタプログラム５２０、５２０’間でのハートビートを行う。

図１３は、スレーブクラスタプログラム１２０がアプリケーション状態を監視し、ハートビートとしてマスタクラスタプログラム５２０に通知する処理を表したフローチャートである。

図１３において、スレーブクラスタプログラム１２０は、図１３の処理５Ｃを実行し、一定の監視時間毎にアプリケーションを監視するため、一定時間が経過したかを判断する（Ｓ２４１）。一定の監視時間が経過していない場合には、監視時間が経過するまで待つため、処理Ｓ２４１に戻る。一方、一定の監視時間が経過している場合には、スレーブクラスタプログラム１２０がアプリケーション監視部１２２を通じてアプリケーション状態を取得し（Ｓ２４２）、アプリケーション状態通知部１２１がアプリケーション状態をハートビートとしてマスタクラスタプログラム５２０のアプリケーション状態管理部５２６へ送信する（Ｓ５４３、通知Ｔ２２）。

一方、マスタクラスタプログラム５２０は、図１３の処理５Ａを実行し、前記アプリケーション状態管理部５２６が前記の通知Ｔ２２によってアプリケーション状態を通知されたかどうかを判断し（Ｓ５０１）、通知された場合には、アプリケーション状態管理表５２７に通知されたアプリケーション状態を記録し、更新を行う（Ｓ５０２）。

次に図１４は、図１３で通知されたスレーブクラスタプログラム１２０のハートビートをホストＯＳ５３０のマスタクラスタプログラム５２０のハートビートと一括して待機系へ送信する処理と、スレーブクラスタプログラム１２０’がハートビートを受信し、障害発生時には系切り替えを行う処理を表したフローチャートである。

図１４では、前記第１実施形態の図１０と同様に、実行系のマスタクラスタプログラム５２０は、図中処理６Ａを実行し、一定監視時間毎にホストＯＳ５３０の監視用のハートビートを送信するために、まずホストＯＳ５３０の監視時間が経過したかを判断する（Ｓ６０１）。監視時間が経過していない場合には、この監視時間が経過するまで待つため、処理Ｓ６０１に戻る。一方、監視時間を経過している場合には、前記Ｓ５０２で更新されたアプリケーション状態管理表５２７を、ゲストＯＳ状態管理表５１３とホストＯＳ状態管理表５２５から得られるホストＯＳ状態とゲストＯＳ状態を、実行系のホストＯＳのハートビートとして、待機系のマスタクラスタプログラム５２０’に対して一括して送信する（Ｓ６０２、通知Ｔ２３）。

前記通知Ｔ２３は、図１５に示すように、送信元のホストＯＳ５３０の情報（識別子５００１、ホストＯＳ状態５００２、ホストＯＳ状態の更新時刻５００３）を含む。さらに、前記通知Ｔ２３は、前記ホストＯＳ５３０の情報と同様に、ゲストＯＳ１３０（ＯＳ１）、２３０（ＯＳ２）の情報５１０１〜５１０３、５２０１〜５２０３と、前記ゲストＯＳ１３０、２３０上のアプリケーション１１０（ＡＰ１）、２１０（ＡＰ２）の情報５１１１〜５１１３、５２１１〜５２１３を含む。

つまり、マスタクラスタプログラム５２０は、ホストＯＳ５３０の状態と、ゲストＯＳ１３０、２３０の状態及びアプリケーション１１０、２１０の状態を一纏めにして待機系のクラスタプログラム５２０’へ送信する。

一方、待機系のマスタクラスタプログラム５２０’は、図１４の処理６Ｂを実行し、前記第１実施形態の図９に示した処理Ｓ３４１〜Ｓ３４８と同様の処理Ｓ６４１〜Ｓ６４８を実施する。

前記第１実施形態の図９と本第３実施形態に示す図１４の処理の相違点を以下に述べる。

まず、処理Ｓ６４３は、実行系のホストＯＳ５３０に障害が発生している状態の場合、待機系のマスタクラスタプログラム５２０’の系切り替え制御部１２３は、系切り替え対応表５２３を参照し、障害が発生した前記ホストＯＳ上で稼動するゲストＯＳ及びアプリケーションを抽出する。続く処理Ｓ６４４では、前記ホストＯＳ及び、抽出した前記ゲストＯＳ及びアプリケーションの状態を障害状態として、ホストＯＳ状態管理表５２５、ゲストＯＳ状態管理表５１３、アプリケーション状態管理表５２７を更新する。また、処理Ｓ６４５における管理表５２５、５１３、５２７の更新処理は、前記処理Ｓ６４４と同様に、マスタクラスタプログラム５２０’が前記各管理表５２５、５１３、５２７を更新する。続く処理Ｓ６４６では、処理Ｓ３４６のゲストＯＳの障害の判定に加えて、前記表５２７を参照してアプリケーションの障害を実施し、マスタクラスタプログラム５２０’はどちらか一方が障害であるかを判断する。処理Ｓ６４７では、障害が発生しているゲストＯＳ又はアプリケーションの系切り替え先となるゲストＯＳが自ホストＯＳ５３０’上にあるかを、前記処理Ｓ３４７と同様に判定する。つまり、系切り替え対応表５２３を参照し、系切り替え先のゲストＯＳの有無をマスタクラスタプログラム５２０’が判定する。最後に、マスタクラスタプログラム５２０’は、処理Ｓ６４８では、前記処理３４８と同様に、前記処理Ｓ６４７で抽出されたゲストＯＳに対して、アプリケーション状態が障害であることを、待機系のスレーブクラスタプログラムに通知する（通知Ｔ２４）。

待機系スレーブクラスタプログラム１２０’、（２２０’）は、図１４の処理６Ｄを実行し、前記第１実施形態の図８に示した処理Ｓ２６１〜Ｓ２６４と同様の処理Ｓ６６１〜Ｓ６６４を実施する。これにより、スレーブクラスタプログラム１２０’は、前記第１実施形態の図８に示した処理Ｓ２６１〜Ｓ２６４で、スレーブクラスタプログラム１２０、１２０’同士でハートビートを実施していた場合と同様に、ハートビートを実施することが可能となる。さらに、前記通知Ｔ２４において、通知先である待機系のマスタクラスタプログラム５２０’が、ゲストＯＳのハートビートの送信元である実行系のスレーブクラスタプログラム１２０を装って、通知Ｔ２４を待機系のスレーブクラスタプログラム１２０’に通信することで、待機系のスレーブクラスタプログラム１２０’は、マスタクラスタプログラム５２０’が存在することによる新たな設定を不要とした状態で、ハートビートを受信することが可能となる。

また、前記通知Ｔ２４は、アプリケーションの障害ではなく、前記Ｔ１４と同様にゲストＯＳの障害通知や、明示的に系切り替えを指示する通知であっても良い。この場合、前記図９における処理と同様に、スレーブクラスタプログラム１２０がマスタクラスタプログラム５２０からの明示的な通知によって系切り替えを実施する処理を行なうことで系切り替えを実現することができる。

ここで、第３の実施形態において、系切り替えが完了した場合には、ゲストＯＳ１３０（２３０）上のアプリケーションの系状態が変更される。従って、前記の系切り替え処理において、系切り替えが完了した場合に、アプリケーション状態管理表５２７の系状態４００２を変更する。系状態の変更の契機は、スレーブクラスタプログラム１２０によって系切り替えが完了したときや、スレーブクラスタプログラム１２０が系状態の変更をマスタクラスタプログラム５２０に通知する形であってもよい。あるいは、マスタクラスタプログラム５２０の管理者が明示的に変更を指示する形であってもよい。また、加えて、前記第１の実施形態に記載された、系切り替え後のゲストＯＳ、ホストＯＳの状態の削除又は変更も実施されてもよく、この場合、前記系状態の変更と、ゲストＯＳ・ホストＯＳ状態の変更は、矛盾しない状態で行なわれる。

以上、図１０〜図１５に示した一連の処理を行うことで、ゲストＯＳ１３０、２３０上のスレーブクラスタプログラム１２０、２２０が行うハートビートを、実行系のホストＯＳ５３０上のマスタクラスタプログラム５２０が集約して一括して待機系のマスタクラスタプログラム５２０’へ送信することが可能になる。加えて、マスタクラスタプログラム５２０によって集約されたハートビートを利用した場合も、スレーブクラスタプログラム１２０、２２０に新たな設定を行なうことなく、ハートビートを実現する効果も有する。従って、スレーブクラスタプログラム１２０、１２０’間のハートビートによる障害監視をゲストＯＳの数に依存することなく実現でき、ホットスタンバイを実現する系切り替え方法を実現することができ、前記第１の課題を解決することができる。

＜第４の実施の形態＞
図１６は第４の実施形態を示し、前記第３の実施形態の図１４の一部を変更したものである。その他の構成は前記第３実施形態と同様である。

図１６は、スレーブクラスタプログラム１２０（１２０’）がマスタクラスタプログラム５２０（５２０’）からアプリケーションの状態を取得し、アプリケーションの障害時には系切り替えを行う処理を表したフローチャートである。

図１６において、処理Ｓ７０１、７０２、Ｓ７４１〜７４４、及び、Ｓ７６１〜Ｓ７６４は、それぞれ、前記第３実施形態のＳ４０１、４０２、Ｓ４４１〜Ｓ４４４、及び、Ｓ４６１〜Ｓ４６４と同様の処理を行なう。なお、図１６の処理７Ａは、前記第３実施形態の図１４に示した処理６Ａと同様であり、同じく処理７Ｂは前記第３実施形態の処理６ＢのうちＳ６４６〜Ｓ６４８、Ｓ６４４を削除したものと同様である。前記第３実施形態との相違点を以下に述べる。

第４実施形態では、まず、処理７Ｂの処理Ｓ７４３、Ｓ７４４において、待機系のマスタクラスタプログラム５２０’は、ホストＯＳの障害が発生している状態では、処理Ｓ６４３、Ｓ６４４と同様に、障害となった実行系のホストＯＳ５３０上で稼動するゲストＯＳ１３０、２３０と、アプリケーション１１０、２１０を抽出し、アプリケーションの障害状態として、ホストＯＳ状態管理表５２５、ゲストＯＳ状態管理表５１３、アプリケーション状態管理表５２７を更新する。

また、待機系のスレーブクラスタプログラム１２０’は、処理Ｓ７６２において、上記処理Ｓ４６２のゲストＯＳ状態対応表５２３に加えて、アプリケーション状態管理表５２７を参照し、ゲストＯＳ１３０’、２３０’の状態とアプリケーション状態を取得する。さらに、続く処理Ｓ７６３では、取得した前記ゲストＯＳ／アプリケーション状態から、実行系のスレーブクラスタプログラム１２０、２２０が稼動するゲストＯＳ１３０、２３０と、監視対象のアプリケーションに障害が発生したか否かを判断する。

以上、前記第３実施形態の図１４を上記図１６に置き換えることにより、ゲストＯＳ１３０、２３０上のスレーブクラスタプログラム１２０、２２０が行うハートビートを、ホストＯＳ５３０上のマスタクラスタプログラム５２０、が集約して一括して待機系のマスタクラスタプログラム５２０’へ送信することが可能になる。従って、スレーブクラスタプログラム間のハートビートによる障害監視をゲストＯＳの数に依存することなく実現でき、ホットスタンバイを実現する系切り替え方法を実現することができ、前記第１の課題を解決することができる。

＜第５の実施の形態＞
図１７〜図１９は、第５の実施の形態を示し、前記第３の実施形態の図１１、図１４、図１５に代わって実行する処理である。

まず、図１７は第５の実施の形態における機能ブロック図である。

図１７は、前記第３実施形態の図１１と異なり、スレーブクラスタプログラム１２０（２２０）は、スレーブクラスタプログラム間のハートビートからアプリケーションの障害を判断し、系切り替えを行う系切り替え制御部１２３に代わり、系切り替えの実行のみを行う系切り替え実行部１２４を有する。一方で、アプリケーションの障害を判断し、前記系切り替え実行部１２４へ系切り替え指示を行う役割は、マスタクラスタプログラム５２０、５２０’における系切り替え制御部５２２が含む。

図１８は、マスタクラスタプログラム５２０、５２０’が実行するアプリケーション状態の監視と、ハートビートの送受信処理、さらに、障害発生時の系切り替え制御を行うフローチャートである。なお、実行系の処理と、待機系の処理は同様である。

図１８において、マスタクラスタプログラム５２０は、処理８Ａを実行し、まず図９のＳ３０１と同様に、一定監視時間毎にハートビートを待機系のマスタクラスタプログラム５２０’へ送信するために、ホストＯＳ５３０の所定の監視時間が経過したかを判断し（Ｓ８０１）、経過していない場合には、上記監視時間が経過するまで待つため、処理Ｓ８０１に戻る。一方、所定の監視時間が経過している場合には、前記第１実施形態の処理Ｓ１０２、前記第３実施形態のＳ５０２と同様に更新された各管理表５１３、５２７を参照し（Ｓ８０２）、ゲストＯＳ／アプリケーションに障害があるかどうかを判断する（Ｓ８０３）。

前記処理Ｓ８０３において、障害が発生していない場合は、待機系での系切り替えが不要であるため、マスタクラスタプログラム５２０はゲストＯＳ状態／アプリケーション状態を送信せず、ホストＯＳ５３０の状態のみをハートビートの情報とする（Ｓ８０５）。

一方、ゲストＯＳ１３０、２３０またはアプリケーション１１０、２１０に障害がある場合には、系切り替えを実施するために、ホストＯＳ状態に加えて、ゲストＯＳやアプリケーションの状態もハートビートの情報とする（Ｓ８０４）。処理Ｓ８０６では、処理Ｓ８０４、Ｓ８０５で指定された情報を一纏めのハートビートとして、待機系のクラスタプログラム５２０’へ送信する（Ｓ８０６、通知Ｔ３３）。ここで、通知Ｔ３３は、図１９に示すような情報を含む。

図１９において、通知Ｔ３３は、ホストＯＳの識別子６００１と、ホストＯＳ５３０の状態（実行系（ＯＮＬ）と待機系（ＳＢＹ））６００２と、ホストＯＳ５３０の状態を更新した時刻６００３からなるホストＯＳの情報と、障害は発生したゲストＯＳの識別子６１０１と、ゲストＯＳの状態を更新した時刻６１０３とからなる障害ゲストＯＳ情報と、障害が発生したアプリケーション１１０、２１０の識別子６１１１と、当該アプリケーションの稼動情報６１１２（ＳｔａｔｕｓＮＧまたはＯＫ）と、アプリケーションの稼動情報を更新した時刻６１１３とからなる障害アプリケーション情報とから構成される。

通知Ｔ３３を構成するこれらの情報６００１〜６１１３は、前記第３実施形態の図１５に示した情報５００１〜５００３、５１０１、５１０３、５１１１〜５１１３に対応する。前記通知Ｔ３３は、マスタクラスタプログラム５２０が前記処理Ｓ８０４を実施した場合（ゲストＯＳまたはアプリケーションに障害がある場合）は、前記情報６００１〜６１１３を含む情報を一纏めのハートビートとする。一方、マスタクラスタプログラム５２０は、前記処理Ｓ８０４を実施しない場合（ゲストＯＳまたはアプリケーションに障害が無い場合）には、前記６００１〜６００３だけがハートビートとして送信される。また、前記アプリケーション稼動情報６１１２がアプリケーションの障害の有無のみを通知する場合は、前記障害アプリケーション識別子６１１１で通知される情報に含まれるため、前記情報６１１２は前記通知Ｔ３３で送信しなくても良い。

次に、前記通知Ｔ３３を受信する待機系のマスタクラスタプログラム５２０’は処理８Ｂを実行し、処理８Ｂで実施される処理Ｓ８４１〜Ｓ８４８は、それぞれ、前記第３実施形態の図１４に示した処理Ｓ６４１〜６４８と同様の処理を行なう。

前記第３実施形態の図１４と本第５実施形態の図１８の相違点を以下に述べる。まず、処理Ｓ８４５は、実行系のホストＯＳ５３０が正常な状態のときに実行される。従って、実行系のゲストＯＳ／アプリケーション状態が正常な状態であるため、前記処理Ｓ８４５では、前記通知Ｔ３３に含まれるホストＯＳ３５０の状態以外に、前記ホストＯＳ３５０上のゲストＯＳ１３０、２３０の状態と、各ゲストＯＳ上で稼動するアプリケーション１１０、２１０の状態も正常な状態として、ホストＯＳ状態管理表５２５、ゲストＯＳ状態管理表５１３、アプリケーション状態管理表５２７を更新する。

また、処理Ｓ８４８は、前記処理Ｓ３４８、通知Ｔ１４と同様に、系切替を実施する場合であり、待機系のスレーブクラスタプログラム１２０’、２２０’に系切り替えを指示するように通知を行なう（通知Ｔ３４）。

さらに、前記通知Ｔ３４を受信する待機系のスレーブクラスタプログラム１２０’、２２０’で実施される処理３Ｄの処理Ｓ８６１、Ｓ８６３は、前記第１実施形態の図９に示した処理Ｓ３６１、Ｓ３６３と同様の処理を行なう。

以上、第５の実施形態では、実行系となるゲストＯＳ１３０、２３０とアプリケーションの障害を実行系のマスタクラスタプログラム５２０が監視することが可能であり、ゲストＯＳとアプリケーションが正常稼動中は、ホストＯＳ間のハートビートは、ホストＯＳ５３０の状態のみを送信し、ゲストＯＳとアプリケーションに障害が発生した場合にのみ、ゲストＯＳ／アプリケーションの状態を通知するだけで系切り替えが実現可能である。従って、スレーブクラスタプログラム間のハートビートによる障害監視を、障害発生時以外は不要とすることで、ゲストＯＳの数に依存しないハートビート量の削減を実現し、ホットスタンバイを実現する系切り替え方法を実現することができる。

＜第６の実施の形態＞
図２０から図２３は、第６の実施形態を示し、ゲストＯＳを実行するＣＰＵの割り当てを管理するＣＰＵスケジューラ部５１４とＣＰＵ割付表５１５を設け、前記第５の実施形態の図１８に示す処理を図２３に置き換えたものである。

まず、図２０は第６の実施の形態における実行系の物理計算機Ａの機能ブロック図である。なお、待機系の物理計算機Ｂも、図２０と同様に構成されるので図示は省略する。

図２０において、物理計算機Ａは、前記第５実施形態に示した図１７に加えて、前記サーバ仮想化プログラム５１０は、各ゲストＯＳにＣＰＵを割り当てるＣＰＵスケジューラ部５１４と、その割付状態を管理するＣＰＵ割付表５１５を有する。

前記ＣＰＵ割付表５１５は、図２１に示すように、ＣＰＵの割当対象となるゲストＯＳの識別子７００１と、割り付けを停止するかどうかの割付凍結フラグ７００２とを含む。前記フラグ７００２が「凍結中」に設定されている場合は、前記ＣＰＵスケジューラ部５１４は、そのゲストＯＳへのＣＰＵの割当を行わないため、ゲストＯＳが凍結（一時停止）した状態となる。一方、割当凍結フラグが「稼働中」であれば、サーバ仮想化プログラム５１０は、ゲストＯＳ識別子７００１のゲストＯＳにＣＰＵを割り当てて実行させる。

図２２は、第６の実施の形態における待機系のゲストＯＳ１３０’、２３０’の凍結を行う処理を表すフローチャートである。

まず、待機系のスレーブクラスタプログラム１２０’、（２２０’）は、アプリケーションをホットスタンバイによる系切り替えが実現できるホットスタンバイ状態にする（Ｓ９６１）。アプリケーションがホットスタンバイ状態になったら（Ｓ９６２）、アプリケーションのホットスタンバイ化が完了したことを待機系のマスタクラスタプログラム５２０’に通知する（Ｓ９６３、通知Ｔ４１）。

一方、待機系のマスタクラスタプログラム５２０’は、前記通知Ｔ４１を受け取ると、通知してきた待機系のゲストＯＳに対して、前記ＣＰＵ割付表５１５の割付凍結フラグを「凍結中」に設定することにより、ＣＰＵ割当の停止を行う（Ｓ９２２）。これにより、待機系のゲストＯＳは常にＣＰＵ割当が０％（凍結）となる（Ｓ９６４、凍結処理Ｔ４２）。凍結後は、待機系のマスタ／スレーブクラスタプログラムは、凍結解除による系切り替え処理である処理（１０Ｂ、１０Ｄ以降）をそれぞれ行なう。なお、ゲストＯＳが凍結中となるため、ゲストＯＳ上のクラスタプログラム１２０’、（２２０’）も凍結される。

次に、図２３は、第６の実施形態における待機系のゲストＯＳへの系切り替えを行う処理を表すフローチャートである。

処理１０Ｂのうち処理Ｓ１０４１〜Ｓ１０４７は、前記第５実施形態の図１８に示した処理８４１〜Ｓ８４７と同様の処理を行なう。そして、処理Ｓ１０４８では、ホストＯＳ／ゲストＯＳ／アプリケーションのいずれかに障害が発生した状態であり、系切り替えが必要となるため、前記ＣＰＵ割付表５１５の割付凍結フラグを解除（稼働中に更新）することで、系切り替え先となる待機系のゲストＯＳの凍結の解除を行う。これにより、待機系のゲストＯＳは再び、稼動を開始し（凍結解除処理Ｔ４３）、スレーブクラスタプログラム１２０’、（２２０’）は再び待機系として再稼動する（Ｓ１０６１）。スレーブクラスタプログラム１２０’、（２２０’）の再稼動は、実行系に障害があったことを示すため、スレーブクラスタプログラムは、系切り替えを実行する（Ｓ１０６２）。

以上の図２０〜図２３によって、第６の実施形態によれば、自計算機上で稼動する待機系のゲストＯＳが従来使用していたＣＰＵをはじめとする計算機資源やホストＯＳ５３０’の資源の消費を停止させることができるとともに、実行系に障害が発生した場合には、待機系ゲストＯＳを再稼動させることで系切り替えを実現することができる。従って、実行系が正常な場合は、待機系への計算機資源を停止することで、待機系のゲストＯＳの数が増えても、パフォーマンスの低下を生じないホットスタンバイによる系切り替え方法を実現することができ、前記第２、第３の課題を解決することができる。また、待機系の消費電力の低減と発熱の抑制を実現し、運用コストの削減を図ることができる。

＜第７の実施の形態＞
図２４から図２８は、第７の実施形態を示し、前記第６実施形態のゲストＯＳを実行するＣＰＵの割り当てを管理するＣＰＵスケジューラ部５１４とＣＰＵ割付表５１６を、前記第１の実施形態に適用し、さらに前記第１実施形態の図９に示す処理を図２７に置き換えたものである。

まず、図２４は第７の実施の形態における実行系の物理計算機Ａの機能ブロック図である。なお、待機系の物理計算機Ｂも、図２４と同様に構成されるので図示は省略する。

図２４において、物理計算機Ａは、前記第６実施形態に示した図２０と同様に、前記サーバ仮想化プログラム５１０は、ＣＰＵスケジューラ部５１４と、その割付状態を管理するＣＰＵ割付表５１６を有する。前記ＣＰＵ割付表５１６は、図２５に示すように、ＣＰＵの割当対象となるゲストＯＳの識別子８００１と、割当量を削減するかどうかのフラグ（割当制限フラグ）８００２とを含む。前記フラグ８００２が設定されている場合（割当制限）、ＣＰＵスケジューラ部５１４は、ゲストＯＳへのＣＰＵ割当を減少させる。ここで、ＣＰＵ割当の減少方法は、一定の割合で割当を行なわない方法であっても良いし、対象となるゲストＯＳの負荷量に応じて、例えば負荷量が少ない場合に割当を一定の割合で行なわない方法であってもよい。さらに、ＣＰＵの動作モードを切り替えて、例えば省電力モードに切り替える方法であっても良い。

図２６は、第７の実施の形態における待機系のゲストＯＳ１３０’、２３０’へのＣＰＵ割当量の制限を行う処理を表すフローチャートである。

ここで、図２６におけるＳ１１６１〜Ｓ１１６３、Ｓ１１２１は、前記第６実施形態の図２２に示した処理Ｓ９６１〜９６３、Ｓ９２１と同様の処理を行なう。処理Ｓ１１２１において、待機系のマスタクラスタプログラム５２０’は、前記通知Ｔ４１を受け取ると、通知してきた待機系のゲストＯＳ１３０’、２３０’に対して、前記ＣＰＵ割付表５１６の割当削減フラグを「割当制限」に設定し、ＣＰＵ割当量の低減を行い（Ｓ１１２２）、待機系のゲストＯＳはＣＰＵ割当量が制限される（Ｓ１１６４、割当量制限処理Ｔ５２）。これにより、待機系のスレーブクラスタプログラム１２０’、２２０’は、稼動率が低下するが、前記第１の実施形態同様に、スレーブクラスタプログラム間でのハートビートの監視は実施されるため、処理Ｓ１１６４終了後、障害監視処理（２Ｄ）以降の処理を行なう。一方、待機系のマスタクラスタプログラム５２０’は、後述する処理１２Ｂ以降を実施する。

次に、図２７は、本第７実施形態において、待機系のマスタクラスタプログラム５２０’が実行系の障害を検出した場合における待機系のゲストＯＳ１３０’、２３０’への系切り替えを行う処理を表すフローチャートである。

図２７において、Ｓ１２４１〜Ｓ１２４７は、前記第６実施形態の図２３に示した処理Ｓ１０４１〜Ｓ１０４７と同様の処理を行なう。処理Ｓ１２４８では、ホストＯＳ／ゲストＯＳ／アプリケーションのいずれかに障害が発生した状態であり、系切り替えが必要となるため、待機系のマスタクラスタプログラム５２０’は、前記ＣＰＵ割付表５１６の割付量制限フラグを解除することで、待機系のゲストＯＳ１３０’、２３０’の割当量制限の解除を行う（Ｓ１２４８、割当量制限解除処理Ｔ５２）。これにより、待機系のゲストＯＳ１３０’、２３０’は再び、前記割当量制限処理Ｓ１１６４以前の状態で稼動を再開する（Ｓ１２６１）。処理Ｓ１２４８に続いて、マスタクラスタプログラム５２０’は、スレーブクラスタプログラムに１２０’（２２０’）に対して系切り替えを指示し（Ｓ１２４９、通知Ｔ５３）、スレーブクラスタプログラム１２０’は、処理Ｓ１２６２でマスタクラスタプログラム５２０’から前記通知Ｔ５３を受信すると、系切り替えを実行する（Ｓ１２６３）。

このようにして、待機系のＣＰＵ割当量が制限された状態において、マスタクラスタプログラム５２０’が障害を検出した場合において、待機系のＣＰＵ割当量を回復し、系切り替えを実現することができる。

さらに、図２８は、本第７の実施形態において、待機系のスレーブクラスタプログラム１２０’（２２０’）が実行系の障害を検出した場合における待機系のゲストＯＳへの系切り替えを行う処理を表すフローチャートである。

ここで、処理Ｓ１３６１〜Ｓ１３６３は、前記第１実施形態の図８に示した処理Ｓ２６１〜Ｓ２６４と同様の処理を行なう。次に、処理Ｓ１３６４では、待機系のスレーブクラスタプログラム１２０’は、実行系のアプリケーション障害を検出しているため、系切り替えを行なうために前記Ｓ１１６４で実施されたＣＰＵ割当量の制限を解除するために、待機系のマスタクラスタプログラム５２０’に対してＣＰＵ割当制限の解除要求を行なう（Ｓ１３６４、通知Ｔ５４）。

待機系のマスタクラスタプログラム５２０’は前記通知Ｔ５４を受信すると（処理Ｓ１３２１）、前記図２７の処理１２４８と同様に、前記ＣＰＵ割付表５１６の割付量制限フラグを解除することで、待機系のゲストＯＳのＣＰＵ割当量制限の解除を行う（Ｓ１３２２）。これにより、前記処理１２６１と同様に、待機系のゲストＯＳ１３０’、２３０’のＣＰＵ割当量が前記処理Ｓ１１６４以前の状態で稼動を開始する（処理Ｓ１３６５）後に、待機系のスレーブクラスタプログラム１２０’、２２０’を実行する（処理Ｓ１３６６）。

このようにして、待機系のＣＰＵ割当量が制限された状態において、待機系のスレーブラスタプログラム１２０’、２２０’が障害を検出した場合も、待機系のＣＰＵ割当量の制限を解除した状態に復帰し、系切り替えを実現することができる。

なお、上記では待機系のアプリケーションまたはゲストＯＳへのＣＰＵの割当量を制限する例を示したが、メモリやＩ／Ｏの割当量を低減することで、さらに待機系の計算機資源を他の処理に有効利用することが可能となる。

以上の図２４〜図２８によって、第１の実施形態に第６の実施形態を適用した本第７実施形態によれば、自計算機上で稼動する待機系のゲストＯＳによるＣＰＵをはじめとする計算機資源やＯＳ資源の消費を制限することができ、障害が発生した場合には、待機系のゲストＯＳへのＣＰＵ割当制限を解除し、待機系のゲストＯＳに指示することで系切り替えを実現することができる。従って、実行系が正常な場合は、待機系への計算機資源を制限することで、待機系ゲストＯＳ数が増えても、パフォーマンスの低下を制限するホットスタンバイによる系切り替え方法を実現することができる。

また、本発明の説明においては、ホストＯＳ上にサーバ仮想化機構（サーバ仮想化プログラム）が存在する実施形態を用いて説明したが、本発明の背景技術に述べたように、図２９のハードウェア構成図に示すように、サーバ仮想化機構がハイパバイザ１７、２７等にある場合であってもよい。例えば、図３０のサーバ仮想化環境を表す機能ブロック図に示すように、ホストＯＳをハイパバイザ６３０等に置き換えることで、同様の方法を適用して、同様の効果を得ることが可能である。さらに、図３１では、ホストＯＳを全てハイパバイザ６３０に置き換える例を示したが、一部の機能のみをハイパバイザ６３０に移動する構成であっても良い。例えば、図３１に示すように、サーバ仮想化プログラム７１０やマスタクラスタプログラム７２０がホストＯＳではなく、他のゲストＯＳと同様のＬＰＡＲである管理ＬＰＡＲ７００上にあり、ＣＰＵスケジューラ部５１４をハイパバイザ上６３０に有する場合がある。この場合でも、同様の方法を適用して、同様の効果を得ることが可能である。

なお、上記各実施形態では、複数のゲストＯＳを提供する仮想化部が、ホストＯＳとサーバ仮想化プログラムやハイパバイザと仮想化プログラムあるいは管理ＯＳとサーバ仮想化プログラムの例を示したが、これらに限定されるものではない。例えば、仮想マシンモニタ（Virtual Machine Monitor）上に複数の仮想マシンを設定し、各仮想マシン上でゲストＯＳを稼動させる構成、あるいは、ファームウェアで物理的なパーティション（Physical PARtition ＝ＰＰＡＲ）を設定し、各ＰＰＡＲ上でゲストＯＳを稼動させる構成でクラスタリングを行う構成に本発明を適用することができる。なお、ＰＰＡＲを用いる場合には、ゲストＯＳ用のＰＰＡＲと、マスタクラスタプログラム用のＰＰＡＲを設定すればよい。

以上のように、本発明は、クラスタ構成をとる仮想化サーバ環境に適用することが可能である。特に、障害が発生した場合でも迅速な回復を要求されるシステムに適用すると好適である。

第１の実施形態の物理計算機のハードウェア構成を示すブロック図である。第１の実施形態の物理計算機におけるサーバ仮想化環境のソフトウェアを主体とした機能ブロック図である。第１の実施形態の実行系の物理計算機で実行されるソフトウェアの詳細な構成を示すブロック図である。第１の実施形態のゲストＯＳ系切り替え対応表の構成図である。第１の実施形態のホストＯＳ状態管理表の構成図である。第１の実施形態のゲストＯＳ状態管理表の構成図である。第１の実施形態の実行系のゲストＯＳの状態を実行系のマスタクラスタプログラムが検知する処理の一例を示すフローチャートである。第１の実施形態のスレーブクラスタプログラム間のハートビートによる系切り替え処理の一例を示すフローチャートである。第１の実施形態のマスタクラスタプログラム間のハートビートによるゲストＯＳの系切り替え処理の一例を示すフローチャートである。第２の実施形態を示し、マスタクラスタプログラム間のハートビートによるゲストＯＳの系切り替え処理の一例を示すフローチャートである。第３の実施形態を示し、実行系の物理計算機で実行されるソフトウェアの詳細な構成を示すブロック図である。第３の実施形態を示し、アプリケーション状態管理表の構成図である。第３の実施形態を示し、スレーブクラスタプログラムで実行されるアプリケーション状態の監視処理の一例を示すフローチャートである。第３の実施形態を示し、実行系のマスタクラスタプログラムがハートビートと一括して待機系へ送信する処理と、待機系のスレーブクラスタプログラムがハートビートを受信し、障害発生時には系切り替えを行う処理の一例を示すフローチャートである。第３の実施形態を示し、ホストＯＳ状態とゲストＯＳ状態を含む実行系のホストＯＳのハートビートの詳細を示す構成図である。第４の実施形態を示し、実行系のマスタクラスタプログラムがハートビートと一括して待機系へ送信する処理と、待機系のスレーブクラスタプログラムがハートビートを受信し、障害発生時には系切り替えを行う処理の一例を示すフローチャートである。第５の実施形態を示し、実行系の物理計算機で実行されるソフトウェアの詳細な構成を示すブロック図である。第５の実施形態を示し、マスタクラスタプログラムが実行するアプリケーション状態の監視と、ハートビートの送受信処理、さらに、障害発生時の系切り替え処理の一例を示すフローチャートである。第５の実施形態を示し、ホストＯＳ状態とゲストＯＳ状態及びアプリケーション状態を含む集約されたハートビートの一例を示す構成図である。第６の実施形態を示し、実行系の物理計算機で実行されるソフトウェアの詳細な構成を示すブロック図である。第６の実施形態を示し、ＣＰＵ割付表を示す構成図である。第６の実施形態を示し、待機系のゲストＯＳの凍結処理の一例を示すフローチャートである。第６の実施形態を示し、待機系のゲストＯＳへの系切り替え処理の一例を示すフローチャートである。第７の実施形態を示し、実行系の物理計算機で実行されるソフトウェアの詳細な構成を示すブロック図である。第７の実施形態を示し、ＣＰＵ割付表を示す構成図である。第７の実施形態を示し、待機系のゲストＯＳへのＣＰＵ割当量の制限を行う処理を表すフローチャートである。第７の実施形態を示し、待機系のマスタクラスタプログラムが実行する系切り替え処理の一例を示すフローチャートである。第７の実施形態を示し、待機系のスレーブクラスタプログラムの系切り替え処理の一例を示すフローチャートである。物理計算機のハードウェア構成の他の形態を示すブロック図である。他のサーバ仮想化環境を表すソフトウェアの機能ブロック図。さらに、他のサーバ仮想化環境を表すソフトウェアの機能ブロック図。

符号の説明

１１０、２１０アプリケーション
１２０スレーブクラスタプログラム
１２１アプリケーション状態通知部
１２２アプリケーション監視部
１２３系切り替え制御部
１３０ゲストＯＳ
５１０サーバ仮想化プログラム
５１１ゲストＯＳ制御部
５１２ゲストＯＳ監視部
５２０マスタクラスタプログラム
５３０ホストＯＳ
５２２系切り替え制御部
５２４ホストＯＳ監視部

Claims

少なくとも１つ以上の物理計算機で稼動する第１の仮想化部と第２の仮想化部と、
前記第１の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第１の系と、
前記第２の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第２の系と、
前記第２の仮想化部でゲストＯＳとアプリケーションを起動可能な第３の系と、を備え、
前記各ゲストＯＳ上で稼動して当該ゲストＯＳ上のアプリケーションを監視し、障害発生時には前記アプリケーションを第１の系と第２の系の間で切り替える第１のクラスタ処理を実行する第１のクラスタ管理部と、
前記各仮想化部上で稼動して、当該仮想化部上で稼動するゲストＯＳと他の仮想化部を監視し、障害発生時には前記第１の系のゲストＯＳ及びアプリケーションを第３の系へ移動し、前記ゲストＯＳ及びアプリケーションを起動することで第１の系と第３の系の間で切り替える第２のクラスタ処理を第２のクラスタ管理部が実行して、前記第１の系と第２の系または第３の系の間でゲストＯＳまたはアプリケーションを切り替えるクラスタシステムの系切り替え方法であって、
前記第２のクラスタ処理が、前記第１の系のゲストＯＳまたは第１の仮想化部を監視して障害を検出するステップと、
前記第２のクラスタ処理が、前記障害を検出したときには、前記障害を検出したゲストＯＳ上の第１のクラスタ処理を判定するステップと、
前記第２のクラスタ処理が、前記判定した第１のクラスタ処理に対して系切り替えを指令するステップと
前記第１のクラスタ処理が、前記ゲストＯＳ上のアプリケーションの障害を監視するステップと、
前記第１のクラスタ処理が、前記アプリケーションの障害を検出したときには、第１の系と第２の系との間で当該アプリケーションを切り替えるステップと、
前記第１のクラスタ処理が、前記第２のクラスタ処理から前記系切り替え指令を取得したときには、前記第１の系と第２の系の間で当該アプリケーション及びゲストＯＳを切り替えるステップと、
を含むことを特徴とするクラスタシステムの系切り替え方法。
前記第１のクラスタ処理が、前記ゲストＯＳ上のアプリケーションの障害を監視するステップは、
第１の系の第１のクラスタ処理が、当該第１のクラスタ処理を実行するゲストＯＳ上のアプリケーションの情報を取得するステップと、
前記第１の系の第１のクラスタ処理が、前記取得したアプリケーションの情報を前記第１の仮想化部の前記第２のクラスタ処理へ通知するステップと、を含み、
第２のクラスタ処理が、前記第１のクラスタ処理からのアプリケーションの情報を取得するステップと、
前記第１の仮想化部の第２のクラスタ処理が、前記各ゲストＯＳ上の第１のクラスタ処理からそれぞれ受信したアプリケーションの情報を一括して第２の仮想化部の第２のクラスタ処理へ通知するステップと、
前記第２の仮想化部の第２のクラスタ処理が、前記第１の系から受信したアプリケーションの情報を、当該アプリケーションに対応するゲストＯＳ上の第１のクラスタ処理へ通知するステップと、を含み、
第２の系の第１のクラスタ処理が、前記第２の系の前記第２のクラスタ処理から取得した第１の系のアプリケーションの情報に基づいて、前記アプリケーションの障害を監視することを特徴とする請求項１に記載のクラスタシステムの系切り替え方法。
前記アプリケーションの情報は、アプリケーションの稼動情報を含み、
前記第１の系の第１のクラスタ処理が、前記取得したアプリケーションの情報を前記第２のクラスタ処理へ通知するステップは、
前記アプリケーションの稼動情報を前記第２のクラスタ処理へ通知することを特徴とする請求項２に記載のクラスタシステムの系切り替え方法。
少なくとも１つ以上の物理計算機で稼動する第１の仮想化部と第２の仮想化部と、
前記第１の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第１の系と、
前記第２の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第２の系と、
前記第２の仮想化部で任意のゲストＯＳとアプリケーションを起動可能な第３の系と、を備え、
前記各ゲストＯＳ上で稼動して当該ゲストＯＳ上のアプリケーションを監視し、障害発生時には前記アプリケーションを第１の系と第２の系の間で切り替える第１のクラスタ処理を実行する第１のクラスタ管理部と、
前記各仮想化部上で稼動して、当該仮想化部上で稼動するゲストＯＳと他の仮想化部を監視し、障害発生時には前記第１の系のゲストＯＳ及びアプリケーションを第３の系へ移動し、前記ゲストＯＳ及びアプリケーションを起動することで第１の系と第３の系の間で切り替える第２のクラスタ処理を第２のクラスタ管理部が実行して、前記第１の系と第２の系または第３の系の間でゲストＯＳまたはアプリケーションを切り替えるクラスタシステムの系切り替え方法であって、
前記第１のクラスタ処理が、当該第１のクラスタ処理を実行するゲストＯＳ上のアプリケーションの情報を取得するステップと、
前記第１の系の第１のクラスタ処理が、前記取得したアプリケーションの情報を前記第２のクラスタ処理へ通知するステップと、
前記第１の仮想化部の第２のクラスタ処理が、前記第１のクラスタ処理から前記アプリケーションの情報を取得するステップと、
前記第１の仮想化部の第２のクラスタ処理が、前記各ゲストＯＳ上の第１のクラスタ処理からそれぞれ取得したアプリケーションの情報を集約するステップと、
前記第１の仮想化部の前記第２のクラスタ処理が、前記集約したアプリケーションの情報を、一括して第２の仮想化部の第２のクラスタ処理へ通知するステップと、
前記第２の仮想化部の第２のクラスタ処理が、前記アプリケーションの情報をハートビートとして取得し、当該アプリケーションに対応する第２の系のゲストＯＳ上の第１のクラスタ処理へ転送するステップと、
前記第２の系の第１のクラスタ処理が、前記第２のクラスタ処理から転送された前記アプリケーションの情報に基づいて、前記第１の系のアプリケーションの障害を監視し、障害を検知したときには前記アプリケーションを第１の系から第２の系へ切り替えるステップと、
を含むことを特徴とするクラスタシステムの系切り替え方法。
前記アプリケーションの情報は、アプリケーションの稼動情報を含み、
第１の系の第１のクラスタ処理が、前記取得したアプリケーションの情報を前記第２のクラスタ処理へ通知するステップは、前記アプリケーションの稼動情報を前記第２のクラスタ処理へ通知することを特徴とする請求項４に記載のクラスタシステムの系切り替え方法。
前記第１の仮想化部の第２のクラスタ処理が、前記集約したアプリケーションの情報を、一括して第２の仮想化部の第２のクラスタ処理へ通知するステップは、
前記第１の仮想化部の第２のクラスタ処理が、第１の系のゲストＯＳの状態を取得するステップと、
前記取得したゲストＯＳの状態と、前記取得したアプリケーションの障害状態とを一括して前記第２の仮想化部の第２のクラスタ処理へ通知するステップと、
を含むことを特徴とする請求項４に記載のクラスタシステムの系切り替え方法。
少なくとも１つ以上の物理計算機で稼動する第１の仮想化部と第２の仮想化部と、
前記第１の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第１の系と、
前記第２の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第２の系と、
前記第２の仮想化部で任意のゲストＯＳとアプリケーションを起動可能な第３の系と、を備え、
前記各ゲストＯＳ上で稼動して当該ゲストＯＳ上のアプリケーションを監視し、障害発生時には前記アプリケーションを第１の系と第２の系の間で切り替える第１のクラスタ処理を実行する第１のクラスタ管理部と、
前記各仮想化部上で稼動して、当該仮想化部上で稼動するゲストＯＳと他の仮想化部を監視し、障害発生時には前記第１の系のゲストＯＳ及びアプリケーションを第３の系へ移動し、前記ゲストＯＳ及びアプリケーションを起動することで第１の系と第３の系の間で切り替える第２のクラスタ処理を第２のクラスタ管理部が実行して、前記第１の系と第２の系または第３の系の間でゲストＯＳまたはアプリケーションを切り替えるクラスタシステムの系切り替え方法であって、
前記第１の系の第１のクラスタ処理が、当該第１のクラスタ処理を実行するゲストＯＳ上のアプリケーションを監視するステップと、
前記第１の系の第１のクラスタ処理が、前記アプリケーションに障害が発生したときには第１の仮想化部の第２のクラスタ処理に障害の状態を通知するステップと、
前記第１の仮想化部の第２のクラスタ処理が、前記アプリケーションの障害の状態を取得したときにのみ前記第２の仮想化部の第２のクラスタ処理へ当該アプリケーションの障害の状態通知するステップと、
前記第２の仮想化部の第２のクラスタ処理が、前記アプリケーションの障害の状態を取得したときには、前記第２の系の第１のクラスタ処理に系切り替えを指令することを特徴とするクラスタシステムの系切り替え方法。
前記第１の仮想化部の第２のクラスタ処理が、前記アプリケーションの障害の状態を取得したときにのみ前記第２の仮想化部の第２のクラスタ処理へ当該アプリケーションの障害の状態を通知するステップは、
前記第１の仮想化部の第２のクラスタ処理が、第１の系のゲストＯＳの状態を取得するステップと、
前記取得したゲストＯＳの状態と、前記取得したアプリケーションの障害状態とを一括して前記第２の仮想化部の第２のクラスタ処理へ通知するステップと、
を含むことを特徴とする請求項７に記載のクラスタシステムの系切り替え方法。
前記第１の仮想化部の第２のクラスタ処理が、前記アプリケーションの障害の状態を取得したときにのみ前記第２の仮想化部の第２のクラスタ処理へ当該アプリケーションの障害の状態を通知するステップは、
所定の周期で第１の系の仮想化部のハートビートに、前記アプリケーションの障害の状態を加えて、前記第２の仮想化部の第２のクラスタ処理へ通知することを特徴とする請求項７に記載のクラスタシステムの系切り替え方法。
前記第２の系の第１のクラスタ処理が、前記アプリケーションを起動して待機させるステップと、
前記第２の系の第１のクラスタ処理が、前記アプリケーションを待機させたことを第２の仮想化部の第２のクラスタ処理へ通知するステップと、
前記第２の仮想化部の第２のクラスタ処理が、前記通知に基づいて前記アプリケーションを待機させたゲストＯＳへのリソースの割当を低減して待機させるステップと、
前記第２の仮想化部の第２のクラスタ処理が、前記第１の系のアプリケーションの障害の状態を取得したときには、前記待機させたゲストＯＳへのリソースの割当を増大させた後に、系切り替えを行うことを特徴とする請求項７に記載のクラスタシステムの系切り替え方法。
少なくとも１つ以上の物理計算機と、
前記物理計算機で稼動する第１の仮想化部と第２の仮想化部と、
前記第１の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第１の系と、
前記第２の仮想化部で稼動するゲストＯＳと、当該ゲストＯＳ上で稼動するアプリケーションからなる第２の系と、
前記第２の仮想化部で任意のゲストＯＳとアプリケーションを起動可能な第３の系と、
前記第１の系のアプリケーションまたは第２の系のアプリケーションを監視して、障害発生時に前記アプリケーションを第１の系と第２の系の間で切り替える第１のクラスタ管理部と、
前記第１の系のゲストＯＳと第１の仮想化部を監視して、障害発生時に前記ゲストＯＳを第１の系と第３の系の間で切り替える第２のクラスタ管理部と、
を備えた計算機システムにおいて、
前記第１のクラスタ管理部は、
前記ゲストＯＳ上のアプリケーションの情報を取得するアプリケーション監視部と、
前記取得したアプリケーションの情報を前記第２のクラスタ管理部へ通知するアプリケーション状態通知部と、
前記アプリケーションの情報に障害情報が含まれるときには、前記アプリケーションを第１の系と第２の系との間で切り替える系切り替え制御部と、を備え、
前記第２のクラスタ管理部は、
前記第１のクラスタ管理部から受信したアプリケーションの情報を、他の仮想化部の第２のクラスタ管理部へ通知し、または、他の系から受信したアプリケーションの情報を前記第１のクラスタ管理部へ転送する通信部と、を備え、
第２の系の第１のクラスタ管理部が、前記第２の仮想化部の前記第２のクラスタ管理部から取得した第１の系のアプリケーションの情報に基づいて、前記アプリケーションの障害を監視することを特徴とする計算機システム。
前記第１のクラスタ管理部は、前記第１の系と第２の系の各ゲストＯＳ上でそれぞれ稼動し、
前記第２のクラスタ管理部は、前記第１の系と第２の系の各仮想化部でそれぞれ稼動し、
前記第１の系の第１のクラスタ管理部は、前記アプリケーション状態通知部が前記アプリケーションの情報を前記第１の仮想化部の第２のクラスタ管理部へ通知し、
前記第１の仮想化部の第２のクラスタ管理部は、前記通信部が前記アプリケーションの情報を前記第２の仮想化部の第２のクラスタ管理部へ通知し、
前記第２の仮想化部の第２のクラスタ管理部は、前記通信部が第１の仮想化部の第２のクラスタ管理部から前記アプリケーションの情報を受信し、当該情報を前記第２の系の第１のクラスタ管理部へ通知し、
前記第２の系の第１のクラスタ管理部は、
前記アプリケーション監視部が前記第１の系のアプリケーションを監視して、当該アプリケーションに情報に障害情報が含まれる場合には、前記系切り替え制御部が、第１の系のアプリケーションを、第２の系に引き継ぐことを特徴とする請求項１１に記載の計算機システム。
前記第２のクラスタ管理部は、
前記アプリケーションの情報からアプリケーションを監視し、当該アプリケーションに障害が発生した場合には、前記第１のクラスタ管理部へ系切り替えの指令を通知する系切り替え制御部を有し、
前記第１のクラスタ管理部は、前記第１の系と第２の系の各ゲストＯＳ上でそれぞれ稼動し、
前記第２のクラスタ管理部は、前記第１の系と第２の系の各仮想化部でそれぞれ稼動し、
前記第１の系の第１のクラスタ管理部は、前記アプリケーション状態通知部が前記アプリケーションの情報を前記第１の仮想化部の第２のクラスタ管理部へ通知し、
前記第１の仮想化部の第２のクラスタ管理部は、前記通信部が前記アプリケーションの情報を前記第２の仮想化部の第２のクラスタ管理部へ通知し、
前記第２の仮想化部の第２のクラスタ管理部は、前記通信部が第１の仮想化部の第２のクラスタ管理部から前記アプリケーションの情報を受信し、前記系切り替え制御部が前記アプリケーションの障害情報が含まれる時には前記第２の系の第１のクラスタ管理部に系切り替えの指令を通知し、
前記第２の系の第１のクラスタ管理部は、前記系切り替え制御部が第１の系のアプリケーションを第２の系へ引き継ぐことを特徴とする請求項１１に記載の計算機システム。
前記第１の系及び第２の系の仮想化部は、複数のゲストＯＳを稼動させ、
前記各ゲストＯＳ上のアプリケーション毎に前記第１のクラスタ管理部がアプリケーションの情報とゲストＯＳの情報を前記第２のクラスタ管理部へ通知し、
前記第２のクラスタ管理部の通信部は、第１のクラスタ管理部からのアプリケーションの情報とゲストＯＳの情報を集約し、当該集約した情報を他の仮想化部の第２のクラスタ管理部へ通知することを特徴とする請求項１１に記載の計算機システム。
前記第２の系の第１のクラスタ処理が、前記アプリケーションを起動して待機させるステップと、
前記第２の系の第１のクラスタ処理が、前記アプリケーションを待機させたことを第２の仮想化部の第２のクラスタ管理部へ通知するステップと、
前記第２の仮想化部の第２のクラスタ処理が、前記通知に基づいて前記アプリケーションを待機させたゲストＯＳへのリソースの割当を低減して待機させるステップと、
前記第２の仮想化部の第２のクラスタ処理が、前記第１の系のアプリケーションの障害の状態を取得したときには、前記待機させたゲストＯＳへのリソースの割当を増大させた後に、系切り替えを行うことを特徴とする請求項４に記載のクラスタシステムの系切り替え方法。