JP5982842B2 - コンピュータ障害監視プログラム、方法、及び装置 - Google Patents

Description

本発明は、コンピュータ障害監視プログラム、方法、及び装置に関する。

近年のサーバシステムの高度化に伴い、オンラインシステムでは、２４時間３６５日停止することのない高い信頼性と可用性が求められている。システムの可用性を向上させるためには、システムを構成するサーバを冗長化する方策が挙げられる。この冗長化によって、あるサーバが故障した場合においても、他のサーバが業務を引き継ぐことで、業務サービスの停止を防止することができる。また、故障したサーバの業務サービスへの影響を最小限にするために、速やかに故障したサーバを切り離し、正常なサーバで業務サービスを継続させることができる。

システムを構成するサーバを冗長化するための上記のような技術として、クラスタシステムがある。代表的なクラスタシステムとしては、ＨＡクラスタとフェイルオーバクラスタがある。

ＨＡ（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）などがある。

なお、請求項に記載された方法やプログラムに係る発明は、矛盾のない限り処理の順番を入れ替えてもよく、あるいは、複数の処理を同時に実施してもよい。そして、これらの実施形態も、請求項に記載された発明の技術的範囲に包含されることは言うまでもない。

上記実施形態に関し、以下の付記を開示する。
（付記１）
第１のサーバ装置に対する処理要求に、記憶部に記憶された前記第１のサーバ装置の状態を表す情報を含む状態情報を含ませた処理要求電文を生成し、
前記処理要求電文を、前記第１のサーバ装置と、前記第１のサーバ装置を監視する第２のサーバ装置とに送信し、
前記第１のサーバ装置から新たな状態情報を受信する、
処理をクライアント装置に実行させるプログラム。
（付記２）
前記状態情報は、処理要求電文に対する前記第１のサーバからの応答電文に含まれる、
付記１記載のプログラム。
（付記３）
前記状態情報は、前記第１のサーバ装置の障害時に稼働する待機系サーバ装置の状態を表す情報を含む、付記１又は２項記載のプログラム。
（付記４）
前記送信する処理は、マルチキャストにより送信する処理を含む、付記１ないし３のうちいずれか１項記載のプログラム。
（付記５）
前記状態情報は、前記第１のサーバ装置により前記クライアント装置に提供される業務サービスの状態を含む、付記１ないし４のうちいずれか１項記載のプログラム。
（付記６）
前記処理要求電文が、前記状態情報を、前記クライアント装置に送信するよう要求する命令を含む、
付記１ないし５のうちいずれか１項記載のプログラム。
（付記７）
前記クライアント装置が前記第２のサーバ装置に電文を最後に送信した時刻から、所定の時間が経過した場合であって、前記最後に送信した前記処理要求電文に含まれていた前記状態情報と、現在の前記状態情報とが異なる場合、現在の前記状態情報を含む制御電文を生成し、
前記制御電文を少なくとも前記第２のサーバに送信する、
処理をクライアント装置に更に実行させる、付記１ないし６のうちいずれか１項記載のプログラム。
（付記８）
第１のサーバ装置が、前記第１のサーバ装置の状態を表す情報を含む状態情報をクライアント装置に送信し、
前記第１のサーバ装置を監視する第２のサーバ装置が、前記クライアント装置から、前記状態情報を含む前記第１のサーバ装置への処理要求電文を受信する、
処理を、前記第１のサーバ及び前記第２のサーバに実行させるプログラム。
（付記９）
前記状態情報は、前記第１のサーバ装置の障害時に稼働する待機系サーバ装置の状態を表す情報を含む、付記８記載のプログラム。
（付記１０）
クライアント装置が、
第１のサーバ装置に対する処理要求に、記憶部に記憶された前記第１のサーバ装置の状態を表す情報を含む状態情報を含ませた処理要求電文を生成し、
前記処理要求電文を、前記第１のサーバ装置と、前記第１のサーバ装置を監視する第２のサーバ装置とに送信し、
前記第１のサーバ装置から新たな状態情報を受信する、
処理を有する方法。
（付記１１）
前記状態情報は、処理要求電文に対する前記第１のサーバからの応答電文に含まれる、
付記１０記載の方法。
（付記１２）
前記状態情報は、前記第１のサーバ装置の障害時に稼働する待機系サーバ装置の状態を表す情報を含む、付記１０又は１１記載の方法。
（付記１３）
前記送信する処理は、マルチキャストにより送信する処理を含む、付記１０ないし１２のうちいずれか１項記載の方法。
（付記１４）
前記状態情報は、前記第１のサーバ装置により前記クライアント装置に提供される業務サービスの状態を含む、付記１０ないし１３のうちいずれか１項記載の方法。
（付記１５）
前記処理要求電文が、前記状態情報を、前記クライアント装置に送信するよう要求する命令を含む、
付記１０ないし１４のうちいずれか１項記載の方法。
（付記１６）
前記クライアント装置が前記第２のサーバ装置に電文を最後に送信した時刻から、所定の時間が経過した場合であって、前記最後に送信した前記処理要求電文に含まれていた前記状態情報と、現在の前記状態情報とが異なる場合、現在の前記状態情報を含む制御電文を生成し、
前記制御電文を少なくとも前記第２のサーバに送信する、
処理を更に有する付記１０ないし１５のうちいずれか１項記載の方法。
（付記１７）
第１のサーバ装置が、前記第１のサーバ装置の状態を表す情報を含む状態情報をクライアント装置に送信し、
前記第１のサーバ装置を監視する第２のサーバ装置が、前記クライアント装置から、前記状態情報を含む前記第１のサーバ装置への処理要求電文を受信する、
処理を有する方法。
（付記１８）
前記状態情報は、前記第１のサーバ装置の障害時に稼働する待機系サーバ装置の状態を表す情報を含む、付記１７記載の方法。
（付記１９）
第１のサーバ装置に対する処理要求に、記憶部に記憶された前記第１のサーバ装置の状態を表す情報を含む状態情報を含ませた処理要求電文を生成する処理要求電文生成部と、
前記処理要求電文を、前記第１のサーバ装置と、前記第１のサーバ装置を監視する第２のサーバ装置とに送信する送信部と、
前記第１のサーバ装置から新たな状態情報を受信する受信部と、
を有するクライアント装置。
（付記２０）
前記状態情報は、処理要求電文に対する前記第１のサーバからの応答電文に含まれる、
付記１９記載のクライアント装置。
（付記２１）
前記状態情報は、前記第１のサーバ装置の障害時に稼働する待機系サーバ装置の状態を表す情報を含む、付記１９又は２０記載のクライアント装置。
（付記２２）
前記送信部は、マルチキャストにより送信するマルチキャスト送信部を含む、付記１９ないし２１のうちいずれか１項記載のクライアント装置。
（付記２３）
前記状態情報は、前記第１のサーバ装置により前記クライアント装置に提供される業務サービスの状態を含む、付記１８ないし２２のうちいずれか１項記載のクライアント装置。
（付記２４）
前記処理要求電文が、前記状態情報を、当該クライアント装置に送信するよう要求する命令を含む、
付記１９ないし２３のうちいずれか１項記載のクライアント装置。
（付記２５）
当該クライアント装置が前記第２のサーバ装置に電文を最後に送信した時刻から、所定の時間が経過した場合であって、前記最後に送信した前記処理要求電文に含まれていた前記状態情報と、現在の前記状態情報とが異なる場合、現在の前記状態情報を含む、制御電文を生成する制御電文生成部、
を有し、
前記送信部は、前記制御電文を少なくとも前記第２のサーバに送信する、
付記１９ないし２４のうちいずれか１項記載のクライアント装置。
（付記２６）
第１のサーバ装置が、前記第１のサーバ装置の状態を表す情報を含む状態情報をクライアント装置に送信するサーバ状態送信部と、
前記第１のサーバ装置を監視する第２のサーバ装置が、前記クライアント装置から、前記状態情報を含む前記第１のサーバ装置への処理要求電文を受信するサーバ状態受信部、
を有するシステム。
（付記２７）
前記状態情報は、前記第１のサーバ装置の障害時に稼働する待機系サーバ装置の状態を表す情報を含む、付記２６記載のシステム。

１１０ 現用サイト
１５０ 監視・バックアップサイト
１８０ クライアント
２１０ クライアント用業務Ｚ処理部
２１５ 業務サービス生存情報テーブル（１）
２２０ クライアント制御部
２２２ 受信部
２２４ 処理要求電文生成部
２２６ 制御電文生成部
２２８ 送信部
２２９ マルチキャスト送信部
２５０ サーバ制御部
２５２ サーバ状態送信部
２５４ 業務サービス生存情報削除部
２６０ サーバ用業務Ｚ処理部
２６５ 業務サービス生存情報テーブル（２）
２６７ 専用線
２８０ サーバ制御部
２８２ サーバ状態受信部
２８４ 動作制御部
２８５ 業務サービス生存情報テーブル（３）
１１８６ 動作選択部

Claims (11)

1. 業務処理要求を第１のサーバ装置へ送信する際に、クライアント装置に記憶された状態情報を添付することによって処理要求電文を生成する処理であって、前記状態情報は、前記第１のサーバ装置から受信された前記第１のサーバ装置の状態を示す情報を含み、前記第１のサーバ装置を監視する第２のサーバ装置であって、前記第１のサーバ装置の業務サービスを即座に引き継ぐクラスタシステムに属さず、前記第１のサーバ装置の前記業務サービスを行うための資源を有する前記第２のサーバ装置に、送信される、処理と、
   前記処理要求電文を、前記第１のサーバ装置と、前記第２のサーバ装置とに送信する処理と、
   前記第１のサーバ装置から前記第１のサーバ装置の新たな状態情報を受信し、前記クライアント装置に記憶された前記状態情報を前記新たな状態情報に更新する処理と、
   を前記クライアント装置に実行させるプログラムであって、
   更新された前記新たな状態情報は、次の処理要求電文によって前記第１のサーバ装置と、前記第２のサーバ装置とに送信されるようにしたプログラム。
2. 前記状態情報は、前記処理要求電文に対する前記第１のサーバ装置からの応答電文に含まれる、
   請求項１記載のプログラム。
3. 前記状態情報は、前記第１のサーバ装置の障害時に稼働する前記クラスタシステムに属する待機系サーバ装置の状態を表す情報を含む、請求項１又は２に記載のプログラム。
4. 前記送信する処理は、マルチキャストにより送信する処理を含む、請求項１ないし３のうちいずれか１項記載のプログラム。
5. 前記状態情報は、前記第１のサーバ装置により前記クライアント装置に提供される業務サービスの状態を含む、請求項１ないし４のうちいずれか１項記載のプログラム。
6. 前記処理要求電文が、前記状態情報を、前記クライアント装置に送信するよう要求する命令を含む、
   請求項１ないし５のうちいずれか１項記載のプログラム。
7. 前記クライアント装置が前記第２のサーバ装置に電文を最後に送信した時刻から、所定の時間が経過した場合であって、前記最後に送信した前記処理要求電文に含まれていた前記状態情報と、現在の前記状態情報とが異なる場合、現在の前記状態情報を含む制御電文を生成し、
   前記制御電文を少なくとも前記第２のサーバ装置に送信する、
   処理をクライアント装置に更に実行させる、請求項１ないし６のうちいずれか１項記載のプログラム。
8. クライアント装置が、
   業務処理要求を第１のサーバ装置へ送信する際に、クライアント装置に記憶された状態情報を添付することによって処理要求電文を生成する処理であって、前記状態情報は、前記第１のサーバ装置から受信された前記第１のサーバ装置の状態を示す情報を含み、前記第１のサーバ装置を監視する第２のサーバ装置であって、前記第１のサーバ装置の業務サービスを即座に引き継ぐクラスタシステムに属さず、前記第１のサーバ装置の前記業務サービスを行うための資源を有する前記第２のサーバ装置に、送信される、処理と、
   前記処理要求電文を、前記第１のサーバ装置と、前記第２のサーバ装置とに送信する処理と、
   前記第１のサーバ装置から前記第１のサーバ装置の新たな状態情報を受信し、前記クライアント装置に記憶された前記状態情報を前記新たな状態情報に更新する処理と、
   を有する方法であって、
   更新された前記新たな状態情報は、次の処理要求電文によって前記第１のサーバ装置と、前記第２のサーバ装置とに送信されるようにした方法。
9. 第１のサーバ装置が、業務処理要求と、クライアント装置に記憶された状態情報と、を含む処理要求電文を、前記クライアント装置から受信する処理と、
   前記第１のサーバ装置が、前記処理要求電文に対する業務処理応答を前記クライアント装置へ送信する際に、前記第１のサーバ装置に格納された新たな状態情報を前記業務処理応答に添付することによって応答電文を生成する処理と、
   前記第１のサーバ装置が、前記処理要求電文の送信元である前記クライアント装置に前記応答電文を送信する第１の処理と、
   前記クライアント装置が、前記状態情報を、前記新たな状態情報に更新する処理と、
   前記クライアント装置が、前記新たな状態情報を含む処理要求電文を、前記第１のサーバと、前記第１のサーバ装置を監視する第２のサーバ装置であって、前記第１のサーバ装置の業務サービスを即座に引き継ぐクラスタシステムに属さず、前記第１のサーバ装置の前記業務サービスを行うための資源を有する前記第２のサーバ装置とに、送信する第２の処理と、
   を有する方法。
10. クライアント装置であって、
    業務処理要求を第１のサーバ装置へ送信する際に、前記クライアント装置に記憶された状態情報を添付することによって処理要求電文を生成する処理要求電文生成部であって、前記状態情報は、前記第１のサーバ装置から受信された前記第１のサーバ装置の状態を示す情報を含み、前記第１のサーバ装置を監視する第２のサーバ装置であって、前記第１のサーバ装置の業務サービスを即座に引き継ぐクラスタシステムに属さず、前記第１のサーバ装置の前記業務サービスを行うための資源を有する前記第２のサーバ装置に、送信される、処理要求電文生成部と、
    前記処理要求電文を、前記第１のサーバ装置と、前記第２のサーバ装置とに送信する送信部と、
    前記第１のサーバ装置から前記第１のサーバ装置の新たな状態情報を受信し、前記クライアント装置に記憶された前記状態情報を前記新たな状態情報に更新する更新部と、
    を有するクライアント装置であって、
    更新された前記新たな状態情報は、次の処理要求電文によって前記第１のサーバ装置と、前記第２のサーバ装置とに送信されるようにしたクライアント装置。
11. 第１のサーバ装置と、クライアント装置とを有するシステムであって、
    前記第１のサーバ装置は、
    業務処理要求と、クライアント装置に記憶された状態情報と、を含む処理要求電文を、前記クライアント装置から受信する受信部と、
    前記処理要求電文に対する業務処理応答を前記クライアント装置へ送信する際に、前記第１のサーバ装置に格納された新たな状態情報を前記業務処理応答に添付することによって応答電文を生成する応答電文生成部と、
    前記処理要求電文の送信元である前記クライアント装置に前記応答電文を送信する第１の送信部と、
    を含み、
    前記クライアント装置は、
    前記状態情報を、前記新たな状態情報に更新する更新部と、
    前記新たな状態情報を含む処理要求電文を、前記第１のサーバと、前記第１のサーバ装置を監視する第２のサーバ装置であって、前記第１のサーバ装置の業務サービスを即座に引き継ぐクラスタシステムに属さず、前記第１のサーバ装置の前記業務サービスを行うための資源を有する前記第２のサーバ装置とに、送信する第２の送信部と、
    を含む、
    システム。

Images