(57)【要約】【課題】予備プロセスを多数用意した場合に発生するオーバーヘッドを軽減する。【解決手段】複数の計算機内に同一のサービスを提供する実行プロセス3a〜3cと、実行プロセスの障害に備える第１、第２の予備プロセス4a〜4c、5a、5bとを分散配置し、クライアント2a、2bが実行プロセスと第１及び第２の予備プロセスとに同一のデータを送信することによって、実行プロセスと第１の予備プロセスとは、お互いに自プロセスで保持するデータの同期を取りながら動作し、第２の予備プロセスは、実行プロセスが保持するデータの一部のサービスについて実行プロセスと同期をとって動作して業務処理を行う。【選択図】図１
2009211536.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからの要求による業務処理を行うコンピュータを使用した複数の予備プロセスを持つ業務処理システムでの系切り替え方法において、
複数の計算機内に同一のサービスを提供する複数のプロセスを分散して配置し、前記複数のプロセスの１つをサービスを提供する実行プロセスとし、他の複数のプロセスを前記実行プロセスの障害に備える予備プロセスとし、複数の予備プロセスを第１及び第２の予備プロセスの２種類の予備プロセスとし、
前記クライアントが前記実行プロセスと前記第１及び第２の予備プロセスとに同一のデータを送信することによって、前記実行プロセスと前記第１の予備プロセスとは、お互いに自プロセスで保持するデータの同期を取りながら動作し、前記第２の予備プロセスは、前記実行プロセスが保持するデータの一部のサービスについて前記実行プロセスと同期をとって動作して業務処理を行うことを特徴とする系切り替え方法。
【請求項２】
前記第２の予備プロセスは、前記実行プロセスが提供するサービスに重要度を設定し、自プロセスが動作する計算機の動作状況とサービスの重要度に応じて、同期をとるデータ量の調整を行うことを特徴とする請求項１記載の系切り替え方法。
【請求項３】
前記前記実行プロセスと前記第１及び第２の予備プロセスとがプロセスグループとして管理されており、前記プロセスグループ内に少なくとも２つの前記第１の予備プロセスが含まれていて、前記実行プロセスに障害が発生した場合、１つの前記第１の予備プロセスが実行プロセスに遷移させられることを特徴とする請求項１または２記載の系切り替え方法。
【請求項４】
前記前記実行プロセスと前記第１及び第２の予備プロセスとがプロセスグループとして管理されており、前記プロセスグループ内に１つの前記第１の予備プロセスと少なくとも２つの前記第２の予備プロセスが含まれていて、前記実行プロセスに障害が発生した場合、１つの前記第２の予備プロセスが実行プロセスに遷移させられ、実行プロセスに遷移させられた第２の予備プロセスは、自プロセスで管理しているサービスについて前記実行プロセスと同期をとって動作して業務処理を行い、その後、２つの前記第２の予備プロセスとが連携して非同期にサービスの回復を行って、前記第１の予備プロセスが実行プロセスに遷移させられることを特徴とする請求項１または２記載の系切り替え方法。
【請求項５】
クライアントからの要求による業務処理を行うコンピュータを使用した複数の予備プロセスを持つ業務処理システムにおいて、
複数の計算機内に同一のサービスを提供する複数のプロセスを分散して配置し、前記複数のプロセスの１つをサービスを提供する実行プロセスとし、他の複数のプロセスを前記実行プロセスの障害に備える予備プロセスとし、複数の予備プロセスを第１及び第２の予備プロセスの２種類の予備プロセスとし、
前記クライアントが前記実行プロセスと前記第１及び第２の予備プロセスとに同一のデータを送信することによって、前記実行プロセスと前記第１の予備プロセスとは、保持するデータの同期を取りながら動作し、前記第２の予備プロセスは、前記実行プロセスが保持するデータの一部のサービスについて前記実行プロセスと同期をとって動作して業務処理を行うことを特徴とする業務処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、系切り替え方法及び業務処理システムに係り、特に、コンピュータを使用した複数の予備プロセスを持つ業務処理システムでの系切り替え方法及び業務処理システムに関する。
【背景技術】
【０００２】
業務処理システムは、クライアント・サーバ型の計算機システム内に構築されることが多く、このようなクライアント・サーバ型の業務処理システムは、サーバがクライアントからのサービス要求を受信した後に異常終了すると、そのサービス要求電文が失われてしまうことになる。サービス要求電文を失わないようにすることができる方法は、従来から多数提案されているが、その１つに、サービスを提供するプロセスと障害に備えるプロセスとが同一データに対して、同期を取りながら業務を行うという方法が知られている。
【０００３】
なお、この種の方法に関する従来技術として、例えば、特許文献１等に記載された技術が知られている。
【特許文献１】特開２００４−３２２２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
複数の実行プロセスと予備プロセスとを有し、実行プロセスと予備プロセスとがメモリ同期をとって動作する分散型ネットワークシステムは、計算機やプロセスに障害が発生すると、処理中のデータが失われてしまうものである。多重障害によるデータの損失を防止するためには、予備プロセスを多数の計算機に分散して配置する必要がある。その場合、予備プロセスの数が増大するために、実行プロセスと予備プロセスとの間の同期処理によって多量の計算機資源を消費し、業務処理システムの性能に影響を及ぼしてしまうという問題を生じさせる。しかも、実行プロセスと予備プロセスとの同期処理が業務処理システムに与える影響は、業務処理システムを構成する計算機の能力差や計算機上のプロセスの数や種類によって一意ではないという問題を有している。
【０００５】
また、メモリ同期を行う業務処理システムは、実行プロセスと待機プロセスとが提供するサービスが常に同期している必要があり、実行プロセスと同期のとれていない予備プロセスへの系の切り替えを行うと、系切り替えの失敗やデータの損失が発生するという問題を生じさせる。
【０００６】
前述したような点に鑑み、本発明の目的は、予備プロセスを多数用意した場合に発生するオーバーヘッドを軽減することができる系切り替え方法及び業務処理システムを提供することにある。
【課題を解決するための手段】
【０００７】
本発明によれば前記目的は、クライアントからの要求による業務処理を行うコンピュータを使用した複数の予備プロセスを持つ業務処理システムでの系切り替え方法において、複数の計算機内に同一のサービスを提供する複数のプロセスを分散して配置し、前記複数のプロセスの１つをサービスを提供する実行プロセスとし、他の複数のプロセスを前記実行プロセスの障害に備える予備プロセスとし、複数の予備プロセスを第１及び第２の予備プロセスの２種類の予備プロセスとし、前記クライアントが前記実行プロセスと前記第１及び第２の予備プロセスとに同一のデータを送信することによって、前記実行プロセスと前記第１の予備プロセスとが、お互いに自プロセスで保持するデータの同期を取りながら動作し、前記第２の予備プロセスが、前記実行プロセスが保持するデータの一部のサービスについて前記実行プロセスと同期をとって動作して業務処理を行うことにより達成される。
【発明の効果】
【０００８】
本発明によれは、多数の予備プロセスを使用する業務処理システムにおいて、実行プロセスと予備プロセスとが同期する業務処理システムが本来持つ高速な系切り替えを損なわずに、実行プロセスと予備プロセスとの同期処理が引き起こす性能低下の軽減を図ることができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明による系切り替え方法及び業務処理システムの実施形態を図面により詳細に説明する。
【００１０】
図１は本発明の一実施形態による業務処理システムの構成を示すブロックである。図１に示す業務処理システムは、複数の計算機のそれぞれがサーバとして動作するようにネットワークにより相互に接続されて構成されるクライアント・サーバ型の計算機システム内に構築された例である。
【００１１】
本発明の実施形態による業務処理システムは、複数のサーバ１ａ、１ｂ、１ｃ、１ｄ、１ｅ、１ｆがネットワークを介して接続されて構成されている。複数のサーバ１ａ、１ｂは、クライアントとしての機能を実行するものであり、それぞれに、サービス要求を行う複数のクライアントプロセス２ａ、２ｂが備えられている。図示例では、クライアントとしてのサーバを２台だけ示しているが、さらに多くのクライアントとしてのサーバが設けられていてもよい。
【００１２】
また、複数のサーバ１ｃ、１ｄ、１ｅ、１ｆは、クライアントプロセス２ａ、２ｂからの要求に従ってサービスの実行を行うサーバであり、複数のサーバ１ｃ、１ｄ、１ｅ、１ｆには、サービスの実行を行う複数の実行プロセス３ａ、３ｂ、３ｃ、実行プロセスの障害発生時にサービス実行を続行するための複数の予備プロセス４ａ、４ｂ、４ｃ及び５ａ、５ｂ、クライアントプロセス２ａ、２ｂに対して実行プロセス及び予備プロセスの位置情報を通知するネームサービス６ａ、６ｂ、実行プロセスに障害が発生したことを検知し予備プロセスのうちの１つを実行プロセスに変更するように指示を行うクラスタサービス７ａ、７ｂ、７ｃ、７ｄが分散して配置されている。予備プロセスは、プライマリ予備プロセス（以下、Ｐ予備プロセスという）４ａ、４ｂ、４ｃとセカンダリ予備プロセス（以下、Ｓ予備プロセスという）５ａ、５ｂとに分類されている。
【００１３】
図１に示す例では、サーバ１ｃには、ネームサービス６ａ、実行プロセス３ａ、クラスタサービス７ａ、Ｓ予備プロセス５ｂが配置され、サーバ１ｄには、ネームサービス６ｂ、Ｐ予備プロセス４ａ、クラスタサービス７ｂ、実行プロセス３ｂが配置され、サーバ１ｅには、Ｐ予備プロセス４ｂ、クラスタサービス７ｃ、Ｐ予備プロセス４ｃが配置され、サーバ１ｆには、Ｓ予備プロセス５ａ、クラスタサービス７ｄ、実行プロセス３ｃが配置されている。
【００１４】
前述において、Ｐ予備プロセス４ａ、４ｂは、実行プロセス３ａに障害が発生した場合に備えて実行プロセス３ａが保持するサービス要求を完全に同期させておくための予備プロセスである。同様に、Ｐ予備プロセス４ｃは、実行プロセス３ｂが保持するサービス要求を完全に同期させるための予備プロセスである。また、Ｓ予備プロセス５ａは、自プロセスが構築されている計算機であるサーバ１ｆや、後述する自プロセスが属するプロセスグループ内の実行プロセス３ａ、自プロセスが構築されているサーバ１ｆ内の実行プロセス３ｃの動作状況を監視し、負荷が高い場合に、同期するサービス要求の量を調整し、業務処理システム全体の負荷軽減を図る制御を行う予備プロセスである。
【００１５】
説明している本発明の実施形態は、実行プロセス３ａとその実行プロセスのための予備プロセス４ａ、４ｂ、５ａとをまとめて１つのプロセスグループ８ａという単位により管理している。同様に、実行プロセス３ｂ、３ｃと予備プロセス４ｃ、５ｂとは、まとめられて１つのプロセスグループ８ｂという単位で管理されている。
【００１６】
実行プロセス３ａ、Ｐ予備プロセス４ａ、４ｂ、Ｓ予備プロセス５ａは、それぞれ、異なるサーバ上で動作する。１つのサーバ上には、複数のプロセスグループが同時に動作することが可能であり、あるプロセスグループの実行プロセスと別のプロセスグループのＰ予備プロセス、Ｓ予備プロセスや異なるプロセスグループのＰ予備プロセス、Ｓ予備プロセスが同一のサーバ上で動作することができる。ネームサービス６ａ、６ｂは、業務処理システムに１つ以上存在し、クライアントプロセス及び実行プロセス、Ｐ予備プロセス、Ｓ予備プロセスは、ネームサービスの位置を予め知っている。
【００１７】
図２はクライアントプロセス、実行プロセス、Ｐ予備プロセス、Ｓ予備プロセスの機能構成を示すブロック図である。
【００１８】
以下に説明する各プロセスの機能は、すでに説明した計算機であるサーバの中に構築されるものであるので、ここで、各サーバのハードウェア構成について説明する。各サーバは、一般によく知られているように、図には示していないが、ＣＰＵ、ＨＤＤ、主記憶装置、キーボード、ディスプレイ等による入出力装置を備えて構成された情報処理装置である。図２により以下に説明する各プロセスの機能は、プログラムとして構成され、ＨＤＤ等の記憶装置に格納されていて、処理動作の開始時に主記憶装置にロードされ、同様にＨＤＤ等の記憶装置に格納されていて主記憶装置にロードされたＯＳの制御の下にＣＰＵにより実行されることにより、それぞれの機能が構築される。
【００１９】
クライアントプロセス２（２ａ、２ｂ）は、図２（ａ）に示すように、他のプロセスとネットワークを介して情報の授受を行う送受信部２１と、送信先プロセス名及び送信先アドレスを管理し、変換を行う送信先管理部２２と、送信したデータの送達の確認、再送の処理を行う送達確認部２３とを備えている。
【００２０】
実行プロセス３（３ａ〜３ｃ）は、図２（ｂ）に示すように、クライアントプロセス２の場合と同様に、送受信部３１と、送信先管理部３２と、送達確認部３３とを備える他、クライアントプロセス２から受信したサービス要求を管理するサービス要求管理部３４と、サービス要求を実行し管理するサービス要求実行部３５と、クラスタサービス７との連携を行うクラスタサービス連携部３６とを備えている。
【００２１】
Ｐ予備プロセス４（４ａ〜４ｃ）は、図２（ｃ）に示すように、クライアントプロセス２の場合と同様に、送受信部４１と、送信先管理部４２と、送達確認部４３とを備える他、実行プロセス３の場合同様に、サービス要求管理部４４と、クラスタサービス連携部４５とを備えている。また、自プロセスが実行プロセスとなったときに、サービス要求を実行し管理するサービス要求実行部４６を備えている。
【００２２】
Ｓ予備プロセス５（５ａ、５ｂ）は、図２（ｄ）に示すように、Ｐ予備プロセス４の場合と同様に、送受信部５１と、送信先管理部５２と、送達確認部５３と、サービス要求管理部５４と、クラスタサービス連携部５５とを備える他、サーバ１（１ｃ〜１ｆ）や実行プロセス３の負荷情報を管理する負荷管理部５６と、負荷情報を取得する負荷監視部５７と、実行プロセス２、Ｐ予備プロセス３と同期するサービスを管理する同期サービス管理部５８と、系切り替え時に同期していないサービスを回復するサービス回復部５９とを備えている。また、自プロセスが実行プロセスとなったときに、サービス要求を実行し管理するサービス要求実行部５０を備えている。
【００２３】
図３Ａ〜図３Ｃはサービス要求送信から送信完了までの各プロセスでの動作を説明するフローチャートであり、次に、これについて説明する。なお、ここでは、ネームサービスの１つを６ｇとし、クライアントプロセスの１つを２ｇとし、実行プロセスの１つを３ｇとし、Ｐ予備プロセスの１つを４ｇとし、Ｓ予備プロセスの１つを５ｇとしている。また、図３Ａ〜図３Ｃに示すフローは一連のものであるので、以下の説明では、図番を示すことなく、説明を続ける。
【００２４】
（１）処理の開始時、クライアントプロセス２ｇは、実行プロセス３ｇにサービス要求電文送信するときに、送信先管理部２２を介して送信先を解決しており、また、送信先管理部２２は、送信先実行プロセス３ｇが属するプロセスグループに対応するマルチキャストアドレスを管理している。クライアントプロセス２ｇは、要求された実行プロセス３ｇが属するプロセスグループに対応するマルチキャストアドレスが保持されているか否かを判定する（ステップＳ２０１）。
【００２５】
（２）ステップＳ２０１の判定で、プロセスグループに対応するマルチキャストアドレスが保持されていなかった場合、クライアントプロセス２ｇは、送受信部２１を介してネームサービス６ｇに問い合わせを行う（ステップＳ２０２）。
【００２６】
（３）ネームサービス６ｇは、ステップＳ２０２でのクライアントプロセス２ｇからの問い合わせに対して、問い合わせのあったプロセスグループのマルチキャストアドレスを含む送信元解決電文をクライアントプロセス２ｇに送信することにより、要求された問い合わせに応答する（ステップＳ６０１）。
【００２７】
（４）クライアントプロセス２ｇは、ネームサービス６ｇから送信元解決電文を受信すると、送信先管理部２２にマルチキャストアドレスを登録して管理する。以降、同一のプロセスグループへの送信時には管理しているマルチキャストアドレスを用いて送信を行うこととする（ステップＳ２０３、Ｓ２０４）。
【００２８】
（５）ステップＳ２０４の処理の後、あるいは、ステップＳ２０１の判定で、プロセスグループに対応するマルチキャストアドレスが保持されていた場合、クライアントプロセス２ｇは、プロセスグループに対応するマルチキャストアドレスを用いてサービス要求電文を送信する。これにより、プロセスグループに属する全てのプロセスに対する要求の送信を１度で行うことが可能となる（ステップＳ２０５）。
【００２９】
（６）実行プロセス３ｇ、Ｐ予備プロセス４ｇ及びＳ予備プロセス５ｇは、それぞれが有する送受信部によりクライアントプロセス２ｇからのサービス要求電文を受信する（ステップＳ３０１、Ｓ４０１、Ｓ５０１）。
【００３０】
（７）その後、実行プロセス３ｇ及びＰ予備プロセス４ｇは、それぞれが有するサービス要求管理部で同一のサービス要求電文を受信済みか否かを判定し、Ｓ予備プロセス５ｇは、受信したサービスが自Ｓ予備プロセス５ｇで管理しているサービスであるか否かを判定し、自Ｓ予備プロセス５ｇで管理しているサービスである場合に、自プロセスのサービス要求管理部で同一のサービス要求電文を受信済みか否かを判定する（ステップＳ３０２、Ｓ４０２、Ｓ５０２、Ｓ５０３）。
【００３１】
（８）ステップＳ３０２、Ｓ４０２、Ｓ５０３の判定で、受信していないサービス要求電文であった場合、実行プロセス３ｇ、Ｐ予備プロセス４ｇ及びＳ予備プロセス５ｇは、それぞれが有するサービス要求管理部にサービス要求電文を登録する（ステップＳ３０３、Ｓ４０３、Ｓ５０４）。
【００３２】
（９）実行プロセス３ｇ、Ｐ予備プロセス４ｇ及びＳ予備プロセス５ｇは、それぞれ、ステップＳ３０３、Ｓ４０３、Ｓ５０４の処理によるサービス要求電文の登録が成功したか否かを判定する（ステップＳ３０４、Ｓ４０４、Ｓ５０５）。
【００３３】
（10）ステップＳ３０４、Ｓ４０４、Ｓ５０５の判定で、サービス要求電文の登録が成功していた場合、あるいは、ステップＳ３０２、Ｓ４０２、Ｓ５０２の判定で、同一のサービス要求電文を受信済みであった場合、実行プロセス３ｇ、Ｐ予備プロセス４ｇ及びＳ予備プロセス５ｇは、それぞれが有する送受信部を介してクライアントプロセス２ｇに対してサービス受信成功応答を送信する。また、Ｓ予備プロセス５ｇは、ステップＳ５０２の判定で、受信したサービスが自Ｓ予備プロセス５ｇで管理しているサービスでなかった場合にも、サービス受信成功応答を送信する（ステップＳ３０５、Ｓ４０５、Ｓ５０６）。
【００３４】
（11）ステップＳ３０４、Ｓ４０４、Ｓ５０５の判定で、サービス要求電文の登録が失敗した場合、実行プロセス３ｇ、Ｐ予備プロセス４ｇ及びＳ予備プロセス５ｇは、それぞれが有する送受信部を介してクライアントプロセス２ｇに対してサービス要求失敗応答を送信する（ステップＳ３０６、Ｓ４０６、Ｓ５０７）。
【００３５】
（12）クライアントプロセス２ｇは、サービス要求送信後、送達確認部２３でサービス受信成功応答及びサービス受信失敗応答を待ち、送達確認部２３は、一定時間内に全ての送信先からサービス受信成功応答の受信に成功したか否かを判定し、成功した場合、サービス要求成功と判断し、サービス受信失敗応答を受信した場合、あるいは、受信がタイムアウトした場合、ステップＳ２０５からの処理に戻って、サービス要求を再送する（ステップＳ２０６、Ｓ２０７）。
【００３６】
図９はクライアントプロセスから実行プロセス、Ｐ予備プロセス及びＳ予備プロセスへ送信するサービス要求電文の構造を説明する図である。このサービス要求電文は、前述で説明したステップＳ２０５の処理で送信されるものである。
【００３７】
サービス要求電文は、図９に示すように、電文種別Ｄ００１、送信元であるクライアントプロセスのＩＰアドレスＤ００２、送信元であるクライアントプロセスのポート番号Ｄ００３、サービス要求電文ＩＤ  Ｄ００４、サービス要求電文のリトライ回数Ｄ００５、サービス要求種別Ｄ００６、サービス要求本体（本文）Ｄ００７により構成される。電文種別Ｄ００１は、このメッセージがサービス要求電文であることを示す情報である。送信元のＩＰアドレスＤ００２と送信元のポート番号Ｄ００３は、受信側のプロセスがクライアントプロセスを識別するための情報であり、また、受信側のプロセスからクライアントプロセスへ応答を送信するための宛先情報でもある。サービス要求電文ＩＤ  Ｄ００４は、クライアントプロセス側で送信するサービス要求毎に一意になるように設定されるＩＤであり、受信側のプロセスで当該サービス要求電文が受信済みであるか新規電文であるかを判定するために使用される。サービス要求電文のリトライ回数Ｄ００５は、クライアントが同一のサービス要求電文のリトライを行う度にインクリメントされる。サービス要求種別Ｄ００６は、実行プロセスがサービス要求を実行するために使用する情報であり、サービス実行結果の応答可否や統計情報の取得有無等を指定する。このサービス要求種別の内容は、クライアントプロセスと受信側のプロセスとの間のインタフェースに依存する。サービス要求本体（本文）Ｄ００７は、クライアントプロセス上のユーザプログラムでユーザが設定したメッセージ本文であり、実行プロセスで動作するサービスに渡される情報である。
【００３８】
図１０はサービス要求電文を受信した実行プロセス、Ｐ予備プロセス及びＳ予備プロセスがクライアントプロセスに対して送信するサービス要求受信成功応答電文、サービス要求受信失敗応答電文の構造を説明する図である。このサービス要求受信成功、失敗の応答電文は、前述で説明したステップＳ３０５、Ｓ３０６、Ｓ４０５、Ｓ４０６、Ｓ５０６、Ｓ５０７の処理で送信されるものである。
【００３９】
サービス受信成功応答、サービス受信失敗応答の電文は、図１０に示すように、電文種別Ｄ０１１、送信元のＩＰアドレスＤ０１２、送信元のポート番号Ｄ０１３、サービス要求電文ＩＤ  Ｄ０１４、サービス要求電文のリトライ回数Ｄ０１５、サービス実行結果Ｄ０１６により構成される。電文種別Ｄ０１１は、この電文がサービス要求電文に対する応答であることを示す情報である。送信元のＩＰアドレスＤ０１２と送信元のポート番号Ｄ０１３とは、クライアントプロセスが送信元のプロセスを識別するために使用される。サービス要求電文ＩＤ  Ｄ０１４とサービス要求電文のリトライ回数Ｄ０１５とは、送信元がサービス要求の応答を送信するとき、該当するサービス要求電文のサービス要求電文ＩＤとリトライ回数とを複写したものである。クライアントプロセスは、この情報から該当するサービス要求電文を判定する。サービス実行結果Ｄ０１６には、サービス要求受信成功であるかサービス要求受信失敗であるかの情報が設定される。
【００４０】
図１１はクライアントプロセス、実行プロセス、Ｐ予備プロセス及びＳ予備プロセスがプロセスグループ内の各プロセスに対して電文を送信するために使用するマルチキャストアドレスを取得するために、ネームサービスから受信する送信先解決電文の構造を説明する図である。この送信先解決電文は、前述で説明したフローの例では、ステップＳ６０１の処理で、ネームサービス６ｇからクライアントプロセス２ｇに送信されるものである。
【００４１】
送信先解決電文は、電文種別Ｄ０２１、プロセスグループ名Ｄ０２２、マルチキャストアドレスＤ０２３、実行プロセス数Ｄ０２４、予備プロセス数Ｄ０２５、実行プロセス毎の負荷状態Ｄ０２６、実行プロセスと予備プロセスとのＩＰアドレスＤ０２８、ポート番号Ｄ０２９により構成される。電文種別Ｄ０２１は、この電文が送信先解決電文であることを示す情報である。プロセスグループ名Ｄ０２２には、要求したプロセスグループ名が設定される。マルチキャストアドレスＤ０２３には、要求したプロセスグループのプロセスが参加しているプロセスグループのアドレスが設定される。要求元プロセスは、このアドレスを使用してマルチキャスト送信を行う。実行プロセス数Ｄ０２４には、要求したプロセスグループ内の実行プロセスの数が設定される。予備プロセス数Ｄ０２５には、要求したプロセスグループ内の予備プロセスの数が設定される。実行プロセスの負荷状態Ｄ０２６には、実行プロセスの現在の負荷状態が設定される。クライアントプロセスで負荷分散を行う場合、この情報を用いて要求する実行プロセスを決定する。実行プロセスの負荷状態は、実行プロセス数だけＤ０２６の部分をＤ０２７以降の部分に繰り返して設定される。プロセスのＩＰアドレスＤ０２８とポート番号Ｄ０２９とには、要求したプロセスグループ内のプロセスのＩＰアドレスとポート番号とが設定される。クライアントプロセスは、この情報を送信先プロセスを識別するときに使用する。プロセスのＩＰアドレスとポート番号とは、実行プロセスと予備プロセスとの数だけ、Ｄ０２８、Ｄ０２９の部分をＤ０３０以降の部分に繰り返して設定される。
【００４２】
図４Ａ、図４Ｂは図３Ａ〜図３Ｃの処理でサービス要求の送信が完了した後に、各プロセスで行われるサービス実行からサービス実行完了までの動作を説明するフローチャートであり、次に、これについて説明する。なお、図４Ａ、図４Ｂに示すフローは一連のものであるので、以下の説明では、図番を示すことなく、説明を続ける。
【００４３】
（１）実行プロセス３ｇのサービス要求管理部３４は、管理しているサービス要求を既定の順序制御を用いてサービスの引き出しを制御する。そして、サービス要求実行部３５は、サービス要求管理部３４からサービス要求を受け取り、受け取ったサービス要求の実行を行う（ステップＳ３１１、Ｓ３１２）。
【００４４】
（２）サービス要求管理部３４は、サービス要求実行部３５でのサービス実行が完了すると、送信先管理部３２からプロセスグループのマルチキャストアドレスを取得し、予備プロセス４ｇ及び５ｇに対して、取得したマルチキャストアドレスを使用してサービス完了通知を送信する。ここでのマルチキャストアドレスを取得は、図３Ａで説明したステップＳ２０１〜Ｓ２０４での処理と同様にして行われる（Ｓ３１３、Ｓ３１４）。
【００４５】
（３）Ｐ予備プロセス４ｇ及びＳ予備プロセス５ｇは、それらのプロセスが有する送受信部が、実行プロセス３ｇからのサービス完了通知を受信すると、自プロセスが有するサービス要求管理部に対して該当するサービス要求の破棄を要求して、該当するサービス要求を破棄させる（ステップＳ４１１、Ｓ４１２、Ｓ５１１、Ｓ５１２）。
【００４６】
（４）Ｐ予備プロセス４ｇ及びＳ予備プロセス５ｇでサービス要求の破棄が完了すると、実行プロセス３ｇのサービス要求管理部３４は、自プロセスのサービス要求の破棄を行うと共に、クライアントプロセス２ｇへのサービス結果応答の送信を行い、ここでのサービス要求の実行が終了する（ステップＳ３１５）。
【００４７】
（５）クライアントプロセス２ｇは、実行プロセス３ｇのサービス要求管理部３４から送信されてきたサービス結果応答を受信する（ステップＳ２１１）。
【００４８】
図１２は実行プロセスがサービス実行完了時に、Ｐ予備プロセス４ｇ及びＳ予備プロセス５ｇに送信するサービス完了通知の電文の構造を説明する図である。このサービス完了通知の電文は、前述で説明したステップＳ３１４の処理で送信されるものである。
【００４９】
サービス完了通知の電文は、電文種別Ｄ０３１、送信元のＩＰアドレスＤ０３２、送信元のポート番号Ｄ０３３、クライアントプロセスのＩＰアドレスＤ０３４、クライアントプロセスのポート番号Ｄ０３５、サービス要求電文ＩＤ  Ｄ０３６により構成される。電文種別Ｄ０３１は、この電文がサービス完了通知電文であることを示す情報である。送信元のＩＰアドレスＤ０３２とポート番号Ｄ０３３とは、受信側であるＰ予備プロセス及びＳ予備プロセスが送信元である実行プロセスを識別するために使用される。クライアントプロセスのＩＰアドレスＤ０３４、ポート番号Ｄ０３５及びサービス要求電文ＩＤ  Ｄ０３６とは、実行が完了したサービス要求電文を識別するために使用される。
【００５０】
図１３は実行プロセスがサービス実行完了時に、クライアントプロセスにサービス結果を通知するサービス結果応答の電文の構造を説明する図である。このサービス結果応答の電文は、前述で説明したステップＳ３１５の処理で実行プロセスからクライアントプロセスに送信されるものである。
【００５１】
サービス結果応答の電文は、電文種別Ｄ０４１、送信元のＩＰアドレスＤ０４２、送信元のポート番号Ｄ０４３、クライアントプロセスのＩＰアドレスＤ０４４、クライアントプロセスのポート番号Ｄ０４５、サービス要求電文ＩＤ  Ｄ０４６、サービス実行結果Ｄ０４７、応答電文本体Ｄ０４８により構成される。電文種別Ｄ０４１は、この電文がサービス結果応答電文であることを示す情報である。送信元のＩＰアドレスＤ０４２とポート番号Ｄ０４３とは、クライアントプロセスが送信元である実行プロセスを識別するために使用される。クライアントプロセスのＩＰアドレスＤ０４４、ポート番号Ｄ０４５及びサービス要求電文ＩＤ  Ｄ０４６は、実行が完了したサービス要求電文を識別するために使用される。サービス実行結果Ｄ０４７は、クライアントプロセスがサービスの実行結果を知るために使用する。応答電文本体Ｄ０４８は、実行プロセスのサービスがクライアント上のユーザプログラムに応答するデータの本体である。
【００５２】
図３Ａ〜図３Ｃ、図４Ａ、図４Ｂで説明したクライアントプロセスによるサービス要求電文の再送処理と実行プロセスのサービス完了通知によって実行プロセスとＰ予備プロセス、Ｓ予備プロセスとの間のサービス同期処理を実現することができる。
【００５３】
前述で説明したクライアントプロセス２ｇからサービス要求電文を受信する処理において、受信するプロセスがＳ予備プロセス５ｇである場合、受信したサービス要求電文が現在管理しているサービスに対するものかどうかの判定を行って（ステップＳ５０３）、管理外のサービスである場合にはサービス要求電文を破棄し、クライアントプロセス２ｇへサービス要求成功応答を送信している（ステップＳ５０６）。
【００５４】
このような処理により、Ｓ予備プロセス５ｇは、以降のサービス要求管理処理を省略することができ、計算機のメモリ資源、ＣＰＵ資源の節約を行い、業務処理システムの高速な系切り替えと負荷の軽減との両方を実現することができる。
【００５５】
図５はサービスの重要度と計算機の動作状況とに応じて同期したデータ量の調整処理を行う動作を説明するフローチャートであり、次に、これについて説明する。この処理は、Ｓ予備プロセスが実行するものであり、ここでの計算機の動作状況とは、Ｓ予備プロセスが動作している計算機であるサーバの動作状況である。なお、ここでの処理を実行するＳ予備プロセスをＳ予備プロセス５ｉとする。そして、ここでの処理において、Ｓ予備プロセス５ｉは、負荷が低い状態では実行プロセスと同期する要求データの量を増加させ、負荷が高い状態では同期する要求データの量を減らすように動作する。
【００５６】
（１）Ｓ予備プロセス５ｉの負荷監視部５７は、一定間隔で自身が動作する計算機の負荷やその計算機上で動作する他プロセスグループの実行プロセスの負荷を監視しており、現在の計算機や実行サーバの負荷を取得して記憶する（ステップＳ５２１）
（２）負荷監視部５７は、現在の負荷のレベルが前回取得時の負荷のレベルから上昇したか否かを判定すると共に、負荷が設定された閾値以上であるか否かを判定し、判定結果を負荷管理部５６に通知する（ステップＳ５２２）。
【００５７】
（３）負荷管理部５６は、負荷監視部５７から負荷のレベルが上昇し、設定された閾値以上となったことの通知を受けた場合、負荷レベルを上昇させ、また、負荷のレベルが降下し、設定された閾値以下となったことの通知を受けた場合、負荷レベルを下降させる。このとき、負荷管理部５６は、負荷レベルの連続した上昇回数及び連続した降下回数をカウントする（ステップＳ５２３、Ｓ５２４）。
【００５８】
（４）ステップＳ５２３、Ｓ５２４での処理の後、負荷管理部５６は、負荷レベルが設定された最低負荷レベルを超過したか否かを判定し、負荷レベルが設定された最低負荷レベルを超過していた場合、さらに、負荷レベルの連続上昇回数が停止閾値を超過したか否かを確認し、負荷レベルの連続上昇回数が停止閾値を超過していなかった場合、ここでの負荷管理の処理を終了する（ステップＳ５２５、５２６）。
【００５９】
（５）ステップＳ５２６の判定で、負荷レベルが最低負荷レベルを超え、さらに、一定の負荷レベルの上昇回数が増加し停止しきい値を超過していた場合、その旨を同期サービス管理部５８に通知する（ステップＳ５２７）。
【００６０】
（６）同期サービス管理部５８は、ステップＳ５２７での通知を受けて、管理しているサービスの中から重要度が低いサービスで、停止していないサービスを選択し、選択したサービスのサービス要求の管理を停止する。但し、最も重要度の高いサービスの処理は停止させずにここでの処理を終了する（ステップＳ５２８、Ｓ５２９）。
【００６１】
前述において、サービス要求の管理が停止すると、保持しているサービス要求の破棄を行い、以降、サービス要求管理部に対してサービス要求の登録、管理を行わなくなる。これによって、計算機のメモリ資源とＣＰＵ資源を節約し、負荷が上昇した計算機及び実行プロセスの負荷を軽減させることができる。
【００６２】
（７）ステップＳ５２５の判定で、負荷レベルが設定された最低負荷レベルを超過しておらず、システムの負荷が改善していた場合、負荷管理部５６は、同期サービス管理部５８に、その旨の通知を行い、停止していたサービスの管理を再開する（ステップＳ５３０、Ｓ５３１）。
【００６３】
前述の処理において、同期サービス管理部５８は、サービスの管理数に変更があった場合、サービス監視数をクラスタサービスに通知する。クラスタサービスは、実行プロセスに障害が発生した場合、Ｓ予備プロセスのサービス管理数を考慮して次の実行プロセスを決定する。
【００６４】
図６は実行プロセスに障害が発生したときに、クラスタサービスがどの予備プロセスを次の実行プロセスとして選択するかの規則の例を説明する図である。
【００６５】
クラスタサービスは、実行プロセスに障害が発生したことを検知したとき、その実行プロセスが属しているプロセスグループ内に、Ｐ予備プロセスが２プロセス以上存在する場合に、任意のＰ予備プロセスを次の実行プロセスに選択し、また、Ｐ予備プロセスが１プロセスしか存在しない場合には、Ｓ予備プロセスのうち、管理しているサービスが最も多いＳ予備プロセスを次の実行プロセスに選択する。
【００６６】
図７はＰ予備プロセスが実行プロセスに選択されたときの系切り替え処理の処理の概要を説明するフローチャートである。この処理は、実行プロセスが属しているプロセスグループ内に、Ｐ予備プロセスが２プロセス以上存在する場合に実行される処理である。
【００６７】
（１）実行プロセス３ｊに障害が発生し、クラスタサービス６ｊが実行プロセス３ｊの障害を検知すると、クラスタサービス６ｊは、任意のＰ予備プロセス４ｊを選択し、そのＰ予備プロセス４ｊに実行プロセスへの遷移を通知する（ステップＳ３４１、Ｓ６４１、Ｓ６４２）。
【００６８】
（２）実行プロセスへの遷移の通知を受信したＰ予備プロセス４ｊは、自身を実行プロセスに状態を遷移させ、Ｐ予備プロセス４ｊのサービス要求管理部４４が管理しているサービス要求を実行することにより業務を開始する（ステップＳ４４１、Ｓ４４２）。
【００６９】
図８Ａ〜図８ＣはＳ予備プロセスが実行プロセスに選択されたときの系切り替え処理を説明するフローチャートであり、次に、これについて説明する。この処理は、実行プロセスが属しているプロセスグループ内に、Ｐ予備プロセスが１プロセスしか存在しない場合に実行される処理である。また、この処理では、Ｓ予備プロセスが、プロセスグループ内に少なくとも２つ存在する必要がある。
【００７０】
本発明の実施形態は、次の実行プロセスとしてＳ予備プロセスが選択された場合、全体のサービス要求を回復する前に、Ｓ予備プロセスが管理しているサービスのみで業務を再開し、業務の再開とは非同期に残りのサービスの回復を行う。これにより、重要な業務を停止させることはなく、業務処理システムの稼働率を向上させることができる。この場合、業務処理システムの部分開始とサービス回復処理とが非同期に動作し、回復処理完了後に業務処理システムが全面開始されることになる。なお、図８Ａ〜図８Ｃで説明する処理では、実行プロセスの１つを３ｋとし、Ｐ予備プロセスの１つを４ｋとし、２つのＳ予備プロセスのそれぞれを５ｋ、５ｍとし、クラスタサービスの１つを６ｋとしている。また、図８Ａ〜図８Ｃに示すフローは一連のものであるので、以下の説明では、図番を示すことなく、説明を続ける。
【００７１】
（１）いま、実行プロセス３ｋに障害が発生すると、クラスタサービス６ｋは、実行プロセス３ｋの障害を検知し、Ｓ予備プロセスのうち、管理しているサービス数が最も多いＳ予備プロセス５ｋを選択し、Ｓ予備プロセス５ｋに実行プロセスへの遷移を通知する（ステップＳ３５１、Ｓ６５１、Ｓ６５２）。
【００７２】
（２）実行プロセスへの遷移の通知を受信したＳ予備プロセス５ｋは、自プロセスを実行プロセスに状態を遷移させ、サービス要求実行部５０が、サービス要求管理部５４が管理しているサービス要求を実行することにより業務を開始する。このとき、Ｓ予備プロセス５ｋのサービス要求管理部５４は、障害が発生する前の実行プロセス３ｋが保持していたサービス要求の一部のみを管理しているので、Ｓ予備プロセス５ｋは、自プロセスが管理していた業務だけについて、業務を部分開始する（ステップＳ５５１、Ｓ５５２）。
【００７３】
前述において、部分開始した実行プロセスは、自身が管理しているサービスのみを処理することを除いて図４Ａ〜図４Ｃに示して説明したフローの場合と同様の方法で予備プロセスとの同期処理を実行する。
【００７４】
（３）次に、クラスタサービス６ｋは、ステップＳ６５２の処理で、Ｓ予備プロセス５ｋに実行プロセスへの遷移を通知すると同時に、残りのＳ予備プロセスの１つであるＳ予備プロセス５ｍにＰ予備プロセスへの遷移を通知する（ステップＳ３５３）。
【００７５】
（４）Ｐ予備プロセスへの遷移の通知を受信したＳ予備プロセス５ｍは、送信先管理部５２を介してプロセスグループのマルチキャストアドレスを取得し、取得したマルチキャストアドレスを用い、送受信部５１を介してプロセスグループ内のＰ予備プロセスに対してＰ予備プロセス存在確認電文を送信する（ステップＳ５６０〜Ｓ５６２）。
【００７６】
（５）Ｐ予備プロセス存在確認電文を受信したＰ予備プロセス４ｋは、送信元のＳ予備プロセス５ｍに対してＰ予備プロセス存在確認応答電文を送信する（ステップＳ４５１、Ｓ４５２）。
【００７７】
（６）Ｐ予備プロセス４ｋからのＰ予備プロセス存在確認応答電文により、Ｐ予備プロセス４ｋの存在を確認したＳ予備プロセス５ｍは、Ｐ予備プロセス４ｋに対して自身が管理しているサービス一覧を通知するためにサービス同期依頼電文を送信する（ステップＳ５６３、Ｓ５６４）。
【００７８】
（７）Ｓ予備プロセス５ｍからサービス同期依頼電文を受信したＰ予備プロセス４ｋは、Ｓ予備プロセス５ｍが管理しているサービス一覧を取得し、受信したサービス一覧と自身が管理しているサービス一覧を比較し、Ｓ予備プロセスが管理していないサービスのサービス要求をサービス同期依頼応答電文としてＳ予備プロセス５ｍに送信する（ステップＳ４５３〜Ｓ４５５）。
【００７９】
（８）Ｐ予備プロセス４ｋからサービス同期依頼応答電文を受信したＳ予備プロセス５ｍは、受信したサービス要求をサービス要求管理部５４に登録し、このサービスの登録によってサービス要求の回復が完了し、Ｐ予備プロセスへの遷移を完了する（ステップＳ５６５〜Ｓ５６７）。
【００８０】
ここまでの処理によって、サービスの回復処理が完了する。
【００８１】
（９）サービスの同期処理が完了し、Ｐ予備プロセスへの遷移を完了したＳ予備プロセス５ｍは、送信先管理部５２を介してプロセスグループのマルチキャストアドレスを取得し、送受信部５１を介して実行プロセスに遷移しているＳ予備プロセス５ｋに対して同期合わせ完了通知電文（サービス同期処理完了通知電文）を取得したマルチキャストアドレスを用いて送信する（ステップＳ５６８、Ｓ５６９）。
【００８２】
（10）同期合わせ完了通知電文によるサービス回復完了通知を受信した実行プロセスとなっているＰ予備プロセス５ｋは、クラスタサービス６ｋへ実行プロセスとしての処理停止を通知し、その後、Ｓ予備プロセスへと遷移する（ステップＳ５５３〜Ｓ５５５）。
【００８３】
（11）実行プロセスとなっているＰ予備プロセス５ｋから実行プロセスの処理停止の通知を受信したクラスタサービス６ｋは、Ｐ予備プロセス４ｋに対して実行プロセスへの遷移を通知する（ステップＳ３５４、Ｓ３５５）。
【００８４】
（12）実行プロセスへの遷移の通知を受信したＰ予備プロセス４ｋは、実行プロセスへ遷移し、サービス要求管理部４４で管理しているサービスをサービス要求実行部４６で実行することにより業務を開始し、以後、実行プロセスとして業務を続ける（ステップＳ４５６、Ｓ４５７）。
【００８５】
前述までの処理によって、業務の完全回復が完了する。本発明の実施形態では、以上の処理により、非同期のデータ回復処理による業務処理システムの稼働率の向上と信頼性の向上とを実現することができる。
【００８６】
図１４はＳ予備プロセス５ｍがＰ予備プロセスの存在を確認するために送信するＰ予備プロセス存在確認電文の構造を説明する図である。このＰ予備プロセス存在確認電文は、図８Ｂに示したフローのステップＳ５６２の処理で送信されるものである。
【００８７】
Ｐ予備プロセス存在確認電文は、電文種別Ｄ０５１、送信元のＩＰアドレスＤ０５２、送信元のポート番号Ｄ０５３により構成される。電文種別Ｄ０５１は、この電文がＰ予備プロセス存在確認電文であることを示す情報である。送信元のＩＰアドレスＤ０５２とポート番号Ｄ０５３とは、Ｐ予備サーバ存在確認電文を送信したサーバを識別する情報であり、存在確認応答を送信するための送信先情報として使用される。
【００８８】
図１５はＰ予備プロセス存在確認電文を受信したＰ予備プロセスが送信元に応答するＰ予備プロセス存在確認応答電文の構造を説明する図である。このＰ予備プロセス存在確認応答電文は、図８Ｂに示したフローのステップＳ４５２の処理で送信されるものである。
【００８９】
Ｐ予備プロセス存在確認応答電文は、電文種別Ｄ０６１、送信元ＩＰアドレスＤ０６２、送信元のポート番号Ｄ０６３により構成される。電文種別Ｄ０６１は、この電文がＰ予備サーバ存在確認応答電文であることを示す情報である。送信元のＩＰアドレスＤ０６２とポート番号Ｄ０６３とは、Ｐ予備プロセス存在確認応答電文を送信したＰ予備プロセスを識別する情報であり、サービス要求の同期依頼電文の送信先情報として使用される。
【００９０】
図１６はＰ予備プロセスの存在を確認したＳ予備プロセス５ｍがサービス要求の回復のために送信するサービス同期依頼電文の構造を説明する図である。このサービス同期依頼電文は、図８Ｂに示したフローのステップＳ５６４の処理で送信されるものである。
【００９１】
Ｓ予備プロセス５ｍからＰ予備プロセス４ｋへのサービス同期依頼電文は、電文種別Ｄ０７１、Ｐ送信元のＩＰアドレスＤ０７２、送信元のポート番号Ｄ０７３、管理中サービス名のリストＤ０７４、Ｄ０７５により構成される。電文種別Ｄ０７１は、この電文がサービス同期依頼電文であることを示す情報である。送信元のＩＰアドレスＤ０７２とポート番号Ｄ０７３とは、送信元プロセスを識別するための情報であり、サービス同期依頼応答の送信先として使用される。管理中サービス名のリストＤ０７４、Ｄ０７５は、送信元プロセスが管理しているサービス名であり、受信側のＰ予備プロセスが、送信元であるＳ予備プロセスに不足しているサービス要求を判断するために使用される。
【００９２】
図１７はサービス同期依頼電文の受信側であるＰ予備プロセスが送信するサービス同期依頼応答電文の構造を説明する図である。このサービス同期依頼応答電文は、図８Ｂに示したフローのステップＳ４５５の処理で送信されるものである。
【００９３】
サービス同期依頼応答電文は、電文種別Ｄ０８１、送信元のＩＰアドレスＤ０８２、送信元のポート番号Ｄ０８３、回復サービスＤ０８４及びそのリストＤ０８５により構成される。さらに、回復サービスは、サービス名Ｄ０８６とそのサービスに対応するサービス要求Ｄ０８７とそのリストＤ０８８とにより構成される。電文種別Ｄ８１は、この電文がサービス同期依頼応答であることを示す情報である。送信元プロセスのＩＰアドレスＤ０８２と送信元プロセスのポート番号Ｄ０８３とは、送信元であるＰ予備プロセスを識別するために使用される。回復サービスＤ０８４、そのリストＤ０８５は、Ｐ予備プロセスが保持しているサービス要求電文のうち、要求元であるＳ予備プロセスが保持していないサービス要求をサービス名毎にまとめたものである。
【００９４】
図１８は回復処理が完了したＰ予備プロセスに遷移しているＳ予備プロセス５ｍから部分開始状態で業務を継続している実行プロセスに遷移しているＳ予備プロセス５ｋへ送信する同期合わせ完了通知電文の構造を説明する図である。この同期合わせ完了通知電文は、図８Ｃに示したフローのステップＳ５６９の処理で送信されるものである。
【００９５】
同期合わせ完了通知電文は、電文種別Ｄ０９１、送信元のＩＰアドレスＤ０９２、送信元のポート番号Ｄ０９３により構成される。電文種別Ｄ０９１は、この電文が同期合わせ完了通知であることを示す情報である。送信元のＩＰアドレスＤ０９２とポート番号Ｄ０９３とは、送信元であるＰ予備プロセスに遷移しているＳ予備プロセス５ｍを識別するための情報である。
【００９６】
前述した本発明の実施形態での各処理は、プログラムにより構成し、本発明が備えるサーバのＣＰＵに実行させることができ、また、それらのプログラムは、ＦＤ、ＣＤＲＯＭ、ＤＶＤ等の記録媒体に格納して提供することができ、また、ネットワークを介してディジタル情報により提供することができる。
【００９７】
前述した本発明の実施形態によれば、クライアントプロセスから実行プロセス、Ｐ及びＳ予備プロセスへのマルチキャスト通信を行って、その送達を確認すると共に、実行済み要求を破棄する機能を備えることにより、予備プロセスを多数用意した場合に発生するオーバーヘッドを軽減することができる。
【００９８】
また、本発明の実施形態によれば、実行プロセスが提供するサービスに重要度を与え、計算機の動作状況を取得して、サービスの重要度と計算機の動作状況とから同期させるデータ量を決定する機能を備えることにより、実行プロセスと予備プロセスとの間の同期処理が異なる性能の計算機を混在させて実行される場合にも、システムへの影響を軽減してシステムを安定に稼動させることができる。
【００９９】
さらに、本発明の実施形態によれば、系切り替え時に同期が取れているサービスのみで縮退運転するようにし、他の予備プロセスと非同期にサービスの回復を行うこととしているので、実行プロセスと予備プロセスとのデータ量が不一致な状態で系切り替えが行われた場合にも、系切り替えの失敗やデータの損失を防止し、システムの稼働率の向上を図ることができる。
【図面の簡単な説明】
【０１００】
【図１】本発明の一実施形態による業務処理システムの構成を示すブロックである。
【図２】クライアントプロセス、実行プロセス、Ｐ予備プロセス、Ｓ予備プロセスの機能構成を示すブロック図である。
【図３Ａ】サービス要求送信から送信完了までの各プロセスでの動作を説明するフローチャート（その１）である。
【図３Ｂ】サービス要求送信から送信完了までの各プロセスでの動作を説明するフローチャート（その２）である。
【図３Ｃ】サービス要求送信から送信完了までの各プロセスでの動作を説明するフローチャート（その３）である。
【図４Ａ】サービス要求の送信が完了した後に、各プロセスで行われるサービス実行からサービス実行完了までの動作を説明するフローチャート（その１）である。
【図４Ｂ】サービス要求の送信が完了した後に、各プロセスで行われるサービス実行からサービス実行完了までの動作を説明するフローチャート（その２）である。
【図５】サービスの重要度と計算機の動作状況とに応じて同期したデータ量の調整処理を行う動作を説明するフローチャートである。
【図６】実行プロセスに障害が発生したときに、クラスタサービスがどの予備プロセスを次の実行プロセスとして選択するかの規則の例を説明する図である。
【図７】Ｐ予備プロセスが実行プロセスに選択されたときの系切り替え処理の処理の概要を説明するフローチャートである。
【図８Ａ】Ｓ予備プロセスが実行プロセスに選択されたときの系切り替え処理を説明するフローチャート（その１）である。
【図８Ｂ】Ｓ予備プロセスが実行プロセスに選択されたときの系切り替え処理を説明するフローチャート（その２）である。
【図８Ｃ】Ｓ予備プロセスが実行プロセスに選択されたときの系切り替え処理を説明するフローチャート（その３）である。
【図９】クライアントプロセスから各プロセスへ送信するサービス要求電文の構造を説明する図である。
【図１０】サービス要求電文を受信した各プロセスがクライアントプロセスに対して送信するサービス要求受信成功応答電文、サービス要求受信失敗応答電文の構造を説明する図である。
【図１１】各プロセスがプロセスグループ内の各プロセスに対して電文を送信するために使用するマルチキャストアドレスを取得するために、ネームサービスから受信する送信先解決電文の構造を説明する図である。
【図１２】実行プロセスがサービス実行完了時に、Ｐ予備プロセス及びＳ予備プロセスに送信するサービス完了通知の電文の構造を説明する図である。
【図１３】実行プロセスがサービス実行完了時に、クライアントプロセスにサービス結果を通知するサービス結果応答の電文の構造を説明する図である。
【図１４】Ｓ予備プロセスがＰ予備プロセスの存在を確認するために送信するＰ予備プロセス存在確認電文の構造を説明する図である。
【図１５】Ｐ予備プロセス存在確認電文を受信したＰ予備プロセスが送信元に応答するＰ予備プロセス存在確認応答電文の構造を説明する図である。
【図１６】Ｐ予備プロセスの存在を確認したＳ予備プロセスサービス要求の回復のために送信するサービス同期依頼電文の構造を説明する図である。
【図１７】サービス同期依頼電文の受信側であるＰ予備プロセスが送信するサービス同期依頼応答電文の構造を説明する図である。
【図１８】回復処理が完了したＰ予備プロセスに遷移しているＳ予備プロセスから部分開始状態で業務を継続している実行プロセスに遷移しているＳ予備プロセスへ送信する同期合わせ完了通知電文の構造を説明する図である。
【符号の説明】
【０１０１】
１ａ〜１ｆ  サーバ（計算機）
２、２ａ、２ｂ  クライアントプロセス
３、３ａ〜３ｃ  実行プロセス
４、４ａ〜４ｃ  Ｐ予備プロセス
５、５ａ、５ｂ  Ｓ予備プロセス
６ａ、６ｂ  ネームサービス
７ａ〜７ｄ  クラスタサービス
８ａ、８ｂ  プロセスグループ
２１、３１、４１、５１  送受信部
２２、３２、４２、５２  送信先管理部
２３、３３、４３、５３  送達確認部
３４、４４、５４  サービス要求管理部
３５、４６、５０  サービス要求実行部
３６、４５、５５  クラスタサービス連携部
５６  負荷管理部
５７  負荷監視部
５８  同期サービス管理部
５９  同期サービス回復部
【図１】
2009211536.tif 000003
【図２】
2009211536.tif 000004
【図３Ａ】
2009211536.tif 000005
【図３Ｂ】
2009211536.tif 000006
【図３Ｃ】
2009211536.tif 000007
【図４Ａ】
2009211536.tif 000008
【図４Ｂ】
2009211536.tif 000009
【図５】
2009211536.tif 000010
【図６】
2009211536.tif 000011
【図７】
2009211536.tif 000012
【図８Ａ】
2009211536.tif 000013
【図８Ｂ】
2009211536.tif 000014
【図８Ｃ】
2009211536.tif 000015
【図９】
2009211536.tif 000016
【図１０】
2009211536.tif 000017
【図１１】
2009211536.tif 000018
【図１２】
2009211536.tif 000019
【図１３】
2009211536.tif 000020
【図１４】
2009211536.tif 000021
【図１５】
2009211536.tif 000022
【図１６】
2009211536.tif 000023
【図１７】
2009211536.tif 000024
【図１８】
2009211536.tif 000025