(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0015】
−−−ネットワーク構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。
図1は、本実施形態の仮想マシン運用支援システムたる運用管理サーバ100を含むネットワーク構成図である。
図1に示す仮想マシン運用支援システムたる運用管理サーバ100(以下、運用管理サーバ)は、仮想マシンにおける性能安定化を効率的に実現するコンピュータシステムである。
【0016】
図1に例示するネットワーク構成では、運用管理サーバ100が、ネットワーク10、11を介して、運用管理対象システム1および操作端末200と通信可能に接続された構成となっている。このうち運用管理対象システム1は、複数のホスト21〜23、31〜33等、を含んで構成されるものとする。また、操作端末200は、上述の運用管理対象システム1の運用管理者等が利用する端末である。
【0017】
上述の運用管理対象システム1におけるホスト21〜23は、ラック20内に収容されており、またホスト31〜33はラック30内に収容されている。また、ラック20における各ホスト21〜23上では仮想マシンたる仮想サーバ25〜27が、またラック30における各ホスト31〜33上では仮想サーバ35〜37が稼働している。なお、こうした仮想サーバをVMと以降は記載する。
【0018】
こうしたネットワーク構成における運用管理サーバ100は、上述の運用管理対象システム1が含む各ホストにおけるVMの運用管理を行うサーバ装置であり、ホスト間での負荷の偏り発生に伴い、所定のVMを移動させる、いわゆるライブマイグレーションの要否判断に必要となる情報を生成し、これを操作端末200に出力するものとなる。上述の運用管理者は、運用管理サーバ100から出力された上述の情報を操作端末200を介して閲覧し、移動対象の仮想サーバやその移動要否、移動先について容易かつ的確な判断が可能となる。この操作端末200は、例えば運用管理者ごとに備わるものとしてもよい。
【0019】
−−−ハードウェア構成−−−
また、本実施形態の運用管理サーバ100のハードウェア構成は以下の如くとなる。本実施形態における運用管理サーバ100は、SSD(Solid State Drive)やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置101、RAMなど揮発性記憶素子で構成されるメモリ103、記憶装置101に保持されるプログラム102をメモリ103に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なう演算装置たるCPU104、および、ネットワーク10、11と接続し他装置との通信処理を担う通信装置105、を備える。
【0020】
上述のCPU104がプログラム102を実行することで、リソース予約処理部110、リソース使用量予測部111、および移動先候補評価部112の各機能を実装することとなる。これら各機能の詳細は後述する。
【0021】
なお、記憶装置101内には、本実施形態の仮想マシン運用支援システムとして必要な機能を実装する為のプログラム102の他、処理に用いる各種情報を格納したDB125〜130が少なくとも記憶されている。これらDB125〜130のデータ構成の具体例については後述する。また、本実施形態の運用管理サーバ100を、いわゆるスタンドアロンの計算機として構成する場合、上述の構成の他に、ユーザからのキー入力や音声入力を受け付ける入力装置、処理データの表示を行うディスプレイ等の出力装置、を備えるも
のとする。
【0022】
なお、ホスト21〜23、31〜33等と、操作端末200も、上述の運用管理サーバ100の構成と同様に、一般的なコンピュータ装置としてのハードウェア構成を備えるものとする。
【0023】
−−−データ構造例−−−
次に、本実施形態の運用管理サーバ100が用いるテーブルにおけるデータ構造例について説明する。
図3は本実施形態におけるVM管理情報DB125の構成例を示す図である。
図3に例示する本実施形態のVM管理情報DB125は、運用管理対象システム1の各ホスト上で稼働しているVM、および将来稼働する予定のVMに関する管理情報を格納したデータベースである。
【0024】
図3のVM管理情報DB125における各レコードは、それぞれ1つのVMに対応している。こうしたレコードにおいて、VMフィールド801の値は、該当VMを一意に示すIDである。また、ホストフィールド802の値は、該当VMが稼働しているホストを一意に示すIDである。また、稼働時間フィールド804の値は、該当VMの稼働時間を表す時刻情報である。このうち稼働時間フィールド804の「開始時刻」の値は、該当VMの稼働開始時刻である。この開始時刻が現時刻からみて過去の時刻である場合、該当VMは既に稼働中であることを意味する。一方、開始時刻が現時刻からみて未来の時刻である場合、該当VMの稼働が予約されていることを表す。また、稼働時間フィールド804の「終了時刻」の値は、該当VMの稼働終了予定時刻である。この終了時刻が現時刻からみて未来の時刻である場合、該当VMはその時刻に稼働終了する予定であることを表す。一方、終了時刻が「−」の場合、該当VMは終了予定が定まっていないことを表す。また、割当てリソース量フィールド805の値は、該当VMに割り当てるリソース量である。このうち「CPUコア数」は該当VMに割り当てるCPUのコア数を、また、「CPU周波数」は該当VMに割り当てる各コアの周波数を、また、「メモリ」は該当VMに割り当てるメモリ容量を表す。
【0025】
図4は本実施形態におけるホスト管理情報DB126の構成例を示す図である。
図4にて例示する本実施形態のホスト管理情報DB126は、運用管理対象システム1に含まれる各ホストに関する情報を格納したデータベースである。
【0026】
図4で例示するホスト管理情報DB126の各レコードは、それぞれ1つのホストに対応したレコードである。このレコードにおいて、ホストフィールド811の値は、該当ホストを一意に示すIDである。また、ラックフィールド812の値は、該当ホストを収容したラックを一意に示すIDである。また、キャパシティフィールド813の値は、該当ホストが持つ物理的なリソースのキャパシティを表す。
【0027】
このキャパシティフィールド813のうち「CPUコア数」は、該当ホストが持つCPUコア数を、また、「CPU周波数」は該当ホストが持つ各CPUコアの周波数を、また、「メモリ」は該当ホストが持つメモリ容量を表す。
【0028】
例えば、或るホストに関するリソースのキャパシティとして、CPUコア数が「12」、1つのCPUの周波数が「2.0GHz」である場合、このホストが、CPUに基づくリソースとしてVMに提供しうるのは、12×2=24GHzとなる。
【0029】
図5は本実施形態における割当て予定リソース量DB127の構成例を示す図である。
図5にて例示する本実施形態の割当て予定リソース量DB127は、各ホストにおいて、ホスト上で稼働する各VMに割当てるリソース量の合計を表す情報を格納したデータベー
スである。
【0030】
図5で例示する割当て予定リソース量DB127の各レコードは、該当ホストについての、ある時刻における割当て予定リソース量を表す。このうち時刻フィールド821の値は、対象とする時刻を表す。また、割当てリソース量フィールド822の値は、該当時刻に稼働予定である各VMに割当てるCPU、メモリの各リソース量の合計値である。また、オーバーコミット率フィールド823の値は、該当ホストが持つリソースのキャパシティに対する割当てリソース量822の割合である。
【0031】
例えば、或る日時に関して各VMに割当て予定となっているCPUの周波数が、「6GHz」、「4GHz」、「2GHz」、であった場合(VM管理情報DB125から該当日時に関してレコードを抽出して取得)、該当日時の割当てリソース量のうちCPUに関しては、6+4+2=12GHzである。またこの場合、該当ホストに関するリソースのうちCPUに関するキャパシティが「CPUコア数=12」および「CPU周波数=2.0GHz」であった場合(ホスト管理情報DB126から該当ホストに関してレコードを抽出して取得)、該当ホストは、最大で12×2.0=24GHzのCPUリソースを提供出来る。この場合、オーバーコミット率823の値は、(12GHz÷24GHz)×100=50%、となる。
【0032】
このように、例えばオーバーコミット率が「50%」の場合、該当ホストが持つリソースのキャパシティのうち、50%のリソースが割当て予定であることを表している。該当ホストが持つリソースのキャパシティよりも多くのリソースを割当てる場合(すなわちオーバーコミットをしている場合)、オーバーコミット率は100%を上回る。
【0033】
図6は本実施形態におけるオーバーコミット率上限DB128の構成例を示す図である。
図6にて例示する本実施形態のオーバーコミット率上限DB128は、運用管理対象システム1において許容するオーバーコミット率の上限値を格納したデータベースである。このオーバーコミット率上限DB128のうち、CPUフィールド831の値は、CPUのオーバーコミット率の上限値を表し、またメモリフィールド823の値はメモリのオーバーコミット率の上限値を表す。こうしたオーバーコミット率上限DB128は、運用管理者が許容出来るコストや性能安定性などの要件に応じて事前に決定し、記憶装置101に格納しておくものとする。
【0034】
図7は本実施形態における稼働履歴DB129の構成例を示す図である。
図7にて例示する本実施形態の稼働履歴DB129は、各ホストに関して、該当ホスト上における各VMにより使用されたリソース量の情報を格納したデータベースである。すなわち、
図7で例示する稼働履歴DB129の各レコードは、該当ホストについての、過去のある時刻におけるCPUおよびメモリといった各リソースの使用量実績を表している。
【0035】
このうち時刻フィールド901の値は、対象とする時刻を表す。また、CPU使用量フィールド902の値は、該当時刻に該当ホスト上の各VMで使用されたCPUのリソース量の合計値である。また、メモリフィールド903の値は、該当時刻に該当ホスト上の各VMで使用されたメモリのリソース量の合計値である。
【0036】
図8は本実施形態におけるリソース使用量予測DB130の構成例を示す図である。
図7にて例示する本実施形態のリソース使用量予測DB130は、上述の稼働履歴DB129のデータに基づいて、運用管理サーバ100が所定アルゴリズムによって生成した、各ホストにおけるリソース使用量の予測値を格納したデータベースである。すなわち、
図8で例示するリソース使用量予測DB130の各レコードは、該当ホストについての、将来のある時刻におけるCPUおよびメモリといった各リソースの使用量予測値を表している
。
【0037】
このうち時刻フィールド911の値は、対象とする時刻を表す。また、CPU使用量フィールド912の値は、該当時刻に該当ホスト上の各VMで使用されるであろうCPUのリソース量の合計値である。また、メモリフィールド913の値は、該当時刻に該当ホスト上の各VMで使用されるであろうメモリのリソース量の合計値である。こうしたリソース使用量予測DB130の生成については後述する。
【0038】
−−−リソース予約処理の例−−−
以下、本実施形態における仮想マシン運用支援方法の実際手順について図に基づき説明する。以下で説明する仮想マシン運用支援方法に対応する各種動作は、仮想マシン運用支援システムたる上述の運用管理サーバ100がメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【0039】
図9は、本実施形態における仮想マシン運用支援方法の処理手順例1を示すフロー図である。ここで、本実施形態の操作端末200を操作するユーザとしては、アプリケーション管理者とインフラ管理者の2種類の管理者が存在するものとする。このうちアプリケーション管理者は、VM上で稼働するアプリケーションに対する運用管理の操作を行うユーザである。一方、インフラ管理者は、ホストやネットワークなどのインフラの管理を行うユーザである。この
図9で例示するフローで運用管理サーバ100との間でデータ授受を行う操作端末200は、上述のユーザのうち、VMに関してリソース予約を希望するアプリケーション管理者が操作するものとする。すなわち、アプリケーション管理者によるリソース予約に伴う処理手順が
図9のフローとなる。
【0040】
この場合、操作端末200は、所定のVMに関するリソース予約要求をアプリケーション管理者から受け付け、これをネットワーク11を介して運用管理サーバ100に送信する(S411)。
【0041】
一方、運用管理サーバ100は、ネットワーク11を介して上述のリソース予約要求を受信し、これに伴って後述するリソース予約処理を実行し(S412)、当該予約処理の結果を操作端末200に返信して(S413)、処理を終了する。運用管理サーバ100において、このリソース予約処理を実行するのはリソース予約処理部110である。
【0042】
ここで、上述のステップS412、すなわちリソース予約処理の詳細について説明する。
図10は本実施形態における仮想マシン運用支援方法の処理手順例2を示すフロー図であり、具体的には、運用管理サーバ100におけるリソース予約処理の詳細を示すフロー図となる。
【0043】
この場合まず、運用管理サーバ100のリソース予約処理部110は、アプリケーション管理者の指示を受けた操作端末200から、リソース予約要求を受信する(S501)。ここで受信したリソース予約要求には、VMに関してリソースを確保したい予約期間に対応した予約開始時刻および予約終了時刻と、確保したいリソース量を示す割当てリソース量(例えば、CPUコア数、CPU周波数、メモリ)の各情報が少なくとも含まれている。
【0044】
次に、運用管理サーバ100のリソース予約処理部110は、運用管理対象システム1に含まれる全ホストの情報をホスト管理情報DB126から読み出し、各ホストに対して、以下のステップS503からステップS506に至る一連の各処理を実行する(S502)。
【0045】
このうちステップS503において、リソース予約処理部110は、上述のステップS502で情報を読み出したホストのうち、例えばホストのID(例:
図4のホスト管理情報DB126におけるホストフィールド811の値)の昇順で1つ選択した処理対象ホストについて、割当て予定リソース量DB127にて各レコードを参照し、上述の予約期間に時刻フィールド821の時刻が含まれる各レコードから、割当てリソース量フィールド822の各値を抽出する(S503)。
【0046】
また、ステップS504において、リソース予約処理部110は、上述のステップS503で抽出した(他の各VMに対する)割当て予定リソース量(例えば、CPU:12GHz、メモリ:10GB)に、(今次、リソース割当てを想定しているVMに関して)上述のリソース予約要求が示す割当てリソース量(例えば、CPU:20GHz、メモリ:20GB)を更に加えた総リソース量(例えば、CPU:32GHz、メモリ:20GB)を、上述の処理対象ホストが全て担って各VMを稼働させた場合、予約期間におけるオーバーコミット率が上限値(
図6のオーバーコミット率上限DB128の示す値。例えば、CPU:400%、メモリ:100%)を超えないか判定する(S504)。
【0047】
この判定の結果、上述の総リソース量がオーバーコミット率上限値を超える場合(S504:No)、リソース予約処理部110は、処理対象ホストに対する処理を終了し、処理をステップS502に戻して、未処理の次のホストに対する処理を実行する。
【0048】
一方、上述の判定の結果、総リソース量がオーバーコミット率上限値を超えない場合(S504:Yes)、リソース予約処理部110は処理をステップS505に進める。
【0049】
このステップS505において、リソース予約処理部110は、上述の予約期間における平均リソース割当て予定量を計算する。ここで平均リソース割当て予定量とは、予約期間に関してステップS504で得た総リソース量の時間平均である。例えば、総リソース量が、CPU:32GHz、メモリ:20GBで、予約期間が2時間であった場合、平均リソース割当て予定量は、CPU:16GHz/時間、メモリ:10GB/時間、となる。
【0050】
続いてステップS506において、リソース予約処理部110は、上述のステップS505まで処理対象とした処理対象ホストのIDと、ステップS505で求めた平均リソース割当て予定量の各情報を、配置先候補ホストとしてメモリ103上に保存する。
【0051】
以上のステップS503からS506の各処理が、全ホストに対して完了した場合(S507)、リソース予約処理部110は、処理をS508に進める。
【0052】
ステップS508において、リソース予約処理部110は、メモリ103において配置先候補ホストの情報有無を判定する。この判定の結果、メモリ103に配置先候補ホストの情報が存在しない場合(S508:No)、リソース予約処理部110は、処理をステップS512に進めて、予約失敗の旨を示すメッセージを操作端末200に送信し、処理を終了する。他方、上述の判定の結果、メモリ103に配置先候補ホストの情報が存在する場合(S508:Yes)、リソース予約処理部110は、処理をS509に進める。
【0053】
ステップS509において、リソース予約処理部110は、メモリ103に情報を保持する配置先候補ホストの中で、ステップS505で求めた平均リソース割当て予定量が最も小さいホストを、今次のVMに関して配置先ホストに決定する。
【0054】
続いてステップS510において、リソース予約処理部110は、ステップS501で
受けた今回のリソース予約要求が示す予約情報を、VM管理情報DB125にてレコードを生成して追加する。また、リソース予約処理部110は、割当て予定リソース量DB127において、該当ホストに関するレコードのうち、上述の予約期間に対応した時刻821のレコードに対して、上述のリソース予約要求が示す割当てリソース量(CPUコア数とCPU周波数の乗算値と、メモリの値)を割当てリソース量822の値に加算し、修正する。
【0055】
またステップS511において、リソース予約処理部110は、ここまでの処理結果、すなわち予約結果として、予約成功の旨を示すメッセージを操作端末200に送信し、処理を終了する。
【0056】
−−−VM移動に伴う処理の例−−−
次に、VM配置最適化の処理に伴うフローについて図に基づき説明する。
図11は、本実施形態における仮想マシン運用支援方法の処理手順例3を示すフロー図である。この場合、操作端末200は、インフラ管理者からのリソース使用量の予測要求を受け付けて、これをネットワーク11を介して、運用管理サーバに送信する(S421)。この処理は、例えば、所定時間毎に操作端末200が自動実行するとしてもよいし、運用管理対象システム1におけるホスト間での負荷偏在のアラートが、運用管理サーバ100から通知されたことを認識したインフラ管理者からの指示によって開始されるとしてもよく、処理のトリガーについては限定しない。
【0057】
一方、運用管理サーバ100は、上述の予測要求の受信に伴ってリソース使用量の予測処理を実行し(S422)、この予測結果を操作端末200に返信する(S423)。このリソース使用量の予測処理の詳細は後述する。
【0058】
他方、インフラ管理者は、上述の運用管理サーバ100からのリソース使用量の予測結果を操作端末200で閲覧し、運用管理対象システム1の各ホストのうちリソース不足発生が予想されるホストの有無を確認する。これにより、リソース不足発生が予想されるホストの存在を認識した場合、このインフラ管理者は、そのリソース不足発生前に、ライブマイグレーション技術を用いて該当ホストの所定VMを他ホストに移動させることで、負荷平準化を図り、リソース不足発生を未然に防ぐ。
【0059】
こうしたインフラ管理者は、上述のステップS423にて操作端末200が受信した予測結果を参照し、移動対象とするVMと移動させる時間を判断する。こうした判断結果を入力装置等で受けた操作端末200は、これをネットワーク11を介して運用管理サーバ100に送信する(S424)。
【0060】
一方、運用管理サーバ100は、操作端末200から受信した判断結果が示す、移動対象のVMおよび移動時間に基づき、該当VMの移動先候補となるホストの評価を行い(S425)、この評価結果を操作端末200に送信する(S426)。
【0061】
他方、操作端末200は、運用管理サーバ100から上述の評価結果を受信して、ディスプレイ等の表示装置に出力し、インフラ管理者の閲覧に供する。この場合、インフラ管理者は、操作端末200が受信した評価結果を閲覧して、VM移動先のホストを決定し、該当VMの移動予約の要求を操作端末200に入力する。これを受けた操作端末200は、該当VMの移動予約の要求を運用管理サーバ100に送信する(S427)。
【0062】
この場合、運用管理サーバ100は、操作端末200から受信したVM移動の予約要求に基づき、既に述べたライブマイグレーション等の既存技術を適宜に利用したVM移動の予約処理を行う(S428)。
【0063】
ここで、上述のステップS422、すなわちリソース使用量予測の処理の詳細について、説明する。
図12は、本実施形態における仮想マシン運用支援方法の処理手順例4を示すフロー図であり、具体的には、運用管理サーバ100におけるリソース使用量予測部111による処理を示すフロー図である。
【0064】
この場合まず、運用管理サーバ100のリソース使用量予測部111は、操作端末200から、インフラ管理者による予測要求を受信する(S601)。
【0065】
次に、リソース使用量予測部111は、運用管理対象システム1に含まれる全ホストに対して、以下のステップS603からすなわちS604に至る一連の各処理を実行する(S602)。この場合のホストの選択方法については、
図10で例示した形態と同様である。
【0066】
このうちステップS603において、リソース使用量予測部111は、稼働履歴DB129の格納情報のうち対象ホストに関するレコードを抽出し、該当レコードが示す稼働履歴情報を、所定の予測アルゴリズムに適用することで、対象ホストにおける、現時点から所定未来の将来までの予測期間のリソース使用量を予測し、この予測結果をリソース使用量予測DB130に格納する。こうしたリソース使用量予測に採用する上述のアルゴリズムとしては、例えば、SARIMA(Seasonal Auto Regressive Integrated Moving Average)モデルや、Holt−Winters法など、時系列データ分析において一般的に用いられている手法に対応したアルゴリズムを用いるとすればよい。
【0067】
続いて、ステップS604において、リソース使用量予測部111は、上述のステップS603で予測対象とした予測期間に、稼働時間フィールド804の開始時刻、終了時刻が含まれるレコードを、VM管理情報DB125から抽出し、該当レコードが示す割当てリソース量805の値に基づいて、リソース使用量の予測値に関する補正処理を実行する。この補正処理は、上述の予測期間にて、リソース割当て停止が予定されているVMの存在がVM管理情報DB125のレコードから特定できた場合に、その割当て停止分のリソース使用量を予測値から差し引き、リソース使用量予測DB130の該当レコードを更新する。また、上述の予測期間にて、リソース割当てが開始される、すなわち稼働開始予定のVMの存在がVM管理情報DB125のレコードから特定出来た場合に、その割当て開始分のリソース使用量を予測値に加算し、リソース使用量予測DB130の該当レコードを更新する。
【0068】
全ホストに対して、上述のステップS603からステップS604の各処理が完了した場合(S605)、リソース使用量予測部111は、処理をステップS606に進める。
【0069】
ステップS606
から開始されるループにおいて、リソース使用量予測部111は、ホスト管理情報DB126が示す各ホストのラック812の情報(
図4では図示していないが、ラックにおける配置位置も含むものとする)に基づき、各ホストのIDを各ラックの物理的な棚構成に応じたマトリクス(記憶装置101に予め保持する描画データ)の該当区画に配置し、ヒートマップキャンバスを生成する
(S607)。
図14に、このステップS60
7にてリソース使用量予測部111が生成するヒートマップキャンバス1010の具体例を示す。
【0070】
図14に例示するヒートマップキャンバス1010において、マトリクス中の1つのマスが1つのホストを表し、マスの中に記載された文字列が当該ホストのIDを表している。また、太線はラックの範囲を表す。
図14に例示するヒートマップキャンバス1010の例では、例えばIDが「H01」〜「H08」であるホストが、同一のラック内に格納
されている例を示している。
【0071】
続いてリソース使用量予測部111は、予測期間の日数分だけ、上述のステップS60
7の処理を繰り返し、日数分のヒートマップキャンバス1010を生成する
。ここでは、予測期間が7日である場合を例に取り説明する。そのため、上述のステップS60
7の処理を1日目から7日目まで7回繰り返し、7枚のヒートマップキャンバス1010が生成されるものとする。
【0072】
次にステップS608において、リソース使用量予測部111は、上述のステップS60
7で生成した各ヒートマップキャンバス1010の各マスに対し、ステップS604を経て得ている各ホストに関するリソース使用量予測値の大きさに応じた所定色を選択的に付与し、ヒートマップ1020を生成する。
図15に、このステップS608で生成したヒートマップ1020の具体例を示す。
【0073】
この場合、リソース使用量予測部111は、運用管理対象システム1に含まれる各ホストに関して、ヒートマップ1020が対象とする日付におけるリソース使用量予測値の平均値を算定し、この平均値の大きさに応じて予め定めてある色を選択する。例えば、リソース使用量予測値が第1基準値より大きい場合は「赤色」、第1基準値と第2基準値の間に属する場合は「黄色」、第2基準値より小さい場合は「青」、を選択する。
【0074】
続いてステップS610において、リソース使用量予測部111は、上述のステップS60
6からステップS609で生成した、予測期間の日数分のヒートマップ1020を画面表示する表示用データを生成し、これを予測結果として操作端末200に送信する。
図16に、このステップS610で生成した画面データの例を示す。
図16の画面データ例では、操作端末200のインターフェイスを介してインフラ管理者が操作したタイムスライダー1032によって指定される、所定日のヒートマップ1031を画面中央部に表示した形態を示している。このように、複数日に渡るヒートマップを1画面中において連続的かつ特定可能に表示することで、これを閲覧したインフラ管理者は、リソース使用量が増大する日付およびホストを容易に特定することが可能になる。
【0075】
次に、運用管理サーバ100の移動先候補評価部112による処理、すなわち上述のステップS425の処理について説明する。
図13は、本実施形態における仮想マシン運用支援方法の処理手順例5を示すフロー図である。
【0076】
この場合、インフラ管理者は、上述のステップS423において提示された予測結果を操作端末200にて参照し、移動対象とするVMおよび移動時刻を決定しているものとする。一方、この決定事項を入力装置で受けた操作端末200は、上述のステップS424において、移動対象のVMおよび移動時刻の各情報を運用管理サーバ100に送信することとなる。
【0077】
他方、運用管理サーバ100の移動先候補評価部112は、操作端末200を介してインフラ管理者から指定された移動対象VMおよび移動開始時間の情報を受信し(S701)、これに応じて、VM管理情報DB125において移動対象VMに関するレコードを抽出し、該当レコードが含む情報を取得する(S702)。具体的には、移動対象VMに関する割当てリソース量805および稼働時間804の終了時刻の各値を取得し、これをメモリ103に格納する。
【0078】
次に、移動先候補評価部112は、運用管理対象システム1に含まれる全ホストに対して、以下のステップS704からすなわちS708に至る一連の各処理を実行して、上述の移動対象VMの移行先のホストとしての適性評価を行う(S703)。処理対象すなわ
ち評価対象ホストの選択手法は上述の各フローにて述べたものと同様である。
【0079】
このうちステップS704において、移動先候補評価部112は、リソース使用量予測DB130から、以降の処理で使用する時系列データとして、ステップS701で受信した移動開始時間から、ステップS702において取得した稼働時間の終了時刻に至る間の、一連のリソース使用量予測値(該当時刻に関するCPU使用量912、メモリ913の各値)を抽出する。
【0080】
次にステップS705において、移動先候補評価部112は、ホスト管理情報DB126を参照し、評価対象ホストのキャパシティ813の各値を取得する。
【0081】
またステップ
s706において、移動先候補評価部112は、評価対象ホストにおけるリソース量の余裕度を算定する。この余裕度は、上述の移動開始時間から稼働終了時刻までの時系列データが示すリソース使用量予測値に対し、該当ホストのキャパシティの値がどれほど大きいかを示すものなる。
【0082】
ここで、ステップS705にて取得した評価対象ホストのキャパシティC、ステップS702で取得した割当てリソース量R、および、ステップS704で抽出した時刻iのリソース使用量予測データP
iによって、時刻iにおける余裕度S
iを以下の数1に示す式で定義出来る。
S
i=C−R−P
i ・・・数1
【0083】
余裕度S
iが正の値である時間帯は、移動してくるVMに対して十分なリソースを割当てることができる見込みであることを表し、この値が大きいほどその確度が高い。逆に、余裕度S
iが負の値である時間帯は、移動してくるVMに対して十分なリソースを割当てることができない見込みであることを表す。移動先候補評価部112は、評価対象期間における余裕度の積算値Σ
iS
iを算定し、これを対象ホストの余裕度の評価値とする(S707)。
【0084】
次にステップS708において、移動先候補評価部112は、リソースを確保できる時間の連続性Dに対する評価を行う。この連続性Dは、次のようにして求める。
【0085】
・S
O≧0の場合、最初にS
O<0となる時刻をDとする。
【0086】
・S
O<0の場合、最初にS
O≧0となる時刻をDとする。
【0087】
上述の連続性Dの値が大きいと、リソースが確保できる(もしくは確保できない)時間が長期間続く見込みであることを表す。逆に、連続性Dの値が小さいと、リソースを確保できる(もしくは確保できない)時間が長く続かない見込みであることを表す。
【0088】
こうしたステップS703からステップS709の一連の各処理により、全ホストに対する評価を実施した後(S709)、移動先候補評価部112は、処理をステップS710に進め、評価結果を表示する画面データを作成し、これを操作端末200に送信する。
図17に、このステップS710により生成する画面データの例を示す。ここでは、ステップS606で作成したヒートマップキャンバス1010に対して、ステップS707で求めた余裕度およびステップS708で求めた連続性に基づき色づけを行うことで、ヒートマップ1040を作成し、これを画面データに含めた形態を示した。
【0089】
このヒートマップ1040は、ヒートマップキャンバス1010の各マスに対して、該当ホストに関して得ている余裕度の大きさに応じて色を選択し、設定したものとなる。移
動先候補評価部112は、例えば、余裕度が第1基準より大きい場合は「青色」、第1基準より小さく第2基準より大きい場合は「黄色」、第2基準より小さい場合は「赤色」などと色の選択動作を行う。さらに移動先候補評価部112は、各ホストに関して得ている連続性に応じて、該当マスの設定した各色の濃さを決定する。この場合、移動先候補評価部112は、例えば、連続性が所定基準より高くなるほど該当色を濃くし、連続性が所定基準より低くなるほど該当色を薄くする。
【0090】
このように、余裕度および連続性を示すヒートマップ1040を生成し、これを操作端末200に送信して表示させることで、これを閲覧したインフラ管理者は、移動先ホストの選択作業時に、上述の連続性および余裕度に高さに応じて移動先ホストを選択すればよく、こうした作業の負荷を大きく低減することができる。
【0091】
図17で例示したヒートマップ1040の例では、インフラ管理者が操作端末200から指定してきた移動対象VMを、移動先候補評価部112が丸印1041のアイコンとして画面表示している。移動対象VMを示す丸印1101は、VMが稼働しているホストを表すマスの中に表示している。前述した通り、ヒートマップ1040における太線はラックを表す。これにより、インフラ管理者は、移動対象VMと、移動対象VMを含むホストおよびラック、同ラック内に含まれるホストを容易に特定することができる。そのため、ネットワーク性能などを考慮して同ラック内で移動を行いたい場合は、容易に移動先ホストを絞り込むことができる。
図17の例では、移動対象VMがホスト「H32」上で稼働しており、同ラック内にはホスト「H31」〜「H38」が存在することが容易に分かる。
【0092】
さらに、前述した通りヒートマップ1040上の色が移動先ホストの評価結果を表している。リソースの余裕度を色で、連続性を色の濃さで表現しているため、インフラ管理者は、移動先として長時間に渡りリソースに余裕があるホストを選びたい場合、濃い青で表示されているホストを探せばよい。
【0093】
このようにして、インフラ管理者は、運用管理サーバ100から送信された評価結果を操作端末200にて参照して移動先ホストを選定し、その選定結果を操作端末200を介して運用管理サーバ100に送信する。
【0094】
運用管理サーバは、操作端末200から指示された移動先ホストへの移動対象VMの移動処理の予約を行い、該当予約で指定された時刻になるとVM移動を実行する。このVM移動は既に述べたライブマイグレーションを採用して実行すればよい。
【0095】
以上で述べた処理により、負荷平準化のためのVM移動における移動先ホストを、リソースの余裕度および連続性の観点から評価し、その結果をユーザに提示することができる。こうした評価結果を認識したユーザは、移動対象VMの移動先ホストの選択に関わる作業負荷を軽減することができる。また、連続性と余裕度を考慮した評価結果に基づいて移動先ホストを決定できるため、長期に渡りリソースに余裕があるホストを効率的かつ的確に選択することが可能となり、VM移動が頻繁に発生することを抑え、性能を安定化させることが可能となる。
【0096】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【0097】
こうした本実施形態によれば、仮想マシンにおける性能安定化を効率的に実現できる。
【0098】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態
の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報を少なくとも保持しており、前記演算装置は、前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、各判定により各物理サーバに関して得た前記余裕度および前記連続性の各情報を所定装置に表示する処理を実行するものである、としてもよい。
【0099】
これによれば、仮想マシンの移動先となる物理サーバについて、該当仮想マシンに必要なリソースを確保可能な時間の連続性と共に、その際の余裕度も更に踏まえた情報を、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は、仮想マシンの移動検討時点のみならず、移動後から所定期間の将来について必要なリソースを余裕を持って連続的に確保出来るか否かを容易かつ確実に認識して、仮想マシン移動先とその可否について的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。
【0100】
また、本実施形態の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報を少なくとも保持しており、前記演算装置は、前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するものであるとしてもよい。
【0101】
これによれば、過去の履歴に基づき精度良く予測されたリソース使用量を踏まえた上述の連続性を、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は仮想マシン移動先とその可否について更に的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。
【0102】
また、本実施形態の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報と、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報とを少なくとも保持しており、前記演算装置は、前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値に対し、前記予約情報が示す、該当物理サーバの該当時期における各仮想マシンによるリソースの使用有無の情報を適用して補正を実行し、当該補正後の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するものであるとしてもよい。
【0103】
これによれば、過去の履歴に基づき更に精度良く予測されたリソース使用量を踏まえた上述の連続性を、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は仮想マシン移動先とその可否について更に的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。
【0104】
また、本実施形態の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理
サーバに関する情報として、所定空間における各物理サーバの配置位置を示す表示用オブジェクトを少なくとも保持しており、前記演算装置は、前記連続性の情報を所定装置に表示する処理に際し、前記表示用データを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低に応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するものであるとしてもよい。
【0105】
これによれば、各物理サーバにおける上述の連続性を視覚的に認識容易な形態で、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は仮想マシン移動先とその可否について更に効率的かつ的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。
【0106】
また、本実施形態の仮想マシン運用支援システムにおいて、前記記憶装置は、前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報と、所定空間における各物理サーバの配置位置を示す表示用オブジェクトと、を少なくとも保持しており、前記演算装置は、前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、前記連続性の情報を所定装置に表示する処理に際し、前記表示用オブジェクトを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低および前記余裕度の情報が示す余裕度高低のそれぞれに応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するものであるとしてもよい。
【0107】
これによれば、各物理サーバにおける上述の連続性および余裕度を視覚的に認識容易な形態で、仮想マシンの運用担当者等に提示することが出来る。これを閲覧した運用担当者等は仮想マシン移動先とその可否について更に効率的かつ的確に判断することが可能となる。ひいては、仮想マシンにおける性能安定化を効率的に実現できる。
【0108】
また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記記憶装置において、前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報を少なくとも保持しており、前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、各判定により各物理サーバに関して得た前記余裕度および前記連続性の各情報を所定装置に表示する処理を実行するとしてもよい。
【0109】
また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記記憶装置において、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報を少なくとも保持しており、前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するとしてもよい。
【0110】
また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記
記憶装置において、前記物理サーバに関する情報として、過去のリソース使用量の履歴情報と、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報とを少なくとも保持しており、前記連続性を判定するに際し、前記記憶装置で保持する過去のリソース使用量の履歴情報を所定のアルゴリズムに適用して、前記所定時期以降の将来のリソース使用量の予測を各物理サーバに関して実行し、当該予測で得た、各物理サーバにおける将来のリソース使用量の予測値に対し、前記予約情報が示す、該当物理サーバの該当時期における各仮想マシンによるリソースの使用有無の情報を適用して補正を実行し、当該補正後の予測値と、前記所定仮想マシンが前記所定時期に要するリソースの情報とに基づき、各物理サーバについて、前記所定仮想マシン向けに前記所定時期から将来に亘って該当リソースを確保可能な時間の連続性を所定アルゴリズムにて判定するとしてもよい。
【0111】
また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記記憶装置において、前記物理サーバに関する情報として、所定空間における各物理サーバの配置位置を示す表示用オブジェクトを少なくとも保持しており、前記連続性の情報を所定装置に表示する処理に際し、前記表示用データを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低に応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するとしてもよい。
【0112】
また、本実施形態の仮想マシン運用支援方法において、前記情報処理システムが、前記記憶装置において、前記物理サーバに関する情報として、各仮想マシンに関して時期毎に割当て済みのリソースの予約情報と、所定空間における各物理サーバの配置位置を示す表示用オブジェクトと、を少なくとも保持しており、前記連続性の判定に際し、前記所定仮想マシンが所定時期に要する前記リソースの情報と、前記記憶装置が保持する各物理サーバに関する時期毎の前記予約情報とに基づき、各物理サーバにおける、前記所定仮想マシン向けに確保すべきリソースの余裕度を所定アルゴリズムで判定する処理を更に実行し、前記連続性の情報を所定装置に表示する処理に際し、前記表示用オブジェクトを記憶装置より読み出し、当該表示用オブジェクトにおける各物理サーバ用の領域について、該当物理サーバに関する前記連続性の情報が示す連続性高低および前記余裕度の情報が示す余裕度高低のそれぞれに応じて表示形態を設定し、当該設定後の表示用オブジェクトを前記所定装置に出力するとしてもよい。