JP5892031B2 - リソース管理システム、リソース管理方法、およびリソース管理プログラム - Google Patents

Description

本発明は、リソース管理システム、リソース管理方法、およびリソース管理プログラムに関する。

データセンタ（ＤＣ：Ｄａｔａ Ｃｅｎｔｅｒ）は、サーバ、ストレージ装置、ルータ、スイッチ等の複数のリソースが設置された施設である。たとえば、ＤＣでは、ＤＣ内のサーバがユーザのアプリケーションを実行する仮想マシンを起動し、仮想マシンがアプリケーションを実行することにより、ユーザが要求するシステムをユーザに提供する。

たとえば、ＤＣにおいて、最適化のためのポリシーと、アプリケーションに依存するポリシーとを考慮して、アプリケーションが稼働する仮想マシンを稼働させたまま、アプリケーションを移行する技術がある。また、リソースの余剰ポリシーの変更に応じて、仮想マシンの配置案を生成し、物理マシンのリソースとネットワーク機器のリソースの両方について、リソースの使用量をシミュレーションする技術がある。さらに、複数のサーバが複数の仮想サーバを実行するシステムにて、仮想サーバ間の通信量を計測し、仮想サーバを他のサーバに割り当てた場合に通信量に基づく平均消費コストを算出して、平均消費コストが下がる他のサーバに仮想サーバを再割当する技術がある。（たとえば、下記特許文献１〜３を参照。）

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

しかしながら、上記した技術によれば、ユーザからの要求に応じて新たなシステムをＤＣに構築する際に、ＤＣに空きリソースがあるにも関わらず要求された性能を満たすシステムを構築できず、ＤＣのリソースが有効活用されない場合がある。

１つの側面では、本発明は、データセンタのリソースを有効活用してシステムを構築するリソース管理システム、リソース管理方法、およびリソース管理プログラムを提供することを目的とする。

一側面によれば、システムの性能情報を参照して、第１のデータセンタのリソースを利用して実現される第１のシステムの一部の機能構成を第２のデータセンタのリソースを利用して実現しても第１のシステムに対応する第１の性能情報を満たすか否かを判断し、第１の性能情報を満たすと判断した場合、第２のデータセンタのリソースを利用して一部の機能を実現することで、第１の性能情報を満たす構成システムを第１のデータセンタのリソースと第２のデータセンタのリソースとを利用して構築するリソース管理システム、リソース管理方法、およびリソース管理プログラムが提案される。

一態様によれば、データセンタのリソースを有効活用してシステムを構築することができるという効果を奏する。

図１は、本実施の形態にかかるリソース管理システムの動作例を示す説明図である。 図２は、クラウドシステムのシステム構成例を示す説明図である。 図３は、リソース管理装置のハードウェア構成例を示すブロック図である。 図４は、リソース管理装置の機能構成例を示すブロック図である。 図５は、テナントの仮想システム情報の記憶内容の一例を示す説明図である。 図６は、新規テナントの構築要求のメッセージの一例を示す説明図である。 図７は、新規テナント用の仮想システム情報の記憶内容の一例を示す説明図である。 図８は、トンネリング設定情報の記憶内容の一例を示す説明図である。 図９は、運用ポリシーの設定要求の一例を示す説明図である。 図１０は、新規テナントの構築要求が行われた場合の各テナントの状態例を示す説明図である。 図１１は、新規テナントの構築要求が行われた場合のクラウドシステムの状態例を示す説明図である。 図１２は、新規テナントの構築要求が行われた場合の構築先ＤＣの選択例を示す説明図である。 図１３は、新規テナントの構築要求が行われた場合の移行対象構成の選択例を示す説明図である。 図１４は、新規テナントの構築要求が行われた場合の選択結果に従った移行処理例を示す説明図（その１）である。 図１５は、新規テナントの構築要求が行われた場合の選択結果に従った移行処理例を示す説明図（その２）である。 図１６は、新規テナントの構築要求が行われた場合の移行処理の結果を示す説明図である。 図１７は、新規テナントの構築要求が行われた場合のリソース配備処理手順の一例を示すフローチャートである。 図１８は、構築先ＤＣ選択処理手順の一例を示すフローチャートである。 図１９は、移行対象構成選択処理手順の一例を示すフローチャートである。 図２０は、移行対象構成の移行指示処理手順の一例を示すフローチャートである。 図２１は、新規テナントの構築指示処理手順の一例を示すフローチャートである。 図２２は、運用ポリシーの設定要求が行われた場合のクラウドシステムの状態例を示す説明図である。 図２３は、運用ポリシーの設定要求が行われた場合の運用ポリシーの変更を反映した状態を示す説明図である。 図２４は、運用ポリシーの設定要求が行われた場合のテナントの移行先ＤＣの選択例を示す説明図である。 図２５は、運用ポリシーの設定要求が行われた場合の選択結果に従った移行処理例を示す説明図（その１）である。 図２６は、運用ポリシーの設定要求が行われた場合の選択結果に従った移行処理例を示す説明図（その２）である。 図２７は、運用ポリシーの設定要求が行われた場合の移行処理の結果を示す説明図である。 図２８は、運用ポリシーの設定要求が行われた場合のリソース配備処理手順の一例を示すフローチャートである。 図２９は、運用ポリシー適用処理手順の一例を示すフローチャートである。

以下に添付図面を参照して、開示のリソース管理システム、リソース管理方法、およびリソース管理プログラムの実施の形態を詳細に説明する。

図１は、本実施の形態にかかるリソース管理システムの動作例を示す説明図である。リソース管理システム１００は、複数のＤＣ（Ｄａｔａ Ｃｅｎｔｅｒ）を有するシステムである。リソース管理システム１００は、ユーザからの要求に応じて、複数のＤＣのリソースの中から、ユーザの要求を満たすシステムを構築して、ユーザに提供するシステムである。リソース管理システム１００内にあるリソース管理装置１０１は、複数のＤＣを制御するコンピュータである。

ＤＣは、各種のコンピュータやデータ通信などの装置を運用する装置を備えている。以下、ユーザからの要求に応じて構築される各システムを、「テナント」と称する。ＤＣは、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）や、ストレージ等のリソース等を含む。そして、ＤＣのリソースにより実現される構成により、システムの機能が実現される。ＤＣのリソースにより実現される構成としては、たとえば、仮想的な装置である仮想マシン（ＶＭ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）や、論理ボリュームが挙げられる。

リソース管理システム１００内のリソース管理装置１０１は、新たなテナントを構築できない場合に、第１のＤＣのリソースを利用して実現される構成を第２のＤＣに移行しても、構築済のテナントの性能情報を満たすか否かを判断する。構築済のテナントの性能情報を満たす場合、リソース管理装置１０１は、該当の構成を第１のＤＣから第２のＤＣに移行した結果、第１のＤＣのリソースを利用して実現される構成により新たなシステムを構築する。この動作について、図１の（Ａ）〜図１の（Ｃ）を用いて説明する。

図１の（Ａ）にて、リソース管理システム１００は、ＤＣ１とＤＣ２を有する。ＤＣ１は、構成として、ＶＭ１−１、ボリュームＶＯ１−１、ボリュームＶＯ１−２を有する。さらに、ＤＣ１は、ＶＭ１−１とボリュームＶＯ１−１とから構築されるテナントＴａを有する。図１では、テナントが行うサービスを模式的に店舗のイラストにて示す。たとえば、店舗Ｓａは、ＶＭ１−１とボリュームＶＯ１−１を用いて提供されるサービスである。

また、ＤＣ２は、構成として、ＶＭ２−１、ＶＭ２−２、ボリュームＶＯ２−１、ボリュームＶＯ２−２を有する。さらに、ＤＣ２は、ＶＭ２−１とボリュームＶＯ２−１とから構築されるテナントＴｂを有する。店舗Ｓｂは、ＶＭ２−１とボリュームＶＯ２−１を用いて提供されるサービスである。リソース管理装置１０１は、ＶＭ１つとボリューム１つというＴａの性能情報と、ＶＭ１つとボリューム１つというＴｂの性能情報と、を記憶する。

このような状態で、リソース管理装置１０１は、第１のＤＣとしてＤＣ１に、１つのＶＭと、１つのボリュームから構成される新規テナントＴｃの構築要求を行う。しかしながら、ＤＣ１には、利用されていないＶＭがないため、新規テナントＴｃが構築できない。

次に、図１の（Ｂ）にて、新規テナントＴｃが構築できない場合に、リソース管理装置１０１は、Ｔａの性能情報を参照して、ＤＣ１のリソースを利用して実現される構成を第２のＤＣとしてＤＣ２に移行してもＴａの性能情報を満たすか否かを判断する。図１の（Ｂ）では、リソース管理装置１０１は、ＤＣ１内のＶＭ１−１をＤＣ２内のＶＭ２−２に移行してもＶＭ１つとボリューム１つというＴａの性能情報を満たすと判断する。Ｔａの性能情報を満たすと判断した場合、リソース管理装置１０１は、ＶＭ１−１をＤＣ２内のＶＭ２−２に移行する。これにより、Ｔａは、ＶＭ２−２とボリュームＶＯ１−１から構築されることになる。

続けて、図１の（Ｃ）にて、ＶＭ１−１をＤＣ２内のＶＭ２−２に移行した結果、ＶＭ１−１を実現していたリソースが解放されたため、リソース管理装置１０１は、ＶＭ１−１とボリュームＶＯ１−２によりテナントＴｃを構築する。

（クラウドシステムのシステム構成例）
次に、図１に示したリソース管理システム１００をクラウドシステムに適用した場合について説明する。

図２は、クラウドシステムのシステム構成例を示す説明図である。クラウドシステム２００は、リソース管理装置１０１と、ＤＣ１〜ＤＣ３と、ユーザ用端末２１１と、管理用端末２１２と、を含む。リソース管理装置１０１とＤＣ１〜ＤＣ３とは、ネットワーク２０１にてそれぞれ接続される。また、図２では図示していないが、リソース管理装置１０１は、ユーザ用端末２１１と、管理用端末２１２とも、ネットワークにてそれぞれ接続される。ＤＣ１〜ＤＣ３は、ルータｒ１、ルータｒ２、ルータｒ３により接続される。

ＤＣ１は、ルータｒ１と、コアスイッチｃｓｗ１と、スイッチｓｗ１０と、スイッチｓｗ１１と、物理マシンｐｍ１０と、物理マシンｐｍ１１と、ストレージ装置ｓｔ１０と、ストレージ装置ｓｔ１１と、を含む。続けて、ＤＣ１内の接続関係について説明する。ルータｒ１は、コアスイッチｃｓｗ１と接続する。コアスイッチｃｓｗ１は、ルータｒ１と、スイッチｓｗ１０と、スイッチｓｗ１１とに接続する。スイッチｓｗ１０は、コアスイッチｃｓｗ１と、物理マシンｐｍ１０と、物理マシンｐｍ１１とに接続する。スイッチｓｗ１１は、コアスイッチｃｓｗ１と、ストレージ装置ｓｔ１０と、ストレージ装置ｓｔ１１とに接続する。

ＤＣ２は、ルータｒ２と、コアスイッチｃｓｗ２と、スイッチｓｗ２０と、スイッチｓｗ２１と、物理マシンｐｍ２０と、物理マシンｐｍ２１と、ストレージ装置ｓｔ２０と、ストレージ装置ｓｔ２１と、を含む。ＤＣ２内の接続関係は、ＤＣ１内の接続関係において、符号“１ｘ”が“２ｘ”に置き換わったものと同一であるため、説明は省略する。

ＤＣ３は、ルータｒ３と、コアスイッチｃｓｗ３と、スイッチｓｗ３０と、スイッチｓｗ３１と、物理マシンｐｍ３０と、ストレージ装置ｓｔ３０と、を含む。続けて、ＤＣ３内の接続関係について説明する。ルータｒ３は、コアスイッチｃｓｗ３と接続する。コアスイッチｃｓｗ３は、ルータｒ３と、スイッチｓｗ３０と、スイッチｓｗ３１とに接続する。スイッチｓｗ３０は、コアスイッチｃｓｗ３と、物理マシンｐｍ３０に接続する。スイッチｓｗ３１は、コアスイッチｃｓｗ３と、ストレージ装置ｓｔ３０とに接続する。

ルータｒ１〜ルータｒ３は、ネットワーク間を相互接続する装置である。以下、ネットワークを、単に、「ＮＷ」と記載する場合がある。スイッチｓｗ１０〜スイッチｓｗ３１は、パケットの交換機能を持った装置である。コアスイッチは、スイッチの一種であり、中心的なネットワーク内部でのデータ転送や、データの中継に用いられる装置である。

物理マシンｐｍ１０〜物理マシンｐｍ３０は、５つのＶＭを実行することができる。また、ストレージ装置ｓｔ１０〜ストレージ装置ｓｔ３０は、１つ２００［ＧＢ］のボリュームＶＯを５つ生成することができる。以下、テナントを構築する構成は、該当の構成の符号の後ろに、テナントの符号を結合することにより表すこととする。たとえば、テナントＴａを構築する１番目のＶＭは、ＶＭａ１と表記する。

また、リソース管理装置１０１は、クラウドシステム２００内に、テナントＴａ、テナントＴｂ、テナントＴｃという３つのテナントを構築する。テナントＴａは、物理マシンｐｍ１０のＶＭａ１〜ＶＭａ５と、ストレージ装置ｓｔ１０のボリュームＶＯａ１〜ボリュームＶＯａ５により構築される。テナントＴｂは、物理マシンｐｍ２０のＶＭｂ１〜ＶＭｂ５と、物理マシンｐｍ２１のＶＭｂ６と、ストレージ装置ｓｔ２０のボリュームＶＯｂ１〜ボリュームＶＯｂ５と、ストレージ装置ｓｔ２１のボリュームＶＯｂ６により構築される。テナントＴｃは、物理マシンｐｍ３０のＶＭｃ１〜ＶＭｃ３と、ストレージ装置ｓｔ３０のボリュームＶＯｃ１〜ボリュームＶＯｃ３により構築される。

ユーザ用端末２１１は、ユーザによって操作される端末である。ユーザ用端末２１１は、ユーザの操作によって、新規テナントの構築要求２２１をリソース管理装置１０１に送信する。新規テナントの構築要求２２１の具体例は、図６にて後述する。管理用端末２１２は、クラウドシステム２００の管理者によって操作される端末である。管理用端末２１２は、管理者の操作によって、運用ポリシーの設定要求２２２をリソース管理装置１０１に送信する。運用ポリシーの設定要求２２２の具体例は、図９にて後述する。

（リソース管理装置のハードウェア）
図３は、リソース管理装置のハードウェア構成例を示すブロック図である。図４において、リソース管理装置１０１は、ＣＰＵ３０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０３と、を含む。また、リソース管理装置１０１は、ディスクドライブ３０４およびディスク３０５と、通信インターフェース３０６と、を含む。また、ＣＰＵ３０１〜通信インターフェース３０６はバス３０７によってそれぞれ接続される。また、図３では図示していないが、ルータｒ１〜ルータｒ３、コアスイッチｃｓｗ１〜コアスイッチｃｓｗ３、スイッチｓｗ１０〜スイッチｓｗ３１、物理マシンｐｍ１０〜ストレージ装置ｓｔ３０も、リソース管理装置１０１と同様のハードウェアを有する。

ＣＰＵ３０１は、リソース管理装置１０１の全体の制御を司る演算処理装置である。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶する不揮発性メモリである。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される揮発性メモリである。

ディスクドライブ３０４は、ＣＰＵ３０１の制御に従ってディスク３０５に対するデータのリードおよびライトを制御する制御装置である。ディスクドライブ３０４には、たとえば、磁気ディスクドライブ、ソリッドステートドライブなどを採用することができる。ディスク３０５は、ディスクドライブ３０４の制御で書き込まれたデータを記憶する不揮発性メモリである。たとえばディスクドライブ３０４が磁気ディスクドライブである場合、ディスク３０５には、磁気ディスクを採用することができる。また、ディスクドライブ３０４がソリッドステートドライブである場合、ディスク３０５には、半導体素子メモリを採用することができる。

通信インターフェース３０６は、ＮＷ２０１と内部のインターフェースを司り、他の装置からのデータの入出力を制御する制御装置である。具体的に、通信インターフェース３０６は、通信回線を通じてＮＷ２０１となるＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどに接続され、ＮＷ２０１を介して他の装置に接続される。通信インターフェース３０６には、たとえば、モデムやＬＡＮアダプタなどを採用することができる。また、リソース管理装置１０１は、光ディスクドライブ、光ディスク、キーボード、マウスを有していてもよい。また、ユーザ用端末２１１と、管理用端末２１２も、光ディスクドライブ、光ディスク、キーボード、マウスを有していてもよい。

（リソース管理装置１０１の機能）
次に、リソース管理装置１０１の機能について説明する。図４は、リソース管理装置の機能構成例を示すブロック図である。リソース管理装置１０１は、受付部４０１と、判断部４０２と、負荷量算出部４０３と、通信量算出部４０４と、選択部４０５と、構築部４０６と、を含む。制御部となる受付部４０１〜構築部４０６は、記憶装置に記憶されたプログラムをＣＰＵ３０１が実行することにより、受付部４０１〜構築部４０６の機能を実現する。記憶装置とは、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ディスク３０５などである。

また、リソース管理装置１０１は、記憶部４１０にアクセス可能である。記憶部４１０は、ＲＡＭ３０３、ディスク３０５といった記憶装置に格納される。また、記憶部４１０は、ユーザからの要求に応じたテナントの性能情報を記憶するテナントの仮想システム情報４１１、トンネリング設定情報４１２を含む。また、記憶部４１０は、複数の構成の各々の構成間で発生した通信量を記憶していてもよい。テナントの仮想システム情報４１１の記憶内容の一例は、図５にて後述する。トンネリング設定情報４１２の記憶内容の一例は、図８にて後述する。

受付部４０１は、ユーザ用端末２１１から、新規テナントの構築要求２２１を受け付ける。また、受付部４０１は、管理用端末２１２から、運用ポリシーの設定要求２２２を受け付ける。受け付けた新規テナントの構築要求２２１、運用ポリシーの設定要求２２２は、ＲＡＭ３０３、ディスク３０５などの記憶領域に記憶される。

判断部４０２は、記憶部４１０に記憶される性能情報を参照して、第１のＤＣのリソースを利用して実現される第１のテナントの一部の機能構成を第２のＤＣのリソースを利用して実現しても第１のテナントに対応する第１の性能情報を満たすか否かを判断する。また、判断部４０２は、受付部４０１によって新規テナントの構築要求２２１を受け付けた結果、複数のＤＣのいずれか一つのＤＣに新たなテナントを構築できない場合に、判断を行ってもよい。さらに、判断部４０２は、受付部４０１によって運用ポリシーの設定要求２２２を受け付けた結果、複数のＤＣのいずれか一つのＤＣにて、リソースが利用できなくなって構築できなくなった新たなテナントがある場合に、判断を行ってもよい。なお、判断結果は、ＲＡＭ３０３、ディスク３０５などの記憶領域に記憶される。

負荷量算出部４０３は、次に記述する場合、第１の構成を第２のＤＣに移行する処理にかかる負荷量と、第２の構成を第２のＤＣに移行する処理にかかる負荷量とを算出する。次に記述する場合とは、判断部４０２によって第１のＤＣのリソースを利用して実現される第１の構成または第２の構成を第２のＤＣに移行しても第１の性能情報を満たすと判断された場合である。負荷量は、たとえば、移行するデータサイズに基づいて算出されてもよい。負荷量の算出例は、図１２にて後述する。

また、負荷量算出部４０３は、選択部４０５によって選択された移行対象構成を第２のＤＣとは異なる第３のＤＣに移行しても第１の性能情報を満たすと判断された場合、移行対象構成を第３のＤＣに移行する処理にかかる負荷量を算出してもよい。

また、負荷量算出部４０３は、次に示す場合、構成を第２のＤＣに移行する処理にかかる負荷量と、構成を第３のＤＣに移行する処理にかかる負荷量とを算出してもよい。次に示す場合とは、判断部４０２によって第１のＤＣのリソースを利用して実現される構成を第２のＤＣまたは第３のＤＣに移行しても第１の性能情報を満たすと判断された場合である。

また、負荷量算出部４０３は、さらに、第１のＤＣのリソースを利用して実現される構成とは異なる他の構成を移行先ＤＣに移行しても第１の性能情報を満たすと判断された場合、他の構成を移行先ＤＣに移行する処理にかかる負荷量を算出してもよい。算出された負荷量は、ＲＡＭ３０３、ディスク３０５などの記憶領域に記憶される。

通信量算出部４０４は、記憶部４１０に記憶される通信量に基づいて、第１の構成を第２のＤＣに移行した後に第１のＤＣと第２のＤＣとの間で発生する通信量を算出する。さらに、通信量算出部４０４は、第２の構成を第２のＤＣに移行した後に第１のＤＣと第２のＤＣとの間で発生する通信量とを算出する。通信量の算出例は、図１３にて後述する。なお、算出された通信量は、ＲＡＭ３０３、ディスク３０５などの記憶領域に記憶される。

選択部４０５は、負荷量算出部４０３によって算出された算出結果に基づいて、第１の構成または第２の構成のうち第１のＤＣから第２のＤＣに移行する移行対象構成を選択する。たとえば、第１の構成を第２のＤＣに移行する処理にかかる負荷量として、移行するデータサイズが、３０［ＭＢ］であり、第２の構成を第２のＤＣに移行する処理にかかる負荷量として、移行するデータサイズが、２０［ＭＢ］であるとする。この場合、選択部４０５は、負荷量が小さい第１の構成を移行対象構成として選択する。

また、選択部４０５は、負荷量算出部４０３によって算出された算出結果に基づいて、第２のＤＣまたは第３のＤＣのうち移行対象構成の移行先ＤＣを選択してもよい。また、選択部４０５は、通信量算出部４０４によって算出された算出結果に基づいて、第１の構成または第２の構成のうち第１のＤＣから第２のＤＣに移行する移行対象構成を選択してもよい。また、選択部４０５は、負荷量算出部４０３によって算出された算出結果に基づいて、第２のＤＣまたは第３のＤＣのうち構成を移行する移行先ＤＣを選択してもよい。また、選択部４０５は、負荷量算出部４０３によって算出された算出結果に基づいて、構成または他の構成のうち移行先ＤＣに移行する移行対象構成を選択してもよい。なお、算出された通信量は、ＲＡＭ３０３、ディスク３０５などの記憶領域に記憶される。

構築部４０６は、判断部４０２によって性能情報を満たすと判断された場合、第２のＤＣのリソースを利用して一部の機能を実現することで、第１の性能情報を満たす構成テナントを第１のＤＣのリソースと第２のＤＣのリソースとを利用して構築する。構成テナントとは、新しく構成されるテナントである。具体的に、構築部４０６は、通信用のトンネリング設定情報４１２を作成して、構成を第１のＤＣから第２のＤＣに移行して、第１のＤＣの空きリソースとなったリソースを利用して実現される構成により新たなテナントを構築する。また、新たなテナントが２つ以上のＤＣのリソースを利用する場合、構築部４０６は、サービス用のトンネリング設定情報４１２を作成する。

また、構築部４０６は、第２のＤＣのリソースを利用して選択部４０５によって選択された移行対象構成を実現することで、第１の性能情報を満たす構成テナントを第１のＤＣのリソースと第２のＤＣのリソースとを利用して構築してもよい。また、構築部４０６は、選択部４０５によって選択された移行先ＤＣのリソースを利用して移行対象構成を実現することで、第１の性能情報を満たす構成テナントを第１のＤＣのリソースと移行先データセンタのリソースとを利用して構築してもよい。また、構築部４０６は、選択部４０５によって選択された移行先データセンタのリソースを利用して構成を実現することで、第１の性能情報を満たす構成テナントを第１のＤＣのリソースと移行先ＤＣのリソースとを利用して構築してもよい。また、構築部４０６は、移行先ＤＣのリソースを利用して選択部４０５によって選択された移行対象構成を実現することで、第１の性能情報を満たす構成テナントを第１のＤＣのリソースと移行先ＤＣのリソースとを利用して構築してもよい。

図５は、テナントの仮想システム情報の記憶内容の一例を示す説明図である。図５に示すテナントの仮想システム情報４１１は、レコード５０１−１〜レコード５０１−３を有する。テナントの仮想システム情報４１１は、テナントＩＤと構成ＩＤという２つのフィールドを有する。テナントＩＤフィールドには、テナントを一意に識別する識別情報が格納される。構成ＩＤフィールドには、テナントを構築する構成を識別する識別情報が格納される。

たとえば、レコード５０１−１は、テナントＩＤがＴａであるテナントがＤＣ１内の物理マシンｐｍ１０のＶＭａ１〜ＶＭａ５と、ＤＣ１内の物理マシンｐｍ１１のＶＭａ６と、ＤＣ１内のストレージ装置ｓｔ１０により構築されることを示す。

図６は、新規テナントの構築要求のメッセージの一例を示す説明図である。図６に示す新規テナントの構築要求２２１のメッセージは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）により表現される。新規テナントの構築要求２２１のメッセージは、仮想システムが要求する性能情報を記憶する。

以下、図６に示す新規テナントの構築要求２２１のメッセージが記憶する性能情報について説明する。性能情報の一つであるＶＭのタイプは、＜Ｍａｃｈｉｎｅ＞タグ内の、＜ＲｅｑｕｉｒｅｄＴｙｐｅ＞タグ内に記憶される。ＶＭのタイプは、ＶＭ１つの処理性能を表す。たとえば、ＶＭのタイプに大きい値が設定された場合、該当のＶＭを実行するＣＰＵの個数が多くなる。また、性能情報の一つであるＶＭの個数は、＜Ｍａｃｈｉｎｅ＞タグ内の、＜ＲｅｑｕｉｒｅｄＮｕｍｂｅｒ＞タグで示される。

さらに、性能情報の一つであるＶＭが用いるボリュームサイズは、＜Ｖｏｌｕｍｅ＞タグ内の、＜ＲｅｑｕｉｒｅｄＳｉｚｅ＞タグで示される。また、性能情報の一つであるＮＷ帯域は、＜Ｎｅｔｗｏｒｋ＞タグ内の、＜ＲｅｑｕｉｒｅｄＢａｎｄｗｉｄｔｈ＞タグで示される。さらに、性能情報の一つであるＮＷ遅延時間は、＜ＲｅｑｕｉｒｅｄＭａｘＴｒａｆｆｉｃＤｅｌａｙ＞タグで示される。

図７は、新規テナント用の仮想システム情報の記憶内容の一例を示す説明図である。新規テナント用の仮想システム情報７０１は、構築要求のあった新規テナント用の仮想システムの構成の一覧を記憶する。図７に示す新規テナント用の仮想システム情報７０１は、レコード７０１−１〜レコード７０１−６を記憶する。

新規テナント用の仮想システム情報７０１は、構成ＩＤと、構成構築先という２つのフィールドを有する。構成ＩＤフィールドには、新規テナント用に構築された仮想システムの構成の識別情報が格納される。構成構築先フィールドには、構築された構成を実現するリソースの識別情報が格納される。

たとえば、レコード７０１−１は、新規テナント用に構築された仮想システムの構成ＩＤがＶＭｘ１となるＶＭが、ＤＣ１内の物理マシンｐｍ１０内にあることを示す。また、レコード７０１−６は、新規テナント用に構築された仮想システムの構成ＩＤがボリュームｘ１となるボリュームが、ＤＣ１内のストレージ装置ｓｔ１１に接続されたストレージに確保されたことを示す。

図８は、トンネリング設定情報の記憶内容の一例を示す説明図である。トンネリング設定情報４１２は、構成の移行時の通信用として、または仮想システムが複数のＤＣにより構築された場合に、サービス通信用として設定される。図８に示すトンネリング設定情報４１２は、レコード８０１−１〜レコード８０１−１２を記憶する。

トンネリング設定情報４１２は、設定元、トンネリング先ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスという２つのフィールドを含む。設定元フィールドには、トンネリング設定情報４１２が設定される構成の識別情報が格納される。構成の識別情報は、構成を一意に特定できるように割り振られるＩＰアドレスを用いてもよい。トンネリング先ＩＰアドレスフィールドには、通信先となる異なるセグメントの構成のＩＰアドレスが格納される。

たとえば、レコード８０１−１は、ＶＭａ２からＶＭａ１の通信用として、ＤＣ１内の物理マシンｐｍ１０のＶＭａ２から、異なるセグメントとなるＤＣ２内の物理マシンｐｍ２１のＶＭａ１へのトンネリング設定であることを示す。また、レコード８０１−２は、ＶＭａ１からＶＭａ２の通信用として、ＤＣ２内の物理マシンｐｍ２１のＶＭａ１から、異なるセグメントとなるＤＣ１内の物理マシンｐｍ１０のＶＭａ２へのトンネリング設定であることを示す。

図９は、運用ポリシーの設定要求の一例を示す説明図である。運用ポリシーの設定要求２２２は、システム管理者が操作する管理用端末２１２から発行される。図９に示す運用ポリシーの設定要求２２２は、ＤＣ３内の物理マシンｐｍ３０の保守要求である。

図１０は、新規テナントの構築要求が行われた場合の各テナントの状態例を示す説明図である。図１０では、クラウドシステム２００が、テナントＴａ、テナントＴｂ、テナントＴｃが構築済みであり、新規テナントＴｘの構築要求を受けた状態を示す。ここで、説明の簡略化のため、テナントＴａ〜テナントＴｃ、テナントＴｘが要求するＶＭのタイプはｍｅｄｉｕｍとする。ＶＭのタイプがｍｅｄｉｕｍである場合、該当のＶＭに割り当てられるＣＰＵ数は１であり、ＶＭに割り当てられるメモリサイズは１［ＧＢ］であり、ＶＭが使用するボリュームサイズは０．０４［ＴＢ］である。

また、新規テナントＴｘが要求する性能情報は、ＶＭ数が５個であり、ボリュームサイズが１．０［ＴＢ］であり、ＮＷ帯域が４［Ｇｂｐｓ］であり、ＮＷ遅延時間が２［ｍｓ］である。

図１１は、新規テナントの構築要求が行われた場合のクラウドシステムの状態例を示す説明図である。図１１では、クラウドシステム２００が有するＤＣ１、ＤＣ２、ＤＣ３の空きリソースの状態を示す。たとえば、ＤＣ１は、空ＶＭ数が４であり、空ストレージ領域が１［ＴＢ］であり、空ＮＷ帯域が９［Ｇｂｐｓ］であり、ＮＷ遅延時間が１［ｍｓ］である。また、ＤＣ１とＤＣ２間の利用可能ＮＷ帯域は、５［Ｇｂｐｓ］であり、ＤＣ１とＤＣ２のＮＷ平均遅延時間は、５［ｍｓ］である。さらに、ＤＣ１とＤＣ３間の利用可能ＮＷ帯域は、５［Ｇｂｐｓ］であり、ＤＣ１とＤＣ３のＮＷ平均遅延時間は、１３［ｍｓ］である。利用可能ＮＷ帯域は、ＮＷ帯域から、現在使用されるＮＷ帯域を減じたものである。

図１２は、新規テナントの構築要求が行われた場合の構築先ＤＣの選択例を示す説明図である。リソース管理装置１０１は、Ｔｘの構築先ＤＣ候補となるＤＣを列挙して、構築先ＤＣ候補の空リソースとＴｘの性能情報との差分と、移行コストを算出する。Ｔｘの構築先ＤＣ候補ごとの構築先ＤＣ候補の空リソースとＴｘの性能情報との差分と、移行コストとを、表１２０１に示す。

表１２０１は、テナントを構築するＤＣ、構築先ＤＣ候補の空リソース状況、Ｔｘの性能情報、構築先ＤＣ候補の空リソースとＴｘの性能情報との差分、移行コストという５つのフィールドを有する。構築先ＤＣ候補の空リソース状況フィールドは、空ＶＭ数、空ストレージ領域、空ＮＷ帯域、ＮＷ総遅延時間という４つのサブフィールドを有する。Ｔｘの性能情報フィールドは、ＶＭ数、ボリュームサイズ、ＮＷ帯域、ＮＷ遅延時間という４つのサブフィールドを有する。構築先ＤＣ候補の空リソースとＴｘの性能情報との差分フィールドは、ＶＭ数、ボリュームサイズ、ＮＷ帯域、ＮＷ遅延時間という４つのサブフィールドを有する。

テナントを構築するＤＣフィールドには、テナントの構築先ＤＣ候補となるＤＣの識別情報が格納される。移行コストフィールドには、構築先ＤＣ候補にテナントを構築したときに発生する、他のテナントの構成の移行にかかる負荷量が格納される。

構築先ＤＣ候補の空リソース状況フィールドの４つのサブフィールドと、Ｔｘの性能情報フィールドの４つのサブフィールドとには、図６、図１０で示したテナントの性能情報がそれぞれ格納される。また、構築先ＤＣ候補の空リソースとＴｘの性能情報との差分フィールドの４つのサブフィールドには、構築先ＤＣ候補の空リソース状況フィールドの４つのサブフィールドの値と、Ｔｘの性能情報フィールドのうち対応するサブフィールドの値の差分が格納される。

また、図１２に示す表１２０１は、レコード１２０１−１〜レコード１２０１−６を有する。レコード１２０１−１は、Ｔｘの構築先ＤＣ候補をＤＣ１とした場合の構築先ＤＣ候補の空リソースとＴｘの性能情報との差分と、移行コストを示す。同様に、レコード１２０１−２はＴｘの構築先ＤＣ候補がＤＣ２である場合を示し、レコード１２０１−３はＴｘの構築先ＤＣ候補がＤＣ３である場合を示す。レコード１２０１−４はＴｘの構築先ＤＣ候補がＤＣ１とＤＣ２である場合を示す。レコード１２０１−５はＴｘの構築先ＤＣ候補がＤＣ１とＤＣ３である場合を示す。レコード１２０１−６はＴｘの構築先ＤＣ候補がＤＣ２とＤＣ３である場合を示す。Ｔｘの構築先ＤＣ候補が、３つ以上のＤＣとなってもよい。

構築先ＤＣ候補の空リソースとＴｘの性能情報との差分フィールドの各サブフィールドの値は、以下の式により算出される。

ＶＭ数＝空ＶＭ数−Ｔｘの性能情報によるＶＭ数
ボリュームサイズ＝空ストレージ領域−Ｔｘの性能情報によるボリュームサイズ
ＮＷ帯域＝空ＮＷ帯域−Ｔｘの性能情報によるＮＷ帯域
ＮＷ遅延時間＝Ｔｘの性能情報によるＮＷ遅延時間−ＮＷ総遅延時間

１つのＤＣにより構築されるテナントでの空ＮＷ帯域は、該当のＤＣの利用可能ＮＷ帯域の値となり、ＮＷ総遅延時間は、該当のＤＣのＮＷ遅延時間の値となる。また、複数のＤＣにより構築されるテナントでの空ＮＷ帯域と、ＮＷ総遅延時間の算出手順については、下記（１）式と（２）式により算出できる。

空ＮＷ帯域＝Ｍｉｎ（各々のＤＣの空ＮＷ帯域，ＤＣ間の利用可能ＮＷ帯域） …（１）
ＮＷ総遅延時間＝Σ（各々のＤＣのＮＷ遅延時間，ＤＣ間のＮＷ平均遅延時間） …（２）

ただし、Ｍｉｎ（）は、引数内の最小値を出力する関数である。たとえば、Ｔｘの構築先ＤＣ候補がＤＣ１とＤＣ２である場合の空ＮＷ帯域は、（１）式を適用して、以下のように算出される。

空ＮＷ帯域＝Ｍｉｎ（ＤＣ１の空きＮＷ帯域，ＤＣ２の空きＮＷ帯域，ＤＣ１とＤＣ２間の利用可能ＮＷ帯域）
空ＮＷ帯域＝Ｍｉｎ（９，９，５）＝５［Ｍｂｐｓ］

同様に、Ｔｘの構築先ＤＣ候補がＤＣ１とＤＣ２である場合のＮＷ総遅延時間は、（２）式を適用して、以下のように算出される。

ＮＷ総遅延時間＝Σ（ＤＣ１のＮＷ遅延時間，ＤＣ２のＮＷ遅延時間，ＤＣ１とＤＣ２のＮＷ平均遅延時間）
ＮＷ総遅延時間＝Σ（１，１，５）＝１＋１＋５＝７［ｍｓ］

また、移行コストは、下記（３）式により算出できる。

移行コスト＝ＶＭの不足数＊（ＶＭのメモリサイズ＋ＶＭのボリュームサイズ）＋ストレージの不足サイズ …（３）

なお、移行コストの算出式は、（３）式に限られない。たとえば、移行コストの算出式は、（３）式の第３項としてＮＷ帯域の不足量が追加された式でもよい。また、移行コストを算出する際に、ＮＷ遅延時間が負になった構築先ＤＣ候補は、構築先から除外する。理由として、ＮＷ遅延時間は、距離の影響が強く、構成を移行しても大きな改善が見られないためである。表１２０１により、ＮＷ遅延時間が負となる構築先ＤＣ候補は、ＤＣ１とＤＣ２となる場合、ＤＣ１とＤＣ３となる場合、ＤＣ２とＤＣ３となる場合である。ＮＷ遅延時間が負になった構築先ＤＣ候補が構築先ＤＣとして選択されないようにするため、リソース管理装置１０１は、たとえば、ＮＷ遅延時間が負になった構築先ＤＣ候補の移行コストを無限大に設定する。

たとえば、Ｔｘの構築先ＤＣ候補がＤＣ１である場合の移行コストは、（３）式を適用して、以下のように算出される。

移行コスト＝ＤＣ１のＶＭの不足数＊（ＶＭのメモリサイズ＋ＶＭのボリュームサイズ）＋ＤＣ１のストレージの不足サイズ
移行コスト＝１＊（０．００１＋０．０４）＋０＝０．０４１

リソース管理装置１０１は、たとえば、算出した移行コストのうち、最小の移行コストとなる構築先ＤＣ候補を、Ｔｘの構築先として選択する。図１２の例では、リソース管理装置１０１は、ＤＣ１〜ＤＣ３から、Ｔｘの構築先としてＤＣ１を選択する。次に、リソース管理装置１０１は、ＤＣ１に構築されるＴｘの構成のうち移行対象構成の選択処理と、移行先ＤＣを選択する処理を実行する。移行対象構成の選択例と、移行先ＤＣの選択例について、図１３にて説明する。

図１３は、新規テナントの構築要求が行われた場合の移行対象構成の選択例を示す説明図である。リソース管理装置１０１は、Ｔａの各ＶＭを移行候補として列挙して、ＶＭごとに、該当のＶＭの移行先ＤＣの候補と、該当のＶＭを移行するときの移行コストと、該当のＶＭを移行すると発生する通信コストを求める。ＶＭごとの、該当のＶＭの移行先ＤＣの候補と、該当のＶＭを移行するときの移行コストと、該当のＶＭを移行すると発生する通信コストを、表１３０１に示す。

表１３０１は、移行対象ＶＭ候補、移行先ＤＣ候補、移行した場合のＴａを構築するＤＣ、移行による性能情報違反の有無、移行コスト、移行後のＤＣ間の通信コスト、という６つのフィールドを有する。また、表１３０１は、レコード１３０１−１〜レコード１３０１−１２を有する。

移行対象ＶＭ候補フィールドは、移行候補となるＶＭの識別情報が格納される。移行先ＤＣ候補フィールドには、該当のＶＭの移行候補となるＤＣの識別情報が格納される。移行した場合のＴａを構築するＤＣフィールドには、該当のＶＭが移行候補となるＤＣに移行した場合のＴａを構築するＤＣの識別情報が格納される。移行による性能情報違反の有無フィールドには、該当のＶＭが移行候補となるＤＣに移行した場合に、Ｔａの性能情報を満たすか否かを示す識別子が格納される。具体的に、移行による性能情報違反の有無フィールドには、Ｔａの性能情報を満たすことを示す“無”識別子と、Ｔａの性能情報を満たさないことを示す“有”識別子とが格納される。移行コストフィールドには、該当のＶＭを移行にかかる負荷量が格納される。移行後のＤＣ間の通信コストフィールドには、該当のＶＭを移行した後に発生する、通信にかかる負荷量が格納される。

移行コストフィールドには、たとえば、下記（４）式により算出した値が格納されてもよい。

移行コスト＝移行するＶＭ数＊（ＶＭのメモリサイズ＋ＶＭのボリュームサイズ）＋移行するストレージのサイズ …（４）

たとえば、レコード１３０１−１は、移行候補のＶＭがＴａ．ＶＭａ１であり、移行先ＤＣがＤＣ２である場合について示す。さらに、レコード１３０１−１は、Ｔａ．ＶＭａ１が、ＤＣ２に移行することにより、移行後のＴａは、ＤＣ１とＤＣ２のリソースを利用して構築されることになることを示す。さらに、レコード１３０１−１は、ＶＭがＤＣ２に移行したとき、性能情報を満たすことを示す。

一方、レコード１３０１−２は、移行候補のＶＭがＴａ．ＶＭａ１であり、移行先ＤＣがＤＣ３である場合について示す。さらに、レコード１３０１−２は、Ｔａ．ＶＭａ１が、ＤＣ３に移行することにより、移行後のＴａは、ＤＣ１とＤＣ３のリソースを利用して構築されることになることを示す。さらに、レコード１３０１−２は、ＶＭがＤＣ３に移行したとき、性能情報を満たさないことを示す。具体的に、ＤＣ１とＤＣ３のリソースを利用して構築されるＴａは、図１２に示したレコード１２０１−６によりＮＷ総遅延時間が１５［ｍｓ］であり、図１１等で示したようにＴａのＮＷ遅延時間は８［ｍｓ］であるから、Ｔａの性能情報を満たさない。

また、レコード１３０１−１は、（４）式により算出された移行コストが０．０４１であることを示す。図１３の例では、レコード１３０１−１に格納された移行コストは、以下のように算出される。

移行コスト＝移行するＶＭ数＊（ＶＭのメモリサイズ＋ＶＭのボリュームサイズ）＋移行するストレージのサイズ
移行コスト＝１＊（０．００１＋０．０４）＋０＝０．０４１

また、レコード１３０１−１は、通信コストとして、１１０［Ｋｐｋｔｓ］であることを示す。なお、Ｋｐｋｔｓは、１０００パケットを意味する。通信コストフィールドには、前述の例のような、Ｔａ内での構成間の通信量が格納されていてもよい。Ｔａ内での構成間の通信量は、一定期間Ｔａ内での構成間で発生した通信量を記録してもよい。表１３０２は、移行対象ＶＭ候補を１レコードとして、一定期間Ｔａ内での構成間で発生した通信量を示す。図１３に示す表１３０２は、レコード１３０２−１〜レコード１３０２−６を有する。

表１３０２は、移行対象ＶＭ候補の通信先、総通信量という２つのフィールドを含む。移行対象ＶＭ候補の通信先フィールドは、Ｔａ内の構成ごとに、該当の構成と移行対象ＶＭとの通信量を格納するサブフィールドを有する。総通信量フィールドには、該当の構成と移行対象ＶＭとの通信量の和が格納される。

さらに、レコード１３０１−１は、ＶＭａ１と各構成との通信量の和が１１０［Ｋｐｋｔｓ］であることを示す。

リソース管理装置１０１は、レコード１３０２−１〜レコード１３０２−６の総通信量フィールドの値を、レコード１３０１−１、３、５、７、９、１１の移行後のＤＣ間の通信コストフィールドの値として格納する。

以上、レコード１３０１−１〜レコード１３０１−１２の各値について説明したところで、リソース管理装置１０１が行う移行対象構成の選択例について説明する。リソース管理装置１０１は、表１３０１を参照して、次の３つの条件に当てはまるレコードを選択し、移行対象ＶＭとして、選択したレコードの移行対象ＶＭ候補フィールドに設定されたＶＭを選択する。また、リソース管理装置１０１は、移行先ＤＣとして、選択したレコードの移行先ＤＣ候補フィールドに設定されたＤＣを選択する。

１つ目の条件は、移行による性能情報違反の有無フィールドの値が“無”となるレコードである。２つ目の条件は、移行コストフィールドの値が最小となるレコードである。３つ目の条件は、移行後のＤＣ間の通信コストの値が最小となるレコードである。リソース管理装置１０１は、１つ目の条件により選択したレコードが１つであれば、移行対象ＶＭとして、選択したレコードの移行対象ＶＭ候補フィールドに設定されたＶＭを選択し、移行先ＤＣとして、移行先ＤＣ候補フィールドに設定されたＤＣを選択する。また、リソース管理装置１０１は、１つ目の条件により選択したレコードが複数あれば、さらに２つ目の条件と、３つ目の条件を用いてレコードを絞り込んでもよい。

また、図１３の例では、移行すべきＶＭが１つである場合について説明した。移行すべきＶＭが２つ以上有る場合の移行コストは、それぞれのＶＭの移行コストを加算すればよい。たとえば、ＶＭａ１とＶＭａ２をＤＣ２に移行する場合の移行コストは、０．０４１＋０．０４１＝０．０８２となる。また、移行すべきＶＭが２つ以上有る場合の通信コストは、それぞれのＶＭの通信コストを加算し、移行先ＶＭが同一であれば、それぞれのＶＭ間で発生した通信量を減ずればよい。たとえば、ＶＭａ１とＶＭａ２をＤＣ２に移行する場合の通信コストは、１１０＋２２０−５０−５０＝２３０［Ｋｐｋｔｓ］となる。

図１３の例では、移行による性能情報違反の有無フィールドの値が“無”であり、移行コストと移行後のＤＣ間の通信コストが最小値となるレコード１３０１−１を選択する。したがって、リソース管理装置１０１は、移行対象ＶＭとしてＶＭａ１を選択し、移行先ＤＣとしてＤＣ２を選択する。次に、図１４と図１５を用いて、ＶＭａ１をＤＣ２に移行する場合の処理を説明する。

図１４は、新規テナントの構築要求が行われた場合の選択結果に従った移行処理例を示す説明図（その１）である。（１）番目の処理として、リソース管理装置１０１は、移行用のトンネリング設定情報４１２を作成する。具体的に、リソース管理装置１０１は、移行元構成から移行先構成への移行用のトンネリング設定情報４１２として、レコード１４０１−１を作成する。また、リソース管理装置１０１は、移行先構成から移行元構成への移行用のトンネリング設定情報４１２として、レコード１４０２−１を作成する。レコード１４０１−１、レコード１４０２−１の作成後、リソース管理装置１０１は、レコード１４０１−１、レコード１４０２−１を物理マシンｐｍ１０内のＶＭａ１と、物理マシンｐｍ２１内のＶＭａ１に送信し、トンネリングを作成させる。

なお、本実施の形態におけるトンネリング設定情報４１２は、仮想マシン間でのトンネリングを行うため、仮想マシンまでのアドレスを格納する。もし、仮想マシン間でのトンネリングが行えない場合、トンネリング設定情報４１２は、物理マシンまでのアドレスを格納しておき、物理マシン間でのトンネリングを行ってもよい。

（２）番目の処理として、リソース管理装置１０１は、ＶＭの移行を実施する。リソース管理装置１０１は、移行対象ＶＭとなるＶＭａ１を、移行元リソースとなるＤＣ１内の物理マシンｐｍ１０から移行先リソースとなるＤＣ２内の物理マシンｐｍ２１に移行する。リソース管理装置１０１は、移行が終わったら、物理マシンｐｍ１０内のＶＭａ１と、物理マシンｐｍ２１内のＶＭａ１に対し、作成したトンネリングを削除させる。

図１５は、新規テナントの構築要求が行われた場合の選択結果に従った移行処理例を示す説明図（その２）である。図１５の状態は、ＶＭａ１の移行が終了した状態である。リソース管理装置１０１は、Ｔａ内の各構成を同一のセグメントと見なすために、Ｔａを運用するためのサービス用のトンネリングを設定する。具体的に、リソース管理装置１０１は、各構成から移行したＶＭａ１へのＴａのサービス用のトンネリング設定情報４１２として、レコード１５０１−１〜レコード１５０１−６を作成する。また、リソース管理装置１０１は、移行したＶＭａ１から各構成へのＴａのサービス用のトンネリング設定情報４１２として、レコード１５０２−１〜レコード１５０２−６を作成する。作成後、リソース管理装置１０１は、対応する物理マシン内の各構成に、作成したレコード群を送信し、トンネリングを作成させる。

図１６は、新規テナントの構築要求が行われた場合の移行処理の結果を示す説明図である。図１６では、Ｔｘが構築されたことにより、ＤＣ１の空きＶＭ数が０となり、空きストレージ領域が０［ＴＢ］となり、空きＮＷ帯域が、９［Ｇｂｐｓ］から、Ｔｘの性能情報である４［Ｇｂｐｓ］を減じた、５［Ｇｂｐｓ］となる。

次に、図１７〜図２１を用いて、新規テナントの構築要求２２１をトリガーとしたリソース配備処理のフローチャートを説明する。

図１７は、新規テナントの構築要求が行われた場合のリソース配備処理手順の一例を示すフローチャートである。新規テナントの構築要求が行われた場合のリソース配備処理は、新規テナントの構築要求２２１をトリガーとして、複数のＤＣの中から新規テナント用のリソースを配備する処理である。

リソース管理装置１０１は、構築先ＤＣ選択処理を実行する（ステップＳ１７０１）。構築先ＤＣ選択処理の詳細は、図１８にて後述する。次に、リソース管理装置１０１は、構築済のテナントの構成を移行すべきか否かを判断する（ステップＳ１７０２）。構築済のテナントの構成を移行すべきか否かは、構築先ＤＣ選択処理で選択された構築先ＤＣの移行コストの値によって判断することができる。具体的に、移行コストの値は、０より大きければ、何らかの構成を移行させなければ、新規テナントを構築できないことを示し、０であれば、構成を移行させなくても、新規テナントを構築できることを示す。

構築済のテナントの構成の移行を行う場合（ステップＳ１７０２：Ｙｅｓ）、リソース管理装置１０１は、移行対象構成選択処理を実行する（ステップＳ１７０３）。移行対象構成選択処理の詳細は、図１９にて後述する。

ステップＳ１７０３の実行後、または構築済のテナントの構成の移行を行わない場合（ステップＳ１７０２：Ｎｏ）、リソース管理装置１０１は、移行対象構成があるか否かを判断する（ステップＳ１７０４）。移行対象構成がある場合（ステップＳ１７０４：Ｙｅｓ）、リソース管理装置１０１は、移行対象構成の移行指示処理を実行する（ステップＳ１７０５）。移行対象構成の移行指示処理の詳細は、図２０にて後述する。

ステップＳ１７０５の実行後、または移行対象構成がない場合（ステップＳ１７０４：Ｎｏ）、リソース管理装置１０１は、新規テナントがあるか否かを判断する（ステップＳ１７０６）。新規テナントがある場合（ステップＳ１７０６：Ｙｅｓ）、リソース管理装置１０１は、新規テナントの構築指示処理を実行する（ステップＳ１７０７）。新規テナントの構築指示処理の詳細は、図２１にて後述する。ステップＳ１７０７の実行後、または新規テナントがない場合（ステップＳ１７０６：Ｎｏ）、リソース管理装置１０１は、新規テナントの構築要求が行われた場合のリソース配備処理を終了する。新規テナントの構築要求が行われた場合のリソース配備処理を実行することにより、クラウドシステム２００は、１つのＤＣ内に新規テナントを構築できない場合でも、構築済のテナントの構成を移行することで、新規テナントを構築することができる。

図１８は、構築先ＤＣ選択処理手順の一例を示すフローチャートである。構築先ＤＣ選択処理は、複数のＤＣの中から、新規テナントを構築するＤＣを選択する処理である。リソース管理装置１０１は、新規テナントの構築先ＤＣ候補となるＤＣの一覧を作成する（ステップＳ１８０１）。ステップＳ１８０１の処理は、図１２の例で具体的に説明すると、表１２０１のテナントを構築するＤＣフィールドに格納されるＤＣの識別情報を取得する処理である。

次に、リソース管理装置１０１は、各構築先ＤＣ候補について、テナントの構築による、構築済のテナントの構成の移行コストを算出する（ステップＳ１８０２）。続けて、リソース管理装置１０１は、移行コストが最小となる構築先ＤＣ候補を選択する（ステップＳ１８０３）。ステップＳ１８０３の終了後、リソース管理装置１０１は、構築先ＤＣ選択処理を終了する。構築先ＤＣ選択処理を実行することにより、クラウドシステム２００は、複数のＤＣの中から、新規テナントを構築するＤＣを選択することができる。

図１９は、移行対象構成選択処理手順の一例を示すフローチャートである。移行対象構成選択処理は、テナントを構築する構成の中から、移行対象構成を選択する処理である。リソース管理装置１０１は、移行対象構成候補と、移行先ＤＣ候補との組合せの一覧を作成する（ステップＳ１９０１）。ステップＳ１９０１の処理は、図１３の例で具体的に説明すると、表１３０１の移行対象ＶＭ候補フィールドに格納されるＶＭの識別情報と、移行先ＤＣ候補フィールドに格納されるＤＣの識別情報との組合せを作成する処理である。

次に、リソース管理装置１０１は、移行対象構成候補と移行先ＤＣ候補の組合せについて、移行対象構成候補により構築されるテナントの性能情報違反の有無を判断する（ステップＳ１９０２）。続けて、リソース管理装置１０１は、移行対象構成候補と移行先ＤＣ候補の組合せから、移行コストが最小となる組合せを選択する（ステップＳ１９０３）。次に、リソース管理装置１０１は、移行コストが最小となる組合せから、ＤＣ間通信コストが最小となる組合せを選択する（ステップＳ１９０４）。ステップＳ１９０４の処理終了後、リソース管理装置１０１は、移行対象構成選択処理を終了する。移行対象構成選択処理を実行することにより、クラウドシステム２００は、移行にかかる負荷量が小さく、さらに、移行後のＤＣ間の通信量が少なくなる構成を移行対象構成として選択することができる。

図２０は、移行対象構成の移行指示処理手順の一例を示すフローチャートである。移行対象構成の移行指示処理は、移行対象構成の移行指示を指示する処理である。リソース管理装置１０１は、移行用のトンネリング設定情報４１２を作成して、移行対象構成の移行元での物理マシンと移行対象構成の移行先での物理マシンに、移行用のトンネリングの設定指示を行う（ステップＳ２００１）。次に、リソース管理装置１０１は、移行対象構成の移行元での物理マシンと移行対象構成の移行先での物理マシンに、移行対象構成の移行指示を行う（ステップＳ２００２）。続けて、リソース管理装置１０１は、移行対象構成の移行元での物理マシンと移行対象構成の移行先での物理マシンに、移行用のトンネリングの削除指示を行う（ステップＳ２００３）。次に、リソース管理装置１０１は、移行対象構成を有するテナントの各構成に、テナントのサービス用のトンネリングの作成指示を行う（ステップＳ２００４）。ステップＳ２００４の処理終了後、リソース管理装置１０１は、移行対象構成の移行指示処理を終了する。

構築済のテナントの構成の移行指示処理を実行することにより、クラウドシステム２００は、複数のＤＣにより構築されたテナントについて、移行用のトンネリングを設定して同一セグメントと見なして、構成の移行を行うことができる。また、サービス用のトンネリングを設定して、クラウドシステム２００は、同一セグメントと見なして該当のテナントをユーザに提供することができる。

図２１は、新規テナントの構築指示処理手順の一例を示すフローチャートである。新規テナントの構築指示処理は、新規テナントを構築する指示を、物理マシンまたは構成に指示する処理である。リソース管理装置１０１は、物理マシンに、リソースの配備指示を行う（ステップＳ２１０１）。具体的に、物理マシンは、空リソースの中から、新規テナントを構築する構成を実現するリソースを確保する。

次に、リソース管理装置１０１は、新規テナントが複数のＤＣにより構築されるか否かを判断する（ステップＳ２１０２）。新規テナントが複数のＤＣにより構築される場合（ステップＳ２１０２：Ｙｅｓ）、リソース管理装置１０１は、新規テナントの各構成に、新規テナントのサービス用のトンネリングの作成指示を行う（ステップＳ２１０３）。ステップＳ２１０３の終了後、または新規テナントが複数のＤＣにより構築されていない場合（ステップＳ２１０２：Ｎｏ）、リソース管理装置１０１は、新規テナントの構築指示処理を終了する。

（運用ポリシーの設定要求）
次に、図２２〜図２９を用いて、運用ポリシーの設定要求が行われた場合のクラウドシステム２００の動作について説明する。

図２２は、運用ポリシーの設定要求が行われた場合のクラウドシステムの状態例を示す説明図である。図２２でのクラウドシステム２００の状態は、図１６で示したクラウドシステム２００の状態に等しい。この状態で、物理マシンｐｍ３０を保守するため、運用ポリシーの変更として、管理用端末２１２が、物理マシンの保守要求（ＤＣ３，ｐｍ３０）を発行したとする。続けて、図２３にて、運用ポリシーに従った状態について説明する。

図２３は、運用ポリシーの設定要求が行われた場合の運用ポリシーの変更を反映した状態を示す説明図である。物理マシンの保守要求（ＤＣ３，ｐｍ３０）を受け付けたリソース管理装置１０１は、運用ポリシーに従い、ｐｍ３０を、テナントの構築先対象から除外する。したがって、クラウドシステム２００は、ｐｍ３０のリソースを利用して実現される構成であるＴｃのＶＭｃ１、ＴｃのＶＭｃ２、ＴｃのＶＭｃ３を移行対象構成として選択して、ＤＣ３以外の他のＤＣに移行することになる。図２４にて、移行対象構成の移行先ＤＣの選択例について説明する。

図２４は、運用ポリシーの設定要求が行われた場合のテナントの移行先ＤＣの選択例を示す説明図である。リソース管理装置１０１は、移行対象構成の移行先ＤＣ候補となるＤＣを列挙して、移行先ＤＣ候補の空リソースとＴｃの性能情報との差分と、移行コストを算出する。移行対象構成の移行先ＤＣ候補ごとの移行先ＤＣの空リソースとＴｃの性能情報との差分と、移行コストとを、表２４０１に示す。表２４０１の各フィールドは、表１２０１にて示した、構築先ＤＣ候補が移行先ＤＣ候補に置き換わり、ＴｘがＴｃに置き換わっただけであるため、説明を省略する。また、移行先ＤＣ候補の空リソースとＴｃの性能情報との差分フィールドの各サブフィールドの算出方法も、ＴｘがＴｃに置き換わっただけであるため、説明を省略する。図２４に示す表２４０１は、レコード２４０１−１〜レコード２４０１−３を有する。

図２４の例では、リソース管理装置１０１は、Ｔｃの構築先として、移行コストが最小となったＤＣ２を選択する。次に、ＤＣ２の各構成の移行処理の例について、図２５、図２６にて説明する。

図２５は、運用ポリシーの設定要求が行われた場合の選択結果に従った移行処理例を示す説明図（その１）である。（１）番目の処理として、リソース管理装置１０１は、移行用のトンネリング設定情報４１２を作成する。具体的に、リソース管理装置１０１は、移行元構成から移行先構成への移行用のトンネリング設定情報４１２として、レコード２５０１−１〜レコード２５０１−３を作成する。また、リソース管理装置１０１は、移行先構成から移行元構成への移行用のトンネリング設定情報４１２として、レコード２５０２−１〜レコード２５０２−３を作成する。次に、リソース管理装置１０１は、レコード２５０１−１〜レコード２５０１−３、レコード２５０２−１〜レコード２５０２−３を物理マシンｐｍ３０内のＶＭｃ１〜ＶＭｃ３と、物理マシンｐｍ２１内のＶＭｃ１〜ＶＭｃ３に送信し、トンネリングを作成させる。

（２）番目の処理として、リソース管理装置１０１は、ＶＭの移行を実施する。リソース管理装置１０１は、移行対象ＶＭとなる仮想マシンＶＭｃ１〜ＶＭｃ３を、移行元リソースとなるＤＣ３内の物理マシンｐｍ３０から移行先リソースとなるＤＣ２内の物理マシンｐｍ２１に移行する。リソース管理装置１０１は、移行が終わったら、物理マシンｐｍ３０内のＶＭｃ１〜ＶＭｃ３と、物理マシンｐｍ２１内のＶＭｃ１〜ＶＭｃ３に対し、作成したトンネリングを削除させる。

図２６は、運用ポリシーの設定要求が行われた場合の選択結果に従った移行処理例を示す説明図（その２）である。図２６の状態は、ＶＭｃ１〜ＶＭｃ３の移行が終了した状態である。リソース管理装置１０１は、Ｔｃ内の各構成を同一のセグメントと見なすために、Ｔｃを運用するためのサービス用のトンネリングを設定する。具体的に、リソース管理装置１０１は、移行したＶＭｃ１〜ＶＭｃ３からストレージ装置ｓｔ３０へのＴｃのサービス用のトンネリング設定情報４１２として、レコード２６０１−１〜レコード２６０１−３を作成する。また、リソース管理装置１０１は、ストレージ装置ｓｔ３０から移行したＶＭｃ１〜ＶＭｃ３へのＴａのサービス用のトンネリング設定情報４１２として、レコード２６０２−１〜レコード２６０２−６を作成する。作成後、リソース管理装置１０１は、対応する物理マシン内の各構成に、作成したレコード群を送信し、トンネリングを作成させる。

図２７は、運用ポリシーの設定要求が行われた場合の移行処理の結果を示す説明図である。図２７では、ＴｃがＤＣのリソースを利用して構築されたことにより、ＤＣ２の空きＶＭ数が０となり、空きＮＷ帯域が、９［Ｇｂｐｓ］から、Ｔｂの性能情報である１［Ｇｂｐｓ］を減じた、８［Ｇｂｐｓ］となる。

次に、運用ポリシーの設定要求２２２をトリガーとしたリソース配備処理のフローチャートを説明する。

図２８は、運用ポリシーの設定要求が行われた場合のリソース配備処理手順の一例を示すフローチャートである。運用ポリシーの設定要求が行われた場合のリソース配備処理は、運用ポリシーの設定要求２２２をトリガーとして、運用ポリシーの適用により移行することになった構成のリソースを配備する処理である。また、図２８に示すステップＳ２８０４〜ステップＳ２８０７は、ステップＳ１７０２〜ステップＳ１７０５と同一であるため、説明を省略する。

リソース管理装置１０１は、運用ポリシー適用処理を実行する（ステップＳ２８０１）。運用ポリシー適用処理の詳細は、図２９にて後述する。次に、リソース管理装置１０１は、運用ポリシーの適用により、移行対象構成が選択されたか否かを判断する（ステップＳ２８０２）。移行対象構成が選択された場合（ステップＳ２８０２：Ｙｅｓ）、リソース管理装置１０１は、移行先ＤＣ選択処理を実行する（ステップＳ２８０３）。移行先ＤＣ選択処理の処理内容は、図１８で示した構築先ＤＣ選択処理の処理内容とほぼ同等であるため、図示を省略する。移行先ＤＣ選択処理の処理内容の差分は、「構築先ＤＣ候補」が「移行先ＤＣ候補」となり、ステップＳ１８０２の処理である「構築済のテナントの構成」が、「移行対象構成により構築されるテナント以外の構築済のテナントの構成」となる。ステップＳ２８０３の実行終了後、リソース管理装置１０１は、ステップＳ２８０４の処理に移行する。

また、移行対象構成が選択されていない場合（ステップＳ２８０２：Ｎｏ）、リソース管理装置１０１は、運用ポリシーの設定要求が行われた場合のリソース配備処理を終了する。運用ポリシーの設定要求が行われた場合のリソース配備処理を実行することにより、運用ポリシーの適用によって、リソースが利用できなくなった構成に対して、使用可能なリソースを配備して、構成を移行することができる。

図２９は、運用ポリシー適用処理手順の一例を示すフローチャートである。運用ポリシー適用処理は、クラウドシステム２００に、運用ポリシーを適用する処理である。リソース管理装置１０１は、運用ポリシーで指定されたリソースの確認を行う（ステップＳ２９０１）。次に、リソース管理装置１０１は、対象リソースへの変更内容を適用する（ステップＳ２９０２）。続けて、リソース管理装置１０１は、テナントの構築先対象から除外されたリソースを利用して実現される構成があるか否かを判断する（ステップＳ２９０３）。

テナントの構築先対象から除外されたリソースを利用して実現される構成がある場合（ステップＳ２９０３：Ｙｅｓ）、リソース管理装置１０１は、除外されたリソースを利用して実現される構成を移行対象構成として選択する（ステップＳ２９０４）。ステップＳ２９０４の実行終了後、または、テナントの構築先対象から除外されたリソースを利用して実現される構成がない場合（ステップＳ２９０３：Ｎｏ）、リソース管理装置１０１は、運用ポリシー適用処理を終了する。

以上説明したように、リソース管理装置１０１によれば、新しいテナントを第１のＤＣに構築できない場合、第１のＤＣのリソースを利用して実現される構成を第１のＤＣから第２のＤＣに移行しても構築済のシステムの性能情報を満たすなら、構成を移行する。これにより、リソース管理装置１０１は、移行することによって生まれた空リソースを用いて、ユーザからの要求を満足する新たなテナントを構築することができる。また、リソース管理装置１０１は、ＤＣの空きリソースを有効活用することができる。

また、リソース管理装置１０１は、第１のＤＣのリソースを利用して実現される第１の構成または第２の構成を第１のＤＣから第２のＤＣに移行しても構築済のシステムの性能情報を満たすか否かを判断する。構築済のシステムの性能情報を満たすと判断した場合、リソース管理装置１０１は、第１の構成または第２の構成について、移行にかかる負荷量を算出して、負荷量に基づいて、第１の構成または第２の構成から、移行対象構成を選択してもよい。これにより、リソース管理装置１０１は、ユーザからの要求を満足する新たなテナントを構築することができるとともに、移行にかかる負荷量がより少ない構成を移行することができる。

また、リソース管理装置１０１は、さらに、移行対象構成を第２のＤＣとは異なる第３のＤＣに移行しても性能情報を満たすか否かを判断する。第３のＤＣに移行しても性能情報を満たすと判断した場合、リソース管理装置１０１は、移行対象構成を第３のＤＣに移行する処理にかかる負荷量を算出して、負荷量に基づいて、第２のＤＣまたは第３のＤＣから、移行先ＤＣを選択してもよい。これにより、リソース管理装置１０１は、ユーザからの要求を満足する新たなテナントを構築することができるとともに、移行にかかる負荷量がより少ないＤＣに、移行にかかる負荷量がより少ない構成を移行することができる。

また、リソース管理装置１０１は、さらに、第１の構成を第２のＤＣに移行した後に第１のＤＣと第２のＤＣとの間で発生する通信量と、第２の構成を第２のＤＣに移行した後に第１のＤＣと第２のＤＣとの間で発生する通信量を算出する。続けて、リソース管理装置１０１は、算出した通信量に基づいて、第１の構成または第２の構成から、移行対象構成を選択してもよい。これにより、リソース管理装置１０１は、ユーザからの要求を満足する新たなテナントを構築することができるとともに、移行後に発生する通信量がより少ない構成を移行することができる。

また、リソース管理装置１０１は、構成を第２のＤＣとは異なる第３のＤＣに移行しても性能情報を満たすか否かを判断する。第３のＤＣに移行しても性能情報を満たすと判断した場合、リソース管理装置１０１は、構成を第３のＤＣに移行する処理にかかる負荷量を算出して、負荷量に基づいて、第２のＤＣまたは第３のＤＣから、移行先ＤＣを選択してもよい。これにより、リソース管理装置１０１は、ユーザからの要求を満足する新たなテナントを構築することができるとともに、移行にかかる負荷量がより少ないＤＣに構成を移行することができる。

また、リソース管理装置１０１は、さらに、構成または前述の構成とは異なる他の構成を移行先ＤＣに移行しても性能情報を満たすか否かを判断する。構成または他の構成を移行先ＤＣに移行しても性能情報を満たすと判断した場合、リソース管理装置１０１は、他の構成を移行先ＤＣに移行する処理にかかる負荷量を算出し、負荷量に基づいて、構成または他の構成のうち移行対象構成を選択してもよい。これにより、リソース管理装置１０１は、ユーザからの要求を満足する新たなテナントを構築することができるとともに、負荷量がより少ない構成を、移行にかかる負荷量のより少ないＤＣに移行することができる。

なお、本実施の形態で説明したリソース管理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本リソース管理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本リソース管理プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）システムの性能情報を記憶する記憶部と、
前記性能情報を参照して、第１のデータセンタのリソースを利用して実現される第１のシステムの一部の機能構成を第２のデータセンタのリソースを利用して実現しても前記第１のシステムに対応する第１の性能情報を満たすか否かを判断する判断部と、
前記判断部によって前記第１の性能情報を満たすと判断された場合、前記第２のデータセンタのリソースを利用して前記一部の機能を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記第２のデータセンタのリソースとを利用して構築する構築部と、
を有することを特徴とするリソース管理システム。

（付記２）前記判断部によって前記第１のデータセンタのリソースを利用して実現される第１の構成または第２の構成を前記第２のデータセンタに移行しても前記第１の性能情報を満たすと判断された場合、前記第１の構成を前記第２のデータセンタに移行する処理にかかる負荷量と、前記第２の構成を前記第２のデータセンタに移行する処理にかかる負荷量とを算出する負荷量算出部と、
前記負荷量算出部によって算出された算出結果に基づいて、前記第１の構成または前記第２の構成のうち前記第１のデータセンタから前記第２のデータセンタに移行する移行対象構成を選択する選択部と、をさらに有し、
前記構築部は、
前記第２のデータセンタのリソースを利用して前記選択部によって選択された前記移行対象構成を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記第２のデータセンタのリソースとを利用して構築することを特徴とする付記１に記載のリソース管理システム。

（付記３）前記負荷量算出部は、
さらに、前記移行対象構成を前記第２のデータセンタとは異なる第３のデータセンタに移行しても前記第１の性能情報を満たすと判断された場合、前記移行対象構成を前記第３のデータセンタに移行する処理にかかる負荷量を算出し、
前記選択部は、
前記負荷量算出部によって算出された算出結果に基づいて、前記第２のデータセンタまたは前記第３のデータセンタのうち前記移行対象構成の移行先データセンタを選択し、
前記構築部は、
前記選択部によって選択された前記移行先データセンタのリソースを利用して前記移行対象構成を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記移行先データセンタのリソースとを利用して構築することを特徴とする付記２に記載のリソース管理システム。

（付記４）前記記憶部は、複数の構成の各々の構成間で発生した通信量を記憶しており、
前記通信量に基づいて、前記第１の構成を前記第２のデータセンタに移行した後に前記第１のデータセンタと前記第２のデータセンタとの間で発生する通信量と、前記第２の構成を前記第２のデータセンタに移行した後に前記第１のデータセンタと前記第２のデータセンタとの間で発生する通信量とを算出する通信量算出部をさらに有し、
前記選択部は、
さらに、前記通信量算出部によって算出された算出結果に基づいて、前記第１の構成または前記第２の構成のうち前記第１のデータセンタから前記第２のデータセンタに移行する移行対象構成を選択することを特徴とする付記２または３に記載のリソース管理システム。

（付記５）前記判断部によって前記第１のデータセンタのリソースを利用して実現される構成を第２のデータセンタまたは第３のデータセンタに移行しても前記第１の性能情報を満たすと判断された場合、前記構成を前記第２のデータセンタに移行する処理にかかる負荷量と、前記構成を前記第３のデータセンタに移行する処理にかかる負荷量とを算出する負荷量算出部と、
前記負荷量算出部によって算出された算出結果に基づいて、前記第２のデータセンタまたは前記第３のデータセンタのうち前記構成を移行する移行先データセンタを選択する選択部と、をさらに有し、
前記構築部は、
前記選択部によって選択された移行先データセンタのリソースを利用して前記構成を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記移行先データセンタのリソースとを利用して構築することを特徴とする付記１に記載のリソース管理システム。

（付記６）前記負荷量算出部は、
さらに、前記第１のデータセンタのリソースを利用して実現される前記構成とは異なる他の構成を前記移行先データセンタに移行しても前記第１の性能情報を満たすと判断された場合、前記他の構成を前記移行先データセンタに移行する処理にかかる負荷量を算出し、
前記選択部は、
前記負荷量算出部によって算出された算出結果に基づいて、前記構成または前記他の構成のうち前記移行先データセンタに移行する移行対象構成を選択し、
前記構築部は、
前記移行先データセンタのリソースを利用して前記選択部によって選択された前記移行対象構成を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記移行先データセンタのリソースとを利用して構築することを特徴とする付記５に記載のリソース管理システム。

（付記７）コンピュータが、
システムの性能情報を参照して、第１のデータセンタのリソースを利用して実現される第１のシステムの一部の機能構成を第２のデータセンタのリソースを利用して実現しても前記第１のシステムに対応する第１の性能情報を満たすか否かを判断し、
前記第１の性能情報を満たすと判断した場合、前記第２のデータセンタのリソースを利用して前記一部の機能を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記第２のデータセンタのリソースとを利用して構築する、
処理を実行することを特徴とするリソース管理方法。

（付記８）コンピュータに、
システムの性能情報を参照して、第１のデータセンタのリソースを利用して実現される第１のシステムの一部の機能構成を第２のデータセンタのリソースを利用して実現しても前記第１のシステムに対応する第１の性能情報を満たすか否かを判断し、
前記第１の性能情報を満たすと判断した場合、前記第２のデータセンタのリソースを利用して前記一部の機能を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記第２のデータセンタのリソースとを利用して構築する、
処理を実行させることを特徴とするリソース管理プログラム。

（付記９）システムの性能情報を参照して、第１のデータセンタのリソースを利用して実現される第１のシステムの一部の機能構成を第２のデータセンタのリソースを利用して実現しても前記第１のシステムに対応する第１の性能情報を満たすか否かを判断し、
前記第１の性能情報を満たすと判断した場合、前記第２のデータセンタのリソースを利用して前記一部の機能を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記第２のデータセンタのリソースとを利用して構築する、
処理をコンピュータに実行させるリソース管理プログラムを記録したことを特徴とする記録媒体。

１００ リソース管理システム
１０１ リソース管理装置
４０１ 受付部
４０２ 判断部
４０３ 負荷量算出部
４０４ 通信量算出部
４０５ 選択部
４０６ 構築部
４１０ 記憶部
４１１ テナントの仮想システム情報
４１２ トンネリング設定情報

Claims (7)

1. システムの性能情報を記憶する記憶部と、
   前記性能情報を参照して、第１のデータセンタのリソースを利用して実現される第１のシステムの一部の機能構成を第２のデータセンタのリソースを利用して実現しても前記第１のシステムに対応する第１の性能情報を満たすか否かを判断する判断部と、
   前記判断部によって前記第１の性能情報を満たすと判断された場合、前記第２のデータセンタのリソースを利用して前記一部の機能を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記第２のデータセンタのリソースとを利用して構築する構築部と、
   を有することを特徴とするリソース管理システム。
2. 前記判断部によって前記第１のデータセンタのリソースを利用して実現される第１の構成または第２の構成を前記第２のデータセンタに移行しても前記第１の性能情報を満たすと判断された場合、前記第１の構成を前記第２のデータセンタに移行する処理にかかる負荷量と、前記第２の構成を前記第２のデータセンタに移行する処理にかかる負荷量とを算出する負荷量算出部と、
   前記負荷量算出部によって算出された算出結果に基づいて、前記第１の構成または前記第２の構成のうち前記第１のデータセンタから前記第２のデータセンタに移行する移行対象構成を選択する選択部と、をさらに有し、
   前記構築部は、
   前記第２のデータセンタのリソースを利用して前記選択部によって選択された前記移行対象構成を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記第２のデータセンタのリソースとを利用して構築することを特徴とする請求項１に記載のリソース管理システム。
3. 前記負荷量算出部は、
   さらに、前記移行対象構成を前記第２のデータセンタとは異なる第３のデータセンタに移行しても前記第１の性能情報を満たすと判断された場合、前記移行対象構成を前記第３のデータセンタに移行する処理にかかる負荷量を算出し、
   前記選択部は、
   前記負荷量算出部によって算出された算出結果に基づいて、前記第２のデータセンタまたは前記第３のデータセンタのうち前記移行対象構成の移行先データセンタを選択し、
   前記構築部は、
   前記選択部によって選択された前記移行先データセンタのリソースを利用して前記移行対象構成を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記移行先データセンタのリソースとを利用して構築することを特徴とする請求項２に記載のリソース管理システム。
4. 前記記憶部は、複数の構成の各々の構成間で発生した通信量を記憶しており、
   前記通信量に基づいて、前記第１の構成を前記第２のデータセンタに移行した後に前記第１のデータセンタと前記第２のデータセンタとの間で発生する通信量と、前記第２の構成を前記第２のデータセンタに移行した後に前記第１のデータセンタと前記第２のデータセンタとの間で発生する通信量とを算出する通信量算出部をさらに有し、
   前記選択部は、
   さらに、前記通信量算出部によって算出された算出結果に基づいて、前記第１の構成または前記第２の構成のうち前記第１のデータセンタから前記第２のデータセンタに移行する移行対象構成を選択することを特徴とする請求項２または３に記載のリソース管理システム。
5. 前記判断部によって前記第１のデータセンタのリソースを利用して実現される構成を第２のデータセンタまたは第３のデータセンタに移行しても前記第１の性能情報を満たすと判断された場合、前記構成を前記第２のデータセンタに移行する処理にかかる負荷量と、前記構成を前記第３のデータセンタに移行する処理にかかる負荷量とを算出する負荷量算出部と、
   前記負荷量算出部によって算出された算出結果に基づいて、前記第２のデータセンタまたは前記第３のデータセンタのうち前記構成を移行する移行先データセンタを選択する選択部と、をさらに有し、
   前記構築部は、
   前記選択部によって選択された移行先データセンタのリソースを利用して前記構成を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記移行先データセンタのリソースとを利用して構築することを特徴とする請求項１に記載のリソース管理システム。
6. コンピュータが、
   システムの性能情報を参照して、第１のデータセンタのリソースを利用して実現される第１のシステムの一部の機能構成を第２のデータセンタのリソースを利用して実現しても前記第１のシステムに対応する第１の性能情報を満たすか否かを判断し、
   前記第１の性能情報を満たすと判断した場合、前記第２のデータセンタのリソースを利用して前記一部の機能を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記第２のデータセンタのリソースとを利用して構築する、
   処理を実行することを特徴とするリソース管理方法。
7. コンピュータに、
   システムの性能情報を参照して、第１のデータセンタのリソースを利用して実現される第１のシステムの一部の機能構成を第２のデータセンタのリソースを利用して実現しても前記第１のシステムに対応する第１の性能情報を満たすか否かを判断し、
   前記第１の性能情報を満たすと判断した場合、前記第２のデータセンタのリソースを利用して前記一部の機能を実現することで、前記第１の性能情報を満たす構成システムを前記第１のデータセンタのリソースと前記第２のデータセンタのリソースとを利用して構築する、
   処理を実行させることを特徴とするリソース管理プログラム。

Images