JP2012141671A - 仮想計算機の移動方法、仮想計算機システム及び管理サーバ - Google Patents

Abstract

【課題】仮想計算機の移動のオーバヘッドとネットワーク機器の負荷変動を考慮して、ネットワーク機器を含めた計算機システム全体の消費電力を削減する。
【解決手段】物理計算機へ割り当てる仮想計算機を制御する管理サーバは、移動対象の前記仮想計算機と仮想計算機の移動先の候補となる物理計算機を選択する移動先判定部と、移動先の候補として選択された物理計算機について、選択した仮想計算機を移動させるのに必要な第１電力量を演算し、移動先の候補として選択された物理計算機へ仮想計算機を移動させた後に削減される第２電力を演算し、仮想計算機を移動させた後に削減される第２電力が、第１電力量と等しくなる第１の時間を演算する負荷予測部と、を備え、移動先判定部は、移動先の候補としての物理計算機へ仮想計算機を移動させた後に稼動可能な第２の時間を演算し、第２の時間が第１の時間を超える物理計算機を仮想計算機の移動先として決定する。
【選択図】図３

Description

本発明は、サーバ、ストレージ、ネットワークより構成されるデータセンタ及びデータセンタ間を結ぶ広域ネットワークの運用管理に係り、特に、データセンタと広域ネットワークの統合的な省電力運用管理を行うのに好適な技術に関する。

近年、ＩＣＴ（Information and Communication Technology）システムの処理量の増大や高速化に伴い、データセンタ内のサーバ、ストレージ、ネットワーク装置及びデータセンタ間を結ぶ広域ネットワーク（ＷＡＮ等）を構成するネットワーク装置の消費電力が急激に増大している。

このような消費電力の増大に対処するため、データセンタ内のＩＴ機器と給電設備及び冷却設備の消費電力の総和を低減するように、ＩＴ機器へ作業負荷を割り当てる手法が提案されている（例えば、特許文献１）。上記従来技術では、データセンタ全体の消費電力の総和を目的関数とし、ＩＴ機器等の装置群へ作業負荷（仮想計算機または業務）を割り当てる組み合わせの最適化問題を定義し、前記目的関数を最小化する詰め込み問題（ビンパッキング問題）を解くことにより、目的関数を最小化する最適解または最適解近傍の実行可能な近似解を求めてデータセンタ全体の消費電力を低減させる。

特開２００９−２５２０５６号公報

上記従来例では、データセンタ内のサーバ（物理計算機）に割り当てる仮想計算機（業務）を最適化するが、データセンタ間をまたがった仮想計算機の割り当てについて最適化は行われない。そのため、上記従来例では、データセンタ間を結ぶネットワークの消費電力は削減されず、また、サーバに割り当てる仮想計算機の最適化に際して、ネットワーク機器の帯域を考慮することはない。

しかし、近年の調査結果によれば、ＩＣＴシステムの消費電力の約半分は、ＷＡＮのルータ等のネットワーク機器の消費電力が占めることが指摘されており、ネットワーク機器の消費電力を削減することは今後必須の課題である。さらに、今後適用範囲が広がると予想されるクラウドコンピューティングにおいては、データセンタ間にまたがった業務が広く行われるようになると予想される。したがって、ネットワークをまたがったデータセンタ間での業務の広域割り当ての最適化により、個々のデータセンタ内の仮想計算機への業務の割り当ての最適化だけでは達成できないレベルの、さらなる消費電力低減を実現するとともに、ネットワーク機器の消費電力を削減することが今後は求められる。上記を実現するためには、サーバに割り当てる仮想計算機の配置を最適化する業務配置最適化において、ネットワーク機器の稼働状況、消費電力を考慮する必要がある。

さらに、近年の仮想化技術の発達により、上記業務配置最適化を行う際の、物理サーバ間での業務の移動は仮想計算機（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ、以下ＶＭとする）のマイグレーションにより実現されるが、ＶＭのマイグレーションに伴うオーバヘッド（主記憶や、ディスク領域のコピー等に伴う消費電力増大）に関しても考慮する必要がある。

上記マイグレーション処理では、ＶＭの主記憶、ディスク領域のコピーが必要になる。特に、マイグレーション先の物理計算機がＷＡＮにより接続された環境では、上記コピー処理に伴うネットワーク装置を経由した通信で余計な電力が発生し、上記従来の業務の配置最適化による電力削減効果を減少させる。さらに、上記従来の業務の配置最適化によって多数のＶＭのマイグレーションが必要な場合、ＶＭのマイグレーションの完了までに時間がかかり、計算機システムが消費電力の少ない適正な業務の配置で運用を始めるまでの時刻が遅れ、業務の配置適正化の効果を減少させる。さらに、マイグレーションが余りに頻発する場合、マイグレーションに伴う電力増大が、マイグレーションの結果削減される電力削減効果を上回る危険性がある。

上記従来技術では、上記ＶＭの移動に伴うオーバヘッドは考慮されていない。つまり、ＶＭマイグレーションによる電力消費の増大と適正な業務の配置を実現するまでの時間の遅延からなるオーバヘッドについて、上記従来技術では検討されていない、という問題があった。

特に、従来の主流である、上記詰め込み問題により業務の最適配置を求める場合には、現在迄の業務の配置の連続性は考慮されず、結果として、ＶＭのマイグレーションが頻発する配置を生成する危険性がある。

ＶＭのマイグレーション先を検討する場合、該当するＶＭの将来のリソース使用量予測値と、マイグレーション先の将来のリソース使用量予測値の合計が、物理リソースの限界値を超えないようにする必要がある。例えばリソース使用量として、ネットワークトラヒックを考えた場合、該当するＶＭが移動したことにより、各物理サーバの出口のＮＩＣのみならず、各仮想サーバに割り当てられた仮想ＮＩＣ、データセンタ内のネットワーク回線、データセンタ出口の回線のトラヒックが増える可能性があるため、何れの部分もボトルネックにならないことを確かめる必要がある。ネットワーク使用量の予測値は時々刻々変化するため、ＶＭを移行した後、しばらくの間ネットワーク使用量は帯域（実効通信速度の最大値）以下であるが、将来のある時点でネットワーク使用量が帯域を超えると予想される場合がある。そのような場合でも、ネットワーク使用量がネットワークの帯域を超えない時間が長く、消費電力を十分節約できるならば、該当する物理サーバにＶＭを一時的に移動させることにより、消費電力を節約できる。例えば、ＶＭの負荷の変動で夜間にトラヒックが減る場合が該当する。

これに対して、ＶＭをマイグレーションした直後に負荷変動によりネットワーク使用量が帯域を超えてしまい、仮想サーバに割り当てる業務の配置を元に戻さなければならない場合は、マイグレーションによる電力節約は小さく、場合によっては、マイグレーションに要する電力が上回ってしまうため、該当するＶＭの移動を行うことで消費電力が増大するため得策ではない。このように、ＶＭのマイグレーション先の決定には、ＶＭの負荷の変動を考慮して、該当するＶＭのマイグレーションにより、データセンタ内のトータルでどれだけ電力を削減できるかを考慮する必要がある。従来の業務の最適配置を適用する計算機システムでは、負荷の状況を固定された時間範囲で判定していたため、上記のように変動する物理サーバの負荷に対して効率よく対処することができなかった。

本発明は、業務を提供する仮想計算機を物理サーバ間で移動させて消費電力を低減させる際に、仮想計算機の移動のオーバヘッドを考慮し、かつ、ネットワーク機器の負荷変動を考慮し、ネットワーク機器を含めた計算機システム全体の消費電力を削減することが可能な制御方法の提供を目的とする。

本発明は、プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記複数の物理計算機を接続するネットワーク機器と、前記複数の物理計算機を管理する管理サーバとを備えて、前記物理計算機で１つ以上の仮想計算機を提供する仮想化部を実行し、前記管理サーバが前記複数の物理計算機の消費電力を低減するように前記物理計算機へ割り当てる前記仮想計算機を制御する仮想計算機の移動方法であって、前記管理サーバが、移動対象の前記仮想計算機を選択する第１のステップと、前記管理サーバが、前記選択した仮想計算機の移動先の候補となる物理計算機を選択する第２のステップと、前記管理サーバが、前記移動先の候補として選択された物理計算機について、前記選択した仮想計算機を移動させるのに必要な第１の電力量を演算する第３のステップと、前記管理サーバが、前記移動先の候補として選択された物理計算機について、前記選択した仮想計算機を移動させた後に削減される第２の電力を演算する第４のステップと、前記管理サーバが、前記選択した仮想計算機を移動させた後に削減される第２の電力に時間を乗じた第２の電力量が、前記第１の電力量と等しくなる第１の時間を演算する第５のステップと、前記管理サーバが、前記移動先の候補として選択された物理計算機で、前記選択した仮想計算機を移動させた後に稼動可能な第２の時間を演算する第６のステップと、前記管理サーバが、前記第２の時間が前記第１の時間を超える物理計算機を、前記選択した仮想計算機の移動先として決定する第７のステップと、を含む。

したがって、本発明は、仮想計算機の移動の結果削減される消費電力量だけでなく、仮想計算機の移動に必要となる消費電力量を求め、仮想計算機の移動によりネットワーク機器を含めた計算機システムのトータルの消費電力量が削減される場合に限り、処理の移動を行うと判定する。これにより、無駄な処理の移動を行うことを防止することができる。

本発明の実施形態を示し、データセンタの計算機システムのブロック図である。 本発明の実施形態を示し、管理サーバのブロック図である。 本発明の実施形態を示し、データセンタの計算機システムで仮想計算機の移動を行った場合の通信経路の変化を示すブロック図である。 本発明の実施形態を示し、管理サーバで行われる負荷の収集処理の一例を示すフローチャートである。 本発明の実施形態を示し、管理サーバで行われるＶＭ移動先判定処理の一例を示すフローチャートである。 本発明の実施形態を示し、仮想サーバの移動に伴う消費電力の収支を判定する一例を示すグラフである。 本発明の実施形態を示し、ネットワーク機器の負荷変動を考慮して仮想計算機の移動後に運用可能な時間を判定する例を示すための説明図である。 本発明の実施形態を示し、図５の移動先判定処理の詳細を示すフローチャートである。 本発明の実施形態を示し、モニタリング情報の一例を示す説明図である。 本発明の実施形態を示し、ネットワーク管理テーブルの一例を示す説明図でマイグレーション前の状態を示す。 本発明の実施形態を示し、ネットワーク管理テーブルの一例を示す説明図でマイグレーション後の状態を示す。 本発明の実施形態を示し、サーバ１の構成の一例を示すブロック図である。 本発明の実施形態を示し、負荷予測値の一例を示す説明図である。 本発明の実施形態を示し、仮想サーバ割当テーブルの一例を示す説明図である。 本発明の第２の実施形態を示し、複数のデータセンタの計算機システムのブロック図である。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、本発明の実施形態を示し、本発明を適用するデータセンタ内の計算機システムの構成の一例を示すブロック図である。

本発明はデータセンタ間での仮想計算機（業務）の移動先判定に適用できるが、仮想計算機（以下、仮想サーバ）の移動先の判定はデータセンタ内での仮想サーバの移動にも適用可能である。第一の実施形態では、説明を簡易にするために、データセンタ１００内についての仮想サーバの移動について説明する。なお、本実施形態では、一つの仮想サーバが一つの業務またはサービスを提供するため、アプリケーションまたはサービスあるいはデーモンを実行する例を示し、以下の説明では、仮想サーバの移動を業務の移動とする。

図１において、１００はデータセンタ、５０はＷＡＮ、１０〜１１はクライアントである。データセンタ１００の中では、１４０はデータセンタ１００の入口のルータ、１５０〜１５４はデータセンタ内のスイッチ、１１０〜１１８はサーバである。サーバ（物理計算機）１１０〜１１８はルータ１４０、スイッチ１５０〜１５４を介してＷＡＮ５０及びクライアント１０，１１に接続される。

データセンタ１００内にはさらに、サーバ１１０〜１１８を管理する管理サーバ１２０と、管理サーバ１２０との間で入出力を行う管理者端末１９０が設置される。管理サーバ１２０は、管理者端末１９０から受け付けた指令に応じてサーバ１１０〜１１８や仮想計算機を制御する。

各サーバ１１０〜１１８内では業務の提供を行う仮想サーバ（以下ではＶＭ（Ｖｉｒｔｕａｌ Ｓｅｒｖｅｒ）と呼ぶ）１１０ａ、１１０ｂ、１１１ａ、１１１ｂ、１１２ａ、１１２ｂ、１１３ａ、１１６ｂ、１１７ａ、１１７ｂが実行される。サーバ１１０〜１１８やルータ１４０、スイッチ１５０〜１５４、ＶＭ１１０ａ〜１１７ｂは、図１の構成だけでなく、任意の台数、構成をとることが可能である。

管理サーバ１２０内には、データセンタ１００内の計算機システムの構成情報１２１と、データセンタ１００内のネットワーク機器（ルータ１４０、スイッチ１５０〜１５４）やサーバ１１０〜１１８及びＶＭ１１０ａ〜１１７ｂより収集した稼働情報のレポジトリであるモニタリング情報１２２をメモリ（主記憶）に格納する。管理サーバ１２０は、管理ネットワーク１２０ａを介してサーバ１１０〜１１８、スイッチ１５０〜１５４及びルータ１４０に接続され、稼動情報を取得する。サーバ１１０〜１１８は、スイッチ１５０〜１５４、ルータ１４０及びＷＡＮ５０を介してクライアント（（クライアント計算機）１０、１１に接続され、サーバ１１０〜１１８はクライアント１０、１１からの要求に応じてサービスや業務を提供する。

なお、図１において、ルータ１４０やスイッチ１５０〜１５４のｐ０〜ｐ３はそれぞれポート番号０〜３を示すものである。

図２は管理サーバ１２０の構成の一例を示すブロック図を示す。管理サーバ１２０は、上述した構成情報１２１やモニタリング情報１２２を記憶するストレージ１２６と、演算処理を行うＣＰＵ１３０と、ＣＰＵ１３０と主記憶やインタフェースを接続するチップセット１２３と、管理ネットワーク１２０ａに接続されるＮＩＣ（ネットワークインタフェースカード）１２５と、データやプログラムを格納する主記憶１２４を主体にして構成される計算機である。

構成情報１２１は、サーバの物理構成（ＣＰＵの性能やメモリ、ストレージの容量）等の基本的な情報を格納する構成情報テーブル（図示省略）と、サーバ（物理計算機）１１０〜１１８の識別子と、仮想サーバ１１０ａ〜１１７ｂの識別子の対応関係を管理する仮想サーバ割り当てテーブル１２１０を含む。なお、構成情報１２１は、管理サーバ１２０のＶＭ管理プログラム（ＶＭ管理部）１２９が管理する。

主記憶１２４内には、各サーバ１１０〜１１８やルータ１４０の負荷値を収集する負荷値収集プログラム１２８と、本発明の移動先判定プログラム（移動先判定部）１２７と、移動先判定プログラム１２７の判定結果に基づき、各サーバ１１０〜１１８に割り当てられたＶＭ１１０ａ〜１１７ｂをサーバ１１０〜１１８に移動させるＶＭ管理プログラム（ＶＭ管理部）１２９と、収集されたモニタリング情報１２２に基づき将来の各機器（サーバ１１０〜１１８やスイッチ１５０〜１５４またはルータ１４０）の負荷を予測する負荷予測プログラム（負荷予測部）１３１が格納され、ＣＰＵ１３０で実行される。

ここで、サーバ１１０〜１１８やネットワーク機器の負荷を監視する負荷値収集プログラム１２８（負荷モニタ部）は公知または周知の技術を適用することができるので、ここでは詳述しない。この負荷値の収集処理は、例えば、ＳＮＭＰマネージャ等の手段により、各スイッチ１５０〜１５４やサーバ１１０〜１１８の稼働状況を表すモニタリングデータを収集することができる。

サーバ１１０〜１１８の物理資源を仮想サーバ１１０ａ〜１１７ｂに割り当てるＶＭ管理プログラム１２９（仮想化管理部）は、公知または周知の技術を用いることができる。仮想化管理部としては、ハイパーバイザやＶＭＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）の管理ソフトウェアを利用すればよいので、ここでは詳述しない。また、仮想サーバ１１０ａ〜１１７ｂを他のサーバ（物理計算機）に移動させるＶＭマイグレーション処理は、公知または周知の技術を採用すればよいので、ここでは詳述しない。ＶＭマイグレーションを実行するプログラムが各社より提供されている。例えば、ＶＭｗａｒｅ社の提供するＶＣｅｎｔｅｒ等のプログラムにより、ＶＭ１１０ａ〜１１７ｂやＶＭの使用するデータをサーバ間で移動させることができる。

負荷予測プログラム１３１（負荷予測部）も公知または周知の技術を用いることができる。例えば、ＡＲＩＭＡモデル（Autoregressive Integrated Moving Average：自己回帰和分移動平均モデル）等を用いて過去の負荷の値の履歴から将来の値を予測するプログラムが各社より提供されている（例えば、ＩＢＭ社のＳＰＳＳ等が例である）。本実施形態では、負荷予測の処理について公知または周知の技術を採用するので、詳細についての説明は省略する。

主記憶１２４にはさらに、負荷予測プログラム１３１により予測された、将来のサーバ１１０〜１１８やネットワーク機器の稼働状況を表す負荷予測値リポジトリ１３１ａと、仮想サーバ１１０ａ〜１１７ｂの通信経路の構成情報を示すネットワーク管理テーブル１２７ａが格納される。ネットワーク管理テーブル１２７ａは、ＶＭの移動時の各機器の稼働状況を判定するために管理サーバ１２０が使用する。

なお、管理サーバ１２０で実行される各プログラムは、ストレージ１２６に保持され、必要に応じて主記憶１２４へロードされる。ストレージ１２６は、これらプログラムの記憶媒体として機能される。

図１０は、サーバ１１０の構成の一例を示すブロック図である。サーバ１１０は、演算処理を行うＣＰＵ２００と、主記憶２０２やインタフェース２０４とＣＰＵ２００を接続するチップセット２０１と、ＷＡＮ５０や管理ネットワーク１２０ａに接続されるＮＩＣ（ネットワークインタフェースカード）２０３と、データやプログラムを格納する主記憶２０２を主体にして構成される物理計算機である。インタフェース２０４にはデータ２１１やプログラム２１２を保持するストレージ２１０が接続される。なお、ストレージ２１０は、各サーバ１１０〜１１８がアクセス可能な共有ストレージとして機能することができる。

主記憶２０２には、サーバ１１０の物理資源を複数の仮想サーバ（仮想計算機）に割り当てる仮想化部２２０が格納され、ＣＰＵ２００によって実行される。図１０の例では、仮想化部２２０が２つの仮想サーバ１１０ａ、１１０ｂを実行させる例を示す。仮想サーバ１１０ａでは、ＯＳ１６０ａが実行され、ＯＳ１６０ａ上でアプリケーション１７０ａが実行されクライアント１０，１１に業務（またはサービス）を提供する。仮想サーバ１１０ｂでは、ＯＳ１６０ｂが実行され、ＯＳ１６０ｂ上でアプリケーション１７０ｂが実行されクライアント１０，１１に業務（またはサービス）を提供する。

ここで、仮想化部２２０としては、例えば、ハイパーバイザやＶＭＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）を採用することができる。仮想化部２２０は、管理サーバ１２０からの指令に応じて仮想サーバ１１０ａ〜１１７ｂの生成、移動、削除を行う。また、仮想化部２２０は、管理サーバ１２０の負荷値収集プログラム１２８から稼動情報を要求された場合には、図８に示した仮想サーバ１１０ａ、１１０ｂのフロー毎のトラヒック量と、各仮想サーバ１１０ａ、１１０ｂのＯＳ１６０ａが検知したＣＰＵの使用率と、ＣＰＵ２００の使用率を稼動情報として応答することができる。

図１２は、管理サーバ１２０のＶＭ管理プログラム１２９が管理する仮想サーバ割当テーブル１２１０の一例を示す説明図である。ＶＭ管理プログラム１２９は、サーバ（物理計算機）１１０〜１１８の物理リソースを割り当てた仮想サーバ１１０ａ〜１１７ｂに対する割り当て量等を管理する。

仮想サーバ割当テーブル１２１０は、物理計算機の識別子を格納する物理計算機ＮＯ１２１１と、仮想サーバの識別子を格納する仮想計算機ＮＯ１２１２と、仮想サーバに割り当てたプロセッサの量を格納する割当プロセッサ量１２１３と、仮想サーバに割り当てたメモリの量を格納する割当メモリ量１２１４と、仮想サーバに割り当てたストレージの量を格納する割当ストレージ量１２１５と、仮想サーバで実行するアプリケーションの識別子を格納するアプリケーションＮＯ１２１６とからひとつのエントリが構成される。

管理サーバ１２０のＶＭ管理プログラム１２９は、仮想サーバの生成、移動、削除を行う際に、仮想サーバ割当テーブル１２１０を更新する。

図３は、図１の計算機システムにおいて、本発明のＶＭ移動先判定により、サーバ１１０〜１１８間で業務を提供するＶＭをマイグレーションさせることにより、計算機システム全体の消費電力を低減する手法を示す説明図である。

図３のＰ０〜ｐ３は、図１と同様に、各スイッチ１５０〜１５４、及びルータ１４０で入出力を行うｐｏｒｔ番号を記す。ここでは例として、サーバ４（１１３）で稼動しているＶＭ１１３ａをサーバ７（１１６）のＶＭ１１６ａにマイグレーションさせる場合について示す。

上記マイグレーションにより、サーバ４（１１３）で稼動するＶＭが無くなり、該サーバはアイドル状態になるので、電源を遮断したり、省電力モードに移行させたりすることが可能になり、計算機システムの消費電力を制限することができる。さらに、スイッチ４（１５２）に接続されたサーバ１１０３〜１１５ではＶＭが稼動していないため、通信も発生していない。このため、電源の遮断や省電力モードに移行したサーバが接続されたポートについても、電源の遮断や省電力モードへの移行を実施することで、さらなる消費電力の削減を図ることができる。なお。スイッチ等のネットワーク機器の省電力制御については、例えば、特開２００９−３３６９１号公報などの公知の技術を用いればよい。

ここで、ＶＭ１１２ａは、ネットワークを介してサーバ１（１１０）で稼動するＶＭ１１０ａ、及びクライアント１０と通信を行っている。ＶＭマイグレーション前の通信経路に関して、ＶＭ１１０ａとＶＭ１１３ａの通信経路（フロー）を太実線９０と二点鎖線９１で示し、ＶＭ１１３ａとクライアント１０の通信経路を太実線９５と、一点鎖線９６で示す。

これに対して、ＶＭ１１６ａのマイグレーション後には、上記通信経路の一部が太点線９０，９５を経由するようになる。具体的にはＶＭ１１０ａとＶＭ１１６ａのフローに関しては、二点鎖線９１の代わりに太点線９２を、クライアント１０とＶＭ１１６ａのフローに関しては、一点鎖線９６の代わりに破線９７を経由するようになる。したがって、新しくフローが経由するルータ１４０、スイッチ１５３、１５４のトラヒック量は増加する一方、スイッチ４（１５２）、スイッチ１（１５０）のトラヒック量は減少することになる。

図８は、モニタリング情報の一例を示す説明図である。図８は、本発明におけるモニタリング情報１２２において、ネットワークフロー毎のトラヒック量を管理サーバ１２０がモニタリングした結果の一例を示す。

管理サーバ１２０の負荷値収集プログラム１２８は、各フロー（ソースＩＰアドレス、デスティネーションＩＰアドレスの組み合わせ）毎に、一定時間毎（図の例では１０秒毎）のトラヒックを測定し、主記憶１２４のモニタリング情報１２２に蓄積する。このモニタリング情報１２２のデータをもとに、負荷予測プログラム１３１は将来の稼働状況を予測する。

モニタリング情報１２２は、送信元のＩＰアドレスを格納するＳｏｕｒｃｅＩＰ１２２１と、宛先のＩＰアドレスを格納するｄｅｓｔＩＰ１２２２と、ＳｏｕｒｃｅＩＰ１２２１とｄｅｓｔＩＰ１２２２間のトラヒック量を各時間毎に格納するモニタリング結果１２２３−１〜１２２３−ｎから一つのエントリが構成される。なお、図示の例では、説明を簡易にするため、ＩＰアドレスに代わって、計算機の識別子を格納した例を示す。モニタリング結果１２２３−１〜１２２３−ｎは、上記一定時間毎のトラヒック量をそれぞれ格納する。トラヒック量は、例えば、単位時間当たりのデータ量（例えば、Ｍｂｐｓ）で表現する。なお、トラヒック量は、この他、一定時間毎のデータ量の平均値や、最大値などで表すようにしてもよい。なお、本実施形態では、管理サーバ１２０が仮想サーバ１１０ａ〜１１７ｂ毎にＩＰアドレスを割り当てるものとするが、管理者端末１９０から手動でＩＰアドレスを設定するようにしても良い。また、ＳｏｕｒｃｅＩＰ１２２１と、ｄｅｓｔＩＰ１２２２は送信元と宛先が特定できればよいので、ＩＰアドレスの他に、ＭＡＣアドレス（または仮想ＭＡＣアドレス）やＷＷＮ等一意の識別子を用いるようにしてもよい。

このモニタリング情報１２２は、管理サーバ１２０とネットワーク機器により、公知または周知のモニタリング技術を用いて測定される。あるいは、各サーバ１１０〜１１８の仮想化部２２０が収集したトラヒック量を、管理サーバ１２０の負荷値収集プログラム１２８が取得するようにしてもよい。また、モニタリング情報１２２が、各仮想サーバ１１０ａ〜１１７ｂの稼動情報の場合には、ｄｅｓｔＩＰ１２２２をブランクとして、仮想サーバ１１０ａ〜１１７ｂ上のＯＳ１６０ａが検知したＣＰＵの使用率を各時間毎のモニタリング結果１２２３−１〜１２２３−ｎに格納すればよい。また、モニタリング情報１２２が、各サーバ１１０〜１１８の稼動情報の場合には、ｄｅｓｔＩＰ１２２２をブランクとして、各仮想化部２２０が検知したＣＰＵ２００の使用率を各時間毎のモニタリング結果１２２３−１〜１２２３−ｎに格納すればよい。

図９Ａ、図９Ｂは、ネットワーク管理テーブル１２７ａの一例を示す説明図である。図９Ａは、マイグレーション前の状態を示し、図９Ｂは、マイグレーション後の状態を示す。

ネットワーク管理テーブル１２７ａは、各フロー（ソースＩＰアドレス、デスティネーションＩＰアドレスの組み合わせ）毎に、当該フローが経由する通信機器及び通信機器のポートを表す。このネットワーク管理テーブル１２７ａは、管理サーバ１２０によって管理される。ネットワーク管理テーブル１２７ａは、送信元のＩＰアドレスを格納するＳｏｕｒｃｅＩＰ１２７１と、宛先のＩＰアドレスを格納するｄｅｓｔＩＰ１２７２と、ＳｏｕｒｃｅＩＰ１２７１とｄｅｓｔＩＰ１２７２間の通信経路のネットワーク機器のポートの識別子を格納するポート１２７３−１〜１２７３−ｎから一つのエントリが構成される。なお、図示の例では、ＩＰアドレスに代わって、計算機の識別子を格納した例を示す。

ネットワーク管理テーブル１２７ａは、マイグレーション前のフローと、マイグレーション後のフローがどのように変化したかを示すことができる。

ネットワーク管理テーブル１２７ａは、公知または周知のシステム構成管理技術により作成することができる。

ネットワーク管理テーブル１２７ａを管理者端末１９０を利用する管理者などが参照することにより、各ネットワークフローがデータセンタ１００内のどこのネットワーク機器を経由しており、ＶＭ１１０ａ〜１１７ｂをマイグレーションさせることにより、フローの経由するネットワーク機器がどのように変化するかを知ることができる。

図３に示したマイグレーションで、ＶＭ１１３a（マイグレーション後はＶＭ１１６a）とＶＭ１１０ａとの通信フローについて説明すると、マイグレーション前ではＶＭ１１３ａとＶＭ１１０ａ間のフローが、スイッチ３、スイッチ１、スイッチ４を経由するのに対し、マイグレーション後ではＶＭ１１６ａとＶＭ１１０ａ間のフローがスイッチ３、スイッチ１、ルータ、スイッチ２、スイッチ５を経由するようになる（表の中に示されているｐｏｒｔ番号は、図３においての各スイッチ、ルータに示されているポート番号である）。図９Ｂにおいて、マイグレーション後の表における網かけ部がマイグレーション前と異なる部分である。したがって、網かけを行った部分に関しては、トラヒックが新たに増える可能性があるため、本発明の方法にしたがって、マイグレーション後のトラヒック量がハードウェアの限界を超えない期間を判定し、ＶＭの移動後にどれだけの時間まで運用可能であるかの判定が必要である。

＜管理サーバの処理＞
以下では、本発明によるＶＭの移動先判定の処理を図４、図７のフローチャートを用いて説明する。

図４Ａ、図４Ｂに、管理サーバ１２０で行われる処理の全体のフローチャートを示す。管理サーバ１２０は、図４Ａに示すフローチャートを所定の短い周期（例えば、１０秒毎）で実行し、図４Ｂで示すフローチャートを定期的（もしくは必要に応じて）実行し、データセンタ１００内の計算機システム全体の消費電力が削減できるように、計算機システム内のＶＭの配置を適正化する。なお、図４Ｂのフローチャートを実行する周期は、例えば１０分などとする。

管理サーバ１２０は先ず、ステップ１００１において、負荷値収集プログラム１２８により、管理ネットワーク１２０ａを介して、データセンタ１００内に設置された、各サーバ、スイッチ、ルータの稼働情報を収集し、ストレージ１２６上にモニタリング情報１２２として記憶する。収集されたデータは図８で示したように、各ＶＭ１１０ａ〜１１７ｂのＣＰＵ使用率、各ネットワークフロー（ソースＩＰ、デスティネーションＩＰの組）のトラヒック量である。収集されるデータの一例を図８に示す。図８では、ネットワーク上のフロー毎にトラヒック量の時系列変化を記録した例を示している。

ここで注意しなければならないことは、負荷値の収集を行う図４Ａのフローチャートと、図４Ｂで行われるフローチャートの実行周期は異なり、図４Ｂのステップ１００２〜１００４の処理が行われる期間に、複数の時刻のデータが収集されることである。例えば、図４ＢのＶＭ配置判定の処理が１０分に一回行われる場合でも、図８に示すように、図４Ａの負荷値収集処理は例えば１０秒毎に実行される。その理由は、一般にＶＭのマイグレーションには数十秒〜数分かかるため、配置判定を短い周期で行っても、短い周期に追従したシステム構成の変更を行うことは困難である。それに対して、負荷値の収集においては、負荷の細かい変動に伴うジッタ等の影響を考慮してＶＭの配置判定を行うために、ある程度細かい時間間隔で負荷値をモニタリングする必要があるからである。

ステップ１００１で負荷値を収集した後、管理サーバ１２０は、所定の周期（１０分毎）になると図４Ｂの処理を開始する。管理サーバ１２０は、図４Ｂのステップ１００２において、図４Ａの処理で蓄積されたモニタリング情報１２２に基づき、負荷予測プログラム１３１を起動して、上述のＡＲＩＭＡモデルなどを用いて、時系列データである負荷値のパターンを特定し、特定したパターンをモデル化して、将来の負荷値を予測し、主記憶上の負荷予測値リポジトリ１３１ａに格納する。

負荷予測値リポジトリ１３１ａのデータ形式は、図８のモニタリング情報１２２と同じく、各ＶＭのＣＰＵ使用率や、各ネットワークフローのトラヒック量の未来の時系列変化を、所定時間間隔（例えば、１０秒）毎に求めたテーブルである。

図１１は、負荷予測値リポジトリ１３１ａの一例を示す説明図である。負荷予測値リポジトリ１３１ａは、送信元のＩＰアドレスを格納するＳｏｕｒｃｅＩＰ１３１１と、宛先のＩＰアドレスを格納するｄｅｓｔＩＰ１３１２と、ＳｏｕｒｃｅＩＰ１３１１とｄｅｓｔＩＰ１３１２間のトラヒック量の予測値を各時間毎に格納する予測値１３１３−１〜１３１３−ｎから一つのエントリが構成される。なお、図示の例では、説明を簡易にするため、ＩＰアドレスに代わって、計算機の識別子を格納した例を示す。また、負荷予測値リポジトリ１３１ａが、各仮想サーバ１１０ａ〜１１７ｂの稼動情報の場合には、ｄｅｓｔＩＰ１３１２をブランクとして、仮想サーバ１１０ａ〜１１７ｂ上のＯＳ１６０ａが使用するＣＰＵの使用率を各時間毎の予測値１３１３−１〜１３１３−ｎに格納すればよい。

上記負荷予測値リポジトリ１３１ａを使用して、管理サーバ１２０は、ステップ２００３において移動対象とするべきＶＭ１１０ａ〜１１７ｂを選択する。移動対象となるＶＭは下記の観点で選択される。

（場合１）リソース使用量が限界を超えると予測される場合
例えば、あるＶＭが接続されたネットワークのリンクを流れるトラヒック量が所定の限界値に達していたり、サーバ１１０〜１１８のＣＰＵ使用率が１００％に達する等、負荷予測値リポジトリ１３１ａで予測される負荷値が物理リソースのキャパシティに達する場合、当該物理リソースを使用するＶＭを、物理リソースに空きのあるサーバ（物理計算機）へ移動させる。また、ネットワークリソースが限界に達した場合は、物理リソースの空きがあるスイッチの配下で物理リソースに空きがあるサーバにＶＭを移動させる。この移動はシステムのオーバーロードを避けるため必須である。なお、ネットワークのトラヒック量の限界は、データセンタ１００の管理者などが予め設定したもので、実効通信速度の上限値などに設定される。また、ネットワークのトラヒック量の限界は、ルータ１４０やスイッチ１５０〜１５４等のネットワーク機器のメーカや仕様が異なる場合には、ネットワーク機器間毎にトラヒック量の限界値を設定することができる。

この場合の移動対象とするＶＭは、キャパシティに達する物理リソースを使用しているＶＭである。複数のＶＭが同一の物理リソースを使用している場合は、リソース使用量が小さいＶＭが選択される。

（場合２）リソース使用量が少ない場合
例えば、サーバ１１０〜１１８のリソース使用率（例えば、ＣＰＵ２００の使用率）が予め設定したしきい値より小さい場合、該当するサーバ上で稼働している全ＶＭを、他のリソース使用量に余裕のあるサーバに移動させ、該当するサーバの電源を遮断、もしくは省電力モードに移行させることにより、計算機システム全体の消費電力低減を図る（図３の例において、サーバ４（１１３）に置かれたＶＭ１３３ａをサーバ７（１１６）のＶＭ１１６ａにマイグレーションさせる場合が該当する）。

この場合、移動対象とするＶＭは、該当するリソース使用率が小さいサーバで動作している全てのＶＭである。

本実施形態のＶＭ移動先判定が対象にするのは、上記の場合２において、選択されたＶＭをどのサーバ１１０〜１１８に移動させるかを判定する処理である。場合１におけるＶＭの移動先判定については、後述する変形例で述べる。

図４のステップ１００３で上記の場合２に該当し、移動対象となるＶＭが選択されると、管理サーバ１２０はステップ１００４でＶＭの移動先の判定を行う。ＶＭの移動先の判定の詳細な処理を図７に示す。

図７に示すＶＭ移動先判定処理の説明に先立ち、ＶＭの移動による電力収支について図５を用いて示す。

図５は、複数のサーバで稼動するＶＭをひとつのサーバに集約して消費電力を低減する際の、将来の電力変化の模式図である。横軸は時刻であり、時刻０は現在の（管理サーバがＶＭの移動先を判定する）時刻である。縦軸は計算機システム全体の消費電力であり、全サーバの消費電力と、全ネットワーク機器の消費電力の総和である（データセンタ間の配置最適化を行う場合は、各データセンタの消費電力と、ＷＡＮ上のネットワーク機器の消費電力の総和とすればよい）。

図５において、現在の電力はＷ０とする。ＶＭマイグレーションを行わなかった場合、計算機システムの消費電力はＷ０で推移する。

以下の変数を定義する。

マイグレーションによる配置変更で削減される電力：Ｗｂ
マイグレーションに要する時間：ｔ₀
配置変更トリガ後、ＶＭマイグレーション後の構成で消費電力の低減が実現できる期間（以下、電力削減実現期間とする）：ｔ_f
マイグレーションに要する電力量：Ａ
マイグレーション後に削減できる電力量：Ｂ
マイグレーションの開始から電力削減実現期間ｔ_fまでに削減できる電力量：Ｐｍ
次に、ＶＭの移動により計算機システムの消費電力を削減するには、
Ｐｍ＞０ ………（１）
である必要があり、上記条件式（１）が成立する電力削減実現期間ｔ_fの条件を求める。以下に処理の詳細を述べる。

先ず、マイグレーション基本パラメータを計算する。マイグレーションの内容（マイグレーション対象となるＶＭが使用する主記憶のサイズ、ストレージのサイズ、ＶＭマイグレーションのトラヒックに割り当てる回線スループット）に基づき、下記の基本パラメータを計算する（下記で求める値は近似値である）。

マイグレーションに必要な時間：ｔ₀
ｔ₀＝（Ｃ１×ＶＭ主記憶サイズ＋Ｃ２×ストレージサイズ＋Ｃ３）÷回線スループット
……（２）
マイグレーションに必要な電力量：Ａ
Ａ ＝ Ｃ４×ＶＭ主記憶サイズ＋Ｃ５×ストレージサイズ＋Ｃ６）
×（Ｃ８＋Ｃ７×ネットワーク通信距離） ……（３）
ここで、Ｃ１〜Ｃ７はシステムにより決まる定数である。ｔ₀やＡには、ＶＭの主記憶サイズだけでなく、データを移動するコスト（ストレージサイズ）も含む。また、回線スループットは、データセンタ１００内のネットワークの通信速度の平均値や実効値を用いることができる。あるいは、回線スループットは、ネットワーク機器間毎に予め設定し、複数の回線スループットから最も遅いものを選択してもよい。

マイグレーションの結果削減（省電力化）できる電力：Ｗｂ
Ｗｂ ＝ ｓｈｕｔｄｏｗｎ／省電力モードに移行したサーバの消費電力削減量
− 負荷が増えたサーバの消費電力増加量
＋ Ｃ９ × Σ（各ネットワーク機器のトラヒック削減量） ……（４）
ここでＣ９はシステムにより決まる定数である。最終項のネットワーク機器の電力に関しては、関連する（マイグレーション対象となるＶＭのフローが通過する）全てのネットワーク機器について、電力の収支を計算する必要がある（トラヒックが増える場合は負の値になる）。

上記の基本パラメータを用いて、マイグレーション後の構成で運用しなければならない電力削減実現期間ｔ_fを計算する。先ず、マイグレーションにより削減できる電力量Ｐｍを計算すると、下記で表すことができる（ただしｔ_f ＞ ｔ₀が前提）。

Ｐｍ ＝ Ｂ−Ａ ＝ Ｗｂ×（ｔ_f−ｔ₀）−Ａ ……（５）
ここで、マイグレーションにより電力削減を実現するためには、
Ｐｍ ＞ ０
であるから、
Ｐｍ ＝ Ｂ−Ａ ＝ Ｗｂ×（ｔ_f−ｔ₀）−Ａ ＞ ０ ……（５’）
である必要がある。上記の不等式を解くことにより電力削減実現期間ｔ_fを求めることができる。負荷変動により、ＶＭの移動後の構成で電力削減実現期間ｔ_fの期間が経過するまで運用できないと予想される場合は、ＶＭを移動しても消費電力の削減ができないため、ＶＭの移動を行わない。

一方、負荷変動により、ＶＭの移動後の構成で電力削減実現期間ｔ_fの期間まで運用できると予想される場合は、ＶＭを移動すれば消費電力の削減が可能となるので、ＶＭの移動を実行する。すなわち、
図６にＶＭの移動後の構成でどれだけの期間運用できるかを、負荷変動を考慮して判定する例を示す。図６では、物理的なネットワークリンクのネットワークトラヒックが、物理リソースの限界値に達するか否かを判定する例を示すが、ＣＰＵ使用率が物理リソースの限界値に達するか否かの判定も同様の処理で実施できる。

図６では、移動するＶＭ及び、各移動先候補となるサーバにフローが流れる際に経由するネットワーク機器のリソース使用量の予測値を示す（例えばスイッチのリンクの帯域使用量）。

ここで、図９で述べたように、一般にはＶＭマイグレーション後に新たにフローが経由する機器（図９Ｂの網かけ部）は複数存在する。したがって、ネットワーク使用量のグラフは、一般には一つの移動先候補に対して、（フローが経由する機器ごとに）複数存在する。ネットワークフローが複数の機器を経由する場合、何れか一つの機器がボトルネックになると、システム性能が低下することより、ＶＭの移動後の構成で運用可能な時間は、各ネットワーク機器で求めた運用可能な時間の最小値となる。さらに、ＣＰＵ使用率に関しても同様の評価を行い、ＣＰＵ使用率の方がトラヒック量よりも早くボトルネックになる場合は、ＣＰＵ使用率がボトルネックにならない期間を運用可能な期間ｔ_f1としなければならない。以下では、ＶＭの移動後の構成で、リソースの使用量が限界値に達することなくサーバ１１０〜１１８を運用可能な期間を運用可能期間ｔ_f1と置く。換言すれば、移動対象のＶＭを、移動先の候補となるサーバ（物理計算機）で円滑に稼動可能な期間が運用可能期間ｔ_f1となる。つまり、移動先の候補となるサーバに接続されたネットワーク機器でトラヒック量が限界値に達したり、サーバのＣＰＵ２００の使用率が限界値（１００％）に到達すると、ＶＭで実行するアプリケーション１７０ａのレスポンスが低下する。このため、ＶＭをマイグレーションした後に、円滑な稼動を保証できる期間を運用可能期間ｔ_f1とするのである。そして、マイグレーション後のＶＭは、運用可能期間ｔ_f1を経過すると、管理サーバ１２０によって次に稼動可能なサーバにマイグレーションされる。
図６において、横軸は現在以降の時刻であり、縦軸はネットワーク使用量（例えば、Ｍｂｐｓ）である。図６に示す（Ａ）は、移動対象のＶＭｘが使用するネットワークトラヒック量の予測値２００１を示す。図６に示す（Ｂ）〜（Ｄ）は、移動先候補となるサーバが３つあった場合を示し、各移動先のサーバからのトラヒック量の予測値を示している。

図６に示す（Ｂ）は、移動先候補Ａのサーバ上で稼動するＶＭのトラヒック量の予測値２０１２を示す。そして、移動先候補Ａのサーバ上に移動対象のＶＭｘが使用するトラヒック量の予測値を加えた値が一点鎖線２０１１で示される。

ステップ１００４の移動先判定処理では、管理サーバ１２０の移動先判定プログラム１２７が、移動先候補Ａのサーバ上のＶＭのトラヒック量の予測値２０１２に、移動対象のＶＭｘが使用するトラヒック量の予測値を加えた値（予測値の総和）２０１１が、予め設定したしきい値（限界値）に達するまでの運用可能時間ｔ_f1を求める。管理サーバ１２０は、負荷予測値リポジトリ１３１ａを読み込んで、該当するフローについて各時刻の予測値１３１３−１〜１３１３−ｎを取得し、移動先候補Ａのサーバ上で稼動するＶＭのトラヒック量の予測値２０１２に、移動対象のＶＭｘが使用するトラヒック量の予測値２００１を各時間毎に加算し、所定の限界値に達するまでの運用可能期間をｔ_f1として求める。図６の（Ｂ）の場合、移動先候補Ａのサーバ上に移動対象のＶＭｘをマイグレーションした場合、現在から３時間以降にトラヒック量の予測値の総和が限界値に達する。そこで、管理サーバ１２０は、所定の限界値に達するまでの運用可能期間をｔ_f1を３時間として設定する。

図６の（Ｃ）の場合も上記（Ｂ）と同様であり、移動先候補Ｂのサーバ上のＶＭのトラヒック量の予測値２０２２に、移動対象のＶＭｘが使用するトラヒック量の予測値を加えた値（予測値の総和）２０２１が、予め設定したしきい値（限界値）に達するまでの運用可能期間ｔ_f1を求める。管理サーバ１２０は、現在から２時間以降にトラヒック量の予測値の総和２０２１が限界値に達する。そこで、管理サーバ１２０は、所定の限界値に達するまでの運用可能期間をｔ_f1を２時間として設定する。

図６の（Ｄ）の場合も上記（Ｂ）と同様であり、移動先候補Ｃのサーバ上のＶＭのトラヒック量の予測値２０３２に、移動対象のＶＭｘが使用するトラヒック量の予測値を加えた値（予測値の総和）２０３１が、予め設定したしきい値（限界値）に達するまでの運用可能期間ｔ_f1を求める。管理サーバ１２０は、現在から５時間以降にトラヒック量の予測値の総和２０３１が限界値に達する。そこで、管理サーバ１２０は、所定の限界値に達するまでの運用可能期間をｔ_f1を５時間として設定する。

ＶＭのマイグレーションにより、各移動先候補にＶＭが移動された場合、移動先候補のネットワーク機器の使用量（トラヒック量）は、移動されたＶＭへのフロー（図６の（Ａ）のグラフ）分だけ増える。図６の（Ｂ）〜（Ｄ）で示すように、各移動先候補にフローが流れる際に経由するネットワーク機器のリソース使用量のグラフでは、ＶＭを移動させる前のネットワーク使用量を実線で示し、ＶＭを移動した後のネットワーク使用量を一点鎖線で示す。実線のグラフは、管理サーバ１２０の負荷予測値リポジトリ１３１ａより得られる値である。実線に対して一点鎖線の値は、上記実線のグラフに、図６の（Ａ）に示した移動対象のＶＭのネットワーク使用量（この値も、負荷予測値リポジトリ１３１ａより得られる）を加えた値となる。

ここで、図６の（Ｂ）〜（Ｄ）の各移動先候補の予測値のグラフにおいて、ネットワーク帯域（限界値）を点線で示す。図６の（Ｂ）〜（Ｄ）に示すように、ＶＭマイグレーション後のネットワーク使用量のグラフ（一点鎖線）がネットワーク帯域（限界値）を超えない間は、各移動先候補にＶＭを移動させた後の構成で運用可能である。

したがって、図６の（Ｂ）〜（Ｄ）の例では、運用可能期間ｔ_f1の値は、上述のように移動先候補Ａの場合は３時間、移動先候補Ｂの場合は２時間、移動先候補Ｃの場合は５時間となる。ここで求めた、上記運用可能期間ｔ_f1と、図５で求めた電力削減実現期間ｔ_fを比較することにより、該当する移動先候補のサーバに移動対象のＶＭを移動できるか否かを判定できる。

つまり、
ｔ_f ＜ ｔ_f1 ……（６）
となる移動先候補を選択すればよい。さらに、管理サーバ１２０では、上記（６）式を満たす移動先候補のうち運用可能期間ｔ_f1が最大の移動先候補を選択することで、次回のマイグレーションまでの時間を増大させて、マイグレーションの発生頻度を抑制することができる。

以上の例では、ＶＭの移動後の構成で運用可能な期間を求める判定基準として、リソース使用量が限界値に達するか否かを用いたが、ＶＭ移動後の構成が変更される要因としては、上記の他にも下記が考えられ、運用可能期間ｔ_f1の算出には、下記も考慮する必要がある。

・計算機システムの負荷がさらに減少し、サーバ（物理計算機）をさらに減らせると予想される時刻
・ユーザによりサーバが予約される場合や、管理者によるメンテナンスがスケジューリングされている場合等、システム構成を再度見直す必要がある場合
・その他、サーバ割り当ての変更が必要なことが予め分かっている場合
これらの予定またはスケジュールを加味してマイグレーション後の運用可能期間ｔ_f1を求めるようにしてもよい。

図７は、上記図４Ｂのステップ１００４のＶＭの移動先判定処理の詳細を示すフローチャートである。先ず、管理サーバ１２０は、負荷予測値リポジトリ１３１ａより、移動対象ＶＭのネットワークリソース使用量の予測値を取得する（ステップ１１０１）。

次に、管理サーバ１２０は、上記ステップ１００３で求めたＶＭの移動先探索候補となるサーバ（物理計算機）の集合を取得する（ステップ１１０２）。ＶＭの移動先となるサーバは、基本的にデータセンタ１００内の全サーバを対象とするが、下記の選択条件に従い、ＶＭを移動するのが適切では無いサーバを予め除外する。

・配置の制約に抵触するサーバは除外する
例えば、信頼性（冗長性）向上のため、複数のＶＭを複数のサーバ１１０〜１１８に分散して作成している場合は、これらのＶＭを同一の物理サーバに配置しない。

・レスポンスタイムが長い（ＲＴＴ大）サーバは除外する
移動させるＶＭ上のアプリケーションのレスポンスタイムが確保できなくなるのを回避する。なお、各サーバ１１０〜１１８のレスポンスタイムは、仮想サーバ割り当てテーブル１２１０等の構成情報に設定しておけばよい。

・データ移動量が大きいサーバは除外
大量のデータを使用するデータベースサーバ等を移動することはしない。マイグレーションの際にデータ転送に要する時間が過大となるのを回避する。

移動先候補となるサーバの集合を求めた後、管理サーバ１２０は、ステップ１１０５の処理を、全移動先候補物理サーバに対して実行する。

すなわち、先ず、図５で述べた手順に従って、管理サーバ１２０は、該当するサーバにＶＭを移動させた場合に、ＶＭ移動の電力収支がプラスとなる時間ｔ_fを求める（ステップ１１０５−１）。

さらに、管理サーバ１２０は、負荷予測値リポジトリ１３１ａより、該サーバにＶＭを移動させた場合に、移動対象ＶＭのフローが新たに経由するネットワーク機器のリソース使用量予測値を取得する（ステップ１１０５−２）。ここで、移動対象のＶＭのフローの情報はネットワーク管理テーブル１２７ａより得る。その後、図６で述べた手順に従い、ＶＭの移動後の構成でリソースの使用量が限界値に到達するまでサーバを運用可能な運用可能期間ｔ_f1を求める（ステップ１１０５−３）。

ここで、移動対象のＶＭのフローが新たに経由するネットワーク機器が複数ある場合には、管理サーバ１２０は各々のネットワーク機器に関して運用可能期間ｔ_f1を求め、そのうち最小の値を選択する必要がある（さらに、ＣＰＵ使用率より求めた運用可能期間ｔ_f1も考慮する必要がある）。

運用可能な時間ｔ_f1を求めた後、管理サーバ１２０は、運用可能な時間ｔ_f1と、電力削減実現期間ｔ_fを比較し（ステップ１１０５−４）、運用可能期間ｔ_f1が電力削減実現期間ｔ_fよりも小さい場合はＶＭの移動により電力が削減できないので、該当するサーバにＶＭを移動させることはできないと判定する（ステップ１１０５−７）。一方、運用可能期間ｔ_f1が電力削減実現期間ｔ_fよりも大きい場合には、該当するサーバにＶＭを移動することが可能である（ステップ１１０５−５）。この場合、運用可能期間ｔ_f1まで当該サーバで運用した場合に削減できる電力量Ｐｍ１を、図５で説明した下記の式により求める（ステップ１１０５−６）。

Ｐｍ１ ＝ Ｂ−Ａ ＝ Ｗｂ×（ｔ_f1−ｔ₀）−Ａ ……（７）
全ての移動先候補の物理サーバについて上記の処理（１１０５−１〜１１０５−７）を行った後に、移動可能なサーバが一台もなかった場合は、ＶＭの移動は行われない（ステップ１１０６、１１０８）。一方、移動可能なサーバがあった場合は、各移動先候補のＰｍ１を比較し、Ｐｍ１が最大の移動先候補のサーバにＶＭを移動することを決定する（ステップ１１０７）。

以上の処理により、ネットワークトラヒックの変動状況と、ＶＭマイグレーションによるＶＭの移動による電力収支を考慮してＶＭの移動先を決定することができる。

＜変形例１＞
上記実施形態では、ＶＭの移動の可否を判定する際に、マイグレーションにより削減可能な電力量（Ｂ）と、マイグレーションに必要な電力量（Ａ）の差分が正である（マイグレーションにより少しでも電力が削減できる）ことを判定基準としていた。
Ｐｍ ＝ Ｂ−Ａ ＞ ０ ……（５’）
しかし、上記パラメータ計算の近似計算の誤差や、ＶＭマイグレーションに伴うリスク（何らかの原因でマイグレーションに失敗すると、システムダウンが発生する）を考慮すると、電力削減量が僅少の場合にマイグレーションを行うことは得策ではない。したがって、ＶＭの移動による電力削減量の最小値Ｃを定義し、
Ｐｍ ＝ Ｂ−Ａ ＞ Ｃ ……（８）
の場合のみ、ＶＭのマイグレーションを行う方式が考えられる。これにより、電力削減量がほとんど無いマイグレーションが頻発することを防止することができる。上記定数Ｃはデータセンタ１００内の計算機システムの運用ポリシーにより決定される閾値であり、システム管理者により、管理者端末１９０から入力された値である。

＜変形例２＞
以上の実施形態及び第１の変形例では、ＶＭをひとつのサーバへ集約することによって、消費電力を削減する場合を示したＶＭ移動先判定の処理である（図４ステップ１００３の場合２）。これに対して、計算機システムの負荷が増え、今迄サーバ（物理計算機）一台で行っていたＶＭを複数のサーバに分散する場合等（ステップ１００３の場合１）におけるＶＭの移動先も、本実施形態の手順を応用して判定することができる。

この場合は、処理する機器の台数が増えるので、データセンタ１００内の計算機システムのトータルの消費電力は増大する。したがって、上述の電力削減実現期間ｔ_fによりマイグレーションの可否を判定する部分は適用できない。しかし、各々の移動先候補のサーバについて図７に示したステップ１１０５−６で述べた手順によりサーバで運用した場合に削減できる電力量Ｐｍ１を計算し（Ｐｍ１は負になる）、Ｐｍ１が最大の（絶対値が最小の）サーバにＶＭを移動させることにより、ＶＭの移動に伴う消費電力の増大を最小限に抑えることができる。

あるいは、前記実施形態で、マイグレーション後のＶＭが、運用可能期間ｔ_f1に達した場合も本変形例２によって、再度マイグレーション先を探索することができる。

＜変形例３＞
図１３は、本発明の第３の変形例であり、複数のデータセンタ間でＶＭの配置を判定する場合の計算機システムのブロック図を示す。

以上の実施形態及び第１、第２の変形例は、ひとつのデータセンタ１００内におけるＶＭの移動先の判定方法について述べた。複数のデータセンタにまたがったＶＭの移動先も上記と同様の処理で判定することができる。図１３に全体のアーキテクチャを示す。

図１３において、６００、７００、８００はデータセンタ、５００はＷＡＮ、５１０、５１１はクライアントである。データセンタ６００、７００、８００はＷＡＮ５００を介してクライアント５１０，５１１に接続される。データセンタ６００、７００、８００の構成は前記実施形態の図１と同様の構成である。

データセンタの中では６００を例に述べると、６４０はデータセンタ入口のルータ（データセンタ内スイッチは省略する）、６１０、６１１、６１２はサーバ（物理計算機）、６２０は管理サーバである。各サーバ６１０、６１１、６１２では、業務（またはサービス）をクライアント５１０，５１１に提供する仮想サーバ（以下、ＶＭ）６１０ａ、６１０ｂ、６１１ａ、６１１ｂ、６１２ａ、６１２ｂが実行される。

管理サーバ６２０内には、前記実施形態の図１と同様に構成情報６２１、モニタリング情報６２２を持つ。ＷＡＮ５００の中ではルータ５５１〜５５４が設置され、データセンタ６００、７００，８００やクライアント５１０、５１１を接続する。ＷＡＮ５００にも管理サーバ５２０が置かれる。各データセンタ６００、７００、８００、ＷＡＮ５００の管理サーバ間では、管理サーバ間ネットワーク５９０が配置され、相互にアクセスが可能である。データセンタの各管理サーバ６２０，７２０，８２０は、前記実施形態の図１と同様に、図示しない管理ネットワークを介して各データセンタ内のサーバに接続される。

図１３では、データセンタ２（７００）のＶＭ７１０ａをデータセンタ３（８００）のＶＭ８１０ａに移動させる例を示す。

データセンタ間のＶＭの移動先判定では、基本的には移動対象のＶＭが稼働しているデータセンタの管理サーバが（この例では７２０）が移動先を判定する。データセンタ内のＶＭの移動先判定と比較して、以下が異なる。

各データセンタの管理サーバは、自データセンタ内のサーバ、ネットワーク機器の構成情報（データセンタ２の管理サーバの場合７２１）、モニタリング情報（７２２）を持つ。他のデータセンタに置かれた機器の構成や稼働情報は、管理サーバ間ネットワーク５９０を通じて、他の管理サーバが持っている情報（６２１、６２２、８２１、８２２）にアクセスする。

ＷＡＮ５００に関しては、データセンタとは違うキャリアにより提供されている。したがって、データセンタ６００の管理サーバ６２０が、ＶＭの移動時にＷＡＮ５００の部分で削減可能な電力量を直接求めることは困難である。上記を解決するために、ＷＡＮ５００の部分の消費電力の削減に関しては、ＶＭの移動元の管理サーバ（７２０）がＷＡＮ５００の管理サーバ５２０に問い合わせ、移動させるＶＭのフローの経路が変更になった場合の電力削減量Ｗｂ２を問い合わせるインタフェースをＷＡＮ５００の管理サーバ５２０に設ける。

問い合わせインタフェースの例は下記である。

ｑｕｅｒｙ＿ｐｏｗｅｒ＿ｄｉｆｆｅｒｎｃｅ（ｆｌｏｗ流量、現在のＷＡＮ入口、現在のＷＡＮ出口、ＶＭ移動後のＷＡＮ入口、ＶＭ移動後のＷＡＮ出口）
ＶＭの移動の結果、移動後のＶＭのフローがＷＡＮ５００を経由しなくなった場合は、入口、出口には空の引数（ＮＩＬまたはＮＵＬＬ等）を与える。

図５に示したＶＭの移動によって削減される電力Ｗｂの計算において上記の問い合わせ結果を使用することにより、ブラックボックスであるＷＡＮ５００の部分の電力を考慮したＶＭの移動先判定が可能である。つまり、各データセンタ（７００、８００）内で削減される電力Ｗｂと、通信経路の変更によってＷＡＮ５００で削減される消費電力Ｗｂ２の和に時間ｔ_fを乗じた電力量Ｂが、ＶＭを移動させるための電力量Ａ以上となればよい。

図１３の例では、データセンタ２（７００）のＶＭ７１０ａをデータセンタ３（８００）のサーバ８１０のＶＭ８１０ａに移動させるため、管理サーバ７２０は、データセンタ２（７００）で削減される電力ｗｂ−１を求める。管理サーバ７２０は、データセンタ３（８００）で削減（または増加）する電力Ｗｂ−２を管理サーバ８２０に問い合わせる。さらに、管理サーバ７２０は、ＷＡＮ５００で削減（または増加）する電力Ｗｂ−３を管理サーバ５２０に問い合わせる。そして、管理サーバ７２０は、上記取得した電力Ｗｂ−１〜Ｗｂ−３の総和を、ＶＭの移動により削減される電力Ｗｂとして求めることができる。

＜まとめ＞
以上のように、本発明によれば、データセンタ内外のＶＭの配置の最適化において、
・ＶＭの移動オーバヘッド（ＶＭの移動に必要となる電力）
・ネットワーク機器の使用状況
・負荷変動状況
を考慮して、移動先のサーバ（物理計算機）を選択することが可能である。

上記により、負荷変動がある計算機システムにおいても、ネットワーク機器を含めた機器のリソースの使用量を考慮して、適切なＶＭの移動先を判定することができる。

以上のように、本発明は仮想計算機のマイグレーションを行う計算機システム及び、計算機システムの管理サーバに適用することができる。

５０ ＷＡＮ
１００ データセンタ
１１０〜１１８ サーバ
１１０ａ〜１１７ｂ 仮想サーバ
１２１ 構成情報
１２２ モニタリング情報
１２７ 移動先判定プログラム
１２７ａ ネットワーク管理テーブル
１２８ 負荷値収集プログラム
１２９ ＶＭ管理プログラム
１３１ 負荷予測プログラム
１３１ａ 負荷予測値リポジトリ
１４０ ルータ
１５０〜１５４ スイッチ

Claims (15)

1. プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記複数の物理計算機を接続するネットワーク機器と、前記複数の物理計算機を管理する管理サーバとを備えて、前記物理計算機で１つ以上の仮想計算機を提供する仮想化部を実行し、前記管理サーバが前記複数の物理計算機の消費電力を低減するように前記物理計算機へ割り当てる前記仮想計算機を制御する仮想計算機の移動方法であって、
   前記管理サーバが、移動対象の前記仮想計算機を選択する第１のステップと、
   前記管理サーバが、前記選択した仮想計算機の移動先の候補となる物理計算機を選択する第２のステップと、
   前記管理サーバが、前記移動先の候補として選択された物理計算機について、前記選択した仮想計算機を移動させるのに必要な第１の電力量を演算する第３のステップと、
   前記管理サーバが、前記移動先の候補として選択された物理計算機について、前記選択した仮想計算機を移動させた後に削減される第２の電力を演算する第４のステップと、
   前記管理サーバが、前記選択した仮想計算機を移動させた後に削減される第２の電力に時間を乗じた第２の電力量が、前記第１の電力量と等しくなる第１の時間を演算する第５のステップと、
   前記管理サーバが、前記移動先の候補として選択された物理計算機で、前記選択した仮想計算機を移動させた後に稼動可能な第２の時間を演算する第６のステップと、
   前記管理サーバが、前記第２の時間が前記第１の時間を超える物理計算機を、前記選択した仮想計算機の移動先として決定する第７のステップと、
   を含むことを特徴とする仮想計算機の移動方法。
2. 請求項１に記載の仮想計算機の移動方法であって、
   前記第２の時間は、
   前記選択した仮想計算機を前記移動先の候補として選択された物理計算機で稼動させてから当該物理計算機が使用するリソース量が所定の限界値に達するまでの時間であることを特徴とする仮想計算機の移動方法。
3. 請求項２に記載の仮想計算機の移動方法であって、
   前記リソース量は、
   前記選択した仮想計算機を前記選択された物理計算機へ移動した後に前記物理計算機が使用するネットワークのトラヒック量の予測値であることを特徴とする仮想計算機の移動方法。
4. 請求項１に記載の仮想計算機の移動方法であって、
   前記第７のステップは、
   前記第２の時間が前記第１の時間を超える物理計算機のそれぞれについて、前記仮想計算機を移動してから前記第２の時間までに削減される第３の電力量を演算するステップと、
   前記第３の電力量が最大となる物理計算機を前記仮想計算機の移動先として選択するステップと、
   を含むことを特徴とする仮想計算機の移動方法。
5. 請求項１に記載の仮想計算機の移動方法であって、
   前記第７のステップは、
   前記第２の時間と前記第１の時間の差が、所定の閾値を超える物理計算機を、前記選択した仮想計算機の移動先として決定することを特徴とする仮想計算機の移動方法。
6. 請求項１に記載の仮想計算機の移動方法であって、
   前記ネットワーク機器は、第２のネットワークに接続されたルータを含み、当該ルータは配下の物理計算機と前記第２のネットワークを介して他の計算機群との通信を行い、前記管理サーバは、前記他の計算機群を管理する第２の管理サーバと通信を行って、前記ルータの配下の物理計算機で稼動する仮想計算機を、前記他の計算機群の物理計算機へ移動可能であって、前記第２のネットワークは、当該第２のネットワークの消費電力を管理する第３の管理サーバを含み、
   前記第２のステップは、
   前記管理サーバが、前記選択した仮想計算機の移動先の候補となる物理計算機を、前記他の計算機群の物理計算機から選択し、
   前記第４のステップは、
   前記管理サーバが、前記移動先の候補として選択された前記他の計算機群へ前記仮想計算機を移動させた後に、前記ルータの配下の物理計算機で削減される電力を求める第８のステップと、
   前記移動先の候補として選択された前記他の計算機群の物理計算機へ前記選択した仮想計算機を移動させた後に削減される電力を前記第２の管理サーバに前記管理サーバが問い合わせる第９のステップと、
   前記移動先の候補として選択された前記他の計算機群の物理計算機へ前記選択した仮想計算機を移動させた後に前記第２のネットワークで削減される電力を前記第３の管理サーバへ前記管理サーバが問い合わせる第１０のステップと、
   前記第８のステップで求めた電力と、前記第９のステップで問い合わせた電力と、前記第１０のステップで問い合わせた電力の和を第２の電力として求める第１１のステップと、
   を含むことを特徴とする仮想計算機の移動方法。
7. プロセッサとメモリをそれぞれ備えた複数の物理計算機と、
   前記複数の物理計算機を接続するネットワーク機器と、
   プロセッサとメモリを備えて前記複数の物理計算機を管理する管理サーバと、を備えて、前記物理計算機で１つ以上の仮想計算機を提供する仮想化部を実行し、前記管理サーバが前記複数の物理計算機の消費電力を低減するように前記物理計算機へ割り当てる前記仮想計算機を制御する仮想計算機システムであって、
   前記管理サーバは、
   移動対象の前記仮想計算機を選択し、前記選択した仮想計算機の移動先の候補となる物理計算機を選択する移動先判定部と、
   前記移動先の候補として選択された物理計算機について、前記選択した仮想計算機を移動させるのに必要な第１の電力量を演算し、前記移動先の候補として選択された物理計算機について、前記選択した仮想計算機を移動させた後に削減される第２の電力を演算し、前記選択した仮想計算機を移動させた後に削減される第２の電力に時間を乗じた第２の電力量が、前記第１の電力量と等しくなる第１の時間を演算する負荷予測部と、を備え、
   前記移動先判定部は、
   前記移動先の候補として選択された物理計算機で、前記選択した仮想計算機を移動させた後に稼動可能な第２の時間を演算して、前記第２の時間が前記第１の時間を超える物理計算機を、前記選択した仮想計算機の移動先として決定することを特徴とする仮想計算機システム。
8. 請求項７に記載の仮想計算機システムであって、
   前記第２の時間は、
   前記選択した仮想計算機を前記移動先の候補として選択された物理計算機で稼動させてから当該物理計算機が使用するリソース量が所定の限界値に達するまでの時間であることを特徴とする仮想計算機システム。
9. 請求項８に記載の仮想計算機システムであって、
   前記リソース量は、
   前記選択した仮想計算機を前記選択された物理計算機へ移動した後に前記物理計算機が使用するネットワークのトラヒック量の予測値であることを特徴とする仮想計算機システム。
10. 請求項７に記載の仮想計算機システムであって、
    前記移動先判定部は、
    前記第２の時間が前記第１の時間を超える物理計算機のそれぞれについて、前記仮想計算機を移動してから前記第２の時間までに削減される第３の電力量を演算し、前記第３の電力量が最大となる物理計算機を前記仮想計算機の移動先として選択することを特徴とする仮想計算機システム。
11. 請求項７に記載の仮想計算機システムであって、
    前記移動先判定部は、
    前記第２の時間と前記第１の時間の差が、所定の閾値を超える物理計算機を、前記選択した仮想計算機の移動先として決定することを特徴とする仮想計算機システム。
12. プロセッサとメモリを備えて、複数の物理計算機の消費電力を低減するように前記物理計算機へ割り当てる仮想計算機を制御する管理サーバであって、
    移動対象の前記仮想計算機を選択し、前記選択した仮想計算機の移動先の候補となる物理計算機を選択する移動先判定部と、
    前記移動先の候補として選択された物理計算機について、前記選択した仮想計算機を移動させるのに必要な第１の電力量を演算し、前記移動先の候補として選択された物理計算機について、前記選択した仮想計算機を移動させた後に削減される第２の電力を演算し、前記選択した仮想計算機を移動させた後に削減される第２の電力に時間を乗じた第２の電力量が、前記第１の電力量と等しくなる第１の時間を演算する負荷予測部と、を備え、
    前記移動先判定部は、
    前記移動先の候補として選択された物理計算機で、前記選択した仮想計算機を移動させた後に稼動可能な第２の時間を演算して、前記第２の時間が前記第１の時間を超える物理計算機を、前記選択した仮想計算機の移動先として決定することを特徴とする管理サーバ。
13. 請求項１２に記載の管理サーバであって、
    前記第２の時間は、
    前記選択した仮想計算機を前記移動先の候補として選択された物理計算機で稼動させてから当該物理計算機が使用するリソース量が所定の限界値に達するまでの時間であることを特徴とする管理サーバ。
14. 請求項１３に記載の管理サーバであって、
    前記リソース量は、
    前記選択した仮想計算機を前記選択された物理計算機へ移動した後に前記物理計算機が使用するネットワークのトラヒック量の予測値であることを特徴とする管理サーバ。
15. 請求項１２に記載の管理サーバであって、
    前記移動先判定部は、
    前記第２の時間が前記第１の時間を超える物理計算機のそれぞれについて、前記仮想計算機を移動してから前記第２の時間までに削減される第３の電力量を演算し、前記第３の電力量が最大となる物理計算機を前記仮想計算機の移動先として選択することを特徴とする管理サーバ。