18.7. 在升级前创建集群资源备份

对于单节点 OpenShift，Topology Aware Lifecycle Manager (TALM) 可以在升级前创建部署备份。如果升级失败，您可以恢复之前的版本并将集群恢复到工作状态，而无需重新置备应用程序。

当 ClusterGroupUpgrade CR 中将 backup 字段设置为 true 时，容器镜像备份将开始。

备份过程可能处于以下状态：

BackupStatePreparingToStart: 第一个协调通过正在进行。TALM 删除所有 spoke 备份命名空间和 hub 查看在升级尝试中创建的资源。
BackupStateStarting: 正在创建备份先决条件和备份作业。
BackupStateActive: 备份正在进行。
BackupStateSucceeded: 备份已成功。
BackupStateTimeout: 工件备份部分完成。
BackupStateError: 备份以非零退出代码结尾。

注意

如果备份失败，并进入 BackupStateTimeout 或 BackupStateError 状态，集群升级不会进行。

18.7.1. 使用备份创建 ClusterGroupUpgrade CR

对于单节点 OpenShift，您可以在升级前创建部署的备份。如果升级失败，您可以使用 Topology Aware Lifecycle Manager (TALM) 生成的 upgrade-recovery.sh 脚本将系统返回到其 preupgrade 状态。备份由以下项目组成：

集群备份: etcd 和静态 pod 清单的快照。
内容备份: 文件夹备份，例如 /etc、/usr/local、/var/lib/kubelet。
已更改的文件备份: 由 machine-config 管理的任何文件都已更改。
Deployment: 固定 ostree 部署。
镜像（可选）: 使用的任何容器镜像。

先决条件

安装 Topology Aware Lifecycle Manager(TALM)。
置备一个或多个受管集群。
以具有 cluster-admin 特权的用户身份登录。
安装 Red Hat Advanced Cluster Management (RHACM)。

注意

强烈建议您创建一个恢复分区。以下是一个恢复分区的 SiteConfig 自定义资源 (CR) 示例，大小为 50 GB：

nodes:
    - hostName: "snonode.sno-worker-0.e2e.bos.redhat.com"
    role: "master"
    rootDeviceHints:
        hctl: "0:2:0:0"
        deviceName: /dev/sda
........
........
    #Disk /dev/sda: 893.3 GiB, 959119884288 bytes, 1873281024 sectors
    diskPartition:
        - device: /dev/sda
        partitions:
        - mount_point: /var/recovery
            size: 51200
            start: 800000

流程

在 clustergroupupgrades-group-du.yaml 文件中，保存 ClusterGroupUpgrade CR 的内容，其中 backup 字段被设置为 true：

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: du-upgrade-4918
  namespace: ztp-group-du-sno
spec:
  preCaching: true
  backup: true
  clusters:
  - cnfdb1
  - cnfdb2
  enable: false
  managedPolicies:
  - du-upgrade-platform-upgrade
  remediationStrategy:
    maxConcurrency: 2
    timeout: 240

要启动更新，请运行以下命令来应用 ClusterGroupUpgrade CR：
```
$ oc apply -f clustergroupupgrades-group-du.yaml
```

验证

运行以下命令，检查 hub 集群中的升级状态：

$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

输出示例

{
    "backup": {
        "clusters": [
            "cnfdb2",
            "cnfdb1"
    ],
    "status": {
        "cnfdb1": "Succeeded",
        "cnfdb2": "Succeeded"
    }
},
"computedMaxConcurrency": 1,
"conditions": [
    {
        "lastTransitionTime": "2022-04-05T10:37:19Z",
        "message": "Backup is completed",
        "reason": "BackupCompleted",
        "status": "True",
        "type": "BackupDone"
    }
],
"precaching": {
    "spec": {}
},
"status": {}

18.7.2. 在升级后恢复集群

如果集群的升级失败，您可以手动登录到集群，并使用备份使集群返回到其升级前的状态。有两个阶段：

回滚（Rollback）: 如果尝试升级包括对平台操作系统部署的更改，则必须在运行恢复脚本前回滚到以前的版本。

重要

回滚仅适用于从 TALM 和单节点 OpenShift 升级。这个过程不适用于从任何其他升级类型进行回滚。

恢复: 恢复会关闭容器，并使用备份分区中的文件来重新启动容器并恢复集群。

先决条件

安装 Topology Aware Lifecycle Manager(TALM)。
置备一个或多个受管集群。
安装 Red Hat Advanced Cluster Management (RHACM)。
以具有 cluster-admin 特权的用户身份登录。
运行为备份而配置的升级。

流程

运行以下命令来删除之前创建的 ClusterGroupUpgrade 自定义资源 (CR)：
```
$ oc delete cgu/du-upgrade-4918 -n ztp-group-du-sno
```
登录到要恢复的集群。

运行以下命令，检查平台操作系统部署的状态：

$ oc ostree admin status

输出示例

[root@lab-test-spoke2-node-0 core]# ostree admin status
* rhcos c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9.0
    Version: 49.84.202202230006-0
    Pinned: yes 1
    origin refspec: c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9

1: 当前部署已被固定。不需要平台操作系统部署回滚。

[root@lab-test-spoke2-node-0 core]# ostree admin status
* rhcos f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa.0
    Version: 410.84.202204050541-0
    origin refspec: f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa
rhcos ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52ca.0 (rollback) 1
    Version: 410.84.202203290245-0
    Pinned: yes 2
    origin refspec: ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52ca

1: 此平台操作系统部署标记为回滚。
2: 以前的部署已被固定，可以回滚。

要触发平台操作系统部署的回滚，请运行以下命令：
```
$ rpm-ostree rollback -r
```
恢复的第一阶段会关闭容器，并将文件从备份分区恢复到目标目录。要开始恢复，请运行以下命令：
```
$ /var/recovery/upgrade-recovery.sh
```
提示时，运行以下命令重启集群：
```
$ systemctl reboot
```
重新引导后，运行以下命令重启恢复：
```
$ /var/recovery/upgrade-recovery.sh  --resume
```

注意

如果恢复工具失败，您可以使用 --restart 选项重试：

$ /var/recovery/upgrade-recovery.sh --restart

验证

运行以下命令检查恢复的状态：

$ oc get clusterversion,nodes,clusteroperator

输出示例

NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.9.23    True        False         86d     Cluster version is 4.9.23 1


NAME                          STATUS   ROLES           AGE   VERSION
node/lab-test-spoke1-node-0   Ready    master,worker   86d   v1.22.3+b93fd35 2

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/authentication                             4.9.23    True        False         False      2d7h    3
clusteroperator.config.openshift.io/baremetal                                  4.9.23    True        False         False      86d


..............

1: 集群版本可用，并具有正确的版本。
2: 节点状态为 Ready。
3: ClusterOperator 对象的可用性为 True。

18.7. 在升级前创建集群资源备份

18.7.1. 使用备份创建 ClusterGroupUpgrade CR

18.7.2. 在升级后恢复集群

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links