本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
使用 AWS 应用程序迁移服务进行迁移
要 AWS 使用AWS Application Migration Service
这种块级复制方法不支持网络连接存储 (NAS)、共享驱动器（例如网络文件系统 (NFS) 共享）或通用互联网文件系统 (CIFS) /服务器消息块 (SMB) 共享。它仅支持在迁移时直接连接到迁移系统的块级存储。（有关更多信息，请参阅有关 SAN/NAS 支持的应用程序迁移服务常见问题解答。） 这限制了通过应用程序迁移服务对大多数群集系统进行复制的适用性，因为大多数群集依赖于各种实现的共享存储。有关更多信息，请参阅本页的 “优缺点” 部分。
块级复制方法要求您在操作系统 (OS) 级别安装 AWS 复制代理，并且该代理仅支持基于 Windows 或 Linux 操作系统的 x86 平台（请参阅应用程序迁移服务支持的操作系统）。非 x86 平台超出了此迁移方法的范围。其中包括 ARM、 RISC/CISC 系统、PowerPC 变体、IBM 系统（例如 pSeries、iSeries、zSeries）及其各自的操作系统，例如 AIX、HP-UX、Solaris、适用于 PowerPC 的 Linux、大型机上的 zLinux 和其他非 x86 架构。
AWS Replication Agent 在操作系统堆栈中的虚拟文件系统设备驱动程序*级别上工作，捕获要写入底层数据块级设备（包括驱动器、硬盘驱动器和直接连接的 SAN 设备）的所有数据块，如应用程序迁移服务常见问题解答页面中以下问题所述：
* 参见维基百科中文件系统
优点
对于任何规模的 lift-and-shift迁移，应用程序迁移服务都有许多好处：
-
复制易于设置（不需要陡峭的学习曲线）。
-
通过在源计算机上推出代理，它可以快速扩展。
-
您可以使用云迁移工厂
自动执行大多数手动任务、管理多台计算机和编排迁移波次。 -
它支持广泛的 x86 操作系统架构。
-
它支持任何类型的源环境（本地数据中心、任何其他云或其他云 AWS 区域）。
-
它与应用程序无关，因此它支持在源服务器上运行的任何应用程序。
-
无需许可或购买。 AWS 提供 pay-as-you-go定价，因此您只需在使用服务期间付费，无需签订长期合同或复杂的许可。应用程序迁移服务为每台服务器提供 90 天的免费使用期，这对于大多数迁移来说已经足够了。有关详细信息，请参阅 AWS 网站上的AWS Application Migration Service 定价
。
缺点
使用块级复制工具（例如应用程序迁移服务）时，可能会遇到以下需要考虑的极端情况和因素：
-
应用程序迁移服务不支持已装载的共享文件系统或共享存储设备，例如 NAS，包括 CIFS/SMB 和 NFS 文件系统。有关 NAS 或共享文件系统的复制方法的更多信息，请参阅用于迁移 NFS 共享的 MGN 复制代理
（re AWS : Post 文章）和在AWS 大型迁移中迁移共享文件系统（AWS 规范指导模式）。 -
应用程序迁移服务不支持大多数使用共享存储的群集文件服务器或数据库群集配置，因为通过设备驱动程序层向操作系统级别表示共享存储的方式存在限制。例如，不支持带有 “存储空间直接 (S2D)” 选项的 Microsoft SQL Server 群集。但是，您仍然可以使用应用程序迁移服务使用共享块存储复制其他类型的群集系统，例如Windows服务器故障转移群集 (WSFC) 中故障转移群集实例 (FCI) 配置中的共享存储，如博客文章将您的微软 Windows 群集迁移到 AWS 使用 CloudEndure迁移
中所述，从外部 SAN 阵列（iSCSI 连接）暴露的存储，以及特定极端情况下的某些 Microsoft SQL Server Always On 可用性组 (AAG) 群集。通常，应用程序迁移服务支持从服务器复制块级设备，在迁移过程中，存储设备完全存在于服务器上。（ AWS 复制代理必须安装在服务器上，并且该设备必须对代理可见，才能进行复制。） 但是，所有这些场景都需要非常具体的程序，并且会导致更长的转换窗口。 -
数据更改率较高的系统（如 OLTP 数据库）可能对性能或网络要求有更高的要求，这会使迁移工作更复杂。
-
网络带宽必须足以在计划的迁移和割接时间窗口内传输大量数据。这是因为与之不同的是，应用程序迁移服务不提供离线配送选项AWS Snowball
。 -
迁移需要很短的停机时间，在几分钟的 RTO 之内。应用程序迁移服务使用 EBS 快照作为迁移过程的一部分，而从此类快照创建的新 EBS 磁盘最初性能较差。对于某些数据库读取模式，这可能会增加有效的割接窗口，直到迁移的数据库达到最高性能。
最适合的场景
如前两节所述，应用程序 lift-and-shift迁移服务几乎涵盖了所有迁移，但缺点很少。该工具可以处理大多数极端情况，如数据库集群，只要这些系统所需的较长割接窗口满足您的迁移要求。
以下部分深入介绍了两种场景：
-
具有多个迁移波次的大规模迁移
-
需要最短停机时间的单个应用程序迁移
具有多个迁移波次的大规模迁移
大规模迁移的一个例子是以大小和速度要求为特征的数据中心出口。它通常还涉及特定的时间限制，例如数据中心租赁合同的终止。在这种情况下，规模决定了方法。迁移波次由应用程序（包括数据库）确定和分组，每个迁移波次都有计划的准备、迁移和最终割接阶段，并有特定的停机时间要求。
在每个迁移浪潮中，最好使用应用程序迁移服务块级复制来大规模迁移数据库服务器，但以下特殊情况除外，可能需要单独的迁移方法：
-
大多数集群数据库系统
-
更改速率超过可用网络吞吐量的数据库系统（这可能会导致复制延迟）
对于每种特殊情况，请考虑停机时间要求与使用其他迁移工具的工作量之间的权衡。在某些情况下，对所有系统使用相同的迁移方法比使用单独的工具为特定系统创建不同的流程要容易得多。如果应用程序迁移服务不支持特定系统的停机时间要求，我们建议您改用使用本机数据库工具迁移部分中描述的方法之一。
单个应用程序迁移
单个应用程序场景代表了一种精细的方法，用来迁移单个业务关键型应用程序（需要最短或近零的停机时间）或几个这样的应用程序。与先前（大规模迁移）场景的速度和规模要求相比，迁移的范围可能会有所不同，具体取决于业务关键程度和停机时间要求。如果应用程序允许在应用程序迁移服务的 RTO 内停机，则应以与前面描述的任何大规模迁移相同的方式进行处理。
但是，如果切换时间必须尽可能接近最小值，例如，当迁移的数据库的读取模式需要很长时间才能以最高性能运行，并且切换窗口必须保持较小时，则应考虑采用更详细、更精细的方法。通常，这种方法涉及额外的步骤和要求，需要更多的精力和时间。其中一个步骤是将数据库迁移与应用程序服务器迁移分开，并使用下一节中描述的数据库迁移工具使源数据库和目标数据库保持同步。您可以使用多种方法来实现同步。每种方法都有优点和缺点，在停机时间和同步的复杂性之间需要进行不同的权衡。不过，在源环境和目标环境之间保持数据库同步，可以让您将数据库层与应用层分离开来。假设应用程序服务器不在本地存储永久性数据，而是将所有内容传递到数据库层，则同步还会消除应用程序层的停机时间限制。
通过将数据库层和应用程序层分离，您可以像前面的场景一样使用应用程序迁移服务来迁移应用程序服务器。目标应用程序服务器可以在目标环境中启动，而源系统仍在工作，处理数据并将其存储在数据库层中。由于数据库层已经与目标系统同步，因此切换时间极短，仅涉及切换网络并将客户请求从旧源系统重定向到目标环境。您可以使用多种方法来执行此操作，遵循蓝绿部署指南，通常通过切换 DNS 端点、使用加权 DNS 区域、使用 AWS Global Accelerator
