(57)【要約】【課題】  クラスタ構成のキューシステムにおいて、サーバの障害を検知するサーバ自身の障害により、キューを持つサーバの障害が検知が不能となり、キューに残ったメッセージの引き継ぎが不可能となる事象を回避する必要がある。【解決手段】  複数サーバがキューを共用するクラスタ構成のキューシステムで、他サーバの障害を検出したときに、メッセージ管理プログラムは前記障害サーバが管理していたメッセージを引き継ぐかどうかを自発的に判断する。引き継ぐと判断したメッセージ管理プログラムは、障害サーバが管理していたキュー内のメッセージで“処理未済み”のメッセージの管理者ＩＤを自身のＩＤに更新し、メッセージのコピーを自身のメッセージキャッシュ領域にコピーすることで、障害サーバが管理していたメッセージを引き継ぐ。【選択図】  図６
2007133795.tif 000002
【特許請求の範囲】
【請求項１】
所定の業務を実行する業務システムであって、前記業務の実行を要求する要求情報であるメッセージを一時的に記憶するキューを複数のサーバが共用するクラスタ構成の業務システムにおいて、
前記メッセージを入力するプログラムと、前記メッセージを管理するプログラムと、前記メッセージに従い業務を実行するプログラムとを保持する手段と、
前記複数のサーバのうち特定のサーバに障害が発生したことを検知する手段と、
前記障害が発生した特定のサーバが管理していた前記メッセージを前記複数のサーバのうち障害が発生していない特定のサーバが引き継ぐ手段とを有することを特徴とするクラスタ構成の業務システム。
【請求項２】
前記障害が発生した特定のサーバが管理していた前記メッセージを前記複数のサーバのうち障害が発生していない特定のサーバが引き継ぐ手段は、前記複数のサーバのうち特定のサーバに障害が発生したことを検知する手段を用いて障害が発生したサーバを特定し、予め決められた前記障害が発生したサーバが管理していた前記メッセージを前記複数サーバのうちのいずれのサーバが引き継ぐべきかを定めた情報に基づいて、前記メッセージを引き継ぐべきサーバが自ら判断し、前記メッセージを引き継ぐことを特徴とする、請求項１に記載のクラスタ構成の業務システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定の業務を実行する業務システムであって、複数のサーバが一つのキューを共用するクラスタ構成のキューシステムに関するものであり、業務処理要求が処理されずに滞ることを防ぐ技術に関するものである。業務システムには、金融システムなどが含まれる。
【背景技術】
【０００２】
キューを使用するクラスタ構成のキューシステムにおいて、一部のサーバで障害が発生した場合に、障害が発生したサーバが行っていた処理を、他のサーバが引き継ぐ方法として、特許文献１が知られている。特許文献１においては、サーバの障害を検知するサーバが、障害サーバと同じ名称のキューを持つサーバに対して前記障害サーバのサーバ状態を通知し、通知を受けたサーバが引き継ぎサーバとして前記障害サーバのメッセージ処理を引き継ぐ。また、特許文献１においては、障害サーバが再始動する過程で、障害サーバのキューの他サーバ参照状態が参照中であった場合、そのキューは使用せずに待機状態となり、他サーバ参照状態が参照終了となった場合、初めてそのキューを使用することにすることで、障害サーバのキューに残ったメッセージに対して障害サーバと引継ぎサーバが二重に処理を行わないようにすることを可能としている。
【０００３】
【特許文献１】特開２００４−８６５４３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記従来技術では、サーバの障害を検知するサーバ自身に障害が発生した場合、キューを持つサーバの障害を検知できなくなり、キューに残ったメッセージの引き継ぎが不可能となる。また、障害サーバのキューの他サーバ参照状態が参照中であった場合、障害サーバが再始動したにもかかわらず、そのキューは使用できない状態となり、システムの障害からの即時復旧が困難となる。
【課題を解決するための手段】
【０００５】
そこで、本発明では、キューを管理する複数のサーバが互いに生存を確認し合い、他サーバの障害を検知したサーバは、予め定められた情報に従って自身が引き継ぎサーバであるかどうかを自発的に判断し、その結果、自身が引き継ぎサーバであると判断したサーバが障害サーバの管理していたメッセージを引き継ぐ。また、本発明では、クラスタ構成の複数のサーバがキューを共用し、キューにメッセージを登録する際に、メッセージに自身が管理するメッセージあることを特定可能なＩＤを付与する。前記引き継ぎサーバは、前記障害サーバが管理していたメッセージに付与された前記ＩＤを自身のＩＤに更新することで、メッセージの引継ぎを行う。また、前記障害サーバが再始動する場合、共用しているキューを使用することが可能である。
【発明の効果】
【０００６】
本発明によれば、クラスタを構成する複数のサーバが互いに生存を確認し合い、他サーバの障害を検知したサーバが、自発的に障害サーバのメッセージを引き継ぐかどうか判断することができる。これにより、特定のサーバの障害によりメッセージの引き継ぎが不可能となることを防ぐことができる。また、障害サーバが再始動する場合、即座にキューを使用することが可能であり、システムの障害からの即時復旧が可能となる。
【発明を実施するための最良の形態】
【０００７】
本発明の実施の形態について、図面を用いて説明する。
まず、本実施の形態におけるシステム構成図を図1に示す。サーバ装置１（１１），サーバ装置２（２1）、サーバ装置３（３１）は同一の構成をしており、それぞれサーバ装置４（４１）とネットワークを介して接続されている。また、サーバ装置１（１１）、サーバ装置２（２１）、サーバ装置３（３１）は互いの生存を確認し合う目的で電文をやり取り（５４）できるように、ネットワークを介して互いに接続されている。サーバ装置１（１１）では、メッセージの入力処理を行うプログラム（１２）と、メッセージにより要求された業務処理を実行するプログラム（１３）と、メッセージの管理を行うプログラム（１４）とが動作する。メッセージの管理を行うプログラム（１４）は、図２に示すように、システム内で自身を一意に特定するＩＤ（１５）と、メッセージのコピーを保持しておくメモリ上の領域であるメッセージキャッシュ領域（１６）と、サーバ障害時のメッセージの引継ぎのための情報を記しておく引継ぎ情報管理テーブル（１７）とを持つ。サーバ装置２（２１）およびサーバ装置３（３１）においても、前記サーバ装置１（１１）と同様のプログラムが動作する。サーバ装置４（４１）ではＤＢＭＳ（４２）が動作し、メッセージを記憶するＤＢキュー（４３）を実装している。ＤＢキュー（４３）の実態は、ＤＢＭＳ（４２）のテーブルである。
【０００８】
基本的な処理の流れについて、図１を用いて説明する。前記の通り、サーバ装置１（１１）、サーバ装置２（１２）、サーバ装置３（１３）は同一の構成をしており、互いに生存確認をしている。また、各サーバ装置および各サーバ装置上で動作する各プログラムは同一の機能を有しており、それらは並列に動作する。以下では、サーバ装置１（１１）を例に基本的な処理の流れについて説明する。メッセージ入力プログラム（１２）は、Webブラウザからのリクエストを受け付けてメッセージを生成するプログラムやCSVファイル等からの入力をもとに一括でメッセージの生成を行うバッチプログラム等を想定する。メッセージ入力プログラム（１２）は生成したメッセージをメッセージ管理プログラム（１４）へ送信し（５１）、メッセージをＤＢキュー（４３）へ登録するよう依頼する。メッセージ管理プログラム（１４）は、受信したメッセージをＤＢキュー（４３）へ登録（５２）する。メッセージ管理プログラム（１４）は、ＤＢキュー（４３）へ登録したメッセージをメッセージ処理プログラム（１３）へ送信し（５３）、メッセージの処理を依頼する。メッセージ処理プログラム（１３）はメッセージに従い業務処理を実行する。
【０００９】
以下、本実施の形態の処理内容について図４、図５、図６を用いて説明する。説明においては、サーバ装置１（１１）を例に用いるが、サーバ装置２（２１）、サーバ装置３（３１）においても同様の処理内容である。なお、処理内容以外の対象物については、図１、図２、図７および図８の表記を引用する。
【００１０】
まず、メッセージ入力の処理内容について図４を用いて説明する。メッセージ入力プログラム（１２）は、WebブラウザからのリクエストやCSVファイルからの入力等を受け付けてメッセージを生成し、メッセージ管理プログラムへメッセージを送信する（１０１）。メッセージ管理プログラム(１４)は、メッセージ入力プログラム（１２）から送信されたメッセージのコピーを自身のメッセージキャッシュ領域（１６）に保持し（１０２）、その後、ＤＢキュー（４３）へメッセージを登録する（１０３）。ＤＢキュー（４３）へ登録されたメッセージの実態は、ＤＢキュー（４３）の実態であるＤＢＭＳ（４２）のテーブルの１レコードであり、図７に示した項目を持つ。メッセージＩＤ（６１）はメッセージをシステム内で一意に特定するＩＤであり、メッセージ管理プログラム（１４）がＤＢキュー（４３）へメッセージを登録する際にシステム内で一意なＩＤを生成し付与する。管理者ＩＤ（６２）はメッセージの管理者をシステム内で一意に特定するＩＤであり、当該メッセージをＤＢキュー（４３）へ登録したメッセージ管理プログラム（１４）のＩＤ（１５）を付与する。ステータス（６３）はメッセージの処理状態を表す値であり、メッセージ登録時は“処理未済”を付与する。メッセージ本体（６４）は、メッセージ入力プログラム（１２）から受信したメッセージそのものである。また、メッセージキャッシュ領域（１６）に保持するメッセージのコピーは、ＤＢキュー（４３）へ登録するメッセージと同一のメッセージ本体（６４）およびメッセージＩＤ（６１）を持つ。
【００１１】
次に、メッセージ処理の処理内容について図５を用いて説明する。メッセージ管理プログラム（１４）は自身のメッセージキャッシュ領域（１６）に保持しているメッセージのコピーを一つ取り出し、メッセージ処理プログラム（１３）へ送信する（２０１）。メッセージ処理プログラム（１０３）は、受け取ったメッセージに従い業務処理を実行し、業務処理が終了するとその旨をメッセージ管理プログラム（１４）へ通知する（２０２）。メッセージ管理プログラム（１４）は、メッセージ処理プログラム（１３）からの終了通知を受け取ると、ＤＢキュー（４３）に登録してある当該メッセージのステータス（６２）を“処理済み”に更新し（２０３）、その後、自身のメッセージキャッシュ領域（１６）から当該メッセージのコピーを削除する（２０４）。
【００１２】
最後に、サーバ障害時のメッセージの引継ぎ処理の内容について図６を用いて説明する。システムを起動する（３０１）と、サーバ装置１（１１）、サーバ装置２（２１）、サーバ装置３（３１）で動作するメッセージ管理プログラム（１４、２４、３４）は、それぞれ互いが動作していることを確認する生存監視を開始する（３０２）。生存監視は、例えばサーバ装置１（１１）のメッセージ管理プログラム（１４）がサーバ装置２（２１）のメッセージ管理プログラム（２４）へ生存確認問合せ電文を送信し、電文を受信したサーバ装置２（２１）のメッセージ管理プログラム（２４）がサーバ装置１（１１）のメッセージ管理プログラム（１４）へ生存応答電文を返送して、それをサーバ装置１（１１）のメッセージ管理プログラム（１４）が受信することでサーバ装置２（２１）のメッセージ管理プログラム（２４）の生存を確認するという手段で行う。サーバ装置１（１１）のメッセージ管理プログラム（１４）がサーバ装置２（２１）のメッセージ管理プログラム（２４）からの生存応答電文を受信できない時、サーバ装置２（２１）のメッセージ管理プログラム（２４）に障害が発生したことを検知できる。
【００１３】
他サーバの障害を検知しない間は、定期的に他サーバの生存確認を繰り返す。他サーバの障害を検知した場合、メッセージ管理プログラム（１４）は、自身の引継ぎ情報テーブル（１７）を参照し、障害が発生したサーバの引継ぎ情報を取得する（３０４）。メッセージ管理プログラム（１４）は、前記引継ぎ情報より前記障害が発生したサーバが管理していたメッセージを引き継ぐサーバの優先度を確認する（３０５）。メッセージ管理プログラム（１４）は、前記優先度で自身が最も優先度の高いサーバであった場合、ＤＢキュー（４３）を参照し、前記障害が発生したサーバが管理していたメッセージで、且つ、ステータス（６３）が“処理未済”のメッセージを検索する（３０７）。メッセージ管理プログラム（１４）は、前記検索にヒットしたメッセージの管理者ＩＤ（６２）を自身のＩＤ（１５）に更新し、その後、メッセージのコピーを自身のメッセージキャッシュ領域（１６）に保持する（３０８）。一方、前記優先度で自身よりも優先度の高いサーバが存在する場合、メッセージ管理プログラム（１４）は、前記優先度の高いサーバが生存しているか確認する（３０６）。前記優先度の高いサーバが一つでも生存している場合、メッセージ管理プログラム（１４）は何もしない。前記優先度の高いサーバが全て生存していない場合、メッセージ管理プログラム（１４）は、自身が最も優先度の高いサーバであると判断し、前記メッセージ引継ぎ処理（３０７、３０８）を行う。
【産業上の利用可能性】
【００１４】
本発明は、業務処理の滞りが許されない金融システムなどの社会インフラシステムに利用可能である。
【図面の簡単な説明】
【００１５】
【図１】キューを用いて非同期でメッセージを連携させる基本的な処理の流れを説明する概念図である。
【図２】メッセージ管理プログラム14の構成例を説明する概念図である。
【図３】ＤＢキュー43の構成例を説明する概念図である。
【図４】本発明において、キューにメッセージを入力する処理の流れを説明したフローチャートである。
【図５】本発明において、キューに入力されたメッセージを処理する際の流れを説明したフローチャートである。
【図６】本発明において、システム内の特定のサーバに障害は発生した際に残りの特定のサーバがメッセージを引き継ぐ処理の流れを説明したフローチャートである。
【図７】ＤＢキュー43の構成例である。
【図８】引継ぎ情報テーブル17の構成例である。
【符号の説明】
【００１６】
11  サーバ装置１
12  メッセージ入力プログラム
21  サーバ装置２
22  メッセージ入力プログラム
23  メッセージ処理プログラム
24  メッセージ管理プログラム２
31  サーバ装置３
32  メッセージ入力プログラム
33  メッセージ処理プログラム
34  メッセージ管理プログラム３
41  サーバ装置４
42  ＤＢＭＳ
51  メッセージＩＤ
52  管理者ＩＤ
53  ステータス
54  メッセージ
61  サーバＩＤ
62  引継ぎサーバ
【図１】
2007133795.tif 000003
【図２】
2007133795.tif 000004
【図３】
2007133795.tif 000005
【図４】
2007133795.tif 000006
【図５】
2007133795.tif 000007
【図６】
2007133795.tif 000008
【図７】
2007133795.tif 000009
【図８】
2007133795.tif 000010