18.7. 업그레이드하기 전에 클러스터 리소스의 백업 생성
단일 노드 OpenShift의 경우 TALM(토폴로지 라이프사이클 관리자)는 업그레이드하기 전에 배포 백업을 생성할 수 있습니다. 업그레이드에 실패하면 애플리케이션을 재프로비저닝하지 않고도 이전 버전을 복구하고 클러스터를 작동 상태로 복원할 수 있습니다.
ClusterGroupUpgrade CR에서 backup 필드가 true 로 설정된 경우 컨테이너 이미지 백업이 시작됩니다.
백업 프로세스는 다음 상태에 있을 수 있습니다.
BackupStatePreparingToStart- 첫 번째 조정 통과가 진행 중입니다. TALM은 실패한 업그레이드 시도에서 생성된 모든 설명된 백업 네임스페이스 및 허브 뷰 리소스를 삭제합니다.
BackupStateStarting- 백업 사전 요구 사항 및 백업 작업이 생성됩니다.
BackupStateActive- 백업이 진행 중입니다.
BackupStateSucceeded- 백업이 성공했습니다.
BackupStateTimeout- 아티팩트 백업이 부분적으로 수행되었습니다.
BackupStateError- 백업이 0이 아닌 종료 코드로 종료되었습니다.
백업에 실패하고 BackupStateTimeout 또는 BackupStateError 상태를 입력하면 클러스터 업그레이드가 진행되지 않습니다.
18.7.1. 백업을 사용하여 ClusterGroupUpgrade CR 생성
단일 노드 OpenShift의 경우 업그레이드 전에 배포 백업을 생성할 수 있습니다. 업그레이드에 실패하면 Topology Aware Lifecycle Manager (TALM)에서 생성한 upgrade-recovery.sh 스크립트를 사용하여 시스템을 사전 업그레이드 상태로 되돌릴 수 있습니다. 백업은 다음 항목으로 구성됩니다.
- 클러스터 백업
-
etcd및 정적 포드 매니페스트의 스냅샷입니다. - 콘텐츠 백업
-
폴더 백업(예:
/etc,/usr/local,/var/lib/kubelet) - 변경된 파일 백업
-
변경된
machine-config에서 관리하는 모든 파일 - 배포
-
고정된
ostree배포. - 이미지 (선택 사항)
- 사용 중인 모든 컨테이너 이미지입니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- 하나 이상의 관리 클러스터를 프로비저닝합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - RHACM(Red Hat Advanced Cluster Management)을 설치합니다.
복구 파티션을 만드는 것이 좋습니다. 다음은 50GB의 복구 파티션에 대한 SiteConfig CR(사용자 정의 리소스)의 예입니다.
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파일에서backup필드가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: false 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": "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
- 시도한 업그레이드에 플랫폼 OS 배포로 변경 사항이 포함된 경우 복구 스크립트를 실행하기 전에 이전 버전으로 롤백해야 합니다.
롤백은 TALM 및 단일 노드 OpenShift에서의 업그레이드에만 적용됩니다. 이 프로세스는 다른 업그레이드 유형의 롤백에는 적용되지 않습니다.
- 복구
- 복구 시 컨테이너가 종료되고 백업 파티션의 파일을 사용하여 컨테이너를 다시 시작하고 클러스터를 복원합니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- 하나 이상의 관리 클러스터를 프로비저닝합니다.
- RHACM(Red Hat Advanced Cluster Management)을 설치합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - 백업용으로 구성된 업그레이드를 실행합니다.
절차
다음 명령을 실행하여 이전에 생성한
ClusterGroupUpgrade사용자 정의 리소스(CR)를 삭제합니다.$ oc delete cgu/du-upgrade-4918 -n ztp-group-du-sno
- 복구하려는 클러스터에 로그인합니다.
다음 명령을 실행하여 플랫폼 OS 배포의 상태를 확인합니다.
$ 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
- 현재 배포가 고정되어 있습니다. 플랫폼 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.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 ..............
