仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムにおけるリソース管理方法であって、前記各計算機は、第1のプロセッサと、前記第1のプロセッサに接続される第1のメモリと、前記第1のプロセッサに接続される第1のI/Oインタフェースとを有し、前記管理計算機は、第2のプロセッサと、前記第2のプロセッサに接続される第2のメモリと、前記第2のプロセッサに接続される第2のI/Oインタフェースとを有し、前記ホストは、前記第1のプロセッサが、前記仮想化プログラムを実行する物理ホストと、前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、を含み、前記管理計算機は、複数の前記ホストから構成されるクラスタが有する物理リソースを管理するリソース管理部を有し、前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、前記リソース管理方法は、前記リソース管理部が、前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定する第1のステップと、前記リソース管理部が、前記対象論理ホストに対する物理リソースの割り当て量を変更する第2のステップと、を含むことを特徴とするリソース管理方法。前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、前記第1のステップは、前記クラスタ管理部が、前記物理ホストの負荷情報を取得する第3のステップと、前記論理区画管理部が、前記論理区画に対応する前記論理ホストの負荷情報を取得する第4のステップと、前記リソース管理部が、前記物理ホストの負荷情報及び前記論理ホストの負荷情報を取得して、前記複合クラスタにおける負荷を表す負荷値を算出する第5のステップと、前記リソース管理部が、前記算出された負荷値に基づいて、前記ホストの負荷を分散するための物理リソースが不足している第1の複合クラスタを特定する第6のステップと、を含むことを特徴とする請求項1にリソース管理方法。前記物理ホストの負荷情報は、前記物理ホスト上で稼動する前記仮想計算機によって使用される前記計算機が有する物理リソースの使用率を表す第1のリソース利用率であり、前記論理ホストの負荷情報は、前記論理ホスト上で稼動する前記仮想計算機によって使用される前記論理区画に割り当てられた物理リソースの使用率を表す第2のリソース利用率であり、前記負荷値は、前記クラスタが有する物理リソースに対する使用率を表す第3のリソース使用率であり、前記第6のステップは、前記取得された第1のリソース使用率、及び、前記取得された第2のリソース使用率に基づいて、前記第3のリソース使用率を算出することを特徴とする請求項2に記載のリソース管理方法。前記リソース管理部は、前記クラスタの構成を管理する構成情報を保持し、前記第5のステップは、前記構成情報を参照し、前記第1の複合クラスタを構成する前記物理ホスト及び前記論理ホストを特定するステップと、前記特定された物理ホストの識別情報を含む物理ホストの負荷情報の取得要求を前記クラスタ管理部に送信するステップと、前記特定された論理ホストの識別情報を含む論理ホストの負荷情報の取得要求を前記論理区画管理部に送信するステップと、を含むことを特徴とする請求項2に記載のリソース管理方法。前記第2のステップは、物理リソースの割り当てが変更可能な他の前記論理区画を特定するステップと、前記他の論理区画に割り当てられた物理リソースを所定量だけ削減するステップと、前記対象論理ホストに対応する前記論理区画に、前記所定量の物理リソースを追加するステップと、を含むことを特徴とする請求項1に記載にリソース管理方法。前記物理リソースの割り当てが変更可能な他の論理区画は、前記対象論理ホストに対応する前記論理区画が生成された同一の前記計算機上に生成される前記論理区画であり、かつ、前記第1の複合クラスタとは異なる第2の複合クラスタを構成する前記論理ホストに対応する前記論理区画であることを特徴とする請求項5に記載のリソース管理方法。前記物理リソースの割り当てが変更可能な他の論理区画は、前記クラスタを構成しない前記論理ホストに対応する前記論理区画であることを特徴とする請求項5に記載のリソース管理方法。前記第2のステップでは、前記対象論理ホストに対応する前記論理区画を、他の前記計算機上に移動させることを特徴とする請求項1に記載のリソース管理方法。前記第2のステップでは、前記対象論理ホストに対応する前記論理区画が生成された前記計算機の空きリソースを、当該論理区画に追加することを特徴とする請求項1に記載のリソース管理方法。仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムであって、前記各計算機は、第1のプロセッサと、前記第1のプロセッサに接続される第1のメモリと、前記第1のプロセッサに接続される第1のI/Oインタフェースとを有し、前記管理計算機は、第2のプロセッサと、前記第2のプロセッサに接続される第2のメモリと、前記第2のプロセッサに接続される第2のI/Oインタフェースとを有し、前記ホストは、前記第1のプロセッサが、前記仮想化プログラムを実行する物理ホストと、前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、を含み、前記管理計算機は、複数の前記ホストから構成されるクラスタが有する物理リソースを管理するリソース管理部を有し、前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、前記計算機システムは、前記リソース管理部が、前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定し、前記リソース管理部が、前記対象論理ホストに対する物理リソースの割り当て量を変更することを特徴とする計算機システム。前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、前記対象クラスタを特定する場合に、前記クラスタ管理部が、前記物理ホストの負荷情報を取得し、前記論理区画管理部が、前記論理区画に対応する前記論理ホストの負荷情報を取得し、前記リソース管理部が、前記物理ホストの負荷情報及び前記論理ホストの負荷情報を取得して、前記複合クラスタにおける負荷を表す負荷値を算出し、前記算出された負荷値に基づいて、前記ホストの負荷を分散するための物理リソースが不足している第1の複合クラスタを特定することを特徴とする請求項10に計算機システム。前記物理ホストの負荷情報は、前記物理ホスト上で稼動する前記仮想計算機によって使用される前記計算機が有する物理リソースの使用率を表す第1のリソース利用率であり、前記論理ホストの負荷情報は、前記論理ホスト上で稼動する前記仮想計算機によって使用される前記論理区画に割り当てられた物理リソースの使用率を表す第2のリソース利用率であり、前記負荷値は、前記クラスタが有する物理リソースに対する使用率を表す第3のリソース使用率であり、前記第3のリソース利用率は、前記取得された第1のリソース使用率、及び、前記取得された第2のリソース使用率に基づいて算出されることを特徴とする請求項11に記載の計算機システム。前記リソース管理部は、前記クラスタの構成を管理する構成情報を保持し、前記物理ホストの負荷情報及び前記論理ホストの負荷情報を取得する他場合に、前記構成情報を参照し、前記第1の複合クラスタを構成する前記物理ホスト及び前記論理ホストを特定し、前記特定された物理ホストの識別情報を含む物理ホストの負荷情報の取得要求を前記クラスタ管理部に送信し、前記特定された論理ホストの識別情報を含む論理ホストの負荷情報の取得要求を前記論理区画管理部に送信することを特徴とする請求項11に記載の計算機システム。前記リソース管理部は、前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、物理リソースの割り当てが変更可能な他の前記論理区画を特定し、前記他の論理区画に割り当てられた物理リソースを所定量だけ削減し、前記対象論理ホストに対応する前記論理区画に、前記所定量の物理リソースを追加することを特徴とする請求項10に記載に計算機システム。前記物理リソースの割り当てが変更可能な他の論理区画は、前記対象論理ホストに対応する前記論理区画が生成された同一の前記計算機上に生成される前記論理区画であり、かつ、前記第1の複合クラスタとは異なる第2の複合クラスタを構成する前記論理ホストに対応する前記論理区画であることを特徴とする請求項14に記載の計算機システム。前記物理リソースの割り当てが変更可能な他の論理区画は、前記クラスタを構成しない前記論理ホストに対応する前記論理区画であることを特徴とする請求項14に記載の計算機システム。前記リソース管理部は、前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、前記対象論理ホストに対応する前記論理区画を、他の前記計算機上に移動させることを特徴とする請求項10に記載の計算機システム。前記リソース管理部は、前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、前記対象論理ホストに対応する前記論理区画が生成された前記計算機の空きリソースを、当該論理区画に追加することを特徴とする請求項10に記載の計算機システム。VMの移動させるためには、複数のサーバがストレージを共有するクラスタを構成する必要がある。クラスタに登録されたサーバ間において、VMを移動させることができる。これによって、特定のサーバの負荷を平準化することができる。しかし、従来の仮想化技術では、クラスタに登録できるサーバ数には制限がある。そのため、VMの移動範囲はクラスタに登録できるサーバ数の範囲に制限される。したがって、クラスタに新たにサーバを追加して特定のサーバの負荷を平準化することができない場合がある。本発明は、クラスタに登録できるサーバ数が制限されていても、クラスタ内のサーバの負荷を平準化すること可能とする仮想化技術を提供することを目的とする。本発明の代表的な一例を示せば以下の通りである。すなわち、仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムにおけるリソース管理方法であって、前記各計算機は、第1のプロセッサと、前記第1のプロセッサに接続される第1のメモリと、前記第1のプロセッサに接続される第1のI/Oインタフェースとを有し、前記管理計算機は、第2のプロセッサと、前記第2のプロセッサに接続される第2のメモリと、前記第2のプロセッサに接続される第2のI/Oインタフェースとを有し、前記ホストは、前記第1のプロセッサが、前記仮想化プログラムを実行する物理ホストと、前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、を含み、前記管理計算機は、複数の前記ホストから構成されるクラスタが有する物理リソースを管理するリソース管理部を有し、前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、前記リソース管理方法は、前記リソース管理部が、前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定する第1のステップと、前記リソース管理部が、前記対象論理ホストに対する物理リソースの割り当て量を変更する第2のステップと、を含むことを特徴とする。本発明によれば、クラスタを構成するホスト数を変更することなく、物理リソースが不足しているクラスタのリソース量を変更することができる。したがって、クラスタの登録されるサーバ間の負荷を平準化できる。以下に、本発明の実施形態について図面を用いて説明する。[第1の実施形態]図1は、本発明の第1の実施形態における計算機システムの構成例を説明するブロック図である。本実施形態における計算機システムは、管理サーバ10、入出力装置15、管理ネットワーク16、サーバ40、ネットワーク機器41及びストレージ装置45から構成される。管理サーバ10と各サーバ40とは管理ネットワーク16を介して接続される。また、各サーバ40は、ネットワーク機器41を介してストレージ装置45と接続される。管理サーバ10は、計算機システム全体を管理する。また、管理サーバ10は、リソースプール90を管理する。なお、本実施形態では、サーバ40、ネットワーク機器41及びストレージ装置45が備える物理リソースが一つのリソースプール90として管理される。管理サーバ10は、CPU11、メモリ12及びNICNetworkInterfaceCard13を備える。CPU11は、メモリ12上に展開されるプログラムを実行する。CPU11が所定のプログラムを実行することによって管理サーバ10が備える機能を実現することができる。メモリ12は、CPU11によって実行されるプログラム及び当該プログラムを実行するために必要な情報を格納する。具体的には、メモリ12は、リソース管理プログラム20を格納する。なお、他のプログラムが格納されていてもよい。リソース管理プログラム20は、リソースプール90を管理するプログラムである。以下、リソース管理プログラム20を主語に処理を説明するときには、CPU11によってリソース管理プログラム20が実行されていることを示す。なお、リソース管理プログラム20の詳細については、図4を用いて後述する。なお、リソース管理プログラム20によって実現される機能を、管理サーバ10が搭載するハードウェア、ファームウェア、又はこれらの組み合わせによって、例えば、リソース管理部として実装してもよい。NIC13は、リソースプール90に含まれるサーバ40に接続するためのインタフェースである。また、管理サーバ10には、当該管理サーバ10を操作するための入出力装置15が接続される。入出力装置15は、マウス、キーボード及びディスプレイなどの装置であり、管理サーバ10と管理者との間で情報を入出力するために利用される。サーバ40は、複数の仮想計算機VM50を稼動させるための仮想化環境を提供する。本実施形態では、一つのホスト上に一つ以上のVM50が稼動する。ここで、ホストは、VM50を管理する仮想化プログラム60図2A及び図2B参照を実行する計算機インスタンスを示す。本実施形態では、サーバ40上で直接仮想化プログラム60図2A及び図2B参照が実行される物理ホスト30と、論理区画LPAR51上で仮想化プログラム60図2A及び図2B参照が実行される論理ホスト31とが含まれる。論理区画LPAR51は、サーバ40が備える物理リソースを論理的に分割して生成された論理的な区画を示す。なお、物理リソースを論理的に分割する方法は、どのようなものでもよい。例えば、複数のコアを備えるCPUを論理的に分割する方法は、それぞれのコアをLPAR51に割り当てる方法が考えられる。また、メモリを論理的に分割する方法は、所定のアドレス領域を各LPAR51に割り当てる方法が考えられる。なお、サーバ40のハードウェア構成及びソフトウェア構成については、図2A及び図2Bを用いて後述する。また、物理ホスト30及び論理ホスト31の構成については図3A及び図3Bを用いて後述する。ネットワーク機器41は、各サーバ40とストレージ装置45とを接続する。ネットワーク機器41には、FCFibreChannelスイッチ、EthernetネットワークスイッチEthernetは登録商標、以下同じ、及びFCoEFibreChanneloverEthernetネットワークスイッチなどが含まれる。ストレージ装置45は、サーバ40が実行するプログラム、及びVM50の実行に必要な情報等を格納する。ストレージ装置45には、ディスクアレイ装置及びNASNetworkAttachedStorageなどが含まれる。なお、複数のサーバ40がストレージ装置45を共有することもできる。図2A及び図2Bは、本発明の第1の実施形態におけるサーバ40のハードウェア構成及びソフトウェア構成を説明するブロック図である。図2Aは、物理ホスト30を構成するサーバ40のハードウェア構成を示す。図2Bは、論理ホスト31を構成するサーバ40のハードウェア構成を示す。図2Aに示すサーバ40は、CPU41、メモリ42及びI/Oデバイス43を備える。CPU41は、メモリ42上に展開されるプログラムを実行する。CPU41が所定のプログラムを実行することによってサーバ40が備える機能を実現することができる。メモリ42は、CPU41によって実行されるプログラム及び当該プログラムを実行するために必要な情報を格納する。具体的には、メモリ42は、仮想化プログラム60を格納する。仮想化プログラム60は、VM50を生成し、VM50を制御する。以下、仮想化プログラム60を主語に処理を説明するときには、CPU41によって仮想化プログラム60が実行されていることを示す。なお、仮想化プログラム60によって実現される機能を、サーバ40が搭載するハードウェア、ファームウェア、又はこれらの組み合わせによって、例えば、仮想化部として実装してもよい。I/Oデバイス43は、ストレージ装置45などの外部装置と接続するためのデバイスであり、例えば、NIC、HBAHostBusAdaptor及びCNAConvergedNetworkAdapterなどが考えられる。図2Bに示すサーバ40は、図2Aに示すサーバ40と同一のハードウェア構成であるため説明を省略する。図2Bに示すサーバ40は、メモリ42に論理分割プログラム70を格納する点が異なる。論理分割プログラム70は、サーバ40上に1つ以上のLPAR51を生成し、当該LPAR51を管理する。以下、論理分割プログラム70を主語に処理を説明するときには、CPU41によって論理分割プログラム70が実行されていることを示す。なお、論理分割プログラム70によって実現される機能を、サーバ40が搭載するハードウェア、ファームウェア、又はこれらの組み合わせによって、例えば、論理分割部として実装してもよい。図3A及び図3Bは、本発明の第1の実施形態におけるサーバ40上で稼働するVM50のスタックの一例を示す説明図である。図3Aは、物理ホスト30を構成するサーバ40のスタックを示す。サーバ40上では、CPU41によって仮想化プログラム60が実行される。当該仮想化プログラム60は、1つ以上のVM50を生成し、生成されたVM50を稼働させる。VM50上ではオペレーティングシステム及びアプリケーションが実行される。本実施形態では、仮想化プログラム60を実行するサーバ40が物理ホスト30に対応する。図3Bは、論理ホスト31を構成するサーバ40のスタックを示す。サーバ40上では、CPU41によって論理分割プログラム70が実行される。当該論理分割プログラム70は、1つ以上のLPAR51を生成し、生成されたLPAR51を管理する。さらに、LPAR51に割り当てられたCPU41が仮想化プログラム60を実行する。当該仮想化プログラム60は、当該LPAR51上に1つ以上のVM50を生成し、生成されたVM50を稼働させる。VM50上ではオペレーティングシステム及びアプリケーションが実行される。本実施形態では、仮想化プログラム60を実行するLPAR51が論理ホスト31に対応する。図4は、本発明の第1の実施形態におけるリソース管理プログラム20の構成例を示す説明図である。リソース管理プログラム20は、統合リソース管理モジュール21、クラスタ管理モジュール22及びサーバ管理モジュール23を含む。統合リソース管理モジュール21は、リソースプール90を管理する。統合リソース管理モジュール21は、構成テーブル25を含む。構成テーブル25は、リソースプール90の構成情報を格納する。構成テーブル25の詳細については、図8を用いて後述する。クラスタ管理モジュール22は、クラスタ図5参照を管理する。具体的には、クラスタ管理モジュール22は、VM50の構成及び状態、並びに、クラスタ図5参照の構成を管理する。クラスタ管理モジュール22は、クラスタテーブル27を含む。クラスタテーブル27は、仮想化プログラム60から取得されたVM50の構成情報、及び、クラスタ図5参照の構成情報を格納する。クラスタテーブル27の詳細については、図7を用いて後述する。サーバ管理モジュール23は、サーバ40を管理する。具体的には、サーバ管理モジュール23は、サーバ40の構成及び状態、並びに、LPAR51の構成及び状態を管理する。サーバ管理モジュール23は、サーバテーブル28を含む。サーバテーブル28は、サーバ40の構成情報、及び、論理分割プログラム70から取得されたLPAR51の構成情報を格納する。サーバテーブル28の詳細については、図6を用いて後述する。なお、統合リソース管理モジュール21、クラスタ管理モジュール22及びサーバ管理モジュール23を、サーバ40が搭載するハードウェア、ファームウェア、又はこれらの組み合わせによって、実装してもよい。また、統合リソース管理モジュール21、クラスタ管理モジュール22及びサーバ管理モジュール23を異なる計算機が備えていてもよい。図5は、本発明の第1の実施形態におけるリソースプール90の構成例を示す説明図である。図5に示すサーバ2及びサーバ4は、物理ホスト30に対応するサーバ40である。また、サーバ1及びサーバ3は、論理ホスト31を構成するLPAR51が生成されるサーバ40である。各LPAR51が論理ホスト31に対応する。物理ホスト30は、サーバ40が備えるすべての物理リソースが割り当てられた計算機として稼動する。LPAR51には、サーバ40が備える物理リソースを論理的に分割した物理リソースが割り当てられる。また、論理ホスト31は、LPAR51が備える物理リソースが割り当てられた計算機として稼動する。VM50は、物理ホスト30又は論理ホスト31が備える物理リソースが割り当てられた仮想的な計算機である。VM50上では、オペレーティングシステム及びアプリケーションが実行される。リソースプール90は、クラスタ53から構成される。本実施形態では、クラスタ53が一つの物理リソースとして扱われ、当該物理リソースが各VM50に割り当てられる。クラスタ53は、1つ以上の物理ホスト30と1つ以上の論理ホスト31とから構成されるリソースグループ、複数の論理ホスト31から構成されるリソースグループ、及び、複数の物理ホスト30から構成されるリソースグループを含む。以下、クラスタ53を構成する物理ホスト30及び論理ホスト31を、クラスタに属する物理ホスト30及び論理ホスト31とも記載する。なお、物理ホスト30及び論理ホスト31は必ずしもクラスタ53に属する必要はない。また、どのクラスタ53にも属さないホスト物理ホスト30及び論理ホスト31も、一つのクラスタ53として管理してもよい。図5に示す例では、物理ホスト2はサーバ2に対応し、物理ホスト5はサーバ4に対応する。論理ホスト1はサーバ1に生成されたLPAR1に対応し、論理ホスト3はサーバ1に生成されたLPAR2に対応する。また、論理ホスト4はサーバ3に生成されたLPAR4に対応する。本実施形態では、少なくとも1つ以上の論理ホスト31を含むクラスタ53からリソースプール90が構成される点に特徴がある。これによって、論理ホスト31を構成するLPAR51への物理リソースの割り当てを変更することによって、クラスタ53の物理リソース量を変更することができる。図6は、本発明の第1の実施形態におけるサーバテーブル28の一例を示す説明図である。サーバテーブル28は、サーバ管理モジュール23によって作成される。サーバテーブル28は、サーバ281、スペック情報282、LPAR283及び構成284を含む。サーバ281は、計算機システム内においてサーバ40を一意に識別するための識別子を格納する。サーバ40の識別子としては、例えば、サーバ40のUUID、MACアドレス、ブレードサーバ又はラックの物理位置を示す情報スロット位置番号、及び、管理者によって設定された名称などが考えられる。スペック情報282は、サーバ40が備える物理リソースのリソース量を表すスペック情報を格納する。本実施形態では、CPU、メモリ及びI/Oデバイスのリソース量がスペック情報として格納される。なお、スペック情報は、他の物理リソースのリソース量を含んでいてもよい。LPAR283は、計算機システム内においてLPAR51を一意に識別するための識別子を格納する。なお、LPAR51が生成されていない場合、LPAR283にはLPAR51が生成されていないことを示す情報が格納される。例えば、物理ホスト30の場合、LPAR283には前述した情報が格納される。構成284は、LPAR51に論理的に割り当てられた物理リソースのリソース量を表すスペック情報を格納する。なお、LPAR51が生成されていない場合、構成284には、スペック情報は格納されない。図7は、本発明の第1の実施形態におけるクラスタテーブル27の一例を示す説明図である。クラスタテーブル27は、クラスタ管理モジュール22によって作成される。クラスタテーブル27は、クラスタ271、クラスタリソース272、ホスト273及びVM274を含む。クラスタ271は、リソースプール90内におけるクラスタ53を一意に識別するための識別子を格納する。クラスタリソース272は、クラスタ53における物理リソースのリソース量を格納する。具体的には、クラスタ53を構成する全ホストが備える物理リソースのリソース量の合計値が格納される。ホスト273は、クラスタ53に属するホストの識別子を格納する。ホストの識別子としては、例えば、ホスト名及びIPアドレスなどが考えられる。VM274は、ホスト上で稼働するVM50を識別するための識別子を格納する。なお、クラスタテーブル27は、クラスタ53に属さないホストのエントリも含む。この場合、当該エントリのクラスタ271及びクラスタリソース272は、クラスタ53に属していないことを表す情報が格納される。図7に示す例では、n/aが格納される。図8は、本発明の第1の実施形態における構成テーブル25の一例を示す説明図である。構成テーブル25は、統合リソース管理モジュール21によって作成される。構成テーブル25は、クラスタ251、ホスト252、サーバ253及びLPAR254を格納する。クラスタ251は、リソースプール90内におけるクラスタ53を一意に識別するための識別子を格納する。なお、クラスタ251は、クラスタ271と同一のものである。ホスト252は、クラスタ53に属するホストの識別子を格納する。ホスト252は、ホスト273と同一のものである。統合リソース管理モジュール21は、クラスタ管理モジュール22のクラスタテーブル27からクラスタ271及びホスト273を取得し、取得された各情報をクラスタ251及びホスト24に格納する。サーバ253は、計算機システム内においてサーバ40を一意に識別するための識別子を格納する。なお、サーバ253は、サーバ281と同一のものである。LPAR254は、計算機システム内においてLPAR51を一意に識別するための識別子を格納する。なお、LPAR254は、LPAR283と同一のものである。統合リソース管理モジュール21は、サーバ管理モジュール23のサーバテーブル28からサーバ281及びLPAR283を取得し、取得された各情報をサーバ253及びLPAR254に格納する。なお、統合リソース管理モジュール21は、サーバ40及びLPAR51への仮想化プログラム60の配布及び設定が可能であり、これによって物理ホスト30及び論理ホスト31を構築できる。統合リソース管理モジュール21は、仮想化プログラム60を配布したサーバ40の識別子と、各ホストに設定したホスト名又はIPアドレスなどのホストの識別子とを対応づけて管理する。これによって、構成テーブル25におけるホストとサーバ40との関係を把握することができる。なお、本実施形態では、統合リソース管理モジュール21は、クラスタ53に属しないホストを一つのクラスタ53として管理する。この場合、クラスタ53に属しないホストに対応するエントリのクラスタ251には、ホストの識別子が格納される。図9は、本発明の第1の実施形態のリソース管理プログラム20が実行するリソース管理処理を説明するフローチャートである。なお、以下の説明において、リソースプール90には、1つ以上の物理ホスト30及び1つ以上の論理ホスト31から構成されるクラスタ53が1つ以上構築済みであるものとする。さらに、サーバ管理モジュール23、クラスタ管理モジュール22及び統合リソース管理モジュール21は、サーバテーブル28、クラスタテーブル27及び構成テーブル25を保持しているものとする。まず、リソース管理プログラム20は、物理リソースの監視処理を実行するステップS201。リソース管理プログラム20は、周期的に監視処理を実行してもよいし、管理者からの指示にしたがって監視処理を実行してもよい。具体的には、リソース管理プログラム20は、物理リソースの監視処理を実行して、各クラスタ53における物理リソースの利用率を含む情報を取得する。なお、物理リソースの監視処理の詳細については、図10を用いて後述する。リソース管理プログラム20は、各クラスタ53から取得された情報に基づいて、リソース決定処理を実行するステップS202。リソース管理プログラム20は、リソース決定処理を実行して、物理リソースの割り当て量を変更するクラスタ53を決定する。なお、リソース決定処理の詳細については、図12を用いて後述する。リソース管理プログラム20は、決定されたクラスタ53について、物理リソースの割り当て量を変更できるか否かを判定するステップS203。物理リソースの割り当て量が変更できない場合には、リソース管理プログラム20は、ステップS201に戻り、同様の処理ステップS201~ステップS204を実行する。このとき、リソース管理プログラム20は、物理リソースの割り当て量が変更できない旨を示すメッセージを管理者及び他のプログラムに通知する。物理リソースの割り当て量が変更できる場合には、リソース管理プログラム20は、リソース量の変更処理を実行するステップS204。その後、リソース管理プログラム20は、ステップS201に戻り、同様の処理ステップS201~ステップS204を実行する。なお、リソース量の変更処理の詳細については、図13を用いて後述する。以下では、物理リソースの割り当て量をリソース量とも記載する。図10は、本発明の第1の実施形態における物理リソースの監視処理を説明するシーケンス図である。クラスタ管理モジュール22及びサーバ管理モジュール23は、それぞれ、リソース利用率を監視する。具体的には、クラスタ管理モジュール22は、VM50によって使用される各ホストのリソース利用率を監視するステップS2011。クラスタ管理モジュール22は、監視結果を所定の形式のデータとして保持する。ここで、ホストのリソース利用率とは、ホストに割り当てられたCPU、メモリ及びI/Oデバイスの利用率を示す値であり、0~100までの値で表される。I/Oデバイスの利用率としては、最大性能に対する利用バンド幅などが考えられる。なお、最大性能とは、ホストの割り当てられたI/Oデバイスにおける性能値の合計値であり、例えば、ホストに10GbのCNAが4枚割り当てられている場合、最大性能は40Gbとなる。一方、サーバ管理モジュール23は、各LPAR51のリソース利用率を監視するステップS2012。サーバ管理モジュール23は、監視結果を所定の形式のデータとして保持する。ここで、LPAR51のリソース利用率とは、LPAR51に割り当てられたCPU、メモリ及びI/Oデバイスの利用率を示す値であり、0~100までの値で表される。なお、クラスタ管理モジュール22及びサーバ管理モジュール23は、それぞれ、周期的に前述した監視処理を実行する。なお、前述したステップS2011の監視処理及びステップS2012の監視処理の実行タイミングは、本シーケンスの示すタイミングに限定されない。統合リソース管理モジュール21は、構成テーブル25を参照して、リソース利用率の問い合わせ先を決定するステップS2010。LPAR254に識別子が格納されていない場合、当該ホストは物理ホスト30であるため、統合リソース管理モジュール21は、クラスタ管理モジュール22を問い合わせ先として決定する。LPAR254に識別子が格納されている場合、当該ホストは論理ホスト31であるため、統合リソース管理モジュール21は、サーバ管理モジュール23を問い合わせ先として決定する。問い合わせ先がクラスタ管理モジュール22である場合、統合リソース管理モジュール21は、物理ホスト30のリソース利用率の取得要求をクラスタ管理モジュール22に出力するステップS2013。なお、当該取得要求には、クラスタ53の識別子、及び、物理ホスト30の識別子が含まれる。クラスタ管理モジュール22は、取得要求を受け付けると、要求された物理ホスト30のリソース利用率を統合リソース管理モジュール21に通知するステップS2014。具体的には、クラスタ管理モジュール22は、クラスタ53及び物理ホスト30の識別子に基づいて、対象となる物理ホスト30を特定する。さらに、クラスタ管理モジュール22は、監視結果を参照し、特定された物理ホスト30のリソース利用率を読み出し、読み出された物理ホスト30のリソース利用率を統合リソース管理モジュール21に通知する。なお、ステップS2013~ステップS2016は、各クラスタ53に対して実行される。問い合わせ先がサーバ管理モジュール23である場合、統合リソース管理モジュール21は、LPAR51のリソース利用率の取得要求をサーバ管理モジュール23に出力するステップS2015。なお、当該取得要求には、クラスタ53の識別子、及び、LPAR51の識別子が含まれる。サーバ管理モジュール23は、取得要求を受け付けると、要求されたLPAR51のリソース利用率を統合リソース管理モジュール21に通知するステップS2016。具体的には、サーバ管理モジュール23は、取得要求に含まれるクラスタ53の識別子、及び、LPAR51の識別子に基づいて、通知対象となるLPAR51を特定する。さらに、サーバ管理モジュール23は、監視結果を参照して特定されたLPAR51のリソース利用率を読み出し、読み出されたLPAR51のリソース利用率を統合リソース管理モジュール21に通知する。統合リソース管理モジュール21は、取得されたリソース利用率に基づいて、各クラスタ53の実リソース利用率を算出するステップS2017。ここで、クラスタ53の実リソース利用率とは、クラスタ53における物理リソースの利用率を表す。物理リソースには、少なくともCPU、メモリ及びI/Oデバイスが含まれる。したがって、CPU、メモリ及びI/Oデバイスそれぞれの実リソース利用率が算出される。なお、各クラスタ53の実リソース利用率の算出方法については、図11を用いて後述する。統合リソース管理モジュール21は、算出された各クラスタ53の実リソース利用率に基づいて、リソース量を変更するクラスタ53が存在するか否かを判定するステップS2018。以下、リソース量を変更するクラスタ53を対象クラスタ53とも記載する。当該判定処理は、例えば、以下のような方法が考えられる。第1の方法としては、CPUの実リソース利用率が予め設定された閾値例えば、70以上であるクラスタ53が存在するか否かを判定する方法が考えられる。なお、第1の方法では、CPUの実リソース利用率に限定されず、メモリ及びI/Oデバイスの実リソース利用率であってもよい。すなわち、少なくともいずれかの物理リソースの実リソース利用率が閾値以上であるクラスタ53が対象クラスタ53として判定される。なお、CPU、メモリ及びI/Oデバイスのうち、2つ以上の物理リソースの実リソース利用率が閾値以上であるクラスタ53を対象クラスタ53としてもよい。また、CPU、メモリ及びI/Oデバイスの実リソース利用率の平均値を用いた判定方法であってもよい。第1の方法は、クラスタ53の負荷を分散させることを目的とした判定方法である。第2の方法としては、CPUの実リソース利用率が最大のクラスタ53とCPUの実リソース利用率が最小のクラスタ53との実リソース利用率の差が、所定の閾値以上であるか否かを判定する方法が考えられる。CPUの実リソース利用率の差が所定の閾値以上である場合には、CPUの実リソース利用率が最大のクラスタ53が対象クラスタ53となる。なお、第2の方法では、CPUの実リソース利用率に限定されず、メモリ及びI/Oデバイスの実リソース率であってもよい。すなわち、少なくともいずれかの物理リソースの実リソース利用率の差が所定の閾値以上である場合に、物理リソースの実リソース利用率が最大のクラスタ53が対象クラスタ53として判定される。また、CPU、メモリ及びI/Oデバイスの実リソース利用率の平均値を用いた判定方法であってもよい。第2の方法は、計算機システム内のクラスタ53間の負荷の平準化を目的とした判定方法である。なお、上記判定方法は一例であって、他の方法を用いて対象クラスタを判定してもよい。なお、第1の方法及び第2の方法において用いられる各閾値は、統合リソース管理モジュール21が保持する。閾値の入力方法としては、統合リソース管理モジュール21によって提供されるUIを用いて管理者が入力してもよいし、統合リソース管理モジュール21が予め保持していてもよい。ステップS2018において、対象クラスタ53が存在しないと判定された場合、統合リソース管理モジュール21は、ステップS2010に戻り、同様の処理を実行する。ステップS2018において、対象クラスタ53が存在すると判定された場合、統合リソース管理モジュール21は、対象クラスタ53を設定し、処理を終了するステップS2019。図11は、本発明の第1の実施形態におけるクラスタ53の実リソース利用率の算出方法を示す説明図である。ステップS2013において取得された物理ホスト30のリソース利用率をUiiは1~nの間の整数として、ステップS2015において取得されたLPAR51のリソース利用率をVjjは1~mの間の整数とすると、クラスタ53の実リソース利用率Rkは、図11に示す式1を用いて算出される。ここで、nはクラスタ53を構成する物理ホスト30の数を示し、mはクラスタ53を構成する論理ホスト31の数を示す。また、kはクラスタ53における物理リソースの種類を表す。本実施形態では、kが1の場合にはCPUの実リソース利用率を表し、kが2の場合にはメモリの実リソース利用率を表し、また、kが3の場合にはI/Oデバイスの実リソース利用率を表す。ここでは、クラスタ53の識別子がC1のクラスタ53のCPUの実リソース利用率を例に説明する。ステップS2010において、統合リソース管理モジュール21は、ホスト252がH1であるホストは論理ホスト31であるため、サーバ管理モジュール23に問い合わせるステップS2015。また、ステップS2010において、統合リソース管理モジュール21は、ホスト252がH2であるホストは物理ホスト30であるため、クラスタ管理モジュール22に問い合わせるステップS2013。物理ホスト30のCPUのリソース利用率をU1とし、LPAR51のCPUのリソース利用率をV1としたとき、n=1、m=1であるため、クラスタ53のCPUの実リソース利用率は、下式2に示すように算出される。R1=U1V1/2...2論理ホスト31のリソース利用率は、LPAR51の監視手段が論理分割プログラム70の影響を受けて、正確なリソース利用率を測定できない場合がある。しかし、前述した計算式を用いることによって、クラスタ53における実際の物理リソースの利用率を取得することができる。図12は、本発明の第1の実施形態におけるリソース決定処理を説明するフローチャートである。統合リソース管理モジュール21は、対象クラスタ53と同一のサーバ40が備える物理リソースを共有する共有クラスタ53を特定するステップS2021。具体的には、以下のような処理が実行される。統合リソース管理モジュール21は、構成テーブル25を参照して、対象クラスタ53を構成する論理ホスト31に対応するLPAR51を特定する。具体的には、LPAR254に識別子が格納されるエントリが検索される。次に、統合リソース管理モジュール21は、特定されたLPAR51の識別子を含む検索要求をサーバ管理モジュール23に出力する。当該検索要求を受け付けたサーバ管理モジュール23は、サーバテーブル28を参照して、対象クラスタ53を構成する論理ホスト31が生成されるサーバ40を特定する。さらに、サーバ管理モジュール23は、特定されたサーバ40上に生成された他のLPAR51を検索する。サーバ管理モジュール23は、検索された他のLPAR51の識別情報LPAR283を統合リソース管理モジュール21に通知する。統合リソース管理モジュール21は、通知されたLPAR51の識別子に基づいて構成テーブル25を参照して、通知されたLPAR51に対応する論理ホスト31から構成される共有クラスタ53を特定する。なお、共有クラスタ53は複数存在してもよい。図8に示す例では、論理ホストH3がクラスタC1の論理ホストH1と同一のサーバS1が備える物理リソースを共有する。したがって、論理ホストH3から構成されるクラスタC2が、クラスタC1の共有クラスタとなる。共有クラスタ53が存在しない場合、リソース量を変更できないと判定される。そのためステップS203の判定処理ではNoとなる。なお、共有クラスタ53が存在しない場合における、クラスタ53のリソース量の変更方法については第3の実施形態において説明する。統合リソース管理モジュール21は、リソース量を変更する論理ホスト31を決定するステップS2022。具体的には、統合リソース管理モジュール21は、対象クラスタ53を構成する論理ホスト31と、共有クラスタ53を構成する論理ホスト31との組み合わせを決定する。図8に示す例では、対象クラスタC1を構成する論理ホストH1と、共有クラスタC2を構成する論理ホストH3との組み合わせが決定される。複数の組み合わせがある場合には、以下のようにして決定される。まず、統合リソース管理モジュール21は、共有クラスタ53の実リソース利用率の予測値第1の予測値とも記載するを算出する。ここで、共有クラスタ53の実リソース利用率の予測値は、共有クラスタ53を構成する論理ホスト31の物理リソースをリソース変更量分だけ削減した場合におけるリソース利用率を示す。また、統合リソース管理モジュール21は、対象クラスタ53の実リソース利用率の予測値第2の予測値とも記載するを算出する。ここで、対象クラスタ53の実リソース利用率の予測値は、対象クラスタ53を構成する論理ホスト31の物理リソースをリソース変更量分だけ追加した場合におけるリソース利用率を示す。統合リソース管理モジュール21は、第1の予測値と第2の予測値との差が最小となる組み合わせを決定する。ここで、クラスタ53の実リソース利用率の予測値Eは、下式3を用いて算出することができる。Ek=Rk×A/DA...3ここで、Rはクラスタ53の実リソース利用率を表し、Aはクラスタリソース272に格納される値を表し、また、Dはリソース変更量を表す。なお、共有クラスタ53の実リソース利用率を算出する場合、リソース変更量Dの前にマイナスをつけた式となる。ただし、以下の2つの条件のもと、クラスタ53の実リソース利用率の予測値Eは算出される。条件1Dは、論理ホスト31を構成するサーバ40が備える物理リソース量を超えない。条件2Eは、図10のステップS2018における閾値より小さい。前述した条件を満たす論理ホスト31の組み合わせが存在しない場合、リソース量を変更できないと判定される。そのためステップS203の判定処理ではNoとなる。なお、本実施形態では、図10のステップS2018の判定処理において、実リソース利用率が閾値以上となった物理リソースについて予測値Eが算出される。ただし、複数又は全ての物理リソースについて予測値Eを算出し、条件1及び条件2満たす論理ホスト31の組み合わせ及びリソース変更量Dを決定してもよい。なお、前述した判定条件は一例であって、管理者によって適宜変更できる。例えば、統合リソース管理モジュール21が、対象クラスタ53及び共有クラスタ53の実リソース利用率、各クラスタ53の実リソース利用率の差、論理ホスト31の組み合わせ、及び、リソース変更量Dの一覧をUIを用いて管理者に提示して、かつ、論理ホストの組み合わせ及びリソース変更量Dを決定するインタフェースを提供してもよい。また、実リソース利用率の予測値の差が最小ではなく、他の条件に基づいて論理ホスト31の組み合わせ及びリソース変更量Dを決定してもよい。なお、対象クラスタ53及び共有クラスタ53のそれぞれに論理ホスト31が一つしか含まれない場合は、ステップS2022の処理では、論理ホスト31の組み合わせが自動的に決定される。図13は、本発明の第1の実施形態におけるリソース変更処理を説明するシーケンス図である。リソース変更処理では、図12のステップS2022において決定された対象クラスタ53の論理ホスト31と共有クラスタ53の論理ホスト31との間でリソース量が変更される。以下、対象クラスタ53の論理ホスト31を追加対象の論理ホスト31と記載し、共有クラスタ53の論理ホスト31を削減対象の論理ホスト31と記載する。統合リソース管理モジュール21は、クラスタ管理モジュール22に対して削減対象の論理ホスト31上で稼動するVM50の移動を要求するステップS2041。クラスタ管理モジュール22は、VM50の移動要求を受け付けると、VM50の移動処理を実行するステップS2042。具体的には、クラスタ管理モジュール22は、削減対象の論理ホスト31上で稼動するVM50を、共有クラスタ内の他のホスト物理ホスト30及び論理ホスト31に移動させる。なお、VM50の移動方法は、VM50上で稼働するOS及びソフトウェアを停止することなく他のホストに移動する方法、VM50を一旦停止した後当該VM50を他のホストに移動する方法が考えられる。削減対象の論理ホスト31を実現するLPAR51のリソース量の割り当てを変更する前にVM50を移動させることによって、影響を受けるVM50を解消できる。なお、影響を受けるVM50が存在しない場合には、クラスタ管理モジュール22は、VM50の移動処理を実行しなくてもよい。本実施形態では、削減対象の論理ホスト31上で稼動する全VM50のリソース利用率の合計値が、当該論理ホスト31に対応するLPAR51に割り当てられる物理リソースからリソース変更量Dを減算した値より小さい場合に、影響を受けるVM50が存在しないものとする。統合リソース管理モジュール21は、サーバ管理モジュール23に対して、削減対象の論理ホスト31に対応するLPAR51のリソース量の変更を要求するステップS2043。サーバ管理モジュール23は、リソース量の変更要求を受け付けると、削減対象の論理ホスト31に対応するLPAR51のリソース量を変更するステップS2044。具体的には、当該LPAR51のソース量からリソース変更量Dを減算したリソース量に変更される。このとき、サーバ管理モジュール23は、サーバテーブル28を参照し、当該LPAR51に対応するエントリの構成284を更新する。統合リソース管理モジュール21は、クラスタ管理モジュール22に対して共有クラスタ53のリソース量の変更を要求するステップS2045。当該変更要求には、リソース変更量Dの値が含まれる。クラスタ管理モジュール22は、リソース量の変更要求を受け付けると、共有クラスタ53のリソース量を変更するステップS2046。具体的には、共有クラスタ53のリソース量をリソース変更量D分だけ減算した値に変更される。このとき、クラスタ管理モジュール22は、クラスタテーブル27を参照し、共有クラスタ53に対応するエントリのクラスタリソース272を更新する。すなわち、LPAR51におけるリソース量の変更が反映される。クラスタ管理モジュール22がステップS2044の処理の実行後、自動的にステップS2046の処理を実行する場合、ステップS2045の処理は省略できる。すなわち、サーバ管理モジュール23が、クラスタ管理モジュール22にLPAR51のリソース量の変更を通知するAPIApplicationProgramInterfaceを備える場合には、ステップS2045の処理は省略できる。ステップS2041~ステップS2046は、共有クラスタ53のリソース量が削減される処理である。次に、統合リソース管理モジュール21は、サーバ管理モジュール23に対して、追加対象の論理ホスト31に対応するLPAR51のリソース量の変更を要求するステップS2047。当該変更要求には、リソース変更量Dの値が含まれる。サーバ管理モジュール23は、リソース量の変更要求を受け付けると、追加対象の論理ホスト31に対応するLPAR51のリソース量を変更するステップS2048。具体的には、当該LPAR51のリソース量がリソース変更量D分だけ加算される。このとき、サーバ管理モジュール23は、サーバテーブル28を参照し、当該LPAR51に対応するエントリの構成284を更新する。統合リソース管理モジュール21は、クラスタ管理モジュール22に対して対象クラスタのリソース量の変更を要求するステップS2049。当該変更要求には、リソース変更量Dの値が含まれる。クラスタ管理モジュール22は、リソース量の変更要求を受け付けると、対象クラスタ53のリソース量を変更するステップS2050。具体的には、対象クラスタ53のリソース量がリソース変更量D分だけ加算した値に変更される。このとき、クラスタ管理モジュール22は、クラスタテーブル27を参照し、対象クラスタ53に対応するエントリのクラスタリソース272を更新する。すなわち、LPAR51におけるリソース量の変更が反映される。クラスタ管理モジュール22がステップS2046の処理の実行後、自動的にステップS2048の処理を実行する場合、ステップS2047の処理は省略できる。すなわち、サーバ管理モジュール23が、クラスタ管理モジュール22にLPAR51のリソース量の変更を通知するAPIを備える場合には、ステップS2047の処理は省略できる。図14は、本発明の第1の実施形態におけるリソース変更処理の概要を示す説明図である。図14では、クラスタ1が対象クラスタ53であり、クラスタ2が共有クラスタ53である場合のリソース変更処理の概要を示す。このとき、サーバ1が対象クラスタ1及び共有クラスタ2によって共有される。したがって、ステップS2022において、論理ホスト1及び論理ホスト2がリソース量を変更する論理ホスト31の組み合わせとして決定される。また、ステップS2044において、LPAR2のリソース量がリソース変更量D分だけ削減される。ステップS2046において、LPAR2のリソース量の削減がクラスタ2に反映される。ステップS2048において、LPAR1のリソース量がリソース変更量D分だけ追加される。ステップS2050において、LPAR1におけるリソース量の追加がクラスタ1に反映される。[第1の実施形態の変形例1]リソース決定処理では、クラスタ53に属しない論理ホスト31を、リソース量を変更する共有クラスタ53として選択してもよい。この場合、リソース決定処理は以下のようになる。ステップS2021では、対象クラスタ53に属する論理ホスト31に対応するLPAR51と同一のサーバ40上に生成されたLPAR51に対応し、かつ、クラスタ53に属しない論理ホスト31が共有クラスタ53として選択される。ステップS2022では、クラスタ53に属しない論理ホスト31の実リソース利用率を算出し、算出された論理ホスト31の実リソース利用率に基づいて、削減対象の論理ホスト31を決定する。なお、クラスタ53の実リソース利用率を算出する場合に、Aには、当該論理ホスト31に対応するLPAR51のスペック情報、すなわち、構成284に格納される値が用いられる。なお、リソース変更処理は、第1の実施形態と同一である。[第1の実施形態の変形例2]対象クラスタ53のリソース量を追加する場合に、対象クラスタ53に属する論理ホスト31に対応するLPAR51に、当該LPAR51が生成されたサーバ40の空きリソースを追加してもよい。当該変形例では、リソース管理プログラム20が、各サーバ40の空きリソース量を管理する情報を保持する。図15は、本発明の第1の実施形態の変形例における空きリソーステーブル29の一例を示す説明図である。空きリソーステーブル29は、サーバ291及び空きリソース292を含む。サーバ291は、サーバ40の識別子を格納し、サーバ281と同一のものである。空きリソース292は、サーバ40における空きリソース量を格納する。なお、サーバ40の空きリソース量は、サーバテーブル28のスペック情報282から構成284を差分することによって算出することができる。図16は、本発明の第1の実施形態の変形例におけるリソース決定処理を説明するフローチャートである。統合リソース管理モジュール21は、対象クラスタ53を構成する論理ホスト31を特定するステップS2901。具体的には、統合リソース管理モジュール21は、構成テーブル25を参照し、対象クラスタ53に対応するエントリのLPAR254に識別子が格納されるホストを検索する。次に、統合リソース管理モジュール21は、特定された論理ホスト31に対応するLPAR51が生成されるサーバ40を特定するステップS2902。具体的には、統合リソース管理モジュール21は、特定された論理ホスト31に対応するLPAR51の識別子を含む検索要求をサーバ管理モジュール23に出力する。当該検索要求を受け付けたサーバ管理モジュール23は、サーバテーブル28を参照して、LPAR51が生成されるサーバ40を特定する。サーバ管理モジュール23は、特定されたサーバ40の識別子を統合リソース管理モジュール21に通知する。統合リソース管理モジュール21は、通知されたサーバ40の識別子に基づいて、空きリソーステーブル29を参照して、リソース量を変更する論理ホスト31を決定するステップS2903。例えば、以下のような方法が考えられる。まず、統合リソース管理モジュール21は、特定されたサーバ40に対応するエントリの空きリソース292を参照し、リソース変更量D以上の空きリソースを保持するサーバ40を検索する。さらに、統合リソース管理モジュール21は、検索されたサーバ40のうち、空きリソース量が最も多いサーバ40を特定する。これによって、特定されたサーバ40上に生成されたLPAR51に対応する論理ホスト31が、リソース量を変更する論理ホスト31に決定される。なお、他の基準に基づいてリソース量を変更する論理ホスト31を決定してもよい。リソース変更処理では、以下の点が異なる。変形例では共有クラスタ53は考慮する必要がないため、ステップS2041~ステップS2046の処理は実行されない。ステップS2048では、サーバ管理モジュール23は、リソース量を変更する論理ホスト31に対応するLPAR51に、リソース変更量D分のリソース量を追加する。このとき、サーバ管理モジュール23は、サーバテーブル28を参照し、当該LPAR51に対応するエントリの構成284を更新する。ステップS2049では、統合リソース管理モジュール21は、クラスタ管理モジュール22に対して対象クラスタ53のリソース量の変更を要求し、また、空きリソーステーブル29の対応するエントリを更新する。変形例1及び変形例2は、物理リソースを有効に活用するとともに、他のクラスタに影響を与えることなくクラスタのリソース量を変更できる。[第2の実施形態]第2の実施形態では、リソース変更処理が第1の実施形態と異なる。具体的には、統合リソース管理モジュール21は、追加対象の論理ホスト31及び削減対象の論理ホスト31を停止させ、リソース量が変更された後に各論理ホストを再起動する点が異なる。以下、第1の実施形態との差異を中心に説明する。第2の実施形態における計算機システムの構成は第1の実施形態と同一であるため説明を省略する。また、管理サーバ10、サーバ40のハードウェア構成及びソフトウェア構成は第1の実施形態と同一であるため説明を省略する。また、物理ホスト30及び論理ホスト31の構成も第1の実施形態と同一であるため説明を省略する。さらに、リソース監視処理及びリソース決定処理も第1の実施形態と同一であるため説明を省略する。図17は、本発明の第2の実施形態におけるリソース変更処理を説明するシーケンス図である。統合リソース管理モジュール21は、クラスタ管理モジュール22に対して追加対象の論理ホスト31上で稼動する全てのVM50の移動を要求するステップS2501。クラスタ管理モジュール22は、VM50の移動要求を受け付けると、追加対象の論理ホスト31上で稼動する全てのVM50の移動処理を実行するステップS2502。具体的には、クラスタ管理モジュール22は、追加対象の論理ホスト31上で稼動するVM50を、対象クラスタ53内の他のホスト物理ホスト30及び論理ホスト31に移動する。なお、VM50の移動方法は、VM50上で稼働するOS及びソフトウェアを停止することなく他のホストに移動する方法、VM50を一旦停止した後当該VM50を他のホストに移動する方法が考えられる。これは、追加対象の論理ホスト31を停止することによって影響を受けるVM50を解消するための処理である。なお、追加対象の論理ホスト31上でVM50が稼働していない場合、ステップS2052の処理は省略できる。統合リソース管理モジュール21は、クラスタ管理モジュール22に対して削減対象の論理ホスト31上で稼動する全てのVM50の移動を要求するステップS2503。クラスタ管理モジュール22は、VM50の移動要求を受け付けると、削減対象の論理ホスト31上で稼動する全てのVM50の移動処理を実行するステップS2504。当該処理は、ステップS2042と同一の処理である。これは、削減対象の論理ホスト31を停止することによって影響を受けるVM50を解消するための処理である。なお、削減対象の論理ホスト31上でVM50が稼働していない場合、ステップS2054の処理は省略できる。統合リソース管理モジュール21は、クラスタ管理モジュール22に対して、対象クラスタ53を構成する論理ホスト31、及び、共有クラスタ53を構成する論理ホスト31の停止を要求するステップS2055。クラスタ管理モジュール22は、停止要求を受け付けると、各クラスタ53を構成する論理ホスト31を停止するステップS2056。クラスタ管理モジュール22は、論理ホスト31の停止中に、論理ホスト31が属するクラスタ53のリソース量の変更を反映する。統合リソース管理モジュール21は、サーバ管理モジュール23に対して、削減対象の論理ホスト31に対応するLPAR51のリソース量の変更を要求するステップS2057。当該処理はステップS2043と同一である。サーバ管理モジュール23は、リソース量の変更要求を受け付けると、削減対象の論理ホスト31に対応するLPAR51のリソース量を変更するステップS2058。当該処理は、ステップS2044と同一である。このとき、サーバ管理モジュール23によって、サーバテーブル28の当該LPAR51に対応するエントリの構成284が更新される。統合リソース管理モジュール21は、サーバ管理モジュール23に対して、追加対象の論理ホスト31に対応するLPAR51のリソース量の変更を要求するステップS2059。当該処理は、ステップS2047と同一である。サーバ管理モジュール23は、リソース量の変更要求を受け付けると、追加対象の論理ホスト31に対応するLPAR51のリソース量の割り当てを変更するステップS2060。当該処理は、ステップS2048と同一である。統合リソース管理モジュール21は、サーバ管理モジュール23に対して、追加対象の論理ホスト31に対応するLPAR51、及び、削減対象の論理ホスト31に対応するLPAR51の起動を要求するステップS2061。サーバ管理モジュール23は、起動要求を受け付けると、各論理ホスト31に対応するLPAR51を起動するステップS2062。これによって、対象クラスタ53を構成する論理ホスト31と共有クラスタ53を構成する論理ホスト31が起動する。なお、論理ホスト31が起動した後、クラスタ管理モジュール22は、該当論理ホスト31が属するクラスタ53のリソース量の変更をクラスタテーブル27に反映する。[第3の実施形態]第3の実施形態では、LPAR51を他のサーバ40に移動することによって当該LPAR51に割り当てられるリソース量を変更する点が第1の実施形態と異なる。以下、第1の実施形態との差異を中心に説明する。第3の実施形態における計算機システムの構成は第1の実施形態と同一であるため説明を省略する。また、管理サーバ10、サーバ40のハードウェア構成及びソフトウェア構成は第1の実施形態と同一であるため説明を省略する。また、物理ホスト30及び論理ホスト31の構成も第1の実施形態と同一であるため説明を省略する。さらに、リソース監視処理も第1の実施形態と同一であるため説明を省略する。図18は、本発明の第3の実施形態におけるリソース決定処理を説明するフローチャートである。統合リソース管理モジュール21は、対象クラスタ53と同一のサーバ40の物理リソースを共有する共有クラスタ53を特定するステップS2021。統合リソース管理モジュール21は、移動対象の論理ホスト31が対象クラスタ53を構成する論理ホスト31であるか否かを判定するステップS2071。ここで、移動対象の論理ホストとは、リソース変更処理の実行時に、論理ホスト31に対応するLPAR51を他のサーバ40へと移動する論理ホスト31を示す。具体的には以下のような判定処理が実行される。まず、統合リソース管理モジュール21は、共有クラスタ53が存在するか否かを判定する。共有クラスタ53が存在しないと判定された場合、統合リソース管理モジュール21は、移動対象となる論理ホスト31が共有クラスタ53を構成する論理ホスト31ではないと判定する。共有クラスタ53が存在すると判定された場合、共有クラスタ53を構成する論理ホスト31が移動可能か否かを判定する。統合リソース管理モジュール21は、所定の基準値に基づいて、又は、共有クラスタ53の実リソース利用率と他のクラスタ53の実リソース利用率との比較結果に基づいて、判定処理を実行する。また、管理者がUI等を用いて、共有クラスタ53を構成する論理ホスト31が移動するか否かを選択してもよい。共有クラスタ53を構成する論理ホスト31が移動可能である場合には、移動対象となる論理ホスト31が共有クラスタ53を構成する論理ホスト31であると判定される。移動対象が共有クラスタ53を構成する論理ホスト31であると判定された場合、統合リソース管理モジュール21は、共有クラスタ53を構成する論理ホスト31の中から移動対象となる論理ホスト31を決定するステップS2072。複数の論理ホスト31から共有クラスタ53が構成される場合、リソース利用率が最も大きい論理ホスト31、又は、リソース量が最小のLPAR51に対応する論理ホスト31を移動対象として選択する方法が考えられる。本発明は前述した判定方法に限定されず、他の基準に基づいて移動対象となる論理ホスト31を決定してもよい。統合リソース管理モジュール21は、移動対象として決定された論理ホスト31の移動先のサーバ40を決定するステップS2073。移動先のサーバ40を決定する方法としては、移動対象である論理ホスト31に対応するLPAR51のリソース量構成284以上の空きリソースが存在するサーバ40を選択する方法が考えられる。なお、サーバ40の空きリソース量は、サーバテーブル28のスペック情報282から、サーバ40に生成された各LPAR51の構成284の合計値を減算することによって算出することができる。例えば、図6において、サーバ281がS1であるサーバ40の空きリソース量は、CPUについては2GHz×2、メモリについては128GB、またI/Oデバイスについては10GbCNA×2と算出される。なお、サーバ管理モジュール23が、予め算出した各サーバ40の空きリソース量を保持していてもよい。ステップS2073の処理において、論理分割プログラム70が実行されていないサーバ40は、すなわち、論理ホスト31が稼動していないサーバ40は、移動先のサーバ40の候補から除外してもよい。ただし、移動先のサーバ40の候補から除外しない場合には、統合リソース管理モジュール21は、論理分割プログラム70の実行を当該サーバ40に指示する。このとき、サーバ40は、論理分割プログラム70を実行してLPAR51を生成する。さらに、サーバ40は、当該サーバ40上で稼働していた物理ホスト30を生成されたLPAR51に対応する論理ホスト31に変換する。その後、統合リソース管理モジュール21は、ステップS2073の処理を実行する。なお、論理分割プログラム70を含まないサーバ40についても、稼動中のVM50を同一又は異なるサーバ40上のLPAR51に移動させることによって、移動先のサーバ40の候補としてもよい。ステップS2071において、移動対象が対象クラスタ53を構成する論理ホスト31であると判定された場合、統合リソース管理モジュール21は、対象クラスタ53を構成する論理ホスト31の中から移動対象となる論理ホスト31を決定するステップS2074。なお、移動対象となる論理ホスト31を決定する方法は、ステップS2072と同一の方法を用いることが考えられる。統合リソース管理モジュール21は、移動対象として決定された論理ホスト31の移動先のサーバ40を決定するステップS2075。移動先のサーバ40を決定する方法としては、移動対象となる論理ホスト31に対応するLPAR51に割り当てられたリソース量構成284にリソース変更量Dを加算した値以上の空きリソースが存在するサーバ40を選択する方法が考えられる。なお、論理分割プログラム70が実行されていないサーバ40は、移動先のサーバ40の候補から除外してもよい。ただし、移動先のサーバ40の候補から除外しない場合には、統合リソース管理モジュール21は、論理分割プログラム70の実行を当該サーバ40に指示する。このとき、サーバ40は、論理分割プログラム70を実行してLPAR51を生成する。さらに、サーバ40は、当該サーバ40上で稼動する物理ホスト30を、生成されたLPAR51に対応する論理ホスト31に変換する。その後、統合リソース管理モジュール21は、ステップS2075の処理を実行する。図19は、本発明の第3の本実施形態におけるリソース変更処理を説明するシーケンス図である。統合リソース管理モジュール21は、サーバ管理モジュール23に対して、移動対象として決定された論理ホスト31に対応するLPAR51の移動を要求するステップS2081。当該移動要求には、移動対象として決定された論理ホスト31に対応するLPAR51の識別子、及び、移動先のサーバ40の識別子が含まれる。サーバ管理モジュール23は、移動要求を受け付けると、移動対象の論理ホスト31に対応するLPAR51の移動処理を実行するステップS2082。ここで、LPAR51の移動方法としては、LPAR51上で実行される仮想化プログラム60及びVM50を停止せずに移動させる方法が考えられる。また、一旦LPAR51を停止させ、LPAR51移動先のサーバ40に移動させた後、LPARを再起動する方法も考えられる。なお、LPAR51を停止させる場合には、当該LPAR51に対応する論理ホスト31上で稼働するVM50を他のホストに移動させることが望ましい。統合リソース管理モジュール21は、サーバ管理モジュール23に対して、対象クラスタ53を構成する論理ホスト31に対応するLPAR51のリソース量の割り当て変更を要求するステップS2083。ここで、リソース量の変更対象となる論理ホスト31は、移動対象となる論理ホスト31によって異なる。移動対象となる論理ホスト31が共有クラスタ53を構成する論理ホスト31である場合、移動対象である論理ホスト31と同一のサーバ40上に存在する論理ホスト31に対応するLPAR51がリソース量の変更対象となる。一方、移動対象となる論理ホスト31が対象クラスタを構成する論理ホスト31である場合、移動対象である論理ホスト31に対応するLPAR51がリソース量の変更対象となる。サーバ管理モジュール23は、変更要求を受け付けると、リソース量の変更対象となるLPAR51のリソース量を変更するステップS2084。具体的には、変更対象であるLPAR51のリソース量がリソース変更量D分だけ追加される。統合リソース管理モジュール21は、クラスタ管理モジュール22に対して、対象クラスタ53のリソース量の変更を要求するステップS2085。当該変更要求には、リソース変更量Dの値が含まれる。クラスタ管理モジュール22は、変更要求を受け付けると、対象クラスタ53のリソース量を変更するステップS2086。具体的には、対象クラスタ53のリソース量がリソース変更量D分だけ追加された値に変更される。このとき、クラスタ管理モジュール22は、クラスタテーブル27を参照し、対象クラスタ53に対応するエントリのクラスタリソース272を更新する。すなわち、LPAR51に追加されたリソース量の変更が反映される。なお、クラスタ管理モジュール22がステップS2084の処理の実行後、自動的にステップS2086の処理を実行する場合、ステップS2086の処理は省略できる。すなわち、サーバ管理モジュール23が、クラスタ管理モジュール22にLPAR51のリソース量の変更を通知するAPIを備える場合には、ステップS2086の処理は省略できる。図20は、本発明の第3の実施形態におけるリソース変更処理の概要を示す説明図である。図20では、クラスタ2が対象クラスタ53、論理ホスト2が移動対象となる論理ホスト31、また、サーバ1が移動先のサーバ40である場合のリソース変更処理の概要を示す。ステップS2082では、論理ホスト2に対応するLPAR2がサーバ2からサーバ1に移動される。ステップS2084では、サーバ1に移動したLPAR2のリソース量がリソース変更量D分だけ追加される。ステップS2086では、LPAR2のリソース量の追加がクラスタ2のリソース量の増加として反映される。[第3の実施形態の変形例]第3の実施形態のリソース決定処理では、クラスタ53に属しない論理ホスト31を、リソース量を変更する共有クラスタ53として選択してもよい。この場合、リソース決定処理は以下のようになる。ステップS2021では、対象クラスタ53に属する論理ホスト31に対応するLPAR51と同一のサーバ40上に生成されたLPAR51に対応し、かつ、クラスタ53に属しない論理ホスト31が共有クラスタ53として選択される。他の処理は同一であるため説明を省略する。また。リソース変更処理は、第3の実施形態と同一であるため説明を省略する。本発明の一実施形態によれば、論理ホスト31から構成されるクラスタ53を備えることによって、クラスタ53を構成するホスト数を増減することなく、ホストの負荷に応じてクラスタ53のリソース量を変更することができる。特許請求の範囲に記載した以外の発明の観点の代表的なものとして、次のものがあげられる。1仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムにおけるリソース管理方法であって、前記各計算機は、第1のプロセッサと、前記第1のプロセッサに接続される第1のメモリと、前記第1のプロセッサに接続される第1のI/Oインタフェースとを有し、前記管理計算機は、第2のプロセッサと、前記第2のプロセッサに接続される第2のメモリと、前記第2のプロセッサに接続される第2のI/Oインタフェースとを有し、前記ホストは、前記第1のプロセッサが、前記仮想化プログラムを実行する物理ホストと、前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、を含み、前記管理計算機は、複数の前記ホストを一つのリソースグループとするクラスタが有するリソースを管理するリソース管理部を有し、前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、前記リソース管理方法は、前記リソース管理部が、前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定する第1のステップと、前記リソース管理部が、前記対象論理ホストに対する物理リソースの割り当て量を変更する第2のステップと、を含むことを特徴とするリソース管理方法。2前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、前記第2のステップは、前記リソース管理部が、物理リソースの割り当てが変更可能な他の前記論理区画を特定するステップと、前記リソース管理部が、前記他の論理区画に割り当てられた物理リソースの変更要求を前記論理区画管理部に送信するステップと、前記論理区画管理部が、前記他の論理区画に割り当てられた物理リソースを所定量だけ削減するステップと、前記リソース管理部が、前記対象論理ホストに対応する前記論理区画に割り当てられる物理リソースの変更要求を前記論理区画管理部に送信するステップと、前記論理区画管理部が、前記対象論理ホストに対応する前記論理区画に、前記所定量の物理リソースを追加するステップと、を含むことを特徴とする1に記載にリソース管理方法。3前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、前記第2のステップでは、前記リソース管理部が、前記対象論理ホストに対応する前記論理区画の移動要求を前記論理区画管理部に送信するステップと、前記論理区画管理部が、前記対象論理ホストに対応する論理区画を、他の前記計算機上に移動させるステップと、前記リソース管理部が、前記対象論理ホストに対応する論理区画に割り当てられた物理リソースの変更要求を送信するステップと、前記論理区画管理部が、前記対象論理ホストに対応する論理区画に、所定量の物理リソースを追加するステップと、を含むことを特徴とする1に記載にリソース管理方法。4前記論理区画管理部は、前記対象論理ホストに対応する論理区画の物理リソースを変更した後に、前記クラスタ管理部に変更結果を送信するステップと、前記クラスタ管理部が、前記対象論理ホストに対応する論理区画の物理リソースの変更結果を反映するステップと、を含むことを特徴とする請求項2又は3に記載のリソース管理方法。5仮想計算機を管理する仮想化プログラムを実行するホストを提供する複数の計算機、及び、前記各計算機とネットワークを介して接続され、前記計算機を管理する管理計算機を備える計算機システムであって、前記各計算機は、第1のプロセッサと、前記第1のプロセッサに接続される第1のメモリと、前記第1のプロセッサに接続される第1のI/Oインタフェースとを有し、前記管理計算機は、第2のプロセッサと、前記第2のプロセッサに接続される第2のメモリと、前記第2のプロセッサに接続される第2のI/Oインタフェースとを有し、前記ホストは、前記第1のプロセッサが、前記仮想化プログラムを実行する物理ホストと、前記計算機が有する物理リソースを論理的に分割して生成された論理区画に割り当てられるプロセッサが、前記仮想化プログラムを実行する論理ホストと、を含み、前記管理計算機は、複数の前記ホストを一つのリソースグループとするクラスタが有するリソースを管理するリソース管理部を有し、前記クラスタは、一以上の前記物理ホストと一以上の前記論理ホストとから構成される複合クラスタを少なくとも一以上含み、前記計算機システムは、前記リソース管理部が、前記複合クラスタを構成する前記ホストの負荷を分散するための物理リソースが不足している場合に、前記複合クラスタを構成する対象論理ホストを特定し、前記対象論理ホストに対する物理リソースの割り当て量を変更することを特徴とする計算機システム。6前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、前記リソース管理部が、物理リソースの割り当てが変更可能な他の前記論理区画を特定し、前記リソース管理部が、前記他の論理区画に割り当てられた物理リソースの変更要求を前記論理区画管理部に送信し、前記論理区画管理部が、前記他の論理区画に割り当てられた物理リソースを所定量だけ削減し、前記リソース管理部が、前記対象論理ホストに対応する前記論理区画に割り当てられる物理リソースの変更要求を前記論理区画管理部に送信し、前記論理区画管理部が、前記対象論理ホストに対応する前記論理区画に、前記所定量の物理リソースを追加することを特徴とする5に記載に計算機システム。7前記管理計算機は、さらに、前記クラスタを構成し、前記クラスタを管理するクラスタ管理部と、前記各計算機上に生成された前記論理区画を管理する論理区画管理部と、を有し、前記対象論理ホストに対する物理リソースの割り当て量を変更する場合に、前記リソース管理部が、前記対象論理ホストに対応する前記論理区画の移動要求を前記論理区画管理部に送信し、前記論理区画管理部が、前記対象論理ホストに対応する論理区画を、他の前記計算機上に移動させ、前記リソース管理部が、前記対象論理ホストに対応する論理区画に割り当てられた物理リソースの変更要求を送信し、前記論理区画管理部が、前記対象論理ホストに対応する論理区画に、所定量の物理リソースを追加することを特徴とする5に記載に計算機システム。8前記論理区画管理部は、前記対象論理ホストに対応する論理区画の物理リソースを変更した後に、前記クラスタ管理部に変更結果を送信し、前記クラスタ管理部が、前記対象論理ホストに対応する論理区画の物理リソースの変更結果を反映することを特徴とする請求項6又は7に記載の計算機システム。