第 1 章 业务连续性


有关灾难恢复解决方案和 hub 集群以及受管集群,请参阅以下主题。

1.1. 备份和恢复

集群备份和恢复 Operator 在 hub 集群上运行,并为 Red Hat Advanced Cluster Management for Kubernetes hub 集群失败提供灾难恢复解决方案。当 hub 集群失败时,一些功能(如基于策略的警报或集群更新)会停止工作,即使所有受管集群仍可以正常工作。当 hub 集群不可用时,您需要恢复计划来确定是否可以恢复,或者需要在新部署的 hub 集群中恢复数据。

集群备份和恢复 Operator 支持备份扩展 hub 集群安装的任何第三方资源。使用这个备份解决方案,您可以定义在指定时间段内运行的基于 cron 的备份计划。当 hub 集群停机时,可以部署新的 hub 集群,并将备份的数据移到新的 hub 集群中。

继续阅读以下主题以了解更多有关备份和恢复 Operator 的信息:

1.1.1. 备份和恢复 Operator 架构

Operator 定义 BackupSchedule.cluster.open-cluster-management.io 资源,该资源设置 Red Hat Advanced Cluster Management 备份计划,以及 restore.cluster.open-cluster-management.io 资源。使用这些资源来处理和恢复这些备份。Operator 会创建对应的 Velero 资源,并定义备份远程集群和需要恢复的任何其他 hub 集群资源所需的选项。

查看以下构架图:

Backup and restore architecture diagram

备份和恢复组件为报告问题提供一组策略,如备份 pod 或未运行备份调度。如果备份解决方案无法正常工作,请使用策略模板为 hub 集群管理员创建警报。如需更多信息,请参阅验证备份或恢复配置

集群备份和恢复 Operator 依赖于 OADP Operator 安装 Velero,并从 hub 集群创建到存储数据的备份存储位置的连接。Velero 是运行备份和恢复操作的组件。集群备份和恢复 Operator 解决方案为所有 Red Hat Advanced Cluster Management hub 集群资源(包括受管集群、应用程序和策略)提供备份和恢复支持。

1.1.1.1. 备份的资源

集群备份和恢复 Operator 解决方案为所有 hub 集群资源(如受管集群、应用程序和策略)提供备份和恢复支持。使用解决方案备份任何扩展基本 hub 集群安装的第三方资源。使用这个备份解决方案,定义一个基于 cron 的备份调度,该调度在指定的时间间隔运行,并持续备份 hub 集群内容的最新版本。

当 hub 集群需要替换或处于灾难情况下,当 hub 集群停机时,可以部署新的 hub 集群并备份数据被移到新的 hub 集群中。

查看以下集群备份和恢复过程列表,以及它们如何备份或排除资源和组来识别备份数据:

  • 排除 MultiClusterHub 命名空间中的所有资源。这是为了避免备份链接到当前 hub 集群身份的安装资源,不应该备份。
  • 备份由 .open-cluster-management.io.hive.openshift.io 后缀的 API 版本的所有资源。这些后缀表示所有 Red Hat Advanced Cluster Management 资源都已备份。
  • 备份以下 API 组中的所有资源: argoproj.io,app.k8s.io,core.observatorium.io,hive.openshift.io.资源在 acm-resources-schedule 备份中备份,但 agent-install.openshift.io API 组中的资源除外。agent-install.openshift.io API 组中的资源在 acm-managed-clusters-schedule 备份中备份。来自 hive.openshift.iohiveinternal.openshift.io API 组中的以下资源也由 acm-managed-clusters-schedule 备份备份:

    • clusterdeployment.hive.openshift.io
    • machinepool.hive.openshift.io
    • clusterpool.hive.openshift.io
    • clusterclaim.hive.openshift.io
    • clusterimageset.hive.openshift.io
    • clustersync.hiveinternal.openshift.io
  • 从以下 API 组中排除所有资源:

    • internal.open-cluster-management.io
    • operator.open-cluster-management.io
    • work.open-cluster-management.io
    • search.open-cluster-management.io
    • admission.hive.openshift.io
    • proxy.open-cluster-management.io
    • action.open-cluster-management.io
    • view.open-cluster-management.io
    • clusterview.open-cluster-management.io
    • velero.io
  • 排除作为包含 API 组一部分的所有资源,但不需要,或者由备份的所有者资源重新创建:

    • clustermanagementaddon.addon.open-cluster-management.io
    • backupschedule.cluster.open-cluster-management.io
    • restore.cluster.open-cluster-management.io
    • clusterclaim.cluster.open-cluster-management.io
    • discoveredcluster.discovery.open-cluster-management.io
  • 使用以下标签之一备份 secret 和 ConfigMap:cluster.open-cluster-management.io/type, hive.openshift.io/secret-type, cluster.open-cluster-management.io/backup
  • cluster.open-cluster-management.io/backup 标签用于您要备份的任何其他资源,且未包含在前面提到的条件中,或者是排除的 API 组的一部分。请参见以下示例:

    apiVersion: my.group/v1alpha1
    kind: MyResource
     metadata:
       labels:
        cluster.open-cluster-management.io/backup: ""
    Copy to Clipboard Toggle word wrap

    注: hive.openshift.io.ClusterDeployment 资源使用的 Secret 需要备份,并仅在使用控制台创建集群时使用 cluster.open-cluster-management.io/backup 标签自动标注。如果使用 GitOps 部署 Hive 集群,您必须手动将 cluster.open-cluster-management.io/backup 标签添加到 ClusterDeployment 资源使用的 secret 中。带有 cluster. open-cluster-management.io/backup: cluster-activation 标签的 secret 和配置映射资源会在集群激活时恢复。

  • 排除您不想备份的特定资源。请参阅以下示例从备份过程中排除 Velero 资源:

    apiVersion: my.group/v1alpha1
    kind: MyResource
     metadata:
      labels:
        velero.io/exclude-from-backup: "true"
    Copy to Clipboard Toggle word wrap

您可以使用 Red Hat Advanced Cluster Management 调度来备份 hub 集群资源,这些资源根据资源类型或标签注解在单独的备份文件中分组。

BackupSchedule.cluster.open-cluster-management.io 资源会创建一组四个 schedule.velero.io 资源。这些 schedule.velero.io 资源生成备份文件,这些文件也称为资源。

要查看调度的备份文件列表,请运行以下命令: oc get schedule -A | grep acm

调度的备份文件是 backup.velero.io。下表列出了这些调度的备份文件的描述:

Expand
表 1.1. 调度的备份表
调度的备份描述

凭证备份

存储以下内容: Hive 凭证、Red Hat Advanced Cluster Management、用户创建的凭证和 ConfigMap。此备份文件的名称是 acm-credentials-schedule-<timestamp&gt;。

资源备份

包含 Red Hat Advanced Cluster Management 资源、acm-resources-schedule-<timestamp> 备份,一个用于通用资源 acm-resources-generic-schedule-<timestamp> 的一个备份。使用备份标签 cluster.open-cluster-management.io/backup 注解的任何资源都存储在备份中 acm-resources-generic-schedule- backup。例外是存储在备份 acm-credentials-schedule-<timestamp > 下的 SecretConfigMap 资源。

受管集群备份

仅包含激活受管集群连接到 hub 集群的资源,其中恢复备份。此备份文件的名称是 acm-managed-clusters-schedule-<timestamp&gt;。

1.1.1.3. 在受管集群激活时恢复的资源

cluster.open-cluster-management.io/backup 标签添加到资源时,资源会在 acm-resources-generic-schedule 备份中自动备份,但备份 acm-credentials-schedule-schedule- 中备份的 SecretsConfigMap 资源除外。如果您需要在将受管集群移至新的 hub 集群后恢复任何资源,并在恢复的资源中使用 veleroManagedClustersBackupName:latest,请将标签值设置为 cluster-activation

当您将 cluster.open-cluster-management.io/backup 标签设置为 cluster-activation 时,您可以确保资源不会被恢复,除非激活受管集群。查看以下示例:

apiVersion: my.group/v1alpha1
kind: MyResource
 metadata:
  labels:
    cluster.open-cluster-management.io/backup: cluster-activation
Copy to Clipboard Toggle word wrap

注: 对于任何受管集群命名空间或其中的任何资源,您必须在集群激活步骤中恢复一个。因此,如果您需要添加到受管集群命名空间中创建的备份资源,请为 cluster.open-cluster-management.io/backup 标签使用 cluster-activation 值。要了解恢复过程,请查看以下信息:

  • 如果恢复命名空间,则 managedcluster-import-controller 会删除命名空间。
  • 如果恢复 managedCluster 自定义资源,则 cluster-manager-registration-controller 会创建命名空间。

除了使用 cluster.open-cluster-management.io/backup: cluster-activation 标签并由 acm-resources-generic-schedule 备份存储的激活数据资源外,集群备份和恢复 Operator 还默认在激活集合中包括一些资源。以下资源由 acm-managed-clusters-schedule 备份备份:

  • managedcluster.cluster.open-cluster-management.io
  • klusterletaddonconfig.agent.open-cluster-management.io
  • managedclusteraddon.addon.open-cluster-management.io
  • managedclusterset.cluster.open-cluster-management.io
  • managedclusterset.clusterview.open-cluster-management.io
  • managedclustersetbinding.cluster.open-cluster-management.io
  • clusterpool.hive.openshift.io
  • clusterclaim.hive.openshift.io
  • clustercurator.cluster.open-cluster-management.io

1.1.1.4. 备份 标签功能

您可以通过在资源中添加 cluster.open-cluster-management.io/backup 标签来备份集群备份和恢复的第三方资源。标签的值可以是任意字符串,包括空字符串。使用一个可以帮助您识别要备份的组件的值。例如,如果组件是由 IDP 解决方案提供,请使用 cluster.open-cluster-management.io/backup: idp 标签。

注: 如果您希望在受管集群激活资源时恢复资源,请使用 cluster.open-cluster-management.io/backup 标签的 cluster-activation 值。当您恢复受管集群激活资源时,对由 hub 集群主动管理的受管集群开始恢复。

1.1.2. 配置主动-被动 hub 集群

了解如何配置主动 - 被动 hub 集群配置,其中初始 hub 集群备份数据,在活跃集群不可用时,可以备份一个或多个被动 hub 集群,以便在活跃集群不可用时控制受管集群。

1.1.2.1. 主动-被动配置

在主动-被动配置中,有一个主动 hub 集群和多个被动 hub 集群。活跃的 hub 集群也被视为 hub 集群,它使用 BackupSchedule.cluster.open-cluster-management.io 资源在定义的时间间隔管理集群并备份资源。

主动和被动 hub 集群必须使用相同的 Red Hat Advanced Cluster Management for Kubernetes 版本。当您将 主动-被动配置 使用的 hub 集群时,首先将恢复 hub 升级到最新版本,然后升级主 hub 集群。

注: 要备份主 hub 集群数据,您不需要 主动 - 被动配置。您只需备份并存储 hub 集群数据。这样,如果出现问题或失败,您可以部署新的 hub 集群,并在这个新 hub 集群上恢复主 hub 集群数据。要减少恢复主 hub 集群数据的时间,您可以使用 主动 - 被动配置,但这不是必需的。

被动 hub 集群会持续检索最新的备份并恢复被动数据。当有新的备份数据时,被动 hub 使用 Restore.cluster.open-cluster-management.io 资源从主 hub 集群恢复被动数据。这些 hub 集群处于备用状态,当主 hub 集群失败时会成为主 hub 集群。

主动和被动 hub 集群连接到相同的存储位置,主 hub 集群备份 被动 hub 集群的数据,以访问主 hub 集群。有关如何设置此自动恢复配置的详情,请参阅在检查备份时恢复被动资源

在以下图中,活跃 hub 集群会管理本地集群并定期备份 hub 集群数据:

Active-passive configuration diagram

被动 hub 集群恢复这个数据,但受管集群激活数据除外,后者将受管集群移到 passive hub 集群。被动 hub 集群可以持续恢复被动数据。被动 hub 集群可以将被动数据恢复为一次性操作。如需了解更多详细信息,请参阅恢复被动资源

1.1.2.2. 灾难恢复

当主 hub 集群失败时,作为 hub 管理员,您可以选择一个被动 hub 集群来接管受管集群。在以下 灾难恢复图中,请参阅 如何使用 Hub 集群 N 作为新的主 hub 集群:

Disaster recovery diagram

hub 集群 N 恢复受管集群激活数据。受管集群连接到 Hub 集群 N。您可以通过创建一个 BackupSchedule.cluster.open- cluster -management.io 资源,并将备份存储在与初始主 hub 集群相同的存储位置,在新的主 hub 集群上激活备份。

所有其他被动 hub 集群现在使用新的主 hub 集群创建的备份数据恢复被动数据。Hub N 现在是主 hub 集群,管理集群和备份数据。

重要:

  • 早期 灾难恢复图中的第一个进程 没有被自动化,原因如下:

    • 您必须决定主 hub 集群是否失败,需要替换,或者 hub 集群和受管集群之间存在网络通信错误。
    • 您必须决定哪个被动 hub 集群成为主 hub 集群。策略与 Red Hat Ansible Automation Platform 作业集成,您可以通过在备份策略报告备份错误时进行作业运行来自动化此步骤。
  • 早期 灾难恢复图中的 第二个进程是 manual。如果您没有在新的主 hub 集群上创建备份调度,则 backup-restore-enabled 策略将使用 backup-schedule-cron-enabled 策略模板显示违反情况。在这个第二个过程中,您可以执行以下操作:

    • 使用 backup-schedule-cron-enabled 策略模板来验证新的主 hub 集群是否有作为 cron 作业运行的备份。
    • 使用策略与 Ansible 集成,并定义一个 Ansible 作业,该作业可在 backup-schedule-cron-enabled 策略模板报告违反情况时运行。
  • 有关 backup-restore-enabled 策略模板的详情,请参阅 验证备份或恢复配置

1.1.2.3. 其他资源

有关被动资源的更多信息,请参阅以下恢复选项:

1.1.3. 安装备份和恢复 Operator

集群备份和恢复 Operator 不会被自动安装。继续阅读以了解如何安装和启用 Operator。

1.1.3.1. 为备份和恢复 Operator 设置 hub 集群

要使用备份和恢复 Operator,您必须设置 hub 集群。要设置 hub 集群,请按顺序完成以下部分:

1.1.3.1.1. 创建存储位置 secret

要创建存储位置 secret,请完成以下步骤:

  1. 完成为保存备份的云存储 创建默认 Secret 的步骤。
  2. 在 OADP Operator 命名空间中创建 secret 资源,该资源位于备份组件命名空间中。
1.1.3.1.2. 启用备份 Operator

启用备份 Operator,以使用 Red Hat Advanced Cluster Management for Kubernetes 的灾难恢复解决方案。

1.1.3.1.2.1. 先决条件
  • 在 Red Hat OpenShift Container Platform 集群中,安装 Red Hat Advanced Cluster Management Operator 版本 2.12。安装 Red Hat Advanced Cluster Management 时会自动创建 MultiClusterHub 资源,并显示以下状态: Running
1.1.3.1.2.2. 为 hub 集群启用备份 Operator

要为您的主动和被动 hub 集群启用备份 Operator,请完成以下步骤:

  1. 通过完成以下步骤启用集群备份和恢复 Operator cluster-backup

    1. 通过将 cluster-backup 参数设置为 true 来更新 MultiClusterHub 资源。如果此 hub 集群没有启用 AWS 安全令牌服务(STS)选项,则 OADP Operator 也安装在带有备份组件的同一命名空间中。
    2. 对于启用了 STS 选项的 hub 集群,您必须手动安装 OADP operator。
  2. 确保恢复 hub 集群使用与备份 hub 集群使用的相同 Red Hat Advanced Cluster Management 版本。您不能在 hub 集群上恢复备份,其版本早于备份 hub 集群使用的版本。
  3. 通过完成以下步骤手动配置恢复 hub 集群:

    1. 安装在活跃 hub 集群上安装的所有 Operator,以及与活跃 hub 集群相同的命名空间中。
    2. 验证新 hub 集群是否已配置与备份 hub 集群相同。
    3. 安装备份和恢复 Operator 以及备份 hub 集群上配置的任何 Operator 时,请使用与备份 hub 集群相同的命名空间名称。
  4. 通过完成以下步骤,在被动 hub 集群上创建 DataProtectionApplication 资源:

    1. 在主动和被动 hub 集群上创建 DataProtectionApplication 资源。
    2. 对于恢复 hub 集群,当您创建 DataProtectionApplication 资源时,请使用与备份 hub 相同的存储位置。
1.1.3.1.3. 安装 OADP operator

对于启用了 AWS Security Token Service (STS)选项的 hub 集群,在 hub 集群上安装集群备份和恢复 Operator 时不会安装 OADP operator。要将 STS role_arn 传递给 OADP operator,您必须手动安装 OADP operator。

对于没有启用 STS 选项的 hub 集群,当您在 hub 集群上安装集群备份和恢复 Operator 时,会自动安装 OADP operator。

当您启用 MultiClusterHub 资源的 backup 选项时,backup 选项会一直处于 Pending 状态,直到您在 open-cluster-management-backup 命名空间中安装 OADP operator。如果您还没有在 hub 集群上启用 AWS STS 选项,则 OADP operator 会使用备份 chart 自动安装。否则,您必须手动安装 OADP operator。

当集群处于 STS 模式时,备份 chart 在 open-cluster-management-backup 命名空间中创建一个名为 acm-redhat-oadp-operator-subscription 的配置映射。此配置映射还包含 OADP 频道和环境信息。使用此配置映射获取您需要安装的 OADP 版本,并获取要在 OADP 订阅上设置的任何环境选项。

如需了解更多有关使用 STS 选项安装 OADP Operator 的信息,请参阅 OpenShift Container Platform 文档中的在 OADP ROSA 上备份工作负载

重要:

安装 OADP operator 时,请参阅以下备注:

  • 自定义资源定义是集群范围的,因此不能在同一集群中安装两个不同版本的 OADP 或 Velero。如果您有两个不同的版本,则一个版本会使用错误的自定义资源定义来运行。
  • 当您创建 MultiClusterHub 资源时,Velero 自定义资源定义(CRD)不会在 hub 集群中自动安装。安装 OADP operator 时,Velero CRD 会在 hub 集群上安装。因此,Multielero CRD 资源不再被 MultiClusterHub 资源协调和更新。
  • 备份组件可用于在组件命名空间中安装的 OADP Operator。
  • 如果手动安装 OADP operator,OADP operator 的自定义资源定义版本和 Velereo 必须完全匹配。如果这些版本不完全匹配,您会收到问题。
  • Velero 在 Red Hat Advanced Cluster Management for Kubernetes hub 集群中使用 OADP Operator 安装。它用于备份和恢复 Red Hat Advanced Cluster Management hub 集群资源。
  • 有关 Velero 支持的存储供应商列表,请参阅关于安装 OADP
1.1.3.1.4. 安装自定义 OADP 版本

MultiClusterHub 资源上设置注解后,您可以根据您的特定需求自定义 OADP 版本。完成以下步骤:

  1. 要覆盖备份和恢复 Operator 安装的 OADP 版本,请在 MultiClusterHub 资源中使用以下注解:

    installer.open-cluster-management.io/oadp-subscription-spec: '{"channel": "stable-1.4"}'
    Copy to Clipboard Toggle word wrap

    重要: 如果您使用这个选项获得与备份和恢复 Operator 默认安装的 OADP 版本不同的 OADP 版本,请确保 hub 集群使用的 Red Hat OpenShift Container Platform 版本上支持这个版本。请谨慎使用此覆盖选项,因为它可能会导致配置不受支持。

  2. 例如,通过设置注解来安装 OADP 1.5 版本。您的 MultiClusterHub 资源可能类似以下示例:

    apiVersion: operator.open-cluster-management.io/v1
    kind: MultiClusterHub
    metadata:
      annotations:
        installer.open-cluster-management.io/oadp-subscription-spec: '{"channel": "stable-1.5","installPlanApproval": "Automatic","name":
          "redhat-oadp-operator","source": "redhat-operators","sourceNamespace": "openshift-marketplace"}'
      name: multiclusterhub
    spec: {}
    Copy to Clipboard Toggle word wrap
  3. 通过将 cluster-back 设置为 true,在 MultiClusterHub 资源上启用 cluster-backup 选项。
1.1.3.1.5. 创建 DataProtectionApplication 资源

要为您的主动和被动 hub 集群创建 DataProtectionApplication 资源实例,请完成以下步骤:

  1. 在 Red Hat OpenShift Container Platform 控制台中选择 Operators > Installed Operators
  2. 在 DataProtectionApplication 下点 Create instance
  3. 使用 OpenShift Container Platform 控制台或使用 YAML 文件(如 DataProtectionApplication 示例中所述)选择配置来创建 Velero 实例。
  4. DataProtectionApplication namespace 设置为 open-cluster-management-backup
  5. DataProtectionApplication 资源正确设置规格(spec:)值。然后点创建

    如果您打算使用默认的备份存储位置,请在 backupStorageLocations 部分中设置以下值 default: true。查看以下 DataProtectionApplication 资源示例:

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: dpa-sample
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - aws
        restic:
          enable: true
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: my-bucket
              prefix: my-prefix
            config:
              region: us-east-1
              profile: "default"
            credential:
              name: cloud-credentials
              key: cloud
      snapshotLocations:
        - name: default
          velero:
            provider: aws
            config:
              region: us-west-2
              profile: "default"
    Copy to Clipboard Toggle word wrap

要在断开连接的环境中使用 Red Hat OpenShift Container Platform 启用备份和恢复组件,请完成以下步骤:

  1. 使用 follwing 注解更新 MultiClusterHub 资源,以覆盖安装 OADP Operator 的源。在 MultiClusterHub 资源上启用 cluster-backup 组件前创建注解:

    apiVersion: operator.open-cluster-management.io/v1
    kind: MultiClusterHub
    metadata:
      annotations:
        installer.open-cluster-management.io/oadp-subscription-spec: '{"source": "redhat-operator-index"}'
    Copy to Clipboard Toggle word wrap
  2. redhat-operator-index 是一个自定义名称,代表您定义并用来在断开连接的环境中访问 Red Hat OpenShift Operator 的 CatalogSource 资源的名称。运行以下命令来检索 catalogsource

    oc get catalogsource -A
    Copy to Clipboard Toggle word wrap

    输出可能类似以下:

    NAMESPACE               NAME                         DISPLAY                       TYPE   PUBLISHER   AGE
    openshift-marketplace   acm-custom-registry          Advanced Cluster Management   grpc   Red Hat     42h
    openshift-marketplace   multiclusterengine-catalog   MultiCluster Engine           grpc   Red Hat     42h
    openshift-marketplace   redhat-operator-index                                      grpc               42h
    Copy to Clipboard Toggle word wrap

1.1.3.2. 启用备份和恢复 Operator

当第一次创建 MultiClusterHub 资源时,可以启用集群备份和恢复 Operator。cluster-backup 参数设为 true。启用 Operator 后,会安装 operator 资源。

如果已创建了 MultiClusterHub 资源,您可以通过编辑 MultiClusterHub 资源来安装或卸载集群备份 Operator。如果要卸载集群备份 Operator,将 cluster-backup 设置为 false

启用备份和恢复 Operator 时,MultiClusterHub 资源可能类似以下 YAML 文件:

apiVersion: operator.open-cluster-management.io/v1
  kind: MultiClusterHub
  metadata:
    name: multiclusterhub
    namespace: open-cluster-management
  spec:
    availabilityConfig: High
    enableClusterBackup: false
    imagePullSecret: multiclusterhub-operator-pull-secret
    ingress:
      sslCiphers:
        - ECDHE-ECDSA-AES256-GCM-SHA384
        - ECDHE-RSA-AES256-GCM-SHA384
        - ECDHE-ECDSA-AES128-GCM-SHA256
        - ECDHE-RSA-AES128-GCM-SHA256
    overrides:
      components:
        - enabled: true
          name: multiclusterhub-repo
        - enabled: true
          name: search
        - enabled: true
          name: management-ingress
        - enabled: true
          name: console
        - enabled: true
          name: insights
        - enabled: true
          name: grc
        - enabled: true
          name: cluster-lifecycle
        - enabled: true
          name: volsync
        - enabled: true
          name: multicluster-engine
        - enabled: true
          name: cluster-backup
    separateCertificateManagement: false
Copy to Clipboard Toggle word wrap

1.1.3.3. 其他资源

1.1.4. 调度备份

通过调度备份,您可以确保数据保持保护并可访问。完成以下步骤以调度备份:

  1. 运行以下命令来创建 backupschedule.cluster.open-cluster-management.io 资源:

    oc create -f cluster_v1beta1_backupschedule.yaml
    Copy to Clipboard Toggle word wrap

    您的 cluster_v1beta1_backupschedule.yaml 资源可能类似以下文件:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
      name: schedule-acm
      namespace: open-cluster-management-backup
    spec:
      veleroSchedule: "0 */2 * * *" 
    1
    
      veleroTtl: 120h 
    2
    
      useManagedServiceAccount: true 
    3
    
      paused: false 
    4
    Copy to Clipboard Toggle word wrap
    1
    veleroSchedule 是必需属性,定义用于调度备份的 cron 作业。在前面的示例中,它每 2 小时创建一个备份。
    2
    可选: veleroTtl 是一个可选属性,定义调度的备份资源的过期时间。如果没有指定,则使用 Velero 设置的最大默认值,即 720h。它会在 120h 后删除调度的备份。
    3
    可选: 使用ManagedServiceAccount 是一个可选属性,可启用自动导入功能,在恢复操作中导入集群。如果您将其设置为 true,它会启用自动导入功能,在恢复操作中导入集群。
    4
    可选: paused 是一个可选属性,可以暂停备份调度。如果您将其设置为 true,它会暂停备份调度,请删除此资源创建的所有 Velero 调度。
  2. 检查 backupschedule.cluster.open-cluster-management.io 资源的状态,这会显示三个 schedule.velero.io 资源的定义。运行以下命令:

    oc get BackupSchedule -n open-cluster-management-backup
    Copy to Clipboard Toggle word wrap
  3. 提醒,恢复操作在不同的 hub 集群上运行,用于恢复场景。要启动恢复操作,请在要恢复备份的 hub 集群中创建一个 restore.cluster.open-cluster-management.io 资源。

    注:当您在新的 hub 集群上恢复备份时,请确保关闭创建备份的以前的 hub 集群。如果正在运行,则旧的 hub 集群会在受管集群协调发现受管集群不再可用时立即重新导入受管集群。

backupschedule.cluster.open-cluster-management.io 资源会创建六个 schedule.velero.io 资源,用于生成备份。运行以下命令查看调度的备份列表:

oc get schedules -A | grep acm
Copy to Clipboard Toggle word wrap

资源在组中单独备份,如下表所示:

Expand
表 1.2. 资源组表
资源描述

凭证 备份

存储 Hive 凭证、Red Hat Advanced Cluster Management 和用户创建的凭证和 ConfigMap 的备份文件。

资源 备份

包括一个 Red Hat Advanced Cluster Management 资源的备份,另一个用于通用资源。这些资源使用 cluster.open-cluster-management.io/backup 标签。

ManagedClusters backup

仅包含激活受管集群连接到 hub 集群的资源,其中恢复备份。

资源备份文件包含特定于受管集群的资源,但不包含将受管集群连接到 hub 集群的资源子集。连接受管集群的资源称为激活资源,并包含在受管集群备份中。当您只在新 hub 集群中为 凭证资源备份中恢复备份时,新的 hub 集群将所有使用 Hive API 创建的受管集群处于分离状态。只有在被动 hub 集群上恢复激活数据时,才会使用导入操作在主 hub 集群上导入的受管集群。受管集群仍然连接到创建备份文件的原始 hub 集群。

当恢复激活数据时,只有使用 Hive API 创建的受管集群才会与新的 hub 集群自动连接。所有其他受管集群都处于 Pending 状态。您需要手动将它们重新关联到新集群。

有关各种 BackupSchedule 状态的描述,请查看下表:

Expand
表 1.3. BackupSchedule 状态表
BackupSchedule 状态描述

Enabled

BackupSchedule 正在运行并生成备份。

FailedValidation

错误阻止 BackupSchedule 运行。因此,BackupSchedule 不会生成备份,而是协调并等待错误被修复。查看 BackupSchedule status 部分,以了解资源无效的原因。解决错误后,BackupSchedule 状态更改为 Enabled,资源开始生成备份。

BackupCollision

BackupSchedule 没有生成备份。查看 BackupSchedule status 部分,以了解资源状态为 BackupCollision 的原因。要开始创建备份,请删除此资源并创建一个新资源。

paused

如果您使用 BackupSchedule.paused 属性暂停 Red Hat Advanced Cluster Management 备份调度,由 BackupSchedule 资源创建的 Velero 调度会被删除,且没有生成新的 hub 备份。如果您将 BackupSchedule.paused 属性更新为 False,则 BackupSchedule 资源状态返回到 Enabled,Velero 调度被重新创建。

1.1.4.1. 了解备份冲突

如果 hub 集群的状态从被动改为主 hub 集群,或从主到被动(从主到被动)和不同的 hub 集群备份同一存储位置的数据,则可能会出现备份冲突。

因此,最新的备份由 hub 集群生成,该集群不再设置为主 hub 集群。这个 hub 集群仍然会生成备份,因为 BackupSchedule.cluster.open-cluster-management.io 资源仍被启用。

当您在受控环境中运行恢复操作(如灾难恢复测试操作)时,您可以在使用备份 hub 集群上的 BackupSchedule 暂停 属性时防止备份冲突。在恢复新 hub 集群上的资源前,请通过在 BackupSchedule 资源上设置 paused=true 属性来暂停备份 hub 上的 BackupSchedule 资源。

请参阅以下列表以了解两个可能会导致备份冲突的情况:

  1. 主 hub 集群意外失败,这由以下条件导致:

    • 从主 hub 集群到初始 hub 集群的通信会失败。
    • 初始 hub 集群备份数据会在名为 secondary hub 集群的二级 hub 集群上恢复。
    • 管理员在二级 hub 集群中创建 BackupSchedule.cluster.open-cluster-management.io 资源,该资源现在是主 hub 集群,并将备份数据生成到通用存储位置。
    • 初始 hub 集群意外开始工作。

      因为 BackupSchedule.cluster.open-cluster-management.io 资源在初始 hub 集群中仍被启用,所以初始 hub 集群会恢复到与二级 hub 集群相同的存储位置。现在,两个 hub 集群都在同一个存储位置写入备份数据。任何 hub 集群从这个存储位置恢复最新的备份都可以使用初始 hub 集群数据,而不是二级 hub 集群数据。

  2. 管理员通过将二级 hub 集群设置为主 hub 集群来测试灾难场景,这是由以下条件造成的:

    • 初始 hub 集群已停止。
    • 初始 hub 集群备份数据在二级 hub 集群上恢复。
    • 管理员在二级 hub 集群中创建 BackupSchedule.cluster.open-cluster-management.io 资源,该资源现在是主 hub 集群,并将备份数据生成到通用存储位置。
    • 灾难恢复完成后,管理员将恢复到之前的状态,并使初始 hub 集群再次变为主 hub 集群。
    • 当二级 hub 集群仍然处于活跃状态时,初始 hub 集群会启动。

      因为 BackupSchedule.cluster.open-cluster-management.io 资源仍然在二级 hub 集群中启用,所以它会在违反备份数据的同一存储位置写入备份。任何从此位置恢复最新备份的 hub 集群都可以使用二级 hub 集群数据,而不是初始 hub 集群数据。在这种情况下,在启动初始 hub 集群前,首先停止二级 hub 集群或暂停 BackupSchedule.cluster.open-cluster-management.io 资源,以避免备份冲突问题。

  3. 管理员通过使二级 hub 集群设置为主 hub 集群来测试灾难的情况,而无需首先停止初始 hub 集群,从而导致以下条件:

    • 初始 hub 集群仍在运行。
    • 初始 hub 集群备份数据在二级 hub 集群上恢复,包括受管集群备份。因此,二级 hub 集群现在是活跃的集群。
    • 因为 BackupSchedule.cluster.open-cluster-management.io 资源在初始 hub 集群上仍被启用,因此它会将备份位置写入破坏备份数据的同一存储位置。例如,任何 hub 集群从这个位置恢复最新的备份都可以使用初始 hub 集群数据,而不是二级 hub 集群数据。为避免数据崩溃,初始 hub 集群 BackupSchedule 资源状态会自动更改为 BackupCollision。在这种情况下,为了避免这个备份冲突状态,请首先停止初始 hub 集群,或者在在二级 hub 集群上恢复受管集群数据前,在初始 hub 集群上删除 BackupSchedule.cluster.open-cluster-management.io 资源。

1.1.4.2. 防止备份冲突

要防止和报告备份冲突,请使用 BackupSchedule.cluster.open-cluster-management.io 资源中的 BackupCollision 状态。控制器定期检查存储位置的最新备份是否已从当前 hub 集群生成。如果没有,则不同的 hub 集群最近已将备份数据写入存储位置,这表示 hub 集群与不同的 hub 集群合并。

在备份冲突场景中,当前 hub 集群 BackupSchedule.cluster.open-cluster-management.io 资源状态被设置为 BackupCollision。要防止数据崩溃,此资源会删除 Schedule.velero.io 资源。备份策略报告 BackupCollision

在同一场景中,管理员会验证哪些 hub 集群写入存储位置。管理员在从无效的 hub 集群中删除 BackupSchedule.cluster.open-cluster-management.io 资源前进行这个验证。然后,管理员可以在有效的主 hub 集群上创建一个新的 BackupSchedule.cluster.open-cluster-management.io 资源,恢复备份。

要检查是否有备份冲突,请运行以下命令:

oc get backupschedule -A
Copy to Clipboard Toggle word wrap

如果存在备份冲突,输出可能类似以下示例:

NAMESPACE       NAME               PHASE             MESSAGE
openshift-adp   schedule-hub-1   BackupCollision   Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to  resume backups from this cluster.
Copy to Clipboard Toggle word wrap

1.1.4.3. 其他资源

  • 有关 Restore YAML 资源的参数和示例的描述,请参阅 恢复备份 部分。
  • 如需更多信息,请参阅 备份和恢复

1.1.5. 恢复备份

在典型的恢复情形中,备份运行的 hub 集群变得不可用,您需要将备份的数据移到新的 hub 集群。在新 hub 集群上运行集群恢复操作。在这种情况下,恢复操作会在创建备份的不同 hub 集群中运行。

如果要恢复收集备份的同一 hub 集群上的数据,您可以从早期快照中恢复数据。在这种情况下,恢复和备份操作都在同一 hub 集群中运行。

要完全恢复备份,请完成以下内容:

1.1.5.1. 使用恢复操作进行备份类型

使用恢复操作恢复备份操作创建的所有三种备份类型。选择只安装特定类型的备份,如只安装受管集群、仅用户凭证或只安装 hub 集群资源。

恢复定义以下三个必要的 spec 属性,其中为备份文件类型定义了恢复逻辑:

  • veleroManagedClustersBackupName 用于定义受管集群激活资源的恢复选项。
  • veleroCredentialsBackupName 用于为用户凭证定义 restore 选项。
  • veleroResourcesBackupName 用于定义 hub 集群资源的 restore 选项(ApplicationsPolicy 及其他 hub 集群资源,如受管集群被动数据)。

    前面提到的属性的有效选项有以下值:

    • latest - 此属性恢复此类型的备份文件。
    • skip - 此属性不会尝试使用当前恢复操作恢复这种类型的备份。
    • <backup_name> - 此属性按名称恢复指向它的指定的备份。

restore.cluster.open-cluster-management.io 创建的 restore.velero.io 资源的名称遵循以下模版规则 <restore.cluster.open-cluster-management.io name>-<velero-backup-resource-name>.查看以下描述:

  • restore.cluster.open-cluster-management.io 名称 是当前 restore.cluster.open-cluster-management.io 资源的名称,该资源用于启动恢复。
  • velero-backup-resource-name 是 Velero 备份文件的名称,用于恢复数据。例如,名为 restore-acmrestore.cluster.open-cluster-management.io 资源创建 restore.velero.io 恢复资源。查看以下格式示例:

    • restore-acm-acm-managed-clusters-schedule-20210902205438 可用于恢复受管集群激活数据备份。在本例中,用于恢复资源的 backup.velero.io 备份名称为 acm-managed-clusters-schedule-20210902205438
    • restore-acm-acm-credentials-schedule-20210902206789 用于恢复凭据备份。在本例中,用于恢复资源的 backup.velero.io 备份名称为 acm-managed-clusters-schedule-20210902206789
    • restore-acm-acm-resources-schedule-20210902201234 用于恢复应用程序、策略和其他 hub 集群资源,如受管集群被动数据备份。在这个示例中,用于恢复资源的 backup.velero.io 备份名称为 acm-managed-clusters-schedule-20210902201234

注:如果 skip 用于备份类型,则不会创建 restore.velero.io

查看以下集群 Restore 资源的 YAML 示例。在这个示例中,使用最新可用的备份文件恢复所有三种备份文件:

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest
Copy to Clipboard Toggle word wrap

Note:当来自受管集群备份的 acm-managed-clusters 备份被恢复到另外一个 hub 集群时,只有 Hive API 创建的受管集群会自动连接到新的 hub 集群。所有其他受管集群都处于 Pending Import 状态,且必须重新导入到新的 hub 集群中。如需更多信息,请参阅恢复导入的受管集群

1.1.5.2. 将数据恢复到初始主 hub

当您需要恢复集群中的备份数据时,使用主 hub 集群或带有用户创建的资源的 hub 集群创建新集群而不是恢复数据。

如果将数据恢复到初始主 hub 集群,则您的当前 hub 集群和主 hub 集群都可以访问受管集群。hub 集群都尝试控制,使受管集群在 hub 集群之间持续返回。

如果您使用在恢复操作前用户创建的资源的 hub 集群上恢复数据,则操作将无法包含资源。hub 集群上的数据不包含所有可用的数据。

在灾难恢复测试场景中,使用主 hub 集群作为被动集群。在灾难恢复测试中,您只能在被动 hub 上验证恢复操作,然后使用主 hub 集群。

您只测试 hub 备份集群,且不使用主 hub 集群创建新资源。相反,备份数据会临时从主 hub 集群移到 passive hub 集群。如果恢复所有资源,您可以使初始主 hub 集群再次成为主 hub 集群。此操作运行后恢复操作,并将受管集群重新移至此 hub 集群。

重要: 在灾难恢复测试中,在切换到初始主 hub 集群前停止恢复集群。停止恢复集群可防止在恢复操作将数据移到初始主 hub 集群后返回受管集群。

1.1.5.3. 准备新的 hub 集群

当您需要在 hub 集群上恢复备份数据时,请创建一个新的 hub 集群,而不是使用主 hub 集群,或之前在恢复操作前创建资源的 hub 集群。

在灾难恢复场景中,当将备份恢复到被动 hub 集群时,您希望一个 hub 集群与灾难过程中失败的 hub 集群相同。您不需要任何其他用户资源,如应用程序、策略和额外的受管集群。

当您恢复此 hub 集群上的备份时,如果您有由此 hub 集群管理的受管集群,恢复操作可能会分离它们并删除其集群资源。恢复操作会进行清理不是恢复备份一部分的资源,使此 hub 集群中的内容与初始 hub 集群相同。在这种情况下,您可能会丢失用户数据,因为受管集群工作负载由 detach 操作删除。

在新 hub 集群上运行恢复操作前,您需要手动配置 hub 集群,并在初始 hub 集群上安装相同的 Operator。您必须在与初始 hub 集群相同的命名空间中安装 Red Hat Advanced Cluster Management Operator,创建 DataProtectionApplication 资源,然后连接到之前备份了数据的同一存储位置。

对 Red Hat Advanced Cluster Management Operator 创建的 MultiClusterHub 资源使用与初始 hub 集群上的配置相同,包括对 MultiClusterEngine 资源的任何更改。

例如,如果初始 hub 集群安装了任何其他 Operator,如 Ansible Automation Platform、Red Hat OpenShift GitOps、cert-manager,则必须在运行恢复操作前安装它们。这样可确保配置新的 hub 集群与初始 hub 集群相同。

在与备份数据的 hub 集群相同的 Red Hat Advanced Cluster Management Operator 版本上运行恢复操作。如果要在使用较新的 Red Hat Advanced Cluster Management Operator 版本的 hub 集群中运行恢复操作,请完成以下步骤:

  1. 在恢复 hub 集群中,将 Red Hat Advanced Cluster Management Operator 安装到与创建备份的 hub 集群相同的版本。
  2. 恢复恢复 hub 集群上的备份数据。
  3. 在恢复 hub 集群中,使用 upgrade 操作升级到您要使用的 Red Hat Advanced Cluster Managementoperator 版本。

1.1.5.5. 在恢复后清理 hub 集群

如果使用当前恢复的备份更改了,Velero 会更新现有资源。Velero 不会清理 delta 资源,这些资源是由以前的恢复创建的资源,而不是当前恢复的备份的一部分。这限制了在新 hub 集群上恢复 hub 集群数据时可以使用的情况。除非恢复只应用一次,否则您无法可靠地使用新的 hub 集群作为被动配置。hub 集群中的数据没有反映恢复的资源可用的数据。

为解决这个限制,当创建 Restore.cluster.open-cluster-management.io 资源时,备份 Operator 会运行一个清理 hub 集群的 post 恢复操作。该操作会删除之前不是由 Red Hat Advanced Cluster Management 恢复(不是当前恢复的备份的一部分)创建的资源。

后恢复清理使用 cleanupBeforeRestore 属性来识别要清理的对象子集。您可以使用以下选项进行后恢复清理:

  • None: 不需要清理,只开始 Velero 恢复。在新 hub 集群中使用 None
  • CleanupRestored :清理之前由以前 Red Hat Advanced Cluster Management 恢复创建的所有资源,这些资源不是当前恢复的备份的一部分。
  • CleanupAll :清理 hub 集群上可能成为 Red Hat Advanced Cluster Management 备份的一部分的所有资源,即使它们没有因为恢复操作而创建。这在恢复操作启动前在 hub 集群上创建额外内容时使用。

    最佳实践:避免使用 CleanupAll 选项。仅将它用作最后的手段,且需要非常小心。除了之前恢复的备份创建的资源外,CleanupAll 还会清理用户创建的 hub 集群上的资源。反之,使用 CleanupRestored 选项来防止在 hub 集群指定为灾难场景的被动候选时更新 hub 集群内容。使用干净的 hub 集群作为被动集群。

备注:

  • 如果恢复的备份没有资源,Velero 会为 velero 恢复资源设置状态 PartiallyFailed。这意味着,如果任何创建的 restore.velero.io 资源没有恢复任何资源,则 restore.cluster.open-cluster-management.io 资源可能会处于 PartiallyFailed 状态。
  • restore.cluster.open-cluster-management.io 资源会运行一次,除非您使用 syncRestoreWithNewBackups:true 来在新的备份可用时恢复被动数据。在这种情况下,请按照使用同步示例的恢复被动操作。请参阅在检查备份时恢复被动资源。完成恢复操作后,您想要在同一 hub 集群上运行另一个恢复操作,您必须创建一个新的 restore.cluster.open-cluster-management.io 资源。
  • 虽然您可以创建多个 restore.cluster.open-cluster-management.io 资源,但在任何时间点上只能有一个。

1.1.5.6. 在检查备份时恢复被动资源

使用 restore-passive-sync 示例恢复被动数据,同时继续检查新备份是否可用并自动恢复它们。要自动恢复新的备份,您必须将 syncRestoreWithNewBackups 参数设置为 true。您还必须仅恢复最新的被动数据。您可以在本节末尾找到示例示例。

VeleroResourcesBackupNameVeleroCredentialsBackupName 参数设置为 latestVeleroManagedClustersBackupName 参数为 skip。当将 VeleroManagedClustersBackupName 设置为 latest 后,受管集群会在新的 hub 集群中激活,现在是主 hub 集群。

当激活的受管集群变为主 hub 集群时,恢复资源被设置为 Finished,并且 syncRestoreWithNewBackups 会被忽略,即使设置为 true

默认情况下,当 syncRestoreWithNewBackups 设为 true 时,控制器会每 30 分钟检查新的备份。如果找到新的备份,它会恢复备份的资源。您可以通过更新 restoreSyncInterval 参数来更改检查的持续时间。

如果要在恢复操作完成后再次运行相同的恢复操作,您必须创建一个具有相同 spec 选项的新 restore.cluster.open-cluster-management.io 资源。

例如,请查看以下资源每 10 分钟检查备份:

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-sync
  namespace: open-cluster-management-backup
spec:
  syncRestoreWithNewBackups: true # restore again when new backups are available
  restoreSyncInterval: 10m # check for new backups every 10 minutes
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest
Copy to Clipboard Toggle word wrap

1.1.5.7. 恢复被动资源

使用 restore-acm-passive 示例在被动配置中恢复 hub 集群资源。被动数据是备份数据,如 secret、ConfigMap、应用程序、策略以及所有受管集群自定义资源,它不在受管集群和 hub 集群之间激活连接。备份资源通过凭证备份和恢复资源在 hub 集群上恢复。

请参见以下示例:

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest
Copy to Clipboard Toggle word wrap

1.1.5.8. 恢复激活资源

在恢复被动 hub 集群上的激活数据前,请关闭创建备份的之前的 hub 集群。如果主 hub 集群仍在运行,它会尝试根据在此 hub 集群上运行的协调流程,尝试使用不再可用的受管集群。

当您希望 hub 集群管理集群时,请使用 restore-acm-passive-activate 示例。在这种情况下,假设其它数据已在使用被动资源的 hub 集群上恢复。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-activate
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: skip
  veleroResourcesBackupName: skip
Copy to Clipboard Toggle word wrap

根据您如何恢复被动资源,您有一些选项来恢复激活资源:

  • 如果您使用 restore-acm-passive-sync cluster.open-cluster-management.io 资源,如 Restore passive resources while checking for backups to restore passive data 部分所述,将 veleroManagedClustersBackupName 值更新为 latest。因此,受管集群资源和 restore-acm-passive-sync 资源会被恢复。
  • 如果您将被动资源恢复为一个时间操作,或者还没有恢复任何资源,选择恢复所有资源,如 恢复所有资源部分所述。

1.1.5.9. 恢复受管集群激活数据

当使用 cluster.open-cluster-management.io/backup: cluster-activation 标签时,受管集群激活数据或其他激活数据资源由受管集群备份和 resource-generic 备份存储。当在新的 hub 集群上恢复激活数据时,受管集群由运行恢复的 hub 集群主动管理。请参阅 调度和恢复备份 以了解如何使用 Operator。

1.1.5.10. 恢复所有资源

要恢复所有数据,请使用以下 restore-acm 示例:

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest
Copy to Clipboard Toggle word wrap

在 hub 集群中创建 restore.cluster.open-cluster-management.io 资源后,运行以下命令来获取恢复操作的状态:

oc describe -n open-cluster-management-backup restore-acm
Copy to Clipboard Toggle word wrap

1.1.5.11. 恢复导入的受管集群

只有使用 Hive API 与主 hub 集群连接的受管集群会自动连接到新的 hub 集群,其中恢复激活数据。这些集群由 Hive API 在主 hub 集群上创建,使用 Clusters 选项卡中的 Create cluster 按钮或通过 CLI 创建。当激活数据被恢复时,使用 Import cluster 按钮连接到初始 hub 集群的受管集群显示为 Pending Import,需要在新的 hub 集群中重新导入。

Hive 受管集群可以与新的 hub 集群连接,因为 Hive 将受管集群 kubeconfig 存储在 hub 集群上的受管集群命名空间中。这在新的 hub 集群上备份和恢复。然后,导入控制器使用恢复的配置更新受管集群上的 bootstrap kubeconfig,该配置仅适用于使用 Hive API 创建的受管集群。导入的集群不可用。

要在恢复操作过程中重新在新 hub 集群上重新连接导入的集群,请在 BackupSchedule 上启用自动导入功能。如需更多信息,请参阅启用自动导入

1.1.5.12. 使用其他恢复示例

查看以下 YAML 示例以恢复不同类型的备份文件:

  • 恢复所有三种备份资源:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupSchedule: latest
      veleroCredentialsBackupSchedule: latest
      veleroResourcesBackupSchedule: latest
    Copy to Clipboard Toggle word wrap
  • 仅恢复受管集群资源:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupName: latest
      veleroCredentialsBackupName: skip
      veleroResourcesBackupName: skip
    Copy to Clipboard Toggle word wrap
  • 使用 acm-managed-clusters-schedule-20210902205438 备份只为受管集群恢复资源:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupName: acm-managed-clusters-schedule-20210902205438
      veleroCredentialsBackupName: skip
      veleroResourcesBackupName: skip
    Copy to Clipboard Toggle word wrap

    备注:

    • 如果阶段为 EnabledRunning,则 restore.cluster.open-cluster-management.io 资源仍然活跃。如果阶段更改为 Finished,则资源运行已完成。恢复操作完成后,您可以在同一 hub 集群中运行另一个恢复操作。
    • 一次只能运行一个 restore.cluster.open-cluster-management.io
  • 使用带有 velero.io.restore 的高级选项对要恢复的资源进行文件化。将以下示例与 velero.io.restore spec 选项一起使用,只从 vb-managed-cls-2 受管集群命名空间中恢复资源,并排除全局 MultiCluster 资源:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-filter-sample
      namespace: open-cluster-management-backup
    spec:
      cleanupBeforeRestore: None
      veleroCredentialsBackupName: latest
      veleroResourcesBackupName: latest
      veleroManagedClustersBackupName: latest
    excludedResources:
      - ManagedCluster
    orLabelSelectors:
      - matchExpressions:
      - values:
      - vb-managed-cls-2
    key: name
    operator: In
    Copy to Clipboard Toggle word wrap
  • 在创建 Red Hat Advanced Cluster Management 恢复资源时设置以下 velero.io.restore spec 选项:

    spec:
      includedResources
      includedNamespaces
      excludedResources
      excludedNamespaces
      LabelSelector
      OrLabelSelector
    Copy to Clipboard Toggle word wrap

    备注:

    • 当您设置任何这些 Velero 恢复过滤器时,将 cleanupBeforeRestore 设置为 None,以避免清理作为恢复备份一部分的 hub 集群资源,但不会因为应用的过滤器被恢复。

1.1.5.13. 使用高级恢复选项

velero.io.restore 规范定义了高级恢复选项。您可以使用这些高级恢复选项来过滤您要恢复的资源。

例如,您可以使用以下 YAML 示例只从 vb-managed-cls-2 受管集群命名空间中恢复资源,并排除全局 Managedluster 资源:

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-filter-sample
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest
  veleroManagedClustersBackupName: latest
  excludedResources:
    - ManagedCluster
  includedNamespaces:
    - vb-managed-cls-2
Copy to Clipboard Toggle word wrap

如果您在创建 Red Hat Advanced Cluster Management for Kubernetes 恢复资源时需要更多 velero.io.restore 规格的选项,请参阅以下恢复过滤器:

spec:
  includedResources
  includedNamespaces
  excludedResources
  excludedNamespaces
  LabelSelector
  OrLabelSelector
Copy to Clipboard Toggle word wrap

注: 对于任何 Velero 恢复过滤器,将 cleanupBeforeRestore 字段设置为 None,以防止清理属于恢复备份一部分的 hub 集群资源,但不会被因为应用的过滤器恢复。

1.1.5.14. 查看恢复事件

使用以下命令获取有关恢复事件的信息:

oc describe -n open-cluster-management-backup <restore-name>
Copy to Clipboard Toggle word wrap

您的事件列表可能类似以下示例:

Spec:
  Cleanup Before Restore:               CleanupRestored
  Restore Sync Interval:                4m
  Sync Restore With New Backups:        true
  Velero Credentials Backup Name:       latest
  Velero Managed Clusters Backup Name:  skip
  Velero Resources Backup Name:         latest
Status:
  Last Message:                     Velero restores have run to completion, restore will continue to sync with new backups
  Phase:                            Enabled
  Velero Credentials Restore Name:  example-acm-credentials-schedule-20220406171919
  Velero Resources Restore Name:    example-acm-resources-schedule-20220406171920
Events:
  Type    Reason                   Age   From                Message
  ----    ------                   ----  ----                -------
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-generic-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-cluster-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      64m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-cluster-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406171920
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406171920
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-cluster-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-generic-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-hive-schedule-20220406171919
Copy to Clipboard Toggle word wrap

1.1.5.15. 其他资源

1.1.6. 使用受管服务帐户自动连接集群

备份控制器使用 Managed Service Account 组件自动将导入的集群连接到新的 hub 集群。Managed Service Account 创建一个令牌,为每个受管集群命名空间中的每个导入的集群备份令牌。该令牌使用 klusterlet-bootstrap-kubeconfig ClusterRole 绑定,允许自动导入操作使用令牌。klusterlet-bootstrap-kubeconfig ClusterRole 只能获取或更新 bootstrap-hub-kubeconfig secret。要了解更多有关受管服务帐户组件的信息,请参阅什么是受管服务帐户?

当新 hub 集群上恢复激活数据时,恢复控制器会运行 post 恢复操作,并查找处于 Pending Import 状态的所有受管集群。如果找到了 Managed Service Account 生成的有效令牌,控制器会使用令牌创建一个 auto-import-secret。因此,导入组件会尝试重新连接受管集群。如果可以访问集群,则操作可以成功。

1.1.6.1. 启用自动导入

默认情况下,禁用使用 Managed Service Account 组件的自动导入功能。要启用自动导入功能,请完成以下步骤:

  1. 通过在 MultiClusterEngine 资源中将 managedserviceaccount enabled 参数设置为 true 来启用 Managed Service Account 组件。请参见以下示例:

    apiVersion: multicluster.openshift.io/v1
    kind: MultiClusterEngine
    metadata:
      name: mmulticlusterengine
    spec:
      overrides:
        components:
          - enabled: true
            name: managedserviceaccount
    Copy to Clipboard Toggle word wrap
  2. 通过将 useManagedServiceAccount 参数设置为 true,为 BackupSchedule.cluster.open-cluster-management.io 资源启用自动导入功能。请参见以下示例:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
      name: schedule-acm-msa
      namespace: open-cluster-management-backup
    spec:
      veleroSchedule:
      veleroTtl: 120h
      useManagedServiceAccount: true
    Copy to Clipboard Toggle word wrap

    默认令牌有效期持续时间被设置为 veleroTtl 值的两倍,以提高令牌对整个生命周期存储令牌的所有备份的几率。在某些情况下,您可能需要通过为可选的 managedServiceAccountTTL 属性设置值来控制令牌的有效时长。

    如果您需要为生成的令牌更新默认令牌过期时间,请谨慎使用 managedServiceAccountTTL。从默认值更改令牌过期时间可能会导致生成带有令牌集的备份,在备份生命周期中过期。因此,导入功能不适用于受管集群。

    重要 :除非需要控制令牌的有效时长,否则不要使用 managedServiceAccountTTL

    有关使用 managedServiceAccountTTL 属性的示例:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
      name: schedule-acm-msa
      namespace: open-cluster-management-backup
    spec:
      veleroSchedule:
      veleroTtl: 120h
      useManagedServiceAccount: true
      managedServiceAccountTTL: 300h
    Copy to Clipboard Toggle word wrap

启用自动导入功能后,备份组件通过创建以下内容开始处理导入的受管集群:

  • 名为 managed-serviceaccountManagedServiceAddon
  • 名为 auto-import-accountManagedServiceAccount
  • 每个 ManagedServiceAccountManifestWork,用于为受管集群上的 ManagedServiceAccount 令牌设置 klusterlet-bootstrap-kubeconfig RoleBinding

只有在创建 Managed Service Account 时可以访问受管集群时,才会创建令牌,否则在受管集群可用后它会被创建。

1.1.6.2. 自动导入注意事项

以下场景可能会阻止受管集群在迁移到新 hub 集群时被自动导入:

  • 在没有 ManagedServiceAccount 令牌的情况下运行 hub 备份时,例如在受管集群无法访问时创建 ManagedServiceAccount 资源时,备份不包含自动导入受管集群的令牌。
  • 如果 auto-import-account secret 令牌有效并且已备份,但在备份的可用令牌已过期时运行恢复操作,则自动导入操作会失败。restore.cluster.open-cluster-management.io 资源会为每个受管集群报告无效的令牌问题。
  • 因此在恢复时创建的 auto-import-secret 使用 ManagedServiceAccount 令牌连接到受管集群,受管集群还必须提供 kube apiserver 信息。apiserver 必须在 ManagedCluster 资源中设置。请参见以下示例:

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      name: managed-cluster-name
    spec:
      hubAcceptsClient: true
      leaseDurationSeconds: 60
      managedClusterClientConfigs:
          url: <apiserver>
    Copy to Clipboard Toggle word wrap

    当在 hub 集群中导入集群时,只会在 OpenShift Container Platform 集群中自动设置 apiserver。您必须在其他类型的受管集群中手动设置 apiserver,如 EKS 集群,否则自动导入功能会忽略集群。因此,当您将其移到恢复 hub 集群时,集群会处于 Pending Import 状态。

  • 如果备份调度在 ManagedServiceAccount secret 上设置了备份标签前运行,则 ManagedServiceAccount secret 可能不包含在备份中。ManagedServiceAccount secret 在创建时没有设置集群 open-cluster-management.io/backup 标签。因此,备份控制器定期在受管集群命名空间下搜索 ManagedServiceAccount secret,并在未找到时添加备份标签。

1.1.6.3. 禁用自动导入

您可以通过在 BackupSchedule 资源中将 useManagedServiceAccount 参数设置为 false 来禁用自动导入集群功能。请参见以下示例:

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule:
  veleroTtl: 120h
  useManagedServiceAccount: false
Copy to Clipboard Toggle word wrap

默认值为 false。将值设为 false 后,备份 Operator 会删除所有创建的资源,包括 ManagedServiceAddonManagedServiceAccountManifestWork。删除资源会删除 hub 集群和受管集群中的自动导入令牌。

1.1.6.4. 其他资源

1.1.7. 验证备份或恢复配置

当在 MultiClusterHub 资源中将 cluster-backup 选项设置为 true 时,multicluster engine operator 会安装集群备份和恢复名为 cluster-backup-chart 的 operator Helm chart。然后,此图会安装 backup-restore-enabledbackup-restore-auto-import 策略。使用这些策略查看有关备份和恢复组件问题的信息。

注: hub 集群由 作为 local-cluster 自动导入和自我管理。如果您通过将 MultiClusterHub 资源上的 disableHubSelfManagement 设置为 true 来禁用自我管理,则 backup-restore-enabled 策略不会放置在 hub 集群中,策略模板不会生成任何报告。

如果 hub 集群由全局 hub 集群管理,或者安装在受管集群实例上,则 self-management 选项可能会通过将 disableHubSelfManagement 设置为 true 来禁用。在这个实例中,您仍然可以在 hub 集群上启用 backup-restore-enabled 策略。在代表本地集群的 ManagedCluster 资源中设置 is-hub=true 标签。

backup-restore-enabled 策略包括一组用于检查以下限制的模板:

  • OADP 频道验证

    • 当您在 MultiClusterHub 上启用备份组件时,集群备份和恢复 Operator Helm chart 可以在 open-cluster-management-backup 命名空间中自动安装 OADP Operator。您还可以在命名空间中手动安装 OADP operator。
    • 为手动安装选择的 OADP-channel 必须匹配或超过 Red Hat Advanced Cluster Management 备份和恢复 Operator Helm Chart 版本。
    • 由于 OADP Operator 和 Velero 自定义资源定义(CRD) 是集群范围的,所以您无法在同一集群中有多个版本。您必须在 open-cluster-management-backup 命名空间和任何其他命名空间中安装相同的版本。
    • 使用以下模板来检查可用性并验证 OADP 安装:

      • OADP -operator-exists :使用此模板验证 OADP operator 是否安装在 open-cluster-management-backup 命名空间中。
      • OADP -channel-validation :使用此模板来确保 open-cluster-management-backup 命名空间中的 OADP operator 版本与 Red Hat Advanced Cluster Management 备份和恢复 Operator 设置的版本匹配或超过。
      • custom-oadp-channel-validation :使用此模板检查其他命名空间中的 OADP operator 是否与 open-cluster-management-backup 命名空间中的版本匹配。
  • Pod 验证

    以下模板检查备份组件和依赖项的 pod 状态:

    • acm-backup-pod-running 模板检查备份和恢复 operator pod 是否在运行。
    • oadp-pod-running 模板检查 OADP operator pod 是否在运行。
    • velero-pod-running 模板检查 Velero pod 是否在运行。
  • 数据保护应用程序验证

    • data-protection-application-available 模板检查是否创建了 DataProtectioApplicatio.oadp.openshift.io 资源。这个 OADP 资源设置 Velero 配置。
  • 备份存储验证

    • backup-storage-location-available 模板检查 BackupStorageLocation.velero.io 资源是否已创建以及状态值是否为 Available。这意味着与备份存储的连接有效。
  • BackupSchedule 冲突验证

    • 如果当前 hub 集群上存在 BackupSchedule.cluster.open-cluster-management.io,则 acm-backup-clusters-collision-report 模板会验证状态不是 BackupCollision。这会在将备份数据写入存储位置时,验证当前 hub 集群与其它 hub 集群不冲突。

      有关 BackupCollision 的定义,请参阅 防止备份冲突

  • BackupSchedule 和恢复状态验证

    • acm-backup-phase-validation 模板检查当前集群中是否存在 BackupSchedule.cluster.open-cluster-management.io,则检查状态为 FailedEmpty 状态。这样可确保如果此集群是主 hub 集群,并正在生成备份,则 BackupSchedule.cluster.open-cluster-management.io 状态是健康。
    • 如果当前集群中存在 Restore.cluster.open-cluster-management.io,则相同的模板会检查当前集群中没有处于 FailedEmpty 状态的状态。这样可确保如果这个集群是二级 hub 集群,且被恢复备份,Restore.cluster.open-cluster-management.io 状态是健康。
  • 备份存在验证

    • acm-managed-clusters-schedule-backups-available 模板检查 Backup.velero.io 资源是否位于 BackupStorageLocation.velero.io 指定的位置上,以及备份是否由 BackupSchedule.cluster.open-cluster-management.io 资源创建。这验证了备份已至少运行一次,使用备份和恢复 Operator。
  • 备份完成

    • acm-backup-in-progress-report 模板检查 Backup.velero.io 资源是否处于 InProgress 状态。这个验证会被添加,因为带有大量资源,velero pod 会作为备份运行重启,备份会停留在不继续完成状态。在正常备份过程中,备份资源会在某一时间点进行,但不会被卡住并在完成运行。正常情况下,在调度运行时报告 acm-backup-in-progress-report 模板会在调度运行时报告警告并备份正在进行。
  • 备份调度在主 hub 集群上生成备份

    • backup-schedule-cron-enabled 策略模板通知 hub 集群管理员主 hub 集群没有创建新的备份。策略显示 BackupSchedule.cluster.open-cluster-management.io 资源在主 hub 集群中被禁用,或者无法创建调度的备份。
    • 如果主 hub 集群上的备份调度没有生成新的备份,则 backup-schedule-cron-enabled 策略模板会处于违反状态。如果 BackupSchedule 不存在,将暂停,或者更新 BackupSchedule cron job 属性以及运行增加备份的时间,会出现这种情况。该模板违反了,直到创建新的备份集为止。
    • 模板验证以以下方式工作:

      • BackupSchedule.cluster.open-cluster-management.io 主动运行并在存储位置保存新的备份。backup-schedule-cron-enabled 策略模板完成此验证。模板检查是否有带有 velero.io/schedule-name: acm-validation-policy-schedule 标签的 Backup.velero.io
      • acm-validation-policy-schedule 备份设置为在为备份 cron 调度设置时间后过期。如果没有创建备份的 cron 作业,旧的 acm-validation-policy-schedule 备份将被删除,因为它过期且没有创建新的备份。因此,如果没有 acm-validation-policy-schedule backups,则没有活跃的 cron 作业生成备份。

backup-restore-auto-import 策略包括一组用于检查以下限制的模板:

  • 自动导入 secret 验证

    • auto-import-account-secret 模板检查 ManagedServiceAccount secret 是否在 local-cluster 以外的受管集群命名空间中创建。备份控制器定期扫描导入的受管集群。发现受管集群后,备份控制器会在受管集群命名空间中创建 ManagedServiceAccount 资源。此过程会在受管集群中启动令牌创建。但是,如果此操作无法访问受管集群,则 ManagedServiceAccount 无法创建令牌。例如,如果受管集群正在休眠,则无法创建令牌。因此,如果在此期间执行 hub 备份,则备份缺少自动导入受管集群的令牌。
  • 自动导入备份标签验证

    • auto-import-backup-label 模板验证 local-cluster 以外的受管集群命名空间中是否存在 ManagedServiceAccount secret。如果模板找到 ManagedServiceAccount secret,则模板会在 secret 上强制执行 cluster.open-cluster-management.io/backup 标签。该标签对于在 Red Hat Advanced Cluster Management 备份中包含 ManagedServiceAccount secret 至关重要。

1.1.7.1. 使用服务器端加密保护数据

服务器端加密是应用程序或服务的数据加密,在存储位置接收数据。在传输过程中,备份机制本身不会加密数据(因为它会前往备份存储位置),或其他人(同时存储在备份存储位置的磁盘上)。它依赖于对象和快照系统中的原生机制。

最佳实践 :使用可用的备份存储服务器端加密数据。备份包含资源,如在 hub 集群外存储需要加密的凭证和配置文件。

您可以使用 serverSideEncryptionkmsKeyId 参数为存储在 Amazon S3 中的备份启用加密。如需了解更多详细信息,请参阅备份存储位置 YAML。以下示例指定在设置 DataProtectionApplication 资源时的 AWS KMS 密钥 ID:

spec:
  backupLocations:
    - velero:
        config:
          kmsKeyId: 502b409c-4da1-419f-a16e-eif453b3i49f
          profile: default
          region: us-east-1
Copy to Clipboard Toggle word wrap

请参阅 Velero 支持的存储供应商,以找出其它存储供应商的所有可配置参数。

1.1.7.2. 其他资源

在典型的灾难恢复操作中,主 hub 集群不活跃,且恢复 hub 集群没有冲突。例如,在运行灾难恢复模拟测试时,您可能需要在恢复操作或之后保留原始 hub 集群。

当您的主 hub 集群仍然活跃时,当您将数据恢复到新的 hub 集群时,两个 hub 集群都尝试管理同一集群群。如果主 hub 集群控制受管集群,可能会覆盖您对新 hub 集群所做的策略或应用程序更改。

要在新 hub 集群上安全地恢复 hub 数据,同时保持主 hub 集群活跃,请在运行灾难恢复测试前配置主 hub 集群。完成以下任务:

1.1.8.1. 准备主 hub 集群

在运行恢复操作并保持 hub 集群活跃前,您必须准备主 hub 集群。

要准备主 hub 集群,请完成以下步骤:

  1. 通过将 paused 属性设为 true 来暂停 BackupSchedule 资源。请参见以下示例:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
     name: schedule-acm-msa
     namespace: open-cluster-management-backup
    spec:
     veleroSchedule: 0 */1 * * *
     veleroTtl: 120h
     useManagedServiceAccount: true
     paused: true
    Copy to Clipboard Toggle word wrap

    备注: - 如果您在继续下一步前,不要在主 hub 集群上暂停备份调度,您可以使用 import.open-cluster-management.io/disable-auto-import 注解设置,使用 import.open-cluster-management.io/disable-auto-import 注解设置备份调度,使用 import.open-cluster-management.io/disable-auto-import 注解设置。

    • 如果您使用 import.open-cluster-management.io/disable-auto-import 注解备份 ManagedCluster 资源,则受管集群在新的 hub 集群上恢复备份数据时,受管集群将无法自动导入。
  2. 使用备份注解标记主 hub 集群资源。完成以下步骤:

    1. 创建名为 restore-acm.yaml 的文件。
    2. 在文件中添加以下内容:

      apiVersion: cluster.open-cluster-management.io/v1beta1
      kind: Restore
      metadata:
       name: restore-acm
       namespace: open-cluster-management-backup
      spec:
       cleanupBeforeRestore: None
       veleroManagedClustersBackupName: latest
       veleroCredentialsBackupName: latest
       veleroResourcesBackupName: latest
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令应用该文件并运行恢复操作:

      oc -f apply restore-acm.yaml
      Copy to Clipboard Toggle word wrap

      注: 运行 Restore 资源时,如果启用了 BackupSchedule,则会标记要备份的所有 hub 集群资源。资源使用 velero.io/backup-name: backupName 标签标记,其中 backupName 是主 hub 集群创建的最新备份的名称。

      因此,任何在主集群中运行的恢复操作通过使用 Restore 资源,将 cleanupBeforeRestore d 设置为 CleanupRestored 处理这些资源,如果它们不是最新的备份的一部分,则删除这些资源。

  3. 为受管集群禁用自动导入。

    1. ManagedCluster global 资源中为您要移至恢复 hub 集群的所有受管集群设置以下注解。通过设置注解,您可以防止备份 hub 集群在受管集群移至恢复 hub 集群后恢复任何受管集群:
    annotations:
       import.open-cluster-management.io/disable-auto-import: ''
    Copy to Clipboard Toggle word wrap

1.1.8.2. 在新 hub 集群中运行恢复操作

准备主 hub 集群后,在新 hub 集群上运行恢复操作并移动受管集群。受管集群连接到新的 hub 集群,且不会返回到初始 hub 集群,因为备份 hub 集群上现在禁用了自动导入功能。

通过完成以下步骤,在新的 hub 集群中运行恢复操作:

  1. 将以下内容添加到 restore-acm.yaml 文件:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
     name: restore-acm
     namespace: open-cluster-management-backup
    spec:
     cleanupBeforeRestore: None
     veleroManagedClustersBackupName: latest
     veleroCredentialsBackupName: latest
     veleroResourcesBackupName: latest
    Copy to Clipboard Toggle word wrap

    注:veleroManagedClustersBackupName 设置为 最新 恢复受管集群并将其与二级 hub 集群连接。

  2. 运行以下命令应用该文件并运行恢复操作:

    oc -f apply restore-acm.yaml
    Copy to Clipboard Toggle word wrap

1.1.8.3. 清理备份 hub 集群中的受管集群资源

在恢复并成功连接到新的 hub 集群后,从初始备份 hub 集群中清理受管集群资源。如果要在恢复测试完成后将数据恢复到备份,请跳过清理资源

要从备份 hub 集群清理受管集群,请完成以下步骤:

  1. 在删除 ManagedCluster 全局资源前,请确保主 hub 上的受管集群状态为 Unknown。如果状态不是 Unknown,则您的工作负载将从受管集群卸载。
  2. 决定您要删除 ManagedCluster 全局资源。这样做会删除受管集群命名空间。
  3. 使用恢复操作,从备份 hub 集群中删除您移至新 hub 集群的受管集群的 ManagedCluster 全局资源。

重要:

  • 在删除 ManagedCluster 全局资源前,请确保主 hub 上的受管集群状态为 Unknown。如果状态不是 Unknown,则您的工作负载将从受管集群卸载。
  • 删除 ManagedCluster 全局资源也会删除受管集群命名空间。

1.1.9. 备份和恢复高级配置

您可以通过查看以下部分来进一步配置备份和恢复:

1.1.9.1. 资源请求和限值自定义

最初安装 Velero 时,Velero pod 会被设置为默认 CPU 和内存限值,如下例所示:

resources:
 limits:
   cpu: "1"
   memory: 256Mi
 requests:
   cpu: 500m
   memory: 128Mi
Copy to Clipboard Toggle word wrap

以上示例中的限制在某些情况下可以正常工作,但可能会在集群备份大量资源时进行更新。例如,当备份在管理 2000 集群的 hub 集群上运行时,Velero pod 会因为内存不足错误(OOM)崩溃。对于这种情况,以下配置允许备份完成:

  limits:
    cpu: "2"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi
Copy to Clipboard Toggle word wrap

要更新 Velero pod 资源的限制和请求,您需要更新 DataProtectionApplication 资源,并为 Velero pod 插入 resourceAllocation 模板。查看以下示例:

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero
  namespace: open-cluster-management-backup
spec:
...
  configuration:
...
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "2"
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 256Mi
Copy to Clipboard Toggle word wrap

1.1.9.2. 其他资源

  • 请参阅 Red Hat OpenShift Container Platform 文档中的 Default Velero 云供应商插件 主题,以了解更多有关 DataProtectionApplication 参数的信息。
  • 如需有关集群使用情况 备份和恢复 CPU 和内存要求的更多详情,请参阅 OpenShift Container Platform 文档中的配置主题的 CPU 和内存要求。

如果您使用现有 hub 集群作为在恢复操作之前创建的资源的恢复 hub 集群,请考虑以下情况:

  • 现有受管集群可能会在恢复过程中分离。
  • 恢复 hub 集群上可能会有比备份 hub 集群更多的资源。

如果您计划用于恢复操作的 hub 集群已管理集群,并且运行 restore 操作,并将 cleanupBeforeRestore d 设置为 CleanupRestored,则预期以下结果:

  • 如果 ManagedCluster 资源由恢复的备份创建,则资源会设置 velero.io/backup-name: backupName 标签注解。如果用户运行恢复操作并使用 cleanupBeforeRestore=CleanupRestored 选项,受管集群将从 hub 集群分离,并在这些受管集群中清理工作负载。
  • 如果用户创建了 ManagedCluster 资源,则资源没有设置 velero.io/backup-name: backupName 标签注解。如果您运行恢复操作并使用 cleanupBeforeRestore=CleanupRestored 选项,则不会清理受管集群资源,即使资源不是当前恢复的备份的一部分。

当您在包含用户创建的数据的 hub 集群上恢复数据时,为恢复操作将 cleanupBeforeRestore d 设置为 CleanupRestored,则不会清理这些数据。这是因为数据由用户创建,而不是由早期恢复。

即使用户创建的资源没有清理,您仍可使用现有的 hub 集群进行恢复 hub 集群配置。您可以在备份和恢复 hub 集群中使内容相互匹配。使用 cluster.open-cluster-management.io/backup 标签标记资源,使所有用户创建的资源都相同,就像它们是由早期恢复操作生成的一样。

要了解如何标记资源,请使用 backup 标签完成标记用户资源 以了解更多信息。

1.1.11. 使用备份标签标记用户资源

当您将现有 hub 集群用于恢复 hub 集群配置时,决定您要包含在 hub 集群中的用户创建的资源,然后使用 velero.io/backup-name: backupName 标签标记该资源。如果您使用 Velero 注解标记这些资源,它类似于之前恢复生成的资源。

由于 Velero 注解,当运行 hub restore 操作并将 cleanupBeforeRestore d 设置为 restore 资源上的 CleanupRestored 时,不属于当前恢复的备份的用户资源会被清理。因此,您可以在现有集群中恢复 hub 数据,并生成与初始 hub 相同的集群。

1.1.11.1. 先决条件

  • 查看将现有 hub 集群用作在恢复操作前创建的资源的恢复 hub 集群的场景。使用现有 hub 集群作为恢复 hub 集群时,请参阅场景
  • 在恢复 hub 集群中,更新 DataProtectionApplication 资源,并将存储位置设置为一个新的临时位置。您不想创建备份,用于在与备份 hub 集群相同的存储位置标记恢复 hub 集群资源。
  • 在标记资源前,请确保将存储位置设置为与备份 hub 集群不同的位置。

1.1.11.2. 使用 velero 标签标记资源

要使用 velero.io/backup-name: backupName 标签在恢复 hub 集群上标记用户创建的资源,请完成以下步骤:

  1. 使用以下 YAML 创建 BackupSchedule 资源来生成包含所有 hub 集群资源的备份:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
      name: schedule-acm-msa
      namespace: open-cluster-management-backup
    spec:
      veleroSchedule: 0 */1 * * *
      veleroTtl: 120h
      useManagedServiceAccount: true
      paused: false
    Copy to Clipboard Toggle word wrap
  2. 验证 BackupSchedule 创建了 hub 集群备份资源,且资源状态为 Completed
  3. 通过在 schedule-acm-msa BackupSchedule 上设置属性 paused=true 来暂停 BackupSchedule 调度并停止生成备份。

    注: 如果启用了 BackupSchedule,则无法在 hub 集群上运行恢复操作。

  4. 使用以下 YAML 运行恢复操作:

    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      cleanupBeforeRestore: None
      veleroManagedClustersBackupName: latest
      veleroCredentialsBackupName: latest
      veleroResourcesBackupName: latest
      excludedResources: 
    1
    
        - ManagedCluster
      excludedNamespaces: 
    2
    
        - managed-cls-1
        - managed-cls-2
        - managed-cls-n
    Copy to Clipboard Toggle word wrap
    1
    要排除的资源。在本例中,受管集群资源会被排除。
    2
    要排除的命名空间。在本例中,受管集群命名空间会被排除。

Operator 会通过作为 hub 集群备份一部分的每个资源,并使用 velero.io/backup-name: backupName 标记,其中 backupName 是最新备份的名称。

标记资源后,您可以使用 hub 集群作为恢复集群。现在,您可以通过更新 DataProtectionApplication 存储位置来指向备份 hub 集群的存储位置,以便您可以运行使用 hub 集群备份资源的恢复操作,从主 hub 集群恢复数据。

所有恢复 hub 集群资源都使用 velero.io/backup-name 标签标记,因此 hub 集群会显示早期恢复生成的。因此,在使用 cleanupBeforeRestore 选项设置为 CleanupRestored 时,您在现有 hub 集群上运行的恢复操作都会清理不是恢复的备份一部分的数据。

重要:

  • 如果您在恢复 hub 集群上有一个没有恢复备份一部分的恢复操作创建的受管集群,请不要使用 cleanupBeforeRestore 选项的恢复操作,将 cleanupBeforeRestore d 设置为 CleanupRestored。否则,恢复 hub 集群上的受管集群会从 hub 集群分离,受管集群资源会被删除。
  • 当恢复 hub 集群中数量超过备份 hub 集群时,您可以在以下情况下使用现有 hub 集群作为恢复 hub 集群:

    • 此恢复 hub 集群上没有受管集群。
    • 恢复 hub 集群上有受管集群,您不需要恢复的 hub 集群用户数据与恢复的备份的可用数据相同。
    • 来自恢复 hub 集群的受管集群的名称与备份 hub 集群中的任何受管集群名称都不冲突。

1.1.12. 将数据恢复到初始 hub 集群

运行 hub 集群灾难恢复模拟后,您可以将数据恢复到初始 hub 集群,然后将其用作主 hub 集群。

当您进行灾难恢复操作测试时,您可以模拟主 hub 集群失败,并将其数据恢复到新的 hub 集群,验证您的备份和恢复过程是否正常工作。在灾难恢复测试模拟完成后,返回到主 hub 集群,并使它成为管理集群机的活动 hub 集群。

完成以下部分,在运行灾难恢复模拟后将您的数据恢复到初始 hub 集群。

1.1.12.1. 准备主 hub 集群

要准备主 hub 集群在恢复过程期间保持活动状态,请完成以下任务,在主 hub 集群处于活跃状态时运行恢复操作

1.1.12.2. 先决条件

要为恢复操作准备备份 hub 集群并运行恢复,请完成以下文档: 在恢复过程中保持主 hub 集群处于活动状态

1.1.12.3. 将新 hub 集群设置为活跃 hub 集群

要开始模拟,您必须通过完成以下步骤使新的 hub 集群设置为活跃 hub 集群:

  1. 在新 hub 集群上运行恢复操作,使其活跃 hub 集群。
  2. 要验证受管集群现在是否已连接到新的 hub 集群,请从集群控制台检查受管集群的状态。
  3. 在新 hub 集群上运行灾难恢复模拟测试。

1.1.12.4. 返回到主 hub 集群

在灾难恢复测试完成后,完成以下步骤以返回到主 hub 集群,并使其成为管理集群机的活跃 hub 集群。

  1. 通过应用以下资源,在恢复 hub 集群中创建备份:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
     name: schedule-acm-msa
     namespace: open-cluster-management-backup
    spec:
     veleroSchedule: "0 */1 * * *"
     veleroTtl: 120h
     useManagedServiceAccount: true
     paused: false
    Copy to Clipboard Toggle word wrap
  2. 确保生成 Red Hat Advanced Cluster Management 备份并具有 Completed 状态。
  3. 通过在 schedule-acm-msa BackupSchedule 资源上设置 paused=true 属性来暂停备份调度。
  4. 要确保 ManagedCluster 资源在移至主 hub 集群后不会重新连接到初始 hub 集群,请将 import.open-cluster-management.io/disable-auto-import: '' 注解添加到所有 ManagedCluster 资源。
  5. 通过应用以下恢复资源从二级 hub 集群备份中恢复所有资源:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
     name: restore-acm
     namespace: open-cluster-management-backup
    spec:
     cleanupBeforeRestore: CleanupRestored
     veleroManagedClustersBackupName: latest
     veleroCredentialsBackupName: latest
     veleroResourcesBackupName: latest
    Copy to Clipboard Toggle word wrap

    注: 当您将 cleanupBeforeRestore 属性设置为 CleanupRestored 时,会在所有资源恢复后运行清理操作。此清理操作会删除不是恢复备份一部分的 hub 资源。

1.1.12.5. 在主 hub 集群上启用备份调度

现在,初始 hub 集群再次是主 hub 集群,通过完成以下步骤在主 hub 集群上启用备份调度:

  1. 进入主 hub 集群。
  2. 应用以下 BackupSchedule 资源:

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
     name: schedule-acm-msa
     namespace: open-cluster-management-backup
    spec:
     veleroSchedule: "0 */1 * * *"
     veleroTtl: 120h
     useManagedServiceAccount: true
     paused: false
    Copy to Clipboard Toggle word wrap

    注: 第二个 hub 集群可以 在主动 - 被动配置中 再次用作二级 hub 集群。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat