针对云基础设施服务中断设计灾难恢复架构

Last reviewed 2024-05-10 UTC

本文是介绍 Google Cloud 中的灾难恢复 (DR) 的系列文章中的一篇，本部分讨论了使用 Google Cloud 设计工作负载架构的过程，以及能够应对云基础设施服务中断的基础组件。

该系列包含以下部分：

• 灾难恢复规划指南
• 灾难恢复组件
• 数据灾难恢复方案
• 应用灾难恢复场景
• 为受限于位置的工作负载设计灾难恢复架构
• 灾难恢复使用场景：受限于位置的数据分析应用
• 针对云基础架构服务中断设计灾难恢复架构（本文档）

简介

随着企业将工作负载迁移到公有云，他们需要将对构建弹性本地系统的理解转换为 Google Cloud 等云服务商的超大规模基础架构。本文将有关灾难恢复的业界标准概念（例如，恢复时间目标 (RTO) 和恢复点目标 (RPO)）映射到 Google Cloud 基础架构。

本文档中的指导遵循了 Google 的一项关键原则，从而实现极高的服务可用性：针对故障进行规划。虽然 Google Cloud 可提供高度可靠的服务，但灾难会引起自然灾害、光纤断裂和复杂的不可预测的基础架构故障，这些灾难都会导致服务中断。通过规划服务中断，Google Cloud 客户可以利用“内置”灾难恢复机制的 Google Cloud 产品，构建能够以可预测的方式处理这些不可避免的事件的应用。

灾难恢复是一个宽泛的主题，不只是涵盖基础架构故障（例如软件 bug 或数据损坏），您应制定全面的端到端方案。但是，本文重点介绍了整个灾难恢复方案的一部分：如何设计能够应对云基础架构服务中断的应用。具体来说，本文将分步演示：

1. Google Cloud 基础架构、灾难事件如何表现为 Google Cloud 服务中断，以及如何设计 Google Cloud 架构以最大限度地减少服务中断的频率和范围。
2. 架构规划指南，该指南提供了一个框架，以便您根据所需的可靠性结果对应用进行分类和设计。
3. 具有您可能希望在应用中使用的内置灾难恢复功能的精选 Google Cloud 产品的详细列表。

如需详细了解通用灾难恢复规划以及如何将 Google Cloud 用作本地灾难恢复策略中的一个组件，请参阅灾难恢复规划指南。此外，虽然高可用性是与灾难恢复密切相关的概念，但本文未对其进行介绍。如需详细了解如何设计架构以实现高可用性，请参阅 Google Cloud 架构框架。

关于术语的说明：本文引用了可用性来讨论在一段时间内是否能够有效访问和使用某个产品，而可靠性指的是一组特性，包括可用性以及耐用性和正确性等特性。

如何设计 Google Cloud 以实现恢复能力

Google 数据中心

传统数据中心依赖于尽可能提高各个组件的可用性。在云端，扩缩功能可让 Google 等运营商使用虚拟化技术将服务分布到多个组件，从而超越传统组件的可靠性。这意味着，您可以改变可靠性架构思维模式，而不再考虑之前所担心的有关本地环境的诸多细节。您可以针对 Google Cloud 产品及其指明的可靠性指标进行规划，而不必考虑组件的各种故障模式（例如，制冷和电源输送）。这些指标反映了整个底层基础架构的总体服务中断风险。这使您可以更专注于应用设计、部署和操作，而不是基础架构管理。

Google 凭借我们构建和运行现代数据中心的丰富经验设计其基础架构，从而满足严格的可用性目标。Google 是数据中心设计领域的全球领导者。从电源到制冷再到网络，每个数据中心技术都有其自己的冗余和缓解措施，包括 FMEA 方案。Google 的数据中心所采用的构建方式可以均衡多种不同风险，并且可为客户提供一致的 Google Cloud 产品预期可用性水平。Google 可凭借其经验模拟整体物理和逻辑系统架构的可用性，从而确保数据中心设计符合预期。Google 的工程师们在运营上会竭尽全力，以帮助确保符合这些预期。实际衡量的可用性通常远远超出我们的设计目标。

通过将所有数据中心风险和缓解措施提炼成面向用户的产品，Google Cloud 可让您减轻设计和运营方面的负担。相反，您可以专注于从设计层面在 Google Cloud 区域和可用区实现可靠性。

区域和可用区

很多区域和可用区都提供了 Google Cloud 产品。区域是物理上独立的地理位置，包含三个或三个以上的可用区。可用区表示物理物理组中的资源组，它们在物理和逻辑基础架构方面具有高度独立的独立性。同一区域中的可用区之间有着高带宽、低延迟网络连接。例如，日本的 asia-northeast1 区域包含三个可用区：asia-northeast1-a、asia-northeast1-b 和 asia-northeast1-c。

Google Cloud 产品分为可用区级资源、区域级资源或多区域资源。

可用区级资源托管在单个可用区中。该可用区发生服务中断可能会影响其中的所有资源。例如，某个 Compute Engine 实例在单个指定可用区中运行；如果硬件故障导致该可用区的服务中断，则该 Compute Engine 实例在中断期间不可用。

区域级资源以冗余方式部署在一个区域内的多个可用区中。因此，与可用区级资源相比，区域级资源具有较高的可靠性。

多区域资源分布在相同区域内和不同区域之间。通常情况下，多区域资源比单区域资源具有更高的可靠性。但是，在此层级上，产品必须优化可用性、性能和资源效率。因此，了解您决定使用的每个多区域产品所做的权衡非常重要。本文档后面部分介绍了具体产品的相应权衡。

如何利用可用区和区域实现可靠性

Google SRE 可通过各种方法和技术在全球各地顺畅利用计算基础架构，从而管理和扩缩 Gmail 和 Google 搜索等高可靠性的全球用户产品。这包括使用全球负载均衡将流量从不可用位置重定向到其他位置、在全球多个位置运行多个副本，以及在各个不同位置复制数据。Cloud Load Balancing、Google Kubernetes Engine (GKE) 和 Spanner 等产品也可为 Google Cloud 客户提供上述同样的功能。

Google Cloud 通常设计的产品可为可用区和区域提供以下可用性级别：

资源	示例	可用性设计目标	隐含的停机时间
可用区级	Compute Engine、Persistent Disk	99.9%	8.75 小时/年
区域	区域级 Cloud Storage、复制的 Persistent Disk、区域级 GKE	99.99%	52 分钟/年

注意：这些是设计准则。如需了解 Google Cloud 服务等级承诺，请参阅 Google Cloud 服务等级协议。

将 Google Cloud 可用性设计目标与可接受的停机时间级别进行比较，可确定相应的 Google Cloud 资源。虽然传统设计侧重于通过提高组件级可用性来改进生成的应用可用性，但云模型专注于组合组件来实现此目标。Google Cloud 中的许多产品都使用此方法。例如，Spanner 提供一个组合多个区域的多区域数据库，从而实现 99.999% 的可用性。

组合非常重要，因为如果没有它，您的应用可用性无法超过您所用的 Google Cloud 产品的可用性；事实上，除非您的应用从不发生故障，否则它的可用性低于底层 Google Cloud 产品的可用性。本部分其余内容简要介绍了如何通过可用区和区域产品的组合来实现高于单可用区或单区域所提供的应用可用性。下一部分提供了将这些原则应用于您的应用的实用指南。

规划可用区服务中断的范围

基础架构故障通常会在单个可用区造成服务中断。一个区域内，可用区旨在最大限度地降低与其他可用区关联故障的风险，并且可用区中的服务中断通常不会影响同一区域内其他可用区的服务。范围限定至可用区的服务中断不一定意味着整个可用区都不可用，而只是定义了突发事件的边界。有可能出现某可用区发生服务中断不会对该可用区中的特定资源产生切实影响的情况。

这种情况比较少见，但另请务必注意，一个区域内的多个可用区最终仍会在某个时间点发生相关服务中断。当两个或两个以上可用区发生服务中断时，系统将应用下面的区域服务中断范围策略。

区域级资源旨在通过从多个可用区组合提供服务来防范可用区服务中断。如果支持区域级资源的某一可用区级服务中断，则可自动从其他可用区获得该资源。如需了解详情，请仔细查看附录中的产品功能说明。

Google Cloud 仅提供少量可用区级资源，即 Compute Engine 虚拟机 (VM) 和 Persistent Disk。如果您计划使用可用区级资源，则需要通过在位于多个可用区中的可用区级资源之间设计、构建和测试故障切换及恢复来自行执行资源组合。部分策略包括：

• 在健康检查确定某个可用区遇到问题时，使用 Cloud Load Balancing 将流量快速路由到其他可用区中的虚拟机。
• 使用 Compute Engine 实例模板和/或代管式实例组在多个可用区中运行和扩缩相同的虚拟机实例。
• 使用区域级 Persistent Disk 将数据同步复制到一个区域中的其他可用区。如需了解详情，请参阅使用区域级 Persistent Disk 的高可用性选项。

规划区域服务中断的范围

区域服务中断是指影响单个区域中的多个可用区的服务中断。这种服务中断规模较大、发生频率较低，可能是由于自然灾害或大规模基础架构故障引起的。

对于旨在提供 99.99% 可用性的区域级产品，服务中断仍可转换为特定产品每年近一个小时的停机时间。因此，如果此服务中断时长不可接受，则您的关键应用可能需要实施多区域灾难恢复方案。

多区域资源旨在通过从多个区域提供服务来防范区域级服务中断。如上所述，多区域产品会在延迟时间、一致性和费用之间进行权衡。最常见的权衡是在同步数据复制和异步数据复制之间权衡。异步复制可实现更短的延迟，但代价是在服务中断期间会有数据丢失的风险。因此，请务必查看附录中的产品功能说明以了解详情。

注意：在 BigQuery 中，多区域位置不提供跨区域复制和区域冗余功能。数据将存储在该地理位置的单个区域中。

如果您要使用区域级资源并且能够始终应对区域级服务中断，则您必须通过在位于多个区域的区域级资源之间设计、构建和测试故障切换及恢复来自行执行资源组合。除了上述可用区级策略（也可以在不同区域中应用）之外，还请考虑以下策略：

• 区域级资源应将数据复制到次要区域、多区域存储选项（如 Cloud Storage）或混合云选项（如 GKE Enterprise）。
• 在制定区域级服务中断缓解措施后，请定期对其进行测试。很糟糕的一种情况是，您原本以为能够应对单区域服务中断，然而发现现实并非如此。

Google Cloud 实现恢复能力和可用性的方法

Google Cloud 会定期超越其可用性设计目标，但您不应认为，这一出色的过往表现就是您可以设计的最低可用性。相反，您应该选择其设计的目标超过应用预期可靠性的 Google Cloud 依赖项，这样应用停机时间加上 Google Cloud 停机时间便会实现您所寻求的结果。

一个精心设计的系统可以回答以下问题：“如果可用区或区域出现 1 分钟、5 分钟、10 分钟或 30 分钟服务中断，会发生什么情况？”您应该在多个层面考虑这一问题，包括：

• 在服务中断期间，我的客户会遇到什么情况？
• 如何检测是否发生服务中断？
• 在服务中断期间，我的应用会发生什么？
• 在服务中断期间，我的数据会发生什么？
• 由于交叉依赖项导致服务中断，我的其他应用会发生什么？
• 在解决服务中断后，我需要做什么才能恢复？谁解决服务中断？
• 我需要在哪个时间段内通知发生服务中断？

为 Google Cloud 中的应用设计灾难恢复的分步指南

前面部分介绍了 Google 如何构建云基础设施，以及用于处理可用区级和区域级服务中断的一些方法。

本部分帮助您开发一个框架，以便您根据所需的可靠性结果将组合原则应用于您的应用。

Google Cloud 中针对灾难恢复目标（例如 RTO 和 RPO）的客户应用必须进行架构设计，以保证业务关键型操作仅受 RTO/RPO 约束，并且只依赖于负责持续处理服务操作的数据平面组件。换句话说，此类客户业务关键型操作不得依赖于管理平面操作，后者管理配置状态并将配置推送到控制平面和数据平面。

例如，打算为业务关键型操作实现 RTO 的 Google Cloud 客户不应依赖 VM-creation API 或 IAM 权限更新。

第 1 步：收集现有要求

第一步是定义应用的可用性要求。大多数公司在这一领域已有一定程度的设计指导，这可能是在公司内部制定的，也可能源自法规或其他法律要求。该设计指导通常会纳入两个关键指标：恢复时间目标 (RTO) 和恢复点目标 (RPO)。在商业术语中，RTO 的意思是“灾难发生后多久应用才能启动和运行”。RPO 的意思是“发生灾难时我可以接受丢失多少数据”。

过去，企业已针对各种灾难事件（从组件故障到地震）定义了 RTO 和 RPO 要求。这在本地环境中很有用，因为在本地环境中规划人员必须通过整个软件和硬件堆栈映射 RTO/RPO 要求。在云端，您无需再定义包含此类详情的要求，因为提供商会负责这一点。相反，您可以根据损失范围（整个可用区或区域）定义 RTO 和 RPO 要求，而无需考虑根本原因。对于 Google Cloud，这可简化您针对以下 3 种场景收集的要求：可用区服务中断、区域服务中断或极不可能发生的多区域服务中断。

由于认识到并不是每个应用都具有相同的重要性，因此大多数客户都会按重要性层级对其应用分类，并且可以根据这些重要性层级应用特定 RTO/RPO 要求。将 RTO/RPO 和应用重要性相结合后，通过回答以下方面的问题可简化设计给定应用架构的过程：

1. 应用需要在同一区域内的多个可用区中运行，还是需要在多个区域内的多个可用区中运行？
2. 应用可以依赖哪些 Google Cloud 产品？

以下是一个要求收集练习的输出示例：

按示例组织 Co 的应用重要性定义的 RTO 和 RPO：

应用重要性	应用百分比	示例应用	可用区服务中断	区域服务中断
层级 1 （最重要）	5%	通常是全球应用或外部面向客户的应用，例如实时付款和电子商务店面。	RTO 为零 RPO Zero	RTO 为零 RPO Zero
层级 2	35%	通常是区域级应用或重要的内部应用，例如 CRM 或 ERP。	RTO 为 15 分钟 RPO 为 15 分钟	RTO 为 1 小时 RPO 为 1 小时
层级 3 （最不重要）	60%	通常是团队或部门应用，例如后台、请假、国内差旅、会计和 HR。	RTO 为 1 小时 RPO 为 1 小时	RTO 为 12 小时 RPO 为 12 小时

第 2 步：将功能映射到可用产品

第二步是了解您的应用将使用的 Google Cloud 产品的恢复能力。大多数公司都会查看相关产品信息，然后添加有关如何修改其架构的指导，以适应产品功能与恢复能力要求之间的差距。本部分介绍了针对此领域的数据和应用限制的一些常见方面和建议。

如前所述，Google 支持灾难恢复的产品广泛适用于两种类型的服务中断范围：区域级和可用区级。部分服务中断的规划方式与对完全服务中断进行灾难恢复采用的方式相同。这会为默认情况下哪些产品适合于每种场景提供一个最初的高层矩阵。

Google Cloud 产品一般功能
（请参阅附录，了解特定产品功能）

	所有 Google Cloud 产品	可跨可用区自动复制的区域级 Google Cloud 产品	可跨区域自动复制的多区域或全球 Google Cloud 产品
可用区内的组件发生故障	覆盖*	覆盖	覆盖
可用区服务中断	未覆盖	覆盖	覆盖
区域服务中断	未覆盖	未覆盖	覆盖

* 除产品文档中所述的具体情况外，所有 Google Cloud 产品均能够应对组件故障。这是典型的情况，产品能够直接访问或静态映射到一个特定硬件（如内存或固态磁盘 (SSD)）。

RPO 如何限制产品选择

在大多数云部署中，数据完整性是针对服务需要考虑的最重要的架构方面。至少某些应用的 RPO 要求为零，这意味着如果发生服务中断，数据不应丢失。这通常需要将数据同步复制到其他可用区或区域。同步复制需要权衡费用和延迟，因此虽然许多 Google Cloud 产品可以在不同可用区之间进行同步复制，但只有少数 Google Cloud 产品可以在不同区域之间进行同步复制。这种费用和复杂性权衡意味着应用内不同类型的数据具有不同的 RPO 值是常见情况。

对于 RPO 大于零的数据，应用可以利用异步复制。如果丢失的数据可以轻松重新创建，或者可以从黄金数据源恢复（如果需要），则可以执行异步复制。如果在预期的可用区级和区域级服务中断期间少量数据丢失是可以接受的权衡，则异步复制也是一个合理的选择。此外，异步复制对以下情况下也很有用：在暂时性服务中断期间，已写入受影响位置但尚未复制到其他位置的数据在服务中断解决后通常变得可用。这意味着，永久性数据丢失的风险低于服务中断期间失去数据访问权限的风险。

关键操作：确定您是否确实需要 RPO 为零，如果需要，确定您是否可以针对部分数据进行此设置，这会大大增加您可以使用的支持灾难恢复的服务范围。在 Google Cloud 中，实现 RPO 为零意味着主要为应用使用区域级产品，默认情况下，这些产品能够应对可用区级但非区域级的服务中断。

RTO 如何限制产品选择

云计算的一个主要优势是能够按需部署基础架构；但是，这与即时部署不同。应用的 RTO 值需要满足应用所用的 Google Cloud 产品的总 RTO，以及您的工程师或 SRE 重启虚拟机或应用组件所必须执行的任何操作。RTO（以分钟为单位）表示设计的应用可以自动从灾难恢复，而无需任何人工干预，或者只需执行最少步骤（例如，将按钮推送到故障切换）。这种系统的费用和复杂性过去一直都非常高，但 Google Cloud 产品（如负载均衡器和实例组）使此设计更加经济实惠和简单。因此，您应该考虑对大多数应用进行自动故障切换和恢复。请注意，为不同区域之间的此类热故障切换设计系统非常复杂且费用高；只有极少数的关键服务能保证这种能力。

大多数应用的 RTO 介于一小时与一天之间，这允许在灾难情况下进行暖故障切换，部分应用组件在备份模式（例如数据库）下始终保持运行，而其他应用组件在发生实际灾难（例如 Web 服务器）时进行扩容。对于这些应用，强烈建议您对扩容事件进行自动处理。RTO 超过一天的服务具有最低重要性，并且通常可以通过备份恢复或从头开始创建。

关键操作：确定您是否确实需要 RTO 为零（接近于零）以进行区域级故障切换，如果需要，确定您是否可以针对部分服务进行此设置。此操作会更改运行和维护服务的费用。

第 3 步：开发您自己的参考架构和指南

建议在最后一步构建您自己的公司专用架构模式，以帮助您的团队标准化灾难恢复方法。大多数 Google Cloud 客户都会为其开发团队提供指南，该指南会将开发团队各自业务恢复能力期望与 Google Cloud 中的两大类服务中断场景相匹配。这样一来，团队可以轻松划分哪些支持灾难恢复的产品适合各重要性级别。

制定产品准则

我们再看一下上面的示例 RTO/RPO 表，假设您有一个指南，其中列出了每个重要性层级默认允许的产品。请注意，虽然某些产品已默认识别为不适合，但您可以随时添加自己的复制和故障切换机制来启用跨可用区或跨区域同步，但此练习不在本文的讨论范围内。该表还链接到有关每个产品的详细信息，以帮助您了解这些产品对管理可用区或区域服务中断的能力。

示例组织 Co 的架构模式示例 - 可用区服务中断恢复能力

Google Cloud 产品	产品是否符合示例组织的可用区级服务中断要求（根据相应的产品配置）
	层级 1	层级 2	层级 3
Compute Engine	否	否	否
Dataflow	否	否	否
BigQuery	否	否	是
GKE	是	是	是
Cloud Storage	是	是	是
Cloud SQL	否	是	是
Spanner	是	是	是
Cloud Load Balancing	是	是	是

此表是仅基于上述假设性层级的示例。

示例组织 Co 的架构模式示例 - 区域服务中断恢复能力

Google Cloud 产品	产品是否符合示例组织的区域级服务中断要求（根据相应的产品配置）
	层级 1	层级 2	层级 3
Compute Engine	是	是	是
Dataflow	否	否	否
BigQuery	否	否	是
GKE	是	是	是
Cloud Storage	否	否	否
Cloud SQL	否	是	是
Spanner	是	是	是
Cloud Load Balancing	是	是	是

此表是仅基于上述假设性层级的示例。

为展示如何使用这些产品，以下部分逐步介绍了每个假设性应用重要性级别对应的一些参考架构。这些是有针对性的简要说明，介绍了关键的架构决策，并不代表完整的解决方案设计。

层级 3 架构示例

应用重要性	可用区服务中断	区域服务中断
层级 3 （最不重要）	RTO 为 12 小时 RPO 为 24 小时	RTO 为 28 天 RPO 为 24 小时

（灰显图标表示要启用恢复的基础架构）

此架构描述了传统的客户端/服务器应用：内部用户连接到在由永久性存储数据库支持的计算实例上运行的应用。

请务必注意，此架构所支持的 RTO 和 RPO 值比所需的高。但是，如果其他手动步骤可能费用很高或不可靠，您还应考虑将这些步骤消除。例如，从夜间备份恢复数据库可支持 24 小时的 RPO，但这通常需要可能无法空闲的有技能的人员（例如数据库管理员），尤其是多个服务同时受影响的情况下。借助 Google Cloud 的按需基础架构，您可以实现此功能而无需进行主要的费用权衡取舍，因此该架构对可用区级服务中断使用 Cloud SQL 高可用性，而不是使用手动备份/恢复。

针对可用区服务中断的关键架构决策 - RTO 为 12 小时，RPO 为 24 小时：

• 使用内部负载均衡器为用户提供可扩缩的接入点，从而支持自动故障切换至其他可用区。尽管 RTO 为 12 小时，手动更改 IP 地址甚至是 DNS 更新所花费的时间都可能比预期要长。
• 区域级托管式实例组配置有多个可用区但资源最少。这样可以优化费用，但仍支持虚拟机在备份可用区中快速扩容。
• 高可用性 Cloud SQL 配置允许自动故障切换到其他可用区。重新创建和恢复数据库比重新创建和恢复 Compute Engine 虚拟机要困难得多。

针对区域服务中断的关键架构决策 - RTO 为 28 小时，RPO 为 24 小时：

• 仅在发生区域级服务中断时才会在区域 2 中构建负载均衡器。使用 Cloud DNS 提供已编排但手动区域级故障切换功能，因为区域 2 中的基础架构仅在发生区域服务中断时可用。
• 仅在发生区域服务中断时才会构建新的托管式实例组。这可以优化费用，但如果大部分区域级服务中断时间较短，则不太可能调用新的托管式实例组。请注意，为简单起见，上图未显示重新部署或复制必要的 Compute Engine 映像所需的关联工具。
• 系统会重新创建一个新的 Cloud SQL 实例，并通过备份恢复数据。同样，某区域发生长时间服务中断的风险极低，因此这是另一种费用优化权衡。
• 使用多区域级 Cloud Storage 存储这些备份。这可在 RTO 和 RPO 内提供自动可用区和区域级恢复能力。

层级 2 架构示例

应用重要性	可用区服务中断	区域服务中断
层级 2	RTO 为 4 小时 RPO 为零	RTO 为 24 小时 RPO 为 4 小时

此架构描述了一个内部用户在其中连接到计算实例可视化层的数据仓库，以及一个填充后端数据仓库的数据提取和转换层。

此架构的某些单独的组件不直接支持其层级所要求的 RPO。但是，由于这些组件结合使用的方式，整体服务符合 RPO 要求。在本示例中，由于 Dataflow 是可用区级产品，因此请遵循高可用性设计的建议，以防止在服务中断期间丢失数据。不过，Cloud Storage 层是黄金数据源并支持 RPO 为零。因此，在可用区 a 发生服务中断时，您可以使用可用区 b 将任何丢失的数据重新提取到 BigQuery 中。

针对可用区服务中断的关键架构决策 - RTO 为 4 小时，RPO 为零：

• 使用负载均衡器为用户提供可扩缩的接入点，从而支持自动故障切换至其他可用区。尽管 RTO 为 4 小时，手动更改 IP 地址甚至是 DNS 更新所花费的时间都可能比预期要长。
• 数据可视化计算层的区域级托管式实例组配置有多个可用区但资源最少。这样可以优化费用，但仍支持虚拟机快速扩容。
• 区域级 Cloud Storage 用作最初数据提取的暂存层，从而提供自动可用区恢复能力。
• 使用 Dataflow 从 Cloud Storage 中提取数据并转换数据，然后将其加载至 BigQuery。在某个可用区发生服务中断时，这是一个无状态过程，可在其他可用区中重启。
• BigQuery 为数据可视化前端提供数据仓库后端。发生可用区服务中断时，任何丢失的数据都将从 Cloud Storage 中重新提取。

针对区域服务中断的关键架构决策 - RTO 为 24 小时，RPO 为 4 小时：

• 使用每个区域中的负载均衡器为用户提供可扩缩的接入点。使用 Cloud DNS 提供已编排但手动区域级故障切换功能，因为区域 2 中的基础架构仅在发生区域服务中断时可用。
• 数据可视化计算层的区域级托管式实例组配置有多个可用区但资源最少。在负载均衡器重新配置之前，该实例组无法访问，但不需要手动干预。
• 区域级 Cloud Storage 用作最初数据提取的暂存层。这会同时加载到两个区域，以满足 RPO 要求。
• 使用 Dataflow 从 Cloud Storage 中提取数据并转换数据，然后将其加载至 BigQuery。发生区域服务中断时，将使用 Cloud Storage 中的最新数据填充 BigQuery。
• BigQuery 提供数据仓库后端。在正常操作下，数据仓库后端会间歇性进行刷新。发生区域服务中断时，最新数据将通过 Dataflow 从 Cloud Storage 中重新提取。

层级 1 架构示例

应用重要性	可用区服务中断	区域服务中断
层级 1 （最重要）	RTO 为零 RPO 为零	RTO 为 4 小时 RPO 为 1 小时

此架构描述了一个外部用户在其中连接到 GKE 中运行的一组微服务的移动应用后端基础架构。Spanner 为实时数据提供后端数据存储层，历史数据会流式传输到每个区域中的 BigQuery 数据湖。

同样，此架构的某些单独的组件不直接支持其层级所要求的 RPO；但是，由于这些组件结合使用的方式，整体服务符合 RPO 要求。在本示例中，BigQuery 用于分析查询。系统会同时从 Spanner 中为每个区域输送数据。

针对可用区服务中断的关键架构决策 - RTO 为零，RPO 为零：

• 使用负载均衡器为用户提供可扩缩的接入点，从而支持自动故障切换至其他可用区。
• 区域级 GKE 集群用于配置有多个可用区的应用层。 这样可在每个区域内实现 RTO 为零。
• 多区域 Spanner 用作数据持久层，从而提供自动可用区级数据恢复能力和事务一致性。
• BigQuery 为应用提供分析功能。系统会单独从 Spanner 为每个区域输送数据，并且应用会单独访问每个区域。

针对区域服务中断的关键架构决策 - RTO 为 4 小时，RPO 为 1 小时：

• 使用负载均衡器为用户提供可扩缩的接入点，从而支持自动故障切换至其他区域。
• 区域级 GKE 集群用于配置有多个可用区的应用层。 在发生区域服务中断时，备用区域中的集群会自动扩缩以应对额外的处理负载。
• 多区域级 Spanner 用作数据持久层，从而提供自动区域级数据恢复能力和事务一致性。这是实现跨区域 RPO 为 1 小时的关键组件。
• BigQuery 为应用提供分析功能。系统会单独从 Spanner 为每个区域输送数据，并且应用会单独访问每个区域。此架构可弥补 BigQuery 组件的不足，使其满足整体应用要求。

附录：产品参考

本部分介绍了客户应用中最常使用并且可轻松利用来满足灾难恢复需求的 Google Cloud 产品的架构和灾难恢复功能。

共同主题

许多 Google Cloud 产品提供单区域或多区域配置。区域级产品能够应对可用区服务中断，多区域产品和全球产品能够应对区域服务中断。一般来说，这意味着在服务中断期间，应用遇到中断情况最少。Google 可通过一些常见架构方法实现这些结果，这反映了上述架构指导。

• 冗余部署：应用后端和数据存储部署在一个区域内的多个可用区中，以及一个多区域位置内的多个可用区中。

• 数据复制：产品在冗余位置之间使用同步或异步复制。

  • 同步复制表示当您的应用进行 API 调用来创建或修改由产品存储的数据时，只有在产品将数据写入多个位置后，您的应用才会收到成功响应。同步复制可确保您在 Google Cloud 基础架构服务中断期间不会失去对任何数据的访问权限，因为您可以在一个可用的后端位置获取所有数据。

    虽然此方法可最大程度保护数据，但它可能会在延迟和性能方面进行权衡。使用同步复制的多区域产品在这方面的权衡最为显著，通常大约出现 10 秒或 100 秒的额外延迟。

  • 异步复制表示当您的应用进行 API 调用来创建或修改由产品存储的数据时，在产品将数据写入一个位置后，您的应用就会收到成功响应。写入请求之后，产品会将数据复制到其他位置。

    此方法在 API 可提供比同步复制更低的延迟和更高的吞吐量，但要以牺牲数据保护为代价。如果写入数据的位置在复制完成之前发生了服务中断，则在该位置服务中断得到解决之前，您会失去对该数据的访问权限。

• 通过负载均衡处理服务中断：Google Cloud 使用软件负载均衡将请求路由到适当的应用后端。与 DNS 负载均衡等其他方法相比，此方法可缩短服务中断的系统响应时间。当 Google Cloud 位置发生服务中断时，负载均衡器会快速检测到该位置部署的后端已变为“运行状况不佳”，并将所有请求定向到备用位置中的后端。这样，产品就可以在某位置发生服务中断期间继续处理您的应用的请求。该位置的服务中断解决后，负载均衡器会检测该位置的产品后端的可用性，并继续在该位置发送流量。

Access Context Manager

利用 Access Context Manager，企业可配置与根据请求特性制定的政策相对应的访问权限级别。系统会按照区域制作政策的镜像。

如果某个可用区发生服务中断故障，则系统会自动、透明地从该区域中的其他可用区传送对不可用的可用区的请求。

如果某个区域发生服务中断故障，则在该区域再次可用之前，来自受影响区域的政策计算将不可用。

Access Transparency

Access Transparency 可让 Google Cloud 组织管理员为 Google Cloud 中的项目和资源定义基于属性的精细访问权限控制。有时，Google 必须出于管理目的访问客户数据。当我们访问客户数据时，Access Transparency 会向受影响的 Google Cloud 客户提供访问日志。这些 Access Transparency 日志有助于确保 Google 致力于保证数据安全以及数据处理透明度。

Access Transparency 能够适应可用区和区域服务中断。如果发生可用区或区域服务中断，Access Transparency 会继续处理另一个可用区或区域中的管理访问日志。

AlloyDB for PostgreSQL

AlloyDB for PostgreSQL 是一种与 PostgreSQL 兼容的全托管式数据库服务。AlloyDB for PostgreSQL 通过其位于一个区域的两个不同可用区的主实例的冗余节点，在区域内提供高可用性。如果活跃可用区遇到问题，则主实例会通过触发到备用可用区的自动故障切换来保持区域可用性。区域存储可保证在单可用区丢失时的数据耐用性。

作为灾难恢复的进一步方法，AlloyDB for PostgreSQL 使用跨区域复制功能，通过将主集群的数据异步复制到位于不同 Google Cloud 区域的次要集群来提供灾难恢复功能。

可用区级服务中断：在正常运行期间，高可用性主实例的两个节点中只有一个处于活跃状态，并且会提供所有数据写入操作。此活跃节点将数据存储在集群的单独区域存储层中。

AlloyDB for PostgreSQL 会自动检测可用区级故障并触发故障切换以恢复数据库可用性。在故障切换期间，AlloyDB for PostgreSQL 会在备用节点上启动数据库，而该节点已在其他可用区中预配。新的数据库连接会自动路由到此可用区。

从客户端应用的角度来看，可用区服务中断类似于网络连接的暂时性中断。故障切换完成后，客户端可以使用相同凭据重新连接到同一地址的实例，且不会丢失数据。

区域服务中断：跨区域复制使用异步复制功能，可让主实例在副本实例提交事务之前先提交事务。事务在主实例上提交与在副本上提交之间的时间差称为“复制延迟时间”。主实例生成预写式日志 (WAL) 与 WAL 到达副本之间的时间差称为“刷新延迟”。复制延迟和刷新延迟取决于数据库实例配置和用户生成的工作负载。

在发生区域级服务中断时，您可以将其他区域中的次要集群提升为可写的独立主集群。此提升集群不再从其先前关联的原始主集群复制数据。由于刷新延迟，可能会发生一些数据丢失，因为原始主实例上可能存在未传播到次要集群的事务。

跨区域复制 RPO 会受到主要集群的 CPU 利用率以及主要集群所在区域和次要集群所在区域之间的物理距离的影响。为了优化 RPO，我们建议您使用包含副本的配置来测试工作负载，以确定每秒安全事务数 (TPS) 上限，即不会使刷新延迟时间累积的最佳持续 TPS。如果您的工作负载超过安全 TPS 上限，则刷新延迟时间会受到累积，这可能会影响 RPO。要限制网络延迟，请选择同一大洲内的区域对。

如需详细了解如何监控网络延迟和其他 AlloyDB for PostgreSQL 指标，请参阅监控实例。

Anti Money Laundering AI

Anti Money Laundering AI (AML AI) 提供了一个 API，可帮助全球金融机构更有效地检测洗钱。Anti Money Laundering AI 是区域级产品，这意味着客户可以选择区域，但不能选择构成区域的可用区。系统会在一个区域内的多个可用区之间自动平衡数据和流量。这些操作（例如，创建流水线或运行预测）会在后台自动扩缩，并根据需要跨可用区进行负载均衡。

可用区级服务中断：AML AI 会在区域范围内存储其资源的数据，并以同步方式复制。长时间运行的操作成功完成后，无论可用区故障是什么，都可以依赖资源。处理还会跨可用区复制，但这种复制针对的是负载均衡而不是高可用性，因此操作期间的可用区故障可能会导致操作失败。如果发生这种情况，重试操作可以解决问题。在可用区服务中断期间，处理时间可能会受到影响。

区域级服务中断：客户选择要在其中创建 AML AI 资源的 Google Cloud 区域。数据绝不会跨区域复制。AML AI 绝不会将客户流量路由到其他区域。如果发生区域级故障，AML AI 将在服务中断问题得到解决后立即恢复可用。

API 密钥

API 密钥可为项目提供可扩缩的 API 密钥资源管理。 API 密钥属于全球性服务，这意味着可从任何 Google Cloud 位置查看和访问密钥。其数据和元数据以冗余方式存储在多个可用区和区域。

API 密钥可灵活应对可用区和区域服务中断。如果发生可用区服务中断或区域服务中断，API 密钥会继续处理来自同一区域或不同区域中的其他可用区的请求。

如需详细了解 API 密钥，请参阅 API 密钥 API 概览。

Apigee

Apigee 提供了一个安全、可扩缩且可靠的平台，可用于开发和管理 API。Apigee 提供单区域和多区域部署。

可用区级服务中断：客户运行时数据会在多个可用区之间复制。因此，单可用区服务中断不会影响 Apigee。

区域级服务中断：对于单区域 Apigee 实例，如果一个区域发生故障，则 Apigee 实例在该区域中不可用，并且无法恢复到不同的区域。对于多区域 Apigee 实例，数据会异步复制到所有区域。因此，一个区域发生故障并不会完全减少流量。但是，您可能无法访问发生故障的区域中的未提交数据。您可以将流量从健康状况不佳的区域迁出。为了实现自动流量故障切换，您可以使用代管式实例组 (MIG) 配置网络路由。

AutoML Translation

AutoML Translation 是一项机器翻译服务，可让您导入自己的数据（句子对）来训练特定领域的自定义模型。

可用区级服务中断：AutoML Translation 在多个可用区和区域中具有活跃的计算服务器。它还支持跨区域内的各可用区进行同步数据复制。这些功能有助于 AutoML Translation 实现即时故障切换，并且不会在可用区发生故障时丢失任何数据，也不需要客户执行任何输入或调整操作。

区域级服务中断：如果发生区域级故障，则 AutoML Translation 不可用。

AutoML Vision

AutoML Vision 是 Vertex AI 的一部分。它提供了一个统一的框架来创建数据集、导入数据、训练模型以及为在线预测和批量预测提供模型。

AutoML Vision 是一项区域性服务。客户可以选择他们想要从哪个区域启动作业，但不能选择该区域内的特定可用区。该服务会自动在区域内的不同可用区之间对工作负载进行负载均衡。

可用区级服务中断：AutoML Vision 会在区域范围内存储作业的元数据，并在该区域内的各个可用区之间同步写入。作业会在 Cloud Load Balancing 选择的特定可用区中启动。

• AutoML Vision 训练作业：可用区服务中断会导致所有正在运行的作业失败，并且作业状态会更新为“失败”。如果作业失败，请重试 。新作业会路由到可用区。

• AutoML Vision 批量预测作业：批量预测是基于 Vertex AI 批量预测构建的。当发生区域中断时，该服务会通过将作业路由到可用区来自动重试该作业。如果多次重试失败，则作业状态会更新为“失败”。运行该作业的后续用户请求将被路由到可用的可用区。

区域级服务中断：客户选择要在其中运行训练作业的 Google Cloud 区域。数据绝不会跨区域复制。如果发生区域级故障，则 AutoML Vision 服务在该区域中不可用。服务中断解决后，批量预测会恢复可用。我们建议客户使用多个区域来运行作业。如果发生区域级服务中断，请将作业定向到其他可用区域。

批量

Batch 是一项全托管式服务，可在 Google Cloud 上将批量作业加入队列、安排以及执行批量作业。Batch 设置在区域级别定义。客户必须选择一个区域（而不是区域中的一个可用区）来提交其批量作业。提交作业后，Batch 会将客户数据同步写入多个可用区。但是，客户可以指定 Batch 虚拟机在其中运行作业的可用区。

可用区级故障：如果一个可用区发生故障，则该可用区中运行的任务也会失败。如果任务具有重试设置，则 Batch 会自动将这些任务故障切换到同一区域中的其他活跃可用区。自动故障切换取决于同一区域内活跃可用区中的资源的可用性。需要仅在故障可用区提供的可用区级资源（例如虚拟机、GPU 或可用区级永久性磁盘）的作业会排入队列，直到故障可用区恢复或达到作业的排队超时时间。如果可能，我们建议客户让 Batch 选择可用区级资源来运行其作业。这样做有助于确保作业能够应对可用区级服务中断。

区域级故障：如果发生区域级故障，则服务控制平面在该区域中不可用。该服务不会跨区域复制数据或重定向请求。我们建议客户使用多个区域来运行其作业，并在某个区域发生故障时将作业重定向到其他区域。

Chrome Enterprise 进阶版威胁和数据保护

Chrome Enterprise 进阶版威胁防护和数据保护功能是 Chrome Enterprise 进阶版解决方案的一部分。它扩展了 Chrome 的各种安全功能，包括恶意软件和钓鱼式攻击防护、数据泄露防护 (DLP)、网址过滤规则和安全报告。

Chrome Enterprise 进阶版管理员可以选择将违反 DLP 或恶意软件政策的客户核心内容存储到 Google Workspace 规则日志事件和/或 Cloud Storage 中，以便日后进行调查。Google Workspace 规则日志事件由多区域 Spanner 数据库提供支持。Chrome Enterprise 进阶版最长可能需要几个小时才能检测到违规行为。在此期间，任何未处理的数据都可能因可用区或区域故障而丢失。一旦检测到违规行为，违反您政策的内容就会写入 Google Workspace 规则日志事件和/或 Cloud Storage。

可用区和区域服务中断：由于 Chrome Enterprise 进阶版威胁防范和数据保护是多可用区级和多区域级的，因此它可以在可用区或区域的计划外完全丢失后继续运行，而不会影响可用性。它通过将流量重定向到其他可用区或区域中的服务来提供这种可靠性。但是，由于 Chrome Enterprise 进阶版威胁和数据保护可能需要几个小时才能检测到 DLP 和恶意软件违规行为，因此特定可用区或区域中任何未处理的数据都可能因可用区或区域中断而丢失。

BigQuery

BigQuery 是一个无服务器、扩缩能力极强且经济实惠的云数据仓库，旨在提升您的业务敏捷性。BigQuery 支持用户数据集的以下位置类型：

• 单区域：特定的地理位置，例如爱荷华州 (us-central1) 或蒙特利尔 (northamerica-northeast1)。
• 多区域：包含两个或更多地理位置的大型地理区域，例如美国 (US) 或欧洲 (EU)。

无论哪种情况，数据都会以冗余方式存储在所选位置的单个区域内两个可用区中。写入 BigQuery 的数据会同步写入主要可用区和次要可用区。这样可以防止该区域内的单个可用区不可用，但无法阻止区域级服务中断。

Binary Authorization

Binary Authorization 是适用于 GKE 和 Cloud Run 的软件供应链安全产品。

所有 Binary Authorization 政策会在每个区域内的多个可用区中复制。复制可帮助 Binary Authorization 政策读取操作从其他区域的故障中恢复。复制还可确保读取操作能够容忍每个区域内的可用区故障。

Binary Authorization 强制执行操作可以应对可用区级服务中断，但无法应对区域级服务中断。强制执行操作在发出请求的 GKE 集群或 Cloud Run 作业所在的区域中运行。因此，在发生区域服务中断的情况下，没有任何发出 Binary Authorization 强制执行请求的操作可以运行。

Certificate Manager

通过 Certificate Manager，您可以获取和管理传输层安全协议 (TLS) 证书，以便与不同类型的 Cloud Load Balancing 搭配使用。

如果发生可用区级服务中断故障，区域和全球 Certificate Manager 可以应对可用区级故障，因为作业和数据库冗余分部在一个区域内的多个可用区中。如果发生区域级服务中断故障，全球 Certificate Manager 可以应对区域级故障，因为作业和数据库冗余分布在多个区域中。区域级 Certificate Manager 是区域级产品，因此无法承受区域级故障。

Cloud Intrusion Detection System

Cloud Intrusion Detection System (Cloud IDS) 是一项可用区级服务，可提供可用区范围的 IDS 端点，这种端点处理一个特定可用区中的虚拟机流量，因此无法容忍可用区或区域服务中断。

可用区性服务中断：Cloud IDS 与虚拟机实例相关联。如果客户计划通过在多个可用区中部署虚拟机（手动或通过区域托管式实例组）来缓解可用区性服务中断，则还需要在这些可用区中部署 Cloud IDS 端点。

区域性服务中断：Cloud IDS 是区域性产品。它不提供任何跨区域功能。区域性故障将关闭该区域的所有可用区中的所有 Cloud IDS 功能。

Google Security Operations SIEM

Google Security Operations SIEM（属于 Google Security Operations）是一项全代管式服务，可帮助安全团队检测、调查和应对威胁。

Google Security Operations SIEM 提供单区域和多区域产品。

• 在区域级产品中，数据和流量会在所选区域内的各可用区之间自动进行负载均衡，并且数据会跨区域内的各可用区以冗余方式存储。

• 多区域是地理位置冗余的。与 Regional Storage 相比，该冗余可提供更广泛的保护。它还有助于确保即使整个区域丢失，服务仍可继续正常运行。

• 大多数数据注入路径会跨多个位置同步复制客户数据。异步复制数据时，会有一个时间范围（恢复点目标 [RPO]），在此期间数据尚未跨多个位置进行复制。在多区域部署中使用 Feed 进行注入时就会出现这种情况。在 RPO 之后，数据在多个位置中可用。

可用区级服务中断：

• 区域级部署：请求从该区域内的任何可用区传送。数据会跨多个可用区同步复制。如果发生全可用区服务中断，其余可用区会继续处理流量并继续处理数据。Google Security Operations SIEM 的冗余预配和自动扩缩有助于确保在负载转移期间服务在其余可用区中保持运行。

• 多区域部署：可用区级服务中断等同于区域级服务中断。

区域服务中断：

• 区域级部署：Google Security Operations SIEM 将所有客户数据存储在单个区域内，并且流量绝不会跨区域路由。如果发生区域级服务中断，Google Security Operations SIEM 在该区域中不可用，直到服务中断得到解决。

• 多区域部署（无 Feed）：请求从多区域部署的任何区域传送。数据会跨多个区域同步复制。如果发生全区域服务中断，其余区域会继续处理流量并继续处理数据。Google Security Operations SIEM 的冗余预配和自动扩缩有助于确保服务在这些负载转移期间在其余区域中保持运行。

• 多区域部署（具有 Feed）：请求从多区域部署的任何区域传送。数据按照提供的 RPO 跨多个区域异步复制。如果发生全区域服务中断，则只有 RPO 后存储的数据在其余区域中可用。RPO 窗口中的数据可能不会复制。

Cloud Asset Inventory

Cloud Asset Inventory 是一种高性能、弹性佳的全球服务，用于维护 Google Cloud 资源和政策元数据的仓库。Cloud Asset Inventory 提供搜索和分析工具，可帮助您跨组织、文件夹和项目跟踪已部署的资产。

如果某个可用区发生服务中断故障，Cloud Asset Inventory 会继续处理来自同一区域或不同区域中的其他可用区的请求。

如果某个区域发生服务中断故障，则 Cloud Asset Inventory 会继续处理来自其他区域的请求。

Bigtable

Bigtable 是一种全托管式高性能 NoSQL 数据库服务，用于处理大规模分析和运营工作负载。

Bigtable 复制概览

Bigtable 提供灵活且可全面配置的复制功能，该功能可用于将数据复制到多个区域中的集群或同一区域内的多个可用区，从而提高数据的可用性和耐用性。当您使用复制功能时，Bigtable 还可以为请求提供自动故障切换。

将多可用区或多区域配置与多集群路由结合使用时，如果发生可用区级或区域级服务中断，Bigtable 会自动重新路由流量并从最近的可用集群处理请求。由于 Bigtable 复制功能是异步的，并且具有最终一致性，因此对最近发生服务中断位置的数据的更改如果尚未复制到其他位置，则可能无法获得这些更改。

性能考虑因素

重要提示：您必须确保 CPU 利用率和数据大小不超过建议的最大值，并且您的集群必须始终预配足够的资源，以便复制以可预测的方式执行。

当 CPU 资源需求超过可用节点容量时，Bigtable 会始终优先处理复制请求之前传入的请求。

如需详细了解如何在工作负载中使用 Bigtable 复制，请参阅 Cloud Bigtable 复制概览和复制设置示例。

Bigtable 节点用于处理传入请求以及复制其他集群的数据。除了保持每个集群有足够的节点数之外，您还必须确保应用使用正确的架构设计以避免热点，热点可能导致 CPU 利用率过高或不平衡以及复制延迟时间增加。

如需详细了解如何设计应用架构以最大限度地提高 Bigtable 性能和效率，请参阅架构设计最佳实践。

监控

Bigtable 提供了多种方法来使用 Google Cloud 控制台中提供的复制图表直观地监控实例和集群的复制延迟时间。

您还可以使用 Cloud Monitoring API 以编程方式监控 Bigtable 复制指标。

Certificate Authority Service

借助 Certificate Authority Service (CA Service)，客户可以简化、自动执行和自定义私有证书授权机构 (CA) 的部署、管理和安全维护，并以富有弹性的方式大规模颁发证书。

可用区级服务中断：CA Service 能够应对可用区级故障，因为它的控制平面在一个区域内的多个可用区中是冗余的。如果发生可用区级服务中断，CA Service 会继续不间断地处理来自同一区域内其他可用区的请求。由于数据是同步复制的，因此不会造成数据丢失或损坏。

区域级服务中断：CA Service 是区域级产品，因此无法承受区域级故障。如果您需要能够应对区域级故障，请在两个不同的区域中创建颁发 CA。在需要证书的区域中创建主要颁发 CA。在其他区域中创建后备 CA。在主要从属 CA 的区域发生服务中断时使用后备 CA。如有需要，两个 CA 都可以链接到同一根 CA。

Cloud Billing

Cloud Billing API 可让开发者以程序化方式管理其 Google Cloud 项目的结算。Cloud Billing API 设计为一个全球系统，可将更新同步写入多个区域和可用区。

可用区级或区域级故障：Cloud Billing API 会自动故障切换到其他可用区或区域。个别请求可能会失败，但重试政策应允许后续尝试成功。

Cloud Build

Cloud Build 服务让您在 Google Cloud 上执行构建。

Cloud Build 由区域隔离的实例组成，这些实例在区域内的各可用区之间同步复制数据。我们建议您使用特定的 Google Cloud 区域（而非全球区域），并确保您的构建使用的资源（包括日志存储桶、Artifact Registry 代码库等）位于运行您的构建的区域中。

如果某个可用区发生服务中断故障，则控制平面操作不受影响。但是，故障可用区内当前正在执行的构建将会延迟或永久丢失。新触发的构建将自动分发到其余正常运行的可用区。

如果发生区域级故障，则控制平面将离线，并且当前正在执行的构建将延迟或永久丢失。触发器、工作器池和构建数据绝不会跨区域复制。我们建议您在多个区域中准备触发器和工作器池，以便更轻松地缓解服务中断故障。

Cloud CDN

Cloud CDN 跨 Google 网络上的许多位置分发和缓存内容，以缩短客户端的传送延迟时间。系统会尽力而为地传送缓存内容，如果 Cloud CDN 缓存无法响应请求，请求将被转发到源服务器，例如存储原始内容的后端虚拟机或 Cloud Storage 存储桶。

当某个可用区或区域发生故障时，受影响的位置的缓存将不可用。入站请求会被路由到可用的 Google 边缘位置和缓存。如果这些备用缓存无法响应请求，则会将请求转发到可用的源服务器。如果服务器可以使用最新数据响应请求，则不会丢失内容。缓存未命中率的增加会导致源服务器由于缓存被填满而出现高于正常水平的流量。后续请求将由不受该可用区或区域服务中断影响的缓存进行响应。

如需详细了解 Cloud CDN 和缓存行为，请参阅 Cloud CDN 文档。

Cloud Composer

Cloud Composer 是一项托管式工作流编排服务，可让您创建、安排、监控和管理跨越多个云平台和本地数据中心的工作流。Cloud Composer 环境基于 Apache Airflow 开源项目构建。

Cloud Composer API 可用性不受可用区不可用的影响。在可用区级服务中断期间，您可以保留对 Cloud Composer API 的访问权限，包括可以创建新的 Cloud Composer 环境。

Cloud Composer 环境的架构中含有一个 GKE 集群。在可用区级服务中断期间，集群上的工作流可能会中断：

• 在 Cloud Composer 1 中，环境的集群是可用区级资源，因此可用区级服务中断可能会使集群不可用。服务中断时执行的工作流可能会在完成之前停止。
• 在 Cloud Composer 2 中，环境的集群是区域级资源。但是，在受可用区级服务中断影响的可用区中的节点上执行的工作流可能会在完成之前停止。

在这两种版本的 Cloud Composer 中，可用区服务中断都可能导致已部分执行的工作流（包括工作流配置为由您完成的任何外部操作）停止执行。这样可能会导致外部不一致，具体取决于工作流，例如，工作流在多步骤执行过程中停止来修改外部数据存储区。因此，在设计 Airflow 工作流时，您应考虑恢复流程，包括如何检测部分未执行的工作流的状态以及修复任何部分数据更改。

在 Cloud Composer 1 中，在可用区服务中断期间，您可以选择在另一个可用区中启动新的 Cloud Composer 环境。由于 Airflow 将工作流的状态保留在其元数据数据库中，因此将此信息转移到新的 Cloud Composer 环境可能需要执行其他步骤并做好准备。

在 Cloud Composer 2 中，您可以提前设置使用环境快照进行灾难恢复，从而解决可用区服务中断故障。在发生可用区服务中断期间，您可以使用环境快照来转移工作流的状态，从而切换到其他环境。只有 Cloud Composer 2 支持使用环境快照进行灾难恢复。

Cloud Data Fusion

Cloud Data Fusion 是一项全托管式企业数据集成服务，用于快速构建和管理数据流水线。它提供了三个版本。

• 可用区级服务中断会影响开发者版实例。

• 区域级服务中断会影响基本和企业版实例。

要控制对资源的访问权限，您可以在单独的环境中设计和运行流水线。这种分离可让您一次性设计流水线，然后在多个环境中运行该流水线。您可以在两个环境中恢复流水线。如需了解详情，请参阅备份和恢复实例数据。

以下建议同时适用于区域级和可用区级服务中断。

流水线设计环境中的服务中断

在设计环境中，保存流水线草稿以应对服务中断的情况。根据具体的 RTO 和 RPO 要求，您可以在服务中断期间使用已保存的草稿在不同的 Cloud Data Fusion 实例中恢复流水线。

流水线执行环境中的服务中断

在执行环境中，您可以使用 Cloud Data Fusion 触发器或时间表在内部启动流水线，也可以使用 Cloud Composer 等编排工具在外部启动流水线。为了能够恢复流水线的运行时配置，请备份流水线和配置，例如插件和时间表。在服务中断时，您可以使用备份来复制未受影响的区域或可用区中的实例。

准备应对服务中断的另一种方法是，在多个区域中设置多个具有相同配置和流水线的实例。如果您使用外部编排，则正在运行的流水线可以在实例之间自动进行负载均衡。请特别注意，确保没有资源（例如数据源或编排工具）与单个区域绑定并供所有实例使用，因为这可能会成为服务中断的故障中心点。例如，您可以在不同区域中拥有多个实例，并使用 Cloud Load Balancing 和 Cloud DNS 将流水线运行请求定向到不受服务中断影响的实例（请参阅示例层级 1和层级 3 架构）。

流水线中其他 Google Cloud 数据服务的中断

您的实例可能会使用其他 Google Cloud 服务作为数据源或流水线执行环境，例如 Dataproc、Cloud Storage 或 BigQuery。这些服务可以位于不同的区域。如果需要跨区域执行，则任一区域发生故障都会导致服务中断。在这种情况下，请遵循标准灾难恢复步骤，但请注意，将关键服务分布在不同区域的跨区域设置的弹性较低。

Cloud Deploy

Cloud Deploy 将工作负载持续交付到 GKE 和 Cloud Run 等运行时服务。该服务由跨区域内的各可用区同步复制数据的区域实例组成。

可用区级服务中断：控制平面操作不受影响。但是，在可用区发生故障时运行的 Cloud Build 构建（例如呈现或部署操作）会延迟或永久丢失。在服务中断期间，触发构建的 Cloud Deploy 资源（版本或发布）会显示失败状态，表示底层操作失败。您可以重新创建资源，以在其余正常运行的可用区中启动新的构建。例如，通过将版本重新部署到目标来创建新发布。

区域服务中断：在恢复区域之前，控制平面操作以及来自 Cloud Deploy 的数据都不可用。为了在发生区域服务中断时更轻松地恢复服务，我们建议您将交付流水线和目标定义存储在源代码控制中。您可以使用这些配置文件在正常运行的区域中重新创建 Cloud Deploy 流水线。在服务中断期间，有关现有版本的数据将丢失。创建新版本以继续将软件部署到目标。

Cloud DNS

Cloud DNS 是一种高性能、高弹性的全球域名系统 (DNS) 服务，也是将您的域名发布到全球 DNS 的一种经济实惠的方式。

如果某个可用区发生服务中断，Cloud DNS 将不间断地继续处理来自同一区域或不同区域中的其他可用区的请求。对 Cloud DNS 记录的更新会在接收它们的区域内跨可用区同步复制。因此，不会丢失数据。

如果某个区域发生服务中断，Cloud DNS 会继续传送来自其他区域的请求。Cloud DNS 记录的最近更新有可能不可用，因为更新首先在单个区域中进行处理，然后再异步复制到其他区域。

Cloud Functions

Cloud Functions 是一个无状态计算环境，在此环境中，客户可以在 Google 的基础架构上运行其函数代码。Cloud Functions 是区域级产品，这意味着客户可以选择区域，但不能选择构成区域的可用区。系统会在一个区域内的多个可用区之间自动平衡数据和流量。函数会自动扩缩以满足传入的流量，并在需要时跨可用区进行负载均衡。每个可用区都维护一个为每个可用区提供此自动扩缩功能的调度器。它还考虑其他可用区正在接收的负载，并将在可用区内预配额外的容量来应对任何可用区级故障。

可用区级服务中断：Cloud Functions 会存储元数据以及已部署的函数。此数据按照区域来存储并同步写入。只有在数据被提交到区域内的仲裁后，Cloud Functions Admin API 才会返回 API 调用。由于数据按区域存储，因此数据平面操作也不受可用区级故障的影响。 如果发生可用区级故障，流量会自动路由到其他可用区。

区域级服务中断：客户选择要在其中创建函数的 Google Cloud 区域。数据绝不会跨区域复制。Cloud Functions 绝不会将客户流量路由到其他区域。如果发生区域级故障，Cloud Functions 将在服务中断问题得到解决后立即恢复可用。建议客户部署到多个区域，并根据需要使用 Cloud Load Balancing 实现更高的可用性。

Cloud Healthcare API

Cloud Healthcare API 是一项用于存储和管理医疗保健数据的服务，旨在提供高可用性并针对可用区级和区域级故障提供保护（具体取决于所选配置）。

区域级配置：在其默认配置中，Cloud Healthcare API 会针对可用区级故障提供保护。服务会被部署到一个区域内的三个可用区中，数据也会被复制到该区域内的三个不同可用区中。如果一个可用区发生故障，影响到服务层或数据层，那么其余的可用区便会无中断地接管这些服务或数据。使用区域级配置时，如果服务所在的整个区域都发生服务中断，那么在该区域恢复在线状态之前，服务将不可用。如果整个区域发生不可预见的物理销毁，存储在该区域的数据将丢失。

多区域配置：在多区域配置中，Cloud Healthcare API 会被部署到分别属于三个不同区域的三个可用区中。数据也会被复制到三个区域。这样可以防止在发生全区域服务中断时丢失服务，因为其余区域会自动接管。结构化数据（例如 FHIR）会跨多个区域同步复制，因此在发生全区域服务中断时可防止数据丢失。存储在 Cloud Storage 存储桶中的数据（例如 DICOM 和 Dictation 或大型 HL7v2/FHIR 对象）是跨多个区域异步复制的。

Cloud Identity

Cloud Identity 服务分布在多个区域中，并使用动态负载均衡。Cloud Identity 不允许用户选择资源范围。如果特定可用区或区域发生服务中断，则流量会自动分配到其他可用区或区域。

在大多数情况下，永久性数据会通过同步复制在多个区域中镜像。考虑到性能原因，一些系统（例如影响大量实体的缓存或更改）会跨区域异步复制。如果存储最新数据的主要区域发生服务中断，则在该主要区域变为可用之前，Cloud Identity 会从其他位置传送过时数据。

Cloud Interconnect

Cloud Interconnect 为客户提供通过连接到 Google 对等边缘的物理线缆从本地数据中心访问 Google Cloud 网络的 RFC 1918。

如果客户在都市区域中预配与两个 EAD（边缘可用性网域）的连接，则 Cloud Interconnect 可提供 99.9% 的 SLA。如果客户使用全球路由将两个都市区域中的两个 EAD 预配到两个区域，则可提供 99.99% 的 SLA。如需了解详情，请参阅非关键应用拓扑概览和生产级应用拓扑概览。

Cloud Interconnect 与计算可用区无关，并以 EAD 的形式提供高可用性。如果 EAD 发生故障，与该 EAD 的 BGP 会话会中断，并且流量会故障切换到另一个 EAD。

如果发生区域级故障，通往该区域的 BGP 会话会中断，并且流量会故障切换到工作区域中的资源。这适用于启用全局路由时。

Cloud Key Management Service

Cloud Key Management Service (Cloud KMS) 提供可扩缩且高度耐用的加密密钥资源管理系统。Cloud KMS 将其所有数据和元数据存储在 Spanner 数据库中，该数据库通过同步复制可提高数据耐用性和可用性。

您可以在单个区域、多个区域或在全球范围内创建 Cloud KMS 资源。

如果某个可用区发生服务中断，则 Cloud KMS 将不间断地继续处理来自同一区域或不同区域中的其他可用区的请求。由于数据是同步复制的，因此不会造成数据丢失或损坏。该可用区服务中断解决后，完全冗余性将恢复。

如果某个区域发生服务中断，则在该区域再次可用之前，该区域中的可用区级资源会处于离线状态。请注意，即使在一个区域内，至少 3 个副本保留在不同可用区中。如果需要更高的可用性，则资源应存储在多区域配置或全球配置中。多区域配置和全球配置旨在发生区域级服务中断时，通过以地理位置冗余方式在多个区域存储和传送数据来保持可用。

Cloud External Key Manager (Cloud EKM)

Cloud External Key Manager 与 Cloud Key Management Service 集成，可让您通过支持的第三方合作伙伴控制和访问外部密钥。您可以使用这些外部密钥来加密静态数据，以用于支持客户管理的加密密钥 (CMEK) 集成的其他 Google Cloud 服务。

• 可用区级服务中断：由于一个区域中的多个可用区提供的冗余，Cloud External Key Manager 可以应对可用区级服务中断。如果发生可用区级服务中断，流量会重新路由到该区域内的其他可用区。在重新路由流量期间，您可能会看到错误增加，但服务仍然可用。

• 区域级服务中断：在发生区域级服务中断时，Cloud External Key Manager 不可用。没有跨区域重定向请求的故障切换机制。我们建议客户使用多个区域来运行作业。

Cloud External Key Manager 不会永久存储任何客户数据。因此，在发生区域级服务中断时，Cloud External Key Manager 系统中不会丢失数据。但是，Cloud External Key Manager 依赖于其他服务的可用性，例如 Cloud Key Management Service 和外部第三方供应商。如果这些系统在区域级服务中断期间发生故障，您可能会丢失数据。这些系统的 RPO/RTO 不在 Cloud External Key Manager 承诺的范围内。

Cloud Load Balancing

Cloud Load Balancing 是一项完全分布式、软件定义的托管式服务。借助 Cloud Load Balancing，您可以将一个任播 IP 地址用作全球各区域中后端的前端。它并非基于硬件，因此您无需管理物理负载均衡基础架构。负载均衡器是大多数高可用性应用的关键组成部分。

Cloud Load Balancing 可提供区域级和全球负载均衡器。Cloud Load Balancing 还可提供跨区域负载均衡功能，包括自动多区域故障切换（即在主后端健康状况不佳时，可将流量转移到故障切换后端）。

全球负载均衡器可以灵活应对可用区和区域服务中断。区域级负载均衡器可以灵活应对可用区服务中断，但会受其区域服务中断的影响。但在任何一种情况下，都请务必了解整体应用的弹性不仅取决于您部署的负载均衡器类型，还取决于后端的冗余。

如需详细了解 Cloud Load Balancing 及其功能，请参阅 Cloud Load Balancing 概览。

Cloud Logging

Cloud Logging 由两个主要部分组成：日志路由器和 Cloud Logging 存储。

日志路由器处理流式日志事件，并将日志定向到 Cloud Storage、Pub/Sub、BigQuery 或 Cloud Logging 存储。

Cloud Logging 存储是一项用于存储、查询和管理日志合规性的服务。它支持许多用户和工作流，包括开发、合规性、问题排查和主动提醒。

日志路由器和传入的日志：在某可用区发生服务中断期间，Cloud Logging API 会将日志路由到相应区域中的其他可用区。通常，日志路由器路由到 Cloud Logging、BigQuery 或 Pub/Sub 的日志会尽快写入其最终目标位置，而发送到 Cloud Storage 的日志会缓冲并按小时批量写入。

日志条目：发生可用区级或区域级服务中断时，在受影响的可用区或区域中已缓冲且尚未写入导出目标位置的日志条目会变得无法访问。基于日志的指标也会在日志路由器中计算，并受到相同的限制条件约束。在将日志传送到所选日志导出位置后，日志将根据目标位置服务进行复制。导出到 Cloud Logging 存储的日志会同步复制到一个区域的两个可用区中。如需了解其他目标位置类型的复制行为，请参阅本文中的相关部分。请注意，导出到 Cloud Storage 的日志每小时都会进行批处理和写入。因此，我们建议您使用 Cloud Logging 存储空间、BigQuery 或 Pub/Sub，以尽量减少受中断影响的数据量。

日志元数据：接收器和排除配置等元数据在全球范围内存储，但在区域范围内缓存，因此如果发生服务中断，区域日志路由器实例会正常运行。单个区域服务中断对该区域之外无任何影响。

Cloud Monitoring

Cloud Monitoring 包含各种互连的功能，例如信息中心（内置和用户定义）、提醒和正常运行时间监控。

所有 Cloud Monitoring 配置（包括信息中心、拨测和提醒政策）都是全局定义的。对它们的所有更改都会同步复制到多个区域。因此，在发生可用区级和区域级服务中断期间，成功的配置更改会持久。此外，虽然可用区或区域最初发生故障时，可能会发生暂时性读写故障，但 Cloud Monitoring 会将请求重新路由到可用的可用区和区域。在这种情况下，您可以使用指数退避算法重试配置更改。

为特定资源写入指标时，Cloud Monitoring 首先会确定资源所在的区域。 然后，它会写入该区域内指标数据的三个独立副本。三个写入操作之一成功后，整体区域指标写入会立即返回成功。无法保证三个副本位于区域内的不同可用区。

• 可用区级：在可用区级服务中断期间，指标写入和读取对受影响的可用区中的资源完全不可用。实际上，Cloud Monitoring 的行为类似于受影响的可用区不存在。

• 区域级：在区域级服务中断期间，指标写入和读取对受影响的区域中的资源完全不可用。实际上，Cloud Monitoring 的行为类似于受影响的区域不存在。

Cloud NAT

Cloud NAT（网络地址转换）是一种软件定义的分布式托管式服务，可让某些没有外部 IP 地址的资源创建与互联网的出站连接。它并非基于代理虚拟机或设备。Cloud NAT 会配置 Andromeda 软件，该软件为您的 Virtual Private Cloud 网络提供支持，从而为没有外部 IP 地址的虚拟机提供来源网络地址转换（来源 NAT 或 SNAT）。此外，Cloud NAT 还会对建立的入站响应数据包执行目标网络地址转换（目标 NAT 或 DNAT）。

如需详细了解 Cloud NAT 的功能，请参阅文档。

可用区级中断：Cloud NAT 能够适应可用区级故障，因为控制平面和网络数据平面在一个区域内的多个可用区中是冗余的。

区域级服务中断：Cloud NAT 是区域级产品，因此无法承受区域级故障。

Cloud Router

Cloud Router 是一项完全分布式的代管 Google Cloud 服务，它使用边界网关协议 (BGP) 来通告 IP 地址范围。Cloud Router 根据从对等体收到的 BGP 通告来对动态路由进行编程。每个 Cloud Router 路由器不是实体设备，而是由充当 BGP 发言者和响应者的软件任务组成。

如果某个可用区发生服务中断故障，则具有高可用性 (HA) 配置的 Cloud Router 路由器可以适应可用区故障。在这种情况下，一个接口可能会失去连接，但流量会通过使用 BGP 的动态路由重定向到另一个接口。

如果发生区域级服务中断故障，则由于 Cloud Router 路由器是区域级产品，因此无法承受区域级故障。如果客户启用了全球路由模式，则故障区域与其他区域之间的路由可能会受到影响。

Cloud Run

Cloud Run 是一个无状态的计算环境，在此环境中，客户可以在 Google 的基础架构上运行其容器化代码。Cloud Run 是区域级产品，这意味着客户可以选择区域，但不能选择构成区域的可用区。系统会在一个区域内的多个可用区之间自动平衡数据和流量。容器实例会自动扩缩以满足传入的流量，并在需要时跨区域进行负载均衡。每个可用区都维护一个为每个可用区提供此自动扩缩功能的调度器。它还考虑其他可用区正在接收的负载，并将在可用区内预配额外的容量来应对任何可用区级故障。

可用区级服务中断：Cloud Run 会存储元数据以及已部署的容器。此数据按照区域来存储并同步写入。只有在数据被提交到区域内的仲裁后，Cloud Run Admin API 才会返回 API 调用。由于数据按区域存储，因此数据平面操作也不受可用区级故障的影响。 如果发生可用区级故障，流量会自动路由到其他可用区。

区域级服务中断：客户选择要在其中创建 Cloud Run 服务的 Google Cloud 区域。数据绝不会跨区域复制。Cloud Run 绝不会将客户流量路由到其他区域。如果发生区域级故障，Cloud Run 将在服务中断问题得到解决后立即恢复可用。建议客户部署到多个区域，并根据需要使用 Cloud Load Balancing 实现更高的可用性。

Cloud Shell

Cloud Shell 为 Google Cloud 用户提供对单用户 Compute Engine 实例的访问权限，这些实例已经过预先配置，用于初始配置、教育、开发和运营商任务。

Cloud Shell 不适合运行应用工作负载，而适合用于交互式开发和教育使用场景。它具有每个用户的运行时配额限制，并且会在短时间不活动后自动关闭，并且只有已分配用户可以访问该实例。

支持服务的 Compute Engine 实例是可用区级资源，因此在发生可用区服务中断故障时，用户的 Cloud Shell 将不可用。

Cloud Source Repositories

借助 Cloud Source Repositories，用户可以创建和管理私有源代码库。此产品采用全球模型设计，因此您无需针对区域或可用区弹性进行配置。

针对 Cloud Source Repositories 执行的 git push 操作会将源代码库更新同步复制到多个区域的多个可用区。这意味着服务能够应对任何区域的服务中断故障。

如果特定可用区或区域发生服务中断，则流量会自动分配到其他可用区或区域。

自动镜像 GitHub 或 Bitbucket 中的代码库的功能可能会受到这些产品问题的影响。例如，如果 GitHub 或 Bitbucket 无法向 Cloud Source Repositories 提醒新提交，或者 Cloud Source Repositories 无法从更新后的代码库中检索内容，则镜像作业会受到影响。

Spanner

Spanner 是一种具备扩缩能力、扩容能力极强的多版本、同步复制以及具备关系语义的高度一致性数据库。

区域 Spanner 实例在单个区域中三个可用区之间同步复制数据。对某个区域 Spanner 实例的写入将同步发送到所有 3 个副本，并在至少 2 个副本（其中的大多数数量为 2/3）提交写入之后向客户端确认。这样，通过提供对所有数据的访问权限，Spanner 可以适应可用区故障，因为最新写入仍然存在，并且使用 2 个副本仍可达成大部分仲裁。

Spanner 的多区域实例包括一个写入区域，即跨三个区域中的 5 个可用区同步复制数据（两个读写副本分别位于默认主要区域和另一个区域中；一个副本位于见证者区域）。对多区域 Spanner 实例执行写入操作后，至少要等待 3 个副本（大部分是 3 个，共 5 个）提交的写入操作。如果在一个可用区或区域发生故障，Spanner 可以访问所有数据（包括最新的写入），并可以处理读写请求，因为数据会在至少 3 个可用区中持续存在 2 个区域。

如需详细了解这些配置，请参阅 Spanner 实例文档；如需详细了解 Spanner 复制的工作原理，请参阅复制文档。

Cloud SQL

Cloud SQL 是一项适用于 MySQL、PostgreSQL 和 SQL Server 的全托管式关系型数据库服务。Cloud SQL 使用代管式 Compute Engine 虚拟机来运行数据库软件。Cloud SQL 为区域冗余提供高可用性配置，从而保护数据库不受可用区服务中断的影响。您可以预配跨区域副本以保护数据库不受区域服务中断的影响。由于该产品还提供不能应对可用区或区域服务中断的可用区级选项，因此您应该谨慎选择高可用性配置和/或跨区域副本。

可用区级服务中断：高可用性选项可在一个区域内的两个不同可用区中创建主虚拟机实例和备用虚拟机实例。在正常操作期间，主虚拟机实例会处理所有请求，并将数据库文件写入区域级 Persistent Disk，该 Persistent Disk 会同步复制到主要可用区和备用可用区。如果可用区服务中断影响主实例，则 Cloud SQL 会启动故障切换，在此期间，Persistent Disk 会挂接到备用虚拟机且流量会重新路由。

在此过程中，数据库必须初始化，包括处理已写入事务日志但未应用于数据库的任何事务。未处理的事务的数量和类型会增加 RTO 时间。最近的写入可能会导致未处理的事务积压。RTO 时间主要受以下因素的影响：(a) 最近的写入活动；(b) 最近对数据库架构的更改。

最后，可用区级服务中断解决后，您可以手动触发故障恢复操作以在主要可用区继续传送数据。

如需详细了解高可用性选项，请参阅 Cloud SQL 高可用性文档。

区域级服务中断：跨区域副本选项可在其他区域中创建主实例的读取副本，以保护您的数据库不受区域级服务中断的影响。跨区域复制使用异步复制功能，可让主实例在副本实例提交事务之前先提交事务。事务在主实例上提交和在副本实例上提交之间的时间差称为“复制延迟”（可以进行监控）。此指标反映了尚未从主实例发送到副本实例的事务，以及副本实例已收到但尚未处理的事务。在区域级服务中断期间，未发送到副本实例的事务会变得不可用。副本实例已收到但未处理的事务会影响恢复时间，如下所述。

Cloud SQL 建议您使用包含一个副本的配置测试您的工作负载，以确定“每秒安全事务数 (TPS)”上限，即不会使复制延迟时间累积的最大持续 TPS。如果您的工作负载超过安全 TPS 上限，复制延迟时间会累积，对 RPO 和 RTO 值产生不利影响。一般来说，请避免使用易受复制延迟影响的小型实例配置（vCPU 核心小于 2 个，磁盘小于 100GB 或 PD-HDD）。

如果发生区域级服务中断，您必须决定是否手动提升读取副本。这是一项手动操作，因为提升可能会导致脑裂情况，在此情况下，尽管提升时主实例延迟，提升的副本仍会接受新事务。这在区域级服务中断解决后可能会导致问题，您必须调整从未从主实例传播到副本实例的事务。如果这对您的需求有影响，您可以考虑使用跨区域同步复制数据库产品（如 Spanner）。

用户触发提升过程后，提升过程将遵循与在高可用性配置中激活备用实例类似的步骤。在此过程中，只读副本必须处理可增加总恢复时间的事务日志。由于副本升级不涉及内置负载均衡器，因此请手动将应用重定向到提升的主节点。

如需详细了解跨区域副本选项，请参阅 Cloud SQL 跨区域副本文档。

如需详细了解 Cloud SQL 灾难恢复，请参阅以下内容：

• Cloud SQL for MySQL 数据库灾难恢复
• Cloud SQL for PostgreSQL 数据库灾难恢复
• Cloud SQL for SQL Server 数据库灾难恢复

Cloud Storage

Cloud Storage 可提供全球统一、可扩缩且高度耐用的对象存储。您可以在以下三种不同类型的位置中创建 Cloud Storage 存储桶：大洲内的单区域、双区域或多区域。使用区域级存储桶时，对象会跨单个区域中的多个可用区以冗余方式存储。另一方面，双区域和多区域存储桶则提供地理位置冗余。这意味着在将新写入的数据复制到至少一个远程区域后，对象便会跨区域以冗余方式存储。与单区域存储相比，这种方法可为双区域和多区域存储桶中的数据提供更广泛的保护。

在单个可用区发生服务中断时，区域级存储桶能够提供灵活的灾难恢复。如果某个可用区发生服务中断，则系统会自动、透明地从相应区域中的其他位置传送中断可用区中的对象。从最初写入开始，数据和元数据以冗余方式跨可用区存储。当某个可用区变为不可用时，所有写入都不会丢失。如果某个区域发生服务中断，则在该区域再次可用之前，该区域中的区域级存储桶会处于离线状态。

如果需要更高的可用性，您可以将数据存储在双区域或多区域配置中。双区域和多区域存储桶也是单个存储桶（没有单独的主要位置和次要位置），但它们能够跨区域以冗余方式存储数据和元数据。如果有某个区域发生服务中断，服务不会受到影响。您可以将双区域和多区域存储桶视为主动-主动类型，因为您可以同时在多个区域中读取和写入工作负载，同时存储桶还能保持高度一致。对于想要在灾难恢复架构中跨两个区域拆分工作负载的客户而言，这尤其具有吸引力。

双区域和多区域能够实现高度一致性，因为元数据始终跨区域同步写入。这种方法让服务始终能够确定对象的最新版本及其来源位置（包括远程区域）。

数据是异步复制的。这意味着存在一个 RPO 时间窗口，在该时间窗口中，新写入的对象开始时作为区域对象受到保护，并可在单个区域内的多个可用区之间实现冗余。之后，该服务会将该 RPO 窗口内的对象复制到一个或多个远程区域，使其能够提供地理位置冗余。该复制完成后，如果发生区域级服务中断，则数据可以自动、透明地从另一个区域进行传送。增强型复制是双区域存储桶上提供的高级功能，可获得更小的 RPO 窗口，其目标是 100% 复制新写入的对象，并在 15 分钟内实现地理位置冗余。

RPO 是一个重要的考虑因素，因为在区域中断期间，最近在 RPO 窗口内写入受影响区域的数据可能还没有复制到其他区域。因此，在服务中断期间，您可能无法访问这些数据，并且如果数据在受影响区域内发生物理销毁，则数据可能还会丢失。

Cloud Translation

Cloud Translation 在多个可用区和区域中具有活跃的计算服务器。它还支持跨区域内的各可用区进行同步数据复制。这些功能有助于 Translation 实现即时故障切换，并且不会在可用区发生故障时丢失任何数据，也不需要客户执行任何输入或调整操作。如果发生区域级故障，Cloud Translation 将不可用。

Compute Engine

Compute Engine 是 Google Cloud 的基础设施即服务选项之一，它使用 Google 的全球性基础设施为客户提供虚拟机（及相关服务）。

Compute Engine 实例是可用区级资源，因此在发生可用区服务中断时，实例默认不可用。Compute Engine 提供了托管式实例组 (MIG)，它可以在一个区域内的单个可用区中和多个可用区之间，通过预配置的实例模板自动扩容额外的虚拟机。MIG 非常适合那些需要对可用区故障具有恢复能力且无状态的应用，但需要进行配置和资源规划。多个区域级 MIG 可用于为无状态应用实现区域服务中断恢复能力。

具有有状态工作负载的应用仍可以使用有状态 MIG，但在进行容量规划时需要特别注意，因为有状态 MIG 不会横向扩容。无论是哪种情况，都请务必提前正确配置和测试 Compute Engine 实例模板及 MIG，以确保故障切换到其他可用区的功能正常。如需了解详情，请参阅上面的开发您自己的参考架构和指南部分。

单租户

借助单租户，您可以拥有单租户节点的独占访问权限，单租户节点是专门用于仅托管您的项目的虚拟机的物理 Compute Engine 服务器。

单租户节点（如 Compute Engine 实例）属于可用区级资源。万一发生罕见的可用区级服务中断，单租户节点会不可用。为缓解可用区级故障，您可以在另一个可用区中创建单租户节点。考虑到某些工作负载可能会受益于单租户节点以进行许可或资本支出记账，您应该提前规划故障切换策略。

在其他位置重新创建这些资源可能会产生额外的许可费用或违反资本支出记账要求。如需获取一般指导，请参阅开发您自己的参考架构和指南。

单租户节点属于可用区级资源，无法承受区域级故障。如需跨可用区进行扩缩，请使用区域级 MIG。

Compute Engine 网络

如需了解互连连接的高可用性设置，请参阅以下文档：

• 专用互连达到 99.99% 的可用性
• 合作伙伴互连达到 99.99% 的可用性

您可以在全球级或区域级模式中预配外部 IP 地址，如果发生区域级故障，这会影响其可用性。

Cloud Load Balancing 弹性

负载均衡器是大多数高可用性应用的关键组成部分。请务必了解，整体应用的弹性不仅取决于您选择的负载均衡器范围（全球或区域），还取决于后端服务的冗余。

下表总结了基于负载均衡器的分布或范围的负载均衡器弹性。

负载均衡器范围	架构	能够应对可用区级服务中断	能够应对区域级服务中断
全球	每个负载均衡器均分布在所有区域中
跨地区	每个负载均衡器均分布在多个区域中
区域	每个负载均衡器均分布在区域的多个可用区中		给定区域的服务中断会影响该区域的区域级负载均衡器

如需详细了解如何选择负载均衡器，请参阅 Cloud Load Balancing 文档。

Connectivity Tests

Connectivity Tests 是一种诊断工具，可让您检查网络端点之间的连接。它会分析您的配置，在某些情况下还会在端点之间执行实时数据平面分析。端点是指网络流量的来源或目的地，例如虚拟机、Google Kubernetes Engine (GKE) 集群、负载均衡器转发规则或 IP 地址。Connectivity Tests 是一种没有数据平面组件的诊断工具。它不处理或生成用户流量。

可用区级服务中断：Connectivity Tests 资源属于全球性资源。在发生可用区级服务中断时，您可以管理和查看这些资源。Connectivity Tests 资源是配置测试的结果。这些结果可能包括受影响可用区中的可用区级资源（例如虚拟机实例）的配置数据。如果发生服务中断，则分析结果将不准确，因为分析基于服务中断之前的过时数据。请勿依赖此分析。

区域级服务中断：在区域级服务中断时，您仍然可以管理和查看 Connectivity Tests 资源。Connectivity Tests 资源可能包括受影响区域中的区域级资源（例如子网）的配置数据。如果发生服务中断，则分析结果将不准确，因为分析基于服务中断之前的过时数据。请勿依赖此分析。

Container Registry

Container Registry 提供可扩缩的托管式 Docker Registry 实现，可安全、私密地存储 Docker 容器映像。Container Registry 实现了 HTTP Docker Registry API。

Container Registry 是一项全球服务，默认情况下以冗余方式将映像元数据同步存储到多个可用区和区域。容器映像存储在 Cloud Storage 多区域级存储桶中。借助此存储策略，Container Registry 能够在所有情况下提供可用区级服务中断恢复能力，并能够为 Cloud Storage 已异步复制到多个区域的任何数据提供区域级服务中断恢复能力。

Database Migration Service

Database Migration Service 是一种全托管式 Google Cloud 服务，用于将数据库从其他云服务提供商或本地数据中心迁移到 Google Cloud。

Database Migration Service 的架构设计为一个区域级控制平面。控制平面不依赖于给定区域中的个别可用区。在发生可用区级服务中断期间，您可以继续访问 Database Migration Service API，包括能够创建和管理迁移作业。在发生区域级服务中断期间，您将无法访问属于该区域的 Database Migration Service 资源，直到服务中断得到解决。

Database Migration Service 取决于用于迁移过程的源数据库和目标数据库的可用性。如果 Database Migration Service 源数据库或目标数据库不可用，则迁移会停止进行，但客户核心数据或作业数据不会丢失。当该源数据库和目标数据库再次可用时，迁移作业将恢复。

例如，您可以配置启用了高可用性 (HA) 的目标 Cloud SQL 数据库，以获取能够应对可用区级服务中断的目标数据库。

Database Migration Service 迁移分为两个阶段：

• 完整转储：根据迁移作业规范执行从来源到目标位置的完整数据复制。
• 变更数据捕获 (CDC)：将增量更改从来源复制到目标位置。

可用区级服务中断：如果以上任一阶段发生可用区级故障，您仍然可以访问和管理 Database Migration Service 中的资源。数据迁移的影响如下：

• 完整转储：数据迁移失败；您需要在目标数据库完成故障切换操作后重启迁移作业。
• CDC：数据迁移已暂停。迁移作业会在目标数据库完成故障切换操作后自动恢复。

区域级服务中断：Database Migration Service 不支持跨区域级资源，因此无法应对区域级故障。

Dataflow

Dataflow 是 Google Cloud 的全托管式无服务器数据处理服务，可用于流处理和批处理流水线。默认情况下，区域级端点会将 Dataflow 工作器池配置为使用该区域内的所有可用的可用区。每个工作器在创建时，系统都会为其计算可用区选择，从而优化资源获取和未使用预留的使用。在 Dataflow 作业的默认配置中，中间数据由 Dataflow 服务存储，作业状态存储在后端。如果某个可用区出现故障，Dataflow 作业可以继续运行，因为系统会在其他可用区重新创建工作器。

存在以下限制：

• 只有使用 Streaming Engine 或 Dataflow Shuffle 的作业支持区域选择。已停用 Streaming Engine 或 Dataflow Shuffle 的作业无法使用区域选择。
• 区域选择仅适用于虚拟机。但不适用于 Streaming Engine 和 Dataflow Shuffle 相关资源。
• 虚拟机不会跨多个可用区复制。如果某虚拟机不可用，则其工作项会被视为丢失，并由另一个虚拟机重新处理。
• 如果区域范围的资源缺乏，则 Dataflow 服务将无法创建更多虚拟机。

设计 Dataflow 流水线架构以实现高可用性

您可以并行运行多个流式传输流水线以实现高可用性数据处理。例如，您可以在不同的区域运行两个并行流式传输作业。运行并行流水线可为数据处理提供地理冗余和容错。通过考虑数据源和接收器的地理可用性，您可以在可用性高的多区域配置中操作端到端流水线。如需了解详情，请参阅“设计 Dataflow 流水线工作流”中的高可用性和地理冗余。

如果可用区或区域发生服务中断，您可以将通过对 Pub/Sub 主题重复使用同一订阅来避免数据丢失。为了保证记录在重排期间不会丢失，Dataflow 使用上游备份，这意味着发送记录的工作器会重试 RPC，直到收到记录的肯定确认，以及处理记录的副作用已提交到永久性存储空间下游。如果发送记录的工作器不可用，Dataflow 会继续重试 RPC。重试 RPC 可确保每条记录正好传送一次。 如需详细了解 Dataflow 的正好一次保证，请参阅 Dataflow 中的“正好一次”。

如果流水线使用了分组或时间数据选取，则您可以在可用区级或区域级服务中断后使用 Pub/Sub 的还原功能或 Kafka 的重放功能来重新处理数据元素，以获得相同的计算结果。如果流水线使用的业务逻辑不依赖于服务中断之前的数据，则流水线输出的数据丢失可降至 0 个元素。如果流水线业务逻辑依赖于服务中断之前处理的数据（例如，如果使用了长滑动窗口，或者如果全局时间窗口存储了不断增加的计数器），请使用Dataflow 快照保存流式传输流水线的状态，然后启动新版本的作业，且不丢失状态。

Dataproc

Dataproc 具有流式和批量数据处理功能。Dataproc 的架构设计为一个区域级控制平面，让用户可以管理 Dataproc 集群。控制平面不依赖于给定区域中的个别可用区。因此，在发生可用区级服务中断期间，您可以保留对 Dataproc API 的访问权限，包括创建新集群的权限。

您可以创建以下 Dataproc 集群：

• Compute Engine 上的 Dataproc 集群
• GKE 上的 Dataproc 集群

Compute Engine 上的 Dataproc 集群

由于 Compute Engine 上的 Dataproc 集群是可用区级资源，因此可用区级服务中断会导致集群不可用，或者会销毁集群。 Dataproc 不会自动截取集群状态快照，因此可用区服务中断可能会导致正在处理的数据丢失。Dataproc 不会保留服务中的用户数据。用户可以配置其流水线，以将结果写入多个数据存储区；您应该考虑数据存储区的架构，并选择具有所需灾难恢复能力的产品。

如果某个区域发生服务中断，您可以选择在另一个区域中重新创建集群的新实例，方法是选择其他区域，或者使用 Dataproc 中的“自动选择区域”功能自动选择可用区域。集群可用后，数据处理就可以继续进行。您还可以运行启用了高可用性模式的集群，从而降低部分可用区服务中断影响主节点，因此影响整个集群的可能性。

GKE 上的 Dataproc 集群

GKE 上的 Dataproc 集群可以是可用区级或区域级集群。

如需详细了解可用区级和区域级 GKE 集群的架构和灾难恢复功能，请参阅本文档后面的 Google Kubernetes Engine 部分。

Datastream

Datastream 是一种无服务器变更数据捕获 (CDC) 和复制服务，可让您可靠地同步数据，同时将延迟时间缩至最短。Datastream 可将数据从运维数据库复制到 BigQuery 和 Cloud Storage。此外，它还可与 Dataflow 模板简化集成，以构建用于将数据加载到各种目标位置（例如 Cloud SQL 和 Spanner）的自定义工作流。

可用区级服务中断：Datastream 是一项多可用区级服务。它可以承受全面的计划外可用区级服务中断，而不会造成任何数据或可用性损失。如果发生可用区级故障，您仍然可以在 Datastream 中访问和管理资源。

区域级服务中断：如果发生区域级服务中断，Datastream 会在服务中断问题得到解决后立即恢复可用。

Document AI

Document AI 是一个文档理解平台，可从文档中获取非结构化数据并转换为结构化数据，使数据更易于理解、分析和使用。Document AI 是一项区域级服务。客户可以选择区域，但不能选择区域内的可用区。系统会在一个区域内的多个可用区之间自动平衡数据和流量。服务器会自动扩缩以满足传入的流量，并在需要时跨可用区进行负载均衡。每个可用区都维护一个为每个可用区提供此自动扩缩功能的调度器。调度器还会考虑其他可用区正在接收的负载，并在可用区内预配额外的容量来应对任何可用区级故障。

可用区级服务中断：Document AI 会存储用户文档和处理方版本数据。此数据按区域存储并同步写入。由于数据按区域存储，因此数据平面操作不受可用区级故障影响。如果发生可用区级故障，流量会自动路由到其他可用区，产生的延迟取决于依赖服务（如 Vertex AI）的恢复时间。

区域级服务中断：数据绝不会跨区域复制。在发生区域级服务中断时，Document AI 不会进行故障切换。客户选择要使用 Document AI 的 Google Cloud 区域。但是，该客户流量绝不会路由到另一个区域。

端点验证

借助端点验证，管理员和安全运维专业人员可以构建访问组织数据的设备清单。作为 BeyondCorp Enterprise 解决方案的一部分，端点验证还提供重要的设备信任和基于安全性的访问权限控制。

如需大致了解组织的笔记本电脑和桌面设备的安全措施，请使用端点验证。与 BeyondCorp Enterprise 产品搭配使用时，端点验证有助于对 Google Cloud 资源进行精细的访问权限控制。

端点验证适用于 Google Cloud、Cloud Identity、Google Workspace 商务版和 Google Workspace 企业版。

Eventarc

Eventarc 使用对状态变化做出反应的松散耦合服务，提供来自 Google 提供商（第一方）、用户应用（第二方）和软件即服务（第三方）的异步交付事件。这样一来，客户可以将目标（例如 Cloud Run 实例或第 2 代 Cloud Functions 函数）配置为在事件提供程序服务或客户代码事件发生时触发。

可用区级服务中断：Eventarc 会存储与触发器相关的元数据。此数据按区域存储并同步写入。只有在数据被提交到区域内的仲裁时，创建和管理触发器和渠道的 Eventarc API 才会返回 API 调用。由于数据按区域存储，因此数据平面操作不受可用区故障影响。如果发生可用区故障，流量会自动路由到其他可用区。用于接收和递送第二方和第三方事件的 Eventarc 服务会跨可用区复制。这些服务按区域分布。系统会自动从该区域可用的可用区传送对不可用的可用区的请求。

区域级服务中断：客户选择要在其中创建 Eventarc 触发器的 Google Cloud 区域。数据绝不会跨区域复制。Eventarc 绝不会将客户流量路由到其他区域。如果发生区域级故障，Eventarc 会在服务中断问题得到解决后立即恢复可用。为了实现更高的可用性，建议客户根据需要将触发器部署到多个区域。

请注意以下几点：

• Eventarc 服务会尽力接收和传送第一方事件，不在 RTO/RPO 的涵盖范围内。
• Google Kubernetes Engine 服务的 Eventarc 事件传送尽力而为，不在 RTO/RPO 的涵盖范围内。

Filestore

基本层级和大规模层级是可用区级资源。它们无法容忍已部署的可用区或区域发生故障。

Enterprise 层级 Filestore 实例是区域级资源。 Filestore 遵循 NFS 要求的严格一致性政策。 当客户端写入数据时，Filestore 会在两个可用区中保留并复制更改后才返回确认，以便后续读取返回正确的数据。

如果发生可用区故障，Enterprise 层级实例会继续从其他可用区传送数据，同时接受新写入的数据。读写操作的性能都可能会下降；写入操作可能不会进行复制。加密不会被破解，因为密钥从其他可用区传送。

我们建议客户端创建外部备份，以防同一区域的其他可用区中发生进一步服务中断。备份可用于将实例恢复到其他区域。

Firestore

Firestore 是一种灵活且可扩容的数据库，适用于在 Firebase 和 Google Cloud Platform 上进行移动、Web 和服务器开发。Firestore 提供自动多区域数据复制、强一致性保证、原子批量操作和 ACID 事务。

Firestore 为客户提供单区域和多区域位置。流量在区域内的各可用区之间自动进行负载均衡。

区域 Firestore 实例至少在三个可用区中同步复制数据。如果发生可用区故障，仍然可以通过其余两个（或更多）副本提交写入，并保留提交的数据。流量会自动路由到其他可用区。区域位置的费用更低，写入延迟时间更低，并且可与其他 Google Cloud 资源共用位置。

Firestore 多区域实例跨三个区域（两个传送区域和一个见证者区域）中的五个可用区同步复制数据，并且它们可以非常稳健地应对可用区和区域故障。如果发生可用区或区域故障，系统会保留已提交的数据。流量会自动路由到传送可用区/区域，提交仍由两个剩余区域中的至少三个可用区传送。多区域可最大限度地提高数据库的可用性和耐用性。

防火墙数据分析

防火墙数据分析可帮助您了解和优化防火墙规则。它提供了有关如何使用防火墙规则的数据分析、建议和指标。防火墙数据分析还会使用机器学习来预测未来的防火墙规则使用情况。借助防火墙数据分析，您可以在防火墙规则优化期间做出更明智的决策。例如，防火墙数据分析会标识其归类为过于宽松的规则。您可以使用此信息来严格限制防火墙配置。

可用区性服务中断：由于防火墙数据分析数据会跨可用区复制，因此不受可用区性服务中断的影响，并且客户流量会自动路由到其他可用区。

区域级服务中断：由于防火墙数据分析数据跨区域复制，因此它不受区域级服务中断的影响，并且客户流量会自动路由到其他区域。

舰队

舰队可让客户以群组形式管理多个 Kubernetes 集群，并允许平台管理员使用多集群服务。例如，通过舰队，管理员可以在所有集群中应用统一政策或设置多集群 Ingress。

将 GKE 集群注册到舰队时，默认情况下，该集群在同一区域中具有区域级成员资格。将非 Google Cloud 集群注册到舰队时，您可以选择任何区域或全球位置。最佳实践是选择靠近集群的物理位置的区域。这在使用 Connect 网关访问集群时可提供最佳延迟时间。

在发生可用区级服务中断的情况下，舰队功能不会受影响，除非底层集群是可用区级集群并且变得不可用。

在发生区域级服务中断的情况下，对于区域内成员资格集群，舰队功能会静态失效。缓解区域级服务中断需要在多个区域中进行部署，如针对云基础架构服务中断设计灾难恢复架构所建议。

Google Cloud Armor

Google Cloud Armor 可帮助您保护您的部署和应用免受多种类型的威胁，包括耗尽容量的 DDoS 攻击以及跨站脚本攻击和 SQL 注入等应用攻击。Google Cloud Armor 会过滤 Google Cloud 负载均衡器上不需要的流量，并阻止此类流量进入您的 VPC 以及使用资源。其中一些保护措施是自动进行的。有些服务要求您配置安全政策并将其附加到后端服务或区域。全球范围的 Google Cloud Armor 安全政策应用于全球负载均衡器。区域范围的安全政策应用于区域级负载均衡器。

可用区性服务中断：如果发生可用区性服务中断，Google Cloud 负载均衡器会将流量重定向到提供运行状况良好的后端实例的其他可用区。流量故障切换后，Google Cloud Armor 保护将立即可用，因为 Google Cloud Armor 安全政策会同步复制到一个区域中的所有可用区。

区域性服务中断：如果发生区域性服务中断，全球 Google Cloud 负载均衡器会将流量重定向到提供运行状况良好的后端实例的其他区域。流量故障切换后，Google Cloud Armor 保护会立即可用，因为您的全局 Google Cloud Armor 安全政策会同步复制到所有区域。为应对区域级故障，您必须为所有区域配置 Google Cloud Armor 区域安全政策。

Google Kubernetes Engine

Google Kubernetes Engine (GKE) 可简化 Google Cloud 上的容器化应用的部署，从而提供代管式 Kubernetes 服务。您可以选择区域级集群拓扑或可用区级集群拓扑。

• 创建可用区级集群时，GKE 会在选定区域中预配一个控制平面机器，并在同一区域中预配工作器机器（节点）。
• 对于区域级集群，GKE 会在选定区域内的三个不同可用区中预配三个控制平面机器。默认情况下，节点也分布在三个可用区中，但您可以选择创建具有仅在一个可用区中预配的节点的区域级集群。
• 多可用区级集群与可用区级集群类似，前者包含一个主节点机器，但还能够将节点分布在多个可用区中。

可用区级服务中断：为避免可用区级服务中断，请使用区域级集群。控制平面和节点分布在一个区域内的三个不同可用区中。一个可用区发生服务中断不会影响其他两个可用区中部署的控制平面和工作器节点。

区域级服务中断：缓解区域级服务中断需要在多个区域中进行部署。虽然多区域拓扑目前未作为内置产品功能提供，但它是现如今很多 GKE 客户所采用的方法，可手动实现。您可以创建多个区域级集群在多个区域中复制您的工作负载，并使用多集群 Ingress 控制发送到这些集群的流量。

高可用性 VPN

HA VPN（高可用性）是一种弹性的 Cloud VPN 产品，可以安全地加密从本地私有云、其他虚拟私有云或其他云服务提供商网络到 Google Cloud Virtual Private Cloud (VPC) 的流量。

HA VPN 网关有两个接口，每个接口的 IP 地址来自不同的 IP 地址池，因此请在逻辑上和物理上跨不同的 PoP 和集群进行拆分，以确保最佳冗余。

可用区级服务中断：在发生可用区级服务中断时，一个接口可能会丢失连接，但流量会通过边界网关协议 (BGP) 通过动态路由重定向到另一个接口。

区域级中断：在发生区域级服务中断的情况下，两个接口可能会在短时间内失去连接。

Identity and Access Management

Identity and Access Management (IAM) 负责针对云资源的操作的所有授权决策。IAM 确认政策会授予每项操作（在数据平面中）的权限，并通过 SetPolicy 调用（在控制平面中）处理对这些政策的更新。

所有 IAM 政策均会在每个区域内的多个可用区复制，这有助于 IAM 数据平面操作从其他区域的故障中恢复，以及容忍每个区域内的可用区故障。IAM 数据平面针对可用区故障和区域故障的弹性可帮助多区域和多可用区架构实现高可用性。

IAM 控制平面操作可以依赖于跨区域复制。当 SetPolicy 调用成功时，数据已写入多个区域，但传播到其他区域的操作具有最终一致性。IAM 控制平面可以应对单区域故障。

Identity-Aware Proxy

借助 Identity-Aware Proxy，您可以访问托管在 Google Cloud、其他云平台和本地的应用。IAP 按区域分布，系统会自动从该区域中的其他可用区传送对不可用的可用区的请求。

IAP 中的区域级服务中断会影响对受影响区域中托管的应用的访问。我们建议您部署到多个区域，并使用 Cloud Load Balancing 实现更高的可用性和弹性，以应对区域级服务中断故障。

Identity Platform

借助 Identity Platform，客户可以为其应用添加可自定义的 Google 级身份和访问权限管理。Identity Platform 是全球性产品。 客户无法选择存储其数据的区域或可用区。

可用区性服务中断：在可用区性服务中断期间，Identity Platform 会将请求故障切换到下一个最近的单元。 所有数据都会在全球范围内保存，因此不会丢失数据。

区域性服务中断：在发生区域性服务中断期间，Identity Platform 向不可用区域发送的请求会暂时失败，同时 Identity Platform 会从受影响区域中移除流量。 当没有更多流量流向受影响的区域时，全球服务器负载均衡服务会将请求路由到运行状况良好的最近可用区域。所有数据均在全球范围内保存，因此不会丢失数据。

Knative serving

Knative Serving 是一项全球服务，使客户能够在客户集群上运行无服务器工作负载。其目的是确保 Knative serving 工作负载在客户集群上正确部署，并且 Knative serving 的安装状态会反映在 GKE Fleet API 功能资源中。仅当在客户集群上安装或升级 Knative Serving 资源时，此服务才会参与。它不涉及执行集群工作负载。属于启用了 Knative serving 的项目的客户集群分布在多个区域和可用区的副本之间，每个集群由一个副本监控。

可用区和区域服务中断：由托管在发生服务中断的位置的副本监控的集群会自动在其他可用区和区域中运行状况良好的副本之间重新分布。在进行此重新分配过程中，在短时间内，某些集群不受 Knative Serving 监控。如果在此期间用户决定在集群上启用 Knative serving 功能，则在集群与运行状况良好的 Knative serving 服务副本重新连接后，集群便会开始安装 Knative serving 资源。

Looker (Google Cloud Core)

Looker (Google Cloud Core) 是一个商业智能平台，可让您通过 Google Cloud 控制台简化 Looker 实例的预配、配置和管理。通过 Looker (Google Cloud Core)，用户可以探索数据、创建信息中心、设置提醒和共享报告。此外，Looker (Google Cloud Core) 为数据建模者提供一个 IDE，为开发者提供丰富的嵌入和 API 功能。

Looker (Google Cloud Core) 由区域隔离的实例组成，这些实例在区域内跨可用区同步复制数据。确保您的实例使用的资源（例如 Looker [Google Cloud Core] 连接的数据源）位于实例运行所在的区域中。

可用区性服务中断：Looker (Google Cloud Core) 实例会存储元数据以及它们自己已部署的容器。数据在复制的实例之间同步写入。在发生可用区性服务中断时，Looker (Google Cloud Core) 实例会继续从同一区域中的其他可用可用区提供服务。任何事务或 API 调用都会在数据被提交到区域内的仲裁后返回。如果复制失败，则不会提交事务，并且用户会收到有关失败的通知。如果多个可用区发生故障，则事务也会失败并且用户会收到通知。Looker (Google Cloud Core) 会停止当前正在运行的所有时间表或查询。解决失败问题后，您必须重新安排它们或将其重新排入队列。

区域级服务中断：受影响区域内的 Looker (Google Cloud Core) 实例不可用。Looker (Google Cloud Core) 会停止当前正在运行的任何时间表或查询。解决失败问题后，您必须重新安排查询或将查询重新排队。您可以在其他区域手动创建新实例。您还可以使用从 Looker (Google Cloud Core) 实例导入数据或将数据导出到 Looker (Google Cloud Core) 中定义的流程恢复实例。我们建议您设置定期数据导出流程，提前复制资产，以防发生罕见的区域性服务中断。

Looker Studio

Looker Studio 是一种数据可视化和商业智能产品。它使客户能够连接到存储在其他系统中的数据、使用这些数据创建报告和信息中心，并在整个组织中共享报告和信息中心。Looker Studio 是一项全球性服务，不允许用户选择资源范围。

如果某个可用区的服务中断，则 Looker Studio 会继续处理同一区域内或不同区域中的其他可用区的请求，而不会中断。用户资源会跨区域同步复制。因此，不会丢失数据。

如果某个区域的服务中断，Looker Studio 将继续处理来自其他区域的请求，而不会中断。用户资源会跨区域同步复制。因此，不会丢失数据。

Memorystore for Memcached

Memorystore for Memcached 是 Google Cloud 的托管式 Memcached 产品。 借助 Memorystore for Memcached，客户可以创建 Memcached 集群，将其用作应用的高吞吐量键值对数据库。

Memcached 集群是区域级的，节点分布在所有客户指定的可用区中。但是，Memcached 不会跨节点复制任何数据。因此，可用区级故障可能会导致数据丢失，这也称为“部分清空缓存”。Memcached 实例将继续运行，但它们的节点会较少，因为服务不会在可用区故障期间启动任何新节点。未受影响可用区中的 Memcached 节点将继续处理流量，但该可用区故障会导致缓存命中率降低，直到该可用区恢复为止。

如果发生区域级故障，Memcached 节点将不会处理流量。在这种情况下，数据会丢失，这将导致完全清空缓存。为缓解区域级中断，您可以实现一种架构，用于跨多个区域部署应用和 Memorystore for Memcached。

Memorystore for Redis

Memorystore for Redis 是 Google Cloud 的一种全托管式 Redis 服务，可以减少管理复杂 Redis 部署的负担。目前提供 2 个层级：基本层级和标准层级。对于基本层级，可用区级或区域级服务中断会导致数据丢失，也称为“清空缓存”。对于标准层级，区域级服务中断会导致数据丢失。可用区级服务中断可能会导致标准层级实例因其异步复制而丢失部分数据。

重要提示：为使复制功能以可预测的方式运行，请确保 CPU 使用率和系统内存使用率不超过建议值。

可用区级服务中断：标准层级实例会将数据集操作从主节点中的数据集异步复制到副本节点。当主节点的可用区内发生中断时，副本节点将升级为主节点。在提升期间，会发生故障切换，并且 Redis 客户端必须重新连接到实例。重新连接后，操作会继续执行。如需详细了解标准层级中 Memorystore for Redis 实例的高可用性，请参阅 Memorystore for Redis 高可用性。

如果您在标准层级实例中启用读取副本，并且只有一个副本，则读取端点在可用区级服务中断期间不可用。如需详细了解读取副本的灾难恢复，请参阅读取副本的故障模式。

区域级服务中断：Memorystore for Redis 是区域级产品，因此单个实例无法承受区域级故障。您可以安排定期任务，将 Redis 实例导出到其他区域的 Cloud Storage 存储桶。发生区域级中断时，您可以在与已导出的数据集不同的区域恢复 Redis 实例。

多集群服务发现和多集群 Ingress

GKE 多集群 Service (MCS) 由多个组件组成。这些组件包括 Google Kubernetes Engine 中心（使用成员资格编排多个 Google Kubernetes Engine 集群）、集群本身和 GKE 中心控制器（多集群 Ingress、多集群服务发现）。中心控制器通过在多个集群上使用后端来编排 Compute Engine 负载均衡器配置。

如果发生可用区级服务中断，多集群服务发现会继续处理来自其他可用区或区域的请求。如果发生区域级服务中断，多集群服务发现不会进行故障切换。

多集群 Ingress 发生可用区级服务中断时，如果配置集群是可用区级集群且在故障范围内，则用户需要手动进行故障切换。数据平面可以停滞故障，并将继续处理流量，直到用户故障切换。为避免需要手动故障切换，请为配置集群使用区域级集群。

在发生区域级服务中断时，多集群 Ingress 不会进行故障切换。用户必须部署了 DR 计划才能手动对配置集群进行故障切换。如需了解详情，请参阅设置多集群 Ingress 和配置多集群 Service。

如需详细了解 GKE，请参阅针对云基础架构服务中断设计灾难恢复架构中的“Google Kubernetes Engine”部分。

网络分析器

网络分析器会自动监控您的 VPC 网络配置，并检测配置错误和欠佳配置。它提供了有关网络拓扑、防火墙规则、路由、配置依赖项以及与服务和应用的连接的数据分析。它可识别网络故障，提供根本原因信息，并建议可能的解决方法。

网络分析器会持续运行，并根据网络中近乎实时的配置更新触发相关分析。如果网络分析器检测到网络故障，则会尝试将故障与最近的配置更改关联起来，以确定根本原因。该分析器会尽可能提供有关如何解决问题的详细建议。

网络分析器是一种没有数据平面组件的诊断工具。它不处理或生成用户流量。

可用区级服务中断：网络分析器服务在全球范围内进行复制，其可用性不受可用区级服务中断的影响。

如果来自网络分析器的数据分析包含发生服务中断的可用区中的配置，则会影响数据质量。引用该可用区中的配置的网络数据分析会过时。请勿依赖在服务中断期间网络分析器提供的任何数据分析。

区域级服务中断：网络分析器服务在全球范围内进行复制，其可用性不受区域级服务中断的影响。

如果来自网络分析器的数据分析包含发生服务中断的区域中的配置，则会影响数据质量。引用该区域中的配置的网络数据分析会过时。请勿依赖在服务中断期间网络分析器提供的任何数据分析。

网络拓扑

网络拓扑是一种可视化工具，可显示网络基础设施的拓扑。基础设施视图显示 Virtual Private Cloud (VPC) 网络、与本地网络的混合连接、与 Google 管理的服务的连接以及关联的指标。

可用区级服务中断：如果某个可用区发生服务中断，则该可用区的数据不会显示在网络拓扑中。其他可用区的数据不受影响。

区域级服务中断：如果某个区域发生服务中断，则该区域的数据不会显示在网络拓扑中。其他区域的数据不受影响。

性能信息中心

通过性能信息中心，您可以了解整个 Google Cloud 网络的性能以及项目资源的性能。

借助这些性能监控功能，您可以区分应用中的问题和底层 Google Cloud 网络中的问题。此外，您还可以调查历史网络性能问题。 性能信息中心还会将数据导出到 Cloud Monitoring。您可以使用 Monitoring 查询数据并获取其他信息。

可用区级服务中断：

如果发生可用区级服务中断，来自受影响可用区的流量的延迟时间和丢包数据不会显示在性能信息中心内。来自其他可用区的流量的延迟时间和丢包数据不受影响。服务中断结束后，延迟时间和丢包数据会恢复。

区域服务中断：

如果发生区域级服务中断，则来自受影响区域的流量的延迟时间和丢包数据不会显示在性能信息中心内。来自其他区域的流量的延迟时间和丢包数据不受影响。服务中断结束后，延迟时间和丢包数据会恢复。

Network Connectivity Center

Network Connectivity Center 是一款 Network Connectivity 管理产品，它采用中心辐射型架构。使用此架构时，集中管理资源充当 hub，每个连接资源充当 spoke。混合 spoke 目前支持来自主要第三方供应商的高可用性 VPN、专用互连和合作伙伴互连以及 SD-WAN 路由器设备。借助 Network Connectivity Center 混合 spoke, 企业可以通过 Google Cloud 网络的全球覆盖面将 Google Cloud 工作负载和服务连接到本地数据中心、其他云及其分支办公室。

可用区级服务中断：具有高可用性配置的 Network Connectivity Center 混合 spoke 能够应对可用区级故障，因为控制平面和网络数据平面在一个区域内的多个可用区中是冗余的。

区域级服务中断：Network Connectivity Center 混合 spoke 是区域级资源，因此无法承受区域级故障。

Network Service Tiers

通过 Network Service Tiers，您可以优化互联网上的系统和 Google Cloud 实例之间的连接。Network Service Tiers 提供两个不同的服务层级：高级层级和标准层级。使用高级层级时，全球范围内公布的任播高级层级 IP 地址可以用作区域级后端或全球后端的前端。使用标准层级时，区域范围内公布的标准层级 IP 地址可以用作区域级后端的前端。应用的整体恢复能力受网络服务层级及其关联的后端的冗余的影响。

可用区级服务中断：高级层级和标准层级与区域冗余后端关联时可以提供针对可用区级服务中断的恢复能力。发生可用区级服务中断时，对于使用区域冗余后端的情况，故障切换行为由关联的后端本身决定。与可用区级后端关联时，服务会在服务中断问题得到解决后立即恢复可用。

区域级服务中断：高级层级与全球冗余后端关联时可以提供针对区域级服务中断的恢复能力。在标准层级中，流向受影响区域的所有流量都会失败。流向所有其他区域的流量不会受影响。发生区域级级服务中断时，对于将高级层级与全球冗余后端搭配使用的情况，故障切换行为由关联的后端本身决定。如果将高级层级与区域级后端或标准层级搭配使用，服务会在服务中断问题得到解决后立即恢复可用。

数据包镜像

数据包镜像会克隆 Virtual Private Cloud (VPC) 网络中特定实例的流量，并将克隆的数据转发到区域级内部负载均衡器后面的实例以进行检查。数据包镜像可捕获所有流量和数据包数据，包括载荷和标头。

如需详细了解数据包镜像的功能，请参阅数据包镜像概览页面。

可用区级服务中断：配置内部负载均衡器，以使多个可用区中存在实例。如果发生可用区级服务中断，数据包镜像会将克隆的数据包转移到健康状况良好的可用区。

区域级服务中断：数据包镜像是一个区域级产品。如果存在区域级服务中断，则系统不会克隆受影响区域中的数据包。

Persistent Disk

可用区级和区域级配置中提供了 Persistent Disk。

可用区级 Persistent Disk 托管在单个可用区中。如果可用区级 Persistent Disk 所在的可用区不可用，则在该可用区服务中断解决之前，该 Persistent Disk 无法使用。

区域级 Persistent Disk 可在同一区域中的两个可用区之间同步复制数据。如果虚拟机所在的可用区发生服务中断，您可以将区域级 Persistent Disk 强制挂接到该 Persistent Disk 所在的次要可用区中的虚拟机实例。如需执行此任务，您必须在该可用区中启动另一个虚拟机实例，或者在该可用区中维护一个热备用虚拟机实例。

如需跨区域异步复制永久性磁盘中的数据，您可以使用永久性磁盘异步复制，该功能可提供低 RTO 和 RPO 的块存储复制以实现跨区域主动-被动灾难恢复。万一发生罕见的区域级服务中断，永久性磁盘异步复制使您能够将数据故障切换到次要区域，并在该区域中重启工作负载。

Personalized Service Health

Personalized Service Health 会传达与您的 Google Cloud 项目相关的服务中断情况。它提供多种渠道和流程，方便您查看中断事件（突发事件、计划内维护）或将其整合到突发事件响应流程中，具体包括：

• Google Cloud 控制台中的信息中心
• 服务 API
• 可进行配置的提醒信息
• 已生成并发送到 Cloud Logging 的日志

可用区级服务中断：数据从全球数据库传送，不依赖于特定位置。如果发生可用区级服务中断，Service Health 能够处理请求，并将流量自动重新路由到同一区域内仍可正常运行的可用区。如果 Service Health 能够从 Service Health 数据库中检索事件数据，它就可以成功返回 API 调用。

区域级服务中断：数据从全球数据库传送，不依赖于特定位置。如果发生区域级服务中断，Service Health 仍然可以处理请求，但处理能力可能会降低。Logging 位置中的区域级故障可能会影响 Service Health 用户使用日志或 Cloud Alerting 通知。

Private Service Connect

Private Service Connect 是 Google Cloud 网络的一项功能，允许使用方从其 VPC 网络内部以私密方式访问托管式服务。同样，它允许托管式服务提供方在其各自的 VPC 网络中托管这些服务，并为其使用方提供专用连接。

已发布服务的 Private Service Connect 端点

Private Service Connect 端点使用 Private Service Connect 转发规则连接到服务提供方 VPC 网络中的服务。服务提供方通过公开单个服务连接，使用与服务使用方的专用连接提供服务。然后，服务使用方将能够从其 VPC 为此类服务分配虚拟 IP 地址。

可用区级服务中断：来自使用方 VPC 客户端端点生成的虚拟机流量的 Private Service Connect 流量仍可以访问服务提供方的内部 VPC 网络上的公开托管式服务。这种访问之所以可行，是因为 Private Service Connect 流量会故障切换到另一个可用区中更健康的服务后端。

区域级服务中断：Private Service Connect 是区域级产品。无法应对区域级服务中断。通过在多个区域中配置 Private Service Connect 端点，多区域托管式服务可以在区域级服务中断期间实现高可用性。

Google API 的 Private Service Connect 端点

Private Service Connect 端点使用 Private Service Connect 转发规则连接到 Google API。此转发规则允许客户将自定义端点名称与内部 IP 地址搭配使用。

可用区级服务中断：来自使用方 VPC 客户端端点的 Private Service Connect 流量仍然可以访问 Google API，因为虚拟机和端点之间的连接将自动故障切换到同一区域中其他运行正常的可用区。服务中断开始时已传输的请求将取决于客户端的 TCP 超时和重试恢复行为。

如需了解详情，请参阅 Compute Engine 恢复。

区域级服务中断：Private Service Connect 是区域级产品。无法应对区域级服务中断。通过在多个区域中配置 Private Service Connect 端点，多区域托管式服务可以在区域级服务中断期间实现高可用性。

如需详细了解 Private Service Connect，请参阅 Private Service Connect 类型中的“端点”部分。

Pub/Sub

Pub/Sub 是一种用于应用集成和流式分析的消息传递服务。Pub/Sub 主题是全球性的，这意味着可从任何 Google Cloud 位置查看和访问这些主题。但是，任何给定消息都存储在一个距离发布者最近且资源位置存储政策允许的 Google Cloud 区域中。因此，主题可能会将消息存储在整个 Google Cloud 的不同区域中。Pub/Sub 消息存储政策可以限制存储消息的区域。

可用区级服务中断：发布 Pub/Sub 消息后，系统会将其同步写入相应区域内至少两个可用区中的存储空间。因此，如果一个可用区变得不可用，则对客户没有任何可见的影响。

区域级服务中断：在某区域发生服务中断期间，存储在该区域内的消息无法访问。通过区域端点或全球端点连接到受影响区域的发布方和订阅方无法连接。连接到其他区域的发布方和订阅方仍可以连接，其他区域中的可用消息会传送给距离网络最近且具有容量的订阅方。

如果您的应用依赖于消息排序，请查看 Pub/Sub 团队提供的详细建议。消息排序保证按区域提供，如果您使用全局端点，可能会中断。

reCAPTCHA

reCAPTCHA Enterprise 是一项全球服务，可检测欺诈活动、垃圾邮件和滥用行为。它不需要或允许配置区域级或可用区级弹性。配置元数据的更新会异步复制到运行 reCAPTCHA Enterprise 的每个区域。

如果发生可用区级服务中断，reCAPTCHA Enterprise 将不间断地继续处理来自同一区域或不同区域中的其他可用区的请求。

如果发生区域级服务中断，reCAPTCHA Enterprise 将不间断地继续处理来自另一个区域的请求。

Secret Manager

Secret Manager 是 Google Cloud 的密文和凭据管理产品。借助 Secret Manager，您可以轻松地审核和限制对密文的访问、加密静态密文，并确保 Google Cloud 中的敏感信息安全无虞。

Secret Manager 资源通常使用自动复制政策创建（推荐），从而实现全局复制。如果您的组织具有不允许对密文数据进行全局复制的政策，那么您可以使用用户管理的复制政策创建 Secret Manager 资源，您可以在这些政策中选择一个或多个要将密文复制到的区域。

可用区级服务中断：如果发生可用区级服务中断，Secret Manager 会继续无中断地处理来自同一区域或不同区域中的其他可用区的请求。在每个区域内，Secret Manager 总是会在不同的可用区中维护至少 2 个副本（在大多数区域中，会维护 3 个副本）。该可用区服务中断解决后，完全冗余性将恢复。

区域级服务中断：如果发生区域级服务中断，Secret Manager 会继续无中断地处理来自另一个区域的请求，这里假定数据已复制到多个区域（通过自动复制或通过用户管理的复制）。该区域服务中断解决后，完全冗余性将恢复。

Security Command Center

Security Command Center 是 Google Cloud 的全球实时风险管理平台。它包含两个主要组件：检测器和发现结果。

检测器受到区域和可用区服务中断的影响会有所不同。在区域服务中断期间，检测器无法为区域资源生成新的发现结果，因为应该扫描的资源不可用。

在发生可用区级服务中断期间，检测器可能需要几分钟到几个小时才能恢复正常运行。Security Command Center 不会丢失发现结果数据。它也不会为不可用的资源生成新的发现结果数据。在最坏的情况下，Container Threat Detection 代理可能会在连接到健康状况良好的单元时耗尽缓冲区空间，这可能会导致检测丢失。

发现结果可灵活用于区域和可用区服务中断，因为它们可以跨区域同步复制。

Sensitive Data Protection（包括 DLP API）

Sensitive Data Protection 提供敏感数据分类、剖析、去标识化、令牌化和隐私风险分析服务。它可同步处理请求正文中发送的数据或异步处理 Cloud Storage 系统中已存在的数据。Sensitive Data Protection 可通过全球或区域特定端点进行调用。

全球端点：该服务设计为能够应对区域级和可用区级故障。如果发生故障时服务过载，则发送到服务的 hybridInspect 方法的数据可能会丢失。

如需创建防故障架构，请添加逻辑以检查 hybridInspect 方法生成的最新故障前发现结果。如果发生中断，发送到方法的数据可能会丢失，但不会超过故障事件发生前 10 分钟的时间。如果服务中断之前 10 分钟之前的发现结果，则表示导致发现结果未丢失的数据。在这种情况下，无需重放发现结果时间戳之前的数据，即使这些数据在 10 分钟间隔内也是如此。

区域端点：区域端点不能应对区域故障。如果需要针对区域级故障的恢复能力，请考虑故障切换到其他区域。可用区级故障特征与上述相同。

服务用途

Service Usage API 是 Google Cloud 的一项基础架构服务，可让您列出和管理 Google Cloud 项目中的 API 和服务。您可以列出和管理 Google、Google Cloud 和第三方提供方提供的 API 和服务。Service Usage API 是一项全球性服务，可灵活应对可用区和区域服务中断。如果发生可用区服务中断或区域服务中断，Service Usage API 会继续响应来自不同区域的其他可用区的请求。

如需详细了解 Service Usage，请参阅 Service Usage 文档。

Speech-to-Text

借助 Speech-to-Text，您可以使用神经网络模型等机器学习技术将语音音频转换为文本。音频实时从应用的麦克风发送，或者作为一批音频文件进行处理。

可用区级服务中断：

• Speech-to-Text API v1：在某个可用区发生服务中断期间，Speech-to-Text API 版本 1 会继续从同一区域内的另一个可用区不间断地处理请求。但是，当前正在发生故障的可用区中执行的所有作业都会丢失。用户必须重试失败的作业，这些作业将自动路由到可用的可用区。

• Speech-to-Text API v2：在某个可用区发生服务中断期间，Speech-to-Text API 版本 2 会继续从同一区域内的另一个可用区处理请求。但是，当前正在发生故障的可用区中执行的所有作业都会丢失。用户必须重试失败的作业，这些作业将自动路由到可用的可用区。只有在数据被提交到区域内的仲裁后，Speech-to-Text API 才会返回 API 调用。在某些区域，AI 加速器 (TPU) 只能在一个可用区使用。如果是这种情况，该可用区发生服务中断会导致语音识别失败，但不会丢失数据。

区域服务中断：

• Speech-to-Text API v1：Speech-to-Text API 版本 1 不受区域故障的影响，因为它是一项全球多区域服务。此服务会继续从另一个区域不间断地处理请求。但是，当前正在在故障区域内执行的作业会丢失。用户必须重试失败的作业，这些作业将自动路由到可用区域。

• Speech-to-Text API v2：

  • 多区域 Speech-to-Text API 版本 2，此服务会继续从同一区域内的另一个可用区无中断地处理请求。

  • 单区域 Speech-to-Text API 版本 2，此服务将作业执行范围限定在所请求的区域。Speech-to-Text API 版本 2 不会将流量路由到其他区域，数据也不会复制到其他区域。在某个区域发生故障期间，Speech-to-Text API 版本 2 在该区域不可用。不过，在服务中断问题解决后，它会重新变得可用。

Storage Transfer Service

Storage Transfer Service 可管理从各种云来源到 Cloud Storage 以及与各文件系统之间的数据转移。

Storage Transfer Service API 是一项全球性资源。

Storage Transfer Service 取决于转移作业的来源和目标位置的可用性。如果转移作业的来源或目标位置不可用，则转移作业会停止执行；但客户的核心数据或作业数据并不会丢失。转移作业会在来源和目标位置再次可用时恢复。

无论是否使用代理，您都可以使用 Storage Transfer Service，如下所示：

• 无代理转移作业会使用区域级工作器来编排转移作业。

• 基于代理的转移作业则会使用安装在基础架构上的软件代理。基于代理的转移作业依赖于转移代理的可用性以及代理连接到文件系统的能力。在确定安装转移代理的位置时，请考虑文件系统的可用性。例如，如果您在多个 Compute Engine 虚拟机上运行转移代理来将数据转移到企业级层的 Filestore 实例（区域级资源），则应考虑在 Filestore 实例区域的多个不同可用区内放置虚拟机。

  如果代理变为不可用，或者它们与文件系统的连接中断，则转移作业会停止执行，但不会丢失数据。如果所有代理进程都终止，则转移作业会暂停，直到有新代理添加到转移作业的代理池中为止。

在服务中断期间，Storage Transfer Service 的行为如下：

• 可用区级中断：在发生可用区级中断期间，Storage Transfer Service API 仍然可用，您可以继续创建转移作业。数据会继续转移。

• 区域级中断：在发生区域级中断期间，Storage Transfer Service API 仍然可用，您可以继续创建转移作业。如果转移作业的工作器位于受影响区域，则数据转移会停止，直到该区域再次可用，届时转移作业会自动恢复。

Vertex ML Metadata

借助 Vertex ML Metadata，您可以记录机器学习系统生成的元数据和工件，并查询该元数据以帮助分析、调试和审核机器学习系统或其生成的工件的性能。

可用区性服务中断：在默认配置中，Vertex ML Metadata 会针对可用区性故障提供保护。该服务部署在每个区域的多个可用区，数据在每个区域内的不同可用区中同步复制。如果发生可用区故障，则其余可用区会接管操作并将中断时间缩至最短。

区域级服务中断：Vertex ML Metadata 是一项区域化服务。在发生区域级服务中断时，Vertex ML Metadata 不会故障切换到其他区域。

Vertex AI Batch Prediction

通过批量预测，用户可以在 Google 基础架构上对 AI/机器学习模型运行批量预测。批量预测是一项区域级服务。客户可以选择运行作业的地区，但不能选择该地区内的特定区域。批量预测服务会自动在所选区域内的不同可用区之间对作业进行负载均衡。

可用区级服务中断：批量预测会在区域内存储批量预测作业的元数据。这些数据跨该区域内的多个可用区同步写入。在发生可用区级服务中断时，批量预测会部分丢失执行作业的工作器，但会自动将这些工作器重新添加到其他可用区中。如果多次批量预测重试失败，则界面会在界面和 API 调用请求中将作业状态列为失败。用户运行该作业的后续请求会被路由到可用区域。

区域级服务中断：客户选择要在其中运行批量预测作业的 Google Cloud 区域。数据绝不会跨区域复制。批量预测会将作业执行的范围限定在请求的区域，并且绝不会将预测请求路由到其他区域。发生区域级故障时，批量预测在该区域不可用。服务中断解决后，批量预测会恢复可用。我们建议客户使用多个区域来运行作业。如果某个区域发生服务中断，则将作业定向到其他可用区域。

Vertex AI Model Registry

Vertex AI Model Registry 可让用户在中央存储库中简化机器学习模型的管理、治理和部署。Vertex AI Model Registry 是一种具有高可用性的区域产品，可防范可用区级服务中断。

可用区级服务中断：Vertex AI Model Registry 可防范可用区服务中断。该服务部署在每个区域的三个可用区，数据在该区域内的不同可用区中同步复制。如果某个可用区发生故障，则其余可用区将接管操作，数据不会丢失，服务中断故障也会降到最低程度。

区域级服务中断：Vertex AI Model Registry 是一项区域化服务。如果某个区域发生故障，Model Registry 将不会进行故障切换。

Vertex AI Online Prediction

在线预测可让用户在 Google Cloud 上部署 AI/机器学习模型。在线预测是一项区域级服务。客户可以选择部署模型的区域，但不能选择该区域内的特定可用区。预测服务会自动在所选区域内的不同可用区之间对工作负载进行负载均衡。

可用区级服务中断：在线预测不会存储任何客户内容。可用区级服务中断会导致当前预测请求执行失败。在线预测可能会也可能不会自动重试预测请求，具体取决于所使用的端点类型，具体而言，公共端点会自动重试，而专用端点则不会。为了帮助处理失败并提高弹性，请在您的代码中包含带有指数退避算法的重试逻辑。

区域级服务中断：客户选择要在其中运行 AI/机器学习模型和在线预测服务的 Google Cloud 区域。数据绝不会跨区域复制。在线预测将 AI/机器学习模型执行范围限定在请求的区域，并且绝不会将预测请求路由到其他区域。发生区域级故障时，在线预测服务在该区域中不可用。服务中断解决后，在线预测会恢复可用。我们建议客户使用多个区域来运行其 AI/机器学习模型。如果发生区域级服务中断，将流量定向到其他可用区域。

Vertex AI Pipelines

Vertex AI Pipelines 是一项 Vertex AI 服务，可让您以无服务器方式自动执行、监控和管理机器学习 (ML) 工作流。Vertex AI Pipelines 旨在提供高可用性并防范可用区级故障。

可用区性服务中断：在默认配置中，Vertex AI Pipelines 会针对可用区性故障提供保护。该服务部署在每个区域的多个可用区，数据在该区域内的不同可用区中同步复制。如果发生可用区故障，则其余可用区会接管操作并将中断时间缩至最短。

区域级服务中断：Vertex AI Pipelines 是一项区域化服务。如果某个区域发生服务中断，Vertex AI Pipelines 不会故障切换到其他区域。如果发生区域性服务中断，我们建议您在备用区域中运行流水线作业。

Vertex AI Search

Vertex AI Search 是可自定义的搜索解决方案，具有生成式 AI 功能和原生企业合规性。Vertex AI Search 会在 Google Cloud 内的多个区域中自动部署和复制。您可以通过选择受支持的多区域（例如全球、美国或欧盟）来配置数据的存储位置。

可用区级和区域级服务中断：由于异步复制延迟，上传到 Vertex AI Search 的 UserEvents 可能无法恢复。由于自动故障切换和同步数据复制，Vertex AI Search 提供的其他数据和服务仍然可用。

Vertex AI Training

借助 Vertex AI Training，用户可以在 Google 的基础设施上运行自定义训练作业。Vertex AI Training 是区域级产品，这意味着客户可以选择运行其训练作业的区域。但是，客户无法选择该区域内的特定可用区。训练服务可能会对区域内不同可用区中的作业执行自动进行负载均衡。

可用区级服务中断：Vertex AI Training 会存储自定义训练作业的元数据。此数据按区域存储并同步写入。只有在此元数据被提交到区域内的仲裁后，Vertex AI Training API 调用才会返回。训练作业可能在特定可用区中运行。可用区服务中断会导致当前作业执行失败。如果是这样，则服务会通过将作业路由到其他可用区来自动重试作业。如果多次重试失败，则作业状态会更新为失败。运行该作业的后续用户请求将被路由到可用的可用区。

区域级服务中断：客户选择要在其中运行训练作业的 Google Cloud 区域。数据绝不会跨区域复制。 Vertex AI Training 会将作业执行范围限定在所请求的区域，且绝不会将训练作业路由到其他区域。如果发生区域级故障，则 Vertex AI Training 服务在该区域中不可用，并在服务中断解决后再次可用。我们建议客户使用多个区域来运行其作业，并在发生区域级服务中断故障时，将作业定向到其他可用的区域。

Virtual Private Cloud (VPC)

VPC 是一项为资源提供网络连接的全球级服务（例如虚拟机）。但是，故障是可用区级的。如果发生可用区级故障，则该可用区中的资源将不可用。同样，如果一个区域发生故障，则只有进出故障区域的流量会受到影响。健康状况良好的区域的连接不受影响。

可用区级服务中断：如果 VPC 网络覆盖多个可用区，并且某个可用区发生故障，则 VPC 网络健康状况仍然良好。健康状况良好的可用区中的资源之间的网络流量在故障期间会继续正常运行。可用区级故障只会影响进出故障可用区中的资源的网络流量。为缓解可用区级故障的影响，我们建议您不要在单个可用区中创建所有资源。相反，当您创建资源时，需要将它们分布在多个可用区中。

区域级服务中断：如果 VPC 网络覆盖多个区域，而某个区域发生故障，则 VPC 网络健康状况良好。健康状况良好的区域中的网络流量在故障期间将继续正常运行。区域级故障只会影响进出故障区域中的资源的网络流量。为缓解区域级故障的影响，我们建议您将资源分布到多个区域。

VPC Service Controls

VPC Service Controls 是区域级服务。使用 VPC Service Controls，企业安全团队可以定义精细的边界控制措施，并跨众多 Google Cloud 服务和项目实施此类安全布置。客户政策会在区域范围内镜像。

可用区级服务中断：VPC Service Controls 会不间断地继续处理来自同一区域内其他可用区的请求。

区域级服务中断：在受影响的区域再次可用之前，为受影响的区域强制执行 VPC Service Controls 政策的 API 不可用。如果需要更高的可用性，建议客户将 VPC Service Controls 强制执行的服务部署到多个区域。

Workflows

Workflows 是一种编排产品，让 Google Cloud 客户能够执行以下操作：

• 部署和运行使用 HTTP 连接其他现有服务的工作流。
• 自动执行流程，包括等待 HTTP 响应并自动重试（长达一年时间），以及
• 使用短延迟时间且由事件驱动的执行机制来实现实时处理。

Workflows 客户可以部署工作流来描述要执行的业务逻辑，然后直接通过 API 或事件驱动的触发器（当前仅限于 Pub/Sub 或 Eventarc）运行工作流。正在运行的工作流可以处理变量、进行 HTTP 调用并存储结果，或者定义回调并等待由其他服务继续。

可用区级服务中断：Workflows 源代码不受可用区服务中断的影响。Workflows 会存储工作流的源代码，以及正在运行的工作流收到的变量值和 HTTP 响应。源代码按区域存储并同步写入：控制平面 API 仅在此元数据提交到某一区域内的仲裁后返回。变量和 HTTP 结果也会按区域存储并同步写入，至少每 5 秒存储一次。

如果某个可用区出现故障，则系统会根据上次存储的数据自动继续工作流。但是，尚未收到响应的任何 HTTP 请求都不会自动重试。可以按照文档中所述对可安全重试的请求使用重试政策。

区域级服务中断：Workflows 是一项区域化服务；在发生区域级服务中断的情况下，Workflows 不会进行故障切换。如果需要更高的可用性，建议客户将 Workflows 部署到多个区域。

Cloud Service Mesh

借助 Cloud Service Mesh，您可以配置跨多个 GKE 集群的托管式服务网格。本文档仅涉及托管式 Cloud Service Mesh，集群内变体是自托管的，应遵循常规平台准则。

可用区级服务中断：只要集群位于区域级，网格配置（存储在 GKE 集群中）就可以适应可用区级服务中断。产品用于内部簿记的数据按区域或全局存储，如果单个可用区已停止使用，则不受影响。控制平面在其支持的 GKE 集群所在的区域中运行（对于可用区级集群，控制平面为包含集群），并且不受单个可用区内服务中断的影响。

区域级服务中断：Cloud Service Mesh 向 GKE 集群（区域级或可用区级）提供服务。发生区域级服务中断时，Cloud Service Mesh 不会进行故障切换。GKE 也不适用。我们鼓励客户部署由覆盖不同区域的 GKE 集群组成的网格。

Service Directory

Service Directory 是一个发现、发布和连接服务的平台。它集中在一个地方提供您的所有服务的相关实时信息。无论您的服务端点是只有几个还是数以千计，Service Directory 都可让您大规模执行服务目录管理。

Service Directory 资源按区域创建，且与用户指定的位置参数匹配。

可用区级服务中断：在发生可用区级服务中断期间，Service Directory 会继续无中断地处理来自同一区域或不同区域中的其他可用区的请求。在每个区域内，Service Directory 始终会维护多个副本。该可用区服务中断解决后，完全冗余性将恢复。

区域级服务中断：Service Directory 不能应对区域级服务中断。