无代理迁移体系结构

本文介绍在 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 小时后，而不是下一个小时。

  注意

  初始复制完成后，调度逻辑将有所变化。 初始复制完成后，会立即安排第一个增量周期。 后续周期遵循调度逻辑。

• 触发迁移时，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 迁移以避免资源争用。

复制管理

限制

可以通过使用 NetQosPolicy 来增加或减少复制带宽。 要在 AppNamePrefix 中使用的 NetQosPolicy 值为 GatewayWindowsService.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（无代理）