Azure Site RecoveryによるDR計画とテスト

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure Site RecoveryによるDR計画とテスト

クラウドにおけるディザスターリカバリ（DR）は、事業継続計画（BCP）の中核をなす重要な要素です。Azure Site Recovery (ASR) は、Azure IaaS仮想マシン、オンプレミスの物理サーバーやVMware、Hyper-V仮想マシンをAzureにレプリケートすることで、災害発生時に迅速なサービス復旧を可能にするDRaaS (Disaster Recovery as a Service) ソリューションを提供します。本記事では、クラウドアーキテクトの視点からASRを用いたDR計画の策定、設定、運用、セキュリティ、コスト最適化、そして一般的な落とし穴について解説します。

アーキテクチャ

ASRは、プライマリ環境（オンプレミスまたはAzureのソースリージョン）からセカンダリ環境（Azureのターゲットリージョン）へ継続的にデータをレプリケートし、プライマリ環境に障害が発生した場合にセカンダリ環境へフェールオーバーすることでサービスを継続します。

主要コンポーネント:

  • Recovery Services コンテナー (Recovery Services Vault): ASRとAzure Backupの中央管理ポイント。レプリケーションポリシー、リカバリープラン、レプリケーション項目などが格納されます。

  • レプリケーションポリシー: データの整合性、復旧ポイントオブジェクト (RPO) の目標、アプリケーショントランザクション整合性の頻度などを定義します。

  • リカバリープラン: フェールオーバー時に起動する仮想マシンのグループ、起動順序、スクリプト実行、手動アクションなどを定義し、復旧プロセスをオーケストレーションします。

ASRは、RPO (目標復旧時点) と RTO (目標復旧時間) の両方を達成するために設計されています。Azure VM間のレプリケーションでは、通常数秒から数分のRPO、リカバリープランを用いることで数分から数十分のRTOが実現可能です。

以下に、Azure VMからAzure VMへのリージョン間DRにおけるASRのアーキテクチャ概要を示します。

flowchart LR
    subgraph A["ソースリージョン |東日本|"]
        A1["ソースVNet"] --> A2("ソースサブネット")
        A2 --> A3("ソースVM-1")
        A2 --> A4("ソースVM-2")
        A3 -- ASRエージェント |データ変更追跡| --> A5("レプリケーション")
        A4 -- ASRエージェント |データ変更追跡| --> A5
    end

    A5 -- レプリケーション |差分データ同期| --> B["Recovery Services コンテナー"]
    B -- レプリケーションポリシー |RPO/アプリ整合性| --> C["ターゲットリージョン |西日本|"]

    subgraph C
        C1["ターゲットVNet"] --> C2("ターゲットサブネット")
        C2 --> C3("レプリカディスク-1")
        C2 --> C4("レプリカディスク-2")
    end

    B -- リカバリープラン |オーケストレーション| --> C
    C -- フェールオーバーアクション |ターゲットVMのアクティブ化| --> C5("ターゲットVM-1")
    C -- フェールオーバーアクション |ターゲットVMのアクティブ化| --> C6("ターゲットVM-2")
    C3 -- 接続先 |フェールオーバー時| --> C5
    C4 -- 接続先 |フェールオーバー時| --> C6

設定手順

ここでは、Azure VMからAzure VMへのレプリケーションをPowerShellで設定する手順の概要を示します。

  1. Recovery Services コンテナーの作成 ASRを管理するためのコンテナーを作成します。

    # 前提条件: Azureにログイン済み、適切なサブスクリプションが設定済み


# 変数定義

$resourceGroupName = "ASR-DR-RG"
$vaultName = "ASRDRVaultEastJapan"
$location = "japaneast" # ソースリージョン

# リソースグループの作成（もし存在しない場合）

try {
    Get-AzResourceGroup -Name $resourceGroupName -ErrorAction Stop
} catch {
    New-AzResourceGroup -Name $resourceGroupName -Location $location
    Write-Host "Resource Group '$resourceGroupName' created."
}

# Recovery Services コンテナーの作成

$vault = New-AzRecoveryServicesVault -Name $vaultName -ResourceGroupName $resourceGroupName -Location $location -StorageReplicationType GeoRedundant
Write-Host "Recovery Services Vault '$vaultName' created."

    コメント: Recovery Services コンテナーは、レプリケーションの管理ポイントとなります。ストレージレプリケーションタイプは、コンテナー自体の冗長性を決定しますが、ASRのデータレプリケーションとは直接関係しません。

  2. レプリケーションポリシーの作成 ソースVMからターゲットリージョンへのデータのレプリケーション設定を定義します。

    # 変数定義

$policyName = "ASR-VMtoAzurePolicy"
$recoveryPointRetentionInHours = 24 # 復旧ポイントの保持期間 (時間)
$applicationConsistentSnapshotFrequencyInHours = 4 # アプリケーション整合性スナップショットの頻度 (時間)

# レプリケーションポリシーの作成

$policy = New-AzSiteRecoveryPolicy -Name $policyName `
    -RecoveryPointRetentionInHours $recoveryPointRetentionInHours `
    -ApplicationConsistentSnapshotFrequencyInHours $applicationConsistentSnapshotFrequencyInHours
Write-Host "Replication Policy '$policyName' created."

# 作成されたポリシーを確認

Get-AzSiteRecoveryPolicy -Name $policyName

    コメント: RecoveryPointRetentionInHoursは、遡って復元可能な時間を示し、RPOに影響します。ApplicationConsistentSnapshotFrequencyInHoursは、アプリケーション整合性スナップショットの取得頻度で、データベースなどの整合性確保に重要です。

  3. Azure VMのレプリケーション有効化 既存のAzure VMを選択し、ターゲットリージョンへのレプリケーションを有効化します。

    # 変数定義

$sourceVmName = "MyWebAppVM"
$sourceVmResourceGroup = "SourceVM-RG"
$targetLocation = "japanwest" # ターゲットリージョン
$targetResourceGroup = "ASR-DR-Target-RG"
$targetNetworkName = "TargetVNet"
$targetSubnetName = "default"
$targetStorageAccountName = "asrdrcachestorage" # キャッシュストレージアカウント名
$targetStorageAccountRg = "ASR-DR-RG" # キャッシュストレージアカウントのリソースグループ

# Recovery Services Vaultのコンテキストを設定

Set-AzRecoveryServicesVaultContext -Vault $vault

# ソースVMの取得

$sourceVm = Get-AzVM -Name $sourceVmName -ResourceGroupName $sourceVmResourceGroup

# ターゲットリソースグループの作成

try {
    Get-AzResourceGroup -Name $targetResourceGroup -ErrorAction Stop
} catch {
    New-AzResourceGroup -Name $targetResourceGroup -Location $targetLocation
    Write-Host "Target Resource Group '$targetResourceGroup' created."
}

# キャッシュストレージアカウントの作成 (まだ存在しない場合)

try {
    Get-AzStorageAccount -ResourceGroupName $targetStorageAccountRg -Name $targetStorageAccountName -ErrorAction Stop
} catch {
    New-AzStorageAccount -ResourceGroupName $targetStorageAccountRg -Name $targetStorageAccountName -Location $location -SkuName Standard_LRS
    Write-Host "Cache Storage Account '$targetStorageAccountName' created."
}

# ターゲットVNetとサブネットの取得 (事前にターゲットリージョンに作成しておく必要があります)

$targetNetwork = Get-AzVirtualNetwork -ResourceGroupName $targetResourceGroup -Name $targetNetworkName
$targetSubnet = $targetNetwork.Subnets | Where-Object { $_.Name -eq $targetSubnetName }

# レプリケーションの有効化

$job = New-AzSiteRecoveryReplicationProtectedItem -AzureToAzure `
    -VMId $sourceVm.Id `
    -RecoveryServicesProvider $vault `
    -Policy $policy `
    -RecoveryResourceGroupId $targetResourceGroup `
    -RecoveryProximityPlacementGroupId $null ` # 必要に応じて指定
    -RecoveryAvailabilitySetId $null ` # 必要に応じて指定
    -RecoveryVirtualNetworkId $targetNetwork.Id `
    -RecoverySubnetName $targetSubnet.Name `
    -RecoveryAzureStorageAccountId $targetStorageAccount.Id ` # レプリカディスク用。Managed Diskの場合はASRが自動作成
    -RecoveryDiskAccountType Standard_LRS ` # レプリカディスクのSKU
    -TargetLocation $targetLocation `
    -Name "$($sourceVmName)-replication" # レプリケーションアイテムの名前

Write-Host "Replication enabled for VM '$sourceVmName'. Job ID: $($job.Id)"
Wait-AzSiteRecoveryJob -Job $job # プロセス完了を待機
Write-Host "Replication setup complete."

    コメント: このスクリプトは基本的な設定例です。実際の環境では、ターゲットVMのSKU、可用性セット/ゾーン、ディスクタイプ、IPアドレス、NSG設定など、より詳細な構成が必要になります。初期レプリケーションには時間がかかります。

  4. リカバリープランの作成とテストフェールオーバー フェールオーバー時のVM起動順序やスクリプト実行を定義し、DRテストを実施します。

    # 変数定義

$recoveryPlanName = "WebTierRecoveryPlan"
$primaryProtectionContainer = Get-AzSiteRecoveryProtectionContainer -ProtectionContainerType ASR_Azure_V2 -ResourceGroupName $resourceGroupName -VaultName $vaultName | Select-Object -First 1 # ソースコンテナー
$recoveryProtectionContainer = Get-AzSiteRecoveryProtectionContainer -ProtectionContainerType ASR_Azure_V2 -ResourceGroupName $resourceGroupName -VaultName $vaultName | Select-Object -Last 1 # ターゲットコンテナー (異なるリージョン)
$protectionItem = Get-AzSiteRecoveryReplicationProtectedItem -Name "$($sourceVmName)-replication" # 先ほどレプリケーションを有効化したアイテム

# リカバリープランの作成

$recoveryPlan = New-AzSiteRecoveryRecoveryPlan -Name $recoveryPlanName `
    -PrimaryProtectionContainerId $primaryProtectionContainer.Id `
    -RecoveryProtectionContainerId $recoveryProtectionContainer.Id `
    -VmToInclude $protectionItem # 計画に含めるVMを追加

Write-Host "Recovery Plan '$recoveryPlanName' created."

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


# -Direction PrimaryToRecovery: ソースからリカバリーサイトへ


# -ReplicationProtectedItem: リカバリープラン内の保護されたアイテム


# -RecoveryPointType LatestProcessed: 最新の処理済み復旧ポイント


# -RecoveryPlan: 実行するリカバリープラン


# -TestType NonProduction: テストフェールオーバーであることを示す

$testFailoverJob = Start-AzSiteRecoveryTestFailoverJob `
    -RecoveryPlan $recoveryPlan `
    -Direction PrimaryToRecovery `
    -RecoveryPointType LatestProcessed ` # アプリケーション整合性スナップショットの場合は 'AppConsistent'
    -TestType NonProduction

Write-Host "Test failover job started for Recovery Plan '$recoveryPlanName'. Job ID: $($testFailoverJob.Id)"
Wait-AzSiteRecoveryJob -Job $testFailoverJob
Write-Host "Test failover completed. Please verify the recovered VMs in the test network."

# テストクリーンアップ (テストフェールオーバー後にリカバリーVMを削除)


# Start-AzSiteRecoveryTestFailoverCleanupJob -RecoveryPlan $recoveryPlan -Comments "Test cleanup after successful verification."

    コメント: リカバリープランには、VMの起動順序やカスタムスクリプト（Azure Automationなどと連携）を組み込むことができます。テストフェールオーバーは、本番環境に影響を与えずにDRの有効性を検証する重要なプロセスです。

運用監視

ASRの運用においては、継続的な監視と定期的なDRテストが不可欠です。

  • レプリケーション状態の監視: Azure PortalのRecovery Services コンテナーから、各レプリケーションアイテムの健全性、RPO、最新の復旧ポイントを確認できます。Azure Monitorを活用し、レプリケーションの遅延やエラーが発生した場合にアラートを発するように設定します。

  • DRドリル (テストフェールオーバー) の実施: 定期的に（最低でも年1回、可能であれば四半期に1回）テストフェールオーバーを実施し、リカバリープランが想定通りに動作するか、復旧されたアプリケーションが正しく機能するかを検証します。テストフェールオーバーは、本番環境のレプリケーションに影響を与えません。

  • フェールオーバーとフェールバック: 実際の災害発生時には、リカバリープランを実行してターゲットリージョンへフェールオーバーします。障害が復旧した後、必要に応じてフェールバックして元のソースリージョンに戻すことも可能です。フェールバックには、元のソースVMの状態復元と再保護が必要となります。

  • SLA: Azure Site Recoveryは、月間稼働率99.9%のSLAを提供しています。

セキュリティ

ASRの導入と運用におけるセキュリティは、以下の要素で構成されます。

  • アイデンティティと権限境界 (Azure Entra ID / RBAC):

    • Azure Entra ID: ユーザー、グループ、サービスプリンシパルを管理し、ASRリソースへのアクセスを認証します。

    • Azure RBAC (Role-Based Access Control): Recovery Services コンテナーやASR関連リソースへの最小権限アクセスを適用します。

      • Site Recovery Contributorロール: レプリケーションの有効化、リカバリープランの作成・管理、フェールオーバー実行など、ASR関連の主要な操作を許可します。

      • Recovery Services Contributorロール: Recovery Services コンテナー自体の管理権限を含みます。

    • マネージドID: ASRがAzureリソース（ストレージアカウントなど）と安全に連携するために使用します。システム割り当てまたはユーザー割り当てのマネージドIDをASRエージェントや関連サービスに付与することで、資格情報を管理せずに認証を行うことができます。

    • 条件付きアクセス (Conditional Access): Azure PortalやAzure CLIを通じてASRを管理する際に、多要素認証（MFA）の強制、デバイスの状態チェック、IPアドレスの制限などのポリシーを適用し、管理操作のセキュリティを強化します。

  • データ保護:

    • 転送中の暗号化: ソースからターゲットへのレプリケーションデータは、TLS 1.2以上を使用して暗号化されます。

    • 保存時の暗号化: レプリケートされたディスクデータは、Azure Storageに保存される際に既定でサービス側暗号化（SSE）によって暗号化されます。必要に応じて、カスタマーマネージドキー (CMK) を使用して暗号化を強化することも可能です。

  • ネットワークセキュリティ:

    • ネットワークセキュリティグループ (NSG): レプリケーションに必要な特定のポート（HTTPS 443、エージェント通信用ポートなど）のみを許可するように、ソースVMとターゲットVNetのNSGを設定します。

    • Azure Firewall: リージョン間のレプリケーショントラフィックや、DRテスト時のターゲットVNetへのアクセスを制御します。

  • 脅威検出:

    • Azure Defender for Cloud: レプリケートされたVMを含むすべてのAzureリソースのセキュリティ体制を監視し、構成の誤り、脆弱性、脅威を検出してアラートを発します。DR環境のVMがアクティブになった際にも、セキュリティ監視が継続されます。

コスト

ASRのコストは、主に以下の要素で構成されます。

  1. Azure Site Recovery料金:

    • 保護されるインスタンス数に基づいて課金されます。

    • 最初の31日間は無料ですが、その後は保護されている各VMに対して月額料金が発生します（例: 約2,500円/月/VM、SKUやリージョンによる）。

    • 詳細な料金はAzure Site Recovery の料金を参照ください。

  2. ストレージコスト:

    • キャッシュストレージ: ソースVMからの変更データを一時的に保存するストレージアカウント（通常はStandard_LRS）の料金。

    • レプリカディスク: ターゲットリージョンに作成されるレプリケートされたディスク（Managed DiskまたはStorage Account）の料金。これはフェールオーバーが発生しなくても発生します。ソースディスクと同じSKUまたは、より安価なSKUを選択することも可能です。

  3. ネットワークコスト:

    • データ転送: ソースリージョンからターゲットリージョンへのレプリケーションデータ転送に対するリージョン間データ転送コスト。

  4. コンピューティングコスト (フェールオーバー時のみ):

    • 実際にターゲットリージョンでVMが起動し稼働している期間のみ、コンピューティングリソース（VM、IPアドレス、ロードバランサーなど）の料金が発生します。テストフェールオーバーの場合も、テスト用のVMが起動している期間だけ課金されます。

コスト最適化のヒント:

  • RPO/RTO要件の適切な設定: 過剰なRPO目標は、より頻繁なスナップショットや高性能なストレージを要求し、コストを増加させる可能性があります。ビジネス要件に合った最小限の目標を設定します。

  • ターゲットディスクのSKU最適化: レプリカディスクは、ソースディスクと同じ性能である必要がない場合があります。要件に応じて、より安価なStandard HDDやStandard SSDを選択することでストレージコストを削減できます。

  • テスト環境の最適化: テストフェールオーバー時に起動するVMは、本番環境と異なる、より低スペックなSKUを使用することで、テスト期間中のコンピューティングコストを削減できます。テストが完了したら、速やかにクリーンアップを実行し、テスト用のVMを停止・削除します。

  • リザーブドインスタンス (RI) の活用: フェールオーバー後、ターゲットリージョンでVMが長期的に稼働する可能性がある場合、リザーブドインスタンスを事前に購入することで、コンピューティングコストを大幅に削減できます。

落とし穴

ASRを用いたDR計画では、いくつかの一般的な落とし穴が存在します。

  • RPO/RTO目標の誤解または未設定: ビジネス要件に合致しないRPO/RTO目標を設定したり、そもそも明確な目標を設定しなかったりすると、DR計画が実用的でなくなります。

  • リカバリープランのテスト不足: リカバリープランは、実際のフェールオーバーシナリオを想定したオーケストレーションです。定期的なテストフェールオーバーを実施しないと、いざという時に起動順序の誤りやスクリプトの不具合が発覚し、RTOを達成できない可能性があります。特に、アプリケーションの依存関係（DBがWebサーバーより先に起動する必要があるなど）を考慮しないと問題が発生します。

  • ネットワーク構成の複雑性: フェールオーバー後のターゲットVNetでのIPアドレス、DNS解決、VNetピアリング、VPN Gatewayなどのネットワーク構成が正しく機能しない場合、アプリケーションはアクセス不能になります。テストフェールオーバー時に必ずネットワーク疎通を確認することが重要です。

  • アプリケーション整合性の不足: データベースサーバーなど、トランザクション整合性が必要なアプリケーションに対して、適切なアプリケーション整合性スナップショットの頻度を設定しないと、データ損失のリスクが高まります。

  • レプリケーション対象外のリソース: ロードバランサー (Azure Load Balancer/Application Gateway)、Azure SQL DatabaseやAzure Cosmos DBのようなPaaSサービス、Azure Kubernetes Service (AKS) クラスターなどはASRの直接のレプリケーション対象外です。これらのリソースは、DR戦略の一環として別途デプロイまたは復旧計画に含める必要があります。

  • フェールバックの複雑性: フェールオーバーは比較的シンプルですが、フェールバックは元のソース環境への復旧と再保護を伴うため、より複雑になりがちです。フェールバックのプロセスも計画に含め、テストすることが望ましいです。

まとめ

Azure Site Recoveryは、複雑なDR対策を効率的かつ費用対効果の高い方法で実現する強力なサービスです。適切なアーキテクチャ設計、詳細な設定、継続的な運用監視、そして定期的なDRテストを通じて、ビジネスの継続性を確保することができます。セキュリティとコスト最適化の考慮も忘れずに行い、企業が災害時にも迅速にサービスを復旧できる体制を構築しましょう。DR計画は一度作って終わりではなく、常に変化する環境に合わせて見直しと改善を続けることが重要です。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました