Amazon Web Services ブログ

VMware Cloud Disaster Recovery (VCDR) と NetApp CVO を活用したディザスタリカバリの要求への対応

AWS で VMware Cloud Global Account Specialist SA Lead を務める David Piet PhD と Sr. Solutions Architect を務める Dhaval Shah による記事です。

多くの組織は、アップグレードが必要となった老朽化したインフラストラクチャ、コロケーション設備リースの更新、または DR 戦略を必要とするアプリケーション範囲の拡大など、さまざまな理由でディザスタリカバリ (DR) 戦略を再検討しなければならない段階に達しています。

組織は主要なニーズに合わせてクラウドにマイグレーションすることのメリットを評価していますが、DR サイトのアップグレードへの追加投資が急に必要になると、IT 予算にさらに負担がかかり、新しいビジネスチャンスへの取り組みが遅くなってしまう可能性があります。

Fortune 500 企業のとある AWS のお客様は、リースの期限切れとインフラストラクチャの老朽化により、新しい DR ソリューションを模索していました。また、コストを削減し、メンテナンスと運用管理を削減する方法も調査していました。本番ワークロードは VMware vSphere ハイパーバイザー上で実行されており、NetApp Filer も利用していました。

この投稿では、上述のお客様と同様に、 VMware Cloud Disaster Recovery (VCDR) ソリューションおよびさまざまな AWS サービスを活用して、最小限のアプリケーション変更で DR サイトを AWS 上にマイグレーションする手法についてご紹介します。

この手法では、緩やかな学習曲線でありながら総所有コスト (TCO) のメリットが高くなるため、お客様は AWS にすばやくマイグレーションできます。このソリューションでは、お客様は現在 VMware 仮想環境上でインフラストラクチャを実行しており、CIFS (Common Internet File System) 共有など何らかの共有ストレージを使用していることを前提としています。

ディザスタリカバリのソリューション

図 1 に示すディザスタリカバリのソリューションは、3 つの主要なコンポーネントで構成されています。

  • VCDR は、 オンプレミスの仮想マシン (VM) のフェイルオーバーを管理します。
  • NetApp Cloud Volumes ONTAP (CVO) は、 CIFS 共有を管理します。
  • AWS Landing Zone は、DMZ レイヤー、ストレージレイヤー、およびさまざまなサービス間の接続を管理します。

では、これらの各コンポーネントがそれぞれどのように機能するのか簡単に見てみましょう。

図 1 — ソリューションアーキテクチャ

VCDR の概要

VCDR は、VMware Cloud on AWS にネイティブに組み込まれ、完全に統合されたディザスタリカバリソリューションです。使いやすい Software as a Service (SaaS) ソリューションを提供するオンデマンドの DR サービスです。VCDR を利用することで、オンプレミス VMware 仮想環境の仮想マシンを AWS にレプリケーションし、災害発生時には VMware Cloud on AWS にフェールオーバーすることで、ワークロードを保護することができます。

VCDR を DR ソリューションとして構成するには、最初に OVA アプライアンスである DRaaS Connector をオンプレミス VMware 仮想環境にデプロイします。DR 保護グループに追加された仮想マシンは、クラウドベースの VCDR サービスにレプリケーションされます。

クラウドベースのサービス内には、DRaaS Orchestrator と Scale-out Cloud File System が存在します。実際の災害復旧または DR シミュレーションでは、Scale-out Cloud File System は VMware Cloud on AWS 内の software-defined data center (SDDC) からマウントされ、ワークロードは AWS 上で実行されます。

VMware Cloud on AWS 内のディザスタリカバリ SDDC では、次の 2 つのモデルを利用できます。

  • 1 つ目は、パイロットライトモードです。このモデルでは、常に必要最小数の VMware Cloud on AWS ホストが稼働しています。DR フェイルオーバーが発生した場合、仮想マシンがオンラインになると、クラスタは Elastic Distributed Resource Scheduler (EDRS) を使用して自動的にスケールアップします。この運用モデルでは、通常時にはパイロットライトのホストにはサブスクリプションが関連付けられ、フェイルオーバー時にはスケールアップで追加されたホストはオンデマンドで実行されます。
  • 2 つ目は、just-in-time (JIT) な展開モードです。つまり、障害が発生した場合に新しい SDDC をプロビジョニングし、それに応じて設定を行い、ワークロードをフェールオーバーします。このモデルでは、24 時間稼働しているホストがないため、比較的低コストとなります。ただし、災害発生時にDR環境をリアルタイムでデプロイするには、時間と人員が追加で必要になります。プロビジョニングされるホストは通常、オンデマンドで実行されます。

NetApp Cloud Volume ONTAP の概要

NetApp Cloud Volumes ONTAP は、Data ONTAP のソフトウェアのみのバージョンです。これは、物理的な NetApp ストレージアプライアンスで使用される NetApp のデータ管理オペレーティングシステムです。

Cloud Volumes ONTAP では、オペレーティングシステムが Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されるようにカスタマイズされています。Cloud Volumes ONTAP on AWS を使用すると、新しいエンタープライズクラスのデータ管理システムがクラウド上で数分で起動できます。

Cloud Volumes ONTAP には、SMB および NFS のマルチプロトコルサポート、ローカルスナップショット、圧縮と重複排除によるストレージ効率性、効率性とスナップショットをそのまま維持したままでの SnapMirror によるクラウドへのデータ移行などの機能が含まれています。CVO 機能の詳細については、 NetApp Cloud Manager および Cloud Volumes ONTAP for AWS の AWS Marketplace のページを参照してください。

ソリューションの概要

上述の各コンポーネントを組み合わせると、全体的なソリューションは次のようになります。仮想マシン と NetApp ボリューム両方からのレプリケーションにより、DR 環境との同期が維持されます。災害発生時には、仮想マシンは VMware Cloud on AWS にフェイルオーバーし、接続用に AWS Transit Gateway を使用して CVO ボリュームをそれぞれのファイルシステムに直接マウントします。

図 2 は、AWS Transit Gateway を使用したトラフィックフロー管理を示しています。これにより、east-west および north-south のネットワークトラフィックを柔軟に管理および制御できるほか、AWS サービスまたは外部サービスを追加のアタッチメントとして拡張できるネットワークスケーラビリティを実現できます。

図 2 — AWS Transit Gateway を経由するネットワークルート

AWS 設定にかかるワークフロー

VCDR ソリューションの AWS コンポーネント設定にかかる大まかなワークフローは次のとおりです。

  • AWS アカウントを作成し、DR インフラストラクチャをデプロイするリージョンを選択します。今回のケースでは、お客様は DR サイトとして us-west-2 を選択しています。
  • 組織のニーズとベストプラクティスに基づいて、ユーザーと AWS Identity Access Management (IAM) ロールを作成します。
  • Amazon Virtual Private Cloud (Amazon VPC)、仮想プライベートネットワーク (VPN)、AWS Transit Gateway、およびファイアウォールアプライアンスを使用したトランジット VPC など、基本的なネットワークコンポーネントをデプロイします。
  • Transit Gateway に加えてルートとセキュリティグループを設定し、すべてのコンポーネントを接続します。

VCDR 設定にかかるワークフロー

基本的なワークフローは次のとおりです。

  • VMware Cloud Disaster Recovery ポータルで、必要最小数のクラスタをデプロイします。これらのホストは、災害発生時には、AWS のパイロットライトのコンピューティングリソースとして機能します。例として、上述のお客様はパイロットライトとして 2 ノードクラスタを展開しました。
  • VCDR を DR ターゲットとして利用する、オンプレミス VMware 仮想環境を保護サイトとして設定します。このプロセスの一環として、DRaaS Connector がオンプレミス環境にダウンロードされます。
  • 2 つのサイトが正常にペアリングされると、あとは保護グループポリシーを作成するだけです。これらのポリシーによって、保護対象の仮想マシン、それぞれの目標復旧時点 (RPO)、およびバックアップのストレージレベルのポリシー (保持期間) が設定されます。

CVO 設定にかかるワークフロー

基本的なワークフローは次のとおりです。

  • Amazon EC2 インスタンスを作成して、Cloud Manager と対応するルートとファイアウォールルールを設定します。
  • EC2 インスタンスを作成して NetApp CVO をインストールし、CIFS 共有を管理します。
  • SnapMirror プロセスを設定して、オンプレミスの CIFS 共有を AWS 側 に同期します。

まとめ

お客様が既存のディザスタリカバリ戦略を再考する理由は数多くあり、その際には、使い慣れたソリューションやテクノロジーに注目されることがよくあります。

この投稿で説明したアーキテクチャーでは、現在 VMware vSphere ハイパーバイザーと NetApp ストレージを使用しているお客様は、VCDR と VMware Cloud on AWS および Amazon EC2 上の NetApp Cloud Volumes ONTAP を活用することで、AWS 上でもオンプレミスと同様のテクノロジーを利用しながら、オンプレミス DR サイトを完全に廃止することが可能となります。

翻訳は Specialist SA 武田が担当しました。原文はこちらです。