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

Description

関連出願の説明

本願は２００７年２月１５日出願の米国仮特許出願第６０／８９０，１５５号明細書の利益を主張するものであって、その仮出願の内容はすべて参照により本明細書に援用する。

本開示はネットワーク管理に関し、特に分散型ネットワーク管理システムに関する。

ネットワーク管理は、ネットワークの故障を回避すると共にネットワークの性能を確保するために、異なるレベルで様々な種類のネットワークにおいて行われ得る。通信ネットワークでは、ネットワーク内のネットワーク要素を監視し管理するために要素管理システム（ＥＭＳ）が使用され得る。また、通信ネットワークは、いくつかのＥＭＳと通信することによってネットワーク全体を管理するネットワーク管理システム（ＮＭＳ）を含み得る。

波調分割多重化（ＷＤＭ）システム等の光通信システムでは、例えば、終端やケーブル局がケーブルセグメントによって相互接続されてネットワークが形成され得る。光通信システムのネットワーク要素は、ケーブル局に接続された装置（例えば、中継器及び等価器）と同様にケーブル局に配置される装置（例えば、終端装置及び電力供給装置）も含み得る。そのようなシステムでは、ＥＭＳはケーブル局に（又は別の場所に）配置され、このケーブル局に関連するネットワーク要素を管理するために使用され得る。ＥＭＳは要素管理機能を実行するための１つ又は複数のサーバー及びユーザーインターフェイスを提供するための１つ又は複数のワークステーションを含み得る（例えば、ＥＭＳによって管理されるネットワーク要素に関連する情報を表示する）。ＮＭＳは光通信システム全体、即ちネットワークを管理するためにケーブル局のいずれか又は別の場所に配置され得る。

ネットワークの管理には、構成管理、故障管理、性能管理等が含まれ得る。ＥＭＳでは、ＥＭＳが管理するネットワーク要素から転送されるアラーム、イベント、及びシステムメッセージを取得、記憶、及び／又は表示することによって故障管理を行うことができる。ＥＭＳでは、伝送品質データを取得、記憶、表示、及び／又は測定することによって性能管理を行うことができる。ＮＭＳでは、各ＥＭＳから転送されるアラーム、イベント、及びシステムメッセージの全てと伝送品質データとを管理することによってネットワーク全体を対象とした故障管理及び性能管理を行うことができる。ＮＭＳは、各ＥＭＳから受信した故障情報や性能情報を例えばネットワークの構成配置マップ上に表示することができる。

図１の例に示すように、ＮＭＳによって表示され得る情報の１つのタイプは、内在するＥＭＳによって管理されるネットワークアラームステータスである。ユーザー（例えば、ネットワーク管理者又はオペレーター）は表示された情報を監視して、ネットワークアラームがネットワーク停止の原因となり得るネットワーク内の故障を示しているか判別することができる。アラーム概要情報は、アラームのレベル（例えば、重大、軽微、なし、使用不可／報告なし）と、重大アラーム及び軽微アラームの発生数とを示すことが可能である。

図２に示すように、アラームステータス情報は各ＥＭＳサーバー２０とＮＭＳ ２２との間で階層的手法を用いて通信され得る。一実施形態によると、ＮＭＳにある１つ又は複数のコンピュータがＥＭＳサーバー２０から情報を受信する１つ又は複数のサーバー（例えば、単一のサーバー又は冗長なサーバー）として構成され得る。そして（例えば、図１に示すように）ＮＭＳはアラーム概要情報をネットワーク内のＥＭＳごとに表示することが可能である。

別の可能な実施形態によると、ＮＭＳ機能をＥＭＳサーバーに分散すること（即ち、各ＥＭＳに設置されたミニＮＭＳ機能）によって、ＮＭＳは物理的ＮＭＳサーバー又は層なくして形成できる。しかし、ＮＭＳ層を持たない分散されたＮＭＳを用いて、完全なネットワークのステータスの概要画面を提供することがなお望ましい。これを実現するため、各ＥＭＳは、最も高いレベルのアラームステータスを「マスター」サーバーに提示することによって単一の「マスター」サーバーと通信することができる。それに対して、「マスター」サーバーは各ＥＭＳサーバーに、ネットワーク中の全ＥＭＳサーバーに対するアラームステータスの統合された画面を提供することができる。そして、（例えば図１に示すように）ネットワーク内のＥＭＳ毎のアラーム概要情報はＥＭＳのワークステーション上に表示され得る。したがって、この分散されたＮＭＳ手法はまた、階層的手法を使用、即ちＮＭＳサーバーではなくマスターＥＭＳサーバーを使用することもできる。

階層的手法のシステム動作はＮＭＳサーバー又はマスターサーバーに大きく依存し、処理の負荷集中を招き、故障ポイントとなり得る。ＮＭＳサーバー又はマスターサーバーが故障すると、或いはネットワークファイバが切断されると、アラーム及びステータス共有機能も故障する恐れがある。また、分散されたＮＭＳシステムで利用可能な単純なＴＣＰ／ＩＰクライアントサーバーに基づく通信モデルでは不十分である可能性があり、処理および伝送のリソースを必要とすると考えられる。

本開示によるこれら及び他の特徴や利点は、図面を参照しながら以下の詳細な説明を読めば理解を深めることができよう。

ネットワーク管理システム（ＮＭＳ）のグラフィカルユーザーインターフェイス（ＧＵＩ）レポートを示す図である。 要素管理システム（ＥＭＳ）とＮＭＳとの間のデータ共有化のための階層的手法を示す概略図である。 本開示によるＥＭＳ−ＮＭＳを使用した分散型ネットワーク管理手法を示す概略図である。 ネットワークで故障が発生した場合の、本開示によるＥＭＳ−ＮＭＳ（上記にコメント）を使用した分散型ネットワーク管理手法を示す概略図である。 本開示による分散型ネットワーク管理システムの一部分の論理的な上位レベルのアーキテクチャの実施形態である。 本開示によるネットワーク管理システム機能の実施形態である。 本開示によるＮＭＳサーバーアプリケーションの状態遷移図の実施形態である。 本開示による別のＮＭＳサーバーのランタイムステータスのチェック方法を示すフローチャートである。 ＤＣＮの故障が発生し修理される場合の本開示によるＮＭＳサーバーのアクティブ化と非アクティブ化を示すタイミング／状態図である。 本開示による２つのアクティブなＮＭＳサーバーの間でランタイム優先度を決定する方法を示すフローチャートである。 本開示による光トランスポート層ネットワークを示す。 本開示による例示的な一ワークステーション機能のＧＵＩを表す図である。 本開示によるワークステーション機能のＧＵＩを表す図であり、ネットワーク要素のユニット画面の例を示す。

一般に、本開示による分散型ネットワーク管理システムはネットワーク内の各ハードウェアサーバーにＮＭＳ機能を含むことができる。各ハードウェアサーバーはまた、ＥＭＳ機能を含むこともできる。本明細書中で用いられるように、ＮＭＳ機能及びＥＭＳ機能を含むハードウェアサーバーはＥＭＳ−ＮＭＳサーバーと称される場合がある。全体的なネットワークドメインが機能している場合、ホストとしてドメインにＮＭＳ機能を提供する役割をサーバーの１つに割り当てて、そのサーバーと他のサーバーとでＥＭＳタイプの機能を実行するようにしてもよい。ホストサーバーが利用不可となった場合は、ネットワーク内の他のサーバーのいずれかをホストとしての役割を果たすよう割り当てることができる。また、例えばネットワークファイバの断線等のネットワーク故障の場合は、個々に作成されたネットワーク「アイランド」即ちドメインでＮＭＳ機能を果たすよう個々のホストサーバーを自動的に、つまりオペレーターの介在なく、割り当てることができる。一例では、元々のホストＮＭＳを第１のアイランドのホストとして割り当てて、新しいＮＭＳホストを第２のアイランドのホストとして割り当てることが可能である。ネットワーク故障が復旧されると、ドメイン即ち「アイランド」は自動的に、つまりオペレーターの介在なく、崩壊し、サーバーの１つ（例えば、元々のホストサーバー）にＮＭＳ機能が自動的に割り当てられ得る。

本明細書に説明する例示的な実施形態によれば、各ＥＭＳ−ＮＭＳサーバーはデータ通信ネットワーク（ＤＣＮ）を用いて、他の各ＥＭＳ−ＮＭＳサーバーとネットワーク情報を共有し得る。本明細書で使用するように、サーバーという用語は、ネットワークリソースを管理するソフトウェア及び／又はハードウェアのことをいい、単一のコンピュータ又は装置に限定されるものではない。一例では、ネットワークステータスデータは、ＥＭＳ−ＮＭＳによって管理されているネットワーク要素によってＥＭＳ−ＮＭＳに転送されたアラームを表すＥＭＳアラームステータスデータを含む。アラームステータスに加えて、ネットワークステータスデータは、回線監視装置の状態又は他のステータスデータ等、ＥＭＳ−ＮＭＳ間で共有される他のタイプの情報を含んでもよい。しかし、本開示は、アラームステータスデータ又はＥＭＳ−ＮＭＳステータスデータに限定されるものではない。本明細書で用いられるように、ネットワークステータスデータは、ネットワーク全体のステータス及び／又はそのネットワーク内の１つ又は複数の特定のネットワーク要素のステータスに関係する任意のタイプのデータを含んでいてもよい。共有化されたネットワークステータスデータの一部（例えば、アラーム概要情報）が、ユーザーインターフェイスを用いて、例えばホストＥＭＳ−ＮＭＳサーバーにログインしたクライアントワークステーション上のグラフィカルユーザーインターフェイス（ＧＵＩ）を用いて表示されるようにしてもよい。

図３を参照すると、ＥＭＳ−ＮＭＳサーバー３０−１〜３０−ｎが、ネットワークステータスデータをＥＭＳ−ＮＭＳサーバー３０−１〜３０−ｎ間で共有する。ネットワーク内のＥＭＳ−ＮＭＳサーバー３０−１〜３０−ｎのそれぞれは、ＥＭＳ−ＮＭＳサーバーの全てに関連するネットワークステータスデータを示すメッセージ又は通知を送信及び受信することができる。ＥＭＳ−ＮＭＳサーバーは、他の登録されたＥＭＳ−ＮＭＳサーバーにメッセージを、例えばＥＭＳ−ＮＭＳサーバーがメッセージを他のサーバーにブロードキャストするスター型／ブロードキャスト方法を用いて、又はＥＭＳ−ＮＭＳサーバー３０−１〜３０−ｎがメッセージを隣接するサーバーに送信する環状メッセージキュー（ＣＭＱ）方法を用いて送信することができる。ＥＭＳ−ＮＭＳサーバー３０−１〜３０−ｎの１つ又は複数が、例えば、サーバーの故障又はＤＣＮリンクの故障により、報告不可となっていないか又は利用不可となっていないかを判定するために、追加的なメッセージ及び／又は通知を送信するようにしてもよい。

ＥＮＳ−ＮＭＳサーバーのいずれか、例えばサーバー３０−１を、ＮＭＳ機能を実行するためのホストサーバーとして割り当てることができる。この割り当ては、個別に行うことも、クライアントサーバーでルックアップテーブルを使用する等して自動的に行うこともできる。ホストＥＮＳ−ＮＭＳサーバーが故障した場合、他のサーバー（例えば３０−２〜３０−ｎ）のいずれかが自動的にホストサーバーとして割り当てられることが可能である。

ネットワークが個々のドメイン即ちアイランドに分割された場合、個々のドメインのそれぞれに対してＥＭＳ−ＮＭＳサーバーをホストサーバーとして割り当てることができる。即ち、ドメインごとにホストサーバーを１つずつ割り当てられた複数のホストサーバーができる。図４に示すように、ＤＣＮファイバの断線等のネットワーク故障により、ネットワークが別々のドメイン４０２、４０４に分断される場合がある。別々のドメイン４０２、４０４に分離され、即ち、互いに通信できなくなると考えられる。例えば、例示した実施形態では、サーバー２０−１と２０−８〜２０−ｎが第１のドメイン４０２に分割され、サーバー２０−２〜２０−７が第２のドメイン４０４に分割され得る。ネットワーク故障の結果として、ドメイン、例えば第１のドメイン４０２内のＥＭＳ−ＮＭＳサーバーはもう一方のドメイン、例えば第２のドメイン４０４内のサーバーと通信できなくなると考えられるが、各ドメイン内のサーバー間の通信は存続可能である。

本開示によるシステムでは、個々のドメインが作成されると、例えばクライアントサーバーでルックアップテーブルを使用するか、又はローカルホストサーバーのルールに従い、各ドメインに対してホストサーバーを自動的に割り当てることが可能である。例えば、サーバー２０−２がドメイン４０４のホストＥＭＳ−ＮＭＳサーバーとして割り当てられ、サーバー２０−１がドメイン４０２のホストサーバーとして割り当てられ得る。ネットワーク故障が復旧され、ネットワークドメイン即ち「アイランド」が崩壊すると、個々のアイランドのホストサーバーは、修復されたネットワークに対し、自動的に割り当てられるホストサーバー、例えばサーバー２０−１にホストサーバーステータスを与えることができる。

図５は、本開示による分散型ネットワーク管理システムの一部分における論理的な上位レベルのアーキテクチャ５００の実施形態を示す。論理アーキテクチャ５００は１つ又は複数の要素管理システム機能（ＥＭＳ）、例えばＥＭＳ ５０−１、ＥＭＳ ５０−２を備えることができる。各ＥＭＳ機能はＥＭＳ−ＮＭＳハードウェアサーバーに常駐することができる。ＥＭＳの機能にはトランスポートネットワーク５８のコンポーネントの管理を含めることができる。トランスポートネットワークのコンポーネントには、回線終端装置、電力供給装置、ケーブル（例えば、海底ケーブル）及び／又はその他の装置が含まれ得る。

ＥＭＳの機能は、更に、ネットワーク管理システム（ＮＭＳ）機能、例えばＮＭＳ ５４との通信も含むことができる。ＮＭＳ機能はＥＭＳ−ＮＭＳハードウェアサーバーに常駐することができる。ＮＭＳ ５４はノースバウンドインターフェイス（例えばＮＢＩ ５２−１、ＮＢＩ ５２−２）を介して、内在するＥＭＳ（例えばＥＭＳ ５０−１、ＥＭＳ ５０−２）と通信することができる。一実施形態では、ノースバウンドインターフェイスはＣＯＲＢＡ（共通オブジェクト・リクエスト・ブローカー・アーキテクチャ）ノースバウンドインターフェイスとすることができる。ＣＯＲＢＡノースバウンドインターフェイスは、分散型アプリケーションの間で、即ち様々なコンピュータ上で動作し同一のオペレーティングシステムを共有できないアプリケーションの間で通信を提供することができる。更に、様々なプログラム言語を使用して、アプリケーションを実装することができる。別の実施形態では、ノースバウンドインターフェイスをＳＮＭＰ（簡易ネットワーク管理プロトコル）インターフェイスとすることができる。別の実施形態では、ノースバウンドインターフェイスをＴＬ１（Ｔｒａｎｓａｃｔｉｏｎ Ｌａｎｇｕａｇｅ １）インターフェイスとすることができる。

ＮＭＳ ５４は更にクライアントワークステーション機能（ＷＳＦ）、例えばＷＳＦ ５６−１、ＷＳＦ ５６−２と通信することができる。ＷＳＦはワークステーションに常駐することができる。ワークステーションは、ＥＭＳ−ＮＭＳハードウェアサーバーと一緒に、例えばケーブル局に配置されてもよい。更に／或いは、ワークステーションは、例えばＮＯＣ（Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｉｏｎｓ Ｃｅｎｔｅｒ）等の顧客施設でのスタンドアローンであってもよい。ＷＳＦはグラフィカルユーザーインターフェイス（ＧＵＩ）を含んでもよい。ＷＳＦ ＧＵＩを介してユーザーに分散型ネットワークのステータスを表示することができる。ＷＳＦ ＧＵＩを介してユーザーにネットワーク管理情報を表示することができる。ユーザーはＷＳＦ ＧＵＩを使用して、例えばステータスを要求すること及び／又はネットワークの再検出を促すことができる。

上記で述べたように、ＮＭＳ機能（例えば、ＮＭＳ ５４）、ＥＭＳ機能（例えば、ＥＭＳ ５０−１）、及びＮＢＩ（例えば、ＮＢＩ ５２−１）は、１つのハードウェアサーバー（ＥＭＳ−ＮＭＳサーバー）に共存してもよい。ＷＳＦ（例えば、ＷＳＦ ５６−１）は、ＥＭＳ−ＮＭＳサーバーと一緒に配置されるワークステーションに常駐してもよい。一部の実施形態では、ネットワークドメインごとにたった１つのＮＭＳ機能が、特定の時点においてそのドメインをアクティブに管理することができる。このため、ＮＭＳ機能は、たった１つのＮＭＳ機能で、確実にドメインをアクティブに管理できる機能を含んでもよい。ＮＭＳ機能は、更に、アイランドの原因となるネットワーク故障、及び／又はハードウェアサーバー故障、及び／又はネットワークをアクティブに管理しているＮＭＳ機能の障害が発生した場合には、別のＮＭＳ機能をアクティブにする機能を含んでもよい。ＮＭＳ機能は、アイランドの原因となるネットワーク故障が修復した時には追加のＮＭＳ機能の非アクティブ化をサポートする機能を含んでもよい。

図６は、本開示によるＮＭＳ機能６００の実施形態を示す。ＮＭＳ機能６００は１つまたは複数のモジュールを含むことができる。各モジュールは、独立したランタイムプロセスにすることができ、１つ又は複数のアプリケーションコンポーネントを含むことが可能である。各アプリケーションコンポーネントは、特定の管理機能（例えば、特化したＣＯＲＢＡサーバントを実現する等）を実行するように特化することができる。本明細書で用いるように、ＣＯＲＢＡサーバントは、ＣＯＲＢＡオブジェクトの機能を実現するために使用するプログラム言語内のデータ構造又はオブジェクトを含んでもよい。

ＮＭＳ機能６００は、ＯＳＦ（運用サポート機能）モジュール６１０と、ＮＢＩ（ノースバウンドインターフェイス）モジュール６２０と、関係マネージャモジュール６３０と、ＣＯＲＢＡネームサービス６４０と、ＣＯＲＢＡイベントサービス６５０とを含むことができる。各モジュール６１０、６２０、６３０はそれぞれ、関連するアプリケーションマネージャコンポーネント６１２、６２２、６３２を備えることが可能である。ＯＳＦモジュール６１０は更に、トポロジーマネージャコンポーネント６１４、パフォーマンスマネージャコンポーネント６１６、及び故障マネージャコンポーネント６１８を含むことができる。ＮＢＩモジュール６２０は、更にプロトコルコンポーネント６２４を含むことができる。関係マネージャモジュール６３０は、更に関係マネージャコンポーネント６３４を含むことができる。各モジュール６１０、６２０、６３０は、ＣＯＲＢＡサーバントのオブジェクトリファレンスをＣＯＲＢＡネームサービス６４０に発行し、ＣＯＲＢＡイベントサービス６５０を介して自律通知メッセージを送信及び／又は受信することができる。モジュールのライフサイクルは、そのモジュールの関連するアプリケーションマネージャコンポーネントによって制御し、それ以外のコンポーネントは、それに応じてアクティブ化及び／又は非アクティブ化することができる。

ＯＳＦモジュール６１０はＮＭＳ機能６００の他のどのモジュールからも独立して実行することができる。ＯＳＦモジュールのアプリケーションマネージャコンポーネント６１２で、ＮＭＳ機能６００のランタイム動作を制御することができる。例えば、ＯＳＦモジュールのアプリケーションマネージャコンポーネント６１２では、クライアントがアクティブにサポートされるかどうかを判別することができる。

図７は、本開示によるＯＳＦモジュールのアプリケーションマネージャコンポーネント（「サーバーアプリケーション」）の状態遷移図７００の実施形態を示す。状態遷移図７００は、状態及び状態の遷移を含む。状態には、サーバーアプリケーションが実行する１つ又は複数のタスクが含まれる。状態は、更にサーバーアプリケーションがその状態においてサポートできるサービスを特定することができる。例えば、サービスは、ユーザーにより（例えば、ＷＳＦ ＧＵＩを介して）要求されたときのランタイムのステータスチェックを含むことができる。状態遷移は、アプリケーションマネージャコンポーネントの実行、セルフ健全性チェックの動作、及び／又はユーザーが発行した要求で到達するマイルストーンによって支配することができる。状態遷移は状態間及び／又は状態内であってよく、自律メッセージを介してクライアントアプリケーションに通知することができる。

起動７１０時、サーバーアプリケーションはまず初期化に必要とするローカルリソースの利用可能性をチェックすることができる。サーバーアプリケーションはまた、提供する機能に対するランタイムサポートの利用可能性もチェックすることができる。言い換えれば、サーバーアプリケーションは、ランタイム環境が適切に構成されていること、及びサーバーセッションを初期化するためのリソースが利用可能であることを検証することができる。例えば、サーバーアプリケーションはアプリケーション構成ファイル、サーバー構成、及び／又はシステムリソースの利用可能性を検証することができる。ローカルリソース及び／又はランタイムサポートが利用可能であれば、サーバーアプリケーションは初期化状態７２０に遷移することができる。或いは、サーバーアプリケーションは該当するメッセージ（例えば、初期化故障）を記録し、シャットダウン状態７８０に遷移するようにしてもよい。

初期化状態７２０では、サーバーアプリケーションは、ランタイムでのサーバーアプリケーションの動作を定義し、サーバーアプリケーションが従うステップを支配するランタイム構成ファイルを処理する。一実施形態では、サーバーアプリケーションがケーブルシステムのトポロジーの検出を実行するのか、それとも予め作成されたネットワークのトポロジー構成ファイルを処理するのかを、ランタイム構成ファイルによって決定する。サーバーアプリケーションでは更に、トポロジー検出を実行した後、トポロジー構成ファイル（存在する場合）を自動的に上書きするかどうかも決定する。別の実施形態では、ランタイム構成ファイルは、サーバーアプリケーションが他のサーバーアプリケーションのインスタンスと共存するかどうか、及びサーバーアプリケーションのインスタンスをアクティブ化する優先順位の状態を決定してもよい。別の実施形態では、ランタイム構成ファイルは、サーバーアプリケーションの競合を検出する間隔を含むと共に、他のサーバーホスト（即ち、ＥＭＳ−ＮＭＳハードウェアサーバー又はＥＭＳ若しくはＮＭＳソフトウェアサーバー）が利用可能であるかどうかを示すようにしてもよい。

初期化状態７２０で、サーバーアプリケーションは、クライアントユーザーからのそのランタイムステータスに関する要求に応えることができる。サーバーアプリケーションはスタンバイ状態７７０から初期化状態７２０へ、例えばユーザーの要求（ユーザーが発行したアクティブ化要求等）に応答して遷移する。サーバーアプリケーションはまた、起動状態７１０から初期化状態７２０に遷移することもできる（即ち、初期化及び／又はランタイムサポートにリソースが利用可能となる）。

サーバーアプリケーションは初期化状態７２０で１つ又は複数のタスクを実行する。このタスクには、例えばＣＯＲＢＡネームサービス（ＣＯＲＢＡネームサービス６４０等）を使用して、サーバーアプリケーションサーバントを作成して登録することを含めることができる。このタスクには更に、例えばＣＯＲＢＡイベントサービス（ＣＯＲＢＡイベントサービス６５０等）を使用して、自律メッセージ用のチャネルを作成することを含めることができる。一実施形態では、当該タスクには、アクティブである可能性がある他のサーバーアプリケーション（即ち、他のＮＭＳ機能）との競合を検出して防止することを含めることができる。タスクには更に、ユーザーによって定義されたアプリケーション構成の同期化を保証することを含めることができる。タスクには更に、適切なトポロジーアップロードオプションを検出及びトリガすることを含めることができる。

例えば、サーバー競合の検出では、サーバー競合が検出されない場合もあれば、サーバー競合が検出される場合もある。サーバー競合が検出されない場合、サーバーアプリケーションは次の適切な状態に遷移する。次の適切な状態は、サーバーアプリケーションのランタイム構成ファイルに従って決定することが可能である。例えば、サーバーアプリケーションは構成ファイルのアップロード状態７３０又はトポロジーの検出状態７４０に遷移する。

サーバー競合が検出され、競合しているサーバーと接続できない場合、サーバーアプリケーションは次の適切な状態に遷移できる。次の適切な状態は、サーバーアプリケーションのランタイム構成ファイルに従って決定することが可能である。例えば、サーバーアプリケーションは構成ファイルのアップロード状態７３０又はトポロジー検出状態７４０に遷移する。例えば、サーバーアプリケーションのローカルでＤＣＮ故障が発生した場合は、サーバーアプリケーションを切り離すことが可能である。この場合、サーバーアプリケーションは、競合の可能性がある別のＮＭＳインスタンスと接続できなくしてよい。ＤＣＮ故障を修復すると、この状況が復旧する。

競合が検出されたが、競合しているサーバーと接続できる場合は、以下のシナリオを発生させることができる。競合しているサーバーをアクティブ化する優先度が、初期化しているサーバーアプリケーションインスタンスの場合よりも高いならば、サーバーアプリケーションは対応するメッセージを記録してスタンバイ状態７７０に遷移する。競合しているサーバーをアクティブ化する優先度が、初期化しているサーバーアプリケーションインスタンスの場合よりも低いならば、サーバーアプリケーションはそのランタイム構成ファイルに従って次の適切な状態に遷移する。競合しているサーバーをアクティブ化する優先度が初期化しているサーバーアプリケーションインスタントと同じである場合、初期化しているサーバーアプリケーションをアクティブ化する優先度が競合しているサーバーのアクティブ化優先度より高ければ、サーバーアプリケーションはそのランタイム構成ファイルに従って次の適切な状態に遷移する。それ以外であれば、サーバーアプリケーションは該当するメッセージを記録し、スタンバイ状態７７０に遷移する。アクティブ化の優先度は、以下に詳細に説明するランタイムステータスチェック及び競合検出プロトコルに基づくものとすることができる。

サーバーアプリケーションは次のように初期化状態７２０から遷移する。サーバーアプリケーションは、初期化が完了すると、そのランタイム構成ファイルに応じて、構成ファイルのアップロード状態７３０及び／又はトポロジー検出状態７４０に遷移する。サーバーアプリケーションは、サーバーの競合検出の結果として、及び／又はクライアントが発行したスタンバイ要求に応答して、スタンバイ状態７７０に遷移する。サーバーアプリケーションは、シャットダウン要求に応答してシャットダウン７８０に遷移する。この状態中に処理され得るユーザー要求には、ランタイムステータスチェック、サーバースタンバイ、及び／又はサーバーシャットダウンが含まれる。

スタンバイ状態７７０において、サーバーアプリケーションはネットワークをアクティブに監視しなくてもよい。アクティブ化要求が受信されると、サーバーアプリケーションは初期化状態７２０に遷移し、そのランタイム構成に応じて処理を続行することができる。サーバーアプリケーションは、クライアントが開始した要求に応答してスタンバイ状態７７０に遷移する。例えば、システムの保守が実行される場合、ユーザーはＷＳＦ ＧＵＩを使用してスタンバイ要求を発行することができる。

サーバーアプリケーションは、サーバーの競合を検出した結果としてスタンバイ状態７７０に遷移する場合がある。例えば、単一のサーバー環境ではサーバー競合は初期化状態７２０の期間、及び／又はネットワーク管理がアクティブな期間（即ち、実行状態７６０）に検出され得る。更に、サーバーアプリケーションはＮＭＳインスタンス統合プロトコル（以下に詳細を説明）に従ってスタンバイ状態７７０へ自主的に遷移する。

サーバーアプリケーションは、クライアントが発行したアクティブ化要求に呼応してスタンバイ状態７７０から初期化状態７２０へ、及び／又は、シャットダウン要求に呼応してスタンバイ状態７７０からシャットダウン状態７８０に遷移する。スタンバイ状態７７０中に処理され得るユーザー要求には、ランタイムステータスチェック、サーバーのアクティブ化、サーバースタンバイ、及びサーバーのシャットダウンが含まれる。

構成ファイルのアップロード状態７３０で、サーバーアプリケーションは既存のトポロジーの構成ファイルの処理を試み、その内容に基づいてネットワークで管理されるエンティティを作成する。内在するＥＭＳシステムと接続するだけで、ネットワーク構成エンティティのランタイムステータスを更新することができる。サーバーアプリケーションは、構成ファイルのアップロード状態７３０中に１つ又は複数のタスクを実行する。これらのタスクとしては、管理対象要素の作成、トポロジー関連のイベントチャネルの作成、及び／又は、管理対象情報の更新などがある。これらのタスクの実行中に発生し得る異常及び／又は例外を、記録することが可能である。

サーバーアプリケーションは、トポロジーのアップロードが正常に完了すると、構成ファイルのアップロード状態７３０からアラームの同期化状態７５０に遷移する。トポロジー構成をアップロードできない場合、サーバーアプリケーションはトポロジーを検出する状態７４０に遷移する。

サーバーアプリケーションは、構成ファイルのアップロード状態７３０から、クライアントが発行したスタンバイ要求に呼応してスタンバイ状態７７０に、及び／又は、シャットダウン要求に呼応してシャットダウン状態７８０に遷移する。構成ファイルのアップロード状態７３０になっている間に処理されるユーザー要求には、ランタイムステータスチェック、サーバースタンバイ、及びサーバーのシャットダウンが含まれる。

トポロジー検出状態７４０で、サーバーアプリケーションはネットワークトポロジーの検出及び／又はネットワークで管理されるエンティティの作成を実行する。サーバーアプリケーションは、トポロジー及び最新の構成情報を提供するのに、内在するＮＢＩシステムに依存する。サーバーアプリケーションは、トポロジーの検出状態７４０の間に、１つ又は複数のタスクを実行する。このタスクとしては、ＮＢＩケーブルシステムのネーミングサービス（例えば、ＣＯＲＢＡネーミングサービス６４０）との接続、システムトポロジーの検出、管理される要素の作成、管理される情報の更新、トポロジー関連のイベントチャネルの作成、ランタイム構成ファイルに従ったトポロジー構成ファイルの生成、及びランタイム構成ファイルに従った、サーバーアプリケーション用のトレールトレースの生成を挙げることができる。異常及び例外が発生した場合はクライアントに通知し、専用のファイルに記録する。正常に作成されたネットワークエンティティだけを管理するようにしてもよい。

サーバーアプリケーションは、クライアントが開始した要求（例えば、ＷＳＦクライアントが発行したトポロジーの検出要求）に応答してトポロジーの検出状態７４０に遷移する。サーバーアプリケーションは、サーバーの起動時にサーバーの競合が検出されない場合は、トポロジーの検出状態７４０に遷移する。トポロジー情報のアップロードが不成功の場合は、サーバーアプリケーションは構成ファイルのアップロード状態７３０からトポロジーの検出状態７４０に遷移する。

サーバーアプリケーションは、トポロジーの検出が正常に完了すると、トポロジーの検出状態７４０からアラームの同期化状態７５０に遷移する。サーバーアプリケーションはトポロジーの検出状態７４０から、クライアントが発行したスタンバイ要求に呼応してスタンバイ状態７７０に、及び／又はシャットダウン要求に呼応してシャットダウン状態７８０に遷移する。トポロジーの検出状態７４０の間に処理され得るユーザー要求には、ランタイムステータスチェック、サーバースタンバイ、及びサーバーのシャットダウンが含まれる。

アラームの同期化状態７５０では、サーバーアプリケーションは、ネットワークトポロジーを検出及びアップロードする。次に、サーバーアプリケーションは、アクティブアラームリストの内容をクリアする。サーバーアプリケーションは、ＮＢＩインターフェイス（例えば、ＮＢＩ ５２−１、５２−２）を介して内在するＥＭＳシステムと故障情報を再度同期化する。サーバーアプリケーションは、アラームの同期化状態７５０の間に１つ又は複数のタスクを実行する。これらのタスクとしては、現行のアラームリストのクリーンアップ、ＥＭＳが作成したイベントチャネルへの接続、アラームと内在するＥＭＳとの同期化、及びクライアント（例えばＷＳＦ ５６−１、５６−２）への非応答性のＥＭＳ ＮＢＩ及びイベントチャネルの通知を挙げることができる。

サーバーアプリケーションは、アラームの同期化が正常に完了すると、アラームの同期化状態７５０から実行状態７６０に遷移する。サーバーアプリケーションは、アラームの同期化状態７５０から、クライアントが発行したスタンバイ要求に呼応してスタンバイ状態７７０へ、及び／又は、シャットダウン要求に呼応してシャットダウン状態７８０に遷移する。アラームの同期化状態７５０の間に処理され得るユーザー要求には、ランタイムステータスチェック、サーバースタンバイ、及びサーバーのシャットダウンが含まれ得る。

実行状態７６０では、サービスアプリケーションは、クライアント要求の処理を有効にし、内在するＥＭＳシステムから受信した着信通知を処理する。着信通知として、アラームセット及びアラームクリアを挙げることができる。サーバーアプリケーションは、実行状態７６０の間に１つ又は複数のタスクを実行する。これらのタスクとしては、自律メッセージの待機及び／又は処理、イベントチャネル接続の管理、クライアント要求の処理、及びクライアントへのハートビート通知の送信を挙げることができる。

ハートビート通知は、サーバー（例えば、サーバーアプリケーション）とクライアント（例えば、ＷＳＦ）との間の周期的な信号であり、サーバーが実行していることを示す。サーバーアプリケーションは、ハートビート通知を送信する前にランタイム進捗ステータスをリセットする。クライアントはハートビート通知を受信すると、サーバーアプリケーションのランタイムステータスに対する要求を発行する。サーバーアプリケーションはランタイムステータス要求を受信するたびにアクティブなクライアント番号をインクリメントしてランタイム進捗ステータスを更新する。

サーバーアプリケーションはクライアントが発行した要求に応答して、実行状態７６０からトポロジーの検出状態７４０に遷移する。サーバーアプリケーションはクライアントが発行した要求に応答して、実行状態７６０からアラーム同期化状態７５０に遷移する。サーバーアプリケーションはクライアントが発行したスタンバイ要求に応答して、及び／又はサーバーの競合検出の結果として、実行状態７６０からスタンバイ状態７７０に遷移する。サーバーアプリケーションはシャットダウン要求に応答して、及び／又はサーバーの競合検出の結果として、実行状態７６０からシャットダウン状態７８０に遷移する。実行状態７６０の間に処理され得るユーザー要求にはランタイムステータスチェック、サーバースタンバイ、及びサーバーシャットダウンが含まれる。

サーバーアプリケーションは実行状態７６０から遷移する場合、スケジュールされている周期的な実行状態関連タスクをいずれも停止し、許可済みの未処理リソースのロックをいずれも無条件で解除する。

シャットダウン状態７８０では、サーバーアプリケーションはランタイムステータス以外のクライアント要求を処理できなくなる。サーバーシャットダウン手順は一旦開始されると中断することができず、着信通知は破棄される。サーバーアプリケーションはシャットダウンされると、ＥＭＳイベントチャンネルから切断し、ネーミングサービスから登録を解除し、クライアントに通知を送信し、ログファイルを閉じ、及び／又は使用していたサーバーホストシステムのリソースを解放する。

動作中、分散型ネットワーク管理システムは以下のように機能する。起動時にクライアントユーザー（例えば、ＷＳＦ ５６−１）は既存のアクティブなＮＭＳインスタンスに接続を試みることができる。既存のアクティブなＮＭＳインスタンスが見つからなかった場合、クライアントは起動要求を送信して、ＮＭＳインスタンスをアクティブにすることができる。

前述したように、ケーブルシステム内のどのケーブル局でもＥＭＳ−ＮＭＳハードウェアサーバーにＮＭＳ機能をインストールして構成することが可能である。ケーブル局の特定のＥＭＳ−ＮＭＳハードウェアサーバーを選択して、ＮＭＳサーバーのホストとして動作しないようにしてもよい。通常の条件下では、ユーザーが全てのＮＭＳインスタンスを手動でシャットダウン又はスタンバイに設定しない限り、ネットワークでは少なくとも１つのＮＭＳインスタンスがアクティブになる。

所定のネットワークのサーバースイートは、単一又は複数のＮＭＳインスタンスをサポートするように構成することができる。サーバーアプリケーションについては、複数のインスタンスに対して構成された場合、競合を検出するプロトコルの実行を無効にする。単一のインスタンスモードを構成する場合は、競合を検出するプロトコルを実行してネットワーク内でアクティブなＮＭＳインスタンスを１つだけ設定する。このプロトコルは、サーバーのランタイムステータスチェック動作を基礎とすることができる。

ランタイムステータスチェックにより、ＮＭＳ及びＷＳＦインスタンスは、別のＮＭＳインスタンスのランタイムステータスを要求する。ＮＭＳ及びＷＳＦインスタンスは、受信した結果に基づいて、そのＮＭＳインスタンスとの関係を決定する。ＷＳＦクライアントは、例えば、異なるＮＭＳインスタンスを検索するかどうかを決定することができる。ＮＭＳインスタンスは応答を使用して、起動時及びＤＣＮ通信破壊復旧時におけるインスタンスアクティブ化競合を解決するようにしてもよい。

ランタイムステータスには、サーバーアプリケーションのランタイム状態、進捗ステータス、及びアクティブ化の優先度という３つのコンポーネントを含む。サーバーアプリケーションのランタイム状態は、インスタンスが現在実行しているライフサイクル（例えば、図７に示すような）の状態に応答する。ライフサイクル状態は、優先度を含むことができる。例えば、優先度（最高位から最低位へ）は、実行、アラームの同期化、トポロジーの検出、構成ファイルのアップロード、初期化、スタンバイ、及びシャットダウンとすることができる。ＷＳＦはサーバーアプリケーションのランタイム状態を使用することにより、ＮＭＳインスタンスが要求を処理する準備ができているかどうか確認することができる。ＷＳＦはまた、アプリケーションランタイム状態を使用してサーバーアプリケーションのランタイム動作を制御する方法を決定することができる。これにより、ＷＳＦは該当するＮＭＳインスタンス又は別のＮＭＳインスタンスからサービスを確実に提供される。

サーバーアプリケーションの進捗ステータスは、初期化状態又は実行状態のいずれかで実行されている間のサーバーアプリケーションの相対的な進捗であってもよい。競合の解決は、初期化状態及び実行状態で解決してもよい。例えば、初期化の間に、進捗ステータスでは、どれだけの数の潜在的なＮＭＳサーバーとの接続が行われたかを示す。ドメイン当たりアクティブなサーバーを１つだけにするようにシステムが構成されている場合、この情報を使用してサーバーの複数のインスタンスを検出して阻止することができる。実行状態の間、進捗ステータスは、ＮＭＳインスタンスによってサポートされるように登録されているＷＳＦインスタンスの数を示す。初期化状態及び実行状態中に競合解決のプロトコルを実行することができるので、進捗ステータスが他のランタイム状態と一緒にレポートされた場合には、進捗ステータスは意味がないかもしれない。

サーバーアプリケーションのアクティブ化の優先度は、システム構成に基づいて決定可能な優先度を表す指標とすることができる。複数のＮＭＳインスタンスが許可されていない場合、アクティブ化の優先度を使用して優先されるＥＭＳ−ＮＭＳハードウェアサーバーを特定して、ネットワークを監視するアクティブなＮＭＳのホストとすることができる。アクティブ化優先度の定義は、ネットワークトポロジーとリソースの利用可能性とに依存する。

サーバーアプリケーションのランタイム進捗ステータス及びアクティブ化の優先度は、競合検出のプロトコルをサポートすることができる。サーバーアプリケーションのランタイム進捗ステータス及びアクティブ化の優先度によって、一つのＮＭＳインスタンスがそのランタイム状態を他のＮＭＳインスタンスのランタイム状態と比較できるようにする。一実施形態では、ランタイム競合のチェック時に適用されるこれらの属性の相対的な優先度は構成可能とすることができる。例えば、ランタイム進捗度がアクティブ化の優先度より優先されるように設定された場合、初期化プロセスでより先に進められているＮＭＳインスタンス、及び／又はより多くのクライアントにサービスを提供するＮＭＳインスタンスが優先的にアクティブのままとされる。この構成では、ＮＭＳインスタンスの非アクティブ化（即ち、ＮＭＳインスタンスのシャットダウン又はスタンバイモードへの移行）に影響され得るクライアントに関連するオーバーヘッドを最小限に抑えることができる。アクティブ化の優先度がランタイム進捗度より優先されるように設定された場合、より高いアクティブ化の優先度を持つＮＭＳインスタンスが優先的にアクティブのままとされるか、又はアクティブになる。優先度が低いＮＭＳインスタンスは、自主的な非アクティブ化に移行することができる。

他の要求と同様、ランタイムステータスチェックはサーバーに要求者の識別情報を提供することができる。要求者の識別情報はインスタンスのタイプ（ＮＭＳか、又はＷＳＦか）及びホストを含むため、サーバーは要求者を識別できる。この情報は、ＤＣＮ破壊後に競合を検出した際に有用になる。

サーバーランタイム構成ファイルでは、ネットワーク内で複数のＮＭＳインスタンスが同時にアクティブになるかどうかを決定する。複数のＮＭＳインスタンスを強制的に設定するのでなく、そのように構成されれば、このメカニズムを使用して１つのＮＭＳインスタンスだけが確実にアクティブになるようにする。複数のＮＭＳインスタンスを許容するかどうかは、システム構成で決定することができる。複数のＮＭＳインスタンスを許容すると、ＮＭＳの可用性は高まるもののランタイムオーバーヘッドが大きくなる可能性がある。相対的な費用対効果は、システムに依存すると考えられる。

サーバーが起動すると、ＮＭＳインスタンスはネットワークの管理を試み、初期化状態への移行を試みる。複数のインスタンスが許容されると、ＮＭＳインスタンスはアプリケーションライフサイクル（例えば、図７に示すような）の中を、実行状態に到達するまで競合をチェックすることなしに進む。アクティブなＮＭＳインスタンスが１つだけ選択されている場合は、以下のセクションで説明するように、サーバー競合検出プロトコルを実行する。

初期化状態及び／又は実行状態の間で競合の検出が発生することがある。競合している可能性があるＮＭＳインスタンスは、サーバーのランタイム構成ファイルで指示される。初期化状態では、アクティブなＮＭＳインスタンスを検出するために、各ＮＭＳがローカルサーバーを初めとして、ランタイム構成ファイル内で識別されている潜在的な各サーバーホストと接続する。ローカルネーミングサービスで、ＮＭＳインスタンスは自身を公開し、クライアントから（例えば、ＷＳＦインスタンスによって）アクセスできるようにする。

例えば、図８を参照すると、単一のＮＭＳインスタンスモードが選択されている場合、初期化しているサーバーはリモートサーバーと接続してそのランタイムステータスの問い合わせ（８１０）を行う。リモートサーバーは応答する（８２０）。初期化しているサーバーは応答と自身のランタイムステータスとを比較して（８３０）、初期化プロセスを継続する（８５０）か、スタンバイ状態へ遷移する（８６０）かを、決定する。リモートＮＭＳインスタンスのランタイムステータスがローカルサーバーのランタイムステータスより優先度が高い場合、ローカルサーバーは初期化を中止してスタンバイ状態へ遷移する（８６０）。それ以外の場合、ローカルサーバーは初期化を継続してアクティブなＮＭＳインスタンスになる（８５０）。サーバーランタイム構成ファイル内にＮＭＳサーバーのリストと一緒に定義されたサーバー競合検出メカニズムは、サーバーの導入に柔軟性を持たせることができる。例えば、一連の好適なサーバーホストを定義することができる。好適なサーバーホストは、ネットワークトポロジーと、リソースの利用可能性と、ランタイムワークロードの解析及び推定に基づいて選択することができる。

運用中に、例えばケーブル障害が原因で、ＤＣＮ（データ通信ネットワーク）が破壊される場合がある。ＤＣＮが破壊されると、ＥＭＳ及び／又はＷＳＦクライアントの１つ又は複数の別個のドメインが形成される。ドメイン内の通信は存在するが、ドメイン間の通信は失われると考えられる。破壊される前に、アイランド形成の原因となる故障が存在せず、且つ、単一サーバー構成であると仮定すると、１つのサーバーでネットワークをアクティブに管理することができる。ＤＣＮが破壊されると、ネットワークは分割され、アクティブサーバーから分離されたＷＳＦインスタンスは１つ又は複数のＮＭＳインスタンスを追加的にアクティブ化できるようになる。それに応じて、複数のＮＭＳインスタンスが同時にアクティブになることができる。ドメイン当たり１つのサーバーしかアクティブになっていない場合、複数のＮＭＳインスタンスが競合することはない。ＤＣＮが復旧すると、複数のＮＭＳインスタンスが競合する可能性がある（即ち、１つのドメイン内に複数のアクティブサーバーが存在する状態になる）。一実施形態では、アクティブＮＭＳインスタンスは、このような競合を解決して、ドメイン当たり１つのアクティブサーバーへの統合を行うことができる。

競合の解決と統合は以下のように達成することができる。各アクティブサーバーのランタイム構成ファイルは、潜在的なＮＭＳサーバーのリストを含むようにしてもよい。アクティブな（即ち、実行状態にある）各ＮＭＳサーバーは、他の潜在的なＮＭＳサーバーのそれぞれについてランタイムステータスを定期的にチェックし、それに応じて、スタンバイ状態に移行するかどうかを決定する。各ＮＭＳインスタンスはネットワーク内の全てのＮＭＳサーバーのランタイムステータスをキャッシュする。この情報はＮＭＳサーバーが最初に起動されたときに、初期化プロセスの一環として初めに取得可能である。

図９は２つのＮＭＳサーバー（サーバーＡとサーバーＢ）の状態と、他方のサーバー（サーバーＢとサーバーＡのそれぞれの）のキャッシュ状態を表す例示的なタイミング図９００を示すものである。２つのＮＭＳサーバーの状態及びこの２つのサーバーのキャッシュの内容は時間の経過に伴って及び特定のイベント（例えば、ＤＣＮアイランドの形成をもたらす故障の発生及び／又は解決）に応答して変化する。タイミング図９００に示した時間間隔は、任意であり例示するためのものである。図９００は、わかりやすくするために、ＮＭＳサーバーを２つだけしか含まない。記載した機能は、いくつのＮＭＳサーバーにでも適用可能にすることができる。

例えば、ケーブルシステムの起動時に、アクティブなサーバーは最終的に他の全てのＮＭＳインスタンスにランタイムステータスを要求する。すでに実行されており正常に接続されたＮＭＳインスタンスは、初期化、スタンバイ、又はシャットダウン状態になる。アクティブサーバーでは、接続に失敗したＮＭＳインスタンスのランタイム状態を不明状態に設定する。受信したランタイムステータス要求ごとに、要求を受信するサーバーは要求側サーバーのキャッシュされたランタイムステータスを更新し、不明に設定する。

図９を参照すると、時間ｔ＝０−では、サーバーＡは実行状態９１０になり、サーバーＢはスタンバイ状態９１５になる。サーバーＡとＢは同じドメイン内に存在する（即ち、サーバーＡとサーバーＢとの間にアイランドの形成をもたらす故障は発生していない）。時間ｔ＝０−より前のある時点では、サーバーＡはサーバーＢのランタイム状態を正常に要求することができた。サーバーＢのキャッシュは、サーバーＡがサーバーＢのランタイム状態を要求した結果として、サーバーＡのランタイム状態が不明９１５であることを示している。サーバーＢはスタンバイ状態にある間、サーバーＡのランタイムステータスを要求することができない。サーバーＡのキャッシュは、サーバーＢのランタイムステータスがスタンバイ９１０であることを示すことができる。

安定したシステムでは、非アクティブなＮＭＳインスタンスはすべて最終的にスタンバイ状態になる。スタンバイ状態のＮＭＳインスタンスは、アクティブサーバーのランタイムステータスを要求することができない。アクティブサーバーのキャッシュメモリは、他のサーバーのランタイムステータスを示すデータを含み得る。スタンバイ状態にあるサーバーはアクティブサーバーのランタイムステータスを要求することができないので、アクティブサーバーのキャッシュ内のランタイム状態は変化することがない。したがって、アクティブサーバーは他のサーバーのランタイムステータスを更に要求することはないので追加の通信オーバーヘッドは削除される。

例えば、ＤＣＮ破壊が発生した場合、１つ又は複数のＮＭＳインスタンスをアクティブ化して実行状態に到達してもよい。アクティブなＮＭＳインスタンス（例えば、サーバーＡ）に、新たにアクティブ化されたサーバー（例えば、サーバーＢ）が正常に接続できない場合がある。サーバーＢがサーバーＡに正常に接続できなかった場合、サーバーＢはアクティブになることができない（即ち、同じドメイン内にサーバーＡとサーバーＢが存在する場合）。サーバーＢはサーバーＡに正常に接続できないので、サーバーＢのキャッシュ情報に含まれるサーバーＡのランタイムステータスは不明に設定される。

図９を再度参照すると、時間ｔ＝０で、ＤＣＮ故障が発生している。この故障により、サーバーＡとサーバーＢは通信できなくなっている可能性がある。サーバーＡとサーバーＢは、別々のドメイン及び／又はアイランドに存在する。時間ｔ＝０＋で、例えば、サーバーＢはＷＳＦからアクティブ化のための要求を受信した可能性がある。したがって、サーバーＢは初期化状態９２５にあると考えられる。サーバーＢは、サーバーＡのステータスを正常に要求することができず、従ってサーバーＢのキャッシュ内のサーバーＡのランタイムステータスを不明９２５に設定し、初期化機能を継続している可能性がある。サーバーＡは実行状態９２０のままであると考えられる。時間ｔ＝０から時間ｔ＝０＋までの間に、サーバーＡはサーバーＢのランタイムステータスを要求することができる。ＤＣＮ故障の結果、サーバーＢはサーバーＡに応答できなくなり、このため、サーバーＡのキャッシュ内にあるサーバーＢのランタイムステータスも不明９２０に設定される。時間ｔ＝Ｔ−で、サーバーＢは実行状態９３５に移行する。サーバーＡは、実行状態９３０を継続する。サーバーＡとサーバーＢとの間で通信が行われなくても、サーバーＡのキャッシュとサーバーＢのキャッシュはそれぞれ、他方のサーバーの状態が不明９３０、９３５であることを示している。

周期的にサーバーＢはサーバーＡのランタイムステータスを要求する。例えば、時間ｔ＝Ｔでは、ＤＣＮ接続が再び確立される。サーバーＡとサーバーＢは再び正常に通信できるようになる。ＤＣＮ接続が再び確立されると、次のランタイムチェック時間（例えば、時間ｔ＝Ｔ＋１）では、サーバーＢはサーバーＡに正常に接続することができる。サーバーＡとサーバーＢはどちらも実行状態９４０、９４５で、サーバーＢのキャッシュ内のサーバーＡの状態は実行９４５に設定される。その後、サーバーＢは、サーバーＡの応答に基づいて、アクティブのままでいるのか、それともスタンバイモードに入るのかを決定する。このランタイムステータス要求により、サーバーＡのキャッシュされた情報に含まれるサーバーＢのランタイムステータスは不明９４０へ更新され、サーバーＡは次のチェック時間（例えば、時間ｔ＝Ｔ＋２）でサーバーＢのランタイムステータスをチェックすることができる。サーバーＡがサーバーＢのランタイムステータスを要求した結果、サーバーＢのキャッシュ内のサーバーＡのランタイムステータスは不明９５５に設定される。サーバーＡとサーバーＢのランタイムステータスは両方とも、実行９５０、９５５のままとなり得る。その後、サーバーＡは、サーバーＢの応答に応じて、アクティブのままでいるのか、それともスタンバイモードに入るのかを決定することができる。

サーバーＢがアクティブのままである場合、サーバーＡはスタンバイ状態になり、サーバーＢがネットワークで唯一のアクティブサーバーになる。例えば、時間ｔ＝Ｔ＋３では、サーバーＡはスタンバイ状態９６０に遷移し、サーバーＢは実行状態９６５のままとなる。両方のサーバーのキャッシュはいずれも不明９６０、９６５に設定されたまま変化なしになる。サーバーＢは次のクエリー時間（例えば時間ｔ＝Ｔ＋４）でサーバーＡのランタイムステータスを要求する。この要求の結果として、サーバーＡのキャッシュ内のサーバーＢのランタイム状態は不明９７０に設定され（即ち、変化なし）、サーバーＢのキャッシュ内のサーバーＡのランタイム状態はスタンバイ９７５に設定される。スタンバイ状態では、サーバーＡはサーバーＢのランタイムステータスを要求しないので、サーバーＡのキャッシュ内のサーバーＢのランタイム状態は不明９７０に設定されたままとなる。

図１０を参照すると、サーバーＡとサーバーＢは両方とも実行状態になっている（１０１０）ので、サーバーの相対的なランタイム優先度に基づいてスタンバイモードに移行するかどうかの決定が行われる（１０２０）。ランタイム優先度がランタイム進捗度に依存する場合、各ＮＭＳインスタンスの相対的な進捗に従って、即ち、各ＮＭＳインスタンスがサービスを提供するＷＳＦクライアント数、最終的には各サーバーのアクティブ化優先度に従って、アクティブのままとなるＮＭＳインスタンスが決定される（１０５０）。ランタイム優先度がアクティブ化優先度に依存する場合（１０３０）、優先度の高いサーバーがアクティブのままになる（１０４０）。サーバーが両方ともアクティブ化の優先度が同じである場合、ランタイム進捗度の高いサーバーがアクティブのままになる（１０６０）。サーバーが両方ともランタイム進捗度が同じである場合、両方ともスタンバイ状態に遷移し（１０７０）、そのうちの１つがＷＳＦクライアントによって再度アクティブ化される。

ＥＭＳによって個別に検出された終端点を、ＥＭＳ−ＮＭＳサーバーが適切なネットワークトレイルに「ソーイング（ｓｅｗ）」した場合に構成管理が実現可能となる。このソーイングは、新しいＮＭＳサーバーがアクティブになったとき、又はユーザーが（例えば、ＧＵＩパネルを使用して）ネットワークの再検出を強制実行したときにはいつも発生し得る。

図１１は分散型ネットワーク（例えば、海底光ファイバネットワーク）の概略図を示したものである。分散型ネットワークは３つの層を含むことができる。第１の層は光伝送セクション（ＯＴＳ）層１１１０とする。ＯＴＳ層１１１０は光ファイバと光ファイバの相互接続とを含む。第２の層は光多重セクション（ＯＭＳ）層１１２０とすることができる。ＯＭＳ層１１２０は光信号の多重化チャネルを含む。第３の層は光チャネル（ＯＣＨ）層１１３０とする。

層は１つ又は複数のトレイルを含んでもよい。トレイルは１つ又は複数の接続と少なくとも１つの終端点とを含むようにしてもよい。例えば、ＯＣＨトレイル１１３５は、２つの終端とそれらをつなぐチャネルとを含むようにする。ＯＭＳトレイル１１２５を形成するには１つ又は複数のＯＭＳ接続を順番にリンクする。ＯＭＳ接続は、物理リンク（例えば、ファイバ）に対応するＯＴＳトレイル１１１５によってサポート可能である。

ＮＭＳ機能（例えば、ＮＭＳ ５４）は、終端点及びその接続ポインタを検出し、該当する終端点及びその接続ポインタを適切なネットワークトレイルに結合／ソーイングすることにより、動的なトレイル生成を実現することができる。検出及びソーイングはリアルタイムで実行することができ、比較的大きなシステムの場合でも数分しかかからない。トレイル生成及びトレイルインベントリ情報は、故障管理機能（例えば、故障マネージャコンポーネント６１８）と性能管理機能（例えば、性能マネージャコンポーネント６１６）の両方で使用することができる。

ＷＳＦ構成管理機能は、ＯＣＨトレイル（例えば、ＯＣＨトレイル１１３５）と関連するユーザー指定の顧客名やメモ等をサポートすることができる。ＥＭＳ−ＮＭＳハードウェアサーバー上に常駐するＥＭＳ機能は、装置インベントリのデータベースを維持することができる。ＮＭＳ機能（例えば、ＮＭＳ ５４）では、ＥＭＳ（例えば、ＥＭＳ ５０−１）機能からの情報をノースバウンドインターフェイス（例えば、ＮＢＩ ５２−１）を介して取得して格納する。オペレーターは、トランスポートシステムに従って顧客名を割り当てることにより、ＥＭＳ−ＮＭＳアラームレポートとトランスポートシステムＮＭＳによって生成されたものとを比較的に迅速且つ視覚的に関連付けることができ、潜在的なトランスポート障害と海底障害を手動で関連付けるのに役立つ。

管理対象ネットワークの故障又はアラーム管理は、ＥＭＳ機能のそれぞれからＮＢＩ（例えば、ＮＢＩ ５２−１）を介して送られる自動イベント通知（アラーム同期化を含む）によって実現可能である。このアーキテクチャでは、レポートされるアラームとしてＮＭＳシステムアラーム（例えば、不良ハードディスクドライブ、ＣＰＵアラーム、ＤＣＮアラーム等）を挙げることができる。したがって、故障管理は管理システム自体の故障管理を含むことができる。ＮＭＳ機能は、ネットワークのアクティブアラームリストのリアルタイムコピーを維持し、登録された各クライアント（例えば、ＷＳＦ）の自動更新を行う。トラフィックに影響を及ぼすアラームは、１つ又は複数のトレイルと関連付けることができる。ＷＳＦクライアントは、ＮＭＳ機能のクエリーを発行することなしに、アラームをローカルに調査及びフィルタリングすることができるので、ＤＣＮトラフィックの増大を抑えることができる。アクティブアラームは、表形式で一覧することも、ネットワークトポロジー図（例えば、図１２に示すような）上の発生場所（例えば、監視されているケーブル局又はセグメント）に示すこともできる。図１３はユーザーＷＳＦに提供される表示例を示したものである。この表示には、装置ごとの情報へのユーザーアクセスを可能にする「カットスルー」が含まれている。ラインモニタリングシステム（ＬＭＳ）によって識別される海底セグメントに関するアラームも含めることができる。色を使用して、指定の場所にレポートされているアラームの重大度が最大であることを示すことができる。

ユーザーが選択したトポロジー範囲に基づく追加のトレイルの図もまた、場所ごとにアラームの発生を示すことができる。これにより、ユーザーは装置の故障が及ぼす影響や潜在的な共通の原因を、おそらく調査を長時間しなくても迅速に特定することができる。アクティブアラームリストは、根本原因解析（ＲＣＡ）機能でも使用され得る。

ＲＣＡ機能は、ユーザーからの要求があると、特定の範囲内で現在の任意のアラームを解析して親原因又は根本原因を明らかにすることができる。ＲＣＡ機能は更に、トポロジーベースの正確な故障解析に基づいた、考えられる修正措置を提供することもできる。ＲＣＡ機能は、海底ケーブルネットワークアーキテクチャ向けに設計することが可能であり、この場合、ルール等のユーザー構成は考慮しなくてもよい。しかし、異常なネットワーク管理ポリシー又は挙動に基づいて、新たに考えられる根本原因を明らかにすること又は自動的なＲＣＡアルゴリズムを無効にすることをユーザーが希望する場合には、ルールを定義する手段を提供してもよい。ＲＣＡ機能では、管理されるネットワーク要素（ＮＥ）挙動モデルと海底ネットワークのトポロジーモデルとを組み合わせて利用することにより、可能性のある根本原因に確実に到達することができる。ＲＣＡ機能では、アラームが発生したＮＥの時間的関係と空間的関係の両方を検討することにより、関係のないアラームを効率的にフィルタリングして除外し、複雑なネットワーク故障の場合にユーザーに提供されると考えられる過多なアラームイベントを最小限に抑えることができる。これらの機能により装置ごとにルールを定義することの必要性を効率的になくすことが可能である。ＲＣＡ機能では、他のトレイル表示メカニズムを補完して海底アラームの根本原因を迅速に特定することができる。トレイル階層内のどこでＲＣＡが開始され得るかに応じて、ＲＣＡ機能に提供するアラーム情報の適切なスコーピングを自動的に行い、目的のネットワーク範囲での根本原因を特定することができる。

性能管理機能は、前述の構成管理機能によって作成されたトレイルに依存し、クライアントＷＳＦから要求があった場合にのみアクティブにすることができる。ＥＭＳ−ＮＭＳサーバー上のＥＭＳ機能は、管理されるネットワーク要素に関連する履歴データのデータベースを維持することができる。したがって、ＮＭＳ機能と関連付けられた持続的なデータベースにおいてデータを二重化する必要はない。その代り、クライアント（ＥＭＳ−ＮＭＳ自動ＰＭレポートジェネレータ機能を含んでもよい）がオプションのフィルタ及びスコーピングを使用してトレイルベースのレポートを要求した場合、ホストの役割を果たすＮＭＳサーバーは該当するＥＭＳ機能だけとのＮＢＩを介して、最適化されたデータベースクエリーを開始することができる。これらのサーバーは、トレイルと関連する装置の履歴データを維持することができる。性能管理及びクエリー応答は、ＮＭＳ ＤＣＮトラフィックを最低限に抑えるために最適化することができる。このパラダイムでは、数秒以内にＷＳＦ応答を返すことができる。

分散型ネットワーク管理システム及び方法の実施形態、例えばＥＭＳ−ＮＭＳサーバーのＮＭＳ及びＥＭＳ機能は、コンピュータシステムで用いるためのコンピュータプログラム製品として実施できる。そのような実装例としては、システム及び方法の観点で本明細書に説明された機能の全部又は一部を具現化する一連のコンピュータ命令が挙げられるがこれに限定されない。一連のコンピュータ命令は、半導体、磁気、光学又は他のメモリ装置等のどのような機械可読媒体に記憶されていてもよく、光学、赤外、マイクロ波又は他の伝送技術等のどのような通信技術を用いて伝送されてもよい。そのようなコンピュータプログラム製品は、取り外し可能機械可読媒体（例えば、ディスケット、ＣＤ−ＲＯＭ等）として分散されていてもよく、コンピュータシステム（例えば、システムＲＯＭ又は固定ディスク）に予め読み込まれていてもよく、又はネットワーク上でサーバー若しくは電子掲示板（例えば、インターネット又はワールドワイドウェブ）から分配されるようにしてもよいことが予想される。

当業者であれば、そのようなコンピュータ命令は、多くのコンピュータアーキテクチャ又はオペレーティングシステムで使用される多数のプログラム言語で書かれ得ることを理解するはずである。例えば、好適な実施形態は手続きプログラム言語（例えば、「Ｃ」）又はオブジェクト指向プログラム言語（例えば、「Ｃ＋＋」又はＪａｖａ（登録商標））で実施してもよい。本開示の代替の実施形態は、予めプログラムされたハードウェア要素若しくはファームウェアとして、又はハードウェア、ソフトウェア及びファームウェアの組み合わせとして実施してもよい。

したがって、分散型ネットワーク管理システム及び方法を用いることによって、１つのサーバーへの依存を最小にしてネットワーク内のサーバー間でデータを共有できる。また、分散型メッセージングはトラフィックフローを軽減し、システムのボトルネックをなくすことができる。

本開示の一態様では、複数のサーバーを備える分散型ネットワーク管理システムが提供されており、当該複数のサーバーのそれぞれは、ネットワーク内のネットワーク要素を管理するための要素管理システム（ＥＭＳ）機能と、ＥＭＳ機能を実行する複数のサーバーのうちの複数を管理するためのネットワーク管理システム（ＮＭＳ）機能とを含んでいる。複数のサーバーが１つのネットワークドメインを共有している場合に、確実に、ＮＭＳ機能が複数のサーバーのうちの１つでアクティブとなり、複数のサーバーのうちの他の全てで非アクティブとなるように複数のサーバーは構成される。ネットワークドメインが複数のドメインに分割されている場合に、複数のサーバーは複数のドメインのそれぞれと関連付けられた複数のサーバーのうちの１つでＮＭＳ機能を自動的にアクティブ化し、複数のネットワークドメインのそれぞれを含むサーバーのうちの他の全てのサーバーでＮＭＳ機能が確実に非アクティブとなるように構成される。

本開示の別の態様によれば、ネットワークを管理するための方法であって、複数のサーバーのそれぞれで、ネットワーク内のネットワーク要素を管理するための要素管理システム（ＥＭＳ）機能と、ＥＭＳ機能を実行する複数のサーバーのうちの複数を管理するためのネットワーク管理システム（ＮＭＳ）機能とを提供するステップと、複数のサーバーが１つのネットワークドメインを共有している場合に複数のサーバーのうちの１つでＮＭＳ機能をアクティブにするステップと、１つのネットワークドメインが複数のネットワークドメインに分割されている場合に複数のサーバーのうちの少なくとも１つの他のサーバーでＮＭＳ機能を自動的にアクティブ化するステップと、を含む方法が提供される。それによって、複数のネットワークドメインのそれぞれは、関連付けされた少なくとも１つのアクティブなＮＭＳ機能を有する。

本開示の別の態様によれば、複数のサーバーを備え、当該複数のサーバーのそれぞれがネットワーク内のネットワーク要素を管理するための要素管理システム（ＥＭＳ）機能と、ＥＭＳ機能を実行する複数のサーバーのうちの複数を管理するためのＮＭＳ機能とを備える分散型ネットワーク管理システムにおいてホストサーバーを割り当てるための方法が提供される。この方法は、複数のサーバーのうちの第１のサーバーを操作して複数のサーバーのうちのリモートサーバーのＮＭＳ機能のランタイムステータスを要求するステップと、サーバーのうちのリモートサーバーからの応答を受信するステップと、複数のサーバーのうちの第１のサーバーのランタイムステータスと、複数のサーバーのうちのリモートサーバーのランタイムステータスとを比較するステップと、ランタイムステータスの比較に応答して第１のサーバーをホストサーバーとして初期化するステップとを含む。

本開示の更に別の態様によれば、機械可読な媒体が提供され、この媒体の内容によりコンピュータシステムは、複数のサーバーを備え、当該複数のサーバーのそれぞれが、ネットワーク内のネットワーク要素を管理するための要素管理システム（ＥＭＳ）機能と、ＥＭＳ機能を実行する複数のサーバーのうちの複数を管理するためのＮＭＳ機能とを備える分散型ネットワーク管理システムにおいて、ホストサーバーを割り当てる方法を実行する。この方法は、複数のサーバーのうちの第１のサーバーを操作して複数のサーバーのうちのリモートサーバーのＮＭＳ機能のランタイムステータスを要求するステップと、サーバーのうちのリモートサーバーからの応答を受信するステップと、複数のサーバーのうちの第１のサーバーのランタイムステータスと、複数のサーバーのうちのリモートサーバーのランタイムステータスとを比較するステップと、ランタイムステータスの比較に応答して第１のサーバーをホストサーバーとして初期化するステップとを含む。

本開示の原理が本明細書に説明されてきたが、当業者には分かるように、この説明はあくまでも例示としてなされたものであり、本開示の範囲を限定するものではない。本明細書に示され説明された例示的実施形態に加えて他の実施形態も本開示の範囲において考えられる。当業者による変更及び置換は本開示の範囲のものとしてみなされ、その本開示の範囲は特許請求の範囲以外のものによって限定されるものではない。

Claims (23)

1. 分散型ネットワーク管理システムであって、
   複数のサーバーを備え、前記複数のサーバーのそれぞれが、ネットワーク内のネットワーク要素を管理するための要素管理システム（ＥＭＳ）機能と、前記ＥＭＳ機能を実行する前記複数のサーバーのうちの複数を管理するためのネットワーク管理システム（ＮＭＳ）機能とを備える分散型ネットワーク管理システムにおいて、
   前記複数のサーバーは１つのネットワークドメインを共有している場合に、確実に、前記ＮＭＳ機能が前記複数のサーバーのうちの１つでアクティブとなり、前記複数のサーバーのうちの他の全てで非アクティブとなるように構成され、
   前記１つのネットワークドメインが複数のドメインに分割されている場合に、前記複数のサーバーは前記複数のドメインのそれぞれと関連付けられた前記複数のサーバーのうちの１つで前記ＮＭＳ機能を自動的にアクティブ化し、前記複数のネットワークドメインのそれぞれを含む前記複数のサーバーのうちの他の全てで前記ＮＭＳ機能が確実に非アクティブとなるように構成されることを特徴とする分散型ネットワーク管理システム。
2. 前記複数のドメインが前記１つのネットワークドメインに結合された場合に複数の前記複数のドメインのそれぞれと関連付けられたＮＭＳ機能を非アクティブ化し、前記ＮＭＳ機能が前記複数のサーバーのうちのホストサーバー上で確実にアクティブとなるように、前記複数のサーバーが構成されることを特徴とする請求項１に記載の分散型ネットワーク管理システム。
3. 前記ＮＭＳ機能が非アクティブとなっている前記複数のサーバーのうちの複数で前記ＥＭＳ機能が確実にアクティブになるように、前記複数のサーバーが構成されることを特徴とする請求項１に記載の分散型ネットワーク管理システム。
4. 前記ＮＭＳ機能がアクティブになっているドメインのネットワークトポロジーを自動的に検出するように、前記ＮＭＳ機能が構成されることを特徴とする請求項１に記載の分散型ネットワーク管理システム。
5. 前記複数のサーバーが、前記ＮＭＳ機能用にネットワーク情報の持続データベースを維持しないことを特徴とする請求項１に記載の分散型ネットワーク管理システム。
6. 前記ＮＭＳ機能がアクティブになっている前記ドメイン内で終端点を自動的に検出し、前記終端点を接続して、前記ＮＭＳ機能がアクティブになっている前記ドメイン用にネットワークトレイルを確立するように、前記ＮＭＳ機能が構成されることを特徴とする請求項１に記載の分散型ネットワーク管理システム。
7. 前記ＮＭＳ機能が、前記ネットワークトレイルを使用する前記ネットワークに対して故障管理を実行するよう構成されることを特徴とする請求項６に記載の分散型ネットワーク管理システム。
8. 前記複数のサーバーのそれぞれが、前記ネットワークのステータスをユーザーに表示するためのクライアントワークステーション機能（ＷＳＦ）を更に有することを特徴とする請求項１に記載の分散型ネットワーク管理システム。
9. ネットワークを管理するための方法であって、
   複数のサーバーのそれぞれで、ネットワーク内のネットワーク要素を管理するための要素管理システム（ＥＭＳ）機能と、前記ＥＭＳ機能を実行する前記複数のサーバーのうちの複数を管理するためのネットワーク管理システム（ＮＭＳ）機能とを提供するステップと、
   前記複数のサーバーが１つのネットワークドメインを共有している場合に前記サーバーのうちの１つで前記ＮＭＳ機能をアクティブにするステップと、
   前記１つのネットワークドメインが複数のネットワークドメインに分割されている場合に前記複数のサーバーのうちの少なくとも１つの他のサーバーで前記ＮＭＳ機能を自動的にアクティブ化するステップと、を備え、前記複数のネットワークドメインのそれぞれが少なくとも１つの関連付けされたアクティブなＮＭＳ機能を有するものであることを特徴とする方法。
10. 前記複数のドメインが前記１つのネットワークドメインに結合された場合に複数の前記複数のドメインのそれぞれと関連付けられたＮＭＳ機能を自動的に非アクティブにするステップを更に備えることを特徴とする請求項９に記載の方法。
11. 前記ＮＭＳ機能が非アクティブになっている前記複数のサーバーのうちの複数で前記ＥＭＳ機能をアクティブにするステップを更に備えることを特徴とする請求項９に記載の方法。
12. 前記ＮＭＳ機能がアクティブになっている前記サーバーのうちの複数でネットワークトポロジーを自動的に検出するステップを更に備えることを特徴とする請求項９に記載の方法。
13. 前記ＮＭＳ機能がアクティブになっている前記サーバーのうちの複数で終端点を自動的に検出し、前記終端点を接続してネットワークトレイルを確立するステップを更に備えることを特徴とする請求項９に記載の方法。
14. 前記ネットワークトレイルを使用する前記ネットワークに対する故障管理を実行するステップを更に備えることを特徴とする請求項１３に記載の方法。
15. 前記ネットワークのステータスをユーザーに表示するためのクライアントワークステーション機能（ＷＳＦ）を前記複数のサーバーのそれぞれに提供するステップを更に備えることを特徴とする請求項９に記載の方法。
16. 複数のサーバーを備え、前記複数のサーバーのそれぞれが、ネットワーク内のネットワーク要素を管理するための要素管理システム（ＥＭＳ）機能と、前記ＥＭＳ機能を実行する前記複数のサーバーのうちの複数を管理するためのＮＭＳ機能とを備える分散型ネットワーク管理システムにおいて、ホストサーバーを割り当てるための方法であって、
    前記複数のサーバーのうちの第１のサーバーを操作して前記複数のサーバーのうちのリモートサーバーのＮＭＳ機能のランタイムステータスを要求するステップと、
    前記サーバーのうちの前記リモートサーバーからの応答を受信するステップと、
    前記複数のサーバーのうちの前記第１のサーバーのランタイムステータスと、前記サーバーのうちの前記リモートサーバーの前記ランタイムステータスとを比較するステップと、
    前記ランタイムステータスの比較に応答して前記第１のサーバーをホストサーバーとして初期化するステップとを備えることを特徴とする方法。
17. 前記複数のサーバーと関連付けられたネットワークトポロジーを自動的に検出するステップを更に備えることを特徴とする請求項１６に記載の方法。
18. 前記複数のサーバーと関連付けられた終端点を自動的に検出し、前記終端点を接続してネットワークトレイルを確立するステップを更に備えることを特徴とする請求項１６に記載の方法。
19. 前記ネットワークトレイルを使用する前記ネットワークに対する故障管理を実行するステップを更に備えることを特徴とする請求項１８に記載の方法。
20. 複数のサーバーを備え、前記複数のサーバーのそれぞれが、ネットワーク内のネットワーク要素を管理するための要素管理システム（ＥＭＳ）機能と前記ＥＭＳ機能を実行する前記複数のサーバーのうちの複数を管理するためのＮＭＳ機能とを備える分散型ネットワーク管理システムにおいて、ホストサーバーを割り当てる方法を、コンピュータシステムに実行させるための内容を記録した機械により読取可能な記録媒体であって、
    前記方法が、
    前記複数のサーバーのうちの第１のサーバーを操作して前記複数のサーバーのうちのリモートサーバーのＮＭＳ機能のランタイムステータスを要求するステップと、
    前記サーバーのうちの前記リモートサーバーからの応答を受信するステップと、
    前記複数のサーバーのうちの前記第１のサーバーのランタイムステータスと、前記サーバーのうちの前記リモートサーバーの前記ランタイムステータスとを比較するステップと、
    前記ランタイムステータスの比較に応答して前記第１のサーバーをホストサーバーとして初期化するステップとを備えたものであることを特徴とする記録媒体。
21. 前記方法が、前記複数のサーバーと関連付けられたネットワークトポロジーを自動的に検出するステップを更に備えることを特徴とする請求項２０に記載の記録媒体。
22. 前記方法が、前記複数のサーバーと関連付けられた終端点を自動的に検出し、前記終端点を接続してネットワークトレイルを確立するステップを更に備えることを特徴とする請求項２０に記載の記録媒体。
23. 前記方法が、前記ネットワークトレイルを使用する前記ネットワークに対する故障管理を実行するステップを更に備えることを特徴とする請求項２２に記載の記録媒体。

Images