IBM MQの高可用構成 Native HAをOpenShift上に構築する

メッセージングミドルウェアのIBM MQ(以下MQ)のOpenShift上で実現する高可用性構成のNative HAを構成したので､手順や構成について残す｡

## MQの高可用性構成

MQではオンプレミス上での構成における高可用性構成として以下を構成可能である｡

- HAクラスター構成
    - 2ノード間のActive/Standby構成
    - PowerHA(AIX)やMSCS(MicroSoft Clustering Service)(Windows)のようなHAマネージャーを使用したfailover構成
- マルチインスタンス・キューマネージャー
    - 2ノード間のActive/Standby構成
    - HAクラスター構成のようなHAマネージャーを使用せずに､MQのfailover構成を実現する
- HA RDQM構成
    - 3ノードでのQuorum構成
        - pacemakerを利用して､相互の稼働監視を行う
    - ノード間のデータの同期はDRBD(Distributed Replicated Block Device)を利用したレプリケーションを行う
        - 上記2つの高可用性構成は､MQを構成するキューファイルやトランザクションログはNFSなどの共用ディスク上に配置して構成する
 
OpenShiftにおいては､
MQをStatefulSetとして構成､PVをマウントして必要なデータを外だしにすることで､Podの再作成でもキューのメッセージの喪失を防ぎ､セルフヒーリングによって障害からの復旧も行える｡
(一応､2Pod構成でマルチインスタンス構成を組むことも可能であるが､1Podでセルフヒーリングによるリカバリとの時間差異はコンテナ再作成の時間程度となる(未検証))

今回検証したNative HAは､HA RDQMの様に3ノード(Pod)での高可用性を実現する構成となる｡
HA RDQMと異なるのは､データのレプリケーションやノード間の稼働監視にDRBDやpacemakerを使用せず､MQのネイティブでの実装となっている点である｡

## 環境

OpenShift 4.7.37_1542 @ IBM Cloud VPC Single AZ
MQ V9.2.3

## Operatorの導入

Native HA構成はMQ Operatorでの導入のみサポートされるため､Operatorの導入が必要となる｡
Operatorの導入は[マニュアル](https://www.ibm.com/docs/ja/ibm-mq/9.2?topic=openshift-installing-uninstalling-mq-operator-red-hat)を参考に導入する｡

## Native HAの構成

各設定はGUIで設定可能｡
(`template.pod.containers.env`など､一部フィールドはGUIでは指定できないので､YAML viewで直接編集する)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/137607/df0b8a46-5739-e115-bf46-e7f3b3bc5e39.png)

以下は､GUIでの設定で生成されたyaml｡

```yaml
apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: mq-nativeha
  labels:
    app: mq-nativeha
  namespace: mq
spec:
  license:
    accept: true
    license: L-RJON-BZFQU2
  pki:
    keys:
      - name: tlskey
        secret:
          items:
            - tls.key
            - tls.crt
          secretName: example-tls-secret
    use: NonProduction
  web:
    enabled: false
  version: 9.2.3.0-r1
  template:
    pod:
      containers:
        - env:
            - name: MQSNOAUT
              value: 'yes'
          name: qmgr
  queueManager:
    resources:
      limits:
        cpu: 1000m
        memory: 2Gi
      requests:
        cpu: 500m
        memory: 1Gi
    name: QM.NHA
    ini:            # qm.iniに指定するスタンザ/パラメーターをConfigMapまたはSecretで渡す
      - configMap:
          items:
            - ssl.ini
          name: outbound-sni
    mqsc:          # 起動時実行するmqscコマンドをConfigMapまたはSecretで渡す
      - configMap:
          items:
            - security.mqsc
          name: disable-security
      - configMap:
          items:
            - config.mqsc
          name: config-mqsc
    availability:
      type: NativeHA    # NativeHAを選択する
      updateStrategy: RollingUpdate
    storage:
      defaultClass: ibmc-vpc-block-5iops-tier
      defaultDeleteClaim: true
      persistedData:
        class: ibmc-vpc-block-5iops-tier
        deleteClaim: true
        enabled: true
        size: 10Gi
      queueManager:
        deleteClaim: true
        size: 10Gi
        type: persistent-claim
      recoveryLogs:
        class: ibmc-vpc-block-5iops-tier
        deleteClaim: true
        enabled: true
        size: 10Gi
        type: persistent-claim
```

GUIの下部のCreateボタンでMQをデプロイする｡

## デプロイ後の確認

MQ OperatorではQueueManagerのCRD(Custom Resource Definition)を定義しているので､ `oc get QueueManager`で確認できる｡
また､`QueueManager`は`StatefulSet`を管理している｡
StatefulSetで生成されたPodを見ると､0~2のsuffixが付いたPodが計3つ作成されていることが分かる｡ 

```bash
takzo% oc get QueueManager   
NAME          PHASE
mq-nativeha   Running
takzo% oc get StatefulSet
NAME                 READY   AGE
mq-nativeha-ibm-mq   1/3     21h
takzo% oc get pods       
NAME                   READY   STATUS    RESTARTS   AGE
mq-nativeha-ibm-mq-0   1/1     Running   0          13m
mq-nativeha-ibm-mq-1   0/1     Running   0          11m
mq-nativeha-ibm-mq-2   0/1     Running   0          12m
takzo% 
```

ちなみに各podにはAntiAffinityが設定されており､他のノードのpodが稼働するworker node上でpodが立ち上がらないようにしている｡

```yaml
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: statefulSetName
                operator: In
                values:
                  - mq-nativeha-ibm-mq
```

そのほか､ノード間通信やOpenShiftクラスター外部との通信のために`Service`や`Route`リソースが作成される｡

```bash
takzo% oc get service | grep mq-nativeha
# MQのチャネル接続を受けるService
mq-nativeha-ibm-mq             ClusterIP   172.21.181.198   <none>        1414/TCP            22h
# MQが吐くprometheus exporter用
mq-nativeha-ibm-mq-metrics     ClusterIP   172.21.235.146   <none>        9157/TCP            22h
# ノード間のデータのレプリケーションで使用するService
# この3つのServiceでは､statefulset.kubernetes.io/pod-nameをPod selectorで指定している
mq-nativeha-ibm-mq-replica-0   ClusterIP   172.21.193.19    <none>        9414/TCP            22h
mq-nativeha-ibm-mq-replica-1   ClusterIP   172.21.52.132    <none>        9414/TCP            22h
mq-nativeha-ibm-mq-replica-2   ClusterIP   172.21.198.212   <none>        9414/TCP            22h

Routeでは通常､Http(s)のエンドポイントを生成する｡ 接続元とMQコンテナのend-to-endでTLS接続するためにpassthrughでRouteリソースが作成される｡
takzo% oc get route | grep mq-nativeha
mq-nativeha-ibm-mq-qm   mq-nativeha-ibm-mq-qm-takzo.isemqgvpc-ocp-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud          mq-nativeha-ibm-mq   1414            passthrough   None
```

### Readiness ProbeとLiveness Probe

Podとしては､3ノード分が作成されるが､READYとなっているのは3つのうち1つだけである｡

生成されるMQのPodでは､キューマネージャー起動時に自動的にチャネル接続のためのリスナーが起動し､1414をListenする｡
Readiness Probeとしてこの1414ポートに対する応答の有無をチェックしている｡ Native HAでは3ノードの内､1時点で稼働するのは1ノードのみのため､スタンバイノードでは1414をListenしていないため､READYとはならない｡
Liveness ProbeはMQのユーティリティコマンドの`dspmq`コマンドの応答をチェックしており､キューマネージャーの稼働を示す`RUNNING`または､Native HAのスタンバイノードで起動していることを示す`REPLICA`のいずれかが返ってくることを確認している｡
(実際には､マルチインスタンスQMGR構成のスタンバイノードである`RUNNING AS STANDBY`や起動中を示す`STARTING`ステータスも正常としている)

このあたりの挙動は､実際にプローブとして実行される`chkmqready`や`chkmqhealty`を見ると良い｡
[ibm-messaging/mq-container/cmd/chkmqready/main.go](https://github.com/ibm-messaging/mq-container/blob/master/cmd/chkmqready/main.go#L43)
[ibm-messaging/mq-container/cmd/chkmqhealty/main.go](https://github.com/ibm-messaging/mq-container/blob/master/cmd/chkmqhealthy/main.go#L44)

### プロセス

アクティブノードとスタンバイノードで稼働しているプロセスを見てみる｡(アクティブノードは`mq-nativeha-ibm-mq-1`に移動した)

- アクティブノード

```bash
sh-4.4$ dspmq 
QMNAME(QM.NHA)                                            STATUS(Running)
sh-4.4$ ps -ef
UID         PID   PPID  C STIME TTY          TIME CMD
1000650+      1      0  0 00:30 ?        00:00:00 runmqserver -nologruntime
1000650+     79      1  0 00:30 ?        00:00:00 /opt/mqm/bin/amqzxma0 -m QM.NHA -x -u 1000650000
1000650+     90     79  0 00:30 ?        00:00:00 /opt/mqm/bin/amqzmgr0 -m QM.NHA
1000650+     93     79  0 00:30 ?        00:00:00 /opt/mqm/bin/amqzmuc0 -m QM.NHA -lr mq-nativeha-ibm-mq-1
1000650+    110     79  0 00:30 ?        00:00:00 /opt/mqm/bin/amqzmur0 -m QM.NHA -lr mq-nativeha-ibm-mq-1
1000650+    123     79  0 00:30 ?        00:00:00 /opt/mqm/bin/amqzmuf0 -m QM.NHA -lr mq-nativeha-ibm-mq-1
1000650+    127     79  0 00:30 ?        00:00:00 /opt/mqm/bin/amqrrmfa -m QM.NHA -t2332800 -s2592000 -p2592000 -g5184000 -c3600
1000650+    134     90  0 00:30 ?        00:00:00 /opt/mqm/bin/amqpcsea QM.NHA
1000650+    135     90  0 00:30 ?        00:00:00 /opt/mqm/bin/runmqchi -m QM.NHA -q SYSTEM.CHANNEL.INITQ -r
1000650+    137     79  0 00:30 ?        00:00:00 /opt/mqm/bin/amqzlaa0 -mQM.NHA -fip0
1000650+    165     90  0 00:30 ?        00:00:00 /opt/mqm/bin/runmqlsr -r -m QM.NHA -t TCP -p 1414
1000650+    179    123  0 00:30 ?        00:00:00 /opt/mqm/bin/amqfqpub -mQM.NHA
1000650+    187    179  0 00:30 ?        00:00:00 /opt/mqm/bin/amqfcxba -m QM.NHA
1000650+    231    165  0 00:31 ?        00:00:00 /opt/mqm/bin/amqrmppa -m QM.NHA
1000650+    670      0  0 00:32 pts/0    00:00:00 sh
1000650+    693    670  0 00:32 pts/0    00:00:00 ps -ef
sh-4.4$
```

- スタンバイノード

```bash
sh-4.4$ dspmq
QMNAME(QM.NHA)                                            STATUS(Replica)
sh-4.4$ ps -ef
UID         PID   PPID  C STIME TTY          TIME CMD
1000650+      1      0  0 00:31 ?        00:00:00 runmqserver -nologruntime
1000650+     65      1  0 00:31 ?        00:00:00 /opt/mqm/bin/amqzxma0 -m QM.NHA -x -u 1000650000
1000650+     76     65  0 00:31 ?        00:00:00 /opt/mqm/bin/amqzmgr0 -m QM.NHA
1000650+     79     65  0 00:31 ?        00:00:00 /opt/mqm/bin/amqzmuc0 -m QM.NHA -lr mq-nativeha-ibm-mq-0
1000650+    111      0  0 00:31 pts/0    00:00:00 sh
1000650+    236      0  0 00:31 pts/1    00:00:00 sh
1000650+    549    236  0 00:32 pts/1    00:00:00 ps -ef
sh-4.4$ 
```

Native HA用途で新たに立ち上がるプロセスはなく､いずれも既存のプロセスが立ち上がる｡子プロセス(スレッド)でレプリケーション処理が行われていると思われる｡

### qm.ini

```ini
sh-4.4$ cat /mnt/mqm-data/qmgrs/QM\!NHA/qm.ini 
#*******************************************************************#
#* WARNING: Automatic configuration has been enabled for this      *#
#* queue manager. Modifications in this file to anything other     *#
#* than valid AutoConfig keys will be lost at the next Queue       *#
#* Manager start.  To disable automatic ini configuration, remove  *#
#* the 'IniConfig' key from the AutoConfig stanza.                 *#
#*******************************************************************#
#
#*******************************************************************#
#* Module Name: qm.ini                                             *#
#* Type       : IBM MQ queue manager configuration file            *#
#  Function   : Define the configuration of a single queue manager *#
#*                                                                 *#
#*******************************************************************#
#* Notes      :                                                    *#
#* 1) This file defines the configuration of the queue manager     *#
#*                                                                 *#
#*******************************************************************#
ExitPath:
   ExitsDefaultPath=/mnt/mqm/data/exits
   ExitsDefaultPath64=/mnt/mqm/data/exits64
#*                                                                 *#
#*                                                                 *#
Log:
   LogPrimaryFiles=3
   LogSecondaryFiles=2
   LogFilePages=4096
   LogType=REPLICATED
   LogBufferPages=0
   LogPath=/mnt/mqm-log/log/QM!NHA/
   LogWriteIntegrity=TripleWrite
   LogManagement=Automatic
SSL:
   AllowTLSV13=Yes
   MinimumRSAKeySize=1
   OutboundSNI=HOSTNAME
Channels:
   ChlauthEarlyAdopt=Yes
   ChlauthIgnoreUserCase=No
TCP:
   SndBuffSize=0
   RcvBuffSize=0
   RcvSndBuffSize=0
   RcvRcvBuffSize=0
   ClntSndBuffSize=0
   ClntRcvBuffSize=0
   SvrSndBuffSize=0
   SvrRcvBuffSize=0
NativeHALocalInstance:
   Name=mq-nativeha-ibm-mq-0
AutoConfig:
   MQSCConfig=/etc/mqm/
   IniConfig=/etc/mqm/
Subpool:
   ShortSubpoolName=QM!NHA0000
NativeHAInstance:
   Name=mq-nativeha-ibm-mq-0
   ReplicationAddress=mq-nativeha-ibm-mq-replica-0(9414)
NativeHAInstance:
   Name=mq-nativeha-ibm-mq-1
   ReplicationAddress=mq-nativeha-ibm-mq-replica-1(9414)
NativeHAInstance:
   Name=mq-nativeha-ibm-mq-2
   ReplicationAddress=mq-nativeha-ibm-mq-replica-2(9414)
```

特筆するべきは､ Logスタンザの`LogType=REPLICATED`と`NativeHALocalInstance`スタンザ､`NativeHAInstance`スタンザである｡
LogTypeは通常はリニアログの`LINEAR`､循環ログの`CIRCULAR`のいずれかだが､Native HAの場合は`REPLICATED`という特殊なログタイプとなる｡
また､`NativeHALocalInstance`スタンザ､`NativeHAInstance`スタンザについては､Native HAを構成するインスタンス情報を示すものであると思われる｡
このあたりは製品マニュアルのqm.iniの頁に記述がなく､他に設定項目があるのか不明だが､[Advanced tuning for Native HA](https://www.ibm.com/docs/en/ibm-mq/9.2?topic=ha-advanced-tuning-native)によると､以下の3つのパラメタがあることを確認できた｡

- HeartbeatInterval
- HeartbeatTimeout
- RetryInterval

## クライアントの自動再接続

MQクライアントでは､キューマネージャーとの接続が切れた際にMQのライブラリで透過的に再接続するオプションがある｡
ノード障害によってキューマネージャーが別ノードにfailoverした際､どの程度で再接続､処理を再開できるかを計測する｡

クライアントアプリケーションとして､メッセージをPUT､そのメッセージID指定でそのままメッセージをGETする処理を繰り返す簡単なクライアントアプリケーション(JMS)を実装､コンテナアプリケーションとしてデプロイしている｡(Pod: `jmsclient-6f558495-55gr5`)

クライアントアプリケーションの稼働中に､アクティブインスタンスのPodを`oc delete pod`で削除する｡

時系列を整理すると以下の通りとなった｡検知から12秒程度で復旧することを確認した｡

| 時間 | 操作及び状況 | 補足 |
| :--- | :----------- | :---- |
| 09:26:45 | oc delete podでアクティブインスタンスを削除 |  | 
| 09:26:48 | クライアントアプリケーションで障害を検知 | 再接続のインターバルを1123, 2415, 4525, 8278, 16996, 25798(msec)として設定 |
| 09:26:48 | 再接続 #0 | 設定したインターバルに依存しない初回の再接続 |
| 09:26:50 | 再接続 #1 スケジュール | 再接続インターバル(1123msec) |
| 09:26:51 | 再接続 #1 | スケジュールから1秒後 |
| 09:26:52 | 再接続 #2 スケジュール | 再接続インターバル(2415msec) |
| 09:26:54 | 再接続 #2 | スケジュールから2秒後 |
| 09:26:55 | 再接続 #3 スケジュール | 再接続インターバル(4525msec) |
| 09:27:00 | 再接続 #3 | スケジュールから約4秒後 |
| 09:27:00 | 再接続完了 | JMSのため､コネクションが1つセッション2つ(PUT用とGET用)の計3つのコネクションが張られる |

なお､再接続のインターバルは[マニュアル](https://www.ibm.com/docs/en/ibm-mq/9.2?topic=reconnection-using-automatic-jms-client)の以下の記述に従って設定される｡

> By default, the reconnection attempts happen at the following intervals:
    - The first attempt is made after an initial delay of 1 second, plus a random element up to 250 milliseconds.
    - The second attempt is made 2 seconds, plus a random interval of up to 500 milliseconds, after the first attempt fails.
    - The third attempt is made 4 seconds, plus a random interval of up to 1 second, after the second attempt fails.
    - The fourth attempt is made 8 seconds, plus a random interval of up to 2 seconds, after the third attempt fails.
    - The fifth attempt is made 16 seconds, plus a random interval of up to 4 seconds, after the fourth attempt fails.
    - The sixth attempt, and all subsequent attempts are made 25 seconds, plus a random interval of up to 6 seconds and 250 milliseconds after the previous attempt fails.

### ログ

- Podステータス

```bash
takzo% date;oc get pods             2021年 12月 8日 水曜日 09時26分27秒 JST
NAME                       READY   STATUS      RESTARTS   AGE
jmsclient-6f558495-55gr5   1/1     Running     1          5m7s
mq-nativeha-ibm-mq-0       0/1     Running     0          4d17h
mq-nativeha-ibm-mq-1       1/1     Running     0          4d17h
mq-nativeha-ibm-mq-2       0/1     Running     1          4d19h
takzo% date;oc delete pod/mq-nativeha-ibm-mq-1
2021年 12月 8日 水曜日 09時26分45秒 JST
pod "mq-nativeha-ibm-mq-1" deleted
takzo% date;oc get pods2021年 12月 8日 水曜日 09時27分45秒 JST
NAME                       READY   STATUS              RESTARTS   AGE
jmsclient-6f558495-55gr5   1/1     Running             1          6m25s
mq-nativeha-ibm-mq-0       1/1     Running             0          4d17h
mq-nativeha-ibm-mq-1       0/1     ContainerCreating   0          19s
mq-nativeha-ibm-mq-2       0/1     Running             1          4d19h
takzo% 
```


- アプリケーションログ

```log
(omit)
-----------------------------------------------------
Sent message:
JMSTimestamp: 1638923204696
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c1981b40
Get the message back
Receiced message:
JMSTimestamp: 1638923204690                   # 2021/12/08 09:26:44
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c1981b40
-----------------------------------------------------
Sent message:
JMSTimestamp: 1638923205706
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c2981b40
Get the message back
Receiced message:
JMSTimestamp: 1638923205700                   # 2021/12/08 09:26:45 ← oc pod delete 実行
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c2981b40
-----------------------------------------------------
Sent message:
JMSTimestamp: 1638923206723
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c3981b40
Get the message back
Receiced message:
JMSTimestamp: 1638923206720
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c3981b40
-----------------------------------------------------
Sent message:
JMSTimestamp: 1638923207741
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c4981b40
Get the message back
Receiced message:
JMSTimestamp: 1638923207740
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c4981b40
-----------------------------------------------------
Sent message:
JMSTimestamp: 1638923208750
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c5981b40
Get the message back
Receiced message:
JMSTimestamp: 1638923208750                   # 2021/12/08 09:26:48
MessgeID: ID:414d5120514d2e4e4841202020202020abc2a961c5981b40
-----------------------------------------------------
# ここで障害を検知
Could not initialize log file, java.nio.file.AccessDeniedException: mqjms.log.0.lck
December 8, 2021 12:26:48 AM GMT[RcvThread: com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection@1164677256[qmid=QM.NHA_2021-10-05_10.35.03,fap=14,channel=SYSTEM.DEF.SVRCONN,ccsid=1208,sharecnv=1,hbint=300,peer=mq-nativeha-ibm-mq/172.21.181.198(1414),localport=38831,ssl=no]] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Reconnection times (milliseconds) : '[1123, 2415, 4525, 8278, 16996, 25798]'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:26:48 AM GMT[RcvThread: com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection@1164677256[qmid=QM.NHA_2021-10-05_10.35.03,fap=14,channel=SYSTEM.DEF.SVRCONN,ccsid=1208,sharecnv=1,hbint=300,peer=mq-nativeha-ibm-mq/172.21.181.198(1414),localport=38831,ssl=no]] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Queueing reconnection of parent hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/107ec9e5][connectionId=414D5143514D2E4E4841202020202020ABC2A9611F9D1B40]' to queue manager 'null'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:26:48 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Starting reconnection of parent hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/107ec9e5][connectionId=414D5143514D2E4E4841202020202020ABC2A9611F9D1B40]' to queue manager 'null'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:26:50 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Rescheduling reconnection of parent hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/107ec9e5][connectionId=414D5143514D2E4E4841202020202020ABC2A9611F9D1B40]'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:26:51 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Starting reconnection of parent hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/107ec9e5][connectionId=414D5143514D2E4E4841202020202020ABC2A9611F9D1B40]' to queue manager 'null'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:26:52 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Rescheduling reconnection of parent hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/107ec9e5][connectionId=414D5143514D2E4E4841202020202020ABC2A9611F9D1B40]'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:26:54 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Starting reconnection of parent hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/107ec9e5][connectionId=414D5143514D2E4E4841202020202020ABC2A9611F9D1B40]' to queue manager 'null'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:26:55 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Rescheduling reconnection of parent hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/107ec9e5][connectionId=414D5143514D2E4E4841202020202020ABC2A9611F9D1B40]'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:27:00 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Starting reconnection of parent hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/107ec9e5][connectionId=414D5143514D2E4E4841202020202020ABC2A9611F9D1B40]' to queue manager 'null'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:27:00 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.api.RemoteParentHconn
Starting reconnection of child hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/d10ff268][connectionId=414D5143514D2E4E4841202020202020ABC2A9618B981B40]'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:27:00 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.api.RemoteParentHconn
Completed reconnection of child hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/d10ff268][connectionId=414D5143514D2E4E4841202020202020ABC2A9618B981B40]'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:27:00 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.api.RemoteParentHconn
Starting reconnection of child hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/b8be865f][connectionId=414D5143514D2E4E4841202020202020ABC2A96107961B40]'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:27:00 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.api.RemoteParentHconn
Completed reconnection of child hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/b8be865f][connectionId=414D5143514D2E4E4841202020202020ABC2A96107961B40]'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
December 8, 2021 12:27:00 AM GMT[JMSCCThreadPoolWorker-4] com.ibm.mq.jmqi.remote.impl.RemoteReconnectThread
Completed reconnection of parent hconn 'com.ibm.mq.jmqi.remote.impl.RemoteSession[:/107ec9e5][connectionId=414D5143514D2E4E4841202020202020ABC2A9611F9D1B40]'

EXPLANATION:
null

ACTION:
null
--------------------------------------------------------------------
Sent message:
JMSTimestamp: 1638923209766
MessgeID: ID:414d5120514d2e4e4841202020202020c9fbaf61022a0040
Get the message back
Receiced message:
JMSTimestamp: 1638923220510        # 2021/12/08 09:27:00
MessgeID: ID:414d5120514d2e4e4841202020202020c9fbaf61022a0040
-----------------------------------------------------
Sent message:
JMSTimestamp: 1638923221523
MessgeID: ID:414d5120514d2e4e4841202020202020c9fbaf61032a0040
Get the message back
Receiced message:
JMSTimestamp: 1638923221520
MessgeID: ID:414d5120514d2e4e4841202020202020c9fbaf61032a0040
-----------------------------------------------------
(omit)
```

---

本エントリでは､Native HAを構成し､簡単な調査及び検証を行った｡
レプリケーションの詳細については内部実装となっており､マニュアルにも記載がないため､所謂Split brainの状態が発生した際のリカバリ方法や､実運用の観点で見ていく必要がある部分は多いため､今後も継続して調査していきたい｡