Windows 环境发现

借助当今的可用技术，例如应用程序迁移服务，将 Windows Server、Linux 和其他基于 x86 的操作系统及其工作负载迁移到 AWS 相当简单。但是，让这些工作负载正常工作并大规模运行会带来一系列不同的挑战。本节旨在确定迁移注意事项，使您能够快速、安全、顺利地迁移您的 Microsoft 工作负载。

评估

尽管您可以用最少的规划和自动化程度 “强制” 较小的迁移（例如涉及 100 台服务器的迁移），但使用这种方法无法移动 500 个或更多服务器。以下注意事项是成功进行大规模迁移的主要因素，您可以使用迁移准备情况评估 (MRA)确定您想要重点关注的考虑领域。

企业架构

环境中的技术债务越多，迁移的难度就越大。拥有健全的企业架构程序的组织会努力将其环境限制在软件和系统的当前和最新版本（通常称为主要版本的 N 和 N -1 版本）范围内。这不仅减少了你必须考虑的场景数量，而且还利用了新版本的进步。例如，Windows Server 2012、Windows Server 2008 和较早版本的 Windows Server 在 Windows Server 环境中实现自动化的难度比当前版本要困难得多。对于较旧和不支持的版本，许可也更加困难。

标准化和配置管理

环境的标准化是另一个需要考虑的因素。拥有手工建造和维护的环境的组织被认为更像宠物。每个系统都是独一无二的，与使用标准化映像、基础设施即代码 (IaC) 或持续集成和持续交付 (CI/CD) 管道构建相比，可能的配置组合要多得多。

例如，最佳做法是在迁移时使用 IaC 或 CI/CD 重建典型的 Web 服务器，而不是手动迁移单个服务器。将所有永久数据存储在数据库、文件共享或存储库等数据存储库中也是一种最佳做法。如果系统不是使用 iaC 或 CI/CD 重建的，则至少应使用配置管理工具（例如 Puppet、Chef 或 Ansible）来标准化现有服务器。

好数据

良好的数据也是成功迁移的关键因素。有关当前服务器及其元数据的准确数据对于自动化和规划至关重要。缺乏良好的数据会增加计划迁移的难度。优质数据的示例包括服务器的准确清单、服务器上的应用程序、带有版本的服务器上的软件、CPU 数量、内存量和磁盘数量。我们建议您捕获波浪规划者进行规划所需的任何数据，或者您计划在自动化迁移过程中使用的任何数据。

 自动化

自动化对于大规模迁移至关重要。自动化的示例包括安装代理、更新自动化所需的实用程序的软件版本，例如.NET 或PowerShell，加载或更新 AWS 软件，例如 AWS Systems Manager 代理（SSM 代理）、亚马逊CloudWatch代理或其他在 AWS 中运行所需的备份或管理软件。

详细规划

制定和管理详细计划对于大规模迁移也至关重要。您必须制定明确的计划，在数周内每周迁移 50 台服务器。有效的计划包括以下内容：

• 使用波浪规划根据您的依赖关系和优先级将服务器组织成波形。

• 使用每周计划（在切换之前）与应用程序团队沟通，确定切换期间必须解决的网络、DNS、防火墙和其他细节。

• 使用详细， hour-to-hour规划（大约在实际切换范围内）来描述切换维护窗口。

• 使用通过/不通过标准描述在什么情况下应用程序将被视为切换到 AWS 或必须故障返回到源位置。

• 使用清理活动作为必须完成的后续活动. 这些活动可能在切换维护时段之外发生，也可能发生在切换维护时段完成之后过度护理。清理活动包括验证备份和各种代理、从服务器中删除应用程序迁移服务代理或删除源服务器和相关资源。

动员

在动员阶段，尽可能多地发现组织的复杂性和差异非常重要，以便在迁移计划中将其考虑在内。理想情况下，您可以避免在切换维护窗口期间处理此类复杂性和变化，并防止任何故障恢复。

大规模迁移的挑战

当一个或多个应用程序切换到其新环境并且在迁移维护窗口内无法满足性能或功能要求时，就会发生迁移失败。这会迫使一个或多个应用程序回退到其原始位置。此外，依赖于该或多个应用程序的所有其他应用程序也需要进行故障恢复。失败的迁移不仅会影响当前的浪潮，还会影响未来的浪潮，因为必须重新安排应用程序。

延迟敏感依赖关系

迁移失败的主要原因是延迟敏感的依赖关系。未能识别延迟敏感的依赖关系可能会导致性能问题，从而导致不可接受的响应时间或事务时间。例如，通常，应用程序会将其数据库和应用程序服务器同时移动到云中，因为它们经常相互通信，并且在两者位于同一个数据中心时需要亚毫秒的响应时间。仅将数据库迁移到云端可能会给这些事务带来数秒钟的延迟，从而对应用程序的性能产生重大影响。这也适用于彼此严重依赖且必须位于同一个数据中心才能正常运行的应用程序。

因此，在规划迁移时，了解和解决应用程序依赖关系至关重要。必须识别相互依赖的应用程序和服务，以便它们可以一起迁移。

IT 共享服务

工作负载进入云端后，需要各种服务才能正常安全地运行和维护。这包括着陆区、网络和安全边界、身份验证、补丁、安全扫描仪、IT 服务管理工具、备份、堡垒主机和其他资源。如果没有这些服务，工作负载可能无法正常运行，将被迫切回其原始位置。

配置更新

在大多数情况下，在工作负载移到云端后，您必须进行多项配置更改才能使该工作负载正常运行。这些配置更改通常与工作负载的以下依赖关系有关：

• 防火墙规则

• 允许列表

• DNS 记录

• 连接字符串

如果您没有进行正确的配置更新，则工作负载、其用户及其依赖系统可能无法相互通信。在中断窗口内解决这些问题是可能的，但是此时的更改可能很耗时，或者需要无法及时满足的变更记录。

应用程序功能测试

大规模迁移面临的另一个挑战是需要进行应用程序功能测试。这尤其重要，因为许多组织依靠应用程序团队来识别延迟敏感的依赖关系、IT 共享服务或所需的配置更新。理想情况下，应用程序团队提供书面或自动测试计划，他们可以在切换维护时段内运行该计划，以验证其应用程序是否功能齐全，性能可接受。为了最大限度地缩短切换维护时段，测试应该能够在 30 分钟内完成。

应用程序依赖关系发现工具

确定应用程序之间的依赖关系对于成功迁移至关重要，无论是检测延迟敏感依赖关系还是连接配置项目。市场上有几种工具可用于发现依赖关系，例如应用程序发现服务（代理和无代理工具）和Cloudamiz（基于代理的工具）。

在选择应用程序依赖关系发现工具时，请考虑以下几点：

• 持续时间— 我们建议您运行发现工具足够长的时间以捕获特定于应用程序的事件，例如已知的高峰、月末和其他事件。建议的最低天数为 30 天。

• 激活（基于代理）— 主动依赖关系发现工具通常嵌入到操作系统的内核中，可以捕获所有事务。但是，这通常是最昂贵和最耗时的方法。

• 被动（无代理）— 被动依赖关系发现工具要便宜得多，实施速度也更快，但有可能丢失一些较少使用的连接。

• 机构知识— 尽管应用程序发现工具提供了更详细、更准确的信息，但大多数组织依靠其应用程序团队和机构知识来发现应用程序依赖关系。应用程序团队通常对延迟敏感的依赖关系了如连接配置设置、防火墙规则或合作伙伴的允许列表要求等一些细节被忽视，这种情况并不少见。您可以使用机构知识来加强应用程序依赖关系的发现，但我们建议您也考虑并降低所涉及的风险。例如，如果您仅依赖应用程序团队的知识，则存在缺少连接配置项目或延迟敏感依赖项的风险。这可能会导致中断或迁移失败。为了降低这种风险，我们建议您进行详细的应用程序功能测试。