(57)【要約】【課題】仮想リソース群のスタック管理を適切に行う。【解決手段】複数の仮想リソース群であるスタックを管理するスタック管理装置１０が、スタックの作成、変更および削除のいずれかの処理において、スタックの対象となるいずれかの仮想リソースの処理が失敗した場合、スタック全体または処理が失敗した仮想リソースの削除またはリトライを行い、ロールバックまたはロールフォワードを行う。また、スタック管理装置１０は、スタック操作部１５のみならず、スタック操作部１５以外の操作によりスタックに用いられる仮想リソースの更新および削除のいずれかが行われたとき、当該仮想リソースの状態変化を、前記スタックに用いられる仮想リソースの状態を示すスタック情報ＤＢ１１に反映させる。【選択図】図２
2015170344.tif 000002
【特許請求の範囲】
【請求項１】
複数の仮想リソースの集まりであるスタックを管理するスタック管理装置であって、
前記スタックの作成、削除および更新のいずれかの処理において、前記スタックを構成するいずれかの仮想リソースの処理が失敗した場合、前記スタック全体または前記処理が失敗した仮想リソースの削除またはリトライを行い、ロールバックまたはロールフォワードを行うスタック操作部
を備えることを特徴とするスタック管理装置。
【請求項２】
前記スタック操作部は、
前記スタックを作成する際に、仮想ボリューム、仮想レイヤ２ネットワーク、仮想マシン、仮想ルーター、仮想ロードバランサーの順で前記仮想リソースの作成を行い、いずれかの仮想リソースの作成が失敗した場合、作成した全ての仮想リソースの削除を行い、ロールバックを行うこと
を特徴とする請求項１に記載のスタック管理装置。
【請求項３】
前記スタック操作部は、さらに、
前記スタックを削除する際に、仮想ロードバランサー、仮想ルーター、仮想マシン、仮想レイヤ２ネットワーク、仮想ボリュームの順で前記仮想リソースの削除を行い、いずれかの仮想リソースの削除が失敗した場合、前記削除が失敗した仮想リソース以外の仮想リソースについて削除を行い、前記削除が失敗した仮想リソースに対して削除のリトライを行い、ロールフォワードを行うこと
を特徴とする請求項１または２に記載のスタック管理装置。
【請求項４】
前記スタック操作部は、さらに、
前記スタックの更新のため、前記仮想リソースを削除、作成および更新する際、
削除する仮想リソースに対して、仮想ロードバランサー、仮想ルーター、仮想マシン、仮想レイヤ２ネットワーク、仮想ボリュームの順で前記仮想リソースの削除を行い、
前記削除後、
作成する仮想リソースに対して、仮想ボリューム、仮想レイヤ２ネットワーク、仮想マシン、仮想ルーター、仮想ロードバランサーの順で前記仮想リソースの作成を行い、
前記作成後、
更新する仮想リソースに対して、仮想ボリューム、仮想レイヤ２ネットワーク、仮想マシン、仮想ルーター、仮想ロードバランサーの順で前記仮想リソースの更新を行い、
前記仮想リソースを削除、作成および更新する場合において、いずれかの仮想リソースの処理に失敗した場合、前記失敗した仮想リソースの処理の削除またはリトライを行い、ロールバックもしくはロールフォワードを行うこと
を特徴とする請求項１〜３のいずれか１項に記載のスタック管理装置。
【請求項５】
前記スタック管理装置は、さらに、
前記スタック操作部以外により、前記スタックに用いられる仮想リソースの更新および削除のいずれかが行われたとき、当該仮想リソースの状態変化を、前記スタック操作部が前記スタックの処理に用いるスタック情報に反映させる環境現況反映部を備えること
を特徴とする請求項１〜４のいずれか１項に記載のスタック管理装置。
【請求項６】
複数の仮想リソースの集まりであるスタックの作成、削除および更新のいずれかの処理を実行するステップと、
前記処理において、前記スタックを構成するいずれかの仮想リソースの処理が失敗した場合、前記スタック全体または前記処理が失敗した仮想リソースの削除またはリトライを行い、ロールバックまたはロールフォワードを行うステップと
を含んだことを特徴とするスタック管理方法。
【請求項７】
複数の仮想リソースの集まりであるスタックの作成、削除および更新のいずれかの処理を実行するステップと、
前記処理において、前記スタックを構成するいずれかの仮想リソースの処理が失敗した場合、前記スタック全体または前記処理が失敗した仮想リソースの削除またはリトライを行い、ロールバックまたはロールフォワードを行うステップと
をコンピュータに実行させることを特徴とするスタック管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想ネットワーク、仮想サーバ、仮想ストレージ等の仮想リソースを、ユーザに提供するIaaS(Infrastructure  as  a  Service）型クラウドサービスにおいて、スタックと呼ばれる仮想リソース群を一括して操作するスタック管理技術に関し、特に、スタック操作時のトランザクション管理、仮想リソース状態のスタック情報への反映に関する。
【背景技術】
【０００２】
従来、IaaS型クラウドサービスとして、例えば、Amazon  Elastic  Compute  Cloud（http://aws.amazon.com/ec2）、Rackspace  Cloud  Server（http://www.rackspacecloud.com/cloud-hosting-products/servers/）等がある。
【０００３】
IaaS型クラウドサービスの基盤として、Amazonはプロプライエタリなプラットフォームを用いているが、Rackspace  Cloud  ServerはオープンソースのOpenStack（http://www.openstack.org/）等を用いている。
【０００４】
また、クラウドサービスの普及に伴い、クラウド上の仮想リソース環境を容易に構築、増設、移設するため、仮想リソースの構成情報をテンプレート化して、一括してデプロイを行う技術が出てきており、例えば、Amazon  CloudFormation（非特許文献１参照）、OpenStack  Heat（非特許文献２参照）等が挙げられる。
【０００５】
上記技術において、テンプレートに基づいてデプロイされた仮想リソースのインスタンス群をスタックと呼び、OpenStack  Heat（以下、適宜Heatと略す）もAmazon  CloudFormation（以下、適宜CloudFormationと略す）も、それぞれスタックを操作するＡＰＩ（Application  Programming  Interface）を提供している。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】“Amazon  CloudFormation”、[online]、[平成26年2月6日検索]、インターネット<http://aws.amazon.com/cloudformation/>
【非特許文献２】“OpenStack  Heat”、[online]、[平成26年2月6日検索]、インターネット<https://wiki.openstack.org/wiki/Heat>
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、Heat等の既存のスタック管理技術にはいくつかの問題が有る。具体的には、スタック作成、削除、更新時のトランザクション管理が不十分である。例えば、テンプレートを展開する際は、全リソースが正常に作成されなくては期待通りの業務ができないが、一部リソースは正常終了したけれども、他は異常終了で止まった場合等の中途半端な状態で展開が終わることがある。また、スタックを新しいテンプレートで更新する際も、一部リソースの更新が失敗する等中途半端な状態になる場合がある。
【０００８】
また、スタック作成後の仮想マシンのダウン等の実環境の変更に対応ができない。例えば、仮想マシンがダウンした際や、OpenStackのNova  APIで直接仮想マシンが操作された際に、実環境とテンプレートに差分が出てしまう。このように差分が出た状況で、スタック更新が依頼されると、Heat等のスタック管理技術においては前回のテンプレートと更新用のテンプレートの差分を比較して、更新を行おうとするため、上記の例では、仮想マシンが実際は無いのに有るものとして差分チェックを行い、想定通りの挙動をしない可能性がある。
【０００９】
そこで、本発明は、前記した問題を解決し、仮想リソース群のスタック管理を適切に行うことを課題とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するために、本発明は、複数の仮想リソースの集まりであるスタックを管理するスタック管理装置であって、前記スタックの作成、削除および更新のいずれかの処理において、前記スタックを構成するいずれかの仮想リソースの処理が失敗した場合、前記スタック全体または前記処理が失敗した仮想リソースの削除またはリトライを行い、ロールバックまたはロールフォワードを行うスタック操作部を備えることを特徴とする。また、本発明は、さらに、前記スタック操作部以外により、前記スタックに用いられる仮想リソースの更新および削除のいずれかが行われたとき、当該仮想リソースの状態変化を、前記スタック操作部が前記スタックの処理に用いるスタック情報に反映させる環境現況反映部を備えることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、仮想リソース群のスタック管理を適切に行うができる。
【図面の簡単な説明】
【００１２】
【図１】図１は、本実施形態のシステムの構成例を示す図である。
【図２】図２は、図１の各構成要素を詳細に示した図である。
【図３】図３は、スタック作成、削除、更新の処理例を示す図である。
【図４】図４は、スタック操作の処理手順を示すシーケンス図である。
【図５】図５は、スタック操作以外のリソースコントローラへの操作依頼に伴う環境現況の反映の処理手順を示すシーケンス図である。
【図６】図６は、ユーザ端末の操作による仮想リソースの削除に伴う環境現況反映の処理手順を示すシーケンス図である。
【図７】図７は、物理機器の故障による仮想リソースの状態変化に伴う環境現況反映の処理手順を示すシーケンス図である。
【図８】図８は、スタック管理プログラムを実行するコンピュータを示す図である。
【図９】図９は、スタックの更新を説明するための図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照しながら、本発明を実施するための形態（実施形態）について説明する。なお、本実施形態により本発明が限定されるものではない。
【００１４】
図１に、本実施形態のシステムの構成例を示す。システムは、ユーザ端末１と、スタック管理装置１０と、スタック情報ＤＢ（データベース）１１と、リソースコントローラ２０と、物理機器３０と、監視装置４０とを備える。これらは、インターネット等のネットワーク（図示省略）を介して接続されている。
【００１５】
ユーザ端末１は、IaaS等のクラウド基盤における仮想リソースの作成やスタックの処理等の依頼を行う端末である。
【００１６】
スタック管理装置１０は、ユーザ端末１からのスタックの処理依頼とスタック情報ＤＢ１１の情報を用いて、スタックの作成や更新等の処理を行う。また、スタック管理装置１０は、ユーザ端末１からの処理依頼や監視装置４０からの監視通知に従い、仮想リソースの状態変化をスタック情報ＤＢ１１のスタック情報（スタックに関する情報およびスタック内の仮想リソースの状態の情報）に反映する。
【００１７】
スタック情報ＤＢ１１は、スタック情報を保持する。
【００１８】
リソースコントローラ２０は、当該リソースコントローラ２０のＡＰＩ経由でスタック管理装置１０からの仮想リソースの作成や削除等の依頼を受ける。リソースコントローラ２０は、例えば、OpenStack等が利用できる。
【００１９】
物理機器３０は、IaaS等のクラウド基盤を構成する様々な仮想リソースを提供する。仮想リソースは、例えば、仮想ボリューム、仮想Ｌ２ネットワーク、仮想マシン、仮想ルーター、仮想ロードバランサー等である。物理機器３０は、リソースコントローラ２０から仮想リソースの作成や削除依頼を受け、実際の仮想リソースを作成したり削除したりする。
【００２０】
監視装置４０は、物理機器３０に配置された仮想リソースや物理機器３０本体の監視を行い、仮想リソースや物理機器３０に故障が発生した際、その旨の監視通知をスタック管理装置１０に通知する。
【００２１】
（スタック管理装置）
図２は、図１の各構成要素を詳細に示した図である。まず、スタック管理装置１０を説明する。スタック管理装置１０は、外部とのインタフェースとして、スタック操作ＡＰＩ部１２と、他操作ＡＰＩ部１３と、コントローラ通信部１４とを持ち、内部にスタック操作部１５と、環境現況反映部１６とを持つ。
【００２２】
スタック操作ＡＰＩ部１２はスタック作成や更新等のＡＰＩ処理依頼をユーザ端末１から受けると、この依頼をスタック操作部１５に受け渡す。
【００２３】
他操作ＡＰＩ部１３は、スタック操作以外のリソースコントローラ２０のＡＰＩ処理依頼をユーザ端末１から受けると、この依頼を環境現況反映部１６に受け渡す。
【００２４】
コントローラ通信部１４は、リソースコントローラ２０との通信を行う。例えば、コントローラ通信部１４は、リソースコントローラＡＰＩ部２１の呼び出し（ＡＰＩ呼び出し）や、リソースコントローラＡＰＩ部２１からのＡＰＩ状態の取得（ＡＰＩ状態取得）を行う。具体的には、コントローラ通信部１４は、リソースコントローラ２０のリソースコントローラＡＰＩ部２１に対し、仮想マシン操作部２２（例えば、Nova）や、仮想ネットワーク操作部２３（例えば、Neutron）等の個別ＡＰＩを発行することで、リソースコントローラ２０に対し、処理完了の確認やロールバック依頼を行う。
【００２５】
なお、スタック管理装置１０は、リソースコントローラＤＢ２４とは別にスタック情報等をスタック情報ＤＢ１１に持つ。なお、このスタック情報ＤＢ１１は、図２に例示するようにスタック管理装置１０外に持っていてもよいし、スタック管理装置１０内に持っていてもよい。
【００２６】
スタック操作部１５は、スタック操作ＡＰＩ部１２から受け取った処理依頼の内容を示す情報に基づき、スタックの作成、削除、更新等のスタック操作を行う。具体的には、スタック操作部１５は、スタック操作ＡＰＩ部１２から受け取った処理依頼の内容を示す情報と、スタック情報ＤＢ１１の情報とから実際にリソースコントローラ２０のＡＰＩをコールする順序に分解し、個別リソースのＡＰＩ呼び出しをコントローラ通信部１４を介して行う。また、スタック操作部１５はスタック操作のトランザクション管理を行い、必要に応じて全体ロールバック等の判断を行い、コントローラ通信部１４を介して逆処理のＡＰＩ発行等を行う。なお、スタック操作が正常に進まない例としては、例えば、仮想マシンを作ろうとしたら物理機器３０の余剰リソースが足りないことが判明した場合や、仮想リソース作成中に予期せぬエラーが起きた場合等である。このスタック操作部１５の詳細は後記する。
【００２７】
環境現況反映部１６は、他操作ＡＰＩ部１３から受け取った依頼によるリソースコントローラ２０内の個別ＡＰＩ（例えば、仮想マシン操作部２２や、仮想ネットワーク操作部２３）の呼び出しのプロキシとして動作し、仮想リソースの状態変化の現況をスタック情報ＤＢ１１に反映する。また、環境現況反映部１６は、仮想マシンのダウン等があった場合、監視装置４０からの監視通知を受け、このダウン等をスタック情報ＤＢ１１に反映する。
【００２８】
（スタック情報ＤＢ）
スタック情報ＤＢ１１は、スタックに関する情報としてスタックＩＤやスタック作成状態（スタックが正常に作成されたか、ロールバックされたか等）、スタック内の仮想リソースが何かの情報等を持つ。また、スタック情報ＤＢ１１は、スタック内に含まれる仮想リソースとして、当該仮想リソースの仮想リソースＩＤ、所属スタックＩＤ、仮想リソースの状態（削除や使用可等）等を持つ。
【００２９】
前記したスタック操作部１５は、スタック情報ＤＢ１１における、スタックに関する情報とスタック内の仮想リソースの状態の情報と、スタック操作依頼とを元に、スタックの削除や更新等の処理を行う。
【００３０】
（リソースコントローラ）
リソースコントローラ２０は、スタック管理装置１０からの依頼に基づき、物理機器３０に対し仮想リソースの作成や削除等の制御を行う。リソースコントローラ２０は、リソースコントローラＡＰＩ部２１と、仮想マシン操作部２２と、仮想ネットワーク操作部２３と、リソースコントローラＤＢ２４とを備える。
【００３１】
リソースコントローラＡＰＩ部２１は、スタック管理装置１０からの依頼を受け付けると、仮想マシン操作部２２や仮想ネットワーク操作部２３等の個別ＡＰＩを呼び出す。そして、この個別ＡＰＩ経由で、各種処理を行う。
【００３２】
仮想マシン操作部２２は、リソースコントローラＡＰＩ部２１から受け渡された依頼に基づき、仮想マシンに対する各種制御を実行する。例えば、仮想マシン操作部２２は、当該仮想マシンを収容する物理機器３０内のＨＶ（HyperVisor）に対し、当該仮想マシンの作成、削除、更新等を指示する。
【００３３】
仮想ネットワーク操作部２３は、リソースコントローラＡＰＩ部２１から受け渡された依頼に基づき仮想ネットワークに対する各種制御を実行する。例えば、仮想ネットワーク操作部２３は、当該仮想ネットワークの仮想スイッチを収容する物理機器３０に対し、当該仮想スイッチの設定変更等を指示する。
【００３４】
なお、リソースコントローラ２０は上記の仮想マシン操作部２２や仮想ネットワーク操作部２３以外の個別ＡＰＩ、例えば、仮想ボリューム操作等のＡＰＩを備えていてもよい。
【００３５】
リソースコントローラＤＢ２４は、リソースコントローラ２０により制御される仮想リソースに関する各種情報を持つ。このリソースコントローラＤＢ２４の情報は、リソースコントローラ２０による制御に伴う仮想リソースの状態の情報を保持する。リソースコントローラＤＢ２４の情報は、この仮想リソースの状態の情報の他に、例えば、仮想リソースの構成に関する情報を保持する。
【００３６】
リソースコントローラ２０が物理機器３０に対し、仮想リソースの作成等の制御を行うことで、例えば、複数の仮想マシン（ＶＭ）が、ファイアウォール（ＦＷ）経由で、インターネットやＶＰＮ（Virtual  Private  Network）により接続され、符号２０１に示すようなシステムが構成される。
【００３７】
このようなスタック管理装置１０によれば、スタック作成、削除、更新にて、トランザクション管理を行うので、一部仮想リソースは作られているが、一部仮想リソースは未作成等、スタック全体の処理が中途半端な状態になることを避けることができる。
【００３８】
（スタック操作部の詳細）
テンプレートを用いて仮想リソースの環境を構築する目的としては、既に行っている事業の拡大のためサーバ環境を複製する場合等が考えられる。このような場合において、例えば、仮想マシンが作成できても、仮想ルーターのセキュリティ設定が不十分である等、中途半端な状態になると、セキュリティ設定なしに仮想マシンへのアクセスを許してしまい、事業利用できないことになる。
【００３９】
そのため、スタック管理装置１０のスタック操作部１５は、スタック作成時は全てのリソースの作成完了まで行い、もし一部の仮想リソースの作成に失敗すれば全てのリソースを削除して、スタック作成の開始前に戻す（全ロールバックを行う）。
【００４０】
同様に、スタック削除時は、スタック管理装置１０は、全ての仮想リソースを削除することが目的のため、途中で削除失敗があっても、その他の仮想リソースの削除は行い、失敗した仮想リソースに対しても削除リトライをして全てのリソースを削除する（全ロールフォワードを行う）。
【００４１】
一方、スタック更新の場合は、スタック管理装置１０は、現状のスタックのテンプレートと更新するテンプレートの差分を取り、差分がある仮想リソースに対して作成、削除、更新を行う。具体的には、スタック管理装置１０は、更新元のテンプレートに有り更新先のテンプレートに無い仮想リソースは削除、更新元のテンプレートに無く更新先のテンプレートにある仮想リソースは作成、更新元のテンプレートと更新先のテンプレートでリソース設定に変更がある場合は更新もしくは、削除後新規作成を行う。
【００４２】
例えば、OpenStackではネットワークの接続変更の更新処理ができるが、仮想マシンのメモリサイズの変更は一度削除してから新規作成しないとできない等の制限がある。したがって、リソースコントローラ２０としてOpenStackを用いる場合においてテンプレートの更新があるとき、スタック管理装置１０は、変更対象となる仮想リソースのうち、ネットワークの接続に関しては更新処理を行い、仮想マシンのメモリサイズについては、一度削除してから新規作成する。
【００４３】
なお、差分リソースの操作に関するリソースコントローラ２０の処理は個々のＡＰＩ毎に行われる。このため、例えば、仮想ボリュームの削除後にその後で行われる仮想マシン作成に失敗したとして、ロールバックで仮想ボリュームを復旧することは不可能である。そこで、スタック管理装置１０は、スタック更新について、テンプレート差分にある個々のＡＰＩ処理について失敗した際は、ロールバックもしくはロールフォワードをして、個々の仮想リソースについて状態を確定させるようにする（個別ロールバック／ロールフォワードを行う）。
【００４４】
なお、従来技術であるHeatやCloudFormationで用いられるテンプレートには、どの仮想リソースの処理から行うかの記載はない。そこで、スタック管理装置１０のスタック操作部１５がスタック作成、削除、更新処理を行う際は、どの仮想リソースの処理から行うかを決めておく。例えば、スタック操作部１５は、スタック作成、削除、更新処理を行う際、以下の順で処理を行う。
【００４５】
例えば、スタック操作部１５は、図３の(ａ)のスタック作成フローに示すようにスタック作成については、仮想ボリューム作成、仮想Ｌ２ネットワーク作成、仮想マシン作成、仮想ルーター作成、仮想ロードバランサー作成の順で処理を行う。
【００４６】
また、スタック削除の場合は、図３の（ｂ）のスタック削除フローに示すように、(ａ)に示した順と逆の順、すなわち、仮想ロードバランサー削除、仮想ルーター削除、仮想マシン削除、仮想Ｌ２ネットワーク削除、仮想ボリューム削除の順で処理を行う。
【００４７】
また、スタック操作部１５は、スタック更新については、図３の（ｃ）のスタック更新フローに示すように、まず削除する仮想リソースの削除処理を（ｂ）のスタック削除フローと同様の順で行い、作成する仮想リソースの作成処理を（ａ）のスタック作成フローと同様の順で行い、最後に仮想リソースの更新処理を（ａ）のスタック作成フローと同様の順で行う。
【００４８】
このようにすることで、スタック操作部１５において、スタック作成で必要とする仮想リソースが無く仮想リソースを作れない等、事前条件を満たさないエラーを防ぐことが出来る。この事前条件とは、例えば、仮想マシン作成には仮想ボリュームが必要等の条件である。また、スタック更新では、スタック操作部１５が、先に仮想リソースの登録を行ってしまい名前の重複が発生する等、事前条件を満たさないエラーを防ぐことができる。ここでの事前条件とは、例えば、異なる仮想リソース間で同じＩＰ（Internet  Protocol）アドレスを使わない等の条件である。例えば、スタック更新において、新たな仮想マシンを登録後、古い仮想マシンを削除すると、仮想マシンの名前が重複する可能性が出てくるが、削除→登録の順で行えば仮想マシンの名前が重複することはない。
【００４９】
ここで、引き続き図３を用いて、図３に示すスタック作成、削除、更新の処理において、失敗が有った際のスタック操作部１５の処理について説明する。
【００５０】
スタック操作部１５は、図３の(ａ)のスタック作成フローに示すように、スタック作成は、仮想ボリューム作成、仮想Ｌ２ネットワーク作成、仮想マシン作成、仮想ルーター作成、仮想ロードバランサー作成の順番で行い、もしいずれかの仮想リソースの作成に失敗が生じたら全ての処理をロールバックして、削除する。
【００５１】
また、スタック操作部１５は、図３の（ｂ）のスタック削除フローに示すように、スタック削除は、（ａ）のスタック作成フローの逆の順番で行い、失敗が有った際はリトライする等して全てを削除するようロールフォワードを行う。
【００５２】
さらに、スタック操作部１５は、図３の（ｃ）スタック更新フローに示すように、スタック更新の場合は、まず削除する仮想リソースの削除処理を（ｂ）のスタック削除フローと同様の順番で行い、作成する仮想リソースの作成処理を（ａ）のスタック作成と同様の順番で行い、最後に仮想リソースの更新処理を（ａ）のスタック作成と同様の順番で行い、失敗が起きた場合は個別の仮想リソースに対してロールバック、ロールフォワードを行う。
【００５３】
このように、スタック操作部１５は、リソースコントローラ２０のＡＰＩのコール順序の順序管理とトランザクション管理を行う。トランザクション管理では、リソースコントローラ２０のＡＰＩコールは非同期処理もあるが、ＡＰＩのトランザクションが失敗した場合に、削除するＡＰＩを発行したり、逆処理のＡＰＩを発行したり（作成処理ならば削除処理が逆処理）、リトライを繰り返す等して、異常時のリソースコントローラ２０側の状態をロールバック、ロールフォワードするようにする。このようにすることで、スタック操作部１５は、スタック作成、削除、更新時の中途半端な状態を防ぐことができる。
【００５４】
（現況環境反映部の詳細）
なお、Heat等の従来技術におけるテンプレート処理機能では、テンプレート処理ＡＰＩ以外での環境更新については認識ができない。よって、スタック更新の際に比較対象となるテンプレートは、単純に前回のスタック作成や更新に用いられたテンプレートとなる。そのため、例えば、最初のスタック作成で仮想マシンを一つ作成したが、テンプレート処理機能以外のＡＰＩで仮想マシンを削除した場合に以下の問題が生じる。すなわち、テンプレート処理機能において、当該スタックに更新を行うとき、当該スタックに仮想マシンはあるものとして処理するので、結果的に仮想マシンは削除されたままとなってしまうという問題が生じる。
【００５５】
具体例を挙げる。例えば、図９に示すように、ＶＭ（仮想マシン）−Ｌ２（仮想Ｌ２ネットワーク）−Ｒ（仮想ルーター）という接続のスタックを考える。このスタックにおいて、Ｒの下にＬ２を追加すると、更新されたスタックはＶＭ−Ｌ２−Ｒ−Ｌ２になる。ここでＬ２の追加の直前にＡＰＩや、ユーザ端末１等のＳＳＨ（Secure  Shell)やＶＮＣ（Virtual  Network  Computing）等経由でスタックに含まれるＶＭが削除されていた場合、実際にはＬ２−Ｒという構成になっているが、テンプレート機能は、Ｒの下にＬ２を追加すればよいと判断して処理をするので、更新されたスタックはＬ２−Ｒ−Ｌ２になってしまうという問題がある。
【００５６】
そこで、環境現況反映部１６は、環境現況の更新をスタック情報ＤＢ１１に反映することで、スタック操作部１５によるスタック更新や削除を適切に行えるようにする。
【００５７】
なお、スタック情報ＤＢ１１の更新が必要になる場面としては、以下の場面が考えられる。
【００５８】
（１）スタック操作部１５が仮想リソースの作成、更新、削除を行う場合
（２）リソースコントローラ２０の個別ＡＰＩによる仮想リソースの削除、更新
（３）ユーザ端末１等、リソースコントローラ２０以外の操作による仮想リソースの削除（例えば、仮想マシンの削除）
（４）物理機器３０の故障による仮想リソースの削除
【００５９】
（１）については、スタック操作部１５で用いるテンプレートがスタック情報ＤＢ１１の情報と合っているため、特に処理は必要ない。
【００６０】
（２）については、スタック操作部１５とは独立してリソースコントローラ２０の個別ＡＰＩ（仮想マシン操作部２２や仮想ネットワーク操作部２３）がコールされる際に、環境現況反映部１６が、個別ＡＰＩの依頼をプロキシとしてフックして把握することで、個別ＡＰＩによる環境現況更新をスタック情報ＤＢ１１に反映する。
【００６１】
例えば、他操作ＡＰＩ部１３経由で、仮想マシンや仮想ネットワークの操作が依頼され、コントローラ通信部１４経由でリソースコントローラ２０の個別ＡＰＩ（仮想マシン操作部２２や仮想ネットワーク操作部２３）がコールされた場合を考える。この場合、環境現況反映部１６は、コントローラ通信部１４経由でリソースコントローラ２０のＡＰＩ状態を取得し、このＡＰＩ状態から判断される環境現況更新をスタック情報ＤＢ１１に反映する。
【００６２】
なお、このスタック情報ＤＢ１１への環境現況更新の反映は、環境現況反映部１６が所定期間ごとにリソースコントローラＤＢ２４の情報をポーリング確認することで行ってもよい。なお、前記したNova等の、従来技術による個別ＡＰＩでの仮想リソースの作成については、スタックに追加することはできない。つまり、従来技術では、個別ＡＰＩでの仮想リソースの作成については、スタックとは別に行われる。このため、環境現況反映部１６は、個別ＡＰＩによる仮想リソースの作成に関しては、スタック情報ＤＢ１１に反映しない。
【００６３】
（３）については、ユーザ端末１等のＳＳＨやＶＮＣ等経由での仮想マシンの削除がメインの想定であるが、仮想マシンの制御は、例えば、ＫＶＭ（Kernel-based  Virtual  Machine）であればlibvirt等により行われる。よって、例えば、環境現況反映部１６が削除対象の仮想マシンを収容する物理機器３０内のlibvirt等により、当該仮想マシンが削除された旨の通知を受信すると、その通知に示される内容をスタック情報ＤＢ１１に反映する。
【００６４】
（４）については、例えば、図１の監視装置４０による物理機器３０への監視により、仮想リソースの削除等を検知したとき、環境現況反映部１６が、その旨の監視通知を受信し、その監視通知に示される内容をスタック情報ＤＢ１１に反映する。
【００６５】
このように、環境現況反映部１６が環境現況更新をスタック情報ＤＢ１１に反映することで、スタック管理装置１０にスタック更新や削除依頼が来た際に、現在のスタック情報ＤＢ１１に基づいてスタック更新や削除処理を行うことができる。
【００６６】
図４〜図６にシステムの処理手順を示す。図４は、スタック操作の処理手順を示すシーケンス図である。
【００６７】
ユーザ端末１は、スタック操作依頼をスタック管理装置１０に送信する（Ｓ１）。その後、スタック管理装置１０のスタック操作ＡＰＩ部１２は当該依頼をスタック操作部１５に受け渡し、スタック操作部１５は、当該依頼がスタックの削除または更新であるとき、スタック情報ＤＢ１１へ当該スタックの現況情報の取得依頼を送信する（Ｓ２）。そして、スタック管理装置１０のスタック操作部１５は、スタック情報ＤＢ１１からスタックの現況情報を取得する（Ｓ３）。なお、当該依頼がスタック作成の場合、スタック操作部１５は、現況情報を取得しない。
【００６８】
その後、スタック管理装置１０のスタック操作部１５はスタック情報ＤＢ１１から取得したスタックの現況情報と当該依頼の情報から、リソースコントローラ２０を操作するためのＡＰＩの順序を組み立て（Ｓ４：リソースコントローラ操作ＡＰＩ順序の組み立て）、また当該ＡＰＩのパラメータを準備する（Ｓ５）。
【００６９】
ここで、スタック操作は複数の仮想リソースの操作を伴うため、仮想リソースの操作の分だけ、スタック管理装置１０のスタック操作部１５はコントローラ通信部１４経由でリソースコントローラ２０に仮想リソースの操作依頼を送信する（Ｓ６）。そして、リソースコントローラ２０は当該操作依頼に基づき、各物理機器３０に仮想リソースの操作依頼を行い（Ｓ７）、物理機器３０は当該操作依頼に基づき仮想リソースの操作を行う（Ｓ８）。その後、物理機器３０は仮想リソースの操作を完了させると、仮想リソースの操作が完了した旨の通知を、リソースコントローラ２０経由でスタック管理装置１０へ送信する（Ｓ９、Ｓ１０）。
【００７０】
このＳ６〜Ｓ１０の処理において、スタック管理装置１０のスタック操作部１５は、スタック操作分、個別の仮想リソース処理を実施する。そして、個別処理に対してトランザクション管理をしており、スタック作成時の処理失敗は全ロールバック、スタック削除時の処理失敗は全ロールフォワード、スタック更新時の処理失敗は個別ロールバック、ロールフォワードを実施する。
【００７１】
Ｓ１０の後、スタック管理装置１０のスタック操作部１５は、全ての仮想リソース操作が完了したことを確認すると、スタック操作ＡＰＩ部１２経由でスタック操作が完了した旨をユーザ端末１へ送信する（Ｓ１１）。
【００７２】
このようにすることで、スタック管理装置１０は、スタックの作成、削除、更新を適切に行うことができる。
【００７３】
図５は、スタック操作以外のリソースコントローラへの操作依頼に伴う環境現況の反映の処理手順を示すシーケンス図である。スタック操作以外とは、例えば、リソースコントローラ２０の仮想マシン操作部２２や仮想ネットワーク操作部２３等へのスタック操作部１５を介さないＡＰＩ操作であり、OpenStackでいえばNovaやNeutron等のＡＰＩ操作である。
【００７４】
ユーザ端末１は仮想リソースの操作依頼をスタック管理装置１０に送る（Ｓ２１）。その後、スタック管理装置１０の他操作ＡＰＩ部１３はこの仮想リソースの操作依頼を環境現況反映部１６およびコントローラ通信部１４経由でリソースコントローラ２０に転送する（Ｓ２２）。そして、リソースコントローラ２０は、この仮想リソースの操作依頼に基づき、各物理機器３０に仮想リソースの操作依頼を行う（Ｓ２３）。つまり、リソースコントローラ２０は、リソースコントローラＡＰＩ部２１経由で仮想リソースの操作依頼を受け取ると、この仮想リソースの操作依頼の内容に応じて個別ＡＰＩ（例えば、仮想マシン操作部２２または仮想ネットワーク操作部２３）を呼び出し、物理機器３０へ仮想リソースの操作依頼を行わせる。
【００７５】
この後のＳ２４〜Ｓ２６の処理は、図４のＳ８〜Ｓ１０の処理と同様なので説明を省略する。なお、Ｓ２４により操作された仮想リソースが、スタックに含まれている仮想リソースである場合は、スタック内の仮想リソースの状態が変化するため、スタック管理装置１０の環境現況反映部１６はスタック情報ＤＢ１１のスタック情報を更新する（Ｓ２７）。つまり、スタック管理装置１０の環境現況反映部１６は、コントローラ通信部１４経由でリソースコントローラ２０のＡＰＩ状態として仮想リソースの操作が完了した旨の通知を受信すると、この通知をもとにスタック情報ＤＢ１１のスタック情報を更新する。その後、環境現況反映部１６は、仮想リソース操作完了を、他操作ＡＰＩ部１３経由でユーザ端末１へ送信する（Ｓ２８）。
【００７６】
このようにすることで、スタック管理装置１０は、リソースコントローラ２０の個別ＡＰＩによる仮想リソースの状態の変化をスタック情報ＤＢ１１へ反映させることができる。
【００７７】
図６は、ユーザ端末の操作による仮想リソースの削除に伴う環境現況反映の処理手順を示すシーケンス図である。
【００７８】
例えば、ユーザ端末１等のＳＳＨやＶＮＣ等経由での物理機器３０へ仮想リソースの削除依頼が送信されると（Ｓ３１）、これに基づき物理機器３０における当該仮想リソースを削除する（Ｓ３２）。そして、当該物理機器３０はlibvirt等の仮想リソース管理機能により、当該仮想リソースが削除されたことをスタック管理装置１０へ通知する（Ｓ３３）。そして、このような通知を受けたスタック管理装置１０は、環境現況反映部１６により、スタック情報ＤＢ１１の情報を更新する（Ｓ３４）。例えば、環境現況反映部１６は、当該仮想リソースの削除をスタック情報ＤＢ１１に反映させる。
【００７９】
このようにすることで、スタック管理装置１０はユーザ端末１の操作による仮想リソースの削除をスタック情報ＤＢ１１に反映させることができる。
【００８０】
図７は、物理機器の故障による仮想リソースの状態変化に伴う環境現況反映の処理手順を示すシーケンス図である。
【００８１】
監視装置４０は物理機器３０上の仮想リソースや物理機器３０自体を監視し（Ｓ４１，Ｓ４３）、物理機器３０から状態を受け取る。例えば、監視装置４０は、物理機器３０上の仮想リソースに特に異常がなければその旨の応答を物理機器３０から受け取る（Ｓ４２：仮想リソースＯＫ）。一方、監視装置４０が物理機器３０から、応答を受け取らなかった場合、監視装置４０は、物理機器３０に故障が生じたと判断し、スタック管理装置１０に当該物理機器３０上の仮想リソースの故障通知を送る（Ｓ４４）。その後、当該仮想リソースがスタックに含まれている場合は、スタック管理装置１０は、環境現況反映部１６により、スタック情報ＤＢ１１の情報を更新する（Ｓ４５）。例えば、環境現況反映部１６は、当該仮想リソースの削除をスタック情報ＤＢ１１に反映させる。
【００８２】
このようにすることで、スタック管理装置１０は物理機器３０の故障による仮想リソースの削除をスタック情報ＤＢ１１に反映させることができる。
【００８３】
つまり、スタック管理装置１０は、
（２）リソースコントローラ２０の個別ＡＰＩによる仮想リソースの、削除、更新
（３）ユーザ端末１等、リソースコントローラ２０以外の操作による仮想リソースの削除（例えば、仮想マシンの削除）
（４）物理機器３０の故障による仮想リソースの削除
により仮想リソースの状態が変化した場合でも、この状態の変化をスタック情報ＤＢ１１に反映させる。その結果、スタック管理装置１０は、正しいスタック情報をもとにスタックの更新、削除を行うので、スタックの更新、削除を適切に行うことができる。
【００８４】
（効果）
前記した実施形態のシステムによる効果を以下にまとめる。スタック管理装置１０は、スタック作成時に、事前条件を満たした形で仮想リソースの作成を行い、ある仮想リソースが作成失敗した場合は、全ての仮想リソースを削除してロールバックすることで、中途半端な状態でスタック作成が終わることがなく、適切なスタック作成が保証される。
【００８５】
また、スタック管理装置１０は、スタック削除時に、事前条件を満たした形で仮想リソースの削除を行い、ある仮想リソースが削除失敗した場合も、他の仮想リソースの削除と、失敗した仮想リソースの削除リトライ等により、全ての仮想リソースを削除してロールフォワードすることで、中途半端な状態でスタック削除が終わることがなく、また、スタック削除でゴミが残らずに適切にスタックを削除することが保証される。
【００８６】
また、スタック管理装置１０は、スタック更新時に、事前条件を満たした形で仮想リソースの作成、削除、更新を行い、ある仮想リソースが処理失敗した場合は、その仮想リソースに対してロールバックもしくはロールフォワードすることで、中途半端な状態でスタック更新が終わることがなく、適切なスタック更新が保証される。
【００８７】
また、スタック管理装置１０は、スタック作成後に、スタック内仮想リソースの状態が、スタック操作以外の処理依頼をされた場合でも、その処理依頼による仮想リソースの状態変化をスタック情報ＤＢ１１内のスタック内の仮想リソース情報に反映することで、スタック更新や削除時に想定通りの動作をすることが保証される。
【００８８】
また、スタック管理装置１０は、スタック作成後に、スタック内仮想リソースの状態が、ユーザ端末１等のコンソール経由での削除や、物理機器３０の故障による削除された場合でも、仮想リソースの状態変化をスタック情報ＤＢ１１内のスタック内の仮想リソース情報に反映することで、スタック更新や削除時に想定通りの動作をすることが保証される。
【００８９】
（プログラム）
また、上記実施形態に係るスタック管理装置１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、スタック管理装置１０と同様の機能を実現するスタック管理プログラムを実行するコンピュータの一例を説明する。
【００９０】
図８は、スタック管理プログラムを実行するコンピュータを示す図である。図８に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。
【００９１】
メモリ１０１０は、ＲＯＭ（Read  Only  Memory）１０１１およびＲＡＭ（Random  Access  Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic  Input  Output  System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。
【００９２】
ここで、図８に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。
【００９３】
また、スタック管理プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、ハードディスクドライブ１０９０に記憶される。具体的には、上記実施形態で説明したスタック管理装置１０が実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。
【００９４】
また、スタック管理プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。
【００９５】
なお、スタック管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、スタック管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local  Area  Network）やＷＡＮ（Wide  Area  Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【符号の説明】
【００９６】
１      ユーザ端末
１０    スタック管理装置
１１    スタック情報ＤＢ
１２    スタック操作ＡＰＩ部
１３    他操作ＡＰＩ部
１４    コントローラ通信部
１５    スタック操作部
１６    環境現況反映部
２０    リソースコントローラ
２１    リソースコントローラＡＰＩ部
２２    仮想マシン操作部
２３    仮想ネットワーク操作部
２４    リソースコントローラＤＢ
３０    物理機器
４０    監視装置
【図１】
2015170344.tif 000003
【図２】
2015170344.tif 000004
【図３】
2015170344.tif 000005
【図４】
2015170344.tif 000006
【図５】
2015170344.tif 000007
【図６】
2015170344.tif 000008
【図７】
2015170344.tif 000009
【図８】
2015170344.tif 000010
【図９】
2015170344.tif 000011
【手続補正書】
【提出日】平成27年6月24日(2015.6.24)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数の仮想リソースの集まりであるスタックを管理するスタック管理装置であって、
前記スタックの作成、削除および更新のいずれかの処理において、前記スタックを構成するいずれかの仮想リソースの処理が失敗した場合、前記スタック全体または前記処理が失敗した仮想リソースの削除またはリトライを行い、ロールバックまたはロールフォワードを行うスタック操作部は、前記スタックを作成する際に、仮想ボリューム、仮想レイヤ２ネットワーク、仮想マシン、仮想ルーター、仮想ロードバランサーの順で前記仮想リソースの作成を行い、いずれかの仮想リソースの作成が失敗した場合、作成した全ての仮想リソースの削除を行い、ロールバックを行うこと
を特徴とするスタック管理装置。
【請求項２】
前記スタック操作部は、さらに、
前記スタックを削除する際に、仮想ロードバランサー、仮想ルーター、仮想マシン、仮想レイヤ２ネットワーク、仮想ボリュームの順で前記仮想リソースの削除を行い、いずれかの仮想リソースの削除が失敗した場合、前記削除が失敗した仮想リソース以外の仮想リソースについて削除を行い、前記削除が失敗した仮想リソースに対して削除のリトライを行い、ロールフォワードを行うこと
を特徴とする請求項１に記載のスタック管理装置。
【請求項３】
前記スタック操作部は、さらに、
前記スタックの更新のため、前記仮想リソースを削除、作成および更新する際、
削除する仮想リソースに対して、仮想ロードバランサー、仮想ルーター、仮想マシン、仮想レイヤ２ネットワーク、仮想ボリュームの順で前記仮想リソースの削除を行い、
前記削除後、
作成する仮想リソースに対して、仮想ボリューム、仮想レイヤ２ネットワーク、仮想マシン、仮想ルーター、仮想ロードバランサーの順で前記仮想リソースの作成を行い、
前記作成後、
更新する仮想リソースに対して、仮想ボリューム、仮想レイヤ２ネットワーク、仮想マシン、仮想ルーター、仮想ロードバランサーの順で前記仮想リソースの更新を行い、
前記仮想リソースを削除、作成および更新する場合において、いずれかの仮想リソースの処理に失敗した場合、前記失敗した仮想リソースの処理の削除またはリトライを行い、ロールバックもしくはロールフォワードを行うこと
を特徴とする請求項１または２に記載のスタック管理装置。
【請求項４】
前記スタック管理装置は、さらに、
前記スタック操作部以外により、前記スタックに用いられる仮想リソースの更新および削除のいずれかが行われたとき、当該仮想リソースの状態変化を、前記スタック操作部が前記スタックの処理に用いるスタック情報に反映させる環境現況反映部を備えること
を特徴とする請求項１〜３のいずれか１項に記載のスタック管理装置。
【請求項５】
複数の仮想リソースの集まりであるスタックの作成、削除および更新のいずれかの処理を実行するステップと、
前記処理において、前記スタックを構成するいずれかの仮想リソースの処理が失敗した場合、前記スタック全体または前記処理が失敗した仮想リソースの削除またはリトライを行い、ロールバックまたはロールフォワードを行うステップとを含み、
前記スタックを作成する際に、仮想ボリューム、仮想レイヤ２ネットワーク、仮想マシン、仮想ルーター、仮想ロードバランサーの順で前記仮想リソースの作成を行い、いずれかの仮想リソースの作成が失敗した場合、作成した全ての仮想リソースの削除を行い、ロールバックを行うこと
を特徴とするスタック管理方法。
【請求項６】
複数の仮想リソースの集まりであるスタックの作成、削除および更新のいずれかの処理を実行するステップと、
前記処理において、前記スタックを構成するいずれかの仮想リソースの処理が失敗した場合、前記スタック全体または前記処理が失敗した仮想リソースの削除またはリトライを行い、ロールバックまたはロールフォワードを行うステップと、
前記スタックを作成する際に、仮想ボリューム、仮想レイヤ２ネットワーク、仮想マシン、仮想ルーター、仮想ロードバランサーの順で前記仮想リソースの作成を行い、いずれかの仮想リソースの作成が失敗した場合、作成した全ての仮想リソースの削除を行い、ロールバックを行う処理
をコンピュータに実行させることを特徴とするスタック管理プログラム。