JP5032191B2 - サーバ仮想化環境におけるクラスタシステム構成方法及びクラスタシステム - Google Patents

Description

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

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

このような論理分割を用いた物理計算機（サーバ仮想化環境）では、サーバ仮想化プログラムによって、どのＬＰＡＲも等しい論理計算機として用いることが可能であるため、ユーザはどのＬＰＡＲ上でゲストＯＳと、そのゲストＯＳ上でアプリケーションを稼動させることが可能になる。これにより、ユーザは負荷に応じて、自由にゲストＯＳを実行する位置を決定することができるという機能を有する。

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

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

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

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

一方、上記方法２では、ホストＯＳ上のクラスタプログラムがハートビートによってホストＯＳとゲストＯＳの障害監視を行うことで、実行系の障害が発生した場合には、系切り替え先となる待機系を同一計算機または別計算機上にゲストＯＳのブートから行い、系切り替えを行う。この系切り替え方法では、ゲストＯＳの起動から行うコールドスタンバイが実現できる。

また、特許文献１では、サーバ仮想化環境において、ゲストＯＳ上のアプリケーションの性能を動的に保証する技術として、ゲストＯＳの負荷状態を監視し、過負荷時には必要となるゲストＯＳのリソースを動的に変更する技術が記載される。また、前記のリソースの変更時において、ゲストＯＳを稼動させている物理計算機上に割り当て可能なリソースがない場合に、割り当て可能なリソースを有する別の物理計算機にゲストＯＳを移動することで、ゲストＯＳのリソースを動的に変更する技術も記載されている。
米国特許第６，９８５，９３７号公報 「CLUSTERPRO（登録商標）を利用したVMware（登録商標）Rサーバ統合ソリューション」、[online]、日本電気株式会社 発行、[平成１８年1０月３１日検索]、インターネット＜ＵＲＬ：http://www.ace.comp.nec.co.jp/CLUSTERPRO/doc/pp_lin/CLUSTERPRO_VMware.pdf＞

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

また、上記の方法１と方法２は、それぞれ障害の監視と系切り替えを行うクラスタプログラムが異なるため、どちらの方法による系切り替え手法を用いるかは、事前に決定しておく必要がある。従って、例えば、上記で述べたように、アプリケーションを自由に任意のＬＰＡＲで動作させようとしたとしても、事前に系切り替え手法を選択しておく必要があるため、系切り替え手法を変更することができない。そのため、ＬＰＡＲの追加や削除が行われた場合や、あるいはサーバ仮想化環境を提供する物理計算機の構成に変化があった場合に、ユーザが求める高可用性に対して、演算性能の不足あるいは過剰な系切り替え性能を提供してしまう、という第２の課題がある。この課題によって、系切り替え性能が不足した場合には、障害時（引き継ぎ完了後）にシステムダウンを生じてしまったり、性能が過剰な場合は、余計にシステムリソースを消費してしまったり、という問題を生じる。

一方、クラスタ構成のシステムにおいて、上記特許文献１に記載される方法を用いた場合、処理を行なっている現用系のゲストＯＳの負荷に応じて、現用系のゲストＯＳを十分なリソースを有する物理計算機上に移動することが実現可能である。しかし、待機系のゲストＯＳのアプリケーションは系切り替え前に負荷を監視しても、系切り替え後の負荷を監視することができない。従って、特許文献１に記載される技術では、待機系のゲストＯＳは変更されないため、前記の第２の課題と同様に、ユーザが求める高可用性に対して、不足あるいは過剰な系切り替え性能を提供してしまう課題が生じる。

加えて、上記非特許文献１と上記特許文献１に記載される、物理計算機を跨ったゲストＯＳの移動を適用した場合、ゲストＯＳが重複して稼動するのを避ける必要があるため、移動元でのゲストＯＳの停止と、移動先でのゲストＯＳの開始の処理が必要である。そのため、ゲストＯＳの移動中、すなわち、移動元でのゲストＯＳの停止から移動先でのゲストＯＳの開始までの間は、移動対象のゲストＯＳはクラスタ構成を構築できない。従って、前記の第２の課題と同様に、系切り替え性能が不足するという課題が生じる。

以上に示すように、従来のサーバ仮想化環境では、ゲストＯＳに対して、固定的な系切り替え方法しか提供できないため、物理的あるいは論理的に構成が変更された場合に、ユーザが求める高可用性を適切に満たすことができなくなり、障害発生時にシステムダウンを生じたり、平常動作時に過度なリソース消費を生じたりする、という課題がある。

そこで本発明は、上記問題点に鑑みてなされたもので、サーバ仮想化環境において、系切り替え手法を自由に変更することのできる系切り替え方法を実現し、論理的または物理的に構成が変更された場合であっても、ユーザが求める高可用性に好適なクラスタ構成を提供することを目的とする。

本発明は、ゲストＯＳ上でアプリケーションプログラムを実行する複数の系を提供する仮想化部を備えた少なくとも一つの物理計算機と、前記系のゲストＯＳまたはアプリケーションプログラムを監視して、前記ゲストＯＳまたはアプリケーションプログラムに障害が発生したときには、前記系を他の系に切り替えるクラスタシステムの構成方法であって、前記物理計算機は、前記ゲストＯＳ上で稼働して前記アプリケーションの稼働状態を監視する第１のクラスタ管理部と、前記第１のクラスタ管理部から前記アプリケーションの稼働状態を受け付けて障害発生時に前記アプリケーションプログラムを他の系に切り替える第２のクラスタ管理部と、を有し、前記第２のクラスタ管理部が、前記系毎に、障害発生時に切り替え可能な他の系と、予め設定した複数の系切り換え手法のうちのいずれかひとつを、系切り替えの候補として高可用性構成パターンに設定するステップと、前記第２のクラスタ管理部が、前記系毎に、障害発生時に必要とする切り替え要件を高可用性要件として設定するステップと、前記第２のクラスタ管理部が、前記高可用性構成パターンに設定された系切り替え手法のうち、前記高可用性要件を満たす系切り替え手法を選択するステップと、前記第２のクラスタ管理部が、前記高可用性要件を満たす系切り替え手法がある場合には、前記高可用性構成パターンから前記選択された系切り替え手法を実現可能で、かつ、前記高可用性要件を満たす他の系を、当該系の系切り替え先として設定するステップと、を含む。

また、物理計算機上で複数のゲストＯＳを稼動させる仮想化部と、前記各ゲストＯＳ上で稼動するアプリケーションプログラムからなる複数の系と、前記アプリケーションプログラムまたはゲストＯＳを監視して、障害発生時に前記アプリケーションプログラムを他の系に切り替えるクラスタ管理部と、を備えたクラスタシステムにおいて、前記クラスタ管理部は、前記ゲストＯＳ上で稼働して前記アプリケーションの稼働状態を監視する第１のクラスタ管理部と、前記第１のクラスタ管理部から前記アプリケーションの稼働状態を受け付けて障害発生時に前記アプリケーションプログラムを他の系に切り替える第２のクラスタ管理部と、を有し、前記第２のクラスタ管理部は、前記系毎に設定されて障害発生時に必要とする切り替え要件を高可用性要件として設定する高可用性要件設定部と、前記系毎に、障害発生時に切り替え可能な他の系と、予め設定した複数の系切り換え手法のうちのいずれかひとつを、系切り替えの候補として高可用性構成パターンに設定する高可用性構成パターン設定部と、前記高可用性構成パターンに設定された系切り替えの候補のうち、前記高可用性要件を満たす系切り替え手法と、前記高可用性要件を満たす他の系を、当該系の系切り替え先として選択する高可用性構成判定部と、を備え、前記第２のクラスタ管理部は、前記高可用性構成判定部が選択した系切り替え手法及び系切り替え先に基づいて前記系切り替えを行う。

したがって、本発明は、サーバ仮想化環境におけるクラスタ構成において、ゲストＯＳ／ホストＯＳ（仮想化部）上に複数の系切り替え手法を提供するクラスタ管理部（スレーブクラスタプログラム、マスタクラスタプログラム）が稼動し、設定された高可用性要件（ＨＡ要件）を満たす系切り替え手法を選択し、実現することによって、ユーザが求めるＨＡ要件に好適なクラスタ構成を実現する機能を提供することができる。

これにより、サーバ仮想化環境において、ゲストＯＳに対する複数の系切り替え手法を提供するクラスタ構成において、システムの物理的または論理的な構成や稼動状態が変更した場合であっても、要求された高可用性要件に応じた好適な系切り替え手法を選択することによって、要求された高可用性要件に対して計算機資源の過不足のないクラスタ構成を提供することができる。

以下、本発明の実施の形態を添付図面に基づいて説明する
＜第１の実施の形態＞
本発明に関する図と説明は、本発明を鮮明に理解するのに適当な要素を示すために簡略化されており、発明を実施するのに支障ない範囲で既知の要素等は省略していることを理解されたい。本技術中で従来技術の中には、本発明を実装するために他の要素が望ましく、かつ／または、必要とされると思われるものが幾つかある。しかし、技術中のこれらの要素は既知であり、本発明の理解を容易にするものではないので、ここでは説明しない。

また、以下の説明では、各プログラムは実行系（または現用系）のモジュール番号で説明している場合もあるが、それらの説明は、待機系の対応したプログラムの説明も兼ねる場合もある。さらに、以降の図に示す符号において、他の図中の数字と同様の番号を用いているものがあるが、それらについては特に説明がない場合、他の図の説明と同様である。

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

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

第１の実施の形態の物理計算機Ａは、ＣＰＵ１１と、メモリ１４と、ストレージ装置１５と、ＮＩＣ（ネットワークインターフェースカード）１６、ＨＢＡ（ホストバスアダプタ）１７、さらに前記ＨＢＡ１７を経由して接続可能な共有ストレージ４０を備える。

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

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

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

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

実行系システムを構成する物理計算機Ａでは、ホストＯＳ＿Ａ（５４０）上に論理区画（以下、ＬＰＡＲ＝Logical PARtitionとする）を構成するサーバ仮想化プログラム５１０が稼動し、ＬＰＡＲ１とＬＰＡＲ２を提供する。また、前記サーバ仮想化プログラム５１０は、前記ＬＰＡＲ１とＬＰＡＲ２と異なる新たなＬＰＡＲ５を提供する。なお、ホストＯＳ５４０とサーバ仮想化プログラム５１０が仮想化部を構成する。

ＬＰＡＲ１ではゲストＯＳ１（１３０）が実行され、このゲストＯＳ１上でアプリケーションプログラム（ＡＰ１）１１０が稼動し、また、アプリケーションプログラム（以下、アプリケーションとする）ＡＰ１を監視し、アプリケーションＡＰ１の稼動状態をマスタクラスタプログラム５２０に通知する機能と、マスタクラスタプログラム５２０からの指示を受けて、実行系と待機系の間で系切り替えを行う機能とを有するスレーブクラスタプログラム１２０が稼動する。

ＬＰＡＲ２ではゲストＯＳ２（２３０）が実行され、このゲストＯＳ２上でアプリケーション（ＡＰ２）２１０が稼動し、また、アプリケーションＡＰ２を監視するスレーブクラスタプログラム２２０が稼動する。ＬＰＡＲ５では、ゲストＯＳやアプリケーションは稼動しておらず、実行系上または待機系上の任意のＬＰＡＲを切り替えた場合に、前記切り替えたＬＰＡＲ上のゲストＯＳやアプリケーション、スレーブクラスタプログラムがＬＰＡＲ５で稼動する。ここで、ＬＰＡＲ５は事前に設定されたＬＰＡＲであってもよいし、前記切り替えが行なわれる場合に、前記サーバ仮想化プログラムが提供する新たなＬＰＡＲであってもよい。

また、ホストＯＳ＿Ａ上では、各ＬＰＡＲ１、２のアプリケーションまたはゲストＯＳまたは他の仮想化部を監視し、待機系のＬＰＡＲ２が存在する実行系ＬＰＡＲ１に障害が発生した場合には、前記スレーブクラスタプログラムに指示して、ＬＰＡＲ１とＬＰＡＲ３との間で第１の系切り替えを実行する機能を有するマスタクラスタプログラム５２０が稼動している。加えて、前記マスタクラスタプログラム５２０は、待機系が存在しない実行系ＬＰＡＲ２に障害が発生した場合には、前記ＬＰＡＲ２と前記新たなＬＰＡＲ５の間でゲストＯＳ及びアプリケーションを切り替え、前記ＬＰＡＲ５、ゲストＯＳとアプリケーションを起動することで、第２の系切り替えを実行する機能を有する。

一方、待機系システムを構成する物理計算機Ｂも、実行系システムの物理計算機Ａと同様の構成のソフトウェアが実行される。つまり、物理計算機Ｂでは、ホストＯＳ＿Ｂ（５４０’）上にＬＰＡＲ３を構成するサーバ仮想化プログラム５１０’が稼動する。また、前記サーバ仮想化プログラム５１０’は、前記ＬＰＡＲ３と異なる新たなＬＰＡＲ４を提供する。ＬＰＡＲ３ではゲストＯＳ３（１３０’）が実行され、このゲストＯＳ３上では実行系から切り替えるためのアプリケーション（ＡＰ１）１１０’が稼動し、また、実行系のアプリケーションＡＰ１を監視し、マスタクラスタプログラム５２０’に監視結果を通知する機能と、前記マスタクラスタプログラム５２０’からの指示を受け、実行系と待機系の間で第１の系切り替えを行う機能とを有するスレーブクラスタプログラム１２０’が稼動する。

待機系のＬＰＡＲ４では、ゲストＯＳやアプリケーションは稼動しておらず、実行系上または待機系上の任意のＬＰＡＲを切り替えた場合に、前記切り替えたＬＰＡＲ上のゲストＯＳやアプリケーション、スレーブクラスタプログラムが稼動する。

また、ホストＯＳ＿Ｂ上では、ＬＰＡＲ３のアプリケーションまたはゲストＯＳまたは他の仮想化部を監視するマスタクラスタプログラム５２０’が稼動し、待機系ＬＰＡＲ２が存在する実行系ＬＰＡＲ１に障害が発生した場合には、前記スレーブクラスタプログラムに指示して、実行系のＬＰＡＲ１と待機系のＬＰＡＲ３との間で第１の系切り替えを実行する機能を有するマスタクラスタプログラム５２０’が稼動している。加えて、前記マスタクラスタプログラム５２０’は、待機系が存在しない実行系のＬＰＡＲ２に障害が発生した場合には、前記ＬＰＡＲ２と前記新たなＬＰＡＲ４の間でゲストＯＳ及びアプリケーションを切り替え、前記ＬＰＡＲ４、ゲストＯＳとアプリケーションを起動することで、第２の系切り替えを実行する機能を有する。

ここで、待機系の前記マスタプログラム５２０’によって行なわれるゲストＯＳ及びアプリケーションの切り替えは、例えば、ゲストＯＳやアプリケーションを起動するディスク装置を新たなＬＰＡＲが利用することで実現してもよいし、ゲストＯＳやアプリケーションの動作中のスナップショットを利用することで実現してもよい。なお、ＬＰＡＲ４、ＬＰＡＲ５は、コールドスタンバイとして機能する第３の系を構成する。

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

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

ＬＰＡＲ１００は、ＯＳとしてゲストＯＳ１３０が稼動しており、そのゲストＯＳ１３０上で、業務を行なうアプリケーション（ＡＰ１）１１０と、マスタクラスタプログラム５２０に前記アプリケーションＡＰ１が必要とする高可用性を定義する高可用性（High Availability）要件（以下、ＨＡ要件という）を設定し、マスタクラスタプログラム５２０にＨＡ要件を通知する機能と、アプリケーション（ＡＰ１）１１０の状態を監視し、マスタクラスタプログラム５２０へ前記状態を通知する機能と、前記マスタクラスタプログラム５２０からの指示を受け、実行系と待機系の間で第１の系切り替えを行う機能を有するスレーブクラスタプログラム１２０とを含む。ＨＡ要件は、アプリケーション１１０やゲストＯＳ１３０に障害が発生したときに実行する系切り替えの形態（系切り替え方法や系切り替え先）を決定するための要件である。

前記スレーブクラスタプログラム１２０は、アプリケーション１１０の状態を監視してマスタクラスタプログラム５２０に前記状態を通知するアプリケーション監視部１２１と、前記マスタクラスタプログラム５２０からの指示によって、実行系から待機系へのアプリケーションの系切り替えを実施する系切り替え実施部１２２とを有する。加えて、スレーブクラスタプログラム１２０は、前記アプリケーション１１０が必要とする高可用性を定義するＨＡ要件を設定し、マスタクラスタプログラム５２０にＨＡ要件を通知するＨＡ要件設定部１２３を含む。

前記ＨＡ要件設定部１２３は、例えば、図９に示すようなＨＡ要件定義１２４を有する。ここで、ＨＡ要件とは、例えば、障害発生時に系切り替えによってアプリケーションが引き継ぎを完了するまでに許容される時間（アプリケーションの停止許容時間等）の指定がある。また、系切り替えを含む複数の障害回復方法がある場合には、それらの障害回復方法の指定であったり、複数のアプリケーションの系切り替えが生じる場合には、それらのアプリケーションの優先順序の指定であったりしてもよい。

さらに、系切り替え後もアプリケーションが安定して稼動することを保証するためのアプリケーションの性能に関する要件を含んでも良い。例えば、系切り替え先となる論理計算機や、物理計算機の範囲の指定であったりしてもよく、その範囲の指定方法として、直接的に計算機の位置や範囲の指定を行う以外に、例えば、論理計算機あるいは物理計算機が有するＣＰＵやメモリ、ストレージ装置、ＮＩＣ、ＨＢＡといった計算機リソースが有する機能のうち、アプリケーションが利用する機能を指定することで決定されてもよいし、計算機リソースの種類（例えば、ＣＰＵやストレージ装置の個別の製品名称）を指定することで決定されてもよい。さらに、アプリケーションの同時稼動数を決定するような、ライセンス上限数の指定であってもよい。

図９に示すＨＡ要件定義１２４は、対象とするアプリケーションとＬＰＡＲをそれぞれ示す識別子１３０１、１３０２と、前記ＬＰＡＲ識別子１３０２で示されたＡＰが許容できる停止時間１３０３と、優先される系切り替え方法１３０４を含む。また、それぞれの要件定義に優先度が指定されている場合には、それぞれの識別子１３０１、１３０２に合わせてその優先度を示す情報も含む。加えて、複数のアプリケーションの優先度を指定するアプリケーションの優先度の指定１３０５を有する。前記優先度指定１３０５は、複数のアプリケーションに影響を与えるシステム全体に対するＨＡ要件であり、このようなシステム全体に対するＨＡ要件が複数存在する場合に、前記のアプリケーション内部のＨＡ要件定義１３０１〜１３０４とは異なる優先度を与えることも可能であり、その優先度も前記優先度の指定１３０５に含む。

図９のＨＡ要件定義は、図８で示すようなユーザインターフェース（ＵＩ）を用いて指定されてもよい。例えば、図８のＵＩでは、前記ＨＡ要件定義１２４の設定項目のうち、アプリケーション識別子と前記アプリケーションのＨＡ要件を定義するＵＩ２００１と、複数のアプリケーションに対するシステム全体のＨＡ要件を定義するＵＩ２１０１と、前記ＨＡ要件の追加または削除、加えて、マスタクラスタプログラム５２０への定義の通知とキャンセルを行うＵＩ２２０１と、前記ＵＩ２２０１で実行した結果を表示するＵＩ２３０１と、さらに前記２３０１の結果によるＨＡ構成を承諾あるいは変更するＵＩ２４０１を有する。ここで、前記各ＵＩは同時に表示されることがあってもいいし、その一部のみを表示してもよい。例えば、アプリケーションが１種類に限定される場合であれば、システム全体のＨＡ要件を指定するＵＩ２１０１は省略されてもよいし、実行結果に関するＵＩ２３０１、２４０１は、他のＵＩとは独立して表示されてもよい。また、前記ＵＩ２００１では、ＡＰ識別子を指示するＵＩ２０１１や、ＨＡ要件の識別子、指定内容、優先度を指定するＵＩ２０１２、２０１３、２０１４を有しており、各ＵＩは指定可能な候補から選択する方法で指定してもよいし、ユーザが任意の情報を記入してもよい。

なお、ＵＩ２１０４で指定される優先度は、ＵＩ２００１で指定される各ＨＡ要件で一意に定まる優先度が指定される。加えて、ＵＩ２３０１で表示される実行結果は、マスタクラスタプログラムによって設定された系切り替え手法の情報を示すだけでなく、系切り替え手法が設定できなかった情報を示してもよい。なお、設定できなかった場合は、前記ＵＩ２４０１を用いて再度ＨＡ要件を修正して入力し直してもよい。ここで、図８ではＵＩの一例として、グラフィカルなＵＩを示したが、コマンドや、プログラムの連携Ｉ／Ｆとして提供されてもよい。また、上記ユーザーインターフェースは、物理計算機Ａ、Ｂに接続したコンソールや、ネットワークに接続した計算機などで実行し、管理者などが入力することができる。

図８に示すＵＩ２００１では、図４に示す共有ストレージ装置４０に格納されたアプリケーションＡＰ１の設定の一例を示しており、ＡＰ停止許容時間は１５０秒であるが、第１の系切り替え（ホットスタンバイ）手法を要求していることを表している。また、ＵＩ２１０１では、図４のアプリケーションＡＰ１とＡＰ２のどちらを優先的に、系切り替え手法を決定するか否かを表しており、アプリケーションＡＰ２がＡＰ１に優先することを表している。また、ＵＩ２３０１では、実行結果として、図４に示す通り、ＬＰＡＲ１とＬＰＡＲ３をそれぞれ実行系と待機系とした第１の系切り替え手法が適用されたことを示している。

なお、アプリケーション１１０の稼動状態としては、アプリケーション１１０が実行中に発生する信号の他、アプリケーション１１０が生成したデータやファイルを含めることができ、これらの情報はアプリケーション１１０の稼動状態を示す稼動情報を構成する。そして、これらの稼動状態の検出は、アプリケーション１１０の稼動情報を検知することで行うことができる。

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

サーバ仮想化プログラム５１０は、前記ゲストＯＳ１３０に図１で示した物理的な計算機資源（ハードウェア）の割当を行うゲストＯＳ制御部５１１と、ゲストＯＳ１３０から得たゲストＯＳの稼動状態を管理するゲストＯＳ監視部５１２を有する。前記ゲストＯＳ監視部５１２は、ゲストＯＳ１３０の監視結果をマスタクラスタプログラム５２０が有する系状態管理部５２２に通知する。

さらに、実行系のマスタクラスタプログラム５２０は他の物理計算機Ｂや、前記ホストＯＳ５４０上のスレーブクラスタプログラム１２０、２２０との通信を行うことのできる通信部５２１と、ホストＯＳ５４０の稼動状態を監視するホストＯＳ監視部５２４と、アプリケーションとゲストＯＳとホストＯＳ５４０の稼動状態を記録する系状態管理表５２３を有し、系の状態を監視する系状態管理部５２２を有する。加えて、マスタクラスタプログラム５２０は、前記ホストＯＳ監視部５２４が障害を検出した場合に実行する系切り替え手法を記録する系切り替え対応表５２６を有し、前記系切り替え対応表５２６に従って、障害発生時に系切り替え先となるスレーブクラスタプログラム１２０、２２０に対して系切り替えを指示することで第１の系切り替え手法を実施するか、あるいは、前記第３の系であるＬＰＡＲ４、ＬＰＡＲ５に対して第２の系切り替え手法による系切り替えを実行する系切り替え制御部５２５とを有する。

加えて、マスタクラスタプログラム５２０は、各ゲストＯＳが第１の系切り替え手法と第２の系切り替え手法が実行可能か否かを示すＨＡ構成パターン表（テーブル）５２８を有し、前記スレーブクラスタプログラム１２０のＨＡ要件設定部１２３で定義されたＨＡ要件定義１２４を満たす系切り替え方法を前記ＨＡ構成パターン表（高可用性構成パターン情報）５２８から選択し、前期系切り替え制御部５２５に設定するＨＡ構成判断部５２７を有する。

ここで、前記ＨＡ構成パターン表５２８は、後述の図７のように、アプリケーションに適用するＨＡ構成のパターンを含む。例えば、前記ＨＡ構成パターン表５２８は、複数の障害回復方法（系切り替え方法）が存在する場合には、系切り替え方法の指定を含んでもよいし、複数の系切り替え先が存在する場合には、その系切り替え先の指定を含んでもよい。さらに、前記パターン表は、指定された系切り替え方法や系切り替え先によって、回復される障害の範囲を情報として含んでもよい。また、前述したＨＡ要件の種別に応じて、そのＨＡ要件に関する性能値や、ＨＡ要件への対応の可否を示す情報を含んでもよい。例えば、図７では、前記のアプリケーションの停止許容時間というＨＡ要件に対応して、系切り替え時間が含まれたり、ＨＡ構成パターンが対象とするアプリケーションに設定可能か否かを示す選択可否の情報が含まれたりする。

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

図５に示す前記系状態管理表５２３は、サーバ仮想化プログラム５１０が管理するアプリケーション１１０、２１０とゲストＯＳ１３０、２３０とホストＯＳ５４０の識別子１００１と、前記識別子を有するアプリケーションとゲストＯＳとホストＯＳの状態１００２を含む。図５では、各プリケーションとゲストＯＳとホストＯＳが正常（Ｓｔａｔｕｓ ＯＫ）であることを示す。

図６は、マスタクラスタプログラム５２０の系切替制御部５２５が管理する系切替対応表５２６の一例を示す説明図である。

図６に示す前記系切り替え対応表は、アプリケーション識別子１１０１によって示されるアプリケーション１１１１、１１１２に適用される系切り替え手法を格納するものである。例えば、図６では、系切り替え手法の種別１１０２と、各系切り替え手法における現用系（ＯＮＬ）と待機系（ＳＢＹ）を表す系状態１１０３を有しており、前記系状態毎に、各系の位置する物理計算機、ＬＰＡＲ、ホストＯＳ、ゲストＯＳ、起動ディスクを表すそれぞれの識別子１１０４、１１０５、１１０６、１１０７、１１０８を有する。図６では、図３で示したように、アプリケーションＡＰ１は第１の系切り替え状態（Ｈｏｔ Ｓｔａｎｄｂｙ）で実行系をＬＰＡＲ１、待機系をＬＰＡＲ３に設定しており、アプリケーションＡＰ２は第２の系切り替え状態（Ｃｏｌｄ Ｓｔａｎｄｂｙ）であり、実行系がＬＰＡＲ２で待機系が物理計算機Ｂに設定されていることを意味している。

ここで、起動ディスク１１０８は、図４に示される共有ストレージ装置４０上にある各アプリケーションと、各系状態に対応した起動ディスクを指す。図４では、アプリケーションＡＰ１、ＡＰ２の実行系と待機系の起動ディスクとして、それぞれ起動ディスク４１、４２と４３、４４が存在することを示している。

図７に示す前記ＨＡ構成パターン表５２８は、アプリケーションを表す識別子１２０１を有する。ＨＡ構成パターン表５２８は、加えて、実現可能な各系切り替え手法を表す識別子１２１１、１２１２、１２１３、１２１４、１２１５を有し、各系切り替え手法の識別子１２１１〜１２１５毎に実現する系切り替え（障害回復）手法の識別子１２０２、系切り替え先の識別子１２０３、系切り替えによって回復可能な障害種別の識別子１２０４、系切り替えに要する所要時間１２０５を有する。

例えば、前記識別子１２０２では、第１の系切り替え手法（図中、Ｈｏｔ＝ホットスタンバイ）と第２の系切り替え手法（図中、Ｃｏｌｄ＝コールドスタンバイ）を網羅しており、識別子１２０３によって、第１の系切り替え手法（Ｈｏｔ）では、実行系と異なるＬＰＡＲとなる待機系をどの物理計算機上で実現するかで分類されている。同様に第２の系切り替え手法では、識別子１２０３によって、実行系の同一ＬＰＡＲか異なるＬＰＡＲか、異なるＬＰＡＲの場合は、第１の系切り替え手法と同様に、どの物理計算機上で待機系（系切り替え先）を実現するかで分類されている。また、識別子１２０４は、前記系状態管理部５２２が監視している状態に対応した障害箇所を含む。なお、図７に示す回復可能障害範囲の識別子１２０４ではホストＯＳ間のハートビートが喪失した場合を計算機の障害とみない例を示し、他の物理計算機Ｂ発生した障害を回復可能障害範囲に含んでいる。

さらに、系切替時間１２０５は各系切り替え手法によってアプリケーションＡＰが停止する時間（系切り替え時間）を表しており、本実施形態ではユーザが上述のコンソールなどから設定することで定義される。加えて、前記図８、図９で指定されるＨＡ要件定義及びＵＩでは、前記回復可能障害範囲の識別子１２０４に対応するＨＡ要件定義を示してないが、図８、図９で対応するＨＡ要件で回復可能障害範囲の識別子１２０４を定義してもよい。

さらに、前記ＨＡ構成パターン表５２８は、識別子１２１１〜１２１５で設定された各系切り替え手法が選択可能か否かを示す識別子１２０６を有する。識別子１２０６は識別子１２１１〜１２１５で設定された系切り替え手法が選択不可能であるか、選択可能であるか、現在選択されているか否かを示す。例えば、図７では、アプリケーションＡＰ１はＬＰＡＲ１（物理計算機Ａ）とは異なる計算機（物理計算機Ｂ）に待機系（ＬＰＡＲ３）を有する第１の系切り替え手法（＃５）が選択されていることを示している。

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

以下、同様のフローチャートに示す各動作には、各クラスタプログラム外のモジュールと連携した動作を含む。

図１０は、実行系のマスタクラスタプログラム５２０のＨＡ構成判断部５２７が、実行系のスレーブクラスタプログラム１２０のＨＡ要件設定部１２３で定義されたＨＡ要件定義１２４を通知された場合に、システム全体に関するＨＡ要件定義がある場合に行う第１の処理の例を示すフローチャートである。なお、以下の説明では、実行系についての処理を説明するが、他のゲストＯＳ２及び待機系の処理も同様である。

まず、ＨＡ構成判断部５２７が実行系のゲストＯＳ１３０上のＨＡ要件設定部１２３からＨＡ要件定義を受信すると（Ｓ１０１）、前記ＵＩ２１０１で指定されるシステム全体のＨＡ要件が指定されたか否かを判断する（Ｓ１０２）。システム全体のＨＡ要件が定義されていなければ、実現可能なＨＡ構成に制約が生じないため、実現可能なＨＡ構成があるかどうかの判断（Ｓ１０６）を実行する。

一方、ＨＡ要件が定義されている場合には、他のアプリケーションによるＨＡ構成が存在するか否かを判断する（Ｓ１０３）。存在しない場合は、自アプリケーションに対してＨＡ要件を適用すれば良く、Ｓ１０８で前記ＨＡ要件を満たすＨＡ構成を選択してからＳ１０６を実行する。

一方、Ｓ１０３で他のアプリケーションが存在する場合は、そのアプリケーションのＨＡ構成を参照し（Ｓ１０４）、そのＨＡ構成と合わせて、ＨＡ要件を満たすＨＡ構成を選択する（Ｓ１０５）。例えば、前記図８のＵＩ２１０１に示すように、アプリケーションＡＰ１、ＡＰ２の順に優先度が指定されている場合、アプリケーションＡＰ２のＨＡ構成が決定済であれば、アプリケーションＡＰ１の設定はＳ１０４、Ｓ１０５を実行し、自身より優先度の高いアプリケーションＡＰ２のＨＡ構成と矛盾しないＨＡ構成を選択する。

一方、アプリケーションＡＰ２のＨＡ構成が未決定であればアプリケーションＡＰ１のＨＡ構成を選択し、Ｓ１０６を実行する。また、逆にアプリケーションＡＰ２よりＡＰ１に高い優先度が指定されていて、アプリケーションＡＰ１が設定済である場合には、アプリケーションＡＰ１よりもＡＰ２のＨＡ構成が優先されるため、アプリケーションＡＰ１に関係なく、アプリケーションＡＰ２のＨＡ構成を選択する処理をＳ１０７で行なう。ここで、Ｓ１０７におけるＨＡ構成の選択は、以降に述べる図１１におけるＳ２０１〜Ｓ２１５で実行されるＨＡ構成の選択処理を実行することで実現可能であり、ＨＡ構成が選択された場合には、Ｓ２１５から該処理Ｓ１０４に戻り、以降の処理を継続する。ここで、前記Ｓ２０１〜Ｓ２１５でＨＡ構成が実現できない場合には、後述するエラー通知処理Ｄを呼び出すことで、エラー通知処理が実現される。処理Ｓ１０６では、実現可能なＨＡ構成が選択されているか否かを判断する。Ｓ１０６で、実現可能なＨＡ構成があるならば、それらのＨＡ構成の候補を選択可能として、前記ＨＡ構成パターン表５２８に候補として登録し（Ｓ１０７）、その後、アプリケーションに対するＨＡ要件によるＨＡ構成の選択処理Ｂを実行する。一方、Ｓ１０６で、実現可能ＨＡ構成が存在しない場合には、ＨＡ構成が実現できないため、ユーザにエラーを通知する処理Ｄを実行する。

図１１は、前記ＨＡ構成判断部５２７が、前記ＨＡ要件定義のうち、アプリケーションＡＰに関するＨＡ要件定義がある場合に行う第２の処理の例を示すフローチャートである。

まず、ＨＡ構成判断部５２７は、前記処理Ｓ１０７から処理Ｂが呼び出されると、Ｓ２０１を実行する。Ｓ２０１では、前記ＨＡ要件に優先度が設定されたＨＡ要件があるか否かを判断し、存在する場合には、指定されたＨＡ要件に対する処理を行なうため、Ｓ２０２以下を実行する。Ｓ２０２では、優先度の指定があるＨＡ要件に従って、ＨＡ構成パターンを選択する。例えば、図９において、ＡＰ停止許容時間１３０４が優先度１で定義されているため、これに従い、前記許容時間１３０４を満足する系切り替え時間を有するＨＡ構成パターンを選択する。ＨＡ構成パターンを選択した後、上記処理Ｓ１０６と同様に、実現可能なＨＡ構成があるか否かを判断し（Ｓ２０３）、存在しない場合には、ユーザにエラーを通知する処理Ｄを実行する。

一方、Ｓ２０３の判定において選択可能なＨＡ構成がある場合には、前記処理Ｓ１０７と同様に、実現可能なＨＡ構成を選択し（Ｓ２０４）、優先度が与えられた次のＨＡ要件があるか否かを判断する（Ｓ２０５）。次のＨＡ要件がある場合には、このＨＡ要件を読み出してから（Ｓ２０６）再度Ｓ２０２に戻り、次のＨＡ要件を用いてＨＡ構成の選択を実施する。

一方、上記Ｓ２０１の判定で優先度が指定されたＨＡ要件が処理済み、あるいは、存在しなかった場合には、残りの優先度が指定されていないＨＡ要件の適用処理をＳ２０８以降で実施する。

Ｓ２０８では、ＨＡ要件があるか否かを判断する。実現可能なＨＡ要件がある場合には、指定されたＨＡ要件に従って、ＨＡ構成を選択する（Ｓ２０９）。ＨＡ構成を選択した後、上記Ｓ２０３、Ｓ２０４と同様の処理Ｓ２０９、Ｓ２１０を実施する。すなわち、実現可能なＨＡ構成が存在しない場合には、ユーザにエラーを通知する処理Ｄを実行し、存在する場合には、次のＨＡ要素によるＨＡ構成を選択するため、処理Ｓ２０８へ戻る。一方、Ｓ２０８で、指定されたＨＡ要件がなくなった場合には、全てのＨＡ要件が適用されたことを意味しており、実現可能なＨＡ構成があるか否かを判断する（Ｓ２１１）。Ｓ２１１の判定で実現可能なＨＡ構成が存在しない場合には、ユーザにエラーを通知する処理Ｄを実行する。一方、実現可能なＨＡ構成が存在する場合は、複数のＨＡ構成が選択可能か否かを判断する（Ｓ２１２）。複数のＨＡ構成が存在する場合は、いずれかのＨＡ構成を選択することが可能であるため、その内の一つのＨＡ構成を後述するように選択する（Ｓ２１３）。ここで、選択の方法としては、例えば、ＨＡ要件以外の指標を用いて選択する方法であってもよいし、再度、スレーブクラスタプログラム１２０のＨＡ要件設定部１２３を介して、ユーザに複数の候補を提示し、明示的にユーザに選択してもらう方法であってもよい。Ｓ２１４では、ＨＡ構成は一つに決定されているため、前記ＨＡ要件設定部１２３を介して、決定されたＨＡ構成への変更をユーザに通知する。ここで、前記通知は、ＨＡ要件の入力を行なった前記ＨＡ要件設定部１２３の他に、他のスレーブクラスタプログラム２２０のＨＡ要件設定部に通知を行っても良い。Ｓ２１５を実施後、選択されたＨＡ構成の設定変更を実施する（Ｓ２１５）。

図１２は、上記図１０のＳ１０６、図１１のＳ２０３、Ｓ２１１の何れかで、実現可能なＨＡ構成がないと判定された場合に、前記ＨＡ構成判断部５２７が前記ＨＡ要件設定部１２３を介して、ユーザ（または管理者）にエラーを通知する処理を行う第３の処理の例を示すフローチャートである。

まず、前記ＨＡ構成判断部５２７が、選択可能なＨＡ構成が存在しないという結果を、ＨＡ要件設定部１２３を介して、ユーザへ通知する（Ｓ３０１）。例えば、ＨＡ要件設定部１２３は、前述の図８におけるＵＩ２３０１に示した実行結果の表示を用いて、「選択可能なＨＡ構成が存在しない」という結果をユーザに示す。その後、ユーザが前記ＨＡ要件設定部１２３を介して、ＨＡ要件を修正して再入力が実行されたか否かを判断し（Ｓ３０２）、再入力が無い場合には、該ＨＡ要件に対するＨＡ構成の実現を中断する。一方、ユーザによってＨＡ要件が再入力された場合には、再入力されたＨＡ要件に対して、ＨＡ要件を再度検証する（Ｓ３０３）。Ｓ３０３における前記再度検証を行なうために、前記処理Ｓ１０１から再実行する。

以上の処理により、マスタクラスタプログラム５２０のＨＡ構成判断部５２７は、ユーザが設定したアプリケーションＡＰ毎のＨＡ要件とシステム全体のＨＡ要件から、システム全体のＨＡ要件を満たし、かつ、優先度に従ったＨＡ構成を設定し、ＨＡ構成パターン表５２８を更新する。

図１３は、前記ＨＡ構成判断部５２７が、ＨＡ構成の設定を実施する前記Ｓ２１５に対応する第４の処理の例を示すフローチャートである。

まず、前記ＨＡ構成判断部５２７は、前記図１１のＳ２１２またはＳ２１３で決定されたＨＡ構成において、ホットスタンバイが選択されたか否かを判断する（Ｓ４０１）。ホットスタンバイが選択された場合には、待機系を起動し（Ｓ４０２）、ホットスタンバイ構成を実現した後に、系切り替え対応表５２６に起動した待機系を反映する（Ｓ４０３）。加えて、事前に設定されていたＨＡ構成がコールドスタンバイであったか否かを判断し（Ｓ４０４）、コールドスタンバイであった場合には系切り替え対応表５２６から該コールドスタンバイのエントリを削除する（Ｓ４０５）。Ｓ４０５の処理が終了した後、Ｓ４０６を実行する。

一方、上記Ｓ４０１で、決定されたＨＡ構成がホットスタンバイの追加で無い場合は、コールドスタンバイが選択されたか否かを判断する（Ｓ４０７）。コールドスタンバイが選択された場合には、系切り替え対応表５２６に該コールドスタンバイのエントリを追加する（Ｓ４０８）。その後、系切り替え対応表５２６に事前に設定されていたＨＡ構成がホットスタンバイであったか否かを判断し（Ｓ４０９）、ホットスタンバイが設定されていた場合には、ホットスタンバイで利用していた待機系を停止させ（Ｓ４１０）、系切り替え対応表５２６から該ホットスタンバイのエントリを削除する。Ｓ４１１の処理が完了した後、処理Ｓ４０６を実行する。

一方、Ｓ４０７の判定で、コールドスタンバイではなかった場合には、ＨＡ構成の変更は必要なかったことを意味するため、Ｓ４０６を実行する。ここで、異なる系切り替え手法を異なるエントリとした場合を考慮し、処理Ｓ４０３、Ｓ４０５、またはＳ４０８、Ｓ４１１で系切り替え対応表５２６を二度更新しているが、例えば、一つのアプリケーションに対して一つの系切り替え手法を適用する場合に限定すれば、系切り替え対応表５２６の書き換えは一度でよく、例えば、Ｓ４０４、Ｓ４０５、あるいは、Ｓ４０８は省略する方法を用いても良い。

続いて、Ｓ４０６では、他に設定されていないＨＡ構成があるかを判断し、存在する場合には、次のＨＡ構成の設定を実行するため、処理Ｓ４０１を実行する。一方、他に設定されていないＨＡ構成が存在しない場合には、全てのＨＡ構成の設定が完了しているため、ＨＡ構成判断部５２７はＨＡ要件設定部１２３を介して、ユーザにＨＡ構成の完了を通知し（Ｓ４０７）、ＨＡ構成の設定を終了する。ここで、Ｓ４０７によるＨＡ構成完了の通知は、例えば、前記図８のＵＩ２３０１に示すように、実行結果のウインドウ内に設定した系切り替え手法を通知する方法であってもよい。

さらに、本実施形態では、実行系と待機系がそれぞれ１台ずつである１：１構成のＨＡ構成の例を説明したが、実行系と待機系がそれぞれ複数台存在するＭ：Ｎ構成のＨＡ構成であってもよい。例えば、図６に示した系切り替え対応表５２６は、例えば、複数の現用系と待機系を関連させる表を用いることで適用可能である。

加えて、本実施形態では、コールドスタンバイとホットスタンバイの二つの系切り替え手法において、系切り替え手法を選択し、ＨＡ構成を変更する例を示したが、ゲストＯＳを正常な状態に回復を行う他の方法を用いてもよい。例えば、ゲストＯＳの再起動により回復する方法や、現用系ゲストＯＳのスナップショットを作成し、そのスナップショットを用いて回復する方法であってもよい。この場合も、前記系切り替え対応表５２６に前記回復方法を用いた場合の各要素を追加することで適応可能である。

以上、図１〜図１３に示した一連の処理を行うことで、実行系のスレーブクラスタプログラム１２０のＨＡ要件設定部１２３から入力されたＨＡ要件に基づいて、マスタクラスタプログラム５２０はＨＡ要件を満たす系切り替え手法を用いたＨＡ構成を実現することができる。加えて、システム全体のＨＡ要件や、他のゲストＯＳ上のスレーブクラスタプログラム２２０によってＨＡ要件が設定され、他のＨＡ構成が実現されている場合であっても、複数のゲストＯＳのＨＡ要件を満たす系切り替え手法を選択し、ＨＡ構成を実現することができる。

これにより、ユーザや管理者などはアプリケーションやＬＰＡＲ毎に、系切り替え先や系切り替え方法を細かく指定する必要はなく、アプリケーション毎にどのような系切り換えをしたいか、というＨＡ要件を設定するだけでよく、ホストクラスタプログラム５２０は、最適な系切り替え先と系切り替え方法を決定することができる。したがって、複数のアプリケーションやＬＰＡＲを稼動させている計算機システムにおいては、系切り替え先の計算機の論理的または物理的な構成が変更された場合でも、系切り替え先の計算機資源を不要に消費するのを防いで最適な系切り替え先を選択でき、ユーザや管理者の労力を大幅に低減できる。

また、ＨＡ構成が実現できない場合は、ＨＡ構成判断部５２７がユーザに実現できないことを通知し、再度ＨＡ要件の入力を求めることで、不十分な系切り替え手法を解消することができる。これにより、複数の系切り替え手法を有するクラスタシステムにおいて、ユーザが必要とするＨＡ要件を満たす系切り替え手法を用いたＨＡ構成を実現でき、前述の第１、第２の課題を解決することができる。これにより、系切り替え手法を自由に変更することのできる系切り替え手法を実現し、論理的または物理的に計算機の構成が変更された場合であっても、ユーザが求める高可用性に好適なクラスタ構成を提供することが可能となる。

＜第２の実施の形態＞
図１４から図１８は、本発明における第２の実施形態について表しており、第１の実施形態の一部を変更して実施することで実現される。

図１４は、第２の実施の形態のサーバ仮想化環境の物理計算機のハードウェア構成を表すブロック図で、前記第１の実施の形態の図１の一部を変更したものである。その他の構成は、前記第１の実施形態と同様である。

図１４では、前記第１実施形態の構成に対して、新たに物理計算機Ｃを追加したものである。前記物理計算機Ｃの各要素は、前記の物理計算機Ａ、Ｂと同様の構成をとる。

図１５は、図１４に示した物理計算機におけるサーバ仮想化環境のソフトウェアを主体とした第２の実施の形態の機能ブロック図である。前記第１の実施の形態の図２の一部を変更したものである。その他の構成は、前記第１の実施形態と同様である。

図１５では、物理計算機Ｃ上では、システム管理プログラム６１０を含む、管理サーバ３０を構成する。前記管理サーバ３０は、クラスタシステムを構成する各系のホストＯＳ５４０、５４０’上に新たなゲストＯＳを起動する場合に、その起動するための起動ディスクを生成する機能を有する。

図１６は、管理サーバ３０として機能する物理計算機Ｃで実行されるソフトウェアの詳細な構成を示すブロック図である。物理計算機Ｃは、クラスタシステムを構成する各系のゲストＯＳのうち、待機系となるゲストＯＳを起動するために用いられる共有ストレージ装置４０上の起動ディスク４２、４４（図４参照）を生成するサーバインストール部６１１を有するシステム管理プログラム６１０と、前記待機系用の起動ディスク４２、４４の生成を行なうために用いる各アプリケーションに対応した待機系の起動ディスクイメージ６２１、６２２を有するローカルディスクとを含む。

前記サーバインストール部６１１は、待機系設定定義６１２を有する。前記待機系設定定義６１２は、図１７に示すように、アプリケーション識別子１３０１で指定される各アプリケーション１３１１と１３１２が、ホットスタンバイによる待機系を用いるために必要となる設定として、起動ディスクを生成する元の起動ディスクイメージを表す識別子１３０４と、前記識別子１３０４で指定される起動ディスクイメージから起動ディスクを作成するためのインストール情報１３０３とを含む。

前記インストール情報１３０３は、実行系と共有するリソースに関する情報や、起動時に実行するスクリプトを含む。ここで、例えば、前者のリソースは、図１７に示される共有ディスクやＩＰアドレスの他、ＨＢＡのＷｏｒｌｄ Ｗｉｄｅ Ｎａｍｅが含まれてもよい。前記サーバインストール部６１１は、前記待機系起動ディスクイメージ６２１、６２２と前記待機系設定定義６１２を用いることで、各アプリケーションの待機系を実行するための起動ディスク４２、４４を作成し、共有ストレージ装置４０上に格納する機能を有する。

図１８は、マスタクラスタプログラム５２０上の前記ＨＡ構成判断部５２７が、前記サーバインストール部６１１を介して待機系の起動ディスクを生成し、ＨＡ構成の設定を実施する処理の例を示すフローチャートである。本フローチャートは、前記第１の実施の形態の図１３の一部を変更したものである。

図１８では、Ｓ４０１において、前記第１実施形態の図１１に示したＳ２１２またはＳ２１３で、ホットスタンバイによるＨＡ構成が選択された場合に、ＨＡ構成判断部５２７がサーバインストール部６１１に指示して、待機系が起動可能なように、待機系の起動ディスクを生成し、待機系の追加を実施する（Ｓ４１２）。その後、前記図１１のＳ４０２以降と同様に、待機系の起動を行い、系切り替え対応表を更新する。また、Ｓ４０９において、コールドスタンバイによるＨＡ構成が選択され、以前にホットスタンバイ構成を実現していた場合には、待機系を停止させた後、待機系の起動ディスクを削除することで、待機系の削除を実施する（Ｓ４１３）。その後、前記図１１に示したＳ４１１以降の処理を実施し、系切り替え対応表５２６を更新する。

以上、図１４〜図１８に示した一連の処理を行うことで、実行系のスレーブクラスタプログラム１２０のＨＡ要件設定部１２３から入力されたＨＡ要件に基づいて、マスタクラスタプログラム５２０はＨＡ要件を満たす系切り替え手法を用いたＨＡ構成を実現する際において、事前に待機系ディスクが存在せず、待機系が起動できない場合であっても、待機系を用いるホットスタンバイによる系切り替え手法を用いる場合にのみ、待機系の起動ディスク４２、４４を生成し、コールドスタンバイによる系切り替え手法を用いる場合には、不要な待機系の起動ディスクを削除することができる。これにより、本実施形態では、第１の実施形態に加えて、過剰な系切り替え手法の実現によるリソースの無駄な消費を防ぐことにより、第２の課題をさらに解決することができる。これにより、系切り替え手法を自由に変更することのできる系切り替え手法を実現し、論理的または物理的に構成が変更した場合であっても、ユーザが求める高可用性に好適なクラスタ構成を少ないリソース量で提供することが可能となる。

＜第３の実施の形態＞
図１９から図２３は、本発明における第３の実施形態について表しており、第２の実施形態の一部を変更して実施することで実現される。

図１９は、第３の実施の形態の管理サーバ３０として機能するの物理計算機Ｃで実行されるソフトウェアの詳細な構成を示すブロック図で、前記第２の実施の形態の図１６の一部を変更したものである。その他の構成は、前記第２の実施形態と同様である。

図１９では、システム管理プログラム６１０は、新たに構成管理部６３１を有する。構成管理部６３１は、クラスタシステムを構成する各物理計算機、各ホストＯＳ、各ゲストＯＳ、各アプリケーションに関する構成情報６３２を有する。ここで、構成情報とは、クラスタシステムを構成する物理計算機、ホストＯＳ、ＬＰＡＲ、ゲストＯＳ、アプリケーションが稼動あるいは停止を継続した状態で利用する物理的あるいは論理的な計算機資源の情報を指す。これらの計算機資源の情報は、変化することのない定常的な情報を指す。例えば、前記構成情報６３２は、図２０に示すように、物理計算機や論理計算機に関する情報として、計算機識別子１４０１、消費電力容量１４０２、ＣＰＵやＮＩＣ、ＨＢＡの種別を示す情報１４０３、１４０４、１４０５、物理メモリ容量１４０５を含む。加えて、ホストＯＳやゲストＯＳの実行時にのみ変化する構成情報として、電源投入状態１４０６、空きメモリ容量１４０７、利用メモリ量１４０８、さらに動作するホストＯＳ１４１０、ＬＰＡＲ１４１１、ゲストＯＳ１４１２、アプリケーション１４１３の情報も含む。前記構成管理部６３１は、前記構成情報６３２に含まれる各構成情報を収集し、計算機資源に変更があった場合に検出する機能と、その変更をＬＡＮ経由で他の物理計算機上のマスタクラスタプログラム５２０’に通知する機能とを有する。

図２１は、第３の実施の形態において、マスタクラスタプログラム５２０のＨＡ構成判断部５２７が管理サーバの構成管理部からの構成変更の通知を契機に、ＨＡ構成の検証を実行する第１の処理の例を示すフローチャートである。

図２１において、前記ＨＡ構成判断部５２７は、前記構成管理部６２１からの構成変更の通知を受けると（Ｓ５０１）、現在のＨＡ構成が適切であるかを検証する（Ｓ５０２）。この検証では、現在のＨＡ構成がＨＡ要件に適当であるかを判断するために、再度、前記第１実施形態の図１０に示した処理Ｓ１０１以降からなるＨＡ構成の設定処理を実行することで実現する。ここで、検証に用いるＨＡ要件は、各ゲストＯＳ上のスレーブクラスタプログラム１２０、２２０のＨＡ要件設定部１２３から再度ＨＡ要件定義を取得する方法であっても良いし、一度設定されたＨＡ要件定義をマスタクラスタプログラムが記憶しておき、用いる方法であっても良い。

上記検証の結果、ＨＡ構成を実現できなくなった場合には、前記図１２に記載されるエラー通知処理Ｄが実行され、ユーザに対してＨＡ構成が実現できなくなったことを通知し（Ｓ３０１）、ユーザからＨＡ要件の再入力を受け付ける（Ｓ３０２）。これにより、適切な系切り替え手法が適用できなくなった場合に、ユーザによる解決を図ることが出来る。一方で、ＨＡ構成を実現できる場合には、前記図１３に記載されるＨＡ構成の設定処理Ｅが実行され、ユーザに対してＨＡ構成が新たに設定されたことが通知される（Ｓ４０７）。ここで、前記Ｓ４０７によって通知される情報の例として、図２２、図２３に示されるＵＩ（ユーザーインターフェース）がある。

図２２に示すＵＩでは、ＨＡ構成が変更されたアプリケーションのスレーブクラスタプログラム１２０のＨＡ要件設定部１２３を介してユーザに通知するＵＩを表しており、ＵＩ２３０１に構成の変更状態を表示し、ＵＩ２４０１によってその変更が認められるかをユーザが選択可能となっている。例えば、ユーザが認めない場合には、ＨＡ要件を変更することが可能であり、この場合、前記Ｓ３０２でＨＡ要件の変更入力と同様な処理を行なうことで実現可能である。また、図２３のＵＩでは、ＨＡ構成を変更されたアプリケーション以外のスレーブクラスタプログラム１２０上のＨＡ要件設定部１２３に通知するＵＩを表しており、他のアプリケーションのＨＡ構成が変更されたことを表示するアラートとしてＵＩ２５０１を有し、図２２と同様にＳ２４０１によってそのＨＡ構成の変更を認めるかどうかのＵＩを有する。図２３のＵＩは、例えば、全てのアプリケーションに通知してもよいし、ＨＡ構成が変更されたアプリケーションと、システム全体のＨＡ要件が設定されたアプリケーションに対して通知する場合に用いてもよい。

ここで、本実施形態は、第２の実施形態を元に説明したが、サーバインストール部６１１が存在しない管理サーバ３０であっても、第２の実施形態における待機系の起動ディスクを新規追加しない場合、すなわち、待機系の起動ディスクがすでに存在する場合においても、適用可能である。加えて、構成管理部６３１が存在しない管理サーバ３０であっても、第３の実施形態においてＨＡ構成の変更を行なわない場合であれば、適用可能である。

さらに、本実施形態では、系切り替え手法の変更に基づいて、待機系の起動ディスクの追加と削除を行なう例を説明したが、ホットスタンバイの場合において、待機系が起動するサーバを変更する（待機系のサーバ移動を実行する）場合にも適用可能である。例えば、系切り替え手法をホットスタンバイからコールドスタンバイに変更して、稼動していたホットスタンバイの待機系の停止と起動ディスクの削除を行ない、新たな移動先に対応した待機系の起動ディスクと起動を行なった後に、系切り替え手法をコールドスタンバイからホットスタンバイに変更することで適用可能である。さらに、ホットスタンバイからコールドスタンバイに切り替え、待機系のゲストＯＳを、複数のホストＯＳを跨って移動させる公知技術を用いて、別の物理計算機に移動した後に、移動完了した待機系を用いて、系切り替えをコールドスタンバイからホットスタンバイに変更するような場合にもことにでも適用可能である。加えて、第１の実施形態と同様に、実行系と待機系がそれぞれ複数台存在するＭ：Ｎ構成のＨＡ構成を対象とした場合に、実行系の位置を変更する場合にも適用可能である。例えば、移動したい現用系を一時的に他の現用系あるいは待機系に系切り替えすることで、待機系とし、前記の待機系のサーバ移動を実行した後に、移動先で待機系となったサーバに他の現用系からの系切り替えによって現用系にすることで適用可能である。また、別の実現方法として、例えば、移動先の待機系を新たに追加するようなＨＡ構成の変更を行い、移動したい移動元の現用系を前記追加した待機系に系切り替えした後、待機系となった移動元の系の停止と削除を行うことでも適用可能である。

以上、図１９〜図２３に示した第３の実施形態によれば、クラスタシステムを構成するシステムの構成要素である物理計算機やホストＯＳ、ゲストＯＳ、アプリケーションの構成が物理的または論理的に変更がされた場合に、マスタクラスタプログラム５２０はＨＡ要件を満たす系切り替え手法を用いたＨＡ構成が選択可能であるかを判断し、ＨＡ構成を実現することができる。また、ＨＡ構成が実現できない場合はユーザに実現できないことを通知し、再度ＨＡ要件の入力を求めることで、不十分な系切り替え手法を解消することができる。これにより、複数の系切り替え手法を有するクラスタシステムにおいて、構成が変更された場合であっても、ユーザが必要とするＨＡ要件を満たす系切り替え手法を用いたＨＡ構成を実現でき、前述の第１、第２の課題を第２の実施形態よりもさらに広範囲なクラスタシステムにおいて解決することができる。これにより、系切り替え手法を自由に変更することのできる系切り替え手法を実現し、論理的または物理的に構成が変更した場合であっても、ユーザが求める高可用性に好適なクラスタ構成を提供することが可能となる。

＜第４の実施の形態＞
図２４から図２９は、本発明における第４の実施形態について表しており、第３の実施形態の一部を変更して実施することで実現される。

図２４は、第４の実施の形態の管理サーバとして機能する物理計算機Ｃで実行されるソフトウェアの詳細な構成を示すブロック図で、前記第３の実施の形態の図１９の一部を変更したものである。その他の構成は、前記第３の実施形態と同様である。

図２４では、システム管理プログラム６１０は、新たに統計処理部６４１を有する。統計管理部６４１は、クラスタシステムを構成する各物理計算機、各ホストＯＳ、各ゲストＯＳ、各アプリケーションに関する稼動履歴６４２を有する。前記稼動履歴６４２は、図２５に示すように、例えば、系切り換えを実施したアプリケーションやゲストＯＳ等が動作する対象の情報１５０１と、動作の内容を表す情報１５０２と、動作に要した時間や性能等の数値情報１５０３を有する。例えば、前記情報１５０１は、動作対象に関連するクラスタシステムの構成要素の識別子を含む。例えば、図２５では、計算機、ＬＰＡＲ、ホストＯＳ、ゲストＯＳ、アプリケーションの識別子がある。また、これ以外に、クラスタシステムを構成する要素を含んでもよく、例えば、ＣＰＵやＮＩＣ、ＨＢＡを含んでも良い。さらに、前記情報１５０２は、前記情報１５０１が行った動作内容を示す情報を含み、ＨＡ要件に関連する動作内容を示す情報を含む。例えば、障害時の系切り替えに要する時間や、アプリケーションの性能に関する情報として、アプリケーションの応答時間やＨＢＡによるＩＯ性能を含んでも良い。また、直接的なＨＡ要件ではなく、間接的にＨＡ要件に関連する情報を含んでもよい。ここで、間接的な情報は、ＨＡ要件に対応する情報を生成することが可能な情報であり、例えば、障害発生や、障害検出の時刻、アプリケーションの起動時刻や、それぞれの動作に要した時間がある。この場合、これらの情報を処理することで、アプリケーション停止許容時間というＨＡ要件に対する系切り替え時間の情報を取得可能である。

前記統計処理部６４１は、前記稼動履歴６４２を元に、ＨＡ要件に関連する稼動情報を定期的にマスタクラスタプログラム５２０のＨＡ構成判断部５２７に通知する。ここで、稼動履歴６４２のうちどの情報がＨＡ要件に関連する稼動情報かどうかは、事前にユーザが設定しておいてもよい。

図２６は、第４の実施の形態において、マスタクラスタプログラム５２０のＨＡ構成判断部５２７が、管理サーバ３０の統計処理部６４１からＨＡ要件に関する稼動情報の通知を受信したことを契機に、ＨＡ構成の検証を実行する処理の例を示すフローチャートである。

図２６において、前記ＨＡ構成判断部５２７は、前記統計処理部６４１からの構成変更の通知を受けると（Ｓ６０１）、現在のＨＡ構成パターン表５２８に対応する情報を稼動情報に基づいて更新し（Ｓ６０２）、現在のＨＡ構成が適切であるかを検証する（Ｓ６０３）。この検証は、前記処理Ｓ５０２と同様に、現在のＨＡ構成がＨＡ要件に適当であるかを判断するために、再度、処理Ｓ１０１以降からなるＨＡ構成の設定処理を実行することで実現する。前記ＨＡ構成の設定処理により、新たなＨＡ構成が設定される場合や、ＨＡ構成の実現が不可能な場合の処理は、前記第３実施形態に示したＳ５０２と同様であり、後者の場合、ユーザのＨＡ要件の変更によりＨＡ構成を実現することが可能である。ここで、Ｓ６０２で更新されるＨＡ構成パターン表５２８の例は図２７に示すように、新たに稼動情報に関連するＨＡ要件１２０７、１２０８、１２０９を含む。例えば、ＨＡ要件１２０７は、アプリケーションの応答性能であり、ＨＡ要件１２０８はＨＢＡによる共有ストレージ装置４０へのＩＯ性能であり、ＨＡ要件１２０９は各系切り替え手法によって系切り替えを実施した後に利用可能な最大のＣＰＵ利用率である。これ以外にも、新しく追加されるＨＡ要件は、ＨＡ構成を実現する構成要素が稼動することによって常時変動するような稼動情報であればよく、仮想サーバによって共有されているＮＩＣ、ＨＢＡの利用率であってもよい。

また、前記ＨＡ構成パターン表５２８に対応して、スレーブクラスタプログラム１２０のＨＡ要件設定部１２３のＨＡ要件定義１２４は、図２８に示すように、前記第１実施形態の図９に、ＨＡ要件１２０７、１２０８、１２０９に対応するＨＡ要件１３０６〜１３０８が新たに設定され、加えて、ＨＡ要件定義を設定するＵＩは、図２９に示すようにＵＩ２１０１において新たに指定可能となる。これにより、ユーザは稼動状態に基づいたＨＡ構成の定義を指定することが可能であり、系切り替え後に十分な性能が出る系切り替え先を有する系切り替え手法を選択することが可能である。

ここで、本実施形態は、第３の実施形態を元に説明したが、サーバインストール部６１１が存在しない管理サーバ３０であっても、第２の実施形態における待機系の起動ディスクを新規に追加しない場合であれば適用可能である。加えて、構成管理部６３１が存在しない管理サーバ３０であっても、第３の実施形態においてＨＡ構成の変更を行なわない場合であれば、適用可能である。

さらに、本実施形態では、実行系と待機系がそれぞれ１台ずつである１：１構成のＨＡ構成の例を説明したが、第１の実施形態と同様に、実行系と待機系がそれぞれ複数台存在するＭ：Ｎ構成のＨＡ構成であってもよい。さらに加えて、Ｍ：Ｎ構成のＨＡ構成の場合は、図２８に示したＨＡ要件定義表におけるＡＰ応答要求性能やＩＯ要求性能に基づいて、前記性能を満たすＨＡ構成への変更を含んでもよい。例えば、ＡＰ応答性能が不足するような現用系が存在する場合には、前記第３の実施形態に記載した現用系の移動を伴うＨＡ構成の変更方法を用いることで、性能不足の現用系を、性能を満足する位置に移動することが可能である。

加えて、本実施形態におけるＨＡ要件や稼動情報は、ゲストＯＳやアプリケーション、クラスタプログラムの動作に影響を与える情報に関するものであってもよい。例えば、ネットワークによる通信スループットであってもよい。さらに加えて、前記ＨＡ要件や稼動情報は、特定のシステムの構成要素との間に限定される情報であってもよい。例えば、ゲストＯＳやアプリケーション、クラスタプログラムが互いに通信する場合の通信スループットや、特定のストレージ装置へのＩＯ性能であってもよい。これにより、Ｗｅｂ三階層モデルのように複数のアプリケーション間での通信性能やストレージ装置へのＩＯ性能が求められる場合であっても、その性能を満たすようなＨＡ構成を実現するようなＨＡ構成の変更が実現可能である。

さらに加えて、稼動情報を利用するＨＡ要件では、直接的にアプリケーションのＨＡ構成の依存関係を示す情報を含んでも良い。例えば、各アプリケーションの系切り替え先となる物理的な位置や、系切り替え方法の依存関係がある。これにより、Ｗｅｂ三階層モデル（業務システム）でＷｅｂ層とＡＰ層が同一の仮想サーバ上の異なるゲストＯＳで動作するＨＡ構成をユーザが選択することが実現可能である。

以上、図２４〜図２９に示した第４の実施形態によれば、クラスタシステムを構成するシステムの構成要素である物理計算機やホストＯＳ、ゲストＯＳ、アプリケーションが稼動することで、ゲストＯＳやアプリケーションが得られる性能が変動するような場合であっても、マスタクラスタプログラム５２０はＨＡ要件に性能状態に関する要件を定義することで、ＨＡ要件を満たす系切り替え手法を用いたＨＡ構成が選択可能であるかを判断し、ＨＡ構成を実現することができる。これにより、複数の系切り替え手法を有するクラスタシステムにおいて、複数のアプリケーションが動作することでクラスタシステムの性能が変化した場合であっても、ユーザが必要とする性能を指定したＨＡ要件を満たす系切り替え手法を用いたＨＡ構成を実現でき、前述の第１、第２の課題を第３の実施形態よりもさらに広範囲なクラスタシステムにおいて解決することができる。これにより、系切り替え手法を自由に変更することのできる系切り替え手法を実現し、アプリケーションの負荷状態が変動した場合であっても、ユーザが求める高可用性に好適なクラスタ構成を提供することが可能となる。

＜第５の実施の形態＞
図３０から図３３は、本発明における第５の実施形態について表しており、第３の実施形態の一部を変更して実施することで実現される。

図３０は、第５の実施の形態において、スレーブクラスタプログラム１２０が設定可能なシステム全体への運用コスト面からのＨＡ要件を表したＨＡ要件定義１２４である。

図３０では、新たなシステム全体のＨＡ要件として、システム全体の消費電力量を指定する要件１６０１と、システム全体のアプリケーションのライセンス数の上限を指定する要件１６０２を示している。これらのＨＡ要件を指定するＵＩの例を図３１に示す。各ＨＡ要件は、システム全体のＨＡ要件として設定されるため、システム全体のＨＡ要件を指定するＵＩ２１０１によって指定可能である。

これらのＨＡ要件の判断は、第３の実施形態における管理サーバ３０の構成管理部６３１が管理する構成情報６３２を用いることで判断可能である。構成情報６３２は、例えば、消費電力量の要件１６０１の場合は、図３２に示すように、消費電力量１４０２と電源投入状態１４０７から判断可能であり、ライセンス数であれば、稼動アプリケーション情報１４１３から判断可能である。また、例えば、図３２の構成情報６３２に示されたように、物理計算機Ａ、ＢのＬＰＡＲ１、ＬＰＡＲ３でＡＰ１がホットスタンバイによるＨＡ構成をとるシステムにおいて、図３１に示されるように、ＡＰ２のコールドスタンバイ優先のＨＡ要件で追加し、ＡＰ２がメモリ消費を２ＧＢである場合を想定すると、消費電力の最小化が優先されるため、ＡＰ１がコールドスタンバイによるＨＡ構成を取りえる場合には、図３３に示されるように、ＡＰ１とＡＰ２が共に物理計算機Ａで稼動し、物理計算機Ｂが電源ＯＦＦ状態にあるようなコールドスタンバイによるＨＡ構成が実現される。この結果、物理計算機Ｂの消費電力を低減できるとともに、計算機資源を開放することができる。

以上、図３０〜図３３に示した第５の実施形態によれば、クラスタシステムの運用コストをシステム全体のＨＡ要件として定義することで、構成情報から運用コストによるＨＡ要件を満たす系切り替え手法を用いたＨＡ構成が選択可能であるかを判断し、ＨＡ構成を実現することができる。これにより、複数の系切り替え手法を有するクラスタシステムにおいて、運用コストを抑制した場合であっても、ユーザが必要とする性能を指定したＨＡ要件を満たす系切り替え手法を用いたＨＡ構成を実現でき、前述の第２の課題をさらに解決することができる。これにより、系切り替え手法を自由に変更することのできる系切り替え手法を実現し、アプリケーションの負荷状態が変動した場合であっても、ユーザが求める高可用性に好適なクラスタ構成を提供することが可能となる。

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

第１実施形態のサーバ仮想化環境の物理計算機のハードウェア構成を表すブロック図である。 同じく第１の実施形態を示し、物理計算機におけるサーバ仮想化環境のソフトウェアを主体とした機能ブロック図である。 同じく第１の実施形態を示し、物理計算機Ａで実行されるソフトウェアの詳細な構成を示すブロック図である。 同じく第１の実施形態を示し、共有ストレージ装置に格納された各アプリケーションと、各系状態に対応した起動ディスクを示すブロック図である。 同じく第１の実施形態を示し、系状態管理表の構成例を示す説明図である。 同じく第１の実施形態を示し、系切替対応表の構成例を示す説明図である。 同じく第１の実施形態を示し、ＨＡ構成パターン表の構成例を示す説明図である。 同じく第１の実施形態を示し、ＨＡ要件定義を設定するためのユーザーインターフェースの一例を示す画面イメージである。 同じく第１の実施形態を示し、ＨＡ要件定義の一例を示す説明図である。 同じく第１の実施形態を示し、実行系のマスタクラスタプログラムで行われるＨＡ要件定義の更新処理を示すフローチャートで、第１の処理を示す。 同じく第１の実施形態を示し、実行系のマスタクラスタプログラムで行われるＨＡ要件定義の更新処理を示すフローチャートで、第２の処理を示す。 同じく第１の実施形態を示し、実行系のマスタクラスタプログラムで行われるＨＡ要件定義のエラー通知処理を示すフローチャートで、第３の処理を示す。 同じく第１の実施形態を示し、実行系のマスタクラスタプログラムで行われるＨＡ要件の設定処理を示すフローチャートで、第４の処理を示す。 第２の実施形態を示し、サーバ仮想化環境の物理計算機のハードウェア構成を表すブロック図である。 同じく第２の実施形態を示し、物理計算機で実行するサーバ仮想化環境のソフトウェアを主体とした機能ブロック図である。 同じく第２の実施形態を示し、管理サーバ３０として機能する物理計算機Ｃで実行されるソフトウェアの詳細な構成を示すブロック図である。 同じく第２の実施形態を示し、待機系設定定義６１２の一例を示す説明図である。 同じく第３の実施形態を示し、マスタクラスタプログラムのＨＡ構成判断部が実行する、待機系の起動ディスクを生成し、ＨＡ構成の設定を行う処理の一例を示すフローチャートである。 第３の実施形態を示し、管理サーバとして機能する物理計算機Ｃで実行されるソフトウェアの詳細な構成を示すブロック図である。 同じく第３の実施形態を示し、構成情報６３２の一例を示す説明図である。 同じく第３の実施形態を示し、マスタクラスタプログラムのＨＡ構成判断部で行われるＨＡ構成の検証処理の一例を示すフローチャートである。 同じく第３の実施形態を示し、ユーザーインターフェースの一例を示す画面イメージである。 同じく第３の実施形態を示し、ユーザーインターフェースの他の例を示す画面イメージである。 第４の実施形態を示し、管理サーバとして機能する物理計算機Ｃで実行されるソフトウェアの詳細な構成を示すブロック図である。 同じく第４の実施形態を示し、稼動履歴６４２の一例を示す説明図である。 同じく第４の実施形態を示し、マスタクラスタプログラムのＨＡ構成判断部５２７で行われるＨＡ構成の検証処理の例を示すフローチャートである。 同じく第４の実施形態を示し、ＨＡ構成パターン表５２８の一例を示す説明図である。 同じく第４の実施形態を示し、ＨＡ要件定義１２４の一例を示す説明図である。 同じく第４の実施形態を示し、ユーザーインターフェースの一例を示す説明図である。 第５の実施形態を示し、スレーブクラスタプログラム１２０が設定可能なシステム全体への運用コスト面からのＨＡ要件を表したＨＡ要件定義の一例を示す説明図である。 同じく第５の実施形態を示し、ユーザーインターフェースの一例を示す画面イメージである。 同じく第５の実施形態を示し、構成管理部６３１が管理する構成情報６３２の一例を示す説明図である。 同じく第５の実施形態を示し、構成管理部６３１が管理する構成情報６３２の一例を示し、ＨＡ構成の変更後を示す説明図である。

符号の説明

１１０、２１０ アプリケーションプログラム
１２０ スレーブクラスタプログラム
１２１ アプリケーション監視部
１２２ 系切り替え実行部
１２３ ＨＡ要件設定部
１３０ ゲストＯＳ
５１０ サーバ仮想化プログラム
５１１ ゲストＯＳ制御部
５１２ ゲストＯＳ監視部
５２０ マスタクラスタプログラム
５４０ ホストＯＳ
５２２ 系状態監視部
５２４ ホストＯＳ監視部
５２５ 系切り替え制御部
５２７ ＨＡ構成判断部

Claims (14)

1. ゲストＯＳ上でアプリケーションプログラムを実行する複数の系を提供する仮想化部を備えた少なくとも一つの物理計算機と、
   前記系のゲストＯＳまたはアプリケーションプログラムを監視して、前記ゲストＯＳまたはアプリケーションプログラムに障害が発生したときには、前記系を他の系に切り替えるクラスタシステムの構成方法であって、
   前記物理計算機は、
   前記ゲストＯＳ上で稼働して前記アプリケーションの稼働状態を監視する第１のクラスタ管理部と、前記第１のクラスタ管理部から前記アプリケーションの稼働状態を受け付けて障害発生時に前記アプリケーションプログラムを他の系に切り替える第２のクラスタ管理部と、を有し、
   前記第２のクラスタ管理部が、前記系毎に、障害発生時に切り替え可能な他の系と、予め設定した複数の系切り換え手法のうちのいずれかひとつを、系切り替えの候補として高可用性構成パターンに設定するステップと、
   前記第２のクラスタ管理部が、前記系毎に、障害発生時に必要とする切り替え要件を高可用性要件として設定するステップと、
   前記第２のクラスタ管理部が、前記高可用性構成パターンに設定された系切り替え手法のうち、前記高可用性要件を満たす系切り替え手法を選択するステップと、
   前記第２のクラスタ管理部が、前記高可用性要件を満たす系切り替え手法がある場合には、前記高可用性構成パターンから前記選択された系切り替え手法を実現可能で、かつ、前記高可用性要件を満たす他の系を、当該系の系切り替え先として設定するステップと、
   を含むことを特徴とするクラスタシステムの構成方法。
2. 前記請求項１に記載のクラスタシステムの構成方法において、
   前記高可用性要件は、系切り替え時のアプリケーションプログラムの停止時間または系切り替え手法の少なくとも一つを含むことを特徴とするクラスタシステムの構成方法。
3. 前記請求項１に記載のクラスタシステムの構成方法において、
   前記高可用性要件を満たす他の系を、当該系の系切り替え先として設定するステップは、
   前記系のゲストＯＳに前記設定された系切り替え手法と系切り替え先とを通知するステップ、
   を含むことを特徴とするクラスタシステムの構成方法。
4. 前記請求項１に記載のクラスタシステムの構成方法において、
   前記高可用性要件を満たす系切り替え手法を選択するステップは、
   前記選択可能な系切り替え手法が存在しない場合には、前記ゲストＯＳに選択可能な系切り替え手法が存在しないことを通知するステップを含むことを特徴とするクラスタシステムの構成方法。
5. 前記請求項４に記載のクラスタシステムの構成方法において、
   前記選択可能な系切り替え手法が存在しない場合には、前記高可用性要件を再度設定するステップと、
   前記再度設定された高可用性要件を満たす系切り替え手法を再度選択し直すステップと、
   を含むことを特徴とするクラスタシステムの構成方法。
6. 前記請求項１に記載のクラスタシステムの構成方法において、
   前記障害発生時に必要とする切り替え要件を高可用性要件として設定するステップは、
   複数の高可用性要件を指定する場合に、各高可用性要件の優先度を設定するステップを含み、
   前記高可用性要件を満たす系切り替え手法を選択するステップは、
   前記優先度に基づいて前記高可用性構成パターンから系切り替え手法を選択することを特徴とするクラスタシステムの構成方法。
7. 前記請求項１に記載のクラスタシステムの構成方法において、
   前記障害発生時に必要とする切り替え要件を高可用性要件として設定するステップは、
   前記各系のアプリケーションプログラムについて系切り替えの優先度を設定するステップを含み、
   前記高可用性要件を満たす系切り替え手法を選択するステップは、
   前記アプリケーションプログラムの優先度に基づいて、優先度の高いアプリケーションプログラムに対する高可用性を、前記優先度の低いアプリケーションプログラムに対する高可用性要件よりも優先して、系切り替え手法を選択することを特徴とするクラスタシステムの構成方法。
8. 前記請求項１に記載のクラスタシステムの構成方法において、
   前記切り替え要件を高可用性要件として設定するステップは、
   新たに設定された高可用性要件で既存の高可用性要件を更新するステップを含み、
   前記高可用性要件を満たす系切り替え手法を選択するステップは、
   前記更新された高可用性要件に基づいて前記高可用性構成パターンから系切り替え手法を選択することを特徴とするクラスタシステムの構成方法。
9. 前記請求項８に記載のクラスタシステムの構成方法において、
   前記系切り替え手法は、ホットスタンバイ及びコールドスタンバイを含み、
   前記系切り替え手法がホットスタンバイからコールドスタンバイへ変更されたときには、系切り替え先で当該系を起動するための起動ディスクを生成するステップを、さらに含むことを特徴とするクラスタシステムの構成方法。
10. 前記請求項１に記載のクラスタシステムの構成方法において、
    前記障害発生時に必要とする切り替え要件を高可用性要件として設定するステップは、
    前記物理計算機全体の運用コストに関する要件を含むことを特徴とするクラスタシステムの構成方法。
11. 前記請求項１に記載のクラスタシステムの構成方法において、
    前記第２のクラスタ管理部が、前記物理計算機の物理的または論理的な構成を取得して構成情報に格納するステップと、
    前記第２のクラスタ管理部は、前記構成情報が変化したことを判定するステップと、
    をさらに含み、
    前記高可用性要件を満たす系切り替え手法を選択するステップは、
    前記構成情報が変化したときには、前記高可用性要件を満たす系切り替え手法を再度選択し、
    前記高可用性要件を満たす他の系を、当該系の系切り替え先として設定するステップは、
    前記選択された系切り替え手法の対象となる系切り替え先が、前記構成情報が変化する以前と異なる場合には、新たな系切り替え先を設定するステップを含むことを特徴とするクラスタシステムの構成方法。
12. 前記請求項１１に記載のクラスタシステムの構成方法において、
    前記第２のクラスタ管理部が、全ての系の稼動情報を稼動履歴として取得するステップと、
    前記第２のクラスタ管理部が、前記稼動履歴から前記高可用性要件に対応する稼動情報を抽出するステップと、
    稼動情報が変化したときには前記高可用性構成パターンを更新するステップと、
    をさらに含み、
    前記高可用性要件を満たす他の系を、当該系の系切り替え先として設定するステップは、
    前記更新された高可用性構成パターンに基づいて、前記高可用性要件を満たす系切り替え先を再度選択することを特徴とするクラスタシステムの構成方法。
13. 物理計算機上で複数のゲストＯＳを稼動させる仮想化部と、
    前記各ゲストＯＳ上で稼動するアプリケーションプログラムからなる複数の系と、
    前記アプリケーションプログラムまたはゲストＯＳを監視して、障害発生時に前記アプリケーションプログラムを他の系に切り替えるクラスタ管理部と、を備えたクラスタシステムにおいて、
    前記クラスタ管理部は、
    前記ゲストＯＳ上で稼働して前記アプリケーションの稼働状態を監視する第１のクラスタ管理部と、前記第１のクラスタ管理部から前記アプリケーションの稼働状態を受け付けて障害発生時に前記アプリケーションプログラムを他の系に切り替える第２のクラスタ管理部と、を有し、
    前記第２のクラスタ管理部は、
    前記系毎に設定されて障害発生時に必要とする切り替え要件を高可用性要件として設定する高可用性要件設定部と、
    前記系毎に、障害発生時に切り替え可能な他の系と、予め設定した複数の系切り換え手法のうちのいずれかひとつを、系切り替えの候補として高可用性構成パターンに設定する高可用性構成パターン設定部と、
    前記高可用性構成パターンに設定された系切り替えの候補のうち、前記高可用性要件を満たす系切り替え手法と、前記高可用性要件を満たす他の系を、当該系の系切り替え先として選択する高可用性構成判定部と、を備え、
    前記第２のクラスタ管理部は、
    前記高可用性構成判定部が選択した系切り替え手法及び系切り替え先に基づいて前記系切り替えを行うことを特徴とするクラスタシステム。
14. 前記請求項１３に記載のクラスタシステムにおいて、
    前記物理計算機に接続された管理サーバをさらに備え、
    前記管理サーバは、
    前記物理計算機の物理的または論理的な構成を取得して構成情報に格納する構成管理部を有し、
    前記構成管理部は、前記構成情報が変化したときに前記高可用性構成判定部に構成情報の変化を通知し、
    前記高可用性構成判定部は、前記通知に基づいて高可用性構成パターンを更新し、前記高可用性要件を満たす系切り替え手法と、前記高可用性要件を満たす系切り替え先を更新することを特徴とするクラスタシステム。