JP2013196484A - クラスタシステムの構成を管理する構成管理装置 - Google Patents

Abstract

【課題】リソースを有効利用しながら安定したクラスタシステムを構成可能とする。
【解決手段】実施形態によれば、構成管理装置の検出手段は、複数の物理計算機でそれぞれ動作する論理計算機に割り当てられるリソースの増加を監視して、割当リソース数が増加した第１の論理計算機を検出する。第１の論理計算機が稼動系の論理計算機である場合、算出手段は、第１の論理計算機の第１の割当リソース数及び当該第１の論理計算機に対応する待機系の第２の論理計算機の第２の割当リソース数に基づき、当該第２の論理計算機のサービス引き継ぎ時の不足リソース数を算出する。移動計算機決定手段は、この不足リソース数を補うのに必要な予備リソース数を有する物理計算機を、第２の論理計算機を移動対象論理計算機とする場合の移動先物理計算機として決定する。移動手段は、移動対象論理計算機を移動先物理計算機へ移動させる。
【選択図】図１

Description

本発明の実施形態は、クラスタシステムの構成を管理する構成管理装置に関する。

従来から、ハードウェアリソースを分割し、各々を独立した１台の計算機のように利用できる仮想化技術として、論理パーティションやハイパーバイザによる仮想化が知られている。これら仮想化技術においては、ハードウェアリソースを有効に利用できるよう、計算機に割り当てられるリソースの増減といったワークロード管理の仕組みが提供されている。

特開２００６−３２３８７２号公報 特開２００２−０４１３０４号公報

高可用性を必要とするシステムでは、論理（仮想）計算機においても複数の計算機が相互に接続されたクラスタシステムが構成されている。クラスタシステムにおいても、ワークロード管理機能が適用されている場合、必要に応じてリソースの増減が行われる。

ところが、クラスタシステムでは、サービスを実行している稼働系計算機と待機している待機系計算機とが存在し、稼働系計算機と待機系計算機とでは負荷状況が全く異なる。このため、稼動系計算機に障害が発生した結果、当該稼動系計算機で実行されていたサービスを待機系計算機に引き継がせるフェイルオーバ時に、当該サービスの開始に必要なリソースの不足が発生するといったクラスタ環境ならではの問題が発生する可能性がある。

本発明が解決しようとする課題は、リソースを有効利用しながら安定したクラスタシステムを構成することができる構成管理装置を提供することにある。

実施形態によれば、１つ以上の論理計算機がそれぞれ動作する複数の物理計算機の構成を管理する構成管理装置は、リソース管理テーブルと、クラスタノード管理テーブルと、検出手段と、特定手段と、算出手段と、移動計算機決定手段と、移動手段とを具備する。前記リソース管理テーブルは、前記複数の物理計算機の各々について、当該物理計算機上の前記論理計算機に割り当てられているリソース数及び当該物理計算機における予備リソース数を保持する。前記クラスタノード管理テーブルは、前記複数の物理計算機でそれぞれ動作する論理計算機のうち、クラスタシステムを構成し、サービスを実行する稼動系の論理計算機の情報、及び前記クラスタシステムを構成し、前記稼動系の論理計算機の障害時に前記サービスを引き継ぐ待機系の論理計算機の情報を前記サービス毎に保持する。前記検出手段は、前記複数の物理計算機でそれぞれ動作する論理計算機に割り当てられるリソースの増加を監視して、割当リソース数が増加した第１の論理計算機を検出する。前記特定手段は、前記第１の論理計算機が稼動系の論理計算機であることが前記クラスタノードテーブルによって示されている場合、前記第１の論理計算機に対応する待機系の第２の論理計算機を前記クラスタノードテーブルに基づいて特定する。前記算出手段は、前記リソース管理テーブルから取得される前記第１の論理計算機の第１の割当リソース数及び前記第２の論理計算機の第２の割当リソース数に基づき、前記第２の論理計算機のサービス引き継ぎ時の不足リソース数を算出する。前記移動計算機決定手段は、前記不足リソース数が、前記第２の論理計算機が動作する第１の物理計算機の予備リソース数に満たない場合、当該不足リソース数を補うのに必要な予備リソース数を有する第２の物理計算機を前記リソース管理テーブルに基づいて探索し、当該探索に成功した場合、前記第２の物理計算機を、前記第２の論理計算機を移動対象論理計算機とする場合の移動先物理計算機として決定する。前記移動手段は、前記移動対象論理計算機を前記移動先物理計算機へ移動させる。

実施形態に係る計算機システムの主として機能構成を示すブロック図。 同実施形態で適用されるリソース管理テーブルのデータ構造の一例を示す図。 同実施形態で適用されるクラスタノード管理テーブルのデータ構造の一例を示す図。 同実施形態で適用されるリソース調整処理を説明するためのフローチャートの一部を示す図。 同フローチャートの残りを示す図。 同実施形態におけるリソース管理テーブルの更新例を示す図。 同実施形態におけるリソース管理テーブルの更新例を示す図。 同実施形態の変形例で適用されるリソース調整処理を説明するためのフローチャートの一部を示す図。

以下、実施の形態につき図面を参照して説明する。
図１は実施形態に係る計算機システムの主として機能構成を示すブロック図である。

図１に示す計算機システムは、複数の物理計算機、例えば３台の物理計算機ＰＣ１〜ＰＣ３と、構成管理サーバ２０と、物理計算機ＰＣ１〜ＰＣ３及び構成管理サーバ２０を接続するネットワーク３０とから構成される。

物理計算機ＰＣ１〜ＰＣ３には、それぞれ１つ以上の論理計算機が構築される。つまり物理計算機ＰＣ１〜ＰＣ３上では、それぞれ１つ以上の論理計算機が動作する。図１の状態では、物理計算機ＰＣ１上で２つの論理計算機ＬＣ１１，ＬＣ１２が、物理計算機ＰＣ２上で２つの論理計算機ＬＣ２１，ＬＣ２２が、そして物理計算機ＰＣ３上で３つの論理計算機ＬＣ３１〜ＬＣ３３が、それぞれ動作する。

論理計算機ＬＣ１１，ＬＣ２１，ＬＣ３１，ＬＣ３２はクラスタシステムを構成する。本実施形態では、論理計算機ＬＣ１１，ＬＣ３１の一方は、稼動系論理計算機として高可用性（ＨＡ：High Availability）サービスＳ１を実行する。論理計算機ＬＣ２１，ＬＣ３２の一方は、稼動系論理計算機としてＨＡサービスＳ２を実行する。

クラスタシステムは、クラスタ管理システム１０の管理の下で動作する。クラスタ管理システム１０は、物理計算機ＰＣ１〜ＰＣ３にそれぞれ設けられたクラスタ管理機構ＣＭ１〜ＣＭ３が相互に通信をすることによって実現される。つまりクラスタ管理システム１０は、論理的に物理計算機ＰＣ１〜ＰＣ３にまたがって存在する。クラスタ管理システム１０は、クラスタシステムを構成する各論理計算機を例えばＨＡサービス毎に、クラスタノードとして管理する。クラスタ管理システム１０はＨＡサービスを運用するための機能を提供する。例えば、ＨＡサービスの状態通知、クラスタノードのサービス状態の管理、稼動系−待機系の切り替えのような機能が挙げられる。

構成管理サーバ２０は、構成管理機構２１、リソース管理テーブル２２、クラスタノード管理テーブル２３、リソース変更通知部２４、リソース情報管理部２５、クラスタノード探索部２６及びリソース調整管理部２７を備えている。

構成管理機構２１は、物理計算機ＰＣ１〜ＰＣ３及び当該物理計算機ＰＣ１〜ＰＣ３上の各論理計算機を管理する。構成管理機構２１はまた、物理計算機ＰＣ１〜ＰＣ３及び論理計算機を運用するための機能を提供する。例えば、物理計算機上への論理計算機の構築、ＣＰＵやメモリといったリソースの増加、リソース変更時の通知、リソースの論理計算機への割り当ての管理、論理計算機の物理計算機間の移動のような機能が挙げられる。

リソース管理テーブル２２は、物理計算機毎に、当該物理計算機上の論理計算機に割り当てられているリソース数と、当該物理計算機における予備リソース数とを保持する。図２は、本実施形態で適用されるリソース管理テーブル２２のデータ構造の一例を示す。リソースは、一般にＣＰＵ及びメモリである。しかし、以下の説明では簡略化のために、リソースがＣＰＵであり、且つ全ＣＰＵが同一の性能であるものとする。この場合、リソース数ＮはＣＰＵ数Ｎに一致する。なお、全ＣＰＵが同一の性能ではない場合には、ＣＰＵ性能に応じてＣＰＵ数を正規化すればよい。

クラスタノード管理テーブル２３は、ＨＡサービス毎に、当該ＨＡサービスの実行に係わるクラスタノードの情報、つまり稼動系論理計算機及び待機系論理計算機の情報を保持する。図３は、本実施形態で適用されるクラスタノード管理テーブル２３のデータ構造の一例を示す。

リソース変更通知部２４は、構成管理機構２１の管理による論理計算機のリソース増減を検出する。リソース変更通知部２４は、リソース増減の検出に応じて、その旨をリソース情報管理部２５に通知し、且つリソース増減が発生した論理計算機をリソース調整管理部２７に通知する。

リソース情報管理部２５は、各物理計算機のリソース情報を構成管理機構２１に要求する。リソース情報管理部２５は、この要求によって取得したリソース情報に基づいて、当該物理計算機の予備リソース数と当該物理計算機上の論理計算機の割当リソース数とをリソース管理テーブル２２に設定する。

クラスタノード探索部２６は、クラスタシステムを構成する各クラスタのクラスタノード情報をクラスタ管理システム１０に要求する。クラスタノード探索部２６は、この要求によってクラスタノード情報を取得することにより、当該クラスタノード情報の示す稼動系論理計算機及び待機系論理計算機をＨＡサービス毎に探索する。クラスタノード探索部２６は、この探索結果に基づいて、ＨＡサービス毎に、当該ＨＡサービスに対応する各論理計算機と当該論理計算機の状態（稼動系／待機系）をクラスタノード管理テーブル２３に設定する。

リソース調整管理部２７は、リソース変更通知部２４により通知された論理計算機（以下、該当論理計算機と称する）のリソース増減に基づき、フェイルオーバ時にリソース不足が発生する待機系論理計算機を検出する。リソース調整管理部２７は、検出した待機系論理計算機のリソース不足を解消するためのリソース調整を、論理計算機の物理計算機間の移動により実現する。このリソース調整のため、リソース調整管理部２７は、算出部２７１、移動計算機決定部２７２及び移動部２７３を備えている。

算出部２７１は、該当論理計算機が例えば稼動系論理計算機の場合に、リソース管理テーブル２２から該当論理計算機の割当リソース数及び該当論理計算機に対応する待機系論理計算機の割当リソース数を取得する。算出部２７１は取得した両割当リソース数に基づき、待機系論理計算機のフェイルオーバ時の不足リソース数（＝該当論理計算機の割当リソース数−待機系論理計算機の割当リソース数）を算出する。

移動計算機決定部２７２は、待機系論理計算機の不足リソース数と当該待機系論理計算機が動作する物理計算機の予備リソース数とが、
不足リソース数＞予備リソース数
の場合、当該待機系論理計算機が動作する物理計算機では必要なリソース数を確保できないために、当該待機系論理計算機の別の物理計算機への移動が必要であると決定する。この場合、移動計算機決定部２７２は、上記待機系論理計算機の割当リソース数及び不足リソース数の和と、リソース管理テーブルから取得される物理計算機の予備リソース数とが、
（待機系論理計算機の割当リソース数＋待機系論理計算機の不足リソース数）≦予備リソース数
となる何れかの物理計算機を、必要なリソース数を確保できる物理計算機として決定する。ここで、待機系論理計算機の割当リソース数＋待機系論理計算機の不足リソース数は、該当論理計算機の割当リソース数に一致する。

移動計算機決定部２７２は、決定した物理計算機を、上記待機系論理計算機の移動先の物理計算機として設定する。また移動計算機決定部２７２は、上記待機系論理計算機を移動対象論理計算機として設定する。
移動部２７３は、移動計算機決定部２７２による設定に従い、移動対象論理計算機の移動先物理計算機への移動を構成管理機構２１に要求することにより、移動対象論理計算機を移動させる。

次に、本実施形態の具体的な動作について、構成管理サーバ２０によるリソース調整処理を例に、図４乃至図７を参照して説明する。図４は本実施形態で適用されるリソース調整処理を説明するためのフローチャートの一部を示し、図５は当該フローチャートの残りを示す。図６及び図７は、本実施形態におけるリソース管理テーブル２２の更新例を示す。

以下の説明では、割当リソース数をＮＡＲ、予備リソース数をＮＰＲ、不足リソース数をＮＳＲと、それぞれ表記する。また、例えば物理計算機ＰＣｉ（ｉ＝１，２，３）上の論理計算機ＬＣｉｊ（ｊ＝１，２，３）の割当リソース数をＮＡＲｉｊ、当該論理計算機ＬＣｉｊの不足リソース数をＮＳＲｉｊと表記する。また、物理計算機ＰＣｉの予備リソース数をＮＰＲｉと表記する。

まず、リソース変更通知部２４は検出手段として機能して、構成管理機構２１の管理による論理計算機ＬＣｉｊ（ｉ＝１，２，３，ｊ＝１，２，３）のリソース増減を監視し（ステップ４０１）、リソース増減が発生したかを判定する（ステップ４０２）。本実施形態では、図２に示すリソース管理テーブル２２及び図３に示すクラスタノード管理テーブル２３の各状態で、論理計算機ＬＣ３３の割当リソース数ＮＡＲ３３が５から９に４増加し、これにより当該論理計算機ＬＣ３３が動作する物理計算機ＰＣ３の予備リソース数ＮＰＲ３が５から１に４減少したものとする。

この場合、リソース変更通知部２４は、リソース増減の発生を検出して（ステップ４０２のＹｅｓ）、その旨をリソース情報管理部２５に通知し、且つリソース増減が発生した論理計算機ＬＣ３３（ＬＣｉｊ＝ＬＣ３３）を該当論理計算機としてリソース調整管理部２７に通知する（ステップ４０３）。

リソース情報管理部２５は、リソース変更通知部２４による通知に応じて、該当論理計算機ＬＣ３３が動作する物理計算機ＰＣ３のリソース情報を構成管理機構２１に要求する。リソース情報管理部２５は、この要求によって構成管理機構２１から物理計算機ＰＣ３のリソース情報を取得すると、当該リソース情報に基づき、リソース管理テーブル２２内の物理計算機ＰＣ３の予備リソース数ＮＰＲ３及び該当論理計算機ＬＣ３３の割当リソース数ＮＡＲ３３を更新する。これにより、リソース管理テーブル２２は、図２に示す状態から図６（ａ）に示す状態に更新される。

リソース調整管理部２７は、該当論理計算機ＬＣ３３の通知を受け取ると、該当論理計算機ＬＣ３３が稼動系論理計算機であるかをクラスタノード管理テーブル２３に基づいて判定する（ステップ４０４）。ここでは、該当論理計算機ＬＣ３３（ＬＣij＝ＬＣ３３）は、図３のクラスタノード管理テーブル２３から明らかなように、クラスタノードでなく、したがって稼動系論理計算機でもない（ステップ４０４のＮｏ）。この場合、リソース変更通知部２４により論理計算機のリソース増減が再び監視される（ステップ４０１）。

やがて、図６（ａ）に示すリソース管理テーブル２２及び図３に示すクラスタノード管理テーブル２３の各状態で、論理計算機ＬＣ２１の割当リソース数ＮＡＲ２１が３から４に１増加し、これにより当該論理計算機ＬＣ２１が動作する物理計算機ＰＣ２の予備リソース数ＮＰＲ２が５から４に１減少したものとする。この場合、論理計算機ＬＣ２１の増減の発生が検出される（ステップ４０２のＹｅｓ）。すると、論理計算機ＬＣ２１（ＬＣｉｊ＝ＬＣ２１）が該当論理計算機としてリソース調整管理部２７に通知される（ステップ４０３）。また、リソース管理テーブル２２が、図６（ａ）に示す状態から図６（ｂ）に示す状態に更新される。

該当論理計算機ＬＣ２１（ＬＣｉｊ＝ＬＣ２１）は図３のクラスタノード管理テーブル２３から明らかなようにクラスタノードであり、ＨＡサービスＳ２を実行している稼動系論理計算機である（ステップ４０４のＹｅｓ）。この場合、リソース調整管理部２７は特定手段として機能して、クラスタノード管理テーブル２３に基づき、稼動系論理計算機ＬＣ２１に対応する待機系論理計算機ＬＣｒｓを特定する（ステップ４０５）。ここでは、稼動系論理計算機ＬＣ２１に対応する待機系論理計算機ＬＣｒｓはＬＣ３２である。

リソース調整管理部２７の算出部２７１は、図６（ｂ）に示すリソース管理テーブル２２から、稼動系論理計算機ＬＣ２１の割当リソース数ＮＡＲ２１（ＮＡＲｉｊ＝ＮＡＲ２１）及び待機系論理計算機ＬＣ３２の割当リソース数ＮＡＲ３２（ＮＡＲｒｓ＝ＮＡＲ３２）を取得する。そして算出部２７１は、待機系論理計算機ＬＣ３２のフェイルオーバ時の不足リソース数ＮＳＲ３２（ＮＳＲｒｓ＝ＮＳＲ３２）を
ＮＳＲ３２（＝ＮＳＲｉｊ）＝ＮＡＲｉｊ−ＮＡＲｒｓ
＝ＮＡＲ２１−ＮＡＲ３２
により算出する（ステップ４０６）。

するとリソース調整管理部２７の移動計算機決定部２７２は、図６（ｂ）に示すリソース管理テーブル２２から、待機系論理計算機ＬＣ３２が動作する物理計算機ＰＣ３（ＰＣｒ＝ＰＣ３）の予備リソース数ＮＰＲ３（ＮＰＲｒ＝ＮＰＲ３）を取得する。そして移動計算機決定部２７２は、待機系論理計算機ＬＣ３２（ＬＣｒｓ＝ＬＣ３２）の不足リソース数ＮＳＲ３２（ＮＳＲｒｓ＝ＮＳＲ３２）と物理計算機ＰＣ３（ＰＣｒ＝ＰＣ３）の予備リソース数ＮＰＲ３（ＮＰＲｒ＝ＮＰＲ３）とが、
ＮＳＲ３２＞ＮＰＲ３
であるかを判定する（ステップ４０７）。

もし、ステップ４０７の判定がＮｏであるならば、移動計算機決定部２７２は、稼動系論理計算機ＬＣ２１に障害が発生しても、待機系論理計算機ＬＣ３２はＨＡサービスの開始に必要な数のリソースを確保してフェイルオーバできると判断する。この場合、待機系論理計算機ＬＣ３２を別の物理計算機に移動することによるリソース調整は不要であることから、移動計算機決定部２７２は当該待機系論理計算機ＬＣ３２の移動不要を決定する。すると、リソース変更通知部２４により論理計算機のリソース増減が再び監視される（ステップ４０１）。

本実施形態では、図６（ｂ）のリソース管理テーブル２２から明らかなように、稼動系論理計算機ＬＣ２１の割当リソース数ＮＡＲ２１は４、待機系論理計算機ＬＣ３２の割当リソース数ＮＡＲ３２は２である。したがって算出部２７１は、待機系論理計算機ＬＣ３２の不足リソース数ＮＳＲ３２として、ＮＡＲｉｊ−ＮＡＲｒｓ＝ＮＡＲ２１−ＮＡＲ３２＝４−２＝２を算出する（ステップ４０６）。この不足リソース数ＮＳＲ３２＝２は、図６（ｂ）のリソース管理テーブル２２の示す物理計算機ＰＣ３の予備リソース数ＮＰＲ３＝１よりも大きい（ステップ４０７のＹｅｓ）。つまり、不足リソース数ＮＳＲ３２＝２を、待機系論理計算機ＬＣ３２が動作する物理計算機ＰＣ３の予備リソース数ＮＰＲ３＝１で補うことはできない。この場合、待機系論理計算機ＬＣ３２を別の物理計算機に移動することによるリソース調整が必要であることから、移動計算機決定部２７２は当該待機系論理計算機ＬＣ３２の移動を決定する（ステップ４０８）。

そこで移動計算機決定部２７２は、まず待機系論理計算機ＬＣ３２を移動対象論理計算機として設定する（ステップ５０１）。そして移動計算機決定部２７２は、以下の手順で移動対象論理計算機の移動先物理計算機を決定する。

まず移動計算機決定部２７２は、図６（ｂ）に示すリソース管理テーブル２２に基づいて、条件Ｃ１を満たす物理計算機ＰＣｕ（ｕ≠ｒ）を探索する（ステップ５０２）。条件Ｃ１は
（ＮＡＲｒｓ＋ＮＳＲｒｓ）≦ＮＰＲｕ
である。

ここで、ＮＡＲｒｓは待機系論理計算機ＬＣ３２の割当リソース数ＮＡＲ３２＝２であり、ＮＳＲｒｓはステップ４０６で算出された当該待機系論理計算機ＬＣ３２の不足リソース数ＮＳＲ３２＝２である。したがって待機系論理計算機ＬＣ３２のフェイルオーバ時に必要なリソース数ＮＡＲｒｓ＋ＮＳＲｒｓ＝ＮＡＲ３２＋ＮＳＲ３２（＝稼動系論理計算機ＬＣｉｊ＝ＬＣ２１の割当リソース数ＮＡＲｉｊ＝ＮＡＲ２１）は４である。この場合、物理計算機ＰＣ１の予備リソース数ＮＰＲｕ（＝ＮＰＲ１）は５であり、物理計算機ＰＣ２の予備リソース数ＮＰＲｕ（＝ＮＰＲ２）は４であことから、いずれも条件Ｃ１を満たす。

よって移動計算機決定部２７２は、条件Ｃ１を満たす物理計算機ＰＣｕとして、物理計算機ＰＣ１及びＰＣ２の２つを見つけることができる。ここで、物理計算機ＰＣ２は、図３に示すクラスタノード管理テーブル２３から明らかなように、移動対象の待機系論理計算機ＬＣ３２に対応する稼動系論理計算機ＬＣ２１が動作している物理計算機である。このため、物理計算機ＰＣ２に待機系論理計算機ＬＣ３２を移動したならば、当該物理計算機ＰＣ２に障害が発生した場合に、待機系論理計算機ＬＣ３２へのフェイルオーバが困難となる。

そこで本実施形態では、物理計算機の障害発生に備え、待機系論理計算機ＬＣ３２（ＬＣｒｓ＝ＬＣ３２）の移動先物理計算機ＰＣｕの候補から、上記稼動系論理計算機ＬＣ２１（ＬＣｉｊ＝ＬＣ２１）が動作している物理計算機ＰＣ２（ＰＣｕ＝ＰＣ２）は除外される。つまり移動計算機決定部２７２は、条件Ｃ１を満たす物理計算機ＰＣｕ（ｕ≠ｒ，ｕ≠ｉ）としてＰＣ１（ＰＣｕ＝ＰＣ１）を選択する。

このように条件Ｃ１を満たす物理計算機ＰＣ１（ＰＣｕ＝ＰＣ１）の探索に成功した場合（ステップ５０３のＹｅｓ）、移動計算機決定部２７２は当該物理計算機ＰＣ１を、移動対象論理計算機の移動先物理計算機として設定する（ステップ５０４）。なお上記ステップ５０１における待機系論理計算機ＬＣ３２の移動対象論理計算機としての設定は、ステップ５０３の判定がＹｅｓの場合に有効となる。このことは、待機系論理計算機ＬＣ３２の移動対象論理計算機としての設定が、ステップ５０３の判定がＹｅｓの場合に実行されることと等価である。よって、この設定が、ステップ５０３の判定がＹｅｓの場合に実行されても構わない。

移動部２７３は物理計算機ＰＣ１が移動先物理計算機として設定されると（ステップ５０４）、この設定に応じて、移動対象論理計算機の移動先物理計算機への移動を構成管理機構２１に要求することにより、待機系論理計算機ＬＣ３２を物理計算機ＰＣ１へ移動させる（ステップ５０５）。

するとリソース情報管理部２５は、リソース管理テーブル２２を、図６（ｂ）に示す状態から、図６（ｃ）に示す状態に更新する。図６（ｃ）において矢印６０は、論理計算機ＬＣ３２の物理計算機ＰＣ３から物理計算機ＰＣ１への移動を表す。

このように本実施形態によれば、稼動系論理計算機ＬＣ２１の割当リソース数が増加したために当該稼動系論理計算機ＬＣ２１に対応する待機系論理計算機ＬＣ３２のフェイルオーバ時にリソースが不足することが予測される場合、そのリソース不足の発生を、当該待機系論理計算機ＬＣ３２の物理計算機ＰＣ３から物理計算機ＰＣ１への移動により未然に防止できる。しかも、サービスを実行していない待機系論理計算機ＬＣ３２の移動によるリソース調整であるため、稼動系論理計算機が実行しているサービスに影響を与えることなく、フェイルオーバ時のリソース不足を防止し、クラスタシステムを安定稼働させることができる
次に、条件Ｃ１を満たす物理計算機ＰＣｕの探索に失敗した場合について、具体例を挙げて説明する。
まず、図２に示すリソース管理テーブル２２及び図３に示すクラスタノード管理テーブル２３の各状態で、論理計算機ＬＣ３３の割当リソース数ＮＡＲ３３が５から７に２増加し、これにより物理計算機ＰＣ３の予備リソース数ＮＰＲ３が５から３に２減少したものとする。この場合、リソース管理テーブル２２は、図２に示す状態から図７（ａ）に示す状態に更新される。

次に、図７（ａ）に示すリソース管理テーブル２２及び図３に示すクラスタノード管理テーブル２３の各状態で、ＨＡサービスＳ１を実行している稼動系論理計算機ＬＣ１１の割当リソース数ＮＡＲ１１が５から６に１増加し、これにより物理計算機ＰＣ１の予備リソース数ＮＰＲ１が５から４に１減少したものとする。この場合、リソース管理テーブル２２は、図７（ａ）に示す状態から図７（ｂ）に示す状態に更新される。

この例では、該当論理計算機ＬＣｉｊは稼動系論理計算機ＬＣ１１であり（ステップ４０４のＹｅｓ）、稼動系論理計算機ＬＣ１１に対応する待機系論理計算機ＬＣｒｓはＬＣ３１である（ステップ４０５）。この場合、図７（ｂ）に示すリソース管理テーブル２２から明らかなように、稼動系論理計算機ＬＣ１１の割当リソース数ＮＡＲ１１（ＮＡＲｉｊ＝ＮＡＲ１１）は６、待機系論理計算機ＬＣ３１の割当リソース数ＮＡＲ３１（ＮＡＲｒｓ＝ＮＡＲ３１）は２である。このため、待機系論理計算機ＬＣ３１の不足リソース数ＮＳＲ３１（ＮＳＲｒｓ＝ＮＳＲ３１）は、
ＮＳＲ３１（＝ＮＳＲｒｓ）＝ＮＡＲｉｊ−ＮＡＲｒｓ
＝ＮＡＲ１１−ＮＳＲ３１
＝６−２
＝４
となる（ステップ４０６）。

一方、待機系論理計算機ＬＣ３１が動作する物理計算機ＰＣ３（ＰＣｒ＝ＰＣ３）の予備リソース数ＮＰＲ３（ＮＰＲｒ＝ＮＰＲ３）は、図７（ｂ）に示すリソース管理テーブル２２から明らかなように３である。この場合、待機系論理計算機ＬＣ３１の不足リソース数ＮＳＲ３１（＝ＮＳＲｒｓ）＝４は、物理計算機ＰＣ３の予備リソース数ＮＰＲ３（＝ＮＰＲｒ）＝３よりも大きい（ステップ４０７のＹｅｓ）。そこで移動計算機決定部２７２は、待機系論理計算機ＬＣ３１の移動を決定して（ステップ４０８）、当該待機系論理計算機ＬＣ３１を移動対象論理計算機として設定する（ステップ５０１）。

次に移動計算機決定部２７２は、図７（ｂ）に示すリソース管理テーブル２２及び図３に示すクラスタノード管理テーブル２３に基づいて、前述の条件Ｃ１を満たす物理計算機ＰＣｕ（ｕ≠３，ｕ≠１）を探索する（ステップ５０２）。ところが、待機系論理計算機ＬＣ３１のフェイルオーバ時に必要なリソース数ＮＡＲｒｓ＋ＮＳＲｒｓ＝ＮＡＲ３１＋ＮＳＲ３１（＝稼動系論理計算機ＬＣｉｊ＝ＬＣ１１の割当リソース数ＮＡＲｉｊ＝ＮＡＲ１１）＝６以上の予備リソース数を有する物理計算機は存在しない。この場合、移動計算機決定部２７２は、条件Ｃ１を満たす物理計算機ＰＣｕの探索に失敗する（ステップ５０３のＮｏ）。

すると移動計算機決定部２７２は、待機系論理計算機ＬＣ３１が動作する物理計算機ＰＣ３（ＰＣｒ＝ＰＣ３）上の別の待機系論理計算機の移動によって当該物理計算機ＰＣ３（ＰＣｒ＝ＰＣ３）の予備リソース数ＮＰＲ３（ＮＰＲｒ＝ＮＰＲ３）を上記不足リソース数ＮＳＲ３１（ＮＳＲｒｓ＝ＮＳＲ３１＝４）以上増やすために、以下の手順を実行する。

まず移動計算機決定部２７２は、図７（ｂ）に示すリソース管理テーブル２２に基づいて、条件Ｃ２を満たす、物理計算機ＰＣ３上の待機系論理計算機ＬＣ３１（ＬＣｒｓ＝ＬＣ３１）以外の待機系論理計算機ＬＣｒｔ（ｔ≠ｓ）を探索する（ステップ５０６）。条件Ｃ２は
ＮＡＲｒｔ≧（ＮＳＲｒｓ−ＮＰＲｒ）
である。

ここで、ＮＡＲｒｔは、待機系論理計算機ＬＣｒｔの割当リソース数である。本実施形態では、物理計算機ＰＣ３上の待機系論理計算機ＬＣ３１以外の待機系論理計算機ＬＣｒｔは、図３のクラスタノード管理テーブル２３から明らかなように、ＬＣ３２（ＬＣｒｔ＝ＬＣ３２）であり、ＬＣ３２の割当リソース数ＮＡＲ３２（ＮＡＲｒｔ＝ＮＡＲ３２）は図７（ｂ）のリソース管理テーブル２２から明らかなように２である。

また、ＮＳＲｒｓは、ステップ４０６で算出された、待機系論理計算機ＬＣ３１（ＬＣｒｓ＝ＬＣ３１）の不足リソース数ＮＳＲ３１＝４であり、ＮＰＲｒは物理計算機ＰＣ３の予備リソース数ＮＰＲ３＝３である。ＮＳＲｒｓ−ＮＰＲｒ＝ＮＳＲ３１−ＮＰＲ３は、待機系論理計算機ＬＣ３１のフェイルオーバ時に必要とするリソース数である。ＮＳＲｒｓ−ＮＰＲｒの演算は、算出部２７１によって行われる。

この場合、ＮＡＲｒｔ＝ＮＡＲ３２＝２は、ＮＳＲｒｓ−ＮＰＲｒ＝ＮＳＲ３１−ＮＰＲ３＝４−３＝１以上であることから、条件Ｃ２を満たす。このことは、もし待機系論理計算機ＬＣ３２（ＬＣｒｔ＝ＬＣ３２）を別の物理計算機に移動するならば、待機系論理計算機ＬＣ３１（ＬＣｒｓ＝ＬＣ３１）のフェイルオーバ時に必要とするリソース数を確保できることを示す。

そこで移動計算機決定部２７２は、仮に待機系論理計算機ＬＣ３２（ＬＣｒｔ＝ＬＣ３２）を移動対象論理計算機とした場合における、当該移動対象論理計算機の移動先物理計算機として、条件Ｃ３を満たす物理計算機ＰＣｕ（ｕ≠ｒ）を探索する（ステップ５０７）。条件Ｃ３は
ＮＡＲｒｔ≦ＮＰＲｕ
である。

ここで、ＮＡＲｒｔ（＝ＮＡＲ３２）は前述のように待機系論理計算機ＬＣ３２の割当リソース数であり、２である。ＮＰＲｕは待機系論理計算機ＬＣ３２の移動先の候補となる物理計算機の予備リソース数であり、例えば、物理計算機ＰＣ１の予備リソース数ＮＰＲｕ（＝ＮＰＲ１）は４であり、物理計算機ＰＣ２の予備リソース数ＮＰＲｕ（＝ＮＰＲ２）は５であことから、いずれも条件Ｃ３を満たす。よって移動計算機決定部２７２は、条件Ｃ３を満たす物理計算機ＰＣｕとして、物理計算機ＰＣ１及びＰＣ２の２つを見つけることができる。

さて本実施形態では、前述した場合と同様に物理計算機の障害発生に備えて、待機系論理計算機ＬＣ３２の移動先物理計算機ＰＣｕの候補から、当該待機系論理計算機ＬＣ３２に対応する稼動系論理計算機ＬＣ２１が動作している物理計算機ＰＣ２（ＰＣｕ＝ＰＣ２）は除外される。つまり移動計算機決定部２７２は、条件Ｃ３を満たす物理計算機ＰＣｕ（としてＰＣ１（ＰＣｕ＝ＰＣ１）を選択する。

このように条件Ｃ３を満たす物理計算機ＰＣ１（ＰＣｕ＝ＰＣ１）の探索に成功した場合（ステップ５０８のＹｅｓ）、移動計算機決定部２７２は移動対象論理計算機を、ステップ５０１で設定した待機系論理計算機ＬＣ３１（ＬＣｒｓ＝ＬＣ３１）から、ステップ５０６で探索された待機系論理計算機ＬＣ３２（ＬＣｒｔ＝ＬＣ３２）に変更する（ステップ５０９）。また移動計算機決定部２７２は、ステップ５０６で探索された物理計算機ＰＣ１（ＰＣｕ＝ＰＣ１）を、移動対象論理計算機の移動先物理計算機として設定する（ステップ５０４）。

移動部２７３はこの設定に応じて、移動対象論理計算機の移動先物理計算機への移動を構成管理機構２１に要求することにより、待機系論理計算機ＬＣ３２を物理計算機ＰＣ１へ移動させる（ステップ５０５）。

するとリソース情報管理部２５は、リソース管理テーブル２２を、図７（ｂ）に示す状態から、図７（ｃ）に示す状態に更新する。図７（ｃ）において矢印７０は、論理計算機ＬＣ３２の物理計算機ＰＣ３から物理計算機ＰＣ１への移動を表す。

このように本実施形態によれば、稼動系論理計算機ＬＣ１１の割当リソース数が増加したために当該稼動系論理計算機ＬＣ１１に対応する待機系論理計算機ＬＣ３１のフェイルオーバ時にリソースが不足することが予測されているにも係わらず、当該待機系論理計算機ＬＣ３１の移動先の物理計算機が見つからない場合、移動計算機決定部２７２は、当該待機系論理計算機ＬＣ３１が動作する物理計算機ＰＣ３上の別の待機系論理計算機ＬＣ３２と、当該待機系論理計算機ＬＣ３２の移動先の物理計算機ＰＣ１を見つける。この場合、移動部２７３が待機系論理計算機ＬＣ３２を物理計算機ＰＣ１に移動させることにより、移動先が見つからなかった待機系論理計算機ＬＣ３１のリソース不足の発生を、対応するＨＡサービスＳ１だけでなく他のＨＡサービスＳ２にも影響を与えることなく、未然に防止できる。

一方、条件Ｃ３を満たす物理計算機ＰＣｕの探索に失敗した場合（ステップ５０８のＮｏ）、リソース調整処理はステップ５０８からステップ４０１に戻る。なお、条件Ｃ２を満たす待機系論理計算機ＬＣｒｔを探索できなかった場合にも、条件Ｃ３を満たす物理計算機ＰＣｕの探索に失敗したと判定される。

上記実施形態では、説明の簡略化のために、リソースがＣＰＵである場合を想定している。もし、リソースにメモリを含める場合には、リソース数をＣＰＵ及びメモリそれぞれについて管理し、リソース管理テーブル２２もＣＰＵ及びメモリの各々について用意すればよい。また、ステップ４０７の判定をＣＰＵ及びメモリそれぞれについて行い、少なくとも一方の判定がＹｅｓの場合に、ステップ４０８以降の処理が行われる構成とすればよい。また、ステップ４０８以降の処理においても、不足するＣＰＵ数またはメモリ数を充足できる物理計算機を移動先物理計算機として探索すればよい。勿論、ＣＰＵ及びメモリの両方が不足する場合には、不足するＣＰＵ数及びメモリ数を共に充足できる物理計算機を移動先物理計算機として探索すればよい。

また上記実施形態では、フェイルオーバ時にリソースが不足することが予測される待機系論理計算機の移動先となる物理計算機の探索に失敗し、したがって当該待機系論理計算機のフェイルオーバ時に必要となるソースを確保できない場合（ステップ５０８のＮｏ）、再びステップ４０１から処理が行われる。しかし、ステップ５０８の判定がＮｏの場合、表示器、通信機構のような出力手段により、リソース調整管理部２７がユーザに警告を通知する構成であっても構わない。

また上記実施形態では、該当論理計算機ＬＣｉｊのリソース数が減少した場合にも、ステップ４０４の判定が実行される。しかし、該当論理計算機ＬＣｉｊのリソース数が減少した場合には、ステップ４０４を実行せずに、ステップ４０１に戻っても構わない。

＜変形例＞
次に、上記実施形態の変形例について、図８を参照して説明する。図８は、本変形例で適用されるリソース調整処理を説明するためのフローチャートの一部を示す。本変形例では、上記実施形態で適用されるリソース調整処理の手順のうち、図４のフローチャート部の示す手順に代えて図８のフローチャート部の示す手順が適用される。このため、本変形例で適用されるフローチャートの残りは、図５を参照されたい。また、図８において、図４と等価なステップには同一符号を付してある。

本変形例の特徴は、該当論理計算機Ｌｉｊが稼動系論理計算機でない場合にも、移動対象となり得る待機系論理計算機Ｌｒｖが探索される点にある。例えば、図６（ａ）のリソース管理テーブル２２によって示されるように、物理計算機ＰＣ３上で動作する論理計算機ＬＣ３３の割当リソース数ＮＡＲ３１が５から９に４増加したために、当該物理計算機ＰＣ３の予備レソース数ＮＰＲ３が５から１に減少したものとする。論理計算機ＬＣ３３は、図３に示すクラスタノード管理テーブル２３に稼動系論理計算機として登録されていないため非稼動系論理計算機である。また論理計算機ＬＣ３３は、上記クラスタノード管理テーブル２３にクラスタノードとしても登録されていないため非クラスタ論理計算機でもある。

図６（ａ）のリソース管理テーブル２２の示す状態で、例えば物理計算機ＰＣ１上で動作する稼動系論理計算機ＬＣ１１の障害により当該稼動系論理計算機ＬＣ１１に対応する待機系論理計算機ＬＣ３２のフェイルオーバが発生したならば、必要なリソース数が不足する。前記実施形態では、このリソース数不足を解消するためのリソース調整は、稼動系論理計算機ＬＣ１１のリソース数の増減が検出されるまで待たされる。これに対して本変形例では、非稼動系論理計算機の割当リソース数の増加により、フェイルオーバ時に必要なリソース数が不足する待機系論理計算機が存在する場合にも、リソース調整が行われる。

さて、上述のように、物理計算機ＰＣ３上で動作する論理計算機ＬＣ３３の割当リソース数ＮＡＲ３１が５から９に４増加した場合、当該論理計算機ＬＣ３３（ＬＣｉｊ＝ＬＣ３３）が非稼動系論理計算機であることから、ステップ４０４の判定はＮｏとなる。この場合、上記実施形態と異なり、リソース調整処理はステップ４０４からステップ８０１に進む。

ここで、リソース増加が検出された非稼動系論理計算機Ｌｉｊを便宜的にＬＣｒｖと表記し、当該非稼動系論理計算機ＬＣｒｖ（ＬＣｒｖ＝ＬＣ３３）が動作する物理計算機ＰＣｒ上で動作する別の論理計算機で且つ待機系の論理計算機をＬＣｒｓと表記する。また、待機系論理計算機ＬＣｒｓに対応する稼動系論理計算機をＬＣｐｑと表記する。この場合、待機系論理計算機ＬＣｒｓの不足リソース数ＮＳＲｒｓは、稼動系論理計算機ＬＣｐｑの割当リソース数ＮＡＲｐｑ−待機系論理計算機ＬＣｒｓの割当リソース数ＮＡＲｒｓとなる。この不足リソース数ＮＳＲｒｓは、算出部２７１によって算出される。

ステップ８０１において移動計算機決定部２７２は、ＮＳＲｒｓ（＝ＮＡＲｐｑ−ＮＡＲｒｓ）が、条件Ｃ４を満たす待機系論理計算機ＬＣｒｓを探索する。条件Ｃ４は
ＮＳＲｒｓ＞ＮＰＲｒ
である。

ＬＣｒｖが本変形例のようにＬＣ３３の場合、物理計算機ＰＣｒ（＝ＰＣ３）上で動作するＬＣｒｓの候補はＬＣ３１及びＬＣ３２である。また、ＬＣ３１のＮＳＲ３１は、ＮＳＲｒｓ＝ＮＡＲｐｑ−ＮＡＲｒｓ＝ＮＡＲ１１−ＮＡＲ３１＝５−２＝３であり、ＬＣ３２のＮＳＲ３２は、ＮＳＲｒｓ＝ＮＡＲｐｑ−ＮＡＲｒｓ＝ＮＡＲ２１−ＮＡＲ３２＝３−２＝１である。またＮＰＲｒ＝ＮＰＲ３＝１である。この場合、条件Ｃ４を満たす待機系論理計算機ＬＣｒｓとしてＬＣ３１が探索される（ステップ８０１）。

このように条件Ｃ４を満たす待機系論理計算機ＬＣｒｓの探索に成功した場合（ステップ８０２のＹｅｓ）、移動計算機決定部２７２は上記実施形態においてステップ４０７の判定がＹｅｓの場合と同様にステップ４０８に進む。以降の処理手順は上記実施形態と同様である。必要ならば、図５を参照されたい。一方、条件Ｃ４を満たす待機系論理計算機ＬＣｒｓの探索に失敗した場合（ステップ８０２のＮｏ）、上記実施形態においてステップ４０７の判定がＮｏの場合と同様に、移動計算機決定部２７２は当該待機系論理計算機ＬＣｒｓの移動不要を決定する。すると、リソース変更通知部２４により論理計算機のリソース増減が再び監視される（ステップ４０１）。ステップ８０２の判定がＮｏの場合、ユーザに警告が通知される構成であっても構わない。

以上説明した少なくとも１つの実施形態によれば、リソースを有効利用しながら安定したクラスタシステムを構成することができる構成管理装置を提供することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０…クラスタ管理システム、２０…構成管理サーバ（構成管理装置）、２１…構成管理機構、２２…リソース管理テーブル、２３…クラスタノード管理テーブル、２４…リソース変更通知部（検出手段）、２５…リソース情報管理部、２６…クラスタノード探索部、２７…リソース調整管理部（特定手段）、３０…ネットワーク、２７１…算出部、２７２…移動計算機決定部、２７３…移動部、ＰＣ１〜ＰＣ３…物理計算機、ＬＣ１１，ＬＣ１２，ＬＣ２１，ＬＣ２２，ＬＣ３１〜ＬＣ３３…論理計算機、ＣＭ１〜ＣＭ３…クラスタ管理機構、Ｓ１，Ｓ２…ＨＡサービス。

Claims (5)

1. １つ以上の論理計算機がそれぞれ動作する複数の物理計算機の構成を管理する構成管理装置において、
   前記複数の物理計算機の各々について、当該物理計算機上の前記論理計算機に割り当てられているリソース数及び当該物理計算機における予備リソース数を保持するリソース管理テーブルと、
   前記複数の物理計算機でそれぞれ動作する論理計算機のうち、クラスタシステムを構成し、サービスを実行する稼動系の論理計算機の情報、及び前記クラスタシステムを構成し、前記稼動系の論理計算機の障害時に前記サービスを引き継ぐ待機系の論理計算機の情報を前記サービス毎に保持するクラスタノード管理テーブルと、
   前記複数の物理計算機でそれぞれ動作する論理計算機に割り当てられるリソースの増加を監視して、割当リソース数が増加した第１の論理計算機を検出する検出手段と、
   前記第１の論理計算機が稼動系の論理計算機であることが前記クラスタノードテーブルによって示されている場合、前記第１の論理計算機に対応する待機系の第２の論理計算機を前記クラスタノードテーブルに基づいて特定する特定手段と、
   前記リソース管理テーブルから取得される前記第１の論理計算機の第１の割当リソース数及び前記第２の論理計算機の第２の割当リソース数に基づき、前記第２の論理計算機のサービス引き継ぎ時の不足リソース数を算出する算出手段と、
   前記不足リソース数が、前記第２の論理計算機が動作する第１の物理計算機の予備リソース数に満たない場合、当該不足リソース数を補うのに必要な予備リソース数を有する第２の物理計算機を前記リソース管理テーブルに基づいて探索し、当該探索に成功した場合、前記第２の物理計算機を、前記第２の論理計算機を移動対象論理計算機とする場合の移動先物理計算機として決定する移動計算機決定手段と、
   前記移動対象論理計算機を前記移動先物理計算機へ移動させる移動手段と
   を具備する構成管理装置。
2. 前記第２の物理計算機の探索に失敗した場合、前記移動計算機決定手段は、前記第１の物理計算機上で動作する待機系の論理計算機の中から、前記不足リソース数を補うのに必要な割当リソース数を有する第３の論理計算機を前記リソース管理テーブルに基づいて探索し、且つ予備リソース数が前記第３の論理計算機の割当リソース数以上となる第３の物理計算機を前記リソース管理テーブルに基づいて探索し、前記第３の物理計算機の探索に成功した場合、前記第３の論理計算機を前記移動対象論理計算機として決定し、且つ前記第３の物理計算機を前記移動対象論理計算機の移動先物理計算機として決定する請求項１記載の構成管理装置。
3. 前記不足リソース数を補うのに必要な割当リソース数は、前記不足リソース数と前記第２の物理計算機の予備リソース数との差分以上である請求項２記載の構成管理装置。
4. 前記移動計算機決定手段は、前記第２の物理計算機の探索において、前記第１の論理計算機が動作する物理計算機を探索の対象から除外し、前記第３の物理計算機の探索において、前記第３の論理計算機に対応する稼動系の論理計算機が動作する物理計算機を探索の対象から除外する
   請求項２記載の構成管理装置。
5. 前記不足リソース数は、前記第１の割当リソース数と前記第２の割当リソース数との差分であり、
   前記不足リソース数を補うのに必要な前記予備リソース数は、前記第２の物理計算機の予備リソース数と前記不足リソース数との和以上である
   請求項１記載の構成管理装置。

Images