将虚拟机迁移到 Compute Engine 的最佳做法

本文介绍了将计算工作负载迁移到 Google Cloud 的相关指南和最佳做法。本指南适用于已经熟悉一般云计算概念的云计算架构师和系统架构师。

迁移到 Compute Engine 的好处包括下列几点:

  • 费用。得益于 Compute Engine 虚拟机 (VM) 的持续使用折扣 (SUD),与在传统数据中心管理硬件或虚拟机 (VM) 相比,费用可大幅降低。即使是从其他云平台迁移到 Google Cloud,您同样可以获得这些价格优势。

  • 灵活性。大多数客户会发现灵活性立竿见影地提高,因为他们几乎可以在瞬间创建虚拟机,而无需等待获取和预配资源。您可以快速启动新应用,对应用进行实验,并在需要时将其关闭。

  • 开销。数据中心通常需要许多不同的供应商,每一家供应商都有自己的合作关系、计费模式和合同。迁移到云端可以大幅减少开销。您的员工不再需要处理运行数据中心的管理开销,而是可以集中精力来推动业务发展。

由于绝大多数技术工作负载都需要计算资源(即进行计算),因此本文重点介绍如何迁移虚拟机以及应用正常工作所需的一些其他服务,如数据库、消息传递和分析服务。

迁移并非一蹴而就,以下各部分分别介绍了推荐的各个步骤。

计算费用

在迁移任何虚拟机之前,首先要计算迁移费用以及您在数据中心运行的资源的费用。计算时,不仅要考量实体机器的费用,还要纳入数据中心的网络设备费用、电力费用、散热费用、人力费用和租赁费用。

为了帮助您评估这些费用,Google 与 Cloud Physics 和 StratoZone 等技术合作伙伴密切合作,为您的现有 IT 环境提供免费的发现和评估工具。

在了解费用后,您需要建立一个云端费用模型。请考虑以下事项:

  • 您将使用哪种操作系统?该系统是否需要许可?
  • 您将使用哪些类型的虚拟机?虚拟机有各种大小,其费用取决于大小。您需要大致了解自己的应用有什么样的性能特征。
  • 除虚拟机外,您的应用还需要其他哪些服务?这些服务的价格是多少?
  • 这些应用是否需要任何已获许可的软件?软件价格是多少?云端是否提供?

这些都是您在迁移任何虚拟机之前需要纳入计划的费用考虑事项。您的 Google Cloud 销售团队可以帮助您评估和计算这些费用。

如果您已经在使用云服务商,那么费用计算方式可能有所不同。例如,您无需再考虑数据中心租赁费用。但仍需进行费用评估。在迁移之前,请务必了解当前提供商与 Google 的结算模式有何不同。例如,如果您要从 Amazon Web Services (AWS) 进行迁移,则可在 Cloud Platform 博客中查看虚拟机定价评估。

评估待迁移资源

在评估迁移成本之后,您可以开始考虑哪些资源需要迁移。在现代企业中,有许多不同种类的应用,包括面向客户的应用、后台应用、开发者工具和实验性应用。以相同的方式同时迁移所有这些应用没有意义。

我们建议将应用分为三大类:

  • 容易迁移的应用。这类应用具有较少的依赖项、版本较新、由内部编写(因此无需考虑许可问题),并且可更好地适应更高的扩缩要求和其他云模式。
  • 不容易迁移的应用。这类应用具有较多的依赖项、扩缩能力较差,或者具有复杂的许可要求。
  • 无法迁移的应用。某些可能不适合迁移的应用在专用或较旧的硬件上运行;需要遵守某些业务或法规要求,因此必须留在您的数据中心;或者需要遵守复杂的许可要求,无法迁移到云端。

上面只列出了这三类的部分示例,您的应用可能还有更多决定因素。您的 Google Cloud 销售团队可以为您提供帮助。

无论您是从数据中心还是从其他云服务商那里进行迁移,都应考虑上述事项。

完成此项工作后,您就可以选择首个或首批要迁移的应用。强烈建议您在开始时只迁移少量应用。 先迁移部分应用不仅可为您今后迁移其他应用树立一个模板,而且可帮助您确定迁移流程。

进行迁移设计

在确定要迁移的应用后,您需要在迁移任何资源之前设计好云环境。第一步是了解您当前的环境与 Google Cloud 之间的对比情况。下表是对比结果的简要概览:

服务类型 数据中心 Google Cloud
计算 物理硬件、虚拟硬件(VMware ESXi、Hyper-V、KVM、XEN) Compute Engine
存储 SAN、NAS、DAS Persistent Disk、Cloud Storage
网络 MPLS、VPN、硬件负载平衡、DNS Cloud VPN、Cloud Interconnect、Cloud Load Balancing、Google Domains、Cloud DNS
安全 防火墙、NACL、路由表、加密、IDS、SSL Compute Engine 防火墙、加密、IDS、SSL
身份 Active Directory、LDAP IAM、GCDS、LDAP
管理 配置服务、CI/CD 工具 Cloud Deployment Manager、配置服务、持续集成/持续交付 (CI/CD) 工具

如果您要从 AWS 迁移,则可以使用比较指南来帮助评估 AWS 与 Google Cloud 服务之间的对比情况。

通过比较各项服务来了解您的应用需要什么和使用什么之后,您就可以开始规划您的环境在 Google Cloud 上的情况了。

在迁移任何虚拟机之前,您需要为应用构建环境。接下来的几个部分介绍了建议的步骤。

制定治理政策

您需要规定公司中的哪些人有权创建、访问、修改和销毁云端资源。另外,您还必须确定资源的付费方式。您可以在 Cloud IAM 最佳做法文档中找到相关指导信息。

在这个阶段中,您还应确定哪些人员拥有云帐号。您可能没必要让公司内所有人员都拥有直接访问权限,甚至可能没必要让所有开发者拥有直接访问权限。您应该预先创建帐号并制定有关创建和删除这些帐号的政策。

创建网络

在迁移任何虚拟机之前,虚拟机要迁移到的网络必须存在。与权限和帐号类似,请务必提前创建此网络,因为在应用开始迁移后建立网络可能很困难。

在设计网络时,务必要意识到:您不仅是在为某个应用创建网络,而且是在创建一个可供全公司遵循的模式。请考虑以下问题:

  • 是为每个应用创建一个网络,还是为每个环境创建一个网络?
  • 您的应用将如何访问共享服务?
  • 您将采用中心辐射型网络模式还是全网状网络?
  • 您将如何连接各个网络?
  • 您是在网络间使用 VPN 连接,还是使用跨项目网络?

由于有各种各样的选项,并且公司之间存在差异,因此很难提供适用于所有情况的统一建议。我们唯一的建议是,在开始部署应用之前,先评估您的需求,然后选择一种策略。

网络设计的后半部分工作是确定如何连接到您的现有资源。Google 提供多种不同的连接选项,您可以根据需要选择。

最基本的方案是在现有资源与 Google 之间创建 VPN 连接。借助该服务,您可以在两个位置之间创建静态或动态路由。

如果您需要更快速地连接到 Google,则可与 Cloud Interconnect 团队沟通,他们可以帮助您创建通向 Google 的直接租用线路。

最后,您可以选择在我们的许多直接对等互连位置之一创建通向 Google 的直接链路。

进行运营规划

当您的应用在云端运行时,您需要对其进行监控、保留相关日志,并对其进行运营管理,就像您在任何系统中一样。您必须将这些运营操作视为高级规划的一部分。

有许多第三方配置工具可用。Chef、Puppet 等软件都可以提供帮助。如果您已经在使用这些工具,则应在自己的 Google Cloud 环境中继续使用。如果您还没有使用,我们强烈建议您进行评估,考虑开发者与运营工程师的工作方式,确定哪种工具最适合您。这些工具与 Cloud Deployment Manager(我们建议您将其纳入部署和运营管理中)兼容且互补。

在监控和日志记录方面,您同样需要做出类似的决定。有几个第三方工具可以在 Google Cloud 上稳定运行。如果您已经在使用其中一个或多个,则应继续使用。如果您尚未使用,则应考虑各种工具,例如 Cloud LoggingCloud MonitoringError Reporting

开始迁移

第一次迁移将成为后续迁移的模板。随着迁移的深入,您可能会优化流程,但务必要在第一次迁移时记录您所做的一切。

下一部分介绍了概要迁移架构以及在每种场景下进行迁移所需执行的步骤。

迁移架构

一般来说,有三种迁移架构可供您用来迁移各项应用。

第一种是为云端完全重新设计应用。虽然这是一个可行的选项,但它超出了本文的范围,因为它与在云端创建新应用的方法基本相同。

以下几个部分介绍了第二种和第三种方法。

直接原样迁移

这种方法通常最容易上手,因为几乎不需要对应用进行更改。此场景需要关停现有应用并将数据和虚拟机复制到云端。

移动数据

直接原样迁移的第一步是移动运行应用所必需的数据。这些数据通常为数据库数据,但也可能包括可以从 SAN 移动到 Cloud Storage 中的对象存储服务的静态资源。您还应该将应用本地需要的任何数据移动到 Cloud Storage,以便在虚拟机启动时将这些数据下载到 Compute Engine 永久性磁盘。

迁移虚拟机

下一步是迁移虚拟机。您可以采用多种方式来迁移虚拟机。首选方式是 Migrate for Compute Engine。Migrate for Compute Engine 将一个小型启动集转移到 Google Cloud,启动应用,然后在后台以透明方式转移和同步数据。因此,借助 Migrate for Compute Engine,您的虚拟机(平均)只需数分钟时间即可在 Google Cloud 中启动。

测试应用

当数据和虚拟机在 Google Cloud 上运行后,您应该以测试模式运行应用,以确保其运行符合您的预期。测试包括确定其是否符合您的性能指标,并检查应用是否部署正确并受到适当的监控和记录。Migrate for Compute Engine 具备内置测试和合理调整大小功能,可帮助您验证云端内性能、服务等级协议 (SLA) 和费用。

迁移到生产环境

这一步需要多长时间取决于应用的性质。为了切换到生产应用运行的环境,应用几乎总是需要在一段时间内处于离线状态,但使用 Migrate for Compute Engine,该离线时间可以提前且非常短暂(有时短至 5 分钟)。如何在不让应用离线的情况下(基于用户视角)迁移到生产环境超出了本组最佳做法的讨论范围。

以下两个因素决定了这一迁移过程需要多长时间:

  • 自从您完成原始数据导入后,过了多久?
  • DNS 为应用前端更新条目需要多长时间?

通常,您可以很好地控制上述第一个因素。如果您需要短时间内迁移到生产环境,那么最好在导入数据后尽快完成迁移。

在确定可接受的时间段后,请执行以下操作:

  1. 将维护期告知您的用户。
  2. 从当前位置关停您的应用。
  3. 将缺失的数据导入 Google Cloud 中的适当位置。
  4. 切换 DNS 条目并在云端启用应用。

如果一切进展顺利,应用便可完全迁移,您可以让用户重新开始使用应用。如果使用 Migrate for Compute Engine,该软件负责处理数据到云端的转移、迁移期间在来源和目标位置之间同步数据,以及为您更新 DNS 条目。这有助于在迁移期间显著减少工作量和相关风险。

混合迁移

第三种架构方法是混合迁移。这种方法仅向云端迁移应用的一部分,通常是前端,也可能包括应用逻辑部分。后端及关联服务仍与现有资源的其余部分留在原处。混合迁移是直接原样迁移的变体形式。在应用可以迁移到云端但部分后端服务无法迁移到云端时,混合迁移法较为实用。这种迁移方法所需的步骤少于直接原样迁移。例如,在此架构中,无需将数据存储迁移到云端。

确定网络连接

第一步是在现有资源与 Google Cloud 之间创建一个足够快的连接。采用什么样的连接完全取决于您应用的特性概况。在有些情况下,VPN 可能就足够了。但在另外一些情况下,则可能需要专用高速线路。

迁移虚拟机

下一步是迁移虚拟机映像,与直接原样迁移的情形类似。同样,在该阶段,您应该对应用进行测试,以确保其按预期在云端运行,并可沿链路返回至现有资源。

迁移到生产环境

最后,在这种情况下,所需的维护期要短得多,因为您无需迁移数据。您仍然需要执行以下操作:

  1. 将维护期告知用户。
  2. 关闭现有应用。
  3. 切换 DNS 条目。
  4. 在云端启动应用。

如果一切进展顺利,您的应用便会在 Google Cloud 上运行。此时,您可以再次让用户访问应用。

使用 Migrate for Compute Engine

Migrate for Compute Engine 提供了一种无代理云迁移工具,可以让用户在几分钟内高效地将虚拟机迁移到 Google Cloud。Migrate for Compute Engine 采用流式传输技术缩短迁移时间,在迁移前提供合理的规模建议,以帮助您选择适当的实例类型,并与 VMware vCenter 集成,提供用于管理虚拟机迁移的单一管理平台。 Migrate for Compute Engine 还提供基于 Web 的界面,以组织和自动执行虚拟机的大规模迁移。

目前,迁移到 Google Cloud 的客户可以免费使用 Migrate for Compute Engine。迁移期间或之后使用或消耗的所有其他 Google Cloud 产品均按标准结算费率收费。例如,如果您使用 Compute Engine 虚拟机部署 Migrate for Compute Engine,则需要为其实例小时付费。如需详细了解 Migrate for Compute Engine 使用的 Google Cloud 产品,请参阅 Migrate for Compute Engine 价格页面。

如需了解详情,请参阅有关使用 Migrate for Compute Engine 将虚拟机迁移到 Google Cloud 的文档

后续步骤