JP2022007301A - 復旧制御装置及び復旧制御方法 - Google Patents

Abstract

【課題】仮想マシンの障害発生時に、復旧の判断に複数種別の装置における情報が必要となる場合でも、自動で復旧判断を行う復旧制御装置及び復旧制御方法を提供する。【解決手段】仮想マシンシステムで動作する復旧制御装置は、仮想マシンシステムで稼働する仮想マシンにおいてアラームが発生した場合にＳ１１、当該アラームの内容を示す情報又は仮想マシンシステムを構成する複数種別の構成装置における所定の情報を収集しＳ１２、Ｓ１５、Ｓ１８、Ｓ２１、収集した情報を用いて仮想マシンの復旧要否を判断するＳ１３、Ｓ１６、Ｓ１９、Ｓ２２。【選択図】図４

Description

本発明は、復旧制御装置及び復旧制御方法に関し、障害発生時に仮想マシンの復旧要否を判断する復旧制御装置及び復旧制御方法に適用して好適なものである。

近年、ＩＴシステムの運用効率化と余剰な物理リソースの削減を目的に、様々な分野でシステムの仮想化が行われている。しかし、仮想化されたマシン（仮想マシン）を備えて構成される仮想マシンシステムでは、仮想マシン上で障害が発生した際に、障害の原因が仮想マシンのＯＳにあるのか、仮想基盤を提供しているミドルウェア、ハードウェアにあるのかを即座に切り分けることが難しいという問題があった。このため、切り分けや原因調査をするために時間が掛かり、その間はシステムを正常に稼働できない場合があった。

ここで例えば、特許文献１には、仮想マシンの自動復旧を制御する復旧制御アルゴリズムを有する復旧制御装置が開示されている。特許文献１に開示された復旧制御装置は、障害の発生原因及び発生装置を特定してアプリケーションによるユーザ端末に対するサービス提供を継続するよう障害発生装置を復旧制御する復旧制御部と、復旧制御部による復旧制御処理のトリガ及びその復旧処理内容を関連づけて復旧制御履歴として記憶する復旧制御履歴記憶部とを備え、復旧制御部は、復旧制御履歴記憶部に記憶された復旧制御履歴に基づき復旧制御アルゴリズムを構成して障害発生装置の復旧制御を行う。

特開２０１８－０２５９６８号公報

しかし、特許文献１に記載された復旧制御装置は、仮想マシンで障害が発生した際、仮想マシンシステムを構成する複数種別の装置における情報が復旧判断の判断基準となる場合に、対応ができないという課題があった。

本発明は以上の点を考慮してなされたもので、仮想マシンの障害発生時に、復旧の判断に複数種別の装置における情報が必要となる場合でも、自動で復旧判断を行うことが可能な復旧制御装置及び復旧制御方法を提案しようとするものである。

かかる課題を解決するため本発明においては、仮想マシンシステムで動作する復旧制御装置であって、前記仮想マシンシステムで稼働する仮想マシンにおいてアラームが発生した場合に、当該アラームの内容を示す情報、または前記仮想マシンシステムを構成する複数種別の構成装置における所定の情報を収集し、前記収集した情報を用いて前記仮想マシンの復旧要否を判断する復旧制御装置が提供される。

また、かかる課題を解決するため本発明においては、仮想マシンシステムで動作する復旧制御装置による復旧制御方法であって、前記仮想マシンシステムで稼働する仮想マシンにおいてアラームが発生した場合に、当該アラームの内容を示す情報、または前記仮想マシンシステムを構成する複数種別の構成装置における所定の情報を収集し、前記収集した情報を用いて前記仮想マシンの復旧要否を判断する復旧制御方法が提供される。

本発明によれば、仮想マシンの障害発生時に、復旧の判断に複数種別の装置における情報が必要となる場合でも、自動で復旧判断を行うことができる。

本発明の一実施形態に係る復旧制御装置１０が動作する仮想マシンシステム１の概略構成例を説明するブロック図である。 本番環境２におけるシステム構成例を示すブロック図である。 復旧制御装置１０の構成例を示す図である。 仮想マシン２０の障害発生時に復旧要否を判断する処理の処理手順例を示すフローチャートである。 復旧要件情報１００の一例を示す図である。

以下、図面を参照して、本発明の一実施形態を詳述する。

図１は、本発明の一実施形態に係る復旧制御装置１０が動作する仮想マシンシステム１の概略構成例を説明するブロック図である。図１に示すように、仮想マシンシステム１は、本番環境２（実稼働環境）で稼働する仮想マシン２０と、バックアップ環境３に格納されるバックアップデータ３０と、仮想マシン２０及びバックアップデータ３０にアクセス可能な復旧制御装置１０と、を備えて構成される。本実施形態に係る復旧制御装置１０による復旧制御の対象となるシステムは、本番環境２である。

バックアップデータ３０は仮想マシン２０のバックアップ用のデータであって、仮想マシン２０はバックアップ取得の頻度に基づいて定期的に、バックアップデータ３０を取得してバックアップ環境３に保管する。仮想マシン２０で障害が発生した場合、復旧制御装置１０は、障害からの復旧要否及び復旧方法を判断し、復旧が必要と判断した場合には、判断した復旧方法に従ってバックアップデータ３０（厳密にはそのコピーデータ）を用いて仮想マシン２０の復旧処理を制御する。

図２は、本番環境２におけるシステム構成例を示すブロック図である。図２に示すように、本番環境２には、サーバ装置２１、ネットワーク装置２２、ストレージ装置２３、監視サーバ２４、及び仮想マネージャ２５が備えられる。

サーバ装置２１は、汎用の物理サーバ上にハイパーバイザ２８を導入して構成され、ハイパーバイザ２８上で仮想マシン２０が稼働する。

ネットワーク装置２２は、サーバ装置２１、ストレージ装置２３、監視サーバ２４、及び仮想マネージャ２５との通信経路を形成する機器である。ネットワーク装置２２が形成する通信経路上には、各装置に接続するための接続ポート（不図示）と、ネットワーク装置２２自身をメンテナンスするためのメンテナンスポートとが存在し、メンテナンスポートは監視サーバ２４に到達性を有する。

ストレージ装置２３は、サーバ装置２１上で稼働する仮想マシン２０のデータを格納する記憶装置である。図２では図示を省略しているが、ストレージ装置２３とサーバ装置２１は物理的に接続されているとする。

監視サーバ２４は、仮想マシン２０、サーバ装置２１、ネットワーク装置２２、及びストレージ装置２３といった各装置の状態を監視し、各装置で異常が発生した場合にアラームを受け付けるサーバである。アラームの取得頻度やアラームに対する対応方針は、監視サーバ２４から復旧制御装置１０に転送される。アラーム発生の契機となるレイヤは、各装置及び各アラームごとに異なり、サーバ装置２１ではハードウェア部２９またはハイパーバイザ２８からのアラームが考えられる。例えばハードウェア部２９は、ハードウェアベンダにおいて定義／設計されたメッセージをアラームとして監視サーバ２４に送付する。またハイパーバイザ２８は、仮想化製品ベンダにおいて定義／設計されたメッセージをアラームとして監視サーバ２４に送付する。同様に、仮想マシン２０からは、アプリケーション（ＡＰＰ）２６のレイヤやゲストＯＳ（Operating System）２７のレイヤからもアラームが発生する可能性がある。

また、監視サーバ２４は、仮想マシン２０、サーバ装置２１、ネットワーク装置２２、及びストレージ装置２３といった各装置の死活監視も行う。監視サーバ２４は、各装置に対して定期的に疎通確認を実施し、応答が返ってこない場合に、当該装置との接続が切断された旨のアラームを出力する。

仮想マネージャ２５は、仮想マシン２０上で稼働するＡＰＰ２６の状態、及びサーバ装置２１上で稼働するハイパーバイザ２８の状態を取得可能な仮想インフラ管理サーバである。

図３は、復旧制御装置１０の構成例を示す図である。図３を参照しながら、復旧制御装置１０の内部構成や、復旧制御装置１０と監視サーバ２４及び仮想マネージャ２５との関係について詳しく説明する。図３に示すように、復旧制御装置１０は、復旧制御部１１及びデータベース（ＤＢ）１２を備え、例えばパーソナルコンピュータ（ＰＣ）等の計算機で実現される。

復旧制御部１１は、プロセッサがプログラムを読込んで実行することによって所定の機能を提供する制御手段であって、具体的な機能としては例えば、仮想マシン２０の復旧要否を判断する機能、及び仮想マシン２０の復旧動作を仮想マネージャ２５に指示する機能を提供する。

ＤＢ１２は、データの記憶手段であって、復旧制御部１１が仮想マシン２０の復旧要否及び復旧動作を判断するために必要とされる情報（要件）等が登録された復旧要件情報１００を保持する。復旧要件情報１００の詳細なデータ構成等は、図５を参照しながら後述するが、復旧要件情報１００は、予めユーザによって登録されるとし、また、ユーザの入力を受けて追加または更新することも可能とする。また、ＤＢ１２は、復旧制御部１１が復旧要否を判断するために用いられる要素として、過去のアラーム内容、復旧要否判断に使用した仮想マシン２０の状態、復旧要否判断に使用したＡＰＰ２６の状態を保持する。上記各要素は、復旧制御部１１によって取得されてＤＢ１２に格納される。具体的には例えば、復旧制御部１１は、過去のアラーム内容を本番環境２内の監視サーバ２４から受け取り、復旧要否判断に使用した仮想マシン２０の状態、及び復旧要否判断に使用したＡＰＰ２６の状態を、仮想マネージャ２５から受け取る。

なお、復旧制御装置１０（復旧制御部１１）は、本番環境２の仮想マネージャ２５を操作する権限を有するが、復旧制御装置１０が制御可能な処理は、仮想マシン２０のバックアップデータ３０を本番環境２にコピーし、コピーした仮想マシン２０の電源を起動すること、及び、バックアップ取得の頻度の変更を仮想マネージャ２５に依頼することに限定されるとする。

監視サーバ２４は、アラーム受信時または死活監視による機器（装置）の切断検知時に、アラーム内容と切断対象の機器を復旧制御装置１０に通知する。

仮想マネージャ２５は、定期的に、仮想マシン２０の状態と仮想マシン２０上で稼働するアプリケーション２６の状態を復旧制御装置１０に通知する。あるいは、仮想マネージャ２５は、復旧制御装置１０の要求に基づいて、上記情報（仮想マシン２０の状態と仮想マシン２０上で稼働するアプリケーション２６の状態）を復旧制御装置１０に通知する。

図４は、仮想マシン２０の障害発生時に復旧要否を判断する処理の処理手順例を示すフローチャートである。図４の各処理は、主として復旧制御部１１によって実行される。

図４によるとまず、復旧制御部１１は、仮想マシン２０からアラームが発生しているか否かを確認する（ステップＳ１１）。具体的には、復旧制御部１１は、監視サーバ２４が仮想マシン２０からアラームを受信したか否かを、監視サーバ２４からの通知を確認することによって判断する。仮想マシン２０からアラームが発生していない場合（ステップＳ１１のＮＯ）、復旧制御部１１は復旧不要と判断して処理を終了する。一方、仮想マシン２０からアラームが発生している場合は（ステップＳ１１のＹＥＳ）、復旧制御部１１は、当該アラーム（以後、仮想マシン２０のアラームとも称する）の内容を確認し（ステップＳ１２）、ステップＳ１３に進む。仮想マシン２０のアラームの内容は、監視サーバ２４からの通知の内容を参照することによって確認することができる。

ステップＳ１３では、復旧制御部１１は、ここまでの処理で収集した情報によって復旧要否を判断可能であるか否かを判定する。ステップＳ１３の処理は、言い換えれば、復旧制御部１１が復旧要否を判断するために、ステップＳ１２で確認した仮想マシン２０のアラーム内容以外に、追加情報が必要かを確認するための処理である。

ステップＳ１３において具体的には、復旧制御部１１は、ＤＢ１２に保持されている復旧要件情報１００と仮想マシン２０のアラーム内容とを突合し、上記アラーム内容のみを判断基準とする復旧要否の要件が復旧要件情報１００に登録されている場合には、復旧要否を判断可能と判定して（ステップＳ１３のＹＥＳ）、ステップＳ１４に進む。ステップＳ１４に遷移することにより、復旧制御部１１は復旧要否の判断のためのこれ以上の情報収集が不要となり、後述するステップＳ１５～Ｓ２５の処理をスキップすることができる。なお、詳細は図５を参照しながら後述するが、復旧要件情報１００には、仮想マシン２０で発生するアラームごとに、復旧要否の判断のために必要とされる要件の組合せ、復旧要否、及び、復旧方法が登録されている。

ステップＳ１４において、復旧制御部１１は、復旧要件情報１００に基づいて、障害からの復旧動作が必要か否か（復旧要否）を判断する。ステップＳ１４において復旧が必要と判断された場合（ステップＳ１４のＹＥＳ）、復旧制御部１１は、復旧要件情報１００に登録された復旧方法にしたがって復旧動作を仮想マネージャ２５に指示することにより、仮想マシン２０を復旧する（ステップＳ２６）。また、ステップＳ１４において復旧が不要と判断された場合には（ステップＳ１４のＮＯ）、復旧制御部１１は復旧動作を指示することなく処理を終了する。

一方、ステップＳ１３において復旧制御部１１がここまでの処理で収集した情報だけでは復旧要否を判断できないと判定した場合は（ステップＳ１３のＮＯ）、ステップＳ１５に進む。ステップＳ１５において、復旧制御部１１は、ステップＳ１１で確認したアラームの発生時刻から一定時間（例えば１０秒）前後に発生したアラーム（以後、事象発生前後のアラームと称する）の内容を確認する。ステップＳ１５で確認するアラームの内容は、ステップＳ１１で確認したアラームの内容と同一のものに限定されず、事象発生前後の全てのアラームの内容が確認される。

ステップＳ１５の後、復旧制御部１１は、ここまでの処理で収集した情報によって復旧要否を判断可能であるか否かを判定する（ステップＳ１６）。ステップＳ１６の処理は、言い換えれば、復旧制御部１１が復旧要否を判断するために、仮想マシン２０のアラーム内容及び事象発生前後のアラーム内容以外に、追加情報が必要かを確認するための処理である。

ステップＳ１６において具体的には、復旧制御部１１は、ＤＢ１２に保持されている復旧要件情報１００と仮想マシン２０のアラーム内容及び事象発生前後のアラーム内容とを突合し、これらの情報のみを判断基準とする復旧要否の要件が復旧要件情報１００に登録されている場合には、復旧要否を判断可能と判定して（ステップＳ１６のＹＥＳ）、ステップＳ１７に進む。ステップＳ１７に遷移することにより、復旧制御部１１は復旧要否の判断のためのこれ以上の情報収集が不要となり、後述するステップＳ１８～Ｓ２５の処理をスキップすることができる。

ステップＳ１７において、復旧制御部１１は、復旧要件情報１００に基づいて、復旧要否を判断する。ステップＳ１７において復旧が必要と判断された場合（ステップＳ１７のＹＥＳ）、復旧制御部１１は、復旧要件情報１００に登録された復旧方法にしたがって復旧動作を仮想マネージャ２５に指示することにより、仮想マシン２０を復旧する（ステップＳ２６）。また、ステップＳ１７において復旧が不要と判断された場合には（ステップＳ１７のＮＯ）、復旧制御部１１は復旧動作を指示することなく処理を終了する。

一方、ステップＳ１６において復旧制御部１１がここまでの処理で収集した情報だけでは復旧要否を判断できないと判定した場合は（ステップＳ１６のＮＯ）、ステップＳ１８に進む。ステップＳ１８において、復旧制御部１１は、仮想マシン２０の状態を確認する。

ステップＳ１８の後、復旧制御部１１は、ここまでの処理で収集した情報によって復旧要否を判断可能であるか否かを判定する（ステップＳ１９）。ステップＳ１６の処理は、言い換えれば、復旧制御部１１が復旧要否を判断するために、仮想マシン２０のアラーム内容、事象発生前後のアラーム内容、及び仮想マシン２０の状態以外に、追加情報が必要かを確認するための処理である。

ステップＳ１９において具体的には、復旧制御部１１は、ＤＢ１２に保持されている復旧要件情報１００と、仮想マシン２０のアラーム内容、事象発生前後のアラーム内容、及び仮想マシン２０の状態と、を突合し、これらの情報のみを判断基準とする復旧要否の要件が復旧要件情報１００に登録されている場合には、復旧要否を判断可能と判定して（ステップＳ１９のＹＥＳ）、ステップＳ２０に進む。ステップＳ２０に遷移することにより、復旧制御部１１は復旧要否の判断のためのこれ以上の情報収集が不要となり、後述するステップＳ２１～Ｓ２５の処理をスキップすることができる。

ステップＳ２０において、復旧制御部１１は、復旧要件情報１００に基づいて、復旧要否を判断する。ステップＳ２０において復旧が必要と判断された場合（ステップＳ２０のＹＥＳ）、復旧制御部１１は、復旧要件情報１００に登録された復旧方法にしたがって復旧動作を仮想マネージャ２５に指示することにより、仮想マシン２０を復旧する（ステップＳ２６）。また、ステップＳ２０において復旧が不要と判断された場合には（ステップＳ２０のＮＯ）、復旧制御部１１は復旧動作を指示することなく処理を終了する。

一方、ステップＳ１９において復旧制御部１１がここまでの処理で収集した情報だけでは復旧要否を判断できないと判定した場合は（ステップＳ１９のＮＯ）、ステップＳ２１に進む。ステップＳ２１において、復旧制御部１１は、ＡＰＰ２６の状態を確認する。

ステップＳ２１の後、復旧制御部１１は、ここまでの処理で収集した情報によって復旧要否を判断可能であるか否かを判定する（ステップＳ２２）。ステップＳ２２の処理は、言い換えれば、復旧制御部１１が復旧要否を判断するために、仮想マシン２０のアラーム内容、事象発生前後のアラーム内容、仮想マシン２０の状態、及びＡＰＰ２６の状態以外に、追加情報が必要かを確認するための処理である。

ステップＳ２２において具体的には、復旧制御部１１は、ＤＢ１２に保持されている復旧要件情報１００と、仮想マシン２０のアラーム内容、事象発生前後のアラーム内容、仮想マシン２０の状態、及びＡＰＰ２６の状態と、を突合し、これらの情報のみを判断基準とする復旧要否の要件が復旧要件情報１００に登録されている場合には、復旧要否を判断可能と判定して（ステップＳ２２のＹＥＳ）、ステップＳ２３に進む。

ステップＳ２３において、復旧制御部１１は、復旧要件情報１００に基づいて、復旧要否を判断する。ステップＳ２３において復旧が必要と判断された場合（ステップＳ２３のＹＥＳ）、復旧制御部１１は、復旧要件情報１００に登録された復旧方法にしたがって復旧動作を仮想マネージャ２５に指示することにより、仮想マシン２０を復旧する（ステップＳ２６）。また、ステップＳ２３において復旧が不要と判断された場合には（ステップＳ２３のＮＯ）、復旧制御部１１は復旧動作を指示することなく処理を終了する。

一方、ステップＳ２２において復旧制御部１１がここまでの処理で収集した情報だけでは復旧要否を判断できないと判定した場合は（ステップＳ２２のＮＯ）、ステップＳ２４に進む。ステップＳ２４に遷移する場合は、復旧制御部１１が自動で復旧要否の判断及び復旧動作の決定を行うことができない場合であり、このとき、復旧制御部１１は、担当者に判断を要求する。

具体的には、ステップＳ２４において、復旧制御部１１は、予め用意されたインタフェース（例えばＧＵＩ）を用いて、担当者に復旧要否の判断を求める判断要求画面を表示する。そして、担当者が判断要求画面に対して、復旧要否と判断の根拠とする状況（判断基準の要件）とを入力すると、復旧制御部１１は入力された内容をＤＢ１２に登録する（ステップＳ２５）。なお、担当者に入力を求め、ＤＢ１２に登録する「判断の根拠とする状況」は、具体的には、復旧要件情報１００に記載される各項目の少なくとも一部、すなわち、アラーム内容、事象発生前後のアラーム内容、仮想マシン２０の状態、及びＡＰＰ２６の状態の一部またはすべて、とすることができる。また、復旧方法も、判断要求画面において担当者に入力を要求する項目としてよく、復旧方法が入力された場合、復旧制御部１１はステップＳ２５において復旧方法も合わせてＤＢ１２に登録する。ステップＳ２５で登録した情報は、次回以降のアラーム発生時に、復旧制御部１１による復旧要否及び復旧方法の判断に利用される。そしてステップＳ２５の処理後、復旧制御部１１は処理を終了する。

以上ステップＳ１１～Ｓ２６の処理が行われることにより、復旧制御部１１は、仮想マシン２０の障害発生時に、復旧要否を判断し、さらに復旧が必要な場合にはその復旧動作を仮想マネージャ２５に指示することにより、障害からの復旧を制御することができる。

図５は、復旧要件情報１００の一例を示す図である。復旧要件情報１００は、ＤＢ１２に保持されるデータであり、復旧制御部１１が仮想マシン２０の復旧要否及び復旧動作を判断するために必要とされる情報（要件）が担当者によって予め登録される。また、図４のステップＳ２５で説明したように、復旧要否の判断ができない状況が発生した場合には、担当者によって復旧判断の要否等に関する情報が新たに入力され、当該入力の内容が復旧制御部１１によって復旧要件情報１００に新規に追加される。

図５に例示した復旧要件情報１００は、項番１０１、仮想マシンアラーム１０２、前後アラーム１０３、仮想マシン状態１０４、ＡＰＰ状態１０５、復旧要否１０６、及び復旧方法１０７のデータ項目を有して構成される。

項番１０１は、復旧要件情報１００のレコードごとの整理番号であり、仮想マシンアラーム１０２ごとに異なる番号が割り当てられる。仮想マシンアラーム１０２には、仮想マシン２０で発生するアラームの内容が示される。前後アラーム１０３には、仮想マシンアラーム１０２の一定時間（例えば１０秒）前後に発生したアラーム（事象発生前後のアラーム）の内容が示される。仮想マシン状態１０４には、仮想マシン２０における「正常状態」や「パワーオフ状態」等の動作状態が示される。ＡＰＰ状態１０５には、ＡＰＰ２６における「正常状態」や「異常状態」等の動作状態が示される。復旧要否１０６には、仮想マシンアラーム１０２が発生した場合の復旧作業の要否が示される。復旧方法１０７には、仮想マシンアラーム１０２が発生した場合の復旧作業の方法が示される。そして図５の場合、仮想マシンアラーム１０２からＡＰＰ状態１０５までの各項目が、復旧要否１０６の判断基準（要件）であり、復旧方法１０７は、各要件に基づいて復旧要否１０６が「要」とされるときの復旧方法である。なお、図５は復旧要件情報１００の一例を示すものに過ぎず、本実施形態に係る復旧要件情報１００のデータ構成はこれに限定されるものではなく、仮想マシンシステム１の構成や通知アラーム等に応じて、様々なデータ構成を有するとしてよい。

以下、図５の各レコードの登録内容について具体的に説明する。

項番「１」のレコードには、仮想マシン２０がダウンした旨のアラーム（サーバダウン）が発生し、当該アラームが仮想マシン２０から監視サーバ２４に到達しており、かつ、当該アラームの発生時刻から一定時間前後の時間帯に他のアラーム（事象発生前後のアラーム）が発生していない状況が登録されている。上記項番「１」の状況は、仮想マシン２０単体の障害であり、サーバ装置２１、ネットワーク装置２２、またはストレージ装置２３を起因としたハードウェア障害ではないと考えられるため、復旧が有効（復旧要否１０６が「要」）とされる。また、この状況で有効な復旧方法は、復旧制御部１１が仮想マネージャ２５に以下の復旧動作を指示する方法（復旧方法Ａ）が考えられる。すなわち、復旧方法Ａでは、復旧制御部１１からの復旧指示にしたがって、仮想マネージャ２５は、バックアップ環境３から仮想マシン２０のバックアップデータ３０をコピーし、そのコピーデータを本番環境２の仮想マシン２０に上書きする。

したがって、上記のようなアラームの発生に対する復旧要否及び復旧方法を担当者が新たに登録する場合は、項番「１」に示されるように、復旧要否１０６を「要」とする判断基準（要件）として、仮想マシンアラーム１０２に「サーバダウン」、前後アラーム１０３に「アラームが存在しない」、仮想マシン状態１０４及びＡＰＰ状態１０５に不問を意味する「問わない」、が復旧要件情報１００に登録される。また、復旧方法１０７には「Ａ」が登録される。

項番「２」のレコードには、仮想マシン２０上で稼働している印刷用のサービス（印刷サービス）がダウンした旨のアラームが発生し、当該アラームが仮想マシン２０から監視サーバ２４に到達しており、かつ、当該アラームの発生時刻から一定時間前後の時間帯に他のアラーム（事象発生前後のアラーム）が発生していない状況が登録されている。上記項番「２」の状況は、仮想マシン２０単体の障害であり、サーバ装置２１、ネットワーク装置２２、またはストレージ装置２３を起因としたハードウェア障害ではないと考えられる。但し、項番「１」に登録された「サーバダウン」の状況と比較すると、項番「２」の状況は、業務との関連性が比較的低いサービス（印刷サービス）単体のダウンであることから、業務上の緊急性が低いと考えられるため、復旧は不要（復旧要否１０６が「不要」）とされる。この場合、当然ながら、復旧方法は登録不要である。

したがって、上記のようなアラームの発生に対する復旧要否及び復旧方法を担当者が新たに登録する場合は、項番「２」に示されるように、復旧要否１０６を「不要」とする判断基準（要件）として、仮想マシンアラーム１０２に「印刷サービスがダウン」、前後アラーム１０３に「アラームが存在しない」、仮想マシン状態１０４及びＡＰＰ状態１０５に「問わない」、が復旧要件情報１００に登録される。また、復旧方法１０７には、特段の方法が登録されない。

項番「３」のレコードには、仮想マシン２０においてディスク領域（ストレージ装置２３）にアクセスできない旨のアラームが発生し、当該アラームが仮想マシン２０から監視サーバ２４に到達しており、かつ、当該アラームの発生時刻から一定時間前後の時間帯に、ホストとストレージ装置２３との接続が切断された旨のアラームが監視サーバ２４に到達している状況が登録されている。上記項番「３」の状況は、仮想マシン２０単体の障害ではなく、複数の装置を起因としたハードウェア障害であると考えられるため、仮想マシン２０を含めた複数の装置に対して復旧動作を行うことによって、復旧が有効（復旧要否１０６を「要」）とされる。この状況で有効な復旧方法は、復旧制御部１１が仮想マネージャ２５に以下の復旧動作を指示する方法（復旧方法Ｂ）が考えられる。すなわち、復旧方法Ｂでは、復旧制御部１１からの復旧指示にしたがって、仮想マネージャ２５は、バックアップ環境３から仮想マシン２０のバックアップデータ３０をコピーし、そのコピーデータを用いて、サーバ装置２１以外の他のホストサーバ上で仮想マシン２０を稼働させる。この復旧方法Ｂが実行されることにより、仮想マシン２０とストレージ装置２３の接続だけでなく、ホストとストレージ装置２３の接続を復旧することができる。

したがって、上記のようなアラームの発生に対する復旧要否及び復旧方法を担当者が新たに登録する場合は、項番「３」に示されるように、復旧要否１０６を「要」とする判断基準（要件）として、仮想マシンアラーム１０２に「ディスクにアクセスできない」、前後アラーム１０３に「ホストとストレージの接続が切断」、仮想マシン状態１０４及びＡＰＰ状態１０５に不問を意味する「問わない」、が復旧要件情報１００に登録される。さらに、復旧方法１０７には「Ｂ」が登録される。

項番「４」のレコードには、仮想マシン２０と監視サーバ２４との接続が切断し、監視サーバ２４から仮想マシン２０に接続できなくなった旨のアラームが発生し、仮想マネージャ２５から確認できる仮想マシン２０の状態がパワーオフ状態である状況が登録されている。上記項番「４」の状況は、仮想マシン２０単体の障害でありハードウェア障害ではないと考えられるため、復旧方法Ａによる復旧が有効（復旧要否１０６が「要」）とされる。

したがって、上記のようなアラームの発生に対する復旧要否及び復旧方法を担当者が新たに登録する場合は、項番「４」に示されるように、復旧要否１０６を「要」とする判断基準（要件）として、仮想マシンアラーム１０２に「監視サーバとの接続が切断」、前後アラーム１０３に「問わない」、仮想マシン状態１０４に「パワーオフ状態」、ＡＰＰ状態１０５に「問わない」、が復旧要件情報１００に登録される。また、復旧方法１０７には「Ａ」が登録される。

項番「５」のレコードには、仮想マシン２０と監視サーバ２４との接続が切断し、監視サーバ２４から仮想マシン２０に接続できなくなった旨のアラームが発生し、仮想マネージャ２５から確認できる仮想マシン２０の動作状態が「正常状態」であり、仮想マネージャ２５から確認できるＡＰＰ２６の動作状態が「正常状態」である状況が登録されている。上記項番「５」の状況は、仮想マシン２０と監視サーバ２４との接続が切断された状態ではあるが、仮想マシン２０及びＡＰＰ２６が正常状態であることから、業務上の緊急性が低いと考えられるため、復旧は不要（復旧要否１０６が「不要」）とされる。この場合、当然ながら、復旧方法は登録不要である。

したがって、上記のようなアラームの発生に対する復旧要否及び復旧方法を担当者が新たに登録する場合は、項番「５」に示されるように、復旧要否１０６を「不要」とする判断基準（要件）として、仮想マシンアラーム１０２に「監視サーバとの接続が切断」、前後アラーム１０３に「問わない」、仮想マシン状態１０４に「正常状態」、ＡＰＰ状態１０５に「正常状態」、が復旧要件情報１００に登録される。また、復旧方法１０７には、特段の方法が登録されない。

次に、図５の復旧要件情報１００がＤＢ１２に保持されている場合について、図４に示した処理の具体的な遷移パターンをいくつか確認する。

まず一例として、仮想マシン２０からアラームが発生しているとする場合、ステップＳ１１はＹＥＳと判定されるため、ステップＳ１２に遷移する。そしてステップＳ１２において、例えば仮想マシン２０がダウンした旨のアラーム（サーバダウン）を確認したとする場合、次のステップＳ１３において復旧制御部１１は、ＤＢ１２に保持されている復旧要件情報１００を参照し、当該アラームの内容だけを根拠として復旧要否１０６を判断可能なレコードが登録されているかを確認する。しかし、図５の復旧要件情報１００にはこのようなレコードは存在しないため、ステップＳ１５に遷移する。そしてステップＳ１５において、復旧制御部１１が、例えばサーバダウンのアラーム発生時刻の一定時間前後に他のアラームが発生していないことを確認したとすると、次のステップＳ１６において、これまでに取得・確認した情報が、図５の復旧要件情報１００の項番「１」のレコードに登録された要件に合致することが確認されるため（ステップＳ１６のＹＥＳ）、ステップＳ１７に遷移する。そして、ステップＳ１７では、図５の復旧要件情報１００の項番「１」のレコードの復旧要否１０６が「要」であることから、復旧制御部１１は復旧が必要であると判断し（ステップＳ１７のＹＥＳ）、ステップＳ２６に遷移して、項番「１」のレコードの復旧方法１０７に登録された復旧方法「Ａ」にしたがって、仮想マネージャ２５による復旧動作が行われる。

このように上記例では、復旧制御部１１は、仮想マシン２０で発生したアラームの内容（サーバダウン）と、仮想マシンシステム１を構成する装置全体における事象発生前後のアラームの内容（アラームが存在しない）とを判断基準として、復旧の要否を判断し、適切な復旧動作（復旧方法Ａ）を制御することができる。

また別例として、仮想マシン２０からアラームが発生しているとする場合、ステップＳ１１はＹＥＳと判定されるため、ステップＳ１２に遷移する。そしてステップＳ１２において、例えば仮想マシン２０と監視サーバ２４との接続が切れた旨のアラーム（監視サーバとの接続が切断）を確認したとする場合、次のステップＳ１３において復旧制御部１１は、ＤＢ１２に保持されている復旧要件情報１００を参照し、当該アラームの内容だけを根拠として復旧要否１０６を判断可能なレコードが登録されているかを確認する。しかし、図５の復旧要件情報１００にはこのようなレコードは存在しないため、ステップＳ１５に遷移する。そしてステップＳ１５において、復旧制御部１１が、例えばサーバダウンのアラーム発生時刻の一定時間前後に他のアラームが発生していないことを確認したとすると、次のステップＳ１６で、再び復旧要件情報１００を参照し、これまでに取得・確認した情報を根拠として復旧要否１０６を判断可能なレコードが登録されているかを確認する。しかし、図５の復旧要件情報１００にはこのようなレコードは存在しないため、ステップＳ１８に遷移する。そしてステップＳ１８において、復旧制御部１１が、例えば仮想マシン２０の動作状態が「正常状態」であると確認できたとすると、次のステップＳ１９で、再び復旧要件情報１００を参照し、これまでに取得・確認した情報を根拠として復旧要否１０６を判断可能なレコードが登録されているかを確認する。しかし、図５の復旧要件情報１００にはこのようなレコードは存在しないため、ステップＳ２１に遷移する。そしてステップＳ２１において、復旧制御部１１が、例えばＡＰＰ２６の動作状態が「正常状態」であると確認できたとすると、次のステップＳ２２においてようやく、これまでに取得・確認した情報が、図５の復旧要件情報１００の項番「５」のレコードに登録された要件に合致することが確認されるため（ステップＳ２２のＹＥＳ）、ステップＳ２３に遷移する。そして、ステップＳ２３では、図５の復旧要件情報１００の項番「５」のレコードの復旧要否１０６が「不要」であることから、復旧制御部１１は復旧が不要であると判断し（ステップＳ２３のＮＯ）、仮想マネージャ２５に復旧動作を指示することなく処理を終了する。

このように上記例では、仮想マシン２０で発生したアラームの内容（監視サーバとの接続が切断）に加えて、仮想マシンシステム１を構成する複数の装置、すなわち、仮想マシン２０及びＡＰＰ２６の動作状態を判断基準として、復旧の要否を判断することができる。

以上に説明したように、本実施形態に係る復旧制御装置１０によれば、仮想マシン２０の障害発生時に、復旧を判断するために複数種別の構成装置（具体的には、仮想マシン２０、サーバ装置２１、ネットワーク装置２２、ストレージ装置２３、監視サーバ２４、仮想マネージャ２５、ＡＰＰ２６、ゲストＯＳ２７、ハイパーバイザ２８、ハードウェア部２９）における情報が必要となる場合でも、必要な情報を収集し、自動で復旧要否を判断することができる。また、復旧制御装置１０は、上記の復旧要否を判断するための要件（復旧要件情報１００）をデータ記憶部（ＤＢ１２）に保存することで、仮想マシン２０の障害発生時に、障害の切り分けや原因調査を行わなくても仮想マシン２０の復旧要否を判断できるため、障害の切り分けや原因調査に要する時間を待つことなく、迅速な復旧対応が可能となる。

また、本実施形態に係る復旧制御装置１０では、仮想マシン２０でアラームが発生した場合に、復旧制御部１１が、当該アラームの内容を示す情報を収集する（図４のステップＳ１２）とともに、復旧要否の判断基準（要件）を構成し得る他の情報を、仮想マシンシステム１の構成装置から段階的に収集し（図４のステップＳ１２，Ｓ１５，Ｓ１８，Ｓ２１）、各段階で当該アラームに対する復旧要否の判断の可否を判定し（図４のステップＳ１３，Ｓ１６，Ｓ１９，Ｓ２２）、復旧要否の判断が可能と判定した場合は残りの段階の情報収集を行うことなく、判定結果に従って復旧要否を判断する（図４のステップＳ１４，Ｓ１７，Ｓ２０，Ｓ２３）ため、必要な情報を収集できた時点で不要な処理を省略して、少ない処理負荷で復旧要否を判断することができる。

また、本実施形態に係る復旧制御装置１０では、復旧要件情報１００において、復旧要否１０６とその判断基準（仮想マシンアラーム１０２、前後アラーム１０３、仮想マシン状態１０４、ＡＰＰ状態１０５）に加えて、復旧を必要とする場合の好適な復旧方法１０７を紐付けて登録することができ、復旧制御部１１が、復旧が必要と判断した場合には、当該判断の判断基準に対応する復旧方法にしたがって仮想マシン２０の復旧動作を制御することにより、障害の切り分けや原因調査を行う時間を待つことなく、障害が発生した仮想マシン２０を自動的に迅速に復旧することができる。

また、本実施形態に係る復旧制御装置１０では、復旧要否及び復旧方法並びにそれらの判断基準について、担当者（ユーザ）による入力を受け付けて、復旧要件情報に追加したり修正したりできるため、ユーザによる任意のカスタマイズが可能となり、柔軟な復旧判断に対応することができる。

また、本実施形態に係る復旧制御装置１０では、復旧制御部１１が復旧要否の判断基準を構成し得る情報を段階的に収集する際、監視サーバ２４からの情報の収集（図４のステップＳ１２，Ｓ１５）を先行して行い、仮想マネージャ２５からの情報の収集（図４のステップＳ１８，Ｓ２１）を後続して行う。これは、監視サーバ２４から収集する情報（例えば、仮想マシン２０で発生したアラームの内容、事象発生前後のアラームの内容）が、仮想マネージャ２５から収集する情報（例えば、仮想マシン２０やＡＰＰ２６の動作状態）よりも比較的情報量が多いためであり、情報量が多い情報の収集を先に行うようにすることで、全体的な処理速度及び処理効率を高める効果に期待できる。また、同じ収集先から連続して情報を収集するように構成することで、復旧制御部１１による処理効率を高める効果にも期待できる。

また、本実施形態に係る復旧制御装置１０では、仮想マシン２０でアラームが発生したとき、復旧制御部１１は、仮想マシン２０の復旧が必要であると判断した場合には、復旧要件情報１００に登録された復旧方法１０７に沿った復旧動作の実行を仮想マネージャ２５に指示することで、仮想マシン２０の復旧動作を制御することができる。

なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。例えば、監視サーバ２４による監視対象の種類に増減があった場合でも、本発明を適用可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、図面において制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実施には殆ど全ての構成が相互に接続されていると考えてもよい。

１ 仮想マシンシステム
２ 本番環境
３ バックアップ環境
１０ 復旧制御装置
１１ 復旧制御部
１２ データベース（ＤＢ）
２０ 仮想マシン
２１ サーバ装置
２２ ネットワーク装置
２３ ストレージ装置
２４ 監視サーバ
２５ 仮想マネージャ
２６ アプリケーション（ＡＰＰ）
２７ ゲストＯＳ
２８ ハイパーバイザ
２９ ハードウェア部
３０ バックアップデータ
１００ 復旧要件情報

Claims (12)

1. 仮想マシンシステムで動作する復旧制御装置であって、
   前記仮想マシンシステムで稼働する仮想マシンにおいてアラームが発生した場合に、当該アラームの内容を示す情報、または前記仮想マシンシステムを構成する複数種別の構成装置における所定の情報を収集し、前記収集した情報を用いて前記仮想マシンの復旧要否を判断する
   ことを特徴とする復旧制御装置。
2. 前記仮想マシンの障害からの復旧要否を判断する復旧制御部と、
   前記復旧要否の判断基準が登録された復旧要件情報を保持する情報記憶部と、
   を備え、
   前記復旧要否の判断基準は、前記仮想マシンで発生するアラームの内容と、前記構成装置における１乃至複数の情報と、を組合せて構成され、
   前記仮想マシンでアラームが発生した場合、
   前記復旧制御部は、
   前記発生したアラームの内容を示す情報を収集するとともに、前記復旧要否の判断基準を構成し得る情報として、前記複数種別の構成装置における情報を段階的に収集し、
   前記収集の各段階で、当該段階までに収集した情報と前記復旧要件情報とに基づいて、前記アラームに対する復旧要否の判断の可否を判定し、
   前記復旧要否の判断が可能と判定した時点で、残りの段階の前記収集を行うことなく、前記判定の結果に従って復旧要否を判断する
   ことを特徴とする請求項１に記載の復旧制御装置。
3. 前記復旧要件情報には、復旧を必要とする場合の好適な復旧方法が前記復旧要否の判断基準に紐付けて登録され、
   前記復旧制御部は、前記復旧要否の判断で復旧が必要と判断した場合に、当該判断の判断基準に対応する前記復旧方法に従って、前記仮想マシンの復旧動作を制御する
   ことを特徴とする請求項２に記載の復旧制御装置。
4. 前記情報記憶部は、ユーザによる入力を受けて、前記復旧要件情報において、前記復旧要否及びその判断基準を追加登録することができる
   ことを特徴とする請求項２に記載の復旧制御装置。
5. 前記復旧制御部は、前記復旧要否の判断基準を構成し得る情報を段階的に収集する際、
   先行する段階で、収集する情報量が比較的多い第１の前記構成装置から情報を収集し、
   後続する段階で、前記第１の構成装置よりも収集する情報量が少ない第２の前記構成装置から情報を収集する
   ことを特徴とする請求項２に記載の復旧制御装置。
6. 前記復旧制御部は、前記仮想マシンシステムの監視サーバから、
   前記復旧要否の判断基準を構成し得る情報として、前記仮想マシンで発生したアラームの内容を示す情報と、当該アラームの発生タイミングから所定時間前後する期間に前記仮想マシンシステムの構成装置で発生したアラームの内容を示す情報と、を収集する
   ことを特徴とする請求項２に記載の復旧制御装置。
7. 前記復旧制御部は、前記仮想マシンシステムの仮想インフラを管理する仮想マネージャから、
   前記復旧要否の判断基準を構成し得る情報として、前記仮想マシンの動作状態、または前記仮想マシン上で稼働するアプリケーションの動作状態を収集する
   ことを特徴とする請求項２に記載の復旧制御装置。
8. 前記復旧制御部は、前記仮想マシンの復旧動作を制御する際、前記仮想マシンシステムにおける仮想インフラを管理する仮想マネージャに、前記復旧要件情報に登録された前記復旧方法に沿った復旧動作の実行を指示する
   ことを特徴とする請求項３に記載の復旧制御装置。
9. 仮想マシンシステムで動作する復旧制御装置による復旧制御方法であって、
   前記仮想マシンシステムで稼働する仮想マシンにおいてアラームが発生した場合に、当該アラームの内容を示す情報、または前記仮想マシンシステムを構成する複数種別の構成装置における所定の情報を収集し、
   前記収集した情報を用いて前記仮想マシンの復旧要否を判断する
   ことを特徴とする復旧制御方法。
10. 前記復旧制御装置は、
    前記仮想マシンの障害からの復旧要否を判断する復旧制御部と、
    前記復旧要否の判断基準が登録された復旧要件情報を保持する情報記憶部と、
    を有し、
    前記復旧要否の判断基準は、前記仮想マシンで発生するアラームの内容と、前記構成装置における１乃至複数の情報と、を組合せて構成され、
    前記仮想マシンでアラームが発生した場合、
    前記復旧制御部が、前記発生したアラームの内容を示す情報を収集するとともに、前記復旧要否の判断基準を構成し得る情報として、前記複数種別の構成装置における情報を段階的に収集する情報収集ステップと、
    前記復旧制御部が、前記情報収集ステップの各段階で、当該段階までに収集した情報と前記復旧要件情報とに基づいて、前記アラームに対する復旧要否の判断の可否を判定する判断可否判定ステップと、
    前記復旧制御部が、前記判断可否判定ステップで前記復旧要否の判断が可能と判定した時点で、前記情報収集ステップの残りの段階の処理を行うことなく、前記判定の結果に従って復旧要否を判断する復旧要否判断ステップと、
    を備えることを特徴とする請求項９に記載の復旧制御方法。
11. 前記復旧要件情報には、復旧を必要とする場合の好適な復旧方法が前記復旧要否の判断基準に紐付けて登録され、
    前記復旧制御部が、前記復旧要否判断ステップで復旧が必要と判断した場合に、当該判断の判断基準に対応する前記復旧方法に従って、前記仮想マシンの復旧動作を制御する復旧制御ステップ、をさらに備える
    ことを特徴とする請求項１０に記載の復旧制御方法。
12. 前記情報記憶部が、ユーザによる入力を受けて、前記復旧要件情報において、前記復旧要否及びその判断基準を追加登録することができる
    ことを特徴とする請求項１０に記載の復旧制御方法。
    

Images