日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

NetApp SnapMirrorとTrident Protectを使用してアプリケーションを複製する

10/29/2025 共同作成者

Trident Protect を使用すると、 NetApp SnapMirrorテクノロジーの非同期レプリケーション機能を使用して、データとアプリケーションの変更を、同じクラスター上または異なるクラスター間で、あるストレージバックエンドから別のストレージバックエンドに複製できます。

復元およびフェイルオーバー操作中の名前空間の注釈とラベル

復元およびフェイルオーバー操作中に、宛先名前空間のラベルと注釈は、ソース名前空間のラベルと注釈と一致するように作成されます。宛先名前空間に存在しないソース名前空間のラベルまたは注釈が追加され、既存のラベルまたは注釈はソース名前空間の値と一致するように上書きされます。宛先名前空間にのみ存在するラベルまたは注釈は変更されません。

Red Hat OpenShift を使用する場合は、OpenShift 環境における名前空間アノテーションの重要な役割に注意することが重要です。名前空間アノテーションにより、復元されたポッドが OpenShift のセキュリティコンテキスト制約 (SCC) によって定義された適切な権限とセキュリティ構成に準拠し、権限の問題なくボリュームにアクセスできるようになります。詳細については、 "OpenShift セキュリティコンテキスト制約のドキュメント" 。

Kubernetes環境変数を設定することで、宛先名前空間内の特定のアノテーションが上書きされるのを防ぐことができます。 `RESTORE_SKIP_NAMESPACE_ANNOTATIONS`復元またはフェイルオーバー操作を実行する前に。例えば：

helm upgrade trident-protect --set restoreSkipNamespaceAnnotations=<annotation_key_to_skip_1>,<annotation_key_to_skip_2> --reuse-values

復元またはフェイルオーバー操作を実行する場合、 restoreSkipNamespaceAnnotations そして restoreSkipNamespaceLabels 復元またはフェイルオーバー操作から除外されます。これらの設定が Helm の初期インストール時に構成されていることを確認してください。詳細については、 "AutoSupportと名前空間フィルタリングオプションを構成する"。

ソースアプリケーションをHelmを使用してインストールした場合、 `--create-namespace`旗には特別な扱いが与えられます `name`ラベルキー。復元またはフェイルオーバープロセス中に、 Trident Protect はこのラベルを宛先名前空間にコピーしますが、ソースからの値がソース名前空間と一致する場合は、値を宛先名前空間の値に更新します。この値がソース名前空間と一致しない場合は、変更されずに宛先名前空間にコピーされます。

例

次の例は、それぞれ異なる注釈とラベルを持つソース名前空間と宛先名前空間を示しています。操作の前後の宛先名前空間の状態や、宛先名前空間で注釈とラベルがどのように結合または上書きされるかを確認できます。

復元またはフェイルオーバー操作の前に

次の表は、復元またはフェイルオーバー操作前のサンプルのソース名前空間と宛先名前空間の状態を示しています。

ネームスペース	アノテーション	ラベル
名前空間 ns-1 (ソース)	アノテーション.one/キー: "更新された値" アノテーション.2/キー: "true"	環境=本番環境コンプライアンス=HIPAA 名前=ns-1
名前空間 ns-2 (宛先)	アノテーション.one/キー: "true" 注釈.three/キー: "false"	役割=データベース

ネームスペース

アノテーション

ラベル

名前空間 ns-1 (ソース)

アノテーション.one/キー: "更新された値"
アノテーション.2/キー: "true"

環境=本番環境
コンプライアンス=HIPAA
名前=ns-1

名前空間 ns-2 (宛先)

アノテーション.one/キー: "true"
注釈.three/キー: "false"

役割=データベース

復元操作後

次の表は、復元またはフェイルオーバー操作後の宛先名前空間の例の状態を示しています。いくつかのキーが追加され、いくつかは上書きされ、 `name`ラベルは宛先名前空間と一致するように更新されました:

ネームスペース	アノテーション	ラベル
名前空間 ns-2 (宛先)	アノテーション.one/キー: "更新された値" アノテーション.2/キー: "true" 注釈.three/キー: "false"	名前=ns-2 コンプライアンス=HIPAA 環境=本番環境役割=データベース

ネームスペース

アノテーション

ラベル

名前空間 ns-2 (宛先)

アノテーション.one/キー: "更新された値"
アノテーション.2/キー: "true"
注釈.three/キー: "false"

名前=ns-2
コンプライアンス=HIPAA
環境=本番環境
役割=データベース

データ保護操作中にファイルシステムをフリーズおよびアンフリーズするようにTrident protect を構成できます。"Trident Protectを使用したファイルシステムのフリーズ設定の詳細"。

フェイルオーバーおよびリバース操作中の実行フック

AppMirror 関係を使用してアプリケーションを保護する場合、フェイルオーバーおよびリバース操作中に注意する必要がある実行フックに関連する特定の動作があります。

フェイルオーバー中、実行フックはソースクラスターから宛先クラスターに自動的にコピーされます。手動で再作成する必要はありません。フェイルオーバー後、実行フックがアプリケーション上に存在し、関連するアクション中に実行されます。
リバースまたはリバース再同期中に、アプリケーションの既存の実行フックはすべて削除されます。ソースアプリケーションが宛先アプリケーションになると、これらの実行フックは無効になり、実行されないように削除されます。

実行フックの詳細については、以下を参照してください。"Trident の保護実行フックを管理する" 。

レプリケーション関係を設定する

レプリケーション関係の設定には、次の作業が含まれます。

Trident Protect がアプリのスナップショット (アプリの Kubernetes リソースとアプリの各ボリュームのボリュームスナップショットが含まれます) を取得する頻度を選択します。
レプリケーションスケジュールの選択 (Kubernetes リソースと永続ボリュームデータを含む)
スナップショットを撮影する時間を設定する

手順

ソースクラスターで、ソースアプリケーション用の AppVault を作成します。ストレージプロバイダに応じて、以下の例を変更します。"AppVault カスタムリソース"あなたの環境に合わせて:
CRを使用してAppVaultを作成する
カスタムリソース（CR）ファイルを作成し、名前を付けます（例： trident-protect-appvault-primary-source.yaml ）。

次の属性を構成します。

metadata.name: (必須) AppVault カスタムリソースの名前。レプリケーション関係に必要な他の CR ファイルはこの値を参照するため、選択した名前をメモしておいてください。

spec.providerConfig: (必須) 指定されたプロバイダーを使用して AppVault にアクセスするために必要な構成を保存します。プロバイダーの bucketName とその他の必要な詳細を選択します。レプリケーション関係に必要な他の CR ファイルがこれらの値を参照するため、選択した値をメモしておいてください。参照"AppVault カスタムリソース"他のプロバイダーとの AppVault CR の例。

spec.providerCredentials: (必須) 指定されたプロバイダーを使用して AppVault にアクセスするために必要な資格情報への参照を格納します。

spec.providerCredentials.valueFromSecret: (必須) 資格情報の値がシークレットから取得される必要があることを示します。

key: (必須) 選択するシークレットの有効なキー。

name: (必須) このフィールドの値を含むシークレットの名前。同じ名前空間に存在する必要があります。

spec.providerCredentials.secretAccessKey: (必須) プロバイダーにアクセスするために使用するアクセスキー。 name は spec.providerCredentials.valueFromSecret.name と一致する必要があります。

spec.providerType: (必須) バックアップを提供するものを決定します。たとえば、 NetApp ONTAP S3、汎用 S3、Google Cloud、Microsoft Azure などです。有効な値は次のとおりです。

AWS

紺碧

gcp

ジェネリックS3

オンタップS3

ストレージグリッドS3

入力したら `trident-protect-appvault-primary-source.yaml`正しい値を持つファイルには、CR を適用します。

kubectl apply -f trident-protect-appvault-primary-source.yaml -n trident-protect
CLI を使用して AppVault を作成する
括弧内の値を環境の情報に置き換えて、AppVault を作成します。

tridentctl-protect create vault Azure <vault-name> --account <account-name> --bucket <bucket-name> --secret <secret-name>
ソースクラスターで、ソースアプリケーション CR を作成します。
CRを使用してソースアプリケーションを作成する
カスタムリソース（CR）ファイルを作成し、名前を付けます（例： trident-protect-app-source.yaml ）。

次の属性を構成します。

metadata.name: (必須) アプリケーションのカスタムリソースの名前。レプリケーション関係に必要な他の CR ファイルはこの値を参照するため、選択した名前をメモしておいてください。

spec.includedNamespaces: (必須) 名前空間と関連ラベルの配列。ここにリストされている名前空間内に存在するリソースを指定するには、名前空間名を使用し、オプションでラベルを使用して名前空間の範囲を絞り込みます。アプリケーション名前空間はこの配列の一部である必要があります。

YAMLの例:

--- apiVersion: protect.trident.netapp.io/v1 kind: Application metadata: name: my-app-name namespace: my-app-namespace spec: includedNamespaces: - namespace: my-app-namespace labelSelector: {}

入力したら `trident-protect-app-source.yaml`正しい値を持つファイルには、CR を適用します。

kubectl apply -f trident-protect-app-source.yaml -n my-app-namespace
CLIを使用してソースアプリケーションを作成する
ソースアプリケーションを作成します。例えば：

tridentctl-protect create app <my-app-name> --namespaces <namespaces-to-be-included> -n <my-app-namespace>

必要に応じて、ソースクラスターでソースアプリケーションのスナップショットを取得します。このスナップショットは、宛先クラスター上のアプリケーションのベースとして使用されます。この手順をスキップした場合は、最新のスナップショットを取得するために、次にスケジュールされたスナップショットが実行されるまで待つ必要があります。

以下に示すスケジュールに加えて、ピア接続されたONTAPクラスタ間で共通のスナップショットを維持するために、保持期間が 7 日間の個別の毎日のスナップショットスケジュールを作成することをお勧めします。これにより、スナップショットは最大 7 日間利用できるようになりますが、保持期間はユーザーの要件に基づいてカスタマイズできます。

フェイルオーバーが発生した場合、システムはこれらのスナップショットを最大 7 日間使用して逆の操作を行うことができます。この方法では、すべてのデータではなく、最後のスナップショット以降に行われた変更のみが転送されるため、逆のプロセスがより高速かつ効率的になります。

アプリケーションの既存のスケジュールがすでに必要な保持要件を満たしている場合は、追加のスケジュールは必要ありません。

CRを使用してスナップショットを撮る

ソースアプリケーションのレプリケーションスケジュールを作成します。
1. カスタムリソース（CR）ファイルを作成し、名前を付けます（例： trident-protect-schedule.yaml ）。
2. 次の属性を構成します。
  - metadata.name: (必須) スケジュールカスタムリソースの名前。
  - spec.AppVaultRef: (必須) この値は、ソースアプリケーションの AppVault の metadata.name フィールドと一致する必要があります。
  - spec.ApplicationRef: (必須) この値は、ソースアプリケーション CR の metadata.name フィールドと一致する必要があります。
  - spec.backupRetention: (必須) このフィールドは必須であり、値は 0 に設定する必要があります。
  - spec.enabled: true に設定する必要があります。
  - spec.granularity: に設定する必要があります Custom。
  - spec.recurrenceRule: UTC 時間での開始日と繰り返し間隔を定義します。
  - spec.snapshotRetention: 2 に設定する必要があります。
    
    YAMLの例:
```
---
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  name: appmirror-schedule-0e1f88ab-f013-4bce-8ae9-6afed9df59a1
  namespace: my-app-namespace
spec:
  appVaultRef: generic-s3-trident-protect-src-bucket-04b6b4ec-46a3-420a-b351-45795e1b5e34
  applicationRef: my-app-name
  backupRetention: "0"
  enabled: true
  granularity: custom
  recurrenceRule: |-
    DTSTART:20220101T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  snapshotRetention: "2"
```
1. 入力したら `trident-protect-schedule.yaml`正しい値を持つファイルには、CR を適用します。
  kubectl apply -f trident-protect-schedule.yaml -n my-app-namespace

CLIを使用してスナップショットを取得する

括弧内の値を環境の情報に置き換えてスナップショットを作成します。例えば：

tridentctl-protect create snapshot <my_snapshot_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot> -n <application_namespace>

宛先クラスタで、ソースクラスタに適用したAppVault CRと同一のソースアプリケーションAppVault CRを作成し、名前を付けます（例： trident-protect-appvault-primary-destination.yaml ）。

CR を適用します。

kubectl apply -f trident-protect-appvault-primary-destination.yaml -n my-app-namespace

宛先クラスター上の宛先アプリケーション用の宛先 AppVault CR を作成します。ストレージプロバイダに応じて、以下の例を変更します。"AppVault カスタムリソース"あなたの環境に合わせて:
1. カスタムリソース（CR）ファイルを作成し、名前を付けます（例： trident-protect-appvault-secondary-destination.yaml ）。
2. 次の属性を構成します。
  - metadata.name: (必須) AppVault カスタムリソースの名前。レプリケーション関係に必要な他の CR ファイルはこの値を参照するため、選択した名前をメモしておいてください。
  - spec.providerConfig: (必須) 指定されたプロバイダーを使用して AppVault にアクセスするために必要な構成を保存します。選択してください `bucketName`およびプロバイダーに関するその他の必要な詳細情報。レプリケーション関係に必要な他の CR ファイルがこれらの値を参照するため、選択した値をメモしておいてください。参照"AppVault カスタムリソース"他のプロバイダーとの AppVault CR の例。
  - spec.providerCredentials: (必須) 指定されたプロバイダーを使用して AppVault にアクセスするために必要な資格情報への参照を格納します。
    
    spec.providerCredentials.valueFromSecret: (必須) 資格情報の値がシークレットから取得される必要があることを示します。
    
    key: (必須) 選択するシークレットの有効なキー。
    
    name: (必須) このフィールドの値を含むシークレットの名前。同じ名前空間に存在する必要があります。
    
    spec.providerCredentials.secretAccessKey: (必須) プロバイダーにアクセスするために使用するアクセスキー。 name は spec.providerCredentials.valueFromSecret.name と一致する必要があります。
  - spec.providerType: (必須) バックアップを提供するものを決定します。たとえば、 NetApp ONTAP S3、汎用 S3、Google Cloud、Microsoft Azure などです。有効な値は次のとおりです。
    
    AWS
    
    紺碧
    
    gcp
    
    ジェネリックS3
    
    オンタップS3
    
    ストレージグリッドS3
3. 入力したら `trident-protect-appvault-secondary-destination.yaml`正しい値を持つファイルには、CR を適用します。
  kubectl apply -f trident-protect-appvault-secondary-destination.yaml -n my-app-namespace
宛先クラスターで、AppMirrorRelationship CR ファイルを作成します。
CRを使用してAppMirrorRelationshipを作成する
カスタムリソース（CR）ファイルを作成し、名前を付けます（例： trident-protect-relationship.yaml ）。

次の属性を構成します。

metadata.name: (必須) AppMirrorRelationship カスタムリソースの名前。

spec.destinationAppVaultRef: (必須) この値は、宛先クラスター上の宛先アプリケーションの AppVault の名前と一致する必要があります。

spec.namespaceMapping: (必須) 宛先名前空間とソース名前空間は、それぞれのアプリケーション CR で定義されているアプリケーション名前空間と一致する必要があります。

spec.sourceAppVaultRef: (必須) この値は、ソースアプリケーションの AppVault の名前と一致する必要があります。

spec.sourceApplicationName: (必須) この値は、ソースアプリケーション CR で定義したソースアプリケーションの名前と一致する必要があります。

spec.storageClassName: (必須) クラスター上の有効なストレージクラスの名前を選択します。ストレージクラスは、ソース環境とピアリングされているONTAPストレージ VM にリンクされている必要があります。

spec.recurrenceRule: UTC 時間での開始日と繰り返し間隔を定義します。

YAMLの例:

--- apiVersion: protect.trident.netapp.io/v1 kind: AppMirrorRelationship metadata: name: amr-16061e80-1b05-4e80-9d26-d326dc1953d8 namespace: my-app-namespace spec: desiredState: Established destinationAppVaultRef: generic-s3-trident-protect-dst-bucket-8fe0b902-f369-4317-93d1-ad7f2edc02b5 namespaceMapping: - destination: my-app-namespace source: my-app-namespace recurrenceRule: |- DTSTART:20220101T000200Z RRULE:FREQ=MINUTELY;INTERVAL=5 sourceAppVaultRef: generic-s3-trident-protect-src-bucket-b643cc50-0429-4ad5-971f-ac4a83621922 sourceApplicationName: my-app-name sourceApplicationUID: 7498d32c-328e-4ddd-9029-122540866aeb storageClassName: sc-vsim-2

入力したら `trident-protect-relationship.yaml`正しい値を持つファイルには、CR を適用します。

kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace
CLIを使用してAppMirrorRelationshipを作成する
括弧内の値を環境の情報に置き換えて、AppMirrorRelationship オブジェクトを作成して適用します。例えば：

tridentctl-protect create appmirrorrelationship <name_of_appmirorrelationship> --destination-app-vault <my_vault_name> --recurrence-rule <rule> --source-app <my_source_app> --source-app-vault <my_source_app_vault> -n <application_namespace>
(オプション) 宛先クラスターで、レプリケーション関係の状態とステータスを確認します。
```
kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq
```

宛先クラスタへのフェイルオーバー

Trident Protect を使用すると、複製されたアプリケーションを宛先クラスターにフェイルオーバーできます。この手順により、レプリケーション関係が停止され、宛先クラスターでアプリがオンラインになります。 Trident Protect は、ソースクラスター上のアプリが稼働中であった場合、そのアプリを停止しません。

手順

宛先クラスタで、AppMirrorRelationship CRファイルを編集します（例： trident-protect-relationship.yaml ）の*spec.desiredState*の値を次のように変更します。 Promoted 。
CR ファイルを保存します。

CR を適用します。

kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace

(オプション) フェールオーバーされたアプリケーションで必要な保護スケジュールを作成します。
(オプション) レプリケーション関係の状態とステータスを確認します。
```
kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq
```

フェイルオーバーしたレプリケーション関係を再同期する

再同期操作により、レプリケーション関係が再確立されます。再同期操作を実行すると、元のソースアプリケーションが実行中のアプリケーションになり、宛先クラスター上の実行中のアプリケーションに加えられた変更はすべて破棄されます。

このプロセスでは、レプリケーションを再確立する前に、宛先クラスター上のアプリを停止します。

フェイルオーバー中に宛先アプリケーションに書き込まれたデータはすべて失われます。

手順

オプション: ソースクラスターで、ソースアプリケーションのスナップショットを作成します。これにより、ソースクラスターからの最新の変更が確実にキャプチャされます。
宛先クラスタで、AppMirrorRelationship CRファイルを編集します（例： trident-protect-relationship.yaml ）spec.desiredStateの値を次のように変更します。 Established 。
CR ファイルを保存します。

CR を適用します。

kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace

フェールオーバーされたアプリケーションを保護するために宛先クラスターに保護スケジュールを作成した場合は、それらを削除します。スケジュールが残っていると、ボリュームスナップショットが失敗します。

フェイルオーバーされたレプリケーション関係を逆再同期する

フェールオーバーされたレプリケーション関係を逆再同期すると、宛先アプリケーションがソースアプリケーションになり、ソースが宛先になります。フェイルオーバー中に宛先アプリケーションに加えられた変更は保持されます。

手順

元の宛先クラスターで、AppMirrorRelationship CR を削除します。これにより、宛先がソースになります。新しい宛先クラスターに保護スケジュールが残っている場合は、それらを削除します。
元々関係を設定するために使用した CR ファイルを反対側のクラスターに適用して、レプリケーション関係を設定します。
新しい宛先 (元のソースクラスター) が両方の AppVault CR で構成されていることを確認します。
反対方向の値を設定して、反対側のクラスターにレプリケーション関係を設定します。

アプリケーションのレプリケーション方向を逆にする

レプリケーションの方向を逆にすると、 Trident Protect は、元のソースストレージバックエンドへのレプリケーションを継続しながら、アプリケーションを宛先ストレージバックエンドに移動します。 Trident Protect は、ソースアプリケーションを停止し、宛先アプリにフェールオーバーする前にデータを宛先に複製します。

この状況では、ソースと宛先が入れ替わっています。

手順

ソースクラスターで、シャットダウンスナップショットを作成します。
CRを使用してシャットダウンスナップショットを作成する
ソースアプリケーションの保護ポリシースケジュールを無効にします。

ShutdownSnapshot CR ファイルを作成します。

カスタムリソース（CR）ファイルを作成し、名前を付けます（例： trident-protect-shutdownsnapshot.yaml ）。

次の属性を構成します。

metadata.name: (必須) カスタムリソースの名前。

spec.AppVaultRef: (必須) この値は、ソースアプリケーションの AppVault の metadata.name フィールドと一致する必要があります。

spec.ApplicationRef: (必須) この値は、ソースアプリケーション CR ファイルの metadata.name フィールドと一致する必要があります。

YAMLの例:

--- apiVersion: protect.trident.netapp.io/v1 kind: ShutdownSnapshot metadata: name: replication-shutdown-snapshot-afc4c564-e700-4b72-86c3-c08a5dbe844e namespace: my-app-namespace spec: appVaultRef: generic-s3-trident-protect-src-bucket-04b6b4ec-46a3-420a-b351-45795e1b5e34 applicationRef: my-app-name

入力したら `trident-protect-shutdownsnapshot.yaml`正しい値を持つファイルには、CR を適用します。

kubectl apply -f trident-protect-shutdownsnapshot.yaml -n my-app-namespace
CLIを使用してシャットダウンスナップショットを作成する
括弧内の値を環境の情報に置き換えて、シャットダウンスナップショットを作成します。例えば：

tridentctl-protect create shutdownsnapshot <my_shutdown_snapshot> --appvault <my_vault> --app <app_to_snapshot> -n <application_namespace>
ソースクラスターで、シャットダウンスナップショットが完了したら、シャットダウンスナップショットのステータスを取得します。
```
kubectl get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o yaml
```
ソースクラスターで、次のコマンドを使用して shutdownsnapshot.status.appArchivePath の値を見つけ、ファイルパスの最後の部分 (ベース名とも呼ばれ、最後のスラッシュの後のすべて) を記録します。
```
k get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o jsonpath='{.status.appArchivePath}'
```

次の変更を加えて、新しい宛先クラスターから新しいソースクラスターへのフェイルオーバーを実行します。

フェイルオーバー手順のステップ2では、 spec.promotedSnapshot AppMirrorRelationship CR ファイルのフィールドに追加し、その値を上記の手順 3 で記録したベース名に設定します。

逆再同期の手順を実行します。フェイルオーバーされたレプリケーション関係を逆再同期する。
新しいソースクラスターで保護スケジュールを有効にします。

結果

逆レプリケーションにより、次のアクションが発生します。

元のソースアプリの Kubernetes リソースのスナップショットが取得されます。
元のソースアプリのポッドは、アプリの Kubernetes リソースを削除することで正常に停止されます (PVC と PV はそのまま残ります)。
ポッドがシャットダウンされると、アプリのボリュームのスナップショットが取得され、複製されます。
SnapMirror関係が解除され、宛先ボリュームは読み取り/書き込み可能になります。
アプリの Kubernetes リソースは、元のソースアプリがシャットダウンされた後に複製されたボリュームデータを使用して、シャットダウン前のスナップショットから復元されます。
レプリケーションは逆方向に再確立されます。

アプリケーションを元のソースクラスタにフェイルバックする

Trident Protect を使用すると、次の一連の操作によって、フェイルオーバー操作後に「フェイルバック」を実現できます。元のレプリケーション方向を復元するこのワークフローでは、 Trident Protect は、レプリケーション方向を反転する前に、アプリケーションの変更を元のソースアプリケーションに複製 (再同期) します。

このプロセスは、宛先へのフェイルオーバーを完了した関係から開始され、次の手順が含まれます。

フェイルオーバー状態から開始します。
レプリケーション関係を逆再同期します。

通常の再同期操作は実行しないでください。フェイルオーバー手順中に宛先クラスターに書き込まれたデータが破棄されます。
レプリケーションの方向を逆にします。

手順

実行するフェイルオーバーされたレプリケーション関係を逆再同期する手順。
実行するアプリケーションのレプリケーション方向を逆にする手順。

レプリケーション関係を削除する

レプリケーション関係はいつでも削除できます。アプリケーションレプリケーション関係を削除すると、関係のない 2 つの別個のアプリケーションが作成されます。

手順

現在の宛先クラスターで、AppMirrorRelationship CR を削除します。
```
kubectl delete -f trident-protect-relationship.yaml -n my-app-namespace
```

NetApp SnapMirrorとTrident Protectを使用してアプリケーションを複製する

Creating your file...

復元およびフェイルオーバー操作中の名前空間の注釈とラベル

例

復元またはフェイルオーバー操作の前に

復元操作後

フェイルオーバーおよびリバース操作中の実行フック

レプリケーション関係を設定する

宛先クラスタへのフェイルオーバー

フェイルオーバーしたレプリケーション関係を再同期する

フェイルオーバーされたレプリケーション関係を逆再同期する

アプリケーションのレプリケーション方向を逆にする

結果

アプリケーションを元のソースクラスタにフェイルバックする

レプリケーション関係を削除する