* ONTAPクラスタ*：

ピアリング：

* Astra Control Center *：

"Astra Control Centerを導入" シームレスなディザスタリカバリのための第3の障害ドメインまたはセカンダリサイト。

* Astra Trident / ONTAPの設定*：Astra Control Centerでは、ソースクラスタとデスティネーションクラスタの両方のレプリケーションをサポートするストレージバックエンドを少なくとも1つ設定する必要があります。ソースクラスタとデスティネーションクラスタが同じである場合は、耐障害性を最大限に高めるために、デスティネーションアプリケーションでソースアプリケーションとは別のストレージバックエンドを使用する必要があります。

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と宛先アプリケーションを保持します。ソースとデスティネーションのアプリケーションは、独立したアプリケーションとして扱われるようになりました。バックアップスケジュールは、両方のアプリケーションで維持されますが、相互に関連付けられていません。