次の方法で共有


Azure 間の VM レプリケーションに関するエラーのトラブルシューティング

この記事では、リージョン間で Azure 仮想マシン (VM) のレプリケーションと復旧を行うときに Azure Site Recovery で一般的なエラーをトラブルシューティングする方法について説明します。 サポートされる構成の詳細については、Azure VM をレプリケートするためのサポート マトリックスに関するページをご覧ください。

Azure リソースのクォータに関する問題 (エラー コード 150097)

ディザスター リカバリー (DR) リージョンとして使用するターゲット リージョンで Azure VM を作成するには、サブスクリプションが有効であることを確認してください。 必要なサイズの VM を作成するには、サブスクリプションに十分なクォータが必要です。 既定では、Site Recovery ではソース VM のサイズと同じターゲット VM サイズが選択されます。 同じサイズを利用できない場合、Site Recovery では利用可能な最も近いサイズが自動的に選択されます。

ソース VM 構成をサポートするサイズが存在しない場合、次のメッセージが表示されます。

Replication couldn't be enabled for the virtual machine <VmName>.

考えられる原因

  • ターゲット リージョンの場所で VM を作成するための、サブスクリプション ID が有効になっていません。
  • ターゲット リージョンの場所で特定の VM サイズを作成するための、サブスクリプション ID が有効になっていないか、十分なクォータが確保されていません。
  • ターゲット リージョンの場所のサブスクリプション ID について、ソース VM の ネットワーク インターフェイス カード (NIC) の数 (2) と一致する適切なターゲットVM サイズが見つかりません。

問題の解決

Azure 課金のサポートに連絡して、サブスクリプションで、必要なサイズの VM をターゲットの場所に作成できるようにします。 その後、失敗した操作をやり直してください。

ターゲットの場所に容量の制約がある場合は、その場所へのレプリケーションを無効にします。 次に、必要なサイズの VM を作成できるだけのクォータがサブスクリプションに確保されている別の場所へのレプリケーションを有効にします。

信頼されたルート証明書 (エラー コード 151066)

最新の信頼されたルート証明書の一部が VM にない場合、Site Recovery のレプリケーションを有効にするジョブが失敗することがあります。 これらの証明書がないと、VM からの Site Recovery サービス呼び出しの認証と承認が失敗します。

レプリケーションを有効にするジョブが失敗すると、次のメッセージが表示されます。

Site Recovery configuration failed.

考えられる原因

承認と認証に必要な信頼されたルート証明書が仮想マシンに存在しません。

問題の解決

Windows

Windows オペレーティング システムを実行中の VM の場合、最新 Windows 更新プログラムをインストールし、すべての信頼されたルート証明書が VM に存在するようにします。 組織の一般的な Windows 更新管理プロセスまたは証明書更新管理プロセスに従って、VM で最新のルート証明書と更新済み証明書失効リストを取得します。

  • 接続されていない環境の場合は、組織の標準の Windows 更新プロセスに従って、証明書を取得してください。
  • VM に必要な証明書がない場合は、セキュリティ上の理由から、Site Recovery サービスへの呼び出しが失敗します。

問題が解決されたことを確認するには、VM のブラウザーから login.microsoftonline.com にアクセスします。

詳細については、「信頼されたルートおよび許可されない証明書を構成する」を参照してください。

Linux

お使いの Linux オペレーティング システム バージョンのディストリビューターから提供されるガイダンスに従って、VM で最新の信頼されたルート証明書と最新の証明書失効リストを取得します。

SUSE Linux ではシンボリック リンク (symlink) を使用して証明書リストを保持しているため、次の手順に従います。

  1. ルート ユーザーとしてサインインします。 ハッシュ記号 (#) は、既定のコマンド プロンプトです。

  2. ディレクトリを変更するには、次のコマンドを実行します。

    cd /etc/ssl/certs

  3. Symantec ルート CA 証明書が存在するかどうかを確認します。

    ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

    • Symantec ルート CA 証明書が見つからない場合は、次のコマンドを実行してファイルをダウンロードします。 エラーがないか確認し、ネットワーク障害に対する推奨アクションに従います。

      wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

  4. Baltimore ルート CA 証明書が存在するかどうかを確認します。

    ls Baltimore_CyberTrust_Root.pem

    • Baltimore ルート CA 証明書が見つからない場合は、次のコマンドを実行して証明書をダウンロードします。

      wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem

  5. DigiCert_Global_Root_CA 証明書が存在するかどうかを確認します。

    ls DigiCert_Global_Root_CA.pem

    • DigiCert_Global_Root_CA が見つからない場合は、次のコマンドを実行して証明書をダウンロードします。

      wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
      
      openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
      
  6. 新たにダウンロードした証明書のサブジェクト ハッシュを更新するには、再ハッシュ スクリプトを実行します。

    c_rehash

  7. シンボリック リンクとしてのサブジェクト ハッシュが証明書に対して作成されているかどうかを確認するには、次のコマンドを実行します。

    ls -l | grep Baltimore
    
    lrwxrwxrwx 1 root root   29 Jan  8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem
    
    -rw-r--r-- 1 root root 1303 Jun  5  2014 Baltimore_CyberTrust_Root.pem
    
    ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5
    
    -rw-r--r-- 1 root root 1774 Jun  5  2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
    
    lrwxrwxrwx 1 root root   62 Jan  8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
    
    ls -l | grep DigiCert_Global_Root
    
    lrwxrwxrwx 1 root root   27 Jan  8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem
    
    -rw-r--r-- 1 root root 1380 Jun  5  2014 DigiCert_Global_Root_CA.pem
    
  8. ファイル VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem のコピーを b204d74a.0 というファイル名で作成します。

    cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0

  9. ファイル Baltimore_CyberTrust_Root.pem のコピーを 653b494a.0 というファイル名で作成します。

    cp Baltimore_CyberTrust_Root.pem 653b494a.0

  10. ファイル DigiCert_Global_Root_CA.pem のコピーを 3513523f.0 というファイル名で作成します。

    cp DigiCert_Global_Root_CA.pem 3513523f.0

  11. これらのファイルが存在するかどうかを確認します。

    ls -l 653b494a.0 b204d74a.0 3513523f.0
    
    -rw-r--r-- 1 root root 1774 Jan  8 09:52 3513523f.0
    
    -rw-r--r-- 1 root root 1303 Jan  8 09:52 653b494a.0
    
    -rw-r--r-- 1 root root 1774 Jan  8 09:52 b204d74a.0
    

送信 URL または IP 範囲 (エラー コード 151037 または 151072)

Site Recovery レプリケーションを動作させるには、VM から特定の URL への送信接続が必要です。 VM がファイアウォールの内側にあるか、ネットワーク セキュリティ グループ (NSG) ルールを使用して送信接続を制御している場合は、次のいずれかの問題に直面することがあります。 URL を介した送信アクセスについては引き続きサポートされていますが、IP 範囲の許可リストを使用することはサポートされなくなりました。

考えられる原因

  • ドメイン ネーム システム (DNS) を解決できないため、Site Recovery エンドポイントとの接続を確立できません。
  • この問題が頻繁に発生するのは、仮想マシンをフェールオーバーして再保護を行っているときに、ディザスター リカバリー (DR) リージョンから DNS サーバーに到達できない場合です。

問題の解決

カスタム DNS を使っている場合は、ディザスター リカバリー リージョンから DNS サーバーにアクセスできることを確認します。

VM がカスタム DNS 設定を使用するかどうかを確認するには、次を実行します。

  1. [仮想マシン] を開いて、VM を選択します。
  2. VM の [設定] に移動し、 [ネットワーク] を選択します。
  3. [仮想ネットワーク/サブネット] で、仮想ネットワークのリソース ページを開くためのリンクを選択します。
  4. [設定] に移動して、 [DNS サーバー] を選択します。

仮想マシンから DNS サーバーにアクセスを試みます。 DNS サーバーにアクセスできない場合は、DNS サーバーをフェールオーバーするか、または DR ネットワークと DNS の間にサイトのラインを作成して、アクセスできるようにします。

Note

プライベート エンドポイントを使用する場合は、確実に VM によるプライベート DNS レコードの解決が可能であるようにします。

com-error。

問題 2:Site Recovery の構成に失敗しました (151196)

考えられる原因

Microsoft 365 認証と ID IP4 エンドポイントへの接続を確立できません。

問題の解決

Azure Site Recovery では、認証のために Microsoft 365 の IP 範囲にアクセスする必要がありました。 Azure ネットワーク セキュリティ グループ (NSG) 規則またはファイアウォール プロキシを使用して VM 上で発信ネットワーク接続を制御している場合、Microsoft Entra ID へのアクセスを許可するには Microsoft Entra サービス タグに基づく NSG 規則を確実に使用してください。 IP アドレスベースの NSG 規則はサポートしなくなりました。

問題 3:Site Recovery の構成に失敗しました (151197)

考えられる原因

Azure Site Recovery サービス エンドポイントへの接続を確立できません。

問題の解決

VM での発信ネットワーク接続の制御に Azure ネットワーク セキュリティ グループ (NSG) 規則またはファイアウォール プロキシを使用している場合は、確実にサービス タグを使用してください。 Azure Site Recovery の NSG を介して IP アドレスの許可リストを使用することはサポートされなくなりました。

問題 4:ネットワーク トラフィックでオンプレミスのプロキシ サーバーが使用されるとレプリケーションが失敗する (151072)

考えられる原因

カスタム プロキシ設定が無効であり、Mobility Service エージェントが Internet Explorer からプロキシ設定を自動検出しませんでした。

問題を解決する

  1. モビリティ サービス エージェントは、Windows では Internet Explorer から、Linux では /etc/environment からプロキシ設定を検出します。

  2. プロキシを Mobility Service にのみ設定する場合は、次の場所にある ProxyInfo.conf 内にプロキシの詳細を指定できます。

    • Linux: /usr/local/InMage/config/
    • Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config
  3. ProxyInfo.conf 内のプロキシ設定は、次の INI 形式になっている必要があります。

    [proxy]
    Address=http://1.2.3.4
    Port=567
    

Note

Mobility Service エージェントは、認証されていないプロキシのみをサポートします。

詳細情報

必要な URL または必要な IP 範囲を指定するには、「Azure から Azure へのレプリケーションのネットワークについて」のガイダンスに従ってください。

VM でディスクが見つからない (エラー コード 150039)

VM に接続された新しいディスクを初期化する必要があります。 ディスクが見つからない場合は、次のメッセージが表示されます。

Azure data disk <DiskName> <DiskURI> with logical unit number <LUN> <LUNValue> was not mapped to a corresponding disk being reported from within the VM that has the same LUN value.

考えられる原因

  • 新しいデータ ディスクが VM に接続されているが、初期化されませんでした。
  • VM 内部のデータ ディスクは、そのディスクが VM に接続されている論理ユニット番号 (LUN) 値を正しく報告していません。

問題の解決

データ ディスクが初期化されていることを確認し、操作を再試行します。

問題が解決しない場合は、サポートにお問い合わせください。

複数のディスクで保護が使用可能である (エラー コード 153039)

考えられる原因

  • 保護の後に、1 つまたは複数のディスクが最近仮想マシンに追加された。
  • 仮想マシンの保護の後に、1 つまたは複数のディスクが初期化された。

問題の解決

VM のレプリケーション状態をもう一度正常にするには、ディスクを保護するか、警告を無視します。

ディスクを保護するには、次の手順に従います。

  1. [レプリケートされたアイテム]>[VM 名]>[ディスク] にアクセスします。

  2. 保護されていないディスクを選択し、 [レプリケーションを有効にする] を選択します。

    VM ディスクのレプリケーションを有効にする。

警告を無視するには、次の手順に従います。

  1. [レプリケートされたアイテム]>[VM 名] に移動します。

  2. [概要] セクションで警告を選択し、 [OK] を選択します。

    新規ディスクの警告を無視する。

VM がコンテナーから削除され、完了時に情報が表示された (エラー コード 150225)

Site Recovery によって仮想マシンが保護されると、ソース仮想マシンにリンクが作成されます。 保護を削除するか、レプリケーションを無効にすると、Site Recovery によるクリーンアップ ジョブの一環として、これらのリンクが削除されます。 仮想マシンにリソース ロックが設定されている場合、クリーンアップ ジョブが完了するときに情報が表示されます。 その情報には、仮想マシンが Recovery Services コンテナーから削除されたが、ソース マシンから古いリンクの一部をクリーンアップできなかったことが表示されます。

この仮想マシンを保護する予定がない場合、この警告は無視してもかまいません。 ただし、後でこの仮想マシンを保護する必要がある場合は、このセクションの手順に従ってリンクをクリーンアップしてください。

警告

クリーンアップしないと、次のような事態が発生します。

  • Recovery Services コンテナーを使用してレプリケーションを有効にしたときに、仮想マシンが表示されません。
  • [仮想マシン]>[設定]>[ディザスター リカバリー] を使用して VM を保護しようとすると、"VM の既存のリソース リンクが古いため、レプリケーションを有効にすることはできません" というエラー メッセージが表示されて操作が失敗します。

問題の解決

Note

以下の手順の実行中は、Site Recovery でソース仮想マシンを削除することも、何らかの方法で影響を与えることもできません。

  1. VM または VM リソース グループから、ロックを削除します。 たとえば次の図で、MoveDemo という名前の VM のリソース ロックを削除する必要があります。

    VM からロックを削除する。

  2. 古い Site Recovery 構成を削除するためのスクリプトをダウンロードします。

  3. Cleanup-stale-asr-config-Azure-VM.ps1 スクリプトを実行します。 パラメーターとして、サブスクリプション IDVM リソース グループ、および VM 名を指定します。

  4. Azure 資格情報の入力を求められたら、それを指定します。 次に、スクリプトがエラーを出さずに実行されることを確認します。

古いリソースを含む VM でレプリケーションが有効にならない (エラー コード 150226)

考えられる原因

仮想マシンに、以前の Site Recovery 保護の古い構成が残されている。

Site Recovery を使用して Azure VM のレプリケーションを有効にした後、次のことを行った場合、Azure VM で古い構成が残る可能性があります。

  • レプリケーションを無効にしたが、ソース VM にリソース ロックがある。
  • VM でレプリケーションを明示的に無効にせずに、Site Recovery コンテナーを削除した。
  • VM でレプリケーションを明示的に無効にせずに、Site Recovery コンテナーを含むリソース グループを削除した。

問題の解決

Note

以下の手順の実行中は、Site Recovery でソース仮想マシンを削除することも、何らかの方法で影響を与えることもできません。

  1. VM または VM リソース グループから、ロックを削除します。 たとえば次の図で、MoveDemo という名前の VM のリソース ロックを削除する必要があります。

    VM からロックを削除する。

  2. 古い Site Recovery 構成を削除するためのスクリプトをダウンロードします。

  3. Cleanup-stale-asr-config-Azure-VM.ps1 スクリプトを実行します。 パラメーターとして、サブスクリプション IDVM リソース グループ、および VM 名を指定します。

  4. Azure 資格情報の入力を求められたら、それを指定します。 次に、スクリプトがエラーを出さずに実行されることを確認します。

レプリケーションの有効化ジョブで VM またはリソース グループを選択できない

問題 1:リソース グループとソース VM が別の場所にある

Site Recovery では現在、ソース リージョンのリソース グループと仮想マシンが同じ場所にあることが必須となっています。 そうでない場合、保護を適用しようとするときに、仮想マシンもリソース グループも見つけることができません。

回避策として、Recovery Services コンテナーではなく、VM からレプリケーションを有効にします。 [ソース VM]>[プロパティ]>[ディザスター リカバリー] に移動し、レプリケーションを有効にします。

問題 2:このリソース グループが、選択されたサブスクリプションの一部でない

リソース グループが選択されたサブスクリプションの一部ではない場合、保護されたときにリソース グループを見つけられない可能性があります。 リソース グループが、使用中のサブスクリプションに属していることを確認します。

問題 3:構成が古い

Azure VM 上に古い Site Recovery 構成が存在する場合、レプリケーションを有効にする VM が表示されない可能性があります。 Site Recovery を使用して Azure VM のレプリケーションを有効にした後、次のことを行った場合、この状態が発生する可能性があります。

  • VM でレプリケーションを明示的に無効にせずに、Site Recovery コンテナーを削除した。
  • VM でレプリケーションを明示的に無効にせずに、Site Recovery コンテナーを含むリソース グループを削除した。
  • レプリケーションを無効にしたが、ソース VM にリソース ロックがある。

問題の解決

Note

このセクションで説明するスクリプトを使用する前に、AzureRM.Resources モジュールを必ず更新するようにしてください。 以下の手順の実行中は、Site Recovery でソース仮想マシンを削除することも、何らかの方法で影響を与えることもできません。

  1. VM または VM リソース グループにロックが設定されている場合、ロックを削除します。 たとえば次の図で、MoveDemo という名前の VM のリソース ロックを削除する必要があります。

    VM からロックを削除する。

  2. 古い Site Recovery 構成を削除するためのスクリプトをダウンロードします。

  3. Cleanup-stale-asr-config-Azure-VM.ps1 スクリプトを実行します。 パラメーターとして、サブスクリプション IDVM リソース グループ、および VM 名を指定します。

  4. Azure 資格情報の入力を求められたら、それを指定します。 次に、スクリプトがエラーを出さずに実行されることを確認します。

保護のために VM を選択できない

考えられる原因

仮想マシンの拡張機能のインストールが失敗したかまたは応答しない状態にある

問題の解決

[仮想マシン]>[設定]>[拡張機能] の順に進み、拡張機能のいずれかが失敗した状態になっていないか確認します。 失敗したすべての拡張機能をアンインストールしてから、仮想マシンの保護を再試行してください。

VM のプロビジョニング状態が有効でない (エラー コード 150019)

VM でレプリケーションを有効にするには、プロビジョニングの状態が [成功] になっている必要があります。 プロビジョニングの状態を確認するには、次の手順を実行します。

  1. Azure portal の [すべてのサービス] から [リソース エクスプローラー] を選択します。
  2. [サブスクリプション] 一覧を展開して、自分のサブスクリプションを選択します。
  3. [ResourceGroups] 一覧を展開して、VM のリソース グループを選択します。
  4. [リソース] 一覧を展開して、お使いの VM を選択します。
  5. 右側にあるインスタンス ビューで、 [provisioningState] フィールドを確認します。

問題の解決

  • [provisioningState][失敗] になっている場合は、サポートに詳細を問い合わせてトラブルシューティングします。
  • [provisioningState][更新中] になっている場合は、別の拡張機能がデプロイされている可能性があります。 VM 上に何らかの進行中の操作があるかを確認し、それらが完了するまで待機してから、レプリケーションを有効にする、失敗した Site Recovery ジョブを再試行します。

ターゲット VM を選択できない

問題 1:既にターゲット ネットワークにマップされているネットワークに VM が接続されている

ディザスター リカバリー構成中に、ソース VM が仮想ネットワークの一部であり、かつ同じ仮想ネットワークの別の VM が既にターゲット リソース グループ内のネットワークにマップされている場合は、既定で [ネットワークの選択] ドロップダウン リスト ボックスを使用できません (淡色表示されます)。

ネットワーク選択リストを使用できない。

問題 2:以前に VM を保護した後、レプリケーションを無効にした

VM のレプリケーションを無効にしても、ネットワーク マッピングは削除されません。 VM が保護されていた Recovery Service コンテナーからマッピングを削除する必要があります。 [Recovery Services コンテナー] を選択し、 [管理]>[Site Recovery インフラストラクチャ]>[For Azure virtual machines] (Azure 仮想マシンの場合)>[ネットワーク マッピング] に移動します。

ネットワーク マッピングの削除。

ディザスター リカバリーのセットアップ中に構成されたターゲット ネットワークが、初期セットアップ後で、かつ VM が保護された後に変更される場合があります。 ネットワーク マッピングを変更するには、ネットワーク名を選択します。

ネットワーク マッピングの変更。

COM+ または VSS (エラー コード 151025)

COM+ またはボリューム シャドウ コピー サービス (VSS) エラーが発生すると、次のメッセージが表示されます。

Site Recovery extension failed to install.

考えられる原因

  • COM+ システム アプリケーション サービスが無効になっています。
  • ボリューム シャドウ コピー サービスが無効になっています。

問題の解決

COM+ システム アプリケーションとボリューム シャドウ コピー サービスを、自動または手動スタートアップ モードに設定します。

  1. Windows の "サービス" コンソールを開きます。

  2. COM+ システム アプリケーションとボリューム シャドウ コピー サービスの [スタートアップの種類][無効] に設定されていないことを確認します。

    COM+ システム アプリケーションとボリューム シャドウ コピー サービスのスタートアップの種類を確認する。

サポートされていないマネージド ディスクのサイズ (エラー コード 150172)

このエラーが発生すると、次のメッセージが表示されます。

Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.

考えられる原因

ディスクが、サポートされているサイズの 1024 MB を下回っています。

問題の解決

ディスク サイズがサポートされているサイズの範囲内にあることを確認し、操作を再試行してください。

GRUB でデバイス名を使用するときに保護が有効にならない (エラー コード 151126)

考えられる原因

Linux Grand Unified Bootloader (GRUB) 構成ファイル ( /boot/grub/menu.lst/boot/grub/grub.cfg/boot/grub2/grub.cfg、または /etc/default/grub) に、rootresume パラメーターに対してユニバーサル一意識別子 (UUID) の値ではなく実際のデバイス名が指定されている可能性があります。 デバイス名は変更できるため、Site Recovery には UUID が必要です。 再起動時のフェールオーバー時に VM が同じ名前で表示されず、問題が発生する可能性があります。

次の例は、必要な UUID ではなくデバイス名が表示される、GRUB ファイルの行です。

  • ファイル: /boot/grub2/grub.cfg

    linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts

  • ファイル: /boot/grub/menu.lst

    kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

問題の解決

各デバイス名を対応する UUID に置き換えます。

  1. コマンド blkid <device name> を実行して、デバイスの UUID を検出します。 次に例を示します。

    blkid /dev/sda1
    /dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
    blkid /dev/sda2
    /dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"
    
  2. root=UUID=<UUID> および resume=UUID=<UUID> の形式で、デバイス名を UUID に置き換えます。 たとえば、 /boot/grub/menu.lst の行は置換後に次の行のようになります。

    kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314

  3. 保護を再試行してください。

GRUB デバイスが存在しないため保護に失敗した (エラー コード 151124)

考えられる原因

GRUB 構成ファイル ( /boot/grub/menu.lst/boot/grub/grub.cfg/boot/grub2/grub.cfg、または /etc/default/grub) に、rd.lvm.lv または rd_LVM_LV というパラメーターが含まれている可能性があります。 これらのパラメーターは、起動時に検出される論理ボリューム マネージャ (LVM) デバイスを識別します。 これらの LVM デバイスが存在しない場合、保護されたシステム自体は起動せず、起動プロセスでスタックします。 フェールオーバー VM にも同じ問題が確認されます。 次に例をいくつか示します。

  • ファイル: /boot/grub2/grub.cfg (RHEL7 の場合):

    linux16 /vmlinuz-3.10.0-957.el7.x86_64 root=/dev/mapper/rhel_mup--rhel7u6-root ro crashkernel=128M\@64M rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet LANG=en_US.UTF-8

  • ファイル: /etc/default/grub (RHEL7 の場合):

    GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet

  • ファイル: /boot/grub/menu.lst (RHEL6 の場合):

    kernel /vmlinuz-2.6.32-754.el6.x86_64 ro root=UUID=36dd8b45-e90d-40d6-81ac-ad0d0725d69e rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=rootvg/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=rootvg/lv_swap rd_NO_DM rhgb quiet

それぞれの例で、GRUB はボリューム グループ rootvg から root および swap という名前の 2 つの LVM デバイスを検出する必要があります。

問題の解決

LVM デバイスが存在しない場合は、このデバイスを作成するか、GRUB 構成ファイルから対応するパラメーターを削除します。 次に、再び保護を有効にしてください。

Mobility Service の更新が完了し、警告が表示された (エラー コード 151083)

Site Recovery Mobility Service には多数のコンポーネントがありますが、そのうちの 1 つに、フィルター ドライバーと呼ばれるものがあります。 フィルター ドライバーは、システムの再起動時にのみ、システム メモリ内に読み込まれます。 Mobility Service の更新にフィルター ドライバーの変更が含まれている場合、マシンは更新されますが、一部の修正プログラムで再起動が必要であることを示す警告が表示されます。 この警告が表示される理由は、フィルター ドライバーの修正は、新しいフィルター ドライバーが読み込まれたときにのみ有効になるためであり、これは再起動中にのみ発生します。

Note

これはただの警告です。 既存のレプリケーションは、新しいエージェントが更新された後も引き続き機能します。 再起動は、新しいフィルター ドライバーの利点を活用したい任意のタイミングで実行できますが、再起動しない場合は古いフィルター ドライバーが動作し続けます。

フィルター ドライバーを除く、Mobility Service の更新におけるその他の機能強化や修正の利点は、再起動を必要とせずに有効になります。

レプリカ マネージド ディスクが存在する場合は保護が有効にならない

このエラーは、レプリカ マネージド ディスクが (予測されるタグなしで) ターゲット リソース グループに既に存在する場合に発生します。

考えられる原因

この問題は、仮想マシンが以前に保護されていて、レプリケーションを無効にしたときにレプリカ ディスクが削除されていない場合に発生する可能性があります。

問題の解決

エラー メッセージに示されているレプリカ ディスクを削除し、失敗した保護ジョブを再度開始します。

インストーラーがルート ディスクを検出できないため、保護の有効化に失敗した (エラー コード 151137)

このエラーは、Azure Disk Encryption (ADE) を使用して OS ディスクが暗号化されている Linux マシンで発生します。 これは、エージェント バージョン 9.35 でのみ有効な問題です。

考えられる原因

インストーラーは、ルート ファイル システムをホストしているルート ディスクを検出できません。

問題の解決

この問題を解決するには、次の手順を実行します。

  1. 次のコマンドを使用して、RHEL マシンのディレクトリ /var/lib/waagent の下にあるエージェント ファイルを見つけます。

    # find /var/lib/ -name Micro\*.gz

    予想される出力:

    /var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz

  2. 新しいディレクトリを作成し、ディレクトリをこの新しいディレクトリに変更します。

  3. 次のコマンドを使用して、最初の手順で見つかったエージェント ファイルを抽出します。

    tar -xf <Tar Ball File>

  4. prereq_check_installer.json ファイルを開き、次の行を削除します。 その後、ファイルを保存します。

       {
          "CheckName": "SystemDiskAvailable",
          "CheckType": "MobilityService"
       },
    
  5. 次のコマンドを使用して、インストーラーを起動します。

    ./install -d /usr/local/ASR -r MS -q -v Azure

  6. インストーラーが正常に完了したら、レプリケーションの有効化ジョブを再試行します。

レプリケートされたサーバーでの時間の変更に対するトラブルシューティングと処理

このエラーは、変更を修正するために、ソース マシンの時間が進み、その後短時間で戻る場合に発生します。 時間が非常に迅速に修正されるため、変更に気付かないことがあります。

解決方法: この問題を解決するには、システム時間がずれている未来時間を超えるまで待ちます。 もう 1 つの選択肢は、レプリケーションを無効化し、もう一度有効化することです。これは、フォワード レプリケーション (データがプライマリ リージョンからセカンダリ リージョンにレプリケートされる) の場合のみ実行でき、リバース レプリケーション (データがセカンダリ リージョンからプライマリ リージョンにレプリケートされる) には適用できません。

次のステップ

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