JP6426532B2 - 仮想マシン運用支援システムおよび仮想マシン運用支援方法 - Google Patents

Description

本発明は、仮想マシン運用支援システムおよび仮想マシン運用支援方法に関するものであり、具体的には、仮想マシンにおける性能安定化を効率的に実現する技術に関する。

近年、情報システムにおいて仮想化技術の利用が一般的となっている。仮想化技術とは、サーバなどのコンピューティングリソースを抽象化する技術である。こうした仮想化技術を利用することで、１台の物理サーバ上で複数の抽象化されたコンピュータ（以下、仮想マシン）を稼働させ、少ない物理サーバ上で多数の仮想マシンを稼働させることが可能となる。この仮想化を適用することで、仮想マシンの集約効果によるコスト削減が期待できる。

しかし一方で、仮想マシンの集約率を上げすぎると、多数の仮想マシンで、１台の物理サーバ上のコンピューティングリソースを奪い合うことになり、リソース不足による性能劣化を引き起こす可能性がある。そのため、仮想化環境の運用管理においては、集約率向上によるコスト削減と性能安定性の確保をいかに両立させるかが重要な課題となる。

このような仮想化環境における性能安定性の確保と集約率向上の両立を目的とした技術として、例えば、複数の物理サーバから構成されるシステムにおいて、物理サーバ間で負荷に偏りが生じた場合に、ライブマイグレーション技術を用いて、ある物理サーバ上で稼働する仮想サーバを他の物理サーバへと移動させる技術（特許文献１参照）などが提案されている。これにより、負荷が平準化され、性能劣化発生のリスクが軽減するとされている。

ＵＳ８０９５９２９

上述した従来技術は、仮想サーバの移動先である物理サーバを、移動検討時点での負荷情報に基づき決定する構成となっている。こうした構成の場合、移動検討時点での負荷平準化を図ることは確かに可能であるが、該当仮想マシン移動済みの物理サーバにて負荷上昇が生じる事態については想定されていない。そうした事態が生じれば、当初の負荷平準化、すなわちライブマイグレーションの実行にも関わらず、あらためてライブマイグレーションを再実行することが必要となる。

ライブマイグレーションの実行は、ＣＰＵやネットワーク帯域などのリソースを消費し、仮想マシン上で稼働するアプリケーションの性能にも悪影響を及ぼすケースがある。そのため、頻繁にライブマイグレーションを行う状況は好ましくない。

そこで本発明の目的は、仮想マシンにおける性能安定化を効率的に実現する技術を提供することにある。

そこで本発明は、仮想サーバの配置最適化において、少ないライブマイグレーションの実施により性能安定化を実現するため、長期に渡り安定してリソースを提供可能な移動先ホストを選択可能とすることを目的とする。

管理者における移動先ホスト選択に関わる作業負荷を軽減することができる。また、連続性を考慮した評価結果に基づいて移動先ホストを決定できるため、長期に渡りリソースに余裕があるホストを選択することが可能となり、VM移動が頻繁に発生することを抑え、性能を安定化させることが可能となる。

上記課題を解決する本発明の仮想マシン運用支援システムは、仮想マシンの配置先となる各物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報を少なくとも保持した記憶装置と、所定装置から所定仮想マシンに関して得た、該当仮想マシンが所定時期に要するリソースの情報と、前記記憶装置が保持する各物理サーバに関する情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定する処理と、前記所定仮想マシンが所定時期に要するリソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理と、各判定により各物理サーバに関して得た前記余裕度および前記連続性の各情報を所定装置に表示する処理と、を実行する演算装置と、を備えることを特徴とする。

また、本発明の仮想マシン運用支援方法は、仮想マシンの配置先となる各物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報を少なくとも保持した記憶装置を備えた情報処理システムが、所定装置から所定仮想マシンに関して得た、該当仮想マシンが所定時期に要するリソースの情報と、前記記憶装置が保持する各物理サーバに関する情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定する処理と、前記所定仮想マシンが所定時期に要するリソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理と、各判定により各物理サーバに関して得た前記余裕度および前記連続性の各情報を所定装置に表示する処理と、を実行する、ことを特徴とする。

本発明によれば、仮想マシンにおける性能安定化を効率的に実現できる。

本実施形態における仮想マシン運用支援システムを含むネットワーク構成例を示す図である。 本実施形態における仮想マシン運用支援システムのハードウェア構成例を示す図である。 本実施形態におけるＶＭ管理情報ＤＢの構成例を示す図である。 本実施形態におけるホスト管理情報ＤＢの構成例を示す図である。 本実施形態における割当て予定リソース量ＤＢの構成例を示す図である。 本実施形態におけるオーバーコミット率上限ＤＢの構成例を示す図である。 本実施形態における稼働履歴ＤＢの構成例を示す図である。 本実施形態におけるリソース使用量予測ＤＢの構成例を示す図である。 本実施形態における仮想マシン運用支援方法の処理手順例１を示すフロー図である。 本実施形態における仮想マシン運用支援方法の処理手順例２を示すフロー図である。 本実施形態における仮想マシン運用支援方法の処理手順例３を示すフロー図である。 本実施形態における仮想マシン運用支援方法の処理手順例４を示すフロー図である。 本実施形態における仮想マシン運用支援方法の処理手順例５を示すフロー図である。 本実施形態における画面表示例１を示す図である。 本実施形態における画面表示例２を示す図である。 本実施形態における画面表示例３を示す図である。 本実施形態における画面表示例４を示す図である。

−−−ネットワーク構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の仮想マシン運用支援システムたる運用管理サーバ１００を含むネットワーク構成図である。図１に示す仮想マシン運用支援システムたる運用管理サーバ１００（以下、運用管理サーバ）は、仮想マシンにおける性能安定化を効率的に実現するコンピュータシステムである。

図１に例示するネットワーク構成では、運用管理サーバ１００が、ネットワーク１０、１１を介して、運用管理対象システム１および操作端末２００と通信可能に接続された構成となっている。このうち運用管理対象システム１は、複数のホスト２１〜２３、３１〜３３等、を含んで構成されるものとする。また、操作端末２００は、上述の運用管理対象システム１の運用管理者等が利用する端末である。

上述の運用管理対象システム１におけるホスト２１〜２３は、ラック２０内に収容されており、またホスト３１〜３３はラック３０内に収容されている。また、ラック２０における各ホスト２１〜２３上では仮想マシンたる仮想サーバ２５〜２７が、またラック３０における各ホスト３１〜３３上では仮想サーバ３５〜３７が稼働している。なお、こうした仮想サーバをＶＭと以降は記載する。

こうしたネットワーク構成における運用管理サーバ１００は、上述の運用管理対象システム１が含む各ホストにおけるＶＭの運用管理を行うサーバ装置であり、ホスト間での負荷の偏り発生に伴い、所定のＶＭを移動させる、いわゆるライブマイグレーションの要否判断に必要となる情報を生成し、これを操作端末２００に出力するものとなる。上述の運用管理者は、運用管理サーバ１００から出力された上述の情報を操作端末２００を介して閲覧し、移動対象の仮想サーバやその移動要否、移動先について容易かつ的確な判断が可能となる。この操作端末２００は、例えば運用管理者ごとに備わるものとしてもよい。

−−−ハードウェア構成−−−
また、本実施形態の運用管理サーバ１００のハードウェア構成は以下の如くとなる。本実施形態における運用管理サーバ１００は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なう演算装置たるＣＰＵ１０４、および、ネットワーク１０、１１と接続し他装置との通信処理を担う通信装置１０５、を備える。

上述のＣＰＵ１０４がプログラム１０２を実行することで、リソース予約処理部１１０、リソース使用量予測部１１１、および移動先候補評価部１１２の各機能を実装することとなる。これら各機能の詳細は後述する。

なお、記憶装置１０１内には、本実施形態の仮想マシン運用支援システムとして必要な機能を実装する為のプログラム１０２の他、処理に用いる各種情報を格納したＤＢ１２５〜１３０が少なくとも記憶されている。これらＤＢ１２５〜１３０のデータ構成の具体例については後述する。また、本実施形態の運用管理サーバ１００を、いわゆるスタンドアロンの計算機として構成する場合、上述の構成の他に、ユーザからのキー入力や音声入力を受け付ける入力装置、処理データの表示を行うディスプレイ等の出力装置、を備えるも
のとする。

なお、ホスト２１〜２３、３１〜３３等と、操作端末２００も、上述の運用管理サーバ１００の構成と同様に、一般的なコンピュータ装置としてのハードウェア構成を備えるものとする。

−−−データ構造例−−−
次に、本実施形態の運用管理サーバ１００が用いるテーブルにおけるデータ構造例について説明する。図３は本実施形態におけるＶＭ管理情報ＤＢ１２５の構成例を示す図である。図３に例示する本実施形態のＶＭ管理情報ＤＢ１２５は、運用管理対象システム１の各ホスト上で稼働しているＶＭ、および将来稼働する予定のＶＭに関する管理情報を格納したデータベースである。

図３のＶＭ管理情報ＤＢ１２５における各レコードは、それぞれ１つのＶＭに対応している。こうしたレコードにおいて、ＶＭフィールド８０１の値は、該当ＶＭを一意に示すＩＤである。また、ホストフィールド８０２の値は、該当ＶＭが稼働しているホストを一意に示すＩＤである。また、稼働時間フィールド８０４の値は、該当ＶＭの稼働時間を表す時刻情報である。このうち稼働時間フィールド８０４の「開始時刻」の値は、該当ＶＭの稼働開始時刻である。この開始時刻が現時刻からみて過去の時刻である場合、該当ＶＭは既に稼働中であることを意味する。一方、開始時刻が現時刻からみて未来の時刻である場合、該当ＶＭの稼働が予約されていることを表す。また、稼働時間フィールド８０４の「終了時刻」の値は、該当ＶＭの稼働終了予定時刻である。この終了時刻が現時刻からみて未来の時刻である場合、該当ＶＭはその時刻に稼働終了する予定であることを表す。一方、終了時刻が「−」の場合、該当ＶＭは終了予定が定まっていないことを表す。また、割当てリソース量フィールド８０５の値は、該当ＶＭに割り当てるリソース量である。このうち「ＣＰＵコア数」は該当ＶＭに割り当てるＣＰＵのコア数を、また、「ＣＰＵ周波数」は該当ＶＭに割り当てる各コアの周波数を、また、「メモリ」は該当ＶＭに割り当てるメモリ容量を表す。

図４は本実施形態におけるホスト管理情報ＤＢ１２６の構成例を示す図である。図４にて例示する本実施形態のホスト管理情報ＤＢ１２６は、運用管理対象システム１に含まれる各ホストに関する情報を格納したデータベースである。

図４で例示するホスト管理情報ＤＢ１２６の各レコードは、それぞれ１つのホストに対応したレコードである。このレコードにおいて、ホストフィールド８１１の値は、該当ホストを一意に示すＩＤである。また、ラックフィールド８１２の値は、該当ホストを収容したラックを一意に示すＩＤである。また、キャパシティフィールド８１３の値は、該当ホストが持つ物理的なリソースのキャパシティを表す。

このキャパシティフィールド８１３のうち「ＣＰＵコア数」は、該当ホストが持つＣＰＵコア数を、また、「ＣＰＵ周波数」は該当ホストが持つ各ＣＰＵコアの周波数を、また、「メモリ」は該当ホストが持つメモリ容量を表す。

例えば、或るホストに関するリソースのキャパシティとして、ＣＰＵコア数が「１２」、１つのＣＰＵの周波数が「２．０ＧＨｚ」である場合、このホストが、ＣＰＵに基づくリソースとしてＶＭに提供しうるのは、１２×２＝２４ＧＨｚとなる。

図５は本実施形態における割当て予定リソース量ＤＢ１２７の構成例を示す図である。図５にて例示する本実施形態の割当て予定リソース量ＤＢ１２７は、各ホストにおいて、ホスト上で稼働する各ＶＭに割当てるリソース量の合計を表す情報を格納したデータベー
スである。

図５で例示する割当て予定リソース量ＤＢ１２７の各レコードは、該当ホストについての、ある時刻における割当て予定リソース量を表す。このうち時刻フィールド８２１の値は、対象とする時刻を表す。また、割当てリソース量フィールド８２２の値は、該当時刻に稼働予定である各ＶＭに割当てるＣＰＵ、メモリの各リソース量の合計値である。また、オーバーコミット率フィールド８２３の値は、該当ホストが持つリソースのキャパシティに対する割当てリソース量８２２の割合である。

例えば、或る日時に関して各ＶＭに割当て予定となっているＣＰＵの周波数が、「６ＧＨｚ」、「４ＧＨｚ」、「２ＧＨｚ」、であった場合（ＶＭ管理情報ＤＢ１２５から該当日時に関してレコードを抽出して取得）、該当日時の割当てリソース量のうちＣＰＵに関しては、６＋４＋２＝１２ＧＨｚである。またこの場合、該当ホストに関するリソースのうちＣＰＵに関するキャパシティが「ＣＰＵコア数＝１２」および「ＣＰＵ周波数＝２．０ＧＨｚ」であった場合（ホスト管理情報ＤＢ１２６から該当ホストに関してレコードを抽出して取得）、該当ホストは、最大で１２×２．０＝２４ＧＨｚのＣＰＵリソースを提供出来る。この場合、オーバーコミット率８２３の値は、（１２ＧＨｚ÷２４ＧＨｚ）×１００＝５０％、となる。

このように、例えばオーバーコミット率が「５０％」の場合、該当ホストが持つリソースのキャパシティのうち、５０％のリソースが割当て予定であることを表している。該当ホストが持つリソースのキャパシティよりも多くのリソースを割当てる場合（すなわちオーバーコミットをしている場合）、オーバーコミット率は１００％を上回る。

図６は本実施形態におけるオーバーコミット率上限ＤＢ１２８の構成例を示す図である。図６にて例示する本実施形態のオーバーコミット率上限ＤＢ１２８は、運用管理対象システム１において許容するオーバーコミット率の上限値を格納したデータベースである。このオーバーコミット率上限ＤＢ１２８のうち、ＣＰＵフィールド８３１の値は、ＣＰＵのオーバーコミット率の上限値を表し、またメモリフィールド８２３の値はメモリのオーバーコミット率の上限値を表す。こうしたオーバーコミット率上限ＤＢ１２８は、運用管理者が許容出来るコストや性能安定性などの要件に応じて事前に決定し、記憶装置１０１に格納しておくものとする。

図７は本実施形態における稼働履歴ＤＢ１２９の構成例を示す図である。図７にて例示する本実施形態の稼働履歴ＤＢ１２９は、各ホストに関して、該当ホスト上における各ＶＭにより使用されたリソース量の情報を格納したデータベースである。すなわち、図７で例示する稼働履歴ＤＢ１２９の各レコードは、該当ホストについての、過去のある時刻におけるＣＰＵおよびメモリといった各リソースの使用量実績を表している。

このうち時刻フィールド９０１の値は、対象とする時刻を表す。また、ＣＰＵ使用量フィールド９０２の値は、該当時刻に該当ホスト上の各ＶＭで使用されたＣＰＵのリソース量の合計値である。また、メモリフィールド９０３の値は、該当時刻に該当ホスト上の各ＶＭで使用されたメモリのリソース量の合計値である。

図８は本実施形態におけるリソース使用量予測ＤＢ１３０の構成例を示す図である。図７にて例示する本実施形態のリソース使用量予測ＤＢ１３０は、上述の稼働履歴ＤＢ１２９のデータに基づいて、運用管理サーバ１００が所定アルゴリズムによって生成した、各ホストにおけるリソース使用量の予測値を格納したデータベースである。すなわち、図８で例示するリソース使用量予測ＤＢ１３０の各レコードは、該当ホストについての、将来のある時刻におけるＣＰＵおよびメモリといった各リソースの使用量予測値を表している
。

このうち時刻フィールド９１１の値は、対象とする時刻を表す。また、ＣＰＵ使用量フィールド９１２の値は、該当時刻に該当ホスト上の各ＶＭで使用されるであろうＣＰＵのリソース量の合計値である。また、メモリフィールド９１３の値は、該当時刻に該当ホスト上の各ＶＭで使用されるであろうメモリのリソース量の合計値である。こうしたリソース使用量予測ＤＢ１３０の生成については後述する。

−−−リソース予約処理の例−−−
以下、本実施形態における仮想マシン運用支援方法の実際手順について図に基づき説明する。以下で説明する仮想マシン運用支援方法に対応する各種動作は、仮想マシン運用支援システムたる上述の運用管理サーバ１００がメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図９は、本実施形態における仮想マシン運用支援方法の処理手順例１を示すフロー図である。ここで、本実施形態の操作端末２００を操作するユーザとしては、アプリケーション管理者とインフラ管理者の２種類の管理者が存在するものとする。このうちアプリケーション管理者は、ＶＭ上で稼働するアプリケーションに対する運用管理の操作を行うユーザである。一方、インフラ管理者は、ホストやネットワークなどのインフラの管理を行うユーザである。この図９で例示するフローで運用管理サーバ１００との間でデータ授受を行う操作端末２００は、上述のユーザのうち、ＶＭに関してリソース予約を希望するアプリケーション管理者が操作するものとする。すなわち、アプリケーション管理者によるリソース予約に伴う処理手順が図９のフローとなる。

この場合、操作端末２００は、所定のＶＭに関するリソース予約要求をアプリケーション管理者から受け付け、これをネットワーク１１を介して運用管理サーバ１００に送信する（Ｓ４１１）。

一方、運用管理サーバ１００は、ネットワーク１１を介して上述のリソース予約要求を受信し、これに伴って後述するリソース予約処理を実行し（Ｓ４１２）、当該予約処理の結果を操作端末２００に返信して（Ｓ４１３）、処理を終了する。運用管理サーバ１００において、このリソース予約処理を実行するのはリソース予約処理部１１０である。

ここで、上述のステップＳ４１２、すなわちリソース予約処理の詳細について説明する。図１０は本実施形態における仮想マシン運用支援方法の処理手順例２を示すフロー図であり、具体的には、運用管理サーバ１００におけるリソース予約処理の詳細を示すフロー図となる。

この場合まず、運用管理サーバ１００のリソース予約処理部１１０は、アプリケーション管理者の指示を受けた操作端末２００から、リソース予約要求を受信する（Ｓ５０１）。ここで受信したリソース予約要求には、ＶＭに関してリソースを確保したい予約期間に対応した予約開始時刻および予約終了時刻と、確保したいリソース量を示す割当てリソース量（例えば、ＣＰＵコア数、ＣＰＵ周波数、メモリ）の各情報が少なくとも含まれている。

次に、運用管理サーバ１００のリソース予約処理部１１０は、運用管理対象システム１に含まれる全ホストの情報をホスト管理情報ＤＢ１２６から読み出し、各ホストに対して、以下のステップＳ５０３からステップＳ５０６に至る一連の各処理を実行する（Ｓ５０２）。

このうちステップＳ５０３において、リソース予約処理部１１０は、上述のステップＳ５０２で情報を読み出したホストのうち、例えばホストのＩＤ（例：図４のホスト管理情報ＤＢ１２６におけるホストフィールド８１１の値）の昇順で１つ選択した処理対象ホストについて、割当て予定リソース量ＤＢ１２７にて各レコードを参照し、上述の予約期間に時刻フィールド８２１の時刻が含まれる各レコードから、割当てリソース量フィールド８２２の各値を抽出する（Ｓ５０３）。

また、ステップＳ５０４において、リソース予約処理部１１０は、上述のステップＳ５０３で抽出した（他の各ＶＭに対する）割当て予定リソース量（例えば、ＣＰＵ：１２ＧＨｚ、メモリ：１０ＧＢ）に、（今次、リソース割当てを想定しているＶＭに関して）上述のリソース予約要求が示す割当てリソース量（例えば、ＣＰＵ：２０ＧＨｚ、メモリ：２０ＧＢ）を更に加えた総リソース量（例えば、ＣＰＵ：３２ＧＨｚ、メモリ：２０ＧＢ）を、上述の処理対象ホストが全て担って各ＶＭを稼働させた場合、予約期間におけるオーバーコミット率が上限値（図６のオーバーコミット率上限ＤＢ１２８の示す値。例えば、ＣＰＵ：４００％、メモリ：１００％）を超えないか判定する（Ｓ５０４）。

この判定の結果、上述の総リソース量がオーバーコミット率上限値を超える場合（Ｓ５０４：Ｎｏ）、リソース予約処理部１１０は、処理対象ホストに対する処理を終了し、処理をステップＳ５０２に戻して、未処理の次のホストに対する処理を実行する。

一方、上述の判定の結果、総リソース量がオーバーコミット率上限値を超えない場合（Ｓ５０４：Ｙｅｓ）、リソース予約処理部１１０は処理をステップＳ５０５に進める。

このステップＳ５０５において、リソース予約処理部１１０は、上述の予約期間における平均リソース割当て予定量を計算する。ここで平均リソース割当て予定量とは、予約期間に関してステップＳ５０４で得た総リソース量の時間平均である。例えば、総リソース量が、ＣＰＵ：３２ＧＨｚ、メモリ：２０ＧＢで、予約期間が２時間であった場合、平均リソース割当て予定量は、ＣＰＵ：１６ＧＨｚ／時間、メモリ：１０ＧＢ／時間、となる。

続いてステップＳ５０６において、リソース予約処理部１１０は、上述のステップＳ５０５まで処理対象とした処理対象ホストのＩＤと、ステップＳ５０５で求めた平均リソース割当て予定量の各情報を、配置先候補ホストとしてメモリ１０３上に保存する。

以上のステップＳ５０３からＳ５０６の各処理が、全ホストに対して完了した場合（Ｓ５０７）、リソース予約処理部１１０は、処理をＳ５０８に進める。

ステップＳ５０８において、リソース予約処理部１１０は、メモリ１０３において配置先候補ホストの情報有無を判定する。この判定の結果、メモリ１０３に配置先候補ホストの情報が存在しない場合（Ｓ５０８：Ｎｏ）、リソース予約処理部１１０は、処理をステップＳ５１２に進めて、予約失敗の旨を示すメッセージを操作端末２００に送信し、処理を終了する。他方、上述の判定の結果、メモリ１０３に配置先候補ホストの情報が存在する場合（Ｓ５０８：Ｙｅｓ）、リソース予約処理部１１０は、処理をＳ５０９に進める。

ステップＳ５０９において、リソース予約処理部１１０は、メモリ１０３に情報を保持する配置先候補ホストの中で、ステップＳ５０５で求めた平均リソース割当て予定量が最も小さいホストを、今次のＶＭに関して配置先ホストに決定する。

続いてステップＳ５１０において、リソース予約処理部１１０は、ステップＳ５０１で
受けた今回のリソース予約要求が示す予約情報を、ＶＭ管理情報ＤＢ１２５にてレコードを生成して追加する。また、リソース予約処理部１１０は、割当て予定リソース量ＤＢ１２７において、該当ホストに関するレコードのうち、上述の予約期間に対応した時刻８２１のレコードに対して、上述のリソース予約要求が示す割当てリソース量（ＣＰＵコア数とＣＰＵ周波数の乗算値と、メモリの値）を割当てリソース量８２２の値に加算し、修正する。

またステップＳ５１１において、リソース予約処理部１１０は、ここまでの処理結果、すなわち予約結果として、予約成功の旨を示すメッセージを操作端末２００に送信し、処理を終了する。

−−−ＶＭ移動に伴う処理の例−−−
次に、ＶＭ配置最適化の処理に伴うフローについて図に基づき説明する。図１１は、本実施形態における仮想マシン運用支援方法の処理手順例３を示すフロー図である。この場合、操作端末２００は、インフラ管理者からのリソース使用量の予測要求を受け付けて、これをネットワーク１１を介して、運用管理サーバに送信する（Ｓ４２１）。この処理は、例えば、所定時間毎に操作端末２００が自動実行するとしてもよいし、運用管理対象システム１におけるホスト間での負荷偏在のアラートが、運用管理サーバ１００から通知されたことを認識したインフラ管理者からの指示によって開始されるとしてもよく、処理のトリガーについては限定しない。

一方、運用管理サーバ１００は、上述の予測要求の受信に伴ってリソース使用量の予測処理を実行し（Ｓ４２２）、この予測結果を操作端末２００に返信する（Ｓ４２３）。このリソース使用量の予測処理の詳細は後述する。

他方、インフラ管理者は、上述の運用管理サーバ１００からのリソース使用量の予測結果を操作端末２００で閲覧し、運用管理対象システム１の各ホストのうちリソース不足発生が予想されるホストの有無を確認する。これにより、リソース不足発生が予想されるホストの存在を認識した場合、このインフラ管理者は、そのリソース不足発生前に、ライブマイグレーション技術を用いて該当ホストの所定ＶＭを他ホストに移動させることで、負荷平準化を図り、リソース不足発生を未然に防ぐ。

こうしたインフラ管理者は、上述のステップＳ４２３にて操作端末２００が受信した予測結果を参照し、移動対象とするＶＭと移動させる時間を判断する。こうした判断結果を入力装置等で受けた操作端末２００は、これをネットワーク１１を介して運用管理サーバ１００に送信する（Ｓ４２４）。

一方、運用管理サーバ１００は、操作端末２００から受信した判断結果が示す、移動対象のＶＭおよび移動時間に基づき、該当ＶＭの移動先候補となるホストの評価を行い（Ｓ４２５）、この評価結果を操作端末２００に送信する（Ｓ４２６）。

他方、操作端末２００は、運用管理サーバ１００から上述の評価結果を受信して、ディスプレイ等の表示装置に出力し、インフラ管理者の閲覧に供する。この場合、インフラ管理者は、操作端末２００が受信した評価結果を閲覧して、ＶＭ移動先のホストを決定し、該当ＶＭの移動予約の要求を操作端末２００に入力する。これを受けた操作端末２００は、該当ＶＭの移動予約の要求を運用管理サーバ１００に送信する（Ｓ４２７）。

この場合、運用管理サーバ１００は、操作端末２００から受信したＶＭ移動の予約要求に基づき、既に述べたライブマイグレーション等の既存技術を適宜に利用したＶＭ移動の予約処理を行う（Ｓ４２８）。

ここで、上述のステップＳ４２２、すなわちリソース使用量予測の処理の詳細について、説明する。図１２は、本実施形態における仮想マシン運用支援方法の処理手順例４を示すフロー図であり、具体的には、運用管理サーバ１００におけるリソース使用量予測部１１１による処理を示すフロー図である。

この場合まず、運用管理サーバ１００のリソース使用量予測部１１１は、操作端末２００から、インフラ管理者による予測要求を受信する（Ｓ６０１）。

次に、リソース使用量予測部１１１は、運用管理対象システム１に含まれる全ホストに対して、以下のステップＳ６０３からすなわちＳ６０４に至る一連の各処理を実行する（Ｓ６０２）。この場合のホストの選択方法については、図１０で例示した形態と同様である。

このうちステップＳ６０３において、リソース使用量予測部１１１は、稼働履歴ＤＢ１２９の格納情報のうち対象ホストに関するレコードを抽出し、該当レコードが示す稼働履歴情報を、所定の予測アルゴリズムに適用することで、対象ホストにおける、現時点から所定未来の将来までの予測期間のリソース使用量を予測し、この予測結果をリソース使用量予測ＤＢ１３０に格納する。こうしたリソース使用量予測に採用する上述のアルゴリズムとしては、例えば、ＳＡＲＩＭＡ（Ｓｅａｓｏｎａｌ Ａｕｔｏ Ｒｅｇｒｅｓｓｉｖｅ Ｉｎｔｅｇｒａｔｅｄ Ｍｏｖｉｎｇ Ａｖｅｒａｇｅ）モデルや、Ｈｏｌｔ−Ｗｉｎｔｅｒｓ法など、時系列データ分析において一般的に用いられている手法に対応したアルゴリズムを用いるとすればよい。

続いて、ステップＳ６０４において、リソース使用量予測部１１１は、上述のステップＳ６０３で予測対象とした予測期間に、稼働時間フィールド８０４の開始時刻、終了時刻が含まれるレコードを、ＶＭ管理情報ＤＢ１２５から抽出し、該当レコードが示す割当てリソース量８０５の値に基づいて、リソース使用量の予測値に関する補正処理を実行する。この補正処理は、上述の予測期間にて、リソース割当て停止が予定されているＶＭの存在がＶＭ管理情報ＤＢ１２５のレコードから特定できた場合に、その割当て停止分のリソース使用量を予測値から差し引き、リソース使用量予測ＤＢ１３０の該当レコードを更新する。また、上述の予測期間にて、リソース割当てが開始される、すなわち稼働開始予定のＶＭの存在がＶＭ管理情報ＤＢ１２５のレコードから特定出来た場合に、その割当て開始分のリソース使用量を予測値に加算し、リソース使用量予測ＤＢ１３０の該当レコードを更新する。

全ホストに対して、上述のステップＳ６０３からステップＳ６０４の各処理が完了した場合（Ｓ６０５）、リソース使用量予測部１１１は、処理をステップＳ６０６に進める。

ステップＳ６０６から開始されるループにおいて、リソース使用量予測部１１１は、ホスト管理情報ＤＢ１２６が示す各ホストのラック８１２の情報（図４では図示していないが、ラックにおける配置位置も含むものとする）に基づき、各ホストのＩＤを各ラックの物理的な棚構成に応じたマトリクス（記憶装置１０１に予め保持する描画データ）の該当区画に配置し、ヒートマップキャンバスを生成する（Ｓ６０７）。図１４に、このステップＳ６０７にてリソース使用量予測部１１１が生成するヒートマップキャンバス１０１０の具体例を示す。

図１４に例示するヒートマップキャンバス１０１０において、マトリクス中の１つのマスが１つのホストを表し、マスの中に記載された文字列が当該ホストのＩＤを表している。また、太線はラックの範囲を表す。図１４に例示するヒートマップキャンバス１０１０の例では、例えばＩＤが「Ｈ０１」〜「Ｈ０８」であるホストが、同一のラック内に格納
されている例を示している。

続いてリソース使用量予測部１１１は、予測期間の日数分だけ、上述のステップＳ６０７の処理を繰り返し、日数分のヒートマップキャンバス１０１０を生成する。ここでは、予測期間が７日である場合を例に取り説明する。そのため、上述のステップＳ６０７の処理を１日目から７日目まで７回繰り返し、７枚のヒートマップキャンバス１０１０が生成されるものとする。

次にステップＳ６０８において、リソース使用量予測部１１１は、上述のステップＳ６０７で生成した各ヒートマップキャンバス１０１０の各マスに対し、ステップＳ６０４を経て得ている各ホストに関するリソース使用量予測値の大きさに応じた所定色を選択的に付与し、ヒートマップ１０２０を生成する。図１５に、このステップＳ６０８で生成したヒートマップ１０２０の具体例を示す。

この場合、リソース使用量予測部１１１は、運用管理対象システム１に含まれる各ホストに関して、ヒートマップ１０２０が対象とする日付におけるリソース使用量予測値の平均値を算定し、この平均値の大きさに応じて予め定めてある色を選択する。例えば、リソース使用量予測値が第１基準値より大きい場合は「赤色」、第１基準値と第２基準値の間に属する場合は「黄色」、第２基準値より小さい場合は「青」、を選択する。

続いてステップＳ６１０において、リソース使用量予測部１１１は、上述のステップＳ６０６からステップＳ６０９で生成した、予測期間の日数分のヒートマップ１０２０を画面表示する表示用データを生成し、これを予測結果として操作端末２００に送信する。図１６に、このステップＳ６１０で生成した画面データの例を示す。図１６の画面データ例では、操作端末２００のインターフェイスを介してインフラ管理者が操作したタイムスライダー１０３２によって指定される、所定日のヒートマップ１０３１を画面中央部に表示した形態を示している。このように、複数日に渡るヒートマップを１画面中において連続的かつ特定可能に表示することで、これを閲覧したインフラ管理者は、リソース使用量が増大する日付およびホストを容易に特定することが可能になる。

次に、運用管理サーバ１００の移動先候補評価部１１２による処理、すなわち上述のステップＳ４２５の処理について説明する。図１３は、本実施形態における仮想マシン運用支援方法の処理手順例５を示すフロー図である。

この場合、インフラ管理者は、上述のステップＳ４２３において提示された予測結果を操作端末２００にて参照し、移動対象とするＶＭおよび移動時刻を決定しているものとする。一方、この決定事項を入力装置で受けた操作端末２００は、上述のステップＳ４２４において、移動対象のＶＭおよび移動時刻の各情報を運用管理サーバ１００に送信することとなる。

他方、運用管理サーバ１００の移動先候補評価部１１２は、操作端末２００を介してインフラ管理者から指定された移動対象ＶＭおよび移動開始時間の情報を受信し（Ｓ７０１）、これに応じて、ＶＭ管理情報ＤＢ１２５において移動対象ＶＭに関するレコードを抽出し、該当レコードが含む情報を取得する（Ｓ７０２）。具体的には、移動対象ＶＭに関する割当てリソース量８０５および稼働時間８０４の終了時刻の各値を取得し、これをメモリ１０３に格納する。

次に、移動先候補評価部１１２は、運用管理対象システム１に含まれる全ホストに対して、以下のステップＳ７０４からすなわちＳ７０８に至る一連の各処理を実行して、上述の移動対象ＶＭの移行先のホストとしての適性評価を行う（Ｓ７０３）。処理対象すなわ
ち評価対象ホストの選択手法は上述の各フローにて述べたものと同様である。

このうちステップＳ７０４において、移動先候補評価部１１２は、リソース使用量予測ＤＢ１３０から、以降の処理で使用する時系列データとして、ステップＳ７０１で受信した移動開始時間から、ステップＳ７０２において取得した稼働時間の終了時刻に至る間の、一連のリソース使用量予測値（該当時刻に関するＣＰＵ使用量９１２、メモリ９１３の各値）を抽出する。

次にステップＳ７０５において、移動先候補評価部１１２は、ホスト管理情報ＤＢ１２６を参照し、評価対象ホストのキャパシティ８１３の各値を取得する。

またステップｓ７０６において、移動先候補評価部１１２は、評価対象ホストにおけるリソース量の余裕度を算定する。この余裕度は、上述の移動開始時間から稼働終了時刻までの時系列データが示すリソース使用量予測値に対し、該当ホストのキャパシティの値がどれほど大きいかを示すものなる。

ここで、ステップＳ７０５にて取得した評価対象ホストのキャパシティＣ、ステップＳ７０２で取得した割当てリソース量Ｒ、および、ステップＳ７０４で抽出した時刻ｉのリソース使用量予測データＰ_ｉによって、時刻ｉにおける余裕度Ｓ_ｉを以下の数１に示す式で定義出来る。
Ｓ_ｉ＝Ｃ−Ｒ−Ｐ_ｉ ・・・数１

余裕度Ｓ_ｉが正の値である時間帯は、移動してくるＶＭに対して十分なリソースを割当てることができる見込みであることを表し、この値が大きいほどその確度が高い。逆に、余裕度Ｓ_ｉが負の値である時間帯は、移動してくるＶＭに対して十分なリソースを割当てることができない見込みであることを表す。移動先候補評価部１１２は、評価対象期間における余裕度の積算値Σ_ｉＳ_ｉを算定し、これを対象ホストの余裕度の評価値とする（Ｓ７０７）。

次にステップＳ７０８において、移動先候補評価部１１２は、リソースを確保できる時間の連続性Ｄに対する評価を行う。この連続性Ｄは、次のようにして求める。

・Ｓ_Ｏ≧０の場合、最初にＳ_Ｏ＜０となる時刻をＤとする。

・Ｓ_Ｏ＜０の場合、最初にＳ_Ｏ≧０となる時刻をＤとする。

上述の連続性Ｄの値が大きいと、リソースが確保できる（もしくは確保できない）時間が長期間続く見込みであることを表す。逆に、連続性Ｄの値が小さいと、リソースを確保できる（もしくは確保できない）時間が長く続かない見込みであることを表す。

こうしたステップＳ７０３からステップＳ７０９の一連の各処理により、全ホストに対する評価を実施した後（Ｓ７０９）、移動先候補評価部１１２は、処理をステップＳ７１０に進め、評価結果を表示する画面データを作成し、これを操作端末２００に送信する。
図１７に、このステップＳ７１０により生成する画面データの例を示す。ここでは、ステップＳ６０６で作成したヒートマップキャンバス１０１０に対して、ステップＳ７０７で求めた余裕度およびステップＳ７０８で求めた連続性に基づき色づけを行うことで、ヒートマップ１０４０を作成し、これを画面データに含めた形態を示した。

このヒートマップ１０４０は、ヒートマップキャンバス１０１０の各マスに対して、該当ホストに関して得ている余裕度の大きさに応じて色を選択し、設定したものとなる。移
動先候補評価部１１２は、例えば、余裕度が第１基準より大きい場合は「青色」、第１基準より小さく第２基準より大きい場合は「黄色」、第２基準より小さい場合は「赤色」などと色の選択動作を行う。さらに移動先候補評価部１１２は、各ホストに関して得ている連続性に応じて、該当マスの設定した各色の濃さを決定する。この場合、移動先候補評価部１１２は、例えば、連続性が所定基準より高くなるほど該当色を濃くし、連続性が所定基準より低くなるほど該当色を薄くする。

このように、余裕度および連続性を示すヒートマップ１０４０を生成し、これを操作端末２００に送信して表示させることで、これを閲覧したインフラ管理者は、移動先ホストの選択作業時に、上述の連続性および余裕度に高さに応じて移動先ホストを選択すればよく、こうした作業の負荷を大きく低減することができる。

図１７で例示したヒートマップ１０４０の例では、インフラ管理者が操作端末２００から指定してきた移動対象ＶＭを、移動先候補評価部１１２が丸印１０４１のアイコンとして画面表示している。移動対象ＶＭを示す丸印１１０１は、ＶＭが稼働しているホストを表すマスの中に表示している。前述した通り、ヒートマップ１０４０における太線はラックを表す。これにより、インフラ管理者は、移動対象ＶＭと、移動対象ＶＭを含むホストおよびラック、同ラック内に含まれるホストを容易に特定することができる。そのため、ネットワーク性能などを考慮して同ラック内で移動を行いたい場合は、容易に移動先ホストを絞り込むことができる。図１７の例では、移動対象ＶＭがホスト「Ｈ３２」上で稼働しており、同ラック内にはホスト「Ｈ３１」〜「Ｈ３８」が存在することが容易に分かる。

さらに、前述した通りヒートマップ１０４０上の色が移動先ホストの評価結果を表している。リソースの余裕度を色で、連続性を色の濃さで表現しているため、インフラ管理者は、移動先として長時間に渡りリソースに余裕があるホストを選びたい場合、濃い青で表示されているホストを探せばよい。

このようにして、インフラ管理者は、運用管理サーバ１００から送信された評価結果を操作端末２００にて参照して移動先ホストを選定し、その選定結果を操作端末２００を介して運用管理サーバ１００に送信する。

運用管理サーバは、操作端末２００から指示された移動先ホストへの移動対象ＶＭの移動処理の予約を行い、該当予約で指定された時刻になるとＶＭ移動を実行する。このＶＭ移動は既に述べたライブマイグレーションを採用して実行すればよい。

以上で述べた処理により、負荷平準化のためのＶＭ移動における移動先ホストを、リソースの余裕度および連続性の観点から評価し、その結果をユーザに提示することができる。こうした評価結果を認識したユーザは、移動対象ＶＭの移動先ホストの選択に関わる作業負荷を軽減することができる。また、連続性と余裕度を考慮した評価結果に基づいて移動先ホストを決定できるため、長期に渡りリソースに余裕があるホストを効率的かつ的確に選択することが可能となり、ＶＭ移動が頻繁に発生することを抑え、性能を安定化させることが可能となる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、仮想マシンにおける性能安定化を効率的に実現できる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態
の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報を少なくとも保持しており、前記演算装置は、前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、各判定により各物理サーバに関して得た前記余裕度および前記連続性の各情報を所定装置に表示する処理を実行するものである、としてもよい。

これによれば、仮想マシンの移動先となる物理サーバについて、該当仮想マシンに必要なリソースを確保可能な時間の連続性と共に、その際の余裕度も更に踏まえた情報を、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は、仮想マシンの移動検討時点のみならず、移動後から所定期間の将来について必要なリソースを余裕を持って連続的に確保出来るか否かを容易かつ確実に認識して、仮想マシン移動先とその可否について的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。

また、本実施形態の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報を少なくとも保持しており、前記演算装置は、前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するものであるとしてもよい。

これによれば、過去の履歴に基づき精度良く予測されたリソース使用量を踏まえた上述の連続性を、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は仮想マシン移動先とその可否について更に的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。

また、本実施形態の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報と、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報とを少なくとも保持しており、前記演算装置は、前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値に対し、前記予約情報が示す、該当物理サーバの該当時期における各仮想マシンによるリソースの使用有無の情報を適用して補正を実行し、当該補正後の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するものであるとしてもよい。

これによれば、過去の履歴に基づき更に精度良く予測されたリソース使用量を踏まえた上述の連続性を、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は仮想マシン移動先とその可否について更に的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。

また、本実施形態の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理
サーバに関する情報として、所定空間における各物理サーバの配置位置を示す表示用オブジェクトを少なくとも保持しており、前記演算装置は、前記連続性の情報を所定装置に表示する処理に際し、前記表示用データを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低に応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するものであるとしてもよい。

これによれば、各物理サーバにおける上述の連続性を視覚的に認識容易な形態で、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は仮想マシン移動先とその可否について更に効率的かつ的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。

また、本実施形態の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報と、所定空間における各物理サーバの配置位置を示す表示用オブジェクトと、を少なくとも保持しており、前記演算装置は、前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、前記連続性の情報を所定装置に表示する処理に際し、前記表示用オブジェクトを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低および前記余裕度の情報が示す余裕度高低のそれぞれに応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するものであるとしてもよい。

これによれば、各物理サーバにおける上述の連続性および余裕度を視覚的に認識容易な形態で、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は仮想マシン移動先とその可否について更に効率的かつ的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。

また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記記憶装置において、前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報を少なくとも保持しており、前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、各判定により各物理サーバに関して得た前記余裕度および前記連続性の各情報を所定装置に表示する処理を実行するとしてもよい。

また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記記憶装置において、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報を少なくとも保持しており、前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するとしてもよい。

また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記
記憶装置において、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報と、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報とを少なくとも保持しており、前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値に対し、前記予約情報が示す、該当物理サーバの該当時期における各仮想マシンによるリソースの使用有無の情報を適用して補正を実行し、当該補正後の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するとしてもよい。

また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記記憶装置において、前記物理サーバに関する情報として、所定空間における各物理サーバの配置位置を示す表示用オブジェクトを少なくとも保持しており、前記連続性の情報を所定装置に表示する処理に際し、前記表示用データを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低に応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するとしてもよい。

また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記記憶装置において、前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報と、所定空間における各物理サーバの配置位置を示す表示用オブジェクトと、を少なくとも保持しており、前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、前記連続性の情報を所定装置に表示する処理に際し、前記表示用オブジェクトを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低および前記余裕度の情報が示す余裕度高低のそれぞれに応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するとしてもよい。

１ 運用管理対象システム
１０ ネットワーク
２０、３０ ラック
２１〜２３、３１〜３３ ホスト
２５〜２７、３５〜３７ 仮想マシン
１００ 運用管理サーバ（仮想マシン運用支援システム）
１０１ 記憶装置
１０２ プログラム
１０３ メモリ
１０４ ＣＰＵ（演算装置）
１０５ 通信装置
１１０ リソース予約処理部
１１１ リソース使用量予測部
１１２ 移動先候補評価部
１２５ ＶＭ管理情報ＤＢ
１２６ ホスト管理情報ＤＢ
１２７ 割当て予定リソース量ＤＢ
１２８ オーバーコミット率上限ＤＢ
１２９ 稼働履歴ＤＢ
１３０ リソース使用量予測ＤＢ
２００ 操作端末

Claims (10)

1. 仮想マシンの配置先となる各物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報を少なくとも保持した記憶装置と、
   所定装置から所定仮想マシンに関して得た、該当仮想マシンが所定時期に要するリソースの情報と、前記記憶装置が保持する各物理サーバに関する情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定する処理と、前記所定仮想マシンが所定時期に要するリソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理と、各判定により各物理サーバに関して得た前記余裕度および前記連続性の各情報を所定装置に表示する処理と、を実行する演算装置と、
   を備えることを特徴とする仮想マシン運用支援システム。
2. 前記記憶装置は、
   前記物理サーバに関する情報として、過去のリソース使用量の履歴情報を少なくとも保持しており、
   前記演算装置は、
   前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するものである、
   ことを特徴とする請求項１に記載の仮想マシン運用支援システム。
3. 前記記憶装置は、
   前記物理サーバに関する情報として、過去のリソース使用量の履歴情報と、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報とを少なくとも保持しており、
   前記演算装置は、
   前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値に対し、前記予約情報が示す、該当物理サーバの該当時期における各仮想マシンによるリソースの使用有無の情報を適用して補正を実行し、当該補正後の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するものである、
   ことを特徴とする請求項１に記載の仮想マシン運用支援システム。
4. 前記記憶装置は、
   前記物理サーバに関する情報として、所定空間における各物理サーバの配置位置を示す表示用オブジェクトを少なくとも保持しており、
   前記演算装置は、
   前記連続性の情報を所定装置に表示する処理に際し、前記表示用オブジェクトを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低に応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するものである、
   ことを特徴とする請求項１に記載の仮想マシン運用支援システム。
5. 前記記憶装置は、
   前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報と、所定空間における各物理サーバの配置位置を示す表示用オブジェクトと、を少なくとも保持しており、
   前記演算装置は、
   前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、
   前記連続性の情報を所定装置に表示する処理に際し、前記表示用オブジェクトを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低および前記余裕度の情報が示す余裕度高低のそれぞれに応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するものである、
   ことを特徴とする請求項１に記載の仮想マシン運用支援システム。
6. 仮想マシンの配置先となる各物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報を少なくとも保持した記憶装置を備えた情報処理システムが、
   所定装置から所定仮想マシンに関して得た、該当仮想マシンが所定時期に要するリソースの情報と、前記記憶装置が保持する各物理サーバに関する情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定する処理と、前記所定仮想マシンが所定時期に要するリソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理と、各判定により各物理サーバに関して得た前記余裕度および前記連続性の各情報を所定装置に表示する処理と、を実行する、
   ことを特徴とする仮想マシン運用支援方法。
7. 前記情報処理システムが、
   前記記憶装置において、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報を少なくとも保持しており、
   前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定する、
   ことを特徴とする請求項６に記載の仮想マシン運用支援方法。
8. 前記情報処理システムが、
   前記記憶装置において、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報と、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報とを少なくとも保持しており、
   前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値に対し、前記予約情報が示す、該当物理サーバの該当時期における各仮想マシンによるリソースの使用有無の情報を適用して補正を実行し、当該補正後の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定する、
   ことを特徴とする請求項６に記載の仮想マシン運用支援方法。
9. 前記情報処理システムが、
   前記記憶装置において、前記物理サーバに関する情報として、所定空間における各物理サーバの配置位置を示す表示用オブジェクトを少なくとも保持しており、
   前記連続性の情報を所定装置に表示する処理に際し、前記表示用オブジェクトを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低に応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力する、
   ことを特徴とする請求項６に記載の仮想マシン運用支援方法。
10. 前記情報処理システムが、
    前記記憶装置において、前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報と、所定空間における各物理サーバの配置位置を示す表示用オブジェクトと、を少なくとも保持しており、
    前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、
    前記連続性の情報を所定装置に表示する処理に際し、前記表示用オブジェクトを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低および前記余裕度の情報が示す余裕度高低のそれぞれに応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力する、
    ことを特徴とする請求項６に記載の仮想マシン運用支援方法。