本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

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

11/18/2025 貢獻者

PDF

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

復原和故障轉移操作期間的命名空間註釋和標籤

在復原和故障轉移操作期間，目標命名空間中的標籤和註釋將與來源命名空間中的標籤和註釋相符。來源命名空間中不存在的目標命名空間中的標籤或註釋將被添加，並且任何已存在的標籤或註釋都將被覆蓋以匹配來源命名空間中的值。僅存在於目標命名空間中的標籤或註解保持不變。

如果您使用 Red Hat OpenShift，請務必注意命名空間註解在 OpenShift 環境中的重要角色。命名空間註解可確保復原的 pod 遵守 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（來源）	annotation.one/key: "updatedvalue" annotation.two/key: "true"	環境=生產合規性=HIPAA 名稱=ns-1
命名空間 ns-2（目標）	annotation.one/key: "true" annotation.three/key: "false"	角色=資料庫

命名空間

註解

標籤

命名空間 ns-1（來源）

annotation.one/key: "updatedvalue"
annotation.two/key: "true"

環境=生產
合規性=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 環境=生產角色=資料庫

命名空間

註解

標籤

命名空間 ns-2（目標）

annotation.one/key: "updatedvalue"
annotation.two/key: "true"
annotation.three/key: "false"

名稱=ns-2
合規性=HIPAA
環境=生產
角色=資料庫

您可以設定Trident Protect 在資料保護作業期間凍結和解凍檔案系統。"了解更多關於使用Trident Protect 設定檔系統凍結的信息"。

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

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

故障轉移期間，執行鉤子會自動從來源叢集複製到目標叢集。您無需手動重新建立它們。故障轉移後，應用程式上會存在執行鉤子，這些鉤子將在任何相關操作期間執行。
在反向同步或反向重同步期間，應用程式上任何現有的執行鉤子都會被移除。當來源應用程式變為目標應用程式時，這些執行鉤子將不再有效，並將被刪除以防止其執行。

要了解有關執行鉤子的更多信息，請參閱"管理Trident Protect 執行鉤子"。

建立複製關係

建立複製關係涉及以下步驟：

選擇Trident Protect 執行應用程式快照的頻率（包括應用程式的 Kubernetes 資源以及應用程式每個磁碟區的磁碟區快照）。
選擇複製計劃（包括 Kubernetes 資源以及持久卷資料）
設定拍攝快照的時間

步驟

在來源叢集上，為來源應用程式建立一個 AppVault。根據您的儲存供應商，修改範例中的內容。"AppVault 自訂資源"為了適應您的環境：
使用 CR 建立 AppVault
建立自訂資源 (CR) 檔案並將其命名為（例如， trident-protect-appvault-primary-source.yaml ）。

配置以下屬性：

metadata.name: (必填) AppVault 自訂資源的名稱。請記下您選擇的名稱，因為複製關係所需的其他 CR 檔案會引用此值。

spec.providerConfig: (必要) 儲存使用指定提供者存取 AppVault 所需的設定。選擇儲存桶名稱以及提供者所需的其他任何詳細資訊。請記下您選擇的值，因為複製關係所需的其他 CR 檔案會引用這些值。請參閱"AppVault 自訂資源"例如，AppVault CR 與其他提供者的合作案例。

spec.providerCredentials: (Required) 儲存使用指定提供者存取 AppVault 所需的任何憑證的參考。

spec.providerCredentials.valueFromSecret: (Required) 表示憑證值應來自金鑰。

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

name: (必填) 包含此欄位值的金鑰的名稱。必須位於同一命名空間中。

spec.providerCredentials.secretAccessKey: (必要) 用於存取提供者的存取金鑰。名稱應與 spec.providerCredentials.valueFromSecret.name 相符。

spec.providerType: (必要) 決定備份的提供者；例如， NetApp ONTAP S3、通用 S3、Google Cloud 或 Microsoft Azure。可能的值：

AWS

蔚藍

通用控制協議

通用-s3

ontap-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> -n trident-protect
在來源叢集上，建立來源應用程式 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>
（可選）在來源叢集上，對來源應用程式進行快照。此快照將用作目標叢集上應用程式的基礎。如果跳過此步驟，則需要等待下一次排程快照運行，以便取得最新的快照。若要建立隨選快照，請參閱 "建立按需快照"。

在來源叢集上，建立複製計劃 CR：

除了下面提供的計劃之外，建議建立一個單獨的每日快照計劃，保留期為 7 天，以在對等ONTAP叢集之間保持共同的快照。這樣可以確保快照最多保留 7 天，但保留期限可以根據使用者需求進行自訂。

如果發生故障轉移，系統可以使用這些快照最多 7 天進行逆向操作。這種方法使得逆向過程更快、更有效率，因為只會傳輸自上次快照以來所做的更改，而不是所有資料。

如果應用程式的現有計劃已經滿足所需的保留要求，則無需制定其他計劃。

使用 CR 建立複製計劃

為來源應用程式建立複製計劃：
1. 建立自訂資源 (CR) 檔案並將其命名為（例如， trident-protect-schedule.yaml ）。
2. 配置以下屬性：
  - metadata.name: (必填) 計畫自訂資源的名稱。
  - spec.appVaultRef: (必需) 此值必須與來源應用程式的 AppVault 的 metadata.name 欄位相符。
  - spec.applicationRef: (必需) 此值必須與來源應用程式 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
  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 建立複製計劃

建立複製計劃，並將括號中的值替換為您環境中的資訊：

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>

在目標叢集上，建立一個與在來源叢集上應用的 AppVault CR 完全相同的來源應用程式 AppVault CR，並將其命名為（例如， trident-protect-appvault-primary-destination.yaml ）。

應用 CR：

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

在目標叢集上為目標應用程式建立目標 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: (必填) 包含此欄位值的金鑰的名稱。必須位於同一命名空間中。
    
    spec.providerCredentials.secretAccessKey: (必要) 用於存取提供者的存取金鑰。名稱應與 spec.providerCredentials.valueFromSecret.name 相符。
  - spec.providerType: (必要) 決定備份的提供者；例如， NetApp ONTAP S3、通用 S3、Google Cloud 或 Microsoft Azure。可能的值：
    
    AWS
    
    蔚藍
    
    通用控制協議
    
    通用-s3
    
    ontap-s3
    
    儲存網格-s3
3. 填寫完後 `trident-protect-appvault-secondary-destination.yaml`將檔案的值正確後，套用 CR：
  kubectl apply -f trident-protect-appvault-secondary-destination.yaml -n trident-protect

在目標叢集上，建立 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.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
```
填寫完後 `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> --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

（可選）在目標叢集上，檢查複製關係的狀態：

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），優雅地停止原始來源應用程式的 pod。
在 pod 關閉後，會對應用程式的磁碟區進行快照並進行複製。
SnapMirror關係已斷開，目標磁碟區已準備好進行讀取/寫入操作。
該應用程式的 Kubernetes 資源是從關閉前的快照中恢復的，使用的是在原始來源應用程式關閉後複製的捲資料。
複製過程以相反的方向重新建立。

將應用程式故障恢復到原始來源集群

使用Trident Protect，您可以透過以下步驟序列操作在故障轉移作業後實現「故障復原」。在此恢復原始複製方向的工作流程中， Trident Protect 會將任何應用程式變更複製（重新同步）回原始來源應用程序，然後再反轉複製方向。

流程從已完成故障轉移至目標位置的關係開始，並涉及以下步驟：

從故障轉移狀態開始。
反向重新同步複製關係。

不要執行正常的重新同步操作，因為這將丟棄在故障轉移過程中寫入目標叢集的資料。
反轉複製方向。

步驟

執行反向重新同步失敗的複製關係步驟。
執行反向應用程式複製方向步驟。

刪除複製關係

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

步驟

在目前目標叢集上，刪除 AppMirrorRelationship CR：

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

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

Creating your file...

復原和故障轉移操作期間的命名空間註釋和標籤

例子

在恢復或故障轉移操作之前

恢復操作後

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

建立複製關係

故障轉移到目標集群

重新同步失敗的複製關係

反向重新同步失敗的複製關係

反向應用程式複製方向

結果

將應用程式故障恢復到原始來源集群

刪除複製關係