0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

[MQ学習③]IBM MQのキューマネージャー接続(メッセージチャネル)をGUIで試す

Last updated at Posted at 2024-12-14

はじめに

前回はMQIクライアント接続でのMQ操作を行った。

今回は、もう一つの接続形態である、メッセージチャネルを経由したキューの伝搬を確認する。

接続イメージは以下。

MQ虎の巻1 より「キューマネージャー接続」の図

image.png

MQ虎の巻2より「メッセージチャネル」の図

image.png

環境構成

前回 も利用したコンテナ環境を利用する。

完成イメージは以下。

image.png

  • キューマネージャー、リスナは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コンソールにアクセスすることができる(前々回を参照)。

image.png

以降はGUIで構築していく。

まずはQM1側から進める。https://localhost:9443 を操作する。

リモートキュー

以下の4つを指定。他はデフォルト。

  • キュー名:TEST_REMOTE_QUEUE
  • リモート・キュー:TEST_DEST_QUEUE (=宛先ローカルキュー名)
  • リモート・キュー・マネージャー:QM2
  • 伝送キュー:TEST_DEST_QUEUE (=宛先ローカルキュー名と同名)

image.png

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

以下2つを指定。「トランスミッションキューであること」以外は普通のローカルキューと違いは無い。
虎の巻でも「特殊な目的をもつローカルキュー」の一つとして紹介されている

  • キュー名:TEST_DEST_QUEUE
  • 使用法:伝送

image.png

送信側チャネル

以下を指定して作成。接続名の指定が独特である点に注意。docker networkを共有しているため、QM1_containerから、QM2_containerを名前解決でき、ポートもそのまま指定できる。

  • チャネル名:QM1.TO.QM2
  • チャネル・タイプ:送信側
  • 接続名:QM2_container(1414)
  • 伝送キュー:TEST_DEST_QUEUE

image.png

image.png

受信側チャネル

続いてQM2側を構築する。https://localhost:9444 を操作する。

受信側チャネルは単に名前の指定のみ。

image.png

宛先ローカルキュー

こちらも単に名前のみ指定して作成。

image.png

送信テスト

チャネル接続

QM1側の送信側チャネルを「開始」し、チャネルを接続する

image.png

実行中の表示になった。

image.png

キュー送信

QM1上のリモートキューを選択し、「メッセージの作成」を押す

image.png

適当なメッセージを記載して「送信」
image.png

正常にメッセージが作成された。トランスミッションキューに滞留していないことが確認ポイント
image.png

QM2側の宛先ローカルキューを見ると、無事にキューが伝搬してきたことがわかる。

image.png

補足:

チャネルが断絶した状態でキューを送ろうとすると、キューはトランスミッションキューに滞留する。本番で起きると困る。

チャネルが停止している状態で・・・
image.png

リモートキューにエンキューすると

image.png

キューはトランスミッションキューに滞留する。こうなると困るので、実運用ではトランスミッションキューの滞留状況を監視しておきたい。

image.png

チャネル断絶が解消すると(再度チャネルを開始すると)、
image.png

キュー滞留は解消、
image.png

QM2へ配送される。これで安心。
image.png

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?