JP2019028673A - 管理装置および管理方法 - Google Patents

Abstract

【課題】トラフィック分散先のデータセンタのリソースを容易かつ効率よく運用する。【解決手段】収集部１５ａが、ＶＭの負荷情報を収集し、決定部１５ｂが、収集された負荷情報を用いて、増設対象のＶＭと増設先のホストとを決定し、指示部１５ｃが、決定された増設対象のＶＭの増設先のホストでの複製を指示する。収集部１５ａは、ＶＭのハードウェアリソースの情報と、該ＶＭのゲストＯＳ以上のリソースの情報とを含む負荷情報を収集する。収集部１５ａは、各ＶＭに関する負荷情報と、ＶＭの仮想化環境に関する負荷情報とを含む負荷情報を収集し、決定部１５ｂは、ＶＭに関する負荷を用いて増設対象のＶＭを決定し、仮想化環境に関する負荷情報を用いて増設先のホストを決定する。決定部１５ｂは、収集された負荷情報を用いて、さらに、減設対象の仮想マシンを決定し、指示部１５ｃは、決定された減設対象のＶＭの削除を指示する。【選択図】図４

Description

本発明は、管理装置および管理方法に関する。

近年、ＩｏＴデバイスの増大や将来の５Ｇネットワークを見据え、ユーザの利用するＩｏＴデバイスの近傍にエッジサーバを分散させてＩｏＴデバイスとエッジサーバとの間の低遅延化を図る、エッジコンピューティングと呼ばれる技術が検討されている。サーバが都心部に集中配備される従来のクラウドコンピューティングに対し、エッジサーバが各地域に分散配備されるエッジコンピューティングにおいては、各地域のリソースを小規模にすることでトータルコストを抑えている。

ここで、各地域のＩｏＴデバイスからのトラフィックは、コンサート等のイベント開催時、災害発生に伴う救助ロボット出動時、あるいは帰省する人が増える時期等には、通常時の平均値から大きく変動することが想定される。そのようなトラフィック変動に対応するため、ピークトラフィックを前提としてリソース設計を行えば、トータルコストが増大する。一方、平均トラフィックを前提としたリソース設計では、ピークトラフィックの処理を行えない。

そこで、トータルコストを抑えてピークトラフィックの処理を可能とするため、トラフィックを分散させるトラフィックのオフロード技術が必要になる。トラフィックのオフロード技術として、ＤＷＳ（Dynamic Workload Scaling）と呼ばれる技術が知られている（非特許文献１参照）。ＤＷＳによれば、仮想化管理システムが監視するデータセンタ（以下、ＤＣとも記す）内の仮想マシン（以下、ＶＭと記す）の負荷が所定の閾値を超過した場合に、ロードバランサ（以下、ＬＢとも記す）が、別のＤＣにトラフィックを分散させる。その際、分散先のＤＣに、当該トラフィックを処理するＶＭと同一のＶＭが事前に増設されている必要がある。

"Cisco ACE：VMwareと協調して動作する仮想サーバ ロード バランサ"、[online]、２０１１年、シスコ、［２０１７年６月２１日検索]、インターネット＜URL:http://www.cisco.com/c/ja_jp/about/newsroom/technology-commentary/tech-2011/load-balancing-with-vmware.html＞

しかしながら、従来の技術では、分散先ＤＣにおいてリソースを効率よく運用することが困難であった。具体的には、従来のＤＷＳでは、高負荷になるＶＭは、トラフィックや他のＶＭとの競合に依るため、特定が困難であり、分散先のＤＣに全ＶＭの増設が必要であった。

一方、エッジコンピューティングにおいては、ＩｏＴデバイスがターゲットであるため、ＶＭで処理される内容は業界毎、事業者毎、あるいはデバイス毎等に異なり、多種多様である。したがって、ＶＭのサーバアプリケーション、ミドルウェア、リソース等の構成も管理者も様々に異なり、ＶＭ数が膨大になることが想定される。

その場合に、ＤＷＳでは分散先ＤＣにおけるＶＭの集中は考慮されていない。例えば、分散先ＤＣを都心部ＤＣに１極集中させる場合には、都心部ＤＣには、既設ＶＭに加え、各地域ＤＣから分散される増設ＶＭが加わるため、ＶＭが集中してしまうおそれがある。また、分散先ＤＣを他地域ＤＣに分散させる場合にも同様に、分散先の他地域ＤＣには、既設ＶＭに加え、分散させる増設ＶＭが加わるため、ＶＭが集中するおそれがある。いずれにしても、ハイパーバイザのＶＭの上限数超過、ＶＭ間のリソース競合や性能劣化等のリソースの問題が発生するおそれがある。

また、過去の負荷情報を参照して増設するＶＭを特定し、運用者が手動で増設することによりＶＭ数の増大を回避する場合には、運用者の負担が大きいだけでなく、ＶＭ増設が遅れてトラフィックが分散されないおそれがある。

本発明は、上記に鑑みてなされたものであって、トラフィック分散先のデータセンタのリソースを容易かつ効率よく運用することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る管理装置は、仮想マシンの負荷情報を収集する収集部と、収集された前記負荷情報を用いて、増設対象の仮想マシンと増設先のホストとを決定する決定部と、決定された前記増設対象の仮想マシンの前記増設先のホストでの複製を指示する指示部と、を備えることを特徴とする。

本発明によれば、トラフィック分散先のデータセンタのリソースを容易かつ効率よく運用することができる。

図１は、本実施形態に係る管理装置を含むシステムの概略構成を例示する模式図である。 図２は、ロードバランサを説明するための説明図である。 図３は、管理装置の処理概要を説明するための説明図である。 図４は、管理装置の概略構成を例示する模式図である。 図５は、閾値情報のデータ構成を例示する図である。 図６は、管理処理手順を示すシーケンス図である。 図７は、管理処理手順を示すシーケンス図である。 図８は、対象ＶＭ決定処理手順を示すフローチャートである。 図９は、管理処理の効果を説明するための説明図である。 図１０は、管理プログラムを実行するコンピュータを例示する図である。

以下、図面を参照して、本発明の一実施形態を詳細に説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

［システムの概要］
図１は、本実施形態に係る管理装置を含むシステムの概略構成を例示する模式図である。図１に例示するように、システム１は、ＩｏＴデバイス２がアクセス網を介してアクセスするＶＭ３と、ＶＭ３を管理する仮想化管理システム４と、ロードバランサ５と、オペレーションシステム（ＯｐＳ）６と、管理装置１０とを含む。

ここで、ＶＭ３は、ＤＣ７内に設置されたホスト上に構築される。すなわち、各ホストのハードウェア（ＨＷ）上にインストールされたホストＯＳ上のハイパーバイザにより複数のゲストＯＳが生成され、各ゲストＯＳ上にＶＭ３が構築される。

仮想化管理システム４は、各ＤＣ７内に構築されたＶＭ３を管理する。具体的には、仮想化管理システム４は、ホストのＣＰＵ使用率等のハードウェアリソースの負荷を監視している。また、仮想化管理システム４は、各ＶＭのイメージファイルを管理している。また、ＯｐＳ６は、運用中のシステム１の全体を監視している。

また、図２は、ロードバランサ５を説明するための説明図である。図２に例示するように、ロードバランサ５は、ＶＭ３にアクセスするトラフィックを受信した際等に、仮想化管理システム４が監視するＶＭ３の負荷を確認し、ＶＭ３の負荷が所定の閾値を超過していた場合に、分散先ＤＣのＶＭ３にトラフィックを分散させる。

また、図３は、管理装置１０の処理概要を説明するための説明図である。図３に例示するように、管理装置１０は、後述する管理処理を実行し、ロードバランサ５の分散先とするＤＣ７にＶＭ３を増設する。具体的には、管理装置１０は、仮想化管理システム４からＤＣ７内のＶＭ３およびハイパーバイザ等の仮想化環境の負荷情報を収集し、ＶＭ３の負荷情報を用いて増設対象のＶＭ３を決定し、仮想化環境の負荷情報を用いて分散先ＤＣを決定する。

そして、管理装置１０は、決定したＶＭ３の複製を仮想化管理システム４に指示する。また、管理装置１０は、ロードバランサ５に分散先として増設されたＶＭ３の登録を指示する。また、管理装置１０は、ＯｐＳ６に監視対象として増設されたＶＭ３の登録を指示する。

［管理装置の構成］
図４は、管理装置１０の概略構成を例示する模式図である。図４に例示するように、管理装置１０は、ワークステーションやパソコン等の汎用コンピュータで実現され、入力部１１と出力部１２と通信制御部１３と、記憶部１４と、制御部１５とを備える。

入力部１１は、キーボードやマウス等の入力デバイスを用いて実現され、操作者による入力操作に対応して、制御部１５に対して各種指示情報を入力する。出力部１２は、液晶ディスプレイなどの表示装置、プリンター等の印刷装置、情報通信装置等によって実現され、例えば、後述する管理処理の結果等を操作者に対して出力する。

通信制御部１３は、ＮＩＣ（Network Interface Card）等で実現され、ＬＡＮ（Local Area Network）やインターネットなどの電気通信回線を介したサーバ等の外部の装置と制御部１５との通信を制御する。

記憶部１４は、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１４には、管理装置１０を動作させる処理プログラムや、処理プログラムの実行中に使用されるデータなどが予め記憶され、あるいは処理の都度一時的に記憶される。また、この記憶部１４は、通信制御部１３を介して制御部１５と通信する構成でもよい。

本実施形態において、記憶部１４は、閾値情報１４ａを含む。ここで、図５は、閾値情報１４ａのデータ構成を例示する図である。閾値情報１４ａは、後述する管理処理において、ＶＭ３を増設対象または減設対象として決定する際の閾値を表し、設定された閾値の範囲に合致したＶＭ３が増設対象または減設対象として決定される。閾値情報１４ａは、図５に例示するように、閾値、合致回数、処理条件、および対象ＶＭを含む。

閾値は、ＶＭ３ごとに、あるいは全ＶＭ３に対して共通に、複数の条件を組み合わせて設定可能である。例えば、ＣＰＵ使用率、メモリ使用率、またはスレッド数等の条件をＯＲ／ＡＮＤ等の論理条件で指定することができる。ここで、ＣＰＵ使用率、メモリ使用率等のハードウェアリソースの情報は、後述するように、仮想化管理システム４から収集される。また、スレッド数とは、各ＶＭのゲストＯＳ上のプロセス数を表し、ゲストＯＳのＳＮＭＰ（Simple Network Management Protocol）のエージェントから収集される。

また、対象ＶＭとは、該当の閾値が適用されるＶＭ３を意味し、処理条件とは、対象ＶＭが増設対象か減設対象かを表す。また、合致回数とは、設定された閾値の範囲に合致した回数を意味し、ここで指定されている合致回数に達した場合に、対象ＶＭが増設対象または減設対象として決定される。なお、設定された閾値の範囲に連続して合致した回数をカウントするようにしてもよい。

この合致回数は、対象ＶＭの重要度や対象ＶＭにアクセスするトラフィックのバースト性に応じて設定される。例えば、重要度の高いＶＭ３については、少ない合致回数で増設対象として決定するようにして、呼損を抑止することができる。一方、バースト性の高いトラフィックについては、増設対象と決定するまでの合致回数を多くして、オーバーヘッドの増大すなわちリソースの不要な増設を抑止することができる。

同様に、設定される閾値の数値は、対象ＶＭの重要度に応じて設定される。例えば、一般企業用のＶＭ３については、増設対象とする閾値の数値を大きくすることにより、増設ＶＭ数を抑止してリソースコストを抑えることができる。一方、人命にかかわる医療業界のＶＭ３については、増設対象とする閾値の数値を小さくすることにより、リソースコストよりパフォーマンスを優先した増設が可能となる。

図５には、例えば、全てのＶＭ３について（対象ＶＭ：ＡＬＬ）、ＣＰＵ使用率が７０％以上になった場合に（合致回数：１）、増設対象とすることが示されている。また、ＶＭ−１については、ＣＰＵ使用率が７０％以上、かつ（ＡＮＤ）、メモリ使用率が８０％以上になった回数が２回に達した場合に（合致回数：２）、増設対象とすることが示されている。

なお、同一のＶＭ３に対して複数の閾値が設定されている場合には、後述する管理処理において、優先度の高い順に適用される。また、同一のＶＭ３に対して同一の数値を用いて設定され判定不能な複数通りの閾値が設定されている場合には、設定の際にエラー通知が出力されるようにするとよい。例えば、ＣＰＵ使用率７０％以上の場合に増設対象とする閾値と、ＣＰＵ使用率７０％以上の場合に減設対象とする閾値との対象ＶＭに、同一のＶＭ３が含まれている場合が該当する。

図４の説明に戻る。制御部１５は、ＣＰＵ（Central Processing Unit）等の演算処理装置がメモリに記憶された処理プログラムを実行することにより、図４に例示するように、収集部１５ａ、決定部１５ｂ、指示部１５ｃ、設定部１５ｄおよび試験部１５ｅとして機能する。なお、これらの機能部は、それぞれ、あるいは一部が異なるハードウェアに実装されてもよい。例えば、収集部１５ａと決定部１５ｂとは、負荷情報管理装置等の管理装置１０とは異なるハードウェアに実装されてもよい。

収集部１５ａは、ＶＭ３の負荷情報を収集する。具体的には、収集部１５ａは、ＶＭ３のハードウェアリソースの情報と、該ＶＭ３のゲストＯＳ以上のリソースの情報とを含む負荷情報を収集する。

例えば、収集部１５ａは、ＶＭ３のハードウェアリソースの情報として、ＣＰＵ使用率やメモリ使用率等を、仮想化管理システム４から収集する。なお、ＶＭ３から見てハードウェアリソースはＶＭ間で競合すること、またＶＭ数が膨大であることを考慮して、本実施形態では、ＶＭ３のハードウェアリソースの情報を、ゲストＯＳのエージェントではなく、仮想化管理システム４から収集する。

また、収集部１５ａは、ＶＭ３のゲストＯＳ以上のミドルウェア、アプリケーション等のリソースの情報として、例えばゲストＯＳ上のスレッド数を、ゲストＯＳのエージェントから収集する。あるいは、収集部１５ａは、ミドルウェアのリソース情報として、Ｐｏｓｔｇｒｅｓｓｑｌのコネクション数を収集してもよい。Ｐｏｓｔｇｒｅｓｓｑｌのコネクション数とは、ＷｅｂサーバがＤＢサーバに接続する際のコネクション数を表す。また、収集部１５ａは、アプリケーションのリソース情報として、ＶｏＩＰ（Voice over IP）のＳＩＰ（Session Initiation Protocol）サーバの音声チャネル数を収集してもよい。例えば、１通話につき発信チャネルと着信チャネルとの２チャネルを使用すること等はアプリケーションが管理している。

なお、収集部１５ａは、ゲストＯＳ以上のリソースの情報として、ＶＭ３全体でのサービス品質等の情報を収集してもよい。サービス品質として、例えば、ＷｅｂサーバのＨＴＴＰリクエストに対する応答時間が例示される。この応答時間にはアプリケーションだけでなくミドルウェアおよびゲストＯＳの処理時間が関連している。この場合に、応答時間が所定の閾値を超過した場合に、後述する処理においてＶＭ３を増設対象とする。

また、収集部１５ａは、ゲストＯＳ以上のリソースの情報として、エラーログの量を収集してもよい。この場合に、エラーログの量が所定の閾値を超過した場合に、後述する処理においてＶＭ３を増設対象とする。

また、収集部１５ａは、各ＶＭ３に関する負荷情報と、ＶＭ３の仮想化環境に関する負荷情報とを含む負荷情報を収集する。具体的には、収集部１５ａは、各ＶＭ３に関する負荷情報として、上記のとおり、各ＶＭ３のハードウェアリソースの情報と各ＶＭ３のゲストＯＳ以上のリソースの情報とを収集する。また、収集部１５ａは、ＶＭ３の仮想化環境に関する負荷情報として、ＶＭ３が稼働するホストのハイパーバイザ等の仮想化環境ごとに、同一仮想化環境下に構築された全てのＶＭ３に関する負荷情報を収集する。

なお、ＶＭ３の負荷情報の収集頻度は特に限定されず、任意に設定可能である。例えばバースト的に発生する負荷を検知できるように、短い間隔で収集してもよい。

決定部１５ｂは、収集された負荷情報を用いて、増設対象のＶＭ３と増設先のホストとを決定する。具体的には、決定部１５ｂは、ＶＭ３に関する負荷情報を用いて増設対象のＶＭ３を決定し、仮想化環境に関する負荷情報を用いて増設先のＤＣのホストを決定する。

例えば、決定部１５ｂは、各ＶＭ３に関する負荷情報が、閾値情報１４ａに設定されている閾値の範囲に合致した場合に、増設対象のＶＭ３として決定する。本実施形態においては、決定部１５ｂは、負荷情報が所定の閾値の範囲に合致した回数が所定値を超えた場合に、増設対象のＶＭとして決定する。これにより、例えば、重要度の高いＶＭ３については、少ない合致回数で増設対象として決定して、呼損を抑止することができる。一方、バースト性の高いトラフィックについては、増設対象と決定するまでの合致回数を多くして、オーバーヘッドの増大すなわちリソースの不要な増設を抑止してリソースコストを抑えることができる。

図５に示した閾値情報１４ａによれば、ＶＭ−１が、ＣＰＵ使用率が７０％以上、かつ、メモリ使用率が８０％以上になった回数が２回に達した場合に、増設対象とされる。

また、決定部１５ｂは、仮想化環境に関する負荷情報を用いて、最も負荷の低い環境を増設対象のＶＭ３の配置先として決定する。ここで、配置先すなわち増設先は、増設元のホストと同一セグメントに属していればよい。これにより、ロードバランサ５と連動させてロードバランサ５の分散先とすることが可能となる。また、増設先は、増設元の自ＤＣとは異なるＤＣに限定されず、同じＤＣ内の異なるホストでも同一のホストでもよい。

なお、決定部１５ｂは、収集された負荷情報を用いて、上記と同様に、減設対象のＶＭ３を決定する。例えば、図５に示した閾値情報１４ａによれば、ＶＭ−１が、スレッド数が５０以下になった回数が３回に達した場合に、減設対象とされる。

また、減設の際に、全てのＶＭ３が削除される事態を抑止するため、例えば、閾値情報１４ａに同一ＶＭ３の最低稼働台数を設定可能にしておき、最低稼働台数を下回らない範囲でＶＭの減設が決定されるようにすればよい。

指示部１５ｃは、決定された増設対象のＶＭ３の増設先のホストでの複製を指示する。具体的には、指示部１５ｃは、まず、増設対象のＶＭ３すなわち増設元ＶＭの属する仮想化管理システム４から、増設元ＶＭのイメージファイルと、増減元ＶＭのＣＰＵ、メモリ等の仮想リソース設定内容とを取得する。次に、指示部１５ｃは、増設先のホストが属する仮想化管理システム４に、取得した増設元ＶＭのイメージファイルと仮想リソース設定内容とを送信し、増設元ＶＭの複製を指示する。このように、運用中のＶＭ３自体が複製されるわけではないので、増設元ＶＭが運用中であっても、影響を与えることなく増設先のデータセンタのホストに増設元ＶＭと同一のＶＭを増設することができる。

また、決定部１５ｂが減設対象のＶＭ３を決定した場合に、指示部１５ｃは、決定された減設対象のＶＭ３の削除を指示する。具体的には、減設対象のＶＭ３が運用中の場合を考慮して、指示部１５ｃは、まず、ロードバランサ５に予閉塞の指示を行って、ＩｏＴデバイス２からのトラフィックの増加を抑止する。

この場合に、ロードバランサ５は、同一ユーザからの同一セッションに属するパケットを同一のＶＭ３に転送するパーシステンシー機能を用いて、関連リクエストのみを継続させる。その後、指示部１５ｃは、ロードバランサ５を経由した減設対象のＶＭ３へのセッション数がゼロになった時点で、仮想化管理システム４に減設対象のＶＭ３の削除の指示を行う。これにより、システム１におけるＶＭ３のスケールインが可能となり、さらに効率よくリソースを運用することが可能となる。

設定部１５ｄは、増設されたＶＭ３に対するアドレス設定等の必要最小限のネットワーク設定を行う。設定部１５ｄは、コマンドラインや予め用意されたスクリプトを実行してもよい。また、設定部１５ｄは、ＶＭ３の増設または減設の最新の状態をロードバランサ５およびＯｐＳ６に登録させる。

試験部１５ｅは、増設されたＶＭ３が利用可能であることを確認する試験を実施する。具体的には、試験部１５ｅは、複製されたＶＭ３を、まず、ロードバランサ５に非運用の状態で登録し、インターネット経由で試験パケットを送信する。そして、試験部１５ｅは、試験パケットに対する応答や、ロードバランサ５や増設されたＶＭ３のエラーログの有無を確認することにより、正常性を確認する。増設されたＶＭ３の正常性が確認された場合に、試験部１５ｅは、この増設されたＶＭ３を運用の状態に変更する。

［管理処理］
次に、図６〜図８を参照して、本実施形態に係る管理装置１０による管理処理について説明する。まず、図６および図７は、管理処理手順を示すシーケンス図である。図６および図７のシーケンス図は、例えば、システム１の運用者により、管理処理の開始を指示する操作入力があったタイミングで開始される。

この場合に、収集部１５ａは、ＶＭ３の負荷情報を収集する（ステップＳ１）。具体的には、収集部１５ａは、図６に示すように、各ＶＭ３について、ハードウェアリソースに関する負荷情報を仮想化管理システム４から収集する（ステップＳ１１）。また、収集部１５ａは、ゲストＯＳ以上のリソースの情報をゲストＯＳのエージェントから収集する（ステップＳ１２）。

また、収集部１５ａは、ステップＳ１１およびステップＳ１２の処理を、図７に示すように、各ＶＭ３の負荷情報として収集する（ステップＳ１３）。同様に、収集部１５ａは、各仮想化管理システム４に属する全てのＶＭ３の負荷情報を、ＶＭ３の仮想化環境の負荷情報として収集する（ステップＳ１４）。

収集部１５ａは、収集したＶＭ３の負荷情報を決定部１５ｂに送信する（ステップＳ２）。決定部１５ｂは、受信したＶＭ３の負荷情報を用いて、増設対象または減設対象のＶＭ３を決定する（ステップＳ３）。また、決定部１５ｂは、決定した増設対象のＶＭ３および増設先のホスト、または減設対象のＶＭ３を指示部１５ｃに通知する（ステップＳ４）。

指示部１５ｃは、増設対象のＶＭ３が通知された場合に、この増設元のＶＭ３が属する仮想化管理システム４に、増設元ＶＭのイメージファイルと仮想リソースの設定内容とを問い合わせて取得する（ステップＳ５）。また、指示部１５ｃは、増設先のホストが属する仮想化管理システム４に、増設元ＶＭのイメージファイル、仮想リソースの設定内容および増設先を含む増設指示を通知する（ステップＳ６）。

また、指示部１５ｃは、減設対象のＶＭ３が通知された場合に、減設対象のＶＭ３が属する仮想化管理システム４に、減設対象ＶＭの減設指示を送信する（ステップＳ５）。これにより、一連の管理処理が終了する。

次に、図８を参照して、上記ステップＳ３の対象ＶＭ決定処理手順について説明する。決定部１５ｂは、収集されたＶＭ３の負荷情報を用いて閾値情報１４ａを参照し、各ＶＭ３について、合致する閾値が設定されているか否かの確認を、閾値に合致するＶＭ３があるまで繰り返す（ステップＳ３１，Ｎｏ）。

閾値に合致するＶＭ３があった場合に（ステップＳ３１，Ｙｅｓ）、決定部１５ｂは、閾値の合致回数をカウントし（ステップＳ３２）、閾値情報１４ａに設定されている所定の合致回数に達しているか否かを確認する（ステップＳ３３）。閾値の合致回数が所定の合致回数に達していない場合には（ステップＳ３３，Ｎｏ）、決定部１５ｂは、ステップＳ３１に処理を戻す。

一方、閾値の合致回数が所定の合致回数に達した場合には（ステップＳ３３，Ｙｅｓ）、決定部１５ｂは、合致した閾値の処理条件が増設か減設かを確認する（ステップＳ３４）。合致した閾値の処理条件が増設の場合に（ステップＳ３４，増設）、決定部１５ｂは、このＶＭ３を増設対象に決定し、指示部１５ｃに通知する（ステップＳ３５）。また、合致した閾値の処理条件が減設の場合に（ステップＳ３４，減設）、決定部１５ｂは、このＶＭ３を減設対象に決定し、指示部１５ｃに通知する（ステップＳ３６）。これにより、一連の対象ＶＭ決定処理が終了する。

以上、説明したように、本実施形態の管理装置１０において、収集部１５ａが、ＶＭ３の負荷情報を収集する。また、決定部１５ｂが、収集された負荷情報を用いて、増設対象のＶＭ３と増設先のホストとを決定する。また、指示部１５ｃが、決定された増設対象のＶＭ３の増設先のホストでの複製を指示する。これにより、負荷の大きいＶＭ３を選択的に分散先のデータセンタのホストに増設することができ、効率よくスケールアウトを行える。

これに対し、従来のＤＷＳでは、図９（ａ）に例示するように、分散先ＤＣを都心部ＤＣに一極集中させる場合には、都心部ＤＣには、既設ＶＭに加え、各地域ＤＣから分散される増設ＶＭが加わるため、ＶＭが集中してしまうおそれがあった。また、図９（ｂ）に例示するように、分散先ＤＣを他地域ＤＣに分散させる場合にも同様に、分散先の他地域ＤＣには、既設ＶＭに加え、分散させる増設ＶＭが加わるため、ＶＭが集中するおそれがあった。いずれにしても、分散先ＤＣにおけるＶＭの集中が考慮されていなかったため、ＶＭがハイパーバイザのＶＭの上限数の超過、ＶＭ間のリソース競合や性能劣化等のリソースの問題が発生するおそれがあった。

また、図９（ｃ）に例示するように、分散先ＤＣでのＶＭの集中を避けるために、分散先ＤＣのＶＭの上限数等のリソースを考慮して、分散元ＤＣと分散先ＤＣとの数の比率をＮ対１等に設計されていた。しかしながら、設計が煩雑であり、柔軟性が損なわれるおそれがあった。

また、過去の負荷情報を参照して増設するＶＭを特定して手動で増設すれば、ＶＭ数の増大を回避できるものの、運用者の負担が大きいだけでなく、ＶＭ増設が遅れてトラフィックが分散されない場合があった。

なお、負荷が上昇したＶＭを移動させる技術として、ｖＳｐｈｅｒｅ ＤＲＳ（Distributed Resource Scheduler）と呼ばれる技術が知られている。しかしながら、ＤＲＳによれば、ＶＭをリソースに余裕のある別のホストに移動させることはできるが、増設はできず、地域ＤＣのリソースの余剰は解消されずスケールアウトにはならない。また、ｖＭｏｔｉｏｎ等による移動時には、サービス瞬断が発生し、特にＵＤＰが適用されるＩｏＴデバイスには不利益を与える場合があった。

これに対し、本実施形態の管理装置１０によれば、分散先ＤＣにおいて運用者の手動によらずに容易に、負荷に応じてＶＭの増設や減設が可能となる。このように、トラフィック分散先のデータセンタのリソースを容易かつ効率よく運用することが可能となる。

また、管理装置１０は、収集された負荷情報を用いて減設対象のＶＭ３を決定し、削除を指示する。これによりスケールインも可能となり、さらに効率よくリソースを運用することが可能となる。

［システム構成等］
図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［プログラム］
上記実施形態に係る管理装置１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。一実施形態として、管理装置１０は、パッケージソフトウェアやオンラインソフトウェアとして上記の管理処理を実行する管理プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記の管理プログラムを情報処理装置に実行させることにより、情報処理装置を管理装置１０として機能させることができる。ここで言う情報処理装置には、デスクトップ型またはノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）などの移動体通信端末、さらには、ＰＤＡ（Personal Digital Assistants）などのスレート端末などがその範疇に含まれる。

また、管理装置１０は、ユーザが使用する端末装置をクライアントとし、当該クライアントに上記の管理処理に関するサービスを提供するサーバ装置として実装することもできる。例えば、管理装置１０は、ＶＭ３の負荷情報を入力とし、増減設対象のＶＭ３を出力する管理処理サービスを提供するサーバ装置として実装される。この場合、管理装置１０は、Ｗｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の管理処理に関するサービスを提供するクラウドとして実装することとしてもかまわない。以下に、管理装置１０と同様の機能を実現する管理プログラムを実行するコンピュータの一例を説明する。

図１０は、管理プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。ディスクドライブ１０４１には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１０５１およびキーボード１０５２が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１０６１が接続される。

ここで、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０３１やメモリ１０１０に記憶される。

また、管理プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュール１０９３として、ハードディスクドライブ１０３１に記憶される。具体的には、上記実施形態で説明した管理装置１０が実行する各処理が記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。

また、管理プログラムによる情報処理に用いられるデータは、プログラムデータ１０９４として、例えば、ハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。

なお、管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮやＷＡＮ（Wide Area Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

以上、本発明者によってなされた発明を適用した実施形態について説明したが、本実施形態による本発明の開示の一部をなす記述および図面により本発明は限定されることはない。すなわち、本実施形態に基づいて当業者等によりなされる他の実施形態、実施例および運用技術等は全て本発明の範疇に含まれる。

１ システム
２ ＩｏＴデバイス
３ 仮想マシン（ＶＭ）
４ 仮想化管理システム
５ ロードバランサ
６ オペレーションシステム（ＯｐＳ）
７ データセンタ（ＤＣ）
１０ 管理装置
１１ 入力部
１２ 出力部
１３ 通信制御部
１４ 記憶部
１４ａ 閾値情報
１５ 制御部
１５ａ 収集部
１５ｂ 決定部
１５ｃ 指示部
１５ｄ 設定部
１５ｅ 試験部

Claims (6)

1. 仮想マシンの負荷情報を収集する収集部と、
   収集された前記負荷情報を用いて、増設対象の仮想マシンと増設先のホストとを決定する決定部と、
   決定された前記増設対象の仮想マシンの前記増設先のホストでの複製を指示する指示部と、
   を備えることを特徴とする管理装置。
2. 前記収集部は、前記仮想マシンのハードウェアリソースの情報と、該仮想マシンのゲストＯＳ以上のリソースの情報とを含む前記負荷情報を収集することを特徴とする請求項１に記載の管理装置。
3. 前記収集部は、各前記仮想マシンに関する負荷情報と、前記仮想マシンの仮想化環境に関する負荷情報とを含む前記負荷情報を収集し、
   前記決定部は、前記仮想マシンに関する負荷情報を用いて前記増設対象の仮想マシンを決定し、前記仮想化環境に関する負荷情報を用いて前記増設先のホストを決定することを特徴とする請求項１または２に記載の管理装置。
4. 前記決定部は、前記負荷情報が所定の閾値の範囲に合致した回数が所定値を超えた場合に、前記増設対象の仮想マシンとして決定することを特徴とする請求項１〜３のいずれか１項に記載の管理装置。
5. 前記決定部は、収集された前記負荷情報を用いて、さらに、減設対象の仮想マシンを決定し、
   前記指示部は、決定された前記減設対象の仮想マシンの削除を指示することを特徴とする請求項１〜４のいずれか１項に記載の管理装置。
6. 管理装置で実行される管理方法であって、
   仮想マシンの負荷情報を収集する収集工程と、
   収集された前記負荷情報を用いて、増設対象の仮想マシンと増設先のホストとを決定する決定工程と、
   決定された前記増設対象の仮想マシンの前記増設先のホストでの複製を指示する指示工程と、
   を含んだことを特徴とする管理方法。

Images