(57)【要約】  申請元ノード（Ｎ１）が監視対象ノード（Ｎ２）に購読申請を行なった場合に、申請元ノード（Ｎ１）と監視対象ノード（Ｎ２）を相互接続するとともに、監視対象ノード（Ｎ２）を監視ノード（Ｎ３）によって監視させる。申請元ノード（Ｎ１）は、監視対象ノード（Ｎ２）からの直接の応答と監視ノード（Ｎ３）からの通知とを組み合わせて監視対象ノード（Ｎ２）の生死を判定する。このため、管理対象の状態変化を迅速に把握し、また、監視対象ノード（Ｎ２）のダウンと、ネットワークのダウンとを区別することができる。
2012070155.tif 000002
【特許請求の範囲】
【請求項１】
監視対象のノードに対して生死情報の購読を申請する申請元ノードと、
前記購読の申請を受けて申請元ノードと相互接続するとともに、自ノードをルーティングテーブルに有するノードに自ノードの監視および監視結果の前記申請元ノードへの通知を依頼する監視対象ノードと、
前記監視対象ノードからの依頼を受けて前記監視対象ノードを監視し、監視対象ノードからの応答が停止した場合に前記申請元ノードに通知する監視ノードと、を備え、
前記申請元ノードは、前記監視対象ノードとの通信が途絶え、且つ前記監視ノードから通知を受けた場合に前記監視対象ノードが停止したと判定することを特徴とする管理システム。
【請求項２】
前記申請元ノード、前記監視対象ノードおよび前記監視ノードは、分散ハッシュを用いたオーバーレイネットワーク上のノードであることを特徴とする請求項１に記載の管理システム。
【請求項３】
前記申請元ノードは、前記監視対象ノードとの通信が途絶え、且つ監視ノードから通知がない場合には、監視対象ノードとの通信回線に問題が発生したと判定することを特徴とする請求項１または２に記載の管理システム。
【請求項４】
監視対象のノードに対して生死情報の購読を申請する購読申請部と、
他のノードから購読の申請を受けた場合に申請元ノードと相互接続するとともに、自ノードをルーティングテーブルに有するノードに自ノードの監視および監視結果の前記申請元ノードへの通知を依頼する監視依頼部と、
他のノードから監視および監視結果の申請元ノードへの通知の依頼を受けた場合に、当該ノードを監視し、当該ノードからの応答が停止した場合に前記申請元ノードに通知する監視部と、
前記監視対象ノードとの通信が途絶え、且つ前記監視対象ノードを監視する監視ノードから通知を受けた場合に前記監視対象ノードが停止したと判定する判定部と、
を備えたことを特徴とする管理装置。
【請求項５】
申請元ノードが監視対象のノードに対して生死情報の購読を申請するステップと、
監視対象ノードが前記購読の申請を受けて申請元ノードと相互接続するとともに、自ノードをルーティングテーブルに有するノードに自ノードの監視および監視結果の前記申請元ノードへの通知を依頼するステップと、
監視ノードが前記監視対象ノードからの依頼を受けて前記監視対象ノードを監視し、監視対象ノードからの応答が停止した場合に前記申請元ノードに通知するステップと、
前記申請元ノードが、前記監視対象ノードとの通信が途絶え、且つ前記監視ノードから通知を受けた場合に前記監視対象ノードが停止したと判定するステップと、
を含んだことを特徴とする管理方法。
【請求項６】
監視対象のノードに対して生死情報の購読を申請する購読申請手順と、
他のノードから購読の申請を受けた場合に申請元ノードと相互接続するとともに、自ノードをルーティングテーブルに有するノードに自ノードの監視および監視結果の前記申請元ノードへの通知を依頼する監視依頼手順と、
他のノードから監視および監視結果の申請元ノードへの通知の依頼を受けた場合に、当該ノードを監視し、当該ノードからの応答が停止した場合に前記申請元ノードに通知する監視手順と、
前記監視対象ノードとの通信が途絶え、且つ前記監視対象ノードを監視する監視ノードから通知を受けた場合に前記監視対象ノードが停止したと判定する判定手順と、
をコンピュータに実行させることを特徴とする管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理システム、管理装置、管理方法および管理プログラムに関する。
【背景技術】
【０００２】
従来、大規模なネットワークシステムを管理するには、運用管理用の装置である運用管理マネージャを階層化する技術が用いられてきた。このような大規模システム環境の管理の一例としては、大規模データセンタ等の分散コンピュータシステムの運用管理がある。また、ネットワーク上のノードの生死を監視する技術が各種知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１１−８５６４９号公報
【特許文献２】特開２００９−７７２１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
運用管理マネージャを階層化して大規模データセンタ等のネットワークを運用管理する場合には、例えばポーリングおよびＳＮＭＰ（Simple  Network  Management  Protocol）  Trapによる生死イベントは、各階層のマネージャに順次伝送される。このため、生死イベントの検出にタイムラグが生じるという問題点があった。また、マネージャから管理対象への定期的なポーリングのために、マネージャのＣＰＵ（Central  Processing  Unit）使用率とネットワークトラフィックが増大していた。【０００５】
開示の技術は、上記に鑑みてなされたものであって、管理対象の状態変化を迅速に把握する管理システム、管理装置、管理方法および管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本願の開示する管理システム、管理装置、管理方法および管理プログラムは、申請元ノードが監視対象のノードに対して生死情報の購読を申請すると、監視対象ノードは申請元ノードと相互接続するとともに、自ノードをルーティングテーブルに有するノードに自ノードの監視および監視結果の申請元ノードへの通知を依頼する。監視対象ノードからの依頼を受けた監視ノードは監視対象ノードを監視し、監視対象ノードからの応答が停止した場合に申請元ノードに通知する。申請元ノードは、監視対象ノードとの通信が途絶え、且つ監視ノードから通知を受けた場合に監視対象ノードが停止したと判定する。
【発明の効果】
【０００７】
本願の開示する管理システム、管理装置、管理方法および管理プログラムによれば、管理対象の状態変化を迅速に把握することができる。
【図面の簡単な説明】
【０００８】
【図１】図１は、本実施例に係る管理システムの説明図である。
【図２】図２は、本実施例に係るネットワークの説明図である。
【図３】図３は、本実施例にかかる管理装置の構成図である。
【図４】図４は、管理プログラムによる実施についての説明図である。
【図５】図５は、階層化した管理の説明図である。
【図６】図６は、サーバのハードウェアと管理プログラムの関係についての説明図である。
【図７】図７は、オーバーレイネットワークの説明図である。
【図８】図８は、ハッシュテーブルの定義の具体例についての説明図である。
【図９】図９は、図３に示したセルフノードテーブルｔ２の具体例である。
【図１０】図１０は、図３に示したドメインテーブルｔ3の具体例である。
【図１１】図１１は、図３に示したノード管理テーブルｔ４の具体例である。
【図１２】図１２は、図３に示したルーティングテーブルｔ５の具体例である。
【図１３】図１３は、申請元ノードの処理動作を説明するフローチャートである。
【図１４】図１４は、監視対象ノードの処理動作を説明するフローチャートである。
【図１５】図１５は、監視ノードの処理動作を説明するフローチャートである。
【発明を実施するための形態】
【０００９】
以下に、本発明にかかる管理システム、管理装置、管理方法および管理プログラムの実施例を図面に基づいて詳細に説明する。なお、本実施例は開示の技術を限定するものではない。
【実施例】
【００１０】
図１は、本実施例に係る管理システムの説明図である。図１に示したノードＮ１は、監視対象のノードＮ２に対して生死情報の購読を申請する購読申請部ｍ３１を有する申請元ノードであり、購読申請部ｍ３１に加えて判定部ｍ３４を有する。【００１１】
監視対象ノードであるノードＮ２は、ノードＮ１から購読の申請を受けてノードＮ１と相互接続するとともに、自ノードをルーティングテーブルに有するノードＮ３に自ノードの監視および監視結果の申請元ノードＮ１への通知を依頼する監視依頼部ｍ３２を有する。【００１２】
ノードＮ３は、監視対象ノードＮ２からの依頼を受けて監視対象ノードＮ２を監視し、監視対象ノードＮ２からの応答が停止した場合に申請元ノードＮ１に通知する監視部ｍ３３を有する監視ノードである。【００１３】
申請元ノードＮ１の判定部ｍ３４は、監視対象ノードＮ２との通信が途絶え、且つ監視ノードＮ３から通知を受けた場合に監視対象ノードＮ２が停止したと判定する。【００１４】
また、判定部ｍ３４は、監視対象ノードＮ２との通信が途絶えた場合であって、監視ノードＮ３から通知がない場合には監視対象ノードＮ２との通信回線に問題が発生したと判定する。【００１５】
このように、申請元ノードＮ１は、監視対象ノードＮ２と相互接続するとともに、監視対象ノードＮ２を監視ノードＮ３によって監視させ、ノードＮ２からの直接の応答と監視ノードＮ３からの通知とを組み合わせて判定する。【００１６】
このため、生死イベントは、階層化された管理マネージャを経由するのではなく、直接管理対象からマネージャに送付されるので、タイムラグを抑え、管理対象の状態変化を迅速に把握できる。マネージャは、他の管理対象の提供する生死監視サービスを購読することで、管理対象から生死イベントを入手できる。また、マネージャは、生死監視サービスが必要でなくなれば、いつでも購読を停止できる。以上のような管理システムにより、マネージャから管理対象へのポーリングの必要はなくなり、生死イベントをメッセージとして受け取れるので、マネージャのＣＰＵ使用率とネットワークトラフィックを抑えることができる。また、監視対象ノードＮ２のダウンと、ネットワークのダウンとを区別することができる。【００１７】
図１では、申請元ノード、監視対象ノード、監視ノードを区別して説明したが、各ノードは、申請元ノード、監視対象ノード、監視ノードのいずれとしても動作することが好適である。【００１８】
図２は、本実施例に係るネットワークの説明図であり、図３は、本実施例にかかる管理装置の構成図である。図１に示したように、管理対象装置ｎ１〜４は、ネットワークを介して接続されている。このネットワークが監視対象のネットワークとなる。【００１９】
管理対象装置ｎ１には、管理装置ｍ１が接続され、管理対象装置ｎ２には、管理装置ｍ２が接続され、管理対象装置ｎ３には、管理装置ｍ３が接続されている。管理装置ｍ１〜４は、管理対象装置ｎ１〜４のネットワークインタフェースを利用して、管理対象装置ｎ１〜４が属するネットワークに対してオーバーレイネットワークを構築する。管理装置ｍ１〜４は、このオーバーレイネットワークのノードとして機能し、互いに通信可能である。【００２０】
管理装置ｍ１〜４は、同一の構成を有するので、以降の説明では管理装置ｍ１を例に説明を行なう。管理装置ｍ１は、生死監視部ｍ３０、オーバーレイネットワーク構築部ｍ１１を有する。【００２１】
より詳細には、図２に示したように、管理装置ｍ１は、オーバーレイネットワーク構築部ｍ１１、管理対象検索部ｍ１２、管理情報作成部ｍ１３および生死監視部ｍ３０を有する。また、管理装置ｍ１は、ＳＡＮ（Storage  Area  Network）と接続し、ＳＡＮに後述する各種情報を保持させる。【００２２】
オーバーレイネットワーク構築部ｍ１１は、管理対象のネットワークに対してオーバーレイネットワークを構築する処理部であり、通信処理部ｍ２１、ハッシュ処理部ｍ２２、情報取得部ｍ２３、通知部ｍ２４を有する。【００２３】
通信処理部ｍ２１は、管理装置が直接接続された管理対象装置がノードとして参加するネットワーク上の他のノードと通信する処理を行なう。ハッシュ処理部ｍ２２は、通信処理部ｍ２１が他のノードから取得した情報や管理対象装置の情報からハッシュ値を求め、得られたハッシュ値をオーバーレイネットワークのキーとする。情報取得部ｍ２２は、通信処理部ｍ２１を介してオーバーレイネットワークの他のノードから情報を取得する処理部である。通知部ｍ２４は、通信処理部ｍ２１を介してオーバーレイネットワークの他のノードに対して情報を通知する処理部である。【００２４】
管理対象検索部ｍ１２は、オーバーレイネットワーク構築部ｍ１１が構築したオーバーレイネットワークから、管理装置ｍ１が直接接続された管理対象装置である自ノードと同一の管理範囲に属するノードを検索する処理を行なう。【００２５】
管理情報作成部ｍ１３は、管理対象検索部ｍ１２による検索によって得られたノードを管理対象ノードとする管理情報を作成する。【００２６】
生死監視部ｍ３０は、購読申請部ｍ３１、監視依頼部ｍ３２、監視部ｍ３３、判定部ｍ３４を有する。購読申請部ｍ３１は、監視対象のノードに対して生死情報の購読を申請する処理部である。【００２７】
監視依頼部ｍ３２は、他のノードから購読の申請を受けた場合に申請元ノードと相互接続するとともに、自ノードをルーティングテーブルに有するノードに自ノードの監視および監視結果の前記申請元ノードへの通知を依頼する処理部である。【００２８】
監視部ｍ３３は、他のノードから監視および監視結果の申請元ノードへの通知の依頼を受けた場合に、当該ノードを監視し、当該ノードからの応答が停止した場合に前記申請元ノードに通知する処理部である。【００２９】
判定部ｍ３４は、記監視対象ノードとの通信が途絶え、且つ前記監視対象ノードを監視する監視ノードから通知を受けた場合に前記監視対象ノードが停止したと判定する処理部である。【００３０】
すなわち、購読申請部ｍ３１と判定部ｍ３４は、管理装置ｍ１を申請元ノードとして動作させる処理部である。監視依頼部ｍ３２は、管理装置ｍ１を監視対象ノードとして動作させる処理部である。そして、監視部ｍ３３、は管理装置ｍ１を監視ノードとして動作させる処理部である。【００３１】
管理装置ｍ１は、管理対象装置であるコンピュータ上で動作する管理プログラムとして実施することが好適である。図４に示した例では、ドメインＡとドメインＢにそれぞれ３つのサーバが含まれており、ドメインＡとドメインＢとの間は通信可能である。【００３２】
ドメインＡのサーバのうち１つでは、他のコンピュータシステムの動作環境を仮想的に実現するＶＭ（Virtual  Machines）ホストプログラムが動作している。そして、ＶＭホストプログラム上に４つのＶＭゲストプログラムが動作している。このサーバでは、ＶＭホストプログラム上で運用管理プログラムがさらに動作している。ＶＭホストプログラム上で動作する運用管理プログラムは、サーバを管理装置として機能させる。この運用管理プログラムの管理対象装置は、サーバ自体とサーバ上で動作するＶＭホストプログラム、ＶＭゲストプログラムである。【００３３】
また、ドメインＡのサーバのうち１つでは、ＯＳ（Operating  System）が動作し、ＯＳ上で運用管理プログラムが動作している。そして、このサーバにはスイッチとルータが接続されている。このサーバのＯＳ上で動作する運用管理プログラムは、サーバを管理装置として機能させる。この運用管理プログラムの管理対象装置は、サーバ自体とサーバに接続されたスイッチおよびルータである。【００３４】
また、ドメインＡのサーバのうち１つでは、ＯＳ（Operating  System）が動作し、ＯＳ上で運用管理プログラムが動作している。そして、このサーバにはストレージが接続されている。このサーバのＯＳ上で動作する運用管理プログラムは、サーバを管理装置として機能させる。この運用管理プログラムの管理対象装置は、サーバ自体とサーバに接続されたストレージである。【００３５】
ドメインＡと同様にドメインＢに含まれる３つのサーバについても、サーバ上のＶＭホストプログラムやＯＳ上でそれぞれ運用管理プログラムが動作し、各サーバを管理装置として機能させる。このため、各サーバ、各サーバ上で動作する各種プログラム、各サーバに接続されたハードウェアは、対応するサーバ上で動作する運用管理プログラムによって管理される。【００３６】
各サーバ上の運用管理プログラムは、互いに通信し、オーバーレイネットワークを構築する。加えて、運用管理プログラムは、自らが属するドメイン内の他のノードについて情報を収集し、管理情報を作成することができる。なお、運用管理プログラムは、ドメインＡとドメインＢの双方からアクセス可能な端末から取得することができる。【００３７】
図４に示したように、運用管理プログラムは、管理を階層化することなく、自動的に自ドメインに属するノードの情報を取得することができる。図５は、図４に対する比較例であり、階層化した管理の説明図である。【００３８】
図５に示したシステムでは、ドメインＡを管理するサブマネージャとドメインＢを管理するサブマネージャが設けられており、２つのサブマネージャを統合マネージャが管理している。【００３９】
サブマネージャは、自らの担当するドメインに属する装置に対してSNMPなどを用いて状態監視ポーリングを行う。また、サブマネージャは、自らの担当するドメインに属する装置から、ＳＮＭＰトラップなどのイベントを受信し情報を収集する。【００４０】
このように、管理を階層化した場合、階層ごとに異なる装置もしくはプログラムを用意することとなる。また、管理対象からサブマネージャ、サブマネージャから統合マネージャとイベントが受け渡されていくため、各マネージャのＣＰＵ負荷とネットワークの負荷が大きくなる。【００４１】
これに対し、図４に示した管理プログラムは同一のプログラムを各サーバに配布したものであり、統合マネージャ用、サブマネージャ用の区別がない。また、管理プログラムは、統合マネージャ用のコンピュータやサブマネージャ用のコンピュータを区別して設置することなく、すべての管理対象上で動作する。このため、監視対象と直接イベントの送受信を行なうことができ、管理対象へのポーリングを必要としないので、ＣＰＵ負荷とネットワーク負荷を低減できる。【００４２】
図６は、サーバのハードウェアと管理プログラムの関係についての説明図である。管理プログラムｐｇ１０は、サーバ内部のＨＤＤ（Hard  disk  drive）ｐ１３に格納される。管理プログラムｐｇ１０は、オーバーレイネットワーク構築部としての動作を記述されたオーバーネットワーク構築プロセスｐｇ１１、管理対象検索部としての動作を記述された管理対象検索プロセスｐｇ１２、管理情報作成部としての動作を記述された管理情報作成プロセスｐｇ１３および生死監視部としての動作を記述された生死監視プロセスｐｇ１４を含む。【００４３】
サーバが起動すると、管理プログラムｐｇ１０はＨＤＤｐ１３から読み出され、メモリｐ１２に展開される。そして、ＣＰＵ（Central  Processing  Unit）ｐ１１がメモリに展開されたプログラムを順次実行することで、サーバを管理装置として機能させる。この時、管理装置におけるオーバーレイネットワークのインタフェースとしては、サーバの通信インタフェースｐ１４を使用する。【００４４】
図７は、オーバーレイネットワークの説明図である。管理装置もしくは管理プログラムは、起動するとオーバーレイネットワークを形成する。オーバーレイネットワーク構築部ｍ１１が、例えば、DHT（分散ハッシュテーブル）アルゴリズムのChordを用いた場合、図７に示したような環状のオーバーレイネットワークが形成される。【００４５】
DHTでは、キー（Key）とバリュー（Value）のペアが、オーバーレイネットワークに参加する各ノードで分散して保持される。Chordの場合は、SHA（Secure  Hash  Algorithm）-1でハッシュした値をキーに用い、各キーは自分のキーより大きい値のキーを持ち、管理プログラムが動作している最初のノードに格納される。【００４６】
図７の例では、ｖｍｈｏｓｔ２のキーが１、ｄｏｍａｉｎ１のキーが５、ｓｅｒｖｅｒ１のキーが１５、ｓｅｒｖｅｒ２のキーが２０、ｇｒｏｕｐ１のキーが３２、ｕｓｅｒ１のキーが４０、ｖｍｇｕｅｓｔ１１のキーが５５である。同様に、ｓｅｒｖｅｒ３のキーが６６、ｖｍｇｕｅｓｔ１２のキーが７０、ｖｍｈｏｓｔ３のキーが７５、ｖｍｇｕｅｓｔ１３のキーが８５、ｖｍｇｕｅｓｔ１４のキーが９０である。そして、ｖｍｈｏｓｔ１のキーが１００、ｓｗｉｔｃｈ１のキーが１１０、ｓｔｏｒａｇｅ１のキーが１１５、ｖｍｇｕｅｓｔ２１のキーが１２０である。【００４７】
ここで、ｖｍｈｏｓｔ１〜３、ｓｅｒｖｅｒ１〜３は、ｄｏｍａｉｎ１に属し、管理プログラムが実行されたノードであり、図７において黒い円形記号で示している。また、ｄｏｍａｉｎ１に属するｖｍｇｕｅｔ、ｓｔｏｒａｇｅ、ｓｗｉｃｈなどについては、図７において二重円形記号で示している。加えて、図７では、ｄｏｍａｉｎ２に属するノード（キーが４，３３，３６のノード）については、網掛けの円形記号で示している。【００４８】
既に述べたように、各キーとvalueのペアは自分のキーより大きい値のキーを持つ最初のノードに格納されるので、Key  40,  55  は、Key  =  66  のノードに格納される。【００４９】
また、Chordの場合、各ノードは、直前のノードと、直後のノード及び(自ノードkey+2^(x-1))  mod  (2^k)  (xは1からkの自然数、kはkeyのビット数)  のノードの情報をルーティング情報として保持している。具体的には、1,2,4,8,16,32,64,128…というように離散したノードの情報を持つ。【００５０】
これによって、Chord  DHTでは、各ノードがKeyに対するValueを、Keyより大きい最初のKeyを持つノードに保持させ、更にKeyに対応するValueを、Keyより大きい最初のKeyを持つノードから取得することが可能になる。【００５１】
さらに、図７に示した例では、Key100のvmhost1が新規マネージャであり、Key75のvmhost3とKey66のsever3に対して購読申請(i)を行なっている。Key66のsever3は、Key20のsever2に自身の監視依頼(ii)を行なう。その後、Key66のsever3でダウンイベント(iii)が発生すると、Key100のvmhost1がダウンイベントを直接検知するとともに、Key20のsever2からKey100のvmhost1に対して通知(iv)が行なわれる。【００５２】
図８は、DHT（分散ハッシュテーブル）の定義の具体例についての説明図である。このDHTは、図３のＳＡＮにおけるハッシュテーブルｔ１に相当する。【００５３】
図８では、ハッシュするキーとしてノード名を用い、キーに対応するValueを示している。【００５４】
サーバについては、サーバ名をSHA-1でハッシュしてKeyとする。そして、サーバであることを示すタグ「server」、サーバ名、サーバ名から求めたkey、サーバが有するＩＰアドレスの一覧（ＩＰリスト）、サーバが有するWWNの一覧（ＷＷＮリスト）、管理ノードとして機能しているかを示すmanager-flag、サーバの属するドメインとドメインのキーのリスト、をValueとして有する。【００５５】
ＶＭホストについては、VMホスト名をSHA-1でハッシュしてKeyとする。そして、ＶＭホストであることを示すタグ「vmhost」、VMホスト名、ＶＭホスト名から求めたkey、ＶＭホストのＩＰリスト、ＶＭホストの属するドメインとドメインのキーのリスト、ＶＭホスト上で動作するVMゲストのリスト、をValueとして有する。【００５６】
ＶＭゲストについては、VMゲスト名をSHA-1でハッシュしてKeyとする。そして、ＶＭホストであることを示すタグ「vmguest」、ＶＭゲスト名、ＶＭゲスト名から求めたkey、ＶＭゲストのＩＰリスト、ＶＭゲストが動作しているＶＭホストの名前とｋｅｙ、をValueとして有する。【００５７】
スイッチについては、スイッチ名をSHA-1でハッシュしてKeyとする。そして、スイッチであることを示すタグ「switch」、スイッチ名、スイッチ名から求めたkey、スイッチのＩＰリスト、スイッチの属するドメインとドメインのキーのリスト、をValueとして有する。【００５８】
ストレージについては、ストレージ名をSHA-1でハッシュしてKeyとする。そして、ストレージであることを示すタグ「storage」、ストレージ名、ストレージ名から求めたkey、ストレージのＩＰリスト、ストレージのWWNリスト、ストレージの属するドメインとドメインのキーのリスト、をValueとして有する。【００５９】
ユーザについては、ユーザ名をSHA-1でハッシュしてKeyとする。そして、ユーザであることを示すタグ「user」、ユーザ名、ユーザ名から求めたkey、ユーザの属するグループ名とグループのkeyのリスト、をValueとして有する。【００６０】
グループについては、グループ名をSHA-1でハッシュしてKeyとする。そして、グループであることを示すタグ「group」、グループ名、グループ名から求めたkey、グループに属するユーザ名とkeyのリスト、をValueとして有する。【００６１】
ドメインについては、ドメイン名をSHA-1でハッシュしてKeyとする。そして、ドメインであることを示すタグ「domain」、ドメイン名、ドメイン名から求めたkey、ドメインの管理装置のキーのリスト、をValueとして有する。【００６２】
図９は、図３に示したセルフノードテーブルｔ２の具体例である。図９は、ｖｍｇｕｅｓｔ１１〜１４とともに、ｖｍｈｏｓｔ１上で動作する管理プログラムが作成したセルフノードテーブルを示している。セルフノードテーブルには、種別、ノード名、key、IP、WWNの項目を有する。【００６３】
図９の例では、種別がvmhost、ノード名がvmhost1.domain1.company.com、keyが100、IPが10.20.30.40、WWNが10:00:00:60:69:00:23:74のエントリが登録されている。また、種別がvmguest、ノード名がvmguest11.domain1.company.com、keyが55、IPが10.20.30.41、WWNがnullのエントリが登録されている。【００６４】
同様に、種別がvmguest、ノード名がvmguest12.domain1.company.com、keyが70、IPが10.20.30.42、WWNがnullのエントリが登録されている。そして、種別がvmguest、ノード名がvmguest13.domain1.company.com、keyが85、IPが10.20.30.43、WWNがnullのエントリと、種別がvmguest、ノード名がvmguest14.domain1.company.com、keyが90、IPが10.20.30.44、WWNがnullのエントリが登録されている。【００６５】
図１０は、図３に示したドメインテーブルｔ3の具体例である。各管理装置や管理プログラムは、自ノードが属するドメインのドメイン名をＳＨＡ−１でハッシュしてkeyを求め、ドメインテーブルｔ３に登録する。また、ドメインテーブルｔ3には、ドメイン名とドメインのkeyの他、ドメインの管理を行なうマネージャのkeyを登録する。【００６６】
図１１は、図３に示したノード管理テーブルｔ４の具体例である。ノード管理テーブルｔ４は、ドメイン内のノードを管理するマネージャとして動作する管理装置や管理プログラムが作成する管理情報である。【００６７】
図１１のノード管理テーブルｔ４は、図７に示したオーバーレイネットワークのうちｄｏｍａｉｎ１を管理するマネージャ（Key100,vmhost1）が作成し、保持するテーブルを示している。図１１では、Key100,vmhost1のノード管理テーブルｔ４を示したので、生死監視通知先は全てブランクとなっている。Key20,server2のノード管理テーブルｔ４であれば、Key66,server3を監視し、監視結果をKey100,vmhost1に通知するので、server3のエントリの生死監視通知先が100となる。【００６８】
図１１に示したノード管理テーブルｔ４は、図７の新規マネージャ（vmhost1,  key100)のノード管理テーブルの例であり、種別、ノード名、key、Domain  key、Manager  Flag、Managed  Flag、生死監視フラグ、生死監視通知先の項目（カラム）を有する。Manager  Flagは、そのノードがマネージャである場合にtrue、マネージャではない場合にfalseの値をとる。Managed  Flagは、そのノードが管理されている場合にtrue、管理されていない場合にfalseの値をとる。生死監視フラグは、自ノードが申請元ノードとして動作する際の監視対象のノードについてtrue、監視対象ではないノードについてfalse、監視対象とならないものについてNULLの値をとる。生死監視通知先の項目は、自ノードが監視ノードとして動作する際に、そのノードの監視結果を通知すべき通知先のkeyを示す。【００６９】
具体的には、図１１に示したノード管理テーブルｔ４は、種別がvmhost、ノード名がvmhost2.domain1.company.com、Keyが1、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがfalse、生死監視通知先がブランクのエントリを有する。【００７０】
また、ノード管理テーブルｔ４は、種別がserver、ノード名がserver1.domain1.company.com、Keyが15、Domain  Keyが5、Manager  Flagがtrue、Managed  Flagがtrue、生死監視フラグがfalse、生死監視通知先がブランクのエントリを有する。【００７１】
また、ノード管理テーブルｔ４は、種別がserver、ノード名がserver2.domain1.company.com、Keyが20、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがfalse、生死監視通知先がブランクのエントリを有する。【００７２】
また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest11.domain1.company.com、Keyが55、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがNULL、生死監視通知先がブランク、のエントリを有する。【００７３】
また、ノード管理テーブルｔ４は、種別がserver、ノード名がserver3.domain1.company.com、Keyが66、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがtrue、生死監視通知先がブランク、のエントリを有する。【００７４】
また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest12.domain1.company.com、Keyが70、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがNULL、生死監視通知先がブランク、のエントリを有する。【００７５】
また、ノード管理テーブルｔ４は、種別がvmhost、ノード名がvmhost3.domain1.company.com、Keyが75、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがtrue、生死監視通知先がブランク、のエントリを有する。【００７６】
また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest13.domain1.company.com、Keyが85、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがNULL、生死監視通知先がブランク、のエントリを有する。【００７７】
また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest14.domain1.company.com、Keyが90、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがNULL、生死監視通知先がブランク、のエントリを有する。【００７８】
また、ノード管理テーブルｔ４は、種別がvmhost、ノード名がvmhost1.domain1.company.com、Keyが100、Domain  Keyが5、Manager  Flagがtrue、Managed  Flagがtrue、生死監視フラグがNULL、生死監視通知先がブランク、のエントリを有する。【００７９】
また、ノード管理テーブルｔ４は、種別がswitch、ノード名がswitch1.domain1.company.com、Keyが110、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがNULL、生死監視通知先がブランク、のエントリを有する。【００８０】
また、ノード管理テーブルｔ４は、種別がstorage、ノード名がstorage1.domain1.company.com、Keyが115、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがNULL、生死監視通知先がブランク、のエントリを有する。【００８１】
また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest21.domain1.company.com、Keyが120、Domain  Keyが5、Manager  Flagがfalse、Managed  Flagがtrue、生死監視フラグがNULL、生死監視通知先がブランク、のエントリを有する。【００８２】
なお、ノード管理テーブルｔ４は、ドメイン１に属するノードを管理するテーブルであるので、ドメイン２に属するノードについては登録されていない。【００８３】
図１２は、図３に示したルーティングテーブルｔ５の具体例である。ルーティングテーブルｔ５は、各管理装置や管理プログラムがオーバーレイネットワークにおけるルーティングに用いるテーブルである。【００８４】
図１２に示した例では、ルーティングテーブルｔ５は、最終的な宛先である目的地のキーを示すdistance、目的地のノード名、目的地と通信する場合のルーティング先を示す宛先のキーであるDestination  Key、ルーティング先のＩＰアドレスであるDestination  IPの項目を有する。【００８５】
図１２は、キー１００のノードが用いるルーティングテーブルの具体例である。図１１のルーティングテーブルｔ５は、distanceが1、ノード名がvmhost1.domain1.company.com、Destination  Keyが1、Destination  IPがa1.b1.c1.d1、distanceが2、ノード名がvmhost2.domain1.company.com、Destination  Keyが1、Destination  IPがa1.b1.c1.d1の項目を有する。【００８６】
また、ルーティングテーブルｔ５は、distanceが3、ノード名がvmhost2.domain1.company.com、Destination  Keyが1、Destination  IPがa1.b1.c1.d1の項目を有する。【００８７】
また、ルーティングテーブルｔ５は、distanceが5、ノード名がvmhost2.domain1.company.com、Destination  Keyが1、Destination  IPがa1.b1.c1.d1の項目を有する。【００８８】
また、ルーティングテーブルｔ５は、distanceが9、ノード名がvmhost2.domain1.company.com、Destination  Keyが1、Destination  IPがa1.b1.c1.d1の項目を有する。【００８９】
また、ルーティングテーブルｔ５は、distanceが17、ノード名がvmhost2.domain1.company.com、Destination  Keyが1、Destination  IPがa1.b1.c1.d1の項目を有する。【００９０】
また、ルーティングテーブルｔ５は、distanceが33、ノード名がnode1.domain2.company.com、Destination  Keyが4、Destination  IPがa4.b4.c4.d4の項目を有する。【００９１】
また、ルーティングテーブルｔ５は、distanceが65、ノード名がnode3.domain2.company.com、Destination  Keyが36、Destination  IPがa36.b36.c36.d36の項目を有する。【００９２】
このように、ルーティングテーブルｔ５は、ドメイン１に属するノード(key:1,2,3,5,9,17)が目的地である場合にはKey1（IP:a1.b1.c1.d1）にルーティングすることを規定している。また、ルーティングテーブルｔ５は、ドメイン１に属するノードkey:33が目的地である場合にはKey4（IP:a4.b4.c4.d4）にルーティングし、ドメイン２に属するノードkey:65が目的地である場合にはKey36（IP:a36.b36.c36.d36）にルーティングすることを規定している。【００９３】
図１３は、申請元ノードの処理動作を説明するフローチャートである。図１３では、図７のマネージャＡ(Key  100)がKey  66,  75の購読を申請する場合を例に説明する。まず、管理者はマネージャＡ(Key  100)の管理GUI(Graphical  User  Interface)に接続し、ハッシュテーブルｔ１より、ドメインに参加している管理対象リソースの一覧を得る（Ｓ１０１）。【００９４】
申請元ノードは、生死監視する管理対象リソースを指定する（Ｓ１０２）。ここでは、図７に示したように  Key  66,  75を指定するものとする。この管理対象は、同じ業務に属する管理対象リソースを自動的に指定してもよいし、同じ属性（例えば、vmhost）の管理対象を自動的に選択してもよい。また、オペレータが個別に指定することとしてもよい。【００９５】
マネージャAの運用管理プログラムは、指定されたリソースのKeyよりIPを取得し、各管理対象リソースの生死監視サービスに購読を申し込む（Ｓ１０３）。このとき、マネージャはノード管理テーブルｔ４の生死監視カラムのフラグのうち、生死監視サービスを購読した管理対象のフラグをTrueにする（Ｓ１０４）。【００９６】
この時点で、申請元であるマネージャAの運用管理プログラムと管理対象（図７の  Key  66,  75）の運用管理プログラム間で、相互接続を開始する（Ｓ１０５）。この相互接続は例えばTCP接続でKeep  Aliveオプションを有効にしたもので、接続が切断すると、マネージャA及び管理対象（図７  Key  66,  75）の運用管理プログラムにイベントがあがる。【００９７】
監視対象ノードとの通信が切断すると（Ｓ１０６，Ｙｅｓ）、申請元であるマネージャAの運用管理プログラムは、監視対象をルーティングテーブルにもつ監視ノードから監視対象のダウン通知があったかを判定する（Ｓ１０７）。【００９８】
監視ノードからダウン通知があった場合、申請元であるマネージャAの運用管理プログラムは、監視対象がダウンしたと判定して（Ｓ１０８）、処理を終了する。一方、監視ノードからダウン通知がない場合、申請元であるマネージャAの運用管理プログラムは、ネットワークがダウンしたと判定して（Ｓ１０９）、処理を終了する。【００９９】
図１４は、監視対象ノードの処理動作を説明するフローチャートである。図１４では、図７のKey  66,  75がマネージャＡ(Key  100)から購読申請を受けた場合を例に説明する。【０１００】
監視対象ノード（図７  Key  66,  75）の監視依頼部は、購読申請を受信する（Ｓ２０１）と、自ノードをルーティングテーブルに持つ各ノードに対して、自ノードが応答しない場合に、マネージャA  へ死んだことを通知するように監視依頼を行なう（Ｓ２０２）。図７の例では、Key66  から  Key20  へ監視依頼する。【０１０１】
その後、監視対象ノード（図７Key  66,  75）は、申請元ノード（図７Key100）と相互接続する（Ｓ２０３）。このため、監視対象ノードがダウンすると、申請元ノードにイベントがあがり、また、監視対象ノードを監視している監視ノードにもイベントがあがる。【０１０２】
図１５は、監視ノードの処理動作を説明するフローチャートである。図１５では、図７のKey20がKey66  から監視依頼を受けた場合を例に説明する。【０１０３】
監視ノード（Key20）は、監視対象ノード（Key66）から監視依頼を受信し（Ｓ３０１）、監視ノード（Key20）が有するノード管理テーブルｔ４の生死監視通知先カラムの監視対象（Key66）の欄に申請元ノードであるKey100を登録する（Ｓ３０２）。【０１０４】
その後、監視ノード（Key20）は、監視対象ノード（Key66）の監視を開始（Ｓ３０３）、監視対象ノード（Key66）との通信が切断した場合（Ｓ３０４，Ｙｅｓ）に申請元ノードKey  100にダウン通知を行なう（Ｓ３０５）。【０１０５】
このように、監視対象ノードが異常終了しONからOFFになった場合は、監視対象ノードをルーティングテーブルに持つ各ノードが監視ノードとして、申請元ノードへ死んだことを通知することとなる。【０１０６】
なお、管理対象ノードが正常終了しONからOFFになる場合は、監視対象ノードは、申請元ノードに正常終了することを通知すればよい。また、監視対象ノードは、自ノードがOFFからONになったとき、ノードKey  １００へ生きていることを通知する。【０１０７】
上述したように、本実施例にかかる管理システム、管理装置、管理方法および管理プログラムは、申請元ノードＮ１が監視対象ノードＮ２と相互接続するとともに、監視対象ノードＮ２を監視ノードＮ３によって監視させ、ノードＮ２からの直接の応答と監視ノードＮ３からの通知とを組み合わせて判定する。このため、管理対象の状態変化を迅速に把握し、また、監視対象ノードＮ２のダウンと、ネットワークのダウンとを区別することができる。
【符号の説明】
【０１０８】
Ｎ１  申請元ノード
Ｎ２  監視対象ノード
Ｎ３  監視ノード
ｍ１  管理装置
ｍ１１  オーバーレイネットワーク構築部
ｍ１２  管理対象検索部
ｍ１３  管理情報作成部
ｍ２１  通信処理部
ｍ２２  ハッシュ処理部
ｍ２３  情報取得部
ｍ２４  通知部
ｍ３０  生死監視部
ｍ３１  購読申請部
ｍ３２  監視依頼部
ｍ３３  監視部
ｍ３４  判定部
ｔ１  ハッシュテーブル
ｔ２  セルフノードテーブル
ｔ３  ドメインテーブル
ｔ４  ノード管理テーブル
ｔ５  ルーティングテーブル
ｐ１１  ＣＰＵ
ｐ１２  メモリ
ｐ１３  ＨＤＤ
ｐ１４  通信インタフェース
ｐｇ１０  管理プログラム
ｐｇ１１  オーバーレイネットワーク構築プロセス
ｐｇ１２  管理対象検索プロセス
ｐｇ１３  管理情報作成プロセス
ｐｇ１４  生死監視プロセス
【図１】
2012070155.tif 000003
【図２】
2012070155.tif 000004
【図３】
2012070155.tif 000005
【図４】
2012070155.tif 000006
【図５】
2012070155.tif 000007
【図６】
2012070155.tif 000008
【図７】
2012070155.tif 000009
【図８】
2012070155.tif 000010
【図９】
2012070155.tif 000011
【図１０】
2012070155.tif 000012
【図１１】
2012070155.tif 000013
【図１２】
2012070155.tif 000014
【図１３】
2012070155.tif 000015
【図１４】
2012070155.tif 000016
【図１５】
2012070155.tif 000017
【国際調査報告】
2012070155.tif 000018
2012070155.tif 000019