Google Cloud 提供了将虚拟机 (VM) 及其数据从 Amazon Elastic Compute Cloud (Amazon EC2) 迁移到 Compute Engine 的工具、产品、指导和专业服务。本文档讨论了如何设计、实施和验证从 Amazon EC2 迁移到 Compute Engine 的计划。
本文档中的讨论适用于希望详细了解如何规划和实现迁移过程的云管理员。它还适用于正在评估迁移机会和想要探索迁移可能是什么样子的决策者。
本文档是关于从 AWS 迁移到 Google Cloud 的系列文章中的一篇，该系列文章包括以下文档：
- 开始
- 从 Amazon EC2 迁移到 Compute Engine（本文档）
- 从 Amazon S3 迁移到 Cloud Storage
- 从 Amazon EKS 迁移到 Google Kubernetes Engine
- 从 Amazon RDS 和 Amazon Aurora for MySQL 迁移到 Cloud SQL for MySQL
- 从 Amazon RDS 和 Amazon Aurora for PostgreSQL 迁移到 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL
- 从 Amazon RDS for SQL Server 迁移到 Cloud SQL for SQL Server
- 从 AWS Lambda 迁移到 Cloud Run
如需迁移到 Google Cloud，建议您遵循迁移到 Google Cloud：使用入门中所述的迁移框架。
下图说明了迁移过程的路径。
您可能需要通过一系列迭代从来源环境迁移到 Google Cloud，例如，您可能会先迁移一部分工作负载，然后再迁移其他工作负载。对于每个单独的迁移迭代，您都需要遵循一般迁移框架的各个阶段：
- 评估和发现工作负载和数据。
- 在 Google Cloud 上规划和构建基础。
- 将工作负载和数据迁移到 Google Cloud。
- 优化您的 Google Cloud 环境。
如需详细了解此框架的各个阶段，请参阅迁移到 Google Cloud：使用入门。
如需设计有效的迁移计划，建议您验证计划的每个步骤，并确保您具有回滚策略。为了帮助验证您的迁移计划，请参阅迁移到 Google Cloud：验证迁移计划的最佳做法。
评估来源环境
在评估阶段，您需要确定从来源环境迁移到 Google Cloud 的要求和依赖项。
评估阶段对于成功迁移而言至关重要。您需要深入了解需要迁移的工作负载，它们的要求和依赖项以及您当前的环境。您需要清楚自己的起点，这样才能成功地计划和执行 Google Cloud 迁移。
评估阶段包括以下任务：
- 构建一个完整的工作负载清单。
- 根据工作负载的属性和依赖项对工作负载进行分类。
- 为您的团队开展 Google Cloud 培训和指导
- 在 Google Cloud 上构建实验和概念验证。
- 计算目标环境的总拥有成本 (TCO)。
- 为工作负载选择迁移策略。
- 选择迁移工具。
- 定义迁移计划和时间表。
- 验证迁移计划。
如需详细了解评估阶段和这些任务，请参阅迁移到 Google Cloud：评估和发现工作负载。以下部分基于该文档中的信息。
构建 Amazon EC2 实例的清单
如需确定迁移范围，请创建 Amazon EC2 实例的清单。然后，您可以使用清单评估在这些实例上部署工作负载的部署和操作流程。
如需构建 Amazon EC2 实例的清单，我们建议您使用 Migration Center，这是 Google Cloud 的统一平台，可帮助您加快从当前环境到 Google Cloud 的端到端云之旅速度。 借助 Migration Center，您可以从 Amazon EC2 和其他 AWS 资源导入数据。然后，Migration Center 会推荐您可以迁移到的相关 Google Cloud 服务。
使用 Migration Center 评估您的环境后，我们建议您使用 Migration Center 资产识别客户端 CLI 生成技术迁移评估报告。如需了解详情，请参阅从 Amazon EC2 实例收集客机数据以进行离线评估。
Migration Center 和 Migration Center 资产识别客户端 CLI 提供的数据可能无法完全捕获您感兴趣的维度。在这种情况下，您可以将该数据与您创建的基于 AWS API、AWS 开发者工具和 AWS 命令行界面的其他数据收集机制的结果集成。
除了从 Migration Center 和 Migration Center 资产识别客户端 CLI 获取的数据之外，还请考虑您要迁移的每个 Amazon EC2 实例的以下数据点：
- 部署区域和可用区。
- 实例类型和大小。
- 启动实例的 Amazon 机器映像 (AMI)。
- 实例主机名，以及其他实例和工作负载如何使用此主机名与该实例进行通信。
- 实例标记以及元数据和用户数据。
- 实例虚拟化类型。
- 实例购买选项，例如按需购买或现货购买。
- 实例如何存储数据，例如使用实例存储和 Amazon EBS 卷。
- 实例租户配置。
- 实例是否在特定的放置群组中。
- 实例是否在特定的自动扩缩群组中。
- 实例所属的安全群组。
- 任何涉及实例的 AWS 网络防火墙配置。
- 在实例上运行的工作负载是否受 AWS Shield 和 AWS WAF 保护。
- 您是否控制实例的处理器状态，以及实例上运行的工作负载如何取决于处理器状态。
- 实例 I/O 调度器的配置。
- 如何将在实例上运行的工作负载公开给在 AWS 环境中运行的客户端（例如其他工作负载）和外部客户端。
评估您的部署和运营流程
请务必清楚了解部署和运营流程的工作原理。这些流程是准备和维护生产环境以及在其中运行的工作负载的实践的基本组成部分。
部署和运营流程可能会构建工作负载正常运行所需的工件。因此，您应该收集有关每种工件类型的信息。例如，工件可以是操作系统软件包、应用部署包、操作系统映像、容器映像或其他类型。
除了工件类型之外，请考虑如何完成以下任务：
- 开发工作负载。评估开发团队为构建工作负载而制定的流程。例如，您的开发团队如何设计、编写和测试工作负载？
- 生成您在来源环境中部署的工件。为了在来源环境中部署工作负载，您可能会生成可部署的工件（例如容器映像或操作系统映像），或者您可能会通过安装和配置软件来自定义现有工件（例如第三方操作系统映像）。收集有关如何生成这些工件的信息有助于确保生成的工件适合在 Google Cloud 中部署。
存储工件。如果您生成存储在来源环境的 Artifact Registry 中的工件，则需要在 Google Cloud 环境中提供这些工件。为此，您可以使用以下策略：
- 在环境之间建立通信通道：使来源环境中的工件可从目标 Google Cloud 环境进行访问。
- 重构工件构建流程：完成来源环境的小幅度重构，以便在来源环境和目标环境中存储工件。此方法通过在目标 Google Cloud 环境中实现工件构建流程之前先构建工件制品库等基础架构来支持迁移。您可以直接实现此方法，也可以在上述先建立通信通道方法的基础上进行构建。
通过在来源环境和目标环境中均提供工件，您可以专注于迁移，而无需在迁移过程中在目标 Google Cloud 环境中实现工件构建流程。
扫描代码并签名。在工件构建流程中，您可能会使用代码扫描来帮助防范常见漏洞和意外的网络泄露，并使用代码签名来帮助确保只有受信任的代码在您的环境中运行。
在来源环境中部署工件。生成可部署的工件后，您可能会将其部署到来源环境中。建议您评估每个部署流程。评估有助于确保您的部署流程与 Google Cloud 兼容。它还有助于您了解最终重构流程所需的工作量。例如，如果部署流程仅适用于来源环境，则可能需要重构它们，从而以您的 Google Cloud 环境为目标。
注入运行时配置。您可能会注入特定集群、运行时环境或工作负载部署的运行时配置。该配置可能会初始化环境变量和其他配置值，例如 Secret、凭据和密钥。为帮助确保运行时配置注入过程在 Google Cloud 上正常运行，建议您评估如何配置在来源环境中运行的工作负载。
日志记录、监控和剖析。评估您实施来监控来源环境的健康、相关指标以及您如何使用这些流程提供的数据的日志记录、监控和剖析流程。
Authentication。评估您如何向来源环境进行身份验证。
预配和配置您的资源。为了准备来源环境，您可能设计并实现了预配和配置资源的流程。例如，您可能会使用 Terraform 以及配置管理工具在来源环境中预配和配置资源。
规划和构建基础
在规划和构建阶段，您需要预配和配置基础架构以执行以下操作：
- 在 Google Cloud 环境中支持您的工作负载。
- 连接来源环境和 Google Cloud 环境以完成迁移。
规划和构建阶段由以下任务组成：
- 构建资源层次结构。
- 配置 Google Cloud 的 Identity and Access Management (IAM)。
- 设置结算功能。
- 设置网络连接。
- 强化安全性。
- 设置日志记录、监控和提醒。
如需详细了解这些任务，请参阅迁移到 Google Cloud：规划和构建基础。
迁移工作负载
如需将工作负载从 Amazon EC2 迁移到 Compute Engine，请执行以下操作：
- 将虚拟机从 Amazon EC2 迁移到 Compute Engine。
- 将虚拟机磁盘迁移到 Persistent Disk。
- 将 Compute Engine 上运行的工作负载公开给客户端。
- 重构部署和运营流程，以定位 Google Cloud 而不是定位 Amazon EC2。
以下各部分详细介绍了这些任务。
将虚拟机迁移到 Compute Engine
如需将虚拟机从 Amazon EC2 迁移到 Compute Engine，我们建议您使用 Migrate to Virtual Machines（一项全代管式服务）。如需了解详情，请参阅使用 Migrate to VMs 进行迁移的过程。
在迁移过程中，除了所需的配置更改之外，Migrate for VM 还会迁移处于当前状态的 Amazon EC2 实例。如果 Amazon EC2 实例运行自定义的 Amazon EC2 AMI，Migrate for VMs 会将这些自定义设置迁移到 Compute Engine 实例。但是，如果您想使您的基础架构可重现，您可能需要通过构建 Compute Engine 操作系统映像作为部署和操作流程的一部分来应用等效的自定义，如前所述在本文档的后面。您还可以将 Amazon EC2 AMI 导入 Compute Engine。
将虚拟机磁盘迁移到 Persistent Disk
您还可以使用 Migrate to VMs 将磁盘从源 Amazon EC2 虚拟机迁移到 Persistent Disk，同时将对在 Amazon EC2 虚拟机上运行的工作负载的干扰降到最低。如需了解详情，请参阅迁移虚拟机磁盘并将其挂接到新虚拟机。
例如，您可以将附加到 Amazon EC2 虚拟机的数据磁盘迁移到 Persistent Disk，然后将其附加到新的 Compute Engine 虚拟机。
公开在 Compute Engine 上运行的工作负载
将 Amazon EC2 实例迁移到 Compute Engine 实例后，您可能需要预配和配置 Google Cloud 环境以将工作负载公开给客户端。
Google Cloud 提供了安全可靠的服务和产品，用于将您的工作负载公开给客户端。对于在 Compute Engine 实例上运行的工作负载，您可以为以下类别配置资源：
- 防火墙
- 流量负载均衡
- DNS 名称、区域和记录
- DDoS 防护和 Web 应用防火墙
对于这些类别中的每一个，您可以首先实现一个基线配置，该配置类似于您在等效类别中配置 AWS 服务和资源的方式。然后，您可以迭代配置并使用 Google Cloud 服务提供的其他功能。
以下部分介绍了如何预配和配置这些类别中的 Google Cloud 资源，以及它们如何映射到类似类别中的 AWS 资源。
防火墙
如果您配置了 AWS 安全组以及 AWS 网络防火墙政策和规则，则可以配置 Cloud 新一代防火墙政策和规则。您还可以预配 VPC Service Controls 规则以监管 VPC 内的网络流量。您可以使用 VPC Service Controls 阻止与 Compute Engine 实例的不需要的网络连接，并帮助降低数据渗漏的风险。
例如，如果您使用 AWS 安全组来允许或拒绝与您的 Amazon EC2 实例的连接，您可以配置适用于您的 Compute Engine 实例的类似 Virtual Private Cloud (VPC) 防火墙规则。
流量负载均衡
如果您已在 AWS 环境中配置 Elastic Load Balancing (ELB)，则可以配置 Cloud Load Balancing 以分配网络流量，以帮助提高工作负载的可伸缩性。Cloud Load Balancing 支持多个全球和区域负载均衡产品，这些产品在 OSI 模型的不同层工作，例如传输层和应用层。您可以选择适合工作负载要求的负载均衡产品。
Cloud Load Balancing 还支持配置传输层安全协议 (TLS) 来加密网络流量。为 Cloud Load Balancing 配置 TLS 时，您可以根据自己的要求使用自行管理或 Google 管理的 TLS 证书。
DNS 名称、区域和记录
如果您在 AWS 环境中使用 Amazon Route 53，则可以在 Google Cloud 中使用以下内容：
- Cloud Domains，用于注册 DNS 网域。
- Cloud DNS：用于管理公共和专用 DNS 区域和 DNS 记录。
例如，如果您使用 Amazon Route 53 注册网域，则可以将域名注册转移到 Cloud Domains。同样，如果您使用 Amazon Route 53 配置了公共和专用 DNS 区域，则可以将该配置迁移到 Cloud DNS。
DDoS 防护和 Web 应用防火墙
如果您在 AWS 环境中配置了 AWS Shield 和 AWS WAF，则可以使用 Google Cloud Armor 保护您的 Google Cloud 工作负载免受 DDoS 攻击和常见漏洞攻击。
重构部署和操作流程
重构工作负载后，您可以重构部署和运营流程以执行以下操作：
- 在 Google Cloud 环境中预配和配置资源，而不是在来源环境中预配资源。
- 构建和配置工作负载并在 Google Cloud 中部署它们，而不是在来源环境中部署。
您在此过程早期的评估阶段收集了有关这些流程的信息。
您需要为这些流程考虑的重构类型取决于您如何设计和实现它们。重构还取决于您希望每个流程的最终状态是什么。例如，应该考虑以下事项：
- 您可能已经在来源环境中实现了这些流程，并打算在 Google Cloud 中设计和实现类似流程。例如，您可以重构这些流程，以使用 Cloud Build、Cloud Deploy 和 Infrastructure Manager。
- 您可能已在来源环境之外的其他第三方环境中实现这些流程。在这种情况下，您需要重构这些流程，以将您的 Google Cloud 环境作为目标，而不是将来源环境作为目标。
- 之前方法的组合。
重构部署和运营流程可能很复杂，并且可能需要花费大量精力。如果您尝试将这些任务作为工作负载迁移的一部分执行，则工作负载迁移可能会变得更加复杂，并可能使您面临风险。评估部署和操作流程后，您可能了解了其设计和复杂性。如果您估计重构部署和操作流程需要大量工作，建议您考虑将重构这些流程作为单独的专用项目的一部分。
如需详细了解如何在 Google Cloud 上设计和实现部署流程，请参阅：
本文档重点介绍用于生成要部署的工件并将其部署在目标运行时环境中的部署流程。重构策略在很大程度上取决于这些流程的复杂性。以下列表概述了一种可能的通用重构策略：
- 在 Google Cloud 上预配工件仓库。例如，您可以使用 Artifact Registry 存储工件和构建依赖项。
- 重构构建流程，以便在来源环境和 Artifact Registry 中存储工件。
- 重构部署流程，以便在目标 Google Cloud 环境中部署工作负载。例如，您可以先使用存储在 Artifact Registry 中的工件，在 Google Cloud 中部署一小部分工作负载。然后，您可以逐步增加在 Google Cloud 中部署的工作负载数量，直到要迁移的所有工作负载都在 Google Cloud 上运行。
- 重构 build 流程，以仅将工件存储在 Artifact Registry 中。
- 如有必要，请将要部署的较低版本的工件从来源环境中的代码库迁移到 Artifact Registry。例如，您可以将容器映像复制到 Artifact Registry。
- 当您不再需要来源环境中的代码库时，请将其停用。
为方便在迁移过程中因意外问题而最终回滚，您可以在迁移到 Google Cloud 的过程中将容器映像存储在 Google Cloud 中的当前工件仓库中。最后，在停用来源环境的过程中，您可以重构容器映像构建流程，以仅将工件存储在 Google Cloud 中。
虽然这对于成功迁移可能并不重要，但您可能需要将较低版本的工件从来源环境迁移到 Google Cloud 上的工件仓库。例如，为了支持将工作负载回滚到任意时间点，您可能需要将工件的早期版本迁移到 Artifact Registry。如需了解详情，请参阅从第三方注册表迁移映像。
如果您使用 Artifact Registry 存储工件，我们建议您配置控制功能来帮助保护工件仓库，例如访问权限控制、数据渗漏防范、漏洞扫描和 Binary Authorization。如需了解详情，请参阅控制访问权限和保护工件。
优化您的 Google Cloud 环境
优化是迁移的最后一个阶段。在此阶段中，您将对优化任务进行迭代，直到目标环境满足您的优化要求。每个迭代的步骤如下：
- 评估您的当前环境、团队和优化循环。
- 确定优化要求和目标。
- 优化您的环境和团队。
- 调整优化循环。
重复执行这个任务序列，直到达到您的优化目标。
如需详细了解如何优化 Google Cloud 环境，请参阅迁移到 Google Cloud：优化您的环境和 Google Cloud 架构框架：性能优化。
后续步骤
- 了解其他 AWS 到 Google Cloud 的迁移过程。
- 了解如何将 AWS 和 Azure 服务与 Google Cloud 进行比较。
- 了解何时寻求迁移帮助。
- 如需查看更多参考架构、图表和最佳实践，请浏览 Cloud 架构中心。
贡献者
作者：Marco Ferrari | 云解决方案架构师