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

Tech

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

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

ディザスターリカバリー（DR）は、自然災害、サイバー攻撃、大規模なシステム障害などからビジネスの継続性を確保するために不可欠です。Azure Site Recovery (ASR) は、Azure VM、オンプレミスのHyper-V/VMware VM、物理サーバーのディザスターリカバリーをオーケストレーションする Azure サービスです[2]。本記事では、ASR を使用した DR 計画の策定、設定手順、運用監視、セキュリティ、コスト最適化、および注意点についてクラウドアーキテクトの視点から解説します。

アーキテクチャ

Azure Site Recovery を利用した Azure VM 間の DR (Azure-to-Azure DR) は、主要なワークロードが稼働するプライマリリージョンから、レプリケーション先のセカンダリリージョンへ非同期的にデータを複製するアーキテクチャを採用しています[1]。

主要コンポーネント

  • Recovery Services Vault: ASR の中心となる管理リソースであり、レプリケーションポリシー、回復計画、レプリケートされたアイテムを一元的に管理します[1]。

  • ソース Azure VM: DR の対象となるワークロードが稼働する仮想マシン。VMエージェントを通じてレプリケーションを処理します[1]。

  • キャッシュストレージアカウント: プライマリリージョンで発生したデータの変更を一時的に格納し、セカンダリリージョンへの効率的なレプリケーションを可能にします[1]。

  • ターゲットリソース: セカンダリリージョンに事前にプロビジョニングされるか、フェールオーバー時に作成される仮想ネットワーク、サブネット、IPアドレス、そしてレプリケートされたディスクを保持するマネージドディスクなどです[1]。

レプリケーションの流れ (Azure-to-Azure)

  1. ソースAzure VMのデータ変更が、VM拡張機能によってインターセプトされます[1]。

  2. 変更はキャッシュストレージアカウントに書き込まれます[1]。

  3. キャッシュストレージアカウントから、変更はターゲットリージョンのマネージドディスクに非同期的にレプリケートされます[1]。

  4. Recovery Services Vault は、レプリケーションの状態、復旧ポイント、および全体的なDR体制を監視します[1]。

flowchart TD
    subgraph Primary Region
        A["Azure VM(\"ソース\")"] --> B("VMエージェント");
        B --> C["キャッシュストレージアカウント"];
    end

    subgraph Secondary Region
        D["マネージドディスク (ターゲット)"]
        E["仮想ネットワーク (ターゲット)"]
        F["可用性セット/ゾーン (ターゲット)"]
    end

    G["Recovery Services Vault"]

    C -- |データ変更レプリケーション| D;
    G -- |レプリケーションポリシー管理| A;
    G -- |回復計画オーケストレーション| D, E, F;
    A -- |DR対象| G;
    D -- |フェールオーバー時VM作成| F;

図1: Azure Site Recovery (Azure-to-Azure) アーキテクチャ

設定手順

ここでは、Azure VM 間で Site Recovery を構成する PowerShell スクリプトの例を示します。

# 事前準備: Azure PowerShellモジュールのインストールと認証


# Install-Module -Name Az -AllowClobber -Scope CurrentUser


# Connect-AzAccount

# 変数の定義 (ご自身の環境に合わせて変更してください)

$resourceGroupName = "ASR-DR-RG"
$locationPrimary = "japaneast" # プライマリリージョン
$locationSecondary = "japanwest" # セカンダリリージョン
$vaultName = "MyASRVault"
$policyName = "MyReplicationPolicy"
$sourceVmName = "WebAppVM01" # 保護対象のVM名
$sourceVmRgName = "Source-VM-RG" # 保護対象VMのリソースグループ名
$targetResourceGroup = "ASR-Target-RG" # フェールオーバー先のリソースグループ名 (新規作成または既存指定)
$targetVnetName = "Target-VNet" # フェールオーバー先の仮想ネットワーク名 (新規作成または既存指定)
$targetSubnetName = "default" # フェールオーバー先のサブネット名

# 1. Recovery Services Vault の作成

Write-Host "Recovery Services Vault を作成中..."
New-AzResourceGroup -Name $resourceGroupName -Location $locationPrimary -Force | Out-Null
$vault = New-AzRecoveryServicesVault -Name $vaultName -ResourceGroupName $resourceGroupName -Location $locationPrimary

Set-AzRecoveryServicesAsrVaultContext -Vault $vault | Out-Null
Write-Host "Recovery Services Vault '$vaultName' が作成されました。"

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


# RPO (目標復旧時点) を5分に設定、復旧ポイント保持期間を24時間に設定

Write-Host "レプリケーションポリシー '$policyName' を作成中..."
$policy = New-AzSiteRecoveryReplicationPolicy -Name $policyName `
    -RecoveryPointRetentionInHours 24 `
    -ApplicationConsistentSnapshotFrequencyInHours 4 `
    -RpoInSeconds 300 # 5分
Write-Host "レプリケーションポリシー '$policyName' が作成されました。"

# 3. 保護対象VMの情報取得

Write-Host "ソースVM '$sourceVmName' の情報を取得中..."
$sourceVm = Get-AzVM -Name $sourceVmName -ResourceGroupName $sourceVmRgName
if ($null -eq $sourceVm) {
    throw "ソースVM '$sourceVmName' が見つかりません。"
}
Write-Host "ソースVM '$sourceVmName' の情報取得完了。"

# 4. ターゲットリソースグループの作成 (必要であれば)

Write-Host "ターゲットリソースグループ '$targetResourceGroup' を確認/作成中..."
if (-not (Get-AzResourceGroup -Name $targetResourceGroup -ErrorAction SilentlyContinue)) {
    New-AzResourceGroup -Name $targetResourceGroup -Location $locationSecondary -Force | Out-Null
    Write-Host "ターゲットリソースグループ '$targetResourceGroup' を作成しました。"
} else {
    Write-Host "ターゲットリソースグループ '$targetResourceGroup' は既に存在します。"
}

# 5. ターゲット仮想ネットワークの取得 (既存または新規作成)

Write-Host "ターゲット仮想ネットワーク '$targetVnetName' を取得中..."
$targetVnet = Get-AzVirtualNetwork -Name $targetVnetName -ResourceGroupName $targetResourceGroup -ErrorAction SilentlyContinue
if ($null -eq $targetVnet) {

    # 簡略化のため、ここでは新規作成のVNetとサブネットの例を示す。


    # 実際にはより詳細なネットワーク設計が必要です。

    $targetVnet = New-AzVirtualNetwork -Name $targetVnetName -ResourceGroupName $targetResourceGroup -Location $locationSecondary `
        -AddressPrefix "10.1.0.0/16" | Out-Null
    Add-AzVirtualNetworkSubnetConfig -Name $targetSubnetName -VirtualNetwork $targetVnet `
        -AddressPrefix "10.1.0.0/24" | Set-AzVirtualNetwork | Out-Null
    $targetVnet = Get-AzVirtualNetwork -Name $targetVnetName -ResourceGroupName $targetResourceGroup
    Write-Host "ターゲット仮想ネットワーク '$targetVnetName' を新規作成しました。"
} else {
    Write-Host "ターゲット仮想ネットワーク '$targetVnetName' は既に存在します。"
}

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

Write-Host "VMレプリケーションを有効化中... (最大15分程度かかる場合があります)"
Enable-AzSiteRecoveryVMReplication -Policy $policy `
    -VirtualMachine $sourceVm `
    -RecoveryResourceGroupName $targetResourceGroup `
    -RecoveryAzureStorageAccountName (Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name "asr" -ErrorAction SilentlyContinue).StorageAccountName ` # キャッシュストレージアカウント (既存を使用するか、ASRが自動作成)
    -RecoveryVirtualNetworkId $targetVnet.Id `
    -RecoverySubnetName $targetSubnetName `
    -AsJob | Out-Null # バックグラウンドで実行
Write-Host "VMレプリケーションの有効化コマンドが発行されました。進行状況はAzureポータルで確認してください。"

# 7. 回復計画の作成 (オプションだが推奨)


# 必要に応じて、複数のVMやカスタムスクリプトを含む回復計画を作成します。


# New-AzSiteRecoveryRecoveryPlan -Name "MyWebAppDRPlan" -PrimaryFabric "Azure" -RecoveryFabric "Azure" `


#     -ReplicatedProtectedItem @($replicatedItem) ` # Enable-AzSiteRecoveryVMReplicationの結果から取得


#     -RecoveryPlanType "VMwareToAzure" # または "AzureToAzure"

Write-Host "設定手順が完了しました。"

コード1: PowerShellによるAzure Site Recoveryの設定

運用監視

DR計画の成功は、適切な運用監視にかかっています。

  • RTO/RPOの監視: ASR は、Recovery Services Vault のダッシュボードでレプリケーションの状態と RPO を監視できます。定義した目標復旧時点 (RPO) と目標復旧時間 (RTO) が満たされているか、定期的に確認します[2]。

  • DRドリル（テストフェールオーバー）: 定期的にテストフェールオーバーを実施し、回復計画の有効性を検証します[7]。これは、運用環境に影響を与えずに実行できます。

  • アラートと通知: Azure Monitor と連携し、レプリケーションの遅延、エラー、状態の変化をメール、SMS、Webhook などを通じて通知するように設定します[5]。

  • ログ分析: Azure Activity Log と Azure Monitor Log Analytics を使用して、ASR 操作のログを収集・分析し、問題のトラブルシューティングや監査に活用します[5]。

  • SLA: Microsoft は ASR サービス自体に 99.9% の SLA を提供しています。ただし、これは AS Rサービスが利用可能であることに対するものであり、レプリケートされたワークロードの RPO/RTO は、構成と設計に依存します。

セキュリティ

Azure Site Recovery は、多層的なセキュリティ機能を提供し、DR 環境の保護を支援します[5]。

  • アイデンティティと権限境界:

    • Azure Active Directory (Azure AD): Azure サブスクリプションとリソースへのアクセスを管理します。Recovery Services Vault へのアクセスも Azure AD を通じて認証されます。

    • Azure ロールベースのアクセス制御 (RBAC): Recovery Services Vault や関連リソースへのアクセス権限を最小限に制限します。「Recovery Services Contributor」または「Site Recovery Contributor」ロールは、ASR 関連の操作を実行するために必要な権限を提供します[5]。また、仮想マシン共同作成者、ネットワーク共同作成者など、フェールオーバー時にリソースをプロビジョニングするための追加のロールが必要になる場合があります。

    • Azure AD 条件付きアクセス (Conditional Access): 特定の条件（デバイスの状態、場所、サインインリスクなど）に基づいて、Recovery Services Vault への管理アクセスを制限できます。例えば、信頼できるネットワークからのアクセスのみを許可するように設定可能です。

  • 暗号化:

    • 保存時の暗号化: ASR によってレプリケートされたデータは、Azure Storage に保存される際に Azure Storage Service Encryption (SSE) によって自動的に暗号化されます[5]。カスタマーマネージドキー (CMK) を使用して、暗号化キーをAzure Key Vaultで管理することも可能です[5]。

    • 転送時の暗号化: データは、プライマリリージョンからセカンダリリージョンへの転送中に HTTPS を使用して暗号化されます[5]。

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

    • Private Link: Recovery Services Vault へのアクセスを Azure プライベートエンドポイント経由に限定し、パブリックインターネットからのアクセス経路を排除することで、セキュリティを強化できます[5]。

  • 脅威保護:

    • Azure Defender for Cloud: 保護された Azure VM に Azure Defender for Cloud を適用することで、セキュリティの脆弱性を継続的に監視し、脅威に対する保護を強化できます[5]。

    • Azure Policy: ASR 構成が組織のセキュリティおよびコンプライアンス要件に準拠していることを確認するために、Azure Policy を適用できます。

コスト

Azure Site Recovery のコストは、主に以下の要素によって構成されます[4]。

  • ASR 保護対象インスタンス料金: 保護対象の VM ごとに月額料金が発生します。最初の31日間は無料ですが、その後は保護対象のインスタンス数に応じて課金されます。例えば、Azure VM 間レプリケーションでは、1インスタンスあたり約3,800円/月（$25/月）が目安です[4]。

  • ストレージ料金: レプリケーションされたデータが保存されるターゲットリージョンのマネージドディスク (またはストレージアカウント) の料金。ソース VM のディスク容量と種類 (Standard HDD/SSD、Premium SSD) に応じて課金されます[4]。

  • ストレージトランザクション料金: レプリケーションプロセスで発生するストレージ操作（読み取り/書き込み）に対する料金[4]。

  • データ転送料金: リージョン間のデータ転送（アウトバウンド）に対する料金。レプリケーションの頻度とデータ変更量に比例します[4]。

コスト最適化戦略

  • 適切なストレージ層の選択: ターゲットリージョンのストレージは、フェールオーバー時まで実際にVMが稼働しないため、DR要件に基づいて費用対効果の高いストレージ（例: Standard HDD/SSD）を選択します[4]。

  • VM サイズの最適化: フェールオーバー後のVMのサイズは、必ずしもソースVMと同じである必要はありません。DR 時の最低限のパフォーマンス要件を満たす範囲で、より安価な SKU を選択することを検討します。これにより、フェールオーバー後の運用コストを削減できます[1]。

  • リザーブドインスタンス (RI): フェールオーバー後の VM にリザーブドインスタンスを適用することで、長期的なコストを大幅に削減できます。ただし、RI はフェールオーバー後に VM が実際に起動された場合にのみ適用される点に注意が必要です。

  • 不要なVMの保護解除: 保護の必要がなくなった VM は、速やかに ASR 保護を解除し、課金を停止します。

  • データ変更率の管理: レプリケーション時のデータ転送量を減らすために、VM 内での不要なデータ変更を最小限に抑えるようアプリケーションを最適化します。

落とし穴

DR計画とフェイルオーバープロセスには、いくつかの一般的な落とし穴があります。

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

    • IPアドレスの衝突: フェールオーバー先の仮想ネットワークで、ソースと同じ IP アドレスが使用されているか、または適切な IP アドレスが割り当てられるかを確認します。プライマリとセカンダリで異なるVNetを使用する場合、適切なIPマッピングが必要です。

    • DNS解決: フェールオーバー後のアプリケーションが、新しいIPアドレスで正しく名前解決されるように、DNS設定（Azure Private DNS Zone やカスタムDNSサーバーなど）を適切に構成する必要があります。

    • NVA/ロードバランサー: ネットワーク仮想アプライアンス (NVA) や Azure Load Balancer を使用している場合、DR サイトでも同様の構成がデプロイされ、トラフィックが正しくルーティングされることを確認します。

  • RTO/RPOの誤解: 設定された RPO と RTO がビジネス要件を満たしているか、また実際に達成可能かを定期的なテストフェールオーバーで検証することが重要です。理論値と実測値が異なる場合があります。

  • 依存関係の未考慮: 複数の VM やサービスが連携している場合、すべての依存関係を回復計画に含め、正しい起動順序やスクリプト実行順序を設定する必要があります[3]。データベースサーバー、アプリケーションサーバー、Webサーバーといった階層型アプリケーションの依存関係は特に重要です。

  • ストレージのボトルネック: ソース VM の IOPS 要件に対し、キャッシュストレージアカウントやターゲットディスクの性能が不足していると、レプリケーションの遅延やRPOの悪化を招く可能性があります。

  • テストフェールオーバーの怠り: 最も一般的な落とし穴は、テストフェールオーバーを十分に実施しないことです。回復計画は、実際に災害が発生したときに機能することを確認するために、定期的にテストする必要があります。

  • フェールバック計画の欠如: DR サイトへのフェールオーバーだけでなく、元のプライマリリージョンが復旧した際にワークロードを戻す（フェールバック）計画も重要です。ASR はフェールバックもサポートしていますが、その手順も検証しておく必要があります[7]。

まとめ

Azure Site Recovery は、Azure 環境における堅牢なディザスターリカバリー戦略を構築するための強力なツールです。アーキテクチャの理解、詳細な設定、継続的な運用監視、厳格なセキュリティ対策、そしてコスト最適化のバランスを考慮することが、効果的な DR 計画の鍵となります。特に、定期的なテストフェールオーバーを通じて回復計画の有効性を検証し、潜在的な落とし穴を事前に特定して対処することが、ビジネス継続性を確保するための最も重要なステップです。これらの要素を網羅することで、組織は予期せぬ障害発生時にも迅速かつ確実にシステムを回復できるようになります。

参考文献: [1] Microsoft. (2024年4月11日). Azure Site Recovery を使用した Azure VM ディザスター リカバリーのアーキテクチャ. [オンライン]. https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-architecture [2] Microsoft. (2024年4月11日). Azure Site Recovery とは. [オンライン]. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-overview [3] Microsoft. (2024年1月2日). 回復計画を作成する. [オンライン]. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-create-recovery-plan [4] Microsoft Azure Pricing. (2024年4月22日). Azure Site Recovery の料金. [オンライン]. https://azure.microsoft.com/ja-jp/pricing/details/site-recovery/ [5] Microsoft. (2024年4月11日). Azure Site Recovery のセキュリティに関する考慮事項. [オンライン]. https://learn.microsoft.com/ja-jp/azure/site-recovery/concepts-security [6] Microsoft. (2024年1月2日). Azure Resource Manager を使用して Azure VM のディザスター リカバリーを設定する PowerShell スクリプトの例. [オンライン]. https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-powershell [7] Microsoft. (2024年4月11日). Azure Site Recovery でオンプレミス VM のフェールオーバーとフェールバックを実行する方法. [オンライン]. https://learn.microsoft.com/ja-jp/azure/site-recovery/hyper-v-azure-failover-failback

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

コメント

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