(57)【要約】【課題】管理システムへ通知するアラーム数を削減し、アラーム障害を検知して管理システムへ通知できるアラーム処理システムを提供する。【解決手段】ノード装置INM1の装置IDよりもノード装置INM2の装置IDが若番であると、ノード装置INM1は、ステップＳ５，Ｓ６においてノード装置INM2のアラームDB２２への接続を試行し、接続できればステップＳ７へ進み、ノード装置INM2のアラームDB２２に同一アラームが重複登録されているか否かを判定する。アラーム１が重複登録されていればステップＳ１０へ進み、ノード装置INM2のアラームDB２２において、前記アラーム１と対応付けられた同一レコードの隣接確認フラグFnがセットされる。ステップＳ１１では、ノード装置INM1のアラームDB２２から前記重複登録されていたアラーム１が削除される。【選択図】図３
2015029194.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークのノード装置上でアラーム情報を分散処理するアラーム処理システムにおいて、
ネットワークトポロジおよび各ノード装置のIDを管理する構成管理手段と、
ノード装置により検知されたアラーム情報を蓄積するアラームDBと、
前記ネットワークトポロジに基づいて隣接装置を識別する手段と、
相互に隣接するノード装置の一方が他方のノード装置のアラームDBを参照し、前記アラーム情報と同一のアラーム情報が登録されていれば自装置のアラームDBから前記アラーム情報を削除する手段と、
アラームDBに蓄積されているアラーム情報を前記管理システムへ送信する手段とを具備したことを特徴とするアラーム処理システム。
【請求項２】
前記一方のノード装置は、前記他方のノード装置のアラームDBに前記アラーム情報と同一のアラーム情報が登録されていると当該アラーム情報に隣接確認フラグをセットし、前記他方のノード装置は、当該アラームを前記隣接確認フラグと共に前記管理システムへ送信することを特徴とする請求項１に記載のアラーム処理システム。
【請求項３】
前記一方のノード装置は、前記他方のノード装置のアラームDBに前記アラーム情報と同一のアラーム情報が登録されていないと当該アラーム情報にサイレントフラグをセットし、当該アラームを前記サイレントフラグと共に前記管理システムへ送信することを特徴とする請求項１に記載のアラーム処理システム。
【請求項４】
前記他方のノード装置は、アラームDBに登録されているアラーム情報に隣接確認フラグがセットされていないとサイレントフラグをセットし、当該アラームを前記サイレントフラグと共に前記管理システムへ送信することを特徴とする請求項１ないし３のいずれかに記載のアラーム処理システム。
【請求項５】
前記相互に隣接するノード装置は、自装置に固有のIDと隣接装置に固有のIDとを比較して前記ノード装置の一方を決定することを特徴とする請求項１ないし４のいずれかに記載のアラーム処理システム。
【請求項６】
前記管理システムへ送信されるアラーム情報は、SNMPトラップに記述されて送信されることを特徴とする請求項１ないし５のいずれかに記載のアラーム処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークのアラーム処理システムに係り、特に、一つのアラーム原因に対して複数のノード装置から発せられるアラームを集約することで総アラーム数を減じ、かつサイレント障害を確実に検知できるネットワークのアラーム処理システムに関する。
【背景技術】
【０００２】
ネットワーク仮想化技術の発展により、インターフェースやネットワーク自体の管理オブジェクト数が爆発的に増加し、発生するアラーム数も増加する傾向にあり、ネットワークの障害状態の把握（特に障害原因解析）に遅れが生じる課題がある。
【０００３】
このような技術課題に対して、本発明の発明者等は、ネットワーク装置が保持するデータを、集中管理基盤上で管理するのではなく、ネットワーク上の各ノード装置内部にデータ処理をオフロードする手法を開発し、特許出願（特許文献１）した。更に、トラヒック量などの品質・性能情報も同様に大幅に増加しており、管理システム側の負荷の増加が予想されるため、処理を装置へオフロードする手法を開発し、特許出願（特許文献２）した。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特願2012-030371号
【特許文献２】特願2013-059035号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ネットワークオペレータはネットワークサービスの異常を検知・把握するため、既存方式ではすべての装置で設定されたSNMP（Simple Network Management Protocol）やSyslog情報を、外部管理システム（NMS：Network Management System）で受信し、状態遷移の把握を行っている。しかしながら、既存方式では装置単位でアラーム情報が送信されるため、直接原因でないアラームが送出されてくるとともに、管理対象となるノード装置数が増えるとアラーム情報が爆発的に増加し、結果的に処理遅延が生じる。さらに、サイレント障害の発見に遅延が生じうる。
【０００６】
本発明の目的は、上記の技術課題を解決し、管理システムが持つアラーム管理機能の一部をネットワーク上の各ノード装置内部に配備して機能を分散化すると共に、隣接するノード装置同志がアラーム情報を確認することにより、管理システムへ通知するアラーム数を削減し、更にはサイレント障害を検知できるアラーム処理システムを提供することにある。
【課題を解決するための手段】
【０００７】
上記の目的を達成するために、本発明は、ネットワークのノード装置上でアラーム情報を分散処理するアラーム処理システムにおいて、以下の構成を発明特定事項とした点に特徴がある。
【０００８】
(1)ネットワークトポロジおよび各ノード装置のIDを管理する構成管理手段と、ノード装置により検知されたアラーム情報を蓄積するアラームDBと、ネットワークトポロジに基づいて隣接装置を識別する手段と、相互に隣接するノード装置の一方が他方のアラームDBを参照し、前記アラーム情報と同一のアラーム情報が登録されていれば自装置のアラームDBから前記アラーム情報を削除する手段と、アラームDBに蓄積されているアラーム情報を前記管理システムへ送信する手段とを具備した。
【０００９】
(2)一方のノード装置は、他方のノード装置のアラームDBにアラーム情報と同一のアラーム情報が登録されていると当該アラーム情報に隣接確認フラグをセットし、他方のノード装置は、当該アラームを隣接確認フラグと共に前記管理システムへ送信するようにした。
【００１０】
(3)一方のノード装置は、他方のノード装置のアラームDBにアラーム情報と同一のアラーム情報が登録されていないと当該アラーム情報にサイレントフラグをセットし、当該アラームを前記サイレントフラグと共に管理システムへ送信するようにした。
【００１１】
(4)他方のノード装置は、アラームDBに登録されているアラーム情報に隣接確認フラグがセットされていないとサイレントフラグをセットし、当該アラームを前記サイレントフラグと共に管理システムへ送信するようにした。
【発明の効果】
【００１２】
本発明によれば、以下のような効果が達成される。
(1)同一のネットワーク障害に起因した同一アラームが複数のノード装置において検知されても、隣接ノード同士で同一アラームが一方の隣接ノードへ集約されるので、複数のノード装置から同一アラームがそれぞれ管理システムへ送信される不都合が防止される。
【００１３】
(2)自装置のみに登録されて隣接ノード装置には未登録のアラームをサイレント障害に起因したアラームと推定し、当該アラームがサイレント障害に起因したアラームである旨の情報と共に管理システムへ送信されるので、管理システムはサイレント障害を簡単に判別できるようになる。
【図面の簡単な説明】
【００１４】
【図１】本発明に係るアラーム処理システムが適用されるネットワークノード装置の構成を示した機能ブロック図である。
【図２】発明の一実施形態の動作を模式的に表現した図である。
【図３】本発明の一実施形態の動作を示したフローチャートである。
【図４】アラーム通知のフォーマットを示した図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明に係るアラーム処理システムが適用されるネットワークノード装置の構成を示した機能ブロック図であり、ネットワーク上には多数のネットワークノード装置INMおよびその管理システム１が配置されている。
【００１６】
各ノード装置INMではSNMPエージェントがそれぞれ稼働し、各SNMPエージェントは、あらかじめ指定されたイベントの発生や、プロセス値の閾値越え等が検知されるとSNMPトラップ(Trap)を送出する。当該SNMPトラップは、各ノード装置INMのAPIを経由して、管理システム１のSNMPマネージャへ送信される。
【００１７】
ノード装置INMにおいて、アラーム処理基盤２１は、SNMPエージェントが送出するSNMPトラップをリアルタイムにモニタリングし、本基盤上に設定されたアラームマスクルールに基づいてマスク処理を行う。アラームマスクルールとは、高速データ処理基盤上に設定されたフィルタ機能により、不必要と判断されたアラームをマスクする機能であり、隣接装置間のアラーム受信状況を確認するアラーム処理フロー機能も具備する。
【００１８】
本実施形態では、構成管理DBで管理されているConnectionおよびConnectionLess、ならびにネットワークで保持されるOID情報以外がマスクされる。そして、アラームマスクされたアラームがアラーム保存DB２３で一定時間保存される一方、アラームマスクされなかったアラームはアラームDB２２へ保存される。共有データベース２５は、複数のノード装置間で構成管理データ（装置構成情報やネットワークトポロジ情報）を共有管理する仕組みを提供する。
【００１９】
API（外部インターフェース機能部）は、アラーム情報の記述されたSNMPトラップを管理システム１へ転送するインターフェース機能を実現する。共有DB２５には、ネットワークトポロジおよび各ノード装置INMに固有の識別IDが登録されている。本実施形態では、各ノード装置INMの識別IDとしてIPアドレスが用いられる。
【００２０】
次いで、図２のブロック図および図３のフローチャートを参照して本発明の動作について詳細に説明する。
【００２１】
ステップＳ１では、各ノード装置INMにおいて稼働中のSNMPエージェントから送出されたアラーム(Trap)が受信されたか否かが判定される。ここでは、相互に隣接するノード装置INM1，INM2において、同一のネットワーク障害に起因した同一アラームの記述されたTrapが、ほぼ同時刻に受信されたものとして説明を続ける。
【００２２】
ステップＳ２では、当該アラームが各ノード装置INM1，INM2において自装置のアラームDB２２にそれぞれ登録される。本実施形態では、図２に示したように、アラームの受信時刻およびその送信元(source)情報、ならびにSNMPトラップのOID(オブジェクトID)に記述されているアラーム(Alarm)情報が抽出されてアラームDB２２の同一レコードに登録される。
【００２３】
ステップＳ３では、構成管理DB２５に登録されているネットワークトポロジに基づいて隣接ノード装置INMが識別され、当該隣接ノード装置の識別ID（本実施形態では、IPアドレス）が前記登録されたアラームのレコードに隣接情報として登録される。すなわち、ノード装置INM1では、隣接装置としてノード装置INM2が認識されるので、そのIPアドレスがアラームDB２２の対応レコードに隣接情報として登録される。ノード装置INM2では、隣接装置としてノード装置INM1が認識されるので、そのIPアドレスがアラームDB２２の対応レコードに隣接情報として登録される。
【００２４】
ステップＳ４では、各ノード装置INM1，INM2において自装置のアラームDB２２が参照され、自装置の装置ID(source情報)および隣接装置の装置ID(隣接情報)のいずれが相対的に若番であるか判断される。ここでは、ノード装置INM1の装置ID（ノード1）よりもノード装置INM2の装置ID（ノード2）が若番であるものとして説明を続ける。したがって、ノード装置INM1では処理がステップＳ４からステップＳ５へ進み、ノード装置INM2では処理がステップＳ４からステップＳ１２へ進む。
【００２５】
初めに老番のノード装置INM1の動作に注目し、ステップＳ５，Ｓ６では、隣接するノード装置INM2のアラームDB２２への接続が試行され、接続できればステップＳ７へ進む。ステップＳ７では、ノード装置INM2のアラームDB２２に、前記ステップＳ１で自装置が受信したアラーム（アラーム１）と同一のアラームが重複登録されているか否かが判定される。ここでは、アラーム１が重複登録されていると判定されるのでステップＳ１０へ進み、当該隣接するノード装置INM2のアラームDB２２において、前記アラーム１と対応付けられた同一レコードの隣接確認フラグFnがセット（＝１）される。ステップＳ１１では、ノード装置INM1のアラームDB２２から前記重複登録されていたアラーム１が削除される。
【００２６】
次いで若番のノード装置INM2の動作に注目し、ステップＳ１２では所定の時間だけ待機する。ステップＳ１３では、自装置INM2のアラームDB２２に既登録のアラームについて、その隣接確認フラグFnが「１」であるか否かが判定され、隣接確認フラグFnが「１」であればステップＳ９へ進み、「１」でなければステップＳ８へ進む。本実施形態では、前記ステップＳ１０においてアラーム１の隣接確認フラグFnがセットされているのでステップＳ９へ進む。ステップＳ９では、前記アラーム１の記述されたSNMPトラップが管理システム１へ送出される。
【００２７】
これに対して、ノード装置INM1にサイレント障害が発生し、そのアラーム（アラーム２）の記述されたTrapがノード装置INM1のみで受信されていれば、当該処理はノード装置INM1のみで実行され、そのステップＳ７では、同一アラームが隣接するノード装置INM2のアラームDB２２には未登録と判定されるのでステップＳ８へ進む。ステップＳ８では、自装置INM1のアラームDB２２において前記アラーム２と対応付けられたサイレントフラグFsがセットされる。ステップＳ９では、前記アラーム２の記述されたSNMPトラップが管理システム１へ送出される。
【００２８】
図４は、各ノード装置INMから管理システム１へ送信されるSNMPトラップのフォーマットを示した図であり、本実施形態では、OID (オブジェクトID)に拡張領域として「対向装置情報」および「サイレント故障情報」が用意されている。そして、前記ステップＳ８においてサイレントフラグFsがセットされると、ステップＳ９では、"元のアラーム情報"として前記アラーム２が記述され、"対向装置情報"としてsource情報が記述され、"サイレント故障情報"として前記サイレントフラグFsの値（ここでは、１）の記述されたSNMPトラップが生成されて管理システム１へ送出される。
【００２９】
管理システム１では、SNMPトラップを受信した際に、そのOIDの"サイレント故障情報"がセット(=1)されていれば、"対向装置情報"に記述されたノード装置INMにおいてサイレント障害が発生していると認識できる。また、"サイレント故障情報"がセットされていなければ、サイレント障害以外の例えばリンク障害が発生していると判断できる。
【００３０】
なお、上記の実施形態では、ネットワーク機器を監視、制御するための通信プロトコルとしてSNMPを利用するものとして説明したが、本発明はこれのみに限定されるものではなく、各ノード装置において検知された障害にオリジナルのメッセージやフラグを記述して管理システムに通知できるのであれば、他のプロトコルを用いても良い。
【００３１】
本実施形態によれば、同一のネットワーク障害に起因した同一アラームが複数のノード装置INMにおいて重複検知されても、隣接ノード同士で同一アラームが一方の隣接ノードへ集約されるので、複数のノード装置INMから同一アラームがそれぞれ管理システム１へ送信される不都合が防止される。
【００３２】
また、本実施形態によれば、自装置のみに登録されて隣接ノード装置には未登録のアラームをサイレント障害に起因したアラームと推定し、当該アラームがサイレント障害に起因したアラームである旨の情報と共に管理システム１へ送信されるので、管理システム１はサイレント障害を簡単に判別できるようになる。
【符号の説明】
【００３３】
１…管理システム，２１…アラーム処理基盤，２２…アラームDB，２３…アラーム保存DB，２４…API，２５…共有データベース
【図１】
2015029194.tif 000003
【図２】
2015029194.tif 000004
【図３】
2015029194.tif 000005
【図４】
2015029194.tif 000006