主动-被动设置的灾难恢复策略

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

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

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

灾难恢复架构

以下架构图展示了在 Google Cloud上部署 OpenShift 的主动-被动方案：

主动-被动部署，请参阅下文。

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

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

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

此架构具有以下配置：

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

使用的产品

使用场景

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

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

设计考虑事项

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

保护应用状态和配置

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

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

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

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

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

块存储（永久性卷）

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

PersistentVolume 对象

在 OpenShift 中，在两个集群中创建链接到这些磁盘的 PersistentVolumes 对象，并确保应用在两个集群中使用相同的 PersistentVolumeClaim (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：使用外部 Secret 运算符等工具从 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 集群中的服务之间的通信。此功能对于灾难恢复方案尤其有用，在故障切换或数据复制期间，服务可能需要跨集群进行通信。

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

部署

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

后续步骤