Azure VMware Solution のビジネス継続性とディザスター リカバリー
このエンタープライズ規模のシナリオは、事業継続とディザスター リカバリー (BCDR) の向上に役立ちます。 Azure VMware Solution は、専用のベアメタル Azure インフラストラクチャから構築された VMware vSphere クラスターを含むプライベート クラウドを提供します。 このソリューションでは、最低 3 つの ESXi ホストが提供され、クラスターあたり最大 16 個のホストを使用できます。 プロビジョニングされたすべてのプライベート クラウドに VMware vCenter Server、VMware vSAN、VMware vSphere、VMware NSX-T Data Center があります。 Azure VMware Solution のサービス レベル アグリーメント (SLA) について学習するには、「Azure VMware Solution の SLA」を参照してください。
オンプレミスか Azure VMware Solution かに関係なく、災害に備えてさまざまな BCDR の要因について検討する必要があります。 堅牢な BCDR プランは、破壊的なイベントが起きた場合に、データ損失、金銭的な損失、ダウンタイムから会社を保護することを目的としています。 次のデシジョン ツリーは、Azure VMware Solution で使用できるさまざまな BCDR オプションを示しています。
注意
パイロット ライト環境は最小構成で設定され、重要なアプリケーションのセットをサポートするためのコア コンポーネントのみが含まれます。 ただし、フェールオーバーが発生した場合は、スケールアウトして追加のホストを生成して負荷の大部分を引き受けることができます。 コンピューティングおよびメモリ集中型の Azure VMware Solution ワークロードのディザスター リカバリーの場合、セカンダリ サイトで同じ量のストレージが必要です。
事業継続の設計上の考慮事項
Azure VMware Solution 上の VMware vSAN ストレージ ポリシーは、ストレージの可用性を考慮して実装されます。 クラスターに 3 から 5 個のホストがある場合、データを損失せずに許容できるホスト障害の数は 1 になります。 クラスターに 6 から 16 個のホストがある場合、データ損失が発生するまでに許容されるホスト障害の数は 2 になります。 VMware vSAN ストレージ ポリシーは、VM ごとに適用できます。 これらのポリシーは既定のものですが、ポリシーをカスタム要件に合わせて修正することができます。 詳細については、Azure VMware Solution のストレージ概念に関するページをご覧ください。
Azure VMware Solution では、vSphere の高可用性が既定で有効になっています。 高可用性許可ポリシーでは、単一ノードのコンピューティング容量とメモリ容量が予約されます。 この予約により、Azure VMware Solution クラスター内の別のノードでワークロードを再起動するための十分な容量が確保されます。
ストレッチ クラスターによる高可用性: Azure VMware Solution では、標準の vSphere クラスターにデプロイされた ESXi ホストは、従来は単一の Azure 可用性ゾーンに存在し、vSphere 高可用性によって保護されます。 ただし、可用性ゾーンの障害からワークロードは保護されません。 障害から保護するために、1 つの vSAN クラスターが vSAN ストレッチ クラスターと呼ばれる 2 つの個別の可用性ゾーンにまたがることができます。 詳細については、「vSAN ストレッチ クラスターをデプロイする」を参照してください。
Microsoft Azure Backup Server やパートナーのバックアップ ソリューションなど、VMware vSphere 仮想マシン (VM) に対して検証済みのバックアップ ソリューションを選択します。
パートナーのバックアップ ソリューションでサポートされている機能の詳細については、それぞれのパートナーのドキュメントを参照してください。
Note
Azure VMware Solution プライベート クラウドの vCenter Server と HCX Manager (有効な場合) の各構成は、毎日単位のバックアップ スケジュールで、NSX 構成は時間単位のバックアップ スケジュールに従います。 バックアップは、最低 3 日間保持されます。
vCenter Server、NSX-T Manager、HCX Manager などの Azure VMware Solution コンポーネントは、Azure によってバックアップが管理される管理サービスです。 バックアップから復元するには、Azure サポート要求を作成します。
事業継続の設計に関する推奨事項
Azure VMware Solution のプライベート クラウドをバックアップするには、Azure Backup Server を使用します。 詳細については、Azure Backup を使用した VMware vSphere VM のバックアップに関する記事を参照してください。 サポートされているデプロイ トポロジには、MARS エージェント と Data Protection Manager が含まれます。 各デプロイ トポロジには、独自のサポート マトリックス、制約、および制限があります。
Azure VMware Solution のプライベート クラウドと同じ Azure リージョンに Azure Backup Server をデプロイします。 このデプロイ方法では、トラフィック コストが削減され、管理が容易になり、プライマリ/セカンダリ トポロジが維持されます。 Azure リージョン デプロイのベスト プラクティスについては、Azure リージョンの選択ガイドを参照してください。
Azure Backup は、Azure サービスとしてのインフラストラクチャ (IaaS) の VM として、または Azure VMware Solution のプライベート クラウド内にデプロイできます。 Azure VMware Solution のプライベート クラウドの外部にデプロイすることを強くお勧めします。 Azure 仮想ネットワークにバックアップをデプロイし、この仮想ネットワークが、Azure VMware Solution のプライベート クラウドに接続されているのと同じ ExpressRoute に接続されていることを確認します。 Azure VMware Solution プライベート クラウドの外部で Backup Server を実行すると、vSAN の使用量を削減するのに役立ちます。これは、vSAN が Azure VMware Solution のプライベート クラウド内で "容量が限られた" リソースであるためです。
Azure IaaS VM としてデプロイされた Azure Backup Server。
Azure VMware Solution VM としてデプロイされた Azure Backup Server。
アプリケーションのパフォーマンス要件チェックリストを使用して、適切な容量とディスクの種類 (HDD、SSD、Ultra など) を決定します。 バックアップ操作に合わせてディスクの種類と容量をサポートする Azure IaaS VM SKU を検討してください。
Azure Backup Server Capacity Planner を使用して、それぞれのサービスの数、ストレージ、IOPS の要件を決定します。 容量プランナーで "ワークロードの合計サイズ (GB)*" の値を指定する場合は、バックアップする vCenter 内のすべての VM の "使用済みストレージ" と "割り当て済みストレージ" の間の中央値を使います。
Azure Backup Server に対して記憶域プールを使用し、ディスク IOPS/スループットを強化します。 Backup Server 上で階層型ストレージを使用して、操作を強化します。 MABS ボリュームで DisableWriteAutoTiering 構成値を 1 に設定して、パフォーマンス レベル全体で ReFS メタデータを格納できるようにします。
Azure Backup サーバーで実行する並列バックアップ ジョブと復元操作の数を特定します。 現在、8 つの並列バックアップ ジョブがサポートされています。 複数の実行でミッションクリティカルなワークロードのバックアップと復元にかかった時間を測定します。 バックアップと復元の時間が、Azure Backup サーバーの RPO と RTO の要件を満たしていることを検証します。 AVS vSAN データストアに、復元されたバックアップを保持するのに十分な容量があることを確認します。
Azure Backup Server でウイルス対策/マルウェア対策ソフトウェアが実行されている場合は、こちらに記載されているように、Azure Backup Server のファイルとフォルダーに必要なウイルス対策の例外を追加します。 アプリケーションのバックアップ (SQL、Sharepoint など) に Azure VMware Solution VM で DPM 保護エージェントを使う場合は、dpmra.exe のリアルタイム監視を無効にします。
Azure VMware Solution の保護された VM で実行されている DPM 保護エージェントからのネットワーク通信を許可するように、Azure Backup Server をホストするサブネットに適切な NSG (ネットワーク セキュリティ グループ) 規則を構成します。 DPM 保護エージェントは、1024 から 65535 までの任意の動的ポートで Azure Backup Server と通信します。
現在、Azure Backup Server では、Azure VMware Solution のプライベート クラウドに対するリージョンをまたがる復元がサポートされていません。 Azure VMware Solution のリージョンをまたがる復旧が必要な場合は、パートナーのバックアップ ソリューションに関する記事とディザスター リカバリーに関するセクションを参照してください。
ディザスター リカバリーの設計上の考慮事項
アプリケーションの目標復旧時間 (RTO)、容量、回復ポイントの目標 (RPO) をビジネス要件に合わせて調整します。 これらの目標を実現するために、最も適切なレプリケーション テクノロジを使用して、計画と設計を適宜行います。 たとえば、SQL Always On 可用性グループを使用して SQL データベースをネイティブにレプリケートしたり、VMware Site Recovery Manager などのディザスター リカバリー ツールを使用したりします。
保護されている Azure VMware Solution のプライベート クラウドの対象となるディザスター リカバリー サイトを決定します。 このサイトは、どのディザスター リカバリー ツールが環境に適しているかに影響します。 たとえば、Azure VMware Solution ワークロードを Azure のネイティブ IaaS 仮想マシンに復旧する場合は、Azure Site Recovery または Zerto を検討することができます。
ディザスター リカバリー イベントがある場合、保護が必要な Azure VMware Solution のワークロードのサブセットを決定します。 優先順位に基づいてワークロードを分類することを検討してください。ビジネス クリティカルなワークロードの場合は P0、重要であるものの、ビジネスの運用にとって不可欠ではない他のワークロードの場合は P1、P2、P3 です。 顧客のビジネス継続性計画では、ディザスター リカバリーの実装に関連するコストの制御に役立つ優先度レベルを定義します。
ほとんどの場合、開発、テスト、UAT などの非運用環境では、セカンダリ サイトにフェールオーバーする必要はありません。 コストを節約するために、運用ワークロードと重要なワークロードの容量を削減して、セカンダリ サイトでパイロット ライトを実行する必要があります。 容量を増やすには、ディザスター リカバリー イベント中にスケールアウトしてクラスターに ESXi ホストを追加することができます。
特にパイロット ライト デプロイの場合は、フル スケールアウト中に必要な容量を待たずにすむように、セカンダリ サイトで必要なすべてのホスト クォータを確保していることを確認します。「Azure VMware Solution のホスト クォータを要求する」を参照してください。
セカンダリ環境に、Active Directory ドメイン コントローラーなどの機能ドメイン ロールを設定します。
JetStream や Zerto などのパートナーのソリューションが一般提供され、Azure VMware Solution で検証されます。 ほとんどのディザスター リカバリーのシナリオをサポートしており、ほぼゼロの RPO で迅速な復旧を実現できます。
VMware Site Recovery Manager、Jetstream、および Zerto では、サードパーティの場所から Azure VMware Solution への移行がサポートされています。
VMware HCX も、コスト効率の良いディザスター リカバリー ソリューションです。 ただし、手動によるオーケストレーションのため、大規模な運用ワークロードにはお勧めしません。
別々の Azure リージョンにある Azure VMware Solution プライベート クラウド間のディザスター リカバリーの場合は、両方のバックエンドの ExpressRoute 回線間で ExpressRoute Global Reach を有効にする必要があります。 これらの回線によって、VMware SRM や VMware HCX などのソリューションで必要な場合に、プライマリからセカンダリへのプライベート クラウド接続が作成されます。
同じ Azure リージョン内の Azure VMware Solution プライベート クラウド間のディザスター リカバリーの場合は、Azure VMware Solution の相互接続を有効にする必要があります。 これにより、Azure VMware Solution プライベート クラウドの管理ネットワークとワークロード ネットワーク間にルーティング リンクが作成され、クラウド間の通信が可能になります。 各プライベート クラウドのルーティングされた IP アドレス空間が一意であり、重複していないことを確認します。
ディザスター リカバリーを使用する場合、プライマリ Azure リージョンとセカンダリ Azure リージョンで同じ 送信元 IP アドレス空間を使用できます。 ただし、追加の設計とエンジニアリング作業が必要です。
同じ IP アドレスを維持する: セカンダリ Azure VMware Solution サイトの仮想マシンは、プライマリ サイトと同じ送信元 IP アドレスを使用して復旧できます。 この方法では、分離された VLAN または NSX-T セグメントをセカンダリ サイトに作成し、これらの分離された VLAN またはセグメントが環境に接続されないようにします。 サブネットがセカンダリ サイトと新しい IP アドレスの場所に移動したことを反映して、ディザスター リカバリー ルートを変更します。 この方法はうまくいきますが、完全に自動化されたディザスター リカバリーを目指す場合は技術上のオーバーヘッドがかかります。
異なる IP アドレスを使用する: 復旧される VM には異なる IP アドレスを使用することもできます。 VM がセカンダリ サイトに移動された場合、VMware Site Recovery Manager 内の復旧計画には詳細なカスタム IP マップが示されます。 IP アドレスを変更するには、このマップを選択します。 VM は新しい NSX-T セグメントで起動され、新しい IP アドレスが割り当てられます。 このツールは、ディザスター リカバリー ソリューションによって異なる場合があります。
部分的および完全なディザスター リカバリー シナリオの重要な要因:
VMware Site Recovery Manager では、仮想マシンのサブセットのみを復旧する部分的な回復と、完全なディザスター リカバリーがサポートされています。 リージョン 1 とリージョン 2 の 2 つの Azure VMware Solution サイト間で、VM の全部または一部がフェールオーバーされる可能性があります。
復旧した VM の送信元 IP アドレスの保有期間の要件により、部分的および完全なディザスター リカバリーのどちらが可能かが決まります。
Site Recovery Manager で部分的なディザスター リカバリーを実行中に送信元 IP アドレスを維持するには、サブネット ゲートウェイをセカンダリ サイトに移動する必要があります。
注意
アクティブ/スタンバイのディザスター リカバリーでは、レイヤー 2 拡張は必要ありません。
ディザスター リカバリーの設計に関する推奨事項
プライマリ サイトとセカンダリ サイトの両方で Azure VMware Solution を使用する場合は、VMware Site Recovery Manager を使用します。 プライマリ サイトとセカンダリ サイトは、それぞれ保護されたサイトと復旧サイトとも呼ばれます。
継続的な vSphere レプリケーションの概要。
プライマリ サイトとセカンダリ サイト間の継続的な vSphere レプリケーションの詳細な例。
ビジネス クリティカルなアプリケーションの場合、Zerto と JetStream が、Azure VMware Solution プライベート クラウドのディザスター リカバリー ソリューションとして利用できます。 JetStream と Zerto は、最小限のデータ損失またはデータ損失ほぼなしを可能にする VMware vSphere API for I/O Filtering (VAIO) フレームワークを使用して、継続的データ保護 (CDP) の基礎の上に構築されています。 また、最小限のリソースを使用してコスト効率の良いディザスター リカバリーを可能にします。
Azure VMware Solution のプライベート クラウドのディザスター リカバリー ターゲットが Azure IaaS 仮想マシンの場合、Azure Site Recovery または Zerto を使用します。
各ディザスター リカバリー ソリューション内で自動復旧計画を使用して、手動入力を最小限に抑えます。 これらの計画は、VMware Site Recovery Manager またはパートナー ソリューションを使用する場合に役立ちます。 復旧計画では、マシンをフェールオーバーの復旧グループに収集します。 後でこれは、フェールオーバー可能な独立ユニットを作成して体系的な復旧プロセスを定義するために役立ちます。
復旧計画が期待どおりに動作するように、少なくとも年に 1 回はスモーク テストまたはディザスター リカバリーの訓練を設定します。 選んだディザスター リカバリー ツールのオーケストレーション機能によって、このような訓練の実行に伴う作業レベルが決まります。
セカンダリ ディザスター リカバリー環境として地理的リージョン ペアを使用します。 リージョン ペアの利点には、優先順位付けされたリージョン復旧、順次更新、物理的な分離、データ所在地があります。
2 つのサイト間で IP アドレスが重複しないように、アドレス空間を別のものにします。 たとえば、リージョン 1 には
192.168.0.0/16を使用し、リージョン 2 には10.0.0.0/16を使用します。プライマリとセカンダリのプライベート クラウド間で、ExpressRoute Global Reach 接続を別々のリージョンで使用します。 ネットワークに関するその他の考慮事項と推奨事項については、関連する設計領域に関する記事を参照してください。
次の手順
Azure VMware Solution の初期デプロイに関する考慮事項と推奨事項について説明し、運用の自動化に関するガイダンスを確認します。