JP5370946B2 - リソース管理方法及び計算機システム - Google Patents

Description

本発明は、仮想化技術を用いた計算機システムに係り、特に仮想化技術を用いた計算機システムのリソース管理方法及び計算機システムに関する。

仮想化技術を用いた計算機システムでは、サーバがサーバ仮想化プログラムを実行することによって、１つ以上の仮想サーバ（以下、ＶＭと記載する）を稼働させる。仮想化技術としては例えば、Ｈｙｐｅｒ−Ｖ等が知られており、仮想化技術を利用することによって、複数のサーバを集約でき、及びリソース利用効率の向上を実現することができる。

仮想化技術では、ＶＭをサーバ間で稼働中に移動する技術が知られている。当該技術を用いることによって、特定のサーバに高負荷なＶＭが集中しないようにサーバ間でＶＭを移動させることができ、サーバの負荷を平準化することができる。

また、一方、１台のサーバ上に論理分割プログラムを稼働させ、当該論理分割プログラムが１つ以上の論理区画（以下、ＬＰＡＲと記載する）を生成し、各論理区画において仮想化プログラムを稼働させる多段仮想化技術が知られている（例えば、特許文献１参照）。

特開２００９−００３７４９号公報

ＶＭの移動させるためには、複数のサーバがストレージを共有する「クラスタ」を構成する必要がある。クラスタに登録されたサーバ間において、ＶＭを移動させることができる。これによって、特定のサーバの負荷を平準化することができる。

しかし、従来の仮想化技術では、クラスタに登録できるサーバ数には制限がある。そのため、ＶＭの移動範囲はクラスタに登録できるサーバ数の範囲に制限される。したがって、クラスタに新たにサーバを追加して特定のサーバの負荷を平準化することができない場合がある。

本発明は、クラスタに登録できるサーバ数が制限されていても、クラスタ内のサーバの負荷を平準化すること可能とする仮想化技術を提供することを目的とする。

本発明の代表的な一例を示せば以下の通りである。すなわち、仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムにおけるリソース管理方法であって、前記各計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第１のプロセッサに接続される第１のＩ／Ｏインタフェースとを有し、前記管理計算機は、第２のプロセッサと、前記第２のプロセッサに接続される第２のメモリと、前記第２のプロセッサに接続される第２のＩ／Ｏインタフェースとを有し、前記ホストは、前記第１のプロセッサが、前記仮想化プログラムを実行する物理ホストと、前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、を含み、前記管理計算機は、複数の前記ホストから構成されるクラスタが有する物理リソースを管理するリソース管理部を有し、前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、前記リソース管理方法は、前記リソース管理部が、前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定する第１のステップと、前記リソース管理部が、前記対象論理ホストに対する物理リソースの割り当て量を変更する第２のステップと、を含むことを特徴とする。

本発明によれば、クラスタを構成するホスト数を変更することなく、物理リソースが不足しているクラスタのリソース量を変更することができる。したがって、クラスタの登録されるサーバ間の負荷を平準化できる。

本発明の第１の実施形態における計算機システムの構成例を説明するブロック図である。 本発明の第１の実施形態におけるサーバのハードウェア構成及びソフトウェア構成を説明するブロック図である。 本発明の第１の実施形態におけるサーバのハードウェア構成及びソフトウェア構成を説明するブロック図である。 本発明の第１の実施形態におけるサーバ上で稼働するＶＭのスタックの一例を示す説明図である。 本発明の第１の実施形態におけるサーバ上で稼働するＶＭのスタックの一例を示す説明図である。 本発明の第１の実施形態におけるリソース管理プログラムの構成例を示す説明図である。 本発明の第１の実施形態におけるリソースプールの構成例を示す説明図である。 本発明の第１の実施形態におけるサーバテーブルの一例を示す説明図である。 本発明の第１の実施形態におけるクラスタテーブルの一例を示す説明図である。 本発明の第１の実施形態における構成テーブルの一例を示す説明図である。 本発明の第１の実施形態のリソース管理プログラムが実行するリソース管理処理を説明するフローチャートである。 本発明の第１の実施形態における物理リソースの監視処理を説明するシーケンス図である。 本発明の第１の実施形態におけるクラスタの実リソース利用率の算出方法を示す説明図である。 本発明の第１の実施形態におけるリソース決定処理を説明するフローチャートである。 本発明の第１の実施形態におけるリソース変更処理を説明するシーケンス図である。 本発明の第１の実施形態におけるリソース変更処理の概要を示す説明図である。 本発明の第１の実施形態の変形例における空きリソーステーブルの一例を示す説明図である。 本発明の第１の実施形態の変形例におけるリソース決定処理を説明するフローチャートである。 本発明の第２の実施形態におけるリソース変更処理を説明するシーケンス図である。 本発明の第３の実施形態におけるリソース決定処理を説明するフローチャートである。 本発明の第３の本実施形態におけるリソース変更処理を説明するシーケンス図である。 本発明の第３の実施形態におけるリソース変更処理の概要を示す説明図である。

以下に、本発明の実施形態について図面を用いて説明する。

［第１の実施形態］
図１は、本発明の第１の実施形態における計算機システムの構成例を説明するブロック図である。

本実施形態における計算機システムは、管理サーバ１０、入出力装置１５、管理ネットワーク１６、サーバ４０、ネットワーク機器４１及びストレージ装置４５から構成される。管理サーバ１０と各サーバ４０とは管理ネットワーク１６を介して接続される。また、各サーバ４０は、ネットワーク機器４１を介してストレージ装置４５と接続される。

管理サーバ１０は、計算機システム全体を管理する。また、管理サーバ１０は、リソースプール９０を管理する。なお、本実施形態では、サーバ４０、ネットワーク機器４１及びストレージ装置４５が備える物理リソースが一つのリソースプール９０として管理される。

管理サーバ１０は、ＣＰＵ１１、メモリ１２及びＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１３を備える。

ＣＰＵ１１は、メモリ１２上に展開されるプログラムを実行する。ＣＰＵ１１が所定のプログラムを実行することによって管理サーバ１０が備える機能を実現することができる。

メモリ１２は、ＣＰＵ１１によって実行されるプログラム及び当該プログラムを実行するために必要な情報を格納する。具体的には、メモリ１２は、リソース管理プログラム２０を格納する。なお、他のプログラムが格納されていてもよい。

リソース管理プログラム２０は、リソースプール９０を管理するプログラムである。以下、リソース管理プログラム２０を主語に処理を説明するときには、ＣＰＵ１１によってリソース管理プログラム２０が実行されていることを示す。なお、リソース管理プログラム２０の詳細については、図４を用いて後述する。

なお、リソース管理プログラム２０によって実現される機能を、管理サーバ１０が搭載するハードウェア、ファームウェア、又はこれらの組み合わせによって、例えば、リソース管理部として実装してもよい。

ＮＩＣ１３は、リソースプール９０に含まれるサーバ４０に接続するためのインタフェースである。

また、管理サーバ１０には、当該管理サーバ１０を操作するための入出力装置１５が接続される。入出力装置１５は、マウス、キーボード及びディスプレイなどの装置であり、管理サーバ１０と管理者との間で情報を入出力するために利用される。

サーバ４０は、複数の仮想計算機（ＶＭ）５０を稼動させるための仮想化環境を提供する。本実施形態では、一つのホスト上に一つ以上のＶＭ５０が稼動する。

ここで、ホストは、ＶＭ５０を管理する仮想化プログラム６０（図２Ａ及び図２Ｂ参照）を実行する計算機（インスタンス）を示す。本実施形態では、サーバ４０上で直接仮想化プログラム６０（図２Ａ及び図２Ｂ参照）が実行される物理ホスト３０と、論理区画（ＬＰＡＲ）５１上で仮想化プログラム６０（図２Ａ及び図２Ｂ参照）が実行される論理ホスト３１とが含まれる。

論理区画（ＬＰＡＲ）５１は、サーバ４０が備える物理リソースを論理的に分割して生成された論理的な区画を示す。なお、物理リソースを論理的に分割する方法は、どのようなものでもよい。

例えば、複数のコアを備えるＣＰＵを論理的に分割する方法は、それぞれのコアをＬＰＡＲ５１に割り当てる方法が考えられる。また、メモリを論理的に分割する方法は、所定のアドレス領域を各ＬＰＡＲ５１に割り当てる方法が考えられる。

なお、サーバ４０のハードウェア構成及びソフトウェア構成については、図２Ａ及び図２Ｂを用いて後述する。また、物理ホスト３０及び論理ホスト３１の構成については図３Ａ及び図３Ｂを用いて後述する。

ネットワーク機器４１は、各サーバ４０とストレージ装置４５とを接続する。ネットワーク機器４１には、ＦＣ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）スイッチ、Ｅｔｈｅｒｎｅｔネットワークスイッチ（Ｅｔｈｅｒｎｅｔは登録商標、以下同じ）、及びＦＣｏＥ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ）ネットワークスイッチなどが含まれる。

ストレージ装置４５は、サーバ４０が実行するプログラム、及びＶＭ５０の実行に必要な情報等を格納する。ストレージ装置４５には、ディスクアレイ装置及びＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）などが含まれる。なお、複数のサーバ４０がストレージ装置４５を共有することもできる。

図２Ａ及び図２Ｂは、本発明の第１の実施形態におけるサーバ４０のハードウェア構成及びソフトウェア構成を説明するブロック図である。

図２Ａは、物理ホスト３０を構成するサーバ４０のハードウェア構成を示す。図２Ｂは、論理ホスト３１を構成するサーバ４０のハードウェア構成を示す。

図２Ａに示すサーバ４０は、ＣＰＵ４１、メモリ４２及びＩ／Ｏデバイス４３を備える。

ＣＰＵ４１は、メモリ４２上に展開されるプログラムを実行する。ＣＰＵ４１が所定のプログラムを実行することによってサーバ４０が備える機能を実現することができる。

メモリ４２は、ＣＰＵ４１によって実行されるプログラム及び当該プログラムを実行するために必要な情報を格納する。具体的には、メモリ４２は、仮想化プログラム６０を格納する。

仮想化プログラム６０は、ＶＭ５０を生成し、ＶＭ５０を制御する。以下、仮想化プログラム６０を主語に処理を説明するときには、ＣＰＵ４１によって仮想化プログラム６０が実行されていることを示す。

なお、仮想化プログラム６０によって実現される機能を、サーバ４０が搭載するハードウェア、ファームウェア、又はこれらの組み合わせによって、例えば、仮想化部として実装してもよい。

Ｉ／Ｏデバイス４３は、ストレージ装置４５などの外部装置と接続するためのデバイスであり、例えば、ＮＩＣ、ＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｏｒ）及びＣＮＡ（Ｃｏｎｖｅｒｇｅｄ Ｎｅｔｗｏｒｋ Ａｄａｐｔｅｒ）などが考えられる。

図２Ｂに示すサーバ４０は、図２Ａに示すサーバ４０と同一のハードウェア構成であるため説明を省略する。図２Ｂに示すサーバ４０は、メモリ４２に論理分割プログラム７０を格納する点が異なる。

論理分割プログラム７０は、サーバ４０上に１つ以上のＬＰＡＲ５１を生成し、当該ＬＰＡＲ５１を管理する。以下、論理分割プログラム７０を主語に処理を説明するときには、ＣＰＵ４１によって論理分割プログラム７０が実行されていることを示す。

なお、論理分割プログラム７０によって実現される機能を、サーバ４０が搭載するハードウェア、ファームウェア、又はこれらの組み合わせによって、例えば、論理分割部として実装してもよい。

図３Ａ及び図３Ｂは、本発明の第１の実施形態におけるサーバ４０上で稼働するＶＭ５０のスタックの一例を示す説明図である。

図３Ａは、物理ホスト３０を構成するサーバ４０のスタックを示す。

サーバ４０上では、ＣＰＵ４１によって仮想化プログラム６０が実行される。当該仮想化プログラム６０は、１つ以上のＶＭ５０を生成し、生成されたＶＭ５０を稼働させる。ＶＭ５０上ではオペレーティングシステム及びアプリケーションが実行される。

本実施形態では、仮想化プログラム６０を実行するサーバ４０が物理ホスト３０に対応する。

図３Ｂは、論理ホスト３１を構成するサーバ４０のスタックを示す。

サーバ４０上では、ＣＰＵ４１によって論理分割プログラム７０が実行される。当該論理分割プログラム７０は、１つ以上のＬＰＡＲ５１を生成し、生成されたＬＰＡＲ５１を管理する。

さらに、ＬＰＡＲ５１に割り当てられたＣＰＵ４１が仮想化プログラム６０を実行する。当該仮想化プログラム６０は、当該ＬＰＡＲ５１上に１つ以上のＶＭ５０を生成し、生成されたＶＭ５０を稼働させる。ＶＭ５０上ではオペレーティングシステム及びアプリケーションが実行される。

本実施形態では、仮想化プログラム６０を実行するＬＰＡＲ５１が論理ホスト３１に対応する。

図４は、本発明の第１の実施形態におけるリソース管理プログラム２０の構成例を示す説明図である。

リソース管理プログラム２０は、統合リソース管理モジュール２１、クラスタ管理モジュール２２及びサーバ管理モジュール２３を含む。

統合リソース管理モジュール２１は、リソースプール９０を管理する。統合リソース管理モジュール２１は、構成テーブル２５を含む。構成テーブル２５は、リソースプール９０の構成情報を格納する。構成テーブル２５の詳細については、図８を用いて後述する。

クラスタ管理モジュール２２は、クラスタ（図５参照）を管理する。具体的には、クラスタ管理モジュール２２は、ＶＭ５０の構成及び状態、並びに、クラスタ（図５参照）の構成を管理する。

クラスタ管理モジュール２２は、クラスタテーブル２７を含む。クラスタテーブル２７は、仮想化プログラム６０から取得されたＶＭ５０の構成情報、及び、クラスタ（図５参照）の構成情報を格納する。クラスタテーブル２７の詳細については、図７を用いて後述する。

サーバ管理モジュール２３は、サーバ４０を管理する。具体的には、サーバ管理モジュール２３は、サーバ４０の構成及び状態、並びに、ＬＰＡＲ５１の構成及び状態を管理する。

サーバ管理モジュール２３は、サーバテーブル２８を含む。サーバテーブル２８は、サーバ４０の構成情報、及び、論理分割プログラム７０から取得されたＬＰＡＲ５１の構成情報を格納する。サーバテーブル２８の詳細については、図６を用いて後述する。

なお、統合リソース管理モジュール２１、クラスタ管理モジュール２２及びサーバ管理モジュール２３を、サーバ４０が搭載するハードウェア、ファームウェア、又はこれらの組み合わせによって、実装してもよい。また、統合リソース管理モジュール２１、クラスタ管理モジュール２２及びサーバ管理モジュール２３を異なる計算機が備えていてもよい。

図５は、本発明の第１の実施形態におけるリソースプール９０の構成例を示す説明図である。

図５に示すサーバ２及びサーバ４は、物理ホスト３０に対応するサーバ４０である。また、サーバ１及びサーバ３は、論理ホスト３１を構成するＬＰＡＲ５１が生成されるサーバ４０である。各ＬＰＡＲ５１が論理ホスト３１に対応する。

物理ホスト３０は、サーバ４０が備えるすべての物理リソースが割り当てられた計算機として稼動する。

ＬＰＡＲ５１には、サーバ４０が備える物理リソースを論理的に分割した物理リソースが割り当てられる。また、論理ホスト３１は、ＬＰＡＲ５１が備える物理リソースが割り当てられた計算機として稼動する。

ＶＭ５０は、物理ホスト３０又は論理ホスト３１が備える物理リソースが割り当てられた仮想的な計算機である。ＶＭ５０上では、オペレーティングシステム及びアプリケーションが実行される。

リソースプール９０は、クラスタ５３から構成される。本実施形態では、クラスタ５３が一つの物理リソースとして扱われ、当該物理リソースが各ＶＭ５０に割り当てられる。

クラスタ５３は、１つ以上の物理ホスト３０と１つ以上の論理ホスト３１とから構成されるリソースグループ、複数の論理ホスト３１から構成されるリソースグループ、及び、複数の物理ホスト３０から構成されるリソースグループを含む。

以下、クラスタ５３を構成する物理ホスト３０及び論理ホスト３１を、クラスタに属する物理ホスト３０及び論理ホスト３１とも記載する。

なお、物理ホスト３０及び論理ホスト３１は必ずしもクラスタ５３に属する必要はない。また、どのクラスタ５３にも属さないホスト（物理ホスト３０及び論理ホスト３１）も、一つのクラスタ５３として管理してもよい。

図５に示す例では、物理ホスト２はサーバ２に対応し、物理ホスト５はサーバ４に対応する。論理ホスト１はサーバ１に生成されたＬＰＡＲ１に対応し、論理ホスト３はサーバ１に生成されたＬＰＡＲ２に対応する。また、論理ホスト４はサーバ３に生成されたＬＰＡＲ３に対応する。

本実施形態では、少なくとも１つ以上の論理ホスト３１を含むクラスタ５３からリソースプール９０が構成される点に特徴がある。これによって、論理ホスト３１を構成するＬＰＡＲ５１への物理リソースの割り当てを変更することによって、クラスタ５３の物理リソース量を変更することができる。

図６は、本発明の第１の実施形態におけるサーバテーブル２８の一例を示す説明図である。

サーバテーブル２８は、サーバ管理モジュール２３によって作成される。サーバテーブル２８は、サーバ２８１、スペック情報２８２、ＬＰＡＲ２８３及び構成２８４を含む。

サーバ２８１は、計算機システム内においてサーバ４０を一意に識別するための識別子を格納する。サーバ４０の識別子としては、例えば、サーバ４０のＵＵＩＤ、ＭＡＣアドレス、ブレードサーバ又はラックの物理位置を示す情報（スロット位置番号）、及び、管理者によって設定された名称などが考えられる。

スペック情報２８２は、サーバ４０が備える物理リソースのリソース量を表すスペック情報を格納する。本実施形態では、ＣＰＵ、メモリ及びＩ／Ｏデバイスのリソース量がスペック情報として格納される。なお、スペック情報は、他の物理リソースのリソース量を含んでいてもよい。

ＬＰＡＲ２８３は、計算機システム内においてＬＰＡＲ５１を一意に識別するための識別子を格納する。なお、ＬＰＡＲ５１が生成されていない場合、ＬＰＡＲ２８３にはＬＰＡＲ５１が生成されていないことを示す情報が格納される。例えば、物理ホスト３０の場合、ＬＰＡＲ２８３には前述した情報が格納される。

構成２８４は、ＬＰＡＲ５１に論理的に割り当てられた物理リソースのリソース量を表すスペック情報を格納する。なお、ＬＰＡＲ５１が生成されていない場合、構成２８４には、スペック情報は格納されない。

図７は、本発明の第１の実施形態におけるクラスタテーブル２７の一例を示す説明図である。

クラスタテーブル２７は、クラスタ管理モジュール２２によって作成される。クラスタテーブル２７は、クラスタ２７１、クラスタリソース２７２、ホスト２７３及びＶＭ２７４を含む。

クラスタ２７１は、リソースプール９０内におけるクラスタ５３を一意に識別するための識別子を格納する。

クラスタリソース２７２は、クラスタ５３における物理リソースのリソース量を格納する。具体的には、クラスタ５３を構成する全ホストが備える物理リソースのリソース量の合計値が格納される。

ホスト２７３は、クラスタ５３に属するホストの識別子を格納する。ホストの識別子としては、例えば、ホスト名及びＩＰアドレスなどが考えられる。

ＶＭ２７４は、ホスト上で稼働するＶＭ５０を識別するための識別子を格納する。

なお、クラスタテーブル２７は、クラスタ５３に属さないホストのエントリも含む。この場合、当該エントリのクラスタ２７１及びクラスタリソース２７２は、クラスタ５３に属していないことを表す情報が格納される。図７に示す例では、「ｎ／ａ」が格納される。

図８は、本発明の第１の実施形態における構成テーブル２５の一例を示す説明図である。

構成テーブル２５は、統合リソース管理モジュール２１によって作成される。構成テーブル２５は、クラスタ２５１、ホスト２５２、サーバ２５３及びＬＰＡＲ２５４を格納する。

クラスタ２５１は、リソースプール９０内におけるクラスタ５３を一意に識別するための識別子を格納する。なお、クラスタ２５１は、クラスタ２７１と同一のものである。

ホスト２５２は、クラスタ５３に属するホストの識別子を格納する。ホスト２５２は、ホスト２７３と同一のものである。

統合リソース管理モジュール２１は、クラスタ管理モジュール２２のクラスタテーブル２７からクラスタ２７１及びホスト２７３を取得し、取得された各情報をクラスタ２５１及びホスト２５２に格納する。

サーバ２５３は、計算機システム内においてサーバ４０を一意に識別するための識別子を格納する。なお、サーバ２５３は、サーバ２８１と同一のものである。

ＬＰＡＲ２５４は、計算機システム内においてＬＰＡＲ５１を一意に識別するための識別子を格納する。なお、ＬＰＡＲ２５４は、ＬＰＡＲ２８３と同一のものである。

統合リソース管理モジュール２１は、サーバ管理モジュール２３のサーバテーブル２８からサーバ２８１及びＬＰＡＲ２８３を取得し、取得された各情報をサーバ２５３及びＬＰＡＲ２５４に格納する。

なお、統合リソース管理モジュール２１は、サーバ４０及びＬＰＡＲ５１への仮想化プログラム６０の配布及び設定が可能であり、これによって物理ホスト３０及び論理ホスト３１を構築できる。

統合リソース管理モジュール２１は、仮想化プログラム６０を配布したサーバ４０の識別子と、各ホストに設定したホスト名又はＩＰアドレスなどのホストの識別子とを対応づけて管理する。これによって、構成テーブル２５におけるホストとサーバ４０との関係を把握することができる。

なお、本実施形態では、統合リソース管理モジュール２１は、クラスタ５３に属しないホストを一つのクラスタ５３として管理する。この場合、クラスタ５３に属しないホストに対応するエントリのクラスタ２５１には、ホストの識別子が格納される。

図９は、本発明の第１の実施形態のリソース管理プログラム２０が実行するリソース管理処理を説明するフローチャートである。

なお、以下の説明において、リソースプール９０には、１つ以上の物理ホスト３０及び１つ以上の論理ホスト３１から構成されるクラスタ５３が１つ以上構築済みであるものとする。さらに、サーバ管理モジュール２３、クラスタ管理モジュール２２及び統合リソース管理モジュール２１は、サーバテーブル２８、クラスタテーブル２７及び構成テーブル２５を保持しているものとする。

まず、リソース管理プログラム２０は、物理リソースの監視処理を実行する（ステップＳ２０１）。リソース管理プログラム２０は、周期的に監視処理を実行してもよいし、管理者からの指示にしたがって監視処理を実行してもよい。

具体的には、リソース管理プログラム２０は、物理リソースの監視処理を実行して、各クラスタ５３における物理リソースの利用率を含む情報を取得する。なお、物理リソースの監視処理の詳細については、図１０を用いて後述する。

リソース管理プログラム２０は、各クラスタ５３から取得された情報に基づいて、リソース決定処理を実行する（ステップＳ２０２）。

リソース管理プログラム２０は、リソース決定処理を実行して、物理リソースの割り当て量を変更するクラスタ５３を決定する。なお、リソース決定処理の詳細については、図１２を用いて後述する。

リソース管理プログラム２０は、決定されたクラスタ５３について、物理リソースの割り当て量を変更できるか否かを判定する（ステップＳ２０３）。

物理リソースの割り当て量が変更できない場合には、リソース管理プログラム２０は、ステップＳ２０１に戻り、同様の処理（ステップＳ２０１〜ステップＳ２０４）を実行する。このとき、リソース管理プログラム２０は、物理リソースの割り当て量が変更できない旨を示すメッセージを管理者及び他のプログラムに通知する。

物理リソースの割り当て量が変更できる場合には、リソース管理プログラム２０は、リソース量の変更処理を実行する（ステップＳ２０４）。その後、リソース管理プログラム２０は、ステップＳ２０１に戻り、同様の処理（ステップＳ２０１〜ステップＳ２０４）を実行する。

なお、リソース量の変更処理の詳細については、図１３を用いて後述する。

以下では、物理リソースの割り当て量をリソース量とも記載する。

図１０は、本発明の第１の実施形態における物理リソースの監視処理を説明するシーケンス図である。

クラスタ管理モジュール２２及びサーバ管理モジュール２３は、それぞれ、リソース利用率を監視する。

具体的には、クラスタ管理モジュール２２は、ＶＭ５０によって使用される各ホストのリソース利用率を監視する（ステップＳ２０１１）。クラスタ管理モジュール２２は、監視結果を所定の形式のデータとして保持する。

ここで、ホストのリソース利用率とは、ホストに割り当てられたＣＰＵ、メモリ及びＩ／Ｏデバイスの利用率を示す値であり、０〜１００％までの値で表される。

Ｉ／Ｏデバイスの利用率としては、最大性能に対する利用バンド幅などが考えられる。なお、最大性能とは、ホストの割り当てられたＩ／Ｏデバイスにおける性能値の合計値であり、例えば、ホストに１０ＧｂのＣＮＡが４枚割り当てられている場合、最大性能は４０Ｇｂとなる。

一方、サーバ管理モジュール２３は、各ＬＰＡＲ５１のリソース利用率を監視する（ステップＳ２０１２）。サーバ管理モジュール２３は、監視結果を所定の形式のデータとして保持する。

ここで、ＬＰＡＲ５１のリソース利用率とは、ＬＰＡＲ５１に割り当てられたＣＰＵ、メモリ及びＩ／Ｏデバイスの利用率を示す値であり、０〜１００％までの値で表される。

なお、クラスタ管理モジュール２２及びサーバ管理モジュール２３は、それぞれ、周期的に前述した監視処理を実行する。なお、前述したステップＳ２０１１の監視処理及びステップＳ２０１２の監視処理の実行タイミングは、本シーケンスの示すタイミングに限定されない。

統合リソース管理モジュール２１は、構成テーブル２５を参照して、リソース利用率の問い合わせ先を決定する（ステップＳ２０１０）。

ＬＰＡＲ２５４に識別子が格納されていない場合、当該ホストは物理ホスト３０であるため、統合リソース管理モジュール２１は、クラスタ管理モジュール２２を問い合わせ先として決定する。ＬＰＡＲ２５４に識別子が格納されている場合、当該ホストは論理ホスト３１であるため、統合リソース管理モジュール２１は、サーバ管理モジュール２３を問い合わせ先として決定する。

問い合わせ先がクラスタ管理モジュール２２である場合、統合リソース管理モジュール２１は、物理ホスト３０のリソース利用率の取得要求をクラスタ管理モジュール２２に出力する（ステップＳ２０１３）。なお、当該取得要求には、クラスタ５３の識別子、及び、物理ホスト３０の識別子が含まれる。

クラスタ管理モジュール２２は、取得要求を受け付けると、要求された物理ホスト３０のリソース利用率を統合リソース管理モジュール２１に通知する（ステップＳ２０１４）。

具体的には、クラスタ管理モジュール２２は、クラスタ５３及び物理ホスト３０の識別子に基づいて、対象となる物理ホスト３０を特定する。さらに、クラスタ管理モジュール２２は、監視結果を参照し、特定された物理ホスト３０のリソース利用率を読み出し、読み出された物理ホスト３０のリソース利用率を統合リソース管理モジュール２１に通知する。

なお、ステップＳ２０１３〜ステップＳ２０１６は、各クラスタ５３に対して実行される。

問い合わせ先がサーバ管理モジュール２３である場合、統合リソース管理モジュール２１は、ＬＰＡＲ５１のリソース利用率の取得要求をサーバ管理モジュール２３に出力する（ステップＳ２０１５）。なお、当該取得要求には、クラスタ５３の識別子、及び、ＬＰＡＲ５１の識別子が含まれる。

サーバ管理モジュール２３は、取得要求を受け付けると、要求されたＬＰＡＲ５１のリソース利用率を統合リソース管理モジュール２１に通知する（ステップＳ２０１６）。

具体的には、サーバ管理モジュール２３は、取得要求に含まれるクラスタ５３の識別子、及び、ＬＰＡＲ５１の識別子に基づいて、通知対象となるＬＰＡＲ５１を特定する。さらに、サーバ管理モジュール２３は、監視結果を参照して特定されたＬＰＡＲ５１のリソース利用率を読み出し、読み出されたＬＰＡＲ５１のリソース利用率を統合リソース管理モジュール２１に通知する。

統合リソース管理モジュール２１は、取得されたリソース利用率に基づいて、各クラスタ５３の実リソース利用率を算出する（ステップＳ２０１７）。

ここで、クラスタ５３の実リソース利用率とは、クラスタ５３における物理リソースの利用率を表す。物理リソースには、少なくともＣＰＵ、メモリ及びＩ／Ｏデバイスが含まれる。したがって、ＣＰＵ、メモリ及びＩ／Ｏデバイスそれぞれの実リソース利用率が算出される。

なお、各クラスタ５３の実リソース利用率の算出方法については、図１１を用いて後述する。

統合リソース管理モジュール２１は、算出された各クラスタ５３の実リソース利用率に基づいて、リソース量を変更するクラスタ５３が存在するか否かを判定する（ステップＳ２０１８）。以下、リソース量を変更するクラスタ５３を対象クラスタ５３とも記載する。

当該判定処理は、例えば、以下のような方法が考えられる。

第１の方法としては、ＣＰＵの実リソース利用率が予め設定された閾値（例えば、７０％）以上であるクラスタ５３が存在するか否かを判定する方法が考えられる。

なお、第１の方法では、ＣＰＵの実リソース利用率に限定されず、メモリ及びＩ／Ｏデバイスの実リソース利用率であってもよい。すなわち、少なくともいずれかの物理リソースの実リソース利用率が閾値以上であるクラスタ５３が対象クラスタ５３として判定される。

なお、ＣＰＵ、メモリ及びＩ／Ｏデバイスのうち、２つ以上の物理リソースの実リソース利用率が閾値以上であるクラスタ５３を対象クラスタ５３としてもよい。また、ＣＰＵ、メモリ及びＩ／Ｏデバイスの実リソース利用率の平均値を用いた判定方法であってもよい。

第１の方法は、クラスタ５３の負荷を分散させることを目的とした判定方法である。

第２の方法としては、ＣＰＵの実リソース利用率が最大のクラスタ５３とＣＰＵの実リソース利用率が最小のクラスタ５３との実リソース利用率の差が、所定の閾値以上であるか否かを判定する方法が考えられる。ＣＰＵの実リソース利用率の差が所定の閾値以上である場合には、ＣＰＵの実リソース利用率が最大のクラスタ５３が対象クラスタ５３となる。

なお、第２の方法では、ＣＰＵの実リソース利用率に限定されず、メモリ及びＩ／Ｏデバイスの実リソース率であってもよい。すなわち、少なくともいずれかの物理リソースの実リソース利用率の差が所定の閾値以上である場合に、物理リソースの実リソース利用率が最大のクラスタ５３が対象クラスタ５３として判定される。また、ＣＰＵ、メモリ及びＩ／Ｏデバイスの実リソース利用率の平均値を用いた判定方法であってもよい。

第２の方法は、計算機システム内のクラスタ５３間の負荷の平準化を目的とした判定方法である。

なお、上記判定方法は一例であって、他の方法を用いて対象クラスタを判定してもよい。

なお、第１の方法及び第２の方法において用いられる各閾値は、統合リソース管理モジュール２１が保持する。閾値の入力方法としては、統合リソース管理モジュール２１によって提供されるＵＩを用いて管理者が入力してもよいし、統合リソース管理モジュール２１が予め保持していてもよい。

ステップＳ２０１８において、対象クラスタ５３が存在しないと判定された場合、統合リソース管理モジュール２１は、ステップＳ２０１０に戻り、同様の処理を実行する。

ステップＳ２０１８において、対象クラスタ５３が存在すると判定された場合、統合リソース管理モジュール２１は、対象クラスタ５３を設定し、処理を終了する（ステップＳ２０１９）。

図１１は、本発明の第１の実施形態におけるクラスタ５３の実リソース利用率の算出方法を示す説明図である。

ステップＳ２０１３において取得された物理ホスト３０のリソース利用率をＵｉ（ｉは１〜ｎの間の整数）として、ステップＳ２０１５において取得されたＬＰＡＲ５１のリソース利用率をＶｊ（ｊは１〜ｍの間の整数）とすると、クラスタ５３の実リソース利用率Ｒｋは、図１１に示す式（１）を用いて算出される。

ここで、ｎはクラスタ５３を構成する物理ホスト３０の数を示し、ｍはクラスタ５３を構成する論理ホスト３１の数を示す。

また、ｋはクラスタ５３における物理リソースの種類を表す。本実施形態では、ｋが「１」の場合にはＣＰＵの実リソース利用率を表し、ｋが「２」の場合にはメモリの実リソース利用率を表し、また、ｋが「３」の場合にはＩ／Ｏデバイスの実リソース利用率を表す。

ここでは、クラスタ５３の識別子が「Ｃ１」のクラスタ５３のＣＰＵの実リソース利用率を例に説明する。

ステップＳ２０１０において、統合リソース管理モジュール２１は、ホスト２５２が「Ｈ１」であるホストは論理ホスト３１であるため、サーバ管理モジュール２３に問い合わせる（ステップＳ２０１５）。また、ステップＳ２０１０において、統合リソース管理モジュール２１は、ホスト２５２が「Ｈ２」であるホストは物理ホスト３０であるため、クラスタ管理モジュール２２に問い合わせる（ステップＳ２０１３）。

物理ホスト３０のＣＰＵのリソース利用率をＵ１とし、ＬＰＡＲ５１のＣＰＵのリソース利用率をＶ１としたとき、ｎ＝１、ｍ＝１であるため、クラスタ５３のＣＰＵの実リソース利用率は、下式（２）に示すように算出される。
Ｒ１＝（Ｕ１＋Ｖ１）／２…（２）
論理ホスト３１のリソース利用率は、ＬＰＡＲ５１の監視手段が論理分割プログラム７０の影響を受けて、正確なリソース利用率を測定できない場合がある。しかし、前述した計算式を用いることによって、クラスタ５３における実際の物理リソースの利用率を取得することができる。

図１２は、本発明の第１の実施形態におけるリソース決定処理を説明するフローチャートである。

統合リソース管理モジュール２１は、対象クラスタ５３と同一のサーバ４０が備える物理リソースを共有する共有クラスタ５３を特定する（ステップＳ２０２１）。具体的には、以下のような処理が実行される。

統合リソース管理モジュール２１は、構成テーブル２５を参照して、対象クラスタ５３を構成する論理ホスト３１に対応するＬＰＡＲ５１を特定する。具体的には、ＬＰＡＲ２５４に識別子が格納されるエントリが検索される。

次に、統合リソース管理モジュール２１は、特定されたＬＰＡＲ５１の識別子を含む検索要求をサーバ管理モジュール２３に出力する。

当該検索要求を受け付けたサーバ管理モジュール２３は、サーバテーブル２８を参照して、対象クラスタ５３を構成する論理ホスト３１が生成されるサーバ４０を特定する。さらに、サーバ管理モジュール２３は、特定されたサーバ４０上に生成された他のＬＰＡＲ５１を検索する。

サーバ管理モジュール２３は、検索された他のＬＰＡＲ５１の識別情報（ＬＰＡＲ２８３）を統合リソース管理モジュール２１に通知する。

統合リソース管理モジュール２１は、通知されたＬＰＡＲ５１の識別子に基づいて構成テーブル２５を参照して、通知されたＬＰＡＲ５１に対応する論理ホスト３１から構成される共有クラスタ５３を特定する。なお、共有クラスタ５３は複数存在してもよい。

図８に示す例では、論理ホストＨ３がクラスタＣ１の論理ホストＨ１と同一のサーバＳ１が備える物理リソースを共有する。したがって、論理ホストＨ３から構成されるクラスタＣ２が、クラスタＣ１の共有クラスタとなる。

共有クラスタ５３が存在しない場合、リソース量を変更できないと判定される。そのためステップＳ２０３の判定処理では「Ｎｏ」となる。

なお、共有クラスタ５３が存在しない場合における、クラスタ５３のリソース量の変更方法については第３の実施形態において説明する。

統合リソース管理モジュール２１は、リソース量を変更する論理ホスト３１を決定する（ステップＳ２０２２）。

具体的には、統合リソース管理モジュール２１は、対象クラスタ５３を構成する論理ホスト３１と、共有クラスタ５３を構成する論理ホスト３１との組み合わせを決定する。

図８に示す例では、対象クラスタＣ１を構成する論理ホストＨ１と、共有クラスタＣ２を構成する論理ホストＨ３との組み合わせが決定される。

複数の組み合わせがある場合には、以下のようにして決定される。

まず、統合リソース管理モジュール２１は、共有クラスタ５３の実リソース利用率の予測値（第１の予測値とも記載する）を算出する。ここで、共有クラスタ５３の実リソース利用率の予測値は、共有クラスタ５３を構成する論理ホスト３１の物理リソースをリソース変更量分だけ削減した場合におけるリソース利用率を示す。

また、統合リソース管理モジュール２１は、対象クラスタ５３の実リソース利用率の予測値（第２の予測値とも記載する）を算出する。ここで、対象クラスタ５３の実リソース利用率の予測値は、対象クラスタ５３を構成する論理ホスト３１の物理リソースをリソース変更量分だけ追加した場合におけるリソース利用率を示す。

統合リソース管理モジュール２１は、第１の予測値と第２の予測値との差が最小となる組み合わせを決定する。

ここで、クラスタ５３の実リソース利用率の予測値Ｅは、下式（３）を用いて算出することができる。
Ｅｋ＝Ｒｋ×Ａ／（Ｄ＋Ａ）…（３）
ここで、Ｒはクラスタ５３の実リソース利用率を表し、Ａはクラスタリソース２７２に格納される値を表し、また、Ｄはリソース変更量を表す。なお、共有クラスタ５３の実リソース利用率を算出する場合、リソース変更量Ｄの前にマイナスをつけた式となる。

ただし、以下の２つの条件のもと、クラスタ５３の実リソース利用率の予測値Ｅは算出される。
（条件１）Ｄは、論理ホスト３１を構成するサーバ４０が備える物理リソース量を超えない。
（条件２）Ｅは、図１０のステップＳ２０１８における閾値より小さい。

前述した条件を満たす論理ホスト３１の組み合わせが存在しない場合、リソース量を変更できないと判定される。そのためステップＳ２０３の判定処理では「Ｎｏ」となる。

なお、本実施形態では、図１０のステップＳ２０１８の判定処理において、実リソース利用率が閾値以上となった物理リソースについて予測値Ｅが算出される。

ただし、複数又は全ての物理リソースについて予測値Ｅを算出し、（条件１）及び（条件２）満たす論理ホスト３１の組み合わせ及びリソース変更量Ｄを決定してもよい。

なお、前述した判定条件は一例であって、管理者によって適宜変更できる。例えば、統合リソース管理モジュール２１が、対象クラスタ５３及び共有クラスタ５３の実リソース利用率、各クラスタ５３の実リソース利用率の差、論理ホスト３１の組み合わせ、及び、リソース変更量Ｄの一覧をＵＩを用いて管理者に提示して、かつ、論理ホストの組み合わせ及びリソース変更量Ｄを決定するインタフェースを提供してもよい。

また、実リソース利用率の予測値の差が最小ではなく、他の条件に基づいて論理ホスト３１の組み合わせ及びリソース変更量Ｄを決定してもよい。

なお、対象クラスタ５３及び共有クラスタ５３のそれぞれに論理ホスト３１が一つしか含まれない場合は、ステップＳ２０２２の処理では、論理ホスト３１の組み合わせが自動的に決定される。

図１３は、本発明の第１の実施形態におけるリソース変更処理を説明するシーケンス図である。

リソース変更処理では、図１２のステップＳ２０２２において決定された対象クラスタ５３の論理ホスト３１と共有クラスタ５３の論理ホスト３１との間でリソース量が変更される。

以下、対象クラスタ５３の論理ホスト３１を追加対象の論理ホスト３１と記載し、共有クラスタ５３の論理ホスト３１を削減対象の論理ホスト３１と記載する。

統合リソース管理モジュール２１は、クラスタ管理モジュール２２に対して削減対象の論理ホスト３１上で稼動するＶＭ５０の移動を要求する（ステップＳ２０４１）。

クラスタ管理モジュール２２は、ＶＭ５０の移動要求を受け付けると、ＶＭ５０の移動処理を実行する（ステップＳ２０４２）。

具体的には、クラスタ管理モジュール２２は、削減対象の論理ホスト３１上で稼動するＶＭ５０を、共有クラスタ内の他のホスト（物理ホスト３０及び論理ホスト３１）に移動させる。なお、ＶＭ５０の移動方法は、ＶＭ５０上で稼働するＯＳ及びソフトウェアを停止することなく他のホストに移動する方法、ＶＭ５０を一旦停止した後当該ＶＭ５０を他のホストに移動する方法が考えられる。

削減対象の論理ホスト３１を実現するＬＰＡＲ５１のリソース量の割り当てを変更する前にＶＭ５０を移動させることによって、影響を受けるＶＭ５０を解消できる。

なお、影響を受けるＶＭ５０が存在しない場合には、クラスタ管理モジュール２２は、ＶＭ５０の移動処理を実行しなくてもよい。

本実施形態では、削減対象の論理ホスト３１上で稼動する全ＶＭ５０のリソース利用率の合計値が、当該論理ホスト３１に対応するＬＰＡＲ５１に割り当てられる物理リソースからリソース変更量Ｄを減算した値より小さい場合に、影響を受けるＶＭ５０が存在しないものとする。

統合リソース管理モジュール２１は、サーバ管理モジュール２３に対して、削減対象の論理ホスト３１に対応するＬＰＡＲ５１のリソース量の変更を要求する（ステップＳ２０４３）。

サーバ管理モジュール２３は、リソース量の変更要求を受け付けると、削減対象の論理ホスト３１に対応するＬＰＡＲ５１のリソース量を変更する（ステップＳ２０４４）。

具体的には、当該ＬＰＡＲ５１のリソース量からリソース変更量Ｄを減算したリソース量に変更される。このとき、サーバ管理モジュール２３は、サーバテーブル２８を参照し、当該ＬＰＡＲ５１に対応するエントリの構成２８４を更新する。

統合リソース管理モジュール２１は、クラスタ管理モジュール２２に対して共有クラスタ５３のリソース量の変更を要求する（ステップＳ２０４５）。当該変更要求には、リソース変更量Ｄの値が含まれる。

クラスタ管理モジュール２２は、リソース量の変更要求を受け付けると、共有クラスタ５３のリソース量を変更する（ステップＳ２０４６）。

具体的には、共有クラスタ５３のリソース量をリソース変更量Ｄ分だけ減算した値に変更される。このとき、クラスタ管理モジュール２２は、クラスタテーブル２７を参照し、共有クラスタ５３に対応するエントリのクラスタリソース２７２を更新する。すなわち、ＬＰＡＲ５１におけるリソース量の変更が反映される。

クラスタ管理モジュール２２がステップＳ２０４４の処理の実行後、自動的にステップＳ２０４６の処理を実行する場合、ステップＳ２０４５の処理は省略できる。すなわち、サーバ管理モジュール２３が、クラスタ管理モジュール２２にＬＰＡＲ５１のリソース量の変更を通知するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を備える場合には、ステップＳ２０４５の処理は省略できる。

ステップＳ２０４１〜ステップＳ２０４６は、共有クラスタ５３のリソース量が削減される処理である。

次に、統合リソース管理モジュール２１は、サーバ管理モジュール２３に対して、追加対象の論理ホスト３１に対応するＬＰＡＲ５１のリソース量の変更を要求する（ステップＳ２０４７）。当該変更要求には、リソース変更量Ｄの値が含まれる。

サーバ管理モジュール２３は、リソース量の変更要求を受け付けると、追加対象の論理ホスト３１に対応するＬＰＡＲ５１のリソース量を変更する（ステップＳ２０４８）。

具体的には、当該ＬＰＡＲ５１のリソース量がリソース変更量Ｄ分だけ加算される。このとき、サーバ管理モジュール２３は、サーバテーブル２８を参照し、当該ＬＰＡＲ５１に対応するエントリの構成２８４を更新する。

統合リソース管理モジュール２１は、クラスタ管理モジュール２２に対して対象クラスタのリソース量の変更を要求する（ステップＳ２０４９）。当該変更要求には、リソース変更量Ｄの値が含まれる。

クラスタ管理モジュール２２は、リソース量の変更要求を受け付けると、対象クラスタ５３のリソース量を変更する（ステップＳ２０５０）。

具体的には、対象クラスタ５３のリソース量がリソース変更量Ｄ分だけ加算した値に変更される。このとき、クラスタ管理モジュール２２は、クラスタテーブル２７を参照し、対象クラスタ５３に対応するエントリのクラスタリソース２７２を更新する。すなわち、ＬＰＡＲ５１におけるリソース量の変更が反映される。

クラスタ管理モジュール２２がステップＳ２０４６の処理の実行後、自動的にステップＳ２０４８の処理を実行する場合、ステップＳ２０４７の処理は省略できる。すなわち、サーバ管理モジュール２３が、クラスタ管理モジュール２２にＬＰＡＲ５１のリソース量の変更を通知するＡＰＩを備える場合には、ステップＳ２０４７の処理は省略できる。

図１４は、本発明の第１の実施形態におけるリソース変更処理の概要を示す説明図である。

図１４では、クラスタ１が対象クラスタ５３であり、クラスタ２が共有クラスタ５３である場合のリソース変更処理の概要を示す。

このとき、サーバ１が対象クラスタ１及び共有クラスタ２によって共有される。したがって、ステップＳ２０２２において、論理ホスト１及び論理ホスト２がリソース量を変更する論理ホスト３１の組み合わせとして決定される。

また、ステップＳ２０４４において、ＬＰＡＲ２のリソース量がリソース変更量Ｄ分だけ削減される。ステップＳ２０４６において、ＬＰＡＲ２のリソース量の削減がクラスタ２に反映される。

ステップＳ２０４８において、ＬＰＡＲ１のリソース量がリソース変更量Ｄ分だけ追加される。ステップＳ２０５０において、ＬＰＡＲ１におけるリソース量の追加がクラスタ１に反映される。

［第１の実施形態の変形例１］
リソース決定処理では、クラスタ５３に属しない論理ホスト３１を、リソース量を変更する共有クラスタ５３として選択してもよい。この場合、リソース決定処理は以下のようになる。

ステップＳ２０２１では、対象クラスタ５３に属する論理ホスト３１に対応するＬＰＡＲ５１と同一のサーバ４０上に生成されたＬＰＡＲ５１に対応し、かつ、クラスタ５３に属しない論理ホスト３１が共有クラスタ５３として選択される。

ステップＳ２０２２では、クラスタ５３に属しない論理ホスト３１の実リソース利用率を算出し、算出された論理ホスト３１の実リソース利用率に基づいて、削減対象の論理ホスト３１を決定する。なお、クラスタ５３の実リソース利用率を算出する場合に、Ａには、当該論理ホスト３１に対応するＬＰＡＲ５１のスペック情報、すなわち、構成２８４に格納される値が用いられる。

なお、リソース変更処理は、第１の実施形態と同一である。

［第１の実施形態の変形例２］
対象クラスタ５３のリソース量を追加する場合に、対象クラスタ５３に属する論理ホスト３１に対応するＬＰＡＲ５１に、当該ＬＰＡＲ５１が生成されたサーバ４０の空きリソースを追加してもよい。

当該変形例では、リソース管理プログラム２０が、各サーバ４０の空きリソース量を管理する情報を保持する。

図１５は、本発明の第１の実施形態の変形例における空きリソーステーブル２９の一例を示す説明図である。

空きリソーステーブル２９は、サーバ２９１及び空きリソース２９２を含む。サーバ２９１は、サーバ４０の識別子を格納し、サーバ２８１と同一のものである。空きリソース２９２は、サーバ４０における空きリソース量を格納する。

なお、サーバ４０の空きリソース量は、サーバテーブル２８のスペック情報２８２から構成２８４を差分することによって算出することができる。

図１６は、本発明の第１の実施形態の変形例におけるリソース決定処理を説明するフローチャートである。

統合リソース管理モジュール２１は、対象クラスタ５３を構成する論理ホスト３１を特定する（ステップＳ２９０１）。

具体的には、統合リソース管理モジュール２１は、構成テーブル２５を参照し、対象クラスタ５３に対応するエントリのＬＰＡＲ２５４に識別子が格納されるホストを検索する。

次に、統合リソース管理モジュール２１は、特定された論理ホスト３１に対応するＬＰＡＲ５１が生成されるサーバ４０を特定する（ステップＳ２９０２）。

具体的には、統合リソース管理モジュール２１は、特定された論理ホスト３１に対応するＬＰＡＲ５１の識別子を含む検索要求をサーバ管理モジュール２３に出力する。

当該検索要求を受け付けたサーバ管理モジュール２３は、サーバテーブル２８を参照して、ＬＰＡＲ５１が生成されるサーバ４０を特定する。サーバ管理モジュール２３は、特定されたサーバ４０の識別子を統合リソース管理モジュール２１に通知する。

統合リソース管理モジュール２１は、通知されたサーバ４０の識別子に基づいて、空きリソーステーブル２９を参照して、リソース量を変更する論理ホスト３１を決定する（ステップＳ２９０３）。例えば、以下のような方法が考えられる。

まず、統合リソース管理モジュール２１は、特定されたサーバ４０に対応するエントリの空きリソース２９２を参照し、リソース変更量Ｄ以上の空きリソースを保持するサーバ４０を検索する。

さらに、統合リソース管理モジュール２１は、検索されたサーバ４０のうち、空きリソース量が最も多いサーバ４０を特定する。これによって、特定されたサーバ４０上に生成されたＬＰＡＲ５１に対応する論理ホスト３１が、リソース量を変更する論理ホスト３１に決定される。

なお、他の基準に基づいてリソース量を変更する論理ホスト３１を決定してもよい。

リソース変更処理では、以下の点が異なる。

変形例では共有クラスタ５３は考慮する必要がないため、ステップＳ２０４１〜ステップＳ２０４６の処理は実行されない。

ステップＳ２０４８では、サーバ管理モジュール２３は、リソース量を変更する論理ホスト３１に対応するＬＰＡＲ５１に、リソース変更量Ｄ分のリソース量を追加する。このとき、サーバ管理モジュール２３は、サーバテーブル２８を参照し、当該ＬＰＡＲ５１に対応するエントリの構成２８４を更新する。

ステップＳ２０４９では、統合リソース管理モジュール２１は、クラスタ管理モジュール２２に対して対象クラスタ５３のリソース量の変更を要求し、また、空きリソーステーブル２９の対応するエントリを更新する。

変形例１及び変形例２は、物理リソースを有効に活用するとともに、他のクラスタに影響を与えることなくクラスタのリソース量を変更できる。

［第２の実施形態］
第２の実施形態では、リソース変更処理が第１の実施形態と異なる。具体的には、統合リソース管理モジュール２１は、追加対象の論理ホスト３１及び削減対象の論理ホスト３１を停止させ、リソース量が変更された後に各論理ホストを再起動する点が異なる。以下、第１の実施形態との差異を中心に説明する。

第２の実施形態における計算機システムの構成は第１の実施形態と同一であるため説明を省略する。また、管理サーバ１０、サーバ４０のハードウェア構成及びソフトウェア構成は第１の実施形態と同一であるため説明を省略する。また、物理ホスト３０及び論理ホスト３１の構成も第１の実施形態と同一であるため説明を省略する。

さらに、リソース監視処理及びリソース決定処理も第１の実施形態と同一であるため説明を省略する。

図１７は、本発明の第２の実施形態におけるリソース変更処理を説明するシーケンス図である。

統合リソース管理モジュール２１は、クラスタ管理モジュール２２に対して追加対象の論理ホスト３１上で稼動する全てのＶＭ５０の移動を要求する（ステップＳ２５０１）。

クラスタ管理モジュール２２は、ＶＭ５０の移動要求を受け付けると、追加対象の論理ホスト３１上で稼動する全てのＶＭ５０の移動処理を実行する（ステップＳ２５０２）。

具体的には、クラスタ管理モジュール２２は、追加対象の論理ホスト３１上で稼動するＶＭ５０を、対象クラスタ５３内の他のホスト（物理ホスト３０及び論理ホスト３１）に移動する。

なお、ＶＭ５０の移動方法は、ＶＭ５０上で稼働するＯＳ及びソフトウェアを停止することなく他のホストに移動する方法、ＶＭ５０を一旦停止した後当該ＶＭ５０を他のホストに移動する方法が考えられる。

これは、追加対象の論理ホスト３１を停止することによって影響を受けるＶＭ５０を解消するための処理である。なお、追加対象の論理ホスト３１上でＶＭ５０が稼働していない場合、ステップＳ２０５２の処理は省略できる。

統合リソース管理モジュール２１は、クラスタ管理モジュール２２に対して削減対象の論理ホスト３１上で稼動する全てのＶＭ５０の移動を要求する（ステップＳ２５０３）。

クラスタ管理モジュール２２は、ＶＭ５０の移動要求を受け付けると、削減対象の論理ホスト３１上で稼動する全てのＶＭ５０の移動処理を実行する（ステップＳ２５０４）。当該処理は、ステップＳ２０４２と同一の処理である。

これは、削減対象の論理ホスト３１を停止することによって影響を受けるＶＭ５０を解消するための処理である。なお、削減対象の論理ホスト３１上でＶＭ５０が稼働していない場合、ステップＳ２０５４の処理は省略できる。

統合リソース管理モジュール２１は、クラスタ管理モジュール２２に対して、対象クラスタ５３を構成する論理ホスト３１、及び、共有クラスタ５３を構成する論理ホスト３１の停止を要求する（ステップＳ２０５５）。

クラスタ管理モジュール２２は、停止要求を受け付けると、各クラスタ５３を構成する論理ホスト３１を停止する（ステップＳ２０５６）。

クラスタ管理モジュール２２は、論理ホスト３１の停止中に、論理ホスト３１が属するクラスタ５３のリソース量の変更を反映する。

統合リソース管理モジュール２１は、サーバ管理モジュール２３に対して、削減対象の論理ホスト３１に対応するＬＰＡＲ５１のリソース量の変更を要求する（ステップＳ２０５７）。当該処理はステップＳ２０４３と同一である。

サーバ管理モジュール２３は、リソース量の変更要求を受け付けると、削減対象の論理ホスト３１に対応するＬＰＡＲ５１のリソース量を変更する（ステップＳ２０５８）。当該処理は、ステップＳ２０４４と同一である。このとき、サーバ管理モジュール２３によって、サーバテーブル２８の当該ＬＰＡＲ５１に対応するエントリの構成２８４が更新される。

統合リソース管理モジュール２１は、サーバ管理モジュール２３に対して、追加対象の論理ホスト３１に対応するＬＰＡＲ５１のリソース量の変更を要求する（ステップＳ２０５９）。当該処理は、ステップＳ２０４７と同一である。

サーバ管理モジュール２３は、リソース量の変更要求を受け付けると、追加対象の論理ホスト３１に対応するＬＰＡＲ５１のリソース量の割り当てを変更する（ステップＳ２０６０）。当該処理は、ステップＳ２０４８と同一である。

統合リソース管理モジュール２１は、サーバ管理モジュール２３に対して、追加対象の論理ホスト３１に対応するＬＰＡＲ５１、及び、削減対象の論理ホスト３１に対応するＬＰＡＲ５１の起動を要求する（ステップＳ２０６１）。

サーバ管理モジュール２３は、起動要求を受け付けると、各論理ホスト３１に対応するＬＰＡＲ５１を起動する（ステップＳ２０６２）。

これによって、対象クラスタ５３を構成する論理ホスト３１と共有クラスタ５３を構成する論理ホスト３１が起動する。

なお、論理ホスト３１が起動した後、クラスタ管理モジュール２２は、該当論理ホスト３１が属するクラスタ５３のリソース量の変更をクラスタテーブル２７に反映する。

［第３の実施形態］
第３の実施形態では、ＬＰＡＲ５１を他のサーバ４０に移動することによって当該ＬＰＡＲ５１に割り当てられるリソース量を変更する点が第１の実施形態と異なる。以下、第１の実施形態との差異を中心に説明する。

第３の実施形態における計算機システムの構成は第１の実施形態と同一であるため説明を省略する。また、管理サーバ１０、サーバ４０のハードウェア構成及びソフトウェア構成は第１の実施形態と同一であるため説明を省略する。また、物理ホスト３０及び論理ホスト３１の構成も第１の実施形態と同一であるため説明を省略する。

さらに、リソース監視処理も第１の実施形態と同一であるため説明を省略する。

図１８は、本発明の第３の実施形態におけるリソース決定処理を説明するフローチャートである。

統合リソース管理モジュール２１は、対象クラスタ５３と同一のサーバ４０の物理リソースを共有する共有クラスタ５３を特定する（ステップＳ２０２１）。

統合リソース管理モジュール２１は、移動対象の論理ホスト３１が対象クラスタ５３を構成する論理ホスト３１であるか否かを判定する（ステップＳ２０７１）。ここで、移動対象の論理ホストとは、リソース変更処理の実行時に、論理ホスト３１に対応するＬＰＡＲ５１を他のサーバ４０へと移動する論理ホスト３１を示す。具体的には以下のような判定処理が実行される。

まず、統合リソース管理モジュール２１は、共有クラスタ５３が存在するか否かを判定する。

共有クラスタ５３が存在しないと判定された場合、統合リソース管理モジュール２１は、移動対象となる論理ホスト３１が共有クラスタ５３を構成する論理ホスト３１ではないと判定する。

共有クラスタ５３が存在すると判定された場合、共有クラスタ５３を構成する論理ホスト３１が移動可能か否かを判定する。

統合リソース管理モジュール２１は、所定の基準値に基づいて、又は、共有クラスタ５３の実リソース利用率と他のクラスタ５３の実リソース利用率との比較結果に基づいて、判定処理を実行する。また、管理者がＵＩ等を用いて、共有クラスタ５３を構成する論理ホスト３１が移動するか否かを選択してもよい。

共有クラスタ５３を構成する論理ホスト３１が移動可能である場合には、移動対象となる論理ホスト３１が共有クラスタ５３を構成する論理ホスト３１であると判定される。

移動対象が共有クラスタ５３を構成する論理ホスト３１であると判定された場合、統合リソース管理モジュール２１は、共有クラスタ５３を構成する論理ホスト３１の中から移動対象となる論理ホスト３１を決定する（ステップＳ２０７２）。

複数の論理ホスト３１から共有クラスタ５３が構成される場合、リソース利用率が最も大きい論理ホスト３１、又は、リソース量が最小のＬＰＡＲ５１に対応する論理ホスト３１を移動対象として選択する方法が考えられる。本発明は前述した判定方法に限定されず、他の基準に基づいて移動対象となる論理ホスト３１を決定してもよい。

統合リソース管理モジュール２１は、移動対象として決定された論理ホスト３１の移動先のサーバ４０を決定する（ステップＳ２０７３）。

移動先のサーバ４０を決定する方法としては、移動対象である論理ホスト３１に対応するＬＰＡＲ５１のリソース量（構成２８４）以上の空きリソースが存在するサーバ４０を選択する方法が考えられる。

なお、サーバ４０の空きリソース量は、サーバテーブル２８のスペック情報２８２から、サーバ４０に生成された各ＬＰＡＲ５１の構成２８４の合計値を減算することによって算出することができる。

例えば、図６において、サーバ２８１が「Ｓ１」であるサーバ４０の空きリソース量は、ＣＰＵについては「２ＧＨｚ×２」、メモリについては「１２８ＧＢ」、またＩ／Ｏデバイスについては「１０Ｇｂ ＣＮＡ×２」と算出される。

なお、サーバ管理モジュール２３が、予め算出した各サーバ４０の空きリソース量を保持していてもよい。

ステップＳ２０７３の処理において、論理分割プログラム７０が実行されていないサーバ４０は、すなわち、論理ホスト３１が稼動していないサーバ４０は、移動先のサーバ４０の候補から除外してもよい。ただし、移動先のサーバ４０の候補から除外しない場合には、統合リソース管理モジュール２１は、論理分割プログラム７０の実行を当該サーバ４０に指示する。

このとき、サーバ４０は、論理分割プログラム７０を実行してＬＰＡＲ５１を生成する。さらに、サーバ４０は、当該サーバ４０上で稼働していた物理ホスト３０を生成されたＬＰＡＲ５１に対応する論理ホスト３１に変換する。その後、統合リソース管理モジュール２１は、ステップＳ２０７３の処理を実行する。

なお、論理分割プログラム７０を含まないサーバ４０についても、稼動中のＶＭ５０を同一又は異なるサーバ４０上のＬＰＡＲ５１に移動させることによって、移動先のサーバ４０の候補としてもよい。

ステップＳ２０７１において、移動対象が対象クラスタ５３を構成する論理ホスト３１であると判定された場合、統合リソース管理モジュール２１は、対象クラスタ５３を構成する論理ホスト３１の中から移動対象となる論理ホスト３１を決定する（ステップＳ２０７４）。

なお、移動対象となる論理ホスト３１を決定する方法は、ステップＳ２０７２と同一の方法を用いることが考えられる。

統合リソース管理モジュール２１は、移動対象として決定された論理ホスト３１の移動先のサーバ４０を決定する（ステップＳ２０７５）。

移動先のサーバ４０を決定する方法としては、移動対象となる論理ホスト３１に対応するＬＰＡＲ５１に割り当てられたリソース量（構成２８４）にリソース変更量Ｄを加算した値以上の空きリソースが存在するサーバ４０を選択する方法が考えられる。

なお、論理分割プログラム７０が実行されていないサーバ４０は、移動先のサーバ４０の候補から除外してもよい。

ただし、移動先のサーバ４０の候補から除外しない場合には、統合リソース管理モジュール２１は、論理分割プログラム７０の実行を当該サーバ４０に指示する。このとき、サーバ４０は、論理分割プログラム７０を実行してＬＰＡＲ５１を生成する。さらに、サーバ４０は、当該サーバ４０上で稼動する物理ホスト３０を、生成されたＬＰＡＲ５１に対応する論理ホスト３１に変換する。その後、統合リソース管理モジュール２１は、ステップＳ２０７５の処理を実行する。

図１９は、本発明の第３の本実施形態におけるリソース変更処理を説明するシーケンス図である。

統合リソース管理モジュール２１は、サーバ管理モジュール２３に対して、移動対象として決定された論理ホスト３１に対応するＬＰＡＲ５１の移動を要求する（ステップＳ２０８１）。

当該移動要求には、移動対象として決定された論理ホスト３１に対応するＬＰＡＲ５１の識別子、及び、移動先のサーバ４０の識別子が含まれる。

サーバ管理モジュール２３は、移動要求を受け付けると、移動対象の論理ホスト３１に対応するＬＰＡＲ５１の移動処理を実行する（ステップＳ２０８２）。

ここで、ＬＰＡＲ５１の移動方法としては、ＬＰＡＲ５１上で実行される仮想化プログラム６０及びＶＭ５０を停止せずに移動させる方法が考えられる。また、一旦ＬＰＡＲ５１を停止させ、ＬＰＡＲ５１移動先のサーバ４０に移動させた後、ＬＰＡＲを再起動する方法も考えられる。なお、ＬＰＡＲ５１を停止させる場合には、当該ＬＰＡＲ５１に対応する論理ホスト３１上で稼働するＶＭ５０を他のホストに移動させることが望ましい。

統合リソース管理モジュール２１は、サーバ管理モジュール２３に対して、対象クラスタ５３を構成する論理ホスト３１に対応するＬＰＡＲ５１のリソース量の割り当て変更を要求する（ステップＳ２０８３）。

ここで、リソース量の変更対象となる論理ホスト３１は、移動対象となる論理ホスト３１によって異なる。

移動対象となる論理ホスト３１が共有クラスタ５３を構成する論理ホスト３１である場合、移動対象である論理ホスト３１と同一のサーバ４０上に存在する論理ホスト３１に対応するＬＰＡＲ５１がリソース量の変更対象となる。

一方、移動対象となる論理ホスト３１が対象クラスタを構成する論理ホスト３１である場合、移動対象である論理ホスト３１に対応するＬＰＡＲ５１がリソース量の変更対象となる。

サーバ管理モジュール２３は、変更要求を受け付けると、リソース量の変更対象となるＬＰＡＲ５１のリソース量を変更する（ステップＳ２０８４）。

具体的には、変更対象であるＬＰＡＲ５１のリソース量がリソース変更量Ｄ分だけ追加される。

統合リソース管理モジュール２１は、クラスタ管理モジュール２２に対して、対象クラスタ５３のリソース量の変更を要求する（ステップＳ２０８５）。当該変更要求には、リソース変更量Ｄの値が含まれる。

クラスタ管理モジュール２２は、変更要求を受け付けると、対象クラスタ５３のリソース量を変更する（ステップＳ２０８６）。

具体的には、対象クラスタ５３のリソース量がリソース変更量Ｄ分だけ追加された値に変更される。このとき、クラスタ管理モジュール２２は、クラスタテーブル２７を参照し、対象クラスタ５３に対応するエントリのクラスタリソース２７２を更新する。すなわち、ＬＰＡＲ５１に追加されたリソース量の変更が反映される。

なお、クラスタ管理モジュール２２がステップＳ２０８４の処理の実行後、自動的にステップＳ２０８６の処理を実行する場合、ステップＳ２０８５の処理は省略できる。すなわち、サーバ管理モジュール２３が、クラスタ管理モジュール２２にＬＰＡＲ５１のリソース量の変更を通知するＡＰＩを備える場合には、ステップＳ２０８５の処理は省略できる。

図２０は、本発明の第３の実施形態におけるリソース変更処理の概要を示す説明図である。

図２０では、クラスタ２が対象クラスタ５３、論理ホスト２が移動対象となる論理ホスト３１、また、サーバ１が移動先のサーバ４０である場合のリソース変更処理の概要を示す。

ステップＳ２０８２では、論理ホスト２に対応するＬＰＡＲ２がサーバ２からサーバ１に移動される。

ステップＳ２０８４では、サーバ１に移動したＬＰＡＲ２のリソース量がリソース変更量Ｄ分だけ追加される。

ステップＳ２０８６では、ＬＰＡＲ２のリソース量の追加がクラスタ２のリソース量の増加として反映される。

［第３の実施形態の変形例］
第３の実施形態のリソース決定処理では、クラスタ５３に属しない論理ホスト３１を、リソース量を変更する共有クラスタ５３として選択してもよい。この場合、リソース決定処理は以下のようになる。

ステップＳ２０２１では、対象クラスタ５３に属する論理ホスト３１に対応するＬＰＡＲ５１と同一のサーバ４０上に生成されたＬＰＡＲ５１に対応し、かつ、クラスタ５３に属しない論理ホスト３１が共有クラスタ５３として選択される。他の処理は同一であるため説明を省略する。

また。リソース変更処理は、第３の実施形態と同一であるため説明を省略する。

本発明の一実施形態によれば、論理ホスト３１から構成されるクラスタ５３を備えることによって、クラスタ５３を構成するホスト数を増減することなく、ホストの負荷に応じてクラスタ５３のリソース量を変更することができる。

特許請求の範囲に記載した以外の発明の観点の代表的なものとして、次のものがあげられる。
（１）仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムにおけるリソース管理方法であって、
前記各計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第１のプロセッサに接続される第１のＩ／Ｏインタフェースとを有し、
前記管理計算機は、第２のプロセッサと、前記第２のプロセッサに接続される第２のメモリと、前記第２のプロセッサに接続される第２のＩ／Ｏインタフェースとを有し、
前記ホストは、
前記第１のプロセッサが、前記仮想化プログラムを実行する物理ホストと、
前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、
を含み、
前記管理計算機は、複数の前記ホストを一つのリソースグループとするクラスタが有するリソースを管理するリソース管理部を有し、
前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、
前記リソース管理方法は、
前記リソース管理部が、前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定する第１のステップと、
前記リソース管理部が、前記対象論理ホストに対する物理リソースの割り当て量を変更する第２のステップと、を含むことを特徴とするリソース管理方法。
（２）前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、
前記第２のステップは、
前記リソース管理部が、物理リソースの割り当てが変更可能な他の前記論理区画を特定するステップと、
前記リソース管理部が、前記他の論理区画に割り当てられた物理リソースの変更要求を前記論理区画管理部に送信するステップと、
前記論理区画管理部が、前記他の論理区画に割り当てられた物理リソースを所定量だけ削減するステップと、
前記リソース管理部が、前記対象論理ホストに対応する前記論理区画に割り当てられる物理リソースの変更要求を前記論理区画管理部に送信するステップと、
前記論理区画管理部が、前記対象論理ホストに対応する前記論理区画に、前記所定量の物理リソースを追加するステップと、を含むことを特徴とする（１）に記載にリソース管理方法。
（３）前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、
前記第２のステップでは、
前記リソース管理部が、前記対象論理ホストに対応する前記論理区画の移動要求を前記論理区画管理部に送信するステップと、
前記論理区画管理部が、前記対象論理ホストに対応する論理区画を、他の前記計算機上に移動させるステップと、
前記リソース管理部が、前記対象論理ホストに対応する論理区画に割り当てられた物理リソースの変更要求を送信するステップと、
前記論理区画管理部が、前記対象論理ホストに対応する論理区画に、所定量の物理リソースを追加するステップと、を含むことを特徴とする（１）に記載にリソース管理方法。
（４）前記論理区画管理部は、前記対象論理ホストに対応する論理区画の物理リソースを変更した後に、前記クラスタ管理部に変更結果を送信するステップと、
前記クラスタ管理部が、前記対象論理ホストに対応する論理区画の物理リソースの変更結果を反映するステップと、を含むことを特徴とする請求項（２）又は（３）に記載のリソース管理方法。
（５）仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムであって、
前記各計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第１のプロセッサに接続される第１のＩ／Ｏインタフェースとを有し、
前記管理計算機は、第２のプロセッサと、前記第２のプロセッサに接続される第２のメモリと、前記第２のプロセッサに接続される第２のＩ／Ｏインタフェースとを有し、
前記ホストは、
前記第１のプロセッサが、前記仮想化プログラムを実行する物理ホストと、
前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、
を含み、
前記管理計算機は、複数の前記ホストを一つのリソースグループとするクラスタが有するリソースを管理するリソース管理部を有し、
前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、
前記計算機システムは、
前記リソース管理部が、
前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定し、
前記対象論理ホストに対する物理リソースの割り当て量を変更することを特徴とする計算機システム。
（６）前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、
前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、前記リソース管理部が、物理リソースの割り当てが変更可能な他の前記論理区画を特定し、
前記リソース管理部が、前記他の論理区画に割り当てられた物理リソースの変更要求を前記論理区画管理部に送信し、
前記論理区画管理部が、前記他の論理区画に割り当てられた物理リソースを所定量だけ削減し、
前記リソース管理部が、前記対象論理ホストに対応する前記論理区画に割り当てられる物理リソースの変更要求を前記論理区画管理部に送信し、
前記論理区画管理部が、前記対象論理ホストに対応する前記論理区画に、前記所定量の物理リソースを追加することを特徴とする（５）に記載に計算機システム。
（７）前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、
前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、前記リソース管理部が、前記対象論理ホストに対応する前記論理区画の移動要求を前記論理区画管理部に送信し、
前記論理区画管理部が、前記対象論理ホストに対応する論理区画を、他の前記計算機上に移動させ、
前記リソース管理部が、前記対象論理ホストに対応する論理区画に割り当てられた物理リソースの変更要求を送信し、
前記論理区画管理部が、前記対象論理ホストに対応する論理区画に、所定量の物理リソースを追加することを特徴とする（５）に記載に計算機システム。
（８）前記論理区画管理部は、前記対象論理ホストに対応する論理区画の物理リソースを変更した後に、前記クラスタ管理部に変更結果を送信し、
前記クラスタ管理部が、前記対象論理ホストに対応する論理区画の物理リソースの変更結果を反映することを特徴とする請求項（６）又は（７）に記載の計算機システム。

１０ 管理サーバ
１５ 入出力装置
１６ 管理ネットワーク
２０ リソース管理プログラム
２１ 統合リソース管理モジュール
２２ クラスタ管理モジュール
２３ サーバ管理モジュール
２５ 構成テーブル
２７ クラスタテーブル
２８ サーバテーブル
２９ 空きリソーステーブル
３０ 物理ホスト
３１ 論理ホスト
４０ サーバ
４１ ネットワーク機器
４５ ストレージ装置
５０ ＶＭ
５１ ＬＰＡＲ
５３ クラスタ
６０ 仮想化プログラム
７０ 論理分割プログラム
９０ リソースプール

Claims (18)

1. 仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムにおけるリソース管理方法であって、
   前記各計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第１のプロセッサに接続される第１のＩ／Ｏインタフェースとを有し、
   前記管理計算機は、第２のプロセッサと、前記第２のプロセッサに接続される第２のメモリと、前記第２のプロセッサに接続される第２のＩ／Ｏインタフェースとを有し、
   前記ホストは、
   前記第１のプロセッサが、前記仮想化プログラムを実行する物理ホストと、
   前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、
   を含み、
   前記管理計算機は、複数の前記ホストから構成されるクラスタが有する物理リソースを管理するリソース管理部を有し、
   前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、
   前記リソース管理方法は、
   前記リソース管理部が、前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定する第１のステップと、
   前記リソース管理部が、前記対象論理ホストに対する物理リソースの割り当て量を変更する第２のステップと、
   を含むことを特徴とするリソース管理方法。
2. 前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、
   前記第１のステップは、
   前記クラスタ管理部が、前記物理ホストの負荷情報を取得する第３のステップと、
   前記論理区画管理部が、前記論理区画に対応する前記論理ホストの負荷情報を取得する第４のステップと、
   前記リソース管理部が、前記物理ホストの負荷情報及び前記論理ホストの負荷情報を取得して、前記複合クラスタにおける負荷を表す負荷値を算出する第５のステップと、
   前記リソース管理部が、前記算出された負荷値に基づいて、前記ホストの負荷を分散するための物理リソースが不足している第１の複合クラスタを特定する第６のステップと、
   を含むことを特徴とする請求項１に記載のリソース管理方法。
3. 前記物理ホストの負荷情報は、前記物理ホスト上で稼動する前記仮想計算機によって使用される前記計算機が有する物理リソースの使用率を表す第１のリソース利用率であり、
   前記論理ホストの負荷情報は、前記論理ホスト上で稼動する前記仮想計算機によって使用される前記論理区画に割り当てられた物理リソースの使用率を表す第２のリソース利用率であり、
   前記負荷値は、前記クラスタが有する物理リソースに対する使用率を表す第３のリソース利用率であり、
   前記第６のステップは、前記取得された第１のリソース利用率、及び、前記取得された第２のリソース利用率に基づいて、前記第３のリソース利用率を算出することを特徴とする請求項２に記載のリソース管理方法。
4. 前記リソース管理部は、前記クラスタの構成を管理する構成情報を保持し、
   前記第５のステップは、
   前記構成情報を参照し、前記第１の複合クラスタを構成する前記物理ホスト及び前記論理ホストを特定するステップと、
   前記特定された物理ホストの識別情報を含む物理ホストの負荷情報の取得要求を前記クラスタ管理部に送信するステップと、
   前記特定された論理ホストの識別情報を含む論理ホストの負荷情報の取得要求を前記論理区画管理部に送信するステップと、
   を含むことを特徴とする請求項２に記載のリソース管理方法。
5. 前記第２のステップは、
   物理リソースの割り当てが変更可能な他の前記論理区画を特定するステップと、
   前記他の論理区画に割り当てられた物理リソースを所定量だけ削減するステップと、
   前記対象論理ホストに対応する前記論理区画に、前記所定量の物理リソースを追加するステップと、
   を含むことを特徴とする請求項１に記載のリソース管理方法。
6. 前記物理リソースの割り当てが変更可能な他の論理区画は、前記対象論理ホストに対応する前記論理区画が生成された同一の前記計算機上に生成される前記論理区画であり、かつ、前記ホストの負荷を分散するための物理リソースが不足している第１の複合クラスタとは異なる第２の複合クラスタを構成する前記論理ホストに対応する前記論理区画であることを特徴とする請求項５に記載のリソース管理方法。
7. 前記物理リソースの割り当てが変更可能な他の論理区画は、前記クラスタを構成しない前記論理ホストに対応する前記論理区画であることを特徴とする請求項５に記載のリソース管理方法。
8. 前記第２のステップでは、前記対象論理ホストに対応する前記論理区画を、他の前記計算機上に移動させることを特徴とする請求項１に記載のリソース管理方法。
9. 前記第２のステップでは、前記対象論理ホストに対応する前記論理区画が生成された前記計算機の空きリソースを、当該論理区画に追加することを特徴とする請求項１に記載のリソース管理方法。
10. 仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムであって、
    前記各計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第１のプロセッサに接続される第１のＩ／Ｏインタフェースとを有し、
    前記管理計算機は、第２のプロセッサと、前記第２のプロセッサに接続される第２のメモリと、前記第２のプロセッサに接続される第２のＩ／Ｏインタフェースとを有し、
    前記ホストは、
    前記第１のプロセッサが、前記仮想化プログラムを実行する物理ホストと、
    前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、
    を含み、
    前記管理計算機は、複数の前記ホストから構成されるクラスタが有する物理リソースを管理するリソース管理部を有し、
    前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、
    前記計算機システムは、
    前記リソース管理部が、前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定し、
    前記リソース管理部が、前記対象論理ホストに対する物理リソースの割り当て量を変更することを特徴とする計算機システム。
11. 前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、
    前記ホストの負荷を分散するための物理リソースが不足している第１の複合クラスタを特定する場合に、前記クラスタ管理部が、前記物理ホストの負荷情報を取得し、
    前記論理区画管理部が、前記論理区画に対応する前記論理ホストの負荷情報を取得し、
    前記リソース管理部が、
    前記物理ホストの負荷情報及び前記論理ホストの負荷情報を取得して、前記複合クラスタにおける負荷を表す負荷値を算出し、
    前記算出された負荷値に基づいて、前記第１の複合クラスタを特定することを特徴とする請求項１０に記載の計算機システム。
12. 前記物理ホストの負荷情報は、前記物理ホスト上で稼動する前記仮想計算機によって使用される前記計算機が有する物理リソースの使用率を表す第１のリソース利用率であり、
    前記論理ホストの負荷情報は、前記論理ホスト上で稼動する前記仮想計算機によって使用される前記論理区画に割り当てられた物理リソースの使用率を表す第２のリソース利用率であり、
    前記負荷値は、前記クラスタが有する物理リソースに対する使用率を表す第３のリソース利用率であり、
    前記第３のリソース利用率は、前記取得された第１のリソース利用率、及び、前記取得された第２のリソース利用率に基づいて算出されることを特徴とする請求項１１に記載の計算機システム。
13. 前記リソース管理部は、
    前記クラスタの構成を管理する構成情報を保持し、
    前記物理ホストの負荷情報及び前記論理ホストの負荷情報を取得する場合に、前記構成情報を参照し、前記第１の複合クラスタを構成する前記物理ホスト及び前記論理ホストを特定し、
    前記特定された物理ホストの識別情報を含む物理ホストの負荷情報の取得要求を前記クラスタ管理部に送信し、
    前記特定された論理ホストの識別情報を含む論理ホストの負荷情報の取得要求を前記論理区画管理部に送信することを特徴とする請求項１１に記載の計算機システム。
14. 前記リソース管理部は、
    前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、物理リソースの割り当てが変更可能な他の前記論理区画を特定し、
    前記他の論理区画に割り当てられた物理リソースを所定量だけ削減し、
    前記対象論理ホストに対応する前記論理区画に、前記所定量の物理リソースを追加することを特徴とする請求項１０に記載の計算機システム。
15. 前記物理リソースの割り当てが変更可能な他の論理区画は、前記対象論理ホストに対応する前記論理区画が生成された同一の前記計算機上に生成される前記論理区画であり、かつ、前記ホストの負荷を分散するための物理リソースが不足している第１の複合クラスタとは異なる第２の複合クラスタを構成する前記論理ホストに対応する前記論理区画であることを特徴とする請求項１４に記載の計算機システム。
16. 前記物理リソースの割り当てが変更可能な他の論理区画は、前記クラスタを構成しない前記論理ホストに対応する前記論理区画であることを特徴とする請求項１４に記載の計算機システム。
17. 前記リソース管理部は、
    前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、前記対象論理ホストに対応する前記論理区画を、他の前記計算機上に移動させることを特徴とする請求項１０に記載の計算機システム。
18. 前記リソース管理部は、
    前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、前記対象論理ホストに対応する前記論理区画が生成された前記計算機の空きリソースを、当該論理区画に追加することを特徴とする請求項１０に記載の計算機システム。

Images