已知问题 - Azure Stack Hub 上的 Azure Site Recovery

项目
08/05/2024

本文介绍 Azure Stack Hub 上的 Azure Site Recovery 的已知问题。使用以下部分了解有关 Azure Stack Hub 上的 Azure Site Recovery 中当前已知问题和限制的详细信息。

支持的最大磁盘大小为 1022 GB

保护虚拟机时，Azure Site Recovery 需要向现有磁盘额外添加 1 GB 数据。由于 Azure Stack Hub 对磁盘大小存在最大 1023 GB 的硬性限制，因此 Site Recovery 保护的磁盘的最大大小必须等于或小于 1022 GB。

尝试保护磁盘大小为 1023 GB 的虚拟机时，会发生以下行为：

启用保护成功，因为创建了仅 1 GB 且可供使用的种子磁盘。此步骤中没有错误。
复制在“xx% 同步”时受阻，而一段时间后复制运行状况变为“严重”，并出现“AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure”错误。发生此错误是因为在复制期间，Site Recovery 会尝试将种子磁盘的大小调整为 1024 GB 并写入该磁盘。此操作失败，因为 Azure Stack Hub 不支持 1024 GB 的磁盘。
（在目标订阅中）为此磁盘创建的种子磁盘大小仍为 1 GB，而“活动日志”会显示一些“写入磁盘”故障，并显示错误消息：“参数‘disk.diskSizeGb’的值‘1024’超出范围。值‘1024’必须在‘1’和‘1023’之间（含‘1’和‘1023’）。

此问题目前的解决方法是创建新磁盘（1022 GB 或更小），然后将其附加到源虚拟机，再将数据从 1023 GB 磁盘复制到新磁盘，最后从源虚拟机中删除 1023 GB 磁盘。完成此过程后，虚拟机的所有磁盘都小于或等于 1022 GB，就可以使用 Azure Site Recovery 启用保护了。

重新保护：设备上的可用数据磁盘插槽

确保设备 VM 有足够的数据磁盘插槽，因为用于重新保护的副本磁盘将附加到设备。
允许同时重新保护的磁盘数最初为 31 个。从市场项创建的设备的默认大小为 Standard_DS4_v2，它最多支持 32 个数据磁盘，并且设备本身会使用一个数据磁盘。
如果受保护 VM 的总数大于 31，请执行以下操作之一：
- 将需要重新保护的 VM 拆分为更小的组，以确保同时重新保护的磁盘数不超过设备支持的最大数据磁盘数。
- 增加 Azure Site Recovery 设备 VM 的大小。
注意

我们不会为设备 VM 测试和验证大型 VM SKU。
如果你正在尝试重新保护 VM，但设备上没有足够的插槽来容纳复制磁盘，则会显示错误消息“发生内部错误”。可以检查设备上的当前数据磁盘数，或者登录到设备，转到“事件查看器”，然后在“应用程序和服务日志”下打开“Azure Site Recovery”的日志：

查找最新警告以识别问题。

不支持 Linux VM 内核版本

通过运行命令 uname -r 来检查内核版本。

有关受支持 Linux 内核版本的详细信息，请参阅 Azure 到 Azure 支持矩阵。
使用受支持的内核版本时，导致 VM 执行重启的故障转移可能会导致将故障转移的 VM 更新到可能不受支持的较新内核版本。为了避免因重启故障转移 VM 而发生更新，请运行命令 sudo apt-mark hold linux-image-azure linux-headers-azure，使内核版本更新可以继续进行。
对于不受支持的内核版本，请通过针对 VM 运行相应的命令来检查可回滚到的旧内核版本：
- Debian/Ubuntu：dpkg --list | grep linux-image
下图显示不受支持版本 5.4.0-1103-azure 上的 Ubuntu VM 中的示例。命令运行后，可以看到支持的版本 5.4.0-1077-azure，该版本已安装在 VM 上。有了这些信息，你可以回滚到支持的版本。
使用以下步骤回滚到受支持的内核版本：
1. 首先，创建 /etc/default/grub 的副本，以防出现错误；例如 sudo cp /etc/default/grub /etc/default/grub.bak。
2. 然后修改 /etc/default/grub 以将 GRUB_DEFAULT 设置为要使用的前一版本。你可能遇到类似于 GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 5.4.0-1077-azure" 的内容。
3. 选择“保存”以保存文件，然后选择“退出”。
4. 运行 sudo update-grub 以更新 grub。
5. 最后，重启 VM 并继续回滚到受支持的内核版本。
如果没有可回滚到的旧内核版本，请等待移动代理更新完成，然后你的内核可受支持。更新会自动完成，如果已准备就绪，你可以在门户上检查版本以确认：

目前不支持重新保护手动重新同步

重新保护作业完成后，将依次启动复制。在复制过程中，可能会出现需要重新同步的情况，即，触发新的初始复制来同步所有更改。

有两种类型的重新同步：

自动重新同步。无需用户操作，可自动完成。用户可以查看门户上显示的一些事件：
手动重新同步。需要用户操作以手动触发重新同步。在以下情况下需要手动重新同步：
- 为重新保护选择的存储帐户缺失。
- 设备上的复制磁盘缺失。
- 复制写入超出了设备上复制磁盘的容量。
  
  提示
  
  还可以在事件边栏选项卡中找到手动重新同步的原因，以帮助决定是否需要手动重新同步。

PowerShell 自动化中的已知问题

如果将 $failbackPolicyName 和 $failbackExtensionName 保留为空或 null，重新保护可能会失败。请看以下示例：

始终指定 $failbackPolicyName 和 $failbackExtensionName，如下列示例所示：

$failbackPolicyName = "failback-default-replication-policy"
$failbackExtensionName = "default-failback-extension"
$parameters = @{
    "properties" = @{
        "customProperties" = @{
            "instanceType" = "AzStackToAzStackFailback"
            "applianceId" = $applianceId
            "logStorageAccountId" = $LogStorageAccount.Id
            "policyName" = $failbackPolicyName
            "replicationExtensionName" = $failbackExtensionName
        }
    }
}
$result = Invoke-AzureRmResourceAction -Action "reprotect" ` -ResourceId $protectedItemId ` -Force -Parameters $parameters

移动服务代理警告

复制多个 VM 时，可能会在 Site Recovery 作业中看到“受保护项的运行状况已更改为警告”错误。

此错误消息只是一条警告，并不表示实际复制或故障转移过程遇到障碍性问题。

提示

可以检查相应 VM 的状态以确保其正常。

删除设备虚拟机（源）会阻止删除保管库（目标）

若要删除目标上的 Azure Site Recovery 保管库，必须先删除所有受保护的虚拟机。如果首先删除设备虚拟机，Site Recovery 保管库会阻止删除受保护的资源，而且尝试删除保管库本身也会失败。删除资源组也会失败，而删除保管库的唯一方法是删除在其中创建保管库的 Azure Stack Hub 用户订阅。

要避免此问题，请确保先从保管库中的所有项中移除保护，然后再删除设备 VM。这样，保管库就可以在设备（源端）上完成资源清理。删除受保护的项后，就可以删除保管库并移除设备虚拟机。

通过