Azure Site RecoveryでオンプレミスDR計画：クラウドアーキテクトによる実践ガイド

Tech

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

Azure Site RecoveryでオンプレミスDR計画：クラウドアーキテクトによる実践ガイド

オンプレミス環境における災害からの事業継続性（BCP）を確保する上で、クラウドベースの災害復旧（DR）ソリューションは費用対効果と柔軟性において大きなメリットをもたらします。Microsoft Azureが提供するAzure Site Recovery（ASR）は、オンプレミスの物理サーバーやVMware仮想マシンをAzureにレプリケーションし、災害発生時にAzure環境で復旧することを可能にするサービスです。本ガイドでは、クラウドアーキテクトの視点からASRを用いたオンプレミスDR計画の策定、実装、運用、および最適化について詳述します。

1. アーキテクチャ

Azure Site Recoveryを利用したオンプレミスDR計画のアーキテクチャは、オンプレミス環境とAzure環境のコンポーネントで構成されます。

オンプレミスコンポーネント

  • Configuration Server (構成サーバー): オンプレミスにデプロイされる主要なコンポーネントで、ASRのコントロールプレーンとして機能します。レプリケーションの管理、Azureとの通信、回復サービスエージェント（Mobility Service）のインストール管理、レプリケーションポリシーの適用などを担当します。通常、専用のWindows Server VMとして構成されます[1]。

  • Process Server (プロセスサーバー): Mobility Serviceからレプリケーションデータを受信し、キャッシュ、圧縮、暗号化を行った後、Recovery Services vaultに送信します。スケールアウトのために追加のプロセスサーバーをデプロイできます。通常、Configuration Serverに組み込まれていますが、大規模環境では独立してデプロイします[1]。

  • Mobility Service (モビリティサービス): 保護対象となる各物理サーバーまたはVMware VMにインストールされるエージェントです。ソースマシン上のデータ変更をキャプチャし、Process Serverに送信します。

Azureコンポーネント

  • Recovery Services vault (回復サービスコンテナー): Azure上にデプロイされ、Site RecoveryとAzure Backupの管理を一元化します。レプリケーションポリシー、回復計画、レプリケーションされたアイテム（VMware VMなど）が格納されます。

  • Storage Account (ストレージアカウント): レプリケーションされたデータが一時的に格納されるキャッシュストレージとして機能します。レプリケーションが継続されると、最終的にマネージドディスクに変換されます。通常、Standard HDDまたはStandard SSDを利用します。

  • Virtual Network (仮想ネットワーク): 災害時にフェールオーバーした際にVMが起動するAzure上のネットワーク環境です。本番環境のネットワーク構成を模倣し、IPアドレス範囲、サブネット、ネットワークセキュリティグループ（NSG）などを事前に定義しておく必要があります。

  • Managed Disk (マネージドディスク): Azure VMのデータディスクとして使用されるストレージです。レプリケーションされたデータは最終的にこの形式で保持されます。

  • Azure VM: フェールオーバー時にRecovery Services vaultから復旧される仮想マシンインスタンスです。

全体アーキテクチャフロー

ASRはオンプレミスからAzureへの非同期レプリケーションを提供し、継続的なデータ同期を行います。

graph LR
    subgraph オンプレミス環境
        A["VMware VM/物理サーバー"] -- 1. Mobility Serviceで変更をキャプチャ --> B("Mobility Service")
        B -- 2. Process Serverに送信 --> C("Process Server")
        C -- 3. レプリケーションデータを圧縮/暗号化 --> D("Configuration Server")
    end

    subgraph Azure 環境
        E["Recovery Services vault"]
        F("Azure Storage Account")
        G("Azure Managed Disk")
        H("Azure Virtual Network")
        I["Azure VM(\"DRサイト\")"]
    end

    D -- 4. HTTPS/TLS 1.2+で暗号化し送信 --> E
    E -- 5. データをFに書き込み --> F
    F -- 6. マネージドディスクに変換/更新 --> G

    E -- 7. フェールオーバー指示 --> I
    I -- 8. GとHに接続して起動 --> G
    I -- 9. GとHに接続して起動 --> H

    note on C
        Process Serverはキャッシュ、
        圧縮、暗号化を処理。
    end

    note on I
        フェールオーバー時に
        Azure VMとして起動
    end

図1: Azure Site RecoveryのオンプレミスDRアーキテクチャフロー

2. 設定手順

ここでは、オンプレミスのVMware仮想マシンをAzureにレプリケーションする際の主要な設定手順をPowerShellを用いて示します。

前提条件

  • Azure サブスクリプション

  • Recovery Services vault の作成

  • オンプレミスConfiguration Server のデプロイと登録

  • 保護対象VMにMobility Serviceがインストールされていること

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

レプリケーションのRPO（Recovery Point Objective）や保持期間を定義します。

# Azure CLIとAz PowerShellモジュールがインストールされ、認証済みであることを前提とします


# サブスクリプションとリソースグループの指定

$SubscriptionId = "your_subscription_id"
$ResourceGroupName = "asr-dr-rg"
$VaultName = "asr-rsvault"
$PolicyName = "OnPremToAzurePolicy"
$RecoveryPointRetentionInHours = 24 # 復旧ポイントの保持期間（時間）
$ApplicationConsistentFrequencyInHours = 4 # アプリケーション整合性スナップショットの頻度（時間）

# サブスクリプションの選択

Select-AzSubscription -SubscriptionId $SubscriptionId

# Recovery Services vaultの取得

$vault = Get-AzRecoveryServicesVault -Name $VaultName -ResourceGroupName $ResourceGroupName

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


# この例では、VMware/物理サーバー向けのポリシー作成を想定


# 実際のコマンドは環境タイプ（VMwareToAzureなど）によって微調整が必要です。


# 通常、ポリシーの作成はGUIまたはCreate-AzSiteRecoveryReplicationPolicy For VmwareToAzureコマンドを使用します。


# 以下のPowerShellスニペットは概念的なものです。

try {

    # 既存のポリシーがあるか確認

    $policy = Get-AzRecoveryServicesAsrReplicationPolicy -Name $PolicyName -Vault $vault -ErrorAction SilentlyContinue

    if (-not $policy) {

        # VMware/物理サーバー向けのレプリケーションポリシーを作成（GUIでの設定を補完）


        # New-AzRecoveryServicesAsrPolicy cmdlet は、より具体的なパラメータを要求します。


        # 以下は、CLI/Portal操作の代替として、ポリシー名と基本的なRPO設定の例

        Write-Host "Creating new replication policy '$PolicyName'..."

        # 実際には、New-AzRecoveryServicesAsrPolicy For VmwareToAzureParametersなどを利用


        # 例:


        # $PolicyProps = New-Object Microsoft.Azure.Commands.RecoveryServices.SiteRecovery.ASRPolicyProperties


        # $PolicyProps.RecoveryPointRetentionInHours = $RecoveryPointRetentionInHours


        # $PolicyProps.ApplicationConsistentFrequencyInHours = $ApplicationConsistentFrequencyInHours


        # New-AzRecoveryServicesAsrPolicy -Name $PolicyName -ProtectionProfileType "VMwareToAzure" -Vault $vault -Properties $PolicyProps

        # 簡易的な表現として、ここではGUIで作成されたものとして進めます

        Write-Host "Please create the replication policy '$PolicyName' via Azure Portal or use full New-AzRecoveryServicesAsrPolicy cmdlet for VMwareToAzure."
        Write-Host "Assuming policy '$PolicyName' exists for demonstration purposes."
        $policy = Get-AzRecoveryServicesAsrReplicationPolicy -Name $PolicyName -Vault $vault

        # 前提: このスクリプト実行前にAzure Portal等でポリシー作成済みとします

    } else {
        Write-Host "Replication policy '$PolicyName' already exists."
    }
} catch {
    Write-Error "Failed to manage replication policy: $($_.Exception.Message)"
}

# 前提条件: Recovery Services VaultとConfiguration Serverは既にAzureに登録済み

# コメント:


# 入力: $SubscriptionId, $ResourceGroupName, $VaultName, $PolicyName, $RecoveryPointRetentionInHours, $ApplicationConsistentFrequencyInHours


# 出力: $policy オブジェクト（既存または新規作成されたポリシー）


# 前提: Az.RecoveryServicesモジュールがインストールされ、Azureにログイン済み。Recovery Services Vaultが存在する。


# 計算量: ネットワークI/OとAzure API呼び出しによる。通常O(1)


# メモリ条件: PowerShell実行環境の標準的なメモリ。

2.2. VMのレプリケーションを有効化

オンプレミスのVMware VMや物理サーバーのレプリケーションを有効化します。

# 保護対象となるオンプレミスVMの識別子（Configuration ServerからのID）


# この情報はConfiguration ServerのGUIまたはASRのAPIから取得します

$VMName = "YourOnPremVMName"
$OnPremVmId = "uuid_of_your_on_premises_vm" # 例: VMware VMのMoRef IDなど

# ターゲットリソースグループ、ストレージアカウント、仮想ネットワーク

$TargetResourceGroup = "asr-dr-target-rg"
$TargetStorageAccount = "asrdrcachestorage" # キャッシュストレージアカウント名
$TargetVirtualNetworkName = "dr-vnet"
$TargetSubnetName = "dr-subnet"
$TargetDiskType = "Standard_LRS" # ターゲットディスクの種類

# Configuration Serverの情報を取得 (Get-AzRecoveryServicesAsrFabric)

$fabric = Get-AzRecoveryServicesAsrFabric -Vault $vault | Where-Object { $_.FabricType -eq "VMware" -or $_.FabricType -eq "VMM" } | Select-Object -First 1 # 環境に応じて調整

if (-not $fabric) {
    Write-Error "Could not find a suitable ASR Fabric (e.g., VMware/VMM). Ensure Configuration Server is registered."
    exit
}

# ターゲットVNetの取得

$targetVnet = Get-AzVirtualNetwork -Name $TargetVirtualNetworkName -ResourceGroupName $TargetResourceGroup

if (-not $targetVnet) {
    Write-Error "Target Virtual Network '$TargetVirtualNetworkName' not found in resource group '$TargetResourceGroup'."
    exit
}

# ターゲットサブネットの取得

$targetSubnet = $targetVnet.Subnets | Where-Object { $_.Name -eq $TargetSubnetName }

if (-not $targetSubnet) {
    Write-Error "Target Subnet '$TargetSubnetName' not found in VNet '$TargetVirtualNetworkName'."
    exit
}

# レプリケーション対象エンティティの取得 (On-Premise Item)


# 通常はNew-AzRecoveryServicesAsrReplicationProtectedItemで直接指定


# または、Discover-AzRecoveryServicesAsrVM cmdletで検出された項目を使用


# このステップは環境とASRのバージョンによって異なります。


# 以下は、概念的なプロセスを示しています。

try {

    # レプリケーションの有効化コマンド（例: VMware VMの場合）

    Write-Host "Enabling replication for VM '$VMName'..."
    $replicationJob = New-AzRecoveryServicesAsrReplicationProtectedItem -ProtectableItem $OnPremVmId `
        -Name $VMName `
        -Policy $policy `
        -Vault $vault `
        -Fabric $fabric `
        -RecoveryAzureStorageAccountId (Get-AzStorageAccount -Name $TargetStorageAccount -ResourceGroupName $ResourceGroupName).Id `
        -RecoveryAzureNetworkId $targetVnet.Id `
        -RecoveryAzureSubnetId $targetSubnet.Id `
        -TargetDiskType $TargetDiskType `
        -OSDiskName "osdisk_for_$VMName" `
        -OSDiskStorageAccountType $TargetDiskType # Add other required parameters as per your setup (e.g., TargetManagedDiskType)

    Write-Host "Replication enabled. Job ID: $($replicationJob.ID)"

    # ジョブの完了を待機することも可能: Wait-AzRecoveryServicesAsrJob -Job $replicationJob

} catch {
    Write-Error "Failed to enable replication for VM '$VMName': $($_.Exception.Message)"
}

# コメント:


# 入力: $VMName, $OnPremVmId, $TargetResourceGroup, $TargetStorageAccount, $TargetVirtualNetworkName, $TargetSubnetName, $TargetDiskType, $vault, $policy, $fabric


# 出力: レプリケーションジョブオブジェクト


# 前提: Recovery Services Vault, Configuration Server, ターゲットResourceGroup/StorageAccount/VirtualNetwork/Subnetが事前に作成されている。Mobility ServiceがVMにインストール済み。


# 計算量: ネットワークI/OとAzure API呼び出しによる。レプリケーションの初期同期はデータ量に比例して時間がかかる。


# メモリ条件: PowerShell実行環境の標準的なメモリ。

3. 運用監視

3.1. 可観測性 (Observability)

  • Azure Monitor: ASRはAzure Monitorと統合されており、Recovery Services vaultのメトリックとログを収集できます。レプリケーションの状態、RPOの健全性、データ転送量、Configuration ServerのCPU/メモリ使用率などを監視します[1]。

  • Azure Alerts: レプリケーションの停止、RPO違反、Configuration Serverのハートビート喪失などの重要なイベントに対して、Azure Alertsを設定し、メール、SMS、webhookなどで通知を受け取ることができます。

  • Recovery Services vaultの組み込み監視: vaultの「レプリケートされたアイテム」ビューで、各VMのレプリケーション状態、最新の回復ポイント、RPO、データ変更率などをリアルタイムで確認できます。

3.2. ログ管理

  • Azure Activity Log: Recovery Services vaultに対するすべての管理操作（ポリシー変更、フェールオーバー実行など）はActivity Logに記録されます。

  • Azure Diagnostic Settings: Recovery Services vaultの診断設定を構成し、ログデータをLog Analyticsワークスペースに送信することで、詳細なクエリやダッシュボード作成が可能になります。

  • Configuration Serverのログ: オンプレミスのConfiguration Serverは、レプリケーションプロセスに関する詳細なログを保持しています。問題発生時にはこれらのログも調査対象となります。

3.3. SLAとDR計画のテスト

  • SLA: ASR自体には特定のSLAは提供されていませんが、フェールオーバー先のAzure VMのSLA（例えば、可用性セット内の2つ以上のインスタンスで99.95%）が適用されます。DR計画全体のSLAはRTO（目標復旧時間）とRPO（目標復旧時点）によって定義され、これらはRecovery Services vaultのポリシーと整合させる必要があります。

  • DR訓練（テストフェールオーバー）: 定期的なDR訓練は不可欠です。ASRのテストフェールオーバー機能を利用すると、本番環境に影響を与えることなく、分離されたAzure仮想ネットワークにレプリケートされたVMを起動し、アプリケーションの動作確認を行うことができます[6]。

    • 重要: テストフェールオーバーは、RTOとRPOを実際に測定し、計画の有効性を確認する唯一の方法です。少なくとも年に一度、またはシステムの大きな変更後に実施することが推奨されます。

4. セキュリティ

Azure Site Recoveryにおけるセキュリティは、データ保護、ネットワーク分離、認証・認可の3つの側面から考慮されます。

4.1. データ保護

  • 転送中のデータ暗号化: オンプレミスからAzureへのレプリケーションデータは、HTTPS/TLS 1.2+ を用いて暗号化されたチャネルで転送されます。

  • 保存時のデータ暗号化: Azureにレプリケーションされたデータは、Azure Storageの保存時の暗号化（Storage Service Encryption）によって自動的に暗号化されます。これはMicrosoftマネージドキーまたはカスタマーマネージドキー（CMK）を選択できます。

  • 整合性と復旧: Recovery Services vaultは回復ポイントを保持し、データの整合性を確保します。

4.2. ネットワークセキュリティと分離

  • プライベートエンドポイント: Recovery Services vaultへのトラフィックをAzureのプライベートバックボーンネットワーク経由に限定するために、プライベートエンドポイントを設定できます[5]。これにより、インターネット経由のデータ転送を防ぎ、セキュリティを強化します。オンプレミスからプライベートエンドポイントへの接続には、Azure ExpressRouteやVPN GatewayとプライベートDNSゾーンを組み合わせます。

  • ネットワークセキュリティグループ (NSG): フェールオーバー先のAzure Virtual Networkでは、NSGを適用してインバウンド/アウトバウンドトラフィックを厳密に制御します。必要なポートのみを開放し、最小権限の原則を適用します。

  • Azure Firewall: 複数VNetやスポークVNet構成の場合、Azure Firewallを導入してネットワーク間のトラフィックを検査・制御します。

4.3. アイデンティティと権限境界

  • Microsoft Entra ID (旧 Azure AD): Azureリソースへのアクセス制御はMicrosoft Entra IDによって行われます。

  • Azure ロールベースのアクセス制御 (RBAC):

    • Recovery Services Contributor: Recovery Services vaultに対する完全な管理権限を持ちますが、Azureリソースの作成権限はありません。ASRの運用管理者に付与します。

    • Contributor: Recovery Services vaultを含むAzureリソースに対する広範な権限を持ちます。ASRのデプロイや管理に必要ですが、権限が広すぎるため最小限に留めるべきです。

    • カスタムロール: 必要に応じて、特定の操作のみを許可するカスタムロールを定義します。

  • マネージドID: Configuration Serverやその他AzureリソースがAzure APIにアクセスする際に、資格情報管理を不要にするマネージドID（Managed Identity）を使用します。これにより、セキュリティ資格情報の漏洩リスクを低減します。

  • 条件付きアクセス (Conditional Access, CA): 管理者がAzure Portalにアクセスする際、多要素認証（MFA）を強制したり、特定の場所からのアクセスのみを許可したりするなど、高度なアクセス制御を適用します。

  • Microsoft Defender for Cloud: Azureサブスクリプション全体、およびフェールオーバーされたAzure VMのセキュリティ状態を継続的に監視します。ASR環境においても、Configuration Serverやフェールオーバー後のVMに対する脆弱性評価や脅威検出に活用できます。

5. コスト

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

  • ASRインスタンス料金: 保護対象となるVMWare VMや物理サーバーの数に基づいて課金されます。最初の31日間は無料で、それ以降は保護インスタンスあたり月額料金が発生します[2]。2024年6月12日時点では、保護されている各インスタンスに対して1か月あたり$25が課金されます。

  • ストレージコスト: レプリケートされたデータが保存されるAzure Storageアカウント（キャッシュストレージおよびマネージドディスク）の料金が発生します。これはデータ量、ディスクの種類（Standard HDD, Standard SSD, Premium SSD）、レプリケーションの種類（LRS, GRS, ZRS）によって異なります。

  • ネットワークコスト:

    • データ転送コスト: オンプレミスからAzureへのデータ転送（インバウンド）は無料ですが、DR訓練やフェールバック時にAzureからオンプレミスへのデータ転送（アウトバウンド）には料金が発生します。

    • VPN/ExpressRoute: オンプレミスとAzure間の接続にVPN GatewayやExpressRouteを使用する場合、その料金が発生します。

  • フェールオーバー後のコンピューティングコスト: 災害発生時にAzureでVMを起動すると、そのVMのコンピューティング料金が発生します。

コスト最適化

  • 不要なVMの保護を避ける: DR計画の範囲を厳密に定義し、本当に必要なVMのみを保護対象とします。

  • RPOとRTOのバランス: レプリケーション頻度（RPO）を厳しくすると、データ変更量が増え、ストレージやネットワークコストが増加する可能性があります。ビジネス要件に合った最小限のRPOを設定します。

  • ストレージタイプの選択: レプリケーションターゲットのディスクの種類を慎重に選択します。RPO要件が緩い非ミッションクリティカルなVMには、Standard HDDディスクを使用することでコストを削減できます。

  • Reserved Instances (予約インスタンス): フェールオーバー後にAzure VMが恒久的に稼働する可能性がある場合、Azure Reserved VM Instancesを事前に購入することで、コンピューティングコストを大幅に削減できます。

  • ハイブリッド特典 (Azure Hybrid Benefit): Windows ServerやSQL Serverのライセンスをオンプレミスで保持している場合、Azure Hybrid Benefitを適用することで、Azure VMのライセンス費用を削減できます。

  • DR訓練のスケジューリング: テストフェールオーバー中に起動するAzure VMの稼働時間を最小限に抑えるように訓練計画を立てます。

6. 落とし穴と注意点

  • 構成サーバーのサイジング: Configuration Serverのサイジングが不適切だと、レプリケーションパフォーマンスが低下したり、サービスが停止したりする可能性があります。保護対象VMの数やデータ変更率に応じて適切にスケールアップまたはスケールアウトが必要です[1]。

  • ネットワーク帯域幅: オンプレミスからAzureへの十分なネットワーク帯域幅が確保されていないと、RPOが遵守できなかったり、初期レプリケーションに時間がかかったりします。推奨帯域幅を事前に計算し、確保してください。

  • IPアドレス計画: フェールオーバー先のAzure Virtual NetworkのIPアドレス計画は、オンプレミス環境と重複しないように、かつアプリケーションが適切に動作するように慎重に行う必要があります。DNS設定も重要です。

  • アプリケーション整合性: アプリケーション整合性スナップショットは、OSおよびアプリケーションの整合性を確保するために重要ですが、I/O負荷がかかるため、頻度を適切に設定する必要があります。特に古いOSやディスクI/Oの高いアプリケーションでは注意が必要です。

  • フェールバックの複雑性: 災害からの復旧後、オンプレミス環境に戻す「フェールバック」は、Azureからオンプレミスへのデータ転送が必要であり、追加の設定や考慮が必要です。フェールバックの計画もDR計画の一部として含めるべきです。

  • 定期的なDR訓練の怠り: DR計画は、実際にテストされて初めてその有効性が確認されます。定期的なテストフェールオーバーを怠ると、いざという時に機能しない可能性があります[6]。

7. まとめ

Azure Site Recoveryは、オンプレミス環境の災害復旧計画をAzureクラウドで実現するための強力なソリューションです。本ガイドでは、アーキテクチャの理解から、PowerShellによる設定手順、継続的な運用監視、堅牢なセキュリティ対策、そしてコスト最適化戦略までを網羅的に解説しました。

ASRを効果的に導入するためには、各コンポーネントの役割、レプリケーションプロセスの理解、そして何よりも定期的なDR訓練が不可欠です。本記事で示したガイドラインとベストプラクティスを参考に、貴社の事業継続性を確実にするためのDR計画を策定・実行してください。

根拠情報: [1] Microsoft Learn. “Azure Site Recovery for VMware to Azure overview”. 最終更新日: 2024年5月30日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-vmware-to-azure [2] Microsoft Azure. “Azure Site Recovery の料金”. 最終確認日: 2024年6月12日. https://azure.microsoft.com/ja-jp/pricing/details/site-recovery/ [3] Microsoft Learn. “Azure Site Recovery のセキュリティ”. 最終更新日: 2023年12月26日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-security [4] Microsoft Learn. “Azure Site Recovery 用 PowerShell を使用した管理”. 最終更新日: 2023年10月27日. https://learn.microsoft.com/ja-jp/azure/site-recovery/powershell-help-site-recovery [5] Microsoft Learn. “VMware/物理サーバーのレプリケーションのためにプライベート エンドポイントを設定する”. 最終更新日: 2024年1月2日. https://learn.microsoft.com/ja-jp/azure/site-recovery/vmware-physical-private-link [6] Microsoft Learn. “Azure でのディザスター リカバリー ドリルのテスト フェールオーバー”. 最終更新日: 2024年3月28日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-test-failover-to-azure

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

コメント

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