Azure VM のディザスターリカバリーでのレプリケーションのトラブルシューティング

2025-05-09

この記事では、リージョン間で Azure 仮想マシン (VM) をレプリケートおよび復旧するときに、Azure Site Recovery で発生する一般的な問題について説明します。また、一般的な問題のトラブルシューティング方法についても説明します。サポートされる構成の詳細については、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]>[Events -last 72 hours]\(イベント - 過去 72 時間\) に移動します。 [データ変更率がサポートされている制限を超えています] というイベントが表示されるはずです。

データ変更率が高すぎることを示す Azure Site Recovery ページ。

イベントを選択すると、ディスクの正確な情報が表示されます。

Azure Site Recovery の制限

以下の表は、Azure Site Recovery の制限を示したものです。これらの制限は、Microsoft のテストに基づいていますが、アプリケーションの入出力 (I/O) として想定されるすべての組み合わせを網羅したものではありません。実際の結果は、ご使用のアプリケーションで発生するさまざまな I/O によって異なることが考えられます。

ここで考慮していただきたい制限が 2 つあります。ディスクあたりのデータチャーンと仮想マシンあたりのデータチャーンです。チャーンの制限については、こちら参照してください。

解決策

Azure Site Recovery にはデータ変更率に制限があり、これはディスクの種類に基づいています。この問題が繰り返されているか一時的なものかを判断するには、影響を受ける仮想マシンのデータ変更率を確認します。ソース仮想マシンに移動し、 [監視] の下のメトリックを探して、次のスクリーンショットに示すメトリックを追加します。

データ変更率を見つけるための 3 段階のプロセスを示すページ。

[メトリックの追加] を選択し、 [OS Disk Write Bytes/Sec](OS ディスク書き込みバイト/秒) と [Data Disk Write Bytes/Sec](データディスク書き込みバイト/秒) を追加します。
スクリーンショットに表示される値の急上昇を監視します。
OS ディスクと結合されたすべてのデータディスクで発生している書き込み操作の合計を確認します。これらのメトリックは、個々のディスクレベルの情報ではなく、データ変更率の合計のパターンを示しています。

一時的なデータバーストにより、データ変更率が急増する可能性があります。データ変更率が 10 MB/秒 (Premium の場合) または 2 MB/秒 (Standard の場合) を超えると、そこから低下した時点でレプリケーションが開始します。ただし、サポートされる制限をチャーンが一貫して大きく上回っている場合は、次のいずれかのオプションを検討してください。

高データ変更率を引き起こしているディスクを除外する: まず、レプリケーションを無効にします。その後、PowerShell を使ってディスクを除外できます。
レプリカディスクのディスクサイズを変更します。このオプションは、ディスクデータチャーンがディスクあたり 20 MB/秒未満の場合、高チャーンではディスクあたり 50 MB/秒未満の場合にのみ役立ちます。たとえば、高チャーンのサポートを選択せず、ディスクが 128 GiB の VM と、8 MB/秒から 10 MB/秒の間のデータチャーンがあるとします。ディスクサイズが 128 GiB のチャーン制限は 8 MB/秒であるため、ディスクサイズを 512 GiB に増やして、より高いチャーンをサポートできます。このソリューションは、Premium Managed Disks を使用しているマシンでのみ可能です。次のステップを実行します。
1. 影響を受けたレプリケーション対象のマシンの [ディスク] に移動し、レプリカディスク名をコピーします。
2. このマネージドディスクのレプリカに移動します。
3. [概要] に、SAS URL が生成されたことを示すバナーが表示される場合があります。このバナーを選択して、エクスポートをキャンセルします。バナーが表示されない場合は、このステップを無視してください。
4. SAS URL が取り消されたら、すぐにマネージドディスクの [サイズ + パフォーマンス] に移動します。 Site Recovery がソースディスクで観測されたチャーン率をサポートするように、サイズを大きくします。

重要

Azure Site Recovery でサポートされるチャーン制限は、レプリカ Premium SSD ディスクのディスクサイズによって異なります。レプリカディスクのパフォーマンスレベルを変更する場合でも、この制限は変わりません。たとえば、ディスクサイズ 128 GiB の Premium SSD レプリカディスクが作成されている場合、その基本パフォーマンスレベルは P10 です。ディスクサイズを変更せずにパフォーマンスレベルを P50 に更新しても、チャーン制限は変更されません。

ディスク層/SKU の変更に関する考慮事項

ディスク層または SKU が変更されるたびに、ディスクに対応するすべてのスナップショット (ブックマーク) がディスクリソースプロバイダーによって作成されます。そのため、基になるスナップショットの一部がディスクリソースプロバイダーの最後に存在しない復旧ポイントがある場合があります。

階層/SKU が変更される前に作成された復旧ポイントを使用してフェールオーバーをトリガーすると、最終的にフェールオーバーが失敗し、BookmarkNotFound エラーが発生します。復旧ポイントの排除はスケジュールされたジョブであるため、このような復旧ポイントは削除された時点でポータルに表示される場合があります。

推奨事項: 日付/時刻で作成された復旧ポイントがディスクに加えられた変更を過ぎるまで待ちます。

ネットワーク接続の問題

キャッシュストレージアカウントへのネットワーク待ち時間

Site Recovery では、キャッシュストレージアカウントにレプリケートされたデータを送信します。仮想マシンからキャッシュストレージアカウントへのデータアップロード速度が 3 秒あたり 4 MB よりも遅い場合、ネットワーク待ち時間が発生することがあります。

待ち時間に関連する問題を確認するには、AzCopy を使用します。このコマンドラインユーティリティを使用して、仮想マシンからキャッシュストレージアカウントにデータをアップロードすることができます。待ち時間が長い場合は、VM からの送信ネットワークトラフィックを制御するためのネットワーク仮想アプライアンス (NVA) を使用しているかどうかを確認します。この場合、すべてのレプリケーショントラフィックが NVA を通過すると、アプライアンスがスロットルされる可能性があります。

レプリケーショントラフィックが NVA に送られないように、"ストレージ" 用の仮想ネットワーク内にネットワークサービスエンドポイントを作成することをお勧めします。詳細については、「ネットワーク仮想アプライアンスの構成」をご覧ください。

ネットワーク接続

Site Recovery レプリケーションを動作させるには、VM で特定の URL または IP 範囲への送信接続を提供する必要があります。 VM がファイアウォールの内側にあるか、ネットワークセキュリティグループ (NSG) ルールを使用して送信接続を制御している場合があります。その場合、イシューが発生する可能性があります。すべての URL が接続されていることを確認するには、URL に対する送信接続に関する記事をご覧ください。

エラー ID 153006 - 過去 "X" 分間に、VM で使用可能なアプリ整合性復旧ポイントはありません

最も一般的なイシューの一部を次に示します。

SQL Server 2008/2008 R2 での既知の問題

修正方法: SQL Server 2008/2008 R2 には、既知のイシューがあります。記事「SQL Server 2008 R2 をホストしているサーバーで Azure Site Recovery エージェントまたはその他の非コンポーネント VSS バックアップが失敗する」を参照してください。

AUTO_CLOSE DB があるいずれかのバージョンの SQL Server インスタンスをホストするサーバーで Azure Site Recovery ジョブが失敗します

修正方法: 記事「AUTO_CLOSE DB を使用して SQL Server インスタンスをホストしているサーバーで Azure Site Recovery ジョブなどの非コンポーネント VSS バックアップが失敗する」を参照してください。

SQL Server 2016 および 2017 での既知の問題

修正方法: SQL Server 2017 の累積アップデート 16。

Azure 記憶域スペースダイレクト構成を使用しています

修正方法: Azure Site Recovery では、記憶域スペースダイレクト構成のアプリケーション整合性復旧ポイントを作成できません。レプリケーションポリシーを構成します。

Linux サーバーでアプリの整合性が有効になっていない

修正方法: Linux オペレーティングシステム用の Azure Site Recovery では、アプリの整合性のためのアプリケーションカスタムスクリプトがサポートされています。プリオプションとポストオプションを含むカスタムスクリプトが、アプリの整合性のために Azure Site Recovery の Mobility Agent によって使用されます。これを有効にする手順は、こちらをご覧ください。

さらにトラブルシューティングを続けるには、ソースマシン上のファイルを確認して、失敗の正確なエラーコードを取得します。

C:\Program Files (x86)\Microsoft 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 がエラーコードであり、この文の後にエラーについての情報が示されます。

VSS ライターがインストールされていません - エラー 2147221164

修正方法: アプリケーション整合性タグを生成するために、Azure Site Recovery ではボリュームシャドウコピーサービス (VSS) が使用されます。 Site Recovery で、アプリ整合性スナップショットを作成する操作のために、VSS プロバイダーがインストールされます。 Azure Site Recovery は、この VSS プロバイダーをサービスとしてインストールします。 VSS プロバイダーがインストールされていない場合、アプリケーション整合性スナップショットの作成は失敗します。 エラー ID 0x80040154 "クラスが登録されていません" が表示されます。 VSS ライターのインストールのトラブルシューティングに関する記事を参照してください。

VSS ライターが無効です - エラー 2147943458

修正方法: アプリケーション整合性タグを生成するために、Azure Site Recovery では VSS が使用されます。 Site Recovery で、アプリ整合性スナップショットを作成する操作のために、VSS プロバイダーがインストールされます。この VSS プロバイダーは、サービスとしてインストールされます。 VSS プロバイダーサービスが有効になっていない場合、アプリケーション整合性スナップショットの作成は失敗します。次のエラーが表示されます。指定されたサービスは無効になっているため、開始できません (0x80070422) 。

VSS が無効になっている場合:

VSS プロバイダーサービスのスタートアップの種類が [自動] に設定されていることを確認します。
次のサービスを再起動します。
- VSS サービス。
- Azure Site Recovery VSS プロバイダー。
- VDS サービス。

VSS PROVIDER NOT_REGISTERED - エラー 2147754756

修正方法: アプリケーション整合性タグを生成するために、Azure Site Recovery では VSS が使用されます。 Azure Site Recovery VSS プロバイダーサービスがインストールされているかどうかを確認してください。

次のコマンドを使用して、VSS プロバイダーをインストールします。

既存のプロバイダーのアンインストール:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Uninstall.cmd"
VSS プロバイダーの再インストール:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

VSS プロバイダーサービスのスタートアップの種類が [自動] に設定されていることを確認します。

次のサービスを再起動します。

VSS サービス。
Azure Site Recovery VSS プロバイダー。
VDS サービス。

ソースマシンで TenantId と ClientId を手動で更新する

修正方法: テナントの期限切れによる Mobility Service のハートビートがないエラーを修正するには、次の手順に従います。

GET Protected 項目 API を実行し、出力からmobilityAgentTenantIdToUpdateとmobilityAgentClientIdToUpdateの値を取得します。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{resourceName}/replicationFabrics/{fabricName}/replicationProtectionContainers/{protectionContainerName}/replicationProtectedItems/{replicatedProtectedItemName}?api-version=2025-01-01

ソースマシンで RCMInfo.conf ファイルを開きます。ファイルの場所は次のとおりです。

ウィンドウズ： C:\ProgramData\Microsoft Azure Site Recovery\Config\RCMInfo.conf
Linux: /usr/local/InMage/config/RCMInfo.conf

手順 1 で取得した新しいテナントの詳細でAADTenantIdのAADClientId、AADAudienceUri、tenantid を更新し、次の形式でファイルを保存します。

AADTenantId=<mobilityAgentTenantIdToUpdate>
AADClientId=<mobilityAgentClientIdToUpdate>
AADAudienceUri=api://<mobilityAgentTenantIdToUpdate>/RecoveryServiceContainer/eastus2euap/1394977864085472368/3134366

次のサービスを再起動します。
- Windows: "InMage Scout VX エージェント - Sentinel/Outpost"、"InMage Scout Application Service"
- Linux: vxagent、appservice

次のステップ

Azure VM を別の Azure リージョンにレプリケートします。