[OpenShift Container Platform][Kubernetes][亚马逊EKS][IBM MQ Advanced]

示例：使用 IBM MQ 操作员部署简单的原生高可用CRR配置

此示例通过 IBM® MQ Operator部署了一个队列管理器，采用简单的原生高可用跨区域复制（CRR）配置。

开始之前

要完成此示例，必须首先完成以下步骤：

关于本任务

本地 HA CRR 配置定义了两个本地 HA 组，它们共同组成一个高可用性队列管理器。 这些组通常部署在不同位置的两个集群中，但此示例允许您根据需要将两个组都部署到同一集群。 有关原生高可用性跨区域复制的概述，请参阅《原生高可用性跨区域复制》。

为简单起见，本例使用单个证书来保护所有队列管理器复制流量，该证书名为 nhacrr-qm-replication。

要了解证书在原生高可用性CRR中的使用方式，以及如何使用不同证书来保护群组和实例流量，请参阅示例：在原生高可用性CRR中使用多个 TLS 证书。

显示配置示例

重要提示： 这些示例旨在帮助您入门，并不适合生产环境。 对于高级用户来说，证书管理是一个复杂的课题。 在生产过程中，你必须考虑轮换、撤销、密钥长度、灾难恢复等问题。

本例提供自定义资源 YAML，用于定义两个提供跨区域复制的本地 HA 组。

过程

  1. 创建用于队列管理器复制流量的证书。

    使用以下命令创建私钥，并用它为内部证书颁发机构颁发自签名证书。 然后为队列管理器创建私钥和证书，并与内部证书颁发机构签署：

    openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:4096 -out nhacrr-ca.key
openssl req -x509 -new -nodes -key "nhacrr-ca.key" -sha512 -days 30 -subj "/CN=nhacrr-selfsigned-ca" -out nhacrr-ca.crt
openssl req -new -nodes -out nhacrr-qm-replication.csr -newkey rsa:4096 -keyout nhacrr-qm-replication.key -subj "/CN=nhacrr-qm-replication"
openssl x509 -req -in nhacrr-qm-replication.csr -CA nhacrr-ca.crt -CAkey nhacrr-ca.key -CAcreateserial -out nhacrr-qm-replication.crt -days 7 -sha512

    有关这些命令的更多信息，请参阅 《使用 OpenSSL 创建自签名PKI 》。

  2. 创建两个 Kubernetes 保密文件，其中包含队列管理器密钥和证书。 在罗马和伦敦站点上创建名为 nhacrr-qm-replication 的秘密，用于存储队列管理器实例的密钥和证书。

    使用以下命令创建秘密。 在运行该命令前，先切换到每个命名空间（先是罗马，然后是伦敦）。

    kubectl create secret generic nhacrr-qm-replication --type="kubernetes.io/tls" --from-file=tls.key=nhacrr-qm-replication.key --from-file=tls.crt=nhacrr-qm-replication.crt --from-file=nhacrr-ca.crt
  3. 为队列管理器流量创建一对证书，具体操作请参阅 《使用 OpenSSL 创建自签名PKI 》中的说明。 在罗马和伦敦站点上创建密文（即图中名为 mq-channel 和 client-app 的证书）。
  4. 为罗马和伦敦创建一个包含 MQSC 命令和 INI 文件的配置地图。 创建一个包含MQSC命令的 ConfigMap 资源，用于创建新的持久消息队列和SVRCONN通道，并添加允许访问该通道的通道身份验证记录。
    在罗马站点上，创建以下 ConfigMap ，然后通过在 Red Hat OpenShift...上使用命令，或在... oc apply 上使用 kubectl apply 命令来 Amazon EKS应用它。 在 OCP Web 控制台中，您也可以通过选择 ConfigMaps 然后创建 ConfigMapRed Hat OpenShift 来输入 YAML 配置。 对伦敦站点重复此步骤。
    apiVersion: v1
kind: ConfigMap
metadata:
  name: nhacrr-configmap
data:
  nhacrr.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') DEFPSIST(YES) REPLACE 
    SET AUTHREC PROFILE('EXAMPLE.QUEUE') PRINCIPAL('app1') OBJTYPE(QUEUE) AUTHADD(BROWSE,PUT,GET,INQ)
  nhacrr.ini: |
    Service:
        Name=AuthorizationService
        EntryPoints=14
        SecurityPolicy=UserExternal

    MQSC 定义了一个名为 MTLS.SVRCONN 的通道和一个名为 EXAMPLE.QUEUE 的队列。 通道被配置为只允许提交 CN 为 example-app1 的证书（如步骤 3 中创建的证书）的客户端访问。

  5. 部署本地 HA 恢复组。 恢复小组已部署至罗马现场。 请确保您处于罗马命名空间中，然后创建 QueueManager。
    注意： 您必须在运行组和恢复组中使用相同的队列管理器名称。 默认情况下，如果不指定 .spec.queuemanager.name ，则默认为 .metadata.name。 您可以使用以下方法之一实现名称匹配：
    • 在每个群集中为队列管理器资源命名相同的名称（即 .metadata.name 匹配），并且不要覆盖名称
    • 在 .metadata.name 中单独命名队列管理器，并用 .spec.queuemanager.name 覆盖该名称，以便两个站点的名称一致。
    在此示例中，通过使用 `` 将队列 exampleqm.metadata.name 管理器名称设置为 ``。
    注： 此示例采用 IBM MQ Advanced 许可证。 根据 IBM MQ9.4.2 的说明，通过为队列管理器 IBM MQ 添加额外许可证，授权的队列管理器也可配置为使用原生高可用性和跨区域复制功能。 有关详细信息，请参阅 《使用 IBM MQ 操作员在 IBM MQ 许可的队列管理器上配置本机高可用性和跨区域复制 》。
    重要提示： 若您接受许可 IBM MQ Advanced 协议，请将 替换 accept: false 为 accept: true。 有关许可证的详细信息，请参阅 mq.ibm.com/v1beta1: 当前许可证版本。
    示例 QueueManager 用于 Red Hat OpenShift
    使用命令行或Web Red Hat OpenShift Container Platform 控制台，以以下配置部署队列管理器。
    apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: exampleqm
  labels:
    role: Recovery
spec:
  license:
    accept: false
    license: L-NUUP-23NH8Y
    use: Production
  queueManager:
    name: EXAMPLEQM
    availability:
      type: NativeHA
      tls:
        secretName: nhacrr-qm-replication
      nativeHAGroups:
        local:
          name: "rome"
          role: "Recovery"
    mqsc:
    - configMap:
        name: nhacrr-configmap
        items:
        - nhacrr.mqsc
    ini:
    - configMap:
        name: nhacrr-configmap
        items:
        - nhacrr.ini
    storage:
      queueManager:
        type: persistent-claim
  version:  9.4.5.0-r2
  pki:
    keys:
      - name: default
        secret:
          secretName: example-qm-tls
          items:
            - tls.key
            - tls.crt
            - ca.crt
    示例 QueueManager 用于 Amazon EKS
    在 Amazon EKS 集群上部署队列管理器时，请使用以下配置：
    apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: exampleqm
  labels:
    role: Recovery
spec:
  license:
    accept: false
    license: L-NUUP-23NH8Y
    use: Production
  queueManager:
    name: EXAMPLEQM
    availability:
      type: NativeHA
      tls:
        secretName: nhacrr-qm-replication
      nativeHAGroups:
        local:
          name: "rome"
          role: "Recovery"
          route:
            enabled: false
    mqsc:
    - configMap:
        name: nhacrr-configmap
        items:
        - nhacrr.mqsc
    ini:
    - configMap:
        name: nhacrr-configmap
        items:
        - nhacrr.ini
    storage:
      queueManager:
        type: persistent-claim
    route:
      enabled: false
    metrics:
      serviceMonitor:
        enabled: false
  version: 9.4.5.0-r2
  pki:
    keys:
      - name: default
        secret:
          secretName: example-qm-tls
          items:
            - tls.key
            - tls.crt
            - ca.crt
  web:
    enabled: false
    route:
      enabled: false
    spec.queueManager.route.enabled, spec.queueManager.availability.nativeHAGroups.route.enabled, spec.queueManager.metrics.serviceMonitor.enabled, 和 spec.web.route.enabled 被设置为 false ，因为这些是默认启 Red Hat OpenShift 用的特定功能。 这些功能必须在 Amazon EKS. 上明确禁用。
  6. 验证恢复组是否已正确部署：
    1. 执行相关命令以显示队列管理器资源，然后等待队列管理器开始运行。
      • 在 Red Hat OpenShift 上：
        oc get qmgr exampleqm
      • 在 Amazon EKS 上：
        kubectl get qmgr exampleqm
      您应该看到以下消息：
      NAME             PHASE
exampleqm   Running
    2. 当队列管理器运行时，请使用相关命令检查 Pod 状态。
      • 在 Red Hat OpenShift 上：
        oc get pods
      • 在 Amazon EKS 上：
        kubectl get pods
      一个荚舱应处于就绪状态：
      NAME                 READY   STATUS    RESTARTS   AGE
exampleqm-ibm-mq-0   1/1     Running   0          2m45s
exampleqm-ibm-mq-1   0/1     Running   0          2m45s
exampleqm-ibm-mq-2   0/1     Running   0          2m45s
    3. 使用相关命令检查恢复组的状态，其中 表示 <LEADER-POD> 就绪的 1/1 Pod 名称（exampleqm-ibm-mq-0 示例中为）。
      • 在 Red Hat OpenShift 上：
        oc exec -t <LEADER-POD> -- dspmq -o nativeha -g
      • 在 Amazon EKS 上：
        kubectl exec -t <LEADER_POD> -- dspmq -o nativeha -g
      您应该会看到以下输出：
      QMNAME(EXAMPLEQM)                                         ROLE(Leader) INSTANCE(exampleqm-ibm-mq-0) INSYNC(yes)   QUORUM(1/3) GRPLSN() GRPNAME(rome) GRPROLE(Recovery)
 GRPNAME(rome) GRPROLE(Recovery) GRPADDR(Unknown) GRPVER(9.4.2.0) GRSTATUS(Waiting for connection) RCOVLSN()   RCOVTIME() BACKLOG(Unknown) INSYNC(Unknown) SYNCTIME() ALTDATE(2025-04-25) ALTTIME(13.48.15)
      该状态的关键部分如下：
      • Role(Leader)
      • QUORUM(1/3) - 在Live和Recovery组连接之前，该值保持为1/3
      • GRSTATUS(Waiting for connection) - 当实时组连接时，此内容将更新
  7. 仅限 Amazon EKS 部署 ：配置 以允许 Live 组与 Recovery LoadBalancer 组通信。
    1. 请确保您处于 Rome 命名空间中，然后创建 LoadBalancerService 以便通过以下配置从集群外部建立 TLS 连接至队列管理器。
      apiVersion: v1
kind: Service
metadata:
  name: crr-rome
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
spec:
  type: LoadBalancer
  ports:
    - port: 9415
      targetPort: 9415
      name: nha-crr
  selector:
    app.kubernetes.io/name: ibm-mq
    app.kubernetes.io/instance: exampleqm
      重要提示： 若您使用的是 IPv6 单堆栈系统，请对以下 metadata.annotations 部分进行相应修改：
      • 将 的值 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type 从 "instance" 更改为 "ip"
      • 添加以下行：
        service.beta.kubernetes.io/aws-load-balancer-ip-address-type: "dualstack"
    2. 验证类型为 的 Service 是否已 LoadBalancer 创建：
      kubectl get service <LOAD_BALANCER_NAME>
    3. 请确认您的 LoadBalancer 已准备就绪。
      Amazon 负载均衡控制器需要几分钟时间来配置并注册其目标。 运行以下命令以显示. LoadBalancer的状态。 当 准备就绪 LoadBalancer 时，状态为 active：
      aws elbv2 describe-load-balancers --query 'LoadBalancers[*].[LoadBalancerName,State.Code]' --output text
  8. 部署本地 HA Live 组。 现场小组部署在伦敦现场：
    请确保您处于正确的命名空间中，然后创建 QueueManager。
    注： 此示例采用 IBM MQ Advanced 许可证。 根据 IBM MQ9.4.2 的说明，通过为队列管理器 IBM MQ 添加额外许可证，授权的队列管理器也可配置为使用原生高可用性和跨区域复制功能。 有关详细信息，请参阅 《使用 IBM MQ 操作员在 IBM MQ 许可的队列管理器上配置本机高可用性和跨区域复制 》。
    重要提示： 若您接受许可 IBM MQ Advanced 协议，请将 替换 accept: false 为 accept: true。 有关许可证的详细信息，请参阅 mq.ibm.com/v1beta1: 当前许可证版本。
    示例 QueueManager 用于 Red Hat OpenShift
    使用命令行或Web Red Hat OpenShift Container Platform 控制台，以以下配置部署队列管理器。
    apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: exampleqm
  labels:
    role: Live
spec:
  license:
    accept: false
    license: L-NUUP-23NH8Y
    use: Production
  queueManager:
    name: EXAMPLEQM
    availability:
      type: NativeHA
      tls:
        secretName: nhacrr-qm-replication
      nativeHAGroups:
        local:
          name: "london"
          role: "Live"
        remotes:
          - name: "rome"
            addresses:
              - "<rome group hostname>:443"
    mqsc:
    - configMap:
        name: nhacrr-configmap
        items:
        - nhacrr.mqsc
    ini:
    - configMap:
        name: nhacrr-configmap
        items:
        - nhacrr.ini
    storage:
      queueManager:
        type: persistent-claim
  version: 9.4.5.0-r2
  pki:
    keys:
      - name: default
        secret:
          secretName: example-qm-tls
          items:
            - tls.key
            - tls.crt
            - ca.crt
    更新YAML文件中指定的地址，该地址用于实时组连接到恢复组（"<rome group hostname>:443" 如示例所示）。 将其替换为罗马站点上该 exampleqm-ibm-mq-nhacrr 路由的主机属性。 要检索此属性，请确保您位于罗马站点，并使用以下命令获取路由 nhacrr 主机名：
    oc get route exampleqm-ibm-mq-nhacrr --template="{{.spec.host}}"
    注意： 部署CRR组时会创建两条路由，一条终止于 qm ，另一条终止于 nhacrr。 路由 qm 用于向队列管理器发送消息，而 nhacrr 路由则用于组间通信。 在 YAML 中，始终将 nhacrr 路由的主机地址添加为组的远程地址。
    示例 QueueManager 用于 Amazon EKS

    在 Amazon EKS 集群上部署队列管理器时，请使用以下配置：

    apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: exampleqm
  labels:
    role: Live
spec:
  license:
    accept: false
    license: L-NUUP-23NH8Y
    use: Production
  queueManager:
    name: EXAMPLEQM
    availability:
      type: NativeHA
      tls:
        secretName: nhacrr-qm-replication
      nativeHAGroups:
        local:
          name: "london"
          role: "Live"
          route:
            enabled: false
        remotes:
          - name: "rome"
            addresses:
              - "<rome group hostname>:9415"
    mqsc:
    - configMap:
        name: nhacrr-configmap
        items:
        - nhacrr.mqsc
    ini:
    - configMap:
        name: nhacrr-configmap
        items:
        - nhacrr.ini
    storage:
      queueManager:
        type: persistent-claim
    route:
      enabled: false
    metrics:
      serviceMonitor:
        enabled: false
  version: 9.4.5.0-r2
  pki:
    keys:
      - name: default
        secret:
          secretName: example-qm-tls
          items:
            - tls.key
            - tls.crt
            - ca.crt
  web:
    enabled: false
    route:
      enabled: false
    更新YAML文件中指定的地址，该地址用于实时组连接到恢复组（"<rome group hostname>:9415" 如示例所示）。 将其替换为 LoadBalancer 罗马站点上（您在上一步骤创建的）的宿主属性。 要检索此属性，请确保您位于罗马站点，然后使用以下命令获取主机名 nhacrrLoadBalancer ：
    kubectl get service <LOAD_BALANCER_NAME> -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}"
    spec.queueManager.route.enabled, spec.queueManager.availability.nativeHAGroups.route.enabled, spec.queueManager.metrics.serviceMonitor.enabled, 和 spec.web.route.enabled 被设置为 false ，因为这些是默认启 Red Hat OpenShift 用的特定功能。 这些功能必须在 Amazon EKS. 上明确禁用。
  9. 验证实时组和跨区复制。 重复步骤 6 中的操作，但这次是针对伦敦组。
    1. 执行相关命令以显示队列管理器资源，然后等待队列管理器开始运行。
      • 在 Red Hat OpenShift 上：
        oc get qmgr exampleqm
      • 在 Amazon EKS 上：
        kubectl get qmgr exampleqm
      您应该看到以下消息：
      NAME             PHASE
exampleqm   Running
    2. 当队列管理器运行时，请使用相关命令检查 Pod 状态。
      • 在 Red Hat OpenShift 上：
        oc get pods
      • 在 Amazon EKS 上：
        kubectl get pods
      一个荚舱应处于就绪状态：
      NAME                 READY   STATUS    RESTARTS   AGE
exampleqm-ibm-mq-0   1/1     Running   0          2m45s
exampleqm-ibm-mq-1   0/1     Running   0          2m45s
exampleqm-ibm-mq-2   0/1     Running   0          2m45s
    3. 使用以下命令检查恢复组的状态，其中 <ACTIVE-POD> 是就绪的 1/1 pod 的名称（exampleqm-ibm-mq-0 示例中为）。
      • 在 Red Hat OpenShift 上：
        oc exec -t <ACTIVE-POD> -- dspmq -o nativeha -g
      • 在 Amazon EKS 上：
        kubectl exec -t <ACTIVE-POD> -- dspmq -o nativeha -g
      oc exec -t <ACTIVE-POD> -- dspmq -o nativeha -g
      您应该会看到以下输出：
      QMNAME(EXAMPLEQM)                                         ROLE(Active) INSTANCE(exampleqm-ibm-mq-0) INSYNC(yes)   QUORUM(3/3)       GRPLSN(<0:0:87:58322>) GRPNAME(london) GRPROLE(Live)
 GRPNAME(london) GRPROLE(Live) GRPADDR(Unknown) GRPVER(9.4.2.0) GRSTATUS(Normal) RCOVLSN(<0:0:87:58322>)   RCOVTIME      (2025-05-16T14:27:09.051799Z) INITLSN(<0:0:9:4696>) INITTIME(2025-05-12T16:58:13.582274Z) LIVETIME  (2025-05-12T16:58:16.      319844Z) ALTDATE(2025-05-16) ALTTIME(14.27.10)
 GRPNAME(rome) GRPROLE(Recovery) GRPADDR(exampleqm-ibm-mq-nhacrr-<namespace>.apps.<cluster>) GRPVER(9.4.2.0) CONNGRP  (yes)       GRSTATUS(Normal) RCOVLSN(<0:0:87:58322>) RCOVTIME(2025-05-16T14:27:09.051799Z) BACKLOG(0) INSYNC(yes)   SYNCTIME      (2025-05-16T14:28:38.084565Z) ALTDATE(2025-05-16) ALTTIME(14.28.31)
      该状态的关键部分如下：
      • Role(Active)
      • QUORUM(3/3)实时组已达到法定人数
      • GRSTATUS(Normal)
    4. 在罗马站点上运行相关命令再次检查恢复组的状态，其中 <LEADER_POD> 是 pod READY 1/1 的名称。
      • 在 Red Hat OpenShift 上：
        oc exec -t <LEADER_POD> -- dspmq -o nativeha -g
      • 在 Amazon EKS 上：
        kubectl exec -t <LEADER_POD> -- dspmq -o nativeha -g

      您应该会看到以下输出：

      QMNAME(EXAMPLEQM)                                         ROLE(Leader) INSTANCE(exampleqm-ibm-mq-0) INSYNC(yes)   QUORUM(3/3)       GRPLSN(<0:0:87:58322>) GRPNAME(rome) GRPROLE(Recovery)
 GRPNAME(rome) GRPROLE(Recovery) GRPADDR(exampleqm-ibm-mq-nhacrr-<namespace>.apps.<cluster>) GRPVER(9.4.3.0)   GRSTATUS      (Normal) RCOVLSN(<0:0:87:58322>) RCOVTIME(2025-05-16T14:27:09.051799Z) BACKLOG(0) INSYNC(yes)   SYNCTIME(2025-05-16T14:30:40.      134627Z) ALTDATE(2025-05-16) ALTTIME(14.27.17)
 GRPNAME(london) GRPROLE(Live) GRPADDR(Unknown) GRPVER(9.4.3.0) CONNGRP(yes) GRSTATUS(Normal) RCOVLSN  (<0:0:87:58322>)       RCOVTIME(2025-05-16T14:27:09.051799Z) INITLSN(<0:0:9:4696>) INITTIME(2025-05-12T16:58:13.  582274Z) LIVETIME      (2025-05-12T16:58:16.319844Z) ALTDATE(2025-05-16) ALTTIME(14.30.41)
      请注意， QUORUM(3/3) 和 GRSTATUS(Normal) 字段已更新。
  10. 测试与队列管理器的连接。
    要确认队列管理器已配置且可用，请根据您所在平台的相应链接执行以下步骤：
  11. 仅限 Amazon EKS 部署 ：配置 以允许恢复组与运行 LoadBalancer 组通信。
    1. 请确保您处于伦敦命名空间中，然后创建 LoadBalancerService 以便通过以下配置从集群外部建立 TLS 连接至队列管理器。
      apiVersion: v1
kind: Service
metadata:
  name: crr-london
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
spec:
  type: LoadBalancer
  ports:
    - port: 9415
      targetPort: 9415
      name: nha-crr
  selector:
    app.kubernetes.io/name: ibm-mq
    app.kubernetes.io/instance: exampleqm
      重要提示： 若您使用的是 IPv6 单堆栈系统，请对以下 metadata.annotations 部分进行相应修改：
      • 将 的值 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type 从 "instance" 更改为 "ip"
      • 添加以下行：
        service.beta.kubernetes.io/aws-load-balancer-ip-address-type: "dualstack"
    2. 验证类型为 的 Service 是否已 LoadBalancer 创建：
      kubectl get service <LOAD_BALANCER_NAME>
    3. 请确认您的 LoadBalancer 已准备就绪。
      Amazon 负载均衡控制器需要几分钟时间来配置并注册其目标。 运行以下命令以显示. LoadBalancer的状态。 当 准备就绪 LoadBalancer 时，状态为 active：
      aws elbv2 describe-load-balancers --query 'LoadBalancers[*].[LoadBalancerName,State.Code]' --output text
  12. 将远程地址添加到本机高可用性恢复组。
    当罗马成为活动组时，它需要知道伦敦的远程地址，以便能够连接到伦敦作为恢复组。 要添加此内容，请更新罗马站点的配置文件 spec.queueManager.availability.nativeHAGroups ，在本地配置段落下方添加以下内容：
    打开 Red Hat OpenShift
              remotes:
            - name: "london"
              addresses:
              - "<london group hostname>:443"
    将地址替换为伦敦站点 exampleqm-ibm-mq-nhacrr 路由的主机属性。 请确保您位于伦敦站点，然后使用以下命令获取nhacrr路由的主机名：
    oc get route exampleqm-ibm-mq-nhacrr --template="{{.spec.host}}"
    更新完成后，请等待 pod 重启并运行，且其中一个 pod 处于 pod READY 1/1 状态。
    打开 Amazon EKS
              remotes:
            - name: "london"
              addresses:
              - "<london group hostname>:9415"
    将地址替换为伦敦站点上 LoadBalancer 的主机属性。 请确保您位于伦敦站点，然后使用以下命令获取 LoadBalancer nhacrr主机名：
    kubectl get service <LOAD_BALANCER_NAME> -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}"
    更新完成后，请等待 pod 重启并运行，且其中一个 pod 处于 pod READY 1/1 状态。
  13. 将罗马站点的域名添加到 文件 ccdt.json 中。
    切换后，罗马成为实时站点，客户需要连接到罗马的群组。 通过将罗马的主机名添加到 文件 ccdt.json 中，即可启用此行为。
    打开 Red Hat OpenShift
    1. 获取罗马站点 qm 的主机名。 请确保您位于罗马站点，然后使用以下命令获取路由 qm 的主机名：
      oc get route exampleqm-ibm-mq-qm --template="{{.spec.host}}"
      注： 存在两条路由，此处请使用消息传输路由。 将路由 qm 的主机地址添加到文件 ccdt.json 中。
    2. 在 ccdt.json 文件中，在连接列表中添加第二个主机名和端口对，这样连接列表就会变成这样：
      "connection":
                [
                    {
                        "host": "<hostname from London qm route>",
                        "port": 443
                    },
                    {
                        "host": "<hostname from Rome qm route>",
                        "port": 443
                    }
                ],
    打开 Amazon EKS
    1. 获取罗马站点 qm 的主机名。 请确保您当前位于罗马站点，然后使用以下命令获取主机名 qmLoadBalancer ：
      kubectl get service <LOAD_BALANCER_NAME> -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}"
    2. 在 ccdt.json 文件中，在连接列表中添加第二个主机名和端口对，这样连接列表就会变成这样：
      "connection":
                [
                    {
                        "host": "<hostname from London qm LoadBalancer>",
                        "port": 1414
                    },
                    {
                        "host": "<hostname from Rome qm LoadBalancer>",
                        "port": 1414
                    }
                ],
  14. 向队列中添加一些持续信息。 ConfigMap 中指定的 mqsc 文件中定义的队列具有 DEFPSIST(YES) 属性，因此放入队列的所有报文都将是持久的，并复制到恢复组。 使用以下命令将信息放入队列：
    /opt/mqm/samp/bin/amqsputc EXAMPLE.QUEUE EXAMPLEQM
    如果与队列管理器的连接成功，则输出以下响应：
    target queue is EXAMPLE.QUEUE

    输入一些文字，然后每次都按回车键 ，即可将多条信息放入队列。 按两次回车键完成。

  15. 执行从伦敦的实时组到罗马的恢复组的托管切换，以证明本地 HA - CRR 设置是正确的。 请按照《 在原生高可用性CRR配置中完成计划切换 》中的说明进行操作。 在更新 "实时 "组和 "恢复 "组的角色时，您可能会发现在 YAML 中更新 metadata.labels.role 以反映您的更改非常有用，但这对于切换来说并非必要。 完成切换后，您可以在罗马检索新实时群组中的信息。

    有关故障转移和切换的更多信息，请参阅 《原生高可用性CRR切换与故障转移》。

  16. 运行以下命令，检索切换前发送的信息：
    /opt/mqm/samp/bin/amqsgetc EXAMPLE.QUEUE EXAMPLEQM

    你在步骤14 中添加的消息已准备就绪，并将被输出。 几秒钟后，命令退出。

后续操作

维护完成后，您可以通过重复步骤15 中的操作切换回原始实时组。

您还可以尝试执行非计划故障转移，具体操作请参阅 《在原生高可用性CRR配置中完成非计划故障转移》中的说明。

要了解如何使用不同证书来保护CRR配置的不同部分，请参阅示例：在原生高可用性CRR中使用多个 TLS 证书。