JP2014153897A - 計算機システム及びリソース管理装置並びにリソース管理方法 - Google Patents

Abstract

【課題】データセンタ間を接続する広域のネットワークに輻輳を発生させることなく、ＶＭが提供するサービスの品質を劣化させずに省電力化を達成するためのＶＭ移動先候補を高速に選定する。
【解決手段】複数のデータセンタ３０、４０、５０と、第１のネットワーク１０と、データセンタ内のリソースを管理するリソース管理装置１３０、１４０、１５０と、ネットワーク管理装置３とを備える計算機システムにおいて、第１のリソース管理装置が、移動予定の仮想計算機１３２、１３６、１４２、１４６、１５２，１５６が必要とするリソース量に基づき他のリソース管理装置に依頼して選定した移動先候補情報を、ネットワーク管理装置でエンドユーザからのデータ送受信において第１のネットワーク内に問題が発生するか否かを判定し、その結果と移動先候補の情報から、最も省電力化を達成する物理計算機を移動予定の仮想計算機の移動先として選択する。
【選択図】図１

Description

本発明は、遠隔より計算機資源をユーザへ提供する計算機システム及びリソース管理装置並びにリソース管理方法に関する。特に、計算機資源の配置決定処理の高速化を実現する装置、方法及びシステムに関する。

本技術分野の背景技術として、特許文献１に記載の発明がある。この発明は、仮想マシンの配置先の物理サーバを様々な要因を考慮して決定し、消費電力の低減を効率化することを課題としている。その解決手段として、制御装置は、複数の物理サーバに仮想マシンを配置する配置制御部と、仮想マシン毎の負荷情報を取得する負荷情報取得部と、物理サーバの優先順位情報を記憶する優先順位情記憶部と、物理サーバの制約条件情報を記憶する制約条件情報記憶部と、負荷情報と優先順位情報と制約条件情報とに基づいて、仮想マシン毎に当該仮想マシンの制約条件を満足する最も優先順位の高い物理サーバを選択する選択部とを備え、仮想マシン毎に物理サーバの選択および選択された物理サーバへの仮想マシンの配置を順に繰り返し、配置制御部は、仮想マシン毎に選択された物理サーバに配置するように制御する。

また、他の背景技術として、特許文献２に記載の発明がある。この発明は、アプリケーションのマイグレーションを可能にする、現在のパフォーマンス状態に準じてアプリケーションを実行することが可能な、１つ以上の適切なデータセンタを自動的に見つけることを課題としている。その解決手段として、第１のデータセンタは、そのマイグレーションされるアプリケーションのためのネットワーク要件、サーバ要件、およびストレージ要件を指定するマイグレーション要求文書によって、マイグレーション後にアプリケーションの指定されたパフォーマンスレベルが維持されることを保証する。マイグレーションを受ける候補であるデータセンタは、指定された要件を受け取り、パフォーマンスインデックスおよび他の分析を用いてそのハードウェア、ソフトウェア、及び他の構成が指定された要件を満たすかを決定する。決定結果は要求側データセンタに返され、要求側データセンタはマイグレーションを実施するかを決定する。

特開２０１１−１３８２２号公報 特開２００９−１３４６８７号公報

しかし、従来の仮想マシン（以下、ＶＭと記す。）の配置先決定では、ＣＰＵリソースの収容可否を中心として移動先を決定している。そのため、複数のデータセンタを広域なネットワークで接続した大規模なクラウドシステムでは、ＶＭの移動に伴い、広域ネットワーク側に輻輳が発生し、ＶＭから提供するサービスの品質が大幅に劣化する場合がある。

特許文献１には、システムの消費電力低減を効率化するシステムにおいて、物理サーバが有するネットワークリソースに対して、配分の上限規定が記載されている。例えば、特許文献１の図１７には、制約条件情報記憶部に記憶される物理サーバの制約条件情報として、ネットワーク帯域の配置上限値を設定した例が記載されている。しかし、この方法は、物理サーバに対するネットワークリソースに関する規定であり、複数のデータセンタを接続する広域ネットワークのリソースに関する規定ではない。物理サーバに対するネットワークリソースには余裕があっても、ＶＭ移動に伴う、複数のデータセンタ間を接続する広域ネットワークの輻輳発生やＶＭから提供されるサービス品質が劣化する場合が存在する。

また特許文献２には、複数のデータセンタを備える情報システムにおいて、第１のデータセンタから他のデータセンタに対して、アプリケーションのマイグレーションが可能かを、ネットワークリソース、サーバリソース、およびストレージリソースの観点で十分なリソースの空き容量があるかを確認する処理の記載がある。例えば、特許文献２の図２には個々のデータセンタのハードウェア及びソフトウェアの構成例が示されており、個々のデータセンタはリソースの１つとして仮想プライベートネットワーク（ＶＰＮ）２０３を備えている。また、図１４には、利用可能なＶＰＮ帯域幅の確認を確認するフローチャートが記載されている。各データセンタのリソースマネージャは、利用可能な未割当帯域幅をＶＰＮ要求部で要求されている帯域幅の量と比較している。しかし、この方法は、各データセンタ内でのネットワークリソースの空き容量を考慮しているが、複数のデータセンタ間を接続するネットワークのリソースの過不足を考慮しておらず、ＶＭ移動に伴う、複数のデータセンタ間を接続する広域ネットワークの輻輳発生やＶＭから提供されるサービス品質が劣化する場合が存在する。

本発明は、システムの省電力化を実効するシステムにおいて、複数のデータセンタ間にまたがったＶＭの移動において、各データセンタ間を接続する広域のネットワークに輻輳を発生させることなく、且つ複数のデータセンタ内に相当数存在する物理サーバより、ＶＭが提供するサービスの品質を劣化させずに省電力化を達成するためのＶＭ移動先候補を高速に選定する装置、方法、および計算機システムを提供することを目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数のデータセンタと前記複数のデータセンタを接続する第１のネットワークとを備えた計算機システムであって、前記データセンタ毎に設けられ当該データセンタ内のリソースを管理するリソース管理装置と、前記第１のネットワークを管理するネットワーク管理装置と、前記各データセンタ内に存在する移動予定の仮想計算機が必要とするリソース量を取得する手段とを有し、前記データセンタの１つを管理する第１の前記リソース管理装置は、管理下の前記１つのデータセンタにおける前記移動予定の仮想計算機が必要とする他の前記データセンタのリソース量を、該他のデータセンタを管理する第２の前記リソース管理装置へ通知する機能と、前記必要なリソース量の情報に応答して前記第２のリソース管理装置において選定された、前記移動予定の仮想計算機を稼動することが可能な少なくとも１つの物理計算機の候補の情報を受信する機能と、前記受信した前記仮想計算機の移動先候補の情報を、前記ネットワーク管理装置へ通知する機能とを有し、前記ネットワーク管理装置は、当該システムを利用するエンドユーザから前記受信した移動先候補毎の前記物理計算機へのデータ送受信において、前記ネットワーク内に問題が発生するか否かを判定し、該判定の結果を前記第１のリソース管理装置へ通知する機能を有し、前記第１のリソース管理装置は、さらに、前記移動先候補物理計算機候補の情報と前記の判定の結果とから、省電力化を達成する上位の少なくとも１つの物理計算機を、前記移動予定の仮想計算機の移動先として選択する機能を有することを特徴とする。

本発明によれば、第１のネットワークにより接続された複数のデータセンタを備えた計算機システムにおいて、複数のデータセンタ間にまたがったＶＭの移動において、各データセンタ間を接続する第１のネットワークに輻輳を発生させることなく、且つ複数のデータセンタ内に相当数存在する物理サーバより、ＶＭが提供するサービスの品質を劣化させずに省電力化を達成するためのＶＭ移動先候補を高速に選定することができる。

本発明の第１の実施形態における計算機システムの構成例を示す説明図である。 本発明の第１の実施形態におけるデータセンタ管理装置のメモリに格納されるプログラム及びデータを示す説明図である。 本発明の第１の実施形態におけるＷＡＮ管理装置のメモリに格納されるプログラム及び情報を示す説明図である。 本発明の第１の実施形態における管理装置のハードウェア構成の一例を示すブロック図である。 本発明の第１の実施形態における省電力化制御タイミングの一例を示す説明図である。 第１の実施形態における、複数のデータセンタ管理装置における、物理サーバリソースの利用形態の一例を示す図である。 第１の実施形態の第１のネットワークにおけるデータ送受信の通信経路の一例を示す図である。 本発明の第１の実施形態における計算機システム全体の処理の流れを説明するシーケンス図である。 本発明の第１の実施形態におけるデータセンタ管理装置が実行する省電力配置制御処理を説明するフローチャートである。 本発明の第１の実施形態におけるデータセンタ管理装置が実行する省電力配置解除処理を説明するフローチャートである。 本発明の第１の実施形態におけるデータセンタ管理装置が実行する省電力化応答処理を説明するフローチャートである。 本発明の第１の実施形態におけるＶＭが必要とするリソース量の作成方法を説明する図である。 本発明の第１の実施形態におけるＶＭが消費したリソース量の一例を示す説明図である。 本発明の第１の実施形態におけるＶＭが消費する予想リソース量の一例を示す説明図である。 本発明の第１の実施形態におけるＶＭが必要とする予想リソース量の一例を示す図である。 本発明の第１の実施形態における物理サーバにいて予想される残リソース量の一例を示す図である。 本発明の第１の実施形態におけるデータセンタ内物理サーバの予想残リソース量の一例を示す図である。 本発明の第１の実施形態におけるＷＡＮが必要とするリソース量の作成方法を説明する図である。 本発明の第１の実施形態におけるＷＡＮが消費したリソース量の一例を示す説明図である。 本発明の第１の実施形態におけるＷＡＮが消費する予想リソース量の一例を示す説明図である。 本発明の第１の実施形態におけるＷＡＮの左回りに関する予想残リソース量の一例を示す図である。 本発明の第１の実施形態におけるＷＡＮの右回りに関する予想残リソース量の一例を示す図である。 本発明の第２の実施形態における計算機システムの構成例を示す説明図である。 第２の実施形態におけるデータセンタ統合管理サーバ１６０を含む計算機システムの機能ブロックを示す図である。 第２の実施形態における計算機システム全体の処理の流れを説明するシーケンス図である。

本発明の代表的な実施形態を示せば以下の通りである。すなわち、複数のデータセンタと、前記複数のデータセンタを接続する第１のネットワークと、前記データセンタ毎にデータセンタ内のリソースを管理するリソース管理装置と、前記第１のネットワークを管理するネットワーク管理装置と、を備える計算機システムであって、前記第１のリソース管理装置は、管理するデータセンタ内に存在する移動予定の仮想計算機が必要とするリソース量を取得し、前記取得した移動予定の仮想計算機が必要とするリソース量を１乃至複数の前記第２のリソース管理装置へ通知し、他のリソース管理装置は、移動予定の仮想計算機を稼動することが可能な物理計算機の候補を１乃至複数選定し、前記第１のリソース管理装置へ通知し、前記第１のリソース管理装置は、前記第２のリソース管理装置から受信した仮想計算機の移動先候補情報を、前記ネットワーク管理装置へ通知し、前記ネットワーク管理装置は、システムを利用するエンドユーザから前記受信した移動先候補毎の物理計算機へのデータ送受信において前記第１のネットワーク内に問題が発生するか否かを判定し、その判定結果を前記第１のリソース管理装置へ通知し、前記第１のリソース管理装置は、前記移動先候補物理計算機と前記の判定結果から最も省電力化を達成する物理計算機を、移動予定の仮想計算機の移動先として選択すること、を特徴とする。

本発明によれば、第１の観点で、計算機システムにおいて、サービスを提供する複数の仮想計算機を、計算機リソースのみならず、複数の仮想計算機を移動した場合に、各計算機間を接続する第１のネットワークに輻輳を発生させる等の問題が発生しない場合に限り、且つ省電力化を達成する計算機上へ仮想計算機を移動することができる。したがって、仮想計算機が提供するサービスの品質を劣化させることなく、計算機システムの省電力化を達成できる。

本発明によれば、第２の観点で、複数存在するデータセンタ内の膨大な計算機群の中から、予め条件に適する計算機を選別し、サービスを提供する仮想計算機を移動可能か否かを少量の計算器量にて判定することができる。したがって、サービスを提供する仮想計算機の移動先を高速、短時間にて判定でき、且つ仮想計算機の省電力な配置を長時間に設定することができる。

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

本発明の第１の実施形態では、複数のデータセンタをリングネットワーク１０で接続した計算機システムの省電力化について説明する。
図１は、第１の実施形態における計算機システムの構成例を示す説明図である。本実施形態における計算機システムは、エンドユーザ端末２、第１のネットワーク（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ：ＷＡＮ）１０、ＷＡＮ管理サーバ（ネットワーク管理装置）３、第１のネットワークに接続されたノード２１、２２、２３、２４、２５、複数のデータセンタ３０、４０、５０、各データセンタに設けられたデータセンタ管理装置（データセンタ管理サーバ）１３０、１４０、１５０、第２のネットワーク（データセンタネットワーク）１１、１２、１３等により構成される。各データセンタは、ノード３１、３２、３３、３４、３５、４１、４２、４３、４４、４５、５１、５２、５３、５４、５５、物理サーバ１３１、１３５、１４１、１４５、１５１、１５５、及び仮想サーバ（以下、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ、ＶＭと記す。）１３２、１３６、１４２、１４６、１５２、１５６等を有している。本実施形態では、第１のネットワーク１０が、ノード２１、２２、２３、２４、２５により構成される。また、各データセンタ内の第２のネットワークとして、ノード３２、３３、３４、３５を含むネットワーク１１、ノード４２、４３、４４、４５を含むネットワーク１２、ノード５２、５３、５４、５５を含むネットワーク１３が、各々構成される。なお、第１のネットワーク１０は、他のネットワークタイプ、例えばスター型ネットワークであっても良い。スター型ネットワークの場合、中心のＨＵＢを介してスポーク状に複数のノードが接続され、これらのノードにエンドユーザ端末２、複数のデータセンタ３０、４０、５０、ネットワーク管理装置３等が接続される。

いずれの場合でも、各データセンタのデータセンタ管理サーバ１３０、１４０、１５０は、自データセンタにおける仮想計算機の移動を制御する時はマスタコンピュータとして機能し、他のデータセンタ管理サーバをスレーブコンピュータとして機能させるように構成されている。

図１に示した計算機システムでは、例えば、物理サーバやＶＭの処理負荷が低減する深夜の時間帯等において、複数のデータセンタ３０、４０、５０間にまたがりＶＭの片寄（縮約移動）を行い、不要な物理サーバをスリープさせる、或いは電源を停止することにより計算機システムの省電力化を実現する。

図２は、データセンタ管理装置１３０（１４０、１５０）のメモリ１７２（図４にて後述する。）にて実行されるプログラムおよび格納されるデータを示す説明図である。メモリ１７２では、省電力配置制御処理プログラム２３０、省電力配置解除処理プログラム２３１、データセンタ管理サーバ省電力化応答処理プログラム２３２、ＶＭ配置とサーバ電源管理処理２３３、リソースモニタリング処理プログラム２３４、及びリソース消費予測処理プログラム２３５を実行する。

省電力配置制御処理プログラム２３０は、ＶＭの処理負荷が低い場合に、ＶＭの片寄せ配置を実行する処理を実行する。なお、省電力配置制御処理プログラム２３０の詳細な動作については、図９を用いて後述する。
省電力配置解除処理プログラム２３１は、ＶＭの処理負荷が高くなる場合に、ＶＭの片寄せ配置を解除（非縮約）し、高負荷時のＶＭを適正配置する処理を実行する。なお、省電力配置解除処理プログラム２３１の詳細な動作については、図１０を用いて後述する。

データセンタ管理サーバ省電力化応答処理プログラム２３２は、他データセンタ管理サーバから移動予定のＶＭが必要とするリソース量を受信し、その移動予定のＶＭを収容することが可能な物理サーバを探索し、要求元のデータセンタ管理サーバへ返信する処理を実行する。なお、データセンタ管理サーバ省電力化応答処理プログラム２３２の詳細な動作については、図１１を用いて後述する。

ＶＭ配置とサーバ電源管理処理２３３は、前記の省電力配置制御処理プログラム２３０及び省電力配置解除処理プログラム２３１が決定したＶＭの配置に従い、ＶＭの移動を実際の物理サーバに対して実行する。また、ＶＭの片寄せ移動後に稼動が不要な物理サーバが発生した場合は、省電力なモードに状態を移行する。或いは必要に応じて電源オンが可能な程度に不要な処理を全て停止しても良い。
リソースモニタリング処理プログラム２３４は、データセンタ内に存在する全てのＶＭ及び物理サーバに対して、図１３に示されるリソースに関して、その状態をモニタリングする。なお、図１３の内容については、後述する。

リソース消費予測処理プログラム２３５は、前記のリソースモニタリング処理プログラム２３４の実行により収集したＶＭによるリソース消費履歴から、図１４に示すように、ＶＭが将来に消費する予定のリソース量を予測する。予測の方式としては、自己回帰モデルを用いたが、その他の手法により予測しても良い。なお、図１４の内容については、後述する。

図４は、図２に示した各プログラムを実行するデータセンタ管理装置１３０のハードウェア構成の一例を示すブロック図である。データセンタ管理装置１３０は、ＣＰＵ１７１、メモリ１７２、ストレージ１７３、ネットワークインタフェース１７４を備え、各構成はバス１７５を介して互いに接続される。ＣＰＵ１７１は、ストレージ１７３に格納された各種のプログラムやデータベースのデータをメモリ１７２にロードし、プログラムを実行する。ＣＰＵ１７１がプログラムを実行することによってデータセンタ管理装置１３０が備える機能を実現できる。メモリ１７２は、ＣＰＵ１７１によって実行されるプログラム及び当該プログラムの実行に必要なデータを格納する。メモリ１７２に格納されるプログラム及びデータについては、図２で述べた通りである。ネットワークインタフェース１７４は、第２のネットワーク１１を介して外部の装置と接続する。なお、データセンタ管理装置１４０及び１５０は、データセンタ管理装置１３０と同様のハードウェア構成であり、実行する処理も同一である。また、及びＷＡＮ管理サーバ３は、データセンタ管理装置１３０と同一のハードウェア構成である。

メモリ１７２では、また、図２及び図１３に示したＶＭ消費リソース履歴データベース情報２４０、図２及び図１４に示したＶＭ消費リソース予測データベース情報２４１、図２及び図１５に示したＶＭ必要リソース予測データベース情報２４２、図２及び図１６に示した物理サーバリソース残量予測データベース情報２４３、図２及び図１７に示したデータセンタリソース残量予測データベース情報２４４を保持する。なお、図１３から図１７の内容については、後述する。

なお、データセンタ管理サーバ１３０は、ハードウェアを用いて、上記説明した各種処理（プログラム２３０から２３５）と同様の機能を実現してもよい。

図３は、第１の実施形態におけるＷＡＮ管理サーバ３のメモリに格納されるプログラム及びデータを示す説明図である。図３に示した各プログラムを実行するＷＡＮ管理サーバのハードウェア構成は、図４に示した構成と同一である。メモリ１７２では、ＷＡＮ内輻輳判定処理プログラム２３６、ＷＡＮ内リソースモニタリング処理プログラム２３７、ＷＡＮ内リソース消費予測処理プログラム２３８、及び、ＷＡＮ内帯域残量予測処理プログラム２３９を実行する。

ＷＡＮ内輻輳判定処理プログラム２３６は、データセンタＡ管理サーバ１３０から送信された移動予定のＶＭに関する情報と、移動予定のＶＭを収容可能な物理サーバ及びその物理サーバを収容するデータセンタの識別子情報を受信し、且つ図２１及び図２２に示したＷＡＮ帯域残量予測データベース２４７（Ａ、Ｂ）を参照し、移動予定のＶＭを移動候補先である物理サーバへ移動した場合に、ＷＡＮ側に輻輳が発生するか否かを判断する。例えば、移動予定のＶＭが必要とする帯域として、図１５のＶＭ必要リソース予測データベース情報２４２Ａに示されるように、０．１５Ｇｂｐｓの送信帯域と０．０５Ｇｂｐｓの受信帯域を必要としており、且つデータセンタＢに存在する物理サーバで左回りの通信路を経由してデータを送受信している物理サーバが候補の場合は、図２１に示したＷＡＮ帯域残量予測データベース２４７Ａの左回り向け最少残帯域リソース６０１を参照する。そして、左回りの通信路を経由する場合は、Ｎ２１からＮ２２、Ｎ２２からＮ２３、及びＮ２３からＮ２４までの各区間において、ＶＭが必要とする０．０５Ｇｂｐｓの受信帯域と、Ｎ２４からＮ２５、及びＮ２５からＮ２１までの区間において、ＶＭが必要とする０．１５Ｇｂｐｓの送信帯域を確保可能であることを判定し、収容に問題が無いことをデータセンタＡ管理サーバ１３０へ回答する。

ＷＡＮ内リソースモニタリング処理プログラム２３７は、ＷＡＮ内に存在するノード２１、２２、２３、２４、２５における消費帯域をモニタリングして、図１９に示すＷＡＮ消費帯域履歴データベース２４５Ａを作成する。なお、図１９では、ＷＡＮにおける左回りの帯域、且つある日の２０：００から翌日の６：００までに消費された帯域に関してのみ記載しているが、同様に右回りについても、図示していないＷＡＮ消費帯域履歴データベース２４５Ｂを作成する。

ＷＡＮ内リソース消費予測処理プログラム２３８は、図１９に示したＷＡＮ消費帯域履歴データベース２４５Ａを参照し、将来において各ノードが必要とする帯域リソース量を推測し、図２０に示したＷＡＮ消費帯域予測データベース２４６Ａを作成する。なお、図２０では、ＷＡＮにおける左回りの帯域、且つある日の２０：００から翌日の６：００までに必要とされる帯域に関してのみ記載しているが、同様に右回りについても、図示していないＷＡＮ消費帯域予測データベース２４６Ｂを作成する。

ＷＡＮ内帯域残量予測処理プログラム２３９は、図２０のＷＡＮ消費帯域予測データベース２４６Ａを参照し、図２１及び図２２に示したＷＡＮ帯域残量予測データベース２４７Ａ及び２４７Ｂを作成する。図２１の６０１及び図２２の６０２に示された最少残帯域リソース量は、図２０に示したＷＡＮ消費帯域予測データベース２４６において、所定の期間における最少の帯域量をデータベース化したものである。

メモリ１７２Ｂでは、また、図１９に示したＷＡＮ消費帯域履歴データベース情報２４５Ａ、図２０に示したＷＡＮ消費帯域予測データベース情報２４６Ａ、及び図２１、図２２に示したＷＡＮ帯域残量予測データベース情報２４７Ａ、２４７Ｂを保持する。図１９から図２２の内容については、後述する。

なお、ＷＡＮ管理サーバ３は、ハードウェアを用いて、上記説明した各種処理（プログラム２３６から２３８）と同様の機能を実現してもよい。

図５は、本発明の第１の実施形態における省電力化制御タイミングの一例を示す説明図である。図１に示した計算機システムでは、ＶＭにおける昼夜の処理量の差を利用し、ＶＭのＣＰＵ負荷が低下している間にＶＭを片寄せし且つ不要な物理サーバを停止することで省電力化を図る。図中、２８０の曲線は、１日目の８時から翌日の２４時までの期間において、ＶＭにおける１分毎のＣＰＵにおける平均負荷量の例を示している。

第１の実施形態では、省電力配置開始時刻１（時刻２５１）にて示される１日目の２０時からＶＭの片寄せ（縮約）を開始し、省電力配置完了時刻１（時刻２５２）にて示される２日目の２１時にＶＭ片寄せの完了を見込んだ制御となっている。ここで、時刻２５１と時刻２５２間は、あるデータセンタで予定している全てのＶＭの移動を完了するために見積もられた第一の移動期間（Ｔ２）２５３である。また、ＶＭの処理負荷が増加する期間は、実施したＶＭの片寄を解除（非縮約）するため、省電力配置解除開始時刻１（時刻２５４）にて示される２日目の４時からＶＭの片寄せ解除を開始し、省電力配置解除完了時刻１（時刻２５５）にて示される２日目の６時にＶＭ片寄せ解除の完了を見込んだ制御となっている。ここで、時刻２５４と時刻２５５間は、あるデータセンタで予定している全てのＶＭの片寄せ解除のための移動を完了するために見積もられた第二の移動期間（Ｔ３）２５６である。その後、省電力配置開始時刻２（時刻２５７）にて示される２日目の２０時からＶＭの片寄せを開始し、前記１日目に実施したＶＭ片寄せと同等の処理を実行する。

前記説明した実施形態では、期間２６０で示されるように、ＶＭの片寄せを時刻２５１に開始し、ＶＭの片寄せ解除は時刻２５５に完了している。ここで仮に、ＶＭにおけるＣＰＵ負荷が低下している期間として、時刻２５１から時刻２５４までを指定し、その間において移動予定ＶＭが必要とするリソース量を、他のサーバにおいて収容可能だと判断しＶＭを移動した場合、ＶＭの移動を完了する前に負荷が上昇する可能性があるため、ＶＭの移動が完了するまでの時刻を含めて、ＶＭの移動が可能化を判断する必要がある。即ち、時刻２５１から時刻２５５にて示される期間２６０（図中の低負荷確認期間ＴL）において、移動予定ＶＭが必要するリソース量を、他のサーバにおいて収容可能かを判断する必要がある。

また、前記説明した実施形態では、期間（ＴＨ）２６１で示されるように、ＶＭの片寄せ解除を時刻２５４に開始し、次の回のＶＭ片寄せを時刻２５７に開始し所定期間（Ｔ４）後の時刻２５８に片寄せの完了をしている。期間２５６及び期間２５９の間は、ＶＭの移動が進行している期間であり、この期間にＶＭの処理負荷が上昇する可能性があるため、期間２６１にて示される期間（高負荷確認期間ＴＨ）において、移動予定のＶＭが必要とするリソース量を、他のサーバが収容可能かを判断する必要がある。

前記説明した実施形態では、ＶＭの負荷が低い期間（ＴＬ）２６０と負荷が高い期間（ＴH）２６１の両方において移動予定のＶＭが必要とするリソース量を他の物理サーバが収容可能かを判断する必要がある。そのため、移動予定のＶＭが必要とするリソースの収容可否判定を期間２８２（将来負荷予測対象期間ＴＥＳ）にて示される期間分を少なくとも予測する必要がある。また、前記予測は、ＶＭの移動を開始する前、例えば期間２８１（将来負荷予測実行期間Ｔ１）に行う必要がある。さらに前記予測を、ＶＭの配置を判定したり、或いはＶＭの移動を制御したりしている期間と同時に実行すると、データセンタ管理サーバの負荷が上昇し、処理遅延が発生するため、ＶＭの配置を判定したり、或いはＶＭの移動を制御したりしている期間と重複しない時間帯に実行する。但し、前記予測を、ＶＭの配置を判定したり、或いはＶＭの移動を制御したりするサーバと異なるサーバで実行する場合は、消費電力が増加するが、処理の遅延は削減される。

本発明の計算機システムは、例えば、数個乃至１０個程度のデータセンタを備え、各データセンタが管理サーバを含んで構成され、各データセンタ管理サーバが管理する物理サーバが１ユーザ（企業等）あたり最大１０００台、ＶＭが５０００台程度の規模を有する。すなわち、各データセンタ内には膨大な数の計算機群（リソース）が存在し、これらのリソースは、エンドユーザ向けのサービスを提供する複数の企業に貸与される。

図６は、本発明の第１の実施形態における、データセンタ管理サーバ１３０、１４０、１５０におけるデータセンタのリソースの利用形態の一例を示す図である。複数のデータセンタ管理サーバ１３０、１４０、１５０のリソースが、複数の企業（Ａ〜Ｎ）により使用される。例えば、ある時間帯において、データセンタ管理サーバ１３０−１をマスタ、データセンタ管理サーバ１４０−１、１５０−３をスレーブの関係で、ＷＡＮ管理サーバ３と連携し、図５に示したような省電力化制御タイミングでＶＭの片寄せを行う。同様に、企業Ａとは非同期の関係で、データセンタ管理サーバ１４０−２をマスタ、データセンタ管理サーバ１３０−２、１５０−２をスレーブの関係で、ＷＡＮ管理サーバ３と連携してＶＭの片寄せを行う。また、企業Ａ、Ｂとは非同期の関係で、データセンタ管理サーバ１５０−３をマスタ、データセンタ管理サーバ１３０−３、１４０−３をスレーブの関係で使用してＶＭの片寄せを行う。例えば、１企業当たり、１０００台のＶＭ、２００台の物理サーバが、各々、省電力化制御の対象となる。なお、省電力化制御のパターンは図５の例に限定されるものではない。データセンタのユーザである各企業の業務内容や営業形態、さらにはそれに対応するエンドユーザの構成毎に異なることは言うまでもない。

図７は、第１の実施形態の第１のネットワークにおけるデータ送受信の通信経路の一例を示す図である。この例では、図１の例と異なり、第１のネットワーク１０Ａがノード２１、２４間で短絡されている。そのため例えば、エンドユーザ２が接続されたノードＮ２１を起点としデータセンタＡの物理サーバ１ｓ−１までの経路を想定した時、ノードＮ２１からデータセンタＡのノードＮ２３までの通信経路は、ノードＮ２２を経由する左周りのルート、ノードＮ２５を経由する右周りのルートに加えて、ノードＮ２１からノードＮ２４を経由する中央のルートも存在している。なお、各データセンタ内の１ｓ−１、１ｓ−２等は物理サーバのノードを示している。本実施例では、各サーバや各ノード間の将来負荷の予測に基づき、システムを利用するエンドユーザと移動先候補毎の物理サーバ間において実行されるデータ送受信において、第１のネットワーク内に問題が発生するか否かを判定する。各サーバや第１のネットワークの各ノード間の将来負荷の予測は、ＶＭ移動による省電力化制御のタイミングと重ならない時間帯に実施する。

図８は、本発明の第１の実施形態における計算機システム全体の処理の流れを説明するシーケンス図である。本実施形態では、データセンタ３０内のデータセンタ管理（データセンタ管理サーバ）１３０が、当該データセンタ管理サーバ１３０をマスタ、データセンタ管理サーバ１４０、１５０をスレーブの関係で使用して、データセンタ３０内に存在するＶＭ１３２を、ＷＡＮ１０内に輻輳を発生させることなく、より電力効率の良い他のデータセンタ４０、或いはデータセンタ５０内の物理サーバへ移動することにより、図１に示したシステムの省電力化を実現する例について説明する。なお、移動先の探索では、データセンタ３０内の物理サーバを含めて電力効率の良い物理サーバを探索する。図８では、データセンタＡ管理サーバ１３０が、自データセンタ内のＶＭを、他のデータセンタＢ、或いはデータセンタＣ内の物理サーバへ移動する処理を示す。当該処理に関係のない構成は省略している。

ＷＡＮ管理サーバ３は、ＷＡＮ１０を構成するノード２１、２２、２３、２４、２５における消費帯域をモニタリングし、図１９に示すＷＡＮ消費帯域履歴データベース２４５Ａを構成する（ステップＳ２０１）。また、ＷＡＮ管理サーバ３は、モニタリングした各ノードにおけるＷＡＮ消費帯域履歴データベース２４５Ａから、ＷＡＮ１０における今後の消費帯域を予測し、図２０に示すＷＡＮ消費帯域予測データベース２４６Ａを構成する（ステップＳ２０２）。図１９及び図２０では、ＷＡＮにおける左回りの帯域に関してのみ記載しているが、同様に右回りについてもデータベースを作成する。さらに、ＷＡＮ管理サーバ３は、ＷＡＮ帯域消費予測データベース２４６から、図５にて示した低負荷確認期間（ＴＬ）２６０に関して、図２１、図２２に示した左回り及び右回りの各ノード間における提供可能なＷＡＮ帯域残量予測データベース２４７Ａ及び２４７Ｂ（期間２６０において、最少となる帯域）を算出する（ステップＳ２０３）。なお、図１９、図２０、図２１、図２２の詳細な説明は、後述する。

データセンタ管理サーバ１３０、１４０、１５０は、自データセンタ内のリソースの消費状態をモニタリングし、図１３に示す各ＶＭに対するＶＭ消費リソース履歴データベース２４０Ａを構成する（ステップＳ２０４、ステップＳ２０７、ステップＳ２１０）。

また、データセンタ管理サーバ１３０、１４０、１５０は、ＶＭリソース消費履歴データベース２４０Ａから、各ＶＭにおける今後のリソース消費を予測し、図１４に示すＶＭ消費リソース予測データベース２４１Ａを構成する（ステップ２０５、ステップＳ２０８、ステップＳ２１１）。

さらに、図５にて示した低負荷確認期間（ＴＬ）２６０に関して、ＶＭ消費リソース予測データベース２４１Ａから、図１５に示す各ＶＭが必要とする最大のリソース量を示すＶＭ必要リソース予測データベース２４２Ａを構成する。（ステップＳ２０６、ステップＳ２０９、ステップＳ２１２）。図１３、図１４、図１５では、ＶＭのＣＰＵ負荷が低い場合の期間（図５の期間２６０）に対する単一のＶＭに対するＶＭ消費リソース履歴データベース２４０Ａと、ＶＭ消費リソース予測データベース２４１Ａと、ＶＭ必要リソース予測データベース２４２Ａになっているが、同一構造のデータベースを、ＣＰＵ負荷が高い期間（図５の期間２６１）においても作成する。図１３、図１４、図１５の各データベースは、ＶＭが必要とする各データセンタ内の第２のネットワークの帯域に関する情報（送信帯域及び受信帯域）を含んでいる。なお、図１３、図１４、図１５の詳細な説明は、後述する。

データセンタＡ管理サーバ１３０は、自データセンタ内に存在する全てのＶＭに対して、他のデータセンタへ移動するか否かを判定するための順序を決定する（ステップＳ２１３）。

データセンタＡ管理サーバ１３０は、ステップ２１３にて決定した順序に従い、第１番目の移動予定ＶＭに対して、将来に必要なリソース量を図２に示したＶＭ必要リソース予測データベース２４２から取得する（ステップＳ２１４）。

データセンタＡ管理サーバ１３０は、移動予定のＶＭを収容可能な物理サーバを探索するため、取得した移動予定のＶＭが必要とするリソース量をデータセンタＢ管理サーバ１４０及びデータセンタＣ管理サーバ１５０へ送信する（ステップＳ２１５及びステップＳ２１６）。

データセンタＢ管理サーバ１４０は、データセンタＡ管理サーバより送信された移動予定のＶＭが必要とするリソース量を受信し、図１７に示したデータセンタリソース残量予測データベース２４４を参照し、移動予定のＶＭ収容が可能な物理サーバを探索する（ステップＳ２１７）。なお、図１７の詳細な説明は後述する。また、判断の方法に関しては、図１１に示したデータセンタ管理装置が実行する省電力化応答処理を説明するフローチャートを用いて詳述する。また、データセンタＢ管理サーバ１４０は、ステップＳ２１７の処理において探索した、移動予定ＶＭを収容可能な１乃至複数の物理サーバの情報をデータセンタＡ管理サーバへ送信する（ステップＳ２１９）。

同様に、データセンタＣ管理サーバ１５０は、データセンタＡ管理サーバより送信された移動予定のＶＭが必要とするリソース量を受信し、図１７に示したデータセンタリソース残量予測データベース２４４を参照し、移動予定のＶＭ収容が可能な物理サーバを探索する（ステップＳ２１８）。また、データセンタＣ管理サーバ１５０は、ステップＳ２１８の処理において探索した、移動予定ＶＭを収容可能な１乃至複数の物理サーバの情報をデータセンタＡ管理サーバへ送信する（ステップＳ２２０）。

データセンタＡ管理サーバ１３０は、データセンタＢ管理サーバ１４０及びデータセンタＣ管理サーバ１５０より送信された、移動予定のＶＭを収容可能な全ての物理サーバ候補から所定数（例えば候補数３）の候補物理サーバを選定する（ステップＳ２２１）。続いて、データセンタＡ管理サーバ１３０は、移動予定のＶＭに関する情報（ＶＭのＩＰアドレス等の識別子、及びＶＭが必要とするリソース量情報）と、ステップＳ２２１の処理において選定した物理サーバ候補に関する情報（物理サーバのＩＰアドレス等の識別子、及び物理サーバを収容するデータセンタの識別子）とを、ＷＡＮ管理サーバ３へ送信する（ステップＳ２２２）。ＶＭが必要とするリソース量情報には、第１のネットワークを使用した移動予定の時間帯、すなわち第１のネットワークを使用する低負荷確認期間ＴＬの情報も含まれる。なお、候補物理サーバを選定するのに必要な第１のネットワークを使用する時間帯の情報は、低負荷確認期間ＴＬに限定する必要はなく、例えば、縮約及び非縮約のための移動時間帯Ｔ２，Ｔ３等を適宜組み合わせたものであっても良い。

ＷＡＮ管理サーバ３は、データセンタＡ管理サーバより送信された移動予定のＶＭに関する情報（第１のネットワークの使用予定時間帯の情報を含む）と、移動予定のＶＭを収容可能な物理サーバ及びその物理サーバを収容するデータセンタの識別子情報を受信し、且つ図２１及び図２２に示したＷＡＮ帯域残量予測データベース２４７を参照し、移動予定のＶＭを移動候補先である物理サーバへ、図５中の低負荷確認期間ＴＬに移動した場合に、ＷＡＮ側に輻輳が発生するか否かを判断する（ステップＳ２２３）。この判断は、低負荷確認期間ＴＬの開始前、例えば、図５の１８時乃至２０時の間になされる。ここで例えば、移動先候補の物理サーバの識別子が、２ｓ−１の場合、最初の番号がデータセンタの番号を示し、次の文字ｓはサーバを示し、さらに最後の番号１は、データセンタ２内の物理サーバの番号を示している。また、本実施形態では、最後の物理サーバの番号が１２７までの場合は、左回りの通信路を利用し、物理サーバの番号が１２８から２５５までの場合は、右回りの通信経路を利用することを示している。ここでは、物理サーバの識別子から、どのデータセンタに所属する物理サーバか、また左回りの通信経路を利用するか、或いは右回りの通信経路を利用するかを判別可能なとしたが、それぞれが判別可能な対応を示すデータベースを別途作成し保持しても良い。

例えば、移動予定のＶＭが必要とする帯域として、図１５に示されるように、０．１５Ｇｂｐｓの送信帯域と０．０５Ｇｂｐｓの受信帯域を必要としており、且つデータセンタＢに存在する物理サーバで左回りの通信路を経由してデータを送受信している物理サーバが候補の場合は、図２１に示したＷＡＮ帯域残量予測データベース２４７Ａを参照する。そして、左回りの通信路を経由する場合は、Ｎ２１からＮ２２、Ｎ２２からＮ２３、及びＮ２３からＮ２４までの各区間において、ＶＭが必要とする０．０５Ｇｂｐｓの受信帯域と、Ｎ２４からＮ２５、及びＮ２５からＮ２１までの区間において、低負荷確認期間ＴＬにＶＭが必要とする０．１５Ｇｂｐｓの送信帯域を確保可能な場合は、収容に問題が無いことを、データセンタＡ管理サーバへ回答する（ステップＳ２２４）。一方、候補である物理サーバの収容先がデータセンタＢであり、且つ必要とする帯域として、０．１５Ｇｂｐｓの送信帯域と０．０５Ｇｂｐｓの受信帯域を右回りで必要とする場合は、図２２に示したＷＡＮ帯域残量予測データベース２４７Ｂを参照する。そして、右回りの通信路を経由するため、Ｎ２１からＮ２５、Ｎ２５からＮ２４までの区簡において、ＶＭが必要とする０．０５Ｇｂｐｓの受信帯域と、Ｎ２４からＮ２３、Ｎ２３からＮ２２、及びＮ２２からＮ２１までの区間において、ＶＭが必要とする０．１５Ｇｂｐｓの送信帯域確保が可能かを判断する。本実施形態では、右回りの通信路を経由する場合は、移動予定のＶＭが必要とする通信帯域を確保できないため、収容に予定に問題があることを、データセンタＡ管理サーバへ回答することになる（ステップＳ２２４）。

データセンタＡ管理サーバ１３０は、ＷＡＮ管理サーバより送信された、移動ＶＭ収容候補物理サーバ毎の収容可否を受信し、収容可能な物理サーバにおいて最も電力効率の良い物理サーバを、移動予定のＶＭの移動先として選定する（ステップＳ２２５）。

前記説明した処理、ステップＳ２１４からステップＳ２２５を、自データセンタ内に存在する移動可否判断を実行する全てのＶＭについて実施する（ステップＳ２２６）。また、データセンタＡ管理サーバ１３０は、自データセンタ内の移動可否判断を実行する全てのＶＭについて移動可否を判断した後、移動予定のＶＭを、既存の物理サーバ上から移動候補先の物理サーバへ移動を制御する（ステップＳ２２７）。

移動先候補の物理サーバには、自データセンタ内の物理サーバも対象となる。すなわち、ＶＭの移動には、自データセンタ内の他の物理サーバへの移動が含まれる場合もある。例えば、データセンタＡ管理サーバ１３０が、移動候補先の物理サーバの選定にあたって、各データセンタ３０、４０、５０から３件、合計９件の候補物理サーバをまず選定し、次に、各々の電力効率と、右／左回りの通信帯域とを考慮して、最終的に、移動予定のＶＭの移動先として上位の３件を選定することが考えられる。このような選定は、低負荷確認期間ＴＬの開始前、例えば２０時までになされる。そして、選定されたＶＭの移動が低負荷確認期間ＴＬに行われる。

図９は、本発明の第１の実施形態におけるデータセンタＡ管理サーバ１３０が実行する省電力配置制御処理を説明するフローチャートある。データセンタＡ管理サーバ１３０のＣＰＵ１７１が、省電力配置制御処理プログラム２３０をメモリ１７２にロードすることにより、ＶＭの省電力配置制御処理が開始される（ステップＳ３００）。

ＣＰＵ１７１は、データセンタ内に存在するサーバ及びＶＭに対するモニタリングデータが所定期間以上存在するか否かを判定する（ステップＳ３０１）。例えば、３週間分の履歴データが存在するか否かを判定する。

ステップＳ３０１の条件が満たされていない場合は、ステップＳ３０１の条件が満たされるまでステップＳ３０１を継続する。ステップＳ３０１の条件が満たされた場合、ＣＰＵ１７１は、ＶＭが消費する将来のリソース量を予測する期間にあるか否かを判定する（ステップＳ３０２）。例えば、図５に示した将来負荷予測実行期間２８１内かを判定する。ステップＳ３０２の条件が満たされない場合は、ステップＳ３０２の条件が満たされるまでステップＳ３０２を継続する。

ステップＳ３０２の条件が満たされたと判定した場合、ＶＭが消費する将来（例えば、図５における将来負荷予測対象期間２８２）のリソース量を予測する。具体的な予測例としては、図１３に示した、ＶＭが消費したリソースの履歴情報等から、図１４に示した、ＶＭが将来に消費する予定のリソース量を予測する（ステップＳ３０３）。なお、図１３および図１４では、図５における低負荷確認期間２６０における予測となっているが、同様に高負荷確認期間２６１についても予測する。

続いて、ＣＰＵ１７１は、ＶＭの省電力配置を実行する時刻になっているか否かを判定する（ステップＳ３０４）。ステップＳ３０４の判定において条件を満たしていないと判定した場合、ステップＳ３０４の条件が満たされるまでステップＳ３０４を継続する。
ステップＳ３０４の条件を満たしていると判定した場合、ＶＭ毎の移動先判定の順番を決定する（ステップＳ３０５）。
続いて、ＣＰＵ１７１は、ステップＳ３０５にて決定した順番に、移動予定のＶＭが将来（例えば、図５における低負荷確認期間２６０）の縮約移動において必要とするリソース量を、他のデータセンタ管理サーバ１４０および１５０へ送信する（ステップＳ３０６）。

ＣＰＵ１７１は、移動予定のＶＭを収容可能な物理サーバ候補の回答を、他の全てのデータセンタ管理サーバから受信したかを判定する（ステップＳ３０７）。ステップＳ３０７の条件を満たしていない場合は、ステップＳ３０７条件が満たされるまでステップＳ３０７を継続する。ステップＳ３０７の条件を満たした場合は、移動予定ＶＭを収容可能な物理サーバとして受信した全ての候補及び自データセンタ内において移動ＶＭを収容可能な物理サーバとから、さらに電力効率の良い順番で、所定数の物理サーバを候補として選定する（ステップＳ３０８）。例えば、上位３件の物理サーバを選定する。なお、他のデータセンタ管理サーバから受信した物理サーバを全て候補として選定しても良い。但し、その場合は、実際の移動先物理サーバ選定時間がわずかではあるが増加する。

続いて、ＣＰＵ１７１は、ステップＳ３０８で選定した物理サーバ候補が、他のデータセンタ内の物理サーバか否かを判定する（ステップＳ３０９）。ステップＳ３０９の条件を満たすと判定した場合は、ＣＰＵ１７１は、各候補の物理サーバへＶＭを移動した場合、ＷＡＮに輻輳の問題が発生するか否かを確認するため、移動予定のＶＭに関する情報（ＶＭのＩＰアドレス等の識別子、及びＶＭが必要とするリソース量情報）と、選定した物理サーバ候補に関する情報（物理サーバのＩＰアドレス等の識別子、及び物理サーバを収容するデータセンタの識別子）とを、ＷＡＮ管理サーバ３へ送信する（ステップＳ３１０）。ステップＳ３０９の条件を満たしていないと判定した場合は、ステップＳ３１２の処理へと遷移する。

続いて、ＣＰＵ１７１は、移動予定のＶＭを収容可能な物理サーバ候補の回答を、他の全てのデータセンタ管理サーバから受信したか否かを判定する（ステップＳ３１１）。ステップＳ３１１の条件を満たしていない場合は、ステップＳ３１１の条件が満たされるまでステップＳ３１１を継続する。ステップＳ３１１の条件を満たしていると判定した場合は、候補となっている物理サーバに関して、ＷＡＮ側においても収容可能と判定された物理サーバ候補から最も省電力化を達成する物理サーバをＶＭの移動先候補物理サーバとして決定保持する（ステップＳ３１２）。
ＣＰＵ１７１は、ステップＳ３１２で最終決定した候補の物理サーバ情報を、他のデータセンタ管理サーバへ通知する（ステップＳ３１３）。

続いて、ステップＳ３０６からステップＳ３１３までの処理を、自データセンタ内の全てのＶＭに対して実施したか否かを判定する（ステップＳ３１４）。ステップＳ３１４の条件を満たしていないと判定した場合は、次の移動予定のＶＭを選択し、ステップＳ３０６の処理に戻る（ステップＳ３１５）。ステップＳ３１４の条件を満たしていると判定した場合は、決定したＶＭ移動先へ全てのＶＭ移動を指示する（ステップＳ３１６）。

図１０は、本発明の第１の実施形態におけるデータセンタ管理装置１３０が実行する省電力配置解除処理を説明するフローチャートある。データセンタＡ管理サーバ１３０のＣＰＵ１７１が、省電力配置制御処理プログラム２３１をメモリ１７２にロードすることにより、ＶＭの省電力配置解除処理が開始される（ステップＳ１３００）。

図１０に示した、ステップＳ１３０５、ステップＳ１３０７、及びステップＳ１３０９からステップＳ１３１６までの処理は、図９にて説明したテップＳ３０５、ステップＳ３０７、及びステップＳ３０９からステップＳ３１６までの処理の内容と同一のため、説明を省略する。

ＣＰＵ１７１は、省電力な配置を解除すべき時刻に達しているか否かを判定する（ステップＳ１３２０）。即ち、省電力配置解除開始時刻１（２５４）に達しているか否かを判定する。ステップＳ１３２０の条件を満たしていないと判定した場合は、ステップＳ１３２０条件が満たされるまでステップＳ１３２０を継続する。ステップＳ１３２０の条件を満たしていると判定した場合は、図９に説明したステップＳ１３０５の処理を実行する。

続いて、ＣＰＵ１７１は、ステップＳ１３０５を実行した後、ＶＭの負荷が高まる期間（例えば、図５中の高負荷確認期間２６１）におけるＶＭの片寄せ配置を解除した（非縮約）配置を決定するため、移動予定のＶＭが必要とするリソース量を、他のデータセンタ管理サーバへ送信する（ステップＳ１３２１）。続いて、ＣＰＵ１７１はステップＳ１３０７を実行する。

ステップＳ１３０７の条件を満たした場合は、移動予定ＶＭを収容可能な物理サーバとして受信した全ての候補及び自データセンタ内において移動ＶＭを収容可能な物理サーバとから、さらに電力効率の良い順番で、所定数の物理サーバを候補として選定する（ステップＳ１３２２）。例えば、上位３件の物理サーバを選定する。なお、他のデータセンタ管理サーバから受信した物理サーバを全て候補として選定しても良い。但し、その場合は、実際の移動先物理サーバ選定時間がわずかではあるが増加する。

続いて、ＣＰＵ１７１は、ステップＳ１３０９からステップＳ１３１６までの処理を実行し、図５の高負荷確認期間２６１向けに決定したＶＭ移動先へ全てのＶＭ移動を指示する。

図１１は、本発明の第１の実施形態におけるデータセンタ管理装置が実行する省電力化応答処理を説明するフローチャートある。データセンタＢ管理サーバ１４０、或いはデータセンタＣ管理サーバ１５０のＣＰＵ１７１が、データセンタ管理サーバ省電力化応答処理プログラム２３２をメモリ１７２にロードすることにより、ＶＭ移動先候補選定処理が開始される（ステップＳ４００）。

ＣＰＵ１７１は、別のプロセスを起動し、非同期にてＶＭの配置制御や、物理サーバの電源管理処理を実行する（ステップＳ４０１）。

またＣＰＵ１７１は、別のプロセスを起動し、非同期にて、自データセンタ内のリソースの消費状態をモニタリングし、図１３に示す各ＶＭに対するＶＭ消費リソース履歴データベース２４０Ａを構成する（ステップＳ４０２）。なお、図１３では、図５における低負荷確認期間２６０におけるリソースの消費状態履歴のみ表示しているが、高負荷確認期間２６１を含め、絶え間なくリソースの消費状態をモニタリングする。

続いて、ＣＰＵ１７１は、図１７に示したように、各物理サーバにおける電力効率の良い順に物理サーバをリスト化する（ステップＳ４０３）。ここで例えば、電力効率として、エネルギーの使用の合理化に関する法律が規定するエネルギー消費効率を用いる。

ＣＰＵ１７１は、他のデータセンタ管理サーバから移動予定のＶＭを収容可能な物理サーバの探索依頼を受信しているか否かを判定する（ステップＳ４０４）。ステップＳ４０４の条件を満たしていないと判定した場合は、ステップＳ４０４の条件を満たすまで、ステップＳ４０４の処理を継続する。

ステップＳ４０４の条件を満たしたと判定した場合は、移動予定のＶＭを収容可能な物理サーバを探索開始する（ステップＳ４０５）。

ＣＰＵ１７１は、図１７に示した物理サーバの予想残リソース量データベース２４４Ａを参照し、移動予定のＶＭを収容可能か判定する物理サーバを、物理サーバの予想残リソース量データベース２４４Ａから順次１台を設定する（ステップＳ４０６）。

続いて、ＣＰＵ１７１は、探索した物理サーバの個数として、１を加算する（ステップＳ４０７）。

ＣＰＵ１７１は、ステップＳ４０６にて設定した探索物理サーバが、移動予定のＶＭを収容可能か判定する（ステップＳ４０８）。具体的には、図１７に示す物理サーバの予想残リソース量データベース２４４Ａを参照し、移動予定のＶＭが将来において消費する予定のリソース量を提供可能な物理サーバを、電力効率の良い順に探索する。移動予定のＶＭを収容可能な物理サーバ候補の選定では、図１に示したエンドユーザ２が各物理サーバとデータを送受信する場合に、ＷＡＮ内において異なる経路を利用する物理サーバを複数選定する。例えば、本実施形態では、各データセンタ内における物理サーバの識別子を基に、サーバの識別子が０から１２７の場合は、ＷＡＮにおいて左回りの経路を利用し、１２８から２５５までの場合は、ＷＡＮにおいて右回りの経路を利用するため、左回りと右回りそれぞれにおいて、移動ＶＭを収容可能な物理サーバ候補を選定する。

ステップＳ４０８の条件を満たしていると判定した場合は、移動予定のＶＭを収容可能な物理サーバ候補としてリストへ追加管理する（ステップＳ４０９）。

続いて、ＣＰＵ１７１は、移動予定のＶＭを収容可能な物理サーバ候補がリストされたか否かを判定する（ステップＳ４１０）。具体的には、本実施形態では、ＷＡＮに左回りの通信路と右回りの通信路が存在するため、各データセンタより、左回りの通信路を利用する物理サーバ候補と、右回りの通信路を利用する物理サーバ候補とが、１台ずつ選定されたか否かを判定する。

ステップＳ４１０の条件を満たしていないと判定した場合は、規定の物理サーバを探索したか否かを判定する（ステップＳ４１５）。具体的には、例えば自データセンタ内に１０００台の物理サーバが存在する場合、電力効率順に１０％（１００台）の物理サーバのみを検索するように設定する。或いは、移動予定のＶＭが収容されている物理サーバの電力効率以上の物理サーバのみを対象とした探索を行う設定をする。
ステップＳ４１５の条件を満たしていると判定した場合は、ステップＳ４１１へ進み処理を継続する。

ステップＳ４１５の条件を満たしていないと判定した場合は、探索候補として設定した全ての物理サーバを探索したか否かを判定する（ステップＳ４１６）。
ステップＳ４１６の条件を満たしていると判定した場合は、ステップＳ４１１へ進み処理を継続する。
ステップＳ４１６の条件を満たしていないと判定した場合は、ステップＳ４０６へ進み処理を継続する。

また、ＣＰＵ１７１は、ステップＳ４０８の条件を満たしていないと判定した場合は、規定割合の物理サーバを探索したか否かを判定する（ステップＳ４１５）。
ステップＳ４１０の条件を満たしていると判定した場合、移動予定のＶＭを収容可能な候補としてリストした物理サーバの情報（物理サーバのＩＰアドレス等の識別子、及び物理サーバを収容するデータセンタの識別子）を、要求元のデータセンタＡ管理サーバ１３０へ送信する（ステップＳ４１１）。

続いて、ＣＰＵ１７１は、データセンタＡ管理サーバ１３０から、ＶＭの移動先としての最終的な物理サーバの情報を受信したか否かを判定する（ステップＳ４１２）。ステップＳ４１２の条件を満たしていないと判定した場合は、ステップＳ４１２の条件を満たすまでステップＳ４１２の処理を継続する。

ステップＳ４１２の条件を満たしたと判定した場合、受信したＶＭの移動先としての物理サーバが自データセンタ内の物理サーバかを判定する（ステップＳ４１３）。ステップＳ４１３の条件を満たしていないと判定した場合は、ステップＳ４０４の処理へと進む。ステップＳ４１３の条件を満たしたと判定した場合は、選択された自データセンタ内の物理サーバが将来において提供可能なリソース量を、収容するＶＭが必要とするリソース量を減算し、図１７に示したＤＣリソース残量予測データベース２４４を更新する（ステップＳ４１４）。ここで、ＤＣリソース残量予測データベース２４４の更新では、収容するＶＭが必要とするリソース量を減算した後、提供可能なリソース量が所定の量未満である場合は、ＶＭ移動先候補としての物理サーバリストから除外し、図１７の探索対象５５１に示したフラグを０にセットし、探索対象から除外したことを明示する。

図１２は、本発明の第１の実施形態におけるＶＭが必要とする将来のリソース量を作成する方法を示している。即ち、算出したい期間における１週間、２週間、及び３週間前のリソースの消費履歴５７１、５７２、５７３を用いて、将来に必要とするリソース量５８０を算出する。なお算出では、自己回帰モデルを用いた。

図１３は、本発明の第１の実施形態におけるＶＭが消費したリソース量の一例を示す説明図である。図１３に示したＶＭ消費リソース履歴データベース２４０Ａでは、記録した期間が２０１２年１２月１０日（月）の２０：００から１２月１１日（火）の６：００、すなわち図５中の低負荷確認期間ＴＬとなっている。またモニタリングしたリソースは、ＣＰＵ、メモリ、ストレージ、ＶＭからの送信帯域、及びＶＭの受信帯域となっていることを示している。

図１４は、本発明の第１の実施形態におけるＶＭが消費する予想リソース量の一例を示す説明図である。図１４に示したＶＭ消費リソース予測データベース２４１Ａでは、予測した期間が２０１２年１２月１７日（月）の２０：００から１２月１８日（火）の６：００、すなわち低負荷確認期間ＴＬとなっている。また予測したリソースは、ＣＰＵ、メモリ、ストレージ、ＶＭからの送信帯域、及びＶＭの受信帯域となっていることを示している。

図１５は、本発明の第１の実施形態におけるＶＭが必要とする予想リソース量の一例を示す図である。図１５に示したＶＭ必要リソース予測データベース２４２Ａでは、予測した期間５２１が２０１２年１２月１７日（月）の２０：００から１２月１８日（火）の６：００、すなわち低負荷確認期間ＴＬとなっている。記載した項目５１１は、移動対象ＶＭのＩＰアドレス５２２、移動対象ＶＭを収容している物理サーバ５２３、移動対象ＶＭを収容している物理サーバのエネルギー消費効率５２４、移動予定ＶＭのＣＰＵ必要量５２５、メモリ必要量５２６、ストレージ必要量５２７、移動予定ＶＭの送信帯域５２８、及び移動予定ＶＭのデータ受信帯域５２９とから構成していることを示している。また、各項目における情報、及び必要とするリソース量は、図１４にて予測した必要リソース量を参照し、前記予測期間における必要リソース量の最大値となっている。

図１６は、本発明の第１の実施形態における物理サーバにいて予想される残リソース量の一例を示す図である。図１６に示した物理サーバリソース残量予測データベース２４３Ａでは、残リソースの管理項目５６１として、サーバ（物理サーバ或いはＶＭ）識別子、エネルギー消費効率、ＣＰＵ、メモリ、ストレージ、サーバのデータ送信帯域、サーバのデータ受信帯域があることを示している。図１６の５６２は、複数のＶＭを収容する物理サーバが保有する全リソース量を示している。また、図１６中の５６３、５６４が示すリソース量は、収容しているＶＭ１及びＶＭ２が予測期間中に必要とする最大リソース量を示している。さらに図１６中の５６５は、各データセンタ内において複数のＶＭを収容した物理サーバにおける最少残リソース量を示している。

図１７は、本発明の第１の実施形態におけるデータセンタ内物理サーバの予想残リソース量の一例を示す図である。図１７に示した、データセンタリソース残量予測データベース２４４Ａは、ＶＭ収容探索の対象を示す識別子５５１、物理サーバの電力効率に基づいて探索優先順位５５２、物理サーバ識別子５５３、物理サーバのエネルギー消費効率５５４、予測期間における、最少の残ＣＰＵリソース５５５、最少の残メモリリソース５５６、最少の残ストレージリソース５５７、最少の残送信帯域リソース５５８、及び最少の残受信帯域リソース５５９の項目を含んでいることを示している。各リソース項目における残リソース量は、図１７に記載の値である。

図１８は、本発明の第１の実施形態における複数のデータセンタ間のＷＡＮ（第１のネットワーク）が必要とするリソース量の作成方法を説明する図である。即ち、算出したい期間における１週間、２週間、及び３週間前のリソースの消費履歴５９１、５９２、５９３を用いて、将来に必要とするリソース量６００を算出する。なお算出では、自己回帰モデルを用いた。

図１９は、本発明の第１の実施形態におけるＷＡＮが消費したリソース量の一例を示す説明図である。縦軸は時間帯、横軸はノード間のリンクを示している。図１９に示したＷＡＮ消費帯域履歴データベース２４５Ａでは、図示していないが、記録した期間が２０１２年１２月１０日（月）の２０：００から１２月１１日（火）の６：００、すなわち低負荷確認期間ＴＬとなっている。またモニタリングしたノード間のリンクは、第１のネットワークのノード２１とノード２２間、ノード２２とノード２３間、ノード２３とノード２４間、ノード２４とノード２５間、ノード２５とノード２１間、となっていることを示している。また、ＷＡＮ消費帯域履歴データベース２４５Ａに記載した消費帯域は、１分毎の各リンクにおける平均消費帯域を表している。さらに、図１９では、左回りの通信経路における消費帯域の履歴を示したＷＡＮ消費帯域履歴データベース２４５Ａであるが、同様に、図示していない右回りの通信経路における消費帯域の履歴を示したＷＡＮ消費帯域履歴データベース２４５Ｂも作成する。

図２０は、本発明の第１の実施形態におけるＷＡＮが消費する予想リソース量の一例を示す説明図である。図２０に示したＷＡＮ消費帯域予測データベース２４６Ａでは、図示していないが、予測した期間が２０１２年１２月１７日（月）の２０：００から１２月１８日（火）の６：００、すなわち低負荷確認期間ＴＬとなっている。またモニタリングしたノード間のリンクは、第１のネットワークのノード２１とノード２２間、ノード２２とノード２３間、ノード２３とノード２４間、ノード２４とノード２５間、ノード２５とノード２１間、となっていることを示している。また、ＷＡＮ消費帯域予測データベース２４６Ａに記載した予測消費帯域は、１分毎の各リンクにおける平均消費帯域の予測値を表している。さらに、図２０では、左回りの通信経路における消費帯域の予測値を示したＷＡＮ消費帯域予測データベース２４６Ａであるが、同様に、図示していない右回りの通信経路における消費帯域の予測値を示したＷＡＮ消費帯域予測データベース２４６Ｂも作成する。

図２１は、本発明の第１の実施形態におけるＷＡＮの左回りに関する予想残リソース量の一例を示す図である。図２１に示したＷＡＮ帯域残量予測データベース２４７Ａでは、図示していないが、予測した期間が２０１２年１２月１７日（月）の２０：００から１２月１８日（火）の６：００、すなわち低負荷確認期間ＴＬとなっている。図２１の６０１に示された最少残帯域リソース量は、図２０に示したＷＡＮ消費帯域予測データベース２４６Ａにおいて、前記予測した期間ＴＬにおける第１のネットワークの左回りに対する最少の帯域量をデータベース化したものである。

図２２は、本発明の第１の実施形態におけるＷＡＮの右回りに関する予想残リソース量の一例を示す図である。図２２に示したＷＡＮ帯域残量予測データベース２４７Ｂでは、図示していないが、予測した期間が２０１２年１２月１７日（月）の２０：００から１２月１８日（火）の６：００、すなわち低負荷確認期間ＴＬとなっている。図２２の６０２に示された最少残帯域リソース量は、図示していないが、ＷＡＮ消費帯域予測データベース２４６Ｂにおいて、前記予測した期間ＴLにおける第１のネットワークの右回りに対する最少の帯域量をデータベース化したものである。

本実施例によれば、計算機システムにおいて、サービスを提供する仮想計算機を、計算機リソースのみならず、前記仮想計算機を移動した場合に、低負荷確認期間で計算機のみならずデータセンタ間を接続するネットワークに問題が発生しない場合に限り、且つ省電力化を達成する計算機上へ仮想計算機を移動することができる。したがって、仮想計算機が提供するエンドユーザへのサービスの品質を劣化させることなく、計算機システムの省電力化を達成できる。また、複数存在するデータセンタ内の膨大な計算機群の中から、予め条件に適する計算機を選別し、サービスを提供する仮想計算機移動可能か否かを少量の計算器量にて判定することができる。したがって、サービスを提供する仮想計算機の移動先を高速、短時間にて判定でき、且つ仮想計算機の省電力な配置を長時間に設定することができる。

本発明の第２の実施形態について、図２３乃至図２５を参照して説明する。第２の実施形態では、第１の実施形態と異なり、特定のデータセンタ内に、データセンタ統合管理サーバが設けられている。
図２３は、第２の実施形態における計算機システムの構成例を示す図である。データセンタ統合管理サーバ１６０は、データセンタ３０内の第２のネットワーク１１のノード３６に接続されている。データセンタ統合管理サーバ１６０は、第１の実施形態における各管理サーバ１３０、１４０、１５０が処理していた機能の一部を集約したものである。

図２４は、データセンタ統合管理サーバ１６０を含む計算機システムの機能ブロックを示している。データセンタ統合管理サーバ１６０は、第１のネットワーク１０を介してＷＡＮ管理サーバ３に接続され、各データセンタ内の管理サーバ１３０、１４０、１５０を統合管理する。各データセンタ管理サーバ１３０、１４０、１５０には、第２のネットワーク１１、１２、１３を介して物理サーバ１３１、１４１、１５１やネットワークノード１３８、１４８，１５８が接続されている。ネットワークノード１３８、１４８、１５８は第２のネットワーク１１の各ノード３２、３３、等に相当する。データセンタ統合管理サーバ１６０は、主な機能として、データセンタ省電力化順位制御部、ＷＡＮ管理サーバ連携部、データセンタ管理サーバ連携部を備え、省電力化制御開始前の各データセンタ内の状態のモニタリング、各データセンタの省電力化処理の順序の決定、及び移動予定のＶＭに関する情報や移動先候補の物理サーバ情報等をＷＡＮ管理サーバへ通知等を行う。ＷＡＮ管理サーバ３は、ＷＡＮ状態モニタリング部、ＷＡＮ状態履歴保持部、ＷＡＮ負荷予測部及びＷＡＮ状態回答部を備えている。このＷＡＮ管理サーバ３の構成は図３に示した第１の実施形態のＷＡＮ管理サーバ３の構成例と表現が若干異なるが、全体として両者は処理事項が同じである。各データセンタ管理サーバ１３０、１４０、１５０は、ＤＣ状態モニタリング部、ＤＣ状態履歴保持部、ＤＣ負荷予測部、ＤＣ統合管理サーバ連携部、他ＤＣ管理サーバ連携部、サーバ省電力化制御部、及び、指定ＶＭ収容先判定部を備えている。これらデータセンタ管理サーバの構成は図２に示した第１の実施形態のデータセンタ管理サーバ１３０の構成例と表現が若干異なるが、データセンタ統合管理サーバ１６０に移行した機能を除いて、全体として両者は処理事項が同じである。

図２５は、第２の実施形態における計算機システム全体の処理の流れを説明するシーケンス図である。本実施形態では、データセンタＡ管理サーバ１３０が、データセンタ統合管理サーバ１６０の管理の下で、自データセンタ内のＶＭを、他のデータセンタＢ、或いはデータセンタＣ内の物理サーバへ移動する処理を示す。

ＷＡＮ管理サーバ３は、ＷＡＮ状態のモニタリング、ＷＡＮ内の将来の負荷予測、ＷＡＮ内の将来の残帯域算出の処理を行う。各データセンタ管理サーバ１３０、１４０、１５０は、各データセンタ内のリソースの消費状態をモニタリングし、各ＶＭに対するＶＭ消費リソース履歴データベースを構成する。また、各データセンタ内におけるＶＭリソース消費履歴データベースから、各ＶＭにおける将来のリソース消費（負荷）を予測し、ＶＭ消費リソース予測データベースを構成する。さらに、図５にて示した低負荷確認期間（ＴＬ）２６０に関して、ＶＭ消費リソース予測データベースから、各ＶＭが必要とする最大のリソース量を示すＶＭ必要リソース予測データベースを構成する。これらの処理が、省電力化制御の前に予め実行される。データセンタ統合管理サーバ１６０は、データセンタ毎の省電力化制御の順序を決定し、初めに実行するデータセンタ管理サーバへ通知する。通知を受けたデータセンタ管理サーバは、データセンタ内に存在する全てのＶＭに対して、他のデータセンタへ移動するか否かを判定するための順序を決定する。本実施形態では、データセンタＡ管理サーバ１３０は、データセンタ統合管理サーバ１６０からの指示に従い、第１番目の移動予定ＶＭに対して、将来に必要なリソース量をＶＭ必要リソース予測データベース２４２から取得する。以降の、ＷＡＮ管理サーバ３及び各データセンタ管理サーバ１３０、１４０、１５０における処理は、実施例１と同様である。
本実施形態においても、実施形態１と同様な効果がある。また、各データセンタの全体を集中管理することで、各データセンタにおける省電力化制御のタイミングを適切に制御できる。

２…エンドユーザ端末、
３…ＷＡＮ管理装置、
１０…第１のネットワーク（ＷＡＮ）、
１１、１２、１３…第２の（データセンタ）ネットワーク、
２１、２２、２３、２４、２５…ノード、
３０、４０、５０…データセンタ、
３１、３２、３３、３４、３５、３６…ノード、
４１、４２、４３、４４、４５…ノード、
５１、５２、５３、５４、５５…ノード、
１３０、１４０、１５０…データセンタ管理サーバ、
１３１、１３５、１４１、１４５、１５１、１５５…物理サーバ、
１３２、１３６、１４２、１４６、１５２、１５６…仮想サーバ（ＶＭ）、
２３０…省電力配置制御処理プログラム、
２３１…省電力配置解除処理プログラム、
２３２…データセンタ管理サーバ省電力化応答処理プログラム、
２３３…ＶＭ配置とサーバ電源管理処理、
２３４…リソースモニタリング処理プログラム、
２３５…リソース消費予測処理プログラム
２３６…ＷＡＮ内輻輳判定処理プログラム、
２３７…ＷＡＮ内リソースモニタリング処理プログラム、
２３８…ＷＡＮ内リソース消費予測処理プログラム、
２３９…ＷＡＮ内帯域残量予測処理プログラム、
２４０…ＶＭ消費リソース履歴データベース情報、
２４１…ＶＭ消費リソース予測データベース情報、
２４２…ＶＭ必要リソース予測データベース情報、
２４３…物理サーバリソース残量予測データベース情報、
２４４…データセンタリソース残量予測データベース情報、
２４５…ＷＡＮ消費帯域履歴データベース、
２４６…ＷＡＮ消費帯域予測データベース、
２４７…ＷＡＮ帯域残量予測データベース、
２６０…低負荷確認期間ＴL、
２６１…高負荷確認期間ＴH。

Claims (15)

1. 複数のデータセンタと前記複数のデータセンタを接続する第１のネットワークとを備えた計算機システムであって、
   前記データセンタ毎に設けられ当該データセンタ内のリソースを管理するリソース管理装置と、
   前記第１のネットワークを管理するネットワーク管理装置と、
   前記各データセンタ内に存在する移動予定の仮想計算機が必要とするリソース量を取得する手段とを有し、
   前記データセンタの１つを管理する第１の前記リソース管理装置は、
   管理下の前記１つのデータセンタにおける前記移動予定の仮想計算機が必要とするリソース量を、該他のデータセンタを管理する第２の前記リソース管理装置へ通知する機能と、
   前記必要なリソース量の情報に応答して前記第２のリソース管理装置において選定された、前記移動予定の仮想計算機を稼動することが可能な少なくとも１つの物理計算機の候補の情報を受信する機能と、
   前記受信した前記仮想計算機の移動先候補の情報を、前記ネットワーク管理装置へ通知する機能とを有し、
   前記ネットワーク管理装置は、
   当該システムを利用するエンドユーザから前記受信した移動先候補毎の前記物理計算機へのデータ送受信において、前記第１のネットワーク内に問題が発生するか否かを判定し、該判定の結果を前記第１のリソース管理装置へ通知する機能を有し、
   前記第１のリソース管理装置は、さらに、
   前記移動先候補物理計算機候補の情報と前記の判定の結果とから、省電力化を達成する上位の少なくとも１つの物理計算機を、前記移動予定の仮想計算機の移動先として選択する機能を有する
   ことを特徴とする計算機システム。
2. 請求項１において、
   前記第１のリソース管理装置は、
   管理下の前記データセンタ内に存在する仮想計算機が移動予定の時間帯おいて前記仮想計算機が必要とするリソース量を取得する機能と、
   前記複数の仮想計算機の移動先物理計算機候補の中から、上位の所定数に絞った数の前記物理計算機候補を選択し、該選択した物理計算機情報を前記ネットワーク管理装置へ通知する機能とを有し、
   前記ネットワーク管理装置における前記判定において、前記移動予定の時間帯に前記第１のネットワーク内に問題が発生するか否かを判定する
   ことを特徴とする計算機システム。
3. 請求項２において、
   前記第１のリソース管理装置は、
   前記第２のリソース管理装置から受信した前記仮想計算機の移動先物理計算機候補、及び、自データセンタ内の少なくとも１つの仮想計算機の移動先物理計算機候補とから、前記上位の所定数の物理計算機候補を選択する機能を有する
   ことを特徴とする計算機システム。
4. 請求項１において、
   前記第１のリソース管理装置は、
   前記移動予定の仮想計算機を収容している物理計算機の電力効率を前記第２のリソース管理装置へ通知する機能を有し、
   前記第２のリソース管理装置は、
   前記受信した前記電力効率に応答して、該電力効率以上でかつ前記仮想計算機を稼動することが可能な物理計算機の候補の情報を選定し、前記第１のリソース管理装置へ送信する機能を有する
   ことを特徴とする計算機システム。
5. 請求項１において、
   前記第１のリソース管理装置は、管理する仮想計算機全てに対して移動の可否を決定した後に、該配置換えを予定する仮想計算機の移動を実行する機能を有する
   ことを特徴とする計算機システム。
6. 請求項１において、
   前記第２のリソース管理装置は、
   前記移動予定の仮想計算機を稼動することが可能な同一のデータセンタ内における物理計算機の候補として、前記第１のネットワーク上において異なる通信経路を利用する複数の前記物理計算機候補を選定する機能を有する
   ことを特徴とする計算機システム。
7. 請求項６において、
   前記第１のネットワークがリング型のネットワークであり、
   前記他のデータセンタのリソースを管理する前記第２のリソース管理装置は、仮想計算機を稼動可能な物理計算機の候補を、前記第１のネットワークにおける左回りの通信経路および右回りの通信経路を利用する物理計算機の候補をそれぞれ一台以上選定する機能を有する
   ことを特徴とする計算機システム。
8. 請求項１において、
   前記第２のリソース管理装置は、
   管理する物理計算機を電力効率順に管理し、前記第１のリソース管理装置から移動予定の仮想計算機が必要とするリソース量を受信した場合、前記電力効率順に前記仮想計算機が必要とするリソースを提供可能な物理計算機を探索する機能を有する
   ことを特徴とする計算機システム。
9. 請求項１において、
   前記各データセンタは、当該データセンタ内のリソースとして第２のネットワーク含んでおり、
   前記第２のリソース管理装置は、
   管理する前記物理計算機のうち、所定以上の残リソースを有しない前記物理計算機を、前記移動予定の仮想計算機を収容する物理計算機としてのリストから除外する
   ことを特徴とする計算機システム。
10. 請求項１において、
    前記第２のリソース管理装置は、
    前記第１のリソース管理装置から受信した移動予定の仮想計算機を、該仮想計算機の移動時間を含めた期間の間において収容可能かを判定することにより、前記移動予定の仮想計算機を稼動可能な物理計算機を選定する
    ことを特徴とする計算機システム。
11. 請求項１において、
    前記第１のネットワークに接続されたデータセンタ統合管理サーバを備え、
    該データセンタ統合管理サーバは、
    前記各データセンタ内に存在する移動予定の仮想計算機が必要とするリソース量を取得する機能と、
    前記各データセンタの省電力化処理の順序を決定し、前記各データセンタに通知する機能とを有する
    ことを特徴とする計算機システム。
12. 第１のデータセンタ内のリソースを管理するリソース管理装置であって、
    前記第１のデータセンタは、ネットワーク管理装置により制御される第１のネットワークを介して、計算機システムを構成する複数の第２のデータセンタと接続可能に構成されており、
    前記リソース管理装置は、
    前記第１のデータセンタ内に存在する移動予定の仮想計算機が必要とするリソース量を取得する手段と、
    前記取得した移動予定の仮想計算機が必要とするリソース量を前記第２のデータセンタの第２のリソース管理装置へ通知する手段と、
    前記第２のリソース管理装置から前記移動予定の仮想計算機を収容可能な物理計算機の候補情報を受信する手段と、
    前記受信した仮想計算機を収容可能な物理計算機の候補に対して前記移動予定の前記仮想計算機を移動した場合に前記第１のネットワークに問題が発生しないかを、前記ネットワーク管理装置へ問い合わせる手段と、
    前記物理計算機候補の情報と前記問い合わせた結果とから、省電力化を達成する上位の少なくとも１つの物理計算機へ、前記移動予定の仮想計算機を配置するように決定する手段とを有する
    ことを特徴とするデータセンタ内のリソース管理装置。
13. 請求項１２において、
    前記リソース管理装置は、
    前記第２のリソース管理装置から受信した前記仮想計算機の移動先物理計算機候補、及び、自データセンタ内の少なくとも１つの仮想計算機の移動先物理計算機候補とから、前記上位の所定数の物理計算機候補を選択し、
    該選択した物理計算機情報に関し、移動予定の時間帯に前記仮想計算機を移動した場合に前記第１のネットワークに問題が発生しないかを、前記ネットワーク管理装置へ問い合わせる
    ことを特徴とするデータセンタ内のリソース管理装置。
14. 複数のデータセンタと前記複数のデータセンタを接続する第１のネットワークとを備えた計算機システムにおけるリソース管理方法であって、
    前記計算機システムは、
    前記データセンタ毎に設けられ当該データセンタ内のリソースを管理するリソース管理装置と、
    前記第１のネットワークを管理するネットワーク管理装置とを有しており、
    前記データセンタの１つを管理する第１の前記リソース管理装置が、
    管理下の前記データセンタ内に存在する移動予定の仮想計算機が必要とするリソース量を取得し、
    前記取得した移動予定の仮想計算機が必要とするリソース量を他の前記データセンタを管理する第２のリソース管理装置へ通知し、
    前記第２のリソース管理装置が、移動予定の仮想計算機を稼動することが可能な物理計算機の候補を１乃至複数選定し、前記第１のリソース管理装置へ通知し、
    前記第１のリソース管理装置は、前記第２の前記リソース管理装置から受信した前記仮想計算機の移動先候補の情報を、前記ネットワーク管理装置へ通知し、
    前記ネットワーク管理装置は、当該システムを利用するエンドユーザから前記受信した移動先候補毎の前記物理計算機へのデータ送受信において、前記第１のネットワーク内に問題が発生するか否かを判定し、該判定の結果を前記第１のリソース管理装置へ通知し、
    前記第１のリソース管理装置は、前記移動先候補物理計算機と前記の判定の結果とから最も省電力化を達成する少なくとも１つの物理計算機を、前記移動予定の仮想計算機の移動先として選択する
    ことを特徴とする計算機システムにおけるリソース管理方法。
15. 請求項１４において、
    前記第１のリソース管理装置は、
    管理下の前記データセンタ内に存在する移動予定の仮想計算機が必要とするリソース量を取得し、
    前記第２のリソース管理装置から受信した前記仮想計算機の移動先物理計算機候補、及び、自データセンタ内の少なくとも１つの仮想計算機の移動先物理計算機候補とから、前記上位の所定数の物理計算機候補を選択し、
    移動予定の時間帯に前記仮想計算機を移動した場合に前記第１のネットワークに問題が発生しないかを、前記ネットワーク管理装置へ問い合わせる
    ことを特徴とする計算機システムにおけるリソース管理方法。

Images