ネットワーク障害原因解析方法
【課題】複数のネットワークから構成されているネットワークシステムにおいて、障害が発生した場合、効率的に障害の根本原因およびサービスへの影響範囲を一意に特定可能な方法を提供する。
【解決手段】ネットワーク構成情報を保持している統合管理装置と、警報情報を集約する統合監視装置とを備えているネットワークにおいて、統合監視装置が、障害に関する警報を受信し、警報からアラーム情報を作成し、警報から端点情報を取得し、統合管理装置に端点情報に関連する回線情報を問い合わせ、統合管理装置に回線情報の上位回線および下位回線を問い合わせ、上位回線および下位回線に基づいて、アラーム情報に障害原因フラグを付与することを受信した警報分繰り返し、アラーム情報の障害原因フラグから障害の根本原因を特定する。
【解決手段】ネットワーク構成情報を保持している統合管理装置と、警報情報を集約する統合監視装置とを備えているネットワークにおいて、統合監視装置が、障害に関する警報を受信し、警報からアラーム情報を作成し、警報から端点情報を取得し、統合管理装置に端点情報に関連する回線情報を問い合わせ、統合管理装置に回線情報の上位回線および下位回線を問い合わせ、上位回線および下位回線に基づいて、アラーム情報に障害原因フラグを付与することを受信した警報分繰り返し、アラーム情報の障害原因フラグから障害の根本原因を特定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複雑化するネットワークの中から、障害時に障害原因を一意に特定し、サービスへの影響範囲を特定するための技術に関する。
【背景技術】
【０００２】
現状、ネットワークシステムは複数のネットワークで構成され、エンドエンドでユーザサービスが提供されている。このため、１つの障害（特に伝送網障害など）は複数のサービスや回線に影響を及ぼすだけでなく、この障害により数多くの警報情報が監視装置側に転送される。例えば、物理回線に障害が発生した場合、物理回線からだけでなく、仮想回線等からも警報が転送される。ネットワーク及びサービスの監視において、ネットワークやサービスを監視している運用者はこれらの膨大な警報情報から障害原因の特定や影響するサービスの特定を行わなければならない。しかしながら、これらの多くの警報情報から、障害の原因となる警報を特定したり、影響するサービス（顧客）情報を特定するのは非常に困難である。
【０００３】
このため、障害原因特定手法としては、ネットワークごと・装置ごと・サービスごとに存在する管理装置（ＮＭＳ：Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ ＳｙｓｔｅｍやＥＭＳ：Ｅｌｅｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）内で特定する（図１、特許文献１〜３）手法がある。
【０００４】
また、それらの管理装置が収集した警報またはネットワーク内の装置の警報を、直接上位警報装置（統合監視装置）へ転送し、この警報情報をもとに統合監視装置が特定する手法もある（特許文献４）。
【０００５】
【特許文献１】特開平５−１１４８９９号公報
【特許文献２】特開２００７−１８９６１５号公報
【特許文献３】特開２００７−２３５８９７号公報
【特許文献４】特開２００６−１３６２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、前者の手法では、運用管理者が複数台の管理装置の表示画面を見て、経験を元に解析しているのが現状であり、非常に効率が悪い。複数台の管理装置の表示画面を統合する装置があるが、単に警報を閲覧するだけの機能しかない。後者の手法では、統合監視装置が全てのネットワークノードおよびサービスのインベントリ情報を保持する必要があり、構築するためには膨大な装置となってしまう。
【０００７】
したがって、本発明は複数のネットワークから構成されているネットワークシステムにおいて、障害が発生した場合、効率的に障害の根本原因およびサービスへの影響範囲を一意に特定可能な方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明におけるネットワーク障害原因解析方法によれば、
ネットワーク構成情報を保持している統合管理装置と、警報情報を集約する統合監視装置とを備えているネットワークにおけるネットワーク障害原因解析方法であって、前記統合監視装置が、障害に関する警報を受信し、該警報からアラーム情報を作成するステップと、前記統合監視装置が、前記警報から端点情報を取得し、前記統合管理装置に該端点情報に関連する回線情報を問い合わせるステップと、前記統合監視装置が、前記統合管理装置に前記回線情報の上位回線および下位回線を問い合わせるステップと、前記統合監視装置が、前記上位回線および下位回線に基づいて、アラーム情報に障害原因フラグを付与するステップと、を受信した警報分繰り返し、前記アラーム情報の障害原因フラグから障害の根本原因を特定する。
【０００９】
また、本発明のネットワーク障害原因解析方法における他の実施形態によれば、
前記障害原因フラグを付与するステップは、前記統合監視装置が、前記上位回線のアラーム情報が既に存在するか確認し、存在していた場合、前記上位回線のアラーム情報に非障害原因のフラグを付与し、現在のアラーム情報に障害原因のフラグを付与するサブステップと、前記統合監視装置が、前記下位回線のアラーム情報が既に存在するか確認し、存在していた場合、前記下位回線のアラーム情報に障害原因のフラグを付与し、現在のアラーム情報に非障害原因のフラグを付与するサブステップと、を含み、前記障害原因のフラグのみが付与されたアラーム情報を障害の根本原因と特定する。
【００１０】
また、本発明のネットワーク障害原因解析方法における他の実施形態によれば、
前記統合管理装置は、サービス情報を更に保持しており、前記統合監視装置が、前記統合管理装置に前記回線情報に関するサービス情報を問い合わせるステップと、前記統合監視装置が、前記アラーム情報に前記サービス情報を付与するステップと、をさらに含んでいる。
【発明の効果】
【００１１】
本願発明は、統合管理装置（ＯＳＳ）等が有する構成情報を有効活用することにより、統合監視装置側で構成情報を保持することなく障害の原因究明を行うことが可能となり、システムのスリム化を図ることができる。また、新しいネットワークもしくはサービスを新たに監視対象として追加する場合、構成情報の変更をせず、警報情報のみの登録で使用可能となるために、迅速に監視対象を追加することが可能になる。
【発明を実施するための最良の形態】
【００１２】
本発明を実施するための最良の実施形態について、以下では図面を用いて詳細に説明する。
【００１３】
図２は、本実施形態におけるネットワーク環境と障害管理を示す。本実施形態では、ネットワークＡ、Ｂ、Ｃから構成されるネットワークでユーザ端末間のエンドエンドのサービスを行っている。本ネットワークは、統合管理装置１、統合監視装置２、サービス監視装置３、ネットワーク監視装置４を備えている。
【００１４】
統合管理装置１（ＯＳＳ：Ｏｐｅｒａｔｉｏｎ Ｓｕｐｐｏｒｔ Ｓｙｓｔｅｍ）は、ネットワークノードのサービスの情報を統合的に管理するシステムであり、関連する情報（ネットワーク構成情報及びサービス情報）を全て保持している。
【００１５】
統合監視装置２は、警報情報を集約する装置であり、ネットワーク監視装置４が収集した警報情報、またはネットワーク内の装置が直接送ってくる警報情報を集約する。
【００１６】
サービス監視装置３は、サービスに関する情報を収集し、統合管理装置１に転送する装置である。
【００１７】
ネットワーク監視装置４は、ネットワーク毎に設置されている。対応するネットワークの情報を収集し、ＯＳＳ１に転送している（図２の矢印）。また、障害発生時、対応するネットワークから警報情報を受けとり、統合監視装置２に転送する。
【００１８】
統合監視装置２は、障害発生時、障害原因及びサービスへの影響範囲を特定するための情報をＯＳＳ１から取得し、取得したネットワーク・装置・サービス情報を元に障害原因及びサービスへの影響範囲を特定する。
【００１９】
図３は、統合監視装置２からＯＳＳ１への情報問い合わせを示す。統合監視装置２は警報を受信するたびに、障害根本原因およびサービス影響範囲を特定するため、ＯＳＳ１側に、受信した警報に関する回線情報、その回線を使用しているサービス情報、その回線の上位及び下位に位置している回線情報を取得する。以下のように、２つの装置間で３種類の情報のやり取りが行われる。第１のやり取りは、統合監視装置２が受信した警報情報から取得した端点情報をＯＳＳ１に渡し、ＯＳＳ１が保持する回線情報を取得する「回線情報問合せ」である。第２のやり取りは、取得した回線情報からこの回線情報に関連するサービス情報をＯＳＳ１から収集する「サービス情報問合せ」である。第３のやり取りは、取得した回線情報からこの回線の上下に位置している回線情報を特定する「上下回線情報問合せ」である。
【００２０】
統合監視装置２は、収集した情報を基に、警報情報に「サービス情報」、「障害原因フラグ」を付加し、最終的にその付加情報により障害根本原因およびサービス影響範囲を特定する。
【００２１】
なお、サービス情報を取得する第２のやり取りは、障害によるサービス影響範囲を特定するために必要であり、障害の根本原因のみを特定するときは、このやり取りを省略することが可能である。
【００２２】
また、サービス情報を取得する第２のやり取りは、ＯＳＳ１からではなく、サービスを管理している管理装置から取得することも可能である。
【００２３】
図４および図５は、統合監視装置２が障害根本原因およびサービス影響範囲を特定するためのフローチャートである。なお、このフローチャートは、統合監視装置２が受信した警報１つ１つに対して動作する。
（Ｓ１）ネットワーク内の装置、サービス監視装置３またはネットワーク監視装置４から警報情報が統合監視装置２に送出される。
（Ｓ２）統合監視装置２が、それらの警報情報を受信する。
（Ｓ３）統合監視装置２が、受信した警報情報をアラーム情報として登録する（警報情報を装置内のデータベースに登録する）。
（Ｓ４）統合監視装置２は、警報情報に含まれる装置の端点情報を特定する。例えば、ルータなどのインターフェース障害の場合、障害箇所のインターフェース情報（ルータのＩＰアドレス）が警報情報に含まれている。
（Ｓ５）統合監視装置２は、端点情報に関連する回線情報をＯＳＳ１側に問合せを行う。回線情報とは、物理端点（物理インターフェース）、論理端点（ＩＰアドレス）に関係する物理リンク、ＩＰリンク、Ｅｔｈｅｒｎｅｔ（登録商標）リンク、ＭＰＬＳパスを示す。
（Ｓ６）ＯＳＳ１は、取得した端点情報を基に、自分が保持するデータベースを検索し、関係する回線情報を特定する。特定後、その情報を統合監視装置２側へ返送する。回線情報の内容は、回線名（回線ＩＤ）、両端の装置名、物理（論理）端点などであり、ＯＳＳ１が保持する情報を全て取得可能である。
（Ｓ７）統合監視装置２が、ＯＳＳ１側から送信された回線情報を受信し、アラーム情報に付加する。
（Ｓ８）統合監視装置２が、受信した警報がどのサービスに関連するかを特定するため、回線を一意に特定する回線ＩＤ（回線名）をキーに、サービス情報取得要求をＯＳＳ１もしくはサービスを管理している管理装置に要求する。
（Ｓ９）ＯＳＳ１もしくはサービスを管理している管理装置は、統合監視装置２から受信した回線ＩＤ（回線名）を基に、装置内のデータベースを検索し、関連するサービス情報を特定する。例えば、ＭＰＬＳパスの情報に関して、ＭＰＬＳパスを利用しているイーサＶＰＮ等のサービス名、ＭＰＬＳパスを使用している顧客情報等のサービス情報が特定される。特定後、その情報を統合監視装置２側へ返送する。
（Ｓ１０）統合監視装置２は、サービス情報を受信する。
（Ｓ１１）統合監視装置２は、受信したサービス情報をアラーム情報に付加する。これにより、受信した警報情報が、どのサービスに影響を及ぼしているかを特定することができる。
（Ｓ１２）統合監視装置２は、該当回線の上位に位置する回線情報を取得するため、ＯＳＳ１側に回線ＩＤ（回線名）をキーに上位回線情報取得要求を行う。
（Ｓ１３）ＯＳＳ１は、統合監視装置２から受信し取得した回線ＩＤ（回線名）をキーに、装置内のデータベースを検索し、回線ＩＤ（回線名）の上位に位置する回線情報を特定する。特定後、上位回線情報を統合監視装置２側へ返送する。
（Ｓ１４）統合監視装置２は、上位の回線情報を受信する。
（Ｓ１５）統合監視装置２は、受信した上位の回線情報に関係するアラーム情報を既に取得しているか否かを確認する。つまり、統合監視装置２が保持しているアラーム情報の中に、上位の回線情報の回線ＩＤ（回線名）に関するアラーム情報があるかどうかを確認する。保持している場合には（Ｓ１６）に、保持ない場合には（Ｓ１７）に移行する。なお、上位回線がない場合は、（Ｓ１７）に移行する。
（Ｓ１６）統合監視装置２は、上位回線のアラーム情報を既に取得している場合、上位回線に関係するアラーム情報に障害の根本原因ではないことを示す「非障害原因」というフラグ（識別子）を付加する。また、ここで解析中のアラーム情報には根本原因であることを示す「障害原因」というフラグを付加する。
（Ｓ１７）統合監視装置２は、該当回線の下位に位置する回線情報を取得するため、ＯＳＳ１側に回線ＩＤ（回線名）をキーに下位回線情報取得要求を行う。
（Ｓ１８）ＯＳＳ１は、統合監視装置２から受信し取得した回線ＩＤ（回線名）をキーに、装置内のデータベースを検索し、回線ＩＤ（回線名）の下位に位置する回線情報を特定する。特定後、下位回線情報を統合監視装置２側へ返送する。
（Ｓ１９）統合監視装置２は、下位の回線情報を受信する。
（Ｓ２０）統合監視装置２は、受信した下位の回線情報に関係するアラーム情報を既に取得しているか否かを確認する。つまり、統合監視装置２が保持しているアラーム情報の中に、下位の回線情報の回線ＩＤ（回線名）に関するアラーム情報があるかどうかを確認する。保持している場合には（Ｓ２１）に、保持ない場合には（Ｓ２２）に移行する。なお、下位回線がない場合は、（Ｓ２２）に移行する。
（Ｓ２１）統合監視装置２は、下位回線のアラーム情報を既に取得している場合、下位回線に関係するアラーム情報に障害の根本原因であることを示す「障害原因」というフラグ（識別子）を付加する。また、ここで解析中のアラーム情報には障害の根本原因ではないことを示す「非障害原因」というフラグを付加する。
（Ｓ２２）終了
なお、ネットワーク内にＯＳＳ１が複数ある場合は、複数台のＯＳＳ１に問い合わせを行う。ＯＳＳ１が機能別にサービスを管理するＯＳＳ１、ネットワークの構成を管理するＯＳＳ１と複数ある場合、問い合わせに必要なＯＳＳ１に問い合わせを行う。
【００２４】
上記のＳ１からＳ２２を受信した警報分繰り返す。警報分アラーム情報が統合監視装置２内に作成される。このアラーム情報から「障害原因」というフラグのみが付与されたアラーム情報を検索する。この検索されたアラーム情報が障害の根本原因であり、その他のアラーム情報は、根本原因の障害により影響を受け通知されたものと判明する。
【００２５】
また、アラーム情報には、サービス情報が付与されているため、障害によるサービス影響範囲を特定することが可能になる。
【００２６】
次に、以上のフローチャートの具体例を示す。例えば、ルータ間にＩＰリンクが張られ、ＭＰＬＳパスがこのＩＰリンクを使用して、ＭＰＬＳパス上にＩＰ−ＶＰＮが提供されている場合を考える。この場合、ＩＰリンクに障害が発生した場合、３つの警報が通知される。第１はＩＰリンクからの警報であり、第２はＭＰＬＳパスからの警報であり、第３はＩＰ−ＶＰＮからの警報である。
【００２７】
まず、第２の警報（ＭＰＬＳパスの警報）が来た場合、統合監視装置２はこの警報情報からアラーム情報を作成する（Ｓ３〜Ｓ１１）。Ｓ１２で上位回線を問い合わせ、上位回線がＩＰ−ＶＰＮであることを取得する。Ｓ１５で既存のアラームにＩＰ−ＶＰＮのアラームがあるかどうか確認するが無いため、フラグの設定は行わない。次にＳ１７で下位回線を問い合わせ、下位回線がＩＰリンクであることを取得する。Ｓ２０で既存のアラームにＩＰリンクのアラームがあるかどうか確認するが無いため、フラグの設定は行わない。これで、このアラームに対する処理は終了する。
【００２８】
次に、第１の警報（ＩＰリンクの警報）が来た場合、統合監視装置２はこの警報情報からアラーム情報を作成する（Ｓ３〜Ｓ１１）。Ｓ１２で上位回線を問い合わせ、上位回線がＭＰＬＳパスであることを取得する。Ｓ１５で既存のアラームにＭＰＬＳパスのアラームがあるかどうか確認する。このアラームは既に存在するため、Ｓ１６に進み、ＭＰＬＳパスのアラームに「非障害原因」というフラグを付加し、ＩＰリンクのアラームに「障害原因」というフラグを付与する。次にＳ１７で下位回線を問い合わせるが、下位回線は存在しないため、Ｓ２０の判定は必ずＮＯになり、このアラームに対する処理は終了する。
【００２９】
最後に、第３の警報（ＩＰ−ＶＰＮの警報）が来た場合、統合監視装置２はこの警報情報からアラーム情報を作成する（Ｓ３〜Ｓ１１）。Ｓ１２で上位回線を問い合わせるが、上位回線がないため、Ｓ１５の判定は必ずＮＯになる。次にＳ１７で下位回線を問い合わせ、下位回線がＭＰＬＳパスであることを取得する。Ｓ２０で既存のアラームにＭＰＬＳパスのアラームがあるかどうか確認する。このアラームは既に存在するため、Ｓ２１に進み、ＭＰＬＳパスのアラームに「障害原因」というフラグを付加し、ＩＰ−ＶＰＮのアラームに「非障害原因」というフラグを付与する。
【００３０】
以上の結果により、ＩＰリンクのアラームは「障害原因」のフラグが付与され、ＭＰＬＳパスのアラームは「非障害原因」および「障害原因」のフラグが付与され、ＩＰ−ＶＰＮのアラームに「非障害原因」のフラグが付与される。ここで「障害原因」のフラグのみが付与されたアラームは、ＩＰリンクのアラームであるため、障害の根本原因がＩＰリンクの障害であることが判明する。
【００３１】
なお、本例では、第２の警報、第１の警報、第３の警報の順に、警報が統合監視装置２に来た場合であるが、この順序以外でも障害の根本原因がＩＰリンクの障害という同じ結果になる。
【００３２】
また、ＭＰＬＳパスに論理的な障害が発生した場合、ＭＰＬＳパスからの警報とＩＰ−ＶＰＮからの警報が発生し、統合監視装置２内では、ＭＰＬＳパスのアラームは「障害原因」のフラグが付与されるため、障害の根本原因がＭＰＬＳパスの障害であることが判明する。
【００３３】
また、以上述べた実施形態は全て本発明を例示的に示すものであって限定的に示すものではなく、本発明は他の種々の変形態様および変更態様で実施することができる。従って本発明の範囲は特許請求の範囲およびその均等範囲によってのみ規定されるものである。
【図面の簡単な説明】
【００３４】
【図１】現状のネットワーク環境と障害管理を示す。
【図２】本実施形態におけるネットワーク環境と障害管理を示す。
【図３】統合監視装置から統合管理装置への情報問い合わせを示す。
【図４】統合監視装置が障害根本原因およびサービス影響範囲を特定するためのフローチャートである。
【図５】統合監視装置が障害根本原因およびサービス影響範囲を特定するためのフローチャートである（続き）。
【符号の説明】
【００３５】
１ 統合管理装置（ＯＳＳ）
２ 統合監視装置
３ サービス監視装置
４ ネットワーク監視装置
【技術分野】
【０００１】
本発明は、複雑化するネットワークの中から、障害時に障害原因を一意に特定し、サービスへの影響範囲を特定するための技術に関する。
【背景技術】
【０００２】
現状、ネットワークシステムは複数のネットワークで構成され、エンドエンドでユーザサービスが提供されている。このため、１つの障害（特に伝送網障害など）は複数のサービスや回線に影響を及ぼすだけでなく、この障害により数多くの警報情報が監視装置側に転送される。例えば、物理回線に障害が発生した場合、物理回線からだけでなく、仮想回線等からも警報が転送される。ネットワーク及びサービスの監視において、ネットワークやサービスを監視している運用者はこれらの膨大な警報情報から障害原因の特定や影響するサービスの特定を行わなければならない。しかしながら、これらの多くの警報情報から、障害の原因となる警報を特定したり、影響するサービス（顧客）情報を特定するのは非常に困難である。
【０００３】
このため、障害原因特定手法としては、ネットワークごと・装置ごと・サービスごとに存在する管理装置（ＮＭＳ：Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ ＳｙｓｔｅｍやＥＭＳ：Ｅｌｅｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）内で特定する（図１、特許文献１〜３）手法がある。
【０００４】
また、それらの管理装置が収集した警報またはネットワーク内の装置の警報を、直接上位警報装置（統合監視装置）へ転送し、この警報情報をもとに統合監視装置が特定する手法もある（特許文献４）。
【０００５】
【特許文献１】特開平５−１１４８９９号公報
【特許文献２】特開２００７−１８９６１５号公報
【特許文献３】特開２００７−２３５８９７号公報
【特許文献４】特開２００６−１３６２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、前者の手法では、運用管理者が複数台の管理装置の表示画面を見て、経験を元に解析しているのが現状であり、非常に効率が悪い。複数台の管理装置の表示画面を統合する装置があるが、単に警報を閲覧するだけの機能しかない。後者の手法では、統合監視装置が全てのネットワークノードおよびサービスのインベントリ情報を保持する必要があり、構築するためには膨大な装置となってしまう。
【０００７】
したがって、本発明は複数のネットワークから構成されているネットワークシステムにおいて、障害が発生した場合、効率的に障害の根本原因およびサービスへの影響範囲を一意に特定可能な方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明におけるネットワーク障害原因解析方法によれば、
ネットワーク構成情報を保持している統合管理装置と、警報情報を集約する統合監視装置とを備えているネットワークにおけるネットワーク障害原因解析方法であって、前記統合監視装置が、障害に関する警報を受信し、該警報からアラーム情報を作成するステップと、前記統合監視装置が、前記警報から端点情報を取得し、前記統合管理装置に該端点情報に関連する回線情報を問い合わせるステップと、前記統合監視装置が、前記統合管理装置に前記回線情報の上位回線および下位回線を問い合わせるステップと、前記統合監視装置が、前記上位回線および下位回線に基づいて、アラーム情報に障害原因フラグを付与するステップと、を受信した警報分繰り返し、前記アラーム情報の障害原因フラグから障害の根本原因を特定する。
【０００９】
また、本発明のネットワーク障害原因解析方法における他の実施形態によれば、
前記障害原因フラグを付与するステップは、前記統合監視装置が、前記上位回線のアラーム情報が既に存在するか確認し、存在していた場合、前記上位回線のアラーム情報に非障害原因のフラグを付与し、現在のアラーム情報に障害原因のフラグを付与するサブステップと、前記統合監視装置が、前記下位回線のアラーム情報が既に存在するか確認し、存在していた場合、前記下位回線のアラーム情報に障害原因のフラグを付与し、現在のアラーム情報に非障害原因のフラグを付与するサブステップと、を含み、前記障害原因のフラグのみが付与されたアラーム情報を障害の根本原因と特定する。
【００１０】
また、本発明のネットワーク障害原因解析方法における他の実施形態によれば、
前記統合管理装置は、サービス情報を更に保持しており、前記統合監視装置が、前記統合管理装置に前記回線情報に関するサービス情報を問い合わせるステップと、前記統合監視装置が、前記アラーム情報に前記サービス情報を付与するステップと、をさらに含んでいる。
【発明の効果】
【００１１】
本願発明は、統合管理装置（ＯＳＳ）等が有する構成情報を有効活用することにより、統合監視装置側で構成情報を保持することなく障害の原因究明を行うことが可能となり、システムのスリム化を図ることができる。また、新しいネットワークもしくはサービスを新たに監視対象として追加する場合、構成情報の変更をせず、警報情報のみの登録で使用可能となるために、迅速に監視対象を追加することが可能になる。
【発明を実施するための最良の形態】
【００１２】
本発明を実施するための最良の実施形態について、以下では図面を用いて詳細に説明する。
【００１３】
図２は、本実施形態におけるネットワーク環境と障害管理を示す。本実施形態では、ネットワークＡ、Ｂ、Ｃから構成されるネットワークでユーザ端末間のエンドエンドのサービスを行っている。本ネットワークは、統合管理装置１、統合監視装置２、サービス監視装置３、ネットワーク監視装置４を備えている。
【００１４】
統合管理装置１（ＯＳＳ：Ｏｐｅｒａｔｉｏｎ Ｓｕｐｐｏｒｔ Ｓｙｓｔｅｍ）は、ネットワークノードのサービスの情報を統合的に管理するシステムであり、関連する情報（ネットワーク構成情報及びサービス情報）を全て保持している。
【００１５】
統合監視装置２は、警報情報を集約する装置であり、ネットワーク監視装置４が収集した警報情報、またはネットワーク内の装置が直接送ってくる警報情報を集約する。
【００１６】
サービス監視装置３は、サービスに関する情報を収集し、統合管理装置１に転送する装置である。
【００１７】
ネットワーク監視装置４は、ネットワーク毎に設置されている。対応するネットワークの情報を収集し、ＯＳＳ１に転送している（図２の矢印）。また、障害発生時、対応するネットワークから警報情報を受けとり、統合監視装置２に転送する。
【００１８】
統合監視装置２は、障害発生時、障害原因及びサービスへの影響範囲を特定するための情報をＯＳＳ１から取得し、取得したネットワーク・装置・サービス情報を元に障害原因及びサービスへの影響範囲を特定する。
【００１９】
図３は、統合監視装置２からＯＳＳ１への情報問い合わせを示す。統合監視装置２は警報を受信するたびに、障害根本原因およびサービス影響範囲を特定するため、ＯＳＳ１側に、受信した警報に関する回線情報、その回線を使用しているサービス情報、その回線の上位及び下位に位置している回線情報を取得する。以下のように、２つの装置間で３種類の情報のやり取りが行われる。第１のやり取りは、統合監視装置２が受信した警報情報から取得した端点情報をＯＳＳ１に渡し、ＯＳＳ１が保持する回線情報を取得する「回線情報問合せ」である。第２のやり取りは、取得した回線情報からこの回線情報に関連するサービス情報をＯＳＳ１から収集する「サービス情報問合せ」である。第３のやり取りは、取得した回線情報からこの回線の上下に位置している回線情報を特定する「上下回線情報問合せ」である。
【００２０】
統合監視装置２は、収集した情報を基に、警報情報に「サービス情報」、「障害原因フラグ」を付加し、最終的にその付加情報により障害根本原因およびサービス影響範囲を特定する。
【００２１】
なお、サービス情報を取得する第２のやり取りは、障害によるサービス影響範囲を特定するために必要であり、障害の根本原因のみを特定するときは、このやり取りを省略することが可能である。
【００２２】
また、サービス情報を取得する第２のやり取りは、ＯＳＳ１からではなく、サービスを管理している管理装置から取得することも可能である。
【００２３】
図４および図５は、統合監視装置２が障害根本原因およびサービス影響範囲を特定するためのフローチャートである。なお、このフローチャートは、統合監視装置２が受信した警報１つ１つに対して動作する。
（Ｓ１）ネットワーク内の装置、サービス監視装置３またはネットワーク監視装置４から警報情報が統合監視装置２に送出される。
（Ｓ２）統合監視装置２が、それらの警報情報を受信する。
（Ｓ３）統合監視装置２が、受信した警報情報をアラーム情報として登録する（警報情報を装置内のデータベースに登録する）。
（Ｓ４）統合監視装置２は、警報情報に含まれる装置の端点情報を特定する。例えば、ルータなどのインターフェース障害の場合、障害箇所のインターフェース情報（ルータのＩＰアドレス）が警報情報に含まれている。
（Ｓ５）統合監視装置２は、端点情報に関連する回線情報をＯＳＳ１側に問合せを行う。回線情報とは、物理端点（物理インターフェース）、論理端点（ＩＰアドレス）に関係する物理リンク、ＩＰリンク、Ｅｔｈｅｒｎｅｔ（登録商標）リンク、ＭＰＬＳパスを示す。
（Ｓ６）ＯＳＳ１は、取得した端点情報を基に、自分が保持するデータベースを検索し、関係する回線情報を特定する。特定後、その情報を統合監視装置２側へ返送する。回線情報の内容は、回線名（回線ＩＤ）、両端の装置名、物理（論理）端点などであり、ＯＳＳ１が保持する情報を全て取得可能である。
（Ｓ７）統合監視装置２が、ＯＳＳ１側から送信された回線情報を受信し、アラーム情報に付加する。
（Ｓ８）統合監視装置２が、受信した警報がどのサービスに関連するかを特定するため、回線を一意に特定する回線ＩＤ（回線名）をキーに、サービス情報取得要求をＯＳＳ１もしくはサービスを管理している管理装置に要求する。
（Ｓ９）ＯＳＳ１もしくはサービスを管理している管理装置は、統合監視装置２から受信した回線ＩＤ（回線名）を基に、装置内のデータベースを検索し、関連するサービス情報を特定する。例えば、ＭＰＬＳパスの情報に関して、ＭＰＬＳパスを利用しているイーサＶＰＮ等のサービス名、ＭＰＬＳパスを使用している顧客情報等のサービス情報が特定される。特定後、その情報を統合監視装置２側へ返送する。
（Ｓ１０）統合監視装置２は、サービス情報を受信する。
（Ｓ１１）統合監視装置２は、受信したサービス情報をアラーム情報に付加する。これにより、受信した警報情報が、どのサービスに影響を及ぼしているかを特定することができる。
（Ｓ１２）統合監視装置２は、該当回線の上位に位置する回線情報を取得するため、ＯＳＳ１側に回線ＩＤ（回線名）をキーに上位回線情報取得要求を行う。
（Ｓ１３）ＯＳＳ１は、統合監視装置２から受信し取得した回線ＩＤ（回線名）をキーに、装置内のデータベースを検索し、回線ＩＤ（回線名）の上位に位置する回線情報を特定する。特定後、上位回線情報を統合監視装置２側へ返送する。
（Ｓ１４）統合監視装置２は、上位の回線情報を受信する。
（Ｓ１５）統合監視装置２は、受信した上位の回線情報に関係するアラーム情報を既に取得しているか否かを確認する。つまり、統合監視装置２が保持しているアラーム情報の中に、上位の回線情報の回線ＩＤ（回線名）に関するアラーム情報があるかどうかを確認する。保持している場合には（Ｓ１６）に、保持ない場合には（Ｓ１７）に移行する。なお、上位回線がない場合は、（Ｓ１７）に移行する。
（Ｓ１６）統合監視装置２は、上位回線のアラーム情報を既に取得している場合、上位回線に関係するアラーム情報に障害の根本原因ではないことを示す「非障害原因」というフラグ（識別子）を付加する。また、ここで解析中のアラーム情報には根本原因であることを示す「障害原因」というフラグを付加する。
（Ｓ１７）統合監視装置２は、該当回線の下位に位置する回線情報を取得するため、ＯＳＳ１側に回線ＩＤ（回線名）をキーに下位回線情報取得要求を行う。
（Ｓ１８）ＯＳＳ１は、統合監視装置２から受信し取得した回線ＩＤ（回線名）をキーに、装置内のデータベースを検索し、回線ＩＤ（回線名）の下位に位置する回線情報を特定する。特定後、下位回線情報を統合監視装置２側へ返送する。
（Ｓ１９）統合監視装置２は、下位の回線情報を受信する。
（Ｓ２０）統合監視装置２は、受信した下位の回線情報に関係するアラーム情報を既に取得しているか否かを確認する。つまり、統合監視装置２が保持しているアラーム情報の中に、下位の回線情報の回線ＩＤ（回線名）に関するアラーム情報があるかどうかを確認する。保持している場合には（Ｓ２１）に、保持ない場合には（Ｓ２２）に移行する。なお、下位回線がない場合は、（Ｓ２２）に移行する。
（Ｓ２１）統合監視装置２は、下位回線のアラーム情報を既に取得している場合、下位回線に関係するアラーム情報に障害の根本原因であることを示す「障害原因」というフラグ（識別子）を付加する。また、ここで解析中のアラーム情報には障害の根本原因ではないことを示す「非障害原因」というフラグを付加する。
（Ｓ２２）終了
なお、ネットワーク内にＯＳＳ１が複数ある場合は、複数台のＯＳＳ１に問い合わせを行う。ＯＳＳ１が機能別にサービスを管理するＯＳＳ１、ネットワークの構成を管理するＯＳＳ１と複数ある場合、問い合わせに必要なＯＳＳ１に問い合わせを行う。
【００２４】
上記のＳ１からＳ２２を受信した警報分繰り返す。警報分アラーム情報が統合監視装置２内に作成される。このアラーム情報から「障害原因」というフラグのみが付与されたアラーム情報を検索する。この検索されたアラーム情報が障害の根本原因であり、その他のアラーム情報は、根本原因の障害により影響を受け通知されたものと判明する。
【００２５】
また、アラーム情報には、サービス情報が付与されているため、障害によるサービス影響範囲を特定することが可能になる。
【００２６】
次に、以上のフローチャートの具体例を示す。例えば、ルータ間にＩＰリンクが張られ、ＭＰＬＳパスがこのＩＰリンクを使用して、ＭＰＬＳパス上にＩＰ−ＶＰＮが提供されている場合を考える。この場合、ＩＰリンクに障害が発生した場合、３つの警報が通知される。第１はＩＰリンクからの警報であり、第２はＭＰＬＳパスからの警報であり、第３はＩＰ−ＶＰＮからの警報である。
【００２７】
まず、第２の警報（ＭＰＬＳパスの警報）が来た場合、統合監視装置２はこの警報情報からアラーム情報を作成する（Ｓ３〜Ｓ１１）。Ｓ１２で上位回線を問い合わせ、上位回線がＩＰ−ＶＰＮであることを取得する。Ｓ１５で既存のアラームにＩＰ−ＶＰＮのアラームがあるかどうか確認するが無いため、フラグの設定は行わない。次にＳ１７で下位回線を問い合わせ、下位回線がＩＰリンクであることを取得する。Ｓ２０で既存のアラームにＩＰリンクのアラームがあるかどうか確認するが無いため、フラグの設定は行わない。これで、このアラームに対する処理は終了する。
【００２８】
次に、第１の警報（ＩＰリンクの警報）が来た場合、統合監視装置２はこの警報情報からアラーム情報を作成する（Ｓ３〜Ｓ１１）。Ｓ１２で上位回線を問い合わせ、上位回線がＭＰＬＳパスであることを取得する。Ｓ１５で既存のアラームにＭＰＬＳパスのアラームがあるかどうか確認する。このアラームは既に存在するため、Ｓ１６に進み、ＭＰＬＳパスのアラームに「非障害原因」というフラグを付加し、ＩＰリンクのアラームに「障害原因」というフラグを付与する。次にＳ１７で下位回線を問い合わせるが、下位回線は存在しないため、Ｓ２０の判定は必ずＮＯになり、このアラームに対する処理は終了する。
【００２９】
最後に、第３の警報（ＩＰ−ＶＰＮの警報）が来た場合、統合監視装置２はこの警報情報からアラーム情報を作成する（Ｓ３〜Ｓ１１）。Ｓ１２で上位回線を問い合わせるが、上位回線がないため、Ｓ１５の判定は必ずＮＯになる。次にＳ１７で下位回線を問い合わせ、下位回線がＭＰＬＳパスであることを取得する。Ｓ２０で既存のアラームにＭＰＬＳパスのアラームがあるかどうか確認する。このアラームは既に存在するため、Ｓ２１に進み、ＭＰＬＳパスのアラームに「障害原因」というフラグを付加し、ＩＰ−ＶＰＮのアラームに「非障害原因」というフラグを付与する。
【００３０】
以上の結果により、ＩＰリンクのアラームは「障害原因」のフラグが付与され、ＭＰＬＳパスのアラームは「非障害原因」および「障害原因」のフラグが付与され、ＩＰ−ＶＰＮのアラームに「非障害原因」のフラグが付与される。ここで「障害原因」のフラグのみが付与されたアラームは、ＩＰリンクのアラームであるため、障害の根本原因がＩＰリンクの障害であることが判明する。
【００３１】
なお、本例では、第２の警報、第１の警報、第３の警報の順に、警報が統合監視装置２に来た場合であるが、この順序以外でも障害の根本原因がＩＰリンクの障害という同じ結果になる。
【００３２】
また、ＭＰＬＳパスに論理的な障害が発生した場合、ＭＰＬＳパスからの警報とＩＰ−ＶＰＮからの警報が発生し、統合監視装置２内では、ＭＰＬＳパスのアラームは「障害原因」のフラグが付与されるため、障害の根本原因がＭＰＬＳパスの障害であることが判明する。
【００３３】
また、以上述べた実施形態は全て本発明を例示的に示すものであって限定的に示すものではなく、本発明は他の種々の変形態様および変更態様で実施することができる。従って本発明の範囲は特許請求の範囲およびその均等範囲によってのみ規定されるものである。
【図面の簡単な説明】
【００３４】
【図１】現状のネットワーク環境と障害管理を示す。
【図２】本実施形態におけるネットワーク環境と障害管理を示す。
【図３】統合監視装置から統合管理装置への情報問い合わせを示す。
【図４】統合監視装置が障害根本原因およびサービス影響範囲を特定するためのフローチャートである。
【図５】統合監視装置が障害根本原因およびサービス影響範囲を特定するためのフローチャートである（続き）。
【符号の説明】
【００３５】
１ 統合管理装置（ＯＳＳ）
２ 統合監視装置
３ サービス監視装置
４ ネットワーク監視装置
【特許請求の範囲】
【請求項１】
ネットワーク構成情報を保持している統合管理装置と、警報情報を集約する統合監視装置とを備えているネットワークにおけるネットワーク障害原因解析方法であって、
前記統合監視装置が、障害に関する警報を受信し、該警報からアラーム情報を作成するステップと、
前記統合監視装置が、前記警報から端点情報を取得し、前記統合管理装置に該端点情報に関連する回線情報を問い合わせるステップと、
前記統合監視装置が、前記統合管理装置に前記回線情報の上位回線および下位回線を問い合わせるステップと、
前記統合監視装置が、前記上位回線および下位回線に基づいて、アラーム情報に障害原因フラグを付与するステップと、
を受信した警報分繰り返し、前記アラーム情報の障害原因フラグから障害の根本原因を特定することを特徴とするネットワーク障害原因解析方法。
【請求項２】
前記障害原因フラグを付与するステップは、
前記統合監視装置が、前記上位回線のアラーム情報が既に存在するか確認し、存在していた場合、前記上位回線のアラーム情報に非障害原因のフラグを付与し、現在のアラーム情報に障害原因のフラグを付与するサブステップと、
前記統合監視装置が、前記下位回線のアラーム情報が既に存在するか確認し、存在していた場合、前記下位回線のアラーム情報に障害原因のフラグを付与し、現在のアラーム情報に非障害原因のフラグを付与するサブステップと、
を含み、前記障害原因のフラグのみが付与されたアラーム情報を障害の根本原因と特定することを特徴とする請求項１に記載のネットワーク障害原因解析方法。
【請求項３】
前記統合管理装置は、サービス情報を更に保持しており、
前記統合監視装置が、前記統合管理装置に前記回線情報に関するサービス情報を問い合わせるステップと、
前記統合監視装置が、前記アラーム情報に前記サービス情報を付与するステップと、
をさらに含んでいることを特徴とする請求項１または２に記載のネットワーク障害原因解析方法。
【請求項１】
ネットワーク構成情報を保持している統合管理装置と、警報情報を集約する統合監視装置とを備えているネットワークにおけるネットワーク障害原因解析方法であって、
前記統合監視装置が、障害に関する警報を受信し、該警報からアラーム情報を作成するステップと、
前記統合監視装置が、前記警報から端点情報を取得し、前記統合管理装置に該端点情報に関連する回線情報を問い合わせるステップと、
前記統合監視装置が、前記統合管理装置に前記回線情報の上位回線および下位回線を問い合わせるステップと、
前記統合監視装置が、前記上位回線および下位回線に基づいて、アラーム情報に障害原因フラグを付与するステップと、
を受信した警報分繰り返し、前記アラーム情報の障害原因フラグから障害の根本原因を特定することを特徴とするネットワーク障害原因解析方法。
【請求項２】
前記障害原因フラグを付与するステップは、
前記統合監視装置が、前記上位回線のアラーム情報が既に存在するか確認し、存在していた場合、前記上位回線のアラーム情報に非障害原因のフラグを付与し、現在のアラーム情報に障害原因のフラグを付与するサブステップと、
前記統合監視装置が、前記下位回線のアラーム情報が既に存在するか確認し、存在していた場合、前記下位回線のアラーム情報に障害原因のフラグを付与し、現在のアラーム情報に非障害原因のフラグを付与するサブステップと、
を含み、前記障害原因のフラグのみが付与されたアラーム情報を障害の根本原因と特定することを特徴とする請求項１に記載のネットワーク障害原因解析方法。
【請求項３】
前記統合管理装置は、サービス情報を更に保持しており、
前記統合監視装置が、前記統合管理装置に前記回線情報に関するサービス情報を問い合わせるステップと、
前記統合監視装置が、前記アラーム情報に前記サービス情報を付与するステップと、
をさらに含んでいることを特徴とする請求項１または２に記載のネットワーク障害原因解析方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００９−２４６６７９（Ｐ２００９−２４６６７９Ａ）
【公開日】平成２１年１０月２２日（２００９．１０．２２）
【国際特許分類】
【出願番号】特願２００８−９０７８３（Ｐ２００８−９０７８３）
【出願日】平成２０年３月３１日（２００８．３．３１）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
【公開日】平成２１年１０月２２日（２００９．１０．２２）
【国際特許分類】
【出願日】平成２０年３月３１日（２００８．３．３１）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
[ Back to top ]