Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

NetApp SnapMirror 및 Trident Protect를 사용하여 애플리케이션을 복제합니다

기여자
PDF

Trident Protect를 사용하면 NetApp SnapMirror 기술의 비동기식 복제 기능을 사용하여 동일한 클러스터 또는 서로 다른 클러스터 간에 데이터 및 애플리케이션 변경 사항을 스토리지 백엔드에서 다른 스토리지 백엔드로 복제할 수 있습니다.

복원 및 페일오버 작업 중 네임스페이스 주석 및 레이블

복원 및 페일오버 작업 중에 대상 네임스페이스의 레이블과 주석이 소스 네임스페이스의 레이블 및 주석과 일치하도록 만듭니다. 대상 네임스페이스에 없는 소스 네임스페이스의 레이블 또는 주석이 추가되고 이미 존재하는 모든 레이블 또는 주석이 소스 네임스페이스의 값과 일치하도록 덮어쓰여집니다. 대상 네임스페이스에만 있는 레이블이나 주석은 변경되지 않습니다.

참고 RedHat OpenShift를 사용하는 경우 OpenShift 환경에서 네임스페이스 주석의 중요한 역할을 주목해야 합니다. 네임스페이스 주석을 사용하면 복원된 Pod가 OpenShift SCC(Security Context Constraint)에서 정의한 적절한 권한 및 보안 구성을 준수하고 권한 문제 없이 볼륨에 액세스할 수 있습니다. 자세한 내용은 를 "OpenShift 보안 컨텍스트 제약 조건 문서"참조하십시오.

복원 또는 페일오버 작업을 수행하기 전에 Kubernetes 환경 변수를 설정하여 타겟 네임스페이스의 특정 주석을 덮어쓰지 않도록 할 수 있습니다 RESTORE_SKIP_NAMESPACE_ANNOTATIONS. 예를 들면 다음과 같습니다.

kubectl set env -n trident-protect deploy/trident-protect-controller-manager RESTORE_SKIP_NAMESPACE_ANNOTATIONS=<annotation_key_to_skip_1>,<annotation_key_to_skip_2>

플래그가 있는 Helm을 사용하여 소스 애플리케이션을 설치한 경우 --create-namespace 레이블 키에 특수 치료가 name 제공됩니다. 복구 또는 페일오버 프로세스 중에 Trident Protect는 이 레이블을 대상 네임스페이스에 복제하지만 소스의 값이 소스 네임스페이스와 일치하면 대상 네임스페이스 값으로 업데이트합니다. 이 값이 소스 네임스페이스와 일치하지 않으면 변경 없이 대상 네임스페이스로 복사됩니다.

예

다음 예제에서는 각각 다른 주석과 레이블이 있는 소스 및 대상 네임스페이스를 보여 줍니다. 작업 전후에 대상 네임스페이스의 상태와 대상 네임스페이스에서 주석과 레이블이 결합되거나 덮어써지는 방법을 확인할 수 있습니다.

복구 또는 페일오버 작업 전

다음 표에서는 복구 또는 페일오버 작업 이전의 예제 소스 및 대상 네임스페이스의 상태를 보여 줍니다.

네임스페이스 주석 라벨

네임스페이스 ns-1(소스)

  • annotation.one/key:"updatedvalue"(주석 1개/키)

  • Annotation.two/key(주석.two/키):

  • 환경 = 운영

  • 규정 준수 = HIPAA

  • 이름 = ns-1

네임스페이스 ns-2(대상)

  • Annotation.one/key(주석. 하나/키):"true"

  • Annotation.Three/key:"false"

  • 역할 = 데이터베이스

복구 작업 후

다음 표에서는 복구 또는 페일오버 작업 후의 예제 대상 네임스페이스의 상태를 보여 줍니다. 일부 키가 추가되고, 일부 키가 덮어쓰여졌으며, name 대상 네임스페이스와 일치하도록 레이블이 업데이트되었습니다.

네임스페이스 주석 라벨

네임스페이스 ns-2(대상)

  • annotation.one/key:"updatedvalue"(주석 1개/키)

  • Annotation.two/key(주석.two/키):

  • Annotation.Three/key:"false"

  • 이름 = ns-2

  • 규정 준수 = HIPAA

  • 환경 = 운영

  • 역할 = 데이터베이스
참고 데이터 보호 작업 중에 파일 시스템을 고정 및 고정 해제하도록 Trident Protect를 구성할 수 있습니다. "Trident Protect를 사용하여 파일 시스템 중지를 구성하는 방법에 대해 자세히 알아보십시오"..

복제 관계를 설정합니다

복제 관계를 설정하려면 다음을 수행해야 합니다.

  • Trident Protect에서 앱 스냅샷 생성 빈도 선택(앱의 Kubernetes 리소스 및 각 앱 볼륨에 대한 볼륨 스냅샷 포함)

  • 복제 일정 선택(Kubernetes 리소스 및 영구 볼륨 데이터 포함)

  • 스냅샷을 생성할 시간을 설정합니다

단계

  1. 소스 클러스터에서 소스 애플리케이션에 대한 AppVault를 생성합니다. 스토리지 공급자에 따라 의 예를 "AppVault 사용자 지정 리소스"환경에 맞게 수정합니다.

    CR을 사용하여 AppVault를 작성합니다

    1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다(예: trident-protect-appvault-primary-source.yaml).

    2. 다음 특성을 구성합니다.

      • metadata.name: (required) AppVault 사용자 정의 리소스의 이름입니다. 복제 관계에 필요한 다른 CR 파일은 이 값을 참조하므로 선택한 이름을 기록해 둡니다.

      • spec.providerConfig: (required) 지정된 공급자를 사용하여 AppVault에 액세스하는 데 필요한 구성을 저장합니다. bucketName과 공급자에게 필요한 기타 세부 정보를 선택합니다. 복제 관계에 필요한 다른 CR 파일은 이러한 값을 참조하므로 선택한 값을 기록해 둡니다. 다른 공급자의 AppVault CRS에 대한 예는 을 "AppVault 사용자 지정 리소스"참조하십시오.

      • spec.providerCredentials: (required) 지정된 공급자를 사용하여 AppVault에 액세스하는 데 필요한 자격 증명에 대한 참조를 저장합니다.

        • spec.providerCredentials.valueFromSecret: (required) 자격 증명 값이 비밀에서 와야 함을 나타냅니다.

          • * key *: (required) 선택할 비밀의 유효한 키입니다.

          • * name *: (required) 이 필드의 값을 포함하는 비밀의 이름입니다. 같은 네임스페이스에 있어야 합니다.

        • spec.providerCredentials.secretAccessKey: (required) 제공자에 액세스하는 데 사용되는 액세스 키입니다. name * 은 * spec.providerCredentials.valueFromSecret.name* 과 일치해야 합니다.

      • spec.providerType: (required) 백업을 제공하는 항목을 결정합니다(예: NetApp ONTAP S3, 일반 S3, Google Cloud 또는 Microsoft Azure). 가능한 값:

        • 설치하고

        • Azure를 지원합니다

        • GCP

        • 일반 - 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>

  2. 소스 응용 프로그램 생성 CR:

    CR을 사용하여 소스 응용 프로그램을 만듭니다

    1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다(예: trident-protect-app-source.yaml).

    2. 다음 특성을 구성합니다.

      • metadata.name: (required) 응용 프로그램 사용자 정의 리소스의 이름입니다. 복제 관계에 필요한 다른 CR 파일은 이 값을 참조하므로 선택한 이름을 기록해 둡니다.

      • spec.includedNamespaces: (required) 네임스페이스 및 관련 레이블의 배열입니다. 네임스페이스 이름을 사용하고 선택적으로 레이블을 사용하여 네임스페이스 범위를 좁혀 여기에 나열된 네임스페이스에 있는 리소스를 지정합니다. 응용 프로그램 네임스페이스는 이 배열의 일부여야 합니다.

        • YAML 예 *:

      apiVersion: protect.trident.netapp.io/v1
kind: Application
metadata:
  name: maria
  namespace: my-app-namespace
spec:
  includedNamespaces:
    - namespace: maria
      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 maria --namespaces maria -n my-app-namespace

  3. 필요한 경우 소스 애플리케이션의 스냅샷을 생성합니다. 이 스냅샷은 대상 클러스터에서 애플리케이션의 기반으로 사용됩니다. 이 단계를 건너뛸 경우 다음 예약된 스냅샷이 실행될 때까지 기다려야 최신 스냅샷이 생성됩니다.

    CR을 사용하여 스냅샷을 촬영합니다

    1. 소스 애플리케이션에 대한 복제 스케줄을 생성합니다.

      1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다(예: trident-protect-schedule.yaml).

      2. 다음 특성을 구성합니다.

        • metadata.name: (required) 일정 사용자 정의 리소스의 이름입니다.

        • * spec.AppVaultRef *: (required) 이 값은 원본 응용 프로그램에 대한 AppVault의 metadata.name 필드와 일치해야 합니다.

        • spec.ApplicationRef: (required) 이 값은 소스 응용 프로그램 CR의 metadata.name 필드와 일치해야 합니다.

        • spec.backupRetention: (required) 이 필드는 필수 필드이며 값을 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: maria
  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 snapshot <my_snapshot_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot>

  4. 소스 클러스터에 적용한 AppVault CR과 동일한 소스 응용 프로그램 AppVault CR을 대상 클러스터에 생성하고 이름을 지정합니다(예: trident-protect-appvault-primary-destination.yaml).

  5. CR 적용:

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

  6. 대상 클러스터에서 대상 응용 프로그램에 대한 AppVault를 생성합니다. 스토리지 공급자에 따라 의 예를 "AppVault 사용자 지정 리소스"환경에 맞게 수정합니다.

    1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다(예: trident-protect-appvault-secondary-destination.yaml).

    2. 다음 특성을 구성합니다.

      • metadata.name: (required) AppVault 사용자 정의 리소스의 이름입니다. 복제 관계에 필요한 다른 CR 파일은 이 값을 참조하므로 선택한 이름을 기록해 둡니다.

      • spec.providerConfig: (required) 지정된 공급자를 사용하여 AppVault에 액세스하는 데 필요한 구성을 저장합니다. `bucketName`와 공급자에게 필요한 기타 세부 정보를 선택합니다. 복제 관계에 필요한 다른 CR 파일은 이러한 값을 참조하므로 선택한 값을 기록해 둡니다. 다른 공급자의 AppVault CRS에 대한 예는 을 "AppVault 사용자 지정 리소스"참조하십시오.

      • spec.providerCredentials: (required) 지정된 공급자를 사용하여 AppVault에 액세스하는 데 필요한 자격 증명에 대한 참조를 저장합니다.

        • spec.providerCredentials.valueFromSecret: (required) 자격 증명 값이 비밀에서 와야 함을 나타냅니다.

          • * key *: (required) 선택할 비밀의 유효한 키입니다.

          • * name *: (required) 이 필드의 값을 포함하는 비밀의 이름입니다. 같은 네임스페이스에 있어야 합니다.

        • spec.providerCredentials.secretAccessKey: (required) 제공자에 액세스하는 데 사용되는 액세스 키입니다. name * 은 * spec.providerCredentials.valueFromSecret.name* 과 일치해야 합니다.

      • spec.providerType: (required) 백업을 제공하는 항목을 결정합니다(예: NetApp ONTAP S3, 일반 S3, Google Cloud 또는 Microsoft Azure). 가능한 값:

        • 설치하고

        • Azure를 지원합니다

        • GCP

        • 일반 - S3

        • ONTAP-S3

        • StorageGRID-S3

    3. 파일을 올바른 값으로 채운 후 trident-protect-appvault-secondary-destination.yaml CR:

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

  7. AppMirrorRelationship CR 파일 만들기:

    CR을 사용하여 AppMirrorRelationship을 생성합니다

    1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다(예: trident-protect-relationship.yaml).

    2. 다음 특성을 구성합니다.

      • metadata.name: (필수) AppMirrorRelationship 사용자 정의 리소스의 이름입니다.

      • spec.destinationAppVaultRef: (required) 이 값은 대상 클러스터의 대상 응용 프로그램에 대한 AppVault 이름과 일치해야 합니다.

      • spec.namespaceMapping: (required) 대상 및 소스 네임스페이스는 해당 응용 프로그램 CR에 정의된 응용 프로그램 네임스페이스와 일치해야 합니다.

      • * spec.sourceAppVaultRef *: (required) 이 값은 소스 응용 프로그램의 AppVault 이름과 일치해야 합니다.

      • * spec.sourceApplicationName *: (required) 이 값은 소스 응용 프로그램 CR에서 정의한 소스 응용 프로그램의 이름과 일치해야 합니다.

      • * spec.storageClassName *: (required) 클러스터에서 유효한 스토리지 클래스의 이름을 선택하십시오. 소스 애플리케이션이 구축된 소스 클러스터에서 사용 중인 스토리지 클래스로 스토리지 클래스를 피어링해야 합니다.

      • 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: maria
  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> --recurrence-rule <rule> --source-app <my_source_app> --source-app-vault <my_source_app_vault>

  8. (선택 사항) 복제 관계의 상태 및 상태를 확인합니다.

    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. (선택 사항) 페일오버된 애플리케이션에 필요한 보호 스케줄을 생성합니다.

  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 CRS가 각 클러스터에 준비되어 있는지 확인합니다.

  4. 반대 클러스터에서 복제 관계를 설정하여 반대 방향에 대한 값을 구성합니다.

애플리케이션 복제 방향을 반대로 전환합니다

복제 방향을 반대로 바꾸면 Trident Protect는 애플리케이션을 대상 스토리지 백엔드로 이동하고 계속해서 원래 소스 스토리지 백엔드로 복제합니다. Trident Protect는 소스 애플리케이션을 중지하고 타겟 앱으로 페일오버하기 전에 데이터를 대상에 복제합니다.

이 경우 소스와 대상을 스와핑합니다.

단계

  1. 종료 스냅샷 생성:

    CR을 사용하여 종료 스냅샷을 생성합니다

    1. 소스 애플리케이션에 대한 보호 정책 일정을 해제합니다.

    2. ShutdownSnapshot CR 파일 생성:

      1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다(예: trident-protect-shutdownsnapshot.yaml).

      2. 다음 특성을 구성합니다.

        • metadata.name: (required) 사용자 정의 리소스의 이름입니다.

        • * spec.AppVaultRef *: (required) 이 값은 원본 응용 프로그램에 대한 AppVault의 metadata.name 필드와 일치해야 합니다.

        • spec.ApplicationRef: (required) 이 값은 소스 응용 프로그램 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: maria

    3. 파일을 올바른 값으로 채운 후 trident-protect-shutdownsnapshot.yaml CR:

      kubectl apply -f trident-protect-shutdownsnapshot.yaml -n my-app-namespace
    CLI를 사용하여 종료 스냅샷을 생성합니다

    1. 괄호 안의 값을 사용자 환경의 정보로 대체하여 종료 스냅샷을 만듭니다. 예를 들면 다음과 같습니다.

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

  2. 스냅샷이 완료되면 스냅샷의 상태를 가져옵니다.

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

  3. 다음 명령을 사용하여 * shutdownsnapshot.status.appArchivePath * 의 값을 찾고 파일 경로의 마지막 부분(basename라고도 함. 이것은 마지막 슬래시 다음에 모두 있음)을 기록합니다.

    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 리소스를 삭제하여 원본 소스 앱의 Pod를 정상적으로 중지할 수 있습니다(PVC 및 PVS를 그대로 둡니다).

  • 포드가 종료된 후 앱 볼륨의 스냅샷이 촬영되고 복제됩니다.

  • SnapMirror 관계가 끊어져 타겟 볼륨이 읽기/쓰기 준비가 되었습니다.

  • 앱의 Kubernetes 리소스는 원래 소스 애플리케이션이 종료된 후 복제된 볼륨 데이터를 사용하여 사전 종료 스냅샷에서 복구됩니다.

  • 복제는 반대 방향으로 다시 설정됩니다.

애플리케이션을 원래 소스 클러스터로 페일백합니다

Trident Protect를 사용하면 다음 작업 순서를 사용하여 페일오버 작업 후에 "페일백"을 수행할 수 있습니다. 이 워크플로우에서 원래 복제 방향을 복구하면 Trident Protect는 복제 방향을 바꾸기 전에 애플리케이션 변경 내용을 원래 소스 애플리케이션으로 다시 복제(재동기화)합니다.

이 프로세스는 대상에 대한 페일오버를 완료한 관계로부터 시작되며 다음 단계를 포함합니다.

  • 페일오버된 상태로 시작합니다.

  • 복제 관계를 역방향으로 다시 동기화합니다.

    주의 일반 재동기화 작업을 수행하지 마십시오. 그러면 페일오버 절차 중에 대상 클러스터에 기록된 데이터가 삭제됩니다.

  • 복제 방향을 반대로 바꿉니다.

단계

  1. 페일오버된 복제 관계를 역방향으로 재동기화합니다다음 단계를 수행합니다.

  2. 애플리케이션 복제 방향을 반대로 전환합니다다음 단계를 수행합니다.

복제 관계를 삭제합니다

언제든지 복제 관계를 삭제할 수 있습니다. 애플리케이션 복제 관계를 삭제하면 서로 관계가 없는 두 개의 개별 애플리케이션이 생성됩니다.

단계

  1. AppMirrorRelationship CR 삭제:

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