Azure Site Recovery は、障害発生時にワークロードを利用できるように設計された、仮想マシンのマネージド レプリケーションおよびフェールオーバー サービスです。 プライマリ サイトからセカンダリの場所にワークロードを継続的にレプリケートし、データ損失とダウンタイムを最小限に抑えます。 計画的なメンテナンスや予期しない中断が発生した場合は、フェールオーバーとフェールバックのプロセスを調整します。 このサービスは、オンプレミス環境とAzure VM のディザスター リカバリーをサポートし、組織がビジネス継続性を維持するのに役立ちます。
Azureを使用する場合、信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな潜在的な障害や問題に対するAzure Site Recovery回復性を確保する方法について説明します。 また、Azure Site Recovery サービス レベル アグリーメント (SLA) に関する重要な情報も示します。
注
このドキュメントでは、Azure Site Recovery サービス自体が、さまざまな問題に対してどのように回復可能であるか、または可能であるかについて説明します。 Azure Site Recoveryを使用して VM やその他の資産を保護する方法については説明しません。 Azure Site Recoveryの使用方法については、「About Site Recoveryを参照してください。
信頼性のための運用環境のデプロイに関する推奨事項
運用環境のワークロードでSite Recoveryを使用する場合は、次のアクションを実行することをお勧めします。
- ターゲット リージョンとしてレプリケーション用の Recovery Services ボールトを配置します。
- Azure 間のディザスター リカバリーには、データ変更率が高い VM に対して High Churn を使用します。 高チャーンのサポートにより、目標復旧ポイント (RPO) が向上し、多くの大規模なデータベース ワークロードのレプリケーションが可能になります。
- Azure間でのディザスター リカバリーのために、キャッシュ ストレージ アカウントをゾーン冗長ストレージ (ZRS) を使用するように構成します。
- ディザスター リカバリー (DR) 訓練の一環として、定期的にテスト フェールオーバーを実行します。 DR ドリルは、レプリケーションとフェールオーバー プロセスが正常であることを確認するために、四半期ごとに、または 2 回実行する必要があります。
- オンデマンド容量予約を使用して、フェールオーバーの対象リージョンでコンピューティング リソースを確実に使用できるようにします。
- モビリティ エージェントの自動更新を有効にします。
- レプリケーションの正常性を監視し、問題が発生した場合に通知されるようにアラートを構成します。
信頼性アーキテクチャの概要
Azure Site Recoveryを使用する場合は、レプリケートされる VM を表す source と target を定義します。
- source には、Azure VM、オンプレミスの物理サーバー、VMware VM、Hyper-V VM など、サポートされている別のソースの VM またはサーバーを指定できます。
- target は常にAzure VM です。 Azure対Azure VM レプリケーションの場合、ターゲットはソース VM とは異なるリージョンまたは可用性ゾーンにすることができます。
次のような他のリソースのデプロイと構成は、お客様が行う必要があります。
Recovery Services ボールトは、Site Recovery がレプリケーション構成設定の格納に使用します。 保管庫には、レプリケートされたデータは保存されません。 コンテナーの冗長性の構成はSite Recoveryにとって重要ではありませんが、Azure Backupに同じコンテナーを使用する場合は重要です。
Vaultは、次のような追加構成を含むことができます。
- レプリケーション ポリシー。スナップショットの頻度と保持期間の長さを構成します。
- 復旧計画。マシンのフェールオーバー順序を調整し、スクリプトと手動アクションを含めることができます。 復旧計画は、調整された方法でフェールオーバーする必要がある複数の層 (アプリケーション層やデータベース層など) を持つワークロードに特に役立ちます。
AzureからAzureへのレプリケーションの場合、ターゲットにレプリケートされる前にソース データのコピーをリージョンに格納するcache ストレージ アカウント。 キャッシュ ストレージ アカウントの冗長性構成は、可用性ゾーンの停止中の信頼性に影響する可能性があります。
注
このガイドでは、Azure Site RecoveryのAzureベースのコンポーネントの信頼性とレプリケーション関係に焦点を当てます。 オンプレミス環境または別のクラウド プロバイダーからデータまたは VM をレプリケートする場合は、Azure外のコンポーネントの信頼性も考慮する必要があります。
デプロイするコンポーネントの詳細については、以下を参照してください。
- Azure間ディザスター リカバリー アーキテクチャ
- Hyper-VからAzureへのディザスターリカバリーアーキテクチャ
- VMware のAzure災害復旧アーキテクチャ
- 物理サーバーからAzureへのディザスターリカバリーアーキテクチャ
コア Site Recovery サービスは、Microsoft が管理するインフラストラクチャで実行されます。 このドキュメントでは、これらのコンポーネントをまとめて、core Site Recovery サービスとします。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。
Site Recovery操作を再試行することで、レプリケーション プロセス中に発生した一時的な障害を自動的に処理します。 Azure Site Recoveryの一時的な障害処理を構成する必要はありません。
可用性ゾーンの障害に対する回復性
Availability zones は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
可用性ゾーンの障害時Azure Site Recoveryレプリケーションの動作を理解するには、サービスの次のコンポーネントを考慮する必要があります。
Core Site Recovery service: Site Recovery サービスは、サポートされているリージョンでの可用性ゾーンの障害に対する回復性を備えて設計されています。 サービスの内部コンポーネントは、顧客の構成を必要とせず、ゾーンの冗長性を自動的にサポートします。
Recovery Services コンテナー: コンテナーには構成データが格納されます。 Site Recoveryがゾーンの回復性をサポートしているリージョンでは、コンテナー内の構成データもゾーン回復性があります。
Cache ストレージ アカウント: Azure対Azureレプリケーションの場合は、ZRS 層を使用してキャッシュ ストレージ アカウントをデプロイすることで、キャッシュ ストレージ アカウントがゾーン冗長であることを確認する必要があります。
ローカル冗長ストレージ (LRS) Azure Storageレプリケーション層をキャッシュ ストレージ アカウントに使用する場合、ゾーンが失敗した場合、Site Recoveryは最近変更されたデータをターゲットにレプリケートできない可能性があります。
注
Azure Site Recoveryは、異なる可用性ゾーン内の VM 間でフェールオーバーするのに役立ちます。 詳細については、「可用性ゾーン間での Azure VM の災害復旧の有効化」を参照してください。
Requirements
リージョンのサポート:
コア サイト リカバリー サービスとリカバリー サービス ボールト: Azure Site Recovery は、次のリージョンでゾーン回復性を備えています。
南北アメリカ ヨーロッパ 中東 アジア太平洋 チリ中部 オーストリア東部 イスラエル中部 インドネシア中部 メキシコ中部 イタリア北部 西日本 米国西部 3 ポーランド中部 マレーシア西部 スペイン中部 ニュージーランド北部 Azure Site Recoveryは現在、
に可用性ゾーンのサポートをデプロイしています。 まだゾーン回復性がないリージョンでは、ゾーンの障害が操作に影響する可能性があります。 キャッシュ ストレージ アカウント: ZRS ストレージ アカウントは、すべての可用性ゾーン対応リージョンにデプロイできます。
費用
Site Recoveryは、可用性ゾーンの構成に関係なく、保護された VM インスタンスの数に基づいて課金されます。 詳細については、「Azure Site Recovery pricing」を参照してください。
可用性ゾーンのサポートを設定する
Core Site Recovery service: コア Site Recovery サービスでゾーンの回復性を構成しません。 Microsoft は、サポートされているリージョンでゾーンの回復性を提供します。
Microsoft が後でリージョンのゾーンの回復性を有効にした場合、Site Recovery リソースはゾーンの回復性の恩恵を自動的に受けます。 実行すべきアクションはありません。
Recovery Services コンテナー: Recovery Services コンテナーでは冗長性のレベルを構成できますが、この構成設定はSite Recoveryには使用されません。 Site Recoveryを使用する場合は、ゾーン冗長性のためにボルトを構成する必要はありません。
Cache ストレージ アカウント: Azure対Azureレプリケーションを使用する場合は、キャッシュ ストレージ アカウントを作成し、適切な冗長性レベルで構成する必要があります。 ゾーン冗長にするには、ZRS レプリケーションタイプを設定します。 詳細については、「reliability in Azure Blob Storage」を参照してください。
すべてのゾーンが正常な場合の動作
このセクションでは、コア サービスの可用性ゾーンがサポートされているリージョンでSite Recoveryが使用され、キャッシュ ストレージ アカウントが ZRS を使用するように構成され、すべての可用性ゾーンが動作している場合に想定される内容について説明します。
ゾーン間操作: レプリケーション プロセスでは、複数の可用性ゾーンのインフラストラクチャを使用して、レプリケーション ジョブをトリガーおよび実行できます。 このインフラストラクチャは、サービスによって透過的に管理されます。
クロス ゾーン データ レプリケーション: Site Recovery とAzure Storageは、次のようにゾーン データ レプリケーションを処理します。
Site Recovery configuration: Site Recovery は、ボールトが LRS を使用するように構成されている場合でも、複数のゾーンに構成データをレプリケートします。
Cache ストレージ アカウント: キャッシュ ストレージ アカウントが ZRS を使用するように構成されている場合、Azure Storageはキャッシュされたデータをゾーン間で同期的にレプリケートします。
ゾーン障害時の動作
このセクションでは、コア サービスの可用性ゾーンがサポートされているリージョンでSite Recoveryが使用され、ZRS を使用するようにキャッシュ ストレージ アカウントが構成され、可用性ゾーンの停止が発生した場合に想定される内容について説明します。
注
障害が発生したゾーンにソース VM が含まれている場合は、ターゲットへのフェールオーバーをトリガーする必要があります。 詳細については、以下を参照してください:
- 検出と応答: Site Recovery プラットフォームは、可用性ゾーンの障害を自動的に検出し、応答を開始します。 Site Recovery サービス自体のゾーン フェールオーバーを開始するために手動による介入は必要ありません。 ただし、ゾーンの停止がソース VM に影響する場合は、 VM のフェールオーバーを開始することが必要になる場合があります。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、Azure Service Health を使用して、ゾーン障害を含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することができます。
アクティブな要求: アクティブなレプリケーション ジョブへの影響は、レプリケーションの種類によって異なります。
Azure VM のゾーン間レプリケーションとリージョン間レプリケーション:ソース インスタンスまたはターゲット インスタンスのいずれかが障害ゾーンにある場合、レプリケーションは両方のインスタンスが再び使用可能になるまで一時停止します。
障害が発生したゾーンにソースまたはターゲット VM が含まれていない場合、キャッシュ ストレージ アカウントが ZRS を使用するように構成されている場合、レプリケーションは引き続き実行されます。
オンプレミスから Azure: ターゲット インスタンスが障害が発生したゾーンにある場合、インスタンスが再び使用可能になるまでレプリケーションが一時停止します。
障害が発生したゾーンにターゲット VM が含まれていない場合、レプリケーションは引き続き実行されます。
予想されるデータ損失: ゾーン障害時にデータ損失は発生しません。
予想されるダウンタイム: 障害が発生したゾーンにソース VM またはターゲット VM が含まれている場合、レプリケーションは両方のインスタンスが再び使用可能になるまで一時停止します。
Redistribution: Site RecoveryとAzure Storageはゾーン障害に自動的に適応します。
Site Recoveryコア サービス: Site Recovery サービスは、正常な可用性ゾーン内のインフラストラクチャを自動的に使用してレプリケーションを実行します。 実行すべきアクションはありません。
Cache ストレージ アカウント: Azure Storage は、キャッシュ データの要求を正常なゾーンに自動的にルーティングします。
ゾーンの回復
影響を受ける可用性ゾーンが復旧すると、Site Recoveryは、ゾーンの停止中に一時停止した可能性のあるレプリケーション ジョブを自動的に再開します。
ゾーンの停止中にフェールオーバーしたすべてのサーバーまたは VM のフェールバックを開始する責任があります。 詳細については、以下を参照してください:
Azure VM のゾーン間レプリケーションとリージョン間レプリケーション:Azure VMをプライマリリージョンへフェールバック
オンプレミスからAzureへのレプリケーション:
- 物理サーバーからAzureへのレプリケーション:物理サーバーからAzureへのディザスターリカバリーアーキテクチャ
- Hyper-V から Azure へのレプリケーション: ディザスター リカバリー アーキテクチャHyper-V から Azure への災害復旧
- VMware から Azure へのレプリケーション:オンプレミスのディザスターリカバリー フェイルオーバー/フェイルバックについて
ゾーンエラーのテスト
Site Recovery プラットフォームは、内部コンポーネントのゾーンの回復性を管理します。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。
VM のフェールオーバーと全体的な応答手順をテストする必要がある、定期的なディザスター リカバリー訓練を実行することが重要です。 運用環境への影響を避けるために DR ドリルを設計します。 詳細については、以下を参照してください:
Azure VM のゾーン間レプリケーションとリージョン間レプリケーション: Azure VM のディザスター リカバリー訓練を実行します
オンプレミスからAzureへのレプリケーション:
- 物理的なシステムをAzureにレプリケーション:Azureへのテストフェールオーバー(ディザスターリカバリー訓練)を実行します
Hyper-V から Azure へのレプリケーション: ディザスター リカバリーの訓練を Azure で実行します - VMware からAzureへのレプリケーション:Azureでディザスターリカバリー訓練を実施します
リージョン全体の障害に対する回復性
AzureからAzureへのレプリケーションの場合、Site Recoveryは、正常なターゲット リージョンへの VM のフェールオーバーを有効にすることで、リージョンの障害に対する回復性を提供するように設計されています。 詳細については、「 Azure VM を別のAzure リージョンにレプリケートするを参照してください。
考慮事項
Vault リージョン: Recovery Services コンテナーは、選択した特定のAzure リージョンにデプロイされます。 ボールトのリージョンは重要な選択です。 レプリケーションは、ボールトのリージョンでの障害が発生している間に続行できます。 ただし、フェールオーバーやフェールバックを含むSite Recovery管理操作は、リージョンが復旧するまで使用できません。
ターゲットリージョンにボールトをデプロイすることで、ソースリージョンの障害時にフェールオーバーと復旧操作へのアクセスを確保し、第3リージョンでの障害がフェールオーバーと復旧操作に影響を与えるのを防ぐことができます。
注
通常、ターゲット リージョンとして使用するリージョン内に保管庫がある場合、フェールオーバー後にレプリケーションを再確立すると、その保管庫は新しいソース リージョンに設定されます。 その後、そのリージョンで問題が発生した場合は、両方のリージョンが正常になるまでフェールバックを実行できないことがあります。
容量予約: ターゲット リージョンが必要な VM の種類をサポートしていること、およびワークロードに使用可能な容量があることを確認する責任があります。 オンデマンド容量予約を使用することをお勧めします。これにより、フェールオーバーが発生した場合にワークロードでコンピューティング リソースを使用できるようになります。
複数リージョンのサポートを構成する
Recovery Services ボールト: ボールトのリージョンを選択する必要があります。 詳細については、前の 考慮事項 のセクションを参照してください。
Recovery Services コンテナーを使用すると、冗長性レベルを構成できますが、この構成設定はSite Recoveryには使用されません。 Site Recoveryを使用する場合は、ボールトを地理的冗長性のために構成する必要はありません。
キャッシュ ストレージ アカウント: キャッシュ ストレージ アカウントはレプリケート前のデータの一時的な場所としてのみ使用されるため、GRS を使用するように構成しないでください。
リージョン障害時の動作
リージョン障害時の Site Recovery コア サービスの具体的な動作は、障害が発生するリージョンによって異なります。
ソース リージョンの障害: Azure 間のレプリケーションでは、ソース リージョンが利用できないときにフェールオーバーを起動できます。
ソース リージョンは使用できないため、ソース リージョン内の VM が正常になるまでレプリケーションが停止します。
ターゲット リージョンでのエラー: ターゲット リージョンは使用できないため、レプリケーションは停止し、リージョンが正常になるまでターゲットにフェールオーバーすることはできません。
ボルトを含むリージョンでの障害: ボルトが (ソースまたはターゲット リージョンではなく) 3 番目のリージョンにデプロイされ、そのリージョンで障害が発生した場合、Site Recoveryはデータを引き続きレプリケートします。 ただし、ボルトが正常になるまで、フェールオーバーやフェールバックなどの操作を開始することはできません。
リージョンの復旧
リージョンの停止中にフェールオーバーしたすべてのサーバーまたは VM のフェールバックを開始する責任があります。 詳細については、以下を参照してください:
Azure VM のゾーン間レプリケーションとリージョン間レプリケーション:Azure VMをプライマリリージョンへフェールバック
オンプレミスからAzureへのレプリケーション:
- 物理サーバーからAzureへのレプリケーション:物理サーバーからAzureへのディザスターリカバリーアーキテクチャ
- Hyper-V から Azure へのレプリケーション: ディザスター リカバリー アーキテクチャHyper-V から Azure への災害復旧
- VMware から Azure へのレプリケーション:オンプレミスのディザスターリカバリー フェイルオーバー/フェイルバックについて
リージョン障害のテスト
VM のフェールオーバーと全体的な応答手順をテストする必要がある、定期的なディザスター リカバリー訓練を実行することが重要です。 運用環境への影響を避けるために DR ドリルを設計します。 詳細については、以下を参照してください:
Azure VM のゾーン間レプリケーションとリージョン間レプリケーション: Azure VM のディザスター リカバリー訓練を実行します
オンプレミスからAzureへのレプリケーション:
- 物理的なシステムをAzureにレプリケーション:Azureへのテストフェールオーバー(ディザスターリカバリー訓練)を実行します
Hyper-V から Azure へのレプリケーション: ディザスター リカバリーの訓練を Azure で実行します - VMware からAzureへのレプリケーション:Azureでディザスターリカバリー訓練を実施します
構成とレプリケーションに関する問題に対する回復性
ディザスター リカバリー ソリューションは、障害が発生する前に機能していることがわかっている場合にのみ信頼できます。 つまり、構成の問題や VM レプリケーションの正常性に関する問題など、問題が発生した場合にAzure Site Recoveryを監視することが重要です。 詳細については、「Monitor Azure Site Recovery」を参照してください。
レプリケーションの正常性に関する問題が通知されるように、Azure Monitorアラートを構成することをお勧めします。 詳細については、「Azure Site Recovery の組み込み Azure Monitor アラート」を参照してください。
サービス メンテナンスに対する回復性
Azureは、コア Site Recovery サービスの更新とメンテナンスを自動的に管理します。 メンテナンス操作ではダウンタイムは必要ありません。また、VM とサーバーのレプリケーションが中断されることはありません。
ただし、必要に応じてモビリティ エージェントを含め、VM とサーバー上のSite Recovery コンポーネントに更新プログラムを適用する必要があります。
Important
エージェントの自動更新を有効にすることを強くお勧めします。 エージェントのバージョンが 4 つ以上遅れている場合、レプリケーションは無効になり、ワークロードの回復可能性が損なわれます。
詳細については、「Site Recovery の Service 更新プログラム」を参照してください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのサービスレベルアグリーメント (SLA) を参照してください。
Azure Site Recoveryの場合、次の内容に対応する個別の SLA があります。
- サービスの可用性とは、保護されたインスタンスをフェールオーバーするために、Site Recoveryサービスが利用可能であることを意味します。 保護されたインスタンスは、セカンダリの場所にレプリケートされる VM または物理サーバーです。 この SLA の対象にするには、少なくとも 30 分ごとに失敗したフェールオーバー試行を再試行する必要があります。
- 目標復旧時間 (RTO) は、ユーザー (または作成したスクリプト) がフェールオーバーをトリガーしてからターゲット VM が実行されるまでの時間です。 今回は、手動のアクションまたはスクリプトの実行を除外します。
SLA は、セカンダリ リージョンで使用可能な十分な容量がある場合にのみ、サービス クレジットを提供します。