应用的灾难恢复场景

Last reviewed 2024-08-05 UTC

本文档是介绍 Google Cloud 中的灾难恢复 (DR) 的系列文章中的一篇。本部分探讨了应用的常见灾难恢复场景。

该系列包含以下部分：

简介

本文档根据灾难恢复模式为应用构建灾难恢复场景，指示应用从灾难事件中恢复的容易程度。文中利用在灾难恢复基础组件文档中讨论的概念来描述如何实现适合您的恢复目标的端到端灾难恢复计划。

首先，应当考虑一些典型的工作负载，以说明如何考虑恢复目标和架构对 DR 计划产生的直接影响。

批处理工作负载

批处理工作负载往往不属于任务关键型工作，因此您不需要承担设计高可用性 (HA) 架构以最大化正常运行时间的成本。通常，批处理工作负载可以处理中断。这种类型的工作负载可以利用经济实惠的产品，例如 Spot 虚拟机和抢占式虚拟机实例。与常规实例相比，这种实例的创建和运行费用要低得多。不过，如果 Compute Engine 需要访问这些资源以处理其他任务，可能会提前停止或删除这些实例。

通过将常规检查点作为处理任务的一部分来实现，处理作业可以从启动新虚拟机时的故障点恢复。 如果您在使用 Dataproc，则启动抢占式工作器节点的过程由托管式实例组管理。这可以被认为是一种暖启动模式，其中有一个短暂的暂停，等待替换虚拟机继续处理。

电子商务网站

在电子商务网站中，应用的某些部分可能具有更大的 RTO 值。 例如，实际购买流水线需要具有高可用性，但向客户发送订单通知的电子邮件流程可以容忍几个小时的延迟。客户知道他们购买的产品，因此虽然他们希望收到确认电子邮件，但通知并不是此过程的关键部分。这是热（购买）、暖和冷（通知）模式的混合。

应用的事务部分需要很长的正常运行时间和最小的 RTO 值。因此，使用 HA 可以最大限度地提高应用的这一部分的可用性。这种方法可以被认为是一种热模式。

电子商务场景说明了如何在同一个应用中使用不同的 RTO 值。

视频流式传输

视频流式传输解决方案具有许多需要高度可用的组件，从搜索体验到流式传输内容至用户的实际过程。此外，该系统需要低延迟时间以达到令人满意的用户体验。如果解决方案的任何方面都无法提供良好的用户体验，那么对供应商和客户都是不利的。此外，如今的客户可以转向其他具有竞争力的产品。

在这种场景下，必须部署 HA 架构，并且需要较小的 RTO 值。此场景需要在整个应用架构中使用热模式，以帮助确保在发生灾难时尽量减少影响。

用于本地生产的 DR 和 HA 架构

本节将介绍当应用在本地运行并且 DR 解决方案部署在 Google Cloud 上时如何实现三种模式，即冷、暖和热模式。

冷模式：恢复到 Google Cloud

在冷模式中，DR Google Cloud 项目中的资源最少，仅能够启用恢复场景。当存在阻止生产环境运行生产工作负载的问题时，故障切换策略需要在 Google Cloud 中启动生产环境的镜像。然后，客户端开始使用 DR 环境中的服务。

在本节中，我们将研究此模式的示例。在该示例中，Cloud Interconnect 配置了自行管理（非 Google Cloud）的 VPN 解决方案，以提供与 Google Cloud 的连接。数据作为生产环境的一部分复制到 Cloud Storage。

此模式使用以下灾难恢复基础组件：

  • Cloud DNS
  • Cloud Interconnect
  • 自行管理的 VPN 解决方案
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

下图说明了此示例的架构：

当生产在本地时，冷模式的架构

以下步骤概述了如何配置环境：

  1. 创建 VPC 网络。
  2. 在本地网络和 Google Cloud 网络之间配置连接。
  3. 创建 Cloud Storage 存储桶作为数据备份的目标。
  4. 创建服务账号。
  5. 创建 IAM 政策以限制谁可以访问存储桶及其对象。您需要将专门为此目的创建的服务账号包括在 IAM 政策中。您还可以将用户账号或组添加到操作员或系统管理员的政策中，从而向所有这些身份授予相关权限。如需详细了解用于访问 Cloud Storage 的权限，请参阅 Cloud Storage 的 IAM 权限。
  6. 使用服务账号模拟为本地 Google Cloud 用户（或服务账号）提供访问权限，以模拟您之前创建的服务账号。或者，您也可以专门为此目的创建一个新用户。
  7. 测试您是否可以上传和下载目标存储桶中的文件。
  8. 创建数据传输脚本。
  9. 创建计划任务以运行脚本。 您可以使用 Linux crontab 和 Windows 任务调度器等工具。

  10. 创建为生产环境中的每个服务器配置的自定义映像。每个映像应与其本地等效映像具有相同的配置。

    作为数据库服务器的自定义映像配置的一部分，创建启动脚本，以自动将最新备份从 Cloud Storage 存储桶复制到实例，然后调用恢复过程。

  11. 配置 Cloud DNS 以指向面向互联网的网络服务。

  12. 创建一个 Deployment Manager 模板，该模板将使用先前配置的自定义映像在 Google Cloud 网络中创建应用服务器。此模板还应设置所需的相应防火墙规则。

您需要实现过程以确保自定义映像的版本与本地应用的版本相同。确保将自定义映像的升级合并到标准升级周期中，并确保您的 Deployment Manager 模板使用最新的自定义映像。

故障切换过程和重启后的任务

当发生灾难时，您可以将系统恢复为 Google Cloud 上运行的系统。为此，您可以启动恢复过程，以使用您创建的 Deployment Manager 模板来创建恢复环境。当恢复环境中的实例准备好接受生产流量时，您需要将 DNS 调整为指向 Google Cloud 中的网络服务器。

典型的恢复顺序如下：

  1. 使用 Deployment Manager 模板在 Google Cloud 中创建部署。
  2. 按照数据库系统中用于恢复备份文件的说明，将 Cloud Storage 中的最新数据库备份应用于在 Google Cloud 中运行的数据库服务器。
  3. 将最新的事务日志应用于 Cloud Storage。
  4. 通过在恢复的环境中模拟用户场景来测试应用是否按预期工作。
  5. 测试成功后，将 Cloud DNS 配置为指向 Google Cloud 上的 Web 服务器。（例如，您可以使用 Google Cloud 负载平衡器后的任播 IP 地址，在负载平衡器后有多个网络服务器）。

下图显示了已恢复的环境：

当生产在本地时，用于恢复的冷模式的配置

当生产环境再次在本地运行并且环境可以支持生产工作负载时，您可以逆向执行将故障切换到 Google Cloud 恢复环境所执行的步骤。返回生产环境的典型顺序如下：

  1. 备份在 Google Cloud 上运行的数据库。
  2. 将备份文件复制到生产环境。
  3. 将备份文件应用在生产数据库系统。
  4. 阻止连接到 Google Cloud 中的应用。例如，阻止连接到全局负载平衡器。从此时起，直到完成生产环境的恢复之前，您的应用将不可用。
  5. 将任何事务日志文件复制到生产环境并将其应用到数据库服务器。
  6. 配置 Cloud DNS 以指向您的本地 Web 服务器。
  7. 确保您将数据复制到 Cloud Storage 的过程按预期运行。
  8. 删除部署。

暖备份：恢复到 Google Cloud

通常可以实现暖模式以最小化 RTO 和 RPO 的值，以避免满配置 HA 所需的工作量和费用。当您的环境可以为接近两个环境的流量提供完全冗余时，RTO 和 RPO 值越小，成本就越高。因此，为 DR 场景实现暖模式是平衡预算和可用性的最好方式。

这种方法的示例是使用配置了自行管理的 VPN 解决方案的 Cloud Interconnect 来提供与 Google Cloud 的连接。在 Google Cloud 上使用最小恢复套件时，多层应用在本地运行。恢复套件包含 Google Cloud 上的操作数据库服务器实例。此实例必须始终运行，以便它可以通过异步或半同步复制技术接收复制的事务。要降低成本，您可以在能够运行数据库服务的最小机器类型上运行数据库。因为您可以使用长时间运行的实例，所以将适用持续使用折扣。

此模式使用以下灾难恢复基础组件：

  • Cloud DNS
  • Cloud Interconnect
  • 自行管理的 VPN 解决方案
  • Compute Engine
  • Deployment Manager

Compute Engine 快照提供了一种备份方法，可让系统回滚到先前的状态。在此示例中使用快照，是因为更新的网页和应用二进制文件经常写入生产网络和应用服务器。这些更新定期复制到 Google Cloud 上的参考网络服务器和应用服务器实例。（参考服务器不接受生产流量，它们的作用是创建快照。）

下图说明了实现此方法的架构。 复制目标未在此图中显示。

当生产在本地时，暖模式的架构

以下步骤概述了如何配置环境：

  1. 创建 VPC 网络。
  2. 在本地网络和 Google Cloud 网络之间配置连接。
  3. 将本地服务器复制到 Google Cloud 虚拟机实例。您可以选择使用合作伙伴解决方案，但具体的方法取决于您面临的情况。
  4. 在 Google Cloud 上创建数据库服务器的自定义映像，其配置应与本地数据库服务器的相同。
  5. 为 Web 服务器实例和应用服务器实例创建快照。
  6. 使用您之前创建的自定义映像在 Google Cloud 中启动数据库实例。使用能够接受来自本地生产数据库的复制数据的最小机器类型。
  7. 将永久性磁盘附加到数据库和事务日志的 Google Cloud 数据库实例。
  8. 按照数据库软件的说明，配置本地数据库服务器和 Google Cloud 中数据库服务器之间的复制。
  9. 将附加到数据库实例的永久性磁盘上的自动删除标志设置为 no-auto-delete。
  10. 配置计划任务以在 Google Cloud 上创建数据库实例的永久性磁盘的常规快照。
  11. 创建预留以确保 Web 服务器和应用服务器的容量符合需要。
  12. 测试从快照创建实例和获取永久性磁盘快照的过程。
  13. 使用先前创建的快照创建网络服务器的实例和应用服务器的实例。
  14. 创建一个脚本，只要更新相应的本地服务器，该脚本就会将更新复制到网络应用和应用服务器。编写脚本以创建更新服务器的快照。
  15. 配置 Cloud DNS 以指向在本地面向互联网的 Web 服务。

故障切换过程和重启后的任务

要管理故障切换，通常使用监控和警报系统来调用自动故障切换过程。当本地应用需要进行故障切换时，您可以在 Google Cloud 上配置数据库系统，以便它能够接受生产流量。您还可以启动网络的实例和应用服务器的实例。

下图显示故障切换到 Google Cloud 后的配置，以便从 Google Cloud 提供生产工作负载：

当生产在本地时，用于恢复的暖模式的配置

典型的恢复顺序如下：

  1. 为数据库服务器实例调整大小，使其可以处理生产负载。
  2. 使用 Google Cloud 上的 Web 服务器快照和应用快照创建新的 Web 服务器实例和应用实例。
  3. 通过在恢复的环境中模拟用户场景来测试应用是否按预期工作。
  4. 测试成功后，将 Cloud DNS 配置为指向 Google Cloud 上的 Web 服务器。

当生产环境再次在本地运行并且环境可以支持生产工作负载时，您可以逆向执行将故障切换到 Google Cloud 恢复环境所执行的步骤。返回生产环境的典型顺序如下：

  1. 备份在 Google Cloud 上运行的数据库。
  2. 将备份文件复制到生产环境。
  3. 将备份文件应用在生产数据库系统。
  4. 阻止连接到 Google Cloud 中的应用。一种方法是通过修改防火墙规则来阻止与网络服务器的连接。从此时起，直到完成生产环境的恢复之前，您的应用将不可用。
  5. 将任何事务日志文件复制到生产环境并将其应用到数据库服务器。
  6. 通过在生产环境中模拟用户场景来测试应用是否按预期工作。
  7. 配置 Cloud DNS 以指向您的本地 Web 服务器。
  8. 删除在 Google Cloud 中运行的网络服务器实例和应用服务器实例。保持参考服务器正常运行。
  9. 为 Google Cloud 上的数据库服务器调整大小，将其设置为可以接受来自本地部署生产数据库的复制数据的最小实例。
  10. 按照数据库软件的说明，配置本地数据库服务器和 Google Cloud 中数据库服务器之间的复制。

跨本地和 Google Cloud 的热 HA

如果您具有较小的 RTO 和 RPO 值，则只能通过在生产环境和 Google Cloud 中同时运行 HA 来实现这些目标。这种方法为您提供了热模式，因为本地和 Google Cloud 都在为生产流量提供服务。

与暖模式的主要区别在于两个环境中的资源都在生产模式下运行并为生产流量提供服务。

此模式使用以下灾难恢复基础组件：

  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • 代管实例组
  • Cloud Monitoring
  • Cloud Load Balancing

下图说明了此示例的架构。通过实现此架构，您的 DR 计划可以在发生灾难时需要最少的干预。

当生产在本地时，热模式的架构

以下步骤概述了如何配置环境：

  1. 创建 VPC 网络。
  2. 在本地网络和 Google Cloud 网络之间配置连接。
  3. 在 Google Cloud 中创建为本地生产环境中的每个服务器配置的自定义映像。每个 Google Cloud 映像应具有与其本地等效项相同的配置。

  4. 按照数据库软件的说明，配置本地数据库服务器和 Google Cloud 中数据库服务器之间的复制。

    配置复制时，许多数据库系统仅允许单个可写数据库实例。因此，您可能需要确保其中一个数据库副本充当只读服务器。

  5. 创建使用应用服务器和 Web 服务器的映像的各实例模板。

  6. 为应用服务器和 Web 服务器配置区域级托管式实例组。

  7. 使用 Cloud Monitoring 配置健康检查。

  8. 使用先前配置的区域级托管式实例组配置负载均衡。

  9. 配置计划任务以创建永久性磁盘的常规快照。

  10. 配置 DNS 服务以在本地环境和 Google Cloud 环境之间分配流量。

使用这种混合方法，您需要使用支持加权路由到两个生产环境的 DNS 服务，以便您可以从这两个生产环境中提供同一个应用。

您需要将系统设计为仅在部分环境中发生故障（部分故障）。在这种情况下，应将流量重新路由到其他备份环境中的等效服务上。例如，如果本地网络服务器不可用，则可以禁用到该环境的 DNS 路由。如果您的 DNS 服务支持健康检查，则在健康检查确定无法访问其中一个环境中的网络服务器时，将自动进行此操作。

如果您使用的数据库系统只允许单个可写实例，则在许多情况下，当原始可写数据库与只读副本之间的心跳丢失时，数据库系统将自动将只读副本提升为可写主数据库。如果您需要在灾难发生后进行干预，请确保您了解数据库复制的这一特点。

您需要实现进程以确保 Google Cloud 中自定义虚拟机映像的版本与本地应用的版本相同。确保将自定义映像的升级合并到标准升级周期中，并确保您的 Deployment Manager 模板使用最新的自定义映像。

故障切换过程和重启后的任务

在此处针对热场景描述的配置中，灾难表示两个环境中的一个不可用。暖场景或冷场景的故障切换过程是不同的，因此您需要将数据移动到第二个环境或在其中处理。但是，您可能需要处理以下配置更改：

  • 如果您的 DNS 服务未在健康检查失败时自动重新路由流量，则需要手动配置 DNS 路由以将流量发送到仍处于运行状态的系统。
  • 如果数据库系统未在故障时自动将只读副本提升为可写主数据库，则需要进行干预以确保其能够提升副本。

当第二个环境再次运行并且可以处理生产流量时，您需要重新同步数据库。由于两个环境都支持生产工作负载，因此您无需采取任何进一步操作来确定主数据库。在同步数据库之后，您可以通过调整 DNS 设置再次允许生产流量在两个环境中分布。

用于 Google Cloud 上的生产的 DR 和 HA 架构

在 Google Cloud 上为生产工作负载设计应用架构时，平台的 HA 功能会直接影响 DR 架构。

Backup and DR Service 是一种集中式云原生解决方案，用于备份和恢复云工作负载和混合工作负载。它可快速恢复数据，并有助于快速恢复重要的业务运营。

如需详细了解如何针对 Google Cloud 上的应用场景使用 Backup and DR Service，请参阅以下内容：

冷场景：可恢复的应用服务器

在需要单个活跃服务器实例的冷故障切换场景中，只有一个实例应写入磁盘。在本地环境中，您通常使用主动/被动集群。在 Google Cloud 上运行生产环境时，您可以在仅运行一个实例的托管式实例组中创建虚拟机。

此模式使用以下灾难恢复基础组件：

  • Compute Engine
  • 代管式实例组

此冷故障切换场景如以下示例架构图片所示：

当生产在 Google Cloud 上时，用于恢复的冷模式的配置

以下步骤概述了如何配置此冷故障切换场景：

  1. 创建 VPC 网络。
  2. 创建使用应用 Web 服务配置的自定义虚拟机映像。
    1. 配置虚拟机，以便将应用服务处理的数据写入附加的永久性磁盘。
  3. 从挂接的永久性磁盘创建快照。
  4. 创建引用 Web 服务器的自定义虚拟机映像的实例模板。
    1. 配置启动脚本以使用最新快照创建永久性磁盘并装载磁盘。此脚本必须能够获取磁盘的最新快照。
  5. 创建托管式实例组和健康检查，目标大小为 1，并引用实例模板。
  6. 创建计划任务以创建永久性磁盘的常规快照。
  7. 配置外部应用负载均衡器。
  8. 使用 Cloud Monitoring 配置提醒，以在服务失败时发送提醒。

这种冷故障切换场景利用了 Google Cloud 中提供的一些高可用性功能。如果虚拟机发生故障，则托管式实例组会尝试自动重新创建该虚拟机。您不必启动此故障切换步骤。外部应用负载均衡器可确保即使需要替换虚拟机，也会在应用服务器之前使用相同的 IP 地址。实例模板和自定义映像可确保替换后的虚拟机配置与其替换的实例相同。

您的 RPO 由最后拍摄的快照决定拍摄快照的次数越多，RPO 值越小。

托管式实例组提供更高级的 HA 功能。托管式实例组提供了对应用或虚拟机级别的故障作出反应的机制。如果发生任何这些情况，您不必手动干预，系统会自动为您执行操作。目标大小为 1 可确保您在代管式实例组中只有一个正在运行的实例来处理流量。

永久性磁盘是分区的，因此如果发生可用区级故障，您必须拍摄快照以重新创建磁盘。快照还可以跨区域使用，这使得您可以像恢复到同一区域那样将磁盘恢复到其他区域。

万一发生罕见的可用区级故障，您必须手动干预恢复过程，如下一部分所述。

故障切换过程

如果虚拟机发生故障，则托管式实例组会自动尝试在同一可用区中重新创建该虚拟机。该实例模板中的启动脚本会从最新快照创建一个永久性磁盘，并将其挂接到新虚拟机。

但是，如果发生可用区故障，则大小为 1 的托管式实例组不会恢复。如果某个可用区发生故障，您必须在服务失败时对 Cloud Monitoring 提醒或其他监控平台作出反应，并在其他可用区中手动创建实例组。

此配置的变体是使用地区级永久性磁盘而不是可用区级永久性磁盘。使用此方法，在恢复过程中，您无需使用快照即可恢复永久性磁盘。但是，此变体会消耗两倍的存储空间，您需要为此提供预算。

您选择的方法取决于您的预算以及 RTO 和 RPO 值。

暖场景：静态站点故障切换

如果 Compute Engine 实例失败，您可以通过使基于 Cloud Storage 的静态站点处于待机状态来缓解服务中断。 如果您的 Web 应用基本上处于静态状态，此模式非常适合。

在此场景中，主应用在 Compute Engine 实例上运行。这些实例分组为托管式实例组，且这些实例组用作 HTTPS 负载均衡器的后端服务。HTTP 负载平衡器根据负载平衡器配置、每个实例组的配置以及每个实例的运行状况将传入流量指向实例。

此模式使用以下灾难恢复基础组件：

  • Compute Engine
  • Cloud Storage
  • Cloud Load Balancing
  • Cloud DNS

下图说明了此示例的架构：

当生产在 Google Cloud 上时，用于暖故障切换到静态网站的架构

以下步骤概述了如何配置此场景：

  1. 创建 VPC 网络。
  2. 创建使用应用 Web 服务配置的自定义映像。
  3. 创建一个使用 Web 服务器映像的实例模板。
  4. 为 Web 服务器配置托管式实例组。
  5. 使用 Monitoring 配置健康检查。
  6. 使用先前配置的托管式实例组配置负载均衡。
  7. 创建基于 Cloud Storage 的静态站点。

在生产配置中，Cloud DNS 配置为指向此主应用，并且备用静态站点处于休眠状态。如果 Compute Engine 应用出现故障，您可以将 Cloud DNS 配置为指向此静态站点。

故障切换过程

如果一个或多个应用服务器发生故障，则恢复顺序是配置 Cloud DNS 以指向静态网站。下图显示了其恢复模式下的架构：

当生产工作负载在 Google Cloud 上时，故障切换到静态站点后的配置。

当应用 Compute Engine 实例再次运行并且可以支持生产工作负载时，您可以逆向执行恢复步骤，即配置 Cloud DNS 以指向作为实例前端的负载均衡器。

或者，您可以使用永久性磁盘异步复制。该功能可为跨区域主动-被动灾难恢复提供具有低恢复点目标 (RPO) 和低恢复时间目标 (RTO) 的块存储复制。此存储选项让您可以在基础设施级层（而不是工作负载级层）管理 Compute Engine 工作负载的复制。

热场景：HA Web 应用

生产环境在 Google Cloud 上运行时的热模式用于建立架构良好的 HA 部署。

此模式使用以下灾难恢复基础组件：

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

下图说明了此示例的架构：

当生产在 Google Cloud 上时，热模式的架构

此场景利用了 Google Cloud 中的 HA 功能。即您不必启动任何故障切换步骤，因为它们将在发生灾难时自动进行。

如图所示，该架构使用区域级托管式实例组、全球负载均衡和 Cloud SQL。由于此处的示例使用区域级托管式实例组，因此实例分布在三个可用区中。

通过这种方法，可以使用高级 HA 功能。例如，区域托管实例组提供了对应用、实例或地区级别的故障作出反应的机制。如果发生任何这些情况，您不必手动干预，系统会自动为您执行操作。

要解决应用级的恢复问题，请在设置托管实例组时配置 HTTP 健康检查，以验证服务是否在该组中的实例上正常运行。如果健康检查确定实例上的某项服务出现故障，则该组将自动重新创建该实例。

如需详细了解如何在 Google Cloud 上构建可扩缩且弹性佳的应用，请参阅构建可扩缩且弹性佳的应用时应遵循的模式。

后续步骤