JP2018206170A - 制御装置及び仮想マシン生成方法 - Google Patents

Abstract

【課題】ＮＦＶシステムにおいて障害が発生したとき、システムの運用状態を維持することができる。
【解決手段】１つの側面では、仮想マシンをサーバ上で生成し、前記仮想マシンが使用する前記サーバの有するリソースを管理する仮想マシン管理装置を、制御する制御装置であって、前記仮想マシン管理装置が生成した仮想マシンが削除されたことを検出する検出部と、前記仮想マシンが削除されたことを検出したとき、前記削除された仮想マシン以外の他の仮想マシンが使用していないリソース残量を、前記仮想マシン管理装置から取得する取得部と、前記リソース残量に応じて、前記削除された仮想マシンを生成するよう前記仮想マシン管理装置に指示する制御部を有する。
【選択図】 図９

Description

本発明は、制御装置及び仮想マシン生成方法に関する。

近年、ネットワーク機能の一部を仮想マシン（VM: Virtual Machine）で構築するＮＦＶ（Network Functions Virtualization）が注目されている。ＮＦＶを用いたシステム（
以降、ＮＦＶシステムと呼ぶ場合がある）は、例えば、欧州電気通信標準化機構 （ETSI :European Telecommunications Standards Institute）により、装置構成や機能構成の標準規格が提案される。

標準化規格（例えば、ETSI GS NFV-MAN 001 V1.1.1）によると、ＮＦＶシステムは、例えば、サーバ上でＶＭを生成又は削除するための仮想化基盤であるＮＦＶＩ（NFV Infrastructure）を有する。また、ＮＦＶシステムは、例えば、ＮＦＶＩで生成又は削除したＶＭ、及びＶＭが使用するサーバのリソースを管理するＶＩＭ（Virtualized Infrastructure Manager）を有する。ＮＦＶシステムでは、ＶＩＭを介してＮＦＶＩを制御することで、ネットワーク機能の一部となるＶＭを生成する。

ＶＮＦシステムに関する技術は、以下の特許文献１，２に記載されている。

特開２０１５−５６１８２号公報 国際公開第２０１６／１５２５８７号

ETSI GS NFV-MAN 001 V1.1.1

しかし、例えば、地震などの災害や、マシンの劣化などにより、ＮＦＶＩ配下のサーバが故障し、生成しているＶＭが削除されてしまう場合がある。この場合、例えば、故障が発生したサーバでＶＭを再度生成しようとしても、サーバが故障しているため、ＶＭの生成に失敗することがある。ＶＭの生成に失敗すると、ＮＦＶシステムは、運用状態を維持することができなくなる。

そこで、一開示は、ＮＦＶシステムにおいて障害が発生したとき、システムの運用状態を維持する制御装置及び仮想マシン生成方法を提供する。

１つの側面では、仮想マシンをサーバ上で生成し、前記仮想マシンが使用する前記サーバの有するリソースを管理する仮想マシン管理装置を、制御する制御装置であって、前記仮想マシン管理装置が生成した仮想マシンが削除されたことを検出する検出部と、前記仮想マシンが削除されたことを検出したとき、前記削除された仮想マシン以外の他の仮想マシンが使用していないリソース残量を、前記仮想マシン管理装置から取得する取得部と、前記リソース残量に応じて、前記削除された仮想マシンを生成するよう前記仮想マシン管理装置に指示する制御部を有する。

そこで、一開示は、ＮＦＶシステムにおいて障害が発生したとき、システムの運用状態を維持することができる。

図１は、ＮＦＶシステム１０の構成例を示す図である。 図２は、ＮＦＶＯ４００の構成例を示す図である。 図３は、ＶＭ毎コア数テーブル４２３の例を示す図である。 図４は、ＶＮＦＭ３００の構成例を示す図である。 図５は、ＶＭ要件テーブル３２５の例を示す図である。 図６は、ＶＩＭ２００の構成例を示す図である。 図７は、リソース管理テーブル２２３の例を示す図である。 図８は、運用中のｆｌａｖｏｒの例を示す図である。 図９は、ＮＦＶシステム１０におけるヒーリング処理のシーケンスの例を示す図である。 図１０は、故障発生後のリソース管理テーブル２２３の例を示す図である。 図１１は、Ｇｒａｎｔ判定処理Ｓ１０４の処理フローチャートの例を示す図である。 図１２は、ｆｌａｖｏｒ作成処理の処理フローチャートの例を示す図である。 図１３は、新規ｆｌａｖｏｒの例を示す図である。 図１４は、ヒーリング処理完了後のリソース管理テーブル２２３の例を示す図である。 図１５は、ＮＦＶシステム１０におけるヒーリング処理のシーケンスの例を示す図である。 図１６は、故障復旧後のリソース管理テーブル２２３の例を示す図である。

[第１の実施の形態]
第１の実施の形態について説明する。第１の実施の形態において、制御装置（ＮＦＶＯ４００及びＶＮＦＭ３００）は、仮想マシン管理装置（ＶＩＭ２００及びＮＦＶＩ１００）が生成した仮想マシンが削除されたことを検出する。そして、制御装置は、仮想マシンが削除されたことを検出したとき、削除された仮想マシン以外の他の仮想マシンが使用していないリソース残量を、仮想マシン管理装置から取得する。さらに、制御装置は、取得したリソース残量に応じて、削除された仮想マシンを生成するよう仮想マシン管理装置に指示する。なお、リソースは、サーバ（ＩＡＳ１０２）が有するプロセッサ（ＣＰＵ）のコア数であり、制御装置は、サーバの残コア数をリソース残量として取得する。また、制御装置は、残コア数に基づき、削除された仮想マシンを生成するサーバを選択し、選択したサーバで削除された仮想マシンを生成するよう仮想マシン管理装置に指示する。

＜ＮＦＶシステムの構成例＞
図１は、ＮＦＶシステム１０の構成例を示す図である。ＮＦＶシステム１０は、ＮＦＶＯ（NFV Orchestrator）４００、ＶＮＦＭ（Virtualized Network Function Manager）３００、ＶＩＭ２００、ＮＦＶＩ１００、ＩＡＳ（Intel Architecture Server）１０２−１〜６を有する。ＮＦＶシステム１０は、一部の処理を仮想化された仮想マシンで構築する、仮想化システムである。

ＩＡＳ１０２−１〜３及びＩＡＳ１０２−４〜６のそれぞれは、ＡＺ（Availability Zone）１０１−１及び２を構成する。ＡＺは、ＩＡＳ１０２−１〜６を論理的なグループに分割したグループ（サーバ群）であり、他のＡＺと物理的に分離したり、ＡＺ毎に冗長性を持たせたりする。例えば、ＡＺ１０１−１とＡＺ１０１−２は、ネットワークや電源など含め、それぞれのＡＺを独立した構成としてもよい。また、例えば、ＡＺ１０１−１とＡＺ１０１−２は、同時に障害が発生することを防止するため、互いに遠隔な場所に設置してもよいし、物理的に完全に独立した構成にしてもよい。

ＩＡＳ１０２−１〜６（以降、ＩＡＳ１０２と呼ぶ場合がある）は、ＶＭが稼働する装置であり、例えば、サーバマシンである。ＩＡＳ１０２は、それぞれＣＰＵ（Central Processing Unit）を有し、ＣＰＵが特定のプログラムを実行することで、自装置のメモリ上にＶＭを生成、又は削除したり、生成したＶＭを稼働させたりする。図１においては、ＩＡＳ１０２−１〜６は、それぞれ１つのＶＭを有する。しかし、ＩＡＳ１０２−１〜６は、ＶＭを稼働させていなくてもよいし、複数のＶＭを稼働させていてもよい。なお、ＮＦＶシステム１０は、ＩＡＳ１０２に代替し、Ｉｎｔｅｌ製以外のプロセッサを有するサーバマシンを有してもよい。

ＮＦＶＩ１００は、ＩＡＳ１０２を管理、制御し、ＩＡＳ１０２上でＶＭを生成する装置であり、例えば、コンピュータやサーバマシンである。ＮＦＶＩ１００は、ＩＡＳ１０２のメモリ上にＶＭを生成したり、ＩＡＳ１０２のメモリ上のＶＭを削除したりする。

ＶＩＭ２００は、ＮＦＶＩ１００配下のＩＡＳ１０２における、ＶＭが使用するリソースの管理及び制御を行う。また、ＶＩＭ２００は、例えば、ＩＡＳ１０２それぞれのメモリ上で稼働しているＶＭが使用する使用リソースと、使用リソース以外のリソース残量を管理する。稼働中のＶＭが使用するリソースは、例えば、ＣＰＵのコア数である。稼働中のＶＭは、事前に設定されたコア数を、リソースとして使用する。ＶＩＭ２００は、ＶＮＦＭ３００からの指示に従い、指示されたＩＡＳ１０２に、指示されたリソース（例えば、コア数）を使用するＶＭを生成する。なお、ＶＭが使用するリソース（例えば、コア数）、ＶＭを稼働させるＩＡＳ１０２に関する情報をｆｌａｖｏｒと呼ぶ。また、ｆｌａｖｏｒは、ＶＭを生成し、稼働させるためのプログラム（イメージファイル）に関する情報を有してもよい。

ＶＩＭ２００は、複数のｆｌａｖｏｒを登録しておくことが可能であり、どのｆｌａｖｏｒの内容に従うかをＶＮＦＭ３００から指示され、ＶＮＦＭ３００の指示に応答し、ｆｌａｖｏｒで示されたＩＡＳ１０２のメモリ上にＶＭを生成する。

ＶＮＦＭ３００は、ＶＭを管理する装置であり、例えば、コンピュータやサーバマシンである。ＶＮＦＭ３００は、例えば、ＶＭを生成し、稼働させるプログラム（イメージファイル）を、ＶＩＭ２００を介して、ＮＦＶＩ１００に提供する。また、ＶＮＦＭ３００は、例えば、ＶＭを稼働させるＩＡＳ１０２を決定する。そして、決定した内容のｆａｌｖｏｒをＶＩＭ２００に登録させ、登録させたｆｌａｖｏｒに従いＶＭを生成するようＶＩＭ２００に指示する。

ＮＦＶＯ４００は、ＮＦＶシステム１０の管理者とのインターフェースであり、例えば、ディスプレイを有するコンピュータである。ＮＦＶＯ４００は、例えば、ＩＡＳ１０２の故障などにより、ＶＭが削除されたこと（あるいは正しく動作しなくなったこと）を検出する。ＮＦＶＯ４００は、ＩＡＳ１０２の故障やＶＭの削除などの障害を検出すると、例えば、ディスプレイなどの表示部に障害（故障）の内容を表示する。ＮＦＶＯ４００は、障害発生時に、障害を復旧させるためのヒーリング処理を行う。ヒーリング処理は、例えば、削除されたＶＭを再生成する処理である。ヒーリング処理は、障害を検出したＮＦＶＯ４００により、自動で実行されてもよいし、障害の内容を表示部で確認した管理者が、ＮＦＶＯ４００を操作することにより実行されてもよい。

なお、図１において、ＮＦＶＯ４００とＶＮＦＭ３００は、それぞれ異なる装置であるが、１つの制御装置３０であってもよい。また、ＶＩＭ２００、ＮＦＶＩ１００、及びＩＡＳ１０２は、それぞれ異なる装置であるが、１つの仮想マシン管理装置２０であってもよい。

＜ＮＦＶＯの構成例＞
図２は、ＮＦＶＯ４００の構成例を示す図である。ＮＦＶＯ４００は、ＣＰＵ４１０、ストレージ４２０、ＤＲＡＭ（Dynamic Random Access Memory）などのメモリ４３０、及びＮＩＣ（Network Interface Card）４４０を有する。

ストレージ４２０は、プログラムやデータを記憶する、フラッシュメモリ、ＨＤＤ（Hard Disk Drive）、又はＳＳＤ（Solid State Drive）などの補助記憶装置である。ストレージ４２０は、故障検出プログラム４２１、Ｇｒａｎｔ判定プログラム４２２、ＶＭ毎コア数テーブル４２３、及びｆｌａｖｏｒ管理テーブル４２４を記憶する。

図３は、ＶＭ毎コア数テーブル４２３の例を示す図である。ＶＭ毎コア数テーブルは、稼働中のＶＭがリソースとして使用する、最大コア数と最小コア数を記憶するテーブルである。Ｖ毎Ｍコア数テーブル４２３に記憶する情報は、例えば、「ＶＭ」、「コア数」である。

「ＶＭ」は、対象となるＶＭの名称や識別子である。図３のＶＭ毎コア数テーブル４２３は、ＶＭ１〜ＶＭ４のコア数を記憶する。

「コア数」は、「最大」と「最小」を記憶する。「最大」は、対象となるＶＭが使用する最大のコア数であり、例えば、ＶＭ１の最大コア数は「３」である。「最小」は、対象となるＶＭの使用する最小のコア数であり、例えば、ＶＭ１の最小コア数は「２」である。

ｆｌａｖｏｒ管理テーブル４２４は、ＶＩＭ２００に登録したｆｌａｖｏｒの識別子（例えば、番号）やｆｌａｖｏｒの内容、及び、現在運用されているｆｌａｖｏｒの識別子など、ｆｌａｖｏｒに関する情報を記憶するテーブルである。ｆｌａｖｏｒ管理テーブル４２４は、例えば、ｆｌａｖｏｒを新規で登録したとき、ｆｌａｖｏｒを削除したとき、運用するｆｌａｖｏｒを変更したときに更新される。

メモリ４３０は、ストレージ４２０に記憶されているプログラムをロードする領域である。また、メモリ４３０は、プログラムがデータを記憶する領域としても使用される。

ＮＩＣ４４０は、ＶＮＦＭ３００と接続するネットワークインターフェースである。ＮＦＶＯ４００は、ＮＩＣ４４０を介して、ＶＮＦＭ３００と通信を行う。

ＣＰＵ４１０は、故障検出プログラム４２１を実行することで、検出部を構築し、故障検出処理を行う。故障検出処理は、稼働中であったＶＭが削除されたことを検出する処理である。ＮＦＶＯ４００は、例えば、ＩＡＳ１０２のいずれかに故障が発生したことを示す警告メッセージを、ＮＦＶＩ１００から、ＶＩＭ２００及びＶＮＦＭ３００を介して受信することで、故障の発生を検出する。ＮＦＶＯ４００は、故障検出処理において、ＶＭが削除されたこと、あるいはＶＭが削除されている可能性が高い故障が発生したことを検出すると、ヒーリング処理を行う。

また、ＣＰＵ４１０は、故障検出プログラム４２１が有するヒーリングモジュール４２１１を実行することで、ヒーリング処理を行う。ヒーリング処理は、ＩＡＳ１０２の故障により削除されたＶＭを再生成する処理である。ＮＦＶＯ４００は、ヒーリング処理において、ＶＭを再生成することを要求するメッセージであるヒーリングメッセージを、ＶＮＦＭ３００に送信する。

ＣＰＵ４１０は、Ｇｒａｎｔ判定プログラム４２２を実行することで、取得部を構築し、Ｇｒａｎｔ判定処理を行う。Ｇｒａｎｔ判定処理は、ＶＭの生成許可を要求するメッセージであるＧｒａｎｔを、ＶＮＦＭ３００から受信する処理である。ＮＦＶＯ４００は、Ｇｒａｎｔ判定処理において、Ｇｒａｎｔで指定されたｆｌａｖｏｒでのＶＭの生成を許可（accepted）するか、拒絶（rejected）するかを決定し、Ｇｒａｎｔに対する応答メッセージであるＧｒａｎｔＲｅｓｐｏｎｓｅに決定した結果を含め、ＶＮＦＭ３００に送信する。また、ＮＦＶＯ４００は、Ｇｒａｎｔ判定処理において、運用中のｆｌａｖｏｒでのＶＭの生成（故障前のｆｌａｖｏｒと同じＩＡＳ１０２でのＶＭの再生成）を要求された場合、ＶＩＭ２００から最新のリソース（リソース残量）を取得する。そして、ＮＦＶＯ４００は、取得した最新のリソース残量に基づき、運用中のｆｌａｖｏｒでのＶＭ生成が可能でないと判定した場合、結果を拒絶としたＧｒａｎｔＲｅｓｐｏｎｓｅに、取得した最新のリソース残量を含め、ＶＮＦＭ３００に送信する。

また、ＣＰＵ４１０は、Ｇｒａｎｔ判定プログラム４２２が有するリソース情報取得モジュール４２２１を実行することで、取得部を構築し、リソース情報取得処理を行う。リソース情報取得処理は、ＶＩＭ２００から、リソース残量を取得する処理である。ＮＦＶＯ４００は、リソース情報取得処理において、リソース残量の送信を要求するリソース情報要求メッセージをＶＩＭ２００に送信する。そして、ＮＦＶＯ４００は、リソース情報要求メッセージの受信に応答し、ＶＩＭ２００から送信されるリソース情報応答メッセージを受信し、リソース残量を取得する。なお、リソース情報取得要求メッセージは、再生成する対象のＶＭ（削除されたＶＭ）の属するＡＺを含む。

＜ＶＮＦＭの構成例＞
図４は、ＶＮＦＭ３００の構成例を示す図である。ＶＮＦＭ３００は、ＣＰＵ３１０、ストレージ３２０、ＤＲＡＭなどのメモリ３３０、及びＮＩＣ３４０−１，２を有する。

ストレージ３２０は、プログラムやデータを記憶する、フラッシュメモリ、ＨＤＤ、又はＳＳＤなどの補助記憶装置である。ストレージ３２０は、ヒーリング受信プログラム３２１、ｆｌａｖｏｒ作成プログラム３２２、ＶＭ毎コア数テーブル４２３、ｆｌａｖｏｒ管理テーブル４２４及びＶＭ要件テーブル３２５を記憶する。

ＶＭ毎コア数テーブル４２３、ｆｌａｖｏｒ管理テーブル４２４は、例えば、ＮＦＶＯ４００が有するＶＭ毎コア数テーブル４２３、ｆｌａｖｏｒ管理テーブル４２４と同様のテーブルである。

図５は、ＶＭ要件テーブル３２５の例を示す図である。ＶＭ要件テーブル３２５は、ＶＭを生成する要件を記憶するテーブル（記憶部）である。ＶＭ要件テーブル３２５に記憶する情報は、例えば、「ＶＭ」及び「要件」である。

「ＶＭ」は、対象となるＶＭの名称や識別子である。図５のＶＭ要件テーブル３２５は、ＶＭ１〜ＶＭ４の要件を記憶する。

「要件」は、ＶＭを生成する要件である。図５によると、ＶＭ１の要件は、「ＶＭ２とは異なるＡＺで生成」である。例えば、ＶＭ１とＶＭ２は、同様の処理を行うことができるＶＭであり、通常運用時に使用されるＡＣＴ系のＶＭと、ＡＣＴ系のＶＭが削除された場合やＡＣＴ系のＶＭの処理負荷が過剰になった場合に備え、予備的に生成されるＳＴＡＮＢＹ系のＶＭであるとする。この場合、障害発生時に、少なくともどちらか一方が稼働することが求められるため、ＶＭ１とＶＭ２は、物理的に独立した異なるＡＺで生成されることが好ましい。

また、図５によると、ＶＭ３の要件は、「ＶＭ４と同じＡＺで生成」及び「ＶＭ４と異なるＩＡＳで生成」である。例えば、ＶＭ３とＶＭ４は、互いに通信する機会が多い場合、通信経路の通信量を抑制するため、物理的に近くに配置されている同一ＡＺ内のサーバに生成されることが好ましい。一方、ＶＭ３とＶＭ４の両方が削除された場合に、システム全体に与える影響が大きい場合、ＶＭ３とＶＭ４は、両方のＶＭが同時に削除されてしまうことを防止するため、異なるＩＡＳ上で生成されることが好ましい。ＶＮＦＭ３００は、ＶＭ要件テーブル３２５を参照することで、ＶＭそれぞれの要件を満たすよう、ＶＭの生成、削除をＶＩＭ２００に指示する。

メモリ３３０は、ストレージ３２０に記憶されているプログラムをロードする領域である。また、メモリ３３０は、プログラムがデータを記憶する領域としても使用される。

ＮＩＣ３４０−１，２は、ＮＦＶＯ４００及びＶＩＭ２００と接続するネットワークインターフェースである。ＶＮＦＭ３００は、ＮＩＣ３４０−１，２を介して、ＮＦＶＯ４００及びＶＩＭ２００と通信を行う。

ＣＰＵ３１０は、ヒーリング受信プログラム３２１を実行することで、ヒーリング受信処理を行う。ヒーリング受信処理は、ＮＦＶＯ４００からヒーリングメッセージを受信する処理である。ＶＮＦＭ３００は、ヒーリング受信処理において、例えば、ｆｌａｖｏｒを含むｇｒａｎｔをＮＦＶＯ４００に送信することで、ＮＦＶＯ４００にｇｒａｎｔに含まれるｆｌａｖｏｒでＶＭを生成してもよいか否かを確認する。

ＣＰＵ３１０は、ｆｌａｖｏｒ作成プログラム３２２を実行することで、制御部を構築し、ｆｌａｖｏｒ作成処理を行う。ｆｌａｖｏｒ作成処理は、リソース残量に応じたｆｌａｖｏｒを作成し、作成した新規ｆｌａｖｏｒに従いＶＭを生成するようＶＩＭ２００に指示する処理である。

＜ＶＩＭの構成例＞
図６は、ＶＩＭ２００の構成例を示す図である。ＶＩＭ２００は、ＣＰＵ２１０、ストレージ２２０、ＤＲＡＭなどのメモリ２３０、及びＮＩＣ２４０−１，２を有する。

ストレージ２２０は、プログラムやデータを記憶する、フラッシュメモリ、ＨＤＤ、又はＳＳＤなどの補助記憶装置である。ストレージ２２０は、リソース管理プログラム２２１、リソース情報要求受信プログラム２２２、ｆｌａｖｏｒ管理テーブル４２４、及びリソース管理テーブル２２３を記憶する。

ｆｌａｖｏｒ管理テーブル４２４は、例えば、ＮＦＶＯ４００が有するｆｌａｖｏｒ管理テーブル４２４と同様のテーブルである。

図７は、リソース管理テーブル２２３の例を示す図である。リソース管理テーブル２２３は、ＮＦＶＩ１００の配下のＩＡＳ１０２のリソースを管理するテーブルである。ＶＩＭ２００は、例えば、リソース管理テーブル２２３において、各ＩＡＳ１０２のＣＰＵのコア数を管理する。

リソース管理テーブル２２３に記憶する情報は、例えば、「ＡＺ」、「ＩＡＳ」、「全コア数」、「稼働ＶＭ」、及び「残コア数」である。

「ＡＺ」は、配下のＡＺの名称や識別子である。図７のリソース管理テーブル２２３は、ＡＺ１（ＡＺ１０１−１）とＡＺ２（ＡＺ１０１−２）のリソースを記憶する。

「ＩＡＳ」は、配下のＩＡＳの名称や識別子である。図７のリソース管理テーブル２２３は、ＩＡＳ１（ＩＡＳ１０２−１）、ＩＡＳ２（ＩＡＳ１０２−２）、ＩＡＳ３（ＩＡＳ１０２−３）、ＩＡＳ４（ＩＡＳ１０２−４）、ＩＡＳ５（ＩＡＳ１０２−５）、ＩＡＳ６（ＩＡＳ１０２−６）のリソースを記憶する。

「全コア数」は、それぞれのＩＡＳにおける全コア数である。全コア数は、ＩＡＳ上でＶＭが稼働していないときの残コア数である。図７のリソース管理テーブル２２３は、例えば、ＩＡＳ１の全コア数は４であることを記憶する。

「稼働ＶＭ」は、それぞれのＩＡＳで稼働中のＶＭであり、ＶＭの名称や識別子が記憶される。図７のリソース管理テーブル２２３は、例えば、ＩＡＳ１で稼働中のＶＭは、ＶＭ１であることを記憶する。

「残コア数」は、それぞれのＩＡＳにおける残コア数である。残コア数は、ＩＡＳ上で生成したＶＭが使用することができるコア数（すなわち、稼働中のＶＭが使用していないコア数）を示す。図７のリソース管理テーブル２２３は、例えば、ＩＡＳ１の残コア数は１であることを記憶する。

図８は、運用中のｆｌａｖｏｒの例を示す図である。図８によると、例えばＩＡＳ１上ではＶＭ１が稼働中であり、ＶＭ１の使用コア数は３である。なお、ｆｌａｖｏｒは、例えば、ＶＭ要件テーブル３２５に記憶する要件に基づき、ＶＮＦＭ３００が作成する。すなわち、運用中のｆｌａｖｏｒは、ＶＭ要件テーブル３２５に記憶する要件を満たす内容となっている。

メモリ２３０は、ストレージ２２０に記憶されているプログラムをロードする領域である。また、メモリ２３０は、プログラムがデータを記憶する領域としても使用される。

ＮＩＣ２４０−１，２は、ＶＮＦＭ３００及びＮＦＶＩ１００と接続するネットワークインターフェースである。ＶＩＭ２００は、ＮＩＣ３４０−１，２を介して、ＶＮＦＭ３００及びＮＦＶＩ１００と通信を行う。

ＣＰＵ２１０は、リソース管理プログラム２２１を実行することで、リソース管理処理を行う。リソース管理処理は、ＩＡＳ１０２（ＩＡＳ１〜６）のそれぞれのリソースを管理する処理である。ＶＩＭ２００は、リソースの状態が変化すると、リソース管理テーブル２２３を更新する。

ＣＰＵ２１０は、リソース情報要求受信プログラム２２２を実行することで、リソース情報要求受信処理を行う。リソース情報要求受信処理は、リソース情報要求で指定されたＡＺに属するＩＡＳ１０２それぞれのリソース残量を、リソース情報応答に含め、ＮＦＶＯ４００に送信する処理である。

＜ヒーリング処理＞
図９は、ＮＦＶシステム１０におけるヒーリング処理のシーケンスの例を示す図である。例えば、地震などの災害発生により、ＮＦＶＩ１００の配下のＩＡＳ１０２の一部が故障したり、電源供給が途絶えたりすることで、ＩＡＳ１０２上で稼働していたＶＭが削除されたり、ＶＭが正しく動作できなくなったりする。このとき、ＶＩＭ２００は、ＮＦＶＯ４００に、障害や故障が発生したことを通知するアラームを送信する（Ｓ１０１）。アラームは、例えば、削除されたＶＭを示す情報を含み、図９においては、ＶＭ１が削除されたものとする。

ＮＦＶＯ４００は、アラームを受信すると、例えば、アラームに含まれる障害の内容を、ディスプレイなどの画面に表示し、ＮＦＶシステム１０の管理者に通知する。管理者は、画面を確認し、ＮＦＶＯ４００を操作し、障害が発生したＶＭ１を復旧させるためのＨｅａｌメッセージ（ヒーリングメッセージ）を、ＶＮＦＭ３００に送信する（Ｓ１０２）。また、ＮＦＶＯ４００は、アラームを受信すると、例えば、アラームに含まれる障害を復旧するよう、管理者を介さず、ＶＮＦＭにＨｅａｌメッセージ（ヒーリングメッセージ）を送信してもよい（Ｓ１０２）。

図１０は、故障発生後のリソース管理テーブル２２３の例を示す図である。故障発生後のリソース管理テーブル２２３は、故障発生前の図７のリソース管理テーブル２２３の状態から、ＩＡＳ１で稼働中であったＶＭ１が削除され、ＩＡＳ１が故障したことにより、ＩＡＳ１の全コア数及び残コア数が０となる。

図９のシーケンスに戻り、ＶＮＦＭ３００は、Ｈｅａｌを受信すると、運用中の旧ｆｌａｖｏｒに従いＶＭ１を生成することの許諾を要求するｇｒａｎｔメッセージをＮＦＶＯ４００に送信する（Ｓ１０３）。ｇｒａｎｔＳ１０３は、ＶＭ１が属するＡＺ１（第１サーバ群）を示すＡＺ情報を含む。また、ｇｒａｎｔＳ１０３は、障害が発生したＶＭ１の再生成の許諾を要求する。ＶＭの再生成は、古い（故障発生前に稼働中であった）ＶＭを削除し、削除したＶＭを新たに生成することである。古いＶＭを削除する理由は、ＶＭは障害によって削除されているが、ＶＭが使用していたメモリやリソースが正しく解放されているか否か不明であるため、確実にメモリやリソースを解放するためである。

ＮＦＶＯ４００は、ｇｒａｎｔを受信すると、Ｇｒａｎｔ判定処理を行う（Ｓ１０４）。

図１１は、Ｇｒａｎｔ判定処理Ｓ１０４の処理フローチャートの例を示す図である。ＮＦＶＯ４００は、ｇｒａｎｔで指定されたｆｌａｖｏｒが旧ｆｌａｖｏｒ（運用中のｆｌａｖｏｒ）か否かを確認する（Ｓ１０４−１）。ＮＦＶＯ４００は、運用中のｆｌａｖｏｒを、ｆｌａｖｏｒ管理テーブル４２４に記憶している。

ＮＦＶＯ４００は、ｇｒａｎｔで指定されたｆｌａｖｏｒが旧ｆｌａｖｏｒである場合（Ｓ１０４−１のＹｅｓ）、ＶＩＭ２００にリソース情報要求を送信する（Ｓ１０４−２）。リソース情報要求は、削除されたＶＭが属するＡＺを示すＡＺ情報を含む。そして、ＮＦＶＯ４００は、リソース情報要求に対する応答メッセージであるリソース情報応答を、ＶＩＭ２００から受信するのを待ち受ける（Ｓ１０４−３のＮｏ）。

ＮＦＶＯ４００は、リソース情報応答を受信すると（Ｓ１０４−３のＹｅｓ）、旧ｆｌａｖｏｒで、削除されたＶＭの生成が可能か否かを判定する（Ｓ１０４−４）。リソース情報応答は、例えば、リソース情報要求に含まれるＡＺ情報のＡＺのリソース残量が含まれる。ＮＦＶＯ４００は、リソース情報応答に含まれるリソース残量に基づき、削除されたＶＭが旧ｆｌａｖｏｒで生成することが可能か否かを判定する。

ＮＦＶＯ４００は、旧ｆｌａｖｏｒで削除されたＶＭの生成が可能であると判定すると（Ｓ１０４−４のＹｅｓ）、ｇｒａｎｔで要求された結果が許可（accepted）であることを含む、ＧｒａｎｔＲｅｓｐｏｎｓｅを、ＶＮＦＭ３００に送信する（Ｓ１０４−６）。一方、ＮＦＶＯ４００は、旧ｆｌａｖｏｒで削除されたＶＭの生成が可能ではないと判定すると（Ｓ１０４−４のＮｏ）、ｇｒａｎｔで要求された結果が拒絶（rejected）であること含む、ＧｒａｎｔＲｅｓｐｏｎｓｅを、ＶＮＦＭ３００に送信する（Ｓ１０４−５）。

また、一方、ＮＦＶＯ４００は、受信したｇｒａｎｔで指定されたｆｌａｖｏｒが旧ｆｌａｖｏｒではない場合、ｇｒａｎｔで指定されたｆｌａｖｏｒでＶＭを生成することを許可（accepted）することを含む、ＧｒａｎｔＲｅｓｐｏｎｓｅを、ＶＮＦＭ３００に送信する（Ｓ１０４−６）。

図９のシーケンスに戻り、ＮＦＶＯ４００は、Ｇｒａｎｔ判定処理Ｓ１０４において、ｇｒａｎｔで指定されたｆｌａｖｏｒが旧ｆｌａｖｏｒであるため（図１１のＳ１０４−１のＹｅｓ）、障害が発生した（削除された）ＶＭ１の属する（生成を許可された）ＡＺ１を含むリソース情報要求をＶＩＭ２００に送信する（Ｓ１０５）。

ＶＩＭ２００は、リソース情報要求を受信すると、リソース情報要求受信処理を行い、ＡＺ情報のＡＺ１のリソース残量を含むリソース情報応答を、ＮＦＶＯ４００に送信する（Ｓ１０６）。なお、リソース情報応答に含まれるリソース残量は、ＩＡＳごとのリソース残量であり、例えば、リスト形式で示される。

ＮＦＶＯ４００は、Ｇｒａｎｔ判定処理Ｓ１０４において、旧ｆｌａｖｏｒで示されたＩＡＳ１のリソース残量が０であり、ＶＭ１の生成が可能ではないと判定し(図１１のＳ１０４−４のＮｏ)、結果を拒絶とするＧｒａｎｔＲｅｓｐｏｎｓｅをＶＮＦＭ３００に送信する（Ｓ１０７、図１１のＳ１０４−５）。ＧｒａｎｔＲｅｓｐｏｎｓｅＳ１０７は、ＶＭ１の属するＡＺであるＡＺ１と、ＡＺ１のリソース残量を含む。

ＶＮＦＭ３００は、結果を拒絶とするＧｒａｎｔＲｅｓｐｏｎｓｅを受信すると、ｆｌａｖｏｒ作成処理を行う（Ｓ１０８）。

図１２は、ｆｌａｖｏｒ作成処理の処理フローチャートの例を示す図である。ＶＮＦＭ３００は、ＧｒａｎｔＲｅｓｐｏｎｓｅに含まれるリソース残量に基づき、生成対象のＶＭの最大コア数を以上の残コア数を有するＩＡＳが存在するか否かを確認する（Ｓ１０８−１）。ＶＮＦＭ３００は、最大コア数を満たすＩＡＳが存在する場合（Ｓ１０８−１のＹｅｓ）、最大コア数を満たすＩＡＳを、削除されたＶＭを生成するＩＡＳとして選択する（Ｓ１０８−３）。

一方、ＶＮＦＭ３００は、最大コア数を満たすＩＡＳが存在しない場合（Ｓ１０８−１のＮｏ）、残コア数が最大であるＩＡＳを仮選択する（Ｓ１０８−２）。そして、ＶＮＦＭ３００は、仮選択したＩＡＳの残コア数が、生成対象のＶＭの最小コア数以上か否かを確認する（Ｓ１０８−４）。ＶＮＦＭ３００は、仮選択したＩＡＳの残コア数が生成対象のＶＭの最小コア数以上でない場合（Ｓ１０８−４のＮｏ）、ＶＭを生成できないと判定し、処理を終了する。一方、ＶＮＦＭ３００は、仮選択したＩＡＳの残コア数が生成対象のＶＭの最小コア数以上である場合（Ｓ１０８−４のＮｏ）、仮選択したＩＡＳを、ＶＭを生成するＩＡＳとして選択する（Ｓ１０８−５）。

ＶＮＦＭ３００は、ＶＭを生成するＩＡＳを選択すると、選択したＩＡＳでＶＭを生成する新規ｆｌａｖｏｒを作成する（Ｓ１０８−６）。そして、ＶＮＦＭ３００は、作成した新規ｆｌａｖｏｒをＶＩＭ２００に登録し（Ｓ１０８−７）、新規ｆｌａｖｏｒを指定したｇｒａｎｔをＮＦＶＯ４００に送信し（Ｓ１０８−８）、ＧｒａｎｔＲｅｓｐｏｎｓｅの受信を待ち受ける（Ｓ１０８−９のＮｏ）。

ＶＮＦＭ３００は、ＧｒａｎｔＲｅｓｐｏｎｓｅを受信すると（Ｓ１０８−９のＹｅｓ）、ＧｒａｎｔＲｅｓｐｏｎｓｅの結果を確認する（Ｓ１０８−１０）。ＶＮＦＭ３００は、ＧｒａｎｔＲｅｓｐｏｎｓｅがａｃｃｅｐｔｅｄ（許可）である場合（Ｓ１０８−１０のＹｅｓ）、新規ｆｌａｖｏｒに従いＶＭを生成するようＶＩＭ２００に指示を送信する（Ｓ１０８−１１）。一方、ＶＮＦＭ３００は、ＧｒａｎｔＲｅｓｐｏｎｓｅがｒｅｊｅｃｔｅｄ（拒絶）である場合（Ｓ１０８−１０のＮｏ）、ＶＭを生成せずに処理を終了する。

すなわち、ＶＮＦＭ３００は、ｆｌａｖｏｒ作成処理Ｓ１０８において、残コア数が最大コア数以上であるＩＡＳを優先して選択する。ＶＮＦＭ３００は、最大コア数以上の残コア数のＩＡＳが存在しない場合、最小コア数以上であって、残コア数が最も多いＩＡＳを選択する。これにより、ＶＮＦＭ３００は、できるだけ多いコア数で、削除されたＶＭの再生成を行うことができる。

図９のシーケンスに戻り、ＶＮＦＭ３００は、ｆｌａｖｏｒ作成処理Ｓ１０８において、ＶＭ１の最大コア数（３）を満たす残コア数のＩＡＳが存在しないため（図１２のＳ１０８−１のＮｏ）、残コア数が最大（２）のＩＡＳ２（ＩＡＳ３でもよい）を仮選択する（図１２のＳ１０８−２）。そして、ＶＮＦＭ３００は、仮選択したＩＡＳ２の残コア数（２）がＶＭ１の最小コア数（２）以上であるため（図１２のＳ１０８−４のＹｅｓ）、ＩＡＳ２を、ＶＭ１を生成するＩＡＳとして選択する（Ｓ１０８−５）。そして、ＶＮＦＭ３００は、コア数２を使用するＶＭ１をＩＡＳ２で生成する新規ｆｌａｖｏｒを作成し（図１２のＳ１０８−６）、新規ｆｌａｖｏｒを対象とするｆｌａｖｏｒ登録要求をＶＩＭ２００に送信する（Ｓ１０９、図１２のＳ１０８−７）。ＶＮＦＭ３００は、ｆｌａｖｏｒ登録完了を受信すると（Ｓ１１０）、新規ｆｌａｖｏｒを指定したｇｒａｎｔをＮＦＶＯ４００に送信する（Ｓ１１１、図１２のＳ１０８−８）。

図１３は、新規ｆｌａｖｏｒの例を示す図である。新規ｆｌａｖｏｒは、上述したように、残コア数が２であるＩＡＳ２において、コア数２を使用するＶＭ１を生成するｆｌａｖｏｒである。ＶＭ１以外のＶＭ２〜４は、旧ｆｌａｖｏｒと同様である。

図９のシーケンスに戻り、ＮＦＶＯ４００は、ｇｒａｎｔを受信すると、Ｇｒａｎｔ判定処理を行う（Ｓ１０４）。ＮＦＶＯ４００は、Ｇｒａｎｔ判定処理Ｓ１０４において、旧ｆｌａｖｏｒが指定されていないと判定し（図１１のＳ１０４−１のＮｏ）、結果を許可とするＧｒａｎｔＲｅｓｐｏｎｓｅをＶＮＦＭ３００に送信する（Ｓ１１２、図１１のＳ１０４−６）。

ＶＮＦＭ３００は、ｆｌａｖｏｒ作成処理Ｓ１０８において、ＧｒａｎｔＲｓｐｏｎｓｅを受信し（図１２のＳ１０８−９のＹｅｓ）、結果が許可であるため（図１２のＳ１０８−１０のＹｅｓ）、新規ｆｌａｖｏｒでのＶＭの生成を指示する仮想マシン生成指示をＶＩＭ２００に送信する（Ｓ１１３、図１２のＳ１０８−１１）。

ＶＩＭ２００は、仮想マシン生成指示を受信すると、指定された新規ｆｌａｖｏｒに従い、ＮＦＶＩ１００を介して、コア数２を使用するＶＭ１をＩＡＳ２で生成し、仮想マシン生成完了をＶＮＦＭ３００に送信する（Ｓ１１４）。

図１４は、ヒーリング処理完了後のリソース管理テーブル２２３の例を示す図である。ＶＩＭ２００は、新規ｆｌａｖｏｒに従い、コア数２のＶＭ１をＩＡＳ２で生成する。ＶＭ１がＩＡＳ２のコア数２を使用するため、ＩＡＳ２の残コア数は０となる。

図９のシーケンスに戻り、ＶＮＦＭ３００は、仮想マシン生成完了を受信すると、ヒーリング処理が成功及び完了したこと（finished）を示すＬｉｆｅｃｙｃｌｅＣｈａｎｇｅＮｏｔｉｆｉｃａｔｉｏｎを、ＮＦＶＯ４００に送信する（Ｓ１１５）。

第１の実施の形態では、ＮＦＶＯ４００は、ＶＭ１を旧ｆｌａｖｏｒで再生成する前に、ＶＩＭ２００からリソース残量を取得する。ＮＦＶＯ４００は、故障発生前のＩＡＳでのＶＭ１の生成を行わず、リソース残量から適正なＩＡＳを選択する。これにより、リソース不足によりＶＭ１の再生成の失敗を防止し、ＮＦＶシステム１０の継続した運用が可能となる。

なお、第１の実施の形態において、故障発生により削除されるＶＭは一つである。削除されるＶＭが複数ある場合、ＶＮＦＭ３００は、削除された複数のＶＭ全てのコア数の要件を満たすよう新規ｆｌａｖｏｒを作成する。また、ＶＮＦＭ３００は、リソース不足により、削除された複数のＶＭ全てのコア数の要件を満たすことができない場合、例えば、ＶＭに優先順位を付し、優先順位が高いＶＭを優先して再生成するようｆｌａｖｏｒを作成する。

[第２の実施の形態]
次に、第２の実施の形態について説明する。第２の実施の形態は、ＶＭが削除されたＩＡＳの故障が復旧する場合を想定している。なお、各装置の構成例及び各処理のフローチャートは、第１の実施の形態と同様である。

＜ヒーリング処理＞
図１５は、ＮＦＶシステム１０におけるヒーリング処理のシーケンスの例を示す図である。処理Ｓ１０１から処理Ｓ１０６は、図９に示す処理Ｓ１０１から処理Ｓ１０６と同様である。ただし、図９のシーケンスでは、ＩＡＳ１の故障は復旧しないが、図１５のシーケンスでは、ＩＡＳ１の故障がリソース情報要求Ｓ１０５の送信までに復旧する。ＩＡＳ１の復旧は、例えば、災害により途絶えていた電源供給の復旧や、通信回線の復旧などである。

図１６は、故障復旧後のリソース管理テーブル２２３の例を示す図である。図１６によると、ＩＡＳ１で稼働していたＶＭ１は、削除されている。しかし、ＩＡＳ１のリソースは、故障の復旧により、全コア数は故障発生前の４に戻り、残コア数は全コア数と同じ４となる。

図９のシーケンスに戻り、ＮＦＶＯ４００は、Ｇｒａｎｔ判定処理Ｓ１０４において、リソース情報応答を受信し（図１１のＳ１０４−３のＹｅｓ）、旧ｆｌａｖｏｒで示されたＩＡＳ１のリソース残量が４であり、ＶＭ１の生成が可能であると判定し(図１１のＳ１０４−４のＹｅｓ)、結果を許可とするＧｒａｎｔＲｅｓｐｏｎｓｅをＶＮＦＭ３００に送信する（Ｓ２０１、図１１のＳ１０４−６）。

ＶＮＦＭ３００は、要求が許可されたＧｒａｎｔＲｓｐｏｎｓｅを受信し、旧ｆｌａｖｏｒでのＶＭの生成を指示する仮想マシン生成指示をＶＩＭ２００に送信する（Ｓ２０２）。

ＶＩＭ２００は、仮想マシン生成指示を受信すると、指定された旧ｆｌａｖｏｒに従い、ＮＦＶＩ１００を介して、コア数３を使用するＶＭ１をＩＡＳ１で生成（再生成）し、仮想マシン生成完了をＶＮＦＭ３００に送信する（Ｓ２０３）。このとき、リソース管理テーブル２２３は、図７のリソース管理テーブル２２３と同じ状態となる。

ＶＮＦＭ３００は、仮想マシン生成完了を受信すると、ヒーリング処理が成功及び完了したこと（finished）を示すＬｉｆｅｃｙｃｌｅＣｈａｎｇｅＮｏｔｉｆｉｃａｔｉｏｎを、ＮＦＶＯ４００に送信する（Ｓ２０４）。

第２の実施の形態では、ＮＦＶＯ４００は、故障前のＩＡＳでＶＩＭを再生成することが可能であるとき、新規ｆｌａｖｏｒの作成をせずに、旧ｆｌａｖｏｒでＶＭ１を再生成する。これにより、ＮＦＶＯ４００は、例えば、故障したＩＡＳが早急に復旧した場合、新規ｆｌａｖｏｒの作成や新規ｆｌａｖｏｒの登録などの処理を行わずに、ヒーリングを成功させることができる。

以上、第１及び第２の実施の形態を含む実施形態に関し、更に以下の付記を開示する。

（付記１）
仮想マシンをサーバ上で生成し、前記仮想マシンが使用する前記サーバの有するリソースを管理する仮想マシン管理装置を、制御する制御装置であって、
前記仮想マシン管理装置が生成した仮想マシンが削除されたことを検出する検出部と、
前記仮想マシンが削除されたことを検出したとき、前記削除された仮想マシン以外の他の仮想マシンが使用していないリソース残量を、前記仮想マシン管理装置から取得する取得部と、
前記リソース残量に応じて、前記削除された仮想マシンを生成するよう前記仮想マシン管理装置に指示する制御部を有する
制御装置。

（付記２）
前記リソースは、前記サーバが有するプロセッサのコア数であり、
前記取得部は、前記サーバの残コア数を前記リソース残量として取得し、
前記制御部は、前記残コア数に基づき、前記削除された仮想マシンを生成するサーバを選択し、前記選択したサーバで前記削除された仮想マシンを生成するよう前記仮想マシン管理装置に指示する
付記１記載の制御装置。

（付記３）
さらに、前記削除された仮想マシンが使用するコア数は、第１数値から第１数値以上の第２数値の範囲内の数であり、
前記制御部は、前記残コア数が前記第２数値以上であるサーバを他のサーバよりも優先して選択する
付記２記載の制御装置。

（付記４）
前記制御部は、前記残コア数が前記第２数値以上であるサーバが存在しない場合、前記コア数が前記第１数値以上かつ前記第２数値未満の第３数値であるサーバを選択し、前記第３数値のコア数を使用する前記削除された仮想マシンを生成するよう指示する
付記３記載の制御装置。

（付記５）
前記制御部は、前記残コア数が前記第１数値以上であるサーバが存在しない場合、前記指示を行わない
付記４記載の制御装置。

（付記６）
前記取得部は、前記リソース残量を送信するよう前記仮想マシン管理装置に要求し、前記仮想マシン管理装置が前記要求に応答して送信した前記リソース残量を受信する
付記１記載の制御装置。

（付記７）
前記サーバそれぞれは、複数のサーバ群のいずれかに属し、
前記削除された仮想マシンは、前記複数のサーバ群のうち、第１サーバ群に属するサーバ上で生成されることを許可されており、
前記取得部は、前記第１サーバ群に属するサーバのリソース残量を送信するよう前記仮想マシン管理装置に要求する
付記６記載の制御装置。

（付記８）
前記サーバ群は、ＡＺ（Availability Zone）である
付記７記載の制御装置。

（付記９）
さらに、前記仮想マシンと前記仮想マシンの生成が許可されるサーバ群との対応関係を記憶する記憶部を有する
付記７記載の制御装置。

（付記１０）
前記制御装置は、ＮＦＶＯ（Network Functions Virtualization Orchestrator）及びＶＮＦＭ（Virtualized Network Function Manager）を有し、
前記仮想マシン管理装置は、ＶＩＭ（Virtualized Infrastructure Manager）及びＮＦＶＩ（Network Functions Virtualization Infrastructure）を有する
付記１記載の制御装置。

（付記１１）
前記削除された仮想マシンは複数であって、
前記制御部は、前記複数の削除された仮想マシンのうち、前記リソース残量に応じた一部又は全部の仮想マシンを生成するよう指示する
付記１記載の制御装置。

（付記１２）
仮想マシンをサーバ上で生成し、前記仮想マシンが使用する前記サーバの有するリソースを管理する仮想マシン管理装置を、制御する制御装置における仮想マシン生成方法であって、
前記仮想マシン管理装置が生成した仮想マシンが削除されたことを検出し、
前記仮想マシンが削除されたことを検出したとき、前記削除された仮想マシン以外の他の仮想マシンが使用していないリソース残量を、前記仮想マシン管理装置から取得し、
前記リソース残量に応じて、前記削除された仮想マシンを生成するよう前記仮想マシン管理装置に指示する
仮想マシン生成方法。

１０…ＮＦＶシステム １００…ＮＦＶＩ
１０１…ＡＺ １０２…ＩＡＳ
２０…仮想マシン管理装置 ２００…ＶＩＭ
２１０…ＣＰＵ ２２０…ストレージ
２２１…リソース管理プログラム ２２２…リソース情報要求受信プログラム
２２３…リソース管理テーブル ２３０…メモリ
２４０…ＮＩＣ ３０…制御装置
３００…ＶＮＦＭ ３１０…ＣＰＵ
３２０…ストレージ ３２１…ヒーリング受信プログラム
３２２…ｆｌａｖｏｒ作成プログラム ３２５…ＶＭ要件テーブル
３３０…メモリ ３４０…ＮＩＣ
４００…ＮＦＶＯ ４１０…ＣＰＵ
４２０…ストレージ ４２１…故障検出プログラム
４２１１…ヒーリングモジュール ４２２…Ｇｒａｎｔ判定プログラム
４２２１…リソース情報取得モジュール ４２３…ＶＭ毎コア数テーブル
４２４…ｆｌａｖｏｒ管理テーブル ４３０…メモリ
４４０…ＮＩＣ

Claims (7)

1. 仮想マシンをサーバ上で生成し、前記仮想マシンが使用する前記サーバの有するリソースを管理する仮想マシン管理装置を、制御する制御装置であって、
   前記仮想マシン管理装置が生成した仮想マシンが削除されたことを検出する検出部と、
   前記仮想マシンが削除されたことを検出したとき、前記削除された仮想マシン以外の他の仮想マシンが使用していないリソース残量を、前記仮想マシン管理装置から取得する取得部と、
   前記リソース残量に応じて、前記削除された仮想マシンを生成するよう前記仮想マシン管理装置に指示する制御部を有する
   制御装置。
2. 前記リソースは、前記サーバが有するプロセッサのコア数であり、
   前記取得部は、前記サーバの残コア数を前記リソース残量として取得し、
   前記制御部は、前記残コア数に基づき、前記削除された仮想マシンを生成するサーバを選択し、前記選択したサーバで前記削除された仮想マシンを生成するよう前記仮想マシン管理装置に指示する
   請求項１記載の制御装置。
3. さらに、前記削除された仮想マシンが使用するコア数は、第１数値から第１数値以上の第２数値の範囲内の数であり、
   前記制御部は、前記残コア数が前記第２数値以上であるサーバを他のサーバよりも優先して選択する
   請求項２記載の制御装置。
4. 前記制御部は、前記残コア数が前記第２数値以上であるサーバが存在しない場合、前記コア数が前記第１数値以上かつ前記第２数値未満の第３数値であるサーバを選択し、前記第３数値のコア数を使用する前記削除された仮想マシンを生成するよう指示する
   請求項３記載の制御装置。
5. 前記取得部は、前記リソース残量を送信するよう前記仮想マシン管理装置に要求し、前記仮想マシン管理装置が前記要求に応答して送信した前記リソース残量を受信する
   請求項１記載の制御装置。
6. 前記サーバそれぞれは、複数のサーバ群のいずれかに属し、
   前記削除された仮想マシンは、前記複数のサーバ群のうち、第１サーバ群に属するサーバ上で生成されることを許可されており、
   前記取得部は、前記第１サーバ群に属するサーバのリソース残量を送信するよう前記仮想マシン管理装置に要求する
   請求項５記載の制御装置。
7. 仮想マシンをサーバ上で生成し、前記仮想マシンが使用する前記サーバの有するリソースを管理する仮想マシン管理装置を、制御する制御装置における仮想マシン生成方法であって、
   前記仮想マシン管理装置が生成した仮想マシンが削除されたことを検出し、
   前記仮想マシンが削除されたことを検出したとき、前記削除された仮想マシン以外の他の仮想マシンが使用していないリソース残量を、前記仮想マシン管理装置から取得し、
   前記リソース残量に応じて、前記削除された仮想マシンを生成するよう前記仮想マシン管理装置に指示する
   仮想マシン生成方法。

Images