Azure Site RecoveryによるDR計画とフェイルオーバー

Tech

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

Azure Site RecoveryによるDR計画とフェイルオーバー

はじめに

クラウド環境における事業継続性 (BC) および災害復旧 (DR) は、ビジネスの中断を最小限に抑える上で不可欠な要素です。Microsoft Azureが提供するAzure Site Recovery (ASR) は、オンプレミス環境や異なるAzureリージョン間での仮想マシン (VM) のレプリケーションとオーケストレーションされたフェイルオーバーを可能にする堅牢なDRソリューションです。本記事では、クラウドアーキテクトの視点から、ASRを用いたDR計画の策定、実装、運用、セキュリティ、コスト最適化、そして潜在的な落とし穴について解説します。

アーキテクチャの概要

Azure Site Recoveryは、プライマリリージョンのVMからセカンダリリージョンへと継続的にデータをレプリケートし、障害発生時にはセカンダリリージョンにVMを起動して事業継続を図るサービスです。これにより、データ損失とサービス停止時間を最小限に抑えることが可能です。

主な構成要素は以下の通りです[1]:

  • Recovery Services Vault: ASRの構成、レプリケーション、リカバリープラン、監視を一元管理するハブです。

  • ソースリソース: 保護対象となるAzure VM。

  • ターゲットリソース: フェイルオーバー先のAzureリージョンに事前に準備されるリソース（ストレージアカウント、仮想ネットワーク、サブネットなど）。

  • レプリケーションポリシー: RPO (目標復旧時点) やレプリケーション頻度、保持期間などを定義します。

  • リカバリープラン: 複数のVMをグループ化し、フェイルオーバー時の起動順序やスクリプト実行、手動アクションを定義する自動化された手順書です。

以下に、Azure VMからAzure VMへのASRレプリケーションおよびフェイルオーバーの基本的なアーキテクチャフローを示します。

flowchart TD
    subgraph プライマリリージョン
        A["ソースVNet"] --> B["ソースVM(\"エージェント\")"]
        B --|レプリケーション| C("ストレージアカウント")
    end

    subgraph Recovery Services Vault (RSV)
        C --|レプリケーションデータ| D("ASRサービス")
        D --|レプリケーションポリシー| E["リカバリープラン"]
    end

    subgraph セカンダリリージョン (DRサイト)
        F["ターゲットVNet"] --> G["ターゲットサブネット"]
        H("ターゲットストレージアカウント") --|データ復元| I["フェイルオーバーVMディスク"]
        E --|フェイルオーバー指示| J("フェイルオーバー処理")
        J --|VM作成| K["フェイルオーバーVM"]
        K --|ネットワーク接続| F
    end

    B --|継続的レプリケーション| C
    C --|データ保存| H
    D --|構成管理| A
    D --|構成管理| F
    J --|起動順序と設定| K

出典: Microsoft Learnを基に作成 [1]

設定手順

ここでは、Azure VMからAzure VMへのASRを設定する際のPowerShellコマンドレットの例を示します。

# 前提:


#   - Azureサブスクリプションにログイン済み


#   - ソースとターゲットのAzureリージョン、VNet、サブネットが準備済み


#   - 適切な権限 (例: Recovery Services Contributor) を持つアカウントで実行


#   - Azure Az PowerShellモジュールがインストール済み

# --- 1. Recovery Services Vault の作成 ---


# ASRの構成と管理を行うVaultを作成します。

$resourceGroupName = "asr-dr-rg"
$vaultName = "asr-dr-vault"
$location = "japaneast" # プライマリリージョンと同じか近いリージョン

Write-Host "Recovery Services Vaultを作成中..."
New-AzResourceGroup -Name $resourceGroupName -Location $location | Out-Null
$vault = New-AzRecoveryServicesVault -Name $vaultName -ResourceGroupName $resourceGroupName -Location $location
Write-Host "Recovery Services Vault '$vaultName' が作成されました。"

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

Set-AzRecoveryServicesAsrVaultContext -Vault $vault

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


# RPO目標やデータ保持期間などを定義します。

$policyName = "default-replication-policy"
$recoveryPointRetentionInHours = 24 # 24時間分の復旧ポイントを保持
$applicationConsistentFrequencyInHours = 4 # アプリケーション整合性スナップショットの頻度

Write-Host "レプリケーションポリシーを作成中..."
$policy = New-AzRecoveryServicesAsrPolicy -Name $policyName `
    -RecoveryPointRetentionInHours $recoveryPointRetentionInHours `
    -ApplicationConsistentFrequencyInHours $applicationConsistentFrequencyInHours `
    -ReplicationFrequencyInSeconds 300 # 5分ごとにデータレプリケーション
Write-Host "レプリケーションポリシー '$policyName' が作成されました。"

# --- 3. 保護対象VMの有効化 (レプリケーションの開始) ---


# ソースVMを指定し、ターゲットリージョンのVNet、サブネット、キャッシュストレージなどを設定します。

$sourceVMName = "MySourceVM"
$sourceVMResourceGroup = "SourceVM-RG"
$targetLocation = "japanwest" # ターゲットリージョン
$targetResourceGroup = "asr-dr-target-rg"
$targetVnetName = "TargetVNet"
$targetSubnetName = "default" # ターゲットVNetの既存サブネット名

# 既存のVMを取得

$sourceVM = Get-AzVM -Name $sourceVMName -ResourceGroupName $sourceVMResourceGroup

# ターゲットリソースグループの作成 (存在しない場合)

New-AzResourceGroup -Name $targetResourceGroup -Location $targetLocation -Force | Out-Null

# ターゲットVNetとサブネットを取得

$targetVnet = Get-AzVirtualNetwork -Name $targetVnetName -ResourceGroupName $targetResourceGroup
$targetSubnet = Get-AzVirtualNetworkSubnetConfig -Name $targetSubnetName -VirtualNetwork $targetVnet

# ASRレプリケーションプロバイダーの取得

$provider = Get-AzRecoveryServicesAsrFabric -Azure | Select-Object -First 1

# ASRレプリケーション保護アイテムの作成 (レプリケーションの有効化)

Write-Host "VM '$sourceVMName' のレプリケーションを有効化中..."
$protectionContainer = Get-AzRecoveryServicesAsrProtectionContainer -Fabric $provider -Name $vault.Name
$protectionContainerMapping = Get-AzRecoveryServicesAsrProtectionContainerMapping -ProtectionContainer $protectionContainer -Policy $policy

# ターゲット構成オブジェクトを作成

$diskMappings = @()
foreach ($disk in $sourceVM.StorageProfile.DataDisks) {
    $diskMappings += New-AzRecoveryServicesAsrAzureToAzureDiskReplicationConfig -DiskId $disk.Id -LogStorageAccountId $vault.Properties.MonitoringStorageAccount
}
$osDisk = $sourceVM.StorageProfile.OsDisk
$diskMappings += New-AzRecoveryServicesAsrAzureToAzureDiskReplicationConfig -DiskId $osDisk.Id -LogStorageAccountId $vault.Properties.MonitoringStorageAccount -IsOSDisk

$networkNic = $sourceVM.NetworkProfile.NetworkInterfaces[0].Id
$networkAdapterConfig = New-AzRecoveryServicesAsrVMNicConfig -NicId $networkNic -TargetSubnetName $targetSubnet.Name -TargetStaticIPAddress $null # DHCPの場合

# $networkAdapterConfig = New-AzRecoveryServicesAsrVMNicConfig -NicId $networkNic -TargetSubnetName $targetSubnet.Name -TargetStaticIPAddress "10.0.0.10" # 固定IPの場合

Start-AzRecoveryServicesAsrReplicationProtectedItem `
    -AzureToAzure `
    -VirtualMachineId $sourceVM.Id `
    -ProtectionContainerMapping $protectionContainerMapping `
    -RecoveryResourceGroupId $targetResourceGroup `
    -RecoveryVirtualNetworkId $targetVnet.Id `
    -DiskReplicationConfig $diskMappings `
    -Nic $networkAdapterConfig `
    -Policy $policy `
    -Name ($sourceVMName + "-replication") `
    -EnableReplication
Write-Host "VM '$sourceVMName' のレプリケーションが有効化されました。初期レプリケーションが開始されます。"

# --- 4. リカバリープランの作成 (オプションだが推奨) ---


# 複数のVMや手動/自動スクリプト実行を含む複雑なフェイルオーバーをオーケストレーションします。

$recoveryPlanName = "MyRecoveryPlan"
Write-Host "リカバリープラン '$recoveryPlanName' を作成中..."
$replicationProtectedItem = Get-AzRecoveryServicesAsrReplicationProtectedItem -FriendlyName $sourceVMName
New-AzRecoveryServicesAsrRecoveryPlan -Name $recoveryPlanName `
    -PrimaryFabric $provider `
    -RecoveryFabric $provider `
    -ReplicationProtectedItem $replicationProtectedItem `
    -Direction AzureToAzure `
    -Vault $vault
Write-Host "リカバリープラン '$recoveryPlanName' が作成されました。"

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


# 本番環境に影響を与えずにDR計画の有効性を検証します。

Write-Host "テストフェイルオーバーを実行中..."
Start-AzRecoveryServicesAsrTestFailover -RecoveryPlan $recoveryPlanName -Direction PrimaryToRecovery -Vault $vault
Write-Host "テストフェイルオーバーが開始されました。結果はAzureポータルで確認してください。"

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


# Test-Failover が完了したら、結果を確認し、テスト環境を削除する必要があります。


# $testFailoverJob = Get-AzRecoveryServicesAsrJob | Where-Object { $_.Properties.ScenarioName -eq "TestFailover" -and $_.State -eq "Succeeded" } | Select-Object -First 1


# if ($testFailoverJob) {


#    Remove-AzRecoveryServicesAsrTestFailover -Job $testFailoverJob -Vault $vault


# }

出典: Microsoft Learnを基に作成 [5]

運用監視

ASRの運用においては、レプリケーションの状態、フェイルオーバーの成功率、RTO (目標復旧時間) / RPO (目標復旧時点) の達成度を継続的に監視することが重要です。

  • ASRダッシュボード: Recovery Services Vault内で、レプリケーション状態、エラー、未解決のインシデントを一目で確認できます[6]。

  • Azure Monitorとの統合: ASRはAzure Monitorと連携し、ログ分析ワークスペースにイベントログを送信できます。これにより、レプリケーションエラー、保護状態の変更、フェイルオーバーイベントなどを詳細に分析し、カスタムアラートを設定することが可能です[6]。

  • アラート設定: レプリケーションの遅延、クリティカルなエラー、保護状態の喪失などが発生した場合に、メール、SMS、Webhookなどを通じて関係者に通知されるようアラートルールを設定します。

  • DRドリル (テストフェイルオーバー): 定期的にテストフェイルオーバーを実施し、リカバリープランの有効性、RTOの達成度、アプリケーションの動作確認を行います。これはDR計画の信頼性を維持するために最も重要な運用活動です[2]。Microsoftは、少なくとも年1回のテストを推奨しています。

  • SLA: Azure Site Recoveryは特定のSLAを直接提供しませんが、基盤となるAzure VMやストレージ、ネットワークのSLAが適用されます。RTO/RPOはDR計画の設計とテスト結果に大きく依存します。

セキュリティ

Azure Site Recoveryにおけるセキュリティは、データレプリケーション、アクセス制御、ネットワーク保護の各側面で確保されます。

  • Azure RBAC (ロールベースのアクセス制御): Recovery Services Vaultおよび保護対象リソースへのアクセスを最小限の権限で管理します。主要なロールには以下があります[4]:

    • Site Recovery Contributor: ASRサービスを管理する完全な権限。

    • Site Recovery Operator: フェイルオーバーとテストフェイルオーバーを実行する権限。

    • Virtual Machine Contributor: フェイルオーバー後にVMを管理する権限。

    • Network Contributor: フェイルオーバー後にネットワーク設定を管理する権限。

  • Managed Identity: ASRエージェントはマネージドIDを利用して認証を行い、リソースへのアクセスを安全に行います。

  • データ暗号化:

    • 保管中のデータ: ASRがレプリケーションに使用するストレージアカウントは、Azure Storageの保存データ暗号化 (AES-256) によって保護されます。

    • 転送中のデータ: レプリケーションデータは、転送中にTLS 1.2以上で暗号化されます。

  • ネットワークセキュリティグループ (NSG): ソースおよびターゲットの仮想ネットワークでは、レプリケーションに必要な特定のポート (例: HTTPS 443) のみを開放し、不必要なトラフィックを制限します。

  • プライベートエンドポイント: レプリケーションデータ転送にプライベートエンドポイントを使用することで、パブリックインターネットを経由せずにセキュアな接続を確立できます。

  • Azure Defender for Cloud: フェイルオーバー後のターゲットVMについてもAzure Defender for Cloudによるセキュリティ保護を適用し、脅威検出と脆弱性管理を継続します。

コスト最適化

Azure Site Recoveryのコストは、主にASRのライセンス費用、ストレージ費用、データ転送費用、そしてフェイルオーバー後のターゲットVMの実行費用で構成されます[3]。

  • ASRライセンス費用:

    • 保護対象のVMインスタンスごとに課金されます。最初の31日間は無料ですが、その後は月額料金が発生します。料金はVMのサイズではなく、保護対象インスタンス数に基づきます。

  • ストレージ費用:

    • レプリケーションデータの保存に使用されるストレージアカウントの費用です。ターゲットリージョンのキャッシュストレージ、リカバリーポイントのストレージ費用が含まれます。ストレージアカウントの種類 (Standard HDD/SSD, Premium SSD) や冗長性 (LRS, GRS) によって費用が変動します。

  • データ転送費用:

    • レプリケーションデータが異なるリージョンに転送される際の送信データ転送費用が発生します。

  • ターゲットVMの実行費用:

    • テストフェイルオーバー時: テスト時に起動されるVMインスタンスに対して課金されます。テスト完了後にVMを削除することで費用を最小限に抑えられます。

    • 本番フェイルオーバー時: フェイルオーバー後はターゲットリージョンのVMが稼働するため、通常のVM実行費用が発生します。

コスト最適化戦略:

  • リザーブドインスタンス (RI): フェイルオーバー後のターゲットVMのインスタンスタイプが事前に決まっている場合、RIを事前に購入することで最大72%のコスト削減が可能です。ASRライセンスとは別に、VM本体の実行費用に適用されます。

  • Azure Hybrid Benefit: オンプレミスでWindows ServerやSQL Serverのライセンスを保有している場合、Azure Hybrid Benefitを適用することでVMのソフトウェアコストを削減できます。

  • ストレージの最適化: 適切な種類のストレージアカウント (例: HDD/SSD) と冗長性レベルを選択し、不要なストレージコストを削減します。低頻度アクセスデータはより安価なストレージ階層を検討します。

  • ネットワークの最適化: プライベートエンドポイントを使用する場合、データ転送コストに加えてプライベートエンドポイント自体の費用も考慮します。

よくある落とし穴と対策

  1. ネットワーク構成の不一致:

    • 落とし穴: プライマリとセカンダリのVNet/サブネット構成、NSGルール、UDR (ユーザー定義ルート)、DNS設定などが一致していないと、フェイルオーバー後にアプリケーションが通信できない。

    • 対策: フェイルオーバー先のVNet/サブネット、IPアドレス計画、DNS解決、NSGルールを事前に詳細に設計し、テストフェイルオーバーで徹底的に検証する。

  2. RTO/RPO目標と実際の乖離:

    • 落とし穴: 想定していたRTO/RPOが、実際のテストフェイルオーバーで達成できない。特に大規模環境では、起動順序やアプリケーション依存性が複雑になりがち。

    • 対策: リカバリープランを詳細に設計し、起動順序、スクリプト実行、手動ステップを明確にする。定期的なテストフェイルオーバーを通じて、RTO/RPOを測定し、計画を継続的に改善する。

  3. アプリケーション整合性の問題:

    • 落とし穴: データベースやアプリケーションの状態がレプリケーションポイントで整合性が取れていないと、フェイルオーバー後にデータ破損や起動障害が発生する。

    • 対策: ASRエージェントはVSS (Volume Shadow Copy Service) を利用してアプリケーション整合性のあるスナップショットを作成できます。これを有効にし、レプリケーションポリシーで頻度を設定する。

  4. IPアドレスの管理:

    • 落とし穴: フェイルオーバー後にターゲットVMに割り当てるIPアドレスが競合したり、アプリケーションが固定IPを前提としている場合に問題が発生する。

    • 対策: ターゲットVNetのIPアドレス空間を慎重に計画し、フェイルオーバー時に静的IPアドレスを割り当てるか、DNS更新プロセスを自動化する。

  5. テストフェイルオーバーの不足:

    • 落とし穴: テストフェイルオーバーを実施しない、または不十分なテストしか行わないことで、本番のDR発動時に予期せぬ問題に直面する。

    • 対策: 定期的なDRドリルを組織全体で義務付け、本番環境とほぼ同等の負荷をかけた状態でテストを行う。テスト結果の文書化と共有を徹底する。

  6. DR計画の陳腐化:

    • 落とし穴: システム構成の変更（VMの追加/削除、ネットワーク変更、アプリケーション更新）がDR計画に反映されず、計画が現状と乖離する。

    • 対策: インフラの変更管理プロセスにDR計画の更新を組み込む。構成管理ツール (IaC) を活用してDR設定もコードで管理し、変更を自動的に同期させる。

まとめ

Azure Site Recoveryは、Azure環境における堅牢なDR戦略を構築するための強力なツールです。適切なアーキテクチャ設計、詳細な設定、継続的な運用監視、厳格なセキュリティ対策、そして賢明なコスト最適化戦略を組み合わせることで、事業継続性を大幅に向上させることができます。特に、定期的なテストフェイルオーバーとDR計画の継続的な見直しは、予期せぬ事態が発生した際に、計画通りに事業を復旧させるための鍵となります。クラウドアーキテクトは、これらの要素を総合的に考慮し、ビジネス要件に合致したDRソリューションを設計・実装することが求められます。

参照元

[1] Azure Site Recovery の概要 – Azure Site Recovery | Microsoft Learn. (2024年4月22日). Microsoft. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-overview [2] Azure Site Recovery を使用して Azure VM の障害復旧を実行する – Azure Site Recovery | Microsoft Learn. (2024年3月18日). Microsoft. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-tutorial-failover-test [3] Azure Site Recovery の価格 | Microsoft Azure. (2024年5月1日). Microsoft. URL: https://azure.microsoft.com/ja-jp/pricing/details/site-recovery/ [4] Azure Site Recovery のセキュリティに関する考慮事項 – Azure Site Recovery | Microsoft Learn. (2024年4月22日). Microsoft. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-security [5] PowerShell を使用して Azure VM をセカンダリ リージョンにフェールオーバーする – Azure Site Recovery | Microsoft Learn. (2023年10月26日). Microsoft. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/powershell-failover-azure-to-azure [6] Azure Site Recovery の監視 – Azure Site Recovery | Microsoft Learn. (2024年4月22日). Microsoft. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-monitor-on-premises

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

コメント

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