例: IBM MQ Operator を使用したネイティブ HA の構成

この例では、 IBM® MQ Operatorを使用して、ネイティブ高可用性フィーチャーを使用するキュー・マネージャーを OpenShift® Container Platform にデプロイします。相互 TLS は、認証に使用され、TLS 証明書からキュー・マネージャー内の ID にマップされます。

始める前に

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

この例のための OpenShift Container Platform (OCP) プロジェクト / 名前空間を作成します。
コマンド・ラインで OCP クラスターにログインし、上記の名前空間に切り替えます。
IBM MQ Operator がインストールされており、上記の名前空間で使用可能であることを確認します。

本タスクについて

この例では、 OpenShift Container Platformにデプロイするキュー・マネージャーを定義するカスタム・リソース YAML を提供します。また、TLS を有効にしてキュー・マネージャーをデプロイするために必要な追加のステップも詳しく説明しています。

手順

OpenSSLを使用した自己署名 PKI の作成の説明に従って、証明書のペアを作成します。
MQSC コマンドと INI ファイルを含む構成マップの作成
MQSC コマンドを含む Kubernetes ConfigMap を作成して、新しいキューと SVRCONN チャネルを作成し、チャネルへのアクセスを許可するチャネル認証レコードを追加します。
前に作成した名前空間 ( 始める前にを参照) にいることを確認してから、OCP Web コンソールで、またはコマンド・ラインを使用して、以下の YAML を入力します。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-nativeha-configmap
data:
  example-tls.mqsc: |
    DEFINE CHANNEL('MTLS.SVRCONN') CHLTYPE(SVRCONN) SSLCAUTH(REQUIRED) SSLCIPH('ANY_TLS13_OR_HIGHER') REPLACE
    SET CHLAUTH('MTLS.SVRCONN') TYPE(SSLPEERMAP) SSLPEER('CN=*') USERSRC(NOACCESS) ACTION(REPLACE)
    SET CHLAUTH('MTLS.SVRCONN') TYPE(SSLPEERMAP) SSLPEER('CN=example-app1') USERSRC(MAP) MCAUSER('app1') ACTION(REPLACE)
    SET AUTHREC PRINCIPAL('app1') OBJTYPE(QMGR) AUTHADD(CONNECT,INQ)
    DEFINE QLOCAL('EXAMPLE.QUEUE') REPLACE 
    SET AUTHREC PROFILE('EXAMPLE.QUEUE') PRINCIPAL('app1') OBJTYPE(QUEUE) AUTHADD(BROWSE,PUT,GET,INQ)
  example-tls.ini: |
    Service:
        Name=AuthorizationService
        EntryPoints=14
        SecurityPolicy=UserExternal
```
MQSC は、 MTLS.SVRCONN というチャネルと、 EXAMPLE.QUEUE。チャネルは、「共通名」が example-app1の証明書を提示するクライアントにのみアクセスを許可するように構成されています。これは、ステップ 1で作成した証明書のいずれかで使用される共通名です。この共通名を持つこのチャネル上の接続は、 app1というユーザー ID にマップされます。このユーザー ID は、キュー・マネージャーに接続し、サンプル・キューにアクセスすることを許可されています。 INI ファイルはセキュリティー・ポリシーを使用可能にします。これは、 app1 ユーザー ID が外部ユーザー・レジストリーに存在する必要がないことを意味します。この ID は、この構成に名前としてのみ存在します。
キュー・マネージャーのデプロイ
以下のカスタム・リソース YAML を使用して、新しいキュー・マネージャーを作成します。このタスクを開始する前に作成した名前空間にいることを確認してから、OCP Web コンソールで、またはコマンド・ラインを使用して、以下の YAML を入力します。正しいライセンスが指定されていることを確認し、false を true に変更してライセンスを受け入れます。
```
apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: exampleqm
spec:
  license:
    accept: false
    license: L-AMRD-XH6P3Q
    use: Production
  queueManager:
    name: EXAMPLEQM
    availability:
      type: NativeHA
      tls:
        secretName: example-qm-tls
    mqsc:
    - configMap:
        name: example-nativeha-configmap
        items:
        - example-tls.mqsc
    ini:
    - configMap:
        name: example-nativeha-configmap
        items:
        - example-tls.ini
    storage:
      queueManager:
        type: persistent-claim
  version: 9.3.5.1-r2
  pki:
    keys:
      - name: default
        secret:
          secretName: example-qm-tls
          items:
            - tls.key
            - tls.crt
            - ca.crt
```
シークレット example-qm-tls はステップ 1で作成され、 ConfigMap example-nativeha-configmap はステップ 2 で作成されたことに注意してください。

可用性タイプはNativeHA に設定され、永続ストレージが選択されています。 Kubernetes クラスターで構成されているデフォルトのストレージ・クラスが使用されます。ストレージ・クラスがデフォルトとして構成されていない場合、または別のストレージ・クラスを使用したい場合は、defaultClass: <storage_class_name> を spec.queueManager.storage の下に追加します。

ネイティブ HA キュー・マネージャー内の 3 つのポッドは、ネットワークを介してデータを複製します。このリンクはデフォルトでは暗号化されませんが、この例ではトラフィックの暗号化にキュー・マネージャーの証明書を使用します。セキュリティーを強化するために、別の証明書を指定することができます。ネイティブ HA TLS シークレットは、特定の構造を持つ Kubernetes TLS シークレットでなければなりません (例えば、秘密鍵を tls.keyという名前にする必要があります)。
キュー・マネージャーが稼働していることの確認
キュー・マネージャーがデプロイされます。続行する前に、Running 状態であることを確認してください。以下に例を示します。
```
oc get qmgr exampleqm
```
キュー・マネージャーへの接続のテスト
キュー・マネージャーが構成済みで使用可能であることを確認するには、ラップトップからキュー・マネージャーへの相互 TLS 接続のテストの手順に従います。
アクティブ・ポッドの障害の強制試行
キュー・マネージャーの自動復旧を検証するには、ポッドの障害をシミュレートします。
1. アクティブ・ポッドとスタンバイ・ポッドの表示
  以下のコマンドを実行します。
```
oc get pods --selector app.kubernetes.io/instance=exampleqm
```
  READY フィールドでは、アクティブ・ポッドは値 1/1 を返し、レプリカ・ポッドは値 0/1 を返すことに注意してください。
2. アクティブ・ポッドの削除
  アクティブ・ポッドの絶対パス名を指定して次コマンドを実行します。
```
oc delete pod exampleqm-ibm-mq-<value>
```
3. ポッドの状況の再表示
  以下のコマンドを実行します。
```
oc get pods --selector app.kubernetes.io/instance=exampleqm
```
4. キュー・マネージャーの状況の表示
  他のいずれかのポッドの絶対パス名を指定して次のコマンドを実行します。
```
oc exec -t Pod -- dspmq -o nativeha -x -m EXAMPLEQM
```
  アクティブ・インスタンスが変更されたことを示す状況が表示されるはずです。以下に例を示します。
```
QMNAME(EXAMPLEQM) 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)
```
5. キュー・マネージャーへの接続を再度テストする
  キュー・マネージャーが復旧したことを確認するには、ラップトップからキュー・マネージャーへの相互 TLS 接続のテストの手順に従います。

結果

これで、ネイティブの高可用性と相互 TLS 認証を使用してキュー・マネージャーが正常にデプロイされ、アクティブなポッドで障害が発生したときに自動的に復旧することが確認されました。