![[OpenShift Container Platform]](ngocp.gif)
![[MQ 9.2.3 Jul 2021]](ng923.gif)
![[Continuous Delivery]](ngcd.gif)
![[IBM Cloud Pak for Integration]](ngcp4i.gif)
![[Linux]](nglinux.gif)
例: ネイティブ HA キュー・マネージャーの構成
この例では、ネイティブの高可用性機能を使用したキュー・マネージャを、 IBM® MQ Operator を使用して Red Hat® OpenShift® Container Platform (OCP) に配置する方法を示します。
始める前に
この例を完了するには、まず以下の前提条件を満たしておく必要があります。
- IBM MQ clientをインストールし、インストール済みの samp/bin ディレクトリーおよび bin ディレクトリーを パスに追加します。 この例で必要な runmqakm、amqsputc、amqsgetc の各アプリケーションはクライアントで提供されています。 IBM MQ client を以下のように取り付ける:
![[Windows]](ngwin.gif)
Windows および の場合: 再頒布可能クライアントを次のサイトからインストールします。 Linux® IBM MQ https://ibm.biz/mq92redistclients
Mac : をダウンロードしてセットアップしてください。 IBM MQ MacOS Toolkit 参照 https://ibm.biz/mqdevmacclient.
- お使いのオペレーティングシステム用の 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 秘密鍵と証明書の作成
- キュー・マネージャーの自己署名証明書を作成し、クライアントのトラストストアとして機能する鍵データベースに証明書を追加することができます。 秘密鍵と証明書がすでに存在する場合は、代わりにそれらを使用できます。 開発目的の場合、自己署名証明書のみを使用する必要があることに注意してください。
- ネイティブ HA で内部使用される TLS 秘密鍵と証明書の作成
- ネイティブ HA キュー・マネージャー内の 3 つのポッドは、ネットワークを介してデータを複製します。 内部的に複製する際に使用するための自己署名証明書を作成できます。 開発目的の場合、自己署名証明書のみを使用する必要があることに注意してください。
- クライアントの鍵データベースへのキュー・マネージャーの公開鍵の追加
- クライアント・アプリケーションのトラストストアとしてクライアントの鍵データベースを使用します。
- キュー・マネージャー・デプロイメントのための 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 マップを作成する。
この方法を使用するのは、開発のためだけに限定してください。
- ルーティングの構成
- IBM MQ 9.2.1 以降の IBM MQ client やツールキットを使用している場合、キューマネージャ設定ファイル(INI ファイル)を使用することで、キューマネージャへのルーティングを設定することができます。 このファイル内で、チャネル名ではなくホスト名に基づいてルーティングするように OutboundSNI 変数を設定します。
- キュー・マネージャーのデプロイ
- 重要: この例では、MQSNOAUT 変数を使用してキュー・マネージャーでの許可を無効にします。これにより、TLS を使用してクライアントを接続するために必要なステップに集中できるようになります。 これは、 IBM MQ の本番環境では推奨されません。なぜなら、接続するすべてのアプリケーショ ンが完全な管理権限を持つことになり、個々のアプリケーションの権限を下げる仕組みがないからです。
検証
このセクションでは、キュー・マネージャーが想定どおりに動作することを検証します。
- キュー・マネージャーが稼働していることの確認
- キュー・マネージャーがデプロイされます。 続行する前に、
Running状態であることを確認してください。 以下に例を示します。oc get qmgr nativeha-example - キュー・マネージャーへの接続のテスト
- キュー・マネージャーで単方向の TLS 通信が構成されていることを確認するために、サンプル・アプリケーション amqsputc と amqsgetc を使用します。
- キュー・マネージャーのホスト名の検索
- ルート
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" } ] } - 環境変数のエクスポート
- オペレーティング・システムに適した方法で以下の環境変数をエクスポートします。 これらの変数は amqsputc と amqsgetc によって読み取られます。
- キューへのメッセージの書き込み
- 以下のコマンドを実行します。
amqsputc EXAMPLE.QUEUE HAEXAMPLE - キューからのメッセージの取得
- 以下のコマンドを実行します。
amqsgetc EXAMPLE.QUEUE HAEXAMPLE
- アクティブ・ポッドの障害の強制試行
- キュー・マネージャーの自動復旧を検証するには、ポッドの障害をシミュレートします。
- アクティブ・ポッドとスタンバイ・ポッドの表示
- 以下のコマンドを実行します。
READY フィールドでは、アクティブ・ポッドは値oc get pods --selector app.kubernetes.io/instance=nativeha-example1/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 - メッセージの再度の書き込みと読み込み
- スタンバイ・ポッドがアクティブ・ポッドになった後 (つまり、
READYフィールドの値が1/1になった後) で、前述のように以下のコマンドを再び使用して、キュー・マネージャーにメッセージを渡して、その後にキュー・マネージャーからメッセージを取得します。amqsputc EXAMPLE.QUEUE HAEXAMPLEamqsgetc EXAMPLE.QUEUE HAEXAMPLE
これで成功です。ネイティブ HA キュー・マネージャーが正常にデプロイされ、ポッドの障害から自動的に復旧できることが分かりました。
詳細情報
- 注 1: ルートの作成
- IBM MQ 9.2.1 より前の IBM MQ client またはツールキットを使用している場合は、Route を作成する必要があります。
- 注 2: デフォルト以外のストレージ・クラスの使用
- この例では、 Red Hat OpenShift Container Platform でデフォルトのストレージクラスが設定されていることを想定しています。したがって、 キューマネージャカスタムリソース YAML にはストレージ情報は必要ありません。 ストレージ・クラスがデフォルトとして構成されていない場合、または別のストレージ・クラスを使用したい場合は、
defaultClass: <storage_class_name>をspec.queueManager.storageの下に追加します。