考虑为任务关键型系统提供业务连续性的主要目的是帮助组织在发生故障事件期间和之后保持弹性并继续开展业务运营。通过复制多个地理区域的系统和数据并避免单点故障，您可以将影响本地基础架构的自然灾害风险降至最低。其他故障场景包括严重的系统故障、网络安全攻击，甚至是系统配置错误。
优化系统以应对故障对于建立有效的业务连续性至关重要。系统可靠性会受到多种因素的影响，包括但不限于性能、弹性、正常运行时间可用性、安全性以及用户体验。如需详细了解如何在Google Cloud上构建和运营可靠的服务，请参阅 Google Cloud Well-Architected Framework 的可靠性支柱以及 Google Cloud中的可靠性构建块。
此架构模式依赖于跨多个计算环境的应用的冗余部署。在此模式中，您会在多个计算环境中部署同一应用，旨在提高可靠性。 业务连续性可以定义为组织在中断事件发生后，能够以预定义的可接受水平继续执行其关键业务功能或提供服务的能力。
灾难恢复 (DR) 被认为是业务连续性的一个部分，明确侧重于确保支持关键业务功能的 IT 系统在中断事件发生后尽快运行。一般来说，灾难恢复策略和计划通常有助于形成更广泛的业务连续性策略。从技术角度来看，当您开始制定灾难恢复策略时，业务影响分析应定义两个关键指标：恢复点目标 (RPO) 和恢复时间目标 (RTO)。如需有关使用 Google Cloud 处理灾难恢复的更多指导，请参阅灾难恢复规划指南。
RPO 和 RTO 目标值越小，服务从中断中恢复的速度就越快，数据丢失也越少。不过，这意味着需要构建冗余系统，因此成本会更高。能够执行近乎实时的数据复制并在发生故障事件后以相同规模运行的冗余系统会增加复杂性、管理开销和成本。
选择灾难恢复策略 或模式的决策应以业务影响分析为依据。例如，对于金融服务组织而言，即使停机几分钟造成的财务损失也可能远远超过实施灾难恢复系统的成本。不过，其他行业的企业可能会承受数小时的停机时间，而不会对业务产生重大影响。
当您在本地数据中心运行任务关键型系统时，灾难恢复的方法之一，是在位于另一区域的另一个数据中心维护备用系统。不过，更经济实惠的方法是使用基于公有云的计算环境进行故障切换。此方法是业务连续性混合模式的主要驱动因素。从成本角度来看，云平台尤其具有吸引力，因为您可以关闭部分不使用的灾难恢复基础设施。为了实现低成本的灾难恢复解决方案，企业可以接受云解决方案带来的 RPO 和 RTO 值潜在增加。
上图展示了如何将云用作本地环境的故障切换或灾难恢复环境。
此模式有一个不太常见（且很少被需要）的变体，即业务连续性多云端模式。在该模式下，生产环境使用一个云提供商，灾难恢复环境使用另一个云提供商。通过跨多个云提供商部署工作负载副本，您可以获得超过多区域部署所提供的可用性。
评估跨多个云的灾难恢复与使用一个云提供商的不同区域需要对多种因素进行全面分析，包括：
- 易管理性
- 安全
- 总体可行性。
- 费用
- 如果持续进行云间通信，则向多个云提供商支付的出站数据传输费用可能会非常高昂。
- 复制数据库时，可能会产生大量流量。
- 总体拥有成本和管理云间网络基础设施的成本。
如果您的数据需要保留在您的国家/地区，以满足监管要求，那么使用也位于您国家/地区的第二家云服务商作为灾难恢复解决方案可能是一个不错的选择。使用第二个云服务提供商的前提是，无法使用本地环境来构建混合设置。为避免重新设计云解决方案，理想情况下，您的第二个云提供商应在区域内提供您所需的所有功能和服务。
设计考虑事项
- 灾难恢复预期：企业希望实现的 RPO 和 RTO 目标应推动灾难恢复架构和构建规划。
- 解决方案架构：采用此模式时，您需要复制本地环境的现有功能和能力，以满足灾难恢复预期。因此，您需要评估重新托管、重构或重新设计应用的可行性和可行性，以便在云环境中提供相同（或更优化）的功能和性能。
- 设计和构建：构建着陆区几乎总是在云环境中部署企业工作负载的前提条件。如需了解详情，请参阅 Google Cloud中的着陆区设计。
灾难恢复调用：在设计灾难恢复方案和流程时，请务必考虑以下问题：
- 什么会触发灾难恢复场景？例如，如果主站点中的特定功能或系统发生故障，可能会触发灾难恢复。
- 如何调用到 DR 环境的故障切换？是手动审批流程，还是可以自动执行以实现较低的 RTO 目标？
- 系统故障检测和通知机制应如何设计，才能在发生故障切换时符合预期的 RTO？
- 检测到故障后，流量如何重新路由到 DR 环境？
通过测试验证您对这些问题的回答。
测试：全面测试和评估向 DR 的故障切换。确保其符合您的 RPO 和 RTO 预期。这样做可以帮助您在需要时更有信心调用 DR。每当对流程或技术解决方案进行新的更改或更新时，请再次进行测试。
团队技能：除非您的环境由第三方管理，否则一个或多个技术团队必须具备在云环境中构建、运营和排查生产工作负载的技能和专业知识。
优点
使用 Google Cloud 实现业务连续性具有以下几项优势：
- 由于 Google Cloud 在全球范围内有许多区域可供选择，因此您可以使用它将数据备份或复制到同一大洲内的其他位置。您还可以将数据备份或复制到其他大洲的位置。
- Google Cloud 支持将数据存储在 Cloud Storage 的双区域或多区域存储桶中。数据以冗余方式存储在至少两个不同的地理区域。存储在双区域和多区域存储分区中的数据会使用默认复制跨地理区域进行复制。
- 提供以下一个或多个选项，以减少构建灾难恢复 (DR) 解决方案所需的资本支出和运营支出：
- 已停止的虚拟机实例仅产生存储费用，比正在运行的虚拟机实例便宜很多。这意味着您可以最大限度地降低维护冷备用系统的费用。
- Google Cloud 的按用量计费模式意味着您只需为实际使用的存储和计算容量付费。
- 借助自动扩缩等弹性功能，您可以根据需要自动扩缩灾难恢复环境。
例如，下图显示了在本地环境（生产环境）中运行的应用，该应用使用Google Cloud 上的恢复组件，并搭配使用 Compute Engine、Cloud SQL 和 Cloud Load Balancing。在此方案中，数据库预先配置为基于虚拟机的数据库或 Google Cloud 托管式数据库（例如 Cloud SQL），以便通过持续的数据复制实现更快的恢复。您可以从预先创建的快照启动 Compute Engine 虚拟机，以降低正常运行期间的费用。在这种设置下，发生故障事件后，DNS 需要指向 Cloud Load Balancing 外部 IP 地址。
为了让应用在云端正常运行，您需要预配 Web 和应用虚拟机。根据目标 RTO 级别和公司政策，调用灾难恢复、在云端预配工作负载和重新路由流量的整个过程可以手动完成，也可以自动完成。
为了加快基础架构的预配速度并实现自动化，请考虑以代码形式管理基础架构。您可以使用 Cloud Build（一种持续集成服务）自动将 Terraform 清单应用到您的环境。如需了解详情，请参阅使用 Terraform、Cloud Build 和 GitOps 以代码形式管理基础架构。
最佳做法
使用业务连续性模式时，请考虑以下最佳实践：
- 创建记录基础架构以及故障切换和恢复过程的灾难恢复计划。
- 根据业务影响分析以及确定的所需 RPO 和 RTO 目标，考虑采取以下措施：
- 如果您仅备份数据，请考虑使用切换模式。 否则，网状模式可能是复制现有环境网络架构的理想选择。
- 最大限度减少在不同环境中运行的系统之间的依赖项，尤其是在同步处理通信时。这些依赖项会降低性能并降低整体可用性。
避免脑裂问题。如果跨环境双向复制数据，您可能会遇到脑裂问题。当双向复制数据的两个环境彼此失去通信时，就会出现脑裂问题。这种分裂可能会导致两个环境中的系统断定另一个环境不可用，并且它们拥有对数据的独占访问权限。这可能会导致数据修改冲突。 有两种常见方法可以避免脑裂问题：
- 使用第三个计算环境。在此环境中，系统可以在修改数据之前检查仲裁。
允许在恢复连接后对有冲突的数据修改进行协调。
对于 SQL 数据库，您可以在客户端开始使用新的主实例之前，使原始主实例无法访问，从而避免脑裂问题。如需了解详情，请参阅 Cloud SQL 数据库灾难恢复。
确保 CI/CD 系统和工件代码库不会成为单点故障。当一个环境不可用时，您仍须能够部署新版本或应用配置更改。
在使用备用系统时，请确保所有工作负载都具有可移植性。所有工作负载都应具有可移植性（如果应用支持且可行），以便系统在不同环境之间保持一致。您可以考虑使用容器和 Kubernetes 来实现此方法。借助 Google Kubernetes Engine (GKE)，您可以简化构建和运营。
将备用系统的部署集成到 CI/CD 流水线中。 此集成有助于确保应用版本和配置在不同环境之间保持一致。
为了确保 DNS 更改快速传播，请使用合理的较短存留时间值来配置 DNS，以便在发生灾难时，可以将用户重新路由到备用系统。
选择与您的架构和解决方案行为相符的 DNS 政策和路由政策。此外，您还可以将多个区域级负载平衡器与 DNS 路由政策结合使用，以针对不同的使用情形（包括混合设置）创建全球负载均衡架构。
使用多个 DNS 提供商。使用多个 DNS 提供商时，您可以：
- 提高应用和服务的可用性和弹性。
通过多提供商 DNS 配置，简化在本地和云环境中具有依赖项的混合应用的部署或迁移。
Google Cloud 提供基于 octoDNS 的开源解决方案，帮助您设置和运行具有多个 DNS 提供商的环境。如需了解详情，请参阅使用 Cloud DNS 的多提供商公共 DNS。
使用备用系统时，请使用负载平衡器创建自动故障切换。请注意，负载均衡器硬件可能会发生故障。
使用 Cloud Load Balancing 而不是硬件负载平衡器来应对使用此架构模式时出现的一些情况。内部客户端请求或外部客户端请求可以根据不同的指标（例如基于权重的流量拆分）重定向到主环境或 DR 环境。如需了解详情，请参阅全球外部应用负载平衡器的流量管理概览。
如果从 Google Cloud 到其他环境的出站数据传输量较高，请考虑使用 Cloud Interconnect 或跨云互连。Cloud Interconnect 有助于优化连接性能，并可能降低满足特定条件的流量的出站数据传输费用。如需了解详情，请参阅 Cloud Interconnect 价格。
不妨考虑使用 Google Cloud Marketplace 中您首选的合作伙伴解决方案，以帮助您轻松完成数据备份、复制和其他符合您要求的任务，包括实现 RPO 和 RTO 目标。
测试并评估 DR 调用场景，以了解与目标 RTO 值相比，应用从灾难事件中恢复的容易程度。
加密传输中的通信。为了保护敏感信息，我们建议对所有传输中的通信进行加密。如果需要在连接层进行加密，根据所选的混合连接解决方案，有多种选项可供选择。这些选项包括 VPN 隧道、通过 Cloud Interconnect 实现的高可用性 VPN 和 MACsec for Cloud Interconnect。