已知問題 - Azure Stack Hub 上的 Azure Site Recovery

本文說明 Azure Stack Hub 上的 Azure Site Recovery 已知問題。 如需 Azure Stack Hub 上 Azure Site Recovery 中目前已知問題和限制的詳細數據，請使用下列各節。

支援的磁碟大小上限為 1022 GB

當您保護 VM 時，Azure Site Recovery 必須將額外的 1 GB 數據新增至現有的磁碟。 由於 Azure Stack Hub 對於磁碟大小上限有 1023 GB 的硬性限制，Site Recovery 所保護的磁碟大小上限必須等於或小於 1022。

當您嘗試使用 1023Gb 的磁碟保護 VM 時，會發生下列行為：

• 啟用保護成功，因為只有 1 GB 的種子磁碟已建立並可供使用。 此步驟中沒有任何錯誤。

• 復寫在 xx% 已同步處理，並在一段時間之後封鎖復寫健康情況，並出現 AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure 錯誤。 發生錯誤的原因是在復寫期間，Site Recovery 會嘗試將種子磁碟大小調整為 1024 GB 並寫入該磁碟。 此作業失敗，因為 Azure Stack Hub 不支援 1024 GB 磁碟。

  

• 針對此磁碟所建立的種子磁碟（在目標訂用帳戶中）的大小仍為 1 GB，而 活動記錄 會顯示一些 寫入磁碟 失敗，並顯示錯誤訊息 參數 『disk.diskSizeGb』 的值 '1024' 超出範圍。值 '1024' 必須介於 '1' 和 '1023' 之間。

  

此問題的目前因應措施是建立新的磁碟（1022 GB 或更少），將其連結至來源 VM、將數據從 1023 GB 磁碟複製到新的磁碟，然後從來源 VM 移除 1023 GB 磁碟。 完成此程序之後，且 VM 的所有磁碟都較小或等於 1022 GB，您可以使用 Azure Site Recovery 來啟用保護。

重新保護：設備上的可用數據磁碟位置

1. 請確定設備 VM 有足夠的數據磁碟位置，因為復本磁碟會連結至設備進行重新保護。

2. 同時重新保護磁碟的初始允許數目為 31。 從市集專案建立之設備的預設大小為 Standard_DS4_v2，最多可支援 32 個數據磁碟，而設備本身會使用一個數據磁碟。

3. 如果受保護 VM 的總和大於 31，請執行下列其中一個動作：

   • 將需要重新保護的 VM 分割成較小的群組，以確保同時重新保護的磁碟數目不會超過設備支援的數據磁碟數目上限。
   • 增加 Azure Site Recovery 設備 VM 的大小。

   注意

   我們不會測試及驗證設備 VM 的大型 VM SKU。

4. 如果您嘗試重新保護 VM，但設備上沒有足夠的位置來保存復寫磁碟，就會顯示錯誤訊息 ：發生 內部錯誤。 您可以檢查裝置目前的數據磁碟數目，或登入設備、移至 事件檢視器，並在 [應用程式和服務記錄] 底下開啟 Azure Site Recovery 的記錄：

   

   

   尋找最新的警告以識別問題。

不支援Linux VM核心版本

1. 執行 命令 uname -r來檢查您的核心版本。

   

   如需支援 Linux 核心版本的詳細資訊，請參閱 Azure Azure 支援 矩陣。

2. 使用支援的核心版本時，導致 VM 執行重新啟動的故障轉移，可能會導致故障轉移的 VM 更新為可能不支援的較新版本。 若要避免因為故障轉移 VM 重新啟動而更新，請執行 命令 sudo apt-mark hold linux-image-azure linux-headers-azure ，讓核心版本更新可以繼續。

3. 如需不支援的核心版本，請針對 VM 執行適當的命令，檢查是否有您可以復原的舊版核心版本：

   • Debian/Ubuntu：dpkg --list | grep linux-image

   下圖顯示 Ubuntu VM 5.4.0-1103-azure 版本不支援的範例。 執行命令之後，您可以看到已在 VM 上安裝的支援版本 5.4.0-1077-azure。 利用這項資訊，您可以回復至支援的版本。

   

4. 使用下列步驟回復至支援的核心版本：

   1. 首先，如果發生錯誤，請建立 /etc/default/grub 的複本，例如 。 sudo cp /etc/default/grub /etc/default/grub.bak

   2. 然後，修改 /etc/default/grub，將GRUB_DEFAULT設定為您想要使用的舊版。 您可能有類似 GRUB_DEFAULT=“Ubuntu Ubuntu>的進階選項，Linux 5.4.0-1077-azure”。

      

   3. 選取 [ 儲存 ] 以儲存盤案，然後選取 [ 結束]。

   4. 執行 sudo update-grub 以更新 grub。

   5. 最後，重新啟動 VM，並繼續復原至支援的核心版本。

5. 如果您沒有可復原的舊核心版本，請等候行動代理程式更新，以便支援您的核心。 如果更新已就緒，則會自動完成更新，您可以在入口網站上檢查版本以確認：

   

尚不支援重新保護手動重新同步處理

重新保護作業完成後，復寫會依序啟動。 在復寫期間，可能有需要重新同步處理的情況，這表示會觸發新的初始復寫來同步處理所有變更。

有兩種類型的重新同步處理：

• 自動重新同步處理。 不需要任何用戶動作，而且會自動完成。 使用者可以在入口網站上看到一些事件：

  

• 手動重新同步處理。 需要使用者動作以手動方式觸發重新同步處理，而且需要下列實例：

  • 遺漏為重新保護選擇的記憶體帳戶。

  • 設備上的復寫磁碟遺失。

  • 復寫寫入超過設備上復寫磁碟的容量。

    提示

    您也可以在 [事件] 刀鋒視窗中找到手動重新同步的原因，以協助您決定是否需要手動重新同步處理。

PowerShell 自動化中的已知問題

• 如果您離開並$failbackExtensionName保留$failbackPolicyName空白或 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 的狀態，以確保其狀況良好。

移除裝置 VM （來源） 會封鎖刪除儲存庫 （目標）

若要刪除目標上的 Azure Site Recovery 保存庫，您必須先移除所有受保護的 VM。 如果您先刪除設備 VM，Site Recovery 保存庫會封鎖刪除受保護的資源，並嘗試刪除保存庫本身也會失敗。 刪除資源群組也會失敗，而移除保存庫的唯一方法是刪除建立保存庫的 Azure Stack Hub 使用者訂用帳戶。

若要避免此問題，請務必先從保存庫中的所有專案移除保護，再刪除設備 VM。 這可讓保存庫在設備上完成資源清除（來源端）。 拿掉受保護的項目之後，您可以刪除保存庫並移除設備 VM。

下一步

• Azure Stack Hub 上的 Azure Site Recovery
• Azure Stack Hub 上的 Azure Site Recovery 容量規劃