JPWO2009037915A1 - サーバ組替支援システム、サーバ組替支援方法 - Google Patents

Abstract

サーバ組替支援システムは、記憶装置と、解除状況推定モジュールと、割当計画作成モジュールとを備える。記憶装置には、複数の物理サーバ及び複数の仮想サーバの運用状態を示す運用データと、複数の物理サーバのそれぞれの資源容量を示す容量データとが格納される。解除状況推定モジュールは、運用データ及び容量データを参照して、複数の物理サーバのうち負荷が資源容量に応じた閾値を超過している過負荷サーバを抽出する。更に、解除状況推定モジュールは、複数の仮想サーバのうち過負荷サーバに割り当てられている仮想サーバの少なくとも一部が解除サーバとして解除されたときの状況を推定する。割当計画作成モジュールは、推定された状況に基づいて、解除サーバの割り当て計画を作成する。

Description

本発明は、サーバの組み替えに関する。特に、本発明は、サーバ組み替えを支援するための技術に関する。

ＶＭｗａｒｅやＸｅｎといった仮想化ソフトウェアを用いた仮想化技術によって、１台の物理サーバを複数の仮想サーバとして稼働させることができる。その結果、状況に応じてサーバ運用を効率化することが容易になってきている（例えば、特開２００５−１１５６５３号公報、特開２００２−２０２９５９号公報を参照）。また、仮想化技術によって、サーバの組み替え（server reassignment）を簡単に行うことも可能となってきている。

図１は、サーバ組み替えの一例を概念的に示している。図１において、物理サーバＭ１〜Ｍ３上で動作する仮想サーバＶＭ１〜ＶＭ５で運用が行われているとする。処理量の多い昼間、仮想サーバＶＭ１、ＶＭ２は物理サーバＭ１上に構築され、仮想サーバＶＭ３、ＶＭ４は物理サーバＭ２上に構築され、仮想サーバＶＭ５は物理サーバＭ３上に構築される。一方、処理量の少ない夜間、仮想サーバＶＭ１、ＶＭ２、ＶＭ４は物理サーバＭ１上に構築され、仮想サーバＶＭ３、ＶＭ５は物理サーバＭ２上に構築され、物理サーバＭ３は使用されない。サーバ台数が削減されるため、運用管理コストが削減される。

この例で示されたように、サーバ組み替えとは、運用状況に応じて、物理サーバに対する仮想サーバの割り当てを変更することを意味する。全体としての処理量が減少した場合には、仮想サーバの割り当てを変更することにより、物理サーバの台数を削減できる可能性がある。一方、全体としての処理量が上昇して、ある物理サーバが過負荷状態になった場合には、仮想サーバの割り当てを変更することにより、その過負荷状態を解消する必要がある。場合によっては、物理サーバが追加される。

サーバ組み替えにおいては、組み替え後の物理サーバ台数を見積もるとともに、どの仮想サーバをどの物理サーバに移行するかを示す「サーバ組み替え計画」を策定することが望ましい。サーバ組み替え計画が満たすべき基本点な条件は、計算機資源（リソース）の包含関係である。すなわち、ある物理サーバに割り当てられる仮想サーバの「資源使用量」の合計は、その物理サーバの「資源容量」を超えないことが望ましい。ここで、計算機資源とは、ＣＰＵのほか、ディスクやメモリ、ネットワーク等を指す。

一方、コストの観点からは、組み替え後のサーバ台数がより少なくなるような計画が好適である。容量が一定の容器に様々なサイズの品物を詰めるとき、その品物の集合に対して必要となる容器の最小の個数を見つける問題は、一般に「ビンパッキング問題」と呼ばれている。そのビンパッキング問題に関して、現実的な時間内に最適解を見つけることは極めて難しいことが知られている。近似的な解法アルゴリズムとしては、「Ｆｉｒｓｔ−Ｆｉｔ減少（ＦＦＤ）アルゴリズム」などが知られている（Ｂ．コルテ，Ｊ．フィーゲン著，浅野孝夫他訳，「組合せ最適化 理論とアルゴリズム」，シュプリンガー・フェアラーク東京，２００５年１１月３日，ｐｐ．４６６−４７２．参照）。

特開平１０−２７１６７号公報には、並列計算機の負荷分散方法が記載されている。その並列計算機は、複数の計算機から構成されており、複数の構成プログラムから構成される並列プログラムを実行する。複数の構成プログラムが複数の計算機に割り当てられる際、構成プログラム自身が計算機にかける負荷が考慮され、負荷分散が行われる。具体的には、履歴採取プログラムが、各構成プログラムの資源使用率を採取する。更に、スケジューラが、各計算機の現在の資源使用率を参照し、資源使用率の大きい構成プログラムを、現在の資源使用率の小さい計算機に割り当てる。すなわち、スケジューラは、負荷の高い処理を、余力の大きな計算機に割り当てる。

特開２００３−１３１９０９号公報には、クライアントコンピュータに複数のファイルサーバが接続されたコンピュータネットワークシステムにおけるファイル管理方法が記載されている。比較部は、複数のファイルサーバのそれぞれの最大格納容量データと現在使用容量データとを定期的に参照する。エージェントプロパティは、サーバ状態データベースに格納されたデータを、比較部によって得られたデータで更新する。複数のファイルサーバの間でファイルの移動が発生したとき、その結果は移動記録に記述される。複数のファイルサーバにおける使用量が限界容量を超えたときに、エージェントプロパティは、複数のファイルサーバの中の空き容量の多いものへデータを移動させる。

本発明の１つの目的は、適切なサーバ組み替え計画を機械的に作成することができる技術を提供することにある。

本発明の第１の観点において、複数の物理サーバに割り当てられている複数の仮想サーバの組み替えを支援するサーバ組替支援システムが提供される。そのサーバ組替支援システムは、記憶手段と、解除状況推定手段と、割当計画作成手段とを備える。記憶手段には、複数の物理サーバ及び複数の仮想サーバの運用状態を示す運用データと、複数の物理サーバのそれぞれの資源容量を示す容量データとが格納される。解除状況推定手段は、運用データ及び容量データを参照して、複数の物理サーバのうち負荷が資源容量に応じた閾値を超過している過負荷サーバを抽出する。更に、解除状況推定手段は、複数の仮想サーバのうち過負荷サーバに割り当てられている仮想サーバの少なくとも一部が解除サーバとして解除されたときの状況を推定する。割当計画作成手段は、解除状況推定手段によって推定された状況に基づいて、上記解除サーバの割り当て計画を作成する。

本発明の第２の観点において、コンピュータを利用することにより、複数の物理サーバに割り当てられている複数の仮想サーバの組み替えを支援するサーバ組替支援方法が提供される。そのサーバ組替支援方法は、（Ａ）複数の物理サーバ及び複数の仮想サーバの運用状態を示す運用データを、記憶装置から読み出すステップと、（Ｂ）複数の物理サーバのそれぞれの資源容量を示す容量データを、記憶装置から読み出すステップと、（Ｃ）運用データ及び容量データを参照して、複数の物理サーバのうち負荷が資源容量に応じた閾値を超過している過負荷サーバを抽出するステップと、（Ｄ）複数の仮想サーバのうち過負荷サーバに割り当てられている仮想サーバの少なくとも一部が解除サーバとして解除されたときの状況を推定するステップと、（Ｅ）推定された状況に基づいて、解除サーバの割り当て計画を作成するステップと、を含む。

本発明の第３の観点において、複数の物理サーバに割り当てられている複数の仮想サーバの組み替えを支援するサーバ組替支援プログラムが提供される。そのサーバ組替支援システムは、（Ａ）複数の物理サーバ及び複数の仮想サーバの運用状態を示す運用データを、記憶装置から読み出すステップと、（Ｂ）複数の物理サーバのそれぞれの資源容量を示す容量データを、記憶装置から読み出すステップと、（Ｃ）運用データ及び容量データを参照して、複数の物理サーバのうち負荷が資源容量に応じた閾値を超過している過負荷サーバを抽出するステップと、（Ｄ）複数の仮想サーバのうち過負荷サーバに割り当てられている仮想サーバの少なくとも一部が解除サーバとして解除されたときの状況を推定するステップと、（Ｅ）推定された状況に基づいて、解除サーバの割り当て計画を作成するステップと、をコンピュータに実行させる。

本発明によれば、適切なサーバ組み替え計画を機械的に作成することが可能となる。

上記及び他の目的、長所、特徴は、次の図面と共に説明される本発明の実施の形態により明らかになるであろう。

図１は、サーバ移行の一例を示す概念図である。 図２は、本発明の実施例におけるサーバ割り当て処理を説明するための概念図である。 図３は、本発明の実施例においてサーバ割り当て処理を行う割当計画作成モジュールの一例を示すブロック図である。 図４は、本発明の実施例におけるサーバ割り当て処理の一例を示すフローチャートである。 図５は、サーバ割り当て処理の一例を示す概念図である。 図６は、本発明の実施例に係るサーバ組替支援システムを概略的に示すブロック図である。 図７は、本発明の実施例におけるサーバ組替計画の作成処理を説明するための概念図である。 図８は、物理サーバに関する運用データを示すテーブルである。 図９は、仮想サーバに関する運用データを示すテーブルである。 図１０は、物理サーバに関する容量データを示すテーブルである。 図１１は、第１の実施例に係るサーバ組替支援システムを示すブロック図である。 図１２は、第１の実施例におけるサーバ組替計画の作成処理を示すフローチャートである。 図１３は、第１の実施例におけるサーバ組替計画の作成処理の一例を示す概念図である。 図１４は、第２の実施例に係るサーバ組替支援システムを示すブロック図である。 図１５は、第２の実施例におけるサーバ組替計画の作成処理を示すフローチャートである。 図１６は、第２の実施例におけるサーバ組替計画の作成処理の一例を示す概念図である。 図１７は、第３の実施例に係るサーバ組替支援システムを示すブロック図である。 図１８は、第３の実施例におけるサーバ組替計画の作成処理を示すフローチャートである。 図１９は、サーバ組替支援システムの構成例を示すブロック図である。 図２０は、サーバ組替支援システムの変形例を概略的に示すブロック図である。 図２１は、サーバ組替支援システムの他の構成例を示すブロック図である。

添付図面を参照して、本発明の実施例に係るサーバ組み替え技術を説明する。

１．サーバの割り当て（Allocation）
出願人は、サーバの移行（server migration）に関連する技術を先に出願している（特願２００７−４３７８７：未公開）。そのサーバ移行としては、「サーバの統合（server consolidation）」や「サーバの組み替え（server reassignment）」が挙げられている。特願２００７−４３７８７に記載された内容は、参照により本出願に組み込まれる。まず、特願２００７−４３７８７に記載されている技術の一例を説明する。

図２は、サーバの移行を概念的に示している。サーバの移行では、移行元のサーバを移行先のサーバのいずれかに割り当てる（allocate）必要がある。図２において、移行元のサーバ群は、ｍ台のサーバ１００−０〜１００−（ｍ−１）から構成されている。ｍは２以上の整数である。これら移行元サーバ１００の移行先として、Ｎ台のサーバ２００−０〜２００−（Ｎ−１）が用いられる予定であるとする。Ｎは１以上の整数である。例えば、ｍは５であり、Ｎは２である。但し、Ｎ台の移行先サーバ２００では不十分な場合、それらとは別のサーバ２００−Ｘが追加されるとする。つまり、ｍ台の移行元サーバ１００は、少なくともＮ台の移行先サーバ２００に移行される。

各サーバは、実マシンであってもよいし、仮想化技術に基づいて構築される仮想マシンであってもよい。各サーバは、ＣＰＵ、ディスク、メモリ、ネットワーク等の計算機資源（リソース）を使用する。従って、各移行元サーバ１００に関して、その移行元サーバ１００が使用していた計算機資源の量を示す「資源使用量」を定義することができる。一方、各移行先サーバ２００に関して、その移行先サーバ２００が使用可能な計算機資源の量（許容量）を示す「資源容量」を定義することができる。

資源使用量の一例として、ＣＰＵ使用量が挙げられる。そのＣＰＵ使用量は、“ＣＰＵの相対性能値”と“ＣＰＵ使用率”との積で与えられる。例えば、ある移行元サーバ１００が、相対性能値８０のＣＰＵを搭載しており、ＣＰＵ使用率６０％を上限として稼動していた場合、当該移行元サーバ１００の資源使用量は４８（＝８０×０．６０）である。移行先サーバ２００の資源容量も同様に定義され得る。例えば、相対性能値１２０のＣＰＵを備える移行先サーバ２００を用い、ＣＰＵ使用率７５％を上限として運用を行う予定の場合、当該移行先サーバ２００の資源容量は９０（＝１２０×０．７５）となる。

図２に示されるように、移行元サーバ１００のそれぞれには、ＩＤ番号として整数ｉ（＝０〜（ｍ−１））が付与されている。それら移行元サーバｉの資源使用量は、Ｗ（ｉ）で表されており、図２の例ではＷ（０）＝１７、Ｗ（１）＝２３、Ｗ（２）＝１９、Ｗ（３）＝１１、Ｗ（４）＝１４である。同様に、移行先サーバ２００のそれぞれには、ＩＤ番号として整数ｊ（＝０〜（Ｎ−１））が付与されている。それら移行先サーバｊの資源容量はＵ（ｊ）で表されており、図２の例ではＵ（０）＝５０、Ｕ（１）＝３５である。尚、追加用のサーバ２００−Ｘの資源容量Ｕは、デフォルト値４０である。

サーバ移行に際しては、移行元サーバ１００のそれぞれをどの移行先サーバ２００に割り当てるかを示す「割り当て計画」を策定する必要がある。すなわち、ＩＤ番号ｉとＩＤ番号ｊとの対応関係（Ａ（ｉ）＝ｊ）を決定する必要がある。割り当て計画が満たすべき基本点な条件は、上述の計算機資源の包含関係である。すなわち、ある移行先サーバｊに割り当てられる移行元サーバｉの資源使用量Ｗ（ｉ）の合計は、その移行先サーバｊの資源容量Ｕ（ｊ）を超えてはならない。更に、コストの観点からは、移行後のサーバ台数ｎ（ｎはＮ以上の整数）がより少なくなるような割り当て計画が好適である。

図３は、対応関係Ａ（ｉ）＝ｊ、すなわち、割り当て計画を決定するための割当計画作成モジュール４０の一例を示している。割当計画作成モジュール４０に対する入力は、移行元サーバのそれぞれの資源使用量Ｗ（ｉ）、移行先サーバのそれぞれの資源容量Ｕ（ｊ）及び資源使用量Ｘ（ｊ）である。ある移行先サーバｊの資源使用量Ｘ（ｊ）は、その移行先サーバｊに割り当てられている移行元サーバｉの資源使用量Ｗ（ｉ）の合計であり、「資源割当量」とも参照される。移行先サーバｊにまだいずれの移行元サーバも割り当てられていないとき、その移行先サーバｊの資源使用量Ｘ（ｊ）は０である。割当計画作成モジュール４０は、それら資源使用量Ｗ（ｉ）、資源容量Ｕ（ｊ）及び資源使用量Ｘ（ｊ）に基づいて、好適な割り当て関係Ａ（ｉ）＝ｊを決定する。

図３において、割当計画作成モジュール４０は、移行元ソートモジュール４１、移行先ソートモジュール４２、及びパッキングモジュール４３を有している。以下、割当計画作成モジュール４０の機能、すなわち、サーバの割り当て処理を詳細に説明する。

移行元ソートモジュール４１は、移行元サーバの資源使用量Ｗ（ｉ）を受け取る。そして、移行元ソートモジュール４１は、移行元サーバを、資源使用量Ｗ（ｉ）の大きい順（降順）にソートする。更に、移行元ソートモジュール４１は、ソート結果を配列Ｓに格納する。配列Ｓの各要素はＳ（ｋ）で表されるとする（ｋ＝０〜ｍ−１）。このとき、要素Ｓ（０）は、資源使用量Ｗ（ｉ）が最大の移行元サーバのＩＤ番号ｉを示し、要素Ｓ（ｍ−１）は、資源使用量Ｗ（ｉ）が最小の移行元サーバのＩＤ番号ｉを示す。本例の場合、Ｓ＝［１，２，０，４，３］、Ｗ（Ｓ（０））＝２３，Ｗ（Ｓ（１））＝１９，Ｗ（Ｓ（２））＝１７，Ｗ（Ｓ（３））＝１４，Ｗ（Ｓ（４））＝１１である。後に説明されるように、配列Ｓ＝［１，２，０，４，３］は、割り当て処理の順番を意味している。

一方、移行先ソートモジュール４２は、移行先サーバの資源容量Ｕ（ｊ）及び資源使用量Ｘ（ｊ）を受け取る。そして、移行先ソートモジュール４２は、移行先サーバのそれぞれの資源の残量（Ｕ（ｊ）−Ｘ（ｊ））を算出し、移行先サーバを残量の小さい順（昇順）にソートする。更に、移行先ソートモジュール４２は、ソート結果を配列Ｔに格納する。配列Ｔの各要素はＴ（ｌ）で表されるとする（ｌ＝０〜Ｎ−１）。このとき、要素Ｔ（０）は、残量が最小の移行先サーバのＩＤ番号ｊを示し、要素Ｔ（Ｎ−１）は、残量が最大の移行先サーバのＩＤ番号ｊを示す。現段階では、それぞれの資源使用量Ｘ（ｊ）は０であるとする。その場合、Ｔ＝［１，０］であり、Ｕ（Ｔ（０））＝３５，Ｕ（Ｔ（１））＝５０である。

パッキングモジュール４３は、資源使用量Ｗ（ｉ）、配列Ｓ、資源容量Ｕ（ｊ）、Ｕ、資源使用量Ｘ（ｊ）、及び配列Ｔを用いて、「パッキング処理」を行う。このパッキング処理において、パッキングモジュール４３は、各移行元サーバｉをいずれかの移行先サーバｊに割り当てる。その結果、割当関係Ａ（ｉ）＝ｊ、移行先サーバの必要台数ｎ、最終的な資源使用量Ｘ（ｊ）が決定される。

図４は、サーバの割り当て処理（ステップＳ４０）を示すフローチャートである。また、図５は、割り当て計画の作成例を示す概念図である。図５に示されるように、配列Ｓの要素を表すパラメータｋは資源使用量Ｗ（ｉ）の大きさの順番を示しており、ｋ＝０，１，２，３，４はそれぞれｉ＝１，２，０，４，３に対応している。

まず、必要サーバ台数を示すパラメータｎが１に初期設定される。また、上記パラメータｋが０に初期設定される（ステップＳ４０１）。このパラメータｋは、次に示されるループ処理のカウンタとして用いられ、初期値０から１ずつ増加していく。１回のループ処理では、Ｓ（ｋ）で与えられるＩＤ番号の移行元サーバｉが、いずれかの移行先サーバｊに割り当てられる。全ての移行元サーバに関する割当処理が終了すれば（ステップＳ４０２；Ｎｏ）、ループ処理は終了し、ステップＳ４０は完了する。

パラメータｋが初期値０から１ずつ増加するため、割り当て処理の対象は、ＩＤ番号ｉ＝１，２，０，４，３の順番で変化していく。すなわち、資源使用量Ｗ（ｉ）の大きい順（降順）で、移行元サーバｉが１つずつ割り当て処理の対象として選択される。資源使用量Ｗ（ｉ）の降順で割り当て処理を行うことにより、全ての移行元サーバをより少数の移行先サーバに割り当てることができる。これは、ビンパッキング問題におけるヒューリスティクス（まず大きな物を配置して、小さな物は空きの部分に配置した方が、容器の数を少なくできる）に基づいている。

（１回目のループ処理：ｋ＝０、ｉ＝Ｓ（０）＝１）
まず、移行先サーバ（ｌ＝０；ｊ＝Ｔ（０）＝１）が選択される（ステップＳ４０３）。このとき、ｌはｎより小さいので（ステップＳ４０４；Ｙｅｓ）、処理はステップＳ４０８に進む。

ステップＳ４０８において、資源容量Ｕ（ｊ）が、資源使用量Ｘ（ｊ）と資源使用量Ｗ（ｉ）との和と比較される。これは、選択された移行元サーバｉの資源使用量Ｗ（ｉ）と、選択された移行先サーバｊの資源容量の残量（＝Ｕ（ｊ）−Ｘ（ｊ））との比較を意味する。以下、この比較対象の資源使用量Ｗ（ｉ）を、対象使用量Ｗ（ｉ）と参照する場合もある。現在のループ処理では、対象使用量（Ｗ（１）＝２３）と残量（Ｕ（１）−Ｘ（１）＝３５）との比較が行われる。

対象使用量が残量以下であるため（ステップＳ４０８；Ｙｅｓ）、ステップＳ４１０が実行される。ステップＳ４１０において、選択中の移行元サーバ（ｉ＝１）が、選択中の移行先サーバ（ｊ＝１）に割り当てられる。すなわち、割当関係Ａ（１）＝１が決定する。同時に、資源使用量Ｘ（１）に対象使用量Ｗ（１）が加算される。図５中の符号＃が付与されたボックスは、各ループ処理の結果を示している。現在のループ処理の結果は、符合＃１が付与されたボックス中に示されている。その後、パラメータｋがインクリメントされ、次の移行元サーバＳ（１）が選択される（ステップＳ４１１）。

（２回目のループ処理：ｋ＝１、ｉ＝Ｓ（１）＝２）
移行先サーバ（ｌ＝０；ｊ＝Ｔ（０）＝１）が再度選択される（ステップＳ４０３）。比較処理（ステップＳ４０８）において、対象使用量（Ｗ（２）＝１９）は、残量（Ｕ（１）−Ｘ（１）＝３５−２３）よりも大きい（ステップＳ４０８；Ｎｏ）。その場合、パラメータｌに１が加算される（ステップＳ４０９）。すなわち、次の移行先サーバ（ｊ＝Ｔ（１）＝０）が選択される。このように、パラメータｌは、ループ処理の度に初期化され、必要に応じて１ずつ増加していく。結果として、比較処理の対象が、移行先サーバ（ｊ＝Ｔ（０）＝１）、移行先サーバ（ｊ＝Ｔ（１）＝０）の順番で変化することになる。これは、資源容量の残量の小さい順（昇順）で、Ｎ台の移行先サーバから、比較処理の対象となる移行先サーバが選択されることを意味する。

新たな移行先サーバ（ｌ＝１；ｊ＝０）が選択されたので、必要台数ｎに１が加算される（ステップＳ４０４；Ｎｏ、ステップＳ４０５）。結果として、必要台数ｎは２になる。このとき、使用予定の２台の移行先サーバは未だ不足していない（ステップＳ４０６；Ｎｏ）。従って、処理はステップＳ４０８に進む。

比較処理（ステップＳ４０８）において、対象使用量（Ｗ（２）＝１９）は、残量（Ｕ（０）−Ｘ（０）＝５０）以下である（ステップＳ４０８；Ｙｅｓ）。従って、移行元サーバ（ｉ＝２）が移行先サーバ（ｊ＝０）に割り当てられる（ステップＳ４１０）。すなわち、割当関係Ａ（２）＝０が決定し、資源使用量Ｘ（０）に対象使用量Ｗ（２）が加算される（図５中の＃２参照）。そして、次の移行元サーバＳ（２）が選択される（ステップＳ４１１）。

（３回目のループ処理：ｋ＝２、ｉ＝Ｓ（２）＝０）
移行先サーバ（ｌ＝０；ｊ＝Ｔ（０）＝１）が再度選択される（ステップＳ４０３）。比較処理（ステップＳ４０８）において、対象使用量（Ｗ（０）＝１７）は、残量（Ｕ（１）−Ｘ（１）＝３５−２３）よりも大きい（ステップＳ４０８；Ｎｏ）。従って、次の移行先サーバ（ｌ＝１；ｊ＝Ｔ（１）＝０）が選択される（ステップＳ４０９）。必要台数ｎは既に２になっているので（ステップＳ４０４；Ｙｅｓ）、処理はステップＳ４０８に進む。

比較処理（ステップＳ４０８）において、対象使用量（Ｗ（０）＝１７）は、残量（Ｕ（０）−Ｘ（０）＝５０−１９）以下である（ステップＳ４０８；Ｙｅｓ）。従って、移行元サーバ（ｉ＝０）が移行先サーバ（ｊ＝０）に割り当てられる（ステップＳ４１０）。すなわち、割当関係Ａ（０）＝０が決定し、資源使用量Ｘ（０）に対象使用量Ｗ（０）が加算される（図５中の＃３参照）。そして、次の移行元サーバＳ（３）が選択される（ステップＳ４１１）。

（４回目のループ処理：ｋ＝３、ｉ＝Ｓ（３）＝４）
３回目と同様に処理が進み、移行元サーバ（ｉ＝４）が移行先サーバ（ｊ＝０）に割り当てられる（ステップＳ４１０）。すなわち、割当関係Ａ（４）＝０が決定し、資源使用量Ｘ（０）は５０（＝１９＋１７＋１４）となる（図５中の＃４参照）。そして、次の移行元サーバＳ（４）が選択される（ステップＳ４１１）。

（５回目のループ処理：ｋ＝４、ｉ＝Ｓ（４）＝３）
移行先サーバ（ｌ＝０；ｊ＝Ｔ（０）＝１）が再度選択される（ステップＳ４０３）。比較処理（ステップＳ４０８）において、対象使用量（Ｗ（３）＝１１）は、残量（Ｕ（１）−Ｘ（１）＝３５−２３）以下である（ステップＳ４０８；Ｙｅｓ）。従って、移行元サーバ（ｉ＝３）が移行先サーバ（ｊ＝１）に割り当てられる（ステップＳ４１０）。すなわち、割当関係Ａ（３）＝１が決定し、資源使用量Ｘ（１）に対象使用量Ｗ（３）が加算される（図５中の＃５参照）。

その後、ステップＳ４１１において、パラメータｋは５になる。これは、全ての移行元サーバに関する割当処理が終了したことを意味する（ステップＳ４０２；Ｎｏ）、従って、ループ処理は終了し、サーバの割り当て処理（ステップＳ４０）が完了する。結果として、図５に示されるように、割当関係「Ａ（０）＝０、Ａ（１）＝１、Ａ（２）＝０、Ａ（３）＝１、Ａ（４）＝０」が決定する。移行先サーバの必要台数ｎは２である。移行先サーバで予定される資源使用量は、Ｘ（０）＝５０、Ｘ（１）＝３４である。

尚、場合によっては、ある移行元サーバｉの対象使用量Ｗ（ｉ）が、使用予定の２台の移行先サーバのいずれの残量よりも大きくなるときがある。つまり、必要台数ｎが３となり、予定台数Ｎ（＝２）を上回る場合がある（ステップＳ４０６；Ｙｅｓ）。その場合、デフォルトの資源容量Ｕを有する移行先サーバ２００−Ｘが、移行先サーバ（ｊ＝３）として追加される（ステップＳ４０７）。移行先サーバ（ｊ＝３）の資源容量Ｕ（３）は、デフォルト値Ｕに設定される。また、資源使用量Ｘ（３）は、初期値０に設定される。その後、処理はステップＳ４１０に進み、当該移行元サーバｉは追加された移行先サーバ（ｊ＝３）に割り当てられる。

以上に説明されたように、適切な範囲内のサーバ台数への割り当て計画を機械的に作成することが可能となる。移行先サーバの資源容量Ｕ（ｊ）が互いに異なる場合でも、好適な割り当て計画を機械的に作成することが可能となる。その結果、システム設計者にかかる負担が軽減され、また、サーバ移行に要する時間が削減される。

尚、図３〜図５で示された手法は、特願２００７−４３７８７で記載された技術の一例である。割当計画作成モジュール４０は、特願２００７−４３７８７に記載された機能のいずれを提供してもよい。例えば、割当計画作成モジュール４０は、移行先ソートモジュール４２を含んでいなくてもよい。その場合、配列Ｔ（ｌ）は使用されず、パラメータｌの代わりにパラメータｊが、ループ処理の度に初期化され、必要に応じて１ずつ増加していく。つまり、比較処理の対象となる移行先サーバは、ＩＤ番号ｊの順番で選択される。

但し、特願２００７−４３７８７に記載されているように、図３〜図５で示された手法により、必要台数ｎが抑えられる可能性がある。つまり、配列Ｔを用い、比較処理の対象を資源容量Ｕ（ｊ）の残量の昇順で選択することにより、割当効率の向上が期待される。図３〜図５で示された手法によれば、資源使用量Ｗ（ｉ）のより大きな移行元サーバが、資源容量Ｕ（ｊ）の残量がより小さな移行先サーバに割り当てられる。これは、負荷の高い処理を容量の小さい計算機に割り当てることに相当しており、公知の特開２００２−２０２９５９号公報に記載された手法とは逆である。

２．サーバの組み替え
次に、図１で示されたようなサーバ組み替えを考える。この場合、仮想サーバＶＭ１〜ＶＭ５が移行元サーバに相当し、物理サーバＭ１〜Ｍ３が移行先サーバに相当する。ある物理サーバにかかる負荷が閾値を超えたとき、すなわち、ある物理サーバが過負荷状態になったとき、サーバの組み替えが必要となる。具体的には、その過負荷状態を解消するために、仮想サーバの割り当てを変更する必要がある。

仮想サーバの割り当てを変更するために、第１節（１．サーバの割り当て）で説明された技術を適用することが考えられる。その場合、上述の通り、仮想サーバの資源使用量Ｗ（ｉ）や物理サーバの資源容量Ｕ（ｊ）が考慮され、計算機資源の包含関係を満足する好適な割り当て関係Ａ（ｉ）＝ｊが決定される。これにより、過負荷状態は解消される。但し、第１節で示された技術によれば、現行の仮想サーバの割り当て状況は考慮されない。つまり、仮想サーバがいずれの物理サーバにも割り当てられていない状態から、仮想サーバと物理サーバとの割り当て関係Ａ（ｉ）＝ｊが決定される。その結果、現行の割り当て関係とは独立の、全く新たな割り当て関係Ａ（ｉ）＝ｊが決定される。従って、実際のサーバ組み替え時には、多数の仮想サーバの移行が必要となる可能性がある。

物理サーバ間では仕様や環境が異なることが多いため、仮想サーバの移行はそれなりのリスクを伴う。更に、ある仮想サーバによって提供されるサービスは、その仮想サーバの移行の間、停止することになる。第１節で示された技術によれば、最適な割り当て関係Ａ（ｉ）＝ｊは得られるが、多数の仮想サーバの移行が必要となると、サーバ組み替え時のリスクやサービス停止期間が増大してしまう。このような観点から言えば、移行すべき仮想サーバの数が極力少ないことが望ましい。

本発明の一実施例では、実際のサーバ組み替え時に移行される仮想サーバの数を抑制することができる技術が提供される。そのために、適切なサーバ組み替え計画が機械的に作成される。すなわち、本発明の一実施例では、適切なサーバ組み替え計画を作成することによりサーバ組み替えを支援する「サーバ組替支援システム」が提供される。

図６は、本発明の実施例に係るサーバ組替支援システムの構成を概略的に示している。サーバ組替支援システムは、解除状況推定モジュール３０と割当計画作成モジュール４０を備えている。割当計画作成モジュール４０は、第１節で説明された機能と同様の機能を有している。現在、複数の仮想サーバが複数の物理サーバに割り当てられているとする。

解除状況推定モジュール３０は、現在の運用情報を受け取る。現在の運用情報は、仮想サーバと物理サーバとの間の現在の割り当て関係Ａ（ｉ）＝ｊを含む。また、現在の運用情報は、仮想サーバの現在の資源使用量Ｗ（ｉ）と物理サーバの現在の資源使用量Ｘ（ｊ）とを含む。資源使用量Ｘ（ｊ）は、現在割り当てられている仮想サーバの資源使用量Ｗ（ｉ）の合計であり、物理サーバに関する「負荷」であるとも言える。更に、解除状況推定モジュール３０は、物理サーバの資源容量Ｕ（ｊ）を示す情報を受け取る。

解除状況推定モジュール３０は、それぞれの物理サーバの負荷（資源使用量Ｘ（ｊ））及び資源容量Ｕ（ｊ）を参照して、負荷が資源容量Ｕ（ｊ）に応じた“閾値”を超過している物理サーバを抽出する。そのような物理サーバは、以下「過負荷サーバ」と参照される。上記“閾値”は、資源容量Ｕ（ｊ）そのものであってもよいし、資源容量Ｕ（ｊ）に所定の比率（例えば９５％）を乗じた値であってもよい。

更に、解除状況推定モジュール３０は、仮想サーバの少なくとも一部を「解除候補」として決定し、その解除候補が解除（deallocate）されたときの状況を推定する。特に、解除状況推定モジュール３０は、上述の過負荷サーバに現在割り当てられている仮想サーバの少なくとも一部が解除されたときの状況を推定する。ここで、“状況”とは例えば、解除候補が解除されたときの、それぞれの物理サーバの負荷（資源使用量Ｘ（ｊ））や資源容量の残量（Ｕ（ｊ）−Ｘ（ｊ））を意味する。解除候補として決定された仮想サーバｉは、以下「解除サーバｉ’」と参照される。つまり、解除状況推定モジュール３０は、複数の仮想サーバの中から解除サーバを決定し、解除サーバが解除されたときの物理サーバのそれぞれの負荷等を推定（算出）する。例えば、解除状況推定モジュール３０は、仮想サーバの資源使用量Ｗ（ｉ）と過負荷サーバの資源容量Ｕ（ｊ）を参照して、過負荷サーバの負荷が上記閾値以下となるように、解除サーバを決定することができる。

割当計画作成モジュール４０は、解除状況推定モジュール３０によって推定された状況に基づいて、解除サーバの再割り当て先、すなわち解除サーバの割り当て計画を作成する。例えば、割当計画作成モジュール４０は、解除状況推定モジュール３０によって決定された解除サーバｉ’の資源使用量Ｗ（ｉ’）と、解除状況推定モジュール３０によって推定された物理サーバの負荷（資源使用量Ｘ（ｊ））を示す情報を受け取る。また、割当計画作成モジュール４０は、物理サーバのそれぞれの資源容量Ｕ（ｊ）を示す情報を受け取る。更に、割当計画作成モジュール４０は、割り当て関係Ａ（ｉ）＝ｊを受け取ってもよい。割当計画作成モジュール４０は、第１節で説明された機能と同様の機能を有している。従って、割当計画作成モジュール４０は、受け取った資源使用量Ｗ（ｉ’）、資源使用量Ｘ（ｊ）及び資源容量Ｕ（ｊ）に基づいて、解除サーバの割り当て計画を作成することができる（図３参照）。

割当計画作成モジュール４０による解除サーバの割り当て処理（ステップＳ４０）は、第１節で説明された手順（図４参照）で実施される。つまり、割当計画作成モジュール４０は、受け取った資源容量Ｕ（ｊ）と資源使用量Ｘ（ｊ）に基づいて、それぞれの物理サーバの資源容量の残量（Ｕ（ｊ）−Ｘ（ｊ））を算出する。そして、割当計画作成モジュール４０は、算出された残量と解除サーバの資源使用量Ｗ（ｉ’）を参照して、解除サーバの割り当てを決定する。これにより、仮想サーバと物理サーバとの間の新たな割り当て関係Ａ’（ｉ）＝ｊが決定される。

本実施例では、割り当て処理の対象が「解除サーバ」であることに留意されたい。既出の図３では、割当計画作成モジュール４０は、全ての仮想サーバの資源使用量Ｗ（ｉ）を受け取る。その結果、全ての仮想サーバが割り当て処理の対象となり、現行の割り当て関係Ａ（ｉ）＝ｊに依存しない新たな割り当て関係が決定される。一方、図６では、割当計画作成モジュール４０は、解除サーバの資源使用量Ｗ（ｉ’）を受け取る。従って、割り当て処理では、仮想サーバの全てではなく、その一部の解除サーバだけの割り当てが決定される。言い換えれば、解除サーバの割り当てだけが現行から変更され、その他の仮想サーバの割り当ては変更されない。結果として、現行の割り当て関係Ａ（ｉ）＝ｊに一部依存する新たな割り当て関係Ａ’（ｉ）＝ｊが決定される。つまり、現行の割り当て関係Ａ（ｉ）＝ｊの一部だけが変更（更新）される。

割当計画作成モジュール４０は、決定された割り当て関係Ａ’（ｉ）＝ｊを、割り当て計画として出力する。あるいは、割当計画作成モジュール４０は、解除サーバに関する割り当て関係Ａ’（ｉ’）＝ｊを、割り当て計画として出力してもよい。つまり、割り当て計画は、解除サーバの新たな割り当て先を少なくとも示している。その割り当て計画が、サーバ組み替えに関する計画、すなわちサーバ組み替え計画に相当する。このようにして、図６で示されたサーバ組替支援システムは、サーバ組み替え計画を機械的に作成する。ユーザは、作成されたサーバ組み替え計画を参照して、実際にサーバ組み替えを実施することができる。

そのサーバ組み替え時に移行される仮想サーバの数は、最大でも解除サーバの数である。何故なら、解除サーバ以外の仮想サーバの割り当ては変更されていないからである。従って、第１節で説明された技術だけを単に適用した場合と比較して、移行される仮想サーバの数が抑制される。その結果、実際のサーバ組み替え時のリスクやサービス停止期間が低減され、好適である。また、割り当て対象が解除サーバだけであるため、割り当て計画の作成時間も短縮される。このように、本実施例によれば、実際のサーバ組み替えに際して適切なサーバ組み替え計画が、機械的に且つ短時間で作成される。すなわち、サーバ組み替えが支援される。

３．サーバ組替計画の作成例
次に、具体例を挙げて、サーバ組み替え計画の作成処理を説明する。図７は、あるサーバシステムの運用状態を示している。図７において、複数の仮想サーバＶＭ０〜ＶＭ９が、複数の物理サーバＭ０〜Ｍ２上で動作している。仮想サーバＶＭ０〜ＶＭ９のそれぞれには、ＩＤ番号として整数ｉ（＝０〜９）が付与されている。また、物理サーバＭ０〜Ｍ２のそれぞれには、ＩＤ番号として整数ｊ（＝０〜２）が付与されている。

仮想サーバＶＭ０〜ＶＭ９の各々は、物理サーバＭ０〜Ｍ２のいずれかに割り当てられている。現在の割り当て関係Ａ（ｉ）＝ｊは、次の通りである。すなわち、仮想サーバＶＭ１、ＶＭ２、及びＶＭ６が、物理サーバＭ０に割り当てられている（Ａ（１）＝Ａ（２）＝Ａ（６）＝０）。仮想サーバＶＭ０、ＶＭ３、ＶＭ５、ＶＭ８が、物理サーバＭ１に割り当てられている（Ａ（０）＝Ａ（３）＝Ａ（５）＝Ａ（８）＝１）。仮想サーバＶＭ４、ＶＭ７、ＶＭ９が、物理サーバＭ２に割り当てられている（Ａ（４）＝Ａ（７）＝Ａ（９）＝２）。

図８及び図９は、現在の運用状態を示す運用データ（ＤＰ、ＤＶ）の例を示している。図８に示される運用データＤＰは、物理サーバの運用状態を示す。具体的には、運用データＤＰは、物理サーバと仮想サーバとの現在の割り当て関係Ａ（ｉ）＝ｊと、物理サーバのそれぞれの現在の資源使用量Ｘ（ｊ）を示している。図９に示される運用データＤＶは、仮想サーバの運用状態を示す。具体的には、運用データＤＶは、仮想サーバのそれぞれの資源使用量Ｗ（ｉ）を示している。図７及び図９で示される例では、Ｗ（０）＝２０、Ｗ（１）＝３０、Ｗ（２）＝１０、Ｗ（３）＝５、Ｗ（４）＝１５、Ｗ（５）＝４０、Ｗ（６）＝２０、Ｗ（７）＝５、Ｗ（８）＝２０、Ｗ（９）＝３５である。

図８で示される物理サーバの資源使用量Ｘ（ｊ）は、現在割り当てられている仮想サーバの資源使用量Ｗ（ｉ）の合計であり、物理サーバに関する「負荷」であるとも言える。図７及び図８で示される例では、Ｘ（０）＝６０、Ｘ（１）＝８５、Ｘ（２）＝５５である。

図１０は、物理サーバのそれぞれの資源容量Ｕ（ｊ）を示す容量データＤＤの例を示している。図７及び図１０で示される例では、Ｕ（０）＝Ｕ（１）＝Ｕ（２）＝７０である。また、容量データＤＤは、追加用の物理サーバの資源容量Ｕ（デフォルト値）も示している。本例では、デフォルト値Ｕも７０である。尚、資源容量Ｕ（ｊ）、Ｕは、互いに異なる値であってもよい。

ある物理サーバｊの資源使用量Ｘ（ｊ）がその物理サーバｊの資源容量Ｕ（ｊ）に応じた閾値を超えた場合、その物理サーバｊは過負荷サーバである。その閾値は、資源容量Ｕ（ｊ）そのものであってもよいし、資源容量Ｕ（ｊ）に所定の比率を乗じた値であってもよい。以下の説明では、閾値は資源容量Ｕ（ｊ）と等しい値であるとする。過負荷サーバが発生した場合、その過負荷サーバ並びにその上で稼動している仮想サーバの性能に重大な劣化が発生する。従って、その過負荷状態が解消されるように、仮想サーバの組み替えを実施する必要がある。図７で示された例では、物理サーバＭ１（ｊ＝１）が過負荷サーバとなっている（Ｘ（１）＝８５、Ｕ（１）＝７０）。よって、物理サーバＭ１の過負荷状態が解消されるようなサーバ組み替え計画が作成される。

３−１．第１の実施例
図１１は、第１の実施例に係るサーバ組替支援システムの構成を示すブロック図である。図１１において、サーバ組替支援システムは、運用情報入力モジュール１０、資源容量入力モジュール２０、解除状況推定モジュール３０、割当計画作成モジュール４０、及び出力モジュール５０を備えている。また、解除状況推定モジュール３０は、過負荷解消モジュール３１を含んでいる。

図１２は、第１の実施例におけるサーバ組み替え計画の作成処理を示すフローチャートである。図１３は、既出の図７で示された運用状態に対する処理例を示している。図１１〜図１３を参照して、第１の実施例におけるサーバ組み替え計画の作成処理を説明する。

ステップＳ１０：
運用情報入力モジュール１０は、記憶装置（後述される）から、図８及び図９で示された運用データＤＰ、ＤＶを読み込む。これにより、サーバ組替支援システムは、現在の割り当て関係Ａ（ｉ）＝ｊ、仮想サーバの資源使用量Ｗ（ｉ）、及び物理サーバの現在の資源使用量Ｘ（ｊ）を取得する。運用情報入力モジュール１０は、運用データＤＰ、ＤＶ（Ａ（ｉ）＝ｊ、Ｗ（ｉ）、Ｘ（ｊ））を解除状況推定モジュール３０に出力する。

ステップＳ２０：
資源容量入力モジュール２０は、記憶装置（後述される）から、図１０で示された容量データＤＤを読み込む。これにより、サーバ組替支援システムは、物理サーバの資源容量Ｕ（ｊ）を取得する。資源容量入力モジュール２０は、容量データＤＤ（Ｕ（ｊ））を解除状況推定モジュール３０及び割当計画作成モジュール４０に出力する。

ステップＳ３０：
解除状況推定モジュール３０は、運用データＤＰ、ＤＶ及び容量データＤＤを参照して、物理サーバの中から過負荷サーバを抽出し、また、仮想サーバの中から解除サーバを決定する。

より詳細には、過負荷解消モジュール３１は、現在の資源使用量Ｘ（ｊ）及び資源容量Ｕ（ｊ）を参照して、負荷が資源容量Ｕ（ｊ）を超過している過負荷サーバ［ｊ＝１］を抽出する。更に、過負荷解消モジュール３１は、その過負荷サーバに割り当てられている仮想サーバ［ｉ＝０、３、５、８］の少なくとも一部を解除サーバとして選択する（ステップＳ３１）。このとき、過負荷解消モジュール３１は、仮想サーバの資源使用量Ｗ（０）、Ｗ（３）、Ｗ（５）、Ｗ（８）、過負荷サーバの資源使用量Ｘ（１）及び資源容量Ｕ（１）を参照することにより、資源使用量Ｘ（１）が資源容量Ｕ（１）以下となるように解除サーバを選択することができる。具体的には、過負荷解消モジュール３１は、過負荷状態が解消されるまで、所定の方針に従って、仮想サーバ［ｉ＝０、３、５、８］から解除サーバを１つずつ選択していく。その方針としては、ランダム、仮想サーバの資源使用量Ｗ（ｉ）の大きい順（降順）、あるいは小さい順（昇順）が挙げられる。

例えば、資源使用量Ｗ（ｉ）の大きい順で解除サーバが選択される場合、比較的少ない解除サーバ数で、過負荷状態が解消されると考えられる。言い換えれば、解除サーバの総数が抑えられる。これは、実際にサーバ組み替えを実施する際に仮想サーバの移行数が抑えられるという観点から、好適である。

一方、資源使用量Ｗ（ｉ）の小さい順で解除サーバが選択される場合、実際のサーバ組み替え時には資源使用量Ｗ（ｉ）が比較的小さな仮想サーバが移行されることになる。ある仮想サーバｉの資源使用量Ｗ（ｉ）が小さいことは、その仮想サーバｉを利用しているユーザが少ないことを意味する。上述の通り、仮想サーバの移行はそれなりのリスクを伴い、また、仮想サーバの移行の間はサービスの提供が停止する。従って、資源使用量Ｗ（ｉ）が比較的小さな仮想サーバを優先的に移行させることは、その移行に伴うリスクや影響を最小限に抑えるという観点から、好適である。更に、解除サーバの資源使用量Ｗ（ｉ）が小さい場合、その解除サーバを現在空きのある物理サーバに割り当てやすくなる。つまり、新たな物理サーバを追加することなく、現行の物理サーバだけでサーバ組み替えに対応できる確率が高まる。このようなことから、資源使用量Ｗ（ｉ）の小さい順で解除サーバを選択することも、好適である。

本実施例では、昇順が採用されるとする。すなわち、過負荷サーバ［ｊ＝１］の資源使用量Ｘ（１）が資源容量Ｕ（１）以下となるまで、資源使用量Ｗ（ｉ）の小さい順で解除サーバが１つずつ選択される。

図１３を参照して、過負荷サーバ［ｊ＝１］に現在割り当てられている仮想サーバ［ｉ＝０、３、５、８］のうち最も資源使用量Ｗ（ｉ）が小さいのは、仮想サーバ［ｉ＝３］である。従って、まず最初に、仮想サーバ［ｉ＝３］が、解除サーバｉ’として選択される。解除サーバ［ｉ’＝３］が解除される場合、資源使用量Ｘ（１）は、資源使用量Ｗ（３）だけ減少し、８０（＝８５−５）となる。しかしながら、依然として過負荷状態が解消されないので、次の解除サーバが更に選択される。次に資源使用量Ｗ（ｉ）が小さいのは、仮想サーバ［ｉ＝０、８］である。ここでは、仮想サーバ［ｉ＝０］が解除サーバｉ’として選択されるとする。解除サーバ［ｉ’＝０］が更に解除されると、資源使用量Ｘ（１）は８０から６０に減少する。これにより、過負荷状態が解消されると予測される。

このように、過負荷解消モジュール３１は、仮想サーバ［ｉ＝３、０］を解除サーバとして選択する。また、過負荷解消モジュール３１は、それら解除サーバが過負荷サーバ［ｊ＝１］から解除されたときの資源使用量Ｘ（１）を算出（推定）し、資源使用量Ｘ（１）の値を８５から６０に変更する。そして、過負荷解消モジュール３１は、選択された解除サーバの資源使用量Ｗ（ｉ’）及び変更後の資源使用量Ｘ（ｊ）を、割当計画作成モジュール４０に出力する。

ステップＳ４０：
割当計画作成モジュール４０は、解除サーバの資源使用量Ｗ（ｉ’）、物理サーバの変更後の資源使用量Ｘ（ｊ）及び資源容量（Ｕ（ｊ）、Ｕ）を受け取る。そして、割当計画作成モジュール４０は、解除サーバの資源使用量Ｗ（ｉ’）及び物理サーバの資源容量の残量を参照して、解除サーバの割り当てを再度決定する。ここで、物理サーバの資源容量の残量とは、資源容量Ｕ（ｊ）と資源使用量Ｘ（ｊ）との差Ｕ（ｊ）−Ｘ（ｊ）である。解除サーバの割り当て手順は、第１節で説明された手順（図３〜図５参照）と同じである。すなわち、解除サーバの割り当ては、その資源使用量Ｗ（ｉ’）の大きい順（降順）で決定される。また、資源使用量Ｗ（ｉ’）のより大きな解除サーバが、残量Ｕ（ｊ）−Ｘ（ｊ）のより小さな物理サーバに割り当てられる。

図１３を参照して、解除サーバ［ｉ’＝３］の資源使用量Ｗ（３）は５であり、解除サーバ［ｉ’＝０］の資源使用量Ｗ（０）は２０である。この場合、上述の配列Ｓは、Ｓ＝［０，３］で表される（Ｓ（ｋ＝０）＝０、Ｓ（ｋ＝１）＝３）。従って、ｉ’＝０、３の順で、割り当てが決定される。

また、物理サーバの変更後の資源使用量Ｘ（０）、Ｘ（１）、Ｘ（２）は、それぞれ６０、６０、５５である。よって、資源容量の残量は、それぞれ１０（ｊ＝０）、１０（ｊ＝１）、１５（ｊ＝２）となっている。この場合、上述の配列Ｔは、Ｔ＝［０，１，２］で表される（Ｔ（ｌ＝０）＝０、Ｔ（ｌ＝１）＝１、Ｔ（ｌ＝２）＝２）。従って、比較処理の対象は、ｊ＝０、１、２の順で選択される。

まず、解除サーバ［ｉ’＝０］の割り当て処理が実施される。このとき、資源使用量Ｗ（０）は、いずれの物理サーバの残量よりも大きい。従って、新たな物理サーバ［ｊ＝３］が追加される。追加される物理サーバ［ｊ＝３］の資源容量Ｕ（３）はデフォルト値（＝７０）であり、その資源使用量Ｘ（３）は初期値（＝０）である。解除サーバ［ｉ’＝０］は、物理サーバ［ｊ＝３］に割り当てられる（Ａ’（０）＝３）。その結果、資源使用量Ｘ（３）は２０となる。

次に、解除サーバ［ｉ’＝３］の割り当て処理が実施される。このとき、資源使用量Ｗ（３）は、物理サーバ［ｊ＝０］の残量以下である。従って、解除サーバ［ｉ’＝３］は、物理サーバ［ｊ＝０］に割り当てられる（Ａ’（３）＝０）。その結果、資源使用量Ｘ（０）は６５（＝６０＋５）となる。

このようにして、割当計画作成モジュール４０は、現行の割り当て関係Ａ（ｉ）＝ｊの一部だけを変更し、新たな割り当て関係Ａ’（ｉ）＝ｊを作成する。第１の実施例では、仮想サーバ［ｉ＝０］の割り当て先が、物理サーバ［ｊ＝１］から物理サーバ［ｊ＝３］に変更され、仮想サーバ［ｉ＝３］の割り当て先が、物理サーバ［ｊ＝１］から物理サーバ［ｊ＝０］に変更される。従って、実際のサーバ組み替え時には、２つの仮想サーバ［ｉ＝０、３］の移行だけで、物理サーバ［ｊ＝１］の過負荷状態が解消される。

尚、物理サーバ［ｊ＝０］と物理サーバ［ｊ＝１］とで、資源容量の残量は同じであった。従って、上述の配列Ｔは、Ｔ＝［０，１，２］の代わりに、Ｔ＝［１，０，２］であってもよい。その場合、解除サーバ［ｉ’＝３］は、元々の物理サーバ［ｊ＝１］に割り当てられることになる（Ａ’（３）＝１）。従って、実際のサーバ組み替え時には、１つの仮想サーバ［ｉ＝０］の移行だけで、物理サーバ［ｊ＝１］の過負荷状態が解消される。

ステップＳ５０：
出力モジュール５０は、割当計画作成モジュール４０によって作成された割り当て計画（Ａ’（ｉ）＝ｊ）を受け取る。そして、出力モジュール５０は、作成された割り当て計画を参照して、サーバ組み替えに有用な情報を示す組替計画データＰＬＡＮを出力装置（後述される）に出力する。例えば、組替計画データＰＬＡＮは、割り当て計画の他に、必要な物理サーバの台数ｎや、組み替え後の資源使用量Ｘ（ｊ）の予測値などを示していてもよい。これらサーバ組み替えに有用な情報がサーバ組み替え計画であり、例えば表示装置に表示される。例えば、本実施例では、解除サーバのＩＤ、解除サーバの移行先、必要な物理サーバの台数、新たな物理サーバの追加が必要である旨等が表示装置に表示される。

以上に説明されたように、第１の実施例で作成されるサーバ組み替え計画によれば、仮想サーバの必要最小限の移行（組み替え）によって、過負荷状態を解消することができる。その結果、サーバ組み替え時のリスクやサービス停止期間が大幅に低減される。

３−２．第２の実施例
図１４は、第２の実施例に係るサーバ組替支援システムの構成を示すブロック図である。第２の実施例に係るサーバ組替支援システムは、第１の実施例における構成に加えて、解除数入力モジュール６０を備えている。また、解除状況推定モジュール３０は、過負荷解消モジュール３１に加えて指定数解除モジュール３２を含んでいる。

図１５は、第２の実施例におけるサーバ組み替え計画の作成処理を示すフローチャートである。図１６は、既出の図７で示された運用状態に対する処理例を示している。図１４〜図１６を参照して、第２の実施例におけるサーバ組み替え計画の作成処理を説明する。第１の実施例と重複する説明は、適宜省略される。

ステップＳ１０、ステップＳ２０は、第１の実施例と同じである。

ステップＳ６０：
解除数入力モジュール６０は、パラメータｒを取得する。後述されるように、このパラメータｒは、解除状況推定モジュール３０が解除サーバを選択するにあたって参照するパラメータであり、以下「解除数ｒ」と参照される。解除数ｒは、例えばユーザによって指定される。解除数入力モジュール６０は、解除数ｒを解除状況推定モジュール３０に通知する。本例では、解除数ｒは１であるとする。

ステップＳ３０：
ステップＳ３１は、第１の実施例と同じである。すなわち、過負荷解消モジュール３１は、過負荷サーバ［ｊ＝１］を抽出し、その過負荷サーバに割り当てられている仮想サーバ［ｉ＝０、３］を解除サーバとして選択する。資源使用量Ｘ（１）の値は、８５から６０に変更される。

一方、指定数解除モジュール３２は、過負荷サーバ以外の物理サーバ［ｊ＝０、２］の各々に関して、指定された解除数ｒの仮想サーバを選択する（ステップＳ３２）。このときも、所定の方針に従って、仮想サーバが１つずつ選択される。その方針としては、ランダム、仮想サーバの資源使用量Ｗ（ｉ）の大きい順（降順）、あるいは小さい順（昇順）が挙げられる。本実施例では、指定数解除モジュール３２は、資源使用量Ｗ（ｉ）を参照し、資源使用量Ｗ（ｉ）の小さい順（昇順）で仮想サーバを選択するとする。指定数解除モジュール３２によって選択された仮想サーバも、解除サーバとして扱われる。すなわち、指定数解除モジュール３２は、過負荷サーバ以外に割り当てられている仮想サーバからもいくつかの仮想サーバを選択し、選択された仮想サーバを解除サーバとして更に追加する。

図１６を参照して、物理サーバ［ｊ＝０］に現在割り当てられている仮想サーバ［ｉ＝１、２、６］のうち最も資源使用量Ｗ（ｉ）が小さいのは、仮想サーバ［ｉ＝２］である。従って、指定数解除モジュール３２は、仮想サーバ［ｉ＝２］を選択し、解除サーバとして追加する。解除数ｒは１であるため、物理サーバ［ｊ＝０］に関する処理は終了する。資源使用量Ｘ（０）は、６０から５０に変更される。

同様に、物理サーバ［ｊ＝２］に現在割り当てられている仮想サーバ［ｉ＝４、７、９］のうち最も資源使用量Ｗ（ｉ）が小さいのは、仮想サーバ［ｉ＝７］である。従って、指定数解除モジュール３２は、仮想サーバ［ｉ＝７］を選択し、解除サーバとして追加する。資源使用量Ｘ（２）は、５５から５０に変更される。

このように、本実施例において解除状況推定モジュール３０によって選択される解除サーバは、ｉ’＝０、２、３、７の４種類である。解除状況推定モジュール３０は、解除サーバ［ｉ’＝０、２、３、７］の資源使用量Ｗ（ｉ’）及び変更後の資源使用量Ｘ（ｊ）を、割当計画作成モジュール４０に出力する。

尚、過負荷サーバ［ｊ＝１］に関しては、過負荷解消モジュール３１が既に、２つの仮想サーバ［ｉ＝０、３］を選択している。指定数解除モジュール３２は、それ以上の選択を行わなくてもよい。あるいは、指定数解除モジュール３２は、ｒ個の仮想サーバを過負荷サーバから更に選択してもよい。

ステップＳ４０：
第１の実施例と同様に、割当計画作成モジュール４０は、解除サーバの割り当てを再度決定する。このときの処理対象は、解除状況推定モジュール３０によって選択された全ての解除サーバ［ｉ’＝０、２、３、７］である。

図１６を参照して、資源使用量Ｗ（０）、Ｗ（２）、Ｗ（３）、Ｗ（７）はそれぞれ２０、１０、５、５である。この場合、上述の配列Ｓは、Ｓ＝［０、２、３、７］で表される。従って、ｉ’＝０、２、３、７の順で、割り当てが決定される。

また、物理サーバの変更後の資源使用量Ｘ（０）、Ｘ（１）、Ｘ（２）は、それぞれ５０、６０、５０である。よって、資源容量の残量は、それぞれ２０（ｊ＝０）、１０（ｊ＝１）、２０（ｊ＝２）となっている。この場合、上述の配列Ｔは、Ｔ＝［１，０，２］で表される。従って、比較処理の対象は、ｊ＝１、０、２の順で選択される。

まず、解除サーバ［ｉ’＝０］の割り当て処理が実施される。このとき、資源使用量Ｗ（０）は、物理サーバ［ｊ＝０］の残量以下である。従って、解除サーバ［ｉ’＝０］は、物理サーバ［ｊ＝０］に割り当てられる（Ａ’（０）＝０）。その結果、資源使用量Ｘ（０）は、７０（＝５０＋２０）となる。

次に、解除サーバ［ｉ’＝２］の割り当て処理が実施される。このとき、資源使用量Ｗ（２）は、物理サーバ［ｊ＝１］の残量以下である。従って、解除サーバ［ｉ’＝２］は、物理サーバ［ｊ＝１］に割り当てられる（Ａ’（２）＝１）。その結果、資源使用量Ｘ（１）は、７０（＝６０＋１０）となる。

次に、解除サーバ［ｉ’＝３］の割り当て処理が実施される。このとき、資源使用量Ｗ（３）は、物理サーバ［ｊ＝２］の残量以下である。従って、解除サーバ［ｉ’＝３］は、物理サーバ［ｊ＝２］に割り当てられる（Ａ’（３）＝２）。その結果、資源使用量Ｘ（２）は、５５（＝５０＋５）となる。

最後に、解除サーバ［ｉ’＝７］の割り当て処理が実施される。このとき、資源使用量Ｗ（７）は、物理サーバ［ｊ＝２］の残量以下である。従って、解除サーバ［ｉ’＝７］は、物理サーバ［ｊ＝２］に割り当てられる（Ａ’（７）＝２）。その結果、資源使用量Ｘ（２）は、６０（＝５５＋５）となる。

このように、仮想サーバ［ｉ＝０］の割り当て先が、物理サーバ［ｊ＝１］から物理サーバ［ｊ＝０］に変更され、仮想サーバ［ｉ＝２］の割り当て先が、物理サーバ［ｊ＝０］から物理サーバ［ｊ＝１］に変更され、仮想サーバ［ｉ＝３］の割り当て先が、物理サーバ［ｊ＝１］から物理サーバ［ｊ＝２］に変更される。仮想サーバ［ｉ＝７］の割り当て先は、物理サーバ［ｊ＝２］のまま変わらない。従って、実際のサーバ組み替え時には、３つの仮想サーバ［ｉ＝０、２、３］の移行だけで、物理サーバ［ｊ＝１］の過負荷状態が解消される。

以上に説明されたように、第２の実施例で作成されるサーバ組み替え計画によれば、少ない移行数で過負荷状態を解消することができる。その移行数は、第１の実施例よりも若干多くなるが、第１節で説明された技術だけを単に適用した場合に比べれば抑制される。従って、サーバ組み替え時のリスクやサービス停止期間が低減される。

一方で、第２の実施例によれば、第１の実施例と異なり、新たな物理サーバ［ｊ＝３］は追加されない。すなわち、再割り当て処理後の物理サーバの総台数が、第１の実施例よりも少なくなっている。これは、指定数解除モジュール３２によって解除サーバが更に選択されたからである。過負荷状態の解消に要する物理サーバの総台数が抑制されることは、サーバ組み替えに要するコストが低減されることを意味する。第２の実施例では、仮想サーバの移行数の低減と、必要な物理サーバの総台数の抑制の両立が可能であると言える。

３−３．第３の実施例
図１７は、第３の実施例に係るサーバ組替支援システムの構成を示すブロック図である。第３の実施例に係るサーバ組替支援システムは、第２の実施例における構成に加えて、解除数指定モジュール７０を備えている。また、解除数入力モジュール６０の代わりに、同様の機能を提供する解除数入力モジュール６０ａが用いられる。第２の実施例と重複する説明は、適宜省略される。

第２の実施例と同様に、解除数入力モジュール６０ａは、解除数を取得する。但し、第３の実施例では、解除数入力モジュール６０ａは、解除数ｒの最大値である「最大解除数Ｒ」を取得する。最大解除数Ｒは、０以上の整数であり、例えばユーザによって指定される。

解除数指定モジュール７０は、解除状況推定モジュール３０に対し、複数種類の値を順番に解除数ｒとして指定する。このとき、解除数指定モジュール７０は、最大解除数Ｒを参照して、０〜最大解除数Ｒの範囲内で解除数ｒを１つずつ指定していく。例えば、解除数指定モジュール７０は、解除数ｒを、０から順番に最大解除数Ｒまで増加させていく。

ある解除数ｒが指定されると、解除状況推定モジュール３０、割当計画作成モジュール４０、及び出力モジュール５０は、第２の実施例と同じ処理を行う。つまり、解除数ｒが指定される度に、上述のステップＳ３０、Ｓ４０、Ｓ５０が実施される。例えば最大解除数Ｒが３の場合、解除数ｒは０、１、２、３のそれぞれに設定されるため、ステップＳ３０〜Ｓ５０は４回繰り返される。結果として、４種類のサーバ組み替え計画が作成されることになる。ユーザは、作成された複数のサーバ組替計画の中から最適なものを選択することが可能となる。

図１８は、第３の実施例におけるサーバ組み替え計画の作成処理を示すフローチャートである。図１７及び図１８を参照して、第３の実施例におけるサーバ組み替え計画の作成処理の一例を説明する。本例では、最大解除数Ｒは１であるとする。

ステップＳ１０、ステップＳ２０は、既出の実施例と同じである。ステップＳ６０ａにおいて、解除数入力モジュール６０ａは、最大解除数Ｒを取得する。続いて、解除数指定モジュール７０は、解除数ｒを初期値０に初期化する（ステップＳ７１）。

解除数ｒ＝０の条件の下、ステップＳ３０〜Ｓ５０が実施される。このときの処理は、第１の実施例で説明された例と実質的に同じである（図１３参照）。従って、第１の実施例の場合と同じサーバ組み替え計画が作成される。

次に、解除数指定モジュール７０は、解除数ｒに１をインクリメントする（ステップＳ７２）。解除数ｒ（＝１）は最大解除数Ｒ（＝１）を超えていない（ステップＳ７３；Ｎｏ）。従って、解除数ｒ＝１の条件の下、ステップＳ３０〜Ｓ５０が実施される。このときの処理は、第２の実施例で説明された例と実質的に同じである（図１６参照）。従って、第２の実施例の場合と同じサーバ組み替え計画が作成される。

次に、解除数指定モジュール７０は、解除数ｒに１を更にインクリメントする（ステップＳ７２）。解除数ｒ（＝２）は最大解除数Ｒ（＝１）を超えているため（ステップＳ７３；Ｙｅｓ）、処理は終了する。

以上に説明されたように、第３の実施例によれば、解除数ｒは、複数の値に順番に設定される。その結果、複数種類のサーバ組み替え計画の一覧が作成される。ユーザは、仮想サーバの移行数、必要な物理サーバの総台数、コスト等を比較検討し、最適なサーバ組み替え計画を容易に選択することができる。

４．システム構成
以上に説明された実施例に係る構成及び処理は、コンピュータシステムにより実現可能である。図１９は、サーバ組み替えを支援するサーバ組替支援システム１の一例を示している。サーバ組替支援システム１は、コンピュータシステムであり、例えば管理サーバ上に構築される。

図１９において、サーバ組替支援システム１は、プロセッサ２、記憶装置３、入力装置４、出力装置５、ネットワークインタフェース８、メディアドライブ９を備えている。プロセッサ２はＣＰＵを含み、各種処理を行い、また、各装置や各デバイスの動作を制御する。記憶装置３として、ＲＡＭやハードディスクが例示される。入力装置４として、キーボードやマウスが例示される。出力装置５は、表示装置６やプリンタ７を含んでいる。ユーザは、表示装置６に表示される情報を参照しながら、入力装置４を用いて各種データやコマンドを入力することができる。

記憶装置３には、運用データＤＰ、ＤＶ、容量データＤＤ等が格納される。それらデータは、入力装置４により入力されてもよいし、ネットワークインタフェース８を介して提供されてもよい。または、それらデータは、コンピュータ読み取り可能な記録媒体に記録され、メディアドライブ９によって読み込まれてもよい。

記憶装置３には更に、組替計画作成プログラムＰＲＯが格納される。組替計画作成プログラムＰＲＯは、プロセッサ２によって実行されるソフトウェアである。組替計画作成プログラムＰＲＯは、例えば、コンピュータ読み取り可能な記録媒体に記録されており、メディアドライブ９によって読み込まれる。あるいは、組替計画作成プログラムＰＲＯは、ネットワークインタフェース８を介して提供されてもよい。

プロセッサ２は、組替計画作成プログラムＰＲＯを実行することによって、上述の実施例に係る組み替え計画の作成処理を実現する。すなわち、プロセッサ２と組替計画作成プログラムＰＲＯとの協働により、運用情報入力モジュール１０、資源容量入力モジュール２０、解除状況推定モジュール３０、割当計画作成モジュール４０、出力モジュール５０、解除数入力モジュール６０、６０ａ、及び解除数指定モジュール７０が提供される。

各モジュールは必要なデータを、記憶装置３から読み出す、入力装置４から受け取る、あるいは他のモジュールから受け取る。例えば、運用情報入力モジュール１０は、運用データＤＰ、ＤＶを記憶装置３から読み出す。解除数入力モジュール６０は、解除数ｒあるいは最大解除数Ｒを入力装置４から受け取る。そして、それぞれのモジュールが、上述の実施例で説明された処理をそれぞれ実行する。その結果、サーバ組み替え計画を示す組替計画データＰＬＡＮが作成される。作成された組替計画データＰＬＡＮは、記憶装置３に格納され、また、出力装置５によって出力される。例えば、組替計画データＰＬＡＮは、表示装置６に表示される。ユーザは、出力されたサーバ組み替え計画を参照して、サーバの組み替えを実施することができる。

５．変形例
作成されたサーバ組み替え計画に従って、コンピュータが自動的に、サーバ組み替えを実施してもよい。例えば図２０に示されるように、組替モジュール８０は、割当計画作成モジュール４０によって作成された割り当て計画に従って、仮想サーバの組み替え（移行）を実際に実行する。

図２１は、図２０の場合のシステム構成例を示している。図１９で示された構成と同様の構成には同じ符号が付され、重複する説明は省略される。記憶装置３には更に、組替プログラムＰＲＯ２が格納される。組替プログラムＰＲＯ２は、プロセッサ２によって実行されるソフトウェアである。組替プログラムＰＲＯ２は、例えば、コンピュータ読み取り可能な記録媒体に記録されており、メディアドライブ９によって読み込まれる。あるいは、組替プログラムＰＲＯ２は、ネットワークインタフェース８を介して提供されてもよい。プロセッサ２と組替プログラムＰＲＯ２との協働により、図２０で示された組替モジュール８０が提供される。

組替プログラムＰＲＯ２（組替モジュール８０）は、例えば、ヴィエムウェア株式会社（ＶＭｗａｒｅ Ｉｎｃ．）が提供する「ＶＭｗａｒｅ（登録商標） ＶＭｏｔｉｏｎ（商標）」によって実現可能である（http://www.vmware.com/ja/products/vi/vc/vmotion.html、http://www.vmware.com/products/vi/vc/vmotion.htmlを参照）。また、組替プログラムＰＲＯ２は、上述の組替計画作成プログラムＰＲＯと一体で提供されてもよい。

以上、本発明の実施の形態が添付の図面を参照することにより説明された。但し、本発明は、上述の実施の形態に限定されず、要旨を逸脱しない範囲で当業者により適宜変更され得る。

本出願は、２００７年９月１８日に出願された日本国特許出願２００７−２４０９６４を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (21)

1. 複数の物理サーバに割り当てられている複数の仮想サーバの組み替えを支援するサーバ組替支援システムであって、
   前記複数の物理サーバ及び前記複数の仮想サーバの運用状態を示す運用データと、前記複数の物理サーバのそれぞれの資源容量を示す容量データとが格納される記憶手段と、
   前記運用データ及び前記容量データを参照して、前記複数の物理サーバのうち負荷が前記資源容量に応じた閾値を超過している過負荷サーバを抽出し、前記複数の仮想サーバのうち前記過負荷サーバに割り当てられている仮想サーバの少なくとも一部が解除サーバとして解除されたときの状況を推定する解除状況推定手段と、
   前記推定された状況に基づいて、前記解除サーバの割り当て計画を作成する割当計画作成手段と
   を備える
   サーバ組替支援システム。
2. 請求の範囲１に記載のサーバ組替支援システムであって、
   前記運用データは、
   前記複数の物理サーバと前記複数の仮想サーバとの割り当て関係を示すデータと、
   前記複数の仮想サーバのそれぞれの資源使用量を示すデータと
   を含み、
   前記複数の物理サーバのうちある物理サーバの負荷は、前記ある物理サーバに割り当てられている仮想サーバの前記資源使用量の合計であり、
   前記解除状況推定手段は、前記資源使用量及び前記資源容量を参照して、前記過負荷サーバの負荷が前記閾値以下となるように前記解除サーバを決定し、前記解除サーバが解除されたときの前記複数の物理サーバのそれぞれの負荷を推定し、
   前記割当計画作成手段は、前記推定された負荷、前記資源容量、及び前記解除サーバの前記資源使用量に基づいて、前記割り当て計画を作成する
   サーバ組替支援システム。
3. 請求の範囲２に記載のサーバ組替支援システムであって、
   前記解除状況推定手段は、前記過負荷サーバの負荷が前記閾値以下となるまで、前記資源使用量の小さい順で、前記過負荷サーバに割り当てられている仮想サーバから前記解除サーバを１つずつ選択する
   サーバ組替支援システム。
4. 請求の範囲２又は３に記載のサーバ組替支援システムであって、
   前記解除状況推定手段は、前記複数の物理サーバのうち前記過負荷サーバ以外の各々に関して、指定された解除数の仮想サーバを選択し、前記選択された仮想サーバを前記解除サーバとして更に追加し、前記複数の物理サーバから前記解除サーバが解除されたときの前記複数の物理サーバのそれぞれの負荷を推定する
   サーバ組替支援システム。
5. 請求の範囲４に記載のサーバ組替支援システムであって、
   前記解除状況推定手段は、前記指定された解除数の仮想サーバを、前記資源使用量の小さい順で１つずつ選択する
   サーバ組替支援システム。
6. 請求の範囲４又は５に記載のサーバ組替支援システムであって、
   更に、複数の値を順番に前記解除数として指定する解除数指定手段を備え、
   前記解除数が指定される度に、前記解除状況推定手段は前記指定された解除数を参照して処理を行い、前記割当計画作成手段は前記割り当て計画を作成する
   サーバ組替支援システム。
7. 請求の範囲２乃至６のいずれか一項に記載のサーバ組替支援システムであって、
   前記割当計画作成手段は、前記複数の物理サーバの前記資源容量と前記推定された負荷に基づいて、前記複数の物理サーバのそれぞれの前記資源容量の残量を算出し、
   前記割当計画作成手段は、前記残量と前記解除サーバの前記資源使用量を参照して、前記解除サーバの割り当てを決定し、前記割り当て計画を作成する
   サーバ組替支援システム。
8. 請求の範囲７に記載のサーバ組替支援システムであって、
   前記割当計画作成手段は、前記解除サーバの割り当てを前記資源使用量の降順で決定する
   サーバ組替支援システム。
9. 請求の範囲８に記載のサーバ組替支援システムであって、
   前記割当計画作成手段は、前記資源使用量の降順で前記解除サーバを１つずつ選択し、前記複数の物理サーバのうちいずれかを選択し、前記選択された解除サーバの前記資源使用量である対象使用量と前記選択された物理サーバの前記残量との比較を行い、
   前記対象使用量が前記残量より大きい場合、前記割当計画作成手段は、前記選択された物理サーバとは別の物理サーバを選択した後、前記比較を再度行い、
   前記対象使用量が前記残量以下の場合、前記割当計画作成手段は、前記選択された解除サーバを前記選択された物理サーバに割り当てる
   サーバ組替支援システム。
10. 請求の範囲９に記載のサーバ組替支援システムであって、
    前記割当計画作成手段は、前記複数の物理サーバから前記比較の対象を、前記残量の昇順で選択する
    サーバ組替支援システム。
11. 請求の範囲９又は１０に記載のサーバ組替支援システムであって、
    前記対象使用量が前記複数の物理サーバのいずれの前記残量よりも大きい場合、前記割当計画作成手段は、前記選択された解除サーバを、前記複数の物理サーバとは異なる物理サーバに割り当てる
    サーバ組替支援システム。
12. 請求の範囲１乃至１１のいずれか一項に記載のサーバ組替支援システムであって、
    更に、前記作成された割り当て計画を表示する表示手段を備える
    サーバ組替支援システム。
13. 請求の範囲１乃至１１のいずれか一項に記載のサーバ組替支援システムであって、
    更に、前記作成された割り当て計画に従って前記複数の仮想サーバの組み替えを実施する組替手段を更に備える
    サーバ組替支援システム。
14. コンピュータを利用することにより、複数の物理サーバに割り当てられている複数の仮想サーバの組み替えを支援するサーバ組替支援方法であって、
    前記複数の物理サーバ及び前記複数の仮想サーバの運用状態を示す運用データを、記憶手段から読み出すステップと、
    前記複数の物理サーバのそれぞれの資源容量を示す容量データを、記憶手段から読み出すステップと、
    前記運用データ及び前記容量データを参照して、前記複数の物理サーバのうち負荷が前記資源容量に応じた閾値を超過している過負荷サーバを抽出するステップと、
    前記複数の仮想サーバのうち前記過負荷サーバに割り当てられている仮想サーバの少なくとも一部が解除サーバとして解除されたときの状況を推定するステップと、
    前記推定された状況に基づいて、前記解除サーバの割り当て計画を作成するステップと
    を含む
    サーバ組替支援方法。
15. 請求の範囲１４に記載のサーバ組替支援方法であって、
    前記運用データは、
    前記複数の物理サーバと前記複数の仮想サーバとの割り当て関係を示すデータと、
    前記複数の仮想サーバのそれぞれの資源使用量を示すデータと
    を含み、
    前記複数の物理サーバのうちある物理サーバの負荷は、前記ある物理サーバに割り当てられている仮想サーバの前記資源使用量の合計であり、
    前記状況を推定するステップは、
    前記資源使用量及び前記資源容量を参照して、前記過負荷サーバの負荷が前記閾値以下となるように前記解除サーバを決定するステップと、
    前記解除サーバの前記資源使用量を参照して、前記解除サーバが解除されたときの前記複数の物理サーバのそれぞれの負荷を推定するステップと
    を含み、
    前記割り当て計画を作成するステップは、
    前記推定された負荷、前記資源容量、及び前記解除サーバの前記資源使用量に基づいて、前記割り当て計画を作成するステップ
    を含む
    サーバ組替支援方法。
16. 請求の範囲１５に記載のサーバ組替支援方法であって、
    前記解除サーバを決定するステップにおいて、前記過負荷サーバの負荷が前記閾値以下となるまで、前記資源使用量の小さい順で、前記過負荷サーバに割り当てられている仮想サーバから前記解除サーバが１つずつ選択される
    サーバ組替支援方法。
17. 請求の範囲１５又は１６に記載のサーバ組替支援方法であって、
    前記解除サーバを決定するステップは、
    前記過負荷サーバの負荷が前記閾値以下となるように前記解除サーバを決定するステップと、
    前記複数の物理サーバのうち前記過負荷サーバ以外の各々に関して、指定された解除数の仮想サーバを選択するステップと、
    前記選択された仮想サーバを前記解除サーバとして更に追加するステップと
    を含む
    サーバ組替支援方法。
18. 請求の範囲１５乃至１７のいずれか一項に記載のサーバ組替支援方法であって、
    前記割り当て計画を作成するステップは、
    前記複数の物理サーバの前記資源容量と前記推定された負荷に基づいて、前記複数の物理サーバのそれぞれの前記資源容量の残量を算出するステップと、
    前記残量と前記解除サーバの前記資源使用量を参照して、前記解除サーバの割り当てを決定し、前記割り当て計画を作成するステップと
    を含む
    サーバ組替支援方法。
19. 請求の範囲１８に記載のサーバ組替支援方法であって、
    前記解除サーバの割り当てを決定するステップにおいて、前記解除サーバの割り当ては、前記資源使用量の降順で決定される
    サーバ組替支援方法。
20. 請求の範囲１４乃至１９のいずれか一項に記載のサーバ組替支援方法であって、
    更に、前記作成された割り当て計画を表示手段で表示するステップを含む
    サーバ組替支援方法。
21. 複数の物理サーバに割り当てられている複数の仮想サーバの組み替えを支援するサーバ組替支援プログラムが記録されたコンピュータ読み取り可能な記録媒体であって、
    前記サーバ組替支援プログラムは、
    前記複数の物理サーバ及び前記複数の仮想サーバの運用状態を示す運用データを、記憶手段から読み出すステップと、
    前記複数の物理サーバのそれぞれの資源容量を示す容量データを、記憶手段から読み出すステップと、
    前記運用データ及び前記容量データを参照して、前記複数の物理サーバのうち負荷が前記資源容量に応じた閾値を超過している過負荷サーバを抽出するステップと、
    前記複数の仮想サーバのうち前記過負荷サーバに割り当てられている仮想サーバの少なくとも一部が解除サーバとして解除されたときの状況を推定するステップと、
    前記推定された状況に基づいて、前記解除サーバの割り当て計画を作成するステップと、
    をコンピュータに実行させる
    記録媒体。

Images