(57)【要約】【課題】クラスタシステムが提供するサービスの信頼性を低下させることなく多数のノードのソフトウェア更新ができるサービス提供ノードを提供することを目的とする。【解決手段】サービス提供ノード１００は、監視ノード５００に対して、プログラムのバージョン情報を含めて定期的にハートビート１５１を送信する。ハートビート１５１により監視ノード５００が複数のサービス提供ノード１００、２００、３００、４００から収集した、プログラム情報を含むノード一覧情報１６１を受信する。サービス提供ノード１００は、プログラム情報からプログラム更新対象の他のサービス提供ノードを選択し、更新対象に選択した他のサービス提供ノードがさらに他のサービス提供ノードに更新を指示するための更新タイミング情報とともにプログラムの更新の指示を、選択した他のサービス提供ノードにする。【選択図】図１
2010182061.tif 000002
【特許請求の範囲】
【請求項１】
クラスタシステムに属するサービス提供ノードに対するサービス提供用プログラムの更新指示の送信を、前記サービス提供ノードにネットワークで接続されたコンピュータに実行させるソフトウェア更新指示プログラムであって、
前記コンピュータを、
前記クラスタシステムを監視する監視ノードに対して、前記コンピュータで実行されている前記サービス提供用プログラムに関するプログラム情報を所定の送信間隔で定期的に送信するプログラム情報送信手段、
前記監視ノードから前記サービス提供ノードの前記プログラム情報を含むノード一覧情報を受信するノード一覧情報受信手段、
前記ノード一覧情報の前記プログラム情報から前記サービス提供用プログラムが未更新のサービス提供ノードを判定し、前記サービス提供用プログラムが未更新のサービス提供ノードのうち少なくとも一部を、更新対象サービス提供ノードとして選択する更新対象選択手段、
前記コンピュータで実行されている前記サービス提供用プログラムに対する前記更新指示と共に、前記更新指示を伝搬させるまでの待機時間を示す第一の更新タイミング情報が入力されると、前記第一の更新タイミング情報に示された待機時間経過後の時刻を、前記更新指示の指示タイミングに決定する指示タイミング決定手段、
前記更新対象サービス提供ノードからさらに他のサービス提供ノードへ前記更新指示を伝搬させるまでの待機時間を示す第二の更新タイミング情報を生成する更新タイミング情報生成手段、
前記指示タイミングに達すると、前記サービス提供用プログラムの前記更新指示と前記第二の更新タイミング情報とを、前記更新対象サービス提供ノードに送信する更新指示送信手段、
として機能させることを特徴とするソフトウェア更新指示プログラム。
【請求項２】
前記プログラム情報送信手段は、前記プログラム情報を、前記コンピュータが前記サービス提供プログラムに基づいてサービスを提供していることを示すハートビートに含めて送信することを特徴とする請求項１記載のソフトウェア更新指示プログラム。
【請求項３】
前記更新対象選択手段は、前記コンピュータとの関係が希薄な前記サービス提供ノードを前記更新対象サービス提供ノードとして選択することを特徴とする請求項１記載のソフトウェア更新指示プログラム。
【請求項４】
前記関係は、前記サービス提供ノード間における過去の単位時間当たりの通信量により評価されることを特徴とする請求項３記載のソフトウェア更新指示プログラム。
【請求項５】
前記更新タイミング情報生成手段は、前記第一の更新タイミング情報とは異なる待機時間を指定した前記第二の更新タイミング情報を生成することを特徴とする請求項１記載のソフトウェア更新指示プログラム。
【請求項６】
クラスタシステムに属するサービス提供ノードに対するサービス提供用プログラムの更新指示の送信を、前記サービス提供ノードにネットワークで接続されたコンピュータで実行するソフトウェア更新指示方法であって、
前記コンピュータが、
前記クラスタシステムを監視する監視ノードに対して、前記コンピュータで実行されている前記サービス提供用プログラムに関するプログラム情報を所定の送信間隔で定期的に送信し、
前記監視ノードから前記サービス提供ノードの前記プログラム情報を含むノード一覧情報を受信し、
前記ノード一覧情報の前記プログラム情報から前記サービス提供用プログラムが未更新のサービス提供ノードを判定し、前記サービス提供用プログラムが未更新のサービス提供ノードのうち少なくとも一部を、更新対象サービス提供ノードとして選択し、
前記コンピュータで実行されている前記サービス提供用プログラムに対する前記更新指示と共に、前記更新指示を伝搬させるまでの待機時間を示す第一の更新タイミング情報が入力されると、前記第一の更新タイミング情報に示された待機時間経過後の時刻を、前記更新指示の指示タイミングに決定し、
前記更新対象サービス提供ノードからさらに他のサービス提供ノードへ前記更新指示を伝搬させるまでの待機時間を示す第二の更新タイミング情報を生成し、
前記指示タイミングに達すると、前記サービス提供用プログラムの前記更新指示と前記第二の更新タイミング情報とを、前記更新対象サービス提供ノードに送信する、
ことを特徴とするソフトウェア更新指示方法。
【請求項７】
クラスタシステムに属し、サービス提供用プログラムを実行することでサービスを提供する情報処理装置において、
前記クラスタシステムを監視する監視ノードに対して、前記コンピュータで実行されている前記サービス提供用プログラムに関するプログラム情報を所定の送信間隔で定期的に送信するプログラム情報送信手段と、
前記監視ノードから、前記クラスタシステムに属する他の情報処理装置の前記プログラム情報を含むノード一覧情報を受信するノード一覧情報受信手段と、
前記ノード一覧情報の前記プログラム情報から前記サービス提供用プログラムが未更新の前記他の情報処理装置を判定し、前記サービス提供用プログラムが未更新の前記他の情報処理装置のうち少なくとも一部を、更新対象情報処理装置として選択する更新対象選択手段と、
前記コンピュータで実行されている前記サービス提供用プログラムに対する前記更新指示と共に、前記更新指示を伝搬させるまでの待機時間を示す第一の更新タイミング情報が入力されると、前記第一の更新タイミング情報に示された待機時間経過後の時刻を、前記更新指示の指示タイミングに決定する指示タイミング決定手段と、
前記更新対象情報処理装置からさらに前記他の情報処理装置へ前記更新指示を伝搬させるまでの待機時間を示す第二の更新タイミング情報を生成する更新タイミング情報生成手段と、
前記指示タイミングに達すると、前記サービス提供用プログラムの前記更新指示と前記第二の更新タイミング情報とを、前記更新対象情報処理装置に送信する更新指示送信手段と、
を備えることを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソフトウェア更新指示プログラム、ソフトウェア更新指示方法、および情報処理装置に関し、特に運用を継続しながらソフトウェアを更新するソフトウェア更新指示プログラム、ソフトウェア更新指示方法、および情報処理装置に関する。
【背景技術】
【０００２】
クラスタシステムでは、複数のコンピュータを用いた分散処理がおこなわれる。なお、クラスタシステムを構成するコンピュータを、ノードと呼ぶ。クラスタシステムでは、処理をどのノードに実行させるべきかを判断するために、各ノードが正常に運用されているか否かを認識している必要がある。
【０００３】
クラスタシステムにおいてノードの運用状況を認識する方法として、各ノードから監視ノードへハートビートを定期的に送信する方法がある。ハートビートは、そのハートビートを送信したノードが正常に運用されていることを示す情報である。監視ノードでは、ハートビートを所定間隔で送信しているノードのみを、正常に運用しているノードと判断する。
【０００４】
監視ノードでは、ハートビートが途絶えたノードを検出すると、そのノードに障害が発生したものと判断して、そのノードを処理の要求先から除外する。処理の要求先から除外されたノードは、障害の原因を取り除いた後、運用が再開される。運用再開時には、運転を再開したノードが監視ノードにおいて処理の要求先に追加される。
【０００５】
なお、ハートビートのような周期的に送信される情報は、その間隔が短い程、情報のリアルタイム性が向上するが、その一方で通信負荷が増大する。そこで、通信状態に基づいて周期的におこなわれる送信の間隔を変更する技術が考えられている。
【０００６】
また、システムを運用しているとき、各ノードのソフトウェアを更新する必要が生じることがある。通常は、ソフトウェア更新対象のノードの運用を停止してから、ソフトウェアの更新作業がおこなわれる。そのため、ソフトウェアの更新時には、ノードでのサービスの提供が一時的に停止することとなる。サービスを停止すると、監視ノードにおいて障害が検出されエラー処理が実行される。ソフトウェアの更新の場合、更新処理終了後に正常に運用可能となることが明らかである。そのため、エラー処理が実行されると、無駄な処理が発生することとなり、システムの運用効率が低下する。
【０００７】
そこで、サービスの提供を停止せずに、ソフトウェアを更新する技術が考えられている。たとえば、サービスを提供するためのエージェントと、クラスタシステム内の他のコンピュータと通信をおこないながらエージェントを制御するクラスタ制御部を設ける。そして、エージェントによるサービスを継続しながらクラスタ制御部のソフトウェアをアップグレードする技術がある。
【０００８】
また、複数のノードから構成されるクラスタシステムを一括してインストールするための方法も考えられている。たとえば、マスターノードがインストール情報を保持し、自ノードのインストールをおこなうとともに配下のノードに起動を指示し、上位ノードから末端ノードまで順次インストールを繰り返してクラスタシステム全体のインストールをする。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００４−３６４１６８号公報
【特許文献２】特開２００５−８５１１４号公報
【特許文献３】特開２００２−３０４２９９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかし、ソフトウェアの更新処理中は、ノードの動作が不安定になる。そのため、多数のノードが同時にソフトウェアを更新している状態は、クラスタシステム全体を不安定にするおそれがある。
【００１１】
特に、大規模なクラスタシステムにおいてすべてのノードのソフトウェアを更新する場合、システム全体としての運用効率の低下や信頼性の低下を招いてしまうおそれがある。
本発明はこのような点に鑑みてなされたものであり、クラスタシステムが提供するサービスの信頼性を低下させることなく多数のノードのソフトウェア更新ができるソフトウェア更新指示プログラム、ソフトウェア更新指示方法、および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、図１に示すような分散処理をおこなうクラスタシステムに属するコンピュータを、サービス要求を受け付けてサービスを提供するサービス提供ノードとして機能させるサービス提供用プログラムが提供される。
【００１３】
サービス提供ノードは、プログラム情報送信手段と、ノード一覧情報受信手段と、更新対象選択手段と、指示タイミング決定手段と、更新タイミング情報生成手段と、更新指示送信手段とを備える。
【００１４】
プログラム情報送信手段は、クラスタシステムを監視する監視ノードに対して、コンピュータで実行されているサービス提供用プログラムに関するプログラム情報を所定の送信間隔で定期的に送信する。
【００１５】
ノード一覧情報受信手段は、監視ノードからサービス提供ノードのプログラム情報を含むノード一覧情報を受信する。
更新対象選択手段は、ノード一覧情報のプログラム情報からサービス提供用プログラムが未更新のサービス提供ノードを判定し、サービス提供用プログラムが未更新のサービス提供ノードのうち少なくとも一部を、更新対象サービス提供ノードとして選択する。
【００１６】
指示タイミング決定手段は、コンピュータで実行されているサービス提供用プログラムに対する更新指示と共に、更新指示を伝搬させるまでの待機時間を示す第一の更新タイミング情報が入力されると、第一の更新タイミング情報に示された待機時間経過後の時刻を、更新指示の指示タイミングに決定する。
【００１７】
更新タイミング情報生成手段は、更新対象サービス提供ノードからさらに他のサービス提供ノードへ更新指示を伝搬させるまでの待機時間を示す第二の更新タイミング情報を生成する。
【００１８】
更新指示送信手段は、指示タイミングに達すると、サービス提供用プログラムの更新指示と第二の更新タイミング情報とを、更新対象サービス提供ノードに送信する。
【発明の効果】
【００１９】
上記のサービス提供ノードでは、クラスタシステムが提供するサービスの信頼性を低下させることなく多数のノードのソフトウェア更新ができる。
【図面の簡単な説明】
【００２０】
【図１】実施の形態の概要を示す図である。
【図２】本実施の形態のクラスタシステムの構成例を示す図である。
【図３】本実施の形態に用いる監視ノードのハードウェア構成例を示す図である。
【図４】ハートビートパケットのデータ構造例を示す図である。
【図５】ハートビート確認応答パケットのデータ構造例を示す図である。
【図６】ソフトウェア配布処理を示すフローチャートである。
【図７】更新タイミング情報表である。
【図８】配布先決定処理を示すフローチャートである。
【図９】ノード一覧テーブルである。
【図１０】二重化強度監視処理を示すフローチャートである。
【図１１】二重化強度評価のための通信量表である。
【図１２】ソフトウェア更新指示の伝播を表すダイヤグラム図である。
【図１３】分散処理システムの機能ブロック図である。
【図１４】ソフトウェア更新処理手順を示すシーケンス図である。
【図１５】ソフトウェア更新処理手順を示すシーケンス図である。
【図１６】二重化強度評価のための通信量表である。
【図１７】本実施の形態のクラスタシステムの構成の変形例を示す図である。
【図１８】ノード一覧テーブルである。
【図１９】統合ノード一覧テーブルである。
【発明を実施するための形態】
【００２１】
以下、実施の形態を図面を参照して説明する。
図１は、実施の形態の概要を示す図である。実施の形態に係るサービス提供ノード１００は、サービス提供ノード２００、３００、４００とともにクラスタシステムを構成し、図示しない処理要求ノードからのサービス要求に応じて、分散処理によるサービスを提供している。サービス提供ノード１００、２００、３００、４００は、監視ノード５００にハートビート１５１を送信し、ハートビート１５１の確認応答としてノード一覧情報１６１を受信している。また、サービス提供ノード１００は、管理ノード７００から更新指示１７１を受ける。
【００２２】
サービス提供ノード１００は、プログラム情報送信手段１０１と、更新対象選択手段１０２と、指示タイミング決定手段１０３と、更新タイミング情報生成手段１０４と、ノード一覧情報受信手段１０５と、更新指示送信手段１０６と、ソフトウェア更新手段１０７と、更新ファイル記憶手段１０８とを備える。
【００２３】
サービス提供ノード１００がサービスを提供するサーバ機能は、サーバ１１０が動作することで実現する。サーバ１１０は、サービス提供プログラムをサービス提供ノード１００が実行することで実現する機能である。なお、図１の例では、サービス提供プログラム内に、サービス提供プログラムの更新指示を伝搬させるためのソフトウェア更新指示プログラムを含んでいる。そのため、サービス提供プログラムの更新指示を伝搬させるための機能を、サーバ１１０が有している。
【００２４】
図１では、サーバ１１０が有する各種機能のうち、サービス提供プログラムの更新指示を伝搬させるための機能を示している。すなわち、サーバ１１０は、プログラム情報送信手段１０１、更新対象選択手段１０２、指示タイミング決定手段１０３、更新タイミング情報生成手段１０４、ノード一覧情報受信手段１０５、および更新指示送信手段１０６を有している。また、サーバ１１０は、ソフトウェア更新手段１０７と、更新ファイル記憶手段１０８とを有してもよい。
【００２５】
プログラム情報送信手段１０１は、サービス提供ノード１００の動作状況を知らせるために監視ノード５００に定期的にハートビート１５１を送信する。ハートビート１５１には、サーバプログラムのソフトウェアバージョンを示すバージョン情報（プログラム情報）が含まれる。これにより、監視ノード５００は、サービス提供ノード１００の動作状況を知るとともに、サーバ機能を実現するプログラム（サーバプログラム）のソフトウェアバージョンを把握することができる。また、監視ノード５００は、サービス提供ノード１００の他に、サービス提供ノード２００、３００、４００からもハートビートを受信してノード一覧情報１６１を生成する。ノード一覧情報１６１は、監視ノード５００が監視対象とするサービス提供ノードのネットワークアドレス（アドレス情報）とサーバプログラムのソフトウェアバージョン（プログラム情報）の一覧データである。
【００２６】
ノード一覧情報受信手段１０５は、監視ノード５００からノード一覧情報１６１を受信する。これにより、サービス提供ノード１００は、クラスタシステムを構成する他のサービス提供ノードのプログラム情報とアドレス情報とを取得する。
【００２７】
更新対象選択手段１０２は、ソフトウェアバージョンを比較してプログラム更新対象となる他のサービス提供ノードとしてサービス提供ノード３００を選択する。プログラム更新対象の選択は、ノード一覧情報１６１から自らのソフトウェアバージョンよりも古いソフトウェアバージョンのサービス提供ノードを検索しておこなう。
【００２８】
指示タイミング決定手段１０３は、サービス提供ノード３００に更新を指示するタイミングを決定する。たとえば、指示タイミング決定手段１０３は、更新指示１７１と共に入力される更新タイミング情報に基づいて、更新を指示するタイミングを決定する。更新タイミング情報には、更新指示を伝搬させるまでの待機時間が示されている。この場合、指示タイミング決定手段１０３は、更新指示１７１が入力されてから更新タイイング情報で指示された待機時間経過後の時刻を、更新指示の指示タイミングに決定することができる。
【００２９】
更新タイミング情報生成手段１０４は、サービス提供ノード３００がさらに他のサービス提供ノード（図１の場合、サービス提供ノード４００）に更新を指示するタイミングを決定するための更新タイミング情報を生成（取得）する。ここで、更新を指示するタイミングは、指示タイミング決定手段１０３が決定するタイミングと同期しないように異なる周期を有するタイミングが選択される。
【００３０】
これにより、サービス提供ノード１００が次に他のサービス提供ノードへの更新を指示するタイミングと、サービス提供ノード３００が他のサービス提供ノードへの更新を指示するタイミングとがずれる。
【００３１】
更新指示送信手段１０６は、指示タイミング決定手段が決定したタイミングで、更新指示（更新の指示と更新タイミング情報）１７２を、更新対象に選択したサービス提供ノード３００に送信する。
【００３２】
同様にして、サービス提供ノード３００は、他のサービス提供ノードとしてサービス提供ノード４００に更新指示１７３を送信する。
このように、時間間隔をあけながら更新指示を伝搬させることで、クラスタシステムを構成するサービス提供ノードは、タイミングをずらしながらソフトウェアを更新することができる。しかも、多数のノードが同時にソフトウェアを更新している状態を避けて、クラスタシステムを不安定にするおそれを回避することができる。特に、大規模なクラスタシステムにおいて多数のノードのソフトウェアを更新する場合、システム全体としての運用効率の低下や信頼性の低下を招いてしまうおそれを低減、または排除することができる。また、クラスタシステムの管理者がソフトウェアを更新をする負担（更新スケジュールの立案、更新処理の管理、更新結果のチェックなど）を軽減または排除することができる。
【００３３】
なお、管理ノード７００は、クラスタシステムを構成するサービス提供ノードに最初の更新指示１７１を与える。最初の更新指示１７１は、システム管理者の指示によるものであってもよいし、予めプログラムまたはスケジュールされたものであってもよい。最初の更新指示１７１を１台のサービス提供ノードに与えるだけで更新指示はクラスタシステムを構成するサービス提供ノードを伝播し、すべてのサービス提供ノードのソフトウェア更新は、自動でおこなわれる。ソフトウェア更新手段１０７は、更新指示１７１を受けて更新プログラムを起動する。なお、更新指示１７１に更新ファイルを含めてもよく、更新ファイルは、更新ファイル記憶手段１０８に記憶される。また、更新ファイルが初期から更新を予定していたものであれば、事前に更新ファイル記憶手段１０８に記憶させておいてもよい。また、通常のサービス提供動作中に配布されるものであってもよい。
【００３４】
なお、プログラム情報送信手段１０１は、プログラム情報を含ませて監視ノード５００にハートビートを送信したが、別途、プログラム情報を定期的に送信するようにしてもよい。また、サービス提供ノードが自発的にプログラム情報を送信する場合に限らず、監視ノード５００からの定期的なポーリング応答としてプログラム情報を送信するようにしてもよい。
【００３５】
次に、本実施の形態の詳細を説明する。図２は、本実施の形態のクラスタシステムの構成例を示す図である。本実施の形態では、スイッチ６０を介して、複数のサービス提供ノード１００、２００、３００、４００、監視ノード５００、処理要求ノード６００、および管理ノード７００が接続されている。
【００３６】
サービス提供ノード１００、２００、３００、４００は、たとえば、ＩＡ（Intel Architecture）と呼ばれるアーキテクチャのコンピュータである。サービス提供ノード１００、２００、３００、４００は、アプリケーションソフトウェアに基づいて、処理要求に応じたデータ処理を実行する機能を有する。以下、このようなデータ処理サービス機能を、単にサーバと呼ぶこととする。サービス提供ノード１００、２００、３００、４００に実装されたサーバは、監視ノード５００に対して定期的にハートビートを送信する機能を有している。
【００３７】
なお、ハートビートの間隔は任意に変更可能である。ハートビートの間隔を変更する場合、サービス提供ノード１００、２００、３００、４００から監視ノード５００に対して、ハートビートの間隔を示す情報が送信される。
【００３８】
監視ノード５００は、サービス提供ノード１００、２００、３００、４００を制御する。たとえば、監視ノード５００は、各サービス提供ノード１００、２００、３００、４００から送信されるハートビートを受信して、正常に運用しているサービス提供ノードを認識する。すなわち、監視ノード５００は、各サービス提供ノード１００、２００、３００、４００から送られてくるハートビートの間隔を示す情報に従って、サービス提供ノード１００、２００、３００、４００それぞれ個別の間隔でハートビートを待つ。指定された間隔内でのハートビートが途絶えたサービス提供ノードがあった場合、監視ノード５００は、そのサービス提供ノードを障害発生中と認識する。
【００３９】
処理要求ノード６００には、ネットワーク５０を介して複数の端末装置５１、５２、５３が接続されている。処理要求ノード６００は、サービス提供ノード１００、２００、３００、４００それぞれが管理しているデータの格納場所を認識している。そして、処理要求ノード６００は、端末装置５１、５２、５３からの要求に応答して、サービス提供ノード１００、２００、３００、４００へデータアクセスをおこなう。
【００４０】
管理ノード７００は、システム全体を管理するためのコンピュータである。たとえば、管理ノード７００は、管理者からの操作入力に応答して、サービス提供ノード１００、２００、３００、４００のいずれかに対して、サーバのソフトウェアの更新要求を送信する。
【００４１】
図３は、本実施の形態に用いる監視ノードのハードウェア構成例を示す図である。監視ノード５００は、ＣＰＵ（Central Processing Unit）５０１によって装置全体が制御されている。ＣＰＵ５０１には、バス５０７を介してＲＡＭ（Random Access Memory）５０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）５０３、グラフィック処理装置５０４、入力インタフェース５０５、および通信インタフェース５０６が接続されている。
【００４２】
ＲＡＭ５０２には、ＣＰＵ５０１に実行させるＯＳ（Operating System）のプログラムやサーバを実行するためのアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ５０２には、ＣＰＵ５０１による処理に必要な各種データが格納される。ＨＤＤ５０３には、ＯＳやアプリケーションプログラムが格納される。
【００４３】
グラフィック処理装置５０４には、モニタ６１が接続されている。グラフィック処理装置５０４は、ＣＰＵ５０１からの命令に従って、画像をモニタ６１の画面に表示させる。
入力インタフェース５０５には、キーボード６２とマウス６３とが接続されている。入力インタフェース５０５は、キーボード６２やマウス６３から送られてくる信号を、バス５０７を介してＣＰＵ５０１に送信する。
【００４４】
通信インタフェース５０６は、スイッチ６０に接続されている。通信インタフェース５０６は、スイッチ６０を介して、他のコンピュータとの間でデータの送受信をおこなう。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には監視ノードのハードウェア構成例を示したが、サービス提供ノード１００、２００、３００、４００、処理要求ノード６００、管理ノード７００、および端末装置５１、５２、５３も同様のハードウェア構成で実現できる。
【００４５】
図４は、ハートビートパケットのデータ構造例を示す図である。ハートビートパケット１５０には、送信元アドレス、宛先アドレス、アプリケーション識別番号、パケット種別識別子、ハートビート間隔情報などのフィールドが設けられている。
【００４６】
送信元アドレスのフィールドには、ハートビートパケット１５０を送信したサービス提供ノードをネットワーク上で一意に識別するためのアドレスが設定される。たとえば、サービス提供ノードのＩＰアドレスが、送信元アドレスとして設定される。
【００４７】
宛先アドレスのフィールドには、ハートビートパケット１５０の宛先となる監視ノード５００をネットワーク上で一意に識別するためのアドレスが設定される。たとえば、監視ノード５００のＩＰアドレスが、送信元アドレスとして設定される。
【００４８】
なお、送信元アドレスと宛先アドレスとのフィールドは、ハートビートパケット１５０のヘッダ情報に含まれている。
アプリケーション識別番号のフィールドには、ハートビートを出力するサーバ１１０のサーバプログラムのソフトウェアバージョンを監視ノード５００が一意に識別するための識別番号が設定される。この識別番号は、任意の２つの識別番号を比較することによってバージョンの新旧を一意に識別可能になっている。なお、識別番号は、任意の２つの識別番号を比較することによってバージョンアップの是非を判断可能であればよい。
【００４９】
パケット種別識別子のフィールドには、ハートビートパケット１５０がハートビートを通知するパケットであることを示す識別子が設定される。
ハートビート間隔情報のフィールドには、ハートビートの送信間隔を示す秒単位の数値が設定される。
【００５０】
このようなハートビートパケット１５０を受信した監視ノード５００は、サーバ運用情報記憶部５１０（図１３）内のサーバ運用情報テーブルにハートビートに基づく各サーバの運用状況を登録する。
【００５１】
図５は、ハートビート確認応答パケットのデータ構造例を示す図である。ハートビート確認応答パケット１６０には、送信元アドレス、宛先アドレス、ノード一覧などのフィールドが設けられている。
【００５２】
送信元アドレスのフィールドには、ハートビート確認応答パケット１６０を送信した監視ノード５００をネットワーク上で一意に識別するためのアドレスが設定される。たとえば、監視ノード５００のＩＰアドレスが、送信元アドレスとして設定される。
【００５３】
宛先アドレスのフィールドには、ハートビート確認応答パケット１６０の宛先となるサービス提供ノードをネットワーク上で一意に識別するためのアドレスが設定される。たとえば、サービス提供ノードのＩＰアドレスが、宛先アドレスとして設定される。
【００５４】
なお、送信元アドレスと宛先アドレスとのフィールドは、ハートビート確認応答パケット１６０のヘッダ情報に含まれている。
ノード一覧のフィールドには、さらに監視ノード５００が監視対象とするサービス提供ノードごとのフィールド１６６、１６７、１６８が監視対象となるサービス提供ノードの数だけ設けられる。サービス提供ノードごとのフィールド１６６、１６７、１６８は、さらに、それぞれＩＰアドレス、状態、バージョンなどのサブフィールドで構成される。
【００５５】
アドレスは、サービス提供ノードをネットワーク上で一意に識別するためのアドレスが設定される。たとえば、サービス提供ノードのＩＰアドレスが設定される。
状態は、対応するサービス提供ノードのハートビートパケット１５０の受信状況に基づくサービス提供ノードの状態が設定される。たとえば、定期的なハートビートパケット１５０の受信が確認できている状態では、「正常」状態が設定される。また、定期的なハートビートパケット１５０の受信が確認できていない状態では、「異常」状態が設定される。
【００５６】
バージョンは、アプリケーション識別番号または、アプリケーション識別番号に基づいて監視ノード５００が設定するバージョン比較のための情報が設定される。バージョン比較のための情報は、アプリケーション識別番号と同様に、任意の２つのバージョン比較のための情報を比較することによってバージョンの新旧を一意に識別可能になっている。なお、バージョン比較のための情報は、任意の２つのバージョン比較のための情報を比較することによってバージョンアップの是非を判断可能であればよい。
【００５７】
なお、ノード一覧の大きさ（ノード数に対応した領域数）は、ノード一覧のフィールドにノード一覧を構成するノード数の情報を付加することで把握可能にしてもよい。また、その他の方法（ノード一覧の大きさを固定、終端情報の付加など）によってノード一覧の大きさを把握可能にしてもよい。
【００５８】
このようなハートビート確認応答パケット１６０を受信したサービス提供ノードは、更新対象選択手段１０２がノード一覧を参照可能に最新のノード一覧テーブル８１０（図９）を保持する。
【００５９】
次に、ソフトウェア配布処理について図６、図７を用いて詳細に説明する。
図６は、ソフトウェア配布処理を示すフローチャートである。ソフトウェア（更新プログラム）配布処理は、自らのソフトウェアの更新を終えた後におこなわれる。図７は、更新タイミング情報表である。以下、図６に示す処理を、ステップ番号に沿って説明する。なお、この処理は、サーバ１１０により実行される。
【００６０】
［ステップＳ１１］サーバ１１０の指示タイミング決定手段１０３は、自身（配布元）のソフトウェア配布間隔を設定する。設定する配布間隔は、更新タイミング情報表８００を参照して決定する。管理ノード７００から更新指示１７１を受信してソフトウェアの更新をおこなった場合、配布回数１の行を参照して待機回数７を得る。そして、ハートビート送信間隔と待機回数との積を自身のソフトウェア配布間隔とする。たとえば、ハートビート送信間隔が１０秒で待機回数７を得た場合、自身のソフトウェア配布間隔は７０秒となる。
【００６１】
なお、更新タイミング情報表８００の配布回数は、原則として、配布元から指定される。
［ステップＳ１２］サーバ１１０の更新タイミング情報生成手段１０４は、更新対象に選択する他のサービス提供ノードのソフトウェア配布間隔を設定する。設定する配布間隔は、更新タイミング情報表８００と自身のソフトウェア配布回数を参照して決定する。自身のソフトウェア配布回数が１の場合、更新タイミング情報生成手段１０４は、自身の配布回数１に１を加えた配布回数２の行を参照して待機回数１１を得る。そして、更新タイミング情報生成手段１０４は、待機回数１１を更新対象に選択した他のサービス提供ノード（配布先）のソフトウェア配布間隔に設定する。
【００６２】
［ステップＳ１３］サーバ１１０の更新指示送信手段１０６は、ステップＳ１１で決定したソフトウェア配布間隔を配布待機時間としてタイムアップするまで待機（スリープ）する。
【００６３】
［ステップＳ１４］サーバ１１０の更新対象選択手段１０２は、ソフトウェアの配布先を決定する。この配布先決定処理は、図８を用いて後で詳述する。
［ステップＳ１５］サーバ１１０の更新指示送信手段１０６は、ステップＳ１４の配布先決定処理で配布先がない場合は、ステップＳ１３にすすむ。更新指示送信手段１０６は、配布先がある場合は、ステップＳ１６にすすむ。
【００６４】
［ステップＳ１６］サーバ１１０の更新指示送信手段１０６は、ステップＳ１４の配布先決定処理で決定した配布先に、ソフトウェアを配布してソフトウェア更新を指示する。なお、ソフトウェアの配布は、予めしておいてもよく、その場合、ソフトウェアの配布なしにソフトウェア更新を指示するだけであってもよい。なお、ソフトウェアの配布先のアドレスは、ノード一覧テーブル８１０を参照して取得する。
【００６５】
［ステップＳ１７］サーバ１１０の更新タイミング情報生成手段１０４は、次に更新対象に選択する他のサービス提供ノードのソフトウェア配布間隔を設定する。設定する配布間隔は、更新タイミング情報表８００とステップＳ１２で設定した他のサービス提供ノードのソフトウェア配布回数とを参照して決定する。ステップＳ１２で設定した他のサービス提供ノードのソフトウェア配布回数が２の場合、更新タイミング情報生成手段１０４は、ステップＳ１２で設定した他のサービス提供ノードのソフトウェア配布回数２に１を加えた配布回数３の行を参照して待機回数１３を得る。そして、更新タイミング情報生成手段１０４は、待機回数１３を更新対象に選択した他のサービス提供ノード（配布先）のソフトウェア配布間隔に設定して、ステップＳ１２にすすむ。
【００６６】
したがって、配布回数は、他のサービス提供ノードにソフトウェアを配布するごとに１ずつインクリメントされる。これにより、ソフトウェア配布ごとの待機回数を異ならせることができる。
【００６７】
なお、更新タイミング情報表８００は、配布回数と待機回数とを対応付けた表である。待機回数は、配布回数が異なれば待機回数も異なる値に設定されている。また、待機回数は、配布回数の増加につれて単調増加するように配列されている。また、待機回数は、素数で構成され、初期値（配布回数１に対応する待機回数）は小さすぎない値として７が設定されている。
【００６８】
なお、待機回数の配列に素数を昇順に配列したが、これに限らず任意の配列を採用することができる。
このようにして、ソフトウェアの更新を終えたサービス提供ノードは、他のサービス提供ノードにタイミングをずらしながらソフトウェアの更新を指示する。また、ソフトウェアの更新を終えたサービス提供ノードは、他のサービス提供ノードがソフトウェアの更新を指示するタイミングがずれるように順次指示する。これにより、クラスタシステムを構成するサービス提供ノードのソフトウェア更新タイミングは、クラスタシステム内をタイミングをずらしながら伝播する。したがって、このようなクラスタシステムでは、多数のノードが同時にソフトウェアを更新している状態が回避され、ソフトウェア更新状態であってもシステムが安定する。特に、大規模なクラスタシステムにおいて多数のノードのソフトウェアを更新する場合、システム全体としての運用効率の低下や信頼性の低下を招いてしまうおそれを低減、または排除することができる。
【００６９】
次に、配布先決定処理について図８、図９を用いて詳細に説明する。
図８は、配布先決定処理を示すフローチャートである。配布先決定処理は、ソフトウェア配布処理のステップＳ１４で実行される。図９は、ノード一覧テーブルである。以下、図８に示す処理を、ステップ番号に沿って説明する。なお、この処理は、サーバ１１０の更新対象選択手段１０２により実行される。
【００７０】
［ステップＳ２１］サーバ１１０の更新対象選択手段１０２は、ノード一覧テーブル８１０を取得する。
なお、ノード一覧テーブル８１０は、ハートビート確認応答パケット１６０のノード一覧のフィールドに基づいて生成される。ノード一覧テーブル８１０は、ＩＰアドレス、状態、ＶＥＲ（バージョン）を１組にして、監視ノード５００が監視対象とするサービス提供ノードの数の要素から構成される。
【００７１】
ノード一覧テーブル８１０では、ＩＰアドレスが１９２．１６８．０．２のサービス提供ノードは、「正常」状態であり、ＶＥＲ１．５のソフトウェアで起動していることを示す。また、ＩＰアドレスが１９２．１６８．０．３のサービス提供ノードは、「正常」状態であり、ＶＥＲ１．５のソフトウェアで起動していることを示す。また、ＩＰアドレスが１９２．１６８．０．４のサービス提供ノードは、「正常」状態であり、ＶＥＲ１．３のソフトウェアで起動していることを示す。また、ＩＰアドレスが１９２．１６８．０．５のサービス提供ノードは、「正常」状態であり、ＶＥＲ１．４のソフトウェアで起動していることを示す。
【００７２】
［ステップＳ２２］サーバ１１０の更新対象選択手段１０２は、ノード一覧テーブル８１０を参照して更新対象バージョンのサービス提供ノードを抽出する。まず、「正常」状態にあるサービス提供ノードを抽出する。「異常」状態にあるサービス提供ノードは、ソフトウェア更新の対象とならない。次に、自身のソフトウェアのバージョンを確認する。この場合、自身のＩＰアドレスが１９２．１６８．０．２のサービス提供ノードであるとすれば、ＶＥＲ１．５である。そうすると、ＶＥＲ１．３のＩＰアドレスが１９２．１６８．０．４のサービス提供ノードと、ＶＥＲ１．４のＩＰアドレスが１９２．１６８．０．５のサービス提供ノードとを抽出できる。
【００７３】
なお、自身のバージョンの確認は、ノード一覧テーブル８１０によらずともアプリケーション識別番号から可能な場合もある。また、アプリケーション識別番号からバージョンの新旧の比較が容易でない場合は、監視ノードがアプリケーション識別番号をバージョンの新旧の比較が容易なＶＥＲに変換して各サービス提供ノードに提供してもよい。
【００７４】
［ステップＳ２３］サーバ１１０の更新対象選択手段１０２は、ステップＳ２２で抽出したサービス提供ノードのうち二重化強度の最も低いサービス提供ノードを選択する。二重化強度が同じであれば、無作為に、またはその他の方法でいずれか一方を選択する。二重化強度の低いサービス提供ノードを選択するのは、ある単位時間のなかで関係強度の低いサービス提供ノードがソフトウェアを更新する方がシステムの安定性向上のために望ましいからである。
【００７５】
そして、更新対象選択手段１０２は、いずれか１つのサービス提供ノードを抽出して配布先として決定する、または対象となるサービス提供ノードが存在しないことを確認して終了する。
【００７６】
なお、二重化強度とは、自身のサービス提供ノードと他のサービス提供ノードとの結びつき（関係）の強さを表す。特に、データをセグメント化して高信頼化のために二重化（プライマリセグメントデータ、セカンダリセグメントデータ）して、複数のサービス提供ノードに分散化したシステムにおける結びつきの強さを表す。
【００７７】
なお、二重化強度の評価は、プライマリセグメントデータとセカンダリセグメントデータとして二重化しているデータの大きさや数で評価してもよい。また、二重化強度の評価は、過去一定時間の通信相手ごとの通信量で評価してもよい。
【００７８】
次に、この二重化強度の評価に用いる指標を得るための二重化強度監視処理を図１０、図１１を用いて詳細に説明する。
図１０は、二重化強度監視処理を示すフローチャートである。二重化強度監視処理は、サーバ１１０により実行される。図１１は、二重化強度評価のための通信量表である。以下、図１０に示す処理を、ステップ番号に沿って説明する。
【００７９】
［ステップＳ３１］サーバ１１０は、サービス提供ノード別の単位時間（たとえば、１秒）当たりの通信量を時刻を付して記録する。
［ステップＳ３２］サーバ１１０は、監視期間（たとえば、１時間）を取得する。
【００８０】
［ステップＳ３３］サーバ１１０は、サービス提供ノード別の監視期間（たとえば、１秒）中のステップＳ３１で記録した通信量を集計して通信量表８２０に記録、更新する。
通信量表８２０によれば、ＩＰアドレスが１９２．１６８．０．３のサービス提供ノードとの速度（通信速度）は、１５Ｋｂｐｓ（ビット／秒）である。また、ＩＰアドレスが１９２．１６８．０．４のサービス提供ノードとの速度は、２０Ｋｂｐｓである。また、ＩＰアドレスが１９２．１６８．０．５のサービス提供ノードとの速度は、１０Ｋｂｐｓである。通信量が多いほど二重化強度が強いと評価できるので、二重化強度を監視しているサービス提供ノードと最も二重化強度の弱いサービス提供ノードは、ＩＰアドレスが１９２．１６８．０．５のサービス提供ノードとなる。
【００８１】
なお、監視期間は、ソフトウェアの更新時間よりも長い監視期間を設定することが望ましい。
なお、図９のノード一覧テーブル８１０、図１１の通信量表８２０によれば、ソフトウェア配布処理のステップＳ１４で実行される配布先決定処理では、以下のようにしてソフトウェアの配布先となるサービス提供ノードが決定される。まず、ノード一覧テーブル８１０からＩＰアドレスが１９２．１６８．０．４と１９２．１６８．０．５の２つのサービス提供ノードが抽出される（ステップＳ２２）。次に、ＩＰアドレスが１９２．１６８．０．４の速度２０ＫｂｐｓとＩＰアドレスが１９２．１６８．０．５の速度１０Ｋｂｐｓを比較して二重化強度を評価する。その結果、ＩＰアドレスが１９２．１６８．０．５のサービス提供ノードの方が二重化強度が弱いとして抽出される。
【００８２】
図１２は、ソフトウェア更新指示の伝播を表すダイヤグラム図である。サービス提供ノードとして、ノードＡ、ノードＢ、ノードＣ、ノードＤ、ノードＥ、ノードＦを有するクラスタシステムをモデルにして説明する。図１２中の「丸印」は、ソフトウェアの更新を表す。現実には、更新の指示を受けてから更新終了には時間を要するが、簡潔にするため丸印の一点で表している。図１２中の「ばつ丸印」は、更新の指示のキャンセル動作を表す。図１２中の「四角印」は、更新の指示動作を表す。図１２中の「縦線（破線）」は、サーバが旧バージョンのソフトウェアで動作している状態を表す。図１２中の「縦線（実線）」は、サーバが新バージョンのソフトウェアで動作している状態を表す。
【００８３】
ノードＡは、ソフトウェアの更新をする（動作ＴＡ１）。ノードＡは、自身のソフトウェア配布間隔を１１０秒に設定（待機回数１１、ハートビート間隔１０秒）しているので、動作ＴＡ１の１１０秒後にノードＢにソフトウェアの更新を指示する（動作ＴＡ２）。このとき、ノードＡは、配布回数２（待機回数１１）で最初の配布なので、ノードＢに配布回数３（待機回数１３）を設定するように指示する。そして、動作ＴＡ２から１１０秒経過後にノードＣにソフトウェアの更新を指示する（動作ＴＡ３）。このとき、ノードＡは、配布回数２（待機回数１１）で２回目の配布なので、ノードＣに配布回数４（待機回数１７）を設定するように指示する。そして、動作ＴＡ３から１１０秒経過後にノードＥにソフトウェアの更新を指示する（動作ＴＡ４）。このとき、ノードＡは、配布回数２（待機回数１１）で３回目の配布なので、ノードＥに配布回数５（待機回数１９）を設定するように指示する。そして、動作ＴＡ４から１１０秒経過後にノードＦにソフトウェアの更新を指示する（動作ＴＡ５）。このとき、ノードＡは、配布回数２（待機回数１１）で４回目の配布なので、ノードＦに配布回数６（待機回数２３）を設定するように指示する。以降、配布対象のノードがなくなるまでソフトウェアの更新の指示を繰り返す。このように、配布元は、自身のソフトウェア配布間隔を固定にして定期的に他のノードにソフトウェアの更新を指示する。さらに配布元は、他のノードにソフトウェアの更新を指示するたびに、他のノードが配布元となったときのソフトウェア配布間隔がそれぞれ拡散するようにそれぞれ異なる配布回数を指示する。
【００８４】
ノードＢは、ソフトウェアの更新をする（動作ＴＢ１）。ノードＢは、自身のソフトウェア配布間隔を１３０秒に設定（待機回数１３、ハートビート間隔１０秒）しているので、動作ＴＢ１の１３０秒後にノードＤにソフトウェアの更新を指示する（動作ＴＢ２）。このとき、ノードＢは、配布回数３（待機回数１３）で最初の配布なので、ノードＤに配布回数４（待機回数１７）を設定するように指示する。そして、動作ＴＢ２から１３０秒経過後にノードＥにソフトウェアの更新を指示する（動作ＴＢ３）。このとき、ノードＢは、配布回数３（待機回数１３）で２回目の配布なので、ノードＥに配布回数５（待機回数１９）を設定するように指示する。そして、ノードＢは、動作ＴＢ３から１３０秒経過後に配布対象のノードがないことからソフトウェアの更新を指示しない。このように、配布元であるノードＡとノードＢとで配布タイミングが異なることから、ノードＣとノードＤのソフトウェア更新タイミングに、動作ＴＡ３と動作ＴＢ２で２０秒、動作ＴＡ４と動作ＴＢ３で４０秒のタイムラグが生じている。このタイムラグにより、複数のノード（たとえば、ノードＣとノードＤ）が同時にソフトウェア更新をおこなうことに基づくクラスタシステムの不安定化要因を排除することができる。この効果は、配布世代が次世代、次次世代とすすむほどに大きくなる。
【００８５】
ノードＣは、ソフトウェアの更新をする（動作ＴＣ１）。ノードＣは、自身のソフトウェア配布間隔を１７０秒に設定（待機回数１７、ハートビート間隔１０秒）しているので、動作ＴＣ１の１７０秒後にノードＦにソフトウェアの更新を指示する（動作ＴＣ２）。このとき、ノードＣは、配布回数４（待機回数１７）で最初の配布なので、ノードＦに配布回数５（待機回数１９）を設定するように指示する。
【００８６】
ノードＤは、ソフトウェアの更新をする（動作ＴＤ１）。ノードＤは、自身のソフトウェア配布間隔を１７０秒に設定（待機回数１７、ハートビート間隔１０秒）しているので、動作ＴＤ１の１７０秒後に配布対象のノードがあれば、ソフトウェアの更新を指示する（動作ＴＤ２）。このとき、ノードＤは、配布回数４（待機回数１７）で最初の配布なので、対象となるノードに配布回数５（待機回数１９）を設定するように指示する。
【００８７】
ここで、ノードＣとノードＤとは、ソフトウェア配布間隔が同じ１７０秒であるが、２０秒のタイムラグがある。このタイムラグは、クラスタシステム内のソフトウェア更新タイミングの分散化に寄与している。
【００８８】
ノードＥは、ソフトウェアの更新をする（動作ＴＥ１）。また、動作ＴＥ２でソフトウェア更新の指示を受けても、既にソフトウェアを更新済みのため動作ＴＢ３でのノードＢのソフトウェア更新の指示は無視される。
【００８９】
ノードＦは、ソフトウェアの更新をする（動作ＴＦ１）。また、動作ＴＦ２でソフトウェア更新の指示を受けても、既にソフトウェアを更新済みのため動作ＴＡ５でのノードＡのソフトウェア更新の指示は無視される。
【００９０】
このように、クラスタシステム内でソフトウェアの更新指示を伝播させても、適当にタイムラグを生じ、クラスタシステム内で同時に多数のノード（サービス提供ノード）がソフトウェア更新中になるという状況を回避することができる。
【００９１】
次に、ソフトウェア更新（サーバプログラムの更新）について、図１３、図１４、図１５を用いて説明する。図１３は、分散処理システムの機能ブロック図である。サービス提供ノード１００は、サーバプログラムの更新時の様子を表している。サーバプログラムの更新は、旧サーバ１１０ａと新サーバ１１０ｂとが同時に起動して、旧サーバ１１０ａから新サーバ１１０ｂにサーバ機能を委譲する。これにより、サーバ１１０が提供するサービスの停止時間を最小限度にしてシステムの信頼性を高めている。
【００９２】
旧サーバ１１０ａ、新サーバ１１０ｂは、サービス提供をおこなう処理機能（プロセス）であり、旧版と新版のバージョン違いである。
サービス提供ノード１００の提供するサーバ機能（サービス）は、サービス提供ノード１００がサーバソフトウェアを実行することによって実現される。図１３の機能ブロック図では、このサーバソフトウェアの更新のために、旧サーバ１１０ａと新サーバ１１０ｂの２つのサーバが起動している状態を示している。
【００９３】
サーバ１１０ａ、１１０ｂには、それぞれ、サービス通信処理部１１１ａ、１１１ｂとサービス処理部１１２ａ、１１２ｂとハートビート通信処理部１１３ａ、１１３ｂとプロセス間通信処理部１１４ａ、１１４ｂとが含まれる。
【００９４】
サービス通信処理部１１１ａ、またはサービス通信処理部１１１ｂは、ソケット１２０ａを作成して、あるいは作成済みのソケット１２０ａを介して処理要求ノード６００と通信をする。サービス通信処理部１１１ａ、またはサービス通信処理部１１１ｂは、処理要求ノード６００から送信された処理要求を受け付け、対応するサービス処理部１１２ａ、１１２ｂに要求されたサービス処理を依頼する。そして、サービス通信処理部１１１ａ、またはサービス通信処理部１１１ｂは、対応するサービス処理部１１２ａ、１１２ｂから受領した処理結果を処理要求ノード６００に送信する。
【００９５】
サービス処理部１１２ａ、１１２ｂは、サービス通信処理部１１１ａ、１１１ｂに依頼されたサービス処理を実行し、得た処理結果をサービス通信処理部１１１ａ、１１１ｂに応答する。
【００９６】
ハートビート通信処理部１１３ａ、１１３ｂは、ソケット１２０ｂを作成して、監視ノード５００に対して定期的にハートビートパケット１５０を送信する。なお、ハートビート通信処理部１１３ａ、１１３ｂは、ハートビートパケット１５０内にハートビートの送信間隔を示す情報（ハートビート間隔情報）を含めることで、現在のハートビートの送信間隔を監視ノード５００に伝える。ハートビートパケット１５０の送信間隔は、予め初期状態が決められており、条件に応じて変更できる。
【００９７】
プロセス間通信処理部１１４ａ、１１４ｂは、ソケット１２０ｃ、１２０ｄを作成してプロセス間通信をおこなう。プロセス間通信処理部１１４ａ、１１４ｂは、プロセス間通信により、旧サーバ１１０ａから新サーバ１１０ｂへの切り替えに必要なデータの送受信をする。必要なデータの送受信が完了すると、プロセス間通信処理部１１４ａ、１１４ｂは、旧サーバ１１０ａから新サーバ１１０ｂへとサーバ機能を切り替えて旧サーバ１１０ａを終了させる。このように、ネットワークを介して接続された装置に対してサーバ１１０ａ、１１０ｂのいずれかが応答可能な状態（通信路が確保された状態）で、旧サーバ１１０ａから新サーバ１１０ｂへのデータの承継がされる。
【００９８】
また、サービス提供ノード１００は、更新指示部７２０の指示（更新指示）に従って新サーバ１１０ｂを起動する。更新指示部７２０は、管理者からの操作入力に応答して、サービス提供ノード１００にソフトウェアの更新要求を送信する。新サーバ１１０ｂのサーバソフトウェア（更新プログラム）は、更新ファイル記憶部７１０からサービス提供ノード１００に配布される。
【００９９】
なお、更新要求を送信する際に、更新指示部７２０は、更新ファイル記憶部７１０から更新プログラムを取得し、更新要求とともに更新プログラムをサービス提供ノード１００に送信するようにしてもよいし、更新要求に先立ち予め送信するようにしてもよい。また、更新プログラムは、サービス提供ノード１００が可搬性のある記録媒体を通じて読み込んだものであってもよいし、あるいは更新を予定したプログラムとして予めサービス提供ノード１００内のＨＤＤに記憶したものであってもよい。
【０１００】
監視ノード５００は、サーバ運用情報記憶部５１０とノード監視部５２０とを有している。サーバ運用情報記憶部５１０は、サーバ運用情報を記憶する。サービス提供ノード１００、２００、３００、４００に実装されているサーバが運用中か否かを管理するデータテーブルである。たとえば、ＲＡＭ５０２の記憶領域の一部がサーバ運用情報記憶部５１０として使用される。
【０１０１】
処理要求ノード６００は、処理要求部６１０を有している。処理要求部６１０は、ネットワーク５０を介して端末装置５１〜５３から送られてくる処理要求を、いずれかのサービス提供ノード１００、２００、３００、４００に送信する。たとえば、処理要求ノード６００は、サービス提供ノード１００、２００、３００、４００からそれぞれの負荷情報を取得し、負荷の少ないサービス提供ノードに対して処理要求を送信する。また、処理要求部６１０は、処理要求を送信したサービス提供ノードから応答が返されると、処理要求を出力した端末装置に対してその応答を送信する。
【０１０２】
管理ノード７００は、更新ファイル記憶部７１０と更新指示部７２０とを有している。更新ファイル記憶部７１０は、サーバ１１０を更新するためのプログラムファイル（更新ファイル）を記憶する。たとえば、管理ノード７００のハードディスク装置の記憶領域の一部が更新ファイル記憶部７１０として使用される。
【０１０３】
なお、プロセス間通信は、ソケットを用いる方法に限らない。たとえば、ファイルマッピングやパイプを用いることもできる。
図１４、図１５は、ソフトウェア更新処理手順を示すシーケンス図である。以下、図１４、図１５に示す処理をステップ番号に沿って説明する。
【０１０４】
［ステップＳ４１］サービス提供ノード１００のサーバ１１０ａ（旧サーバ）が有するハートビート通信処理部１１３ａは、サーバ１１０ａが起動されている間、予めデフォルト値として設定されたハートビート送信間隔でハートビートパケット１５０を送信する。この際、ハートビートの送信間隔が１０秒と指定されているものとする。
【０１０５】
［ステップＳ４２］監視ノード５００のノード監視部５２０は、ハートビートパケット１５０を取得してサーバ１１０の正常動作を確認する。そして、ノード監視部５２０は、サーバ運用情報記憶部５１０内のサーバ１１０に対応するハートビート取得時刻の欄に、現在の時刻を設定する。そして、ノード監視部５２０は、確認応答としてハートビート確認応答パケット１６０をサーバ１１０ａに送信する。
【０１０６】
これにより、サービス提供ノード１００のサーバ１１０ａは、クラスタシステム内における他のサービス提供ノード２００、３００、４００のアドレス、状態、ＶＥＲを把握することができる。
【０１０７】
［ステップＳ４３］サービス提供ノード１００は、サーバ１１０ｂ（新サーバ）を起動する。サーバ１１０ｂの起動は、管理ノード７００の更新指示部７２０からの指示に基づいてすることができる。なお、タイマやオペレータによるリモート操作などによっても起動することができる。
【０１０８】
［ステップＳ４４］サーバ１１０ｂのプロセス間通信処理部１１４ｂは、ソケット１２０ｄを作成して、サーバ１１０ａが作成しているソケット１２０ｃとの間でプロセス間通信路を確立する。このプロセス間通信路の確立は、サーバ１１０ｂがサーバ１１０ａの通信相手先情報を既知とし、サーバ１１０ａが既知とされる通信相手先情報のソケット１２０ｃを作成して、サーバ１１０ｂの接続を待つことで実現している。そして、プロセス間通信処理部１１４ａとプロセス間通信処理部１１４ｂとで通信がなされる。
【０１０９】
［ステップＳ４５］処理要求ノード６００の処理要求部６１０は、端末装置から出されたサービス要求（処理要求）をサービス提供ノード１００に送信する。このとき、サービス要求の送信先のポート番号として、サーバ１１０ａが開設しているポート番号が指定される。そして、サービス提供ノード１００のサーバ１１０ａ内のサービス通信処理部１１１ａは、処理要求ノード６００からのサービス要求を受信する。
【０１１０】
［ステップＳ４６］サーバ１１０ａのプロセス間通信処理部１１４ａは、サーバ１１０ｂからのプロセス間通信路確立の要求に応答する。なお、プロセス間通信路確立の応答は、ステップＳ４５のサービス要求を待ってするものではない。遅滞なく応答するところ、ステップＳ４５のサービス要求がイベント的に発生したことを示すに過ぎない。
【０１１１】
［ステップＳ４７］サーバ１１０ａのサービス通信処理部１１１ａは、ステップＳ４５のサービス要求に対応して、サーバ１１０ａのサービス提供状態が「通常」状態であることを確認してから、受け付けたサービス処理をサービス処理部１１２ａに依頼する。そして、サービス通信処理部１１１ａは、サービス処理部１１２ａから受領したサービス応答（処理結果）を処理要求部６１０に送信する。処理要求部６１０は、応答を受信し、応答で示される処理結果を端末装置に送信する。
【０１１２】
なお、サーバ１１０のサービス提供状態には、サービスを提供可能な「通常」状態と、サービスの提供を一時的に停止する「一時停止」状態と、サービスを終了する「終了」状態とを有する。なお、「通常」状態では、サーバ１１０は、サービスの受け付けとサービスの応答ともにする。「一時停止」状態では、サーバ１１０は、サービスの受け付けをするが、有効なサービスの応答を停止する。「終了」状態では、サーバ１１０は、サービスの受け付け、サービスの応答ともに停止する。
【０１１３】
［ステップＳ４８］サーバ１１０ｂのプロセス間通信処理部１１４ｂは、プロセス間通信路確立の応答を受けて、サーバ１１０ａに認証を要求する。認証要求の際に、プロセス間通信処理部１１４ｂは、サーバ１１０ｂの正当性を検証可能な特定の情報を送信する。特定の情報は、たとえば、文字列や数列、特定のコードなどがある。
【０１１４】
［ステップＳ４９］サーバ１１０ａのプロセス間通信処理部１１４ａは、サーバ１１０ｂからの認証要求に応答する。プロセス間通信処理部１１４ａは、認証要求の際に送信されてきた特定の情報について検証して正当性（サーバ１１０ａの承継相手先としてサーバ１１０ｂが正当であるか）を確認する。
【０１１５】
［ステップＳ５０］サーバ１１０ａのハートビート通信処理部１１３ａは、ハートビート送信間隔でハートビートパケット１５０を送信する。
［ステップＳ５１］ノード監視部５２０は、ハートビートパケット１５０を取得してサーバ１１０の正常動作を確認する。また、ノード監視部５２０は、サーバ運用情報記憶部５１０内のサーバ１１０に対応する情報を更新する。そして、ノード監視部５２０は、確認応答としてハートビート確認応答パケット１６０をサーバ１１０ａに送信する。
【０１１６】
［ステップＳ５２］サーバ１１０ｂのプロセス間通信処理部１１４ｂは、認証の応答を受けて、サーバ１１０ａにバージョン判定を要求する。バージョン判定要求の際には、サーバ１１０ａがバージョンアップの是非を確認可能なバージョン情報を送信する。バージョン情報は、たとえば、サーバ１１０ｂのバージョン（版数）、バージョンの新旧を比較可能な数列、バージョンアップの制限などの付加情報などがある。
【０１１７】
［ステップＳ５３］サーバ１１０ａのプロセス間通信処理部１１４ａは、サーバ１１０ｂからのバージョン判定要求に応答する。バージョン判定要求の際に送信されてきたバージョン情報について検証してバージョンアップの是非を判断して結果を応答する。
【０１１８】
［ステップＳ５４］サーバ１１０ｂのプロセス間通信処理部１１４ｂは、バージョンアップを可とする判定結果の応答を受けて、サーバ１１０ａにサーバ機能の一時停止を要求する。
【０１１９】
［ステップＳ５５］サーバ１１０ａのハートビート通信処理部１１３ａは、サーバ１１０ｂからの一時停止要求を受けて、ソフトウェア更新に十分な時間値として設定されたハートビート送信間隔でハートビートパケット１５０を送信する。この際、ハートビートの送信間隔が１２０秒と指定されているものとする。これは、サーバ１１０ａからサーバ１１０ｂへのサーバ機能承継の準備時間の確保と、ノード監視部５２０にサーバ１１０ａが起動されていることを知らせるためである。また、サーバ１１０ａは、一時停止要求を受けたことで、サービスの提供を一時停止する。
【０１２０】
［ステップＳ５６］ノード監視部５２０は、ハートビートパケット１５０を取得してサーバ１１０の正常動作を確認する。また、ノード監視部５２０は、サーバ運用情報記憶部５１０内のサーバ１１０に対応する情報を更新する。このとき、サーバ運用情報記憶部５１０内のサーバ１１０に対応するハートビート間隔情報のフィールドには、ハートビートの送信間隔１２０秒が設定される。そして、ノード監視部５２０は、確認応答としてハートビート確認応答パケット１６０をサーバ１１０ａに送信する。
【０１２１】
［ステップＳ５７］サーバ１１０ａのプロセス間通信処理部１１４ａは、サーバ１１０ｂからの一時停止要求に応答する。一時停止要求の応答は、サービスの提供を一時停止した後におこなわれる。一時停止要求より先にサービス要求を受け付けていた場合には、サービス応答をしてからサービスの提供の一時停止をする。一時停止要求より後にサービス要求を受け付けた場合（ステップＳ５９）には、プロセス間通信処理部１１４ａは、ＢＵＳＹ応答（資源不足を示す応答）をする（ステップＳ６１）。ＢＵＳＹ応答をすることで、サーバ機能が停止していないことを知らせ、サーバ停止時の対応となるトラブル対応を避けることができる。ＢＵＳＹ応答を受け取った処理要求部６１０は、所定時間（たとえば、ランダム時間）経過後に再度、サービス要求を送信する。
【０１２２】
［ステップＳ５８］サーバ１１０ｂのプロセス間通信処理部１１４ｂは、一時停止要求の応答を受けて、サーバ１１０ａにサーバ機能を承継するための情報を要求する。要求する情報には、たとえば、各種サービスを提供するための情報、ハートビート通信をするための情報、サーバソフトウェアの管理情報などがある。情報要求は、所定単位（たとえば、データ項目、データ量など）で必要な回数だけ繰り返し要求する（ステップＳ６２、ステップＳ６４）。
【０１２３】
［ステップＳ６０］サーバ１１０ａのプロセス間通信処理部１１４ａは、サーバ１１０ｂから要求された情報を応答する。応答は、要求される都度する（ステップＳ６３、ステップＳ６５）。
【０１２４】
［ステップＳ６６］サーバ１１０ｂのプロセス間通信処理部１１４ｂは、情報取得の応答を受けて必要な情報のすべてを取得したと判断したら、受信完了した旨を受信完了通知により通知する。
【０１２５】
［ステップＳ６７］サーバ１１０ａのプロセス間通信処理部１１４ａは、受信完了通知を了解した旨を応答する。
［ステップＳ６８］サーバ１１０ｂのプロセス間通信処理部１１４ｂは、受信完了通知に対する応答を受けてサーバ機能の承継処理を完了した旨の完了通知を送信する。以降、サーバ１１０ｂは、サーバ１１０ａからサーバ機能を承継し、サーバ１１０としてサーバ機能を提供する。また、サービス提供ノード１００のサーバ１１０ｂ内のサービス通信処理部１１１ｂは、処理要求ノード６００からのサービス要求を受信する。
【０１２６】
［ステップＳ６９］サーバ１１０ａのプロセス間通信処理部１１４ａは、完了通知を受ける。完了通知を受けて、サーバ１１０ａのサーバ機能を提供したプロセスは、終了する。
【０１２７】
このように３段階のハンドシェイクによりサーバ機能の承継処理を完了するので、サーバ機能承継の信頼性を高めることができる。
［ステップＳ７０］サーバ１１０ｂのハートビート通信処理部１１３ｂは、サーバ機能承継処理の完了を受けてデフォルト値として設定されたハートビート送信間隔でハートビートパケット１５０を送信する。この際、ハートビートの送信間隔が１０秒と指定されているものとする。また、ソフトウェアの更新が完了したことから、ハートビートパケット１５０のアプリケーション識別番号のフィールドには、更新後のソフトウェアの識別番号が設定される。
【０１２８】
［ステップＳ７１］ノード監視部５２０は、ハートビートパケット１５０を取得してサーバ１１０の正常動作を確認する。また、サーバ運用情報記憶部５１０内のサーバ１１０に対応する情報を更新する。このとき、サーバ運用情報記憶部５１０内のサーバ１１０に対応するハートビート間隔情報のフィールドには、ハートビートの送信間隔１０秒が設定される。そして、ノード監視部５２０は、確認応答としてハートビート確認応答パケット１６０をサーバ１１０ｂに送信する。これにより、他のサービス提供ノードは、サービス提供ノード１００のサーバプログラムが更新されたことを知ることができる。また、サーバ１１０ｂは、図６のソフトウェア配布処理を開始する。そして、この後、サーバ１１０ｂは、ハートビートパケット１５０の送信が待機回数だけなされる間、ソフトウェアの配布を待機する（図６のステップＳ１３）。
【０１２９】
［ステップＳ７２］処理要求ノード６００の処理要求部６１０は、端末装置から出されたサービス要求をサービス提供ノード１００に送信する。そして、サービス提供ノード１００のサーバ１１０ｂ内のサービス通信処理部１１１ｂがサービス要求を受信する。
【０１３０】
［ステップＳ７３］サーバ１１０ｂのサービス通信処理部１１１ｂは、ステップＳ７２のサービス要求に対応して、サービス提供状態が「通常」状態であることを確認してから、受け付けたサービス処理をサービス処理部１１２ｂに依頼する。そして、サービス通信処理部１１１ｂは、サービス処理部１１２ｂから受領したサービス応答（処理結果）を処理要求部６１０に送信する。処理要求部６１０は、応答を受信し、応答で示される処理結果を端末装置に送信する。
【０１３１】
なお、図１５では、ステップＳ７３の後、所定回数のハートビート通信と、確認応答通信を図示省略して、ステップＳ７４に至る。
［ステップＳ７４］サーバ１１０ｂのハートビート通信処理部１１３ｂは、デフォルト値として設定されたハートビート送信間隔でハートビートパケット１５０を送信する。
【０１３２】
［ステップＳ７５］ノード監視部５２０は、ハートビートパケット１５０を取得してサーバ１１０の正常動作を確認する。また、サーバ運用情報記憶部５１０内のサーバ１１０に対応する情報を更新する。このとき、サーバ運用情報記憶部５１０内のサーバ１１０に対応するハートビート間隔情報のフィールドには、ハートビートの送信間隔１０秒が設定される。そして、ノード監視部５２０は、確認応答としてハートビート確認応答パケット１６０をサーバ１１０ｂに送信する。
【０１３３】
［ステップＳ７６］サーバ１１０ｂは、ソフトウェアの配布先があれば待機時間の後に、更新対象ノードに対してソフトウェアの配布をする（図６のステップＳ１６）。
このように、プロセス間通信によりサーバ１１０ａからサーバ１１０ｂにサーバ機能の承継に必要な情報を伝達する。また、処理要求部６１０に対して、サーバ機能承継処理中のＢＵＳＹ応答によりサーバ機能がダウンしていないことを明らかにすることができる。資源（通信資源、メモリ資源、ＣＰＵ時間など）不足は、サービス提供ノード１００におけるハードウェアやソフトウェアの障害と異なり、一定時間待つことで解消されることが期待できる。そのため、資源不足の応答を受け取った処理要求部６１０は、処理要求のリトライをおこなう。通常は、リトライを何度か繰り返しても資源不足が解消されない場合に、処理要求部６１０はエラー処理をおこなう。したがって、サーバ機能の承継中のＢＵＳＹ応答は、本来発生していないエラーに対するエラー処理の実行を回避する役割を果たす。また、エラー判定の精度が向上するため、誤ったエラー判定を回避するための判定条件の余裕を制限することができ、より迅速なエラー判定に貢献する。
【０１３４】
また、ノード監視部５２０に対しても、ハートビート通信の送信間隔の変更と、送信元のハートビート通信処理部１１３ａからハートビート通信処理部１１３ｂへの承継によりサーバ機能がダウンしていないことを明らかにして、不要のトラブル処理を回避する。
【０１３５】
なお、サーバ１１０ａは、既存のソフトウェアにより実行されている、ソフトウェア更新の対象となるサーバである。サーバ１１０ａは、サービス提供ノード１００において現にサービスを提供している。サーバ１１０ｂは、新規ソフトウェアにより実行されるサーバであり、サービス提供ノード１００において既存サーバからサーバ機能を承継する。
【０１３６】
なお、新規ソフトウェアは、既存ソフトウェアについて機能拡張や更新、修正などがなされたもので、各々のソフトウェアは版数管理される。版数管理された各々のソフトウェアは、旧版から新版にサーバ機能承継（旧プロセスから新プロセスへの処理の承継）に必要な情報を伝達する機能を有する。具体的には、プロセス間通信による情報伝達で同一資源（たとえば、通信資源、メモリ資源）へのアクセスを可能としている。
【０１３７】
次に、図１１を用いて説明した二重化強度の評価に用いる指標の変形例について説明する。図１６は、二重化強度評価のための通信量表である。図１１の通信量表８２０では、通信量を単位時間当たりの速度を記録していたが、図１６の通信量表８３０では、通信量を単位時間当たりの頻度で記録している点で異なる。特に、通信回線の容量が大きく通信速度の大小よりも、通信頻度の多少で評価した方が望ましいときに有利である。
【０１３８】
なお、図９のノード一覧テーブル８１０、図１６の通信量表８３０によれば、ソフトウェア配布処理のステップＳ１４で実行される配布先決定処理では、以下のようにしてソフトウェアの配布先となるサービス提供ノードが決定される。まず、ノード一覧テーブル８１０からＩＰアドレスが１９２．１６８．０．４と１９２．１６８．０．５の２つのサービス提供ノードが抽出される（ステップＳ２２）。次に、ＩＰアドレスが１９２．１６８．０．４の頻度３０回／時とＩＰアドレスが１９２．１６８．０．５の頻度２０回／時を比較して二重化強度を評価する。その結果、ＩＰアドレスが１９２．１６８．０．５のサービス提供ノードの方が二重化強度が弱いとして抽出される。
【０１３９】
次に、図２を用いて説明したクラスタシステムの構成の変形例について、図１７から図１９を用いて説明する。図１７は、本実施の形態のクラスタシステムの構成の変形例を示す図である。図１８は、ノード一覧テーブルである。図１９は、統合ノード一覧テーブルである。
【０１４０】
本実施の形態の変形例では、スイッチ６０を介して、複数のサービス提供ノード１００、２００、３００、４００からなるクラスタ９００に、監視ノード５００、処理要求ノード６００、および管理ノード７００が接続されている。また、スイッチ６５を介して、複数のサービス提供ノード２５０、３５０、４００からなるクラスタ９５０に、監視ノード５５０、処理要求ノード６５０、および管理ノード７５０が接続されている。そして、サービス提供ノード４００は、クラスタ９００、クラスタ９５０の構成要素となっている。
【０１４１】
監視ノード５００は、クラスタ９００を構成する複数のサービス提供ノード１００、２００、３００、４００を監視している。したがって、サービス提供ノード１００、２００、３００、４００からハートビートパケット１５０を受信して、クラスタ９００に対応するハートビート確認応答パケット１６０を送信している。
【０１４２】
監視ノード５５０は、クラスタ９５０を構成する複数のサービス提供ノード２５０、３５０、４００を監視している。したがって、サービス提供ノード２５０、３５０、４００からハートビートパケット１５０を受信して、クラスタ９５０に対応するハートビート確認応答パケット１６０を送信している。
【０１４３】
サービス提供ノード４００は、２つのクラスタ９００、９５０に属するため、それぞれの監視ノード５００、５５０にハートビートパケット１５０を送信する。そして、それぞれの監視ノード５００、５５０からハートビート確認応答パケット１６０を受信する。
【０１４４】
サービス提供ノード４００は、監視ノード５００から受信したハートビート確認応答パケット１６０に基づいて、図９のノード一覧テーブル８１０を得る。また、サービス提供ノード４００は、監視ノード５５０から受信したハートビート確認応答パケット１６０に基づいて、図１８のノード一覧テーブル８４０を得る。２つのノード一覧テーブル８１０、８４０を得たサービス提供ノード４００は、これら２つのノード一覧テーブル８１０、８４０を統合して図１９の統合ノード一覧テーブル８５０を得る。そして、サービス提供ノード４００は、統合ノード一覧テーブル８５０に基づいて、ソフトウェア更新対象を抽出する。
【０１４５】
これにより、特定のノードでクラスタが重なっているシステムにおいても、ソフトウェアの更新が重複するシステムをまたいで実行される。
なお、上記の実施の形態では、更新対象選択手段が選択するソフトウェア更新対象のサービス提供ノードを１台として説明したが、これに限らず２台以上のソフトウェア更新対象のサービス提供ノードを選択することもできる。その場合には、クラスタシステムで多数のノードが同時にソフトウェアを更新している状態を回避するため、ソフトウェア更新を指示する指示タイミングを、ソフトウェア更新対象のサービス提供ノードを１台とするときよりも大きくすることが望ましい。同様にして、第二の更新タイミング情報と第一の更新タイミング情報との差を、ソフトウェア更新対象のサービス提供ノードを１台とするときよりも大きくして第二の更新タイミング情報を生成することが望ましい。
【０１４６】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、サービス提供ノードや監視ノードが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
【０１４７】
プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１４８】
プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。
【０１４９】
なお、上述の実施の形態は、実施の形態の要旨を逸脱しない範囲内において種々の変更を加えることができる。
さらに、上述の実施の形態は、多数の変形、変更が当業者にとって可能であり、説明した正確な構成および応用例に限定されるものではない。
【０１５０】
以上説明した実施の形態の主な技術的特徴は、以下の付記の通りである。
（付記１）  クラスタシステムに属するサービス提供ノードに対するサービス提供用プログラムの更新指示の送信を、前記サービス提供ノードにネットワークで接続されたコンピュータに実行させるソフトウェア更新指示プログラムであって、
前記コンピュータを、
前記クラスタシステムを監視する監視ノードに対して、前記コンピュータで実行されている前記サービス提供用プログラムに関するプログラム情報を所定の送信間隔で定期的に送信するプログラム情報送信手段、
前記監視ノードから前記サービス提供ノードの前記プログラム情報を含むノード一覧情報を受信するノード一覧情報受信手段、
前記ノード一覧情報の前記プログラム情報から前記サービス提供用プログラムが未更新のサービス提供ノードを判定し、前記サービス提供用プログラムが未更新のサービス提供ノードのうち少なくとも一部を、更新対象サービス提供ノードとして選択する更新対象選択手段、
前記コンピュータで実行されている前記サービス提供用プログラムに対する前記更新指示と共に、前記更新指示を伝搬させるまでの待機時間を示す第一の更新タイミング情報が入力されると、前記第一の更新タイミング情報に示された待機時間経過後の時刻を、前記更新指示の指示タイミングに決定する指示タイミング決定手段、
前記更新対象サービス提供ノードからさらに他のサービス提供ノードへ前記更新指示を伝搬させるまでの待機時間を示す第二の更新タイミング情報を生成する更新タイミング情報生成手段、
前記指示タイミングに達すると、前記サービス提供用プログラムの前記更新指示と前記第二の更新タイミング情報とを、前記更新対象サービス提供ノードに送信する更新指示送信手段、
として機能させることを特徴とするソフトウェア更新指示プログラム。
【０１５１】
（付記２）  前記プログラム情報送信手段は、前記プログラム情報を、前記コンピュータが前記サービス提供プログラムに基づいてサービスを提供していることを示すハートビートに含めて送信することを特徴とする付記１記載のソフトウェア更新指示プログラム。
【０１５２】
（付記３）  前記ノード一覧情報受信手段は、前記監視ノードからの前記ハートビートの確認応答に含まれた前記ノード一覧情報を受信することを特徴とする付記２記載のソフトウェア更新指示プログラム。
【０１５３】
（付記４）  前記更新対象選択手段は、前記コンピュータとの関係が希薄な前記サービス提供ノードを前記更新対象サービス提供ノードとして選択することを特徴とする付記１記載のソフトウェア更新指示プログラム。
【０１５４】
（付記５）  前記関係は、前記サービス提供ノード間における過去の通信履歴により評価されることを特徴とする付記４記載のソフトウェア更新指示プログラム。
（付記６）  前記関係は、前記サービス提供ノード間における過去の単位時間当たりの通信量により評価されることを特徴とする付記４記載のソフトウェア更新指示プログラム。
【０１５５】
（付記７）  前記関係は、前記サービス提供ノード間における過去の単位時間当たりの通信頻度により評価されることを特徴とする付記４記載のサービス提供用プログラム。
（付記８）  前記更新タイミング情報生成手段は、前記第一の更新タイミング情報とは異なる待機時間を指定した前記第二の更新タイミング情報を生成することを特徴とする付記１記載のソフトウェア更新指示プログラム。
【０１５６】
（付記９）  前記第二の更新タイミング情報は、係数値であって、所定の単位時間と前記係数値との積により待機時間が指定されることを特徴とする付記８記載のソフトウェア更新指示プログラム。
【０１５７】
（付記１０）  前記係数値は、素数であることを特徴とする付記９記載のソフトウェア更新指示プログラム。
（付記１１）  前記プログラム情報送信手段は、前記プログラム情報を、前記コンピュータが前記サービス提供プログラムに基づいてサービスを提供していることを示すハートビートに含めて送信し、
前記更新タイミング情報生成手段は、前記第一の更新タイミング情報とは異なる待機時間を指定した前記第二の更新タイミング情報を生成し、
前記第二の更新タイミング情報は、係数値であって、前記ハートビートの送信間隔と前記係数値との積により待機時間が指定されることを特徴とする付記１記載のソフトウェア更新指示プログラム。
【０１５８】
（付記１２）  前記更新タイミング情報生成手段は、前記第一の更新タイミング情報で指定された待機時間より長い待機時間を指定した前記第二の更新タイミング情報を生成することを特徴とする付記１記載のソフトウェア更新指示プログラム。
【０１５９】
（付記１３）  前記更新指示送信手段は、前記更新指示に併せて、前記サービス提供プログラムを更新するための更新プログラムを配布することを特徴とする付記１記載のソフトウェア更新指示プログラム。
【０１６０】
（付記１４）  前記更新対象選択手段は、前記コンピュータが複数のクラスタシステムに属している場合、クラスタシステムそれぞれの前記監視ノードから受信した複数のノード一覧情報を統合した統合ノード一覧情報に基づいて、前記更新対象サービス提供ノードを選択することを特徴とする付記１記載のソフトウェア更新指示プログラム。
【０１６１】
（付記１５）  クラスタシステムに属するサービス提供ノードに対するサービス提供用プログラムの更新指示の送信を、前記サービス提供ノードにネットワークで接続されたコンピュータで実行するソフトウェア更新指示方法であって、
前記コンピュータが、
前記クラスタシステムを監視する監視ノードに対して、前記コンピュータで実行されている前記サービス提供用プログラムに関するプログラム情報を所定の送信間隔で定期的に送信し、
前記監視ノードから前記サービス提供ノードの前記プログラム情報を含むノード一覧情報を受信し、
前記ノード一覧情報の前記プログラム情報から前記サービス提供用プログラムが未更新のサービス提供ノードを判定し、前記サービス提供用プログラムが未更新のサービス提供ノードのうち少なくとも一部を、更新対象サービス提供ノードとして選択し、
前記コンピュータで実行されている前記サービス提供用プログラムに対する前記更新指示と共に、前記更新指示を伝搬させるまでの待機時間を示す第一の更新タイミング情報が入力されると、前記第一の更新タイミング情報に示された待機時間経過後の時刻を、前記更新指示の指示タイミングに決定し、
前記更新対象サービス提供ノードからさらに他のサービス提供ノードへ前記更新指示を伝搬させるまでの待機時間を示す第二の更新タイミング情報を生成し、
前記指示タイミングに達すると、前記サービス提供用プログラムの前記更新指示と前記第二の更新タイミング情報とを、前記更新対象サービス提供ノードに送信する、
ことを特徴とするソフトウェア更新指示方法。
【０１６２】
（付記１６）  クラスタシステムに属し、サービス提供用プログラムを実行することでサービスを提供する情報処理装置において、
前記クラスタシステムを監視する監視ノードに対して、前記コンピュータで実行されている前記サービス提供用プログラムに関するプログラム情報を所定の送信間隔で定期的に送信するプログラム情報送信手段と、
前記監視ノードから、前記クラスタシステムに属する他の情報処理装置の前記プログラム情報を含むノード一覧情報を受信するノード一覧情報受信手段と、
前記ノード一覧情報の前記プログラム情報から前記サービス提供用プログラムが未更新の前記他の情報処理装置を判定し、前記サービス提供用プログラムが未更新の前記他の情報処理装置のうち少なくとも一部を、更新対象情報処理装置として選択する更新対象選択手段と、
前記コンピュータで実行されている前記サービス提供用プログラムに対する前記更新指示と共に、前記更新指示を伝搬させるまでの待機時間を示す第一の更新タイミング情報が入力されると、前記第一の更新タイミング情報に示された待機時間経過後の時刻を、前記更新指示の指示タイミングに決定する指示タイミング決定手段と、
前記更新対象情報処理装置からさらに前記他の情報処理装置へ前記更新指示を伝搬させるまでの待機時間を示す第二の更新タイミング情報を生成する更新タイミング情報生成手段と、
前記指示タイミングに達すると、前記サービス提供用プログラムの前記更新指示と前記第二の更新タイミング情報とを、前記更新対象情報処理装置に送信する更新指示送信手段と、
を備えることを特徴とする情報処理装置。
【符号の説明】
【０１６３】
１００  サービス提供ノード
１０１  プログラム情報送信手段
１０２  更新対象選択手段
１０３  指示タイミング決定手段
１０４  更新タイミング情報生成手段
１０５  ノード一覧情報受信手段
１０６  更新指示送信手段
１０７  ソフトウェア更新手段
１０８  更新ファイル記憶手段
１１０  サーバ
１５１  ハートビート
１６１  ノード一覧情報
１７１、１７２、１７３  更新指示
４００  サービス提供ノード
５００  監視ノード
７００  管理ノード
【図１】
2010182061.tif 000003
【図２】
2010182061.tif 000004
【図３】
2010182061.tif 000005
【図４】
2010182061.tif 000006
【図５】
2010182061.tif 000007
【図６】
2010182061.tif 000008
【図７】
2010182061.tif 000009
【図８】
2010182061.tif 000010
【図９】
2010182061.tif 000011
【図１０】
2010182061.tif 000012
【図１１】
2010182061.tif 000013
【図１２】
2010182061.tif 000014
【図１３】
2010182061.tif 000015
【図１４】
2010182061.tif 000016
【図１５】
2010182061.tif 000017
【図１６】
2010182061.tif 000018
【図１７】
2010182061.tif 000019
【図１８】
2010182061.tif 000020
【図１９】
2010182061.tif 000021