无代理迁移体系结构

本文介绍在 Azure Migrate 中使用无代理迁移方法迁移 VMware 虚拟机（VM）时的复制概念。

复制过程

无代理复制选项的工作原理是使用 VMware 快照和 VMware 更改的块跟踪（CBT）技术从 VM 磁盘复制数据。 以下方块图显示了使用 Azure Migrate 迁移 VM 时所涉及的步骤。

为 VM 配置复制时，它会经历初始复制阶段。 在此阶段，Azure Migrate 会创建 VM 快照。 然后，该服务会将数据的完整副本从快照磁盘复制到目标订阅中的托管磁盘。

VM 的初始复制完成后，复制过程将转换为增量复制（差异复制）阶段。 在此阶段中，自上次完成复制周期开始以来发生的数据更改将复制并写入副本托管磁盘。 此过程的这一部分使复制与 VM 上的更改保持同步。

Azure Migrate 使用 VMware CBT 技术跟踪复制周期之间的更改。 在复制周期开始时，Azure Migrate 会创建 VM 快照。 该服务使用 CBT 获取当前快照与上次成功复制的快照之间的更改。 仅复制自上一个完成复制周期以来更改的数据，以便使 VM 的复制保持同步。在每个复制周期结束时，将释放快照，Azure Migrate 会为 VM 执行快照合并。

在复制 VM 上执行迁移作时，按需增量复制周期将复制自上次复制周期以来的剩余更改。 按需周期完成后，Azure Migrate 使用与 VM 对应的副本托管磁盘在 Azure 中创建 VM。

在触发迁移之前，必须关闭本地 VM。 关闭 VM 可防止在迁移过程中丢失数据。

迁移成功且 VM 在 Azure 中重启后，请确保停止复制 VM。 停止复制会删除在数据复制期间创建的中间磁盘（种子磁盘）。 然后，可以避免产生与这些磁盘上的存储事务相关的额外费用。

复制周期

复制周期是将数据从本地环境传输到 Azure 托管磁盘的定期过程。 完整复制周期包含以下步骤：

1. 为每个与 VM 关联的磁盘创建 VMware 快照。

2. 将数据上传到 Azure 中的日志存储帐户。

3. 释放快照。

4. 合并 VMware 磁盘。

合并磁盘后，将完成一个周期。

用于复制的组件

Azure Migrate 设备具有以下负责复制的 本地 组件：

• 数据复制代理
• 网关代理

下表总结了使用 VMware VM 迁移的无代理方法时创建的 Azure 组件。

所需的权限

首次启动复制时，登录用户必须具有以下角色：

• Azure Migrate 项目的资源组和目标资源组的所有者或参与者和用户访问管理员

对于后续复制，登录用户必须具有以下角色：

• Azure Migrate 项目的资源组和目标资源组的所有者或参与者

除了上述角色，登录用户还需要在订阅级别具有以下权限： Microsoft.Resources/subscriptions/resourceGroups/read

数据完整性

每个复制周期都有两个阶段，以帮助确保本地磁盘（源磁盘）与 Azure 中副本磁盘（目标磁盘）之间的数据完整性。

验证复制

第一阶段验证源磁盘中更改的每个扇区是否都复制到目标磁盘。 使用位图执行验证。

源磁盘划分为 512 字节的扇区。 而源磁盘中的每个扇区都会映射到位图中的某个位。 数据复制启动时，Azure Migrate 将为源磁盘中需要复制的所有已更改块（以增量周期为单位）创建位图。 同样，将数据传输到目标 Azure 磁盘时，Azure Migrate 会创建位图。

数据传输成功完成后，云服务会比较这两个位图，以确保它不会错过任何更改的块。 如果位图之间有任何不匹配，则周期被视为失败。 由于每个周期都重新同步，因此在下一个周期中会修复不匹配。

检查复制的数据

第二个阶段可确保传输到 Azure 磁盘的数据与从源磁盘复制的数据相同。

上传的每个已更改块都会经过压缩和加密，然后再将其写入日志存储帐户中的 Blob。 Azure Migrate 在压缩之前计算此块的校验和。 而该校验和会与压缩数据一并存储为元数据。

解压缩后，Azure Migrate 会计算数据的校验和，并将其与源环境中计算的校验和进行比较。 如果存在不匹配的情况，则相关数据不会写入 Azure 磁盘，该周期被视为失败。 由于每个周期都重新同步，因此在下一个周期中会修复不匹配。

安全性

Azure Migrate 设备在上传数据之前对其进行压缩并对其进行加密。 数据通过使用 HTTPS 和 TLS 1.2 或更高版本的安全信道传输。 此外，Azure 存储会在数据保存到云时自动加密（静态加密）。

复制状态

VM 执行复制（数据复制）时，有几种可能的状态：

• 初始复制已排队：VM 排队进行复制或迁移，因为其他 VM 可能会在复制或迁移期间使用本地资源。 资源免费后，将处理此 VM。
• 正在进行初始复制：VM 计划进行初始复制。
• 初始复制：VM 正在进行初始复制。 VM 正在进行初始复制时，无法继续测试迁移和生产迁移。 你只能在此阶段停止复制。
• 初始复制（x%）：初始复制处于活动状态，并按显示的百分比进行。
• 增量同步：VM 可能正在经历增量复制周期，该循环复制自上次复制周期以来的剩余数据变动量。
• 正在进行暂停：VM 正在经历活动增量复制周期并暂停。
• 已暂停：复制周期已暂停。 可以通过执行恢复复制作来恢复复制周期。
• 恢复排队：VM 已排队用于恢复复制，因为其他 VM 当前正在使用本地资源。
• 正在进行的恢复（x%）：正在为 VM 恢复复制周期，并按显示的百分比进行进度。
• 正在停止复制：复制清理正在进行中。 停止复制时，将删除复制期间创建的中间托管磁盘（种子磁盘）。 可以了解有关在 本文后面停止复制的详细信息。
• 正在完成迁移：迁移清理正在进行中。 完成迁移后，将删除复制期间创建的中间托管磁盘（种子磁盘）。 可以在 本文后面部分详细了解如何完成复制。
• - ：成功迁移 VM 或停止复制时，状态将更改为短划线。 完成迁移或停止复制后，作成功完成后，将从复制计算机列表中删除 VM。 可以在复制向导中的虚拟机的选项卡上找到 VM。

其他状态

• 初始复制失败：无法复制 VM 的初始数据。 按照修正指导进行解决。

• 正在修复：复制周期出现问题。 可以选择链接来了解可能的原因和修正操作（如果适用）。 如果在触发 VM 复制时选择“是”来自动修复复制，该工具会尝试为你修复它。 否则，请选择 VM，然后选择“ 修复复制”。

  如果未选择 自动修复复制 ，或者修复步骤不起作用，请停止 VM 的复制。 重置 VM 上的 CBT，然后重新配置复制。

• 修复已排队的复制：VM 已排队进行复制修复，因为其他 VM 正在使用本地资源。 资源免费后，将处理 VM 以修复复制。

• 重新同步 (x%)：VM 正在进行数据重新同步。 如果数据复制过程中出现问题或不匹配，则可能发生这种重新同步。

• 停止复制/完成迁移失败：选择链接，了解失败的可能原因和修正操作（如果适用）。

测试迁移或生产迁移的状态

• 测试迁移挂起：VM 处于增量复制阶段。 现在可以执行测试迁移（或生产迁移）。
• 测试迁移清理挂起：测试迁移完成后，执行测试迁移清理以避免在 Azure 中产生费用。
• 准备好迁移：VM 已准备好迁移到 Azure。
• 正在进行的迁移已排队：VM 已排队进行迁移，因为其他 VM 在复制（或迁移）期间正在消耗本地资源。 资源可用后，将处理 VM。
• 正在进行测试迁移/迁移：VM 正在进行测试迁移或生产迁移。 你可以选择使用链接来检查正在进行的迁移作业。
• 日期、时间戳：测试迁移或生产迁移在此日期和时间发生。
• -：初始复制正在进行中。 在复制过程转换为增量同步（增量复制）阶段后，可以执行测试迁移或生产迁移。

其他状态

• 已完成信息：测试迁移或生产迁移作业已完成信息。 可以选择链接来检查上一个迁移作业，以查找可能的原因和修正操作（如果适用）。
• 失败：测试迁移或生产迁移作业失败。 可以选择链接来检查上一个迁移作业，以查找可能的原因和修正操作。

计划逻辑

为 VM 配置复制时，会计划初始复制。 增量复制（增量复制）遵循它。

增量复制周期的调度安排如下：

• 初始复制周期完成后，会立即计划第一个增量复制周期。

• 根据以下逻辑计划下一个增量复制周期： min[max[1 hour, (<Previous delta replication cycle time>/2)], 12 hours]

  也就是说，下一个增量复制计划不超过 1 小时且不超过 12 小时。 例如，如果 VM 对增量复制周期需要 4 小时，则下一个增量复制周期计划为 2 小时，而不是在下一小时内计划。

  Note

  初始复制完成后，计划逻辑会有所不同。 初始复制完成后，会立即计划第一个增量周期。 后续周期遵循计划逻辑。

• 触发迁移时，VM 在迁移之前会发生按需（故障转移前）增量复制周期。

优先级

下面是 VM 在不同复制阶段的优先级：

• 正在进行的 VM 复制优先于计划复制（新复制）。
• 按需（故障转移前）增量复制周期具有最高优先级，后跟初始复制周期。 增量复制周期的优先级最低。

每当触发迁移作时，就会计划 VM 的按需复制周期。 其他正在进行的复制必须等待它们是否争用资源。

约束

以下约束有助于确保不超过存储区域网络上的 IOPS 限制：

• 每个 Azure Migrate 设备支持并行复制 52 个磁盘。
• 所有 ESXi 主机都支持 8 个磁盘。 所有 ESXi 主机都设有 32 MB NFC 缓冲区。 因此，可以在主机上计划 8 个磁盘。 （每个磁盘占用 4 MB 的缓冲区，用于事件响应和灾难恢复。
• 每个数据存储最多可包含 15 个磁盘快照。 唯一的例外是将超过 15 个磁盘附加到 VM。

横向扩展复制

Azure Migrate 支持 500 个 VM 的并发复制。 计划复制 300 多个 VM 时，必须部署横向扩展设备。 横向扩展设备类似于 Azure Migrate 主设备，但仅包含网关代理，以方便数据传输到 Azure。

下图显示了横向扩展设备的建议使用方法。

配置主设备后，可以随时部署横向扩展设备，但在同时复制 300 个 VM 之前不需要它。 当 300 个 VM 同时复制时，必须部署横向扩展设备才能继续。

停止复制或完成迁移

停止复制时，将删除复制期间创建的中间托管磁盘（种子磁盘）。 只能在活动复制期间停止复制。 可以选择 “完成迁移 ”以在迁移 VM 后停止复制。

可以通过再次启用复制来复制停止复制的 VM。 如果 VM 已迁移，可以重新恢复复制和迁移。

最佳做法是，VM 成功迁移到 Azure 后，应始终完成迁移。 这种做法可确保在中间托管磁盘（种子磁盘）上存储事务不会产生额外的费用。

在某些情况下，停止复制需要一些时间。 原因是，每当停止复制时，正在进行的复制周期就会完成（仅在 VM 处于增量同步状态）之后才会删除项目。

流失影响

通过在计划下一个周期之前，允许数据尽可能多地折叠，可以最大程度地减少每个复制周期中的数据传输量。 由于无代理复制对半缩减数据，因此流失模式比流失率更重要 。 反复写入文件时，流失率不会造成很大的影响。 但是，每隔一个扇区写入的模式会导致下一个周期的流失变高。

如果当前增量复制周期因数据变动率高而出现延迟，则后续周期的启动可能会延迟。 为特定磁盘复制的数据量会延长创建恢复点所需的持续时间。 因此，最终迁移周期需要更长的时间。 这种情况会导致源 VM 的扩展关闭窗口。

如果快照大小增加（由于改动模式）到跨越数据存储可用容量的某个范围，则数据存储会耗尽空间的风险。 这种情况可能会对生产工作负荷产生不利影响，并且可能会使源 VM 无响应。

若要缓解此风险，建议主动增加数据存储大小。 如果要同时复制的多个 VM 在具有低可用容量的数据存储中具有磁盘，建议一次执行一个 VM 迁移以避免资源争用。

复制管理

Throttling

可以通过使用 NetQosPolicy来增加或减少复制带宽。 AppNamePrefix要使用的NetQosPolicyGatewayWindowsService.exe值为 .

若要限制来自 Azure Migrate 设备的复制流量，可以在设备上创建类似于以下示例的策略。 此策略适用于同时从 Azure Migrate 设备复制的所有 VM。

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

还可以使用 示例脚本根据计划增加和减少复制带宽。

“停电”窗口

Azure Migrate 提供了一种基于配置的机制，可用于指定不希望任何复制继续的时间间隔。 此间隔称为 “停电”窗口。 在多种情况下（例如，当源环境受到资源约束时或希望复制仅在工作时间外进行时），可能会出现对停电窗口的需求。

可以通过创建或更新 GatewayDataWorker.json 文件中 C:\ProgramData\Microsoft Azure\Config来指定设备的停电窗口。 典型的文件采用以下形式：

{

    "BlackoutWindows": "List of blackout windows"

}

停电窗口列表是格式<DayOfWeek>;<StartTime>;<Duration>的以管道分隔的 （|） 字符串。 可以指定天数、小时和分钟数的持续时间。 例如，可以将停电窗口指定为：

{

    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"

}

前面的示例中的第一个值指示一个停电窗口，该窗口每周一上午 7：00（设备的时间）开始，并且持续 7 小时。

使用这些内容创建或更新 GatewayDataWorker.json 后，需要在设备上重启网关服务，以便这些更改生效。

在横向扩展方案中，主设备和横向扩展设备将独立遵循中断窗口。 我们建议的最佳做法是，跨设备保持窗口的一致性。

相关内容

• 将 VMware VM 迁移到 Azure（无代理）