无代理迁移体系结构

本文介绍使用 Azure Migrate：服务器迁移工具的无代理迁移方法迁移 VMware VM 时的复制概念。

复制过程

无代理复制方案的工作原理是使用 VMware 快照以及 VMware 已更改块跟踪 (CBT) 技术从虚拟机磁盘复制数据。 以下方块图显示了使用 Azure Migrate：服务器迁移工具迁移虚拟机时涉及的各种步骤。

为虚拟机配置复制后，首先会经历初始复制阶段。 在初始复制过程中，系统会创建 VM 快照，并将快照磁盘中的完整数据副本复制到目标订阅的托管磁盘。

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

VMware 采用已更改块跟踪 (CBT) 技术来跟踪复制周期之间发生的更改。 复制周期开始时，将创建一个 VM 快照，并使用已更改块跟踪来获取当前快照与上次成功复制的快照之间的变化。 只复制自上一个完整复制周期以来更改的数据，以使 VM 复制保持同步。每个复制周期结束时，系统将发布快照，并在虚拟机上执行快照整合。

在复制虚拟机上执行迁移操作时，会出现按需差异复制周期，即复制自上次复制周期结束后剩余的更改。 按需周期结束后，使用与虚拟机对应的副本托管磁盘在 Azure 中创建虚拟机。 在触发迁移/故障转移之前，必须关闭本地虚拟机。 关闭虚拟机可确保不会在迁移过程中丢失任何数据。

一旦迁移成功，并且 VM 在 Azure 中启动，请务必停止 VM 复制。 停止复制将会删除在数据复制过程中创建的中间磁盘（种子磁盘），还将避免因这些磁盘上的存储事务而产生额外费用。

复制周期

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

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

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

3. 发布快照

4. 整合 VMware 磁盘

完成磁盘整合后，即可视为一个周期已结束。

复制涉及的组件

本地组件：Azure Migrate 设备包含以下负责执行复制的组件

• DRA 代理
• 网关代理

Azure 组件：下表汇总了使用 VMware VM 无代理迁移方法时创建的各种 Azure Artifacts。

所需的权限

首次开始复制时，必须为已登录用户分配下列角色：

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

在后续复制的过程中，必须为已登录用户分配下列角色：

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

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

数据完整性

每个复制周期包含两个阶段，可确保本地磁盘（源磁盘）和 Azure 中的副本磁盘（目标磁盘）之间的数据完整性。

1. 首先，我们要验证是否已成功将源磁盘中发生更改的每个扇区复制到目标磁盘。 验证时要使用位图。

源磁盘会被划分为 512 字节的扇区， 而源磁盘中的每个扇区都会映射到位图中的某个位。 数据复制开始时，系统将会为需要执行复制的源磁盘中的所有已更改块创建位图（遵循增量周期）。 在将数据传输到目标 Azure 磁盘时，系统同样也会创建位图。 数据传输成功完成后，云服务会比较两个位图，以确保没有丢失任何已更改的块。 如果位图之间存在任何不匹配的情况，则该次周期可视为失败。 由于每个周期都会重新进行同步，因此该等不匹配将会在下一个周期得到修复。

1. 接下来，我们要确保传输到 Azure 磁盘的数据与从源磁盘复制的数据相同。 上传的每一个已更改块都会先经过压缩和加密处理，然后再作为 blob 写入日志存储帐户。 我们会在压缩前计算此块的校验和。 而该校验和会与压缩数据一并存储为元数据。 系统会在解压缩时计算数据校验和，再将其与源环境计算的校验和进行比较。 如果存在不匹配的情况，则相关数据不会写入 Azure 磁盘，该周期被视为失败。 由于每个周期都会重新进行同步，因此该等不匹配将会在下一个周期得到修复。

安全

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

复制状态

当 VM 进行复制（数据复制）时，有以下几种可能的状态：

• 初始复制已排队：VM 已排队进行复制（或迁移），因为可能有其他 VM 使用本地资源（在复制或迁移期间）。 有可用资源后，即会处理此 VM。
• 正在进行初始复制：VM 正在计划初始复制。
• 初始复制：VM 正在进行初始复制。 当 VM 正在进行初始复制时，测试迁移及迁移都将无法继续进行。 你只能在此阶段停止复制。
• 初始复制 (x%)：初始复制处于活动状态，并且进度为 x%。
• 增量同步：VM 可能正在经历增量复制周期，该循环复制自上次复制周期以来的剩余数据变动量。
• 正在暂停：VM 正在经历活动的增量复制周期，并将暂停一段时间。
• 已暂停：复制周期已暂停。 通过执行恢复复制操作可以恢复复制周期。
• 恢复已排队：由于目前有其他 VM 正在使用本地资源，因此 VM 排队等待恢复复制。
• 正在恢复 (x%)：VM 的复制周期正在恢复，并且进度为 x%。
• 正在停止复制：复制清理正在进行中。 停止复制时，复制期间创建的中间托管磁盘（种子磁盘）即会删除。 了解详细信息。
• 正在完成迁移：迁移清理正在进行中。 完成迁移时，复制期间创建的中间托管磁盘（种子磁盘）将会删除。 了解详细信息。
• - ：VM 已成功迁移和/或停止复制时，状态将更改为“-”。 一旦停止复制/完成迁移且该操作成功完成后，VM 即会从复制计算机的列表中删除。 你可以在“复制”向导的“VM”选项卡中找到该 VM。

其他状态

• 初始复制失败：无法复制 VM 的初始数据。 按照修正指导进行解决。
• 修复挂起：复制周期中存在问题。 可以选择链接来了解可能的原因和修正操作（如果适用）。 如果你在触发了 VM 复制时通过选择“是”启用了“自动修复复制”，则该工具将尝试修复复制。 否则，选择该 VM 并选择“修复复制”。 如果未启用“自动修复复制”或者上述步骤不起作用，请停止虚拟机复制，在虚拟机上重置已更改的块跟踪，然后重新配置复制。
• 修复复制已排队：由于有其他 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 小时，则安排下一个增量周期的时间将在两小时后，而不是下一个小时。

• 触发迁移后，系统将在迁移前，先对 VM 执行按需增量复制周期（预先进行增量复制周期故障转移）。

VM 在复制的各个阶段的优先级

• 先处理正在进行的 VM 复制，再处理已安排的复制（新复制）
• 一律最先执行预故障转移（按需增量复制）周期，随后是初始复制周期， 最后执行增量复制周期。

也就是说，每当触发迁移操作时，即会安排 VM 执行按需复制周期，而此时正在进行的其他复制也不得与之争用资源。

约束：

我们使用以下约束来确保遵守 SAN 上的 IOPS 限制。

• 所有 Azure Migrate 设备都支持并行复制 52 个磁盘
• 所有 ESXi 主机都支持 8 个磁盘。 所有 ESXi 主机都设有 32 MB NFC 缓冲区。 这样一来，我们便可在主机上调度 8 个磁盘（每个磁盘占用 4 MB IR/DR 缓冲区）。
• 每个数据存储最多可包含 15 个磁盘快照。 唯一的例外情况是，VM 上附加的磁盘数超过 15 个。

横向扩展复制

Azure Migrate 支持并发复制 500 台虚拟机。 如果你计划复制超过 300 台虚拟机，则必须部署横向扩展设备。 横向扩展设备类似于 Azure Migrate 的主设备，但只包含便于将数据传输到 Azure 的网关代理。 下图显示了横向扩展设备的建议使用方法。

在配置主设备（但并非必需）直到能够并发复制 300 台 VM 时，你即可随时部署横向扩展设备。 不过，若要并发复制 300 台 VM，则必须先部署横向扩展设备方可继续。

停止复制/完成迁移

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

VM 若已停止复制，可以通过重新启用复制进行复制。 如果 VM 已迁移，可以重新恢复复制和迁移。

最佳做法是，应当始终在已将 VM 成功迁移到 Azure 后再完成迁移，以确保不会因中间托管磁盘（种子磁盘）上的存储事务而产生额外费用。 在某些情况下，你会注意到停止复制需要一定时间。 这是因为，无论何时停止复制，当前进行的复制周期都要在删除相关项目之前完成（仅当 VM 处于增量同步进程时）。

流失影响

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

复制管理

限制

你可以使用 NetQosPolicy 来增加或减少复制带宽。要在 NetQosPolicy 中使用的 AppNamePrefix 是“GatewayWindowsService.exe”。

可按如下所示在 Azure Migrate 设备上创建一个策略，以限制来自设备的复制流量：

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

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

中断窗口

Azure Migrate 提供一种基于配置的机制，客户可以通过该机制指定中止任何复制的时间间隔。 此时间间隔即称为“中断窗口”。 许多方案都需要中断窗口，例如源环境受资源限制，或者客户希望只在非营业时间进行复制等情况。

通过在 C:\ProgramData\Microsoft Azure\Config 中创建/更新 GatewayDataWorker.json 文件，即可为设备指定中断窗口。典型文件格式如下所示：

{

    "BlackoutWindows": "List of blackout windows"

}

中断窗口的列表是一个以“|”分隔的字符串，格式为“星期；开始时间；持续时间”。 可以按天、小时和分钟指定持续时间。 例如，可将中断窗口指定为：

{

    "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 虚拟机。