Skip to main content
此產品有較新版本可以使用。
本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

使用 NetApp SnapMirror 和 Trident Protect 複製應用程式

PDF

使用 Trident Protect，您可以利用 NetApp SnapMirror 技術的非同步複製功能，將資料和應用程式變更從一個儲存後端複製到另一個儲存後端，無論是在同一叢集內還是在不同叢集之間。

還原和容錯移轉作業期間的命名空間註釋和標籤

在還原和容錯移轉作業期間，目的地命名空間中的標籤和註釋會與來源命名空間中的標籤和註釋相符。來源命名空間中存在但目的地命名空間中不存在的標籤或註釋會被新增，而任何已存在的標籤或註釋則會被覆寫以符合來源命名空間中的值。僅存在於目的地命名空間中的標籤或註釋則保持不變。

註 如果您使用 Red Hat OpenShift，請務必注意命名空間註解在 OpenShift 環境中的關鍵作用。命名空間註解可確保復原的 Pod 遵循 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 Chart 設定"。

如果您使用 Helm 並帶有 --create-namespace 標誌安裝了來源應用程式，則會對 name 標籤鍵進行特殊處理。在還原或容錯移轉過程中，Trident Protect 會將此標籤複製到目的地命名空間，但如果來源的值與來源命名空間相符，則會將值更新為目的地命名空間值。如果此值與來源命名空間不相符，則會將其複製到目的地命名空間而不做任何變更。

範例

以下範例展示了來源命名空間和目標命名空間，它們各自具有不同的註解和標籤。您可以查看操作前後目標命名空間的狀態，以及註解和標籤在目標命名空間中是如何組合或覆蓋的。

在還原或容錯移轉作業之前

下表說明了復原或容錯移轉作業之前範例來源命名空間和目標命名空間的狀態：

命名空間 註解 標籤

命名空間 ns-1 （來源）

  • annotation.one/key: 「updatedvalue」

  • annotation.two/key: 「true」

  • environment=production

  • 合規性＝hipaa

  • 名稱=ns-1

命名空間 ns-2 （目標）

  • annotation.one/key: 「true」

  • annotation.three/key:「false」

  • 角色=資料庫

還原作業後

下表展示了復原或故障轉移作業後範例目標命名空間的狀態。一些鍵已被添加，一些鍵已被覆蓋，並且 name 標籤已更新以匹配目標命名空間：

命名空間 註解 標籤

命名空間 ns-2 （目標）

  • annotation.one/key: 「updatedvalue」

  • annotation.two/key: 「true」

  • annotation.three/key:「false」

  • 名稱=ns-2

  • 合規性＝hipaa

  • environment=production

  • 角色=資料庫
註 您可以設定 Trident Protect 在資料保護作業期間凍結及解除凍結檔案系統。"深入瞭解如何使用 Trident Protect 設定檔案系統凍結"。

故障轉移和反向操作期間的執行掛鉤

使用 AppMirror 關係保護應用程式時，在故障轉移和反向操作期間，您應該注意與執行鉤子相關的特定行為。

  • 故障轉移期間，執行鉤子會自動從來源叢集複製到目標叢集。您無需手動重新建立。故障轉移後，執行鉤子將存在於應用程式中，並在執行任何相關操作時運行。

  • 在反向同步或反向重同步過程中，應用程式上所有現有的執行鉤子都會被移除。當來源應用程式變為目標應用程式時，這些執行鉤子將失效並被刪除以防止其執行。

若要深入瞭解執行掛鉤，請參閱 "管理 Trident Protect 執行掛鉤"。

建立複寫關係

建立複寫關係涉及下列項目：

  • 選擇 Trident Protect 拍攝應用程式快照的頻率（包括應用程式的 Kubernetes 資源以及應用程式每個磁碟區的磁碟區快照）

  • 選擇複寫排程（包括 Kubernetes 資源以及持續性磁碟區資料）

  • 設定拍攝 Snapshot 的時間

步驟

  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：（Required）儲存使用指定提供者存取 AppVault 所需的任何憑證參考。

        • spec.providerCredentials.valueFromSecret：（Required）表示憑證值應來自金鑰。

          • key: (必填) 要從中選取的有效金鑰。

          • name：（必填）包含此欄位值的 secret 名稱。必須位於同一個 namespace 中。

        • 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：

    註

    除了下方提供的排程之外，建議建立一個單獨的每日快照排程，並將保留期設定為 7 天，以便在對等 ONTAP 叢集之間維護一個通用的快照。這樣可以確保快照最多可用 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 自訂資源"以取得其他提供者的 AppVault CR 範例。

      • spec.providerCredentials：（Required）儲存使用指定提供者存取 AppVault 所需的任何憑證參考。

        • spec.providerCredentials.valueFromSecret：（Required）表示憑證值應來自金鑰。

          • key: (必填) 要從中選取的有效金鑰。

          • name：（必填）包含此欄位值的 secret 名稱。必須位於同一個 namespace 中。

        • 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：（Required）此值必須與來源應用程式的 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. （可選）在故障轉移應用程式上建立所需的任何保護排程。

  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：（Required）此值必須與來源應用程式的 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 建立關機快照

    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 中，將 spec.promotedSnapshot 欄位包含在 AppMirrorRelationship CR 檔案中，並將其值設定為您在上面的步驟 3 中記錄的基本名稱。

  5. 在 反向重新同步已容錯移轉的複寫關係 中執行反向重新同步步驟。

  6. 在新來源叢集上啟用保護排程。

結果

由於反向複寫，會發生以下動作：

  • 對原始來源應用程式的 Kubernetes 資源進行快照。

  • 透過刪除應用程式的 Kubernetes 資源（保留 PVC 和 PV），優雅地停止原始來源應用程式的 Pod。

  • 在 pod 關閉後，會對應用程式的 Volume 進行快照並進行複寫。

  • SnapMirror 關係已中斷，使目的地磁碟區準備好進行讀取 / 寫入。

  • 該應用程式的 Kubernetes 資源是從關閉前的快照中還原，使用的是在原始來源應用程式關閉後複寫的磁碟區資料。

  • 複寫會以相反的方向重新建立。

將應用程式容錯回復至原始來源叢集

使用 Trident Protect，您可以透過以下步驟在故障轉移作業後實現「故障復原」。在此工作流程中，為了恢復原始複寫方向，Trident Protect 會在反轉複寫方向之前，將所有應用程式變更複寫（重新同步）回原始來源應用程式。

此程序從已完成容錯移轉至目的地的關係開始，並涉及下列步驟：

  • 從故障轉移狀態開始。

  • 反向重新同步複寫關係。

    警告 不要執行正常的重新同步作業，因為這會捨棄在容錯移轉程序期間寫入目的地叢集的資料。

  • 反轉複寫方向。

步驟

  1. 執行反向重新同步已容錯移轉的複寫關係步驟。

  2. 執行反向應用程式複寫方向步驟。

刪除複寫關係

您可以隨時刪除複寫關係。刪除應用程式複寫關係後，將產生兩個彼此獨立的應用程式，它們之間沒有任何關聯。

步驟

  1. 在目前目標叢集上、刪除 AppMirrorRelationship CR：

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