Skip to main content
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

使用NetApp SnapMirror和Trident Protect 复制应用程序

贡献者 netapp-aruldeepa
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"

  • 角色=数据库

恢复操作后

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

命名空间 标注 标签

命名空间 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 资源以及持久卷数据）

  • 设置拍摄快照的时间

步骤

  1. 在源集群上，为源应用程序创建一个 AppVault。根据您的存储提供商，修改示例中的内容。"AppVault 自定义资源"为了适应您的环境：

    使用 CR 创建 AppVault

    1. 创建自定义资源 (CR) 文件并将其命名为（例如， trident-protect-appvault-primary-source.yaml ）。

    2. 配置以下属性：

      • 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

    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: (必填) 应用程序自定义资源的名称。请记下您选择的名称，因为复制关系所需的其他 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. （可选）在源集群上，对源应用程序进行快照。此快照将用作目标集群上应用程序的基础。如果跳过此步骤，则需要等待下一次计划快照运行，以便获得最新的快照。

    备注

    除了下面提供的计划之外，建议创建一个单独的每日快照计划，保留期为 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: (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: 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 snapshot <my_snapshot_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot> -n <application_namespace>

  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 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 my-app-namespace

  7. 在目标集群上，创建 AppMirrorRelationship CR 文件：

    使用 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.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> --recurrence-rule <rule> --source-app <my_source_app> --source-app-vault <my_source_app_vault> -n <application_namespace>

  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 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 创建关机快照

    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