リカバリーサイトの準備方法によって、災害発生時の運用が変わる

VCDRは、vSphere環境の仮想マシンを別のサイト（＝リカバリーサイト）に復元できる製品になっております。一方でVCDRは単体のみでは利用することができず、リカバリーサイトとしてVMware Cloud on AWSが必要になります。そのようなVCDRですが、実は事前にリカバリーサイトであるVMware Cloud on AWSのSDDCを展開しておくかどうかで、災害発生時にVCDRによってリカバリーするまでの運用が変わってきます。

リカバリーサイトの準備方法のパターンとしては、災害発生時にSDDCを展開する"オンデマンド展開（On-demand）"と、あらかじめSDDCを展開しておく"事前展開（Pilot Light）"の２つのパターンに分けられます。

　

VCDRによるリカバリーまでの準備作業

では、リカバリーサイトの準備方法の違いが、災害発生時に具体的にどういった作業に影響してくるのか確認していきましょう。以下は、VCDRによるリカバリーを実施するために必要な作業の全体的に流れになります。
　※こちらは一例であり、すべての環境に当てはまるわけではございません。

リカバリーサイトとなるSDDCは、災害発生後に本番サイトとして利用する仮想化基盤になるため、サーバー（仮想マシン）をリカバリーする準備として、ネットワーク面の準備が必要になります。ネットワークの作成やファイアウォールの設定やポート開放、拠点間接続のためのVPNやルーティングなどについて検討・準備する必要があります。

一方で、VMware Cloud on AWSのSDDCはクラウド上にVCF（VMware Cloud Foundation）をベースとしたvSphere環境を展開する仕様のため、SDDCを展開しないとネットワーク関連の設定をすることができません。他のパブリッククラウド（AWSやAzure）と違い、ネットワーク関連の設定を事前に用意しておき、インスタンス（サーバー）のみ災害発生時の有事のタイミングで起動するといった運用はできません。

VCDRにおいて、リカバリーサイト（SDDC）を"オンデマンド展開"、"事前展開"のどちらでも利用することは可能ですが、Disaster Recovery（DR）という観点から復旧までの時間をより短くする必要があるのであれば、"事前展開"を選択する必要があります。

　

次の章から、リカバリーサイトの準備方法のパターン毎に、具体的な構成イメージと運用イメージを挙げながらユースケースを紹介いたします。

　

即座にサーバーを起動できる災害対策（事前展開）

始めの構成は、SDDCを事前に展開しているパターン"事前展開"です。

VCDRは、守りたいvSphere環境を保護サイトとして登録します。この保護サイトは複数設定することができます。保護サイトにはVCDRのクラウドストレージにデータ転送をするDRaaS Connector（図ではDRCと表記）を配置し、定期的に保護サイト（vSphere環境）の仮想マシン スナップショットを取得して、クラウドストレージへ転送しております。

リカバリーサイトは、VMware Cloud on AWSのSDDCを事前に展開しております。ネットワークやファイアウォールの設定をあらかじめ行い、有事の際にすぐに利用を開始できる準備を行っております。拠点間接続には、AWS Direct Connectによる専用線の引き込みを行い、既存拠点との通信環境を整えておきます。ただし、保護サイトとリカバリーサイトで同じネットワークセグメントを構成するため、何も対策をしないとネットワークが社内で重複してしまいます。そのため、経路情報の広報を受け取らないよう、あらかじめダイナミックルーティングの設定や専用線サービスのルーティング情報を調整するなど、ネットワーク全体を考慮して設定を調整しておきます。

また、VMware Cloud on AWSのSDDCにはあらかじめパブリックIPアドレスを確保することが可能です。公開サーバーがある場合は、事前にFW設定をすることで有事に即座に利用できるように、あらかじめ備えておくことが可能です。

障害規模が大きく一刻を争う事態になった場合を考慮すると、災害発生時の作業を少なくすることがとても重要になるため、事前準備を数多くできることは大きなメリットになります。

・拠点災害時の運用イメージ

"事前展開"のパターンの場合に、拠点に災害が発生したケースを想定します。

リカバリーサイトであるVMware Cloud on AWSのSDDCを事前に展開しているため、多くの準備作業をあらかじめ完了しています。拠点で利用していたネットワークセグメントのルーティングをリカバリーサイトに切り替える作業を行う作業のみで、リカバリーサイトのサーバー（仮想マシン）にアクセスできるようにできます。このように"事前展開"の構成パターンは、結果として早急なリカバリー開始を実現することが可能です。
　※すべてのケースにおいて当てはまるわけではございません。

・データセンター災害時の運用イメージ

次に、データセンターに災害が発生したケースを想定します。

前述の拠点で障害が起きた際の運用イメージでは、あらかじめVMware Cloud on AWS上に展開してたSDDCのリソース範囲で、リカバリー対象の仮想マシンを実行できる想定でした。

今回の運用イメージは、データセンターでの災害発生です。データセンターは拠点と比較するとサーバー数が多いため、あらかじめ展開していたSDDCのホスト数２台ではリソースが賄えないことが想定されます。そういった場合は、VMware Cloud on AWSの機能を活用し、有事のタイミングでSDDCのESXiホストを追加し総リソース容量を増やすことができます。（スケールアウト）
さらに、データセンターにインターネットへ公開しているサーバーがあると想定した場合は、あらかじめ設定してあるFW設定を無効→有効にすることで、インターネットから公開サーバーへアクセスできる環境を復旧できます。また、併せて公開サーバー用の外部DNSのレコードを保護サイトにあるパブリックIPアドレスから、リカバリーサイトであるSDDCのパブリックIPアドレスへレコード変更を行うことで、同じFQDNでアクセスできるように復旧します。

このようにデータセンターの災害時も、拠点災害時と同様にリカバリーサイトであるSDDCを事前に展開しているため、多くの準備作業をあらかじめ行うことができ、規模の大きいデータセンター災害に対しても早急なリカバリーを実現することが可能です。

・データセンター復旧後の対応

保護サイトであるデータセンターが復旧した際、リカバリーサイトのSDDCに追加したホスト数を通常運用である2台（最低構成数）にスケールインすることができます。
保護サイトの規模に合せてスケールアウトを行い、復旧後はスケールインをさせることで、常時稼働させるSDDCのホスト数を減らしてコストを節約することが可能になります。
　※ストレッチクラスタ構成の場合、スケールインに制限があります。詳細はVMware Cloud on AWSのドキュメントをご確認ください。

このように複数拠点があり、規模が違っていても柔軟にリカバリーを行えるのがVCDRの特徴です。

　

コストを抑えた災害対策（オンデマンド展開）

次に、SDDCのオンデマンド展開を想定した構成"オンデマンド展開"のパターンです。

保護サイトの構成は"事前展開"の構成と変わりませんが、"オンデマンド展開"の場合、常時展開するVMware Cloud on AWSのSDDCがないため事前準備作業ができません。特に専用線についてはSDDCがないため、リカバリーサイトにネットワークを引き込むことができません。災害発生時に速やかにネットワークを準備できるように、拠点間接続・外部接続などのネットワーク構成や設定項目を事前に検討しておく必要があります。

・データセンター災害時の運用イメージ

では、データセンターに災害が発生したケースを想定します。
※拠点災害時の運用イメージも同様のため割愛します。

災害復旧時の構成イメージ図は"事前展開"のパターンとほぼ同じになりますが、この構成にたどり着くまでの作業が大きく異なります。"オンデマンド展開"のパターンは、SDDCの事前準備が一切できないため、ゼロ（SDDC展開）からリカバリーサイトの設定を行う必要があります。また拠点間接続のネットワークは専用線（AWS Direct Connect）の引き込みが事前に準備することができません。もちろんSDDC展開後に専用線の引き込みを試みることは可能ですが、災害発生後にリカバリーを完了したい数時間の間で専用線の引き込みが可能か？という現実的な問題に直面します。

　

ここまでご紹介したとおり"事前展開"と"オンデマンド展開"では、構成パターンや技術的に利用できることについてはそこまで変わりませんが、VCDRによりクラウドへ保護した仮想マシンのスナップショットを利用し、サーバー（仮想マシン）を起動し始めるまでの準備にどれだけ作業を少なくすることが可能か、という点が大きく変わってきます。つまり、災害発生から復旧までの時間が大きく変わることになります。

拠点やデータセンターの災害発生時に短時間でサーバー（仮想マシン）を起動して復旧させる必要があるシステムの災害対策には、"事前展開"のパターンで構成する事が適切です。逆に、多少の時間がかかってもリカバリーサイトのコストを抑えたい場合は、必要になったタイミングでvSphere環境を準備できる"オンデマンド展開"のパターンを選択できます。ただし、ここまでご紹介したように、災害発生時の作業が非常に多くなるため、入念な計画と作業手順の準備が必要となります。

※補足

専用線（Direct Connect）の事前引き込みについて、VMware Transit Connectサービスを利用することでSDDC展開が不要で専用線を利用することが可能です。VMware Transit Connectサービスは"事前展開"においても利用することができます。

　

ランサムウェア対策（VMware Ransomware Recovery）

ここまで、リカバリーサイトの準備方法の視点でユースケースと運用イメージをご紹介してきましたが、また少し違った視点としてランサムウェア対策のユースケースと特徴について簡単にご紹介します。

VCDRでは、仮想マシンのスナップショットをクラウド上のストレージに定期的に送信しているため、オンプレミスのvSphere環境とはネットワーク的に離れた環境に仮想マシンデータを保持することができます。仮想マシンの複数のリカバリポイントを保持しているため、もし仮想マシンがランサムウェアに感染しても攻撃を受ける前のデータに復旧することが可能です。

また更に、仮想マシンのデータをクラウドストレージに保護することは別に、保持している仮想マシンのスナップショットが安全かどうかをチェックする、ランサムウェア対策アドオン（VMware Ransomware Recovery ）の機能が提供されています。

前章までユースケースでは、拠点やデータセンターなどのサイト自体の災害対策になっていましたが、VMware Ransomware Recoveryアドオンでは、リカバリーサイトをいわゆるステージングサイトとして利用し、その中で仮想マシンのスナップショットが安全かどうか、Carbon Black Cloudのテクノロジーを活用してランサムウェアの感染状況をチェックする仕組みになります。

VMware Ransomware Recoveryアドオンを使ってリカバリーサイト（VMware Cloud on AWSのSDDC）へ展開された仮想マシンは、リカバリーサイト内のランサムウェア感染を防ぐため、NSX Advanced Firewallによってネットワークとして隔離された状態で展開されます。隔離されたSDDC環境で、Carbon Black Cloudによる脆弱性スキャンや振舞い分析を行います。

こういったチェックにより、復元をしようとしている仮想マシンのデータが、ランサムウェアにまだ感染していないタイミングのデータであり安全であること見極めることが可能です。リカバリーサイトはステージングサイトとして扱うことや、そのままリカバリーサイトとして利用することが可能で、災害状況や運用に合せた復旧プランに沿って利用することができます。

　

---

本記事では、ユースケースを交えてVCDRの特徴を紹介しました。VCDRは単体では動作せず、災害時にVMware Cloud on AWSを使い、如何にして復旧までもっていくか、その補助をするツールになります。そのため、事前に復旧までのプランを練り、準備しておくことが非常に大事になります。