JP2011197852A - 仮想計算機システムの管理プログラム，管理装置及び管理方法 - Google Patents

Abstract

【課題】物理サーバに発生したボトルネックを解消する。
【解決手段】ゲストＯＳが動作する複数の物理サーバを管理する管理サーバは、物理サーバからリソース不足が発生したことを示すリソース不足情報を受信すると、リソース不足情報を送信した物理サーバを除く他の物理サーバに対して、リソースの使用率を通知することを依頼する（Ｓ６１）。また、管理サーバは、各物理サーバからリソースの使用率が通知されると（Ｓ６２）、各物理サーバのリソース能力及びリソース使用率に基づいて、他の物理サーバの中からリソースに余裕がある物理サーバを選択する（Ｓ６３）。そして、管理サーバは、リソース不足情報を送信した物理サーバで動作している複数のゲストＯＳの中から移動するゲストＯＳを選択し（Ｓ６４）、物理サーバに対して選択されたゲストＯＳをライブマイグレーションすることを依頼する（Ｓ６５）。
【選択図】図１５

Description

本発明は、仮想計算機システムを管理する技術に関する。

近年、物理サーバ上に複数台の仮想マシンを構築し、各仮想マシンごとに任意のＯＳ（Operating System）やアプリケーションを動作させる仮想計算機システムが実用化されている。仮想計算機システムには、負荷変動に柔軟に対応すべく、仮想マシンのＣＰＵ（Central Processing Unit），メモリ，ディスク及びネットワークなどのリソース使用率に基づいて、仮想マシンへのリソース割当を動的に行う動的スケジューリング機能が組み込まれている。

特開２００３−１５７１７７号公報

しかしながら、従来の動的スケジューリング機能は、１台の物理サーバのみを管理対象としていたため、複数の物理サーバを備えた仮想計算機システムにおいて、ある物理サーバにリソースのボトルネックが発生しても、そのボトルネックを解決することができなかった。

そこで、本技術は従来技術の問題点に鑑み、複数台の物理サーバを有する仮想計算機システムにおいて、物理サーバに発生したボトルネックを解消する仮想計算機システムの管理技術を提供することを目的とする。

このため、本技術では、仮想マシンが動作する複数の物理サーバを管理する管理サーバは、管理対象である物理サーバの１つにリソース不足が発生したときに、リソース不足が発生した物理サーバを除く他の物理サーバに対して、リソースの使用率を通知することを依頼する。そして、管理サーバは、各物理サーバのリソースの能力及び使用率に基づいてリソースに余裕がある物理サーバを選択し、リソース不足が発生した物理サーバ及び選択された物理サーバに対して、仮想マシンの１つをライブマイグレーションすることを依頼する。

本技術によれば、仮想マシンが動作する複数の物理サーバを備えた仮想計算機システムにおいて、ある物理サーバにリソースのボトルネックが発生しても、そのボトルネックを解消することができる。

本技術を適用した仮想計算機システムの全体構成図である。 物理サーバ及び管理サーバの機能ブロック図である。 能力情報テーブルの説明図である。 能力情報通知処理のフローチャートである。 能力情報の説明図である。 能力情報格納処理のフローチャートである。 ゲストＯＳ起動処理のメインルーチンのフローチャートである。 リソース使用率情報の説明図である。 リソースに余裕がある物理サーバを選択するサブルーチンのフローチャートである。 スコアを算出するための加算値の算出例１の説明図である。 スコアを算出するための加算値の算出例２の説明図である。 リソース使用率通知処理のフローチャートである。 リソース不足通知処理のフローチャートである。 リソース不足情報の説明図である。 マイグレーション処理のフローチャートである。 ゲストＯＳ起動時に通知されるリソース使用率情報の一例を示し、（Ａ）〜（Ｄ）は夫々Server１〜４のリソース使用率の説明図である。 各物理サーバにおけるリソースの空き状況の説明図である。 リソース不足発生時に通知されるリソース使用率情報の一例を示し、（Ａ）〜（Ｃ）は夫々Server２〜４のリソース使用率の説明図である。 各物理サーバにおけるリソースの空き状況の説明図である。

以下、添付された図面を参照して本発明を実施するための実施例について技術を詳細に説明する。
図１は、本実施例に係る仮想計算機システムの全体構成を示す。

管理対象となる複数の物理サーバ１０は、インターネットなどのコンピュータネットワーク２０を介して、管理サーバ（汎用コンピュータを利用することができる）３０に接続される。物理サーバ１０には、仮想的なコンピュータである仮想マシンをソフトウエアにより実現することで、複数の異なるＯＳを並列に実行できるようにするハイパーバイザ（プログラム）１２が実装される。ハイパーバイザ１２は、仮想マシンのプログラムを動作させる基盤となるホストＯＳ１４と、仮想マシン上で動作しているゲストＯＳ１６と、を夫々管理する。ここで、物理サーバ１０及び管理サーバ３０は、ＣＰＵ（Central Processing Unit）などのプロセッサと、メモリなどの記憶装置と、を夫々有する。

物理サーバ１０のハイパーバイザ１２には、図２に示すように、能力情報通知部１２Ａ，リソース使用率通知部１２Ｂ，リソース使用状況監視部１２Ｃ及びリソース不足通知部１２Ｄとして機能するためのプログラムが組み込まれている。

能力情報通知部１２Ａは、物理サーバ１０が起動、又は、物理サーバ１０にリソース（ＣＰＵ，メモリ，ホストバスアダプタ及びネットワークカードなど）が追加されたことを契機として、管理サーバ３０に対して物理サーバ１０のリソース能力を通知する。ここで、ホストバスアダプタは、ＳＣＳＩ（Small Computer System Interface），ファイバーチャネル及びシリアルＡＴＡ（Advanced Technology Attachment）などを接続するデバイスを含む。リソース使用率通知部１２Ｂは、管理サーバ３０からリソース使用率の通知依頼があったことを契機として、管理サーバ３０に対して物理サーバ１０のリソース使用率を返送する。リソース使用状況監視部１２Ｃは、物理サーバ１０が起動されたことを契機として、リソースの使用状況を常時監視する。リソース不足通知部１２Ｄは、リソース使用状況監視部１２Ｃによりリソース不足が検知されたことを契機として、管理サーバ３０に対してリソース不足が発生したことを通知する。

一方、管理サーバ３０は、ハードディスクなどのストレージに構築されたＤＢ（Database）３２を有する。ＤＢ３２は、図３に示すように、物理サーバ１０を特定するための物理サーバ名に対して、物理サーバ１０のＣＰＵ能力，メモリサイズ，ホストバスアダプタ能力及びネットワーク能力を関連付けた能力情報テーブル４０を保持する。ＣＰＵ能力は、プロセッサコアの動作周波数とコア数とを乗算した値であり、例えば、２．４ＧＨｚのプロセッサコアが１６個実装されていれば、２．４×１６＝３８．４ＧＨｚとなる。メモリサイズは、物理サーバ１０に搭載されているメモリの総量を示す。ホストバスアダプタ能力は、ホストバスアダプタの転送速度と実装数とを乗算した値であり、例えば、０．２ＧＢ／Ｓ（Giga Byte per Second）のホストバスアダプタが４個実装されていれば、０．２×４＝０．８ＧＢ／Ｓとなる。ホストバスアダプタの転送速度は、ホストバスアダプタごとにディスクＩ／Ｏ（Input/Output）を実行して速度を測定したり、ホストバスアダプタの種別ごとに転送速度を規定した辞書を参照して求めるようにすればよい。ネットワーク能力は、ネットワークカードの転送速度とカード数とを乗算した値であり、例えば、１Ｇｂ／Ｓ (Giga bit per Second)のネットワークカードが8個実装されていれば、１×８＝８Ｇｂ／Ｓとなる。ネットワークカードの転送速度は、ネットワークカードごとにＩ／Ｏを実行して速度を測定したり、ネットワークカードの種別ごとに転送速度を規定した辞書を参照して求めるようにすればよい。

また、管理サーバ３０は、仮想計算機システムの管理プログラムを実行することで、図２に示すように、能力情報格納部３０Ａ，リソース使用率通知依頼部３０Ｂ，物理サーバ選択部３０Ｃ，ゲストＯＳ起動依頼部３０Ｄ及びマイグレーション依頼部３０Ｅを夫々具現化する。なお、仮想計算機システムの管理プログラムは、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）などのコンピュータ読取可能な記録媒体から、公知の手段を用いて、管理サーバ３０のストレージにインストールされる。

能力情報格納部３０Ａは、物理サーバ１０のリソース能力が通知されたことを契機として、ＤＢ３２にサーバ１０のリソース能力を格納する。リソース使用率通知依頼部３０Ｂは、管理サーバ３０においてゲストＯＳ１６の起動操作が行われたこと、又は、物理サーバ１０からリソース不足の発生が通知されたことを契機として、物理サーバ１０に対してリソース使用率の通知依頼を行う。物理サーバ選択部３０Ｃは、物理サーバ１０からリソース使用率が通知されたことを契機として、リソースに余裕がある物理サーバ１０を選択する。ゲストＯＳ起動依頼部３０Ｄは、物理サーバ選択部３０Ｃにより選択された物理サーバ１０に対して、ゲストＯＳ１６を起動することを依頼する。マイグレーション依頼部３０Ｅは、リソース不足が発生した物理サーバ１０及び物理サーバ選択部３０Ｃにより選択された物理サーバ１０に対して、リソース不足が発生した物理サーバ１０からゲストＯＳ１６の１つをライブマイグレーションすることを依頼する。

図４は、物理サーバ１０が起動されたこと、又は、物理サーバ１０にリソースが追加されたことを契機として、物理サーバ１０の能力情報通知部１２Ａが実行する能力情報通知処理の一例を示す。

ステップ１（図では「Ｓ１」と略記する。以下同様。）では、能力情報通知部１２Ａが、ＣＰＵ能力，メモリサイズ，ホストバスアダプタ能力及びネットワーク能力を取得又は測定し、図５に示すような能力情報４２を作成する。ここで、能力情報４２は、物理サーバ１０のＣＰＵ能力，メモリサイズ，ホストバスアダプタ能力及びネットワーク能力を含む。

ステップ２では、能力情報通知部１２Ａが、管理サーバ３０の能力情報格納部３０Ａに対して、物理サーバ名を付随した能力情報４２を送信する。
図６は、能力情報４２を受信したことを契機として、管理サーバ３０の能力情報格納部３０Ａが実行する能力情報格納処理の一例を示す。

ステップ１１では、能力情報格納部３０Ａが、能力情報４２に付随する物理サーバ名で特定されるレコードについて、ＤＢ３２の能力情報テーブル４０に能力情報を格納する。
このような能力情報通知処理及び能力情報格納処理によれば、物理サーバ１０が起動、又は、物理サーバ１０にリソースが追加されると、管理サーバ３０におけるＤＢ３２の能力情報テーブル４０には、管理対象となる物理サーバ１０の最新の能力が格納される。このため、管理サーバ３０は、ＤＢ３２の能力情報テーブル４０を参照することで、各物理サーバ１０のリソース能力を把握することができる。なお、ＤＢ３２の能力情報テーブル４０は、例えば、管理サーバ３０の管理者などにより手動で適宜更新されるようにしてもよい。

図７は、管理サーバ３０においてゲストＯＳ１６の起動操作が行われたことを契機として、管理サーバ３０のリソース使用率通知依頼部３０Ｂ，物理サーバ選択部３０Ｃ及びゲストＯＳ起動依頼部３０Ｄが協働して実行するゲストＯＳ起動処理の一例を示す。

ステップ２１では、リソース使用率通知依頼部３０Ｂが、ＤＢ３２の能力情報テーブル４０を参照し、管理対象である全ての物理サーバ１０に対して、リソース使用率を通知することを依頼する。

ステップ２２では、物理サーバ選択部３０Ｃが、全ての物理サーバ１０からリソース使用率の通知があったか否かを判定する。ここで、リソース使用率の通知は、図８に示すように、物理サーバ１０におけるＣＰＵ，メモリ，ホストバスアダプタ及びネットワークの使用率が設定されたリソース使用率情報４４によって行われる。また、各物理サーバ１０から通知されたリソース使用率は、物理サーバ名と関連付けて、例えば、メモリなどの高速な記憶装置に格納しておく。そして、物理サーバ選択部３０Ｃは、全ての物理サーバ１０からリソース使用率の通知があったと判定すれば処理をステップ２３へと進める一方（Ｙｅｓ）、全ての物理サーバ１０からリソース使用率の通知がないと判定すれば待機する（Ｎｏ）。

ステップ２３では、物理サーバ選択部３０Ｃが、リソースに余裕がある物理サーバ１０を選択するサブルーチンを実行する。
ステップ２４では、ゲストＯＳ起動依頼部３０Ｄが、物理サーバ選択部３０Ｃにより選択された物理サーバ１０に対して、起動操作が行われたゲストＯＳ１６を起動することを依頼する。

図９は、管理サーバ３０の物理サーバ選択部３０Ｃが実行するサブルーチン、即ち、リソースに余裕がある物理サーバ１０を選択するサブルーチンの一例を示す。
ステップ３１では、物理サーバ選択部３０Ｃが、ＤＢ３２の能力情報テーブル４０を参照して、選択対象となる物理サーバ１０を順次選択する。

ステップ３２では、物理サーバ選択部３０Ｃが、物理サーバ１０におけるリソースの余裕を示すスコアを０にリセットする。
ステップ３３では、物理サーバ選択部３０Ｃが、ステップ３１で選択された物理サーバ１０にゲストＯＳ１６を起動するためのメモリがあるか否か、即ち、メモリに空きがあるか否かを判定する。そして、物理サーバ選択部３０Ｃは、メモリに空きがあると判定すれば処理をステップ３４へと進める一方（Ｙｅｓ）、メモリに空きがないと判定すれば処理をステップ３８へと進める（Ｎｏ）。なお、後述するリソース不足に対応する処理では、ゲストＯＳ１６が不定であるため、ゲストＯＳ１６を起動するためのメモリは０であるとすればよい。

ステップ３４では、物理サーバ選択部３０Ｃが、ＣＰＵ，ホストバスアダプタ及びネットワークの中からリソースを順次選択する。
ステップ３５では、物理サーバ選択部３０Ｃが、ステップ３４で選択されたリソースについて、次のような方法で、リソース使用率に応じた加算値を算出する。
［加算値の算出例１］
物理サーバ選択部３０Ｃは、図１０に示すように、リソース使用率の増加に伴って加算値が線形に減少する特性を持ったマップを参照し、リソース使用率に応じた加算値を算出する。図示のマップでは、物理サーバ選択部３０Ｃは、リソース使用量が２０％，５０％，８０％，９０％及び１００％の場合、加算値を８０，５０，２０，１０及び０と夫々算出する。なお、「加算値＝初期値―変換係数×リソース使用率」と表すことができるので、物理サーバ選択部３０Ｃは、計算式から加算値を算出するようにしてもよい。
［加算値の算出例２］
物理サーバ選択部３０Ｃは、図１１に示すように、リソース使用率の増加に伴って加算値が離散的に減少する特性を持ったマップを参照し、リソース使用率に応じた加算値を算出する。図示のマップでは、物理サーバ選択部３０Ｃは、リソース使用量が６０％以下，６１％〜８０％，８１％〜９０％，９１％〜９９％及び１００％の場合、加算値を１００，５０，２０，５及び０と夫々算出する。このようにすれば、リソースに十分な余裕があるときには、大きな加算値が採択されるので、リソースに余裕がある物理サーバ１０が選択され易くなる。なお、物理サーバ選択部３０Ｃは、ソフトウエアによる判断処理により、加算値を算出するようにしてもよい。また、リソース使用率に応じた加算値は、仮想計算機システムの管理者などが自由に設定できるようにしてもよい。

ステップ３６では、物理サーバ選択部３０Ｃが、スコアに加算値を加算することで、スコアを更新する（スコア＝スコア＋加算値）。
ステップ３７では、物理サーバ選択部３０Ｃが、全てのリソース、即ち、ＣＰＵ，ホストバスアダプタ及びネットワークについて、スコアの更新処理を実行したか否かを判定する。そして、物理サーバ選択部３０Ｃは、全てのリソースについてスコアの更新処理を実行したと判定すれば処理をステップ３８へと進める一方（Ｙｅｓ）、全てのリソースについてスコアの更新処理を実行していないと判定すれば処理をステップ３４へと戻す（Ｎｏ）。

ステップ３８では、物理サーバ選択部３０Ｃが、メモリなどの高速な記録装置に、物理サーバ名に関連付けてスコアを保存する。
ステップ３９では、物理サーバ選択部３０Ｃが、ＤＢ３２の能力情報テーブル４０に登録された全ての物理サーバ１０について、スコアの算出処理を実行したか否かを判定する。そして、物理サーバ選択部３０Ｃは、全ての物理サーバ１０についてスコアの算出処理を実行したと判定すれば処理をステップ４０へと進める一方（Ｙｅｓ）、全ての物理サーバ１０についてスコアの算出処理を実行していないと判定すれば処理をステップ３１へと戻す（Ｎｏ）。

ステップ４０では、物理サーバ選択部３０Ｃが、ＤＢ３２の能力情報テーブル４０及び記憶装置に保存されたスコアを参照し、リソースの余裕が最も大きな物理サーバ１０を選択する。具体的には、物理サーバ選択部３０Ｃは、各物理サーバ１０ごとに、メモリを除く他のリソース（ＣＰＵ，ホストバスアダプタ及びネットワーク）の空き容量（余裕）にスコアを乗算した値を算出し、最大の値を持つ物理サーバ１０を選択する。ここで、リソースの空き容量は、ＤＢ３２の能力情報テーブル４０を参照し、リソース使用率から逆算するようにすればよい。

図１２は、リソース使用率の通知依頼があったことを契機として、物理サーバ１０のリソース使用率通知部１２Ｂが実行するリソース使用率通知処理の一例を示す。
ステップ４１では、リソース使用率通知部１２Ｂが、物理サーバ１０の各リソースの使用状況を取得し、図８に示すリソース使用率情報４４を管理サーバ３０に返送する。ここで、リソース使用率通知部１２Ｂは、物理サーバ１０を特定するための物理サーバ名をリソース使用率情報４４に付随して返送する。

このようなゲストＯＳ起動処理及び使用率通知処理によれば、管理サーバ３０においてゲストＯＳ１６の起動操作が行われると、管理対象である各物理サーバ１０のリソース使用率が問い合わされる。そして、リソースに最も余裕がある物理サーバ１０に対して、ゲストＯＳ１６を起動することが依頼される。このとき、ゲストＯＳ１６を起動する物理サーバ１０は、ＣＰＵ能力及びメモリサイズだけでなく、ＩＯによるボトルネックが発生し易いホストバスアダプタ能力及びネットワーク能力も考慮して選択される。このため、物理サーバ１０にボトルネックが発生し難いように仮想マシンを配置することができる。

図１３は、物理サーバ１０が起動されたことを契機として、物理サーバ１０のリソース使用状況監視部１２Ｃ及びリソース不足通知部１２Ｄが協働して繰り返し実行するリソース不足通知処理の一例を示す。

ステップ５１では、リソース使用状況監視部１２Ｃが、物理サーバ１０のリソース使用率を取得する。
ステップ５２では、リソース使用状況監視部１２Ｃが、ＣＰＵ使用率が第１の閾値以上であるか否かを介して、ＣＰＵに余裕があるか否かを判定する。ここで、第１の閾値としては、例えば、ＣＰＵに全く余裕がない１００％、余裕が少ない８０％などを採用することができる。そして、リソース使用状況監視部１２Ｃは、ＣＰＵに余裕があると判定すれば処理をステップ５３へと進める一方（Ｙｅｓ）、ＣＰＵに余裕がないと判定すれば処理をステップ５５へと進める（Ｎｏ）。

ステップ５３では、リソース使用状況監視部１２Ｃが、ホストバスアダプタ使用率が第２の閾値以上であるか否かを介して、ホストバスアダプタに余裕があるか否かを判定する。ここで、第２の閾値としては、ホストバスアダプタに全く余裕がない１００％、余裕が少ない８０％などを採用することができる。なお、第２の閾値は、ホストバスアダプタの特性を考慮して、第１の閾値とは異なる値を採るようにしてもよい（以下同様）。そして、リソース使用状況監視部１２Ｃは、ホストバスアダプタに余裕があると判定すれば処理をステップ５４へと進める一方（Ｙｅｓ）、ホストバスアダプタに余裕がないと判定すれば処理をステップ５５へと進める（Ｎｏ）。

ステップ５４では、リソース使用状況監視部１２Ｃが、ネットワーク使用率が第３の閾値以上であるか否かを介して、ネットワークに余裕があるか否かを判定する。ここで、第３の閾値としては、ネットワークに全く余裕がない１００％、余裕が少ない８０％などを採用することができる。そして、リソース使用状況監視部１２Ｃは、ネットワークに余裕があると判定すれば処理を終了させる一方（Ｙｅｓ）、ネットワークに余裕がないと判定すれば処理をステップ５５へと進める（Ｎｏ）。

ステップ５５では、リソース不足通知部１２Ｄが、図１４に示すようなリソース不足情報４６を作成する。リソース不足情報４６は、物理サーバ１０で起動されている各ＯＳを特定するためのＯＳ名に対して、ＣＰＵ使用率，メモリ使用率，ホストバスアダプタ使用率及びネットワーク使用率が関連付けられたレコードを保持する。なお、図１４に示すリソース不足情報４６では、仮想マシンのプログラムを動作させる基盤となるホストＯＳ１４のネットワーク使用率が１００％になったことを示している。

ステップ５６では、リソース不足通知部１２Ｄが、管理サーバ３０に対してリソース不足情報４６を送信する。なお、リソース不足情報４６には、どの物理サーバ１０における情報であるかを特定可能とするため、物理サーバ名が付随される。

図１５は、リソース不足情報４６を受信したことを契機として、管理サーバ３０のリソース使用率通知依頼部３０Ｂ，物理サーバ選択部３０Ｃ及びマイグレーション依頼部３０Ｅが協働して実行するマイグレーション処理の一例を示す。

ステップ６１では、リソース使用率通知依頼部３０Ｂが、ＤＢ３２の能力情報テーブル４０を参照し、リソース不足情報４６を送信した物理サーバ１０を除く他の物理サーバ１０に対して、リソース使用率を通知することを依頼する。

ステップ６２では、物理サーバ選択部３０Ｃが、各物理サーバ１０からリソース使用率の通知があったか否かを判定する。そして、物理サーバ選択部３０Ｃは、各物理サーバ１０からリソース使用率の通知があったと判定すれば処理をステップ６３へと進める一方（Ｙｅｓ）、各物理サーバ１０からリソース使用率の通知がないと判定すれば待機する（Ｎｏ）。

ステップ６３では、物理サーバ選択部３０Ｃが、リソースに余裕がある物理サーバ１０を選択するサブルーチン（図９参照）を実行する。
ステップ６４では、マイグレーション依頼部３０Ｅが、リソース不足情報４６を送信した物理サーバ１０について、ライブマイグレーション対象となるゲストＯＳ１６を選択する。即ち、マイグレーション依頼部３０Ｅは、リソース不足となったリソースの使用率が大きいゲストＯＳ１６から順番に、ステップ６３で選択された物理サーバ１０に移動できるか否かを順次判定する。そして、マイグレーション依頼部３０Ｅは、物理サーバ１０に移動できると最初に判定されたゲストＯＳ１６を選択する。なお、マイグレーション依頼部３０Ｅは、物理サーバ１０に移動できるゲストＯＳ１６がないときには、ライブマイグレーションを実行しないことを決定する。

ステップ６５では、マイグレーション依頼部３０Ｅが、ステップ６３で選択した物理サーバ１０に対して、ステップ６４で選択したゲストＯＳ１６をライブマイグレーションする。即ち、マイグレーション依頼部３０Ｅは、リソース不足情報４６を送信した物理サーバ１０、及び、ステップ６３で選択された物理サーバ１０に対して、ステップ６４で選択されたゲストＯＳ１６をライブマイグレーションすることを依頼する。

このようなリソース不足通知処理及びマイグレーション処理によれば、物理サーバ１０においてリソース不足が発生すると、リソースに余裕がある物理サーバ１０に対して、リソース不足となったリソースの使用率が高いゲストＯＳ１６がライブマイグレーションされる。このため、物理サーバ１０の運用に伴って動的にリソース不足となっても、ゲストＯＳ１６が自動的に再配置されるので、物理サーバ１０に発生したボトルネックを解消することができる。

ここで、本実施形態に係る仮想計算機システムの管理技術の理解を容易ならしめることを目的として、具体的な事例を想定した実施例について説明する。
［ゲストＯＳ起動］
実施例の前提条件として、管理サーバ３０のＤＢ３２には、図３に示す能力情報テーブル４０が保持され、また、スコアを算出するための加算値の算出例２（図１１）が採用されているものとする。なお、他の実施例についても、前提条件は同じであるとする。

管理サーバ３０において、メモリ４ＧＢを要するゲストＯＳ１６の起動操作が行われると、管理サーバ３０から各物理サーバ１０に対してリソース使用率が問い合わされる。その問い合わせの応答として、各物理サーバ１０から管理サーバ３０に対して、図１６（Ａ）〜（Ｄ）に示すようなリソース使用率情報４４が返送される。そして、ＤＢ３２の能力情報テーブル４０が参照され、各物理サーバ１０におけるリソース使用率からリソースの空きを逆算すると、図１７に示すようになる。

次に、ゲストＯＳ１６を起動することができるメモリの空きを有する各物理サーバ１０について、次のようにして、リソース使用率に応じたスコアが算出される。即ち、Server１について、図１１に示すマップが参照され、ＣＰＵ使用率５０％，ホストバスアダプタ使用率８８％及びネットワーク使用率３８％に対応した加算値として、夫々、１００，２０及び１００が求められる。そして、ＣＰＵ使用率，ホストバスアダプタ使用率及びネットワーク使用率に応じた各加算値を積算することで、スコアは２２０であると算出される。Server２〜４についても同様な処理がなされ、スコアは夫々１７０，１７０及び０であると算出される。ここで、Server４については、メモリの空きが２ＧＢであってゲストＯＳ１６を起動できないことから、他のリソースの空き状況にかかわらず、スコアは０であると算出される。

その後、各物理サーバ１０について、次のように、ＣＰＵ能力，ホストバスアダプタ能力及びネットワーク能力にスコアを乗算した値の積算値が算出される。
Server１：４０×２２０＋０．８×２２０＋８×２２０＝１０７３６
Server２：３２×１７０＋１．２×１７０＋１６×１７０＝８３４６
Server３：６０×１７０＋１．６×１７０＋２４×１７０＝１４５５２
Server４：２４×０＋０．６×０＋４×０＝０
そして、積算値が最も大きいServer3が選択され、Server3に対してゲストＯＳ１６の起動が依頼される。
［リソース不足発生］
Server1においてリソース不足が発生すると、Server１から管理サーバ３０に対して、図１４に示すリソース不足情報４６が通知される。リソース不足情報４６を受信した管理サーバ３０では、リソース不足が発生したServer１を除くServer２〜４に対してリソース使用率が問い合わされる。その問い合わせの応答として、Server２〜４から管理サーバ３０に対して、図１８（Ａ）〜（Ｃ）に示すようなリソース使用率情報４４が返送される。そして、ＤＢ３２の能力情報テーブル４０が参照され、各物理サーバ１０におけるリソース使用率からリソースの空きを逆算すると、図１８に示すようになる。ここで、Server１は、リソース不足が発生しているため、ゲストＯＳ１６をライブマイグレーションする対象から外される。

次に、Server２〜４について、次のようにして、リソース使用率に応じたスコアが算出される。即ち、Server２について、図１１に示すマップが参照され、ＣＰＵ使用率２５％，ホストバスアダプタ使用率６７％及びネットワーク使用率８８％に対応した加算値として、夫々、１００，５０及び２０が求められる。そして、ＣＰＵ使用率，ホストバスアダプタ使用率及びネットワーク使用率に応じた各加算値を積算することで、スコアは１７０であると算出される。Server３及び４についても同様な処理がなされ、スコアは夫々２００及び２５０であると算出される。

その後、Server２〜４について、次のように、ＣＰＵ能力，ホストバスアダプタ能力及びネットワーク能力にスコアを乗算した値の積算値が算出される。
Server２：３２×１７０＋１．２×１７０＋１６×１７０＝８３４６
Server３：６０×２００＋１．６×２００＋２４×２００＝１７１２０
Server４：２４×２５０＋０．６×２５０＋４×２５０＝７１５０
そして、積算値が最も大きいServer3が選択される。

また、Server１におけるネットワークについて、ネットワーク使用率が最も大きいゲストＯＳ１６として、Guest１が選択される。Guest１のメモリ使用率は２０％であることから、Guest１の起動に要するメモリは１２．８ＧＢ（６４ＧＢ×０．２）であると求められる。Server３のメモリの空きは１６ＧＢであってGuest１を起動可能であるため、Server３にライブマイグレーションするゲストＯＳ１６はGuest１であると確定される。

その後、Server１及び３に対して、Server１のGuest１をServer３にライブマイグレーションすることが依頼される。
［リソース追加］
ゲストＯＳ起動と同様であるので、その説明を参照されたい。

以上の実施形態及び各実施例に関し、更に以下の付記を開示する。
（付記１）仮想マシンが動作する複数の物理サーバを管理すると共に、各物理サーバにおけるリソースの能力を夫々格納したデータベースを有する管理サーバに、管理対象である物理サーバの１つにリソース不足が発生したときに、リソース不足が発生した物理サーバを除く他の物理サーバに対して、リソースの使用率を通知することを依頼するステップと、前記リソース不足が発生した物理サーバを除く他の物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記リソース不足が発生した物理サーバを除く他の物理サーバの中からリソースに余裕がある物理サーバを選択するステップと、前記リソース不足が発生した物理サーバ及び選択された物理サーバに対して、前記リソース不足が発生した物理サーバで動作している仮想マシンの１つをライブマイグレーションすることを依頼するステップと、を実現させるための仮想計算機システムの管理プログラム。

（付記２）前記管理サーバに、仮想マシンの起動操作が行われたときに、管理対象である全ての物理サーバに対して、リソースの使用率を通知することを依頼するステップと、前記管理対象である全ての物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記全ての物理サーバの中からリソースに余裕がある物理サーバを選択するステップと、前記選択された物理サーバに対して、前記起動操作が行われた仮想マシンの起動を依頼するステップと、を更に実現させることを特徴とする付記１記載の仮想計算機システムの管理プログラム。

（付記３）前記リソースに余裕がある物理サーバを選択するステップは、選択対象となる複数の物理サーバについて、リソースの使用率に応じたスコアを算出し、前記スコアとリソースの能力との乗算値が最大の物理サーバを選択することを特徴とする付記１又は付記２に記載の仮想計算機システムの管理プログラム。

（付記４）前記リソースに余裕がある物理サーバを選択するステップは、リソースの使用率の増加に伴って線形的に減少する特性を持ったスコアの算出要素に基づいて、リソースの使用率に応じたスコアを算出することを特徴とする付記３記載の仮想計算機システムの管理プログラム。

（付記５）前記リソースに余裕がある物理サーバを選択するステップは、リソースの使用率の増加に伴って離散的に減少する特性を持ったスコアの算出要素に基づいて、リソースの使用率に応じたスコアを算出することを特徴とする付記３記載の仮想計算機システムの管理プログラム。

（付記６）前記仮想マシンの１つをライブマイグレーションすることを依頼するステップは、前記リソース不足が発生したリソースについて、前記リソースの使用率が高いものから順番に仮想マシンを順次選択しつつ、マイグレーションが可能であるか否かを判定し、マイグレーションが可能であると最初に判定された仮想マシンのライブマイグレーションを依頼することを特徴とする付記１〜付記５のいずれか１つに記載の仮想計算機システムの管理プログラム。

（付記７）前記リソースに余裕がある物理サーバを選択するステップは、メモリに余裕がない物理サーバを選択対象から除外することを特徴とする付記１〜付記６のいずれか１つに記載の仮想計算機システムの管理プログラム。

（付記８）仮想マシンが動作する複数の物理サーバにおけるリソースの能力を格納したデータベースと、管理対象である物理サーバの１つにリソース不足が発生したときに、リソース不足が発生した物理サーバを除く他の物理サーバに対して、リソースの使用率を通知することを依頼するリソース使用率通知依頼部と、前記リソース不足が発生した物理サーバを除く他の物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記リソース不足が発生した物理サーバを除く他の物理サーバの中からリソースに余裕がある物理サーバを選択する物理サーバ選択部と、前記リソース不足が発生した物理サーバ及び選択された物理サーバに対して、前記リソース不足が発生した物理サーバで動作している仮想マシンの１つをライブマイグレーションすることを依頼するマイグレーション依頼部と、を有する仮想計算機システムの管理装置。

（付記９）前記リソース使用率通知依頼部は、更に、仮想マシンの起動操作が行われたときに、管理対象である全ての物理サーバに対して、リソースの使用率を通知することを依頼すると共に、前記物理サーバ選択部は、更に、前記管理対象である全ての物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記全ての物理サーバの中からリソースに余裕がある物理サーバを選択し、前記選択された物理サーバに対して、前記起動操作が行われた仮想マシンの起動を依頼する起動依頼部を更に有することを特徴とする付記８記載の仮想計算機システムの管理装置。

（付記１０）仮想マシンが動作する複数の物理サーバを管理すると共に、各物理サーバにおけるリソースの能力を夫々格納したデータベースを有する管理サーバが、管理対象である物理サーバの１つにリソース不足が発生したときに、リソース不足が発生した物理サーバを除く他の物理サーバに対して、リソースの使用率を通知することを依頼するステップと、前記リソース不足が発生した物理サーバを除く他の物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記リソース不足が発生した物理サーバを除く他の物理サーバの中からリソースに余裕がある物理サーバを選択するステップと、前記リソース不足が発生した物理サーバ及び選択された物理サーバに対して、前記リソース不足が発生した物理サーバで動作している仮想マシンの１つをライブマイグレーションすることを依頼するステップと、を実行することを特徴とする仮想計算機システムの管理方法。

（付記１１）前記管理サーバが、仮想マシンの起動操作が行われたときに、管理対象である全ての物理サーバに対して、リソースの使用率を通知することを依頼するステップと、前記管理対象である全ての物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記全ての物理サーバの中からリソースに余裕がある物理サーバを選択するステップと、前記選択された物理サーバに対して、前記起動操作が行われた仮想マシンの起動を依頼するステップと、を更に実行することを特徴とする付記１０記載の仮想計算機システムの管理方法。

１０ 物理サーバ
１２Ｂ リソース使用率通知部
１６ ゲストＯＳ
２０ コンピュータネットワーク
３０ 管理サーバ
３０Ｂ リソース使用率通知依頼部
３０Ｃ 物理サーバ選択部
３０Ｄ ゲストＯＳ起動依頼部
３０Ｅ マイグレーション依頼部
３２ ＤＢ
４０ 能力情報テーブル
４２ 能力情報
４４ リソース使用率情報

Claims (5)

1. 仮想マシンが動作する複数の物理サーバを管理すると共に、各物理サーバにおけるリソースの能力を夫々格納したデータベースを有する管理サーバに、
   管理対象である物理サーバの１つにリソース不足が発生したときに、リソース不足が発生した物理サーバを除く他の物理サーバに対して、リソースの使用率を通知することを依頼するステップと、
   前記リソース不足が発生した物理サーバを除く他の物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記リソース不足が発生した物理サーバを除く他の物理サーバの中からリソースに余裕がある物理サーバを選択するステップと、
   前記リソース不足が発生した物理サーバ及び選択された物理サーバに対して、前記リソース不足が発生した物理サーバで動作している仮想マシンの１つをライブマイグレーションすることを依頼するステップと、
   を実現させるための仮想計算機システムの管理プログラム。
2. 前記管理サーバに、
   仮想マシンの起動操作が行われたときに、管理対象である全ての物理サーバに対して、リソースの使用率を通知することを依頼するステップと、
   前記管理対象である全ての物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記全ての物理サーバの中からリソースに余裕がある物理サーバを選択するステップと、
   前記選択された物理サーバに対して、前記起動操作が行われた仮想マシンの起動を依頼するステップと、
   を更に実現させることを特徴とする請求項１記載の仮想計算機システムの管理プログラム。
3. 前記リソースに余裕がある物理サーバを選択するステップは、選択対象となる複数の物理サーバについて、リソースの使用率に応じたスコアを算出し、前記スコアとリソースの能力との乗算値が最大の物理サーバを選択することを特徴とする請求項１又は請求項２に記載の仮想計算機システムの管理プログラム。
4. 仮想マシンが動作する複数の物理サーバにおけるリソースの能力を格納したデータベースと、
   管理対象である物理サーバの１つにリソース不足が発生したときに、リソース不足が発生した物理サーバを除く他の物理サーバに対して、リソースの使用率を通知することを依頼するリソース使用率通知依頼部と、
   前記リソース不足が発生した物理サーバを除く他の物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記リソース不足が発生した物理サーバを除く他の物理サーバの中からリソースに余裕がある物理サーバを選択する物理サーバ選択部と、
   前記リソース不足が発生した物理サーバ及び選択された物理サーバに対して、前記リソース不足が発生した物理サーバで動作している仮想マシンの１つをライブマイグレーションすることを依頼するマイグレーション依頼部と、
   を有する仮想計算機システムの管理装置。
5. 仮想マシンが動作する複数の物理サーバを管理すると共に、各物理サーバにおけるリソースの能力を夫々格納したデータベースを有する管理サーバが、
   管理対象である物理サーバの１つにリソース不足が発生したときに、リソース不足が発生した物理サーバを除く他の物理サーバに対して、リソースの使用率を通知することを依頼するステップと、
   前記リソース不足が発生した物理サーバを除く他の物理サーバからリソースの使用率が通知されたときに、前記データベースに格納された各物理サーバにおけるリソースの能力及び通知されたリソースの使用率に基づいて、前記リソース不足が発生した物理サーバを除く他の物理サーバの中からリソースに余裕がある物理サーバを選択するステップと、
   前記リソース不足が発生した物理サーバ及び選択された物理サーバに対して、前記リソース不足が発生した物理サーバで動作している仮想マシンの１つをライブマイグレーションすることを依頼するステップと、
   を実行することを特徴とする仮想計算機システムの管理方法。

Images