(57)【要約】【課題】本発明はオーバーコミットが発生しないようにリソース配分を制御することを目的とする。【解決手段】仮想マシンの内で、リソースの平均使用率があらかじめ決めてあるポリシー値を超えた場合に、ポリシー値を満たすように、他のポリシー値を満たさなくならない仮想マシンからリソースを確保し、リソースを引き受ける仮想マシンのある物理サーバの余剰リソースより、前記確保したリソース容量が大きい場合、物理サーバのリソース容量を超えないようにリソース配分する変更指示をだす。【選択図】  図１
2014130413.tif 000002
【特許請求の範囲】
【請求項１】
物理マシンを特定する情報と、前記物理マシンのリソース容量と前記物理マシンのリソースの未割当容量とを対応付けて記憶する物理マシンリソース情報管理テーブルと、
仮想マシンを特定する情報と、前記仮想マシンのリソースの容量と前記仮想マシンがある前記物理マシンを特定する情報を対応付けて記憶する仮想マシンリソース情報管理テーブルと、
前記仮想マシンを特定する情報と、前記仮想マシンがリソース要求する閾値であるポリシー値を対応付けて記憶するポリシー情報管理テーブルと、
前記仮想マシンの平均使用リソース容量が前記ポリシー値を超えた場合に、前記平均使用リソース容量が前記ポリシー値を下回るような割当リソース容量を算出し、前記平均使用リソース容量が前記ポリシー値を下回ることなく前記ポリシー値を維持だけるだけの余裕リソース容量のある仮想マシンから、前記追加リソース容量を確保するリソース分析部と、
前記追加リソース容量が確保された場合に、前記仮想マシンのある前記物理マシンの前記未割当容量を、前記確保された追加リソース容量が超える場合に、前記物理マシンリソース情報管理テーブルの各物理マシンの前記未割当容量を参照していき、前記仮想マシンのリソース容量と前記確保された追加リソース容量を加算した容量より、前記未割当容量の方が大きくなる物理マシン上へ前記仮想マシンを移動させてリソースを配分する変更指示を出すプロビジョニング指示部とを有するリソース管理サーバと、
前記リソース管理サーバからの前記変更指示を受け取った場合に、前記物理マシンリソース情報管理テーブルの前記未割当容量から新たに前記仮想マシンに割当られたリソース容量を減じ、前記仮想マシンリソース情報管理テーブルの前記仮想マシンのリソース容量を前記新たに前記仮想マシンに割当られたリソース容量分だけ増やすように、値をそれぞれ書き換えるプロビジョニング実行部を有する仮想環境統合管理サーバと
からなることを特徴とする計算機管理システム。
【請求項２】
請求項１に記載の計算機管理システムであって、
前記仮想マシンリソース情報管理テーブルは更に、
仮想マシンの所属するグループを特定するテナントＩＤを、前記仮想マシンを特定する情報と、前記仮想マシンのリソースの容量と前記仮想マシンがある前記物理マシンを特定する情報と対応付けて記憶し、
前記リソース分析部は、
前記テナントＩＤが同じ仮想マシンから前記追加リソース容量を確保する
ことを特徴とする計算機管理システム。
【請求項３】
請求項１乃至請求項２のうちいずれか一項に記載の計算機管理システムであって、
前記ポリシー情報管理テーブルは更に、
前記仮想マシン毎に優先度の情報を、前記仮想マシンを特定する情報と、前記ポリシー値と対応付けて記憶し、
前記リソース分析部は、
前記優先度の順に前記追加リソース容量を確保する仮想マシンを優先的に選択する
ことを特徴とする計算機管理システム。
【請求項４】
物理マシンを特定する情報と、前記物理マシンのリソース容量と前記物理マシンのリソースの未割当容量とを対応付けて物理マシンリソース情報管理テーブルに記憶するステップと、
仮想マシンを特定する情報と、前記仮想マシンのリソースの容量と前記仮想マシンがある前記物理マシンを特定する情報を対応付けて仮想マシンリソース情報管理テーブルに記憶するステップと、
前記仮想マシンを特定する情報と、前記仮想マシンがリソース要求する閾値であるポリシー値を対応付けてポリシー情報管理テーブルに記憶するステップと、
前記仮想マシンの平均使用リソース容量が前記ポリシー値を超えた場合に、前記平均使用リソース容量が前記ポリシー値を下回るような割当リソース容量を算出し、前記平均使用リソース容量が前記ポリシー値を下回ることなく前記ポリシー値を維持だけるだけの余裕リソース容量のある仮想マシンから、前記追加リソース容量を確保するステップと、
前記追加リソース容量が確保された場合に、前記仮想マシンのある前記物理マシンの前記未割当容量を、前記確保された追加リソース容量が超える場合に、前記物理マシンリソース情報管理テーブルの各物理マシンの前記未割当容量を参照していき、前記仮想マシンのリソース容量と前記確保された追加リソース容量を加算した容量より、前記未割当容量の方が大きくなる物理マシン上へ前記仮想マシンを移動させてリソースを配分する変更指示を出すステップと、
前記物理マシンリソース情報管理テーブルの前記未割当容量から新たに前記仮想マシンに割当られたリソース容量を減じ、前記仮想マシンリソース情報管理テーブルの前記仮想マシンのリソース容量を前記新たに前記仮想マシンに割当られたリソース容量分だけ増やすように、値をそれぞれ書き換えるステップと
を有することを特徴とする計算機管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機システムの運用の管理に用いられる管理装置に係り、特に、物理的な計算機上に構築される仮想マシンへのリソース配分を管理する技術に関する。
【背景技術】
【０００２】
近年のＩＴ市場では、仮想化技術の発展が進んでおり、仮想化技術を用いたサービスが広く提供されている。仮想化技術を利用することで、サーバのＣＰＵやメモリといったハードウェアリソースを論理的にプール化し、必要なだけのリソースを割り当てた仮想マシンを１つの物理マシンから複数構築することができる。例えば、特許文献１には、物理マシン上で複数の仮想マシンを稼働させ、各仮想マシンにおけるリソースの使用状況に応じて仮想マシンに対するリソースの回収・割当をすることが開示されている。
【０００３】
また、仮想マシンにリソースを割当てる場合に、物理マシンが備える物理リソース以上のリソースを仮想マシンに擬似的に割当てるオーバーコミットという技術が一般的に知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2005-309644号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
仮想マシン同士でリソース配分を実施した場合に、仮想マシンに割当てるリソースが物理マシンのリソースを上回ると、仮想マシンの性能が不安定になる恐れがある。特許文献１には、このように、物理マシン上で稼働する仮想マシンへのリソースの割り当てが、物理マシンの有するリソース量を超えてしまい、仮想マシンの性能が不安定な状態となることを回避することについては述べられていない。
【０００６】
本発明は仮想マシンへのリソース配分をする場合にこのような不安定な状態を回避するようにリソース配分を管理することを目的とする。
【課題を解決するための手段】
【０００７】
上述の課題を解決する為に、リソース管理サーバが、物理マシンを特定する情報と、前記物理マシンのリソース容量と前記物理マシンのリソースの未割当容量とを対応付けて記憶する物理マシンリソース情報管理テーブルと、仮想マシンを特定する情報と、前記仮想マシンのリソースの容量と前記仮想マシンがある前記物理マシンを特定する情報を対応付けて記憶する仮想マシンリソース情報管理テーブルと、前記仮想マシンを特定する情報と、前記仮想マシンがリソース要求する閾値であるポリシー値を対応付けて記憶するポリシー情報管理テーブルと、前記仮想マシンの平均使用リソース容量が前記ポリシー値を超えた場合に、前記平均使用リソース容量が前記ポリシー値を下回るような割当リソース容量を算出し、前記平均使用リソース容量が前記ポリシー値を下回ることなく前記ポリシー値を維持だけるだけの余裕リソース容量のある仮想マシンから、前記追加リソース容量を確保するリソース分析部と、前記追加リソース容量が確保された場合に、前記仮想マシンのある前記物理マシンの前記未割当容量を、前記確保された追加リソース容量が超える場合に、前記物理マシンリソース情報管理テーブルの各物理マシンの前記未割当容量を参照していき、前記仮想マシンのリソース容量と前記確保された追加リソース容量を加算した容量より、前記未割当容量の方が大きくなる物理マシン上へ前記仮想マシンを移動させてリソースを配分する変更指示を出すプロビジョニング指示部とを有し、仮想環境統合管理サーバが、前記リソース管理サーバからの前記変更指示を受け取った場合に、前記物理マシンリソース情報管理テーブルの前記未割当容量から新たに前記仮想マシンに割当られたリソース容量を減じ、前記仮想マシンリソース情報管理テーブルの前記仮想マシンのリソース容量を前記新たに前記仮想マシンに割当られたリソース容量分だけ増やすように、値をそれぞれ書き換えるプロビジョニング実行部とを有する。
【発明の効果】
【０００８】
仮想マシンに割当てるリソースが物理マシンのリソースを上回ってしまい仮想マシンの性能が不安定になることを防ぐ。
【図面の簡単な説明】
【０００９】
【図１】計算機システムの全体構成図である。
【図２】物理マシンリソース情報管理テーブルである。
【図３】仮想マシンリソース情報管理テーブルである。
【図４】ポリシー情報管理テーブルである。
【図５】平均稼働情報管理テーブルである。
【図６】仮想マシンの稼働情報管理テーブルである。
【図７】テナントごとの仮想マシンのリソースを自動的に最適化する方法を示すフローチャート図である。
【図８】仮想マシンのリソース平均使用率更新処理の流れを示すフローチャート図である。
【図９】仮想マシンの追加リソース確保処理の流れを示すフローチャート図である。
【図１０】仮想マシンのリソース変更処理の流れを示すフローチャート図である。
【図１１】仮想マシンのリソース変更処理の流れを示すフローチャート図である。
【図１２】リソース管理サーバの構成を表す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施例について、図面を参照して詳細に説明する。
【００１１】
図１は、本実施例に係る計算機システムの全体構成を示す簡略化されたブロック図である。計算機システムは、管理端末１とリソース管理サーバ２と仮想環境統合管理サーバ３と仮想マシン実行サーバ４がネットワークに接続されて構成される。  
リソース管理サーバ２は、仮想環境統合管理サーバ３から仮想マシンのリソース稼動情報を取得するリソース収集部５と、仮想マシンに対してリソースの追加が必要かどうかを判定し、必要な場合にはリソースの適正値を算出するリソース分析部６と、管理端末１から受け付けた仮想マシンのリソース稼動情報におけるポリシー値を設定するためのポリシー管理部７と、仮想環境統合管理サーバ３に対して、プロビジョニング指示を発行するプロビジョニング指示部８と、物理マシンのリソース情報および、テナントごとの仮想マシンのポリシー情報、リソース平均稼動情報、およびリソース情報を管理するリソース管理ＤＢを含んで構成される。
【００１２】
仮想環境統合管理サーバ３は、リソース管理サーバ２よりプロビジョニング指示を受け付け、その内容に従い仮想マシン実行サーバに対し、ＣＰＵおよびメモリのリソース量の変更を命令するプロビジョニング実行部８と、リソース管理サーバ２がテナントごとの仮想マシンの稼働情報を収集するために参照する仮想環境管理ＤＢを含んで構成される。
【００１３】
仮想マシン実行サーバ４は、仮想環境統合管理サーバ３から受け付けた命令に従い、仮想マシン実行サーバ４上に構築される論理的な計算機である仮想マシン１３へのリソースの割り当て、変更を実施し、仮想マシン実行サーバ４上での仮想マシン１３の動作を制御する仮想マシン制御部１０を含んで構成される。仮想マシン実行サーバ４は物理的な計算機（物理マシーン）であって、いわゆるサーバ、パーソナルコンピュータ等の計算機で構成される。なお、仮想マシン１３は、１台の仮想マシン実行サーバ４上で複数存在することが出来る。
【００１４】
本実施例では、このように、管理端末１とリソース管理サーバ２と仮想環境統合管理サーバ３と仮想マシン実行サーバ４がネットワークに接続される構成であるが、これに限定される訳ではなく、それぞれのサーバを一つに統合したサーバー（装置）としてもよいし、それぞれの機能の場所が特定されるものではない。
【００１５】
また、本実施例では、リソース管理サーバ２と仮想環境統合サーバ３が計算機管理システムとしての役割を持つがこれに限定されるものではなく、仮想環境統合サーバ３と共に一つのサーバとして統合された装置として構成されていてもよい。
【００１６】
図１２はリソース管理サーバ２の構成を表すブロック図である。リソース管理サーバ２は、ＣＰＵ０２０１、メモリ０２０２、ハードディスク０２０３、通信制御装置０２０５、Ｉ／Ｏインタフェース０２０８を有してなり、通信制御装置０２０５を通じて、仮想環境統合管理サーバ３や、仮想マシン実行サーバ４、管理端末１に接続される。また、Ｉ／Ｏインタフェースを通じて、入力装置０２０６や出力装置０２０７へ接続される。リソース管理ＤＢはハードディスク等の記憶装置に記憶される。また、リソース収集部、リース分析部、ポリシー管理部、プロビジョニング指示部はそれぞれプログラムとして実現され、これらのプログラムがＣＰＵにより実行されることで、その機能が実現される。
＜テーブル＞
仮想マシンのリソースに余力がある状態の判定については詳細について後述するが、例えば仮想マシン１３に仮想マシン実行サーバ４の物理的な２ＧＢのメモリが割当てられているとすると、仮想マシン１３は必ずしもその２ＧＢのメモリ全体を使うわけではなく、仮想マシン１３の負荷によりその使われる物理的なメモリ領域は変動する。この物理的なメモリ領域の使われない余剰部分が大きい場合が仮想マシン１３のリソースに余裕がある場合である。
【００１７】
図２は、リソース管理サーバ２が具備する物理マシンリソース情報管理テーブル１１２のデータ構造とデータ構成例を示す図である。物理マシンリソース情報管理テーブル１１２は、仮想マシン実行サーバ４ごとのリソース情報を格納するためのテーブルである。
【００１８】
物理マシンリソース情報管理テーブル１１２は、物理マシンＩＤ１１２１、ＣＰＵリソース１１２２、割当済みＣＰＵリソース１１２３、未割当ＣＰＵリソース１１２４、メモリリソース１１２５、割当済みメモリリソース１１２６、未割当メモリリソース１１２７を有する。
【００１９】
物理マシンＩＤ１１２１には、仮想マシン１３を実行している仮想マシン実行サーバ４を識別する値（物理マシンＩＤ）が格納され、各仮想マシン実行サーバ４には、任意の物理マシンＩＤが一意に割り当てられる。ＣＰＵリソース１１２２には、物理マシンＩＤ１１２１に格納された物理マシンＩＤで識別される仮想マシン実行サーバ４が保持しているＣＰＵリソース量が、割当済みＣＰＵリソース１１２３には、当該仮想マシン実行サーバ４上で動作する１つまたは複数の仮想マシンに割り当てられているＣＰＵリソース量の合計値が、ＣＰＵ空きリソース１１２４には、当該仮想マシン実行サーバ４が保持するＣＰＵリソースのうち、未使用のＣＰＵリソース量が、メモリリソース１１２５には、当該仮想マシン実行サーバ４が保持しているメモリリソース量が、割当済みメモリリソース１１２６には、当該仮想マシン実行サーバ４上で動作する１つまたは複数の仮想マシン１３に割り当てられているメモリリソース量の合計値が、メモリ空きリソース１１２７には、当該仮想マシン実行サーバ４が保持するメモリリソースのうち、未使用のメモリリソース量が、それぞれ格納される。
【００２０】
本実施例ではリソースとしてＣＰＵ、メモリのみを考慮しているが、記憶装置や通信装置等、他のリソースを含んでもよい。
【００２１】
図３は、リソース管理サーバ２が具備する仮想マシンリソース情報管理テーブル１１３のデータ構造とデータ構成例を示す図である。仮想マシンリソース情報管理テーブル１１３は、仮想マシンに割り当てられているＣＰＵリソース量とメモリリソース量を管理するためのテーブルである。
【００２２】
仮想マシンリソース情報管理テーブル１１３は、仮想マシンＩＤ１１３１、ＣＰＵリソース１１３２、メモリリソース１１３３、物理マシンＩＤ１１３４、テナントＩＤ１１３５を有する。仮想マシンＩＤ１１３１には、仮想マシン１３を識別する値が、ＣＰＵリソース１１３２には、仮想マシン１３に割り当てられている現在のＣＰＵリソース量が、メモリリソース１１３３には、仮想マシン１３に割り当てられている現在のメモリリソース量が、物理マシンＩＤ１１３４には、仮想マシン１３がどの仮想マシン実行サーバ４上に配置されているかを識別する物理マシンＩＤが、テナントＩＤには、各仮想マシン１３がどのテナントに所属しているかを識別するテナントＩＤが、それぞれ格納される。
【００２３】
ここで、テナントとは、単一もしくは複数の仮想マシンをそれぞれグループ分けする単位を言う。本実施例では、同一テナント内（グループ内）の仮想マシン間でリソースが配分され、この同一テナント内の仮想マシンのリソースの総和が一定になるように制御される。例えば、データセンタなどでは、客はテナント単位で複数の仮想マシンを、仮想マシンを管理する者から購入する。上述したようにリソースの配分を制御することで、同一テナント内のうちどれかの仮想マシンがリソース不足になった場合、その購入した同一テナント内の仮想マシンのリソースの総和内で、他のリソースに余力のある仮想マシンからリソースの不足した仮想マシンへリソースを配分することにより、追加で仮想マシンやリソースを購入することなしに、リーズナブルにリソースを融通できるようになる。
【００２４】
本実施例では、仮想マシンリソース情報管理テーブルで各仮想マシンとテナントを対応させているが、これに限定されるものではなく、別途仮想マシンとテナントだけを対応付けるテナントＤＢを持たせてもよい。
【００２５】
また、仮想マシン１３に割当てられているＣＰＵリソース、メモリリソース等のリソースとは、物理マシンから仮想マシンに物理的に実際に割当てられている容量のことを言う。
【００２６】
図４は、リソース管理サーバ２が具備するポリシー情報管理テーブル１１４のデータ構造とデータ構成例を示す図である。ポリシー情報管理テーブル１１４は、ポリシー管理部７が管理端末１から受け付けたポリシー情報を格納するためのテーブルである。
【００２７】
ポリシー情報管理テーブル１１４は、仮想マシンＩＤ１１４１、ＣＰＵポリシー値１１４２、メモリポリシー値１１４３、開始時刻１１４４、終了時刻１１４５、優先度１１４６を有する。仮想マシンＩＤ１１４１には、テナントが所有する仮想マシン１３を識別する値が、ＣＰＵポリシー値１１４２には、仮想マシン１３へＣＰＵリソース配分するかしないかの判断の閾値となる値が、メモリポリシー値１１４３には、仮想マシンへのメモリリソース配分をするかしないかの判断の閾値となる値が、開始時刻１１４４には、仮想マシンのリソースの稼働情報の収集を開始する時刻が、終了時刻１１４５には、仮想マシンのリソースの稼働情報の収集を終了する時刻が、優先度１１４６には、リソースの自動配置を行う仮想マシン１３の優先度を表す値が、それぞれ格納される。本実施例では、優先度１が最も優先度の高い値とし、ポリシー情報管理テーブル１１４においては、ＶＭ０１が最も優先されるものとする。
【００２８】
本実施例では、ポリシー値として、仮想マシン１３に割り当てられたリソース量に対して、仮想マシン１３が実際に使用しているリソース量の割合である使用率を用い、仮想マシン１３による所定期間におけるリソース使用率の平均値（平均使用率）が、このユーザが任意に定めたある使用率（ポリシー値）を超えた場合にリソース配分が実施される。
【００２９】
具体的には、仮想マシンＩＤがＶＭ０１の場合、この仮想マシンに割当てられている物理リソースは図３の仮想マシンリソース情報管理テーブルよりＣＰＵリソースは６ＧＨｚ、メモリリソースは８ＧＢであり、ＣＰＵポリシー値が６０％とは、この６ＧＨｚのうち、３．６ＧＨｚ、メモリポリシー値が７０％とは、８ＧＢのうち５．６ＧＢ以上使用されると、リソース配分処理が行われる。
【００３０】
つまり、ＶＭ０１の場合は、ＣＰＵリソースが３．６ＧＨｚ以上使用されると、他のリソースに余力のある仮想マシンからＶＭ０１へＣＰＵリソース配分処理が、メモリリソースが５．６ＧＢ以上使用されると、他のリソースに余力のある仮想マシンからＶＭ０１へメモリリソース配分処理が開始されることになる。このリソース配分の処理の詳細については後述する。
【００３１】
本実施例では、リソースの平均使用率がポリシー値を超えた場合にリソース配分処理が行われるが、使用率が瞬間的に閾値として設定されたポリシー値を超えた場合に、リソース配分処理されるようにしてもよい。
【００３２】
図５は、リソース管理サーバ２が具備する平均稼働情報管理テーブル１１５のデータ構造とデータ構成例を示す図である。平均稼働情報管理テーブル１１５は、仮想マシン１３の稼働情報として、平均のリソース使用率を格納するためのテーブルである。稼働情報管理テーブル１１５は、仮想マシンＩＤ１１５１、ＣＰＵ平均使用率１１５２、メモリ平均使用率１１５３を有する。仮想マシンＩＤ１１５１には、テナントが所有する仮想マシンを識別する値が、ＣＰＵ平均使用率１１５２には、ポリシー管理テーブル１１４で指定されたリソース収集時間における仮想マシンのＣＰＵ使用率の平均値が、メモリ平均使用率１１５３には、ポリシー管理テーブル１１４で指定されたリソース収集時間における仮想マシンのメモリ使用率の平均値が、それぞれ格納される。
【００３３】
ここで、例えば、仮想マシンＩＤがＶＭ０１の仮想マシンに着目すると、図３の仮想マシンリソース情報管理テーブル１１３から、割り当てられているＣＰＵリソースは６ＧＨｚである。また、図５の平均稼働情報管理テーブル１１５から、ＶＭ０１のＣＰＵ平均使用率は８０％となっており、仮想マシンＶＭ０１のＣＰＵリソースは単位時間あたりに平均して４．８ＧＨｚ使用されていることが分かる。
【００３４】
図６は、仮想環境統合管理サーバ３が具備する仮想マシンの稼働情報管理テーブル１２１のデータ構造とデータ構成例を示す図である。仮想環境統合管理サーバ３は、このテーブルにより、各仮想マシンのリソースの使用状況を管理する。稼働情報管理テーブル１２１は、仮想マシン毎に管理される。稼働情報管理テーブル１２１には、時刻１２１１、ＣＰＵ使用率１２１２、メモリ使用率１２１３が格納される。時刻１２１１には、００：００〜００：３０といったような時刻の一定範囲の情報が順に（この場合３０分毎に区切られて順に記憶される）格納される。ＣＰＵ使用率１２１２には、時刻１２１１で示される時間範囲における仮想マシンのＣＰＵリソースの平均の使用率を表す値が格納され、メモリ使用率１２１３には、同じ時間範囲において仮想マシンが使用したメモリリソース量の割合を表す値が格納される。
【００３５】
本実施例では００：００から３０分毎の、リソースの平均使用率を記憶しているが、これに限定されるものではなく、１時間毎や１０分毎でもよく、ユーザが適時決定できることとしてもよい。
＜フローチャート＞
次に、本実施例の処理の流れについて説明する。
【００３６】
図７は、本実施例において、テナントごとの仮想マシンのリソースを自動的に最適化する方法を示すフローチャートである。リソース管理サーバ２は、まず、ステップＳ１では、仮想マシンに対して後述するリソース平均使用率更新処理（図８）を行う。次に、ステップＳ２では、ステップＳ１で更新した仮想マシンのリソース平均使用率とリソースのポリシー値とを比較し、リソース追加割り当ての要否を判定し、リソース追加割り当てが必要であれば、ステップＳ３に進む。リソース追加割り当てが不要であればステップＳ１０に進む。
【００３７】
例えば、稼働情報管理テーブル１２１の各仮想マシンのＣＰＵとメモリの使用率から、ポリシー情報管理テーブル１１４のリソース収集時間の開始時刻から終了時刻までの平均使用率を求め、平均稼働情報管理テーブル１１５のデータを更新する。そして、更新されたＣＰＵ、メモリの平均使用率と、ポリシー情報管理テーブル１１４の仮想マシン毎のＣＰＵポリシー値とメモリポリシー値とを比較して、各平均使用率の値がポリシー値を超えている場合にリソースの追加割当が必要と判定してリソースの追加処理に移る。本実施例での場合、仮想マシンＩＤがＶＭ０１のＣＰＵポリシー値が６０％、メモリポリシー値が７０％であり、ＣＰＵポリシー値をＣＰＵの平均使用率が超えている為、リソースの追加割当要と判定する。一方、メモリポリシー値をメモリの平均使用率は下回っている為、リソース追加割当否と判定する。
【００３８】
ステップＳ３では、仮想マシンへの追加リソースの確保処理（図９）を行う。この追加リソースの確保処理については詳細後述する。ステップＳ４では、リソースの確保可否の結果を判定し、リソースの確保ができた場合はステップＳ５に進む。リソースの確保ができなかった場合はステップＳ１０に進む。
ステップＳ５では、Ｓ３で確保したリソースを当該仮想マシンに対して追加した場合に、当該仮想マシンが稼働する仮想マシン実行サーバ４上で稼働する仮想マシンのリソース量の合計値が、仮想マシン実行サーバ４のリソース量を超過するかどうかを判定する（オーバーコミット判定）。ステップＳ５では、オーバーコミット判定において、オーバーコミットであった場合、ステップＳ６に進む。オーバーコミットでなかった場合は、ステップＳ９に進む。
ここでオーバーコミットとは、物理マシン上で例えばリソースが（１０）あるところに、リソース（５）の仮想マシンとリソース（６）の仮想マシンを配置することをいう。この場合本来リソース（１０）を擬似的にリソース（１１）として扱うので処理が重くなる問題がある。
具体的には、仮想マシンリソース情報管理テーブル１１３からリソースを追加割当する仮想マシンＩＤに対応する物理マシンＩＤを特定し、特定された物理マシンＩＤを、物理マシンリソース情報管理テーブル１１２に照合して、当該物理マシンＩＤで特定される仮想マシン実行サーバ４の未割当のリソースの量を特定する。追加割当されるリソースの量が、この特定された未割当のリソースの量を超える場合にオーバーコミットと判定される。例えば、リソースを追加割当する仮想マシンの仮想マシンＩＤがＶＭ０１である場合、仮想マシンリソース情報管理テーブル１１３を参照して、物理マシンＩＤがＰＭ０１の仮想マシン実行サーバを特定する。特定された物理マシンＩＤＰＭ０１を物理マシンリソース情報管理テーブル１１２に照合して、この仮想マシン実行サーバの未割当ＣＰＵリソースが１ＧＨｚであると特定し、追加割当しようとするリソースの量と比較して１ＧＨｚより多い場合にオーバーコミットと判定される。
【００３９】
ステップＳ６では、当該仮想マシンにリソースを追加割り当てした場合に、物理マシンのリソースを超過しないだけの許容量のある物理マシンを物理マシンリソース管理テーブル１１２から物理マシンＩＤの順に探索していく。具体的には、ステップＳ３で確保された追加リソースと、当該仮想マシンのリソース量を加算したものと、物理マシンリソース管理テーブル１１２の未割当リソース（ＣＰＵを追加する場合は未割当ＣＰＵリソース１１２４、メモリを追加する場合は未割当メモリリソース１１２７を参照する。）を比較して、未割当リソース量が大きくなるものを選択する。
【００４０】
ステップＳ７では、ステップＳ６の探索の結果、該当する仮想マシン実行サーバが存在した場合はステップＳ８に進む。該当する仮想マシンが存在しなかった場合はステップＳ１０に進む。
【００４１】
ステップＳ８では、当該仮想マシンをＳ６で発見した仮想マシン実行サーバに、仮想環境統合管理サーバ３が有する仮想マシンを別の仮想マシン実行サーバに移動させる機能を用いるなどして移動させる。
ステップＳ９では、仮想マシンに対するリソースの配分処理（図１０）を行う。そしてステップＳ１０では、テナントの全ての仮想マシンに対してステップＳ１〜Ｓ９が完了したら、ステップＳ１１に進む。完了していない仮想マシンが存在する場合は、ステップＳ１に戻り、次に優先度の高い仮想マシンに対して同様の処理を行う。
【００４２】
ステップＳ１１では、全てのテナントに対してステップＳ１〜Ｓ１０が完了したら、一連の処理を終了する。完了していないテナントが存在する場合は、ステップＳ１に戻り、次のテナントに対して同様の処理を行う。
【００４３】
図８は、リソース管理サーバ２が具備するリソース収集部５において実行される、仮想マシンのリソース平均使用率更新処理の流れを示すフローチャートである。この処理において、リソース収集部５は、ＣＰＵ平均使用率とメモリ平均使用率それぞれに対して更新処理を行う。まず、ＣＰＵ平均使用率から処理を行う。
【００４４】
ステップＳ１２で、リソース収集部５は、仮想環境統合管理サーバ３の稼動情報管理テーブル１２１より、ポリシー管理テーブル１１４の開始時刻１１４４で示される時刻から終了時刻１１４５で示される時刻までの仮想マシンのＣＰＵ使用率を取得する。本実施例ではポリシー管理テーブル１１４で定義される仮想マシンＩＤがＶＭ０１の仮想マシンについて、リソース収集時間の開始時刻は０９：００、終了時刻１７：００なので、稼働情報管理テーブルの０９：００〜０９：３０、０９：３０〜１０：００・・・１６：３０〜１７：００の使用率をそれぞれ取得する。ここで、リソースの使用率としては、仮想マシンから逐次送られてくる使用率の情報をそのまま利用しても良いし、送られてくる情報が使用率ではなく、使用リソース量の場合は、仮想マシンリソース情報管理テーブルを参照し、仮想マシンに割当てられているリソース量に対する受信した使用リソース量を見て使用率を算出してもよい。
【００４５】
例えば、仮想マシンＩＤがＶＭ０１の仮想マシンで使用されるＣＰＵ使用量が３ＧＨｚである場合は、仮想マシンリソース情報管理テーブル１１３より仮想マシンＩＤがＶＭ０１の仮想マシンに割り当てられているＣＰＵリソース量６ＧＨｚから、３／６×１００から５０％として使用率を算出できる。
【００４６】
そしてステップＳ１３では、ステップＳ１２で取得したＣＰＵ使用率と、ＣＰＵ平均使用率１１５２から新たなＣＰＵ平均使用率を再計算し、算出した値をＣＰＵ平均使用率１１５２に書き換え、更新する。平均稼働情報管理テーブル１１５には、リソースの使用量の最新の値を記憶するので、新しく使用率が算出された場合は更新する。
【００４７】
ここで、ポリシー情報管理テーブル１１４でいうリソース収集時間の開始時間と、終了時間とは、ユーザが任意に設定できる平均使用率を算出したい開始時間と終了時間をいい、仮想マシンの稼働情報管理テーブルとは、逐次更新される稼働マシンの時間毎の使用率をみるものである。
【００４８】
また本実施例では使用率のパーセンテージで表記しているがこれに限定されるものではなく、リソース量をそのまま表すものであってもよい。
【００４９】
具体的にはステップＳ１２で読み出した値から、０９：００〜１７：００の平均の使用率を算出して、ポリシー管理テーブル１１４のポリシー値をそれぞれ更新する。例えば、稼働情報管理テーブルの００：００〜００：３０のＣＰＵ使用率が１５％、００：３０〜０１：００のＣＰＵ使用率が１０％である場合、００：００〜０１：００の使用率は、（１０＋１５）／２で１２．５％となる。
【００５０】
ステップＳ１４で、リソース収集部５は、稼動情報管理テーブル１２１より、ポリシー管理テーブル１１４の開始時刻１１４４で示される時刻から終了時刻１１４５で示される時刻までの仮想マシンのメモリ使用率を取得する。そしてステップＳ１５では、取得したメモリ使用率とメモリ平均使用率１１５３から新たなメモリ平均使用率を再計算し、算出した値をメモリ平均使用率１１５３に書き換え、更新する。
【００５１】
図９は、リソース管理サーバ２が具備するリソース分析部６において実施される、仮想マシンの追加リソース確保処理の流れを示すフローチャートである。この処理は、ＣＰＵリソースとメモリリソースそれぞれに対して行われる。まず、ＣＰＵリソースから処理を行う。
【００５２】
ステップＳ１６では、ステップＳ２の判定で仮想マシンに対してＣＰＵリソースの追加が必要だった場合、ステップＳ１７に進む。ＣＰＵリソースの追加が不要だった場合、ステップＳ２０に進む。
【００５３】
ステップＳ１７では、仮想マシンに割り当てる追加ＣＰＵリソース量を算出する。追加ＣＰＵリソース量は、ＣＰＵ平均使用率１１５２がＣＰＵポリシー値１１４２を下回るようにその値を求める。
【００５４】
ＣＰＵリソース量は、ＣＰＵリソース１１３２、ＣＰＵポリシー値１１４２、ＣＰＵ平均使用率１１５２より算出される。仮想マシンに割当てられている物理ＣＰＵリソース量を「Ｖ」、ＣＰＵポリシー値を「Ｗ」、ＣＰＵ平均使用率を「Ｘ」、追加ＣＰＵリソース量を「Ａ」、とすると、（Ｖ＋Ａ)×Ｗ／１００＝Ｖ×Ｘ／１００となり、これをＡについて求めると、Ａ＝Ｖ×（Ｘ−Ｗ）／Ｗにより追加ＣＰＵリソース量を求めることができる。
【００５５】
具体的には、例えば、本実施例の仮想マシンＶＭ０１は、ＣＰＵ平均使用率がＣＰＵポリシー値を超過しているため、ＣＰＵリソースの追加割り当てが必要であり、追加ＣＰＵリソース量を「Ａ」として算出すると、（６＋Ａ）×６０／１００＝６×８０／１００となり、これをＡについて求めると、Ａ＝２（ＧＨｚ）となり、ＣＰＵポリシー値を維持するためには、２ＧＨｚのＣＰＵリソースを他の仮想マシンから回収する必要がある。
【００５６】
ステップＳ１８では、優先度の低い仮想マシンから、回収できるＣＰＵリソース量を算出する。回収できるＣＰＵリソース量は、ＣＰＵ平均使用率１１５２がＣＰＵポリシー値１１４２を下回ることなくＣＰＵポリシーを維持できるだけの値となる。
【００５７】
また、仮想マシンリソース情報管理テーブルの割当予定の仮想マシンの仮想マシンＩＤに対応するテナントＩＤを特定し、同じテナントＩＤの仮想マシンからリソースを割当てる。ここでは、ユーザが利用するテナント中のみで、リソースの割当を行うことで、他のテナントへの影響を防止する。本実施例ではテナントと表現しているがこれに限定されるものではなく、複数の仮想マシンをグルーピングするものであれば良く、グループＩＤのようにしてもよい。前述したテナントＤＢにより、仮想マシンとテナントの関係を定義している場合は、割当予定の仮想マシンＩＤをテナントＤＢに照合して、テナントＩＤを特定し、特定されたテナントＩＤを持つ、仮想マシンＩＤを特定して、特定された仮想マシンＩＤの仮想マシンからリソースを回収すればよい。
【００５８】
仮想マシンから回収できるＣＰＵリソース量は、仮想マシンリソース情報管理テーブル１１３のＣＰＵリソース１１３２、ポリシー情報管理テーブル１１４のＣＰＵポリシー値１１４２、平均稼働情報管理テーブル１１５のＣＰＵ平均使用率１１５２より算出する。ＣＰＵリソースを「Ｖ」、ＣＰＵポリシー値を「Ｗ」、ＣＰＵ平均使用率を「Ｘ」、回収できるＣＰＵリソース量を「Ｂ」、とすると、（Ｖ−Ｂ)×Ｗ／１００＝Ｖ×Ｘ／１００となり、これをＢについて求めると、Ｂ＝Ｖ×（Ｗ−Ｘ）／Ｗにより回収できるＣＰＵリソース量を求めることができる。ここで、Ｂの値が負となる場合は、ＣＰＵ平均使用率がポリシー値を上回っており、リソースの回収をすることはできない。
【００５９】
具体的には、例えば、本実施例の仮想マシンＶＭ０２について回収できるリソース量を求めてみる。回収できるＣＰＵリソース量を「Ｂ」として算出すると、（４−Ｂ）×８０／１００＝４×２０／１００となり、これをＢについて求めると、Ｂ＝３（ＧＨｚ）となり、３ＧＨｚのＣＰＵリソースをＶＭ０２から回収することができる。
【００６０】
なお、自身より優先度の高い仮想マシンからはリソースを回収しないものとし、ＣＰＵリソース量の回収の計算は行わないこととする。回収できるリソースがどこにもない場合は、リソースを確保できないことになる。
【００６１】
ステップＳ１９では、ステップＳ１８において追加ＣＰＵリソース量が確保できたかどうか判定し、追加ＣＰＵリソース量が確保できていればステップＳ２０に進む。確保できていない場合は、処理を終了する。
【００６２】
ステップＳ２０〜Ｓ２３は追加メモリリソース量を算出する処理であり、考え方は追加ＣＰＵリソース量の算出方法と同じである。
【００６３】
図１０は、リソース管理サーバ２が実行する、仮想マシンのリソース変更処理の流れ（オーバーコミットするかどうかの判定）を示すフローチャートである。
【００６４】
ステップＳ２４では、ステップＳ３の追加リソース確保処理において、リソースの回収対象の仮想マシンと、リソースを受ける側の仮想マシンが、同じ仮想マシン実行サーバに配置されているかどうか判定し、同じ仮想マシン実行サーバに配置されていなければステップＳ２５に進み、されている場合は、本処理を終了する。
【００６５】
ステップＳ２５では、ステップＳ３の追加リソース確保処理において、他の仮想マシン実行サーバから回収するリソース量が、当該仮想マシンが配置されている仮想マシン実行サーバの空きリソースを超過するかどうか判定し、超過する場合はステップＳ２６に進む。超過しない場合は本処理を終了する。
ステップＳ２６では、当該仮想マシンが配置されている仮想マシン実行サーバ上で当該仮想マシンにＳ３で確保されたリソース量を割り当てるとオーバーコミットすると判定する。つまり、仮想マシンに、物理マシン以上のリソースが割当てられてしまう状態であると判定する。
【００６６】
図１１は、リソース管理サーバ２が具備するプロビジョニング指示部８において実行される、仮想マシンのリソース変更処理の流れを示すフローチャートである。この処理は、ＣＰＵリソースとメモリリソースそれぞれに対して行われる。まず、ＣＰＵリソースから処理を行う。
【００６７】
ステップＳ２７では、図９の追加ＣＰＵリソース確保処理において、ＣＰＵリソースの回収対象の仮想マシンについて、プロビジョニング指示部８がリソースの変更指示を出し、指示を受け付けたプロビジョニング実行部９がリソースの変更処理を行う。回収対象の仮想マシンが複数あった場合は、全ての仮想マシンに対してリソースの変更処理を行う。
【００６８】
ステップＳ２８では、リソース追加割当を行う仮想マシンについて、プロビジョニング指示部８がステップＳ２７で回収したＣＰＵリソースを追加割り当てするよう変更指示を出し、変更指示を受け付けたプロビジョニング実行部９がリソースの追加割り当てを行う。なお、リソース管理サーバ２は、Ｓ２７とＳ２８によって変更があった仮想マシンが配置されている物理マシンリソース情報管理テーブル１１２の物理マシンの割当済みＣＰＵリソース１１２３、未割当ＣＰＵリソース１１２４および仮想マシンリソース情報管理テーブル１１３の仮想マシンのＣＰＵリソース１１３２の値を書き換え、更新する。
【００６９】
ステップＳ２９では、図９の追加メモリリソース確保処理において、メモリリソースの回収対象の仮想マシンについて、プロビジョニング指示部８がリソースの変更指示を出し、指示を受け付けたプロビジョニング実行部９がリソースの変更処理を行う。回収対象の仮想マシンが複数あった場合は、全ての仮想マシンに対してリソースの変更処理を行う。
【００７０】
ステップＳ３０では、ステップＳ２９で回収したメモリリソースをリソース追加割当を行う仮想マシンについて、プロビジョニング指示部１０が追加割り当ての変更指示を出し、変更指示を受け付けたプロビジョニング実行部９がリソースの追加割り当てを行う。なお、リソース管理サーバ２は、Ｓ２９とＳ３０によって変更があった仮想マシンが配置されている物理マシンリソース情報管理テーブル１１２の物理マシンの割当済みメモリリソース１１２６、未割当メモリリソース１１２７および仮想マシンリソース情報管理テーブル１１３の仮想マシンのメモリリソース１１３３の値を書き換え、更新する。
【００７１】
これにより、仮想マシン間でリソースの配分をする場合、オーバーコミットが発生しないように制御することができる。
【符号の説明】
【００７２】
１：管理端末、２：リソース管理サーバ、３：仮想環境統合管理サーバ、４：仮想マシン実行サーバ、５：リソース収集部、６：リソース分析部、７：ポリシー管理部、８：プロビジョニング指示部、９：プロビジョニング実行部、１０：仮想マシン制御部、１１：リソース管理ＤＢ、１２：仮想環境管理ＤＢ、１３：仮想マシン
【図１】
2014130413.tif 000003
【図２】
2014130413.tif 000004
【図３】
2014130413.tif 000005
【図４】
2014130413.tif 000006
【図５】
2014130413.tif 000007
【図６】
2014130413.tif 000008
【図７】
2014130413.tif 000009
【図８】
2014130413.tif 000010
【図９】
2014130413.tif 000011
【図１０】
2014130413.tif 000012
【図１１】
2014130413.tif 000013
【図１２】
2014130413.tif 000014