デプロイ ワークフローの前提条件を明らかにする
予期しない災害から組織のワークロードを保護するには、最初に、会社の現在の事業継続とディザスター リカバリー (BCDR) 計画を確認する必要があります。 保護が必要なシステムの復旧目標と範囲を明らかにする必要があります。
VMware SRM は BCDR ソリューションであり、保護された VMware vCenter Server サイトとリカバリー vCenter Server サイトの間での VM の復旧を計画、テスト、実行するのに役立ちます。
BCDR
サービスが失われると、どのようなものでも、スタッフやユーザーにとっては中断になる可能性があります。 システムを利用できない 1 秒ごとに、会社の収益が失われる可能性があります。 また、会社としては、提供するサービスについて契約している可用性を満たすことができずに、賠償金を払わなくてはならなくなる可能性もあります。
"BCDR 計画" は、災害や大規模な停止が発生したときに、どのような範囲で何を行うかを規定するために企業が作成する正式なドキュメントです。 組織は、個々の停止をその影響に基づいて評価します。 たとえば、組織はデータセンターで停電が発生したときに BCDR 計画を発動することがあります。
目標復旧時間 (RTO)
"目標復旧時間 (RTO)" とは、継続性の中断による許容できない結果を発生させることなくビジネスを維持できる、障害が発生してから通常のサービスを復元するまでの最大時間を示す尺度です。 たとえば、組織の RTO が 12 時間である場合、ビジネスのコア サービスが機能していなくても、業務を 12 時間継続できることを意味します。 ダウンタイムがそれより長くなると、ビジネスは深刻な影響を受けます。
目標復旧時点
企業は、24 時間ごとや 12 時間ごと、さらにはリアルタイムで、バックアップを実行することを決定する場合があります。 ただし、障害が発生した場合、常にデータがある程度失われます。 "目標復旧時点 (RPO)" とは、障害発生後に許容できるデータ損失の最大量を示す尺度です。
たとえば、バックアップを 24 時間ごとに午前 0 時に実行している組織で、午前 9 時に障害が発生した場合、9 時間分のデータが失われます。 組織の RPO が 12 時間であるとすると、9 時間のデータ損失は許容されます。 RPO が 4 時間の場合は、そのデータ損失は許容されません。
VMware SRM とは
VMware SRM は、プライマリ サイトからセカンダリ サイトにワークロードをレプリケートできるので、BCDR 計画の役に立ちます。 プライマリ サイトで問題が発生したら保護対象の VM を別の場所に自動的にレプリケートするよう、VMware SRM を設定できます。 また、VMware SRM を使用して、オンプレミスのインフラストラクチャからクラウド内の Azure VMware Solution に VM を移行することもできます。
Azure VMware Solution は、VMware の Software Defined Data Center (SDDC) ソフトウェアと Azure のクラウド サービスを組み合わせたものです。 Microsoft では、パフォーマンス、可用性、セキュリティ、コンプライアンスの要件を満たすように Azure VMware Solution を管理ししています。
Azure VMware Solution を Azure で大規模に実行するために、Microsoft は次のコンポーネントを提供します。
- 管理システム
- ネットワーク
- 運用プラットフォーム
- バックエンド インフラストラクチャの運用
VMware Site Recovery Manager を使って、次のようなさまざまな種類の復旧を実装できます。
- オンプレミスの VMware vCenter Server サイトから、Azure VMware Solution のプライベート クラウド内の復旧サイトへ。
- ある Azure リージョンのプライマリ Azure VMware Solution サイトから、別の Azure リージョンのセカンダリ Azure VMware Solution サイトへ。
シナリオ 1: オンプレミスの VMware vCenter Server サイトから、Azure VMware Solution のプライベート クラウド内の復旧サイトへ
Azure VMware Solution に VMware SRM をデプロイすると、専用のディザスター リカバリー (DR) サイトを管理するためのコストとオーバーヘッドを削減することができます。 VMware SRM と、Azure VMware Solution の動的でオンデマンドのスケーラビリティを組み合わせることにより、個々の VM に必要なコストと復旧時間のバランスを取ることができます。
VM をレプリケートし、中断が発生しないテストを作成し、動的な復旧計画を準備することができます。 "復旧計画" では、復旧サイトで VM を起動する順序を指定します。 これには、VM に対してカスタムの復旧操作を実行するための IP アドレスとオプションのユーザー指定スクリプトが含まれます。
シナリオ 1 の前提条件
オンプレミスの VMware vCenter Server サイトの保護を Azure VMware Solution の復旧サイトにデプロイする前に、サイトが次の前提条件を満たすことを確認する必要があります。
ネットワーク: Azure VMware Solution のプライベート クラウド環境に、オンプレミスのリソースと Azure ベースのリソースからアクセスできる必要があります。 この相互接続は、次のサービスを使って実現できます。
Azure ExpressRoute
仮想プライベート ネットワーク (VPN) 接続
Azure Virtual WAN
Note
オンプレミスと Azure VMware Solution の間の ExpressRoute 接続には、少なくとも 2 ギガビット/秒 (Gbps) のスループットが推奨されます。
名前解決: オンプレミスの SRM と仮想クラウド アプライアンスの間に、ドメイン ネーム システム (DNS) の解決を実装する必要があります。 パブリック DNS とプライベート DNS の両方を使用できます。 サポート リクエストを利用して、適切な条件付き転送ルールを備えた Azure VMware Solution 用のプライベート DNS を構成できます。
vCenter Server のバージョンは、VMware SRM のバージョンと互換性がある必要があります。
どちらのサイトにも、相互に接続された vSphere Replication アプライアンスが必要です。
復旧サイトには、保護対象のサイトと同じ VM およびワークロードをサポートできるハードウェア、ネットワーク、ストレージ リソースが必要です。 Azure VMware Solution では、動的なスケーリングによってこの機能が提供されます。
シナリオ 2: プライマリ Azure VMware Solution からセカンダリ Azure VMware Solution へ
このシナリオは最初のシナリオに似ていますが、保護サイトと復旧サイトが異なる Azure リージョンで実行される点が異なります。 プライマリ リージョンとセカンダリ リージョンの両方のプライベート クラウドに、Azure VMware Solution をデプロイする必要があります。 さらに、両方のリージョンが ExpressRoute Global Reach に接続されている必要があります。 両方のサイトに、VMware SRM と vSphere Replication のアプライアンスが含まれる必要があります。
次のユニットでは、このシナリオをセットアップして構成する方法について説明します。