Native HAでAWS EC2環境に高可用なキューマネージャーを構成する

概要

Native HAの概要

Native HAはAWSなどのクラウド環境において高可用なMQを構成する最適な機能です。

3rdパーティー製のクラスタウェアや外部ディスク/データ・レプリケーション・ツールに頼ることなくMQが持つNativeな機能としてフェールオーバー構成を実現できます。さらに従来のフェールオーバーの方式に比べて格段に早いフェールオーバーを実現し、多くの状況では障害を検知して数秒でフェールオーバーが完了するためダウンタイムを小さくすることができます。

Native HAの構成の主な特徴は以下のとおりです

• Native HA は 3ノード構成（active 1 + replica 2）で、Quorum（２ノード以上)を満たすノードからactiveなノードを選出することでSplit Brainを防ぎます。
• Native HA はactive のログ更新を ネットワークでreplica2台へ複製する仕組みなため、 共有ストレージは不要で、各ノードは ローカルのストレージ（xfs/ext4等）を持つだけで構成できます。
• ログ更新の複製は同期的に行われるため、フェールオーバーを跨いでも一貫性が失われることはなく、データの欠損や重複などの不整合が発生しません
• Native HA の同期的なログの複製は低遅延が前提となっているためリージョンを跨ぐフェールオーバーには向きません。

Native HAは３つのサーバーのうち1台の障害には耐えられますが、2台に障害が発生してしまうと動作しません。

そのため、データセンター障害を想定した複数AZ構成を撮る場合、必ず３つのAZに分散して3台のサーバーを構成することが必要です。

3台中2台のサーバーが同一のAZ（データセンター）に配置されていると該当のAZに障害が発生した場合に停止を招くことになってしまうためです。

Native HAを利用する場合、MQ Advanced （またはNative HA用のAdd-onライセンス）が必要です。

Native HAが非コンテナ環境でも利用できるように

元々Native HAの機能はKubernetesの環境を想定した構成として開発されましたが、MQ V9.4.4から非コンテナ環境のLinuxでも利用できるようになりました。

AWSやAzure, IBM CloudなどのPublic CloudのIaaS環境で手軽に高可用なMQの構成を実現することができます。

非コンテナ環境・コンテナ管理基盤の外でNative HAを稼働させる場合、以下の考慮点があります。

• Kubernetes の liveness probe がないので、Linux 構成では systemd 等で監視/再起動が必要です。
  • systemdで監視・起動を行うためのサンプルが提供されています
  • systemdで停止する場合にはendmqmで停止するとsystemdによって再起動されてしまうためsystemctl stopでの停止が必要です
• ロードバランサーがないため、キューマネージャーのエンドポイントは複数になります。MQクライアントや送信チャネルなど接続元側で接続名(CONNAME)に複数のエンドポイントを定義する必要があります。もしくはAWS環境ではELB(Elastic Load Balancing)などをフロントに配置して単一のエンドポイントとして利用し、MQ通信をActiveなキューマネージャーに振り分けを行うなどの方法も可能です。

この記事で説明すること

このブログでは非コンテナ環境（EC2上のLinux）でのNative HAによる高可用なキューマネージャーをAWSのMAZ環境に構成する手順を説明します。

大まかな流れは以下の通りです。

• IBM MQ V9.4.4を3つの仮想マシンにインストール
• それぞれの環境で同一名称のキューマネージャーをを作成（1つのNative HAキューマネージャ）
• レプリケーションの設定
  • qm.ini に NativeHALocalInstance / NativeHAInstance を設定し、レプリケーション(9414) を有効化
• 設定確認
  • dspmq -o nativeha -x で状態確認
• フェールオーバーの監視と自動起動の設定
  • 監視用のサンプルmqmonitor.py とsystemd で監視・自動再起動
• フェールオーバー動作確認
  • サンプル・プログラムを利用した put/get

手順は簡易的な構成となっているためセキュリティや性能などで厳しい非機能要件がある場合には注意深く設計を見直す必要がある点についてはご留意ください。

AWS環境の前提

今回利用したAWS環境を記載します。

リージョン

• ap-northeast-1 (東京)のリージョンを利用します。

ネットワーク構成

• 以下のようにVPCを作成・構成
  • VPC CIDR: 10.0.0.0/16
  • サブネットを3つ作成し、それぞれを別々のAZに配置
    • 10.0.1.0/24（ ap-northeast-1a）
    • 10.0.2.0/24（ ap-northeast-1c）
    • 10.0.3.0/24（ ap-northeast-1d）
  • インターネットゲートウェイ(IGW) を作成 し、VPCにアタッチ
    • ルートテーブルに 0.0.0.0/0 → IGW を追加し、3サブネットに関連付け
  • 各サブネットの「自動割り当てパブリックIPv4」を 有効化

セキュリティ・グループ

• セキュリティ・グループ名　：　sg-mq-nativeha

• インバウンド :

  • SSH 22/tcp 　接続IPアドレス制限を適用（自身のPCのIPなど）
  • MQ 接続 1414/tcp：性能検証クライアントのIPのみ(自身のPCのIPなど)
  • Native HA 複製 9414/tcp：Native HAを構成する 3台間のみに限定

• アウトバウンド:

  • デフォルト

EC2インスタンス

同一リージョン内で AZ を 3つ選び、EC2 を 1台ずつ配置します（例：ap-northeast-1a/1c/1d）。

• 名前：mq-nha-alpha / mq-nha-beta / mq-nha-gamma

  • EC2は同一インスタンスタイプに揃えます。

  • EBS：各ノードに gp3（ログ/データを分けたいならボリューム分割）

• AMI：Red Hat Enterprise Linux 9.7

• アーキテクチャ：x86_64

• インスタンスタイプ：t3.micro

• キーペア：新規作成（mq-nativeha-key など）

• ネットワーク:

  • VPC: 作成済みのVPC
  • サブネット：alpha/beta/gamma で 別サブネット（別AZ）を設定
  • パブリックIP：有効
  • セキュリティグループ：sg-mq-nativeha
  • プライベートIP：今回は 10.0.1.10, 10.0.2.10,10.0.3.10を設定

• ストレージ：

  • ルート：gp3 20GiB（最低限なら 20）
    • MQデータ/ログ用に分ける場合は追加でEBSを構成

IBM MQ V9.4.4のインストール

３つのサーバー上にIBM MQをインストールするために、以下の作業をそれぞれのサーバー上で実施します。

作業はrootユーザーで行います

1. MQのインストール

実行するコマンドのみ記載し、出力結果は省略しています。

# 製品イメージの配置場所に移動
cd /tmp/

# 製品イメージを解凍
tar -xzf 9.4.4.0-IBM-MQ-LinuxX64_.tar.gz

# 解凍された製品イメージのディレクトリに移動
cd MQServer

# ライセンスの受諾
./mqlicense.sh -accept

# 製品のインストール
rpm -ivh MQSeriesRuntime-*.rpm
rpm -ivh MQSeriesSDK-*.rpm
rpm -ivh MQSeriesGSKit-*.rpm
rpm -ivh MQSeriesServer-*.rpm
rpm -ivh MQSeriesSamples-*.rpm
rpm -ivh MQSeriesMan-*.rpm
rpm -ivh MQSeriesMsg_ja-*.rpm
rpm -ivh MQSeriesClient-*.rpm
rpm -ivh MQSeriesJRE-*.rpm
rpm -ivh MQSeriesJava-*.rpm
rpm -ivh MQSeriesWeb-*.rpm
rpm -ivh MQSeriesAMQP-*.rpm
rpm -ivh MQSeriesXRService-*.rpm
rpm -ivh MQSeriesFTBase-*.rpm
rpm -ivh MQSeriesFTTools-*.rpm
rpm -ivh MQSeriesFTAgent-*.rpm
rpm -ivh MQSeriesFTService-*.rpm
rpm -ivh MQSeriesAMS-*.rpm 
rpm -ivh MQSeriesFTLogger-*.rpm 

# MQのプライマリのInstallationに設定
/opt/mqm/bin/setmqinst -i -n Installation1

2. インストールの確認

インストールが行われるとMQの管理ユーザーであるmqmユーザーが作成されています。

管理ユーザーにスイッチしてIBM MQが導入されていることを確認します。

$ su - mqm
$ dspmqver
Name:        IBM MQ
Version:     9.4.4.0
Level:       p944-L251003
BuildType:   IKAP - (Production)
Platform:    IBM MQ for Linux (x86-64 platform)
Mode:        64-bit
O/S:         Linux 5.14.0-611.5.1.el9_7.x86_64
O/S Details: Red Hat Enterprise Linux 9.7 (Plow)
InstName:    Installation1
InstDesc:    
Primary:     Yes
InstPath:    /opt/mqm
DataPath:    /var/mqm
MaxCmdLevel: 944
LicenseType: Production
ReleaseType: Continuous Delivery (CD)

/etc/hostsの設定

キューマネージャーを稼働させるLinuxサーバー間がログの同期を行うためのネットワークについて、設定を簡易化するために今回は3つのサーバーの/etc/hostsに各ノードのプライベートIPを以下のように登録して名前解決を行えるようにしておきます。

/etc/hosts

10.0.1.10 alpha
10.0.2.10 beta
10.0.3.10 gamma

Native HA 用のキューマネージャーを作成

3台のLinuxサーバー上それぞれで 同じ名前でキューマネージャーを作成します。

alphaでmqmユーザーにスイッチして以下のコマンドを実行します。

$ crtmqm -lr alpha -lf 8192 -lp 10 -ls 10 -p 1414 MYQMGR
IBM MQ queue manager 'MYQMGR' created.
Directory '/var/mqm/qmgrs/MYQMGR' created.
The queue manager is associated with installation 'Installation1'.
Creating or replacing default objects for queue manager 'MYQMGR'.
Default objects statistics : 85 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.

• -lr は「log replication」のオプションで, HAグループ内のインスタンス名を指定します。Native HAグループに参加するキューマネージャー作成時に指定が必要です。
  • 今回はインスタンス名をホスト名と同じにしています。
  • ユニークな文字列である必要があり、利用可能な文字は英数字と"-"(ダッシュ記号),"_"(アンダーバー）,"."（ピリオド）です。
  • "-"(ダッシュ)で開始する文字列や" "(スペース)の使用は許可されていません。
• -lfは「Log file pages」オプションで、ログ・ファイルの大きさを4KBのページ数によって指定します。デフォルトは4,096(16MB)です。
• -lp, -lsはプライマリ・ログ（１次ログ）、セカンダリ・ログ（2次ログ）の数を指定しています。
• -p 1414 はキューマネージャー制御でのリスナーを作成するオプションです。この設定をしておくことでキューマネージャーがActiveになった際、 1414 番ポートでリスナーが自動起動されます。

betaでもmqmユーザーで以下のコマンドを実行します。

$ crtmqm -lr beta  -lf 8192 -lp 10 -ls 10 -p 1414 MYQMGR

同様にgammaでは以下のコマンドを実行します。

$ crtmqm -lr gamma -lf 8192 -lp 10 -ls 10 -p 1414 MYQMGR

Native HAグループ内のデータ通信を TLS で保護するための設定

Native HAグループ内のデータ通信をTLSで暗号化することができます。

今回は単一の証明書でインスタンス間の通信の保護を行います。

alpha上で以下のコマンドをmqmユーザーで実行します。

# キー・リポジトリの作成
$ runmqakm -keydb -create -db /var/mqm/qmgrs/MYQMGR/ssl/keystore.kdb -pw PASSWORD -stash

# 証明書の作成
$ runmqakm -cert -create  -db /var/mqm/qmgrs/MYQMGR/ssl/keystore.kdb -pw PASSWORD \
  -label nha-qm-replication -dn CN=MYQMGR-REPLICATION -size 2048

-pwでキー・リポジトリへのアクセスのためのパスワードを設定します。今回パスワードはPASSWORDとしています。

以上の操作で/var/mqm/qmgrs/MYQMGR/sslの下に以下の４つのファイルが作成されます。

• keystore.kdb : キー・データベース（CMS Key Database）でここに秘密鍵・公開鍵・証明書（自己署名/CA署名）されます。
• keystore.sth : kdb を開くためのパスワードを（暗号化/難読化して）保存するスタッシュ・ファイルです。
• keystore.crl : Certificate Revocation List：証明書失効リストを格納するファイルです。
• keystore.rdb : GSKit が 証明書要求（CSR）など、キーDBに紐づく要求情報を保持するために使います。

今回は作成された上記４つのファイル(/var/mqm/qmgrs/MYQMGR/ssl/keystore.*) を beta および gamma にコピーし、以下のように適切な権限を付与します。

$ chown :mqm /var/mqm/qmgrs/MYQMGR/ssl/keystore.*
$ chmod g+r /var/mqm/qmgrs/MYQMGR/ssl/keystore.*

今回のAWS環境の設定ではLinuxサーバー間のscpを許可していないため、作業PC経由でのscpによるファイルの受け渡しが必要です

Native HA のためのqm.iniの編集

Native HAグループを構成するためには qm.ini に以下2つのスタンザを設定します。

1. NativeHALocalInstance
   • 自身のインスタンス名を指定します。
   • また、ログ同期の暗号化や圧縮、ハートビート間隔や同期通信失敗時のリトライなどNative HAに関する様々な設定を行えます。
   • 今回の例では前の手順で構成したTLSによる暗号化のために構成したキー・リポジトリの情報を設定しています。
2. NativeHAInstance
   • Native HAグループ内のメンバー(インスタンス）同士が通信を行うために必要なネットワーク・エンドポイントの設定を行います。

alpha, beta, gamma 各ノードの /var/mqm/qmgrs/MYQMGR/qm.ini に以下を追記します。

NativeHALocalInstance:のNameの値はサーバーによって変更してください(以下はalphaの例です。別サーバーではbeta/gammaを指定)。それ以外の項目は同一です。

NativeHALocalInstance:
  Name=alpha
  CipherSpec=ANY_TLS12
  CertificateLabel=nha-qm-replication
  KeyRepository=/var/mqm/qmgrs/MYQMGR/ssl/keystore

NativeHAInstance:
  Name=alpha
  ReplicationAddress=alpha(9414)
NativeHAInstance:
  Name=beta
  ReplicationAddress=beta(9414)
NativeHAInstance:
  Name=gamma
  ReplicationAddress=gamma(9414)

以上でNative HAに必要な基本的な設定は完了です。

キューマネージャーの起動

3台それぞれで通常通りMQキューマネージャーを起動します。

$ strmqm MYQMGR

どのインスタンスがアクティブなのかを以下のコマンドで確認できます。

$ dspmq -o nativeha -x
QMNAME(MYQMGR)                                            ROLE(Active) INSTANCE(alpha) INSYNC(yes) QUORUM(3/3) GRPLSN(<0:0:18:55929>) GRPNAME() GRPROLE(Live)
 INSTANCE(alpha) ROLE(Active) REPLADDR(alpha) CONNACTV(yes) INSYNC(yes) BACKLOG(0) CONNINST(yes) ACKLSN(<0:0:18:55929>) HASTATUS(Normal) SYNCTIME(2025-12-14T15:06:07.961266Z) ALTDATE(2025-12-14) ALTTIME(15.06.07)
 INSTANCE(beta) ROLE(Replica) REPLADDR(beta) CONNACTV(yes) INSYNC(yes) BACKLOG(0) CONNINST(yes) ACKLSN(<0:0:18:55929>) HASTATUS(Normal) SYNCTIME(2025-12-14T15:06:06.993488Z) ALTDATE(2025-12-14) ALTTIME(15.06.07)
 INSTANCE(gamma) ROLE(Replica) REPLADDR(gamma) CONNACTV(yes) INSYNC(yes) BACKLOG(0) CONNINST(yes) ACKLSN(<0:0:18:55929>) HASTATUS(Normal) SYNCTIME(2025-12-14T15:06:06.993488Z) ALTDATE(2025-12-14) ALTTIME(15.06.07)

• キューマネージャーの状態のほか、Native HAの各インスタンスの状態が確認できます。
• 上の例では３つのインスタンスの内alphaが ROLE(Active)の状態になっており、betaとgammaがROLE(Replica)になっていることがわかります。

監視と自動再起動の設定

Kubernetesの制御下にないNative HA 構成ではMQの稼働状況を 監視して自動的に再起動する仕組みが必要です。

監視のための仕組みとしてmqmonitor.py と systemd のサンプルが提供されていますのでこれを利用します。

alpha, beta, gamma各ノード上で、以下のコマンドをrootユーザーで実行することでキューマネージャーをsystemdの制御下で稼働させます。

# 監視サービス用のテンプレート・ユニット・ファイルをsystemdに配置
$ sudo ln -s /opt/mqm/samp/mqmonitor@.service /etc/systemd/system

# systemdのテンプレート・ユニットにサービス・インスタンスとしてMYQMGRを登録
$ sudo systemctl enable mqmonitor@MYQMGR
Created symlink /etc/systemd/system/[e-mail] → /opt/mqm/samp/mqmonitor@.service.
Created symlink /etc/systemd/system/multi-user.target.wants/[e-mail] → /opt/mqm/samp/mqmonitor@.service.

# サービスの開始
$ sudo systemctl start  mqmonitor@MYQMGR

これでキューマネージャーはsystemdの監視下に入ります。

/opt/mqm/samp/mqmonitor@.serviceでは（mqmonitor.py）を mqm ユーザー権限で実行・常駐させています。

その際、引数として死活監視をの間隔が指定されており、10秒という間隔が指定されています。

mqmonitor.pyの内容を確認すると、死活監視はdspmqコマンドによって行われていることが確認できます。

監視プロセス自体もsystemdの監視下に置かれており、異常停止した場合には自動再起動されるようになっています。

mqmonitor@.serviceのログ（標準出力/標準エラー）は journald に集約されているため journalctl -u mqmonitor@MYQMGR で参照できます。

キューマネージャーをsystemdの監視下に置いて以降は、停止/起動は systemctl stop/start を利用する必要があります。

endmqm コマンドで停止するとsystemdが自動的にキューマネージャーを起動してしまいます。

動作確認

Linux環境で閉じた簡単な動作確認を行います。Native HA構成のキューマネージャー上にキューを作成してメッセージを書き込み、フェールオーバーを実施してフェールオーバー先で投入されたメッセージが受信できることを確認します。

キューの作成

現在キューマネージャーがアクティブになっているalpha上, mqmユーザーで以下を実行します。

$ runmqsc MYQMGR << EOF
DEFINE QLOCAL(QUEUE1) DEFPSIST(YES)
EOF

キューマネージャーMYQMGRにQUEUE1という名前のローカル・キューをデフォルトの持続性(DEFPSIST)をYESにして作成しています。デフォルトの持続性を設定することでアプリケーションで指定がない場合、メッセージはパーシステントとなり、キューマネージャーの再起動を跨いで保護されます。

メッセージのPUT

製品付属のサンプル・プログラムを利用してキューにメッセージを書き込みます。

alpha上, mqmユーザーで以下を実行します。

$ echo "This is a sample message" | /opt/mqm/samp/bin/amqsput QUEUE1 MYQMGR
Sample AMQSPUT0 start
target queue is QUEUE1
Sample AMQSPUT0 end

これでキューマネージャーMYQMGR上のキューQUEUE1にThis is a sample messageという内容のメッセージが投入されました。

フェールオーバーの実行

Activeになっているalphaのキューマネージャーを停止してフェールオーバーを発生させます。

alpha上、rootユーザーで以下を実行します。

$ sudo systemctl stop  mqmonitor@MYQMGR

次にbeta、もしくはgamma上でnativehaの状況を確認してみます。

以下のコマンドをmqmユーザーで実行します。

$ dspmq -o nativeha -x
QMNAME(MYQMGR)                                            ROLE(Replica) INSTANCE(beta) INSYNC(yes) QUORUM(2/3) GRPLSN(<0:0:28:16222>) GRPNAME() GRPROLE(Live)
 INSTANCE(beta) ROLE(Replica) REPLADDR(beta) CONNACTV(yes) INSYNC(yes) BACKLOG(0) CONNINST(yes) ACKLSN(<0:0:28:16222>) HASTATUS(Normal) SYNCTIME(2025-12-14T15:18:26.072134Z) ALTDATE(2025-12-14) ALTTIME(15.18.27)
 INSTANCE(alpha) ROLE(Replica) REPLADDR(alpha) CONNACTV(no) INSYNC(no) BACKLOG(1180) CONNINST(no) ACKLSN() HASTATUS(Disconnected) SYNCTIME() ALTDATE(2025-12-14) ALTTIME(15.18.27)
 INSTANCE(gamma) ROLE(Active) REPLADDR(gamma) CONNACTV(yes) INSYNC(yes) BACKLOG(0) CONNINST(yes) ACKLSN(<0:0:28:16222>) HASTATUS(Normal) SYNCTIME(2025-12-14T15:18:27.081612Z) ALTDATE(2025-12-14) ALTTIME(15.18.27)

フェールオーバーが自動的に行われ、キューマネージャーがgammaでActiveになっていることがわかります。

メッセージの受信

フェールオーバー先のmqmユーザーで以下を実行してメッセージを受信してみます。

$ /opt/mqm/samp/bin/amqsget QUEUE1 MYQMGR
Sample AMQSGET0 start
message <This is a sample message>

alpha上でQUEUE1に送信したメッセージが引き継がれていることがわかります。

テスト完了後、alphaで以下のコマンドをrootユーザーで実行し、mqmonitorのインスタンスを起動しておきます。

$ sudo systemctl start mqmonitor@MYQMGR

以上でAWS上でNative HAの機能を利用したAvailability Zoneを跨ぐ高可用なMQ構成ができました。

最後に

Native HAはAWSなどのクラウド環境で複数AZ環境での高可用なキューマネージャーを運用するための最適なソリューションです。

今までコンテナ環境でのみ利用可能でしたが、V9.4.4のCDリリース(Continuous Delivery)から非コンテナ環境での利用できるようになったことでコンテナでの運用に慣れていない方でも手軽に利用できるようになりました。

この機能が利用可能なV9.4.4はCDリリースであることからサポート期間がリリースから基本的には12ヶ月間(または最新2つのCDの範囲のどちらか長い方)と短いため、継続的なサポートを受けるためには少なくとも1年に１回はリリース・アップが必要となる点はご留意ください。