Azure Site Recovery で災害復旧 (DR) 戦略を実装する

Tech

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

Azure Site Recovery で災害復旧 (DR) 戦略を実装する

災害復旧 (DR) は、事業継続計画 (BCP) の重要な要素であり、ITインフラストラクチャが災害や予期せぬ障害に見舞われた際に、ビジネスサービスを迅速に復旧させることを目的とします。Microsoft Azureが提供するAzure Site Recovery (ASR) は、オンプレミス環境（VMware、Hyper-V、物理サーバー）およびAzure仮想マシン (VM) を、別のAzureリージョンにレプリケートすることで、堅牢なDR戦略を実装するための強力なサービスです。ASRは、RTO (目標復旧時間) およびRPO (目標復旧時点) 要件を満たすための柔軟なオプションを提供します。

アーキテクチャ

Azure Site Recoveryを利用したAzure VMからAzure VMへのDRアーキテクチャは、ソースとなるAzureリージョンの仮想マシンを、地理的に離れたターゲットのAzureリージョンに非同期でレプリケートする仕組みです。災害発生時には、レプリケートされたVMイメージからターゲットリージョンでサービスを迅速に起動できます。

以下のMermaidフローチャートは、Azure VMからAzure VMへのレプリケーションおよびフェールオーバーの基本的な流れを示しています。

flowchart TD
    subgraph "ソース Azure リージョン"
        A["ソースVNet"] --> B["ソースVM"]
        B --> C["レプリケーションプロバイダー (ASRエージェント)"]
    end

    subgraph "Azure Site Recovery サービス"
        C --> D{"Recovery Services コンテナー"}|レプリケーションデータの集約・管理|
    end

    subgraph "ターゲット Azure リージョン"
        D --> E["ターゲットVNet"]
        D --> F["キャッシュストレージアカウント"]
        D --> G["レプリカディスク"]
        E & F & G --> H["ターゲットVM(\"フェールオーバー時\")"]
    end

    style A fill:#e0f2f7,stroke:#333,stroke-width:2px
    style B fill:#e0f2f7,stroke:#333,stroke-width:2px
    style E fill:#e0f2f7,stroke:#333,stroke-width:2px
    style H fill:#e0f2f7,stroke:#333,stroke-width:2px
    style D fill:#fbe9e7,stroke:#333,stroke-width:2px

    B --|継続的なデータ同期| D
    D --|レプリケーション| F
    D --|レプリケーション| G
    D --|災害発生時: フェールオーバー| H
    H --|サービス継続| I["ユーザーアクセス"]
    H --|計画フェールバック| B_new["元のソースVMへ復旧"]

[1, 2]

アーキテクチャの主要コンポーネント:

  • Recovery Services コンテナー: レプリケーション設定、レプリケートされたアイテム、および回復ポイントを管理するための中央ハブです。ソースとターゲットリージョンをまたいで存在します。

  • キャッシュストレージアカウント: ソースVMの変更データを一時的に保持し、ターゲットストレージに効率的に転送するためのストレージです。

  • レプリカディスク: ターゲットリージョンに作成され、ソースVMのデータがレプリケートされるディスクです。

  • ターゲットVNet: フェールオーバー時にVMが起動されるターゲットAzureリージョンの仮想ネットワークです。IPアドレスレンジやサブネットはソースVNetに合わせて事前に計画・構成する必要があります。

  • 可用性ゾーン/セット: ターゲットVMを配置する可用性オプションを指定することで、ターゲットリージョン内でのさらなる回復性を確保できます。

設定手順

ここでは、Azure PowerShell を使用して、Azure VMから別のAzureリージョンへのレプリケーションを構成する手順の概要を示します。この例では、既存のAzure VMを保護対象とします。

# 1. 変数の定義

$ResourceGroupName = "ASR-DR-RG" # Recovery Services コンテナーとVMが存在するリソースグループ
$VaultName = "ASR-RecoveryVault"
$Location = "japaneast" # Recovery Services コンテナーのリージョン
$SourceVMName = "MyWebAppVM"
$SourceVMResourceGroup = "WebApp-RG" # 保護対象VMのリソースグループ
$TargetLocation = "japanwest" # ターゲットのAzureリージョン
$PolicyName = "Default-ReplicationPolicy"
$CacheStorageAccountName = "asrdrwebappcache01" # キャッシュストレージアカウント名 (グローバルに一意である必要あり)
$TargetStorageAccountName = "asrdrwebapptarget01" # ターゲットストレージアカウント名 (フェールオーバー時のVMディスク用)

# Azureにログイン

Connect-AzAccount

# Recovery Services コンテナー用リソースグループの作成 (存在しない場合)

if (-not (Get-AzResourceGroup -Name $ResourceGroupName -ErrorAction SilentlyContinue)) {
    New-AzResourceGroup -Name $ResourceGroupName -Location $Location
    Write-Host "リソースグループ '$ResourceGroupName' を作成しました。"
}

# 2. Recovery Services コンテナーの作成

$Vault = Get-AzRecoveryServicesVault -Name $VaultName -ResourceGroupName $ResourceGroupName -ErrorAction SilentlyContinue
if (-not $Vault) {
    $Vault = New-AzRecoveryServicesVault -Name $VaultName -ResourceGroupName $ResourceGroupName -Location $Location
    Set-AzRecoveryServicesVaultContext -Vault $Vault
    Write-Host "Recovery Services コンテナー '$VaultName' を作成しました。"
} else {
    Set-AzRecoveryServicesVaultContext -Vault $Vault
    Write-Host "既存のRecovery Services コンテナー '$VaultName' を使用します。"
}

# 3. キャッシュストレージアカウントの作成

$CacheStorage = Get-AzStorageAccount -Name $CacheStorageAccountName -ResourceGroupName $ResourceGroupName -ErrorAction SilentlyContinue
if (-not $CacheStorage) {
    New-AzStorageAccount -Name $CacheStorageAccountName -ResourceGroupName $ResourceGroupName -Location $Location `
        -SkuName Standard_LRS -Kind StorageV2
    Write-Host "キャッシュストレージアカウント '$CacheStorageAccountName' を作成しました。"
}

# 4. ターゲットストレージアカウントの作成 (フェールオーバー時にディスクとして使用)

$TargetStorage = Get-AzStorageAccount -Name $TargetStorageAccountName -ResourceGroupName $ResourceGroupName -ErrorAction SilentlyContinue
if (-not $TargetStorage) {
    New-AzStorageAccount -Name $TargetStorageAccountName -ResourceGroupName $ResourceGroupName -Location $TargetLocation `
        -SkuName Standard_LRS -Kind StorageV2
    Write-Host "ターゲットストレージアカウント '$TargetStorageAccountName' を作成しました。"
}

# 5. レプリケーションポリシーの作成 (または既存のものを取得)

$ReplicationPolicy = Get-AzRecoveryServicesAsrPolicy -Name $PolicyName -ErrorAction SilentlyContinue
if (-not $ReplicationPolicy) {

    # 例: RPO閾値15分、回復ポイント保持時間24時間、アプリケーション整合性スナップショット頻度4時間

    $ReplicationPolicy = New-AzRecoveryServicesAsrPolicy -AzureToAzure `
        -Name $PolicyName -RecoveryPointRetentionInHours 24 `
        -ApplicationConsistentSnapshotFrequencyInHours 4 `
        -RpoThresholdInMinutes 15
    Write-Host "レプリケーションポリシー '$PolicyName' を作成しました。"
} else {
    Write-Host "既存のレプリケーションポリシー '$PolicyName' を使用します。"
}

# 6. 保護対象VMの取得

$SourceVM = Get-AzVM -Name $SourceVMName -ResourceGroupName $SourceVMResourceGroup
if (-not $SourceVM) {
    Write-Error "ソースVM '$SourceVMName' が見つかりません。リソースグループを確認してください。"
    exit
}

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


# ターゲットVNetは事前に作成しておく必要があります

$TargetVNet = Get-AzVirtualNetwork -ResourceGroupName $ResourceGroupName -Name "TargetVNet" -Location $TargetLocation # ターゲットVNet名を指定
if (-not $TargetVNet) {
    Write-Error "ターゲットVNet 'TargetVNet' が見つかりません。事前に作成してください。"
    exit
}
$TargetSubnet = $TargetVNet.Subnets | Where-Object {$_.Name -eq "default"} # ターゲットサブネット名を指定

# 仮想マシンへのレプリケーションを有効にする


# ターゲットVMのNIC設定、可用性セット/ゾーンなどを詳細に構成するには追加のパラメータが必要

Enable-AzRecoveryServicesAsrReplication -AzureToAzure `
    -VM $SourceVM `
    -RecoveryVault $Vault `
    -ProtectionPolicy $ReplicationPolicy `
    -RecoveryResourceGroupName $ResourceGroupName `
    -RecoveryVirtualNetworkId $TargetVNet.Id `
    -RecoverySubnetId $TargetSubnet.Id `
    -RecoveryStorageAccountId $TargetStorage.Id `
    -SelectionType Primary `
    -LogStorageAccountId $CacheStorage.Id `
    -TargetZone "1" # ターゲットの可用性ゾーンを指定 (オプション)

Write-Host "VM '$SourceVMName' のレプリケーションを有効にしました。"

[3]

補足: 上記スクリプトは基本的な設定であり、NIC構成、IPアドレス、可用性セット/ゾーン、ディスクタイプ、VMサイズ、近接配置グループなどの詳細なターゲット構成は Enable-AzRecoveryServicesAsrReplication コマンドレットの追加パラメータで指定が必要です。

運用監視

DR戦略の実装は一度きりの作業ではありません。継続的な運用監視とDRテストが不可欠です。

  • Azure Monitor と Log Analytics: Recovery Services コンテナーの診断設定を有効にし、ログをLog Analyticsワークスペースに送信します。レプリケーションの状態、エラー、警告を監視し、アラートを設定します。

  • Azure Activity Log: ASRに関連するコントロールプレーンの操作（レプリケーション有効化、フェールオーバーなど）を追跡します。

  • Recovery Services コンテナーの監視: AzureポータルからRecovery Servicesコンテナーの「レプリケートされたアイテム」ビューで、VMごとのレプリケーションヘルス、RPO、最新回復ポイントなどを確認できます。

  • DRドリル (テストフェールオーバー): 定期的にテストフェールオーバーを実行し、ターゲットリージョンでVMが正常に起動し、アプリケーションが動作することを確認します。これにより、RTOおよびRPO目標が達成可能か検証し、潜在的な問題を特定して修正できます。テストフェールオーバーは、ソース環境に影響を与えずに実行できます。

  • SLAの測定: 定期的なDRドリルを通じて、実際のRTO/RPO値を測定し、定義されたSLA要件を満たしているか確認します。

  • 回復ポイントの管理: レプリケーションポリシーで設定された回復ポイントの保持期間と整合性スナップショットの頻度が適切か、アプリケーション要件に基づいて見直します。

セキュリティ

Azure Site Recoveryのセキュリティは、複数のAzureセキュリティサービスとの統合によって強化されます。

  • Azure AD (Entra ID) と Azure RBAC: Recovery Services コンテナーへのアクセスは、Azure ADのユーザー、グループ、サービスプリンシパルを通じて管理します。ASRの操作には、適切なAzureロールベースのアクセス制御 (RBAC) ロールを割り当てます。

    • Site Recovery Contributor: ASR操作のほとんどを実行できますが、Recovery Services コンテナーの作成や削除はできません。

    • Backup Contributor: バックアップ操作に関連しますが、ASRのコンテキストでも一部関連します。

    • Contributor: Recovery Services コンテナーを含むリソースグループに対する広範な権限。

    • 最小特権の原則に基づき、必要な権限のみを付与するカスタムロールを定義することも推奨されます。

  • マネージドID: ASRエージェントやレプリケーションアプライアンスがAzureリソースと安全に通信するために、マネージドIDを利用することを検討します。これにより、資格情報を管理する手間が省けます。

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

    • NSG (Network Security Group): ソースおよびターゲットVNet内のサブネットにNSGを適用し、レプリケーションに必要な通信（ポート443 HTTPSなど）のみを許可するように構成します。

    • Azure Firewall / NVA: 必要に応じて、VNet間のトラフィックをAzure FirewallやNVA (Network Virtual Appliance) で検査し、セキュリティポリシーを適用します。

  • Azure Defender for Cloud (旧 Azure Security Center): ASRによって保護されるVMは、Defender for Cloudによって継続的に監視され、セキュリティ推奨事項や脅威検出の恩恵を受けます。これにより、DR環境自体のセキュリティ体制も強化されます。

  • 条件付きアクセス (Conditional Access): ASRの管理操作を行うユーザーに対して、多要素認証 (MFA) の要求や、信頼できる場所からのアクセス制限などの条件付きアクセスポリシーを適用し、管理者のIDに対する保護を強化します。

  • 保存データと転送中のデータの暗号化: Azure Site Recoveryは、保存データと転送中のデータを既定で暗号化します。ターゲットストレージアカウントのデータはAzure Storage Service Encryption (SSE) によって暗号化され、レプリケーション中のデータはHTTPS経由で転送されます。[4]

コスト

Azure Site Recoveryのコストは、主に以下の要素によって決定されます。

  1. Azure Site Recovery ライセンス費用: 保護される各VMインスタンスに対して、月額費用が発生します。最初の31日間は無料の試用期間が提供されます。

  2. ストレージ費用:

    • キャッシュストレージアカウント: レプリケーションデータを一時的に保存するためのストレージ費用。

    • レプリカディスク: ターゲットリージョンに保持されるディスクのストレージ費用。ディスクの種類（Standard HDD/SSD, Premium SSD）とサイズによって異なります。

  3. データ転送費用: ソースリージョンからターゲットリージョンへのデータレプリケーションに伴うデータ転送費用。リージョン間のデータ転送は通常課金されます。

  4. コンピューティング費用 (DR実行時のみ): フェールオーバーが実行され、ターゲットリージョンでVMが起動している期間に発生するコンピューティング費用。

コスト最適化の戦略:

  • 適切なディスクタイプの選択: キャッシュストレージおよびレプリカディスクは、I/O要件に応じて最適なディスクタイプ（Standard HDD/SSD、Premium SSD）を選択し、過剰なプロビジョニングを避けます。

  • レプリケーションポリシーの最適化: RPO要件を満たす最低限の回復ポイント保持期間とアプリケーション整合性スナップショット頻度を設定し、ストレージ容量とデータ転送量を抑制します。

  • 予約インスタンス (RI) の活用: フェールオーバー後に長期間ターゲットVMが稼働する可能性がある場合、ターゲットVMのSKUに合わせて予約インスタンスを購入することで、コンピューティング費用を大幅に削減できます。RIはフェールオーバー時に稼働するVMに適用可能です。

  • VMのサイジング: フェールオーバー後のVMのサイズは、必ずしもソースVMと同じである必要はありません。DR時の一時的な稼働を想定し、一時的に小さいSKUを選択することも検討できます。

  • ネットワーク egress 料金の最小化: フェールバック時のデータ転送は、逆方向のデータ転送料金が発生します。計画的なフェールバックの回数を最適化することでコストを管理します。[5]

落とし穴

Azure Site Recoveryの実装と運用において、陥りやすい落とし穴とその対策を以下に示します。

  • ネットワーク構成の不備:

    • 問題: フェールオーバー後のターゲットVNetのIPアドレス、DNS設定、NSGルール、ルーティングが不適切で、アプリケーションが通信できない。

    • 対策: フェールオーバー計画の一部として、ターゲットVNetのネットワーク設計を詳細に行い、テストフェールオーバーで徹底的に検証します。必要に応じてAzure DNSプライベートゾーンやカスタムDNS設定を構成します。

  • 権限の不足:

    • 問題: Recovery Services コンテナーの作成、レプリケーションの有効化、フェールオーバーの実行に必要なRBAC権限が不足している。

    • 対策: 前述の「セキュリティ」セクションで説明した通り、最小限の特権で適切なRBACロールを割り当て、作業前に権限を確認します。

  • DRテストの未実施:

    • 問題: DR計画を文書化しただけで、実際のフェールオーバーテストを実施していないため、いざという時に機能しない。

    • 対策: 定期的なテストフェールオーバーを必須とし、計画の課題を早期に発見し修正します。テストフェールオーバーは本番環境に影響を与えないため、積極的に実施すべきです。

  • レプリケーションポリシーの不適切さ:

    • 問題: RPO要件に対して回復ポイントの保持期間やアプリケーション整合性スナップショットの頻度が不足している、または過剰になっている。

    • 対策: アプリケーションのビジネス要件に基づいてRPO/RTO目標を明確に定義し、それに合致するレプリケーションポリシーを設定します。

  • キャパシティプランニングの不足:

    • 問題: ターゲットリージョンでフェールオーバー後に起動するVMのサイズや台数に対して、クォータやリソースが不足している。

    • 対策: フェールオーバーシナリオを想定し、ターゲットリージョンでのVMサイズ、ディスクタイプ、ネットワーク帯域幅、クォータなどのキャパシティを事前に計画し、必要に応じてMicrosoftサポートに連絡してクォータ増加を依頼します。

  • アプリケーションレベルの依存関係の考慮不足:

    • 問題: データベースとWebサーバーなど、複数のVMで構成されるアプリケーションの復旧順序や依存関係が考慮されていない。

    • 対策: フェールオーバー計画で、回復グループとスクリプト（Azure Automationなど）を使用して、VMの起動順序やカスタムスクリプト実行を定義します。

まとめ

Azure Site Recoveryは、Azure環境、オンプレミス環境における堅牢なDR戦略を実装するための包括的なサービスです。適切なアーキテクチャ設計、PowerShellやAzure CLIを活用した自動化された設定、継続的な運用監視、そして強固なセキュリティ対策を講じることで、災害発生時にもビジネスの継続性を確保できます。コスト最適化と定期的なDRドリルの実施は、ASRを最大限に活用し、予期せぬ事態に備える上で不可欠です。これらのベストプラクティスに従うことで、組織は高い可用性と回復性を実現し、ビジネスの信頼性を向上させることができます。

参照情報 (最終アクセス: 2024年7月29日 JST)

  1. Microsoft Docs. “Azure Site Recovery とは.” 更新日: 2024年7月15日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-overview

  2. Microsoft Docs. “Azure VM ディザスター リカバリーのアーキテクチャ.” 更新日: 2024年7月10日. https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-architecture

  3. Microsoft Docs. “PowerShell を使用して Azure VM の Azure リージョン間ディザスター リカバリーを設定する.” 更新日: 2024年6月20日. https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-powershell

  4. Microsoft Docs. “Azure Site Recovery のセキュリティに関する考慮事項.” 更新日: 2024年7月1日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-security

  5. Azure Pricing. “Azure Site Recovery の料金.” 最終更新日: 2024年5月30日. https://azure.microsoft.com/ja-jp/pricing/details/site-recovery/

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

コメント

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