Redhat OpenshiftでIBM MQのUniform Clusterを動かす (1)

# Redhat Openshift環境でIBM MQのUniform Clusterを構成してみる

# 1.Uniform Clusterとは

IBM MQが提供するUniform Cluster機能は従来からのMQクラスター機能をベースに、MQクライアント接続の自動再接続を用いて接続の負荷分散を可能とする機能です。
MQクライアントは、キュー（回復可能資源）を持ちません。アプリケーションがTCPネットワークを経由し、キュー・マネージャーに対しメッセージのPUT/GET（JMSだとSEND/RECEIVE)処理を行います。
詳しい説明はこちら：https://www.ibm.com/docs/ja/ibm-mq/9.2?topic=cluster-about-uniform-clusters#q132725_
日本語訳だと”均一クラスター”となっていますが、直訳そのものなんで、ここではUniform Clusterで進めます。  

# 2.Open Shift上でのUniform Clusterの構成
IBMクラウド上でRedhat Openshiftを用いてUniform Clusterの構成を実施する際は、大まかには以下のステップが必要です。
0)準備：IBM MQ Operatorの導入

1)キュー・マネージャーの作成

2)MQクラスターの構成

3)Uniform Cluserの構成

4)MQクライアントからの接続情報の構成（CCDT：CLIENT CHANNEL DEFINITION TABLEの作成）とCLIENTからの接続

ここでは主に2)&3)について説明します。
0)はこちら参照 https://www.ibm.com/docs/ja/ibm-mq/9.2?topic=openshift-installing-uninstalling-mq-operator-red-hat

1)については、こちらの記事がまとまっているので参照。
https://qiita.com/ken-sato/items/10581e40e447b67e57a9

4)については続編で紹介します。

## 1)キュー・マネージャーの作成

## 2)MQクラスターの構成
MQクラスターでは複数のキュー・マネージャーで構成されます。 クラスター内資源を全管理するのがフル・リポジトリーで通常は2台構成を組みます。 MQクラスターでは自分宛のチャネルを定義（明示定義）し、フル・リポジトリーに伝える事で、他のキュー・マネージャーにも接続先情報が必要となった時点で共有されます。
ここでは2つのキュー・マネージャーをフル・リポジトリーとして構成する事にします。 ステップとしては、以下になります。
### (1)クラスター受信・クラスター送信チャネルの定義
チャネル定義のCONNAMEには接続先となるIP/PORTを指定します。 PORTを明示指定しない場合は"1414"が使われます。 
CHLTYPEチャネルタイプ：クラスター受信チャネル(CLUSRCVR)では自分宛の指定を行い、チャネルタイプ：クラスター送信チャネル（CLUSSDR)ではペアとなる相手先の指定を行います。
CLUSTERパラメーターはクラスター名で、"CLUST1"としています。 
これら定義体はシークレットに保管・利用することでPODの再起動をまたがって呼び出されますので”REPLACE”オプション付きとしています。

ペアのフル・リポジトリーをxxxx.FR1/xxxx.FR2とした場合は以下のようなチャネル定義になります。 (xxxx.はQiita記事としては、ちょっと。。。という事でお察しください)

FR1では以下のようになります。
    
    DEFINE CHANNEL(TO.FR1) CHLTYPE(CLUSRCVR) CONNAME('自分宛のサービス名') CLUSTER(CLUST1) REPLACE
    ALTER QMGR REPOS(CLUST1) 
    DEFINE CHANNEL(TO.FR2) CHLTYPE(CLUSSDR) CONNAME('FR2宛のサービス名') CLUSTER(CLUST1) REPLACE

FR2では対称構成で以下のようになります。
    
    DEFINE CHANNEL(TO.FR2) CHLTYPE(CLUSRCVR) CONNAME('自分宛のサービス名') CLUSTER(CLUST1) REPLACE 
    ALTER QMGR REPOS('CLUST1')
    DEFINE CHANNEL(TO.FR1) CHLTYPE(CLUSSDR) CONNAME('FR1宛のサービス名') CLUSTER(CLUST1) REPLACE
    
途中のALTER QMGR REPOSコマンドでフル・リポジトリーに昇格させています。

ネットワークのサービス名は以下のようにコンソールで表示されます。 
ここでは、左横のメニュー：ネットワーク→サービスでPod作成時に振られたサービス名：pod名+"-ibm-mq"が自分宛のアドレスとして該当します。
(下のはFR2側の例）

![5041b732756b2da1005698d15d75180f4b9b1a85b7f052ef65f3fd7799d3cf98.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2410463/dc3a6b43-ac82-2b73-e8fb-a7c747d920f7.png)



### (2)接続状態の確認とか
DISPLAY CHSコマンドで相互接続されたことを確認します。
FR1側からは以下のようにFR2との間でCLUSSDR（FR2宛クラスター送信チャネル）とCLUSRCVR（FR1向けクラスター受信チャネル）が接続されています。

    sh-4.4$ runmqsc
    5724-H72 (C) Copyright IBM Corp. 1994, 2021.
    Starting MQSC for queue manager OCQMxxxxFR1.
    dis chs(TO*) STATUS
         1 : dis chs(TO*) STATUS
    AMQ8417I: Display Channel Status details.
        CHANNEL(TO.FR2)                         CHLTYPE(CLUSSDR)
        CONNAME(172.21.84.206(1414))            CURRENT
        RQMNAME(OCQMxxxxFR2)                   STATUS(RUNNING)
        SUBSTATE(MQGET)                         XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
    AMQ8417I: Display Channel Status details.
        CHANNEL(TO.FR1)                         CHLTYPE(CLUSRCVR)
        CONNAME(172.17.20.249)                  CURRENT
        RQMNAME(OCQMxxxxFR2)                   STATUS(RUNNING)
        SUBSTATE(RECEIVE) 


DISPLAY CLUSQMGRコマンドで双方とも認識されている事が確認できます。 

    dis clusqmgr(*) QMTYPE STATUS
     1 : dis clusqmgr(*) QMTYPE STATUS
    MQ8441I: Display Cluster Queue Manager details.
       CLUSQMGR(OCQMxxxxFR1)                  CHANNEL(TO.FR1)
       CLUSTER(CLUST1)                         QMTYPE(REPOS)
       STATUS(RUNNING)                      
    AMQ8441I: Display Cluster Queue Manager details.
       CLUSQMGR(OCQMxxxxFR2)                  CHANNEL(TO.FR2)
       CLUSTER(CLUST1)                         QMTYPE(REPOS)
       STATUS(RUNNING) 


QMTYPEが"REPOS"で両方ともフル・リポジトリーとして稼働している事を確認できます。
良い子は反対側のFR2側からも確認しておいてください。

## 3)Uniform Cluserの構成
上記 2)まででMQクラスター構成が完了したら、Uniform Cluserの構成はもう少しです。
qm.iniにAutoCluster/ClusterNameの定義を行い再起動するだけです。 ここではクラスター名：”CLUST1”です。

    Channels:
    MQIBindType=STANDARD
    AutoCluster:
    ClusterName=CLUST1
    Type=Uniform


起動時にAMQ9883のメッセージが表示されます。 （FR2のサンプル）

     2021-12-13T11:43:41.227Z AMQ9883I: Joining uniform cluster CLUST1. [CommentInsert1(CLUST1)]
     (中略)
     2021-12-13T11:43:41.446Z Started queue manager
 
 "DISPLAY APSTATUS”コマンドでアプリケーションの接続状態を確認できます。 

    dis apstatus(*) type(QMGR)
     1 : dis apstatus(*) type(QMGR)
    AMQ8932I: Display application status details.
       APPLNAME(runmqserver)                   ACTIVE(YES)
       COUNT(1)                                MOVCOUNT(0) 
       BALSTATE(NOTAPPLIC)                     LMSGDATE(2021-12-17)
       LMSGTIME(02.09.17)                      QMNAME(OCQMxxxxFR1)
       QMID(OCQMxxxxFR1_2021-12-15_01.23.12)
       TYPE(QMGR)                           
    AMQ8932I: Display application status details.
       APPLNAME(runmqserver)                   ACTIVE(YES)
       COUNT(1)                                MOVCOUNT(0) 
       BALSTATE(NOTAPPLIC)                     LMSGDATE(2021-12-17)
       LMSGTIME(02.08.35)                      QMNAME(OCQMxxxxFR2)
       QMID(OCQMHxxxxFR2_2021-10-05_12.21.46)
       TYPE(QMGR)    

鋭い方はFR1のQMIDがFR2に比べて進んでいる、と気づかれたかもしれません。 訳あってFR1のPodは再作成しています。 定義体は全てシークレットに保存していたので、そのまま再構成できています。 ただ、コンソールで動的に定義したり、変更した資源はなくなっているので、きちんと都度シークレットに反映しておくほうがよいです。 
MQ CLUSTER構成が作成できたので、次はMQクライアントからの接続となります。