<p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">Azure Site Recovery (ASR) テストフェールオーバーの包括的ガイド</h1> <p>Azure Site Recovery (ASR) は、Azure VM、オンプレミスのVMware VM、Hyper-V VM、および物理サーバーの災害復旧 (DR) 戦略を構築するためのAzureの主要なサービスです。中でも「テストフェールオーバー」は、本番環境に影響を与えることなくDR計画の有効性を検証する上で極めて重要な機能となります。このガイドでは、ASRテストフェールオーバーのアーキテクチャ、設定手順、運用監視、セキュリティ、コスト、そして一般的な落とし穴について、クラウドアーキテクトの視点から包括的に解説します。</p> <h2 class="wp-block-heading">アーキテクチャ概要</h2> <p>ASRのテストフェールオーバーは、本番環境のワークロードを中断することなく、復旧サイトでの仮想マシンの起動と動作を確認するために設計されています。これは、分離されたテスト用仮想ネットワークを作成し、そこにレプリケートされた仮想マシンを展開することで実現されます[1]。</p> <h3 class="wp-block-heading">テストフェールオーバーのフローチャート</h3> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> flowchart TD A["本番Azure VM"] --|継続的にレプリケート| B("ASR Recovery Services Vault") B --|レプリケーションデータ| C("キャッシュストレージアカウント") C --|定期的に転送| D("ターゲットリージョン管理対象ディスク") subgraph テストフェールオーバープロセス E["ASRユーザーがテストフェールオーバー開始"] --|コマンドを発行| B B --|指定された復旧ポイントを選択| F("復旧ポイント") F --|テストVMを作成| G["テスト用仮想ネットワーク"] G --|テストVMを展開| H["テスト用Azure VM"] H --|ネットワーク分離を確認| I{"DR計画の検証"} I --|テスト完了| J["テストクリーンアップ"] J --|リソースを削除| H end A --|レプリケーション| D B --- E E --- F F --- G G --- H H --- I I --- J J --- B </pre></div> <p>この図は、本番Azure VM (A) からASR Recovery Services Vault (B) を介してターゲットリージョン (D) にデータがレプリケートされる過程を示しています。テストフェールオーバーが開始されると (E)、ASRは指定された復旧ポイント (F) に基づいて、分離されたテスト用仮想ネットワーク (G) 内にテスト用Azure VM (H) を作成します。これにより、本番環境に影響を与えることなくDR計画の検証 (I) が可能となり、テスト完了後にはテストリソースのクリーンアップ (J) が行われます[1]。</p> <h2 class="wp-block-heading">設定手順</h2> <p>ASRテストフェールオーバーの設定は、Azureポータル、Azure PowerShell、またはAzure CLIを通じて実行できます。ここでは、Azure PowerShellを使用したテストフェールオーバーの開始とクリーンアップ手順の概要を示します。</p> <h3 class="wp-block-heading">前提条件</h3> <ol class="wp-block-list"> <li><p>Recovery Services コンテナーが作成され、VMのレプリケーションが構成済みであること。</p></li> <li><p>ターゲットリージョンにテスト用の仮想ネットワークが準備されていること。このネットワークは、本番環境のネットワークから完全に分離されている必要があります。</p></li> <li><p>テストフェールオーバーを実行するための適切なAzure RBACロールが付与されていること。</p></li> </ol> <h3 class="wp-block-heading">PowerShellによるテストフェールオーバーの実行</h3> <p>テストフェールオーバーは、指定された復旧ポイントに対して実行されます。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 1. Azureへのログインとサブスクリプションの選択 Connect-AzAccount Select-AzSubscription -SubscriptionId "<Your-Subscription-ID>" # 2. Recovery Services コンテナーのコンテキストを設定 $resourceGroupName = "asr-rg" # Recovery Services コンテナーが存在するリソースグループ名 $vaultName = "asr-vault" # Recovery Services コンテナー名 $vault = Get-AzRecoveryServicesVault -Name $vaultName -ResourceGroupName $resourceGroupName Set-AzRecoveryServicesVaultContext -Vault $vault # 3. 保護されたアイテム（レプリケートされているVM）の取得 # ターゲットVM名、またはレプリケーション設定時に指定した保護されたアイテム名 $protectedItemName = "my-protected-vm" $protectedItem = Get-AzRecoveryServicesAsrReplicationProtectedItem -Name $protectedItemName # 4. 利用可能な復旧ポイントの取得 # 最新のアプリケーション整合性復旧ポイントを使用することを推奨 $recoveryPoints = Get-AzRecoveryServicesAsrRecoveryPoint -ReplicationProtectedItem $protectedItem $latestRecoveryPoint = $recoveryPoints | Sort-Object {$_.RecoveryPointTime} -Descending | Select-Object -First 1 Write-Host "Using recovery point: $($latestRecoveryPoint.RecoveryPointTime)" # 5. テストフェールオーバーの実行 # -NetworkId: テストフェールオーバーに使用する隔離された仮想ネットワークのリソースID # -RecoveryPoint: 使用する復旧ポイントオブジェクト # -ReplicationProtectedItem: 保護されたアイテムオブジェクト # 計算量: O(1) - APIコール # メモリ条件: 通常のPowerShell実行に必要なメモリ $testNetworkId = "/subscriptions/<Your-Subscription-ID>/resourceGroups/<Test-Network-RG>/providers/Microsoft.Network/virtualNetworks/test-vnet" $testFailoverJob = Start-AzRecoveryServicesAsrTestFailover -ReplicationProtectedItem $protectedItem ` -RecoveryPoint $latestRecoveryPoint ` -NetworkId $testNetworkId ` -Direction AzureToAzure # ソースとターゲットがAzureの場合 # ジョブの完了を待機 (オプション) Wait-AzRecoveryServicesAsrJob -Job $testFailoverJob Write-Host "Test failover job completed with status: $($testFailoverJob.State)" </pre> </div> <p>このスクリプトは、指定された保護されたアイテム (<code>my-protected-vm</code>) に対して最新の復旧ポイントを選択し、隔離された仮想ネットワーク (<code>test-vnet</code>) へテストフェールオーバーを実行します[2]。</p> <h3 class="wp-block-heading">テストフェールオーバーのクリーンアップ</h3> <p>テストフェールオーバーの検証が完了したら、必ずクリーンアップを実行して不要なリソースを削除し、課金を停止してください。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 1. 完了したテストフェールオーバージョブの取得 # 前のステップで取得した $testFailoverJob を使用するか、ジョブIDで取得 # $testFailoverJob = Get-AzRecoveryServicesAsrJob -Name "<Test-Failover-Job-ID>" # 2. テストフェールオーバーのクリーンアップ # -Job: クリーンアップするテストフェールオーバージョブオブジェクト # -TestFailoverComments: クリーンアップ理由などのコメント (オプション) # 計算量: O(1) - APIコール # メモリ条件: 通常のPowerShell実行に必要なメモリ $cleanupJob = Remove-AzRecoveryServicesAsrTestFailoverJob -Job $testFailoverJob ` -TestFailoverComments "Test completed successfully on 2024年7月26日." # ジョブの完了を待機 (オプション) Wait-AzRecoveryServicesAsrJob -Job $cleanupJob Write-Host "Test failover cleanup job completed with status: $($cleanupJob.State)" </pre> </div> <p>クリーンアップコマンドは、テストフェールオーバーによって作成されたすべてのテストVMおよび関連リソースを削除します[2]。</p> <h2 class="wp-block-heading">運用監視</h2> <p>ASRテストフェールオーバーの運用監視は、DR計画の信頼性を維持するために不可欠です。</p> <ul class="wp-block-list"> <li><p><strong>ASRジョブ監視</strong>: Recovery Services コンテナーの「Site Recovery ジョブ」から、テストフェールオーバーの進捗と結果を監視できます。成功、失敗、警告などのステータスを確認し、問題が発生した場合は詳細なエラーメッセージを分析します。</p></li> <li><p><strong>Azure Monitor と Log Analytics</strong>: テストフェールオーバーで起動したテストVMに対して、Azure Monitorエージェントをデプロイし、Log Analyticsワークスペースにログを収集することで、VMのパフォーマンス、OSログ、アプリケーションログを監視できます。これにより、DR環境でのアプリケーションの健全性を詳細に検証できます。</p></li> <li><p><strong>アラート</strong>: ASRジョブの失敗や警告が発生した場合に、Azure Monitorアラートを設定して管理者へ通知することで、迅速な対応を可能にします。</p></li> <li><p><strong>SLAの検証</strong>: テストフェールオーバーを通じて、RTO (目標復旧時間) と RPO (目標復旧時点) が実際に達成可能であるかを検証します。起動時間、データ整合性の確認などを含め、本番運用に必要なSLA基準を満たしているか定期的に評価することが重要です。</p></li> </ul> <h2 class="wp-block-heading">セキュリティ</h2> <p>ASRのテストフェールオーバーを含むDR運用全体で、セキュリティは最優先事項です。</p> <ul class="wp-block-list"> <li><p><strong>Azure Entra ID と Azure RBAC</strong>:</p> <ul> <li><p><strong>Recovery Services Contributor</strong>: ASRのレプリケーション設定、フェールオーバー、クリーンアップなど、すべての操作を許可する最も広範なASR関連のロールです。テストフェールオーバーの実行にはこのロールが必要です[6]。</p></li> <li><p><strong>Network Contributor</strong>: テストフェールオーバー時に仮想ネットワークを作成または変更する場合に必要です。</p></li> <li><p><strong>Managed Identities</strong>: ASRコンテナーがAzureストレージアカウントなどの他のAzureサービスと安全に通信するために、マネージドIDを使用することを推奨します。これにより、資格情報を管理する必要がなくなります。</p></li> </ul></li> <li><p><strong>ネットワークセキュリティグループ (NSG)</strong>: テストフェールオーバーに使用する仮想ネットワークは、本番環境のネットワークから完全に分離し、必要な通信のみを許可するNSGルールを設定してください。特にインターネットへの不必要なアクセスは制限すべきです。</p></li> <li><p><strong>Azure Key Vault</strong>: レプリケートされるVMがディスク暗号化を使用している場合、Key Vaultのアクセス許可がDRサイトのVMにも適切に構成されていることを確認します。</p></li> <li><p><strong>Azure Policy</strong>: ASRのデプロイメントが組織のセキュリティ基準に準拠していることを確認するために、Azure Policyを使用して特定の構成（例：ネットワーク分離、タグ付け）を強制できます。</p></li> <li><p><strong>Microsoft Defender for Cloud</strong>: テストフェールオーバーで起動したVMに対しても、Defender for Cloudを有効にすることで、セキュリティ状態の監視と脅威検出を継続的に行うことができます。</p></li> </ul> <h2 class="wp-block-heading">コスト</h2> <p>ASRのコストは、主に以下の要素によって決定されます[3]。</p> <ol class="wp-block-list"> <li><p><strong>保護されたインスタンス</strong>: ASRによって保護される各VMインスタンスに対して課金されます。最初の31日間は無料ですが、それ以降は保護対象のVMごとに月額約3,000円〜7,000円（リージョンや通貨レートによる）が発生します。</p></li> <li><p><strong>ストレージ</strong>: レプリケートされたデータが保存されるストレージアカウント（キャッシュストレージおよびターゲットストレージ）の費用が発生します。これは主に管理対象ディスクやBLOBストレージの標準料金に基づきます。</p></li> <li><p><strong>データ転送</strong>: ソースからターゲットリージョンへのデータ転送（レプリケーション）およびテストフェールオーバー時のデータアクセスには、ネットワークエグレス料金が発生する場合があります。</p></li> </ol> <h3 class="wp-block-heading">コスト最適化</h3> <ul class="wp-block-list"> <li><p><strong>レプリケーションポリシーの最適化</strong>: 復旧ポイントの保持期間を必要最小限に設定することで、ストレージコストを削減できます。例えば、高頻度な復旧ポイントを多数保持するとストレージ使用量が増加します。</p></li> <li><p><strong>リザーブドインスタンス (RI)</strong>: DRサイトのVMに常にリソースを割り当てておく必要がある場合（例：ウォームスタンバイシナリオ）、リザーブドインスタンスを購入することでComputeコストを大幅に削減できます。ASRの保護対象VM自体には直接適用されませんが、フェールオーバー後のVMインスタンスのコストに影響します。</p></li> <li><p><strong>Azure Hybrid Benefit</strong>: オンプレミスからAzureへのフェールオーバー時に、既存のWindows ServerまたはSQL ServerライセンスをAzure VMに持ち込むことで、Computeコストを削減できます。</p></li> <li><p><strong>テストフェールオーバー後のクリーンアップ</strong>: テストフェールオーバー後に不要なテストリソースを放置しないことが重要です。前述のPowerShellスクリプトのように、必ずクリーンアップを実行し、テストVMが不要に課金されないようにします。</p></li> </ul> <h2 class="wp-block-heading">落とし穴とベストプラクティス</h2> <p>ASRテストフェールオーバーを成功させるための一般的な落とし穴とベストプラクティスを以下に示します。</p> <ul class="wp-block-list"> <li><p><strong>ネットワーク分離の不備</strong>: テストフェールオーバーの最も一般的な失敗は、テスト用仮想ネットワークが本番ネットワークと適切に分離されていないことです。IPアドレスの競合や意図しない本番サービスへの影響を避けるため、厳密な分離を確保してください。</p></li> <li><p><strong>IPアドレス構成の考慮</strong>: フェールオーバー後のVMのIPアドレスをどのように構成するか（DHCP、静的IPの維持、Azure Site Recoveryが提供するIPアドレスマッピング）を事前に計画します。DNS設定もDRサイトで適切に機能することを確認します。</p></li> <li><p><strong>アプリケーション整合性</strong>: アプリケーションの整合性のある復旧ポイントを使用することが重要です。これにより、データの一貫性が保たれ、DRサイトでアプリケーションが正常に起動できます。</p></li> <li><p><strong>定期的な実行</strong>: DR計画は一度設定したら終わりではありません。年に数回、定期的にテストフェールオーバーを実行し、DR計画が最新の状態を反映しているか、技術的な変更やアプリケーションの更新に対応しているかを検証します。マイクロソフトは、少なくとも年2回のテストを推奨しています[1]。</p></li> <li><p><strong>テスト計画の文書化</strong>: テストフェールオーバーの手順、期待される結果、検証項目、担当者などを詳細に文書化します。これにより、テストの一貫性が保たれ、問題発生時のトラブルシューティングが容易になります。</p></li> <li><p><strong>依存関係の考慮</strong>: 複数のVMで構成されるアプリケーションの場合、VM間の起動順序や依存関係を考慮した復旧計画 (Recovery Plan) をASRで作成し、それをテストフェールオーバーで検証します。</p></li> </ul> <h2 class="wp-block-heading">まとめ</h2> <p>Azure Site Recoveryのテストフェールオーバーは、ビジネス継続性計画の要となる機能です。本番環境に影響を与えることなく、DR計画の有効性を定期的に検証することで、いざという時のシステム復旧の確実性を高めることができます。アーキテクチャの理解、正確な設定手順、継続的な運用監視、厳格なセキュリティ対策、そしてコスト最適化の意識を持つことが成功の鍵となります。これらのベストプラクティスを実践することで、企業は予期せぬ障害からワークロードを保護し、事業の継続性を確保できるでしょう。</p> <hr/> <p>[1] Microsoft Learn. 「Azure VM のテスト フェールオーバーを実行する」. 2024年4月22日. <a href="https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-drill-failover">https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-drill-failover</a> [2] Microsoft Learn. 「Azure VM に対して PowerShell を使用してテスト フェールオーバーを実行する」. 2024年4月22日. <a href="https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-test-failover-powershell">https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-test-failover-powershell</a> [3] Microsoft Azure. 「Azure Site Recovery の価格」. 2024年1月1日. <a href="https://azure.microsoft.com/ja-jp/pricing/details/site-recovery/">https://azure.microsoft.com/ja-jp/pricing/details/site-recovery/</a> [6] Microsoft Learn. 「Azure のロールベースのアクセス制御を使用してアクセスを管理する」. 2024年4月11日. <a href="https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-role-based-access-control">https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-role-based-access-control</a></p>

flowchart TD
    A["本番Azure VM"] --|継続的にレプリケート| B("ASR Recovery Services Vault")
    B --|レプリケーションデータ| C("キャッシュストレージアカウント")
    C --|定期的に転送| D("ターゲットリージョン管理対象ディスク")

    subgraph テストフェールオーバープロセス
        E["ASRユーザーがテストフェールオーバー開始"] --|コマンドを発行| B
        B --|指定された復旧ポイントを選択| F("復旧ポイント")
        F --|テストVMを作成| G["テスト用仮想ネットワーク"]
        G --|テストVMを展開| H["テスト用Azure VM"]
        H --|ネットワーク分離を確認| I{"DR計画の検証"}
        I --|テスト完了| J["テストクリーンアップ"]
        J --|リソースを削除| H
    end

    A --|レプリケーション| D
    B --- E
    E --- F
    F --- G
    G --- H
    H --- I
    I --- J
    J --- B

# 1. Azureへのログインとサブスクリプションの選択

Connect-AzAccount
Select-AzSubscription -SubscriptionId "<Your-Subscription-ID>"

# 2. Recovery Services コンテナーのコンテキストを設定

$resourceGroupName = "asr-rg" # Recovery Services コンテナーが存在するリソースグループ名
$vaultName = "asr-vault"    # Recovery Services コンテナー名
$vault = Get-AzRecoveryServicesVault -Name $vaultName -ResourceGroupName $resourceGroupName
Set-AzRecoveryServicesVaultContext -Vault $vault

# 3. 保護されたアイテム（レプリケートされているVM）の取得


# ターゲットVM名、またはレプリケーション設定時に指定した保護されたアイテム名

$protectedItemName = "my-protected-vm"
$protectedItem = Get-AzRecoveryServicesAsrReplicationProtectedItem -Name $protectedItemName

# 4. 利用可能な復旧ポイントの取得


# 最新のアプリケーション整合性復旧ポイントを使用することを推奨

$recoveryPoints = Get-AzRecoveryServicesAsrRecoveryPoint -ReplicationProtectedItem $protectedItem
$latestRecoveryPoint = $recoveryPoints | Sort-Object {$_.RecoveryPointTime} -Descending | Select-Object -First 1
Write-Host "Using recovery point: $($latestRecoveryPoint.RecoveryPointTime)"

# 5. テストフェールオーバーの実行


# -NetworkId: テストフェールオーバーに使用する隔離された仮想ネットワークのリソースID


# -RecoveryPoint: 使用する復旧ポイントオブジェクト


# -ReplicationProtectedItem: 保護されたアイテムオブジェクト


# 計算量: O(1) - APIコール


# メモリ条件: 通常のPowerShell実行に必要なメモリ

$testNetworkId = "/subscriptions/<Your-Subscription-ID>/resourceGroups/<Test-Network-RG>/providers/Microsoft.Network/virtualNetworks/test-vnet"
$testFailoverJob = Start-AzRecoveryServicesAsrTestFailover -ReplicationProtectedItem $protectedItem `
    -RecoveryPoint $latestRecoveryPoint `
    -NetworkId $testNetworkId `
    -Direction AzureToAzure # ソースとターゲットがAzureの場合

# ジョブの完了を待機 (オプション)

Wait-AzRecoveryServicesAsrJob -Job $testFailoverJob
Write-Host "Test failover job completed with status: $($testFailoverJob.State)"

# 1. 完了したテストフェールオーバージョブの取得


# 前のステップで取得した $testFailoverJob を使用するか、ジョブIDで取得


# $testFailoverJob = Get-AzRecoveryServicesAsrJob -Name "<Test-Failover-Job-ID>"

# 2. テストフェールオーバーのクリーンアップ


# -Job: クリーンアップするテストフェールオーバージョブオブジェクト


# -TestFailoverComments: クリーンアップ理由などのコメント (オプション)


# 計算量: O(1) - APIコール


# メモリ条件: 通常のPowerShell実行に必要なメモリ

$cleanupJob = Remove-AzRecoveryServicesAsrTestFailoverJob -Job $testFailoverJob `
    -TestFailoverComments "Test completed successfully on 2024年7月26日."

# ジョブの完了を待機 (オプション)

Wait-AzRecoveryServicesAsrJob -Job $cleanupJob
Write-Host "Test failover cleanup job completed with status: $($cleanupJob.State)"