JP2012220977A - 仮想計算機の制御方法及び管理計算機 - Google Patents

Abstract

【課題】複数のテナントが複数の物理計算機リソースを使用する仮想計算機システムにおいてグループ間の負荷の不均衡を迅速に解消する。
【解決手段】管理計算機が、複数の仮想計算機を複数のグループに割り当て、グループ単位の負荷の値を取得し、負荷の値が閾値を超えたグループを第１のグループとし、複数のグループのうち第１のグループを除く第２のグループから移動対象計算機を選択し、移動対象計算機の仮想計算機を第２のグループ内の他の物理計算機へ移動させ、移動対象計算機を第２のグループから第１のグループへ移動させる際に、移動対象計算機の仮想化部の仮想ネットワークの設定を前記第１のグループに応じて変更し、移動対象計算機を第１のグループで稼動するようにネットワークスイッチの設定を変更し、移動対象計算機を第１のグループに追加してから、移動対象計算機に第１のグループの仮想計算機を稼動させる。
【選択図】図３８

Description

本発明は、仮想計算機システムにおける計算機リソースの割り当てに関し、特に、計算機資源のテナント単位（または利用グループ単位）で計算機リソースを管理する際に、仮想計算機とネットワークやストレージ装置の割り当ての変更を円滑に行う技術に関する。

プロセッサのコア数の増大と仮想化技術の向上によって、多数の仮想計算機に物理計算機の計算機リソースを割り当てる自由度も向上し、少ない物理リソースで多数の仮想計算機を運用することが可能となった。

多数の物理計算機を保有するデータセンターでは、複数の顧客に複数の仮想計算機を貸し出すことが広く行われている。そして、データセンターでは、顧客（以下、テナント）毎にネットワークやストレージ装置の利用形態を設定し、ＳＬＡ（Service Level Agreement）に応じて仮想計算機が使用するリソースを設定する。このように複数のテナントがデータセンタ内の物理計算機を利用する環境をマルチテナント環境という。

この種の、マルチテナント環境においては、物理計算機リソースに対する仮想計算機の集約率を向上することでデータセンタの収益性を向上さるには、少ない物理計算機リソースを各テナントの負荷に応じて動的に割り当てる運用が必要となる。

仮想計算機に割り当てる物理計算機リソースを動的に変更する技術としては、ＶＭｗａｒｅ（登録商標）社のＤＲＳ（Distributed Resource Scheduler）やマイクロソフト（登録商標）社のＰＲＯ(Performance and Resource Optimization）などが知られている。これらの技術を利用することで、複数のハイパバイザ(物理サーバ)からなるリソースグループ内において、ハイパバイザ間の負荷に不均衡が生じた場合には、ＤＲＳなどのシステムが仮想計算機のマイグレーションプランを提示したり、自動的に仮想計算機をマイグレーションして負荷の平準化を行い、これによって管理者の運用コストを削減することができる。

上記のＤＲＳを利用して仮想計算機の負荷を平準化するためには、すべての物理計算機に対して、ＬＡＮスイッチやＳＡＮスイッチの設定と、ハイパバイザ内の仮想スイッチの設定及びストレージの設定を同一にしておく必要がある。

しかし、ＬＡＮスイッチやＳＡＮスイッチの設定は、データセンタを利用するテナント毎にＶＬＡＮやゾーニングを設定するため、異なるテナント間で、リソースを分配することは難しい。ここで、異なるネットワークセグメント間で物理計算機の移動を実現するために、物理ルータや物理ＬＡＮスイッチの設定を変更する手法が知られている（例えば、特許文献１）。

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

ところで、仮想計算機に物理計算機リソースを割り当てるハイパバイザなどの仮想化部は、内部に仮想スイッチ（または仮想ネットワーク）を構成して、同一の仮想化部上の仮想計算機間の通信は、物理的なＩ／Ｏデバイスを使用することとなく、内部の仮想スイッチで通信を行っている。

このため、上述のようなマルチテナント環境の仮想計算機システムに上記特許文献１を適用しても、仮想化部の内部の仮想スイッチの設定を変更できないため、ひとつの物理計算機を他のテナントで利用するためには、管理者などが手動で仮想スイッチの設定等を変更しなければならず、データセンタの運用コストが増大する、という問題があった。

また、データセンタ内で、同一のテナントであれば、ＬＡＮスイッチやＳＡＮスイッチの設定も同一の場合が多いので、テナント毎、あるいはテナント内の一部をリソースグループとして扱うことができる。このとき、各リソースグループ内では上述のＤＲＳ等によって低コストで負荷の平準化が可能である。

しかし、リソースグループ間やテナント間等のグループ間で負荷の不均衡が発生した場合には、上述のように、依然として運用管理者が手動で対策しなければならず、物理計算機リソースの割り当て変更を迅速に行うことができず、人手が必要となるため運用コストも増大する、という問題があった。

そこで本発明は、上記問題点に鑑みてなされたもので、複数のテナントが複数の物理計算機リソースを使用する仮想計算機システムにおいて、物理計算機リソースを複数のテナント間で迅速に融通することを目的とする。

本発明は、プロセッサとメモリを備えた物理計算機と、前記物理計算機のリソースを分割して仮想計算機を提供する仮想化部と、複数の前記物理計算機を接続するネットワークスイッチと、前記ネットワークスイッチに接続された管理計算機と、を備えて前記複数の物理計算機上で提供される複数の仮想計算機の制御方法であって、前記管理計算機が、前記複数の仮想計算機を複数のグループに割り当てる第１の手順と、前記管理計算機が、前記グループ単位の負荷の値を取得し、予め設定したしきい値と前記負荷の値を比較する第２の手順と、前記管理計算機が、前記負荷の値が前記しきい値を超えたグループを第１のグループとして特定する第３の手順と、前記管理計算機が、前記複数のグループのうち前記第１のグループを除く第２のグループを選択する第４の手順と、前記管理計算機が、前記第２のグループに割り当てられた仮想計算機を実行する物理計算機のうち所定の物理計算機を移動対象計算機として特定する第５の手順と、前記管理計算機が、前記移動対象計算機で提供される仮想計算機を前記第２のグループ内の他の物理計算機へ移動させる第６の手順と、前記管理計算機が、前記移動対象計算機を前記第２のグループから削除する第７の手順と、前記管理計算機が、前記移動対象計算機の仮想化部の仮想ネットワークの設定を前記第１のグループに応じて変更するよう当該仮想化部に指令する第８の手順と、前記管理計算機が、前記移動対象計算機を第１のグループで稼動するように前記ネットワークスイッチの設定を変更する第９の手順と、前記管理計算機が、前記移動対象計算機を第１のグループに追加する第１０の手順と、前記管理計算機が、前記移動対象計算機に前記第１のグループの仮想計算機を稼動させる第１１の手順と、を含む。

したがって、本発明は、グループ間で負荷の不均衡が発生した場合には、負荷の低いグループ（移動元）から適切な物理計算機を取り除き、負荷の高いグループに当該物理計算機を割り当て直すことで、グループ間の負荷の不均衡を低減することが可能となる。

本発明の第１の実施形態を示し、仮想計算機を提供する計算機システムの一例を示すブロック図である。 本発明の第１の実施形態を示し、仮想計算機を提供するサーバの一例を示すブロック図である。 本発明の第１の実施形態を示し、テナントＡ、Ｂにサーバ１３０を割り当てたときの計算機リソースの一例を示すブロック図である。 本発明の第１の実施形態を示し、テナントＡで実行するサービスとＶＬＡＮ及びゾーンの一例を示すブロック図である。 本発明の第１の実施形態を示し、テナントＡで実行するサービスとＶＬＡＮ及びゾーンとＬＡＮスイッチ、ＳＡＮスイッチの関係を示すブロック図である。 本発明の第１の実施形態を示し、テナントＡのハイパバイザ２００に設定された仮想スイッチの一例を示すブロック図である。 本発明の第１の実施形態を示し、計算機システム内のリソースを管理する運用管理システムの機能要素の一例を示すブロック図である。 本発明の第１の実施形態を示し、テナントデータベースの一例を示すブロック図である。 本発明の第１の実施形態を示し、稼動データベースの一例を示すブロック図である。 本発明の第１の実施形態を示し、構成データベースの一例を示すブロック図である。 本発明の第１の実施形態を示し、リソースグループグループテーブル５１０の一例を示す図である。 本発明の第１の実施形態を示し、 ＶＭテーブル５２０の一例を示す図である。 本発明の第１の実施形態を示し、仮想ネットワークテーブル５３０の一例を示す図である。仮 本発明の第１の実施形態を示し、ＬＵテーブル５４０の一例を示す図である。 本発明の第１の実施形態を示し、稼動データベース４０７のホスト稼動情報テーブル５５０の一例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９のホストテーブル５６０の一例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９の負荷項目テーブル５７０の一例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９のテナント−ホストテーブル５８０の一例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９のホスト−ＶＭテーブル５９０の一例を示す図である。 本発明の第１の実施形態を示し、 構成データベース４０９のホスト−ＮＩＣテーブル６００の一例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９のホスト−ＨＢＡテーブル６１０の一例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９のＬＡＮスイッチ管理情報６２０の一例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９のＳＡＮスイッチ管理情報６３０の一例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９のＳＡＮゾーンテーブル６４０の一例を示す図である。Ｓ 本発明の第１の実施形態を示し、構成データベース４０９のＳＡＮゾーンテーブル６４０の変形例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９のストレージテーブル６５０の一例を示す図である。 本発明の第１の実施形態を示し、構成データベース４０９のストレージ−ホスト管理テーブル６６０の一例を示す図である。 本発明の第１の実施形態を示し、稼動管理モジュール４０３で行われる処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、判定モジュール４０４で行われる処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、図２５のステップＳ１４で行われるテナント毎の評価値ベクトルの演算処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、図２５のステップＳ１８で行われる変更プラン生成モジュール４０５の処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、図２７のステップＳ３１で行われる移動元のテナントと移動先のテナントの決定処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、図２７のステップＳ３２で行われるリソースグループの変更プランの生成処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、図２７のステップＳ３３で行われる仮想ネットワークの変更プランの生成処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、図２７のステップＳ３４で行われるＬＡＮスイッチの変更プランの生成処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、図２７のステップＳ３５で行われるＳＡＮスイッチの変更プランの生成処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、図２７のステップＳ３６で行われるストレージ１５０の変更プランの生成処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、変更モジュール４０６で行われる処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、変更プラン生成モジュール４０５が生成する通知画面４２０の一例を示す画面イメージである。 本発明の第１の実施形態を示し、変更プラン生成モジュール４０５が生成した移動対象ホストＨｍｏｖｅの移動前後の詳細なプランの表示画面４３０の画面イメージである。 本発明の第１の実施形態を示し、変更モジュール４０６が生成する進捗状況表示画面４４０である。 本発明の第１の実施形態を示し、図３４のステップＳ１０１、Ｓ１０２に対応するブロック図である。 本発明の第１の実施形態を示し、図３４のステップＳ１０３に対応するブロック図である。 本発明の第１の実施形態を示し、図３４のステップＳ１０４に対応するブロック図である。 本発明の第１の実施形態を示し、図３４のステップＳ１０５、Ｓ１０６に対応するブロック図である。 本発明の第１の実施形態を示し、図３４のステップＳ１０７に対応するブロック図である。 本発明の第１の実施形態を示し、図３４のステップＳ１０８に対応するブロック図である。 本発明の第２の実施形態を示し、仮想計算機を提供する計算機システムの一例を示すブロック図である。 本発明の第２の実施形態を示し、複数のテナントで共有されるサーバの一例を示すブロック図である。 本発明の第２の実施形態を示し、変更プラン生成モジュール４０５で行われる処理の一例を示すフローチャートである。 本発明の第２の実施形態を示し、変更モジュール４０６で行われる処理の一例を示すフローチャートである。 本発明の第２の実施形態を示し、移動対象ホストＨｍｏｖｅ（ＨＯＳＴ０１）上で稼動する仮想計算機２１１を同一テナント内で退避させる例を示すブロック図である。 本発明の第２の実施形態を示し、親ハイパバイザ２００Ａが論理区画に割り当てるリソースの比率を変更する例を示すブロック図である。 本発明の第２の実施形態を示し、親ハイパバイザ２００Ａが論理区画に割り当てるリソースの比率を変更した後に仮想計算機２１１を再配置するブロック図である。 本発明の第３の実施形態を示し、変更モジュール４０６で行われる処理の一例を示すフローチャートである。 本発明の第４の実施形態を示し、仮想計算機を提供する計算機システムの一例を示すブロック図である。 本発明の第４の実施形態を示し、図２７のステップＳ３４で行われるＬＡＮスイッチの変更プランの生成処理の一例を示すフローチャートである。 本発明の第４の実施形態を示し、ホストＨＯＳＴ０１を移動する前の計算機システムのブロック図である。 本発明の第４の実施形態を示し、ホストＨＯＳＴ０１を移動した後の計算機システムのブロック図である。 本発明の第５の実施形態を示し、サーバ管理者用の通知画面の一例を示す画面イメージである。 本発明の第５の実施形態を示し、ネットワーク管理者用の通知画面の一例を示す画面イメージである。 本発明の第５の実施形態を示し、ＳＡＮ管理者用の通知画面の一例を示す画面イメージである。 本発明の第５の実施形態を示し、ストレージ管理者用の通知画面の一例を示す画面イメージである。

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

図１は、本発明の第１の実施形態を示し、仮想計算機を提供する計算機システムの構成の一例を示すブロック図である。

物理計算機で構成されるサーバ１３０−１〜１３０−６のそれぞれでは、後述するハイパバイザによって複数の仮想計算機が実行される。サーバ１３０−１〜１３０−６はＬＡＮスイッチ１２１、１２２を介して相互に接続され、また、ＬＡＮスイッチ１２１、１２２がネットワーク１１０を介してクライアント１００−１、１００−２に接続される。

サーバ１３０−１〜１３０−６は、ＳＡＮスイッチ１４１，１４２を介してストレージ１５０−１、１５０−２に接続される。サーバ１３０−１〜１３０−６でそれぞれ実行される各仮想計算機は、所定のサービスをクライアント１００−１、１００−２に提供する。

また、各サーバ１３０−１〜１３０−６は管理ＬＡＮスイッチ１６０を介して運用管理システム１７０−１、１７０−２及び管理クライアント１８０に接続される。運用管理システム１７０−１、１７０−２はサーバ１３０−１〜１３０−６の構成や稼動に関する管理を行う物理計算機である。運用管理システム１７０−１、１７０−２は、仮想計算機システムの冗長性を保つため、一方が現用系、他方が待機系となっており以下では運用管理システム１７０−１が現用系とする。管理クライアント１８０は、仮想計算機システムを利用する顧客（以下、テナントとする）の情報や、仮想計算機に割り当てる物理計算機のリソースなどを運用管理システムに指令する。

なお、クライアント１００−１、１００−２の総称を添え字のないクライアント１００で示し、同様にサーバ１３０−１〜１３０−６の総称をサーバ１３０で示し、ストレージ１５０−１、１５０−２の総称をストレージ１５０で示し、現用系の運用管理システム１７０−１を符号１７０で示す。

本発明の仮想計算機システムでは、複数のテナントがサーバ１３０で実行される仮想計算機を利用し、あるテナントＡのサーバ１３０の負荷が上昇すると、他のテナントＢのサーバ１３０のうち適切なサーバ１３０をテナントＡに提供し、物理計算機リソースを融通させるものである。

図２は、仮想計算機を提供するサーバ１３０−ｎの一例を示すブロック図である。なお、サーバ１３０−１〜１３０−６は同一の構成であり、実行する仮想計算機２１１−１〜２１１−ｎの数や割り当てたリソースが異なるだけである。なお、以下では仮想計算機２１１−１〜２１１−ｎの総称を仮想計算機２１１とする。

サーバ１３０は、演算処理を行う複数のプロセッサ（図中ＣＰＵ）２２１−１，２２１−２と、データやプログラムを保持するメモリ２２３と、プログラムやデータを格納するディスク装置２２４と、ＬＡＮスイッチ１２１（または１２２）及び管理ＬＡＮスイッチ１６０に接続されるネットワークインターフェース（図中ＮＩＣ）２２５−１、２２５−２とＳＡＮスイッチ１４１，１４２に接続されるホストバスアダプタ（図中ＨＢＡ）２２６−１、２２６−２と、を備える物理計算機である。

プロセッサ２２１−１，２２１−２は、起動するとディスク装置２２４からハイパバイザ２００を読み込んでメモリ２２３にロードしてから実行する。ハイパバイザ２００は、サーバ１３０の物理計算機リソースを複数の仮想計算機２１１に割り当てて、各仮想計算機２１１を実行させる。仮想計算機２１１では、ＯＳ２０２が実行されこのＯＳ２０２上では所定のアプリケーション２０３が実行される。

図３は、テナントＡ、Ｂにサーバ１３０を割り当てたときの計算機リソースの一例を示すブロック図である。

図示の例では、テナントＡにサーバ１３０−１〜１３０−３を割り当てて、テナントＢにサーバ１３０−４〜１３０−６を割り当てた例を示す。

テナントＡが利用するサーバ１３０−１〜１３０−３の計算機リソースには、物理計算機リソースとしてのサーバハードウェア２０１と、仮想計算機２１１を提供する仮想化部としてのハイパバイザ２００と、複数の仮想計算機２１１からリソースグループＲＧＡを構成する。

同様に、テナントＢが利用するサーバ１３０−４〜１３０−６の計算機リソースには、物理計算機リソースとしてのサーバハードウェア２０１と、仮想計算機２１１を提供する仮想化部としてのハイパバイザ２００と、複数の仮想計算機２１１からリソースグループＲＧＢを構成する。

テナントＡが使用するサーバ１３０−１〜１３０−３はＬＡＮスイッチ１２１のポート１〜３に接続される。ＬＡＮスイッチ１２１には、これらポート１〜３とポート９を接続するＶＬＡＮ２３１が設定される。ポート９は通信経路１２３を介してネットワーク１１０と接続されており、ポート１〜３のサーバ１３０−１〜１３０−３はクライアント１００と通信可能となる。

テナントＢが使用するサーバ１３０−３〜１３０−６はＬＡＮスイッチ１２１のポート４〜６に接続される。ＬＡＮスイッチ１２１には、これらポート４〜６とポート９を接続するＶＬＡＮ２３２が設定される。ポート９は通信経路１２３を介してネットワーク１１０と接続されており、ポート４〜６のサーバ１３０−４〜１３０−６はクライアント１００と通信可能となる。

テナントＡが使用するサーバ１３０−１〜１３０−３は、ＳＡＮスイッチ１４１のポート１．０〜１．３に接続される。ＳＡＮスイッチ１４１には、これらポート１．０〜１．３とポート１．９を接続するゾーンＺ０が設定される。ポート１．９はストレージ１５０−１のポートＳ１に接続されて、論理ユニット(以下、ＬＵ）１（２６１）とＬＵ２（２６２）にアクセス可能となっている。これにより、サーバ１３０−１〜１３０−３はＬＵｌ、ＬＵ２にアクセス可能となっている。

テナントＢが使用するサーバ１３０−１〜１３０−３は、ＳＡＮスイッチ１４１のポート１．５〜１．７に接続される。ＳＡＮスイッチ１４１には、これらポート１．５〜１．７とポート１．１０を接続するゾーンＺ１が設定される。ポート１．１０はストレージ１５０−１のポートＳ２に接続されて、論理ユニットＬＵ３（２６３）とＬＵ４（２６４）及びＬＵ５（２６５）にアクセス可能となっている。これにより、サーバ１３０−４〜１３０−６はＬＵ３〜ＬＵ５にアクセス可能となっている。なお、ＬＡＮスイッチ１２１、ＳＡＮスイッチ１４１及びリソースグループの設定は、後述するように運用管理システム１７０が実施する。

また、運用管理システム１７０に搭載された前記従来例でも述べたＤＲＳ（Distributed Resource Scheduler）やＰｒｏにより、リソースグループＲＧＡ、ＲＧＢ内で仮想計算機をマイグレーションしてサーバ１３０間の負荷の平準化を図ることができる。

図４は、テナントＡで実行するサービスとＶＬＡＮ及びゾーンの一例を示すブロック図である。本図では、図３に示した１２の仮想計算機（図中ＶＭ）２１１のうち、３台がＷｅｂサーバ３０１〜３０３、３台がＡＰ（アプリケーション）サーバ３０４〜３０６、２台がＤＢサーバ３０７，３０８を実行するＷｅｂ３階層アプリケーションの例を示す。

テナントＡのサーバ１３０が利用するＬＡＮスイッチ１２１のＶＬＡＮ２３１（図３参照）は、図４で示す２つのＶＬＡＮ１（３１１）とＶＬＡＮ２（３１２）から構成されている。

一方、ゾーンＺ０は、テナントＡの全てのサーバ３０１〜３０８が論理ユニットＬＵ１へアクセスするパスと、アプリケーションサーバ３０４〜３０６とＤＢサーバ３０７、３０８がＬＵ２にアクセするパスを有する。なお、ＬＵ１は仮想計算機２１１の仮想マシンイメージ（ＷＭｗａｒｅではＶＭＤＫ、ＭＳではＶＨＤ）を保存する領域であり、仮想計算機２１１のマイグレーションをするために格納場所を共有する。ＬＵ２はＡＰサーバやＤＢサーバがアクセスするデータ領域である。本例ではＷｅｂサーバはローカルディスクにデータを格納するものとしているが、ＬＵ２のような外部ストレージにデータを格納してもよい。また、Ｗｅｂサーバ，ＡＰサーバ，ＤＢサーバのそれぞれ毎にＬＵを設けても良い。

図５Ａは、テナントＡで実行するサービスとＶＬＡＮ及びゾーンとＬＡＮスイッチ、ＳＡＮスイッチの関係を示すブロック図である。本図では、図４に示した１２の仮想計算機（図中ＶＭ）２１１のうち、３台の仮想計算機がＷｅｂサーバ３０１〜３０３として稼動し、３台の仮想計算機がＡＰ（アプリケーション）サーバ３０４〜３０６として稼動し、２台の仮想計算機がＤＢサーバ３０７，３０８として稼動する。Ｗｅｂサーバ３０１〜３０３はそれぞれ２つのネットワークインタフェース（ＮＩＣ）を持ち、その１つはＬＡＮスイッチ１２１のＶＬＡＮ１に所属し、ポート９の通信経路１２３とネットワーク１１０を介してクライアント１００と通信可能に設定される。一方各Ｗｅｂサーバ３０１〜３０３のもう一方のネットワークインタフェース（ＮＩＣ）とＡＰサーバ３０４〜３０６とＤＢサーバ３０７，３０８はＶＬＡＮ２に所属しており、相互に通信可能となっている。

図５Ｂは、テナントＡのサーバ１３０−１のハイパバイザ２００に設定された仮想スイッチの設定の一例を示すブロック図である。

図２のネットワークインターフェースＮＩＣ１（２２５−１）が図５Ｂの物理ＮＩＣ（ＰＮＩＣ０）に対応し、ハイパバイザ２００は、物理的なＰＮＩＣ０を仮想化した仮想ネットワークインターフェースＶＮＩＣ＃１〜＃４を仮想計算機２１１−１〜３に提供する。ここで、仮想計算機２１１−１には２つの仮想ネットワークインターフェースＶＮＩＣ＃１、＃２が組み込まれる。

ハイパバイザ２００の仮想スイッチは、仮想ネットワークインターフェースＶＮＩＣ＃１と物理的なＰＮＩＣ０を接続する仮想ネットワーク２５０−１と、各仮想計算機２１１−１〜３の仮想ネットワークインターフェースＶＮＩＣ＃２〜＃４を仮想ネットワーク２５０−２に接続する。そして、ハイパバイザ２００は、仮想ネットワーク２５０−１をＶＬＡＮ１に所属させ、仮想ネットワーク２５０−２をＶＬＡＮ２に所属させる。

この設定により、Ｗｅｂサーバ３０１（仮想計算機２１１−１）は仮想ネットワーク２５０−１のＶＬＡＮ１を介して外部のネットワーク１１０を介してクライアント１００と通信を行うことができる。一方、ＡＰサーバ３０４を提供する仮想計算機２１１−２と、ＤＢサーバ３０７を提供する仮想計算機２１１−３の仮想ネットワークインターフェースＶＮＩＣ＃３、＃４は、仮想ネットワーク２５０−２を介してＷｅｂサーバ３０１の仮想ネットワークインターフェースＶＮＩＣ＃２と通信することができるが、ＶＬＡＮ１にはアクセスできないので、仮想計算機２１１−２、３のＡＰサーバ３０４とＤＢサーバ３０７は外部のネットワーク１１０から遮断されてセキュリティを確保することができる。

なお、ハイパバイザ２００の実装の一例として、仮想化部内に仮想スイッチが定義できる例を示し、仮想ネットワークインターフェースＶＮＩＣ＃１〜＃４、仮想ネットワークインターフェースが属する仮想ネットワーク、仮想ネットワークが外部サーバと通信するための物理ネットワークインターフェースとの対応関係が定義できる。

ハイパバイザ２００内の仮想ネットワークにはＶＬＡＮの設定が存在するため、一つの物理サーバ１３０上で動作する複数の仮想計算機２１１を別々のＶＬＡＮに所属させる運用において、物理サーバ１３０の所属テナントを変更する場合は、仮想スイッチの設定を変更することが必須となる。

図５Ｂの例では、ハイパバイザ２００の仮想スイッチで２つの仮想ネットワークＶＮ＃１とＶＮ＃２が設定され、仮想ネットワークＶＮ＃１はＶＬＡＮ１が割り当てられ、ＶＮ＃２はＶＬＡＮ２が割り当てられる。さらに、仮想ネットワークＶＮ＃１とＶＮ＃２は一つの物理ネットワークインターフェース（ＰＮＩＣ０）を共有している。このため、物理ＬＡＮスイッチ１２１のポート１は複数のＶＬＡＮタグ１とタグ２が通過できるトランクポートとなる。同一テナント内のすべてのハイパバイザ２００は同一の仮想ネットワーク設定を有し、これによって仮想計算機２１１のマイグレーションが可能となる。しかし、他のテナントでは仮想ネットワークの設定が異なるため、後述するように設定変更が必要となる。

図６Ａは、計算機システム内のリソースを管理する運用管理システム（管理サーバ）１７０−１の機能要素の一例を示すブロック図である。運用管理システム１７０−１は、現用系であり待機系の運用管理システム１７０−２も同一の構成である。

運用管理システム１７０−１は、管理クライアント１８０からの入力に基づいてテナント毎に割り当てる計算機リソースを決定し、リソースグループを生成して各サーバ１３０のハイパバイザ２００に仮想計算機２１１の生成を指令する。

そして、運用管理システム１７０−１は、同一のリソースグループ内でサーバ１３０の負荷に不均衡が生じた場合には、サーバ１３０間で仮想計算機２１１のマイグレーションを実施して負荷の平準化を図る。さらに、テナント間のサーバ１３０で負荷の不均衡が発生したときには、テナント間で計算機リソースを融通することで、テナント間の負荷の平準化を図る。

運用管理システム１７０−１は、管理クライアント１８０にＧＵＩ（Graphical User Interface）を提供するＵＩモジュール４１０と、管理クライアント１８０から入力されたテナント毎の情報を格納し、テナント毎の計算機リソースなどを管理するテナント管理モジュール（グループ管理部）４０１と、サーバ１３０や仮想計算機２１１等の計算機リソースの構成を管理する構成管理モジュール４０２と、各サーバ１３０の稼動状態を管理する稼動管理モジュール４００と、サーバ１３０の負荷の不均衡を検知したときに計算機リソースの割り当て変更を実施するか否かを判定する判定モジュール４０４と、判定モジュール４０４の指令に応じてテナント毎、リソースグループ毎に割り当てる変更プランを生成する変更プラン生成モジュール４０５と、変更プランが管理クライアント１８０等で承認されたときには計算機リソースの割り当て変更を指令する変更モジュール４０６と、仮想計算機２１１の生成や移動及び削除を管理するＶＭ管理モジュール４１１と、計算機システムの構成情報を格納する構成データベース４０９と、テナントの情報を格納するテナントデータベース４０８と、サーバ１３０の稼動状態を蓄積する稼動データベース４０７と、を備える。

なお、運用管理システム１７０は、図２に示したサーバ１３０と同様のハードウェア２００を備える。このため、ハードウェア２００に関する重複した説明は省略する。また、上記各機能モジュールは、記憶媒体としてのディスク２２４にプログラムとして格納され、プロセッサ２２１−１，２２１−２によってメモリ２３３にロードされてから実行される。

図６Ｂは、テナントデータベース４０８の一例を示すブロック図である。テナントデータベース４０８は、後述するリソースグループテーブル５１０と、仮想計算機２１１を管理するＶＭテーブル５２０と、テナント毎に利用する仮想ネットワーク（仮想スイッチ）の情報を管理する仮想ネットワークテーブル５３０と、テナント毎に利用するＬＵの情報を管理する仮想ネットワークテーブル５３０と、を含む。

図６Ｃは、稼動データベース４０７の一例を示すブロック図である。稼動データベース４０７は、後述するホスト稼動情報テーブル５５０を含む。

図６Ｄは、構成データベース４０９の一例を示すブロック図である。構成データベース４０７は、後述するホストテーブル５６０と、負荷項目テーブル５７０と、テナント−ホストテーブル５８０と、ホスト−ＶＭテーブル５９０と、ホスト−ＮＩＣテーブル６００と、ホスト−ＨＢＡテーブル６１０と、ＬＡＮスイッチ管理情報６２０と、ＳＡＮスイッチ管理情報６３０と、ＳＡＮゾーンテーブル６４０と、ストレージテーブル６５０と、ストレージ−ホスト管理テーブル６６０と、を含む。

図７は、リソースグループグループテーブル５１０の一例を示す図である。リソースグループテーブル５１０は、テナントの識別子を格納するテナントＩＤと、テナント毎に割り当てたリソースグループの識別子を格納するリソースグループＩＤからひとつのエントリが構成される。このリソースグループテーブル５１０は、管理者が操作する管理クライアント１８０からの入力によって設定される。

図８は、ＶＭテーブル５２０の一例を示す図である。ＶＭテーブル５１０は、テナントの識別子を格納するテナントＩＤと、テナント毎に割り当てた仮想計算機２１１の識別子を格納するＶＭＩＤからひとつのエントリが構成される。このＶＭテーブル５１０は、テナント管理モジュール４０１、変更モジュール４０６等によって設定される。

図９は、仮想ネットワークテーブル５３０の一例を示す図である。仮想ネットワークテーブル５３０は、テナントの識別子を格納するテナントＩＤと、各テナントのハイパバイザ２００に設定された仮想ネットワークの名称を格納する仮想ネットワークＮＡＭＥと、ネットワークインターフェースの識別子を格納するＮＩＣ＿ＩＤと、ＶＬＡＮの識別子を格納するＶＬＡＮ＿ＩＤからひとつのエントリが構成される。この仮想ネットワークテーブル５３０は、テナント管理モジュール４０１、変更モジュール４０６等によって設定される。

図１０は、ＬＵテーブル５４０の一例を示す図である。ＬＵテーブル５４０は、テナントの識別子を格納するテナントＩＤと、ストレージ１５０の識別子を格納するＳｔｏｒａｇｅＩＤと、ストレージ１５０のポートの識別子を格納するＰＯＲＴと、論理ユニットの識別子を格納するＬＵＮと、ＳＡＮスイッチのゾーンの識別子を格納するＺｏｎｅからひとつのエントリが構成される。このＬＵテーブル５４０は、テナント管理モジュール４０１、変更モジュール４０６、構成管理モジュール４０２、管理クライアント１８０からの入力等によって設定される。

図１１は、稼動データベース４０７のホスト稼動情報テーブル５５０の一例を示す図である。ホスト稼動情報テーブル５５０は、日時を格納するタイムスタンプと、ハイパバイザ２００の識別子を格納するインスタンスＩＤと、負荷の種類を格納するＴｙｐｅと、負荷の値を格納するＶａｌｕｅとからひとつのエントリが構成される。

ここで、インスタンスＩＤに格納されるハイパバイザ２００の識別子は、図５Ａにおいて、ハイパバイザ＃１のインスタンスＩＤが「Ｈｏｓｔ０１」となり、ハイパバイザ＃２のインスタンスＩＤが「Ｈｏｓｔ０２」となり、他のハイパバイザ＃ｎも同様の識別子が運用管理システム１７０によって付与される。

また、負荷の種類を示す「Ｔｙｐｅ」は、「ＣＰＵ＿Ｂｕｓｙ」がサーバ１３０のプロセッサ２２１−１，２２１−２の使用率を示し、「Ｍｅｍ＿Ｂｕｓｙ」がサーバ１３０のメモリ２３３の使用率を示し、「Ｄｉｓｋ＿Ｂｕｓｙ」がサーバ１３０のＨＢＡ２２６−１、２２６−２の使用率を示し、「Ｎｗ＿Ｂｕｓｙ」がサーバ１３０のネットワークインターフェース２２５−１，２２５−２の使用率を示す。また、負荷の値を示す「Ｖａｌｕｅ」は、例えば、「０．２３」＝２３％を示す。

このホスト稼動情報テーブル５５０の値は、稼動管理モジュール４０３が、各サーバ１３０のハイパバイザから取得した値を格納することができる。あるいは、各ハイパバイザ２００が所定の周期で上述した負荷の種類を稼動情報として測定し、これらの測定結果を運用管理システム１７０に送信するようにしてもよい。

図１２は、構成データベース４０９のホストテーブル５６０の一例を示す図である。ホストテーブル５６０は、サーバ１３０の格納位置を示すラックＩＤと、ハイパバイザ２００の識別子を格納するＨｏｓｔＩＤと、サーバ１３０のメモリ２３３の容量を格納するメモリ量と、ネットワークインターフェース２２５−１、２２５−２の転送速度を格納するＮＷ帯域と、ＨＢＡ２２６−１、２２６−２の転送速度を格納するディスクＩ／Ｏ帯域と、仮想化部の種類を格納するハイパバイザタイプとからひとつのエントリが構成される。ハイパバイザタイプには、仮想化部の名称などを格納することができる。

このホストテーブル５６０は、管理者などが管理クライアント１８０から設定した値が格納される。

図１３は、構成データベース４０９の負荷項目テーブル５７０の一例を示す図である。負荷項目テーブル５７０は、ハードウェア２０１からハイパバイザ２００が取得する負荷の種類を設定する。負荷項目テーブル５７０は、ハイパバイザ２００が測定する負荷の名称を格納する計測項目と、仮想計算機２１１の移動や物理計算機資源の再割り当てを行う契機を判定する評価閾値とからひとつのエントリが構成される。

例えば、計測項目が「ＨＯＳＴ＿ＣＰＵ＿Ｂｕｓｙ」の項目では、ハイパバイザ２００がプロセッサ２２１−１，２２１−２の負荷を測定し、負荷が評価閾値０．７を超えると、仮想計算機２１１の移動などを開始することを示す。また、計測項目が「ＨＯＳＴ＿Ｆｒｅｅ＿Ｍｅｍｏｒｙ＿ＧＢ」の項目では、ハイパバイザ２００が、メモリ２３３の空きメモリの容量をＧｉｇａＢｙｔｅの単位で測定することを示す。また、計測項目が「ＨＯＳＴ＿Ｄｉｓｋ＿Ｔｈｒｏｕｈｐｕｔ＿ＭＢ」の項目では、ハイパバイザ２００がＨＢＡ２２６−１、２２２６−２の転送速度をＭｅｇａＢｙｔｅ／ｓｅｃの単位で測定することを示す。また、計測項目が「ＨＯＳＴ＿ＮＷ＿Ｔｈｒｏｕｈｐｕｔ＿ＭＢ」の項目では、ハイパバイザ２００がネットワークインターフェース２２５−１、２２５−２の転送速度をＭｅｇａＢｙｔｅ／ｓｅｃの単位で測定することを示す。

図１４は、構成データベース４０９のテナント−ホストテーブル５８０の一例を示す図である。テナント−ホストテーブル５８０は、各テナントに割り当てるハイパバイザ２００及びサーバ１３０（ホスト）を管理するテーブルで、テナント管理モジュール４０１が管理する。テナント−ホストテーブル５８０は、テナントの識別子を格納するテナントＩＤと、ハイパバイザ２００の識別子を格納するＨｏｓｔＩＤと、からひとつのエントリが構成構成される。なお、ハイパバイザ２００の識別子は、管理クライアント１８０から管理者が設定した値を設定することができる。なお、以下の説明では、ハイパバイザ２００とサーバ１３０を組み合わせたものをホストとし、ホストの識別はハイパバイザ２００の識別子で行う例を示す。

図１５は、構成データベース４０９のホスト−ＶＭテーブル５９０の一例を示す図である。ホスト−ＶＭテーブル５９０は、各ハイパバイザ２００に生成させる仮想計算機２１１を管理するテーブルで、構成管理モジュール４０３が管理する。ホスト−ＶＭテーブル５９０は、ハイパバイザ２００の識別子を格納するＨｏｓｔＩＤと、仮想計算機２１１の識別子を格納するＶＭＩＤと、からひとつのエントリが構成構成される。仮想計算機２１１の識別子は、各ハイパバイザ２００が仮想計算機２１１に付与した識別子を用いてもよいし、構成管理モジュール４０２が各仮想計算機２１１に識別子を付与しても良い。

図１６は、構成データベース４０９のホスト−ＮＩＣテーブル６００の一例を示す図である。ホスト−ＮＩＣテーブル６００は、各サーバ１３０の物理ネットワークインターフェース２２５を管理するテーブルで、構成管理モジュール４０２がハイパバイザ２００から取得した値を設定する。

ホスト−ＮＩＣテーブル６００は、ハイパバイザ２００の識別子を格納するＨｏｓｔＩＤと、ネットワークインターフェース２２５の識別子を格納するＮＩＣ＿ＩＤと、ＭＡＣアドレスとからひとつのエントリが構成される。

図１７は、構成データベース４０９のホスト−ＨＢＡテーブル６１０の一例を示す図である。ホスト−ＨＢＡテーブル６１０は、各ホスト（サーバ１３０＋ハイパバイザ２００）の物理ＨＢＡ２２６を管理するテーブルで、構成管理モジュール４０２がハイパバイザ２００から取得した値を設定する。

ホスト−ＨＢＡテーブル６１０は、ハイパバイザ２００の識別子を格納するＨｏｓｔＩＤと、ＨＢＡ２２６５の識別子を格納するＨＢＡ＿ＩＤと、ＷＷＮを格納するＨＢＡ＿ＷＷＮとからひとつのエントリが構成される。

図１８は、構成データベース４０９のＬＡＮスイッチ管理情報６２０の一例を示す図である。ＬＡＮスイッチ管理情報６２０は、ＬＡＮスイッチ１２１、１２２のポートとＶＬＡＮと接続先の関係を管理するテーブルで、構成管理モジュール４０２が各ＬＡＮスイッチ１２１、１２２から取得した値を設定する。

ＬＡＮスイッチ管理情報６２０は、ＬＡＮスイッチ１２１、１２２の識別子を格納するＬＡＮスイッチＩＤと、ＬＡＮスイッチ１２１、１２２のポート番号を格納するポート番号と、当該ポート番号に接続された装置のＭＡＣアドレスを格納する接続先ＭＡＣアドレスと、当該ポート番号のＶＬＡＮの識別子を格納するＶＬＡＮ＿ＩＤとからひとつのエントリが構成される。

図１９は、構成データベース４０９のＳＡＮスイッチ管理情報６３０の一例を示す図である。ＳＡＮスイッチ管理情報６３０は、ＳＡＮスイッチ１４１、１４２のポートとドメインと接続先の関係を管理するテーブルで、構成管理モジュール４０２が各ＳＡＮスイッチ１４１、１４２から取得した値を設定する。

ＳＡＮスイッチ管理情報６３０は、ＳＡＮスイッチ１４１、１４２の識別子を格納するＳＡＮスイッチＩＤと、ＳＡＮスイッチ１４１、１４２のポートに設定されたドメインを格納するドメインＩＤと、ＳＡＮスイッチ１４１、１４２のポート番号を格納するポート番号と、当該ポート番号に接続された装置のＷＷＮを格納する接続先ＷＷＮとからひとつのエントリが構成される。

図２０は、構成データベース４０９のＳＡＮゾーンテーブル６４０の一例を示す図である。ＳＡＮゾーンテーブル６４０は、ＳＡＮスイッチ１４１、１４２のポートとゾーンの関係を管理するテーブルで、構成管理モジュール４０２が各ＳＡＮスイッチ１４１、１４２から取得した値を設定する。

ＳＡＮゾーンテーブル６４０は、ＳＡＮのゾーン識別子を格納するゾーンＩＤと、ドメインの識別子を格納するドメインＩＤと、ＳＡＮスイッチ１４１，１４２のポート番号を格納するＰｏｒｔからひとつのエントリが構成される。

なお、ＳＡＮスイッチ１４１，１４２ではポート毎にホストとストレージ１５０を異なるゾーンに設定する場合もあるので、ＳＡＮゾーンテーブル６４０としては、図２１に示すようにしても良い。

図２１は、構成データベース４０９のＳＡＮゾーンテーブル６４０の変形例を示す図である。ＳＡＮゾーンテーブル６４０は、ゾーンＩＤと、ホスト側のドメインＩＤとポート番号の組と、ストレージ１５０側のドメインＩＤとポート番号の組をひとつのエントリとして構成することができる。

また、図２０の変形例としては、上記ポートゾーニングの他に、ＷＷＮゾーニングを行っても良く、この場合、図２０のＰｏｒｔはＷＷＮに置き換えればよい。

図２２は、構成データベース４０９のストレージテーブル６５０の一例を示す図である。ストレージテーブル６５０は、ストレージ１５０の識別子を格納するストレージＩＤと、ストレージ１５０のポート番号を格納するＰＯＲＴと、ストレージ１５０のＷＷＮを格納する接続機器ＷＷＮとからひとつのエントリが構成される。

これらの値は、構成管理モジュール４０２が各ストレージ１５０から取得した値を設定する。

図２３は、構成データベース４０９のストレージ−ホスト管理テーブル６６０の一例を示す図である。ストレージ−ホスト管理テーブル６６０は、ホストに割り当てるＬＵの関係を管理するテーブルである。ストレージ−ホスト管理テーブル６６０は、ハイパバイザ２００の識別子を格納するホストグループＩＤと、ハイパバイザ２００に割り当てるＬＵの識別子を格納するＬＵＮと、当該ＬＵにアクセスする機器（ＨＢＡ）のＷＷＮを格納する接続機器ＷＷＮとからひとつのエントリが構成される。なお、ホストグループＩＤに代わってハイパバイザ２００の識別子や、サーバ１３０の識別子を用いるようにしてもよい。

図２４は、稼動管理モジュール４０３で行われる処理の一例を示すフローチャートである。この処理は、管理クライアント１８０からの指令に基づいて開始される。

ステップＳ１で、稼動管理モジュール４０３は、構成データベース４０９の負荷項目テーブル５７０を読み込んで、負荷を測定する負荷計測項目リストを作成する。次に、ステップＳ２で、稼動管理モジュール４０３は、構成データベース４０９のホストテーブル５６０を読み込んで、全てのホスト（ハイパバイザ２００）の識別子を取得する。

ステップＳ３では、全てのホスト（ハイパバイザ２００＋サーバ１３０）について負荷の計測が完了したか否かを判定し、完了していなければステップＳ４に進み、完了した場合にはステップＳ６に進む。

ステップＳ４では、稼動管理モジュール４０３は、ひとつのホスト（ハイパバイザ２００）にアクセスしてステップＳ１で生成した負荷計測項目リストの全てについて負荷を取得する。そして、ステップＳ５では、稼動管理モジュール４０３が、取得した負荷の値を使用率に変換して稼動データベース４０７のホスト稼動情報テーブル５５０に書き込む。

上記ステップＳ１〜Ｓ５を繰り返すことで、稼動管理モジュール４０３は全てのホストから負荷項目テーブル５７０に設定された負荷を取得して、ホスト毎にホスト稼動情報テーブル５５０に稼動情報を蓄積する。

そして、ステップＳ５で、全てのホストについて稼動情報の収集が完了すればステップＳ６に進んで、管理クライアント１８０から終了の指示があるまで上記ステップＳ１からＳ５の処理を繰り返す。これにより、ホスト稼動情報テーブル５５０には、新たな負荷を示す値が蓄積される。

図２５は、判定モジュール４０４で行われる処理の一例を示すフローチャートである。この処理は、管理クライアント１８０からの指令に基づいて開始される。または、所定の周期（例えば、１０分毎）等で起動するようにしても良い。

まず、ステップＳ１１では、判定モジュール４０４が、リソースグループテーブル５１０を読み込んで、全てのテナントを取得してテナントリストを生成する。

ステップＳ１２では、判定モジュール４０４は、テナントリストの全てのテナントについてステップＳ１３、Ｓ１４の処理が完了したか否かを判定する。全てのテナントについいて処理が完了していればステップＳ１５に進み、完了していなければステップＳ１３に進む。

ステップＳ１３では、判定モジュール４０４が、ステップＳ１１で作成したテナントリストからひとつのテナントを選択する。そして、ステップＳ１４では、判定モジュール４０４が、選択したテナントの評価値ベクトルＷＬＶｔを演算する。テナントの評価値ベクトルの詳細については図２６で詳述する。

ステップＳ１３、Ｓ１４で全てのテナントについて評価値ベクトルを求めると、ステップＳ１５に進む。ステップＳ１５では、判定モジュール４０４が、上記演算した各テナントの評価値ベクトルＷＬＶｔを予め設定した閾値ベクトルＷＬＴｈとを比較する。

そして、ステップＳ１６では、判定モジュール４０４が、各テナントの評価値ベクトルの全ての要素が、閾値ベクトルの要素よりも小さい場合には処理を終了し、一方、各テナントの評価値ベクトルの少なくともひとつの要素が、閾値ベクトルの要素以上の場合にはステップＳ１７に進む。

ステップＳ１７では、ホスト（ハイパバイザ２００＋サーバ１３０）の再配置（計算機資源の再割り当て）が必要となるため、判定モジュール４０４はＵＩモジュール４１０にアラートを送信する。ＵＩモジュール４１０は、アラートを受信すると、管理クライアント１８０にホストの再配置が必要である旨の通知を送信する。

次に、ステップＳ１８に進んで、判定モジュール４０４は、変更プラン生成モジュール４０５を起動させる。なお、変更プラン生成モジュール４０５の処理については、図２７で詳述する。

以上の処理により、判定モジュール４０４は、全てのテナントについて評価値ベクトルを求め、評価値ベクトルのいずれかひとつが閾値ベクトル以上のときには、計算機資源の再割り当てが必要であると判定して、管理クライアント１８０に通知を送り、変更プランの生成を開始する。

図２６は、図２５のステップＳ１４で行われるテナント毎の評価値ベクトルの演算処理の一例を示すフローチャートである。

まず、ステップＳ２１では、ステップＳ１３で選択されたテナントについて、テナント−ホストテーブル５８０を参照し、当該テナントに割り当てられているホスト（ハイパバイザ２００）のリストを取得する。

ステップＳ２２では、判定モジュール４０４が、ホスト稼働情報テーブル５５０を参照し、予め設定された過去の時刻から現在までの当該テナントに属するすべてのハイパバイザ２００の負荷値を読み出す。ここで、予め設定された過去の時刻は、例えば、５分前に設定され、稼動管理モジュール４０３が１０秒の周期で負荷の測定を行うと、３０個の負荷が集計対象となる。

ステップＳ２３では、判定モジュール４０４が、ステップＳ２２で読み込んだホスト（ハイパバイザ２００＋サーバ１３０）毎の負荷項目毎に負荷の値を集計して、評価値ベクトルＷＬＶｔを演算する。ここで、判定モジュール４０４は、図１１に示したホスト稼動情報テーブル５５０のタイムスタンプから該当するインスタンスＩＤのホスト（ハイパバイザ２００＋サーバ１３０）の稼動情報を取得し、負荷の種類「Ｔｙｐｅ」ごとにビジー率で示された負荷値「Ｖａｌｕｅ」を評価値ベクトルＷＬＶｔとして演算する。この評価値ベクトルは、例えば、ＣＰＵ、メモリ、ディスク、ネットワークの項目毎にビジー率（Ｖａｌｕｅ）の平均値（５分間）をＬｃｐｕ、Ｌｍｅｍ、Ｌｄｉｓｋ、Ｌｎｗとして求め、この平均値のベクトル（Ｌｃｐｕ、Ｌｍｅｍ、Ｌｄｉｓｋ、Ｌｎｗ）を当該ホストの評価値ベクトルＷＬＶｔとする。

上記処理によってあるテナントを構成するホスト毎の負荷が集計され、テナント単位で負荷が閾値ベクトルを超えたか否かを判定することができる。なお、上記では評価値ベクトルＷＬＶｔを求める例を示したが、テナント単位で負荷が閾値を超えたか否かを判定できる値であればよい。

図２７は、図２５のステップＳ１８で行われる変更プラン生成モジュール４０５で行われる処理の一例を示すフローチャートである。

まず、ステップＳ３１では、変更プラン生成モジュール４０５が、ハイパバイザ２００の負荷の要素が閾値以上となった移動先のテナントと、ハイパバイザ２００の移動元のテナント決定する。移動元のテナントは、計算機資源の割り当てを減少させるテナントであり、移動先のテナントが計算機資源の割り当てを増大させるテナントとなる。この処理については、図２８で詳述する。

次に、変更プラン生成モジュール４０５は、ステップＳ３２でリソースグループを構成するホストを変更するプランを生成する。この処理については、図２９で詳述する。

次に、ステップＳ３３では、変更プラン生成モジュール４０５が、ハイパバイザ２００内の仮想ネットワークを変更するプランを生成する。例えば、テナントＢのハイパバイザ２００を、テナントＡのハイパバイザ２００として利用するためには、ＶＬＡＮの設定が異なるのに加え、図５Ｂで示したように、ハイパバイザ２００内の仮想ネットワークの構成も異なるからである。この処理については、図３０で詳述する。

次に、ステップＳ３４では、変更プラン生成モジュール４０５が、ＬＡＮスイッチ１２１、１２２の設定を変更するプランを生成する。これは、上述のように、テナント毎にＶＬＡＮの構成が異なるためで、異なるテナントに移動するハイパバイザ２００に併せてＬＡＮスイッチ１２１、１２２のＶＬＡＮの設定変更のプランを変更プラン生成モジュール４０５が生成する。この処理については、図３１で詳述する。

次に、ステップＳ３５では、変更プラン生成モジュール４０５が、ＳＡＮスイッチ１４１、１４２の設定を変更するプランを生成する。これは、上述のように、テナント毎にゾーンの構成が異なるためで、異なるテナントに移動するハイパバイザ２００に併せてＳＡＮスイッチ１４１、１４２のゾーニングの設定変更のプランを変更プラン生成モジュール４０５が生成する。この処理については、図３２で詳述する。

次に、ステップＳ３６では、変更プラン生成モジュール４０５が、ストレージ１５０の設定を変更するプランを生成する。これは、上述のように、ＳＡＮスイッチ１４１、１４２の設定に応じてストレージ１５０の設定を変更するプランを生成する。この処理については、図３３で詳述する。

図２８は、図２７のステップＳ３１で行われる移動元のテナントと移動先のテナントの決定の処理の一例を示すフローチャートである。

ステップＳ４１では、変更プラン生成モジュール４０５が、上記判定モジュール４０４が求めた評価値ベクトルＷＬＶｔのいずれかの要素が閾値ベクトルＷＬＴｈの対応する要素の値を超えたテナントをホストの移動先テナントＴｍｏｖｅｔｏとして決定する。

ステップＳ４２では、変更プラン生成モジュール４０５が、上記判定モジュール４０４が求めた評価値ベクトルＷＬＶｔのうち、移動先テナント以外のテナントの評価値ベクトルＷＬＶｔの長さが最も小さいテナントを、移動対象ホストの移動元テナントＴｍｏｖｅｆｒｏｍとして決定する。換言すれば複数のテナントのうち最も負荷の小さいテナントを移動元テナントＴｍｏｖｅｆｒｏｍとする。

ステップＳ４３では、変更プラン生成モジュール４０５が、移動元テナントに属するすべてのホストのうち、最も負荷（評価値ベクトルＷＬＶｔ）の低いホストを移動対象ホストＨｍｏｖｅとする。

以上の処理によって、変更プラン生成モジュール４０５がテナント間を移動するホストを特定する。

図２９は、図２７のステップＳ３２で行われるリソースグループの変更プランの生成処理の一例を示すフローチャートである。

ステップＳ５１では、変更プラン生成モジュール４０５が、テナントデータベース４０８のリソースグループテーブル５１０を、移動元テナント名Ｔｍｏｖｅｆｒｏｍで検索してリソースグループＩＤを取得する。取得したリソースグループＩＤが、移動対象ホストＨｍｏｖｅが現在属する変更前リソースグループＲｆｒｏｍを表す。

ステップＳ５２では、変更プラン生成モジュール４０５が、テナントデータベース４０８のリソースグループテーブル５１０を移動先テナント名Ｔｍｏｖｅｔｏで検索してリソースグループＩＤを取得する。このリソースグループＩＤは移動対象ホストＨｍｏｖｅが変更後に所属するリソースグループＲｔｏを表す。

ステップＳ５３では、変更プラン生成モジュール４０５は、リソースグループＩＤの組（Ｒｆｒｏｍ、Ｒｔｏ）をリソースグループの変更プランとして生成する。

以上の処理によって、変更プラン生成モジュール４０５がホストを移動させるリソースグループの変更プランを生成する。

図３０は、図２７のステップＳ３３で行われる仮想ネットワークの変更プランの生成処理の一例を示すフローチャートである。

まず、ステップＳ６１では、変更プラン生成モジュール４０５が、テナントデータベース４０８の仮想ネットワークテーブル５３０（図９を移動元テナント名Ｔｍｏｖｅｆｒｏｍで検索して、仮想ネットワークの設定（仮想ネットワーク名、ＮＩＣ＿ＩＤ、ＶＬＡＮ＿ＩＤ）を取得する。変更プラン生成モジュール４０５が取得した仮想ネットワークの設定が、移動対象ホストＨｍｏｖｅの仮想ネットワーク設定ＶＮｆｒｏｍとなる。

次に、ステップＳ６２では、変更プラン生成モジュール４０５がテナントデータベース４０８の仮想ネットワークテーブル５３０を移動先テナント名Ｔｍｏｖｅｔｏで検索して、仮想ネットワークの設定（仮想ネットワーク名、ＮＩＣ＿ＩＤ、ＶＬＡＮ＿ＩＤ）を取得する。取得した仮想ネットワークの設定が、移動対象ホストＨｍｏｖｅの変更後の仮想ネットワーク設定ＶＮｔｏとなる。

ステップＳ６３では、変更プラン生成モジュール４０５は、上記ステップＳ６１、Ｓ６２で求めた仮想ネットワーク設定ＶＮｆｒｏｍと仮想ネットワーク設定ＶＮｔｏの組を仮想ネットワークの変更プランとして生成する。

以上の処理によって、変更プラン生成モジュール４０５がホストを移動させた前後の仮想ネットワークの変更プランを生成する。

図３１は、図２７のステップＳ３４で行われるＬＡＮスイッチの変更プランの生成処理の一例を示すフローチャートである。

まず、ステップＳ７１では、変更プラン生成モジュール４０５が、テナントデータベース４０８の仮想ネットワークテーブル５３０を参照し、移動先テナントのＮＩＣ＿ＩＤとＶＬＡＮ＿ＩＤの組みをすべて取得する。そして変更プラン生成モジュール４０５は、取得した組み合わせを移動先ＶＬＡＮ設定ＶＬｔｏとする。

ステップＳ７２では、変更プラン生成モジュール４０５が、構成データベース４０９のホスト−ＮＩＣテーブル６００を参照し、移動対象ホストＨｍｏｖｅのすべてのＮＩＣのＭＡＣアドレスを取得する。

ステップＳ７３では、変更プラン生成モジュール４０５が、構成データベース４０９のＬＡＮスイッチ管理情報６２０を参照し、ステップＳ７２で求めたＭＡＣアドレスに一致するＬＡＮスイッチＩＤと、ポート番号と、ＶＬＡＮＩＤを取得する。そして、ステップＳ７１で取得したＮＩＣ＿ＩＤに対応するスイッチＩＤ，ポート番号、ＶＬＡＮＩＤ，ＮＩＣ＿ＩＤの４組の値を求める。変更プラン生成モジュール４０５は、このＮＩＣ＿ＩＤに対応する４組の値を変更前ＬＡＮスイッチポート設定ＬＰｆｒｏｍとする。

次に、ステップＳ７４では、変更前ＬＡＮスイッチポート設定ＬｐｆｒｏｍのＶＬＡＮ＿ＩＤの部分を、先に求めた移動先ＶＬＡＮ設定ＶＬｔｏを利用して書き換える。そして、得られた新しい４組を移動先ＬＡＮスイッチポート設定Ｌｐｔｏとする。

そして、ステップＳ７５では、変更プラン生成モジュール４０５は、上記求めた変更前ＬＡＮスイッチポート設定ＬＰｆｒｏｍと、移動先ＬＡＮスイッチポート設定Ｌｐｔｏの組をＬＡＮスイッチ変更プランとする。

以上の処理によって、変更プラン生成モジュール４０５がホストを移動させた前後のＬＡＮスイッチの変更プランを生成する。

例えば、テナントＡから移動対象ホストＨｏｓｔ０１をテナントＢに割当変更するときには、ＬＰｆｒｏｍ：｛（０，０，（１，２），０），（０，１，−，１）｝となり、ＬＰｔｏ：｛（０，０，（３），０），（０，１，（４，５），１）｝となる。

図３２は、図２７のステップＳ３５で行われるＳＡＮスイッチの変更プランの生成処理の一例を示すフローチャートである。

ステップＳ８１では、変更プラン生成モジュール４０５が、構成データベース４０９のホスト−ＨＢＡテーブル６１０を参照し、移動対象ホストＨｍｏｖｅのＨＢＡのＷＷＮを取得する。

ステップＳ８２では、変更プラン生成モジュール４０５が、構成データベース４０９のＳＡＮスイッチ管理情報６３０を参照し、移動対象ホストＨｍｏｖｅのＨＢＡのＷＷＮと一致する行のＳＡＮスイッチＩＤ、ドメインＩＤ、ポート番号を取得する。これは移動対象ホストＨｍｏｖｅが接続しているＳＡＮポートの情報ＳＰＨを示す。

次に、ステップＳ８３では、変更プラン生成モジュール４０５が、構成データベース４０９のＳＡＮゾーンテーブル６４０を参照し、上記ＳＡＮポートの情報ＳＰＨが属するゾーンＩＤを取得する。ＳＰＨとゾーンＩＤの組は移動対象ホストＨｍｏｖｅが接続しているＳＡＮポートの移動前ゾーン情報Ｚｆｒｏｍを表す。

ステップＳ８４では、変更プラン生成モジュール４０５が、テナントデータベース４０８のＬＵテーブル５４０を参照し、移動先テナントＴｍｏｖｅｔｏの各ＬＵのゾーン（変更後ゾーン）を取得する。

ステップＳ８５では、変更プラン生成モジュール４０５が、ＳＡＮポートの移動前ゾーン情報Ｚｆｒｏｍの各エントリの移動前ゾーンを変更後のゾーンに変更し、移動後ゾーン情報Ｚｔｏとし、（Ｚｆｒｏｍ，Ｚｔｏ）をＳＡＮスイッチ変更プランとする。

以上の処理によって、変更プラン生成モジュール４０５がホストを移動させた前後のＳＡＮスイッチの変更プランを生成する。

図３３は、図２７のステップＳ３６で行われるストレージ１５０の変更プランの生成処理の一例を示すフローチャートである。

ステップＳ９１では、変更プラン生成モジュール４０５が、構成データベース４０９のホスト−ＨＢＡテーブル６１０を参照し、移動対象ホストＨｍｏｖｅのＨＢＡのＷＷＮを取得する。

ステップＳ９２では、変更プラン生成モジュール４０５が、構成データベース４０９のストレージ−ホスト管理テーブル６６０を参照して移動対象ホストＨｍｏｖｅのＨＢＡのＷＷＮに該当する行を取得する。取得した行のＬＵＮが変更前ストレージ設定ＳＣｆｒｏｍとなる。

ステップＳ９３では、変更プラン生成モジュール４０５が、テナントデータベース４０８のＬＵテーブル５４０を参照し、移動先テナントＴｍｏｖｅｔｏのＳｔｏｒａｇｅＩＤ，ＰＯＲＴ，ＬＵＮを取得する。変更プラン生成モジュール４０５が取得したＳｔｏｒａｇｅＩＤ、ＰＯＲＴ、ＬＵＮを移動対象ホストＨｍｏｖｅのＨＢＡのＷＷＮと組にして変更後ストレージ設定ＳＣｔｏとする。

ステップＳ９４では、変更プラン生成モジュール４０５が、上記の変更前ストレージ設定ＳＣｆｒｏｍと変更後ストレージ設定ＳＣｔｏの組（ＳＣｆｒｏｍ、ＳＣと）をストレージ変更プランとする。

変更プラン生成モジュール４０５は、上記図２８〜図３３の処理で生成した各変更プランをＵＩモジュール４１０に出力する。ＵＩモジュール４１０は、変更プラン生成モジュール４０５が生成した移動対象ホストＨｍｏｖｅの移動前後のプランを管理クライアント１８０に送信する。管理クライアント１８０は移動対象ホストＨｍｏｖｅの移動前後のプランを受信して表示装置（図示省略）に図３５に示す通知画面を出力する。

図３５は、変更プラン生成モジュール４０５が生成する通知画面４２０の一例を示す画面イメージである。通知画面４２０は、テナント単位の負荷（例えば、ＣＰＵ負荷）の推移をグラフにて表示する負荷モニタ４２１の領域と、管理者に対して注意を喚起する文章等を表示するアラート４２２の領域と、アラートに対する対処案を提示する変更プラン４２３の領域と、から構成される。

変更プラン４２３の領域には、変更プラン生成モジュール４０５が生成した変更プランの要旨が表示され、さらに詳細を表示するための設定変更詳細表示ボタン４２４，４２５が表示される。設定変更詳細表示ボタン４２４を図示しない入力装置でクリックした場合、図３６で示すような詳細プランの表示画面４３０に切り替わる。

そして、変更プラン４２３の領域には、変更プランを選択するためのチェックボックス４２７、４２８と、選択した変更プランを実行するための実行ボタン４２６が表示される。管理クライアント１８０の図示しない入力装置で実行ボタン４２６をクリックすると、管理クライアント１８０は運用管理システム１７０に対して変更開始の指令を送信する。このとき、管理クライアント１８０は変更プラン生成モジュール４０５が複数の変更プランを提示している場合には、管理者などが選択したチェックボックス４２７、４２８に応じた変更プランの識別子を運用管理システム１７０に送信する。運用管理システム１７０の変更モジュール４０６は、受信した識別子に対応する変更プランを実行することができる。

なお、ＵＩモジュール４１０は、管理クライアント１８０からの要求に応じて通知画面４２０を提供することができ、アラート４２２の領域に表示する情報がない場合では、負荷モニタ４２１の領域に各テナントの負荷をホスト稼動情報テーブル５５０から取得して表示する。

また、変更プラン生成モジュール４０５は、図３５の変更プラン４２３の領域のＰｌａｎ１、Ｐｌａｎ２で示すように、変更ポリシの異なる複数のプランを生成して出力することができる。

図３６は、変更プラン生成モジュール４０５が生成した移動対象ホストＨｍｏｖｅの移動前後の詳細なプランの表示画面４３０の画面イメージである。詳細プランの表示画面４３０では、変更対象のリソースグループと、仮想ネットワーク（図中仮想スイッチ）と、ＬＡＮスイッチ、ＳＡＮスイッチ、ストレージのそれぞれについて、変更前の設定の詳細と、変更後の設定の詳細が表示される。図示の例では、Ｈｏｓｔ０１（図３のハイパバイザ＃１）をテナントＡ（ＲＧＡ）からテナントＢへ移動する場合の設定変更の内容を示す。

図３４は、変更モジュール４０６で行われる処理の一例を示すフローチャートである。この処理は、図３５の通知画面４２０で、実行ボタン４２６がクリックされて変更プランを適用する通知を運用管理システム１７０が管理クライアント１８０から受信したときに実行される。

ステップＳ１０１で、変更モジュール４０６は、ＶＭ管理モジュール４１１に対して移動対象ホストＨｍｏｖｅ上で動作するすべての仮想計算機２１１を他のサーバ１３０へ移動するよう指令する。ＶＭ管理モジュール４１１は、上述したＤＲＳやＨｙｐｅｒ−Ｖ Ｐｒｏなど周知の技術を適用することで、移動対象ホストＨｍｏｖｅ上で動作するすべての仮想計算機２１１を他のサーバ１３０へ移動させる。

ステップＳ１０２では、変更モジュール４０６がＶＭ管理モジュール４１１に対して仮想計算機２１１の移動差が完了した移動対象ホストＨｍｏｖｅを、移動元リソースグループＲｇｆｒｏｍから取り除く。なお、移動元リソースグループＲｇｆｒｏｍは、上記ステップＳ４２で決定した移動元テナント名Ｔｍｏｖｅｆｒｏｍがリソースグループテーブル５１０で対応するリソースグループＩＤである。つまり、ＶＭ管理モジュール４１１は、図１４に示したテナント−ホストテーブル５８０から移動対象ホストＨｍｏｖｅのエントリを削除する。

ステップＳ１０３では、変更モジュール４０６が上記ステップＳ８５で設定した移動後ゾーン情報Ｚｔｏから変更対象のＳＡＮスイッチＩＤを取得し、当該ＳＡＮスイッチＩＤを有するＳＡＮスイッチ１４１のコマンドインタフェースにアクセスし、変更対象ＳＡＮスイッチのポートのゾーン設定を移動後ゾーン情報Ｚｔｏに変更する。

ステップＳ１０４では、変更モジュール４０６が、上記ステップＳ９２で設定した変更前ストレージ設定ＳＣｆｒｏｍから変更前ストレージ設定移動前ストレージＩＤとＰＯＲＴを特定し、当該ストレージＩＤのストレージ１５０のコマンドインタフェースにアクセスし、当該ストレージ１５０に設定されている変更前ストレージ設定ＳＣｆｒｏｍと同等のエントリを削除する。

また、上変更モジュール４０６は、記ステップＳ９３で設定した変更後ストレージ設定ＳＣｔｏから移動後ストレージＩＤとＰＯＲＴを特定する。そして変更モジュール４０６は、特定したストレージＩＤのストレージ１５０のコマンドインタフェースにアクセスし、当該ストレージ１５０に変更後ストレージ設定ＳＣｔｏと同等の設定を追加する。

なお、上記ステップＳ１０３、Ｓ１０４でストレージ１５０とＳＡＮスイッチ１４１，１４２の設定が完了した段階で、必要に応じて移動対象ホストＨｍｏｖｅを再起動するようにしても良い。

ステップＳ１０５では、変更モジュール４０６が上記ステップＳ７４で設定した移動先ＬＡＮスイッチポート設定Ｌｐｔｏから、変更対象ＬＡＮスイッチＩＤを取得する。そして、変更モジュール４０６は当該ＬＡＮスイッチＩＤのＬＡＮスイッチ１２１のコマンドインタフェースにアクセスし、ＬＡＮスイッチ１２１のポートのＶＬＡＮ設定を移動先ＬＡＮスイッチポート設定ＬＰｔｏに変更する。

ステップＳ１０６では、変更モジュール４０６が移動対象ホストＨｍｏｖｅに対して仮想スイッチ（仮想ネットワーク）の設定を、上記ステップＳ６２で設定した変更後の仮想ネットワーク設定ＶＮｔｏに変更するよう指令する。これにより、移動対象ホストＨｍｏｖｅのハイパバイザ２００は、内部の仮想ネットワークの設定を変更後の仮想ネットワーク設定ＶＮｔｏに変更する。

次に、ステップＳ１０７では、変更モジュール４０６が、ＶＭ管理モジュール４１１に対して移動対象ホストＨｍｏｖｅを移動先リソースグループＲＧｔｏに登録するよう指令する。なお、移動先リソースグループＲｇｔｏは、上記ステップＳ４１で決定した移動先テナント名Ｔｍｏｖｅｔｏがリソースグループテーブル５１０で対応するリソースグループＩＤである。つまり、ＶＭ管理モジュール４１１は、図１４のテナント−ホストテーブル５８０に、移動対象ホストＨｍｏｖｅのＩＤを移動先テナント名ＴｍｏｖｅｔｏのテナントＩＤに対応させて新たなエントリを追加する。

ステップＳ１０８では、変更モジュール４０６がＶＭ管理モジュール４１１に対して移動先リソースグループＲＧｔｏ内にて仮想計算機２１１をマイグレーションして負荷を平準化するように指令する。なお、ＶＭ管理モジュール４１１は、上述したＤＲＳやＨｙｐｅｒ−Ｖ Ｐｒｏなど周知の技術を適用することで、移動対象ホストＨｍｏｖｅを加えたリソースグループで仮想計算機２１１の負荷を平準化させる。

以上の処理によって、複数のテナントに計算機資源を割り当てて仮想計算機２１１を稼動させる仮想計算機システムで、ひとつのテナントの負荷の評価値が閾値を超えて増大すると、運用管理システム１７０は、負荷の評価値の低いテナントからホストを、負荷の評価値が閾値を超えたテナントに移動させる。

図３７は、変更モジュール４０６が生成する進捗状況表示画面４４０である。変更モジュール４０６は、管理クライアント１８０から変更開始の指令を受けた後、上記図３４で示した処理の進捗状況を通知するため進捗状況表示画面４４０を生成してＵＩモジュール４１０を介して管理クライアント１８０の表示装置（図示省略）に出力する。

進捗状況表示画面４４０は、処理の順序を示す「＃」と、処理の内容を示す「処理」と、処理の状態を示す「Ｓｔａｔｕｓ」とから一行の表示領域が構成される。各処理が完了すると「Ｓｔａｔｕｓ」に「完了」が表示され、管理クライアント１８０を操作する管理社は、サーバ１３０及びハイパバイザ２００のテナント間の移動を処理の順序を追って確認することができる。

また、変更モジュール４０６は、移動対象ホストＨｍｏｖｅの移動処理中に障害または不具合が発生した場合には、進捗状況表示画面４４０の該当する「処理」の「Ｓｔａｔｕｓ」に障害または不具合の発生を通知するようにしてもよい。

図３８〜図４３は、上記図３４の処理の一例を示す図である。図３８〜図４３では、リソースグループＩＤ＝ＲＧＡのテナントＡのホストＨＯＳＴ０１を移動対象ホストＨｍｏｖｅとし、リソースグループＩＤ＝ＲＧＢのテナントＢに移動させる例を示す。この例では、運用管理システム１７０がリソースグループＩＤ＝ＲＧＢのテナントＢの評価値ベクトルＷＬＶｔが閾値ベクトルを超えて負荷が増大したと判定し、評価値ベクトルＷＬＶｔの最も低いホストＨＯＳＴ０１を移動対象ホストＨｍｏｖｅとして決定した場合を示す。

図３８は、上記図３４のステップＳ１０１、Ｓ１０２に対応し、移動対象ホストＨｍｏｖｅから仮想計算機を移動する処理を示すブロック図である。まず、変更モジュール４０６は、ＶＭ管理モジュール４１１に移動対象ホストＨｍｏｖｅ（ＨＯＳＴ０１）上の仮想計算機２１１（図中ＶＭ）を同じテナントＡ（リソースグループＡ）内の他のホストＨＯＳＴ０２，０３に移動させる。この際、ＶＭ管理モジュール４１１は、上述したＤＲＳ等の技術を適用して、移動する仮想計算機２１１を同一リソースグループＡ内のホストＨＯＳＴ０２，０３に均等に配分してテナントＡ内の負荷の平準化を図る。

次に、変更モジュール４０６は、ＶＭ管理モジュール４１１に指令してテナントＡ（リソースグループＡ＝移動前リソースグループ）から移動対象ホストＨｍｏｖｅ（ＨＯＳＴ０１）を削除する。

図３９は、上記図３４のステップＳ１０３に対応するブロック図である。変更モジュール４０６が移動対象ホストＨｍｏｖｅ（ＨＯＳＴ０１）のＨＢＡに接続されたＳＡＮスイッチ１４１の設定を移動後ゾーン情報Ｚｔｏに変更する。

図４０は、上記図３４のステップＳ１０４に対応し、変更モジュール４０６が移動対象ホストＨｍｏｖｅ（ＨＯＳＴ０１）のＨＢＡがアクセスするストレージ１５０−１の設定を変更して変更後ストレージ設定ＳＣｔｏと同等にする。この例では、移動対象ホストＨｍｏｖｅ（ＨＯＳＴ０１）のＨＢＡのＷＷＮを、変更後のポートＳ２に対応付ける。

図４１は、上記図３４のステップＳ１０５、Ｓ１０６に対応し、変更モジュール４０６が移動対象ホストＨｍｏｖｅ（ＨＯＳＴ０１）のネットワークインターフェースに接続されたＬＡＮスイッチ１２１のポートのＶＬＡＮの設定を変更して変更後ストレージ設定ＳＣｔｏと同等にする。

その後、変更モジュール４０６が移動対象ホストＨｍｏｖｅのハイパバイザ２００に対して仮想スイッチ（仮想ネットワーク）の設定を、上記ステップＳ６２で設定した変更後の仮想ネットワーク設定ＶＮｔｏに変更するよう指令し、ホストＨＯＳＴ０１のハイパバイザ２００（＃１）は、内部の仮想ネットワークの設定を変更後の仮想ネットワーク設定ＶＮｔｏに変更する。

図４２は、上記図３４のステップＳ１０７に対応し、変更モジュール４０６がＶＭ管理モジュール４１１に移動対象ホストＨｍｏｖｅを移動先リソースグループＲＧｔｏに登録するよう指令する。ＶＭ管理モジュール４１１は、構成管理モジュール４０２を介してテナント−ホストテーブル５８０を更新する。テナント−ホストテーブル５８０には、テナントＩＤ＝Ｂ、ＨＯＳＴＩＤ＝ＨＯＳＴ０１のエントリが追加される。これにより、テナントＢに移動対象ホストＨｍｏｖｅとしてＨＯＳＴ０１が加えられる。

図４３は、上記図３４のステップＳ１０８に対応し、変更モジュール４０６がＶＭ管理モジュール４１１に対して移動先リソースグループＲＧｔｏ内にて仮想計算機２１１をマイグレーションして負荷を平準化するように指令する。図示の例では、ＶＭ管理モジュール４１１はテナントＢ内のホストＨＯＳＴ０４とホストＨＯＳＴ０５からそれぞれひとつの仮想計算機２１１を、新たに加えたホストＨＯＳＴ０１に移動させる。

以上のように本発明の第１の実施形態によれば、テナント間の負荷の不均衡が発生した場合、負荷の低いテナント（移動元）から適切な量のホストを取り除き、負荷の高いテナント（移動先）に当該ホストを割り当て直すことが可能となる。ホストを割り当て直す際に、割り当て直す前のテナントと割り当て後のテナントに関連するＬＡＮスイッチ１２１、１２２、ＳＡＮスイッチ１４１、１４２、ハイパバイザ２００の仮想スイッチ（仮想ネットワーク及びストレージ１５０のＬＵの設定を連動して変更するので、テナント固有の設定を引き継いで移動対象のホストを確実に動作させることが可能となる。

なお、上記実施形態では、仮想計算機２１１を提供する仮想化部としてハイパバイザ２００を採用した例を示したが、ＶＭＭ（Virtual Machine Monitor）を採用しても良い。

＜第２実施形態＞
図４４は、第２の実施形態を示し、仮想計算機を提供する計算機システムの一例を示すブロック図である。前記第１の実施形態と異なる点は、テナントＡとテナントＢが物理計算機であるサーバ１３０−４を共有する点である。その他の構成は前記第１の実施形態と同様であるので、説明は省略する。

図４５は、複数のテナント（テナントＡ、Ｂ）で共有されるサーバ（＃４）１３０−４の詳細なブロック図である。ハードウェア２０１は前記第１実施形態と同様であるが、仮想化部が２段階になっている点が前記第１実施形態と相違する。

第１の仮想化部としてのハイパバイザ（親ハイパバイザ）２００Ａは、複数の論理区画（ＬＰＡＲ１、２）を生成する。親ハイパバイザは、サーバ（＃４）１３０−４のプロセッサ２２１、２２２、メモリ２２３、Ｉ／Ｏ２２５−１〜２２６−２を運用管理システム１７０から指定された比率で分割し、各論理区画に割り当てる。

そして、各論理区画内で第２の仮想化部としての子ハイパバイザ２５０−１、２５０−２が稼動する。子ハイパバイザ（＃１）２５０−１では２つの仮想計算機２１１が提供されＶＭ１及びＶＭ２として稼動する。子ハイパバイザ（＃２）２５０−２では２つの仮想計算機２１１が提供されＶＭ３及びＶＭ４として稼動する。各仮想計算機２１１では、前記第１実施形態と同様にＯＳ２０２とアプリケーション２０３が実行される。

運用管理システム１７０は、子ハイパバイザ２５０−１をテナントＡに割り当て、子ハイパバイザ２５０−２をテナントＢに割り当てる例を示す。運用管理システム１７０は、子ハイパバイザ２５０−１の識別子をテナントＡに関連づけて図１４に示したテナント−ホストテーブル５８０に格納し、子ハイパバイザ２５０−２の識別子をテナントＢに関連づけてテナント−ホストテーブル５８０に格納する。その他のテーブルなどについても同様であり、子ハイパバイザ２５０−１、２５０−２を前記第１実施形態のハイパバイザ２００と同様に扱う。

また、子ハイパバイザ２５０−１は、テナントＡのＶＬＡＮに対応する仮想スイッチ（または仮想ネットワーク）を構成し、子ハイパバイザ２５０−２は、テナントＢのＶＬＡＮに対応する仮想スイッチを構成する。

次に、図４６は、図２５のステップＳ１８で行われる変更プラン生成モジュール４０５の処理の一例を示すフローチャートである。このフローチャートは、前記第１実施形態に示した図２７のステップＳ３１〜Ｓ３６の処理にステップＳ１１０の処理を加えたものである。

ステップＳ３１〜Ｓ３６では、前記第１の実施形態と同様に、変更プラン生成モジュール４０５が、評価値ベクトルＷＬＶｔに基づいて移動対象ホストＨｍｏｖｅと移動元テナントＴｍｏｖｅｆｒｏｍと移動先テナントＴｍｏｖｅｔｏを決定する。そして、変更プラン生成モジュール４０５は、移動先テナントＴｍｏｖｅｔｏに対応する各変更プラン（リソースグループ、仮想ネットワーク、ＬＡＮスイッチ、ＳＡＮスイッチ、ストレージの各変更プラン）を前記第１実施形態と同様に生成する。なお、移動対象ホストＨｍｏｖｅは、親ハイパバイザ２００Ａ上でリソースの割り当て比率が減少する子ハイパバイザとすればよい。

その後、変更プラン生成モジュール４０５は、ステップＳ１１０で親ハイパバイザ２００Ａが、各子ハイパバイザ（論理区画）２５０−１、２５０−２に対して割り当てるリソースの比率の変更プランを生成する。変更プラン生成モジュール４０５は、例えば、評価値ベクトルＷＬＶｔの比率に応じて、各論理区画に割り当てるリソースの比率を決定する。

前記第１実施形態では、サーバ１３０単位でテナント間を移動させるのに対し、本第２実施形態では、サーバ１３０単位に加えて、ひとつのサーバ１３０を所望の比率で分割することで、各テナントに割り当てるリソースの量を、細かく調整することが可能となる。

なお、テナントＡ、Ｂ間でのリソースの割り当て変更が、図４５のサーバ１３０−４のみで良い場合には、図４６の処理のうちステップＳ３２〜Ｓ３６を割愛してステップＳ３１とＳ１１０を実行すればよい。

次に、図４７は、変更モジュール４０６で行われる処理の一例を示すフローチャートである。このフローチャートは、前記第１実施形態に示した図３４のステップＳ１０１〜Ｓ１０８の処理にステップＳ１０７０の処理を加えたものである。ステップＳ１０１〜Ｓ１０７は前記第１の実施形態と同様に、移動対象ホストＨｍｏｖｅを移動元テナントから移動先テナントへ移動させるために各種リソースの設定を変更する。

移動対象ホストＨｍｏｖｅを移動先リソースグループに登録するステップＳ１０７の後、変更モジュール４０６は、ステップＳ１０７０で親ハイパバイザ２００Ａに指令して各論理区画に割り当てるリソースの比率を変更する。この比率は、図４６のステップＳ１１０で比率を用いる。

その後、変更モジュール４０６は前記第１の実施形態と同様に、リソースの比率を変更した論理区画へ仮想計算機２１１を再配置する。

図４８〜図５０は、上記図４７の処理の一例を示す図である。図４８〜図５０では、リソースグループＩＤ＝ＲＧＡのテナントＡのホストＨＯＳＴ０１を移動対象ホストＨｍｏｖｅとしてリソースの割り当て比率を減少させ、リソースグループＩＤ＝ＲＧＢのテナントＢのホストＨＯＳＴ０６にホストＨＯＳＴ０１から削減したリソースを割り当てる例を示す。

図４８は、移動対象ホストＨｍｏｖｅ（ＨＯＳＴ０１）上で稼動する仮想計算機２１１を同一テナント内で退避させる例を示すブロック図である。変更モジュール４０６は、ＨＯＳＴ０１の仮想計算機２１１をテナントＡ内の他のＨＯＳＴ０２、０３へ移動させる指令をＶＭ管理モジュール４１１に送信する。ＶＭ管理モジュール４１１は、前記第１実施形態と同様にしてテナントＡ内で負荷が平準化されるように仮想計算機２１１をホストＨＯＳＴ０２、０３に移動させる。

図４９は、親ハイパバイザ２００Ａが論理区画（子ハイパバイザＨＯＳＴ０１、ＨＯＳＴ０６）に割り当てるリソースの比率を変更する例を示すブロック図である。親ハイパバイザ２００Ａは、リソースの割り当て比率を減少する側のホストＨＯＳＴ０１上の仮想計算機２１１を退避させてから、ホストＨＯＳＴ０１のリソースを削減し、削減したリソースをホストＨＯＳＴ０６に加える。これによって、負荷が増大したテナントＢに新たなリソースが加えられる。一方、負荷の低かったテナントＡではホストＨＯＳＴ０１に割り当てるリソースの比率が削減される。なお、リソースの割り当て比率を変更した後、子ハイパバイザ２５０−１、２５０−１の種類によっては再起動を行う場合がある。

図５０は、親ハイパバイザ２００Ａが論理区画（子ハイパバイザＨＯＳＴ０１、ＨＯＳＴ０６）に割り当てるリソースの比率を変更した後に仮想計算機２１１を再配置するブロック図である。変更モジュール４０６は、ＶＭ管理モジュール４１１に対して、リソースの割り当て比率を変更したテナントＡのＨＯＳＴ０１とテナントＢのＨＯＳＴ０６に仮想計算機２１１を再配置する指令を送信し、各テナント内のホストの負荷を平準化させる。

以上のように本第２実施形態では、複数のテナントに跨るサーバ１３０では２段階の仮想化部によって、子ハイパバイザ２５０−１、２５０−２に割り当てるリソースの比率を細かく、かつ動的に変更して、テナント間の負荷の平準化を図ることができる。

また、上記第２の実施形態では、負荷の評価値が閾値を超えたテナントが他のテナントとサーバ１３０を共有する際に、子ハイパバイザ２５０−１と２５０−２に割り当てるリソースの比率を変更するようにしてもよい。

＜第３実施形態＞
図５１は、第３の実施形態を示し、変更モジュール４０６で行われる処理の一例を示すフローチャートである。図５１のフローチャートは、前記第１実施形態に示した図３４のステップＳ１０１〜Ｓ１０８の処理にステップＳ１０８０の処理を加えたものである。ステップＳ１０１〜Ｓ１０５は前記第１の実施形態と同様に、移動対象ホストＨｍｏｖｅを移動元テナントから移動先テナントへ移動させるために各種リソースの設定を変更する。

ＬＡＮスイッチ１２１、１２２の設定を変更した後、変更モジュール４０６は、ステップＳ１０８０で、移動対象ホストＨｍｏｖｅに移動先テナントＴｍｏｖｅｔｏで使用している仮想化部をインストールする。あるいは変更モジュール４０６は、移動対象ホストＨｍｏｖｅが読み込む仮想ディスクを仮想化部の種類に応じて切り替える。

その後、変更モジュール４０６は、前記第１実施形態と同様にステップＳ１０６以降の処理を行って、移動対象ホストＨｍｏｖｅに仮想計算機２１１を再配置させる。

本第３の実施形態によれば、テナントＡがＨｙｐｅｒ−Ｖ環境、テナントＢがＶｍｗａｒｅ環境のとき、移動対象ホストＨｍｏｖｅの仮想化部を移動先テナントＴｍｏｖｅｔｏに応じてインストールまたは仮想ディスクを切り替えることで、テナント毎の環境に対応することが可能となる。

＜第４実施形態＞
図５２は、第４の実施形態を示し、前記第１実施形態のテナントＡ、Ｂが利用するサーバ１３０を異なるラックに収容した例を示し、ラック０、１をＬＡＮスイッチ１１１０で接続したもので、前記第１実施形態と同一の装置には同一の符号を付して重複した説明を省略する。テナントＡ（１９１）は、ラック０に収容された計算機システムを利用し、テナントＢ（１９２）は、ラック１に収容された計算機システムを利用する。

ラック０には、サーバ１３０−１〜１３０−３、ＬＡＮスイッチ１２１，ＳＡＮスイッチ１４１、ストレージ１５０−１が収容される。ラック１には、サーバ１３０−４〜１３０−６、ＬＡＮスイッチ１２２，ＳＡＮスイッチ１４２、ストレージ１５０−２が収容される。ＬＡＮスイッチ１２１とＬＡＮスイッチ１２２はＬＡＮスイッチ１１１０に接続される。また、各装置は管理ＬＡＮスイッチ１６０に接続され、運用管理システム１７０によって管理される。運用管理システム１７０の構成は前記第１実施形態と同様であり、変更プラン生成モジュール４０５の処理の一部が前記第１実施形態と相違する。なお、ＳＡＮスイッチ１４１、１４２はラック０、１間で接続されている。

図５３は、前記第１実施形態に示した図２７のステップＳ３４で行われるＬＡＮスイッチに関する変更プランの生成処理の一例を示すフローチャートである。このフローチャートは、前記第１実施形態の図３１のステップＳ７４とステップＳ７５の間に、新たなステップＳ１１００〜Ｓ１１０２を加えたものである。

ステップＳ７１〜Ｓ７４では、前記第１実施形態の図３１と同様に、変更プラン生成モジュール４０５が、移動先ＶＬＡＮ設定Ｖｔｏ、変更前ＬＡＮスイッチポート設定ＬＰｆｒｏｍ、移動先ＬＡＮスイッチポート設定ＬＰｔｏを演算する。

ステップＳ１１００では、変更プラン生成モジュール４０５が、構成データベース４０９のテナント−ホストテーブル５５０を参照し、移動先テナントのホストの一覧を取得する。次に、変更プラン生成モジュール４０５は、構成データベース４０９のホスト−ＮＩＣテーブル６００を参照し、移動先テナントの各ホストのＭＡＣアドレスを取得する。そして、変更プラン生成モジュール４０５は、構成データベース４０９のＬＡＮスイッチ管理情報６２０を参照し、移動先ホストが接続されているＶＬＡＮ＿ＩＤとポートを取得する。

次に、ステップＳ１１０１では、変更プラン生成モジュール４０５が、各ＬＡＮスイッチ１２１の接続トポロジを利用して、移動対象ホストが接続されているＬＡＮスイッチ１２１と移動先テナントが接続されているＬＡＮスイッチ１２２間をつなぐＶＬＡＮのトランクポートを特定する。

次に、ステップＳ１１０２では、変更プラン生成モジュール４０５が、ステップＳ１１０１で特定したトランクポートのスイッチＩＤとポート番号を、ステップＳ７４で生成した移動先ＬＡＮスイッチポート設定ＬＰｔｏに追加する。

そして、ステップＳ７５では、変更プラン生成モジュール４０５が上記変更前ＬＡＮスイッチポート設定ＬＰｆｒｏｍ、移動先ＬＡＮスイッチポート設定ＬＰｔｏをスイッチ変更プランとする。

上記の処理によって、複数のＶＬＡＮタグを通過させるトランクポートのスイッチＩＤとポート番号が移動先ＬＡＮスイッチポート設定ＬＰｔｏに加えられる。これにより、複数のＬＡＮスイッチを跨ぐＶＬＡＮを構成できる。

図５４は、テナントＡ（リソースグループＩＤ＝ＲＧＡ）のホストＨＯＳＴ０１をテナントＢ（リソースグループＩＤ＝ＲＧＢ）へ移動する前の計算機システムのブロック図である。ホストＨＯＳＴ０１のネットワークインターフェースが接続されたＬＡＮスイッチ１２１と、テナントＢのサーバ１３０−４〜１３０−６（ＨＯＳＴ０３〜ＨＯＳＴ０６）を収装したラック１のＬＡＮスイッチ１２２は、ＬＡＮスイッチ１１１０を介して接続されるが、テナントＡのＶＬＡＮＡと、テナントＢのＶＬＡＮＢは独立している。

図５５は、テナントＡのホストＨＯＳＴ０１をテナントＢへ移動した後の計算機システムのブロック図である。上記図５３の処理を実行することで、テナントＢのＶＬＡＮＢをＬＡＮスイッチ１２２、ＬＡＮスイッチ１１１０とＬＡＮスイッチ１２１のホストＨＯＳＴ０１のポートを含める。これにより、移動対象ホストＨｍｏｖｅのホストＨＯＳＴ０１が接続するＬＡＮスイッチ１２１のポートを、移動先のＶＬＡＮＢに加えることができる。この後には、前記第１実施形態と同様にして、ホストＨＯＳＴ０１をテナントＢのリソースグループＢに加えて仮想計算機２１１のマイグレーションを行えばよい。

以上の処理によって、異なるラック間でホストＨＯＳＴ０１を移動させることが可能となりラック単位でテナントを割り当てた仮想計算機システムにおいても、テナント間の負荷の平準化を図ることができる。

＜第５実施形態＞
図５６〜図５９は、第５の実施形態を示す。第５の実施形態では、テナントＡ、Ｂに計算機資源を提供するデータセンタなどでは、計算機資源の種類毎に管理者が存在する場合に、計算機資源の種類毎に変更プラン画面を生成するようにしたものである。なお、その他の構成は前記第１実施形態と同様である。計算機資源の種類毎の管理者としては、サーバ管理者、ネットワーク管理者、ＳＡＮ管理者、ストレージ管理者などが存在する。

変更プラン生成モジュール４０５は、前記第１実施形態の図２７に示した処理によって構成変更のプランを生成し、ＵＩモジュール４１０を介して管理クライアント１８０に通知画面４２０を送信する。このとき、変更プラン生成モジュール４０５は、予め設定した計算機資源の種類毎に通知画面を生成し、管理クライアント１８０に送信する。

変更プラン生成モジュール４０５は、例えば、サーバ管理者に対しては図５６で示すようにリソース変更の通知画面４２３Ａを送信し、ネットワーク管理者については図５７で示すようにリソース変更の通知画面４２３Ｂを送信し、ＳＡＮ管理者については図５８に示す通知画面４２３Ｃを送信し、ストレージ管理者については図５９に示す通知画面４２３Ｄを送信する。なお、サーバ管理者、ネットワーク管理者、ＳＡＮ管理者、ストレージ管理者はそれぞれ専用の管理クライアント１８０を有していても良い。

図５６に示すサーバ管理者用の通知画面４２３Ａが、ハイパバイザ２００のリソースグループの変更と、ハイパバイザ２００のＶＬＡＮの設定の変更を併記したものである。サーバ管理者は、通知画面４２３Ａのサーバ（ハイパバイザ２００）の変更プランを承認する場合は、承認ボタン４５０を管理クライアント１８０の図示しない入力装置でクリックする。

図５７は、ネットワーク管理者用の通知画面４２３Ｂを示し、ＬＡＮスイッチ１２１、１２２のＶＬＡＮの設定の変更を表示したものである。ネットワーク管理者は、通知画面４２３Ｂの変更プランを承認する場合は、承認ボタン４５０を管理クライアント１８０の図示しない入力装置でクリックする。

図５８は、ＳＡＮ管理者用の通知画面４２３Ｃを示し、ＳＡＮスイッチ１４１，１４２のゾーン設定の変更を表示したものである。ＳＡＮ管理者は、通知画面４２３Ｃの変更プランを承認する場合は、承認ボタン４５０を管理クライアント１８０の図示しない入力装置でクリックする。

図５９は、Ｓストレージ管理者用の通知画面４２３Ｄを示し、ストレージ１５０の設定の変更を表示したものである。ＳＡＮ管理者は、通知画面４２３Ｄの変更プランを承認する場合は、承認ボタン４５０を管理クライアント１８０の図示しない入力装置でクリックする。

そして、変更プラン生成モジュール４０５は、全ての管理者から承認の通知を受信すると図３４の変更モジュール４０６を起動させて変更プランを実現する。なお、何れか一人の管理者が却下を通知した場合には、変更プラン生成モジュール４０５は処理を終了することができる。

＜まとめ＞
なお、上記各実施形態では、一つのテナントに対して一つのリソースグループを割り当てる例を示したが、一つのテナントに対して複数のリソースグループを割り当てるようにしてもよい。

また、上記各実施形態では、複数のテナントに対して計算機資源を割り当てて利用させる例を示したが、テナントに限定されるものではなく、複数の計算機資源の利用対象に複数の仮想計算機と物理計算機を割り当てて利用させる構成であればよく、例えば、複数の顧客を複数の（計算機）利用グループとして捉えてもよい。

また、上記各実施形態では、２つのテナント間でサーバ１３０を移動させる例を示したが、３つ以上のテナント間でサーバ１３０を移動させてもよい。

また、上記各実施形態では、運用管理システム１７０−１、１７０−２をそれぞれ異なる物理計算機で構成する例を示したが、各運用管理システム１７０−１、１７０−２を仮想計算機上で稼動させても良い。

また、上記各実施形態では、運用管理システム１７０が、テナント毎の計算機の負荷を評価値ベクトルを用いて演算したが、各テナントに割り当てたハイパバイザ２００が測定したプロセッサの負荷の測定値を用いてもよい。

また、上記各実施形態では、運用管理システム１７０が移動先テナントＴｍｏｖｅｔｏを決定する際に、評価値ベクトルＷＬＶｔのいずれかの要素が、閾値ベクトルＷＬＴｈの対応する要素の値を超えたテナントとした例を示したが、閾値ベクトルＷＬＴｈの対応する要素の値を超えたテナントが複数存在するときには、これら複数のテナントのうち評価値ベクトルＷＬＶｔが最も高いものを移動先テナントＴｍｏｖｅｔｏとすることができる。

また、上記各実施形態では、運用管理システム１７０が移動対象ホストＨｍｏｖｅを決定する際に、評価値ベクトルＷＬＶｔの長さが最も小さい移動元テナントＴｍｏｖｅｆｒｏｍから最も負荷の低いサーバ１３０を移動対象ホストＨｍｏｖｅとする例を示したが、移動先テナントＴｍｏｖｅｔｏ以外のテナントで、最も負荷の低いサーバ１３０（または、負荷が所定の閾値未満のサーバ１３０）を移動対象ホストＨｍｏｖｅとしてもよい。この場合、最も負荷の低いサーバが所属するテナントを移動元テナントＴｍｏｖｅｆｒｏｍとすればよい。

＜補足＞
プロセッサとメモリを備えた物理計算機と、
前記物理計算機のリソースを分割する第１の仮想化部と、前記分割された複数のリソース上で複数の仮想計算機をそれぞれ提供する第２の仮想化部と、
複数の前記物理計算機を接続するネットワークスイッチと
前記ネットワークスイッチに接続された管理計算機と、を備えて前記複数の物理計算機上で提供される複数の仮想計算機の制御方法であって、
前記管理計算機が、前記複数の仮想計算機を複数のグループに割り当てる第１の手順と、
前記管理計算機が、前記グループ単位の負荷の値を取得し、予め設定したしきい値と前記負荷の値を比較する第２の手順と、
前記管理計算機が、前記負荷の値が前記しきい値を超えたグループを第１のグループとして特定する第３の手順と、
前記管理計算機が、前記複数のグループのうち前記第１のグループと物理計算機を共有する第２のグループを選択する第４の手順と、
前記管理計算機が、前記第１のグループと第２のグループで共有された物理計算機の第１の仮想化部上で稼動する第２仮想化部を、前記第１のグループの第２仮想化部と、第２のグループの第２の仮想化部を特定する第５の手順と、
前記管理計算機が、前記第２のグループの第２の仮想化部が提供する仮想計算機を前記第２のグループ内の他の物理計算機へ移動させる第６の手順と、
前記管理計算機が、前記第１のグループと第２のグループで共有された物理計算機の第１の仮想化部に対して、前記第１のグループの第２仮想化部と前記第２のグループの第２の仮想化部に割り当てるリソースを変更する第７の手順と、
前記管理計算機が、前記第１のグループの第２仮想化部に前記第１のグループの仮想計算機を移動させる第８の手順と、
前記管理計算機が、前記第２のグループの第２仮想化部に前記第２のグループの仮想計算機を移動させる第９の手順と、
を含むことを特徴とする仮想計算機の制御方法。

以上のように、本発明は仮想計算機を複数の顧客で利用する仮想計算機システムに適用することができ、特に、仮想計算機を管理する管理計算機及び管理計算機のプログラムに適用することができる。

１００−１、２ クライアント
１１０ ネットワーク
１２１、１２２ ＬＡＮスイッチ
１３０−１〜１３０−６ サーバ
１４１、１４２ ＳＡＮスイッチ
１５０−１，１５０−２ ストレージ
１６０ 管理ＬＡＮスイッチ
１７０−１，１７０−２ 運用管理システム
１８０ 管理クライアント
４０１ テナント管理モジュール
４０２ 構成管理モジュール
４０３ 稼動管理モジュール
４０４ 判定モジュール
４０５ 変更プラン生成モジュール
４０６ 変更モジュール
４１０ ＵＩモジュール
４１１ ＶＭ管理モジュール

Claims (14)

1. プロセッサとメモリを備えた物理計算機と、
   前記物理計算機のリソースを分割して仮想計算機を提供する仮想化部と、
   複数の前記物理計算機を接続するネットワークスイッチと、
   前記ネットワークスイッチに接続された管理計算機と、を備えて前記複数の物理計算機上で提供される複数の仮想計算機の制御方法であって、
   前記管理計算機が、前記複数の仮想計算機を複数のグループに割り当てる第１の手順と、
   前記管理計算機が、前記グループ単位の負荷の値を取得し、予め設定したしきい値と前記負荷の値を比較する第２の手順と、
   前記管理計算機が、前記負荷の値が前記しきい値を超えたグループを第１のグループとして特定する第３の手順と、
   前記管理計算機が、前記複数のグループのうち前記第１のグループを除く第２のグループを選択する第４の手順と、
   前記管理計算機が、前記第２のグループに割り当てられた仮想計算機を実行する物理計算機のうち所定の物理計算機を移動対象計算機として特定する第５の手順と、
   前記管理計算機が、前記移動対象計算機で提供される仮想計算機を前記第２のグループ内の他の物理計算機へ移動させる第６の手順と、
   前記管理計算機が、前記移動対象計算機を前記第２のグループから削除する第７の手順と、
   前記管理計算機が、前記移動対象計算機の仮想化部の仮想ネットワークの設定を前記第１のグループに応じて変更するよう当該仮想化部に指令する第８の手順と、
   前記管理計算機が、前記移動対象計算機を第１のグループで稼動するように前記ネットワークスイッチの設定を変更する第９の手順と、
   前記管理計算機が、前記移動対象計算機を第１のグループに追加する第１０の手順と、
   前記管理計算機が、前記移動対象計算機に前記第１のグループの仮想計算機を稼動させる第１１の手順と、
   を含むことを特徴とする仮想計算機の制御方法。
2. 請求項１に記載の仮想計算機の制御方法であって、
   前記第１１の手順は、
   前記第１のグループの物理計算機の負荷を平準化するように前記仮想計算機を移動させることを特徴とする仮想計算機の制御方法。
3. 請求項２に記載の仮想計算機の制御方法であって、
   前記第１１の手順は、
   前記第２のグループの物理計算機の負荷を平準化するように前記仮想計算機を移動させることを特徴とする仮想計算機の制御方法。
4. 請求項１に記載の仮想計算機の制御方法であって、
   前記ネットワークスイッチは、前記複数の物理計算機とストレージを接続するＳＡＮスイッチをさらに含み、
   前記第９の手順は、
   前記管理計算機が、前記移動対象計算機を第１のグループで稼動するように前記ＳＡＮスイッチの設定を変更する手順をさらに含むことを特徴とする仮想計算機の制御方法。
5. 請求項１に記載の仮想計算機の制御方法であって、
   前記第２の手順は、
   前記グループ内の物理計算機ごとに、複数の種類の負荷の値を集計した評価値を求めて前記グループ単位の負荷の値とすることを特徴とする仮想計算機の制御方法。
6. 請求項１に記載の仮想計算機の制御方法であって、
   前記第４の手順は、
   前記第１のグループを除く複数のグループのうち、前記グループ単位の負荷の値が最も小さいグループを第２のグループとして選択することを特徴とする仮想計算機の制御方法。
7. 請求項１に記載の仮想計算機の制御方法であって、
   前記第５の手順は、
   前記第２のグループに割り当てられた仮想計算機を実行する物理計算機のうち負荷の最も低い物理計算機を移動対象計算機として特定することを特徴とする仮想計算機の制御方法。
8. プロセッサとメモリを備えた物理計算機と、前記物理計算機のリソースを分割して仮想計算機を提供する仮想化部と、複数の前記物理計算機を接続するネットワークスイッチと
   前記ネットワークスイッチに接続されて前記物理計算機と仮想計算機を管理する管理計算機であって、
   前記複数の仮想計算機を複数のグループに割り当てるグループ管理部と、
   前記グループ単位の負荷の値を取得する稼動管理部と、
   前記グループ単位の負荷の値と予め設定したしきい値とを比較して、前記負荷の値が前記しきい値を超えたグループを第１のグループとして特定する判定部と、
   前記複数のグループのうち前記第１のグループを除く第２のグループを選択し、当該第２のグループに割り当てられた仮想計算機を実行する物理計算機のうち所定の物理計算機を移動対象計算機として特定し、当該移動対象計算機を前記第２のグループから第１のグループへ移動させる変更部と、
   前記物理計算機の仮想化部に指令して前記仮想計算機を制御する仮想計算機管理部と、を備え、
   前記変更部は、
   前記移動対象計算機で提供される仮想計算機を前記第２のグループ内の他の物理計算機へ移動させる指令を前記仮想計算機管理部に出力し、前記移動対象計算機を前記第２のグループから削除し、前記移動対象計算機の仮想化部の仮想ネットワークの設定を前記第１のグループに応じて変更する指令を前記仮想計算機管理部に出力し、前記移動対象計算機を第１のグループで稼動するように前記ネットワークスイッチの設定を変更し、前記移動対象計算機を第１のグループに追加し、前記移動対象計算機に前記第１のグループの仮想計算機を稼動させる指令を前記仮想計算機管理部に出力することを特徴とする管理計算機。
9. 請求項８に記載の管理計算機であって、
   前記仮想計算機管理部は、
   前記第１のグループの物理計算機の負荷を平準化するように前記仮想計算機を移動させることを特徴とする管理計算機。
10. 請求項９に記載の管理計算機であって、
    前記仮想計算機管理部は、
    前記第２のグループの物理計算機の負荷を平準化するように前記仮想計算機を移動させることを特徴とする管理計算機。
11. 請求項８に記載の管理計算機であって、
    前記ネットワークスイッチは、前記複数の物理計算機とストレージを接続するＳＡＮスイッチをさらに含み、
    前記変更部は、
    前記移動対象計算機を第１のグループで稼動するように前記ＳＡＮスイッチの設定を変更することを特徴とする管理計算機。
12. 請求項８に記載の管理計算機であって、
    前記稼動管理部は、
    前記グループ内の物理計算機ごとに、複数の種類の負荷の値を集計した評価値を求めて前記グループ単位の負荷の値とすることを特徴とする管理計算機。
13. 請求項８に記載の管理計算機であって、
    前記変更部は、
    前記第１のグループを除く複数のグループのうち、前記グループ単位の負荷の値が最も小さいグループを第２のグループとして選択することを特徴とする管理計算機。
14. 請求項８に記載の管理計算機であって、
    前記変更部は、
    前記第２のグループに割り当てられた仮想計算機を実行する物理計算機のうち負荷の最も低い物理計算機を移動対象計算機として特定することを特徴とする管理計算機。

Images