(57)【要約】  サービスを提供するノードを運用状態にしたまま、そのノードのソフトウェアを更新できるようにする。  処理実行手段（１ａ）に停止命令が入力されると、ハートビート送信手段（１ｂ）により、元の第１のハートビート送信間隔よりも長い第２のハートビート送信間隔をハートビート間隔情報として含むハートビートパケットが監視ノード（２）に対して送信される。その後、処理実行手段（１ａ）の機能を実現するためのソフトウェアが更新され、処理実行手段（１ａ）が再起動されると、ハートビート送信手段（１ｂ）によって、第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットが、第１のハートビート送信間隔で定期的に監視ノードに対して送信される。ハートビート監視手段（２ｃ）は、ハートビート間隔情報で示された間隔でハートビートを受信している限り、サービス提供ノードを運用中と判断する。
2008126325.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバで分散処理を行うクラスタシステムにおいて、
処理要求が入力されると前記処理要求に応じた処理を実行し、停止命令が入力されると運用を停止する処理実行手段と、予め設定された第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットを前記第１のハートビート送信間隔で定期的に監視ノードに対して送信し、前記処理実行手段に対する前記停止命令が入力されると、前記第１のハートビート送信間隔よりも長い第２のハートビート送信間隔を前記ハートビート間隔情報として含む前記ハートビートパケットを前記監視ノードに対して送信し、前記処理実行手段が再起動されると、前記第１のハートビート送信間隔を示すハートビート間隔情報を含む前記ハートビートパケットを前記第１のハートビート送信間隔で定期的に前記監視ノードに対して送信するハートビート送信手段と、を有するサービス提供ノードと、
前記ハートビートパケットに含まれる前記ハートビート間隔情報を、前記サービス提供ノードに対応付けて記憶するハートビート間隔情報記憶手段と、前記サービス提供ノードから送られる前記ハートビートパケットを受信し、取得した前記ハートビートパケットに含まれる前記ハートビート間隔情報と前記ハートビート間隔情報記憶手段に前記サービス提供ノードに対応付けて記憶されている前記ハートビート間隔情報とが一致しない場合、前記サービス提供ノードに対応付けて前記ハートビート間隔情報記憶手段に記憶された前記ハートビート間隔情報を、取得した前記ハートビートパケットに含まれる前記ハートビート間隔情報で更新するハートビート間隔情報更新手段と、前記サービス提供ノードに対応付けて前記ハートビート間隔情報記憶手段に記憶されている前記ハートビート間隔情報で示される間隔で前記ハートビートパケットを受信している間は、前記処理実行手段を運用中と判断するハートビート監視手段と、を具備する前記監視ノードと、
を有することを特徴とするクラスタシステム。
【請求項２】
前記ハートビート送信手段は、前記停止命令において指定された時間を、前記第２のハートビート送信間隔とすることを特徴とする請求の範囲第１項記載のクラスタシステム。
【請求項３】
前記サービス提供ノードは、さらに、ソフトウェアの更新要求が入力されると、前記処理実行手段に対する前記停止命令を出力し、前記処理実行手段が停止した後、前記更新要求に従って前記処理実行手段を機能させるためのソフトウェアを更新し、更新後のソフトウェアを用いて前記処理実行手段を再起動する更新処理手段をさらに有することを特徴とする請求の範囲第１項記載のクラスタシステム。
【請求項４】
前記更新処理手段は、前記処理実行手段の受信ポートが閉塞すると、前記処理実行手段が閉塞した受信ポートと同じポート番号の受信ポートを開設し、開設した受信ポート宛ての処理要求が他のコンピュータから入力されると、資源不足を示す応答を前記他のコンピュータ宛てに送信することを特徴とする請求の範囲第３項記載のクラスタシステム。
【請求項５】
前記更新処理手段は、ハートビート送信間隔を示す所定の時間を指定した前記停止命令を出力し、
前記ハートビート送信手段は、前記停止命令において指定された時間を、前記第２のハートビート送信間隔とすることを特徴とすることを特徴とする請求の範囲第１項記載のクラスタシステム。
【請求項６】
複数のサーバで分散処理を行うクラスタシステムにおけるソフトウェア更新方法において、
サービス提供ノードが有する処理実行手段が、処理要求が入力されると前記処理要求に応じた処理を実行し、
前記サービス提供ノードが有するハートビート送信手段が、予め設定された第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットを前記第１のハートビート送信間隔で定期的に監視ノードに対して送信し、
前記サービス提供ノードが有する更新処理手段が、ソフトウェアの更新要求が入力されると、前記処理実行手段に対する停止命令を出力し、
前記サービス提供ノードが有するハートビート送信手段が、前記処理実行手段に対する前記停止命令が入力されると、前記第１のハートビート送信間隔よりも長い第２のハートビート送信間隔を前記ハートビート間隔情報として含む前記ハートビートパケットを前記監視ノードに対して送信し、
前記監視ノードが有するハートビート間隔情報更新手段が、前記サービス提供ノードから送られる前記ハートビートパケットを受信し、前記サービス提供ノードに対応付けてハートビート間隔情報記憶手段に記憶された前記ハートビート間隔情報を、取得した前記ハートビートパケットに含まれる前記ハートビート間隔情報で更新し、
前記サービス提供ノードが有する前記処理実行手段が、前記停止命令に応答して運用を停止し、
前記サービス提供ノードが有する前記更新処理手段が、前記更新要求に従って前記処理実行手段を機能させるためのソフトウェアを更新し、更新後のソフトウェアを用いて前記処理実行手段を再起動し、
前記サービス提供ノードが有するハートビート送信手段が、前記処理実行手段が再起動されると、前記第１のハートビート送信間隔を示すハートビート間隔情報を含む前記ハートビートパケットを前記第１のハートビート送信間隔で定期的に前記監視ノードに対して送信し、
前記監視ノードが有する前記ハートビート間隔情報更新手段が、前記サービス提供ノードから送られる前記ハートビートパケットを受信し、前記サービス提供ノードに対応付けて前記ハートビート間隔情報記憶手段に記憶された前記ハートビート間隔情報を、取得した前記ハートビートパケットに含まれる前記ハートビート間隔情報で更新し、
前記監視ノードが有するハートビート監視手段が、前記サービス提供ノードに対応付けて前記ハートビート間隔情報記憶手段に記憶されている前記ハートビート間隔情報で示される間隔で前記ハートビートパケットを受信している間は、前記処理実行手段を運用中と判断する、
ことを特徴とするソフトウェア更新方法。
【請求項７】
分散処理を行うクラスタシステムを構成するサービス提供ノードにおいて、
処理要求が入力されると前記処理要求に応じた処理を実行し、停止命令が入力されると運用を停止する処理実行手段と、
予め設定された第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットを前記第１のハートビート送信間隔で定期的に監視ノードに対して送信し、前記処理実行手段に対する前記停止命令が入力されると、前記第１のハートビート送信間隔よりも長い第２のハートビート送信間隔を前記ハートビート間隔情報として含む前記ハートビートパケットを前記監視ノードに対して送信し、前記処理実行手段が再起動されると、前記第１のハートビート送信間隔を示すハートビート間隔情報を含む前記ハートビートパケットを前記第１のハートビート送信間隔で定期的に前記監視ノードに対して送信するハートビート送信手段と、
を有するサービス提供ノード。
【請求項８】
分散処理を行うクラスタシステムを構成するコンピュータのサービス提供用プログラムにおいて、
前記コンピュータを、
処理要求が入力されると前記処理要求に応じた処理を実行し、停止命令が入力されると運用を停止する処理実行手段、
予め設定された第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットを前記第１のハートビート送信間隔で定期的に監視ノードに対して送信し、前記処理実行手段に対する前記停止命令が入力されると、前記第１のハートビート送信間隔よりも長い第２のハートビート送信間隔を前記ハートビート間隔情報として含む前記ハートビートパケットを前記監視ノードに対して送信し、前記処理実行手段が再起動されると、前記第１のハートビート送信間隔を示すハートビート間隔情報を含む前記ハートビートパケットを前記第１のハートビート送信間隔で定期的に前記監視ノードに対して送信するハートビート送信手段、
として機能させることを特徴とするサービス提供用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は分散処理を行うクラスタシステム、ソフトウェア更新方法、サービス提供ノード、およびサービス提供用プログラムに関し、特に運用を継続しながらソフトウェアを更新するクラスタシステム、ソフトウェア更新方法、サービス提供ノード、およびサービス提供用プログラムに関する。
【背景技術】
【０００２】
クラスタシステムでは、複数のコンピュータを用いた分散処理が行われる。なお、クラスタシステムを構成するコンピュータを、ノードと呼ぶ。クラスタシステムでは、処理をどのノードに実行させるべきかを判断するために、各ノードが正常に運用されているか否かを認識している必要がある。【０００３】
クラスタシステムにおいてノードの運用状況を認識する方法として、各ノードから監視ノードへハートビートを定期的に送信する方法がある。ハートビートは、そのハートビートを送信したノードが正常に運用されていることを示す情報である。監視ノードでは、ハートビートを所定間隔で送信しているノードのみを、正常に運用しているノードと判断する。【０００４】
監視ノードでは、ハートビートが途絶えたノードを検出すると、そのノードに障害が発生したものと判断して、そのノードを処理の要求先から除外する。処理の要求先から除外されたノードは、障害の原因を取り除いた後、運用が再開される。運用再開時には、監視ノードにおいて処理の要求先に追加される。【０００５】
なお、ハートビートのような周期的に送信される情報は、その間隔が短い程、情報のリアルタイム性が向上するが、その一方で通信付加が増大する。そこで、通信状態に基づいて周期的に行われる送信の間隔を変更する技術が考えられている（たとえば、特許文献１参照）。【０００６】
また、システムを運用しているとき、各ノードのソフトウェアを更新する必要が生じることがある。通常は、ソフトウェア更新対象のノードの運用を停止してから、ソフトウェアの更新作業が行われる。そのため、ソフトウェアの更新時には、ノードでのサービスの提供が一時的に停止することとなる。サービスを停止すると、監視ノードにおいて障害が検出されエラー処理が実行される。ソフトウェアの更新の場合、更新処理終了後に正常に運用可能となることが明らかである。そのため、エラー処理が実行されると、無駄な処理が発生することとなり、システムの運用効率が低下する。【０００７】
そこで、サービスの提供を停止せずに、ソフトウェアを更新する技術が考えられている。たとえば、サービスを提供するためのエージェントと、クラスタシステム内の他のコンピュータと通信を行いながらエージェントを制御するクラスタ制御部を設け、エージェントによるサービスを継続しながらクラスタ制御部のソフトウェアをアップグレードする技術がある（たとえば、特許文献２参照）。
【特許文献１】特開２００４−３６４１６８号公報
【特許文献２】特開２００５−８５１１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、特許文献２の技術を用いたとしても、サービスを提供するためのエージェントのソフトウェアを更新する際には、サービスを停止させなければならない。ノードのサービスを停止させれば、そのノードからのハートビートの送信が停止する。その結果、監視ノードにおいて、ノードに異常が発生したものと解釈される。【０００９】
監視ノードでは、異常を検出したノードを、サービスを提供するノード群から除外する。そして、ソフトウェアの更新処理がノードに対して実行されると、その後、そのノードがサービスを提供するノード群に追加する処理が行われる。その間は、ソフトウェアの更新作業を行ったノードによるサービスは停止している。【００１０】
ノードのソフトウェアを更新する毎に、サービスを提供するノード群からの該当ノードの除外と、ソフトウェア更新後の該当ノードのノード群への追加処理を行うことは、サービス停止期間の長期化を招いてしまう。特に、大規模なクラスタシステムにおいて全てのノードのソフトウェアを更新する場合、ソフトウェア更新時のノードの追加、削除処理を行うことは、システム全体としての運用効率の低下を招いてしまう。【００１１】
本発明はこのような点に鑑みてなされたものであり、サービスを提供するノードを運用の状態にしたまま、そのノードのソフトウェアを更新することができるクラスタシステム、ソフトウェア更新方法、サービス提供ノード、およびサービス提供用プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明では上記課題を解決するために、図１に示すような複数のサーバで分散処理を行うクラスタシステムが提供される。クラスタシステムは、サービス提供ノード１と監視ノード２とを有している。サービス提供ノード１は、処理実行手段１ａとハートビート送信手段１ｂとを有する。処理実行手段１ａは、処理要求が入力されると処理要求に応じた処理を実行し、停止命令が入力されると運用を停止する。ハートビート送信手段１ｂは、予め設定された第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットを第１のハートビート送信間隔で定期的に監視ノードに対して送信し、処理実行手段１ａに対する停止命令が入力されると、第１のハートビート送信間隔よりも長い第２のハートビート送信間隔をハートビート間隔情報として含むハートビートパケットを監視ノードに対して送信し、処理実行手段１ａが再起動されると、第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットを第１のハートビート送信間隔で定期的に監視ノードに対して送信する。監視ノード２は、ハートビート間隔情報記憶手段２ａ、ハートビート間隔情報更新手段２ｂ、およびハートビート監視手段２ｃを有する。ハートビート間隔情報記憶手段２ａは、ハートビートパケットに含まれるハートビート間隔情報を、サービス提供ノードに対応付けて記憶する。ハートビート間隔情報更新手段２ｂは、サービス提供ノードから送られるハートビートパケットを受信し、取得したハートビートパケットに含まれるハートビート間隔情報とハートビート間隔情報記憶手段２ａにサービス提供ノードに対応付けて記憶されているハートビート間隔情報とが一致しない場合、サービス提供ノードに対応付けてハートビート間隔情報記憶手段２ａに記憶されたハートビート間隔情報を、取得したハートビートパケットに含まれるハートビート間隔情報で更新するハートビート監視手段２ｃは、サービス提供ノード１に対応付けてハートビート間隔情報記憶手段２ａに記憶されているハートビート間隔情報で示される間隔でハートビートパケットを受信している間は、処理実行手段１ａを運用中と判断する。【００１３】
このようなクラスタシステムによれば、サービス提供ノード１に処理要求が入力されると処理実行手段１ａによって処理要求に応じた処理が実行される。また、ハートビート送信手段１ｂによって、第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットが第１のハートビート送信間隔で定期的に監視ノードに対して送信される。処理実行手段１ａに停止命令が入力されると、処理実行手段１ａの処理が停止すると共に、ハートビート送信手段１ｂにより、第２のハートビート送信間隔をハートビート間隔情報として含むハートビートパケットが監視ノード２に対して送信される。すると、監視ノード２のハートビート間隔情報更新手段２ｂにより、サービス提供ノード１に対応付けてハートビート間隔情報記憶手段２ａに記憶されたハートビート間隔情報が、取得したハートビートパケットに含まれるハートビート間隔情報で更新される。【００１４】
その後、処理実行手段１ａの機能を実現するためのソフトウェアが更新され、処理実行手段１ａが再起動されると、ハートビート送信手段１ｂによって、第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットが、第１のハートビート送信間隔で定期的に監視ノードに対して送信される。すると、監視ノード２のハートビート間隔情報更新手段２ｂにより、サービス提供ノード１に対応付けてハートビート間隔情報記憶手段２ａに記憶されたハートビート間隔情報が、取得したハートビートパケットに含まれるハートビート間隔情報で更新される。サービス提供ノード１からのハートビートパケットの受信が、サービス提供ノード１に対応付けてハートビート間隔情報記憶手段２ａに記憶されているハートビート間隔情報で示される間隔より長い時間途絶えたときは、ハートビート監視手段２ｃによりエラー処理が実行される。
【発明の効果】
【００１５】
本発明では、処理実行手段に対する停止命令が入力されると、第１のハートビート送信間隔よりも長い第２のハートビート送信間隔をハートビート間隔情報として含むハートビートパケットを監視ノードに対して送信し、監視ノードでは、ハートビート間隔情報で示された間隔でハートビートパケットを取得している間は、処理実行手段を運用中と判断するようにした。これにより、延長されたハートビート送信間隔の間にソフトウェアの更新作業を行うことで、監視ノードでエラーを検出させずにソフトウェアの更新が可能となる。【００１６】
本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。
【図面の簡単な説明】
【００１７】
【図１】発明の概要を示す図である。
【図２】本実施の形態のクラスタシステムの構成例を示す図である。
【図３】本実施の形態に用いる監視ノードのハードウェア構成例を示す図である。
【図４】分散処理システムの機能ブロック図である。
【図５】ハートビートパケットのデータ構造例を示す図である。
【図６】サーバ運用情報テーブルのデータ構造例を示す図である。
【図７】ソフトウェア更新時のハートビート送信間隔変更処理手順を示すシーケンス図である。
【図８】ソフトウェア更新中に代理応答を行う処理手順を示すシーケンス図である。
【図９】更新処理部の処理手順を示すフローチャートである。
【図１０】処理要求応答用プロセスの処理手順を示すフローチャートである。
【図１１】ノード監視部におけるハートビート取得処理を示す図である。
【図１２】ノード監視部の状態監視処理手順を示すフローチャートである。
【図１３】処理要求仲介処理の手順を示すフローチャートである。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施の形態を図面を参照して説明する。
図１は、発明の概要を示す図である。本発明に係るクラスタシステムは、サービス提供ノード１と監視ノード２とを有している。サービス提供ノード１は、処理実行手段１ａ、ハートビート送信手段１ｂ、および更新処理手段１ｃを有する。また、監視ノード２は、ハートビート間隔情報記憶手段２ａ、ハートビート間隔情報更新手段２ｂ、およびハートビート監視手段２ｃを有する。【００１９】
処理実行手段１ａは、処理要求が入力されると処理要求に応じた処理を実行する。また、処理実行手段１ａは、停止命令が入力されると運用を停止する。
ハートビート送信手段１ｂは、予め設定された第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットを第１のハートビート送信間隔で定期的に監視ノードに対して送信する。また、ハートビート送信手段１ｂは、処理実行手段１ａに対する停止命令が入力されると、第１のハートビート送信間隔よりも長い第２のハートビート送信間隔をハートビート間隔情報として含むハートビートパケットが送信する。なお、第２のハートビート送信間隔は、ソフトウェアの更新作業に必要な時間が設定される。さらに、ハートビート送信手段１ｂは、処理実行手段１ａが再起動されると、第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットを第１のハートビート送信間隔で定期的に監視ノードに対して送信する。【００２０】
更新処理手段１ｃは、ソフトウェアの更新要求が入力されると、処理実行手段１ａに対する停止命令を出力する。さらに、更新処理手段１ｃは、処理実行手段１ａが停止した後、更新要求に従って処理実行手段１ａを機能させるためのソフトウェアを更新する。そして、更新処理手段１ｃは、更新後のソフトウェアを用いて処理実行手段１ａを再起動する。【００２１】
ハートビート間隔情報記憶手段２ａは、ハートビートパケットに含まれるハートビート間隔情報を、サービス提供ノード１に対応付けて記憶する。また、ハートビート間隔情報更新手段２ｂは、サービス提供ノード１から送られるハートビートパケットを受信し、取得したハートビートパケットに含まれるハートビート間隔情報とハートビート間隔情報記憶手段２ａにサービス提供ノードに対応付けて記憶されているハートビート間隔情報とが一致しない場合、サービス提供ノード１に対応付けてハートビート間隔情報記憶手段２ａに記憶されたハートビート間隔情報を、取得したハートビートパケットに含まれるハートビート間隔情報で更新する。ハートビート監視手段２ｃは、サービス提供ノード１に対応付けてハートビート間隔情報記憶手段２ａに記憶されているハートビート間隔情報で示される間隔でハートビートパケットを受信している間は、処理実行手段を運用中と判断する。なお、ハートビート監視手段２ｃは、前回のハートビートパケットの受信から、ハートビート間隔情報で示される時間間隔を超えて次のハートビートパケットが受信できなかった場合には、エラー処理を行う。【００２２】
このようなクラスタシステムによれば、処理実行手段１ａの運用中は、サービス提供ノード１が有する処理実行手段１ａにより、処理要求が入力されると処理要求に応じた処理が実行される。このとき、ハートビート送信手段１ｂにより、予め設定された第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットが、第１のハートビート送信間隔で定期的に監視ノード２に対して送信される。監視ノード２が有するハートビート監視手段２ｃは、サービス提供ノード１からのハートビートパケットを、サービス提供ノードに対応付けてハートビート間隔情報記憶手段２ａに記憶されているハートビート間隔情報で示される間隔で受信している間は、処理実行手段１ａが運用中であると認識する。【００２３】
サービス提供ノード１において、ソフトウェアの更新要求が入力されると、更新処理手段１ｃにより、処理実行手段１ａに対する停止命令が出力される。すると、ハートビート送信手段１ｂにより、第２のハートビート送信間隔をハートビート間隔情報として含むハートビートパケットが監視ノード２に対して送信される。監視ノード２では、ハートビート間隔情報更新手段２ｂにより、サービス提供ノード１から送られるハートビートパケットが受信され、サービス提供ノード１に対応付けてハートビート間隔情報記憶手段２ａに記憶されたハートビート間隔情報が、取得したハートビートパケットに含まれるハートビート間隔情報で更新される。その後、処理実行手段１ａが、停止命令に応答して運用を停止する。【００２４】
処理実行手段１ａの運用が停止すると、更新処理手段１ｃにより、更新要求に従って処理実行手段１ａを機能させるためのソフトウェアが更新される。そして、更新処理手段１ｃにより、更新後のソフトウェアを用いて処理実行手段１ａが再起動される。【００２５】
処理実行手段１ａが再起動されると、ハートビート送信手段１ｂにより、第１のハートビート送信間隔を示すハートビート間隔情報を含むハートビートパケットが第１のハートビート送信間隔で定期的に監視ノード２に対して送信される。【００２６】
監視ノード２では、ハートビート監視手段２ｃにより、サービス提供ノード１に対応付けてハートビート間隔情報記憶手段２ａに記憶されているハートビート間隔情報で示される間隔でハートビートパケットを受信している間は、処理実行手段１ａが運用中と判断される。【００２７】
このようにして、第２のハートビート送信間隔の時間内に処理実行手段１ａのソフトウェアの更新作業を行えば、監視ノード２では、ソフトウェアの更新前から更新後まで継続した処理実行手段１ａが運用中であるものと判断される。従って、監視ノード２においてエラー処理を発生させずにすみ、ソフトウェア更新作業を行うことによりクラスタシステムの運用効率の低下を最小限に抑えることができる。【００２８】
なお、図１の例では、更新処理手段１ｃが処理実行手段１ａへ停止命令を出力し、ソフトウェアの更新を自動で実行するものとしているが、管理者の操作入力によって、処理実行手段１ａに対して停止命令を出力してもよい。また、ソフトウェアの更新作業も、管理者の操作入力に基づくファイル操作（たとえば、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）からのファイルのコピー）によってソフトウェアの更新作業を行うこともできる。【００２９】
また、停止命令に付与する第２のハートビート送信間隔は、ソフトウェアの更新に必要な時間だけ設定される。
ところで、図１の例では、監視ノード２におけるエラー発生を防止するための処理を示しているが、クラスタシステムでは、サービス提供ノード１に対して処理要求を出力するノード（以下、処理要求ノードと呼ぶ）が存在する。この処理要求ノードにおいても、サービス提供ノード１の処理実行手段１ａが停止している間のエラー発生を防止することが望まれる。すなわち、処理要求ノードでエラーが検出されると、処理要求の発生元の別の処理が中断してしまうことがある。処理が中断すると、管理者が操作入力を行い中断した処理の再開を指示するまで処理が止まってしまい、システムの運用効率の低下を招く。【００３０】
そこで、監視ノードと処理要求ノードとのいずれにおいてもエラーを発生させずにソフトウェアの更新作業を行うためのクラスタシステムの例を用いて、本実施の形態の詳細を説明する。【００３１】
図２は、本実施の形態のクラスタシステムの構成例を示す図である。本実施の形態では、スイッチ１０を介して、複数のサービス提供ノード１００，２００，３００，４００、監視ノード５００、処理要求ノード６００、および管理ノード７００が接続されている。【００３２】
サービス提供ノード１００，２００，３００，４００は、たとえば、ＩＡ（Intel Architecture）と呼ばれるアーキテクチャのコンピュータである。サービス提供ノード１００，２００，３００，４００は、アプリケーションソフトウェアに基づいて、処理要求に応じたデータ処理を実行する機能を有する。以下、このようなデータ処理サービス機能を、単にサーバと呼ぶこととする。サービス提供ノード１００，２００，３００，４００に実装されたサーバは、監視ノード５００に対して定期的にハートビートを送信する機能を有している。【００３３】
なお、ハートビートの間隔は任意に変更可能である。ハートビートの間隔を変更する場合、サービス提供ノード１００，２００，３００，４００から監視ノード５００に対して、ハートビートの間隔を示す情報が送信される。【００３４】
監視ノード５００は、サービス提供ノード１００，２００，３００，４００を制御する。たとえば、監視ノード５００は、各サービス提供ノード１００，２００，３００，４００から送信されるハートビートを受信して、正常に運用しているサービス提供ノードを認識する。すなわち、監視ノード５００は、各サービス提供ノード１００，２００，３００，４００から送られてくるハートビートの間隔を示す情報に従って、サービス提供ノード１００，２００，３００，４００それぞれ個別の間隔でハートビートを待つ。指定された間隔内でのハートビートが途絶えたサービス提供ノードがあった場合、監視ノード５００は、そのサービス提供ノードを障害発生中と認識する。【００３５】
処理要求ノード６００には、ネットワーク２０を介して複数の端末装置２１，２２，２３が接続されている。処理要求ノード６００は、サービス提供ノード１００，２００，３００，４００それぞれが管理しているデータの格納場所を認識しており、端末装置２１，２２，２３からの要求に応答して、サービス提供ノード１００，２００，３００，４００へデータアクセスを行う。【００３６】
管理ノード７００は、システム全体を管理するためのコンピュータである。たとえば、管理ノード７００は、管理者からの操作入力に応答して、サービス提供ノード１００，２００，３００，４００に対して、サーバのソフトウェアの更新要求を送信する。【００３７】
図３は、本実施の形態に用いる監視ノードのハードウェア構成例を示す図である。監視ノード５００は、ＣＰＵ（Central Processing Unit）５０１によって装置全体が制御されている。ＣＰＵ５０１には、バス５０７を介してＲＡＭ（Random Access Memory）５０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）５０３、グラフィック処理装置５０４、入力インタフェース５０５、および通信インタフェース５０６が接続されている。【００３８】
ＲＡＭ５０２には、ＣＰＵ５０１に実行させるＯＳ（Operating System）のプログラムやサーバを実行するためのアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ５０２には、ＣＰＵ５０１による処理に必要な各種データが格納される。ＨＤＤ５０３には、ＯＳやアプリケーションプログラムが格納される。【００３９】
グラフィック処理装置５０４には、モニタ１１が接続されている。グラフィック処理装置５０４は、ＣＰＵ５０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース５０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース５０５は、キーボード１２やマウス１３から送られてくる信号を、バス５０７を介してＣＰＵ５０１に送信する。【００４０】
通信インタフェース５０６は、スイッチ１０に接続されている。通信インタフェース５０６は、スイッチ１０を介して、他のコンピュータとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には監視ノードのハードウェア構成例を示したが、サービス提供ノード１００，２００，３００，４００、処理要求ノード６００、管理ノード７００、および端末装置２１，２２，２３も同様のハードウェア構成で実現できる。【００４１】
図４は、分散処理システムの機能ブロック図である。サービス提供ノード１００は、サーバ１１０と更新処理部１２０とを有している。
サーバ１１０は、サービス提供を行う処理機能（プロセス）である。具体的には、サーバソフトウェアをサービス提供ノード１００が実行することによって、サーバ１１０の機能が実現される。サーバ１１０には、処理実行部１１１とハートビート送信部１１２とが含まれる。【００４２】
処理実行部１１１は、処理要求ノード６００から送信された処理要求に応じて、処理を実行する。そして、処理実行部１１１は、処理要求に対する応答として、処理結果を処理要求ノード６００に送信する。【００４３】
ハートビート送信部１１２は、監視ノード５００に対して定期的にハートビートパケット３０を送信する。なお、ハートビート送信部１１２は、ハートビートパケット３０内にハートビートの送信間隔を示す情報（ハートビート間隔情報）を含めることで、現在のハートビートの送信間隔を監視ノード５００に伝える。ハートビートパケット３０の送信間隔は予め初期状態が決められており、更新処理部１２０などからの指定によって変更できる。【００４４】
更新処理部１２０は、管理ノード７００などからのサーバ１１０を実行するためのソフトウェアの更新要求に応答して、そのソフトウェアを更新する。ソフトウェアの更新は、サーバ１１０の機能を停止した上で実行される。そこで、更新処理部１２０は、ソフトウェアの更新要求を受け取ると、サーバ１１０に対して停止コマンドを発行する。その際、停止コマンドには、ハートビート間隔の延長を指示するパラメータが付与される。これにより、ハートビート間隔を延長させた後に、サーバ１１０を停止させることができる。【００４５】
また、更新処理部１２０は、ソフトウェア更新のためにサーバ１１０を停止させている間に、処理要求ノード６００からサーバ１１０に対する処理要求が出されると、その処理要求を取得する。そして、更新処理部１２０は、サーバ１１０に代わって処理要求に対する応答を処理要求ノード６００に送信する。更新処理部１２０が送信する応答の内容には、処理が混んでいることを示す情報（Ｂｕｓｙ）が含められる。【００４６】
ソフトウェアの更新処理が完了すると、更新処理部１２０は、更新後の版数のソフトウェアに基づいてサーバ１１０を起動する。
監視ノード５００は、サーバ運用情報記憶部５１０とノード監視部５２０とを有している。サーバ運用情報記憶部５１０は、サーバ運用情報を記憶する。サービス提供ノード１００，２００，３００，４００に実装されているサーバが運用中か否かを管理するデータテーブルである。たとえば、ＲＡＭ５０２の記憶領域の一部がサーバ運用情報記憶部５１０として使用される。【００４７】
処理要求ノード６００は、処理要求部６１０を有している。処理要求部６１０は、ネットワーク２０を介して端末装置２１〜２３から送られてくる処理要求を、いずれかのサービス提供ノード１００，２００，３００，４００に送信する。たとえば、処理要求ノード６００は、サービス提供ノード１００，２００，３００，４００からそれぞれの負荷情報を取得し、負荷の少ないサービス提供ノードに対して処理要求を送信する。また、処理要求部６１０は、処理要求を送信したサービス提供ノードから応答が返されると、処理要求を出力した端末装置に対してその応答を送信する。【００４８】
管理ノード７００は、更新ファイル記憶部７１０と更新指示部７２０とを有している。更新ファイル記憶部７１０は、サーバ１１０を更新するためのプログラムファイル（更新ファイル）を記憶する。たとえば、管理ノード７００のハードディスク装置の記憶領域の一部が更新ファイル記憶部７１０として使用される。【００４９】
更新指示部７２０は、管理者からの操作入力に応答して、サービス提供ノード１００，２００，３００，４００に対してソフトウェアの更新要求を送信する。なお、更新要求を送信する際には、更新指示部７２０は、更新ファイル記憶部７１０から更新ファイルを取得し、その更新ファイルを更新要求と共にサービス提供ノード１００，２００，３００，４００に送信する。【００５０】
このような構成の分散処理システムによって、各サービス提供ノード１００のサーバ１１０を実行するためのソフトウェアを更新する際には、ハートビートパケット３０の送信間隔を延長することで、監視ノード５００における障害検出を回避できる。【００５１】
図５は、ハートビートパケットのデータ構造例を示す図である。ハートビートパケット３０には、送信元アドレス、宛先アドレス、アプリケーション識別番号、パケット種別識別子、ハートビート間隔情報などのフィールドが設けられている。【００５２】
送信元アドレスのフィールドには、ハートビートパケット３０を送信したサービス提供ノードをネットワーク上で一意に識別するためのアドレスが設定される。たとえば、サービス提供ノードのＩＰアドレスが、送信元アドレスとして設定される。【００５３】
宛先アドレスのフィールドには、ハートビートパケット３０の宛先となる監視ノード５００をネットワーク上で一意に識別するためのアドレスが設定される。たとえば、監視ノード５００のＩＰアドレスが、送信元アドレスとして設定される。【００５４】
なお、送信元アドレスと宛先アドレスとのフィールドは、ハートビートパケット３０のヘッダ情報に含まれている。
アプリケーション識別番号のフィールドには、ハートビートを出力するサーバ１１０の種別を監視ノード５００が一意に識別するための識別番号が設定される。この識別番号としては、たとえば、サーバ１１０の通信用のポート番号を使用することもできる。【００５５】
パケット種別識別子のフィールドには、ハートビートパケット３０がハートビートを通知するパケットであることを示す識別子が設定される。
ハートビート間隔情報のフィールドには、ハートビートの送信間隔を示す秒単位の数値が設定される。【００５６】
このようなハートビートパケット３０を受信した監視ノード５００は、サーバ運用情報記憶部５１０内のサーバ運用情報テーブルにハートビートに基づく各サーバの運用状況を登録する。【００５７】
図６は、サーバ運用情報テーブルのデータ構造例を示す図である。サーバ運用情報テーブル５１１には、サービス提供ノードアドレス、アプリケーション識別番号、ハートビート間隔、ハートビート取得時刻および状態の欄が設けられている。【００５８】
サービス提供ノードアドレスの欄には、スイッチ１０を介して接続されている各サービス提供ノード１００，２００，３００，４００のアドレスが設定されている。
アプリケーション識別番号の欄には、各サービス提供ノード１００，２００，３００，４００に実装されているサーバのアプリケーション識別番号が設定されている。【００５９】
ハートビート間隔の欄には、対応するアプリケーション識別番号で示されるサーバがハートビートを送信する間隔が秒単位で設定されている。ハートビートの間隔は、ハートビートパケット３０におけるハートビート間隔情報に基づいて設定される。【００６０】
ハートビート取得時刻の欄には、対応するアプリケーション識別番号で示されるサーバからハートビートパケットを取得した時刻（ハートビート取得時刻）が設定される。このハートビート取得時刻と現在の時刻との差を計算することで、前回のハートビート取得からの経過時間を知ることができる。【００６１】
状態の欄には、対応するアプリケーション識別番号で示されるサーバが運用中か否かを示す状態情報が設定される。すなわち、ハートビート間隔で示される間隔でサーバからハートビートが送られてきている間は、そのサーバが運用中であると判断される。サーバからのハートビートが途切れると、そのサーバに障害が発生したものと判断され、状態情報として障害発生を示す情報が設定される。【００６２】
次に、ソフトウェア更新時のハートビート送信間隔変更処理について詳細に説明する。
図７は、ソフトウェア更新時のハートビート送信間隔変更処理手順を示すシーケンス図である。以下、図７に示す処理をステップ番号に沿って説明する。【００６３】
［ステップＳ１１］サービス提供ノード１００のサーバ１１０が有するハートビート送信部１１２は、サーバ１１０が起動されている間、予めデフォルト値として設定されたハートビート送信間隔でハートビートパケット３０を送信する。この際、ハートビートの送信間隔が１０秒と指定されているものとする。【００６４】
［ステップＳ１２］監視ノード５００のノード監視部５２０は、ハートビートパケット３０を取得する。そして、ノード監視部５２０は、サーバ運用情報記憶部５１０内のサーバ１１０に対応するハートビート取得時刻の欄に、現在の時刻を設定する。【００６５】
［ステップＳ１３］ハートビート送信部１１２は、前回のハートビートパケット３０の送信から１０秒経過前に、次のハートビートパケット３０を送信する。
［ステップＳ１４］ノード監視部５２０は、ハートビートパケット３０を取得する。この際、ノード監視部５２０は、前回のハートビート取得時刻からハートビート間隔で指定された時間を経過していないことから、サーバ１１０が正常に動作していることを認識する。また、ステップＳ１２と同様に、サーバ運用情報記憶部５１０内のハートビート取得時刻を更新する。【００６６】
［ステップＳ１５］サービス提供ノード１００の更新処理部１２０は、管理ノード７００から更新要求を受け取る。
［ステップＳ１６］更新処理部１２０は、サーバ１１０に対して停止コマンドを発行する。この停止コマンドには、ハートビート間隔の延長を指示するパラメータが付与される。図７の例では、ハートビート間隔を１２０秒にすることを示すパラメータが付与されている。【００６７】
［ステップＳ１７］サーバ１１０は、ハートビート間隔を変更する処理を伴う停止命令（停止用の処理ルーチン）をＲＡＭから読み出す。
［ステップＳ１８］サーバ１１０は、停止処理を開始する。【００６８】
［ステップＳ１９］サーバ１１０内のハートビート送信部１１２は、ハートビートパケット３０を監視ノード５００に対して送信する。この際、ハートビートパケット３０には、ハートビートの送信間隔を１２０秒にするハートビート間隔情報が含まれる。【００６９】
［ステップＳ２０］監視ノード５００のノード監視部５２０は、ハートビートパケット３０を取得する。この際、ノード監視部５２０は、前回のハートビート取得時刻からハートビート間隔で指定された時間を経過していないことから、サーバ１１０が正常に動作していることを認識する。また、サーバ運用情報記憶部５１０内のハートビート取得時刻を更新する。【００７０】
［ステップＳ２１］ノード監視部５２０は、ハートビートパケット３０で指定されたハートビート間隔が、サーバ運用情報テーブル５１１内においてサーバ１１０に対応付けて設定されたハートビート間隔と一致するか否かを判断する。なお、ステップＳ１２，Ｓ１４では省略したが、この判断処理はハートビートパケット３０を受信する度に行われる。この例では、ハートビート間隔が変更されているため一致しない。そこで、ノード監視部５２０は、サーバ運用情報記憶部５１０内のサーバ１１０に対応するハートビート間隔の欄に、ハートビートパケット３０で指定されたハートビート間隔（この例では１２０秒）を設定する。【００７１】
［ステップＳ２２］サービス提供ノード１００のサーバ１１０は停止処理を続行する。たとえば、サーバ１１０が使用していたメモリ領域の開放処理が行われる。
［ステップＳ２３］サーバ１１０は運用を停止する。すなわち、旧版のプログラムによってサーバ１１０の機能を提供していたプロセスが停止する。【００７２】
［ステップＳ２４］更新処理部１２０は、サーバ１１０が停止したことを確認する。例えば、サーバ１１０の機能を提供していたプロセスが停止したことを確認する。
［ステップＳ２５］更新処理部１２０は、更新要求と共に管理ノード７００から送られた更新ファイル（プログラムファイルや環境定義ファイルなどを含む）を、サーバ１１０を実行するために用意されたフォルダにコピーする。【００７３】
［ステップＳ２６］更新処理部１２０は、サーバ１１０の起動コマンドを発行する。すなわち、更新処理部１２０は、ＯＳに対してサーバ１１０を実現するためのプログラムの名称（パスとファイル名）を指定した実行要求を発行する。【００７４】
［ステップＳ２７］ファイルの更新が行われたサーバ１１０の機能を提供するプロセスがＯＳによって生成され、そのプロセスが更新後のプログラムファイルに示されるプログラムの実行を開始する。その際、サーバ１１０は、最初に初期化処理を行う。初期化処理では、たとえば、メモリ領域の獲得や、動作環境の設定が行われる。【００７５】
［ステップＳ２８］サーバ１１０は、起動処理が終了すると、通常の運用を開始する。
［ステップＳ２９］サーバ１１０内のハートビート送信部１１２は、ハートビートパケット３０を監視ノード５００に対して送信する。この際、ハートビートパケット３０には、予め設定されたデフォルト値（この例では１０秒）をハートビート間隔として指定したハートビート間隔情報が含まれる。【００７６】
［ステップＳ３０］ノード監視部５２０は、ハートビートパケット３０を取得する。この際、ノード監視部５２０は、前回のハートビート取得時刻からハートビート間隔で指定された時間（１２０秒）を経過していないことから、サーバ１１０が正常に動作していることを認識する。また、ステップＳ１２と同様に、サーバ運用情報記憶部５１０内のハートビート取得時刻を更新する。【００７７】
［ステップＳ３１］ノード監視部５２０は、ハートビートパケット３０で指定されたハートビート間隔が、サーバ運用情報テーブル５１１内においてサーバ１１０に対応付けて設定されたハートビート間隔と一致するか否かを判断する。この例では、ハートビート間隔が変更されているため一致しない。そこで、ノード監視部５２０は、サーバ運用情報記憶部５１０内のサーバ１１０に対応するハートビート間隔の欄に、ハートビートパケット３０で指定されたハートビート間隔（この例では１０秒）を設定する。【００７８】
［ステップＳ３２］ハートビート送信部１１２は、前回のハートビートパケット３０の送信から１０秒経過前に、次のハートビートパケット３０を送信する。
［ステップＳ３３］ノード監視部５２０は、ハートビートパケット３０を取得する。この際、ノード監視部５２０は、前回のハートビート取得時刻からハートビート間隔で指定された時間を経過していないことから、サーバ１１０が正常に動作していることを認識する。また、ステップＳ１２と同様に、サーバ運用情報記憶部５１０内のハートビート取得時刻を更新する。【００７９】
このようにしてサーバ１１０のソフトウェアを更新する際に、一時的にハートビート間隔を延長することができる。その結果、ノード監視部５２０において故障扱いされずにすむ。【００８０】
すなわち、ノード監視部５２０においてサーバ１１０が故障していると判断されてしまうと、監視ノード５００においてサービス提供ノード１００に関するエラー処理が実行されてしまう。エラー処理には、サービスの処理要求の送信先となるノード群からサービス提供ノード１００を除外する処理が含まれる。サービスの処理要求の送信先からサービス提供ノード１００が除外されると、サーバ１１０の再起動後に、サービスの処理要求の送信先となるノード群としてサービス提供ノード１００を追加する処理を行わなければならない。これらのエラー処理とエラーからの復旧処理を行うことは、サービス停止期間の長期化の要因となる。【００８１】
本実施の形態のように、ハートビート間隔の延長によってエラーの発生を防止すれば、サービスの停止期間は、ソフトウェアの更新処理の期間だけですむ。その結果、ソフトウェア更新に伴うシステム全体としての運用効率の低下を最小限に抑えることができる。【００８２】
次に、ソフトウェア更新中に処理要求をサービス提供ノード１００に対して送信した処理要求ノード６００でエラーが発生するのを防止する処理について説明する。この処理は、更新処理部１２０において、処理要求に対してサーバ１１０の資源が不足していることを示す応答を返すことによって実現される。資源不足を示す応答には、たとえば、ＵＮＩＸ（登録商標）におけるＥＡＧＡＩＮなどがある。【００８３】
すなわち、処理要求部６１０では、処理要求をサービス提供ノード１００に送信したとき、その処理要求に対する応答を待つ。所定期間待っても応答が受け取れない場合、処理要求部６１０はエラー処理を行う。エラー処理としては、たとえば、処理要求部６１０は、処理要求の送信元である端末装置へエラーメッセージを送信する。【００８４】
このようなエラー処理を発生させないためには、サーバ１１０のソフトウェアを更新中であっても、処理要求に対して所定期間内に何らかの応答を返す必要がある。サーバ１１０の運用が停止しているときに処理結果を応答することはできないため、本実施の形態では、更新処理部１２０がサーバ１１０に代わって資源不足を示す応答を返すこととする。資源不足は、サービス提供ノード１００におけるハードウェアやソフトウェアの障害と異なり、一定時間待つことで解消されることが期待できる。そのため、資源不足の応答を受け取った処理要求部６１０は、処理要求のリトライを行う。通常は、リトライを何度か繰り返しても資源不足が解消されない場合に、処理要求部６１０はエラー処理を行う。従って、処理要求部６１０がリトライを繰り返している間にサーバ１１０のソフトウェアを更新し、再起動させることとで、処理要求ノード６００でエラーが検出されることを防止できる。【００８５】
図８は、ソフトウェア更新中に代理応答を行う処理手順を示すシーケンス図である。以下、図８に示す処理をステップ番号に沿って説明する。
［ステップＳ４１］処理要求ノード６００の処理要求部６１０は、端末装置から出された処理要求をサービス提供ノード１００に送信する。このとき、処理要求に送信先のポート番号として、サーバ１１０が開設しているポート番号が指定される。【００８６】
［ステップＳ４２］サービス提供ノード１００のサーバ１１０内の処理実行部１１１が処理要求を受信する。
［ステップＳ４３］処理実行部１１１は、処理要求に応じた処理を実行する。【００８７】
［ステップＳ４４］処理実行部１１１は、処理結果を処理要求に対する応答として処理要求ノード６００に送信する。
［ステップＳ４５］処理要求ノード６００の処理要求部６１０は、応答を受信し、応答で示される処理結果を端末装置に送信する。【００８８】
［ステップＳ４６］サービス提供ノード１００の更新処理部１２０は、管理ノード７００から更新要求を受け取る。
［ステップＳ４７］更新処理部１２０は、サーバ１１０に対して停止コマンドを発行する。【００８９】
［ステップＳ４８］サーバ１１０は、受信ポートを閉塞する。
［ステップＳ４９］サーバ１１０は、停止処理を開始する。
［ステップＳ５０］更新処理部１２０は、サーバ１１０が使用していた受信ポートを、自己の受信ポートとして開設する。【００９０】
［ステップＳ５１］処理要求ノード６００の処理要求部６１０は、端末装置から出された処理要求をサービス提供ノード１００に送信する。このとき、処理要求に送信先のポート番号として、サーバ１１０が開設していたポート番号であり、現在は更新処理部１２０が開設しているポート番号が指定される。【００９１】
［ステップＳ５２］更新処理部１２０は、サービス提供ノード１００のサーバ１１０内の処理実行部１１１が処理要求を受信する。
［ステップＳ５３］更新処理部１２０は、資源不足を示す応答（Ｂｕｓｙ）を処理要求ノード６００に送信する。【００９２】
［ステップＳ５４］処理要求ノード６００の処理要求部６１０は、資源不足を示す応答（Ｂｕｓｙ）を受信する。処理要求部６１０は、応答の内容により、サービス提供ノード１００の資源が不足していることにより処理が実行できないものと認識する。【００９３】
［ステップＳ５５］サービス提供ノード１００のサーバ１１０は運用を停止する。すなわち、旧版のプログラムによってサーバ１１０の機能を提供していたプロセスが停止する。【００９４】
［ステップＳ５６］処理要求ノード６００の処理要求部６１０は、サーバ１１０が停止したことを確認する。例えば、サーバ１１０の機能を提供していたプロセスが停止したことを確認する。【００９５】
［ステップＳ５７］更新処理部１２０は、更新要求と共に管理ノード７００から送られた更新ファイル（プログラムファイルや環境定義ファイルなどを含む）を、サーバ１１０を実行するために用意されたフォルダにコピーする。【００９６】
［ステップＳ５８］更新処理部１２０は、サーバ１１０の起動コマンドを発行する。すなわち、更新処理部１２０は、ＯＳに対してサーバ１１０を実現するためのプログラムの名称（パスとファイル名）を指定した実行要求を発行する。【００９７】
［ステップＳ５９］ファイルの更新が行われたサーバ１１０の機能を提供するプロセスがＯＳによって生成され、そのプロセスが更新後のプログラムファイルに示されるプログラムの実行を開始する。その際、サーバ１１０は、最初に初期化処理を行う。初期化処理では、たとえば、メモリ領域の獲得や、動作環境の設定が行われる。【００９８】
［ステップＳ６０］サーバ１１０は、起動処理が終了すると、通常の運用を開始する。
［ステップＳ６１］処理要求ノード６００の処理要求部６１０は、ステップＳ５０で開設した受信ポートを閉塞する。【００９９】
［ステップＳ６２］サーバ１１０は、受信ポートを開設する。
［ステップＳ６３］処理要求ノード６００の処理要求部６１０は、端末装置から出された処理要求をサービス提供ノード１００に再度送信する（リトライ）。【０１００】
［ステップＳ６４］サービス提供ノード１００のサーバ１１０内の処理実行部１１１が処理要求を受信する。
［ステップＳ６５］処理実行部１１１は、処理要求に応じた処理を実行する。【０１０１】
［ステップＳ６６］処理実行部１１１は、処理結果を処理要求に対する応答として処理要求ノード６００に送信する。
［ステップＳ６７］処理要求ノード６００の処理要求部６１０は、応答を受信し、応答で示される処理結果を端末装置に送信する。【０１０２】
このようにして、処理要求を送信する処理要求ノード６００でエラーを発生させることなく、サービス提供ノード１００のサーバ１１０を実現するためのソフトウェアを更新することができる。【０１０３】
なお、図７と図８に示した処理の中には、両方のシーケンス図に重複して示されている処理がある。そこで、更新処理部１２０の処理のみを整理した処理手順を以下に示す。
図９は、更新処理部の処理手順を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。【０１０４】
［ステップＳ７１］更新処理部１２０は、管理ノード７００から更新要求を受け取る。
［ステップＳ７２］更新処理部１２０は、サーバ１１０に対して停止コマンドを発行する。この停止コマンドには、ハートビート間隔の延長を指示するパラメータが付与される。【０１０５】
［ステップＳ７３］更新処理部１２０は、サーバ１１０が使用していた受信ポートを、自己の受信ポートとして開設する。
［ステップＳ７４］更新処理部１２０は、処理要求応答用プロセスを起動する。起動された処理要求応答用プロセスは、並列処理で処理要求に対する（Ｂｕｓｙ）応答を行う。この処理の詳細は図１０に示す。【０１０６】
［ステップＳ７５］更新処理部１２０は、サーバ１１０が停止したことを確認する。例えば、サーバ１１０の機能を提供していたプロセスが停止したことを確認する。
［ステップＳ７６］更新処理部１２０は、更新要求と共に管理ノード７００から送られた更新ファイルを、サーバ１１０を実行するために用意されたフォルダにコピーする。【０１０７】
［ステップＳ７７］更新処理部１２０は、サーバ１１０の起動コマンドを発行する。
［ステップＳ７８］更新処理部１２０は、受信ポートを閉塞する。
［ステップＳ７９］更新処理部１２０は、処理要求応答用プロセスを停止する。その後、処理が終了する。【０１０８】
図１０は、処理要求応答用プロセスの処理手順を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。
［ステップＳ９１］更新処理部１２０は、処理要求を受信したか否かを判断する。処理要求を受信した場合、処理がステップＳ９２に進められる。処理要求を受信していない場合、処理がステップＳ９４に進められる。【０１０９】
［ステップＳ９２］更新処理部１２０は、処理要求を取得する。
［ステップＳ９３］更新処理部１２０は、処理要求に対して資源不足を示す応答（Ｂｕｓｙ）を送信する。その後、処理がステップＳ９１に進められる。【０１１０】
［ステップＳ９４］更新処理部１２０は、処理要求応答用プロセスの停止タイミングとなったか否かを判断する。停止タイミングとは、図９のステップＳ７９に達したときである。停止タイミングでなければ、処理がステップＳ９１に進められる。停止タイミングになったら、処理要求応答用プロセスが停止する。【０１１１】
次に、ノード監視部５２０の処理を詳細に説明する。ノード監視部５２０の処理は、ハートビート取得処理と状態監視処理に分かれる。
図１１は、ノード監視部におけるハートビート取得処理を示す図である。以下、図１１に示す処理をステップ番号に沿って説明する。【０１１２】
［ステップＳ１０１］ノード監視部５２０は、ハートビートパケットを受信したか否かを判断する。ハートビートパケットを受信した場合、処理がステップＳ１０２に進められる。ハートビートパケットを受信していなければ、ステップＳ１０１の処理が繰り返される。【０１１３】
［ステップＳ１０２］ノード監視部５２０は、受信したハートビートパケットの送信元であるサービス提供ノードのアドレスとアプリケーション識別番号を取得し、サーバ運用情報テーブル５１１内の該当するレコードを参照する。【０１１４】
［ステップＳ１０３］ノード監視部５２０は、参照しているレコードのハートビート間隔の値が、受信したハートビートパケットに示されるハートビート間隔情報の値と一致するか否かを判断する。一致した場合、処理がステップＳ１０５に進められる。一致しない場合、処理がステップＳ１０４に進められる。【０１１５】
［ステップＳ１０４］ノード監視部５２０は、ハートビート送信間隔の値を変更する。具体的には、ノード監視部５２０は、受信したハートビートパケットに示されるハートビート間隔情報の値を、参照しているレコードにおけるハートビート間隔の欄に登録する。【０１１６】
［ステップＳ１０５］ノード監視部５２０は、参照しているレコードのハートビート取得時刻の欄に、現在の時刻を記録する。
［ステップＳ１０６］ノード監視部５２０は、参照しているレコードの状態が運用停止状態か否かを判断する。運用停止状態であれば、処理がステップＳ１０７に進められる。運用停止状態でなければ、処理がステップＳ１０１に進められる。【０１１７】
［ステップＳ１０７］ノード監視部５２０は、参照しているレコードの状態を運用中に変更し、処理をステップＳ１０１に進める。
図１２は、ノード監視部の状態監視処理手順を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。なお、この処理は、所定の時間間隔で定期的に実行される処理である。【０１１８】
［ステップＳ１１１］ノード監視部５２０は、サービス提供ノードを１つ選択する。具体的には、ノード監視部５２０は、サーバ運用情報テーブル５１１内のサービス提供ノードアドレスを１つ選択する。【０１１９】
［ステップＳ１１２］ノード監視部５２０は、選択したサービス提供ノードで運用されるサーバを１つ選択する。具体的には、ノード監視部５２０は、サーバ運用情報テーブル５１１内において、選択したサービス提供ノードアドレスに対応付けられたアプリケーション識別番号から１つを選択する。【０１２０】
［ステップＳ１１３］ノード監視部５２０は、ハートビート取得時刻からの経過時間を算出する。具体的には、サーバ運用情報テーブル５１１内の選択したアプリケーション識別番号に対応するハートビート取得時刻の値を、現在の時刻から減算する。減算結果が経過時間である。【０１２１】
［ステップＳ１１４］ノード監視部５２０は、経過時間に基づいて、ハートビート間隔以上経過したか否かを判断する。具体的には、ノード監視部５２０は、サーバ運用情報テーブル５１１内の選択したアプリケーション識別番号に対応するハートビート間隔の値と、ステップＳ１１３で算出した経過時間を比較する。ノード監視部５２０は、経過時間の方が所定の遅延許容値以上に大きい場合に、ハートビート間隔以上経過したものと判断する。たとえば、ハートビート間隔の１割を遅延許容値とした場合、ハートビート間隔を１．１倍した値よりも経過時間が大きければ、ハートビート間隔以上経過したこととなる。ハートビート間隔以上経過した場合、処理がステップＳ１１５に進められる。ハートビート間隔以上経過していなければ、処理がステップＳ１１７に進められる。【０１２２】
［ステップＳ１１５］ノード監視部５２０は、ハートビート間隔以上経過していた場合、選択中のサーバを運用停止状態にする。具体的には、ノード監視部５２０は、サーバ運用情報テーブル５１１内の選択したアプリケーション識別番号に対応する状態の欄の値を、エラーに変更する。【０１２３】
［ステップＳ１１６］ノード監視部５２０は、エラー処理を実行する。たとえば、ノード監視部５２０は、処理要求ノード６００に対して、処理要求の送信先の候補から、選択中のサービス提供ノードを除外すべき旨の指示を送信する。この指示を受信した処理要求ノード６００の処理要求部６１０は、指定されたサービス提供ノードを処理要求の送信先の候補から除外する。【０１２４】
［ステップＳ１１７］ノード監視部５２０は、選択中のサービス提供ノードで運用されている全てのサーバを選択したか否かを判断する。具体的には、ノード監視部５２０は、サーバ運用情報テーブル５１１内において、ステップＳ１１１で選択したサービス提供ノードアドレスに対応付けられたすべてのアプリケーション識別番号についてステップＳ１１３〜Ｓ１１６の処理を実行した場合、全てのサーバを選択したと判断する。全てのサーバを選択した場合、処理がステップＳ１１８に進められる。未選択のサーバがある場合、処理がステップＳ１１２に進められる。【０１２５】
［ステップＳ１１８］ノード監視部５２０は、全てのサービス提供ノードを選択したか否かを判断する。具体的には、ノード監視部５２０は、サーバ運用情報テーブル５１１内のサービス提供ノードアドレスを全て選択済み場合、全てのサービス提供ノードを選択したものと判断する。全てのサービス提供ノードを選択した場合、処理が終了する。未選択のサービス提供ノードがある場合、処理がステップＳ１１１に進められる。【０１２６】
次に、処理要求部６１０が行う端末装置からの処理要求の仲介処理の詳細について説明する。
図１３は、処理要求仲介処理の手順を示すフローチャートである。以下、図１３に示す処理を、ステップ番号に沿って説明する。なお、この処理は、端末装置から処理要求が入力されたときに実行される。【０１２７】
［ステップＳ１２１］処理要求部６１０は、端末装置からの処理要求を取得する。
［ステップＳ１２２］処理要求部６１０は、処理要求の送信先とするサービス提供ノードを決定する。たとえば、処理要求部６１０は、現在の処理負荷の少ないサービス提供ノードを送信先とする。【０１２８】
［ステップＳ１２３］処理要求部６１０は、ステップＳ１２２で決定したサービス提供ノードに対して、端末装置から送られた処理要求を送信する。
［ステップＳ１２４］処理要求部６１０は、サービス提供ノードから応答があったか否かを判断する。応答があった場合、処理がステップＳ１２７に進められる。応答がない場合、処理がステップＳ１２５に進められる。【０１２９】
［ステップＳ１２５］処理要求部６１０は、処理要求を送信してから応答が無いまま所定の時間経過したか否かを判断する。所定時間経過した場合、処理がステップＳ１２６に進められる。所定時間経過していない場合、処理がステップＳ１２４に進められる。【０１３０】
［ステップＳ１２６］処理要求部６１０は、エラー処理を行う。たとえば、処理要求部６１０は、処理要求を出力した端末装置に対して、エラーメッセージを送信する。その後、処理を終了する。【０１３１】
［ステップＳ１２７］処理要求部６１０は、受信した応答の内容が資源不足を示す応答（Ｂｕｓｙ）か否かを判断する。資源不足を示す応答であれば、処理がステップＳ１２９に進められる。資源不足の応答でなければ、処理がステップＳ１２８に進められる。【０１３２】
［ステップＳ１２８］処理要求部６１０は、サービス提供ノードからの応答を端末装置に送信する。その後、処理を終了する。
［ステップＳ１２９］処理要求部６１０は、リトライ回数が、予め設定された所定回数を超えたか否かを判断する。リトライ回数は、リトライ回数カウンタの値を参照して判断される。なお、リトライ回数カウンタの値は、端末装置からの処理要求を受け取ったときに０に初期化されているものとする。リトライ回数が所定回数を超えた場合、処理がステップＳ１３２に進められる。リトライ回数が所定回数を超えていなければ、処理がステップＳ１３０に進められる。【０１３３】
［ステップＳ１３０］処理要求部６１０は、所定時間待機する。
［ステップＳ１３１］処理要求部６１０は、リトライ回数カウンタに１を加算し、処理をステップＳ１２３に進める。【０１３４】
［ステップＳ１３２］処理要求部６１０は、リトライ回数が所定回数を超えると、エラー処理を行う。たとえば、処理要求部６１０は、処理要求を出力した端末装置に対して、エラーメッセージを送信する。その後、処理を終了する。【０１３５】
以上のようにして、エラーを発生させずに、サーバのソフトウェアの更新が可能となる。その結果、ソフトウェア更新作業時のシステムの運用効率の低下を最小限に抑えることができる。【０１３６】
特に、サービス提供ノードがストレージサーバとして機能していた場合、サービス提供ノードの運用が停止すると、そのサービス提供ノードで管理していたデータを、全ての他のストレージサーバ内に生成する必要がある。【０１３７】
たとえば、複数のストレージサーバを用いてミラーリングを行っていた場合、一方のストレージサーバの運用が停止したままだと、システムの信頼性が損なわれてしまう。そこで、正常に運用しているストレージサーバから新たにミラーリングの相手となるストレージサーバに対して、データをコピーする必要がある。簡単なソフトウェアの更新作業を行うだけで、大量のデータのコピー処理が発生したのでは、ネットワーク負荷が増大し、システムの運用効率が極めて低下してしまう。本実施の形態の技術を適用すれば、ソフトウェアの更新時にエラーを発生させずに済み、運用効率の低下が最小限に抑えられる。【０１３８】
ところで、上記の実施の形態では、ハートビートの送信間隔を延長することで、監視ノード５００でのエラーの発生を防いでいるが、処理要求部６１０がサーバ１１０の代理でハートビートパケットを送信することで、監視ノード５００でのエラーの発生を防ぐこともできる。その場合、更新処理部１２０は、図８に示す受信ポート開設（ステップＳ５０）から受信ポート閉塞（ステップＳ６１）まで、所定間隔（たとえば１０秒間隔）でハートビートパケット３０を監視ノード５００に対して送信する。このとき、更新処理部１２０は、ハートビートパケット３０のアプリケーション識別番号のフィールドにサーバ１１０の識別番号を設定する。これにより、監視ノード５００では、サーバ１１０が出力したハートビートパケット３０と認識される。この処理を行えば、図７に示すサーバ１１０のハートビート送信間隔を１２０秒としたハートビート送信処理（ステップＳ１９）を行う必要がなくなる。【０１３９】
また、上記の例では、サーバ１１０の運用停止後にソフトウェアの更新作業を行っているが、サーバ１１０を運用したまま新たなソフトウェアのインストール作業ができる場合もある。たとえば、処理要求の実行対象がポート番号のみで決定され実行ファイルのファイル名に依存しない場合、別のファイル名で新規のソフトウェアをインストールできる。その場合、旧版のソフトウェアと新版のソフトウェアとを同時に起動させることができる。そこで、旧版のソフトウェアに基づくサーバから新版のソフトウェアに基づくサーバへ通信ポートを引き継がせることで、エラーを発生させずにソフトウェアの更新が可能となる。【０１４０】
通信ポートの引継を行うため、新版のソフトウェアに基づくサーバは、旧版のソフトウェアに基づくサーバがポートを閉塞させるまで、ポート開設の処理を繰り返し実行する。旧版のソフトウェアに基づくサーバが停止すると、そのサーバは使用していたポートを閉塞する。その後、新版のソフトウェアに基づくサーバによるポートの開設処理が成功し、以後、新版のソフトウェアに基づくサーバが処理要求に応じた処理、および定期的なハートビートの送信を行う。【０１４１】
なお、通信ポートの引継は、旧版のソフトウェアに基づくサーバと新版のソフトウェアに基づくサーバとが同一の通信ポートを使用するために必要な処理である。そのため、ソフトウェアの更新前後において、異なるポート番号を使用することができる場合、通信ポートを引き継ぐ必要なない。ただし、異なるポート番号を使用した場合、ソフトウェア更新前のサーバに渡されていた処理要求を、ソフトウェア更新後のサーバに渡すように制御する仕組みが必要である。【０１４２】
たとえば、Sun Microsystems社のＲＰＣ(Remote Procedure Call)を使用するサービスでは、サービス名とバージョン名をポートマッパに登録する。この技術を用いて、処理要求を渡すサーバの変更が可能となる。【０１４３】
具体的には、ソフトウェア更新後の新しいサーバを、更新前のサーバと同じ名前のサービス名、別のバージョン番号でポートマッパに登録する。クラスタ内の他の機能（たとえば、処理要求部６１０）は、今までのサーバとの通信が不能になると、同じＩＰアドレスに対し、そのサービスの新しいバージョン番号のポート番号をとりなおす。バージョン番号についてはあらかじめルール化しておく。たとえば、新しいバージョン番号をポートマッパに登録するごとに、バージョン番号が昇順に番号が増えてゆくように、バージョン番号の設定方式を取り決めておく。【０１４４】
この方法では、明示的にバージョン番号を意識するので、ソフトウェア更新とともにプロトコルの更新を行なうこともできる。また、全てのノードにおいて、一斉にソフトウェア更新を行なうこともできる。【０１４５】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、サービス提供ノードや監視ノードが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。【０１４６】
プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。【０１４７】
プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。【０１４８】
なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。
上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。
【符号の説明】
【０１４９】
１  サービス提供ノード
１ａ  処理実行手段
１ｂ  ハートビート送信手段
１ｃ  更新処理手段
２  監視ノード
２ａ  ハートビート間隔情報記憶手段
２ｂ  ハートビート間隔情報更新手段
２ｃ  ハートビート監視手段
【図１】
2008126325.tif 000003
【図２】
2008126325.tif 000004
【図３】
2008126325.tif 000005
【図４】
2008126325.tif 000006
【図５】
2008126325.tif 000007
【図６】
2008126325.tif 000008
【図７】
2008126325.tif 000009
【図８】
2008126325.tif 000010
【図９】
2008126325.tif 000011
【図１０】
2008126325.tif 000012
【図１１】
2008126325.tif 000013
【図１２】
2008126325.tif 000014
【図１３】
2008126325.tif 000015
【国際調査報告】
2008126325.tif 000016
2008126325.tif 000017
2008126325.tif 000018
2008126325.tif 000019