NetApp Disaster Recovery は、NetApp Console からアクセスできるクラウドベースの災害復旧サービスであり、VMware および Kubernetes 環境における災害復旧ワークフローを自動化します。このサービスは、ONTAP ストレージを実行するオンプレミスの VMware ワークロード、または Trident が管理する ONTAP ストレージを実行する Kubernetes ワークロードを、災害復旧ターゲットとして別のサイトにレプリケートします。このサービスは、ONTAP SnapMirror テクノロジーと、ネイティブの VMware オーケストレーションまたは Trident Protect オーケストレーションを使用して、圧縮や重複排除などの ONTAP ストレージ効率化機能を維持しながらワークロードを保護します。

Disaster Recoveryを有効にするための特別な操作は必要ありません。NetApp Consoleの左側ナビゲーションの「Protection」＞「Disaster recovery」に自動的に表示されます。NetApp Consoleにアクセスするには、ブラウザで「 "https://console.netapp.com/"」と入力します。

完全な継続アクセスには、Disaster Recoveryライセンスが必要です。ライセンスやサブスクリプションを購入する前に、30日間の無料トライアルでサービスをお試しいただけます。詳細については、"災害復旧ライセンスの設定"を参照してください。

NetApp Disaster Recoveryは、以下の保護対象をサポートします。

VMwareワークロードの場合、NetApp Disaster Recoveryは以下のデータストアタイプをサポートします：

Kubernetesワークロードの場合、ディザスターリカバリーは、ONTAPストレージ上のNetApp Tridentを通じてプロビジョニングされた永続ボリュームを保護します。

NetApp Disaster Recoveryには、以下のライセンスオプションが用意されています。

災害復旧料金は、少なくとも1つの仮想マシンまたはKubernetesリソースにレプリケーションプランが設定されている場合、ソースサイトのデータストアの使用容量に基づいて計算されます。

BYOLの場合、データが許容容量を超えると、追加の容量ライセンスを取得するか、NetApp Consoleでライセンスをアップグレードするまで、サービスの操作が制限されます。

無料トライアル期間終了後も、ワークロードやレプリケーションプランなどのリソースの表示や削除、トライアル期間中に作成されたすべてのスケジュール済み操作の実行は引き続き可能です。サービスの全機能を継続して使用するには、クラウド プロバイダから PAYGO サブスクリプションを取得するか、NetApp から BYOL ライセンスを購入する必要があります。

ライセンスの購入やサブスクリプションはいつでも可能で、30日間の無料トライアル期間が終了するまでは料金は発生しません。

NetApp Disaster Recoveryは、以下のトポロジーをサポートしています：

全リストについては、"災害復旧の前提条件"を参照してください。

Consoleエージェントは、NetApp Consoleがお客様のONTAPストレージおよびVMware vCenterクラスタ、またはKubernetesクラスタと通信できるようにするソフトウェアコンポーネントです。これは、Disaster Recoveryが適切に機能するために必要です。エージェントはお客様のプライベートネットワーク（オンプレミスのデータセンターまたはクラウドVPC）に配置され、ONTAPストレージインスタンスおよびvCenterクラスタ、またはKubernetesクラスタと通信します。

オンプレミスからオンプレミスへのディザスタリカバリの場合は、ディザスタリカバリサイトにオンプレミスのConsoleエージェントをインストールします。オンプレミスからAWSへの場合は、AWS VPC内にAWS用Consoleエージェントをインストールします。ソースとデスティネーションの両方のvCenterクラスタまたはKubernetesクラスタで、同じConsoleエージェントを使用する必要があります。ディザスタリカバリは、標準モードのエージェント導入でのみ機能します。

各 Kubernetes クラスターには、NetApp Trident のインストール、ONTAP バックエンドとストレージクラスの構成、およびボリューム スナップショット CRD とコントローラーのインストールが必要です。アプリケーションは、Trident ストレージクラスを通じてプロビジョニングされた永続ボリュームを使用する必要があります。Kubernetes クラスターをサイトとして追加すると、NetApp Disaster Recovery がそのクラスターへの Trident Protect のインストールと登録の手順を案内します。手順ごとのコマンドと検証チェックについては、"NetApp Disaster RecoveryのKubernetesクラスタの要件" を参照してください。

サイトとは、通常、物理的なデータセンターまたはクラウドの場所に関連付けられた論理コンテナであり、1 つ以上のvCenterクラスターまたは Kubernetes クラスターをホストします。レプリケーション計画を作成する前に、ソース（本番）サイトと宛先（ディザスタリカバリ）サイトの両方を追加する必要があります。

リソースグループとは、複数の仮想マシン、データストア、Kubernetesの名前空間およびリソースを単一の単位として管理できる論理コンテナであり、共通のスナップショットで保護することができます。仮想マシンは、一度に1つのリソースグループにしか所属できません。保護したいアプリケーションやワークロードごとにリソースグループを作成できます。

レプリケーション計画とは、バックアップの頻度やフェイルオーバーイベントの処理方法に関する一連のルールのことです。ソースサイトと宛先サイトを選択し、リソースグループを割り当て、リカバリマッピングを定義し、電源投入時の動作を構成します。プランでは、データ複製の頻度を通じて、目標復旧時点（RPO）を定義します。

リカバリポイント目標（RPO）とは、災害発生時に許容できる最大データ損失量のことであり、レプリケーション計画のレプリケーション頻度またはスケジュールによって定義されます。リカバリタイム目標（RTO）とは、災害から復旧するために許容される最大時間のことであり、DRサイトへのフェイルオーバーとすべてのVMまたはアプリケーションの再起動にかかる時間によって決まります。

手順については、"NetApp Disaster Recoveryにサイトを追加する"を参照してください。

検出機能はデフォルトでは24時間ごとに実行されますが、環境に合わせてスケジュールをカスタマイズできます。最短間隔は30分、最長間隔は24時間です。NetApp では、最新の情報を取得するために、まず手動でいくつかの検出を実行し、その後、スケジュールを自動実行に設定することをお勧めします。新しく追加または削除されたリソースは、次回の定期的または手動による検出時に認識されます。

いいえ。保護された仮想マシンと保護されていない仮想マシンを同じデータストアでホストすると、問題が発生する可能性があります。つまり、データストアがフェイルオーバーされた場合、そのデータストア上の保護されていない仮想マシンはフェイルオーバー後にソース上に存在しなくなり、Disaster Recovery はフェイルオーバーサイトでそれらを起動しません。

Disaster Recoveryを導入する前に、リソースを整理して、保護対象のワークロードと保護対象外のワークロードがそれぞれ別のデータストアのサブセットを使用するようにし、単一のデータストアが複数のレプリケーションプランによって保護されないようにする必要があります。

プラットフォーム管理（ONTAP管理）のバックアップを使用する予定がある場合は、*MirrorAll*ポリシーを使用してください。*MirrorVault*および*Asynchronous*も代替として使用できますが、フェイルオーバーまたはフェイルバック中に選択されたスナップショットがソースボリュームとデスティネーションボリュームの両方に存在することを確認する必要があります。存在しない場合、操作は「no common snapshot found」エラーで失敗します。フェイルオーバー用の共通スナップショットが1つしか残らないため、*MirrorLatest*は推奨されません。NetApp Disaster Recoveryが管理するSnapMirror関係については、NetApp Disaster Recoveryがレプリケーションのタイミングを管理するため、サービス外でアップデートをスケジュールしないでください。

はい。保護されたデータストアのソースボリュームと宛先ボリュームの間にSnapMirrorリレーションシップがすでに存在する場合、NetApp Disaster Recoveryは新しいリレーションシップを作成する代わりに、そのリレーションシップをすべてのレプリケーション操作に使用します。

はい。移行用に構成されたレプリケーションプランを使用すると、VMwareアプリケーションをソースサイトから別のサイトに移行できます。移行を開始すると、サービスは30分ごとに移行が計画通りに進んでいるかどうかを確認します。進捗状況はジョブ監視で確認できます。現在、Kubernetesベースのワークロードの移行はサポートされていません。"アプリケーションを別のサイトに移行する"を参照してください。

はい。テストフェイルオーバーでは、元のソースボリュームが変更されたり、SnapMirror関係や本番ワークロードが中断されたりすることはなく、通常どおりレプリケーションが継続されます。VMwareワークロードの場合、Disaster Recoveryは選択したスナップショットのFlexCloneボリュームから一時VMを作成し、FlexCloneをバッキングとする一時データストアをESXiホストにマッピングします。Kubernetesワークロードの場合、テストによってデスティネーション クラスタ上の保護されたアプリケーションと永続ボリュームがリカバリされます。テスト後、*Clean up failover test*アクションを使用してテスト環境をクリーンアップします。"アプリケーションをリモートサイトにフェイルオーバーする"を参照してください。

はい。レプリケーションプランで起動順序を設定します。デフォルトでは、すべてのエンティティが並行して起動しますが、起動順序を制御するために各エンティティに連番（例えば、1、2、3）を割り当てたり、複数のリソースに同じ番号を割り当てて同時に起動したりすることができます。また、リソースごとに起動遅延時間（0～10分）を設定することで、起動をずらすことができます。これは、優先度の高いリソースが最初に実行されるようにするのに役立ちます。VMwareワークロードとKubernetesワークロードの両方で、起動順序がサポートされています。

フェイルバックとは、災害が解決された後、運用を元のソースサイトに復帰させる機能です。NetApp Disaster Recoveryは、ターゲットへのフェイルオーバーが発生した関係から開始し、レプリケーションの方向を反転させる前に、変更内容を元のソース VM または Kubernetes クラスタに再同期します。プロセス：

"アプリケーションを元のソースにフェイルバックする" を参照してください。

Disaster Recovery の Dashboard を使用して、サイトとプランが正常か、切断されているか、劣化しているかを確認したり、最近の警告や失敗したジョブを確認したり、保護されているワークロードと保護されていないワークロードを特定したり、容量を一目で確認したりできます。"ディザスタリカバリプランの健全性を表示する"を参照してください。

ジョブのタイムスタンプ、ステータス、および開始者（Disaster Recovery によって開始された場合は「システム」）を確認するには、「ジョブ監視」を使用します。「実行中」または「キューに追加済み」のジョブは、そのジョブの「アクション」メニューからキャンセルできます。これは、ジョブが停止した場合や、他の操作を優先する必要がある場合に便利です。詳細については、"災害復旧ジョブを監視する"を参照してください。

VMware、Kubernetes、またはすべてのワークロードを対象としたレポートを生成でき、レプリケーション計画の詳細、コンプライアンス状況、ジョブの概要などを網羅できます。レポートはPDF、HTML、またはJSONファイルとしてダウンロードできます。対象期間は1日から7日間です。詳細については、"Disaster Recovery でレポートを作成する"を参照してください。

AppVaultは、Trident ProtectがKubernetesの保護データを保存するクラウドストレージのターゲットです。Kubernetesレプリケーションプランの設定時にAppVaultを作成します。設定ページでAppVaultsを管理することもできます。