混合云和多云端模式及做法

本文是多篇系列文章中的第一篇,该系列介绍了混合云和多云端部署、架构模式和网络拓扑。本部分探讨了混合云和多云端部署的机遇和挑战,并指导如何使用 Google Cloud Platform (GCP) 进行和实现混合设置。

该系列文章包含以下内容:

数字化以及快速适应不断变化的市场需求提高了对企业 IT 的要求和期望。许多公司发现这些趋势对现有的基础架构和流程极具挑战。

与此同时,IT 部门经常面对审查和要求其提高成本效益的压力,但其很难证明额外的资本支出能够扩展数据中心和设备并实现现代化。

混合云策略提供了一种实用的解决方案。通过使用公共云,您可以扩展 IT 的容量和功能,而无需进行前期的资本支出。通过向现有的基础架构添加一个或多个云部署,您不仅可以保留现有投资,还可以避免仅使用单个 IT 供应商。此外,通过使用混合云策略,您可以在资源允许的情况下逐步实现应用和流程的现代化。

混合云和多云端

由于工作负载、基础架构和流程对每个企业都是唯一的,因此每个混合云策略都必须适应特定需求。其结果是,混合云和多云端这两个术语有时的含义是不一致的。

在 GCP 的上下文中,术语混合云描述了一种设置,其中,在多个计算环境中部署通用或互连的工作负载,一种基于公共云,一种基于私有云。

最常见的示例是将私有计算环境(通常是现有的本地数据中心)与公共云计算环境相结合,如下图所示。

将私有计算环境和公共云计算环境结合

术语多云端描述了至少包含两个公共云提供商的设置,如下图所示。

包含至少两个公共云提供商的多云端拓扑

多云端设置还可能包括私有计算环境。

包含至少两个公共云提供商和私有环境的多云端拓扑

混合云和多云端设置的驱动因素

混合云和多云端设置可能是临时的,仅在有限的时间内维护以促进迁移。但是,这些设置也可能代表大多数组织的未来状态,因为他们构建新系统并发展现有系统以使每个系统达到最佳的效果,无论系统设置在何处。因此,混合云和多云端设置可能是 IT 环境中的永久固定装置。

混合云或多云端设置本身可能并不是一种目标,而是一种满足业务需求的手段。因此,选择正确的混合云或多云端设置之前要先明确这些需求。

业务驱动因素和约束

业务方面的常见驱动因素和约束包括:

  • 减少资本支出或一般 IT 支出。
  • 提高灵活性和敏捷性,以更好地响应不断变化的市场需求。
  • 构建可能很难在现有环境中实现的功能,例如高级分析服务。
  • 提高服务质量和可用性。
  • 提高成本和资源使用的透明度。
  • 遵从有关数据主权的法律法规。
  • 避免或减少与供应商锁定。

设计和开发驱动因素

设计和开发方面的常见驱动因素包括:

  • 自动化和加速应用发布,以加快上市时间并缩短周期。
  • 利用高级 API 和服务来加速开发。
  • 加速计算和存储资源的预配。

运营要求和约束

从运营方面考虑的要求和限制包括以下内容:

  • 确保跨计算环境的身份验证、授权、审核和政策的一致性。
  • 使用一致的工具和流程来降低复杂性。
  • 提供跨环境的公开范围。

架构约束

在架构方面,最大的约束通常源于现有系统,可能包括以下内容:

  • 应用之间的依赖项。
  • 系统间通信的性能和延迟要求。
  • 依赖公共云中不可用的硬件或操作系统。
  • 许可限制。

总体目标:

混合云和多云端策略的目标是通过描述以下内容的计划来满足这些要求:

  • 在每个计算环境中运行或迁移哪些工作负载。
  • 哪些模式适用于多个工作负载。
  • 使用哪种技术和网络拓扑。

从根本上说,任何混合云和多云端策略都源于业务需求。但是,如何从业务需求中推导可用的策略并不明确。您选择的工作负载、架构模式和技术不仅取决于业务需求,还以循环的方式相互影响。下图演示了这一循环。

工作负载、模式和技术如何影响和依赖业务需求

定义愿景

在具有依赖项和约束的网络中,定义一个可以考虑到所有工作负载和需求的计划是最困难的,特别是在复杂的 IT 环境中。此外,规划需要时间并可能导致利益相关者的利益之争。

为避免这种情况,首先需要制定一份关注业务视角的愿景陈述,并解决以下问题:

  • 为什么当前的方法和计算环境不足?
  • 您希望使用公共云优化哪些主要指标?
  • 您计划使用混合云或多云端设置多久?您是否认为此设置是永久性的,或者是完整云迁移过程中的一个临时设置?

愿景陈述不涉及如何实现这些目标。

就愿景达成一致并获得相关的利益相关者签字,为规划过程的后续步骤奠定基础。

设计混合云和多云端策略

在确定了愿景后,您可以详细说明策略:

  1. 初步评估工作负载。考虑到愿景文档中描述的目标,确定可以从部署或迁移到公共云中受益的计划的和现有的工作负载的候选列表。以下部分将更详细地讨论此主题。

  2. 从确定的候选工作负载开始,确定适用的模式,并根据这些模式确定候选拓扑

    如果您确定了多个适用的模式和拓扑,请优化工作负载选择,以便您可以敲定单个模式和拓扑。根据需要进行迭代以优化您的选择。

    对大型组织而言,应用多种模式和拓扑结构是一种可行的方法。但这种方法并不理想,因为由此引致的复杂性反而可能会减慢您的进度。

  3. 确定工作负载的优先级。鉴于存在许多要求,最好采用迭代方法。

  4. 选择要放入公共云的初始工作负载。确保此工作负载不是业务关键或不难迁移,但足以作为即将进行的部署或迁移的蓝图。

    在选择要迁移的工作负载时,请开始在 GCP 端进行准备。

  5. 设置所需的 GCP 组织、项目和政策,以便为首次部署准备云环境。

  6. 实现网络拓扑并在 GCP 与您的私有计算环境之间建立必要的连接。

工作负载

关于在哪些计算环境上运行哪些工作负载的决策对混合云和多云端策略的有效性有着深远的影响。将错误的工作负载放在云端可能会使部署复杂化,同时收益甚微。将适当的工作负载放在正确的位置不仅有益于工作负载,还可以帮助您了解每个环境的优势。

云优先

云优先是一种常见的迁入公共云的方法。通过此方法,您可以在公共云上部署新工作负载。在这种情况下,仅当出于技术或组织原因而无法进行云部署时,才考虑在私有计算环境中进行传统部署。

云优先策略优缺点并存。从积极的方面看,它具有前瞻性。即您可以以干净和云原生方式部署新工作负载,同时免除(或至少最大限度地减少)迁移现有工作负载带来的麻烦。

从消极的方面看,使用云优先策略可能无法充分利用现有工作负载。因为新工作负载可能只占整体 IT 工作负载的一小部分,并且它们对整体 IT 支出和性能的影响可能有限。迁移现有工作负载可能比尝试在云端部署新工作负载更有优势或更节省。

遵循严格的云优先策略还有可能增加 IT 环境的整体复杂性。这种方法可能会产生冗余,由于过度的跨环境通信而导致性能降低,或者导致计算环境不适合单个工作负载。

考虑到这些风险,您最好只针对选定的工作负载使用云优先方法。这样,您就可以专注于可以从云部署或迁移中受益最多的工作负载。此方法还考虑了现有工作负载的现代化,这将在下一节中讨论。

迁移和现代化

混合云/多云端和 IT 现代化是在良性循环中相互关联的独特概念。使用公共云可以促进和简化 IT 工作负载的现代化,而 IT 现代化将使您从云端受益更多。

现代化工作负载的主要目标如下:

  • 实现更高的敏捷性,以便您能够适应不断变化的需求。
  • 降低基础架构和运营成本。
  • 提高可靠性和弹性,以最大限度地降低业务风险。

直接迁移

直接迁移描述了将工作负载从私有计算环境迁移到公共云的过程,而不会对工作负载有重大的改变。最常见的是,此过程涉及将现有虚拟机 (VM) 及其映像迁移到 Compute Engine。

相比私有计算环境,在 Compute Engine 中运行虚拟机具有以下优点:

  • 您可以快速预配计算和存储资源,避免因在传统(私有或本地)数据中心需要采购和安装设备而导致的延迟。

  • 您只需为所用的计算资源付费,无需预先承诺或投资。

  • 您可以自动执行操作任务,从而减少工作量和成本。

如果您还将应用重写为更接近云原生,则可以解锁更显著的额外优势:

  • 通过使用自动扩缩,您可以确保仅在需要时预配计算资源,从而避免任何过度预配成本。

  • 您可以利用 Kubernetes 等集群管理器,通过自动重新启动应用或在发生故障时将它们迁移到不同的计算机来提高应用的弹性。

  • 您可以使用托管服务进一步降低运营开销。

  • 您可以自动部署,这有助于加速产品开发和发布流程,从而帮助您的企业更快地响应反馈、不断变化的需求和市场需求。

通过将应用迁移和转换为云原生来实现工作负载的现代化

如此图所示,当您对现有工作负载进行现代化时,请考虑将应用转移到云端并将应用转换为云原生。

转换和移动

尽管在将应用转换为云原生之前通常会先将其迁移到云端,但对于某些应用来说,反向操作可能更好。转换和移动的核心是通过重构和现代化已经存在的应用来开始迁移。如果在将应用迁移到云端之前执行这种转换,就会带来很多益处:

  • 您可以改进部署过程。

  • 投资持续集成/持续部署 (CI/CD) 基础架构和工具可以加快发布节奏并缩短反馈周期。

转换后,您可以将应用移动到云端,这有助于您通过使用自动扩缩来快速预配资源并提高成本效率,因此不会过度预配。

为了更好的进行转换和移动,请考虑对本地基础架构和工具进行投资,例如设置本地 Docker 注册表和配置 Kubernetes 集群以容器化应用。

淘汰和替换

淘汰和替换是指移除系统并替换它。在某些情况下,尝试发展现有系统和代码库可能不具有甚至没有成本效益。这是因为需求可能已发生实质性变化,或者现有应用可能基于不适合未来投资的软件或硬件堆栈。在这种情况下,更好的方法可能是替换系统,这可能意味着要么购买新的解决方案,要么从头开始开发现代化的云原生应用。

混合和匹配迁移方法

三种迁移方法各有优劣,因此要实施混合云和多云端策略,您无需只采用一种方法。相反,您可以决定最适合每个工作负载的方法。

如果工作负载中出现以下任何一种情况,请选择直接迁移:

  • 它们对环境的依赖项相对较少。
  • 它们被认为不值得重构。
  • 它们基于第三方软件。

如果工作负载中出现以下情况,请考虑转换和移动:

  • 它们具有必须解开的依赖项。
  • 它们依赖于无法迁移到云端的操作系统、硬件或数据库系统。
  • 它们无法有效利用计算或存储资源。
  • 它们不能以自动化方式轻松部署。

最后,对于这些类型的工作负载,淘汰和替换可能是最好的方法:

  • 它们不再满足当前的需求。
  • 它们基于已达到使用寿命的第三方技术。
  • 它们需要支付多余的第三方许可费。

可移植性

在大多数迁移中,将工作负载迁移到云端是一次性的,不可逆转的。但对于混合场景,尤其是多云端场景,您可能希望以后能够在云之间迁移工作负载。要实现此功能,请确保您的工作负载可移植:

  • 确保您可以将工作负载从一个计算环境迁移到另一个计算环境而无需进行重大修改。
  • 确保应用部署和管理在各个计算环境中保持一致。
  • 确保保持工作负载的可移植性不会与工作负载的云原生性质产生冲突。

在基础架构级别,您可以使用 Terraform 等工具自动化和统一基础架构资源的创建,例如异构环境中的虚拟机和负载平衡器。此外,您可以使用 Ansible、Puppet 或 Chef 等配置管理工具来建立通用部署和配置过程。或者,您可以使用类似 Packer 这样的映像定义工具,通过单个共享配置文件创建适用于不同平台的虚拟机映像。最后,您可以使用 Prometheus 和 Grafana 等解决方案来帮助确保跨环境监控的一致性。

基于这些工具,您可以汇编类似于下图中的工具链。该工具链抽象出计算环境之间的差异,使您能够统一预配、部署、管理和监控。

工具链消除了计算环境之间的差异,使您能够统一预配、部署、管理和监控

虽然常见的工具链可以帮助您实现可移植性,但它有几个缺点:

  • 您可能无法使用云环境本身提供的某些功能。具体而言,使用虚拟机作为通用基础很难实现真正的云原生应用。有时,使用虚拟机会使您无法使用托管服务,因此您可能会无法减少管理开销。

  • 建立和维护工具链会产生管理费用和运营成本。

  • 随着时间的推移,工具链可能会因您公司独有的需求变得复杂。这种复杂性可能导致培训成本的增加。

容器和 Kubernetes

通过使用虚拟机来构建和维护自定义工具链以实现工作负载可移植性面临许多挑战。针对此的一种解决方案是使用容器和 Kubernetes。

当您将软件从一个环境移动到另一个环境时,容器可帮助您的软件可靠地运行。Kubernetes 负责处理容器化应用的编排、部署、扩缩和管理,提供构成云原生应用的基础的服务。因为您可以在各种计算环境中安装和运行 Kubernetes,所以您还可以使用它在跨计算环境中建立通用运行时层

  • Kubernetes 在云或私有计算环境中提供相同的服务和 API。此外,使用 Kubernetes 的抽象级别远高于使用虚拟机时的抽象级别,这通常会转化为较少的基础工作并提高开发者的工作效率。

  • 与自定义工具链不同,Kubernetes 被广泛用于开发和应用管理,因此您可以利用现有的专业知识、文档和第三方支持。

  • Kubernetes 使用 Docker 容器,这是一种行业采用的应用打包标准,不会受到任何供应商的限制。Kubernetes 本身是开源的,由 Cloud Native Computing Foundation 管理。

您可以通过使用托管的 Kubernetes 平台(例如 Google Kubernetes Engine (GKE))来避免安装和运行 Kubernetes 的工作,因此操作人员可以将重点从基础架构转移到应用。托管 Kubernetes 平台如下所示。

托管 Kubernetes 平台

工作负载可移植性的限制

为了使您的工作负载更具可移植性,Kubernetes 提供了一个抽象层,可以隐藏计算环境之间的许多复杂性和差异。然而,这种抽象有一些限制,例如:

  • 应用可以通过最少的更改移植到不同的环境,但这并不意味着应用在两种环境中都能同样良好地运行。底层计算或网络架构的差异以及与依赖服务的接近度可能会导致性能大不相同。

  • 在计算环境之间移动工作负载可能还需要您移动数据。除了在计算环境之间复制或移动数据所需的时间、工作和预算之外,这些环境在它们提供的用于存储和管理此类数据的服务和设施方面通常存在差异。

  • Kubernetes 提供了一种统一的方式来预配不同类型的负载平衡器。但是,这些负载平衡器的行为没有详细定义,并且可能在不同的环境之间有微妙的差异。

  • GKE 将基于角色的访问控制 (RBAC) 与 Cloud Identity and Access Management 集成在一起,但在其他环境中,配置 RBAC 和安全工作负载的方式可能不同。

即使使用 Kubernetes,抽象出计算环境或公共云之间的差异也是一项挑战。此外,工作负载可移植性主要旨在简化环境之间的迁移,而不是自动化迁移。

工作负载评估

当您有正在进行的新项目以及已经运行的数百甚至数千个工作负载时,决定部署哪些工作负载或迁移到哪个计算环境可能会令人望而生畏。

为了帮助您持续客观地做出此类决策,请考虑按机会、风险和技术难度对工作负载进行分类和评分。

以下这些因素可以帮助您评估迁移机会:

  • 通过使用云服务实现市场差异化或创新的潜力
  • 可以节省应用的总拥有成本的潜力
  • 改进可用性、弹性、安全性或性能方面的潜力
  • 加速开发和发布过程的潜力

以下这些因素可以帮助您评估迁移风险:

  • 有可能因迁移或部署公共云的经验有限而引发中断
  • 需要遵守任何现有的法律或监管限制

以下这些因素可以帮助您评估迁移的技术难题:

  • 应用的大小、复杂性和存在时间
  • 与其他应用的依赖项数
  • 第三方许可证施加的任何限制
  • 对特定版本的操作系统、数据库或其他环境配置的依赖项

评估初始工作负载后,您可以开始确定工作负载的优先级,并确定适用的架构模式网络拓扑。此步骤可能需要多次迭代。由于您的评估可能会随着时间的推移而发生变化,因此在执行首次云部署后,还需要重新评估工作负载。

后续步骤

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Solutions