本文介绍如何在 Azure Site Recovery 中将本地计算机故障转移到 Azure。
在您开始之前
在故障转移后准备连接
确保能够连接到故障转移后创建的 Azure VM,首先,需要在故障转移之前在本地执行一些步骤。
准备现场环境以在故障转移后进行连接
在故障转移后,如果想要使用 RDP/SSH 连接到 Azure 虚拟机,则需要在故障转移前在本地完成一些必要的准备工作。
故障转移后 | 位置 | 行动 |
---|---|---|
运行 Windows 的 Azure VM | 故障转移之前的本地计算机 | 若要通过 Internet 访问 Azure VM,请启用 RDP,并确保已针对“公共” 添加 TCP 和 UDP 规则,并在“Windows 防火墙” “允许的应用” 中针对所有配置文件允许 RDP。 若要通过站点到站点连接访问 Azure VM,请在计算机上启用 RDP,并确保在“Windows 防火墙”-“允许的应用和功能”中针对“域和专用”网络允许 RDP。 删除任何静态永久性路由和 WinHTTP 代理。 确保操作系统 SAN 策略已设置为 OnlineAll。 了解详细信息。 在触发故障转移时,请确保 VM 上没有处于挂起状态的 Windows 更新。 Windows 更新可能会在故障转移时启动,在更新完成之前,无法登录到 VM。 |
运行 Linux 的 Azure VM | 故障转移之前的本地计算机 | 确保 VM 上的安全外壳服务已设置为在系统引导时自动启动。 确保防火墙规则允许 SSH 连接。 |
运行故障转移
此过程介绍如何为 恢复计划运行故障转移。 若要为单个 VM 运行故障转移,请按照 VMware VM、物理服务器或 Hyper-V VM 的说明进行操作。
运行恢复计划的故障切换,操作如下所示:
在 Site Recovery 保管库中,选择恢复计划>recoveryplan_name。
单击 “故障转移” 。
在 故障转移>故障转移方向中,如果要复制到 Azure,请保留默认值。
在 故障转移中,选择要故障转移到的 恢复点 。
- 最新:使用最新点。 这会处理发送到 Site Recovery 服务的所有数据,并为每台计算机创建恢复点。 此选项提供最低的 RPO(恢复点目标),因为故障转移后创建的 VM 包含触发故障转移时复制到 Site Recovery 的所有数据。 请注意,当源区域出现故障时,无法再进行日志处理。 因此,您必须切换到最近处理的恢复点。 请参阅下一点以了解详细信息。
- 最新处理:使用此选项将 VM 故障转移到 Site Recovery 已处理的最新恢复点。 可以在 VM 最新恢复点中看到最新处理的恢复点。 此选项提供较低的 RTO,因为无需花费时间来处理未处理的数据
- 最新的应用一致性:使用此选项可将 VM 故障转移到 Site Recovery 处理的最新应用程序一致性恢复点。
- 最新处理的多虚拟机:使用此选项作为复制组一部分的虚拟机故障转移到最新的多虚拟机共同一致恢复点。 其他虚拟机故障转移到其最新处理的恢复点。 此选项仅适用于至少有一个虚拟机启用了多虚拟机一致性的恢复计划。
- 最新的多 VM 应用一致:使用此选项,属于复制组的 VM 将切换到最新的通用多 VM 应用程序一致性恢复点。 其他虚拟机故障转移到其最新的应用程序一致性恢复点。 仅适用于包含至少一个启用了多虚拟机一致性的 VM 的恢复计划。
- 自定义:不适用于恢复计划。 此选项仅适用于单个虚拟机的故障转移。
如果希望 Site Recovery 在启动故障转移之前关闭源 VM,请在开始 故障转移之前 选择“关闭计算机”。 即使关机失败,故障转移也仍会继续。
注释
如果故障转移 Hyper-V 虚拟机 (VM),关闭过程会在触发故障转移之前尝试同步并复制尚未发送到服务的本地数据。
在作业页上跟踪故障转移进度。 即使发生错误,恢复计划也会运行,直到它完成。
故障转移后,登录 VM 以验证其正常运行。
如果要切换到用于故障转移的不同恢复点,请使用 更改恢复点。
准备就绪后,可以提交此故障转移。“提交”操作将删除服务中所有可用的恢复点。 “更改恢复点”选项将不再可用。
运行计划内故障转移(Hyper-V)
可以为 Hyper-V VM 执行预先计划的故障转移。
- 计划的故障转移是零数据丢失故障转移选项。
- 触发计划的故障转移时,首先关闭源虚拟机,同步最新数据,然后触发故障转移。
- 使用 计划内故障转移选项运行计划内故障转移 。 它以类似于常规故障转移的方式运行。
跟踪故障转移
有许多与故障转移关联的作业。
- 先决条件检查:确保满足故障转移所需的所有条件。
- 故障转移:处理数据,以便可以从其中创建 Azure VM。 如果选择了 最新 恢复点,则会从发送到服务的数据创建恢复点。
- 开始:使用上一步中处理的数据创建 Azure VM。
警告
请勿取消正在进行的故障转移:在故障转移启动之前,VM 的复制已停止。 如果取消正在进行的作业,故障转移将停止,但虚拟机不会开始进行复制。 无法再次启动复制。
额外的故障转移时间
在某些情况下,VM 故障转移需要中间步骤,通常需要大约 8 到 10 分钟才能完成。 以下是受此额外步骤/时间影响的计算机:
- 运行低于 9.8 的移动服务版本的 VMware 虚拟机。
- 物理服务器,以及按照物理服务器进行保护的 Hyper-V 虚拟机。
- VMware Linux VM。
- 缺少这些启动驱动程序的 VMware 虚拟机:
- storvsc
- vmbus
- storflt
- intelide
- atapi
- 未启用 DHCP 的 VMware VM,无论它们使用的是 DHCP 还是静态 IP 地址。
在故障转移过程中自动执行操作
你可能希望在故障转移过程中自动执行操作。 为此,可以在恢复计划中使用脚本或 Azure 自动化 runbook。
- 了解如何创建和自定义恢复计划,包括添加脚本。
故障转移后配置设置
故障转移后保留驱动器号
Site Recovery 处理驱动器盘符的保留。 如果在 VM 复制期间排除磁盘,请查看说明其工作方式的示例。
故障转移后在 Azure 中准备连接
如果要使用 RDP 或 SSH 连接到故障转移后创建的 Azure VM,请遵循表中汇总的要求。
故障转移 | 位置 | 行动 |
---|---|---|
运行 Windows 的 Azure VM | 故障转移之后在 Azure VM 上 | 为 VM 添加公共 IP 地址。 已故障转移的 VM(及其连接到的 Azure 子网)上的网络安全组规则需要允许与 RDP 端口建立传入连接。 选中“启动诊断”可查看 VM 的屏幕截图 。 如果无法连接,请检查 VM 是否正在运行,并查看这些故障排除提示。 |
运行 Linux 的 Azure VM | 故障转移之后在 Azure VM 上 | 已故障转移的 VM(及其连接到的 Azure 子网)上的网络安全组规则需要允许与 SSH 端口建立传入连接。 为 VM 添加公共 IP 地址。 选中“启动诊断”可查看 VM 的屏幕截图 。 |
请按照此处所述的步骤对故障转移后的任何连接问题进行故障排除。
设置 IP 寻址
-
内部 IP 地址:若要在故障转移后设置 Azure VM 的内部 IP 地址,有以下几个选项:
- 保留相同的 IP 地址:可以在 Azure VM 上使用与分配给本地计算机的 IP 地址相同的 IP 地址。
- 使用不同的 IP 地址:可以为 Azure VM 使用不同的 IP 地址。
- 详细了解 如何设置内部 IP 地址。
- 外部 IP 地址:可以在故障转移时保留公共 IP 地址。 在故障转移过程中创建的 Azure VM 必须被分配一个在 Azure 区域内可用的 Azure 公共 IP 地址。 可以通过手动分配公共 IP 地址,也可以通过恢复计划自动执行该过程。 了解详细信息。
后续步骤
进行故障转移后,需要重新进行保护才能开始将 Azure 虚拟机重新复制回本地站点。 复制启动并运行后,可以在准备就绪时故障切回到本地环境。