任务 1:执行初始发现并验证迁移策略 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

任务 1:执行初始发现并验证迁移策略

大型迁移项目组合评估的第一步是了解您目前拥有的信息、业务和技术驱动因素以及已经做出的任何迁移战略决策。投资组合评估的结果是持续将迁移元数据、波浪计划和迁移策略输入到迁移工作流中。根据收集的信息,您可以分析差距并决定下一步行动。如果您已经完成了分析和任务,则可以跳过本剧本中的某些部分。此任务由以下步骤组成:

步骤 1:验证发现数据

在移动阶段,您可能已经完成了最初的投资组合评估,如果已经完成,则可以在迁移阶段重用这些发现数据。如果不是,别担心。本手册将引导您了解支持大规模迁移所需的内容。

大型迁移通常包含大量数据。例如,您有:

  • 有关源服务器、应用程序和数据库的元数据

  • 来自配置管理数据库 (CMDB) 的 IT 产品组合信息

  • 来自发现工具的数据,可帮助您更好地了解当前状态和依赖关系

  • 目标AWS资源的元数据

关于元数据的类型

以下是支持大规模迁移所需的三种主要元数据类型:

  • 源产品组合元数据-源产品组合元数据是有关您的源服务器、应用程序和数据库的元数据。您可以从现有 CMDB、发现工具甚至应用程序所有者那里获取元数据。您可以在此处找到此元数据类型的完整列表,以下是一些示例:

    • 服务器名称

    • 服务器 IP 地址

    • 服务器操作系统 (OS)

    • 服务器存储/出操作 (IOPS)

    • 应用程序名称

    • 应用程序拥有者

    • Application-to-application 依赖关系

    • 业务单位

    • 一幅pplication-to-server 映射

    • 一幅pplication-to-database 映射

    • 数据库类型和大小

    • 存储类型和大小

    • 依赖元数据

    • 性能和使用情况数据

  • 目标环境元数据-这是一种元数据类型,可帮助您将服务器迁移到目标环境。你需要就目标环境做出决定。你可以从发现工具中获取一些元数据。以下是此元数据类型的一些示例:

    • 目标子网

    • 目标安全组

    • 目标实例类型

    • 目标AWS Identity and Access Management (IAM) 角色

    • 目标 IP 地址

    • 目标AWS账户 ID

    • 目标AWS区域

    • 目标AWS服务

    • 目标应用程序架构设计

  • 波浪规划元数据 — 波浪规划元数据是帮助您管理迁移的元数据类型。以下是此元数据的示例:

    • Wave ID

    • 波开始时间

    • 波形切换时间

    • Wave 拥有者

    • 保存到应用程序/服务器/数据库/移动组映射

验证您的发现数据

在做出任何决定之前,了解您当前的发现数据非常重要。在迁移的这个阶段,你可能没有所有的信息。本手册可帮助您定义元数据要求并帮助您有效地收集元数据。问问自己以下问题,以确定当前有哪些元数据可用及其可能位于何处:

  • 您是否使用过任何工具进行迁移评估,例如迁移评估器?

  • 您是否在环境中部署了任何发现工具,例如AWS Application Discovery Service或 Flexera One 云迁移和现代化?

  • 您是否有一个 CMDB 能为您的IT产品组合提供最多的 up-to-date 信息?

  • 您是否完成了动员阶段的初步投资组合评估?

  • 你完成了最初的波浪计划了吗?

  • 你完成了初始目标环境设计吗?

  • 每种元数据类型的来源是什么?

  • 你有权访问所有元数据吗?

  • 你如何访问所有的元数据?

  • 你记录了访问元数据的过程吗?

步骤 2:确定业务和技术驱动因素

在考虑每个应用程序的高级迁移策略和模式时,业务和技术驱动因素至关重要。您必须了解迁移所特有的驱动因素。在验证迁移策略和定义应用程序映射规则时,您可以使用这些业务和技术驱动因素。

常见的业务驱动因素

业务驱动因素是与业务目标或限制相关的因素,在规划大规模迁移时必须考虑这些因素,例如合同到期、快速增长或预算。以下是常见的业务驱动因素:

  • 退出数据中心-您需要尽快迁移到云端。例如,数据中心合同即将过期。

  • 降低运营成本和风险-您希望降低与运营本地环境相关的成本或风险。

  • 灵活性 — 您需要将迁移到云作为战略方向,以便为业务future 变化做好准备。

  • 发展业务 — 您需要能够快速加快发展和创新或适应快速增长。

  • 智能地使用数据 — 你想利用基于云的人工智能、机器学习和物联网 (IoT),它们可以预测公司的增长并提供对客户行为的见解。

  • 提高安全性和合规性 — 您需要利用AWS云基础架构中已经内置的合规计划,或者您希望利用基于软件的安全工具来警告您数据可能受到威胁。

  • 资源可用性 — 资源有限或内部经验有限可能会导致您选择无需修改即可移动应用程序的策略。

常见技术驱动程序

技术驱动因素是与技术目标或限制相关的因素,在规划大规模迁移(例如当前架构)时必须考虑这些因素。以下是常见的技术驱动程序:

  • 硬件或软件 end-of-support — 您的硬件或软件已接近其生命周期的尽头,您需要对其进行更新,因为供应商不再支持它。

  • 技术集成 — 您可以访问全球基础架构,使您能够快速、战略性地扩展应用程序。借助随时可用的全球服务和基础架构,您可以快速走向全球。

  • 存储和计算限制 — 您的数据中心没有容量容纳更多存储或服务器,您需要寻找其他地方进行扩展。

  • 可扩展性和弹性要求 — 您的应用程序过去曾经历过停机,您希望使用云来改善恢复点目标 (RPO) 和恢复时间目标 (RTO)。

  • 对应用程序架构进行现代化改造 — 您希望利用云的优势,将应用程序更改为云原生应用程序。

  • 提高性能 — 在旺季期间,您的应用程序性能很差,您需要自动向上和向下扩展以满足需求。

更新运行手册*

  1. 投资组合手册模板中,打开用于应用程序优先级排序的 Runbook 模板(Microsoft Word 格式)。

  2. 在 “业务和技术驱动因素” 部分,记录您为大型迁移项目确定的驱动程序。

  3. 保存您的应用程序优先级排序操作手册。

步骤 3:验证迁移策略

选择迁移策略对于大规模迁移至关重要。您必须验证您选择的迁移策略是否符合组织的期望、限制和要求。有关可用迁移策略的更多信息,请参阅AWS大型迁移指南

您可能在动员阶段或初始投资组合评估期间选择了迁移策略。在此步骤中,您将使用业务和技术驱动因素来选择和验证投资组合的迁移策略。

随着您继续评估投资组合并开始迁移,您的迁移策略可能会发生变化。在此阶段,目标是了解您的投资组合在每种迁移策略中的总体分布情况。选择迁移策略对于下一步至关重要,即验证详细的迁移模式。

选择并验证迁移策略

评估产品组合并选择迁移策略,如下所示:

  1. 查看您在上一步中确定的所有技术和业务驱动因素,并根据业务需求确定驱动因素的优先级。

  2. 将每个业务和技术驱动因素映射到迁移策略中。下表是一个示例。

    优先级 业务或技术驱动程序 迁策略

    1

    在指定日期之前退出数据中心

    重新托管尽可能多的应用程序,只有在无法重新托管时才进行平台重构和重构。

    2

    降低运营成本和风险

    要加快迁移速度,请重新托管尽可能多的应用程序。

    3

    硬件或软件 end-of-support

    重新托管支持的应用程序,将不支持的应用程序重新托管到云中较新的硬件和软件上。

    4

    资源可用性

    重新部署到 VMware Cloud 或重新托管到AWS Managed Services (AMS) 以减少运营开销。

  3. 通过权衡每种业务和技术驱动因素并对您的产品组合进行高层次评估,估算应如何在每种迁移策略之间分配应用程序。经常会看到驱动程序之间的冲突。项目利益相关者需要共同努力并做出最终决定以解决冲突。下面是您如何将您的投资组合分配到每个迁移策略:

    • 重新托管 — 60%

    • 平台重组 — 15%

    • 退休 — 10%

    • 保留 — 5%

    • 回购 — 5%

    • 重构 — 5%

在为投资组合选择高级迁移策略之前,不要继续进行迁移。

更新运行手册*

  1. 打开您的应用程序优先级管理手册。

  2. 迁移策略部分中,记录应用程序工作负载在七种迁移策略之间的分布情况。例如:

    • 重新托管 — 60%

    • 平台重组 — 15%

    • 退休 — 10%

    • 保留 — 5%

    • 回购 — 5%

    • 重构 — 5%

  3. 保存您的应用程序优先级排序操作手册。

步骤 4:验证迁移模式

关于迁移模式

迁移模式是一种可重复的迁移任务,它详细说明了迁移策略、迁移目的地以及所使用的迁移应用程序或服务。示例是 Amazon Elastic Compute Cloud (Amazon EC2)AWS Application Migration Service。常见迁移模式中经常提及以下AWS服务和解决方案:

  • AWS App2Container

  • AWS Application Migration Service(AWS MGN)

  • AWS CloudFormation

  • AWS Database Migration Service (AWS DMS)

  • AWS DataSync

  • Amazon Elastic Compute Cloud (Amazon EC2)

  • Amazon Elastic Container Service (Amazon ECS)

  • Amazon Elastic File System (Amazon EFS)

  • AWS云迁移工厂解决方案

  • Amazon Relational Database Service (Amazon RDS)

  • AWS Schema Conversion Tool (AWS SCT)

  • AWS Transfer Family

与选择迁移策略类似,您可能已经在早期阶段确定了迁移模式。但是,您必须对其进行验证,并确保已定义和记录这些模式。下表列出了常见的迁移策略和模式。

ID Strategy Pattern

1

重新托管

使用应用程序迁移服务或云迁移工厂重新托管到 Amazon EC2

2

平台转换

使用AWS DMS和将平台重置为 Amazon RDSAWS SCT

3

平台转换

使用将平台重置为Amazon EC2AWS CloudFormation

注意

CloudFormation 模板在中构建新的基础架构AWS Cloud

4

平台转换

使用AWS DataSync或将平台重置为 Amazon EFSAWS Transfer Family

5

平台转换

使用 AAWS pp2Container 将平台重置为亚马逊 ECS

6

平台转换

使用模拟器将大型机或中端服务器平台重置为 Amazon EC2

7

平台转换

在 Amazon EC2 上从 Windows 改为 Linix

8

停用

停用应用程序

9

保留

在本地保留

10

回购

回购并升级到 SaaS

11

搬迁

AWS使用 VMware HCX 重新部署到 VMware Cloud

12

重构或重新架构

重新架构应用程序

更新运行手册*

此时,您可以在投资组合层面定义模式。在本剧本的稍后部分,您将每个应用程序映射到其相应的迁移模式。

  1. 打开您的应用程序优先级管理手册。

  2. 迁移模式部分中,记录您已识别和验证的迁移模式。为每个模式分配一个唯一的 ID 并记下该模式的迁移策略。

  3. 保存您的应用程序优先级排序操作手册。

请注意,迁移模式可能会随着您的进展而改变。稍后,当你发现新信息、改变工作负载范围,甚至决定使用新AWS服务时,你可能会改变迁移策略和模式。

任务退出条件

如果您尚未从高级投资组合的角度确定迁移策略和模式,我们强烈建议您在继续执行下一个任务之前与技术团队合作定义这些策略和模式。投资组合评估和波浪规划取决于对迁移策略和模式的理解。在继续操作之前,您不需要拥有完整的迁移模式列表。您可以随时添加新模式并调整策略。

完成以下任务后,继续执行下一个任务:

  • 您可以访问并理解最新的发现数据。

  • 您已经确定了迁移的业务和技术驱动因素。

  • 您已经根据您的业务和技术驱动因素选择并验证了迁移策略。

  • 您已经选择并验证了迁移模式。

  • 您已在应用程序优先级划分运行手册中记录了以下内容:

    • 业务和技术驱动因素

    • 迁移策略

    • 迁移模式