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

# Windows 环境发现
<a name="windows-environment-discovery"></a>

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

## 评测
<a name="assess-discovery"></a>

虽然您可以用最少的计划和自动化来“强制执行”较小的迁移（例如涉及 100 台服务器的迁移），但无法用此方法迁移 500 台或更多服务器。以下注意事项是成功进行大规模迁移的主要因素，您可以使用[迁移准备情况评测（MRA）](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/assessment-phase.html)来确定您想要重点关注的考虑领域。

### 企业架构
<a name="enterprise-arch"></a>

环境中存在的技术债务越多，迁移就越困难。拥有运行状况良好的企业架构计划的组织会努力将其环境限制在当前和最近的软件和系统版本（通常称为主要版本的 N 和 N -1 版本）。这不仅减少了您必须考虑的场景数量，还利用了新版本带来的进步。例如，Windows Server 2012、Windows Server 2008 和较旧版本的 Windows Server 在 Windows Server 环境中实现自动化的难度逐渐比当前版本要困难得多。对于较旧且不受支持的版本，许可也更加困难。

### 标准化和配置管理
<a name="standard-config"></a>

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

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

### 良好的数据
<a name="good-data"></a>

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

### 自动化
<a name="automation"></a>

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

### 详细规划
<a name="detailed-planning"></a>

制定和管理详细的计划对于大规模迁移也至关重要。您必须制定完善的计划，在数周内每周迁移 50 台服务器。有效的计划包括：
+ 使用**波次规划**，根据您的依赖关系和优先级将服务器组织成波次。
+ 使用**每周规划**（在割接之前）与应用程序团队沟通，并确定割接期间必须解决的网络、DNS、防火墙及其他详细信息。
+ 使用详细的** hour-to-hour计划**（围绕实际切换）来描述切换维护窗口。
+ 使用**准入/退出标准**来描述在什么情况下应用程序将视为割接到 AWS ，或者必须故障恢复到源位置。
+ 使用**清理活动**作为必须完成的后续活动。这些活动可能发生在割接维护时段之外或 [hypercare](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/managing-large-migration.html#hypercare-period) 完成之后。清理活动包括验证备份和各种代理、从服务器中删除 Application Migration Service 代理或删除源服务器和关联的资源。

## 动员
<a name="mobilize-discovery"></a>

在动员阶段，尽可能多地发现组织的复杂性和差异非常重要，以便在迁移规划期间加以考虑。理想情况下，您可以避免在割接维护时段处理此类复杂性和差异，并防止任何失效自动恢复。

### 大规模迁移的挑战
<a name="scale-challenges"></a>

当应用程序已割接到其新环境，并且在迁移维护时段内无法满足性能或功能要求时，就会发生迁移失败。这会迫使应用程序（或多个应用程序）失效自动恢复到其原始位置。此外，依赖于这些应用程序的所有其他应用程序也需要进行失效自动恢复。迁移失败往往不仅会影响当前波次，还会影响未来波次，因为必须重新计划应用程序。

### 延迟敏感型依赖关系
<a name="latency-dependencies"></a>

迁移失败的主要原因是依赖关系对延迟非常敏感。未能识别对延迟敏感的依赖关系可能会导致性能问题，从而导致不可接受的响应时间或事务时间。

例如，应用程序通常会将其数据库和应用程序服务器同时迁移到云，因为它们经常相互通信，并且当它们位于同一个数据中心时需要亚毫秒级的响应时间。仅将数据库迁移到云可能会给这些事务带来数秒钟的延迟，从而对应用程序的性能造成显著影响。这也适用于彼此高度依赖且必须位于同一个数据中心才能充分发挥性能的应用程序。

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

### IT 共享服务
<a name="shared-services"></a>

工作负载进入云后，需要各种服务才能正常安全地运行和维护。其中包括登录区、网络和安全边界、身份验证、补丁、安全扫描仪、IT 服务管理工具、备份、堡垒主机及其他资源。如果没有这些服务，工作负载可能无法正常运行，将强制失效自动恢复到其原始位置。

### 配置更新
<a name="config-updates"></a>

在大多数情况下，您必须对工作负载进行多项配置更改，才能在该工作负载移至云后正常运行。这些配置更改通常与工作负载的以下依赖关系关联：
+ 防火墙规则
+ 允许列表
+ DNS 记录
+ 连接字符串

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

### 应用程序功能测试
<a name="app-functional"></a>

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

### 用于发现应用程序依赖项的工具
<a name="tools-app-discovery"></a>

确定应用程序之间的依赖关系对于成功迁移至关重要，无论是检测延迟敏感的依赖关系还是连接配置项目。市场上有多种用于发现依赖关系的工具，例如[AWS Transform 发现工具（基于代理的工具](https://docs.aws.amazon.com/transform/latest/userguide/discovery-tool.html)）和 [Cloudamize](https://cloudamize.com/en/)（基于代理的工具）。

在选择应用程序依赖项发现工具时，请考虑以下事项：
+ **持续时间**：我们建议您运行发现工具的时间足够长，以捕获特定于应用程序的事件，例如已知的高峰、月末和其他事件。建议的最短时间为 30 天。
+ **主动（基于代理）**：主动依赖项发现工具通常嵌入在操作系统的内核中并捕获所有事务。但是，这通常是最昂贵和最耗时的方法。
+ **被动**（**无代理**）：被动依赖项发现工具要便宜得多，实施起来也更快，但有可能错过一些较少使用的连接。
+ **机构知识**：虽然应用程序发现工具提供了更详细、更准确的信息，但大多数组织还是依赖应用程序团队和机构知识来发现应用程序依赖关系。应用程序团队通常了解对延迟敏感的依赖关系，但他们常常会忽略一些细节，例如连接配置设置、防火墙规则或合作伙伴的允许列表要求。您可以使用机构知识来增强应用程序依赖项发现，但我们建议您同时考虑并降低所涉及的风险。例如，如果您仅依赖应用程序团队的知识，则存在缺少连接配置项目或延迟敏感依赖关系的风险。这可能会导致服务中断或迁移失败。为了降低此风险，我们建议您进行详细的应用程序功能测试。