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

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

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

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

灾难恢复架构

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

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

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

故障切换过程

故障切换流程如下：

  1. 当受监控的服务变得不可用时，系统会触发 DR 事件。
  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 的操作。
  • 编排：脚本或自动化工具在故障切换期间触发基础架构配置和恢复流程。

使用的产品

使用场景

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

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

设计考虑事项

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

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

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

使用 OpenShift GitOps Operator

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

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

DR 方案执行

在发生灾难时，请执行以下操作：

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

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

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

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

防火墙规则

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

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

部署

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

后续步骤