JP7394906B2 - 制御装置、プログラム、及び制御方法 - Google Patents

Description

本発明は、制御装置、プログラム、及び制御方法に関する。

特許文献１には、仮想マシンに対するリソースの割り当て量の変動を制御するための技術について記載されている。特許文献２には、オーバーコミットが発生しないようにリソース配分を制御するための技術について記載されている。特許文献３には、仮想マシンの適切な配備を実現するための技術について記載されている。
［先行技術文献］
［特許文献］
［特許文献１］特開２０１２－１９０１０９号公報
［特許文献２］特開２０１４－１３０４１３号公報
［特許文献３］特開２０１８－０２８７４６号公報

本発明の一実施態様によれば、制御装置が提供される。前記制御装置は、ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当部を備えてよい。前記制御装置は、前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御部を備えてよい。

前記上限制御部は、前記複数のゲストＯＳの状況に応じて、前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えない範囲内で、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を調整してよい。前記上限制御部は、前記複数のゲストＯＳのうちの第１のゲストＯＳにおける前記仮想リソースの利用率が予め定められた閾値を下回った場合に、前記第１のゲストＯＳの前記仮想リソースの利用可能量の上限を減少させ、前記複数のゲストＯＳのうちの第２のゲストＯＳの前記仮想リソースの利用可能量の上限を増加させてよい。前記上限制御部は、前記複数のゲストＯＳのうちの第１のゲストＯＳにおける前記仮想リソースの利用率が予め定められた閾値を超えた場合に、前記複数のゲストＯＳのうちの第２のゲストＯＳの前記仮想リソースの利用可能量の上限を減少させ、前記第１のゲストＯＳの前記仮想リソースの利用可能量の上限を増加させてよい。

前記リソース割当部は、前記複数のゲストＯＳに対して、前記ホストが有するＣＰＵリソースの量を超える量の仮想ＣＰＵリソースを割り当ててよく、前記上限制御部は、前記複数のゲストＯＳによる前記仮想ＣＰＵリソースの利用量の合計が前記ホストの前記ＣＰＵリソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想ＣＰＵリソースの利用可能量の上限を制御してよい。前記上限制御部は、前記複数のゲストＯＳのうちの第１のゲストＯＳにおけるＣＰＵ制御プロセスの起動管理によって並列処理数を減少させることによって、前記第１のゲストＯＳの前記仮想リソースの利用可能量の上限を減少させてよい。

前記リソース割当部は、前記複数のゲストＯＳに対して、前記ホストが有するメモリリソースの量を超える量の仮想メモリリソースを割り当ててよく、前記上限制御部は、前記複数のゲストＯＳによる前記仮想メモリリソースの利用量の合計が前記ホストの前記メモリリソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想メモリリソースの利用可能量の上限を制御してよい。前記上限制御部は、前記複数のゲストＯＳのうちの第１のゲストＯＳにメモリ領域を再構築させて、前記第１のゲストＯＳの前記仮想メモリリソースの利用可能量の上限を減少させてよい。

本発明の一実施態様によれば、制御装置が提供される。前記制御装置は、ホストのリソースを割り当ててアプリケーションの実行単位を前記ホスト上に生成する実行単位生成部を備えてよい。前記制御装置は、前記実行単位生成部によって生成された第１の実行単位のリソース量を変更することを決定する変更決定部を備えてよい。前記制御装置は、前記変更決定部により変更することが決定された場合に、前記第１の実行単位と同一設定であり、前記第１の実行単位とは異なる量のリソースを割り当てた第２の実行単位を生成させ、前記第１の実行単位と前記第２の実行単位との間で同期処理を実行させた後、前記第１の実行単位のアプリケーションの実行主体を前記第２の実行単位に切り替えさせる変更制御部を備えてよい。

前記変更制御部は、前記変更決定部によって、前記第１の実行単位のリソース量を減少させることが決定された場合に、前記第１の実行単位と同一設定であり、前記第１の実行単位よりも少ない量のリソースを割り当てた前記第２の実行単位を生成させ、前記第１の実行単位と前記第２の実行単位との間で同期処理を実行させた後、前記第１の実行単位のアプリケーションの実行主体を前記第２の実行単位に切り替えさせてよい。前記変更制御部は、前記変更決定部によって、前記第１の実行単位のリソース量を増加させることが決定された場合に、前記第１の実行単位と同一設定であり、前記第１の実行単位よりも多い量のリソースを割り当てた前記第２の実行単位を生成させ、前記第１の実行単位と前記第２の実行単位との間で同期処理を実行させた後、前記第１の実行単位のアプリケーションの実行主体を前記第２の実行単位に切り替えさせてよい。

前記実行単位生成部は、割当リソース情報を含む一の実行単位テンプレートを用いて前記第１の実行単位を生成してよく、前記変更制御部は、前記割当リソース情報を変更した前記一の実行単位テンプレートを用いて前記第２の実行単位を生成してよい。前記変更制御部は、前記第１の実行単位の前記アプリケーションの実行主体を前記第２の実行単位に切り替えさせた後、前記第１の実行単位を削除してよい。前記変更制御部は、前記第１の実行単位の前記アプリケーションの実行主体を前記第２の実行単位に切り替えさせた後、予め定められた条件が満たされたことに応じて、前記第２の実行単位と前記第１の実行単位の間で同期処理を実行させた後、前記第２の実行単位の前記アプリケーションの実行主体を前記第１の実行単位に切り替えさせてよい。前記実行単位は、仮想マシン又はコンテナであってよい。

本発明の一実施態様によれば、コンピュータを、前記制御装置として機能させるためのプログラムが提供される。

本発明の一実施態様によれば、コンピュータによって実行される制御方法が提供される。前記制御方法は、ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当段階を備えてよい。前記制御方法は、前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御段階を備えてよい。

本発明の一実施態様によれば、コンピュータによって実行される制御方法が提供される。前記制御方法は、ホストのリソースを割り当ててアプリケーションの実行単位を前記ホスト上に生成する実行単位生成段階を備えてよい。前記制御方法は、前記実行単位生成段階において生成された前記実行単位のリソース量を変更することを決定する変更決定部を備えてよい。前記制御方法は、前記実行単位と同一設定であり、前記実行単位とは異なる量のリソースを割り当てた他の実行単位を生成し、前記実行単位と前記他の実行単位の間で同期処理を実行させた後、前記実行単位のアプリケーションの実行主体を前記他の実行単位に切り替えさせるリソース変更制御段階を備えてよい。

なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではない。また、これらの特徴群のサブコンビネーションもまた、発明となりうる。

スケール制御装置１００の一例を概略的に示す。 スケール制御装置１００による制御内容について説明するための説明図である。 スケール制御装置１００による制御内容について説明するための説明図である。 スケール制御装置１００の機能構成の一例を概略的に示す。 スケール制御装置１００による制御内容について説明するための説明図である。 スケール制御装置１００による制御内容について説明するための説明図である。 スケール制御装置１００の機能構成の一例を概略的に示す。 スケール制御装置１００として機能するコンピュータ１２００のハードウェア構成の一例を概略的に示す。

ハイパーバイザ型仮想化において、稼働の増減（サービス使用の増減）が発生した際に、アプリケーションが使用可能なリソースを変更するスケーリング手法が定義されている。また、ＮＦＶ（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）では、要求される信頼性・性能の観点から、予測困難な性能劣化を回避するため、複数アプリケーションにリソースの重複割り当てをしないことが一般的である。定義されているスケーリング手法として、スケールアップ／ダウン及びスケールアウト／インがある。スケールアップ／ダウンは、インスタンスに割り当てるリソース量を増減させることである。スケールアウト／インは、インスタンス数を増減させることである。論理的に、スケールアップ／ダウンは、スケールアウト／インに比べて、リソース制御の柔軟性が高い点と、アプリケーション設定変更を最小化できる点とで優位である。

現状、ステートフルなアプリケーションのスケールアップ／アウトは、ＶＭ仮想化において技術的に直接動的なリソースの変更ができないため、柔軟なリソース制御が実現できていない。このため、ステートフル情報を維持したまま最適なリソースの変更をすることができない。

本実施形態では、例えば、ホスト上に、ＣＰＵ及びメモリ等のリソースのオーバーコミット可として、ゲストＯＳを起動する。そして、外部のスケール制御装置１００から、内部で利用できるリソース上限を制御することにより、オーバーコミットでありながら、ホストリソースの上限を超えた、仮想リソースの利用を防ぎ、リソースの効率利用を実現する。

また、例えば、ホスト上の、アプリケーションの実行単位（ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ：仮想マシン）、コンテナ等）のリソースを変更する場合に、サイズ以外同一設定の実行単位を生成し、必要な情報の同期をしたうえで、旧実行単位を削除する。これにより、ステートフル情報を維持したままのスケールダウンを可能とすることができ、最適なリソース変更の実現に貢献することができる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、スケール制御装置１００の一例を概略的に示す。スケール制御装置１００は、制御装置の一例であってよい。スケール制御装置１００は、ホスト上のアプリケーションが利用可能なリソースを変更するスケーリング制御を実行する。スケール制御装置１００は、複数のホストを対象としてよい。図１では、ホスト３１０及びホスト３５０を図示しているが、一例であり、スケール制御装置１００が対象とするホストの数はこれに限らず、３つ以上であってもよい。

スケール制御装置１００は、仮想化制御装置２００を介して、ホスト３１０及びホスト３５０に対する制御を実行してよい。仮想化制御装置２００は、仮想化対象のホストのコントローラであってよい。なお、スケール制御装置１００と仮想化制御装置２００とは一体であってもよい。すなわち、スケール制御装置１００は、仮想化制御装置２００の機能を備えてもよい。

スケール制御装置１００は、例えば、ホスト３１０上で動作する複数のゲストＯＳに対して、ホスト３１０が有する物理リソースの量を超える量の仮想リソースを割り当て、複数のゲストＯＳによる仮想リソースの利用量の合計がホスト３１０の物理リソースの量を超えないように、複数のゲストＯＳのそれぞれの仮想リソースの利用可能量の上限を制御する。

スケール制御装置１００は、例えば、ホスト３１０上の第１の実行単位のリソース量を変更する場合に、第１の実行単位と同一設定であり、第１の実行単位とは異なる量のリソースを割り当てた第２の実行単位をホスト３５０上に生成し、第１の実行単位と第２の実行単位との間で同期処理を実行させた後、第１の実行単位のアプリケーションの実行主体を第２の実行単位に切り替えさせる。

図２は、スケール制御装置１００による制御内容について説明するための説明図である。図２では、説明の便宜上、ホスト３１０が、６つのＣＰＵリソース３２０を有しており、ホスト３１０上に、ゲストＯＳ４１０及びゲストＯＳ４５０を構成する場合を例示する。

スケール制御装置１００は、ＣＰＵリソース３２０を超える量の仮想ＣＰＵリソースをゲストＯＳ４１０及びゲストＯＳ４５０に割り当てる。図２に示す例では、ゲストＯＳ４１０に４つの仮想ＣＰＵリソース４２０が割り当てられ、ゲストＯＳ４５０に４つの仮想ＣＰＵリソース４６０が割り当てられている。

スケール制御装置１００は、ゲストＯＳ４１０及びゲストＯＳ４５０による仮想ＣＰＵリソースの利用量の合計がＣＰＵリソース３２０の量を超えないように、ゲストＯＳ４１０及びゲストＯＳ４５０のそれぞれの仮想ＣＰＵリソースの利用可能量の上限を制御する。スケール制御装置１００は、ゲストＯＳ４１０のプロセス管理４１２と、ゲストＯＳ４５０のプロセス管理４５２とを制御することによって、仮想ＣＰＵリソースの利用可能量の上限を制御してよい。図２に示す例では、ゲストＯＳ４１０の上限を４とし、ゲストＯＳ４５０の上限を２としている。

スケール制御装置１００は、ゲストＯＳ４１０及びゲストＯＳ４５０の状況に応じて、ゲストＯＳ４１０及びゲストＯＳ４５０による仮想ＣＰＵリソースの利用量の合計がＣＰＵリソース３２０の量を超えない範囲内で、ゲストＯＳ４１０及びゲストＯＳ４５０のそれぞれの仮想ＣＰＵリソースの利用可能量の上限を調整してよい。

スケール制御装置１００は、アプリプロセス４１４による仮想ＣＰＵリソース４２０の利用状況を監視してよい。スケール制御装置１００は、アプリプロセス４５４による仮想ＣＰＵリソース４６０の利用状況を監視してよい。

スケール制御装置１００は、例えば、ゲストＯＳ４１０において、４つの仮想ＣＰＵリソース４２０のうちの１つが利用されていない場合に、ゲストＯＳ４１０の仮想ＣＰＵリソースの利用可能量の上限を４から３に変更する。これにより、ステートフル情報を維持したまま容易にスケールダウンを実現することができる。スケール制御装置１００は、例えば、ゲストＯＳ４１０におけるＣＰＵ制御プロセスの起動管理によって並列処理数を減少させることによって、ゲストＯＳ４１０の仮想ＣＰＵリソースの利用可能量の上限を減少させてよい。そして、スケール制御装置１００は、ゲストＯＳ４５０の仮想ＣＰＵリソースの利用可能量の上限を２から３に変更してよい。これにより、容易にスケールアップを実現することができる。

図３は、スケール制御装置１００による制御内容について説明するための説明図である。図３では、説明の便宜上、ホスト３１０が、６つのメモリリソース３３０を有しており、ホスト３１０上に、ゲストＯＳ４１０及びゲストＯＳ４５０を構成する場合を例示する。

スケール制御装置１００は、メモリリソース３３０を超える量の仮想メモリリソースをゲストＯＳ４１０及びゲストＯＳ４５０に割り当てる。図２に示す例では、ゲストＯＳ４１０に４つの仮想メモリリソース４３０が割り当てられ、ゲストＯＳ４５０に４つの仮想メモリリソース４７０が割り当てられている。

スケール制御装置１００は、ゲストＯＳ４１０及びゲストＯＳ４５０による仮想メモリリソースの利用量の合計がメモリリソース３３０の量を超えないように、ゲストＯＳ４１０及びゲストＯＳ４５０のそれぞれの仮想メモリリソースの利用可能量の上限を制御する。スケール制御装置１００は、ゲストＯＳ４１０のプロセス管理４１２と、ゲストＯＳ４５０のプロセス管理４５２とを制御することによって、仮想メモリリソースの利用可能量の上限を制御してよい。図３に示す例では、ゲストＯＳ４１０の上限を４とし、ゲストＯＳ４５０の上限を２としている。

スケール制御装置１００は、ゲストＯＳ４１０及びゲストＯＳ４５０の状況に応じて、ゲストＯＳ４１０及びゲストＯＳ４５０による仮想メモリリソースの利用量の合計がメモリリソース３３０の量を超えない範囲内で、ゲストＯＳ４１０及びゲストＯＳ４５０のそれぞれの仮想メモリリソースの利用可能量の上限を調整してよい。

スケール制御装置１００は、アプリプロセス４１４による仮想メモリリソース４３０の利用状況を監視してよい。スケール制御装置１００は、アプリプロセス４５４による仮想メモリリソース４７０の利用状況を監視してよい。

スケール制御装置１００は、例えば、ゲストＯＳ４１０において、４つの仮想メモリリソース４３０のうちの２つが利用されていない場合に、ゲストＯＳ４１０の仮想メモリリソースの利用可能量の上限を４から２に変更する。これにより、ステートフル情報を維持したまま容易にスケールダウンを実現することができる。スケール制御装置１００は、例えば、ゲストＯＳ４１０にメモリ領域を再構築させて、ゲストＯＳ４１０の仮想メモリリソースの利用可能量の上限を減少させてよい。この場合、再構築のための領域が必要となり、割当量の半分が最大量となる。そして、スケール制御装置１００は、ゲストＯＳ４５０の仮想メモリリソースの利用可能量の上限を２から４に変更してよい。これにより、容易にスケールアップを実現することができる。

図４は、スケール制御装置１００の機能構成の一例を概略的に示す。スケール制御装置１００は、記憶部１０２、登録部１０４、リソース割当部１０６、性能監視部１０８、及び上限制御部１１０を備える。

登録部１０４は、各種情報を登録する。登録部１０４は、例えば、スケール制御装置１００のオペレータの指示に従って各種情報を登録する。登録部１０４は、例えば、管理対象のホストの物理リソースの情報を登録する。登録部１０４は、例えば、ホスト上に生成するゲストＯＳに関する情報を登録する。登録部１０４は、例えば、ホスト上で動作する複数のゲストＯＳに対して割り当てる仮想リソースの量の初期値を登録する。登録部１０４が登録した情報は、記憶部１０２に記憶される。

リソース割当部１０６は、ホスト上で動作する複数のゲストＯＳに対して、ホストが有する物理リソースの量を超える量の仮想リソースを割り当てる。リソース割当部１０６は、記憶部１０２に記憶されている、ホストの物理リソースの情報と、複数のゲストＯＳの情報とから、自動的に複数のゲストＯＳのそれぞれに対して割り当てる仮想リソースの量を決定してよい。登録部１０４によって、複数のゲストＯＳに対して割り当てる仮想リソースの量の初期値が登録されている場合、リソース割当部１０６は、当該情報に従って、複数のゲストＯＳのそれぞれに対して仮想リソースを割り当ててもよい。

性能監視部１０８は、ホスト及びホスト上に生成された複数のゲストＯＳの性能を監視する。性能監視部１０８は、例えば、ホストによるリソースの利用状況を監視する性能監視部１０８は、例えば、複数のゲストＯＳのそれぞれについて、ゲストＯＳにおける仮想リソースの利用状況を監視する。性能監視部１０８は、複数のゲストＯＳのそれぞれについて、ゲストＯＳ上で動作するアプリケーションによるサービス稼働状況を監視してよい。性能監視部１０８による監視対象の例として、ＣＰＵ利用率、メモリ利用率、ネットワーク帯域利用率、セッション数、及びスループット等が挙げられるが、これらに限られない。

上限制御部１１０は、複数のゲストＯＳによる仮想リソースの利用量の合計がホストの物理リソースの量を超えないように、複数のゲストＯＳのそれぞれの仮想リソースの利用可能量の上限を制御する。上限制御部１１０は、記憶部１０２に記憶されている、ホストの物理リソースの情報と、複数のゲストＯＳの情報とから、自動的に複数のゲストＯＳのそれぞれの仮想リソースの利用可能量の上限の初期値を決定してよい。上限制御部１１０は、決定した初期値に従って、複数のゲストＯＳのそれぞれに、仮想リソースの利用可能量の上限を設定してよい。

リソース割当部１０６によって、ホストの物理リソースの量を超える量の仮想リソースを複数のゲストＯＳに割り当てつつ、上限制御部１１０によって、ホストの物理リソースの量を超えないように仮想リソースの利用可能量の上限を制御することによって、スケールアップ及びスケールダウンを容易に実現可能な環境を提供することができる。

上限制御部１１０は、性能監視部１０８によって監視される、複数のゲストＯＳの状況に応じて、複数のゲストＯＳによる仮想リソースの利用量の合計がホストの物理リソースの量を超えない範囲内で、複数のゲストＯＳのそれぞれの仮想リソースの利用可能量の上限を調整してよい。これにより、複数のゲストＯＳの状況の変化に合わせた、複数のゲストＯＳのそれぞれのスケールアップ及びスケールダウンを実現することができる。

例えば、上限制御部１１０は、複数のゲストＯＳのうちの第１のゲストＯＳにおける仮想リソースの利用率が予め定められた閾値を下回った場合に、第１のゲストＯＳの仮想リソースの利用可能量の上限を減少させてよい。仮想リソースの利用率は、仮想リソースの利用可能量の上限に対する、実際の仮想リソースの利用量の割合であってよい。閾値は、登録部１０４によって登録されてよい。上限制御部１１０は、第１のゲストＯＳの仮想リソースの利用可能量の上限を減少させた分、複数のゲストＯＳのうちの第２のゲストＯＳの仮想リソースの利用可能量の上限を増加させてよい。これにより、第１のゲストＯＳの負荷が高くない場合に、仮想リソースの上限量のうちの一部を解放することができ、他のゲストＯＳに割り当てることを可能とすることができる。

上限制御部１１０は、複数のゲストＯＳのうちの第１のゲストＯＳにおいて、設定した仮想リソースの利用量の上限と、実際の仮想リソースの利用量とから、上限のうちの一部を解放可能か否か判定し、解放可能と判定した場合に、第１のゲストＯＳの仮想リソースの利用可能量の上限を減少させてもよい。

例えば、上限制御部１１０は、複数のゲストＯＳのうちの第１のゲストＯＳにおける仮想リソースの利用率が予め定められた閾値を超えた場合に、複数のゲストＯＳのうちの第２のゲストＯＳの仮想リソースの利用可能量の上限を減少させ、第１のゲストＯＳの仮想リソースの利用可能量の上限を増加させてよい。上限制御部１１０は、第１のゲストＯＳにおける仮想リソースの利用率が予め定められた閾値を超えた場合であって、第１のゲストＯＳの仮想リソースの利用可能量の上限が、第１のゲストＯＳに割り当てられている仮想リソースの量よりも少ない場合に、第２のゲストＯＳの仮想リソースの利用可能量の上限を減少させ、第１のゲストＯＳの仮想リソースの利用可能量の上限を増加させてよい。上限制御部１１０は、例えば、複数のゲストＯＳのうちの第１のゲストＯＳ以外のうち、仮想リソースの利用率が最も低いゲストＯＳの仮想リソースの利用可能量の上限を減少させてよい。これにより、第１のゲストＯＳの負荷が高まった場合に、第１のゲストＯＳに割り当てられている仮想リソースの量の範囲内で、第１のゲストＯＳが利用可能な仮想リソースの量を増加させることができる。

図２において例示したように、リソース割当部１０６は、複数のゲストＯＳに対して、ホストが有するＣＰＵリソースの量を超える量の仮想ＣＰＵリソースを割り当ててよく、上限制御部１１０は、複数のゲストＯＳによる仮想ＣＰＵリソースの利用量の合計がホストのＣＰＵリソースの量を超えないように、複数のゲストＯＳのそれぞれの仮想ＣＰＵリソースの利用可能量の上限を制御してよい。例えば、上限制御部１１０は、ゲストＯＳにおけるＣＰＵ制御プロセスの起動管理によって並列処理数を減少させることによって、ゲストＯＳの仮想リソースの利用可能量の上限を減少させてよい。例えば、上限制御部１１０は、ゲストＯＳにおけるＣＰＵ制御プロセスの起動管理によって並列処理数を増加させることによって、ゲストＯＳの仮想リソースの利用可能量の上限を増加させてよい。

図３において例示したように、リソース割当部１０６は、複数のゲストＯＳに対して、ホストが有するメモリリソースの量を超える量の仮想メモリリソースを割り当ててよく、上限制御部１１０は、複数のゲストＯＳによる仮想メモリリソースの利用量の合計がホストのメモリリソースの量を超えないように、複数のゲストＯＳのそれぞれの仮想メモリリソースの利用可能量の上限を制御してよい。例えば、上限制御部１１０は、ゲストＯＳにメモリ領域を再構築させて、ゲストＯＳの仮想メモリリソースの利用可能量の上限を減少させてよい。この場合、再構築のための領域が必要となり、仮想メモリリソースの利用可能量の上限の最大量が、割当メモリリソースの半分となってしまうが、再構築によって不要メモリを完全に解放することができる。なお上限制御部１１０は、再構築を行わなくてもよい。

図５は、スケール制御装置１００による制御内容について説明するための説明図である。従来技術では、直接的に状態６１０と状態６２０との間の変更ができないので、スケール制御装置１００は、状態６３０を追加することによって、状態６１０と状態６２０との間の変更を可能とする。

仮に状態６１０を開始状態とした場合において、スケール制御装置１００は、実行単位５１０に対するリソースの増加が必要と判定した場合に、状態６３０に移行させる。すなわち、スケール制御装置１００は、実行単位５１０とサイズ以外同一設定の実行単位５２０をホスト３５０上に生成し、実行単位５１０と実行単位５２０との間で同期処理を実行させた後、実行単位５１０のアプリケーションの実行主体を実行単位５２０に切り替えさせ、実行単位５１０を削除させることにより、状態６２０に移行させる。同期処理によって、ステートフル情報等の必要な情報を実行単位５２０にコピーすることができるので、ステートフル情報を維持したまま容易にスケールアップを実現することができる。なお、後々のスケーリングを考慮して、アプリケーションの実行主体を切り替えた後に、実行単位５１０を削除することなく、状態６３０を維持するようにしてもよい。これにより、アプリケーションの実行主体を実行単位５２０に切り替えた後、実行単位５２０のリソースを減少可能と判定した場合に、実行単位５２０と実行単位５１０との間で同期処理を実行させ、アプリケーションの実行主体を実行単位５１０に切り替えることによって、ステートフル情報を維持したまま容易にスケールダウンを実現することができる。

仮に状態６２０を開始状態とした場合において、スケール制御装置１００は、実行単位５２０のリソースを減少可能と判定した場合に、状態６３０に移行させる。すなわち、スケール制御装置１００は、実行単位５２０とサイズ以外同一設定の実行単位５１０をホスト３１０上に生成し、実行単位５２０と実行単位５１０との間で同期処理を実行させた後、実行単位５２０のアプリケーションの実行主体を実行単位５１０に切り替えさせ、実行単位５２０を削除させることにより、状態６１０に移行させる。同期処理によって、ステートフル情報等の必要な情報を実行単位５１０にコピーすることができるので、ステートフル情報を維持したまま容易にスケールダウンを実現することができる。この場合も、後々のスケーリングを考慮して、アプリケーションの実行主体を切り替えた後に、実行単位５２０を削除することなく、状態６３０を維持するようにしてもよい。これにより、アプリケーションの実行主体を実行単位５１０に切り替えた後、実行単位５１０のリソースの増加が必要と判定した場合に、実行単位５１０と実行単位５２０との間で同期処理を実行させ、アプリケーションの実行主体を実行単位５２０に切り替えることによって、ステートフル情報を維持したまま容易にスケールアップを実現することができる。

図６は、スケール制御装置１００による制御内容について説明するための説明図である。ここでは、図５と異なる点を主に説明する。本例では、スケール制御装置１００は、実行単位５１０及び実行単位５２０を、一のホスト３１０上に生成する。

仮に状態６４０を開始状態とした場合において、スケール制御装置１００は、実行単位５１０に対するリソースの増加が必要と判定した場合に、状態６６０に移行させる。すなわち、スケール制御装置１００は、実行単位５１０とサイズ以外同一設定の実行単位５２０をホスト３１０上に生成し、実行単位５１０と実行単位５２０との間で同期処理を実行させた後、実行単位５１０のアプリケーションの実行主体を実行単位５２０に切り替えさせ、実行単位５１０を削除させることにより、状態６５０に移行させる。なお、後々のスケーリングを考慮して、アプリケーションの実行主体を切り替えた後に、実行単位５１０を削除することなく、状態６６０を維持するようにしてもよい。

仮に状態６２０を開始状態とした場合において、スケール制御装置１００は、実行単位５２０のリソースを減少可能と判定した場合に、状態６３０に移行させる。すなわち、スケール制御装置１００は、実行単位５２０とサイズ以外同一設定の実行単位５１０をホスト３１０上に生成し、実行単位５２０と実行単位５１０との間で同期処理を実行させた後、実行単位５２０のアプリケーションの実行主体を実行単位５１０に切り替えさせ、実行単位５２０を削除させることにより、状態６１０に移行させる。この場合も、後々のスケーリングを考慮して、アプリケーションの実行主体を切り替えた後に、実行単位５２０を削除することなく、状態６６０を維持するようにしてもよい。

図７は、スケール制御装置１００の機能構成の一例を概略的に示す。スケール制御装置１００は、記憶部１１２、登録部１１４、実行単位生成部１１６、性能監視部１１８、変更決定部１２０、及び変更制御部１２２を備える。

登録部１１４は、各種情報を登録する。登録部１１４は、例えば、スケール制御装置１００のオペレータの指示に従って各種情報を登録する。登録部１１４は、例えば、管理対象のホストの物理リソースの情報を登録する。登録部１１４は、例えば、ホスト上に生成する実行単位に関する情報を登録する。登録部１１４は、例えば、実行単位の生成に用いる複数の実行単位テンプレートを登録する。登録部１１４が登録した情報は、記憶部１１２に記憶される。

実行単位生成部１１６は、ホストのリソースを割り当ててアプリケーションの実行単位をホスト上に生成する。実行単位生成部１１６は、例えば、ＶＭをホスト上に生成する。実行単位生成部１１６は、例えば、コンテナをホスト上に生成する。

性能監視部１１８は、ホスト及びホスト上に生成された実行単位の性能を監視する。性能監視部１１８は、例えば、ホストによるリソースの利用状況を監視する。性能監視部１１８は、実行単位における仮想リソースの利用状況を監視してよい。性能監視部１１８は、実行単位上で動作するアプリケーションによるサービス稼働状況を監視してよい。性能監視部１１８による監視対象の例として、ＣＰＵ利用率、メモリ利用率、ネットワーク帯域利用率、セッション数、及びスループット等が挙げられるが、これらに限られない。

変更決定部１２０は、実行単位生成部１１６によって生成された実行単位のリソース量を変更することを決定する。変更決定部１２０は、性能監視部１１８による監視内容に基づいて、実行単位のリソース量を変更することを決定してよい。

変更決定部１２０は、例えば、性能監視部１１８によって監視される性能情報が、予め定められた閾値を下回った場合に、実行単位のリソース量を減少させると決定する。変更決定部１２０は、例えば、性能監視部１１８によって監視される性能情報が、予め定められた閾値を上回った場合に、実行単位のリソース量を増加させると決定する。閾値は、登録部１１４によって登録されてよい。

変更制御部１２２は、変更決定部１２０によって変更することが決定された場合に、変更制御を実行する。変更制御部１２２は、リソース量を変更することが決定された実行単位と同一設定であり、当該実行単位とは異なる量のリソースを割り当てた他の実行単位を生成し、当該実行単位と当該他の実行単位との間で同期処理を実行させた後、当該実行単位のアプリケーションの実行主体を、当該他の実行単位に切り替えさせる。これにより、ステートフル情報を維持しつつ容易にスケールダウンやスケールアップを実現することができる。

例えば、変更制御部１２２は、変更決定部１２０によって第１の実行単位のリソース量を変更することが決定された場合に、第１の実行単位と同一設定であり、第１の実行単位とは異なる量のリソースを割り当てた第２の実行単位を生成し、第１の実行単位と第２の実行単位との間で同期処理を実行させた後、第１の実行単位のアプリケーションの実行主体を第２の実行単位に切り替えさせる。変更制御部１２２は、第１の実行単位が生成されているホストとは異なるホスト上に第２の実行単位を生成してよい。変更制御部１２２は、第１の実行単位が生成されているホスト上に第２の実行単位を生成してもよい。

実行単位生成部１１６は、記憶部１１２に記憶されている、割当リソース情報を含む一の実行単位テンプレートを用いて第１の実行単位を生成してよい。変更制御部１２２は、割当リソース情報を変更した当該一の実行単位テンプレートを用いて第２の実行単位を生成してよい。

変更制御部１２２は、第１の実行単位のアプリケーションの実行主体を第２の実行単位に切り替えさせた後、第１の実行単位を削除してよい。これにより、他の実行単位に割当可能なリソースを増やすことができる。

変更制御部１２２は、第１の実行単位のアプリケーションの実行主体を第２の実行単位に切り替えさせた後、第１の実行単位を削除せずに維持してもよい。変更制御部１２２は、第１の実行単位のアプリケーションの実行主体を第２の実行単位に切り替えさせた後、予め定められた条件が満たされたことに応じて、第２の実行単位と第１の実行単位の間で同期処理を実行させた後、第２の実行単位のアプリケーションの実行主体を第１の実行単位に切り替えさせてよい。予め定められた条件は、変更決定部１２０が、第２の実行単位のリソース量を変更することを決定したことによって満たされてよい。これにより、第１の実行単位のスケールアップ及びスケールダウンが比較的短時間で発生する場合に、効率的なスケールアップ及びスケールダウンを実現することが可能となる。

以下、具体例を挙げて説明する。下記表１は、性能監視部１１８によって監視されるホストのリソース利用率を示す。ここでは、ホストＡ及びホストＢが監視対象である場合を例示している。

下記表２は、性能監視部１１８によって監視される、ホスト上で動作するアプリケーションの割当リソースと、サービス稼働状況を示す。ここでは、ホストＡ上で動作するアプリＡ及びアプリＢが監視対象である場合を例示している。

下記表３は、記憶部１１２に記憶されている複数の実行単位テンプレートを示す。ここでは、実行単位テンプレートの例として、インスタンスフレーバＡ及びインスタンスフレーバＢを例示している。

表１に示されるように、本例において、ホストＡ及びホストＢは、ＣＰＵリソース：３２、メモリリソース：５１２、ＮＷ（Ｎｅｔｗｏｒｋ）リソース（ＮＷ帯域）：１０を有する。ホストＡは、３２ＣＰＵリソース中２４ＣＰＵリソースを利用しており、５１２メモリリソース中３８４メモリリソースを利用しており、１０ＮＷリソース中３ＮＷリソースを利用している。

表２に示されるように、アプリＡには、１６ＣＰＵリソース、２５６メモリリソース、２ＮＷリソースが割り当てられており、アプリＢには、８ＣＰＵリソース、１２８メモリリソース、１ＮＷリソースが割り当てられている。

変更決定部１２０は、例えば、表２を参照し、セッションやスループットの性能情報が、予め定められた閾値（例えば、容量の半分以下（４５％等））を下回ったことに応じて、アプリＡのリソース量を減少させることを決定する。変更制御部１２２は、フレーバＢを用いることにより、ホストＢに実行単位を生成して、アプリＡ´を生成し、アプリＡと同等のアプリケーション設定を実行する。変更制御部１２２は、ホストＡ上のアプリＡと、ホストＢ上のアプリＡ´との間で、ステートフル情報の同期を実行させる。同期終了後、変更制御部１２２は、アプリＡからアプリＡ´への切り替え処理を実施する。変更制御部１２２は、既存の冗長構成での切り替え手法を用いて、切り替え処理を実施してよい。変更決定部１２０は、切り替え処理実施後、アプリＡを削除してよい。なお、変更決定部１２０は、後々のスケーリングを考慮して、切り替え処理実施後に、アプリＡを維持してもよい。

スケール制御装置１００は、図４において説明した機能と、図７において説明した機能との両方を備えてもよい。この場合、記憶部１０２が記憶部１１２を兼ね、登録部１０４が登録部１１４を兼ね、性能監視部１０８が性能監視部１１８を兼ねてよく、スケール制御装置１００は、記憶部１０２、登録部１０４、リソース割当部１０６、性能監視部１０８、上限制御部１１０、実行単位生成部１１６、変更決定部１２０、及び変更制御部１２２を備えてよい。

図８は、スケール制御装置１００として機能するコンピュータ１２００のハードウェア構成の一例を概略的に示す。コンピュータ１２００にインストールされたプログラムは、コンピュータ１２００を、本実施形態に係る装置の１又は複数の「部」として機能させ、又はコンピュータ１２００に、本実施形態に係る装置に関連付けられるオペレーション又は当該１又は複数の「部」を実行させることができ、及び／又はコンピュータ１２００に、本実施形態に係るプロセス又は当該プロセスの段階を実行させることができる。そのようなプログラムは、コンピュータ１２００に、本明細書に記載のフローチャート及びブロック図のブロックのうちのいくつか又はすべてに関連付けられた特定のオペレーションを実行させるべく、ＣＰＵ１２１２によって実行されてよい。

本実施形態によるコンピュータ１２００は、ＣＰＵ１２１２、ＲＡＭ１２１４、及びグラフィックコントローラ１２１６を含み、それらはホストコントローラ１２１０によって相互に接続されている。コンピュータ１２００はまた、通信インタフェース１２２２、記憶装置１２２４、ＤＶＤドライブ、及びＩＣカードドライブのような入出力ユニットを含み、それらは入出力コントローラ１２２０を介してホストコントローラ１２１０に接続されている。ＤＶＤドライブは、ＤＶＤ－ＲＯＭドライブ及びＤＶＤ－ＲＡＭドライブ等であってよい。記憶装置１２２４は、ハードディスクドライブ及びソリッドステートドライブ等であってよい。コンピュータ１２００はまた、ＲＯＭ１２３０及びキーボードのようなレガシの入出力ユニットを含み、それらは入出力チップ１２４０を介して入出力コントローラ１２２０に接続されている。

ＣＰＵ１２１２は、ＲＯＭ１２３０及びＲＡＭ１２１４内に格納されたプログラムに従い動作し、それにより各ユニットを制御する。グラフィックコントローラ１２１６は、ＲＡＭ１２１４内に提供されるフレームバッファ等又はそれ自体の中に、ＣＰＵ１２１２によって生成されるイメージデータを取得し、イメージデータがディスプレイデバイス１２１８上に表示されるようにする。

通信インタフェース１２２２は、ネットワークを介して他の電子デバイスと通信する。記憶装置１２２４は、コンピュータ１２００内のＣＰＵ１２１２によって使用されるプログラム及びデータを格納する。ＤＶＤドライブは、プログラム又はデータをＤＶＤ－ＲＯＭ等から読み取り、記憶装置１２２４に提供する。ＩＣカードドライブは、プログラム及びデータをＩＣカードから読み取り、及び／又はプログラム及びデータをＩＣカードに書き込む。

ＲＯＭ１２３０はその中に、アクティブ化時にコンピュータ１２００によって実行されるブートプログラム等、及び／又はコンピュータ１２００のハードウェアに依存するプログラムを格納する。入出力チップ１２４０はまた、様々な入出力ユニットをＵＳＢポート、パラレルポート、シリアルポート、キーボードポート、マウスポート等を介して、入出力コントローラ１２２０に接続してよい。

プログラムは、ＤＶＤ－ＲＯＭ又はＩＣカードのようなコンピュータ可読記憶媒体によって提供される。プログラムは、コンピュータ可読記憶媒体から読み取られ、コンピュータ可読記憶媒体の例でもある記憶装置１２２４、ＲＡＭ１２１４、又はＲＯＭ１２３０にインストールされ、ＣＰＵ１２１２によって実行される。これらのプログラム内に記述される情報処理は、コンピュータ１２００に読み取られ、プログラムと、上記様々なタイプのハードウェアリソースとの間の連携をもたらす。装置又は方法が、コンピュータ１２００の使用に従い情報のオペレーション又は処理を実現することによって構成されてよい。

例えば、通信がコンピュータ１２００及び外部デバイス間で実行される場合、ＣＰＵ１２１２は、ＲＡＭ１２１４にロードされた通信プログラムを実行し、通信プログラムに記述された処理に基づいて、通信インタフェース１２２２に対し、通信処理を命令してよい。通信インタフェース１２２２は、ＣＰＵ１２１２の制御の下、ＲＡＭ１２１４、記憶装置１２２４、ＤＶＤ－ＲＯＭ、又はＩＣカードのような記録媒体内に提供される送信バッファ領域に格納された送信データを読み取り、読み取られた送信データをネットワークに送信し、又はネットワークから受信した受信データを記録媒体上に提供される受信バッファ領域等に書き込む。

また、ＣＰＵ１２１２は、記憶装置１２２４、ＤＶＤドライブ（ＤＶＤ－ＲＯＭ）、ＩＣカード等のような外部記録媒体に格納されたファイル又はデータベースの全部又は必要な部分がＲＡＭ１２１４に読み取られるようにし、ＲＡＭ１２１４上のデータに対し様々なタイプの処理を実行してよい。ＣＰＵ１２１２は次に、処理されたデータを外部記録媒体にライトバックしてよい。

様々なタイプのプログラム、データ、テーブル、及びデータベースのような様々なタイプの情報が記録媒体に格納され、情報処理を受けてよい。ＣＰＵ１２１２は、ＲＡＭ１２１４から読み取られたデータに対し、本開示の随所に記載され、プログラムの命令シーケンスによって指定される様々なタイプのオペレーション、情報処理、条件判断、条件分岐、無条件分岐、情報の検索／置換等を含む、様々なタイプの処理を実行してよく、結果をＲＡＭ１２１４に対しライトバックする。また、ＣＰＵ１２１２は、記録媒体内のファイル、データベース等における情報を検索してよい。例えば、各々が第２の属性の属性値に関連付けられた第１の属性の属性値を有する複数のエントリが記録媒体内に格納される場合、ＣＰＵ１２１２は、当該複数のエントリの中から、第１の属性の属性値が指定されている条件に一致するエントリを検索し、当該エントリ内に格納された第２の属性の属性値を読み取り、それにより予め定められた条件を満たす第１の属性に関連付けられた第２の属性の属性値を取得してよい。

上で説明したプログラム又はソフトウエアモジュールは、コンピュータ１２００上又はコンピュータ１２００近傍のコンピュータ可読記憶媒体に格納されてよい。また、専用通信ネットワーク又はインターネットに接続されたサーバシステム内に提供されるハードディスク又はＲＡＭのような記録媒体が、コンピュータ可読記憶媒体として使用可能であり、それによりプログラムを、ネットワークを介してコンピュータ１２００に提供する。

本実施形態におけるフローチャート及びブロック図におけるブロックは、オペレーションが実行されるプロセスの段階又はオペレーションを実行する役割を持つ装置の「部」を表わしてよい。特定の段階及び「部」が、専用回路、コンピュータ可読記憶媒体上に格納されるコンピュータ可読命令と共に供給されるプログラマブル回路、及び／又はコンピュータ可読記憶媒体上に格納されるコンピュータ可読命令と共に供給されるプロセッサによって実装されてよい。専用回路は、デジタル及び／又はアナログハードウェア回路を含んでよく、集積回路（ＩＣ）及び／又はディスクリート回路を含んでよい。プログラマブル回路は、例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、及びプログラマブルロジックアレイ（ＰＬＡ）等のような、論理積、論理和、排他的論理和、否定論理積、否定論理和、及び他の論理演算、フリップフロップ、レジスタ、並びにメモリエレメントを含む、再構成可能なハードウェア回路を含んでよい。

コンピュータ可読記憶媒体は、適切なデバイスによって実行される命令を格納可能な任意の有形なデバイスを含んでよく、その結果、そこに格納される命令を有するコンピュータ可読記憶媒体は、フローチャート又はブロック図で指定されたオペレーションを実行するための手段を作成すべく実行され得る命令を含む、製品を備えることになる。コンピュータ可読記憶媒体の例としては、電子記憶媒体、磁気記憶媒体、光記憶媒体、電磁記憶媒体、半導体記憶媒体等が含まれてよい。コンピュータ可読記憶媒体のより具体的な例としては、フロッピー（登録商標）ディスク、ディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭ又はフラッシュメモリ）、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、静的ランダムアクセスメモリ（ＳＲＡＭ）、コンパクトディスクリードオンリメモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、ブルーレイ（登録商標）ディスク、メモリスティック、集積回路カード等が含まれてよい。

コンピュータ可読命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、又はＳｍａｌｌｔａｌｋ（登録商標）、ＪＡＶＡ（登録商標）、Ｃ＋＋等のようなオブジェクト指向プログラミング言語、及び「Ｃ」プログラミング言語又は同様のプログラミング言語のような従来の手続型プログラミング言語を含む、１又は複数のプログラミング言語の任意の組み合わせで記述されたソースコード又はオブジェクトコードのいずれかを含んでよい。

コンピュータ可読命令は、汎用コンピュータ、特殊目的のコンピュータ、若しくは他のプログラム可能なデータ処理装置のプロセッサ、又はプログラマブル回路が、フローチャート又はブロック図で指定されたオペレーションを実行するための手段を生成するために当該コンピュータ可読命令を実行すべく、ローカルに又はローカルエリアネットワーク（ＬＡＮ）、インターネット等のようなワイドエリアネットワーク（ＷＡＮ）を介して、汎用コンピュータ、特殊目的のコンピュータ、若しくは他のプログラム可能なデータ処理装置のプロセッサ、又はプログラマブル回路に提供されてよい。プロセッサの例としては、コンピュータプロセッサ、処理ユニット、マイクロプロセッサ、デジタル信号プロセッサ、コントローラ、マイクロコントローラ等を含む。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。その様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

特許請求の範囲、明細書、及び図面中において示した装置、システム、プログラム、及び方法における動作、手順、ステップ、及び段階などの各処理の実行順序は、特段「より前に」、「先立って」などと明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り、任意の順序で実現しうることに留意すべきである。特許請求の範囲、明細書、及び図面中の動作フローに関して、便宜上「まず、」、「次に、」などを用いて説明したとしても、この順で実施することが必須であることを意味するものではない。

本発明によれば、例えば、ハイパーバイザ型仮想化において柔軟なスケーリング手法を実現できることから、効率性を向上したネットワークシステムを提供可能なため、持続可能な開発目標（ＳＤＧｓ）の目標９「産業と技術革新の基盤をつくろう」の達成に貢献することができる。

１００ スケール制御装置、１０２ 記憶部、１０４ 登録部、１０６ リソース割当部、１０８ 性能監視部、１１０ 上限制御部、１１２ 記憶部、１１４ 登録部、１１６ 実行単位生成部、１１８ 性能監視部、１２０ 変更決定部、１２２ 変更制御部、２００ 仮想化制御装置、３１０ ホスト、３２０ ＣＰＵリソース、３３０ メモリリソース、３５０ ホスト、４１０ ゲストＯＳ、４１２ プロセス管理、４１４ アプリプロセス、４２０ 仮想ＣＰＵリソース、４３０ 仮想メモリリソース、４５０ ゲストＯＳ、４５２ プロセス管理、４５４ アプリプロセス、４６０ 仮想ＣＰＵリソース、４７０ 仮想メモリリソース、５１０ 実行単位、５２０ 実行単位、６１０ 状態、６２０ 状態、６３０ 状態、６４０ 状態、６５０ 状態、６６０ 状態、１２００ コンピュータ、１２１０ ホストコントローラ、１２１２ ＣＰＵ、１２１４ ＲＡＭ、１２１６ グラフィックコントローラ、１２１８ ディスプレイデバイス、１２２０ 入出力コントローラ、１２２２ 通信インタフェース、１２２４ 記憶装置、１２３０ ＲＯＭ、１２４０ 入出力チップ

Claims (17)

1. ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当部と、
   前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御部であって、前記複数のゲストＯＳのうちの第１のゲストＯＳにおける前記仮想リソースの利用率が予め定められた閾値を下回った場合に、前記第１のゲストＯＳにおいて利用されていない仮想リソースの分、前記第１のゲストＯＳの前記仮想リソースの利用可能量の上限を減少させ、減少させた分、前記複数のゲストＯＳのうちの第２のゲストＯＳの前記仮想リソースの利用可能量の上限を増加させる上限制御部と
   を備える制御装置。
2. 前記上限制御部は、前記複数のゲストＯＳの状況に応じて、前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えない範囲内で、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を調整する、請求項１に記載の制御装置。
3. 前記上限制御部は、前記複数のゲストＯＳのうちの第１のゲストＯＳにおける前記仮想リソースの利用率が予め定められた閾値を超えた場合に、前記複数のゲストＯＳのうちの第２のゲストＯＳの前記仮想リソースの利用可能量の上限を減少させ、前記第１のゲストＯＳの前記仮想リソースの利用可能量の上限を増加させる、請求項２に記載の制御装置。
4. 前記リソース割当部は、前記複数のゲストＯＳに対して、前記ホストが有するＣＰＵリソースの量を超える量の仮想ＣＰＵリソースを割り当て、
   前記上限制御部は、前記複数のゲストＯＳによる前記仮想ＣＰＵリソースの利用量の合計が前記ホストの前記ＣＰＵリソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想ＣＰＵリソースの利用可能量の上限を制御する、請求項１から３のいずれか一項に記載の制御装置。
5. 前記上限制御部は、前記複数のゲストＯＳのうちの第１のゲストＯＳにおけるＣＰＵ制御プロセスの起動管理によって並列処理数を減少させることによって、前記第１のゲストＯＳの前記仮想リソースの利用可能量の上限を減少させる、請求項４に記載の制御装置。
6. 前記リソース割当部は、前記複数のゲストＯＳに対して、前記ホストが有するメモリリソースの量を超える量の仮想メモリリソースを割り当て、
   前記上限制御部は、前記複数のゲストＯＳによる前記仮想メモリリソースの利用量の合計が前記ホストの前記メモリリソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想メモリリソースの利用可能量の上限を制御する、請求項１から３のいずれか一項に記載の制御装置。
7. 前記上限制御部は、前記複数のゲストＯＳのうちの第１のゲストＯＳにメモリ領域を再構築させて、前記第１のゲストＯＳの前記仮想メモリリソースの利用可能量の上限を減少させる、請求項６に記載の制御装置。
8. ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当部と、
   前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御部であって、前記複数のゲストＯＳのうちの第１のゲストＯＳにおける前記仮想リソースの利用率が予め定められた閾値を超えた場合に、前記複数のゲストＯＳのうちの第２のゲストＯＳの前記仮想リソースの利用可能量の上限を減少させ、前記第１のゲストＯＳの前記仮想リソースの利用可能量の上限を増加させる上限制御部と
   を備える制御装置。
9. ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有するＣＰＵリソースの量を超える量の仮想ＣＰＵリソースを割り当てるリソース割当部と、
   前記複数のゲストＯＳによる前記仮想ＣＰＵリソースの利用量の合計が前記ホストの前記ＣＰＵリソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想ＣＰＵリソースの利用可能量の上限を制御する上限制御部であって、前記複数のゲストＯＳのうちの第１のゲストＯＳにおけるＣＰＵ制御プロセスの起動管理によって並列処理数を減少させることによって、前記第１のゲストＯＳの前記仮想ＣＰＵリソースの利用可能量の上限を減少させる上限制御部と
   を備える制御装置。
10. ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当部と、
    前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御部と
    を備え、
    前記ホストの外部に位置する、制御装置。
11. ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当部と、
    前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御部と、
    を備え、
    前記ホストのリソースを割り当ててアプリケーションの実行単位を前記ホスト上に生成する実行単位生成部と、
    前記実行単位生成部によって生成された第１の実行単位のリソース量を変更することを決定する変更決定部と、
    前記変更決定部により変更することが決定された場合に、前記第１の実行単位と同一設定であり、前記第１の実行単位とは異なる量のリソースを割り当てた第２の実行単位を生成させ、前記第１の実行単位と前記第２の実行単位との間で同期処理を実行させた後、前記第１の実行単位のアプリケーションの実行主体を前記第２の実行単位に切り替えさせる変更制御部と
    を更に備える制御装置。
12. コンピュータを、請求項１から１１のいずれか一項に記載の制御装置として機能させるためのプログラム。
13. コンピュータによって実行される制御方法であって、
    ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当段階と、
    前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御段階であって、前記複数のゲストＯＳのうちの第１のゲストＯＳにおける前記仮想リソースの利用率が予め定められた閾値を下回った場合に、前記第１のゲストＯＳにおいて利用されていない仮想リソースの分、前記第１のゲストＯＳの前記仮想リソースの利用可能量の上限を減少させ、減少させた分、前記複数のゲストＯＳのうちの第２のゲストＯＳの前記仮想リソースの利用可能量の上限を増加させる上限制御段階と
    を備える制御方法。
14. コンピュータによって実行される制御方法であって、
    ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当段階と、
    前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御段階であって、前記複数のゲストＯＳのうちの第１のゲストＯＳにおける前記仮想リソースの利用率が予め定められた閾値を超えた場合に、前記複数のゲストＯＳのうちの第２のゲストＯＳの前記仮想リソースの利用可能量の上限を減少させ、前記第１のゲストＯＳの前記仮想リソースの利用可能量の上限を増加させる上限制御段階と
    を備える制御方法。
15. コンピュータによって実行される制御方法であって、
    ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有するＣＰＵリソースの量を超える量の仮想ＣＰＵリソースを割り当てるリソース割当段階と、
    前記複数のゲストＯＳによる前記仮想ＣＰＵリソースの利用量の合計が前記ホストの前記ＣＰＵリソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想ＣＰＵリソースの利用可能量の上限を制御する上限制御段階であって、前記複数のゲストＯＳのうちの第１のゲストＯＳにおけるＣＰＵ制御プロセスの起動管理によって並列処理数を減少させることによって、前記第１のゲストＯＳの前記仮想ＣＰＵリソースの利用可能量の上限を減少させる上限制御段階と
    を備える制御方法。
16. ホストの外に位置するコンピュータによって実行される制御方法であって、
    前記ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当段階と、
    前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御段階と
    を備える制御方法。
17. コンピュータによって実行される制御方法であって、
    ホスト上で動作する複数のゲストＯＳに対して、前記ホストが有する物理リソースの量を超える量の仮想リソースを割り当てるリソース割当段階と、
    前記複数のゲストＯＳによる前記仮想リソースの利用量の合計が前記ホストの前記物理リソースの量を超えないように、前記複数のゲストＯＳのそれぞれの前記仮想リソースの利用可能量の上限を制御する上限制御段階と、
    を備え、
    前記ホストのリソースを割り当ててアプリケーションの実行単位を前記ホスト上に生成する実行単位生成段階と、
    前記実行単位生成段階において生成された前記実行単位のリソース量を変更することを決定する変更決定段階と、
    前記実行単位と同一設定であり、前記実行単位とは異なる量のリソースを割り当てた他の実行単位を生成し、前記実行単位と前記他の実行単位の間で同期処理を実行させた後、前記実行単位のアプリケーションの実行主体を前記他の実行単位に切り替えさせるリソース変更制御段階と
    を更に備える制御方法。

Images