(57)【特許請求の範囲】
【請求項１】
故障したネットワーク・エレメントとアクセス不能ネットワーク・エレメントを区別するネットワーク監視機構であって、（ａ）１つまたは複数のコンピュータ読み取り可能記憶媒体と、（ｂ）コンピュータ読み取り可能プログラム・コードとを備え、
上記コンピュータ読み取り可能プログラム・コード（ｂ）は、
上記１つまたは複数のコンピュータ読み取り可能媒体に記憶され、
（ｂ１）複数のネットワーク・エレメントのトポロジーを検出するコード、
（ｂ２）上記複数のネットワーク・エレメントに関連する複数のネットワーク・インタフェースに周期的にポーリングを行い、それぞれのインタフェースの状態をメモリに記憶させるコード、
（ｂ３）ポーリングに応答しない問題インタフェースに至る経路に介在する１つまたは複数のネットワーク・インタフェースを示す危機的ルート属性を計算または確認するコード、および、
（ｂ４）前記危機的ルート属性によって識別されるネットワーク・インタフェースの状態を分析するコードを含み、
前記分析するコードは、前記危機的ルート属性に含まれる１つまたは複数のネットワーク・インタフェースについて前記メモリに記憶されている状態を調べて、いずれかのネットワーク・インタフェースがダウン状態であるかどうかを判断し、ダウン状態のネットワーク・インタフェースがあれば、該ダウン状態にあるネットワーク・インタフェースを故障として識別し、前記問題インタフェースをアクセス不能として識別する、ネットワーク監視機構。
【請求項２】
請求項１に記載のネットワーク監視機構であって、
減速ポーリング・リストにアクセス不能と識別されたネットワーク・インタフェースのメモリ内表現を書き込むコードを更に含む、ネットワーク監視機構。
【請求項３】
故障したネットワーク・エレメントとアクセス不能ネットワーク・エレメントを区別し、その情報をネットワーク管理者に理解しやすい形式で示すネットワーク管理装置であって、（ａ）表示手段と、（ｂ）ネットワーク監視装置とを備え、
上記ネットワーク監視装置（ｂ）は、
（ｂ１）ネットワークに接続されており、複数のネットワーク・エレメントのトポロジーを検出する手段、
（ｂ２）上記複数のネットワーク・エレメントに関連する複数のネットワーク・インタフェースに周期的にポーリングを行い、それぞれのインタフェースの状態をメモリに記憶させる手段、
（ｂ３）ポーリングに応答しない問題インタフェースに至る経路に介在する１つまたは複数のネットワーク・インタフェースを示す危機的ルート属性ルート属性を計算または確認する手段、および、
（ｂ４）前記危機的ルート属性によって識別されるネットワーク・インタフェースの状態を分析し、前記問題インタフェースについての前記危機的ルート属性に含まれる１つまたは複数のネットワーク・インタフェースについて前記メモリに記憶されている状態を調べて、いずれかのネットワーク・インタフェースがダウン状態であるかどうかを判断し、ダウン状態のネットワーク・インタフェースがあれば、該ダウン状態にあるネットワーク・インタフェースを一次故障として識別し、前記問題インタフェースを二次故障として識別する、分析手段と、を備え、
上記表示手段（ａ）および上記ネットワーク監視機構（ｂ）が１つまたは複数の事象バスを経由して通信する、ネットワーク管理装置。
【請求項４】
請求項３に記載のネットワーク管理装置であって、
（ｃ）事象相関システムをさらに備え、
上記１つまたは複数の事象バスが相関事象バスを含み、
上記表示手段（ａ）が、上記相関事象バスを介して事象データを受け取るネットワーク管理装置。
【請求項５】
請求項４に記載のネットワーク管理装置であって、
上記事象相関システム（ｃ）は、事象が上記相関事象バスに出現しないように事象を削除する手段を含み、
上記表示手段（ａ）は、種々の削除された事象が表示のため呼び出される下位表示インタフェースを含むネットワーク管理装置。
【請求項６】
故障したネットワーク・エレメントとアクセス不能ネットワーク・エレメントを区別し、その情報をネットワーク管理者に理解しやすい形式で示すネットワーク管理方法であって、
（ａ）複数のネットワーク・エレメントのトポロジーを検出するステップと、
（ｂ）上記複数のネットワーク・エレメントに関連する複数のネットワーク・インタフェースに周期的にポーリングを行い、それぞれのインタフェースの状態をメモリに記憶させるステップと、
（ｃ）ポーリングに応答しない問題インタフェースに至る経路に介在する１つまたは複数のネットワーク・インタフェースを示す危機的ルート属性を計算または確認するステップと、
（ｄ）前記危機的ルート属性によって識別されるネットワーク・インタフェースの状態を分析し、前記問題インタフェースについての前記危機的ルート属性に含まれる１つまたは複数のネットワーク・インタフェースについてメモリに記憶されている状態を調べて、いずれかのネットワーク・インタフェースがダウン状態であるかどうかを判断し、ダウン状態であれば、このダウン状態にあるネットワーク・インタフェースを一次故障インタフェースとして識別し、前記問題インタフェースを二次故障インタフェースとして識別する、分析ステップと、
を含むネットワーク管理方法。
【請求項７】
請求項６に記載のネットワーク管理方法であって、上記分析ステップ（ｄ）が、
（ｄ１）最初に、１つまたは複数のネットワーク・インタフェースのメモリ内状態を検証して、上記問題インタフェースの前記ルート属性によって識別されたネットワーク・インタフェースが非活動状態であるか否かを判断し、そうであればそのネットワーク・インタフェースを一次故障インタフェースとして識別するステップと、
（ｄ２）第２に、上記問題インタフェースの前記ルート属性によって識別されたネットワーク・インタフェースが一次故障インタフェースと識別されなかったなら、上記問題インタフェースの前記ルート属性によって識別された１つまたは複数のネットワーク・インタフェースの状態を検証して、それらの１つが一次故障インタフェースであるか否かを判断するステップと、
（ｄ３）第３に、上記問題インタフェースの前記ルート属性によって識別されたネットワーク・インタフェースが一次故障インタフェースと識別されなかったなら、該問題インタフェースを一次故障インタフェースとして識別するステップと、
を含むネットワーク管理方法。
【請求項８】
請求項６に記載のネットワーク管理方法であって、
（ｅ）ルート待機リストを維持するステップを更に含み、
事前ルート待機リスト・アルゴリズムが、
（α１）１つまたは複数のネットワーク・インタフェースのメモリ内状態を検証して、上記問題インタフェースのための上記ルート属性によって識別されたネットワーク・インタフェースが非活動状態であるか否かを判断し、そうであればそのネットワーク・インタフェースを一次故障インタフェースとして識別するステップと、
（α２）そのステップがネットワーク・インタフェースを一次故障インタフェースと識別することに成功すれば、
（α２ｉ）上記問題インタフェースを二次故障インタフェースとして識別し、
（α２ｉｉ）二次故障インタフェース非活動事象を発信し、
（α２ｉｉｉ）低速でポーリングするネットワーク・インタフェースのリスト上に上記問題インタフェースのメモリ内表現を書き込む
ステップとを含むネットワーク管理方法。
【請求項９】
請求項８に記載のネットワーク管理方法であって、ルート待機リスト・アルゴリズムが、
（β１）上記問題インタフェースのための上記ルート属性によって識別された上記ネットワーク・インタフェースのいずれもが一次故障インタフェースと識別されなかったなら、
（β１ｉ)上記問題インタフェースのメモリ内表現および上記問題インタフェースのための上記ルート属性によって識別されるすべてのネットワーク・インタフェースをルート待機リストに移動して、この方法を実行するネットワーク監視機構にアクセス可能なその他のすべてのリストからこれらのネットワーク・インタフェースを削除し、
（β１ｉｉ）上記ルート待機リストを順次なぞっていき、各ネットワーク・インタフェースにポーリングを行い、そのインタフェースが一次故障インタフェースであるか否か判断することによって、
上記問題インタフェースのための上記ルート属性によって識別された１つまたは複数のネットワーク・インタフェースの状態を検証するステップと、
(β２)上記問題インタフェースのための上記ルート属性によって識別されたネットワーク・インタフェースが一次故障インタフェースと識別されなかったなら、上記問題インタフェースを一次故障インタフェースとして識別し、そうでなければ上記問題インタフェースを二次故障インタフェースとして識別するステップと、
を含むネットワーク管理方法。
【請求項１０】
請求項６に記載のネットワーク管理方法であって、
（ｅ）問題インタフェースを一次故障インタフェースまたは二次故障インタフェースとして識別するために問題インタフェースのルート属性を使用するステップを更に含むネットワーク管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク管理システムに関するもので、特に、故障したネットワークエレメントと故障したエレメントが原因でアクセス不能となったネットワーク・エレメントを区別する技術に関するものである。収集された事象データは、単純明瞭で管理しやすい形態でネットワーク管理者に提示される。
【０００２】
【従来の技術】
OpenViewネットワーク・ノード・マネージャ製品のようなネットワーク管理システムは、(例えば、すべてのネットワーク・エレメントに関する領域、タイプおよび接続のリストのような)ネットワーク・トポロジーを検出し、各ネットワーク・エレメントの健康状態を監視し、ネットワーク管理者に問題を報告するように設計される。OpenViewネットワーク・ノード・マネージャ(ネットワーク・ノード・マネージャはその英語名称Network Node Managerの頭文字をとって以下ＮＮＭと略称する場合がある)は、米国カリフォルニア州パロアルト所在のヒューレット・パッカード社によって市販されている製品である。
【０００３】
そのようなシステムの監視機構は、通常、各ネットワーク・エレメントを周期的にポーリングして、ネットワーク・エレメントの健康状態を標示するデータを収集する専用コンピュータ・プログラムによって実施される。監視プログラムは典型的には単一のホスト上で稼働する。しかしながら、分散ネットワークにおいては、複数の監視機構がネットワークの種々のノード上で稼働し、各監視機構がその結果を中央の表示装置に報告する。
【０００４】
ネットワーク管理者は、表示装置上のネットワーク状態表示を観察する。１つのネットワーク・エレメントが故障する場合、ネットワーク管理者に提示される情報は、(1)どのエレメントが故障しているか、(2)故障によって影響を受ける他のネットワーク・エレメントはどれか、すなわち、故障を起こした装置のためネットワーク上でアクセスできない機能中ネットワーク・エレメントはどれか、および、(3)このネットワークに依存している組織の生産性にとってどのアクセス不能ネットワーク・エレメントが不可欠なエレメントか(従って、どのネットワークがネットワーク管理者にとって復旧の優先度が高いか)を識別することが理想的である。
【０００５】
多くの市販のネットワーク管理製品では、これら３つの独立したクラスの情報は１つに統合されている。単一ネットワーク・エレメントの故障が、突然何千もの(ノードおよびインタフェースなどの)エレメントのアクセス不能を招くことになるので、ネットワーク管理者は情報に圧倒される(ネットワーク管理者を以下英語Network Administratorの頭文字をとってＮＡと略称する場合がある)。この結果、ＮＡは、相当の時間を費やして、受け取った過剰な情報を分析し、故障の根本原因および組織への影響を判断する。
【０００６】
１つのネットワーク・エレメントが故障し、その他の多くのノードがアクセス不能となる時、監視機構は、典型的には、機能しているノードとアクセス不能ノードの両者へのポーリングを継続する。監視は、典型的には、ＩＣＭＰピング(すなわちインターネット・コントロール・メッセージ・プロトコルEcho_Request信号)、ＳＮＭＰメッセージ(すなわちシンプル・ネットワーク・マネジメント・プロトコルSimple Network Management Protocolメッセージ)またはＩＰＸ診断要求を使用して行われる。これらの活動は、「照会」または「ピング(Pingすなわち照会信号)」と呼ばれる。ネットワーク・エレメントがアクセス可能な時、これらの照会はミリ秒のオーダーでプロセスされる。しかしながら、ネットワーク・エレメントがアクセス不能の時、照会はタイムアウトまで数秒を要する。この結果、無関係なネットワーク・トラフィックの洪水が発生し、ネットワークの性能が低下する(例えば監視プログラムは機能しているノードの予定したポーリングが遅れる程度まで実行速度を下げることもあり、このことが更にネットワークの処理性能を低下させる原因となる)。
【０００７】
上記問題の解決を試みる製品の１つは、米国カリフォルニア州所在のSeagate Software of Scotts Valley社によって市販されているNerveCenter製品である。しかし、NerveCenter製品は監視プログラムを含まない。従って、同社のトポロジー記述言語を使用してネットワークを手作業で記述するようにＮＡに強制することによって目的が達成される。この作業は、実用的サイズのネットワークに関して実際的ではない。更に、ネットワークへの変更は、トポロジー記述に対する(手作業の)同様の変更をＮＡが行うことに依存する。
【０００８】
上記問題の解決を試みる別の製品の１つは、米国カリフォルニア州パロアルト所在のヒューレット・パッカード社によって市販されているOpenViewネットワーク・ノード・マネージャ５.０１である。OpenViewネットワーク・ノード・マネージャ(ＮＮＭ)の５.０１までのリリース(以下ＮＮＭ5.01と呼称する)は、supraと記述されるネットワークを監視するnetmonと呼ばれる監視プログラムを含む。ＮＮＭ5.01は、単一netmonを含む環境だけでなく、いくつかのnetmonプロセスを含む分散環境をサポートする。分散環境においては、複数のnetmonプロセスは種々の収集ステーション・ホスト上で動き、それら種々の収集ステーション・ホストの各々はネットワークの中央管理ステーションにトポロジーおよび状態情報を通信し、そこで情報がＮＡに提示される。
【０００９】
記述を容易にするため、以下の記述の大部分は非分散環境を前提とする。図１は、MGR HOST N 110上で動くnetmanを備えた小規模ネットワーク１００を示す。ネットワーク１００へのアクセスにはMGR HOST Nのネットワーク・インタフェースN.1が使用される。netmonは、ＩＣＭＰおよびＳＮＭＰを使用してネットワーク１００を検出し、データベース・サーバ(ovtopmd)１１６によって提供されるサービスを介してトポロジー・データベース(topoDB)１１８にトポロジーを記憶する。ipmap/ovwプロセス１０４は、ovtopmd１１６に接続され(線１０６)、検出されたすべてのネットワーク・エレメント、それらの接続およびそれらの状態をグラフィック・ディスプレイ１０８に表示するようにトポロジー情報を変換する。
【００１０】
netmonは、ＩＣＭＰを使用して照会信号を送ることによって各ネットワーク・エレメント１２４、１２８−１３６の状態を判断する。応答が特定のネットワーク・エレメント１２４によって返されれば、エレメントは活動状態(すなわちアップ)である。さもなければエレメント１２８は非活動状態(すなわちダウン)である。エレメント１２４がアップであれば、ipmap/ovw１０４はそのエレメントを緑で表示する(添付図面においては図１のブロック１０８および図３のブロック３０２におけるように中空の円によって示されている)。エレメント１２８がダウンであれば、そのエレメントは赤で表示される(添付図面においては図１のブロック１０８および図３のブロック３０２におけるように中黒の円によって示されている)。ノードまたはインタフェースの状態が不明である可能性があり、その状態は青として表示される(添付図面においては図３のブロック３０６−３１２におけるように斜線入り円によって示されている)。従来技術のネットワーク監視機構によって不明が使用されるケースはまれである。
【００１１】
トポロジー表示に加えて、ＮＮＭは、ノード状態、インタフェース状態および(図２の)ＮＮＭプロセス１２０、２０４および第３者ツール２０６間のその他の情報の通信を行う事象システム１１４を含む。これらの事象は、事象ブラウザxnmevents.web１２０というツールを使用して(図１の発生順事象リスト１２２のように)ＮＡに表示される。
【００１２】
図１において、ノードRouter_B１２８のインタフェースＢ.１はダウンしていて、そのため、Router_B１２８、Bridge_C１３０、Ｘ１３２、Ｙ１３４およびＺ１３６は突然アクセス不能となっている。従って、これらのノード１２８−１３６およびインタフェースがダウン(非活動状態)であるとが検出されるため、次のような事象がnetmonによって発信される。
【００１３】
インタフェースC.2ダウン
インタフェースC.1ダウン
インタフェースB.1ダウン
インタフェースB.2ダウン
インタフェースZ.1ダウン
インタフェースY.1ダウン
インタフェースX.1ダウン
注意すべき点であるが、インタフェース・ダウン事象は、netmonがインタフェースのポーリングを行うランダムな順序で発信される。このようなランダムな発信のため、ＮＡが事象ブラウザを使用して故障の原因を判断することの困難度が増す。各ノード１２４、１２８−１３６およびインタフェースの状態は、ovw画面１０８上にも表示される。上述のように、すべてのアクセス不能ノード／インタフェースは赤色で(図面では中黒円)で表示される。
【００１４】
【発明が解決しようとする課題】
実際のネットワークにおいては、図１のovw１０８またはxnmevents.web１２０に図示されてはいないが、Router_B１２８の別の側には何千ものノードがあり、そのためＮＡは短時間で故障の原因および危機的ノード復旧の緊急性を判断することができない。それに加えて、netmonがアクセス不能ノード１３０−１３６へのポーリングを継続するので、このシステム１００は前述のようにネットワーク性能低下に苦しむ。
【００１５】
このように、問題の根本原因をＮＡに明示して、ＮＡが問題の解決に迅速に着手することができるように、ネットワーク・エレメントに関連する問題をＮＡに提示することが必要とされる。更に、故障したネットワーク・エレメントとそのためにアクセス不能となったネットワーク・エレメントを区別するシステムおよび方法が必要とされる。
【００１６】
更にまた、(1)ネットワーク・エレメントの故障とともにＮＡによって受け取られる情報の供給過多を減少させ、(2)ＮＡが通常の形態で抑制された情報を見る手段を提供するようにネットワーク事象を削除するとともに相関させる手段が求められている。また、高度にカスタマイズ可能であり、従って情報を見るための多数の形式を備えたネットワーク監視機構をＮＡに提供することが必要とされる。
【００１７】
【課題を解決するための手段】
前述の課題を解決するため、本発明は、故障したネットワーク・エレメントとアクセス不能ネットワーク・エレメントを区別するネットワーク監視機構を提供する。該ネットワーク監視機構は、(例えばＣＤ−ＲＯＭ、フロッピー・ディスク、磁気テープ、ハードドライブなどの)１つまたは複数のコンピュータ読み取り可能記憶媒体、および、１つまたは複数のコンピュータ読み取り可能媒体に記憶されたコンピュータ読み取り可能プログラム・コードを含む。このコンピュータ読み取り可能プログラム・コードは、(1)複数のネットワーク・エレメントのトポロジーを検出するコード、（2)複数のネットワーク・エレメントに関連する複数のネットワーク・インタフェースに周期的にポーリングを行うコード、（3)複数のネットワーク・インタフェースの各々に関する危機的ルートの属性を計算または確認するコード、および(4)ポーリングに応答しない問題インタフェースの危機的ルートの属性によって識別されるネットワーク・インタフェースの状態を分析するコードを含む。複数のネットワーク・エレメントのトポロジーを検出するコードおよび複数のネットワーク・エレメントに関連する複数のネットワーク・インタフェースに周期的にポーリングを行うコードの要点は、米国特許第5,185,860号および同第5,276,789号に開示されている。
【００１８】
上述のネットワーク監視機構(およびそれを使用するシステムおよび方法)は、従来技術のネットワーク監視機構に対して多くの利点を提供する。
【００１９】
第１の利点は自動トポロジーである。ネットワーク故障の根本原因を適切に識別するためには、(1)ネットワークのトポロジー・モデルからの入力および(2)ネットワーク上の各エレメントの現在状態が必要とされる。従来技術においては、ＮＡはこのトポロジーを手操作で記述することを要求された。本発明の設計は、前もって作成されたトポロジーおよび状態情報を使用する。
【００２０】
第２の利点は、トポロジー表示である。情報のトポロジー的グラフィック表示は、ネットワーク管理者がネットワーク故障の根本原因を識別し優先度を設定するのを援助する上で、非常に役に立つ。本発明の好ましい実施形態において使用されるグラフィック表示(ovw)は、次の３つのカテゴリでネットワーク・エレメント状態を提示する。すなわち、
・機能しているノードおよびインタフェースは、アップ状態を標示するため緑色で表示される。
【００２１】
・故障の根本原因のインタフェースおよび危機的ノード上のアクセス不能インタフェースは、ダウン状態を標示するため赤色で表示される。
【００２２】
・危機的ではないがアクセス不能なインタフェースは不明状態を標示するため青色で表示される。
【００２３】
第３の利点は、事象を表示する新しい方法である。(図１の)ノードおよびインタフェース状態情報１２２の事象ブラウザの表示１２０は、ネットワーク管理者がネットワーク故障の根本原因を識別し優先度を設定するのを援助する上で、非常に役に立つ。(アクセス不能インタフェースを標示する事象である)２次故障事象は、(本当に故障したインタフェースを標示する事象である)一次故障およびアクセス不能な危機的ノードと共に表示されない。２次故障は、"下位表示"プロセスを介して観察される。
【００２４】
第４の利点はネットワーク性能である。従来技術では、故障が発生するとアクセス不能ネットワーク・エレメントに対する照会の失敗のため一層多くのネットワーク管理メッセージが発信されるので、ネットワーク処理性能が低下する。それに加えて、照会の失敗のタイムアウトは成功した照会より非常に遅くなるので、ネットワーク監視プロセスは予定より遅れるようになる。本発明の設計は、可能な場合は必ずこのような状況を回避するようにネットワーク監視サービスに関するポーリング減速アルゴリズムを含む。
【００２５】
第５の利点は、ネットワーク・エレメントを分類する能力である。ＮＡの優先度を反映してシステムがＮＡに情報を表示することを可能にするため、ネットワーク・エレメントは、通常および危機的という２つのクラスに分類される。これは、ネットワーク管理者が重要であるとみなすルータ、重要なサーバおよびその他のネットワーク・エレメントを定義できるようなメカニズムをネットワーク管理者に提供することによって達成される。
【００２６】
第６の利点は分散性である。従来技術の他のシステムは、アーキテクチャ的に集中的であり、大規模エンタープライズ・ネットワークに対して適応できない。本発明の実施形態は、OpenView分散アーキテクチャを基にして構築され、「大規模」ネットワークに関する新しい機能性を提供する。
【００２７】
第７の利点は恣意的トポロジーを取り扱う能力である。(例えばループや動的経路などの)顧客ネットワーク構成の複雑性のため、ネットワーク・エレメントの根本原因を見つけようとするアルゴリズムはすぐに機能しなくなる。本発明の実施形態におけるアルゴリズムは、「積み上げ型」であり、冗長なルータが故障する時ネットワーク・エレメントが故障していると見なすようなことはしない。
【００２８】
８番目の利点は、システム構成の柔軟性である。ネットワーク管理者はそのネットワーク、稼働スタイルおよび性能を最適化する選択肢を作成することができる。従来技術のシステムでは、構成変更は手操作で行われたり、あるいは、構成変更ができない。
【００２９】
最後の利点は、「事象配列」である。ネットワーク故障状況の間、アクセス不能ネットワーク・エレメントをランダムな順序で検出するという実施形態によって混乱が輻輳する。本発明の実施形態は、予測できる順序で故障を検出する新しい待ち行列アルゴリズムを含む。このような予測性は、ネットワーク管理者、および、ユーザまたは第三者が構築するかもしれないその他の事象相関プロセスの両者にとって役に立つ。
【００３０】
【発明の実施の形態】
ネットワークにおいて、故障したネットワーク・エレメントとアクセス不能ネットワーク・エレメントを区別し、その情報を理解が容易な形式でネットワーク管理者に提示するネットワーク管理装置が図５、図７および図８に示されている。該装置は、一般的に、１つまたは複数の事象バス１１４を経由して接続される表示プロセス１０４、１２０およびネットワーク監視機構(略してnetmon)１１Ｏを含む。ネットワーク監視機構１１０は、それに接続される複数のネットワーク・エレメント１２４、１２８−１３６のトポロジーを検出する手段、複数のネットワーク・エレメント１２４、１２８−１３６に関連する複数のネットワーク・インタフェースに周期的にポーリングを行う手段、複数のネットワーク・インタフェースの各々に関する危機的ルートの属性を計算または確認する手段、ポーリングに応答しない問題インタフェースの危機的ルートの属性によって識別されるネットワーク・インタフェース(例えばN.1, A.1, A.2, B.1, B.2, C.1, C.2, X.1, Y.1, Z.1)の状態を分析する手段を含む。(ポーリングに応答しない問題インタフェースを英語表現interface in questionの頭文字をとって以下ＩＩＱと呼称する場合がある)。
【００３１】
同様に、故障したネットワーク・エレメントとアクセス不能ネットワーク・エレメントを区別し、その情報を理解が容易な形式でネットワーク管理者に提示するコンピュータ方法が提供される。該方法は、複数のネットワーク・エレメント１２４、１２８−１３６のトポロジーを検出するステップ、複数のネットワーク・エレメント１２４、１２８−１３６に関連する複数のネットワーク・インタフェースに周期的にポーリングを行うステップ、複数のネットワーク・インタフェースの各々に関する危機的ルートの属性を計算または確認するステップ、および、ポーリングに応答しない問題インタフェースの危機的ルートの属性によって識別されるネットワーク・インタフェースの状態を分析するステップを含む。
【００３２】
故障したネットワーク・エレメントとアクセス不能ネットワーク・エレメントを区別する方法および装置の概要を上述したが、それら方法および装置の詳細を以下に記述する。本発明の好ましい実施形態は、独立および分散環境のためのOpenViewネットワーク・ノード・マネージャ製品(以下ＮＮＭと呼称する)との連係作業を行うように設計されている。OpenViewネットワーク・ノード・マネージャは、米国カリフォルニア州パロアルト所在のヒューレット・パッカード社の製品である。この製品は、ＨＰ部品番号J1136-90000、J1136-90001、J1136-90002、J1136-90004およびJ1136-90005によって識別される多数のエンド・ユーザ・マニュアル、およびＨＰ部品番号J1150-90001、J1150-90002、J1150-90003およびJ1150-90005によって識別される多数の開発者用マニュアルおいて詳細に記述されている。
【００３３】
システムが非分散環境において動作する様態を先ず記述する。非分散環境は、１つの管理ステーション１１０を備え、収集ステーションは持たない。管理ステーション１１０上で１つのＮＮＭnetmonプロセスが稼働している。また、ＮＡ表示プロセスovwおよびovevents.webが管理ステーション１１０上で稼働している。
【００３４】
危機的ルートの属性
netmonはＮＮＭ5.01の場合と全く同様にネットワーク１００のトポロジーを検出する。しかし、(典型的には１日１回発生する)netmon構成ポーリングの間および(netmon稼働開始後の)各ノードの最初の状態ポーリングの間、netmonは、危機的ルートと呼ばれるネットワーク・インタフェースの属性を計算または確認する。
【００３５】
危機的ルートの属性は、netmonから特定インタフェースに送信されるネットワーク・パケットを通過させるルートに対応する一連のＤＢオブジェクト識別子ovtopmdである。危機的ルートの属性は、介在するネットワーク・インタフェースの経路をたどる。
【００３６】
以下の表１のリストは、図１の各ネットワーク・インタフェースに関する危機的ルートの値を列挙している。
【００３７】
【表１】
ネットワーク
インタフェース  危機的ルート
N.1            N.1
A.1            N.1, A.1
A.2            N.1, A.1, A.2
B.1            N.1, A.1, A.2, B.1
B.2            N.1, A.1, A.2, B.1, B.2
C.1            N.1, A.1, A.2, B.1, B.2, C.1
C.2            N.1, A.1, A.2, B.1, B.2, C.1, C.2
X.1            N.1, A.1, A.2, B.1, B.2, C.1, C.2, X.1
Y.1            N.1, A.1, A.2, B.1, B.2, C.1, C.2, Y.1
Z.1            N.1, A.1, A.2, B.1, B.2, C.1, C.2, Z.1
ネットワークがたとえループを含んでも、計算実行の瞬間にはパケットが進むルートがただ１つ存在するので、危機的ルートを計算することができる。危機的ルートの計算の際複数の可能性が存在する場合、ネットワークの外部をたどるルート上の同じネットワークまたはサブネットの範囲内のルートに優先順位が与えられる。また、その他の非ルータの「複数ホーム」ノード上にルータ・ノードを含むルートにも優先順位が与えられる。
【００３８】
一次故障対二次故障
各ネットワーク・インタフェースに関する危機的ルートの属性を計算した後、一次故障インタフェースと二次故障インタフェースを見分けることが可能である。本明細書において、一次故障インタフェースとは故障したインタフェースを意味し、一方、二次故障インタフェースは、故障したインタフェースが原因でアクセス不能なインタフェースを意味する。
【００３９】
図１の事象ブラウザ１２０において事象が表示されているものと同じ順序で、すなわち、
インタフェースC.2
インタフェースC.1
インタフェースB.1
インタフェースB.2
インタフェースZ.1
インタフェースY.1
インタフェースX.1
という順序でnetmonがネットワーク・インタフェースのポーリングを実行すると仮定する。
【００４０】
ノードBRIDGE_Cのインタフェースの状態ポーリングの前段階では、ノード１２４、１２８−１３６およびインタフェースのすべてはアップであり、ovwマップ１０４／１０８上に緑色で表示されている。事象ブラウザ１２０にはダウン状態のインタフェース事象はない。インタフェースＣ.２に対するnetmonのポーリングがタイムアウトとなる時、netmonは、インタフェースＣ.２がアクセス不能であると認識する。インタフェースＣ.２について、それが物理的にハードウェア／ソフトウェア故障と共にダウンしているためなのか、あるいは、接続しているインタフェースがダウンしているためにインタフェースＣ.２がアクセス不能であるのかこの時点では不明である。
【００４１】
ＮＮＭ5.01においては、netmonがovtopmdＡＰＩ１１６を使用してインタフェースの状態を危機的に設定するだけであり、次に、ovtopmd１１６がトポロジー・データベース１１８の中のインタフェース状態を変更しインタフェース・ダウン事象を送出する。
【００４２】
本発明の場合、その方法の一部として、netmonは、ＩＩＱのインタフェースに関して危機的ルートに沿ったインタフェースの状態を分析し、どのインタフェースがハードウェア／ソフトウェア故障を含むのか判断することを試みる。上述のように、それ自身のハードウエア／ソフトウェア故障のためアクセス不能であるインタフェースは一次故障インタフェースとみなされる。一次故障インタフェースが原因でアクセス不能なインタフェースは、二次故障インタフェースとみなされる。このようなシナリオにおいて、(インタフェースＢ.１が故障したと仮定して)インタフェースは次の表２のように分類される。
【００４３】
【表２】
インタフェース     故障分類
N.1              故障していない。
A.1              故障していない。
A.2              故障していない。
B.1              一次故障。
B.2              二次故障。
C.1              二次故障。
C.2              二次故障。
X.1              二次故障。
Y.1              二次故障。
Z.1              二次故障。
【００４４】
事前危機的ルート待機リスト分類アルゴリズム
インタフェースＣ.２に対するnetmonのポーリングがタイムアウトとなる時、netmonは、ＩＩＱ(インタフェースＣ.２)に関する危機的ルート経路に沿ったあらゆるインタフェースのメモリ内状態を調べる。この経路に沿ったインタフェースがダウン(危機的状態)であれば、ＩＩＱは二次故障インタフェースである。ＩＩＱが二次故障インタフェースであれば、libtopmの二次故障状態変更ＡＰＩ呼び出しを使用してnetmonはその状態を不明に変更する。
【００４５】
ovtopmd１１６はトポロジー・データベース１１８の中のインタフェースの状態を変更し、特別な"二次故障インタフェース・ダウン"メッセージを発信する。次に、netmonは、インタフェースの内部表現をポーリング減速リストに書き込み、ネットワーク上のその他のインタフェースに対する通常の状態ポーリング処理を継続する。
【００４６】
危機的ルート待機リスト分類アルゴリズム
事前危機的ルート待機リストのインタフェース故障分類アルゴリズムが危機的ルートに沿った既にダウンした(ＩＩＱ以外の)インタフェースを検出することができない場合、これらインタフェースのうちの１つが最後に検査されてから故障していないことを確認するため、危機的ルートに沿ったすべてのインタフェースの状態が検証されなければならない。これを実施するため、netmonは、このＩＩＱの表現を通常のポーリング・リストから危機的ルート待機リストと呼ばれる新しい待ち行列へ移動させることによってインタフェースＣ.２がアクセス不能であるという事実を保存する。このリストは以下の特性を持つ。
【００４７】
・リストに書き込まれるインタフェースの数はいくつでもよい。
【００４８】
・リスト上の最初のインタフェースだけが危機的ルート待機リスト・アルゴリズムによって処理される。すべての他のインタフェースは保持されるだけである。
【００４９】
・インタフェースがこのリスト上にある時、それは他のいかなるリスト上にもない。このため他のnetmon活動によるこのインタフェースの処理が防止される。
【００５０】
・このリストは、危機的ルート待機リスト(ＩＩＱ)の順次アクセスを可能にするデータ構造を持つ。これはnetmonのスレッド化された特性のため重要である。危機的ルート上の特定のインタフェース(ＩＩＱ)にポーリング信号を送信した後、応答またはタイムアウト発生を待つ間netmonは他のタスクを実行する。
【００５１】
インタフェース・ダウンを検出またはＩＩＱのアクセス不能インタフェースに出会うまで(管理ステーション１１０における)netmonノードのインタフェースから始めて一度に１つのステーションへポーリング信号を送信することによって、netmonはＩＩＱインタフェースに代わって危機的ルートに沿った各インタフェースに問い合わせを行う。
【００５２】
(ＩＩＱ以外の)インタフェースがダウンしていれば、それは一次故障インタフェースとして処理される。インタフェースの状態は、ＮＮＭ5.01libtopmＡＰＩを使用して危機的に変更される。ovtopmdは、トポロジー・データベース１１８の中のインタフェースの状態を変更し、特別な"一次故障インタフェース・ダウン"メッセージを発信する。次に、netmonは、インタフェースの内部表現を危機的ルート待機リストから減速ポーリング・リストへ移し、ネットワーク１００上の他のインタフェースの通常の状態ポーリング処理を継続する。
【００５３】
(ＩＩＱ以外の)一次故障が検出されれば、ＩＩＱの故障は二次故障であり、二次故障に関する上述の処理が行われる。netmonは、ＮＮＭ5.01libtopmＡＰＩを使用して不明に変更する。ovtopmd１１６は、トポロジー・データベース１１８の中のインタフェースの状態を変更し、後述するような特別な"二次故障インタフェース・ダウン"メッセージを発信する。次に、netmonは、インタフェースの内部表現を減速ポーリング・リストへ移し、ネットワーク１００上の他のインタフェースの通常の状態ポーリング処理を継続する。
【００５４】
危機的ルートに沿って一次故障インタフェースが検出されなければ、危機的ルート待機リスト処理は最終的にＩＩＱインタフェースへ戻る。この場合、ＩＩＱインタフェースが一次故障インタフェースと認められる。通常の一次故障処理がＩＩＱに対して実行される。
【００５５】
ＮＮＭ5.01libtopmＡＰＩを使用してインタフェースの状態が危機的に変更される。ovtopmdは、トポロジー・データベース１１８の中のインタフェースの状態を変更し、特別な"一次故障インタフェース・ダウン"メッセージを発信する。次に、netmonは、インタフェースの内部表現を危機的ルート待機リストから減速ポーリングリストへ移し、ネットワーク上の他のインタフェースの通常の状態ポーリング処理を継続する。
【００５６】
危機的ルート待機リストの巻き上げ処理
危機的ルート待機リストが処理されている間、netmonは、ポーリング・リストによって制御されているネットワーク１００の他のインタフェースへのポーリングを続行する。これらのいくつかはアクセス不能である可能性があり、上述のアルゴリズムによって危機的ルート待機リストを先に進めなければならないかもしれない。これらのインタフェースの多くは、同じ一次故障インタフェースが原因の二次故障であるかもしれない。二次故障インタフェースの各々に関して危機的ルート全体の状態を検証することは非常に能率が悪い。
【００５７】
最初の二次故障インタフェースが識別され処理される時までには、一次故障インタフェースも識別され処理されている。このことは、新しいＩＩＱ(すなわちＩＩＱ２)が一次故障インタフェースであるのかあるいは二次故障インタフェースであるのか判断することが可能であることを意味する。この判断は、事前危機的ルート待機リスト分類アルゴリズムを使用して危機的ルートに沿った各インタフェースのメモリ内状態を検証することによって実行され、追加照会信号を送信する時間の浪費が避けられる。
【００５８】
ＩＩＱ２が二次故障であると判断されると、二次故障処理が実行され、インタフェースは危機的ルート待機リストから減速ポーリング・リストへ移され、危機的ルート状態の検証は不要となる。そうでない場合、ＩＩＱ２に関する処理がＩＩＱの処理の場合と同じように継続される。
【００５９】
一次故障および二次故障に関するインタフェース・ダウン事象
上述から理解されるように、ovtopmdデーモン１１６は、トポロジー・データベース１１８の中のネットワーク・エレメント１２４、１２８−１３６の状態変更および関連事象の送信に対して責任を持つ。他のプロセスがovtopmdにlibtopmＡＰＩを使用するように指示する時、ovtopmdはそれら他のプロセスのためそのような責任を果たす。
【００６０】
一次故障事象に関するこのＡＰＩへの変更はなく、一次故障事象はＭＮＭ5.01形式を変更なしに使用する。しかしながら、二次故障事象に関しては、二次故障に関する情報が伝えられなければならず、それに加えて、一次故障インタフェースが識別されなければならない。（米国カリフォルニア州パロアルト所在のヒューレット・パッカード社によって市販されている)図４のＥＣＳ４０８のような事象相関システムが事象の２つのタイプの間を区別し相関または削除することができるようにするため、この付加要件が必要とされる。
【００６１】
これは、付加的var-bindを通常の一次故障事象形式に追加することによって達成される(SNMP var-bindの詳細はMarshall Rose著'Simple Book'に記載されている)。この付加的var-bindは、...一次故障Uuidと呼ばれ、対応する一次故障事象の事象UUIDを含む(UUIDはUniversally Unique IDentifierを略称したもので、各事象にとって特有のハンドルである)。ネットワーク・エレメントの状態を変更するために使用されるlibtopmには二次故障状態変更という独立したＡＰＩがある。このＡＰＩ呼び出しのパラメータは、一次故障のために使用された呼び出しと同じものに加えて、一次故障ネットワーク・エレメントのovwDbldがプラスされる(動作も異なる)。
【００６２】
一次故障状態変更ＡＰＩが呼び出されると、ovtopmd１１６は、トポロジー・データベース１１８の中の状態を変更してＮＮＭ5.01にあるような適切な事象を送出する。加えて、それはそのプロセス・メモリにダウン事象のUUIDを記録する。
【００６３】
二次故障状態変更ＡＰＩが呼び出されると、ovtopmd１１６は、トポロジー・データベース１１８の中の状態を変更してＮＮＭ5.01にあるような事象を構築する。更に、ovovtopmd１１６はパラメータowvDbldを取得して、対応する一次故障事象UUIDを照合し、一次故障Uuid var-bindを作成して二次故障事象に含める。次に事象を発信する。二次故障事象のUUIDは、後の使用に備えて、ovtopmdのプロセスのメモリに記録される。
【００６４】
減速ポーリング・リスト
減速ポーリング・リストは、netmonがアップ状態のインタフェースへのポーリングを遅延させることなくダウン状態のインタフェースへのポーリングを実行することを可能にする。ダウン状態のインタフェース(次のポーリングの際もなおダウンしている可能性がある)をアップ・インタフェースから分離することによって、netmonは、アップからダウンへの移行についてネットワーク管理者にタイムリに警告することができる。netmonは減速ポーリング・リスト上のインタフェースに対しての再試行を少なくすることができ、それによって、これら動作を実行するために浪費される時間およびネットワーク・バンド幅が制約される。
【００６５】
ＰＭＤ／ＥＣＳ事象分散
図１は、事象システム・バス１１４を含むＮＮＭ5.01アーキテクチャの単純化された図である。事象システム・バス１１４は実際には存在しないこともある。むしろ、あらゆる通信ツール１２０、２０２−２０６とＰＭＤ(ポスト・マスタ・デーモンPost Master Daemon)プロセス１０２の間にソケット接続が存在するかもしれない(図２参照)。送信元２０２はＰＭＤプロセス１０２に事象を送信し、ＰＭＤ１０２があらゆる受け取り手１２０、２０４、２０６に事象を分配する。あらゆるプロセス１０２、１２０、２０２−２９６が送信元とも受け取り手ともなれるように、接続は双方向性であるかもしれない。
【００６６】
本発明のシステムの好ましい実施形態において、事象システム２００は、事象相関システム(ＥＣＳ)４０８をＰＭＤ４０６へ組み入れることによって強化される(図４参照)。ＥＣＳ４０８はヒューレット・パッカード社によって市販されている製品の１つである。この製品は、ＨＰ部品番号J1095-90203によって識別される'ECS 2.0 Designer's Reference Manual'に詳細に記述されている。図４は、ＰＭＤ／ＥＣＳアーキテクチャ５０２を示す。ＰＭＤ４０６に流入するすべての事象は、以下のように事象を取り扱うことができるＥＣＳエンジン４０８に流入する。
【００６７】
・事象は変更せずにＥＣＳエンジン４０８を単に通過することができる。
【００６８】
・事象は一定時間ＥＣＳエンジン４０８に保存され、後に解放されることができる。
【００６９】
・事象はＥＣＳエンジン４０８によって削除されることができる。すなわち事象は流入するが流出しない。
【００７０】
・事象は削除から独立した他の事象と相関されることができる。すなわち、親事象を指定する事象に属性が付加される。これは、事象ブラウザ１２０に新しい下位表示機能を備えさせる。
【００７１】
・ＥＣＳ４０８に入る事象に加えてまたはその代わりに新しい事象が生成されることができる。
【００７２】
・後続の事象の意味を解釈する助けとなるように、一層長い時間事象がＥＣＳ４０８に保存され状態情報として使用されることができる。
【００７３】
・現在の事象の意味を解釈する助けとなるように、事象はＰＭＤ４０６およびＥＣＳエンジン４０８にとって外部のデータの照会を誘発することができる。
【００７４】
事象ブラウザ１２０、いくつかのＮＮＭプロセスおよび大部分の第３者ツールが、相関事象バス４０２に接続する。エンジンの回路４０８の論理がそうするように設計されていれば、このバス４０２は削除または遅延されたいくつかの事象を保持することができる。オリジナルのＮＮＭプロセス２０４／２０６の多くは、システムの中のすべての事象を見ることができるようにするため、相関事象追加バス４０４に接続する。
【００７５】
ＢＣＳエンジンの構成の詳細な記述は本明細書の目的を越える。要約すれば、その論理部は２つの層で構成される。第１の層は、開発者ＧＵＩおよび種々の機能性を持つ種々のタイプのＥＣＳ回路ノードを使用して構築されたグラフィック・データ流れ機構(ＥＣＳ回路)である。回路の各ノードは、事象相関記述言語(すなわちＥＣＤＬ)で書かれたコンピュータ・プログラムを含むことができる。ＥＣＳ回路エレメントのうちの１つは、注釈ノード４１２と呼ばれるもので、ＥＣＳ４０８に含まれないデータに関してＥＣＳ４０８にとって外部の注釈サーバ５１０に照会を行うために使用される。
【００７６】
ユーザ構成属性
上記の事象システムは、性能および可用性の種々のトレードオフを考慮して多くの可能な動作のうちの１つを得るためユーザによって構成されることができる。以下のリストは、主な構成可能な属性を記述する。
【００７７】
・Critical_Node_Filter_Name<文字列>：このnetmonパラメータは、netmonが危機的ノードおよび通常ノードを区別することを可能にするトポロジー・フィルタを指定する。危機的ノードに関する事象は相関させることはできるが、たとえそれが二次的なものでもＥＣＳ４０８またはnetmonによって削除されることは決してできない。
【００７８】
・Critical_Node_Sec_Status <ダウン | 不明>：このnetmonパラメータは、二次故障を持つ危機的ノードに関する状態変更事象のため使用する新しい状態を記述する。一次故障は、ノードが危機的であろうが通常のものであろうが関係なく、常にダウン状態を受け取る。
【００７９】
・Normal_Node_Sec_Status <ダウン | 不明 | 無視>：このnetmonパラメータは、二次故障を持つ通常ノードに関する状態変更事象のため使用する新しい状態を記述する。値が無視であれば、ノードの状態は変わらない。たとえそれがアクセス不能であっても、それはマップ上にアップとして残る。
【００８０】
・Sec_Fail_Event_Suppress_Switch <偽 | 真>：このnetmonブーリアン・パラメータは、ルータ・ダウン注釈サーバ・インタフェース４１０を経由してＥＣＳ４０８に送られ、通常ノードに関する二次故障を削除すべきか否かをＥＣＳ４０８に通知する。
【００８１】
これらパラメータを参照する以下の記述は上述のパラメータの順序で参照する。例えば、[＜＞, ダウン，無視，真]は、フィルタなし、Critical_Node_Sec_Status=ダウン、Normal_Node_Sec_Status=無視およびSec_Fail_Event_Suppress_Switch=真を標示する。
【００８２】
[<>, ダウン,不明 ,真]構成の動作
図１は、ＮＮＭ5.01に関するシステム動作を示す。図５は、[<>, ダウン,不明 ,真]構成が選択される場合の本発明のシステムに関するシステム動作を示す。このシステムにおいて、netmonはインタフェースＢ.１が一次故障であり、インタフェースＢ.２、Ｃ.１、Ｃ.２、Ｘ.１、Ｙ.１およびＺ.１が二次故障であると認識した。インタフェースＢ.１が一次故障であるので、それには危機的状態が与えられ、ovwにおいて赤色で表示される。また、インタフェースＢのダウン事象が発信される。
【００８３】
フィルタが指定されていないので(すなわちCritical_Node_Filter_Name=" ")、すべてのノードは通常ノードとみなされ(すなわち危機的ノードはない)、Critical_Node_Sec_Status属性は使用されない。Normal_Node_Sec_Status=不明であるので、すべてのノード１２４、１２８−１３６上のすべての二次故障インタフェースは青色で表示され(図５の表示１０８において斜線入り円で表され)、不明状態を表す。
【００８４】
一旦netmonが二次故障インタフェースと認めると、すべての二次故障インタフェースに関して状態変更不明事象が、netmon／ovtopmd１１０／１１６によって発信される。しかしながら、ＥＣＳ４０８は、Sec_Fail_Event_Suppress_Switch=真であるので、事象を削除する。従って、二次故障事象は、事象ブラウザxnmevents.web１２０の上位表示５２２に表示されない。
【００８５】
事象ブラウザの新しい機能性によって、選択された上位事象に関連した(相関する)二次故障事象を取り出すためのメニュー・オプションをユーザが起動することができる。この場合、インタフェースＢ.１ダウンの選択および「相関事象表示」の呼び出しによって、相関二次故障事象を表示する別のダイアログが取り出される。
【００８６】
図１を図５と比較すれば、本明細書の従来技術の項で記述した諸問題が図５のアーキテクチャおよび構成によって解決されていることが認められるであろう。ovw表示１０４は、稼働するノードならびにインタフェース(緑色表示)、一次故障ノード(赤色表示)およびすべての二次故障ノード(青色表示)を識別する。事象ブラウザ表示５２２は二次故障５２４をきちんと配列し、ＮＡがメンテナンスを必要とするインタフェースを単純に識別している。
【００８７】
危機的ノード・フィルタ名およびＥＣＳ注釈サーバ
ユーザが指定することができるCritical_Node_Filter_Name属性は、ＮＮＭ5.01ネットワーク・フィルタ言語を使用してネットワーク・ノードの(危機的および通常という)２つのクラスを定義する。この言語によって、ユーザはデータベースの属性に基づいたトポロジー・データベース１１８のエレメントのサブセットを記述することができる。ユーザは、例えば、すべてのルータ１２４、１２８およびipAddress 15.1.2.*を持つノードからなるグループを指定することができる。
【００８８】
組織の生産性にとってアクセス可能性が不可欠なネットワーク・エレメントをユーザが識別することができるようにするためこのメカニズムが提供される。例えば、ルータ１２４、１２８およびサーバは不可欠なものであるが、ワークステーション１３２−１３６およびＰＣはそうではないかもしれない。アクセス不能で一次故障であるインタフェースは、どの分類に属しているかには関係なく、常にダウン状態を与えられる。しかしながら、インタフェースがアクセス不能で二次故障であれば、危機的ノード・フィルタを使用してシステムの動作を定めることができる。
【００８９】
(フィルタによる定義およびnetmonの評価に従って)インタフェースがアクセス不能であって危機的ノード上に位置すれば、Critical_Node_Sec_Status属性値が、インタフェースに実際に与えられる状態を定義する。可能な値は、ダウンおよび不明である。この属性はnetmonによって評価される。netmonは、インタフェースの状態を変更するようにovtopmd１１６に指示する。
【００９０】
(フィルタによる定義およびnetmonの評価に従って)インタフェースがアクセス不能であって通常ノード上に位置すれば、Critical_Node_Sec_Status属性値が、インタフェースに実際に与えられる状態を定義する。可能な値は、ダウン、不明および無視である。この場合も、この属性はnetmonによって評価され、netmonがインタフェースの状態を変更するようにovtopmd１１６に指示する。
【００９１】
ダウンおよび不明の値は、危機的ノードの動作の場合と同様な通常ノード動作に結びつく。しかしながら、無視の値は、通常ノード上のアクセス不能インタフェースを無視するようにnetmonに指示する。すなわち、インタフェースの状態は変更されず、このインタフェースに関するいかなる事象も送出されない。そのインタフェースがたとえアクセス不能でもマップ上はアップのままとされる。
【００９２】
このような構成は、組織の生産性にとって不可欠でないノードに関してネットワーク・トラフィックおよびＮＮＭ処理性能を最小にすることが望ましい時、役立つ。この状況においては、netmonは、ネットワーク・トラフィックが更に最小にされnetmon状態ポーリングが予定した通りのまま実行されるようにするため、インタフェースを減速ポーリング・リストに書き込む。
【００９３】
このフィルタは、二次故障インタフェースがダウン状態にあることを検出する時上述のようにnetmonによって使用される。このフィルタは、また、対応する事象が削除されるべきか否かを決定するためＥＣＳエンジン４０によって必要とされる。netmonがすでに危機的ノードと通常ノードを区別するように設定されているので、netmonがＥＣＳエンジン４０８の中のルータ・ダウン回路にこのような区別を通知することには意味がある。
【００９４】
netmonは、ＥＣＳ４０８によって提供される注釈サーバ・メカニズム４１２を通してこれを実行する。ＥＣＳ４０８における回路が受け取った事象が危機的ノードまたは通常ノードに対応するか否かを知る必要がある時はいつでも、事象は対応する注釈回路ノード４１２へ送られ、そこからＵＮＩＸドメイン・ソケットを使用して注釈サーバ・プロセス５１０に照会が送られる。ＵＮＩＸドメイン・ソケット以外のメカニズムはウィンドウズＮＴ上で使用される。
【００９５】
照会は、ルータダウン注釈サーバ５１０に到着し、同サーバ５１０は、ovwDbld引数をそのフィルタ評価機構を通過させ、ブール結果をＥＣＳ回路４０８の注釈回路ノード４１２へ送出する。この特定の注釈サーバは、netmonの中に組み込まれる(図４参照)。複数netmonが稼働している分散処理システムにおいては、管理ステーション５１０に関するCritical_Node_Filter_Name属性は収集ステーションの値とは異なる点に注意する必要がある。
【００９６】
ＥＣＳルータ・ダウン回路
ＥＣＳエンジン４０８はかなりの能力を持つけれども、論理の大部分が性能理由のためにnetmonプロセスに置かれるので、その潜在能力はルータ・ダウン回路によってほとんど使用されない。図６は回路論理６００を示す。
【００９７】
事象が状態変更事象(ノード・ダウンまたはインタフェース・ダウン)でなければ(ブロック６０２／６０４)、または事象が(付加的var-bindの存在のため)一次故障であれば(ブロック６０６)、事象は直ちに他のＥＣＳ回路エレメントに渡される(ブロック６０８／６２６)。さもなければ、事象は、それが一次故障事象に関連づけられている二次故障経路に流れる(ブロック６１０／６１２)。この相関動作は、現在事象の親事象を識別するログ・ファイルに属性を記録すること以外の何物でもない。親事象(一次故障事象)のUUIDが付加的var-bindに含まれているので、これは可能である。この相関によって、事象ブラウザが下位表示機能を備えることができる。
【００９８】
この時点で、回路は、事象を削除しなければならないか否か決定する必要がある。事象が危機的ノードに対応していれば(ブロック６２０)、この重要なサーバまたはルータが直ちに修復されなければらないことをＮＡが知ることが重要であるので、その事象は削除されない(ブロック６１８)。回路は、netmonに埋め込まれたルータ・ダウン注釈サーバに問いただすことによって、ノードが危機的か通常か決定する(ブロック６１６)。
【００９９】
事象が通常ノードに対応していれば(ブロック６２２)、回路はSec_Fail_Event_Suppress_Switch属性の値を検証して、それに応じて動作する(ブロック６２４／６２６／６２８)。これらの属性のすべては、netmonの構成の中に構成される。この属性は実際にはnetmonによって使用されない。それはＥＣＳ回路６００によって使用されるだけである。従って、この属性の値は、また、注釈サーバ・インタフェースを経由しててＥＣＳに通知される。
【０１００】
[<サーバ・フィルタ>, ダウン,不明 ,真]構成の動作
図７は、[<サーバ・フィルタ>, ダウン,不明 ,真]構成のシステム動作を示す。この構成は、ユーザがCritical_Node_Filter_Name属性を使用するフィルタを指定したので、図５の構成と異なる。図７のフィルタは、ノードＺを危機的ノードとして識別するように設計された。例えば、組織の生産性は、ノードＺ上で稼働するアプリケーション・サーバの可用性に依存する場合がある。
【０１０１】
このシナリオにおいては、netmonはインタフェースＢ.１が一次故障であり、インタフェースＢ.２、Ｃ.１、Ｃ.２、Ｘ.１、Ｙ.１およびＺ.１が二次故障であると認識している。Ｂ.１が一次故障インタフェースであるので、それは危機的状態を与えられ、ovwに赤色で表示され、インタフェースＢダウン事象が発信される。インタフェースＺ.１は危機的ノード上に位置する二次故障インタフェースであるので、ダウンという値を持つように構成されたCritical_Node_Sec_Status属性によって指定される状態を与えられる。ノードＺおよびインタフェースＺ.１はovwに赤色で表示され、インタフェースＺ.１ダウン事象が発信される。
【０１０２】
残りのすべての二次故障インタフェースは、不明という値を持つNormal_Node_Sec_Status属性によって指定される状態を与えられる。これらのインタフェースは、不明状態を表すように青色で表示される。
【０１０３】
一旦netmonが二次故障インタフェースと認識すれば、すべての非危機的／二次故障インタフェースに関して状態変更不明事象が、netmon／ovtopmdによって発信される。しかしながら、ＥＣＳ４０８は、Sec_Fail_Event_Suppress_Switch=真であるので、事象を削除する。従って、危機的ノードに対応しない二次故障事象は、事象ブラウザxnmevents.web１２０の上位表示５２２に表示されない。
【０１０４】
事象ブラウザ１２０の新しい機能性によって、選択された上位事象に関連した(相関する)二次故障事象を取り出すためのメニュー・オプションをユーザが起動することができる。この場合、インタフェースＢ.１ダウンの選択および「相関事象表示」の呼び出しによって、相関二次故障事象を表示する別のダイアログが取り出される。インタフェースＺ.１は上位表示７２２および下位表示７２４の両方に現れる点注意する必要がある。インタフェースＺ.１は、危機的ノード上に位置するので、上位表示７２２に表示される。インタフェースＺ.１は、インタフェースＢ.１の故障のためアクセス不能であるので、下位表示７２４に表示される。
【０１０５】
図１を図７と比較すれば、本明細書の従来技術の項で記述した諸問題が図７のアーキテクチャおよび構成によって解決されていることが認められるであろう。ovw表示１０４／１０８は、稼働するノードならびにインタフェース(緑色表示)、一次故障ノード(赤色表示)およびすべての二次故障ノード(青色表示)を識別する。事象ブラウザ表示７２２は二次故障をきちんと配列し、ＮＡがメンテナンスを必要とするインタフェースを単純に識別している。
【０１０６】
[<サーバ・フィルタ>，不明 ,無視，真]構成の動作
図８は、[<サーバ・フィルタ>，不明 ,無視，真]構成のシステム動作を示す。この構成は、危機的ノードの二次故障が不明の状態を与えられなければならないことおよび通常ノード上の二次故障が無視されなければならないことをユーザが指定したという点において図７に示された構成と異なる。
【０１０７】
この構成は利点および不利を持つ。主な利点は、収集ステーションおよび管理ステーションに関して状態変更および事象がほとんど生成されないのでシステムおよびネットワーク性能が非常によいという点である。ovw表示１０４／１０８および事象ブラウザ表示８２２は、危機的ノードのインタフェースの一次故障および二次故障が異なる色で表示され、重要でない二次故障という不要なものは表示されないので、故障の影響を一層よく伝える。不利な点は、重要でない二次故障がアクセス不能の時アクセス可能として表示される点である。この点は、ネットワーク管理者がこの構成を選択する際に評価すべきトレードオフである。
【０１０８】
このシナリオにおいては、netmonは、インタフェースＢ.１が一次故障であり、インタフェースＢ.２、Ｃ.１、Ｃ.２、Ｘ.１、Ｙ.１およびＺ.１が二次故障であると認識する。
【０１０９】
Ｂ.１が一次故障インタフェースであるので、それは危機的状態を与えられ、ovw１０４／１０８に赤色で表示される。更に、インタフェースＢダウン事象が発信される。インタフェースＺ.１は危機的ノード上に位置する二次故障インタフェースであるので、不明という値を持つように構成されたCritical_Node_Sec_Status属性によって指定される状態を与えられる。インタフェースＺ.１はovwに青色で表示され、インタフェースＺ.１不明事象が発信される。
【０１１０】
残りのすべての二次故障インタフェースは無視される。状態変更は起こらないし、事象はなにも発信されない。それら残りのインタフェースはアップという状態値を表現するように緑色で引き続き表示される。しかしながら、netmonはバックアップ・ポーリング・モードに入る。
【０１１１】
図８は、いくつかのインタフェース・アップ事象が集合的に表示されている点に注意する必要がある。このような表現は誤解を招きやすい。これらは、初期的にｎetmonがノードおよびインタフェースを検出する時インタフェース・アップ事象が送信されることを例示するために示されている。しかし、それは一度発生するだけである。ノードがネットワーク上で物理的に移動されない限りそれは再び決して起こらない。
【０１１２】
典型的な動作の間、ＮＡは、インタフェースＢ.１ダウンおよびインタフェースＺ.１不明という２つの事象に出会うだけである。同じように、図１、図５および図７のインタフェース・アップ事象はノード１２４、１２８−１３６が検出される時にだけ発生する。これら４つのシナリオの各々における表示は、故障ネットワーク・エレメントを正確に指摘することを試みるので、ＮＡにとってよく整理された有用なものであろう。
【０１１３】
事象ブラウザ１２０の新しい機能性によって、選択された上位事象に関連した(相関する)二次故障事象を取り出すためのメニュー・オプションをユーザが起動することができる。この場合、インタフェースＢ.１ダウンの選択および「相関事象表示」の呼び出しによって、相関二次故障事象を表示する別のダイアログが取り出される。この場合も、インタフェースＺ.１が上位表示８２２および下位表示８２４の両方に現れる点注意する必要がある。インタフェースＺ.１は、危機的ノード上に位置するので、上位表示８２２に表示される。インタフェースＺ.１は、インタフェースＢ.１の故障のためアクセス不能であるので、下位表示８２４に表示される。
【０１１４】
[<>，ダウン, ダウン，偽]構成の動作
この構成は、すべてのアクセス不能インタフェースがダウン状態を与えられovwに赤色で表示され、削除される事象はないので、ＮＮＭ5.01に非常に類似した動作をシステムに強制する(図１参照)。相違するシステム動作は次の通りである。
【０１１５】
・SecondaryFailureインタフェースはnetmonによってなお認識され、それらのノード・ダウン／インタフェース・ダウン事象は付加的var-bindを含む。
【０１１６】
・二次故障は削除されないけれども、それらはなおも一次故障と関連づけられていて、下位画面を通して観察される。
【０１１７】
・減速ポーリング・アルゴリズムが性能向上を提供する。
【０１１８】
分散アーキテクチャ
上述のシステムおよび方法は、収集ステーションおよび管理ステーションを含む分散環境に容易に適応できる。上記システムおよび方法が容易に適用可能な分散環境の例は、米国特許出願第08/705,358号に記載されているものである。
【０１１９】
以上、本発明の好ましい実施形態を記述したが、本発明の概念は上記以外の種々の形態で実施および利用することが可能である点は理解されるべきであろう。
【０１２０】
【発明の効果】
本発明によって、ネットワークの故障発生の際故障の根本原因であるネットワーク・エレメントと故障したエレメントのためにアクセス不能となったネットワーク・エレメントが明確に区別され、その状態情報が理解し易い形式で画面に表示されるので、ネットワーク管理者が迅速に適切な復旧措置を講ずることが可能とされる。
【図面の簡単な説明】
【図１】ＮＮＭ5.01ネットワーク管理者表示機能を示すブロック図である。
【図２】ＮＮＭ5.01事象分散システムを示すブロック図である。
【図３】ネットワーク・エレメント健康状態を表すグラフィック表示のブロック図である。
【図４】好ましい事象分散システムを示すブロック図である。
【図５】好ましいネットワーク管理者表示機能を示すブロック図である。
【図６】ＥＣＳルータダウン回路の動作を示す流れ図である。
【図７】別の好ましいネットワーク管理者表示機能を示すブロック図である。
【図８】更に別の好ましいネットワーク管理者表示機能を示すブロック図であ
【符号の説明】
１２４、１２８、１３０、１３２、１３４、１３６    ネットワーク・エレメント
５１０  ネットワーク監視機構
【図１】
0003556842.tif 000002
【図２】
0003556842.tif 000003
【図３】
0003556842.tif 000004
【図４】
0003556842.tif 000005
【図５】
0003556842.tif 000006
【図６】
0003556842.tif 000007
【図７】
0003556842.tif 000008
【図８】
0003556842.tif 000009