JP6555721B2

JP6555721B2 - 障害復旧システム及び方法

Info

Publication number: JP6555721B2
Application number: JP2016157458A
Authority: JP
Inventors: 健太川上; 兼三奥田; 利幸倉橋; 安川　正祥; 正祥安川
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2016-08-10
Filing date: 2016-08-10
Publication date: 2019-08-07
Anticipated expiration: 2036-08-10
Also published as: JP2018026709A

Description

本発明は、仮想化されたネットワークにおいて、障害が発生した際に自動的に復旧するシステムに関する

近年、ネットワーク機能仮想化が注目されている（非特許文献１，２参照）。ネットワーク機能仮想化のメリットとしては、保守運用の自動化の一つとして、障害が発生した際に自動的に復旧できること（オートヒーリング）が期待されている。

既存のオートヒーリング（非特許文献３参照）では、主にハードウェア故障をターゲットとしており、障害が発生した場合に、他の物理サーバに同一の仮想サーバを構築する手法が一般的であった。

また、オートヒーリングにおいて、ネットワークデータ分析を行う事でネットワークの状態を可視化し、復旧手順の検討に利用する手法が提案されている（非特許文献４参照）。

また、ネットワークネットワーク内外から得られる装置ログ、トラフィック、トラブルチケットなどのデータ分析、およびネットワーク故障対応の迅速化・正確化・省力化に取り組む手法が提案されている（非特許文献５，６参照）。

下西英之, "ネットワーク機能仮想化（ＮＦＶ）概要", [online], [平成28年7月14日検索], インターネット<URL:http://www.e-side.co.jp/okinawaopendays/2014/document/12_shimonishi.pdf> "Network Functions Virtualisation (NFV); Management and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, 2014-12 木内道男, "ＮＦＶ導入を左右する保守のしやすさ；鍵となるＥ２Ｅのオーケストレーション", [online], [平成28年7月14日検索], インターネット<URL:http://www.ric.co.jp/expo/ngns2014/extract/nec.html> T. Kimura, K. Ishibashi, T. Mori, H. Sawada, T. Toyono, K. Nishimatsu, A. Watanabe, A. Shimoda, and K. Shiomoto, "Spatio-temporal factorization of log data for understanding network events," Proc. of IEEE INFOCOM 2014, pp.610 -618, 2014 石橋圭介, "将来ネットワークの実現に向けたＡｎａｌｙｔｉｃｓ−ｂａｓｅｄオペレーション", [online], [平成28年7月14日検索], インターネット<URL:http://www.ntt.co.jp/journal/1507/files/jn201507024.pdf> 石橋圭介, 林孝典, 塩本公平, "機械学習・データ分析によるネットワーク設計・運用高度化", [online], [平成28年7月14日検索], インターネット<URL:http://www.ntt.co.jp/journal/1512/files/jn201512029.pdf>

しかし従来の各手法では、障害発生時の復旧に関して下記のような課題がある。

課題１：ソフトウェアレイヤの障害やその復旧は対象外である。

既存手法（非特許文献３）は、ハードウェア障害のみを対象としているため、障害復旧は他の物理サーバに同一の仮想サーバを構築する手法が使用されている。ソフトウェアバグが発生した場合は、他の物理サーバに同一の仮想サーバを構築しても同じソフトウェアバグが発生しサービス停止する可能性がある。

また、既存手法（非特許文献４）についても、ハードウェア障害やそれに起因したエラーメッセージをトリガとしてネットワークの状態を可視化する手法となっており、仮想化のソフトウェアに関する障害は対象外となっている。

既存手法（非特許文献５，６）についても、主にハードウェア障害を対象としており、ソフトウェアレイヤのバグやその復旧手順は対象外である。

課題２：ネットワーク全体の故障個所の切り分け→復旧の自動化が困難である。

既存手法（非特許文献３）では、特定装置の故障を契機として、該当装置のハードウェアの復旧を行っている。しかし、実際に発生するネットワーク障害は、上記の様な単純なケースばかりではなく、故障の原因箇所が不明であり、その特定が必要な場合がある。そのような場合に、既存手法では、故障個所を切り分けやそれに基づく復旧方法を保守運用者のノウハウに依存して手動で実施する必要がある。

既存手法（非特許文献５，６）では、故障対応時に運用者が記録するトラブルチケットログからの故障対応ワークフロー自動生成技術の検討が行われているが、そもそも予め未知の故障について運用者が手動で対応する事を前提としており、その様な故障に対する切り分け→復旧の自動化は行う事ができない。

課題３：サービス断の原因切り分けの自動化が困難である。

既存手法（非特許文献３，４）では、ハードウェア障害によるサービス断のみを対象としているが、実際のネットワークではトラヒックの予期せぬ急増による処理溢れもサービス断の原因となり得る。既存手法では、障害によるサービス断とトラヒック急増によるサービス断を切り分けて自動的に対処する事が不可能である。

既存手法（非特許文献５，６）では、サイバー空間上のユーザ行動を加味したトラフィック予測を行う検討を進めているが、そもそもトラヒック増の要因（単発での正常トラヒックの急増か、セキュリティ攻撃等の異常トラヒックの急増か）やその要因に基づく適切な対処の切り替えといった事は対象としてない。

上記課題を解決するために、本願発明は、仮想化環境が構築され該仮想化環境上でアプリケーションが動作するサーバ装置と、専用物理装置として構成されたネットワーク装置とを備え、前記サーバ装置の前記アプリケーションがユーザ端末にサービスを提供する仮想化されたネットワークにおいて、該ネットワークで発生した障害を復旧させる障害復旧システムであって、前記障害の発生原因及び発生装置を特定して前記アプリケーションによる前記ユーザ端末に対するサービス提供を継続するよう障害発生装置を復旧制御する復旧制御装置を備え、前記サーバ装置及び前記ネットワーク装置並びに前記ユーザ端末は、前記アプリケーションの正常性及び通信路の正常性を試験して正常性試験結果情報を前記復旧制御装置に送信する正常性試験手段を備え、前記サーバ装置及び前記ネットワーク装置は、自身のトラヒックを監視してトラヒック情報を前記復旧制御装置に送信するトラヒック監視手段を備え、前記復旧制御装置は、前記トラヒック情報に基づき障害が前記サーバ装置又は前記ネットワーク装置の装置障害によるものか或いはトラヒック増加によるものかを判定する障害原因判定手段と、装置障害が原因の場合には前記正常性試験結果情報に基づき障害発生装置を特定する障害装置特定手段と、障害発生装置に対して再起動及び再起動後に正常性試験を実施するよう指示し、障害が復旧しない場合には、予め用意しておいた代替サーバ装置又は代替ネットワーク装置であって障害発生装置と同等の機能を提供するものを障害発生装置の代替として使用するよう制御する第１の復旧制御手段とを備えたことを特徴とする。

本発明によれば、トラヒック情報及び正常性試験の結果情報に基づき障害発生の原因及び障害箇所の特定を行うので、ハードウェアだけでなく該ハードウェア上の各種ソフトウェアでの障害にも対応することができ、また、仮想化ネットワーク全体において障害箇所の切り分け及びそれに伴う障害復旧の自動化が可能となる。

本発明の概要を説明するシステム構成図アプリケーション正常性試験を説明する図通信路正常性試験を説明する図ユーザ端末・サーバ装置・ネットワーク装置の構成図復旧制御装置の構成図自動復旧のパターンを説明する図代替構成を説明する図自動復旧処理の概要を説明するフローチャート自動復旧処理の詳細を説明するフローチャート自動復旧処理の詳細を説明するフローチャート自動復旧処理の詳細を説明するフローチャート自動復旧処理の詳細を説明するフローチャート自動復旧処理の詳細を説明するフローチャート自動復旧処理の詳細を説明するフローチャート

本発明の一実施の形態に係る障害復旧システムについて図面を参照して説明する。図１は本発明の概要を説明するシステム構成図である。

本発明において障害復旧の対象とする仮想化されたネットワークは、ＮＦＶ（Network Functions Virtualisation）技術によりネットワーク機能が仮想化されたものを想定しており、図１に示すように、サーバ装置１００と、ネットワーク装置２００と、ユーザ端末１０とを備えている。

サーバ装置１００は、汎用物理サーバ装置上に仮想化環境が構築されており、さらに当該仮想化環境上にアプリケーションが動作する。本発明では、図１に示すように、サーバ装置１００は、下層から順に、ハードウェア層・ホストＯＳ層・ハイパーバイザー層・ゲストＯＳ層・アプリケーション層が形成されているものとして取り扱う。なお、ここでのレイヤは、ＯＳＩ（Open Systems Interconnection）参照モデルの７階層とは異なるものである点に留意されたい。すなわち、本発明においてサーバ装置１００で動作するアプリケーションは、ＯＳＩ参照モデルのアプリケーション層だけでなくネットワーク層やトランスポート層などの階層に対応するものも含まれる点に留意されたい。例えば、サーバ装置１００としては、ユーザ宅内の通信設備（ＣＰＥ（Customer Premises Equipment））を仮想化してネットワーク側に配置したｖＣＰＥなどが想定され、ファイヤウォール・ルータなどの各種ネットワーク機能を提供するものが挙げられる。

ネットワーク装置２００は、サーバ装置１００とユーザ端末１０との間の通信経路を形成する装置の１つであり、専用物理装置として実装されたものである。本発明では、ネットワーク装置２００は、下層から順に、ハードウェア層・ファームウェア層が形成されているものとして取り扱う。なお、ここでのレイヤは、サーバ装置１００と同様に、ＯＳＩ参照モデルとは異なるものである点に留意されたい。ネットワーク装置２００の具体例としては、専用物理装置としてのファイヤウォールやルータやＬ２スイッチなどが挙げられる。

また、本発明では、１つ以上のサーバ装置１００及び１つ以上のネットワーク装置２００により１つのサイトを構成し、さらに１つ以上のサイトによりプラットフォームを構成しているものとする。プラットフォームの配備位置としては、典型的には、インターネット上の所謂「クラウド」としてデータセンタ内に配備されたり、ユーザ端末がインターネットに接続するためのアクセスネットワーク（キャリアネットワーク）内のデータセンタ内に配備されたりする。プラットフォームの管理者は、プラットフォーム内において物理的な装置の増強等が可能であるものとする。

本発明では、復旧制御装置３００によりネットワークで生じた障害を自動的に復旧させることを目的とする。復旧制御装置３００のネットワーク上での配備位置は不問である。

本発明の特徴点は、（１）正常性試験及びトラヒック情報に基づく動作判断ロジックの確立、（２）「代替構成」による障害発生箇所の切り分け・サービス継続、という２つの手法を組み合わせることにより、多様な障害に対して柔軟に対応し、サービスの継続性を維持するものである。

上記の正常性試験としては、（Ａ）アプリケーション正常性試験、（Ｂ）通信路正常性試験、を定常的に行い、その試験結果は復旧制御装置３００に通知されるものとする。前記（Ａ）アプリケーション正常試験は、例えばＤＮＳ（Domain Name System）問合せ自動送信試験などが挙げられ、図２に示すように、（Ａ１）ユーザ端末１０・サーバ装置１００間での試験、（Ａ２）サーバ装置１００での単体試験が含まれる。また、前記（Ｂ）通信路正常性試験は、例えばＰＩＮＧによる疎通確認試験などが挙げられ、図３に示すように、（Ｂ１）ユーザ端末１０・サーバ装置１００間での試験、（Ｂ２）隣接する装置間での試験、（Ｂ３）ネットワーク装置２００単体での試験、（Ｂ４）サーバ装置１００単体での試験が含まれる。

また、上記のトラヒック情報は定期的に収集され、復旧制御装置３００に通知されるものとする。トラヒック情報としては、（Ｃ１）ネットワーク装置２００単体のトラヒック情報（例えば各インタフェースの入力パケットや出力パケットなど）、（Ｃ２）サーバ装置１００単体のトラヒック情報（例えば各インタフェースの入力パケットや出力パケットなど）が含まれる。

また、上記の「代替構成」について説明する。障害の形態として、各レイヤにおけるバグが発生した場合に、単純にその装置全体の再起動等の処理を行っても障害から復旧できないパターンが想定される。その様なパターンでもサービスを継続するために、障害発生前における構成を基本構成として、各レイヤ単位で、基本構成とは異なる種別の構成を用いる。これを代替構成と呼ぶ。ここで、「異なる種別の構成」とは、障害発生前における装置の当該レイヤにおいて同等の機能を提供するものであるが、異なる実装のものであり、異なる製品だけでなく、同一製品だが異なるバージョンやリビジョンのものも含んでよい。

ただし、全てのバリエーションの構成を準備すると、構成が爆発的に増加する可能性がある。このため、図４に示すように、１レイヤのみ変更した構成（（ｉ）〜（ｖ））と、全てを入れ替えた構成（（ｖｉ））を用意する。なお、図４では、ハッチングをかけたレイヤが「異なる種別の構成」である。

図５にユーザ端末、サーバ装置、ネットワーク装置の構成図を示す。図５に示すように、ユーザ端末１０、サーバ装置１００、ネットワーク装置２００は、それぞれ上述の正常性試験を定期的又は復旧制御装置３００などの他の装置或いは管理者等の指示に基づき実施し、試験結果情報を復旧制御装置３００に通知する正常性試験機能部１１，１０１，２０１を備える。また、サーバ装置１００及びネットワーク装置２００は、自身のトラヒックを監視し、定期的又は復旧制御装置３００などの他の装置或いは管理者等の指示に基づきトラヒック情報を復旧制御装置３００に通知するトラヒック監視部１２，１０２，２０２を備える。

図６に復旧制御装置３００の構成図を示す。図６に示すように、復旧制御装置３００は、サーバ装置１００・ネットワーク装置２００から収集したトラヒック情報を記憶するトラヒック情報記憶部３１０と、ユーザ端末１０・サーバ装置１００・ネットワーク装置２００から受信した正常性試験の結果情報を記憶する正常性試験結果情報記憶部３２０と、障害発生の原因を特定する障害原因特定部３３０と、障害発生の箇所を特定する障害箇所特定部３４０と、障害から復旧するための制御処理を行う第１の復旧制御部３５０及び第２の復旧制御部３６０とを備える。

本発明における障害発生の原因と障害箇所の特定並びに復旧方法の考え方について図７の表に示す。本発明では、トラヒック情報に基づき、障害発生の原因が内的要因であるか外的要因であるかを判定している。内的要因とはサーバ装置１００又はネットワーク装置２００或いはその通信路に原因があることを意味し、外的要因はトラヒックの急増に原因があることを意味する。内的要因の障害については、再起動により復旧するか否か、またその装置及びレイヤごとに発生箇所が分類でき、それぞれの分類に対して復旧方法が定められる。また、外的要因の障害については、急増したトラヒックの正常か異常か、またその装置毎に、さらに短期的なものか長期的なものかによって分類でき、それぞれの分類に対して、復旧方法が定められる。なお、既存手法は、専ら、図７の表における１行目のもののみをターゲットとしている。

前記障害原因特定部３３０及び障害箇所特定部３４０は図７の表に基づき障害原因特定処理・障害箇所特定処理を行う。また、第１の復旧制御部３５０は、内的要因の障害についての復旧処理を行う。また、第２の復旧制御部３６０は、外的要因の障害についての復旧処理を行うものである。

図８は本発明の障害復旧動作の概要を示すフローチャートである。本処理の開始となる契機（トリガ）としては、アラーム発生、ユーザ申告、定期的な正常性試験が挙げられる。ここで、「アラーム発生」は、サーバ装置１００やネットワーク装置２００等の機器が備えている既存の障害検知システムによる障害発生の警告を契機とするものである。また「ユーザ申告」は、ユーザ端末１０のユーザやその他の利用者等からの申告を契機とするものである。また、「定常的な正常性試験」は、ユーザ端末１０・サーバ装置１００・ネットワーク装置２００の正常性試験機能部１１，１０１，２０１における正常性試験結果の内容（典型的には、障害が生じたとの内容）を契機とするものである。

本発明におけるポイントは、図８に示すように、（ア）トラヒック情報に基づく障害原因被疑の切り分け、（イ）トラヒック急増の原因に基づく対処の変化により、リソースを有効活用（異常系トラヒックでは、増設しない）、（ウ）自動正常性試験の結果に基づく故障個所の切り分け、（エ）まずは簡易な手法（再起動）で復旧しないかを試す、（オ）簡易な手法で復旧しない場合は代替構成でのサービス継続を試みる、という点にある。なお、前記（イ）における「増設」とは、既設の汎用サーバ装置にアプリケーションを設定してサーバ装置１００を構成したり、既設の専用物理装置を設定してネットワーク装置２００を構成したりすることを意味するものであり、新たな物理装置を設置することではない点に留意されたい。

図９〜図１４は本実施の形態に係る障害復旧システムの詳細動作を説明するフローチャートである。復旧制御装置３００は、図９に示すように、収集したトラヒック情報に大きな変動がある場合には、図１０に示すトラヒック変動有りの場合の復旧制御を行う。収集したトラヒック情報に大きな変動がない場合には、ユーザ端末１０・サーバ装置１００間の全ての通信路の正常性試験結果情報に基づき、正常性試験にＮＧがある場合には、図１１に示す通信路が被疑箇所の場合の復旧制御を行う。全ての通信路の正常性試験結果がＯＫの場合には、図１２に示すサーバ装置が被疑箇所である場合の復旧制御を行う。最後に、全てのユーザ端末１０・サーバ装置１００間のアプリケーション正常性の試験結果がＯＫの場合には、復旧処理が完了したものとして処理を終了する。

図１０に示すトラヒック変動有りの場合の復旧制御では、サーバでのログ解析から正常系トラヒックの増大か、或いは、異常系トラヒックの増大かを確認する。異常系トラヒックの増加の場合には、異常トラヒックを所定の待避サイトに向けるようネットワーク装置２００等を制御しつつ、さらに異常系トラヒックの増大が長期的な場合にはプラットフォーム管理者に物理的装置増設要求を通知する。一方、正常系トラヒックの増加の場合には、サーバ装置１００及び／又はネットワーク装置２００を自動的に増加させるように制御処理しつつ、さらに異常系トラヒックの増大が長期的な場合にはプラットフォーム管理者に物理的装置増設要求を通知する。なお、サーバ装置１００の増加制御処理とは、既設の汎用物理サーバ装置上にアプリケーションが動作するようにインストール処理や設定処理を行うことによりサーバ装置１００として機能させることを意味する。また、ネットワーク装置２００の増加制御処理とは、既設の専用物理装置に設定処理を行うことによりネットワーク装置２００として機能させることを意味する。

図１１に示す通信路が被疑箇所の場合の復旧制御では、まず全てのサーバ装置１００単体での通信路の正常性試験結果情報に基づき、正常性試験にＮＧがある場合には、ＮＧとなった全てのサーバ装置１００について、図１３に示すサーバ装置単体の復旧制御処理（通信路）を行う。全てのサーバ装置１００単体での通信路の正常性試験結果がＯＫの場合には、次に、全てのネットワーク装置２００単体での通信路の正常性試験結果情報に基づき、正常性試験にＮＧがある場合には、ＮＧとなった全てのネットワーク装置２００について、図１４に示すネットワーク装置単体の復旧制御処理を行う。全てのネットワーク装置２００単体での通信路の正常性試験結果がＯＫの場合には、次に、全ての隣接する装置間での通信路の正常性試験結果情報に基づき、正常性試験にＮＧがある場合には、ＮＧとなった全てのネットワーク経路について、別ネットワーク経路を設定する。全てのユーザ端末１０・サーバ装置１００間の通信路の正常性試験結果がＯＫの場合には、復旧処理が完了したものとして処理を終了する。ユーザ端末１０・サーバ装置１００間の通信路の正常性試験結果にＮＧがある場合には、処理が無限ループにならないように図１１の処理を継続する。

図１２に示すサーバ装置が被疑箇所である場合の復旧制御では、全てのサーバ装置１００単体でのアプリケーション正常性の試験結果情報に基づき、正常性試験にＮＧがある場合には、ＮＧとなった全てのサーバ装置１００について、図１３に示すサーバ装置単体の復旧制御処理（アプリケーション正常性）を行う。

図１３にサーバ装置単体の復旧制御処理のフローチャートを示す。なお、図１３では説明の簡略化のため、通信路正常性とアプリケーション正常性の両方のケースについてまとめて記載している点に留意されたい。両者の相違点は、正常性試験として、サーバ単体での通信路の正常性試験を実施するのか、サーバ単体でのアプリケーション正常性試験を実施するのか、にある。

サーバ装置単体の復旧制御処理では、図１３に示すように、当該サーバ装置１００についてレイヤ毎に再起動を行い、その都度サーバ装置単体の正常性試験により復旧するかを確認する。当該再起動は上位レイヤから順に行う。全てのレイヤでの再起動処理によっても復旧しない場合、レイヤ毎の代替構成による起動を行い、その都度復旧するかを確認する。ここでレイヤ毎の代替構成による起動は、下位レイヤから順に行う。最後に全てのレイヤを代替構成として起動を行い、復旧するかを確認する。

図１４に示すネットワーク装置単体の復旧制御処理では、サーバ装置単体の復旧制御処理と同様に、当該ネットワーク装置２００についてレイヤ毎に再起動を行い、その都度ネットワーク装置単体の通信路の正常性試験により復旧するかを確認する。当該再起動は上位レイヤから順に行う。全てのレイヤでの再起動処理によっても復旧しない場合、レイヤ毎の代替構成による起動を行い、その都度復旧するかを確認する。ここでレイヤ毎の代替構成による起動は、下位レイヤから順に行う。

以上のように本実施の形態に係る障害復旧システムでは、トラヒック情報及び正常性試験の結果情報に基づき障害発生の原因及び障害箇所の特定を行うので、ハードウェアだけでなく該ハードウェア上の各種ソフトウェアでの障害にも対応することができ、また、ネットワーク全体において障害箇所の切り分け及びそれに伴う障害復旧の自動化が可能となる。

より具体的には、前記ポイント(ア)では、トラヒック情報に基づく障害原因被疑の切り分けを行っているので、トラヒック急増も自動対処できるようになる。そして、最初にトラヒック変動を調べる事で、サービス断の原因が障害かトラヒック急増かを判断する事ができ、原因に応じた自動復旧処理を実施する事ができる。これにより前述の課題３を解決することができる。

また、前記ポイント(イ)では、トラヒック急増の原因に基づく対処の変化により、リソースを有効活用（異常系トラヒックでは、増設しない）するので、原因に応じて対処を変えることでリソース有効活用ができる。すなわち、異常系トラヒックに対してもサーバを増やしてしまうと、真に必要となる正常系トラヒックの処理が逼迫する可能性がある。そこで、異常系トラヒックの場合は別対処とすることでリソースを有効活用するものである。これにより、前述の課題３を解決することができる。

また、前記ポイント(ウ)では、正常性試験の結果に基づく故障個所の切り分けを行っているので、ネットワーク全体の故障個所を自動特定できる。すなわち、正常性試験を行い、その内容に応じて自動的に分析する事で、故障の原因箇所が不明の場合も、自動的に故障個所を特定する事ができる。これにより、前述の課題２を解決することができる。

また、前記ポイント (エ)では、まずは簡易な手法（再起動）で復旧しないかを試しているので、サービス復旧時間を短縮できる。すなわち、簡易な手法から試すことにより、故障復旧までにトライアンドエラーの全体のエラーの時間を減らし、サービス復旧時間を短縮できる。これにより、前述の課題２を解決することができる。

また、ポイント(オ)では、簡易な手法で復旧しない場合は代替構成でのサービス継続を試みるので、ハードウェア以外の多様な障害に網羅的に対処可能である。すなわち、代替構成を使用する事により、ハードウェアより上位のレイヤで障害が発生した場合でも対処する事ができる様になる。また図６に記載した様に故障パターンを網羅的に整理し、復旧するフローを確立する事で、多様な未知の障害に対処する事ができる。これにより、前述の課題１を解決することができる。

以上本発明の一実施の形態について詳述したが、本発明はこれに限定されるものではない。例えば、上記実施の形態では代替構成として、組み合わせ数の増大を防止するため、１つのレイヤを代替構成としたもの及び全てのレイヤの構成を代替構成としたものを用いたが、任意の組み合わせであってもよい。

１０…ユーザ端末
１１…正常性試験機能部
１００…サーバ装置
１０１…正常性試験機能部
１０２…トラヒック監視部
２００…ネットワーク装置
２０１…正常性試験機能部
２０２…トラヒック監視部
３００…復旧制御装置
３１０…トラヒック情報記憶部
３２０…正常性試験結果情報記憶部
３３０…障害原因特定部
３４０…障害箇所特定部
３５０…第１の復旧制御部
３６０…第２の復旧制御部

Claims

仮想化環境が構築され該仮想化環境上でアプリケーションが動作するサーバ装置と、専用物理装置として構成されたネットワーク装置とを備え、前記サーバ装置の前記アプリケーションがユーザ端末にサービスを提供する仮想化されたネットワークにおいて、該ネットワークで発生した障害を復旧させる障害復旧システムであって、
前記障害の発生原因及び発生装置を特定して前記アプリケーションによる前記ユーザ端末に対するサービス提供を継続するよう障害発生装置を復旧制御する復旧制御装置を備え、
前記サーバ装置及び前記ネットワーク装置並びに前記ユーザ端末は、前記アプリケーションの正常性及び通信路の正常性を試験して正常性試験結果情報を前記復旧制御装置に送信する正常性試験手段を備え、
前記サーバ装置及び前記ネットワーク装置は、自身のトラヒックを監視してトラヒック情報を前記復旧制御装置に送信するトラヒック監視手段を備え、
前記復旧制御装置は、
前記トラヒック情報に基づき障害が前記サーバ装置又は前記ネットワーク装置の装置障害によるものか或いはトラヒック増加によるものかを判定する障害原因判定手段と、
装置障害が原因の場合には前記正常性試験結果情報に基づき障害発生装置を特定する障害装置特定手段と、
障害発生装置に対して再起動及び再起動後に正常性試験を実施するよう指示し、障害が復旧しない場合には、予め用意しておいた代替サーバ装置又は代替ネットワーク装置であって障害発生装置と同等の機能を提供するものを障害発生装置の代替として使用するよう制御する第１の復旧制御手段とを備えた
ことを特徴とする障害復旧システム。
前記サーバ装置は、ハードウェア層・ホストＯＳ層・仮想化環境層・ゲストＯＳ層・アプリケーション層からなる階層構造を有し、
前記ネットワーク装置は、ハードウェア層・ファームウェア層からなら階層構造を有し、
前記第１の復旧制御手段は、サーバ装置又はネットワーク装置に対して、障害が復旧するまで、各層ごとに再起動及び正常性試験を実施するよう指示する
ことを特徴とする請求項１記載の障害復旧システム。
前記代替サーバ装置は、ハードウェア層・ホストＯＳ層・仮想化環境層・ゲストＯＳ層・アプリケーション層からなる階層構造を有し、
前記代替ネットワーク装置は、ハードウェア層・ファームウェア層からなら階層構造を有し、
前記第１の復旧制御手段は、各層毎に、当該層においては障害発生装置と同等の機能を提供する他の構成が設定され且つ他の層においては障害発生装置と同一構成が設定された代替サーバ装置又は代替ネットワーク装置の１つを用いて正常性試験を実施するよう指示し、障害が復旧しない場合には、全ての層において障害発生装置と同等の機能を提供する他の構成が設定された代替サーバ装置又は代替ネットワーク装置を用いて正常性試験を実施し、障害が復旧した代替サーバ装置又は代替ネットワーク装置を障害発生装置の代替として使用するよう制御する
ことを特徴とする請求項２記載の障害復旧システム。
前記復旧制御装置は、更に、
障害発生原因がトラヒック増加の場合、トラヒックの迂回或いはサーバ装置又はネットワーク装置の物理的又は論理的な増加による処理能力の向上により障害復旧を行うよう制御する第２の復旧制御手段を備えた
ことを特徴とする請求項１乃至３何れか１項記載の障害復旧システム。
仮想化環境が構築され該仮想化環境上でアプリケーションが動作するサーバ装置と、専用物理装置として構成されたネットワーク装置とを備え、前記サーバ装置の前記アプリケーションがユーザ端末にサービスを提供する仮想化されたネットワークにおいて、復旧制御装置が該ネットワークで発生した障害を復旧させる障害復旧方法であって、
前記サーバ装置及び前記ネットワーク装置並びに前記ユーザ端末は、前記アプリケーションの正常性及び通信路の正常性を試験して正常性試験結果情報を前記復旧制御装置に送信する正常性試験手段を備え、
前記サーバ装置及び前記ネットワーク装置は、自身のトラヒックを監視してトラヒック情報を前記復旧制御装置に送信するトラヒック監視手段を備え、
前記復旧制御装置の障害原因判定手段が、前記トラヒック情報に基づき障害が前記サーバ装置又は前記ネットワーク装置の装置障害によるものか或いはトラヒック増加によるものかを判定し、
前記復旧制御装置の障害装置特定手段が、装置障害が原因の場合には前記正常性試験結果情報に基づき障害発生装置を特定し、
前記復旧制御装置の第１の復旧制御手段が、障害発生装置に対して再起動及び再起動後に正常性試験を実施するよう指示し、障害が復旧しない場合には、予め用意しておいた代替サーバ装置又は代替ネットワーク装置であって障害発生装置と同等の機能を提供するものを障害発生装置の代替として使用するよう制御する
ことを特徴とする障害復旧方法。