10章キュー・マネージャー・クラスターその1 今回 …public.dhe.ibm.com/software/dw/jp/websphere/wmq/mq_intro/...TRIGINT(999999999) となっています。これらの属性の中で、クラスターに関係するのが"REPOS"属性です。これは

- 1 -

10章キュー・マネージャー・クラスターその1

今回は、MQSeries V5.1からサポートされているキュー・マネージャー・クラスターの基本をお話し

したいと思います。

「クラスター」(集団とか群れ)という言葉が示すとおり、このキュー・マネージャー・クラスター

は、ネットワークで接続された複数のキュー・マネージャーで「1つのドメイン」を構成し、より簡単

にメッセージ交換ができるようにするための機能です。

これまでお話ししてきたキュー・マネージャー同士を接続する方法では、通常

●送信側

- リモート・キュー定義

- トランスミッション・キュー

- 送信チャネル

●受信側

- 受信チャネル

- ローカル・キュー

と、5つのオブジェクトを定義する必要がありました。もしn個のキュー・マネージャーが互いに双方向

のメッセージのやり取りを行うような場合、5*n*(n-1)個のオブジェクトを定義する必要があることに

なります。このため、オブジェクト定義の際にスペルを間違えるといった可能性が増えることや、

ネットワークなどの管理が複雑になるなど、かなり面倒になります。

一対のキュー・マネージャーが相互にメッセージの送受信を行う場合でさえ、10オブジェクトが必要

キュー・マネージャー・クラスターを利用すると、このような作業の繁雑さを解消することができま

すし、他にも幾つかの機能が使えるようになります。

まずは、キュー・マネージャー・クラスターの構成から、お話しします。

(以降、キュー・マネージャー・クラスターのことを、単にクラスターと略します)

③ ④

⑦

⑧

⑤

⑨

①

⑥

②

⑩

④受信チャネル⑤ローカル・キュー⑥リモート・キュー定義⑦トランスミッション・キュー⑧送信チャネル

①リモート・キュー定義②トランスミッション・キュー③送信チャネル⑨受信チャネル⑩ローカル・キュー

③ ④

⑦

⑧

⑤

⑨

①

⑥

②

⑩

④受信チャネル⑤ローカル・キュー⑥リモート・キュー定義⑦トランスミッション・キュー⑧送信チャネル

①リモート・キュー定義②トランスミッション・キュー③送信チャネル⑨受信チャネル⑩ローカル・キュー

Copyright IBM Japan, Ltd

- 2 -

10-1. キュー・マネージャー・クラスターの構成

(1) クラスター環境におけるキューマネージャーの種類

先にお話ししたように、このクラスターという機能は、複数のキュー・マネージャーを

1つのグループにまとめるものです。その中には、クラスターに参加している各キュー・

マネージャーの情報を保持するという役割を持つ、「フル・リポジトリー・キュー・マネー

ジャー」と呼ばれる、ちょっと特別なキュー・マネージャーが存在します。

このフル・リポジトリー・キュー・マネージャーは、

- クラスターに参加しているキュー・マネージャーの名前や、存在場所(IPアドレス/

hostname)

- それぞれのキュー・マネージャーが管理しているキューやチャネルの中で、その

「クラスターに公開」しているもの

など各種の情報をリポジトリー(実際には、SYSTEM.CLUSTER.REPOSITRY.QUEUE)に管理し、

必要に応じてクラスター内の他キュー・マネージャーへ配布したり、またそれらの情報を

収集したりしています。もし何らかの問題が起こって、フル・リポジトリー・キュー・

マネージャーが機能出来なくなると、クラスター全体に影響が及ぶことになります。このため

1つのクラスターには、複数のフル・リポジトリー・キュー・マネージャーを配置します。

(補足:非常に多数のキュー・マネージャーによるクラスターを構成するとか、地理的に広域な

クラスターを構成するなどの場合を除き、1つのクラスターに設置するフル・リポジトリー・

キュー・マネージャーは2つで十分です)

フル・リポジトリー・キュー・マネージャーがそのクラスターに関する全ての情報を保持

しているのに対して、他のキュー・マネージャーは

- フル・リポジトリー・キュー・マネージャーに関する情報

- それまで自分が接続した、他のキュー・マネージャーの情報

という「部分的な」情報を、リポジトリー(やはりSYSTEM.CLUSTER.REPOSITRY.QUEUE)内に

持っています。(このことから、これらのキュー・マネージャーのことを、「部分リポジト


- 3 -


リー・キュー・マネージャー」とか、「パーティシャル・リポジトリー・キュー・マネー

ジャー : Particial Repository Queue Manager」などとマニュアルに記述されていることが

あります)

なお、以降では

● フル・リポジトリー・キューマネージャーの事を、単にリポジトリー・キュー・

マネージャー

● フル・リポジトリー・キューマネージャー以外の部分リポジトリー・キュー・マネー

ジャーのことを、メンバー・キュー・マネージャー

と、それぞれ略して話を進めていきます。

(2) クラスター送信チャネルとクラスター受信チャネル

クラスターに参加しているキュー・マネージャー同士を接続する場合、明示的に送信チャネル

(例:SDRタイプのチャネル)と受信チャネル(例:RCVRタイプのチャネル)を作成する必要はあり

ません。

クラスターに参加しているキュー・マネージャーが定義するのは

● リポジトリー・キュー・マネージャーの場合

- 他方のリポジトリー・キュー・マネージャーへのクラスター送信チャネル

- クラスター内に存在する他のキュー・マネージャーから接続されるために使用する

クラスター受信チャネル

②①

クラスター送信チャネル


リポジトリー・キュー・マネージャーは、お互いを接続するようにクラスター送信チャネル/クラスター受信チャネルを定義する.

●①のクラスター送信チャネルは、②のクラスター受信チャネルに接続●②のクラスター送信チャネルは、①のクラスター受信チャネルに接続

②②①①

クラスター送信チャネル


リポジトリー・キュー・マネージャーは、お互いを接続するようにクラスター送信チャネル/クラスター受信チャネルを定義する.

●①のクラスター送信チャネルは、②のクラスター受信チャネルに接続●②のクラスター送信チャネルは、①のクラスター受信チャネルに接続

- 4 -


● メンバー・キュー・マネージャーの場合

- クラスター内に存在する、いずれかのリポジトリー・キュー・マネージャーに

対するクラスター送信チャネル

- クラスター内に存在する他のキュー・マネージャーから接続されるために使用する


と、それぞれ2本のチャネルのみを定義します。

(3) 実際の定義

では、クラスターを構成するには、どのような定義になるのか、実際にコマンドで追ってみる

ことにします。

まず、4つのキュー・マネージャーから構成されるクラスターを構成してみましょう (次ページ

の図参照)。ここで、

- クラスター名は、"galaxy"

- "rqmgr01"と"rqmgr02"が、リポジトリー・キューマネージャー

- "cqmgr03"と"cqmgr04"が、メンバー・キュー・マネージャー

(つまり、パーティシャル・リポジトリー・キュー・マネージャー)

とします。

まずリポジトリー・キューマネージャーが存在しないと、クラスターは機能しませんので、

リポジトリー・キューマネージャーである"rqmgr01"と"rqmgr02"をそれぞれ構成します。

- 5 -

まず、キュー・マネージャーを作成し、起動します。(以下では、WebSphere MQ V6を使って

います)

f:\work>crtmqm rqmgr01

WebSphere MQ キュー・マネージャーが作成されました。

rqmgr01 のデフォルト・オブジェクトを作成または置換しています。

デフォルト・オブジェクトの統計 : 作成 43、置換 0、失敗 0

設定を完了中です。

設定が完了しました。

f:\work>strmqm rqmgr01

WebSphere MQ キュー・マネージャー rqmgr01' を開始しています。

ログのやり直しフェーズ中に、キュー・マネージャー 'rqmgr01' で 5 ログ・レコードが

アクセスされました。

キュー・マネージャー 'rqmgr01' のログのやり直しが完了しました。

キュー・マネージャー 'rqmgr01' のトランザクション・マネージャーの状態が回復され

ました。

WebSphere MQ キュー・マネージャー 'rqmgr01' が始動しました。

続いて、管理コマンド・インターフェース runmqsc を起動します。

f:\work>runmqsc rqmgr01

5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.

キュー・マネージャー rqmgr01 に対して MQSC を始動中です。

rqmgr01は作成したばかりなので、その属性はデフォルトのままです。実際にキュー・マネー

ジャー自身の属性を表示させると


- 6 -


dis qmgr

1 : dis qmgr

AMQ8408: キュー・マネージャーの内容を表示します。

QMNAME(rqmgr01) ACCTCONO(DISABLED)

ACCTINT(1800) ACCTMQI(OFF)

ACCTQ(OFF) ACTIVREC(MSG)

ALTDATE(2005-11-17) ALTTIME(15.37.24)

AUTHOREV(DISABLED) CCSID(932)

CHAD(DISABLED) CHADEV(DISABLED)

CHADEXIT( ) CHLEV(DISABLED)

CLWLDATA( ) CLWLEXIT( )

CLWLLEN(100) CLWLMRUC(999999999)

CLWLUSEQ(LOCAL) CMDLEVEL(600)

COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) CRDATE(2005-11-17)

CRTIME(15.37.24) DEADQ( )

DEFXMITQ( ) DESCR( )

DISTL(YES) INHIBTEV(DISABLED)

IPADDRV(IPV4) LOCALEV(DISABLED)

LOGGEREV(DISABLED) MAXHANDS(256)

MAXMSGL(4194304) MAXPRTY(9)

MAXUMSGS(10000) MONACLS(QMGR)

MONCHL(OFF) MONQ(OFF)

PERFMEV(DISABLED) PLATFORM(WINDOWSNT)

QMID(rqmgr01_2005-11-17_15.37.24) REMOTEEV(DISABLED)

REPOS( ) REPOSNL( )

ROUTEREC(MSG) SCHINIT(QMGR)

SCMDSERV(QMGR) SSLCRLNL( )

SSLCRYP( ) SSLEV(DISABLED)

SSLFIPS(NO)

SSLKEYR(E:\MQV6.0\qmgrs\rqmgr01\ssl\key)

SSLRKEYC(0) STATACLS(QMGR)

STATCHL(OFF) STATINT(1800)

STATMQI(OFF) STATQ(OFF)

STRSTPEV(ENABLED) SYNCPT

TRIGINT(999999999)

となっています。これらの属性の中で、クラスターに関係するのが"REPOS"属性です。これは

このキュー・マネージャーが「どのクラスターのリポジトリー・キューマネージャーとして

機能するのか」を意味するもので、クラスターの名前を指定します。

では、この"rqmgr01"がクラスター"galaxy"のリポジトリー・キューマネージャーとして

- 7 -


機能するように、この"REPOS"属性を変更します。

alter qmgr repos('galaxy')

2 : alter qmgr repos('galaxy')

AMQ8005: WebSphere MQ キュー・マネージャーが変更されました。

dis qmgr repos

3 : dis qmgr repos

AMQ8408: キュー・マネージャーの内容を表示します。

QMNAME(rqmgr01) REPOS(galaxy)

同様に、rqmgr02も作成/開始し、"REPOS"属性を変更します。

次に、クラスター受信チャネルとクラスター送信チャネルを定義します。これらのチャネルは

定義すると、自動的に始動しますので、先にクラスター受信チャネルから作成することを

お勧めします。(クラスター送信チャネルを先に定義した場合、クラスター送信チャネルが

自動始動しても、相手となるクラスター受信チャネルが存在しないため、チャネル状況が

"RETRYING"になり、チャネルが接続するまでに時間が必要になることがあります)

define channel('ch.to.rqmgr01') +

4 : define channel('ch.to.rqmgr01') +

chltype(clusrcvr) trptype(tcp) +

: chltype(clusrcvr) trptype(tcp) +

conname('aaa.bbb.ccc.1(1416)') +

: conname('aaa.bbb.ccc.1(1416)') +

cluster('galaxy')

: cluster('galaxy')

AMQ8014: WebSphere MQ チャネルが作成されました。

クラスター受信チャネルを定義する際のポイントは、最低でも3点あり

● "chltype"属性を、"CLUSRCVR"を設定

● "conname"属性に、自分自身のアドレス(IPアドレスやhostname、port番号など)を設定

● "CLUSTER"属性に、キュー・マネージャーがこのチャネルを使って参加するクラスター

名を設定

になります。(他にも、NETPRTY属性など、受信側で幾つか設定可能な属性はあります)

続いてリスナーを起動しますが、WebSphere MQ V6から、リスナーもキュー・マネージャーが

管理するオブジェクトとして定義および管理出来るようになりました。今回はrunmqlsrを直接

起動するのではなく、こちらの方法で作成します。(runmqlsr自体もまだ残っていますので、

コマンドによるrunmqlsr起動も出来ます)

- 8 -


define listener('lst.rqmgr01') +

6 : define listener('lst.rqmgr01') +

trptype(tcp) +

: trptype(tcp) +

ipaddr('aaa.bbb.ccc.1') port(1416) +

: ipaddr('aaa.bbb.ccc.1') port(1416) +

control(qmgr)

: control(qmgr)

AMQ8626: WebSphere MQ リスナーが作成されました。

この定義では、port 1416をlistenするリスナーを作成したことになります。この定義の中で

"CONTROL"属性がありますが、これはこのリスナーの起動や停止をどのように取り扱うかの

指定です。今回"qmgr"と指定したので、キュー・マネージャー起動時にこのリスナーは開始

され、キュー・マネージャー停止時にはリスナーも停止することになります。今回は新たに

作成したので、"start listener"コマンドでこのリスナーを起動します。

start listener('lst.rqmgr01')

7 : start listener('lst.rqmgr01')

AMQ8021: WebSphere MQ リスナーの開始要求が受け入れられました。

display lsstatus(*)

8 : display lsstatus(*)

AMQ8631: リスナー状況の詳細を表示します。

LISTENER(lst.rqmgr01) STATUS(RUNNING)

PID(2196)

これは、runmqslrを使って

runmqlsr -t tcp -m rmqgr01 -p 1416

リモートのキュー・マネージャーからの接続要求に対応するのと同じです。

同様に、rqmgr02でクラスター受信チャネルとリスナーを定義します。







cluster('galaxy')

: cluster('galaxy')


- 9 -


define listener('lst.rqmgr02') +

6 : define listener('lst.rqmgr02') +

trptype(tcp) +

: trptype(tcp) +

ipaddr('aaa.bbb.ccc.2') port(1418) +

: ipaddr('aaa.bbb.ccc.2') port(1418) +

control(qmgr)

: control(qmgr)


では、次にクラスター送信チャネルを定義します。まず、rqmgr01側です。

define channel('ch.to.qmgr02') +

7 : define channel('ch.to.qmgr02') +

chltype(clussdr) trptype(tcp) +

: chltype(clussdr) trptype(tcp) +



cluster('galaxy')

: cluster('galaxy')


同様に、rqmgr02側も作成します。

define channel('ch.to.qmgr01') +

7 : define channel('ch.to.qmgr01') +





cluster('galaxy')

: cluster('galaxy')


定義が間違いなければ、クラスター送信チャネルが自動始動し、rqmgr01とrqmgr02との間に

2本のチャネルが確立します (次ページ参照)。

- 10 -


(rqmgr01側)

dis chs(*)

12 : dis chs(*)

AMQ8417: チャネル状況の内容を表示します。

CHANNEL(ch.to.rqmgr01) CHLTYPE(CLUSRCVR)

CONNAME(aaa.bbb.ccc.1) CURRENT

RQMNAME(rqmgr02) STATUS(RUNNING)

SUBSTATE(RECEIVE) XMITQ( )


CHANNEL(ch.to.rqmgr02) CHLTYPE(CLUSSDR)

CONNAME(aaa.bbb.ccc.2(1418)) CURRENT


SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)

(rqmgr02側)

dis chs(*)

1 : dis chs(*)

AMQ8417: Display Channel Status details.










これで、2つのリポジトリー・キュー・マネージャー(rqmgr01とrqmgr02)が接続出来たことに

なり、クラスターの準備が完了したことになります。

もし"STATUS(RUNNNING)"とならなかった場合には、再度チャネルの定義(特にconname属性.

スペルミスも含めて)があっているかどうか、またLinuxのようにFIREWALL機能を持っている

ようなOSを使っている場合には指定したportが利用可能になっているか、などの点を確認して

下さい。

次に、メンバー・キュー・マネージャーを作成し、クラスターへ参加させましょう。まず、

cqmgr03を作成し、起動します。

- 11 -


[mqm@jupiter ~]$ crtmqm cqmgr03

WebSphere MQ queue manager created.

Creating or replacing default objects for cqmgr03.

Default objects statistics : 40 created. 0 replaced. 0 failed.

Completing setup.

Setup completed.

[mqm@jupiter ~]$ strmqm cqmgr03

WebSphere MQ queue manager 'cqmgr03' starting.

5 log records accessed on queue manager 'cqmgr03' during the log replay phase.

Log replay for queue manager 'cqmgr03' complete.

Transaction manager state recovered for queue manager 'cqmgr03'.

WebSphere MQ queue manager 'cqmgr03' started.

リポジトリー・キュー・マネージャーであるrqmgr01やrqmgr02と違い、メンバーとしてクラ

スターに参加するだけなので、今回作成する必要があるのは、

● リスナー

● クラスター受信チャネル

● クラスター送信チャネル

の3つになります。管理コマンド・インタフェースから、まずリスナーの作成とその起動を

行いましょう。

define listener('lst.cqmgr03') +

2 : define listener('lst.cqmgr03') +

trptype(tcp) ipaddr(aaa.bbb.ccc.3) port(1415) +

: trptype(tcp) ipaddr(aaa.bbb.ccc.3) port(1415) +

control(qmgr)

: control(qmgr)

AMQ8626: WebSphere MQ listener created.

start listener ('lst.cqmgr03')

3 : start listener ('lst.cqmgr03')

AMQ8021: Request to start WebSphere MQ Listener accepted.

続いて、クラスター受信チャネルを作成します。

define channel('ch.to.cqmgr03') +

4 : define channel('ch.to.cqmgr03') +




- 12 -



cluster('galaxy')

: cluster('galaxy')

AMQ8014: WebSphere MQ channel created.

更に、クラスター送信チャネルを定義します。このとき、先に起動したリポジトリー・

キュー・マネージャーのrqmgr01か、またはrqmgr02のどちらかに接続するように、チャネルを

作成します。(今回は、rqmgr01へ接続するように、クラスター送信チャネルを作成します)







cluster('galaxy')

: cluster('galaxy')

AMQ8014: WebSphere MQ channel created.

暫くすると、チャネルが起動し、直接指定したリポジトリー・キュー・マネージャーrqmgr01

だけでなく、rqmgr02にも自動的に接続します。

dis chs(*)

1 : dis chs(*)







CHANNEL(ch.to.cqmgr03) CHLTYPE(CLUSRCVR)










- 13 -






初めの2つがリポジトリー・キュー・マネージャー rqmgr01とのチャネル接続を、残りの2つが

リポジトリー・キュー・マネージャー rqmgr02との接続状況になります。では、実際に

rqmgr02上でチャネル状況を表示させると、以下のようになります。

dis chs(*)

1 : dis chs(*)














RQMNAME(cqmgr03) STATUS(RUNNING)



CHANNEL(ch.to.cqmgr03) CHLTYPE(CLUSSDR)




こちらも初めの2つがリポジトリー・キュー・マネージャー rqmgr01との接続を表しており、

残りの2つが「自動的に生成され、起動した」cqmgr03へのチャネル状況になります。

今の状況を図にすると、次ページのようになります。

- 14 -


(4) クラスターへのキュー・マネージャー追加

上の図のようにクラスター"galaxy"は、現時点で3つのキュー・マネージャーから構成されて

います。このクラスターに、新規キュー・マネージャーとしてcqmgr04を追加してみましょう。

といっても、手順は簡単で、cqmgr04を作成し、cqmgr03と同様に

- リスナー

- クラスター送信チャネル

- クラスター受信チャネル

を定義するだけで、クラスター "galaxy"に参加出来ます。

define listener('lst.cqmgr04') +

1 : define listener('lst.cqmgr04') +

trptype(tcp) ipaddr(aaa.bbb.ccc.4) port(1417) control(qmgr)

: trptype(tcp) ipaddr(aaa.bbb.ccc.4) port(1417) control(qmgr)


start listener('lst.cqmgr04')

2 : start listener('lst.cqmgr04')

AMQ8021: WebSphere MQ リスナーの開始要求が受け入れられました。

define channel('ch.to.cqmgr04') +

3 : define channel('ch.to.cqmgr04') +




- 15 -



cluster('galaxy')

: cluster('galaxy')








cluster('galaxy')

: cluster('galaxy')


暫くすると、クラスター送信チャネルとクラスター受信チャネルが起動します。この時点で、

cqmgr04はクラスター"galaxy"に参加したことになります。確認するために"display clusqmgr"

というコマンドを使うと、その時点でキュー・マネージャーが認識したクラスター内に存在

するキュー・マネージャーを表示させることが出来ます。

(cqmgr04上)

dis clusqmgr(*)

7 : dis clusqmgr(*)

AMQ8441: クラスター・キュー・マネージャーの詳細を表示します。

CLUSQMGR(cqmgr04) CHANNEL(ch.to.cqmgr04)

CLUSTER(galaxy)


CLUSQMGR(rqmgr01) CHANNEL(ch.to.rqmgr01)

CLUSTER(galaxy)



CLUSTER(galaxy)

この表示を見ると、この段階ではまだcqmgr04はcqmgr03の存在を認識していないことが分かり

ます。ちなみに、リポジトリー・キュー・マネージャー rqmgr02で"display clusqmgr"

コマンドを実行すると、こちらはcqmgr03を含む全てのキュー・マネージャーが存在することを

認識していることが分かります (次ページ参照)。

(rqmgr02上)

display clusqmgr(*)

1 : display clusqmgr(*)

AMQ8441: Display Cluster Queue Manager details.

- 16 -



CLUSTER(galaxy)



CLUSTER(galaxy)



CLUSTER(galaxy)



CLUSTER(galaxy)

10-2. クラスター内でのメッセージ送受信

やっとクラスターの構成が終わりましたので、ここでは実際にメッセージの送受信を行って

みたいと思います。

クラスターを使わない「従来のキュー・マネージャー接続」を行った場合、次ページの図のよう

にリモート・キュー定義を初めとする幾つかのオブジェクトを作成する必要がありました。

さらにチャネルを起動させることで、リモート・キュー定義されたキューにMQPUTされた

メッセージの転送がトランスミッション・キュー経由で行われていました。

- 17 -


これに対して、クラスターを使うとどうなるでしょうか。例として、cqmgr03からcqmgr04への

メッセージ転送を考えてみたいと思います。

(1) クラスター・キュー

メッセージの宛先となるローカル・キューを定義しなければいけないのは、クラスター環境

でも同じです。そこで、cqmgr04に"lq01.cqmgr04"を作成します。このとき、この

"lq01.cqmgr04"を、クラスター"galaxy"に参加している他のキュー・マネージャーに「公開」

するために、"cluster"属性にクラスター名"galaxy"を指定します。

define qlocal('lq01.cqmgr04') +

cluster('galaxy')

この定義によりローカル・キュー"lq01.cqmgr04"が作成されると、cqmgr04は「クラスター・

キュー "lq01.cqmgr04"を作成した」という情報を、リポジトリー・キュー・マネージャー

"rqmgr01"と"rqmgr02"へ送信し、リポジトリーへの登録を行います。もう少し具体的には、

①cqmgr04は、この情報をリポジトリー・キュー・マネージャーへメッセージとして送信

②リポジトリー・キュー・マネージャーは、受け取ったメッセージをシステム・キュー

"SYSTEM.CLUSTER.REPOSITORY.QUEUE"へ登録

という処理が行われます。この結果、クラスター"galaxy"に"lq01.cqmgr04"が登録されたこと

になります。

- 18 -


では、まだcqmgr04の存在を認識していないcqmgr03からサンプル・プログラムamqsputを

使って、このcqmgr04上のlq01.cqmgr04へメッセージを送ってみましょう。

[mqm@jupiter ~]$ /opt/mqm/samp/bin/amqsput lq01.cqmgr04 cqmgr03

Sample AMQSPUT0 start

target queue is lq01.cqmgr04

This is cluster test

message from cqmgr03

Sample AMQSPUT0 end

[mqm@jupiter ~]$

cqmgr03は、cqmgr04とその管理下にあるlq01.cqmgr04をまだ知らないどころか、転送するた

めのリモート・キュー定義などを持っていない状態にも関わらず、amqsputは何もエラーを

起こさず、完了します。この時点で、cqmgr03上のチャネル状況を表示させると、

dis chs(*)

1 : dis chs(*)






















CHANNEL(ch.to.cqmgr04) CHLTYPE(CLUSSDR)

- 19 -





となり、一番最後にcqmgr04との間にチャネルが確立していることが分かります。当然cmqgr04

上でチャネル状況を表示させると、上記のクラスター送信チャネル"ch.to.cqmgr04"に対して






と、クラスター受信チャネルが存在していることが分かります。ここで、lq01.cqmgr04の

CURDEPTH属性(キュー内に存在するメッセージ数)を確認すると、

dis ql('lq01.cqmgr04') curdepth

6 : dis ql('lq01.cqmgr04') curdepth

AMQ8409: キューの内容を表示します。

QUEUE(lq01.cqmgr04) TYPE(QLOCAL)

CURDEPTH(2)

となり、amqsgetで取り出すと、次ページのようにcqmgr03上からamqsputを使って送信した

メッセージを読み出すことが出来ます。

f:\work>amqsget lq01.cqmgr04 cqmgr04

Sample AMQSGET0 start

message <This is cluster test>

message <message from cqmgr03>

no more messages

Sample AMQSGET0 end

f:\work>

- 20 -


このように、クラスター環境下では事前にリモート・キュー定義を行わなくとも、またその

宛先キューがどのキュー・マネージャー上に定義されているかを知らなくても、メッセージを

送信することができます。

(2) クラスター・トランスミッション・キュー

(1)で見てきたように、クラスター環境でのメッセージの送信では、トランスミッション・

キューをユーザーが独自に作成する必要がありません。

前述のチャネル状況を確認した際XMITQ属性に表示されたように、クラスター環境下では

"SYSTEM.CLUSTER.TRANSMIT.QUEUE"というキューを使って、全てのメッセージ送信を行います。

(WebSphere MQ V6.0でのSYSTEM.CLUSTER.TRANSMIT.QUEUEの属性)

dis ql(system.cluster.transmit.queue)

1 : dis ql(system.cluster.transmit.queue)

AMQ8409: キューの内容を表示します。

QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE) TYPE(QLOCAL)

ACCTQ(QMGR) ALTDATE(2005-11-28)

ALTTIME(14.10.53) BOQNAME( )

BOTHRESH(0) CLUSNL( )

CLUSTER( ) CLWLPRTY(0)

CLWLRANK(0) CLWLUSEQ(QMGR)

CRDATE(2005-11-21) CRTIME(16.36.16)

CURDEPTH(0) DEFBIND(OPEN)

DEFPRTY(0) DEFPSIST(NO)

DEFSOPT(SHARED) DEFTYPE(PREDEFINED)

DESCR(WebSphere MQ Cluster Transmission Queue)

DISTL(YES) GET(ENABLED)

HARDENBO INITQ( )

IPPROCS(1) MAXDEPTH(999999999)

MAXMSGL(4194304) MONQ(QMGR)

MSGDLVSQ(PRIORITY) TRIGGER

NPMCLASS(NORMAL) OPPROCS(1)

PROCESS( ) PUT(ENABLED)

QDEPTHHI(80) QDEPTHLO(20)

QDPHIEV(DISABLED) QDPLOEV(DISABLED)

QDPMAXEV(ENABLED) QSVCIEV(NONE)

QSVCINT(999999999) RETINTVL(999999999)

SCOPE(QMGR) SHARE

STATQ(QMGR) TRIGDATA( )

TRIGDPTH(1) TRIGMPRI(0)

- 21 -


TRIGTYPE(FIRST) USAGE(XMITQ)

このキュー自体はローカル・キューですので、alterコマンドなどで属性を変更することが

可能ですが、キュー・マネージャー内部で使用するものですので、むやみに変更したり、

削除したりしないよう、気をつけて下さい。

(3) リポジトリー情報

(1)でメッセージの送信ができたのは、先に挙げたcqmgr04上でのクラスター・キュー

"lq01.cqmgr04"の作成で

①cqmgr04は、この情報をリポジトリー・キュー・マネージャーへメッセージとして送信

②リポジトリー・キュー・マネージャーは、受け取ったメッセージをシステム・キュー

"SYSTEM.CLUSTER.REPOSITRY"へ登録

という処理が行われたことと関係します。

まだcqmgr04とその管理下にある"lq01.cqmgr04"を認識していないcqmgr03は、amqsputでの

メッセージ書き込みが発生すると、

③自分自身の管理下に、ローカル・キュー"lq01.cqmgr04"が存在するかどうかを確認

④もし存在しなかったら、自分が持っているリポジトリー(SYSTEM.CLUSTER.REPOSITRY)

内にあるローカル・キャッシュの情報を検索

⑤ローカル・キャッシュにその情報が存在していれば、その情報を基にメッセージの

転送先情報を作成する. 存在していない場合、

ⅰ. クラスター内のリポジトリー・キューマネージャーへ問い合わせて、情報を入手.

ⅱ. その情報を基に、メッセージの宛先情報を作成

⑥作成された宛先情報を付加して、書き込まれたメッセージを(2)でお話しした

SYSTEM.CLUSTER.TRANSMIT.QUEUEキュー経由で、キュー・マネージャー "cqmgr04"への

転送を実行

という処理を行い、メッセージ転送を実行します (次ページの図を参照)。

(注)

③でキュー・マネージャー自身が、メッセージの宛先となるキューと同じ名前の

ローカル・キューを直接管理していた場合には、そのローカル・キューが優先

されます。ただし、WebSphere MQ V6からは設定により、ローカル・キューより

も、他のキュー・マネージャー上に存在する同一名称のキューを優先させる

ことができるようになっています。

- 22 -

SYSTEM.CLUSTER.REPOJITORY.QUEUEに格納される情報は、

- リポジトリー・キューマネージャーでは、クラスターに参加している各メンバーと

その資源

- メンバー側では、リポジトリー・キューマネージャーに関する情報と、自分が

アクセスしたクラスター内の資源とそれを管理するキュー・マネージャーの情報

です。これらの情報は、リポジトリー・キューマネージャー同士、およびリポジトリー・

キューマネージャーとメンバーとの間で、定期的に更新が行われます。

もし使われなくなったクラスター・キューが存在するような場合でも、ある程度の猶予期間

その情報はキャッシュされており、その猶予期間が経過した後削除されることになります。

なお、クラスターに参加していたキュー・マネージャーが長期間リポジトリー・キュー・

マネージャーと「音信不能」になるような場合には、そのメンバーをクラスターから外した

方がいいでしょう。


Documents

10章キュー・マネージャー・クラスターその1 今回 …public.dhe.ibm.com/software/dw/jp/websphere/wmq/mq_intro/...TRIGINT(999999999) となっています。これらの属性の中で、クラスターに関係するのが"REPOS"属性です。これは