はじめに
前回はMQIクライアント接続でのMQ操作を行った。
今回は、もう一つの接続形態である、メッセージチャネルを経由したキューの伝搬を確認する。
接続イメージは以下。
↓MQ虎の巻1 より「キューマネージャー接続」の図
↓MQ虎の巻2より「メッセージチャネル」の図
環境構成
前回 も利用したコンテナ環境を利用する。
完成イメージは以下。
- キューマネージャー、リスナはMQコンテナ起動時にデフォルトで作成されるものを使用する。
- 各オブジェクトの命名はMQ虎の巻7章:ネーミングルールを参考に以下とする
- リモートキュー:TEST_REMOTE_QUEUE
- トランスミッションキュー:TEST_DEST_QUEUE (宛先ローカルキューと同名)
- 送信側チャネル:QM1.TO.QM2
- 受信側チャネル:QM1.TO.QM2 (送信側と同名)
- 宛先ローカルキュー:TEST_DEST_QUEUE
MQコンテナ起動
# コンテナ間で名前解決・通信できるようにnetworkを定義
docker network create QM-network
# 永続化用のvolumeを作成
docker volume create qm1data
docker volume create qm2data
# QM1_containerを起動
docker run \
--name QM1_container \
--detach \
--rm \
--network QM-network \
--volume qm1data:/mnt/mqm \
--publish 1414:1414 \
--publish 9443:9443 \
--env LICENSE=accept \
--env MQ_QMGR_NAME=QM1 \
--env MQ_DEV=false \
--env MQ_APP_USER=app \
--env MQ_APP_PASSWORD=passw0rd \
--env MQ_ADMIN_USER=admin \
--env MQ_ADMIN_PASSWORD=passw0rd \
icr.io/ibm-messaging/mq:9.2.4.0-r1
# QM2_containerを起動
# そのままだとホストのポート番号が重複するため、ホスト側にマッピングするポートを1ずつずらしている
docker run \
--name QM2_container \
--detach \
--rm \
--network QM-network \
--volume qm2data:/mnt/mqm \
--publish 1415:1414 \
--publish 9444:9443 \
--env LICENSE=accept \
--env MQ_QMGR_NAME=QM2 \
--env MQ_DEV=false \
--env MQ_APP_USER=app \
--env MQ_APP_PASSWORD=passw0rd \
--env MQ_ADMIN_USER=admin \
--env MQ_ADMIN_PASSWORD=passw0rd \
icr.io/ibm-messaging/mq:9.2.4.0-r1
キューマネージャー・リスナ存在確認
キューマネージャー・リスナは公式MQコンテナ起動時にデフォルトで作成されるものを利用する
# キューマネージャーQM1, QM2それぞれの存在確認。Runningになっている
[root@my-instance ~]# docker exec -it QM1_container dspmq
QMNAME(QM1) STATUS(Running)
[root@my-instance ~]# docker exec -it QM2_container dspmq
QMNAME(QM2) STATUS(Running)
# QM2側のリスナの存在確認。1414ポートでlistenしている
[root@my-instance ~]# docker exec -it QM2_container sh -c "echo \"DISPLAY LSSTATUS(*) ALL\" | runmqsc QM2 "
5724-H72 (C) Copyright IBM Corp. 1994, 2021.
Starting MQSC for queue manager QM2.
1 : DISPLAY LSSTATUS(*) ALL
AMQ8631I: Display listener status details.
LISTENER(SYSTEM.LISTENER.TCP.1) STATUS(RUNNING)
PID(321) STARTDA(2024-12-14)
STARTTI(19.08.01) DESCR( )
TRPTYPE(TCP) CONTROL(QMGR)
IPADDR(*) PORT(1414)
BACKLOG(100)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.
各種キュー・チャネル作成
https://localhost:9443, 9444 でそれぞれのMQに対応したGUIコンソールにアクセスすることができる(前々回を参照)。
以降はGUIで構築していく。
まずはQM1側から進める。https://localhost:9443 を操作する。
リモートキュー
以下の4つを指定。他はデフォルト。
- キュー名:
TEST_REMOTE_QUEUE
- リモート・キュー:
TEST_DEST_QUEUE
(=宛先ローカルキュー名) - リモート・キュー・マネージャー:
QM2
- 伝送キュー:
TEST_DEST_QUEUE
(=宛先ローカルキュー名と同名)
トランスミッションキュー
以下2つを指定。「トランスミッションキューであること」以外は普通のローカルキューと違いは無い。
※虎の巻でも「特殊な目的をもつローカルキュー」の一つとして紹介されている
- キュー名:
TEST_DEST_QUEUE
- 使用法:
伝送
送信側チャネル
以下を指定して作成。接続名の指定が独特である点に注意。docker networkを共有しているため、QM1_containerから、QM2_containerを名前解決でき、ポートもそのまま指定できる。
- チャネル名:
QM1.TO.QM2
- チャネル・タイプ:
送信側
- 接続名:
QM2_container(1414)
- 伝送キュー:
TEST_DEST_QUEUE
受信側チャネル
続いてQM2側を構築する。https://localhost:9444 を操作する。
受信側チャネルは単に名前の指定のみ。
宛先ローカルキュー
こちらも単に名前のみ指定して作成。
送信テスト
チャネル接続
QM1側の送信側チャネルを「開始」し、チャネルを接続する
実行中の表示になった。
キュー送信
QM1上のリモートキューを選択し、「メッセージの作成」を押す
正常にメッセージが作成された。トランスミッションキューに滞留していないことが確認ポイント
QM2側の宛先ローカルキューを見ると、無事にキューが伝搬してきたことがわかる。
補足:
チャネルが断絶した状態でキューを送ろうとすると、キューはトランスミッションキューに滞留する。本番で起きると困る。
リモートキューにエンキューすると
キューはトランスミッションキューに滞留する。こうなると困るので、実運用ではトランスミッションキューの滞留状況を監視しておきたい。