(57)【要約】【課題】冗長性を有しつつ効率のよい協調動作が可能な、クラスタ構成の複数サーバによるネットワークの管理方法、システムを提供する。【解決手段】複数のNMSサーバをクラスタ構成にしたネットワーク管理システムであって、NMSサーバが管理対象であるノードの一覧を分散ハッシュテーブルのアルゴリズムに従って分割生成して該NMSサーバに割り当てるためのテーブルを有し、該テーブルに従って管理すべきノードが割り当てられると共に分散ハッシュテーブルのアルゴリズムに対応したハッシュ空間上に配置され、クライアントからの問い合わせに対して前記アルゴリズムに基づいたノードの検索および他NMSサーバへの問い合わせを実行する。【選択図】図２
2010282450.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続されるノードを管理するネットワーク管理システムであって、
前記ネットワークに複数のNMS（Network Management System）サーバが接続され、且つ各NMSサーバは分散ハッシュテーブル（以下、DHTという）を有し、該分散ハッシュテーブルのアルゴリズムに従って前記ノードを分散管理することを特徴とするネットワーク管理システム。
【請求項２】
前記分散ハッシュテーブルのアルゴリズムとして、DHTのアルゴリズムに従う各ゾーンに分割配置された全てのノードが、少なくとも２つのNMSサーバによって管理されるように構成した請求項１記載のネットワーク管理システム。
【請求項３】
前記DHTのアルゴリズムとしてのChordの手法に従って、全てのNMSサーバとノードとにハッシュ値が割り当てられ、且つそれらのハッシュ値によってNMSサーバとノードとが円環的に配置された構成において、各NMSサーバは少なくとも両隣のNMSサーバとの間に配置されたノードを管理する請求項２記載のネットワーク管理システム。
【請求項４】
前記DHTのアルゴリズムとしてのCANの手法に従って、全てのNMSサーバとノードとには2組のハッシュ値(x,y：0≦x≦１, 0≦y≦１)が割り当てられ、かつそれらのハッシュ値によって前記NMSサーバとノードとが二次元座標上の正方形(0≦x≦１, 0≦y≦１)領域に配置された構成において、該正方形領域がさらに内部に一つのNMSサーバを含む長方形の領域に分割され、各NMSサーバは自己が所属する領域のノードと隣接する少なくとも一つの領域のノードとを管理する請求項２記載のネットワーク管理システム。
【請求項５】
ネットワークに接続されるノードを管理するネットワーク管理方法であって、
前記ネットワークにそれぞれが分散ハッシュテーブルを有する複数のNMSサーバを接続し、各NMSサーバが前記分散ハッシュテーブルのアルゴリズムに従って前記ノードを分散管理するネットワーク管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタ構成された複数のサーバにより多数のノードを監視または管理するネットワーク管理システム及びネットワーク管理方法に関する。
【背景技術】
【０００２】
ネットワーク管理システムは、管理対象のノードを監視するNMS（Network Management System）サーバとNMSクライアントから構成される。近年管理対象のノード数が増大し、１台のNMSサーバで管理することが困難となり、複数のNMSサーバによるクラスタ構成での管理が提案されている。
【０００３】
なお、関連する技術として、下記非特許文献（例えば、非特許文献１参照）が知られている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Ratnasamy et al.(2001)."A Scalable Content-Addressable Network". In Proceedings of ACM SIGCOMM 2001. Retrieved on 2008-12-22
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、クラスタ構成の複数のサーバによりノードを管理する場合、機能の拡張（サーバの追加、削除等）に伴い主として以下の２つの問題点がある。
【０００６】
まず、どのノードをどのサーバで管理するか、またはあるクライアントをどのサーバに接続するかについて、任意に定めたのでは、協調動作が効率よく行えなくなるという問題点がある。
【０００７】
また、少ないサーバで効率よくクラスタを構成しなければ、経済性が悪くなり、また、ある程度システムに冗長性を持たせなければ、あるサーバがダウンした場合のリスクが回避できなくなり信頼性が低下するという問題点もある。
【０００８】
本発明は、上述した問題点を解決するためになされたものであり、冗長性を高めて信頼性を確保しつつ効率のよい協調動作が可能な、クラスタ構成の複数サーバによるネットワークの管理システム、およびネットワーク管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決するため、本発明の一態様は、ネットワークに接続されるノードを管理するネットワーク管理システムにおいて、前記ネットワークに複数のNMSサーバが接続され、且つ各NMSサーバは分散ハッシュテーブルを有し、該分散ハッシュテーブルのアルゴリズムに従って前記ノードを分散管理することを特徴とする。
【００１０】
また、本発明の一態様は、ネットワークに接続されるノードを管理するネットワーク管理方法において、前記ネットワークにそれぞれが分散ハッシュテーブルを有する複数のNMSサーバを接続し、各NMSサーバが前記分散ハッシュテーブルのアルゴリズムに従って前記ノードを分散管理する。
【発明の効果】
【００１１】
本発明に係る複数サーバによるネットワーク管理システムによれば、冗長性と柔軟な拡張性とを具備した複数サーバの協調動作を容易に実現できる。
【図面の簡単な説明】
【００１２】
【図１】複数のサーバによるネットワーク管理システムの図である。
【図２】NMSサーバとノードとに割り当てられたハッシュ値の例を示す図である。
【図３】Chordアルゴリズムに従いハッシュ値によってノードとNMSサーバとを円環状に配置した例を示す図である。
【図４】各NMSサーバとこれらが管理するノードとの対応例を示す図である。
【図５】CANアルゴリズムに従い２種のハッシュ値の組によってNMSサーバとノードとを二次元座標上に配置した状態を示す図である。
【図６】CANアルゴリズムの場合の各NMSサーバが所有する情報（管理領域、隣接サーバ等）の例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明の実施の形態について図面を参照しつつ説明する。
【００１４】
図１は、複数のNMSサーバにより構成されるネットワーク管理システムの図である。この管理システムは、ネットワーク１に接続される複数のノード（機器）２を複数のNMSサーバA〜Dで管理するシステムであり、所定のNMSサーバ（ここではNMSサーバB,D）にはNMSサーバによるノードの管理状況の問い合わせを行うクライアント３が接続されている。なお、本実施の形態として、ノード２には、通常のパーソナルコンピュータの他、プラント内のフィールド機器、センサ群、および検査装置やその端末、更には医療、診断機器やその端末が含まれる。
【００１５】
各NMSサーバA〜Dは、自身が管理すべきノードの一覧（あるいは範囲）と、隣接のNMSサーバの情報とをテーブルとして持つ。ノード（負荷）をバランスよくNMSサーバに割り付け、かつこれらノードの検索を容易にするために、ここでは、分散ハッシュテーブル（Distributed Hash Table、以降DHTと略す）のアルゴリズムが利用されている。
【００１６】
DHTのアルゴリズムとしては、Chord、CAN、Pastry、Tapestry等が知られるがここでは、特にChord、およびCANのアルゴリズムについて説明する。
【００１７】
図２は、NMSサーバ（A〜D）を含む全管理ノード２に対しハッシュ値を割り付けた一例を示している。Chordアルゴリズムでは、これらNMSサーバA〜Dとノード２とを円環的（リング状）に配置し、ノードの検索、あるいはNMSサーバの参加、離脱を行うものである。図３は、NMSサーバA〜Dとノード２とをそれらのハッシュ値に従ってリング状に配置した状態を示している。
【００１８】
なお、これらは、物理的な位置関係ではなく、ハッシュ値による数値空間上での位置関係を示している。
【００１９】
図３に示す例では、ノード２として、NMSサーバA、Bの間にノードb1、b2、b3が、NMSサーバB、Cの間にノードc1、c2、c3が、NMSサーバC、Dの間にノードd1、d2、d3が、およびNMSサーバD、Aの間にノードa1、a2、a3がそれぞれ配置されている。
【００２０】
これらノード２がどのNMSサーバA〜Dによって管理されるかについては、通常以下の規則がある。まず各ノードのハッシュ値を計算し、最も近いハッシュ値を持つサーバによって管理されることになる。図３のようなリング状の配置では、各ノード２の位置から時計
回りに最初に位置するNMSサーバとなる。
【００２１】
さらに本実施の形態では冗長性を持たせるために以下の管理を行う。すなわち各NMSサーバA〜Dは、リング上の前後のNMSサーバおよびそれらのハッシュ値を認識しているので、前後のNMSサーバと自身のサーバとの間に存在するノードも認識することができ、これらを管理するようにする。
【００２２】
これを全てのNMSサーバに適用すると、全てのノード２はリング上の前後２つのNMSサーバによって同時に管理されることになる（図４参照）。つまり仮にある一つのNMSサーバがダウンしても、当該サーバが管理しているノード情報は、その前後のNMSサーバが二重に管理しているので、情報が失われることはなく、ノード２の再配置も可能となる。
【００２３】
クライアント３からのノードを管理するNMSサーバの問い合わせ要求に対するノードの検索は以下の手順で行われる。
（Ｓ１）検索したいノードのハッシュ値を計算し、自己が管理しているノードであればそのままクライアントに結果を返す。
（Ｓ２）自己が保持していない場合は、隣のNMSサーバ（リング時計回りで最初に位置するNMSサーバ）に問い合わせる。
（Ｓ３）隣のNMSサーバも保持していない場合は、また次の隣のNMSサーバに問い合わせるということを繰り返す。このようにして該当ノードを管理しているNMSサーバに到達し、当該NMSサーバからクライアントに結果を返す。
（Ｓ４）クライアントは、問い合わせたノードがどのNMSサーバで管理しているかを知ることができるため、以後該当するNMSサーバに直接問い合わせることも可能となる。
【００２４】
次にNMSサーバの追加、削除の手順について説明する。
【００２５】
まず、NMSサーバを追加する場合について説明する。
（Ｓ１１）追加される自己のNMSサーバのハッシュ値を計算し、リング上での位置、すなわち隣接のNMSサーバの情報を、自己のテーブルに登録する。
（Ｓ１２）追加される自己のNMSサーバの情報を隣接するNMSサーバに通知し、登録データを更新してもらう。
（Ｓ１３）管理すべきノードの情報を隣接のNMSサーバから引き継ぐ。
【００２６】
次に、NMSサーバを削除する場合について説明する。なお、ここでは、削除対象となるNMSサーバに隣接するNMSサーバをX、Yとする。
（Ｓ２１）NMSサーバXに対し、サーバYが隣接サーバになることを通知し、登録データを更新してもらう。
（Ｓ２２）削除される自己のNMSサーバが管理するノードの情報をサーバXに移管する。
（Ｓ２３）NMSサーバYに対し、サーバXが隣接サーバになることを通知し、登録データを更新してもらう。
（Ｓ２４）自己の（削除される）NMSサーバが管理するノードの情報をサーバYに移管する。
【００２７】
図５は同じくDHTの一つであるCANアルゴリズムに従い、２種のハッシュ値（Hash1, Hash2）の組によってNMSサーバとノードとを二次元座標上に配置した例を示す図である。
【００２８】
全領域Sが、一辺が１の正方形内部に相当し、これを左下の座標と右上の座標とでS:(0,
0)〜(1, 1)と表す。各サーバA〜Fとそれらが管理する領域a〜fが図示してある。各領域（一般には長方形）a〜fは同様に左下の座標と右上の座標とで表現する。例えば領域cは、c: (0.3, 0.4)〜(0.7, 1)となる。
【００２９】
図６は、NMSサーバの情報として、それらの座標および管理する領域を一例として表にまとめたものである。各NMSサーバに対し、隣接サーバの情報も必要な情報となる。
【００３０】
この場合、クライアントから要求に対するノードの検索は以下の手順で行われる。ただし各NMSサーバは、隣接したNMSサーバは既知とする。例えばNMSサーバAは隣接するNMSサーバとして、サーバB、サーバC、サーバDを認識しているものとする。
【００３１】
（Ｓ３１）まず、クライアントがハッシュ値(0.8, 0.9)を持つノードの検索をNMSサーバAに依頼したとする。
（Ｓ３２）NMSサーバAは自己が知らないノードなので、ハッシュ値(0.8, 0.9)と既知のNMSサーバとの距離を計算し、より近いNMSサーバCに探索を依頼する（図５中の矢印Ｌ１）。
（Ｓ３３）NMSサーバCは隣接サーバであるNMSサーバFのことを知っており、ハッシュ値(0.8, 0.9)がNMSサーバFの管理下であることも知っているので、NMSサーバFに探索を依頼する（図５中の矢印Ｌ２）。
（Ｓ３４）NMSサーバFはハッシュ値(0.8, 0.9)のノードが自己の管理下であることを知っており、該当の情報をクライアントに返す（図５中の矢印Ｌ３）。
【００３２】
各NMSサーバが管理する領域をオーバーラップさせ冗長性を持たせる方法としては以下の方法がある。隣接する領域のうち少なくとも一つの領域を管理するようにあらかじめ決めておき、例えば各NMSサーバが図６の“拡張管理領域”のように、（本来の管理領域）＋（少なくとも一つの隣接領域）をカバーするように決めておけば、全てのノードは二つのサーバによって管理されることになる。仮にNMSサーバがダウンしても、当該サーバが管理しているノード情報は、その隣接のNMSサーバが二重に管理しているので、情報が失われることはない。
【００３３】
サーバの追加、削除の手順についても、当該サーバと隣接サーバの概念を利用すると、前述のChordアルゴリズムの場合と同じになる。
【００３４】
以上ノードとしてはネットワークに接続される機器を想定し、かつ常にアップデートされる情報を想定してきたが、最新のアップデートされた情報だけでなく過去の膨大なトレンドデータ等も保管する必要がある、例えばプラント内のフィールド機器、検査装置、更には医療・診断機器、装置およびこれらからの膨大なデータを含めた管理にも本手法は有効である。
【００３５】
以上に説明した本発明の実施の形態では、複数のNMSサーバをクラスタ構成にしたネットワーク管理システムであって、NMSサーバが管理対象であるノードの一覧を分散ハッシュテーブルのアルゴリズムに従って分割生成して該NMSサーバに割り当てるためのテーブルを有し、該テーブルに従って管理すべきノードが割り当てられると共に分散ハッシュテーブルのアルゴリズムに対応したハッシュ空間上に配置され、クライアントからの問い合わせに対して前記アルゴリズムに基づいたノードの検索および他NMSサーバへの問い合わせを実行する。
【００３６】
また、複数のNMSサーバをクラスタ構成にしたネットワーク管理システムであって、DHTのアルゴリズムに従って各NMSサーバが管理すべきノードの範囲を互いにオーバーラップするように配置し、各ノードは少なくとも２台のNMSサーバによって管理されるように構成し冗長性を持たせることにより耐故障性を向上させている。
【００３７】
本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施する
ことができる。そのため、前述の実施の形態は、あらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には、何ら拘束されない。更に、特許請求の範囲の均等範囲に属する全ての変形、様々な改良、代替および改質は、全て本発明の範囲内のものである。
【符号の説明】
【００３８】
１  ネットワーク
２  ノード
３  クライアント
Ａ〜Ｄ  NMSサーバ
【図１】
2010282450.tif 000003
【図２】
2010282450.tif 000004
【図３】
2010282450.tif 000005
【図４】
2010282450.tif 000006
【図５】
2010282450.tif 000007
【図６】
2010282450.tif 000008