11.7. 업그레이드하기 전에 클러스터 리소스의 백업 생성
단일 노드 OpenShift의 경우 TALM(토폴로지 Aware Lifecycle Manager)은 업그레이드하기 전에 배포 백업을 생성할 수 있습니다. 업그레이드에 실패하면 이전 버전을 복구하고 애플리케이션을 다시 프로비저닝하지 않고도 클러스터를 작동 상태로 복원할 수 있습니다.
백업 기능을 사용하려면 먼저 backup 필드가 true 로 설정된 ClusterGroupUpgrade CR을 생성합니다. 백업 내용이 최신 상태인지 확인하기 위해 ClusterGroupUpgrade CR의 enable 필드를 true 로 설정할 때까지 백업이 수행되지 않습니다.
TALM은 BackupSucceeded 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.
true모든 클러스터 또는 백업 실행이 완료되었지만 하나 이상의 클러스터에 대해 백업이 완료되었습니다. 클러스터에 대한 백업이 실패하면 해당 클러스터를 업데이트하지 않습니다.
false하나 이상의 클러스터에 대한 백업이 진행 중이거나 모든 클러스터에 실패했습니다. spoke 클러스터에서 실행되는 백업 프로세스는 다음과 같은 상태를 가질 수 있습니다.
PreparingToStart첫 번째 조정 단계는 진행 중입니다. TALM은 업그레이드 실패 시 생성된 모든 spoke 백업 네임스페이스 및 허브 뷰 리소스를 삭제합니다.
Starting백업 사전 요구 사항 및 백업 작업이 생성 중입니다.
활성 상태백업이 진행 중입니다.
succeeded백업에 성공했습니다.
BackupTimeout아티팩트 백업은 부분적으로 수행됩니다.
UnrecoverableError백업이 0이 아닌 종료 코드로 종료되었습니다.
클러스터 백업에 실패하고 BackupTimeout 또는 UnrecoverableError 상태를 입력하면 클러스터 업데이트가 해당 클러스터를 진행하지 않습니다. 다른 클러스터의 업데이트는 영향을 받지 않으며 계속됩니다.
11.7.1. 백업을 사용하여 ClusterGroupUpgrade CR 생성
단일 노드 OpenShift 클러스터에서 업그레이드하기 전에 배포 백업을 생성할 수 있습니다. 업그레이드에 실패하면 Topology Aware Lifecycle Manager(TALM)에서 생성한 upgrade-recovery.sh 스크립트를 사용하여 시스템을 사전 업그레이드 상태로 되돌릴 수 있습니다. 백업은 다음 항목으로 구성됩니다.
- 클러스터 백업
-
etcd및 정적 pod 매니페스트의 스냅샷입니다. - 콘텐츠 백업
-
폴더의 백업(예:
/etc,/usr/local,/var/lib/kubelet). - 변경된 파일 백업
-
변경된
machine-config에서 관리하는 모든 파일입니다. - Deployment
-
고정된
ostree배포입니다. - 이미지(선택 사항)
- 사용 중인 컨테이너 이미지입니다.
사전 요구 사항
- TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
- 하나 이상의 관리 클러스터를 프로비저닝합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - RHACM(Red Hat Advanced Cluster Management)을 설치합니다.
복구 파티션을 만드는 것이 좋습니다. 다음은 50GB의 복구 파티션에 대한 SiteConfig CR(사용자 정의 리소스)의 예입니다.
nodes:
- hostName: "node-1.example.com"
role: "master"
rootDeviceHints:
hctl: "0:2:0:0"
deviceName: /dev/disk/by-id/scsi-3600508b400105e210000900000490000
...
#Disk /dev/disk/by-id/scsi-3600508b400105e210000900000490000:
#893.3 GiB, 959119884288 bytes, 1873281024 sectors
diskPartition:
- device: /dev/disk/by-id/scsi-3600508b400105e210000900000490000
partitions:
- mount_point: /var/recovery
size: 51200
start: 800000프로세스
clustergroupupgrades-group-du.yaml파일에서backup및enable필드를true로 설정하여ClusterGroupUpgradeCR의 내용을 저장합니다.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: true managedPolicies: - du-upgrade-platform-upgrade remediationStrategy: maxConcurrency: 2 timeout: 240업데이트를 시작하려면 다음 명령을 실행하여
ClusterGroupUpgradeCR을 적용합니다.$ 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": "Failed" 1 } }, "computedMaxConcurrency": 1, "conditions": [ { "lastTransitionTime": "2022-04-05T10:37:19Z", "message": "Backup failed for 1 cluster", 2 "reason": "PartiallyDone", 3 "status": "True", 4 "type": "Succeeded" } ], "precaching": { "spec": {} }, "status": {}
11.7.2. 업그레이드 실패 후 클러스터 복구
클러스터 업그레이드가 실패하면 클러스터에 수동으로 로그인하고 백업을 사용하여 클러스터를 업그레이드 전 상태로 되돌릴 수 있습니다. 두 단계가 있습니다.
- rollback
- 시도한 업그레이드에 플랫폼 OS 배포 변경 사항이 포함된 경우 복구 스크립트를 실행하기 전에 이전 버전으로 롤백해야 합니다.
롤백은 TALM 및 단일 노드 OpenShift에서 업그레이드하는 경우에만 사용할 수 있습니다. 이 프로세스는 다른 업그레이드 유형의 롤백에는 적용되지 않습니다.
- 복구
- 복구는 컨테이너를 종료하고 백업 파티션의 파일을 사용하여 컨테이너를 다시 시작하고 클러스터를 복원합니다.
사전 요구 사항
- TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
- 하나 이상의 관리 클러스터를 프로비저닝합니다.
- RHACM(Red Hat Advanced Cluster Management)을 설치합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - 백업용으로 구성된 업그레이드를 실행합니다.
프로세스
다음 명령을 실행하여 이전에 생성한
ClusterGroupUpgradeCR(사용자 정의 리소스)을 삭제합니다.$ oc delete cgu/du-upgrade-4918 -n ztp-group-du-sno
- 복구할 클러스터에 로그인합니다.
다음 명령을 실행하여 플랫폼 OS 배포의 상태를 확인합니다.
$ 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
- 현재 배포가 고정되어 있습니다. 플랫폼 OS 배포 롤백은 필요하지 않습니다.
[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플랫폼 OS 배포의 롤백을 트리거하려면 다음 명령을 실행합니다.
$ 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.4.15.23 True False 86d Cluster version is 4.4.15.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.4.15.23 True False False 2d7h 3 clusteroperator.config.openshift.io/baremetal 4.4.15.23 True False False 86d ..............
