[OpenShift Container Platform][Kubernetes][亚马逊EKS]

规划容器中 IBM MQ 的高可用性

对于 IBM® MQ Operator，有三种高可用性选项: 本机 HA 队列管理器 (具有一个活动副本和两个备用副本) ， 多实例队列管理器 (这是使用共享的网络文件系统的主动/备用对) 或 单个弹性队列管理器 (通过网络存储器为 HA 提供简单方法)。 后两者依赖于文件系统来确保可恢复数据的可用性，但是本机 HA 不会。 因此，当不使用本机 HA 时，文件系统的可用性对于队列管理器可用性至关重要。 在数据恢复很重要的情况下，文件系统应确保通过复制实现冗余。

您应该单独考虑 消息 和 服务 可用性。 使用 IBM MQ for Multiplatforms时，消息仅存储在一个队列管理器上。 因此，如果该队列管理器变得不可用，那么您将暂时失去对其保存的消息的访问权。 要实现高 消息 可用性，您需要能够尽快恢复队列管理器。 您可以通过具有多个队列实例供客户机应用程序使用 (例如，通过使用 IBM MQ 统一集群) 来实现 服务 可用性。

队列管理器可以分为两部分: 存储在磁盘上的数据以及允许访问数据的正在运行的进程。 任何队列管理器均可迁移至不同 Kubernetes 节点，前提是其保持相同数据（由 Kubernetes 持久卷提供）且客户端应用程序仍可通过网络访问该队列。 在 Kubernetes中，服务用于提供一致的网络身份。

IBM MQ 依赖于持久卷上数据的可用性。 因此，提供持久卷的存储器的可用性对于队列管理器可用性至关重要，因为 IBM MQ 的可用性不能超过它所使用的存储器。 如果要容许整个可用性区域的中断，那么需要使用将磁盘写入复制到另一个区域的卷提供程序。

[IBM MQ Advanced]

本机 HA 队列管理器

本机 HA 队列管理器涉及一个 活动 和两个 副本 Kubernetes Pod ，它们作为 Kubernetes StatefulSet 的一部分运行，每个副本正好有三个副本具有自己的 Kubernetes 持久卷集。 使用本机 HA 队列管理器 (基于租赁的锁定除外) 时，共享文件系统的 IBM MQ 需求也适用，但您不需要使用共享文件系统。 您可以使用块存储器，顶部有合适的文件系统。 例如， xfs 或 ext4。 本机 HA 队列管理器的恢复时间由以下因素控制:
  1. 副本实例检测活动实例是否失败所花费的时间。 这是可配置的。
  2. Kubernetes Pod 就绪性探测器检测就绪容器是否已更改并重定向网络流量所需的时间。 这是可配置的。
  3. IBM MQ 客户机重新连接所需的时间。

有关更多信息，请参阅本机高可用性。

[IBM MQ Advanced][ MQ 9.4.2 2025年2月]

本地HA CRR（跨区域复制）

您可以实施灾难恢复解决方案，该方案由位于不同区域的两个本地高可用性（Native HA）组组成。 一个本地HA组负责实时操作 ，另一个负责恢复操作。 当实时群组所在区域发生计划内或计划外中断时，用户操作可将远程区域群组的作用从恢复切换到实时。 然后，该组接管原始队列管理器实例的工作，接受应用程序连接等。

有关更多信息，请参阅原生高可用跨区域复制。

多实例队列管理器

多实例队列管理器涉及一个 活动 和一个 备用 Kubernetes Pod ，它们作为具有正好两个副本和一组 Kubernetes 持久卷的 Kubernetes 有状态集的一部分运行。 队列管理器事务日志和数据保存在使用共享文件系统的两个持久卷上。

多实例队列管理器需要 active 和 standby Pod 都具有对持久卷的并发访问权。 要配置此功能，您需要使用 Kubernetes 持久卷，并将 access mode 设置为 ReadWriteMany 。 这些卷还必须满足 IBM MQ 共享文件系统的需求，因为 IBM MQ 依赖于自动释放文件锁定来启动队列管理器故障转移。 IBM MQ 生成已测试文件系统的列表。

多实例队列管理器的恢复时间由以下因素控制:

  1. 发生故障后，共享文件系统释放活动实例最初获取的锁定所需的时间。
  2. 备用实例获取锁定然后启动所需的时间。
  3. Kubernetes Pod 就绪性探测器检测就绪容器是否已更改并重定向网络流量所需的时间。 这是可配置的。
  4. IBM MQ 客户机重新连接所需的时间。

单个弹性队列管理器

单个弹性队列管理器是在单个 Kubernetes Pod 中运行的队列管理器的单个实例，其中 Kubernetes 监视队列管理器并根据需要替换 Pod。

在使用单个弹性队列管理器 (基于租赁的锁定除外) 时，共享文件系统的 IBM MQ 需求 也适用，但您不需要使用共享文件系统。 您可以使用块存储器，顶部有合适的文件系统。 例如， xfs 或 ext4。

单个弹性队列管理器的恢复时间由以下因素控制:

  1. 活动性探测器运行所需的时间，以及它容忍的失败次数。 这是可配置的。
  2. Kubernetes 调度程序将失败的 Pod 重新调度到新节点所需的时间。
  3. 将容器映像下载到新节点所需的时间。 如果您使用 imagePullPolicy 值为 IfNotPresent ，那么图像可能已经在该节点上可用。
  4. 启动新队列管理器实例所需的时间。
  5. Kubernetes Pod 就绪性探测器检测容器是否就绪所需的时间。 这是可配置的。
  6. IBM MQ 客户机重新连接所需的时间。
重要说明：

虽然单一弹性队列管理器模式提供了一些优势，但您需要了解是否可以通过针对 Node 故障的限制来实现可用性目标。

在 Kubernetes中，发生故障的 Pod 通常会快速恢复; 但整个 Node 的故障会以不同方式进行处理。 在使用 IBM MQ 等有状态工作负载和 Kubernetes StatefulSet, 如果 Kubernetes 主节点与工作节点失去联系，它将无法确定节点是发生故障还是仅仅失去了网络连接。 因此，在此情况下， Kubernetes 将 不执行任何操作 ，直到发生下列其中一个事件为止:
  1. 节点恢复到 Kubernetes 主节点可与其通信的状态。
  2. 将执行管理操作以显式删除 Kubernetes 主节点上的 Pod。 这不一定会阻止 Pod 运行，而只是将其从 Kubernetes 商店中删除。 因此，必须非常谨慎地采取这一行政行动。
注: 通过 IBM MQ Operator创建队列管理器时，不支持更改 IBM MQ 队列管理器的 StatefulSet 详细信息 (包括副本数)。