JP2004152320A - ネットワーク管理システムおよびネットワーク管理方法 - Google Patents

Abstract

【課題】
ＳＮＭＰに基づいて大規模な通信ネットワークを階層管理し、大規模な通信ネットワークを低トラフィックおよび低コストで管理する。
【解決手段】
複数のエージェントが、ネットワーク資源単位に当該ネットワーク資源に関する情報及び当該ネットワーク資源と他のネットワーク資源との通信コネクションに関する情報を管理オブジェクトとして管理し、サブマネージャが、複数のエージェントとＳＮＭＰを用いて通信することにより管理オブジェクトを収集し、収集した管理オブジェクトのうち各ネットワーク資源に関する情報を集約した新たな管理オブジェクト及び複数のネットワーク資源に関連する通信コネクションに関する情報を集約した新たな管理オブジェクトを各々生成して管理し、統合マネージャが、サブマネージャとＳＮＭＰを用いて通信することにより新たな管理オブジェクトを参照する。
【選択図】 図２

Description

本発明は、ネットワーク管理システムおよびネットワーク管理方法に係り、特に、エージェント、サブマネージャ、統合マネージャにより階層的にネットワーク資源を管理し、それらの間の通信プロトコルとしてＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ ｍａｎａｇｅｍｅｎｔ ｐｒｏｔｏｃｏｌ）を用いるネットワーク管理システムおよびネットワーク管理方法に関する。

一般に、通信ネットワークの管理システムは、マネージャ、エージェントの２種類のサブシステムにより構成され、マネージャはエージェント単位にネットワーク資源を管理・制御する。また、エージェントは通信ネットワークの資源単位にその構成情報、状態情報等の管理オブジェクトを管理・制御する。

通信ネットワークの管理に関する国際的な標準規格には、アイ・エイ・ビー（ＩＡＢ＝Ｉｎｔｅｒｎｅｔ Ａｃｔｉｖｉｔｉｅｓ Ｂｏａｒｄ）管理標準と、オー・エス・アイ（ＯＳＩ＝Ｏｐｅｎ Ｓｙｓｔｅｍｅｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）管理標準の２つが存在し、これらの管理基準を使用したネットワークにあっては、次のようにしてネットワーク資源を管理している。

（１）ＩＡＢ管理標準を使用したネットワーク管理システム
通信ネットワークが大規模になった場合、当該通信ネットワークを分割し、分割された通信ネットワーク（以下、サブネットワークと言う）のそれぞれに、マネージャ、エージェントを配置してネットワーク資源を管理する。

この場合、ＩＡＢ管理標準における資源管理を行うに際しては、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ ｍａｎａｇｅｍｅｎｔ ｐｒｏｔｏｃｏｌ）が使用される。なお、このＳＮＭＰに関する規格は、アール・エフ・シー・１１５７、シンプル・ネットワーク・マネージメント・プロトコル（RFC 1157，″A Simple Network Management Protocol″）で規定されている。

（２）ＯＳＩ管理標準とＩＡＢ管理標準を併用した階層型ネットワーク管理システム
「分散ＬＡＮドメインのＯＳＩによる統合管理」（宮内他、情報処理学会論文誌、１９９３年、６月号、ｐｐ１４２６〜１４４０，以下、参考文献〔１〕）に記載されているように、各ＬＡＮ（ローカル・エリア・ネットワーク）をＩＡＢ管理基準に基づくサブマネージャにて管理し、サブマネージャとその上位の統合マネージャ間はＯＳＩ管理基準に基づいてネットワーク資源を管理する。

すなわち、サブマネージャにおいてＩＡＢ管理標準に従ってネットワーク資源を管理し、それをＯＳＩ管理標準へ変換して統合マネージャに伝達し、統合マネージャにおいてネットワーク全体の資源を管理する。

ところで、大規模ネットワークを管理する場合、管理パケットの削減およびマネージャの簡略化等を図る上で階層構造で管理した方が効果的である。

しかしながら、ＩＡＢ管理標準のＳＮＭＰを用いた上記ネットワーク管理システムにあっては、階層管理を考慮していないため、マネージャとエージェントとの間にサブマネージャを配置したとしても、マネージャとサブマネージャ間で伝達する管理情報の構造やその収集方法について解決しなければ、階層管理を実現できないという問題がある。すなわち、エージェントの一群を管理、制御する階層型ネットワーク管理システムは実現できないという問題がある。

この場合、ＳＮＭＰｖ２（ＳＮＭＰバージョン２）の標準では、マネージャからマネージャに対してイベントを通知することが可能であるが、ＳＮＭＰ同様、階層管理を考慮していないため、マネージャとエージェントとの間にサブマネージャを配置したとしても、マネージャとサブマネージャ間で伝達する管理情報の構造やその収集方法について解決しなければ、階層管理を実現できないという問題がある。

一方、参考文献〔１〕に記載されているＯＳＩ管理システムにあっては、サブマネージャはＯＳＩ管理標準が実現されるＯＳＩ標準の通信サービスと、ＩＡＢ管理標準が実現されるＩＡＢ標準の通信サービスの両方を実装しなければならないため、サブマネージャが大規模になってしまうという問題がある。

また、ＬＡＮではＩＡＢ標準の通信サービスが使用されている。そして、通信ネットワークの運用では、ＬＡＮ間でもＩＡＢ標準の通信サービスを使用することが通常の運用である。したがって、参考文献〔１〕に記述されている管理システムでは、ＷＡＮ（ワイド・エリア・ネットワーク）上でＩＡＢ管理標準の標準規格を使用するにも関わらず、ＯＳＩ管理標準の標準規格を使用しなければならず、この点でもサブマネージャの構成が大きくなるという問題がある。

さらに、複数の管理標準で管理される通信ネットワークを統合マネージャで統一化して階層管理する場合、そのための管理情報の変換や統合マネージャの負荷を軽減するための管理機能の代行、分散化等を予め考慮しておく必要があるが、参考文献〔１〕の管理システムでは、管理機能の代行、分散化等を考慮していないため、ネットワークが大規模になるに従って統合マネージャとサブマネージャ間で管理情報を交換する際に使用する管理パケットの数が増加してしまうという問題がある。

本発明の目的は、ＩＡＢ管理標準のＳＮＭＰに基づいて大規模な通信ネットワークを階層管理し、大規模な通信ネットワークを低トラフィックおよび低コストで管理することができるネットワーク管理システムおよびネットワーク管理システムを提供することである。

本発明は、複数のエージェントが、ネットワーク資源単位に当該ネットワーク資源に関する情報及び当該ネットワーク資源と他のネットワーク資源との通信コネクションに関する情報を管理オブジェクトとして管理し、サブマネージャが、複数のエージェントとＳＮＭＰを用いて通信することにより管理オブジェクトを収集し、収集した管理オブジェクトのうち各ネットワーク資源に関する情報を集約した新たな管理オブジェクト及び複数のネットワーク資源に関連する通信コネクションに関する情報を集約した新たな管理オブジェクトを各々生成して管理し、統合マネージャが、サブマネージャとＳＮＭＰを用いて通信することにより新たな管理オブジェクトを参照するものである。

上記手段によると、サブマネージャは自己の管理範囲に属するエージェントを介して同管理範囲の管理オブジェクトを収集し、その収集情報を統合マネージャからの参照要求に応じて統合マネージャに通知する。

この場合、収集情報は、複数の管理オブジェクトの集合として保持され、統合マネージャからの参照要求に応じてアクセスされて統合マネージャに通知される。

これによって、ＩＡＢ管理標準のＳＮＭＰという単一のプロトコルに基づいて大規模な通信ネットワークを階層管理することができ、しかも単一プロトコルであるのでサブマネージャの構成を簡単にすることができる。

また、複数の識別子で管理している各エージェントからの複数の管理オブジェクトを集約して統合マネージャに通知する。従って、少量の管理パケットで統合マネージャとサブマネージャ間の管理情報を伝達することができるうえ、統合マネージャの負荷を軽減することができる。

本発明により、ＩＡＢ管理標準のＳＮＭＰに基づいて大規模な通信ネットワークを階層管理し、大規模な通信ネットワークを低トラフィックおよび低コストで管理することができるネットワーク管理システムおよびネットワーク管理方法を提供できる。

以下、本発明を図面に示す一実施例に基づいて詳細に説明する。

図１は、本発明を適用する通信ネットワークの一実施例を示すシステム構成図であり、複数のＬＡＮ１，２，３がＷＡＮ（ワイドエリアネットワーク）４によって結合されている。

このうち、ＬＡＮ１には、ネットワーク資源単位にその構成情報、状態情報等の管理オブジェクトを管理・制御する複数のエージェント２０ａ−１，２０ａ−２およびエージェント未実装のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ノード３０ａが接続され、さらにこれらエージェント２０ａ−１，２０ａ−２を介してＬＡＮ１内の管理オブジェクトを管理・制御するサブマネージャ１０ａが接続されている。

また、ＬＡＮ２には、ネットワーク資源単位にその構成情報、状態情報等の管理オブジェクトを管理・制御する複数のエージェント２０ｂ−１，２０ｂ−２が接続され、さらにこれらエージェント２０ｂ−１，２０ｂ−２の管理下の管理オブジェクトを管理・制御するサブマネージャ１０ｂが接続されている。さらに、エージェント２０ｃ，エージェント未実装のＩＰノード３０ｃが接続されると共に、これらエージェント２０ｃの管理下の管理オブジェクトを管理・制御するサブマネージャ１０ｃが接続されている。

すなわち、ＬＡＮ２においては、２つのサブマネージャ１０ｂ，１０ｃで管理オブジェクトが管理されるようになっている。

一方、ＬＡＮ３には、複数のエージェント２０−１，２０−２が接続され、さらにこれらエージェント２０−１，２０−２の管理下の管理オブジェクトを管理・制御すると共に、ＷＡＮ４およびサブマネージャ１０ａ，１０ｂ，１０ｃを通じて、これらの管理下の管理オブジェクトを管理・制御する統合マネージャ５０が接続されている。すなわち、ＬＡＮ３には、ネットワーク全体の資源を階層管理する統合マネージャ５０が接続されている。

図２は、エージェント、サブマネージャおよび統合マネージャの論理的関係を示す図であり、ＬＡＮ１に接続されたサブマネージャ１０ａとエージェント２０ａ−１，２０ａ−２との間はＩＡＢ管理標準のＳＮＭＰおよびＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍａｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）を使用して管理オブジェクトを管理するようになっている。また、サブマネージャ１０ａとエージェント未実装のＩＰノード３０ａとの間は、ＩＣＭＰを使用して管理オブジェクトを管理するようになっている。そして、サブマネージャ１０ａには、管理範囲のエージェントを通じて収集した複数の管理オブジェクトの集合を木構造で表現したＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）という形式で保持する収集ＭＩＢデータベース１７０ａが接続されている。

同様に、ＬＡＮ２に接続されたサブマネージャ１０ｃとエージェント２０ｃとの間はＩＡＢ管理標準のＳＮＭＰおよびＩＣＭＰを使用して管理オブジェクトを管理するようになっている。また、サブマネージャ１０ｃとエージェント未実装のＩＰノード３０ｃとの間は、ＩＣＭＰを使用して管理オブジェクトを管理するようになっている。そして、サブマネージャ１０ｃには、管理範囲のエージェントを通じて収集した複数の管理オブジェクトの集合を木構造で表現したＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）という形式（以下、ＭＩＢ形式と言う）で保持する収集ＭＩＢデータベース１７０ｃが接続されている。

なお、サブマネージャ１０ｂおよびエージェント２０−１，２０−２についても同様の論理的関係で統合マネージャ５０に接続されている。

図３は、サブマネージャ１０の内部構成の一実施例を示す機能ブロック図であり、次のような機能モジュールから構成されている。

（１）通信制御機能１００
（２）管理範囲監視機能１１０
（３）収集データベース管理機能１２０
（４）自エージェント機能１３０
（５）サブマネージャエージェント機能１４０
（６）集約化機能１５０
（７）トラップ管理機能１６０
各機能の詳細は次の通りである。

（１）通信制御機能１００
ＩＡＢ管理標準では、ネットワーク管理のためのプロトコルをエス・エヌ・エム・ピー（ＳＮＭＰ、以降、単にＳＮＭＰと記述する）と名付けている。この規格は、アール・エフ・シー・１１５７、シンプル・ネットワーク・マネージメント・プロトコル（RFC 1157，″A Simple Network Management Protocol″）で規定されている。

当該通信制御手段１００は、統合マネージャ５０およびサブマネージャ１０自身からのＳＮＭＰ要求の受信、およびＳＮＭＰトラップを受信する。

ＳＮＭＰ要求とは、統合マネージャ５０からサブマネージャ１０に対する管理オブジェクトの取得要求およびサブマネージャ１０からエージェント２０に対する管理オブジェクトの取得要求のことである。

受信したＳＮＭＰ要求は、そのプロトコル内に存在する管理オブジェクト識別子に従い、自エージェント機能１３０又はサブマネージャエージェント機能１４０に通知するとともに、その結果をＳＮＭＰ要求元である統合マネージャ５０又はサブマネージャ１０自身に応答する。また、受信したＳＮＭＰトラップは、トラップ管理機能１６０に通知する。

（２）管理範囲監視機能１１０
サブマネージャ１０のネットワーク管理者が指定した環境設定ファイル１８０を参照し、サブマネージャ１０の管理範囲として指定されたＩＰアドレスの範囲を取得する。指定されたＩＰアドレス群（エージェントの実装有無にかかわらない）に対して、ＭＩＢ−IIで定義された特定の管理オブジェクトを取得するためのＳＮＭＰ要求およびＩＣＭＰエコー要求を定期的に発行し、その結果であるＳＮＭＰ応答およびＩＣＭＰエコー応答を取得する。

この場合、定期的に発行するＳＮＭＰ要求およびＩＣＭＰエコー要求のポーリング間隔、およびＳＮＭＰプロトコル上に記述するコミュニティ名は、環境設定ファイル１８０を参照して取得する。

定期的に取得した結果からＭＩＢ形式の情報を作成し、最新のＭＩＢ形式の情報をメモリ中に保存するとともに、収集データベース管理機能１２０に渡し、収集ＭＩＢデータベース１７０に格納させる。

また、集約化機能１５０に対しては、管理範囲のＩＰアドレスおよびステータスとエージェントの実装有無の各情報の参照を可能とさせる。

さらにトラップ管理機能１６０に対しては、管理範囲のＩＰアドレスとインデックス番号の各情報の参照を可能とさせる。

また、管理範囲のＩＰノードの追加又は削除等のような収集ＭＩＢの値を構成する情報に変化が発生したときは、統合マネージャ５０に対してその旨を通知するためのサブマネージャ拡張トラップを発行する。

なお、ＭＩＢ−IIの規格は、アール・エフ・シー・１２１３、マネージメント・インフォメーション・ベース・フォー・ネットワーク・マネージメント・オブ・ティー・シー・ピー・アイ・ピー・アイ・ピー・ベースド・インターネッツ：エム・アイ・ビー・ツー（RFC 1213，″Management Information Base for Network Management of TCP/IP Based internets: MIB-II″）で規定されている。

（３）収集データベース管理機能１２０
この収集データベース管理機能１２０は、管理範囲監視機能１１０から収集ＭＩＢの値を構成する各情報を入力した場合は、収集ＭＩＢデータベース１７０に格納し、サブマネージャエージェント機能１４０から収集ＭＩＢ値の取得要求を入力したときは、収集ＭＩＢの値を構成する各情報を管理オブジェクト形式に組立てて応答する。

（４）自エージェント機能１３０
自エージェント機能１３０は、サブマネージャ１０が存在するホストを管理するもので、統合マネージャ５０およびサブマネージャ１０自身からのＭＩＢ−IIおよびエージェント拡張ＭＩＢに対するＳＮＭＰ要求を通信制御機能１００を通じて入力し、その結果を通信制御機能１００に出力する。

環境設定ファイル１８０からは、コミュニティ名（ＳＮＭＰ要求に応答するかどうかのパスワード）を参照する。

（５）サブマネージャエージェント機能１４０
統合マネージャ５０からのサブマネージャ拡張ＭＩＢに対するＳＮＭＰ要求を通信制御機能１００から入力し、そのＳＮＭＰ要求のプロトコル内に記述された管理オブジェクト識別子により取得先を振り分ける。

すなわち、本発明においてはサブマネージャ１０が収集および集約した管理情報を統合マネージャ５０に提供するために、定期収集ＭＩＢとリアルタイム収集ＭＩＢとから成るサブマネージャ拡張ＭＩＢを定義する。

定期収集ＭＩＢは、サブマネージャ１０が管理範囲のＩＰノード群に対して定期的に収集した管理情報をＭＩＢ化したものである。

リアルタイム収集ＭＩＢは、サブマネージャ１０が統合マネージャ５０からの参照要求に従いリアルタイムに管理範囲の管理オブジェクトの情報を収集、集約（不要な情報の削除、加工）し、統合マネージャ５０に対して応答するためにＭＩＢ形式に集約したものである。

サブマネージャエージェント機能１４０は、定期収集ＭＩＢに対する参照要求の場合は、収集データベース管理機能１２０にＭＩＢ値取得要求を行い、その結果を収集ＭＩＢデータベース１７０から取得する。

リアルタイム収集ＭＩＢに対する参照要求の場合は、集約化機能１５０に対してＭＩＢ値取得要求を行い、その結果を集約化機能１５０から取得する。

その後、取得した結果を通信制御機能１００に出力する。

環境設定ファイル１８０からは、コミュニティ名（ＳＮＭＰ要求に応答するかどうかのパスワード）を参照する。

（６）集約化機能１５０
サブマネージャエージェント機能１４０からリアルタイム収集ＭＩＢ値の取得要求を入力したときは、管理範囲のエージェントを実装したＩＰノード群に対してＳＮＭＰ要求を発行する。また、その応答を取得した後、集約処理を行い、その集約したＭＩＢ値をサブマネージャエージェント機能１４０に返信する。

環境設定ファイル１８０からは、ＳＮＭＰ要求を発行時にプロトコル内に記述するコミュニティ名を参照する。

（７）トラップ管理機能１６０
通信制御機能１００から通知されたＳＮＭＰトラップを、このトラップ管理機能１６０と内部インタフェースを確立している全ての機能およびアプリケーションに通知する。また、一定時間内に通知された複数のＳＮＭＰトラップを１つのサブマネージャ拡張トラップとしてまとめ、統合マネージャ５０に中継する。

環境設定ファイル１８０からは、サブマネージャ拡張トラップを発行する時間間隔およびプロトコル内に記述するコミュニティ名等を参照する。

以下、本発明の主要部であるサブマネージャ拡張ＭＩＢの論理構造、サブマネージャの管理範囲の決定方法および監視方法、サブマネージャが受信したＳＮＭＰ要求の振り分け方法、収集ＭＩＢの管理方法、収集ＭＩＢの集約方法、ＳＮＭＰトラップ管理方法について具体的に説明する。

（１）サブマネージャ拡張ＭＩＢの論理構造
ＩＡＢ管理標準では、一般に、管理オブジェクトの論理構造は管理情報ベースと呼ばれる仮想的データベースにて定義される。この管理情報ベースはＭＩＢと呼ばれている。

なお、ＭＩＢを記述するシンタックス、および管理オブジェクトのインスタンスを識別するための方法は、アール・エフ・シー１１５５、ストラクチャ・アンド・アイデンティフィケーション・オブ・マネージメント・インフォーメーション・フォー・ティー・シー・ピー・ア イ・ピー・ベースド・インターネッツ（RFC １１５５, ″Structure and Identification of Management Information for TCP/IP-based internets″）、およびアール・エフ・シー１２１２、コンサイス・エム・アイ・ビー・デフィニションズ（RFC １２１２, ″Consice MIB Definitions″）に規定されている。

ここで、標準的なエージェント２０は、ＭＩＢ−IIに規定されている管理オブジェクトを実装している。

サブマネージャ１０は、管理範囲のＩＰノード群から特定のＭＩＢ−IIの値を取得するためのＳＮＭＰ要求およびＩＣＭＰエコー要求を発行し、その収集結果からサブマネージャ拡張ＭＩＢの値を求める。

このサブマネージャ拡張ＭＩＢは、定期収集ＭＩＢとリアルタイム収集ＭＩＢで構成される。

定期収集ＭＩＢは、サブマネージャ１０が管理範囲のＩＰノード群に対して定期的に収集した管理情報をＭＩＢ化したものである。このデータ構造は、複数のエントリからなるテーブル型の管理オブジェクト識別子と非テーブル型の管理オブジェクト識別子から構成される。

テーブル型の管理オブジェクト識別子は、管理範囲のＩＰノード単位にエントリを有し、各エントリには、管理範囲の構成情報（ＩＰアドレス、ホスト名、エージェントの実装有無、ＩＰルータの識別フラグ等）、およびＩＰ状態とｐｉｎｇ（ＩＣＭＰエコー要求パケット）の応答時間等の状態情報が保持される。

統合マネージャ５０から参照要求を受信したときは、複数の情報からなるエントリを、インデックス部分とコンテキスト部分からなる情報単位にまとめ、返信する管理オブジェクト識別子数を減らす方法が講じられる。

非テーブル型の管理オブジェクト識別子は、テーブル型の管理オブジェクト識別子の構成情報や状態情報の各内容をＩＰノード数で集計した情報を表現する。

サブマネージャ１０には、統合マネージャ５０に集計情報を提供するために集計を行う手段が設けられている。

一方、リアルタイム収集ＭＩＢは、サブマネージャ１０が統合マネージャ５０からの参照要求に従いリアルタイムに管理範囲の状態情報を収集、集約（不要な情報の削除、加工）することによって、統合マネージャ５０に返信する管理情報をＭＩＢ化したものである。

サブマネージャ１０は、ＳＮＭＰ要求を、統合マネージャ５０から受信すると共に、サブマネージャ自身からも受信する。これは、サブマネージャ１０の管理範囲にサブマネージャ自身を含むことができるためである。特に、統合マネージャ５０からリアルタイム収集ＭＩＢの参照要求を受信したときは、サブマネージャ自身に対してＳＮＭＰ要求を発行し、その結果を集約した後、統合マネージャ５０に返信する。そのため、サブマネージャ１０は複数のＳＮＭＰ要求を並列処理可能に構成されている。

サブマネージャ拡張ＭＩＢである定期収集ＭＩＢの定義例を図４〜図６に、リアルタイム収集ＭＩＢの定義例を図７〜図９に、サブマネージャ拡張トラップの定義例を図１０に示す。

図４〜図６の定期収集ＭＩＢの定義例においては、
（１）管理対象のＩＰノード数、
（２）サブマネージャとの状態がクリティカルなノード数、
（３）サブマネージャと通信可能であるが、動作していないＴＣＰ／ＩＰインタフェースが存在するノード数、
（４）全てのＴＣＰ／ＩＰインタフェースが動作しているノード数、
（５）サブマネージャの管理範囲内にあるルータの数、
（６）サブマネージャの管理範囲内にあるＳＮＭＰを実装したノード数、
（７）サブマネージャの管理範囲のＩＰノードに関する情報の一覧、
（８）管理範囲のＩＰの度毎の情報を含んだエントリ、
の定義例が示されている。

図７〜図９のリアルタイム収集ＭＩＢの定義例においては、
（１）サブマネージャの管理範囲内のＴＣＰコネクションの一覧、
（２）ＴＣＰコネクションを開設しているＩＰアドレス、
（３）smgSumTcpServerIpAddressで定義されているノードが使用しているポート番号、
（４）ＴＣＰコネクションを開設しているＩＰアドレス（smgSumTcpServerIpAddressで定義されているものの相手のアドレス）、
（５）smgSumTcpClientIpＡｄｄｒｅｓｓで定義されているＩＰノードが使用しているポート番号、
（６）管理範囲のＩＰノードで開設されているＴＣＰコネクション情報のエントリ、
の定義例が示されている。

図１０のサブマネージャ拡張トラップの定義例においては、
（１）システムが追加されたことを通知するトラップ、
（２）システムが追加されたことを通知するトラップ、
（３）中継トラップ
の定義例が示されている。

図１１は、サブマネージャ１０が定期的およびリアルタイムに収集したＭＩＢ−IIの管理オブジェクト（以降、ＭＩＢ−IIオブジェクトと言う）名を拡張ＭＩＢの管理オブジェクト名に変換する際の対応表１９０であり、ＭＩＢ−IIの管理オブジェクトを標準的に実装したエージェント２０から定期的およびリアルタイムにＭＩＢ−IIオブジェクトを収集したならば、この対応表１９０に従って拡張ＭＩＢの管理オブジェクト名に変換する。

図１２に、変換された定期収集ＭＩＢの管理オブジェクトである smgIpNodeContext の内容２００を示す。図示のように、 smgIpNodeContext は、ＩＰアドレス２１０、ホスト名２２０、ステータス２３０、ｐｉｎｇの応答時間２４０、ＳＮＭＰサポート情報２５０、ルータ情報２６０によって構成されている。

このように構成された管理オブジェクトを統合マネージャ５０により定期的に収集して表示した場合、１つのエージェント又はＩＰノードに関する複数の情報を１行で表示することができるため、１つのエージェント又はＩＰノードの状態を容易に確認することが可能になる。

図１３に、リアルタイム収集ＭＩＢの管理オブジェクトである smgSumTcpContext の内容３００を示す。図示のように、 smgSumTcpContext は、ＩＰアドレス（その１）３１０、ポート番号（その１）３２０、ステータス（その１）３３０、ＩＰアドレス（その２）３４０、ポート番号（その２）３５０、ステータス（その２）３６０、サービス名３７０によって構成されている。

このように構成された管理オブジェクトを統合マネージャ５０によってリアルタイムに収集して表示した場合、１つのＴＣＰコネクションに関する複数の情報を１行で表示することができるため、１つのＴＣＰコネクションの状態を容易に確認することが可能になる。

また、定期収集ＭＩＢには、図１４の対応表４００に示すように、この定期収集ＭＩＢの値を集計するために使用する管理オブジェクト名（識別子）が用意され、この対応表４００に従って定期収集ＭＩＢが集計される。

集計された管理オブジェクトを統合マネージャ５０で例えば１０分間隔で収集してグラフ表示した例を図２９に示す。

（２）サブマネージャの管理範囲の決定方法および監視方法
図１０のsmgCreateSystemTrapは、サブマネージャ管理範囲にＩＰノードが追加されたときに発行するサブマネージャ拡張トラップを定義したものである。拡張トラップ番号は「１」であり、変数リスト(Variable-bindings)には図１６に占めエス管理範囲テーブル５００の該当するインデックス番号５２０aを指定する。

図１０のsmgDeleteSystemTrapは、サブマネージャ管理範囲からＩＰノードが削除されたときに発行するサブマネージャ拡張トラップを定義したものである。拡張トラップ番号は「２」であり、変数リスト(Variable-bindings)には管理範囲テーブル５００の該当するインデックス番号５２０aを指定する。

図１５は、サブマネージャの管理範囲および監視範囲を決定する際に用いる環境設定ファイル１８０の形式を示す図であり、取得用コミュニティ名４００、設定用コミュニティ名４１０、トラップ宛先４２０、管理範囲数４３０、管理アドレス範囲４４０、トラップ中継間隔４５０をそれぞれ格納する領域から成っている。

このうち、取得用コミュニティ名４００は、ＳＮＭＰの取得要求を受信したときに認証を行うための名称であり、サブマネージャ１０がサブマネージャ拡張トラップを発行するときにも使用する。

設定用コミュニティ名４１０は、ＳＮＭＰの設定要求を受信したときに認証を行うための名称である。

トラップ宛先４２０は、サブマネージャ１０がサブマネージャ拡張トラップを発行する相手のＩＰアドレスであり、トラップ宛先４２０ａ，４２０ｂというように複数指定できる。

管理範囲数４３０は、サブマネージャ１０の管理範囲に含める最大のＩＰノード数を指定する情報である。

管理アドレス範囲４４０は、管理範囲の対象となるＩＰノードのＩＰアドレス、コミュニティ名、ポーリング間隔、タイムアウト時間を指定する情報であり、図示の４４０ａ，４４０ｂように複数組指定可能になっている。そして、各組においてＩＰアドレスを範囲指定できる。例えば、管理アドレス範囲４４０ａでは ２００.１０.２０.１ から ２００.１０.２０.７０ までのＩＰアドレスを指定していることを示している。

この管理アドレス範囲４４０のコミュニティ名は、サブマネージャ１０が管理範囲のエージェントに対して、ＳＮＭＰ要求を発行するときに使用する。

また、エージェントの管理オブジェクトを定期収集する時のポーリング間隔の初期値（デフォルト値）は例えば５分に設定されている。また、タイムアウト時間の初期値は、例えば１秒に設定されている。さらにトラップ中継間隔４５０の初期値は例えば１０分に設定されている。

図１６は、管理範囲監視機能１１０の内部に設けられる管理範囲テーブル５００の形式を示す図であり、制御部と複数のエントリとから構成され、エントリ数の最大は図１５の管理範囲数４３０で指定した値と同数である。

制御部は取得用コミュニティ名５１０a等を格納する領域で構成される。この制御部に環境設定ファイル１８０から取り込む内容について説明すると、次の通りである。

取得用コミュニティ名５１０aには取得用コミュニティ名４００を、設定用コミュニティ名５１０bには設定用コミュニティ名４１０を、管理範囲数５１０cには管理範囲数４３０を、トラップ宛先数５１０dとトラップ宛先テーブルアドレス５１０eにはトラップ宛先４２０で指定した宛先数および宛先のＩＰアドレスをそれぞれ設定する。その他の内容については、図１７から図２４で説明する。

図１７は、管理範囲監視機能１１０のメイン処理の概要を示したものである。まず、管理範囲の初期設定を行い（ステップ６００）、終了要求を受信するまでループする（ステップ６１０）。この間、管理範囲の監視（ステップ６２０）、集計処理（ステップ６３０）、および管理範囲の更新（ステップ６４０）を順番に行う。

図１８は、管理範囲の初期設定（ステップ６００）の概要を示したものである。前記した環境設定ファイル１８０の参照と管理範囲テーブル５００の設定（ステップ６５０，６５１）を行う。

管理範囲テーブル５００のエントリのＩＰアドレス５２０bには、管理アドレス範囲４４０に指定されたＩＰアドレスのうち、存在するＩＰアドレスだけを設定するため、以下の処理を行う。まず、サブマネージャ１０が認識しているＩＰアドレスを取得するために、自エージェント機能１３０からＭＩＢ−IIのアドレス変換グループである atNetAddress を取得（ステップ６５２）する（ステップ６５２）。

取得した atNetAddress の値は、ＩＰアドレスと物理アドレスの対応関係を示している。管理範囲テーブル５００に空のエントリ５２０が存在し、かつ atNetAddress のＩＰアドレスが存在する間ループする（ステップ６５３）。

atNetAddress のＩＰアドレスが図１５の管理アドレス範囲４４０に含まれるか判定し（ステップ６５４）、含まれるＩＰアドレスについてのみｐｉｎｇを発行する（ステップ６５５）。

そして、ｐｉｎｇの応答の有無を判定し（ステップ６５６）、応答があるＩＰアドレスを管理範囲テーブル５００の空のエントリ５２０のＩＰアドレス５２０bに設定する。また、統合マネージャ５０へ管理範囲にＩＰノードを追加したことを通知するサブマネージャ拡張トラップを発行する（ステップ６５８）。

次に、環境設定ファイル１８０の管理アドレス範囲４４０から当該ＩＰアドレスに関するコミュニティ名、ポーリング間隔およびタイムイアウト時間をそれぞれ取得し、コミュニティ名５２０c、ポーリング間隔５２０d、およびタイムイアウト時間５２０eをそれぞれ設定する（ステップ６５９）。

次に/etc/hosts ファイル（図６のＩＰノード毎の情報に含まれる）を参照して、当該ＩＰアドレス５２０bのホスト名５２０fを設定する（ステップ６６０）。その後、ステータス５２０gに″Normal″を設定する（ステップ６６１）。

図１９は、管理範囲の監視（ステップ６２０）の概要を示したものである。

前記した管理範囲テーブル５００を参照し（ステップ６７０）、ＩＰアドレス５２０bが設定されているエントリ５２０数だけループする。

この間にｐｉｎｇ処理を行う（ステップ６７２）。当該エントリ５２０にＩＰアドレス５２０bが設定されており、かつステータス５２０gが″Critical″以外であるか判定し（ステップ６７３）、条件を満たすＩＰノードに対してＭＩＢ−II（sysObjectID、ifNumber、ifType、ifOperStatus、ipForwarding）の値（図１１参照）を取得するためＳＮＭＰ要求を発行する（ステップ６７４）。

次に、ＳＮＭＰ要求の応答の有無を判定する（ステップ６７５）。応答があった場合は、当該エントリ５２０のＳＮＭＰサポート情報５２０jに″snmp″を設定し（ステップ６７６）、ルータ判定を行う（ステップ６７７）。

応答がなかった場合は、当該エントリ５２０のＳＮＭＰサポート情報５２０jに″nonsnmp″を設定し（ステップ６７８）、ルータサポート情報５２０kに″host″を設定する（ステップ６７９）。

図２０は、ルータ判定（ステップ６７７）の概要を示したものである。初期設定としてルータサポート情報５２０kに″host″を設定する（ステップ６９０）。ＭＩＢ−IIの ipForwarding の値（図１１参照）を判定し（ステップ６９１）、″１″(gateway)であればステップ６９２へ、″１″以外(host)であればステップ６９８へ進む。

インタフェース数を示したＭＩＢ−IIの ifNumber の値を判定し（ステップ６９２）、″２″以上のときはステップ６９３に進み、″１″のときはステータス５２０gに″Normal″を設定する（ステップ６９７）。

インタフェースタイプを示したＭＩＢ−IIの ifType の値が″２４″(softwareLoopback)以外のインタフェースが複数存在し、かつそのステータスを示したＭＩＢ−IIの ifOperStatus の値が全て″１″(up)であるか判定する（ステップ６９３）。条件を満たす場合は、ルータサポート情報５２０kに″router″を設定し（ステップ６９４）、ステータス５２０gに″Normal″を設定する（ステップ６９５）。

条件を満たさない場合は、ステータス５２０gに″Marginal″を設定する（ステップ６９６）。

ＭＩＢ−IIの ipForwarding の値が″１″以外(host)であれば（ステップ６９１）、インタフェース数を示したＭＩＢ−IIの ifNumber の値を判定し（ステップ６９８）、″２″以上のときはステップ６９９に進み、″１″のときはステータス５２０gに″Normal″を設定する（ステップ７０２）。

ステップ６９９ではステップ６９３と同じ判定を行い、条件を満たす場合はステータス５２０gに″Normal″を設定し（ステップ７００）、条件を満たさない場合はステータス５２０gに″Marginal″を設定する（ステップ７０１）。

図２１は、ｐｉｎｇ処理（ステップ６７２）の概要を示したものである。

まず、当該エントリ５２０のｐｉｎｇの応答時間５２０hをクリアし（ステップ７１０）、指定されたＩＰアドレスへｐｉｎｇを発行し（ステップ７１１）、その応答の有無を確認する（ステップ７１２）。ｐｉｎｇの応答があった場合（ステップ７１２）、当該エントリ５２０のｐｉｎｇの応答時間５２０hの設定（ステップ７１３）、ｐｉｎｇの応答がなくなった最古の時間５２０iのクリア（ステップ７１４）、ＳＮＭＰサポート情報５２０jの判定（ステップ７１５）を行う。

ＳＮＭＰサポート情報５２０jが、″nonsnmp″のときはステータス５２０gに″Normal″を設定し（ステップ７１６）、″snmp″のときはステータス５２０gに″Marginal″を設定する（ステップ７１７）。

ｐｉｎｇの応答がなかった場合（ステップ７１２）、当該エントリ５２０のステータス５２０gに″Critical″を設定し（ステップ７１８）、ｐｉｎｇの応答がなくなった最古の時間５２０iを確認する（ステップ７１９）。

最古の時間５２０iが存在し（ステップ７１９）、一定時間（例えば１週間）を経過しているときは（ステップ７２０）、当該エントリ５２０から内容５２０a〜５２０kを削除（ステップ７２１）し、統合マネージャ５０に対し管理範囲からＩＰノードを削除したことを通知するサブマネージャ拡張トラップを発行する（ステップ７２２）。

最古の時間５２０iが存在しないときは（ステップ７１９）、現在時間を設定（ステップ７２３）する。

図２２は、集計処理（ステップ６３０）の概要を示したものである。

まず、管理範囲テーブル５００の制御部のうちＩＰアドレス数をカウントする部分５１０f〜５１０kをクリアし、エントリ５２０の数だけループする（ステップ７３２）。そして、当該エントリ５２０にＩＰアドレスが設定されている場合だけ、以下の条件でカウントアップ（＋１）する。

すなわち、smgTotalManagedNodeNumber は無条件に（ステップ７３４）、smgTotalCriticalNodeNumber はステータス５２０gが″Critical″のとき（ステップ７３６）だけ、smgTotalMarginalNodeNumber はステータス５２０gが″Marginal″のとき（ステップ７３７）だけ、smgTotalNormalNodeNumberはステータス５２０gが″Normal″のとき（ステップ７３８）だけ、smgTotalRouterNodeNumber はルータサポート情報５２０kが″router″のとき（ステップ７４０）だけ、 smgTotalSnmpSupportNodeNumber はＳＮＭＰサポート情報５２０jが″snmp″のとき（ステップ７４２）だけ、それぞれカウントアップする。

集計前と集計後の結果に差が発生したときは（ステップ７４３）、収集データベース管理機能１２０に差分情報を格納する（ステップ７４４）。

図２３は、管理範囲の更新（ステップ６４０）の概要を示したものである。

まず、前回の更新時間から一定時間、例えば３時間経過したことを確認して動作する（ステップ７５０）。

管理範囲テーブル５００に空のエントリ５２０が存在し、ステータス５２０gが″Critical″以外で、かつＳＮＭＰサポート情報５２０jが″snmp″であるＩＰアドレスについてのみループする（ステップ７５１）。

次に、当該エントリのＩＰアドレス５２０bに対して前記ＭＩＢ−IIの atNetAddress を取得するためにＳＮＭＰ要求を発行する（ステップ７５２）。

ＳＮＭＰ要求の応答があった場合は（ステップ７５２）、空のエントリ５２０が存在する間、かつ取得したＩＰアドレスの数だけループし（ステップ７５４）、更新処理を行う（ステップ７５５）。

ＳＮＭＰ要求の応答がなかった場合は（ステップ７５２）、ステータス５２０gを更新するため″Critical″を設定する（ステップ７５６）。

図２４は、更新処理（ステップ７５５）の概要を示したものである。

まず、管理範囲テーブル５００のＩＰアドレス５２０bに存在しないＩＰアドレスであり、かつ環境設定ファイル１８０の管理アドレス範囲４４０に含まれるかどうか判定し（ステップ７６０）、条件を満たすときだけ次の処理を行う。

すなわち、空のエントリ５２０に当該ＩＰアドレスを設定し（ステップ７６１）、統合マネージャ５０に対し管理範囲にＩＰノードを追加したことを通知するサブマネージャ拡張トラップを発行する（ステップ７６２）。

以上のような処理を行うことによって、サブマネージャ１０は管理範囲に含めるＩＰノード数を制限できるばかりでなく、存在するＩＰノードだけを監視することができる。

（３）サブマネージャが受信したＳＮＭＰ要求振り分け方法
通信制御機能１００は、統合マネージャ５０およびサブマネージャ１０の集約化機能１５０からＳＮＭＰ要求を、またエージェント２０からＳＮＭＰトラップを受信する。

サブマネージャエージェント機能１４０は、通信制御機能１００から入力されたＳＮＭＰ要求を管理オブジェクト識別子により振り分け、収集ＭＩＢデータベース管理機能１２０又は集約化機能１５０に中継する。

自エージェント機能１３０とサブマネージャエージェント機能１４０の２つのエージェント機能を設ける主な理由としては、統合マネージャ５０からのＳＮＭＰ要求と集約化機能１５０からのＳＮＭＰ要求を並列に処理する必要があるためである。すなわち、ＳＮＭＰ要求を並列に処理することにより、統合マネージャ５０からサブマネージャ１０のリアルタイム収集ＭＩＢに対してＳＮＭＰ要求を受信した場合、その延長で集約化機能１５０が通信制御機能１００を経由して自エージェント機能１３０にＳＮＭＰ要求を発行し、また、その結果を元にリアルタイム収集ＭＩＢ値を作成して統合マネージャ５０にＳＮＭＰ応答を返すことを可能にする。

図２５は、通信制御機能１００の管理オブジェクトによる振り分け方法の概略を示したものである。通信制御機能１００は、終了要求を受信するまでループする（ステップ７７０）。受信するデータには、統合マネージャ５０およびサブマネージャ１０の集約化機能１５０からのＳＮＭＰ要求、自エージェント１３０およびサブマネージャエージェント機能１４０からのＳＮＭＰ応答、エージェントからのＳＮＭＰトラップがあるので、このうちいずれであるかを判断する（ステップ７７１）。

まず、ＳＮＭＰ要求を受信した場合は、ＳＮＭＰ要求のプロトコル内の管理オブジェクト識別子により振り分けを行うためにサブマネージャ拡張ＭＩＢかどうかを判定する（ステップ７７２）。サブマネージャ拡張ＭＩＢのときはサブマネージャエージェント機能１４０に通知する（ステップ７７３）。しかし、サブマネージャ拡張ＭＩＢでないときは自エージェント機能１３０に通知する（ステップ７７４）。

一方、ＳＮＭＰ応答を受信した場合は、統合マネージャ５０に応答を返す（ステップ７７５）。

また、ＳＮＭＰトラップを受信した場合は、トラップ管理機能１６０に通知する（ステップ７７６）。

図２６は、サブマネージャエージェント機能１４０の管理オブジェクトによる振り分け方法の概略を示したものである。

まず、サブマネージャエージェント機能１４０は、終了要求を受信するまでループする（ステップ７８０）。

受信するデータには、通信制御機能１００からのＳＮＭＰ要求、収集データベース管理機能１２０および集約化機能１５０からのＭＩＢ値の結果応答があるので、このうちいずれであるかを判断する（ステップ７８１）。

ＳＮＭＰ要求を受信した場合は、ＭＩＢ取得要求であり、かつコミュニティ名が一致しているかどうかを判定する（ステップ７８２）。コミュニティ名の確認は、ＳＮＭＰ要求のプロトコル内にあるコミュニティ名と図１５に示した取得用のコミュニティ名４００とを比較することによって行う。

前記ステップ７８２の判定条件を満たすときは、オペレーションの判定を行う（ステップ７８３）。

オペレーションがｇｅｔ−ｎｅｘｔのときは、指定された次の管理オブジェクト識別子を求め、要求された管理オブジェクト識別子とする（ステップ７８４）。次に、定期収集ＭＩＢかリアルタイム収集ＭＩＢかの判定を行い（ステップ７８５）、定期収集ＭＩＢのときは収集データベース管理機能１２０に通知し（ステップ７８６）、リアルタイム収集ＭＩＢのときは集約化機能に通知する（ステップ７８７）。

前記ステップ７８２の判定条件を満たさないときは、通信制御機能１００にエラー応答を返す（ステップ７８８）。

一方、結果応答を受信した場合は、ＳＮＭＰ応答を組立て（ステップ７８９）、通信制御機能１００に応答する（ステップ７９０）。

（４）収集データベース管理機能１２０における収集ＭＩＢの管理方法
ここでは、特に、管理オブジェクトを分割管理し、ＭＩＢ値の応答時に管理オブジェクトを組立てる方法について説明する。

収集データベース管理機能１２０は、管理範囲監視機能１１０から定期収集ＭＩＢを構成する個々の情報を入力し、メモリに保持するとともに収集ＭＩＢデータベース１７０に格納する。

この個々の情報には、図２７に示すように、smgIpNodeIndex ８１０と、smgIpNodeContextの内容２００であるＩＰアドレス２１０、ホスト名２２０、ステータス２３０、ｐｉｎｇの応答時間２４０、ＳＮＭＰサポート情報２５０、ルータ情報２6０がある。

すなわち、収集データベース管理機能１２０は、定期収集ＭＩＢである管理オブジェクト単位ではなく、管理オブジェクトを構成する個々の情報単位に個別管理を行う。収集データベース管理機能１２０は、管理範囲監視機能１１０からＩＰノードを特定するキー情報であるsmgIpNodeIndex ８１０と、変更の発生した例えばステータス２３０だけを入力することにより、収集データベース管理機能１２０と管理範囲監視機能１１０間で交換するデータ量を削減するように構成されている。

サブマネージャ１０の管理範囲から任意のＩＰノードが削除された場合は、管理範囲監視機能１１０からsmgIpNodeIndex ８１０の削除要求を入力し、収集データベース管理機能１２０はフラグ８００を”あり”から”なし”に変更することにより管理範囲のＩＰノードの管理を行う。

また、管理範囲監視機能１１０から定期収集ＭＩＢを構成する個々の情報の参照要求を受信した場合は、前記キー情報であるsmgIpNodeIndex ８１０と要求された個々の情報を提供する。これは、主にサブマネージャ１０が再起動した場合にも、図２７に示すsmgIpNodeIndex ８１０とＩＰアドレス２１０の対応関係を、再起動前の対応関係と同じにするために行う。

収集データベース管理機能１２０は、前記対応関係を維持するために、定期収集ＭＩＢを構成する個々の情報を収集ＭＩＢデータベース１７０に格納する。

収集データベース管理機能１２０は、サブマネージャ１０が統合マネージャ５０から定期収集ＭＩＢの取得要求を受信したときは、通信制御機能１００、サブマネージャエージェント機能１４０を経由して、定期収集ＭＩＢ値の取得要求を受信する。

収集データベース管理機能１２０は、定期収集ＭＩＢを構成する個々の情報から定期収集ＭＩＢ値を組立て、その結果をサブマネージャエージェント機能１４０、通信制御機能１００を経由して統合マネージャ５０に返信する。

ここで、定期収集ＭＩＢ値の組立てとは、図２７に示すように、１つのエージェントまたＩＰノード特性およびＩＰ状態を示したＩＰアドレス２１０、ホスト名２２０、ステータス２３０、ｐｉｎｇの応答時間２４０、ＳＮＭＰサポート情報２５０、ルータ情報２6０の各情報を、１つの管理オブジェクトであるsmgIpNodeContext ２００にまとめることである。

図２８は、収集データベース管理機能１２０の動作の概略を示したものである。

収集データベース管理機能１２０は、終了要求を受信するまでループする（ステップ８２０）。

受信するデータ（ステップ８２１）には、サブマネージャエージェント機能１４０からの定期収集ＭＩＢの取得要求、管理範囲監視機能１１０からの格納要求および参照要求があるので、いずれであるかを判定する（ステップ８２１）。

取得要求を受信した場合、ｇｅｔ−ｎｅｘｔオペレーションの判定を行い（ステップ８２２）、ｇｅｔ−ｎｅｘｔオペレーションである場合は指定された次のインデックス（smgIpNodeIndex ８１０）を求める（ステップ８２３）。

次のステップ８２４では、インデックスの有無を図２７のフラグ８００を使用して判定する。これは、主にｇｅｔオペレーションで指定されたインデックスを確認するためである。

インデックスが存在する場合、ステップ８２５では、応答する定期収集ＭＩＢ値を作成する。すなわち、smgIpNodeContext ２００を要求されたときは組立てを行い、図１４に示した定期収集ＭＩＢである集計結果を表現した管理オブジェクトを要求されたときは組立ての対象から除く。

その後、サブマネージャエージェント機能１４０にＭＩＢ値を応答する（ステップ８２６）。インデックスが存在しない場合、サブマネージャエージェント機能１４０にエラー応答を返す（ステップ８２７）。

格納要求を受信した場合、管理範囲監視機能１１０から定期収集ＭＩＢを構成する前記キー情報であるsmgIpNodeIndex ８１０と更新するsmgIpNodeContextの内容２００とを入力し、前記キー情報により該当するＩＰノードを検索した後、メモリに保持しているsmgIpNodeContextの内容２００を更新する（ステップ８２８）。

サブマネージャ１０の管理範囲から任意のＩＰノードの追加又は削除を行う場合は、図２７のフラグ８００をそれぞれ”あり”又は”なし”に更新（変更）する。

その後、収集ＭＩＢデータベース１７０を更新する（ステップ８２９）。

図１４に示した、収集ＭＩＢである集計結果を表現した管理オブジェクトに対しては、分割管理を行えないため、単純にＭＩＢ値を更新する。

参照要求を受信した場合、管理範囲監視機能１１０に対して、定期収集ＭＩＢを構成する前記キー情報であるsmgIpNodeIndex ８１０とsmgIpNodeContextの内容２００のうち要求された個々の情報を提供する（ステップ８３０）。図１４に示した定期収集ＭＩＢである集計結果を表現した管理オブジェクトに対しては、分割管理を行わないため、単純にＭＩＢ値を提供する。

（５）集約化機能１５０における収集・集約方法
集約化機能１５０は、例えば図３０に示すようなＴＣＰコネクションがあったとすると、管理範囲のＩＰノード間のＴＣＰコネクション１０００および管理範囲のＩＰノードと管理範囲外のＩＰノード間のＴＣＰコネクション１０１０を集約の対象とする。管理範囲外のＩＰノード間のＴＣＰコネクション１０２０は対象としない。つまり、少なくともＴＣＰコネクションの一端が管理範囲のＩＰノードであり、かつそのＩＰノードがエージェント２０を実装しているＴＣＰコネクションについて集約の対象とする。

図３１は、集約化機能１５０が管理範囲のエージェントから収集するＭＩＢ−IIの tcpConnState のインデックスとＭＩＢ値の形式を示したものである。

図３２は、サブマネージャ１０のリアルタイム収集ＭＩＢであり、統合マネージャ５０からＭＩＢ値を要求される smgSumTcpContext のインデックスとＭＩＢ値の形式を示したものである。

図３３は、図３１と図３２の間の変換について示している。統合マネージャ５０から要求された smgSumTcpContext のインデックスのＩＰアドレス（その１）３１０、ポート番号（その１）３２０、ＩＰアドレス（その２）３３０、ポート番号（その２）３４０を、それぞれＩＰアドレス（その１）３１０から取得し、 tcpConnState １１００のインデックスのローカルのＩＰアドレス１１２０、ローカルのＴＣＰポート１１３０、リモートのＩＰアドレス１１４０、リモートのＴＣＰポート１１５０として使用する。

また、tcpConnState の値１１６０は、smgSumTcpContext のステータス（その１）３３０に設定する。

同様にして、tcpConnState １１１０のインデックスのリモートのＩＰアドレス１１２０、リモートのＴＣＰポート１１３０、ローカルのＩＰアドレス１１４０、ローカルのＴＣＰポート１１５０として使用する。また、tcpConnState の値１１７０は、smgSumTcpContext のステータス（その２）３６０に設定する。

smgSumTcpContextのサービス名３７０は、/etc/services ファイルを参照し、ポート番号（その１）３２０、又はポート番号（その２）３５０に対応したサービス名を取得して設定する。

図３４は、図３２に示したインデックスの順序性について説明したものであり、管理範囲テーブル５００のエントリ５２０の順番と関係を持つ。

ＩＰアドレス（その１）３１０には、エントリの先頭から順番にＩＰアドレス５２０bが並ぶ。また、ポート番号（その１）３２０およびポート番号（その２）３５０には、ポート番号の小さい値から順番に並ぶ。さらに、ＩＰアドレス（その２）３４０には、ＩＰアドレス（その１）３１０の次のエントリのＩＰアドレス５２０bから順番に並び、最後は管理範囲外のＩＰアドレスになる。

図３５は、集約化機能１５０のメイン処理の概要を示したものであり、終了要求を受信するまでループする（ステップ１２００）。

サブマネージャエージェント機能１４０から集約ＭＩＢの取得要求を受信したときに動作を開始し（ステップ１２０１）、まず、オペレーションを判定し（ステップ１２０２）、ｇｅｔオペレーションのときはｇｅｔ処理（ステップ１２０３）を、その他の場合はｇｅｔ−ｎｅｘｔ処理を行う（ステップ１２０４）。

次にエラー判定を行い（ステップ１２０５）、エラーなしのときは前記したサービス名の取得（ステップ１２０６）および応答する smgSumTcpContext の内容を組立てる（ステップ１２０７）。また、サブマネージャエージェント機能１４０に結果応答を返す（ステップ１２０８）。

エラーありのときは、サブマネージャエージェント機能１４０にエラー応答を返す（ステップ１２０９）。

図３６は、ｇｅｔ処理（ステップ１２０３）の概要を示したものであり、まず図３３に示したインデックスの分解を行い（ステップ１２５０）、管理範囲に含まれるＩＰアドレスかどうかを判定（ステップ１２５２）するために管理範囲テーブル５００を参照する（ステップ１２５１）。

ＩＰアドレス（その１）だけ管理範囲に含まれるときは、ＩＰアドレス（その１）に対してのみｇｅｔ発行を実行する（ステップ１２５３，１２５４）。

同様に、ＩＰアドレス（その２）だけ管理範囲に含まれるときは、ＩＰアドレス（その２）に対してのみｇｅｔ発行を実行する（ステップ１２５５，１２５６）。

しかし、両方のＩＰアドレスが管理範囲に含まれるときは、まずＩＰアドレス（その１）に対してｇｅｔ発行を実行し（ステップ１２５７，１２５８）、エラーのないときだけＩＰアドレス（その２）に対してｇｅｔ発行を実行する（ステップ１２５９，１２６０，１２６１）。

両方のＩＰアドレスが管理範囲に含まれないときは、エラーを返す（ステップ１２６２）。

図３７は、図３６で実行するｇｅｔ発行の概要を示したものである。

効率良くＭＩＢ−IIの値を取得するために、管理範囲テーブル５００を参照し、当該ＩＰアドレスのステータス５２０gが″Marginal″又は″Normal″であり、かつＳＮＭＰサポート情報５２０jが″snmp″であるか判定する（ステップ１２７０）。

条件を満たすときは、図３３に示した管理オブジェクト識別子の変換を行い（ステップ１２７１）、ｇｅｔ要求を発行する（ステップ１２７２）。

次に、ｇｅｔ要求の応答の有無の判定およびエラーの判定（ステップ１２７３，１２７４）を行い、条件を満たすときは取得結果を返す（ステップ１２７５）。

ステップ１２７０、ステップ１２７３およびステップ１２７４の条件を満たさないときは、エラーを返す（ステップ１２７８，１２７７，１２７６）。

図３８は、ｇｅｔ−ｎｅｘｔ処理（ステップ１２０４）の概要を示したものである。

まず、インデックス指定の有無を判定し（ステップ１２８０）、存在するときはステップ１２５０と同様にインデックスを分解する（ステップ１２８１）。

インデックスが指定されていないときは、先頭のインデックスを求めるために、次インデックス算出を実行する（ステップ１２８２）。

次に、管理範囲に存在するＩＰアドレスか判定するために、図３６のステップ１２５２と同様の判定を行う（ステップ１２８４）。

この判定において、ＩＰアドレス（その１）だけ管理範囲に含まれるときは、ＩＰアドレス（その１）に対してのみｇｅｔ−ｎｅｘｔ発行（ステップ１２８５，１２８６）を実行する。

同様に、ＩＰアドレス（その２）だけ管理範囲に含まれるときは、ＩＰアドレス（その２）に対してのみｇｅｔ−ｎｅｘｔ発行を実行する（ステップ１２８７，１２８８）。

両方のＩＰアドレスが管理範囲に含まれるときは、まずＩＰアドレス（その１）に対してｇｅｔ−ｎｅｘｔ発行を実行し（ステップ１２８９，１２９０）、エラーのないときだけコネクションの相手アドレスに対してｇｅｔ−ｎｅｘｔ発行を実行する（ステップ１２９１，１２９２，１２９３）。

両方のＩＰアドレスが管理範囲に含まれないときは、エラーを返す（ステップ１２９４）。

図３９は、次インデックス算出の概要を示したものである。

まず、指定されたインデックスの有無の判定を行い（ステップ１３００）、存在しないときは先頭のインデックスを求めるために管理範囲テーブル５００の先頭エントリから順番に検索し、ステータス５２０gが″Marginal″又は″Normal″であり、かつＳＮＭＰサポート情報が″snmp″であるＩＰアドレス５２０bを、新しいＩＰアドレス（その１）３１０とする（ステップ１３０１）。

また、ポート番号（その１）３３０には″０″を、ＩＰアドレス（その２）３４０には″０.０.０.０″を、ポート番号（その２）３５０には″０″を、それぞれ設定する。

しかし、ステップ１３００においてインデックスが存在するときは、効率良く次のインデックスを求めるために管理範囲テーブル５００を順番に検索し、図３４に示したインデックスの順番に従い、ＩＰアドレス（その１）３１０以降のＩＰアドレス５２０bであり、かつステータス５２０gが″Marginal″又は″Normal″であり、かつＳＮＭＰサポート情報が″snmp″であるＩＰアドレス５２０bを、新しいＩＰアドレス（その１）３１０とする（ステップ１３０５）。

図４０は、図３８で実行するｇｅｔ−ｎｅｘｔ発行の概要を示したものである。

まず、効率良くＭＩＢ−IIの値を取得するために、管理範囲テーブル５００を参照し、当該ＩＰアドレスのステータス５２０gが″Marginal″又は″Normal″であり、かつＳＮＭＰサポート情報５２０jが″snmp″であるかを判定する（ステップ１３１０）。

条件を満たすときは、図３３に示した管理オブジェクト識別子の変換を行い（ステップ１３１１）、ｇｅｔ−ｎｅｘｔ要求を発行する（ステップ１３１２）。

次に、取得結果の管理オブジェクト識別子を判定し（ステップ１３１３）、 tcpConnState であるときはＩＰノード間のＴＣＰコネクションであるか判定する（ステップ１３１４）。

ＩＰノード間のＴＣＰコネクションであるときは取得結果を返し（ステップ１３１５）、ＩＰノード間のＴＣＰコネクションでないときはｇｅｔ−ｎｅｘｔ発行を再度実行する（ステップ１３１６）。

ステップ１３１３において tcpConnState でないときは、次インデックス算出の実行および次インデックスの有無の判定を行い（ステップ１３１７，１３１８）、存在するときはｇｅｔ−ｎｅｘｔ発行を実行し（ステップ１３１９）、存在しないときはエラーを返す（ステップ１３２０）。

ステップ１３１０の条件を満たさないときは、ステップ１３１７からステップ１３２０と同様の処理を行う。

（６）トラップ管理機能１６０におけるＳＮＭＰトラップの削減方法
図１０のsmgIntermediaryTrapは、ＳＮＭＰトラップが使用する管理パケット数を削減するために、サブマネージャ１０が中継するサブマネージャ拡張トラップを定義したものであり、拡張トラップ番号は「３」である。

また、図１５で説明した環境設定ファイル１８０の取得用コミュニティ名４００は、サブマネージャ１０がサブマネージャ拡張トラップを発行するときにも使用する。トラップ宛先４２０は、サブマネージャ１０がサブマネージャ拡張トラップを発行する相手のＩＰアドレスであり、複数指定できる。トラップ中継間隔４５０は、サブマネージャの管理範囲であるエージェント２０から受信したＳＮＭＰトラップを蓄える時間であり、この間にＳＮＭＰトラップを受信した場合は、１つのサブマネージャ拡張トラップにまとめ、統合マネージャ５０に中継する。

図４１は、サブマネージャ１０が管理範囲のエージェント２０から受信したＳＮＭＰトラップからサブマネージャ拡張トラップへの変換の概要を示したものである。

サブマネージャ拡張トラップであるsmgIntermediaryTrapの形式１４００は、トラップヘッダ１４１０とVariable-bindings １４２０とにより構成する。

トラップヘッダ１４１０はenterprise １４１１、agent-addr １４１２、generic-trap １４１３、specific-trap １４１４、time-stamp １４１５から構成し、それぞれ、サブマネージャ１０のsysObjectID、サブマネージャ１０のＩＰアドレス「６」、「３」、サブマネージャ １０のsysUpTimeを記述する。

Variable-bindings １４２０には、受信したＳＮＭＰトラップの内容を順番に記述する。

図４２は、ＳＮＭＰトラップからサブマネージャ拡張トラップへの変換の詳細を示したものである。

smgIntermediaryTrapの形式１４００のVariable-bindings １４２０は、主に、smgIpNodeIndex １４３０、smgEnterprise １４３１、smgAgentAddr １４３２、 smgGenericTrap １４３３、smgSpecificTrap １４３４、VarBindList １４３５から構成する。

smgIpNodeIndex １４３０には、ＳＮＭＰトラップを発行したＩＰアドレスであるagent-addr １４６２に該当する管理範囲テーブル５００のインデックス番号５２０aを記述する。

smgEnterprise １４３１、smgAgentAddr １４３２、smgGenericTrap １４３３、smgSpecificTrap １４３４には、それぞれ、管理範囲のエージェント２０から受信したＳＮＭＰトラップのenterprise １４６１、agent-addr １４６２、generic-trap １４６３、specific-trap １４６４を記述する。

VarBindList １４３５には、受信したＳＮＭＰトラップのVariable-bindings １４７０を記述する。

図４３は、ＳＮＭＰトラップの削減方法の概要を示したものである。

まず、環境設定ファイル１８０を参照し（ステップ１５００）、終了要求を受信するまでループ（ステップ１５０１）する。

次に、バッファの確保を行い（ステップ１５０２）、トラップ中継間隔４５０（図１５参照）の間だけループし（ステップ１５０３）、ＳＮＭＰトラップを受信する（ステップ１５０４）。

受信したＳＮＭＰトラップが、サブマネージャ管理範囲のエージェント２０からのものか確認するために、管理範囲テーブル５００からＩＰアドレス５２０bとインデックス５２０aを参照する（ステップ１５０５）。

受信したＳＮＭＰトラップがサブマネージャ管理範囲のエージェント２０が発行したものである場合、バッファにインデックス５２０aと受信したＳＮＭＰトラップを格納する（ステップ１５０６，１５０７）。

このバッファの内容からサブマネージャ拡張トラップを組立て（ステップ１５０８）、統合マネージャ５０にサブマネージャ拡張トラップを発行する（ステップ１５０９）。その後、バッファを解放する（ステップ１５１０）。

以上、本発明の要部であるサブマネージャ１０の詳細について説明したが、本実施例によれば、統合マネージャ５０からサブマネージャ１０の拡張ＭＩＢである定期収集ＭＩＢおよびリアルタイム収集ＭＩＢを参照することにより、以下の効果がある。

（１）定期収集ＭＩＢを参照する場合
サブマネージャ１０がサブマネージャ管理範囲のＩＰノードに対して定期的にｐｉｎｇ（ＩＣＭＰエコー要求パケット）およびＳＮＭＰ要求パケットを発行し、その応答結果をサブマネージャ拡張ＭＩＢの一つである定期収集ＭＩＢとして保持することにより、統合マネージャ５０からのＳＮＭＰ取得要求に即座に応答することができる。

定期収集ＭＩＢは、サブマネージャ管理範囲のＩＰノードの特性（インデックス、ＩＰアドレス、ホスト名、ＩＰ状態、ｐｉｎｇの応答時間、ＳＮＭＰ実装フラグ、ＩＰルータ実装フラグ）を１〔管理オブジェクト識別子／ＩＰノード〕で表現した管理オブジェクト識別子とその個々の特性をＩＰノード数で集計した管理オブジェクト識別子から成っているので、統合マネージャ５０側のネットワーク管理者は、用途に合わせ、サブマネージャ１０の定期収集ＭＩＢを参照することにより、サブマネージャ管理範囲の構成情報や状態情報を確認できる。

さらに、統合マネージャ５０とサブマネージャ１０間の管理パケット数を、定期収集ＭＩＢの集約数分だけ減少させることができる。

（２）リアルタイム収集ＭＩＢを参照する場合
統合マネージャ５０からのサブマネージャ１０へのリアルタイム収集ＭＩＢへの参照要求に従い、リアルタイムに各エージェントの管理オブジェクトを収集・集約して統合マネージャ５０に返信するため、少ない資源（ＣＰＵパワー、メモリ容量）および少ない管理パケット数でサブマネージャ管理範囲の最新状態を把握することができる。また、エージェント間の時間誤差を低減できる。

また、サブマネージャ管理範囲のＴＣＰコネクション情報をリアルタイム収集ＭＩＢとして管理することにより、統合マネージャ５０での少ない操作で、サブマネージャ１０の管理範囲のトラフィックの高いＩＰノードおよびサービスを特定できる。さらに、統合マネージャ５０とサブマネージャ１０間の管理パケット数を、サブマネージャ１０が存在しない場合に比べて減少させることができる。

さらに、サブマネージャ拡張トラップを発行することにより、サブマネージャ管理範囲の変化およびエージェントから受信したＳＮＭＰトラップを、効率良く統合マネージャ５０に伝えることができる。

なお、図２の論理関係図においては、エージェントから統合マネージャまでの階層は３層になっているが、本発明はこれに限定されるものではない。

以上説明したように、本発明の実施例においては、エージェントとサブマネージャ間、およびサブマネージャと統合マネージャ間の通信プロトコルとしてＳＮＭＰを使用し、かつサブマネージャ内に、自己の管理範囲に属するエージェントを介して同管理範囲の管理オブジェクトを定期的に収集し、その収集情報を統合マネージャからの参照要求に応じて、ＭＩＢ形式で統合マネージャに通知するようにしたので、簡単な構成のサブマネージャで、かつＩＡＢ管理標準のＳＮＭＰに基づいて大規模な通信ネットワークを階層管理することができる。

また、統合マネージャから参照要求に対し、複数の識別子で管理している各エージェントからの複数の情報を集約して統合マネージャに通知するようにしたので、少量の管理パケットで統合マネージャとサブマネージャ間の管理情報を伝達することができ、大規模な通信ネットワークを低トラフィックおよび低コストで管理することができる。さらに、統合マネージャの負荷を軽減することができる。

また、統合マネージャ側のネットワーク管理者は、用途に合わせ、サブマネージャの定期収集ＭＩＢを参照することにより、サブマネージャ管理範囲の構成情報や状態情報を確認できる。

さらに、リアルタイムに管理オブジェクトを収集し、統合マネージャへ通知するようにした場合、少ない資源（ＣＰＵパワー、メモリ容量）および少ない管理パケット数でサブマネージャ管理範囲の最新状態を把握することができる。

また、サブマネージャ管理範囲のＴＣＰコネクション情報をリアルタイム収集ＭＩＢとして管理することにより、統合マネージャでの少ない操作で、サブマネージャ１０の管理範囲のトラフィックの高いＩＰノードおよびサービスを特定できるなどの効果が得られる。

統合マネージャ、サブマネージャ、エージェントを配置した通信ネットワーク管理システムの一実施例を示すシステム構成図である。 図１の統合マネージャ、サブマネージャ、エージェントの論理的な関係を示す論理関係図である。 本発明の要部であるサブマネージャの詳細構成を示す機能構成図である。 サブマネージャ拡張ＭＩＢである定期収集ＭＩＢの定義例（その１）を示す説明図である。 サブマネージャ拡張ＭＩＢである定期収集ＭＩＢの定義例（その２）を示す説明図である。 サブマネージャ拡張ＭＩＢである定期収集ＭＩＢの定義例（その３）を示す説明図である。 サブマネージャ拡張ＭＩＢであるリアルタイム収集ＭＩＢの定義例（その１）を示す説明図である。 サブマネージャ拡張ＭＩＢであるリアルタイム収集ＭＩＢの定義例（その２）を示す説明図である。 サブマネージャ拡張ＭＩＢであるリアルタイム収集ＭＩＢの定義例（その３）を示す説明図である。 サブマネージャ拡張トラップの定義例を示す説明図である。 ＭＩＢ−IIからサブマネージャ拡張ＭＩＢへ変換する管理オブジェクトの対応表を示す図である。 サブマネージャ拡張ＭＩＢであるsmgIpNodeContextの内容を示す説明図である。 サブマネージャ拡張ＭＩＢであるsmgSumTcpContextの内容を示す説明図である。 集計する定期収集ＭＩＢの対応表を示す図である。 環境設定ファイルの例を示す説明図である。 管理範囲テーブルの内容例を示す説明図である。 管理範囲の監視方法（メイン）の概略ＰＡＤ図である。 管理範囲の初期設定の概略ＰＡＤ図である。 管理範囲の監視の概略ＰＡＤ図である。 ルータ判定の概略ＰＡＤ図である。 ｐｉｎｇ処理の概略ＰＡＤ図である。 集計処理の概略ＰＡＤ図である。 管理範囲の更新の概略ＰＡＤ図である。 更新処理の概略ＰＡＤ図である。 通信制御機能における振り分け方法の概略ＰＡＤ図である。 サブマネージャエージェント機能における振り分け方法の概略ＰＡＤ図である。 定期収集ＭＩＢ値管理テーブルの内容例を示す説明図である。 収集データベース管理機能の概略ＰＡＤ図である。 定期収集ＭＩＢである集計値の統合マネージャでのグラフ表示例を示す説明図である。 集約化機能が対象とするＴＣＰコネクションの例を示す説明図である。 ＭＩＢ−IIのtcpConnStateのインデックスと値の形式を示す説明図である。 リアルタイム収集ＭＩＢのsmgSumTcpContextのインデックスと値の形式を示す説明図である。 ＭＩＢ−IIのtcpConnStateとリアルタイム収集ＭＩＢのsmgSumTcpContextとの変換説明図である。 リアルタイム収集ＭＩＢのインデックスの順序性を示す説明図である。 管理範囲の集約化方法（メイン）の概略ＰＡＤ図である。 管理範囲の集約化方法（ｇｅｔ処理）の概略ＰＡＤ図である。 管理範囲の集約化方法（ｇｅｔ発行）の概略ＰＡＤ図である。 管理範囲の集約化方法（ｇｅｔ−ｎｅｘｔ処理）の概略ＰＡＤ図である。 管理範囲の集約化方法（次インデックス算出）の概略ＰＡＤ図である。 管理範囲の集約化方法（ｇｅｔ−ｎｅｘｔ発行）の概略ＰＡＤ図である。 ＳＮＭＰトラップからサブマネージャ拡張トラップへの変換図である。 ＳＮＭＰトラップからサブマネージャ拡張トラップへの変換図である。 ＳＮＭＰトラップの削減方式の概略ＰＡＤ図である。

符号の説明

１０，１０ａ，１０ｂ，１０ｃ…サブマネージャ、２０，２０ａ−１，２０ａ−２，２０ｂ−１，２０ｂ−２，２０ｃ…エージェント、３０ａ，３０ｃ…エージェント未実装のＩＰノード、５０…統合マネージャ、１００…通信制御機能、１１０…管理範囲監視機能、１２０…収集データベース管理機能、１３０…自エージェント機能、１４０…サブマネージャエージェント機能、１５０…集約化機能、１６０…トラップ管理機能、１７０…収集ＭＩＢデータベース、１８０…環境設定ファイル、５００…管理範囲テーブル

Claims (2)

1. ネットワーク資源単位に当該ネットワーク資源に関する情報及び当該ネットワーク資源と他のネットワーク資源との通信コネクションに関する情報を管理オブジェクトとして管理する複数のエージェントと、当該複数のエージェントとＳＮＭＰを用いて通信することにより前記管理オブジェクトを収集し、当該収集した管理オブジェクトのうち各ネットワーク資源に関する情報を集約した新たな管理オブジェクト及び複数のネットワーク資源に関連する通信コネクションに関する情報を集約した新たな管理オブジェクトを各々生成して管理するサブマネージャと、当該サブマネージャとＳＮＭＰを用いて通信することにより前記新たな管理オブジェクトを参照する統合マネージャとを備えたことを特徴とするネットワーク管理システム。
2. ネットワーク資源単位に当該ネットワーク資源に関連する情報を管理する複数のエージェントからの情報を収集し、当該収集した情報を集約して新たな情報を生成し、当該新たな情報を統合マネージャヘ通知するサブマネージャにおけるネットワーク管理方法であって、前記複数のエージェントとＳＮＭＰを用いて通信することにより収集される情報を各ネットワーク資源に関する情報及び複数のネットワーク資源に関連する情報として各々集約し、当該集約された情報をＳＮＭＰを用いて通信することにより前記統合マネージャに通知することを特徴とするネットワーク管理方法。
   

Images