地理位置和地区

Google Cloud 产品由特定的区域性故障网域提供,并受到服务等级协议的全面支持,以确保您在 Google Cloud 的结构中设计应用架构。

Google Cloud 基础设施服务目前可在北美洲、南美洲、欧洲、亚洲、中东和澳洲的多个位置使用。这些位置分为区域和可用区。您可以根据延迟时间、可用性和耐用性要求,选择要将您的应用部署在哪些位置。

自行试用

如果您是 Google Cloud 新手,请创建一个账号来评估我们的产品在实际场景中的表现。新客户还可获享 $300 赠金,用于运行、测试和部署工作负载。

免费开始使用

区域和可用区

区域是独立的地理位置,由多个地区组成。可用区和区域是对底层物理资源的逻辑抽象。区域由 3 个或更多可用区组成,这些可用区位于 3 个或更多物理数据中心内。墨西哥、大阪和蒙特利尔有三个可用区,位于一个或两个物理数据中心内。这些区域目前正在扩展到至少三个物理数据中心。在 Google Cloud 中构建解决方案时,请参考 Cloud 位置Google Cloud Platform 服务等级协议以及适当的 Google Cloud 产品文档中的指南。

这些数据中心可能归 Google 所有,并列在 Google Cloud 位置页面上,也可能从第三方数据中心提供商租用。如需查看 Google Cloud 的数据中心位置的完整列表,请参阅我们的 ISO/IEC 27001 证书。无论数据中心是自有还是租赁,Google Cloud 都会选择数据中心并设计其基础架构,以提供一致的性能、安全性和可靠性。

地区是区域中用于部署 Google Cloud 资源的位置。可用区应被视为区域中的一个故障域。如需部署具备高可用性的容错应用以及防范意外故障,请跨区域中的多个可用区部署您的应用。

为了防止因自然灾害导致整个区域服务中断,请制定一项灾难恢复计划,并了解如何在主要区域服务中断的情况下(这种情况不太可能发生)启动您的应用。如需了解详情,请参阅应用部署考虑因素

如需详细了解每个位置选项中提供的特定资源,请参阅我们的 Cloud 位置

Google Cloud 的服务和资源可以是可用区性区域性的,也可以由 Google 跨多个区域进行管理。如需详细了解这些方案对您数据的影响,请参阅数据的地理位置管理

Google Cloud 打算在每个通用区域提供至少三个可用区(在物理和逻辑方面均不相同的可用区)。

可用区级资源

地区资源在单个地区内运作。地区服务中断可能会影响该地区中的部分或全部资源。可用区级资源的一个示例是:位于特定可用区内的 Compute Engine 虚拟机 (VM) 实例。

区域资源

区域资源是跨某个区域中的多个地区以冗余方式部署的资源,例如 App Engine 应用或区域性代管式实例组。因此,与地区资源相比,区域资源具有较高的可用性。

多区域资源

由 Google 管理的多项 Google Cloud 服务是分布在相同区域内的不同地区之间的冗余服务。这些服务有助于优化可用性、性能和资源效率。因此,这些服务需要在延迟时间或一致性模型间进行权衡。如需了解具体权衡,请参阅与特定产品相关的文档。

除了任何区域位置外,以下服务还具有一个或多个多区域位置

  • Artifact Registry
  • Bigtable
  • 敏感数据保护
  • Cloud Healthcare API
  • Cloud KMS
  • Container Registry
  • Spanner
  • Cloud Storage
  • Database Migration Service
  • Datastore
  • Firestore

这些多区域服务的设计初衷是为了能够在单个区域丢失后正常运行。

如需了解详情,请参阅各区域可使用的产品以及各产品的文档。

全球均可运行的服务

Google Cloud 的设计初衷是为了支持全球的运营,持续全天候处理维护和升级工作,而无需您进行干预。我们的全球骨干可提供极大的灵活性以实现负载均衡,并通过靠近您进行互连来缩短最终用户延迟时间。我们的全球云管理平面简化了管理多区域开发的工作。

内部服务

为许多面向客户的 Google Cloud 服务提供支持是一组久经考验的内部服务,例如 Spanner、Colossus、Borg 和 Chubby。

这些内部服务可在多个区域间进行全局负载均衡,或者专用于其中提供了这些服务的每个可域。如果服务在多个区域之间实现负载均衡,我们将按区域逐步部署更新,这有助于检测并解决问题,而不会影响您的服务使用情况。这些内部服务都不限于单个逻辑数据中心或单个区域。

全球内部服务可在以下云区域中运行或复制:

美洲

  • southamerica-west1
  • us-central1
  • us-east1
  • us-east4
  • us-west1
  • us-west4

欧洲

  • europe-north1
  • europe-west1
  • europe-west4

亚洲

  • asia-east1
  • asia-southeast1

服务依赖项

一般来说,对于 Google Cloud 服务,如果单个区域发生故障,则只有该区域中的客户会受到影响,使用多区域产品的客户不受影响。Google Cloud 提供强大的架构,致力于防止跨区域的关联故障。

所有 Google Cloud 服务都依靠核心内部工具来提供基本服务,例如网络(进出数据中心)、访问数据中心以及身份授权系统。这些工具可灵活应对区域性服务中断,其目标是当某个区域不可用时,另一个区域不受影响。

Google Cloud 提供明确的指导(特别是针对 Compute Engine、BigQuery、Pub/Sub 等常用的 Google Cloud 产品),向客户介绍如何在我们的公共网站上构建应用以实现所需的弹性。

下面列出了我们的主要依赖项,从所有服务通用的依赖项开始,但较低级层的实现详情随时可能更改。

所有服务的通用依赖项

  • 用于身份验证和授权的身份数据层面
  • 提供日志记录、元数据存储和工作流的内部服务
  • 对 Google Cloud API 的访问依赖于 DNS、全球分布的负载均衡器和接入点 (PoP)。
  • 全球性资源的配置:例如,IAM 政策、全局防火墙规则、全球负载均衡器配置和 Pub/Sub 主题存储在复制的数据库中。
  • 当 Google Cloud 服务向客户控制的端点发送请求(例如 Cloud EKM 提取客户密钥或 Pub/Sub 传送消息)时,这些请求依赖于我们的全球网络基础架构来访问这些客户控制端点

具有其他依赖项的服务

  • Compute Engine 服务
    • Google Cloud 虚拟机和 Persistent Disk 数据层面依赖于较低级层的 Compute Engine 和 Cloud Storage 服务(如 Borg 和 Colossus)。
  • Google Cloud 和基础架构存储服务(如 Spanner、Bigtable 和 Cloud Storage)依赖于:
    • 面向客户的加密和密钥管理基础架构 (Cloud KMS/Cloud EKM) 以及面向 Google 拥有的密钥的内部基础架构
    • 提供数据访问的日志记录和审核的内部服务
    • 内部数据复制服务,可在多个区域提供数据
    • 明确配置的到其他区域的备份和复制依赖于跨区域网络
  • 通讯服务
    • Pub/Sub 依赖于我们的全球网络基础架构访问客户控制的端点
  • 网络服务
    • 全球负载均衡、DNS 和区域间的故障切换都依赖于物理网络基础架构。
    • 防止 DDos 攻击等功能依赖于较低级层的 Compute Engine 基础架构。
  • GKE 和 Cloud SQL 等代管式和托管式服务
    • 依赖于 Compute Engine 以及存储虚拟机映像的 Container Registry 或 Artifact Registry。
  • 独立的低级层基础架构
    • 我们的内部集群级控制平面(包括 Borg 和网络结构)
    • 集群级存储,例如 Colossus
    • 加密和密钥管理基础架构

维护和改善可用性和弹性

站点可靠性工程 (SRE) 是 Google 的内部组织,专注于可用性、延迟时间、性能和容量。服务中断和服务不可用与新代码部署或环境更改相关。SRE 深刻理解必要的更改可能会导致服务停机,并借鉴行业最佳做法,在发布新软件的需求和保障环境安全之间取得平衡。

与客户合作构建弹性服务

如果您有重要的关键需求,并且需要设计架构以实现弹性和灾难恢复,我们的 SRE/CRE 和 PSO 团队将与您合作构建应用以桥接多个区域和地区,并可进一步帮助您设计高可用性 (HA) 系统。

如果您在特定日期(如黑色星期五/网购星期一)有更高的可用性要求,则 Google Cloud 会有意与您协作,让您能够检查并验证在 Google Cloud 中运行的特定应用,并识别应用与服务之间任何意外的服务依赖项。

入网点 (POP)

Google 运营着一个全球对等互连点网络,这意味着客户流量可以在 Google 网络内部传输,直至其靠近目的地,从而为用户提供更好的体验和更好的安全性。如需了解详情,请参阅网络边缘位置

数据的地理位置管理

Google Cloud 服务的数据存储区域受服务条款(包括服务专用条款)的约束。Google 了解,每位客户可能都有独特的安全性和合规性需求。Google Cloud 销售团队可以帮助您满足您的要求。

使用区域或地区存储资源时,我们强烈建议您将数据复制到另一个区域,或截取数据快照并存储到一个多区域存储资源,以用于进行灾难恢复。

应用部署考虑因素

若想构建具备高可用性的服务和应用,以便能够应对地区不可用这一情况

使用以下资源:

  • 区域资源(例如 App Engine 应用、区域代管实例组)或代管式多区域资源(例如 Cloud Storage、Datastore、Firestore 或 Spanner)。
  • 地区资源,例如 Compute Engine 虚拟机,但您需要跨地区或跨区域管理自己的计算和存储冗余性。
若想构建具备灾难恢复能力的应用,以便能够应对整个区域长期服务中断的情况

对于数据,请使用以下一种或多种策略:

  • 使用代管式多区域存储服务,例如 Cloud Storage、Datastore、Firestore 或 Spanner。
  • 使用地区资源或区域资源,但需要截取数据快照并存储到 Cloud Storage、Datastore、Firestore 或 Spanner 等多区域资源。
  • 使用地区或区域资源,但需要将您自己的数据复制到一个或多个其他区域。

对于计算,请使用以下策略:

  • 使用 Compute Engine 或 App Engine 等可用区资源或区域资源,但如果数据尚未包含在代管式多区域资源中,则当发生区域故障时,您需要在另一个引用主数据副本的区域中手动或自动启动您的应用。

如需详细了解服务依赖项,请与销售人员联系

额外的解决方案和教程

以下解决方案和教程介绍了如何确保您的应用具备高可用性并能够应对服务中断的情况:

构建可扩缩且弹性佳的应用时应遵循的模式

了解如何借助 Google Cloud,采用广泛适用于任何 Web 应用的模式和做法来构建可扩缩的弹性应用架构。

创建 HTTPS 负载均衡器

在不同区域中配置 Compute Engine 实例,同时使用 HTTP 负载均衡在不同区域之间分配流量,从而提高跨区域的可用性,并在服务中断时提供故障切换服务。

设计可靠的系统

在 Compute Engine 服务上设计稳健可靠的应用,使之能够抵御故障、网络中断和意外灾难。

使用 Cloud Storage 进行 Cassandra 备份和恢复

了解如何通过将数据备份到 Cloud Storage 并从 Cloud Storage 中恢复数据,为 Cassandra 安装添加基本灾难恢复能力。

灾难恢复规划指南

了解使用 Google Cloud 设计和测试灾难恢复计划的一般原则。