この記事では、Azure Stack Hub 上の Azure Site Recovery の既知の問題について説明します。 Azure Stack Hub 上の Azure Site Recovery の現在の既知の問題と制限事項の詳細については、次のセクションを参照してください。
サポートされている最大ディスク サイズは 1,022 GB です
仮想マシン (VM) を保護する場合、Azure Site Recovery では、既存のディスクに 1 GB のデータを追加する必要があります。 Azure Stack Hub には 1,023 GB のディスクの最大サイズに対するハード制限があるため、Site Recovery によって保護されるディスクの最大サイズは 1022 以下である必要があります。
1023 Gb のディスクで VM を保護しようとすると、次の動作が発生します。
1 GB のシード ディスクのみが作成され、使用できる状態になったら、保護を有効にします。 この手順ではエラーはありません。
xx% 同期でレプリケーションがブロックされ、しばらくすると、AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure というエラーでレプリケーションの正常性がクリティカルになります。 このエラーは、レプリケーション中に、Site Recovery がシード ディスクのサイズを 1,024 GB に変更して書き込もうとしているために発生します。 Azure Stack Hub では 1,024 GB のディスクがサポートされていないため、この操作は失敗します。
このディスク (ターゲット サブスクリプション内) 用に作成されたシード ディスクのサイズは 1 GB のままであり、 アクティビティ ログ には、エラー メッセージ "disk.diskSizeGb" の値 '1024' の値が範囲外である、いくつかの ディスク書き込み エラーが表示されます 。値 '1024' は、'1' から '1023' までの範囲である必要があります。
この問題の現在の回避策は、新しいディスク (1,022 GB 以下) を作成し、それをソース VM にアタッチし、1,023 GB のディスクのデータを新しいディスクにコピーしてから、ソース VM から 1,023 GB のディスクを削除することです。 この手順が完了し、VM のすべてのディスクが 1,022 GB 以下になったら、Azure Site Recovery を使用して保護を有効にすることができます。
再保護: アプライアンスで使用可能なデータ ディスク スロット
再保護用のレプリカ ディスクがアプライアンスに接続されるため、アプライアンス VM に十分なデータ ディスク スロットがあることを確認します。
同時に再保護されるディスクの初期許容数は 31 です。 Marketplace 項目から作成されたアプライアンスの既定のサイズは Standard_DS4_v2であり、最大 32 個のデータ ディスクをサポートし、アプライアンス自体は 1 つのデータ ディスクを使用します。
保護された 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 の例を示しています。これはサポートされていません。 コマンドを実行すると、VM に既にインストールされているサポートされているバージョン 5.4.0-1077-azure が表示されます。 この情報を使用すると、サポートされているバージョンにロールバックできます。
- Debian/Ubuntuの場合:
次の手順を使用して、サポートされているカーネル バージョンにロールバックします。
まず、エラーが発生した場合に 備えて、/etc/default/grub のコピーを作成します。たとえば、
sudo cp /etc/default/grub /etc/default/grub.bak。次に、/etc/default/grub を変更して、GRUB_DEFAULT を使用したい以前のバージョンに設定します。 GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 5.4.0-1077-azure" のようなものが表示されることがあります。
[保存] を選択してファイルを保存し、[終了] を選択します。
sudo update-grubを実行して grub を更新します。最後に、VM を再起動し、サポートされているカーネル バージョンへのロールバックを続行します。
ロールバックできる古いカーネル バージョンがない場合は、カーネルをサポートできるように、モビリティ エージェントの更新を待ちます。 更新プログラムは準備ができている場合は自動的に完了し、ポータルでバージョンを確認して次のことを確認できます。
手動再同期の再保護はまだサポートされていない
再保護ジョブが完了すると、レプリケーションが順番に開始されます。 レプリケーション中に再同期が必要な場合があります。つまり、すべての変更を同期するために新しい初期レプリケーションがトリガーされます。
再同期には次の 2 種類があります。
自動再同期。 ユーザーアクションは必要なく、自動的に実行されます。 ユーザーは、ポータルに表示されるいくつかのイベントを確認できます。
手動による再同期。 再同期を手動でトリガーするユーザー アクションが必要であり、次のインスタンスで必要です。
再保護用に選択されたストレージ アカウントがありません。
アプライアンス上のレプリケーション ディスクがありません。
レプリケーションの書き込みが、アプライアンス上のレプリケーション ディスクの容量を超えています。
ヒント
手動による再同期の理由は、手動再同期が必要かどうかを判断するのに役立つイベント ブレードにも表示されます。
PowerShell の自動化に関する既知の問題
$failbackPolicyNameのままにして空または null$failbackExtensionNameすると、再保護が失敗する可能性があります。 次の例を参照してください。
次の例に示すように、常に
$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 を削除できます。