その "Azure VMware ソリューション"(AVS) は、Microsoft Azure パブリック クラウド内で完全に機能する VMware SDDC を提供するハイブリッド クラウド サービスです。 AVS は、Microsoft によって完全に管理およびサポートされ、Azure インフラストラクチャを使用する VMware によって検証されたファーストパーティ ソリューションです。そのため、お客様は、コンピューティング仮想化用の VMware ESXi、ハイパーコンバージド ストレージ用の vSAN、ネットワークとセキュリティ用の NSX を利用できると同時に、Microsoft Azure のグローバルな展開、クラス最高のデータセンター設備、ネイティブ Azure サービスとソリューションの豊富なエコシステムへの近接性を活用できます。 Azure VMware Solution SDDC とAzure NetApp Files を組み合わせることで、最小限のネットワーク待機時間で最高のパフォーマンスが得られます。

AzureでAVSプライベートクラウドを構成するには、次の手順に従ってください。"リンク" NetAppのドキュメントとこの "リンク"Microsoft ドキュメント。最小限の構成でセットアップされたパイロットライト環境は、DR の目的で使用できます。このセットアップには、重要なアプリケーションをサポートするためのコア コンポーネントのみが含まれており、フェイルオーバーが発生した場合には、スケールアウトしてより多くのホストを生成し、負荷の大部分を処理できます。

"Azure NetApp Files"は、高性能でエンタープライズ クラスの従量制ファイル ストレージ サービスです。この手順に従ってください "リンク"Azure NetApp Files をNFS データストアとしてプロビジョニングおよび構成し、AVS プライベート クラウドの展開を最適化します。

プラットフォームを追加したら、回復する VM をリソース グループにグループ化します。 DRO リソース グループを使用すると、依存する VM のセットを、ブート順序、ブート遅延、および回復時に実行できるオプションのアプリケーション検証を含む論理グループにグループ化できます。

リソース グループの作成を開始するには、[新しいリソース グループの作成] メニュー項目をクリックします。

災害が発生した場合にアプリケーションを回復するための計画が必要です。ドロップダウンからソースとターゲットの vCenter プラットフォームを選択し、このプランに含めるリソース グループを選択します。また、アプリケーションを復元してパワーオンする方法のグループ化も含めます (たとえば、ドメイン コントローラ、Tier-1、Tier-2 など)。計画は青写真とも呼ばれることがあります。リカバリ プランを定義するには、[レプリケーション プラン] タブに移動し、[新しいレプリケーション プラン] をクリックします。

レプリケーション プランの作成を開始するには、次の手順を実行します。

フェールオーバーおよびテスト フェールオーバーのオプションでは、最新のスナップショットが使用されるか、または特定の時点のスナップショットから特定のスナップショットを選択することもできます。最新のレプリカがすでに侵害または暗号化されているランサムウェアなどの破損イベントに直面している場合、ポイントインタイム オプションは非常に役立ちます。 DRO は利用可能なすべての時点を表示します。

レプリケーション プランで指定された構成でフェイルオーバーをトリガーするか、フェイルオーバーをテストするには、フェイルオーバー または フェイルオーバーのテスト をクリックします。タスク メニューでレプリケーション プランを監視できます。

フェイルオーバーがトリガーされると、回復されたアイテムがセカンダリ サイトの AVS SDDC vCenter (VM、ネットワーク、データストア) に表示されます。デフォルトでは、VM はワークロード フォルダーに回復されます。

フェイルバックはレプリケーション プラン レベルでトリガーできます。テストフェイルオーバーの場合、ティアダウン オプションを使用して変更をロールバックし、新しく作成されたボリュームを削除できます。フェイルオーバーに関連するフェイルバックは 2 段階のプロセスです。レプリケーション プランを選択し、逆データ同期 を選択します。

この手順が完了したら、フェイルバックをトリガーしてプライマリ AVS サイトに戻ります。

Azure ポータルから、セカンダリ サイトの AVS SDDC に読み取り/書き込みボリュームとしてマップされた適切なボリュームのレプリケーションの正常性が失われていることがわかります。テスト フェイルオーバー中、DRO は宛先ボリュームまたはレプリカ ボリュームをマップしません。代わりに、必要なリージョン間レプリケーション スナップショットの新しいボリュームを作成し、そのボリュームをデータストアとして公開します。これにより、容量プールから追加の物理容量が消費され、ソース ボリュームが変更されないようになります。特に、レプリケーション ジョブは DR テスト中またはトリアージ ワークフロー中でも継続できます。さらに、このプロセスにより、エラーが発生したり破損したデータが回復されたりした場合にレプリカが破壊されるリスクなしに、回復をクリーンアップできるようになります。

ランサムウェアからの回復は困難な作業になる可能性があります。具体的には、IT 組織にとって、安全な復帰ポイントがどこなのかを正確に特定することが困難になる可能性があり、また、それが決定された後、回復したワークロードが再発する攻撃 (たとえば、休眠中のマルウェアや脆弱なアプリケーションによるもの) から確実に保護されるようにする方法も困難になります。

DRO は、組織が利用可能な任意の時点から回復できるようにすることで、これらの懸念に対処します。その後、ワークロードは機能的でありながら分離されたネットワークに回復され、アプリケーションは機能し相互に通信できるようになりますが、南北トラフィックにはさらされません。このプロセスにより、セキュリティ チームは安全な場所でフォレンジックを実施し、隠れたマルウェアや潜伏中のマルウェアを特定できるようになります。

このドキュメントに記載されている情報の詳細については、次のドキュメントや Web サイトを参照してください。