本文介绍了在不同区域之间复制和恢复 Azure 虚拟机 (VM) 时在 Azure Site Recovery 中经常出现的问题。 另外还介绍了如何排查常见问题。 有关支持的配置的详细信息,请参阅 support matrix for replicating Azure VMs(复制 Azure VM 的支持矩阵)。
Azure Site Recovery 以一致的方式将数据从源区域复制到灾难恢复区域。 它还每隔 5 分钟创建崩溃一致性恢复点。 如果 Site Recovery 在 60 分钟内无法创建恢复点,它会通过以下信息向你发出警报:
Error message: "No crash consistent recovery point available for the VM in the last 60 minutes."
Error ID: 153007
以下部分介绍原因和解决方案。
如果源虚拟机上的数据更改率超过支持的限制,Azure Site Recovery 将创建一个事件。 若要确定问题是否由高变动率造成,请转到“复制的项”>“VM”>“事件 - 过去 72 小时”。 你应当会看到“数据更改率超过支持的限制”事件:
如果选择该事件,应会看到确切的磁盘信息:
下表提供了 Azure Site Recovery 限制。 这些限制基于我们的测试,但无法涵盖所有可能的应用程序输入-输出 (I/O) 组合。 实际结果可能因应用程序 I/O 组合而异。
有两个限制需要考虑:每个磁盘的数据变动率,以及每个虚拟机的数据变动率。 查看此处的变动率限制。
Azure Site Recovery 根据磁盘类型实施数据更改率限制。 若要确定此问题是重复性的还是暂时性的,请确定受影响虚拟机的数据更改率。 请转到源虚拟机,在“监视”下找到指标,然后添加以下屏幕截图所示的指标:
- 选择“添加指标”,并添加“OS 磁盘写入字节数/秒”和“数据磁盘写入字节数/秒”。
- 监视屏幕截图中所示的峰值。
- 查看 OS 磁盘和所有数据磁盘中总共发生的写入操作次数。 这些指标可能无法提供磁盘级别的信息,但能够反映数据变动率总模式。
数据更改率出现高峰的原因可能是偶发性的数据突发。 如果数据更改率高于 10 MB/秒(针对高级存储)或 2 M/秒(针对标准存储),但随后又下降,则复制可以赶上进度。 如果变动率一直远远超过支持的限制,请考虑以下做法之一:
排除导致数据更改率变高的磁盘:首先禁用复制。 然后可以使用 PowerShell 来排除磁盘。
更改副本磁盘的磁盘大小。 只有当每个磁盘的磁盘数据变动率小于 20 MB/秒,或在高变动率的情况下每个磁盘小于 50 MB/秒时,此选项才有用。 例如,假设你没有选择高变动支持,并且有一个 VM 带有 128 GiB 的磁盘,数据变动率在 8 MB/秒和 10 MB/s秒之间。 现在,由于 128 GiB 磁盘大小的变动率限制为 8 MB/秒,因此你可将磁盘大小增加到 512 GiB 来支持更高的变动率。 此解决方法仅适用于使用高级托管磁盘的计算机。 执行以下步骤:
- 转到受影响的已复制计算机的“磁盘”,并复制副本磁盘名称。
- 转到托管磁盘的此副本。
- 可能会在“概述”中看到一个横幅,指出已生成 SAS URL。 请选择此横幅并取消导出。 如果看不到该横幅,请忽略此步骤。
- 撤销 SAS URL 后,立即转到托管磁盘的“大小 +性能”。 增大大小,使 Site Recovery 支持在源磁盘上观测到的变动率。
重要
Azure Site Recovery 支持的变动率限制取决于副本高级 SSD 磁盘的磁盘大小。 即使更改副本磁盘的性能层,此限制也保持不变。 例如,如果创建了磁盘大小为 128 GiB 的高级 SSD 副本磁盘,则其基本性能层为 P10。 如果在不更改磁盘大小的情况下将其性能层更新为 P50,则变动率限制保持不变。
每当更改磁盘层或 SKU 时,磁盘资源提供程序都会创建与磁盘对应的所有快照(书签)。 因此,可能在某些恢复点中,一些底层快照在磁盘资源提供程序的末尾不存在。
一旦你使用在层级/SKU 更改之前创建的恢复点触发故障转移,则故障转移最终会失败并出现 BookmarkNotFound
错误。 由于修剪恢复点是一项计划作业,因此你可能会在门户上看到这样的恢复点,但是随着时间的推移,它会被删除。
建议:等待创建日期时间晚于磁盘更改的恢复点。
Site Recovery 会将已复制数据发送到缓存存储帐户。 如果将数据从虚拟机上传到缓存存储帐户时的速度有 3 秒低于 4 MB,则可能是遇到了网络延迟。
若要检查延迟相关的问题,请使用 AzCopy。 可以使用此命令行实用工具将数据从虚拟机上传到缓存存储帐户。 如果延迟较高,请检查你是否在使用网络虚拟设备 (NVA) 控制来自 VM 的出站网络流量。 如果所有复制流量都通过 NVA,设备可能会受到限制。
建议在虚拟网络中为“存储”创建一个网络服务终结点,这样复制流量就不会经过 NVA。 有关详细信息,请参阅网络虚拟设备配置。
要使 Site Recovery 复制正常运行,需要 VM 提供到特定 URL 或 IP 范围的出站连接。 VM 可能位于防火墙后面,或使用网络安全组 (NSG) 规则控制出站连接。 如果是这样,则可能会遇到问题。 若要确保所有 URL 都已连接,请参阅 URL 的出站连接。
下面是一些最常见的问题。
如何修复: SQL Server 2008/2008 R2 有一个已知问题。 请参阅托管 SQL Server 2008 R2 的服务器的 Azure Site Recovery 代理或其他非组件 VSS 备份失败一文。
如何修复: 请参阅托管包含 AUTO_CLOSE DB 的 SQL Server 实例上的非组件 VSS 备份(例如 Azure Site Recovery 作业)失败一文。
如何解决:请参阅 SQL Server 2017 累积更新 16 一文。
如何解决:Azure Site Recovery 无法针对存储空间直通配置创建应用程序一致性恢复点。 配置复制策略。
如何解决:适用于 Linux 操作系统的 Azure Site Recovery 支持通过应用程序自定义脚本实现应用一致性。 为保障应用一致性,Azure Site Recovery 移动代理将使用带有 pre 和 post 选项的自定义脚本。 这里是启用此功能的步骤。
若要进一步排查问题,请查看源计算机上的文件,获取故障的具体错误代码:
C:\Program Files (x86)\21Vianet Azure Site Recovery\agent\Application Data\ApplicationPolicyLogs\vacp.log
若要查找错误,请在文本编辑器中打开 vacp.log 文件,并搜索字符串“vacpError”。
Ex: vacpError:220#Following disks are in FilteringStopped state [\\.\PHYSICALDRIVE1=5, ]#220|^|224#FAILED: CheckWriterStatus().#2147754994|^|226#FAILED to revoke tags.FAILED: CheckWriterStatus().#2147754994|^|
在上面的示例中,2147754994 是错误代码,提供有关此句子后面的失败的信息。
如何解决:为了生成应用程序一致性标记,Azure Site Recovery 将使用卷影复制服务 (VSS)。 Site Recovery 安装适用于其操作的 VSS 提供程序,以创建应用一致性快照。 Azure Site Recovery 将此 VSS 提供程序作为服务安装。 如果未安装 VSS 提供程序,则创建应用程序一致性快照的操作将会失败。 此时会显示“错误 ID 0x80040154 未注册类”。 请参阅有关 VSS 编写器安装故障排除的文章。
如何解决:为了生成应用程序一致性标记,Azure Site Recovery 将使用 VSS。 Site Recovery 安装适用于其操作的 VSS 提供程序,以创建应用一致性快照。 此 VSS 提供程序作为服务安装。 如果未启用 VSS 提供程序服务,则创建应用程序一致性快照的操作将会失败。 此时会显示错误:“指定的服务已禁用且无法启动(0x80070422)”。
如果已禁用 VSS:
- 确认 VSS 提供程序服务的启动类型是否设置为“自动”。
- 重启以下服务:
- VSS 服务。
- Azure Site Recovery VSS 提供程序。
- VDS 服务。
如何解决:为了生成应用程序一致性标记,Azure Site Recovery 将使用 VSS。 检查是否已安装 Azure Site Recovery VSS 提供程序服务。
使用以下命令重新安装 VSS 提供程序:
卸载现有的提供程序:
"C:\Program Files (x86)\21Vianet Azure Site Recovery\agent\InMageVSSProvider_Uninstall.cmd"
重新安装 VSS 提供程序:
"C:\Program Files (x86)\21Vianet Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"
确认 VSS 提供程序服务的启动类型是否设置为“自动”。
重启以下服务:
- VSS 服务。
- Azure Site Recovery VSS 提供程序。
- VDS 服务。