Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

NetApp SnapMirrorとTrident Protectを使用したアプリケーションのレプリケート

PDF

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

リストアおよびフェイルオーバー処理中のネームスペースのアノテーションとラベル

復元およびフェイルオーバー処理中に、デスティネーションネームスペースのラベルとアノテーションは、ソースネームスペースのラベルとアノテーションと一致するように作成されます。デスティネーションネームスペースに存在しないソースネームスペースのラベルまたはアノテーションが追加され、既存のラベルまたはアノテーションはソースネームスペースの値と一致するように上書きされます。デスティネーションネームスペースにのみ存在するラベルまたはアノテーションは変更されません。

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

リストアまたはフェイルオーバー処理を実行する前にKubernetes環境変数 `RESTORE_SKIP_NAMESPACE_ANNOTATIONS`を設定することで、デスティネーションネームスペース内の特定のアノテーションが上書きされるのを防ぐことができます。例：

helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect \
  --set-string restoreSkipNamespaceAnnotations="{<annotation_key_to_skip_1>,<annotation_key_to_skip_2>}" \
  --reuse-values
メモ 復元またはフェイルオーバー操作を実行する場合、 `restoreSkipNamespaceAnnotations`および `restoreSkipNamespaceLabels`で指定されたネームスペースのアノテーションとラベルは、復元またはフェイルオーバー操作から除外されます。これらの設定がHelmの初期インストール時に構成されていることを確認してください。詳細については、"追加のTrident Protectヘルムチャート設定を構成する"を参照してください。

Helm を使用して `--create-namespace`フラグを指定してソースアプリケーションをインストールした場合、 `name`ラベルキーには特別な処理が適用されます。リストアまたはフェイルオーバープロセス中に、 Trident Protect はこのラベルをデスティネーションネームスペースにコピーしますが、ソースからの値がソースネームスペースと一致する場合は、値をデスティネーションネームスペースの値に更新します。この値がソースネームスペースと一致しない場合は、変更されずにデスティネーションネームスペースにコピーされます。

例

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

リストアまたはフェイルオーバー処理の前に

次の表は、リストアまたはフェイルオーバー処理前のサンプルのソースネームスペースとデスティネーションネームスペースの状態を示しています：

ネームスペース アノテーション ラベル

ネームスペースns-1（ソース）

  • annotation.one/key："updatedvalue"

  • annotation.two/key："true"

  • environment=production

  • コンプライアンス＝hipaa

  • name=ns-1

ネームスペースns-2（宛先）

  • annotation.one/key："true"

  • annotation.three/key："false"

  • ロール＝database

リストア処理後

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

ネームスペース アノテーション ラベル

ネームスペースns-2（宛先）

  • annotation.one/key："updatedvalue"

  • annotation.two/key："true"

  • annotation.three/key："false"

  • name=ns-2

  • コンプライアンス＝hipaa

  • environment=production

  • ロール＝database
メモ Trident Protectを設定して、データ保護操作中にファイルシステムをフリーズおよびフリーズ解除することができます。"Trident Protectを使用したファイルシステムのフリーズの設定の詳細については、こちらをご覧ください".

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

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

  • フェイルオーバー中、実行フックはソースクラスタからデスティネーション クラスタに自動的にコピーされます。手動で再作成する必要はありません。フェイルオーバー後、実行フックがアプリケーション上に存在し、関連するアクション中に実行されます。

  • リバースまたはリバース再同期中に、アプリケーションの既存の実行フックはすべて削除されます。ソース アプリケーションがデスティネーション アプリケーションになると、これらの実行フックは無効になり、実行されないように削除されます。

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

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

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

  • Trident Protect でアプリのスナップショット（アプリの Kubernetes リソースとアプリの各ボリュームのボリューム スナップショットが含まれます）を取得する頻度を選択します

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

  • スナップショットを作成する時間を設定する

手順

  1. ソースクラスタで、ソース アプリケーション用のAppVaultを作成します。ストレージプロバイダに応じて、"AppVault カスタムリソース"の例を環境に合わせて変更します：

    CR を使用して AppVault を作成する

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

    2. 次の属性を設定します：

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

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

      • 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

        • azure

        • gcp

        • generic-s3

        • ontap-s3

        • storagegrid-s3

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

      kubectl apply -f trident-protect-appvault-primary-source.yaml -n trident-protect
    CLIを使用してAppVaultを作成する

    1. AppVaultを作成します。括弧内の値は、実際の環境の情報に置き換えてください：

      tridentctl-protect create vault Azure <vault-name> --account <account-name> --bucket <bucket-name> --secret <secret-name> -n trident-protect

  2. ソース クラスタで、ソース アプリケーション CR を作成します：

    CRを使用してソースアプリケーションを作成する

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

    2. 次の属性を設定します：

      • 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: {}

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

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

    1. ソース アプリケーションを作成します。例：

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

  3. 必要に応じて、ソース クラスターでソース アプリケーションのスナップショットを取得します。このスナップショットは、デスティネーション クラスタ上のアプリケーションの基盤として使用されます。この手順をスキップした場合は、最新のスナップショットを取得するために、次にスケジュールされたスナップショットが実行されるまで待つ必要があります。オンデマンド スナップショットを作成するには、"オンデマンドスナップショットを作成する"を参照してください。

  4. ソース クラスタで、レプリケーション スケジュール CR を作成します：

    メモ

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

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

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

    1. ソース アプリケーションのレプリケーション スケジュールを作成します：

      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
  namespace: my-app-namespace
spec:
  appVaultRef: my-appvault-name
  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 を使用してレプリケーションスケジュールを作成する

    1. 括弧内の値を環境の情報に置き換えて、レプリケーション スケジュールを作成します：

      tridentctl-protect create schedule --name appmirror-schedule --app <my_app_name> --appvault <my_app_vault> --granularity Custom --recurrence-rule <rule> --snapshot-retention <snapshot_retention_count> -n <my_app_namespace>

      例：

      tridentctl-protect create schedule --name appmirror-schedule --app <my_app_name> --appvault <my_app_vault> --granularity Custom --recurrence-rule  "DTSTART:20220101T000200Z\nRRULE:FREQ=MINUTELY;INTERVAL=5" --snapshot-retention 2 -n <my_app_namespace>

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

  6. CR を適用します：

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

  7. デスティネーション クラスタ上のデスティネーションアプリケーション用のデスティネーションAppVault CRを作成します。ストレージプロバイダに応じて、"AppVault カスタムリソース"の例を環境に合わせて変更します：

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

    2. 次の属性を設定します：

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

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

      • 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

        • azure

        • gcp

        • generic-s3

        • ontap-s3

        • storagegrid-s3

    3. `trident-protect-appvault-secondary-destination.yaml`ファイルに正しい値を入力したら、CRを適用します：

      kubectl apply -f trident-protect-appvault-secondary-destination.yaml -n trident-protect

  8. デスティネーション クラスタで、AppMirrorRelationship CR ファイルを作成します。

    メモ CR を使用する場合は、CR を適用する前に、デスティネーション ネームスペースを手動で作成します。Trident Protect は、CLI を使用する場合にのみネームスペースを自動的に作成します。
    CRを使用してAppMirrorRelationshipを作成する

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

    2. 次の属性を設定します：

      • metadata.name:（必須）AppMirrorRelationshipカスタム リソースの名前。

      • spec.destinationAppVaultRef：（必須）この値は、デスティネーション クラスタ上のデスティネーション アプリケーションのAppVaultの名前と一致する必要があります。

      • spec.namespaceMapping：（必須）デスティネーション名前空間とソース名前空間は、それぞれのアプリケーション CR で定義されたアプリケーション名前空間と一致する必要があります。

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

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

      • spec.sourceApplicationUID：（必須）この値は、ソース アプリケーション CR で定義したソース アプリケーションの UID と一致する必要があります。

      • 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

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

      kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace
    CLI を使用して AppMirrorRelationship を作成する

    1. AppMirrorRelationshipオブジェクトを作成して適用し、括弧内の値を環境の情報に置き換えます：

      tridentctl-protect create appmirrorrelationship <name_of_appmirorrelationship> --destination-app-vault <my_vault_name> --source-app-vault <my_vault_name> --recurrence-rule <rule> --namespace-mapping <ns_mapping> --source-app-id <source_app_UID> --source-app <my_source_app_name> --storage-class <storage_class_name> -n <application_namespace>

      例：

      tridentctl-protect create appmirrorrelationship my-amr --destination-app-vault appvault2 --source-app-vault appvault1 --recurrence-rule "DTSTART:20220101T000200Z\nRRULE:FREQ=MINUTELY;INTERVAL=5" --source-app my-app --namespace-mapping "my-source-ns1:my-dest-ns1,my-source-ns2:my-dest-ns2" --source-app-id 373f24c1-5769-404c-93c3-5538af6ccc36 --storage-class my-storage-class -n my-dest-ns1

  9. （オプション）デスティネーション クラスタで、レプリケーション関係の状態とステータスを確認します：

    kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq

デスティネーション クラスタへのフェイルオーバー

Trident Protect を使用すると、レプリケートされたアプリケーションをデスティネーション クラスタにフェイルオーバーできます。この手順では、レプリケーション関係を停止し、デスティネーション クラスタでアプリをオンラインにします。Trident Protect は、ソース クラスタ上のアプリが稼働中であっても停止しません。

手順

  1. デスティネーション クラスタで、AppMirrorRelationship CR ファイル（例： trident-protect-relationship.yaml）を編集し、spec.desiredState の値を `Promoted`に変更します。

  2. CR ファイルを保存します。

  3. CR を適用します：

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

  4. （オプション）fail over されたアプリケーションで必要な保護スケジュールを作成します。

  5. （オプション）レプリケーション関係の状態とステータスを確認します：

    kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq

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

再同期操作により、レプリケーション関係が再確立されます。再同期操作を実行すると、元のソースアプリケーションが実行中のアプリケーションになり、デスティネーション クラスタ上の実行中のアプリケーションに対して行われた変更は破棄されます。

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

重要 フェイルオーバー中にデスティネーションアプリケーションに書き込まれたデータはすべて失われます。
手順

  1. オプション：ソース クラスターで、ソース アプリケーションのスナップショットを作成します。これにより、ソース クラスターからの最新の変更が確実にキャプチャされます。

  2. デスティネーション クラスタで、AppMirrorRelationship CR ファイル（例： trident-protect-relationship.yaml）を編集し、spec.desiredState の値を `Established`に変更します。

  3. CR ファイルを保存します。

  4. CR を適用します：

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

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

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

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

手順

  1. 元のデスティネーション クラスタで、AppMirrorRelationship CRを削除します。これにより、デスティネーションがソースになります。新しいデスティネーション クラスタに保護スケジュールが残っている場合は、それらを削除します。

  2. 元々関係を設定するために使用した CR ファイルを反対側のクラスタに適用して、レプリケーション関係を設定します。

  3. 新しいデスティネーション（元のソースクラスタ）が両方のAppVault CRで設定されていることを確認します。

  4. 逆方向の値を設定して、反対側のクラスタにレプリケーション関係を設定します。

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

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

この状況では、ソースとデスティネーションが入れ替わっています。

手順

  1. ソース クラスタで、シャットダウン スナップショットを作成します：

    CRを使用してシャットダウンスナップショットを作成する

    1. ソース アプリケーションの保護ポリシー スケジュールを無効にします。

    2. ShutdownSnapshot CR ファイルを作成します：

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

      2. 次の属性を設定します：

        • 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

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

      kubectl apply -f trident-protect-shutdownsnapshot.yaml -n my-app-namespace
    CLI を使用してシャットダウン Snapshot を作成する

    1. 括弧内の値を環境の情報に置き換えて、シャットダウン スナップショットを作成します。例：

      tridentctl-protect create shutdownsnapshot <my_shutdown_snapshot> --appvault <my_vault> --app <app_to_snapshot> -n <application_namespace>

  2. ソース クラスタで、シャットダウン Snapshot が完了したら、シャットダウン Snapshot のステータスを取得します：

    kubectl get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o yaml

  3. ソース クラスタで、次のコマンドを使用して shutdownsnapshot.status.appArchivePath の値を見つけ、ファイル パスの最後の部分（ベース名とも呼ばれます。最後のスラッシュの後のすべてです）を記録します：

    k get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o jsonpath='{.status.appArchivePath}'

  4. 新しいデスティネーション クラスタから新しいソース クラスタへのフェイルオーバーを実行します。次の変更を加えます：

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

  5. フェイルオーバーしたレプリケーション関係を逆再同期するで逆再同期の手順を実行します。

  6. 新しいソース クラスタで保護スケジュールを有効にします。

結果

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

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

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

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

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

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

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

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

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

このプロセスは、デスティネーションへのフェイルオーバーを完了した関係から開始され、次の手順が含まれます：

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

  • レプリケーション関係を逆再同期します。

    注意 通常の再同期操作は実行しないでください。フェイルオーバー手順中にデスティネーション クラスタに書き込まれたデータが破棄されます。

  • レプリケーションの方向を逆にします。

手順

  1. フェイルオーバーしたレプリケーション関係を逆再同期するの手順を実行します。

  2. アプリケーションのレプリケーション方向を逆にするの手順を実行します。

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

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

手順

  1. 現在の宛先クラスタで、AppMirrorRelationship CRを削除します：

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