本文档适用于负责保持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 最低，具有持续可用性。 | 复杂性和费用最高，需要稳健的网络和数据同步。 |
后续步骤
- 了解如何在 主要环境和次要环境中实现监控和提醒 ，以了解集群健康状况、复制状态、备份成功情况和应用 性能。
- 了解如何在上安装 OpenShift Google Cloud。
- 详细了解上的 Red Hat 解决方案 Google Cloud