灾难恢复规划指南

Last reviewed 2023-11-22 UTC

本文档是介绍 Google Cloud 中的灾难恢复 (DR) 的系列文章中的第一篇，概述了 DR 规划流程：设计和实施 DR 计划需要了解的内容。后续文章讨论了 Google Cloud 上的具体 DR 使用场景以及示例实现。

该系列包含以下部分：

简介

服务中断事件可能随时发生。您的网络可能会中断，您的最新应用推送可能会引发严重错误，或者您可能需要应对自然灾害。出意外时，拥有一个有针对性且经过良好测试的强大 DR 计划非常重要。

借助精心设计且经过良好测试的 DR 计划，您可以确保灾难来袭时您的业务盈利受到的影响最小。无论您的 DR 需求是怎样的，Google Cloud 均可提供强大灵活且经济实惠的产品和功能，供您构建或扩展适合自己的解决方案。

DR 规划的基础知识

DR 是业务连续性规划的一部分。 DR 规划的起点是业务影响分析，该分析定义了两个关键指标：

  • 恢复时间目标 (RTO)，即可以接受的最长应用宕机时间。此数值通常作为服务等级协议 (SLA) 的一部分进行定义。
  • 恢复点目标 (RPO)，即可能由于重大事件而丢失应用中数据的最长可接受时长。此指标因数据的使用方式而异。例如，经常修改的用户数据的 RPO 可能仅为几分钟。相比之下，不太关键、不经常修改的数据的 RPO 可能为几个小时。（此指标仅描述时长；它不会涉及已丢失数据的数量或质量。）

通常，RTO 和 RPO 值越低（应用必须越快地从中断中恢复），应用运行费用越高。下图显示了费用与 RTO/RPO 的比率。

显示低 RTO/RPO 与高费用之间对应关系的图表。

由于较低的 RTO 和 RPO 值通常意味着较高的复杂性，因此相关的管理开销遵循类似的曲线。高可用性应用可能需要您管理两个物理上分离的数据中心之间的分配、管理复制等。

RTO 和 RPO 值通常汇总到另一个指标：服务等级目标 (SLO)，它是 SLA 的关键可测量元素。SLA 和 SLO 经常被混淆。SLA 是指定要提供的服务、支持方式、时间、地点、费用、性能、处罚和相关各方的责任的整个协议。SLO 是 SLA 的特定可测量特征，例如可用性、吞吐量、频率、响应时间或质量。SLA 可以包含许多 SLO。RTO 和 RPO 是可测量的，应被视为 SLO。

您可以在《Google 站点可靠性工程》一书中详细了解 SLO 和 SLA。

您可能还在规划可实现高可用性 (HA) 的架构。 HA 与 DR 并不完全重叠，但在考虑 RTO 和 RPO 值时，通常需要考虑 HA。HA 有助于确保实现约定的运行表现等级，而这通常是维持高于一般水平的正常运行时间。当您在 Google Cloud 上运行生产工作负载时，可以使用全球分布式系统，确保在某个地区出现问题时，应用可以继续提供服务（即使可用范围变小）。实质上，该应用会激活其 DR 计划。

为什么选择 Google Cloud？

与在本地满足 RTO 和 RPO 要求相比，Google Cloud 可以大大减少与 RTO 和 RPO 相关的费用。例如，传统的 DR 规划需要您考虑许多要求，包括下列各项：

  • 容量：获取充足资源以按需扩缩。
  • 安全性：提供物理安全性以保护资产。
  • 网络基础架构：包括防火墙和负载平衡器等软件组件。
  • 支持：提供熟练的技术人员，以进行维护并解决问题。
  • 带宽：为峰值负载规划合适带宽。
  • 设施：确保包括设备和电力在内的物理基础设施。

通过在世界级生产平台上提供代管程度极高的解决方案，Google Cloud 可帮助您避开大部分或所有这些复杂因素，从而消除流程中的许多业务费用。此外，Google Cloud 重视管理简单性，这可减少管理复杂应用的费用。

Google Cloud 提供与 DR 规划相关的若干功能，包括下列各项：

  • 全球网络。Google 拥有全球最大、最先进的计算机网络之一。Google 骨干网采用先进的软件定义网络技术，且提供边缘缓存服务，可实现快速、一致和可伸缩的性能。
  • 冗余。全球的多个入网点 (PoP) 可提供强大的冗余能力。您的数据会自动镜像到多个位置的存储设备。
  • 可伸缩性。Google Cloud 像其他 Google 产品（例如搜索和 Gmail）一样具备可伸缩性，即使您遇到巨大的流量高峰，也能应对自如。App Engine、Compute Engine 自动扩缩器和 Datastore 等代管式服务可为您提供自动扩缩功能，使您的应用可以根据需要进行扩缩。
  • 安全。我们在 Gmail 和 Google Workspace 等 Google 应用中保护客户安全，拥有超过 15 年的丰富经验，Google 安全模型正是基于这些经验构建而成。此外，Google 的网站可靠性工程团队可帮助确保高可用性并防止平台资源的滥用。
  • 合规性。Google 会定期接受独立的第三方审核，以验证 Google Cloud 是否符合安全性、隐私和合规性规定以及最佳做法。Google Cloud 符合 ISO 27001、SOC 2/3 和 PCI DSS 3.0 等认证标准。

DR 模式

DR 模式被认为具有冷、暖或热三种。这些模式表明出现问题时系统恢复的容易程度。做一个类比，如果您在驾驶时爆胎了，您可能会怎么做？

3 张汽车爆胎情景的照片：没有备用轮胎；一个备用轮胎和若干工具；一个跑气保用轮胎。

处理爆胎的方式取决于您的准备情况：

  • 冷：您没有备用轮胎，所以必须打电话叫人带新轮胎进行更换。您的旅程会停止，直到援助人员到来进行维修。
  • 暖：您有备用轮胎和换胎工具，可以立即更换车胎并继续前进。但是，您必须停车进行维修。
  • 热：您有跑气保用轮胎。您可能需要稍微放慢速度，但这不会对旅程产生直接影响。您的轮胎可确保继续行驶一段时间，只是您最终必须解决这个问题。

创建详细的 DR 计划

本部分包含有关如何创建 DR 计划的建议。

根据您的恢复目标进行设计

在设计 DR 计划时，您需要结合应用和数据恢复技术，放眼全局。典型的方法是关注 RTO 和 RPO 值，以及可以采用哪种 DR 模式来满足这些值。例如，在历史合规性导向数据的情况下，您可能不需要快速访问数据，因此适合采用较大的 RTO 值和冷 DR 模式。但是，如果您的在线服务出现中断，您将希望能够尽快恢复数据和面向客户的应用部分。在此情况下，热模式会更合适。电子邮件通知系统通常不是业务关键型的，可能适合采用暖模式。

如需了解使用 Google Cloud 处理常见 DR 方案的指导，请查看应用恢复方案。这些方案为各种使用场景提供了针对性的 DR 策略，并分别提供了 Google Cloud 上的示例实现。

设计端到端恢复

仅仅制定数据备份或归档计划是不够的。请确保您的 DR 计划能处理从备份到恢复再到清理的完整恢复过程。我们在有关 DR 数据和恢复的相关文档中对此进行了讨论。

让任务具体化

在运行 DR 计划时，您不希望停下来猜测每个步骤的含义。确保 DR 计划中的每项任务都包含一个或多个具体且明确的命令或操作。例如，“运行恢复脚本”过于笼统。相比之下，“打开 Bash 并运行 /home/example/restore.sh”就比较精确而具体。

实施控制措施

添加控件以防止灾难发生并在问题发生之前检测问题。例如，添加监视器，此监视器在数据破坏性流（如删除流水线）出现意外峰值或其他异常活动时发送警报。如果达到某个删除阈值，此监视器还可以终止流水线进程，从而防止出现灾难性的情况。

准备软件

DR 计划的目标之一是确保您所依赖的软件已准备好应对恢复事件。

验证您是否可以安装软件

确保可以从源或预配置的映像安装应用软件。确保您具有将在 Google Cloud 上部署的任何软件的相应许可 - 请咨询软件供应商以获取指导。

确保所需的 Compute Engine 资源在恢复环境中可用。这可能需要预分配实例或预留这些实例。

设计持续部署以进行恢复

在部署应用时，您的持续部署 (CD) 工具集是必备组件。在恢复计划中，您必须考虑将在已恢复的环境中部署软件工件的位置。计划您要托管 CD 环境和软件工件的位置，它们需要在发生灾难时可用并且可操作。

实施安全性和合规性控制

设计 DR 计划时，安全性至关重要。必须在已恢复的环境中应用与生产环境中相同的控件。合规性规定也适用于已恢复的环境。

为 DR 和生产环境配置相同的安全性

确保您的网络控件可提供与源生产环境相同的分隔和阻止功能。了解如何配置共享 VPC 和防火墙，以便您可以建立部署的集中式网络和安全控制、配置子网、控制入站和出站流量等。了解如何使用服务账号为访问 Google Cloud API 的应用实施最小权限。确保在防火墙规则中使用服务账号。

请确保您向用户授予与源生产环境访问权限相同的 DR 环境访问权限。以下列表概述了在环境之间同步权限的方法：

  • 如果您的生产环境是 Google Cloud，则在 DR 环境中复制 IAM 政策非常简单。您可以使用 Terraform 等基础架构即代码 (IaC) 工具来将 IAM 政策部署到生产环境。然后，在创建 DR 环境的过程中，您可以使用同一工具将政策绑定到 DR 环境中的相应资源。

  • 如果您的生产环境是本地，则将职能角色（例如网络管理员和审核员角色）映射到具有相应 IAM 角色的 IAM 政策。例如，IAM 文档提供了一些示例职能角色配置，请参阅有关创建网络和审核日志职能角色的文档。

  • 您必须配置 IAM 政策以向产品授予相应权限。例如，您可能需要限制对特定 Cloud Storage 存储分区的访问。

  • 如果您的生产环境是其他云提供商，请将该提供商的 IAM 中的权限映射到 Google Cloud IAM 政策。

验证 DR 安全性

为 DR 环境配置权限后，请确保测试所有内容。创建测试环境。使用 Terraform 等 IaC 工具将 Google Cloud 政策部署到测试环境。验证您授予用户的权限与在本地授予用户的权限相匹配。

确保用户可以访问 DR 环境

请在灾难发生之前检查用户是否可以访问 DR 环境。确保您已向用户、开发者、操作员、数据科学家、安全管理员、网络管理员以及组织中的任何其他角色授予相应的访问权限。如果您使用的是其他身份系统，请确保已将账号与您的 Cloud Identity 账号同步。由于 DR 环境将暂时成为您的生产环境，因此请让需要访问 DR 环境的用户登录，并解决所有身份验证问题。将要登录 DR 环境的用户纳入您实施的常规 DR 测试。

如需集中管理对已启动的虚拟机 (VM) 具有 SSH 访问权限的用户，请在构成 DR 环境的 Google Cloud 项目上启用操作系统登录功能。

培训用户

用户需要了解如何在 Google Cloud 中执行他们习惯在生产环境中完成的操作，例如登录、访问虚拟机等。使用测试环境，培训用户如何以可确保系统安全性的方式执行这些任务。

确保 DR 环境符合合规性要求

验证对 DR 环境的访问是否仅限于需要访问的用户。确保遮盖和加密 PII 数据。如果您对生产环境执行常规渗透测试，则应在该范围中包含 DR 环境，并通过创建 DR 环境进行常规测试。

确保在 DR 环境使用时，您收集的所有日志都会回填到生产环境的日志归档中。 同样，确保在 DR 环境中，您可以将通过 Cloud Logging 收集的审核日志导出到主日志接收器归档中。使用导出接收器设施。 对于应用日志，请创建本地日志记录和监控环境的镜像。如果您的生产环境是其他云提供商，请将该提供商的日志记录和监控映射到等效的 Google Cloud 服务。制定流程以设置用于生产环境的输入格式。

在日常备份过程中，使用 Cloud Storage

使用 Cloud Storage 来存储备份。确保包含备份的存储分区具有应用于它们的相应权限。

妥善管理密钥

通过使用 Google Cloud 托管密钥管理服务 (KMS) 来管理应用级密钥。您可以将 Cloud KMS 或第三方解决方案（如 HashiCorp Vault）与Google Cloud 后端（如 Spanner 或 Cloud Storage）搭配使用。

将恢复的数据视为生产数据

确保应用于生产数据的安全控件也适用于恢复的数据：相同的权限、加密和审核要求都应适用。

了解备份的位置以及有权恢复数据的人员。确保恢复过程可审核 - 在灾难恢复后，确保您可以显示有权访问备份数据和执行了恢复操作的人员。

确保灾难恢复计划正常运行

确保发生灾难时，您的 DR 计划会按预期发挥作用。

维护多个数据恢复路径

如果发生灾难，您与 Google Cloud 的连接方法可能会变得不可用。实施访问 Google Cloud 的替代方法，以帮助确保您可以将数据传输到 Google Cloud。定期测试备份路径是否正常运行。

定期测试计划

创建灾难恢复计划后，请定期对其进行测试，记下出现的任何问题并相应地调整您的计划。使用 Google Cloud 可让您以最低费用测试恢复方案。为帮助进行测试，建议您完成以下任务：

  • 自动执行基础架构预配。您可以使用 Terraform 等 IaC 工具自动预配虚拟机实例和其他 Google Cloud 基础架构。如果您在本地运行生产环境，请确保具有监控流程，该流程可在检测到失败时启动 DR 流程并可触发相应恢复操作。
  • 使用 Cloud Logging 和 Cloud Monitoring 监控和调试测试。Google Cloud 拥有出色的日志记录和监控工具（您可以通过 API 调用访问这些工具），您可以通过对指标作出反应来自动部署恢复方案。在设计测试时，请确保设置可触发相应恢复操作的监控和警报功能。

  • 执行前面提到的测试：

    • 测试 DR 环境中的权限和用户访问权限是否像在生产环境中一样正常运行。
    • 对 DR 环境执行渗透测试。
    • 执行一项测试，在该测试中，您通常使用的 Google Cloud 访问路径不可用。

后续步骤