任务 1：执行初步发现并验证迁移策略 - AWS 规范性指导
步骤 1：验证发现数据第 2 步：确定业务和技术驱动因素步骤 3：验证迁移策略步骤 4：验证迁移模式任务退出标准

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

任务 1：执行初步发现并验证迁移策略

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

步骤 1：验证发现数据

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

大型迁移通常包含大量数据。例如，你有：

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

  • 配置管理数据库 (CMDB) 中有关您的 IT 产品组合的信息

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

  • 目标 AWS 资源的元数据

关于元数据的类型

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

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

    • 服务器名称

    • 服务器 IP 地址

    • 服务器操作系统 (OS)

    • 服务器存储、CPU、内存和每秒输入/输出操作数 (IOPS)

    • 应用程序名称

    • 应用程序所有者

    • Application-to-application 依赖关系

    • 业务部门

    • Application-to-server 映射

    • Application-to-database 映射

    • 数据库类型和大小

    • 存储类型和大小

    • 依赖关系元数据

    • 性能和使用数据

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

    • 目标子网

    • 目标安全组

    • 目标实例类型

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

    • 目标 IP 地址

    • 目标 AWS 账户 ID

    • 目标 AWS 区域

    • 目标 AWS 服务

    • 目标应用程序架构设计

  • 波浪规划元数据-波浪规划元数据是帮助您管理迁移的元数据类型。以下是这种元数据类型的示例：

    • Wave ID

    • 波浪开始时间

    • 波浪切换时间

    • Wave 所有者

    • 波到application/server/database/move群组的映射

验证您的发现数据

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

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

  • 您是否在自己的环境中部署了任何发现工具，例如 Flexera AWS Application Discovery Service One Cloud 迁移和现代化？

  • 您是否有一个包含最多 IT 产品组合 up-to-date信息的 CMDB？

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

  • 你完成了最初的浪潮规划吗？

  • 您是否完成了最初的目标环境设计？

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

  • 你有权访问所有的元数据吗？

  • 如何访问所有元数据？

  • 您是否记录了访问元数据的过程？

第 2 步：确定业务和技术驱动因素

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

常见的业务驱动因素

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

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

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

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

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

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

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

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

常见的技术驱动因素

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

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

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

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

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

  • 实现@@ 应用程序架构现代化 — 您希望利用云的优势，将应用程序更改为云原生。

  • 提高性能-在高峰季节，您的应用程序性能很差，您希望自动向上和向下扩展以满足需求。

更新运行手册

  1. 在产品组合剧本模板中，打开用于确定应用程序优先级的运行手册模板（Microsoft Word 格式）。

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

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

步骤 3：验证迁移策略

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

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

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

选择并验证迁移策略

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

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

  2. 将每个业务和技术驱动因素与迁移策略对应起来。下表是一个示例。

    优先级 业务或技术驱动因素 迁移策略

    1

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

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

    2

    降低运营成本和风险

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

    3

    硬件或软件 end-of-support

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

    4

    资源可用性

    重新托管到 AWS Managed Services (AMS) 以减少运营开销。

  3. 通过权衡每个业务和技术驱动因素并从较高的层面评估您的产品组合，估算应用程序在每种迁移策略中的分配方式。司机之间经常会出现冲突。项目利益相关者需要共同努力，做出最终决定以解决冲突。以下是如何将您的产品组合分配给每种迁移策略的示例：

    • 重新托管 — 60%

    • 平台重置 — 15%

    • 退休 — 10%

    • 保留 — 5%

    • 回购 — 5%

    • 重构 — 5%

在为产品组合选择了高级迁移策略之前，请勿继续迁移。

更新运行手册

  1. 打开您的应用程序优先级排序操作手册。

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

    • 重新托管 — 60%

    • 平台重置 — 15%

    • 退休 — 10%

    • 保留 — 5%

    • 回购 — 5%

    • 重构 — 5%

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

步骤 4：验证迁移模式

关于迁移模式

迁移模式是一种可重复的迁移任务，它详细说明了迁移策略、迁移目标以及所使用的迁移应用程序或服务。例如，使用 AWS Application Migration Service重新托管到亚马逊弹性计算云 (Amazon EC2)。常见迁移模式中经常提及以下 AWS 服务和解决方案：

  • AWS App2容器

  • AWS Application Migration Service (AWS MGN)

  • AWS CloudFormation

  • AWS Database Migration Service (AWS DMS)

  • AWS DataSync

  • 亚马逊弹性计算云（亚马逊 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 策略 模式

1

重新托管

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

2

更换平台

使用和将平台重定向 Amazon RDS AWS DMS AWS SCT

3

更换平台

使用 Amazon 将平台重定向到亚马逊 EC2 AWS CloudFormation

注意

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

4

更换平台

使用或将平台重定向 Amazon EFS AWS DataSync AWS Transfer Family

5

更换平台

使用 App2Container 将平台重置到亚马逊 ECS AWS

6

更换平台

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

7

更换平台

在亚马逊上将平台从 Windows 迁移到 Linux EC2

8

停用

停用应用程序

9

保留

在本地保留

10

回购

回购并升级到 SaaS

11

重构或重新架构

重新架构应用程序

更新运行手册

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

  1. 打开您的应用程序优先级排序操作手册。

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

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

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

任务退出标准

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

完成以下任务后，继续执行下一个任务：

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

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

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

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

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

    • 业务和技术驱动因素

    • 迁移策略

    • 迁移模式