JP2014199974A - ネットワークエレメント監視システム及びサーバ - Google Patents

Abstract

【課題】ネットワークエレメント（ＮＥ）を監視するサーバの処理負荷を軽減する。
【解決手段】ＡＣＴ系のサーバ２０は、一部のＮＥ３０が故障する等して、一定時間内に規定数以上の大量のＴｒａｐであるバースト警報情報が通知された場合、ＳＴＢＹ系サーバ２０に対し、ＡＣＴ系サーバ２０に切り替わってバースト警報情報を通知しているＮＥ３０以外のＮＥ３０を監視対象とするよう要求し、自身はＳＴＢＹ系に切り替え、バースト警報情報を通知しているＮＥ３０を監視（ヘルスチェック）対象とする。
【選択図】図２

Description

本発明の一態様は、ネットワークエレメント監視システム及びサーバに関する。

図２６に例示するように、伝送装置運用システムの一態様は、１又は複数のクライアント装置を含むクライアントシステムと、システムの信頼性／堅牢性向上のために冗長構成化したサーバシステムとを含むクライアント−サーバ型のシステムである。

サーバシステムは、ネットワーク（以下「監視ネットワーク」という。）により１又は複数の伝送装置（ネットワークエレメント：ＮＥ）と通信可能に接続されており、ＮＥの運用状態等を監視する。また、サーバシステムは、クライアントシステムとも通信可能に接続されており、ＮＥの監視結果をクライアントシステムに提供できる。

監視性能の向上を目的に、アクティブ／スタンバイ（ＡＣＴ／ＳＴＢＹ）の両系サーバから伝送装置を監視（以下、デュアル監視）するため、サーバシステムには、ホットスタンバイ型冗長構成を採用することがある。

デュアル監視を実現するため、ＡＣＴ／ＳＴＢＹ両系のサーバは、独立して監視対象のＮＥに対し稼働状況（疎通状態）のチェック（ヘルスチェック）を実施する。また、ＮＥの故障発生時や状態変化時に当該ＮＥから送信されるトラップ（Ｔｒａｐ）をそれぞれのサーバで受信し、管理することができる。

通信網及びＮＥの構成（コンフィギュレーション）情報（例えば、エリア情報、ノード情報、ファシリティ情報、パス情報等）の管理については、マルチマスター型レプリケーションを用い、両系サーバで同期した情報を管理することができる。

なお、伝送装置の監視技術として、下記の特許文献１に記載された技術が知られている。

特開２００８−２１９２７９号公報

昨今の通信量の増大、通信サービスの多種多様化に伴い、１システムで管理するＮＥの数は増大する傾向にある。そのため、通常運転時においても、ヘルスチェック実施やＮＥから通知されるＴｒａｐによってサーバの負荷が増大したり、サーバとＮＥとの間の監視ネットワークの通信負荷が増大したりする。

こうした状況で、図２７に例示するように、監視対象であるＮＥにおいて故障等に伴う大量のトラップが発生した場合、監視ネットワークの通信負荷が更に増大する。これに伴い、通常運転中のＮＥが送信したＴｒａｐの欠落や遅達等が発生し、ＮＥの監視に影響する。例えば、クライアントシステムにおいて、Ｔｒａｐが確認できなかったり、実際にＴｒａｐが発生した時点から遅れてＴｒａｐが表示されたりする。

また、大量のＴｒａｐを処理するためにサーバの処理負荷も増大し、ＮＥ運用システム全体にも影響を及ぼしてしまう。

本発明の目的の１つは、ＮＥを監視するサーバの処理負荷を軽減することにある。

ネットワークエレメント監視システムの一態様は、複数のネットワークエレメント（ＮＥ）に対しヘルスチェックを実施することにより前記ＮＥの稼動状況を監視する第１のサーバ及び第２のサーバを備え、前記第１のサーバは、監視対象のＮＥからのイベント情報の受信状況に応じて、前記ヘルスチェックの実施元を前記第２のサーバに変更する。

ＮＥを監視するサーバの処理負荷を軽減することができる。

一実施形態に係る伝送装置（ＮＥ）運用システム（ＮＥ監視システム）の一例を模式的に示す図である。 図１に例示するシステムの模式的な動作例を説明する図である。 図１及び図２に例示するクライアント装置のハードウェア構成例を示すブロック図である。 図１及び図２に例示するクライアント装置の機能ブロック図である。 図１及び図２に例示するＮＥのハードウェア構成例を示すブロック図である。 図１及び図２に例示するＮＥの機能ブロック図である。 図１及び図２に例示するサーバシステムのハードウェア構成例を示すブロック図である。 図１及び図２に例示するサーバの機能ブロック図である。 図８に例示する構成情報データベースの一例を示す図である。 図８に例示する通知情報データベースの一例を示す図である。 図８に例示するヘルスチェック管理部の動作例を示すフローチャートである。 図８に例示する通知情報管理部の動作例を示すフローチャートである。 図８に例示する通知情報管理部の動作例を示すフローチャートである。 図８に例示する通知情報管理部の動作例を示すフローチャートである。 図８に例示するヘルスチェック管理部の動作例を示すフローチャートである。 図８に例示する通知情報管理部の動作例を示すフローチャートである。 図８に例示する管理部の動作例を示すフローチャートである。 図８に例示する通知情報管理部の動作例を示すフローチャートである。 図８に例示する通知情報管理部の動作例を示すフローチャートである。 図８に例示するヘルスチェック管理部の動作例を示すフローチャートである。 図１に例示するシステムの模式的な動作例を説明する図である。 他の実施形態に係る伝送装置（ＮＥ）運用システム（ＮＥ監視システム）の一例を模式的に示す図である。 他の実施形態に係る管理部の動作例を示すフローチャートである。 他の実施形態に係る通知情報管理部の動作例を示すフローチャートである。 他の実施形態に係る通知情報管理部の動作例を示すフローチャートである。 伝送装置（ＮＥ）運用システム（ＮＥ監視システム）の一例を模式的に示す図である。 図２６に例示するシステムの課題を説明するための模式図である。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

図１は、一実施形態に係る伝送装置（ＮＥ）運用システム（ＮＥ監視システム）の一例を模式的に示す図である。図１に示す伝送装置運用システムは、例示的に、１又は複数のクライアント装置１０を含むクライアントシステムと、ＡＣＴ／ＳＴＢＹ系の複数のサーバ２０を含む冗長構成化されたサーバシステムと、監視対象の複数のＮＥ３０と、を備える。

サーバシステムは、１又は複数の監視ネットワークによりいずれかのＮＥ３０と通信可能に接続されており、ＮＥ３０の運用状態の監視を行なう。図１の例では、ＮＥ３０が１つの監視ネットワークに接続されており、別のＮＥが別の監視ネットワークに接続されている。サーバシステムは、ＮＥ３０の故障時や状態変化の発生時等にＮＥから送信されるＴｒａｐ（以下「警報」と表記することもある。）を受信、管理する。

サーバシステムを成すＡＣＴ／ＳＴＢＹ系の両サーバ（第１及び第２のサーバ）２０は、互いに通信可能に接続されており、互いが保持する情報（Ｔｒａｐ情報等）を互いに通知し合うことにより同期させることが可能である。したがって、クライアントシステムは、ＡＣＴ／ＳＴＢＹ系のいずれのサーバ２０にアクセスしても同じ情報を得ることができ、クライアントシステムにおいて監視状態に差分が生じない。

クライアントシステムは、サーバシステムと通信可能に接続されており、サーバシステムによる監視結果をイベント情報等としてオペレータ等に提示する。当該提示は、クライアント装置のディスプレイ（表示装置）にイベント情報を表示することで実施してもよいし、プリンタ（印刷装置）にイベント情報を印刷することで実施してもよい。

サーバシステムは、図２に模式的に例示するように、一部のＮＥ３０が故障する等してＡＣＴ系のサーバ２０に一定時間内に規定数（閾値）以上の大量のＴｒａｐ（以下「バースト警報」という。）情報が通知された場合、当該サーバをＳＴＢＹ系に切り替える。その際、サーバシステムは、ＳＴＢＹ系のサーバ２０をＡＣＴ系のサーバ２０に切り替える。

当該切り替えは、サーバ２０どうしの相互通信により実施される。切り替え後のＳＴＢＹ系のサーバ２０は、バースト警報を通知しているＮＥ（以下「バーストＮＥ」という。）３０を監視（ヘルスチェック）対象とし、その他の通常運用中のＮＥ（以下「通常ＮＥ」という。）３０は切り替え後のＡＣＴ系のサーバによる監視（ヘルスチェック）対象とする。バーストＮＥ３０は第１のＮＥの一例であり、通常ＮＥ３０は第２のＮＥの一例である。

具体的に、ＡＣＴ系サーバ２０は、バースト警報を受信すると、ＳＴＢＹ系サーバ２０に対し、ＡＣＴ系サーバ２０に切り替わってバーストＮＥ３０以外のＮＥ３０を監視対象とするよう要求し、自身はＳＴＢＹ系サーバ２０に切り替わってバーストＮＥ３０を監視対象とする。

当該サーバ切り替えに伴って、通常ＮＥのＴｒａｐ情報の通知先は、切り替え後のＡＣＴ系サーバ２０とする。切り替え後のＡＣＴ系サーバ２０は、通常ＮＥ３０から通知されるＴｒａｐ情報をＳＴＢＹ系サーバ２０に通知してよい。これにより、両サーバ２０が管理する情報を同期させることができる。

以下、クライアント装置１０、ＮＥ３０、及び、サーバシステムの構成例について、図３〜図８を参照して説明する。

（クライアント装置）
図３は、クライアント装置１０のハードウェア構成例を示すブロック図である。図３に示すクライアント装置１０は、例示的に、パーソナルコンピュータ（ＰＣ）１０１と、その周辺機器の一例としてのディスプレイ１０２、キーボード１０３及びマウス１０４等を備える。ディスプレイ１０２は、オペレータに情報を提示する出力装置の一例であり、キーボード１０３及びマウス１０４は、ＰＣ１０１に情報を入力する入力装置の一例である。

ＰＣ１０１は、例示的に、ＣＰＵ、メモリ、ハードディスクドライブ（ＨＤＤ）、ネットワークインタフェースカード（ＮＩＣ）、及び、冷却用のファン（ＦＡＮ）等を備える。ＣＰＵが、メモリやＨＤＤから必要に応じてプログラムやデータを読み取って動作することで、クライアント装置１０としての機能が具現される。

図４に、クライアントシステムを成すクライアント装置１０の機能ブロック図を例示する。図４に示すクライアント装置１０は、例示的に、グラフィカルユーザインタフェース（ＧＵＩ）表示／データ入出力部１１１と、サーバシステム向け通信部１１２と、を備える。

ＧＵＩ表示／データ入出力部１１１は、サーバシステム向け通信部１１２から受信した情報をディスプレイ１０２に表示する。また、ＧＵＩ表示／データ入出力部１１１は、オペレータ等のユーザから受け付けた情報をサーバシステム向け通信部１１２に送信する。当該情報には、例示的に、サーバシステムを制御する要求等が含まれてよい。

サーバシステム向け通信部１１２は、サーバシステムから受信した情報をＧＵＩ／データ入出力部１１１に送信する。また、サーバシステム向け通信部１１２は、入力装置を通じてＧＵＩ表示／データ入出力部１１１から受信した情報をサーバシステムに送信する。

（ＮＥ）
次に、図５に、ＮＥ３０のハードウェア構成例を示す。図５に示すＮＥ３０は、例示的に、メモリを有する１又は複数のラインインタフェースユニット（ＬＩＵ）３０１と、ＬＩＵ３０１を通じた通信やＮＥ３０の動作を制御する制御部（ＣＯＭ）３０２と、冷却用のファン（ＦＡＮ）３０３と、を備える。

ＬＩＵ３０１は、その用途に応じて光ファイバケーブルやイーサネット（登録商標）ケーブル等の通信ケーブルが接続される。

制御部３０２は、例示的に、ＣＰＵ、メモリ、ＨＤＤ、及び、ＮＩＣを備える。ＣＰＵが、メモリやＨＤＤから必要に応じてプログラムやデータを読み取って動作することで、ＮＥ３０としての機能が具現される。

図６に、ＮＥ３０の機能ブロック図を例示する。図６に示すＮＥ３０は、例示的に、サーバシステム向け通信部３１１、ハードウェア設定／制御部３１２、Ｔｒａｐ情報生成処理部３１３、及び、ハードウェアシグナル受信部３１４を備える。

ハードウェア設定／制御部３１２は、サーバシステムから受信した制御情報をハードウェア設定／制御部３１２に送信する。また、ハードウェア設定／制御部３１２は、Ｔｒａｐ情報生成処理部３１３から受信した情報をサーバシステムに送信する。

ハードウェア設定／制御部３１２は、ＬＩＵ３０１等に対してハードウェア設定やハードウェア制御を行なう。

Ｔｒａｐ情報生成処理部３１３は、ハードウェアシグナル受信部３１４から受信した状態変化（イベント）通知を基にサーバシステムに通知するためのＴｒａｐ情報を生成し、生成したＴｒａｐ情報をサーバシステム向け通信部３１１に送信する。Ｔｒａｐ情報は、Ｅの故障発生時や状態変化時に当該ＮＥ３０から送信されるイベント情報の一例である。

（サーバシステム）
次に、図７に、サーバシステムのハードウェア構成例を示す。図７に示すサーバシステムは、例示的に、ＡＣＴ系（０系）サーバ２０−１及びＳＴＢＹ系（１系）サーバ２０−２の２つのサーバを備える。各サーバ２０−１及び２０−２は、それぞれ、出力装置の一例としてのディスプレイ（表示装置）２０１、入力装置の一例としてのキーボード２０２及びマウス２０３を備える。

また、各サーバ２０−１及び２０−２（以下、両者を区別しない場合には「サーバ２０」と表記する。）は、それぞれ、ＣＰＵ、メモリ、ＨＤＤ、クライアント向けＮＩＣ、他系サーバ向けＮＩＣ、ＮＥ向けＮＩＣ、及び、冷却用のファンを備える。ＣＰＵが、メモリやＨＤＤから必要に応じてプログラムやデータを読み取って動作することで、サーバ２０としての機能が具現される。

クライアント向けＮＩＣは、クライアントシステムとの通信インタフェースである。

他系サーバ向けＮＩＣは、他系のサーバとの通信インタフェースである。

ＮＥ向けＮＩＣは、ＮＥ３０との通信インタフェースである。

図８に、サーバ２０の機能ブロック図を例示する。図８に示すサーバ２０は、例示的に、管理部２１１、クライアントシステム向け通信部２１２、ＮＥ向け通信部２１３、他系サーバ通信部２１４、通知情報管理部２１５、ＮＥ制御部２１６、ヘルスチェック管理部２１７、サーバ運用系管理部２１８、構成情報データベース２１９、及び、通知情報データベース２２０を備える。

管理部２１１は、クライアントシステム向け通信部２１２から受信した要求の処理及び起動／停止を含め、サーバ２０全体を制御する。また、管理部２１１は、クライアントシステムに通知する情報をクライアントシステム向け通信部２１２に送信する。

クライアントシステム向け通信部２１２は、クライアントシステムから受信した情報を管理部２１１に送信する。また、クライアントシステム向け通信部２１２は、管理部２１１から受信した情報をクライアントシステムに送信する。

ＮＥ向け通信部２１３は、ＮＥ制御部２１６及びヘルスチェック管理部２１７から受信した制御要求に応じたコマンド送信及び情報取得をＮＥ３０に対して実施する。また、ＮＥ向け通信部２１３は、ＮＥ３０から受信したＴｒａｐ通知（Ｔｒａｐ情報）を通知情報管理部２１５に送信する。

他系サーバ通信部２１４は、他系サーバ２０から受信した情報を処理する。また、他系サーバ通信部２１４は、他系サーバ２０に情報を送信する。

通知情報管理部２１５は、ＮＥ向け通信部２１３から受信したＴｒａｐ通知を通知情報データベース２２０に格納するとともに、条件によっては他系サーバ通信部２１４にＴｒａｐ通知を送信する。

ＮＥ制御部２１６は、ＮＥ３０を制御する要求を受信し、要求に応じたコマンドを生成し、生成したコマンドをＮＥ向け通信部２１３に送信する。

ヘルスチェック管理部２１７は、管理部２１１から受信したヘルスチェック要求に応じて、ＮＥ向け通信部２１３に対し、ヘルスチェック要求を送信する。また、ヘルスチェック管理部２１７は、ＮＥ向け通信部２１３から受信したヘルスチェックの実施結果を、通知情報データベース２２０に格納する。

サーバ運用系管理部２１８は、サーバ２０の運用／非運用の状態を管理する。

構成情報データベース２１９は、管理するＮＥ３０の情報やＮＥ３０で構成されるネットワークの情報を保持する。構成情報データベース２１９の一例を図９に示す。図９に示す構成情報データベースは、例示的に、システムテーブル２１９１及びＮＥ管理テーブル２１９２を０系／１系の別に保持する。

システムテーブル２１９１には、例示的に、系情報、運用系情報、バースト警報受信情報等が設定可能である。系情報は、０系か１系かを示す情報であり、運用系情報は、ＡＣＴ／ＳＴＢＹを示す情報であり、バースト警報受信情報は、バースト警報の受信状態を示す情報である。

ＮＥ管理テーブル２１９２には、例示的に、ＮＥ番号、ＮＥ名、ＩＰアドレス、監視状態等の情報が設定可能である。

通知情報データベース２２０は、ＮＥ３０から受信したＴｒａｐ情報を格納する。通知情報データベース２２０の一例を図１０に示す。図１０に示す通知情報データベース２２０は、例示的に、アラーム管理テーブル２２０１を保持する。アラーム管理テーブル２２０１には、アラーム名、アラームの発生日時、アラームの発生したＮＥ番号、発生したアラームの重要度等の情報が設定可能である。

構成情報データベース２１９及び通知情報データベース２２０は、例えば図７に例示したＨＤＤに記憶される。

（動作説明）
以下、上述したＮＥ運用システムの動作について、図１１〜図２０を参照して説明する。

図１１は、ヘルスチェック管理部２１７の動作例を示すフローチャートである。
監視対象のＮＥ３０を新規に追加した場合やサーバ２０を起動した場合、管理部２１１が、ＮＥ３０の疎通状態確認のため、ヘルスチェック管理部２１７に対し、ヘルスチェック開始要求を送信する。

ヘルスチェック管理部２１７は、対象ＮＥ３０をスケジュール登録後、ヘルスチェック実施シーケンスに移行する。ヘルスチェック実施シーケンスでは、構成情報データベース２１９（ＮＥ管理テーブル２１９２）における対象ＮＥの「監視状態」カラムを参照する（処理Ｐ１１及びＰ１２）。

対象ＮＥの「監視状態」カラムが「初期状態」もしくは「自系監視」を示す場合、ヘルスチェック管理部２１７は、ＮＥ向け通信部２１３に対し、ヘルスチェック実施要求を送信する（処理Ｐ１３）。対象ＮＥ３０の「監視状態」カラムが「他系監視」を示す場合、ヘルスチェック管理部２１７は、次のＮＥ３０の処理に移行する。

ＮＥ向け通信部２１３は、ヘルスチェック管理部２１７からヘルスチェック実施要求を受信すると、対象ＮＥ３０に対してヘルスチェックを実施し、実施結果をヘルスチェック管理部２１７に送信する（処理Ｐ１４）。

ヘルスチェック管理部２１７は、ヘルスチェックの実施結果が「異常」を示す場合、他系サーバ通信部２１４に対し、ヘルスチェック結果を通知する（処理Ｐ１５）。他系サーバ通信部２１４は、他系サーバ２０に対しヘルスチェック結果を送信する。

ヘルスチェックの実施結果が「正常」または「異常からの復旧」を示す場合、ヘルスチェック管理部２１７は、構成情報データベース２１９（ＮＥ管理テーブル２１９２）における対象ＮＥ３０の「監視状態」カラムをチェックする（処理Ｐ１６）。

「監視状態」カラムのチェック結果が「初期状態」を示す場合、ヘルスチェック管理部２１７は、当該「監視状態」カラムを「自系監視」に更新する（処理Ｐ１７）。また、ヘルスチェック管理部２１７は、他系サーバ通信部２１４に対し、ヘルスチェック結果を通知する（処理Ｐ１８）。

他系サーバ通信部２１４は、他系サーバ２０に対しヘルスチェック結果を送信する。また、ヘルスチェック管理部２１７は、Ｔｒａｐ通知先に自系サーバ２０を設定する（処理Ｐ１９）。

監視状態カラムのチェック結果が「初期状態」でない場合、ヘルスチェック管理部２１７は、次のＮＥ３０の処理に移行する。

ヘルスチェック管理部２１７は、他系サーバ２０から「正常」を示すヘルスチェック結果を受信した際には、構成情報データベース２１９のシステムテーブル２１９１を参照し（処理Ｐ２１）、「運用状態（運用系情報）」カラムが「ＡＣＴ」及び「ＳＴＢＹ」のいずれとなっているかをチェックする（処理Ｐ２２）。

「運用状態（運用系情報）」カラムが「ＳＴＢＹ」の場合、ヘルスチェック管理部２１７は、構成情報データベース２１９のＮＥ管理テーブル２１９２を参照し、「監視状態」カラムが「自系監視」を示しているか否かをチェックする（処理Ｐ２３）。

「監視状態」カラムが「自系監視」の場合、ヘルスチェック管理部２１７は、Ｔｒａｐ通知先の情報から自系サーバの情報を削除し（処理Ｐ２４）、対象ＮＥの「監視状態」カラムを「他系監視」に更新する（処理Ｐ２５）。

なお、処理Ｐ２２において、「運用状態（運用系情報）」カラムが「ＡＣＴ」の場合、ヘルスチェック管理部２１７は、処理を終了する。また、処理Ｐ２３において「監視状態」カラムが「他系監視」の場合、ヘルスチェック管理部２１７は、対象ＮＥ３０の「監視状態」カラムを「他系監視」に維持する。

ヘルスチェック管理部２１７は、他系サーバ２０から「異常」を示すヘルスチェック結果を受信した際には、構成情報データベース２１９のシステムテーブル２１９１を参照し、「運用状態（運用系情報）」カラムが「ＡＣＴ」及び「ＳＴＢＹ」のいずれとなっているかをチェックする（処理Ｐ３１）。

「運用状態（運用系情報）」カラムが「ＳＴＢＹ」の場合、ヘルスチェック管理部２１７は、構成情報データベース２１９（ＮＥ管理テーブル２１９２）における対象ＮＥ３０の「監視状態」カラムを「他系監視」に更新する（処理Ｐ３２）。一方、「運用状態（運用系情報）」カラムが「ＡＣＴ」の場合、ヘルスチェック管理部２１７は、処理を終了する。

対象ＮＥ３０の「監視状態」カラムを「他系監視」に更新した場合、ヘルスチェック管理部２１７は、ＮＥ向け通信部２１３に対し、ヘルスチェック実施要求を送信する（処理Ｐ３３）。

ＮＥ向け通信部２１３は、ヘルスチェック管理部２１７からヘルスチェック実施要求を受信すると、対象ＮＥ３０に対してヘルスチェックを実施し、実施結果をヘルスチェック管理部２１７に送信する。

ヘルスチェック管理部２１７は、ヘルスチェックの実施結果をチェックし（処理Ｐ３４）、実施結果が「異常」を示す場合、処理を終了する。一方、ヘルスチェックの実施結果が「正常」を示す場合、ヘルスチェック管理部２１７は、Ｔｒａｐ通知先の情報に自系サーバの情報を設定して（処理Ｐ３５）処理を終了する。

以上のようにして、サーバ間で連動したヘルスチェックを実施することが可能となる。

なお、ヘルスチェック管理部２１７は、構成情報データベース２１９（ＮＥ管理テーブル２１９２）における対象ＮＥ３０の「監視状態」カラムを「自系監視」（もしくは「両系監視」）に更新した際には、ＮＥ制御部２１６に対し、対象ＮＥ３０のＴｒａｐ通知先設定要求を送信する。

また、ヘルスチェック管理部２１７は、対象ＮＥ３０の「監視状態」カラムを「他系監視」に更新した場合は、ＮＥ制御部２１６に対し、対象ＮＥ３０のＴｒａｐ通知先解除要求を送信する。

ＮＥ向け通信部２１３は、Ｔｒａｐ通知先変更コマンド（Ｔｒａｐ通知先設定／解除要求）を受信すると、対象ＮＥ３０に対しコマンドを送信する。

これにより、各系のサーバ２０のうち、ヘルスチェックを実施している系のサーバ２０でのみ、ＮＥからのＴｒａｐ通知を受信することが可能となる。

図１２は、通知情報管理部２１５の動作例を示すフローチャートである。
ＮＥ３０からＴｒａｐ通知を受信したＮＥ向け通信部２１３は、通知情報管理部２１２５にＴｒａｐ情報を送信する。通知情報管理部２１５は、通知情報データベースにＴｒａｐ情報を格納し（処理Ｐ４１）、他系サーバ通信部２１４に対し、Ｔｒａｐ情報を送信する（処理Ｐ４２）。

また、通知情報管理部２１５は、他系サーバ通信部２１４からＴｒａｐ情報を受信した場合、構成情報データベース２１９（ＮＥ管理テーブル２１９２）における対象ＮＥ３０の「監視状態」カラムを参照する（処理Ｐ５１及びＰ５２）。

「監視状態」カラムが「自系監視」の場合、通知情報管理部２１５は、処理を終了する。一方、「監視状態」カラムが「他系監視」を示している場合、通知情報管理部２１５は、通知情報データベース２２０にＴｒａｐ情報を格納する（処理Ｐ５３）。

通知情報データベース２２０に格納されたＴｒａｐ情報は、管理部２１１が取得し、クライアントシステム向け通信部２１２に対し情報通知を行なうことで、クライアントシステムにＴｒａｐ情報を通知する。

以上のようにして、一方の系で受信したＴｒａｐ情報を他方の系に通知することで、両系が同一Ｔｒａｐ情報を受信することが可能となる。

図１３及び図１４は、通知情報管理部２１５の動作例を示すフローチャートである。
図１３に例示するように、通知情報管理部２１５は、ＮＥ向け通信部２１３からＴｒａｐ情報を受信すると、内部メモリにＴｒａｐ情報を格納する。なお、規定時間を超えたＴｒａｐ情報は削除してよい（処理Ｐ６１）。通知情報管理部２１５は、同一ＮＥ３０から規定時間内に受信したＴｒａｐ数をチェックし（処理Ｐ６２）、受信Ｔｒａｐ数が規定数を超えたか否かをチェックする（処理Ｐ６３）。なお、規定時間及び規定数は、コンフィギュレーションファイルにて設定可能である。

規定時間内に受信したＴｒａｐ情報数が規定数以下の場合、通知情報管理部２１５は、処理を終了する。規定時間内に規定数を超えるＴｒａｐ情報を受信した場合、通知情報管理部２１５は、対象ＮＥ３０から大量警報（バースト警報）が発生したと判断する。バースト警報が発生したと判断すると、通知情報管理部２１５は、構成情報データベース２１９のＮＥ管理テーブル２１９２における対象ＮＥの「バースト状態」カラムを「発生」に更新するとともに、システムテーブル２１９１の「バースト警報受信」カラムを「自系」に更新する（処理Ｐ６４）。そして、通知情報管理部２１５は、他系サーバ通信部２１４に対し、対象ＮＥ３０のバースト状態を通知する（処理Ｐ６５）。

一方、図１４に例示するように、他系サーバ２０の他系サーバ通信部２１４にバースト状態が通知されると、通知情報管理部２１５は、構成情報データベース２１９（ＮＥ管理テーブル２１９２）における対象ＮＥの「バースト状態」カラムを「発生」に更新する。また、通知情報管理部２１５は、システムテーブル２１９１の「バースト警報受信」カラムを「他系」に更新する（処理Ｐ７１）。

また、通知情報管理部２１５は、バースト警報発生Ｔｒａｐを生成し（処理Ｐ７２）、生成したバースト警報発生Ｔｒａｐを通知情報データベース２２０に格納する（処理Ｐ７３）。これにより、バースト警報が発生していることをクライアントシステムに通知することが可能となる。

なお、図１５に例示するように、ヘルスチェック管理部２１７によるヘルスチェック実施シーケンスでは、構成情報データベース２１９を参照し（処理Ｐ８１）、「バースト受信警報」カラム、「バースト状態」カラム、及び、「監視状態」カラムのチェックを実施する（処理Ｐ８２〜Ｐ８４）。

構成情報データベース２１９の「バースト受信警報」カラムが「他系」の場合で、対象ＮＥ３０の「バースト状態」カラムが「発生」以外であり、かつ、「監視状態」カラムが「他系監視」の場合に、ヘルスチェック管理部２１７は、ＮＥ向け通信部２１３に対し、ヘルスチェック実施要求を送信する（処理Ｐ８５）。

ＮＥ向け通信部２１３は、対象ＮＥ３０に対してヘルスチェックを実施し、実施結果をヘルスチェック管理部２１７に送信する。ヘルスチェック管理部２１７は、ヘルスチェック結果が「正常」であるか「異常」であるかをチェックする（処理Ｐ８６）。

「正常」であれば、ヘルスチェック管理部２１７は、構成情報データベース２１９における対象ＮＥ３０の「監視状態」カラムを「バースト対応自系」に更新する（処理Ｐ８７）とともに、他系サーバ通信部２１４に対し、ヘルスチェック結果を送信する（処理Ｐ８８）。また、ヘルスチェック管理部２１７は、Ｔｒａｐ通知先の情報に自系サーバの情報を設定する（処理Ｐ８９）。

なお、「バースト受信警報」カラムが「他系」以外の場合、対象ＮＥの「バースト状態」カラムが「発生」の場合、あるいは、「監視状態」カラムが「自系監視」の場合、ヘルスチェック管理部２１７は、次のＮＥ３０の処理に移行する。

自系サーバ２０のヘルスチェック管理部２１７は、他系サーバ２０からのヘルスチェック結果を受信した際には、Ｔｒａｐ通知先の情報から自系サーバの情報を削除し（処理Ｐ９１）、構成情報データベース２１９の対象ＮＥ３０の「監視状態」カラムを「他系監視」に更新する（処理Ｐ９２）。

ヘルスチェック管理部２１７は、構成情報データベース２１９における対象ＮＥ３０の「監視状態」カラムが「初期状態」、「自系監視」、及び、「バースト対応自系」の場合にヘルスチェックを実施する。

以上により、同一ＮＥ３０からバースト警報を受信した場合、該当ＮＥ３０以外のヘルスチェックを実施するサーバ２０をＳＴＢＹ系に切り替えることが可能となる。

なお、ヘルスチェック管理部２１７は、構成情報データベース２１９における対象ＮＥ３０の「監視状態カラム」を「バースト対応自系」もしくは「バースト対応他系」に更新した際には、ＮＥ制御部２１６に対し、対象ＮＥ３０のＴｒａｐ通知先設定要求を送信する。

また、対象ＮＥ３０の「監視状態」カラムを「他系監視」に更新した場合、ヘルスチェック管理部２１７は、ＮＥ制御部２１６に対し、対象ＮＥ３０のＴｒａｐ通知先解除要求を送信する。

ＮＥ向け通信部２１３は、Ｔｒａｐ通知先変更コマンド（Ｔｒａｐ通知先設定／解除要求）をＮＥ制御部２１６から受信すると、対象ＮＥ３０に対しコマンドを送信する。

以上により、ヘルスチェックを実施するサーバ２０を切り替えた際の、対象ＮＥ３０のＴｒａｐ通知先を変更することが可能となる。

図１６は、通知情報管理部２１５の動作例を示すフローチャートである。
通知情報管理部２１５は、通知情報データベース２２０及び構成情報データベース２１９を参照し（処理Ｐ９３及びＰ９４）、「バースト警報受信」カラム及び「バースト状態」カラムをチェックする（処理Ｐ９５及びＰ９６）。

通知情報管理部２１５は、「バースト警報受信」カラムが「自系」以外の場合で、「バースト状態」カラムが「発生」以外のＮＥからＴｒａｐ情報を受信した場合、他系サーバ通信部２１４に対し、Ｔｒａｐ情報を送信する（処理Ｐ９７）。

一方、「バースト警報受信」カラムが「自系」の場合で、「バースト状態」カラムが「発生」のＮＥからＴｒａｐ情報を受信した場合、通知情報管理部２１５は、他系サーバ通信部２１４に対し、Ｔｒａｐ情報を送信せずに処理を終了する。

以上により、バースト警報が発生しているＮＥ３０から受信したＴｒａｐ情報については、他方の系のサーバ２０に通知しないことが可能となる。

次に、図１７は、管理部２１１の動作例を示すフローチャートである。
管理部２１１は、通知情報データベース２２０を参照し（処理Ｐ１０１）、警報種別のチェックを行なう（処理Ｐ１０２）。当該チェックの結果、管理部２１１は、「バースト警報発生」を示す情報を取得すると、他系サーバ通信部２１４に対し、運用系切替要求を送信する（処理Ｐ１０３）。

他系サーバ通信部２１４では、サーバ運用系管理部２１８に対して、運用系の変更要求を送信するとともに、他系サーバ２０に対して、非運用系への変更要求を送信する。

以上により、バースト警報が発生しているＮＥ３０以外を監視している系をＡＣＴ系に切り替えることが可能となる。

図１８は、通知情報管理部２１５の動作例を示すフローチャートである。
通知情報管理部２１５は、ＮＥ向け通信部２１３からＴｒａｐ情報を受信すると、内部メモリにＴｒａｐ情報を格納する。なお、規定時間を超えたＴｒａｐ情報は削除してよい（処理Ｐ１１１）。通知情報管理部２１５は、同一ＮＥ３０から規定時間内に受信したＴｒａｐ数をチェックし（処理Ｐ１１２）、受信Ｔｒａｐ数が規定数以下になっているか否かをチェックする（処理Ｐ１１３）。なお、規定時間及び規定数は、コンフィギュレーションファイルにて設定可能である。

規定時間内に受信したＴｒａｐ情報数が規定数を超える場合、通知情報管理部２１５は、処理を終了する。規定時間内に受信したＴｒａｐ情報数が規定数以下の場合、通知情報管理部２１５は、対象ＮＥ３０で発生していた大量警報（バースト警報）が回復したと判断する。バースト警報が回復したと判断すると、通知情報管理部２１５は、構成情報データベース２１９のＮＥ管理テーブル２１９２における対象ＮＥ３０の「バースト状態」カラムを「発生無し」に更新するとともに、システムテーブル２１９１の「バースト警報受信」カラムを「正常」に更新する（処理Ｐ１１４）。そして、通知情報管理部２１５は、他系サーバ通信部２１４に対し、対象ＮＥ３０のバースト状態（回復）を通知する（処理Ｐ１１５）。

一方、図１９に例示するように、他系サーバ２０の他系サーバ通信部２１４にバースト状態の回復が通知されると、通知情報管理部２１５は、構成情報データベース（ＮＥ管理テーブル２１９２）における対象ＮＥ３０の「バースト状態」カラムを「発生無し」に更新する。また、通知情報管理部２１５は、システムテーブル２１９１の「バースト警報受信」カラムを「正常」に更新する（処理Ｐ１２１）。

また、通知情報管理部２１５は、バースト警報回復Ｔｒａｐを生成し（処理Ｐ１２２）、生成したバースト警報回復Ｔｒａｐを通知情報データベース２２０に格納する（処理Ｐ１２３）。これにより、バースト警報が回復したことをクライアント装置１０に通知することが可能となる。

次に、図２０は、ヘルスチェック管理部２１７の動作例を示すフローチャートである。
ヘルスチェック管理部２１７によるヘルスチェック実施シーケンスでは、構成情報データベース２１９を参照し（処理Ｐ１３１）、「バースト受信警報」カラムが「正常」であるか否か、及び、対象ＮＥ３０の「監視状態」カラムが「バースト対応自系」であるか否かをチェックする（処理Ｐ１３２及びＰ１３３）。

「バースト受信警報」が「正常」の場合で、かつ、対象ＮＥ３０の「監視状態カラム」が「バースト対応自系」の場合は、「監視状態」カラムを「自系監視」に更新する（処理Ｐ１３４）。上記以外の場合、ヘルスチェック管理部２１７は、次のＮＥ３０の処理に移行する。

なお、構成情報データベース２１９の「バースト状態」カラムを「発生無し」に更新したＮＥ３０については、「監視状態」カラムを「自系監視」に更新し、対象ＮＥ３０のＴｒａｐ通知先設定要求をＮＥ制御部２１６に送信する。ＮＥ向け通信部２１３は、ＮＥ制御部２１６からＴｒａｐ通知先変更コマンドを受信すると、ＮＥ３０に対しコマンドを送信する。

以上により、バースト警報回復時に通常の監視に自動的に戻ることが可能となる。

なお、図２１に例示するように、ＳＴＢＹ系サーバ２０がバースト警報を受信した場合、バースト警報が発生しているＮＥ３０から受信したＴｒａｐ情報は他系のサーバ２０には通知せず、バースト警報が発生していることを通知する。その際、サーバ２０のＡＣＴ／ＳＴＢＹの運用系も変更しない。

また、図２２に例示するように、ＳＴＢＹ系サーバ２０が複数存在する構成において、１つのＳＴＢＹ系サーバ２０がバースト警報を受信し、更にＡＣＴ系サーバ２０がバースト警報を受信する場合がある。この場合、残りのＳＴＢＹ系サーバ２０が、ＡＣＴ系サーバ２０に切り替わり、通常運用中のＮＥ３０を監視する。

ここで、バースト警報を受信した際の通知情報管理部２１５及びヘルスチェック管理部２１７の処理としては、ＡＣＴ系サーバ２０及びＳＴＢＹ系サーバ２０で同様となる。図２３に、管理部２１１の動作例を示す。

図２３に例示するように、管理部２１１は、通知情報データベース２１９を参照し（処理Ｐ１４１）、警報種別のチェックを行なう（処理Ｐ１４２）。当該チェックの結果、管理部２１１は、「バースト警報発生」を示す情報を取得すると、構成情報データベース２１９の「運用系情報」カラムを参照、チェックする（処理Ｐ１４３及びＰ１４４）。

「運用系情報」カラムが「ＡＣＴ」であれば、管理部２１１は、他系サーバ通信部２１４に対し、運用系切替要求を送信する（処理Ｐ１４５）。一方、警報種別が「バースト発生無し」の場合や「運用系情報」カラムが「ＳＴＢＹ」であれば、管理部２１１は、他系サーバ通信部２１４に対し、運用系切替要求を送信しない。

また、図２４に例示するように、通知情報管理部２１５は、ＮＥ向け通信部２１３からＴｒａｐ情報を受信すると、内部メモリにＴｒａｐ情報を格納する。なお、規定時間を超えたＴｒａｐ情報は削除してよい（処理Ｐ１５１）。通知情報管理部２１５は、同一ＮＥ３０から規定時間内に受信したＴｒａｐ数をチェックし（処理Ｐ１５２）、受信Ｔｒａｐ数が規定数を超えたか否かをチェックする（処理Ｐ１５３）。なお、規定時間及び規定数は、コンフィギュレーションファイルにて設定可能である。

規定時間内に受信したＴｒａｐ情報数が規定数以下の場合、通知情報管理部２１５は、処理を終了する。規定時間内に規定数を超えるＴｒａｐ情報を受信した場合、通知情報管理部２１５は、対象ＮＥ３０から大量警報（バースト警報）が発生したと判断する。バースト警報が発生したと判断すると、通知情報管理部２１５は、構成情報データベース２１９のＮＥ管理テーブル２１９２における対象ＮＥ３０の「バースト状態」カラムを「発生」に更新する。

その際、「バースト警報受信」カラムが「他系」であった場合、バースト警報を両系で受信することになるので、通知情報管理部２１５は、構成情報データベース２１９のシステムテーブル２１９１における「バースト警報受信」カラムを「両系」に更新する（処理Ｐ１５４）。そして、通知情報管理部２１５は、他系サーバ通信部２１４に対し、対象ＮＥ３０のバースト状態を通知する（処理Ｐ１５５）。これにより、第３のサーバ２０に対し、対象ＮＥのバースト状態を通知することができる。

一方、図２５に例示するように、他系サーバ２０の他系サーバ通信部２１４にバースト状態が通知されると、通知情報管理部２１５は、構成情報データベース２１９（ＮＥ管理テーブル２１９２）における対象ＮＥ３０の「バースト状態」カラムを「発生」に更新する。また、通知情報管理部２１５は、システムテーブル２１９１の「バースト警報受信」カラムを「他系」に更新する（処理Ｐ１６１）。

また、通知情報管理部２１５は、バースト警報発生Ｔｒａｐを生成し（処理Ｐ１６２）、生成したバースト警報発生Ｔｒａｐを通知情報データベース２２０に格納する（処理Ｐ１６３）。これにより、バースト警報が発生していることをクライアント装置１０に通知することが可能となる。

１０ クライアント装置
１０１ パーソナルコンピュータ（ＰＣ）
１０２ ディスプレイ
１０３ キーボード
１０４ マウス
１１１ ＧＵＩ表示／データ入出力部
１１２ サーバシステム向け通信部
２０ サーバ
２０−１ ０系サーバ
２０−２ １系サーバ
２０１ ディスプレイ
２０２ キーボード
２０３ マウス
２１１ 管理部
２１２ クライアントシステム向け通信部
２１３ ＮＥ向け通信部
２１４ 他系サーバ通信部
２１５ 通知情報管理部
２１６ ＮＥ制御部
２１７ ヘルスチェック管理部
２１８ サーバ運用系管理部
２１９ 構成情報データベース
２１９１ システムテーブル
２１９２ ＮＥ管理テーブル
２２０ 通知情報データベース
２２０１ アラーム管理テーブル
３０ ネットワークエレメント（ＮＥ）
３０１ ラインインタフェースユニット（ＬＩＵ）
３０２ 制御部
３０３ ファン（ＦＡＮ）
３１１ サーバシステム向け通信部
３１２ ハードウェア設定／制御部
３１３ Ｔｒａｐ情報生成処理部
３１４ ハードウェアシグナル受信部

Claims (12)

1. 複数のネットワークエレメント（ＮＥ）に対しヘルスチェックを実施することにより前記ＮＥの稼動状況を監視する第１及び第２のサーバを備え、
   前記第１のサーバは、監視対象のＮＥからのイベント情報の受信状況に応じて、前記ヘルスチェックの実施元を前記第２のサーバに変更する、ネットワークエレメント監視システム。
2. 前記第１のサーバは、前記イベント情報の受信数が一定時間に閾値を超えるバースト受信状況であると、当該イベント情報の送信元である第１のＮＥ以外の第２のＮＥに対する前記ヘルスチェックの実施要求を前記第２のサーバに送信する、請求項１に記載のネットワークエレメント監視システム。
3. 前記第１のサーバは、前記第２のＮＥによるイベント情報の送信先を前記第２のサーバに変更する、請求項２に記載のネットワークエレメント監視システム。
4. 前記第２のサーバは、前記第２のＮＥから受信したイベント情報を前記第１のサーバに通知する、請求項３に記載のネットワークエレメント監視システム。
5. 前記第１のサーバは、前記第１のＮＥから受信したイベント情報を前記第２のサーバに通知しない、請求項３に記載のネットワークエレメント監視システム。
6. 前記第１及び第２のサーバに通信可能に接続されたクライアント装置を備え、
   前記第１及び第２のサーバのいずれかが前記バースト受信状況を前記クライアント装置に通知する、請求項２〜５のいずれか１項に記載のネットワークエレメント監視システム。
7. 前記第１のサーバは、前記イベント情報の受信数が一定時間に閾値以下であるバースト回復状況になると、前記ヘルスチェックの実施元を前記第１のサーバに戻す、請求項２〜６のいずれか１項に記載のネットワークエレメント監視システム。
8. 前記第１及び第２のサーバに通信可能に接続されたクライアント装置を備え、
   前記第１及び第２のサーバのいずれかが前記バースト回復状況を前記クライアント装置に通知する、請求項７に記載のネットワークエレメント監視システム。
9. 前記第２のサーバが、監視対象のＮＥからのイベント情報の受信数が一定時間に閾値を超えるバースト受信状況であると、当該バースト受信状況を前記第１のサーバに送信し、前記イベント情報は前記第１のサーバに通知しない、請求項１に記載のネットワークエレメント監視システム。
10. 前記第１及び第２のサーバの双方が、監視対象のＮＥからのイベント情報の受信数が一定時間に閾値を超えるバースト受信状況であると、前記イベント情報の送信元である第１のＮＥ以外の第２のＮＥに対する前記ヘルスチェックの実施要求を第３のサーバに送信する、請求項１に記載のネットワークエレメント監視システム。
11. 複数のネットワークエレメント（ＮＥ）に対しヘルスチェックを実施することにより前記ＮＥの稼動状況を監視するサーバであって、
    監視対象のＮＥからのイベント情報の受信状況に応じて、前記ヘルスチェックの実施元を他のサーバに変更する、サーバ。
12. 複数のネットワークエレメント（ＮＥ）に対しヘルスチェックを実施することにより前記ＮＥの稼動状況を監視するサーバであって、
    他のサーバによる監視対象のＮＥに対するヘルスチェックの実施要求を前記他のサーバから受信すると、当該ＮＥに対するヘルスチェックを実施し、
    前記実施要求は、前記他のサーバによる監視対象のＮＥが送信したイベント情報の前記他のサーバにおける受信状況に応じて送信される、サーバ。

Images