(57)【要約】【課題】ネットワークに接続された計算機群におけるマネージャに障害が発生したときにエージェントを管理する新たなマネージャに早期に切り替えが可能な計算機管理システム、方法、計算機管理制御プログラムを得ること。【解決手段】マネージャ２０１の管理ノード決定部２１１はマネージャ２０１自身が障害を起こす前にエージェント２０２1、２０２2の中でマネージャになり得るものを決定して、現在のエージェントの管理ノード記憶部２２７に記憶させる。マネージャ監視部２２１はマネージャ２０１の障害を検知すると管理依頼部２２５がそのエージェント２０２にマネージャへの移行を依頼する。これによりマネージャ２０１の早期切り替えが可能になる。【選択図】図２
2009128987.tif 000002
【特許請求の範囲】
【請求項１】
任意の数の管理される側の計算機と、
これら任意の数の管理される側の計算機とそれぞれネットワークを介して接続され、これら管理される側の計算機の管理に障害が発生する前の段階で障害が発生した時点における管理される側の計算機が実行する障害対応処理の内容を決定する障害対応決定手段を備えた、管理する側の計算機
とを具備することを特徴とする計算機管理システム。
【請求項２】
前記管理する側の計算機は、前記障害対応決定手段の決定結果を前記管理される側の計算機に通知する通知手段を具備することを特徴とする請求項１記載の計算機管理システム。
【請求項３】
前記管理する側の計算機の前記障害対応決定手段は、自装置が管理する側の計算機になった時点から間隔を置いて自装置と代替可能な計算機を判別する処理を繰り返すことを特徴とし、前記通知手段はこの障害対応決定手段の決定のたびに該当する管理される側の計算機に決定結果を通知することを特徴とする請求項２記載の計算機管理システム。
【請求項４】
前記障害対応決定手段は、前記管理する側の計算機と代替可能な計算機として前記管理される側の計算機の中から前記管理する側の計算機を選択することを特徴とする請求項１〜請求項３いずれかに記載の計算機管理システム。
【請求項５】
前記障害対応決定手段の決定した前記代替可能な計算機は、前記管理される側の計算機の管理に障害が発生した時点でこの管理される側の計算機の依頼を受けて、自装置が前記管理する側の計算機に移行する同意を行うことで移行が行われることを特徴とする請求項１〜請求項４いずれかに記載の計算機管理システム。
【請求項６】
前記障害対応決定手段の決定した前記代替可能な計算機は、優先順位が付けられた複数のものであり、前記管理する側の計算機に移行する同意を優先順位の高い方から得ることを特徴とする請求項５記載の計算機管理システム。
【請求項７】
ネットワークを介して自装置の管理下に置いた任意の数の計算機と通信を行ってこれらの計算機のそれぞれの障害発生時に実行する処理内容を決定する障害対応決定ステップ
を具備することを特徴とする計算機管理方法。
【請求項８】
前記障害対応決定ステップで管理側の計算機に障害が発生したときに実行する処理内容を管理される側の計算機に前記ネットワークを介して通知する通知ステップを具備することを特徴とする請求項７記載の計算機管理方法。
【請求項９】
前記管理側計算機判別ステップでは、管理する側の計算機が間隔を置いて障害対応処理の内容を決定する処理を繰り返すことを特徴とし、この決定する処理が行われるたびに前記通知ステップで決定結果が該当する管理される側の計算機に通知されることを特徴とする請求項８記載の計算機管理方法。
【請求項１０】
ネットワークを介して任意の数管理される側の計算機と接続された、これらの管理される側の計算機を管理する側のコンピュータに、
自装置に障害が発生した時点における前記管理される側の計算機が実行する処理内容を時間を置いて逐次決定する決定処理と、
この決定処理による決定結果を前記管理される側の計算機に通知する通知処理
とを実行させることを特徴とする計算機管理制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続された複数の計算機を管理する計算機管理システム、計算機管理方法および計算機管理制御プログラムに係わり、特に管理する側の計算機に障害が発生したときに好適な計算機管理システム、計算機管理方法および計算機管理制御プログラムに関する。
【背景技術】
【０００２】
多くのパーソナルコンピュータ、サーバあるいはファクシミリ装置、携帯電話機、ＰＤＡ（Personal Digital Assistants）といったプロセッサを内蔵した機器（以下、単に計算機という。）がインターネットやＬＡＮ（Local Area Network）等のネットワークに接続されるようになってきている。これら計算機はネットワークで接続されることによって特定のグループの間でそのうちの１台の計算機が他の計算機を管理するといったことが可能となっている。
【０００３】
本明細書では、管理する側の計算機をマネージャと呼び、管理される側の計算機をエージェントと呼ぶことにする。たとえば複数のパーソナルコンピュータが１つのグループとしてインターネットによって接続されており、その中の１台あるいは同一のグループに配置された１台のサーバがマネージャであるとする。すると、マネージャはグループ内のその他のパーソナルコンピュータからなるエージェントの監視を行う。そして、その中の１台に障害が発生したような場合に、これをユーザに通知したり、そのパーソナルコンピュータの設定が許せば再起動処理等の適切な処理を行って障害から復旧するための対応を採ることができる。
【０００４】
このような計算機管理システムを採用すると、マネージャにエージェントそれぞれの情報が集中する。したがって、マネージャはシステム全体を容易に把握することができるという利点が生じる。しかしながら、マネージャにシステム管理のための機能が集中すると、マネージャ自身に障害が発生した場合や、ネットワークに障害が発生してマネージャとエージェント間の通信が途絶えたような場合、エージェントを管理するノードが存在しなくなる。この結果として、マネージャにこのような障害が発生すると、計算機管理システム自体の信頼性が著しく低下することになる。
【０００５】
そこで、マネージャとなるノードを二重化することが本発明の第１の関連技術として提案されている（たとえば特許文献１参照）。また、本発明の第２の関連技術では、マネージャとなるノードを二重化すると共に、これらのノードの１つに障害が発生したときにはエージェントをマネージャに仕立て常にマネージャのノードが二重化されている状態を維持する提案を行っている（たとえば特許文献２参照）。
【０００６】
これら第１および第２の関連技術ではマネージャのノードを現用系と予備系に二重化している。しかしながら二重化されたこれらのマネージャのノードに同時に障害が発生する可能性は否定できない。このような障害が発生したときには、これらの技術では通信の継続性への対応が不可能である。また、マネージャのノードを二重化することがリソースの制約上で不可能な計算機管理システムも存在する。
【０００７】
そこで、複数のクライアント端末を管理するクライアント端末用管理サーバの他に、ネットワーク監視サーバと管理サーバを設けるようにした本発明の第３の関連技術が提案されるに至っている（たとえば特許文献３参照）。この第３の関連技術は、管理サーバの負担を軽減することを目的として案出されたものであり、クライアント端末用管理サーバに複数のネットワーク監視サーバのアドレスを登録するようにしている。これにより、ネットワーク監視サーバの１つに障害が発生した場合でもクライアント端末用管理サーバは他のネットワーク監視サーバにアクセスして、所望のネットワーク監視サーバのアドレスを取得することができる。
【特許文献１】特開平０６−１９７１１２号公報（第００１３段落、図１）
【特許文献２】特開２００６−２３５８３７号公報（第００１０段落、図１）
【特許文献３】特開２００３−２５６３０３号公報（第００２９段落、第００４５段落、第００６０段落、図４）
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところが、この第３の関連技術はクライアント端末用管理サーバに障害が発生したときに、これに代わってネットワーク監視サーバがクライアント端末の管理を代行するような技術のものではない。すなわち、唯一のクライアント端末用管理サーバを介してネットワーク監視サーバが接続されているので、クライアント端末用管理サーバに障害が発生すると、クライアント端末の管理はこの時点で不可能になる。
【０００９】
また、第３の関連技術では、クライアント端末用管理サーバ、ネットワーク監視サーバおよび管理サーバという３層構造のサーバ組織を備えているが、中間に位置するネットワーク監視サーバがサーバリストを共通して備えることが特徴であって、ネットワーク監視サーバのすべてに障害が発生したときはクライアント端末用管理サーバがリスト自体にアクセスできなくなってしまう。
【００１０】
そこで本発明の目的は、ネットワークに接続された計算機群におけるマネージャ側に障害が発生したときにエージェントを管理する新たなマネージャに早期に切り替えが可能な計算機管理システム、計算機管理方法および計算機管理制御プログラムを提供することにある。
【課題を解決するための手段】
【００１１】
本発明では、（イ）任意の数の管理される側の計算機と、（ロ）これら任意の数の管理される側の計算機とそれぞれネットワークを介して接続され、これら管理される側の計算機の管理に障害が発生する前の段階で障害が発生した時点における管理される側の計算機が実行する障害対応処理の内容を決定する障害対応決定手段を備えた、管理する側の計算機とを計算機管理システムに具備させる。
【００１２】
また、本発明では、（イ）ネットワークを介して自装置の管理下に置いた任意の数の計算機と通信を行ってこれらの計算機のそれぞれを自装置に代わって管理するのに適した計算機であるかを判別する管理側計算機判別ステップを計算機管理方法に具備させる。
【００１３】
更に本発明では、ネットワークを介して任意の数の管理される側の計算機と接続された、これらの管理される側の計算機を管理する側のコンピュータに、計算機管理制御プログラムとして、（イ）自装置に障害が発生した時点における前記管理される側の計算機が実行する処理内容を時間を置いて逐次決定する決定処理と、（ロ）この決定処理による決定結果を前記管理される側の計算機に通知する通知処理とを実行させることを特徴としている。
【発明の効果】
【００１４】
以上説明したように本発明によれば、ネットワークを介して自装置の管理下に置いた任意の数の計算機と通信を行って管理される側の計算機が実行する障害対応処理の内容を決定することにした。したがって、管理される側にいた他の計算機が新たなマネージャ候補としての判別結果を取得することで、障害発生時に、管理される側の計算機同士でシステムの信頼性を早急に回復できる。また、管理される側の計算機同士が自律分散的に管理するシステムに移行することができる。
【発明を実施するための最良の形態】
【００１５】
次に、本発明の実施の最良の形態を詳細に説明する。
【００１６】
図１は、本実施の形態の計算機管理システムの原理的な構成を表わしたものである。本実施の形態の計算機管理システム１００は、特定の計算機もしくは計算機群（以下、マネージャと呼ぶ。）１０１と、このマネージャ１０１によって管理される他の計算機（以下、エージェントと呼ぶ。）としての第１および第２のエージェント１０２1、１０２2によって構成されている。マネージャ１０１と第１および第２のエージェント１０２1、１０２2（エージェントの数は任意の正の整数である。）は、ネットワーク１０３によって接続されている。
【００１７】
マネージャ１０１は、その内部に障害の発生に対応するための処理部分として、障害対応決定部１１１と障害対応通知部１１２を配置している。ここで障害対応決定部１１１は、第１または第２のエージェント１０２1、１０２2に対する管理内容をマネージャ１０１の障害が発生していないなうちに決定する処理部分である。具体的には、マネージャ１０１の障害時に各エージェントが新たに管理を依頼する最適な他のエージェントをマネージャになるものとして、現在のマネージャ１０１の生存時に予め決定しておく処理部である。障害対応通知部１１２は、マネージャ１０１の障害時に障害対応決定部１１１の決定内容１１３の通知１１４を、第１および第２のエージェント１０２1、１０２2に対してネットワーク１０３を通じて行うようにする処理部である。
【００１８】
本実施の形態の計算機管理システム１００は、このような構成をとることで、実際にマネージャ１０１に障害が発生した際に、各エージェント１０２1、１０２2は、決定された他の図示しないエージェントに対して即座に管理を依頼することができる。これにより、マネージャ１０１と第１および第２のエージェント１０２1、１０２2の構成による管理形態から、第１および第２のエージェント１０２1、１０２2同士の自律分散的な管理に早急に移行することができるので、マネージャ障害時にシステムの信頼性を早急に回復することができることになる。
【００１９】
図２は、本実施の形態の計算機管理システムの構成を具体的に表わしたものである。図２で図１と同一部分には同一の符号を付しており、これらの説明を適宜省略する。この計算機管理システム２００は、マネージャ２０１と第１および第２のエージェント２０２1、２０２2がネットワーク２０３で接続された構成となっている。
【００２０】
このうち、マネージャ２０１は、図１における障害対応決定部１１１に対応する管理ノード決定部２１１と、障害対応通知部１１２に対応する管理ノード通知部２１２を備えている。ここで管理ノード決定部２１１は、マネージャ２０１の障害時に対応するものとして、各エージェントとしての第１および第２のエージェント２０２1、２０２2を代わって管理する最適な管理ノードの候補を決定する処理部をいう。すなわち、管理ノード決定部２１１で決定される最適な管理ノードとは、あるエージェントが管理する最適なノードではなく、あるエージェントを管理する最適なノードのことを指している。管理ノード通知部２１２は、管理ノード決定部２１１の決定事項を第１および第２のエージェント２０２1、２０２2に送信する処理部である。なお、この図では第１および第２のエージェント２０２1、２０２2を示しているが、計算機管理システム２００を構成するエージェントの数はこれら２つに限定されるものではない。
【００２１】
第１および第２のエージェント２０２1、２０２2は、互いに同一の構成となっている。このため、第１のエージェント２０２1の構成を中心に説明し、第２のエージェント２０２2については、説明を適宜省略する。また、第２のエージェント２０２2については、第１のエージェント２０２1の構成部分を表わすのに用いた符号に付した数字の添え字の「１」を「２」に置き換えることにする。
【００２２】
第１のエージェント２０２1は、マネージャ２０１の監視を行うマネージャ監視部２２１1と、マネージャ２０１から通知された管理ノード情報２２２1を受け取る管理ノード受信部２２３1を備えている。マネージャ監視部２２１1の監視結果情報２２４1は、管理依頼部２２５1に入力されるようになっている。管理依頼部２２５1は監視結果としてマネージャ２０１の障害状態を検知すると、自ノードの管理依頼２２６1を他ノードとしての第２のエージェント２０２2に対して行う。
【００２３】
第１のエージェント２０２1は、管理ノード記憶部２２７1と、管理判定部２２８1も備えている。管理ノード記憶部２２７1は、管理ノード受信部２２３1で受け取った受信情報２２９1を保管するようになっている。管理判定部２２８1は、他ノードとしての第２のエージェント２０２2の管理依頼部２２５2から管理依頼２２６1があったときこれを判定するようになっている。
【００２４】
以上説明したマネージャ２０１と第１および第２のエージェント２０２1、２０２2は、共に計算機であるので当然であるが、ＣＰＵ（Central Processing Unit）や、記憶媒体を備えている。記憶媒体にはＣＰＵがこの計算機管理システム２００を実現するための制御プログラムが格納されている。マネージャ２０１に障害が発生したときにその役割を交代する他ノードとしての計算機にも同様にＣＰＵと所定の制御プログラムを格納した記憶媒体が備えられていることも当然である。
【００２５】
図３および図４は、以上のような構成の計算機管理システムでマネージャの管理移行を可能にするシステム動作の概要を示したものである。このうち、図３は、図２に示す現在のマネージャ２０１の障害対応として、第１および第２のエージェント２０２1、２０２2の管理を依頼する最適な他ノードの情報をこれらエージェント２０２1、２０２2が保管するまでの障害に対応するための事前の準備動作を示している。また、図４は現在のマネージャ２０１に障害が発生した時に、その管理を他のエージェントに依頼する障害発生時の動作を示している。
【００２６】
まず、計算機管理システム２００全体がマネージャ２０１の障害に対応するための事前の準備動作を図３で説明する。図２と共に説明する。最初にマネージャ２０１は、自装置に障害が発生した場合の第１および第２のエージェント２０２1、２０２2に対する自装置以外で最適な管理ノードを、管理ノード決定部２１１で決定する（ステップＳ３０１）。この決定は、計算機管理システム２００が最初に起動した場合や、第１および第２のエージェント２０２1、２０２2等のエージェント２０２の構成に変更があった場合に行われる。エージェント２０２の構成に変更があれば、最適な管理ノードも変化する場合があるからである。マネージャ２０１がこの処理を障害発生時まで定期的に行ってもよい。
【００２７】
マネージャ２０１はこの決定２３１を自装置内の管理ノード通知部２１２からネットワーク２０３を介して管理ノード情報２２２1、２２２2として送出し、第１および第２のエージェント２０２1、２０２2に通知される（ステップＳ３０２）。この最適な管理ノード（の候補）に関する通知は、第１および第２のエージェント２０２1、２０２2内の管理ノード受信部２２３1、２２３2で受信される（ステップＳ３０３）。これらの受信情報２２９1、２２９2は、それぞれ対応する管理ノード記憶部２２７1、２２７2に記憶される（ステップＳ３０４）。
【００２８】
すでに説明したようにエージェント２０２の構成に変更があった場合や定期的な処理として、この図３のステップＳ３０１からの処理が所定のタイミングで再度行われた場合には、最適な管理ノード（の候補）に関する受信情報２２９1、２２９2が管理ノード記憶部２２７1、２２７2に上書き保存されることになる。
【００２９】
次に図４の処理を図２と共に説明する。図２に示した第１および第２のエージェント２０２1、２０２2内のマネージャ監視部２２１1、２２１2は、マネージャ２０１に障害が発生するかを常に監視している（ステップＳ３２１）。そして、マネージャ２０１に障害が発生すると（Ｙ）、第１および第２のエージェント２０２1、２０２2の管理依頼部２２５1、２２５2は、自装置の管理ノード記憶部２２７1、２２７2から自ノードの管理を依頼するノード情報２３３1、２３３2を読み出す（ステップＳ３２２）。
【００３０】
このノード情報２３３1、２３３2の取得に成功した場合（ステップＳ３２３：Ｙ）、管理依頼部２２５1、２２５2はその取得したノードに対して管理依頼２２６1、２２６2を行う（ステップＳ３２４）。この場合、管理依頼の対象となった現時点ではエージェント２０２である装置の管理判定部２２８は、管理を行うかどうか判定を行う（ステップＳ３２５）。この結果として、その装置の管理判定部２２８が管理可能であると判定（あるいは同意）した場合には（ステップＳ３２６：Ｙ）、この判定結果を依頼側に通知した後、そのエージェント２０２が新たなマネージャ２０１となり（ステップＳ３２７）、一連の処理を終了する（エンド）。
【００３１】
たとえば第２のエージェント２０２2が第１のエージェント２０２1のマネージャ２０１になるのが最適であると管理ノード記憶部２２７1に記憶されており、第２のエージェント２０２2の管理判定部２２８2がこれを可とする判定を行ったとする。この場合にはマネージャ２０１の障害を第１のエージェント２０２1が検出した後、第２のエージェント２０２2が第１のエージェント２０２1のマネージャ２０１になることになる（ステップＳ３２７）。この例の場合には、マネージャ２０１の交代が迅速に行われることになる。
【００３２】
これに対して、ステップＳ３２３で管理ノード記憶部２２７1（あるいは管理ノード記憶部２２７2）に最適な管理ノードの候補が記憶されておらず、取得できない場合がある（ステップＳ３２３：Ｎ）。このような場合には、従来から行われている一般的な手法で、マネージャ２０１となる管理ノードを探索する（ステップＳ３２８）。また、候補とされたエージェント２０２が管理可能ではないと判定した場合（ステップＳ３２６：Ｎ）も同様である。この場合には、新たなマネージャ２０１が定まるまで、管理が比較的長い時間にわたって不能になる可能性もある。
【００３３】
このように本実施の形態によれば、マネージャ２０１の障害時に、すでに決定してある最適な管理ノードの情報を利用することで、マネージャ主導の管理から自律分散的な管理へ早急に切り替えることができるため、システムの信頼性が低下している時間を短縮することができるという効果がある。また、マネージャ２０１が新たなマネージャとなるべき候補を決定しても、その候補に決定されたエージェント２０２はマネージャとなるかを判定（あるいは同意）するようにしたので、マネージャとして無理のない移行が可能になる。
【実施例１】
【００３４】
図５は、本発明の一実施例における計算機管理システムの構成を表わしたものである。この簡略化された図で示されるように本実施例の計算機管理システム４００では、第１〜第３のノード４０１〜４０３が、インターネット等の共通のネットワーク４０４によって相互に接続されている。
【００３５】
図６は、本実施例の各ノードの共通した構成を示したものである。マネージャにもエージェントにもなり得るノードとしての計算機４１１は、マネージャとして機能するマネージャ部４１２と、エージェントとして機能するエージェント部４１３と、これらの機能を切り替える機能切替部４１４と、図５に示したネットワーク４０４と通信するネットワーク通信部４１５を備えている。この計算機４１１は、機能切替部４１４によってマネージャ部４１２の方を機能させたとき、マネージャとなる。また、機能切替部４１４によってエージェント部４１３の方を機能させたときには、エージェントとなる。
【００３６】
マネージャ部４１２は、図２に示した管理ノード決定部２１１と管理ノード通知部２１２で構成されている。管理ノード通知部２１２は機能切替部４１４を介してネットワーク通信部４１５と接続されている。管理ノード決定部２１１と管理ノード通知部２１２は具体的に説明したので、これらの説明は省略する。
【００３７】
エージェント部４１３は、機能切替部４１４を介してネットワーク通信部４１５と接続されたエージェント通信部４２１を備えている。エージェント通信部４２１はネットワーク通信部４１５と通信する部分であり、管理ノード受信部２２３、マネージャ監視部２２１、管理依頼部２２５および管理判定部２２８と接続されている。管理ノード記憶部２２７は計算機４１１内の図示しない不揮発性メモリの一部領域を構成しており、マネージャ監視部２２１および管理依頼部２２５と接続されている。また、マネージャ監視部２２１と管理依頼部２２５は直接接続されている。エージェント部４１３内のエージェント通信部４２１を除く各部は、図２に示した各処理部と内容が変わらないので、その詳細な説明は省略する。
【００３８】
機能切替部４１４は、前記した不揮発性メモリの他の領域で構成される機能分担テーブル４１６と接続されており、この内容に応じて、相手ノードとの関係でマネージャ部４１２とエージェント部４１３のいずれか一方が機能するように設定されている。
【００３９】
図７は、障害が発生する前の初期状態における機能分担テーブルの内容を表わしたものである。この時点を第１の時点ｔ1とする。機能分担テーブル４１６には、第１の時点ｔ1で、たとえば図５に示す計算機管理システム４００の管理者が、それぞれ管理されるノードと管理するノードの割り当てを行っている。図５と共に説明する。
【００４０】
この機能分担テーブル４１６で、管理されるノードがエージェントとしてのノードであり、管理するノードがマネージャとしてのノードである。この例では、第１のノード４０１と第３のノード４０３の間では前者がエージェントであり、後者がマネージャとなっている。第２のノード４０２と第１のノード４０１との間では、前者がエージェントであり、後者がマネージャとなっている。第３のノード４０３と第２のノード４０２との間では前者がエージェントであり、後者がマネージャとなっている。
【００４１】
そこで、一例として第１のノード４０１と第３のノード４０３の関係について具体的に考察してみる。この例では、マネージャとしての第３のノード４０３が第１の時点ｔ1よりも後の第２の時点ｔ2で障害を発生させるものとする。この第２の時点ｔ2よりも前の時点で、第３のノード４０３は第２のノード４０２がエージェントとしての第１のノード４０１を管理するのに最適なノードであると決定するものとする。
【００４２】
図８は、相手のノードとの関係で管理する側のマネージャとなるノードの処理の様子を表わしたものである。図５および図６と共に説明する。第３のノード４０３は機能分担テーブル４１６で第１のノード４０１との関係でマネージャとしての機能を備えているので、まず、自装置にエージェントとしての第１のノード４０１との関係で障害が発生したとき、マネージャとしての役割を果たすことのできるノードの決定を行う（ステップＳ５０１）。
【００４３】
ここでまず、ノードの決定の様子を説明する。マネージャとしての第３のノード４０３の管理ノード決定部２１１は、エージェントとしての第１のノード４０１等の各エージェントに対して適宜通信を行い、各種の情報を収集することができる。この結果、得られた各エージェントのＣＰＵの負荷やメモリの使用量といった情報を基にして、第３のノード４０３の管理ノード決定部２１１は自装置に障害が発生した際の第１のノード４０１に最適なノードの決定を行う。
【００４４】
この決定のタイミングは、監視情報が収集された時であってもよいし、マネージャとしての第３のノード４０３の負荷が低い監視の行いやすい時で、各エージェントのＣＰＵ負荷の急激な上昇を行った場合のように状態が大幅に変化した時であってもよい。もちろん、これ以外の各種の場合でもよい。管理ノード決定部２１１がどのタイミングで決定を行うかは、システムの要件に応じて変更しうる。たとえば、監視情報が収集された時に決定する場合には、最新の監視情報を利用できるため、常に最新の状態での管理ノードの情報を維持することができる。これに対して、マネージャの負荷が低い時に決定することにすると、第３のノード４０３の本来の処理動作への影響を最小限とすることができる。
【００４５】
図８に戻って説明を続ける。第３のノード４０３が第１のノード４０１についての最適なマネージャとなるノードが存在すると判別した場合には（ステップＳ５０２：Ｙ）、その最適なマネージャとなるノードを対応するエージェントとしての第１のノード４０１に通知する（ステップＳ５０３）。そして、次の決定のためのタイミングが到来するまで待機し（ステップＳ５０４：Ｎ）、先に説明したタイミングが到来したら（Ｙ）、ステップＳ５０１の処理に戻る（リターン）。このようにして、環境の変化に対応して最適なマネージャとなるノードを適宜変更できるようにしている。
【００４６】
ステップＳ５０２で最適なマネージャとなるノードが存在しないと判別された場合には（Ｎ）、該当するノードが存在しないとするエラーを対応するエージェントとしての第１のノード４０１に通知する（ステップＳ５０５）。この場合にもステップＳ５０４に進んで、次のタイミングでステップＳ５０１の判定を行うことになる。
【００４７】
図９は、エージェント側の処理の流れを表わしたものである。図５および図６と共に説明する。この例でエージェントである第１のノード４０１は、マネージャとしての第３のノード４０３から図８のステップＳ５０３あるいはステップＳ５０５の通知が受信されるのを待機している（ステップＳ５２１）。そして、この通知を受信すると（Ｙ）、自装置の管理ノード記憶部２２７に通知の内容を上書きして更新する（ステップＳ５２２）。たとえば第３のノード４０３から第２のノード４０２が最適なマネージャとなるノードであると通知を受けたものとすると、管理ノード記憶部２２７に「第２のノード」と上書きすることになる。エラーの通知が来た場合には、管理ノード記憶部２２７に「該当ノードなし」と上書きする。たとえば第２のノード４０２が過負荷の状態のときに第３のノード４０３によるチェックを受けたような場合がそれである。
【００４８】
エージェントである第１のノード４０１は、この他に他のマネージャからマネージャとしての管理依頼を受信する場合がある（ステップＳ５２３：Ｙ）。この場合、第１のノード４０１は自装置の管理判定部２２８で自装置が指定されたノードをマネージャとして管理可能であるかを判定する（ステップＳ５２４）。この判定は、自装置の将来の負荷の状態の予測や自装置がすでに他のノードのマネージャとなっているかといった各種の状況を材料として行われる。
【００４９】
この判定でマネージャとしての管理が可能であると判定した場合には（ステップＳ５２５：Ｙ）、管理依頼先に管理が可能である旨の通知を行う（ステップＳ５２６）。この場合には、すぐに管理が実行されるので自装置の機能分担テーブル４１６該当する欄の記載を変更する。たとえば、第３のノード４０３と第１のノード４０１との関係で、第３のノード４０３がマネージャとして管理できない状況になったとき、第１のノード４０１が第２のノード４０２にマネージャとしての管理を依頼してきたとする。この場合、第２のノード４０２が管理依頼を受ける場合には、自装置の機能分担テーブル４１６の該当する「管理するノード」を「第２のノード」に書き換える（ステップＳ５２７）。
【００５０】
図１０は、機能分担テーブルが図７の状態から書き換えられた状態を示したものである。図７と対比すれば分かるように第１のノード４０１を「管理するノード」が、第３のノード４０３から第２のノード４０２に変更されている。これにより、第２のノード４０２は、第１および第３のノード４０１、４０３の双方を管理するマネージャとなる。もちろん、たとえば第２のノード４０２が第３のノード４０３との関係でマネージャとしての適格性を欠いたような場合には、代わって第１のノード４０１が第３のノード４０３を管理するマネージャとなるといった変更が将来生じる可能性もある。
【００５１】
図９に戻って説明を続ける。ステップＳ５２５で第１のノード４０１の管理が可能でないと判定された場合には（Ｎ）、管理が不可能であることの通知が管理依頼先のノードに通知される（ステップＳ５２８）。
【００５２】
ところで、第３のノード４０３が第１のノード４０１を管理している図７に示す状態で、エージェントである第１のノード４０１は第３のノード４０３がマネージャとしての機能を果たしているかどうかをマネージャ監視部２２１で監視する。具体的にはマネージャの監視時機が到来すると（ステップＳ５２９：Ｙ）、自装置との関係で、たとえばその生存を確認する（ステップＳ５３０）。そして、たとえば生存確認のメッセージに応答したことで生存が確認されれば（ステップＳ５３１：Ｙ）、そのまま何もしないで処理を終了する（リターン）。
【００５３】
これに対して生存が確認されなかった場合には（ステップＳ５３１：Ｎ）、マネージャを他のノードに代わって行ってもらう必要がある。そこで自装置の管理ノード記憶部２２７から最適な管理ノードの候補を読み出す（ステップＳ５３２）。このとき、マネージャとなるノードが読み出されないといったエラーが発生しなければ（ステップＳ５３３：Ｎ）、その読み出したノードに管理依頼を通知する（ステップＳ５３４）。先の例で第３のノード４０３に障害が発生した場合には、管理ノード記憶部２２７から第２のノード４０２を指定するデータが読み出され、これに管理依頼が通知されることになる。
【００５４】
これに対して、ステップＳ５３３でエラーが発生した場合には（Ｙ）、マネージャとなるノードが決定できない状態となる。そこでこの場合には、一般的な管理ノードの探索処理が実行される（ステップＳ５３５）。本実施例では、説明を簡略化するために第１〜第３のノード４０１〜４０３のみが計算機管理システム４００を構成しているが、これよりも多いノードがシステムを構成している場合、残りのノードに対しても管理する側のノードに成り得るかのチェックが行われることになる。ステップＳ５３４で管理依頼を行った先のノード（この例の場合には第２のノード４０２）から管理が不可能である旨の受信があった場合（ステップＳ５３６：Ｙ）も、同様にステップＳ５３５に進んで、一般的な管理ノードの探索処理が実行されることになる。
【００５５】
以上説明したように本実施例によれば、マネージャとなったノードが自装置に代わる装置を次のマネージャとなるノードとして選択することにしたので、個々のエージェントにマネージャを選択させる場合と比べて複数の候補の間で１つのマネージャを選択するといった調整が不要となる。また、エージェント側のノードもマネージャの選択の仕事から解放されるので、自装置やネットワークの負荷を軽減することができるという長所がある。
【００５６】
なお、実施例ではマネージャに対して生存確認のメッセージを送信することにしたが、マネージャからの応答時間の遅延を測定したり、マネージャの負荷の状態の報告を受けることで、生存状態であっても他のエージェントをマネージャとして交代させるようにしてもよいことは当然である。
【００５７】
また、複数のエージェントの中からマネージャとなるノードを決定する際には、各エージェントがマネージャとなった割合といったような過去の実績をデータとして保存しておき、これを参考にしてもよい。
【００５８】
更に実施例では各ノードが図６に示すようなマネージャとしての機能とエージェントとしての機能を予め持っているものとして説明したが、特定のノードについてはこれらの機能の一方のみを持ったノードとして構成されていてもよい。
【００５９】
更にまた実施例では、マネージャが新たなマネージャとなり得る最適な１つのエージェントをその候補としたが、優先順位を付けて２以上の候補を通知するようにしてもよい。この場合、優先順位の最も高いエージェントに最初にマネージャへの依頼が行われ、同意が得られない場合には順位を繰り下げた依頼が行われる。これにより、管理依頼が拒絶された場合のリスクを軽減させることができる。
【図面の簡単な説明】
【００６０】
【図１】本実施の形態の計算機管理システムの原理図である。
【図２】本実施の形態の計算機管理システムの構成を具体的に表わしたブロック図である。
【図３】本実施の形態で障害に対応するためのマネージャの事前の準備動作を示す流れ図である。
【図４】本実施の形態で障害が発生した時の管理を他のエージェントに依頼するエージェント側の動作を示す流れ図である。
【図５】本発明の一実施例における計算機管理システムの構成の概要を表わしたシステム構成図である。
【図６】本実施例の各ノードの共通した構成を示したブロック図である。
【図７】障害が発生する前の初期状態における機能分担テーブルの内容を表わした説明図である。
【図８】本実施例で相手のノードとの関係で管理する側のマネージャとなるノードの処理の様子を表わした流れ図である。
【図９】本実施例でエージェント側の処理の流れを表わした流れ図である。
【図１０】機能分担テーブルが図７の状態から書き換えられた状態を示した説明図である。
【符号の説明】
【００６１】
１００、２００、４００  計算機管理システム
１０１、２０１  マネージャ
１０２1、２０２1  第１のエージェント
１０２2、２０２2  第２のエージェント
１０３、２０３、４０４  ネットワーク
１１１  障害対応決定部
１１２  障害対応通知部
２１１  管理ノード決定部
２１２  管理ノード通知部
２２１  マネージャ監視部
２２５  管理依頼部
２２７  管理ノード記憶部
２２８  管理判定部
４０１  第１のノード
４０２  第２のノード
４０３  第３のノード
４１１  計算機
４１２  マネージャ部
４１３  エージェント部
４１４  機能切替部
４１６  機能分担テーブル
【図１】
2009128987.tif 000003
【図２】
2009128987.tif 000004
【図３】
2009128987.tif 000005
【図４】
2009128987.tif 000006
【図５】
2009128987.tif 000007
【図６】
2009128987.tif 000008
【図７】
2009128987.tif 000009
【図８】
2009128987.tif 000010
【図９】
2009128987.tif 000011
【図１０】
2009128987.tif 000012