(57)【要約】【課題】サーバの障害に対処するための冗長化の支援を行うこと。【解決手段】一実施形態によれば、クライアント装置によって収集された、第１のサーバ装置の状態と第１のサーバ装置の障害時に稼働する１以上の待機系サーバ装置の状態とを含む、状態情報を、第２のサーバ装置が、クライアント装置から受信し、状態情報が所定の第１の状態を表している場合、第２のサーバ装置が、第２のサーバ装置を第１のサーバ装置及び／又は１以上の待機系サーバ装置の障害時のためのサーバ装置として動作させる、処理をコンピュータに実行させるプログラムが提供される。【選択図】図１１
2013161252.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置によって収集された、第１のサーバ装置の状態と前記第１のサーバ装置の障害時に稼働する１以上の待機系サーバ装置の状態とを含む、状態情報を、第２のサーバ装置が、前記クライアント装置から受信し、
前記状態情報が所定の第１の状態を表している場合、前記第２のサーバ装置が、前記第２のサーバ装置を前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作させる、
処理をコンピュータに実行させるプログラム。
【請求項２】
前記所定の第１の状態は、前記第１のサーバ装置及び前記１以上の待機系サーバ装置のうち稼働することができる装置の数が1以下の状態である、請求項１記載のプログラム。
【請求項３】
前記動作させる処理は、
前記第２のサーバ装置が、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作している場合であって、前記状態情報が所定の第２の状態を表している場合、前記第２のサーバ装置による、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置としての動作を終了させる、
処理を含む請求項１又は２記載のプログラム。
【請求項４】
前記所定の第２の状態は、前記第１のサーバ装置及び前記１以上の待機系サーバ装置のうち稼働することができる装置の数が２以上の状態である、請求項１ないし３のうちいずれか１項記載のプログラム。
【請求項５】
前記状態情報は、前記第１のサーバ装置が前記クライアント装置に提供する１以上の業務の各々に対応して存在する、請求項１ないし４のうちいずれか１項記載のプログラム。
【請求項６】
前記第２のサーバ装置が複数存在する場合、予め定められた選択基準に従って選択された１つの前記第２のサーバ装置が、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作する、
処理をコンピュータに実行させる請求項１ないし５のうちいずれか１項記載のプログラム。
【請求項７】
前記予め定められた選択基準は、複数の前記第２のサーバ装置のうち、業務への利用のための優先度の値が最も小さい値である、請求項１ないし６のうちいずれか１項記載のプログラム。
【請求項８】
クライアント装置によって収集された、第１のサーバ装置の状態と前記第１のサーバ装置の障害時に稼働する１以上の待機系サーバ装置の状態とを含む、状態情報を、第２のサーバ装置が、前記クライアント装置から、受信し、
前記状態情報が所定の第１の状態を表している場合、前記第２のサーバ装置が、前記第２のサーバ装置を前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作させる、
処理を有する方法。
【請求項９】
クライアント装置によって収集された、第１のサーバ装置の状態と前記第１のサーバ装置の障害時に稼働する１以上の待機系サーバ装置の状態とを含む、状態情報を、第２のサーバ装置が、前記クライアント装置から受信するサーバ状態受信部と、
前記状態情報が所定の第１の状態を表している場合、前記第２のサーバ装置が、前記第２のサーバ装置を前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作させる動作制御部と、
を有するシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、冗長化されたコンピュータの制御プログラム、方法、及び装置に関する。
【背景技術】
【０００２】
近年のサーバシステムの高度化に伴い、オンラインシステムでは、２４時間３６５日停止することのない高い信頼性と可用性が求められている。システムの可用性を向上させるためには、システムを構成するサーバを冗長化する方策が挙げられる。この冗長化によって、あるサーバが故障した場合においても、他のサーバが業務を引き継ぐことで、業務サービスの停止を防止することができる。また、故障したサーバの業務サービスへの影響を最小限にするために、速やかに故障したサーバを切り離し、正常なサーバで業務サービスを継続させることができる。
【０００３】
システムを構成するサーバを冗長化するための上記のような技術として、クラスタシステムがある。代表的なクラスタシステムとしては、ＨＡクラスタとフェイルオーバクラスタがある。
【０００４】
ＨＡ（High  Availability）クラスタは、サーバを複数台使用して冗長化させることにより、システム停止時間を最小限に抑え、業務サービスの可用性を向上させるクラスタシステムである。
【０００５】
フェイルオーバクラスタは、現用系サーバと待機系サーバとで構成される。業務サービスを運用中のサーバを現用系サーバと呼ぶ。そして、現用系サーバがダウンした場合に、その業務を引き継ぐサーバを待機系サーバと呼ぶ。この待機系サーバが複数台存在することでシステムの信頼性がより向上する。現用系サーバから待機系サーバへの業務処理の引き継ぎの仕組みをフェイルオーバと呼ぶ。
【０００６】
現用系サーバと待機系サーバとは、ハートビートと呼ばれる信号を送受信し合い、それぞれが正常に動作していることを確かめる（生存監視）。ハートビートとは「心臓の拍動」を意味し、自身が生きている（正常に動作している）ことを周囲に知らせるために定期的に送信する信号である。
【０００７】
クラスタシステムは、業務サービス単位にクラスタシステムを構築してもよい。したがって、サーバＡとサーバＢが、業務サービスＸと業務サービスＹを提供し得る場合、業務サービスＸについてはサーバＡが現用系サーバでサーバＢが待機系サーバであり、業務サービスＹについてはサーバＡが待機系サーバでサーバＢが現用系サーバであってもよい。
【０００８】
一般に、ある単一箇所が障害となると、システム全体が停止となるような箇所を、単一障害点と言う。フェイルオーバ後において、例えば現用系サーバＣだけで業務サービスＺを提供しており、待機系サーバが存在しない場合、現用系サーバＣによって提供される業務サービスＺは、単一障害点である。なぜなら、現用系サーバＣによって提供される業務サービスＺにおいて障害が発生した場合、業務サービスＺの提供が停止してしまうからである。
【０００９】
上述のような単一障害点については、故障した現用系サーバを復旧し、クラスタシステムに組み込むことで、冗長化が回復し、単一障害点は解消する。しかしながら、上述の障害が回復し、クラスタシステムに組み込むことが完了するまでは、単一障害点が存在することとなり、危険な状態である。
【００１０】
一般に、故障に備えて、冗長化の多重度を増加させたシステムは、可用性が高いと言える。しかしながら、ハードウェアを含めたリソースを手当する必要があり、その分だけコストがかかることとなる。
【００１１】
また、地震や火災などの災害によってシステム障害が発生した場合に、迅速に復旧するための仕組みや組織体制を「ディザスターリカバリ」と呼ぶ。ディザスターリカバリに対処するためには、例えば冗長化するシステムの一部を地理的に離れた場所に設置することが有効である。
【００１２】
このディザスターリカバリを考慮すると、現用系サーバが存在するサイトから離れた遠隔地にバックアップサイトを設けることも考慮する必要がある。クラスタシステムを構成しているサーバ間では、生存監視とデータ同期が頻繁に行われる。このため、バンド幅の広い専用線等が用いられる。しかしながら、遠隔地に対して専用線を敷くことはコストアップとなる。
【００１３】
また、例えば、業務サービスを三重化以上にした場合であっても、上述のハートビート用の専用線が故障すると、クラスタシステムを構成しているサーバ間の監視が不能となる。この場合、待機系のサーバ群は、現用系から切り離され、現用系の業務サービスが単一障害点になってしまう。単一障害点となった業務サービスにおいて故障が発生すると、上述のように業務サービスの提供は停止する。このため、業務サービスの停止を避けるためには、単一障害点を発見すること、及びこれを迅速に解消することが必要である。
【００１４】
また、現用系サーバが業務に利用しているネットワークを、生存監視等に用いることで、冗長化を図ることは可能であるが、業務サービス用のネットワークに負荷をかけ、システムのパフォーマンスに影響を与える可能性がある。
【００１５】
従来、クラスタシステムにおいて、複数の現用系サーバと１台または複数台の待機系サーバを配してクラスタシステムを構成し、現用系サーバは自サーバの障害を監視し、障害が発生した場合には障害通信部に障害発生を示し、また待機系サーバは、現用系サーバの障害通信部を監視し、現用系サーバの障害発生を確認した場合には、待機系サーバ主導により現用系サーバをシャットダウンし、待機系サーバを現用系サーバとして切り替える技術がある（特許文献１参照）。
【００１６】
また、従来、現用系サーバに固定的に割り当てられた、高速バックアップを実現する１次待機系サーバ、更に２次待機系サーバを備え、かつ、待機系サーバの信頼性確保のため、集中コンピュータ管理装置にて、正常時に、周期的に全てのコンピュータを現用系サーバとして動作させ、異常を迅速に検出可能とし、また、現用系サーバ異常時に、１次待機系サーバを現用系に切り替えて高速バックアップするとともに、共用２次待機系サーバをこの新たな１次待機系サーバに割り当てる技術がある（特許文献２参照）。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】特開２００４−３５５４４６号公報
【特許文献２】特開平８−１８５３３０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１８】
１つの側面では、本発明は、サーバの障害に対処するための冗長化の支援を行うことを目的とする。
【課題を解決するための手段】
【００１９】
一実施形態によれば、クライアント装置によって収集された、第１のサーバ装置の状態と前記第１のサーバ装置の障害時に稼働する１以上の待機系サーバ装置の状態とを含む、状態情報を、第２のサーバ装置が、前記クライアント装置から受信し、前記状態情報が所定の第１の状態を表している場合、前記第２のサーバ装置が、前記第２のサーバ装置を前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作させる、処理をコンピュータに実行させるプログラムが提供される。
【発明の効果】
【００２０】
実施態様によれば、サーバの障害に対処するための冗長化の支援を簡便に行うことができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態のシステム環境を示す図である。
【図２】一実施形態に係る機能ブロック図である。
【図３】業務サービス生存情報テーブルの例を示す図である。
【図４】業務サービス生存情報配信リストの例を示す図である。
【図５】通常処理におけるクラスタシステムの監視の概略を示すフローチャートである。
【図６】現用系サーバが業務サービス生存情報テーブルを更新するフローチャートである。
【図７】コネクション確立時におけるクライアントの処理を示すフローチャートである。
【図８】コネクション確立時における現用サイトの現用系サーバの処理を示すフローチャートである。
【図９】コネクション確立時における現用サイトの待機系サーバの処理を示すフローチャートである。
【図１０】コネクション確立時における監視・バックアップサイトの予備サーバの処理を示すフローチャートである。
【図１１】一実施形態に係る機能ブロック図である。
【図１２】予備サーバがクラスタシステムに参入する概略を示すフローチャートである。
【図１３】クラスタシステムへの参入の詳細を示すフローチャートである。
【図１４】予備サーバがクラスタシステムから離脱する概略を示すフローチャートである。
【図１５】クライアント及びサーバのハードウェア構成を示す図である。
【発明を実施するための形態】
【００２２】
本明細書においては、クラスタシステムを例示して説明を行うが、本発明は、クラスタシステムに限定されるものではない。また、図面を用いて説明するが、図面は、実施形態の内容を分かりやすく説明するためのものであり、発明を限定するためのものではない。
【００２３】
なお、各図に付された参照符号は、図面において最初に用いられた番号を他の図においても用いることがある点に留意すべきである。
【００２４】
図１は、本発明の実施形態のシステム環境１００を示している。以下に説明する実施形態では、図１に示すシステム環境を前提とするが、本発明は、この環境に限定されるものではない。
【００２５】
図１に示すように、システム環境１００は、現用サイト１１０と、監視・バックアップサイト１５０、クライアント１８０がネットワークＮＷで接続されている。なお、クライアント１８０は複数存在してもよい。
【００２６】
まず、現用サイト１１０は、複数の業務Ａないし業務Ｚをクライアント１８０にサービスしている。例えば、業務Ａをサービスしているクラスタシステム１１０Ａは、現用系サーバ１１１Ａと待機系サーバ１１２Ａを有する。待機系サーバ１１２Ａは、複数存在していてもよい。現用系サーバ１１１Ａと待機系サーバ１１２Ａとは、バンド幅の広い専用線１９０で接続されている。この専用線１９０によって、双方のサーバが生存監視を行い、データの同期を行っている。そして、例えば、クラスタシステム１１０Ａのフェイルオーバ機能により、現用系サーバ１１１Ａが故障した場合には、待機系サーバ１１２Ａが業務を引き継ぎ、現用系サーバとして機能する。これにより、業務Ａの継続的なサービスが担保されている。
【００２７】
監視・バックアップサイト１５０には、現用サイト１１０によりサービスされている業務Ａと同じ業務を継続するために現用サイト１１０の１１１Ａないし１１２Ａと同等なハードウェア構成・ソフトウエア構成を持つサーバ１５１Ａが存在する。このため、サーバ１５１Ａは、現用サイトによりサービスされている業務Ａの監視を行うことで業務Ａのクラスタシステムに参入及び離脱することが可能である。業務Ａのクラスタシステム１１０Ａの現用系サーバ１１１Ａ及び待機系サーバ１１２Ａが正常に稼働している限り、監視・バックアップサイト１５０のサーバ１５１Ａは、業務Ａのクラスタシステム１１０Ａからは切り離され、業務Ａのクラスタシステム１１０Ａの監視を行ってもよい。そして、サーバ１５１Ａは、監視・バックアップサイト１５０における他の業務の別個のクラスタシステムの一部として機能していてもよい。同様に、監視・バックアップサイト１５０には、業務ｎないし業務Ｚを監視し、またはバックアップするため、サーバ１５１ｎないし１５１Ｚが存在してもよい。
【００２８】
なお、上述の説明では、各業務にそれぞれ別個のサーバが用意されているが、一つのサーバが複数の業務をサポートしてもよい。また、サーバは、物理マシンであっても仮想マシンであってもよい。
【００２９】
更に、図１において、クライアント１８０が存在する。クライアント１８０は、ネットワークＮＷを介して、現用サイトの現用系サーバが提供する業務Ａないし業務Ｚのうちの少なくとも１つのサービスを受けることができる。例えば、クライアント１８０は、業務Ｚのサービスを受けてもよい。例えば、クライアント１８０は、業務Ｚの処理要求電文１７１、１７２、及び１７３をマルチキャストでそれぞれサーバ１１１Ｚ、１１２Ｚ、及び１５１Ｚに送信してもよい。
【００３０】
図１では、現用サイト１１０と監視・バックアップサイト１５０とは、業務に用いるネットワークＮＷによって接続されており、バンド幅の広い専用線１９０によって接続されていなくてもよい。なお、現用サイト１１０と監視・バックアップサイト１５０とは、地理的に離れていても、接近していてもよい。
【００３１】
バックアップサイトに存在するサーバ１５１Ａないし１５１Ｚは、現用サイトのクラスタシステムに常時組み込まれていないことが望ましい。そして、監視・バックアップサイトの主たる機能は、現用サイトのクラスタシステムの単一障害点の迅速な発見、及び／又は、現用サイトにおける単一障害点が存在する間にクラスタシステムへの一時的な参入を行い、この単一障害点を解消することである。
【００３２】
なお、上記システム環境１００の詳細な動作については、後述する。
【００３３】
以下の、詳細な実施形態においては、大きく以下の２つの項目に分けて、順を追って説明を行う。
（Ａ）監視・バックアップサイトの予備サーバが現用サイトのクラスタシステムの単一障害点を監視する実施形態。
（Ｂ）現用サイトのクラスタシステムの単一障害点が存在する場合、監視・バックアップサイトのサーバが、現用サイトのクラスタシステムに参入及び離脱する実施形態。
【００３４】
なお、各実施形態は、それぞれ排他的なものではない。すなわち、必要に応じて、ある実施形態の一部を他の実施形態と組合せてもよいことは言うまでもない。
【実施例】
【００３５】
（Ａ）監視・バックアップサイトの予備サーバが現用サイトのクラスタシステムの単一障害点を監視する実施形態。
【００３６】
図２は、一実施形態に係る機能ブロック図を示している。図２は、図１における業務Ｚに係る機能について例示したものである。
【００３７】
クライアント１８０は、クライアント用業務Ｚ処理部２１０、クライアント制御部２２０、業務サービス生存情報テーブル（１）２１５、業務サービス生存情報配信リスト２１６を含む。
【００３８】
クライアント用業務Ｚ処理部２１０は、例えばスケジュール管理を提供するアプリケーションプログラムであってもよい。クライアント用業務Ｚ処理部は、処理要求を現用系サーバ１１１Ｚのサーバ用業務Ｚ処理部２６０に与える。そして、サーバ用業務Ｚ処理部２６０からの応答を受信することにより、スケジュール管理の業務を遂行してもよい。
【００３９】
クライアント制御部２２０は、クライアント用業務Ｚ処理部２１０からの処理要求と、サーバ用業務Ｚ処理部２６０からの応答を仲介する機能を有する。クライアント制御部２２０は、受信部２２２、処理要求電文生成部２２４、制御電文生成部２２６、及び送信部２２８を含んでもよい。また送信部２２８は、マルチキャスト送信部２２９を含むことが望ましい。また、クライアント制御部２２０は、業務サービス生存情報テーブル（１）２１５及び業務サービス生存情報配信リスト２１６を利用してもよい。
【００４０】
業務サービス生存情報テーブル（１）２１５は、各サーバの状態を業務別に整理した情報であり、その具体例を図３（Ａ）に示す。なお、図３の詳細については、後述する。
【００４１】
また、業務サービス生存情報配信リスト２１６は、マルチキャスト送信部２２９が、業務に係る電文をその業務に関連するサーバにマルチキャスト送信するために用いるサーバのアドレスが記憶されたリストである。具体的な業務サービス生存情報配信リスト２１６の例を図４に示す。なお、図４の詳細については後述する。
【００４２】
受信部２２２は、業務Ｚ処理部に処理結果を返却する。また、サーバからの応答電文に付加されたサーバ状態情報を抽出して、業務サービス生存情報テーブル（１）２１５に蓄積する機能を有してもよい。
【００４３】
処理要求電文生成部２２４は、クライアント用業務Ｚ処理部２１０からの処理要求に業務サービス生存情報テーブル（１）２１５の情報を付加して処理要求電文を生成する機能を有してもよい。
【００４４】
制御電文生成部２２６は、所定の時間内（例えば、業務Ｚ用クラスタシステムで用いられるハートビートの時間間隔）にクライアント用業務Ｚ処理部２１０からの処理要求が発生せず、かつその間に業務サービス生存情報テーブル（１）２１５の業務Ｚに係る情報が変更されている場合に、業務サービス生存情報テーブル（１）２１５の情報を制御電文として生成してもよい。この制御電文は、各サーバにマルチキャスト送信される。この機能によって、処理要求が所定の時間内に発生しない場合であっても、監視・バックアップサイト１５０の業務Ｚ予備サーバ（１）１５１Ｚが管理している業務サービス生存情報テーブル（３）２８５の情報をアップデートすることができる。これによって、監視・バックアップサイト１５０の業務Ｚ予備サーバ（１）１５１Ｚは、クラスタシステムの状態を常に監視することができる。
【００４５】
更に図２において、現用サイトの業務Ｚ用クラスタシステム１１０Ｚは、現用系サーバ１１１Ｚと待機系サーバ１１２Ｚとを有している。上述のように、待機系サーバ１１２Ｚは、複数存在することが望ましいが、その分コストを増加させることとなる。図２においては、例示としてクラスタシステムを構成する最小限の数のサーバが示されている。現用系サーバ１１１Ｚと待機系サーバ１１２Ｚは、同じ構成であることが望ましいが、異なるハードウェア要素又はソフトウエア要素があってもよい。ただし、クラスタシステムを構成するために必要なソフトウエアがインストールされていること、および最低限のハードウェアスペックが確保されていることが必要である。
【００４６】
現用系サーバ１１１Ｚには、サーバ制御部２５０、サーバ用業務Ｚ処理部２６０、業務サービス生存情報テーブル（２）２６５、待機系サーバ１１２Ｚとの同期・生存監視（ハートビート）のための専用線２６７を有することが望ましい。
【００４７】
業務サービス生存情報テーブル（２）２６５は、例えばサーバ制御部２５０によってアップデートされてもよい。サーバ制御部２５０は、待機系サーバ１１２Ｚの生存監視を行い、この情報を業務サービス生存情報テーブル（２）２６５に反映させることが望ましい。業務サービス生存情報テーブル（２）２６５の具体例を図３（Ｂ）に示す。図３の詳細は後述する。
【００４８】
サーバ用業務Ｚ処理部２６０は、クライアント１８０からの処理要求を受け、その処理結果を応答として返す。サーバ用業務Ｚ処理部２６０は、業務処理Ｚ（例えば、スケジュール管理）の業務を処理するアプリケーションプログラムであってもよい。
【００４９】
サーバ状態送信部２５２は、サーバ用業務Ｚ処理部２６０からの応答に、業務サービス生存情報テーブル（２）２６５の情報を付加して、応答電文を生成し、クライアント１８０に送信する機能を有してもよい。また、サーバ状態送信部２５２は、ハートビートの時間間隔に関する情報を含む電文を生成し、クライアント１８０に送信する機能を有してもよい。
【００５０】
業務サービス生存情報削除部２５４は、クライアント１８０から送られた電文から業務情報サービス生存情報を削除することにより、クライアント１８０からの処理要求を抽出して、サーバ用業務Ｚ処理部２６０に伝達してもよい。業務情報サービス生存情報は、現用系サーバ１１１Ｚが過去にクライアント１８０に送った情報によってアップデートされた業務サービス生存情報テーブル（２）２６５の情報及び他の業務に係る情報であるため、削除してもよい。
【００５１】
待機系サーバ１１２Ｚにも、クライアント１８０から、マルチキャストで電文が送信されてもよい。なお、待機系サーバ１１２Ｚは、この電文を単に破棄してもよい。
【００５２】
更に図２を参照する。監視・バックアップサイト１５０には、少なくとも１つの業務Ｚ予備サーバ（１）１５１Ｚが存在する。
【００５３】
業務Ｚ予備サーバ（１）１５１Ｚは、少なくとも現用サイトの業務Ｚ用クラスタシステム１１０Ｚの監視機能を有することが望ましい。業務Ｚ予備サーバ（１）１５１Ｚは、少なくとも、サーバ制御部２８０及び業務サービス生存情報テーブル（３）２８５を有し、現用サイトの業務Ｚ用クラスタシステム１１０Ｚに存在する複数のサーバを監視する機能を有する。また、業務Ｚ予備サーバ（１）１５１Ｚは、現用サイトの業務Ｚ用クラスタシステム１１０Ｚに単一障害点が発生した場合に、能動的（主体的）に当該クラスタシステムに参入し、そして、クラスタシステムの障害が回復した際に、能動的（主体的）にクラスタシステムから離脱する機能を有してもよい。なお、この点に関する詳細は、実施形態（Ｂ）において後述する。
【００５４】
サーバ状態受信部２８２は、クライアント１８０からマルチキャストされた電文を受信する。そして、サーバ状態受信部２８２は、更にその電文から業務サービス生存情報のうち、業務Ｚに係る情報を抽出し、業務サービス生存情報テーブル（３）２８５を更新する。この処理を行うことによって、業務サービス生存情報テーブル（３）２８５には、現用サイトの業務Ｚ用クラスタシステム１１０Ｚに存在する複数のサーバの状態が蓄積されると共に、アップデートされてゆく。
【００５５】
動作制御部２８４は、業務サービス生存情報テーブル（３）２８５の内容を読み出し、現用サイトの業務Ｚ用クラスタシステム１１０Ｚに単一障害点が存在するか否かを監視する。動作制御部２８４は、この監視した情報をオペレータに分かるように報知してもよい。あるいは、後述するように、動作制御部２８４は、業務Ｚ予備サーバ（１）１５１Ｚを、業務Ｚ用クラスタシステム１１０Ｚに参入させ、あるいは、離脱させてもよい。
【００５６】
なお、図２は、クライアントからサーバへの処理依頼に対し、サーバからクライアントへ結果を返却する同期型の説明をしているが、クライアントからサーバへの処理依頼を一方的に通知し、サーバからクライアントへ結果が返却されない、非同期型でもよい。
【００５７】
図３は、業務サービス生存情報テーブルの例を示しており、記憶部（図示せず）に記憶される。
【００５８】
図３（Ａ）は、クライアント１８０に存在する業務サービス生存情報テーブル（１）２１５の例を示している。業務サービス生存情報テーブル（１）２１５は、サーバ名、業務サービス名、サーバの場所、業務サービス生存情報、サーバ状態取得時刻、業務サービス生存情報配信時刻、業務サービス生存情報配信タイマー値、及びサーバ状態変更フラグを有することが望ましい。業務サービス生存情報テーブル（１）２１５は、クライアント１８０が利用する業務に関連するクラスタシステムの各々のサーバの状態が蓄積された情報である。この情報は、上述のように、現用系サーバ１１１Ｚ等からの応答に付加された業務サービス生存情報を抽出することによって取得される。そして、業務サービス生存情報テーブル（１）２１５の情報は、処理要求に付加された処理要求電文、又は制御電文によって、マルチキャスト送信される。なお、業務サービス生存情報テーブル（１）２１５の情報のうち、処理要求電文に係る業務に関連する情報のみを抽出して、処理要求電文に付加してもよい。
【００５９】
サーバ名は、各サーバに付与された固有の識別情報である。
【００６０】
業務サービス名は、クラスタシステムが提供する業務サービスを特定する情報である。
【００６１】
サーバの場所は、例えば、現用サイト、監視・バックアップサイトのいずれかである。サーバの場所は、例えば、サーバが、能動的にクラスタシステムから離脱する際に、自身が、クラスタシステムに参入した監視・バックアップサイト１５０の予備サーバであるか否かを確認するために利用してもよい。また、サーバの場所の情報を参照することによって、現用サイトのサーバは、能動的にクラスタシステムから離脱させないようにすることも可能である。
【００６２】
業務サービスの生存情報は、現用系（Active：業務サービス動作可能な状態)、待機系(Standby：業務サービス切り替え可能な状態)、Activating(Standby→Activeへ切り替わり中)、Stop(停止)、Starting(Stop→Standby中)、Stopping(Active,  Standby→stop中)、Faulted(故障)、データ同期中等の状態を用いてもよい。たとえば、特定の業務において、現用サイトの現用系だけが稼働しており、待機系が存在しない場合（例えば、故障の場合）には、その現用サイトの業務は、単一障害点であることが分かる。この場合には、現用系だけが稼働しており、危険な状態である。したがって、監視・バックアップサイト１５０のサーバを、そのクラスタシステムに参入させる等の対応を行うことにより、単一障害点を解消することができる。
【００６３】
サーバ状態取得時刻は、業務サービス生存情報テーブル（１）２１５を更新する際に、既に登録されている情報を古い情報で上書きしてしまうのを防止するために利用してもよい。
【００６４】
業務サービス生存情報配信時刻は、クライアント１８０が、業務サービス生存情報テーブル（１）２１５の情報を最後に送信した時刻が記憶される。
【００６５】
業務サービス生存情報配信タイマー値は、例えば、対応する業務のクラスタシステムのハートビートの時間間隔を用いてもよい。
【００６６】
サーバ状態変更フラグは、クライアント１８０が、業務サービス生存情報テーブル（１）２１５の情報を最後に送信した時刻から、現在時刻までに、対応する業務に係る業務サービス生存情報テーブル（１）２１５のエントリが更新されたか否かを示す。ＯＦＦであれば、更新されていないことを示す。ＯＮであれば、更新されていることを示す。
【００６７】
業務サービス生存情報配信時刻から、業務サービス生存情報配信タイマー値の時間が経過し、かつサーバ状態変更フラグがＯＮの場合、以下の処理を行うことが望ましい。すなわち、次の処理要求の発生を待たずに、制御電文生成部が業務サービス生存情報を含む制御電文を生成し、かつ、サーバ状態変更フラグがＯＮの業務に結びつけられた業務サービス生存情報配信リストのサーバへマルチキャスト送信する。この処理によって、クライアント１８０の業務サービス生存情報テーブル（１）２１５の更新された情報を、監視・バックアップサイト１５０の業務Ｚ予備サーバ（１）１５１Ｚに、ハートビートの時間間隔と同程度のタイムラグで伝達することができる。
【００６８】
業務Ｂ（人事）のエントリでは、監視・バックアップサイト１５０の予備サーバ１５１Ｂがリストアップされている。そして、現用サイト１１０のサーバ１１１Ｂが故障しているため、現用サイト１１０のサーバ１１２Ｂが、現用系サーバとして稼働している。すなわち、現用サイト１１０の業務Ｂのサービスにおいて単一障害点が存在しているため、監視・バックアップサイト１５０の予備サーバ１５１Ｂが、待機系サーバとして、業務Ｂに係るクラスタシステムに参入していることが示されている。このように、監視・バックアップサイト１５０の予備サーバは、クラスタシステムに参入したときだけ、この業務サービス生存情報テーブル（１）にリストアップされてもよい。図３に示す他のテーブルについても同様である。
【００６９】
図３（Ｂ）は、現用系サーバ１１１Ｚが管理する業務サービス生存情報テーブル（２）２６５の例を示す。このテーブルの情報は、サーバ用業務Ｚ処理部２６０の応答に付加されて、クライアント１８０に伝達され、業務サービス生存情報テーブル（１）２１５を更新するために用いられることが望ましい。
【００７０】
図３（Ｃ）は、業務Ｚ予備サーバ（１）１５１Ｚが管理する業務サービス生存情報テーブル（３）２８５の例を示している。このテーブルの情報は、クライアント１８０からのマルチキャスト送信で配信された電文に含まれる情報（すなわち、業務サービス生存情報テーブル（１）２１５の情報）によって更新される。業務Ｚ予備サーバ（１）１５１Ｚは、業務サービス生存情報テーブル（３）２８５を参照することにより、業務Ｚ用クラスタシステム１１０Ｚを監視することができる。また、業務Ｚ用クラスタシステム１１０Ｚに単一障害点が存在する場合には、例えば実施形態（Ｂ）において後述するように、この単一障害点を解消するためのオペレーションを開始してもよい。
【００７１】
図４は、業務サービス生存情報配信リストの例を示している。このリストは、業務サービス名、サーバ名、ＩＰアドレスの項目を有することが望ましい。このリストにより、特定の業務サービスに対応できるサーバ名とそのネットワークアドレスが取得できる。なお、アドレスは必ずしもＩＰアドレスである必要はない。マルチキャスト送信部２２９は、このリストを参照して、電文に関連する業務に関係するサーバに、電文をマルチキャスト送信することができる。このリストには、現用サイトの現用系サーバ１１１Ｚ及び待機系サーバ１１２Ｚ、並びに監視・バックアップサイトの予備サーバ１５１Ｚの情報が格納されていることが望ましい。  図５は、通常処理におけるクラスタシステムの監視の概略を示すフローチャートを示している。通常処理とは、コネクション確立時等の初期化の処理等を含まない、通常の処理のフローを意味する。
【００７２】
ステップ５０２において、クライアント１８０が処理要求電文又は制御電文を最後に配信した時刻から、ハートビートの時間間隔が経過したかが判断される。この判断が「はい」であれば、ハートビートの時間間隔よりも長い間、業務サービス生存情報テーブル（１）２１５の情報が、各サーバにマルチキャスト配信されていないことを意味する。なお、この判断は、業務サービス生存情報テーブル（１）２１５の業務サービス生存情報配信時刻と現在時刻の差を、業務サービス生存情報配信タイマー値と比較することにより判断できる。ステップ５０２は、定期的なタイマー割込で開始されることが望ましい。また、このタイマー割込の間隔は、ハートビートタイマー値よりも十分短いことが望ましい。なお、ハートビートタイマー値以外の時間間隔を別途設定してもよい。この判断が、「いいえ」であれば、処理は終了する。この判断が「はい」であれば、ステップ５０４に進む。
【００７３】
ステップ５０４において、業務サービス生存情報テーブル（１）２１５のサーバ状態変更フラグがＯＮのエントリが存在するか否かが判断される。この判断が、「はい」であれば、業務サービス生存テーブル（１）の情報が最後に送信されてから、現在までの間に業務サービス生存情報テーブル（１）２１５の情報がマルチキャストされておらず、かつその時間がハートビート時間間隔よりも長いことを意味する。この状況は、クラスタシステムの状況が変化したにもかかわらず、その情報が、監視・バックアップサイトの予備サーバ１５１Ｚに一定期間（ハートビート時間間隔以上の期間）伝達されていないことを示す。この判断が「いいえ」であれば、業務サービス生存情報テーブル（１）２１５の情報は変更されていないため、処理は終了する。この判断が「はい」であれば、ステップ５０６に進む。
【００７４】
ステップ５０６において、クライアント１８０は、業務サービス生存情報テーブル（１）２１５の情報含む処理要求なしの制御電文を生成する。この制御電文は、クライアント用業務Ｚ処理部２１０からの処理要求を待たずに、業務サービス生存情報テーブル（１）２１５の情報を、クラスタシステムを監視する監視・バックアップサイトに転送するための電文である。次にステップ５１０に進むが、その前にステップ５０８について説明する。
【００７５】
ステップ５０８は、クライアント１８０が、処理要求を発生した場合に開始される。このステップで、処理要求に業務サービス生存情報テーブル（１）２１５の情報を付加した処理要求電文が生成される。この処理は、処理要求を現用系サーバにユニキャストで送るのではなく、処理要求に業務サービス生存情報テーブル（１）２１５の情報を付加した電文を生成し、監視等を行う予備サーバにもマルチキャストで同じ電文を送ることにより、処理要求と監視用の情報とを送信し、トラフィックの増加を極力抑えつつ、複数の情報を送り、複数の処理（処理要求の処理とクラスタシステムの監視）をすることが可能となる。なお、業務サービス生存情報テーブル（１）２１５の情報のうち、電文に関連する業務の部分のみを抽出して、処理要求に付加してもよい。また、この処理要求電文には、現用系サーバ１１１Ｚに対し、応答電文にクラスタシステムを構成する現用系サーバと待機系サーバの状態に関する情報を送るよう要求する命令を含めてもよい。この場合には、後述するように、この命令がなされた場合にのみ、現用系サーバ１１１Ｚは、上記状態に関する情報を応答電文に付加して、クライアントに返信する。
【００７６】
ステップ５１０において、クライアント１８０が、業務サービス生存情報配信リスト２１６を参照し、処理要求電文又は制御電文の業務に結びつけられた配信先のサーバに、処理要求電文又は制御電文をマルチキャストで送信する。業務サービス生存情報配信時刻は、クライアント１８０が、業務サービス生存情報テーブル（１）２１５の情報に電文を送信した時刻を記憶する。そして、業務サービス生存情報テーブル（１）２１５の関連する業務のサーバ状態変更フラグをＯＦＦにする。
【００７７】
ステップ５１２において、現用系サーバ１１１Ｚは、電文を受け取り、クライアント１８０の処理要求を処理し応答を生成し、応答に業務サービス生存情報テーブル（２）２６５の情報を付加して応答電文を生成し、クライアント１８０に送信する。たとえば、現用系サーバ１１１Ｚが管理している業務サービス生存情報テーブル（２）２６５は、クラスタシステムを構成している待機系サーバ１１２Ｚの生存情報も含まれる（図３（Ｂ）参照）。したがって、クライアント１８０は、この応答電文を受信することにより、処理要求の結果とクラスタシステムに関連するサーバの情報の最新情報を入手することが可能となる。このように、応答電文に業務処理の応答とクラスタシステムに関連するサーバの情報を含めることにより、トラフィックの増加を最小限に抑えつつ、二つの情報をクライアント１８０に送ることが可能となる。なお、この伝送は、ユニキャストにより送信されることが望ましい。なお、ステップ５０８で述べたように、クライアントからの電文にクラスタシステムを構成する現用系サーバと待機系サーバの状態に関する情報を送るよう要求する命令が含まれていた場合にのみ、応答に業務サービス生存情報テーブル（２）２６５の情報を付加してもよい。
【００７８】
ステップ５１４において、クライアント１８０は、例えば、現用系サーバ１１１Ｚから受信した応答電文に含まれるクラスタシステムの情報を取得し、業務サービス生存情報テーブル（１）２１５を更新し、変更があれば、対応する業務のサーバ状態変更フラグをＯＮにする。なお、この処理においては、業務サービス生存情報テーブル（１）２１５の関連する業務のサーバ状態取得時刻をチェックすることが望ましい。このチェックにより、業務サービス生存情報テーブル（１）２１５に記録されたサーバ状態取得時刻が、サーバから取得された情報に付加されたサーバ状態取得時刻よりも新しい場合には、業務サービス生存情報テーブル（１）２１５を古い情報で上書きしてしまうことを避けることができる。そして、その後処理は終了する。
【００７９】
ステップ５１６は、待機系サーバ１１２Ｚの処理を示している。上述の電文のマルチキャスト送信では、電文を待機系サーバ１１２Ｚに送信してもよい。この場合には、待機系サーバ１１２Ｚは、受信した電文を単に破棄してもよい。なお、待機系サーバ１１２Ｚが現用系サーバになった場合には、自己の業務サービス生存情報テーブルを参照して、自サーバの業務サービス生存情報を付加し、クライアント１８０に返信する。
【００８０】
ステップ５１８は、監視・バックアップサイト１５０の予備サーバ１５１Ｚの処理を示している。予備サーバ１５１Ｚは、処理要求電文又は制御電文から業務サービス生存情報を抽出し、業務サービス生存情報テーブル（３）２８５を更新することが望ましい。業務サービス生存情報テーブル（３）２８５をチェックすることにより、例えば、現用サイトの業務Ｚ用クラスタシステム１１０Ｚを監視することができる。このクラスタシステムに単一障害点が発見されれば障害の解消を実行してもよい。あるいは、オペレータに報知してもよい。障害の解消の詳細は、実施形態（Ｂ）において後述する。なお、予備サーバ１５１Ｚが待機系サーバ又は現用系サーバになった場合には、自己の業務サービス生存情報テーブル（３）２８５を参照して、自サーバの業務サービス生存情報を付加し、クライアント１８０に返信する。
【００８１】
以上の一連の処理によって、監視・バックアップサイトの予備サーバ１５１Ｚは、ネットワークＮＷのトラフィックの増加を抑えつつ、業務Ｚクラスタシステム１１０Ｚに存在する現用系サーバ１１１Ｚ及び待機系サーバ１１２Ｚを簡便に監視することが可能となる。
【００８２】
図６は、現用系サーバ１１１Ｚが業務サービス生存情報テーブルを更新するフローチャートを示している。
【００８３】
ステップ６０２において、現用系サーバ１１１Ｚが、待機系サーバ１１２Ｚの状態を取得し、現用系サーバ１１１Ｚと待機系サーバ１１２Ｚの状態を業務サービス生存情報テーブル（２）２６５に保存する（図３（Ｂ）参照）。通常、クラスタシステムは、ハートビートの時間間隔で、現用系と待機系とが相互に相手の生存監視を行っている。この監視の結果の情報を業務サービス生存情報テーブル（２）２６５に保存することが望ましい。
【００８４】
図７ないし図１０は、コネクション確立時における処理を示している。クライアント１８０が現用系サーバと連携して業務を処理するためには、まずコネクションの確立が正常に行われる必要がある。また、クライアント１８０は、現用系サーバ１１１Ｚ、待機系サーバ１１２Ｚ及び、監視・バックアップサイト１５０の予備サーバ１５１Ｚにマルチキャスト送信を行うため、予めコネクション確立を行っておくことが望ましい。
【００８５】
図７は、コネクション確立時におけるクライアント１８０の処理を示すフローチャートである。
【００８６】
ステップ７０２において、業務サービス生存情報配信リストをメモリ上のテーブルに設定する。特定の業務に関係するサーバのサーバ名及びネットワークアドレスは、予めクライアント１８０に記憶されていてもよい。あるいは、ネットワーク上の特定のサイトを参照して、クライアント１８０が、特定の業務に関係するサーバのサーバ名とアドレスを検索して取得してもよい。
【００８７】
ステップ７０４において、クライアント１８０は、業務サービス名に結びつけられた現用サイトおよび監視・バックアップサイトのサーバへコネクション確立依頼の処理要求を含む処理要求電文をマルチキャスト送信する。
【００８８】
ステップ７０６において、業務サービス生存情報テーブル（１）２１５のサーバ状態変更フラグをＯＦＦに設定する。
【００８９】
ステップ７０８において、現用系サーバ１１１Ｚから応答電文を受信する。
【００９０】
ステップ７１０において、受信した電文に付加されているクラスタシステムを構成しているサーバ間のハートビートのタイマー値を業務サービス状態配信タイマー値として業務サービス生存情報テーブル（１）２１５に設定する。この値は、その後変更しなくてもよい。また、ハートビートのタイマー値以外の値が設定されてもよい。なお、このステップにおいて、現用系サーバ１１１Ｚから、業務サービス生存情報テーブル（２）２６５に関する情報を取得し、クライアント１８０の業務サービス生存情報テーブル（１）２１５に保存してもよい。
【００９１】
ステップ７１２において、現用系サーバ１１１Ｚからの応答電文からクラスタシステムを構成しているサーバ間のハートビートのタイマー値（及び必要に応じて、業務サービス生存情報テーブル（２）２６５に関する情報）を除外し、呼び出し元のクライアント制御部２２０に渡す。
【００９２】
以上の処理によって、クライアント１８０は、コネクションが確立されたことが確認できると共に、業務サービス状態配信タイマー値がセットされる。また、業務サービス生存情報テーブル（２）２６５に関する情報を取得することも可能である。
【００９３】
図８は、コネクション確立時における現用サイトの現用系サーバ１１１Ｚの処理を示すフローチャートである。
【００９４】
ステップ８０２において、現用系サーバ１１１Ｚは、クライアント１８０のクライアント制御部２２０からのコネクション確立依頼の処理要求電文を受信する。
【００９５】
ステップ８０４において、現用系サーバ１１１Ｚは、クライアント１８０とコネクションを確立する。
【００９６】
ステップ８０６において、クラスタシステムを構成しているサーバ間のハートビートのタイマー値を応答電文に付加する。なお、このステップにおいて、現用系サーバ１１１Ｚが管理する業務サービス生存情報テーブル（２）２６５の情報を応答電文に付加してもよい。
【００９７】
ステップ８０８において、呼び出し元のクライアント１８０のクライアント制御部２２０へ応答電文を返信する。
【００９８】
図９は、コネクション確立時における現用サイト１１０の待機系サーバ１１２Ｚの処理を示すフローチャートである。
【００９９】
ステップ９０２において、クライアント制御部２２０からのコネクション確立依頼の処理要求電文を受信する。
【０１００】
ステップ９０４において、クライアント１８０とコネクションを確立する。
【０１０１】
ステップ９０６において、呼び出し元のクライアント制御部２２０へ応答電文を返信する。コネクション確立が確実に行われたか否かをクライアント１８０が確認するために、待機系サーバ１１２Ｚであっても、コネクション確立に対する応答をクライアント１８０に返信することが望ましい。
【０１０２】
図１０は、コネクション確立時における監視・バックアップサイト１５０の予備サーバ１５１Ｚの処理を示すフローチャートである。
【０１０３】
ステップ１００２において、クライアント制御部２２０からのコネクション確立依頼の処理要求電文を受信する。
【０１０４】
ステップ１００４において、クライアント１８０とコネクションを確立する。
【０１０５】
ステップ１００６において、呼び出し元のクライアント制御部２２０へ応答電文を返信する。コネクション確立が確実に行われたか否かをクライアント１８０が確認するために、予備サーバであっても、コネクション確立に対する応答をクライアント１８０に返信することが望ましい。
【０１０６】
以上の処理が正常に終了することによって、業務サービス生存情報配信リスト２１６の内容が正しいことが確認できる。
【０１０７】
（Ｂ）現用サイトのクラスタシステムの単一障害点が存在する場合、監視・バックアップサイトのサーバが、現用サイトのクラスタシステムに参入及び離脱する実施形態。
【０１０８】
図１１は、一実施形態に係る機能ブロック図を示している。図２と同じ構成要素には、同じ参照符号が付されている。図２と比較して、図１１では、新たに業務Ｚ予備サーバ（２）１１５１Ｚが示されている。なお、業務Ｚ予備サーバ（２）１１５１Ｚが必須であるわけではない。また、業務Ｚ予備サーバ（１）１５１Ｚのサーバ制御部２８０に、動作選択部１１８６が存在してもよい。また、動作制御部２８４は、業務Ｚ用クラスタシステム１１０Ｚへの参入要求及び離脱要求１１０１を伝達できる能力があることが望ましい。また、併せて業務Ｚ予備サーバ（１）１５１Ｚは、監視・バックアップサイト１５０に存在する別個のクラスタシステムへの離脱及び参入ができる能力があることが望ましい（図示せず）。
【０１０９】
図１２は、監視・バックアップサイト１５０の予備サーバ（１）１５１Ｚがクラスタシステム１１０Ｚに参入する概略を示すフローチャートを示している。
【０１１０】
ステップ１２０２において、監視・バックアップサイト１５０の予備サーバ１５１Ｚ（自サーバ）が、処理要求電文又は制御電文をクライアント制御部２２０から受信する。
【０１１１】
ステップ１２０４において、自サーバが、処理要求電文又は制御電文から業務サービス生存情報を抽出し、業務サービス生存情報テーブル（３）２８５を更新することが望ましい。この処理によって、クラスタシステム１１０Ｚの現用系サーバ１１１Ｚ及び待機系サーバ１１２Ｚに関して新たな状態が業務サービス生存情報テーブル（３）２８５に蓄積される。なお、この処理においては、業務サービス生存情報テーブル（３）２８５のサーバ状態取得時刻をチェックすることが望ましい。このチェックにより、蓄積されている情報よりも取得した情報が古いものであるか否かがチェックでき、古い情報で、業務サービス生存情報テーブル（３）２８５が上書きされてしまうことを防止できる。
【０１１２】
ステップ１２０６において、業務サービス生存情報テーブル（３）２８５に存在する、受信した電文に係る業務の業務サービス生存情報を参照する。
【０１１３】
ステップ１２０８において、監視対象の業務サービスが単一障害点になっているかがチェックされる。このチェックは、稼働可能な現用サイトのサーバ台数が１以下となっているか否かで判断することが可能である。この判断が「いいえ」であれば、処理は、ステップ１２０２に戻る。この判断が「はい」であれば、ステップ１２１２に移る。
【０１１４】
ステップ１２１２において、現在参入している監視・バックアップサイトのクラスタシステムから、予備サーバ（１）１５１Ｚ（自サーバ）を離脱させる。予備サーバ（１）１５１Ｚは、クラスタシステム１１０Ｚを監視しつつ、他のクラスタシステムの一部として稼働していてもよいからである。この場合には、クラスタシステム１１０Ｚの負荷を軽くするため、現在参入している監視・バックアップサイトのクラスタシステムから、予備サーバ（１）１５１Ｚ（自サーバ）を離脱させることが望ましい。なお、予備サーバ（１）１５１Ｚの処理能力に応じて、離脱させないようにすることも可能である。この離脱は、予備サーバ（１）１５１Ｚによって、能動的に行われることが望ましい。
【０１１５】
また、複数の予備サーバが存在する場合には、クラスタシステムに現在参入している予備サーバのうちで、最も業務処理の優先度が低い予備サーバを選択してもよい。この選択は、図１１における動作選択部１１８６によって遂行される。この選択基準は、予備サーバの業務サービス生存情報（図示せず）に、予め優先順位を与えておいてもよい。
【０１１６】
ステップ１２１４において、現用サイトのクラスタシステム１１０Ｚに対し、予備サーバ（１）１５１Ｚ（自サーバ）の参入要求を送信する（１１０１）。この参入要求は、予備サーバ（１）１５１Ｚ（自サーバ）によって、能動的に行われることが望ましい。
【０１１７】
ステップ１２１６において、現用サイトのクラスタシステム１１０Ｚの肯定応答を受けて、現用サイトのクラスタシステム１１０Ｚに、予備サーバ（１）１５１Ｚ（自サーバ）を参入させる。なお、参入の手順の詳細は、図１３を用いて後述する。
【０１１８】
ステップ１２１８において、クライアント１８０からの処理要求電文が到来した際に、業務サービス生存情報テーブル（３）２８５を参照して、これに対する応答電文に、自サーバの業務サービス生存情報を付加し、クライアント１８０に返信する。この処理によって、クライアント１８０の管理する業務サービス生存情報テーブル（１）２１６が更新される。
【０１１９】
以上の処理によって、監視・バックアップサイト１５０の予備サーバ（１）１５１Ｚがクラスタシステム１１０Ｚに参入する。
【０１２０】
図１３は、クラスタシステム１１０Ｚへの参入の詳細を示すフローチャートである。
【０１２１】
ステップ１３０２において、監視・バックアップサイトの予備サーバ（１）１５１Ｚ（自サーバ）の状態をデータ同期中にして、現用サイトのクラスタシステムとハートビートを開始する。
【０１２２】
ハートビートは、ステップ１３０４、ステップ１３０６、ステップ１３０８のデータ同期処理と並行に実施する。
【０１２３】
なお、クラスタシステム参入後、クラスタシステムを構成する他サーバの生存監視について、クラスタシステムの機能を使用して実施してもよい。
【０１２４】
ステップ１３０４において、例えば、現用サイトの現用系サーバ１１１Ｚとデータ同期を開始する。この同期は、専用線ではなく業務に用いられているネットワークＮＷを用いることができる。なお、ファイル共有機能を用いて、データ同期のためのデータ転送量を減少させてもよい。
【０１２５】
ステップ１３０６において、現用サイトの現用系サーバとデータ同期完了を待ち合わせる。
【０１２６】
ステップ１３０８において、データ同期が完了したか否かが判断される。この判断が「いいえ」であれば、ステップ１３０６に戻る。この判断が「はい」であれば、ステップ１３１０に移る。
【０１２７】
ステップ１３１０において、自サーバの状態を待機系にして、現用サイトの現用系サーバにハートビートを送信する。この送信には、業務用のネットワークＮＷを用いることができる。
【０１２８】
以上の処理で、監視・バックアップサイト１５０の予備サーバ（１）１５１Ｚがクラスタシステム１１０Ｚに参入し、待機系サーバとして機能することができる。なお、現用系のサーバが全てダウンした場合には、監視・バックアップサイト１５０の予備サーバ（１）１５１Ｚが、現用系サーバとなることができることは言うまでもない。
【０１２９】
図１４は、予備サーバ１５１Ｚがクラスタシステム１１０Ｚから離脱する概略を示すフローチャートである。
【０１３０】
ステップ１４０２において、現用系サーバからのハートビートを待機する。
【０１３１】
ステップ１４０４において、現用系サーバからのハートビートを受信する。
【０１３２】
ステップ１４０６において、受信したハートビートから業務サービス生存情報を参照する。なお、業務サービス生存情報は、クライアント１８０からのマルチキャストされる電文からも得ることができる。いずれのルートを用いてもよい。
【０１３３】
ステップ１４０８において、自サーバが監視・バックアップサイトのサーバであるかが、チェックされる。このチェックは、業務サービス生存情報テーブル（３）２８５のサーバの場所を確認し、現用サイト１１０であるか監視・バックアップサイト１５０であるかの情報を参照して判定できる。このチェックによって、現用サイト１１０に存在するサーバが、能動的にクラスタシステム１１０Ｚから離脱してしまうことを防止できる。この判断が「いいえ」であれば、ステップ１４０２に戻る。この判断が「はい」であれば、ステップ１４１０に移る。
【０１３４】
ステップ１４１０において、現用サイトのクラスタシステム１１０Ｚで故障したサーバが復旧されている、または、新たなサーバが追加されているかが判断される。この判断は、業務サービス生存情報テーブル（３）２８５から業務サービス生存情報を参照し、稼働可能な現用サイト１１０のサーバ数が２以上となっているかで判断できる。この場合には、現用サイト１１０における単一障害点が解消していることを示している。この判断が「いいえ」であれば、ステップ１４０２に戻る。この判断が「はい」であれば、ステップ１４１２に移る。
【０１３５】
ステップ１４１２において、現用サイトのクラスタシステム１１０Ｚに対し、自サーバの離脱要求を送信する（１１０１）。この離脱要求は、能動的に実行されることが望ましい。この処理によって、離脱が行われる。
【０１３６】
ステップ１４１４において、監視・バックアップサイト１５０のクラスタシステムに自サーバが参入する。この参入は能動的に行われることが望ましい。このクラスタシステムは、過去に参入していたクラスタシステムに復帰するものであってもよい。あるいは、新しいクラスタシステムに参入してもよい。あるいは、監視・バックアップサイト１５０に、参入すべきクラスタシステムがない場合には、参入の処理を行わなくてもよい。
【０１３７】
ステップ１４１６において、業務サービス生存情報テーブル（３）２８５の業務サービス生存情報から、離脱した監視・バックアップサイトのサーバ（自サーバ）を削除し、復旧した現用サイトのサーバを追加する。
【０１３８】
ステップ１４１８において、業務サービス生存情報テーブル（３）２８５のサーバ状態取得時刻を現在時刻に更新する。
【０１３９】
ステップ１４２０において、クライアント制御部２２０からの電文を受信する。
【０１４０】
ステップ１４２２において、クライアント制御部２２０に返信する電文を作成する。
【０１４１】
ステップ１４２４において、呼び出し元のクライアント１８０に返信する電文に業務サービス生存情報テーブル（３）２８５に保存された業務サービス生存情報を付加し、呼び出し元のクライアント１８０に応答電文を返信する。この処理によって、クライアント１８０が管理している業務サービス生存情報テーブル（１）２１５が更新される。
【０１４２】
以上の処理によって、離脱が完了する。なお、離脱する自サーバが、現用系サーバである場合には、上記の処理に加えて、フェイルオーバの処理がなされる。
【０１４３】
以上のように、本実施形態を利用することによって、現用サイトの業務サービスの停止という最悪の事態を簡便な形で回避することができる。また、クラスタシステムの監視においては、ネットワークＮＷへの負荷を可能な限り軽減することが可能である。また、クラスタシステムが正常動作している場合、監視・バックアップサイト１５０の予備サーバを、他の業務でも有効活用することができる。
【０１４４】
図１５は、クライアント及びサーバのハードウェア構成を示している。クライアント及びサーバは、ＣＰＵ１５１０、メモリ１５１５、入力装置１５２０、出力装置１５２５、外部記憶装置１５３０、可搬記録媒体駆動装置１５３５、ネットワーク接続装置１５４５が含まれる。そして、それぞれの機器は、バス１５５０によって接続されている。また、可搬記録媒体駆動装置１５３５は、可搬記録媒体１５４０を読み書きすることができる。そして、ネットワーク接続装置１５４５には、インターネット１５６０及び専用線１５６１が接続されている。
【０１４５】
なお、本実施形態のプログラムは、可搬記録媒体１５４０に格納することができる。可搬記録媒体１５４０とは、構造（structure）を有する１つ以上の非一時的（non-transitory）な、有形（tangible）な、記憶媒体を言う。例示として、可搬記録媒体１５４０としては、磁気記録媒体、光ディスク、光磁気記録媒体、不揮発性メモリなどがある。磁気記録媒体には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープ（ＭＴ）などがある。光ディスクには、ＤＶＤ（Digital  Versatile  Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact  Disc-Read  Only  Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。また、光磁気記録媒体には、ＭＯ（Magneto-Optical  disk）などがある。
【０１４６】
なお、請求項に記載された方法やプログラムに係る発明は、矛盾のない限り処理の順番を入れ替えてもよく、あるいは、複数の処理を同時に実施してもよい。そして、これらの実施形態も、請求項に記載された発明の技術的範囲に包含されることは言うまでもない。
【０１４７】
上記実施形態に関し、以下の付記を開示する。
（付記１）
クライアント装置によって収集された、第１のサーバ装置の状態と前記第１のサーバ装置の障害時に稼働する１以上の待機系サーバ装置の状態とを含む、状態情報を、第２のサーバ装置が、前記クライアント装置から受信し、
前記状態情報が所定の第１の状態を表している場合、前記第２のサーバ装置が、前記第２のサーバ装置を前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作させる、
処理をコンピュータに実行させるプログラム。
（付記２）
前記所定の第１の状態は、前記第１のサーバ装置及び前記１以上の待機系サーバ装置のうち稼働することができる装置の数が1以下の状態である、付記１記載のプログラム。
（付記３）
前記動作させる処理は、
前記第２のサーバ装置が、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作している場合であって、前記状態情報が所定の第２の状態を表している場合、前記第２のサーバ装置による、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置としての動作を終了させる、
処理を含む付記１又は２記載のプログラム。
（付記４）
前記所定の第２の状態は、前記第１のサーバ装置及び前記１以上の待機系サーバ装置のうち稼働することができる装置の数が２以上の状態である、付記１ないし３のうちいずれか１項記載のプログラム。
（付記５）
前記状態情報は、前記第１のサーバ装置が前記クライアント装置に提供する１以上の業務の各々に対応して存在する、付記１ないし４のうちいずれか１項記載のプログラム。
（付記６）
前記第２のサーバ装置が複数存在する場合、予め定められた選択基準に従って選択された１つの前記第２のサーバ装置が、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作する、
処理をコンピュータに実行させる付記１ないし５のうちいずれか１項記載のプログラム。
（付記７）
前記予め定められた選択基準は、複数の前記第２のサーバ装置のうち、業務への利用のための優先度の値が最も小さい値である、付記１ないし６のうちいずれか１項記載のプログラム。
（付記８）
クライアント装置によって収集された、第１のサーバ装置の状態と前記第１のサーバ装置の障害時に稼働する１以上の待機系サーバ装置の状態とを含む、状態情報を、第２のサーバ装置が、前記クライアント装置から、受信し、
前記状態情報が所定の第１の状態を表している場合、前記第２のサーバ装置が、前記第２のサーバ装置を前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作させる、
処理を有する方法。
（付記９）
前記所定の第１の状態は、前記第１のサーバ装置及び前記１以上の待機系サーバ装置のうち稼働することができる装置の数が1以下の状態である、付記８記載の方法。
（付記１０）
前記動作させる処理は、
前記第２のサーバ装置が、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作している場合であって、前記状態情報が所定の第２の状態を表している場合、前記第２のサーバ装置による、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置としての動作を終了させる、
処理を有する付記８又は９記載の方法。
（付記１１）
前記所定の第２の状態は、前記第１のサーバ装置及び前記１以上の待機系サーバ装置のうち稼働することができる装置の数が２以上の状態である、付記８ないし１０のうちいずれか１項記載の方法。
（付記１２）
前記状態情報は、前記第１のサーバ装置が前記クライアント装置に提供する１以上の業務の各々に対応して存在する、付記８ないし１１のうちいずれか１項記載の方法。
（付記１３）
前記第２のサーバ装置が複数存在する場合、予め定められた選択基準に従って選択された１つの前記第２のサーバ装置が、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作する、
処理を有する付記８ないし１２のうちいずれか１項記載の方法。
（付記１４）
前記予め定められた選択基準は、複数の前記第２のサーバ装置のうち、業務への利用のための優先度の値が最も小さい値である、付記８ないし１３のうちいずれか１項記載の方法。
（付記１５）
クライアント装置によって収集された、第１のサーバ装置の状態と前記第１のサーバ装置の障害時に稼働する１以上の待機系サーバ装置の状態とを含む、状態情報を、第２のサーバ装置が、前記クライアント装置から受信するサーバ状態受信部と、
前記状態情報が所定の第１の状態を表している場合、前記第２のサーバ装置が、前記第２のサーバ装置を前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作させる動作制御部と、
を有するシステム。
（付記１６）
前記所定の第１の状態は、前記第１のサーバ装置及び前記１以上の待機系サーバ装置のうち稼働することができる装置の数が1以下の状態である、付記１５記載のシステム。
（付記１７）
前記動作制御部は、
前記第２のサーバ装置が、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作している場合であって、前記状態情報が所定の第２の状態を表している場合、前記第２のサーバ装置による、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置としての動作を終了させる、
付記１５又は１６記載のシステム。
（付記１８）
前記所定の第２の状態は、前記第１のサーバ装置及び前記１以上の待機系サーバ装置のうち稼働することができる装置の数が２以上の状態である、付記１５ないし１７のうちいずれか１項記載のシステム。
（付記１９）
前記状態情報は、前記第１のサーバ装置が前記クライアント装置に提供する１以上の業務の各々に対応して存在する、付記１５ないし１８のうちいずれか１項記載のシステム。
（付記２０）
前記第２のサーバ装置が複数存在する場合、予め定められた選択基準に従って選択された１つの前記第２のサーバ装置が、前記第１のサーバ装置及び／又は前記１以上の待機系サーバ装置の障害時のためのサーバ装置として動作させる動作選択部、
を有する付記１５ないし１９のうちいずれか１項記載のシステム。
（付記２１）
前記予め定められた選択基準は、複数の前記第２のサーバ装置のうち、業務への利用のための優先度の値が最も小さい値である、付記１５ないし２０のうちいずれか１項記載のシステム。
【符号の説明】
【０１４８】
１１０    現用サイト
１５０    監視・バックアップサイト
１８０    クライアント
２１０    クライアント用業務Ｚ処理部
２１５    業務サービス生存情報テーブル（１）
２２０    クライアント制御部
２２２    受信部
２２４    処理要求電文生成部
２２６    制御電文生成部
２２８    送信部
２２９    マルチキャスト送信部
２５０    サーバ制御部
２５２    サーバ状態送信部
２５４    業務サービス生存情報削除部
２６０    サーバ用業務Ｚ処理部
２６５    業務サービス生存情報テーブル（２）
２６７    専用線
２８０    サーバ制御部
２８２    サーバ状態受信部
２８４    動作制御部
２８５    業務サービス生存情報テーブル（３）
１１８６  動作選択部
【図１】
2013161252.tif 000003
【図２】
2013161252.tif 000004
【図３】
2013161252.tif 000005
【図４】
2013161252.tif 000006
【図５】
2013161252.tif 000007
【図６】
2013161252.tif 000008
【図７】
2013161252.tif 000009
【図８】
2013161252.tif 000010
【図９】
2013161252.tif 000011
【図１０】
2013161252.tif 000012
【図１１】
2013161252.tif 000013
【図１２】
2013161252.tif 000014
【図１３】
2013161252.tif 000015
【図１４】
2013161252.tif 000016
【図１５】
2013161252.tif 000017