既知の問題 - 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 以下である必要があります。

1023 Gb のディスクで 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 です。 Marketplace アイテムから作成されたアプライアンスの既定のサイズはStandard_DS4_v2で、最大 32 個のデータ ディスクがサポートされ、アプライアンス自体は 1 つのデータ ディスクを使用します。

3. 保護された VM の合計が 31 を超える場合は、次のいずれかのアクションを実行します。

   • 再保護を必要とする VM をより小さなグループに分割して、同時に再保護されたディスクの数が、アプライアンスでサポートされているデータ ディスクの最大数を超えないようにします。
   • Azure Site Recovery アプライアンス VM のサイズを増やします。

   Note

   アプライアンス 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

   次の図は、バージョン 5.4.0-1103-azure の Ubuntu VM の例を示しています。これはサポートされていません。 コマンドを実行すると、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="Linux 5.4.0-1077-azure を使用した Ubuntu>Ubuntu の高度なオプション" に似ている場合があります。

      

   3. [保存] を選択してファイルを保存し、[終了] を選択します。

   4. grub を更新するために実行 sudo update-grub します。

   5. 最後に、VM を再起動し、サポートされているカーネル バージョンへのロールバックを続行します。

5. ロールバックできる古いカーネル バージョンがない場合は、カーネルをサポートできるように、モビリティ エージェントの更新を待ちます。 更新プログラムは、準備ができたら自動的に完了し、ポータルでバージョンをチェックして確認できます。

   

手動再同期の再保護はまだサポートされていません

再保護ジョブが完了すると、レプリケーションが順番に開始されます。 レプリケーション中に再同期が必要な場合があります。つまり、すべての変更を同期するために新しい初期レプリケーションがトリガーされます。

再同期には次の 2 種類があります。

• 自動再同期。 ユーザーアクションは必要なく、自動的に実行されます。 ユーザーは、ポータルに表示されるいくつかのイベントを確認できます。

  

• 手動による再同期。 再同期を手動でトリガーするユーザー アクションが必要であり、次のインスタンスで必要です。

  • 再保護用に選択されたストレージ アカウントがありません。

  • アプライアンス上のレプリケーション ディスクがありません。

  • レプリケーションの書き込みが、アプライアンス上のレプリケーション ディスクの容量を超えています。

    ヒント

    手動による再同期の理由は、手動再同期が必要かどうかを判断するのに役立つイベント ブレードにも表示されます。

PowerShell の自動化に関する既知の問題

• 空$failbackPolicyName$failbackExtensionNameまたは null のままにすると、再保護が失敗する可能性があります。 次の例を参照してください。

  

  

• 次の例に $failbackPolicyName 示すように、常に and を $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 コンテナーを削除するには、まず、保護されているすべての VM を削除する必要があります。 アプライアンス VM を最初に削除すると、Site Recovery コンテナーによって保護されたリソースの削除がブロックされ、コンテナー自体の削除も失敗します。 リソース グループの削除も失敗します。コンテナーを削除する唯一の方法は、コンテナーが作成された Azure Stack Hub ユーザー サブスクリプションを削除することです。

この問題を回避するには、アプライアンス VM を削除する前に、コンテナー内のすべての項目から保護を必ず削除してください。 これにより、コンテナーはアプライアンス (ソース側) でリソースクリーンアップを完了できます。 保護された項目が削除されたら、コンテナーを削除し、アプライアンス VM を削除できます。

次のステップ

• Azure Stack Hub 上の Azure Site Recovery
• Azure Site Recovery on Azure Stack Hub の容量計画