Amazon FSx for NetApp ONTAP と SnapMirror を活用した VMware Cloud on AWS のディザスタリカバリ

現代のビジネスの大部分は、IT システムの機能と可用性に依存しています。したがって、災害発生時にも事業継続するためには、これらのシステムを保護することが極めて重要です。

オンプレミスのデータセンターでは、VMware の仮想化ソリューションと NetApp ONTAP ストレージが広く採用されています。Amazon FSx for NetApp ONTAP のリリースと、VMware Cloud on AWS による Amazon FSx for NetApp ONTAP のサポートは、お客様に災害復旧（DR）の新しい選択肢をもたらしました。

これらのソリューションにより、NetApp SnapMirror を使用して仮想マシン（VM）のデータをオンプレミス環境から AWS にコピーできます。AWS 内では、仮想マシンをディザスタリカバリの退避先として VMware Cloud on AWS 環境の vCenter にインポートできます。

以前の AWS ブログ投稿では、VMware Cloud on AWS を利用したディザスタリカバリの設計上の考慮点について掲載しました。続いて、VMware Site Recovery と VMware Cloud Disaster Recovery を利用した複数のディザスタリカバリ SLA に対処する方法について掲載しました。

VMware のハイパーバイザー機能は、仮想ディスクのスナップショット、変更ブロックの追跡、および DR システムへの API データ保護アクセスを可能にします。さらに、お客様は各仮想マシンのオペレーティングシステム（OS）内のエージェントなどの各種 DR ツールを活用して機能追加できます。

Amazon FSx for NetApp ONTAP（FSx for ONTAP）と VMware Cloud on AWS の統合が発表されたことで、お客様はデータストア用の追加ストレージという選択肢と、VMware ワークロード用の DR という選択肢を手に入れました。

このブログ投稿では、お客様が Amazon FSx for NetApp ONTAP をターゲットとして使用し、SnapMirror を活用して移行とディザスタリカバリの両方の目的でオンプレミスの VMware ワークロードをレプリケーションする方法について説明します。

ディザスタリカバリにおける一般的な課題

ディザスタリカバリを計画する際の課題と、SnapMirror がそれらにどのように対処できるかを確認します。ディザスタリカバリの計画には、目標復旧時間 (RTO)、目標復旧時点 (RPO)、コストのトレードオフが伴います。RTO と RPO が縮小するにつれて、コストが増加します。DR に関する意思決定では、各オプションのコストとメリットをビジネスニーズとともに比較検討する必要があります。

従来の DR ツールは、DR 保護プランに組み込まれた個々の仮想マシンを対象としています。保護の際には、エージェントソフトウェアまたは VMware Data Protection API プラグインを使用して VM データを取得し、変更ブロックの更新を保持します。場合によっては、課題が生じる可能性があります。

図 1. 一般的な災害復旧の課題

コスト

インフラストラクチャとライセンスの重複による高額なコスト : セカンダリ DR サイトを維持するために、そのサイトを使用する必要があるか確証がないままで、コンピューティング、ネットワーク、およびソフトウェアのライセンスの重複に高額なコストを払っている可能性があります。高価な高性能ストレージを DR ストレージ階層 (障害時にのみパフォーマンスが必要な場合) として使用すると、コストが不必要に増加します。ストレージコピーを効率的に重複排除、圧縮、圧縮できない場合は、コストがさらに増加します。
スケーリング : オンプレミスの DR ソリューションでは、プライマリ環境に変更があった場合でもスケールアップやスケールダウンが困難で費用がかかることがよくあります。組織は通常、将来予想される成長に応じて、DR インフラストラクチャを事前にプロビジョニングするために事前に投資するためです

複雑性

サーバーの互換性の問題 : オンプレミスや他のクラウドから AWS にサーバーをレプリケーションする際、レプリケーションされたサーバーを AWS ネイティブ環境で実行するためには、サーバーを変換する必要があります。これには、ハイパーバイザー、ドライバー、およびその他の変更が含まれます。
目標達成が困難 : DR テストを実施しても要求された RTO/RPO を達成するのが難しい、あるいはテスト結果の信頼性が低い場合があります。

ディザスタリカバリの方法論

リカバリソリューションを選択する際、お客様にはさまざまな選択肢があります。このセクションでは、エージェント、エージェントレス、アレイベースのソリューションについて説明します。

エージェント

このシナリオでは、ハイパーバイザーの統合やアクセスは不要で、VMware スナップショットにも依存しません。現在のイメージベースのバックアップシステムのほとんどは、非イメージベースのシステムと同じきめ細かなファイルリストアを実行できるというメリットがあります。

エージェントベースのバックアップはゲスト OS スタックにロードされるため、エージェントレスバックアップの場合ではすぐには利用できないホストシステムの制御と可視性を向上させることができます。エージェントベースのバックアップにより、ロックされているファイルシステムオブジェクトのボリュームシャドウコピー (あるいは Volume Snapshot Service (VSS) としても知られる) やデータベーススナップショットをデータ整合性のある手法で保護できます。

この手法で考慮すべき点は、ゲスト内エージェントが各サーバに確実にインストールするための、エージェントの実行コストです。サーバーのコミッショニング時に実施する必要があり、実施しない場合、スナップショットドライバーは OS カーネル上にあるために再起動が必要になる場合があります。

エージェントによっては、ゲストだけでなくホストやデータストアにもオーバーヘッドが発生する可能性があります。エージェントベースのジョブの同時実行も制限される場合があります。

エージェントレス

すべての主要なプロセスはハイパーバイザーによって実行されます。そのため、仮想マシンはゲストデータを含むディスクイメージを伴う構成の記述になります。その結果、ゲストファイルシステムを経由することなく、仮想マシン全体をイメージレベルで一度にバックアップできます。バックアップソフトウェアに必要なすべてのリソースには、ハイパーバイザーを介してアクセスできます。

さらに、エージェントレスバックアップには、ターゲットとストレージデバイス間のデータだけでなく、アプリケーションコマンドをネットワーク経由で送信するためのネットワークリソースも必要です。VMware Installation Bundle (VIB) が必要となるため一部のハイパースケーラーでは実現できない、ハイパーバイザーとの統合や互換性も存在します。保護レベルは、ゲスト (VSS、DB スナップショット) と連携しなくてもクラッシュ・コンシステントになります。

ストレージアレイのレプリケーション

アレイベースのレプリケーションは、ストレージベースのスナップショットを使用してデータをコピーし、そのスナップショットデータを複製して別のサイトに保存するプロセスです。このタイプのデータ複製は、物理または仮想ストレージアレイレベルで実行されるため、ハイパーバイザーのスナップショットには依存しません。

アレイベースのレプリケーション製品は特定のストレージベンダーによって提供され、オーバーヘッドの大部分はストレージアレイで発生します。

ストレージアレイのレプリケーションでは、レプリケーション前にストレージ層で重複排除と圧縮を行うことができるため、レプリケーションされるデータが少なくなります。お客様は、ハイパーバイザーやゲストにほとんど影響を与えずに、テストに必要なときに環境全体をカットオーバーできます。

ストレージアレイのレプリケーションに考慮事項がないわけではありません。たとえば、お客様は通常、単一のポリシーでデータストア全体をレプリケーションしますが、これはきめ細かな設定には適していません。

さらに、保護サイトのデータをミラーリングするために、DR ロケーションに 2 台目のストレージアレイを運用するコストも必要です。データ同期の際には、コピーされたデータが有効であることを確認するためにエージェントがゲストオペレーティングシステムとディスクを休止する必要がある場合があります。休止しない場合はクラッシュコンシステントになります。

NetApp SnapMirror を活用した DR 戦略の組み立て

ディザスタリカバリソリューションを成功させるための基本は、保護対象サイトと DR ロケーション間の信頼性の高いデータ同期です。NetApp は ONTAP のネイティブ機能である SnapMirror で実現しています。

NetApp SnapMirror は、ブロックレベルのレプリケーションを採用して迅速かつ効率的なデータ転送を可能にしており、オンプレミスから AWS にレプリケーションする場合でも、AWS リージョンにまたがる2つのAmazon FSxファイルシステム間でレプリケーションする場合においても、ONTAP システム全体で高いデータ可用性と高速なデータ複製を実現できます。

レプリケーションは 5 分おきにスケジュールすることもできますが、間隔は RPO、帯域幅、レイテンシーを考慮して検討する必要があります。

SnapMirror は、NetApp Snapshot テクノロジーをレプリケーションプロセスの基盤として使用します。このテクノロジーでは、最初にソースデータのフルコピーをターゲットにレプリケーションし、その後、前回のレプリケーションイベント以降に変更されたブロックのみをレプリケーションするため、転送とストレージのコストを節約できます。

お客様は、数分から数時間までの同期スケジュールを指定でき、このスケジュールに従って、ソースからのデータ変更がコピー先に転送されます。

NetApp SnapMirror を活用して仮想マシンの移行を実現するソリューションアーキテクチャ例は、次の図を参照してください。

図 2. NetApp SnapMirror を活用した VM の障害復旧と移行

NetApp ONTAP は、仮想マシンのストレージとファイル共有の両方の目的で、オンプレミスで VMware 環境と組み合わせて使用されることがよくあります。

オンプレミスの ONTAP ボリュームに保存されている VM やファイルは、AWS Direct Connect などのプライベート接続または仮想プライベートネットワーク（VPN）接続を介して、AWS 上の FSx for ONTAP に簡単にレプリケーションできます。これにより、セカンダリサイトとして利用している AWS にオンプレミスのデータを便利で簡単に同期できます。

フェイルバックの前に、SnapMirror はセカンダリサイトからプライマリサイトにデータを自動的に再同期させます。

オンプレミスで障害が発生した場合、Amazon FSx for NetApp ONTAP サービスに同期されたボリュームを読み取り専用から読み取り/書き込みに切り替え、ネットワークファイルシステム（NFS）プロトコルを使用して、既存または新規作成した VMware Cloud on AWS 環境にマウントできます。

ボリュームを VMware Cloud on AWS にアタッチすると、そのボリュームにあるすべての仮想マシンを、手動またはスクリプトを使用により自動的に vCenter に登録できます。NetApp SnapMirror を使用して FSx for ONTAP に移行する手順については、ドキュメントを参照してください。

ディザスタリカバリにおける一般的な課題への対処

コスト

ディザスタリカバリのために2つ目のデータセンターを所有またはレンタルする場合と比較して、Amazon FSx for NetApp ONTAP と VMware Cloud on AWS を活用することは、高度な DR 対策を維持しながら全体的な総所有コスト（TCO）を削減するための効果的な手段となります。

仮想マシンのデータはビジネスの RPO 要件に従って同期するように設定可能であり、VMware Cloud on AWS 環境も RTO 要件を満たす最小ホスト台数で稼働可能であるため、ランニングコストを最小限に抑えることができます。

また、VMware Cloud on AWS をオンデマンドでデプロイすることによって、2 つ目の VMware 環境のランニングコストを完全に削減することも可能です。

Amazon FSx for NetApp ONTAP は、スループット、IOPS、ストレージ容量を拡張できるため、進化、変化、拡大するビジネスニーズに合わせてストレージを適切なサイズに設定できます。DR もしくは VMware Cloud on AWS のセカンダリストレージとしての用途にも、スループットのスケールアップまたはダウン、IOPS の変更、およびキャパシティのスケールアップをオンデマンドで対応できます。

AWS Transit Gateway (TGW) および VMware Transit Connect (VTGW) 経由のデータ転送は、AWS Transit Gateway の料金表に従って請求されることに注意してください。

複雑性

災害が発生した場合、複雑性は RTO に大きな影響を与える可能性がありますが、FlexClone によって簡易実行できる頻繁な DR テストによって影響を緩和できる可能性があります。

VMware Cloud on AWS と Amazon FSx for NetApp ONTAP はどちらもマネージドサービスとして提供されるため、インフラストラクチャを維持するための面倒な作業が削減されます。

すでに VMware と NetApp ONTAP に精通している IT 管理者は、AWS 上でもこれらのソリューションを引き続き利用できます。これらのサービスを組み合わせて活用することで、サードパーティのデータ複製ソリューションが不要になります。ただしフェイルオーバー時におけるオーケストレーションは手動で実施するか、他のツールを使用する必要があります。

お客様が Amazon FSx for NetApp ONTAP を追加データストアとして使用しておらず、フルマネージドソリューションを希望する場合は、VMware Site Recovery や VMware Cloud Disaster Recovery などの VMware Cloud on AWS アドオンサービスを検討してください。

信頼性と一貫性

プライマリサイトで障害が発生し、セカンダリサイトへのフェールオーバーを実施す場合、移行に必要なすべてのコンポーネントが期待どおりに機能することが重要です。VMware Cloud on AWS には標準のクラスタ構成では 99.9％の SLA が適用され、Amazon FSx for NetApp ONTAP にはマルチアベイラビリティゾーン（AZ）構成では 99.99% の SLA が提供されます。

また、DR プランを定期的にテストすることも可能であり推奨されています。テストのために、仮想マシンのデータを Amazon FSx for NetApp ONTAP の別のボリュームにコピーし、常時利用またはオンデマンドの VMware Cloud on AWS Software-Defined Data Center (SDDC) と組み合わせることが可能です。これにより、DR プランは常に最新の状態に保たれ、実行手順を十分にリハーサルできます。

まとめ

Amazon FSx for NetApp ONTAP は、VMware Cloud on AWS をディザスタリカバリ用途で活用することで、オンプレミスの ONTAP ストレージ環境向けに信頼性ならびに費用対効果が高く、柔軟で使い慣れたソリューションを提供します。

Amazon FSx for NetApp ONTAP を追加データストアとして使用しておらず、フルマネージドソリューションを希望するお客様は、ディザスタリカバリのニーズに合わせて VMware Cloud Disaster Recovery または VMware Site Recovery を利用できます。ほとんどのお客様は複数のワークロード群を抱えており、いくつかの DR 手法を組み合わせることで、コスト最適化とパフォーマンスのバランスをとることができます。

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

参考資料:

Amazon Web Services ブログ