从经典 VMware 灾难恢复迁移到新式 VMware 灾难恢复
本文介绍体系结构、必要的基础结构和有关如何将 VMware 或物理计算机复制从经典迁移到新式保护体系结构的常见问题解答。 使用此功能可迁移，可以将复制的项从配置服务器成功传输到 Azure Site Recovery 复制设备。 此迁移由智能复制机制进行指导，可确保不会针对非关键复制项再次执行完整的初始复制，仅传输差异数据。
注意
恢复计划不会迁移，需要在新式恢复服务保管库中再次创建。
体系结构
下表汇总了迁移 VMware 或物理计算机复制项所涉及的组件：
| 组件 | 要求 |
|---|---|
| 经典恢复服务保管库中的复制项 | 使用经典体系结构和正常配置服务器保护的一个或多个复制项。 复制项应处于非关键状态，并且必须使用在版本 9.50 或更高版本上运行的移动代理从本地复制到 Azure。 |
| 复制项使用的配置服务器 | 复制项使用的配置服务器应处于非关键状态，其组件应升级到最新版本（9.50 或更高版本）。 |
| 可提供现代化体验的恢复服务保管库 | 可提供现代化体验的恢复服务保管库。 |
| 正常的 Azure Site Recovery 复制设备 | 非关键 Azure Site Recovery 复制设备，可发现本地计算机，其所有组件均已升级到最新版本（9.50 或更高版本）。 确切的所需版本如下所示： 进程服务器：9.50 代理服务器：1.35.8419.34591 恢复服务代理：2.0.9249.0 复制服务：1.35.8433.24227 |
要求的基础设施
确保下述各项能成功移动复制项：
- 使用现代化体验的恢复服务保管库。
注意
默认情况下，所创建的任何新恢复服务保管库都将启动现代化体验。 无法切换到经典体验，因为已宣布弃用经典体验。
- 已成功注册到保管库的 Azure Site Recovery 复制设备及其所有组件都处于非关键状态。
- 设备的版本必须为 9.50 或更高版本。 有关详细的版本说明，请单击此处查看。
- vCenter 服务器或 vSphere 主机的详细信息（现有复制计算机所在位置）将添加到设备中用于确保成功实现本地发现。
先决条件
准备基础结构
在从经典体系结构迁移到现代化体系结构之前，确保执行下列操作：
- 创建恢复服务保管库并确保体验未切换到经典
- 部署 Azure Site Recovery 复制设备。
- 将本地计算机的 vCenter Server 详细信息添加到设备中，确保其成功执行发现。
准备经典恢复服务保管库
对于计划迁移的复制项，确保满足以下条件：
- 复制项是通过配置服务器进行复制的 VMware 或物理计算机。
- 复制不会对非托管存储帐户进行，而是对托管磁盘进行。
- 复制是从本地到 Azure，并且复制项未处于已故障转移或已故障回复状态。
- 复制项不会将数据从 Azure 复制到本地。
- 初始复制未在进行中，已完成。
- 复制项未处于“重新同步”状态。
- 配置服务器的版本为 9.50 或更高版本，其健康状况处于非关键状态。
- 配置服务器的检测信号正常。
- 在源计算机上安装的移动服务代理版本为 9.50 或更高版本。
- 支持启用了 MSI 的恢复服务保管库。
- 支持启用了专用终结点的恢复服务保管库。
- 复制项的运行状况处于非关键状态，或成功创建了其恢复点。
准备新式恢复服务保管库
对于现代化体系结构设置，请确保：
- 用于现代化体系结构设置的恢复服务保管库与经典保管库处于同一地理位置。
- Azure Site Recovery 复制设备部署在本地，版本为 9.50 或更高版本。
- 设备已成功注册到保管库。
- 设备及其所有组件都处于非关键状态，并且设备具有正常检测信号。
- 现代化体系结构支持 vCenter Server 版本。
- 源计算机的 vCenter Server 详细信息会添加到设备中。
- 现代化体系结构支持 Linux distro 版本。 了解详细信息。
- 现代化体系结构支持 Windows 服务器版本。 了解详细信息。
计算总移动时间
将任何复制项从经典保管库迁移到新式保管库所需的总时间取决于项目的复制状态和磁盘大小。
| 状态 | 迁移到新式保管库需要的时间 |
|---|---|
| 复制项的保护状态正常，最后一个恢复点在 50 分钟前创建 | 迁移将在 1-2 小时内完成 |
| 复制项的保护状态不正常，或最后一个恢复点在 50 分钟前创建 | 迁移时间会发生变化，具体取决于磁盘大小 |
如果计算机保护状态不正常，请使用以下公式计算计算机的确切时间：
迁移时间 = 1 小时 + 45 秒/GiB
| 计算机配置 | 迁移时间 |
|---|---|
| 1 台具有 2 个磁盘（大小都为 256 GiB）的计算机 | 大约 4 小时 15 分钟 [两个磁盘都是并行迁移的] |
| 10 台各自具有 2 个磁盘（大小都为 256 GiB）的计算机 | 大约 4 小时 15 分钟 [所有 VM 及其磁盘都是并行迁移的] |
| 1 台具有 4 个磁盘（大小都为 512 GiB）的计算机 | 大约 7 小时 30 分钟 [两个磁盘都是并行迁移的] |
| 10 台各自具有 4 个磁盘（大小都为 512 GiB）的计算机 | 大约 7 小时 30 分钟 [所有 VM 及其磁盘都是并行迁移的] |
相同的公式用于计算迁移时间，会显示在门户中。
如何定义所需的基础结构
将计算机从经典体系结构迁移到新式体系结构时，需要确保已在新式恢复服务保管库中注册所需基础结构。 请参阅复制设备的大小调整和容量详情，定义所需的基础结构。
通常，应将经典恢复服务保管库中的进程服务器数量设置为与复制设备数量相同。 在经典保管库中，如果有一个配置服务器和四个进程服务器，应在新式恢复服务保管库中设置四个复制设备。
定价
经典保管库将继续收取 Site Recovery 许可证费用，直到所有恢复点的保持期过期。 所有恢复点都清除后，经典保管库上的定价也会停止。 所有恢复点的保持期到期后，将通过系统触发的清除复制操作自动移除复制项。
Site Recovery 仅在生成第一个恢复点并清理旧保管库后，才会对新式保管库中的复制项收取许可证费用。 如果经典保管库出现任何试用使用天数，则会将相同的信息传递给新式保管库。 只有在此试用期过后，定价才会在新式保管库上启用。
注意
在某个时间点，只需使用一个保管库（经典保管库或新式保管库）进行定价。
常见问题解答
为何应将计算机迁移到现代化体系结构中？
请务必注意，用于灾难恢复的经典体系结构将被逐步淘汰，因此用户应确保切换到最新的新式版本。 下表提供了这两种体系结构的比较，以帮助你选择在发生灾难时保护计算机的正确选项。
| 经典体系结构 | 现代化体系结构[新增] |
|---|---|
| 发现本地数据需要使用的多个设置。 | 使用发现服务集中发现本地数据中心。 |
| 初始载入需遵循的大量步骤。 | 通过创建自动化项目并引入默认值来简化载入体验，以减少所需的输入内容。 |
| 利用手动下载的文件获取云上下文。 | 在设置设备时获取云上下文引入的复制密钥。 |
| 简单启用复制过程需遵循的大量步骤。 | 通过减少所需的输入内容并重新定义每个边栏选项卡来简化启用复制体验。 |
| 配置服务器仍然是一个本地基础结构，其中包含各种组件的多项设置。 | 将所有组件转换为 Azure 托管微服务可实现设备增强。 这简化了设备的缩放、监视和故障排除流程。 |
| 为 Linux 计算机在 Azure 中提供横向扩展进程服务器和主目标服务器是一个阻碍需求。 | 删除维护独立进程服务器和主目标服务器的需要。 |
| 使用静态密码进行身份验证，这干扰了客户的定期密码轮换业务需求。 | 引入基于证书的身份验证，更安全，消除了客户的安全顾虑。 |
| 应手动升级到更新版本，这个过程比较繁琐。 | 为设备组件和出行服务引入自动升级。 |
| 配置服务器没有高可用性，可能面临崩溃的风险。 | 实现设备的高可用性 ，可确保复原能力。 |
| 应定期更新根凭据，以免升级时出现错误。 | 消除维持计算机执行自动升级的根凭据的需求。 |
| 应将静态 IP 地址分配给配置服务器以维持连接。 | 引入基于 FQDN 的设备与本地计算机之间的连接。 |
| 仅应使用启用了站点到站点 VPN 或快速路由的虚拟网络。 | 删除维护站点到站点 VPN 或快速路由进行反向复制的需求。 |
| 还需要设置第三方工具 MySQL。 | 删除了对任何第三方工具的依赖项。 |
应将哪些计算机迁移到现代化体系结构中？
使用配置服务器复制的所有 VMware 或物理机都应迁移到新式体系结构。
新式恢复服务保管库应在哪里创建？
新式恢复服务保管库应与经典保管库处于相同区域和租户中。 它可以是任何订阅或资源组的一部分。
迁移发生时，是否还会继续复制？
不会，迁移进行时，复制将中断一段时间。 在此期间，可将故障转移到经典恢复服务保管库中最后一个创建的恢复点。 迁移完成后，将在新式恢复服务保管库中生成新的恢复点。
迁移操作何时标记为完成？
只有在成功在新式恢复服务保管库中创建第一个恢复点后，迁移操作才会标记为完成。
迁移完成后，可以在经典恢复服务保管库执行哪些操作？
迁移后，只能从经典保管库执行故障转移。 故障转移操作将继续在经典保管库中可用，直到恢复点过期为止。
例如，如果复制项的保留期为 72 小时（三天），则成功迁移后，经典保管库上的最新恢复点会继续在 72 小时（三天）内保持可用。 规定的时间过后，Azure Site Recovery 将对复制项自动触发清除复制操作，并清理所有关联的存储和计费项。
如果我的计算机在迁移时出现灾难性故障，会怎样？
在最终恢复点的保持期结束之前，任何正在进行迁移的复制项仍可通过经典恢复服务保管库支持故障转移操作。 如果尝试执行故障转移操作，那么它将优先于迁移操作，并且迁移作业被中止。 若要确保复制项已迁移，需要稍后再次触发迁移操作。
注意
迁移正在进行时，可以更新复制项的计算和网络属性。 但是，这些更改可能不会复制到新式恢复服务保管库。
一次性可以从经典保管库迁移到新式保管库多少台计算机？
通过门户一次性最多可迁移 10 台计算机。
是否应重新创建要在新保管库中使用的虚拟网络、存储帐户和复制策略？
不需要，以前使用的资源会默认出现在新式保管库中。 始终可以从复制项的“计算”和“网络”边栏选项卡更改这些资源。 必须确保资源继续享有所需的访问权限。
如何将复制策略移动到新式保管库？
作为先决条件，Site Recovery 将使用与经典保管库中相同的配置在新式保管库中创建复制策略。 因此，在移动复制项之前，将在新式保管库中创建关联的策略。 建议避免在触发迁移后更改经典保管库中复制策略的配置，因为这些更改不会反映在新式保管库中。 最好在开始迁移过程之前进行这些更改。
在现代化保管库中创建的复制策略将在新式保管库中更改名称。 它会使用新式恢复服务保管库的资源组名称和保管库名称作为前缀。 因此，如果策略名称在经典保管库中为“default replication policy”，则在新式保管库中，此策略的名称为 default replication policy contoso-modern-vault_contoso-rg，因为保管库的名称是 contoso-modern-vault，保管库的资源组是 contoso-rg。
是否可以在迁移过程中或迁移后在经典保管库中编辑复制策略？
如果复制策略的副本已在新式保管库中创建，则经典保管库中的策略的任何更改都不会传播到新式保管库。
因此，如果有 10 个使用策略进行复制的复制项，并且你决定将其中 5 个项迁移到新式体验，则在迁移开始之前会创建策略的副本。 现在，迁移其余 5 项之前，如对经典保管库中的策略进行了任何更改，则不会更新新式保管库中的策略。 还需要在新式保管库中对这些配置进行更改。
如何迁移复制组（也称为多 VM 一致组）中的复制项？
复制组中的所有复制项将一起迁移。 可以通过选择复制组来全选或全部跳过。 如果复制组中某些计算机的迁移过程失败但其他计算机成功，则会针对失败的复制项执行回滚到经典体验的操作，并且可以针对这些项再次触发迁移过程。