特許 5707355 ホットスタンバイ方式によるクライアントサーバシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5707355

(24)【登録日】2015年3月6日

(45)【発行日】2015年4月30日

(54)【発明の名称】ホットスタンバイ方式によるクライアントサーバシステム

(51)【国際特許分類】

   G06F 11/20 20060101AFI20150409BHJP

【ＦＩ】

   G06F11/20 310C

【請求項の数】7

【全頁数】18

(21)【出願番号】特願2012-56245(P2012-56245)

(22)【出願日】2012年3月13日

(65)【公開番号】特開2013-190955(P2013-190955A)

(43)【公開日】2013年9月26日

【審査請求日】2014年2月3日

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(73)【特許権者】

【識別番号】301063496

【氏名又は名称】東芝ソリューション株式会社

(74)【代理人】

【識別番号】100087398

【弁理士】

【氏名又は名称】水野 勝文

(74)【代理人】

【識別番号】100067541

【弁理士】

【氏名又は名称】岸田 正行

(74)【代理人】

【識別番号】100103506

【弁理士】

【氏名又は名称】高野 弘晋

(74)【代理人】

【識別番号】100105072

【弁理士】

【氏名又は名称】小川 英宣

(72)【発明者】

【氏名】新井 浩

(72)【発明者】

【氏名】茅沼 英司

(72)【発明者】

【氏名】山中 恭介

(72)【発明者】

【氏名】畑田 健太郎

(72)【発明者】

【氏名】瀧口 彬子

【審査官】 ▲高▼橋 正▲徳▼

(56)【参考文献】

【文献】 特開２００９−０８０７０４（ＪＰ，Ａ）

【文献】 特開平０８−１０６４２６（ＪＰ，Ａ）

【文献】 特開２００５−３３９３１５（ＪＰ，Ａ）

【文献】 特開平０３−１２６１３９（ＪＰ，Ａ）

【文献】 特開２００１−２８２７６２（ＪＰ，Ａ）

【文献】 特開２００８−２８７６３２（ＪＰ，Ａ）

【文献】 特開２０１０−１７６５１１（ＪＰ，Ａ）

【文献】 森 良哉, 小林 茂, 金子 哲夫, 原 修一，ＰＣサーバ・クラスタ −アベイラビリティ（可用性）向上をねらって−，情報処理 第３９巻 第１号，日本，社団法人情報処理学会，１９９８年 １月１５日，第39巻, 第1号，pp.49-54

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／１６−１１／２０，

Ｇ０６Ｆ １１／２８−１１／３４，

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

クライアント端末と通信可能な主系サーバ及び従系サーバを含み、片系に障害が発生すると他系のサーバを主従系サーバとして動作させるホットスタンバイ方式のクライアントサーバシステムであって、
前記主系サーバは、クライアント端末のリクエストを受信及び処理し、該処理データを前記従系サーバに送信し、前記従系サーバは、受信された処理データを前記クライアント端末に転送し、
各サーバは、
他系サーバとハートビートを送受信し、他系の状態を検出するハートビート監視部と、
業務アプリケーションの稼働時に業務ハートビートを送受信し、他系の業務アプリケーションの状態を検出する業務ハートビート監視部と、
前記ハートビート監視部及び前記業務ハートビート監視部の検出結果に基づいて、自サーバを、前記リクエストの受信及び処理、前記処理データの前記クライアント端末への送信を行う主従系サーバとして動作するように切り替える切り替え部と、
を備えるクライアントサーバシステム。

【請求項2】

前記切り替え部は、監視開始命令を受信するまでは、前記ハートビート監視部及び前記業務ハートビート監視部の検出結果に関わらず、前記主従系サーバへの切り替えが禁止される請求項１記載のクライアントサーバシステム。

【請求項3】

前記従系サーバは、前記受信された処理データを前記クライアント端末に転送するとともにデータベースに保存し、
前記切り替え部は、自サーバを、さらに、前記処理結果データのデータベースへの保存を行うように動作させる請求項１又は２に記載のクライアントサーバシステム。

【請求項4】

前記切り替え部は、前記ハートビート及び前記業務ハートビートの両方の受信が途絶されると、自サーバを前記主従系サーバに切り替える請求項１乃至３のいずれか一項に記載のクライアントサーバシステム。

【請求項5】

前記ハートビートには自サーバのステータス情報が含まれ、
前記ハートビート監視部は、自サーバの業務アプリケーションが停止すると、該停止を示すステータス情報を含めたハートビートを送信し、
前記切り替え部は、前記停止を示すステータス情報のハートビートが受信されると前記業務ハートビートの受信の有無をチェックし、業務ハートビートの受信が途絶されると、自サーバを前記主従系サーバに切り替える請求項４に記載のクライアントサーバシステム。

【請求項6】

クライアント端末と通信可能な主系サーバ及び従系サーバを含み、片系に障害が発生すると他系のサーバを主従系サーバに切り替えるホットスタンバイ方式のクライアントサーバシステムにおける切り替え制御方法であって、
前記主系サーバは、クライアント端末のリクエストを受信及び処理し、該処理データを前記従系サーバに送信し、前記従系サーバは、受信された処理データを前記クライアント端末に転送し、
各サーバは、
他系サーバとハートビートを送受信して他系の状態を検出するハートビート監視ステップと、
業務アプリケーションの稼働時に業務ハートビートを送受信して他系の業務アプリケーションの状態を検出する業務ハートビート監視ステップと、
前記ハートビート監視ステップ及び前記業務ハートビート監視ステップでの検出結果に基づいて、自サーバを、前記リクエストの受信及び処理、前記処理データの前記クライアント端末への送信を行う主従系サーバとして動作するように切り替える切り替えステップと、
を遂行する切り替え制御方法。

【請求項7】

クライアント端末と通信可能な主系サーバ及び従系サーバを含み、片系に障害が発生すると他系のサーバを主従系サーバに切り替えるホットスタンバイ方式のクライアントサーバシステムにおける制御プログラムであって、
前記主系サーバに、クライアント端末のリクエストを受信及び処理させるとともに、該処理データを前記従系サーバに送信させ、前記従系サーバに、受信された処理データを前記クライアント端末に転送させ、
各サーバに、
他系サーバとハートビートを送受信して他系の状態を検出するハートビート監視ステップと、
業務アプリケーションの稼働時に業務ハートビートを送受信して他系の業務アプリケーションの状態を検出する業務ハートビート監視ステップと、
前記ハートビート監視ステップ及び前記業務ハートビート監視ステップでの検出結果に基づいて、自サーバを、前記リクエストの受信及び処理、前記処理データの前記クライアント端末への送信を行う主従系サーバとして動作するように切り替える切り替えステップと、
を遂行させるための制御プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、情報システムの信頼性向上技術であって、ホットスタンバイ構成によるクライアントサーバシステムに関する。

【背景技術】

【0002】

クライアントサーバシステムにおける従来のホットスタンバイ方法として、スレーブシステム（クライアント端末）がマスタシステム（稼働系サーバ）とスタンバイシステム（待機系サーバ）に対して各々に同一のデータを出力し、稼働系サーバがクライアント端末に対してデータにインデックスを付けて応答するものが知られている（例えば特許文献１）。このシステムでは、待機系サーバも稼働系サーバと同様のインデックスを付けたデータをバッファに書き込み、稼働系サーバがダウンした際は、クライアント端末より受け取るダウン直前のインデックスを元にそれ以降のデータを待機系サーバに応答する方式となっていた。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１０−１７６５１１号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

各系サーバによる業務の２重処理を防止し、応答レスポンス特性の向上が図られたホットスタンバイ方式のクライアントサーバシステムを提供する。

【課題を解決するための手段】

【0005】

実施形態の一側面は、クライアント端末とネットワーク経由で通信可能な主系サーバ及び従系サーバを含み、片系に障害が発生すると他系のサーバを主従系サーバとして動作させるホットスタンバイ方式のクライアントサーバシステムであって、主系サーバは、クライアント端末のリクエストを受信及び処理し、該処理データを従系サーバに送信し、従系サーバは、受信された処理データをクライアント端末に転送し、各サーバは、他系サーバとハートビートを送受信し、他系の状態を検出するハートビート監視部と、業務アプリケーションの稼働時に業務ハートビートを送受信し、他系の業務アプリケーションの状態を検出する業務ハートビート監視部と、ハートビート監視部及び業務ハートビート監視部の検出結果に基づいて、自サーバを、リクエストの受信及び処理、処理データのクライアント端末への送信を行う主従系サーバとして動作するように切り替える切り替え部と、を備える。

【図面の簡単な説明】

【0006】

【図1】第１実施形態のホットスタンバイ機能を備えたクライアント／サーバ型システムの構成を示すブロック図である。

【図2】図１のシステムでサーバのハートビート伝送機能に障害が発生した場合の動作を説明する図である。

【図3】従系サーバが主従系サーバに切り替わる場合を説明する図である。

【図4】主系サーバが主従系サーバに切り替わる場合を説明する図である。

【図5】ハートビート電文のステータスと業務ハートビートの状態の組合せに基づく処理を説明するための表である。

【図6】ハートビート電文の送信に関する処理を説明するフローチャートである。

【図7】他系サーバに対する監視及び主従系サーバへの切り替えの処理に関するフローチャートである。

【図8】通常状態における主系サーバと従系サーバとクライアント端末との通信を説明するための設定テーブルである。

【図9】従系サーバが主従系サーバに切り替わる場合の設定テーブルの書き換えを示す図である。

【図10】主系サーバが主従系サーバに切り替わる場合の設定テーブルの書き換えを示す図である。

【図11】第２の実施形態を説明するフローチャートである。

【発明を実施するための形態】

【0007】

以下、実施形態のホットスタンバイ方式のクライアントサーバシステムの概要を説明する。

【0008】

上述した従来のホットスタンバイ方式は、マスタシステムとスタンバイシステムが非同期であることから、マスタシステム（稼働系サーバ）とスタンバイシステム（待機系サーバ）でデータとインデックスが合致している保証がないものであった。

【0009】

他方、従来の他のホットスタンバイ方式として、２台ペアのサーバで主系・従系を構成し、主系サーバがクライアント端末より受信したデータを従系サーバに同期させた後に、主系サーバからクライアント応答を送信することで主系・従系のデータを保証するシステムがあり、このようなシステムでは、主系・従系の監視方法として、各サーバがハートビートを送受信することで実現していた。

【0010】

しかしながら、このようなシステムでは、クライアント端末から受信したデータを従系に同期させた後に主系でクライアント応答を送信していた、すなわちデータの流れがクライアント端末⇒主系サーバ⇒従系サーバ⇒主系サーバ⇒クライアント端末であったことから、応答レスポンスが遅いという技術的課題があった。また、このようなシステムでは、ハートビートの機能に障害が発生した場合、他系の生存監視が不能となり、本来不要なサーバ切り替え処理によって両系のサーバで主系業務を実行してしまう可能性があるという技術的課題があった。さらに、このようなシステムでは、片系のサーバに起動障害が生じた場合には他系のサーバが主従系として稼働するため、その後に主系・従系で起動させるには、主従系として動作しているサーバを一旦停止させる必要があり、復旧作業が繁雑になるという技術的課題もあった。

【0011】

本願では上述の課題を解決するため、以下のような構成とする。すなわち、通常（正常）状態では主系サーバでクライアント端末からの要求（リクエスト電文）を受信及び処理し、処理データを従系サーバに転送した後に従系サーバからクライアント応答をするシステムとする。これにより、データの流れ（データ経路）がクライアント端末⇒主系サーバ⇒従系サーバ⇒クライアント端末となるため、応答レスポンスの向上を図ることが可能となる。ここで、クライアント応答を従系サーバで行うことにより、データ経路の観点のみならず、負荷分散の観点から主系サーバの負荷が軽減されるため、システム全体での応答性が向上する。この負荷分散の観点からは、さらに、処理データをデータベースに保存する場合に、かかる保存の処理を従系サーバで行う構成とすることが好ましい。

【0012】

また、本願では、監視プロセスによる従来のハートビートに加え、業務プロセス自身がハートビート（以下、区別のため「業務ハートビート」と称する）を出力することで、他系の業務状態を監視する。これにより、他系の業務状態を判定した上で主従系サーバへの切り替えの判断をすることができるようになり、主系業務の２重処理を防止することが可能となる。

【0013】

さらに、本願では、サーバ起動後に任意の手段でハートビート監視を開始させる構成とする。これにより、ハートビート監視前の障害（起動障害など）の発生時に他系サーバの稼働状況を気にすることなくサーバ再起動等の復旧作業を実施できるようになる。

【0014】

以下、ホットスタンバイ方式のクライアントサーバシステムのより具体的な構成を、図面を参照して説明する。

【0015】

（基本ブロック構成）
図１は、第１実施形態によるホットスタンバイ方式によるクライアントサーバシステムのブロック図である。本実施形態のクライアントサーバシステムは、クライアント端末４０とネットワーク１００経由で通信可能な主系サーバ及び従系サーバを含み、いずれかの系に障害が発生すると他系のサーバを主従系として動作させるホットスタンバイ方式のクライアントサーバシステムであり、図１では簡明のため、サーバ１及びサーバ２の２台のサーバで主系・従系を構成する例を示している。

【0016】

サーバ１及びサーバ２は、ネットワーク１００を介してクライアント端末４０に接続される。なお、各サーバ１，２とクライアント端末４０との接続は、図示しないルータ等を介して行うこともできる。また、ネットワーク１００は、インターネット網、あるいは種々の専用通信網を使用することができる。

【0017】

サーバ１及びサーバ２は、相互に同一の業務アプリケーションが格納（インストール）されており、かかる業務アプリケーションに基づいて、相互に同じ機能（業務）を遂行することができる。但し、起動時及び通常（正常）時にはいずれか一方がクライアント端末４０からのリクエストを受信し処理する主系サーバ、他方が主系サーバの処理結果のデータをクライアント端末４０に転送しデータベース３に保存する従系サーバとして機能する。

【0018】

より具体的には、主系サーバは、業務アプリケーションにアクセスするクライアント端末４０からの要求メッセージ（以下「リクエスト電文」とも称する）を受信して当該リクエスト内容を自サーバ（以下、自ノードともいう）の業務アプリケーションで処理し、リクエスト電文及び処理結果のデータを従系サーバに転送することで、これらデータを従系サーバに同期させ、さらに、従系サーバが主系サーバでの処理結果のデータをクライアント端末４０に転送することでクライアント応答を行い、クライアント端末４０に対してデータサービスを提供する。また、従系サーバは、かかる一連の処理結果をデータベース３に保存する。

【0019】

データベース３に保存されたデータは、両系サーバダウン時のデータ復旧、業務内容の証跡、クライアント端末側とサーバ側とのリコンサイルに使用される。

【0020】

また、本システムでは、片系のサーバ（すなわち主系又は従系サーバ）の業務に障害が発生した場合、他系（従系又は主系）のサーバが主従系サーバとして動作するように切り替える処理を行う。すなわち、主従系サーバとは、片系の障害時に縮退モードで業務を遂行する他系のサーバであり、上述したクライアント端末４０からのリクエストの受信、当該リクエスト内容の業務アプリケーションでの処理、当該処理結果をクライアント端末４０に転送する処理、かかる一連の処理結果をデータベース３に保存する業務を行うサーバである（図３及び図４参照）。本実施形態では、障害の無い他系のサーバが自ノードの業務アプリケーションの設定を変更する（設定テーブルを書き換える）ことで自ノード（自サーバ）を主従系サーバに切り替えるようになっており、この詳細については後述する。

【0021】

本実施形態では、クライアント端末４０、サーバ１及びサーバ２間の通信は、パブリッシュ・サブスクライブのアーキテクチャーを使用してデータの送受信を行う。このため、クライアント端末４０は、通信先を意識せずにデータを送信することが出来、サーバ切り替えにより通信先を変更する処理をクライアント端末４０側で行う必要がなくなる。

【0022】

以下は、特に断りがない限り、初期設定でサーバ１が主系サーバ、サーバ２が従系サーバとしてそれぞれ稼働するように設定された場合を説明する。また、図面では、ハートビートを「ＨＢ」と、アプリケーションを「ＡＰ」と略記している。

【0023】

サーバ１は、ハートビート監視部１１、業務アプリケーション制御部１２、業務アプリケーション切り替え部１３、記憶部１４を有している。ここで、業務アプリケーション制御部１２は、監視部１２１と通信部１２２とを有する。サーバ２も同様に、ハートビート監視部２１、業務アプリケーション制御部２２、業務アプリケーション切り替え部２３、記憶部２４を有しており、この内の業務アプリケーション制御部２２は、監視部２２１と通信部２２２とを有する。記憶部１４及び記憶部２４には、上述したパブリッシュ・サブスクライブのアーキテクチャーに関する設定テーブルが格納され（図８乃至図１０参照）、かかる設定テーブルの詳細については後述する。

【0024】

図１から分かるように、サーバ１とサーバ２では各部の機能が共通するため、以下は主にサーバ１の機能を中心に説明し、サーバ２の各部の説明は適宜省略する。

【0025】

ハートビート監視部１１は、自ノードのハートビートを予め設定した周期毎に他系サーバのハートビート監視部２１に送信し、かつ、ハートビート監視部２１からのハートビートを受信して当該ハートビートが予め設定した周期毎に送られてくるかを監視する。さらに、本実施形態では、自ノードの業務アプリケーションに関するステータス情報をハートビートに含ませるようになっており、これについては後述する。ハートビート監視部１１及びハートビート監視部２１間でのハートビートの送受信は、クライアント端末４０に接続されているネットワーク１００と異なるネットワークセグメントを用いて行う。

【0026】

業務アプリケーション制御部１２は、業務アプリケーションの実行に伴う各種処理を行うものであり、自ノードの系（すなわち主系／従系／主従系）により異なる業務（業務プロセス）を遂行する。業務アプリケーション制御部１２は、監視部１２１及び通信部１２２を含む。この内、監視部１２１は、上述したハートビートとは別個の業務ハートビートを他系サーバとの間で送受信する。

【0027】

より具体的には、監視部１２１は、自ノードの業務アプリケーションが起動すると、予め設定された周期毎に、業務アプリケーションが活性していることを通知する電文（業務ハートビート電文）を他系サーバの監視部２２１に繰り返し送信する。また、監視部１２１は、他系の監視部２２１からの業務ハートビート電文を予め設定された周期毎に受信して、他系の業務アプリケーションの死活を監視する。ここで、監視部１２１は、他系サーバの監視部２２１からの業務ハートビート電文を所定時間受信しなくなると、他系の業務ハートビートが途絶されたものとして業務アプリケーション切り替え部１３に通知する。なお、監視部１２１及び監視部２２１間での業務ハートビート電文の送受信は、クライアント端末４０に接続されているネットワーク１００と異なるネットワークセグメントを用いて行う。

【0028】

図１に示すように、業務ハートビートとハートビートとは相互に別個に送受信される。すなわち、業務ハートビートは業務アプリケーションの業務プロセスの一部として業務ハートビート監視部である監視部１２１及び２２１間で送受信され、ハートビートは監視プロセスの機能としてハートビート監視部１１及び２１間で送受信される。このため、送信周期や送信タイミングなどを業務ハートビートとハートビートとで別個に設定することもできる。これにより、誤検知による誤動作を防止する。

【0029】

さらに、監視部１２１は、自ノードの業務アプリケーションの状態を検出し、かかる検出結果の情報をハートビート監視部１１に提供する。本実施形態では、監視部１２１は、業務アプリケーションが起動中の場合、稼働中の場合、及び自系業務に障害が発生して業務アプリケーションを停止させた場合に、各々その旨の検出情報をハートビート監視部１１に渡す。業務アプリケーションの状態の検出において、監視部１２１は、自系の業務に該当する業務アプリケーションのプロセスに動作確認の確認信号を送信し、業務アプリケーションからの応答信号の有無により、自系の業務の障害の有無を検出する。

【0030】

通信部１２２は、他系サーバの通信部２２２と通信し、ネットワーク１００経由でクライアント端末４０と通信する。また、外部記憶装置（データベース３）へのデータ保存の処理も通信部１２２を介して行う。ここで、通信部１２２及び２２２間での通信は、クライアント端末４０に接続されているネットワーク１００と異なるネットワークセグメントを用いて行う。通信部１２２は、自ノードの系（主系／従系／主従系）により以下のように異なった機能すなわち業務を遂行する。

【0031】

すなわち、自ノードが主系サーバである場合、通信部１２２は、ネットワーク１００を介して業務アプリケーションにアクセスするクライアント端末４０からのリクエスト電文を受信して自ノードの業務アプリケーションに提供し、当該リクエストが業務アプリケーションで処理されると、処理されたデータをリクエスト電文とともに従系サーバに送信する。

【0032】

一方、自ノードが従系サーバである場合、通信部１２２は、主系サーバ（サーバ２）の業務アプリケーションで処理されたデータを通信部２２２から受信し、かかるデータをネットワーク１００を介してクライアント端末４０に送信してリクエストに対する応答を行い、さらに、かかる一連の処理結果を同期済みデータとしてデータベース３に保存する処理を行う。

【0033】

さらに、自ノードが主従系サーバである場合、通信部１２２は、ネットワーク１００を介して業務アプリケーションにアクセスするクライアント端末４０からのリクエスト電文を受信して自ノードの業務アプリケーションに提供し、当該リクエストが業務アプリケーションで処理されると、処理されたデータをネットワーク１００を介してクライアント端末４０に送信してリクエストに対する応答を行い、さらに、かかる一連の処理結果のデータをデータベース３に保存する処理を行う（図３及び図４参照）。

【0034】

次に、ハートビート監視部の機能を詳細に説明する。ハートビート監視部１１は、業務アプリケーション制御部１２の監視部１２１から上述した業務アプリケーションについての検出情報を取得すると、ハートビートを、当該検出情報に対応するステータス情報を含めたメッセージ（以下「ハートビート電文」と称する）の形態で、所定周期毎に他系のハートビート監視部２１に送信する。

【0035】

また、ハートビート監視部１１は、他系サーバのハートビート監視部２１からのハートビート電文を受信すると、当該電文に含まれたステータス情報を業務アプリケーション切り替え部１３に通知する。さらに、ハートビート監視部１１は、他系サーバのハートビート監視部２１からのハートビート電文を所定時間受信しなくなると、他系のハートビートが途絶されたものとして、業務アプリケーション切り替え部１３にハートビートの途絶を通知する。

【0036】

本システムでは、ハートビート電文に含まれる業務アプリケーションのステータス情報として、起動中に対応する「ＳＴＡＲＴＩＮＧ」、稼働中に対応する「ＲＥＡＤＹ」、業務アプリケーションの停止に対応する「ＳｈｕｔＤｏｗｎ」のいずれかが含まれる（図５参照）。

【0037】

業務アプリケーション切り替え部１３は、ハートビート監視部１１及び監視部１２１の検出結果に基づいて、自ノード（自サーバ）を上述した主従系サーバに切り替える処理を行う。すなわち、業務アプリケーション切り替え部１３は、ハートビート監視部１１の検出結果と監視部１２１の検出結果の組合せから、他系（従系又は主系）サーバの業務に障害が発生したか否かを判定し、障害発生したと判定された場合に自ノードが主従系サーバとして動作するように切り替える処理を行う。より詳細には、業務アプリケーション切り替え部１３は、ハートビート監視部１１で他系サーバの障害が検出されると、監視部１２１の検出結果をチェックし、業務ハートビート電文の受信が途絶している場合に、自ノードを主従系サーバに切り替える処理を行う。

【0038】

（基本動作）
以下、初期設定でサーバ１を主系、サーバ２を従系として稼働させる場合の本システムの基本動作について、フローチャートを参照しながら説明する。なお、図６及び図７のフローチャートでは、主系及び従系サーバに共通する処理を示している。

【0039】

本システムでは主系及び従系サーバは各々単独で起動され、個々のサーバの電源投入により、サーバ１及び２内の業務アプリケーションがそれぞれ起動する。電源投入時の起動処理において、各サーバ１のハートビート監視部１１は、監視部１２１の検出情報に基づいて、自ノードの業務状態を示すステータス情報「ＳＴＡＲＴＩＮＧ」を含むハートビート電文を所定周期で他系のサーバ２に送信する（ステップＳ１）。ステップＳ２で、ハートビート監視部１１は、監視部１２１からの検出情報に基づいて、業務アプリケーションの起動処理が完了したかをチェックし、稼働中（すなわち自ノード配下の全プロセスの起動が完了した旨）を監視部１２１から通知されると（ステップＳ２でＹＥＳ）、ハートビート電文中に含めるステータス情報を「ＲＥＡＤＹ」に変更する（ステップＳ３）。

【0040】

また、サーバ１で業務アプリケーションが起動されると、業務アプリケーション制御部１１は、監視部１２１から業務ハートビート電文の送信を開始する。これにより、監視部１２１から他系サーバの監視部２２１に業務ハートビート電文が所定周期で繰り返し伝送される。以上の動作は、従系であるサーバ２でも同様に行われる。

【0041】

以後、主系であるサーバ１は、ネットワーク１００を介して業務アプリケーションにアクセスするクライアント端末４０からのリクエスト電文を通信部１２２で受信し、当該リクエスト内容を自ノードの業務アプリケーション（業務アプリケーション制御部１２）で処理し、リクエスト電文及び処理結果のデータを通信部１２２から従系であるサーバ２に転送する。そして、従系サーバ２の業務アプリケーション制御部２２は、リクエスト電文及び処理結果のデータを通信部２２２で受信すると、かかる処理結果のデータを通信部２２２からネットワーク１００を介してクライアント端末４０にリクエスト応答として転送することで、クライアント端末４０に対してデータサービスを提供する。さらに、従系サーバ２の業務アプリケーション制御部２２は、要求メッセージを含めた一連の処理結果のデータを、通信部２２２経由でデータベース３に保存する。以上の動作は、クライアント端末４０からリクエスト電文が送信される毎に行われる。

【0042】

このように、本実施形態のシステムでは、従来システムのように従系サーバから主系サーバにデータ同期を通知する応答を返した後に主系サーバからクライアント端末にリクエスト応答する構成とはせずに、主系サーバで処理したデータを受信した従系サーバが直接クライアント端末にリクエスト応答する構成としたので、リクエスト電文の受信からクライアント端末への応答までの時間を短縮することが可能となり、レスポンス性の向上が図られる。

【0043】

（業務アプリケーションに障害が発生した場合）
上述の通常処理を行う間、業務アプリケーション制御部１２及びハートビート監視部１１は、自ノードの監視部１２１の検出結果に基づいて、自ノードの業務処理に障害が発生したかを監視する（ステップＳ４）。監視部１２１から障害発生が検出されると、業務アプリケーション制御部１２は、自ノードの業務アプリケーションの各プロセスを停止させる処理を行う（ステップＳ５）。かかる処理が完了すると、監視部１２１は、業務アプリケーションの停止を検出し、かかる検出情報をハートビート監視部１１に提供する。この検出情報を取得したハートビート監視部１１は、ハートビート電文中に含めるステータス情報を「ＳｈｕｔＤｏｗｎ」に変更する（ステップＳ６）。ここで、業務アプリケーションの各プロセスが完全に停止すると、監視部１２１から業務ハートビート電文が送信されなくなるため、他系サーバでの業務ハートビート電文の受信が途絶される。

【0044】

以上の処理は、他ノードであるサーバ２でも同様に行われる。但し、主系であるサーバ１と従系であるサーバ２では、業務処理の内容が異なるので、自ノードの業務アプリケーションの状態を検出する際の監視部１２１及び２２１間での障害検出の対象は、相互に異なるものとなる。

【0045】

（業務アプリケーション切り替え部の処理）
次に、図７を参照して業務アプリケーション切り替え部が行う処理について詳述する。ここでは従系であるサーバ２の業務アプリケーション切り替え部２３を中心に説明する。

【0046】

サーバ２の業務アプリケーション切り替え部２３は、ハートビート監視部２１でのハートビート電文の受信が途絶されたか（ステップＳ１１）及びハートビート電文のステータス情報が「ＳｈｕｔＤｏｗｎ」であるか（ステップＳ１２）をチェックする。ここで、業務アプリケーション切り替え部２３は、ハートビート電文中のステータス情報が「ＲＥＡＤＹ」であればステップＳ１１及びＳ１２を繰り返し、ハートビート監視部２１で「ＳｈｕｔＤｏｗｎ」のハートビート電文を受信した場合、或いはハートビート監視部２１でハートビート電文を受信できなくなった場合に、ステップＳ１３に移行して警告の処理を行う。この警告処理は、他ノードで異常が発生した旨を自ノードの表示画面に表示する処理である。続いて、業務アプリケーション切り替え部２３は、監視部２２１で業務ハートビート電文が受信されているか否か（ステップＳ１４）により他系の業務状態を判定した上で、主従系サーバへの切り替えを行うか否かを判断する。

【0047】

すなわち、業務アプリケーション切り替え部２３は、他系サーバからの業務ハートビート電文が受信できない「途絶」状態となった場合（ステップＳ１４でＹＥＳ）に、他系（この場合は主系）サーバ１の業務に障害ありとみなし、自ノードを主従系サーバとするように切り替える処理を行う（ステップＳ１５）。他方、業務ハートビート電文が監視部２２１で受信できている場合（ステップＳ１４でＮＯ）には、業務アプリケーション切り替え部２３は、ステップＳ１１乃至ステップＳ１３の処理を繰り返す。

【0048】

ハートビート電文に含まれるステータス情報と業務ハートビート電文の受信状態の組合せから業務アプリケーション切り替え部２３が判定する内容についてのマトリクス表を図５に示す。本システムでは、ハートビート電文と業務ハートビート電文の両方が途絶状態になった場合、あるいはハートビート電文に含まれるステータス情報が「ＳｈｕｔＤｏｗｎ」で業務ハートビート電文が途絶状態である場合に主従系サーバへの切り替えを行うことが分かる。

【0049】

したがって、ハートビート電文中のステータス情報が「ＳｈｕｔＤｏｗｎ」であっても業務ハートビート電文が受信されている場合は、業務アプリケーション切り替え部２３は、他ノードの業務アプリケーションに障害なしとみなして、ステップＳ１３でハートビート電文のステータス表示にエラーがある旨の警告表示を行う。これに対して、単に他系サーバでの業務ハートビート電文送信プロセスの停止が遅れているだけの場合（すなわちＳｈｕｔＤｏｗｎが先行してしまったような場合）には、業務アプリケーション切り替え部２３は、ステップＳ１１乃至ステップＳ１４の判定を継続していれば業務ハートビート受信の途絶を判定できるので、このような場合にはステップＳ１５に移行する。

【0050】

本システムでは、このように、監視プロセスのハートビートとは別個に、業務プロセス自身（換言すると業務アプリケーション自ら）が所定周期でハートビートを繰り返し出力する構成としていることから、業務アプリケーションの死活状態を他系サーバで正確に検出することが可能となり、また、他ノードの業務アプリケーションの停止時に主従系サーバへの切り替えを速やかに行うことができるようになる。

【0051】

また、本システムでは、業務アプリケーションの状態がステータス情報としてハートビート電文中に含まれるため、かかるステータス情報によって業務アプリケーションの停止が通知される（ステップＳ１２）かハートビート電文自体が途絶された場合（ステップＳ１１）にのみ、業務ハートビート電文の受信状態をチェックする構成としている（ステップＳ１４）。このため、業務アプリケーション切り替え部２３は、業務ハートビート電文の受信が途絶状態となってもハートビート電文中のステータス情報が「ＲＥＡＤＹ」である場合には、他ノードの業務自体には障害なしとみなしてステップＳ１５の切り替え処理を行わないが、業務ハートビート電文が受信できていない旨の警告表示の処理を行うようにする（図５参照）。この場合、典型的には自ノードの業務ハートビート電文の受信機能に異常が生じたことが考えられる。

【0052】

また、業務アプリケーション切り替え部２３は、ハートビート電文の受信が途絶された場合（ステップＳ１１でＹＥＳ）でも、業務ハートビート電文が受信できている場合には、同様に他ノードの業務自体には障害なしとみなしてステップＳ１５の切り替え処理を行わないが、ハートビート電文が受信できていない旨の警告表示の処理を行うようにする（図５参照）。この場合、典型的には、自ノードのハートビート受信機能あるいは他ノードのハートビート送信機能に異常が生じたことが考えられる（図２参照）。

【0053】

なお、上述した処理は、主系であるサーバ１の業務アプリケーション切り替え部１３でも同様に行われる。

【0054】

以下、主系サーバ１の障害発生により、従系であったサーバ２が主従系サーバになるように切り替える処理について説明する。

【0055】

（業務アプリケーションの障害発生時）
サーバ１は、自ノードの業務処理（この場合、クライアント端末からのリクエスト電文の受信、当該リクエストの処理、従系サーバ（サーバ２）への同期データの送信、業務ハートビートの送受信のいずれか）に障害が発生した場合（ステップＳ４でＹＥＳ）、自ノードの業務アプリケーションの各プロセスを停止する（ステップＳ５）。そして、業務アプリケーションの全プロセスが停止した後に、自ノードの状態を「ＳｈｕｔＤｏｗｎ」とするハートビート電文を送信する（ステップＳ６）。

【0056】

（その他の障害発生時）
その他の障害発生の場合、例えばサーバ１で電源遮断や断線等のハードウェア障害が発生した場合には、ハートビート電文及び業務ハートビート電文のいずれもサーバ１から送信できなくなるので、サーバ２でのこれらの電文の受信が「途絶」状態となる。但し、単にハートビート電文の送信機能のみに障害が発生する場合も考えられ、この場合にはサーバ１から業務ハートビート電文が送信される。

【0057】

（サーバ２の処理）
これに対して、サーバ１の障害を検出したサーバ２は、ステップＳ１５で記憶部２４の設定テーブルを書き換える（図８及び図９参照）。記憶部２４に格納された設定テーブルの初期設定状態を図８に示す。この設定テーブルでは、業務アプリケーションの業務すなわち各機能の処理主体を規定している。図中のトピック欄は、業務アプリケーションの機能を示すものであり、「／ＨＢ」がハートビート電文の送受信機能、「／ＷＨＢ」が業務ハートビート電文の送受信機能、「／ＳＹＮＣ」が同期データの送受信機能、「／ＯＲＤ」がクライアント端末からのリクエスト電文の受信及び処理機能、「／ＡＣＫ」がクライアント端末への応答機能、「／ＤＢ」がデータベースへの保存機能を示す。

【0058】

また、トピック欄に対応する右側の欄では、各機能を処理する主体や各機能の活性（アクティブ）状態を示しており、図８では初期設定状態を表している。具体的には、上記各機能が「○」すなわち活性状態であり、クライアント端末からのリクエスト電文の受信が「ＳI」すなわちサーバ１で行われ、クライアント端末（「Ｃｌ」）への応答及びデータベースへの保存が「ＳII」すなわちサーバ２で行われる設定となっている。また、正常状態では、送受信されるハートビート電文中に「ＲＥＡＤＹ」のステータス情報が含まれることが分かる。

【0059】

サーバ２は、ステータス情報として「ＳｈｕｔＤｏｗｎ」の含まれたハートビート電文を受信し（ステップＳ１２でＹＥＳ）、業務ハートビート電文の途絶を検出すると（ステップＳ１４でＹＥＳ）、図９に示すように、サーバ１の業務プロセス（ＳI＿ＷＰ）における業務ハートビート電文の送信機能（／ＷＨＢ）、同期用データの送信機能（／ＳＹＮＣ）、及びクライアント端末からのリクエスト電文の受信機能（／ＯＲＤ）の活性状態をそれぞれ非活性に設定する（図中「×」で表記）とともに、自ノードの業務プロセス（ＳII＿ＷＰ）でのクライアント端末からのリクエスト電文の受信及び処理機能（／ＯＲＤ）を活性化させる（図中「○」で表記）ように設定テーブルを書き換える。なお、この場合は同期用データの送受信機能は使用しないため、自ノードの業務プロセス（ＳII＿ＷＰ）の「／ＳＹＮＣ」を非活性に設定する（図中「−」で表記）。

【0060】

かかる処理の後、書き換えられた設定テーブルの設定に基づいて、従系であったサーバ２が図３に示すように主従系サーバとして処理を行う。すなわち、サーバ２は、ネットワーク１００を介して業務アプリケーションにアクセスするクライアント端末４０からのリクエスト電文を通信部２２２で受信し、当該リクエスト内容を自ノードの業務アプリケーション（業務アプリケーション制御部２２）で処理し、処理結果のデータを通信部２２２からネットワーク１００を介してクライアント端末４０にリクエスト応答として送信することで、クライアント端末４０に対してデータサービスを提供する。さらに、サーバ２の業務アプリケーション制御部２２は、リクエスト電文を含めた一連の処理結果のデータを、通信部２２２経由でデータベース３に保存する。

【0061】

（クライアント端末の処理）
なお、障害発生時点から上述の切り替え処理が完了するまでは、クライアント端末４０からのリクエスト電文が受信されない或いは処理されないことになるため、当該リクエスト電文に対するリクエスト応答がされない状態となる。したがって、クライアント端末４０は、リクエスト電文に対する応答が所定時間経過してもなされない場合に、当該無応答となったリクエスト電文を主従系サーバに再送する。

【0062】

（主系サーバが主従系サーバに切り替わる場合）
次に、従系サーバ２の障害発生により、主系であったサーバ１が主従系サーバになるように切り替える処理について説明する。

【0063】

（サーバ２の処理）
サーバ２は、自ノードの業務処理、この場合、サーバ１からの同期データの受信、クライアント端末への応答、データベースへの保存、業務ハートビートの送受信のいずれかに障害が発生した場合（ステップＳ４でＹＥＳ）、自ノードの業務アプリケーションの各プロセスを停止する（ステップＳ５）。そして、業務アプリケーションの全プロセスが停止した後に、自ノードの状態を「ＳｈｕｔＤｏｗｎ」とするハートビート電文を送信する（ステップＳ６）。

【0064】

（その他の障害発生時）
その他の障害発生の場合、例えばサーバ２で電源遮断や断線等のハードウェア障害が発生した場合には、ハートビート電文及び業務ハートビート電文のいずれもサーバ２から送信できなくなるので、サーバ１でのこれらの電文の受信が「途絶」状態となる。但し、単にハートビート電文の送信機能のみに障害が発生する場合もあり、この場合にはサーバ２から業務ハートビート電文が送信される。

【0065】

（サーバ１の処理）
一方、サーバ２の障害を検出したサーバ１は、ステップＳ１５で記憶部２４の設定テーブルを例えば図１０のように書き換える。ここで、図１０は、従系のサーバ２が電源遮断によりダウンした場合の設定テーブルの書き換えの例を示している。

【0066】

すなわち、サーバ１は、サーバ２からのハートビート電文の受信が途絶されたことを検出し（ステップＳ１１でＹＥＳ）、ステップＳ１４で業務ハートビート電文の途絶を検出すると、図１０に示すように、サーバ２の業務プロセス（ＳII＿ＷＰ）におけるハートビート電文の送受信機能（／ＨＢ）、業務ハートビート電文の送信機能（／ＷＨＢ）、同期データの受信機能（／ＳＹＮＣ）、クライアント端末への応答機能（／ＡＣＫ）、及びデータベース保存機能（／ＤＢ）の活性状態をそれぞれ取消す（図中「×」で表記）とともに、自ノードの業務プロセス（ＳI＿ＷＰ）でのクライアント端末からのリクエスト電文の受信及び処理機能（／ＯＲＤ）を活性化させる（図中「○」で表記）ように設定テーブルを書き換える。なお、この場合は同期用データの送受信機能は使用しないため、自ノードの業務プロセス（ＳII＿ＷＰ）の「／ＳＹＮＣ」を非活性にする（図中「−」で表記）。

【0067】

かかる処理の後、書き換えられた設定テーブルの設定に基づいて、主系であったサーバ２が図４に示すように主従系サーバとして処理を行う。すなわち、サーバ１は、ネットワーク１００を介して業務アプリケーションにアクセスするクライアント端末４０からのリクエスト電文を通信部１２２で受信し、当該リクエスト内容を自ノードの業務アプリケーション（業務アプリケーション制御部１２）で処理し、処理結果のデータを通信部１２２からネットワーク１００を介してクライアント端末４０にリクエスト応答として送信することで、クライアント端末４０に対してデータサービスを提供する。さらに、サーバ１の業務アプリケーション制御部１２は、リクエスト電文を含めた一連の処理結果のデータを、通信部１２２経由でデータベース３に保存する。

【0068】

このように、本システムでは、ハートビート電文に基づく監視プロセス（図６参照）に加えて、業務アプリケーションによる業務プロセスで別個のハートビート（すなわち業務ハートビート電文）を送受信する構成としたので、ハートビート電文の受信が途絶した場合でも他系の業務実行状態を判別することが可能になり、主従系への切り替えが必要とされているか否かの判定を正確かつ容易に行えるようになる。具体的には、本システムによれば、単にハートビート電文の送受信機能だけに障害がある場合には主従系への切り替えが行われないため（図２参照）、本来無用な切り替えを回避することが可能になり、さらには主系及び従系の各サーバがそれぞれ主従系へ切り替わることによる２重処理が防止される。

【0069】

また、本システムでは、通常時にクライアントからの要求の受信と処理を主系サーバで、クライアントへの応答及びデータベース保存を従系サーバで行う構成としたので、各サーバの負荷が分散され、クライアントへの応答レスポンスが向上し、システム全体として処理が早くなる。さらに、本システムでは、従来システムのように従系から主系への返答を行わずに従系からクライアントへ直接に応答を行う構成としたので、クライアントへの応答レスポンスが向上する。さらにまた、本システムでは、主系サーバの障害時にクライアントへの電文応答やデータベースへの保存データのロストの発生を防止することが可能となる。

【0070】

（第２の実施形態）
本システムの第２の実施形態について説明する。図１１は第２の実施形態を説明するフローチャートであり、上述した図５のルーチンに入る前にハートビート監視モードであるか否かを判定するステップＳ１０が加えられている他は図７と同じである。

【0071】

すなわち、本システムの第２の実施形態では、各サーバ（１及び２）は、電源投入時に他系サーバのハートビートの監視を行わないハートビート監視モードＯＦＦの状態で起動し、ハートビート監視を開始する旨の開始命令を受信するまでは、ハートビート監視モードＯＦＦの状態を維持する。換言すると、第２の実施形態では、監視開始命令を受信するまでは、ハートビート監視部（１１及び２１）及び監視部（１２１及び２２１）の検出結果に関わらず、主従系サーバへの切り替えが禁止される。

【0072】

ここで、ハートビート監視を開始する旨の開始命令は、本実施形態ではシステム全体の命令として、システム管理者がサーバ１又は２のいずれかの入力手段（図示しないキーボードやマウス等）を操作することによって、業務アプリケーション制御部（１２又は２２）で検知される。以下、開始命令がサーバ１で入力された場合を説明すると、開始命令を検知したサーバ１の業務アプリケーション制御部１２は、当該開始命令を通信部１２２及び２２２経由で他系サーバ２の業務アプリケーション制御部２２に転送するともに、開始命令を受信した旨を自ノードの業務アプリケーション切り替え部１３に通知する。業務アプリケーション切り替え部１３は、サーバ起動時にはステップＳ１０の判定を行い、開始命令を受信した旨が通知されるとハートビート監視モードがＯＮになったものと判定し（ステップＳ１０でＹＥＳ）、上述したステップＳ１１以下の処理を開始する。一方、サーバ１から開始命令を転送されたサーバ２は、開始命令を受信した旨を業務アプリケーション制御部２２から業務アプリケーション切り替え部２３に通知し、同様に、業務アプリケーション切り替え部２３でハートビート監視モードがＯＮになったものと判定し（ステップＳ１０でＹＥＳ）、上述したステップＳ１１以下の処理を開始する。

【0073】

このように、本システムの第２の実施形態では、開始命令が入力されるまではハートビート監視モードＯＦＦの状態が維持され、他系サーバの監視が行われないので、主従系サーバへの切り替え（ステップＳ１５）も実行されることがない。したがって、第２の実施形態では、いわゆる起動障害が発生して片系のサーバに不具合が生じた場合に、当該サーバのメインテナンスや再起動などを制限なく実施することができる。また、第２の実施形態によれば、電源投入時などのシステム全体が比較的不安定な状態での本来不要な主従系への切り替えが防止され、各サーバが比較的安定した状態になった後に開始命令を入力して他系サーバの監視を開始することができる。したがって、第２の実施形態によれば、システム管理者の負担が大幅に軽減される。

【0074】

（応用技術分野）
上述した各実施形態のシステムは、冗長化構成のシステムにおいて好適に適用可能である。また、本システムは、クラスタソフトウエアを導入することなく、低コストかつ確実で高いレスポンス性を備えたホットスタンバイ方式のシステムを実現することが可能である。

【0075】

なお、本発明の実施形態を説明したが、当該実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0076】

１，２ サーバ
１１，２１ ハートビート（ＨＢ）監視部
１２，２２ 業務アプリケーション（ＡＰ）制御部
１２１，２２１ 監視部
１２２，２２２ 通信部
１３，２３ 業務アプリケーション（ＡＰ）切り替え部
１４，２４ 記憶部
３ データベース
４０ クライアント端末
１００ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】