[OpenShift Container Platform][MQ 9.2.3 Jul 2021][Continuous Delivery][IBM Cloud Pak for Integration][Linux]

例: ネイティブ HA キュー・マネージャーの構成

この例では、ネイティブの高可用性機能を使用したキュー・マネージャを、 IBM® MQ Operator を使用して Red Hat® OpenShift® Container Platform (OCP) に配置する方法を示します。

始める前に

この例を完了するには、まず以下の前提条件を満たしておく必要があります。

  • IBM MQ clientをインストールし、インストール済みの samp/bin ディレクトリーおよび bin ディレクトリーを パスに追加します。 この例で必要な runmqakmamqsputcamqsgetc の各アプリケーションはクライアントで提供されています。 IBM MQ client を以下のように取り付ける:
  • お使いのオペレーティングシステム用の OpenSSL ツールをインストールしてください。 この作業は、まだ秘密鍵と証明書がない場合に、キュー・マネージャー用の自己署名証明書を生成するために必要です。
  • 作成する Red Hat OpenShift Container Platform この例では、(OCP)プロジェクト/名前空間を選択し、 IBM MQ 用の Red Hat OpenShift プロジェクトの準備のタスクの手順に従ってください。
  • コマンド・ラインで OCP クラスターにログインし、今作成した名前空間に切り替えます。
  • IBM MQ Operator がインストールされ、ネームスペースで利用可能であることを確認する。
  • キュー・マネージャーで使用されるデフォルトのストレージ・クラスを OCP で構成します。 デフォルトのストレージ・クラスを設定せずにこのチュートリアルを完了したい場合は、 「注2:デフォルト以外のストレージ・クラスを使用する 」を参照してください。

本タスクについて

ネイティブHAキューマネージャは、アクティブと2つのレプリカ Kubernetes Podsを含む。 これらは、ちょうど3つのレプリカと Kubernetes Persistent Volumesのセットを持つ Kubernetes Stateful Setの一部として実行される。 ネイティブHAキュー・マネージャの詳細については、 High availability for IBM MQ in containersを参照のこと。

この例では、永続ストレージを使用し、TLS で構成されている、ネイティブ HA キュー・マネージャーを定義するカスタム・リソース YAML を示します。 キュー・マネージャーを OCP にデプロイした後、アクティブ・キュー・マネージャー・ポッドの障害をシミュレートします。 自動復旧が行われた後、メッセージの書き込みと読み取りを行うことによって、障害発生後の復旧に成功したことが証明されます。

MQ サーバーの TLS 秘密鍵と証明書の作成
キュー・マネージャーの自己署名証明書を作成し、クライアントのトラストストアとして機能する鍵データベースに証明書を追加することができます。 秘密鍵と証明書がすでに存在する場合は、代わりにそれらを使用できます。 開発目的の場合、自己署名証明書のみを使用する必要があることに注意してください。
現行ディレクトリーへの自己署名の秘密鍵と公開証明書を作成するには、次のコマンドを実行します。
openssl req -newkey rsa:2048 -nodes -keyout tls.key -subj "/CN=localhost" -x509 -days 3650 -out tls.crt
ネイティブ HA で内部使用される TLS 秘密鍵と証明書の作成
ネイティブ HA キュー・マネージャー内の 3 つのポッドは、ネットワークを介してデータを複製します。 内部的に複製する際に使用するための自己署名証明書を作成できます。 開発目的の場合、自己署名証明書のみを使用する必要があることに注意してください。
現行ディレクトリーへの自己署名の秘密鍵と公開証明書を作成するには、次のコマンドを実行します。
openssl req -newkey rsa:2048 -nodes -keyout nativeha.key -subj "/CN=localhost" -x509 -days 3650 -out nativeha.crt
クライアントの鍵データベースへのキュー・マネージャーの公開鍵の追加
クライアント・アプリケーションのトラストストアとしてクライアントの鍵データベースを使用します。
クライアントの鍵データベースを作成します。
runmqakm -keydb -create -db clientkey.kdb -pw password -type cms -stash
前に生成した公開鍵をクライアントの鍵データベースに追加します。
runmqakm -cert -add -db clientkey.kdb -label mqservercert -file tls.crt -format ascii -stashed
キュー・マネージャー・デプロイメントのための TLS 証明書を格納するシークレットの作成
キュー・マネージャが鍵と証明書を参照して適用できるように、 Kubernetes TLS シークレットを作成し、上記で作成したファイルを参照する。 まず、このタスクの開始前に作成した名前空間で作業していることを確認してください。
oc create secret tls example-ha-secret --key="tls.key" --cert="tls.crt"
内部で使用するネイティブ HA TLS 証明書と鍵を格納するシークレットの作成
キュー・マネージャが鍵と証明書を参照して適用できるように、 Kubernetes TLS シークレットを作成し、上記で作成したファイルを参照する。 まず、このタスクの開始前に作成した名前空間で作業していることを確認してください。
oc create secret tls example-ha-secret-internal --key="nativeha.key" --cert="nativeha.crt"
MQSC コマンドを組み込んだ構成マップの作成
新しいキューと SVRCONN チャネルを作成し、 nobody と呼ばれるユーザのみをブロックすることによりチャネルへのアクセスを許可するチャネル認証レコードを追加するための MQSC コマンドを含む Kubernetes config マップを作成する。

この方法を使用するのは、開発のためだけに限定してください。

先に作成したネームスペースにいることを確認してから(「 始める前に 」を参照)、OCP UIで、あるいはコマンドラインを使って、以下のYAMLを入力してください:
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-mi-configmap
data:
  tls.mqsc: |
    DEFINE QLOCAL('EXAMPLE.QUEUE') DEFPSIST(YES) REPLACE 
    DEFINE CHANNEL(HAQMCHL) CHLTYPE(SVRCONN) TRPTYPE(TCP) SSLCAUTH(OPTIONAL) SSLCIPH('ANY_TLS12_OR_HIGHER')
    SET CHLAUTH(HAQMCHL) TYPE(BLOCKUSER) USERLIST('nobody') ACTION(ADD)
ルーティングの構成
IBM MQ 9.2.1 以降の IBM MQ client やツールキットを使用している場合、キューマネージャ設定ファイル(INI ファイル)を使用することで、キューマネージャへのルーティングを設定することができます。 このファイル内で、チャネル名ではなくホスト名に基づいてルーティングするように OutboundSNI 変数を設定します。
コマンドを実行するディレクトリーに、 mqclient.iniという名前のファイルを作成します。これには、以下のテキストが正確に含まれます。
SSL:
   OutboundSNI=HOSTNAME
この INI ファイル内の値を変更しないでください。 例えば、ストリング HOSTNAME は変更してはなりません。
詳細については、 クライアント設定ファイルのSSLスタンザを参照のこと。
IBM MQ 9.2.1 より前の IBM MQ client またはツールキットを使用している場合は、以前の構成ファイルの代わりに OCP ルートを作成する必要があります。 注1:ルートの作成 」の手順に従ってください。
キュー・マネージャーのデプロイ
重要: この例では、MQSNOAUT 変数を使用してキュー・マネージャーでの許可を無効にします。これにより、TLS を使用してクライアントを接続するために必要なステップに集中できるようになります。 これは、 IBM MQ の本番環境では推奨されません。なぜなら、接続するすべてのアプリケーショ ンが完全な管理権限を持つことになり、個々のアプリケーションの権限を下げる仕組みがないからです。

以下の YAML をコピーして更新します。
  • 正しいライセンスが指定されていることを確認します。 mq.ibm.com/v1beta1 についてはライセンス・リファレンスを参照。 IBM Cloud Pak® for Integration 2021.1.1 では、ライセンスは評価ライセンス L-RJON-BYRMYW でなければなりません
  • falsetrue に変更して、ライセンスに同意します。
キュー・マネージャーのカスタム・リソース YAML は、以下のようになります。
apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: nativeha-example
spec:
  license:
    accept: false
    license: L-RJON-C7QG3S
    use: Production
  queueManager:
    name: HAEXAMPLE
    availability:
      type: NativeHA
      tls:
        secretName: example-ha-secret-internal
    mqsc:
    - configMap:
        name: example-mi-configmap
        items:
        - tls.mqsc
  template:
    pod:
      containers:
        - env:
            - name: MQSNOAUT
              value: 'yes'
          name: qmgr
  version: 9.2.5.0-r3
  pki:
    keys:
      - name: example
        secret:
          secretName: example-ha-secret
          items: 
          - tls.key
          - tls.crt

先ほど作成したネームスペースにいることを確認し、 Red Hat OpenShift Container Platform ウェブコンソール、コマンドライン、または IBM Cloud Pak for Integration Platform Navigator を使って、更新した YAML をデプロイする。

システムがネイティブ HA キュー・マネージャーを構成している間、少しの遅延があります。その後、キュー・マネージャーを使用できるようになるはずです。

検証

このセクションでは、キュー・マネージャーが想定どおりに動作することを検証します。

キュー・マネージャーが稼働していることの確認
キュー・マネージャーがデプロイされます。 続行する前に、Running 状態であることを確認してください。 以下に例を示します。
oc get qmgr nativeha-example
キュー・マネージャーへの接続のテスト
キュー・マネージャーで単方向の TLS 通信が構成されていることを確認するために、サンプル・アプリケーション amqsputcamqsgetc を使用します。
キュー・マネージャーのホスト名の検索
ルート nativeha-example-ibm-mq-qm のキュー・マネージャー・ホスト名を見つけるには、以下のコマンドを実行します。 ホスト名は HOST フィールドに返されます。
oc get routes nativeha-example-ibm-mq-qm
キュー・マネージャーの詳細情報の指定
キュー・マネージャーの詳細を指定するファイル CCDT.JSON を作成します。 ホストの値は、直前のステップで返されたホスト名に置き換えてください。
{
    "channel":
    [
        {
            "name": "HAQMCHL",
            "clientConnection":
            {
                "connection":
                [
                    {
                        "host": "<host from previous step>",
                        "port": 443
                    }
                ],
                "queueManager": "HAEXAMPLE"
            },
            "transmissionSecurity":
            {
              "cipherSpecification": "ECDHE_RSA_AES_128_CBC_SHA256"
            },
            "type": "clientConnection"
        }
   ]
}
環境変数のエクスポート
オペレーティング・システムに適した方法で以下の環境変数をエクスポートします。 これらの変数は amqsputcamqsgetc によって読み取られます。
システム上のファイルへのパスを更新します。
export MQCCDTURL='<full_path_to_file>/CCDT.JSON'
export MQSSLKEYR='<full_path_to_file>/clientkey'
キューへのメッセージの書き込み
以下のコマンドを実行します。
amqsputc EXAMPLE.QUEUE HAEXAMPLE
キュー・マネージャーへの接続が成功すると、以下の応答が出力されます。
target queue is EXAMPLE.QUEUE
任意のテキストを入力してから Enter を押す操作を何回か繰り返すことで、キューに複数のメッセージを書き込みます。
書き込みを終了するには、Enter を 2 回押します。
キューからのメッセージの取得
以下のコマンドを実行します。
amqsgetc EXAMPLE.QUEUE HAEXAMPLE
前のステップで追加したメッセージがコンシュームされ、出力されます。
数秒後にコマンドが終了します。
アクティブ・ポッドの障害の強制試行
キュー・マネージャーの自動復旧を検証するには、ポッドの障害をシミュレートします。
アクティブ・ポッドとスタンバイ・ポッドの表示
以下のコマンドを実行します。
oc get pods --selector app.kubernetes.io/instance=nativeha-example
READY フィールドでは、アクティブ・ポッドは値 1/1 を返し、レプリカ・ポッドは値 0/1 を返すことに注意してください。
アクティブ・ポッドの削除
アクティブ・ポッドの絶対パス名を指定して次コマンドを実行します。
oc delete pod nativeha-example-ibm-mq-<value>
ポッドの状況の再表示
以下のコマンドを実行します。
oc get pods --selector app.kubernetes.io/instance=nativeha-example
キュー・マネージャーの状況の表示
他のいずれかのポッドの絶対パス名を指定して次のコマンドを実行します。
oc exec -t Pod -- dspmq -o nativeha -x -m HAEXAMPLE
アクティブ・インスタンスが変更されたことを示す状況が表示されるはずです。以下に例を示します。
QMNAME(HAEXAMPLE) ROLE(Active) INSTANCE(inst1) INSYNC(Yes) QUORUM(3/3)
INSTANCE(inst1) ROLE(Active) REPLADDR(9.20.123.45) CONNACTV(Yes) INSYNC(Yes) BACKLOG(0) CONNINST(Yes) ALTDATE(2022-01-12) ALTTIME(12.03.44)
INSTANCE(inst2) ROLE(Replica) REPLADDR(9.20.123.46) CONNACTV(Yes) INSYNC(Yes) BACKLOG(0) CONNINST(Yes) ALTDATE(2022-01-12) ALTTIME(12.03.44)
INSTANCE(inst3) ROLE(Replica) REPLADDR(9.20.123.47) CONNACTV(Yes) INSYNC(Yes) BACKLOG(0) CONNINST(Yes) ALTDATE(2022-01-12) ALTTIME(12.03.44)
メッセージの再度の書き込みと読み込み
スタンバイ・ポッドがアクティブ・ポッドになった後 (つまり、READY フィールドの値が 1/1 になった後) で、前述のように以下のコマンドを再び使用して、キュー・マネージャーにメッセージを渡して、その後にキュー・マネージャーからメッセージを取得します。
amqsputc EXAMPLE.QUEUE HAEXAMPLE
amqsgetc EXAMPLE.QUEUE HAEXAMPLE

これで成功です。ネイティブ HA キュー・マネージャーが正常にデプロイされ、ポッドの障害から自動的に復旧できることが分かりました。

詳細情報

注 1: ルートの作成
IBM MQ 9.2.1 より前の IBM MQ client またはツールキットを使用している場合は、Route を作成する必要があります。
ルートを作成するには、先ほど作成した名前空間にいることを確認し( 始める前にを参照)、 Red Hat OpenShift Container Platform のWebコンソールもしくはコマンドラインで次のYAMLを入力します:
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: example-mi-route
spec:
  host: hamqchl.chl.mq.ibm.com
  to:
    kind: Service
    name: nativeha-example-ibm-mq
  port:
    targetPort: 1414
  tls:
    termination: passthrough
なお、 Red Hat OpenShift Container Platform Router は、 IBM MQ キュー・マネージャーへのリクエストのルーティングにSNIを使用している。 MQSC コマンドを含む構成マップで指定されたチャネル名を変更する場合は、ここでホスト・フィールドも変更する必要があります。また、 キュー・マネージャーの詳細を指定する CCDT.JSON ファイルで変更する必要もあります。 詳細については、 Red Hat OpenShift クラスタの外部からキューマネージャに接続するためのルートの設定を参照してください。
注 2: デフォルト以外のストレージ・クラスの使用
この例では、 Red Hat OpenShift Container Platform でデフォルトのストレージクラスが設定されていることを想定しています。したがって、 キューマネージャカスタムリソース YAML にはストレージ情報は必要ありません。 ストレージ・クラスがデフォルトとして構成されていない場合、または別のストレージ・クラスを使用したい場合は、defaultClass: <storage_class_name>spec.queueManager.storage の下に追加します。
このストレージ・クラス名は、既存のストレージ・クラスの名前と厳密に一致している必要があります。 つまり、この名前はコマンド oc get storageclass によって返される名前と一致しなければなりません。 また、これは ReadWriteMany もサポートする必要があります。 詳細については、 IBM MQ Operatorのストレージに関する考慮事項を参照。