混合云和多云架构模式

本文是由多篇文章组成的系列教程中的第二篇,该系列教程介绍了混合和多云端部署、架构模式和网络拓扑。本文探讨常见的混合和多云端架构模式。本文还介绍了这些模式最适合的场景,并提供了使用 Google Cloud 实现这些模式的最佳做法。

该系列包含以下部分:

每家企业都有独特的应用工作负载组合,对混合或多云端设置的架构提出了要求和限制条件。虽然您必须设计和定制架构来满足这些限制条件和要求,但您可以依靠一些常见模式。

模式分为两类:

  • 依赖于应用分布式部署的模式。这些模式旨在利用计算环境的不同属性和特征,以在最适合应用的计算环境中运行应用。

  • 基于应用冗余部署的模式。在这些模式中,您会在多个计算环境中部署同一应用,旨在提高容量或弹性。

分布式部署模式

从经典计算环境迁移到混合或多云端设置时,请注意现有应用所施加的限制。您还需要利用每个计算环境提供的独特功能。这些分布式模式旨在实现两个目标之间的合理平衡。

分层混合

大多数应用可以归为前端或后端应用

  • 前端应用直接对最终用户或设备公开。因此,这些应用通常对性能要求较高,并且随着新功能和改进的开发,可能会经常发布新版本。由于前端应用通常依赖后端应用来存储和管理数据,因此,前端应用通常是无状态的,或者仅管理少量数据。

  • 后端应用通常专注于管理数据。此类应用面临的主要挑战包括批量处理数据并对其进行适当保护。后端应用新版本的推出往往不如前端应用频繁。

分层混合模式的理念是先专注于将现有前端应用部署到公有云。在此模式中,您会重复使用保留在其私有计算环境中的现有后端应用。您可以根据具体情况迁移前端应用。

下图展示了典型的分层混合模式。

分层混合模式。

随着时间的推移,您部署到云的应用的比例会增加,增加到一定量后,您可能会考虑将后端应用也移动到公有云。

优势

首先专注于前端应用具有许多优势:

  • 前端应用依赖于后端,偶尔依赖于其他前端,但后端不依赖于前端。因此,隔离和迁移前端应用往往没有迁移后端应用那样复杂,后端应用可能具有复杂的依赖项。

  • 由于前端应用通常是无状态的,或者不自行管理数据,因此迁移的难度较小。

将现有或新开发的前端应用部署到公有云具有多项主要优势:

  • 许多前端应用可能会频繁更改。在公有云中运行这些应用可以简化持续集成/持续部署 (CI/CD) 流程的设置,您可以使用该流程以高效自动的方式发布更新。

  • 对性能要求较高的前端和可能频繁更改的前端可以从云部署启用的负载平衡、多区域部署和自动扩缩功能中大大受益。

  • 无论是实现界面或 API,还是处理 IoT(物联网)数据提取,前端应用都可以受益于 FirebaseCloud CDNCloud IoT 等云服务提供的功能。

如果您的后端管理受监管或辖区限制约束的数据,您可能需要将其永久保留在私有计算环境中,或者至少需在找到符合限制条件的处理方式前将其保留在私有计算环境中。

您也可反向应用分层混合模式(虽然这不太常见),方法是在云中部署后端并同时将前端保留在私有计算环境中。如果您处理重量级、单体式前端,此方法非常适用。在这种情况下,以迭代方式提取后端功能,以及在云中部署这些新后端可能更轻松。

最佳做法

在应用分层混合模式时,请考虑采用以下做法:

  • 使用门控出站流量 (gated egress) 或网状拓扑。由于大多数用户互动都涉及在多个计算环境之间进行连接的系统,因此在这些系统之间实现快速低延迟连接非常重要。因此,设计高可用性、低延迟和适当的吞吐量级别至关重要。

  • 要最大限度地降低各环境之间的通信延迟,请选择地理位置靠近您的私有计算环境的 GCP 区域互连位置

  • 在分层混合设置中,进入 Google Cloud 的数据量(入站流量)通常大于从 Google Cloud 转移到私有计算环境的数据量(出站流量)。但请注意,离开 Google Cloud 的流量依照出站流量价格计费。使用专用互连直接对等互连有助于减少这些费用。

  • 确保环境之间的通信为单向通信。允许在公有云中运行的前端应用向在私有计算环境中运行的后端应用通信,但不允许反向通信。

  • 由于环境之间交换的数据可能是敏感数据,因此请确保已依靠虚拟专用网 (VPN) 隧道和/或传输层安全协议 (TLS) 加密所有通信。

  • 我们建议将 API 网关部署为现有后端服务的门面,特别是在协议、API 和身份验证机制在后端之间不一致的情况下。除了用作统一层之外,API 网关还可以作为关卡。通过此网关,您可以实现适用于所有跨环境通信的其他安全和审核措施。

  • 在环境之间建立通用标识,以便系统能够跨环境边界安全地进行身份验证。

对于各个工作负载,请考虑下面的其他最佳做法:

  • 虽然此模式侧重于前端应用,但请注意后端应用现代化的需求。如果后端的开发速度远远低于前端的开发速度,这种差异可能会额外增加项目的复杂性。

  • 如需实现转换和移动迁移,请使用 Kubernetes 作为 Google Cloud 和私有计算环境之间的通用运行时层。凭借 Kubernetes,您可以在不同时间实现工作负载的现代化并迁移到 Google Cloud。如果某个工作负载严重依赖于另一个工作负载,因而无法单独迁移,这种方法就非常重要。

  • 避免要求在环境之间进行双向通信。为此,还要考虑在公有云中部署持续集成/持续交付系统。

  • 在分层混合场景中,在环境之间使用一致的工具和持续集成/持续交付流程,以提高运营效率。不过,此做法并非必需做法。

  • 使用 Kubernetes 运行前端工作负载时,请使用无选择器的服务,使私有计算环境中运行的任何服务或 API 网关能被检测到。借助 Kubernetes 存根网域,您可以与基于 DNS 的外部服务发现系统(如 Consul)集成。

分区多云端

分区多云端模式结合了由不同供应商运营的多个公有云环境,使您可以灵活地在最佳计算环境中部署应用。下图展示了典型的分区多云端模式。

分区多云端模式。

您可以保留在公有云环境之间按需迁移工作负载的功能;按需迁移时,关键要求就是工作负载的可移植性。如果您将工作负载部署到多个计算环境,并希望保留在环境之间移动工作负载的功能,则必须忽略环境之间的差异。

Google Cloud 提供了一套丰富的服务,您可用它们来以不同的方式部署工作负载。但在某些情况下,也需要将 Google Cloud 与其他云服务商相结合,并跨云环境对工作负载进行分区。示例如下:

  • 为避免锁定在单个供应商,您需要在多个云提供商之间分布应用。

  • 出于监管原因,您需要为尚未推出 Google Cloud 的国家/地区的特定用户群和数据提供服务。

  • 您需要跨多个云服务商部署应用,以便可在服务商提供的最佳服务之间进行选择。

优势

以下是分区多云端模式的一些主要优势:

  • 您可以避免供应商锁定。此模式有助于降低战略风险,并且具有灵活性,您可以在后期更改计划或合作伙伴关系。

  • 如果保持工作负载的可移植性,您可以通过在计算环境之间迁移工作负载来优化操作。

最佳做法

  • 在分区多云端设置的战略优势和此设置额外增加的复杂性之间进行权衡。跨多个云环境实现工作负载可移植性和一致的工具会增加开发、测试和运营工作。

  • 仅针对任务关键型工作负载使用多云端环境,如因法律或监管原因,单个公有云环境无法容纳工作负载,也可使用多云端环境。

  • 最大限度减少在不同公有云环境中运行的系统之间的依赖项,尤其是在同步处理通信时。这些依赖项会降低性能并降低整体可用性。

  • 要忽略环境之间的差异,请考虑使用容器和 Kubernetes。

  • 确保持续集成/持续交付流程和用于部署和监控的工具在云环境之间保持一致。

  • 使用网状拓扑或门控 (gated) 拓扑。

  • 由于环境之间交换的数据可能是敏感数据,因此请确保已依靠 VPN 隧道和/或 TLS 加密所有通信。

  • 在环境之间建立通用标识,以便系统能够跨环境边界安全地进行身份验证。

  • 使用 Kubernetes 时,请考虑使用 ExternalDNS,确保能跨计算环境按 DNS 名称检测到服务。

  • 虽然您可以使用基于 Anycast IP 的 Google Cloud 负载平衡器来平衡多个 Google Cloud 区域之间的请求,但您无法使用它们在多个云之间分发用户请求。对于此分发,您必须使用轮循机制或地理位置 DNS。例如,您可以使用 NS1Oracle®Akamai

分析混合云和多云端

在企业系统中,大多数工作负载可分为以下类别:

  • 事务性工作负载包括销售、财务处理、企业资源规划或通信等交互式应用

  • 分析工作负载包括可转换、分析、优化或直观显示数据以辅助决策制定过程的应用

虽然分析系统通过查询 API 或访问数据库从事务系统获取数据,但在大多数企业中,分析系统和事务系统往往各自独立,松散地耦合。分析混合云和多云端模式的理念是通过在两个不同的计算环境中运行两种工作负载来利用这种预先存在的分离。首先从私有计算环境中运行的工作负载中提取原始数据,然后将其加载到 Google Cloud 中,它在此用于分析处理。其中一些结果随后可能会反馈给事务系统。

分析混合云和多云端模式。

优点

在云中运行分析工作负载具有多项主要优势:

  • 分析工作负载通常需要处理大量数据并且可能具有突发性,因此特别适合将其部署在公有云环境中。通过动态调节计算资源,您可以快速处理大型数据集,同时避免前期投资或超额预配计算设备。

  • Google Cloud 提供了一套丰富的服务,用于在数据的整个生命周期内对其进行管理;整个生命周期是指从初始的获取到处理和分析,再到最终可视化的整个过程。

  • Cloud Storage 非常适合构建数据湖

  • 入站流量(即从私有计算环境向 Google Cloud 移动数据)是免费的

最佳做法

要实现分析混合/多云端模式,请考虑以下最佳做法:

  • 使用切换拓扑来启用数据的提取。如果需要将分析结果反馈回事务系统,请将切换拓扑和门控出站流量拓扑结合使用。

  • 使用 Pub/Sub 队列或 Cloud Storage 存储分区,将数据从私有计算环境中运行的事务系统提供给 Google Cloud。然后,这些队列或存储分区可用作数据处理流水线和工作负载的源。

  • 如果您当前具有 Hadoop 或 Spark 工作负载,请考虑将作业迁移到 Dataproc,并将现有 HDFS 数据迁移到 Cloud Storage

  • 执行从私有计算环境到 Google Cloud 的初始数据传输时,请选择最适合您的数据集大小和可用带宽的传输方法。

  • 在环境之间使用一致的工具和流程。在分析混合场景中,此做法有助于提高运营效率,但这并非先决条件。

边缘混合

在云中运行工作负载需要客户端具有快速可靠的互联网连接。考虑到当今的网络,这一要求很少对云的采用构成难题。但在某些情况下,您无法保证持续连接:

  • 远洋船舶和其他交通工具可能只能间歇性连接,或者只能访问高延迟卫星链接。

  • 工厂或发电厂可能连接到互联网,这些设施具有的可靠性要求可能超出链接的可用性保证。

  • 商店或超市可能仅偶尔连接,或使用不提供处理业务关键型事务所需的可靠性或吞吐量的链接。

边缘混合模式解决了这些难题,方法是在网络边缘本地运行时间关键型和业务关键型工作负载,同时将云用于所有其他类型的工作负载。在边缘混合设置中,互连网链接是非关键组件,用于管理用途以及同步或上传数据(通常以异步方式),但不涉及时间关键型或业务关键型事务。

边缘混合模式。

优点

在边缘运行某些工作负载并在云中运行其他工作负载具有多项优势:

  • 在边缘运行业务关键型和时间关键型工作负载有助于确保低延迟和自给自足。如果互联网连接失败或暂时不可用,您仍然可以执行所有重要事务。同时,在云端处理大部分工作负载仍能让您受益。

  • 您可以重复使用对计算和存储设备的现有投资。

  • 随着时间的推移,您可以通过重新处理某些应用,或通过为某些边缘位置配备更可靠的互联网链接,逐步减少在边缘运行的工作负载的比例。

  • 入站流量(即从边缘向 Google Cloud 移动数据)是免费的

最佳做法

在实现边缘混合模式时,请考虑以下建议:

  • 对于单向通信,使用封闭入站流量拓扑。对于双向通信,请考虑门控入站和出站流量拓扑。

  • 最大限度地减少在边缘运行的系统与在云环境中运行的系统之间的依赖项。每个依赖项都可能破坏边缘混合设置的可靠性和延迟优势。

  • 为高效管理和操作多个边缘位置,请在云中提供集中式控制平面。

  • 确保持续集成/持续交付流程以及用于部署和监控的工具在云环境和边缘环境之间保持一致。

  • 考虑使用容器和 Kubernetes,从而忽略各边缘位置之间,以及边缘位置和云之间的差异。由于 Kubernetes 提供了一个通用运行时层,因此您可以跨计算环境一致地开发、运行和操作工作负载,并可在边缘和云之间移动工作负载。

  • 在环境之间建立通用标识,以便系统能够跨环境边界安全地进行身份验证。

  • 由于环境之间交换的数据可能是敏感数据,因此请确保已使用 VPN 隧道和/或 TLS 加密所有通信。

冗余部署模式

以下各部分探讨了一些常见模式,这些模式依赖于跨多个计算环境的应用的冗余部署。在这些模式中,您可在多个计算环境中部署同一应用,以提高容量或弹性。

环境混合

环境混合模式的理念是将工作负载的生产环境保留在现有数据中心中,但将公有云用于其他非生产环境。

在评估要迁移的工作负载时,您可能会注意到,在公有云中运行特定应用存在一些难题:

  • 辖区或监管限制条件可能要求您将数据保存在特定国家/地区。
  • 第三方许可条款可能会阻止您在云环境中操作某些软件。
  • 应用可能需要访问仅在本地可用的硬件设备,正如移动工作负载一样。

在这种情况下,不仅应考虑生产环境,还应考虑应用生命周期中涉及的所有环境,包括开发、测试和模拟环境系统。可能对云迁移构成难题的限制通常适用于生产环境及其数据,但不适用于其他环境。

下图展示了典型的环境混合模式。

环境混合模式。

在生产系统之外的其他环境中运行开发和测试系统似乎具有风险,并且与现有的最佳做法以及为最大限度减少这些环境之间的差异而进行的尝试背道而驰。虽然这些顾虑是有理由的,但如果您区分开发和测试过程的各个阶段,就会发现这些顾虑是不必要的:

  • 虽然每个应用的开发、测试和部署过程各不相同,但它们通常涉及以下阶段的变体:

    • 开发:创建候选版本。
    • 功能测试或用户验收测试:验证候选版本是否符合功能要求。
    • 性能和可靠性测试:验证候选版本是否符合非功能性要求。
    • 模拟环境或部署测试:验证部署过程是否有效。
    • 生产。

在单个环境中执行上述多个阶段不太现实,因此每个阶段通常需要一个或多个专用环境。

为确保测试结果有意义且适用于生产部署,您在整个应用生命周期中使用的一组环境必须尽可能符合以下规则:

  • 所有环境在功能上都等效。也就是说,操作系统和库的架构、API 和版本都是等效的,系统在不同环境中的行为也都相同。这种等效性可避免出现这样的情况,就是应用在一个环境中正常运行但在另一个环境中失败,或者缺陷无法重现。

  • 用于性能和可靠性测试、预演和生产的环境在非功能上是等效的。也就是说,其性能、规模、配置及其操作和维护方式要么相同,要么仅具有微不足道的差异。否则,性能和预演测试毫无意义。

重要的一点是,如果用于开发和功能测试的环境与其他环境在非功能性上不同,则没有什么问题。这种情况非常适合环境混合模式:

  • 通过依赖 Kubernetes 作为通用运行时层,实现所有环境中的功能等效,确保工作负载的可移植性并忽略计算环境之间的差异。

  • 在私有计算环境中运行用于生产、预演及性能和可靠性测试的环境,确保在功能性上和非功能性上都是等效的。

  • 在公有云中运行开发和功能测试环境。这些环境在功能上等效于其他环境,但在性能等非功能性方面可能有所不同。

优势

在公有云中运行开发和功能测试工作负载具有多项优势:

  • 您可以根据需要自动启动和清理环境。例如,您可以为每个提交或拉取请求预配整个环境,允许运行测试,然后再次清理环境。

  • 开发和测试环境的使用通常是间歇性的。您可以通过在非活动状态期间停止虚拟机 (VM) 实例或仅按需预配环境来减少费用。

  • 在公有云中运行这些环境有助于增加对云及相关工具的了解和信心,这可能有助于迁移其他工作负载。

最佳做法

要成功实现环境模式,请考虑以下建议:

  • 使用镜像拓扑,防止不同环境中的系统互相通信。由于系统不需要跨环境进行通信,因此您无需建立通用标识。

  • 要使工作负载具有可移植性并忽略环境之间的差异,请使用容器和 Kubernetes,但需注意工作负载可移植性的限制

  • 确保持续集成/持续交付流程在计算环境之间保持一致,并确保将一组完全相同的二进制文件、软件包或容器部署到各种环境中。

  • 对于部署、配置和操作工作负载,建立可跨计算环境的常见工具链。使用 Kubernetes 可让您保持这种一致性,但连接到不同计算环境中运行的集群或对其进行身份验证的方式可能存在一些细微差别。

  • 使用 Kubernetes 时,使用 Jenkins 等持续集成系统实施部署流水线,该流水线可部署到集群并跨环境工作。此外,您还可以在 Google Kubernetes Engine (GKE) 上运行 Jenkins

  • 使用相同的工具在 Google Cloud 和现有云环境中进行日志记录和监控。考虑使用 Prometheus 等开源监控系统。如果由不同团队管理测试和生产工作负载,则虽然使用各自的工具是可接受的,但使用相同的工具有助于减少培训工作量和复杂性。

  • 如果选择数据库、存储和消息传递服务,请使用 Google Cloud 上具有等效托管功能的产品。依靠托管式服务有助于减少维护开发和测试环境所需的管理工作量。

下表显示了与常见 OSS 产品兼容的 Google Cloud 产品。

OSS 产品 兼容的 Google Cloud 产品
Apache HBase Cloud Bigtable
Apache Beam Dataflow
Apache Hadoop Dataproc
MySQL、PostgreSQL Cloud SQL
Redis Memorystore
Network File System (NFS) Filestore
JMS、Kafka Pub/Sub

业务连续性混合云和多云端

理想情况下,任务关键型系统设置为在灾难中具有弹性。通过复制多个地理区域的系统和数据并避免单点故障,您可以将影响本地基础架构的自然灾害风险降至最低。但是,此方法无法解决因人为错误或软件缺陷而产生的中断风险。因此,还必须制定灾难恢复 (DR) 计划,确保您在发生其他类型的灾难时能够在可接受的时间限制内恢复系统,并最大程度减少数据丢失。

灾难恢复计划的一个关键部分是要经常将数据备份到其他地理位置,从而最大限度地减少恢复点目标 (RPO)。此外,在另一个位置维护冷、温或热备用系统有助于尽可能减少恢复时间目标 (RTO)。

当您在中央数据中心运行任务关键型系统时,进行灾难恢复的一种方法是,在位于另一区域的另一个数据中心维护备用系统。但是,更经济实惠的方法是使用基于公有云的计算环境进行故障转移,这是业务连续性混合模式的理念

业务连续性混合模式。

此模式有一个不太常见(且很少被需要)的变体,即业务连续性多云端模式;在此模式下,生产环境使用一个云提供商,灾难恢复环境使用其他云提供商。通过跨多个云提供商部署工作负载副本,您可以获得超过多区域部署所提供的可用性。

优势

使用公有云实现业务连续性具有许多优势:

  • 由于 Google Cloud 具有十多个区域可供选择,因此您可以使用它将数据备份或复制到同一大洲内的其他位置,甚至还可以备份或复制到其他大洲的位置。

  • 已停止的虚拟机实例仅产生存储费用,并且比正在运行的虚拟机实例便宜很多,因此您可以最大限度地降低维护冷备用系统的费用。

  • Google Cloud 的按用量计费模式可确保您只为实际使用的存储和计算容量付费,并且您可以根据需要扩缩灾难恢复环境。

最佳做法

使用业务连续性模式时,请考虑以下最佳做法:

  • 创建记录基础架构以及故障转移和恢复过程的灾难恢复计划

  • 根据您的 RPO 和 RTO,确定将数据备份到 Google Cloud 是否足够,或者是否需要维护冷、温或热备用系统。请参阅灾难恢复计划指南,了解常见方案以及在 Google Cloud 上实现这些方案的建议。

  • 如果仅执行数据备份,请使用切换拓扑。否则,请考虑使用镜像拓扑。

  • 最大限度减少在不同环境中运行的系统之间的依赖项,尤其是在同步处理通信时。这些依赖项会降低性能并降低整体可用性。

  • 如果跨环境双向复制数据,您可能会遇到脑裂 (split brain) 问题。在这一问题中,如果两个环境之间的通信中断,双方的系统可能会断定其他环境已经变得不可用。系统可能会断定自己拥有对数据的独占访问权,最终导致修改冲突。防止这种分裂的一种方法是添加第三个计算环境。利用此方法,依赖于数据复制的系统会在断定修改数据是安全操作前检查数量。或者,您可以允许在恢复连接后对有冲突的数据修改进行协调。

  • 确保持续集成/持续交付系统和工件代码库不会成为单点故障。当一个环境不可用时,您仍须能够部署新版本或应用配置更改。

  • 由于环境之间交换的数据可能是敏感数据,因此请确保已依靠 VPN 隧道和/或 TLS 加密所有通信。

  • 在使用备用系统时,请确保工作负载具有可移植性,以便系统在不同环境之间保持一致。请考虑使用容器和 Kubernetes。

  • 将备用系统的部署集成到持续集成/持续交付流程中。此集成有助于确保应用版本和配置在不同环境之间保持一致。

  • 使用热备用系统时,请使用负载平衡器创建自动故障转移,但请注意,负载平衡器也可能失败。作为预防措施,请配置 DNS,以便在发生灾难时将用户重新路由到备用系统。使用合理的短 TTL 确保 DNS 更改可快速传播,并利用 Cloud DNS 提供的 100% 正常运行时间 SLA

  • 对于灾难恢复,可考虑 ActifioCommvault 等合作伙伴解决方案。

云爆发

互联网应用(尤其是针对用户的应用)可能会遇到极大的使用波动。虽然大多数企业应用不会面临这一挑战,但许多企业必须处理其他类型的突发性工作负载:批处理或持续集成/持续交付作业。

虽然您可以通过超额预配资源,在基于数据中心的经典计算环境中容纳突发性工作负载,但这种方法性价比不高。对于批处理作业,您可以通过延长其执行时间段来优化利用率,但如果这些作业对时间要求较高,则延迟作业并不切实可行。

云爆发模式的理念是将私有计算环境用于基线负载,并在需要额外容量时临时爆发到云

云爆发模式。

云爆发方案的关键要求是工作负载可移植性。如果您允许将工作负载部署到多个环境,则必须忽略环境之间的差异。

云爆发模式适用于交互式和批处理工作负载。但是,在处理交互式工作负载时,必须确定如何跨环境分发请求:

  • 您可以将传入的用户请求路由到在现有数据中心中运行的负载平衡器,然后让负载平衡器在本地资源和云资源之间分发请求。此方法要求负载平衡器或现有数据中心中运行的其他系统也跟踪在云中分配的资源,并启动资源的自动扩充或缩减。

    将传入的用户请求路由到在现有数据中心中运行的负载平衡器,然后让负载平衡器在本地资源和云资源之间分发请求。

    一方面,通过此方法,您可以在活动程度较低的时段停用所有云资源。另一方面,实现跟踪资源的机制可能超出现成负载平衡器解决方案的功能范围,从而增加整体复杂性。

  • 或者您可以先将请求路由到 Google Cloud,然后跨环境分发。由于 Google Cloud 负载平衡器仅跨 Google Cloud 资源支持平衡和自动扩缩,因此您需要将 Google Cloud 负载平衡器与其他自定义负载平衡机制相结合,以便分发请求。同样,这种方法会额外增加复杂性。

    如果您打算在需求较低时关闭 Google Cloud 中的所有资源,都无法使用循环 DNS 进行负载平衡。由于 DNS 更新往往传播缓慢,因此使用 DNS 进行负载平衡会带来以下风险:在没有可用于处理用户请求的资源时,用户会路由到 Google Cloud。

考虑到这些难题,云爆发通常更适合批处理工作负载,而不是交互式工作负载。

优势

这种架构模式的主要优势包括:

  • 通过云爆发,您可以重复使用数据中心和私有计算环境中的现有投资。这种重复使用可能是永久性的,也可能是在现有设备到期更换之前有效,届时您可以考虑完整云迁移。

  • 您也许能够提高私有计算环境的利用率和成本效益,因为您不再需要维持多余的容量来满足高峰需求。

  • 云爆发允许批处理作业及时运行,而无需超额预配计算资源。

最佳做法

实现云爆发时,请考虑以下最佳做法:

  • 使用网状拓扑,确保云中运行的工作负载能够以与其他计算环境中运行的工作负载一样的方式访问资源。如果工作负载允许,请仅允许从云访问其他计算环境,反之则不行。

  • 如需最大限度地降低各环境之间的通信延迟,请选择地理位置靠近您的私有计算环境的 Google Cloud 区域互连位置

  • 如果仅将云爆发用于批处理工作负载,那么通过将所有 Google Cloud 资源设为私有,禁止从互联网直接访问这些资源,可以减少安全攻击面。

  • 对于运行时间不超过 24 小时且对时间要求不高的作业,请考虑使用抢占式虚拟机实例,这些实例比常规虚拟机实例便宜很多。但前提条件是,如果正在运行作业的虚拟机遭到抢占,系统必须能够自动重启作业。

  • 使用容器来实现工作负载可移植性。对于资源密集型批处理工作负载,您可以直接在 Compute Engine 虚拟机上部署这些容器,并使用托管实例组来增减虚拟机数。如果是交互式工作负载或资源使用较少的多种工作负载,您还可将 Google Kubernetes Engine (GKE)集群自动扩缩相结合来部署这些容器。但请注意,GKE 要求每个地区至少有一个节点始终在运行。

  • 监控从 Google Cloud 发送到其他计算环境的所有流量。此流量依照出站流量费用计费。

  • 由于环境之间交换的数据可能是敏感数据,因此请确保已依靠 VPN 隧道和/或 TLS 加密所有通信。

  • 对于存储密集型工作负载,请考虑集成混合存储解决方案,例如 CloudianEgnyteSwiftStack

  • 使用爆发云模式动态调节持续集成系统。使用 Jenkins 时,您可以使用 Google Compute Engine 插件在 Compute Engine 上管理和自动调节 Jenkins 实例。

  • 在环境之间建立通用标识,以便系统能够跨环境边界安全地进行身份验证。

后续步骤