Google Cloud 基础架构服务可在全球多个位置运行。这些位置分为称作区域和可用区的故障域，这些故障域是为云工作负载设计可靠基础架构的基础组件。
故障域是可以独立于其他资源失败的资源或资源组。独立 Compute Engine 虚拟机是故障域的资源示例。Google Cloud 区域或可用区是包含一组资源的故障域示例。如果应用以冗余方式分布在故障域中，它可以实现比每个故障域提供的更高的可用性聚合级别。
Google Cloud 基础设施可靠性指南的这一部分介绍了 Google Cloud 中的可靠性组件以及它们如何影响云资源的可用性。
区域和可用区
Google Cloud 区域是独立的地理位置。每个 Google Cloud 区域包含多个可用区。一个可用区中的故障不太可能影响其他可用区中的基础架构。全球网络主干可在所有 Google Cloud 可用区和区域中提供高带宽、短延时的连接。
平台可用性
Google Cloud 基础设施旨在容忍故障并从故障中恢复。Google 持续对创新方法进行投资，以维护和提高 Google Cloud 的可靠性。Google Cloud 基础设施的以下功能有助于为您的云工作负载提供可靠的平台：
- 地理位置分隔的区域，以缓解自然灾害和区域服务中断对全球服务的影响。
- 硬件冗余和复制，以避免单点故障。
- 在维护事件期间实时迁移资源。例如，在计划的基础架构维护期间，您可以使用实时迁移将 Compute Engine 虚拟机移至同一可用区中的其他主机。
- 为 Google Cloud 运行的物理基础设施和软件提供从设计上保证安全的基础设施基础，以及用于保护您的数据和工作负载的运营安全控制措施。如需了解详情，请参阅 Google 基础设施安全设计概览。
- 使用高级软件定义网络 (SDN) 管理方法的高性能骨干网，具有边缘缓存服务，可实现一致的性能。
- 持续监控和报告。您可以使用 Google Cloud Service Health 信息中心查看每个位置的 Google Cloud 服务状态。
- 公司范围的年度灾难恢复测试 (DiRT) 事件，可确保 Google Cloud 服务和内部业务运营在灾难期间继续运行。
Google Cloud 基础设施旨在支持大多数客户工作负载的以下目标可用性级别：
| 部署位置 | 可用性（正常运行时间）% | 预计的最长停机时间 |
|---|---|---|
| 单个可用区 | 3 个 9：99.9% | 30 天一个月中的 43.2 分钟 |
| 同一区域中的多个可用区 | 4 个 9：99.99% | 30 天一个月中的 4.3 分钟 |
| 多个区域 | 5 个 9：99.999% | 30 天一个月中的 26 秒 |
上表中的可用性百分比是目标。特定 Google Cloud 服务的正常运行时间服务等级协议 (SLA) 可能与这些可用性目标不同。例如，Bigtable 实例的正常运行时间服务等级协议 (SLA) 取决于集群的数量、它们在各个位置的分布以及您配置的路由政策。
如果配置了多集群路由政策，则包含三个或更多区域的集群的 Bigtable 实例的正常运行时间服务等级协议 (SLA) 下限为 99.999%。但是，如果配置了单集群路由政策，则无论集群数量及其分布如何，正常运行时间服务等级协议 (SLA) 下限为 99.9%。
本部分中的图表显示了不同集群大小的 Bigtable 实例，以及其正常运行时间服务等级协议 (SLA) 的后续差异。
单集群
下图显示了单集群 Bigtable 实例，其中正常运行时间服务等级协议 (SLA) 下限为 99.9%：
多个集群
下图展示了单个区域内多个可用区的多集群 Bigtable 实例，它采用多集群路由（正常运行时间服务等级协议 (SLA) 下限：99.99%）：
多个集群
下图显示了三个区域的多集群 Bigtable 实例，具有多集群路由（正常运行时间服务等级协议 (SLA) 下限：99.999%）：
总体基础架构可用性
如需在 Google Cloud 中运行应用，请使用虚拟机和数据库等基础架构资源。这些基础架构资源共同构成应用的基础架构堆栈。
下图展示了 Google Cloud 中的基础架构栈堆栈示例以及堆栈中每个资源的可用性 SLA：
此示例基础架构堆栈包括以下 Google Cloud 资源：
- 区域级外部应用负载均衡器接收并响应用户请求。
- 区域级托管式实例组 (MIG) 是区域级外部应用负载均衡器的后端。该 MIG 包含两个位于不同可用区的 Compute Engine 虚拟机。每个虚拟机托管一个 Web 服务器实例。
- 内部负载均衡器处理 Web 服务器与应用服务器实例之间的通信。
- 第二个区域级 MIG 是内部负载均衡器的后端。该 MIG 包含两个位于不同可用区的 Compute Engine 虚拟机。每个虚拟机托管一个应用服务器实例。
- 进行了 HA 配置的 Cloud SQL 实例是应用的数据库。主数据库实例会同步复制到备用数据库实例。
如上述示例所示，可从基础架构堆栈获得的总体可用性取决于以下因素：
Google Cloud SLA
您在基础架构栈中使用的 Google Cloud 服务的正常运行时间 SLA 会影响可从该堆栈获得的最低总体可用性。
下表对某些服务的正常运行时间 SLA 进行了比较：
| 计算服务 | 每月正常运行时间 SLA | 预计一个月（30 天）内的最长停机时间 |
|---|---|---|
| Compute Engine 虚拟机 | 99.9% | 43.2 分钟 |
| 多个可用区中的 GKE Autopilot Pod | 99.9% | 43.2 分钟 |
| Cloud Run 服务 | 99.95% | 21.6 分钟 |
| 数据库服务 | 每月正常运行时间 SLA | 预计一个月（30 天）内的最长停机时间 |
|---|---|---|
| Cloud SQL for PostgreSQL 实例（企业版） | 99.95% | 21.6 分钟 |
| AlloyDB for PostgreSQL 实例 | 99.99% | 4.3 分钟 |
| Spanner 多区域实例 | 99.999% | 26 秒 |
如需了解其他 Google Cloud 服务的 SLA，请参阅 Google Cloud 服务等级协议。
如上表所示，您为基础架构堆栈的每一层选择的 Google Cloud 服务都会直接影响可从基础架构堆栈获得的总体正常运行时间。如需提高在 Google Cloud 资源上部署的工作负载的预期可用性，您可以预配资源的冗余实例，如下一部分所述。
资源冗余
资源冗余意味着预配一个资源的两个或多个相同实例，并在组中的所有资源上部署相同的工作负载。例如，如需托管应用的 Web 层级，您可以预配一个包含多个相同 Compute Engine 虚拟机的 MIG。
如果您以冗余方式将一组资源分布在多个故障域（例如两个 Google Cloud 可用区），则可从该组获得的资源可用性高于该组中每个资源的正常运行时间 SLA。可用性更高是因为该组中的每个资源同时发生故障的概率低于单个故障域中资源发生协调故障的概览。
例如，如果一个资源的可用性 SLA 为 99.9%，则该资源发生故障的概率为 0.001（1 减去 SLA）。如果您将工作负载分布在此资源的两个实例（在单独的故障域中预配）中，则这两个资源同时发生故障的概率为 0.000001（即 0.001 x 0.001）。对于两个资源的组，此故障概率会转换为理论上的可用性 99.9999%。但是，您可以预计的实际可用性仅限于部署位置的目标可用性：如果资源位于单个 Google Cloud 可用区中，则为 99.9%；对于多可用区部署为 99.99%；如果冗余资源分布在多个区域中，则为 99.999%。
堆栈深度
基础架构堆栈的深度是堆栈中不同层级（或层）的数量。基础架构堆栈中的每个层级都包含资源，可为应用提供不同的功能。例如，三层式堆栈中的中间层可以使用 Compute Engine 虚拟机或 GKE 集群来托管应用服务器。基础架构堆栈中的每个层级通常与其相邻层级密切相关。这意味着，如果堆栈的任何层级不可用，则整个堆栈都会变得不可用。
您可以使用以下公式来计算 N 层式基础架构堆栈的预期总体可用性：
例如，如果三层式堆栈中的每个层级都设计为提供 99.9% 的可用性，则堆栈的总体可用性约为 99.7% (0.999 x 0.999 x 0.999)。这意味着多层式堆栈的总体可用性低于提供最低可用性的层级的可用性。
随着堆栈中相互依赖的层级数量的增加，堆栈的总体可用性会降低，如下表所示。表中的每个示例堆栈具有不同的层级数。为了便于比较，假定每个层级都提供 99.9% 的可用性。
| 层级 | 堆栈 A | 堆栈 B | 堆栈 C |
|---|---|---|---|
| 前端 | 99.9% | 99.9% | 99.9% |
| 应用层级 | 99.9% | 99.9% | 99.9% |
| 中间层级 | – | 99.9% | 99.9% |
| 数据层级 | – | – | 99.9% |
| 堆栈的总体可用性 | 99.8% | 99.7% | 99.6% |
| 预计一个月（30 天）内堆栈的最长停机时间 | 86 分钟 | 130 分钟 | 173 分钟 |
设计考虑事项摘要
在设计应用时，请考虑 Google Cloud 基础架构堆栈的总体可用性。
- 基础架构堆栈中每个 Google Cloud 资源的可用性会影响堆栈的总体可用性。选择 Google Cloud 服务来构建基础架构堆栈时，请考虑服务的可用性 SLA。
- 如需提高资源提供的功能（例如计算或数据库）的可用性，您可以预配资源的冗余实例。在设计具有冗余资源的架构时，除了可用性好处之外，您还必须考虑对运营复杂性、延迟时间和费用的潜在影响。
- 基础架构堆栈中的层级数（即堆栈的深度）与堆栈的总体可用性具有反向关系。在设计或修改堆栈时，请考虑这种关系。
如需查看计算总体可用性的示例，请参阅以下部分：
位置范围
Google Cloud 资源的位置范围决定了基础设施故障对资源的影响程度。您在 Google Cloud 中预配的大多数资源具有以下位置范围之一：可用区、区域、多区域或全球。
某些资源类型的位置范围是固定的；也就是说，您无法选择或更改位置范围。例如，Virtual Private Cloud (VPC) 网络是全球性资源，Compute Engine 虚拟机 (VM) 是可用区级资源。对于某些资源，您可以在预配资源时选择位置范围。例如，创建 Google Kubernetes Engine (GKE) 集群时，您可以选择创建可用区或区域 GKE 集群。
以下各部分更详细地介绍了位置范围。
可用区级资源
可用区级资源部署在 Google Cloud 区域的单个可用区内。以下是可用区级资源的示例。该列表并不详尽。
- Compute Engine 虚拟机
- 可用区代管式实例组 (MIG)
- 可用区永久性磁盘
- 单可用区 GKE 集群
- Filestore 基本实例和可用区实例
- Dataflow 作业
- Cloud SQL 实例
- Compute Engine 上的 Dataproc 集群
一个可用区中的故障可能会影响该可用区内预配的可用区级资源。可用区旨在最大限度地降低与区域中其他可用区相关的故障的风险。一个可用区中的故障通常不会影响区域内其他可用区的资源。此外，一个可用区中的故障不一定会导致该可用区中的所有基础架构都不可用。该可用区只是定义故障影响的预期边界。
为了保护使用可用区级资源的应用免受可用区突发事件的影响，您可以在多个可用区或区域之间分布或复制资源。如需了解详情，请参阅在 Google Cloud 中为工作负载设计可靠的基础设施。
区域资源
区域级资源在区域内的多个可用区中以冗余方式部署。以下是区域级资源的示例。该列表并不详尽。
- 区域级 MIG
- 区域 Cloud Storage 存储桶
- 区域永久性磁盘
- 使用默认（多可用区）配置的区域 GKE 集群
- VPC 子网
- 区域外部应用负载均衡器
- 区域级 Spanner 实例
- Filestore Enterprise 实例
- Cloud Run 服务
区域级资源可以适应特定可用区中的突发事件。区域服务中断可能会影响该区域内预配的部分或全部区域级资源。此类服务中断可能是由自然灾害或大规模基础设施故障引起的。
多区域资源
多区域资源分布在特定区域。以下是多区域资源的示例。该列表并不详尽。
- 双区域和多区域 Cloud Storage 存储桶
- 多区域 Spanner 实例
- 多集群（多区域）Bigtable 实例
- Cloud Key Management Service 中的多区域密钥环
如需查看多区域配置中可用的 Google 服务的完整列表，请参阅各位置可使用的产品。
多区域资源可以灵活应对特定区域和可用区中的突发事件。多个区域中发生的基础架构服务中断可能会影响受影响区域中预配的部分或所有多区域资源的可用性。
全球性资源
全球性资源可在所有 Google Cloud 位置使用。以下是全球性资源的示例。该列表并不详尽。
项目。如需了解将 Google Cloud 资源整理到文件夹和项目的指南和最佳实践，请参阅确定 Google Cloud 着陆区的资源层次结构。
VPC 网络，包括关联的路由和防火墙规则
Cloud DNS 区域
全局外部应用负载均衡器
Cloud Key Management Service 中的全球密钥环
Pub/Sub 主题
Secret Manager 中的 Secret
如需查看可在全球范围内使用的 Google 服务的完整列表，请参阅全球产品。
全球性资源能够灵活应对可用区和区域突发事件。这些资源不依赖于任何特定区域的基础设施。Google Cloud 的系统和流程可帮助最大限度地降低全球基础架构服务中断的风险。Google 还会持续监控基础架构，并快速解决任何全球服务中断故障。
下表汇总了可用区、区域、多区域以及全球性资源相对于应用和基础架构问题的弹性。此外，它还介绍了设置这些资源所需的工作，以及缓解服务中断影响的建议。
| 资源范围 | 弹性 | 缓解基础架构服务中断影响的建议 |
|---|---|---|
| 可用区级 | 低 | 在多个可用区或区域中以冗余方式部署资源。 |
| 区域级 | 中 | 以冗余方式在多个区域中部署资源。 |
| 多区域或全球 | 高 | 请谨慎管理更改，并尽可能使用纵深防御回退。如需了解详情，请参阅管理全球性资源服务中断的风险的建议。 |
管理全球性资源服务中断风险的建议
如需利用全球性资源在可用区和区域服务中断时的恢复能力，您可以考虑在架构中使用某些全球性资源。 Google 推荐以下方法来管理全球性资源服务中断的风险：
谨慎管理全球性资源的变化
全球性资源能够灵活应对物理故障。此类资源的配置是全球范围的。因此，设置和配置单个全球性资源比操作多个区域级资源更容易。但是，全球性资源配置中的严重错误可能会成为单点故障 (SPOF)。例如，您可以将全球负载均衡器用作分布在不同地理位置的应用的前端。全球负载均衡器通常是此类应用的理想选择。但是，此负载均衡器的配置错误可能会导致它在所有地理位置不可用。为避免此风险，您必须谨慎管理全球性资源的配置更改。如需了解详情，请参阅控制对全球性资源的更改。
使用区域级资源作为深度防御措施
对于可用性要求极高的应用，区域深度防御措施有助于最大限度地减少全球性资源服务中断的影响。考虑将全球负载均衡器作为前端的地理分布应用示例。如需确保在即使全球负载均衡器受到全球服务中断的影响时应用仍可访问，您可以部署区域负载均衡器。您可以将客户端配置为首选全球负载均衡器，但如果全球负载均衡器不可用，则通过故障切换机制改用最近的区域负载均衡器。
具有可用区级资源、区域级资源和全球性资源的示例架构
您的云拓扑可以包含可用区、区域和全球性资源的组合，如下图所示。下图展示了在 Google Cloud 中部署的多层应用的示例架构。
如上图所示，全球外部 HTTP/S 负载均衡器接收客户端请求。负载均衡器将请求分配给后端，后端是具有两个 Compute Engine 虚拟机的区域 MIG。在虚拟机上运行的应用对 Cloud SQL 数据库执行数据读写操作。数据库已配置为具有高可用性。数据库的主实例和备用实例在单独的可用区中预配，并且主数据库会同步复制到备用数据库。此外，数据库会自动备份到 Cloud Storage 中的多区域存储桶。
下表汇总了上述架构中的 Google Cloud 资源，以及每个资源对可用区和区域服务中断的恢复能力：
| 资源 | 对服务中断的恢复能力 |
|---|---|
| VPC 网络 | VPC 网络（包括关联的路由和防火墙规则）属于全球性资源。它们可以灵活应对可用区和区域服务中断。 |
| 子网 | VPC 子网属于区域级资源。它们能够灵活应对可用区服务中断。 |
| 全球外部 HTTP/S 负载均衡器 | 全球外部 HTTP/S 负载均衡器可以灵活应对可用区和区域服务中断。 |
| 区域 MIG | 区域 MIG 能够灵活应对可用区服务中断。 |
| Compute Engine 虚拟机 | Compute Engine 虚拟机是可用区级资源。如果可用区服务中断，各个 Compute Engine 虚拟机可能会受到影响。但是，应用可以继续处理请求，因为负载均衡器的后端是区域 MIG，而不是独立虚拟机。 |
| Cloud SQL 实例 | 此架构中的 Cloud SQL 经过配置可实现高可用性；也就是说，部署包括一个主备用数据库实例对。系统会使用区域永久性磁盘将主数据库同步复制到备用数据库。
|
| 多区域 Cloud Storage 存储桶 | 存储在多区域 Cloud Storage 存储桶中的数据可以适应单区域服务中断。 |
| 永久性磁盘 | 永久性磁盘可以是可用区级磁盘，也可以是区域级磁盘。区域永久性磁盘可以适应可用区服务中断。为了做好准备以便从区域服务中断中恢复，您可以安排永久性磁盘的快照，并将快照存储在多区域 Cloud Storage 存储桶中。 |