JP5895564B2

JP5895564B2 - ネットワーク運用管理システムおよびネットワーク運用管理方法

Info

Publication number: JP5895564B2
Application number: JP2012019883A
Authority: JP
Inventors: 聡一郎佐原
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2012-02-01
Filing date: 2012-02-01
Publication date: 2016-03-30
Anticipated expiration: 2032-02-01
Also published as: JP2013161115A

Description

本発明は、ネットワーク管理システムに関し、特に分散型ネットワーク管理システムおよびネットワーク管理方法に関する。

ネットワーク管理システム（ＮＭＳ）は、構成情報管理、障害監視、性能管理など多様な機能を有する。障害監視の例としては、ＳＮＭＰ（ＳｉｍｐｌｅＮｅｔｗｏｒｋＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）トラップの受信などの受動的なアラート監視や、ＩＣＭＰ（ＩｎｔｅｒｎｅｔＣｏｎｔｒｏｌＭｅｓｓａｇｅＰｒｏｔｏｃｏｌ）エコーによる生存確認、ＳＮＭＰＭＩＢ（ＭａｎａｇｅｍｅｎｔＩｎｆｏｒｍａｔｉｏｎＢａｓｅ：管理情報ベース）のしきい値監視などの能動的なポーリング監視などがある。性能管理の例としては、ＳＮＭＰＭＩＢ値をノードから一定間隔で取得して蓄積し、分析したりグラフ化したりする機能がある。

しかしながら、ネットワーク規模の拡大や、ネットワークの品質に対する要求の高まりに伴い、監視対象や監視項目は増大している。したがって、ＮＭＳが稼働するサーバーの負荷が増大しており、ＮＭＳ自体に対する処理性能や耐故障性の向上の要求が高まっている。この課題に対し、複数のサーバーを導入し、監視負荷を分散させる手法が提案されている。

例えば、特開２００１−１４４７６１号公報では、監視処理を複数の監視サーバーに分散させ、ネットワークの構成情報などの全ての管理情報を全ての監視サーバーで共有する技術が公開されている。これによって、監視処理の負荷分散および耐故障性を図る。しかしながら、この技術では、全ての監視サーバーそれぞれが全ての管理情報を保持するため、各監視サーバーが保持する情報量は、ネットワークの規模拡大に伴って線形的に増え、拡張性に欠ける。特に、アラートログやＭＩＢのログ情報を保持することまで考えると、大規模ネットワークの管理には向かないと言える。

この問題を改善する技術として、特開２０１０−１９８４３４号公報に、収集したログ情報を全体で共有せず、指定のサーバーに保持する技術が開示されている。しかしながら、この技術では、収集されるログ情報が単一のサーバーに保存されるため、耐故障性に難点があり、ログ喪失のリスクがある。

一方、一般的な技術として、コンテンツ管理の負荷分散に分散ハッシュテーブル（ＤｉｓｔｒｉｂｕｔｅｄＨａｓｈＴａｂｌｅ：ＤＨＴ）を用いる技術が知られている。この技術をネットワーク管理に応用した技術が、特開２０１０−２８２４５０号公報に公開されており、ネットワーク規模拡大に対する拡張性や耐故障性を確保できるとされている。しかしながら、この技術では、監視対象の割り振りは、ハッシュ空間上の論理的な距離の近さによって行なわれるため、監視側であるサーバーと、被監視側であるノードとの実際のネットワークの物理的距離が近いことを保証できない。ネットワーク監視にはＳＮＭＰが重要であるが、このプロトコルはＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）上に実装されることが前提になっているため、物理的距離が遠ければ遠いほど、パケットロスによるアラート検出漏れなどのリスクが高くなる。また、監視設定が多くなると、ネットワークの通信帯域を圧迫し、監視パケットが遅延すること等により正常な監視が行えないおそれもある。

特開２００１−１４４７６１号公報特開２０１０−１９８４３４号公報特開２０１０−２８２４５０号公報

本発明は、上述した課題を解決するためになされたものであり、ネットワーク監視の耐故障性および拡張性の向上を実現することを目的とする。

本発明の観点では、ネットワーク運用管理システムは、複数の管理サーバーと、複数の管理サーバーの管理対象である複数の管理対象ノードとを具備する。複数の管理サーバーは、ネットワークの構成を示す構成情報およびネットワーク全体の管理情報を含む更新する頻度の低い低更新頻度情報を分散して保持するＤＨＴ（ＤｉｓｔｒｉｂｕｔｅｄＨａｓh Ｔａｂｌｅ）のデータ保有ノードである。複数の管理サーバーは、各々に物理的に近い位置の管理対象ノードを監視した結果を示すアラートログおよびＭＩＢ（ＭａｎａｇｅｍｅｎｔＩｎｆｏｒｍａｔｉｏｎＢａｓｅ）のログを含む高更新頻度情報を保持する。

本発明の他の観点では、ネットワークの分散運用管理方法は、ネットワークの構成を示す構成情報およびネットワーク全体の管理情報を含む更新する頻度の低い低更新頻度情報を複数の管理サーバー上に形成されるＤＨＴ（ＤｉｓｔｒｉｂｕｔｅｄＨａｓh Ｔａｂｌｅ）上に保持するステップと、ネットワークの物理的配置に基づいて、物理的に近い位置の管理対象ノードの管理を複数の管理サーバーのそれぞれに割当てるステップと、管理対象ノードを監視した結果を示すアラートログおよびＭＩＢ（ＭａｎａｇｅｍｅｎｔＩｎｆｏｒｍａｔｉｏｎＢａｓｅ）のログを含む更新頻度の高い高更新頻度情報を前記管理対象ノードに物理的に近い位置の管理サーバーに保存して複数の管理サーバーのそれぞれの負荷を分散するステップとを備える。

ネットワーク規模の拡大に合わせて、耐故障性を保ちつつ柔軟に拡張可能な分散型ネットワーク運用管理システムを提供することができる。

図１は、本発明の実施の形態に係るネットワーク運用管理システムの構成を示す図であり、管理サーバーの監視範囲を示す。図２は、本発明の実施の形態に係るネットワークの拡大を説明する図である。図３は、本発明の実施の形態に係る拡大したネットワークの監視範囲の分割を説明する図である。図４は、本発明の実施の形態に係る管理サーバー間のデータの同期を説明する図である。図５は、本発明の実施の形態に係る管理サーバーの物理的接続構成と論理的接続構成を説明する図である。図６は、本発明の実施の形態に係るＤＨＴ上の情報の例を示す図である。図７は、本発明の実施の形態に係る管理サーバーの追加手順を示す図である。図８は、本発明の実施の形態に係る管理サーバーの離脱手順を示す図である。図９は、本発明の実施の形態に係る管理対象ノードの追加手順を示す図である。図１０は、本発明の実施の形態に係る管理対象ノードの削除手順を示す図である。図１１は、本発明の実施の形態に係る監視範囲の見直し手順を示す図である。図１２は、本発明の実施の形態に係るポーリング監視の手順を示す図である。

図面を参照して、本発明を実施するための形態を説明する。

本発明の実施の形態に係るネットワーク運用管理システムでは、図１に示されるように、ネットワークの管理対象ノードを複数の管理サーバーが分割して管理する。ここでは、ネットワークは、管理対象ノード３１〜３５と、管理対象ノード３１〜３５を監視する管理サーバー１１、１２および管理端末１９を備える。管理サーバー１１は、監視範囲２１に含まれる管理対象ノード３１、３２を監視する。管理サーバー１２は、監視範囲２０に含まれる管理対象ノード３３、３４、３５を監視する。管理端末１９は、管理対象ノード３１に接続される。ネットワーク管理者は、管理端末１９から各管理サーバー１１、１２に処理を指示し、管理情報を取得して、ネットワーク状態の閲覧や管理を行なうことができる。管理端末１９は、ネットワークの任意の場所に接続できる。各管理サーバー１１、１２が管理する管理対象ノード３１〜３５すなわち監視範囲は、ネットワークの物理的構成に基づいて決定される。管理サーバー１１、１２は、物理的に近い位置の管理対象ノード３１〜３５を分担して監視する。

図２に示されるように、管理サーバー１２の監視範囲２０に管理対象ノード３６が追加され、ネットワークの規模が増大して管理サーバーの負荷が高くなると、負荷の高い管理サーバー１２の近傍に新しい管理サーバー１３が追加される。管理サーバー１３が追加されると、負荷を分散するように自動で管理範囲の再設定が行われる。すなわち、図３に示されるように、監視範囲２０は、監視範囲２２、２３に分割され、管理サーバー１２は監視範囲２２に含まれる管理対象ノードを監視し、管理サーバー１３は監視範囲２３に含まれる管理対象ノードを監視するように再設定される。すなわち、管理サーバー１２の負荷が管理サーバー１３の追加により分散される。

なお、この自動負荷分散は、管理サーバーの追加のときだけでなく、定期的に行われるように構成することも可能である。したがって、監視負荷が設定変更等によって変化した場合でも、時間経過とともに、管理サーバーの負荷を平準化することができる。

また、図４に示されるように、管理情報やログ情報は、複数の管理サーバーで同期化される。したがって、これらのデータは冗長性を有することになり、耐故障性を確保することができる。データを同期させる管理サーバーは、それぞれの管理サーバーのネットワーク上の物理的近傍に位置する複数台とする。同期する管理サーバーの範囲を限定することによって、各管理サーバーが保持するデータ量が、ネットワーク全体に存在する管理サーバーの数に影響されないようになり、ネットワークの負荷が広範囲に波及することを防止できる。このように、データが冗長性を有することにより、管理サーバーが故障したときには、近傍サーバーとしてデータを同期している管理サーバーが、故障した管理サーバーの監視範囲を引き継ぐことが容易になり、耐故障性が確保される。

ネットワーク運用管理システムにおいて、ユーザーはネットワーク上の任意の地点から所望の情報を有する管理対象ノードをアクセスして情報を閲覧することができる。すなわち、管理サーバー１１〜１４は、図５（ａ）に示されるように、伝送路を介して互いにデータを授受できるように物理的に接続されていることになる。そして、全ての管理サーバー１１〜１４は、ネットワーク構成等の情報を分散して有し、分散ハッシュテーブル（ＤＨＴ）を形成する。

このＤＨＴには、管理対象ノード３１〜３８を示す情報をキーとして、その管理対象ノード３１〜３８を監視する管理サーバー１１〜１４に関する情報等をデータ値とする組情報が保持される。ＤＨＴのアルゴリズムは、Ｃｈｏｒｄ、ＣＡＮ、Ｐａｓｔｒｙ等が知られるが、例えば、Ｃｈｏｒｄアルゴリズムを用いると、図５（ｂ）に示されるように、各管理サーバー１１〜１４はハッシュＩＤ空間に位置付けされる。したがって、各管理サーバー間のハッシュＩＤ空間における論路的距離と、ネットワーク上の物理的距離とは異なる。

ネットワーク管理者が、本ネットワーク運用管理システムに接続される管理端末１９によって所望の管理対象ノード（例えば管理対象ノード３３）に関する情報を取得するためには、まず任意の管理サーバー（例えば管理サーバー１１）に問い合わせてＤＨＴ上の情報探索を行なう。管理サーバー１１は、ＤＨＴ上で管理サーバー１３、１２を順に探索し、所望の管理対象ノード３３を管理している管理サーバー１２を特定する。ネットワーク管理者は、特定された管理サーバーに管理端末１９を用いて問い合わせ、所望の管理対象ノード３３に関する情報を取得する。管理対象ノード３３に関する情報は、管理端末１９に表示される。新たな監視設定の投入の手続きも上記の情報の取得の手続きと同様の手続きで行われる。

例えば、図４に示されるようなネットワーク構成の場合、ＤＨＴには、図６に示されるような情報が格納される。図４に示されるネットワークには監視対象となる管理対象ノード３１〜３８が接続されている。また、管理サーバー１１〜１４が接続されている。管理対象ノード３１〜３８は、管理サーバー１１〜１４のいずれかに管理される。図４に示されるネットワーク構成では、管理対象ノード３１〜３２は管理サーバー１１に、管理対象ノード３３〜３４は管理サーバー１２に、管理対象ノード３５〜３６は管理サーバー１３に、管理対象ノード３７〜３８は管理サーバー１４によって管理されている。ネットワーク状態の閲覧や管理のために、管理端末（Ｔ）１９が接続されている。管理端末１９は、ネットワークの任意の場所に接続できる。

ＤＨＴ上に保持される情報は、図６のような形態となる。図６には、図４に示されるネットワーク構成を例としたデータ一覧である。管理対象ノードまたは管理サーバーを示す情報をキーとして各種情報を引き出すことができる。キーとする情報は、例えばＩＰアドレスのような、管理対象ノードおよび管理サーバーを一意に識別可能な情報が使用される。

キーによって検索できるデータ値は、複数の情報を組み合わせたものとなる。キーが管理対象ノードを示す場合、その管理対象ノードを管理する管理サーバー（管理サーバー列）、他の管理対象ノードや管理サーバーとの接続状態を示す接続情報リスト（隣接ノード列）等が得られる。キーが管理サーバーを示す場合、管理サーバーが管理する管理対象ノードのリスト（管理ノード列）、管理情報を同期する近傍サーバーのリスト（近傍サーバー列）、他の管理対象ノードや管理サーバーとの接続状態を示す接続情報リスト（隣接ノード列）等が得られる。

本発明における各種動作について説明する。

（管理サーバーの追加）
ネットワーク管理サーバーを新規に追加する場合、図７に示されるように処理される。ここでは、図１から図３に示されるように、管理対象ノード３６が増設され、管理サーバー１２の負荷が増加したため、管理サーバー１３を追加して監視範囲を分割する場合を例示する。

（ステップＳ１１）ネットワーク管理者は、管理端末１９を用いて新しい管理サーバー１３をＤＨＴシステムの構成ノードとして登録する。ＤＨＴへの登録処理の手続き（プロトコル）の詳細は、使用されるＤＨＴの仕様に規定されるものとし、ここでは詳細について言及しない。

（ステップＳ１２）ネットワーク管理者は、管理端末１９を用いて新しい管理サーバー１３を示す情報をキーとしたデータ行を生成してＤＨＴに入力する。新しく生成したデータ行の隣接ノード列には、新しい管理サーバー１３に直接接続される各ノードの接続情報が入力される。新しい管理サーバー１３は、図２に示されるように、管理対象ノード３５に直接接続される。したがって、管理サーバー１３の隣接ノード列には管理対象ノード３５を示す情報が格納される。

（ステップＳ１３）新しい管理サーバー１３は、ネットワーク上の物理的距離が近い別の管理サーバー（以後、近傍サーバーと称する）を最大Ｎ台探す。近傍サーバーの探索は、ＤＨＴ上に保持されている隣接ノード情報に基づいて、ダイクストラ法などのアルゴリズムで行う。近傍サーバーが発見されると、発見された近傍サーバーの情報は、ＤＨＴ上の新しい管理サーバー１３の近傍サーバー列に保存される。

（ステップＳ１４）新しい管理サーバー１３の近傍サーバーとなった管理サーバー１２は、ステップＳ１３の要領でその近傍サーバーを再探索する。管理サーバー１２の近傍に更新があると、ＤＨＴ上の近傍サーバー列の情報を更新し、管理サーバー１２および新しい近傍サーバーの間で管理対象ノードに関するデータの同期を行う。ここでは、管理サーバー１３が追加されているので、管理サーバー１２の近傍サーバー列に管理サーバー１３を示す情報が追加される。

（ステップＳ１５）ステップＳ１４において、近傍サーバーの情報が変更された管理サーバー（例えば管理サーバー１２）は、近傍サーバーの情報に追加または削除された管理サーバー（例えば管理サーバー１３）に対して、ステップＳ１４、Ｓ１５を実行するように通知する。例えば、次は管理サーバー１３がステップＳ１４、Ｓ１５を実行する。

（ステップＳ１６）近傍サーバーの情報の更新がネットワークを管理する管理サーバー全体で収束すると、管理サーバーの追加処理は終了する。

（管理サーバーの離脱）
管理サーバーがシステムから離脱する契機は、計画された離脱と、障害等による予期せぬ離脱の二通りがある。本発明では、ＤＨＴ上で各管理サーバー同士が定期的に生存確認を行うことによって、予期せぬ離脱を検知する。障害発生が検知できれば、予期せぬ離脱も計画された離脱と同じ手順で処理できる。管理サーバーの離脱は、図８に示されるように、処理される。

（ステップＳ２１）離脱する管理サーバーは、監視する管理対象ノードの管理を離脱する管理サーバーの近傍サーバーのいずれか一つに委譲する。登録されている近傍サーバーから、管理を委譲する管理サーバーを選択する方法は、単純にリストの先頭に登録されている近隣サーバーを選択してもよいし、委譲後の監視負荷が最小になるように監視負荷に基づいて選択してもよい。

（ステップＳ２２）離脱する管理サーバーの近傍サーバーとして登録されている管理サーバーは、前述の管理サーバーの追加の場合と同じように、近傍サーバー情報を更新する。すなわち、近傍サーバーとして登録されている管理サーバーは、ネットワーク上の物理的距離が近い別の管理サーバー（近傍サーバー）を最大Ｎ台探す。近傍サーバーとして別の管理サーバーが発見されると、発見された近傍サーバーの情報は、ＤＨＴ上の近傍サーバー列に保存される（ステップＳ１３に対応）。

（ステップＳ２３）近傍サーバーとして追加または削除された管理サーバーは、ステップＳ２２の要領でさらにその近傍サーバーを再探索する。近傍に更新があると、その管理サーバーは、ＤＨＴ上の近傍サーバー列の情報を更新し、管理対象ノードに関するデータのコピーを行う（ステップＳ１４に対応。前述と同様、どのデータをどこにコピーするのか不明）。

（ステップＳ２４）ステップＳ２３において、近傍サーバーの情報が変更された管理サーバーは、その近傍サーバー情報に追加または削除された管理サーバーに対して、ステップＳ２３、Ｓ２４を実行するように通知する。

（ステップＳ２５）離脱対象である管理サーバーをＤＨＴから離脱させる。なお、ＤＨＴからの離脱処理の詳細は、各ＤＨＴによるものとし、本発明では言及しない。

（管理対象ノードの追加）
管理対象ノードを追加する場合、図９に示されるように処理する。

（ステップＳ３１）ネットワーク管理者は、管理端末を用いて追加される管理対象ノードを示す情報をキーとしたデータ行を生成しＤＨＴに入力する。新しく生成された行の隣接ノード列には、追加される管理対象ノードに直接接続される管理対象ノードの接続情報が入力される。

（ステップＳ３２）追加される管理対象ノードに直接接続される各管理対象ノードは、各管理対象ノードを管理する管理サーバーと管理対象ノードとのネットワーク上の距離を計算する。なお、各管理対象ノードを管理する管理サーバーに関する情報は、ノード情報をキーとしてＤＨＴに問い合わせることにより取得できる。また、ネットワーク上の物理的距離は、ＤＨＴに保持されているネットワーク接続関係の情報に基づいて、ダイクストラ法などのアルゴリズムを用いて計算することができる。

（ステップＳ３３）追加される管理対象ノードとの距離が最も近い管理サーバーを、追加される管理対象ノードを管理する管理サーバーとしてＤＨＴの情報が更新される。すなわち、管理対象ノードの情報を検索キーとする行を新規に追加し、管理サーバー列、隣接ノード列にそれぞれ情報が登録される。また、管理対象ノードに隣接する隣接ノードを示す情報をキーとする行にある隣接ノード列の情報を更新する。また、管理対象ノードを管理する管理サーバーの情報を検索キーとする行にある管理ノード列の情報を更新する。

なお、この追加方法では、追加する管理対象ノードと管理サーバーとが、必ずしも最近傍の関係ではない可能性があるが、距離が近ければ最近傍でなくてもよい。また、管理対象ノードの追加により、管理サーバー間に負荷の偏りが発生しても、後述する管理範囲の定期な見直し処理により、負荷が平準化される。

（管理対象ノードの削除）
管理中のノードを管理対象から外す（削除する）場合、図１０に示されるように処理する。

（ステップＳ４１）ネットワーク管理者は、管理端末１９から削除する管理対象ノードを示す情報を検索キーにしてＤＨＴに問い合わせ、管理対象ノードを管理する管理サーバーに関する情報を取得する。

（ステップＳ４２）ネットワーク管理者は、検索によって取得した管理サーバーに所望の管理対象ノードの削除を要求する削除要求を送る。

（ステップＳ４３）要求を受けた管理サーバーは、管理対象ノードを管理する管理情報を削除する。

（ステップＳ４４）さらに管理サーバーは、更新後の情報を近傍サーバーとして登録されている管理サーバー全てに通知して同期する。

（ステップＳ４５）管理サーバーは、管理対象ノードを示す情報をキーとしてＤＨＴ上の情報を削除する。また、管理対象ノードに隣接する隣接ノードを示す情報をキーとするデータの隣接ノード列を更新する。また、管理対象ノードの管理サーバーを示す情報をキーとするデータの管理ノード列を更新する。管理対象ノードを削除することにより、管理サーバー間に負荷に偏りが出ても、後述する管理範囲の定期な見直しにより負荷が平準化される。そのため、ここでは負荷見直しをしない。

（監視範囲の見直し）
本発明では、管理サーバー間で管理負荷に大きな偏差がないように、定期的に管理対象ノードを監視する範囲を見直す。管理対象ノードの監視範囲の見直しは、図１１に示されるように、定期的に実行される。

（ステップＳ５１）各管理サーバーは、それぞれその時点における監視負荷を計算する。

（ステップＳ５２）各管理サーバーは、それぞれの近傍サーバーの監視負荷を取得する。

（ステップＳ５３）各管理サーバーは、自身と各近傍サーバーとの監視負荷の平均を算出し、それぞれの監視負荷が、算出された平均に近づくように、それぞれが監視する管理対象ノードを分担し合う。

（ポーリング監視）
上述のように構成されるシステム上では、ある管理対象ノードに対するポーリング監視は、図１２に示されるように行われる。

（ステップＳ６１）管理サーバーは、監視範囲内の管理対象ノードに対して監視パケットを送出する。

（ステップＳ６２）管理対象ノードから結果が返送されると、管理サーバーはその結果を保存する。

（ステップＳ６３）管理サーバーは、その近傍サーバーに管理対象ノードから返送された結果を転送し、データを同期する。管理サーバーは、ＳＮＭＰトラップの受信等のパッシブ監視も同様に、受信するとその受信結果を近傍サーバーに転送し、データを同期する。

上述のように、本実施の形態に係るネットワーク運用管理システムでは、各ノードの情報はある特定の複数台のサーバーにのみ配置されているため、管理端末から情報を閲覧するためには、まず管理サーバーを特定する。ＤＨＴ上には、管理対象ノードを示す情報をキーとする、その管理対象ノードの情報を管理している管理サーバーのリストが保持されている。したがって、管理対象ノードを示す情報をキーとしてＤＨＴに問い合わせることにより、その管理対象ノードを管理する管理サーバーの情報が得られる。管理サーバーが判明すれば、その管理サーバーに問い合わせ、情報が得られる。

管理対象ノードを示す情報をキーとしてＤＨＴに問い合わせると、管理サーバーの情報が得られるが、さらに、その管理サーバーを示す情報をキーとしてＤＨＴに問い合わせることにより、近傍サーバー、つまり所望の管理対象ノードの情報を保持している全ての管理サーバーのリストが得られる。管理端末は、情報取得の際、このリストから任意のサーバーを選んでよい。例えば、ネットワーク上の近い管理サーバーを選択すると、情報取得の際の通信コストを抑えることもできる。

上述のように、本発明では、ネットワーク構成情報およびシステム全体の管理情報などの更新頻度の低い低更新頻度情報を、複数の管理サーバーに形成されるＤＨＴ上に保持する。また、ネットワークの物理的配置に基づいて、各管理サーバーに管理対象ノードの管理を割り当て、監視の結果であるアラートログやＭＩＢのログなどの更新頻度の高い高更新頻度情報をネットワーク上の物理的に近い位置の管理サーバーに保存する。したがって、ネットワーク規模が増大した場合でも、管理サーバーを増設するだけで各サーバーの負荷を分散することができる。さらに、ネットワーク上の物理的に近い位置の管理サーバー同士で監視の結果情報を同期して保持し、管理サーバーが故障した場合に、物理的に近い位置の管理サーバーが代りに監視を継続することができ、耐障害性を確保することができる。上述の実施の形態では、ＤＨＴのアルゴリズムとしてＣｈｏｒｄを例に挙げたが、他のＤＨＴアルゴリズムを使用して構成してもよい。

すなわち、本発明によれば、管理するネットワークの規模に合わせて管理サーバーを設置することにより自動的に監視負荷の分散を行うことができ、拡張性の高いネットワーク管理が実現できる。また、ネットワーク上の近いサーバー間で同期して保持することによって監視情報の冗長化を行ない、管理サーバーの障害時にも監視を継続することができ、障害に強いネットワーク管理が実現できる。

以上、実施の形態を参照して本願発明を説明したが、上記実施の形態は、矛盾のない限り組み合わせて実施可能である。また、本願発明は上記実施の形態に限定されるものではなく、本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

１１〜１４管理サーバー
１９管理端末
２０〜２４監視範囲
３１〜３８管理対象ノード

Claims

低更新頻度情報を分散して保持するＤＨＴ（ＤｉｓｔｒｉｂｕｔｅｄＨａｓｈＴａｂｌｅ）のデータ保有ノードである複数の管理サーバーと、ここで、前記低更新頻度情報は、ネットワークの構成を示す構成情報および前記ネットワーク全体の管理情報を含んでおり、
前記複数の管理サーバーの管理対象である複数の管理対象ノードと
を具備し、
前記複数の管理対象ノードの各々は、前記ネットワークの物理的配置に基づいて、複数の監視グループのいずれかに割当てられており、
前記複数の管理サーバーの各々は、前記複数の監視グループのうちで自身が属する監視グループに含まれる管理対象ノードを監視し、前記複数の監視グループのうちで自身に隣接する監視グループの管理サーバーによる監視結果を示すアラートログおよびＭＩＢ（ＭａｎａｇｅｍｅｎｔＩｎｆｏｒｍａｔｉｏｎＢａｓｅ）のログを含む高更新頻度情報を保持する
ネットワーク運用管理システム。
前記複数の管理サーバーの各々は、自身に隣接する監視グループの管理サーバーによる監視結果を当該隣接する監視グループの管理サーバーと同期して保持し、
前記複数の管理サーバーのうち、第１監視グループの第１管理サーバーが故障した場合、前記第１管理サーバーの代わりに、前記第１監視グループに隣接する第２監視グループの第２管理サーバーが監視を継続する
請求項１に記載のネットワーク運用管理システム。
前記ＤＨＴは、データ行およびデータ列で構成されており、
前記データ列は、近傍サーバー列および隣接ノード列を含み、
前記ネットワークに第３管理サーバーが追加されるとき、
前記第３管理サーバーを示す情報をキーとする第１データ行が前記ＤＨＴに生成され、
前記第３管理サーバーに直接接続される隣接ノードを示す情報が前記第１データ行の前記隣接ノード列に格納され、
前記複数の管理サーバーのうち、前記第３管理サーバーが属する監視グループに隣接する所定数の監視グループの管理サーバーを示す情報が前記第１データ行の前記近傍サーバー列に格納される
請求項２に記載のネットワーク運用管理システム。
前記複数の管理サーバーのうちの第４管理サーバーが前記ネットワークから離脱するとき、
前記第４管理サーバーは、前記第４管理サーバーが監視する管理対象ノードの管理を、前記ＤＨＴの前記第４管理サーバーを示す情報をキーとする第２データ行の前記近傍サーバー列に格納される第５管理サーバーに委譲し、
前記複数の管理サーバーのうち、前記第４管理サーバーを近傍サーバーとしている管理サーバーは、前記第２データ行における前記近傍サーバー列の情報を更新する
請求項３に記載のネットワーク運用管理システム。
前記複数の管理サーバーの各々は、定期的に自身の監視負荷を計算して、前記複数の管理サーバーのうち、自身に隣接する監視グループの管理サーバーの監視負荷を取得し、前記自身の監視負荷と前記自身に隣接する監視グループの管理サーバーの監視負荷との平均に近づくように、監視する前記複数の管理対象ノードを分担する
請求項１から請求項４のいずれかに記載のネットワーク運用管理システム。
複数の管理サーバーと、前記複数の管理サーバーの管理対象である複数の管理対象ノードとを用いるネットワーク運用管理方法であって、
更新する頻度の低い低更新頻度情報を前記複数の管理サーバー上に形成されるＤＨＴ（ＤｉｓｔｒｉｂｕｔｅｄＨａｓｈＴａｂｌｅ）上に保持するステップと、ここで、前記低更新頻度情報は、ネットワークの構成を示す構成情報および前記ネットワーク全体の管理情報を含んでおり、
前記ネットワークの物理的配置に基づいて、前記複数の管理対象ノードの各々を複数の監視グループのいずれかに割当てるステップと、
前記複数の監視グループのうちで自身が属する監視グループの管理対象ノードを監視するステップと、
前記複数の監視グループのうちで自身に隣接する監視グループの管理サーバーによる監視結果を示すアラートログおよびＭＩＢ（ＭａｎａｇｅｍｅｎｔＩｎｆｏｒｍａｔｉｏｎＢａｓｅ）のログを含む高更新頻度情報を保持するステップと
を備える
ネットワーク運用管理方法。
前記ＤＨＴは、データ行およびデータ列で構成されており、
前記データ列は、近傍サーバー列および隣接ノード列を含み、
前記ネットワーク運用管理方法は、前記ネットワークに第１管理サーバーを追加するステップを更に備え、
前記追加するステップは、
前記第１管理サーバーを示す情報をキーとする第１データ行を前記ＤＨＴに生成するステップと、
前記第１管理サーバーに直接接続される隣接ノードを示す情報を前記第１データ行の前記隣接ノード列に格納するステップと、
前記複数の管理サーバーのうち、前記第１管理サーバーが属する監視グループに隣接する所定数の監視グループの管理サーバーを示す情報を前記第１データ行の前記近傍サーバー列に格納するステップと
を含む
請求項６に記載のネットワーク運用管理方法。
前記複数の管理サーバーのうちの第２管理サーバーを前記ネットワークから削除するステップをさらに備え、
前記削除するステップは、
前記第２管理サーバーが監視する管理対象ノードの管理を、前記ＤＨＴの前記第２管理サーバーを示す情報をキーとする第２データ行の前記近傍サーバー列に格納される第３管理サーバーに委譲するステップと、
前記複数の管理サーバーのうち、前記第２管理サーバーを近傍サーバーとしている管理サーバーを示す情報をキーとする前記第２データ列における前記近傍サーバー列の情報を更新するステップと
を含む
請求項７に記載のネットワーク運用管理方法。
定期的に前記管理対象ノードを監視する範囲を見直すステップを更に備え、
前記見直すステップは、
定期的に前記複数の管理サーバーの各々の監視負荷を計算するステップと、
前記複数の監視グループのうち、自身に隣接する監視グループの管理サーバーの監視負荷を取得するステップと、
前記複数の管理サーバーの各々の監視負荷と前記自身に隣接する監視グループの管理サーバーの監視負荷との平均に近づくように、監視する前記複数の管理対象ノードを分担するステップと
を含む
請求項７または請求項８に記載のネットワーク運用管理方法。
請求項６から請求項９のいずれかに記載のネットワーク運用管理方法をコンピュータに実行させるためのプログラム。