[OpenShift Container Platform][MQ 9.2.3 2021 年 7 月][持續交付][IBM Cloud Pak for Integration][Linux]

範例: 配置原生 HA 佇列管理程式

此範例顯示如何使用 IBM® MQ Operator,將使用原生高可用性特性的佇列管理程式部署至 Red Hat® OpenShift® Container Platform (OCP)。

開始之前

若要完成此範例,您必須先完成下列必要條件:

  • 安裝 IBM MQ client,並將已安裝的 samp/binbin 目錄新增至 PATH。 用戶端提供此範例所需的 runmqakmamqsputcamqsgetc 應用程式。 安裝 IBM MQ client ,如下所示:
  • 安裝適用於您作業系統的 OpenSSL 工具。 如果您還沒有私密金鑰和憑證,則需要此項來產生佇列管理程式的自簽憑證。
  • 為此範例建立 Red Hat OpenShift Container Platform (OCP) 專案/名稱空間,並遵循作業 為 IBM MQ 準備 Red Hat OpenShift 專案 中的步驟
  • 在指令行上,登入 OCP 叢集,並切換至您剛建立的名稱空間。
  • 請確定 IBM MQ Operator 已安裝且可在名稱空間中使用。
  • 在 OCP 中配置要由佇列管理程式使用的預設儲存類別。 如果您想要在不設定預設儲存空間類別的情況下完成本指導教學,請參閱 附註 2: 使用非預設儲存空間類別

關於此作業

原生 HA 佇列管理程式涉及一個作用中及兩個抄本 Kubernetes Pod。 這些會作為 Kubernetes 有狀態集的一部分執行,其中正好有三個抄本及一組 Kubernetes 持續性磁區。 如需原生 HA 佇列管理程式的相關資訊,請參閱 儲存器中 IBM MQ 的高可用性

此範例提供自訂資源 YAML ,其定義使用持續性儲存體且使用 TLS 配置的原生 HA 佇列管理程式。 將佇列管理程式部署至 OCP 之後,您會模擬作用中佇列管理程式 Pod 的失敗。 您會看到自動回復發生,並在失敗之後放置並取得訊息,以證明它已成功。

範例

為 MQ 伺服器建立 TLS 私密金鑰和憑證
您可以為佇列管理程式建立自簽憑證,並將憑證新增至金鑰資料庫,以充當用戶端的信任儲存庫。 如果您已有私密金鑰和憑證,則可以改用那些金鑰和憑證。 請注意,您只應該將自簽憑證用於開發目的。
若要在現行目錄中建立自簽私密金鑰及公用憑證,請執行下列指令:
openssl req -newkey rsa:2048 -nodes -keyout tls.key -subj "/CN=localhost" -x509 -days 3650 -out tls.crt
建立 TLS 私密金鑰及憑證,以供原生 HA 內部使用
原生 HA 佇列管理程式中的三個 Pod 會透過網路抄寫資料。 您可以建立自簽憑證,以在內部抄寫時使用。 請注意,您只應該將自簽憑證用於開發目的。
若要在現行目錄中建立自簽私密金鑰及公用憑證,請執行下列指令:
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 指令的配置對映
建立包含 MQSC 指令的 Kubernetes 配置對映,以建立新的佇列及「SVRCONN 通道」,以及新增通道鑑別記錄,只封鎖那些稱為 nobody的使用者來容許存取通道。

請注意,此方法應該僅用於開發目的。

確定您位於先前建立的名稱空間中 (請參閱 開始之前) ,然後在 OCP 使用者介面中輸入下列 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 client 或工具箱早於 IBM MQ 9.2.1,則需要建立 OCP 路徑,而不是先前的配置檔。 遵循 附註 1: 建立路徑中的步驟。
部署佇列管理程式
重要事項: 在此範例中,我們使用 MQSNAUT 變數來停用佇列管理程式上的授權,這可讓我們專注於使用 TLS 連接用戶端所需的步驟。 在 IBM MQ的正式作業部署中不建議這樣做,因為它會導致任何連接的應用程式都具有完整管理權力,且沒有降低個別應用程式許可權的機制。

複製並更新下列 YAML。
  • 請確定已指定正確的授權。 請參閱 mq.ibm.com/v1beta1。 在 IBM Cloud Pak® for Integration 2021.1.1中,授權必須是評估授權 L-RJON-BYRMYW
  • false 變更為 true以接受授權。
佇列管理程式自訂資源 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 Web 主控台、指令行或使用 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 鍵兩次。
從佇列擷取訊息
請執行下列指令:
amqsgetc EXAMPLE.QUEUE HAEXAMPLE
您在前一個步驟中新增的訊息已耗用且為輸出。
在幾秒鐘之後,指令結束。
強制作用中 Pod 失敗
若要驗證佇列管理程式的自動回復,請模擬 Pod 失敗:
檢視作用中及待命 Pod
請執行下列指令:
oc get pods --selector app.kubernetes.io/instance=nativeha-example
請注意,在 READY 欄位中,作用中 Pod 會傳回值 1/1,而抄本 Pod 會傳回值 0/1
刪除作用中 Pod
執行下列指令,並指定作用中 Pod 的完整名稱:
oc delete pod nativeha-example-ibm-mq-<value>
再次檢視 Pod 狀態
請執行下列指令:
oc get pods --selector app.kubernetes.io/instance=nativeha-example
檢視佇列管理程式狀態
執行下列指令,並指定其中一個其他 Pod 的完整名稱:
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)
再次放置並取得訊息
在待命 Pod 變成作用中 Pod (亦即,在 READY 欄位值變成 1/1之後) 之後,如先前所述,再次使用下列指令將訊息放置到佇列管理程式,然後從佇列管理程式擷取訊息:
amqsputc EXAMPLE.QUEUE HAEXAMPLE
amqsgetc EXAMPLE.QUEUE HAEXAMPLE

恭喜您,您已順利部署原生 HA 佇列管理程式,並顯示它可以自動從 Pod 失敗中回復。

其他資訊

附註 1: 建立路徑
如果您使用早於 IBM MQ 9.2.1IBM MQ client 或工具箱,則需要建立路徑。
若要建立路徑,請確定您位於先前建立的名稱空間中 (請參閱 開始之前) ,然後在 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 會使用 SNI 將要求遞送至 IBM MQ 佇列管理程式。 如果您變更 包含 MQSC 指令的配置對映中指定的通道名稱,則也必須在這裡變更主機欄位,以及在 CCDT.JSON 檔案中指定佇列管理程式詳細資料。 如需相關資訊,請參閱 配置路徑以從 Red Hat OpenShift 叢集外部連接至佇列管理程式
附註 2: 使用非預設儲存類別
此範例預期已在 Red Hat OpenShift Container Platform中配置預設儲存類別,因此 佇列管理程式自訂資源 YAML中不需要任何儲存體資訊。 如果您未將儲存類別配置為預設值,或想要使用不同的儲存類別,請在 spec.queueManager.storage下新增 defaultClass: <storage_class_name>
儲存類別名稱必須完全符合已存在的儲存類別名稱。 也就是說,它必須符合指令 oc get storageclass所傳回的名稱。 它也必須支援 ReadWriteMany。 如需相關資訊,請參閱 IBM MQ 操作器的儲存體考量