设计工作负载架构

Last reviewed 2024-07-24 UTC

本文档可帮助您设计工作负载,以最大限度地减少未来将工作负载扩展和迁移到其他 Google Cloud 区域的影响,或最大限度地减少跨区域迁移工作负载的影响。如果您计划执行上述任何活动,或者正在评估未来执行这些活动的机会并想了解具体工作内容,本文档会非常有用。

本文档是以下系列文章中的一篇:

如果您不打算跨区域迁移或提前扩展到多个区域,则本系列中的指南也非常有用。在这种情况下,您可能需要花费额外的精力来准备基础架构、工作负载和数据,以便进行跨区域迁移以及扩展到多个区域。

本文档可帮助您执行以下操作:

  1. 准备着陆可用区
  2. 准备工作负载以进行跨区域迁移
  3. 准备计算资源
  4. 准备数据存储资源
  5. 准备停用来源环境

准备着陆可用区

本部分重点介绍了在跨区域迁移时,您必须考虑的着陆可用区(也称为云基础)扩展注意事项。

第一步是重新评估任何现有着陆可用区的各个方面。您必须已部署着陆可用区,然后才能迁移任何工作负载。虽然您可能已为托管工作负载的区域部署着陆可用区,但着陆可用区可能不支持在其他区域中部署工作负载,因此必须扩展到目标区域。某些已部署的着陆可用区的设计可以支持其他区域,而无需对着陆可用区进行大量返工(例如身份和访问权限管理或资源管理)。不过,网络或数据等其他因素可能需要您为扩展进行一些规划。重新评估过程应考虑工作负载的主要要求,以便可建立一个以后在迁移过程中可以实现专用化的通用基础。

企业注意事项

当涉及到行业和政府标准、法规及认证等方面时,将工作负载迁移到另一个区域可能会有不同的要求。在实际位于不同国家/地区的 Google 区域上运行的工作负载必须遵守该国家/地区的法律法规。此外,不同的业界标准可能对在国外运行的工作负载有特定要求(特别是在安全性方面)。由于 Google Cloud 区域是为在单个国家/地区运行资源而构建的,因此有时工作负载会从另一个 Google 区域迁移到该国家/地区,以遵守特定法规。当您执行这些“国家/地区内”迁移时,请务必重新评估在本地运行的数据,以检查新区域是否允许将数据迁移到 Google Cloud。

身份和访问权限管理

在规划迁移时,对于已在 Google Cloud 中的区域,您可能无需规划太多身份和访问权限变更。Google Cloud 上的身份决策以及资源访问权限通常基于资源的性质,而不是资源运行的区域。您可能需要考虑以下一些事项:

  • 团队设计:某些公司的结构设计为让不同的团队来处理不同的资源。当工作负载迁移到另一个区域时,由于资源结构发生变化,其他团队可能会成为负责某些资源的最佳候选,在这种情况下,应相应地调整访问权限。
  • 命名规则:虽然命名规则可能不会对功能产生任何技术影响,但如果存在使用引用特定区域的命名规则定义的资源,那么可能需要考虑一些注意事项。以下情况是一个典型示例:已部署了多个复制区域,例如 Compute Engine 虚拟机 (VM),它们以区域作为前缀来命名,例如 europe-west1-backend-1。在迁移过程中,为避免混乱,甚至是发生破坏依赖于特定命名规则的流水线这种更糟糕的情况,请务必更改名称以反映新区域。

连接性与网络

您的网络设计会影响迁移执行方式的多个方面,因此在规划如何迁移工作负载之前解决此设计问题十分重要。

请记住,与 Google Cloud 的本地连接是您必须在迁移中重新评估的因素之一,因为它可以设计为特定于区域。此因素的一个示例是 Cloud Interconnect,它通过与特定区域的 VLAN 连接来连接到 Google Cloud。您必须先更改连接 VLAN 连接的区域,然后才能关闭该区域,以避免区域间流量。另一个需要考虑的因素是,如果您在使用合作伙伴互连,则迁移区域可帮助您选择不同的物理位置,以用于将 VLAN 连接连接到 Google Cloud。如果您使用 Cloud VPN 并决定在迁移过程中更改子网地址,那么也需要考虑此注意事项:您必须重新配置路由器以反映新网络。

虽然 Google Cloud 上的虚拟私有云 (VPC) 是全球性资源,但单个子网会始终绑定到某个区域,这意味着在迁移后,您不能将相同的子网用于工作负载。由于子网不能是重叠的 IP,因此为了保持相同的地址,您应创建新 VPC。如果您使用的是 Cloud DNS,则此过程会简化,Cloud DNS 可以利用 DNS 对等互连等功能,在关闭旧区域之前路由所迁移工作负载的流量。

如需详细了解如何在 Google Cloud 上构建基础,请参阅迁移到 Google Cloud:规划和构建您的基础

准备工作负载以进行跨区域迁移

无论您是在 Google Cloud 上设置基础架构并计划以后迁移到另一个区域,还是已经在使用 Google Cloud 并需要迁移到另一个区域,都必须确保可以通过最简单直接的方式迁移工作负载,以减少工作量并最大限度地降低风险。为帮助您确保所有工作负载都处于允许实施迁移路径的状态,我们建议您采用以下方法:

  • 首选易于复制且与特定网络拓扑松散耦合的网络设计。Google Cloud 提供了不同的产品,可帮助您将当前网络配置与使用该网络的资源分离。Cloud DNS 是这类产品的一个示例,可让您将内部子网 IP 与虚拟机分离。
  • 设置支持多区域配置或全球配置的产品。支持涉及多个区域的配置的产品通常可简化迁移到另一个区域的过程。
  • 考虑为数据使用托管式跨区域副本的托管式服务。如本文档的以下部分所述,某些托管式服务允许您在其他区域中创建副本(通常用于实现备份或高可用性)。对于将数据从一个区域迁移到另一个区域,此功能可能非常重要。

某些 Google Cloud 服务旨在支持多区域部署全球部署。您无需迁移这些服务,不过可能需要调整某些配置。

准备计算资源

本部分简要介绍 Google Cloud 上的计算资源,以及为迁移到另一个区域做准备的设计原则。

本文档重点介绍以下 Google Cloud 计算产品:

Compute Engine

Compute Engine 是向客户提供虚拟机的 Google Cloud 服务。

如需将 Compute Engine 资源从一个区域迁移到另一个区域,除了网络注意事项之外,您还必须评估不同的因素。

建议您执行以下操作:

  • 检查计算资源:在更改虚拟机的托管区域时,您可能会遇到的首要限制之一是新目标区域中 CPU 平台的可用性。如果您必须在迁移过程中更改机器系列,请检查相应系列是否支持当前虚拟机的操作系统。一般来说,此问题可以扩展到每个 Google Cloud 计算服务(一些新区域可能没有 Cloud RunCloud GPU 等服务),因此在规划迁移之前,请确保目标区域中提供您需要的所有计算服务。
  • 配置负载均衡和扩缩:Compute Engine 支持 Compute Engine 实例之间的负载均衡流量,并且支持自动扩缩,以便根据需要自动在 MIG 中添加或移除虚拟机。我们建议您配置负载均衡和自动扩缩以提高环境的可靠性和灵活性,从而避免自行管理的解决方案的管理负担。如需详细了解如何为 Compute Engine 配置负载均衡和扩缩功能,请参阅负载均衡和扩缩
  • 使用可用区级 DNS 名称:为了降低跨区域服务中断的风险,我们建议您使用可用区级 DNS 名称,在您的环境中使用 DNS 名称唯一地标识虚拟机。默认情况下,Google Cloud 为 Compute Engine 虚拟机使用可用区级 DNS 名称。如需详细了解 Compute Engine 内部 DNS 的工作原理,请参阅内部 DNS 概览。为方便跨区域进行未来迁移并使您的配置更易于维护,我们建议您考虑将可用区级 DNS 名称作为配置参数,以备将来更改。
  • 使用相同的托管式实例组 (MIG) 模板:Compute Engine 可让您创建区域级 MIG,以便自动跨区域内的多个可用区预配虚拟机。如果您在旧区域中使用某个模板,则可以在新区域中使用同一模板部署 MIG。

GKE

Google Kubernetes Engine (GKE) 可帮助您在 Kubernetes 上部署、管理和扩缩容器化工作负载。

如需准备 GKE 工作负载以进行迁移,请考虑以下设计点和 GKE 功能:

  • Cloud Service Mesh:Istio 网格的托管式实现。通过为集群采用 Cloud Service Mesh,您可以更好地控制进入集群的网络流量。Cloud Service Mesh 的主要功能之一是让您可以在两个集群之间创建服务网格。您可以使用此功能在新区域中创建 GKE 集群并将其添加到服务网格中,从而规划从一个区域到另一个区域的迁移。通过使用此方法,您可以开始在新集群中部署工作负载并将流量逐步路由到这些工作负载,从而使您能够测试新部署,同时可以选择通过修改网格路由进行回滚。
  • Config Sync:基于开源核心构建的 GitOps 服务,可让集群运维人员和平台管理员从单个来源部署配置。Config Sync 可以支持一个或多个集群,使您能够使用单一可靠来源来配置集群。您可以使用此 Config Sync 功能将现有集群的配置复制到新区域的集群上,并且可以为该区域自定义特定资源。
  • Backup for GKE:借助此功能,您可以定期备份集群永久性数据,并将数据恢复到同一集群或新集群。

Cloud Run

Cloud Run 提供了一种在 Google Cloud 上部署容器的轻量级方法。Cloud Run 服务是区域级资源,会跨其所在区域中的多个可用区复制部署 Cloud Run 服务时,您可以选择要在其中部署实例的区域,然后使用此功能在其他区域中部署工作负载。

VMware Engine

Google Cloud VMware Engine 是一项全托管式服务,可让您在 Google Cloud 中运行 VMware 平台。VMware 环境在 Google Cloud 位置中的 Google Cloud 裸金属基础架构上以原生方式运行,包括 vSphere、vCenter、vSAN、NSX-T、HCX 以及相应的工具。

如需将 VMware Engine 实例迁移到其他区域,您应该在新区域中创建私有云,然后使用 VMware 工具移动实例。

在规划迁移时,您还应该考虑 Compute Engine 环境中的 DNS 和负载均衡。VMware Engine 使用 Google Cloud DNS,这是一项托管式 DNS 托管服务,提供发布到公共互联网的权威 DNS 托管、对 VPC 网络可见的专用区域以及用于在 VPC 网络上管理域名解析的 DNS 转发和对等互连。您的
迁移计划可以为测试多区域负载均衡和 DNS 配置提供支持。

准备数据存储资源

本部分简要介绍 Google Cloud 上的数据存储资源,以及有关如何为迁移到另一个区域做好准备的基础知识。

数据已在 Google Cloud 中存在可简化迁移,因为这意味着存在无需进行任何转换即可托管这些数据的解决方案,或者该解决方案可以在 Google Cloud 上托管。

将数据库数据复制到不同区域并在其他位置恢复数据是灾难恢复 (DR) 中的常见模式。因此,本文档中介绍的一些模式依赖于数据库备份和恢复等灾难恢复机制。

本文档介绍了以下托管式服务:

本文档假定您使用的存储解决方案是与计算资源共存的区域级实例。

Cloud Storage

Cloud Storage 提供 Storage Transfer Service,可自动将文件从不同系统传输到 Cloud Storage。它可用于将数据复制到不同区域以进行备份,以及进行区域间迁移。

Cloud SQL

Cloud SQL 提供关系型数据库服务,用于托管不同类型的数据库。Cloud SQL 还提供跨区域复制功能,允许将实例数据复制到另一个区域。此功能是 Cloud SQL 实例备份和恢复的常见模式,但也使您可以将另一个区域中的第二个副本提升为主副本。您可以使用此功能在第二个区域中创建读取副本,然后在迁移工作负载后将其提升为主副本。通常,对于数据库,托管式服务可简化数据复制过程,以便在迁移过程中更轻松地在新区域中创建副本。

处理迁移的另一种方法是使用 Database Migration Service,该服务可让您将不同来源的 SQL 数据库迁移到 Google Cloud。另一个 Cloud SQL 实例也是受支持的来源,唯一的限制是您可以迁移到不同区域,但不能迁移到不同项目。

Filestore

如本文档前面所述,Filestore 的备份和恢复功能使您能够创建可恢复到其他区域的文件共享备份。此功能可用于执行区域间迁移。

Bigtable

Cloud SQL 一样,Bigtable 支持复制功能。您可以使用此功能复制所描述的相同模式。请查看 Bigtable 位置列表,以了解该服务是否在目标区域可用。

此外,与 Filestore 一样,Bigtable 支持备份和恢复。与 Filestore 一样,此功能可用于通过创建备份并在新区域的另一个实例中恢复来实现迁移。

最后一个选项是导出表,例如在 Cloud Storage 上导出表。这些导出会在其他服务中托管数据,而这些数据随后可以导入到相应区域中的实例。

Firestore

Firestore 位置可能会与项目中是否存在 App Engine 相关,在某些场景中,这会强制 Firestore 实例为多区域实例。在这些迁移场景中,还需要考虑 App Engine,以便为 Firestore 设计合适的解决方案。事实上,如果您已有位置为 us-central
europe-west 的 App Engine 应用,则您的 Firestore 数据库将被视为多区域数据库。

如果您具有区域级位置并且您想要迁移到其他位置,托管导出和导入服务可让您使用 Cloud Storage 存储桶导入和导出 Firestore 实体。此方法可用于将实例从一个区域移动到另一个区域。另一种方法是使用 Firestore 备份和恢复功能。与导入和导出相比,此方法费用更低,且更加简单直接。

准备停用来源环境

您必须在停用来源环境并切换到新环境之前提前做好准备。

概括来讲,在停用来源环境之前,应考虑以下事项:

  • 新环境测试:在将流量从旧环境切换到新环境之前,您可以执行测试以验证应用的正确性。除了可以对新迁移的应用执行的经典单元测试和集成测试之外,还有其他不同的测试策略。新环境可视为软件的新版本,流量迁移可以使用常见模式(例如用于验证的 A/B 测试)来实现。另一种方法是在来源环境和新环境中复制传入流量,以检查功能是否得以保留。
  • 停机时间规划:如果您选择蓝绿部署等迁移策略,即将流量从一个环境切换到另一个环境,请考虑采用计划内停机时间。通过停机时间可以更好地监控过渡,并避免客户端出现不可预测的错误。
  • 回滚:根据迁移流量时所采用的策略,在新环境出现错误或配置错误时,可能需要实现回滚。为了能够回滚环境,您必须部署监控基础架构来检测新环境的状态。

只有在新区域中执行扩展测试并且服务在新区域中上线且没有错误后,才能关停第一个区域中的服务。我们建议您在有限的时间内保留第一个区域的备份,直到确定新迁移的区域中没有问题为止。

您还应该考虑是否要将旧区域提升为灾难恢复站点(假设尚未实施相应的解决方案)。此方法需要额外的设计来确保网站可靠性。如需详细了解如何正确设计和规划灾难恢复,请参阅灾难恢复规划指南

后续步骤

贡献者

作者:Valerio Ponza | 技术解决方案顾问

其他贡献者: