JP2007133453A - メッセージキューイングサーバ及びその監視方法 - Google Patents

Abstract

【課題】MQミドルウェア、キュー、送信チャネル、及び、受信チャネルを常時監視し、これらに障害が発生した場合、自動的に必要最低限のMQを閉鎖させることができるMQ監視ツールを提供する。
【解決手段】メッセージを保存するメッセージキューと、該メッセージキューを利用して他のメッセージキューイングシステムとの間でメッセージの送受信を行うミドルウエアと、他のメッセージキューイングシステムに接続された送信チャネル及び受信チャネルと、を有するメッセージキューイングサーバにおいて、メッセージキュー、ミドルウエア、送信チャネル及び受信チャネルを監視する監視ツールを設ける。監視ツールは、メッセージキューとミドルウエアの少なくとも１つに障害が発生したとき、全てのミドルウエアを停止し、全ての送信チャネル及び全ての受信チャネルを停止する。
【選択図】図１

Description

本発明は、メッセージキューイングサーバに存在するミドルウエア、メッセージキュー、送信チャネル、及び、受信チャネルを常時監視し、これらに障害が発生した場合、自動的にメッセージキューイングサーバを閉鎖させる技術に関するものである。

メッセージキューイングシステム（以下、単にMQシステムと呼ぶ。）は、メッセージキュー（以下、随時、単にキューと呼ぶ。）を介してメッセージ転送を非同期に行うことで、送信側と受信側が同時に動作している必要がない通信方式である。MQシステムは、非同期通信を前提とするワークフロー処理、移動通信分野を始め、様々なシステムを接続する場合の通信基盤である。

MQミドルウェアは、MQシステムが提供するキューへのメッセージの登録および取り出しを操作し、チャネルを介してメッセージの送受信を行う。キューとは、メッセージを保存できる論理的な待ち行列を構成する器であり、通常は磁気ディスク上に存在する。

MQシステムは、送信側と受信側の双方のノードが同時に稼動していなくても、自ノードが稼動していればキューを介することにより、他方側の状態に依存せず送信処理または受信処理が可能であるため、拡張性および柔軟性を備えた通信方式であると言える。また、メッセージが大量に入ってきた場合に処理性能の劣化を防ぐため、キューの滞留時間を設定することができ、設定時間を超えてキューに格納されているメッセージを削除する機能を持っている。

MQシステムはクラスタ構成を採ることができる。クラスタ構成のMQシステムは、同一キュー、同一業務プログラム、同一サービスを動作させるノードを複数同時に並列処理させる構成を採るものである。これにより、障害時の可用性を高めることができる。

このMQシステムにおいて、一部のノードで障害が発生した場合にクラスタ構成を採っていたとしても、障害ノードにあるメッセージは消失してしまう。

特開２００４−８６５４３号公報には、障害の発生によりメッセージが消失することを防ぐために、障害ノードのキューと同じ名称のキューをもつノードが障害ノードのメッセージ処理を引き継ぎ、処理を続行させる方法が記載されている。
特開２００４−８６５４３号公報

MQシステムにおける障害として、送信チャネル又は受信チャネルの切断のようなネットワーク障害、MQミドルウェアの異常停止、ディスク障害によるキューアクセス不能などが考えられる。MQシステムに障害が発生すると、メッセージの処理、及び、送受信を正常に行うことができない。例えば、MQミドルウェアに障害が発生した場合、キューにメッセージを登録することも、取り出すこともできなくなる。そのため、他方のシステムから登録されたメッセージが受信キューに滞留し続ける。

従来の技術では、障害ノードのキューに滞留しているメッセージを別ノードに引き継ぐことができるため、障害ノードにメッセージが滞留し続けることなく、別ノードで処理を続行することができる。

しかし、従来の技術では、MQミドルウェアに障害が発生した場合、送信チャネル、受信チャネルは接続されているため、障害ノードにメッセージが毎回登録され、その度に別ノードにメッセージを引き継がなければならない。このため、処理性能が劣化する。また、送信チャネル障害や受信チャネル障害が発生した場合は、メッセージを送信することが不可能であるにも拘らず、メッセージを送信し続けることとなり、更に障害が発生する可能性がある。このため、MQシステムが基本的にクラスタ構成を採っている場合でも、MQシステムの全ての機能が正常に動作していなければ、処理を続行させることができない。よって、障害が発生した場合は、障害ノードのMQシステムを閉鎖させる必要がある。

また、クラスタ構成などで、他方のシステムが複数ノードある場合、他方のシステムの一部のノードで障害が発生し、送受信チャネルが切断された場合、別ノードが稼動状態であれば、MQ処理は可能である。そのため、自システムのMQシステムを全て閉鎖することはできない。よって、障害ノードのみ通信しないようMQシステムを閉鎖させる必要がある。

本発明の目的は、MQミドルウェア、キュー、送信チャネル、及び、受信チャネルを常時監視し、これらに障害が発生した場合、自動的に必要最低限のMQを閉鎖させることができるMQ監視ツールを提供することにある。

本発明によると、メッセージを保存するメッセージキューと、該メッセージキューを利用して他のメッセージキューイングシステムとの間でメッセージの送受信を行うミドルウエアと、他のメッセージキューイングシステムに接続された送信チャネル及び受信チャネルと、を有するメッセージキューイングサーバにおいて、メッセージキュー、ミドルウエア、送信チャネル及び受信チャネルを監視する監視ツールを設ける。

監視ツールは、メッセージキューとミドルウエアの少なくとも１つに障害が発生したとき、全てのミドルウエアを停止し、全ての送信チャネル及び全ての受信チャネルを停止する。

本発明によると、MQミドルウェア、キュー、送信チャネル、及び、受信チャネルを常時監視し、これらに障害が発生した場合、自動的に必要最低限のMQを閉鎖させることができる。

以下、本発明を適用したMQ環境の一実施の形態について説明する。図１に示すように、メッセージキューイング（MQ）システムは、MQサーバ１によって構成されている自システムと複数のMQサーバ２、３によって構成されクラスタ構成の他システムからなる。

自システムのMQサーバ１をノード１、他システムのMQサーバ２、３をノード２、３とする。

自システムのMQサーバ１は、複数のMQミドルウェア１０、複数のキュー２０、MQ監視ツール３０、MQ監視対象テーブル３１及びMQチャネル障害テーブル３２を有する。

自システムのMQサーバ１と他システムのMQシステム２、３の間は送信チャネル４１、４３及び受信チャネル４２、４４によって接続されている。

MQ監視ツール３０は、MQミドルウェア１０、キュー２０、送信チャネル４１、４３、及び、受信チャネル４２、４４を、監視対象として、MQ監視対象テーブル３１に登録する。MQ監視ツール３０は、MQ監視対象テーブル３１から、監視対象であるMQミドルウェア１０、キュー２０、送信チャネル４１、４３、受信チャネル４２、４４を読み込み、障害が発生しているか否か常時監視する。MQ監視ツール３０は、受信チャネル４２、４４及び送信チャネル４１、４３の１つに障害が発生したことを検知すると、障害が発生したチャネルをMQチャネル障害テーブル３２に登録する。MQ監視ツール３０は、監視対象テーブルに登録された送信チャネル及び受信チャネルとＭＱチャネル障害テーブルに登録された送信チャネル及び受信チャネルを比較することによって障害が発生していない送信チャネル又は受信チャネルの有無を判定する。

MQ監視ツール３０は、次の４つの場合に自ノードのＭＱサーバ１を閉鎖する。
（１）MQミドルウェア１０のうちの１つに障害が発生したとき。
（２）キュー２０のうちの１つに障害が発生したとき。
（３）全ての受信チャネルに障害が発生したとき。
（４）全ての送信チャネルに障害が発生したとき。

自ノードのＭＱサーバ１を閉鎖するときは、障害が発生していない全てのMQミドルウェア、受信チャネル及び送信チャネルを停止する。

本発明によると、次のような利点が得られる。
（１）自ノードのMQミドルウェア、キュー、送信チャネル及び受信チャネルを常時監視し、MQミドルウェア又はキューに障害が発生した場合に、自ノードのＭＱサーバを閉鎖する。
（２）他システムがクラスタ構成であり複数のノード２、３を有するとき、他システムの一部のノードに障害が発生し、そのノードと自ノードの間の送受信チャネルが切断された場合でも、障害が発生していないノードと自ノードの間の通信は確保される。

図２は、MQ監視対象テーブル３１の構成例を示す。MQ監視対象テーブル３１は、送信チャネル２０１、受信チャネル２０２、MQミドルウェア２０３、及び、キュー２０４の項目を含む。MQ監視対象テーブル３１には、MQ監視ツール３０による監視対象が登録される。MQ監視ツール３０は、MQ監視対象テーブル３１を読み込み、監視および閉鎖処理を行う。

図３は、MQチャネル障害テーブル３２の構成例を示す。MQチャネル障害テーブル３２は、送信チャネル３０１、及び、受信チャネル３０２の項目を含む。MQチャネル障害テーブル３２には、障害が発生した送信チャネルまたは受信チャネルが登録される。

図４を参照して、MQ監視ツール３０による処理のうち、MQミドルウェア、及び、キューを監視し、自ノードのＭＱサーバを閉鎖する処理を説明する。ステップ４００にて、MQ監視ツール３０によるＭＱ監視処理を開始する。ステップ４０１にて、障害が発生しているMQミドルウェアがあるか否かを判定する。

ステップ４０１にて、障害が発生しているMQミドルウェアがないと判定した場合には、ステップ４０２に進み、障害が発生しているキューがあるか否かを判定する。障害が発生しているキューがない場合にはステップ４０１に戻る。障害が発生しているキューがある場合にはステップ４０３に進み、全ての送受信チャネルを停止する。次にステップ４０４にて、全てのMQミドルウェアを停止し、ステップ４０７にて、MQ監視ツール３０の処理を終了する。

ステップ４０１にて、障害が発生しているMQミドルウェアがあると判定した場合には、ステップ４０５にて、他の全てのMQミドルウェアを停止する。次にステップ４０６にて、全ての送受信チャネルを停止し、ステップ４０７にて、MQ監視ツール３０の処理を終了する。

こうして本例では、MQミドルウェアとキューのうち１つでも障害が発生している場合には、他の全てのMQミドルウェアを停止し、自ノードのＭＱサーバを閉鎖する。障害が発生しているMQミドルウェア又はキューがない場合には、監視を継続する。

図５及び図６を参照して、MQ監視ツール３０の処理方法のうち、送信チャネル及び受信チャネルを監視し、自ノードのＭＱサーバを閉鎖する処理を説明する。

ステップ５００にて、MQ監視ツール３０によるＭＱ監視処理を開始する。ステップ５０１を経由してステップ５０２に進む。ステップ５０２にて、MQ監視ツール３０は、MQチャネル障害テーブル３２に登録されている送信又は受信チャネルがあるか否かを判定する。MQチャネル障害テーブル３２に登録されている送信又は受信チャネルがある場合には、ステップ５０３に進む。MQチャネル障害テーブル３２に登録されているチャネルは障害が発生したが、既に、復旧している可能性がある。そこで、ステップ５０３にて、MQチャネル障害テーブル３２に登録されているチャネルが復旧したか否かを判定する。この判定は、そのチャネルが接続されているか切断されているかを調べることによりなされる。接続されていれば、そのチャネルは復旧され、切断されていれば、そのチャネルは復旧されていない。そのチャネルが復旧している場合にはステップ５０４に進む。ステップ５０４にて、復旧しているチャネルを、MQチャネル障害テーブル３２から削除し、ステップ６００に進む。

こうして本例では、MQチャネル障害テーブル３２は常に最新の情報によって更新されるから、MQチャネル障害テーブル３２を読み出すことにより、障害が発生しているチャネルをリアルタイムにて検出することができる。

ステップ５０２にて、MQチャネル障害テーブル３２に登録されている送信又は受信チャネルがないと判定した場合、及び、ステップ５０３にて、MQチャネル障害テーブル３２に登録されているチャネルが復旧していないと判定した場合、そのままステップ６００に進む。

図６を参照して説明する。ステップ６００を経由してステップ６０１に進む。ステップ６０１にて、MQ監視ツール３０は、障害が発生している送信チャネル、又は、受信チャネルがあるか否かを判定する。この判定は、ステップ５０３の場合と同様、送信及び受信チャネルがそれぞれ接続されているか切断されているかを調べることによりなされる。

障害が発生しているチャネルがない場合には、ステップ５０１を経由して、図５の処理に戻る。障害が発生しているチャネルがある場合には、ステップ６０２に進み、障害が発生しているチャネルがMQチャネル障害テーブル３２に登録されているか否かを判定する。登録されていない場合は、ステップ６０３にて、そのチャネルをMQチャネル障害テーブル３２に登録する。

次に、ステップ６０４にて、起動している送信チャネルがあるか否かを判定する。この判定は、MQチャネル障害テーブル３２に登録されている送信チャネルとMQ監視対象テーブル３１に登録している送信チャネルを比較することにより行う。MQ監視対象テーブル３１に登録されている全ての送信チャネルが、MQチャネル障害テーブル３２に登録されている場合には、全ての送信チャネルは停止している。MQ監視対象テーブル３１に登録されている送信チャネルのうち、MQチャネル障害テーブル３２に登録されていないものがある場合には、その送信チャネルは起動している。

ステップ６０４にて、起動している送信チャネルがないと判定された場合には、ステップ６０７に進む。ステップ６０７にて、起動している受信チャネルがあるか否かを判定する。この判定は、MQチャネル障害テーブル３２に登録されている受信チャネルとMQ監視対象テーブル３１に登録している受信チャネルを比較することにより行う。MQ監視対象テーブル３１に登録されている全ての受信チャネルが、MQチャネル障害テーブル３２に登録されている場合には、全ての受信チャネルは停止している。MQ監視対象テーブル３１に登録されている受信チャネルのうち、MQチャネル障害テーブル３２に登録されていないものがある場合には、その受信チャネルは起動している。

起動している受信チャネルがある場合には、ステップ６０８に進む。ステップ６０８にて起動している受信チャネルを停止し、ステップ６０９に進む。起動している受信チャネルがない場合には、そのままステップ６０９に進む。

ステップ６０４にて、起動している送信チャネルがあると判定された場合には、ステップ６０５に進む。ステップ６０５にて、起動している受信チャネルがあるか否かを判定する。ステップ６０５の処理はステップ６０７の処理と同様である。

ステップ６０５にて、起動している受信チャネルがあると判定された場合には、ステップ５０１を経由して、図５の処理に戻る。ステップ６０５にて、起動している受信チャネルがないと判定された場合には、ステップステップ６０６にて、起動している送信チャネルを停止し、ステップ６０９に進む。

ステップ６０９にて、全てのMQミドルウェアを停止する。ステップ６１０にて、MQチャネル障害テーブル３２に登録されている全ての送信チャネル及び受信チャネルを削除し、ステップ６１１にて、MQ監視ツール３０の処理を終了する。

こうして本例では、全ての送信チャネルに障害が発生している場合及び全ての受信チャネルに障害が発生している場合に、自ノードのＭＱサーバを閉鎖する。

以上、本発明の例を説明したが本発明は上述の例に限定されるものではなく、特許請求の範囲に記載された発明の範囲にて様々な変更が可能であることは当業者に容易に理解されよう。

本発明によるＭＱシステムの一実施の形態の全体構成である。 MQ監視対象テーブルの構成例を示す図である。 MQチャネル障害テーブルの構成例を示す図である。 MQミドルウェア、キューを監視し、自ノードのＭＱサーバを閉鎖する処理を示す図である。 本発明によるMQ監視ツールを用いてMQチャネル障害テーブルを更新する処理を示す図である。 本発明によるMQ監視ツールを用いて送信チャネル及び受信チャネルを監視し、自ノードのＭＱサーバを閉鎖する処理を示す図である。

符号の説明

１…自システムのMQサーバ、２，３…他システムのMQサーバ、１０…MQミドルウェア、２０…キュー、４１、４３…送信チャネル、４２、４４…受信チャネル、３０…Q監視ツール、３１…MQ監視対象テーブル、３２…MQチャネル障害テーブル

Claims (6)

1. メッセージを保存するメッセージキューと、該メッセージキューを利用して他のメッセージキューイングシステムとの間でメッセージの送受信を行うミドルウエアと、他のメッセージキューイングシステムに接続された送信チャネル及び受信チャネルと、を有するメッセージキューイングサーバにおいて、
   上記メッセージキュー、上記ミドルウエア、上記送信チャネル及び上記受信チャネルを監視し、上記メッセージキューと上記ミドルウエアの少なくとも１つに障害が発生したとき、全てのミドルウエアを停止し、全ての送信チャネル及び全ての受信チャネルを停止する監視ツールを設けたことを特徴とするメッセージキューイングサーバ。
2. 請求項１記載のメッセージキューイングサーバにおいて、上記監視ツールは、全ての受信チャネル又は全ての送信チャネルに障害が発生したとき、全てのミドルウエアを停止し、全ての送信チャネル及び全ての受信チャネルを停止することを特徴とするメッセージキューイングサーバ。
3. 請求項１記載のメッセージキューイングサーバにおいて、上記監視ツールによる監視対象である上記メッセージキュー、上記ミドルウエア、上記送信チャネル及び上記受信チャネルを登録する監視対象テーブルを有し、上記監視ツールは該監視対象テーブルに登録されたメッセージキュー、ミドルウエア、送信チャネル及び受信チャネルを常時監視することを特徴とするメッセージキューイングサーバ。
4. 請求項３記載のメッセージキューイングサーバにおいて、障害が発生した送信チャネル及び受信チャネルを登録するチャネル障害テーブルを有し、上記監視ツールは上記監視対象テーブルに登録された送信チャネル及び受信チャネルと上記チャネル障害テーブルに登録された送信チャネル及び受信チャネルを比較することによって障害が発生していない送信チャネル又は受信チャネルの有無を判定することを特徴とするメッセージキューイングサーバ。
5. メッセージを保存するメッセージキューを監視することと、該メッセージキューを利用して他のメッセージキューイングサーバとの間でメッセージの送受信を行うミドルウエアを監視することと、他のメッセージキューイングサーバに接続された送信チャネル及び受信チャネルを監視することと、上記メッセージキューと上記ミドルウエアの少なくとも１つに障害が発生したとき、全てのミドルウエア、全ての送信チャネル及び全ての受信チャネルを停止することを特徴とするメッセージキューイングサーバの監視方法。
6. 請求項５記載のメッセージキューイングサーバの監視方法において、全ての受信チャネル又は全ての送信チャネルに障害が発生したとき、全てのミドルウエアを停止し、全ての送信チャネル及び全ての受信チャネルを停止することを特徴とするメッセージキューイングサーバの監視方法。
   
   

Images