Google Cloud 上的 OpenShift：主动-被动和主动-非主动设置的灾难恢复策略

本文档介绍了如何为 Google Cloud 上的 OpenShift 部署规划和实现主动-被动和主动-非主动灾难恢复，以帮助您在发生灾难时最大限度地减少停机时间并快速恢复。它提供了有关备份数据、将配置作为代码进行管理以及处理 Secret 的最佳实践，有助于确保您在发生灾难时能够快速恢复应用。

本文档适用于负责保持Google Cloud中部署的 OpenShift Container Platform 上的应用的可用性和弹性的系统管理员、云架构师和应用开发者。

本文档是系列文章中的一篇，重点介绍应用级策略，这些策略可确保您的工作负载在发生故障时保持高可用性并快速恢复。本文假设您已阅读使用 OpenShift 实现灾难恢复的最佳实践。本系列中的文档如下：

• Google Cloud上 OpenShift 的灾难恢复
• 使用 OpenShift 实现高可用性的最佳实践
• Google Cloud上的 OpenShift：主动-被动和主动-非主动设置的灾难恢复策略（本页）

灾难恢复架构

本部分介绍了主动-被动和主动-非主动灾难恢复方案的架构。

使用的产品

• Google Compute Engine
• Google Cloud 全球外部 HTTPS 负载均衡器
• Google Cloud 直通式网络负载均衡器
• Cloud DNS
• 网络端点组
• Cloud Storage
• Cloud SQL
• 永久性磁盘
• Cloud Storage
• Secret Manager
• Cloud Monitoring
• VPC 网络

主动-被动部署

下图展示了在 Google Cloud上部署 OpenShift 的主动-被动方案。

如上图所示，在用于灾难恢复的主动-被动部署中，主区域中的 OpenShift 集群会处理所有生产流量。如果主集群发生故障，不同区域中的辅助集群会随时准备好接管。此设置可确保停机时间最短，因为辅助集群已预先配置并处于暖状态，这意味着它已设置必要的基础架构和应用组件，但在需要之前不会主动处理流量。应用数据会复制到被动集群，以最大限度减少数据丢失，从而符合 RPO。

其中一个区域集群充当主（活跃）站点，并处理所有生产流量。位于不同区域的辅助集群是灾难恢复的备用集群。次要集群会保持在暖状态，一旦主要集群发生故障，次要集群便可立即接管，延迟时间极短。

主动-被动灾难恢复方案中各组件的说明

该架构具有以下配置：

• 主 OpenShift 集群（主动）：位于主Google Cloud 区域，此集群运行生产工作负载，并在正常运行条件下主动处理所有用户流量。
• 辅助 OpenShift 集群（被动）：位于单独的Google Cloud 区域，用于隔离故障，此集群充当温备集群。它已部分设置并正在运行，如果主系统发生故障，它随时可以接管。它具有必要的基础设施、OpenShift 配置和部署在其上的应用组件，但在触发故障切换事件之前，它不会处理实时生产流量。
• Google Cloud 区域：地理位置上彼此隔离，为灾难恢复提供基础。使用单独的区域可确保影响一个区域的大规模事件不会影响备用集群。
• 全球外部 HTTPS 负载均衡器：充当应用流量的单一全球入口点。在正常情况下，它配置为将所有流量路由到主（主动）集群。其健康检查会监控主集群的可用性。
• 数据复制机制：负责将必要应用数据从主集群复制到辅助集群（例如数据库或永久性卷状态）的持续性流程或工具。这种方法可确保数据一致性，并最大限度地减少故障切换期间的数据丢失，从而帮助您实现 RPO。
• 监控和健康检查：持续评估主集群及其应用的健康状况和可用性的系统，例如 Cloud Monitoring、负载均衡器健康检查、内部集群监控。这些系统对于快速检测任何故障至关重要。
• 故障切换机制：一种预定义的过程（手动、半自动或全自动），用于在检测到主集群中发生无法恢复的故障时，将流量从主集群重定向到辅助集群。此过程通常涉及更新全球负载均衡器的后端配置，以将目标设为辅助集群，使其成为新的活跃站点。
• VPC 网络：用于在区域之间创建必要连接以实现数据复制和管理的底层 Google Cloud 网络基础设施。

主动-非主动部署

主动-非主动灾难恢复是指将辅助区域作为备用区域进行维护，该区域仅在发生灾难时激活。与持续复制数据的主动-被动设置不同，此策略依赖于存储在 Cloud Storage 中的定期备份，并在故障切换期间预配基础架构和恢复数据。您可以使用与 OpenShift API for Data Protection (OADP) 集成的 Velero 等工具来执行定期备份。这种方法可最大限度地降低费用，非常适合可以容忍较长恢复时间的应用。它还可以帮助组织实现扩展的恢复时间目标 (RTO) 和恢复点目标 (RPO)。

在主动-非主动灾难恢复方案中，数据会定期备份到备用区域，但不会主动复制。基础架构在故障切换过程中进行预配，数据从最新备份中恢复。您可以使用基于 Velero 开源项目的 OpenShift API for Data Protection (OADP) 来执行定期备份。我们建议您将这些备份存储在启用了版本控制功能的 Cloud Storage 存储桶中。如果发生灾难，您可以使用 OADP 恢复集群的内容。这种方法可最大限度地降低持续成本，但与主动-被动方法相比，会导致 RTO 更长，RPO 也可能更高。此设置适用于恢复时间目标较长的应用。

下图显示了主动-非主动部署和故障切换过程。

故障切换流程如下：

1. 当受监控的服务变得不可用时，系统会触发灾难恢复事件。
2. 流水线会自动在灾难恢复区域中预配基础架构。
3. 系统会预配新的 OpenShift 集群。
4. 通过 OADP 从最新备份中恢复应用数据、Secret和对象。
5. Cloud DNS 记录已更新为指向灾难恢复区域中的区域级负载均衡器。

如上图所示，部署了两个独立的 OpenShift 区域级集群，每个集群位于不同的 Google Cloud 区域，例如 us-central1 和 europe-west1。每个集群都必须在其区域内实现高可用性，并使用多个可用区以实现冗余。

主动-非主动灾难恢复方案中组件的说明

该架构具有以下配置：

• 主要区域（区域 A）：包含可完全运行的 OpenShift 集群，用于处理生产流量。
• 辅助区域（区域 B）：最初包含最少的资源（VPC 和子网）。在故障切换期间，系统会预配基础架构（Compute Engine 实例和 OCP）。
• 备份存储空间：Google Cloud Storage 存储桶用于存储定期备份（应用对象的 OADP 或 Velero，以及 PV 和数据库备份）。我们建议您为相应存储桶使用版本控制和跨区域复制。
• 配置管理：Git 代码库存储基础设施即代码（IaC，例如 Terraform）和 Kubernetes 或 OpenShift 清单（用于 GitOps）。
• 备份工具：在主集群中配置的 OADP (Velero)，用于执行定期备份到 Cloud Storage 的操作。
• 编排：脚本或自动化工具在故障切换期间触发基础架构配置和恢复流程。

使用场景

本部分提供了主动-被动部署和主动-非主动部署的不同应用场景示例。

主动-被动灾难恢复使用情形

建议在以下使用场景中采用主动-被动 DR：

• 需要比冷恢复更低的 RTO（例如几分钟到几小时）的应用，其中数据是从无法立即访问的备份中恢复的。
• 持续数据复制可行且必须最大限度缩短 RPO（例如，从分钟级缩短到秒级）的系统。
• 受监管的行业，停机时间限制非常严格；关键业务应用，维护暖备用集群的成本因停机造成的业务影响而合理。

主动-非主动灾难恢复使用情形

建议在以下使用情形下使用主动-非主动灾难恢复：

• 可以容忍较长 RTO（例如几分钟到几小时）的应用。
• 需要优化成本的环境，以及持续运行备用集群的费用过高的情况。主要持续费用是对象存储费用，而不是运行计算实例的费用。
• 开发工作负载、测试工作负载或不太重要的生产工作负载。
• 归档或批处理系统，恢复时间不太重要。

设计考虑事项

本部分介绍了一些设计因素、最佳实践和设计建议，您在使用此参考架构开发满足特定安全性、可靠性、费用和性能要求的拓扑时应考虑这些内容。

主动-被动设计注意事项

本部分介绍了主动-被动灾难恢复方案的设计注意事项。

保护应用状态和配置

OpenShift Container Platform 提供 OADP，并为在集群中运行的应用提供全面的灾难恢复保护。您可以使用此工具备份容器化应用和虚拟机使用的 Kubernetes 和 OpenShift 对象（例如部署、服务、路由、PVC、ConfigMap、Secret 和 CRD）。不过，OADP 不支持完整集群备份和恢复。如需了解如何配置和安排备份，以及如何执行恢复操作，请参阅 Red Hat 文档。

OADP 为依赖于应用所使用的块存储和 NFS 存储的永久性卷提供备份和恢复流程。您可以使用 Restic 或 Kopia 等工具来截取快照或执行文件级备份，从而对这些进程采取行动。

OADP 可用于备份对象定义、确保配置一致性，并可在需要时恢复特定应用或命名空间，从而补充数据复制功能。

为了在主动-被动配置中进一步缩短 RPO 和 RTO，我们建议您在主区域和辅助区域之间配置数据复制。

数据复制对于确保辅助集群能够无缝接管至关重要。如下一部分中所述，从主集群到辅助集群的数据复制实现取决于应用使用的存储类型。

块存储（永久性卷）

使用 Google 永久性磁盘异步复制功能将数据从主区域复制到次区域。在此方法中，您需要在主要区域中创建一个主磁盘，在次要区域中创建一个辅助磁盘，并在它们之间设置复制。使用一致性组可确保两个磁盘都包含共同时间点的复制数据，然后将这些数据用于灾难恢复。如需了解详情，请参阅配置永久性磁盘异步复制。

PersistentVolume 对象

在 OpenShift 中，在两个集群中创建链接到这些磁盘的 PersistentVolumes 对象，并确保应用在两个集群中使用相同的 Persistent Volume Claims (PVC)。

应用级复制

某些应用（例如数据库和消息队列）具有内置的复制功能，您可以在集群之间配置这些功能。您还可以使用 Pub/Sub 等托管服务来帮助复制特定类型的应用数据或事件。（例如，数据库和消息队列）。

数据库备份

应用可以依赖于不同类型的数据库产品。为帮助您了解数据库备份的设计注意事项，本文档以 PostgreSQL 为示例数据库。

使用集群内数据库运算符进行自托管备份

CloudNative PostgreSQL Operator 等数据库运算符可以帮助您为 PostgreSQL 集群安排备份和灾难恢复。CloudNative PostgreSQL Operator 可与 pg_basebackup 等工具原生集成，并支持流式复制备份。您可以将备份存储在 Google Cloud Storage (Cloud Storage) 等云存储服务中，以确保数据持久性和可恢复性。

您可以在主要区域集群和次要区域集群之间设置流式复制，以确保即使在主要区域发生中断的情况下，数据也能正常使用。这种流式复制通常在区域内是同步的，而在区域之间是异步的。如需了解详细的配置步骤，请参阅 CloudNativePG 文档。

在发生灾难时，您可以将备份恢复到新的 PostgreSQL 集群，从而尽可能缩短停机时间并减少数据丢失。以下是使用 CloudNative PostgreSQL 运算符启用定期备份的配置代码段示例：

        apiVersion: postgresql.cnpg.io/v1
        kind: ScheduledBackup
        metadata:
        name: backup-example
        spec:
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        cluster:
            name: pg-backup

代管式服务

Cloud SQL 等托管式数据库具有内置的备份和复制功能。我们建议您设置从主数据库实例到次要区域中副本的异步复制。如需了解详情，请参阅 Cloud SQL 中的复制简介。在 OpenShift 中，配置 Secret 或 ConfigMap，以指向每个集群的正确数据库连接字符串。

由于异步复制会导致 RPO 不为零，因此可能会丢失最近写入的数据。您必须设计应用来缓解数据丢失问题。或者，考虑使用其他复制方法。

我们还建议您启用 Cloud SQL 自动备份。如需了解详情，请参阅 创建和管理按需备份与自动备份。

故障切换过程

如果主集群发生故障，Cloud DNS 会根据健康检查和故障切换政策自动将流量重定向到次要区域集群。

当次要集群从读取副本提升为主集群时，它会接管作为活跃站点的角色，并处理生产流量。此提升是接受数据库写入操作所必需的。

如需为 Cloud SQL 设置灾难恢复，请按照 Google Cloud SQL 灾难恢复文档中所述的步骤操作。 使用异步数据库或存储复制会导致 RPO 不为零，有助于确保您的应用能够容忍最近写入的数据丢失。或者，考虑使用其他复制方法。

安全Secret管理

数据库密码、API 密钥和 TLS 证书等 Secret 是灾难恢复的重要方面。您必须能够在新的集群中安全可靠地恢复这些 Secret。

常见的 Secret 管理方法如下：

• 使用外部 Secret：使用 external secrets operator 等工具从 Google Secret Manager 中提取 Secret。
• 使用 OADP Operator 备份 Secret：如果您不使用外部存储区，请确保备份中包含 Secret。
• 定期轮替：定期轮替Secret，并确保您的Secret管理策略能够应对灾难恢复场景。
• 测试：在预发布环境中测试Secret恢复，以确认所有服务都可以使用提供的凭证启动。
• 验证：验证 DR 集群是否具有必要的 IAM 角色或身份验证方法，以从外部存储区检索Secret。

网络和流量管理

使用 Google Cloud的全球外部 HTTPS 负载均衡器作为主要入口点，以在多个 OpenShift 集群（例如主集群和辅助集群）之间分配流量。此全球服务会根据邻近性、健康状况和可用性，将用户请求定向到适当的后端集群。

如需将全球负载均衡器连接到 OpenShift 集群，您可以使用以下任一方法：

• 使用区域级负载均衡器（互联网 NEG）：配置Google Cloud 互联网网络端点群组 (NEG)，以指向公开每个 OpenShift 集群的入站服务 (OCP 路由器) 的区域级负载均衡器的外部 IP 地址。然后，全球负载均衡器会将流量路由到这些区域级负载均衡器 IP。这种方法提供了一个抽象层，但涉及跳到其他网络。
• 直接 Pod 路由 (Compute Engine_VM_IP_PORT NEGs)：配置 OpenShift Ingress 控制器集成，以使用 Compute Engine_VM_IP_PORT 类型的 Google Cloud网络端点组 (NEG)。此方法允许全球负载均衡器使用 OpenShift Ingress 控制器（路由器）Pod 的内部 PodIP:TargetPort 直接定位这些 Pod。此方法可绕过额外的跃点和额外的节点代理。这通常会缩短延迟时间，并使全球负载均衡器能够进行更直接的健康检查。

这两种设置都允许全球负载均衡器有效地管理不同区域中集群之间的流量分配。如需了解详情，请参阅设置具有外部后端的全球外部应用负载均衡器。

VPC

我们建议采用以下 VPC 管理方法：

• 共享 VPC：使用共享 VPC 集中管理主集群和辅助集群的网络。 这种方法可简化管理，并确保各区域的网络政策保持一致。
• 全球动态路由：在 VPC 中启用全球动态路由，以在区域之间自动传播路由，确保集群之间的连接顺畅无缝。
• 自定义模式 VPC：使用自定义模式 VPC，并在集群运行的区域中创建特定的子网。对于 Compute Engine_VM_IP_PORT 路由等方法所需的 VPC 原生 Pod 网络，这通常是必需的。
• VPC 网络对等互连：如果您必须为每个区域和集群使用单独的 VPC 网络，请使用 VPC 网络对等互连来连接区域和集群。

子网和 IP 地址

在每个区域中创建区域子网，以保持网络分段并避免 IP 地址冲突。

确保各区域之间的 IP 范围不重叠，以防止出现路由问题。

使用 Red Hat Service Mesh 实现跨集群流量

OpenShift 支持服务网格联邦，从而实现部署在多个 OpenShift 集群中的服务之间的通信。此功能在 DR 方案中特别有用，因为在故障切换或数据复制期间，服务可能需要在集群之间进行通信。

如需了解如何在主集群和辅助集群之间设置 Service Mesh 联邦，请参阅 Red Hat 文档。

主动-非主动设计注意事项

本部分介绍了主动-非主动灾难恢复解决方案的设计注意事项。

以代码形式管理应用配置 (GitOps)

我们建议您采用 GitOps 方法，将所有集群和应用配置存储在 Git 代码库中。此方法可实现快速恢复，因为在灾难恢复 (DR) 方案中，它可实现同步到已知在另一集群中可靠运行的状态。备份可确保您拥有运行时状态的快照，但您还需要一种可靠的方法，以便在灾难发生后快速重新部署应用逻辑、清单和基础架构定义。

使用 OpenShift GitOps Operator

OpenShift GitOps Operator基于 Argo CD，提供了一种受 Red Hat 支持的方式，可在 OpenShift 环境中直接实现 GitOps 模式。它可自动执行以下流程：持续将集群状态与所选配置进行协调，并将协调结果存储在 Git 代码库中。

OpenShift GitOps Operator的控制器会持续确保集群的状态与此代码库中定义的配置相匹配。如果资源发生漂移或丢失，系统会自动协调这些资源。如需了解详情，请参阅关于 Red Hat OpenShift GitOps。

灾难恢复方案执行

如果发生灾难，请执行以下操作：

• 在其他区域中设置新的 OpenShift 集群。
• 安装 OpenShift GitOps Operator。
• 应用引用您的 Git 代码库的同一应用清单。

该运算符会同步集群状态以与代码库保持一致，从而快速重新部署代码中定义的部署、服务、路由、运算符和任何其他资源。

为避免在灾难恢复期间出现任何问题，我们建议您执行以下操作：

• 在 Git 代码库中维护严格的分支和标记策略，以便您可以识别适合灾难恢复的稳定配置。
• 检查 DR 集群是否具有网络连接和访问 Git 代码库的相应权限。
• 将所有资源类型都作为代码纳入，以避免在故障切换期间进行人工干预（例如，基础架构组件、应用工作负载和配置）。

防火墙规则

定义统一的防火墙政策，并将其一致地应用于两个集群，以控制流量并增强安全性。

遵循最小权限原则，这意味着您应将入站和出站流量限制为仅允许应用功能所需的流量。

部署

如需了解如何部署基于此参考架构的拓扑，请参阅 Red Hat 文档。

后续步骤

• 了解如何实现监控和提醒：在主环境和辅助环境中，监控集群健康状况、复制状态、备份成功情况和应用性能。
• 了解如何在 Google Cloud上安装 OpenShift
• 详细了解 Google Cloud上的 Red Hat 解决方案