백업 및 복원
OpenShift Container Platform 클러스터 백업 및 복원
초록
1장. 백업 및 복원
1.1. 컨트롤 플레인 백업 및 복원 작업
클러스터 관리자는 일정 기간 동안 OpenShift Container Platform 클러스터를 중지한 후 나중에 다시 시작해야 할 수 있습니다. 클러스터를 다시 시작하는 몇 가지 이유는 클러스터에서 유지 관리를 수행하거나 리소스 비용을 줄이기를 원하기 때문입니다. OpenShift Container Platform에서는 나중에 클러스터를 쉽게 다시 시작할 수 있도록 클러스터의 정상 종료 를 수행할 수 있습니다.
클러스터를 종료하기 전에 etcd 데이터를 백업해야 합니다. etcd는 모든 리소스 오브젝트의 상태를 유지하는 OpenShift Container Platform의 키-값 저장소입니다. etcd 백업은 재해 복구에서 중요한 역할을 합니다. OpenShift Container Platform에서는 비정상적인 etcd 멤버를 교체할 수도 있습니다.
클러스터를 다시 실행하려면 클러스터를 정상적으로 다시 시작합니다.
클러스터 인증서는 설치 날짜로부터 1년 후에 만료됩니다. 인증서가 유효한 상태에서 클러스터를 종료하고 정상적으로 다시 시작할 수 있습니다. 클러스터가 만료된 컨트롤 플레인 인증서를 자동으로 검색하지만 CSR(인증서 서명 요청)을 계속 승인해야 합니다.
다음과 같이 OpenShift Container Platform이 예상대로 작동하지 않는 여러 가지 상황이 발생할 수 있습니다.
- 노드 오류 또는 네트워크 연결 문제와 같은 예기치 않은 조건으로 인해 재시작 후 작동하지 않는 클러스터가 있습니다.
- 클러스터에서 중요한 것을 실수로 삭제했습니다.
- 대부분의 컨트롤 플레인 호스트가 손실되어 etcd 쿼럼이 손실됩니다.
저장된 etcd 스냅샷을 사용하여 클러스터를 이전 상태로 복원하여 재해 상황에서 항상 복구할 수 있습니다.
추가 리소스
1.2. 애플리케이션 백업 및 복원 작업
클러스터 관리자는 OADP(OpenShift API for Data Protection)를 사용하여 OpenShift Container Platform에서 실행되는 애플리케이션을 백업하고 복원할 수 있습니다.
OADP는 Velero CLI 툴 다운로드 의 표에 따라 설치하는 OADP 버전에 적합한 Velero 버전을 사용하여 네임스페이스 단위로 Kubernetes 리소스 및 내부 이미지를 백업하고 복원합니다. OADP는 스냅샷 또는 Restic을 사용하여 PV(영구 볼륨)를 백업 및 복원합니다. 자세한 내용은 OADP 기능을 참조하십시오.
1.2.1. OADP 요구 사항
OADP에는 다음과 같은 요구 사항이 있습니다.
-
cluster-admin
역할의 사용자로 로그인해야 합니다. 다음 스토리지 유형 중 하나와 같은 백업을 저장하기 위한 오브젝트 스토리지가 있어야 합니다.
- OpenShift Data Foundation
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- S3 호환 오브젝트 스토리지
OCP 4.11 이상에서 CSI 백업을 사용하려면 OADP 1.1.x 를 설치하십시오.
OADP 1.0.x 는 OCP 4.11 이상에서 CSI 백업을 지원하지 않습니다. OADP 1.0.x 에는 Velero 1.7이 포함되어 있으며 OCP 4.11 이상에는 존재하지 않는 API 그룹 snapshot.storage.k8s.io/v1beta1
이 예상됩니다.
S3 스토리지의 CloudStorage
API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
스냅샷을 사용하여 PV를 백업하려면 다음 공급자와 같이 기본 스냅샷 API가 있거나 CSI(Container Storage Interface) 스냅샷을 지원하는 클라우드 스토리지가 있어야 합니다.
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- CSI 스냅샷 지원 클라우드 스토리지(예: Ceph RBD 또는 Ceph FS)
스냅샷을 사용하여 PV를 백업하지 않으려면 기본적으로 OADP Operator에서 설치하는 Restic 을 사용할 수 있습니다.
1.2.2. 애플리케이션 백업 및 복원
Backup
CR(사용자 정의 리소스)을 생성하여 애플리케이션을 백업합니다. Backup CR 생성을 참조하십시오. 다음 백업 옵션을 구성할 수 있습니다.
- 백업 작업 전후에 명령을 실행할 백업 후크 생성
- 백업 예약
- 파일 시스템 백업을 사용하여 애플리케이션 백업: Kopia 또는 Restic
-
복원(CR)을 생성하여 애플리케이션 백업을
복원합니다
. 복원 CR 생성을 참조하십시오. - 복원 작업 중에 init 컨테이너 또는 애플리케이션 컨테이너에서 명령을 실행하도록 복원 후크 를 구성할 수 있습니다.
2장. 클러스터를 안전하게 종료
이 문서에서는 클러스터를 안전하게 종료하는 프로세스를 설명합니다. 유지 관리를 위해 또는 리소스 비용을 절약하기 위해 일시적으로 클러스터를 종료해야 할 수 있습니다.
2.1. 전제 조건
클러스터를 종료하기 전에 etcd 백업을 수행합니다.
중요클러스터를 다시 시작할 때 문제가 발생할 경우 클러스터를 복원 할 수 있도록 이 단계를 수행하기 전에 etcd 백업을 해 두는 것이 중요합니다.
예를 들어 다음 조건으로 인해 재시작된 클러스터가 손상될 수 있습니다.
- 종료 중 etcd 데이터 손상
- 하드웨어로 인한 노드 오류
- 네트워크 연결 문제
클러스터를 복구하지 못하는 경우 이전 클러스터 상태로 복원 단계를 따르십시오.
2.2. 클러스터 종료
나중에 클러스터를 다시 시작하기 위해 안전한 방법으로 클러스터를 종료할 수 있습니다.
설치 날짜부터 1년까지 클러스터를 종료하고 정상적으로 다시 시작할 수 있습니다. 설치 날짜로부터 1년 후에는 클러스터 인증서가 만료됩니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있습니다. - etcd 백업이 수행되었습니다.
절차
연장된 기간 동안 클러스터를 종료하는 경우 인증서 만료 날짜를 확인하고 다음 명령을 실행합니다.
$ oc -n openshift-kube-apiserver-operator get secret kube-apiserver-to-kubelet-signer -o jsonpath='{.metadata.annotations.auth\.openshift\.io/certificate-not-after}'
출력 예
2022-08-05T14:37:50Zuser@user:~ $ 1
- 1
- 클러스터를 정상적으로 다시 시작할 수 있도록 지정된 날짜 또는 그 이전에 클러스터를 다시 시작하도록 계획합니다. 클러스터가 재시작되면 프로세스에서 kubelet 인증서를 복구하기 위해 보류 중인 인증서 서명 요청(CSR)을 수동으로 승인해야 할 수 있습니다.
클러스터의 모든 노드를 예약 불가로 표시합니다. 클라우드 공급자의 웹 콘솔에서 이 작업을 수행하거나 다음 반복문을 실행하여 수행할 수 있습니다.
$ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm cordon ${node} ; done
출력 예
ci-ln-mgdnf4b-72292-n547t-master-0 node/ci-ln-mgdnf4b-72292-n547t-master-0 cordoned ci-ln-mgdnf4b-72292-n547t-master-1 node/ci-ln-mgdnf4b-72292-n547t-master-1 cordoned ci-ln-mgdnf4b-72292-n547t-master-2 node/ci-ln-mgdnf4b-72292-n547t-master-2 cordoned ci-ln-mgdnf4b-72292-n547t-worker-a-s7ntl node/ci-ln-mgdnf4b-72292-n547t-worker-a-s7ntl cordoned ci-ln-mgdnf4b-72292-n547t-worker-b-cmc9k node/ci-ln-mgdnf4b-72292-n547t-worker-b-cmc9k cordoned ci-ln-mgdnf4b-72292-n547t-worker-c-vcmtn node/ci-ln-mgdnf4b-72292-n547t-worker-c-vcmtn cordoned
다음 방법을 사용하여 Pod를 비웁니다.
$ for node in $(oc get nodes -l node-role.kubernetes.io/worker -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm drain ${node} --delete-emptydir-data --ignore-daemonsets=true --timeout=15s --force ; done
클러스터의 모든 노드를 종료합니다. 클라우드 공급자 웹 콘솔의 웹 콘솔에서 또는 다음 반복문을 실행하여 이 작업을 수행할 수 있습니다. 이러한 방법 중 하나를 사용하여 노드를 종료하면 Pod가 정상적으로 종료되어 데이터 손상 가능성을 줄일 수 있습니다.
참고할당된 API VIP가 있는 컨트롤 플레인 노드가 루프에서 처리된 마지막 노드인지 확인합니다. 그렇지 않으면 shutdown 명령이 실패합니다.
$ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 1; done 1
- 1
-h 1
은 컨트롤 플레인 노드가 종료되기 전에 이 프로세스가 지속됩니다. 10개 이상의 노드가 있는 대규모 클러스터의 경우-h 10
이상으로 설정하여 모든 컴퓨팅 노드를 먼저 종료할 시간이 있는지 확인합니다.
출력 예
Starting pod/ip-10-0-130-169us-east-2computeinternal-debug ... To use host binaries, run `chroot /host` Shutdown scheduled for Mon 2021-09-13 09:36:17 UTC, use 'shutdown -c' to cancel. Removing debug pod ... Starting pod/ip-10-0-150-116us-east-2computeinternal-debug ... To use host binaries, run `chroot /host` Shutdown scheduled for Mon 2021-09-13 09:36:29 UTC, use 'shutdown -c' to cancel.
참고종료하기 전에 OpenShift Container Platform과 함께 제공되는 표준 Pod의 컨트롤 플레인 노드를 드레인할 필요가 없습니다. 클러스터 관리자는 클러스터를 다시 시작한 후 워크로드를 완전히 다시 시작해야 합니다. 사용자 지정 워크로드로 인해 종료하기 전에 컨트롤 플레인 노드를 드레 이한 경우 다시 시작한 후 클러스터가 다시 작동하기 전에 컨트롤 플레인 노드를 스케줄 대상으로 표시해야합니다.
외부 스토리지 또는 LDAP 서버와 같이 더 이상 필요하지 않은 클러스터 종속성을 중지합니다. 이 작업을 수행하기 전에 공급 업체의 설명서를 확인하십시오.
중요클러스터를 클라우드 공급자 플랫폼에 배포한 경우 관련 클라우드 리소스를 종료, 일시 중단 또는 삭제하지 마십시오. 일시 중지된 가상 머신의 클라우드 리소스를 삭제하면 OpenShift Container Platform이 성공적으로 복원되지 않을 수 있습니다.
2.3. 추가 리소스
3장. 클러스터를 정상적으로 다시 시작
이 문서에서는 정상 종료 후 클러스터를 다시 시작하는 프로세스에 대해 설명합니다.
다시 시작한 후 클러스터가 정상적으로 작동할 것으로 예상되지만 예상치 못한 상황으로 인해 클러스터가 복구되지 않을 수 있습니다. 예를 들면 다음과 같습니다.
- 종료 중 etcd 데이터 손상
- 하드웨어로 인한 노드 오류
- 네트워크 연결 문제
클러스터를 복구하지 못하는 경우 이전 클러스터 상태로 복원 단계를 따르십시오.
3.1. 전제 조건
3.2. 클러스터를 다시 시작
클러스터가 정상적으로 종료된 후 클러스터를 다시 시작할 수 있습니다.
전제 조건
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있습니다. - 이 프로세스에서는 클러스터를 정상적으로 종료하고 있는 것을 전제로 하고 있습니다.
프로세스
- 외부 스토리지 또는 LDAP 서버와 같은 클러스터의 종속 장치를 시작합니다.
모든 클러스터 시스템을 시작합니다.
클라우드 제공 업체의 웹 콘솔에서 시스템을 시작하는 것과 같이 클라우드 환경에 적합한 방법을 사용하여 시스템을 시작합니다.
약 10 분 정도 기다린 후 컨트롤 플레인 노드의 상태를 확인합니다.
모든 컨트롤 플레인 노드가 준비되었는지 확인합니다.
$ oc get nodes -l node-role.kubernetes.io/master
다음 출력에 표시된 대로 노드의 상태가
Ready
인 경우 컨트롤 플레인 노드는 준비된 것입니다.NAME STATUS ROLES AGE VERSION ip-10-0-168-251.ec2.internal Ready master 75m v1.26.0 ip-10-0-170-223.ec2.internal Ready master 75m v1.26.0 ip-10-0-211-16.ec2.internal Ready master 75m v1.26.0
컨트롤 플레인 노드가 준비되지 않은 경우 승인해야하는 보류중인 인증서 서명 요청(CSR)이 있는지 확인합니다.
현재 CSR의 목록을 가져옵니다.
$ oc get csr
CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.
$ oc describe csr <csr_name> 1
- 1
<csr_name>
은 현재 CSR 목록에 있는 CSR의 이름입니다.
각각의 유효한 CSR을 승인합니다.
$ oc adm certificate approve <csr_name>
컨트롤 플레인 노드가 준비되면 모든 작업자 노드가 준비되었는지 확인합니다.
$ oc get nodes -l node-role.kubernetes.io/worker
다음 출력에 표시된 대로 작업자 노드의 상태가
Ready
인 경우 작업자 노드는 준비된 것입니다.NAME STATUS ROLES AGE VERSION ip-10-0-179-95.ec2.internal Ready worker 64m v1.26.0 ip-10-0-182-134.ec2.internal Ready worker 64m v1.26.0 ip-10-0-250-100.ec2.internal Ready worker 64m v1.26.0
작업자 노드가 준비되지 않은 경우 승인해야하는 보류중인 인증서 서명 요청(CSR)이 있는지 확인합니다.
현재 CSR의 목록을 가져옵니다.
$ oc get csr
CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.
$ oc describe csr <csr_name> 1
- 1
<csr_name>
은 현재 CSR 목록에 있는 CSR의 이름입니다.
각각의 유효한 CSR을 승인합니다.
$ oc adm certificate approve <csr_name>
클러스터가 제대로 시작되었는지 확인합니다.
성능이 저하된 클러스터 Operator가 없는지 확인합니다.
$ oc get clusteroperators
DEGRADED
조건이True
로 설정된 클러스터 Operator가 없는지 확인합니다.NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.13.0 True False False 59m cloud-credential 4.13.0 True False False 85m cluster-autoscaler 4.13.0 True False False 73m config-operator 4.13.0 True False False 73m console 4.13.0 True False False 62m csi-snapshot-controller 4.13.0 True False False 66m dns 4.13.0 True False False 76m etcd 4.13.0 True False False 76m ...
모든 노드가
Ready
상태에 있는지 확인합니다.$ oc get nodes
모든 노드의 상태가
Ready
상태인지 확인합니다.NAME STATUS ROLES AGE VERSION ip-10-0-168-251.ec2.internal Ready master 82m v1.26.0 ip-10-0-170-223.ec2.internal Ready master 82m v1.26.0 ip-10-0-179-95.ec2.internal Ready worker 70m v1.26.0 ip-10-0-182-134.ec2.internal Ready worker 70m v1.26.0 ip-10-0-211-16.ec2.internal Ready master 82m v1.26.0 ip-10-0-250-100.ec2.internal Ready worker 69m v1.26.0
클러스터가 제대로 시작되지 않은 경우 etcd 백업을 사용하여 클러스터를 복원해야 할 수 있습니다.
컨트롤 플레인 및 작업자 노드가 준비되면 클러스터의 모든 노드를 예약 가능으로 표시합니다. 다음 명령을 실행합니다.
for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm uncordon ${node} ; done
추가 리소스
4장. OADP 애플리케이션 백업 및 복원
4.1. 데이터 보호를 위한 OpenShift API 소개
OADP(OpenShift API for Data Protection) 제품은 OpenShift Container Platform에서 고객 애플리케이션을 보호합니다. OpenShift Container Platform 애플리케이션, 애플리케이션 관련 클러스터 리소스, 영구 볼륨 및 내부 이미지를 다루는 포괄적인 재해 복구 보호 기능을 제공합니다. OADP는 컨테이너화된 애플리케이션과 VM(가상 머신)을 모두 백업할 수 있습니다.
그러나 OADP는 etcd 또는 {OCP-short} Operator의 재해 복구 솔루션 역할을 하지 않습니다.
OADP 지원은 고객 워크로드 네임스페이스 및 클러스터 범위 리소스에 제공됩니다.
4.1.1. OpenShift API for Data Protection API
OADP(OpenShift API for Data Protection)는 여러 가지 접근 방식을 통해 백업을 사용자 지정하고 불필요하거나 부적절한 리소스가 포함되지 않도록 하는 API를 제공합니다.
OADP는 다음 API를 제공합니다.
4.1.1.1. OpenShift API for Data Protection 지원
버전 | OCP 버전 | 정식 출시일 (GA) | 완전 지원 종료 | 유지 관리 종료 | Extended Update Support (EUS) | EUS (Extended Update Support Term 2) |
1.3 |
| 2023년 11월 29일 | 2024년 7월 10일 | 1.5 릴리스 | 2025년 10월 31일 EUS는 OCP 4.14에 있어야 합니다. | 2026년 10월 31일 EUS 용어 2는 OCP 4.14에 있어야 합니다. |
4.1.1.1.1. 지원되지 않는 OADP Operator 버전
버전 | 정식 출시일 (GA) | 완전 지원 종료 | 유지 관리 종료 |
1.2 | 2023년 6월 14일 | 2023년 11월 29일 | 2024년 7월 10일 |
1.1 | 2022년 9월 01일 | 2023년 6월 14일 | 2023년 11월 29일 |
1.0 | 2022년 2월 9일 | 2022년 9월 01일 | 2023년 6월 14일 |
EUS에 대한 자세한 내용은 확장 업데이트 지원을 참조하십시오.
EUS 용어 2에 대한 자세한 내용은 Extended Update Support Term 2 를 참조하십시오.
추가 리소스
4.2. OADP 릴리스 정보
4.2.1. OADP 1.3 릴리스 노트
OADP(OpenShift API for Data Protection) 1.3의 릴리스 노트는 새로운 기능 및 개선 사항, 더 이상 사용되지 않는 기능, 제품 권장 사항, 알려진 문제, 해결된 문제에 대해 설명합니다.
4.2.1.1. OADP 1.3.6 릴리스 노트
OADP(OpenShift API for Data Protection) 1.3.6은 컨테이너의 상태 등급을 새로 고치기 위해 릴리스되는 컨테이너 전용(CGO) 릴리스입니다. OADP 1.3.5에 비해 제품 자체의 코드가 변경되지 않았습니다.
4.2.1.2. OADP 1.3.5 릴리스 노트
OADP(OpenShift API for Data Protection) 1.3.5는 컨테이너의 상태 등급을 새로 고치기 위해 릴리스되는 컨테이너 전용(CGO) 릴리스입니다. 제품 자체에서 OADP 1.3.4에 비해 코드가 변경되지 않았습니다.
4.2.1.3. OADP 1.3.4 릴리스 노트
OADP(OpenShift API for Data Protection) 1.3.4 릴리스 노트에는 해결된 문제 및 알려진 문제가 나열됩니다.
4.2.1.3.1. 해결된 문제
backup spec.resourcepolicy.kind 매개변수가 대소문자를 구분하지 않음
이전에는 backup spec.resourcepolicy.kind
매개변수가 하위 수준 문자열에서만 지원되었습니다. 이번 수정으로 이제 대소문자를 구분하지 않습니다. OADP-2944
olm.maxOpenShiftVersion을 사용하여 OCP 4.16 버전으로 클러스터를 업그레이드하지 마십시오.
클러스터 operator-lifecycle-manager
Operator는 마이너 OpenShift Container Platform 버전 간에 업그레이드할 수 없습니다. olm.maxOpenShiftVersion
매개변수를 사용하면 OADP 1.3이 설치된 경우 OpenShift Container Platform 4.16 버전으로 업그레이드할 수 없습니다. OpenShift Container Platform 4.16 버전으로 업그레이드하려면 OCP 4.15 버전의 OADP 1.3을 OADP 1.4로 업그레이드하십시오. OADP-4803
BSL 및 VSL이 클러스터에서 제거됨
이전에는 DPA(데이터 보호 애플리케이션)가 backupLocations
또는 snapshotLocations
섹션에서 Backup Storage Locations(BSL) 또는 Volume Snapshot Locations(VSL)를 제거하도록 수정된 경우 DPA가 삭제될 때까지 BSL 또는 VSL이 클러스터에서 제거되지 않았습니다. 이번 업데이트를 통해 BSL/VSL이 클러스터에서 제거됩니다. OADP-3050
DPA는 시크릿 키를 조정하고 검증합니다.
이전에는 DPA(데이터 보호 애플리케이션)가 잘못된 VSL(volume Snapshot Locations) 시크릿 키 이름에 성공적으로 조정되었습니다. 이번 업데이트를 통해 DPA는 VSL에서 조정하기 전에 시크릿 키 이름을 검증합니다. OADP-3052
Velero의 클라우드 인증 정보 권한이 제한됨
이전에는 Velero의 클라우드 인증 정보 권한이 0644 권한으로 마운트되었습니다. 결과적으로 소유자와 그룹을 제외한 /credentials/cloud
파일을 읽을 수 있어 스토리지 액세스 키와 같은 중요한 정보에 더 쉽게 액세스할 수 있었습니다. 이번 업데이트를 통해 이 파일의 권한이 0640으로 업데이트되고 소유자 및 그룹을 제외한 다른 사용자가 이 파일에 액세스할 수 없습니다.
ArgoCD 관리 네임스페이스가 백업에 포함된 경우 경고가 표시됩니다.
ArgoCD 및 Velero가 동일한 네임스페이스를 관리하면 백업 작업 중에 경고가 표시됩니다. OADP-4736
이 릴리스에 포함된 보안 수정 목록은 RHSA-2024:9960 권고에 설명되어 있습니다.
이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.3.4 해결 문제 목록을 참조하십시오.
4.2.1.3.2. 확인된 문제
Cryostat 애플리케이션 Pod는 복원 후 CrashLoopBackoff
상태로 들어갑니다.
OADP 복원 후 Cryostat 애플리케이션 pod는 CrashLoopBackoff
상태가 될 수 있습니다. 이 문제를 해결하려면 OADP를 복원한 후 오류 또는 CrashLoopBackoff
상태를 반환하는 StatefulSet
Pod를 삭제합니다. StatefulSet
컨트롤러는 이러한 Pod를 다시 생성하고 정상적으로 실행됩니다. OADP-3767
defaultVolumesToFSBackup 및 defaultVolumesToFsBackup 플래그는 동일하지 않습니다.
dpa.spec.configuration.velero.defaultVolumesToFSBackup
플래그가 backup.spec.defaultVolumesToFsBackup
플래그와 동일하지 않으므로 혼동이 발생할 수 있습니다. OADP-3692
복원이 실패로 표시되더라도 PodVolumeRestore가 작동합니다.
podvolumerestore
는 복원이 실패로 표시된 경우에도 데이터 전송을 계속합니다. OADP-3039
Velero가 initContainer 사양 복원을 건너뛸 수 없음
Velero는 필요하지 않은 경우에도 restore-wait init
컨테이너를 복원할 수 있습니다. OADP-3759
4.2.1.4. OADP 1.3.3 릴리스 노트
OADP(OpenShift API for Data Protection) 1.3.3 릴리스 노트에는 해결된 문제 및 알려진 문제가 나열됩니다.
4.2.1.4.1. 해결된 문제
네임스페이스 이름이 37자를 초과하면 OADP가 실패합니다.
37자 이상이 있고 새 DPA를 생성할 때 네임스페이스에 OADP Operator를 설치할 때 cloud-credentials
보안에 레이블이 지정됩니다. 이번 릴리스에서는 이 문제가 해결되었습니다. OADP-4211
OADP 이미지 PullPolicy가 Always
로 설정
이전 버전의 OADP에서는 adp-controller-manager 및 Velero Pod의 이미지 PullPolicy가 Always
로 설정되었습니다. 이는 레지스트리에 대한 네트워크 대역폭이 제한될 수 있는 에지 시나리오에서 문제가 발생하여 Pod를 다시 시작한 후 복구 시간이 느려졌습니다. OADP 1.3.3에서 openshift-adp-controller-manager
및 Velero Pod의 이미지 PullPolicy는 IfNotPresent
로 설정됩니다.
이 릴리스에 포함된 보안 수정 목록은 RHSA-2024:4982 권고에 설명되어 있습니다.
이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.3.3 해결 문제 목록을 참조하십시오.
4.2.1.4.2. 확인된 문제
Cryostat 애플리케이션 pod는 OADP를 복원한 후 CrashLoopBackoff
상태로 들어갑니다.
OADP 복원 후 Cryostat 애플리케이션 pod는 CrashLoopBackoff
상태에 입력할 수 있습니다. 이 문제를 해결하려면 OADP를 복원한 후 오류 또는 CrashLoopBackoff
상태를 반환하는 StatefulSet
Pod를 삭제합니다. StatefulSet
컨트롤러는 이러한 Pod를 다시 생성하고 정상적으로 실행됩니다.
4.2.1.5. OADP 1.3.2 릴리스 노트
OADP(OpenShift API for Data Protection) 1.3.2 릴리스 노트에는 해결된 문제 및 알려진 문제가 나열됩니다.
4.2.1.5.1. 해결된 문제
BSL에 유효한 사용자 정의 시크릿을 사용하는 경우 DPA 실패
DPA는 백업 스토리지 위치(BSL)에 유효한 사용자 정의 시크릿을 사용하지만 기본 시크릿이 없는 경우 조정할 수 없습니다. 해결방법은 처음에 필요한 기본 cloud-credentials
를 생성하는 것입니다. 사용자 정의 보안이 다시 생성되면 해당 보안의 존재를 확인하고 사용할 수 있습니다.
CVE-2023-45290: oadp-velero-container
: Golang net/http
: Request.ParseMultipartForm
의 메모리 소진
이전 버전의 OADP에 영향을 미치는 net/http
Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. Request.ParseMulti
파트 양식을 구문 분석할 때 구문 분석 양식의 총 크기에 대한 제한은 단일 양식 줄을 읽는 동안 사용되는 메모리에 적용되지 않습니다. 이렇게 하면 긴 줄이 포함된 악의적인 입력으로 인해 임의로 많은 양의 메모리를 할당하여 메모리 소모가 발생할 수 있습니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.
partForm
을 사용하여 명시적으로 또는 Request.FormValue
,Request.PostFormValue
또는 Request.FormFile
.FormFile을 사용하여 명시적으로 다중
자세한 내용은 CVE-2023-45290 에서 참조하십시오.
CVE-2023-45289: oadp-velero-container
: Golang net/http/cookiejar
: 민감한 헤더 및 쿠키를 HTTP 리디렉션에서 올바르게 전달하지 않음
이전 버전의 OADP에 영향을 미치는 net/http/cookiejar
Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. HTTP 리디렉션을 하위 도메인 일치 또는 초기 도메인의 정확한 일치가 아닌 도메인으로 리디렉션하는 경우 http.Client
는 Authorization
또는 Cryostat와 같은 중요한 헤더를 전달하지 않습니다. 악의적인 HTTP 리디렉션으로 인해 중요한 헤더가 예기치 않게 전달될 수 있습니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.
자세한 내용은 CVE-2023-45289 를 참조하십시오.
CVE-2024-24783: oadp-velero-container
: Golang crypto/x509
: 알 수 없는 공개 키 알고리즘이 있는 인증서의 패닉 확인
이전 버전의 OADP에 영향을 미치는 crypto/x509
Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. 알 수 없는 공개 키 알고리즘이 포함된 인증서 체인을 확인하면 Certificate.Verify
에 패닉 상태가 됩니다. 이는 Config.ClientAuth
를 VerifyClientCert 또는 RequireAnd
로 설정하는 모든 VerifyClientCert
암호화/tls
클라이언트 및 서버에 영향을 미칩니다. 기본 동작은 TLS 서버가 클라이언트 인증서를 확인하지 않는 것입니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.
자세한 내용은 CVE-2024-24783 에서 참조하십시오.
CVE-2024-24784: oadp-velero-plugin-container
: Golang net/mail
: 표시 이름의 댓글이 잘못 처리됨
이전 버전의 OADP에 영향을 미치는 net/mail
Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. ParseAddressList
함수는 주석을 잘못 처리하고, 괄호 안의 텍스트, 이름을 표시합니다. 이는 주소 구문 분석기를 따르는 잘못된 정렬이므로 다른 구문 분석을 사용하는 프로그램에서 서로 다른 신뢰 결정을 내릴 수 있습니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.
자세한 내용은 CVE-2024-24784 를 참조하십시오.
CVE-2024-24785: oadp-velero-container
: Golang: html/template: MarshalJSON
메서드에서 반환된 오류는 템플릿을 이스케이프할 수 있습니다.
이전 버전의 OADP에 영향을 미치는 html/template
Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. MarshalJSON
메서드에서 반환된 오류에 사용자 제어 데이터가 포함된 경우 HTML/template 패키지의 컨텍스트 자동 이스케이프 동작을 분할하여 후속 작업이 예기치 않은 콘텐츠를 템플릿에 삽입할 수 있습니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.
자세한 내용은 CVE-2024-24785 를 참조하십시오.
이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.3.2 해결 문제 목록을 참조하십시오.
4.2.1.5.2. 확인된 문제
Cryostat 애플리케이션 pod는 OADP를 복원한 후 CrashLoopBackoff
상태로 들어갑니다.
OADP 복원 후 Cryostat 애플리케이션 pod는 CrashLoopBackoff
상태에 입력할 수 있습니다. 이 문제를 해결하려면 OADP를 복원한 후 오류 또는 CrashLoopBackoff
상태를 반환하는 StatefulSet
Pod를 삭제합니다. StatefulSet
컨트롤러는 이러한 Pod를 다시 생성하고 정상적으로 실행됩니다.
4.2.1.6. OADP 1.3.1 릴리스 노트
OADP(OpenShift API for Data Protection) 1.3.1 릴리스 노트에는 새로운 기능 및 해결된 문제가 나열됩니다.
4.2.1.6.1. 새로운 기능
OADP 1.3.0 Data Mover가 완전 지원됨
OADP 1.3.0에 기술 프리뷰로 도입된 OADP 내장 데이터 Mover는 이제 컨테이너화된 워크로드와 가상 머신 워크로드 모두에 대해 완전히 지원됩니다.
4.2.1.6.2. 해결된 문제
IBM Cloud(R) Object Storage가 백업 스토리지 공급자로 지원됨
IBM Cloud® Object Storage는 이전에 지원되지 않는 AWS S3 호환 백업 스토리지 공급자 중 하나입니다. 이번 업데이트를 통해 IBM Cloud® Object Storage가 AWS S3 호환 백업 스토리지 공급자로 지원됩니다.
OADP Operator에서 누락된 지역 오류를 올바르게 보고
이전에는 AWS Backup Storage Location (BSL) 구성에 region
을 지정하지 않고 profile:default
를 지정하면 OADP Operator에서 DPA(Data Protection Application) 사용자 정의 리소스(CR)에서 누락된 리전
오류를 보고하지 못했습니다. 이번 업데이트에서는 AWS의 DPA BSL 사양의 검증이 수정되었습니다. 결과적으로 OADP Operator에서 누락된 지역
오류를 보고합니다.
사용자 정의 레이블은 openshift-adp 네임스페이스에서 제거되지 않음
이전에는 openshift-adp-controller-manager
Pod가 openshift-adp
네임스페이스에 연결된 레이블을 재설정했습니다. 이로 인해 Argo CD와 같은 사용자 정의 레이블이 필요한 애플리케이션의 동기화 문제로 인해 부적절한 기능이 발생했습니다. 이번 업데이트를 통해 이 문제가 수정되었으며 사용자 정의 레이블은 openshift-adp
네임스페이스에서 제거되지 않습니다.
OADP must-gather 이미지는 CRD를 수집합니다.
이전에는 OADP must-gather
이미지가 OADP에서 제공하는 CRD(사용자 정의 리소스 정의)를 수집하지 않았습니다. 결과적으로 지원 쉘에서 데이터를 추출하는 데 omg
툴을 사용할 수 없었습니다. 이번 수정으로 must-gather
이미지는 이제 OADP에서 제공하는 CRD를 수집하고 omg
툴을 사용하여 데이터를 추출할 수 있습니다.
가비지 컬렉션에는 기본 빈도 값에 대한 올바른 설명이 있습니다.
이전에는 garbage-collection-frequency
필드에 기본 빈도 값에 대한 잘못된 설명이 있었습니다. 이번 업데이트를 통해 garbage-collection-frequency
의 gc-controller
조정 기본 빈도에 대해 1시간의 올바른 값이 있습니다.
OperatorHub에서 FIPS 모드 플래그를 사용할 수 있습니다.
fips-compliant
플래그를 true
로 설정하면 OperatorHub의 OADP Operator 목록에 FIPS 모드 플래그가 추가되었습니다. 이 기능은 OADP 1.3.0에서 활성화되었지만 Red Hat Container 카탈로그에 FIPS가 활성화된 것으로 표시되지 않았습니다.
csiSnapshotTimeout이 짧은 기간으로 설정된 경우 CSI 플러그인에 nil 포인터가 패닉되지 않음
이전 버전에서는 csiSnapshotTimeout
매개변수가 단기간에 설정된 경우 CSI 플러그인에 다음 오류가 발생했습니다. plugin panicked: runtime error: invalid memory address or nil pointer dereference
.
이번 수정으로 다음 오류와 함께 백업이 실패합니다. volumesnapshot의 조정 대기 시간이 초과
되었습니다.
이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.3.1 해결 문제 목록을 참조하십시오.
4.2.1.6.3. 확인된 문제
IBM Power(R) 및 IBM Z(R) 플랫폼에 배포된 단일 노드 OpenShift 클러스터의 백업 및 스토리지 제한 사항
IBM Power® 및 IBM Z® 플랫폼에 배포된 Single-node OpenShift 클러스터에 대한 다음 백업 및 스토리지 관련 제한을 검토하십시오.
- 스토리지
- 현재 NFS 스토리지만 IBM Power® 및 IBM Z® 플랫폼에 배포된 단일 노드 OpenShift 클러스터와 호환됩니다.
- Backup
-
kopia
및restic
와 같은 파일 시스템 백업을 사용하는 백업 애플리케이션만 백업 및 복원 작업을 지원합니다.
Cryostat 애플리케이션 Pod는 OADP를 복원한 후 CrashLoopBackoff 상태로 입력합니다.
OADP 복원 후 Cryostat 애플리케이션 pod는 CrashLoopBackoff
상태에 입력할 수 있습니다. 이 문제를 해결하려면 OADP를 복원한 후 오류 또는 CrashLoopBackoff
상태의 StatefulSet
Pod를 삭제합니다. StatefulSet
컨트롤러는 이러한 Pod를 다시 생성하고 정상적으로 실행됩니다.
4.2.1.7. OADP 1.3.0 릴리스 노트
OADP(OpenShift API for Data Protection) 1.3.0 릴리스에는 새로운 기능, 해결된 문제 및 버그, 알려진 문제가 포함되어 있습니다.
4.2.1.7.1. 새로운 기능
Velero 내장 DataMover는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
OADP 1.3에는 CSI(Container Storage Interface) 볼륨 스냅샷을 원격 오브젝트 저장소로 이동하는 데 사용할 수 있는 기본 제공 데이터 Mover가 포함되어 있습니다. 기본 제공 Data Mover를 사용하면 오류, 실수로 삭제 또는 클러스터 손상이 발생하는 경우 원격 오브젝트 저장소에서 상태 저장 애플리케이션을 복원할 수 있습니다. Kopia를 업로드기 메커니즘으로 사용하여 스냅샷 데이터를 읽고 Unified Repository에 씁니다.
파일 시스템 백업을 사용하여 애플리케이션 백업: Kopia 또는 Restic
Velero의 파일 시스템 백업(FSB)은 Restic 경로와 Kopia 경로의 두 가지 백업 라이브러리를 지원합니다.
Velero를 사용하면 두 경로 중 하나를 선택할 수 있습니다.
backup의 경우 uploader-type
플래그를 통해 설치 중 경로를 지정합니다. 유효한 값은 restic
또는 kopia
입니다. 이 필드는 값이 지정되지 않은 경우 기본값은 kopia
입니다. 설치 후에는 선택을 변경할 수 없습니다.
GCP 클라우드 인증
GCP(Google Cloud Platform) 인증을 사용하면 수명이 짧은 Google 인증 정보를 사용할 수 있습니다.
GCP with Workload Identity Federation을 사용하면 IAM(Identity and Access Management)을 사용하여 서비스 계정을 가장하는 기능을 포함하여 외부 ID IAM 역할을 부여할 수 있습니다. 이렇게 하면 서비스 계정 키와 관련된 유지 관리 및 보안 위험이 제거됩니다.
AWS ROSA STS 인증
ROSA(Red Hat OpenShift Service) 클러스터에서 OADP(OpenShift API for Data Protection)를 사용하여 애플리케이션 데이터를 백업하고 복원할 수 있습니다.
ROSA는 다양한 AWS 컴퓨팅, 데이터베이스, 분석, 머신 러닝, 네트워킹, 모바일 및 기타 서비스와 원활한 통합을 제공하여 고객에게 차별화된 경험을 구축하고 제공합니다.
AWS 계정에서 직접 서비스에 등록할 수 있습니다.
클러스터가 생성되면 OpenShift 웹 콘솔을 사용하여 클러스터를 작동할 수 있습니다. ROSA 서비스는 OpenShift API 및 CLI(명령줄 인터페이스) 툴도 사용합니다.
4.2.1.7.2. 해결된 문제
ACM 애플리케이션이 복원 후 관리 클러스터에서 제거 및 다시 생성됨
복원 활성화 시 관리 클러스터의 애플리케이션이 삭제되고 다시 생성되었습니다. OADP 1.2(OpenShift API for Data Protection) 백업 및 복원 프로세스는 이전 버전보다 빠릅니다. OADP 성능 변경으로 인해 ACM 리소스를 복원할 때 이러한 동작이 발생했습니다. 따라서 다른 리소스보다 먼저 일부 리소스가 복원되어 관리 클러스터에서 애플리케이션이 제거되었습니다. OADP-2686
Pod 보안 표준으로 인해 Restic 복원이 부분적으로 실패했습니다.
상호 운용성 테스트 중에 OpenShift Container Platform 4.14에 Pod 보안 모드가 적용
되도록 설정되어 이로 인해 Pod가 거부됩니다. 이는 복원 순서 때문에 발생했습니다. Pod가 podSecurity
표준을 위반하여 Pod가 Pod를 거부했기 때문에 SCC(보안 컨텍스트 제약 조건) 리소스 전에 포드가 생성되었습니다. Velero 서버에서 restore 우선순위 필드를 설정하는 경우 복원에 성공합니다. OADP-2688
Velero가 여러 네임스페이스에 설치된 경우 가능한 Pod 볼륨 백업 실패
Velero가 여러 네임스페이스에 설치된 경우 PVB(Pod Volume Backup) 기능에 회귀 문제가 있었습니다. PVB 컨트롤러가 자체 네임스페이스의 PVB로 올바르게 제한되지 않았습니다. OADP-2308
OADP Velero 플러그인 반환 "Received EOF, stop recv loop" 메시지
OADP에서 Velero 플러그인은 별도의 프로세스로 시작되었습니다. Velero 작업이 완료되면 해당 작업이 성공적으로 종료됩니다. 따라서 디버그 로그에 recv 루프 메시지를 중지하여 수신된 EOF
가 표시되면 오류가 발생한 것은 아닙니다. 플러그인 작업이 완료되었음을 의미합니다. OADP-2176
CVE-2023-39325 Multiple HTTP/2 enabled 웹 서버는 DDoS 공격에 취약합니다(Rapid Reset Attack)
이전 릴리스의 OADP 릴리스에서는 요청 취소가 여러 스트림을 빠르게 재설정할 수 있기 때문에 HTTP/2 프로토콜이 서비스 거부 공격에 취약했습니다. 서버는 스트림을 설정하고 해체하는 동시에 연결당 최대 활성 스트림 수에 대한 서버 측 제한에 도달하지 않아야 했습니다. 이로 인해 서버 리소스 사용량으로 인해 서비스가 거부되었습니다.
자세한 내용은 CVE-2023-39325 (Rapid Reset Attack)를 참조하십시오.
이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.3.0 해결 문제 목록을 참조하십시오.
4.2.1.7.3. 확인된 문제
csiSnapshotTimeout이 짧은 기간으로 설정된 경우 nil 포인터에 CSI 플러그인 오류
csiSnapshotTimeout
이 짧은 기간으로 설정된 경우 nil 포인터에 CSI 플러그인 오류가 발생합니다. 경우에 따라 짧은 기간 내에 스냅샷을 완료하는 데 성공하지만 plugin panicked: runtime error: invalid memory address 또는 nil 포인터 역참조
와 함께 백업 PartiallyFailed
가 패닉되는 경우가 있습니다.
volumeSnapshotContent CR에 오류가 있을 때 백업이 PartiallyFailed로 표시됩니다.
VolumeSnapshotBeingCreated
주석 제거와 관련된 VolumeSnapshotContent
CR에 오류가 있는 경우 백업을 WaitingForPluginOperationsPartiallyFailed
단계로 이동합니다. OADP-2871
performance issues when restoring resources for the first time
existing-resource-policy 없이 처음으로 Cryostat 리소스를 복원할 때 두 번째 및 세 번째 시도 중에 업데이트를
위해 설정된 existing-resource-policy를 사용하여 복원하는 데 걸리는 두 배의 시간이 걸립니다. OADP-3071
Datadownload 작업이 관련 PV를 릴리스하기 전에 복원 후 후크가 실행될 수 있습니다.
Data Mover 작업의 비동기적 특성으로 인해 관련 Pod PV(영구 볼륨 클레임)를 PVC(영구 볼륨 클레임)에서 릴리스하기 전에 후크를 시도할 수 있습니다.
GCP-Workload Identity Federation VSL 백업 PartiallyFailed
VSL 백업은 GCP 워크로드 ID가 GCP에 설정된 경우 부분적으로Failed
됩니다.
이 릴리스에서 알려진 모든 문제의 전체 목록은 Jira의 OADP 1.3.0 알려진 문제 목록을 참조하십시오.
4.2.1.7.4. 업그레이드 노트
항상 다음 마이너 버전으로 업그레이드합니다. 버전을 건너뛰 지 마십시오. 이후 버전으로 업데이트하려면 한 번에 하나의 채널만 업그레이드합니다. 예를 들어 OADP(OpenShift API for Data Protection) 1.1에서 1.3으로 업그레이드하려면 먼저 1.2로 업그레이드한 다음 1.3으로 업그레이드합니다.
4.2.1.7.4.1. OADP 1.2에서 1.3으로 변경
Velero 서버가 버전 1.11에서 1.12로 업데이트되었습니다.
OADP(OpenShift API for Data Protection) 1.3은 VolumeSnapshotMover(VSM) 또는volsync Data Mover 대신 Velero 기본 제공 데이터 Mover를 사용합니다.
이렇게 하면 다음이 변경됩니다.
-
spec.features.dataMover
필드와 VSM 플러그인은 OADP 1.3과 호환되지 않으며 DPA(DataProtectionApplication
) 구성에서 구성을 제거해야 합니다. - volsync Operator는 더 이상 Data Mover 기능에 필요하지 않으며 제거할 수 있습니다.
-
사용자 정의 리소스 정의
volumesnapshotbackups.datamover.oadp.openshift.io
및volumesnapshotrestores.datamover.oadp.openshift.io
는 더 이상 필요하지 않으며 제거할 수 있습니다. - OADP-1.2 Data Mover에 사용된 시크릿은 더 이상 필요하지 않으며 제거할 수 있습니다.
OADP 1.3은 Restic에 대한 대체 파일 시스템 백업 툴인 Kopia를 지원합니다.
Kopia를 사용하려면 다음 예와 같이 새
spec.configuration.nodeAgent
필드를 사용합니다.예제
spec: configuration: nodeAgent: enable: true uploaderType: kopia # ...
spec.configuration.restic
필드는 OADP 1.3에서 더 이상 사용되지 않으며 향후 OADP 버전에서 제거될 예정입니다. 사용 중단 경고가 표시되지 않도록 하려면restic
키와 해당 값을 제거하고 다음 새 구문을 사용합니다.예제
spec: configuration: nodeAgent: enable: true uploaderType: restic # ...
향후 OADP 릴리스에서는 kopia
툴이 기본 uploaderType
값이 될 계획입니다.
4.2.1.7.4.2. OADP 1.2 기술 프리뷰 데이터에서 업그레이드
OADP(OpenShift API for Data Protection) 1.2 Data Mover 백업을 OADP 1.3으로 복원 할 수 없습니다. 애플리케이션 데이터 보호의 격차를 방지하려면 OADP 1.3으로 업그레이드하기 전에 다음 단계를 완료합니다.
프로세스
- 클러스터 백업이 충분하고 CSI(Container Storage Interface) 스토리지를 사용할 수 있는 경우 CSI 백업을 사용하여 애플리케이션을 백업합니다.
클러스터 백업을 꺼야 하는 경우:
-
--default-volumes-to-fs-backup=true 또는 backup.spec.defaultVolumesToFsBackup
옵션을 사용하는 파일 시스템 백업으로 애플리케이션을 백업합니다. -
오브젝트 스토리지 플러그인으로 애플리케이션을 백업합니다(예:
velero-plugin-for-aws
).
-
Restic 파일 시스템 백업의 기본 시간 초과 값은 1시간입니다. OADP 1.3.1 이상에서는 Restic 및 Kopia의 기본 시간 초과 값은 4시간입니다.
OADP 1.2 데이터 관리 백업을 복원하려면 OADP를 제거하고 OADP 1.2를 설치 및 구성해야 합니다.
4.2.1.7.4.3. DPA 구성 백업
현재 DPA( DataProtectionApplication
) 구성을 백업해야 합니다.
프로세스
다음 명령을 실행하여 현재 DPA 구성을 저장합니다.
예제
$ oc get dpa -n openshift-adp -o yaml > dpa.orig.backup
4.2.1.7.4.4. OADP Operator 업그레이드
OADP(OpenShift API for Data Protection) Operator를 업그레이드할 때 다음 시퀀스를 사용합니다.
프로세스
-
OADP Operator의 서브스크립션 채널을
stable-1.2
에서stable-1.3
으로 변경합니다. - Operator 및 컨테이너가 업데이트 및 재시작될 수 있는 시간을 허용합니다.
추가 리소스
4.2.1.7.4.5. DPA를 새 버전으로 변환
Data Mover를 사용하여 클러스터에서 백업을 이동해야 하는 경우 다음과 같이 DPA( DataProtectionApplication
) 매니페스트를 재구성합니다.
프로세스
- Operators → 설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
- 제공된 API 섹션에서 추가 보기를 클릭합니다.
- DataProtectionApplication 상자에서 인스턴스 만들기 를 클릭합니다.
YAML View 를 클릭하여 현재 DPA 매개변수를 표시합니다.
현재 DPA의 예
spec: configuration: features: dataMover: enable: true credentialName: dm-credentials velero: defaultPlugins: - vsm - csi - openshift # ...
DPA 매개변수를 업데이트합니다.
-
DPA에서
features.dataMover
키와 값을 제거합니다. - VolumeSnapshotMover(VSM) 플러그인을 제거합니다.
nodeAgent
키와 값을 추가합니다.업데이트된 DPA 예
spec: configuration: nodeAgent: enable: true uploaderType: kopia velero: defaultPlugins: - csi - openshift # ...
-
DPA에서
- DPA가 성공적으로 조정될 때까지 기다립니다.
4.2.1.7.4.6. 업그레이드 확인
다음 절차를 사용하여 업그레이드를 확인합니다.
프로세스
다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다.
$ oc get all -n openshift-adp
출력 예
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
다음 명령을 실행하여 DPA(
DataProtectionApplication
)가 조정되었는지 확인합니다.$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
출력 예
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
유형이
Reconciled
으로 설정되어 있는지 확인합니다. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여
PHASE
가 사용
가능한지 확인합니다.$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
OADP 1.3에서는 DPA( DataProtectionApplication
) 구성을 생성하는 대신 백업당 클러스터에서 데이터 이동을 시작할 수 있습니다.
예제
$ velero backup create example-backup --include-namespaces mysql-persistent --snapshot-move-data=true
예제
apiVersion: velero.io/v1 kind: Backup metadata: name: example-backup namespace: openshift-adp spec: snapshotMoveData: true includedNamespaces: - mysql-persistent storageLocation: dpa-sample-1 ttl: 720h0m0s # ...
4.3. OADP 성능
4.3.1. OADP 권장 네트워크 설정
OADP(OpenShift API for Data Protection)에서 지원되는 환경을 위해 {OCP-short} 노드, S3 스토리지 및 {OCP-short} 네트워크 요구 사항을 충족하는 지원되는 클라우드 환경에서 안정적이고 탄력적인 네트워크를 보유해야 합니다.
최적의 데이터 경로가 있는 원격 S3 버킷을 사용한 배포에 대한 백업 및 복원 작업을 성공적으로 수행하려면 네트워크 설정이 최적의 조건에서 다음과 같은 최소 요구 사항을 충족하는 것이 좋습니다.
- 대역폭(오브젝트 스토리지에 대한 네트워크 업로드 속도): 작은 백업의 경우 2Mbps 이상, 더 큰 백업의 데이터 볼륨에 따라 10-100Mbps입니다.
- 패킷 손실: 1%
- 패킷 손상: 1%
- 대기 시간: 100ms
OpenShift Container Platform 네트워크가 최적으로 작동하고 OpenShift Container Platform 네트워크 요구 사항을 충족하는지 확인하십시오.
Red Hat은 표준 백업 및 복원 실패를 지원하지만 권장 임계값을 충족하지 않는 네트워크 설정으로 인한 오류를 지원하지 않습니다.
4.4. OADP 기능 및 플러그인
OpenShift API for Data Protection(OADP) 기능은 애플리케이션을 백업 및 복원하는 옵션을 제공합니다.
기본 플러그인을 사용하면 Velero가 특정 클라우드 공급자와 통합하고 OpenShift Container Platform 리소스를 백업 및 복원할 수 있습니다.
4.4.1. OADP 기능
OpenShift API for Data Protection(OADP)은 다음 기능을 지원합니다.
- Backup
OADP를 사용하여 OpenShift Platform의 모든 애플리케이션을 백업하거나 유형, 네임스페이스 또는 레이블별로 리소스를 필터링할 수 있습니다.
OADP는 Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지에 아카이브 파일로 저장하여 백업합니다. OADP는 기본 클라우드 스냅샷 API 또는 CSI(Container Storage Interface)를 사용하여 스냅샷을 생성하여 PV(영구 볼륨)를 백업합니다. 스냅샷을 지원하지 않는 클라우드 공급자의 경우 OADP는 Restic을 통해 리소스 및 PV 데이터를 백업합니다.
참고백업 및 복원에 성공하려면 애플리케이션의 백업에서 Operator를 제외해야 합니다.
- Restore
백업에서 리소스 및 PV를 복원할 수 있습니다. 백업의 모든 오브젝트를 복원하거나 네임스페이스, PV 또는 라벨별로 오브젝트를 필터링할 수 있습니다.
참고백업 및 복원에 성공하려면 애플리케이션의 백업에서 Operator를 제외해야 합니다.
- 스케줄
- 지정된 간격으로 백업을 예약할 수 있습니다.
- 후크
-
후크를 사용하여 Pod의 컨테이너에서 명령을 실행할 수 있습니다(예:
fsfreeze
파일 시스템). 백업 또는 복원 전이나 후에 실행되도록 후크를 구성할 수 있습니다. 복원 후크는 init 컨테이너 또는 애플리케이션 컨테이너에서 실행될 수 있습니다.
4.4.2. OADP 플러그인
OADP(OpenShift API for Data Protection)는 백업 및 스냅샷 작업을 지원하기 위해 스토리지 공급자와 통합된 기본 Velero 플러그인을 제공합니다. Velero 플러그인을 기반으로 사용자 지정 플러그인 을 생성할 수 있습니다.
OADP는 OpenShift Container Platform 리소스 백업, OpenShift Virtualization 리소스 백업 및 CSI(Container Storage Interface) 스냅샷에 대한 플러그인도 제공합니다.
OADP 플러그인 | 함수 | 스토리지 위치 |
---|---|---|
| Kubernetes 오브젝트를 백업하고 복원합니다. | AWS S3 |
스냅샷을 사용하여 볼륨을 백업하고 복원합니다. | AWS EBS | |
| Kubernetes 오브젝트를 백업하고 복원합니다. | Microsoft Azure Blob 스토리지 |
스냅샷을 사용하여 볼륨을 백업하고 복원합니다. | Microsoft Azure Managed Disks | |
| Kubernetes 오브젝트를 백업하고 복원합니다. | Google Cloud Storage |
스냅샷을 사용하여 볼륨을 백업하고 복원합니다. | Google Compute Engine Disks | |
| OpenShift Container Platform 리소스를 백업하고 복원합니다. [1] | 오브젝트 저장소 |
| OpenShift Virtualization 리소스를 백업하고 복원합니다. [2] | 오브젝트 저장소 |
| CSI 스냅샷을 사용하여 볼륨을 백업하고 복원합니다. [3] | CSI 스냅샷을 지원하는 클라우드 스토리지 |
| VolumeSnapshotMover는 클러스터 삭제와 같은 상황에서 상태 저장 애플리케이션을 복구하는 동안 사용할 스냅샷을 클러스터에서 오브젝트 저장소로 재배치합니다. [4] | 오브젝트 저장소 |
- 필수.
- 가상 머신 디스크는 CSI 스냅샷 또는 Restic을 사용하여 백업됩니다.
csi
플러그인은 Kubernetes CSI 스냅샷 API를 사용합니다.-
OADP 1.1 이상에서는
snapshot.storage.k8s.io/v1
을 사용합니다. -
OADP 1.0 uses
snapshot.storage.k8s.io/v1beta1
-
OADP 1.1 이상에서는
- OADP 1.2만 해당
4.4.3. OADP Velero 플러그인 정보
Velero를 설치할 때 다음 두 가지 유형의 플러그인을 구성할 수 있습니다.
- 기본 클라우드 공급자 플러그인
- 사용자 정의 플러그인
두 가지 유형의 플러그인은 모두 선택 사항이지만 대부분의 사용자는 하나 이상의 클라우드 공급자 플러그인을 구성합니다.
4.4.3.1. 기본 Velero 클라우드 공급자 플러그인
배포 중에 oadp_v1alpha1_dpa.yaml
파일을 구성할 때 다음과 같은 기본 Velero 클라우드 공급자 플러그인을 설치할 수 있습니다.
-
AWS
(Amazon Web Services) -
GCP(
Google Cloud Platform) -
Azure
(Microsoft Azure) -
OpenShift
(OpenShift Velero 플러그인) -
CSI
(컨테이너 스토리지 인터페이스) -
KubeVirt
(KubeVirt)
배포 중에 oadp_v1alpha1_dpa.yaml
파일에 원하는 기본 플러그인을 지정합니다.
파일 예
다음 .yaml
파일은 openshift
,aws
,azure
, gcp
플러그인을 설치합니다.
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: velero: defaultPlugins: - openshift - aws - azure - gcp
4.4.3.2. 사용자 정의 Velero 플러그인
배포 중에 oadp_v1alpha1_dpa.yaml
파일을 구성할 때 플러그인 이미지
및 이름을
지정하여 사용자 정의 Velero 플러그인을 설치할 수 있습니다.
배포 중에 oadp_v1alpha1_dpa.yaml
파일에 원하는 사용자 지정 플러그인을 지정합니다.
파일 예
다음 .yaml
파일은 기본 openshift
,azure
, gcp
플러그인 및 이름이 custom-plugin-example
이고 quay.io/example-repo/custom-velero-plugin
이미지가 있는 사용자 정의 플러그인을 설치합니다.
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: velero: defaultPlugins: - openshift - azure - gcp customPlugins: - name: custom-plugin-example image: quay.io/example-repo/custom-velero-plugin
4.4.3.3. Velero 플러그인에서 "received EOF, stop recv loop" 메시지를 반환
Velero 플러그인은 별도의 프로세스로 시작됩니다. Velero 작업이 성공적으로 완료되거나 실패하면 종료됩니다. 디버그 로그에서 recv 루프 메시지를 중지하여 수신된 EOF
를 수신하면 플러그인 작업이 완료되었음을 나타냅니다. 이는 오류가 발생했음을 의미하지 않습니다.
4.4.4. OADP에서 지원되는 아키텍처
OADP(OpenShift API for Data Protection)는 다음과 같은 아키텍처를 지원합니다.
- AMD64
- ARM64
- PPC64le
- s390x
OADP 1.2.0 이상 버전은 ARM64 아키텍처를 지원합니다.
4.4.5. IBM Power 및 IBM Z에 대한 OADP 지원
OADP(OpenShift API for Data Protection)는 플랫폼에서 사용할 수 없습니다. 다음 정보는 IBM Power® 및 IBM Z®에만 관련이 있습니다.
- OADP 1.1.7은 IBM Power® 및 IBM Z® 모두에 대해 OpenShift Container Platform 4.11에 대해 성공적으로 테스트되었습니다. 다음 섹션에서는 이러한 시스템의 백업 위치 측면에서 OADP 1.1.7에 대한 테스트 및 지원 정보를 제공합니다.
- OADP 1.2.3은 IBM Power® 및 IBM Z® 모두에 대해 OpenShift Container Platform 4.12, 4.13, 4.14 및 4.15에 대해 성공적으로 테스트되었습니다. 다음 섹션에서는 이러한 시스템의 백업 위치 측면에서 OADP 1.2.3에 대한 테스트 및 지원 정보를 제공합니다.
- OADP 1.3.6은 IBM Power® 및 IBM Z® 모두에 대해 OpenShift Container Platform 4.12, 4.13, 4.14 및 4.15에 대해 성공적으로 테스트되었습니다. 다음 섹션에서는 이러한 시스템의 백업 위치 관점에서 OADP 1.3.6에 대한 테스트 및 지원 정보를 제공합니다.
4.4.5.1. IBM Power를 사용하여 대상 백업 위치에 대한 OADP 지원
- OpenShift Container Platform 4.11 및 4.12로 실행 중인 IBM Power®는 OADP(OpenShift API for Data Protection) 1.1.7을 사용하여 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트에는 AWS S3 대상만 포함되었지만 Red Hat은 OpenShift Container Platform 4.11 및 4.12를 사용하여 IBM Power® 실행을 지원하며 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OADP 1.1.7도 지원합니다.
- OpenShift Container Platform 4.12, 4.13, 4.14, 4.15 및 OADP 1.2.3에서 실행되는 IBM Power®는 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트는 AWS S3 대상만 포함했지만 Red Hat은 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OpenShift Container Platform 4.12, 4.13. 4.14, 4.15 및 OADP 1.2.3을 사용하여 IBM Power® 실행을 지원합니다.
- OpenShift Container Platform 4.12, 4.13, 4.14, 4.15 및 OADP 1.3.6에서 실행 중인 IBM Power®는 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트에는 AWS S3 대상만 포함되었지만 Red Hat은 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OpenShift Container Platform 4.12, 4.13, 4.14, 4.15, OADP 1.3.6을 사용하여 IBM Power® 실행을 지원합니다.
4.4.5.2. OADP 테스트 및 IBM Z를 사용하여 대상 백업 위치 지원
- OpenShift Container Platform 4.11 및 4.12로 실행 중인 IBM Z®는 OADP(OpenShift API for Data Protection) 1.1.7을 사용하여 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트에는 AWS S3 대상만 포함되었지만 Red Hat은 OpenShift Container Platform 4.11 및 4.12를 사용하여 IBM Z® 실행을 지원하며 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OADP 1.1.7도 지원합니다.
- OpenShift Container Platform 4.12, 4.13, 4.14, 4.15 및 OADP 1.2.3에서 실행 중인 IBM Z®는 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트는 AWS S3 대상만 포함했지만 Red Hat은 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OpenShift Container Platform 4.12, 4.14, 4.15 및 OADP 1.2.3을 사용하여 IBM Z® 실행을 지원합니다.
- OpenShift Container Platform 4.12, 4.13, 4.14 및 4.15에서 실행 중인 IBM Z®는 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트는 AWS S3 대상만 포함했지만 Red Hat은 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OpenShift Container Platform 4.12, 4.13 4.14, 4.15 및 1.3.6을 사용하여 IBM Z® 실행을 지원합니다.
4.4.5.2.1. IBM Power(R) 및 IBM Z(R) 플랫폼을 사용하는 OADP의 알려진 문제
- 현재 IBM Power® 및 IBM Z® 플랫폼에 배포된 단일 노드 OpenShift 클러스터에 대한 백업 방법 제한 사항이 있습니다. 현재 NFS 스토리지만 이러한 플랫폼의 단일 노드 OpenShift 클러스터와 호환됩니다. 또한 Kopia 및 Restic과 같은 파일 시스템 백업(FSB) 메서드만 백업 및 복원 작업에 지원됩니다. 현재 이 문제에 대한 해결방법이 없습니다.
4.4.6. OADP 플러그인의 알려진 문제
다음 섹션에서는 OADP(OpenShift API for Data Protection) 플러그인의 알려진 문제에 대해 설명합니다.
4.4.6.1. 시크릿이 누락되어 이미지 스트림 백업 중 Velero 플러그인 패닉
백업 및 백업 스토리지 위치(BSL)가 데이터 보호 애플리케이션(DPA)의 범위 외부에서 관리되는 경우, OADP 컨트롤러는 DPA 조정에서 관련 oadp-<bsl_name>-<bsl_provider>-registry-secret
을 생성하지 않습니다.
백업이 실행되면 다음 패닉 오류와 함께 이미지 스트림 백업에 OpenShift Velero 플러그인이 패닉됩니다.
024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item" backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io, namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked: runtime error: index out of range with length 1, stack trace: goroutine 94…
4.4.6.1.1. 패닉 오류를 방지하기 위한 해결방법
Velero 플러그인 패닉 오류를 방지하려면 다음 단계를 수행합니다.
관련 라벨을 사용하여 사용자 지정 BSL에 레이블을 지정합니다.
$ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl
BSL 레이블이 지정된 후 DPA가 조정될 때까지 기다립니다.
참고DPA 자체를 약간 변경하여 강제로 조정할 수 있습니다.
DPA가 조정되면 관련
oadp-<bsl_name>-<bsl_provider>-registry-secret
이 생성되고 올바른 레지스트리 데이터가 입력되었는지 확인합니다.$ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
4.4.6.2. OpenShift ADP 컨트롤러 분할 오류
cloudstorage
및 restic
이 활성화된 DPA를 구성하는 경우 openshift-adp-controller-manager
Pod가 충돌하고 크래시 루프 세그먼트 오류로 인해 Pod가 실패할 때까지 무기한 재시작합니다.
상호 배타적 필드이므로 velero
또는 cloudstorage
를 정의할 수 있습니다.
-
velero
및cloudstorage
가 모두 정의되어 있는 경우openshift-adp-controller-manager
가 실패합니다. -
velero
또는cloudstorage
가 정의되지 않은 경우openshift-adp-controller-manager
가 실패합니다.
이 문제에 대한 자세한 내용은 OADP-1054 를 참조하십시오.
4.4.6.2.1. OpenShift ADP 컨트롤러 분할 오류 해결
DPA를 구성할 때 velero
또는 cloudstorage
를 정의해야 합니다. DPA에 두 API를 모두 정의하면 크래시 루프 분할 오류와 함께 openshift-adp-controller-manager
Pod가 실패합니다.
4.5. OADP 사용 사례
4.5.1. 데이터 보호 및 {odf-first}용 OpenShift API를 사용한 백업
다음은 애플리케이션을 백업하기 위해 OADP 및 {odf-short}을 사용하는 사용 사례입니다.
4.5.1.1. OADP 및 {odf-short}을 사용하여 애플리케이션 백업
이 사용 사례에서는 OADP를 사용하여 애플리케이션을 백업하고 {odf-first}에서 제공하는 오브젝트 스토리지에 백업을 저장합니다.
- OBC(오브젝트 버킷 클레임)를 생성하여 백업 스토리지 위치를 구성합니다. {odf-short}을 사용하여 Amazon S3 호환 오브젝트 스토리지 버킷을 구성합니다. {odf-short}은 MultiCloud Object Gateway(NooBaa MCG) 및 Ceph Object Gateway(RGW), 개체 스토리지 서비스라고도 합니다. 이 사용 사례에서는 NooBaa MCG를 백업 스토리지 위치로 사용합니다.
-
aws
공급자 플러그인을 사용하여 OADP와 함께 NooBaa MCG 서비스를 사용합니다. - BPA(데이터 보호 애플리케이션)를 백업 스토리지 위치(BSL)로 구성합니다.
- 백업 CR(사용자 정의 리소스)을 생성하고 백업할 애플리케이션 네임스페이스를 지정합니다.
- 백업을 생성하고 확인합니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- {odf-short} Operator를 설치했습니다.
- 별도의 네임스페이스에서 실행 중인 데이터베이스가 있는 애플리케이션이 있습니다.
절차
다음 예와 같이 OBC 매니페스트 파일을 생성하여 NooBaa MCG 버킷을 요청합니다.
OBC의 예
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: test-obc 1 namespace: openshift-adp spec: storageClassName: openshift-storage.noobaa.io generateBucketName: test-backup-bucket 2
다음 명령을 실행하여 OBC를 생성합니다.
$ oc create -f <obc_file_name> 1
- 1
- 오브젝트 버킷 클레임 매니페스트의 파일 이름을 지정합니다.
OBC를 생성할 때 {odf-short}은 오브젝트 버킷 클레임과 동일한 이름의
시크릿
및구성 맵
을 생성합니다.시크릿에
는 버킷 인증 정보가 있으며구성 맵에
는 버킷에 액세스하는 데 필요한 정보가 있습니다. 생성된 구성 맵에서 버킷 이름과 버킷 호스트를 가져오려면 다음 명령을 실행합니다.$ oc extract --to=- cm/test-obc 1
- 1
test-obc
는 OBC의 이름입니다.
출력 예
# BUCKET_NAME backup-c20...41fd # BUCKET_PORT 443 # BUCKET_REGION # BUCKET_SUBREGION # BUCKET_HOST s3.openshift-storage.svc
생성된
보안
에서 버킷 인증 정보를 가져오려면 다음 명령을 실행합니다.$ oc extract --to=- secret/test-obc
출력 예
# AWS_ACCESS_KEY_ID ebYR....xLNMc # AWS_SECRET_ACCESS_KEY YXf...+NaCkdyC3QPym
다음 명령을 실행하여
openshift-storage
네임스페이스의 s3 경로에서 S3 끝점의 공용 URL을 가져옵니다.$ oc get route s3 -n openshift-storage
다음 명령에 표시된 대로 오브젝트 버킷 인증 정보를 사용하여
cloud-credentials
파일을 만듭니다.[default] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
다음 명령에 표시된 대로
cloud-credentials
$ oc create secret generic \ cloud-credentials \ -n openshift-adp \ --from-file cloud=cloud-credentials
다음 예와 같이 DPA(Data Protection Application)를 구성합니다.
DPA 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: oadp-backup namespace: openshift-adp spec: configuration: nodeAgent: enable: true uploaderType: kopia velero: defaultPlugins: - aws - openshift - csi defaultSnapshotMoveData: true 1 backupLocations: - velero: config: profile: "default" region: noobaa s3Url: https://s3.openshift-storage.svc 2 s3ForcePathStyle: "true" insecureSkipTLSVerify: "true" provider: aws default: true credential: key: cloud name: cloud-credentials objectStorage: bucket: <bucket_name> 3 prefix: oadp
다음 명령을 실행하여 DPA를 생성합니다.
$ oc apply -f <dpa_filename>
다음 명령을 실행하여 DPA가 성공적으로 생성되었는지 확인합니다. 예제 출력에서
status
오브젝트에type
필드가Reconciled
으로 설정되어 있음을 확인할 수 있습니다. 즉, DPA가 성공적으로 생성됩니다.$ oc get dpa -o yaml
출력 예
apiVersion: v1 items: - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: namespace: openshift-adp #...# spec: backupLocations: - velero: config: #...# status: conditions: - lastTransitionTime: "20....9:54:02Z" message: Reconcile complete reason: Complete status: "True" type: Reconciled kind: List metadata: resourceVersion: ""
다음 명령을 실행하여 백업 스토리지 위치(BSL)를 사용할 수 있는지 확인합니다.
$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 3s 15s true
다음 예와 같이 백업 CR을 구성합니다.
백업 CR의 예
apiVersion: velero.io/v1 kind: Backup metadata: name: test-backup namespace: openshift-adp spec: includedNamespaces: - <application_namespace> 1
- 1
- 애플리케이션을 백업할 네임스페이스를 지정합니다.
다음 명령을 실행하여 backup CR을 생성합니다.
$ oc apply -f <backup_cr_filename>
검증
다음 명령을 실행하여 백업 오브젝트가
Completed
단계에 있는지 확인합니다. 자세한 내용은 예제 출력을 참조하십시오.$ oc describe backup test-backup -n openshift-adp
출력 예
Name: test-backup Namespace: openshift-adp # ....# Status: Backup Item Operations Attempted: 1 Backup Item Operations Completed: 1 Completion Timestamp: 2024-09-25T10:17:01Z Expiration: 2024-10-25T10:16:31Z Format Version: 1.1.0 Hook Status: Phase: Completed Progress: Items Backed Up: 34 Total Items: 34 Start Timestamp: 2024-09-25T10:16:31Z Version: 1 Events: <none>
4.5.2. OADP(OpenShift API for Data Protection) 복원 사용 사례
다음은 OADP를 사용하여 다른 네임스페이스로 백업을 복원하는 사용 사례입니다.
4.5.2.1. OADP를 사용하여 애플리케이션을 다른 네임스페이스로 복원
OADP를 새 대상 네임스페이스 test-restore-application
에 사용하여 애플리케이션 백업을 복원합니다. 백업을 복원하려면 다음 예와 같이 복원 사용자 정의 리소스(CR)를 생성합니다. restore CR에서 소스 네임스페이스는 백업에 포함된 애플리케이션 네임스페이스를 나타냅니다. 그런 다음 프로젝트를 새 복원 네임스페이스로 변경하고 리소스를 확인하여 복원을 확인합니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- 복원할 애플리케이션의 백업이 있습니다.
절차
다음 예와 같이 복원 CR을 생성합니다.
복원 CR의 예
apiVersion: velero.io/v1 kind: Restore metadata: name: test-restore 1 namespace: openshift-adp spec: backupName: <backup_name> 2 restorePVs: true namespaceMapping: <application_namespace>: test-restore-application 3
다음 명령을 실행하여 복원 CR을 적용합니다.
$ oc apply -f <restore_cr_filename>
검증
다음 명령을 실행하여 복원이
완료된
단계에 있는지 확인합니다.$ oc describe restores.velero.io <restore_name> -n openshift-adp
다음 명령을 실행하여 복원된 네임스페이스
test-restore-application
로 변경합니다.$ oc project test-restore-application
다음 명령을 실행하여 영구 볼륨 클레임(pvc), 서비스(svc), 배포, 시크릿, 구성 맵과 같은 복원된 리소스를 확인합니다.
$ oc get pvc,svc,deployment,secret,configmap
출력 예
NAME STATUS VOLUME persistentvolumeclaim/mysql Bound pvc-9b3583db-...-14b86 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/mysql ClusterIP 172....157 <none> 3306/TCP 2m56s service/todolist ClusterIP 172.....15 <none> 8000/TCP 2m56s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/mysql 0/1 1 0 2m55s NAME TYPE DATA AGE secret/builder-dockercfg-6bfmd kubernetes.io/dockercfg 1 2m57s secret/default-dockercfg-hz9kz kubernetes.io/dockercfg 1 2m57s secret/deployer-dockercfg-86cvd kubernetes.io/dockercfg 1 2m57s secret/mysql-persistent-sa-dockercfg-rgp9b kubernetes.io/dockercfg 1 2m57s NAME DATA AGE configmap/kube-root-ca.crt 1 2m57s configmap/openshift-service-ca.crt 1 2m57s
4.5.3. 백업 중 자체 서명된 CA 인증서 포함
DPA(Data Protection Application)에 자체 서명된 CA(인증 기관) 인증서를 추가한 다음 애플리케이션을 백업할 수 있습니다. {odf-first}에서 제공하는 NooBaa 버킷에 백업을 저장합니다.
4.5.3.1. 애플리케이션 및 자체 서명된 CA 인증서 백업
{odf-short}에서 제공하는 s3.openshift-storage.svc
서비스는 자체 서명된 서비스 CA로 서명된 TLS(Transport Layer Security Protocol) 인증서를 사용합니다.
알 수 없는 기관 오류로 서명된 인증서
를 방지하려면 DataProtectionApplication
CR(사용자 정의 리소스)의 백업 스토리지 위치(BSL) 섹션에 자체 서명된 CA 인증서를 포함해야 합니다. 이 경우 다음 작업을 완료해야 합니다.
- OBC(오브젝트 버킷 클레임)를 생성하여 NooBaa 버킷을 요청합니다.
- 버킷 세부 정보를 추출합니다.
-
DataProtectionApplication
CR에 자체 서명된 CA 인증서를 포함합니다. - 애플리케이션을 백업합니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- {odf-short} Operator를 설치했습니다.
- 별도의 네임스페이스에서 실행 중인 데이터베이스가 있는 애플리케이션이 있습니다.
절차
다음 예와 같이 OBC 매니페스트를 생성하여 NooBaa 버킷을 요청합니다.
ObjectBucketClaim
CR의 예apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: test-obc 1 namespace: openshift-adp spec: storageClassName: openshift-storage.noobaa.io generateBucketName: test-backup-bucket 2
다음 명령을 실행하여 OBC를 생성합니다.
$ oc create -f <obc_file_name>
OBC를 생성할 때 {odf-short}은 오브젝트 버킷 클레임과 동일한 이름의
시크릿
및ConfigMap
을 생성합니다.보안
오브젝트에는 버킷 인증 정보가 포함되어 있으며ConfigMap
오브젝트에는 버킷에 액세스하는 데 필요한 정보가 포함되어 있습니다. 생성된 구성 맵에서 버킷 이름과 버킷 호스트를 가져오려면 다음 명령을 실행합니다.$ oc extract --to=- cm/test-obc 1
- 1
- OBC의 이름은
test-obc
입니다.
출력 예
# BUCKET_NAME backup-c20...41fd # BUCKET_PORT 443 # BUCKET_REGION # BUCKET_SUBREGION # BUCKET_HOST s3.openshift-storage.svc
보안
오브젝트에서 버킷 인증 정보를 가져오려면 다음 명령을 실행합니다.$ oc extract --to=- secret/test-obc
출력 예
# AWS_ACCESS_KEY_ID ebYR....xLNMc # AWS_SECRET_ACCESS_KEY YXf...+NaCkdyC3QPym
다음 예제 구성을 사용하여 오브젝트 버킷 자격 증명으로
cloud-credentials
파일을 생성합니다.[default] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
다음 명령을 실행하여
cloud-credentials
파일 콘텐츠를 사용하여cloud-credentials
시크릿을 생성합니다.$ oc create secret generic \ cloud-credentials \ -n openshift-adp \ --from-file cloud=cloud-credentials
다음 명령을 실행하여
openshift-service-ca.crt
구성 맵에서 서비스 CA 인증서를 추출합니다. 인증서를Base64
형식으로 인코딩하고 다음 단계에서 사용할 값을 기록해야 합니다.$ oc get cm/openshift-service-ca.crt \ -o jsonpath='{.data.service-ca\.crt}' | base64 -w0; echo
출력 예
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0... ....gpwOHMwaG9CRmk5a3....FLS0tLS0K
다음 예와 같이 버킷 이름 및 CA 인증서를 사용하여
DataProtectionApplication
CR 매니페스트 파일을 구성합니다.Example
DataProtectionApplication
CRapiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: oadp-backup namespace: openshift-adp spec: configuration: nodeAgent: enable: true uploaderType: kopia velero: defaultPlugins: - aws - openshift - csi defaultSnapshotMoveData: true backupLocations: - velero: config: profile: "default" region: noobaa s3Url: https://s3.openshift-storage.svc s3ForcePathStyle: "true" insecureSkipTLSVerify: "false" 1 provider: aws default: true credential: key: cloud name: cloud-credentials objectStorage: bucket: <bucket_name> 2 prefix: oadp caCert: <ca_cert> 3
다음 명령을 실행하여
DataProtectionApplication
CR을 생성합니다.$ oc apply -f <dpa_filename>
다음 명령을 실행하여
DataProtectionApplication
CR이 성공적으로 생성되었는지 확인합니다.$ oc get dpa -o yaml
출력 예
apiVersion: v1 items: - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: namespace: openshift-adp #...# spec: backupLocations: - velero: config: #...# status: conditions: - lastTransitionTime: "20....9:54:02Z" message: Reconcile complete reason: Complete status: "True" type: Reconciled kind: List metadata: resourceVersion: ""
다음 명령을 실행하여 백업 스토리지 위치(BSL)를 사용할 수 있는지 확인합니다.
$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 3s 15s true
다음 예제를 사용하여
Backup
CR을 구성합니다.Backup
CR의 예apiVersion: velero.io/v1 kind: Backup metadata: name: test-backup namespace: openshift-adp spec: includedNamespaces: - <application_namespace> 1
- 1
- 애플리케이션을 백업할 네임스페이스를 지정합니다.
다음 명령을 실행하여
Backup
CR을 생성합니다.$ oc apply -f <backup_cr_filename>
검증
다음 명령을 실행하여
Backup
오브젝트가Completed
단계에 있는지 확인합니다.$ oc describe backup test-backup -n openshift-adp
출력 예
Name: test-backup Namespace: openshift-adp # ....# Status: Backup Item Operations Attempted: 1 Backup Item Operations Completed: 1 Completion Timestamp: 2024-09-25T10:17:01Z Expiration: 2024-10-25T10:16:31Z Format Version: 1.1.0 Hook Status: Phase: Completed Progress: Items Backed Up: 34 Total Items: 34 Start Timestamp: 2024-09-25T10:16:31Z Version: 1 Events: <none>
4.6. OADP 설치 및 구성
4.6.1. OADP 설치 정보
클러스터 관리자는 OADP Operator를 설치하여 OADP(Data Protection)용 OpenShift API를 설치합니다. OADP Operator는 Velero 1.14 를 설치합니다.
OADP 1.0.4부터 모든 OADP 1.0.z 버전은 Migration Toolkit for Containers Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.
Kubernetes 리소스 및 내부 이미지를 백업하려면 다음 스토리지 유형 중 하나와 같은 백업 위치로 오브젝트 스토리지가 있어야 합니다.
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- Multicloud Object Gateway
- AWS S3 호환 오브젝트 스토리지(예: Multicloud Object Gateway 또는 MinIO)
개별 OADP 배포에 대해 동일한 네임스페이스 내에서 여러 백업 스토리지 위치를 구성할 수 있습니다.
달리 지정하지 않는 한 "NooBa"는 경량 오브젝트 스토리지를 제공하는 오픈 소스 프로젝트를 나타내며 "MCG(Multicloud Object Gateway)는 NooBaa의 Red Hat 배포를 나타냅니다.
MCG에 대한 자세한 내용은 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.
오브젝트 스토리지용 버킷 생성을 자동화하는 CloudStorage
API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
API는 CloudStorage 오브젝트를 사용하고 OADP에서 CloudStorage
CloudStorage
API를 사용하여 BackupStorageLocation
으로 사용할 S3 버킷을 자동으로 생성하도록 하는 경우 기술 프리뷰 기능입니다.
CloudStorage
API는 기존 S3 버킷을 지정하여 BackupStorageLocation
오브젝트를 수동으로 생성할 수 있도록 지원합니다. S3 버킷을 자동으로 생성하는 CloudStorage
API는 현재 AWS S3 스토리지에만 활성화됩니다.
스냅샷 또는 FSB(파일 시스템 백업)를 사용하여 PV(영구 볼륨)를 백업할 수 있습니다.
스냅샷을 사용하여 PV를 백업하려면 다음 클라우드 공급자 중 하나와 같이 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원하는 클라우드 공급자가 있어야 합니다.
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- CSI 스냅샷 지원 클라우드 공급자 (예: OpenShift Data Foundation)
OCP 4.11 이상에서 CSI 백업을 사용하려면 OADP 1.1.x 를 설치하십시오.
OADP 1.0.x 는 OCP 4.11 이상에서 CSI 백업을 지원하지 않습니다. OADP 1.0.x 에는 Velero 1.7이 포함되어 있으며 OCP 4.11 이상에는 존재하지 않는 API 그룹 snapshot.storage.k8s.io/v1beta1
이 예상됩니다.
클라우드 공급자가 스냅샷을 지원하지 않거나 스토리지가 NFS인 경우 오브젝트 스토리지에서 File System Backup: Kopia 또는 Restic을 사용하여 애플리케이션을 백업하여 애플리케이션을 백업할 수 있습니다.
기본 보안을 생성한 다음 데이터 보호 애플리케이션을 설치합니다.
4.6.1.1. AWS S3 호환 백업 스토리지 공급자
OADP는 다양한 백업 및 스냅샷 작업에 사용하기 위해 많은 오브젝트 스토리지 공급자와 호환됩니다. 여러 오브젝트 스토리지 공급자가 완전히 지원되며, 일부 오브젝트 스토리지 공급자는 지원되지만 작동하지 않으며 일부에는 알려진 제한 사항이 있습니다.
4.6.1.1.1. 지원되는 백업 스토리지 공급자
다음 AWS S3 호환 오브젝트 스토리지 공급자는 AWS 플러그인을 통해 백업 스토리지 위치로 사용하기 위해 OADP에서 완전히 지원합니다.
- MinIO
- MCG(Multicloud Object Gateway)
- AWS(Amazon Web Services) S3
- IBM Cloud® Object Storage S3
- Ceph RADOS Gateway(Ceph Object Gateway)
- Red Hat Container Storage
- {odf-full}
- GCP(Google Cloud Platform)
- Microsoft Azure
GCP(Google Cloud Platform) 및 Microsoft Azure에는 자체 Velero 오브젝트 저장소 플러그인이 있습니다.
4.6.1.1.2. 지원되지 않는 백업 스토리지 공급자
다음 AWS S3 호환 오브젝트 스토리지 공급자는 백업 스토리지 위치로 사용하기 위해 AWS 플러그인을 통해 Velero와 함께 작업하는 것으로 알려져 있지만 이는 지원되지 않으며 Red Hat에서 테스트하지 않았습니다.
- IBM Cloud
- Oracle Cloud
- DigitalOcean
- MCG(Multicloud Object Gateway)를 사용하여 설치하지 않는 한 NooBaa
- Tencent Cloud
- Ceph RADOS v12.2.7
- Quobyte
- Cloudian HyperStore
달리 지정하지 않는 한 "NooBa"는 경량 오브젝트 스토리지를 제공하는 오픈 소스 프로젝트를 나타내며 "MCG(Multicloud Object Gateway)는 NooBaa의 Red Hat 배포를 나타냅니다.
MCG에 대한 자세한 내용은 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.
4.6.1.1.3. 알려진 제한이 있는 백업 스토리지 공급자
다음 AWS S3 호환 오브젝트 스토리지 공급자는 제한된 기능 세트로 AWS 플러그인을 통해 Velero와 함께 작동하는 것으로 알려져 있습니다.
- Swift - 백업 스토리지의 백업 스토리지 위치로 사용하기 위해 작동하지만 파일 시스템 기반 볼륨 백업 및 복원에는 Restic과 호환되지 않습니다.
4.6.1.2. OpenShift Data Foundation에서 재해 복구를 위해 MCG(Multicloud Object Gateway) 구성
OpenShift Data Foundation에서 MCG 버킷 backupStorageLocation
에 클러스터 스토리지를 사용하는 경우 MCG를 외부 오브젝트 저장소로 구성합니다.
MCG를 외부 오브젝트 저장소로 구성하지 않으면 백업을 사용할 수 없게 될 수 있습니다.
달리 지정하지 않는 한 "NooBa"는 경량 오브젝트 스토리지를 제공하는 오픈 소스 프로젝트를 나타내며 "MCG(Multicloud Object Gateway)는 NooBaa의 Red Hat 배포를 나타냅니다.
MCG에 대한 자세한 내용은 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.
절차
- 하이브리드 또는 Multicloud용 스토리지 리소스 추가 에 설명된 대로 MCG를 외부 오브젝트 저장소로 구성합니다.
추가 리소스
4.6.1.3. OADP 업데이트 채널 정보
OADP Operator를 설치할 때 업데이트 채널을 선택합니다. 이 채널은 OADP Operator 및 수신하는 Velero에 대한 업그레이드를 결정합니다. 언제든지 채널을 변경할 수 있습니다.
다음 업데이트 채널을 사용할 수 있습니다.
-
stable 채널이 더 이상 사용되지 않습니다. stable 채널에는
OADP.v1.1.z
용 OADPClusterServiceVersion
및OADP.v1.0.z
의 이전 버전의 패치(z-stream 업데이트)가 포함되어 있습니다. - stable-1.0 채널은 더 이상 사용되지 않으며 지원되지 않습니다.
- stable-1.1 채널은 더 이상 사용되지 않으며 지원되지 않습니다.
- stable-1.2 채널은 더 이상 사용되지 않으며 지원되지 않습니다.
-
stable-1.3 채널에는 최신 OADP 1.3
ClusterServiceVersion
인OADP.v1.3.z
가 포함되어 있습니다. -
stable-1.4 채널에는 최신 OADP 1.4
ClusterServiceVersion
인OADP.v1.4.z
가 포함되어 있습니다.
자세한 내용은 OpenShift Operator 라이프 사이클 을 참조하십시오.
어떤 업데이트 채널을 사용할 수 있습니까?
-
stable 채널이 더 이상 사용되지 않습니다. stable 채널을 이미 사용 중인 경우
OADP.v1.1.z
에서 업데이트를 계속 받을 수 있습니다. - OADP 1.y를 설치하고 패치를 계속 받을 stable-1.y 업데이트 채널을 선택합니다. 이 채널을 선택하면 버전 1.y.z에 대한 모든 z-stream 패치가 제공됩니다.
언제 업데이트 채널을 전환해야합니까?
- OADP 1.y가 설치되어 있고 해당 y-stream용 패치를 받으려면 stable 업데이트 채널에서 stable -1.y 업데이트 채널로 전환해야 합니다. 그런 다음 버전 1.y.z에 대한 모든 z-stream 패치를 받게 됩니다.
- OADP 1.0이 설치되어 있고 OADP 1.1로 업그레이드하려는 경우 패치는 stable-1.0 업데이트 채널에서 stable-1.1 업데이트 채널로 전환해야 합니다. 그런 다음 버전 1.1.z에 대한 모든 z-stream 패치를 받게 됩니다.
- OADP 1. y 가 0보다 크고 OADP 1.0으로 전환하려면 OADP Operator를 제거한 다음 stable-1.0 업데이트 채널을 사용하여 다시 설치해야 합니다. 그런 다음 버전 1.0.z에 대한 모든 z-stream 패치를 받게 됩니다.
업데이트 채널을 전환하여 OADP 1.y에서 OADP 1.0으로 전환할 수 없습니다. Operator를 제거한 다음 다시 설치해야 합니다.
4.6.1.4. 여러 네임스페이스에 OADP 설치
여러 프로젝트 소유자가 자체 OADP 인스턴스를 관리할 수 있도록 OADP(OpenShift API for Data Protection)를 동일한 클러스터의 여러 네임스페이스에 설치할 수 있습니다. 이 사용 사례는 파일 시스템 백업(FSB) 및 CSI(Container Storage Interface)에서 검증되었습니다.
다음 추가 요구 사항을 사용하여 이 문서에 포함된 플랫폼별 절차에 따라 OADP의 각 인스턴스를 설치합니다.
- 동일한 클러스터에 있는 OADP의 모든 배포는 동일한 버전이어야 합니다(예: 1.1.4). 동일한 클러스터에 다른 버전의 OADP를 설치할 수 없습니다.
-
OADP의 개별 배포마다 고유한 인증 정보 세트 및 하나 이상의
BackupStorageLocation
구성이 있어야 합니다. 동일한 네임 스페이스 내에서 여러BackupStorageLocation
구성을 사용할 수도 있습니다. - 기본적으로 각 OADP 배포에는 네임스페이스에서 클러스터 수준 액세스 권한이 있습니다. OpenShift Container Platform 관리자는 보안 및 RBAC 설정을 주의 깊게 검토하고 각 OADP 인스턴스에 올바른 권한이 있는지 확인하기 위해 필요한 사항을 변경해야 합니다.
추가 리소스
4.6.1.5. 수집된 데이터를 기반으로 하는 Velero CPU 및 메모리 요구 사항
다음 권장 사항은 규모 및 성능 랩에서 수행된 성능 관찰을 기반으로 합니다. 백업 및 복원 리소스는 플러그인 유형, 해당 백업 또는 복원에 필요한 리소스 양, 해당 리소스와 관련된 PV(영구 볼륨)에 포함된 해당 데이터의 영향을 받을 수 있습니다.
4.6.1.5.1. 구성에 대한 CPU 및 메모리 요구 사항
구성 유형 | [1] 평균 사용량 | [2] 대규모 사용 | resourceTimeouts |
---|---|---|---|
CSI | Velero: cpu- 요청 200m, 제한 1000m memory - 256Mi 요청, 제한 1024Mi | Velero: CPU- 요청 200m, 제한 2000m memory- requests 256Mi, Limits 2048Mi | 해당 없음 |
Restic | [3] Restic: CPU- 요청 1000m, 제한 2000m memory - 16Gi 요청, 32Gi 제한 | [4] Restic: CPU - 2000m 요청, 8000m 제한 Memory - 16Gi 요청, 제한 40Gi | 900m |
[5] 데이터 관리 | 해당 없음 | 해당 없음 | 10m - 평균 사용량 60m - 대규모 사용 |
- 평균 사용량 - 대부분의 사용 상황에 대해 이러한 설정을 사용합니다.
- 대규모 사용 - 대규모 PV(500GB 사용), 다중 네임스페이스(100+) 또는 단일 네임스페이스(2000 pods+) 내의 여러 Pod 및 대규모 데이터 세트와 관련된 백업 및 복원을 위한 최적의 성능을 위해 이러한 설정을 사용합니다.
- Restic 리소스 사용량은 데이터 양 및 데이터 유형에 해당합니다. 예를 들어 많은 작은 파일 또는 대량의 데이터가 있으면 Restic에서 대량의 리소스를 사용할 수 있습니다. Velero 문서는 500m을 제공된 기본값으로 참조합니다. 대부분의 테스트에서는 1000m 제한이 있는 200m 요청을 찾았습니다. Velero 문서에서 인용한 대로 정확한 CPU 및 메모리 사용은 환경 제한 외에도 파일 및 디렉터리의 크기에 따라 달라집니다.
- CPU를 늘리면 백업 및 복원 시간 개선에 큰 영향을 미칩니다.
- Data Mover - Data Mover 기본 resourceTimeout은 10m입니다. 테스트 결과 대규모 PV(500GB 사용량)를 복원하려면 resourceTimeout을 60m로 늘려야 합니다.
가이드 전체에 나열된 리소스 요구 사항은 평균 사용량 전용입니다. 큰 용도의 경우 위의 표에 설명된 대로 설정을 조정합니다.
4.6.1.5.2. 대규모 사용을 위한 nodeagent CPU
테스트 결과 NodeAgent
CPU를 늘리면 OADP(OpenShift API for Data Protection)를 사용할 때 백업 및 복원 시간을 크게 향상시킬 수 있습니다.
Kopia의 적극적인 리소스 사용으로 인해 프로덕션 워크로드를 실행하는 노드의 프로덕션 환경에서 제한 없이 Kopia를 사용하지 않는 것이 좋습니다. 그러나 너무 낮은 제한으로 Kopia를 실행하면 CPU 제한 및 백업 속도가 느려지고 복원 상황이 발생합니다. 테스트 결과 20개 코어 및 32Gi 메모리가 있는 Kopia를 실행하면 100GB 이상의 데이터, 여러 네임스페이스 또는 2000개 이상의 Pod가 단일 네임스페이스에서 백업 및 복원 작업을 지원했습니다.
이러한 리소스 사양을 사용하여 CPU 제한 또는 메모리 포화 상태로 감지된 테스트입니다.
rook-ceph Pod에서 CPU 및 메모리 리소스 변경 절차에 따라 Ceph MDS Pod 에서 이러한 제한을 설정할 수 있습니다.
제한을 설정하려면 스토리지 클러스터 CR(사용자 정의 리소스)에 다음 행을 추가해야 합니다.
resources: mds: limits: cpu: "3" memory: 128Gi requests: cpu: "3" memory: 8Gi
4.6.2. OADP Operator 설치
OLM(Operator Lifecycle Manager)을 사용하여 OpenShift Container Platform 4.13에 OADP(OpenShift API for Data Protection) Operator를 설치할 수 있습니다.
OADP Operator는 Velero 1.14 를 설치합니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 로그인해야 합니다.
절차
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
- OADP Operator 를 선택하고 설치를 클릭합니다.
-
설치를 클릭하여
openshift-adp
프로젝트에서 Operator를 설치합니다. - Operators → 설치된 Operators 를 클릭하여 설치를 확인합니다.
4.6.2.1. OADP-Velero-OpenShift Container Platform 버전 관계
OADP 버전 | Velero 버전 | OpenShift Container Platform 버전 |
---|---|---|
1.1.0 | 4.9 이상 | |
1.1.1 | 4.9 이상 | |
1.1.2 | 4.9 이상 | |
1.1.3 | 4.9 이상 | |
1.1.4 | 4.9 이상 | |
1.1.5 | 4.9 이상 | |
1.1.6 | 4.11 이상 | |
1.1.7 | 4.11 이상 | |
1.2.0 | 4.11 이상 | |
1.2.1 | 4.11 이상 | |
1.2.2 | 4.11 이상 | |
1.2.3 | 4.11 이상 | |
1.3.0 | 4.10 - 4.15 | |
1.3.1 | 4.10 - 4.15 | |
1.3.2 | 4.10 - 4.15 | |
1.3.3 | 4.10 - 4.15 | |
1.4.0 | 4.14 이상 | |
1.4.1 | 4.14 이상 |
4.6.3. Amazon Web Services를 사용하여 데이터 보호를 위한 OpenShift API 구성
OADP Operator를 설치하여 AWS(Amazon Web Services)를 사용하여 OADP(OpenShift API for Data Protection)를 설치합니다. Operator는 Velero 1.14 를 설치합니다.
OADP 1.0.4부터 모든 OADP 1.0.z 버전은 Migration Toolkit for Containers Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.
Velero에 대해 AWS를 구성하고, 기본 보안
보안을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.
제한된 네트워크 환경에서 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.
4.6.3.1. Amazon Web Services 구성
OpenShift API for Data Protection(OADP)을 위해 AWS(Amazon Web Services)를 구성합니다.
사전 요구 사항
- AWS CLI가 설치되어 있어야 합니다.
절차
BUCKET
변수를 설정합니다.$ BUCKET=<your_bucket>
REGION
변수를 설정합니다.$ REGION=<your_region>
AWS S3 버킷을 생성합니다.
$ aws s3api create-bucket \ --bucket $BUCKET \ --region $REGION \ --create-bucket-configuration LocationConstraint=$REGION 1
- 1
us-east-1
은LocationConstraint
를 지원하지 않습니다. 리전이us-east-1
인 경우--create-bucket-configuration LocationConstraint=$REGION
을 생략합니다.
IAM 사용자를 생성합니다.
$ aws iam create-user --user-name velero 1
- 1
- Velero를 사용하여 여러 S3 버킷이 있는 여러 클러스터를 백업하려면 각 클러스터에 대해 고유한 사용자 이름을 생성합니다.
velero-policy.json
파일을 생성합니다.$ cat > velero-policy.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeVolumes", "ec2:DescribeSnapshots", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateSnapshot", "ec2:DeleteSnapshot" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:DeleteObject", "s3:PutObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::${BUCKET}/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation", "s3:ListBucketMultipartUploads" ], "Resource": [ "arn:aws:s3:::${BUCKET}" ] } ] } EOF
정책을 연결하여
velero
사용자에게 최소한의 필요한 권한을 부여합니다.$ aws iam put-user-policy \ --user-name velero \ --policy-name velero \ --policy-document file://velero-policy.json
velero
사용자에 대한 액세스 키를 생성합니다.$ aws iam create-access-key --user-name velero
출력 예
{ "AccessKey": { "UserName": "velero", "Status": "Active", "CreateDate": "2017-07-31T22:24:41.576Z", "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>, "AccessKeyId": <AWS_ACCESS_KEY_ID> } }
credentials-velero
파일을 생성합니다.$ cat << EOF > ./credentials-velero [default] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY> EOF
Data Protection Application을 설치하기 전에
credentials-velero
파일을 사용하여 AWS에 대한Secret
오브젝트를 생성합니다.
4.6.3.2. 백업 및 스냅샷 위치 및 시크릿 정보
DataProtectionApplication
CR(사용자 정의 리소스)에 백업 및 스냅샷 위치와 해당 시크릿을 지정합니다.
백업 위치
AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.
Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.
스냅샷 위치
클라우드 공급자의 기본 스냅샷 API를 사용하여 영구 볼륨을 백업하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.
CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass
CR을 생성하므로 스냅샷 위치를 지정할 필요가 없습니다.
FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.
보안
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 Secret
을 생성합니다.
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.
-
백업
위치에
대한 사용자 지정 보안(DataProtectionApplication
CR에서 지정) -
DataProtectionApplication
CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
데이터 보호 애플리케이션에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다.
설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 Secret
을 생성할 수 있습니다.
4.6.3.2.1. 기본 보안 생성
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 보안을 생성합니다.
Secret
의 기본 이름은 cloud-credentials
입니다.
DataProtectionApplication
사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret
이 지정되지 않은 경우 기본 이름이 사용됩니다.
설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 이름으로 Secret
을 생성할 수 있습니다.
사전 요구 사항
- 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
- Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
-
적절한 형식으로 오브젝트 스토리지에 대한
credentials-velero
파일을 생성해야 합니다.
절차
기본 이름으로 보안을 생성합니다.
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
Data Protection Application을 설치할 때 DataProtectionApplication
CR의 spec.backupLocations.credential
블록에서 Secret
을 참조합니다.
4.6.3.2.2. 다양한 자격 증명에 대한 프로필 생성
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 credentials-velero
파일에 별도의 프로필을 생성합니다.
그런 다음 Secret
오브젝트를 생성하고 DataProtectionApplication
CR(사용자 정의 리소스)에 프로필을 지정합니다.
절차
다음 예제와 같이 백업 및 스냅샷 위치에 대한 별도의 프로필이 있는
credentials-velero
파일을 생성합니다.[backupStorage] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY> [volumeSnapshot] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
credentials-velero
파일을 사용하여Secret
오브젝트를 생성합니다.$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero 1
다음 예제와 같이
DataProtectionApplication
CR에 프로필을 추가합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket_name> prefix: <prefix> config: region: us-east-1 profile: "backupStorage" credential: key: cloud name: cloud-credentials snapshotLocations: - velero: provider: aws config: region: us-west-2 profile: "volumeSnapshot"
4.6.3.2.3. AWS를 사용하여 백업 스토리지 위치 구성
다음 예제 절차에 표시된 대로 AWS 백업 스토리지 위치(BSL)를 구성할 수 있습니다.
사전 요구 사항
- AWS를 사용하여 오브젝트 스토리지 버킷을 생성했습니다.
- OADP Operator가 설치되어 있습니다.
절차
사용 사례에 적용할 수 있는 값으로 BSL CR(사용자 정의 리소스)을 구성합니다.
백업 스토리지 위치
apiVersion: oadp.openshift.io/v1alpha1 kind: BackupStorageLocation metadata: name: default namespace: openshift-adp spec: provider: aws 1 objectStorage: bucket: <bucket_name> 2 prefix: <bucket_prefix> 3 credential: 4 key: cloud 5 name: cloud-credentials 6 config: region: <bucket_region> 7 s3ForcePathStyle: "true" 8 s3Url: <s3_url> 9 publicUrl: <public_s3_url> 10 serverSideEncryption: AES256 11 kmsKeyId: "50..c-4da1-419f-a16e-ei...49f" 12 customerKeyEncryptionFile: "/credentials/customer-key" 13 signatureVersion: "1" 14 profile: "default" 15 insecureSkipTLSVerify: "true" 16 enableSharedConfig: "true" 17 tagging: "" 18 checksumAlgorithm: "CRC32" 19
- 1 1
- 오브젝트 저장소 플러그인의 이름입니다. 이 예제에서 플러그인은
aws
입니다. 이 필드는 필수입니다. - 2
- 백업을 저장할 버킷의 이름입니다. 이 필드는 필수입니다.
- 3
- 백업을 저장할 버킷 내 접두사입니다. 이 필드는 선택 사항입니다.
- 4
- 백업 스토리지 위치에 대한 자격 증명입니다. 사용자 지정 인증 정보를 설정할 수 있습니다. 사용자 정의 인증 정보가 설정되지 않은 경우 기본 인증 정보의 시크릿이 사용됩니다.
- 5
- 시크릿 인증 정보 데이터 내의
키
입니다. - 6
- 인증 정보가 포함된 시크릿의 이름입니다.
- 7
- 버킷이 있는 AWS 리전입니다. s3ForcePathStyle이 false인 경우 선택 사항입니다.
- 8
- 가상 호스트 버킷 주소 지정 대신 경로 스타일 주소 지정을 사용할지 여부를 결정하는 부울 플래그입니다. MinIO 또는 NooBaa와 같은 스토리지 서비스를 사용하는 경우
true
로 설정합니다. 이 필드는 선택적 필드입니다. 기본값은false
입니다. - 9
- 명시적성을 위해 AWS S3 URL을 지정할 수 있습니다. 이 필드는 주로 MinIO 또는 NooBaa와 같은 스토리지 서비스를 위한 것입니다. 이 필드는 선택적 필드입니다.
- 10
- 이 필드는 주로 MinIO 또는 NooBaa와 같은 스토리지 서비스에 사용됩니다. 이 필드는 선택적 필드입니다.
- 11
- 오브젝트 업로드에 사용할 서버 측 암호화 알고리즘의 이름입니다(예:
AES256
). 이 필드는 선택적 필드입니다. - 12
- AWS KMS 키 ID를 지정합니다. 예제에 표시된 대로 별칭(예:
alias/<KMS-key-alias-name
> ) 또는 전체ARN
을 지정하여 S3에 저장된 백업의 암호화를 활성화할 수 있습니다.kmsKeyId
는customerKeyEncryptionFile
과 함께 사용할 수 없습니다. 이 필드는 선택적 필드입니다. - 13
SSE-C
고객 키가 있는 파일을 지정하여 S3에 저장된 백업의 고객 키 암호화를 활성화합니다. 파일에는 32바이트 문자열이 포함되어야 합니다.customerKeyEncryptionFile
필드는velero
컨테이너 내에서 마운트된 시크릿을 가리킵니다.velero
cloud-credentials
시크릿에 다음 키-값 쌍을 추가합니다.customer-key: <your_b64_encoded_32byte_string>
.customerKeyEncryptionFile
필드는kmsKeyId
필드와 함께 사용할 수 없습니다. 기본값은 빈 문자열(""
)이며 이는SSE-C
가 비활성화되어 있습니다. 이 필드는 선택적 필드입니다.- 14
- 서명된 URL을 생성하는 데 사용되는 서명 알고리즘의 버전입니다. 서명된 URL을 사용하여 백업을 다운로드하거나 로그를 가져옵니다. 유효한 값은
1
및4
입니다. 기본 버전은4
입니다. 이 필드는 선택적 필드입니다. - 15
- 인증 정보 파일에 있는 AWS 프로필의 이름입니다. 기본값은
default
입니다. 이 필드는 선택적 필드입니다. - 16
- 오브젝트 저장소에 연결할 때 TLS 인증서를 확인하지 않으려면
insecureSkipTLSVerify
필드를true
로 설정합니다(예: MinIO를 사용한 자체 서명 인증서의 경우).true
로 설정하는 것은 중간자 공격에 취약하며 프로덕션 워크로드에는 권장되지 않습니다. 기본값은false
입니다. 이 필드는 선택적 필드입니다. - 17
- 인증 정보 파일을 공유 구성 파일로 로드하려면
enableSharedConfig
필드를true
로 설정합니다. 기본값은false
입니다. 이 필드는 선택적 필드입니다. - 18
- AWS S3 오브젝트에 주석을 달 태그를 지정합니다. 키-값 쌍으로 태그를 지정합니다. 기본값은 빈 문자열(
""
)입니다. 이 필드는 선택적 필드입니다. - 19
- 오브젝트를 S3에 업로드하는 데 사용할 체크섬 알고리즘을 지정합니다. 지원되는 값은 CRC32 ,
CRC32
CSHA1
,SHA256
입니다. 필드를 빈 문자열(""
)으로 설정하면 체크섬 검사를 건너뜁니다. 기본값은CRC32
입니다. 이 필드는 선택적 필드입니다.
4.6.3.2.4. 추가 데이터 보안을 위한 OADP SSE-C 암호화 키 생성
AWS(Amazon Web Services) S3는 Amazon S3 관리 키(SSE-S3)를 Amazon S3의 모든 버킷의 기본 암호화 수준으로 적용하여 서버 측 암호화를 적용합니다.
OADP(OpenShift API for Data Protection)는 클러스터에서 스토리지로 데이터를 전송할 때 SSL/TLS, HTTPS, velero-repo-credentials
시크릿을 사용하여 데이터를 암호화합니다. AWS 인증 정보가 손실되거나 도난된 경우 백업 데이터를 보호하려면 추가 암호화 계층을 적용합니다.
velero-plugin-for-aws 플러그인은 몇 가지 추가 암호화 방법을 제공합니다. 해당 구성 옵션을 검토하고 추가 암호화를 구현하는 것이 좋습니다.
SSE-C(고객 제공 키)와 함께 서버 측 암호화를 사용하여 고유한 암호화 키를 저장할 수 있습니다. 이 기능은 AWS 인증 정보가 노출되는 경우 추가 보안을 제공합니다.
암호화 키를 안전하고 안전한 방식으로 저장해야 합니다. 암호화 키가 없는 경우 암호화된 데이터 및 백업을 복구할 수 없습니다.
사전 요구 사항
OADP 마운트를
/credentials
의 Velero pod에 포함하는 시크릿을 만들려면 cloud-credentials :cloud-credentials
에 다음과 같은 기본 시크릿 이름을 사용하고 다음 라벨 중 하나를 비워 둡니다.-
dpa.spec.backupLocations[].velero.credential
dpa.spec.snapshotLocations[].velero.credential
다음은 알려진 문제에 대한 해결 방법입니다. https://issues.redhat.com/browse/OADP-3971.
-
다음 절차에는 인증 정보를 지정하지 않는 spec:backupLocations
블록의 예가 포함되어 있습니다. 이 예제에서는 OADP 시크릿 마운트를 트리거합니다.
-
cloud-credentials
와 다른 이름으로 백업 위치가 필요한 경우 인증 정보 이름이 포함되지 않은 다음 예제의 스냅샷 위치를 추가해야 합니다. 예제에는 인증 정보 이름이 없기 때문에 스냅샷 위치는cloud-credentials
를 스냅샷 생성의 시크릿으로 사용합니다.
인증 정보가 지정되지 않은 DPA의 스냅샷 위치 예
snapshotLocations: - velero: config: profile: default region: <region> provider: aws # ...
절차
SSE-C 암호화 키를 생성합니다.
임의의 번호를 생성하고 다음 명령을 실행하여
sse.key
라는 파일로 저장합니다.$ dd if=/dev/urandom bs=1 count=32 > sse.key
Base64를 사용하여
sse.key
를 인코딩하고 다음 명령을 실행하여 결과를sse_encoded.key
라는 파일로 저장합니다.$ cat sse.key | base64 > sse_encoded.key
다음 명령을 실행하여
sse_encoded.key
라는 파일을customer-key
라는 새 파일에 연결합니다.$ ln -s sse_encoded.key customer-key
OpenShift Container Platform 시크릿을 생성합니다.
처음에 OADP를 설치하고 구성하는 경우 다음 명령을 실행하여 AWS 인증 정보 및 암호화 키 시크릿을 동시에 생성합니다.
$ oc create secret generic cloud-credentials --namespace openshift-adp --from-file cloud=<path>/openshift_aws_credentials,customer-key=<path>/sse_encoded.key
기존 설치를 업데이트하는 경우 다음 예와 같이
DataProtectionApplication
CR 매니페스트의cloud-credential
시크릿
블록 값을 편집합니다.apiVersion: v1 data: cloud: W2Rfa2V5X2lkPSJBS0lBVkJRWUIyRkQ0TlFHRFFPQiIKYXdzX3NlY3JldF9hY2Nlc3Nfa2V5P<snip>rUE1mNWVSbTN5K2FpeWhUTUQyQk1WZHBOIgo= customer-key: v+<snip>TFIiq6aaXPbj8dhos= kind: Secret # ...
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의backupLocations
블록에서customerKeyEncryptionFile
속성 값을 편집합니다.spec: backupLocations: - velero: config: customerKeyEncryptionFile: /credentials/customer-key profile: default # ...
주의기존 설치에서 시크릿 인증 정보를 올바르게 마운트하려면 Velero 포드를 다시 시작해야 합니다.
설치가 완료되었으며 OpenShift Container Platform 리소스를 백업하고 복원할 수 있습니다. AWS S3 스토리지에 저장된 데이터는 새 키로 암호화되며 추가 암호화 키 없이는 AWS S3 콘솔 또는 API에서 다운로드할 수 없습니다.
검증
추가 키를 포함하지 않고 암호화된 파일을 다운로드할 수 없는지 확인하려면 테스트 파일을 만들고 업로드한 다음 다운로드하려고 합니다.
다음 명령을 실행하여 테스트 파일을 생성합니다.
$ echo "encrypt me please" > test.txt
다음 명령을 실행하여 테스트 파일을 업로드합니다.
$ aws s3api put-object \ --bucket <bucket> \ --key test.txt \ --body test.txt \ --sse-customer-key fileb://sse.key \ --sse-customer-algorithm AES256
파일을 다운로드해 보십시오. Amazon 웹 콘솔 또는 터미널에서 다음 명령을 실행합니다.
$ s3cmd get s3://<bucket>/test.txt test.txt
파일이 추가 키로 암호화되므로 다운로드에 실패합니다.
다음 명령을 실행하여 추가 암호화 키로 파일을 다운로드합니다.
$ aws s3api get-object \ --bucket <bucket> \ --key test.txt \ --sse-customer-key fileb://sse.key \ --sse-customer-algorithm AES256 \ downloaded.txt
다음 명령을 실행하여 파일 내용을 읽습니다.
$ cat downloaded.txt
출력 예
encrypt me please
추가 리소스
다른 명령을 실행하여 Velcro로 백업된 추가 암호화 키가 있는 파일을 다운로드할 수도 있습니다. Velero에서 지원하는 파일은 SSE-C 암호화 키로 파일 다운로드를 참조하십시오.
4.6.3.2.4.1. Velero에서 지원하는 파일의 SSE-C 암호화 키로 파일 다운로드
SSE-C 암호화 키를 확인하는 경우 Velcro로 백업된 파일의 추가 암호화 키로 파일을 다운로드할 수도 있습니다.
절차
- 다음 명령을 실행하여 Velero에서 백업한 파일의 추가 암호화 키로 파일을 다운로드합니다.
$ aws s3api get-object \ --bucket <bucket> \ --key velero/backups/mysql-persistent-customerkeyencryptionfile4/mysql-persistent-customerkeyencryptionfile4.tar.gz \ --sse-customer-key fileb://sse.key \ --sse-customer-algorithm AES256 \ --debug \ velero_download.tar.gz
4.6.3.3. 데이터 보호 애플리케이션 구성
Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.
4.6.3.3.1. Velero CPU 및 메모리 리소스 할당 설정
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero
Pod에 대한 CPU 및 메모리 리소스 할당을 설정합니다.
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.configuration.velero.podConfig.ResourceAllocations
블록의 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node_selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.
Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.
nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.
4.6.3.3.2. 자체 서명된 CA 인증서 활성화
알 수 없는 기관 오류로 서명된 인증서를 방지하려면
활성화해야 합니다.
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 자체 서명된 CA 인증서를
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
DataProtectionApplication
CR 매니페스트의spec.backupLocations.velero.objectStorage.caCert
매개변수 및spec.backupLocations.velero.config
매개변수를 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.6.3.3.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용
별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다. OpenShift CLI(
oc
)가 설치되어 있어야 합니다.aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
다음 명령을 실행하여 별칭이 작동하는지 확인합니다.
예제
$ velero version Client: Version: v1.12.1-OADP Git commit: - Server: Version: v1.12.1-OADP
이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.
$ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}') $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
$ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
백업 로그를 가져오려면 다음 명령을 실행합니다.
$ velero backup logs <backup_name> --cacert /tmp/<your_cacert.txt>
이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.
-
Velero 포드가 다시 시작되면
/tmp/your-cacert.txt
파일이 사라지고 이전 단계의 명령을 다시 실행하여/tmp/your-cacert.txt
파일을 다시 생성해야 합니다. 다음 명령을 실행하여
/tmp/your-cacert.txt
파일이 여전히 있는지 확인할 수 있습니다.$ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt" /tmp/your-cacert.txt
향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.
4.6.3.4. 데이터 보호 애플리케이션 설치
DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application
)를 설치합니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
- 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
-
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하는 경우 기본 이름
cloud-credentials
를 사용하여 보안을 생성해야 합니다. 백업 및 스냅샷 위치에서 다른 자격 증명을 사용하는 경우 백업 및 스냅샷 위치 자격 증명에 대한 별도의 프로필이 포함된 기본 이름
cloud-credentials
로시크릿
을 생성해야 합니다.참고설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈
credentials-velero
파일을 사용하여 기본Secret
을 생성할 수 있습니다. 기본Secret
이 없는 경우 설치가 실패합니다.
절차
- Operators → 설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
- 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
YAML 보기를 클릭하고
DataProtectionApplication
매니페스트의 매개변수를 업데이트합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp 1 spec: configuration: velero: defaultPlugins: - openshift 2 - aws resourceTimeout: 10m 3 nodeAgent: 4 enable: true 5 uploaderType: kopia 6 podConfig: nodeSelector: <node_selector> 7 backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket_name> 8 prefix: <prefix> 9 config: region: <region> profile: "default" s3ForcePathStyle: "true" 10 s3Url: <s3_url> 11 credential: key: cloud name: cloud-credentials 12 snapshotLocations: 13 - name: default velero: provider: aws config: region: <region> 14 profile: "default" credential: key: cloud name: cloud-credentials 15
- 1
- OADP의 기본 네임스페이스는
openshift-adp
입니다. 네임스페이스는 변수이며 구성 가능합니다. - 2
openshift
플러그인은 필수입니다.- 3
- Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
- 4
- 관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
- 5
nodeAgent
를 활성화하고 파일 시스템 백업을 수행하려면 이 값을true
로 설정합니다.- 6
- 업로드로
kopia
또는restic
을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다.nodeAgent
는 데몬 세트를 배포합니다. 즉,nodeAgent
Pod가 각 작동 중인 노드에서 실행됩니다.Backup
CR에spec.defaultVolumesToFsBackup: true
를 추가하여 파일 시스템 백업을 구성할 수 있습니다. - 7
- Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
- 8
- 버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
- 9
- 버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
- 10
- S3 오브젝트에 대해 경로 스타일 URL을 강제 적용할지 여부를 지정합니다(부울). AWS S3에는 필요하지 않습니다. S3 호환 스토리지에만 필요합니다.
- 11
- 백업을 저장하는 데 사용 중인 오브젝트 저장소의 URL을 지정합니다. AWS S3에는 필요하지 않습니다. S3 호환 스토리지에만 필요합니다.
- 12
- 생성한
Secret
오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본값cloud-credentials
가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다. - 13
- CSI 스냅샷 또는 FSB(File System Backup)를 사용하여 PV를 백업하지 않는 한 스냅샷 위치를 지정합니다.
- 14
- 스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.
- 15
- 생성한
Secret
오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본값cloud-credentials
가 사용됩니다. 사용자 지정 이름을 지정하면 스냅샷 위치에 사용자 지정 이름이 사용됩니다. 백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우credentials-velero
파일에 별도의 프로필을 생성합니다.
- 생성을 클릭합니다.
검증
다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다.
$ oc get all -n openshift-adp
출력 예
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
다음 명령을 실행하여 DPA(
DataProtectionApplication
)가 조정되었는지 확인합니다.$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
출력 예
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
유형이
Reconciled
으로 설정되어 있는지 확인합니다. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여
PHASE
가 사용
가능한지 확인합니다.$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
4.6.3.4.1. 노드 에이전트 및 노드 라벨 구성
OADP의 DPA는 nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.
지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다.
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
다음 예제는 nodeSelector
의 안티 패턴이며 'node-role.kubernetes.io/infra: ""'
및 'node-role.kubernetes.io/worker: ""'
둘 다 노드에 있지 않으면 작동하지 않습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.6.3.5. MD5 체크섬 알고리즘을 사용하여 백업 스토리지 위치 구성
DPA(Data Protection Application)에서 백업 스토리지 위치(BSL)를 구성하여 Amazon Simple Storage Service(Amazon S3) 및 S3 호환 스토리지 공급자 모두에 MD5 체크섬 알고리즘을 사용할 수 있습니다. 체크섬 알고리즘은 Amazon S3에 오브젝트를 업로드하고 다운로드하는 체크섬을 계산합니다. 다음 옵션 중 하나를 사용하여 DPA의 spec.backupLocations.velero.config.checksumAlgorithm
섹션에서 checksumAlgorithm
필드를 설정할 수 있습니다.
-
CRC32
-
CRC32C
-
SHA1
-
SHA256
checksumAlgorithm
필드를 빈 값으로 설정하여 MD5 체크섬 검사를 건너뛸 수도 있습니다.
checksumAlgorithm
필드의 값을 설정하지 않으면 기본값은 CRC32
로 설정됩니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- Amazon S3 또는 S3 호환 오브젝트 스토리지를 백업 위치로 구성했습니다.
절차
다음 예와 같이 DPA에서 BSL을 구성합니다.
데이터 보호 애플리케이션 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-dpa namespace: openshift-adp spec: backupLocations: - name: default velero: config: checksumAlgorithm: "" 1 insecureSkipTLSVerify: "true" profile: "default" region: <bucket_region> s3ForcePathStyle: "true" s3Url: <bucket_url> credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> prefix: velero provider: aws configuration: velero: defaultPlugins: - openshift - aws - csi
- 1
checksumAlgorithm
을 지정합니다. 이 예에서는checksumAlgorithm
필드가 빈 값으로 설정됩니다. 다음 목록에서 옵션을 선택할 수 있습니다. CRC32 ,CRC32
CSHA1
,SHA256
.
If you are using Noobaa as the object storage provider, and you do not set the spec.backupLocations.velero.config.checksumAlgorithm
field in the DPA, an empty value of checksumAlgorithm
is added to the BSL configuration.
빈 값은 DPA를 사용하여 생성된 BSL에만 추가됩니다. 이 값은 다른 방법을 사용하여 BSL을 생성하는 경우 추가되지 않습니다.
4.6.3.6. 클라이언트 버스트 및 QPS 설정으로 DPA 구성
버스트 설정은 제한을 적용하기 전에 velero
서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.
버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero
서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burst
및 dpa.configuration.velero.client-qps
필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
절차
다음 예와 같이 DPA에서
client-burst
및client-qps
필드를 구성합니다.데이터 보호 애플리케이션 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-dpa namespace: openshift-adp spec: backupLocations: - name: default velero: config: insecureSkipTLSVerify: "true" profile: "default" region: <bucket_region> s3ForcePathStyle: "true" s3Url: <bucket_url> credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: restic velero: client-burst: 500 1 client-qps: 300 2 defaultPlugins: - openshift - aws - kubevirt
4.6.3.7. 두 개 이상의 BSL로 DPA 구성
DPA를 두 개 이상의 BSL로 구성하고 클라우드 공급자가 제공하는 자격 증명을 지정할 수 있습니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성해야 합니다.
절차
두 개 이상의 BSL로 DPA를 구성합니다. 다음 예제를 참조하십시오.
DPA 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication #... backupLocations: - name: aws 1 velero: provider: aws default: true 2 objectStorage: bucket: <bucket_name> 3 prefix: <prefix> 4 config: region: <region_name> 5 profile: "default" credential: key: cloud name: cloud-credentials 6 - name: odf 7 velero: provider: aws default: false objectStorage: bucket: <bucket_name> prefix: <prefix> config: profile: "default" region: <region_name> s3Url: <url> 8 insecureSkipTLSVerify: "true" s3ForcePathStyle: "true" credential: key: cloud name: <custom_secret_name_odf> 9 #...
- 1
- 첫 번째 BSL의 이름을 지정합니다.
- 2
- 이 매개 변수는 이 BSL이 기본 BSL임을 나타냅니다.
Backup CR
에 BSL이 설정되지 않은 경우 기본 BSL이 사용됩니다. 하나의 BSL만 기본값으로 설정할 수 있습니다. - 3
- 버킷 이름을 지정합니다.
- 4
- Velero 백업의 접두사를 지정합니다(예:
velero
). - 5
- 버킷의 AWS 리전을 지정합니다.
- 6
- 생성한 기본
Secret
오브젝트의 이름을 지정합니다. - 7
- 두 번째 BSL의 이름을 지정합니다.
- 8
- S3 끝점의 URL을 지정합니다.
- 9
시크릿
의 올바른 이름을 지정합니다(예:custom_secret_name_odf
).Secret
이름을 지정하지 않으면 기본 이름이 사용됩니다.
백업 CR에 사용할 BSL을 지정합니다. 다음 예제를 참조하십시오.
백업 CR의 예
apiVersion: velero.io/v1 kind: Backup # ... spec: includedNamespaces: - <namespace> 1 storageLocation: <backup_storage_location> 2 defaultVolumesToFsBackup: true
4.6.3.7.1. DataProtectionApplication CR에서 CSI 활성화
CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication
CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.
사전 요구 사항
- 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
기본 플러그인을 추가합니다.
4.6.3.7.2. DataProtectionApplication에서 노드 에이전트 비활성화
백업에 Restic
,Kopia
또는 DataMover
를 사용하지 않는 경우 DataProtectionApplication
CR(사용자 정의 리소스)에서 nodeAgent
필드를 비활성화할 수 있습니다. nodeAgent
를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.
절차
nodeAgent
를 비활성화하려면enable
플래그를false
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: false 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 비활성화합니다.
nodeAgent
를 활성화하려면enable
플래그를true
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: true 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 활성화합니다.
DataProtectionApplication
CR에서 nodeAgent
필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.
4.6.4. IBM Cloud를 사용하여 OpenShift API for Data Protection 구성
IBM Cloud 클러스터에 OpenShift API for Data Protection(OADP) Operator를 설치하여 클러스터에서 애플리케이션을 백업 및 복원합니다. 백업을 저장하도록 IBM Cloud Object Storage(COS)를 구성합니다.
4.6.4.1. COS 인스턴스 구성
OADP 백업 데이터를 저장하기 위해 IBM COS(Cloud Object Storage) 인스턴스를 생성합니다. COS 인스턴스를 생성한 후 HMAC
서비스 자격 증명을 구성합니다.
사전 요구 사항
- IBM Cloud Platform 계정이 있습니다.
- IBM Cloud CLI 를 설치했습니다.
- IBM Cloud에 로그인되어 있습니다.
절차
다음 명령을 실행하여 IBM Cloud Object Storage(COS) 플러그인을 설치합니다.
$ ibmcloud plugin install cos -f
다음 명령을 실행하여 버킷 이름을 설정합니다.
$ BUCKET=<bucket_name>
다음 명령을 실행하여 버킷 리전을 설정합니다.
$ REGION=<bucket_region> 1
- 1
- 버킷 리전을 지정합니다(예:
eu-gb
).
다음 명령을 실행하여 리소스 그룹을 생성합니다.
$ ibmcloud resource group-create <resource_group_name>
다음 명령을 실행하여 대상 리소스 그룹을 설정합니다.
$ ibmcloud target -g <resource_group_name>
다음 명령을 실행하여 대상 리소스 그룹이 올바르게 설정되었는지 확인합니다.
$ ibmcloud target
출력 예
API endpoint: https://cloud.ibm.com Region: User: test-user Account: Test Account (fb6......e95) <-> 2...122 Resource group: Default
예제 출력에서 리소스 그룹은
Default
로 설정됩니다.다음 명령을 실행하여 리소스 그룹 이름을 설정합니다.
$ RESOURCE_GROUP=<resource_group> 1
- 1
- 리소스 그룹 이름을 지정합니다(예:
"default"
).
다음 명령을 실행하여 IBM Cloud
service-instance
리소스를 생성합니다.$ ibmcloud resource service-instance-create \ <service_instance_name> \1 <service_name> \2 <service_plan> \3 <region_name> 4
명령 예
$ ibmcloud resource service-instance-create test-service-instance cloud-object-storage \ 1 standard \ global \ -d premium-global-deployment 2
다음 명령을 실행하여 서비스 인스턴스 ID를 추출합니다.
$ SERVICE_INSTANCE_ID=$(ibmcloud resource service-instance test-service-instance --output json | jq -r '.[0].id')
다음 명령을 실행하여 COS 버킷을 생성합니다.
$ ibmcloud cos bucket-create \// --bucket $BUCKET \// --ibm-service-instance-id $SERVICE_INSTANCE_ID \// --region $REGION
$BUCKET
,$SERVICE_INSTANCE_ID
및$REGION
과 같은 변수는 이전에 설정한 값으로 교체됩니다.다음 명령을 실행하여
HMAC
자격 증명을 만듭니다.$ ibmcloud resource service-key-create test-key Writer --instance-name test-service-instance --parameters {\"HMAC\":true}
HMAC
인증 정보에서 액세스 키 ID와 시크릿 액세스 키를 추출하여credentials-velero
파일에 저장합니다.credentials-velero
파일을 사용하여 백업 스토리지 위치에 대한시크릿을
생성할 수 있습니다. 다음 명령을 실행합니다.$ cat > credentials-velero << __EOF__ [default] aws_access_key_id=$(ibmcloud resource service-key test-key -o json | jq -r '.[0].credentials.cos_hmac_keys.access_key_id') aws_secret_access_key=$(ibmcloud resource service-key test-key -o json | jq -r '.[0].credentials.cos_hmac_keys.secret_access_key') __EOF__
4.6.4.2. 기본 보안 생성
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 보안을 생성합니다.
DataProtectionApplication
사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret
이 지정되지 않은 경우 기본 이름이 사용됩니다.
설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 이름으로 Secret
을 생성할 수 있습니다.
사전 요구 사항
- 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
- Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
-
적절한 형식으로 오브젝트 스토리지에 대한
credentials-velero
파일을 생성해야 합니다.
절차
기본 이름으로 보안을 생성합니다.
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
Data Protection Application을 설치할 때 DataProtectionApplication
CR의 spec.backupLocations.credential
블록에서 Secret
을 참조합니다.
4.6.4.3. 다른 인증 정보의 보안 생성
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 Secret
오브젝트를 생성해야 합니다.
-
사용자 지정 이름을 사용한 백업 위치
시크릿
. 사용자 지정 이름은DataProtectionApplication
CR(사용자 정의 리소스)의spec.backupLocations
블록에 지정됩니다. -
스냅샷 위치
보안
(기본값:cloud-credentials
)입니다. 이보안은
DataProtectionApplication
CR에 지정되지 않습니다.
절차
-
클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한
credentials-velero
파일을 생성합니다. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
-
오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한
credentials-velero
파일을 생성합니다. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.
$ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
다음 예제와 같이 사용자 지정 이름으로
Secret
을DataProtectionApplication
CR에 추가합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - velero: provider: <provider> default: true credential: key: cloud name: <custom_secret> 1 objectStorage: bucket: <bucket_name> prefix: <prefix>
- 1
- 사용자 지정 이름으로 백업 위치 보안.
4.6.4.4. 데이터 보호 애플리케이션 설치
DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application
)를 설치합니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
- 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하는 경우 기본 이름
cloud-credentials
를 사용하여 보안을 생성해야 합니다.참고설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈
credentials-velero
파일을 사용하여 기본Secret
을 생성할 수 있습니다. 기본Secret
이 없는 경우 설치가 실패합니다.
절차
- Operators → 설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
- 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
YAML 보기를 클릭하고
DataProtectionApplication
매니페스트의 매개변수를 업데이트합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: namespace: openshift-adp name: <dpa_name> spec: configuration: velero: defaultPlugins: - openshift - aws - csi backupLocations: - velero: provider: aws 1 default: true objectStorage: bucket: <bucket_name> 2 prefix: velero config: insecureSkipTLSVerify: 'true' profile: default region: <region_name> 3 s3ForcePathStyle: 'true' s3Url: <s3_url> 4 credential: key: cloud name: cloud-credentials 5
- 1
- IBM Cloud를 백업 스토리지 위치로 사용하는 경우 공급자가
aws
입니다. - 2
- IBM Cloud Object Storage(COS) 버킷 이름을 지정합니다.
- 3
- COS 리전 이름을 지정합니다(예:
eu-gb
). - 4
- COS 버킷의 S3 URL을 지정합니다. 예:
http://s3.eu-gb.cloud-object-storage.appdomain.cloud
. 여기서eu-gb
는 지역 이름입니다. 버킷 리전에 따라 지역 이름을 바꿉니다. - 5
- 액세스 키와
HMAC
인증 정보의 시크릿 액세스 키를 사용하여 생성한 시크릿의 이름을 정의합니다.
- 생성을 클릭합니다.
검증
다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다.
$ oc get all -n openshift-adp
출력 예
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
다음 명령을 실행하여 DPA(
DataProtectionApplication
)가 조정되었는지 확인합니다.$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
출력 예
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
유형이
Reconciled
으로 설정되어 있는지 확인합니다. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여
PHASE
가 사용
가능한지 확인합니다.$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
4.6.4.5. Velero CPU 및 메모리 리소스 할당 설정
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero
Pod에 대한 CPU 및 메모리 리소스 할당을 설정합니다.
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.configuration.velero.podConfig.ResourceAllocations
블록의 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node_selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.
Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.
4.6.4.6. 노드 에이전트 및 노드 라벨 구성
OADP의 DPA는 nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.
지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다.
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
다음 예제는 nodeSelector
의 안티 패턴이며 'node-role.kubernetes.io/infra: ""'
및 'node-role.kubernetes.io/worker: ""'
둘 다 노드에 있지 않으면 작동하지 않습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.6.4.7. 클라이언트 버스트 및 QPS 설정으로 DPA 구성
버스트 설정은 제한을 적용하기 전에 velero
서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.
버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero
서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burst
및 dpa.configuration.velero.client-qps
필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
절차
다음 예와 같이 DPA에서
client-burst
및client-qps
필드를 구성합니다.데이터 보호 애플리케이션 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-dpa namespace: openshift-adp spec: backupLocations: - name: default velero: config: insecureSkipTLSVerify: "true" profile: "default" region: <bucket_region> s3ForcePathStyle: "true" s3Url: <bucket_url> credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: restic velero: client-burst: 500 1 client-qps: 300 2 defaultPlugins: - openshift - aws - kubevirt
4.6.4.8. 두 개 이상의 BSL로 DPA 구성
DPA를 두 개 이상의 BSL로 구성하고 클라우드 공급자가 제공하는 자격 증명을 지정할 수 있습니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성해야 합니다.
절차
두 개 이상의 BSL로 DPA를 구성합니다. 다음 예제를 참조하십시오.
DPA 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication #... backupLocations: - name: aws 1 velero: provider: aws default: true 2 objectStorage: bucket: <bucket_name> 3 prefix: <prefix> 4 config: region: <region_name> 5 profile: "default" credential: key: cloud name: cloud-credentials 6 - name: odf 7 velero: provider: aws default: false objectStorage: bucket: <bucket_name> prefix: <prefix> config: profile: "default" region: <region_name> s3Url: <url> 8 insecureSkipTLSVerify: "true" s3ForcePathStyle: "true" credential: key: cloud name: <custom_secret_name_odf> 9 #...
- 1
- 첫 번째 BSL의 이름을 지정합니다.
- 2
- 이 매개 변수는 이 BSL이 기본 BSL임을 나타냅니다.
Backup CR
에 BSL이 설정되지 않은 경우 기본 BSL이 사용됩니다. 하나의 BSL만 기본값으로 설정할 수 있습니다. - 3
- 버킷 이름을 지정합니다.
- 4
- Velero 백업의 접두사를 지정합니다(예:
velero
). - 5
- 버킷의 AWS 리전을 지정합니다.
- 6
- 생성한 기본
Secret
오브젝트의 이름을 지정합니다. - 7
- 두 번째 BSL의 이름을 지정합니다.
- 8
- S3 끝점의 URL을 지정합니다.
- 9
시크릿
의 올바른 이름을 지정합니다(예:custom_secret_name_odf
).Secret
이름을 지정하지 않으면 기본 이름이 사용됩니다.
백업 CR에 사용할 BSL을 지정합니다. 다음 예제를 참조하십시오.
백업 CR의 예
apiVersion: velero.io/v1 kind: Backup # ... spec: includedNamespaces: - <namespace> 1 storageLocation: <backup_storage_location> 2 defaultVolumesToFsBackup: true
4.6.4.9. DataProtectionApplication에서 노드 에이전트 비활성화
백업에 Restic
,Kopia
또는 DataMover
를 사용하지 않는 경우 DataProtectionApplication
CR(사용자 정의 리소스)에서 nodeAgent
필드를 비활성화할 수 있습니다. nodeAgent
를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.
절차
nodeAgent
를 비활성화하려면enable
플래그를false
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: false 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 비활성화합니다.
nodeAgent
를 활성화하려면enable
플래그를true
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: true 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 활성화합니다.
DataProtectionApplication
CR에서 nodeAgent
필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.
4.6.5. Microsoft Azure를 사용하여 데이터 보호를 위한 OpenShift API 구성
OADP Operator를 설치하여 Microsoft Azure와 함께 OADP(OpenShift API for Data Protection)를 설치합니다. Operator는 Velero 1.14 를 설치합니다.
OADP 1.0.4부터 모든 OADP 1.0.z 버전은 Migration Toolkit for Containers Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.
Velero에 대해 Azure를 구성하고, 기본 Secret
을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.
제한된 네트워크 환경에서 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.
4.6.5.1. Microsoft Azure 구성
OADP(OpenShift API for Data Protection)에 대해 Microsoft Azure를 구성합니다.
사전 요구 사항
- Azure CLI가 설치되어 있어야 합니다.
Azure 서비스를 사용하는 툴에는 항상 Azure 리소스가 안전한지 확인하기 위해 제한된 권한이 있어야 합니다. 따라서 애플리케이션이 완전히 권한이 있는 사용자로 로그인하는 대신 Azure는 서비스 주체를 제공합니다. Azure 서비스 주체는 애플리케이션, 호스팅 서비스 또는 자동화된 도구와 함께 사용할 수 있는 이름입니다.
이 ID는 리소스에 대한 액세스에 사용됩니다.
- 서비스 주체 생성
- 서비스 주체 및 암호를 사용하여 로그인
- 서비스 주체 및 인증서를 사용하여 로그인
- 서비스 주체 역할 관리
- 서비스 주체를 사용하여 Azure 리소스 생성
- 서비스 주체 인증 정보 재설정
자세한 내용은 Azure CLI를 사용하여 Azure 서비스 주체 만들기를 참조하십시오.
4.6.5.2. 백업 및 스냅샷 위치 및 시크릿 정보
DataProtectionApplication
CR(사용자 정의 리소스)에 백업 및 스냅샷 위치와 해당 시크릿을 지정합니다.
백업 위치
AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.
Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.
스냅샷 위치
클라우드 공급자의 기본 스냅샷 API를 사용하여 영구 볼륨을 백업하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.
CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass
CR을 생성하므로 스냅샷 위치를 지정할 필요가 없습니다.
FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.
보안
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 Secret
을 생성합니다.
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.
-
백업
위치에
대한 사용자 지정 보안(DataProtectionApplication
CR에서 지정) -
DataProtectionApplication
CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
데이터 보호 애플리케이션에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다.
설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 Secret
을 생성할 수 있습니다.
4.6.5.2.1. 기본 보안 생성
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 보안을 생성합니다.
Secret
의 기본 이름은 cloud-credentials-azure
입니다.
DataProtectionApplication
사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret
이 지정되지 않은 경우 기본 이름이 사용됩니다.
설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 이름으로 Secret
을 생성할 수 있습니다.
사전 요구 사항
- 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
- Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
-
적절한 형식으로 오브젝트 스토리지에 대한
credentials-velero
파일을 생성해야 합니다.
절차
기본 이름으로 보안을 생성합니다.
$ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
Data Protection Application을 설치할 때 DataProtectionApplication
CR의 spec.backupLocations.credential
블록에서 Secret
을 참조합니다.
4.6.5.2.2. 다른 인증 정보의 보안 생성
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 Secret
오브젝트를 생성해야 합니다.
-
사용자 지정 이름을 사용한 백업 위치
시크릿
. 사용자 지정 이름은DataProtectionApplication
CR(사용자 정의 리소스)의spec.backupLocations
블록에 지정됩니다. -
스냅샷 위치
보안
(기본값:cloud-credentials-azure
). 이보안은
DataProtectionApplication
CR에 지정되지 않습니다.
절차
-
클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한
credentials-velero
파일을 생성합니다. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.
$ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
-
오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한
credentials-velero
파일을 생성합니다. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.
$ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
다음 예제와 같이 사용자 지정 이름으로
Secret
을DataProtectionApplication
CR에 추가합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - velero: config: resourceGroup: <azure_resource_group> storageAccount: <azure_storage_account_id> subscriptionId: <azure_subscription_id> storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY credential: key: cloud name: <custom_secret> 1 provider: azure default: true objectStorage: bucket: <bucket_name> prefix: <prefix> snapshotLocations: - velero: config: resourceGroup: <azure_resource_group> subscriptionId: <azure_subscription_id> incremental: "true" provider: azure
- 1
- 사용자 지정 이름으로 백업 위치 보안.
4.6.5.3. 데이터 보호 애플리케이션 구성
Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.
4.6.5.3.1. Velero CPU 및 메모리 리소스 할당 설정
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero
Pod에 대한 CPU 및 메모리 리소스 할당을 설정합니다.
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.configuration.velero.podConfig.ResourceAllocations
블록의 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node_selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.
Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.
nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.
4.6.5.3.2. 자체 서명된 CA 인증서 활성화
알 수 없는 기관 오류로 서명된 인증서를 방지하려면
활성화해야 합니다.
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 자체 서명된 CA 인증서를
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
DataProtectionApplication
CR 매니페스트의spec.backupLocations.velero.objectStorage.caCert
매개변수 및spec.backupLocations.velero.config
매개변수를 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.6.5.3.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용
별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다. OpenShift CLI(
oc
)가 설치되어 있어야 합니다.aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
다음 명령을 실행하여 별칭이 작동하는지 확인합니다.
예제
$ velero version Client: Version: v1.12.1-OADP Git commit: - Server: Version: v1.12.1-OADP
이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.
$ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}') $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
$ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
백업 로그를 가져오려면 다음 명령을 실행합니다.
$ velero backup logs <backup_name> --cacert /tmp/<your_cacert.txt>
이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.
-
Velero 포드가 다시 시작되면
/tmp/your-cacert.txt
파일이 사라지고 이전 단계의 명령을 다시 실행하여/tmp/your-cacert.txt
파일을 다시 생성해야 합니다. 다음 명령을 실행하여
/tmp/your-cacert.txt
파일이 여전히 있는지 확인할 수 있습니다.$ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt" /tmp/your-cacert.txt
향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.
4.6.5.4. 데이터 보호 애플리케이션 설치
DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application
)를 설치합니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
- 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
-
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하는 경우 기본 이름
cloud-credentials-azure
로 보안을 생성해야 합니다. 백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 보안을 생성해야 합니다.
-
백업 위치에 대한 사용자 지정 이름이 있는
시크릿
입니다. 이 보안을DataProtectionApplication
CR에 추가합니다. -
스냅샷 위치에 대한 다른 사용자 지정 이름이 있는
시크릿
입니다. 이 보안을DataProtectionApplication
CR에 추가합니다.
참고설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈
credentials-velero
파일을 사용하여 기본Secret
을 생성할 수 있습니다. 기본Secret
이 없는 경우 설치가 실패합니다.-
백업 위치에 대한 사용자 지정 이름이 있는
절차
- Operators → 설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
- 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
YAML 보기를 클릭하고
DataProtectionApplication
매니페스트의 매개변수를 업데이트합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp 1 spec: configuration: velero: defaultPlugins: - azure - openshift 2 resourceTimeout: 10m 3 nodeAgent: 4 enable: true 5 uploaderType: kopia 6 podConfig: nodeSelector: <node_selector> 7 backupLocations: - velero: config: resourceGroup: <azure_resource_group> 8 storageAccount: <azure_storage_account_id> 9 subscriptionId: <azure_subscription_id> 10 storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY credential: key: cloud name: cloud-credentials-azure 11 provider: azure default: true objectStorage: bucket: <bucket_name> 12 prefix: <prefix> 13 snapshotLocations: 14 - velero: config: resourceGroup: <azure_resource_group> subscriptionId: <azure_subscription_id> incremental: "true" name: default provider: azure credential: key: cloud name: cloud-credentials-azure 15
- 1
- OADP의 기본 네임스페이스는
openshift-adp
입니다. 네임스페이스는 변수이며 구성 가능합니다. - 2
openshift
플러그인은 필수입니다.- 3
- Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
- 4
- 관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
- 5
nodeAgent
를 활성화하고 파일 시스템 백업을 수행하려면 이 값을true
로 설정합니다.- 6
- 업로드로
kopia
또는restic
을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다.nodeAgent
는 데몬 세트를 배포합니다. 즉,nodeAgent
Pod가 각 작동 중인 노드에서 실행됩니다.Backup
CR에spec.defaultVolumesToFsBackup: true
를 추가하여 파일 시스템 백업을 구성할 수 있습니다. - 7
- Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
- 8
- Azure 리소스 그룹을 지정합니다.
- 9
- Azure 스토리지 계정 ID를 지정합니다.
- 10
- Azure 서브스크립션 ID를 지정합니다.
- 11
- 이 값을 지정하지 않으면 기본값
cloud-credentials-azure
이 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다. - 12
- 버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
- 13
- 버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
- 14
- CSI 스냅샷 또는 Restic을 사용하여 PV를 백업하는 경우 스냅샷 위치를 지정할 필요가 없습니다.
- 15
- 생성한
Secret
오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본 이름,cloud-credentials-azure
가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
- 생성을 클릭합니다.
검증
다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다.
$ oc get all -n openshift-adp
출력 예
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
다음 명령을 실행하여 DPA(
DataProtectionApplication
)가 조정되었는지 확인합니다.$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
출력 예
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
유형이
Reconciled
으로 설정되어 있는지 확인합니다. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여
PHASE
가 사용
가능한지 확인합니다.$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
4.6.5.5. 클라이언트 버스트 및 QPS 설정으로 DPA 구성
버스트 설정은 제한을 적용하기 전에 velero
서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.
버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero
서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burst
및 dpa.configuration.velero.client-qps
필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
절차
다음 예와 같이 DPA에서
client-burst
및client-qps
필드를 구성합니다.데이터 보호 애플리케이션 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-dpa namespace: openshift-adp spec: backupLocations: - name: default velero: config: insecureSkipTLSVerify: "true" profile: "default" region: <bucket_region> s3ForcePathStyle: "true" s3Url: <bucket_url> credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: restic velero: client-burst: 500 1 client-qps: 300 2 defaultPlugins: - openshift - aws - kubevirt
4.6.5.5.1. 노드 에이전트 및 노드 라벨 구성
OADP의 DPA는 nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.
지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다.
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
다음 예제는 nodeSelector
의 안티 패턴이며 'node-role.kubernetes.io/infra: ""'
및 'node-role.kubernetes.io/worker: ""'
둘 다 노드에 있지 않으면 작동하지 않습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.6.5.5.2. DataProtectionApplication CR에서 CSI 활성화
CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication
CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.
사전 요구 사항
- 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
기본 플러그인을 추가합니다.
4.6.5.5.3. DataProtectionApplication에서 노드 에이전트 비활성화
백업에 Restic
,Kopia
또는 DataMover
를 사용하지 않는 경우 DataProtectionApplication
CR(사용자 정의 리소스)에서 nodeAgent
필드를 비활성화할 수 있습니다. nodeAgent
를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.
절차
nodeAgent
를 비활성화하려면enable
플래그를false
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: false 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 비활성화합니다.
nodeAgent
를 활성화하려면enable
플래그를true
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: true 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 활성화합니다.
DataProtectionApplication
CR에서 nodeAgent
필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.
4.6.6. Google Cloud Platform을 사용하여 데이터 보호를 위한 OpenShift API 구성
OADP Operator를 설치하여 GCP(Google Cloud Platform)를 사용하여 OADP(Data Protection)용 OpenShift API를 설치합니다. Operator는 Velero 1.14 를 설치합니다.
OADP 1.0.4부터 모든 OADP 1.0.z 버전은 Migration Toolkit for Containers Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.
Velero에 대해 GCP를 구성하고 기본 시크릿
을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.
제한된 네트워크 환경에서 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.
4.6.6.1. GCP(Google Cloud Platform) 구성
OADP(Data Protection)를 OpenShift API용으로 GCP(Google Cloud Platform)를 구성합니다.
사전 요구 사항
-
gcloud
및gsutil
CLI 툴이 설치되어 있어야 합니다. 자세한 내용은 Google 클라우드 설명서를 참조하십시오.
절차
GCP에 로그인합니다.
$ gcloud auth login
BUCKET
변수를 설정합니다.$ BUCKET=<bucket> 1
- 1
- 버킷 이름을 지정합니다.
스토리지 버킷을 생성합니다.
$ gsutil mb gs://$BUCKET/
PROJECT_ID
변수를 활성 프로젝트로 설정합니다.$ PROJECT_ID=$(gcloud config get-value project)
서비스 계정을 생성합니다.
$ gcloud iam service-accounts create velero \ --display-name "Velero service account"
서비스 계정을 나열합니다.
$ gcloud iam service-accounts list
email
값과 일치하도록SERVICE_ACCOUNT_EMAIL
변수를 설정합니다.$ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \ --filter="displayName:Velero service account" \ --format 'value(email)')
정책을 연결하여
velero
사용자에게 최소한의 필요한 권한을 부여합니다.$ ROLE_PERMISSIONS=( compute.disks.get compute.disks.create compute.disks.createSnapshot compute.snapshots.get compute.snapshots.create compute.snapshots.useReadOnly compute.snapshots.delete compute.zones.get storage.objects.create storage.objects.delete storage.objects.get storage.objects.list iam.serviceAccounts.signBlob )
velero.server
사용자 정의 역할을 생성합니다.$ gcloud iam roles create velero.server \ --project $PROJECT_ID \ --title "Velero Server" \ --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
프로젝트에 IAM 정책 바인딩을 추가합니다.
$ gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \ --role projects/$PROJECT_ID/roles/velero.server
IAM 서비스 계정을 업데이트합니다.
$ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
IAM 서비스 계정 키를 현재 디렉터리의
credentials-velero
파일에 저장합니다.$ gcloud iam service-accounts keys create credentials-velero \ --iam-account $SERVICE_ACCOUNT_EMAIL
데이터 보호 애플리케이션을 설치하기 전에
credentials-velero
파일을 사용하여 GCP용Secret
오브젝트를 생성합니다.
4.6.6.2. 백업 및 스냅샷 위치 및 시크릿 정보
DataProtectionApplication
CR(사용자 정의 리소스)에 백업 및 스냅샷 위치와 해당 시크릿을 지정합니다.
백업 위치
AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.
Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.
스냅샷 위치
클라우드 공급자의 기본 스냅샷 API를 사용하여 영구 볼륨을 백업하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.
CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass
CR을 생성하므로 스냅샷 위치를 지정할 필요가 없습니다.
FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.
보안
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 Secret
을 생성합니다.
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.
-
백업
위치에
대한 사용자 지정 보안(DataProtectionApplication
CR에서 지정) -
DataProtectionApplication
CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
데이터 보호 애플리케이션에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다.
설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 Secret
을 생성할 수 있습니다.
4.6.6.2.1. 기본 보안 생성
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 보안을 생성합니다.
Secret
의 기본 이름은 cloud-credentials-gcp
입니다.
DataProtectionApplication
사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret
이 지정되지 않은 경우 기본 이름이 사용됩니다.
설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 이름으로 Secret
을 생성할 수 있습니다.
사전 요구 사항
- 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
- Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
-
적절한 형식으로 오브젝트 스토리지에 대한
credentials-velero
파일을 생성해야 합니다.
절차
기본 이름으로 보안을 생성합니다.
$ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
Data Protection Application을 설치할 때 DataProtectionApplication
CR의 spec.backupLocations.credential
블록에서 Secret
을 참조합니다.
4.6.6.2.2. 다른 인증 정보의 보안 생성
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 Secret
오브젝트를 생성해야 합니다.
-
사용자 지정 이름을 사용한 백업 위치
시크릿
. 사용자 지정 이름은DataProtectionApplication
CR(사용자 정의 리소스)의spec.backupLocations
블록에 지정됩니다. -
스냅샷
위치
기본 이름cloud-credentials-gcp
. 이보안은
DataProtectionApplication
CR에 지정되지 않습니다.
절차
-
클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한
credentials-velero
파일을 생성합니다. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.
$ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
-
오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한
credentials-velero
파일을 생성합니다. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.
$ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
다음 예제와 같이 사용자 지정 이름으로
Secret
을DataProtectionApplication
CR에 추가합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - velero: provider: gcp default: true credential: key: cloud name: <custom_secret> 1 objectStorage: bucket: <bucket_name> prefix: <prefix> snapshotLocations: - velero: provider: gcp default: true config: project: <project> snapshotLocation: us-west1
- 1
- 사용자 지정 이름으로 백업 위치 보안.
4.6.6.3. 데이터 보호 애플리케이션 구성
Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.
4.6.6.3.1. Velero CPU 및 메모리 리소스 할당 설정
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero
Pod에 대한 CPU 및 메모리 리소스 할당을 설정합니다.
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.configuration.velero.podConfig.ResourceAllocations
블록의 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node_selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.
Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.
nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.
4.6.6.3.2. 자체 서명된 CA 인증서 활성화
알 수 없는 기관 오류로 서명된 인증서를 방지하려면
활성화해야 합니다.
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 자체 서명된 CA 인증서를
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
DataProtectionApplication
CR 매니페스트의spec.backupLocations.velero.objectStorage.caCert
매개변수 및spec.backupLocations.velero.config
매개변수를 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.6.6.3.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용
별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다. OpenShift CLI(
oc
)가 설치되어 있어야 합니다.aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
다음 명령을 실행하여 별칭이 작동하는지 확인합니다.
예제
$ velero version Client: Version: v1.12.1-OADP Git commit: - Server: Version: v1.12.1-OADP
이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.
$ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}') $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
$ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
백업 로그를 가져오려면 다음 명령을 실행합니다.
$ velero backup logs <backup_name> --cacert /tmp/<your_cacert.txt>
이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.
-
Velero 포드가 다시 시작되면
/tmp/your-cacert.txt
파일이 사라지고 이전 단계의 명령을 다시 실행하여/tmp/your-cacert.txt
파일을 다시 생성해야 합니다. 다음 명령을 실행하여
/tmp/your-cacert.txt
파일이 여전히 있는지 확인할 수 있습니다.$ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt" /tmp/your-cacert.txt
향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.
4.6.6.4. Google 워크로드 ID 페더레이션 클라우드 인증
Google Cloud 외부에서 실행되는 애플리케이션은 사용자 이름 및 암호와 같은 서비스 계정 키를 사용하여 Google Cloud 리소스에 액세스할 수 있습니다. 이러한 서비스 계정 키는 올바르게 관리되지 않는 경우 보안 위험이 될 수 있습니다.
Google의 워크로드 ID 페더레이션을 사용하면 IAM(Identity and Access Management)을 사용하여 서비스 계정을 가장하는 기능을 포함하여 외부 ID IAM 역할을 제공할 수 있습니다. 이렇게 하면 서비스 계정 키와 관련된 유지 관리 및 보안 위험이 제거됩니다.
워크로드 ID 페더레이션은 인증서 암호화 및 암호 해독, 사용자 속성 추출 및 검증을 처리합니다. ID 페더레이션은 인증을 외부화하고 STS(Security Token Services)에 전달하여 개별 개발자의 요구 사항을 줄입니다. 리소스에 대한 액세스 권한 부여 및 제어는 애플리케이션의 책임이 그대로 유지됩니다.
볼륨을 백업할 때 Google 워크로드 ID 페더레이션 인증을 사용하여 GCP의 OADP는 CSI 스냅샷만 지원합니다.
Google 워크로드 ID 페더레이션 인증을 사용하는 GCP의 OADP는 VSL(volume Snapshot Locations) 백업을 지원하지 않습니다. 자세한 내용은 Google 워크로드 ID 페더레이션의 알려진 문제를 참조하십시오.
Google 워크로드 ID 페더레이션 클라우드 인증을 사용하지 않는 경우 데이터 보호 애플리케이션 설치를 계속합니다.
사전 요구 사항
- GCP 워크로드 ID가 구성되어 있는 수동 모드로 클러스터를 설치했습니다.
-
Cloud Credential Operator 유틸리티(
ccoctl
) 및 관련 워크로드 ID 풀에 액세스할 수 있습니다.
절차
다음 명령을 실행하여
oadp-credrequest
디렉터리를 생성합니다.$ mkdir -p oadp-credrequest
다음과 같이
CredentialsRequest.yaml
파일을 생성합니다.echo 'apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: oadp-operator-credentials namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: GCPProviderSpec permissions: - compute.disks.get - compute.disks.create - compute.disks.createSnapshot - compute.snapshots.get - compute.snapshots.create - compute.snapshots.useReadOnly - compute.snapshots.delete - compute.zones.get - storage.objects.create - storage.objects.delete - storage.objects.get - storage.objects.list - iam.serviceAccounts.signBlob skipServiceCheck: true secretRef: name: cloud-credentials-gcp namespace: <OPERATOR_INSTALL_NS> serviceAccountNames: - velero ' > oadp-credrequest/credrequest.yaml
다음 명령을 실행하여
ccoctl
유틸리티를 사용하여oadp-credrequest
디렉터리에서CredentialsRequest
오브젝트를 처리합니다.$ ccoctl gcp create-service-accounts \ --name=<name> \ --project=<gcp_project_id> \ --credentials-requests-dir=oadp-credrequest \ --workload-identity-pool=<pool_id> \ --workload-identity-provider=<provider_id>
다음 단계에서
manifests/openshift-adp-cloud-credentials-gcp-credentials.yaml
파일을 사용할 수 있습니다.다음 명령을 실행하여 네임스페이스를 생성합니다.
$ oc create namespace <OPERATOR_INSTALL_NS>
다음 명령을 실행하여 네임스페이스에 인증 정보를 적용합니다.
$ oc apply -f manifests/openshift-adp-cloud-credentials-gcp-credentials.yaml
4.6.6.4.1. Google 워크로드 ID 페더레이션 알려진 문제
-
GCP 워크로드 ID 페더레이션이 구성된 경우 VSL(volume Snapshot Location) 백업은
부분적으로Failed
단계로 완료됩니다. Google 워크로드 ID 페더레이션 인증은 VSL 백업을 지원하지 않습니다.
4.6.6.5. 데이터 보호 애플리케이션 설치
DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application
)를 설치합니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
- 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
-
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하는 경우 기본 이름
cloud-credentials-gcp
로Secret
을 생성해야 합니다. 백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 보안을 생성해야 합니다.
-
백업 위치에 대한 사용자 지정 이름이 있는
시크릿
입니다. 이 보안을DataProtectionApplication
CR에 추가합니다. -
스냅샷 위치에 대한 다른 사용자 지정 이름이 있는
시크릿
입니다. 이 보안을DataProtectionApplication
CR에 추가합니다.
참고설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈
credentials-velero
파일을 사용하여 기본Secret
을 생성할 수 있습니다. 기본Secret
이 없는 경우 설치가 실패합니다.-
백업 위치에 대한 사용자 지정 이름이 있는
절차
- Operators → 설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
- 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
YAML 보기를 클릭하고
DataProtectionApplication
매니페스트의 매개변수를 업데이트합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: <OPERATOR_INSTALL_NS> 1 spec: configuration: velero: defaultPlugins: - gcp - openshift 2 resourceTimeout: 10m 3 nodeAgent: 4 enable: true 5 uploaderType: kopia 6 podConfig: nodeSelector: <node_selector> 7 backupLocations: - velero: provider: gcp default: true credential: key: cloud 8 name: cloud-credentials-gcp 9 objectStorage: bucket: <bucket_name> 10 prefix: <prefix> 11 snapshotLocations: 12 - velero: provider: gcp default: true config: project: <project> snapshotLocation: us-west1 13 credential: key: cloud name: cloud-credentials-gcp 14 backupImages: true 15
- 1
- OADP의 기본 네임스페이스는
openshift-adp
입니다. 네임스페이스는 변수이며 구성 가능합니다. - 2
openshift
플러그인은 필수입니다.- 3
- Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
- 4
- 관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
- 5
nodeAgent
를 활성화하고 파일 시스템 백업을 수행하려면 이 값을true
로 설정합니다.- 6
- 업로드로
kopia
또는restic
을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다.nodeAgent
는 데몬 세트를 배포합니다. 즉,nodeAgent
Pod가 각 작동 중인 노드에서 실행됩니다.Backup
CR에spec.defaultVolumesToFsBackup: true
를 추가하여 파일 시스템 백업을 구성할 수 있습니다. - 7
- Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
- 8
- 인증 정보가 포함된 시크릿 키입니다. Google 워크로드 ID 페더레이션 클라우드 인증의 경우
service_account.json
을 사용합니다. - 9
- 인증 정보가 포함된 시크릿 이름입니다. 이 값을 지정하지 않으면 기본값
cloud-credentials-gcp
가 사용됩니다. - 10
- 버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
- 11
- 버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
- 12
- CSI 스냅샷 또는 Restic을 사용하여 PV를 백업하지 않는 한 스냅샷 위치를 지정합니다.
- 13
- 스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.
- 14
- 생성한
Secret
오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본 이름,cloud-credentials-gcp
가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다. - 15
- Google 워크로드 ID 페더레이션은 내부 이미지 백업을 지원합니다. 이미지 백업을 사용하지 않으려면 이 필드를
false
로 설정합니다.
- 생성을 클릭합니다.
검증
다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다.
$ oc get all -n openshift-adp
출력 예
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
다음 명령을 실행하여 DPA(
DataProtectionApplication
)가 조정되었는지 확인합니다.$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
출력 예
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
유형이
Reconciled
으로 설정되어 있는지 확인합니다. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여
PHASE
가 사용
가능한지 확인합니다.$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
4.6.6.6. 클라이언트 버스트 및 QPS 설정으로 DPA 구성
버스트 설정은 제한을 적용하기 전에 velero
서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.
버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero
서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burst
및 dpa.configuration.velero.client-qps
필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
절차
다음 예와 같이 DPA에서
client-burst
및client-qps
필드를 구성합니다.데이터 보호 애플리케이션 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-dpa namespace: openshift-adp spec: backupLocations: - name: default velero: config: insecureSkipTLSVerify: "true" profile: "default" region: <bucket_region> s3ForcePathStyle: "true" s3Url: <bucket_url> credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: restic velero: client-burst: 500 1 client-qps: 300 2 defaultPlugins: - openshift - aws - kubevirt
4.6.6.6.1. 노드 에이전트 및 노드 라벨 구성
OADP의 DPA는 nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.
지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다.
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
다음 예제는 nodeSelector
의 안티 패턴이며 'node-role.kubernetes.io/infra: ""'
및 'node-role.kubernetes.io/worker: ""'
둘 다 노드에 있지 않으면 작동하지 않습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.6.6.6.2. DataProtectionApplication CR에서 CSI 활성화
CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication
CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.
사전 요구 사항
- 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
기본 플러그인을 추가합니다.
4.6.6.6.3. DataProtectionApplication에서 노드 에이전트 비활성화
백업에 Restic
,Kopia
또는 DataMover
를 사용하지 않는 경우 DataProtectionApplication
CR(사용자 정의 리소스)에서 nodeAgent
필드를 비활성화할 수 있습니다. nodeAgent
를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.
절차
nodeAgent
를 비활성화하려면enable
플래그를false
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: false 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 비활성화합니다.
nodeAgent
를 활성화하려면enable
플래그를true
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: true 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 활성화합니다.
DataProtectionApplication
CR에서 nodeAgent
필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.
4.6.7. Multicloud Object Gateway를 사용하여 데이터 보호를 위한 OpenShift API 구성
OADP Operator를 설치하여 MCG(Multicloud Object Gateway)를 사용하여 OADP(OpenShift API for Data Protection)를 설치합니다. Operator는 Velero 1.14 를 설치합니다.
OADP 1.0.4부터 모든 OADP 1.0.z 버전은 Migration Toolkit for Containers Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.
Multicloud Object Gateway 를 백업 위치로 구성합니다. MCG는 OpenShift Data Foundation의 구성 요소입니다. MCG를 DataProtectionApplication
CR(사용자 정의 리소스)에서 백업 위치로 구성합니다.
오브젝트 스토리지용 버킷 생성을 자동화하는 CloudStorage
API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
백업 위치에 대한
보안을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.
제한된 네트워크 환경에서 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.
4.6.7.1. 멀티 클라우드 오브젝트 게이트웨이 인증 정보 검색
OADP(Data Protection)용 OpenShift API에 대한 Secret
CR(사용자 정의 리소스)을 생성해야 하는 MCG(Multicloud Object Gateway) 인증 정보를 검색해야 합니다.
MCG Operator는 더 이상 사용되지 않지만 OpenShift Data Foundation에서 MCG 플러그인을 계속 사용할 수 있습니다. 플러그인을 다운로드하려면 Red Hat OpenShift Data Foundation 을 다운로드하여 운영 체제에 적합한 MCG 플러그인을 다운로드합니다.
사전 요구 사항
절차
-
NooBaa
사용자 정의 리소스에서describe
명령을 실행하여 S3 엔드포인트AWS_ACCESS_KEY_ID
및AWS_SECRET_ACCESS_KEY
를 가져옵니다. credentials-velero
파일을 생성합니다.$ cat << EOF > ./credentials-velero [default] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY> EOF
Data Protection Application을 설치할 때
credentials-velero
파일을 사용하여Secret
오브젝트를 생성합니다.
4.6.7.2. 백업 및 스냅샷 위치 및 시크릿 정보
DataProtectionApplication
CR(사용자 정의 리소스)에 백업 및 스냅샷 위치와 해당 시크릿을 지정합니다.
백업 위치
AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.
Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.
스냅샷 위치
클라우드 공급자의 기본 스냅샷 API를 사용하여 영구 볼륨을 백업하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.
CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass
CR을 생성하므로 스냅샷 위치를 지정할 필요가 없습니다.
FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.
보안
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 Secret
을 생성합니다.
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.
-
백업
위치에
대한 사용자 지정 보안(DataProtectionApplication
CR에서 지정) -
DataProtectionApplication
CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
데이터 보호 애플리케이션에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다.
설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 Secret
을 생성할 수 있습니다.
4.6.7.2.1. 기본 보안 생성
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 보안을 생성합니다.
Secret
의 기본 이름은 cloud-credentials
입니다.
DataProtectionApplication
사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret
이 지정되지 않은 경우 기본 이름이 사용됩니다.
설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 이름으로 Secret
을 생성할 수 있습니다.
사전 요구 사항
- 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
- Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
-
적절한 형식으로 오브젝트 스토리지에 대한
credentials-velero
파일을 생성해야 합니다.
절차
기본 이름으로 보안을 생성합니다.
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
Data Protection Application을 설치할 때 DataProtectionApplication
CR의 spec.backupLocations.credential
블록에서 Secret
을 참조합니다.
4.6.7.2.2. 다른 인증 정보의 보안 생성
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 Secret
오브젝트를 생성해야 합니다.
-
사용자 지정 이름을 사용한 백업 위치
시크릿
. 사용자 지정 이름은DataProtectionApplication
CR(사용자 정의 리소스)의spec.backupLocations
블록에 지정됩니다. -
스냅샷 위치
보안
(기본값:cloud-credentials
)입니다. 이보안은
DataProtectionApplication
CR에 지정되지 않습니다.
절차
-
클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한
credentials-velero
파일을 생성합니다. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
-
오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한
credentials-velero
파일을 생성합니다. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.
$ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
다음 예제와 같이 사용자 지정 이름으로
Secret
을DataProtectionApplication
CR에 추가합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - velero: config: profile: "default" region: <region_name> 1 s3Url: <url> insecureSkipTLSVerify: "true" s3ForcePathStyle: "true" provider: aws default: true credential: key: cloud name: <custom_secret> 2 objectStorage: bucket: <bucket_name> prefix: <prefix>
4.6.7.3. 데이터 보호 애플리케이션 구성
Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.
4.6.7.3.1. Velero CPU 및 메모리 리소스 할당 설정
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero
Pod에 대한 CPU 및 메모리 리소스 할당을 설정합니다.
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.configuration.velero.podConfig.ResourceAllocations
블록의 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node_selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.
Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.
nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.
4.6.7.3.2. 자체 서명된 CA 인증서 활성화
알 수 없는 기관 오류로 서명된 인증서를 방지하려면
활성화해야 합니다.
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 자체 서명된 CA 인증서를
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
DataProtectionApplication
CR 매니페스트의spec.backupLocations.velero.objectStorage.caCert
매개변수 및spec.backupLocations.velero.config
매개변수를 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.6.7.3.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용
별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다. OpenShift CLI(
oc
)가 설치되어 있어야 합니다.aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
다음 명령을 실행하여 별칭이 작동하는지 확인합니다.
예제
$ velero version Client: Version: v1.12.1-OADP Git commit: - Server: Version: v1.12.1-OADP
이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.
$ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}') $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
$ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
백업 로그를 가져오려면 다음 명령을 실행합니다.
$ velero backup logs <backup_name> --cacert /tmp/<your_cacert.txt>
이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.
-
Velero 포드가 다시 시작되면
/tmp/your-cacert.txt
파일이 사라지고 이전 단계의 명령을 다시 실행하여/tmp/your-cacert.txt
파일을 다시 생성해야 합니다. 다음 명령을 실행하여
/tmp/your-cacert.txt
파일이 여전히 있는지 확인할 수 있습니다.$ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt" /tmp/your-cacert.txt
향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.
4.6.7.4. 데이터 보호 애플리케이션 설치
DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application
)를 설치합니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
- 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
-
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하는 경우 기본 이름
cloud-credentials
를 사용하여 보안을 생성해야 합니다. 백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 보안을 생성해야 합니다.
-
백업 위치에 대한 사용자 지정 이름이 있는
시크릿
입니다. 이 보안을DataProtectionApplication
CR에 추가합니다. -
스냅샷 위치에 대한 다른 사용자 지정 이름이 있는
시크릿
입니다. 이 보안을DataProtectionApplication
CR에 추가합니다.
참고설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈
credentials-velero
파일을 사용하여 기본Secret
을 생성할 수 있습니다. 기본Secret
이 없는 경우 설치가 실패합니다.-
백업 위치에 대한 사용자 지정 이름이 있는
절차
- Operators → 설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
- 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
YAML 보기를 클릭하고
DataProtectionApplication
매니페스트의 매개변수를 업데이트합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp 1 spec: configuration: velero: defaultPlugins: - aws 2 - openshift 3 resourceTimeout: 10m 4 nodeAgent: 5 enable: true 6 uploaderType: kopia 7 podConfig: nodeSelector: <node_selector> 8 backupLocations: - velero: config: profile: "default" region: <region_name> 9 s3Url: <url> 10 insecureSkipTLSVerify: "true" s3ForcePathStyle: "true" provider: aws default: true credential: key: cloud name: cloud-credentials 11 objectStorage: bucket: <bucket_name> 12 prefix: <prefix> 13
- 1
- OADP의 기본 네임스페이스는
openshift-adp
입니다. 네임스페이스는 변수이며 구성 가능합니다. - 2
- 스토리지 위치에 해당하는 오브젝트 저장소 플러그인이 필요합니다. 모든 S3 공급자의 경우 필요한 플러그인은
aws
입니다. Azure 및 GCP 오브젝트 저장소의 경우azure
또는gcp
플러그인이 필요합니다. - 3
openshift
플러그인은 필수입니다.- 4
- Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
- 5
- 관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
- 6
nodeAgent
를 활성화하고 파일 시스템 백업을 수행하려면 이 값을true
로 설정합니다.- 7
- 업로드로
kopia
또는restic
을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다.nodeAgent
는 데몬 세트를 배포합니다. 즉,nodeAgent
Pod가 각 작동 중인 노드에서 실행됩니다.Backup
CR에spec.defaultVolumesToFsBackup: true
를 추가하여 파일 시스템 백업을 구성할 수 있습니다. - 8
- Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
- 9
- 오브젝트 스토리지 서버 설명서의 이름 지정 규칙에 따라 리전을 지정합니다.
- 10
- S3 끝점의 URL을 지정합니다.
- 11
- 생성한
Secret
오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본값cloud-credentials
가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다. - 12
- 버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
- 13
- 버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
- 생성을 클릭합니다.
검증
다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다.
$ oc get all -n openshift-adp
출력 예
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
다음 명령을 실행하여 DPA(
DataProtectionApplication
)가 조정되었는지 확인합니다.$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
출력 예
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
유형이
Reconciled
으로 설정되어 있는지 확인합니다. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여
PHASE
가 사용
가능한지 확인합니다.$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
4.6.7.5. 클라이언트 버스트 및 QPS 설정으로 DPA 구성
버스트 설정은 제한을 적용하기 전에 velero
서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.
버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero
서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burst
및 dpa.configuration.velero.client-qps
필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
절차
다음 예와 같이 DPA에서
client-burst
및client-qps
필드를 구성합니다.데이터 보호 애플리케이션 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-dpa namespace: openshift-adp spec: backupLocations: - name: default velero: config: insecureSkipTLSVerify: "true" profile: "default" region: <bucket_region> s3ForcePathStyle: "true" s3Url: <bucket_url> credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: restic velero: client-burst: 500 1 client-qps: 300 2 defaultPlugins: - openshift - aws - kubevirt
4.6.7.5.1. 노드 에이전트 및 노드 라벨 구성
OADP의 DPA는 nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.
지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다.
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
다음 예제는 nodeSelector
의 안티 패턴이며 'node-role.kubernetes.io/infra: ""'
및 'node-role.kubernetes.io/worker: ""'
둘 다 노드에 있지 않으면 작동하지 않습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.6.7.5.2. DataProtectionApplication CR에서 CSI 활성화
CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication
CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.
사전 요구 사항
- 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
기본 플러그인을 추가합니다.
4.6.7.5.3. DataProtectionApplication에서 노드 에이전트 비활성화
백업에 Restic
,Kopia
또는 DataMover
를 사용하지 않는 경우 DataProtectionApplication
CR(사용자 정의 리소스)에서 nodeAgent
필드를 비활성화할 수 있습니다. nodeAgent
를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.
절차
nodeAgent
를 비활성화하려면enable
플래그를false
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: false 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 비활성화합니다.
nodeAgent
를 활성화하려면enable
플래그를true
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: true 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 활성화합니다.
DataProtectionApplication
CR에서 nodeAgent
필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.
4.6.8. OpenShift Data Foundation으로 데이터 보호를 위한 OpenShift API 구성
OADP Operator를 설치하고 백업 위치와 스냅샷 위치를 구성하여 OpenShift Data Foundation을 사용하여 OADP(OpenShift API for Data Protection)를 설치합니다. 그런 다음 Data Protection Application을 설치합니다.
OADP 1.0.4부터 모든 OADP 1.0.z 버전은 Migration Toolkit for Containers Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.
Multicloud Object Gateway 또는 AWS S3 호환 오브젝트 스토리지를 백업 위치로 구성할 수 있습니다.
오브젝트 스토리지용 버킷 생성을 자동화하는 CloudStorage
API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
백업 위치에 대한
보안을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.
제한된 네트워크 환경에서 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.
4.6.8.1. 백업 및 스냅샷 위치 및 시크릿 정보
DataProtectionApplication
CR(사용자 정의 리소스)에 백업 및 스냅샷 위치와 해당 시크릿을 지정합니다.
백업 위치
AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.
Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.
스냅샷 위치
클라우드 공급자의 기본 스냅샷 API를 사용하여 영구 볼륨을 백업하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.
CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass
CR을 생성하므로 스냅샷 위치를 지정할 필요가 없습니다.
FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.
보안
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 Secret
을 생성합니다.
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.
-
백업
위치에
대한 사용자 지정 보안(DataProtectionApplication
CR에서 지정) -
DataProtectionApplication
CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
데이터 보호 애플리케이션에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다.
설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 Secret
을 생성할 수 있습니다.
4.6.8.1.1. 기본 보안 생성
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 보안을 생성합니다.
백업 스토리지 공급자에 aws
,azure
또는 gcp
와 같은 기본 플러그인이 없으면 Secret
의 기본 이름은 cloud-credentials
입니다. 이 경우 기본 이름은 공급자별 OADP 설치 절차에 지정됩니다.
DataProtectionApplication
사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다
. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret
이 지정되지 않은 경우 기본 이름이 사용됩니다.
설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero
파일을 사용하여 기본 이름으로 Secret
을 생성할 수 있습니다.
사전 요구 사항
- 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
- Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
-
적절한 형식으로 오브젝트 스토리지에 대한
credentials-velero
파일을 생성해야 합니다.
절차
기본 이름으로 보안을 생성합니다.
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
Data Protection Application을 설치할 때 DataProtectionApplication
CR의 spec.backupLocations.credential
블록에서 Secret
을 참조합니다.
4.6.8.1.2. 다른 인증 정보의 보안 생성
백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 Secret
오브젝트를 생성해야 합니다.
-
사용자 지정 이름을 사용한 백업 위치
시크릿
. 사용자 지정 이름은DataProtectionApplication
CR(사용자 정의 리소스)의spec.backupLocations
블록에 지정됩니다. -
스냅샷 위치
보안
(기본값:cloud-credentials
)입니다. 이보안은
DataProtectionApplication
CR에 지정되지 않습니다.
절차
-
클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한
credentials-velero
파일을 생성합니다. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
-
오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한
credentials-velero
파일을 생성합니다. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.
$ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
다음 예제와 같이 사용자 지정 이름으로
Secret
을DataProtectionApplication
CR에 추가합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - velero: provider: <provider> default: true credential: key: cloud name: <custom_secret> 1 objectStorage: bucket: <bucket_name> prefix: <prefix>
- 1
- 사용자 지정 이름으로 백업 위치 보안.
4.6.8.2. 데이터 보호 애플리케이션 구성
Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.
4.6.8.2.1. Velero CPU 및 메모리 리소스 할당 설정
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero
Pod에 대한 CPU 및 메모리 리소스 할당을 설정합니다.
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.configuration.velero.podConfig.ResourceAllocations
블록의 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node_selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.
Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.
nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.
4.6.8.2.1.1. 수집된 데이터를 기반으로 Ceph CPU 및 메모리 요구 사항 조정
다음 권장 사항은 규모 및 성능 랩에서 수행된 성능 관찰을 기반으로 합니다. 변경 사항은 특히 {odf-first}와 관련이 있습니다. {odf-short}로 작업하는 경우 공식 권장 사항은 적절한 튜닝 가이드를 참조하십시오.
4.6.8.2.1.1.1. 구성에 대한 CPU 및 메모리 요구 사항
백업 및 복원 작업에는 대량의 CephFS PersistentVolume
(PV)이 필요합니다. 메모리
부족(OOM) 오류로 Ceph MDS Pod를 재시작하지 않으려면 다음 설정이 권장됩니다.
구성 유형 | 요청 | 최대 제한 |
---|---|---|
CPU | 3으로 변경됨 | 최대 제한 3 |
메모리 | 8Gi로 변경됨 | 최대 제한 128Gi |
4.6.8.2.2. 자체 서명된 CA 인증서 활성화
알 수 없는 기관 오류로 서명된 인증서를 방지하려면
활성화해야 합니다.
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 자체 서명된 CA 인증서를
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
DataProtectionApplication
CR 매니페스트의spec.backupLocations.velero.objectStorage.caCert
매개변수 및spec.backupLocations.velero.config
매개변수를 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.6.8.2.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용
별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다. OpenShift CLI(
oc
)가 설치되어 있어야 합니다.aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
다음 명령을 실행하여 별칭이 작동하는지 확인합니다.
예제
$ velero version Client: Version: v1.12.1-OADP Git commit: - Server: Version: v1.12.1-OADP
이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.
$ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}') $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
$ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
백업 로그를 가져오려면 다음 명령을 실행합니다.
$ velero backup logs <backup_name> --cacert /tmp/<your_cacert.txt>
이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.
-
Velero 포드가 다시 시작되면
/tmp/your-cacert.txt
파일이 사라지고 이전 단계의 명령을 다시 실행하여/tmp/your-cacert.txt
파일을 다시 생성해야 합니다. 다음 명령을 실행하여
/tmp/your-cacert.txt
파일이 여전히 있는지 확인할 수 있습니다.$ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt" /tmp/your-cacert.txt
향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.
4.6.8.3. 데이터 보호 애플리케이션 설치
DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application
)를 설치합니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
- 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
-
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하는 경우 기본 이름
cloud-credentials
를 사용하여 보안을 생성해야 합니다. 백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 두 개의 보안을 생성해야 합니다.
-
백업 위치에 대한 사용자 지정 이름이 있는
시크릿
입니다. 이 보안을DataProtectionApplication
CR에 추가합니다. -
스냅샷 위치에 대한 다른 사용자 지정 이름이 있는
시크릿
입니다. 이 보안을DataProtectionApplication
CR에 추가합니다.
참고설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈
credentials-velero
파일을 사용하여 기본Secret
을 생성할 수 있습니다. 기본Secret
이 없는 경우 설치가 실패합니다.-
백업 위치에 대한 사용자 지정 이름이 있는
절차
- Operators → 설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
- 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
YAML 보기를 클릭하고
DataProtectionApplication
매니페스트의 매개변수를 업데이트합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp 1 spec: configuration: velero: defaultPlugins: - aws 2 - kubevirt 3 - csi 4 - openshift 5 resourceTimeout: 10m 6 nodeAgent: 7 enable: true 8 uploaderType: kopia 9 podConfig: nodeSelector: <node_selector> 10 backupLocations: - velero: provider: gcp 11 default: true credential: key: cloud name: <default_secret> 12 objectStorage: bucket: <bucket_name> 13 prefix: <prefix> 14
- 1
- OADP의 기본 네임스페이스는
openshift-adp
입니다. 네임스페이스는 변수이며 구성 가능합니다. - 2
- 스토리지 위치에 해당하는 오브젝트 저장소 플러그인이 필요합니다. 모든 S3 공급자의 경우 필요한 플러그인은
aws
입니다. Azure 및 GCP 오브젝트 저장소의 경우azure
또는gcp
플러그인이 필요합니다. - 3
- 선택 사항:
kubevirt
플러그인은 OpenShift Virtualization과 함께 사용됩니다. - 4
- CSI 스냅샷을 사용하여 PV를 백업하는 경우
csi
기본 플러그인을 지정합니다.csi
플러그인은 Velero CSI 베타 스냅샷 API 를 사용합니다. 스냅샷 위치를 구성할 필요가 없습니다. - 5
openshift
플러그인은 필수입니다.- 6
- Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
- 7
- 관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
- 8
nodeAgent
를 활성화하고 파일 시스템 백업을 수행하려면 이 값을true
로 설정합니다.- 9
- 업로드로
kopia
또는restic
을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다.nodeAgent
는 데몬 세트를 배포합니다. 즉,nodeAgent
Pod가 각 작동 중인 노드에서 실행됩니다.Backup
CR에spec.defaultVolumesToFsBackup: true
를 추가하여 파일 시스템 백업을 구성할 수 있습니다. - 10
- Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
- 11
- 백업 공급자를 지정합니다.
- 12
- 백업 공급자에 기본 플러그인을 사용하는 경우
Secret
의 올바른 기본 이름(예:cloud-credentials-gcp
)을 지정합니다. 사용자 지정 이름을 지정하면 사용자 지정 이름이 백업 위치에 사용됩니다.Secret
이름을 지정하지 않으면 기본 이름이 사용됩니다. - 13
- 버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
- 14
- 버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
- 생성을 클릭합니다.
검증
다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다.
$ oc get all -n openshift-adp
출력 예
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
다음 명령을 실행하여 DPA(
DataProtectionApplication
)가 조정되었는지 확인합니다.$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
출력 예
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
유형이
Reconciled
으로 설정되어 있는지 확인합니다. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여
PHASE
가 사용
가능한지 확인합니다.$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
4.6.8.4. 클라이언트 버스트 및 QPS 설정으로 DPA 구성
버스트 설정은 제한을 적용하기 전에 velero
서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.
버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero
서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burst
및 dpa.configuration.velero.client-qps
필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
절차
다음 예와 같이 DPA에서
client-burst
및client-qps
필드를 구성합니다.데이터 보호 애플리케이션 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-dpa namespace: openshift-adp spec: backupLocations: - name: default velero: config: insecureSkipTLSVerify: "true" profile: "default" region: <bucket_region> s3ForcePathStyle: "true" s3Url: <bucket_url> credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: restic velero: client-burst: 500 1 client-qps: 300 2 defaultPlugins: - openshift - aws - kubevirt
4.6.8.4.1. 노드 에이전트 및 노드 라벨 구성
OADP의 DPA는 nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.
지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다.
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
다음 예제는 nodeSelector
의 안티 패턴이며 'node-role.kubernetes.io/infra: ""'
및 'node-role.kubernetes.io/worker: ""'
둘 다 노드에 있지 않으면 작동하지 않습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.6.8.4.2. OpenShift Data Foundation에서 재해 복구에 대한 오브젝트 버킷 클레임 생성
OpenShift Data Foundation에서 MCG(Multicloud Object Gateway) 버킷 backupStorageLocation
에 클러스터 스토리지를 사용하는 경우 OpenShift 웹 콘솔을 사용하여 OBC(Object Bucket Claim)를 생성합니다.
OBC(Object Bucket Claim)를 구성하지 않으면 백업을 사용할 수 없습니다.
달리 지정하지 않는 한 "NooBa"는 경량 오브젝트 스토리지를 제공하는 오픈 소스 프로젝트를 나타내며 "MCG(Multicloud Object Gateway)는 NooBaa의 Red Hat 배포를 나타냅니다.
MCG에 대한 자세한 내용은 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.
절차
- OpenShift 웹 콘솔을 사용하여 Object Bucket Claim 생성에 설명된 대로 OpenShift 웹 콘솔을 사용하여 Object Bucket 클레임(OBC)을 생성합니다.
4.6.8.4.3. DataProtectionApplication CR에서 CSI 활성화
CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication
CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.
사전 요구 사항
- 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
기본 플러그인을 추가합니다.
4.6.8.4.4. DataProtectionApplication에서 노드 에이전트 비활성화
백업에 Restic
,Kopia
또는 DataMover
를 사용하지 않는 경우 DataProtectionApplication
CR(사용자 정의 리소스)에서 nodeAgent
필드를 비활성화할 수 있습니다. nodeAgent
를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.
절차
nodeAgent
를 비활성화하려면enable
플래그를false
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: false 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 비활성화합니다.
nodeAgent
를 활성화하려면enable
플래그를true
로 설정합니다. 다음 예제를 참조하십시오.Example
DataProtectionApplication
CR# ... configuration: nodeAgent: enable: true 1 uploaderType: kopia # ...
- 1
- 노드 에이전트를 활성화합니다.
DataProtectionApplication
CR에서 nodeAgent
필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.
4.6.9. OpenShift Virtualization을 사용하여 데이터 보호를 위한 OpenShift API 구성
OADP Operator를 설치하고 백업 위치를 구성하여 OpenShift Virtualization을 사용하여 OADP(OpenShift API for Data Protection)를 설치할 수 있습니다. 그런 다음 데이터 보호 애플리케이션을 설치할 수 있습니다.
OpenShift API for Data Protection 을 사용하여 가상 머신을 백업하고 복원합니다.
OpenShift Virtualization을 사용한 OpenShift API for Data Protection에서는 다음과 같은 백업 및 복원 스토리지 옵션을 지원합니다.
- CSI(Container Storage Interface) 백업
- DataMover를 사용한 CSI(Container Storage Interface) 백업
다음 스토리지 옵션은 제외됩니다.
- 파일 시스템 백업 및 복원
- 볼륨 스냅샷 백업 및 복원
자세한 내용은 파일 시스템 백업: Kopia 또는 Restic을 사용하여 애플리케이션 백업을 참조하십시오.
제한된 네트워크 환경에서 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.
4.6.9.1. OpenShift Virtualization을 사용하여 OADP 설치 및 구성
클러스터 관리자는 OADP Operator를 설치하여 OADP를 설치합니다.
Operator는 Velero 1.14 를 설치합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
절차
- 스토리지 공급자의 지침에 따라 OADP Operator를 설치합니다.
-
kubevirt
및openshift
OADP 플러그인으로 DPA(Data Protection Application)를 설치합니다. Backup
CR(사용자 정의 리소스)을 생성하여 가상 머신을 백업합니다.주의Red Hat 지원은 다음 옵션으로 제한됩니다.
- CSI 백업
- DataMover를 사용한 CSI 백업.
Restore CR을 생성하여 Backup
CR을 복원합니다
.
4.6.9.2. 데이터 보호 애플리케이션 설치
DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application
)를 설치합니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
- 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하는 경우 기본 이름
cloud-credentials
를 사용하여 보안을 생성해야 합니다.참고설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈
credentials-velero
파일을 사용하여 기본Secret
을 생성할 수 있습니다. 기본Secret
이 없는 경우 설치가 실패합니다.
절차
- Operators → 설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
- 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
YAML 보기를 클릭하고
DataProtectionApplication
매니페스트의 매개변수를 업데이트합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp 1 spec: configuration: velero: defaultPlugins: - kubevirt 2 - gcp 3 - csi 4 - openshift 5 resourceTimeout: 10m 6 nodeAgent: 7 enable: true 8 uploaderType: kopia 9 podConfig: nodeSelector: <node_selector> 10 backupLocations: - velero: provider: gcp 11 default: true credential: key: cloud name: <default_secret> 12 objectStorage: bucket: <bucket_name> 13 prefix: <prefix> 14
- 1
- OADP의 기본 네임스페이스는
openshift-adp
입니다. 네임스페이스는 변수이며 구성 가능합니다. - 2
kubevirt
플러그인은 OpenShift Virtualization에 필수입니다.- 3
- 백업 공급자의 플러그인을 지정합니다(예:
gcp
). - 4
- CSI 스냅샷을 사용하여 PV를 백업하려면
csi
플러그인이 필요합니다.csi
플러그인은 Velero CSI 베타 스냅샷 API 를 사용합니다. 스냅샷 위치를 구성할 필요가 없습니다. - 5
openshift
플러그인은 필수입니다.- 6
- Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
- 7
- 관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
- 8
nodeAgent
를 활성화하고 파일 시스템 백업을 수행하려면 이 값을true
로 설정합니다.- 9
- Built-in DataMover를 사용하려면 업로드기로
kopia
를 입력합니다.nodeAgent
는 데몬 세트를 배포합니다. 즉,nodeAgent
Pod가 각 작동 중인 노드에서 실행됩니다.Backup
CR에spec.defaultVolumesToFsBackup: true
를 추가하여 파일 시스템 백업을 구성할 수 있습니다. - 10
- Kopia를 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia는 모든 노드에서 실행됩니다.
- 11
- 백업 공급자를 지정합니다.
- 12
- 백업 공급자에 기본 플러그인을 사용하는 경우
Secret
의 올바른 기본 이름(예:cloud-credentials-gcp
)을 지정합니다. 사용자 지정 이름을 지정하면 사용자 지정 이름이 백업 위치에 사용됩니다.Secret
이름을 지정하지 않으면 기본 이름이 사용됩니다. - 13
- 버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
- 14
- 버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
- 생성을 클릭합니다.
검증
다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다.
$ oc get all -n openshift-adp
출력 예
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
다음 명령을 실행하여 DPA(
DataProtectionApplication
)가 조정되었는지 확인합니다.$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
출력 예
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
유형이
Reconciled
으로 설정되어 있는지 확인합니다. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여
PHASE
가 사용
가능한지 확인합니다.$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
VM이 재부팅된 직후 Microsoft Windows 가상 머신(VM)의 백업을 실행하는 경우 부분적으로Failed
오류와 함께 백업이 실패할 수 있습니다. 이는 VM이 부팅된 직후 Microsoft Windows Volume shadow Copy Service(VSS) 및 게스트 에이전트(GA) 서비스가 준비되지 않았기 때문입니다. VSS 및 GA 서비스가 준비되지 않아 백업이 실패합니다. 이러한 경우 VM이 부팅된 후 몇 분 후에 백업을 다시 시도합니다.
4.6.9.3. 단일 VM 백업
여러 VM(가상 머신)이 있고 그 중 하나만 백업하려는 경우 라벨 선택기를 사용하여 백업에 포함해야 하는 VM을 필터링할 수 있습니다. app: vmname
레이블을 사용하여 VM을 필터링할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- 네임스페이스에 여러 VM이 실행되고 있습니다.
-
kubevirt
플러그인을 DPA(DataProtectionApplication
) CR(사용자 정의 리소스)에 추가했습니다. -
BackupStorageLocation
CR을DataProtectionApplication
CR에 구성했으며BackupStorageLocation
을 사용할 수 있습니다.
절차
다음 예에 표시된 대로
Backup
CR을 구성합니다.Backup
CR의 예apiVersion: velero.io/v1 kind: Backup metadata: name: vmbackupsingle namespace: openshift-adp spec: snapshotMoveData: true includedNamespaces: - <vm_namespace> 1 labelSelector: matchLabels: app: <vm_app_name> 2 storageLocation: <backup_storage_location_name> 3
Backup
CR을 생성하려면 다음 명령을 실행합니다.$ oc apply -f <backup_cr_file_name> 1
- 1
Backup
CR 파일의 이름을 지정합니다.
4.6.9.4. 단일 VM 복원
Backup
CR(사용자 정의 리소스)의 라벨 선택기를 사용하여 단일 VM(가상 머신)을 백업한 후 Restore
CR을 생성하여 백업을 가리킬 수 있습니다. 이 복원 작업에서는 단일 VM을 복원합니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- 라벨 선택기를 사용하여 단일 VM을 백업했습니다.
절차
4.6.9.5. 여러 VM의 백업에서 단일 VM 복원
여러 VM(가상 머신)이 포함된 백업이 있고 하나의 VM만 복원하려는 경우 Restore
CR에서 LabelSelectors
섹션을 사용하여 복원할 VM을 선택할 수 있습니다. VM에 연결된 PVC(영구 볼륨 클레임)가 올바르게 복원되고 복원된 VM이 프로비저닝
상태에 있지 않도록 하려면 app: <vm_name
> 및 kubevirt.io/created-by
레이블을 모두 사용합니다. kubevirt.io/created-by
레이블과 일치하려면 VM의 UID
를 사용합니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- 백업해야 하는 VM에 레이블이 지정되어 있습니다.
- 여러 VM의 백업이 있습니다.
절차
여러 VM을 백업하기 전에 다음 명령을 실행하여 VM에 레이블을 지정했는지 확인합니다.
$ oc label vm <vm_name> app=<vm_name> -n openshift-adp
다음 예와 같이
Restore
CR에서 라벨 선택기를 구성합니다.CR
복원
예apiVersion: velero.io/v1 kind: Restore metadata: name: singlevmrestore namespace: openshift-adp spec: backupName: multiplevmbackup restorePVs: true LabelSelectors: - matchLabels: kubevirt.io/created-by: <datavolume_uid> 1 - matchLabels: app: <vm_name> 2
VM을 복원하려면 다음 명령을 실행합니다.
$ oc apply -f <restore_cr_file_name> 1
- 1
Restore
CR 파일의 이름을 지정합니다.
4.6.9.6. 클라이언트 버스트 및 QPS 설정으로 DPA 구성
버스트 설정은 제한을 적용하기 전에 velero
서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.
버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero
서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burst
및 dpa.configuration.velero.client-qps
필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
절차
다음 예와 같이 DPA에서
client-burst
및client-qps
필드를 구성합니다.데이터 보호 애플리케이션 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-dpa namespace: openshift-adp spec: backupLocations: - name: default velero: config: insecureSkipTLSVerify: "true" profile: "default" region: <bucket_region> s3ForcePathStyle: "true" s3Url: <bucket_url> credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: restic velero: client-burst: 500 1 client-qps: 300 2 defaultPlugins: - openshift - aws - kubevirt
4.6.9.6.1. 노드 에이전트 및 노드 라벨 구성
OADP의 DPA는 nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.
지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다.
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
다음 예제는 nodeSelector
의 안티 패턴이며 'node-role.kubernetes.io/infra: ""'
및 'node-role.kubernetes.io/worker: ""'
둘 다 노드에 있지 않으면 작동하지 않습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.6.9.7. 증분 백업 지원 정보
OADP는 컨테이너화된 워크로드와 OpenShift Virtualization 워크로드 모두에 대해 블록
및 Filesystem
영구 볼륨의 증분 백업을 지원합니다. 다음 표에는 파일 시스템 백업(FSB), CSI(Container Storage Interface) 및 CSI 데이터 Mover에 대한 지원이 요약되어 있습니다.
볼륨 모드 | FSB - Restic | FSB - Kopia | CSI | CSI 데이터 Mover |
---|---|---|---|---|
파일 시스템 | S [1], I [2] | S [1], I [2] | S [1] | S [1], I [2] |
블록 | N [3] | N [3] | S [1] | S [1], I [2] |
볼륨 모드 | FSB - Restic | FSB - Kopia | CSI | CSI 데이터 Mover |
---|---|---|---|---|
파일 시스템 | N [3] | N [3] | S [1] | S [1], I [2] |
블록 | N [3] | N [3] | S [1] | S [1], I [2] |
- 지원되는 백업
- 증분 백업 지원
- 지원되지 않음
CSI Data Mover 백업은 uploaderType
과 관계없이 Kopia를 사용합니다.
Red Hat은 OADP 버전 1.3.0 이상과 OpenShift Virtualization 버전 4.14 이상만 지원합니다.
1.3.0 이전 OADP 버전은 OpenShift Virtualization의 백업 및 복원에 지원되지 않습니다.
4.6.10. 두 개 이상의 Backup Storage 위치를 사용하여 OADP(OpenShift API for Data Protection) 구성
DPA(Data Protection Application)에서 하나 이상의 백업 스토리지 위치(BSL)를 구성할 수 있습니다. 백업을 생성할 때 백업을 저장할 위치를 선택할 수도 있습니다. 이 구성을 사용하면 다음과 같은 방법으로 백업을 저장할 수 있습니다.
- 다른 리전으로
- 다른 스토리지 공급자로 전환
OADP는 두 개 이상의 BSL을 구성하기 위한 여러 자격 증명을 지원하므로 모든 BSL과 함께 사용할 인증 정보를 지정할 수 있습니다.
4.6.10.1. 두 개 이상의 BSL로 DPA 구성
DPA를 두 개 이상의 BSL로 구성하고 클라우드 공급자가 제공하는 자격 증명을 지정할 수 있습니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성해야 합니다.
절차
두 개 이상의 BSL로 DPA를 구성합니다. 다음 예제를 참조하십시오.
DPA 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication #... backupLocations: - name: aws 1 velero: provider: aws default: true 2 objectStorage: bucket: <bucket_name> 3 prefix: <prefix> 4 config: region: <region_name> 5 profile: "default" credential: key: cloud name: cloud-credentials 6 - name: odf 7 velero: provider: aws default: false objectStorage: bucket: <bucket_name> prefix: <prefix> config: profile: "default" region: <region_name> s3Url: <url> 8 insecureSkipTLSVerify: "true" s3ForcePathStyle: "true" credential: key: cloud name: <custom_secret_name_odf> 9 #...
- 1
- 첫 번째 BSL의 이름을 지정합니다.
- 2
- 이 매개 변수는 이 BSL이 기본 BSL임을 나타냅니다.
Backup CR
에 BSL이 설정되지 않은 경우 기본 BSL이 사용됩니다. 하나의 BSL만 기본값으로 설정할 수 있습니다. - 3
- 버킷 이름을 지정합니다.
- 4
- Velero 백업의 접두사를 지정합니다(예:
velero
). - 5
- 버킷의 AWS 리전을 지정합니다.
- 6
- 생성한 기본
Secret
오브젝트의 이름을 지정합니다. - 7
- 두 번째 BSL의 이름을 지정합니다.
- 8
- S3 끝점의 URL을 지정합니다.
- 9
시크릿
의 올바른 이름을 지정합니다(예:custom_secret_name_odf
).Secret
이름을 지정하지 않으면 기본 이름이 사용됩니다.
백업 CR에 사용할 BSL을 지정합니다. 다음 예제를 참조하십시오.
백업 CR의 예
apiVersion: velero.io/v1 kind: Backup # ... spec: includedNamespaces: - <namespace> 1 storageLocation: <backup_storage_location> 2 defaultVolumesToFsBackup: true
4.6.10.2. 두 개의 BSL 사용 사례
이 사용 사례에서는 두 개의 클라우드 인증 정보를 사용하여 두 개의 스토리지 위치로 DPA를 구성합니다. 기본 BSL을 사용하여 데이터베이스와 함께 애플리케이션을 백업합니다. OADP는 백업 리소스를 기본 BSL에 저장합니다. 그런 다음 두 번째 BSL을 사용하여 애플리케이션을 다시 백업합니다.
사전 요구 사항
- OADP Operator를 설치해야 합니다.
- AWS S3 및 MCG(Multicloud Object Gateway)의 두 개의 백업 스토리지 위치를 구성해야 합니다.
- Red Hat OpenShift 클러스터에 배포된 데이터베이스가 있는 애플리케이션이 있어야 합니다.
절차
다음 명령을 실행하여 기본 이름으로 AWS S3 스토리지 공급자에 대한 첫 번째 보안을 생성합니다.
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=<aws_credentials_file_name> 1
- 1
- AWS S3의 클라우드 인증 정보 파일의 이름을 지정합니다.
다음 명령을 실행하여 사용자 지정 이름으로 MCG의 두 번째 보안을 생성합니다.
$ oc create secret generic mcg-secret -n openshift-adp --from-file cloud=<MCG_credentials_file_name> 1
- 1
- MCG의 클라우드 인증 정보 파일의 이름을 지정합니다.
mcg-secret
사용자 정의 시크릿의 이름을 확인합니다.
다음 예와 같이 두 개의 BSL로 DPA를 구성합니다.
DPA 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: two-bsl-dpa namespace: openshift-adp spec: backupLocations: - name: aws velero: config: profile: default region: <region_name> 1 credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> 2 prefix: velero provider: aws - name: mcg velero: config: insecureSkipTLSVerify: "true" profile: noobaa region: <region_name> 3 s3ForcePathStyle: "true" s3Url: <s3_url> 4 credential: key: cloud name: mcg-secret 5 objectStorage: bucket: <bucket_name_mcg> 6 prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: kopia velero: defaultPlugins: - openshift - aws
다음 명령을 실행하여 DPA를 생성합니다.
$ oc create -f <dpa_file_name> 1
- 1
- 구성한 DPA의 파일 이름을 지정합니다.
다음 명령을 실행하여 DPA가 조정되었는지 확인합니다.
$ oc get dpa -o yaml
다음 명령을 실행하여 BSL을 사용할 수 있는지 확인합니다.
$ oc get bsl
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT aws Available 5s 3m28s true mcg Available 5s 3m28s
기본 BSL을 사용하여 백업 CR을 생성합니다.
참고다음 예제에서는
storageLocation
필드가 백업 CR에 지정되지 않습니다.백업 CR의 예
apiVersion: velero.io/v1 kind: Backup metadata: name: test-backup1 namespace: openshift-adp spec: includedNamespaces: - <mysql_namespace> 1 defaultVolumesToFsBackup: true
- 1
- 클러스터에 설치된 애플리케이션의 네임스페이스를 지정합니다.
다음 명령을 실행하여 백업을 생성합니다.
$ oc apply -f <backup_file_name> 1
- 1
- 백업 CR 파일의 이름을 지정합니다.
다음 명령을 실행하여 백업이 기본 BSL로 완료되었는지 확인합니다.
$ oc get backups.velero.io <backup_name> -o yaml 1
- 1
- 백업 이름을 지정합니다.
MCG를 BSL로 사용하여 백업 CR을 생성합니다. 다음 예제에서는 백업 CR 생성 시 두 번째
storageLocation
값이 지정됩니다.백업
CR
의 예apiVersion: velero.io/v1 kind: Backup metadata: name: test-backup1 namespace: openshift-adp spec: includedNamespaces: - <mysql_namespace> 1 storageLocation: mcg 2 defaultVolumesToFsBackup: true
다음 명령을 실행하여 두 번째 백업을 생성합니다.
$ oc apply -f <backup_file_name> 1
- 1
- 백업 CR 파일의 이름을 지정합니다.
다음 명령을 실행하여 스토리지 위치를 MCG로 사용하여 백업이 완료되었는지 확인합니다.
$ oc get backups.velero.io <backup_name> -o yaml 1
- 1
- 백업 이름을 지정합니다.
추가 리소스
4.6.11. 두 개 이상의 Volume Snapshot Location으로 OADP(OpenShift API for Data Protection) 구성
스냅샷을 다른 클라우드 공급자 지역에 저장하도록 하나 이상의 볼륨 스냅샷 위치(VSL)를 구성할 수 있습니다.
4.6.11.1. 두 개 이상의 VSL로 DPA 구성
두 개 이상의 VSL로 DPA를 구성하고 클라우드 공급자가 제공하는 인증 정보를 지정합니다. 영구 볼륨과 동일한 리전에 스냅샷 위치를 구성해야 합니다. 다음 예제를 참조하십시오.
DPA 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication #... snapshotLocations: - velero: config: profile: default region: <region> 1 credential: key: cloud name: cloud-credentials provider: aws - velero: config: profile: default region: <region> credential: key: cloud name: <custom_credential> 2 provider: aws #...
4.7. OADP 설치 제거
4.7.1. 데이터 보호를 위한 OpenShift API 설치 제거
OADP Operator를 삭제하여 OADP(Data Protection)용 OpenShift API를 설치 제거합니다. 자세한 내용은 클러스터에서 Operator 삭제를 참조하십시오.
4.8. OADP 백업
4.8.1. 애플리케이션 백업
빈번한 백업은 백업 스토리지 위치에 스토리지를 사용할 수 있습니다. 로컬이 아닌 백업(예: S3 버킷)을 사용하는 경우 백업, 보존 시간, PV(영구 볼륨)의 데이터 양을 확인합니다. 수행된 모든 백업은 만료될 때까지 유지되므로 일정의 라이브(TTL) 설정도 확인합니다.
Backup
사용자 정의 리소스(CR)를 생성하여 애플리케이션을 백업할 수 있습니다. 자세한 내용은 Backup CR 생성을 참조하십시오.
-
Backup
CR은 S3 오브젝트 스토리지에 Kubernetes 리소스 및 내부 이미지에 대한 백업 파일을 생성합니다. -
클라우드 공급자에 기본 스냅샷 API가 있거나 CSI 스냅샷을 지원하는 경우
Backup
CR은 스냅샷을 생성하여 PV(영구 볼륨)를 백업합니다. CSI 스냅샷 작업에 대한 자세한 내용은 CSI 스냅샷을 사용하여 영구 볼륨 백업을 참조하십시오.
CSI 볼륨 스냅샷에 대한 자세한 내용은 CSI 볼륨 스냅샷을 참조하십시오.
오브젝트 스토리지용 버킷 생성을 자동화하는 CloudStorage
API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
API는 CloudStorage 오브젝트를 사용하고 OADP에서 CloudStorage
CloudStorage
API를 사용하여 BackupStorageLocation
으로 사용할 S3 버킷을 자동으로 생성하도록 하는 경우 기술 프리뷰 기능입니다.
CloudStorage
API는 기존 S3 버킷을 지정하여 BackupStorageLocation
오브젝트를 수동으로 생성할 수 있도록 지원합니다. S3 버킷을 자동으로 생성하는 CloudStorage
API는 현재 AWS S3 스토리지에만 활성화됩니다.
- 클라우드 공급자가 스냅샷을 지원하지 않거나 애플리케이션이 NFS 데이터 볼륨에 있는 경우 Kopia 또는 Restic을 사용하여 백업을 생성할 수 있습니다. 파일 시스템 백업: Kopia 또는 Restic을 사용하여 애플리케이션 백업을 참조하십시오.
…/.snapshot: 읽기 전용 파일 시스템
오류로 인해 실패합니다.
…/.snapshot
디렉터리는 여러 NFS 서버에서 사용하는 스냅샷 복사 디렉터리입니다. 이 디렉터리에는 기본적으로 읽기 전용 액세스 권한이 있으므로 Velero는 이 디렉터리로 복원할 수 없습니다.
.snapshot
디렉터리에 Velero 쓰기 액세스 권한을 부여하지 말고 이 디렉터리에 대한 클라이언트 액세스를 비활성화합니다.
OADP(OpenShift API for Data Protection)는 다른 소프트웨어에 의해 생성된 볼륨 스냅샷 백업 기능을 지원하지 않습니다.
4.8.1.1. 백업을 실행하고 복원하기 전에 리소스 미리 보기
OADP는 유형, 네임스페이스 또는 레이블을 기반으로 애플리케이션 리소스를 백업합니다. 즉, 백업이 완료된 후 리소스를 볼 수 있습니다. 마찬가지로 복원 작업이 완료된 후 네임스페이스, 영구 볼륨(PV) 또는 라벨을 기반으로 복원된 오브젝트를 볼 수 있습니다. 리소스를 미리 미리 보려면 백업 및 복원 작업을 예행히 실행할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
절차
실제 백업을 실행하기 전에 백업에 포함된 리소스를 미리 보려면 다음 명령을 실행합니다.
$ velero backup create <backup-name> --snapshot-volumes false 1
- 1
--snapshot-volumes
매개변수 값을false
로 지정합니다.
백업 리소스에 대한 자세한 내용을 보려면 다음 명령을 실행합니다.
$ velero describe backup <backup_name> --details 1
- 1
- 백업 이름을 지정합니다.
실제 복원을 실행하기 전에 복원에 포함된 리소스를 미리 보려면 다음 명령을 실행합니다.
$ velero restore create --from-backup <backup-name> 1
- 1
- 백업 리소스를 검토하기 위해 생성된 백업의 이름을 지정합니다.
중요velero restore create
명령은 클러스터에 복원 리소스를 생성합니다. 리소스를 검토한 후 복원의 일부로 생성된 리소스를 삭제해야 합니다.복원 리소스에 대한 자세한 내용을 보려면 다음 명령을 실행합니다.
$ velero describe restore <restore_name> --details 1
- 1
- 복원의 이름을 지정합니다.
백업 작업 전이나 후에 명령을 실행하기 위해 백업 후크를 생성할 수 있습니다. 백업 후크 생성 을 참조하십시오.
Backup
CR 대신 Schedule
CR을 생성하여 백업을 예약할 수 있습니다. 스케줄 CR을 사용하여 백업 스케줄링 을 참조하십시오.
4.8.1.2. 확인된 문제
OpenShift Container Platform 4.14는 Restic 복원 프로세스 중에 Pod 준비 상태를 방해할 수 있는 PSA(Pod 보안 승인) 정책을 적용합니다.
이 문제는 OADP 1.1.6 및 OADP 1.2.2 릴리스에서 해결되어 사용자가 이러한 릴리스로 업그레이드하는 것이 좋습니다.
4.8.2. 백업 CR 생성
Backup CR(사용자 정의 리소스)을 생성하여 Kubernetes 이미지, 내부 이미지 및 PV(영구 볼륨)를 Backup
합니다.
사전 요구 사항
- OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
-
DataProtectionApplication
CR은Ready
상태에 있어야 합니다. 백업 위치 사전 요구 사항:
- Velero에 대해 구성된 S3 오브젝트 스토리지가 있어야 합니다.
-
DataProtectionApplication
CR에 구성된 백업 위치가 있어야 합니다.
스냅샷 위치 사전 요구 사항:
- 클라우드 공급자에는 기본 스냅샷 API가 있거나 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
-
CSI 스냅샷의 경우 CSI 드라이버를 등록하려면
VolumeSnapshotClass
CR을 생성해야 합니다. -
DataProtectionApplication
CR에 구성된 볼륨 위치가 있어야 합니다.
절차
다음 명령을 입력하여
backupStorageLocations
CR을 검색합니다.$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
다음 예와 같이
Backup
CR을 생성합니다.apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> labels: velero.io/storage-location: default namespace: openshift-adp spec: hooks: {} includedNamespaces: - <namespace> 1 includedResources: [] 2 excludedResources: [] 3 storageLocation: <velero-sample-1> 4 ttl: 720h0m0s 5 labelSelector: 6 matchLabels: app: <label_1> app: <label_2> app: <label_3> orLabelSelectors: 7 - matchLabels: app: <label_1> app: <label_2> app: <label_3>
- 1
- 백업할 네임스페이스 배열을 지정합니다.
- 2
- 선택 사항: 백업에 포함할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: 'pods'의 경우')이거나 정규화된 것일 수 있습니다. 지정하지 않으면 모든 리소스가 포함됩니다.
- 3
- 선택 사항: 백업에서 제외할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: 'pods'의 경우')이거나 정규화된 것일 수 있습니다.
- 4
backupStorageLocations
CR의 이름을 지정합니다.- 5
ttl
필드는 생성된 백업의 보존 시간과 백업 데이터를 정의합니다. 예를 들어 Restic을 백업 도구로 사용하는 경우 백업이 만료될 때까지 백업된 데이터 항목과 PV(영구 볼륨)의 데이터 콘텐츠가 저장됩니다. 그러나 이러한 데이터를 저장하면 대상 백업 위치에 더 많은 공간이 사용됩니다. 추가 스토리지는 만료되지 않은 다른 완료된 백업이 시간 초과되었을 수 있기 전에 생성되는 빈번한 백업과 함께 사용됩니다.- 6
- 지정된 라벨이 모두 있는 백업 리소스의 {key,value} 쌍의 맵입니다.
- 7
- 지정된 라벨이 하나 이상 있는 백업 리소스의 {key,value} 쌍의 맵입니다.
Backup
CR의 상태가Completed
인지 확인합니다.$ oc get backups.velero.io -n openshift-adp <backup> -o jsonpath='{.status.phase}'
4.8.3. CSI 스냅샷을 사용하여 영구 볼륨 백업
Backup CR을 생성하기 전에 클라우드 스토리지의 VolumeSnapshotClass
CR(사용자 정의 리소스)을 편집하여 CSI(Container Storage Interface) 스냅샷을 사용하여 영구 볼륨을 백업
합니다. CSI 볼륨 스냅샷을 참조하십시오.
자세한 내용은 Backup CR 생성을 참조하십시오.
사전 요구 사항
- 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.
-
DataProtectionApplication
CR에서 CSI를 활성화해야 합니다.
절차
volume
Class
CR에metadata.labels.velero.io/csi-volumesnapshot-class: "true"
키-값 쌍을 추가합니다.설정 파일 예
apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: name: <volume_snapshot_class_name> labels: velero.io/csi-volumesnapshot-class: "true" 1 annotations: snapshot.storage.kubernetes.io/is-default-class: true 2 driver: <csi_driver> deletionPolicy: <deletion_policy_type> 3
다음 단계
-
이제
Backup
CR을 생성할 수 있습니다.
4.8.4. 파일 시스템 백업을 사용하여 애플리케이션 백업: Kopia 또는 Restic
OADP를 사용하여 볼륨의 파일 시스템에서 Pod에 연결된 Kubernetes 볼륨을 백업하고 복원할 수 있습니다. 이 프로세스를 파일 시스템 백업(FSB) 또는 Pod 볼륨 백업(PVB)이라고 합니다. 이는 오픈 소스 백업 툴 Restic 또는 Kopia의 모듈을 사용하여 수행됩니다.
클라우드 공급자가 스냅샷을 지원하지 않거나 애플리케이션이 NFS 데이터 볼륨에 있는 경우 FSB를 사용하여 백업을 생성할 수 있습니다.
OADP와 FSB 통합은 거의 모든 유형의 Kubernetes 볼륨을 백업하고 복원하는 솔루션을 제공합니다. 이러한 통합은 OADP의 추가 기능이며 기존 기능을 대체할 수 없습니다.
Backup CR(사용자 정의 리소스)을 편집하여 Kopia 또는 Restic을 사용하여 Kubernetes 리소스, 내부 이미지 및 영구 볼륨을 백업
합니다.
DataProtectionApplication
CR에서 스냅샷 위치를 지정할 필요가 없습니다.
OADP 버전 1.3 이상에서는 애플리케이션 백업에 Kopia 또는 Restic 중 하나를 사용할 수 있습니다.
기본 제공 DataMover의 경우 Kopia를 사용해야 합니다.
OADP 버전 1.2 및 이전 버전에서는 애플리케이션 백업에 Restic만 사용할 수 있습니다.
FSB는 hostPath
볼륨 백업을 지원하지 않습니다. 자세한 내용은 FSB 제한 사항을 참조하십시오.
…/.snapshot: 읽기 전용 파일 시스템
오류로 인해 실패합니다.
…/.snapshot
디렉터리는 여러 NFS 서버에서 사용하는 스냅샷 복사 디렉터리입니다. 이 디렉터리에는 기본적으로 읽기 전용 액세스 권한이 있으므로 Velero는 이 디렉터리로 복원할 수 없습니다.
.snapshot
디렉터리에 Velero 쓰기 액세스 권한을 부여하지 말고 이 디렉터리에 대한 클라이언트 액세스를 비활성화합니다.
사전 요구 사항
- OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
-
DataProtectionApplication
CR에서spec.configuration.
을nodeAgent
.enablefalse
로 설정하여 기본 nodeAgent 설치를 비활성화해서는 안 됩니다. -
spec.configuration.nodeAgent.uploaderType
을DataProtectionApplication
CR에서kopia
또는restic
으로 설정하여 업로드로 Kopia 또는 Restic을 선택해야 합니다. -
DataProtectionApplication
CR은Ready
상태에 있어야 합니다.
절차
다음 예와 같이
Backup
CR을 생성합니다.apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> labels: velero.io/storage-location: default namespace: openshift-adp spec: defaultVolumesToFsBackup: true 1 ...
- 1
- OADP 버전 1.2 이상에서
spec
블록 내에defaultVolumesToFsBackup: true
설정을 추가합니다. OADP 버전 1.1에서defaultVolumesToRestic: true
를 추가합니다.
4.8.5. 백업 후크 생성
백업을 수행할 때 백업 중인 Pod에 따라 Pod 내의 컨테이너에서 실행할 하나 이상의 명령을 지정할 수 있습니다.
사용자 정의 작업 처리(사전 후크) 전에 또는 모든 사용자 정의 작업이 완료된 후 및 사용자 지정 작업에 의해 지정된 추가 항목이 백업(후크)되도록 명령을 구성할 수 있습니다.
Backup CR(사용자 정의 리소스)을 편집하여 Pod의 컨테이너에서 명령을 실행하는 백업
후크를 생성합니다.
절차
다음 예제와 같이
Backup
CR의spec.hooks
블록에 후크를 추가합니다.apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> namespace: openshift-adp spec: hooks: resources: - name: <hook_name> includedNamespaces: - <namespace> 1 excludedNamespaces: 2 - <namespace> includedResources: [] - pods 3 excludedResources: [] 4 labelSelector: 5 matchLabels: app: velero component: server pre: 6 - exec: container: <container> 7 command: - /bin/uname 8 - -a onError: Fail 9 timeout: 30s 10 post: 11 ...
- 1
- 선택 사항: 후크가 적용되는 네임스페이스를 지정할 수 있습니다. 이 값을 지정하지 않으면 후크가 모든 네임스페이스에 적용됩니다.
- 2
- 선택 사항: 후크가 적용되지 않는 네임스페이스를 지정할 수 있습니다.
- 3
- 현재 Pod는 후크를 적용할 수 있는 유일한 지원 리소스입니다.
- 4
- 선택 사항: 후크가 적용되지 않는 리소스를 지정할 수 있습니다.
- 5
- 선택 사항: 이 후크는 라벨과 일치하는 오브젝트에만 적용됩니다. 이 값을 지정하지 않으면 후크가 모든 오브젝트에 적용됩니다.
- 6
- 백업 전에 실행할 후크 배열입니다.
- 7
- 선택 사항: 컨테이너를 지정하지 않으면 Pod의 첫 번째 컨테이너에서 명령이 실행됩니다.
- 8
- 추가되는
init
컨테이너의 진입점입니다. - 9
- 오류 처리에 허용되는 값은
Fail
및Continue
입니다. 기본값은Fail
입니다. - 10
- 선택 사항: 명령을 실행할 때까지 대기하는 시간입니다. 기본값은
30s
입니다. - 11
- 이 블록은 사전 백업 후크와 동일한 매개변수를 사용하여 백업 후 실행할 후크 배열을 정의합니다.
4.8.6. 스케줄 CR을 사용하여 백업 예약
schedule 작업을 사용하면 Cron 표현식에 지정된 특정 시간에 데이터 백업을 생성할 수 있습니다.
Backup
CR 대신 Schedule
CR(사용자 정의 리소스)을 생성하여 백업을 예약합니다.
다른 백업이 생성되기 전에 백업이 완료될 때까지 백업 일정에 충분한 시간을 남겨 둡니다.
예를 들어 네임스페이스 백업에 일반적으로 10분이 걸리는 경우 15분마다 백업을 더 자주 예약하지 마십시오.
사전 요구 사항
- OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
-
DataProtectionApplication
CR은Ready
상태에 있어야 합니다.
절차
backupStorageLocations
CR을 검색합니다.$ oc get backupStorageLocations -n openshift-adp
출력 예
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
다음 예와 같이
Schedule
CR을 생성합니다.$ cat << EOF | oc apply -f - apiVersion: velero.io/v1 kind: Schedule metadata: name: <schedule> namespace: openshift-adp spec: schedule: 0 7 * * * 1 template: hooks: {} includedNamespaces: - <namespace> 2 storageLocation: <velero-sample-1> 3 defaultVolumesToFsBackup: true 4 ttl: 720h0m0s 5 EOF
참고특정 간격으로 백업을 예약하려면 다음 형식으로 <
;duration_in_minutes&
gt;를 입력합니다.schedule: "*/10 * * * *"
따옴표 사이에 분 값을 입력합니다(
" "
).- 1
- 백업을 예약하는 Cron 표현식(예:
0 7 * * *
*)은 7:00에 매일 백업을 수행합니다. - 2
- 백업할 네임스페이스 배열입니다.
- 3
backupStorageLocations
CR의 이름입니다.- 4
- 선택 사항: OADP 버전 1.2 이상에서 Restic을 사용하여 볼륨 백업을 수행할 때
defaultVolumesToFsBackup: true
key-value 쌍을 구성에 추가합니다. OADP 버전 1.1에서 Restic을 사용하여 볼륨을 백업할 때defaultVolumesToRestic: true
key-value 쌍을 추가합니다. - 5
ttl
필드는 생성된 백업의 보존 시간과 백업 데이터를 정의합니다. 예를 들어 Restic을 백업 도구로 사용하는 경우 백업이 만료될 때까지 백업된 데이터 항목과 PV(영구 볼륨)의 데이터 콘텐츠가 저장됩니다. 그러나 이러한 데이터를 저장하면 대상 백업 위치에 더 많은 공간이 사용됩니다. 추가 스토리지는 만료되지 않은 다른 완료된 백업이 시간 초과되었을 수 있기 전에 생성되는 빈번한 백업과 함께 사용됩니다.
예약된 백업이 실행된 후
Schedule
CR의 상태가Completed
인지 확인합니다.$ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
4.8.7. 백업 삭제
DeleteBackupRequest
CR(사용자 정의 리소스)을 생성하거나 다음 절차에 설명된 대로 velero backup delete
명령을 실행하여 백업을 삭제할 수 있습니다.
백업 방법에 따라 볼륨 백업 아티팩트는 다른 시간에 삭제됩니다.
- Restic: 백업 삭제 후 다음 전체 유지 관리 주기에서 아티팩트가 삭제됩니다.
- CSI(Container Storage Interface): 백업을 삭제할 때 아티팩트가 즉시 삭제됩니다.
- Kopia: 아티팩트는 백업 삭제 후 Kopia 리포지토리의 세 가지 유지 관리 주기 후에 삭제됩니다.
4.8.7.1. DeleteBackupRequest CR을 생성하여 백업 삭제
DeleteBackupRequest
CR(사용자 정의 리소스)을 생성하여 백업을 삭제할 수 있습니다.
사전 요구 사항
- 애플리케이션의 백업을 실행했습니다.
절차
DeleteBackupRequest
CR 매니페스트 파일을 생성합니다.apiVersion: velero.io/v1 kind: DeleteBackupRequest metadata: name: deletebackuprequest namespace: openshift-adp spec: backupName: <backup_name> 1
- 1
- 백업 이름을 지정합니다.
DeleteBackupRequest
CR을 적용하여 백업을 삭제합니다.$ oc apply -f <deletebackuprequest_cr_filename>
4.8.7.2. Velero CLI를 사용하여 백업 삭제
Velero CLI를 사용하여 백업을 삭제할 수 있습니다.
사전 요구 사항
- 애플리케이션의 백업을 실행했습니다.
- Velero CLI를 다운로드하여 클러스터의 Velero 바이너리에 액세스할 수 있습니다.
절차
백업을 삭제하려면 다음 Velero 명령을 실행합니다.
$ velero backup delete <backup_name> -n openshift-adp 1
- 1
- 백업 이름을 지정합니다.
4.8.7.3. Kopia 리포지토리 유지 관리 정보
Kopia 리포지토리 유지 관리에는 다음 두 가지 유형이 있습니다.
- 빠른 유지 관리
- 매시간 을 실행하여 인덱스 Blob(n) 수를 낮게 유지합니다. 많은 수의 인덱스가 Kopia 작업의 성능에 부정적인 영향을 미칩니다.
- 동일한 메타데이터의 다른 사본이 있는지 확인하지 않고 리포지토리에서 메타데이터를 삭제하지 않습니다.
- 완전 유지 관리
- 더 이상 필요하지 않은 리포지토리 콘텐츠의 가비지 컬렉션을 수행하기 위해 24시간마다 실행됩니다.
-
전체 유지 관리 작업인
snapshot-gc
는 스냅샷 매니페스트에서 더 이상 액세스할 수 없는 모든 파일 및 디렉터리 목록을 찾아 삭제된 것으로 표시합니다. - 전체 유지 관리는 클러스터에서 활성 상태인 모든 스냅샷의 모든 디렉터리를 검사해야 하므로 리소스 비용이 많이 드는 작업입니다.
4.8.7.3.1. OADP에서 Kopia 유지 관리
repo-maintain-job
작업은 다음 예와 같이 OADP가 설치된 네임스페이스에서 실행됩니다.
pod/repo-maintain-job-173...2527-2nbls 0/1 Completed 0 168m pod/repo-maintain-job-173....536-fl9tm 0/1 Completed 0 108m pod/repo-maintain-job-173...2545-55ggx 0/1 Completed 0 48m
백업 오브젝트 스토리지에서 정리 및 아티팩트 제거에 대한 자세한 내용은 repo-maintain-job
의 로그를 확인할 수 있습니다. 다음 전체 사이클 유지 관리로 인해 repo-maintain-job
에서 다음 예에 표시된 대로 노트를 찾을 수 있습니다.
not due for full maintenance cycle until 2024-00-00 18:29:4
백업 오브젝트 스토리지에서 오브젝트를 삭제하려면 전체 유지 관리 주기를 성공적으로 실행해야 합니다. 즉, 백업 오브젝트 스토리지의 모든 아티팩트가 삭제될 때까지 최대 72시간을 기대할 수 있습니다.
4.8.7.4. 백업 리포지토리 삭제
백업을 삭제한 후 관련 아티팩트를 삭제하기 위해 Kopia 리포지토리 유지 관리 주기가 완료되면 메타데이터 또는 매니페스트 오브젝트에서 더 이상 백업을 참조하지 않습니다. 그런 다음 backuprepository
CR(사용자 정의 리소스)을 삭제하여 백업 삭제 프로세스를 완료할 수 있습니다.
사전 요구 사항
- 애플리케이션의 백업을 삭제했습니다.
- 백업이 삭제된 후 최대 72시간 동안 대기했습니다. 이 시간 프레임을 사용하면 Kopia에서 리포지토리 유지 관리 사이클을 실행할 수 있습니다.
절차
백업에 대한 백업 리포지토리 CR의 이름을 가져오려면 다음 명령을 실행합니다.
$ oc get backuprepositories.velero.io -n openshift-adp
백업 리포지토리 CR을 삭제하려면 다음 명령을 실행합니다.
$ oc delete backuprepository <backup_repository_name> -n openshift-adp 1
- 1
- 이전 단계에서 백업 리포지토리의 이름을 지정합니다.
4.8.8. Kopia 정보
Kopia는 데이터의 암호화된 스냅샷을 작성하고 선택한 원격 또는 클라우드 스토리지에 스냅샷을 저장할 수 있는 빠르고 안전한 오픈 소스 백업 및 복원 도구입니다.
Kopia는 네트워크 및 로컬 스토리지 위치와 다음을 포함한 많은 클라우드 또는 원격 스토리지 위치를 지원합니다.
- Amazon S3 및 S3와 호환되는 모든 클라우드 스토리지
- Azure Blob Storage
- Google Cloud Storage 플랫폼
Kopia는 스냅샷을 위해 콘텐츠 주소 지정 가능 스토리지를 사용합니다.
- 스냅샷은 항상 증분입니다. 이전 스냅샷에 이미 포함된 데이터는 리포지토리에 다시 업로드되지 않습니다. 파일은 수정된 경우에만 리포지토리에 업로드됩니다.
- 저장된 데이터는 중복됩니다. 동일한 파일의 복사본이 여러 개 있으면 둘 중 하나만 저장됩니다.
- 파일이 이동되거나 이름이 변경된 경우 Kopia는 동일한 콘텐츠가 있고 다시 업로드하지 않는다는 것을 인식할 수 있습니다.
4.8.8.1. Kopia와 OADP 통합
OADP 1.3은 Restic 외에도 Pod 볼륨 백업의 백업 메커니즘으로 Kopia를 지원합니다. 설치 시 DataProtectionApplication
CR(사용자 정의 리소스)에서 uploaderType
필드를 설정하여 설치 시 하나 이상을 선택해야 합니다. 가능한 값은 restic
또는 kopia
입니다. uploaderType
을 지정하지 않으면 OADP 1.3의 기본값은 Kopia를 백업 메커니즘으로 사용합니다. 데이터는 통합 리포지토리로 작성 및 읽습니다.
다음 예제에서는 Kopia를 사용하도록 구성된 DataProtectionApplication
CR을 보여줍니다.
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: nodeAgent: enable: true uploaderType: kopia # ...
4.9. OADP 복원
4.9.1. 애플리케이션 복원
Restore
CR(사용자 정의 리소스)을 생성하여 애플리케이션 백업을 복원합니다. 복원 CR 생성을 참조하십시오.
Restore
CR을 편집하여 Pod의 컨테이너에서 명령을 실행하기 위해 복원 후크를 생성할 수 있습니다. 복원 후크 생성 을 참조하십시오.
4.9.1.1. 백업을 실행하고 복원하기 전에 리소스 미리 보기
OADP는 유형, 네임스페이스 또는 레이블을 기반으로 애플리케이션 리소스를 백업합니다. 즉, 백업이 완료된 후 리소스를 볼 수 있습니다. 마찬가지로 복원 작업이 완료된 후 네임스페이스, 영구 볼륨(PV) 또는 라벨을 기반으로 복원된 오브젝트를 볼 수 있습니다. 리소스를 미리 미리 보려면 백업 및 복원 작업을 예행히 실행할 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
절차
실제 백업을 실행하기 전에 백업에 포함된 리소스를 미리 보려면 다음 명령을 실행합니다.
$ velero backup create <backup-name> --snapshot-volumes false 1
- 1
--snapshot-volumes
매개변수 값을false
로 지정합니다.
백업 리소스에 대한 자세한 내용을 보려면 다음 명령을 실행합니다.
$ velero describe backup <backup_name> --details 1
- 1
- 백업 이름을 지정합니다.
실제 복원을 실행하기 전에 복원에 포함된 리소스를 미리 보려면 다음 명령을 실행합니다.
$ velero restore create --from-backup <backup-name> 1
- 1
- 백업 리소스를 검토하기 위해 생성된 백업의 이름을 지정합니다.
중요velero restore create
명령은 클러스터에 복원 리소스를 생성합니다. 리소스를 검토한 후 복원의 일부로 생성된 리소스를 삭제해야 합니다.복원 리소스에 대한 자세한 내용을 보려면 다음 명령을 실행합니다.
$ velero describe restore <restore_name> --details 1
- 1
- 복원의 이름을 지정합니다.
4.9.1.2. Restore CR을 생성
Restore
CR을 생성하여 Backup
CR(사용자 정의 리소스)을 복원합니다.
사전 요구 사항
- OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
-
DataProtectionApplication
CR은Ready
상태에 있어야 합니다. -
Velero
Backup
CR이 있어야 합니다. - PV(영구 볼륨) 용량이 백업 시 요청된 크기와 일치해야 합니다. 필요한 경우 요청된 크기를 조정합니다.
절차
다음 예제와 같이
Restore
CR을 생성합니다.apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: backupName: <backup> 1 includedResources: [] 2 excludedResources: - nodes - events - events.events.k8s.io - backups.velero.io - restores.velero.io - resticrepositories.velero.io restorePVs: true 3
다음 명령을 입력하여
Restore
CR의 상태가Completed
인지 확인합니다.$ oc get restores.velero.io -n openshift-adp <restore> -o jsonpath='{.status.phase}'
다음 명령을 입력하여 백업 리소스가 복원되었는지 확인합니다.
$ oc get all -n <namespace> 1
- 1
- 백업한 네임스페이스입니다.
볼륨과 함께
DeploymentConfig
를 복원하거나 복원 후 후크를 사용하는 경우 다음 명령을 입력하여dc-post-restore.sh
정리 스크립트를 실행합니다.$ bash dc-restic-post-restore.sh -> dc-post-restore.sh
참고복원 프로세스 중에 OADP Velero 플러그인은
DeploymentConfig
오브젝트를 축소하고 Pod를 독립 실행형 포드로 복원합니다. 이 작업은 클러스터가 복원 시 복원된DeploymentConfig
Pod를 즉시 삭제하지 않고 복원 및 복원 후 후크로 복원된 Pod에서 작업을 완료할 수 있도록 하기 위해 수행됩니다. 아래에 표시된 정리 스크립트는 이러한 연결이 끊긴 Pod를 제거하고 적절한 복제본 수로DeploymentConfig
오브젝트를 다시 확장합니다.예 4.1.
DC-restic-post-restore.sh → dc-post-restore.sh
정리 스크립트#!/bin/bash set -e # if sha256sum exists, use it to check the integrity of the file if command -v sha256sum >/dev/null 2>&1; then CHECKSUM_CMD="sha256sum" else CHECKSUM_CMD="shasum -a 256" fi label_name () { if [ "${#1}" -le "63" ]; then echo $1 return fi sha=$(echo -n $1|$CHECKSUM_CMD) echo "${1:0:57}${sha:0:6}" } if [[ $# -ne 1 ]]; then echo "usage: ${BASH_SOURCE} restore-name" exit 1 fi echo "restore: $1" label=$(label_name $1) echo "label: $label" echo Deleting disconnected restore pods oc delete pods --all-namespaces -l oadp.openshift.io/disconnected-from-dc=$label for dc in $(oc get dc --all-namespaces -l oadp.openshift.io/replicas-modified=$label -o jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{","}{.metadata.annotations.oadp\.openshift\.io/original-replicas}{","}{.metadata.annotations.oadp\.openshift\.io/original-paused}{"\n"}') do IFS=',' read -ra dc_arr <<< "$dc" if [ ${#dc_arr[0]} -gt 0 ]; then echo Found deployment ${dc_arr[0]}/${dc_arr[1]}, setting replicas: ${dc_arr[2]}, paused: ${dc_arr[3]} cat <<EOF | oc patch dc -n ${dc_arr[0]} ${dc_arr[1]} --patch-file /dev/stdin spec: replicas: ${dc_arr[2]} paused: ${dc_arr[3]} EOF fi done
4.9.1.3. 복원 후크 생성
Restore
CR(사용자 정의 리소스)을 편집하여 Pod의 컨테이너에서 명령을 실행할 복원 후크를 생성합니다.
다음 두 가지 유형의 복원 후크를 생성할 수 있습니다.
init
후크는 애플리케이션 컨테이너가 시작되기 전에 설정 작업을 수행하기 위해 Pod에 init 컨테이너를 추가합니다.Restic 백업을 복원하면 복원 후크 init 컨테이너 앞에
restic-wait
init 컨테이너가 추가됩니다.-
exec
후크는 복원된 Pod의 컨테이너에서 명령 또는 스크립트를 실행합니다.
절차
다음 예제와 같이
Restore
CR의spec.hooks
블록에 후크를 추가합니다.apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: hooks: resources: - name: <hook_name> includedNamespaces: - <namespace> 1 excludedNamespaces: - <namespace> includedResources: - pods 2 excludedResources: [] labelSelector: 3 matchLabels: app: velero component: server postHooks: - init: initContainers: - name: restore-hook-init image: alpine:latest volumeMounts: - mountPath: /restores/pvc1-vm name: pvc1-vm command: - /bin/ash - -c timeout: 4 - exec: container: <container> 5 command: - /bin/bash 6 - -c - "psql < /backup/backup.sql" waitTimeout: 5m 7 execTimeout: 1m 8 onError: Continue 9
- 1
- 선택 사항: 후크가 적용되는 네임스페이스 배열입니다. 이 값을 지정하지 않으면 후크가 모든 네임스페이스에 적용됩니다.
- 2
- 현재 Pod는 후크를 적용할 수 있는 유일한 지원 리소스입니다.
- 3
- 선택 사항: 이 후크는 라벨 선택기와 일치하는 오브젝트에만 적용됩니다.
- 4
- 선택 사항: 시간 초과는 Velero가
initContainers
가 완료될 때까지 대기하는 최대 시간을 지정합니다. - 5
- 선택 사항: 컨테이너를 지정하지 않으면 Pod의 첫 번째 컨테이너에서 명령이 실행됩니다.
- 6
- 이는 추가 중인 init 컨테이너의 진입점입니다.
- 7
- 선택 사항: 컨테이너가 준비될 때까지 대기하는 시간입니다. 컨테이너가 시작되고 동일한 컨테이너의 이전 후크가 완료될 때까지 충분히 길어야 합니다. 설정하지 않으면 복원 프로세스가 무기한 대기합니다.
- 8
- 선택 사항: 명령을 실행할 때까지 대기하는 시간입니다. 기본값은
30s
입니다. - 9
- 오류 처리에 허용되는 값은
Fail
및Continue
입니다.-
continue
: 명령 실패만 기록합니다. -
실패
: Pod의 모든 컨테이너에서 복구 후크를 더 이상 실행하지 않습니다.Restore
CR의 상태는partiallyFailed 입니다
.
-
FSB(파일 시스템 백업) 복원 작업 중에 ImageStream
을 참조하는 Deployment
리소스가 제대로 복원되지 않습니다. FSB를 실행하는 복원된 Pod 및 postHook
은 조기에 종료됩니다.
이는 복원 작업 중에 OpenShift 컨트롤러에서 업데이트된 ImageStreamTag
해시로 Deployment
리소스의 spec.template.spec.containers[0].image
필드를 업데이트하기 때문에 발생합니다. 이번 업데이트에서는 새 Pod의 롤아웃을 트리거하여 velero
가 FSB를 실행하는 Pod와 복원 후 후크를 종료합니다. 이미지 스트림 트리거에 대한 자세한 내용은 "이미지 스트림 변경에 대한 업데이트 트리거"를 참조하십시오.
이 동작에 대한 해결방법은 2단계 복원 프로세스입니다.
먼저
Deployment
리소스를 제외한 복원을 수행합니다. 예를 들면 다음과 같습니다.$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --exclude-resources=deployment.apps
첫 번째 복원이 성공한 후 다음 리소스를 포함하여 두 번째 복원을 수행합니다. 예를 들면 다음과 같습니다.
$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --include-resources=deployment.apps
추가 리소스
4.10. OADP 및 ROSA
4.10.1. OADP를 사용하여 ROSA 클러스터에서 애플리케이션 백업
ROSA(Red Hat OpenShift Service) 클러스터에서 OADP(OpenShift API for Data Protection)를 사용하여 애플리케이션 데이터를 백업하고 복원할 수 있습니다.
ROSA는 애플리케이션을 구축하고 배포하여 고객에게 가치를 제공할 수 있는 완전한 턴키 애플리케이션 플랫폼입니다.
ROSA는 다양한 AWS(Amazon Web Services) 컴퓨팅, 데이터베이스, 분석, 머신러닝, 네트워킹, 모바일 및 기타 서비스와 원활한 통합을 제공하여 고객에게 차별화된 경험의 구축 및 제공을 가속화합니다.
AWS 계정에서 직접 서비스에 등록할 수 있습니다.
클러스터를 생성한 후 OpenShift Container Platform 웹 콘솔 또는 Red Hat OpenShift Cluster Manager 를 통해 클러스터를 작동할 수 있습니다. ROSA를 OpenShift API 및 CLI(명령줄 인터페이스) 툴과 함께 사용할 수도 있습니다.
ROSA 설치에 대한 자세한 내용은 AWS(ROSA) 대화형 방법에 대한 Red Hat OpenShift Service 설치를 참조하십시오.
OADP(OpenShift API for Data Protection)를 설치하기 전에 Amazon Web Services API를 사용할 수 있도록 OADP의 역할 및 정책 자격 증명을 설정해야 합니다.
이 프로세스는 다음 두 단계로 수행됩니다.
- AWS 인증 정보 준비
- OADP Operator를 설치하고 IAM 역할을 제공합니다.
4.10.1.1. OADP에 대한 AWS 인증 정보 준비
Amazon Web Services 계정은 OADP(OpenShift API for Data Protection) 설치를 허용하도록 준비하고 구성해야 합니다.
절차
다음 명령을 실행하여 다음 환경 변수를 생성합니다.
중요ROSA 클러스터와 일치하도록 클러스터 이름을 변경하고 관리자로 클러스터에 로그인했는지 확인합니다. 계속하기 전에 모든 필드가 올바르게 출력되었는지 확인합니다.
$ export CLUSTER_NAME=my-cluster 1 export ROSA_CLUSTER_ID=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .id) export REGION=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .region.id) export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed 's|^https://||') export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export CLUSTER_VERSION=$(rosa describe cluster -c ${CLUSTER_NAME} -o json | jq -r .version.raw_id | cut -f -2 -d '.') export ROLE_NAME="${CLUSTER_NAME}-openshift-oadp-aws-cloud-credentials" export SCRATCH="/tmp/${CLUSTER_NAME}/oadp" mkdir -p ${SCRATCH} echo "Cluster ID: ${ROSA_CLUSTER_ID}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"
- 1
my-cluster
를 ROSA 클러스터 이름으로 교체합니다.
AWS 계정에서 AWS S3에 대한 액세스를 허용하는 IAM 정책을 생성합니다.
다음 명령을 실행하여 정책이 존재하는지 확인합니다.
$ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaOadpVer1'].{ARN:Arn}" --output text) 1
- 1
RosaOadp
를 정책 이름으로 교체합니다.
다음 명령을 입력하여 정책 JSON 파일을 생성한 다음 ROSA에서 정책을 생성합니다.
참고정책 ARN을 찾을 수 없는 경우 명령에서 정책을 생성합니다. 정책 ARN이 이미 존재하는 경우
if
문이 의도적으로 정책 생성을 건너뜁니다.$ if [[ -z "${POLICY_ARN}" ]]; then cat << EOF > ${SCRATCH}/policy.json 1 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket", "s3:DeleteBucket", "s3:PutBucketTagging", "s3:GetBucketTagging", "s3:PutEncryptionConfiguration", "s3:GetEncryptionConfiguration", "s3:PutLifecycleConfiguration", "s3:GetLifecycleConfiguration", "s3:GetBucketLocation", "s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUploads", "s3:ListMultipartUploadParts", "s3:DescribeSnapshots", "ec2:DescribeVolumes", "ec2:DescribeVolumeAttribute", "ec2:DescribeVolumesModifications", "ec2:DescribeVolumeStatus", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateSnapshot", "ec2:DeleteSnapshot" ], "Resource": "*" } ]} EOF POLICY_ARN=$(aws iam create-policy --policy-name "RosaOadpVer1" \ --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \ --tags Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-oadp Key=operator_name,Value=openshift-oadp \ --output text) fi
- 1
SCRATCH
는 환경 변수에 대해 생성된 임시 디렉터리의 이름입니다.
다음 명령을 실행하여 정책 ARN을 확인합니다.
$ echo ${POLICY_ARN}
클러스터에 대한 IAM 역할 신뢰 정책을 생성합니다.
다음 명령을 실행하여 신뢰 정책 파일을 생성합니다.
$ cat <<EOF > ${SCRATCH}/trust-policy.json { "Version":2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OIDC_ENDPOINT}:sub": [ "system:serviceaccount:openshift-adp:openshift-adp-controller-manager", "system:serviceaccount:openshift-adp:velero"] } } }] } EOF
다음 명령을 실행하여 역할을 생성합니다.
$ ROLE_ARN=$(aws iam create-role --role-name \ "${ROLE_NAME}" \ --assume-role-policy-document file://${SCRATCH}/trust-policy.json \ --tags Key=rosa_cluster_id,Value=${ROSA_CLUSTER_ID} Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=openshift-oadp \ --query Role.Arn --output text)
다음 명령을 실행하여 역할 ARN을 확인합니다.
$ echo ${ROLE_ARN}
다음 명령을 실행하여 IAM 역할에 IAM 정책을 연결합니다.
$ aws iam attach-role-policy --role-name "${ROLE_NAME}" \ --policy-arn ${POLICY_ARN}
4.10.1.2. OADP Operator 설치 및 IAM 역할 제공
AWS STS(보안 토큰 서비스)는 IAM 또는 페더레이션 사용자를 위한 단기 자격 증명을 제공하는 글로벌 웹 서비스입니다. STS가 있는 ROSA(OpenShift Container Platform)는 ROSA 클러스터에 권장되는 인증 정보 모드입니다. 이 문서에서는 AWS STS를 사용하여 ROSA에 OADP(OpenShift API for Data Protection)를 설치하는 방법을 설명합니다.
Restic은 지원되지 않습니다.
CSI(Container Storage Interface) 스냅샷이 지원되지 않는 파일 시스템을 백업할 때 Kopia 파일 시스템 백업(FSB)이 지원됩니다.
예제 파일 시스템에는 다음이 포함됩니다.
- Amazon Elastic File System (EFS)
- 네트워크 파일 시스템(NFS)
-
emptyDir
볼륨 - 로컬 볼륨
볼륨 백업의 경우 AWS STS를 사용하여 ROSA의 OADP는 기본 스냅샷 및 CSI(Container Storage Interface) 스냅샷만 지원합니다.
STS 인증을 사용하는 Amazon ROSA 클러스터에서는 다른 AWS 리전에서 백업 데이터를 복원할 수 없습니다.
Data Mover 기능은 현재 ROSA 클러스터에서 지원되지 않습니다. 데이터 이동을 위해 기본 AWS S3 툴을 사용할 수 있습니다.
사전 요구 사항
-
필요한 액세스 및 토큰이 있는 OpenShift Container Platform ROSA 클러스터 자세한 내용은 OADP에 대한 AWS 인증 정보 준비 절차를 참조하십시오. 백업 및 복원을 위해 두 개의 다른 클러스터를 사용하려면 각 클러스터에 대해
ROLE_ARN
을 포함한 AWS 인증 정보를 준비해야 합니다.
절차
다음 명령을 입력하여 AWS 토큰 파일에서 OpenShift Container Platform 시크릿을 생성합니다.
인증 정보 파일을 생성합니다.
$ cat <<EOF > ${SCRATCH}/credentials [default] role_arn = ${ROLE_ARN} web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token region = <aws_region> 1 EOF
- 1
- &
lt;aws_region
>을 STS 끝점에 사용할 AWS 리전으로 바꿉니다.
OADP의 네임스페이스를 생성합니다.
$ oc create namespace openshift-adp
OpenShift Container Platform 시크릿을 생성합니다.
$ oc -n openshift-adp create secret generic cloud-credentials \ --from-file=${SCRATCH}/credentials
참고OpenShift Container Platform 버전 4.14 이상에서 OADP Operator는 OLM(Operator Lifecycle Manager) 및 CCO(Cloud Credentials Operator)를 통해 새로운 표준화된 STS 워크플로를 지원합니다. 이 워크플로우에서는 OpenShift Container Platform 웹 콘솔을 사용하여 OLM 관리 Operator를 설치하는 동안 위의 시크릿을 생성할 필요가 없습니다. 자세한 내용은 웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.
이전 시크릿은 CCO에 의해 자동으로 생성됩니다.
OADP Operator를 설치합니다.
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub 로 이동합니다.
- OADP Operator 를 검색합니다.
- role_ARN 필드에 이전에 생성한 role_arn을 붙여넣고 설치를 클릭합니다.
다음 명령을 입력하여 AWS 인증 정보를 사용하여 AWS 클라우드 스토리지를 생성합니다.
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: CloudStorage metadata: name: ${CLUSTER_NAME}-oadp namespace: openshift-adp spec: creationSecret: key: credentials name: cloud-credentials enableSharedConfig: true name: ${CLUSTER_NAME}-oadp provider: aws region: $REGION EOF
다음 명령을 입력하여 애플리케이션의 스토리지 기본 스토리지 클래스를 확인합니다.
$ oc get pvc -n <namespace>
출력 예
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE applog Bound pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8 1Gi RWO gp3-csi 4d19h mysql Bound pvc-16b8e009-a20a-4379-accc-bc81fedd0621 1Gi RWO gp3-csi 4d19h
다음 명령을 실행하여 스토리지 클래스를 가져옵니다.
$ oc get storageclass
출력 예
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE gp2 kubernetes.io/aws-ebs Delete WaitForFirstConsumer true 4d21h gp2-csi ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3 ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3-csi (default) ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h
참고다음 스토리지 클래스가 작동합니다.
- gp3-csi
- gp2-csi
- gp3
- gp2
백업 중인 애플리케이션 또는 애플리케이션이 모두 CSI(Container Storage Interface)를 사용하는 PV(영구 볼륨)를 사용하는 경우 OADP DPA 구성에 CSI 플러그인을 포함하는 것이 좋습니다.
DataProtectionApplication
리소스를 만들어 백업 및 볼륨 스냅샷이 저장되는 스토리지에 대한 연결을 구성합니다.CSI 볼륨만 사용하는 경우 다음 명령을 입력하여 데이터 보호 애플리케이션을 배포합니다.
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true 1 features: dataMover: enable: false backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws - csi nodeAgent: 2 enable: false uploaderType: kopia 3 EOF
CSI 또는 비 CSI 볼륨을 사용하는 경우 다음 명령을 입력하여 데이터 보호 애플리케이션을 배포합니다.
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true 1 backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws nodeAgent: 2 enable: false uploaderType: restic snapshotLocations: - velero: config: credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials 3 enableSharedConfig: "true" 4 profile: default 5 region: ${REGION} 6 provider: aws EOF
- 1
- ROSA는 내부 이미지 백업을 지원합니다. 이미지 백업을 사용하지 않으려면 이 필드를 false로 설정합니다.
- 2
nodeAgent
속성과 관련된 중요한 노트를 참조하십시오.- 3
credentialsFile
필드는 Pod에 버킷 인증 정보의 마운트된 위치입니다.- 4
enableSharedConfig
필드를 사용하면snapshotLocations
에서 버킷에 대해 정의된 인증 정보를 공유하거나 재사용할 수 있습니다.- 5
- AWS 인증 정보 파일에 설정된 프로필 이름을 사용합니다.
- 6
리전을 AWS 리전
으로 지정합니다. 이는 클러스터 리전과 동일해야 합니다.
이제 애플리케이션 백업에 설명된 대로 OpenShift Container Platform 애플리케이션을 백업 하고 복원할 준비가 되었습니다.
OADP가 ROSA 환경에서 Restic을 지원하지 않기 때문에 restic
의 enable
매개변수는 이 구성에서 false
로 설정됩니다.
OADP 1.2를 사용하는 경우 이 구성을 교체합니다.
nodeAgent: enable: false uploaderType: restic
다음 구성에서는 다음을 수행합니다.
restic: enable: false
백업 및 복원을 위해 두 개의 다른 클러스터를 사용하려면 클라우드 스토리지 CR과 OADP DataProtectionApplication
구성 둘 다에 동일한 AWS S3 스토리지 이름이 있어야 합니다.
추가 리소스
4.10.1.3. 예: 선택적 정리를 사용하여 OADP ROSA STS에서 워크로드 백업
4.10.1.3.1. OADP 및 ROSA STS로 백업 수행
다음 예제 hello-world
애플리케이션에는 PV(영구 볼륨)가 연결되어 있지 않습니다. ROSA(Red Hat OpenShift Service on AWS) STS를 사용하여 OADP(OpenShift API for Data Protection)를 사용하여 백업을 수행합니다.
DPA(Data Protection Application) 구성이 작동합니다.
다음 명령을 실행하여 백업할 워크로드를 생성합니다.
$ oc create namespace hello-world
$ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
다음 명령을 실행하여 경로를 노출합니다.
$ oc expose service/hello-openshift -n hello-world
다음 명령을 실행하여 애플리케이션이 작동하는지 확인합니다.
$ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
출력 예
Hello OpenShift!
다음 명령을 실행하여 워크로드를 백업합니다.
$ cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Backup metadata: name: hello-world namespace: openshift-adp spec: includedNamespaces: - hello-world storageLocation: ${CLUSTER_NAME}-dpa-1 ttl: 720h0m0s EOF
백업이 완료될 때까지 기다린 후 다음 명령을 실행합니다.
$ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"
출력 예
{ "completionTimestamp": "2022-09-07T22:20:44Z", "expiration": "2022-10-07T22:20:22Z", "formatVersion": "1.1.0", "phase": "Completed", "progress": { "itemsBackedUp": 58, "totalItems": 58 }, "startTimestamp": "2022-09-07T22:20:22Z", "version": 1 }
다음 명령을 실행하여 데모 워크로드를 삭제합니다.
$ oc delete ns hello-world
다음 명령을 실행하여 백업에서 워크로드를 복원합니다.
$ cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Restore metadata: name: hello-world namespace: openshift-adp spec: backupName: hello-world EOF
다음 명령을 실행하여 복원이 완료될 때까지 기다립니다.
$ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"
출력 예
{ "completionTimestamp": "2022-09-07T22:25:47Z", "phase": "Completed", "progress": { "itemsRestored": 38, "totalItems": 38 }, "startTimestamp": "2022-09-07T22:25:28Z", "warnings": 9 }
다음 명령을 실행하여 워크로드가 복원되었는지 확인합니다.
$ oc -n hello-world get pods
출력 예
NAME READY STATUS RESTARTS AGE hello-openshift-9f885f7c6-kdjpj 1/1 Running 0 90s
다음 명령을 실행하여 JSONPath를 확인합니다.
$ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
출력 예
Hello OpenShift!
문제 해결 팁은 OADP 팀의 문제 해결 설명서를 참조하십시오.
4.10.1.3.2. OADP 및 ROSA STS를 사용하여 백업 후 클러스터 정리
이 예제에서 OADP(OpenShift API for Data Protection) Operator를 백업 및 S3 버킷과 함께 설치 제거해야 하는 경우 다음 지침을 따르십시오.
절차
다음 명령을 실행하여 워크로드를 삭제합니다.
$ oc delete ns hello-world
다음 명령을 실행하여 DPA(데이터 보호 애플리케이션)를 삭제합니다.
$ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
다음 명령을 실행하여 클라우드 스토리지를 삭제합니다.
$ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
주의이 명령이 중단되면 다음 명령을 실행하여 종료자를 삭제해야 할 수 있습니다.
$ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
Operator가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 Operator를 제거합니다.
$ oc -n openshift-adp delete subscription oadp-operator
Operator에서 네임스페이스를 제거합니다.
$ oc delete ns openshift-adp
백업 및 복원 리소스가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 리소스를 제거합니다.
$ oc delete backups.velero.io hello-world
AWS S3에서 백업, 복원 및 원격 오브젝트를 삭제하려면 다음 명령을 실행합니다.
$ velero backup delete hello-world
더 이상 CRD(Custom Resource Definitions)가 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 정의를 제거하십시오.
$ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
다음 명령을 실행하여 AWS S3 버킷을 삭제합니다.
$ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
$ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
다음 명령을 실행하여 역할에서 정책을 분리합니다.
$ aws iam detach-role-policy --role-name "${ROLE_NAME}" --policy-arn "${POLICY_ARN}"
다음 명령을 실행하여 역할을 삭제합니다.
$ aws iam delete-role --role-name "${ROLE_NAME}"
4.11. OADP 및 AWS STS
4.11.1. OADP를 사용하여 AWS STS에서 애플리케이션 백업
OADP Operator를 설치하여 AWS(Amazon Web Services)를 사용하여 OADP(OpenShift API for Data Protection)를 설치합니다. Operator는 Velero 1.14 를 설치합니다.
OADP 1.0.4부터 모든 OADP 1.0.z 버전은 Migration Toolkit for Containers Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.
Velero에 대해 AWS를 구성하고, 기본 보안
보안을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.
제한된 네트워크 환경에서 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.
AWS STS(AWS STS) 클러스터에 OADP를 수동으로 설치할 수 있습니다. Amazon AWS는 사용자가 제한된 임시 자격 증명을 요청할 수 있는 웹 서비스로 AWS STS를 제공합니다. STS를 사용하여 신뢰할 수 있는 사용자에게 API 호출, AWS 콘솔 또는 AWS CLI(명령줄 인터페이스)를 통해 리소스에 대한 임시 액세스를 제공합니다.
OADP(OpenShift API for Data Protection)를 설치하기 전에 Amazon Web Services API를 사용할 수 있도록 OADP의 역할 및 정책 자격 증명을 설정해야 합니다.
이 프로세스는 다음 두 단계로 수행됩니다.
- AWS 인증 정보를 준비합니다.
- OADP Operator를 설치하고 IAM 역할을 부여합니다.
4.11.1.1. OADP의 AWS STS 인증 정보 준비
Amazon Web Services 계정은 OADP(OpenShift API for Data Protection) 설치를 허용하도록 준비하고 구성해야 합니다. 다음 절차를 사용하여 AWS 인증 정보를 준비합니다.
절차
다음 명령을 실행하여
cluster_name
환경 변수를 정의합니다.$ export CLUSTER_NAME= <AWS_cluster_name> 1
- 1
- 변수는 임의의 값으로 설정할 수 있습니다.
다음 명령을 실행하여
AWS_ACCOUNT_ID, OIDC_ENDPOINT
와 같은클러스터
의 모든 세부 정보를 검색합니다.$ export CLUSTER_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}') export AWS_CLUSTER_ID=$(oc get clusterversion version -o jsonpath='{.spec.clusterID}{"\n"}') export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed 's|^https://||') export REGION=$(oc get infrastructures cluster -o jsonpath='{.status.platformStatus.aws.region}' --allow-missing-template-keys=false || echo us-east-2) export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export ROLE_NAME="${CLUSTER_NAME}-openshift-oadp-aws-cloud-credentials"
다음 명령을 실행하여 모든 파일을 저장할 임시 디렉터리를 생성합니다.
$ export SCRATCH="/tmp/${CLUSTER_NAME}/oadp" mkdir -p ${SCRATCH}
다음 명령을 실행하여 수집된 모든 세부 정보를 표시합니다.
$ echo "Cluster ID: ${AWS_CLUSTER_ID}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"
AWS 계정에서 AWS S3에 대한 액세스를 허용하는 IAM 정책을 생성합니다.
다음 명령을 실행하여 정책이 존재하는지 확인합니다.
$ export POLICY_NAME="OadpVer1" 1
- 1
- 변수는 임의의 값으로 설정할 수 있습니다.
$ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='$POLICY_NAME'].{ARN:Arn}" --output text)
다음 명령을 입력하여 정책 JSON 파일을 생성한 다음 정책을 생성합니다.
참고정책 ARN을 찾을 수 없는 경우 명령에서 정책을 생성합니다. 정책 ARN이 이미 존재하는 경우
if
문이 의도적으로 정책 생성을 건너뜁니다.$ if [[ -z "${POLICY_ARN}" ]]; then cat << EOF > ${SCRATCH}/policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket", "s3:DeleteBucket", "s3:PutBucketTagging", "s3:GetBucketTagging", "s3:PutEncryptionConfiguration", "s3:GetEncryptionConfiguration", "s3:PutLifecycleConfiguration", "s3:GetLifecycleConfiguration", "s3:GetBucketLocation", "s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts", "ec2:DescribeSnapshots", "ec2:DescribeVolumes", "ec2:DescribeVolumeAttribute", "ec2:DescribeVolumesModifications", "ec2:DescribeVolumeStatus", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateSnapshot", "ec2:DeleteSnapshot" ], "Resource": "*" } ]} EOF POLICY_ARN=$(aws iam create-policy --policy-name $POLICY_NAME \ --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \ --tags Key=openshift_version,Value=${CLUSTER_VERSION} Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=oadp \ --output text) 1 fi
- 1
SCRATCH
는 파일을 저장하기 위해 생성된 임시 디렉터리의 이름입니다.
다음 명령을 실행하여 정책 ARN을 확인합니다.
$ echo ${POLICY_ARN}
클러스터에 대한 IAM 역할 신뢰 정책을 생성합니다.
다음 명령을 실행하여 신뢰 정책 파일을 생성합니다.
$ cat <<EOF > ${SCRATCH}/trust-policy.json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OIDC_ENDPOINT}:sub": [ "system:serviceaccount:openshift-adp:openshift-adp-controller-manager", "system:serviceaccount:openshift-adp:velero"] } } }] } EOF
다음 명령을 실행하여 클러스터에 대한 IAM 역할 신뢰 정책을 생성합니다.
$ ROLE_ARN=$(aws iam create-role --role-name \ "${ROLE_NAME}" \ --assume-role-policy-document file://${SCRATCH}/trust-policy.json \ --tags Key=cluster_id,Value=${AWS_CLUSTER_ID} Key=openshift_version,Value=${CLUSTER_VERSION} Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=oadp --query Role.Arn --output text)
다음 명령을 실행하여 역할 ARN을 확인합니다.
$ echo ${ROLE_ARN}
다음 명령을 실행하여 IAM 역할에 IAM 정책을 연결합니다.
$ aws iam attach-role-policy --role-name "${ROLE_NAME}" --policy-arn ${POLICY_ARN}
4.11.1.1.1. Velero CPU 및 메모리 리소스 할당 설정
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero
Pod에 대한 CPU 및 메모리 리소스 할당을 설정합니다.
사전 요구 사항
- OADP(Data Protection) Operator가 설치되어 있어야 합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.configuration.velero.podConfig.ResourceAllocations
블록의 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node_selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.
Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.
4.11.1.2. OADP Operator 설치 및 IAM 역할 제공
AWS STS(보안 토큰 서비스)는 IAM 또는 페더레이션 사용자를 위한 단기 자격 증명을 제공하는 글로벌 웹 서비스입니다. 이 문서에서는 AWS STS 클러스터에 OADP(OpenShift API for Data Protection)를 수동으로 설치하는 방법을 설명합니다.
Restic 및 Kopia는 OADP AWS STS 환경에서 지원되지 않습니다. Restic 및 Kopia 노드 에이전트가 비활성화되어 있는지 확인합니다. 볼륨 백업의 경우 AWS STS의 OADP는 기본 스냅샷 및 CSI(Container Storage Interface) 스냅샷만 지원합니다.
STS 인증을 사용하는 AWS 클러스터에서는 다른 AWS 리전에서 백업 데이터를 복원할 수 없습니다.
데이터 Mover 기능은 현재 AWS STS 클러스터에서 지원되지 않습니다. 데이터 이동을 위해 기본 AWS S3 툴을 사용할 수 있습니다.
사전 요구 사항
-
필요한 액세스 및 토큰이 있는 OpenShift Container Platform AWS STS 클러스터 자세한 내용은 OADP에 대한 AWS 인증 정보 준비 절차를 참조하십시오. 백업 및 복원을 위해 두 개의 다른 클러스터를 사용하려면 각 클러스터에 대해
ROLE_ARN
을 포함한 AWS 인증 정보를 준비해야 합니다.
절차
다음 명령을 입력하여 AWS 토큰 파일에서 OpenShift Container Platform 시크릿을 생성합니다.
인증 정보 파일을 생성합니다.
$ cat <<EOF > ${SCRATCH}/credentials [default] role_arn = ${ROLE_ARN} web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token EOF
OADP의 네임스페이스를 생성합니다.
$ oc create namespace openshift-adp
OpenShift Container Platform 시크릿을 생성합니다.
$ oc -n openshift-adp create secret generic cloud-credentials \ --from-file=${SCRATCH}/credentials
참고OpenShift Container Platform 버전 4.14 이상에서 OADP Operator는 OLM(Operator Lifecycle Manager) 및 CCO(Cloud Credentials Operator)를 통해 새로운 표준화된 STS 워크플로를 지원합니다. 이 워크플로우에서는 OpenShift Container Platform 웹 콘솔을 사용하여 OLM 관리 Operator를 설치하는 동안 위의 시크릿을 생성할 필요가 없습니다. 자세한 내용은 웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.
이전 시크릿은 CCO에 의해 자동으로 생성됩니다.
OADP Operator를 설치합니다.
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub 로 이동합니다.
- OADP Operator 를 검색합니다.
- role_ARN 필드에 이전에 생성한 role_arn을 붙여넣고 설치를 클릭합니다.
다음 명령을 입력하여 AWS 인증 정보를 사용하여 AWS 클라우드 스토리지를 생성합니다.
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: CloudStorage metadata: name: ${CLUSTER_NAME}-oadp namespace: openshift-adp spec: creationSecret: key: credentials name: cloud-credentials enableSharedConfig: true name: ${CLUSTER_NAME}-oadp provider: aws region: $REGION EOF
다음 명령을 입력하여 애플리케이션의 스토리지 기본 스토리지 클래스를 확인합니다.
$ oc get pvc -n <namespace>
출력 예
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE applog Bound pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8 1Gi RWO gp3-csi 4d19h mysql Bound pvc-16b8e009-a20a-4379-accc-bc81fedd0621 1Gi RWO gp3-csi 4d19h
다음 명령을 실행하여 스토리지 클래스를 가져옵니다.
$ oc get storageclass
출력 예
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE gp2 kubernetes.io/aws-ebs Delete WaitForFirstConsumer true 4d21h gp2-csi ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3 ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3-csi (default) ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h
참고다음 스토리지 클래스가 작동합니다.
- gp3-csi
- gp2-csi
- gp3
- gp2
백업 중인 애플리케이션 또는 애플리케이션이 모두 CSI(Container Storage Interface)를 사용하는 PV(영구 볼륨)를 사용하는 경우 OADP DPA 구성에 CSI 플러그인을 포함하는 것이 좋습니다.
DataProtectionApplication
리소스를 만들어 백업 및 볼륨 스냅샷이 저장되는 스토리지에 대한 연결을 구성합니다.CSI 볼륨만 사용하는 경우 다음 명령을 입력하여 데이터 보호 애플리케이션을 배포합니다.
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true 1 features: dataMover: enable: false backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws - csi restic: enable: false EOF
- 1
- 이미지 백업을 사용하지 않으려면 이 필드를
false
로 설정합니다.
CSI 또는 비 CSI 볼륨을 사용하는 경우 다음 명령을 입력하여 데이터 보호 애플리케이션을 배포합니다.
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true 1 features: dataMover: enable: false backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws nodeAgent: 2 enable: false uploaderType: restic snapshotLocations: - velero: config: credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials 3 enableSharedConfig: "true" 4 profile: default 5 region: ${REGION} 6 provider: aws EOF
이제 애플리케이션 백업에 설명된 대로 OpenShift Container Platform 애플리케이션을 백업 하고 복원할 준비가 되었습니다.
OADP 1.2를 사용하는 경우 이 구성을 교체합니다.
nodeAgent: enable: false uploaderType: restic
다음 구성에서는 다음을 수행합니다.
restic: enable: false
백업 및 복원을 위해 두 개의 다른 클러스터를 사용하려면 클라우드 스토리지 CR과 OADP DataProtectionApplication
구성 둘 다에 동일한 AWS S3 스토리지 이름이 있어야 합니다.
4.11.1.3. 선택적 정리를 사용하여 OADP AWS STS에서 워크로드 백업
4.11.1.3.1. OADP 및 AWS STS로 백업 수행
다음 예제 hello-world
애플리케이션에는 PV(영구 볼륨)가 연결되어 있지 않습니다. AWS(Amazon Web Services)를 사용하여 OADP(OpenShift API for Data Protection)로 백업을 수행합니다.
DPA(Data Protection Application) 구성이 작동합니다.
다음 명령을 실행하여 백업할 워크로드를 생성합니다.
$ oc create namespace hello-world
$ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
다음 명령을 실행하여 경로를 노출합니다.
$ oc expose service/hello-openshift -n hello-world
다음 명령을 실행하여 애플리케이션이 작동하는지 확인합니다.
$ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
출력 예
Hello OpenShift!
다음 명령을 실행하여 워크로드를 백업합니다.
$ cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Backup metadata: name: hello-world namespace: openshift-adp spec: includedNamespaces: - hello-world storageLocation: ${CLUSTER_NAME}-dpa-1 ttl: 720h0m0s EOF
백업이 완료될 때까지 기다린 후 다음 명령을 실행합니다.
$ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"
출력 예
{ "completionTimestamp": "2022-09-07T22:20:44Z", "expiration": "2022-10-07T22:20:22Z", "formatVersion": "1.1.0", "phase": "Completed", "progress": { "itemsBackedUp": 58, "totalItems": 58 }, "startTimestamp": "2022-09-07T22:20:22Z", "version": 1 }
다음 명령을 실행하여 데모 워크로드를 삭제합니다.
$ oc delete ns hello-world
다음 명령을 실행하여 백업에서 워크로드를 복원합니다.
$ cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Restore metadata: name: hello-world namespace: openshift-adp spec: backupName: hello-world EOF
다음 명령을 실행하여 복원이 완료될 때까지 기다립니다.
$ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"
출력 예
{ "completionTimestamp": "2022-09-07T22:25:47Z", "phase": "Completed", "progress": { "itemsRestored": 38, "totalItems": 38 }, "startTimestamp": "2022-09-07T22:25:28Z", "warnings": 9 }
다음 명령을 실행하여 워크로드가 복원되었는지 확인합니다.
$ oc -n hello-world get pods
출력 예
NAME READY STATUS RESTARTS AGE hello-openshift-9f885f7c6-kdjpj 1/1 Running 0 90s
다음 명령을 실행하여 JSONPath를 확인합니다.
$ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
출력 예
Hello OpenShift!
문제 해결 팁은 OADP 팀의 문제 해결 설명서를 참조하십시오.
4.11.1.3.2. OADP 및 AWS STS를 사용하여 백업 후 클러스터 정리
이 예제에서 OADP(OpenShift API for Data Protection) Operator를 백업 및 S3 버킷과 함께 설치 제거해야 하는 경우 다음 지침을 따르십시오.
절차
다음 명령을 실행하여 워크로드를 삭제합니다.
$ oc delete ns hello-world
다음 명령을 실행하여 DPA(데이터 보호 애플리케이션)를 삭제합니다.
$ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
다음 명령을 실행하여 클라우드 스토리지를 삭제합니다.
$ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
중요이 명령이 중단되면 다음 명령을 실행하여 종료자를 삭제해야 할 수 있습니다.
$ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
Operator가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 Operator를 제거합니다.
$ oc -n openshift-adp delete subscription oadp-operator
다음 명령을 실행하여 Operator에서 네임스페이스를 제거합니다.
$ oc delete ns openshift-adp
백업 및 복원 리소스가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 리소스를 제거합니다.
$ oc delete backups.velero.io hello-world
AWS S3에서 백업, 복원 및 원격 오브젝트를 삭제하려면 다음 명령을 실행합니다.
$ velero backup delete hello-world
더 이상 CRD(Custom Resource Definitions)가 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 정의를 제거하십시오.
$ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
다음 명령을 실행하여 AWS S3 버킷을 삭제합니다.
$ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
$ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
다음 명령을 실행하여 역할에서 정책을 분리합니다.
$ aws iam detach-role-policy --role-name "${ROLE_NAME}" --policy-arn "${POLICY_ARN}"
다음 명령을 실행하여 역할을 삭제합니다.
$ aws iam delete-role --role-name "${ROLE_NAME}"
4.12. OADP 데이터 Mover
4.12.1. OADP Data Mover 정보
OADP(OpenShift API for Data Protection)에는 CSI(Container Storage Interface) 볼륨 스냅샷을 원격 오브젝트 저장소로 이동하는 데 사용할 수 있는 기본 제공 데이터 Mover가 포함되어 있습니다. 기본 제공 Data Mover를 사용하면 오류, 실수로 삭제 또는 클러스터 손상이 발생하는 경우 원격 오브젝트 저장소에서 상태 저장 애플리케이션을 복원할 수 있습니다. Kopia 를 업로드기 메커니즘으로 사용하여 스냅샷 데이터를 읽고 통합 리포지토리에 씁니다.
OADP는 다음에서 CSI 스냅샷을 지원합니다.
- {odf-full}
- Kubernetes Volume Snapshot API를 지원하는 CSI(Container Storage Interface) 드라이버가 있는 기타 클라우드 스토리지 공급자
4.12.1.1. Data Mover 지원
OADP 1.3에 기술 프리뷰로 도입된 OADP 내장 데이터 Mover는 이제 컨테이너화된 및 가상 머신 워크로드 모두에 대해 완전히 지원됩니다.
지원됨
OADP 1.3으로 가져온 데이터 Mover 백업은 OADP 1.3, 1.4 이상을 사용하여 복원할 수 있습니다. 이는 지원됩니다.
지원되지 않음
Data Mover 기능을 사용하여 OADP 1.1 또는 OADP 1.2로 가져온 백업은 OADP 1.3 이상을 사용하여 복원할 수 없습니다. 따라서 지원되지 않습니다.
OADP 1.1 및 OADP 1.2는 더 이상 지원되지 않습니다. OADP 1.1 또는 OADP 1.2의 DataMover 기능은 기술 프리뷰였으며 지원되지 않았습니다. OADP 1.1 또는 OADP 1.2로 가져온 DataMover 백업은 이후 버전의 OADP에서 복원할 수 없습니다.
4.12.1.2. 기본 제공 데이터 Mover 활성화
기본 제공 데이터 Mover를 활성화하려면 CSI 플러그인을 포함하고 DataProtectionApplication
CR(사용자 정의 리소스)에서 노드 에이전트를 활성화해야 합니다. 노드 에이전트는 데이터 이동 모듈을 호스팅하는 Kubernetes 데몬 세트입니다. 여기에는 데이터 Mover 컨트롤러, 업로드자 및 리포지토리가 포함됩니다.
DataProtectionApplication
매니페스트의 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: nodeAgent: enable: true 1 uploaderType: kopia 2 velero: defaultPlugins: - openshift - aws - csi 3 defaultSnapshotMoveData: true defaultVolumesToFSBackup: 4 featureFlags: - EnableCSI # ...
4.12.1.3. 기본 제공 데이터 Mover 컨트롤러 및 CRD(사용자 정의 리소스 정의)
기본 제공 Data Mover 기능에는 백업 및 복원을 관리하기 위해 CRD로 정의된 새로운 API 오브젝트 3개가 도입되었습니다.
-
DataDownload
: 볼륨 스냅샷의 데이터 다운로드를 나타냅니다. CSI 플러그인은 복원할 볼륨당 하나의DataDownload
오브젝트를 생성합니다.DataDownload
CR에는 대상 볼륨, 지정된 데이터 Mover, 현재 데이터 다운로드의 진행 상황, 지정된 백업 리포지토리 및 프로세스가 완료된 후 현재 데이터 다운로드 결과가 포함됩니다. -
DataUpload
: 볼륨 스냅샷의 데이터 업로드를 나타냅니다. CSI 플러그인은 CSI 스냅샷당 하나의DataUpload
오브젝트를 생성합니다.DataUpload
CR에는 지정된 스냅샷, 지정된 데이터 Mover, 지정된 백업 리포지토리, 현재 데이터 업로드 진행률, 프로세스가 완료된 후 현재 데이터 업로드 결과가 포함됩니다. -
BackupRepository
: 백업 리포지토리의 라이프사이클을 나타내며 관리합니다. OADP는 네임스페이스에 대한 첫 번째 CSI 스냅샷 백업 또는 복원이 요청되면 네임스페이스당 백업 리포지토리를 생성합니다.
4.12.1.4. 증분 백업 지원 정보
OADP는 컨테이너화된 워크로드와 OpenShift Virtualization 워크로드 모두에 대해 블록
및 Filesystem
영구 볼륨의 증분 백업을 지원합니다. 다음 표에는 파일 시스템 백업(FSB), CSI(Container Storage Interface) 및 CSI 데이터 Mover에 대한 지원이 요약되어 있습니다.
볼륨 모드 | FSB - Restic | FSB - Kopia | CSI | CSI 데이터 Mover |
---|---|---|---|---|
파일 시스템 | S [1], I [2] | S [1], I [2] | S [1] | S [1], I [2] |
블록 | N [3] | N [3] | S [1] | S [1], I [2] |
볼륨 모드 | FSB - Restic | FSB - Kopia | CSI | CSI 데이터 Mover |
---|---|---|---|---|
파일 시스템 | N [3] | N [3] | S [1] | S [1], I [2] |
블록 | N [3] | N [3] | S [1] | S [1], I [2] |
- 지원되는 백업
- 증분 백업 지원
- 지원되지 않음
CSI Data Mover 백업은 uploaderType
과 관계없이 Kopia를 사용합니다.
4.12.2. CSI 스냅샷 데이터 이동 백업 및 복원
OADP 1.3 Data Mover를 사용하여 영구 볼륨을 백업하고 복원할 수 있습니다.
4.12.2.1. CSI 스냅샷을 사용하여 영구 볼륨 백업
OADP 데이터 Mover를 사용하여 CSI(Container Storage Interface) 볼륨 스냅샷을 원격 오브젝트 저장소에 백업할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할을 사용하여 클러스터에 액세스할 수 있습니다. - OADP Operator가 설치되어 있습니다.
-
CSI 플러그인을 포함하고
DataProtectionApplication
CR(사용자 정의 리소스)에 노드 에이전트를 활성화했습니다. - 별도의 네임스페이스에서 영구 볼륨이 실행되는 애플리케이션이 있습니다.
-
metadata.labels.velero.io/csi-volumesnapshot-class: "true"
키-값 쌍을VolumeSnapshotClass
CR에 추가했습니다.
절차
다음 예와 같이
Backup
오브젝트에 대한 YAML 파일을 생성합니다.Backup
CR의 예kind: Backup apiVersion: velero.io/v1 metadata: name: backup namespace: openshift-adp spec: csiSnapshotTimeout: 10m0s defaultVolumesToFsBackup: 1 includedNamespaces: - mysql-persistent itemOperationTimeout: 4h0m0s snapshotMoveData: true 2 storageLocation: default ttl: 720h0m0s 3 volumeSnapshotLocations: - dpa-sample-1 # ...
- 1
fs-backup
에서 옵트아웃하는 볼륨에만 Data Mover를 사용하는 경우true
로 설정합니다. 볼륨에 대해 기본적으로 Data Mover를 사용하는 경우false
로 설정합니다.- 2
- CSI 스냅샷을 원격 오브젝트 스토리지로 이동하려면
true
로 설정합니다. - 3
ttl
필드는 생성된 백업의 보존 시간과 백업 데이터를 정의합니다. 예를 들어 Restic을 백업 도구로 사용하는 경우 백업이 만료될 때까지 백업된 데이터 항목과 PV(영구 볼륨)의 데이터 콘텐츠가 저장됩니다. 그러나 이러한 데이터를 저장하면 대상 백업 위치에 더 많은 공간이 사용됩니다. 추가 스토리지는 만료되지 않은 다른 완료된 백업이 시간 초과되었을 수 있기 전에 생성되는 빈번한 백업과 함께 사용됩니다.
참고XFS 파일 시스템을 사용하여 볼륨을 포맷하고 볼륨이 100%인 경우
장치 오류에 남아 있는 공간이 없는 상태에서
백업이 실패합니다. 예를 들면 다음과 같습니다.Error: relabel failed /var/lib/kubelet/pods/3ac..34/volumes/ \ kubernetes.io~csi/pvc-684..12c/mount: lsetxattr /var/lib/kubelet/ \ pods/3ac..34/volumes/kubernetes.io~csi/pvc-68..2c/mount/data-xfs-103: \ no space left on device
이 시나리오에서는 백업이 성공적으로 완료되도록 볼륨 크기 조정 또는 다른 파일 시스템 유형(예:
ext4
)을 사용하는 것이 좋습니다.매니페스트를 적용합니다.
$ oc create -f backup.yaml
DataUpload
CR은 스냅샷 생성이 완료된 후 생성됩니다.
검증
DataUpload
CR의status.phase
필드를 모니터링하여 스냅샷 데이터가 원격 오브젝트 저장소로 성공적으로 전송되었는지 확인합니다. 가능한 값은진행
중 ,완료됨
,실패
또는취소됨
입니다. 오브젝트 저장소는DataProtectionApplication
CR의backupLocations
스탠자에 구성됩니다.다음 명령을 실행하여 모든
DataUpload
오브젝트 목록을 가져옵니다.$ oc get datauploads -A
출력 예
NAMESPACE NAME STATUS STARTED BYTES DONE TOTAL BYTES STORAGE LOCATION AGE NODE openshift-adp backup-test-1-sw76b Completed 9m47s 108104082 108104082 dpa-sample-1 9m47s ip-10-0-150-57.us-west-2.compute.internal openshift-adp mongo-block-7dtpf Completed 14m 1073741824 1073741824 dpa-sample-1 14m ip-10-0-150-57.us-west-2.compute.internal
다음 명령을 실행하여 특정
DataUpload
오브젝트의status.phase
필드 값을 확인합니다.$ oc get datauploads <dataupload_name> -o yaml
출력 예
apiVersion: velero.io/v2alpha1 kind: DataUpload metadata: name: backup-test-1-sw76b namespace: openshift-adp spec: backupStorageLocation: dpa-sample-1 csiSnapshot: snapshotClass: "" storageClass: gp3-csi volumeSnapshot: velero-mysql-fq8sl operationTimeout: 10m0s snapshotType: CSI sourceNamespace: mysql-persistent sourcePVC: mysql status: completionTimestamp: "2023-11-02T16:57:02Z" node: ip-10-0-150-57.us-west-2.compute.internal path: /host_pods/15116bac-cc01-4d9b-8ee7-609c3bef6bde/volumes/kubernetes.io~csi/pvc-eead8167-556b-461a-b3ec-441749e291c4/mount phase: Completed 1 progress: bytesDone: 108104082 totalBytes: 108104082 snapshotID: 8da1c5febf25225f4577ada2aeb9f899 startTimestamp: "2023-11-02T16:56:22Z"
- 1
- 스냅샷 데이터가 원격 오브젝트 저장소로 성공적으로 전송되었음을 나타냅니다.
4.12.2.2. CSI 볼륨 스냅샷 복원
Restore
CR을 생성하여 볼륨 스냅샷을 복원할 수 있습니다.
OAPD 1.3 기본 제공 데이터 Mover를 사용하여 OADP 1.2의 reflectsync 백업을 복원할 수 없습니다. OADP 1.3으로 업그레이드하기 전에 Restic을 사용하여 모든 워크로드의 파일 시스템 백업을 수행하는 것이 좋습니다.
사전 요구 사항
-
cluster-admin
역할을 사용하여 클러스터에 액세스할 수 있습니다. -
데이터를 복원할 OADP
Backup
CR이 있습니다.
절차
다음 예와 같이
Restore
CR에 대한 YAML 파일을 생성합니다.CR
복원
예apiVersion: velero.io/v1 kind: Restore metadata: name: restore namespace: openshift-adp spec: backupName: <backup> # ...
매니페스트를 적용합니다.
$ oc create -f restore.yaml
복원이 시작될 때
DataDownload
CR이 생성됩니다.
검증
DataDownload
CR의status.phase
필드를 확인하여 복원 프로세스의 상태를 모니터링할 수 있습니다. 가능한 값은진행
중 ,완료됨
,실패
또는취소됨
입니다.모든
DataDownload
오브젝트 목록을 가져오려면 다음 명령을 실행합니다.$ oc get datadownloads -A
출력 예
NAMESPACE NAME STATUS STARTED BYTES DONE TOTAL BYTES STORAGE LOCATION AGE NODE openshift-adp restore-test-1-sk7lg Completed 7m11s 108104082 108104082 dpa-sample-1 7m11s ip-10-0-150-57.us-west-2.compute.internal
다음 명령을 입력하여 특정
DataDownload
오브젝트의status.phase
필드 값을 확인합니다.$ oc get datadownloads <datadownload_name> -o yaml
출력 예
apiVersion: velero.io/v2alpha1 kind: DataDownload metadata: name: restore-test-1-sk7lg namespace: openshift-adp spec: backupStorageLocation: dpa-sample-1 operationTimeout: 10m0s snapshotID: 8da1c5febf25225f4577ada2aeb9f899 sourceNamespace: mysql-persistent targetVolume: namespace: mysql-persistent pv: "" pvc: mysql status: completionTimestamp: "2023-11-02T17:01:24Z" node: ip-10-0-150-57.us-west-2.compute.internal phase: Completed 1 progress: bytesDone: 108104082 totalBytes: 108104082 startTimestamp: "2023-11-02T17:00:52Z"
- 1
- CSI 스냅샷 데이터가 성공적으로 복원되었음을 나타냅니다.
4.12.2.3. OADP 1.3 삭제 정책
삭제 정책은 시스템에서 데이터를 제거하는 규칙을 결정하며 보존 기간, 데이터 민감도 및 규정 준수 요구 사항과 같은 요인에 따라 삭제 시기와 방법을 지정합니다. 규정을 준수하고 중요한 정보를 보존하면서 효과적으로 데이터 제거를 관리합니다.
4.12.2.3.1. OADP 1.3 삭제 정책 지침
OADP 1.3의 다음 삭제 정책 지침을 검토하십시오.
-
OADP 1.3.x에서는 모든 유형의 백업 및 복원 방법을 사용할 때
VolumeSnapshotClass
CR(사용자 정의 리소스)에서deletionPolicy
필드를Retain
또는Delete
로 설정할 수 있습니다.
4.12.3. Kopia 해시, 암호화 및 분할 알고리즘 덮어쓰기
DPA(Data Protection Application)의 특정 환경 변수를 사용하여 Kopia 해시, 암호화 및 분할 알고리즘의 기본값을 재정의할 수 있습니다.
4.12.3.1. Kopia 해시, 암호화 및 분할 알고리즘을 재정의하도록 DPA 구성
OADP(OpenShift API for Data Protection) 옵션을 사용하여 해시, 암호화 및 분할에 대한 기본 Kopia 알고리즘을 재정의하여 Kopia 성능을 개선하거나 성능 지표를 비교할 수 있습니다. DPA의 spec.configuration.velero.podConfig.env
섹션에서 다음 환경 변수를 설정할 수 있습니다.
-
KOPIA_HASHING_ALGORITHM
-
KOPIA_ENCRYPTION_ALGORITHM
-
KOPIA_SPLITTER_ALGORITHM
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성했습니다.
DPA(Data Protection Application)의 분할, 해시 및 암호화를 위한 Kopia 알고리즘의 구성은 초기 Kopia 리포지토리 생성 중에만 적용되며 나중에 변경할 수 없습니다.
다른 Kopia 알고리즘을 사용하려면 오브젝트 스토리지에 이전 Kopia 리포지토리가 포함되어 있지 않은지 확인합니다. Backup Storage Location(BSL)에서 새 오브젝트 스토리지를 구성하거나 BSL 구성에서 오브젝트 스토리지에 대한 고유한 접두사를 지정합니다.
절차
다음 예와 같이 해시, 암호화 및 분할에 대한 환경 변수를 사용하여 DPA를 구성합니다.
DPA 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication #... configuration: nodeAgent: enable: true 1 uploaderType: kopia 2 velero: defaultPlugins: - openshift - aws - csi 3 defaultSnapshotMoveData: true podConfig: env: - name: KOPIA_HASHING_ALGORITHM value: <hashing_algorithm_name> 4 - name: KOPIA_ENCRYPTION_ALGORITHM value: <encryption_algorithm_name> 5 - name: KOPIA_SPLITTER_ALGORITHM value: <splitter_algorithm_name> 6
4.12.3.2. Kopia 해시, 암호화 및 분할 알고리즘을 재정의하는 사용 사례
사용 사례 예제에서는 해시, 암호화 및 분할에 Kopia 환경 변수를 사용하여 애플리케이션 백업을 수행하는 방법을 보여줍니다. 백업을 AWS S3 버킷에 저장합니다. 그런 다음 Kopia 리포지토리에 연결하여 환경 변수를 확인합니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- AWS S3 버킷이 백업 스토리지 위치로 구성되어 있습니다.
- 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성했습니다.
- Kopia 클라이언트를 설치했습니다.
- 별도의 네임스페이스에서 영구 볼륨이 실행되는 애플리케이션이 있습니다.
절차
다음 예와 같이 DPA(Data Protection Application)를 구성합니다.
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> 1 namespace: openshift-adp spec: backupLocations: - name: aws velero: config: profile: default region: <region_name> 2 credential: key: cloud name: cloud-credentials 3 default: true objectStorage: bucket: <bucket_name> 4 prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: kopia velero: defaultPlugins: - openshift - aws - csi 5 defaultSnapshotMoveData: true podConfig: env: - name: KOPIA_HASHING_ALGORITHM value: BLAKE3-256 6 - name: KOPIA_ENCRYPTION_ALGORITHM value: CHACHA20-POLY1305-HMAC-SHA256 7 - name: KOPIA_SPLITTER_ALGORITHM value: DYNAMIC-8M-RABINKARP 8
다음 명령을 실행하여 DPA를 생성합니다.
$ oc create -f <dpa_file_name> 1
- 1
- 구성한 DPA의 파일 이름을 지정합니다.
다음 명령을 실행하여 DPA가 조정되었는지 확인합니다.
$ oc get dpa -o yaml
다음 예와 같이 backup CR을 생성합니다.
백업 CR의 예
apiVersion: velero.io/v1 kind: Backup metadata: name: test-backup namespace: openshift-adp spec: includedNamespaces: - <application_namespace> 1 defaultVolumesToFsBackup: true
- 1
- 클러스터에 설치된 애플리케이션의 네임스페이스를 지정합니다.
다음 명령을 실행하여 백업을 생성합니다.
$ oc apply -f <backup_file_name> 1
- 1
- 백업 CR 파일의 이름을 지정합니다.
다음 명령을 실행하여 백업이 완료되었는지 확인합니다.
$ oc get backups.velero.io <backup_name> -o yaml 1
- 1
- 백업 이름을 지정합니다.
검증
다음 명령을 실행하여 Kopia 리포지토리에 연결합니다.
$ kopia repository connect s3 \ --bucket=<bucket_name> \ 1 --prefix=velero/kopia/<application_namespace> \ 2 --password=static-passw0rd \ 3 --access-key="<aws_s3_access_key>" \ 4 --secret-access-key="<aws_s3_secret_access_key>" \ 5
참고AWS S3 이외의 스토리지 공급자를 사용하는 경우 버킷 끝점 URL 매개변수인
--endpoint
를 명령에 추가해야 합니다.다음 명령을 실행하여 Kopia에서 DPA에 구성된 환경 변수를 사용하는지 확인합니다.
$ kopia repository status
출력 예
Config file: /../.config/kopia/repository.config Description: Repository in S3: s3.amazonaws.com <bucket_name> # ... Storage type: s3 Storage capacity: unbounded Storage config: { "bucket": <bucket_name>, "prefix": "velero/kopia/<application_namespace>/", "endpoint": "s3.amazonaws.com", "accessKeyID": <access_key>, "secretAccessKey": "****************************************", "sessionToken": "" } Unique ID: 58....aeb0 Hash: BLAKE3-256 Encryption: CHACHA20-POLY1305-HMAC-SHA256 Splitter: DYNAMIC-8M-RABINKARP Format version: 3 # ...
4.12.3.3. Kopia 해시, 암호화 및 분할 알고리즘 벤치마킹
Kopia 명령을 실행하여 해시, 암호화 및 분할 알고리즘을 벤치마킹할 수 있습니다. 벤치마킹 결과에 따라 워크로드에 가장 적합한 알고리즘을 선택할 수 있습니다. 이 절차에서는 클러스터의 Pod에서 Kopia 벤치마킹 명령을 실행합니다. 벤치마킹 결과는 CPU 속도, 사용 가능한 RAM, 디스크 속도, 현재 I/O 로드 등에 따라 다를 수 있습니다.
사전 요구 사항
- OADP Operator가 설치되어 있습니다.
- 별도의 네임스페이스에서 영구 볼륨이 실행되는 애플리케이션이 있습니다.
- CSI(Container Storage Interface) 스냅샷을 사용하여 애플리케이션 백업을 실행합니다.
DPA(Data Protection Application)의 분할, 해시 및 암호화를 위한 Kopia 알고리즘의 구성은 초기 Kopia 리포지토리 생성 중에만 적용되며 나중에 변경할 수 없습니다.
다른 Kopia 알고리즘을 사용하려면 오브젝트 스토리지에 이전 Kopia 리포지토리가 포함되어 있지 않은지 확인합니다. Backup Storage Location(BSL)에서 새 오브젝트 스토리지를 구성하거나 BSL 구성에서 오브젝트 스토리지에 대한 고유한 접두사를 지정합니다.
절차
다음 예와 같이
must-gather
Pod를 구성합니다. OADP 버전 1.3 이상에oadp-mustgather
이미지를 사용하고 있는지 확인합니다.Pod 구성 예
apiVersion: v1 kind: Pod metadata: name: oadp-mustgather-pod labels: purpose: user-interaction spec: containers: - name: oadp-mustgather-container image: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 command: ["sleep"] args: ["infinity"]
참고Kopia 클라이언트는
oadp-mustgather
이미지에서 사용할 수 있습니다.다음 명령을 실행하여 Pod를 생성합니다.
$ oc apply -f <pod_config_file_name> 1
- 1
- Pod 구성에 대한 YAML 파일의 이름을 지정합니다.
Kopia가 리포지토리에 연결할 수 있도록 Pod의 SCC(보안 컨텍스트 제약 조건)가
anyuid
인지 확인합니다.$ oc describe pod/oadp-mustgather-pod | grep scc
출력 예
openshift.io/scc: anyuid
다음 명령을 실행하여 SSH를 통해 포드에 연결합니다.
$ oc -n openshift-adp rsh pod/oadp-mustgather-pod
다음 명령을 실행하여 Kopia 리포지토리에 연결합니다.
sh-5.1# kopia repository connect s3 \ --bucket=<bucket_name> \ 1 --prefix=velero/kopia/<application_namespace> \ 2 --password=static-passw0rd \ 3 --access-key="<access_key>" \ 4 --secret-access-key="<secret_access_key>" \ 5 --endpoint=<bucket_endpoint> \ 6
참고다음은 예제 명령입니다. 명령은 오브젝트 스토리지 공급자에 따라 다를 수 있습니다.
해시 알고리즘을 벤치마크하려면 다음 명령을 실행합니다.
sh-5.1# kopia benchmark hashing
출력 예
Benchmarking hash 'BLAKE2B-256' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE2B-256-128' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE2S-128' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE2S-256' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE3-256' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'BLAKE3-256-128' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA224' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA256' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA256-128' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA3-224' (100 x 1048576 bytes, parallelism 1) Benchmarking hash 'HMAC-SHA3-256' (100 x 1048576 bytes, parallelism 1) Hash Throughput ----------------------------------------------------------------- 0. BLAKE3-256 15.3 GB / second 1. BLAKE3-256-128 15.2 GB / second 2. HMAC-SHA256-128 6.4 GB / second 3. HMAC-SHA256 6.4 GB / second 4. HMAC-SHA224 6.4 GB / second 5. BLAKE2B-256-128 4.2 GB / second 6. BLAKE2B-256 4.1 GB / second 7. BLAKE2S-256 2.9 GB / second 8. BLAKE2S-128 2.9 GB / second 9. HMAC-SHA3-224 1.6 GB / second 10. HMAC-SHA3-256 1.5 GB / second ----------------------------------------------------------------- Fastest option for this machine is: --block-hash=BLAKE3-256
암호화 알고리즘을 벤치마크하려면 다음 명령을 실행합니다.
sh-5.1# kopia benchmark encryption
출력 예
Benchmarking encryption 'AES256-GCM-HMAC-SHA256'... (1000 x 1048576 bytes, parallelism 1) Benchmarking encryption 'CHACHA20-POLY1305-HMAC-SHA256'... (1000 x 1048576 bytes, parallelism 1) Encryption Throughput ----------------------------------------------------------------- 0. AES256-GCM-HMAC-SHA256 2.2 GB / second 1. CHACHA20-POLY1305-HMAC-SHA256 1.8 GB / second ----------------------------------------------------------------- Fastest option for this machine is: --encryption=AES256-GCM-HMAC-SHA256
splitter 알고리즘을 벤치마크하려면 다음 명령을 실행합니다.
sh-5.1# kopia benchmark splitter
출력 예
splitting 16 blocks of 32MiB each, parallelism 1 DYNAMIC 747.6 MB/s count:107 min:9467 10th:2277562 25th:2971794 50th:4747177 75th:7603998 90th:8388608 max:8388608 DYNAMIC-128K-BUZHASH 718.5 MB/s count:3183 min:3076 10th:80896 25th:104312 50th:157621 75th:249115 90th:262144 max:262144 DYNAMIC-128K-RABINKARP 164.4 MB/s count:3160 min:9667 10th:80098 25th:106626 50th:162269 75th:250655 90th:262144 max:262144 # ... FIXED-512K 102.9 TB/s count:1024 min:524288 10th:524288 25th:524288 50th:524288 75th:524288 90th:524288 max:524288 FIXED-8M 566.3 TB/s count:64 min:8388608 10th:8388608 25th:8388608 50th:8388608 75th:8388608 90th:8388608 max:8388608 ----------------------------------------------------------------- 0. FIXED-8M 566.3 TB/s count:64 min:8388608 10th:8388608 25th:8388608 50th:8388608 75th:8388608 90th:8388608 max:8388608 1. FIXED-4M 425.8 TB/s count:128 min:4194304 10th:4194304 25th:4194304 50th:4194304 75th:4194304 90th:4194304 max:4194304 # ... 22. DYNAMIC-128K-RABINKARP 164.4 MB/s count:3160 min:9667 10th:80098 25th:106626 50th:162269 75th:250655 90th:262144 max:262144
4.13. 문제 해결
OpenShift CLI 툴 또는 Velero CLI 툴 을 사용하여 Velero 사용자 정의 리소스(CR)를 디버깅할 수 있습니다. Velero CLI 툴에서는 자세한 로그 및 정보를 제공합니다.
설치 문제,백업 및 복원 CR 문제 및 Restic 문제를 확인할 수 있습니다.
must-gather
툴 을 사용하여 로그 및 CR 정보를 수집할 수 있습니다.
Velero CLI 툴은 다음을 통해 얻을 수 있습니다.
- Velero CLI 툴 다운로드
- 클러스터의 Velero 배포에서 Velero 바이너리에 액세스
4.13.1. Velero CLI 툴 다운로드
Velero 문서 페이지의 지침에 따라 Velero CLI 툴을 다운로드하여 설치할 수 있습니다.
페이지에는 다음에 대한 지침이 포함되어 있습니다.
- macOS에서 Homebrew를 사용
- GitHub
- Chocolatey를 사용하여 Windows
사전 요구 사항
- DNS 및 컨테이너 네트워킹이 활성화된 Kubernetes 클러스터 v1.16 이상에 액세스할 수 있습니다.
-
kubectl
을 로컬로 설치했습니다.
절차
- 브라우저를 열고 Velero 웹 사이트에서 "Install the CLI" 로 이동합니다.
- macOS, GitHub 또는 Windows에 대한 적절한 절차를 따르십시오.
- OADP 및 OpenShift Container Platform 버전에 적합한 Velero 버전을 다운로드합니다.
4.13.1.1. OADP-Velero-OpenShift Container Platform 버전 관계
OADP 버전 | Velero 버전 | OpenShift Container Platform 버전 |
---|---|---|
1.1.0 | 4.9 이상 | |
1.1.1 | 4.9 이상 | |
1.1.2 | 4.9 이상 | |
1.1.3 | 4.9 이상 | |
1.1.4 | 4.9 이상 | |
1.1.5 | 4.9 이상 | |
1.1.6 | 4.11 이상 | |
1.1.7 | 4.11 이상 | |
1.2.0 | 4.11 이상 | |
1.2.1 | 4.11 이상 | |
1.2.2 | 4.11 이상 | |
1.2.3 | 4.11 이상 | |
1.3.0 | 4.10 - 4.15 | |
1.3.1 | 4.10 - 4.15 | |
1.3.2 | 4.10 - 4.15 | |
1.3.3 | 4.10 - 4.15 | |
1.4.0 | 4.14 이상 | |
1.4.1 | 4.14 이상 |
4.13.2. 클러스터의 Velero 배포에서 Velero 바이너리에 액세스
쉘 명령을 사용하여 클러스터의 Velero 배포의 Velero 바이너리에 액세스할 수 있습니다.
사전 요구 사항
-
DataProtectionApplication
사용자 정의 리소스의 상태는Reconcile complete
입니다.
절차
다음 명령을 입력하여 필요한 별칭을 설정합니다.
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
4.13.3. OpenShift CLI 툴을 사용하여 Velero 리소스 디버깅
OpenShift CLI 툴을 사용하여 Velero CR(사용자 정의 리소스) 및 Velero
Pod 로그를 확인하여 실패한 백업을 디버그하거나 복원할 수 있습니다.
Velero CR
oc describe
명령을 사용하여 Backup
또는 Restore
CR과 관련된 경고 및 오류 요약을 검색합니다.
$ oc describe <velero_cr> <cr_name>
Velero Pod 로그
oc logs
명령을 사용하여 Velero
pod 로그를 검색합니다.
$ oc logs pod/<velero>
Velero Pod 디버그 로그
다음 예와 같이 DataProtectionApplication
리소스에서 Velero 로그 수준을 지정할 수 있습니다.
이 옵션은 OADP 1.0.3부터 사용할 수 있습니다.
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: velero-sample spec: configuration: velero: logLevel: warning
다음 logLevel
값을 사용할 수 있습니다.
-
trace
-
debug
-
info
-
경고
-
error
-
fatal
-
panic
대부분의 로그에 디버그
를 사용하는 것이 좋습니다.
4.13.4. Velero CLI 툴을 사용하여 Velero 리소스 디버깅
Backup
및 Restore
CR(사용자 정의 리소스)을 디버그하고 Velero CLI 툴을 사용하여 로그를 검색할 수 있습니다.
Velero CLI 툴은 OpenShift CLI 툴보다 자세한 정보를 제공합니다.
구문
oc exec
명령을 사용하여 Velero CLI 명령을 실행합니다.
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ <backup_restore_cr> <command> <cr_name>
예제
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql
도움말 옵션
velero --help
옵션을 사용하여 모든 Velero CLI 명령을 나열합니다.
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ --help
Describe 명령
velero describe
명령을 사용하여 Backup
또는 Restore
CR과 관련된 경고 및 오류 요약을 검색합니다.
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ <backup_restore_cr> describe <cr_name>
예제
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql
다음 유형의 복원 오류 및 경고는 velero describe
요청 출력에 표시됩니다.
-
Velero
: Velero 자체 작업과 관련된 메시지 목록(예: 클라우드 연결, 백업 파일 읽기 등) -
클러스터: 클러스터
범위 리소스 백업 또는 복원과 관련된 메시지 목록입니다. -
네임스페이스
: 네임스페이스에 저장된 리소스 백업 또는 복원과 관련된 메시지 목록
이러한 카테고리 중 하나에 있는 하나 이상의 오류로 인해 복원
작업에서 PartiallyFailed
의 상태를 수신하고 완료
하지 않습니다. 경고로 인해 완료 상태가 변경되지 않습니다.
-
리소스별 오류(
클러스터
및네임스페이스 오류)의
경우restore describe --details
출력에 Velero가 복원에 성공한 모든 리소스를 나열하는 리소스 목록이 포함됩니다. 이러한 오류가 있는 모든 리소스의 경우 리소스가 실제로 클러스터에 있는지 확인합니다. describe
명령의 출력에서Velero
오류가 있지만 리소스별 오류가 없는 경우 워크로드를 복원하는 실제 문제 없이 복원이 완료될 수 있지만 복원 후 애플리케이션을 신중하게 검증할 수 있습니다.예를 들어 출력에
PodVolumeRestore
또는 노드 에이전트 관련 오류가 포함된 경우PodVolumeRestores
및DataDownloads
의 상태를 확인합니다. 이러한 항목이 실패하거나 계속 실행되지 않은 경우 볼륨 데이터가 완전히 복원되었을 수 있습니다.
Logs 명령
velero logs
명령을 사용하여 Backup
또는 Restore
CR의 로그를 검색합니다.
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ <backup_restore_cr> logs <cr_name>
예제
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
4.13.5. 메모리 또는 CPU 부족으로 인해 Pod 충돌 또는 재시작
메모리 또는 CPU 부족으로 인해 Velero 또는 Restic Pod가 충돌하는 경우 해당 리소스 중 하나에 대한 특정 리소스 요청을 설정할 수 있습니다.
추가 리소스
4.13.5.1. Velero Pod에 대한 리소스 요청 설정
oadp_v1alpha1_dpa.yaml
파일에서 configuration.velero.podConfig.resourceAllocations
사양 필드를 사용하여 Velero
Pod에 대한 특정 리소스 요청을 설정할 수 있습니다.
절차
YAML 파일에서
cpu
및memory
리소스 요청을 설정합니다.Velero 파일의 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... configuration: velero: podConfig: resourceAllocations: 1 requests: cpu: 200m memory: 256Mi
- 1
- 나열된
resourceAllocations
는 평균 사용량입니다.
4.13.5.2. Restic Pod에 대한 리소스 요청 설정
configuration.restic.podConfig.resourceAllocations
사양 필드를 사용하여 Restic
Pod에 대한 특정 리소스 요청을 설정할 수 있습니다.
절차
YAML 파일에서
cpu
및memory
리소스 요청을 설정합니다.Restic 파일 예
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... configuration: restic: podConfig: resourceAllocations: 1 requests: cpu: 1000m memory: 16Gi
- 1
- 나열된
resourceAllocations
는 평균 사용량입니다.
리소스 요청 필드의 값은 Kubernetes 리소스 요구 사항과 동일한 형식을 따라야 합니다. 또한 configuration.velero.podConfig.resourceAllocations
또는 configuration.restic.podConfig.resourceAllocations
를 지정하지 않으면 Velero Pod 또는 Restic Pod의 기본 리소스
사양은 다음과 같습니다.
requests: cpu: 500m memory: 128Mi
4.13.6. StorageClass가 NFS인 경우 PodVolumeRestore가 완료되지 않음
Restic
또는 Kopia
를 사용하여 NFS 복원 중에 볼륨이 두 개 이상 있는 경우 복원 작업이 실패합니다. PodVolumeRestore
는 다음 오류와 함께 실패하거나 마지막으로 실패하기 전에 복원하려고 합니다.
오류 메시지
Velero: pod volume restore failed: data path restore failed: \ Failed to run kopia restore: Failed to copy snapshot data to the target: \ restore error: copy file: error creating file: \ open /host_pods/b4d...6/volumes/kubernetes.io~nfs/pvc-53...4e5/userdata/base/13493/2681: \ no such file or directory
원인
NFS 마운트 경로는 복원할 두 볼륨의 고유하지 않습니다. 결과적으로 velero
잠금 파일은 복원 중에 NFS 서버에서 동일한 파일을 사용하므로 PodVolumeRestore
가 실패합니다.
해결 방법
deploy/class.yaml
파일에서 nfs-subdir-external-provisioner
의 StorageClass
를 정의하는 동안 각 볼륨에 고유한 pathPattern
을 설정하여 이 문제를 해결할 수 있습니다. 다음 nfs-subdir-external-provisioner
StorageClass
예제를 사용합니다.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-client
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
pathPattern: "${.PVC.namespace}/${.PVC.annotations.nfs.io/storage-path}" 1
onDelete: delete
- 1
- 레이블, 주석, 이름 또는 네임스페이스와 같은
PVC
메타데이터를 사용하여 디렉터리 경로를 생성하기 위한 템플릿을 지정합니다. 메타데이터를 지정하려면${.PVC.<metadata>} 를 사용합니다
. 예를 들어 폴더의 이름을 <pvc-namespace>-<pvc-name
>로 지정하려면${.PVC.namespace}-${.PVC.name}
을pathPattern
으로 사용합니다.
4.13.7. Velero 및 승인 Webhook 관련 문제
Velero는 복원 중에 승인 Webhook 문제를 해결할 수 있는 제한된 기능을 제공합니다. 승인 Webhook가 있는 워크로드가 있는 경우 추가 Velero 플러그인을 사용하거나 워크로드를 복원하는 방법을 변경해야 할 수 있습니다.
일반적으로 승인 Webhook가 있는 워크로드에는 특정 종류의 리소스를 먼저 생성해야 합니다. 이는 승인 Webhook가 일반적으로 하위 리소스를 차단하므로 워크로드에 하위 리소스가 있는 경우 특히 그러합니다.
예를 들어 service.serving.knative.dev
와 같은 최상위 오브젝트를 생성하거나 복원하면 일반적으로 하위 리소스가 자동으로 생성됩니다. 이 작업을 먼저 수행하는 경우 Velero를 사용하여 이러한 리소스를 생성하고 복원할 필요가 없습니다. 이렇게 하면 Velero가 사용할 수 있는 승인 Webhook에 의해 하위 리소스 문제가 차단되지 않습니다.
4.13.7.1. 승인 Webhook를 사용하는 Velero 백업에 대한 해결 방법 복원
이 섹션에서는 승인 Webhook를 사용하는 Velero 백업의 여러 유형의 리소스를 복원하는 데 필요한 추가 단계에 대해 설명합니다.
4.13.7.1.1. Knative 리소스 복원
Velero를 사용하여 승인 Webhook를 사용하는 Knative 리소스를 백업하는 데 문제가 발생할 수 있습니다.
승인 Webhook를 사용하는 Knative 리소스를 백업하고 복원할 때마다 최상위 서비스
리소스를 먼저 복원하여 이러한 문제를 방지할 수 있습니다.
절차
최상위 수준의
service.serving.knavtive.dev Service
리소스를 복원합니다.$ velero restore <restore_name> \ --from-backup=<backup_name> --include-resources \ service.serving.knavtive.dev
4.13.7.1.2. IBM AppConnect 리소스 복원
승인 Webhook가 있는 IBM AppConnect 리소스를 복원하기 위해 Velero를 사용할 때 문제가 발생하면 이 절차에서 검사를 실행할 수 있습니다.
절차
클러스터에 변경 승인 플러그인이 있는지 확인합니다
: MutatingWebhookConfiguration
.$ oc get mutatingwebhookconfigurations
-
각
종류의 YAML 파일을 검사합니다. MutatingWebhookConfiguration
은 규칙이 문제가 발생하는 오브젝트 생성을 차단하지 않도록 합니다. 자세한 내용은 공식 Kubernetes 설명서를 참조하십시오. -
백업 시간에 사용된
Configuration.appconnect.ibm.com/v1beta1
의spec.version
이 설치된 Operator에서 지원되는지 확인합니다.
4.13.7.2. OADP 플러그인의 알려진 문제
다음 섹션에서는 OADP(OpenShift API for Data Protection) 플러그인의 알려진 문제에 대해 설명합니다.
4.13.7.2.1. 시크릿이 누락되어 이미지 스트림 백업 중 Velero 플러그인 패닉
백업 및 백업 스토리지 위치(BSL)가 데이터 보호 애플리케이션(DPA)의 범위 외부에서 관리되는 경우, OADP 컨트롤러는 DPA 조정에서 관련 oadp-<bsl_name>-<bsl_provider>-registry-secret
을 생성하지 않습니다.
백업이 실행되면 다음 패닉 오류와 함께 이미지 스트림 백업에 OpenShift Velero 플러그인이 패닉됩니다.
024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item" backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io, namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked: runtime error: index out of range with length 1, stack trace: goroutine 94…
4.13.7.2.1.1. 패닉 오류를 방지하기 위한 해결방법
Velero 플러그인 패닉 오류를 방지하려면 다음 단계를 수행합니다.
관련 라벨을 사용하여 사용자 지정 BSL에 레이블을 지정합니다.
$ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl
BSL 레이블이 지정된 후 DPA가 조정될 때까지 기다립니다.
참고DPA 자체를 약간 변경하여 강제로 조정할 수 있습니다.
DPA가 조정되면 관련
oadp-<bsl_name>-<bsl_provider>-registry-secret
이 생성되고 올바른 레지스트리 데이터가 입력되었는지 확인합니다.$ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
4.13.7.2.2. OpenShift ADP 컨트롤러 분할 오류
cloudstorage
및 restic
이 활성화된 DPA를 구성하는 경우 openshift-adp-controller-manager
Pod가 충돌하고 크래시 루프 세그먼트 오류로 인해 Pod가 실패할 때까지 무기한 재시작합니다.
상호 배타적 필드이므로 velero
또는 cloudstorage
를 정의할 수 있습니다.
-
velero
및cloudstorage
가 모두 정의되어 있는 경우openshift-adp-controller-manager
가 실패합니다. -
velero
또는cloudstorage
가 정의되지 않은 경우openshift-adp-controller-manager
가 실패합니다.
이 문제에 대한 자세한 내용은 OADP-1054 를 참조하십시오.
4.13.7.2.2.1. OpenShift ADP 컨트롤러 분할 오류 해결
DPA를 구성할 때 velero
또는 cloudstorage
를 정의해야 합니다. DPA에 두 API를 모두 정의하면 크래시 루프 분할 오류와 함께 openshift-adp-controller-manager
Pod가 실패합니다.
4.13.7.3. Velero 플러그인에서 "received EOF, stop recv loop" 메시지를 반환
Velero 플러그인은 별도의 프로세스로 시작됩니다. Velero 작업이 성공적으로 완료되거나 실패하면 종료됩니다. 디버그 로그에서 recv 루프 메시지를 중지하여 수신된 EOF
를 수신하면 플러그인 작업이 완료되었음을 나타냅니다. 이는 오류가 발생했음을 의미하지 않습니다.
4.13.8. 설치 문제
Data Protection Application을 설치할 때 유효하지 않은 디렉토리를 사용하거나 잘못된 인증 정보를 사용하여 발생한 문제가 발생할 수 있습니다.
4.13.8.1. 백업 스토리지에 잘못된 디렉터리가 포함되어 있습니다.
Velero
Pod 로그에 오류 메시지가 표시되고 Backup 스토리지에 잘못된 최상위 디렉터리가 포함되어 있습니다
.
원인
오브젝트 스토리지에는 Velero 디렉터리가 아닌 최상위 디렉터리가 포함되어 있습니다.
해결 방법
오브젝트 스토리지가 Velero 전용이 아닌 경우 DataProtectionApplication
매니페스트에 spec.backupLocations.velero.objectStorage.prefix
매개변수를 설정하여 버킷의 접두사를 지정해야 합니다.
4.13.8.2. 잘못된 AWS 인증 정보
oadp-aws-registry
Pod 로그에 오류 메시지 InvalidAccessKeyId: The AWS Access Key Id가 기록에 존재하지 않습니다.
Velero
Pod 로그에 오류 메시지 NoCredentialProviders: no valid providers in chain
.
원인
Secret
오브젝트를 생성하는 데 사용되는 credentials-velero
파일이 잘못 포맷됩니다.
해결 방법
다음 예와 같이 credentials-velero
파일이 올바르게 포맷되었는지 확인합니다.
credentials-velero
파일의 예
[default] 1 aws_access_key_id=AKIAIOSFODNN7EXAMPLE 2 aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
4.13.9. OADP Operator 문제
OADP(OpenShift API for Data Protection) Operator는 해결할 수 없는 문제로 인해 문제가 발생할 수 있습니다.
4.13.9.1. OADP Operator가 자동으로 실패
OADP Operator의 S3 버킷은 비어 있을 수 있지만 oc get po -n <OADP_Operator_namespace> 명령을 실행하면 Operator의 상태가
임을 확인할 수 있습니다. 이러한 경우 Operator는 실행 중이라고 잘못 보고하기 때문에 자동으로 실패했다고 합니다.
Running
원인
클라우드 인증 정보가 충분하지 않은 권한을 제공하는 경우 문제가 발생합니다.
해결 방법
백업 스토리지 위치(BSL) 목록을 검색하고 인증 정보 문제는 각 BSL의 매니페스트를 확인합니다.
절차
다음 명령 중 하나를 실행하여 BSL 목록을 검색합니다.
OpenShift CLI 사용:
$ oc get backupstoragelocations.velero.io -A
Velero CLI 사용:
$ velero backup-location get -n <OADP_Operator_namespace>
BSL 목록을 사용하여 다음 명령을 실행하여 각 BSL의 매니페스트를 표시하고 각 매니페스트에 오류가 있는지 검사합니다.
$ oc get backupstoragelocations.velero.io -n <namespace> -o yaml
결과 예
apiVersion: v1 items: - apiVersion: velero.io/v1 kind: BackupStorageLocation metadata: creationTimestamp: "2023-11-03T19:49:04Z" generation: 9703 name: example-dpa-1 namespace: openshift-adp-operator ownerReferences: - apiVersion: oadp.openshift.io/v1alpha1 blockOwnerDeletion: true controller: true kind: DataProtectionApplication name: example-dpa uid: 0beeeaff-0287-4f32-bcb1-2e3c921b6e82 resourceVersion: "24273698" uid: ba37cd15-cf17-4f7d-bf03-8af8655cea83 spec: config: enableSharedConfig: "true" region: us-west-2 credential: key: credentials name: cloud-credentials default: true objectStorage: bucket: example-oadp-operator prefix: example provider: aws status: lastValidationTime: "2023-11-10T22:06:46Z" message: "BackupStorageLocation \"example-dpa-1\" is unavailable: rpc error: code = Unknown desc = WebIdentityErr: failed to retrieve credentials\ncaused by: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n\tstatus code: 403, request id: d3f2e099-70a0-467b-997e-ff62345e3b54" phase: Unavailable kind: List metadata: resourceVersion: ""
4.13.10. OADP 시간 초과
시간 제한을 늘리면 복잡하고 리소스를 많이 사용하는 프로세스가 조기 종료되지 않고 성공적으로 완료할 수 있습니다. 이 구성을 사용하면 오류, 재시도 또는 실패 가능성을 줄일 수 있습니다.
프로세스의 기본 문제를 숨길 수 있는 과도하게 긴 시간 초과를 구성하지 않도록 시간 초과 확장의 균형을 조정해야 합니다. 프로세스 및 전체 시스템 성능을 충족하는 적절한 시간 초과 값을 신중하게 고려하고 모니터링합니다.
다음은 이러한 매개변수를 구현하는 방법과 시기에 대한 지침이 포함된 다양한 OADP 시간 초과입니다.
4.13.10.1. Restic 타임아웃
spec.configuration.nodeAgent.timeout
매개변수는 Restic 타임아웃을 정의합니다. 기본값은 1h
입니다.
다음 시나리오에서는 nodeAgent
섹션에서 Restic timeout
매개변수를 사용합니다.
- 500GB보다 큰 총 PV 데이터 사용량이 있는 Restic 백업의 경우
다음 오류로 인해 백업이 시간 초과되는 경우:
level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete"
절차
다음 예와 같이
DataProtectionApplication
CR(사용자 정의 리소스) 매니페스트의spec.configuration.nodeAgent.timeout
블록에서 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: configuration: nodeAgent: enable: true uploaderType: restic timeout: 1h # ...
4.13.10.2. Velero 리소스 시간 초과
resourceTimeout
은 Velero CRD(사용자 정의 리소스 정의) 가용성, volumeSnapshot
삭제 및 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 시간을 정의합니다. 기본값은 10m
입니다.
다음 시나리오에 대해 resourceTimeout
을 사용합니다.
총 PV 데이터 사용량이 1TB 이상인 백업의 경우 이 매개 변수는 Velero가 백업을 완료로 표시하기 전에 CSI(Container Storage Interface) 스냅샷을 정리하거나 삭제하려고 할 때 시간 초과 값으로 사용됩니다.
- 이 정리의 하위 작업은 VSC 패치를 시도하며 이 시간 초과는 해당 작업에 사용할 수 있습니다.
- Restic 또는 Kopia에 대한 파일 시스템 기반 백업에 대한 백업 리포지토리를 생성하거나 확인하려면 다음을 수행합니다.
- CR(사용자 정의 리소스) 또는 리소스를 백업에서 복원하기 전에 클러스터에서 Velero CRD를 사용할 수 있는지 확인하려면 다음을 수행합니다.
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.configuration.velero.resourceTimeout
블록에서 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: configuration: velero: resourceTimeout: 10m # ...
4.13.10.3. 데이터 Mover 시간 초과
timeout
은 VolumeSnapshotBackup
및 VolumeSnapshotRestore
를 완료하는 사용자 제공 타임아웃입니다. 기본값은 10m
입니다.
다음 시나리오에 대해 Data Mover 시간 초과
를 사용합니다.
-
VolumeSnapshotBackups
(VSB) 및VolumeSnapshotRestores
(VSR)를 생성하는 경우 10분 후에 시간 초과됩니다. -
총 PV 데이터 사용량이 500GB 이상인 대규모 환경의 경우
1h
에 시간 제한을 설정합니다. -
VolumeSnapshotMover
(VSM) 플러그인 사용 - OADP 1.1.x에서만 사용
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.features.dataMover.timeout
블록에서 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: features: dataMover: timeout: 10m # ...
4.13.10.4. CSI 스냅샷 시간 초과
CSISnapshotTimeout
은 오류를 시간 초과로 반환하기 전에 CSI VolumeSnapshot
상태가 ReadyToUse
상태가 될 때까지 대기하는 시간을 지정합니다. 기본값은 10m
입니다.
다음 시나리오에 CSISnapshotTimeout
을 사용합니다.
- CSI 플러그인 사용
- 스냅샷에 10분 이상 걸릴 수 있는 대용량 스토리지 볼륨의 경우. 로그에 시간 초과가 있는 경우 이 시간 제한을 조정합니다.
일반적으로 기본 설정은 대규모 스토리지 볼륨을 수용할 수 있으므로 CSISnapshotTimeout
의 기본값을 조정할 필요가 없습니다.
절차
다음 예제와 같이
Backup
CR 매니페스트의spec.csiSnapshotTimeout
블록에서 값을 편집합니다.apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> spec: csiSnapshotTimeout: 10m # ...
4.13.10.5. Velero 기본 항목 작업 시간 초과
DefaultItemOperationTimeout은 시간
초과 전에 비동기 BackupItemActions
및 RestoreItemActions
가 완료될 때까지 대기하는 시간을 정의합니다. 기본값은 1h
입니다.
다음 시나리오에 defaultItemOperationTimeout
을 사용합니다.
- Data Mover 1.2.x만 사용할 수 있습니다.
- 특정 백업 또는 복원이 완료될 때까지 대기해야 하는 시간을 지정하려면 다음을 수행합니다. OADP 기능의 컨텍스트에서 이 값은 CSI(Container Storage Interface) 데이터 Mover 기능과 관련된 비동기 작업에 사용됩니다.
-
defaultItemOperationTimeout
이defaultItemOperationTimeout
을 사용하여 DPA(Data Protection Application)에 정의되면 백업 및 복원 작업에 모두 적용됩니다.itemOperationTimeout
을 사용하여 다음 "Item operation timeout - restore" 섹션과 "Item operation timeout - backup" 섹션에 설명된 대로 해당 CR의 백업 또는 복원만 정의할 수 있습니다.
절차
다음 예제와 같이
DataProtectionApplication
CR 매니페스트의spec.configuration.velero.defaultItemOperationTimeout
블록에서 값을 편집합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: configuration: velero: defaultItemOperationTimeout: 1h # ...
4.13.10.6. 항목 작업 시간 초과 - 복원
ItemOperationTimeout
은 RestoreItemAction
작업을 기다리는 데 사용되는 시간을 지정합니다. 기본값은 1h
입니다.
다음 시나리오에는 복원 ItemOperationTimeout
을 사용합니다.
- Data Mover 1.2.x만 사용할 수 있습니다.
-
Data Mover가
BackupStorageLocation
에 업로드 및 다운로드되는 경우 . 시간 초과에 도달하면 복원 작업이 완료되지 않으면 실패로 표시됩니다. 스토리지 볼륨 크기 때문에 시간 초과 문제로 인해 데이터 Mover 작업이 실패하는 경우 이 시간 초과 설정을 늘려야 할 수 있습니다.
절차
다음 예제와 같이
Restore
CR 매니페스트의Restore.spec.itemOperationTimeout
블록에서 값을 편집합니다.apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> spec: itemOperationTimeout: 1h # ...
4.13.10.7. 항목 작업 제한 시간 - 백업
ItemOperationTimeout
은 비동기 BackupItemAction
작업을 대기하는 데 사용되는 시간을 지정합니다. 기본값은 1h
입니다.
다음 시나리오에는 ItemOperationTimeout
백업을 사용합니다.
- Data Mover 1.2.x만 사용할 수 있습니다.
-
Data Mover가
BackupStorageLocation
에 업로드 및 다운로드되는 경우 . 시간 초과에 도달하면 백업 작업이 완료되지 않으면 실패로 표시됩니다. 스토리지 볼륨 크기 때문에 시간 초과 문제로 인해 데이터 Mover 작업이 실패하는 경우 이 시간 초과 설정을 늘려야 할 수 있습니다.
절차
다음 예제와 같이
Backup
CR 매니페스트의Backup.spec.itemOperationTimeout
블록에서 값을 편집합니다.apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> spec: itemOperationTimeout: 1h # ...
4.13.11. CR 문제 백업 및 복원
Backup
및 Restore
CR(사용자 정의 리소스)에서 이러한 일반적인 문제가 발생할 수 있습니다.
4.13.11.1. 백업 CR에서 볼륨을 검색할 수 없음
Backup
CR에 InvalidVolume.NotFound: 볼륨 'vol-xxxx'가 존재하지 않는
오류 메시지가 표시됩니다.
원인
영구 볼륨(PV) 및 스냅샷 위치는 서로 다른 지역에 있습니다.
해결 방법
-
스냅샷 위치가 PV와 동일한 지역에 있도록
DataProtectionApplication
매니페스트에서spec.snapshotLocations.velero.config.region
키의 값을 편집합니다. -
새
백업
CR을 만듭니다.
4.13.11.2. 백업 CR 상태가 진행 중인 상태로 유지됨
Backup
CR의 상태는 InProgress
단계에 남아 있으며 완료되지 않습니다.
원인
백업이 중단되면 다시 시작할 수 없습니다.
해결 방법
Backup
CR의 세부 정보를 검색합니다.$ oc -n {namespace} exec deployment/velero -c velero -- ./velero \ backup describe <backup>
Backup
CR을 삭제합니다.$ oc delete backups.velero.io <backup> -n openshift-adp
진행 중인
Backup
CR이 오브젝트 스토리지에 파일을 업로드하지 않았기 때문에 백업 위치를 정리할 필요가 없습니다.-
새
백업
CR을 만듭니다. Velero 백업 세부 정보 보기
$ velero backup describe <backup-name> --details
4.13.11.3. Backup CR 상태는 PartiallyFailed에 남아 있습니다.
Restic이 사용되지 않은 Backup
CR의 상태는 PartiallyFailed
단계에 남아 있으며 완료되지 않습니다. 관련 PVC의 스냅샷이 생성되지 않습니다.
원인
CSI 스냅샷 클래스를 기반으로 백업을 생성하지만 라벨이 누락된 경우 CSI 스냅샷 플러그인이 스냅샷을 생성하지 못합니다. 결과적으로 Velero
pod는 다음과 유사한 오류를 기록합니다.
+
time="2023-02-17T16:33:13Z" level=error msg="Error backing up item" backup=openshift-adp/user1-backup-check5 error="error executing custom action (groupResource=persistentvolumeclaims, namespace=busy1, name=pvc1-user1): rpc error: code = Unknown desc = failed to get volumesnapshotclass for storageclass ocs-storagecluster-ceph-rbd: failed to get volumesnapshotclass for provisioner openshift-storage.rbd.csi.ceph.com, ensure that the desired volumesnapshot class has the velero.io/csi-volumesnapshot-class label" logSource="/remote-source/velero/app/pkg/backup/backup.go:417" name=busybox-79799557b5-vprq
해결 방법
Backup
CR을 삭제합니다.$ oc delete backups.velero.io <backup> -n openshift-adp
-
필요하면
BackupStorageLocation
에서 저장된 데이터를 정리하여 공간을 확보합니다. VolumeSnapshotClass
오브젝트에velero.io/csi-volumesnapshot-class=true
라벨을 적용합니다.$ oc label volumesnapshotclass/<snapclass_name> velero.io/csi-volumesnapshot-class=true
-
새
백업
CR을 만듭니다.
4.13.12. Restic 문제
Restic으로 애플리케이션을 백업할 때 이러한 문제가 발생할 수 있습니다.
4.13.12.1. root_squash가 활성화된 NFS 데이터 볼륨에 대한 Restic 권한 오류
Restic
pod 로그에 오류 메시지 controller=pod-volume-backup error="fork/exec/usr/bin/restic: permission denied"
가 표시됩니다.
원인
NFS 데이터 볼륨에 root_squash
가 활성화된 경우 Restic
은 nfsnobody
에 매핑되고 백업을 생성할 수 있는 권한이 없습니다.
해결 방법
Restic
에 대한 추가 그룹을 생성하고 DataProtectionApplication
매니페스트에 그룹 ID를 추가하여 이 문제를 해결할 수 있습니다.
-
NFS 데이터 볼륨에
Restic
에 대한 추가 그룹을 생성합니다. -
그룹 소유권이 상속되도록 NFS 디렉터리에
setgid
비트를 설정합니다. 다음 예와 같이
spec.configuration.nodeAgent.supplementalGroups
매개변수와 그룹 ID를DataProtectionApplication
매니페스트에 추가합니다.apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication # ... spec: configuration: nodeAgent: enable: true uploaderType: restic supplementalGroups: - <group_id> 1 # ...
- 1
- 보조 그룹 ID를 지정합니다.
-
변경 사항을 적용할 수 있도록
Restic
Pod가 다시 시작될 때까지 기다립니다.
4.13.12.2. Restic Backup CR은 버킷이 제거된 후에는 다시 생성할 수 없습니다.
네임스페이스에 대한 Restic Backup
CR을 생성하고 오브젝트 스토리지 버킷을 비우고 동일한 네임스페이스에 대한 Backup
CR을 다시 생성하면 다시 생성되는 Backup
CR이 실패합니다.
velero
Pod 로그에 다음 오류 메시지가 표시됩니다. stderr=Fatal: 구성 파일을 열 수 없습니다. Stat: 지정된 키가 존재하지 않습니다.\nIs 다음 위치에 리포지토리가 있습니까?
원인
Restic 디렉터리가 오브젝트 스토리지에서 삭제되는 경우 Velero는 ResticRepository
매니페스트에서 Restic 리포지토리를 다시 생성하거나 업데이트하지 않습니다. 자세한 내용은 Velero issue 4421 을 참조하십시오.
해결 방법
다음 명령을 실행하여 네임스페이스에서 관련 Restic 리포지토리를 제거합니다.
$ oc delete resticrepository openshift-adp <name_of_the_restic_repository>
다음 오류 로그에서
mysql-persistent
은 문제가 있는 Restic 리포지토리입니다. 저장소 이름은 명확성을 위해 이탈리아에 표시됩니다.time="2021-12-29T18:29:14Z" level=info msg="1 errors encountered backup up item" backup=velero/backup65 logSource="pkg/backup/backup.go:431" name=mysql-7d99fc949-qbkds time="2021-12-29T18:29:14Z" level=error msg="Error backing up item" backup=velero/backup65 error="pod volume backup failed: error running restic backup, stderr=Fatal: unable to open config file: Stat: The specified key does not exist.\nIs there a repository at the following location?\ns3:http://minio-minio.apps.mayap-oadp- veleo-1234.qe.devcluster.openshift.com/mayapvelerooadp2/velero1/ restic/mysql-persistent\n: exit status 1" error.file="/remote-source/ src/github.com/vmware-tanzu/velero/pkg/restic/backupper.go:184" error.function="github.com/vmware-tanzu/velero/ pkg/restic.(*backupper).BackupPodVolumes" logSource="pkg/backup/backup.go:435" name=mysql-7d99fc949-qbkds
4.13.13. must-gather 툴 사용
must-gather
툴을 사용하여 OADP 사용자 정의 리소스에 대한 로그, 메트릭 및 정보를 수집할 수 있습니다.
must-gather
데이터는 모든 고객 사례에 첨부되어야 합니다.
다음 데이터 수집 옵션을 사용하여 must-gather
툴을 실행할 수 있습니다.
-
전체
must-gather
데이터 수집은 OADP Operator가 설치된 모든 네임스페이스에 대한 Prometheus 메트릭, Pod 로그 및 Velero CR 정보를 수집합니다. -
필수
must-gather
데이터 수집은 특정 기간(예: 1시간 또는 24시간) 동안 Pod 로그 및 Velero CR 정보를 수집합니다. Prometheus 지표 및 중복 로그는 포함되지 않습니다. -
시간 초과가 포함된
must-gather
데이터 수집 많은 실패Backup
CR이 있는 경우 데이터 수집에 시간이 오래 걸릴 수 있습니다. 시간 초과 값을 설정하여 성능을 향상시킬 수 있습니다. - Prometheus 지표 데이터 덤프는 Prometheus에서 수집한 지표 데이터가 포함된 아카이브 파일을 다운로드합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있어야 합니다. - OADP 1.3과 함께 RHEL(Red Hat Enterprise Linux) 9.x를 사용해야 합니다.
절차
-
must-gather
데이터를 저장하려는 디렉터리로 이동합니다. 다음 데이터 수집 옵션 중 하나에 대해
oc adm must-gather
명령을 실행합니다.Prometheus 지표를 포함한 전체
must-gather
데이터 수집$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
데이터는
must-gather/must-gather.tar.gz
로 저장됩니다. Red Hat 고객 포털에서 해당 지원 사례에 이 파일을 업로드할 수 있습니다.특정 기간 동안 Prometheus 메트릭이 없는 필수
must-gather
데이터 수집$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 \ -- /usr/bin/gather_<time>_essential 1
- 1
- 시간을 시간 단위로 지정합니다. 허용되는 값은
1h
,6h
,24h
,72h
또는all
입니다 (예:gather_1h_essential
또는gather_all_essential
).
시간 초과가 있는
must-gather
데이터 수집:$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 \ -- /usr/bin/gather_with_timeout <timeout> 1
- 1
- 시간 초과 값을 초 단위로 지정합니다.
Prometheus 지표 데이터 덤프:
$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_metrics_dump
이 작업에는 오랜 시간이 걸릴 수 있습니다. 데이터는
must-gather/metrics/prom_data.tar.gz
로 저장됩니다.
추가 리소스
4.13.13.1. 안전하지 않은 TLS 연결로 must-gather 사용
사용자 정의 CA 인증서가 사용되는 경우 must-gather
Pod가 velero logs/describe
의 출력을 가져오지 못합니다. 안전하지 않은 TLS 연결과 함께 must-gather
툴을 사용하려면 gather_without_tls
플래그를 must-gather
명령에 전달할 수 있습니다.
절차
-
다음 명령을 사용하여 값이
true
로 설정된gather_without_tls
플래그를must-gather
툴로 전달합니다.
$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_without_tls <true/false>
기본적으로 플래그 값은 false
로 설정됩니다. 안전하지 않은 TLS 연결을 허용하려면 값을 true
로 설정합니다.
4.13.13.2. must-gather 툴을 사용할 때 옵션 결합
현재 must-gather 스크립트를 결합할 수 없습니다(예: 비보안 TLS 연결을 허용하는 동안 시간 초과 임계값 지정). 다음 예와 같이 must-gather 명령줄에서 내부 변수를 설정하여 이러한 제한 사항을 해결할 수 있습니다.
$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- skip_tls=true /usr/bin/gather_with_timeout <timeout_value_in_seconds>
이 예제에서는 gather_with_timeout
스크립트를 실행하기 전에 skip_tls
변수를 설정합니다. 결과는 gather_with_timeout
및 gather_without_tls
의 조합입니다.
이렇게 지정할 수 있는 다른 변수는 다음과 같습니다.
-
logs_since
기본 값이72h
-
request_timeout
, 기본값0s
DataProtectionApplication
CR(사용자 정의 리소스)이 s3Url
및 insecureSkipTLS: true
로 구성된 경우 CR은 CA 인증서가 누락되어 필요한 로그를 수집하지 않습니다. 해당 로그를 수집하려면 다음 옵션을 사용하여 must-gather
명령을 실행합니다.
$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_without_tls true
4.13.14. OADP 모니터링
OpenShift Container Platform에서는 사용자와 관리자가 클러스터를 효과적으로 모니터링 및 관리할 수 있는 모니터링 스택을 제공하고, 이벤트가 발생하는 경우 경고 수신을 포함하여 클러스터에서 실행되는 사용자 애플리케이션 및 서비스의 워크로드 성능을 모니터링 및 분석할 수 있습니다.
추가 리소스
4.13.14.1. OADP 모니터링 설정
OADP Operator는 Velero 서비스 끝점에서 지표를 검색하기 위해 OpenShift 모니터링 스택에서 제공하는 OpenShift 사용자 워크로드 모니터링을 활용합니다. 모니터링 스택을 사용하면 OpenShift Metrics 쿼리 프런트 엔드를 사용하여 사용자 정의 경고 규칙을 생성하거나 지표를 쿼리할 수 있습니다.
활성화된 사용자 워크로드 모니터링을 사용하면 Grafana와 같은 Prometheus 호환 타사 UI를 구성하고 사용하여 Velero 지표를 시각화할 수 있습니다.
메트릭을 모니터링하려면 사용자 정의 프로젝트를 모니터링하고 ServiceMonitor
리소스를 생성하여 openshift-adp
네임스페이스에 있는 이미 활성화된 OADP 서비스 끝점에서 해당 메트릭을 스크랩해야 합니다.
사전 요구 사항
-
cluster-admin
권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다. - 클러스터 모니터링 구성 맵이 생성되어 있습니다.
절차
openshift-monitoring
네임스페이스에서cluster-monitoring-config
ConfigMap
오브젝트를 편집합니다.$ oc edit configmap cluster-monitoring-config -n openshift-monitoring
data
섹션의config.yaml
필드에enableUserWorkload
옵션을 추가하거나 활성화합니다.apiVersion: v1 data: config.yaml: | enableUserWorkload: true 1 kind: ConfigMap metadata: # ...
- 1
- 이 옵션을 추가하거나
true
로 설정합니다.
다음 구성 요소가
openshift-user-workload-monitoring
네임스페이스에서 실행 중인지 확인하여 짧은 시간 동안 User Workload Monitoring Setup을 확인합니다.$ oc get pods -n openshift-user-workload-monitoring
출력 예
NAME READY STATUS RESTARTS AGE prometheus-operator-6844b4b99c-b57j9 2/2 Running 0 43s prometheus-user-workload-0 5/5 Running 0 32s prometheus-user-workload-1 5/5 Running 0 32s thanos-ruler-user-workload-0 3/3 Running 0 32s thanos-ruler-user-workload-1 3/3 Running 0 32s
openshift-user-workload-monitoring
에user-workload-monitoring-config
ConfigMap이 있는지 확인합니다. 존재하는 경우 이 절차의 나머지 단계를 건너뜁니다.$ oc get configmap user-workload-monitoring-config -n openshift-user-workload-monitoring
출력 예
Error from server (NotFound): configmaps "user-workload-monitoring-config" not found
User Workload Monitoring에 대한
user-workload-monitoring-config
ConfigMap
오브젝트를 생성하고2_configure_user_workload_monitoring.yaml
파일 이름에 저장합니다.출력 예
apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: |
2_configure_user_workload_monitoring.yaml
파일을 적용합니다.$ oc apply -f 2_configure_user_workload_monitoring.yaml configmap/user-workload-monitoring-config created
4.13.14.2. OADP 서비스 모니터 생성
OADP는 DPA가 구성될 때 생성되는 openshift-adp-velero-metrics-svc
서비스를 제공합니다. 사용자 워크로드 모니터링에서 사용하는 서비스 모니터는 정의된 서비스를 가리켜야 합니다.
다음 명령을 실행하여 서비스에 대한 세부 정보를 가져옵니다.
절차
openshift-adp-velero-metrics-svc
서비스가 있는지 확인합니다.ServiceMonitor
오브젝트의 선택기로 사용할app.kubernetes.io/name=velero
레이블이 포함되어야 합니다.$ oc get svc -n openshift-adp -l app.kubernetes.io/name=velero
출력 예
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE openshift-adp-velero-metrics-svc ClusterIP 172.30.38.244 <none> 8085/TCP 1h
기존 서비스 레이블과 일치하는
ServiceMonitor
YAML 파일을 생성하고 파일을3_create_oadp_service_monitor.yaml
로 저장합니다. 서비스 모니터는openshift-adp
-velero-metrics-svc 서비스가 있는 openshift-adp
네임스페이스에 생성됩니다.ServiceMonitor
오브젝트의 예apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: app: oadp-service-monitor name: oadp-service-monitor namespace: openshift-adp spec: endpoints: - interval: 30s path: /metrics targetPort: 8085 scheme: http selector: matchLabels: app.kubernetes.io/name: "velero"
3_create_oadp_service_monitor.yaml
파일을 적용합니다.$ oc apply -f 3_create_oadp_service_monitor.yaml
출력 예
servicemonitor.monitoring.coreos.com/oadp-service-monitor created
검증
OpenShift Container Platform 웹 콘솔의 관리자 화면을 사용하여 새 서비스 모니터가 Up 상태인지 확인합니다.
- 모니터링 → 대상 페이지로 이동합니다.
-
필터 가 선택되지 않았거나 사용자 소스가 선택되어 있는지 확인하고
텍스트
검색 필드에openshift-adp
를 입력합니다. 서비스 모니터의 상태 상태가 Up 인지 확인합니다.
그림 4.1. OADP 메트릭 대상
4.13.14.3. 경고 규칙 생성
OpenShift Container Platform 모니터링 스택을 사용하면 경고 규칙을 사용하여 구성된 경고를 수신할 수 있습니다. OADP 프로젝트에 대한 경고 규칙을 생성하려면 사용자 워크로드 모니터링으로 스크랩되는 지표 중 하나를 사용합니다.
절차
샘플
OADPBackupFailing
경고를 사용하여PrometheusRule
YAML 파일을 생성하고4_create_oadp_alert_rule.yaml
로 저장합니다.샘플
OADPBackupFailing
경고apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: sample-oadp-alert namespace: openshift-adp spec: groups: - name: sample-oadp-backup-alert rules: - alert: OADPBackupFailing annotations: description: 'OADP had {{$value | humanize}} backup failures over the last 2 hours.' summary: OADP has issues creating backups expr: | increase(velero_backup_failure_total{job="openshift-adp-velero-metrics-svc"}[2h]) > 0 for: 5m labels: severity: warning
이 샘플에서는 다음 조건 아래에 경고가 표시됩니다.
- 지난 2시간 동안 0보다 큰 새 오류 백업이 증가하고 상태가 최소 5분 동안 지속됩니다.
-
첫 번째 증가 시간이 5분 미만이면 경고가
Pending
상태가 되고 그 후에는 실행 중 상태가 됩니다.
openshift-adp
네임스페이스에PrometheusRule
오브젝트를 생성하는4_create_oadp_alert_rule.yaml
파일을 적용합니다.$ oc apply -f 4_create_oadp_alert_rule.yaml
출력 예
prometheusrule.monitoring.coreos.com/sample-oadp-alert created
검증
경고가 트리거되면 다음과 같은 방법으로 볼 수 있습니다.
- 개발자 화면에서 모니터링 메뉴를 선택합니다.
관리자 관점에서 모니터링 → 경고 메뉴의 필터 상자에서 사용자를 선택합니다. 그렇지 않으면 기본적으로 플랫폼 경고만 표시됩니다.
그림 4.2. OADP 백업 실패 경고
추가 리소스
4.13.14.4. 사용 가능한 메트릭 목록
이러한 지표는 OADP가 해당 유형과 함께 제공하는 메트릭 목록입니다.
메트릭 이름 | 설명 | 유형 |
---|---|---|
| 캐시에서 검색된 바이트 수 | 카운터 |
| 캐시에서 콘텐츠를 검색한 횟수 | 카운터 |
| 캐시에서 잘못된 콘텐츠를 읽은 횟수 | 카운터 |
| 캐시에서 콘텐츠를 찾을 수 없고 가져온 횟수 | 카운터 |
| 기본 스토리지에서 검색된 바이트 수 | 카운터 |
| 기본 스토리지에서 콘텐츠를 찾을 수 없는 횟수 | 카운터 |
| 캐시에 콘텐츠를 저장할 수 없는 횟수 | 카운터 |
|
| 카운터 |
|
| 카운터 |
|
| 카운터 |
|
| 카운터 |
|
| 카운터 |
|
| 카운터 |
| 시도된 총 백업 수 | 카운터 |
| 시도된 총 백업 삭제 수 | 카운터 |
| 실패한 백업 삭제 총 수 | 카운터 |
| 성공적인 백업 삭제 총 수 | 카운터 |
| 백업 완료 시간(초) | 히스토그램 |
| 실패한 총 백업 수 | 카운터 |
| 백업 중 발생한 총 오류 수 | 게이지 |
| 백업된 총 항목 수 | 게이지 |
| 백업의 마지막 상태입니다. 1의 값은 success, 0입니다. | 게이지 |
| 백업이 성공적으로 실행된 마지막 시간, Unix 타임스탬프(초) | 게이지 |
| 부분적으로 실패한 백업의 총 수 | 카운터 |
| 총 성공적인 백업 수 | 카운터 |
| 백업의 크기(바이트) | 게이지 |
| 현재 존재하는 백업 수 | 게이지 |
| 총 검증 실패 백업 수 | 카운터 |
| 경고된 총 백업 수 | 카운터 |
| 총 CSI 시도 볼륨 스냅샷 수 | 카운터 |
| 총 CSI 실패 볼륨 스냅샷 수 | 카운터 |
| 총 CSI 성공 볼륨 스냅샷 수 | 카운터 |
| 시도한 총 복원 수 | 카운터 |
| 실패한 총 복원 수 | 카운터 |
| 부분적으로 실패한 복원의 총 수 | 카운터 |
| 성공적인 총 복원 수 | 카운터 |
| 현재 존재하는 복원 수 | 게이지 |
| 검증에 실패한 총 복원 수 | 카운터 |
| 시도한 총 볼륨 스냅샷 수 | 카운터 |
| 실패한 총 볼륨 스냅샷 수 | 카운터 |
| 총 볼륨 스냅샷 수 | 카운터 |
4.13.14.5. 모니터링 UI를 사용하여 메트릭 보기
OpenShift Container Platform 웹 콘솔의 관리자 또는 개발자 화면에서 메트릭을 볼 수 있습니다. openshift-adp
프로젝트에 액세스할 수 있어야 합니다.
절차
모니터링 → 메트릭 페이지로 이동합니다.
개발자 화면을 사용하는 경우 다음 단계를 따르십시오.
- 사용자 지정 쿼리 를 선택하거나 PromQL 표시 링크를 클릭합니다.
- 쿼리를 입력하고 Enter 를 클릭합니다.
관리자 화면을 사용하는 경우 텍스트 필드에 표현식을 입력하고 Run Queries 를 선택합니다.
그림 4.3. OADP 메트릭 쿼리
4.14. OADP와 함께 사용되는 API
이 문서에서는 OADP와 함께 사용할 수 있는 다음 API에 대한 정보를 제공합니다.
- Velero API
- OADP API
4.14.1. Velero API
Velero API 문서는 Red Hat이 아닌 Velero에서 유지 관리합니다. Velero API 유형에서 찾을 수 있습니다.
4.14.2. OADP API
다음 표에서는 OADP API의 구조를 제공합니다.
속성 | 유형 | 설명 |
---|---|---|
|
| |
|
| |
| map [ UnsupportedImageKey ] 문자열 |
개발을 위해 배포된 종속 이미지를 재정의하는 데 사용할 수 있습니다. 옵션은 |
| Operator에서 배포한 Pod에 주석을 추가하는 데 사용됩니다. | |
| Pod의 DNS 구성을 정의합니다. | |
|
| |
| *bool | 이미지 백업 및 복원을 활성화하기 위해 레지스트리를 배포할지 여부를 지정하는 데 사용됩니다. |
| 데이터 보호 애플리케이션의 서버 구성을 정의하는 데 사용됩니다. | |
|
* | 기술 프리뷰 기능을 활성화하는 DPA에 대한 구성을 정의합니다. |
속성 | 유형 | 설명 |
---|---|---|
| ||
| [기술 프리뷰] 백업 스토리지 위치로 사용하기 위해 일부 클라우드 스토리지 공급자에서 버킷 생성을 자동화합니다. |
bucket
매개변수는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
BackupLocation
유형의 스키마 정의를 완료합니다.
속성 | 유형 | 설명 |
---|---|---|
| 볼륨 스냅샷 위치에 설명된 대로 볼륨 스냅샷을 저장할 위치입니다. |
SnapshotLocation
유형의 스키마 정의를 완료합니다.
속성 | 유형 | 설명 |
---|---|---|
| Velero 서버에 대한 구성을 정의합니다. | |
| Restic 서버에 대한 구성을 정의합니다. |
ApplicationConfig
유형의 스키마 정의를 완료합니다.
속성 | 유형 | 설명 |
---|---|---|
| [] string | Velero 인스턴스에 사용할 기능 목록을 정의합니다. |
| [] string |
다음과 같은 기본 Velero 플러그인을 설치할 수 있습니다. |
| 사용자 지정 Velero 플러그인 설치에 사용됩니다. 기본 및 사용자 정의 플러그인은 OADP 플러그인에설명되어 있습니다. | |
|
| |
|
기본 백업 스토리지 위치 없이 Velero를 설치하려면 설치를 확인하려면 | |
|
| |
|
Velero 서버의 로그 수준(가장 세부적인 로깅에 대해 |
VeleroConfig
유형의 스키마 정의를 완료합니다.
속성 | 유형 | 설명 |
---|---|---|
| 사용자 정의 플러그인의 이름입니다. | |
| 사용자 지정 플러그인의 이미지입니다. |
CustomPlugin
유형의 스키마 정의를 완료합니다.
속성 | 유형 | 설명 |
---|---|---|
| *bool |
|
| []int64 |
|
|
Restic 타임아웃을 정의하는 사용자 제공 기간 문자열입니다. 기본값은 | |
|
|
ResticConfig
유형의 스키마 정의를 완료합니다.
속성 | 유형 | 설명 |
---|---|---|
|
| |
| []톨러레이션 |
Velero 배포 또는 Restic |
|
Velero CPU 및 메모리 리소스 할당 설정에 설명된 대로 | |
| Pod에 추가할 레이블입니다. |
4.14.2.1. 노드 에이전트 및 노드 라벨 구성
OADP의 DPA는 nodeSelector
필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector
필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.
지정된 라벨은 각 노드의 라벨과 일치해야 합니다.
선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다.
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
다음 예제는 nodeSelector
의 안티 패턴이며 'node-role.kubernetes.io/infra: ""'
및 'node-role.kubernetes.io/worker: ""'
둘 다 노드에 있지 않으면 작동하지 않습니다.
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
속성 | 유형 | 설명 |
---|---|---|
| 데이터 Mover의 구성을 정의합니다. |
기능
유형에 대한 전체 스키마 정의 입니다.
속성 | 유형 | 설명 |
---|---|---|
|
| |
|
데이터 Mover의 사용자 제공 Restic | |
|
|
OADP API는 OADP Operator 에 자세히 설명되어 있습니다.
4.15. 고급 OADP 기능 및 기능
이 문서에서는 OADP(OpenShift API for Data Protection)의 고급 기능 및 기능에 대한 정보를 제공합니다.
4.15.1. 동일한 클러스터에서 다른 Kubernetes API 버전으로 작업
4.15.1.1. 클러스터의 Kubernetes API 그룹 버전 나열
소스 클러스터는 이러한 버전 중 하나가 기본 API 버전인 API의 여러 버전을 제공할 수 있습니다. 예를 들어 Example
이라는 API가 있는 소스 클러스터는 example.com/v1
및 example.com/v1beta2
API 그룹에서 사용할 수 있습니다.
Velero를 사용하여 이러한 소스 클러스터를 백업하고 복원하는 경우 Velero는 Kubernetes API의 기본 버전을 사용하는 해당 리소스의 버전만 백업합니다.
위 예제로 돌아가려면 example.com/v1
이 기본 API인 경우 Velero는 example.com/v1
을 사용하는 리소스의 버전만 백업합니다. 또한 Velero가 대상 클러스터에서 리소스를 복원하려면 대상 클러스터에 example.com/v1
이 사용 가능한 API 리소스 세트에 등록되어 있어야 합니다.
따라서 기본 API 버전이 사용 가능한 API 리소스 세트에 등록되어 있는지 확인하려면 대상 클러스터에서 Kubernetes API 그룹 버전 목록을 생성해야 합니다.
절차
- 다음 명령을 실행합니다.
$ oc api-resources
4.15.1.2. API 그룹 버전 활성화 정보
기본적으로 Velero는 Kubernetes API의 기본 버전을 사용하는 리소스만 백업합니다. 그러나 Velero에는 이러한 제한을 해결하는 기능인 Enable API Group Versions 도 포함되어 있습니다. 소스 클러스터에서 활성화되면 Velero가 기본 기능뿐만 아니라 클러스터에서 지원되는 모든 Kubernetes API 그룹 버전을 백업합니다. 백업 .tar 파일에 버전이 저장된 후 대상 클러스터에서 복원할 수 있습니다.
예를 들어 Example
이라는 API가 있는 소스 클러스터는 example.com/v1
및 example.com/v1beta2
API 그룹에서 사용할 수 있으며 example.com/v1
은 기본 API입니다.
API 그룹 버전 사용 기능을 활성화하지 않으면 Velero는 예제
용으로 기본 API 그룹 버전만 백업합니다. 이 버전은 example.com/v1
입니다. 이 기능을 활성화하면 Velero도 example.com/v1beta2
를 백업합니다.
대상 클러스터에서 API 그룹 버전 활성화 기능이 활성화되면 Velero는 API 그룹 버전의 우선 순위에 따라 복원할 버전을 선택합니다.
Enable API Group Versions는 아직 베타 버전입니다.
Velero는 다음 알고리즘을 사용하여 1
을 가장 우선 순위로 사용하여 API 버전에 우선순위를 할당합니다.
- 대상 클러스터의 기본 버전
- source_ 클러스터의 기본 버전
- Kubernetes 버전 우선순위가 가장 높은 일반 지원 버전
추가 리소스
4.15.1.3. Enable API Group Versions 사용
Velero의 Enable API Group Versions 기능을 사용하여 기본 버전뿐만 아니라 클러스터에서 지원되는 모든 Kubernetes API 그룹 버전을 백업할 수 있습니다.
Enable API Group Versions는 아직 베타 버전입니다.
절차
-
EnableAPIGroupVersions
기능 플래그를 구성합니다.
apiVersion: oadp.openshift.io/vialpha1 kind: DataProtectionApplication ... spec: configuration: velero: featureFlags: - EnableAPIGroupVersions
추가 리소스
4.15.2. 한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원
4.15.2.1. 한 클러스터에서 데이터 백업 및 다른 클러스터에서 복원 정보
OADP(OpenShift API for Data Protection)는 동일한 OpenShift Container Platform 클러스터에서 애플리케이션 데이터를 백업하고 복원하도록 설계되었습니다. MTC(Migration Toolkit for Containers)는 하나의 OpenShift Container Platform 클러스터에서 다른 클러스터로 애플리케이션 데이터를 포함한 컨테이너를 마이그레이션하도록 설계되었습니다.
OADP를 사용하여 하나의 OpenShift Container Platform 클러스터에서 애플리케이션 데이터를 백업하고 다른 클러스터에 복원할 수 있습니다. 그러나 이러한 작업은 MTC를 사용하거나 OADP를 사용하여 동일한 클러스터에서 백업 및 복원하는 것보다 더 복잡합니다.
OADP를 사용하여 한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원하려면 OADP를 사용하여 동일한 클러스터에서 데이터를 백업하고 복원하는 데 적용되는 사전 요구 사항 및 절차 외에 다음 요인을 고려해야 합니다.
- Operator
- Velero 사용
- UID 및 GID 범위
4.15.2.1.1. Operator
백업 및 복원에 성공하려면 애플리케이션의 백업에서 Operator를 제외해야 합니다.
4.15.2.1.2. Velero 사용
OADP가 구축된 Velero는 기본적으로 클라우드 공급자 간에 영구 볼륨 스냅샷 마이그레이션을 지원하지 않습니다. 클라우드 플랫폼 간에 볼륨 스냅샷 데이터를 마이그레이션하려면 파일 시스템 수준에서 볼륨 콘텐츠를 백업하는 Velero Restic 파일 시스템 백업 옵션을 활성화 하거나 CSI 스냅샷에 대해 OADP Data Mover를 사용해야 합니다.
OADP 1.1 및 이전 버전에서는 Velero Restic 파일 시스템 백업 옵션을 restic
이라고 합니다. OADP 1.2 이상에서는 Velero Restic 파일 시스템 백업 옵션을 file-system-backup
이라고 합니다.
- 또한 Velero의 파일 시스템 백업을 사용하여 AWS 리전 간에 데이터를 마이그레이션하거나 Microsoft Azure 리전 간에 데이터를 마이그레이션해야 합니다.
- Velero는 소스 클러스터보다 이전 Kubernetes 버전의 클러스터로 데이터 복원을 지원하지 않습니다.
- 이론적으로 소스보다 최신 Kubernetes 버전이 있는 대상으로 워크로드를 마이그레이션할 수 있지만 각 사용자 지정 리소스에 대한 클러스터 간 API 그룹의 호환성을 고려해야 합니다. Kubernetes 버전 업그레이드에서 코어 또는 네이티브 API 그룹의 호환성을 중단하는 경우 먼저 영향을 받는 사용자 정의 리소스를 업데이트해야 합니다.
4.15.2.2. 백업할 Pod 볼륨 확인 정보
파일 시스템 백업(FSB)을 사용하여 백업 작업을 시작하기 전에 백업할 볼륨이 포함된 Pod를 지정해야 합니다. Velero는 이 프로세스를 적절한 Pod 볼륨을 "검색"이라고 합니다.
Velero는 Pod 볼륨을 결정하기 위해 다음 두 가지 접근 방식을 지원합니다. opt-in 또는 opt-out 접근 방식을 사용하여 Velero가 FSB, 볼륨 스냅샷 또는 Data Mover 백업을 결정할 수 있습니다.
- 옵트인 접근 방식: 옵트인 접근 방식을 사용하면 기본적으로 스냅샷 또는 데이터 Mover를 사용하여 볼륨이 백업됩니다. FSB는 주석으로 옵트인되는 특정 볼륨에서 사용됩니다.
- 옵트아웃 접근 방식에서는 옵트아웃 접근 방식을 통해 기본적으로 FSB를 사용하여 볼륨이 백업됩니다. 스냅샷 또는 데이터 Mover는 주석으로 옵트아웃되는 특정 볼륨에서 사용됩니다.
4.15.2.2.1. 제한
-
FSB는
hostpath
볼륨 백업 및 복원을 지원하지 않습니다. 그러나 FSB는 로컬 볼륨 백업 및 복원을 지원합니다. - Velero는 생성하는 모든 백업 리포지토리에 정적, 공통 암호화 키를 사용합니다. 이 정적 키는 백업 스토리지에 액세스할 수 있는 모든 사용자가 백업 데이터를 해독할 수 있음을 의미합니다. 백업 스토리지에 대한 액세스를 제한하는 것이 중요합니다.
PVC의 경우 Pod 일정을 변경할 때마다 모든 증분 백업 체인이 유지됩니다.
emptyDir
볼륨과 같이 PVC가 아닌 Pod 볼륨의 경우(예:ReplicaSet
또는 배포) Pod가 삭제되거나 다시 생성되는 경우 해당 볼륨의 다음 백업은 증분 백업이 아닌 전체 백업이 됩니다. Pod 볼륨의 라이프사이클이 해당 Pod에 의해 정의되는 것으로 가정합니다.- 백업 데이터를 점진적으로 유지할 수 있지만 데이터베이스와 같은 대용량 파일을 백업하는 데 시간이 오래 걸릴 수 있습니다. FSB는 중복 제거를 사용하여 백업해야 하는 차이점을 찾기 때문입니다.
- FSB는 Pod가 실행 중인 노드의 파일 시스템에 액세스하여 볼륨에서 데이터를 읽고 씁니다. 이러한 이유로 FSB는 PVC에서 직접 마운트하지 않고 Pod에서 마운트된 볼륨만 백업할 수 있습니다. 일부 Velero 사용자는 Velero 백업을 수행하기 전에 이러한 PVC 및 PV 쌍을 마운트하도록 BusyBox 또는 Alpine 컨테이너와 같은 스테이징 Pod를 실행하여 이 제한을 극복했습니다.
-
FSB에서는 <
hostPath>/<pod UID
> 아래에 볼륨을 마운트할 것으로 예상하고, <hostPath
>를 구성할 수 있습니다. 예를 들어 vCluster와 같은 일부 Kubernetes 시스템은 <pod UID
> 하위 디렉터리 아래에 볼륨을 마운트하지 않으며 VFSB는 예상대로 작동하지 않습니다.
4.15.2.2.2. 옵트인 방법을 사용하여 Pod 볼륨 백업
옵트인 방법을 사용하여 파일 시스템 백업(FSB)에서 백업해야 하는 볼륨을 지정할 수 있습니다. backup.velero.io/backup-volumes
명령을 사용하여 이 작업을 수행할 수 있습니다.
절차
백업할 볼륨이 하나 이상 포함된 각 Pod에서 다음 명령을 입력합니다.
$ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \ backup.velero.io/backup-volumes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>
다음과 같습니다.
<your_volume_name_x>
- Pod 사양에 xth 볼륨의 이름을 지정합니다.
4.15.2.2.3. 옵트아웃 방법을 사용하여 Pod 볼륨 백업
옵트아웃 접근 방식을 사용하는 경우 몇 가지 예외가 있지만 FSB(File System Backup)를 사용하여 모든 Pod 볼륨이 백업됩니다.
- 기본 서비스 계정 토큰, 시크릿 및 구성 맵을 마운트하는 볼륨입니다.
-
hostPath
볼륨
옵트아웃 방법을 사용하여 백업 하지 않는 볼륨을 지정할 수 있습니다. backup.velero.io/backup-volumes-excludes
명령을 사용하여 이 작업을 수행할 수 있습니다.
절차
백업하지 않으려는 볼륨이 하나 이상 포함된 각 Pod에서 다음 명령을 실행합니다.
$ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \ backup.velero.io/backup-volumes-excludes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>
다음과 같습니다.
<your_volume_name_x>
- Pod 사양에 xth 볼륨의 이름을 지정합니다.
--default-volumes-to-fs-backup
플래그를 사용하여 velero install
명령을 실행하여 모든 Velero 백업에 대해 이 동작을 활성화할 수 있습니다.
4.15.2.3. UID 및 GID 범위
한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원하는 경우 UID(사용자 ID) 및 GID(그룹 ID) 범위에서 문제가 발생할 수 있습니다. 다음 섹션에서는 이러한 잠재적인 문제 및 완화 방법에 대해 설명합니다.
- 문제 요약
- 대상 클러스터에 따라 네임스페이스 UID 및 GID 범위가 변경될 수 있습니다. OADP는 OpenShift UID 범위 메타데이터를 백업하고 복원하지 않습니다. 백업 애플리케이션에 특정 UID가 필요한 경우 범위를 사용할 수 있는지 확인합니다. OpenShift의 UID 및 GID 범위에 대한 자세한 내용은 A Guide to OpenShift and UIDs 를 참조하십시오.
- 문제에 대한 자세한 설명
쉘 명령
oc create namespace
를 사용하여 OpenShift Container Platform에서 네임스페이스를 생성할 때 OpenShift Container Platform은 사용 가능한 UID 풀, 추가 그룹(GID) 범위 및 고유한 SELinux MCS 레이블에서 네임스페이스에 고유한 UID(사용자 ID) 범위를 할당합니다. 이 정보는 클러스터의metadata.annotations
필드에 저장됩니다. 이 정보는 다음 구성 요소로 구성된 SCC(보안 컨텍스트 제약 조건) 주석의 일부입니다.-
openshift.io/sa.scc.mcs
-
openshift.io/sa.scc.supplemental-groups
-
openshift.io/sa.scc.uid-range
-
OADP를 사용하여 네임스페이스를 복원하면 대상 클러스터에 대해 재설정하지 않고 metadata.annotations
의 정보를 자동으로 사용합니다. 결과적으로 다음 중 하나라도 해당하는 경우 워크로드가 백업된 데이터에 액세스할 수 없을 수 있습니다.
- 다른 SCC 주석이 있는 기존 네임스페이스가 있습니다(예: 다른 클러스터에). 이 경우 OADP는 복원하려는 네임스페이스 대신 백업 중에 기존 네임스페이스를 사용합니다.
백업 중에 레이블 선택기가 사용되었지만 워크로드가 실행되는 네임스페이스에 레이블이 없습니다. 이 경우 OADP는 네임스페이스를 백업하지 않지만 백업 네임스페이스의 주석이 포함되지 않은 복원 중에 새 네임스페이스를 생성합니다. 그러면 새 UID 범위가 네임스페이스에 할당됩니다.
이는 OpenShift Container Platform에서 영구 볼륨 데이터가 백업된 이후 변경된 네임스페이스 주석을 기반으로 Pod에
securityContext
UID를 할당하는 경우 고객 워크로드에 문제가 될 수 있습니다.- 컨테이너의 UID가 더 이상 파일 소유자의 UID와 일치하지 않습니다.
OpenShift Container Platform이 백업 클러스터 데이터와 일치하도록 대상 클러스터의 UID 범위를 변경하지 않았기 때문에 오류가 발생합니다. 결과적으로 백업 클러스터에는 대상 클러스터와 다른 UID가 있으므로 애플리케이션이 대상 클러스터에서 데이터를 읽거나 쓸 수 없습니다.
- 완화 방법
- 다음 완화 방법 중 하나를 사용하여 UID 및 GID 범위 문제를 해결할 수 있습니다.
간단한 완화 방법:
-
Backup
CR에서 라벨 선택기를 사용하여 백업에 포함할 오브젝트를 필터링하는 경우 이 라벨 선택기를 작업 공간이 포함된 네임스페이스에 추가해야 합니다. - 동일한 이름의 네임스페이스를 복원하기 전에 대상 클러스터에서 기존 네임스페이스 버전을 제거합니다.
-
고급 완화 방법:
- 마이그레이션 후 OpenShift 네임스페이스에서 UID 범위가 겹치는 UID 범위를 다시 확인하여 UID 범위를 수정합니다. 1단계는 선택 사항입니다.
한 클러스터에서 데이터를 백업하고 다른 클러스터에서 데이터를 복원하는 데 있는 문제를 해결하면서 OpenShift Container Platform의 UID 및 GID 범위에 대한 자세한 내용은 OpenShift 및 UID에 대한 가이드를 참조하십시오.
4.15.2.4. 한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원
일반적으로 하나의 OpenShift Container Platform 클러스터의 데이터를 백업하고 동일한 클러스터에 데이터를 백업하고 복원하는 것과 동일한 방식으로 다른 OpenShift Container Platform 클러스터에 복원합니다. 그러나 한 OpenShift Container Platform 클러스터에서 데이터를 백업하고 다른 OpenShift Container Platform 클러스터에서 복원할 때 프로세스에 몇 가지 추가 사전 요구 사항과 차이점이 있습니다.
사전 요구 사항
- 플랫폼(예: AWS, Microsoft Azure, GCP 등)에서 백업 및 복원을 위한 모든 관련 사전 요구 사항은 이 가이드의 관련 섹션에 설명되어 있습니다.
절차
플랫폼에 지정된 절차를 추가합니다.
- 백업 저장소 위치(BSL) 및 볼륨 스냅샷 위치에 다른 클러스터의 리소스를 복원하는 것과 동일한 이름과 경로가 있는지 확인합니다.
- 클러스터 전체에서 동일한 오브젝트 스토리지 위치 인증 정보를 공유합니다.
- 최상의 결과를 얻으려면 OADP를 사용하여 대상 클러스터에 네임스페이스를 생성합니다.
Velero
file-system-backup
옵션을 사용하는 경우 다음 명령을 실행하여 백업 중에 사용할--default-volumes-to-fs-backup
플래그를 활성화합니다.$ velero backup create <backup_name> --default-volumes-to-fs-backup <any_other_options>
OADP 1.2 이상에서는 Velero Restic 옵션을 file-system-backup
이라고 합니다.
4.15.3. OADP 스토리지 클래스 매핑
4.15.3.1. 스토리지 클래스 매핑
스토리지 클래스 매핑을 사용하면 다양한 유형의 데이터에 적용해야 하는 스토리지 클래스를 지정하는 규칙 또는 정책을 정의할 수 있습니다. 이 기능은 액세스 빈도, 데이터 중요 및 비용 고려 사항에 따라 스토리지 클래스를 결정하는 프로세스를 자동화합니다. 특성 및 사용 패턴에 대해 데이터가 가장 적합한 스토리지 클래스에 저장되도록 하여 스토리지 효율성 및 비용 효율성을 최적화합니다.
change-storage-class-config
필드를 사용하여 데이터 오브젝트의 스토리지 클래스를 변경할 수 있으므로 요구 사항과 액세스 패턴에 따라 다양한 스토리지 계층 간에 데이터를 이동하여 비용 및 성능을 최적화할 수 있습니다.
4.15.3.1.1. Migration Toolkit for Containers를 사용한 스토리지 클래스 매핑
MTC(Migration Toolkit for Containers)를 사용하여 하나의 OpenShift Container Platform 클러스터에서 다른 클러스터로 애플리케이션 데이터를 포함한 컨테이너를 마이그레이션하고 스토리지 클래스 매핑 및 변환을 수행할 수 있습니다. 동일한 클러스터 내에서 마이그레이션하여 PV(영구 볼륨)의 스토리지 클래스를 변환할 수 있습니다. 이를 위해서는 MTC 웹 콘솔에서 마이그레이션 계획을 생성하고 실행해야 합니다.
4.15.3.1.2. OADP로 스토리지 클래스 매핑
Velero 플러그인 v1.1.0 이상과 함께 OpenShift API for Data Protection(OADP)을 사용하여 Velero 네임스페이스의 구성 맵에 스토리지 클래스 매핑을 구성하여 복원 중에 PV(영구 볼륨)의 스토리지 클래스를 변경할 수 있습니다.
OADP를 사용하여 ConfigMap을 배포하려면 change-storage-class-config
필드를 사용합니다. 클라우드 공급자에 따라 스토리지 클래스 매핑을 변경해야 합니다.
절차
다음 명령을 실행하여 스토리지 클래스 매핑을 변경합니다.
$ cat change-storageclass.yaml
다음 예와 같이 Velero 네임스페이스에 구성 맵을 생성합니다.
예제
apiVersion: v1 kind: ConfigMap metadata: name: change-storage-class-config namespace: openshift-adp labels: velero.io/plugin-config: "" velero.io/change-storage-class: RestoreItemAction data: standard-csi: ssd-csi
다음 명령을 실행하여 스토리지 클래스 매핑 기본 설정을 저장합니다.
$ oc create -f change-storage-class-config
4.15.4. 추가 리소스
5장. 컨트롤 플레인 백업 및 복원
5.1. etcd 백업
etcd는 모든 리소스 개체의 상태를 저장하는 OpenShift Container Platform의 키-값 형식의 저장소입니다.
클러스터의 etcd 데이터를 정기적으로 백업하고 OpenShift Container Platform 환경 외부의 안전한 위치에 백업 데이터를 저장하십시오. 설치 후 24 시간 내에 발생하는 첫 번째 인증서 교체가 완료되기 전까지 etcd 백업을 수행하지 마십시오. 인증서 교체가 완료되기 전에 실행하면 백업에 만료된 인증서가 포함됩니다. etcd 스냅샷에 I/O 비용이 높기 때문에 사용량이 많지 않은 시간 동안 etcd 백업을 수행하는 것이 좋습니다.
클러스터를 업그레이드한 후 etcd 백업을 수행해야 합니다. 이는 클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 하므로 중요합니다. 예를 들어 OpenShift Container Platform 4.y.z 클러스터는 4.y.z에서 가져온 etcd 백업을 사용해야 합니다.
컨트롤 플레인 호스트에서 백업 스크립트를 실행하여 클러스터의 etcd 데이터를 백업합니다. 클러스터의 각 컨트롤 플레인 호스트마다 백업을 수행하지 마십시오.
etcd 백업 후 이전 클러스터 상태로 복원할 수 있습니다.
5.1.1. etcd 데이터 백업
다음 단계에 따라 etcd 스냅샷을 작성하고 정적 pod의 리소스를 백업하여 etcd 데이터를 백업합니다. 이 백업을 저장하여 etcd를 복원해야하는 경우 나중에 사용할 수 있습니다.
단일 컨트롤 플레인 호스트의 백업만 저장합니다. 클러스터의 각 컨트롤 플레인 호스트에서 백업을 수행하지 마십시오.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. 클러스터 전체의 프록시가 활성화되어 있는지 확인해야 합니다.
작은 정보oc get proxy cluster -o yaml
의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다.httpProxy
,httpsProxy
및noProxy
필드에 값이 설정되어 있으면 프록시가 사용됩니다.
절차
컨트롤 플레인 노드의 root로 디버그 세션을 시작합니다.
$ oc debug --as-root node/<node_name>
디버그 쉘에서 root 디렉토리를
/host
로 변경합니다.sh-4.4# chroot /host
클러스터 전체 프록시가 활성화된 경우 다음 명령을 실행하여
NO_PROXY
,HTTP_PROXY
및HTTPS_PROXY
환경 변수를 내보냅니다.$ export HTTP_PROXY=http://<your_proxy.example.com>:8080
$ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
$ export NO_PROXY=<example.com>
디버그 쉘에서
cluster-backup.sh
스크립트를 실행하고 백업을 저장할 위치를 전달합니다.작은 정보cluster-backup.sh
스크립트는 etcd Cluster Operator의 구성 요소로 유지 관리되며etcdctl snapshot save
명령 관련 래퍼입니다.sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup
스크립트 출력 예
found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6 found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7 found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6 found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3 ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1 etcdctl version: 3.4.14 API version: 3.4 {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"} {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"} {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"} {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"} {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459} {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"} Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336} snapshot db and kube resources are successfully saved to /home/core/assets/backup
이 예제에서는 컨트롤 플레인 호스트의
/home/core/assets/backup/
디렉토리에 두 개의 파일이 생성됩니다.-
snapshot_<datetimestamp>.db
:이 파일은 etcd 스냅샷입니다.cluster-backup.sh
스크립트는 유효성을 확인합니다. static_kuberesources_<datetimestamp>.tar.gz
: 이 파일에는 정적 pod 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.참고etcd 암호화가 활성화되어 있는 경우 보안상의 이유로 이 두 번째 파일을 etcd 스냅 샷과 별도로 저장하는 것이 좋습니다. 그러나 이 파일은 etcd 스냅 샷에서 복원하는데 필요합니다.
etcd 암호화는 키가 아닌 값만 암호화합니다. 이는 리소스 유형, 네임 스페이스 및 개체 이름은 암호화되지 않습니다.
-
5.1.2. 추가 리소스
5.2. 비정상적인 etcd 멤버 교체
이 문서는 비정상적인 단일 etcd 멤버를 교체하는 프로세스를 설명합니다.
이 프로세스는 시스템이 실행 중이 아니거나 노드가 준비되지 않았거나 etcd pod가 크래시 루프 상태에있는 등 etcd 멤버의 비정상적인 상태에 따라 다릅니다.
대부분의 컨트롤 플레인 호스트가 손실된 경우 재해 복구 절차에 따라 이 절차 대신 이전 클러스터 상태로 복원 하십시오.
교체 중인 멤버 에서 컨트롤 플레인 인증서가 유효하지 않은 경우 이 절차 대신 만료된 컨트롤 플레인 인증서 복구 절차를 따라야 합니다.
컨트롤 플레인 노드가 유실되고 새 노드가 생성되는 경우 etcd 클러스터 Operator는 새 TLS 인증서 생성 및 노드를 etcd 멤버로 추가하는 프로세스를 진행합니다.
5.2.1. 사전 요구 사항
- 비정상적인 etcd 멤버를 교체하기 전에 etcd 백업을 수행하십시오.
5.2.2. 비정상 etcd 멤버 식별
클러스터에 비정상적인 etcd 멤버가 있는지 여부를 확인할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
다음 명령을 사용하여
EtcdMembersAvailable
상태의 상태 조건을 확인하십시오.$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}'
출력을 확인합니다.
2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy
이 출력 예는
ip-10-0-131-183.ec2.internal
etcd 멤버가 비정상임을 보여줍니다.
5.2.3. 비정상적인 etcd 멤버의 상태 확인
비정상적인 etcd 멤버를 교체하는 프로세스는 etcd가 다음의 어떤 상태에 있는지에 따라 달라집니다.
- 컴퓨터가 실행 중이 아니거나 노드가 준비되지 않았습니다.
- etcd pod가 크래시 루프 상태에 있습니다.
다음 프로세스에서는 etcd 멤버가 어떤 상태에 있는지를 확인합니다. 이를 통해 비정상 etcd 멤버를 대체하기 위해 수행해야하는 단계를 확인할 수 있습니다.
시스템이 실행되고 있지 않거나 노드가 준비되지 않았지만 곧 정상 상태로 돌아올 것으로 예상되는 경우 etcd 멤버를 교체하기 위한 절차를 수행할 필요가 없습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 비정상적인 etcd 멤버를 식별하고 있습니다.
프로세스
시스템이 실행되고 있지 않은지를 확인합니다.
$ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running
출력 예
ip-10-0-131-183.ec2.internal stopped 1
- 1
- 이 출력은 노드와 노드 시스템의 상태를 나열합니다. 상태가
running
이 아닌 경우 시스템은 실행되지 않습니다.
시스템이 실행되고 있지 않은 경우, 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.
노드가 준비되지 않았는지 확인합니다.
다음 조건 중 하나에 해당하면 노드가 준비되지 않은 것입니다.
시스템이 실행중인 경우 노드에 액세스할 수 있는지 확인하십시오.
$ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable
출력 예
ip-10-0-131-183.ec2.internal node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable 1
- 1
unreachable
상태의 노드가 나열되면 노드가 준비되지 않은 것 입니다.
노드에 여전히 액세스할 수 있는 경우 노드가
NotReady
로 나열되어 있는지 확인하십시오.$ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"
출력 예
ip-10-0-131-183.ec2.internal NotReady master 122m v1.26.0 1
- 1
- 노드가
NotReady
로 표시되면 노드가 준비되지 않은 것입니다.
노드가 준비되지 않은 경우 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.
etcd pod가 크래시 루프 상태인지 확인합니다.
시스템이 실행되고 있고 노드가 준비된 경우 etcd pod가 크래시 루프 상태인지 확인하십시오.
모든 컨트롤 플레인 노드가
Ready
로 나열되어 있는지 확인합니다.$ oc get nodes -l node-role.kubernetes.io/master
출력 예
NAME STATUS ROLES AGE VERSION ip-10-0-131-183.ec2.internal Ready master 6h13m v1.26.0 ip-10-0-164-97.ec2.internal Ready master 6h13m v1.26.0 ip-10-0-154-204.ec2.internal Ready master 6h13m v1.26.0
etcd pod의 상태가
Error
또는CrashloopBackoff
인지 확인하십시오.$ oc -n openshift-etcd get pods -l k8s-app=etcd
출력 예
etcd-ip-10-0-131-183.ec2.internal 2/3 Error 7 6h9m 1 etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 6h6m etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 6h6m
- 1
- 이 pod의 상태는
Error
이므로 etcd pod는 크래시 루프 상태입니다.
etcd pod가 크래시 루프 상태인 경우etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.
5.2.4. 비정상적인 etcd 멤버 교체
비정상적인 etcd 멤버의 상태에 따라 다음 절차 중 하나를 사용합니다.
5.2.4.1. 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체
다음에서는 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 경우의 비정상적인 etcd 멤버를 교체하는 프로세스에 대해 자세히 설명합니다.
클러스터가 컨트롤 플레인 머신 세트를 사용하는 경우 보다 간단한 etcd 복구 프로세스의 "컨트롤 플레인 머신 세트 해결"의 "분명된 etcd Operator 복구"를 참조하십시오.
사전 요구 사항
- 비정상적인 etcd 멤버를 식별했습니다.
시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.
중요다른 컨트롤 플레인 노드의 전원이 꺼진 경우 기다려야 합니다. 비정상 etcd 멤버 교체가 완료될 때까지 컨트롤 플레인 노드의 전원을 꺼야 합니다.
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. etcd 백업이 수행되었습니다.
중요문제가 발생할 경우 클러스터를 복원할 수 있도록 이 프로세스를 수행하기 전에 etcd 백업을 수행해야합니다.
프로세스
비정상적인 멤버를 제거합니다.
영향을 받는 노드에 없는 pod를 선택합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc -n openshift-etcd get pods -l k8s-app=etcd
출력 예
etcd-ip-10-0-131-183.ec2.internal 3/3 Running 0 123m etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 123m etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 124m
실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
멤버 목록을 확인합니다.
sh-4.2# etcdctl member list -w table
출력 예
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 | | 757b6793e2408b6c | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오.
$ etcdctl endpoint health
명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.etcdctl member remove
명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.sh-4.2# etcdctl member remove 6fc1e7c9db35841d
출력 예
Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346
멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다.
sh-4.2# etcdctl member list -w table
출력 예
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | 757b6793e2408b6c | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
이제 노드 쉘을 종료할 수 있습니다.
다음 명령을 입력하여 쿼럼 보호기를 끄십시오.
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.
중요쿼럼 가드를 끄면 나머지 etcd 인스턴스가 재부팅되는 동안 구성 변경 사항을 반영하는 동안 클러스터에 연결할 수 없을 수 있습니다.
참고두 멤버로 실행하는 경우 etcd는 추가 멤버 실패를 허용할 수 없습니다. 나머지 멤버 중 하나를 다시 시작하면 쿼럼이 중단되고 클러스터의 다운 타임이 발생합니다. 쿼럼 가드에서는 다운타임을 일으킬 수 있는 구성 변경으로 인해 etcd가 다시 시작되지 않도록 보호하므로 이 절차를 완료하려면 비활성화해야 합니다.
다음 명령을 실행하여 영향을 받는 노드를 삭제합니다.
$ oc delete node <node_name>
명령 예
$ oc delete node ip-10-0-131-183.ec2.internal
삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.
삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다.
$ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1
- 1
- 이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.
다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.
출력 예
etcd-peer-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-metrics-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.
피어 시크릿을 삭제합니다.
$ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
서빙 시크릿을 삭제합니다.
$ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
메트릭 시크릿을 삭제합니다.
$ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
컨트롤 플레인 시스템을 삭제하고 다시 생성합니다. 이 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd는 자동으로 확장됩니다.
설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 마스터를 만드는 데 사용된 방법과 동일한 방법을 사용하여 새 마스터를 만들어야 합니다.
비정상 멤버의 컴퓨터를 가져옵니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc get machines -n openshift-machine-api -o wide
출력 예
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-0 Running m4.xlarge us-east-1 us-east-1a 3h37m ip-10-0-131-183.ec2.internal aws:///us-east-1a/i-0ec2782f8287dfb7e stopped 1 clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-154-204.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-164-97.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
- 1
- 이는 비정상 노드의 컨트롤 플레인 시스템
ip-10-0-131-183.ec2.internal
입니다.
비정상 멤버의 시스템을 삭제합니다.
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
- 1
- 비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.
비정상 멤버의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.
새 시스템이 생성되었는지 확인합니다.
$ oc get machines -n openshift-machine-api -o wide
출력 예
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-154-204.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-164-97.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-master-3 Provisioning m4.xlarge us-east-1 us-east-1a 85s ip-10-0-133-53.ec2.internal aws:///us-east-1a/i-015b0888fe17bc2c8 running 1 clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
- 1
- 새 시스템
clustername-8qw5l-master-3
이 생성되고 단계가Provisioning
에서Running
으로 변경되면 시스템이 준비 상태가 됩니다.
새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.
참고시스템 세트에 사용하는 서브넷 ID를 확인하여 해당 ID가 올바른 가용성 영역에 속하는지 확인합니다.
다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
다음 명령을 입력하여
unsupportedConfigOverrides
섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.$ oc get etcd/cluster -oyaml
단일 노드 OpenShift를 사용하는 경우 노드를 다시 시작합니다. 그렇지 않으면 etcd 클러스터 Operator에서 다음 오류가 발생할 수 있습니다.
출력 예
EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
검증
모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc -n openshift-etcd get pods -l k8s-app=etcd
출력 예
etcd-ip-10-0-133-53.ec2.internal 3/3 Running 0 7m49s etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 123m etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 124m
이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
- 1
forceRedeploymentReason
값은 고유해야하므로 타임 스탬프가 추가됩니다.
정확히 세 개의 etcd 멤버가 있는지 확인합니다.
실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
멤버 목록을 확인합니다.
sh-4.2# etcdctl member list -w table
출력 예
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | 5eb0d6b8ca24730c | started | ip-10-0-133-53.ec2.internal | https://10.0.133.53:2380 | https://10.0.133.53:2379 | | 757b6793e2408b6c | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.
주의올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다.
추가 리소스
5.2.4.2. etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체
이 단계에서는 etcd pod가 크래시 루프 상태에 있는 경우 비정상 etcd 멤버를 교체하는 방법을 설명합니다.
전제 조건
- 비정상적인 etcd 멤버를 식별했습니다.
- etcd pod가 크래시 루프 상태에 있는것으로 확인되었습니다.
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있습니다. etcd 백업이 수행되었습니다.
중요문제가 발생할 경우 클러스터를 복원할 수 있도록 이 프로세스를 수행하기 전에 etcd 백업을 수행해야합니다.
프로세스
크래시 루프 상태에 있는 etcd pod를 중지합니다.
크래시 루프 상태의 노드를 디버깅합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc debug node/ip-10-0-131-183.ec2.internal 1
- 1
- 이를 비정상 노드의 이름으로 변경합니다.
루트 디렉토리를
/host
로 변경합니다.sh-4.2# chroot /host
kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.
sh-4.2# mkdir /var/lib/etcd-backup
sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
etcd 데이터 디렉토리를 다른 위치로 이동합니다.
sh-4.2# mv /var/lib/etcd/ /tmp
이제 노드 쉘을 종료할 수 있습니다.
비정상적인 멤버를 제거합니다.
영향을 받는 노드에 없는 pod를 선택합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc -n openshift-etcd get pods -l k8s-app=etcd
출력 예
etcd-ip-10-0-131-183.ec2.internal 2/3 Error 7 6h9m etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 6h6m etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 6h6m
실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
멤버 목록을 확인합니다.
sh-4.2# etcdctl member list -w table
출력 예
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 | | b78e2856655bc2eb | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오.
etcdctl member remove
명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.sh-4.2# etcdctl member remove 62bcf33650a7170a
출력 예
Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346
멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다.
sh-4.2# etcdctl member list -w table
출력 예
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | b78e2856655bc2eb | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
이제 노드 쉘을 종료할 수 있습니다.
다음 명령을 입력하여 쿼럼 보호기를 끄십시오.
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.
삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.
삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다.
$ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1
- 1
- 이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.
다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.
출력 예
etcd-peer-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-metrics-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.
피어 시크릿을 삭제합니다.
$ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
서빙 시크릿을 삭제합니다.
$ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
메트릭 시크릿을 삭제합니다.
$ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
etcd를 강제로 재배포합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
- 1
forceRedeploymentReason
값은 고유해야하므로 타임 스탬프가 추가됩니다.
etcd 클러스터 Operator가 재배포를 수행하면 모든 컨트롤 플레인 노드가 etcd pod가 작동하는지 확인합니다.
다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
다음 명령을 입력하여
unsupportedConfigOverrides
섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.$ oc get etcd/cluster -oyaml
단일 노드 OpenShift를 사용하는 경우 노드를 다시 시작합니다. 그렇지 않으면 etcd 클러스터 Operator에서 다음 오류가 발생할 수 있습니다.
출력 예
EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
검증
새 멤버가 사용 가능하고 정상적인 상태에 있는지 확인합니다.
실행중인 etcd 컨테이너에 다시 연결합니다.
cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다.
$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
모든 멤버가 정상인지 확인합니다.
sh-4.2# etcdctl endpoint health
출력 예
https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms
5.2.4.3. 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 베어 메탈 etcd 멤버 교체
이 절차에서는 시스템이 실행되고 있지 않거나 노드가 준비되지 않았기 때문에 비정상 베어 메탈 etcd 멤버를 교체하는 단계를 자세히 설명합니다.
설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오. 그렇지 않으면 원래 생성하는 데 사용된 것과 동일한 방법을 사용하여 새 컨트롤 플레인 노드를 생성해야 합니다.
사전 요구 사항
- 비정상적인 베어 메탈 etcd 멤버를 식별했습니다.
- 시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. etcd 백업이 수행되었습니다.
중요문제가 발생하면 클러스터를 복원할 수 있도록 이 절차를 수행하기 전에 etcd 백업을 수행해야 합니다.
절차
비정상 멤버를 확인하고 제거합니다.
영향을 받는 노드에 없는 pod를 선택합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
출력 예
etcd-openshift-control-plane-0 5/5 Running 11 3h56m 192.168.10.9 openshift-control-plane-0 <none> <none> etcd-openshift-control-plane-1 5/5 Running 0 3h54m 192.168.10.10 openshift-control-plane-1 <none> <none> etcd-openshift-control-plane-2 5/5 Running 0 3h58m 192.168.10.11 openshift-control-plane-2 <none> <none>
실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
멤버 목록을 확인합니다.
sh-4.2# etcdctl member list -w table
출력 예
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+ | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false | | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false | | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/ | false | +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오.
etcdctl endpoint health
명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.etcdctl member remove
명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.주의올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다.
sh-4.2# etcdctl member remove 7a8197040a5126c8
출력 예
Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b
멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다.
sh-4.2# etcdctl member list -w table
출력 예
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+ | cc3830a72fc357f9 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false | | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false | +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
이제 노드 쉘을 종료할 수 있습니다.
중요멤버를 제거한 후 나머지 etcd 인스턴스가 재부팅되는 동안 클러스터에 연결할 수 없을 수 있습니다.
다음 명령을 입력하여 쿼럼 보호기를 끄십시오.
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.
다음 명령을 실행하여 제거된 비정상 etcd 멤버의 이전 암호를 제거하십시오.
삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다.
$ oc get secrets -n openshift-etcd | grep openshift-control-plane-2
이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.
다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.
etcd-peer-openshift-control-plane-2 kubernetes.io/tls 2 134m etcd-serving-metrics-openshift-control-plane-2 kubernetes.io/tls 2 134m etcd-serving-openshift-control-plane-2 kubernetes.io/tls 2 134m
제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.
피어 시크릿을 삭제합니다.
$ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd secret "etcd-peer-openshift-control-plane-2" deleted
서빙 시크릿을 삭제합니다.
$ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd secret "etcd-serving-metrics-openshift-control-plane-2" deleted
메트릭 시크릿을 삭제합니다.
$ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd secret "etcd-serving-openshift-control-plane-2" deleted
비정상 멤버의 컴퓨터를 가져옵니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc get machines -n openshift-machine-api -o wide
출력 예
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE examplecluster-control-plane-0 Running 3h11m openshift-control-plane-0 baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e externally provisioned 1 examplecluster-control-plane-1 Running 3h11m openshift-control-plane-1 baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1 externally provisioned examplecluster-control-plane-2 Running 3h11m openshift-control-plane-2 baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135 externally provisioned examplecluster-compute-0 Running 165m openshift-compute-0 baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f provisioned examplecluster-compute-1 Running 165m openshift-compute-1 baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9 provisioned
- 1
- 이는 비정상 노드의 컨트롤 플레인 시스템(
예:cluster-control-plane-2)
입니다.
다음 명령을 실행하여 Bare Metal Operator를 사용할 수 있는지 확인합니다.
$ oc get clusteroperator baremetal
출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE baremetal 4.13.0 True False False 3d15h
다음 명령을 실행하여 이전
BareMetalHost
오브젝트를 제거합니다.$ oc delete bmh openshift-control-plane-2 -n openshift-machine-api
출력 예
baremetalhost.metal3.io "openshift-control-plane-2" deleted
다음 명령을 실행하여 비정상 멤버의 시스템을 삭제합니다.
$ oc delete machine -n openshift-machine-api examplecluster-control-plane-2
BareMetalHost
및Machine
Node
오브젝트를 자동으로 삭제합니다.머신 삭제가 어떤 이유로든 지연되거나 명령이 지연되고 지연되면 머신 오브젝트 종료자 필드를 제거하여 삭제를 강제 수행할 수 있습니다.
중요Ctrl+c
를 눌러 머신 삭제를 중단하지 마십시오. 명령이 완료되도록 허용해야 합니다. 새 터미널 창을 열어 종료자 필드를 편집하고 삭제합니다.비정상 멤버의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.
다음 명령을 실행하여 머신 구성을 편집합니다.
$ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
Machine
사용자 정의 리소스에서 다음 필드를 삭제한 다음 업데이트된 파일을 저장합니다.finalizers: - machine.machine.openshift.io
출력 예
machine.machine.openshift.io/examplecluster-control-plane-2 edited
다음 명령을 실행하여 시스템이 삭제되었는지 확인합니다.
$ oc get machines -n openshift-machine-api -o wide
출력 예
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE examplecluster-control-plane-0 Running 3h11m openshift-control-plane-0 baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e externally provisioned examplecluster-control-plane-1 Running 3h11m openshift-control-plane-1 baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1 externally provisioned examplecluster-compute-0 Running 165m openshift-compute-0 baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f provisioned examplecluster-compute-1 Running 165m openshift-compute-1 baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9 provisioned
다음 명령을 실행하여 노드가 삭제되었는지 확인합니다.
$ oc get nodes NAME STATUS ROLES AGE VERSION openshift-control-plane-0 Ready master 3h24m v1.26.0 openshift-control-plane-1 Ready master 3h24m v1.26.0 openshift-compute-0 Ready worker 176m v1.26.0 openshift-compute-1 Ready worker 176m v1.26.0
BMC 인증 정보를 저장할 새
BareMetalHost
오브젝트와 시크릿을 생성합니다.$ cat <<EOF | oc apply -f - apiVersion: v1 kind: Secret metadata: name: openshift-control-plane-2-bmc-secret namespace: openshift-machine-api data: password: <password> username: <username> type: Opaque --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: openshift-control-plane-2 namespace: openshift-machine-api spec: automatedCleaningMode: disabled bmc: address: redfish://10.46.61.18:443/redfish/v1/Systems/1 credentialsName: openshift-control-plane-2-bmc-secret disableCertificateVerification: true bootMACAddress: 48:df:37:b0:8a:a0 bootMode: UEFI externallyProvisioned: false online: true rootDeviceHints: deviceName: /dev/disk/by-id/scsi-<serial_number> userData: name: master-user-data-managed namespace: openshift-machine-api EOF
참고사용자 이름과 암호는 다른 베어 메탈 호스트의 시크릿에서 확인할 수 있습니다.
bmc:address
에서 사용할 프로토콜을 다른 bmh 오브젝트에서 가져올 수 있습니다.중요기존 컨트롤 플레인 호스트에서
BareMetalHost
오브젝트 정의를 재사용하는 경우 externalProvisioned
필드를true
로 설정하지 마십시오.기존 컨트롤 플레인
BareMetalHost
오브젝트에 OpenShift Container Platform 설치 프로그램에서 프로비저닝한 경우 externalProvisioned
플래그가true
로 설정되어 있을 수 있습니다.검사가 완료되면
BareMetalHost
오브젝트가 생성되고 프로비저닝할 수 있습니다.사용 가능한
BareMetalHost
오브젝트를 사용하여 생성 프로세스를 확인합니다.$ oc get bmh -n openshift-machine-api NAME STATE CONSUMER ONLINE ERROR AGE openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true 4h48m openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true 4h48m openshift-control-plane-2 available examplecluster-control-plane-3 true 47m openshift-compute-0 provisioned examplecluster-compute-0 true 4h48m openshift-compute-1 provisioned examplecluster-compute-1 true 4h48m
새 시스템이 생성되었는지 확인합니다.
$ oc get machines -n openshift-machine-api -o wide
출력 예
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE examplecluster-control-plane-0 Running 3h11m openshift-control-plane-0 baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e externally provisioned 1 examplecluster-control-plane-1 Running 3h11m openshift-control-plane-1 baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1 externally provisioned examplecluster-control-plane-2 Running 3h11m openshift-control-plane-2 baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135 externally provisioned examplecluster-compute-0 Running 165m openshift-compute-0 baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f provisioned examplecluster-compute-1 Running 165m openshift-compute-1 baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9 provisioned
- 1
- 새 시스템
clustername-8qw5l-master-3
이 생성되고 단계가Provisioning
에서Running
으로 변경된 후 준비됩니다.
새 머신을 생성하는 데 몇 분이 걸립니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.
다음 명령을 실행하여 베어 메탈 호스트가 프로비저닝되고 오류가 보고되지 않았는지 확인합니다.
$ oc get bmh -n openshift-machine-api
출력 예
$ oc get bmh -n openshift-machine-api NAME STATE CONSUMER ONLINE ERROR AGE openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true 4h48m openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true 4h48m openshift-control-plane-2 provisioned examplecluster-control-plane-3 true 47m openshift-compute-0 provisioned examplecluster-compute-0 true 4h48m openshift-compute-1 provisioned examplecluster-compute-1 true 4h48m
다음 명령을 실행하여 새 노드가 추가되었고 준비 상태인지 확인합니다.
$ oc get nodes
출력 예
$ oc get nodes NAME STATUS ROLES AGE VERSION openshift-control-plane-0 Ready master 4h26m v1.26.0 openshift-control-plane-1 Ready master 4h26m v1.26.0 openshift-control-plane-2 Ready master 12m v1.26.0 openshift-compute-0 Ready worker 3h58m v1.26.0 openshift-compute-1 Ready worker 3h58m v1.26.0
다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
다음 명령을 입력하여
unsupportedConfigOverrides
섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.$ oc get etcd/cluster -oyaml
단일 노드 OpenShift를 사용하는 경우 노드를 다시 시작합니다. 그렇지 않으면 etcd 클러스터 Operator에서 다음 오류가 발생할 수 있습니다.
출력 예
EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
검증
모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc -n openshift-etcd get pods -l k8s-app=etcd
출력 예
etcd-openshift-control-plane-0 5/5 Running 0 105m etcd-openshift-control-plane-1 5/5 Running 0 107m etcd-openshift-control-plane-2 5/5 Running 0 103m
이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
- 1
forceRedeploymentReason
값은 고유해야하므로 타임 스탬프가 추가됩니다.
정확히 세 개의 etcd 멤버가 있는지 확인하려면 실행중인 etcd 컨테이너에 연결하여 영향을 받는 노드에 없는 pod 이름을 전달합니다. 클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
멤버 목록을 확인합니다.
sh-4.2# etcdctl member list -w table
출력 예
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+ | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 | false | | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 | false | | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 | false | +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
참고이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.
다음 명령을 실행하여 모든 etcd 멤버가 정상인지 확인합니다.
# etcdctl endpoint health --cluster
출력 예
https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms
다음 명령을 실행하여 모든 노드가 최신 버전인지 확인합니다.
$ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
AllNodesAtLatestRevision
5.2.5. 추가 리소스
5.3. 재해 복구
5.3.1. 재해 복구 정보
재해 복구 문서에서는 관리자에게 OpenShift Container Platform 클러스터에서 발생할 수있는 여러 재해 상황을 복구하는 방법에 대한 정보를 제공합니다. 관리자는 클러스터를 작동 상태로 복원하려면 다음 절차 중 하나 이상을 수행해야합니다.
재해 복구를 수행하려면 하나 이상의 정상 컨트롤 플레인 호스트가 있어야 합니다.
- 이전 클러스터 상태로 복원
클러스터를 이전 상태로 복원하려는 경우 (예: 관리자가 일부 주요 정보를 삭제한 경우) 이 솔루션을 사용할 수 있습니다. 이에는 대부분의 컨트롤 플레인 호스트가 손실되고 etcd 쿼럼이 손실되고 클러스터가 오프라인인 상태에서도 사용할 수 있습니다. etcd 백업을 수행한 경우 이 절차에 따라 클러스터를 이전 상태로 복원할 수 있습니다.
해당하는 경우 만료된 컨트롤 플레인 인증서에서 복구해야 할 수도 있습니다.
주의이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이 절차는 마지막 수단으로만 사용해야 합니다.
복원을 수행하기 전에 클러스터에 미치는 영향에 대한 자세한 내용은 클러스터 상태 복원을 참조하십시오.
참고대다수의 마스터를 계속 사용할 수 있고 etcd 쿼럼이 있는 경우 절차에 따라 비정상적인 단일 etcd 멤버를 교체 합니다.
- 만료된 컨트롤 플레인 인증서 복구
- 컨트롤 플레인 인증서가 만료된 경우 이 솔루션을 사용할 수 있습니다. 예를 들어, 설치 후 24 시간 내에 발생하는 첫 번째 인증서 교체 전에 클러스터를 종료하면 인증서가 교체되지 않고 만료됩니다. 다음 단계에 따라 만료된 컨트롤 플레인 인증서를 복구할 수 있습니다.
5.3.2. 이전 클러스터 상태로 복원
클러스터를 이전 상태로 복원하려면 스냅샷을 생성하여 etcd
데이터를 백업해야 합니다. 이 스냅샷을 사용하여 클러스터 상태를 복구합니다. 자세한 내용은 " etcd 데이터 백업"을 참조하십시오.
5.3.2.1. 클러스터 상태 복원 정보
etcd 백업을 사용하여 클러스터를 이전 상태로 복원할 수 있습니다. 이를 사용하여 다음과 같은 상황에서 복구할 수 있습니다.
- 클러스터에서 대부분의 컨트롤 플레인 호스트가 손실되었습니다(쿼럼 손실).
- 관리자가 중요한 것을 삭제했으며 클러스터를 복구하려면 복원해야 합니다.
이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이는 마지막 수단으로만 사용해야 합니다.
Kubernetes API 서버를 사용하여 데이터를 검색할 수 있는 경우 etcd를 사용할 수 있으며 etcd 백업을 사용하여 복원할 수 없습니다.
etcd를 복원하려면 클러스터를 효율적으로 복원하는 데 시간이 걸리며 모든 클라이언트가 충돌하는 병렬 기록이 발생합니다. 이는 kubelets, Kubernetes 컨트롤러 관리자, SDN 컨트롤러 및 영구 볼륨 컨트롤러와 같은 구성 요소 모니터링 동작에 영향을 줄 수 있습니다.
이로 인해 etcd의 콘텐츠가 디스크의 실제 콘텐츠와 일치하지 않을 때 Operator가 문제가 발생하여 디스크의 파일이 etcd의 콘텐츠와 충돌할 때 Kubernetes API 서버, Kubernetes 컨트롤러 관리자, Kubernetes 스케줄러 및 etcd의 Operator가 중단될 수 있습니다. 여기에는 문제를 해결하기 위해 수동 작업이 필요할 수 있습니다.
극단적인 경우 클러스터에서 영구 볼륨 추적을 손실하고, 더 이상 존재하지 않는 중요한 워크로드를 삭제하고, 시스템을 다시 이미지화하고, 만료된 인증서로 CA 번들을 다시 작성할 수 있습니다.
5.3.2.2. 이전 클러스터 상태로 복원
저장된 etcd 백업을 사용하여 이전 클러스터 상태를 복원하거나 대부분의 컨트롤 플레인 호스트가 손실된 클러스터를 복원할 수 있습니다.
클러스터에서 컨트롤 플레인 머신 세트를 사용하는 경우 보다 간단한 etcd 복구 절차는 "컨트롤 플레인 머신 세트 문제 해결"을 참조하십시오.
클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 합니다. 예를 들어 OpenShift Container Platform 4.7.2 클러스터는 4.7.2에서 가져온 etcd 백업을 사용해야 합니다.
사전 요구 사항
-
설치 중에 사용된 인증서 기반
kubeconfig
파일을 통해cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있습니다. - 복구 호스트로 사용할 정상적인 컨트롤 플레인 호스트가 있어야 합니다.
- 컨트롤 플레인 호스트에 대한 SSH 액세스.
-
동일한 백업에서 가져온 etcd 스냅샷과 정적 pod 리소스가 모두 포함된 백업 디렉토리입니다. 디렉토리의 파일 이름은
snapshot_<datetimestamp>.db
및static_kuberesources_<datetimestamp>.tar.gz
형식이어야합니다.
복구되지 않은 컨트롤 플레인 노드의 경우 SSH 연결을 설정하거나 정적 Pod를 중지할 필요가 없습니다. 복구되지 않은 다른 컨트롤 플레인 머신을 하나씩 삭제하고 다시 생성할 수 있습니다.
절차
- 복구 호스트로 사용할 컨트롤 플레인 호스트를 선택합니다. 이는 복구 작업을 실행할 호스트입니다.
복구 호스트를 포함하여 각 컨트롤 플레인 노드에 SSH 연결을 설정합니다.
복구 프로세스가 시작된 후에는 Kubernetes API 서버에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 다른 터미널에서 각 컨트롤 플레인 호스트에 대한 SSH 연결을 설정하는 것이 좋습니다.
중요이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.
etcd 백업 디렉토리를 복구 컨트롤 플레인 호스트에 복사합니다.
이 단계에서는 etcd 스냅샷 및 정적 pod의 리소스가 포함된
backup
디렉터리를 복구 컨트롤 플레인 호스트의/home/core/
디렉터리에 복사하는 것을 전제로하고 있습니다.다른 컨트롤 플레인 노드에서 정적 Pod를 중지합니다.
참고복구 호스트에서 정적 Pod를 중지할 필요가 없습니다.
- 복구 호스트가 아닌 컨트롤 플레인 호스트에 액세스합니다.
kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.
$ sudo mv -v /etc/kubernetes/manifests/etcd-pod.yaml /tmp
etcd pod가 중지되었는지 확인합니다.
$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.
kubelet 매니페스트 디렉토리에서 기존 Kubernetes API 서버 pod 파일을 이동합니다.
$ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
Kubernetes API 서버 pod가 중지되었는지 확인합니다.
$ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.
etcd 데이터 디렉토리를 다른 위치로 이동합니다.
$ sudo mv -v /var/lib/etcd/ /tmp
/etc/kubernetes/manifests/keepalived.yaml
파일이 있고 노드가 삭제되면 다음 단계를 따르십시오.kubelet 매니페스트 디렉토리에서
/etc/kubernetes/manifests/keepalived.yaml
파일을 이동합니다.$ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp
keepalived
데몬에서 관리하는 컨테이너가 중지되었는지 확인합니다.$ sudo crictl ps --name keepalived
이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.
컨트롤 플레인에 VIP가 할당되어 있는지 확인합니다.
$ ip -o address | egrep '<api_vip>|<ingress_vip>'
보고된 각 VIP에 대해 다음 명령을 실행하여 제거합니다.
$ sudo ip address del <reported_vip> dev <reported_vip_device>
- 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
- 복구 컨트롤 플레인 호스트에 액세스합니다.
keepalived
데몬이 사용 중인 경우 복구 컨트롤 플레인 노드가 VIP를 소유하고 있는지 확인합니다.$ ip -o address | grep <api_vip>
VIP 주소가 있는 경우 출력에 강조 표시됩니다. VIP가 잘못 설정되거나 구성되지 않은 경우 이 명령은 빈 문자열을 반환합니다.
클러스터 전체의 프록시가 활성화되어 있는 경우
NO_PROXY,
HTTP_PROXY
및https_proxy
환경 변수를 내보내고 있는지 확인합니다.작은 정보oc get proxy cluster -o yaml
의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다.httpProxy
,httpsProxy
및noProxy
필드에 값이 설정되어 있으면 프록시가 사용됩니다.복구 컨트롤 플레인 호스트에서 복원 스크립트를 실행하고 etcd 백업 디렉터리에 경로를 전달합니다.
$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/backup
스크립트 출력 예
...stopping kube-scheduler-pod.yaml ...stopping kube-controller-manager-pod.yaml ...stopping etcd-pod.yaml ...stopping kube-apiserver-pod.yaml Waiting for container etcd to stop .complete Waiting for container etcdctl to stop .............................complete Waiting for container etcd-metrics to stop complete Waiting for container kube-controller-manager to stop complete Waiting for container kube-apiserver to stop ..........................................................................................complete Waiting for container kube-scheduler to stop complete Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup starting restore-etcd static pod starting kube-apiserver-pod.yaml static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml starting kube-controller-manager-pod.yaml static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml starting kube-scheduler-pod.yaml static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml
참고마지막 etcd 백업 후 노드 인증서가 업데이트된 경우 복원 프로세스에서 노드가
NotReady
상태가 될 수 있습니다.노드가
Ready
상태인지 확인합니다.다음 명령을 실행합니다.
$ oc get nodes -w
샘플 출력
NAME STATUS ROLES AGE VERSION host-172-25-75-28 Ready master 3d20h v1.26.0 host-172-25-75-38 Ready infra,worker 3d20h v1.26.0 host-172-25-75-40 Ready master 3d20h v1.26.0 host-172-25-75-65 Ready master 3d20h v1.26.0 host-172-25-75-74 Ready infra,worker 3d20h v1.26.0 host-172-25-75-79 Ready worker 3d20h v1.26.0 host-172-25-75-86 Ready worker 3d20h v1.26.0 host-172-25-75-98 Ready infra,worker 3d20h v1.26.0
모든 노드에서 상태를 보고하는 데 몇 분이 걸릴 수 있습니다.
노드가
NotReady
상태에 있는 경우 노드에 로그인하고 각 노드의/var/lib/kubelet/pki
디렉터리에서 모든 PEM 파일을 제거합니다. 노드에 SSH를 실행하거나 웹 콘솔에서 터미널 창을 사용할 수 있습니다.$ ssh -i <ssh-key-path> core@<master-hostname>
샘플
pki
디렉터리sh-4.4# pwd /var/lib/kubelet/pki sh-4.4# ls kubelet-client-2022-04-28-11-24-09.pem kubelet-server-2022-04-28-11-24-15.pem kubelet-client-current.pem kubelet-server-current.pem
모든 컨트롤 플레인 호스트에서 kubelet 서비스를 다시 시작합니다.
복구 호스트에서 다음 명령을 실행합니다.
$ sudo systemctl restart kubelet.service
- 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
보류 중인 CSR을 승인합니다.
참고3개의 스케줄링 가능한 컨트롤 플레인 노드로 구성된 단일 노드 클러스터 또는 클러스터와 같이 작업자 노드가 없는 클러스터에는 승인할 보류 중인 CSR이 없습니다. 이 단계에서 나열된 모든 명령을 건너뛸 수 있습니다.
현재 CSR의 목록을 가져옵니다.
$ oc get csr
출력 예
NAME AGE SIGNERNAME REQUESTOR CONDITION csr-2s94x 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending 1 csr-4bd6t 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending 2 csr-4hl85 13m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending 3 csr-zhhhp 3m8s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending 4 ...
CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.
$ oc describe csr <csr_name> 1
- 1
<csr_name>
은 현재 CSR 목록에 있는 CSR의 이름입니다.
각각의 유효한
node-bootstrapper
CSR을 승인합니다.$ oc adm certificate approve <csr_name>
사용자 프로비저닝 설치의 경우 각 유효한 kubelet 서비스 CSR을 승인합니다.
$ oc adm certificate approve <csr_name>
단일 멤버 컨트롤 플레인이 제대로 시작되었는지 확인합니다.
복구 호스트에서 etcd 컨테이너가 실행 중인지 확인합니다.
$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
출력 예
3ad41b7908e32 36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009 About a minute ago Running etcd 0 7c05f8af362f0
복구 호스트에서 etcd pod가 실행 중인지 확인합니다.
$ oc -n openshift-etcd get pods -l k8s-app=etcd
출력 예
NAME READY STATUS RESTARTS AGE etcd-ip-10-0-143-125.ec2.internal 1/1 Running 1 2m47s
Pending
상태에 있거나 출력에 여러 실행중인 etcd pod가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.
OVNKubernetes
네트워크 플러그인을 사용하는 경우 복구 컨트롤 플레인 호스트가 아닌 컨트롤 플레인 호스트와 연결된 노드 오브젝트를 삭제합니다.$ oc delete node <non-recovery-controlplane-host-1> <non-recovery-controlplane-host-2>
CNO(Cluster Network Operator)가 OVN-Kubernetes 컨트롤 플레인을 재배포하고 더 이상 복구되지 않은 컨트롤러 IP 주소를 참조하지 않는지 확인합니다. 이 결과를 확인하려면 다음 명령의 출력을 정기적으로 확인하십시오. 다음 단계의 모든 호스트에서 OVN(Open Virtual Network) Kubernetes Pod를 다시 시작하기 전에 빈 결과를 반환할 때까지 기다립니다.
$ oc -n openshift-ovn-kubernetes get ds/ovnkube-master -o yaml | grep -E '<non-recovery_controller_ip_1>|<non-recovery_controller_ip_2>'
참고OVN-Kubernetes 컨트롤 플레인을 재배포하고 이전 명령을 사용하여 빈 출력을 반환하는 데 최소 5-10 분이 걸릴 수 있습니다.
OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 모든 호스트에서 OVN(Open Virtual Network) Kubernetes Pod를 다시 시작합니다.
참고승인 Webhook 확인 및 변경은 Pod를 거부할 수 있습니다.
failurePolicy
를Fail
로 설정하여 추가 Webhook를 추가하는 경우 Pod를 거부하고 복원 프로세스가 실패할 수 있습니다. 클러스터 상태를 복원하는 동안 Webhook를 저장하고 삭제하여 이 문제를 방지할 수 있습니다. 클러스터 상태가 성공적으로 복원되면 Webhook를 다시 활성화할 수 있습니다.또는 클러스터 상태를 복원하는 동안
failurePolicy
를Ignore
로 일시적으로 설정할 수 있습니다. 클러스터 상태가 성공적으로 복원된 후failurePolicy
를Fail
로 설정할 수 있습니다.northbound 데이터베이스(nbdb) 및 southbound 데이터베이스(sbdb)를 제거합니다. SSH(Secure Shell)를 사용하여 복구 호스트와 나머지 컨트롤 플레인 노드에 액세스하고 다음 명령을 실행합니다.
$ sudo rm -f /var/lib/ovn/etc/*.db
다음 명령을 실행하여 모든 OVN-Kubernetes 컨트롤 플레인 Pod를 삭제합니다.
$ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes
다음 명령을 실행하여 OVN-Kubernetes 컨트롤 플레인 Pod가 다시 배포되고
Running
상태에 있는지 확인합니다.$ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes
출력 예
NAME READY STATUS RESTARTS AGE ovnkube-master-nb24h 4/4 Running 0 48s
다음 명령을 실행하여 모든
ovnkube-node
Pod를 삭제합니다.$ oc get pods -n openshift-ovn-kubernetes -o name | grep ovnkube-node | while read p ; do oc delete $p -n openshift-ovn-kubernetes ; done
다음 명령을 실행하여 OVN Pod의 상태를 확인합니다.
$ oc get po -n openshift-ovn-kubernetes
OVN Pod가
종료
상태에 있는 경우 다음 명령을 실행하여 해당 OVN Pod를 실행 중인 노드를 삭제합니다. <node
>를 삭제 중인 노드의 이름으로 바꿉니다.$ oc delete node <node>
다음 명령을 실행하여 SSH를 사용하여
종료
상태의 OVN pod 노드에 로그인합니다.$ ssh -i <ssh-key-path> core@<node>
다음 명령을 실행하여
/var/lib/kubelet/pki
디렉토리에서 모든 PEM 파일을 이동합니다.$ sudo mv /var/lib/kubelet/pki/* /tmp
다음 명령을 실행하여 kubelet 서비스를 다시 시작합니다.
$ sudo systemctl restart kubelet.service
다음 명령을 실행하여 복구 etcd 머신으로 돌아갑니다.
$ oc get csr
출력 예
NAME AGE SIGNERNAME REQUESTOR CONDITION csr-<uuid> 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending
다음 명령을 실행하여 새 CSR을 모두 승인하고
csr-<uuid>
;를 CSR 이름으로 교체하십시오.oc adm certificate approve csr-<uuid>
다음 명령을 실행하여 노드가 다시 있는지 확인합니다.
$ oc get nodes
다음 명령을 실행하여 모든
ovnkube-node
Pod가 다시 배포되고Running
상태에 있는지 확인합니다.$ oc get pods -n openshift-ovn-kubernetes | grep ovnkube-node
복구되지 않는 다른 컨트롤 플레인 시스템을 삭제하고 하나씩 다시 생성합니다. 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd가 자동으로 확장됩니다.
사용자가 프로비저닝한 베어 메탈 설치를 사용하는 경우 원래 사용했던 것과 동일한 방법을 사용하여 컨트롤 플레인 시스템을 다시 생성할 수 있습니다. 자세한 내용은 " 베어 메탈에 사용자 프로비저닝 클러스터 설치"를 참조하십시오.
주의복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.
설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오.
주의복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.
설치 관리자 프로비저닝 인프라에 베어 메탈 설치의 경우 컨트롤 플레인 머신이 다시 생성되지 않습니다. 자세한 내용은 " 베어 메탈 컨트롤 플레인 노드 교체"를 참조하십시오.
손실된 컨트롤 플레인 호스트 중 하나에 대한 머신을 가져옵니다.
cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다.
$ oc get machines -n openshift-machine-api -o wide
출력 예:
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-0 Running m4.xlarge us-east-1 us-east-1a 3h37m ip-10-0-131-183.ec2.internal aws:///us-east-1a/i-0ec2782f8287dfb7e stopped 1 clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-143-125.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-154-194.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
- 1
- 이는 손실된 컨트롤 플레인 호스트인
ip-10-0-131-183.ec2.internal
의 컨트롤 플레인 시스템입니다.
다음을 실행하여 손실된 컨트롤 플레인 호스트의 시스템을 삭제합니다.
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
- 1
- 손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.
손실된 컨트롤 플레인 호스트의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.
다음을 실행하여 새 시스템이 생성되었는지 확인합니다.
$ oc get machines -n openshift-machine-api -o wide
출력 예:
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-143-125.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-154-194.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-master-3 Provisioning m4.xlarge us-east-1 us-east-1a 85s ip-10-0-173-171.ec2.internal aws:///us-east-1a/i-015b0888fe17bc2c8 running 1 clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
- 1
- 새 시스템
clustername-8qw5l-master-3
이 생성되고 단계가Provisioning
에서Running
으로 변경된 후 준비됩니다.
새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.
- 복구 호스트가 아닌 손실된 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.
다음 명령을 입력하여 쿼럼 보호기를 끄십시오.
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.
복구 호스트 내의 별도의 터미널 창에서 다음 명령을 실행하여 복구
kubeconfig
파일을 내보냅니다.$ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
etcd를 강제로 재배포합니다.
복구
kubeconfig
파일을 내보낸 동일한 터미널 창에서 다음 명령을 실행합니다.$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
- 1
forceRedeploymentReason
값은 고유해야하므로 타임 스탬프가 추가됩니다.
etcd 클러스터 Operator가 재배포를 실행하면 기존 노드가 초기 부트 스트랩 확장과 유사한 새 pod를 사용하기 시작합니다.
다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
다음 명령을 입력하여
unsupportedConfigOverrides
섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.$ oc get etcd/cluster -oyaml
모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
etcd의
NodeInstallerProgressing
상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에AllNodesAtLatestRevision
이 표시됩니다.AllNodesAtLatestRevision 3 nodes are at revision 7 1
- 1
- 이 예에서 최신 버전 번호는
7
입니다.
출력에
2 nodes are at revision 6; 1 nodes are at revision 7
와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.etcd를 재배포한 후 컨트롤 플레인에 새 롤아웃을 강제 실행합니다. kubelet이 내부 로드 밸런서를 사용하여 API 서버에 연결되어 있으므로 Kubernetes API 서버는 다른 노드에 다시 설치됩니다.
cluster-admin
사용자로 클러스터에 액세스할 수있는 터미널에서 다음 명령을 실행합니다.Kubernetes API 서버에 대해 새 롤아웃을 강제 적용합니다.
$ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
NodeInstallerProgressing
상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에AllNodesAtLatestRevision
이 표시됩니다.AllNodesAtLatestRevision 3 nodes are at revision 7 1
- 1
- 이 예에서 최신 버전 번호는
7
입니다.
출력에
2 nodes are at revision 6; 1 nodes are at revision 7
와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.Kubernetes 컨트롤러 관리자에 대해 새 롤아웃을 강제 적용합니다.
$ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
$ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
NodeInstallerProgressing
상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에AllNodesAtLatestRevision
이 표시됩니다.AllNodesAtLatestRevision 3 nodes are at revision 7 1
- 1
- 이 예에서 최신 버전 번호는
7
입니다.
출력에
2 nodes are at revision 6; 1 nodes are at revision 7
와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.Kubernetes 스케줄러에 대해 새 롤아웃을 강제 적용합니다.
$ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
$ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
NodeInstallerProgressing
상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에AllNodesAtLatestRevision
이 표시됩니다.AllNodesAtLatestRevision 3 nodes are at revision 7 1
- 1
- 이 예에서 최신 버전 번호는
7
입니다.
출력에
2 nodes are at revision 6; 1 nodes are at revision 7
와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.
모든 컨트롤 플레인 호스트가 클러스터를 시작하여 참여하고 있는지 확인합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc -n openshift-etcd get pods -l k8s-app=etcd
출력 예
etcd-ip-10-0-143-125.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-154-194.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-173-171.ec2.internal 2/2 Running 0 9h
복구 절차에 따라 모든 워크로드가 일반 작업으로 돌아가도록 하려면 Kubernetes API 정보를 저장하는 각 Pod를 다시 시작합니다. 여기에는 라우터, Operator 및 타사 구성 요소와 같은 OpenShift Container Platform 구성 요소가 포함됩니다.
이전 절차 단계를 완료하면 모든 서비스가 복원된 상태로 돌아올 때까지 몇 분 정도 기다려야 할 수 있습니다. 예를 들어, OAuth 서버 pod가 다시 시작될 때까지 oc login
을 사용한 인증이 즉시 작동하지 않을 수 있습니다.
즉각적인 인증을 위해 system:admin
kubeconfig
파일을 사용하는 것이 좋습니다. 이 방법은 OAuth 토큰에 대해 SSL/TLS 클라이언트 인증서에 대한 인증을 기반으로 합니다. 다음 명령을 실행하여 이 파일로 인증할 수 있습니다.
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
다음 명령을 실행하여 인증된 사용자 이름을 표시합니다.
$ oc whoami
5.3.2.3. etcd 백업에서 수동으로 클러스터 복원
"이전 클러스터 상태로 복원" 섹션에 설명된 복원 절차:
-
UPI 설치 시 컨트롤 플레인 노드에 대한
Machine
또는ControlPlaneMachineset
을 생성하지 않으므로 UPI 설치 방법을 사용하여 설치된 클러스터에 대한 2개의 컨트롤 플레인 노드를 완전히 다시 생성해야 합니다. - 새 단일 멤버 etcd 클러스터를 시작한 /usr/local/bin/cluster-restore.sh 스크립트를 사용하여 세 멤버로 확장합니다.
이와 반대로 이 절차는 다음과 같습니다.
- 컨트롤 플레인 노드를 다시 생성할 필요가 없습니다.
- 3개의 멤버 etcd 클러스터를 직접 시작합니다.
클러스터에서 컨트롤 플레인에 MachineSet
을 사용하는 경우 etcd 복구 절차를 위해 "Restoring to a previous cluster state"를 사용하는 것이 좋습니다.
클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 합니다. 예를 들어 OpenShift Container Platform 4.7.2 클러스터는 4.7.2에서 가져온 etcd 백업을 사용해야 합니다.
사전 요구 사항
-
cluster-admin
역할(예:kubeadmin
사용자)을 사용하여 사용자로 클러스터에 액세스합니다. -
호스트 사용자를 사용하여 모든 컨트롤 플레인 호스트에 대한 SSH 액세스
(
예: 기본코어
호스트 사용자) -
이전 etcd 스냅샷과 동일한 백업의 정적 pod 리소스가 모두 포함된 백업 디렉터리입니다. 디렉토리의 파일 이름은
snapshot_<datetimestamp>.db
및static_kuberesources_<datetimestamp>.tar.gz
형식이어야합니다.
절차
SSH를 사용하여 각 컨트롤 플레인 노드에 연결합니다.
복구 프로세스가 시작된 후에는 Kubernetes API 서버에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 별도의 터미널에서 액세스하려는 각 컨트롤 플레인 호스트에 SSH 연결을 사용하는 것이 좋습니다.
중요이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.
etcd 백업 디렉터리를 각 컨트롤 플레인 호스트에 복사합니다.
이 절차에서는 etcd 스냅샷과 정적 pod의 리소스가 포함된
백업
디렉터리를 각 컨트롤 플레인 호스트의/home/core/assets
디렉터리에 복사하는 것을 전제로 합니다. 아직 존재하지 않는 경우 이러한assets
폴더를 생성해야 할 수도 있습니다.모든 컨트롤 플레인 노드에서 정적 Pod를 중지합니다. 한 번에 하나의 호스트입니다.
kubelet 매니페스트 디렉터리에서 기존 Kubernetes API Server 정적 Pod를 표시합니다.
$ mkdir -p /root/manifests-backup $ mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /root/manifests-backup/
명령을 사용하여 Kubernetes API 서버 컨테이너가 중지되었는지 확인합니다.
$ crictl ps | grep kube-apiserver | grep -E -v "operator|guard"
이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.
Kubernetes API Server 컨테이너가 계속 실행 중인 경우 다음 명령을 사용하여 수동으로 종료합니다.
$ crictl stop <container_id>
kube-controller-manager-pod.yaml
,kube-scheduler-pod.yaml
및 마지막으로etcd-pod.yaml
에 대해 동일한 단계를 반복합니다.다음 명령을 사용하여
kube-controller-manager
Pod를 중지합니다.$ mv /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /root/manifests-backup/
다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다.
$ crictl ps | grep kube-controller-manager | grep -E -v "operator|guard"
다음 명령을 사용하여
kube-scheduler
Pod를 중지합니다.$ mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /root/manifests-backup/
다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다.
$ crictl ps | grep kube-scheduler | grep -E -v "operator|guard"
다음 명령을 사용하여
etcd
pod를 중지합니다.$ mv /etc/kubernetes/manifests/etcd-pod.yaml /root/manifests-backup/
다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다.
$ crictl ps | grep etcd | grep -E -v "operator|guard"
각 컨트롤 플레인 호스트에서 현재
etcd
데이터를백업
폴더로 이동하여 저장합니다.$ mkdir /home/core/assets/old-member-data $ mv /var/lib/etcd/member /home/core/assets/old-member-data
이 데이터는
etcd
백업 복원이 작동하지 않고etcd
클러스터를 현재 상태로 복원해야 하는 경우 유용합니다.각 컨트롤 플레인 호스트에 대해 올바른 etcd 매개변수를 찾습니다.
<
ETCD_NAME
>의 값은 각 컨트롤 플레인 호스트에 대해 고유하며 매니페스트/etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml
파일의ETCD_NAME
변수와 동일합니다. 다음 명령을 사용하여 찾을 수 있습니다.RESTORE_ETCD_POD_YAML="/etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml" cat $RESTORE_ETCD_POD_YAML | \ grep -A 1 $(cat $RESTORE_ETCD_POD_YAML | grep 'export ETCD_NAME' | grep -Eo 'NODE_.+_ETCD_NAME') | \ grep -Po '(?<=value: ").+(?=")'
<
UUID>
;의 값은 명령을 사용하여 컨트롤 플레인 호스트에서 생성할 수 있습니다.$ uuidgen
참고<
UUID>
의 값은 한 번만 생성되어야 합니다. 하나의 컨트롤 플레인 호스트에서UUID
를 생성한 후 다른 컨트롤 플레인 호스트에서 다시 생성하지 마십시오. 모든 컨트롤 플레인 호스트의 다음 단계에서 동일한UUID
를 사용합니다.ETCD_NODE_PEER_URL
의 값은 다음 예와 같이 설정해야 합니다.https://<IP_CURRENT_HOST>:2380
올바른 IP는 특정 컨트롤 플레인 호스트의 <
ETCD_NAME
>에서 명령을 사용하여 찾을 수 있습니다.$ echo <ETCD_NAME> | \ sed -E 's/[.-]/_/g' | \ xargs -I {} grep {} /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd.env | \ grep "IP" | grep -Po '(?<=").+(?=")'
<
ETCD_INITIAL_CLUSTER
>의 값은 다음과 같이 설정해야 합니다. 여기서 <ETCD_NAME_n
>은 각 컨트롤 플레인 호스트의 <ETCD_NAME
>입니다.참고사용되는 포트는 2380이어야 하며 2379가 아닙니다. 포트 2379는 etcd 데이터베이스 관리에 사용되며 컨테이너의 etcd start 명령에 직접 구성됩니다.
출력 예
<ETCD_NAME_0>=<ETCD_NODE_PEER_URL_0>,<ETCD_NAME_1>=<ETCD_NODE_PEER_URL_1>,<ETCD_NAME_2>=<ETCD_NODE_PEER_URL_2> 1
- 1
- 각 컨트롤 플레인 호스트의
ETCD_NODE_PEER_URL
값을 지정합니다.
&
lt;ETCD_INITIAL_CLUSTER&
gt; 값은 모든 컨트롤 플레인 호스트에서 동일하게 유지됩니다. 모든 컨트롤 플레인 호스트의 다음 단계에서 동일한 값이 필요합니다.
백업에서 etcd 데이터베이스를 다시 생성합니다.
이러한 작업은 각 컨트롤 플레인 호스트에서 실행해야 합니다.
다음 명령을 사용하여
etcd
백업을/var/lib/etcd
디렉토리에 복사합니다.$ cp /home/core/assets/backup/<snapshot_yyyy-mm-dd_hhmmss>.db /var/lib/etcd
계속하기 전에 올바른
etcdctl
이미지를 식별합니다. 다음 명령을 사용하여 Pod 매니페스트 백업에서 이미지를 검색합니다.$ jq -r '.spec.containers[]|select(.name=="etcdctl")|.image' /root/manifests-backup/etcd-pod.yaml
$ podman run --rm -it --entrypoint="/bin/bash" -v /var/lib/etcd:/var/lib/etcd:z <image-hash>
etcdctl
도구 버전이 백업이 생성된etcd
서버의 버전인지 확인합니다.$ etcdctl version
현재 호스트에 올바른 값을 사용하여
etcd
데이터베이스를 다시 생성하려면 다음 명령을 실행합니다.$ ETCDCTL_API=3 /usr/bin/etcdctl snapshot restore /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db \ --name "<ETCD_NAME>" \ --initial-cluster="<ETCD_INITIAL_CLUSTER>" \ --initial-cluster-token "openshift-etcd-<UUID>" \ --initial-advertise-peer-urls "<ETCD_NODE_PEER_URL>" \ --data-dir="/var/lib/etcd/restore-<UUID>" \ --skip-hash-check=true
참고etcd
데이터베이스를 다시 생성할 때는 따옴표가 필요합니다.
추가된 멤버
로그에 출력된 값을 기록합니다. 예를 들면 다음과 같습니다.출력 예
2022-06-28T19:52:43Z info membership/cluster.go:421 added member {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "56cd73b614699e7", "added-peer-peer-urls": ["https://10.0.91.5:2380"], "added-peer-is-learner": false} 2022-06-28T19:52:43Z info membership/cluster.go:421 added member {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "1f63d01b31bb9a9e", "added-peer-peer-urls": ["https://10.0.90.221:2380"], "added-peer-is-learner": false} 2022-06-28T19:52:43Z info membership/cluster.go:421 added member {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "fdc2725b3b70127c", "added-peer-peer-urls": ["https://10.0.94.214:2380"], "added-peer-is-learner": false}
- 컨테이너를 종료합니다.
-
다른 컨트롤 플레인 호스트에서 이러한 단계를 반복하여
추가된 멤버
로그에 출력된 값이 모든 컨트롤 플레인 호스트에 대해 동일한지 확인합니다.
재생성된
etcd
데이터베이스를 기본 위치로 이동합니다.이러한 작업은 각 컨트롤 플레인 호스트에서 실행해야 합니다.
재현된 데이터베이스(이전
etcdctl snapshot restore
명령으로 생성된멤버
폴더)를 기본 etcd 위치/var/lib/etcd
:로 이동합니다.$ mv /var/lib/etcd/restore-<UUID>/member /var/lib/etcd
/var/lib/etcd
/member 폴더에서/var/lib/etcd/member
폴더의 SELinux 컨텍스트를 복원합니다.$ restorecon -vR /var/lib/etcd/
남은 파일과 디렉터리를 제거합니다.
$ rm -rf /var/lib/etcd/restore-<UUID>
$ rm /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db
중요완료되면
/var/lib/etcd
디렉토리에 폴더멤버
만 포함되어야 합니다.- 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
etcd 클러스터를 다시 시작하십시오.
- 다음 단계는 모든 컨트롤 플레인 호스트에서 실행해야 하지만 한 번에 하나의 호스트 를 실행해야 합니다.
kubelet이 관련 컨테이너를 시작하도록 하려면
etcd
정적 Pod 매니페스트를 kubelet 매니페스트 디렉터리로 다시 이동합니다.$ mv /tmp/etcd-pod.yaml /etc/kubernetes/manifests
모든
etcd
컨테이너가 시작되었는지 확인합니다.$ crictl ps | grep etcd | grep -v operator
출력 예
38c814767ad983 f79db5a8799fd2c08960ad9ee22f784b9fbe23babe008e8a3bf68323f004c840 28 seconds ago Running etcd-health-monitor 2 fe4b9c3d6483c e1646b15207c6 9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06 About a minute ago Running etcd-metrics 0 fe4b9c3d6483c 08ba29b1f58a7 9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06 About a minute ago Running etcd 0 fe4b9c3d6483c 2ddc9eda16f53 9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06 About a minute ago Running etcdctl
이 명령의 출력이 비어 있으면 몇 분 기다렸다가 다시 확인하십시오.
etcd
클러스터의 상태를 확인합니다.다음 명령을 사용하여 컨트롤 플레인 호스트에서
etcd
클러스터의 상태를 확인합니다.$ crictl exec -it $(crictl ps | grep etcdctl | awk '{print $1}') etcdctl endpoint status -w table
출력 예
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS | +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | https://10.0.89.133:2379 | 682e4a83a0cec6c0 | 3.5.0 | 67 MB | true | false | 2 | 218 | 218 | | | https://10.0.92.74:2379 | 450bcf6999538512 | 3.5.0 | 67 MB | false | false | 2 | 218 | 218 | | | https://10.0.93.129:2379 | 358efa9c1d91c3d6 | 3.5.0 | 67 MB | false | false | 2 | 218 | 218 | | +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
다른 정적 pod를 다시 시작합니다.
한 번에 하나의 호스트이지만 모든 컨트롤 플레인 호스트에서 다음 단계를 실행해야 합니다.
Kubernetes API Server 정적 Pod 매니페스트를 kubelet 매니페스트 디렉터리로 다시 이동하여 kubelet이 명령을 사용하여 관련 컨테이너를 시작합니다.
$ mv /root/manifests-backup/kube-apiserver-pod.yaml /etc/kubernetes/manifests
모든 Kubernetes API Server 컨테이너가 시작되었는지 확인합니다.
$ crictl ps | grep kube-apiserver | grep -v operator
참고다음 명령의 출력이 비어 있으면 몇 분 기다렸다가 다시 확인합니다.
kube-controller-manager-pod.yaml
및kube-scheduler-pod.yaml
파일에 대해 동일한 단계를 반복합니다.다음 명령을 사용하여 모든 노드에서 kubelet을 다시 시작합니다.
$ systemctl restart kubelet
다음 명령을 사용하여 나머지 컨트롤 플레인 Pod를 시작합니다.
$ mv /root/manifests-backup/kube-* /etc/kubernetes/manifests/
kube-apiserver
,kube-scheduler
및kube-controller-manager
Pod가 올바르게 시작되었는지 확인합니다.$ crictl ps | grep -E 'kube-(apiserver|scheduler|controller-manager)' | grep -v -E 'operator|guard'
다음 명령을 사용하여 OVN 데이터베이스를 지웁니다.
for NODE in $(oc get node -o name | sed 's:node/::g') do oc debug node/${NODE} -- chroot /host /bin/bash -c 'rm -f /var/lib/ovn-ic/etc/ovn*.db && systemctl restart ovs-vswitchd ovsdb-server' oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --wait oc -n openshift-ovn-kubernetes wait pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --for condition=ContainersReady --timeout=600s done
5.3.2.4. 추가 리소스
5.3.2.5. 영구 스토리지 상태 복원을 위한 문제 및 해결 방법
OpenShift Container Platform 클러스터에서 모든 형식의 영구저장장치를 사용하는 경우 일반적으로 클러스터의 상태가 etcd 외부에 저장됩니다. StatefulSet
오브젝트에서 실행 중인 Pod 또는 데이터베이스에서 실행 중인 Elasticsearch 클러스터일 수 있습니다. etcd 백업에서 복원하면 OpenShift Container Platform의 워크로드 상태도 복원됩니다. 그러나 etcd 스냅샷이 오래된 경우 상태가 유효하지 않거나 오래되었을 수 있습니다.
PV(영구 볼륨)의 내용은 etcd 스냅샷의 일부가 아닙니다. etcd 스냅샷에서 OpenShift Container Platform 클러스터를 복원할 때 중요하지 않은 워크로드가 중요한 데이터에 액세스할 수 있으며 그 반대의 경우로도 할 수 있습니다.
다음은 사용되지 않는 상태를 생성하는 몇 가지 예제 시나리오입니다.
- MySQL 데이터베이스는 PV 오브젝트에서 지원하는 pod에서 실행됩니다. etcd 스냅샷에서 OpenShift Container Platform을 복원해도 스토리지 공급자의 볼륨을 다시 가져오지 않으며 pod를 반복적으로 시작하려고 하지만 실행 중인 MySQL pod는 생성되지 않습니다. 스토리지 공급자에서 볼륨을 복원한 다음 새 볼륨을 가리키도록 PV를 편집하여 이 Pod를 수동으로 복원해야 합니다.
- Pod P1에서는 노드 X에 연결된 볼륨 A를 사용합니다. 다른 pod가 노드 Y에서 동일한 볼륨을 사용하는 동안 etcd 스냅샷을 가져오는 경우 etcd 복원이 수행되면 해당 볼륨이 여전히 Y 노드에 연결되어 있으므로 Pod P1이 제대로 시작되지 않을 수 있습니다. OpenShift Container Platform은 연결을 인식하지 못하고 자동으로 연결을 분리하지 않습니다. 이 경우 볼륨이 노드 X에 연결된 다음 Pod P1이 시작될 수 있도록 노드 Y에서 볼륨을 수동으로 분리해야 합니다.
- etcd 스냅샷을 만든 후 클라우드 공급자 또는 스토리지 공급자 인증 정보가 업데이트되었습니다. 이로 인해 해당 인증 정보를 사용하는 CSI 드라이버 또는 Operator가 작동하지 않습니다. 해당 드라이버 또는 Operator에 필요한 인증 정보를 수동으로 업데이트해야 할 수 있습니다.
etcd 스냅샷을 만든 후 OpenShift Container Platform 노드에서 장치가 제거되거나 이름이 변경됩니다. Local Storage Operator는
/dev/disk/by-id
또는/dev
디렉터리에서 관리하는 각 PV에 대한 심볼릭 링크를 생성합니다. 이 경우 로컬 PV가 더 이상 존재하지 않는 장치를 참조할 수 있습니다.이 문제를 해결하려면 관리자가 다음을 수행해야 합니다.
- 잘못된 장치가 있는 PV를 수동으로 제거합니다.
- 각 노드에서 심볼릭 링크를 제거합니다.
-
LocalVolume
또는LocalVolumeSet
오브젝트를 삭제합니다 (스토리지 → 영구 스토리지 구성 → 로컬 볼륨을 사용하는 영구 스토리지 → Local Storage Operator 리소스 삭제참조).
5.3.3. 만료된 컨트롤 플레인 인증서 복구
5.3.3.1. 만료된 컨트롤 플레인 인증서 복구
클러스터는 만료된 컨트롤 플레인 인증서에서 자동으로 복구될 수 있습니다.
그러나 kubelet 인증서를 복구하려면 대기 중인 node-bootstrapper
인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 사용자 프로비저닝 설치의 경우 보류 중인 kubelet 서비스 CSR을 승인해야 할 수도 있습니다.
보류중인 CSR을 승인하려면 다음 단계를 수행합니다.
절차
현재 CSR의 목록을 가져옵니다.
$ oc get csr
출력 예
NAME AGE SIGNERNAME REQUESTOR CONDITION csr-2s94x 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending 1 csr-4bd6t 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending csr-4hl85 13m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending 2 csr-zhhhp 3m8s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.
$ oc describe csr <csr_name> 1
- 1
<csr_name>
은 현재 CSR 목록에 있는 CSR의 이름입니다.
각각의 유효한
node-bootstrapper
CSR을 승인합니다.$ oc adm certificate approve <csr_name>
사용자 프로비저닝 설치의 경우 CSR을 제공하는 각 유효한 kubelet을 승인합니다.
$ oc adm certificate approve <csr_name>
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.