OpenShift on Google Cloud 的灾难恢复

灾难恢复 (DR) 对于保持在Google Cloud的 OpenShift Container Platform 上部署的应用的连续性至关重要。本文档简要介绍了使用 OpenShift on Google Cloud进行灾难恢复的架构选项，可帮助您的组织在发生灾难时最大限度地减少停机时间并快速恢复。

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

本文档是系列文章中的一篇，重点介绍应用级策略，这些策略可确保您的工作负载在发生故障时保持高可用性并快速恢复。本系列中的文档如下：

灾难恢复规划

规划灾难恢复是在云端运行生产工作负载的关键组成部分。虽然 OpenShift 和 Google Cloud 提供稳健的基础设施级冗余，但您还必须设计和配置应用，以便从灾难性故障中快速恢复。

有效的灾难恢复规划需要采用分层方法。首先，您需要为应用和系统定义明确的恢复时间目标 (RTO) 和恢复点目标 (RPO)，以便快速重新部署。

最后，密钥和凭证还必须可恢复且安全地进行管理。综合考虑所有这些因素，您可以实现灾难恢复态势，以便在不同区域中快速创建新的 OpenShift 集群，或故障切换到处于非主动状态的次要集群。在发生故障之前，此次要集群会一直处于离线状态；发生故障时，它会上线，以尽可能缩短停机时间的方式接管操作。

灾难恢复架构

您可以使用不同的部署架构选项通过 OpenShift on Google Cloud进行灾难恢复。每个选项对费用、复杂性和可用性的影响各不相同。下表概述了这些架构：

架构 说明 用例 优势 缺点
主动/被动 一个集群处于主动状态，负责处理所有流量；另一个集群处于被动状态，随时可以接管。数据会复制到被动集群。 适用于对 RTO 和 RPO 要求适中的应用。 实现更简单，备用集群的费用更低。 由于故障切换时间较长，RTO 较高，可能会出现数据同步延迟。
主动-非主动 与主动-被动类似，但在发生灾难恢复事件之前，不会使用非主动集群。数据会定期备份。 非常适合对成本敏感且允许较高 RTO 和 RPO 的环境。 在非主动时运营成本较低，适合辅助系统当前未运行的灾难恢复 (DR)（冷 DR）。 由于激活和同步时间，RTO 较高，但数据可能会过时。
主动/主动 两个集群均处于主动状态，通过负载均衡处理流量，并在区域之间复制数据。 需要尽可能减少停机时间并实现高可用性的关键应用。 RTO 和 RPO 最低，具有持续可用性。 复杂性和成本最高，需要强大的网络和数据同步功能。

后续步骤