缺省和定制企业套餐
本部分描述了 IBM MQ on Cloud 服务提供的高可用性 (HA)，如何创建队列管理器 HA 解决方案体系结构以及灾难恢复的详细信息。 此处的信息是“缺省”和“定制企业”套餐的具体信息。
高可用性
在内部，IBM MQ on Cloud 使用一系列组件进行部署，这些组件作为容器构建并部署到在所选特定地理区域中运行的 Kubernetes 集群中。 部署的每个付费队列管理器都位于其自己的隔离容器中，并且已分配专用的 CPU、RAM 和磁盘以供其使用。
Kubernetes 集群包含多个工作程序节点（例如，虚拟机），部署的容器分布在这些节点上，并且每个容器都定义了运行状况检查和活性检查，这样在发生特定类型的故障时，Kubernetes 将自动使容器从一个工作程序移动到另一个工作程序。
目前 MQ on Cloud 基础架构是部署到每个区域内的单个数据中心（也称为“单个可用性专区”），因此 Kubernetes 集群中的每个工作程序都位于单个数据中心内。
队列管理器的持久性状态（例如，定义的队列、这些队列中包含的持久消息以及队列管理器通道的通道序列状态）存储在容器映像外部的持久卷上，因此当队列管理器容器在不同的工作程序节点上重新启动时，其持久性状态与在原始工作程序节点上运行时的持久性状态完全相同。
上述方法构成了 IBM MQ on Cloud 中高可用性的基础，并确保即使在集群中个别工作程序发生故障的情况下，队列管理器也能够继续运行。
HA 队列管理器配置所需的解决方案体系结构
上述 MQ on Cloud 体系结构通过确保在底层基础架构的某些部分可能发生故障时单个队列管理器仍能够继续运行，为队列管理器提供了极好的可用性，但是单个队列管理器仍然是单点故障，因为在某些情况下（例如，队列管理器故障转移到新的工作程序以避免中断时，重新启动队列管理器以应用安全修订或功能更新时，或者存在区域范围的故障时），它会短时间处于脱机状态。
以下项目符号描述了如何使用 IBM MQ on Cloud 来部署高可用性解决方案体系结构，该体系结构提供不间断的服务可用性，即使在个别队列管理器处于脱机状态一段时间时也是如此。 此解决方案体系结构还为 IBM MQ on Cloud 定义了 “HA 标识的配置”，如 IBM Cloud 服务描述 的 3.2 部分中所引用的，由 IBM Cloud 合同服务级别协议 (SLA) 针对高可用性配置所规定。
- 用户必须在不同的部署位置中部署两个或更多队列管理器，以确保在发生区域范围的中断时，继续保持可用性（例如，队列管理器分别部署在伦敦和法兰克福区域，或 IBM Cloud 达拉斯和 AWS 美国东部 1，而不是两个队列管理器都部署在 IBM Cloud 达拉斯中）
- 每个队列管理器都必须配置有相同的连接和对象集（例如，队列/主题/通道），以便应用程序可以同等连接到任一队列管理器来执行其工作
- 应用程序应该配置为可以连接到任何可用的队列管理器
- 生产者应用程序应该配置为能够连接到任一队列管理器（例如，主动/主动工作负载均衡，或者如果第一个队列管理器不可用，以主动/被动方式回退到第二个队列管理器）
- 使用者应用程序的多个实例应该在可用队列管理器之间进行部署和分布，避免在队列/主题的可用实例上留有未使用的消息
- 应用程序应该配置有自动重新连接，以确保在发生故障时，应用程序会自动重新建立与队列管理器的连接
用于实现 HA 解决方案体系结构的 IBM MQ 方法
IBM MQ 产品包含客户机端和服务器（队列管理器）端的各种功能，支持配置上述高可用性解决方案体系结构；
- ConnectionNameList 是队列管理器端点的逗号分隔列表，格式为“host1(port1),host2(port2)”，在应用程序创建连接时将按顺序尝试连接这些端点，因此非常适合主动/被动样式的场景，在这种场景中，如果 host1 可用，那么应用程序应该会首选连接到 host1
- CCDT（客户机通道定义表）是一种文件格式，用于定义一组可用的队列管理器，并允许用户定义多组等效队列管理器，以及用于在这些队列管理器之间分布连接请求的策略。 缺省情况下，CCDT 会随机选择连接来连接到组中的队列管理器集（这对于主动/主动场景非常理想），但是也可以配置为定义首选项（例如，主动/被动场景）
- 使用 IBM MQ REST 消息传递 API 的应用程序对于每个队列管理器，会连接到一个不同的 REST URL 端点，并且可以使用自己的编程环境的功能来选择要使用的端点，以及如何在其中一个端点不可用时处理故障转移
冷灾难恢复
以上各部分描述了 IBM MQ on Cloud 如何提供高可用性来处理针对正在运行队列管理器的个别工作程序可能发生的中断或故障，但是存在更极端的故障场景，在此场景中，灾难性故障会导致所有现有基础结构和数据不可用或损坏。 我们将发生此类型故障后对服务进行复原的过程称为“冷灾难恢复”，简称为“冷 DR”。
例如，如果针对给定区域部署的 MQ on Cloud 基础架构所在的整个数据中心处于脱机状态，比如由于发生重大自然灾害，那么会发生冷 DR 场景。 在这种情况下，存储队列管理器运行时状态的持久卷不再可用（因为它存储在单个数据中心内），因此无法将队列管理器复原到发生灾难性故障前的准确原始状态。
IBM 职责
要使 IBM 能够在发生此类型灾难性故障后复原服务，每个付费队列管理器的配置须每 24 小时备份一次，并以加密格式保存在主动数据中心外部的存储位置。 配置备份包括队列管理器中存在的队列、主题和通道的管理员定义以及已应用的 TLS 证书，但不包括运行时状态（例如，持久性消息或通道序列状态），因为队列管理器中的运行时状态更改如此频繁，以致于企业通常宁可从干净状态开始，也不愿意复原最长过去 24 小时的数据副本。
由于从此配置备份复原队列管理器会导致丢失运行时状态（例如，持久性消息），这并不是 IBM 能轻松执行的操作，因此 IBM 操作团队将首先与基础架构提供者（例如，IBM 或 Amazon Web Services）合作，以恢复现有基础架构。 仅当确定无法在可接受的时间范围内恢复原始基础架构后，才会激活冷 DR 过程。
决定触发冷 DR 过程后，IBM 会在其他数据中心启动新的基础架构来托管付费队列管理器，并使用每个付费队列管理器的配置备份来重新创建部署在新基础架构中的队列管理器的副本。 最后，将更新应用程序用于访问队列管理器的 DNS 主机名，使其指向新的基础架构部署。
RTO 和 RPO（恢复时间目标和恢复点目标）
- RTO 为 24 小时
- RPO 为 24 小时
| 队列管理器区域 | 处理可用性专区 | 备用可用性专区 | 备份多个可用性专区区域 |
|---|---|---|---|
| us-south | dal12 | dal14 | us-south |
| us-east | wdc04 | wdc06 | us-east |
| eu-de | fra02 | fra05 | eu-de |
| eu-gb | lon04 | lon02 | eu-gb |
| AWS us-east-1 | us-east-1d | us-east-1b | us-east |
| AWS eu-west-1 | eu-west-1c | eu-west-1b | eu-west |
客户职责
由于队列管理器的冷复原不会保留运行时状态（例如，通道序列状态），因此您可能需要执行某种管理操作，以将复原的队列管理器与其他基础架构重新集成，例如通过重置通道序号，以便通道成功通信。 为了帮助执行此最终恢复步骤，建议您在部署队列管理器时配置灾难恢复通知处理程序（如此处所述），以便能在灾难恢复过程完成时收到来自 IBM 操作团队的通知。