WO2012164624A1 - 仮想マシンのリソース管理装置及び管理方法 - Google Patents

Abstract

　システム全体を安定化させ得る管理装置及び管理方法を提案する。　複数の物理サーバを複数の論理グループに分けて管理し、各論理グループ内における各物理サーバの負荷バランスを平準化するように、いずれかの物理サーバ上で稼働し又は稼働予定の仮想マシンを同一の論理グループ内の他の物理サーバに移動するよう対応する物理サーバを制御する管理装置及び方法において、論理グループ内のリソースが不足したときに発生する仮想マシンの移動パターンをエラールールとして設定し、当該エラールールに該当する仮想マシンの移動が発生した場合に、当該仮想マシンの移動が発生した論理グループ以外の論理グループに所属する物理サーバの中から１つの物理サーバを選択し、選択した物理サーバをエラールールに該当する仮想マシンの移動が発生した論理グループに貸し出すように、対応する論理グループの構成を変更するようにした。

Description

仮想マシンのリソース管理装置及び管理方法

　本発明は、仮想マシンのリソース管理装置及び管理方法に管理し、特に、ＤＲＳ（Distributed Resource Scheduler）機能が搭載された管理サーバに適用して好適なものである。

　近年、物理的なサーバ装置（以下、これを物理サーバと呼ぶ）上に仮想的なサーバ装置（以下、これを仮想マシンと呼ぶ）を構築することでサーバの集約を行い、所有リソースの効率的な運用をサポートするシステムが普及している。また、「VMotion」及び「ＤＲＳ」などのホットマイグレーション機能を利用した仮想化技術の進歩により、可用性の高いシステムの構築が進んでいる。

　ここで、「VMotion」とは、ある物理サーバ上で動作中の仮想マシンを動作させたまま別の物理サーバ上に移動する機能をいう。VMotion機能によれば、ＩＰ（Internet Protocol）アドレスやＭＡＣ（Media Access Control）などを変更することなく、ＴＣＰ（Transmission Control Protocol）などのセッションも完全に維持したまま仮想マシンを他の物理サーバに移動することができる。VMotion機能は、実際のデータを移動するのではなく、仮想マシンの実行インスタンスのデータを移動する機能であり、実際のデータは共有ストレージに配置される。

　また「ＤＲＳ」とは、計算機システム内の複数の物理サーバをＶＭクラスタという複数の論理的なグループ（以下、これを論理グループと呼ぶ）に分け、これら論理グループ内の物理サーバ群の負荷（ＣＰＵ利用率及びメモリ利用率）のばらつきを標準偏差として管理する機能をいう。この標準偏差の値が予め設定された目標値を超えた場合に自動的に「VMotion」を実行し、仮想マシンを論理グループ内の他の物理サーバに移行させる。ＤＲＳ機能は、物理サーバ間の負荷バランスの平準化を行うことによりパフォーマンスの最大化を行うことを目的とする。またＤＲＳ機能によれば、例えば「仮想マシンＡと仮想マシンＢとは共存不可」、「仮想マシンＣ及び仮想マシンＤは共存」といった仮想マシンごとの移行ルールを策定することができる。

　なお、下記特許文献１には、ＤＲＳ機能に関連して、仮想マシンを他の物理サーバに移動させるごとに、移動時刻と、仮想マシン識別子と、移動元及び移動先の物理サーバ識別子とを含む移動履歴を記憶しておき、仮想マシンの障害などのイベントが発生したときに、障害にかかる仮想マシンが現在存在する物理サーバ及び過去に存在していた物理サーバのログファイルへのリンクを張ったイベントメッセージを生成し、生成したイベントメッセージを管理端末の画面に表示する技術が開示されている。

特開２００７－３２３２４４号公報

　ところで、計算機システムの管理コストを抑えるためには、自律的に負荷バランスをとって仮想マシンの配置を構成するＤＲＳ機能は有効な手段であるが、マルチテナント型のデータセンタなどでは、障害の影響範囲を限定したり、権限による担当の分割を行うなどの必要があるため、ある程度運用者がリソースのグルーピングを行い、複数の論理グループを構築する必要がある。

　既存技術では、論理グループ単位でのリソースの最適化ができるが、システム全体を最適な状態に移行することについては考慮されていない。そのため、ある論理グループ内のリソースが不足した状態となると、他の論理グループでは平衡状態であっても、リソースが不足した論理グループ内ではいつまでもホットマイグレーションが収束せず、ホットマイグレーションが頻発するという問題がある。

　また論理グループ内でホットマイグレーションが頻発すると、ネットワークの負荷が増大し、計算機システムに余分な負荷がかかる。計算機システムの安定稼働を実現するためには、仮想マシンを「動かさない」ことが鉄則であるため、不要なホットマイグレーションは抑止することが望ましい。

　本発明は以上の点を考慮してなされたもので、システム全体を安定化させ得る仮想マシンのリソース管理装置及び管理方法を実現しようとするものである。

　かかる課題を解決するため本発明においては、それぞれ仮想化プログラムが実装された複数の物理サーバを複数の論理グループに分けて管理し、各前記論理グループ内における各物理サーバの負荷バランスを平準化するように、いずれかの前記物理サーバ上で稼働し又は稼働予定の仮想マシンを同一の前記論理グループ内の他の前記物理サーバに移動するよう対応する前記物理サーバを制御する管理装置において、前記論理グループ内のリソースが不足したときに発生する前記仮想マシンの移動パターンをエラールールとして設定でき、設定された前記エラールールに該当する前記仮想マシンの移動の有無を監視する監視部と、前記エラールールに該当する前記仮想マシンの移動が発生したことが前記監視部により検出された場合に、当該仮想マシンの移動が発生した前記論理グループ以外の前記論理グループに所属する前記物理サーバの中から１つの前記物理サーバを選択し、選択した物理サーバ上で稼働し又は稼働予定の前記仮想マシンを同一論理グループ内の他の前記物理サーバに移動させた後に、当該選択した物理サーバを前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに貸し出すように、対応する前記論理グループの構成を変更する論理グループ構成変更部とを設けるようにした。

　また本発明においては、それぞれ仮想化プログラムが実装された複数の物理サーバを複数の論理グループに分けて管理し、各前記論理グループ内における各物理サーバの負荷バランスを平準化するように、いずれかの前記物理サーバ上で稼働し又は稼働予定の仮想マシンを同一の前記論理グループ内の他の前記物理サーバに移動するよう対応する前記物理サーバを制御する管理方法において、前記論理グループ内のリソースが不足したときに発生する前記仮想マシンの移動パターンをエラールールとして設定する第１のステップと、設定された前記エラールールに該当する前記仮想マシンの移動の発生の有無を監視し、前記エラールールに該当する前記仮想マシンの移動が発生したことを検出した場合に、当該仮想マシンの移動が発生した前記論理グループ以外の前記論理グループに所属する前記物理サーバの中から１つの前記物理サーバを選択し、選択した物理サーバ上で稼働し又は稼働予定の前記仮想マシンを同一論理グループ内の他の前記物理サーバに移動させた後に、当該選択した物理サーバを前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに貸し出すように、対応する前記論理グループの構成を変更する第２のステップとを設けるようにした。

　本発明の管理装置及び管理方法によれば、リソース不足の論理グループに対して他の論理グループから物理サーバが貸し出されるため、論理グループ間の負荷バランスを平準化することができる。また論理グループ内における仮想マシンの移動の発生を抑えることができる。

　本発明によれば、論理グループ間における負荷バランスの平準化及び各論理グループ内における仮想マシンの移動の発生を抑えることができ、かくしてシステム全体を安定化させ得る仮想マシンのリソース管理装置及び管理方法を実現できる。

本実施の形態による計算機システムの全体構成を示すブロック図である。 管理サーバのメモリに格納された各種プログラム及び各種情報の説明に供する概念図である。 物理サーバ構成テーブルの構成を示す概念図である。 仮想マシン予約情報一覧の構成を示す概念図である。 ホットマイグレーション情報テーブルの構成を示す概念図である。 イベント一覧の構成を示す概念図である。 リソース取得先一覧の構成を示す概念図である。 移動先候補一覧の構成を示す概念図である。 借用リソース管理テーブルの構成を示す概念図である。 物理サーバ一覧の構成を示す概念図である。 第１のイベント監視処理の処理手順を示すフローチャートである。 第２のイベント監視処理の処理手順を示すフローチャートである。 論理グループ構成変更処理の処理手順を示すフローチャートである。 リソース取得先一覧作成処理の処理手順を示すフローチャートである。 貸出し期限計算処理の処理手順を示すフローチャートである。 貸出し期限計算処理の処理手順を示すフローチャートである。 リソース取得先一覧作成処理の処理手順を示すフローチャートである。 リソース取得先一覧ソート処理の処理手順を示すフローチャートである。 移動先物理サーバ決定処理の処理手順を示すフローチャートである。 物理サーバ貸出し処理の処理手順を示すフローチャートである。 ホットマイグレーション処理の処理手順を示すフローチャートである。 借用リソース返却処理の処理手順を示すフローチャートである。 借用リソース返却処理の処理手順を示すフローチャートである。 貸出し期限通知処理の処理手順を示すフローチャートである。 貸出し解除処理の処理手順を示すフローチャートである。

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

（１）本実施の形態による計算機システムの構成
　図１において、１は全体として本実施の形態による計算機システムを示す。この計算機システム１は、複数の物理サーバ２と、管理サーバ３及び管理クライアント４とが通信ネットワーク５を介して相互に接続されることにより構成されている。

　物理サーバ２は、パーソナルコンピュータなどから構成されるコンピュータ装置であり、ＣＰＵ（Central Processing Unit）１０、メモリ１１及び記憶装置１２等の情報処理資源を備えて構成される。物理サーバ２のメモリ１１には、仮想化プログラムであるハイパーバイザ１３が格納されており、このハイパーバイザ１３をＣＰＵ１０が実行することにより１又は複数の仮想マシン１４がメモリ１１上に構築され、これら仮想マシン１４によりユーザに対して各種のサービスが提供される。

　管理サーバ３は、例えばパーソナルコンピュータや、ワークステーション又はメインフレームなどから構成され、ＣＰＵ２０、メモリ２１及び記憶装置２２等の情報処理資源を備えて構成される。管理サーバ３は、計算機システム１内に存在する各物理サーバ２及び各仮想マシン１４の各種情報を各物理サーバ２から収集して管理する。また管理サーバ３は、システム管理者の設定に応じて、１又は複数の物理サーバ２をまとめて論理的なグループ（以下、これを論理グループと呼ぶ）ＬＧを構築し、論理グループＬＧ単位でＣＰＵ性能及びメモリ容量などのリソースを管理することもできる。物理サーバ２上における仮想マシン１４の生成、停止及び移動などの仮想マシン１４に関する管理は、この管理サーバ３により行われる。

　管理クライアント４は、ＣＰＵ３０、記憶装置３１及びメモリ（図示せず）などの情報処理資源と、入力装置３２及び出力装置３３となどを備えたコンピュータ装置であり、例えばパーソナルコンピュータなどから構成される。ユーザは、この管理クライアント４を用いて、管理サーバ３から各物理サーバ２及び各仮想マシン１４の構成情報を取得したり、仮想マシン１４の生成、起動及び停止の予約などの各種設定を管理サーバ３に対して行うことができる。

（２）本実施の形態による論理グループ構成変更機能
（２－１）論理グループ構成変更機能の概要及び各種テーブルの構成
　次に、本実施の形態による計算機システム１に搭載された論理グループ構成変更機能について説明する。

　本実施の形態の計算機システム１の場合、個々の論理グループＬＧ内の物理サーバ２の負荷バランスが崩れた場合に、これら物理サーバ２間の負荷バランスを平準化するように、必要な仮想マシン１４を同じ論理グループＬＧ内の他の物理サーバ２にホットマイグレーションさせるＤＲＳ機能が管理サーバ３に搭載されている。

　実際上、管理サーバ３は、計算機システム１内の各物理サーバ２の負荷状況をシステム管理者により予め設定された論理グループＬＧ単位で管理しており、いずれかの論理グループＬＧ内の物理サーバ２間の負荷バランスが崩れた場合に、対応する物理サーバ２を制御することにより、その物理サーバ２上で稼働する対応する仮想マシン１４を同じ論理グループＬＧ内の他の物理サーバ２にホットマイグレーションさせる。

　加えて、本実施の形態による計算機システム１では、システム全体で共通のホットマイグレーションのエラールールを設定することができる。このエラールールは、論理グループＬＧ内のリソースが不足したときに発生すると考えられるホットマイグレーションの発生パターンである。そして本計算機システム１の場合、管理サーバ３には、そのエラールールに該当するホットマイグレーションが発生した場合に、論理グループＬＧ内でホットマイグレーションが収束していない（その論理グループＬＧ内のリソースが不足している）ものとして、他の論理グループＬＧの余剰リソースを検索し、エラールールに該当するホットマイグレーションが発生した論理グループＬＧに対して他の論理グループＬＧから物理サーバ２を貸し出すように、論理グループＬＧの構成を変更する論理グループ構成変更機能が搭載されている。

　ここで、本実施の形態においては、かかる「エラールール」の１つ目のパターンとして、ある仮想マシン１４がホットマイグレーションされた後、所定時間内（以下、３０分以内とする）に移動先の物理サーバ２上で稼働していた他の仮想マシン１４が他の物理サーバ２にホットマイグレーションされた場合（以下、これを第１のエラールールと呼ぶ）が規定されている。これは、物理サーバ２の負荷バランスを考慮して論理グループＬＧ内で仮想マシン１４のホットマイグレーションを実行したにも関わらず、かかるホットマイグレーションが他のホットマイグレーションを誘発しており、このようなホットマイグレーションが発生した場合、その論理グループＬＧ内でリソースが不足しているものと判断できるからである。

　また本実施の形態においては、かかる「エラールール」の２つ目のパターンとして、ある論理グループＬＧ内で特定の仮想マシン１４のホットマイグレーションの発生頻度が予め設定された頻度（以下、１日に３回とする）以上となっている場合（以下、これを第２のエラールールと呼ぶ）が規定されている。これは、論理グループＬＧ内の物理サーバ２の負荷バランスを考慮して自律的に行われる仮想マシンのホットマイグレーションが収束していないため、このようなホットマイグレーションが発生している場合は、その論理グループ内でリソースが不足していると判断できるからである。

　そして管理サーバ３は、ＤＲＳ機能により仮想マシン１４のホットマイグレーションを実行させた場合、そのホットマイグレーションが第１又は第２のエラールールに該当するイベントであったか否かを判断し、そのホットマイグレーションが第１又は第２のエラールールに該当するイベントであった場合には、他の論理グループＬＧにおける余剰分のリソース量を確認し、リソースに余力がある論理グループＬＧからその第１又は第２のエラールールに該当するホットマイグレーションを行った論理グループＬＧに対して期限を決めて物理サーバを貸し出すように、対応する論理グループＬＧの構成を一時的に変更する（論理グループ構成変更処理）。

　また管理サーバ３は、ある論理グループＬＧから他の論理グループＬＧに貸し出した物理サーバ２の貸出し期限を管理し、その貸出し期限が近付くと、その旨をシステム管理者に通知する（貸出し期限通知処理）一方、かかる貸出し期限の１日以内となると、その物理サーバ２を貸出し元の論理グループＬＧに返却するように論理グループＬＧの構成を変更する（借用リソース返却処理）。

　さらに管理サーバ３は、システム管理者の入力操作に応じて、ある論理グループＬＧから他の論理グループＬＧに貸し出した物理サーバ２の貸出し状態を解除して、その物理サーバ２をそのまま貸出し先の論理グループＬＧに所属させる処理（以下、これを貸出し解除処理と呼ぶ）も実行する。

　以上のような本実施の形態による論理グループ構成変更機能を実現するための手段として、管理サーバ３のメモリ２１には、図２に示すように、論理グループ構成変更プログラム４０と、物理サーバ構成テーブル４１、仮想マシン予約情報一覧４２、ホットマイグレーション情報テーブル４３、イベント一覧４４、リソース取得先一覧４５、移動先候補一覧４６、借用リソース管理テーブル４７及び物理サーバ一覧４８とが格納されている。

　このうち論理グループ構成変更プログラム４０は、上述のような本実施の形態による論理グループ構成変更機能に基づく各種処理を実行するためのプログラムである。

　また物理サーバ構成テーブル４１は、管理サーバ３が計算機システム１内に存在する各物理サーバ２から収集したこれら物理サーバ２の構成情報を管理するために利用されるテーブルであり、図３に示すように、物理サーバ欄４１Ａ、ＣＰＵ性能欄４１Ｂ、メモリ容量欄４１Ｃ及び所属論理グループ欄４１Ｄから構成される。

　そして物理サーバ欄４１Ａには、対応する物理サーバ２のサーバ名（例えば装置ＩＤ）が格納される。またＣＰＵ性能欄４１Ｂには、それぞれその物理サーバに搭載されたＣＰＵ１０（図１）の性能が格納され、メモリ容量欄４１Ｃには、当該物理サーバ２に搭載されたメモリ１１（図１）のメモリ容量が格納される。さらに所属論理グループ欄４１Ｄには、その物理サーバ２が所属する論理グループＬＧのグループ名が格納される。

　従って、図３の場合、「物理サーバ1」という物理サーバ２は、それぞれ「2GHz」の処理性能を有する４つのコアを有するＣＰＵ１０と、「6GB」の容量を有するメモリ１１とが搭載され、「論理グループＥ」という論理グループＬＧに所属するようシステム管理者により設定されていることが示されている。

　仮想マシン予約情報一覧４２は、物理サーバ２上で稼働し又は稼働予定の仮想マシン１４（図１）を管理するために利用される一覧であり、ユーザ操作に応じて管理クライアント４から管理サーバ３に与えられる仮想マシン１４の予約設定要求に応じて論理グループＬＧごとに作成される。この仮想マシン予約情報一覧４２は、図４に示すように、仮想マシン欄４２Ａ、ＣＰＵ割当て欄４２Ｂ、メモリ割当て欄４２Ｃ、割当て先欄４２Ｄ、開始日時欄４２Ｅ及び終了日時欄４２Ｆから構成される。

　そして仮想マシン欄４２Ａには、その仮想マシン予約情報一覧４２に対応する論理グループＬＧに所属するいずれかの物理サーバ２上で稼働させるよう予約設定要求において指定された仮想マシン１４のホスト名が格納され、ＣＰＵ割当て量欄４２Ｂには、その仮想マシン１４に割り当てるべきＣＰＵ１０の性能が格納される。またメモリ割当て量欄４２Ｃには、その仮想マシン１４に割り当てるべきメモリ容量が格納され、割当て先欄４２Ｄには、その仮想マシン１４を稼働させるべき物理サーバ２のサーバ名が格納される。さらに開始日時欄４２Ｅには、その仮想マシン１４の稼働を開始すべき日時（開始日時）が格納され、終了日時欄４２Ｆには、その仮想マシン１４の稼働を終了すべき日時（終了日時）が格納される。なお、これら仮想マシン欄４２Ａ、ＣＰＵ割当て欄４２Ｂ、メモリ割当て欄４２Ｃ、割当て先欄４２Ｄ、開始日時欄４２Ｅ及び終了日時欄４２Ｆにそれぞれ格納される情報は、すべてユーザ操作に応じて管理クライアント４から管理サーバ３に与えられる予約設定要求において指定されたものである。

　従って、図４の場合、「2010/07/10 00:00:00」から「2011/08/10 00:00:00」までの間、「物理サーバ1」という物理サーバ２上に、ＣＰＵ割当て量が「2GHz×1コア」、メモリ割当て量が「2GB」の「仮想マシンＡ」という仮想マシン１４を稼働すべきことがユーザにより設定されていることが示されている。

　ホットマイグレーション情報テーブル４３は、各論理グループＬＧ内で発生したホットマイグレーションを管理するために利用されるテーブルである。管理サーバ３は、ＤＲＳ機能により物理サーバ２を制御してホットマイグレーションを実行させた場合に、そのホットマイグレーションに関する各種情報をホットマイグレーション情報テーブル４３に登録して管理する。このホットマイグレーション情報テーブル４３は、図５に示すように、発生日時欄４３Ａ、移動仮想マシン欄４３Ｂ、移動元欄４３Ｃ、移動先欄４３Ｄ及び論理グループ欄４３Ｅから構成される。

　そして発生日時欄４３Ａには、対応するホットマイグレーションが発生した日時が格納され、移動仮想マシン欄４３Ｂには、そのホットマイグレーションにより同一の論理グループＬＧ内の他の物理サーバ２に移動された仮想マシン１４のホスト名が格納される。また移動元欄４３Ｃには、かかる仮想マシン１４の移動元の物理サーバ２のサーバ名が格納され、移動先欄４３Ｄには、当該仮想マシン１４の移動先の物理サーバ２のサーバ名が格納される。さらに論理グループ欄４３Ｅには、そのホットマイグレーションが発生した論理グループＬＧのグループ名が格納される。

　従って、図５の場合、「論理グループＥ」という論理グループＬＧでは、「2011/02/03 18:00」に、「仮想マシンA_A」という仮想マシン１４を「物理サーバA_A」という物理サーバ２から「物理サーバA_B」という物理サーバ２に移動させるホットマイグレーションが行われたことが示されている。

　一方、イベント一覧４４は、計算機システム１内で発生した第１又は第２のエラールールに該当するホットマイグレーションを管理するための一覧であり、図６に示すように、イベント内容欄４４Ａ、発生日時欄４４Ｂ、発生元欄４４Ｃ及び原因仮想マシン欄４４Ｄから構成される。

　そしてイベント内容欄４４Ａには、かかるホットマイグレーションが該当するエラールール種別が格納され、発生日時欄４４Ｂには、そのホットマイグレーションが発生した日時が格納される。また発生元欄４４Ｃには、そのホットマイグレーションが発生した論理グループＬＧのグループ名が格納され、原因仮想マシン欄４４Ｄには、そのホットマイグレーションが発生する原因となった仮想マシン１４のホスト名が格納される。なお、図中、「エラールール１」は第１のエラールールに該当し、「エラールール２」は第２のエラールールに該当する。

　従って、図６の場合、「2011/2/4 14:00」に「エラールール１（第１のエラールール）」に該当するホットマイグレーションが「論理グループＡ」という論理グループＬＧにおいて発生し、その原因となった仮想マシン１４のホスト名が「仮想マシンA_A」であることが示されている。

　他方、リソース取得先一覧４５は、第１又は第２のエラールールに該当するホットマイグレーションが発生した論理グループＬＧに対して他の論理グループＬＧから物理サーバ２を貸し出す際に、その物理サーバ２の貸出し期限を計算するために一時的に作成される一覧である。このリソース取得先一覧４５は、図７に示すように、物理サーバ欄４５Ａ、余剰ＣＰＵ性能欄４５Ｂ、余剰メモリ容量欄４５Ｃ、貸出し期限欄４５Ｄ及び貸出し元欄４５Ｅから構成される。

　そして物理サーバ欄４５Ａには、かかる検索により余力を有する物理サーバ２として検出された物理サーバ２のサーバ名が格納される。

　また余剰ＣＰＵ性能欄４５Ｂには、その物理サーバ２が有する余剰分のＣＰＵ性能（以下、これを余剰ＣＰＵ性能と呼ぶ）が格納される。この余剰ＣＰＵ性能は、その物理サーバ２に搭載されたＣＰＵ１０（図１）のＣＰＵ性能の総量（コア性能×コア数）から、当該物理サーバ２上で稼働する仮想マシン１４に割り当てるべきＣＰＵ性能の総和を減算することにより算出された値である。

　さらに余剰メモリ容量欄４５Ｃには、その物理サーバ２が有する余剰分のメモリ容量（以下、これを余剰メモリ容量と呼ぶ）が格納される。この余剰メモリ容量も、その物理サーバ２に搭載されたメモリ１１の容量から、当該物理サーバ２上で稼働する仮想マシン１４に割り当てるべきメモリ容量の総和を減算することにより算出された値である。

　さらに貸出し期限欄４５Ｄには、第１又は第２のエラールールに該当するホットマイグレーションが発生した論理グループＬＧに対してその物理サーバ２を貸し出し得る期限（貸出し期限）が格納され、貸出し元欄４５には、その物理サーバ２の貸出し元となる論理グループＬＧのグループ名が格納される。

　従って、図７の例では、「論理グループＥ」という論理グループＬＧに所属する「物理サーバ1」という物理サーバ２は、合計で「6GHz」の余剰ＣＰＵ性能と、「4GB」の余剰メモリ容量とを有しており、その貸出し期限は「2011/08/10 00:00」であることが示されている。

　移動先候補一覧４６は、第１又は第２のエラールールに該当するホットマイグレーションが発生した論理グループＬＧに対して他の論理グループＬＧから物理サーバ２を貸し出す際に、その貸出し対象の物理サーバ２上で稼働する仮想マシン１４の移動先となり得る物理サーバ２を決定するために一時的に作成される一覧であり、図８に示すように、仮想マシン欄４６Ａ及び移動先候補欄４６Ｂから構成される。

　そして仮想マシン欄４６Ａには、第１又は第２のエラールールに該当するホットマイグレーションが発生した論理グループＬＧに対する貸出し候補の物理サーバ（以下、これを貸出し候補物理サーバと呼ぶ）２上で稼働する各仮想マシン１４のホスト名が格納され、移動先候補欄４６Ｂには、対応する仮想マシン１４の移動先となり得る物理サーバ２のサーバ名が格納される。

　従って、図８の例では、貸出し候補物理サーバ２上では「仮想マシンＢ」という仮想マシン１４が稼働しており、その移動先として「物理サーバ1」という物理サーバ２が候補として挙げられていることが示されている。

　また借用リソース管理テーブル４７は、ある論理グループＬＧに対して他の論理グループＬＧから貸し出された物理サーバ２を管理するために利用される一覧であり、図９に示すように、物理サーバ欄４７Ａ、貸出し期限欄４７Ｂ、借用元欄４７Ｃ及び借用者欄４７Ｄから構成される。

　そして物理サーバ欄４７Ａには、ある論理グループＬＧ（借用者）に対して他の論理グループＬＧ（借用元）から貸し出された物理サーバ２のサーバ名が格納され、貸出し期限欄４７Ｂには、その物理サーバ２をいつまで貸し出せるかの期限を表す貸出し期限が格納される。

　また借用元欄４７Ｃには、その物理サーバ２の貸出し元（借用元）の論理グループＬＧのグループ名が格納され、借用者欄４７Ｄには、その物理サーバ２の貸出し先（借用者）の論理グループＬＧのグループ名が格納される。

　従って、図９の例では、「論理グループＢ」という論理グループＬＧに対して「論理グループＥ」という論理グループＬＧから「物理サーバ２」という物理サーバ２が「2011/08/09 00:00」までを貸出し期限として貸し出されていることが示されている。

　物理サーバ一覧４８は、上述のように貸出し候補物理サーバ２を決定する移動先物理サーバ決定処理（図１８）や、他の論理グループＬＧに貸し出された物理サーバ２を貸出し元の論理グループＬＧに返却する借用リソース返却処理（図２１Ａ及び図２１Ｂ）時に一時的に作成される一覧である。

　この物理サーバ一覧４８は、図１０に示すように、物理サーバ欄４８Ａ、ＣＰＵ性能欄４８Ｂ、メモリ容量欄４８Ｃ及び所属論理グループ欄４８Ｄから構成される。なお、これら物理サーバ欄４８Ａ、ＣＰＵ性能欄４８Ｂ、メモリ容量欄４８Ｃ及び所属論理グループ欄４８Ｄに格納される情報は、物理サーバ構成テーブル４１（図３）の物理サーバ欄４１Ａ、ＣＰＵ性能欄４１Ｂ、メモリ容量欄４１Ｃ及び所属論理グループ欄４１Ｄにそれぞれ格納される情報と同じであるため、ここでのこれ以上の説明は省略する。

（２－２）管理サーバのＣＰＵの各種処理
　次に、論理グループ構成変更機能に関して管理サーバ３のＣＰＵ２０により実行される各種処理の具体的な処理内容について説明する。
（２－２－１）第１のイベント監視処理
　図１１は、管理サーバ３のＣＰＵ２０により定期的（例えば１日１回）に実行される第１のイベント監視処理の処理手順を示す。上述のように本実施の形態による計算機システム１では、ある仮想マシン１４がホットマイグレーションされてから３０分以内に、移動先の物理サーバ２上で稼働していた他の仮想マシン１４が他の物理サーバ２にホットマイグレーションされた場合を第１のエラールールに該当するホットマイグレーションとして規定されている。そこで、管理サーバ３のＣＰＵ２０は、この図１１に示す第１のイベント監視処理を定期的に実行することにより、かかる第１のエラールールに該当するホットマイグレーションの発生の有無を監視する。

　実際上、ＣＰＵ２０は、この第１のイベント監視処理を開始すると、まず、予めシステム管理者により設定された複数の論理グループＬＧの中から１つの論理グループＬＧを選択し（ＳＰ１）、選択した論理グループＬＧにおいて発生したホットマイグレーションに関する情報（以下、これをホットマイグレーション情報と呼ぶ）をすべてホットマイグレーション情報テーブル４３から取得する（ＳＰ２）。

　続いて、ＣＰＵ２０は、ステップＳＰ２において取得したホットマイグレーション情報の中から１つのホットマイグレーション情報を選択し（ＳＰ３）、そのホットマイグレーション情報に対応するホットマイグレーションの「移動先」の物理サーバ２が「移動元」の物理サーバ２となっているホットマイグレーションに関する情報（ホットマイグレーション情報）が、ステップＳＰ２において取得したホットマイグレーション情報に含まれているか否かを判断する（ＳＰ４）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ３に戻る。これに対してＣＰＵ２０は、ステップＳＰ４の判断で肯定結果を得ると、ステップＳＰ２において取得した各ホットマイグレーション情報にそれぞれ対応するホットマイグレーションの中から「移動先」の物理サーバ２が「移動元」の物理サーバ２となっているホットマイグレーションのホットマイグレーション情報を１つ選択し（ＳＰ５）、当該ホットマイグレーション情報に対応するホットマイグレーションの発生日時がステップＳＰ３で選択したホットマイグレーションの発生日時の３０分以内であるか否かを判断する（ＳＰ６）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ８に進む。これに対してＣＰＵ２０は、ステップＳＰ６の判断で肯定結果を得ると、ステップＳＰ３で選択したホットマイグレーションのホットマイグレーション情報及びそのステップＳＰ５で選択したホットマイグレーションのホットマイグレーション情報に基づいて、発生時刻が早いホットマイグレーションをそのとき発生した第１のエラールールに該当するホットマイグレーションの発生原因となったホットマイグレーションとして特定し、当該ホットマイグレーションの発生時刻、イベント内容、発生元の論理グループＬＧのグループ名及びそのイベントの原因となった仮想マシン１４のホスト名をイベント一覧４４（図６）に登録する（ＳＰ７）。

　またＣＰＵ２０は、この後、ステップＳＰ４の判断で肯定結果を得られるすべてのホットマイグレーションについて同様の処理を実行し終えたか否かを判断する（ＳＰ８）。そしてＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ５に戻り、この後、ステップＳＰ５～ステップＳＰ８の処理を繰り返す。そしてＣＰＵ２０は、やがて該当するすべてのホットマイグレーションについてステップＳＰ５～ステップＳＰ８の処理を実行し終えることによりステップＳＰ８において肯定結果を得ると、ステップＳＰ２においてホットマイグレーション情報を取得したすべてのホットマイグレーションについてステップＳＰ３～ステップＳＰ８の処理を実行し終えたか否かを判断する（ＳＰ９）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ３に戻り、この後、ステップＳＰ３において選択するホットマイグレーション情報を未処理の他のホットマイグレーション情報に順次切り替えながらステップＳＰ３～ステップＳＰ９の処理を繰り返す。

　そしてＣＰＵ２０は、やがてステップＳＰ２においてホットマイグレーション情報を取得したすべてのホットマイグレーションについてステップＳＰ３～ステップＳＰ９の処理を実行し終えることによりステップＳＰ９において肯定結果を得ると、すべての論理グループＬＧについてステップＳＰ２～ステップＳＰ９の処理を実行し終えたか否かを判断する（ＳＰ１０）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１に戻り、この後、ステップＳＰ１～ステップＳＰ１０の処理を繰り返す。そしてＣＰＵ２０は、やがてすべての論理グループＬＧについてステップＳＰ２～ステップＳＰ９の処理を実行し終えることによりステップＳＰ１０において肯定結果を得ると、この第１のイベント監視処理を終了する。

（２－２－２）第２のイベント監視処理
　図１２は、管理サーバ３のＣＰＵ２０により定期的（例えば１日１回）に実行される第２のイベント監視処理の処理手順を示す。上述のように本実施の形態による計算機システム１では、ある論理グループＬＧ内で特定の仮想マシン１４のホットマイグレーションが１日に３回以上発生している場合を第２のエラールールに該当するホットマイグレーションとして規定されている。そこで、管理サーバ３のＣＰＵ２０は、この図１２に示す第２のイベント監視処理を定期的に実行することにより、かかる第２のエラールールに該当するホットマイグレーションの発生を監視する。

　実際上、ＣＰＵ２０は、この第２のイベント監視処理を開始すると、まず、予めシステム管理者により設定された複数の論理グループＬＧの中から１つの論理グループＬＧを選択し（ＳＰ２０）、選択した論理グループＬＧにおいて発生したホットマイグレーションのうち、発生日時が１日以内のすべてのホットマイグレーション（前回の第２のイベント監視処理を実行してから発生したすべてのホットマイグレーション）のホットマイグレーション情報をホットマイグレーション情報テーブルから取得する（ＳＰ２１）。

　続いてＣＰＵ２０は、ステップＳＰ２１においてホットマイグレーション情報を取得したホットマイグレーションにより他の物理サーバ２に移動された仮想マシン１４の中から１つの仮想マシン１４を選択し（ＳＰ２２）、選択した仮想マシン１４に関するホットマイグレーション情報を、ステップＳＰ２１において取得したホットマイグレーション情報の中からすべて取得する（ＳＰ２３）。

　次いで、ＣＰＵ２０は、ステップＳＰ２３において取得したホットマイグレーション情報が３個以上存在するか否かを判断する（ＳＰ２４）。

　そしてＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ２２に戻り、この後、ステップＳＰ２２において選択する仮想マシン１４を未処理の他の仮想マシン１４に順次切り替えながらステップＳＰ２２以降の処理を繰り返す。

　これに対してＣＰＵ２０は、ステップＳＰ２４の判断で肯定結果を得ると、ステップＳＰ２１において取得したすべてのホットマイグレーション情報に基づいて、発生時刻が最も早いホットマイグレーションをそのとき発生した第２のエラールールに該当するホットマイグレーションの発生原因となったホットマイグレーションとして特定し、当該ホットマイグレーションの発生時刻、イベント内容、発生元の論理グループＬＧのグループ名及びそのイベントの原因となった仮想マシン１４のホスト名をイベント一覧４４（図６）に登録する（ＳＰ２５）。

　続いて、ＣＰＵ２０は、該当するすべての仮想マシン１４（つまりステップＳＰ２１において取得したホットマイグレーション情報のいずれかに関連する仮想マシン１４）についてステップＳＰ２２～ステップＳＰ２５の処理を実行し終えたか否かを判断する（ＳＰ２６）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ２２に戻り、この後、ステップＳＰ２２において選択する仮想マシン１４を未処理の他の仮想マシン１４に順次切り替えながら、ステップＳＰ２２～ステップＳＰ２６の処理を繰り返す。

　そしてＣＰＵ２０は、やがて該当するすべての仮想マシン１４についてステップＳＰ２２～ステップＳＰ２６の処理を実行し終えることによりステップＳＰ２６において肯定結果を得ると、すべての論理グループＬＧについてステップＳＰ２１～ステップＳＰ２５の処理を実行し終えたか否かを判断する（ＳＰ２７）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ２０に戻り、この後、ステップＳＰ２０～ステップＳＰ２７の処理を繰り返す。そしてＣＰＵ２０は、やがてすべての論理グループＬＧについてステップＳＰ２１～ステップＳＰ２６の処理を実行し終えることによりステップＳＰ２７において肯定結果を得ると、この第２のイベント監視処理を終了する。

（２－２－３）論理グループ構成変更処理
　一方、図１３は、管理サーバ３のＣＰＵ２０が上述の第１及び第２のイベント監視処理により第１又は第２のエラールールに該当するホットマイグレーションを検出した場合に、その後ＣＰＵ２０により実行される論理グループ構成変更処理の具体的な処理手順を示す。ＣＰＵ２０は、この図１３に示す処理手順に従って、計算機システム１内の論理グループＬＧの構成を変更する。

　すなわちＣＰＵ２０は、この論理グループ構成変更処理を開始すると、まず過去１週間以内にエラールールに該当するホットマイグレーションが発生した論理グループＬＧ以外の論理グループＬＧに所属する物理サーバ２の中から、リソース（ＣＰＵ性能及びメモリ容量）に余剰がある物理サーバ２を検索し、検索結果に基づいて、そのような物理サーバ２の一覧である上述のリソース取得先一覧４５（図７）を作成する（ＳＰ３０）。

　続いて、ＣＰＵ２０は、リソース取得先一覧４５に登録された物理サーバ２のうち、リソース取得先一覧４５の最も上段に登録されている未処理の物理サーバ２を１つ選択し（ＳＰ３１）、選択した物理サーバ２上で稼働するよう予約されているすべての仮想マシン１４の予約情報を仮想マシン予約情報一覧４２（図４）から取得する（ＳＰ３１）。

　次いで、ＣＰＵ２０は、ステップＳＰ３２において取得した予約情報の中から１つの予約情報を選択し（ＳＰ３３）、選択した予約情報に対応する仮想マシン１４の移行先となり得る同じ論理グループＬＧ内の物理サーバ２を検索及び決定し、決定結果に基づいて移動先候補一覧４６（図８）を作成する（ＳＰ３４）。

　続いて、ＣＰＵ２０は、ステップＳＰ３４の処理により、ステップＳＰ３３において選択した予約情報に対応する仮想マシン１４の移動先となり得る物理サーバ２を決定できたか否かを判断する（ＳＰ３５）。そしてＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ３７に進む。

　これに対してＣＰＵ２０は、ステップＳＰ３５の判断で肯定結果を得ると、ステップＳＰ３２において取得したすべての予約情報について、対応する仮想マシン１４の移動先となり得る物理サーバ２を決定し終えたか否かを判断する（ＳＰ３６）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ３３に戻り、この後、ステップＳＰ３３において選択する予約情報を、ステップＳＰ３２で取得した予約情報のうちの未処理の他の予約情報に順次切り替えながら、ステップＳＰ３３～ステップＳＰ３６の処理を繰り返す。

　そしてＣＰＵ２０は、やがてステップＳＰ３１で選択した物理サーバ２上で稼働するよう予約されているすべての仮想マシン１４の移動先を決定し終えることによりステップＳＰ３６で肯定結果を得ると、ステップＳＰ３０で作成したリソース取得先一覧４５に登録されたすべての物理サーバ２についてステップＳＰ３２～ステップＳＰ３６の処理を実行し終えたか否かを判断する（ＳＰ３７）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ３１に戻り、この後、ステップＳＰ３１において選択する物理サーバ２を、リソース取得先一覧４５に登録された物理サーバ２のうち、未処理の他の物理サーバ２に順次切り替えながら、ステップＳＰ３１～ステップＳＰ３７の処理を繰り返す。

　そしてＣＰＵ２０は、やがてリソース取得先一覧４５に登録されたすべての物理サーバ２について同様の処理を実行し終えることによりステップＳＰ３７において肯定結果を得ると、リソース取得先一覧４５に登録されたすべての物理サーバ２の中に、その物理サーバ２上で稼働するよう予約されたすべての仮想マシン１４の移動先を決定できた物理サーバ２が存在するか否かを判断する（ＳＰ３８）。

　そしてＣＰＵ２０は、この判断で否定結果を得ると、論理グループＬＧの構成変更を行うことなく、この論理グループ構成変更処理を終了する。

　これに対してＣＰＵ２０は、ステップＳＰ３８の判断で肯定結果を得ると、リソース取得先一覧４５に登録された物理サーバ２であって、その物理サーバ２上で稼働するよう予約されたすべての仮想マシン１４の移動先を決定できた物理サーバ２のうち、リソース取得先一覧４５の最も上段に登録された物理サーバ（以下、これを貸出し対象物理サーバと呼ぶ）２について、その貸出し対象物理サーバ２上で稼働するよう予約された仮想マシン１４をすべて移動先候補一覧４６に登録された対応する物理サーバ２に移動させる。またＣＰＵ２０は、これと併せて、かかる貸出し対象物理サーバ２を、第１又は第２のエラールールに該当するホットマイグレーションが発生した論理グループＬＧに貸し出す（ＳＰ３９）。なお、かかる貸出し対象物理サーバ２の貸し出しは、物理サーバ構成テーブル４１（図３）におけるその貸出し物理サーバ２に対応するエントリ（行）の所属論理グループ欄４１Ｄ（図３）に格納されている論理グループ名を、貸出し先の論理グループＬＧのグループ名に更新することにより行われる。

　そしてＣＰＵ２０は、この後、かかる貸出し対象物理サーバ２の貸出し先の論理グループＬＧに対応して設けられた借用リソース管理テーブル４７（図９）に、その貸出し対象物理サーバ２のサーバ名と、その貸出し対象物理サーバ２の貸出し期間と、その貸出し対象物理サーバ２の貸出し先及び貸出し元の各論理グループＬＧのグループ名とをそれぞれ登録し（ＳＰ４０）、この後、この論理グループ構成変更処理を終了する。

（２－２－４）リソース取得先一覧作成処理
　図１４は、かかる論理グループ構成変更処理（図１３）のステップＳＰ３０におけるＣＰＵ２０の具体的な処理内容を示す。ＣＰＵ２０は、この図１４に示す処理手順に従って、過去１週間以内にエラールールに該当するホットマイグレーションが発生した論理グループＬＧ以外の論理グループＬＧに所属する物理サーバ２の中から、リソース（ＣＰＵ性能及びメモリ容量）に余剰がある物理サーバ２の一覧であるリソース取得先一覧４５（図７）を作成する。

　実際上、ＣＰＵ２０は、論理グループ構成変更処理のステップＳＰ３０に進むと、この図１４に示すリソース取得先一覧作成処理を開始し、まず、イベント一覧４４（図６）を参照して、過去１週間以内に第１又は第２のエラールールに該当するイベント（ホットマイグレーション）が発生した論理グループＬＧをすべて検出する（ＳＰ５０）。

　続いて、ＣＰＵ２０は、ステップＳＰ５０において検出した論理グループＬＧ以外の論理グループＬＧを１つ選択し（ＳＰ５１）、選択した論理グループＬＧについて、その論理グループＬＧに所属する個々の物理サーバ２について、それらの物理サーバ２を、論理グループ構成変更処理の実行契機となった仮想マシン１４（第１又は第２のエラールールに該当するホットマイグレーションが行われた仮想マシン１４）が稼働している又は稼働していた物理サーバ２が所属する論理グループＬＧに貸し出し可能な貸出し期間を計算する（ＳＰ５２）。

　続いて、ＣＰＵ２０は、ステップＳＰ５０において検出した論理グループＬＧ（過去１週間以内に第１又は第２のエラールールに該当するイベント（ホットマイグレーション）が発生した論理グループＬＧ）以外のすべての論理グループＬＧについてステップＳＰ５２の処理を実行し終えたか否かを判断する（ＳＰ５３）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ５１に戻り、この後ステップＳＰ５１において選択する論理グループＬＧを、未処理の他の論理グループＬＧに順次切り替えながらステップＳＰ５１～ステップＳＰ５３の処理を繰り返す。

　そしてＣＰＵ２０は、やがてステップＳＰ５０において検出した論理グループＬＧ以外のすべての論理グループＬＧについてステップＳＰ５１～ステップＳＰ５３の処理を実行し終えることによりステップＳＰ５３において肯定結果を得ると、ステップＳＰ５２の処理結果に基づいて、上述したリソース取得先一覧４５を作成する（ＳＰ５４）。

　またＣＰＵ２０は、この後、ステップＳＰ５４において作成したリソース取得先一覧４５に登録された物理サーバ２を、リソースの余力が少ないものから順番に並べるようにソートし（ＳＰ５５）、この後、このリソース取得先一覧作成処理を終了する。

（２－２－５）貸出し期間計算処理
　図１５Ａ及び図１５Ｂは、かかるリソース取得先一覧処理（図１４）のステップＳＰ５２におけるＣＰＵ２０の具体的な処理手順を示す。ＣＰＵ２０は、この図１５Ａ及び図１５Ｂに示す処理手順に従って、過去１週間以内に第１又は第２のエラールールに該当するホットマイグレーションが発生した論理グループＬＧ以外の論理グループＬＧに所属する各物理サーバ２について、過去１週間以内に第１又は第２のエラールールに該当するホットマイグレーションが発生した論理グループＬＧに貸出し可能な期間を計算する。

　実際上、ＣＰＵ２０は、かかるリソース取得先一覧処理（図１４）のステップＳＰ５２に進むと、この図１５Ａ及び図１５Ｂに示す貸出し期間計算処理を開始し、まず、リソース取得先一覧処理のステップＳＰ５１において選択した論理グループＬＧ（以下、これを選択論理グループＬＧと呼ぶ）に所属する各物理サーバ２のＣＰＵ性能及びメモリ容量をそれぞれ物理サーバ構成テーブル４１（図３）から取得し、その選択論理グループＬＧ全体の総リソース量を計算する（ＳＰ６０）。

　例えば図３に示すように、「論理グループＥ」という選択論理グループＬＧに「物理サーバ1」、「物理サーバ2」及び「物理サーバ3」という３つの物理サーバ２のみが所属しており、これらの物理サーバ２のリソース量（ＣＰＵ性能及びメモリ容量）が図３のような状態であるものとすると、ＣＰＵ２０は、次式

　　　　　 ……（１）
により、「論理グループＥ」全体のＣＰＵ性能（GHz×コア数の総量）Ｒ_CPU1を計算すると共に、次式

　　　　　　　　　　　　　　　……（２）
により、「論理グループＥ」全体のメモリ容量（メモリ容量の総量）Ｒ_MEMO1を計算する。

　続いて、ＣＰＵ２０は、かかる選択論理グループＬＧに所属する物理サーバ２の貸出し期間を計算するために利用する内部フラグ（以下、これを貸出し期限フラグと呼ぶ）をオフに設定する（ＳＰ６１）。またＣＰＵ２０は、この後、対応する仮想マシン予約情報一覧４２（図４）を参照して、エラー仮想マシン１４の終了日時を取得する（ＳＰ６３）。

　次いで、ＣＰＵ２０は、かかる選択論理グループＬＧに所属する物理サーバ２のうちのリソースに余力がある物理サーバ２の一覧であるリソース取得先一覧４５（図７）を作成する（ＳＰ６３）。なお、この時点では、リソース取得先一覧４５の各エントリ（行）の貸出し期限欄４５Ｄに貸出し期限は格納されていない。

　この後、ＣＰＵ２０は、ステップＳＰ６３において作成したリソース取得先一覧４５に登録されている物理サーバ２を１つ選択し（ＳＰ６４）、選択した物理サーバ２について、ステップＳＰ６５～ステップＳＰ７１までの処理を、現在の日時からステップＳＰ６２において取得したエラー仮想マシン１４の終了日時まで１日単位で順次実行する。

　すなわち、ＣＰＵ２０は、まず、ステップＳＰ６５～ステップＳＰ７０で実行する計算の対象となる日にち（以下、これを第１の計算対象日と呼ぶ）を決定する（ＳＰ６５）。そしてＣＰＵ２０は、仮想マシン予約情報一覧４２（図４）を参照して、かかる選択論理グループＬＧに所属する物理サーバ２上で稼働する各仮想マシン１４に対してその第１の計算対象日に割り当てるべきリソース量の合計値（その選択論理グループＬＧのその第１の計算対象日における最大のリソースの使用量であり、以下、これを第１の計算対象日の最大使用リソース量と呼ぶ）を計算する（ＳＰ６６）。なお、この最大使用リソース量は、ＣＰＵ性能及びメモリ容量のそれぞれについて計算される。

　続いて、ＣＰＵ２０は、ステップＳＰ６０において算出した選択論理グループＬＧの総リソース量から、ステップＳＰ６６において算出したその選択論理グループＬＧのその第１の計算対象日の最大使用リソース量を減算することにより、その選択論理グループＬＧのその第１の計算対象日におけるリソースの余剰量（余剰ＣＰＵ性能及び余剰メモリ容量）を算出する（ＳＰ６７）。

　例えば、選択論理グループＬＧに関連する仮想マシン予約情報一覧４２が図４のような状態にあるものとし、第１の計算対象日が「2011/02/04」であるものとすると、選択論理グループＬＧのその第１の計算対象日における最大使用リソース量は、ＣＰＵ性能Ｒ_CPU2については、次式

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　……（３）
により計算され、メモリ容量Ｒ_MEMO2については、次式

　　　　　　　　　　　　　……（４）
により計算される。

　よって、「2011/02/04」における余剰ＣＰＵ性能は、次式

　　　　　　　　　　　　　　　……（５）
のように算出することができ、余剰メモリ容量は、次式

　　　　　　　　　……（６）
のように算出することができる。

　次いで、ＣＰＵ２０は、ステップＳＰ６７において算出した余剰リソース量（余剰ＣＰＵ性能及び余剰メモリ容量）が、ステップＳＰ６４において選択した物理サーバ２のリソース量（ＣＰＵ性能及びメモリ容量の双方）以下であるか否かを判断する（ＳＰ６８）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ６５に戻り、この後、ステップＳＰ６５において決定する第１の計算対象日をその翌日に切り換えた後、ステップＳＰ６６以降の処理を実行する。

　これに対してＣＰＵ２０は、ステップＳＰ６８の判断で肯定結果を得ると、貸出し期限フラグをオンに設定する（ＳＰ６９）。またＣＰＵ２０は、ステップＳＰ６３において作成したリソース取得先一覧４５（図７）におけるそのとき対象としている物理サーバ２に対応する貸出し期限欄４５Ｄ（図７）にそのときの第１の計算対象日の前日を格納した後（ＳＰ７０）、現在の第１の計算対象日がステップＳＰ６２において取得したエラー仮想マシン１４の終了日時を超えたか否かを判断する（ＳＰ７１）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ６５に戻り、この後、ステップＳＰ６５において決定する第１の計算対象日をその翌日に切り換えた後、ステップＳＰ６５以降の処理を実行する。

　そしてＣＰＵ２０は、そのとき対象としている物理サーバ２について、ステップＳＰ６５～ステップＳＰ７０の処理を現在の日時からステップＳＰ６２において取得した終了日時まで終了することによりステップＳＰ７１において肯定結果を得ると、貸出し期限フラグがオフに設定されているか否かを判断する（ＳＰ７２）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ７４に進み、これに対して肯定結果を得ると、ステップＳＰ６３において作成したリソース取得先一覧４５におけるそのとき対象としている物理サーバ２に対応する貸出し期限欄４５Ｄに、ステップＳＰ６３において取得したエラー仮想マシン１４の終了日時の前日を設定する（ＳＰ７３）。なお、このようにかかる終了日時の前日を設定するのは、その物理サーバ２の返却処理を行うためのバッファとして、１日分の余裕をもたせるためである。

　続いて、ＣＰＵ２０は、ステップＳＰ６４～ステップＳＰ７３の処理をステップＳＰ６３において作成したリソース取得先一覧４５に登録されたすべての物理サーバ２について実行し終えたか否かを判断する（ＳＰ７４）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ６４に戻り、この後、ステップＳＰ６４において選択する物理サーバ２をリソース取得先一覧４５に登録された未処理の他の物理サーバ２に順次切り替えながら、同様の処理を繰り返す。

　そしてＣＰＵ２０は、やがてリソース取得先一覧４５に登録されたすべての物理サーバ２についてステップＳＰ６４～ステップＳＰ７３の処理を実行し終えることによりステップＳＰ７４において肯定結果を得ると、この貸出し期間計算処理を終了する。

（２－２－６）リソース取得先一覧作成処理
　図１６は、上述の貸出し期間計算処理（図１５Ａ及び図１５Ｂ）のステップＳＰ６３におけるＣＰＵ２０の具体的な処理内容を示す。ＣＰＵ２０は、この図１６に示す処理手順に従ってリソース取得先一覧４５を作成する。

　実際上、ＣＰＵ２０は、かかる貸出し期間計算処理のステップＳＰ６３に進むと、このリソース取得先一覧作成処理を開始し、まず、仮想マシン予約情報一覧４２（図４）を参照して、エラー仮想マシン１４のＣＰＵ性能及びメモリ容量を取得する（ＳＰ８０）。

　続いて、ＣＰＵ２０は、このとき対象としている論理グループ（選択論理グループ）ＬＧに所属する物理サーバ２を１つ選択する（ＳＰ８１）。

　次いで、ＣＰＵ２０は、リソース取得先一覧４５上の１つの未使用のエントリ（行）を確保し、そのエントリの物理サーバ欄４５Ａ（図７）及び貸出し元欄４５Ｅ（図７）に、ステップＳＰ８１において選択した物理サーバ２のサーバ名及びその物理サーバ２が所属する論理グループ（選択論理グループ）ＬＧのグループ名をそれぞれ格納する（ＳＰ８２）。またＣＰＵ２０は、上述の処理と併せて、そのエントリの貸出し期限欄４５Ｄ（図７）に初期値を格納する（ＳＰ８２）。

　続いて、ＣＰＵ２０は、ステップＳＰ８１において選択した物理サーバ２のＣＰＵ性能を物理サーバ構成テーブル４１（図３）から取得し、取得したその物理サーバ２のＣＰＵ性能からステップＳＰ８０において取得したエラー仮想マシン１４のＣＰＵ性能を減算し、減算結果を余剰ＣＰＵ性能として、リソース取得先一覧４５のステップＳＰ８２において確保したエントリの余剰ＣＰＵ性能欄４５Ｂ（図７）に格納する（ＳＰ８３）。

　またＣＰＵ２０は、ステップＳＰ８１において選択した物理サーバ２のメモリ容量を物理サーバ構成テーブル４１から取得し、取得したその物理サーバ２のメモリ容量からステップＳＰ８０において取得したエラー仮想マシン１４のメモリ容量を減算し、減算結果を余剰メモリ容量として、リソース取得先一覧４５のステップＳＰ８２において確保したエントリの余剰メモリ容量欄４５Ｃ（図７）に格納する（ＳＰ８４）。

　次いで、ＣＰＵ２０は、そのとき対象としている論理グループ（選択論理グループ）ＬＧに所属するすべての物理サーバ２についてステップＳＰ８１～ステップＳＰ８４の処理を実行し終えたか否かを判断する（ＳＰ８５）。

　そしてＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ８１に戻り、この後、ステップＳＰ８１において選択する物理サーバ２を未処理の他の物理サーバ２に順次切り替えながら、同様の処理を繰り返す。

　そしてＣＰＵ２０は、やがてそのとき対象としている論理グループＬＧに所属するすべての物理サーバ２についてステップＳＰ８１～ステップＳＰ８４の処理を実行し終えることによりステップＳＰ８５において肯定結果を得ると、このとき作成したリソース取得先一覧４５のエントリを余剰ＣＰＵ性能又は余剰メモリ容量の値に基づいてソートするリソース取得先一覧ソート処理を実行し（ＳＰ８６）、この後、このリソース取得先一覧作成処理を終了する。

　なお、かかるリソース取得先一覧作成処理のステップＳＰ８６においてＣＰＵ２０により実行されるリソース取得先一覧ソート処理の具体的な処理手順を図１７に示す。

　ＣＰＵ２０は、リソース取得先一覧作成処理のステップＳＰ８６に進むと、このリソース取得先一覧ソート処理を開始し、まず、予めシステム管理者により設定されている余力優先フラグを確認する（ＳＰ９０）。この余力優先フラグは、リソース取得先一覧４５の各エントリをソートする際に、余剰ＣＰＵ性能及び余剰メモリ容量のいずれを優先的に考慮してこれらのエントリをソートするかを規定するフラグである。

　そしてＣＰＵ２０は、ステップＳＰ９０の確認結果に従って、リソース取得先一覧のエントリの並べ替え（ソート）を実行する（ＳＰ９１）。具体的に、ＣＰＵ２０は、例えば余剰ＣＰＵ性能を優先的に考慮すべき状態に余力優先フラグが設定されている場合には、余剰ＣＰＵ性能欄４５Ｂに格納された余剰ＣＰＵ性能が小さいエントリから順番に並べるようにリソース取得先一覧４５の各エントリをソートする。またＣＰＵ２０は、余剰メモリ容量を優先的に考慮すべき状態に余力優先フラグが設定されている場合には、余剰メモリ容量欄４５Ｃに格納された余剰メモリ容量が小さいエントリから順番に並べるようにリソース取得先一覧４５の各エントリをソートする。

　続いて、ＣＰＵ２０は、ステップＳＰ９１のソートを完了したリソース取得先一覧４５について、余力優先フラグにより優先的に考慮すべきリソース量として指定されたリソース量（余剰ＣＰＵ性能又は余剰メモリ容量）が同じ値のエントリが存在するか否かを判断する（ＳＰ９２）。

　そしてＣＰＵ２０は、この判断で否定結果を得ると、このリソース取得先一覧ソート処理を終了する。これに対してＣＰＵ２０は、ステップＳＰ９２の判断で肯定結果を得ると、余力優先フラグにより優先的に考慮すべきリソース量として指定されたリソース量が同じ値のエントリを、当該リース量と異なる方のリソース量（余力優先フラグにより優先的に考慮すべきリソース量として指定されていない方のリソース量）が少ない順に並べ替え（ＳＰ９３）、この後、このリソース取得先一覧ソート処理を終了する。

（２－２－７）移動先物理サーバ決定処理
　他方、図１８は、図１３について上述した論理グループ構成変更処理のステップＳＰ３４においてＣＰＵ２０により実行される移動先物理サーバ決定処理の具体的な処理手順を示す。ＣＰＵ２０は、この図１８に示す処理手順に従って、論理グループ構成変更処理のステップＳＰ３３において選択した仮想マシン１４の移動先候補とする物理サーバ２を決定する。

　すなわちＣＰＵ２０は、この移動先物理サーバ決定処理を開始すると、まず、論理グループ構成変更処理のステップＳＰ３１で選択したそのとき対象としている物理サーバ２と同一の論理グループＬＧに所属するすべての物理サーバ２に関する情報を物理サーバ構成テーブル４１から抽出して物理サーバ一覧４８（図１０）を作成する（ＳＰ１００）。

　続いて、ＣＰＵ２０は、ステップＳＰ１００において作成した物理サーバ一覧４８に登録されている各物理サーバの中から論理グループ構成変更処理のステップＳＰ３１で選択した物理サーバ２以外の物理サーバ２を１つ選択する（ＳＰ１０１）。

　この後、ＣＰＵ２０は、ステップＳＰ１０１で選択した物理サーバ２について、ステップＳＰ１０２～ステップＳＰ１０８までの処理を、現在の日時からエラー仮想マシン１４の終了日時まで１日単位で順次実行する。

　すなわち、ＣＰＵ２０は、まず、ステップＳＰ１０３～ステップＳＰ１０７で実行する計算の対象となる日にち（以下、これを第２の計算対象日と呼ぶ）を決定する（ＳＰ１０２）。そしてＣＰＵ２０は、仮想マシン予約情報一覧４２（図４）を参照して、ステップＳＰ１０１で選択した物理サーバ２上で稼働する各仮想マシン１４に対してその第２の計算対象日に割り当てるべきリソース量の合計値（その物理サーバ２のその第２の計算対象日における最大のリソースの使用量であり、以下、これを第２の計算対象日の最大使用リソース量と呼ぶ）を計算する（ＳＰ１０３）。なお、この最大使用リソース量は、ＣＰＵ性能及びメモリ容量のそれぞれについて計算される。

　続いて、ＣＰＵ２０は、ステップＳＰ１０１において選択した物理サーバ２のＣＰＵ性能及びメモリ容量を物理サーバ構成テーブル４１から取得し、取得したＣＰＵ性能及びメモリ容量からそれぞれステップＳＰ１０３において算出した第２の計算対象日のＣＰＵ性能又はメモリ容量を減算することにより、ステップＳＰ１０１において選択した物理サーバ２の第２の計算対象日におけるＣＰＵ性能及びメモリ容量の余力（余力リソース量）をそれぞれ算出する（ＳＰ１０４）。以下においては、このように計算されたＣＰＵ性能の余力を余力ＣＰＵ性能と呼び、メモリ容量の余力を余力メモリ容量と呼ぶものとする。

　次いで、ＣＰＵ２０は、現在対象としているステップＳＰ１０１において選択した物理サーバ２が候補先一覧４６（図８）の移動先候補として設定されている仮想マシン１４が存在するか否かを判断する（ＳＰ１０５）。そしてＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１０７に進む。

　これに対してＣＰＵ２０は、ステップＳＰ１０５の判断で肯定結果を得ると、ステップＳＰ１０６において算出した余力ＣＰＵ性能からその仮想マシン１４（現在対象としているステップＳＰ１０１において選択した物理サーバ２が候補先一覧４６の移動先候補として設定されている仮想マシン１４）のＣＰＵ性能を減算した新しい余力ＣＰＵ性能と、ステップＳＰ１０６において算出した余力メモリ容量からその仮想マシン１４のメモリ容量を減算した新しい余力メモリ容量とをそれぞれ算出する（ＳＰ１０６）。

　この後、ＣＰＵ２０は、ステップＳＰ１０４において算出した余力ＣＰＵ性能及び余力メモリ容量、又は、ステップＳＰ１０６において算出した新しい余力ＣＰＵ性能及び余力メモリ容量に基づいて、そのとき対象としているステップＳＰ１０１において選択した物理サーバ２が、そのとき対象としている論理グループ構成変更処理のステップＳＰ３３において選択した仮想マシン１４を稼働できるだけのリソースの余力があるか否かを判断する（ＳＰ１０７）。

　具体的に、この判断は、ステップＳＰ１０４又はステップＳＰ１０６において算出した余力ＣＰＵ性能及び余力メモリ容量と、仮想マシン予約情報一覧４２（図４）から取得できる、そのとき対象としている論理グループ構成変更処理のステップＳＰ３３において選択した仮想マシン１４に割り当てるべきＣＰＵ性能及びメモリ容量とをそれぞれ比較することにより行われる。そしてかかる仮想マシン１４のＣＰＵ性能よりも余力ＣＰＵ性能の方が大きく、かつ仮想マシン１４のメモリ容量よりも余力メモリ容量の方が大きいときに「リソースの余力がある」との判断が得られ（ステップＳＰ１０７で肯定結果が得られ）、これ以外のときに「リソースの余力がない」との判断が得られる（ステップＳＰ１０７で否定結果が得られ）ことになる。

　ここで、ステップＳＰ１０７の判断で否定結果を得ることは、そのとき対象としている物理サーバ２が、そのときの第２の計算対象日時において、そのとき対象としている論理グループ構成変更処理のステップＳＰ３３において選択した仮想マシン１４の移動先とすることができないことを意味する。かくして、このときＣＰＵ２０は、ステップＳＰ１０１に戻って、対象とする物理サーバ２をステップＳＰ１００で作成した物理サーバ一覧４８に登録されている他の物理サーバ２に切り換え、この後ステップＳＰ１０２～ステップＳＰ１０７を同様に処理する。

　一方、ステップＳＰ１０７の判断で肯定結果を得ることは、そのとき対象としている物理サーバ２が、そのときの第２の計算対象日時において、そのとき対象としている論理グループ構成変更処理のステップＳＰ３３において選択した仮想マシン１４の移動先とすることができることを意味する。かくして、このときＣＰＵ２０は、仮想マシン予約情報一覧４２を参照して、現在の第２の計算対象日が、そのとき対象としている論理グループ構成変更処理のステップＳＰ３３において選択した仮想マシン１４の終了日時を超えたか否かを判断する（ＳＰ１０８）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１０２に戻り、この後、ステップＳＰ１０８で肯定結果を得るまで同様の処理を繰り返す。そしてＣＰＵ２０は、やがてステップＳＰ１０８の判断で肯定結果を得ると、ステップＳＰ１００において情報を収集したすべての物理サーバ２について同様の処理を実行し終えたか否かを判断する（ＳＰ１０９）。

　またＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１０１に戻り、この後、ステップＳＰ１０１において選択する物理サーバ２を、ステップＳＰ１００で作成した物理サーバ一覧４８に登録されているすべての物理サーバ２のうちの未処理の他の物理サーバ２に順次切り換えながら、ステップＳＰ１０１～ステップＳＰ１０９の処理を繰り返す。

　そしてＣＰＵ２０は、やがてかかる物理サーバ一覧４８に登録されているすべての物理サーバ２についてステップＳＰ１０２～ステップＳＰ１０８の処理を実行し終えることによりステップＳＰ１０９で肯定結果を得ると、ステップＳＰ１００で情報を取得した物理サーバ２の中に、現在からかかる仮想マシン１４の終了日時までの全期間で仮想マシン１４を稼働できるリソース余力がある物理サーバ２（ステップＳＰ１０７の判断で肯定結果が得られた物理サーバ２）が存在するか否かを判断する（ＳＰ１１０）。

　ＣＰＵ２０は、この判断で肯定結果を得ると、その物理サーバ２を、そのとき対象としている論理グループ構成変更処理のステップＳＰ３３において選択した仮想マシン１４の移動先候補として移動先候補一覧４６（図８）に登録する（ＳＰ１１１）。この際、ＣＰＵ２０は、例えばステップＳＰ１１０の判断で肯定結果が得られた物理サーバが複数存在する場合には、ステップＳＰ１００で作成した物理サーバ一覧４８に登録されている物理サーバ２のうち、リソース余力が最も小さい物理サーバ２を、かかる仮想マシン１４の移動先候補として移動先候補一覧４６に登録する。これは、かかる仮想マシン１４をこのような物理サーバ２に移動した方が最も影響が小さいからである。そしてＣＰＵ２０は、この後、この移動先物理サーバ決定処理を終了する。

（２－２－８）物理サーバ貸出し処理
　図１９は、論理グループ構成変更処理のステップＳＰ３９においてＣＰＵ２０により実行される物理サーバ貸出し処理の具体的な処理手順を示す。ＣＰＵ２０は、この図１９に示す処理手順に従って、貸出し対象の物理サーバ（以下、これを貸出し対象物理サーバと呼ぶ）２を他の論理グループＬＧに貸し出す。

　すなわち、ＣＰＵ２０は、論理グループ構成変更処理のステップＳＰ３９に進むとこの物理サーバ貸出し処理を開始し、まず、仮想マシン予約情報一覧４２を参照して、貸出し対象物理サーバ２上で稼働し又は稼働が予定されている仮想マシン１４を１つ選択する（ＳＰ１２０）。

　続いて、ＣＰＵ２０は、貸出し対象物理サーバ２を制御することにより、ステップＳＰ１２０において選択した仮想マシン１４を、移動先候補一覧４６（図８）に登録されている対応する物理サーバ２にホットマイグレーションさせる（ＳＰ１２１）。

　次いで、ＣＰＵ２０は、貸出し対象物理サーバ２上で稼働し又は稼働が予定されているすべての仮想マシン１４を移動先候補一覧４６において指定されている対応する物理サーバ２にホットマイグレーションし終えたか否かを判断する（ＳＰ１２２）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１２０に戻り、この後、ステップＳＰ１２０において選択する仮想マシン１４を未処理の他の仮想マシン１４に順次切り替えながら、ステップＳＰ１２０～ステップＳＰ１２２の処理を繰り返す。

　そしてＣＰＵ２０は、やがて貸出し対象物理サーバ２上で稼働し又は稼働予定のすべての仮想マシン１４についてステップＳＰ１２１の処理を実行し終えることによりステップＳＰ１２２において肯定結果を得ると、物理サーバ構成テーブル４１（図３）における貸出し対象物理サーバ２に対応するエントリの所属論理グループ欄４１Ｄ（図３）に格納されている論理グループ名を、このとき貸出し対象物理サーバ２の貸出し先となる論理グループＬＧのグループ名に更新した後（ＳＰ１２３）、この物理サーバ貸出し処理を終了する。

　なお、かかる物理サーバ貸出し処理のステップＳＰ１２２においてＣＰＵ２０により実行されるホットマイグレーション処理の具体的な処理内容を図２０に示す。

　ＣＰＵ２０は、かかる物理サーバ貸出し処理のステップＳＰ１２２に進むと、このホットマイグレーション処理を開始し、まず、ホットマイグレーションさせたい仮想マシン１４が稼働している物理サーバ２（つまり貸出し対象物理サーバ２）に対して、移動対象の仮想マシン１４及びその仮想マシン１４の移動先を指定したホットマイグレーション実行命令を送信する（ＳＰ１３０）。かくして貸出し対象物理サーバ２は、このホットマイグレーション実行命令に従って、当該ホットマイグレーション実行命令において指定された移動先の物理サーバ２に、当該ホットマイグレーション実行命令において指定された仮想マシン１４をホットマイグレーションさせる。

　続いて、ＣＰＵ２０は、仮想マシン予約情報一覧４２（図４）におけるかかる仮想マシン１４に対応するエントリの割当て先欄４２Ｄ（図４）に格納されている物理サーバ２のサーバ名を、かかるホットマイグレーション実行命令において当該仮想マシン１４の移動先として指定した物理サーバ２のサーバ名に更新し（ＳＰ１３１）、この後、このホットマイグレーション処理を終了する。

（２－２－９）借用リソース返却処理
　図２１Ａ及び図２１Ｂは、管理サーバ３のＣＰＵ２０により定期的に実行される借用リソース返却処理の処理手順を示す。ＣＰＵ２０は、この処理手順に従って、借用リソース管理テーブル４７（図９）に登録されている物理サーバ２を借用元（貸出し元）の論理グループＬＧに返却する。

　実際上、ＣＰＵ２０は、この借用リソース返却処理を開始すると、借用リソース管理テーブル４７に登録されている物理サーバ２の中から未処理の１つの物理サーバ２を選択し（ＳＰ１４０）、この後、借用リソース管理テーブル４７を参照して、その物理サーバ２の貸出し期限の残り日数が１日以下となっているか否かを判断する（ＳＰ１４１）。

　ＣＰＵ２０は、この判断で否定結果を得ると、借用リソース管理テーブル４７に登録されているすべての物理サーバ２に対するステップＳＰ１４１の判断を実行し終えたか否かを判断する（ＳＰ１５７）。そしてＣＰＵ２０は、この判断で肯定結果を得ると、この借用リソース返却処理を終了する。

　これに対してＣＰＵ２０は、ステップＳＰ１５７の判断で否定結果を得るとステップＳＰ１４０に戻り、この後、ステップＳＰ１４１において選択する物理サーバ２を未処理の他の物理サーバ２に順次切り換えながら、同様の判断を繰り返す。

　一方、ＣＰＵ２０は、ステップＳＰ１４１の判断で肯定結果を得ると、そのとき対象としている物理サーバ２（ステップＳＰで選択した物理サーバ２）上で稼働し又は稼働予定のすべての仮想マシン１４に関する情報（終了日時を含む）を仮想マシン予約情報一覧４２から取得する（ＳＰ１４２）。

　続いて、ＣＰＵ２０は、物理サーバ構成テーブル４１を参照して、ステップＳＰ１４０において選択した物理サーバ２が貸し出されている論理グループＬＧ（当該物理サーバ２が現在所属する論理グループＬＧ）に所属する、ステップＳＰ１４０において選択した物理サーバ２以外の物理サーバ２がすべて登録された物理サーバ一覧４８（図１０）を作成する（ＳＰ１４３）。

　次いで、ＣＰＵ２０は、ステップＳＰ１４３において作成した物理サーバ一覧４８に登録されている物理サーバ２を１つ選択すると共に（ＳＰ１４４）、ステップＳＰ１４０において選択した物理サーバ２上で稼働し又は稼働予定の仮想マシン１４を１つ選択する（ＳＰ１４５）。

　この後、ＣＰＵ２０は、ステップＳＰ１４４で選択した物理サーバ及びステップＳＰ１４５で選択した仮想マシン１４について、ステップＳＰ１４６～ステップＳＰ１４９までの処理を、現在の日時からその仮想マシン１４の終了日時まで１日単位で順次実行する。

　すなわち、ＣＰＵ２０は、まず、ステップＳＰ１４６～ステップＳＰ１４９で実行する計算の対象となる日にち（以下、これを第３の計算対象日と呼ぶ）を決定する（ＳＰ１４６）。そしてＣＰＵ２０は、仮想マシン予約情報一覧４２（図４）を参照して、ステップＳＰ１４４で選択した物理サーバ２上で稼働する各仮想マシン１４に対してその第３の計算対象日に割り当てるべきＣＰＵ性能及びメモリ容量の合計値（以下、これを第３の計算対象日の最大使用リソース量と呼ぶ）を計算する（ＳＰ１４７）。なお、この最大使用リソース量は、ＣＰＵ性能については各仮想マシンのＣＰＵ性能の合計値として算出され、メモリ容量については、仮想マシン１４のメモリ容量の合計値として算出される。

　続いて、ＣＰＵ２０は、ステップＳＰ１４４で選択した物理サーバ２のＣＰＵ性能及びメモリ容量を物理サーバ構成テーブル４１（図３）から取得し、取得したＣＰＵ性能及びメモリ容量からそれぞれステップＳＰ１４７において算出した第３の計算対象日のＣＰＵ性能又はメモリ容量を減算することにより、ステップＳＰ１４４において選択した物理サーバ２の第３の計算対象日における余力ＣＰＵ性能及び余力メモリ容量をそれぞれ算出する（ＳＰ１４８）。

　次いで、ＣＰＵ２０は、仮想マシン予約情報一覧４２（図４）を参照して、現在の第３の計算対象日が、そのとき対象としているステップＳＰ１４５において選択した仮想マシン１４の終了日時を超えたか否かを判断する（ＳＰ１４９）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１４６に戻り、この後、ステップＳＰ１４９で肯定結果を得るまで同様の処理を繰り返す。そしてＣＰＵ２０は、やがてステップＳＰ１４９で肯定結果を得ると、ステップＳＰ１４５において選択した仮想マシン１４をステップＳＰで選択した物理サーバ２に移動できるか否かを判断する（ＳＰ１５０）。

　具体的に、ＣＰＵ２０は、このステップＳＰ１５０において、現在からステップＳＰ１４５において選択した仮想マシン１４の終了日時まで１日単位で行ったステップＳＰ１４６～ステップＳＰ１４９の処理において、現在から当該終了日時までの全期間について、ステップＳＰ１４８で計算した余力ＣＰＵ性能及び余力メモリ容量が０以上である場合には、かかる「仮想マシン１４を移動できる」と判断し、これ以外の場合にかかる「仮想マシン１４を移動できない」と判断することになる。

　そしてＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１５２に進む。これに対してＣＰＵ２０は、ステップＳＰ１５０の判断で肯定結果を得ると、ステップＳＰ１４０で選択した物理サーバ２を制御することにより、そのとき対象としているステップＳＰ１４５で選択した仮想マシン１４をステップＳＰ１４４で選択した物理サーバ２にホットマイグレーションさせる（ＳＰ１５１）。

　なお、このように仮想マシン１４を移動可能な物理サーバ２を最初に検出した段階でその仮想マシン１４をその物理サーバ２に移動させるようにした場合、物理サーバ２間におけるリソースの負荷バランスが一時的に崩れるおそれがあるが、計算機システム１に適用されたＤＲＳ機能により、ほどなくして物理サーバ２間の負荷バランスが平準化されるため問題はない。

　続いて、ＣＰＵ２０は、ステップＳＰ１４０で選択した物理サーバ２上で稼働し又は稼働予定のすべての仮想マシン１４について同様の処理を実行し終えたか否かを判断する（ＳＰ１５２）。そしてＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１４５に戻り、この後、ステップＳＰ１４５において選択する仮想マシン１４を未処理の他の仮想マシン１４に切り替えながらステップＳＰ１４５～ステップＳＰ１５２の処理を繰り返す。

　そしてＣＰＵ２０は、やがてステップＳＰ１４０で選択した物理サーバ２上で稼働し又は稼働予定のすべての仮想マシン１４についてステップＳＰ１４６～ステップＳＰ１５１の処理を実行し終えることによりステップＳＰ１５２で肯定結果を得ると、ステップＳＰ１４３で作成した物理サーバ一覧４８（図１０）に登録されているすべての物理サーバ２について同様の処理を実行し終えたか否かを判断する（ＳＰ１５３）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１４０に戻り、この後、ステップＳＰ１４４において選択する物理サーバ２を未処理の他の物理サーバ２に順次切り替えながら、ステップＳＰ１４４～ステップＳＰ１５３の処理を繰り返す。

　そしてＣＰＵ２０は、やがてステップＳＰ１４３において作成した物理サーバ一覧４８に登録されているすべての物理サーバ２についてステップＳＰ１４５～ステップＳＰ１５２の処理を実行し終えることによりステップＳＰ１５３で肯定結果を得ると、ステップＳＰ１４０で選択した物理サーバ２上で稼働し又は稼働予定の仮想マシン１４の中で当該物理サーバ２から他の物理サーバ２に移動できなかった仮想マシン１４が存在するか否かを判断する（ＳＰ１５４）。

　そしてＣＰＵ２０は、この判断で否定結果を得るとこの借用リソース返却処理を終了する。これに対してＣＰＵ２０は、ステップＳＰ１５４の判断で肯定結果を得ると、移動できなかった仮想マシン１４を停止状態にするようステップＳＰ１４０で選択した物理サーバ２を制御すると共に、その旨を表示するなどしてシステム管理者に通知する（ＳＰ１５５）。

　続いて、ＣＰＵ２０は、そのとき対象としているステップＳＰ１４０において選択した物理サーバ２を貸出し元の論理グループＬＧに返却する（ＳＰ１５６）。具体的に、ＣＰＵ２０は、このステップＳＰ１５６において、借用リソース管理テーブル４７（図９）上からその物理サーバ２に関するエントリを削除すると共に、物理サーバ構成テーブル４１（図３）におけるその物理サーバ２に対応するエントリの所属論理グループ欄４１Ｄ（図３）に格納されている論理グループ名を、返却先（貸出し元）の論理グループＬＧのグループ名に更新する。

　なお、以上のように、返却対象の物理サーバ２から同一論理グループＬＧ内の他の物理サーバ２に移動できなかった仮想マシン１４を停止状態にしてまでもかかる物理サーバ２を貸出し元に返却するのは、図１３について上述した論理グループ構成変更処理が論理グループ構成の一時的な変更を目的とするものであり、貸出し期限以降については、その物理サーバ２のリソース量を考慮して仮想マシン１４の予約がなされている可能性があるためである。よって、本実施の形態においては、かかる物理サーバ２を貸出し元の論理グループＬＧに返却することを優先する。

　次いで、ＣＰＵ２０は、以上の処理を借用リソース管理テーブル４７に登録されたすべての物理サーバ２について実行し終えたか否かを判断する（ＳＰ１５７）。そしてＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１４０に戻り、この後、ステップＳＰ１４０において選択する物理サーバ２を未処理の他の物理サーバ２に順次切り替えながらステップＳＰ１４０～ステップＳＰ１５７の処理を繰り返す。

　そしてＣＰＵ２０は、借用リソース管理テーブル４７に登録されたすべての物理サーバ２について同様の処理を実行し終えることによりステップＳＰ１５７で肯定結果を得ると、この借用リソース返却処理を終了する。

（２－２－１０）貸出し期限通知処理
　図２２は、管理サーバ３のＣＰＵ２０により定期的に実行される貸出し期限通知処理の処理手順を示す。ＣＰＵ２０は、この図２２に示す処理手順に従って、貸出し期限までの残り日数が所定日数（以下においては１週間以内とする）となった物理サーバ２の貸出し期限等をシステム管理者に通知する。

　実際上、ＣＰＵ２０は、この貸出し期限通知処理を開始すると、まず、借用リソース管理テーブル４７（図９）を参照して、当該借用リソース管理テーブル４７に登録されている物理サーバ２を１つ選択し（ＳＰ１６０）、その物理サーバ２の貸出し期限が現在日時から１週間以内であるか否かを判断する（ＳＰ１６１）。

　ＣＰＵ２０は、この判断で否定結果を得るとステップＳＰ１６３に進み、これに対して肯定結果を得ると、そのとき対象としている物理サーバ２のサーバ名及び貸出し期限をシステム管理者に通知する（ＳＰ１６２）。

　続いて、ＣＰＵ２０は、借用リソース管理テーブル４７に登録されているすべての物理サーバ２についてステップＳＰ１６１以降の処理を実行し終えたか否かを判断し（ＳＰ１６３）、否定結果を得るとステップＳＰ１６０に戻って、この後、ステップＳＰ１６１において選択する物理サーバ２を未処理の他の物理サーバ２に順次切り換えながらステップＳＰ１６１～ステップＳＰ１６３の処理を繰り返す。

　そしてＣＰＵ２０は、やがて借用リソース管理テーブル４７に登録されたすべての物理サーバ２についてステップＳＰ１６１～ステップＳＰ１６３の処理を実行し終えることによりステップＳＰ１６３で肯定結果を得ると、この貸出し期限通知処理を終了する。

（２－２－１１）貸出し解除処理
　図２３は、所定操作により管理サーバ３のＣＰＵ２０により実行される貸出し解除処理の処理手順を示す。ＣＰＵ２０は、この図２３に示す処理手順に従って、システム管理者により指定された他の論理グループＬＧに貸出し中の物理サーバ２について、その貸出し状態を解除して、その物理サーバ２の所属を貸出し先の論理グループＬＧに移動させる。

　実際上、ＣＰＵ２０は、管理サーバ３が操作されて貸出し解除画面の表示命令が入力されると、借用リソース管理テーブル４７の内容が表示された所定の貸出し解除設定画面（図示せず）を表示する（ＳＰ１７０）。

　この後、ＣＰＵ２０は、かかる貸出し解除設定画面を閉じる入力操作が行われ、又は、貸出し解除設定画面上で貸出し状態を解除すべき物理サーバ２が指定され、その物理サーバ２の貸出し状態を解除すべき命令（以下、これを貸出し状態解除命令と呼ぶ）の入力操作が行われるのを待ち受ける（ＳＰ１７１、ＳＰ１７２）。

　そしてＣＰＵ２０は、やがてかかる貸出し状態解除命令の入力操作が行われると、当該貸出し状態解除命令において指定された物理サーバ２の貸出し状態を解除する（Ｓ１７３Ｐ）。具体的に、ＣＰＵ２０は、このステップＳＰ１７３において、借用リソース管理テーブル４７からその物理サーバ２に対応するエントリを削除し、物理サーバ構成テーブル４１におけるその物理サーバ２に対応するエントリの所属論理グループ欄４１Ｄ（図３）に格納されているグループ名を、それまでの貸出し先であった論理グループＬＧのグループ名に更新する。

　この後、ＣＰＵ２０は、ステップＳＰ１７１に戻り、同様の処理を繰り返す。そしてＣＰＵ２０は、やがて貸出し解除設定画面上で、当該貸出し解除設定画面を閉じる入力操作が行われると、この貸出し解除処理を終了する。

　なお、この機能は、リソース不足となっていた論理グループＬＧに新規にリソースを追加した場合や、貸出し元の論理グループＬＧに十分なリソースがあるため貸し出したリソースを返却してもらう必要がない場合などに有効である。

（３）本実施の形態の効果
　以上のように本実施の形態による計算機システム１では、第１又は第２のエラールールに該当するホットマイグレーションが発生した場合に、当該ホットマイグレーションが発生した論理グループＬＧに対して他の論理グループＬＧから余剰分の物理サーバ２が貸し出されるため、第１又は第２のエラールールに該当するホットマイグレーションが発生した論理グループＬＧにおけるリソース不足を解消することができる。よって、かかるホットマイグレーションが発生した論理グループＬＧにおけるリソース不足に起因するホットマイグレーションの発生を抑制することができる。

　また本計算機システム１では、上述のように第１又は第２のエラールールに該当するホットマイグレーションが発生した論理グループＬＧに対して他の論理グループＬＧから余剰分の物理サーバ２を貸し出すため、論理グループＬＧ間の負荷バランスを平準化することができる。

　従って、本計算機システム１によれば、システム内におけるホットマイグレーションの発生を効果的に低減させることができ、かくしてシステム全体の安定化を図ることができる。

（４）他の実施の形態
　なお上述の実施の形態においては、エラールールとして、ある仮想マシン１４がホットマイグレーションされた後、所定時間内に移動先の物理サーバ２上で稼働していた他の仮想マシン１４が他の物理サーバ２にホットマイグレーションされた場合（第１のエラールール）と、ある論理グループＬＧ内で特定の仮想マシン１４のホットマイグレーションが頻発している場合（第２のエラールール）とを規定するようにした場合について述べたが、本発明はこれに限らず、要は、論理グループＬＧ内のリソースが不足したときに発生するホットマイグレーションのパターンをエラールールとして規定するのであれば、上述の第１及び第２のエラールール以外のパターンをエラールールとして規定するようにしても良い。

　また上述の実施の形態においては、第１又は第２のエラールールに該当するホットマイグレーションの発生の有無を監視する監視部と、エラールールに該当するホットマイグレーションが発生したことが監視部により検出された場合に、当該ホットマイグレーションが発生した論理グループＬＧ以外の論理グループＬＧに所属する物理サーバ２の中から１つの物理サーバ２を選択し、選択した物理サーバ２上で稼働し又は稼働予定の仮想マシン１４を同一論理グループＬＧ内の他の物理サーバ２に移動させた後に、当該選択した物理サーバ２を第１又は第２のエラールールに該当する仮想マシン１４の移動が発生した論理グループＬＧに貸し出すように、対応する論理グループＬＧの構成を変更する論理グループ構成変更部とを、管理サーバ３内の同じＣＰＵ２０及び論理グループ構成変更プログラム４０により実現するようにした場合について述べたが、本発明はこれに限らず、これら監視部及び論理グループ構成変更部を別個のＣＰＵ及びプログラムにより実現するようにしても良い。

　本発明は、ＤＲＳ機能が搭載された管理サーバに適用することができる。

　１……計算機システム、２……物理サーバ、３……管理サーバ、１０，２０……ＣＰＵ、１１，２１……メモリ、１３……ハイパーバイザ、１４……仮想マシン、４０……論理グループ構成変更プログラム、４１……物理サーバ構成テーブル、４２……仮想マシン予約情報一覧、４３……ホットマイグレーション情報テーブル、４４……イベント一覧、４５……リソース取得先一覧、４６……移動先候補一覧、４７……借用リソース管理テーブル、４８……物理サーバ一覧、ＬＧ……論理グループ。

Claims (14)

1. 　それぞれ仮想化プログラムが実装された複数の物理サーバを複数の論理グループに分けて管理し、各前記論理グループ内における各物理サーバの負荷バランスを平準化するように、いずれかの前記物理サーバ上で稼働し又は稼働予定の仮想マシンを同一の前記論理グループ内の他の前記物理サーバに移動するよう対応する前記物理サーバを制御する管理装置において、
   　前記論理グループ内のリソースが不足したときに発生する前記仮想マシンの移動パターンをエラールールとして設定でき、
   　設定された前記エラールールに該当する前記仮想マシンの移動の有無を監視する監視部と、
   　前記エラールールに該当する前記仮想マシンの移動が発生したことが前記監視部により検出された場合に、当該仮想マシンの移動が発生した前記論理グループ以外の前記論理グループに所属する前記物理サーバの中から１つの前記物理サーバを選択し、選択した物理サーバ上で稼働し又は稼働予定の前記仮想マシンを同一論理グループ内の他の前記物理サーバに移動させた後に、当該選択した物理サーバを前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに貸し出すように、対応する前記論理グループの構成を変更する論理グループ構成変更部と
   　を備えることを特徴とする管理装置。
2. 　前記エラールールとして、
   　前記仮想マシンが他の前記物理サーバに移動されたために、所定時間内に、当該物理サーバ上で稼働していた他の前記仮想マシンがさらに他の前記物理サーバに移動される第１のパターンと、同一の前記論理グループ内で発生した同一の前記仮想マシンの移動頻度が予め設定された閾値以上である第２のパターンとの少なくとも一方が設定された
   　ことを特徴とする請求項１に記載の管理装置。
3. 　前記論理グループ構成変更部は、
   　前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに対して、他の論理グループから前記物理サーバを貸出し期限を決めて貸し出す
   　ことを特徴とする請求項１に記載の管理装置。
4. 　前記貸出し期限は、
   　前記物理サーバを前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに貸し出すように、対応する前記論理グループの構成を変更する処理の実行契機となった前記仮想マシンの終了日時の前日である
   　ことを特徴とする請求項３に記載の管理装置。
5. 　前記論理グループ構成変更部は、
   　前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに対して他の前記論理グループから貸し出した各前記物理サーバの前記貸出し期限を管理し、
   　前記貸出し期限までの残り日数が所定の第１の日数以下の物理サーバを、当該物理サーバの貸出し元の前記論理グループに返却するように、対応する前記論理グループの構成を変更する
   　ことを特徴とする請求項３に記載の管理装置。
6. 　前記論理グループ構成変更部は、
   　前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに対して他の前記論理グループから貸し出した各前記物理サーバの前記貸出し期限を管理し、
   　前記貸出し期限までの残り日数が所定の第２の日数以下の物理サーバが存在する場合には、当該物理サーバの前記貸出し期限を管理者に通知する
   　ことを特徴とする請求項３に記載の管理装置。
7. 　前記論理グループ構成変更部は、
   　外部操作に応じて、前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに対して他の前記論理グループから貸し出した前記物理サーバの貸出し状態を解除し、当該物理サーバを貸出し先の前記論理グループに所属するよう対応する前記論理グループの構成を変更する
   　ことを特徴とする請求項１に記載の管理装置。
8. 　それぞれ仮想化プログラムが実装された複数の物理サーバを複数の論理グループに分けて管理し、各前記論理グループ内における各物理サーバの負荷バランスを平準化するように、いずれかの前記物理サーバ上で稼働し又は稼働予定の仮想マシンを同一の前記論理グループ内の他の前記物理サーバに移動するよう対応する前記物理サーバを制御する管理方法において、
   　前記論理グループ内のリソースが不足したときに発生する前記仮想マシンの移動パターンをエラールールとして設定する第１のステップと、
   　設定された前記エラールールに該当する前記仮想マシンの移動の発生の有無を監視し、前記エラールールに該当する前記仮想マシンの移動が発生したことを検出した場合に、当該仮想マシンの移動が発生した前記論理グループ以外の前記論理グループに所属する前記物理サーバの中から１つの前記物理サーバを選択し、選択した物理サーバ上で稼働し又は稼働予定の前記仮想マシンを同一論理グループ内の他の前記物理サーバに移動させた後に、当該選択した物理サーバを前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに貸し出すように、対応する前記論理グループの構成を変更する第２のステップと
   　を備えることを特徴とする管理方法。
9. 　前記エラールールとして、
   　前記仮想マシンが他の前記物理サーバに移動されたために、所定時間内に、当該物理サーバ上で稼働していた他の前記仮想マシンがさらに他の前記物理サーバに移動される第１のパターンと、同一の前記論理グループ内で発生した同一の前記仮想マシンの移動頻度が予め設定された閾値以上となっている第２のパターンとの少なくとも一方が設定された
   　ことを特徴とする請求項８に記載の管理方法。
10. 　前記第２のステップでは、
    　前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに対して、他の論理グループから前記物理サーバを貸出し期限を決めて貸し出す
    　ことを特徴とする請求項８に記載の管理方法。
11. 　前記貸出し期限は、
    　前記物理サーバを前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに貸し出すように、対応する前記論理グループの構成を変更する処理の実行契機となった前記仮想マシンの終了日時の前日である
    　ことを特徴とする請求項１０に記載の管理方法。
12. 　前記第２のステップでは、
    　前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに対して他の前記論理グループから貸し出した各前記物理サーバの前記貸出し期限を管理し、
    　前記貸出し期限までの残り日数が所定の第１の日数以下の物理サーバを、当該物理サーバの貸出し元の前記論理グループに返却するように、対応する前記論理グループの構成を変更する
    　ことを特徴とする請求項１０に記載の管理方法。
13. 　前記第２のステップでは、
    　前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに対して他の前記論理グループから貸し出した各前記物理サーバの前記貸出し期限を管理し、
    　前記貸出し期限までの残り日数が所定の第２の日数以下の物理サーバが存在する場合には、当該物理サーバの前記貸出し期限を管理者に通知する
    　ことを特徴とする請求項１０に記載の管理方法。
14. 　前記第２のステップでは、
    　外部操作に応じて、前記エラールールに該当する前記仮想マシンの移動が発生した前記論理グループに対して他の前記論理グループから貸し出した前記物理サーバの貸出し状態を解除し、当該物理サーバを貸出し先の前記論理グループに所属するよう対応する前記論理グループの構成を変更する
    　ことを特徴とする請求項８に記載の管理方法。

Images