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