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 图表设置"。

如果使用带有 --create-namespace 标志的 Helm 安装源应用程序，则会对 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"

  • 角色=数据库

还原操作后

下表显示了还原或故障转移操作后示例目标命名空间的状态。已添加一些键，一些键已被覆盖，并且已更新 name 标签以匹配目标命名空间：

命名空间 标注 标签

命名空间 ns-2（目标）

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • annotation.three/key: "false"

  • name=ns-2

  • 合规性=hipaa

  • environment=production

  • 角色=数据库
备注 您可以配置 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: (Required) AppVault 自定义资源的名称。记下您选择的名称，因为复制关系所需的其他 CR 文件引用此值。

      • spec.providerConfig：（必需）存储使用指定提供程序访问 AppVault 所需的配置。为您的提供程序选择 bucketName 和任何其他必要的详细信息。记下您选择的值，因为复制关系所需的其他 CR 文件会引用这些值。有关其他提供程序的 AppVault CR 示例，请参阅 "AppVault 自定义资源"。

      • spec.providerCredentials：（Required）存储使用指定提供程序访问 AppVault 所需的任何凭据的引用。

        • spec.providerCredentials.valueFromSecret: (Required) 指示凭据值应来自机密。

          • key：（Required）要从中选择的 secret 的有效 key。

          • name：（Required）包含此字段值的密钥的名称。必须位于同一命名空间中。

        • 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：（Required）计划自定义资源的名称。

        • 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 创建复制计划

    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: (Required) AppVault 自定义资源的名称。记下您选择的名称，因为复制关系所需的其他 CR 文件引用此值。

      • spec.providerConfig：（必需）存储使用指定提供程序访问 AppVault 所需的配置。为您的提供程序选择 bucketName 和任何其他必要的详细信息。记下您选择的值，因为复制关系所需的其他 CR 文件会引用这些值。有关其他提供程序的 AppVault CR 示例，请参阅 "AppVault 自定义资源"。

      • spec.providerCredentials：（Required）存储使用指定提供程序访问 AppVault 所需的任何凭据的引用。

        • spec.providerCredentials.valueFromSecret: (Required) 指示凭据值应来自机密。

          • key：（Required）要从中选择的 secret 的有效 key。

          • name：（Required）包含此字段值的密钥的名称。必须位于同一命名空间中。

        • 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: (Required) 此值必须与目标集群上目标应用程序的 AppVault 名称匹配。

      • spec.namespaceMapping：（必需）目标和源命名空间必须与相应应用程序 CR 中定义的应用程序命名空间匹配。

      • spec.sourceAppVaultRef: (Required) 此值必须与源应用程序的 AppVault 名称匹配。

      • spec.sourceApplicationName：（必需）此值必须与您在源应用程序 CR 中定义的源应用程序的名称匹配。

      • spec.sourceApplicationUID：（必需）此值必须与您在源应用程序 CR 中定义的源应用程序的 UID 匹配。

      • spec.storageClassName：（可选）选择集群上有效存储类的名称。存储类必须链接到与源环境对等的 ONTAP 存储虚拟机。如果未提供存储类，则默认情况下将使用集群上的默认存储类。

      • 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：（Required）自定义资源的名称。

        • 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. 在源集群上，关闭快照完成后，获取关闭快照的状态：

    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 后，将拍摄并复制应用卷的快照。

  • SnapMirror 关系已中断，使目标卷准备好读/写。

  • 使用原始源应用程序关闭后复制的卷数据，从预关闭快照中还原应用程序的 Kubernetes 资源。

  • 反向重新建立复制。

将应用程序故障回切至原始源群集

使用 Trident Protect，您可以使用以下操作序列在故障转移操作后实现"回切"。在此工作流程中，为了还原原始复制方向，Trident Protect 会在反转复制方向之前将任何应用程序更改复制（重新同步）回原始源应用程序。

此过程从已完成故障转移到目标的关系开始，涉及以下步骤：

  • 从故障转移状态开始。

  • 反向重新同步复制关系。

    注意 请勿执行正常的重新同步操作，因为这将丢弃在故障转移过程中写入目标集群的数据。

  • 反转复制方向。

步骤

  1. 执行 反向重新同步故障转移的复制关系 步骤。

  2. 执行 反向应用程序复制方向 步骤。

删除复制关系

您可以随时删除复制关系。当您删除应用程序复制关系时，会产生两个独立的应用程序，它们之间没有关系。

步骤

  1. 在当前目标集群上，删除 AppMirrorRelationship CR：

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