(57)【要約】【課題】クラスタ構成のメッセージキューイングシステムにおいて、引継ぎノードが、業務プログラムやキュー管理プログラムを再開始することなく、障害ノードが持つキューに残された滞留メッセージを引継ぎ、引継ぎノードのキューのメッセージと同一視して処理を行なえるようにすることを目的とする。【解決手段】クラスタ構成のメッセージキューイングシステムで、あるノードに障害が発生したとき、障害ノードのキューと同じ名称のキューを持つノードが障害ノードのメッセージ処理を引継ぎ、障害ノードのメッセージを引継ぎノードのメッセージとマージする。引継ぎノードのユーザアプリケーションからメッセージの取得要求があったときは、メッセージの属するノードに応じたディスク装置からメッセージを取得する。障害ノードが復旧したときは、他ノードによる引継ぎ処理が終了していた場合、ログ情報を初期化し、キューへのアクセスを可能にする。【選択図】　図１
2004086543.tif 000002
【特許請求の範囲】
【請求項１】
同じ名称の複数のキューからメッセージの取得を行う複数のノードを備えたクラスタ構成のメッセージキューイングシステムにおける障害時のキュー制御方法であって、
障害ノードのキューと同じ名称のキューを持つノードが引継ぎノードとして前記障害ノードのメッセージ処理を引継ぎ、前記障害ノードが持つキューのメッセージを前記引継ぎノードが持つキューのメッセージと合わせて前記引継ぎノードの管理下に置く他ノードキュー情報取得制御ステップと、
前記引継ぎノードのユーザアプリケーションからメッセージの取得要求があったとき、前記引継ぎノードの管理下にあるメッセージの中から取得したメッセージを前記ユーザアプリケーションに渡すメッセージ取得制御ステップと
を備えることを特徴とする障害時におけるキュー制御方法。
【請求項２】
請求項１に記載のキュー制御方法において、
前記他ノードキュー情報取得制御ステップは、前記障害ノードが持つキューのメッセージを前記引継ぎノードが持つキューのメッセージと合わせて前記引継ぎノードの管理下に置く際に、前記引継ぎノードで引継いだ前記障害ノードが持つキューのメッセージが前記引継ぎノード以外のノードで処理されないように、前記障害ノードが持つキューの他ノード参照状態を参照中に変更するステップを含み、
前記メッセージ取得制御ステップは、前記引継ぎノードの管理下にあるメッセージを前記ユーザアプリケーションに渡した結果、前記障害ノードが持つキューのメッセージが無くなった場合には、前記障害ノードが持つキューの他ノード参照状態を参照終了に変更するステップを含む
ことを特徴とする障害時におけるキュー制御方法。
【請求項３】
請求項２に記載のキュー制御方法において、
前記障害ノードが復旧したとき、該障害ノードであったノードが持つキューの他ノード参照状態が参照終了であった場合のみ、ログ情報を初期化し、該他ノード参照状態を未参照に変更して該障害ノードであったノードが該キューへアクセスすることを可能にするノード復旧制御ステップを、さらに備えたことを特徴とする障害時におけるキュー制御方法。
【請求項４】
同じ名称の複数のキューからメッセージの取得を行う複数のノードを備えたクラスタ構成のメッセージキューイングシステムにおける障害時のキュー制御方法であって、
何れかのノードに障害が発生したことを検知するステップと、
障害が発生したノードのキューと同じ名称のキューを持つノードに対して、そのノードを引継ぎノードとして、前記ノード障害を通知するステップと、
前記引継ぎノードで引継ぐ前記障害ノードが持つキューのメッセージが前記引継ぎノード以外のノードで処理されないように、前記障害ノードが持つキューの他ノード参照状態を参照中に変更するステップと、
前記障害ノードが持つキューに仕掛り中のメッセージがあれば、それを決着させるステップと、
前記障害ノードが持つキューのメッセージの位置情報を取得し、前記引継ぎノードが持つキューのメッセージの位置情報とマージするステップと、
前記引継ぎノードのユーザアプリケーションからメッセージの取得要求があった場合、前記メッセージの位置情報を参照して、取出そうとするメッセージが前記障害ノードが持つキューであったときはそのキューから取出し、取出そうとするメッセージが前記引継ぎノードが持つキューであったときはそのキューから取出して、前記ユーザアプリケーションに渡すステップと、
前記障害ノードが持つキューのメッセージが無くなった場合には、前記障害ノードが持つキューの他ノード参照状態を参照終了に変更するステップと、
前記障害ノードが復旧したとき、該障害ノードであったノードが持つキューの他ノード参照状態が参照終了であった場合のみ、ログ情報を初期化し、該他ノード参照状態を未参照に変更して該障害ノードであったノードが該キューへアクセスすることを可能にするステップと
を備えることを特徴とする障害時におけるキュー制御方法。
【請求項５】
同じ名称の複数のキューからメッセージの取得を行う複数のノードを備えたクラスタ構成のメッセージキューイングシステムにおける障害時のキュー制御システムであって、
障害ノードのキューと同じ名称のキューを持つノードが引継ぎノードとして前記障害ノードのメッセージ処理を引継ぎ、前記障害ノードが持つキューのメッセージを前記引継ぎノードが持つキューのメッセージと合わせて前記引継ぎノードの管理下に置く他ノードキュー情報取得制御手段と、
前記引継ぎノードのユーザアプリケーションからメッセージの取得要求があったとき、前記引継ぎノードの管理下にあるメッセージの中から取得したメッセージを前記ユーザアプリケーションに渡すメッセージ取得制御手段と
を備えることを特徴とする障害時におけるキュー制御システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、クラスタ構成をとるオンラインシステムにおいて、一部のノードで障害が発生した場合に、障害が発生したノードが使用していたキューを、他の正常なノードが引継いで、処理を継続するキュー制御方法および装置に関する。
【０００２】
【従来の技術】
メッセージキューイングシステムは、キューを介してメッセージ転送を非同期に行うことで、送信側と受信側のノードが同時に動作している必要がない通信方式を提供する。メッセージキューイングシステムは、非同期通信を前提とするワークフロー処理、移動通信分野を始め、様々なシステムを接続する際の通信基盤となる技術である。
【０００３】
アプリケーションプログラムは、メッセージキューイングシステムが提供するキューへのメッセージ登録および取り出しを操作するアプリケーション・プログラム・インタフェース（ＡＰＩ）を使用してメッセージを送受信する。キューとは、メッセージを保存できる論理的な待ち行列を構成する器であり、通常はディスク装置上のファイルで実現されている。メッセージ送信時には、あて先キューを指定してメッセージ登録ＡＰＩを発行することで、メッセージが送信側ノードの転送用キューに格納される。メッセージキューイングシステムの転送機能は、転送用キューにつながれたメッセージを先入れ先出し方式（ＦＩＦＯ）で取り出し、所定のあて先のキューへ送信してあて先のキューに格納する。受信側ノードのアプリケーションは、メッセージ取り出しＡＰＩを発行することで、あて先キューに格納されたメッセージを、キュー（待ち行列）に最も長くつながれた順番に取り出す。なお、この取り出しにおいては、特定のメッセージを優先的に取り出すことも可能である。
【０００４】
メッセージキューイングシステムは、送信側と受信側の双方のノードが同時に稼動していなくても、自ノードが稼動していればキューを介することにより、相手側の状態に依存せず送信処理または受信処理が可能であるため、拡張性および柔軟性を備えた通信方式であるといえる。また、通信障害やシステムダウンが発生しても、ディスク装置等の物理媒体に実体を有するキューに格納されたメッセージは消失することはなく、かつ、送信側および受信側の転送機能が互いにメッセージ送達の確認をとることでメッセージの欠落および重複を発生させない方式をとっており、信頼性の高い通信方式を提供している。
【０００５】
クラスタ構成のメッセージキューイングシステムは、同一キュー、同一業務プログラム、サービスを動作させるノードを複数同時に並列処理させる構成を採るものである。これにより、負荷分散、障害時の可用性、および接続性を高めることができる。例として、クラスタ構成をとるメッセージキューイングシステムにおいては、複数のノードのプログラムが不特定のクライアントからメッセージを受信し、クライアントに対しては応答を返し、一方でメッセージをキューに格納しておき、業務プログラムが前記メッセージをキューから取得して処理を行うシステムが実現されている。
【０００６】
また、クラスタ構成において、一部のノードで障害が発生した場合に、障害が発生したノードが行っていた処理を、他のノードで引継ぐ方法として、業務プログラムを別ノードで待機させ、障害発生時には該待機していたプログラムを実行させて処理を続行する方法（特開平１０−１８７６３８号、クラスタ制御システム）が知られている。
【０００７】
【発明が解決しようとする課題】
上記従来技術の問題点は、メッセージキューイングシステムにおいて、一つのノード内の一つのキューに対して、複数のキュー管理プログラムおよびその下で動作する業務プログラムを動作させることができないため、キュー管理プログラムや業務プログラムを待機させておくことができず、障害が発生した時点で開始させなければならない点にある。前記業務プログラムの開始に時間がかかる場合、メッセージの滞留時間が長くなる問題がある。また、障害ノードが再始動したあとにディスクにデータが残っていた場合、再始動したノードと、引継いだノードが、同時にディスク上のデータを処理しようとする問題がある。
【０００８】
本発明の目的は、クラスタ構成のメッセージキューイングシステムにおいて、障害ノードのメッセージの滞留時間を短くするために、業務プログラムやキュー管理プログラムを再開始することなく、障害ノードのキューに蓄積された滞留メッセージを別のノードが引継ぎノードとなってメッセージ処理を引継ぎ、当該滞留メッセージを引継ぎノードのキューに格納されたメッセージとして扱えるようにすることで、引継ぎノードのユーザアプリケーションが、障害ノードのキューに残ったメッセージを引継ぎノードのキューのメッセージと同一視して処理することができるようにすることにある。
【０００９】
また本発明の他の目的は、障害ノードが復旧し再始動したとき、前記障害ノードのキューに残ったメッセージに対して障害ノードと引継ぎノードが二重に処理を行わないようにすることにある。
【００１０】
【課題を解決するための手段】
上記目的を達成するため、本発明は、メッセージを格納するキューが存在する記憶装置と、前記キューを持つノードのうち、キューに対してメッセージの登録を行うノードと、同じ名称の複数のキューからメッセージの取得を行う複数のノードと、ノード障害を検知し、障害ノードと同じ名称のキューを持つノードに対して前記障害ノードのノード状態を通知する機能を持ったクラスタ構成のメッセージキューイングシステムを前提とする。
【００１１】
前記メッセージキューイングシステムで、メッセージの取得を行うノードに障害が発生した場合、その障害ノードのキューと同じ名称のキューを持つノードが引継ぎノードとして前記障害ノードのメッセージ処理を引継ぐようにする。具体的には、その障害ノードの記憶装置上のキューおよびログ情報の位置を特定するためのキュー・ログ情報へのポインタ、障害ノード名称、および障害ノードが持つ記憶装置の位置情報を取得する。また、前記障害ノードのキューが参照中であることを示すために、他のノードからの参照状況を示す他ノード参照状態を参照中の状態にする。さらに、前記キュー情報に含まれている、メッセージの位置情報と、キューのメッセージ登録・取り出し履歴が記録されたログ情報をもとに、仕掛り中のメッセージを決着させるとともに、メッセージの位置情報と、障害ノードのノード名称とを含むメッセージポインタ情報を作成し、前記引継ぎノードの前記メッセージポインタ情報領域に追加する。
【００１２】
また本発明では、ユーザアプリケーションからメッセージの取得要求があったとき、前記メッセージポインタ情報を取得し、ノード名称が引継ぎノードである場合は引継ぎノードの記憶装置からメッセージ情報の入力を行い、ノード名称が障害ノードである場合はその障害ノード名称と記憶装置の位置情報から記憶装置を特定し、前記記憶装置からメッセージ情報の入力を行う。障害ノードからすべてのメッセージを取得した場合、前記他ノード参照状態を参照終了とする。
【００１３】
本発明では、上述したように、引継ぎノードが、障害ノードが持つキューに残された滞留メッセージを引継ぎ、引継ぎノードのキューのメッセージと同一視して処理を行う。
【００１４】
また本発明では、障害ノードが再始動する過程で、記憶装置上のキューの他ノード参照状態が参照中であった場合、そのキューは使用せずに待機状態となり、他ノード参照状態が参照終了となった場合、初めてそのキューを使用するようにする。これにより、障害ノードのキューに残ったメッセージに対して障害ノードと引継ぎノードが二重に処理を行わないようにすることが可能となる。
【００１５】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
【００１６】
図１は、クラスタ構成のノード間のメッセージキューイングシステムを示す図である。本クラスタシステムは、ノード２００，３００およびノード４００から構成される。ノード２００とディスク装置２４０とで一つのシステム２１０が構成され、ノード３００とディスク装置３４０とでもう一方のシステム３１０が構成されている。各ノードは、それぞれ自ノードのノード名称を記憶している。例えば、ノード名称２９８，３９８は、それぞれノード２００，３００の名称である。ノード２００，３００およびディスク装置２４０，３４０はそれぞれネットワーク１５０によって接続されており、ディスク装置２４０，３４０は各ノードで共有可能な状態となっている。本実施の形態では簡単のため、アプリケーションが動作するノードは２つとしている。
【００１７】
ノード２００はキュー２２０を、ノード３００はキュー２２０と同じ名称のキュー３２０を持つ。ディスク装置２４０にはキュー２２０とログ情報２３０が含まれ、同じくディスク装置３４０にはキュー３２０とログ情報３３０が含まれている。ログ情報２３０および３３０は、メッセージのキューへの登録あるいはキューからの取り出しの履歴情報を含んでいる。キュー２２０は他ノード参照状態６１０を持ち、キュー３２０は他ノード参照状態７１０を持つ。他ノード参照状態６１０，７１０とも、初期状態は未参照の状態であるが、他のノードから当該キューが参照されると、これらの他ノード参照状態は他ノードによって参照中の状態でることを示すため「参照中」に変更される。
【００１８】
ノード２００は、メッセージポインタ情報領域２５０、ノード名称テーブル３０５０、他ノードキュー情報取得制御２８０、メッセージ取得制御２９０、およびノード復旧制御２９５を持つ。ノード３００は、ノード２００と同様に、メッセージポインタ情報領域３５０、ノード名称テーブル３１５０、他ノードキュー情報取得制御３８０、メッセージ取得制御３９０、およびノード復旧制御３９５を持つ。ノード４００は、ノード監視制御４１０を持つ。ノード監視制御４１０は、ノード２００や３００に障害が発生していないか監視する。
【００１９】
ノード２００では、メッセージを受信するためのユーザアプリケーション２６０が動作しており、同様にノード３００ではユーザアプリケーション３６０が動作している。前記ユーザアプリケーション２６０，３６０は、それぞれキュー２２０，３２０からメッセージの取得を行う。キュー２２０，３２０に対してメッセージが登録されるとき、本メッセージキューイングシステムはクラスタ構成のため、登録されるメッセージは、同じ名称のすべてのキューに対して振り分けられる。例えば図１では、ノード２００にメッセージＹ５２０が、もう一方のノード３００にメッセージＸ５１０およびＺ５３０が振り分けられている。メッセージＹ５２０は、ディスク装置２４０のキュー２２０に格納され、メッセージＸ５１０，Ｚ５３０はディスク装置３４０のキュー３２０に格納される。キュー２２０，３２０にメッセージが格納されたとき、それらのメッセージの位置情報がメッセージの位置情報６２０，７２０にそれぞれ格納される。
【００２０】
ノード３００に障害が発生した場合、ノード４００のノード監視制御４１０は、ノード３００の障害検知４２０を行い、障害ノード３００が持つキュー３２０と同名称のキュー２２０を持つノード２００を引継ぎノードに決定し、ノード２００に対して、障害発生を通知し引継ぎ指示４３０を行う。引継ぎノードとなったノード２００は、他ノードキュー情報取得制御２８０によって障害ノード３００のキュー３２０のメッセージの引継ぎを行い、他ノード参照状態７１０を「参照中」の状態に更新する。
【００２１】
図２は、ノード３００に障害が発生しノード２００を引継ぎノードに決定した場合の他ノードキュー情報取得制御２８０、メッセージ取得制御２９０、およびノード復旧制御３９５を含む全体の処理の流れを示すフローチャートである。ステップ２０００で開始し、ステップ２０１０でノード３００に障害が発生すると、ノード監視制御４１０はそのノード障害を検知し、障害ノード３００のキュー３２０と同名称のキュー２２０を持つノード２００を引継ぎノードに決定し、ノード２００に対して当該ノード障害を通知する。
【００２２】
ステップ２０１５はそのノード２００における他ノードキュー情報取得制御２８０の処理である。ステップ２０２０で、自ノード２００で引継いだ障害ノードのキュー３２０が他のノードによって変更されるのを防ぐために、そのキュー３２０の他ノード参照状態７１０を「参照中」に更新する。ステップ２０３０で、障害ノードのキュー３２０に格納された仕掛り中メッセージがあれば決着させる。ステップ２０４０で、障害ノードのキューのメッセージの位置情報を取得し、自ノード２００と同名称のキューのメッセージの位置情報とマージする。
【００２３】
ステップ２０４５は、ノード２００のメッセージ取得制御２９０による処理である。ステップ２０５０で、自ノード２００のユーザアプリケーション２６０からメッセージの取得要求があったとき、メッセージのノード名称に応じたキューからメッセージの取得を行う。ステップ２０６０で、障害ノード３００の全てのメッセージを取得したとき、障害ノード３００のキューの他ノード参照状態７１０を「参照終了」に変更する。
【００２４】
ステップ２０６５は、ノード３００のノード復旧制御３９５による処理である。ステップ２０７０で、障害ノードであったノード３００が復旧したとき、キュー３２０の他ノード参照状態７１０が「参照終了」であれば、他ノードによる引継ぎ処理が終了しているということであるから、ログ情報３３０を初期化し、キュー３２０へのアクセスを可能にする。ステップ２０８０で処理を終了する。
【００２５】
図３は、ノード３００（ノード名称Ｂ）に障害が発生した場合における、ノード２００（ノード名称Ａ）の他ノードキュー情報取得制御２８０の処理（図２のステップ２０１５）の流れの詳細を示すフローチャートである。なお、図１中、ノード名称Ａであるノード２００側の各部については各番号の前にＡを付け、ノード名称Ｂであるノード３００側の各部については各番号の前にＢを付けて示すことがあるものとする。ここで、ノード３００が持つキューＢ３２０にはメッセージＸ５１０とメッセージＺ５３０が格納されており、ノード２００が持つキューＡ２２０にはメッセージＹ５２０が格納されているものとする。
【００２６】
ステップ１０１０において、他ノードキュー情報取得制御２８０は、ノード監視制御４１０から、キューＢ３２０・ログ情報Ｂ３３０へのポインタ７４０と、障害ノードのノード名称Ｂ３９８と、ディスク装置Ｂ３４０の位置情報７５０を取得する。取得したノード名称Ｂ３９８とディスク装置Ｂの位置情報７５０は、ノード名称テーブルＡ３０５０に追加する。次に、ディスク装置Ｂの位置情報７５０をもとに、障害ノードのディスク装置Ｂ３４０をマウントしアクセス可能とする。キューＢへのポインタから、キューＢ３２０の位置を特定し、他ノード参照状態Ｂ７１０を参照する。
【００２７】
ステップ１０２０で、他ノード参照状態Ｂ７１０が「参照中」であれば処理を終了（ステップ１０７０）し、「参照中」でなければステップ１０３０で他ノード参照状態Ｂ７１０を「参照中」に変更し、キューＢ３２０に格納されているメッセージの位置情報Ｂ７２０からメッセージＸ５１０の位置情報５１３を取得し、キューＢのログ情報Ｂ３３０を取得する。
【００２８】
ステップ１０４０で、障害ノードのキューＢ３２０に仕掛り中のメッセージがあるかどうかを判断する。ログ情報Ｂ３３０によってメッセージが仕掛り中であることが判明した場合、ステップ１０５０で、そのトランザクションを決着させ、決着の結果をメッセージの位置情報Ｂ７２０に出力する。
【００２９】
ステップ１０６０では、ノード名称Ｂ３９８とメッセージＸ５１０の位置情報５１３から、メッセージＸへのポインタ情報５１１を作成し、そのメッセージＸポインタ情報５１１をメッセージポインタ情報領域Ａ２５０に追加し、すでにメッセージポインタ情報領域Ａ２５０にメッセージポインタ情報が存在している場合、メッセージの位置情報に記録されたメッセージの登録時刻の順番にメッセージポインタ情報のソートを行う。ノード２００と３００の時間が常に同じになるように管理されている場合、キュー２２０，３２０に登録されたメッセージの順序が守られる。ステップ１０７０で、処理を終了する。
【００３０】
なお、上記ではメッセージＸ５１０の処理を例として説明したが、同様にして、障害ノードのキューＢ３２０中のメッセージＺ５３０についても処理される。
【００３１】
図４は、メッセージＸのメッセージポインタ情報５１１の構成を示す。メッセージＸポインタ情報５１１は、メッセージＸを格納するキューを持つノード３００のノード名称Ｂ３９８と、キューＢ３２０に格納されたメッセージＸの位置を示すメッセージＸの位置情報５１３とを有する。メッセージポインタ情報は、そのノードで処理待ちになっているメッセージを特定するための情報である。
【００３２】
図５は、ノード名称テーブルＡ３０５０の構成を示す。ノード名称テーブルＡ３０５０は、ノード名称Ｂ３９８と、ディスク装置Ｂ３４０の位置情報７５０を一組としたエントリからなる。ノード名称テーブルは、障害ノードの処理を引継ぐため、障害ノードのノード名称とディスク装置の位置を記憶するテーブルである。
【００３３】
図６は、メッセージの位置情報Ｂ７２０の構成を示す。メッセージの位置情報には、当該キューに格納された各メッセージの位置情報を格納する。例えば、メッセージの位置情報Ｂ７２０には、キューＢ３２０に格納されたメッセージの位置を示すメッセージＸ５１０の位置情報５１３とメッセージＺ５３０の位置情報５３３が格納されている。なお、メッセージの位置情報Ｂ７２０には、各メッセージがキューに登録されたときの時刻の情報も含まれている。
【００３４】
図７は、ノード２００のユーザアプリケーションＡ２６０からキューＡ２２０のメッセージの取得要求があったときの、メッセージ取得制御２９０の処理（図２のステップ２０４５）の流れの詳細を示すフローチャートである。ここで、既にノード２００は障害ノード３００を引継いでいるので、ノード２００のメッセージポインタ情報領域Ａ２５０にはメッセージＸ５１０，Ｙ５２０，Ｚ５３０のポインタ情報が格納されていることとする。
【００３５】
ステップ１２００で開始し、ステップ１２１０において、ユーザアプリケーションＡ２６０からメッセージ取り出し依頼を受けたとき、メッセージ取得制御２９０はメッセージポインタ情報領域Ａ２５０からメッセージボインタ情報を取り出す。ステップ１２２０で、取り出したメッセージポインタ情報のノード名称が自ノード２００のノード名称Ａと等しいかどうかを判断する。ここで、取り出したメッセージポインタ情報がメッセージＹ５２０のポインタ情報５２１であった場合、ノード名称が等しいので、ステップ１２３０で、自ノード２００のディスク装置Ａ２４０から、当該メッセージＹ５２０の位置情報５２３（メッセージポインタ情報に含まれている）をもとにメッセージＹ５２０のデータ取得を行い、ステップ１２５０（図８）に進む。
【００３６】
取り出したメッセージポインタ情報がメッセージＸ５１０のポインタ情報５１１であった場合、ステップ１２２０の判定でノード名称が等しくないので、ステップ１２４０で、ノード名称テーブルＡ３０５０から前記取り出したメッセージポインタ情報のノード名称Ｂ３９８をもとにディスク装置Ｂの位置情報７５０を取得し、ディスク装置Ｂの位置情報７５０とメッセージＸ５１０の位置情報５１３をもとにメッセージＸ５１０のデータ取得を行い、ステップ１２５０（図８）に進む。
【００３７】
図８に、メッセージ取得制御２９０の処理の続きを示す。ここではメッセージＸ５１０のデータを既に取得しているものとする。ステップ１２６０で、取得したメッセージＸ５１０をユーザアプリケーションＡ２６０に渡す。ステップ１２７０で、メッセージの位置情報Ｂ７２０からメッセージＸ５１０の位置情報５１３を削除する。ステップ１２８０で、障害ノード３００のメッセージが無くなったかどうかを判断し、残っている場合はステップ１２９５で終了する。メッセージが無くなった場合は、ステップ１２９０で、障害ノード３００のキューＢ３２０の他ノード参照状態Ｂ７１０を「参照終了」に変更し、ステップ１２９５で終了する。
【００３８】
図９は、ノード復旧制御３９５の処理（図２のステップ２０６５）の流れの詳細を示すフローチャートである。ここで、キューＢ３２０にはメッセージＸ５１０が格納されているものとする。このメッセージＸ５１０は、障害が発生し、その障害が復旧したとき、もともと処理されずに残ったメッセージなどである。前述の図８までの例ではメッセージＸ５１０が障害ノード３００を引継いだノード２００で処理される例を説明したが、図９では復旧したノード３００でそのメッセージＸ５１０が残っていたケースで説明する。
【００３９】
ステップ１３００で開始し、ステップ１３１０では、コマンド入力などによってノード３００を復旧開始し、キューＢ３２０内のメッセージＸ５１０の位置情報５１３と、他ノード参照状態Ｂ７１０を取得する。ステップ１３２０で、他ノード参照状態Ｂ７１０が「未参照」であるかどうかを判断する。他ノード参照状態Ｂ７１０が「未参照」の状態である場合は、ステップ１３３０でメッセージＸ５１０のポインタ情報５１１を作成し、メッセージポインタ情報領域Ｂ３５０に格納し、ステップ１３７０で処理を終了する。
【００４０】
ステップ１３２０で他ノード参照状態Ｂ７１０が「未参照」の状態でない場合は、ステップ１３４０で、他ノード参照状態Ｂ７１０が「参照終了」の状態であるかどうかを判断する。他ノード参照状態Ｂ７１０が「参照終了」の状態である場合は、ステップ１３５０で、ログ情報Ｂ３３０の初期化を行い、他ノード参照状態Ｂ７１０を「未参照」の状態に変更し、キューＢ３２０へのアクセスを可能にして、ステップ１３７０で処理を終了する。他ノード参照状態Ｂ７１０が「参照中」である場合は、キューＢ３２０が他のノードによって処理中であるため、ステップ１３６０で、他ノード参照状態Ｂ７１０が更新されるまで待機を行い、ステップ１３２０に戻る。
【００４１】
以上は、単独のノードに障害が発生した場合の実施の形態であるが、同名称のキューを持つ複数のノードに障害が発生した場合も、同名称のキューを持つ他のノードにメッセージの処理を引継がせることが可能である。図１０に、この場合の実施の形態を示す。同図は、同名称のキューを持つ３つのノード２００（ノード名称Ａ）、ノード３００（ノード名称Ｂ）、およびノード９００（ノード名称Ｃ）があるクラスタシステムを示している。ノード２００はシステムＡ２１０に属しており、ノード３００とディスク装置Ｂ３４０とで一つのシステムＢ３１０を構成している。同様に、ノード９００とディスク装置Ｃ９４０とで一つのシステムＣ９１０となっている。ここで、メッセージＸ５１０がディスク装置Ｂ３４０に、メッセージＸＸ５４０がディスク装置Ｃ９４０に滞留しているものとする。なお、図１０では図１〜図９で説明した実施の形態における各部と対応する部分は同じ番号を付けて示した。図１〜図９の実施の形態では２つのノードＡ，Ｂで説明しているのに対し、図１０の実施の形態ではさらに１つノードＣを加えた形である。
【００４２】
図１０において、ノードＢ、Ｃに障害が発生し、ディスク装置Ｂ３４０内のキューＢ、およびディスク装置Ｃ９４０内のキューＣにメッセージの滞留が発生した場合、ノードＡは、ノードＢのノード名称Ｂ３９８とディスク装置Ｂの位置情報７５０を一つのエントリとし、さらにノードＣのノード名称Ｃ９９８とディスク装置Ｃの位置情報８５０をもう一つのエントリとして、これらのエントリをノード名称テーブルＡ３０５０に格納する。そして、ディスク装置Ｂ３４０のメッセージの位置情報Ｂ７２０からメッセージＸ５１０の位置情報５１３を取得してメッセージＸ５１０のポインタ情報５１１を作成し、ディスク装置Ｃ９４０のメッセージの位置情報Ｃ８２０からメッセージＸＸ５４０の位置情報５４３を取得してメッセージＸＸ５４０のポインタ情報５４１を作成する。これらのメッセージポインタ情報は、いずれもメッセージポインタ情報Ａ２５０に格納される。ノードＡのユーザアプリケーションからメッセージの取得要求があった場合、これらのメッセージポインタ情報から、メッセージのデータが格納されているディスク装置が特定できる。
【００４３】
なお、上述の実施の形態では何れも１つのノードが１つのキューを持つ例で説明したが、１つのノードが複数のキューを持つ場合でも本発明は適用可能である。
【００４４】
【発明の効果】
以上説明したように、本発明によれば、引継ぎノードが、業務プログラムやキュー管理プログラムを再開始することなく、障害ノードが持つキューに残された滞留メッセージを引継ぎ、引継ぎノードのキューのメッセージと同一視して処理を行うことが可能となる。また、障害ノードのキューに残ったメッセージに対して障害ノードと引継ぎノードが二重に処理を行わないようにすることが可能となる。
【図面の簡単な説明】
【図１】本発明の実施形態であるクラスタ構成のメッセージキューイングシステムの構成図
【図２】クラスタ構成のメッセージキューイングシステムでノード障害が発生した場合の一連の処理の流れを示す図
【図３】他ノードキュー情報取得制御の処理の流れを示すフローチャート図
【図４】メッセージのメッセージポインタ情報の一例を示す図
【図５】ノード名称テーブルの一例を示す図
【図６】メッセージの位置情報の一例を示す図
【図７】メッセージ取得制御の処理の流れ（その１）を示すフローチャート図
【図８】メッセージ取得制御の処理の流れ（その２）を示すフローチャート図
【図９】ノード復旧制御の処理の流れを示すフローチャート図
【図１０】クラスタ構成のメッセージキューイングシステムで、複数のノードに障害が発生した場合の構成を示す図
【符号の説明】
１５０……ネットワーク
２００，３００，４００，９００……ノード
２１０，３１０，９１０……システム
２２０，３２０……キュー
２３０，３３０……ログ情報
２４０，３４０，９４０……ディスク装置
２５０，３５０……メッセージポインタ情報領域
２６０，３６０……ユーザアプリケーション
２８０，３８０……他ノードキュー情報取得制御
２９０，３９０……メッセージ取得制御
２９５，３９５……ノード復旧制御
２９８，３９８，９９８……ノード名称
４１０……ノード監視制御
４２０……障害検知
４３０……引継ぎ指示
５１０，５２０，５３０，５４０……メッセージ
５１１，５２１，５３１，５４１……メッセージポインタ情報
５１３，５２３，５３３，５４３……メッセージの位置情報
６１０，７１０……他ノード参照状態
６２０，７２０，８２０……メッセージ位置情報
７４０……キュー・ログ情報へのポインタ
７５０，８５０……ディスク装置の位置情報
３０５０，３１５０……ノード名称テーブル
【図１】
2004086543.tif 000003
【図２】
2004086543.tif 000004
【図３】
2004086543.tif 000005
【図４】
2004086543.tif 000006
【図５】
2004086543.tif 000007
【図６】
2004086543.tif 000008
【図７】
2004086543.tif 000009
【図８】
2004086543.tif 000010
【図９】
2004086543.tif 000011
【図１０】
2004086543.tif 000012