* Astra Control ProvisionerまたはAstra Trident *：Astra Control ProvisionerまたはAstra Tridentは、ONTAPをバックエンドとして利用するソースとデスティネーションの両方のKubernetesクラスタに存在する必要があります。Astra Controlは、次のドライバでサポートされるストレージクラスを使用して、NetApp SnapMirrorテクノロジによるレプリケーションをサポートします。

ライセンス：Data Protection Bundleを使用するONTAP SnapMirror非同期ライセンスが、ソースとデスティネーションの両方のONTAPクラスタで有効になっている必要があります。を参照してください "ONTAP のSnapMirrorライセンスの概要" を参照してください。

*クラスタとSVM *：ONTAPストレージバックエンドにピア関係が設定されている必要があります。を参照してください "クラスタと SVM のピアリングの概要" を参照してください。

2つのONTAPクラスタ間のレプリケーション関係で使用されるSVM名が一意であることを確認してください。

* Astra Control ProvisionerまたはAstra TridentとSVM *：ピア関係にあるリモートSVMは、デスティネーションクラスタのAstra Control ProvisionerまたはAstra Tridentで使用できる必要があります。

マネージドバックエンド：レプリケーション関係を作成するには、Astra Control CenterでONTAPストレージバックエンドを追加および管理する必要があります。

Astra Control Provisionerを有効にしている場合、Astra Control CenterでONTAPストレージバックエンドの追加と管理はオプションです。

管理対象クラスタ：Astra Controlを使用して次のクラスタを追加、管理できます。理想的には、異なる障害ドメインまたはサイトに配置されます。

ユーザアカウント：ONTAPストレージバックエンドをAstra Control Centerに追加する場合は、「admin」ロールのユーザクレデンシャルを適用します。このロールにはアクセス方法があります http および ontapi ONTAP ソースとデスティネーションの両方のクラスタで有効にします。を参照してください "ONTAP ドキュメントの「ユーザーアカウントの管理」を参照してください" を参照してください。

Astra Control Provisioner機能では、Astra Control Centerでクラスタを管理するために「admin」ロールを明確に定義する必要はありません。これらのクレデンシャルはAstra Control Centerでは必要ありません。

Astra ControlでアプリケーションSnapshotを作成する頻度を選択します（アプリケーションのKubernetesリソースと、アプリケーションの各ボリュームのボリュームSnapshotが含まれます）。

レプリケーションスケジュールの選択（Kubernetesリソースと永続ボリュームデータを含む）

Snapshotの作成時間の設定

デスティネーションにネームスペースを作成します（存在しない場合）。

送信元アプリケーションのPVCに対応する宛先ネームスペースにPVCを作成します。

アプリケーションと整合性のある初期スナップショットを作成します。

最初のSnapshotを使用して、永続ボリュームのSnapMirror関係を確立します。

デスティネーションアプリケーションは、最新のレプリケートされたSnapshotに基づいて起動されます。

ソースクラスタとアプリケーション（動作している場合）は停止されず、引き続き実行されます。

レプリケーションの状態は「フェイルオーバー」に変わり、完了すると「フェイルオーバー」に変わります。

ソースアプリの保護ポリシーは、フェイルオーバー時にソースアプリに存在するスケジュールに基づいて、デスティネーションアプリにコピーされます。

ソースアプリで1つ以上のリストア後の実行フックが有効になっている場合、それらの実行フックはデスティネーションアプリに対して実行されます。

Astra Controlには、ソースクラスタとデスティネーションクラスタの両方のアプリケーションと、それぞれの健全性が表示されます。

Replication（レプリケーション）ページに、レプリケーションステータスとしてEstablishing（確立）が表示されます。

Astra Controlは、新しいデスティネーションクラスタのアプリケーションを停止します。

SnapMirror resyncを使用して、指定した方向に永続的ボリュームのレプリケーションを再確立します。

[レプリケーション]ページに、更新された関係が表示されます。

元のソースアプリのKubernetesリソースのスナップショットが作成されます。

元のソースアプリケーションのポッドは、アプリケーションのKubernetesリソースを削除することで正常に停止されます（PVCとPVはそのまま維持されます）。

ポッドがシャットダウンされると、アプリのボリュームのスナップショットが取得され、レプリケートされます。

SnapMirror関係が解除され、デスティネーションボリュームが読み取り/書き込み可能な状態になります。

アプリのKubernetesリソースは、元のソースアプリがシャットダウンされた後に複製されたボリュームデータを使用して、シャットダウン前のスナップショットから復元されます。

逆方向にレプリケーションが再確立されます。

フェイルオーバー状態から開始します。

関係を再同期します。

レプリケーションを反転する。

関係が確立されていても、アプリケーションがデスティネーションクラスタでオンラインになっていない（フェイルオーバーした）場合、Astra Controlは、初期化中に作成されたPVCを保持し、「空」の管理対象アプリケーションをデスティネーションクラスタに残します。また、作成されたバックアップを保持するためにデスティネーションアプリケーションを保持します。

アプリケーションがデスティネーションクラスタでオンラインになった（フェイルオーバーした）場合、Astra ControlはPVCと宛先アプリケーションを保持します。ソースとデスティネーションのアプリケーションは、独立したアプリケーションとして扱われるようになりました。バックアップスケジュールは、両方のアプリケーションで維持されますが、相互に関連付けられていません。