ホーム > 特許ランキング > 日本電信電話株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-10-17
(45)【発行日】2022-10-25
(54)【発明の名称】仮想化基盤および仮想化基盤のスケーリング管理方法
(51)【国際特許分類】
G06F 9/50 20060101AFI20221018BHJP
G06F 9/455 20060101ALI20221018BHJP
【ＦＩ】
G06F9/50 150Z
G06F9/455 150
【請求項の数】
10
(21)【出願番号】P 2019012719
(22)【出願日】2019-01-29
(65)【公開番号】P2020123003
(43)【公開日】2020-08-13
【審査請求日】2021-05-10
(73)【特許権者】
【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
(74)【代理人】
【識別番号】110001807
【氏名又は名称】弁理士法人磯野国際特許商標事務所
(72)【発明者】
【氏名】岩佐 絵里子
【審査官】漆原 孝治
(56)【参考文献】
【文献】特開２０１１－０９０５９４（ＪＰ，Ａ）
【文献】特開２０１５－１１５０５９（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ９／５０
Ｇ０６Ｆ ９／４５５
(57)【特許請求の範囲】
【請求項1】
複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視するリソース監視部と、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行うスケーリング実施判定部と、
各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行うリソース払出制御部と、
前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、スケールアウト、スケールアップ、スケールアウトおよびスケールアップの併用のうち何れかのスケーリング方法を選択するスケーリング方法判定部と、
前記スケーリング方法判定部が選択したスケーリング方法を前記リソース払出制御部に対して指示するスケーリング指示部と、
を備え、
前記リソース払出制御部は、スケールアウトまたは併用がスケーリング方法として指示されている場合、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との間に余剰があるならば、スケールアップによるリソース量から前記余剰を差し引くか、またはスケールダウンを併用する、
ことを特徴とする仮想化基盤。
【請求項2】
複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視するリソース監視部と、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行うスケーリング実施判定部と、
各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行うリソース払出制御部と、
前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、スケールアウト、スケールアップ、スケールアウトおよびスケールアップの併用のうち何れかのスケーリング方法を選択するスケーリング方法判定部と、
前記スケーリング方法判定部が選択したスケーリング方法を前記リソース払出制御部に対して指示するスケーリング指示部と、
を備え、
前記リソース払出制御部は、スケールアウトまたは併用がスケーリング方法として指示されており、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との余剰がスケールアップによるリソース量よりも大きいならば、前記余剰からスケールアップによるリソース量を減じた量を稼働中の実行環境からリソース割当変更手段によって削除し、かつスケールアップを行わない、
ことを特徴とする仮想化基盤。
【請求項3】
前記スケーリング方法判定部は、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースより多い場合、スケールアップによるスケーリング方法を選択する、ことを特徴とする請求項１または２に記載の仮想化基盤。
【請求項4】
前記リソース払出制御部は、スケールアップによるスケーリング方法で各前記コンピュートのリソース割当を変更する場合、リソース割当変更手段によってリソース割当量を変更する、ことを特徴とする請求項３に記載の仮想化基盤。
【請求項5】
前記スケーリング方法判定部は、何れかの実行環境が稼働しているコンピュートのいずれにも空きリソースがない場合、スケールアウトによるスケーリング方法を選択する、ことを特徴とする請求項４に記載の仮想化基盤。
【請求項6】
前記スケーリング方法判定部は、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースよりも少ない場合、スケールアウトおよびスケールアップの併用によるスケーリング方法を選択する、ことを特徴とする請求項５に記載の仮想化基盤。
【請求項7】
複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視するリソース監視部と、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行うスケーリング実施判定部と、
各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行うリソース払出制御部と、
前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースより多い場合、スケールアップによるスケーリング方法を選択し、何れかの実行環境が稼働しているコンピュートのいずれにも空きリソースがない場合、スケールアウトによるスケーリング方法を選択し、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースよりも少ない場合、スケールアウトおよびスケールアップの併用によるスケーリング方法を選択する選択するスケーリング方法判定部と、
前記スケーリング方法判定部が選択したスケーリング方法を前記リソース払出制御部に対して指示するスケーリング指示部と、
を備え、
前記リソース払出制御部は、スケールアップによるスケーリング方法で各前記コンピュートのリソース割当を変更する場合、リソース割当変更手段によってリソース割当量を変更し、スケールアウトまたは併用がスケーリング方法として指示されている場合、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との間に余剰があるならば、スケールアップによるリソース量から前記余剰を差し引くか、またはスケールダウンを併用する、
ことを特徴とする仮想化基盤。
【請求項8】
リソース監視部は、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視し、スケーリング実施判定部は、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行い、
スケーリング方法判定部は、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、スケールアウト、スケールアップ、スケールアウトおよびスケールアップの併用のうち何れかのスケーリング方法を選択し、
スケーリング指示部は、前記スケーリング方法判定部が選択したスケーリング方法をリソース払出制御部に対して指示し、
前記リソース払出制御部は、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行い、
スケールアウトまたは併用がスケーリング方法として指示されている場合、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との間に余剰があるならば、スケールアップによるリソース量から前記余剰を差し引くか、またはスケールダウンを併用する、
ことを特徴とする仮想化基盤のスケーリング管理方法。
【請求項9】
リソース監視部は、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視し、スケーリング実施判定部は、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行い、
スケーリング方法判定部は、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、スケールアウト、スケールアップ、スケールアウトおよびスケールアップの併用のうち何れかのスケーリング方法を選択し、
スケーリング指示部は、前記スケーリング方法判定部が選択したスケーリング方法をリソース払出制御部に対して指示し、
前記リソース払出制御部は、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行い、
スケールアウトまたは併用がスケーリング方法として指示されており、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との余剰がスケールアップによるリソース量よりも大きいならば、前記余剰からスケールアップによるリソース量を減じた量を稼働中の実行環境からリソース割当変更手段によって削除し、かつスケールアップを行わない、
ことを特徴とする仮想化基盤のスケーリング管理方法。
【請求項10】
リソース監視部は、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視し、スケーリング実施判定部は、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行い、
スケーリング方法判定部は、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースより多い場合、スケールアップによるスケーリング方法を選択し、
何れかの実行環境が稼働しているコンピュートのいずれにも空きリソースがない場合、スケールアウトによるスケーリング方法を選択し、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースよりも少ない場合、スケールアウトおよびスケールアップの併用によるスケーリング方法を選択し、
スケーリング指示部は、前記スケーリング方法判定部が選択したスケーリング方法をリソース払出制御部に対して指示し、
前記リソース払出制御部は、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行い、
スケールアップによるスケーリング方法で各前記コンピュートのリソース割当を変更する場合、リソース割当変更手段によってリソース割当量を変更し、
スケールアウトまたは併用がスケーリング方法として指示されている場合、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との間に余剰があるならば、スケールアップによるリソース量から前記余剰を差し引くか、またはスケールダウンを併用する、
ことを特徴とする仮想化基盤のスケーリング管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、同一コンピュート内のスケーリングについてはスケールアップを、コンピュートを超えるスケーリングについてはスケールアウトを適用する仮想化基盤および仮想化基盤のスケーリング管理方法に関する。
【背景技術】
【0002】
仮想化基盤とは、仮想化技術を用いてサーバやネットワークといった物理資源を抽象化・隠蔽し、複数のアプリケーションやサービスに対して共通基盤として準備された仮想環境、またそれらの仮想環境を管理するシステムのことをいう。
【0003】
近年では通信サービスにおいても、仮想化技術を適用したネットワーク機能の仮想化（ＮＦＶ：Network Functions Virtualization）の採用が進展している。ネットワークの仮想化とは、従来では専用のハードウェアを用いて実現されていたネットワーク機能を、ソフトウェア化して汎用サーバ上で動作させるように構成することをいう。このようなネットワーク機能の仮想化技術をキャリア網に適用することで、経済的にスケーラビリティと信頼性を両立させることや、迅速なサービス提供、サービスごとの需要に応じた柔軟なリソース割り当てと、ハードウェアの寿命に縛られないサービス展開が実現できると期待されている。
【0004】
OpenStackとはクラウド環境構築用のオープンソースソフトウェア群のことをいう。非特許文献１に記載のOpenStack Novaは、OpenStackコンポーネントの1つであり、仮想マシンの制御や管理を担当する。Novaは、仮想マシンを作成する際に、flavorと呼ばれる仮想ハードウェアのテンプレートを用い、この仮想ハードウェア上で仮想マシンを起動させる。このテンプレートには、ＣＰＵ（Central Processing Unit）やメモリやディスク等のリソース割当条件が記載されている。
【0005】
非特許文献２に記載のOpenStack Heatは、OpenStackコンポーネントの1つであり、リソースの配置を定義したテンプレートを用いて、システムの構築を自動化するオーケストレーションを担当する。OpenStack Heatは、テンプレート内のAutoScalingGroupやScalingPolicyにスケーリング対象やスケーリングルールを記述すると、その条件に従ってスケールアウトする。なおOpenStackでは、ホットプラグのように仮想マシンを無停止でリソース割当を変更すること、即ち無停止でスケールアップをすることはできない。
【0006】
仮想化基盤上では、新たな実行環境であるＶＭ（Virtual Machine：仮想マシン）やコンテナの生成および既存の実行環境であるＶＭやコンテナの削除が容易になることから、仮想化基盤上に搭載したアプリケーションをスケーリングする際には、処理量に応じてＶＭやコンテナの数を増減させることにより処理能力を最適化するスケールアウトやスケールインの方法が採用される。具体的には、前段にロードバランサを配置し、仮想マシン群またはコンテナ群（クラスタ）に対して処理を振り分ける構成をとることが多い。
【0007】
一方、仮想マシンやコンテナ自体の処理能力を増減させることで処理能力を最適化するスケールアップやスケールダウンの方法も存在する。代表的な技術であるホットプラグでは、仮想マシンに割り当てるＣＰＵやメモリやディスクを柔軟に追加または削除することが可能である。
【先行技術文献】
【非特許文献】
【0008】
【文献】“OpenStack Compute (nova)”，インターネット<URL:https://docs.openstack.org/nova/latest/>
【文献】“OpenStack-Heat”，インターネット<URL:https://docs.openstack.org/heat/latest/>
【発明の概要】
【発明が解決しようとする課題】
【0009】
上記したスケールアウトは、以下の問題がある。
第１の問題は、クラスタを構成する仮想マシンやコンテナ間の負荷の偏りや特定の仮想マシンまたはコンテナへの突発的な負荷増に対応できないことである。
第２の問題は、仮想マシンやコンテナのイメージがコンピュート上にない場合は、イメージコピーに時間を要することである。
第３の問題は、アプリケーションによっては、仮想マシンやコンテナの起動後のコンフィグ投入や、仮想マシンやコンテナ間の同期処理に長い時間がかかるケースがあることである。
第１の問題は、クラスタを構成する仮想マシンやコンテナ間の負荷の偏りや特定の仮想マシンまたはコンテナへの突発的な負荷増に対応できないことである。
第２の問題は、仮想マシンやコンテナのイメージがコンピュート上にない場合は、イメージコピーに時間を要することである。
第３の問題は、アプリケーションによっては、仮想マシンやコンテナの起動後のコンフィグ投入や、仮想マシンやコンテナ間の同期処理に長い時間がかかるケースがあることである。
【0010】
第４の問題は、特に仮想マシンでは、仮想マシン起動に数分単位で時間がかかる懸念があることである。リソースの追加単位が仮想マシンの起動時に用いる仮想ハードウェアのテンプレートサイズに依存するため、追加粒度を細かくすることが難しい。追加粒度を細かくするとスケーリング回数が増えて第２～第４の問題が課題となるため、細かくすることは難しい。
【0011】
一方で、仮想マシンやコンテナ自体の処理能力を増減させることで処理能力を最適化するスケールアップやスケールダウンの方法も存在する。スケールアップやスケールダウンを実現する代表的な技術であるホットプラグでは、仮想マシンに割り当てるＣＰＵやメモリやディスクを柔軟に追加および削除することが可能である。この技術は仮想マシンの生成は伴わないため、処理は１秒未満で完了するというメリットがある。しかし、スケールアップは、同一コンピュート上に仮想マシンが動作しており、かつ余剰のリソースがなければならない。
【0012】
そこで、本発明は、高速であり、かつ粒度の細かいスケーリングを実現することを課題とする。
【課題を解決するための手段】
【0013】
前記した課題を解決するため、請求項１に記載の発明では、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視するリソース監視部と、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行うスケーリング実施判定部と、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行うリソース払出制御部と、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、スケールアウト、スケールアップ、スケールアウトおよびスケールアップの併用のうち何れかのスケーリング方法を選択するスケーリング方法判定部と、前記スケーリング方法判定部が選択したスケーリング方法を前記リソース払出制御部に対して指示するスケーリング指示部と、を備え、前記リソース払出制御部は、スケールアウトまたは併用がスケーリング方法として指示されている場合、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との間に余剰があるならば、スケールアップによるリソース量から前記余剰を差し引くか、またはスケールダウンを併用する、ことを特徴とする仮想化基盤とした。
【0014】
このようにすることで、高速であり、かつ粒度の細かいスケーリングを実現できる。
請求項２に記載の発明では、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視するリソース監視部と、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行うスケーリング実施判定部と、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行うリソース払出制御部と、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、スケールアウト、スケールアップ、スケールアウトおよびスケールアップの併用のうち何れかのスケーリング方法を選択するスケーリング方法判定部と、前記スケーリング方法判定部が選択したスケーリング方法を前記リソース払出制御部に対して指示するスケーリング指示部と、を備え、前記リソース払出制御部は、スケールアウトまたは併用がスケーリング方法として指示されており、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との余剰がスケールアップによるリソース量よりも大きいならば、前記余剰からスケールアップによるリソース量を減じた量を稼働中の実行環境からリソース割当変更手段によって削除し、かつスケールアップを行わない、ことを特徴とする仮想化基盤とした。
このようにすることで、高速であり、かつ粒度の細かいスケーリングを実現できる。
請求項２に記載の発明では、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視するリソース監視部と、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行うスケーリング実施判定部と、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行うリソース払出制御部と、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、スケールアウト、スケールアップ、スケールアウトおよびスケールアップの併用のうち何れかのスケーリング方法を選択するスケーリング方法判定部と、前記スケーリング方法判定部が選択したスケーリング方法を前記リソース払出制御部に対して指示するスケーリング指示部と、を備え、前記リソース払出制御部は、スケールアウトまたは併用がスケーリング方法として指示されており、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との余剰がスケールアップによるリソース量よりも大きいならば、前記余剰からスケールアップによるリソース量を減じた量を稼働中の実行環境からリソース割当変更手段によって削除し、かつスケールアップを行わない、ことを特徴とする仮想化基盤とした。
このようにすることで、高速であり、かつ粒度の細かいスケーリングを実現できる。
【0015】
請求項３に記載の発明では、前記スケーリング方法判定部は、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースより多い場合、スケールアップによるスケーリング方法を選択する、ことを特徴とする請求項１または２に記載の仮想化基盤とした。
【0016】
このようにすることで、本発明によれば、高速なスケーリングが実現できる。
【0017】
請求項４に記載の発明では、前記リソース払出制御部は、スケールアップによるスケーリング方法で各前記コンピュートのリソース割当を変更する場合、リソース割当変更手段によってリソース割当量を変更する、ことを特徴とする請求項３に記載の仮想化基盤とした。
【0018】
このようにすることで、本発明によれば、粒度の細かいスケーリングが実現できる。
【0019】
請求項５に記載の発明では、前記スケーリング方法判定部は、何れかの実行環境が稼働しているコンピュートのいずれにも空きリソースがない場合、スケールアウトによるスケーリング方法を選択する、ことを特徴とする請求項４に記載の仮想化基盤とした。
【0020】
このようにすることで、本発明によれば、高速なスケーリングが実現できる。
【0021】
請求項６に記載の発明では、前記スケーリング方法判定部は、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースよりも少ない場合、スケールアウトおよびスケールアップの併用によるスケーリング方法を選択する、ことを特徴とする請求項５に記載の仮想化基盤とした。
【0022】
このようにすることで、本発明によれば、粒度の細かいスケーリングが実現できる。
【0023】
請求項７に記載の発明では、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視するリソース監視部と、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行うスケーリング実施判定部と、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行うリソース払出制御部と、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースより多い場合、スケールアップによるスケーリング方法を選択し、何れかの実行環境が稼働しているコンピュートのいずれにも空きリソースがない場合、スケールアウトによるスケーリング方法を選択し、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースよりも少ない場合、スケールアウトおよびスケールアップの併用によるスケーリング方法を選択する選択するスケーリング方法判定部と、前記スケーリング方法判定部が選択したスケーリング方法を前記リソース払出制御部に対して指示するスケーリング指示部と、を備え、前記リソース払出制御部は、スケールアップによるスケーリング方法で各前記コンピュートのリソース割当を変更する場合、リソース割当変更手段によってリソース割当量を変更し、スケールアウトまたは併用がスケーリング方法として指示されている場合、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との間に余剰があるならば、スケールアップによるリソース量から前記余剰を差し引くか、またはスケールダウンを併用する、ことを特徴とする仮想化基盤とした。
【0024】
このようにすることで、高速であり、かつ粒度の細かいスケーリングを実現できる。
【0025】
請求項８に記載の発明では、リソース監視部は、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視し、スケーリング実施判定部は、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行い、スケーリング方法判定部は、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、スケールアウト、スケールアップ、スケールアウトおよびスケールアップの併用のうち何れかのスケーリング方法を選択し、スケーリング指示部は、前記スケーリング方法判定部が選択したスケーリング方法をリソース払出制御部に対して指示し、前記リソース払出制御部は、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行い、スケールアウトまたは併用がスケーリング方法として指示されている場合、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との間に余剰があるならば、スケールアップによるリソース量から前記余剰を差し引くか、またはスケールダウンを併用する、ことを特徴とする仮想化基盤のスケーリング管理方法とした。
【0026】
請求項９に記載の発明では、リソース監視部は、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視し、スケーリング実施判定部は、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行い、スケーリング方法判定部は、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、スケールアウト、スケールアップ、スケールアウトおよびスケールアップの併用のうち何れかのスケーリング方法を選択し、スケーリング指示部は、前記スケーリング方法判定部が選択したスケーリング方法をリソース払出制御部に対して指示し、前記リソース払出制御部は、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行い、スケールアウトまたは併用がスケーリング方法として指示されており、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との余剰がスケールアップによるリソース量よりも大きいならば、前記余剰からスケールアップによるリソース量を減じた量を稼働中の実行環境からリソース割当変更手段によって削除し、かつスケールアップを行わない、ことを特徴とする仮想化基盤のスケーリング管理方法とした。
【0027】
請求項１０に記載の発明では、リソース監視部は、複数のコンピュートの負荷、および前記コンピュート上で稼働している実行環境の負荷を監視し、スケーリング実施判定部は、前記リソース監視部の監視情報に基づき、スケーリングの実施判定と必要なリソース量算出を行い、スケーリング方法判定部は、前記スケーリング実施判定部によるスケーリングの実施判定の際、各前記コンピュートのリソースの空きを確認し、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースより多い場合、スケールアップによるスケーリング方法を選択し、何れかの実行環境が稼働しているコンピュートのいずれにも空きリソースがない場合、スケールアウトによるスケーリング方法を選択し、何れかの実行環境が稼働しているコンピュートの空きリソースの総和が追加リソースよりも少ない場合、スケールアウトおよびスケールアップの併用によるスケーリング方法を選択し、スケーリング指示部は、前記スケーリング方法判定部が選択したスケーリング方法をリソース払出制御部に対して指示し、前記リソース払出制御部は、各前記コンピュートのリソースの管理と各前記実行環境へのリソースの割当を行い、スケールアップによるスケーリング方法で各前記コンピュートのリソース割当を変更する場合、リソース割当変更手段によってリソース割当量を変更し、スケールアウトまたは併用がスケーリング方法として指示されている場合、スケールアウトのリソース量と実行環境の起動時に用いる仮想ハードウェアのテンプレートに基づくスケールアウトのリソース量との間に余剰があるならば、スケールアップによるリソース量から前記余剰を差し引くか、またはスケールダウンを併用する、ことを特徴とする仮想化基盤のスケーリング管理方法とした。
【0028】
このようにすることで、高速であり、かつ粒度の細かいスケーリングを実現できる。
【発明の効果】
【0029】
本発明によれば、高速であり、かつ粒度の細かいスケーリングを実現することが可能となる。
【図面の簡単な説明】
【0030】
【図1】本実施形態に係る仮想化基盤の構成図である。
【図2】本実施形態に係るコンピュートと仮想マシンを示すシステム図である。
【図3】仮想マシンの起動処理を示すフローチャートである。
【図4】クラスタを監視対象にした場合のスケーリング手法の選択処理を示すフローチャートである。
【図5】仮想マシンを監視対象にした場合のスケーリング手法の選択処理を示すフローチャートである。
【図6】リソース管理テーブルの一例を示す図である。
【図7】スケーリング方法とリソース量から、実際にスケールアップまたはスケールアウトするリソース量を算出するフローチャートある。
【図8】各コンピュート上で動作するリソースの選択を示すフローチャートである。
【図9A】クラスタを監視対象にした場合の初期状態を示す図である。
【図9B】クラスタを監視対象にした場合のスケールアップの例を示す図である。
【図9C】クラスタを監視対象にした場合のスケールアップの例を示す図である。
【図9D】クラスタを監視対象にした場合の併用パターンを示す図である。
【図10A】クラスタを監視対象にした場合の初期状態を示す図である。
【図10B】クラスタを監視対象にした場合のスケールアウトの例を示す図である。
【発明を実施するための形態】
【0031】
以降、本発明を実施するための形態を、各図を参照して詳細に説明する。本実施形態は、仮想マシンについてのみ着目した実施形態である。
図１は、本実施形態に係る仮想化基盤の構成図である。図２は、本実施形態に係るコンピュートと仮想マシンを示すシステム図である。以下、図１と図２とを参照しつつ仮想化基盤の各部構成と概略動作について説明する。
仮想化基盤１は、スケーリング部１１と、リソース払出制御部１２と、監視部１３と、記憶部１４とを含んで構成される。
図１は、本実施形態に係る仮想化基盤の構成図である。図２は、本実施形態に係るコンピュートと仮想マシンを示すシステム図である。以下、図１と図２とを参照しつつ仮想化基盤の各部構成と概略動作について説明する。
仮想化基盤１は、スケーリング部１１と、リソース払出制御部１２と、監視部１３と、記憶部１４とを含んで構成される。
【0032】
この仮想化基盤１は、図２に示すように、仮想化技術を用いてサーバやネットワークといったコンピュート３－１～３－４，…を抽象化・隠蔽し、このコンピュート３－１～３－４，…のうち何れかで動作する仮想マシン２ａ，２ｂ，…を管理する。各仮想マシン２ａ，２ｂ，…には、ロードバランサ４が接続され、ローカルネット５を介してインターネット６からトラヒックが振り分けられる。ロードバランサ４も仮想マシンとして構築してもよい。コンピュート３－１～３－４は、仮想マシンごとに、この仮想マシンに割り当てるリソース情報が定義されている仮想マシン設定ファイル３１を保持する。この仮想マシン設定ファイル３１は、例えばXML形式で記載されている。
【0033】
以下、各コンピュート３－１～３－４を特に区別しないときには、単にコンピュート３と記載する。仮想マシン２ａ，２ｂ，…を特に区別しないときには、単に仮想マシン２と記載する。仮想マシン２は、ユーザのアプリケーションを実行するための実行環境である。
コンピュート３は、それぞれ自身で動作する仮想マシン２の設定情報を格納する仮想マシン設定ファイル３１と、仮想マシン２を制御するための制御プログラムを、不図示のＣＰＵが実行することにより具現化される仮想化層３２とを備えている。
コンピュート３は、それぞれ自身で動作する仮想マシン２の設定情報を格納する仮想マシン設定ファイル３１と、仮想マシン２を制御するための制御プログラムを、不図示のＣＰＵが実行することにより具現化される仮想化層３２とを備えている。
【0034】
図１に戻り説明を続ける。スケーリング部１１は、スケーリング方法判定部１１１と、スケーリング指示部１１２と、スケーリング実施判定部１１３とを含んで構成される。このスケーリング部１１は、スケーリング方法の判定とスケーリングの指示を行う。
スケーリング実施判定部１１３は、監視部１３に含まれるリソース監視部１３１の監視情報に基づき、スケーリングを実施するか否かを判定し、スケーリングを実施する場合には必要なリソース量を算出する。
スケーリング実施判定部１１３は、監視部１３に含まれるリソース監視部１３１の監視情報に基づき、スケーリングを実施するか否かを判定し、スケーリングを実施する場合には必要なリソース量を算出する。
【0035】
スケーリング方法判定部１１１は、リソース払出制御部１２に払い出し可能なリソースを問い合わせることで、スケーリングの方法を決定する。スケーリング方法判定部１１１は、スケーリング実施判定部１１３によるスケーリングの実施判定の際、各コンピュート３のリソースの空きを確認し、スケーリング方法として、スケールアウト、スケールアップ、スケールアウトとスケールアップの併用のうちいずれかを選択する。
スケーリング指示部１１２は、スケーリング方法判定部１１１の選択したスケーリング方法を、リソース払出制御部１２に対して指示する。
スケーリング指示部１１２は、スケーリング方法判定部１１１の選択したスケーリング方法を、リソース払出制御部１２に対して指示する。
【0036】
リソース払出制御部１２は、リソース管理部１２１と、リソース抽出選定部１２２と、仮想マシン制御部１２３とを含んで構成される。リソース払出制御部１２は、各コンピュート３のリソースの管理と各仮想マシン２へのリソースの割当を行う。
【0037】
リソース管理部１２１は、記憶部１４のリソース情報リポジトリ１４１に基づき、各コンピュート３や各仮想マシン２が使用しているリソース情報を管理する。
リソース抽出選定部１２２は、リソース管理部１２１にリソース情報を問い合わせて、割り当てるリソースを決定する。リソース管理部１２１は、新規に割り当てたリソースの情報を反映する。なおリソース情報は、リソース情報リポジトリ１４１で管理されている。
リソース抽出選定部１２２は、リソース管理部１２１にリソース情報を問い合わせて、割り当てるリソースを決定する。リソース管理部１２１は、新規に割り当てたリソースの情報を反映する。なおリソース情報は、リソース情報リポジトリ１４１で管理されている。
【0038】
リソース抽出選定部１２２は、仮想マシン制御部１２３にスケーリングの指示を行う。スケーリングとは、仮想マシンの追加や削除、仮想マシンが使用するリソースの割当を変更することをいう。仮想マシン制御部１２３は、コンピュート３の仮想化層３２に対して処理を行い、スケーリング処理を完了させる。
監視部１３は、リソース監視部１３１を含んでいる。このリソース監視部１３１は、複数のコンピュートの負荷、およびこれらコンピュート上で稼働している仮想マシン２の負荷を監視する。
記憶部１４は、リソース情報リポジトリ１４１と仮想マシンイメージリポジトリ１４２を含んでいる。記憶部１４は、リソースの情報と仮想マシンイメージの管理を行う。
リソース情報リポジトリ１４１には、各仮想マシンが使用するリソース情報が記載されたリソース管理テーブル１４１１を含んでいる。仮想マシンイメージリポジトリ１４２は、各仮想マシンの起動時に用いる仮想ハードウェアのテンプレートや仮想マシンイメージが格納されている。
監視部１３は、リソース監視部１３１を含んでいる。このリソース監視部１３１は、複数のコンピュートの負荷、およびこれらコンピュート上で稼働している仮想マシン２の負荷を監視する。
記憶部１４は、リソース情報リポジトリ１４１と仮想マシンイメージリポジトリ１４２を含んでいる。記憶部１４は、リソースの情報と仮想マシンイメージの管理を行う。
リソース情報リポジトリ１４１には、各仮想マシンが使用するリソース情報が記載されたリソース管理テーブル１４１１を含んでいる。仮想マシンイメージリポジトリ１４２は、各仮想マシンの起動時に用いる仮想ハードウェアのテンプレートや仮想マシンイメージが格納されている。
【0039】
仮想マシン２の追加の場合、仮想化基盤１は、仮想マシンイメージリポジトリ１４２で管理されている仮想ハードウェアのテンプレートを指定し、仮想ハードウェアテンプレートで規定されたリソース容量で仮想マシンイメージから仮想マシンを起動する。その後、仮想化基盤１は、前段のロードバランサ４の振り分け設定を変更すると共に、リソース監視部１３１の監視対象も変更する。
仮想マシン２の削除の場合、仮想化基盤１は、前段のロードバランサ４の振り分け設定を変更した後仮想マシン２およびその仮想ハードウェアを削除する。また仮想化基盤１は、リソース監視部１３１の監視対象も変更する。リソース割当変更の場合、仮想化基盤１は、ホットプラグによりリソース割当量を変更する。なおリソース割当変更手段は、ホットプラグに限定されない。
仮想マシン２の削除の場合、仮想化基盤１は、前段のロードバランサ４の振り分け設定を変更した後仮想マシン２およびその仮想ハードウェアを削除する。また仮想化基盤１は、リソース監視部１３１の監視対象も変更する。リソース割当変更の場合、仮想化基盤１は、ホットプラグによりリソース割当量を変更する。なおリソース割当変更手段は、ホットプラグに限定されない。
【0040】
図３は、仮想マシン２の起動処理を示すフローチャートである。
ここで仮想マシン２の起動については、市中の仮想化基盤と同様に行われていることを前提とする。
最初、リソース払出制御部１２は、不図示の上位システムからリソース割当要求を受け付ける（Ｓ１０）。このリソース割当要求とは、具体的にいうと仮想マシン２の起動要求である。リソース払出制御部１２内のリソース抽出選定部１２２は、割当可能リソースを抽出して（Ｓ１１）、割当リソースを選定する（Ｓ１２）。ここでリソース抽出選定部１２２は、割当ポリシや、既に割当てられている仮想マシン２の使用リソース量等を考慮して選定する。ここで割当ポリシとは、例えば非特許文献３に記載のAffinityルールやAnti-Affinityルール、CPU Pinning適用によるＣＰＵの固定割当を行うか否かなどをいう。
非特許文献３：インターネット<URL:https://docs.openstack.org/ocata/config-reference/compute/schedulers.html>
ここで仮想マシン２の起動については、市中の仮想化基盤と同様に行われていることを前提とする。
最初、リソース払出制御部１２は、不図示の上位システムからリソース割当要求を受け付ける（Ｓ１０）。このリソース割当要求とは、具体的にいうと仮想マシン２の起動要求である。リソース払出制御部１２内のリソース抽出選定部１２２は、割当可能リソースを抽出して（Ｓ１１）、割当リソースを選定する（Ｓ１２）。ここでリソース抽出選定部１２２は、割当ポリシや、既に割当てられている仮想マシン２の使用リソース量等を考慮して選定する。ここで割当ポリシとは、例えば非特許文献３に記載のAffinityルールやAnti-Affinityルール、CPU Pinning適用によるＣＰＵの固定割当を行うか否かなどをいう。
非特許文献３：インターネット<URL:https://docs.openstack.org/ocata/config-reference/compute/schedulers.html>
【0041】
リソース管理部１２１は、リソース情報リポジトリ１４１のリソース管理テーブル１４１１（図６参照）を書き換える（Ｓ１３）。リソース払出制御部１２の仮想マシン制御部１２３は、仮想マシン２を起動する（Ｓ１４）。
【0042】
ステップＳ１４の仮想マシン２の起動時に、コンピュート３内に仮想マシン設定ファイル３１が作成される。この仮想マシン設定ファイル３１には、リソースの割当情報等が記載されている。以下の非特許文献４には、仮想マシン設定ファイル３１の要素と属性の概要が記載されている。
非特許文献４：インターネット<URL:https://libvirt.org/formatdomain.html>
非特許文献４：インターネット<URL:https://libvirt.org/formatdomain.html>
【0043】
リソース監視部１３１は、起動した仮想マシン２の情報を監視対象情報に追加して更新する（Ｓ１５）。最後にリソース払出制御部１２は、不図示の上位システムに対してリソース（仮想マシン２）の払い出しを応答し（Ｓ１６）、図３の処理を終了する。
【0044】
図４は、クラスタを監視対象にした場合のスケーリング手法の選択処理を示すフローチャートである。
最初、リソース監視部１３１は、例えばＣＰＵ使用率、メモリ使用量など負荷状態を示す指標であるメトリック情報を収集する（Ｓ２０）。
最初、リソース監視部１３１は、例えばＣＰＵ使用率、メモリ使用量など負荷状態を示す指標であるメトリック情報を収集する（Ｓ２０）。
【0045】
スケーリング実施判定部１１３は、リソース監視部１３１が収集したメトリック情報に従い、監視対象の負荷が閾値を超えたか否かを判定し（Ｓ２１）、よってスケーリングを実施するか否かを判定する。この判定に用いるメトリック情報の種類やその閾値などの判定ルールは、事前に設定されている。
【0046】
スケーリング実施判定部１１３は、監視対象が閾値を超えたならば（Ｙｅｓ）、ステップＳ２３の処理に進み、監視対象が閾値以下ならば（Ｎｏ）、所定時間αの待ち時間（Ｓ２２）の後、ステップＳ２０の処理に戻る。ここで所定時間αは、監視対象の各コンピュート３の変化速度に応じて設定すればよく、限定されない。
【0047】
スケーリング実施判定部１１３は、追加が必要なリソース量を算出する（Ｓ２３）。ここで追加される固定のリソース量や割合の単位は、予め決められている。
【0048】
具体例としてＣＰＵ使用率を監視している場合、ＣＰＵ使用率が７０％を超えたら、２コアを追加するというルールや、２０％のリソースを追加するルールが考えられる。２０％のリソース追加とは、複数の仮想マシン２でクラスタを組んでいる場合において、このクラスタを組む仮想マシン２の合計コア数に２０％を乗算して得られるコア数となる。この例以外にも、時系列データの推定モデルを用いてリソース変化を予測してスケーリング量やスケーリングの実施を決定するといったより高度な手法を用いてもよい。監視対象は仮想マシン単位とすることもでき、クラスタ単位とすることも可能であるが、ここではクラスタ単位の負荷を監視対象とする場合の処理を説明する。
【0049】
スケーリング実施判定部１１３から追加するリソース量を通知されると、スケーリング方法判定部１１１は、一連の処理を開始する。
最初、スケーリング方法判定部１１１は、クラスタを構成する仮想マシンのインデックス変数Ｘを１で初期化し（Ｓ２４）、空きリソース量Ｙを０で初期化する（Ｓ２５）。これらＸとＹとは、プログラムの内部変数である。
最初、スケーリング方法判定部１１１は、クラスタを構成する仮想マシンのインデックス変数Ｘを１で初期化し（Ｓ２４）、空きリソース量Ｙを０で初期化する（Ｓ２５）。これらＸとＹとは、プログラムの内部変数である。
【0050】
次にスケーリング方法判定部１１１は、リソース管理部１２１に問い合わせて、クラスタを構成するＸ個目の仮想マシン２を搭載するコンピュート３内にリソースの空きがあるかを確認する（Ｓ２６）。更にスケーリング方法判定部１１１は、当該コンピュート３のリソースの空きが確認済みか否かを判定する（Ｓ２７）。スケーリング方法判定部１１１は、リソースの空きを確認済みならば（Ｙｅｓ）、ステップＳ３０に進み、リソースの空きを確認していなかったならば（Ｎｏ）、空きリソース量Ｙに当該コンピュート３の空きリソースを加えて（Ｓ２８）、ステップＳ２９に進む。
【0051】
ステップＳ２９において、スケーリング方法判定部１１１は、空きリソース量Ｙが追加リソース量よりも大きいか否かを判定する。スケーリング方法判定部１１１は、空きリソース量Ｙが追加リソース量以上ならば（Ｙｅｓ）、スケールアップを選択して、図４の処理を終了する。スケーリング方法判定部１１１は、空きリソース量Ｙが追加リソース量よりも小さいならば（Ｎｏ）、ステップＳ３０の処理に進む。
【0052】
ステップＳ３０において、スケーリング方法判定部１１１は、変数Ｘがクラスタを構成する仮想マシン数と等しいか否かを判定する。スケーリング方法判定部１１１は、変数Ｘがクラスタを構成する仮想マシン数と等しいならば（Ｙｅｓ）、ステップＳ３２の処理に進み、変数Ｘがクラスタを構成する仮想マシン数とは異なるならば（Ｎｏ）、変数Ｘに１を加算して（Ｓ３１）、ステップＳ２６の処理に戻る。
【0053】
ステップＳ３２において、スケーリング方法判定部１１１は、空きリソース量Ｙが０であるか否かを判定する。スケーリング方法判定部１１１は、空きリソース量Ｙが０ならば（Ｙｅｓ）、スケールアウトを選択し、空きリソース量Ｙが０でないならば（Ｎｏ）、スケールアップとスケールアウトの併用を選択して、図４の処理を終了する。
【0054】
つまり、クラスタを構成する仮想マシンを搭載する各コンピュート内の空きリソースの総和が追加リソースより多い場合はスケールアップが選択される。クラスタを構成する仮想マシンを搭載する各コンピュート内にリソースの空きはあるが追加リソースよりは少ない場合は併用が選択される。クラスタを構成する仮想マシンを搭載する各コンピュート３内にリソースの空きがない場合はスケールアウトが選択される。
【0055】
図５は、仮想マシン２を監視対象にした場合のスケーリング手法の選択処理を示すフローチャートである。
最初、リソース監視部１３１は、例えばＣＰＵ使用率、メモリ使用量など負荷状態を示す指標であるメトリック情報を収集する（Ｓ４０）。
最初、リソース監視部１３１は、例えばＣＰＵ使用率、メモリ使用量など負荷状態を示す指標であるメトリック情報を収集する（Ｓ４０）。
【0056】
スケーリング実施判定部１１３は、リソース監視部１３１が収集したメトリック情報に従い、監視対象の負荷が閾値を超えたか否かを判定し（Ｓ４１）、よってスケーリングを実施するか否かを判定する。
【0057】
スケーリング実施判定部１１３は、監視対象が閾値を超えたならば（Ｙｅｓ）、ステップＳ４３の処理に進み、監視対象が閾値以下ならば（Ｎｏ）、所定時間αの待ち時間（Ｓ４２）の後、ステップＳ４０の処理に戻る。
【0058】
スケーリング実施判定部１１３は、追加が必要なリソース量を算出する（Ｓ４３）。ここで追加される固定のリソース量や割合の単位は、予め決められている。スケーリング実施判定部１１３から追加するリソース量を通知されると、スケーリング方法判定部１１１は、一連の処理を開始する。
【0059】
最初、スケーリング方法判定部１１１は、リソース管理部１２１に問い合わせて、この仮想マシンを搭載する同一コンピュート３内にリソースの空きがあるか否かを確認する（Ｓ４４）。
【0060】
次にスケーリング方法判定部１１１は、同一コンピュート３内の空きリソースが追加リソース量よりも多いか否かを判定する（Ｓ４５）。スケーリング方法判定部１１１は、同一コンピュート３内の空きリソースが追加リソース量以上ならば（Ｙｅｓ）、スケールアップを選択して、図５の処理を終了する。
スケーリング方法判定部１１１は、同一コンピュート３内の空きリソースが追加リソース量未満ならば（Ｎｏ）、同一コンピュートの空きリソースが０であるか否かを判定する（Ｓ４６）。スケーリング方法判定部１１１は、空きリソースが０ならば（Ｙｅｓ）、スケールアウトを選択して図５の処理を終了し、空きリソースが０でないならば（Ｎｏ）、スケールアップとスケールアウトの併用を選択して、図５の処理を終了する。
スケーリング方法判定部１１１は、同一コンピュート３内の空きリソースが追加リソース量未満ならば（Ｎｏ）、同一コンピュートの空きリソースが０であるか否かを判定する（Ｓ４６）。スケーリング方法判定部１１１は、空きリソースが０ならば（Ｙｅｓ）、スケールアウトを選択して図５の処理を終了し、空きリソースが０でないならば（Ｎｏ）、スケールアップとスケールアウトの併用を選択して、図５の処理を終了する。
【0061】
図６は、リソース管理テーブル１４１１の一例を示す図である。
リソース管理テーブル１４１１は、リソースの割当状況を管理するために利用され、Compute ID欄と多重率欄と、使用率欄と、割当先欄とを含む各レコードによって構成される。なお、リソース管理テーブル１４１１の各レコードは、図６の各行に対応する。
リソース管理テーブル１４１１は、リソースの割当状況を管理するために利用され、Compute ID欄と多重率欄と、使用率欄と、割当先欄とを含む各レコードによって構成される。なお、リソース管理テーブル１４１１の各レコードは、図６の各行に対応する。
【0062】
Compute ID欄には、当該レコードに係るコンピュート３の識別情報が格納される。
多重率欄には、コンピュート３間の性能比率が格納される。図６では、Compute ID#0,#1の多重率欄には１００％が格納されており、Compute ID#0のコンピュート３とCompute ID#1のコンピュート３とが性能の基準であることを示している。更にCompute ID#2,#3の多重率欄には、１５０％が格納されており、Compute ID#2,#3のコンピュート３は、Compute ID#0,#1のコンピュート３に対して、それぞれ１．５倍の性能を有していることを示している。この多重率欄の情報により、コンピュート３間の性能差分を吸収することが可能である。
多重率欄には、コンピュート３間の性能比率が格納される。図６では、Compute ID#0,#1の多重率欄には１００％が格納されており、Compute ID#0のコンピュート３とCompute ID#1のコンピュート３とが性能の基準であることを示している。更にCompute ID#2,#3の多重率欄には、１５０％が格納されており、Compute ID#2,#3のコンピュート３は、Compute ID#0,#1のコンピュート３に対して、それぞれ１．５倍の性能を有していることを示している。この多重率欄の情報により、コンピュート３間の性能差分を吸収することが可能である。
【0063】
使用率欄には、各コンピュート３における使用リソースの数値が格納される。なお、この使用率欄の値は、性能基準のコンピュート３に対する当該コンピュートにおける使用リソースの割合である。多重率欄の値から使用率欄の値を減算することで、当該コンピュート３における空きリソース量を算出することができる。図６では、Compute ID#0の使用率欄には５０％が格納され、Compute ID#1の使用率欄には７０％が格納され、Compute ID#2の使用率欄には２０％が格納され、Compute ID#3の使用率欄には５０％が格納されている。なお図６において使用率欄は１次元であるが、ＣＰＵやメモリやディスク使用量など多次元に拡張してもよい。
【0064】
割当先欄には、各コンピュートに割り当てられた仮想マシンの識別情報が格納される。図６では、Compute ID#0の割当先欄にVM#01,VM#05が格納され、Compute ID#1の割当先欄にVM#02,VM#10,VM#13が格納され、Compute ID#2の割当先欄にVM#08が格納され、Compute ID#3の割当先欄にVM#20,VM#04が格納されている。
【0065】
リソース管理テーブル１４１１を用いる際、スケーリング実施判定部１１３が算出した追加リソース量と使用率の変換は事前に決められているものとする。例えば、使用率２５％が２コアに該当するなどである。またスケーリング実施判定部１１３は、多重率が使用率よりも大きい場合、リソースの空きがあると判定する。例えば、多重率１００％のコンピュートで使用率が５０％の場合、５０％のリソースの空きがある。この５０％のリソースの空きは、例えば４コア分の空きに相当する。
【0066】
図７は、スケーリング方法とリソース量から、実際にスケールアップまたはスケールアウトするリソース量を算出するフローチャートある。
最初、スケーリング指示部１１２は、スケーリング方法を判定して分岐する（Ｓ５０）。スケーリング指示部１１２は、スケーリング方法がスケールアップならば、ステップＳ５１の処理に進み、スケールアウトならばステップＳ５８の処理に進み、これらの併用ならばステップＳ５２の処理に進む。
最初、スケーリング指示部１１２は、スケーリング方法を判定して分岐する（Ｓ５０）。スケーリング指示部１１２は、スケーリング方法がスケールアップならば、ステップＳ５１の処理に進み、スケールアウトならばステップＳ５８の処理に進み、これらの併用ならばステップＳ５２の処理に進む。
【0067】
《スケールアップの場合》
ステップＳ５１において、スケーリング指示部１１２は、リソース抽出選定部１２２によってスケールアップを指示されたリソース量（例えば２コア）を、実際にスケールアウトするリソース量として通知し、図７の処理を終了する。
ステップＳ５１において、スケーリング指示部１１２は、リソース抽出選定部１２２によってスケールアップを指示されたリソース量（例えば２コア）を、実際にスケールアウトするリソース量として通知し、図７の処理を終了する。
【0068】
《スケールアウトの場合》
ステップＳ５８において、スケーリング指示部１１２は、スケーリング実施判定部１１３から指示されたリソース量とＶＭの起動時に用いる仮想ハードウェアのテンプレートにより、実際にスケールアウトするリソース量を決定する。なお、このテンプレートのことを略して「ＶＭテンプレート」と記載する。本実施形態のテンプレートには、４コア分のＣＰＵを使用することが記載されているので、スケールアウトする単位は４の倍数となる。
ステップＳ５８において、スケーリング指示部１１２は、スケーリング実施判定部１１３から指示されたリソース量とＶＭの起動時に用いる仮想ハードウェアのテンプレートにより、実際にスケールアウトするリソース量を決定する。なお、このテンプレートのことを略して「ＶＭテンプレート」と記載する。本実施形態のテンプレートには、４コア分のＣＰＵを使用することが記載されているので、スケールアウトする単位は４の倍数となる。
【0069】
スケーリング指示部１１２は、決定したスケールアウトのリソース量がスケーリング実施判定部１１３から指示されたスケールアウトのリソース量と等しいか否かを判定する（Ｓ５９）。スケーリング指示部１１２は、決定したスケールアウトのリソース量が指示されたスケールアウトのリソース量と等しくないならば（Ｎｏ）、リソース抽出選定部１２２に、差分のリソース量と実際にスケールアウトするリソース量を通知し（Ｓ６０）、図７の処理を終了する。
具体的にいうと、スケールアウト６コアが指示され、ＶＭのテンプレートが４コアならは、２つのＶＭの追加となる。このときスケーリング指示部１１２が決定したスケールアウトのリソース量は８コアとなり、２個のコアが差分のリソース量となる。この差分の２コアは、図８のステップＳ８０の処理で削除（スケールダウン）される。
スケーリング指示部１１２は、決定したリソース量が指定されたリソース量と等しいならば（Ｙｅｓ）、リソース抽出選定部１２２に、スケールアウトするリソース量（例えば４コア）を通知し（Ｓ６１）、図７の処理を終了する。
具体的にいうと、スケールアウト６コアが指示され、ＶＭのテンプレートが４コアならは、２つのＶＭの追加となる。このときスケーリング指示部１１２が決定したスケールアウトのリソース量は８コアとなり、２個のコアが差分のリソース量となる。この差分の２コアは、図８のステップＳ８０の処理で削除（スケールダウン）される。
スケーリング指示部１１２は、決定したリソース量が指定されたリソース量と等しいならば（Ｙｅｓ）、リソース抽出選定部１２２に、スケールアウトするリソース量（例えば４コア）を通知し（Ｓ６１）、図７の処理を終了する。
【0070】
《併用の場合》
ステップＳ５２において、スケーリング指示部１１２は、スケーリング実施判定部１１３から指示されたスケールアウトのリソース量とＶＭテンプレートにより、実際にスケールアウトするリソース量を決定する。スケーリング指示部１１２は、決定したスケールアウトするリソース量がスケーリング実施判定部１１３から指定されたスケールアウトのリソース量よりも大きいか否かを判定する（Ｓ５３）。スケーリング指示部１１２は、決定したスケールアウトするリソース量が指示されたスケールアウトのリソース量と等しいならば（Ｙｅｓ）、リソース抽出選定部１２２に、実際にスケールアップするリソース量とスケールアウトするリソース量を通知し（Ｓ５７）、図７の処理を終了する。
具体的にいうと、スケーリング実施判定部１１３から指定されたスケールアウトのリソース量がＶＭテンプレートのリソース量の倍数ならば、スケーリング指示部１１２が決定したスケールアウトするリソース量は、実際にスケールアウトするリソース量と等しくなる。また、スケーリング指示部１１２は、スケーリング実施判定部１１３から指示されたスケールアップするリソース量を、実際にスケールアップするリソース量としてリソース抽出選定部１２２に通知する。
ステップＳ５２において、スケーリング指示部１１２は、スケーリング実施判定部１１３から指示されたスケールアウトのリソース量とＶＭテンプレートにより、実際にスケールアウトするリソース量を決定する。スケーリング指示部１１２は、決定したスケールアウトするリソース量がスケーリング実施判定部１１３から指定されたスケールアウトのリソース量よりも大きいか否かを判定する（Ｓ５３）。スケーリング指示部１１２は、決定したスケールアウトするリソース量が指示されたスケールアウトのリソース量と等しいならば（Ｙｅｓ）、リソース抽出選定部１２２に、実際にスケールアップするリソース量とスケールアウトするリソース量を通知し（Ｓ５７）、図７の処理を終了する。
具体的にいうと、スケーリング実施判定部１１３から指定されたスケールアウトのリソース量がＶＭテンプレートのリソース量の倍数ならば、スケーリング指示部１１２が決定したスケールアウトするリソース量は、実際にスケールアウトするリソース量と等しくなる。また、スケーリング指示部１１２は、スケーリング実施判定部１１３から指示されたスケールアップするリソース量を、実際にスケールアップするリソース量としてリソース抽出選定部１２２に通知する。
【0071】
スケーリング指示部１１２は、決定したリソース量が指定されたリソース量と等しくないならば（Ｎｏ）、スケールアップを指示されたリソース量から余剰のコア数を引いて実際にスケールアップ量を決定する。（Ｓ５４）。具体的にいうと、スケールアウト７コアが指示され、ＶＭのテンプレートが４コアならは、２つのＶＭの追加となる。このときスケーリング指示部１１２が決定したスケールアウトのリソース量は８コアとなり、１個のコアが余剰となる。
【0072】
更にスケーリング指示部１１２は、余剰のコア数よりもスケールアップを指示されたリソース量が多いか否かを判定する（Ｓ５５）。スケーリング指示部１１２は、余剰のコア数がスケールアップを指示されたリソース量よりも多くなかったならば（Ｎｏ）、リソース抽出選定部１２２に、ステップＳ５４で決定したスケールアップするリソース量とステップＳ５２で決定したスケールアウトするリソース量を通知し（Ｓ５７）、図７の処理を終了する。
具体的にいうと、スケールアウト７コアとスケールアップ２コアが指示され、ＶＭのテンプレートが４コアならは、２つのＶＭの追加となる。このときスケーリング指示部１１２が決定したスケールアウトのリソース量は８コアとなり、１個のコアが余剰となる。スケーリング指示部１１２は、スケールアップを指示されたリソース量の２コアから、余剰の１コアを差し引くことで、実際にスケールアップされるリソース量の１コアを算出する。
具体的にいうと、スケールアウト７コアとスケールアップ２コアが指示され、ＶＭのテンプレートが４コアならは、２つのＶＭの追加となる。このときスケーリング指示部１１２が決定したスケールアウトのリソース量は８コアとなり、１個のコアが余剰となる。スケーリング指示部１１２は、スケールアップを指示されたリソース量の２コアから、余剰の１コアを差し引くことで、実際にスケールアップされるリソース量の１コアを算出する。
【0073】
ステップＳ５５において、スケーリング指示部１１２は、余剰のコア数がスケールアップを指示されたリソース量よりも多かったならば（Ｙｅｓ）、余剰のコア数からスケールアップを指示されたリソース量を引いて差分リソース量を決定し（Ｓ５６）、リソース抽出選定部１２２に、差分のリソース量とステップＳ５２で決定したスケールアウトするリソース量を通知し（Ｓ６０）、図７の処理を終了する。
具体的にいうと、スケールアウト６コアとスケールアップ１コアが指示され、ＶＭのテンプレートが４コアならは、２つのＶＭの追加となる。このときスケーリング指示部１１２が決定したスケールアウトのリソース量は８コアとなり、２個のコアが余剰となる。この余剰のコア数はスケールアップの１コアよりも多いので、余剰のコア数からスケールアップを指示されたリソース量を引いた差分のリソース量は１コアとなる。この差分の１コアは、図８のステップＳ８０の処理で削除（スケールダウン）される。
具体的にいうと、スケールアウト６コアとスケールアップ１コアが指示され、ＶＭのテンプレートが４コアならは、２つのＶＭの追加となる。このときスケーリング指示部１１２が決定したスケールアウトのリソース量は８コアとなり、２個のコアが余剰となる。この余剰のコア数はスケールアップの１コアよりも多いので、余剰のコア数からスケールアップを指示されたリソース量を引いた差分のリソース量は１コアとなる。この差分の１コアは、図８のステップＳ８０の処理で削除（スケールダウン）される。
【0074】
図８は、各コンピュート上で動作するリソースの選択を示すフローチャートである。
リソース抽出選定部１２２は、再びリソース管理部１２１に空きリソースを問い合せ、スケールアップ／スケールアウト／差分のリソース量の指示を受信する（Ｓ７０）。
リソース抽出選定部１２２は、再びリソース管理部１２１に空きリソースを問い合せ、スケールアップ／スケールアウト／差分のリソース量の指示を受信する（Ｓ７０）。
【0075】
リソース抽出選定部１２２は、スケールアップのリソース量の指示が有るか否かを判定する（Ｓ７１）。リソース抽出選定部１２２は、スケールアップ指示が有るならば（Ｙｅｓ）、同一コンピュートの空きリソースとスケールアップのリソース量を比較し（Ｓ７２）、リソースが確保可能であるか否かを判定する（Ｓ７３）。リソース抽出選定部１２２は、スケールアップ指示が無いならば（Ｎｏ）、ステップＳ７６の処理に進む。
【0076】
ステップＳ７３において、リソース抽出選定部１２２は、リソースが確保可能ならば（Ｙｅｓ）、仮想マシン制御部１２３に同一コンピュートへのリソースの追加を指示し（Ｓ７４）、ステップＳ７６の処理に進む。仮想マシン制御部１２３は、スケールアップの際、ホットプラグを用いて指定されたリソース量を追加する。
ステップＳ７３において、リソース抽出選定部１２２は、リソースが確保できないならば（Ｎｏ）、ＮＧ応答をスケーリング指示部１１２に返して（Ｓ７５）、いったん終了する。これにより、スケーリング部１１は、再びスケーリング方法の判定から繰り返す。
ステップＳ７３において、リソース抽出選定部１２２は、リソースが確保できないならば（Ｎｏ）、ＮＧ応答をスケーリング指示部１１２に返して（Ｓ７５）、いったん終了する。これにより、スケーリング部１１は、再びスケーリング方法の判定から繰り返す。
【0077】
ステップＳ７６において、リソース抽出選定部１２２は、スケールアウトのリソース量の指示が有るか否かを判定する。リソース抽出選定部１２２は、スケールアウト指示が有るならば（Ｙｅｓ）、仮想マシン制御部１２３に仮想マシンを起動可能な各コンピュートにおける仮想マシンの起動を指示し（Ｓ７７）、ステップＳ７８の処理に進む。リソース抽出選定部１２２は、スケールアウト指示が無いならば（Ｎｏ）、ステップＳ７８の処理に進む。
【0078】
ステップＳ７８において、リソース抽出選定部１２２は、差分のリソース量の指示が有るか否かを判定する。リソース抽出選定部１２２は、差分指示が有るならば（Ｙｅｓ）、ＣＰＵコア数が最小の仮想マシンを選択し（Ｓ７９）、差分をホットプラグ機能で削除すると（Ｓ８０）、図８の処理を終了する。リソース抽出選定部１２２は、差分指示が無いならば（Ｎｏ）、図８の処理を終了する。
【0079】
併用およびスケールアウトの際には、事前に準備されたＶＭのテンプレートを使用してＶＭを追加する。このＶＭのテンプレートは、ＶＭ起動時に使用するものと同様である。
併用の際、ＶＭのテンプレートのＣＰＵリソースがスケールアウト指定されたＣＰＵリソースより大きいならば、差分のＣＰＵリソースについてはスケールアップリソース量から差し引く。その上でさらに差分が生じる場合、仮想化基盤１は、ホットプラグ機能を使って既存のＣＰＵリソースを削除する。ＣＰＵリソースを削除する対象となる仮想マシンは、クラスタ群の中で最もＣＰＵコア数の小さい仮想マシンを選ぶとよい。
他にもＣＰＵコア数の平均値から最も離れているコア数の仮想マシンを選ぶ、ランダムに仮想マシンを選ぶ、などの選択肢も取り得る。
併用の際、ＶＭのテンプレートのＣＰＵリソースがスケールアウト指定されたＣＰＵリソースより大きいならば、差分のＣＰＵリソースについてはスケールアップリソース量から差し引く。その上でさらに差分が生じる場合、仮想化基盤１は、ホットプラグ機能を使って既存のＣＰＵリソースを削除する。ＣＰＵリソースを削除する対象となる仮想マシンは、クラスタ群の中で最もＣＰＵコア数の小さい仮想マシンを選ぶとよい。
他にもＣＰＵコア数の平均値から最も離れているコア数の仮想マシンを選ぶ、ランダムに仮想マシンを選ぶ、などの選択肢も取り得る。
【0080】
図９Ａは、クラスタを監視対象にした場合の初期状態を示す図である。
監視対象は、コンピュート＃１～＃３からなるクラスタである。各コンピュート＃１～３は、それぞれ８コアのＣＰＵを備えている。
監視対象は、コンピュート＃１～＃３からなるクラスタである。各コンピュート＃１～３は、それぞれ８コアのＣＰＵを備えている。
【0081】
初期状態において、コンピュート＃１には、ＶＭ＃１－１とＶＭ＃２－１とが稼働している。コンピュート＃１は、ＶＭ＃１－１が４コアを占有し、ＶＭ＃２－１が２コアを占有している。コンピュート＃１の使用率は、７５％である。
【0082】
コンピュート＃２には、ＶＭ＃１－２が稼働している。コンピュート＃２は、ＶＭ＃１－２が６コアを占有している。コンピュート＃２の使用率は、７５％である。
コンピュート＃３には、どのＶＭも稼働しておらず、その使用率は０％である。
コンピュート＃３には、どのＶＭも稼働しておらず、その使用率は０％である。
【0083】
図９Ｂは、クラスタを監視対象にした場合のスケールアップの一例を示す図である。
図９Ｂに示すクラスタでは、初期状態に対してＶＭ＃１に２コア分のＣＰＵがスケールアップされている。ＶＭ＃１－１は、２コア分だけスケールアップしている。仮想化基盤１は、ホットプラグ機能を用いてＶＭ＃１－１をスケールアップしているため、短時間で処理を完了できる。
図９Ｂに示すクラスタでは、初期状態に対してＶＭ＃１に２コア分のＣＰＵがスケールアップされている。ＶＭ＃１－１は、２コア分だけスケールアップしている。仮想化基盤１は、ホットプラグ機能を用いてＶＭ＃１－１をスケールアップしているため、短時間で処理を完了できる。
【0084】
図９Ｃは、クラスタを監視対象にした場合のスケールアップの他の例を示す図である。
図９Ｃに示すクラスタでは、初期状態に対してＶＭ＃１に４コア分のＣＰＵがスケールアップされている。ＶＭ＃１－２は、２コア分だけスケールアップしている。仮想化基盤１は、ホットプラグ機能を用いてＶＭ＃１－２をスケールアップしているため、短時間で処理を完了できる。
図９Ｃに示すクラスタでは、初期状態に対してＶＭ＃１に４コア分のＣＰＵがスケールアップされている。ＶＭ＃１－２は、２コア分だけスケールアップしている。仮想化基盤１は、ホットプラグ機能を用いてＶＭ＃１－２をスケールアップしているため、短時間で処理を完了できる。
【0085】
図９Ｄは、クラスタを監視対象にした場合の併用パターンを示す図である。
図９Ｄに示すクラスタでは、初期状態に対して、ＶＭ＃１に６コア分のＣＰＵがスケールアップされている。ここではコンピュート＃３上に新たにＶＭ＃１－３が稼働している。ＶＭ＃１－３は、４コアを占有している。仮想化基盤１は、ホットプラグ機能を用いてＶＭ＃１－３をスケールアウトし、かつ、差分のリソース量だけＶＭ＃１－１からスケールダウンしているため、細かな粒度でスケーリングを制御できる。
図９Ｄに示すクラスタでは、初期状態に対して、ＶＭ＃１に６コア分のＣＰＵがスケールアップされている。ここではコンピュート＃３上に新たにＶＭ＃１－３が稼働している。ＶＭ＃１－３は、４コアを占有している。仮想化基盤１は、ホットプラグ機能を用いてＶＭ＃１－３をスケールアウトし、かつ、差分のリソース量だけＶＭ＃１－１からスケールダウンしているため、細かな粒度でスケーリングを制御できる。
【0086】
図１０Ａは、クラスタを監視対象にした場合の初期状態を示す図である。
初期状態において、コンピュート＃１には、ＶＭ＃１－１が稼働している。このＶＭ＃１－１は、コンピュート＃１の８コアを全て占有している。コンピュート＃１の使用率は、１００％である。
初期状態において、コンピュート＃１には、ＶＭ＃１－１が稼働している。このＶＭ＃１－１は、コンピュート＃１の８コアを全て占有している。コンピュート＃１の使用率は、１００％である。
【0087】
コンピュート＃２には、ＶＭ＃１－２が稼働している。このＶＭ＃１－２は、コンピュート＃１の８コアを全て占有している。コンピュート＃２の使用率は、１００％である。
コンピュート＃３には、どのＶＭも稼働しておらず、その使用率は０％である。
コンピュート＃３には、どのＶＭも稼働しておらず、その使用率は０％である。
【0088】
図１０Ｂは、クラスタを監視対象にした場合のスケールアウトの例を示す図である。
図１０Ｂに示すクラスタでは、初期状態に対して２コア分のＣＰＵがスケールアップされている。ここではＶＭ＃１－３が４コア分だけスケールアップしており、差分のリソース量である２コア分は、ホットプラグ機能を用いてＶＭ＃１－１をスケールダウンしている。これによりＣＰＵコアを過剰に占有することがなくなる。
図１０Ｂに示すクラスタでは、初期状態に対して２コア分のＣＰＵがスケールアップされている。ここではＶＭ＃１－３が４コア分だけスケールアップしており、差分のリソース量である２コア分は、ホットプラグ機能を用いてＶＭ＃１－１をスケールダウンしている。これによりＣＰＵコアを過剰に占有することがなくなる。
【0089】
（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ），（ｂ）のようなものがある。
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ），（ｂ）のようなものがある。
【0090】
（ａ） スケールアウトやスケールアップの対象は、ＣＰＵリソースに限定されず、メモリリソースやディスクリソースなどであってもよい。
（ｂ） 上記実施形態では、実行環境として仮想マシンが用いられた例を記載したが、実行環境としてコンテナを用いて、このコンテナに対するリソースの割り当てに適用してもよく、限定されない。
（ｂ） 上記実施形態では、実行環境として仮想マシンが用いられた例を記載したが、実行環境としてコンテナを用いて、このコンテナに対するリソースの割り当てに適用してもよく、限定されない。
【符号の説明】
【0091】
１ 仮想化基盤
１１ スケーリング部
１１１ スケーリング方法判定部
１１２ スケーリング指示部
１１３ スケーリング実施判定部
１２ リソース払出制御部
１２１ リソース管理部
１２２ リソース抽出選定部
１２３ 仮想マシン制御部
１３ 監視部
１３１ リソース監視部
１４ 記憶部
１４１ リソース情報リポジトリ
１４１１ リソース管理テーブル
１４２ 仮想マシンイメージリポジトリ
２ 仮想マシン （実行環境）
３，３－１～３－４ コンピュート
３１ 仮想マシン設定ファイル
３２ 仮想化層
４ ロードバランサ
５ ローカルネット
６ インターネット
１１ スケーリング部
１１１ スケーリング方法判定部
１１２ スケーリング指示部
１１３ スケーリング実施判定部
１２ リソース払出制御部
１２１ リソース管理部
１２２ リソース抽出選定部
１２３ 仮想マシン制御部
１３ 監視部
１３１ リソース監視部
１４ 記憶部
１４１ リソース情報リポジトリ
１４１１ リソース管理テーブル
１４２ 仮想マシンイメージリポジトリ
２ 仮想マシン （実行環境）
３，３－１～３－４ コンピュート
３１ 仮想マシン設定ファイル
３２ 仮想化層
４ ロードバランサ
５ ローカルネット
６ インターネット
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図9C】
【図9D】
【図10A】
【図10B】