应用的灾难恢复场景

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

该系列包含以下部分:

简介

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

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

批处理工作负载

批处理工作负载往往不属于任务关键型工作,因此您不需要承担设计 HA 架构以最大化正常运行时间的成本。通常,批处理工作负载可以处理中断。这种类型的工作负载可以使用经济高效的产品,例如抢占式虚拟机实例。相比普通实例,这种实例的创建和运行所需的成本更低。(但是,如果 Compute Engine 需要访问这些资源以执行其他任务,它们将终止抢占 这些实例,并且这些实例将在启动后 24 小时内终止。)

通过将常规检查点作为处理任务的一部分来实现,处理作业可以从启动新虚拟机时的故障点恢复。 如果您正在使用 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. 将服务帐号密钥复制到本地计算机,您将在其中运行上传到数据库备份的脚本。(这个本地计算机可以是您的数据库服务器,但您的安全政策可能不允许您在数据库服务器上安装其他软件。)

  6. 创建 IAM 政策以限制谁可以访问存储分区及其对象。您需要将专门为此目的创建的服务帐号包括在 IAM 政策中。您还可以将用户帐号或组添加到操作员或系统管理员的政策中,从而向所有这些身份授予相关权限。如需详细了解用于访问 Cloud Storage 的权限,请参阅 gsutil 命令的 IAM 权限

  7. 测试您是否可以上传和下载目标存储分区中的文件。

  8. 创建数据传输脚本

  9. 创建计划任务以运行脚本。

  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 上的网络服务器。(例如,您可以使用 Google Cloud 负载平衡器后的任播 IP 地址,在负载平衡器后有多个网络服务器)。

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

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

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

  1. 备份在 Google Cloud 上运行的数据库。
  2. 将备份文件复制到生产环境。
  3. 将备份文件应用在生产数据库系统。
  4. 阻止连接到 Google Cloud 中的应用。例如,阻止连接到全局负载平衡器。从此时起,直到完成生产环境的恢复之前,您的应用将不可用。
  5. 将任何事务日志文件复制到生产环境并将其应用到数据库服务器。
  6. 配置 Cloud DNS 以指向您的本地网络服务。
  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. 为网络服务器实例和应用服务器实例创建快照
  6. 使用您之前创建的自定义映像在 Google Cloud 中启动数据库实例。使用能够接受来自本地生产数据库的复制数据的最小机器类型。
  7. 永久性磁盘附加到数据库和事务日志的 Google Cloud 数据库实例。
  8. 按照数据库软件的说明,配置本地数据库服务器和 Google Cloud 中数据库服务器之间的复制。
  9. 将附加到数据库实例的永久性磁盘上的自动删除标志设置为 no-auto-delete
  10. 配置计划任务以在 Google Cloud 上创建数据库实例的永久性磁盘的常规快照。
  11. 测试从快照创建实例和获取永久性磁盘快照的过程。
  12. 使用先前创建的快照创建网络服务器的实例和应用服务器的实例。
  13. 创建一个脚本,只要更新相应的本地服务器,该脚本就会将更新复制到网络应用和应用服务器。编写脚本以创建更新服务器的快照。
  14. 配置 Cloud DNS 以指向在本地面向互联网的网络服务。

故障转移过程和重启后的任务

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

下图显示故障转移到 Google Cloud 后的配置,以便从 Google Cloud 提供生产工作负载:

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

典型的恢复顺序如下:

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

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

  1. 备份在 Google Cloud 上运行的数据库。
  2. 将备份文件复制到生产环境。
  3. 将备份文件应用在生产数据库系统。
  4. 阻止连接到 Google Cloud 中的应用。一种方法是通过修改防火墙规则来阻止与网络服务器的连接。从此时起,直到完成生产环境的恢复之前,您的应用将不可用。
  5. 将任何事务日志文件复制到生产环境并将其应用到数据库服务器。
  6. 通过在生产环境中模拟用户场景来测试应用是否按预期工作。
  7. 配置 Cloud DNS 以指向您的本地网络服务。
  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. 创建使用应用服务器和网络服务器的映像的单个实例模板

  6. 为应用服务器和网络服务器配置区域代管实例组

  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 架构。

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

在只需要一个服务器实例的冷场景中,您只需要将一个实例写入磁盘。在本地,这通常通过使用主动/被动集群来实现。相反,当您在 Google Cloud 上运行生产环境时,服务器实例是托管实例组的一部分,该组用作内部负载平衡服务的后端服务

灾难恢复组件:

  • Compute Engine
  • Google Cloud 内部负载平衡

下图说明了此示例的架构。此图没有说明客户端连接,因为通常不会有外部客户端直接连接到应用服务器。相反,应用服务器前面通常会有一个代理或 Web 应用。

当生产在 Google Cloud 上时,冷场景的架构

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

  1. 创建 VPC 网络
  2. 创建自定义映像并使用应用服务进行配置。作为映像的一部分,进行以下配置:

    1. 配置服务器,以便将应用服务处理的数据写入附加的永久性磁盘。
    2. 从附加的永久性磁盘创建快照
    3. 配置启动脚本以使用最新快照创建永久性磁盘并装载磁盘。此脚本需要能够获取磁盘的最新快照。
  3. 创建使用该映像的实例模板

  4. 使用先前创建的实例模板配置目标大小为 1 的区域托管实例组

  5. 使用 Monitoring 配置运行状况检查。

  6. 使用先前配置的区域托管实例组配置内部负载平衡

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

此场景利用了 Google Cloud 中提供的一些高可用性功能。您不必启动任何故障转移步骤,因为这些步骤将在灾难发生时自动执行。内部负载平衡器确保即使需要替换实例,也会为应用服务器配置相同的 IP 地址。实例模板和自定义映像可确保替换实例的配置与其替换的实例完全相同。

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

区域托管实例组提供更高级的 HA 功能。例如,它提供了对应用、实例或地区级别的故障作出反应的机制。如果出现任何这些情况,您不必手动干预,系统会自动为您执行操作。将目标大小设置为 1 可确保您只运行 1 个实例。

永久性磁盘是分区的,因此需要快照才能在地区性故障时重新创建磁盘。跨区域也可以使用快照,这使得您可以将磁盘还原到其他区域,且操作与将磁盘还原到同一区域一样简单。

故障转移过程

在此场景中,如果发生地区性故障,区域实例组将在同一区域的不同地区中启动替换实例。然后,从最新快照创建新的永久性磁盘并将其附加到新实例。下图说明了这种状态:

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

此配置的一些变体包括以下内容:

  • 使用区域永久性磁盘而不是地区永久性磁盘。使用此方法,在恢复过程中,您无需使用快照即可恢复永久性磁盘。 但是,此变体会消耗两倍的存储空间,您需要为此提供预算。
  • 使用托管实例组而不是区域托管实例组,并将永久性磁盘附加到与故障实例位于同一地区的替换实例。在这种情况下,您必须将永久性磁盘的自动删除设置配置为 no-auto-delete

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

暖场景:静态站点故障转移

如果 Compute Engine 实例失败,您可以通过使基于 Cloud Storage 的静态站点处于待机状态来缓解服务中断。 当您的 Web 应用基本上处于静态时,可以考虑使用静态站点。在此场景中,主应用在 Compute Engine 实例上运行。这些实例分组为托管实例组,且这些实例组用作 HTTP 负载平衡器的后端服务。HTTP 负载平衡器根据负载平衡器配置、每个实例组的配置以及每个实例的运行状况将传入流量指向实例。

灾难恢复组件:

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

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

当生产在 Google Cloud 上时,用于暖故障转移到静态网站的架构

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

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

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

故障转移过程

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

当生产在 GCP 时,故障转移到静态站点后的配置

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

热场景:HA Web 应用

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

灾难恢复组件:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

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

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

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

如图所示,该架构使用区域托管实例组、全局负载平衡和 Cloud SQL。此处的示例使用区域托管实例组,因此实例分布在三个地区中。

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

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

如需了解在 Google Cloud 上配置 HA Web 应用的方法的详细步骤,请参阅 Google Cloud 上的可扩缩弹性 Web 应用

后续步骤