Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

백업 및 복원

OpenShift Container Platform 4.12

OpenShift Container Platform 클러스터 백업 및 복원

Red Hat OpenShift Documentation Team

초록

이 문서는 클러스터 데이터를 백업하고 다양한 재해 시나리오에서 복구하는 방법에 대해 설명합니다.

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 x가 포함되어 있으며 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(사용자 정의 리소스)을 생성하여 애플리케이션을 백업합니다. 백업 CR 생성을 참조하십시오. 다음 백업 옵션을 구성할 수 있습니다.

2장. 클러스터를 안전하게 종료
링크 복사

이 문서에서는 클러스터를 안전하게 종료하는 프로세스를 설명합니다. 유지 관리를 위해 또는 리소스 비용을 절약하기 위해 일시적으로 클러스터를 종료해야 할 수 있습니다.

2.1. 전제 조건
링크 복사

  • 클러스터를 종료하기 전에 etcd 백업을 수행합니다.

    중요

    클러스터를 다시 시작할 때 문제가 발생할 경우 클러스터를 복원 할 수 있도록 이 단계를 수행하기 전에 etcd 백업을 해 두는 것이 중요합니다.

    예를 들어 다음 조건으로 인해 재시작된 클러스터의 오작동이 발생할 수 있습니다.

    • 종료 중 etcd 데이터 손상
    • 하드웨어로 인한 노드 오류
    • 네트워크 연결 문제

    클러스터를 복구하지 못하는 경우 이전 클러스터 상태로 복원 단계를 따르십시오.

2.2. 클러스터 종료
링크 복사

나중에 클러스터를 다시 시작하기 위해 안전한 방법으로 클러스터를 종료할 수 있습니다.

참고

설치 날짜부터 1년까지 클러스터를 종료하고 정상적으로 다시 시작할 수 있습니다. 설치 날짜로부터 1년 후에는 클러스터 인증서가 만료됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • etcd 백업이 수행되었습니다.

프로세스

  1. 연장된 기간 동안 클러스터를 종료하는 경우 인증서 만료 날짜를 확인하고 다음 명령을 실행합니다. 

    $ oc -n openshift-kube-apiserver-operator get secret kube-apiserver-to-kubelet-signer -o jsonpath='{.metadata.annotations.auth\.openshift\.io/certificate-not-after}'
    Copy to Clipboard Toggle word wrap

    출력 예

    2022-08-05T14:37:50Zuser@user:~ $
    1
    Copy to Clipboard Toggle word wrap

    1
    클러스터를 정상적으로 다시 시작할 수 있도록 지정된 날짜 또는 그 이전에 클러스터를 다시 시작하도록 계획합니다. 클러스터가 재시작되면 프로세스에서 kubelet 인증서를 복구하기 위해 보류 중인 인증서 서명 요청(CSR)을 수동으로 승인해야 할 수 있습니다.

  2. 클러스터의 모든 노드를 예약 불가로 표시합니다. 클라우드 공급자의 웹 콘솔에서 이 작업을 수행하거나 다음 반복문을 실행하여 수행할 수 있습니다. 

    $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm cordon ${node} ; done
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  3. 다음 방법을 사용하여 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 ; done
    Copy to Clipboard Toggle word wrap

  4. 클러스터의 모든 노드를 종료합니다. 클라우드 공급자의 웹 콘솔에서 이 작업을 수행하거나 다음 반복문을 실행하여 수행할 수 있습니다. 

    $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 1; done
    Copy to Clipboard Toggle word wrap

    출력 예

    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.
    Copy to Clipboard Toggle word wrap

    이러한 방법 중 하나를 사용하여 노드를 종료하면 pod가 정상적으로 종료되어 데이터 손상 가능성을 줄일 수 있습니다.

    참고

    대규모 클러스터에 대해 종료 시간을 더 길게 조정합니다. 

    $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 10; done
    Copy to Clipboard Toggle word wrap
    참고

    종료하기 전에 OpenShift Container Platform과 함께 제공되는 표준 Pod의 컨트롤 플레인 노드를 드레인할 필요가 없습니다. 클러스터 관리자는 클러스터를 다시 시작한 후 워크로드를 완전히 다시 시작해야 합니다. 사용자 지정 워크로드로 인해 종료하기 전에 컨트롤 플레인 노드를 드레 이한 경우 다시 시작한 후 클러스터가 다시 작동하기 전에 컨트롤 플레인 노드를 스케줄 대상으로 표시해야합니다.

  5. 외부 스토리지 또는 LDAP 서버와 같이 더 이상 필요하지 않은 클러스터 종속성을 중지합니다. 이 작업을 수행하기 전에 공급 업체의 설명서를 확인하십시오.

    중요

    클라우드 공급자 플랫폼에 클러스터를 배포한 경우 연결된 클라우드 리소스를 종료, 일시 중지 또는 삭제하지 마십시오. 일시 중지된 가상 머신의 클라우드 리소스를 삭제하면 OpenShift Container Platform이 성공적으로 복원되지 않을 수 있습니다.

3장. 클러스터를 정상적으로 다시 시작
링크 복사

이 문서에서는 정상 종료 후 클러스터를 다시 시작하는 프로세스에 대해 설명합니다.

다시 시작한 후 클러스터가 정상적으로 작동할 것으로 예상되지만 예상치 못한 상황으로 인해 클러스터가 복구되지 않을 수 있습니다. 예를 들면 다음과 같습니다.

  • 종료 중 etcd 데이터 손상
  • 하드웨어로 인한 노드 오류
  • 네트워크 연결 문제

클러스터를 복구하지 못하는 경우 이전 클러스터 상태로 복원 단계를 따르십시오.

3.1. 전제 조건
링크 복사

3.2. 클러스터를 다시 시작
링크 복사

클러스터가 정상적으로 종료된 후 클러스터를 다시 시작할 수 있습니다.

전제 조건

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • 이 프로세스에서는 클러스터를 정상적으로 종료하고 있는 것을 전제로 하고 있습니다.

프로세스

  1. 컨트롤 플레인 노드를 켭니다.

    • 클러스터 설치의 admin.kubeconfig 를 사용하고 API 가상 IP 주소(VIP)가 up인 경우 다음 단계를 완료합니다.

      1. KUBECONFIG 환경 변수를 admin.kubeconfig 경로로 설정합니다.

      2. 클러스터의 각 컨트롤 플레인 노드에 대해 다음 명령을 실행합니다. 

        $ oc adm uncordon <node>
        Copy to Clipboard Toggle word wrap

    • admin.kubeconfig 인증 정보에 액세스할 수 없는 경우 다음 단계를 완료합니다.

      1. SSH를 사용하여 컨트롤 플레인 노드에 연결합니다.
      2. localhost-recovery.kubeconfig 파일을 /root 디렉터리에 복사합니다.

      3. 해당 파일을 사용하여 클러스터의 각 컨트롤 플레인 노드에 대해 다음 명령을 실행합니다. 

        $ oc adm uncordon <node>
        Copy to Clipboard Toggle word wrap
  2. 외부 스토리지 또는 LDAP 서버와 같은 클러스터의 종속 장치를 시작합니다.

  3. 모든 클러스터 시스템을 시작합니다.

    클라우드 제공 업체의 웹 콘솔에서 시스템을 시작하는 것과 같이 클라우드 환경에 적합한 방법을 사용하여 시스템을 시작합니다.

    약 10분 정도 기다린 후 컨트롤 플레인 노드의 상태를 확인합니다.

  4. 모든 컨트롤 플레인 노드가 준비되었는지 확인합니다. 

    $ oc get nodes -l node-role.kubernetes.io/master
    Copy to Clipboard Toggle word wrap

    다음 출력에 표시된 대로 노드의 상태가 Ready인 경우 컨트롤 플레인 노드는 준비된 것입니다. 

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-168-251.ec2.internal   Ready    master   75m   v1.25.0
ip-10-0-170-223.ec2.internal   Ready    master   75m   v1.25.0
ip-10-0-211-16.ec2.internal    Ready    master   75m   v1.25.0
    Copy to Clipboard Toggle word wrap

  5. 컨트롤 플레인 노드가 준비되지 않은 경우 승인해야하는 보류중인 인증서 서명 요청(CSR)이 있는지 확인합니다.

    1. 현재 CSR의 목록을 가져옵니다. 

      $ oc get csr
      Copy to Clipboard Toggle word wrap

    2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다. 

      $ oc describe csr <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

    3. 각각의 유효한 CSR을 승인합니다. 

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

  6. 컨트롤 플레인 노드가 준비되면 모든 작업자 노드가 준비되었는지 확인합니다. 

    $ oc get nodes -l node-role.kubernetes.io/worker
    Copy to Clipboard Toggle word wrap

    다음 출력에 표시된 대로 작업자 노드의 상태가 Ready인 경우 작업자 노드는 준비된 것입니다. 

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-179-95.ec2.internal    Ready    worker   64m   v1.25.0
ip-10-0-182-134.ec2.internal   Ready    worker   64m   v1.25.0
ip-10-0-250-100.ec2.internal   Ready    worker   64m   v1.25.0
    Copy to Clipboard Toggle word wrap

  7. 작업자 노드가 준비되지 않은 경우 승인해야하는 보류중인 인증서 서명 요청(CSR)이 있는지 확인합니다.

    1. 현재 CSR의 목록을 가져옵니다. 

      $ oc get csr
      Copy to Clipboard Toggle word wrap

    2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다. 

      $ oc describe csr <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

    3. 각각의 유효한 CSR을 승인합니다. 

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

  8. 클러스터가 제대로 시작되었는지 확인합니다.

    1. 성능이 저하된 클러스터 Operator가 없는지 확인합니다. 

      $ oc get clusteroperators
      Copy to Clipboard Toggle word wrap

      DEGRADED 조건이 True로 설정된 클러스터 Operator가 없는지 확인합니다. 

      NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.12.0    True        False         False      59m
cloud-credential                           4.12.0    True        False         False      85m
cluster-autoscaler                         4.12.0    True        False         False      73m
config-operator                            4.12.0    True        False         False      73m
console                                    4.12.0    True        False         False      62m
csi-snapshot-controller                    4.12.0    True        False         False      66m
dns                                        4.12.0    True        False         False      76m
etcd                                       4.12.0    True        False         False      76m
...
      Copy to Clipboard Toggle word wrap

    2. 모든 노드가 Ready 상태에 있는지 확인합니다. 

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

      모든 노드의 상태가 Ready 상태인지 확인합니다. 

      NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.25.0
ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.25.0
ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.25.0
ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.25.0
ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.25.0
ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.25.0
      Copy to Clipboard Toggle word wrap

      클러스터가 제대로 시작되지 않은 경우 etcd 백업을 사용하여 클러스터를 복원해야 할 수 있습니다.

  9. 컨트롤 플레인 및 작업자 노드가 준비되면 클러스터의 모든 노드를 예약 가능으로 표시합니다. 다음 명령을 실행합니다. 

    for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm uncordon ${node} ; done
    Copy to Clipboard Toggle word wrap

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.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를 다시 생성하고 정상적으로 실행됩니다.

OADP-3767

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 를 생성하는 것입니다. 사용자 정의 보안이 다시 생성되면 해당 보안의 존재를 확인하고 사용할 수 있습니다.

OADP-3193

CVE-2023-45290: oadp-velero-container: Golang net/http: Request.ParseMultipartForm의 메모리 소진

이전 버전의 OADP에 영향을 미치는 net/http Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. Request.ParseMultipartForm을 사용하여 명시적으로 또는 Request.FormValue,Request.PostFormValue 또는 Request.FormFile을 사용하여 명시적으로 multipart 양식을 구문 분석할 때 구문 분석 양식의 총 크기에 대한 제한은 단일 양식 줄을 읽는 동안 사용되는 메모리에 적용되지 않습니다. 이렇게 하면 긴 줄이 포함된 악의적인 입력으로 인해 임의로 많은 양의 메모리를 할당하여 메모리 소모가 발생할 수 있습니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.

자세한 내용은 CVE-2023-45290 에서 참조하십시오.

CVE-2023-45289: oadp-velero-container: Golang net/http/cookiejar: 민감한 헤더 및 쿠키를 HTTP 리디렉션에서 올바르게 전달하지 않음

이전 버전의 OADP에 영향을 미치는 net/http/cookiejar Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. HTTP 리디렉션을 하위 도메인 일치 또는 초기 도메인의 정확한 일치가 아닌 도메인으로 리디렉션하는 경우 http.Client 는 Authorization 또는 Cookie와 같은 중요한 헤더를 전달하지 않습니다. 악의적인 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를 VerifyClientCertIfGiven 또는 RequireAndVerifyClientCert로 설정하는 모든 crypto/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를 다시 생성하고 정상적으로 실행됩니다.

OADP-3767

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-3788

OADP Operator에서 누락된 지역 오류를 올바르게 보고

이전에는 AWS Backup Storage Location (BSL) 구성에 region 을 지정하지 않고 profile:default 를 지정하면 OADP Operator에서 DPA(Data Protection Application) 사용자 정의 리소스(CR)에서 누락된 리전 오류를 보고하지 못했습니다. 이번 업데이트에서는 AWS의 DPA BSL 사양의 검증이 수정되었습니다. 결과적으로 OADP Operator에서 누락된 지역 오류를 보고합니다.

OADP-3044

사용자 정의 레이블은 openshift-adp 네임스페이스에서 제거되지 않음

이전에는 openshift-adp-controller-manager Pod가 openshift-adp 네임스페이스에 연결된 레이블을 재설정했습니다. 이로 인해 Argo CD와 같은 사용자 정의 레이블이 필요한 애플리케이션의 동기화 문제로 인해 부적절한 기능이 발생했습니다. 이번 업데이트를 통해 이 문제가 수정되었으며 사용자 정의 레이블은 openshift-adp 네임스페이스에서 제거되지 않습니다.

OADP-3189

OADP must-gather 이미지는 CRD를 수집합니다.

이전에는 OADP must-gather 이미지가 OADP에서 제공하는 CRD(사용자 정의 리소스 정의)를 수집하지 않았습니다. 결과적으로 지원 쉘에서 데이터를 추출하는 데 omg 툴을 사용할 수 없었습니다. 이번 수정으로 must-gather 이미지는 이제 OADP에서 제공하는 CRD를 수집하고 omg 툴을 사용하여 데이터를 추출할 수 있습니다.

OADP-3229

가비지 컬렉션에는 기본 빈도 값에 대한 올바른 설명이 있습니다.

이전에는 garbage-collection-frequency 필드에 기본 빈도 값에 대한 잘못된 설명이 있었습니다. 이번 업데이트를 통해 garbage-collection-frequency 의 gc-controller 조정 기본 빈도에 대해 1시간의 올바른 값이 있습니다.

OADP-3486

OperatorHub에서 FIPS 모드 플래그를 사용할 수 있습니다.

fips-compliant 플래그를 true 로 설정하면 OperatorHub의 OADP Operator 목록에 FIPS 모드 플래그가 추가되었습니다. 이 기능은 OADP 1.3.0에서 활성화되었지만 Red Hat Container 카탈로그에 FIPS가 활성화된 것으로 표시되지 않았습니다.

OADP-3495

csiSnapshotTimeout이 짧은 기간으로 설정된 경우 CSI 플러그인에 nil 포인터가 패닉되지 않음

이전 버전에서는 csiSnapshotTimeout 매개변수가 단기간에 설정된 경우 CSI 플러그인에 다음 오류가 발생했습니다. plugin panicked: runtime error: invalid memory address or nil pointer dereference.

이번 수정으로 다음 오류와 함께 백업이 실패합니다. volumesnapshot의 조정 대기 시간이 초과 되었습니다.

OADP-3069

이 릴리스에서 해결된 모든 문제의 전체 목록은 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 와 같은 파일 시스템 백업을 사용하는 백업 애플리케이션만 백업 및 복원 작업을 지원합니다.

OADP-3787

Cryostat 애플리케이션 Pod는 OADP를 복원한 후 CrashLoopBackoff 상태로 입력합니다.

OADP 복원 후 Cryostat 애플리케이션 pod는 CrashLoopBackoff 상태에 입력할 수 있습니다. 이 문제를 해결하려면 OADP를 복원한 후 오류 또는 CrashLoopBackoff 상태의 StatefulSet Pod를 삭제합니다. StatefulSet 컨트롤러는 이러한 Pod를 다시 생성하고 정상적으로 실행됩니다.

OADP-3767

4.2.1.7. OADP 1.3.0 릴리스 노트
링크 복사

OADP(OpenShift API for Data Protection) 1.3.0 릴리스에는 새로운 기능, 해결된 문제 및 버그, 알려진 문제가 포함되어 있습니다.

4.2.1.7.1. 새로운 기능
링크 복사
Velero 내장 DataMover

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

최초 30,000개 리소스 복원 시 성능 문제 발생

existing-resource-policy 없이 처음으로 Cryostat 리소스를 복원할 때 두 번째 및 세 번째 시도 중에 update를 위해 설정된 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
# ...
    Copy to Clipboard Toggle word wrap

  • spec.configuration.restic 필드는 OADP 1.3에서 더 이상 사용되지 않으며 향후 OADP 버전에서 제거될 예정입니다. 사용 중단 경고가 표시되지 않도록 하려면 restic 키와 해당 값을 제거하고 다음 새 구문을 사용합니다.

    예제

    spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: restic
# ...
    Copy to Clipboard Toggle word wrap

참고

향후 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으로 업그레이드하기 전에 다음 단계를 완료합니다.

프로세스

  1. 클러스터 백업이 충분하고 CSI(Container Storage Interface) 스토리지를 사용할 수 있는 경우 CSI 백업을 사용하여 애플리케이션을 백업합니다.

  2. 클러스터 백업을 꺼야 하는 경우:

    1. --default-volumes-to-fs-backup=true 또는 backup.spec.defaultVolumesToFsBackup 옵션을 사용하는 파일 시스템 백업으로 애플리케이션을 백업합니다.
    2. 오브젝트 스토리지 플러그인으로 애플리케이션을 백업합니다(예: velero-plugin-for-aws ).
참고

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
    Copy to Clipboard Toggle word wrap

4.2.1.7.4.4. OADP Operator 업그레이드
링크 복사

OADP(OpenShift API for Data Protection) Operator를 업그레이드할 때 다음 시퀀스를 사용합니다.

프로세스

  1. OADP Operator의 서브스크립션 채널을 stable-1.2 에서 stable-1.3 으로 변경합니다.
  2. Operator 및 컨테이너가 업데이트 및 재시작될 수 있는 시간을 허용합니다.
4.2.1.7.4.5. DPA를 새 버전으로 변환
링크 복사

Data Mover를 사용하여 클러스터에서 백업을 이동해야 하는 경우 다음과 같이 DPA( DataProtectionApplication ) 매니페스트를 재구성합니다.

프로세스

  1. Operators → 설치된 Operator 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 섹션에서 추가 보기를 클릭합니다.
  3. DataProtectionApplication 상자에서 인스턴스 만들기 를 클릭합니다.

  4. YAML View 를 클릭하여 현재 DPA 매개변수를 표시합니다.

    현재 DPA의 예

    spec:
  configuration:
    features:
      dataMover:
      enable: true
      credentialName: dm-credentials
    velero:
      defaultPlugins:
      - vsm
      - csi
      - openshift
# ...
    Copy to Clipboard Toggle word wrap

  5. DPA 매개변수를 업데이트합니다.

    • DPA에서 features.dataMover 키와 값을 제거합니다.
    • VolumeSnapshotMover(VSM) 플러그인을 제거합니다.

    • nodeAgent 키와 값을 추가합니다.

      업데이트된 DPA 예

      spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
    velero:
      defaultPlugins:
      - csi
      - openshift
# ...
      Copy to Clipboard Toggle word wrap

  6. DPA가 성공적으로 조정될 때까지 기다립니다.
4.2.1.7.4.6. 업그레이드 확인
링크 복사

다음 절차를 사용하여 업그레이드를 확인합니다.

프로세스

  1. 다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 DPA( DataProtectionApplication )가 조정되었는지 확인합니다. 

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    Copy to Clipboard Toggle word wrap

    출력 예

    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
    Copy to Clipboard Toggle word wrap

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.

  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다. 

    $ oc get backupStorageLocation -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
dpa-sample-1   Available   1s               3d16h   true
    Copy to Clipboard Toggle word wrap

OADP 1.3에서는 DPA( DataProtectionApplication ) 구성을 생성하는 대신 백업당 클러스터에서 데이터 이동을 시작할 수 있습니다.

명령 예

$ velero backup create example-backup --include-namespaces mysql-persistent --snapshot-move-data=true
Copy to Clipboard Toggle word wrap

설정 파일 예

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
# ...
Copy to Clipboard Toggle word wrap

4.2.2. OADP 1.2 릴리스 노트
링크 복사

OADP(OpenShift API for Data Protection) 1.2 릴리스 노트에서는 새로운 기능 및 개선 사항, 더 이상 사용되지 않는 기능, 제품 권장 사항, 알려진 문제, 해결된 문제에 대해 설명합니다.

4.2.2.1. OADP 1.2.5 릴리스 노트
링크 복사

OADP(OpenShift API for Data Protection) 1.2.5는 컨테이너의 상태 등급을 새로 고치기 위해 릴리스된 컨테이너 전용(CGO) 릴리스이며 OADP 1.2.4와 비교하여 제품 자체의 코드를 변경하지 않습니다.

4.2.2.1.1. 해결된 문제
링크 복사

CVE-2023-2431: oadp-velero-plugin-for-microsoft-azure-container: Bypass of seccomp profile enforcement

Kubernetes에서는 이전 버전의 OADP에 영향을 미치는 취약점이 발견되었습니다. 이 취약점은 Kubernetes에서 로컬 인증된 공격자가 seccomp 프로필에 localhost 유형을 사용할 때 결함으로 인해 보안 제한을 우회할 수 있지만 빈 프로필 필드를 지정할 때 발생하는 경우 발생합니다. 공격자는 특수하게 조작된 요청을 전송하여 seccomp 프로필 시행을 우회할 수 있습니다. 이 취약점은 OADP 1.2.5에서 해결되었습니다.

자세한 내용은 (CVE-2023-2431) 을 참조하십시오.

CSI 복원이 'PartiallyFailed' 상태로 종료되었으며 PVC가 생성되지 않음

CSI 복원은 PartiallyFailed 상태로 종료되었습니다. PVC가 생성되지 않으며 Pod는 Pending 상태입니다. 이 문제는 OADP 1.2.5에서 해결되었습니다.

(OADP-1956)

완료된 Pod 볼륨에서 PodVolumeBackup 실패

이전 버전의 OADP 1.2에서는 Restic podvolumebackup 또는 Velero 백업에서 사용하는 네임스페이스에 볼륨을 마운트한 완료된 Pod가 있는 경우 백업이 성공적으로 완료되지 않습니다. 이는 defaultVolumesToFsBackup 이 true 로 설정된 경우 발생합니다. 이 문제는 OADP 1.2.5에서 해결되었습니다.

(OADP-1870)

4.2.2.1.2. 확인된 문제
링크 복사

인증 정보 시크릿을 업데이트할 때 DPA(Data Protection Application)가 조정되지 않음

현재 cloud-credentials 시크릿을 업데이트할 때 OADP Operator가 조정되지 않습니다. 이는 cloud-credentials 보안에 OADP 특정 라벨 또는 소유자 참조가 없기 때문에 발생합니다. 빈 데이터와 같이 잘못된 인증 정보를 사용하여 cloud-credentials 보안을 생성하면 Operator가 조정되고 빈 데이터로 백업 스토리지 위치(BSL) 및 레지스트리 배포를 생성합니다. 결과적으로 올바른 인증 정보를 사용하여 cloud-credentials 보안을 업데이트하면 OADP Operator가 새 인증 정보를 수집하도록 즉시 조정되지 않습니다.

해결방법: OADP 1.3으로 업데이트합니다.

(OADP-3327)

4.2.2.2. OADP 1.2.4 릴리스 노트
링크 복사

OADP(OpenShift API for Data Protection) 1.2.4는 컨테이너의 상태 등급을 새로 고치기 위해 릴리스된 컨테이너 전용(CGO) 릴리스이며 OADP 1.2.3과 비교하여 제품 자체의 코드를 변경하지 않습니다.

4.2.2.2.1. 해결된 문제
링크 복사

OADP 1.2.4에는 해결된 문제가 없습니다.

4.2.2.2.2. 확인된 문제
링크 복사

OADP 1.2.4에는 다음과 같은 알려진 문제가 있습니다.

인증 정보 시크릿을 업데이트할 때 DPA(Data Protection Application)가 조정되지 않음

현재 cloud-credentials 시크릿을 업데이트할 때 OADP Operator가 조정되지 않습니다. 이는 cloud-credentials 보안에 OADP 특정 라벨 또는 소유자 참조가 없기 때문에 발생합니다. 빈 데이터와 같이 잘못된 인증 정보를 사용하여 cloud-credentials 보안을 생성하면 Operator가 조정되고 빈 데이터로 백업 스토리지 위치(BSL) 및 레지스트리 배포를 생성합니다. 결과적으로 올바른 인증 정보를 사용하여 cloud-credentials 보안을 업데이트하면 Operator가 새 인증 정보를 수집하도록 즉시 조정되지 않습니다.

해결방법: OADP 1.3으로 업데이트합니다.

(OADP-3327)

4.2.2.3. OADP 1.2.3 릴리스 노트
링크 복사
4.2.2.3.1. 새로운 기능
링크 복사

OADP(OpenShift API for Data Protection) 1.2.3 릴리스에는 새로운 기능이 없습니다.

4.2.2.3.2. 해결된 문제
링크 복사

다음 강조 표시된 문제는 OADP 1.2.3에서 해결됩니다.

여러 HTTP/2가 활성화된 웹 서버는 DDoS 공격(Rapid Reset Attack)에 취약합니다.

이전 버전의 OADP 1.2에서는 요청 취소가 여러 스트림을 빠르게 재설정할 수 있기 때문에 HTTP/2 프로토콜이 서비스 거부 공격에 취약했습니다. 서버는 스트림을 설정하고 해체하는 동시에 연결당 최대 활성 스트림 수에 대한 서버 측 제한에 도달하지 않아야 했습니다. 이로 인해 서버 리소스 사용량으로 인해 서비스가 거부되었습니다. 이 CVE와 관련된 모든 OADP 문제 목록은 다음 Jira 목록을 참조하십시오.

자세한 내용은 CVE-2023-39325 (Rapid Reset Attack) 를 참조하십시오.

OADP 1.2.3 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.2.3 해결된 문제 목록을 참조하십시오.

4.2.2.3.3. 확인된 문제
링크 복사

OADP 1.2.3에는 다음과 같은 알려진 문제가 있습니다.

인증 정보 시크릿을 업데이트할 때 DPA(Data Protection Application)가 조정되지 않음

현재 cloud-credentials 시크릿을 업데이트할 때 OADP Operator가 조정되지 않습니다. 이는 cloud-credentials 보안에 OADP 특정 라벨 또는 소유자 참조가 없기 때문에 발생합니다. 빈 데이터와 같이 잘못된 인증 정보를 사용하여 cloud-credentials 보안을 생성하면 Operator가 조정되고 빈 데이터로 백업 스토리지 위치(BSL) 및 레지스트리 배포를 생성합니다. 결과적으로 올바른 인증 정보를 사용하여 cloud-credentials 보안을 업데이트하면 Operator가 새 인증 정보를 수집하도록 즉시 조정되지 않습니다.

해결방법: OADP 1.3으로 업데이트합니다.

(OADP-3327)

4.2.2.4. OADP 1.2.2 릴리스 노트
링크 복사
4.2.2.4.1. 새로운 기능
링크 복사

OADP(OpenShift API for Data Protection) 1.2.2 릴리스에는 새로운 기능이 없습니다.

4.2.2.4.2. 해결된 문제
링크 복사

다음 강조 표시된 문제는 OADP 1.2.2에서 해결됩니다.

Pod 보안 표준으로 인해 Restic 복원이 부분적으로 실패했습니다.

이전 릴리스의 OADP 1.2에서 OpenShift Container Platform 4.14는 Restic 복원 프로세스 중에 Pod 준비 상태를 방해하는 PSA(Pod 보안 승인) 정책을 적용했습니다.

이 문제는 OADP 1.2.2 및 OADP 1.1.6 릴리스에서 해결되었습니다. 따라서 사용자는 이러한 릴리스로 업그레이드하는 것이 좋습니다.

자세한 내용은 변경된 PSA 정책으로 인해 OCP 4.14에서 부분적으로 실패한 Restic 복원을 참조하십시오. (OADP-2094)

내부 이미지가 있는 앱 백업이 플러그인 패닉 오류와 함께 부분적으로 실패했습니다.

이전 릴리스의 OADP 1.2 릴리스에서는 플러그인 패닉 오류가 반환되어 내부 이미지가 부분적으로 실패한 애플리케이션의 백업이 실패했습니다. Velero 로그에서 이 오류와 함께 백업이 부분적으로 실패합니다. 

time="2022-11-23T15:40:46Z" level=info msg="1 errors encountered backup up item" backup=openshift-adp/django-persistent-67a5b83d-6b44-11ed-9cba-902e163f806c logSource="/remote-source/velero/app/pkg/backup/backup.go:413" name=django-psql-persistent
time="2022-11-23T15:40:46Z" level=error msg="Error backing up item" backup=openshift-adp/django-persistent-67a5b83d-6b44-11ed-9cba-902e163f8
Copy to Clipboard Toggle word wrap

이 문제는 OADP 1.2.2에서 해결되었습니다. (OADP-1057).

복원 주문으로 인해 ACM 클러스터 복원이 예상대로 작동하지 않았습니다.

이전 릴리스의 OADP 1.2에서는 복원 주문으로 인해 ACM 클러스터 복원이 예상대로 작동하지 않았습니다. ACM 애플리케이션은 복원 활성화 후 관리 클러스터에서 제거 및 다시 생성되었습니다. (OADP-2505)

볼륨 크기 불일치로 인해 백업 및 복원 시 VM의 filesystemOverhead 사용 실패

이전 릴리스에서는 스토리지 공급자 구현 선택 사항으로 인해 애플리케이션 PVC(영구 볼륨 클레임) 스토리지 요청과 동일한 PVC의 스냅샷 크기에 차이가 있을 때마다 백업 및 복원 시 VM의 filesystemOverhead가 실패했습니다. 이 문제는 OADP 1.2.2의 데이터 Mover에서 해결되었습니다. (OADP-2144)

OADP에는 collectdSync 복제 소스 정리 간격을 설정하는 옵션이 포함되어 있지 않았습니다.

이전 릴리스의 OADP 1.2에서는 ballSync 복제 소스 pruneInterval 을 설정할 수 있는 옵션이 없었습니다. (OADP-2052)

Velero가 여러 네임스페이스에 설치된 경우 가능한 Pod 볼륨 백업 실패

이전 릴리스의 OADP 1.2 릴리스에서는 Velero가 여러 네임스페이스에 설치된 경우 Pod 볼륨 백업 오류가 발생할 수 있었습니다. (OADP-2409)

VSL에서 사용자 정의 시크릿을 사용하는 경우 백업 스토리지 위치가 사용할 수 없는 단계로 이동

이전 릴리스의 OADP 1.2 릴리스에서는 Volume Snapshot Location이 사용자 정의 시크릿을 사용한 경우 Backup Storage Locations를 사용할 수 없는 단계로 이동했습니다. (OADP-1737)

OADP 1.2.2 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.2.2 해결된 문제 목록을 참조하십시오.

4.2.2.4.3. 확인된 문제
링크 복사

다음 문제는 OADP 1.2.2 릴리스에서 알려진 문제로 강조되어 있습니다.

must-gather 명령이 ClusterRoleBinding 리소스를 제거하지 못했습니다

oc adm must-gather 명령은 승인 Webhook로 인해 클러스터에 남아 있는 ClusterRoleBinding 리소스를 제거하지 못합니다. 따라서 ClusterRoleBinding 리소스 제거 요청이 거부됩니다. (OADP-27730) 

admission webhook "clusterrolebindings-validation.managed.openshift.io" denied the request: Deleting ClusterRoleBinding must-gather-p7vwj is not allowed
Copy to Clipboard Toggle word wrap

이 릴리스에서 알려진 모든 문제의 전체 목록은 Jira의 OADP 1.2.2 알려진 문제 목록을 참조하십시오.

4.2.2.5. OADP 1.2.1 릴리스 노트
링크 복사
4.2.2.5.1. 새로운 기능
링크 복사

OADP(OpenShift API for Data Protection) 1.2.1 릴리스에는 새로운 기능이 없습니다.

4.2.2.5.2. 해결된 문제
링크 복사

OADP 1.2.1 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.2.1 해결 문제 목록을 참조하십시오.

4.2.2.5.3. 확인된 문제
링크 복사

다음 문제는 OADP 1.2.1 릴리스에서 알려진 문제로 강조되어 있습니다.

DataMover Restic 유지 및 정리 정책이 예상대로 작동하지 않음

CryostatSync 및 Restic이 제공하는 보존 및 정리 기능은 예상대로 작동하지 않습니다. collectdSync 복제에 정리 간격을 설정하는 작업 옵션이 없으므로 OADP 외부에서 S3 스토리지에 원격으로 저장된 백업을 관리하고 정리해야 합니다. 자세한 내용은 다음을 참조하십시오.

중요

OADP Data Mover는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

이 릴리스에서 알려진 모든 문제의 전체 목록은 Jira의 OADP 1.2.1 알려진 문제 목록을 참조하십시오.

4.2.2.6. OADP 1.2.0 릴리스 노트
링크 복사

OADP 1.2.0 릴리스 노트에는 새로운 기능, 버그 수정 및 알려진 문제에 대한 정보가 포함되어 있습니다.

4.2.2.6.1. 새로운 기능
링크 복사

리소스 제한 시간

새 resourceTimeout 옵션은 다양한 Velero 리소스에서 대기할 때까지 시간 초과 기간을 분 단위로 지정합니다. 이 옵션은 Velero CRD 가용성, volumeSnapshot 삭제 및 백업 리포지토리 가용성과 같은 리소스에 적용됩니다. 기본 기간은 10분입니다.

AWS S3 호환 백업 스토리지 공급자

AWS S3 호환 공급자에서 오브젝트 및 스냅샷을 백업할 수 있습니다.

4.2.2.6.1.1. 기술 프리뷰 기능
링크 복사

Data Mover

OADP Data Mover를 사용하면 CSI(Container Storage Interface) 볼륨 스냅샷을 원격 오브젝트 저장소에 백업할 수 있습니다. Data Mover를 활성화하면 실수로 클러스터 삭제, 클러스터 장애 또는 데이터 손상의 경우 오브젝트 저장소에서 가져온 CSI 볼륨 스냅샷을 사용하여 상태 저장 애플리케이션을 복원할 수 있습니다.

중요

OADP Data Mover는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

4.2.2.6.2. 해결된 문제
링크 복사

이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.2.0 해결 문제 목록을 참조하십시오.

4.2.2.6.3. 확인된 문제
링크 복사

다음 문제는 OADP 1.2.0 릴리스에서 알려진 문제로 강조되어 있습니다.

여러 HTTP/2가 활성화된 웹 서버는 DDoS 공격(Rapid Reset Attack)에 취약합니다.

요청 취소가 여러 스트림을 빠르게 재설정할 수 있으므로 HTTP/2 프로토콜은 서비스 거부 공격에 취약합니다. 서버는 스트림을 설정하고 해체해야 하지만 연결당 최대 활성 스트림 수에 대한 서버 측 제한에 도달하지 않아야 합니다. 이로 인해 서버 리소스 사용량으로 인해 서비스 거부가 발생합니다.

이 문제를 해결하려면 OADP 1.2.3으로 업그레이드하는 것이 좋습니다.

자세한 내용은 CVE-2023-39325 (Rapid Reset Attack) 를 참조하십시오.

생성된 경로에서 호스트 이름을 변경할 때 잘못된 호스트 이름을 생성할 수 있습니다.

기본적으로 OpenShift Container Platform 클러스터는 openshift.io/host.generated: true 주석이 켜져 있고 생성되는 경로와 생성되지 않은 경로의 필드를 채우도록 합니다.

생성된 경로 및 생성되지 않은 경로에 있는 클러스터의 기본 도메인 이름을 기반으로 .spec.host 필드의 값을 수정할 수 없습니다.

.spec.host 필드의 값을 수정하면 OpenShift Container Platform 클러스터에서 생성된 기본값을 복원할 수 없습니다. OpenShift Container Platform 클러스터를 복원한 후 Operator는 필드 값을 재설정합니다.

4.2.2.6.4. 업그레이드 노트
링크 복사
참고

항상 다음 마이너 버전으로 업그레이드합니다. 버전을 건너뛰 지 마십시오. 이후 버전으로 업데이트하려면 한 번에 하나의 채널만 업그레이드합니다. 예를 들어 OADP(OpenShift API for Data Protection) 1.1에서 1.3으로 업그레이드하려면 먼저 1.2로 업그레이드한 다음 1.3으로 업그레이드합니다.

4.2.2.6.4.1. OADP 1.1에서 1.2로 변경
링크 복사

Velero 서버가 버전 1.9에서 1.11로 업데이트되었습니다.

OADP 1.2에서 DPA( DataProtectionApplication ) 구성 dpa.spec.configuration.velero.args 에는 다음과 같은 변경 사항이 있습니다.

  • default-volumes-to-restic 필드의 이름이 default-volumes-to-fs-backup 으로 변경되었습니다. dpa.spec.configuration.velero.args 를 사용하는 경우 OADP를 업그레이드한 후 새 이름으로 DPA를 다시 추가해야 합니다.
  • restic-timeout 필드의 이름이 fs-backup-timeout 로 변경되었습니다. dpa.spec.configuration.velero.args 를 사용하는 경우 OADP를 업그레이드한 후 새 이름으로 DPA를 다시 추가해야 합니다.
  • restic 데몬 세트의 이름이 node-agent 로 변경되었습니다. OADP는 데몬 세트의 이름을 자동으로 업데이트합니다.
  • 사용자 정의 리소스 정의 resticrepositories.velero.io 는 backuprepositories.velero.io 로 변경되었습니다.
  • 사용자 정의 리소스 정의 resticrepositories.velero.io 는 클러스터에서 제거할 수 있습니다.
4.2.2.6.5. 업그레이드 단계
링크 복사
4.2.2.6.5.1. DPA 구성 백업
링크 복사

현재 DPA( DataProtectionApplication ) 구성을 백업해야 합니다.

절차

  • 다음 명령을 실행하여 현재 DPA 구성을 저장합니다.

    예제

    $ oc get dpa -n openshift-adp -o yaml > dpa.orig.backup
    Copy to Clipboard Toggle word wrap

4.2.2.6.5.2. OADP Operator 업그레이드
링크 복사

OADP(OpenShift API for Data Protection) Operator를 업그레이드할 때 다음 시퀀스를 사용합니다.

절차

  1. OADP Operator의 서브스크립션 채널을 stable-1.1 에서 stable-1.2 로 변경합니다.
  2. Operator 및 컨테이너가 업데이트 및 재시작될 수 있는 시간을 허용합니다.
4.2.2.6.5.3. DPA를 새 버전으로 변환
링크 복사

spec.configuration.velero.args 스탠자에서 업데이트된 필드를 사용하는 경우 새 매개변수 이름을 사용하도록 DPA( DataProtectionApplication ) 매니페스트를 구성해야 합니다.

절차

  1. Operators → 설치된 Operator 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 를 선택하고 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

  3. YAML View 를 클릭하여 현재 DPA 매개변수를 표시합니다.

    현재 DPA의 예

    spec:
  configuration:
    velero:
      args:
        default-volumes-to-fs-backup: true
        default-restic-prune-frequency: 6000
        fs-backup-timeout: 600
# ...
    Copy to Clipboard Toggle word wrap

  4. DPA 매개변수를 업데이트합니다.

  5. 값을 변경하지 않고 DPA 매개변수 이름을 업데이트합니다.

    1. default-volumes-to-restic 키를 default-volumes-to-fs-backup 으로 변경합니다.
    2. default-restic-prune-frequency 키를 default-repo-maintain-frequency 로 변경합니다.
    3. restic-timeout 키를 fs-backup-timeout 로 변경합니다.

    .example updated DPA 

    spec:
  configuration:
    velero:
      args:
        default-volumes-to-fs-backup: true
        default-repo-maintain-frequency: 6000
        fs-backup-timeout: 600
# ...
    Copy to Clipboard Toggle word wrap
  6. DPA가 성공적으로 조정될 때까지 기다립니다.
4.2.2.6.5.4. 업그레이드 확인
링크 복사

다음 절차를 사용하여 업그레이드를 확인합니다.

절차

  1. 다음 명령을 실행하여 OADP(OpenShift API for Data Protection) 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-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

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   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
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 DPA( DataProtectionApplication )가 조정되었는지 확인합니다. 

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    Copy to Clipboard Toggle word wrap

    출력 예

    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
    Copy to Clipboard Toggle word wrap

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.

  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다. 

    $ oc get backupStorageLocation -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
dpa-sample-1   Available   1s               3d16h   true
    Copy to Clipboard Toggle word wrap

4.2.3. OADP 1.1 릴리스 노트
링크 복사

OADP(OpenShift API for Data Protection) 1.1의 릴리스 노트에서는 새로운 기능 및 개선 사항, 더 이상 사용되지 않는 기능, 제품 권장 사항, 알려진 문제, 해결된 문제에 대해 설명합니다.

4.2.3.1. OADP 1.1.8 릴리스 노트
링크 복사

OADP(OpenShift API for Data Protection) 1.1.8 릴리스 노트에는 알려진 문제가 나열됩니다. 이 릴리스에는 해결된 문제가 없습니다.

4.2.3.1.1. 확인된 문제
링크 복사

OADP 1.1.8의 알려진 모든 문제의 전체 목록은 Jira에서 알려진 OADP 1.1.8 문제 목록을 참조하십시오.

4.2.3.2. OADP 1.1.7 릴리스 노트
링크 복사

OADP 1.1.7 릴리스 노트에는 해결된 문제와 알려진 문제가 나열되어 있습니다.

4.2.3.2.1. 해결된 문제
링크 복사

다음의 강조된 문제는 OADP 1.1.7에서 해결됩니다.

여러 HTTP/2가 활성화된 웹 서버는 DDoS 공격(Rapid Reset Attack)에 취약합니다.

이전 버전의 OADP 1.1에서는 요청 취소가 여러 스트림을 빠르게 재설정할 수 있기 때문에 HTTP/2 프로토콜이 서비스 거부 공격에 취약했습니다. 서버는 스트림을 설정하고 해체하는 동시에 연결당 최대 활성 스트림 수에 대한 서버 측 제한에 도달하지 않아야 했습니다. 이로 인해 서버 리소스 사용량으로 인해 서비스가 거부되었습니다. 이 CVE와 관련된 모든 OADP 문제 목록은 다음 Jira 목록을 참조하십시오.

자세한 내용은 CVE-2023-39325 (Rapid Reset Attack) 를 참조하십시오.

OADP 1.1.7 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.1.7 문제 목록을 참조하십시오.

4.2.3.2.2. 확인된 문제
링크 복사

OADP 1.1.7 릴리스에는 알려진 문제가 없습니다.

4.2.3.3. OADP 1.1.6 릴리스 노트
링크 복사

OADP 1.1.6 릴리스 노트에는 새로운 기능, 해결된 문제 및 버그, 알려진 문제가 나열되어 있습니다.

4.2.3.3.1. 해결된 문제
링크 복사

Pod 보안 표준으로 인해 Restic 복원이 부분적으로 실패함

OCP 4.14에서는 권한 있는 프로필이 적용됨을 나타내는 Pod 보안 표준이 도입 되었습니다. 이전 릴리스의 OADP에서 이 프로필로 인해 Pod에서 권한 거부 오류가 발생했습니다. 이 문제는 복원 순서 때문에 발생했습니다. Pod는 SCC(보안 컨텍스트 제약 조건) 리소스 전에 생성되었습니다. 이 Pod가 Pod 보안 표준을 위반했기 때문에 Pod가 거부되어 실패했습니다. OADP-2420

작업 리소스에 대해 부분적으로 실패함

이전 릴리스의 OADP에서는 OCP 4.14에서 작업 리소스 복원이 부분적으로 실패했습니다. 이 문제는 이전 OCP 버전에서 볼 수 없었습니다. 이 문제는 이전 OCP 버전에 없는 작업 리소스에 대한 추가 레이블로 인해 발생했습니다. OADP-2530

이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.1.6 해결 문제 목록을 참조하십시오.

4.2.3.3.2. 확인된 문제
링크 복사

이 릴리스에서 알려진 모든 문제의 전체 목록은 Jira의 OADP 1.1.6 알려진 문제 목록을 참조하십시오.

4.2.3.4. OADP 1.1.5 릴리스 노트
링크 복사

OADP 1.1.5 릴리스 노트에는 새로운 기능, 해결된 문제 및 버그, 알려진 문제가 나열되어 있습니다.

4.2.3.4.1. 새로운 기능
링크 복사

이 버전의 OADP는 서비스 릴리스입니다. 이 버전에는 새로운 기능이 추가되지 않습니다.

4.2.3.4.2. 해결된 문제
링크 복사

이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.1.5 해결 문제 목록을 참조하십시오.

4.2.3.4.3. 확인된 문제
링크 복사

이 릴리스에서 알려진 모든 문제의 전체 목록은 Jira의 OADP 1.1.5 알려진 문제 목록을 참조하십시오.

4.2.3.5. OADP 1.1.4 릴리스 노트
링크 복사

OADP 1.1.4 릴리스 노트에는 새로운 기능, 해결된 문제 및 알려진 문제가 나열되어 있습니다.

4.2.3.5.1. 새로운 기능
링크 복사

이 버전의 OADP는 서비스 릴리스입니다. 이 버전에는 새로운 기능이 추가되지 않습니다.

4.2.3.5.2. 해결된 문제
링크 복사

모든 velero 배포 서버 인수에 대한 지원 추가

이전 릴리스에서 OADP는 모든 업스트림 Velero 서버 인수를 지원하지 않았습니다. 이 문제는 OADP 1.1.4에서 해결되었으며 모든 업스트림 Velero 서버 인수가 지원됩니다. OADP-1557

복원 이름과 pvc 이름에 두 개 이상의 VSR이 있는 경우 데이터 Mover가 잘못된 스냅샷에서 복원할 수 있습니다.

이전 릴리스에서는 동일한 Velero 복원 이름 및 영구 볼륨 클레임(pvc) 이름에 대해 클러스터에 VSR( Volume Snapshot Restore) 리소스가 두 개 이상 있는 경우 OADP Data Mover가 잘못된 스냅샷에서 복원할 수 있었습니다. OADP-1822

Cloud Storage API BSL에 OwnerReference 필요

이전 릴리스에서 ACM BackupSchedules는 dpa.spec.backupLocations.bucket 으로 생성된 백업 스토리지 위치(BSL)에서 누락된 OwnerReference 로 인해 검증에 실패했습니다. OADP-1511

이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.1.4 해결 문제 목록을 참조하십시오.

4.2.3.5.3. 확인된 문제
링크 복사

이 릴리스에는 다음과 같은 알려진 문제가 있습니다.

클러스터에서 UID/GID 범위가 변경될 수 있으므로 OADP 백업이 실패할 수 있습니다.

OADP 백업은 애플리케이션이 복원된 클러스터에서 UID/GID 범위가 변경될 수 있기 때문에 실패할 수 있으며, OADP가 OpenShift Container Platform UID/GID 범위 메타데이터를 백업하지 않고 복원하지 않습니다. 문제를 방지하려면 백업 애플리케이션에 특정 UUID가 필요한 경우 복원 시 범위를 사용할 수 있는지 확인하십시오. 추가 해결 방법은 OADP가 복원 작업에 네임스페이스를 생성하도록 허용하는 것입니다.

ArgoCD에서 사용하는 레이블로 인해 프로세스 중에 ArgoCD를 사용하는 경우 복원이 실패할 수 있습니다.

ArgoCD, app.kubernetes.io/instance 에서 사용하는 레이블로 인해 프로세스 중에 ArgoCD를 사용하는 경우 복원이 실패할 수 있습니다. 이 레이블은 ArgoCD를 관리해야 하는 리소스를 식별하여 복원 시 리소스를 관리하는 OADP 절차와 충돌을 생성할 수 있습니다. 이 문제를 해결하려면 ArgoCD YAML에서 .spec.resource>-<ingMethod 를 annotation+label 또는 주석 으로 설정합니다. 문제가 계속되면 복원을 시작하기 전에 ArgoCD를 비활성화하고 복원이 완료되면 다시 활성화합니다.

OADP Velero 플러그인 반환 "Received EOF, stop recv loop" 메시지

Velero 플러그인은 별도의 프로세스로 시작됩니다. Velero 작업이 완료되면 해당 작업이 성공적으로 종료됩니다. 따라서 디버그 로그에서 recv 루프 메시지를 중지하는 EOF가 수신되면 오류가 발생하지 않습니다. 이 메시지는 플러그인 작업이 완료되었음을 나타냅니다. OADP-2176

이 릴리스에서 알려진 모든 문제의 전체 목록은 Jira의 OADP 1.1.4 알려진 문제 목록을 참조하십시오.

4.2.3.6. OADP 1.1.3 릴리스 노트
링크 복사

OADP 1.1.3 릴리스 노트에는 새로운 기능, 해결된 문제 및 버그, 알려진 문제가 나열되어 있습니다.

4.2.3.6.1. 새로운 기능
링크 복사

이 버전의 OADP는 서비스 릴리스입니다. 이 버전에는 새로운 기능이 추가되지 않습니다.

4.2.3.6.2. 해결된 문제
링크 복사

이 릴리스에서 해결된 모든 문제의 전체 목록은 Jira의 OADP 1.1.3 해결 문제 목록을 참조하십시오.

4.2.3.6.3. 확인된 문제
링크 복사

이 릴리스에서 알려진 모든 문제의 전체 목록은 Jira의 OADP 1.1.3 알려진 문제 목록을 참조하십시오.

4.2.3.7. OADP 1.1.2 릴리스 노트
링크 복사

OADP 1.1.2 릴리스 노트에는 제품 권장 사항, 수정된 버그 목록 및 알려진 문제에 대한 설명이 포함되어 있습니다.

4.2.3.7.1. 제품 권장 사항
링크 복사

VolSync

IKEvSync 0.5.1에서 dess stable 채널에서 사용 가능한 최신 버전으로 업그레이드를 준비하려면 다음 명령을 실행하여 openshift-adp 네임스페이스에 이 주석을 추가해야 합니다. 

$ oc annotate --overwrite namespace/openshift-adp volsync.backube/privileged-movers='true'
Copy to Clipboard Toggle word wrap

Velero

이번 릴리스에서는 Velero가 버전 1.9.2에서 버전 1.9.5 로 업그레이드되었습니다.

Restic

이번 릴리스에서는 Restic이 버전 0.13.1에서 버전 0.14.0 으로 업그레이드되었습니다.

4.2.3.7.2. 해결된 문제
링크 복사

이번 릴리스에서는 다음 문제가 해결되었습니다.

4.2.3.7.3. 확인된 문제
링크 복사

이 릴리스에는 다음과 같은 알려진 문제가 있습니다.

  • OADP는 현재 Velero의 restic (OADP-778)을 사용하여 AWS EFS 볼륨의 백업 및 복원을 지원하지 않습니다.

  • PVC당 VolumeSnapshotContent 스냅샷의 Ceph 제한으로 인해 CSI 백업이 실패할 수 있습니다.

    동일한 PVC(영구 볼륨 클레임)의 스냅샷을 여러 개 생성할 수 있지만 스냅샷의 주기적 생성은 예약할 수 없습니다.

    • CephFS의 경우 PVC당 최대 100개의 스냅샷을 생성할 수 있습니다. (OADP-804)
    • RADOS 블록 장치(RBD)의 경우 각 PVC에 대해 최대 512개의 스냅샷을 생성할 수 있습니다. (OADP-975)

    자세한 내용은 볼륨 스냅샷 을 참조하십시오.

4.2.3.8. OADP 1.1.1 릴리스 노트
링크 복사

OADP 1.1.1 릴리스 노트에는 제품 권장 사항 및 알려진 문제에 대한 설명이 포함되어 있습니다.

4.2.3.8.1. 제품 권장 사항
링크 복사

OADP 1.1.1를 설치하기 전에ECDHESync 0.5.1을 설치하거나 업그레이드 하는 것이 좋습니다.

4.2.3.8.2. 확인된 문제
링크 복사

이 릴리스에는 다음과 같은 알려진 문제가 있습니다.

  • 여러 HTTP/2가 활성화된 웹 서버는 DDoS 공격(Rapid Reset Attack)에 취약합니다.

    요청 취소가 여러 스트림을 빠르게 재설정할 수 있으므로 HTTP/2 프로토콜은 서비스 거부 공격에 취약합니다. 서버는 스트림을 설정하고 해체해야 하지만 연결당 최대 활성 스트림 수에 대한 서버 측 제한에 도달하지 않아야 합니다. 이로 인해 서버 리소스 사용량으로 인해 서비스 거부가 발생합니다. 이 CVE와 관련된 모든 OADP 문제 목록은 다음 Jira 목록을 참조하십시오.

    이 문제를 해결하려면 OADP 1.1.7 또는 1.2.3으로 업그레이드하는 것이 좋습니다.

    자세한 내용은 CVE-2023-39325 (Rapid Reset Attack) 를 참조하십시오.

  • OADP는 현재 Velero의 restic (OADP-778)을 사용하여 AWS EFS 볼륨의 백업 및 복원을 지원하지 않습니다.

  • PVC당 VolumeSnapshotContent 스냅샷의 Ceph 제한으로 인해 CSI 백업이 실패할 수 있습니다.

    동일한 PVC(영구 볼륨 클레임)의 스냅샷을 여러 개 생성할 수 있지만 스냅샷의 주기적 생성은 예약할 수 없습니다.

    • CephFS의 경우 PVC당 최대 100개의 스냅샷을 생성할 수 있습니다.

    • RADOS 블록 장치(RBD)의 경우 각 PVC에 대해 최대 512개의 스냅샷을 생성할 수 있습니다. (OADP-804) 및 (OADP-975)

      자세한 내용은 볼륨 스냅샷 을 참조하십시오.

4.3. OADP 기능 및 플러그인
링크 복사

OADP(OpenShift API for Data Protection) 기능은 애플리케이션을 백업하고 복원하는 옵션을 제공합니다.

기본 플러그인을 사용하면 Velero가 특정 클라우드 공급자와 통합하고 OpenShift Container Platform 리소스를 백업 및 복원할 수 있습니다.

4.3.1. OADP 기능
링크 복사

OADP(OpenShift API for Data Protection)는 다음과 같은 기능을 지원합니다.

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.3.2. OADP 플러그인
링크 복사

OADP(OpenShift API for Data Protection)는 백업 및 스냅샷 작업을 지원하기 위해 스토리지 공급자와 통합된 기본 Velero 플러그인을 제공합니다. Velero 플러그인을 기반으로 사용자 지정 플러그인 을 생성할 수 있습니다.

OADP는 OpenShift Container Platform 리소스 백업, OpenShift Virtualization 리소스 백업 및 CSI(Container Storage Interface) 스냅샷에 대한 플러그인도 제공합니다.

Expand
표 4.1. OADP 플러그인
OADP 플러그인함수스토리지 위치

AWS

Kubernetes 오브젝트를 백업하고 복원합니다.

AWS S3

스냅샷을 사용하여 볼륨을 백업 및 복원합니다.

AWS EBS

azure

Kubernetes 오브젝트를 백업하고 복원합니다.

Microsoft Azure Blob 스토리지

스냅샷을 사용하여 볼륨을 백업 및 복원합니다.

Microsoft Azure 관리형 디스크

gcp

Kubernetes 오브젝트를 백업하고 복원합니다.

Google Cloud Storage

스냅샷을 사용하여 볼륨을 백업 및 복원합니다.

Google Compute Engine 디스크

openshift

OpenShift Container Platform 리소스를 백업하고 복원합니다. [1]

오브젝트 저장소

kubevirt

OpenShift Virtualization 리소스를 백업하고 복원합니다. [2]

오브젝트 저장소

csi

CSI 스냅샷을 사용하여 볼륨을 백업 및 복원합니다. [3]

CSI 스냅샷을 지원하는 클라우드 스토리지

vsm

VolumeSnapshotMover는 클러스터 삭제와 같은 상황에서 상태 저장 애플리케이션을 복구하는 동안 사용할 스냅샷을 클러스터에서 오브젝트 저장소로 재배치합니다. [4]

오브젝트 저장소

  1. 필수 항목입니다.
  2. 가상 머신 디스크는 CSI 스냅샷 또는 Restic을 사용하여 백업됩니다.

  3. csi 플러그인은 Kubernetes CSI 스냅샷 API를 사용합니다.

    • OADP 1.1 이상에서는 snapshot.storage.k8s.io/v1을 사용합니다.
    • OADP 1.0 uses snapshot.storage.k8s.io/v1beta1
  4. OADP 1.2만 해당

4.3.3. OADP Velero 플러그인 정보
링크 복사

Velero를 설치할 때 다음 두 가지 유형의 플러그인을 구성할 수 있습니다.

  • 기본 클라우드 공급자 플러그인
  • 사용자 정의 플러그인

두 가지 유형의 플러그인은 모두 선택 사항이지만 대부분의 사용자는 하나 이상의 클라우드 공급자 플러그인을 구성합니다.

4.3.3.1. 기본 Velero 클라우드 공급자 플러그인
링크 복사

배포 중에 oadp_v1alpha1_dpa.yaml 파일을 구성할 때 다음과 같은 기본 Velero 클라우드 공급자 플러그인을 설치할 수 있습니다.

  • AWS (Amazon Web Services)
  • GCP (Google Cloud Platform)
  • azure (Microsoft Azure)
  • OpenShift (OpenShift Velero 플러그인)
  • CSI (컨테이너 스토리지 인터페이스)
  • Kube Virt(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
Copy to Clipboard Toggle word wrap
4.3.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
Copy to Clipboard Toggle word wrap
4.3.3.3. Velero 플러그인에서 "received EOF, stop recv loop" 메시지를 반환
링크 복사
참고

Velero 플러그인은 별도의 프로세스로 시작됩니다. Velero 작업이 성공적으로 완료되거나 실패하면 종료됩니다. 디버그 로그에서 recv 루프 메시지를 중지하여 수신된 EOF 를 수신하면 플러그인 작업이 완료되었음을 나타냅니다. 이는 오류가 발생했음을 의미하지 않습니다.

4.3.4. OADP에서 지원되는 아키텍처
링크 복사

OADP(OpenShift API for Data Protection)는 다음과 같은 아키텍처를 지원합니다.

  • AMD64
  • ARM64
  • PPC64le
  • s390x
참고

OADP 1.2.0 이상 버전은 ARM64 아키텍처를 지원합니다.

4.3.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.3.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.3.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.3.6. OADP 플러그인의 알려진 문제
링크 복사

다음 섹션에서는 OADP(OpenShift API for Data Protection) 플러그인의 알려진 문제에 대해 설명합니다.

백업 및 백업 스토리지 위치(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…
Copy to Clipboard Toggle word wrap
4.3.6.1.1. 패닉 오류를 방지하기 위한 해결방법
링크 복사

Velero 플러그인 패닉 오류를 방지하려면 다음 단계를 수행합니다.

  1. 관련 라벨을 사용하여 사용자 지정 BSL에 레이블을 지정합니다. 

    $ oc label BackupStorageLocation <bsl_name> app.kubernetes.io/component=bsl
    Copy to Clipboard Toggle word wrap

  2. BSL 레이블이 지정된 후 DPA가 조정될 때까지 기다립니다.

    참고

    DPA 자체를 약간 변경하여 강제로 조정할 수 있습니다.

  3. 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'
    Copy to Clipboard Toggle word wrap
4.3.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.3.6.2.1. OpenShift ADP 컨트롤러 분할 오류 해결
링크 복사

DPA를 구성할 때 velero 또는 cloudstorage 를 정의해야 합니다. DPA에 두 API를 모두 정의하면 크래시 루프 분할 오류와 함께 openshift-adp-controller-manager Pod가 실패합니다.

4.4. OADP 설치 및 구성
링크 복사

4.4.1. OADP 설치 정보
링크 복사

클러스터 관리자는 OADP Operator를 설치하여 OADP(Data Protection)용 OpenShift API를 설치합니다. OADP Operator는 Velero 1.12 를 설치합니다.

참고

OADP 1.0.4부터 모든 OADP 1.0.z 버전은 MTC Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.

Kubernetes 리소스 및 내부 이미지를 백업하려면 다음 스토리지 유형 중 하나와 같은 오브젝트 스토리지를 백업 위치로 보유해야 합니다.

개별 OADP 배포에 대해 동일한 네임스페이스 내에서 여러 백업 스토리지 위치를 구성할 수 있습니다.

참고

달리 지정하지 않는 한 "NooBa"는 경량 오브젝트 스토리지를 제공하는 오픈 소스 프로젝트를 나타내며 "MCG(Multicloud Object Gateway)는 NooBaa의 Red Hat 배포를 나타냅니다.

MCG에 대한 자세한 내용은 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.

중요

개체 스토리지의 버킷 생성을 자동화하는 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

스냅샷 또는 Restic을 사용하여 PV(영구 볼륨)를 백업할 수 있습니다.

스냅샷을 사용하여 PV를 백업하려면 다음 클라우드 공급자 중 하나와 같은 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원하는 클라우드 공급자가 있어야 합니다.

참고

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인 경우 오브젝트 스토리지에서 Restic 백업을 사용하여 애플리케이션을 백업할 수 있습니다.

기본 보안을 생성한 다음 데이터 보호 애플리케이션을 설치합니다.

4.4.1.1. AWS S3 호환 백업 스토리지 공급자
링크 복사

OADP는 다양한 백업 및 스냅샷 작업에 사용하기 위해 많은 오브젝트 스토리지 공급자와 호환됩니다. 여러 오브젝트 스토리지 공급자가 완전히 지원되며, 일부 오브젝트 스토리지 공급자는 지원되지만 작동하지 않으며 일부에는 알려진 제한 사항이 있습니다.

4.4.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)
참고

다음과 같은 호환 오브젝트 스토리지 공급자가 지원되며 자체 Velero 오브젝트 저장소 플러그인이 있습니다.

  • GCP(Google Cloud Platform)
  • Microsoft Azure
4.4.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.4.1.1.3. 알려진 제한이 있는 백업 스토리지 공급자
링크 복사

다음 AWS S3 호환 오브젝트 스토리지 공급자는 제한된 기능 세트로 AWS 플러그인을 통해 Velero와 함께 작동하는 것으로 알려져 있습니다.

  • Swift - 백업 스토리지의 백업 스토리지 위치로 사용하기 위해 작동하지만 파일 시스템 기반 볼륨 백업 및 복원에는 Restic과 호환되지 않습니다.

OpenShift Data Foundation에서 MCG 버킷 backupStorageLocation 에 클러스터 스토리지를 사용하는 경우 MCG를 외부 오브젝트 저장소로 구성합니다.

주의

MCG를 외부 오브젝트 저장소로 구성하지 않으면 백업을 사용할 수 없게 될 수 있습니다.

참고

달리 지정하지 않는 한 "NooBa"는 경량 오브젝트 스토리지를 제공하는 오픈 소스 프로젝트를 나타내며 "MCG(Multicloud Object Gateway)는 NooBaa의 Red Hat 배포를 나타냅니다.

MCG에 대한 자세한 내용은 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.

절차

4.4.1.3. OADP 업데이트 채널 정보
링크 복사

OADP Operator를 설치할 때 업데이트 채널을 선택합니다. 이 채널은 OADP Operator 및 수신하는 Velero에 대한 업그레이드를 결정합니다. 언제든지 채널을 변경할 수 있습니다.

다음 업데이트 채널을 사용할 수 있습니다.

  • stable 채널이 더 이상 사용되지 않습니다. stable 채널에는 OADP.v1.1.z 용 OADP ClusterServiceVersion 및 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로 업그레이드한 다음 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.4.1.4. 여러 네임스페이스에 OADP 설치
링크 복사

OADP를 동일한 클러스터의 여러 네임스페이스에 설치할 수 있으므로 여러 프로젝트 소유자가 자체 OADP 인스턴스를 관리할 수 있습니다. 이 사용 사례는 Restic 및 CSI에서 검증되었습니다.

다음 추가 요구 사항을 사용하여 이 문서에 포함된 플랫폼별 절차에 따라 OADP의 각 인스턴스를 설치합니다.

  • 동일한 클러스터에 있는 OADP의 모든 배포는 동일한 버전이어야 합니다(예: 1.1.4). 동일한 클러스터에 다른 버전의 OADP를 설치할 수 없습니다.
  • OADP의 개별 배포마다 고유한 인증 정보 세트 및 하나 이상의 BackupStorageLocation 구성이 있어야 합니다. 동일한 네임 스페이스 내에서 여러 BackupStorageLocation 구성을 사용할 수도 있습니다.
  • 기본적으로 각 OADP 배포에는 네임스페이스에서 클러스터 수준 액세스 권한이 있습니다. OpenShift Container Platform 관리자는 보안 및 RBAC 설정을 주의 깊게 검토하고 각 OADP 인스턴스에 올바른 권한이 있는지 확인하기 위해 필요한 사항을 변경해야 합니다.
4.4.1.5. 수집된 데이터를 기반으로 하는 Velero CPU 및 메모리 요구 사항
링크 복사

다음 권장 사항은 규모 및 성능 랩에서 수행된 성능 관찰을 기반으로 합니다. 백업 및 복원 리소스는 플러그인 유형, 해당 백업 또는 복원에 필요한 리소스 양, 해당 리소스와 관련된 PV(영구 볼륨)에 포함된 해당 데이터의 영향을 받을 수 있습니다.

4.4.1.5.1. 구성에 대한 CPU 및 메모리 요구 사항
링크 복사
Expand
구성 유형[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] DataMover

해당 없음

해당 없음

10m - 평균 사용량

60m - 대규모 사용

  1. 평균 사용량 - 대부분의 사용 상황에 대해 이러한 설정을 사용합니다.
  2. 대규모 사용 - 대규모 PV(500GB 사용), 다중 네임스페이스(100+) 또는 단일 네임스페이스(2000 pods+) 내의 여러 Pod 및 대규모 데이터 세트와 관련된 백업 및 복원을 위한 최적의 성능을 위해 이러한 설정을 사용합니다.
  3. Restic 리소스 사용량은 데이터 양 및 데이터 유형에 해당합니다. 예를 들어 많은 작은 파일 또는 대량의 데이터가 있으면 Restic이 대량의 리소스를 활용할 수 있습니다. Velero 문서는 500m을 제공된 기본값으로 참조합니다. 대부분의 테스트에서는 1000m 제한으로 적합한 200m 요청을 발견했습니다. Velero 문서에서 인용한 대로 정확한 CPU 및 메모리 사용은 환경 제한 외에도 파일 및 디렉터리의 크기에 따라 달라집니다.
  4. CPU를 늘리면 백업 및 복원 시간 개선에 큰 영향을 미칩니다.
  5. DataMover - DataMover 기본 리소스 제한 시간은 10m입니다. 테스트 결과 대규모 PV(500GB 사용량)를 복원하려면 resourceTimeout을 60m로 늘려야 합니다.
참고

가이드 전체에 나열된 리소스 요구 사항은 평균 사용량 전용입니다. 큰 용도의 경우 위의 표에 설명된 대로 설정을 조정합니다.

4.4.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
Copy to Clipboard Toggle word wrap

4.4.2. OADP Operator 설치
링크 복사

OLM(Operator Lifecycle Manager)을 사용하여 OpenShift Container Platform 4.12에 OADP(OpenShift API for Data Protection) Operator를 설치할 수 있습니다.

OADP Operator는 Velero 1.12 를 설치합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
  3. OADP Operator 를 선택하고 설치를 클릭합니다.
  4. openshift-adp 프로젝트에서 Operator를 설치하려면 설치를 클릭합니다.
  5. Operators → 설치된 Operators 를 클릭하여 설치를 확인합니다.
4.4.2.1. OADP-Velero-OpenShift Container Platform 버전 관계
링크 복사
Expand
OADP 버전Velero 버전OpenShift Container Platform 버전

1.1.0

1.9

4.9 이상

1.1.1

1.9

4.9 이상

1.1.2

1.9

4.9 이상

1.1.3

1.9

4.9 이상

1.1.4

1.9

4.9 이상

1.1.5

1.9

4.9 이상

1.1.6

1.9

4.11 이상

1.1.7

1.9

4.11 이상

1.2.0

1.11

4.11 이상

1.2.1

1.11

4.11 이상

1.2.2

1.11

4.11 이상

1.2.3

1.11

4.11 이상

1.3.0

1.12

4.10 - 4.15

1.3.1

1.12

4.10 - 4.15

1.3.2

1.12

4.10 - 4.15

1.3.3

1.12

4.10 - 4.15

4.4.3. Amazon Web Services를 사용하여 데이터 보호를 위한 OpenShift API 구성
링크 복사

OADP Operator를 설치하여 AWS(Amazon Web Services)에서 OADP(Data Protection)용 OpenShift API를 설치합니다. Operator는 Velero 1.12 를 설치합니다.

참고

OADP 1.0.4부터 모든 OADP 1.0.z 버전은 MTC Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.

Velero에 대해 AWS를 구성하고 기본 시크릿 을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.4.3.1. Amazon Web Services 구성
링크 복사

OADP(OpenShift API for Data Protection)에 대해 AWS(Amazon Web Services)를 구성합니다.

사전 요구 사항

  • AWS CLI가 설치되어 있어야 합니다.

절차

  1. BUCKET 변수를 설정합니다. 

    $ BUCKET=<your_bucket>
    Copy to Clipboard Toggle word wrap

  2. REGION 변수를 설정합니다. 

    $ REGION=<your_region>
    Copy to Clipboard Toggle word wrap

  3. AWS S3 버킷을 생성합니다. 

    $ aws s3api create-bucket \
    --bucket $BUCKET \
    --region $REGION \
    --create-bucket-configuration LocationConstraint=$REGION
    1
    Copy to Clipboard Toggle word wrap
    1
    us-east-1은 LocationConstraint를 지원하지 않습니다. 리전이 us-east-1인 경우 --create-bucket-configuration LocationConstraint=$REGION을 생략합니다.

  4. IAM 사용자를 생성합니다. 

    $ aws iam create-user --user-name velero
    1
    Copy to Clipboard Toggle word wrap
    1
    Velero를 사용하여 여러 S3 버킷이 있는 여러 클러스터를 백업하려면 각 클러스터에 대해 고유한 사용자 이름을 생성합니다.

  5. 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
    Copy to Clipboard Toggle word wrap

  6. 정책을 연결하여 velero 사용자에게 필요한 최소 권한을 부여합니다. 

    $ aws iam put-user-policy \
  --user-name velero \
  --policy-name velero \
  --policy-document file://velero-policy.json
    Copy to Clipboard Toggle word wrap

  7. velero 사용자에 대한 액세스 키를 생성합니다. 

    $ aws iam create-access-key --user-name velero
    Copy to Clipboard Toggle word wrap

    출력 예

    {
  "AccessKey": {
        "UserName": "velero",
        "Status": "Active",
        "CreateDate": "2017-07-31T22:24:41.576Z",
        "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
        "AccessKeyId": <AWS_ACCESS_KEY_ID>
  }
}
    Copy to Clipboard Toggle word wrap

  8. credentials-velero 파일을 만듭니다. 

    $ cat << EOF > ./credentials-velero
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
EOF
    Copy to Clipboard Toggle word wrap

    데이터 보호 애플리케이션을 설치하기 전에 credentials-velero 파일을 사용하여 AWS용 Secret 오브젝트를 생성합니다.

4.4.3.2. 백업 및 스냅샷 위치 및 보안 정보
링크 복사

DataProtectionApplication CR(사용자 정의 리소스)에서 백업 및 스냅샷 위치 및 해당 시크릿을 지정합니다.

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Ceph RADOS Gateway 또는 MinIO와 같은 백업 위치로 지정합니다.

Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.

스냅샷 위치

영구 볼륨을 백업하기 위해 클라우드 공급자의 네이티브 스냅샷 API를 사용하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.

CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass CR을 생성하기 때문에 스냅샷 위치를 지정할 필요가 없습니다.

Restic을 사용하는 경우 Restic이 개체 스토리지의 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

백업 및 스냅샷 위치가 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 시크릿 을 생성합니다.

백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.

  • DataProtectionApplication CR에서 지정하는 백업 위치에 대한 사용자 정의 시크릿 입니다.
  • DataProtectionApplication CR에서 참조되지 않는 스냅샷 위치에 대한 기본 시크릿 입니다.
중요

데이터 보호 애플리케이션에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다.

설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다.

4.4.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
    Copy to Clipboard Toggle word wrap

Secret 은 데이터 보호 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조합니다.

4.4.3.2.2. 다양한 인증 정보에 대한 프로필 생성
링크 복사

백업 및 스냅샷 위치에 다른 인증 정보를 사용하는 경우 credentials-velero 파일에 별도의 프로필을 생성합니다.

그런 다음 Secret 오브젝트를 생성하고 DataProtectionApplication CR(사용자 정의 리소스)에서 프로필을 지정합니다.

절차

  1. 다음 예제와 같이 백업 및 스냅샷 위치에 대한 별도의 프로필을 사용하여 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>
    Copy to Clipboard Toggle word wrap

  2. credentials-velero 파일을 사용하여 Secret 오브젝트를 생성합니다. 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    1
    Copy to Clipboard Toggle word wrap

  3. 다음 예와 같이 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"
    Copy to Clipboard Toggle word wrap
4.4.3.3. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.

4.4.3.3.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

사전 요구 사항

  • OADP(OpenShift API for 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
    Copy to Clipboard Toggle word wrap
    1 1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.

nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.

4.4.3.3.2. 자체 서명 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 개체 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

사전 요구 사항

  • OADP(OpenShift API for 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 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.4.3.4. 데이터 보호 애플리케이션 설치
링크 복사

Data ProtectionApplication API 인스턴스를 만들어 DPA(Data Protection Application)를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 자격 증명을 사용하는 경우 기본 이름 cloud-credentials 를 사용하여 Secret 을 생성해야 합니다.

  • 백업 및 스냅샷 위치에 다른 인증 정보를 사용하는 경우 백업 및 스냅샷 위치 자격 증명에 대한 별도의 프로필이 포함된 기본 이름 cloud-credentials 를 사용하여 Secret 을 생성해야 합니다.

    참고

    설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 보안이 없으면 설치에 실패합니다.

    참고

    Velero는 기본 백업 리포지토리 암호가 포함된 OADP 네임스페이스에 velero-repo-credentials 라는 시크릿을 생성합니다. 백업 리포지토리를 대상으로 하는 첫 번째 백업을 실행하기 전에 base64로 인코딩된 고유한 암호로 시크릿을 업데이트할 수 있습니다. 업데이트할 키의 값은 Data[repository-password] 입니다.

    DPA를 생성한 후 백업 리포지토리를 대상으로 하는 백업을 처음 실행하면 Velero에서 시크릿이 기본 암호 또는 교체한 암호가 포함된 velero-repo-credentials 인 백업 리포지토리를 생성합니다. 첫 번째 백업 후 시크릿 암호를 업데이트하면 새 암호가 velero-repo-credentials 의 암호와 일치하지 않으므로 Velero는 이전 백업과 연결할 수 없습니다.

절차

  1. Operators → 설치된 Operator 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - openshift
    1 
    
        - aws
      resourceTimeout: 10m
    2 
    
    restic:
      enable: true
    3 
    
      podConfig:
        nodeSelector: <node_selector>
    4 
    
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket_name>
    5 
    
          prefix: <prefix>
    6 
    
        config:
          region: <region>
          profile: "default"
        credential:
          key: cloud
          name: cloud-credentials
    7 
    
  snapshotLocations:
    8 
    
    - velero:
        provider: aws
        config:
          region: <region>
    9 
    
          profile: "default"
    Copy to Clipboard Toggle word wrap
    1
    openshift 플러그인은 필수입니다.
    2
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    3
    Restic 설치를 비활성화하려면 이 값을 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, Restic pod는 각 작업 노드에서 실행됩니다. OADP 버전 1.2 이상에서는 Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 백업에 대해 Restic을 구성할 수 있습니다. OADP 버전 1.1에서 Backup CR에 spec.defaultVolumesToRestic: true 를 추가합니다.
    4
    Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Restic은 모든 노드에서 실행됩니다.
    5
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업용 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    6
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
    7
    생성한 Secret 오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본 이름 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
    8
    CSI 스냅샷 또는 Restic을 사용하여 PV를 백업하지 않는 한 스냅샷 위치를 지정합니다.
    9
    스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-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

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   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
    Copy to Clipboard Toggle word wrap

4.4.3.4.1. 노드 에이전트 및 노드 라벨 구성
링크 복사

OADP의 DPA는 nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.

지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다. 

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
Copy to Clipboard Toggle word wrap

노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector 에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다. 

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""
Copy to Clipboard Toggle word wrap

다음 예제는 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: ""
Copy to Clipboard Toggle word wrap
4.4.3.4.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
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.

4.4.4. Microsoft Azure를 사용하여 데이터 보호를 위한 OpenShift API 구성
링크 복사

OADP Operator를 설치하여 Microsoft Azure와 함께 OADP(Data Protection)용 OpenShift API를 설치합니다. Operator는 Velero 1.12 를 설치합니다.

참고

OADP 1.0.4부터 모든 OADP 1.0.z 버전은 MTC Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.

Velero에 대해 Azure를 구성하고 기본 시크릿 을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.4.4.1. Microsoft Azure 구성
링크 복사

OADP(OpenShift API for Data Protection)에 대해 Microsoft Azure를 구성합니다.

사전 요구 사항

  • Azure CLI가 설치되어 있어야 합니다.

Azure 서비스를 사용하는 툴에는 항상 Azure 리소스가 안전한지 확인하기 위해 제한된 권한이 있어야 합니다. 따라서 애플리케이션이 완전히 권한이 있는 사용자로 로그인하는 대신 Azure는 서비스 주체를 제공합니다. Azure 서비스 주체는 애플리케이션, 호스팅 서비스 또는 자동화된 도구와 함께 사용할 수 있는 이름입니다.

이 ID는 리소스에 대한 액세스에 사용됩니다.

  • 서비스 주체 생성
  • 서비스 주체 및 암호를 사용하여 로그인
  • 서비스 주체 및 인증서를 사용하여 로그인
  • 서비스 주체 역할 관리
  • 서비스 주체를 사용하여 Azure 리소스 생성
  • 서비스 주체 인증 정보 재설정

자세한 내용은 Azure CLI를 사용하여 Azure 서비스 주체 만들기를 참조하십시오.

4.4.4.2. 백업 및 스냅샷 위치 및 보안 정보
링크 복사

DataProtectionApplication CR(사용자 정의 리소스)에서 백업 및 스냅샷 위치 및 해당 시크릿을 지정합니다.

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Ceph RADOS Gateway 또는 MinIO와 같은 백업 위치로 지정합니다.

Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.

스냅샷 위치

영구 볼륨을 백업하기 위해 클라우드 공급자의 네이티브 스냅샷 API를 사용하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.

CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass CR을 생성하기 때문에 스냅샷 위치를 지정할 필요가 없습니다.

Restic을 사용하는 경우 Restic이 개체 스토리지의 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

백업 및 스냅샷 위치가 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 시크릿 을 생성합니다.

백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.

  • DataProtectionApplication CR에서 지정하는 백업 위치에 대한 사용자 정의 시크릿 입니다.
  • DataProtectionApplication CR에서 참조되지 않는 스냅샷 위치에 대한 기본 시크릿 입니다.
중요

데이터 보호 애플리케이션에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다.

설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다.

4.4.4.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
    Copy to Clipboard Toggle word wrap

Secret 은 데이터 보호 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조합니다.

4.4.4.2.2. 다른 인증 정보의 보안 생성
링크 복사

백업 및 스냅샷 위치에 다른 인증 정보를 사용하는 경우 두 개의 Secret 오브젝트를 생성해야 합니다.

  • 사용자 지정 이름을 사용한 백업 위치 시크릿. 사용자 정의 이름은 DataProtectionApplication CR(사용자 정의 리소스)의 spec.backupLocations 블록에 지정됩니다.
  • 기본 이름 cloud-credentials-azure 인 스냅샷 위치 시크릿. 이 Secret 은 DataProtectionApplication CR에 지정되지 않습니다.

절차

  1. 클라우드 공급자에 적합한 형식으로 스냅샷 위치에 대한 자격 증명-velero 파일을 만듭니다.

  2. 기본 이름으로 스냅샷 위치에 대한 Secret 을 생성합니다. 

    $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap
  3. 오브젝트 스토리지의 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 만듭니다.

  4. 사용자 정의 이름으로 백업 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

  5. 다음 예와 같이 사용자 지정 이름이 있는 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
    Copy to Clipboard Toggle word wrap
    1
    사용자 정의 이름으로 백업 위치 시크릿.
4.4.4.3. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.

4.4.4.3.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

사전 요구 사항

  • OADP(OpenShift API for 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
    Copy to Clipboard Toggle word wrap
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.

nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.

4.4.4.3.2. 자체 서명 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 개체 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

사전 요구 사항

  • OADP(OpenShift API for 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 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.4.4.4. 데이터 보호 애플리케이션 설치
링크 복사

Data ProtectionApplication API 인스턴스를 만들어 DPA(Data Protection Application)를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 자격 증명을 사용하는 경우 기본 이름 cloud-credentials-azure 를 사용하여 Secret 을 생성해야 합니다.

  • 백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 시크릿 을 생성해야 합니다.

    • 백업 위치에 대한 사용자 지정 이름이 있는 시크릿 입니다. 이 보안을 DataProtectionApplication CR에 추가합니다.

    • 스냅샷 위치에 대한 기본 이름 cloud-credentials-azure 가 있는 시크릿 입니다. 이 보안 은 DataProtectionApplication CR에서 참조되지 않습니다.

      참고

      설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 보안이 없으면 설치에 실패합니다.

      참고

      Velero는 기본 백업 리포지토리 암호가 포함된 OADP 네임스페이스에 velero-repo-credentials 라는 시크릿을 생성합니다. 백업 리포지토리를 대상으로 하는 첫 번째 백업을 실행하기 전에 base64로 인코딩된 고유한 암호로 시크릿을 업데이트할 수 있습니다. 업데이트할 키의 값은 Data[repository-password] 입니다.

      DPA를 생성한 후 백업 리포지토리를 대상으로 하는 백업을 처음 실행하면 Velero에서 시크릿이 기본 암호 또는 교체한 암호가 포함된 velero-repo-credentials 인 백업 리포지토리를 생성합니다. 첫 번째 백업 후 시크릿 암호를 업데이트하면 새 암호가 velero-repo-credentials 의 암호와 일치하지 않으므로 Velero는 이전 백업과 연결할 수 없습니다.

절차

  1. Operators → 설치된 Operator 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - azure
        - openshift
    1 
    
      resourceTimeout: 10m
    2 
    
    restic:
      enable: true
    3 
    
      podConfig:
        nodeSelector: <node_selector>
    4 
    
  backupLocations:
    - velero:
        config:
          resourceGroup: <azure_resource_group>
    5 
    
          storageAccount: <azure_storage_account_id>
    6 
    
          subscriptionId: <azure_subscription_id>
    7 
    
          storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
        credential:
          key: cloud
          name: cloud-credentials-azure
    8 
    
        provider: azure
        default: true
        objectStorage:
          bucket: <bucket_name>
    9 
    
          prefix: <prefix>
    10 
    
  snapshotLocations:
    11 
    
    - velero:
        config:
          resourceGroup: <azure_resource_group>
          subscriptionId: <azure_subscription_id>
          incremental: "true"
        name: default
        provider: azure
    Copy to Clipboard Toggle word wrap
    1
    openshift 플러그인은 필수입니다.
    2
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    3
    Restic 설치를 비활성화하려면 이 값을 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, Restic pod는 각 작업 노드에서 실행됩니다. OADP 버전 1.2 이상에서는 Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 백업에 대해 Restic을 구성할 수 있습니다. OADP 버전 1.1에서 Backup CR에 spec.defaultVolumesToRestic: true 를 추가합니다.
    4
    Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Restic은 모든 노드에서 실행됩니다.
    5
    Azure 리소스 그룹을 지정합니다.
    6
    Azure 스토리지 계정 ID를 지정합니다.
    7
    Azure 서브스크립션 ID를 지정합니다.
    8
    이 값을 지정하지 않으면 기본 이름 cloud-credentials-azure 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
    9
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업용 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    10
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
    11
    PV를 백업하기 위해 CSI 스냅샷 또는 Restic을 사용하는 경우 스냅샷 위치를 지정할 필요가 없습니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-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

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   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
    Copy to Clipboard Toggle word wrap

4.4.4.4.1. 노드 에이전트 및 노드 라벨 구성
링크 복사

OADP의 DPA는 nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.

지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다. 

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
Copy to Clipboard Toggle word wrap

노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector 에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다. 

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""
Copy to Clipboard Toggle word wrap

다음 예제는 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: ""
Copy to Clipboard Toggle word wrap
4.4.4.4.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
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.

OADP Operator를 설치하여 GCP(Google Cloud Platform)에서 OADP(Data Protection)용 OpenShift API를 설치합니다. Operator는 Velero 1.12 를 설치합니다.

참고

OADP 1.0.4부터 모든 OADP 1.0.z 버전은 MTC Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.

Velero에 대한 GCP를 구성하고 기본 시크릿 을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.4.5.1. GCP(Google Cloud Platform) 구성
링크 복사

OADP(OpenShift API for Data Protection)에 대해 GCP(Google Cloud Platform)를 구성합니다.

사전 요구 사항

절차

  1. GCP에 로그인합니다. 

    $ gcloud auth login
    Copy to Clipboard Toggle word wrap

  2. BUCKET 변수를 설정합니다. 

    $ BUCKET=<bucket>
    1
    Copy to Clipboard Toggle word wrap
    1
    버킷 이름을 지정합니다.

  3. 스토리지 버킷을 생성합니다. 

    $ gsutil mb gs://$BUCKET/
    Copy to Clipboard Toggle word wrap

  4. PROJECT_ID 변수를 활성 프로젝트로 설정합니다. 

    $ PROJECT_ID=$(gcloud config get-value project)
    Copy to Clipboard Toggle word wrap

  5. 서비스 계정을 생성합니다. 

    $ gcloud iam service-accounts create velero \
    --display-name "Velero service account"
    Copy to Clipboard Toggle word wrap

  6. 서비스 계정을 나열합니다. 

    $ gcloud iam service-accounts list
    Copy to Clipboard Toggle word wrap

  7. email 값과 일치하도록 SERVICE_ACCOUNT_EMAIL 변수를 설정합니다. 

    $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
    --filter="displayName:Velero service account" \
    --format 'value(email)')
    Copy to Clipboard Toggle word wrap

  8. 정책을 연결하여 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
)
    Copy to Clipboard Toggle word wrap

  9. velero.server 사용자 정의 역할을 생성합니다. 

    $ gcloud iam roles create velero.server \
    --project $PROJECT_ID \
    --title "Velero Server" \
    --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
    Copy to Clipboard Toggle word wrap

  10. 프로젝트에 IAM 정책 바인딩을 추가합니다. 

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
    --role projects/$PROJECT_ID/roles/velero.server
    Copy to Clipboard Toggle word wrap

  11. IAM 서비스 계정을 업데이트합니다. 

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
    Copy to Clipboard Toggle word wrap

  12. IAM 서비스 계정 키를 현재 디렉터리의 credentials-velero 파일에 저장합니다. 

    $ gcloud iam service-accounts keys create credentials-velero \
    --iam-account $SERVICE_ACCOUNT_EMAIL
    Copy to Clipboard Toggle word wrap

    credentials-velero 파일을 사용하여 데이터 보호 애플리케이션을 설치하기 전에 GCP용 Secret 오브젝트를 생성합니다.

4.4.5.2. 백업 및 스냅샷 위치 및 보안 정보
링크 복사

DataProtectionApplication CR(사용자 정의 리소스)에서 백업 및 스냅샷 위치 및 해당 시크릿을 지정합니다.

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Ceph RADOS Gateway 또는 MinIO와 같은 백업 위치로 지정합니다.

Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.

스냅샷 위치

영구 볼륨을 백업하기 위해 클라우드 공급자의 네이티브 스냅샷 API를 사용하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.

CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass CR을 생성하기 때문에 스냅샷 위치를 지정할 필요가 없습니다.

Restic을 사용하는 경우 Restic이 개체 스토리지의 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

백업 및 스냅샷 위치가 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 시크릿 을 생성합니다.

백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.

  • DataProtectionApplication CR에서 지정하는 백업 위치에 대한 사용자 정의 시크릿 입니다.
  • DataProtectionApplication CR에서 참조되지 않는 스냅샷 위치에 대한 기본 시크릿 입니다.
중요

데이터 보호 애플리케이션에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다.

설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다.

4.4.5.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
    Copy to Clipboard Toggle word wrap

Secret 은 데이터 보호 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조합니다.

4.4.5.2.2. 다른 인증 정보의 보안 생성
링크 복사

백업 및 스냅샷 위치에 다른 인증 정보를 사용하는 경우 두 개의 Secret 오브젝트를 생성해야 합니다.

  • 사용자 지정 이름을 사용한 백업 위치 시크릿. 사용자 정의 이름은 DataProtectionApplication CR(사용자 정의 리소스)의 spec.backupLocations 블록에 지정됩니다.
  • 기본 이름 cloud-credentials-gcp 를 사용한 스냅샷 위치 시크릿. 이 Secret 은 DataProtectionApplication CR에 지정되지 않습니다.

절차

  1. 클라우드 공급자에 적합한 형식으로 스냅샷 위치에 대한 자격 증명-velero 파일을 만듭니다.

  2. 기본 이름으로 스냅샷 위치에 대한 Secret 을 생성합니다. 

    $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap
  3. 오브젝트 스토리지의 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 만듭니다.

  4. 사용자 정의 이름으로 백업 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

  5. 다음 예와 같이 사용자 지정 이름이 있는 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
    Copy to Clipboard Toggle word wrap
    1
    사용자 정의 이름으로 백업 위치 시크릿.
4.4.5.3. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.

4.4.5.3.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

사전 요구 사항

  • OADP(OpenShift API for 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
    Copy to Clipboard Toggle word wrap
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.

nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.

4.4.5.3.2. 자체 서명 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 개체 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

사전 요구 사항

  • OADP(OpenShift API for 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 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.4.5.4. 데이터 보호 애플리케이션 설치
링크 복사

Data ProtectionApplication API 인스턴스를 만들어 DPA(Data Protection Application)를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 자격 증명을 사용하는 경우 기본 이름 cloud-credentials-gcp 를 사용하여 Secret 을 생성해야 합니다.

  • 백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 시크릿 을 생성해야 합니다.

    • 백업 위치에 대한 사용자 지정 이름이 있는 시크릿 입니다. 이 보안을 DataProtectionApplication CR에 추가합니다.

    • 스냅샷 위치에 대한 기본 이름 cloud-credentials-gcp 가 있는 시크릿 입니다. 이 보안 은 DataProtectionApplication CR에서 참조되지 않습니다.

      참고

      설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 보안이 없으면 설치에 실패합니다.

      참고

      Velero는 기본 백업 리포지토리 암호가 포함된 OADP 네임스페이스에 velero-repo-credentials 라는 시크릿을 생성합니다. 백업 리포지토리를 대상으로 하는 첫 번째 백업을 실행하기 전에 base64로 인코딩된 고유한 암호로 시크릿을 업데이트할 수 있습니다. 업데이트할 키의 값은 Data[repository-password] 입니다.

      DPA를 생성한 후 백업 리포지토리를 대상으로 하는 백업을 처음 실행하면 Velero에서 시크릿이 기본 암호 또는 교체한 암호가 포함된 velero-repo-credentials 인 백업 리포지토리를 생성합니다. 첫 번째 백업 후 시크릿 암호를 업데이트하면 새 암호가 velero-repo-credentials 의 암호와 일치하지 않으므로 Velero는 이전 백업과 연결할 수 없습니다.

절차

  1. Operators → 설치된 Operator 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - gcp
        - openshift
    1 
    
      resourceTimeout: 10m
    2 
    
    restic:
      enable: true
    3 
    
      podConfig:
        nodeSelector: <node_selector>
    4 
    
  backupLocations:
    - velero:
        provider: gcp
        default: true
        credential:
          key: cloud
          name: cloud-credentials-gcp
    5 
    
        objectStorage:
          bucket: <bucket_name>
    6 
    
          prefix: <prefix>
    7 
    
  snapshotLocations:
    8 
    
    - velero:
        provider: gcp
        default: true
        config:
          project: <project>
          snapshotLocation: us-west1
    9
    Copy to Clipboard Toggle word wrap
    1
    openshift 플러그인은 필수입니다.
    2
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    3
    Restic 설치를 비활성화하려면 이 값을 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, Restic pod는 각 작업 노드에서 실행됩니다. OADP 버전 1.2 이상에서는 Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 백업에 대해 Restic을 구성할 수 있습니다. OADP 버전 1.1에서 Backup CR에 spec.defaultVolumesToRestic: true 를 추가합니다.
    4
    Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Restic은 모든 노드에서 실행됩니다.
    5
    이 값을 지정하지 않으면 기본 이름 cloud-credentials-gcp 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
    6
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업용 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    7
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
    8
    CSI 스냅샷 또는 Restic을 사용하여 PV를 백업하지 않는 한 스냅샷 위치를 지정합니다.
    9
    스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-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

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   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
    Copy to Clipboard Toggle word wrap

4.4.5.4.1. 노드 에이전트 및 노드 라벨 구성
링크 복사

OADP의 DPA는 nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.

지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다. 

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
Copy to Clipboard Toggle word wrap

노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector 에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다. 

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""
Copy to Clipboard Toggle word wrap

다음 예제는 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: ""
Copy to Clipboard Toggle word wrap
4.4.5.4.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
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.

OADP Operator를 설치하여 MCG(Multicloud Object Gateway)를 사용하여 OADP(Data Protection)용 OpenShift API를 설치합니다. Operator는 Velero 1.12 를 설치합니다.

참고

OADP 1.0.4부터 모든 OADP 1.0.z 버전은 MTC Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.

Multicloud Object Gateway 를 백업 위치로 구성합니다. MCG는 OpenShift Data Foundation의 구성 요소입니다. DataProtectionApplication CR(사용자 정의 리소스)에서 MCG를 백업 위치로 구성합니다.

중요

개체 스토리지의 버킷 생성을 자동화하는 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

백업 위치에 대한 시크릿 을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.4.6.1. 멀티 클라우드 오브젝트 게이트웨이 인증 정보 검색
링크 복사

OADP(데이터 보호)용 OpenShift API에 대한 Secret CR(사용자 정의 리소스)을 생성하려면 MCG(Multicloud Object Gateway) 인증 정보를 검색해야 합니다.

MCG는 OpenShift Data Foundation의 구성 요소입니다.

사전 요구 사항

절차

  1. NooBaa 사용자 정의 리소스에서 describe 명령을 실행하여 S3 끝점, AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY를 가져옵니다.

  2. credentials-velero 파일을 만듭니다. 

    $ cat << EOF > ./credentials-velero
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
EOF
    Copy to Clipboard Toggle word wrap

    credentials-velero 파일을 사용하여 데이터 보호 애플리케이션을 설치할 때 Secret 오브젝트를 생성합니다.

4.4.6.2. 백업 및 스냅샷 위치 및 보안 정보
링크 복사

DataProtectionApplication CR(사용자 정의 리소스)에서 백업 및 스냅샷 위치 및 해당 시크릿을 지정합니다.

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Ceph RADOS Gateway 또는 MinIO와 같은 백업 위치로 지정합니다.

Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.

스냅샷 위치

영구 볼륨을 백업하기 위해 클라우드 공급자의 네이티브 스냅샷 API를 사용하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.

CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass CR을 생성하기 때문에 스냅샷 위치를 지정할 필요가 없습니다.

Restic을 사용하는 경우 Restic이 개체 스토리지의 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

백업 및 스냅샷 위치가 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 시크릿 을 생성합니다.

백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.

  • DataProtectionApplication CR에서 지정하는 백업 위치에 대한 사용자 정의 시크릿 입니다.
  • DataProtectionApplication CR에서 참조되지 않는 스냅샷 위치에 대한 기본 시크릿 입니다.
중요

데이터 보호 애플리케이션에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다.

설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다.

4.4.6.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
    Copy to Clipboard Toggle word wrap

Secret 은 데이터 보호 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조합니다.

4.4.6.2.2. 다른 인증 정보의 보안 생성
링크 복사

백업 및 스냅샷 위치에 다른 인증 정보를 사용하는 경우 두 개의 Secret 오브젝트를 생성해야 합니다.

  • 사용자 지정 이름을 사용한 백업 위치 시크릿. 사용자 정의 이름은 DataProtectionApplication CR(사용자 정의 리소스)의 spec.backupLocations 블록에 지정됩니다.
  • 기본 이름 cloud-credentials 가 있는 스냅샷 위치 시크릿. 이 Secret 은 DataProtectionApplication CR에 지정되지 않습니다.

절차

  1. 클라우드 공급자에 적합한 형식으로 스냅샷 위치에 대한 자격 증명-velero 파일을 만듭니다.

  2. 기본 이름으로 스냅샷 위치에 대한 Secret 을 생성합니다. 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap
  3. 오브젝트 스토리지의 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 만듭니다.

  4. 사용자 정의 이름으로 백업 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

  5. 다음 예와 같이 사용자 지정 이름이 있는 Secret 을 DataProtectionApplication CR에 추가합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
...
  backupLocations:
    - velero:
        config:
          profile: "default"
          region: minio
          s3Url: <url>
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: aws
        default: true
        credential:
          key: cloud
          name:  <custom_secret>
    1 
    
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
    Copy to Clipboard Toggle word wrap
    1
    사용자 정의 이름으로 백업 위치 시크릿.
4.4.6.3. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.

4.4.6.3.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

사전 요구 사항

  • OADP(OpenShift API for 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
    Copy to Clipboard Toggle word wrap
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.

nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.

4.4.6.3.2. 자체 서명 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 개체 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

사전 요구 사항

  • OADP(OpenShift API for 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 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.4.6.4. 데이터 보호 애플리케이션 설치
링크 복사

Data ProtectionApplication API 인스턴스를 만들어 DPA(Data Protection Application)를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 자격 증명을 사용하는 경우 기본 이름 cloud-credentials 를 사용하여 Secret 을 생성해야 합니다.

  • 백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 시크릿 을 생성해야 합니다.

    • 백업 위치에 대한 사용자 지정 이름이 있는 시크릿 입니다. 이 보안을 DataProtectionApplication CR에 추가합니다.

    • 스냅샷 위치에 대한 기본 이름 cloud-credentials 가 있는 시크릿 입니다. 이 보안 은 DataProtectionApplication CR에서 참조되지 않습니다.

      참고

      설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 보안이 없으면 설치에 실패합니다.

      참고

      Velero는 기본 백업 리포지토리 암호가 포함된 OADP 네임스페이스에 velero-repo-credentials 라는 시크릿을 생성합니다. 백업 리포지토리를 대상으로 하는 첫 번째 백업을 실행하기 전에 base64로 인코딩된 고유한 암호로 시크릿을 업데이트할 수 있습니다. 업데이트할 키의 값은 Data[repository-password] 입니다.

      DPA를 생성한 후 백업 리포지토리를 대상으로 하는 백업을 처음 실행하면 Velero에서 시크릿이 기본 암호 또는 교체한 암호가 포함된 velero-repo-credentials 인 백업 리포지토리를 생성합니다. 첫 번째 백업 후 시크릿 암호를 업데이트하면 새 암호가 velero-repo-credentials 의 암호와 일치하지 않으므로 Velero는 이전 백업과 연결할 수 없습니다.

절차

  1. Operators → 설치된 Operator 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - aws
        - openshift
    1 
    
      resourceTimeout: 10m
    2 
    
    restic:
      enable: true
    3 
    
      podConfig:
        nodeSelector: <node_selector>
    4 
    
  backupLocations:
    - velero:
        config:
          profile: "default"
          region: minio
          s3Url: <url>
    5 
    
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: aws
        default: true
        credential:
          key: cloud
          name: cloud-credentials
    6 
    
        objectStorage:
          bucket: <bucket_name>
    7 
    
          prefix: <prefix>
    8
    Copy to Clipboard Toggle word wrap
    1
    openshift 플러그인은 필수입니다.
    2
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    3
    Restic 설치를 비활성화하려면 이 값을 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, Restic pod는 각 작업 노드에서 실행됩니다. OADP 버전 1.2 이상에서는 Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 백업에 대해 Restic을 구성할 수 있습니다. OADP 버전 1.1에서 Backup CR에 spec.defaultVolumesToRestic: true 를 추가합니다.
    4
    Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Restic은 모든 노드에서 실행됩니다.
    5
    S3 끝점의 URL을 지정합니다.
    6
    이 값을 지정하지 않으면 기본 이름 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
    7
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업용 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    8
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-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

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   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
    Copy to Clipboard Toggle word wrap

4.4.6.4.1. 노드 에이전트 및 노드 라벨 구성
링크 복사

OADP의 DPA는 nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.

지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다. 

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
Copy to Clipboard Toggle word wrap

노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector 에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다. 

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""
Copy to Clipboard Toggle word wrap

다음 예제는 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: ""
Copy to Clipboard Toggle word wrap
4.4.6.4.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
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.

4.4.7. OpenShift Data Foundation으로 데이터 보호를 위한 OpenShift API 구성
링크 복사

OADP Operator를 설치하고 백업 위치와 스냅샷 위치를 구성하여 OpenShift Data Foundation과 함께 OADP(Data Protection)용 OpenShift API를 설치합니다. 그런 다음 데이터 보호 애플리케이션을 설치합니다.

참고

OADP 1.0.4부터 모든 OADP 1.0.z 버전은 MTC Operator의 종속성으로만 사용할 수 있으며 독립 실행형 Operator로 사용할 수 없습니다.

Multicloud Object Gateway 또는 S3 호환 오브젝트 스토리지를 백업 위치로 구성할 수 있습니다.

중요

개체 스토리지의 버킷 생성을 자동화하는 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

백업 위치에 대한 시크릿 을 생성한 다음 데이터 보호 애플리케이션을 설치합니다. 자세한 내용은 OADP Operator 설치를 참조하십시오.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.4.7.1. 백업 및 스냅샷 위치 및 보안 정보
링크 복사

DataProtectionApplication CR(사용자 정의 리소스)에서 백업 및 스냅샷 위치 및 해당 시크릿을 지정합니다.

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Ceph RADOS Gateway 또는 MinIO와 같은 백업 위치로 지정합니다.

Velero는 OpenShift Container Platform 리소스, Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지의 아카이브 파일로 백업합니다.

스냅샷 위치

영구 볼륨을 백업하기 위해 클라우드 공급자의 네이티브 스냅샷 API를 사용하는 경우 클라우드 공급자를 스냅샷 위치로 지정해야 합니다.

CSI(Container Storage Interface) 스냅샷을 사용하는 경우 CSI 드라이버를 등록하기 위해 VolumeSnapshotClass CR을 생성하기 때문에 스냅샷 위치를 지정할 필요가 없습니다.

Restic을 사용하는 경우 Restic이 개체 스토리지의 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

백업 및 스냅샷 위치가 동일한 자격 증명을 사용하거나 스냅샷 위치가 필요하지 않은 경우 기본 시크릿 을 생성합니다.

백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 시크릿 오브젝트를 생성합니다.

  • DataProtectionApplication CR에서 지정하는 백업 위치에 대한 사용자 정의 시크릿 입니다.
  • DataProtectionApplication CR에서 참조되지 않는 스냅샷 위치에 대한 기본 시크릿 입니다.
중요

데이터 보호 애플리케이션에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다.

설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다.

4.4.7.1.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
    Copy to Clipboard Toggle word wrap

Secret 은 데이터 보호 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조합니다.

4.4.7.1.2. 다른 인증 정보의 보안 생성
링크 복사

백업 및 스냅샷 위치에 다른 인증 정보를 사용하는 경우 두 개의 Secret 오브젝트를 생성해야 합니다.

  • 사용자 지정 이름을 사용한 백업 위치 시크릿. 사용자 정의 이름은 DataProtectionApplication CR(사용자 정의 리소스)의 spec.backupLocations 블록에 지정됩니다.
  • 기본 이름 cloud-credentials 가 있는 스냅샷 위치 시크릿. 이 Secret 은 DataProtectionApplication CR에 지정되지 않습니다.

절차

  1. 클라우드 공급자에 적합한 형식으로 스냅샷 위치에 대한 자격 증명-velero 파일을 만듭니다.

  2. 기본 이름으로 스냅샷 위치에 대한 Secret 을 생성합니다. 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap
  3. 오브젝트 스토리지의 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 만듭니다.

  4. 사용자 정의 이름으로 백업 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

  5. 다음 예와 같이 사용자 지정 이름이 있는 Secret 을 DataProtectionApplication CR에 추가합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
...
  backupLocations:
    - velero:
        config:
          profile: "default"
          region: minio
          s3Url: <url>
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: gcp
        default: true
        credential:
          key: cloud
          name:  <custom_secret>
    1 
    
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
    Copy to Clipboard Toggle word wrap
    1
    사용자 정의 이름으로 백업 위치 시크릿.
4.4.7.2. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 설정하거나 자체 서명된 CA 인증서를 활성화하여 데이터 보호 애플리케이션을 구성할 수 있습니다.

4.4.7.2.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

사전 요구 사항

  • OADP(OpenShift API for 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
    Copy to Clipboard Toggle word wrap
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.

nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다. 지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.

다음 권장 사항은 규모 및 성능 랩에서 수행된 성능 관찰을 기반으로 합니다. 변경 사항은 특히 {odf-first}와 관련이 있습니다. {odf-short}로 작업하는 경우 공식 권장 사항은 적절한 튜닝 가이드를 참조하십시오.

4.4.7.2.1.1.1. 구성에 대한 CPU 및 메모리 요구 사항
링크 복사

백업 및 복원 작업에는 대량의 CephFS PersistentVolume (PV)이 필요합니다. 메모리 부족(OOM) 오류로 Ceph MDS Pod를 재시작하지 않으려면 다음 설정이 권장됩니다.

Expand
구성 유형요청최대 제한

CPU

3으로 변경됨

최대 제한 3

메모리

8Gi로 변경됨

최대 제한 128Gi

4.4.7.2.2. 자체 서명 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 개체 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

사전 요구 사항

  • OADP(OpenShift API for 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 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.4.7.3. 데이터 보호 애플리케이션 설치
링크 복사

Data ProtectionApplication API 인스턴스를 만들어 DPA(Data Protection Application)를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 자격 증명을 사용하는 경우 기본 이름 cloud-credentials 를 사용하여 Secret 을 생성해야 합니다.

  • 백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 시크릿 을 생성해야 합니다.

    • 백업 위치에 대한 사용자 지정 이름이 있는 시크릿 입니다. 이 보안을 DataProtectionApplication CR에 추가합니다.

    • 스냅샷 위치에 대한 기본 이름 cloud-credentials 가 있는 시크릿 입니다. 이 보안 은 DataProtectionApplication CR에서 참조되지 않습니다.

      참고

      설치 중에 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 보안이 없으면 설치에 실패합니다.

      참고

      Velero는 기본 백업 리포지토리 암호가 포함된 OADP 네임스페이스에 velero-repo-credentials 라는 시크릿을 생성합니다. 백업 리포지토리를 대상으로 하는 첫 번째 백업을 실행하기 전에 base64로 인코딩된 고유한 암호로 시크릿을 업데이트할 수 있습니다. 업데이트할 키의 값은 Data[repository-password] 입니다.

      DPA를 생성한 후 백업 리포지토리를 대상으로 하는 백업을 처음 실행하면 Velero에서 시크릿이 기본 암호 또는 교체한 암호가 포함된 velero-repo-credentials 인 백업 리포지토리를 생성합니다. 첫 번째 백업 후 시크릿 암호를 업데이트하면 새 암호가 velero-repo-credentials 의 암호와 일치하지 않으므로 Velero는 이전 백업과 연결할 수 없습니다.

절차

  1. Operators → 설치된 Operator 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - aws
        - openshift
    1 
    
      resourceTimeout: 10m
    2 
    
    restic:
      enable: true
    3 
    
      podConfig:
        nodeSelector: <node_selector>
    4 
    
  backupLocations:
    - velero:
        config:
          profile: "default"
          region: minio
          s3Url: <url>
    5 
    
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: gcp
        default: true
        credential:
          key: cloud
          name: cloud-credentials
    6 
    
        objectStorage:
          bucket: <bucket_name>
    7 
    
          prefix: <prefix>
    8
    Copy to Clipboard Toggle word wrap
    1
    openshift 플러그인은 필수입니다.
    2
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    3
    Restic 설치를 비활성화하려면 이 값을 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, Restic pod는 각 작업 노드에서 실행됩니다. OADP 버전 1.2 이상에서는 Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 백업에 대해 Restic을 구성할 수 있습니다. OADP 버전 1.1에서 Backup CR에 spec.defaultVolumesToRestic: true 를 추가합니다.
    4
    Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Restic은 모든 노드에서 실행됩니다.
    5
    S3 끝점의 URL을 지정합니다.
    6
    이 값을 지정하지 않으면 기본 이름 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
    7
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업용 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    8
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-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

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   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
    Copy to Clipboard Toggle word wrap

4.4.7.3.1. 노드 에이전트 및 노드 라벨 구성
링크 복사

OADP의 DPA는 nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.

지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다. 

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
Copy to Clipboard Toggle word wrap

노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector 에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다. 

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""
Copy to Clipboard Toggle word wrap

다음 예제는 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: ""
Copy to Clipboard Toggle word wrap

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 액세스를 참조하십시오.

절차

4.4.7.3.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
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.

4.5. OADP 설치 제거
링크 복사

4.5.1. 데이터 보호를 위한 OpenShift API 설치 제거
링크 복사

OADP Operator를 삭제하여 OADP(Data Protection)용 OpenShift API를 설치 제거합니다. 자세한 내용은 클러스터에서 Operator 삭제를 참조하십시오.

4.6. OADP 백업
링크 복사

4.6.1. 애플리케이션 백업
링크 복사

Backup CR(사용자 정의 리소스)을 생성하여 애플리케이션을 백업합니다. Backup CR 생성을 참조하십시오.

  • Backup CR은 S3 오브젝트 스토리지에 Kubernetes 리소스 및 내부 이미지에 대한 백업 파일을 생성합니다.
  • 클라우드 공급자에 기본 스냅샷 API가 있거나 CSI 스냅샷을 지원하는 경우 Backup CR은 스냅샷을 생성하여 PV(영구 볼륨)를 백업합니다. CSI 스냅샷 작업에 대한 자세한 내용은 CSI 스냅샷을 사용하여 영구 볼륨 백업을 참조하십시오.

CSI 볼륨 스냅샷에 대한 자세한 내용은 CSI 볼륨 스냅샷을 참조하십시오.

중요

S3 스토리지용 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

PodVolumeRestore가 …​/.snapshot: 읽기 전용 파일 시스템 오류로 인해 실패합니다.

…​/.snapshot 디렉터리는 여러 NFS 서버에서 사용하는 스냅샷 복사 디렉터리입니다. 이 디렉터리에는 기본적으로 읽기 전용 액세스 권한이 있으므로 Velero는 이 디렉터리로 복원할 수 없습니다.

.snapshot 디렉터리에 Velero 쓰기 액세스 권한을 부여하지 말고 이 디렉터리에 대한 클라이언트 액세스를 비활성화합니다.

중요

OADP(OpenShift API for Data Protection)는 다른 소프트웨어에 의해 생성된 볼륨 스냅샷 백업 기능을 지원하지 않습니다.

백업 작업 전이나 후에 명령을 실행하기 위해 백업 후크를 생성할 수 있습니다. 백업 후크 생성 을 참조하십시오.

Backup CR 대신 Schedule CR을 생성하여 백업을 예약할 수 있습니다. 스케줄 CR을 사용하여 백업 예약]을 참조하십시오.

4.6.1.1. 확인된 문제
링크 복사

OpenShift Container Platform 4.14는 Restic 복원 프로세스 중에 Pod 준비 상태를 방해할 수 있는 PSA(Pod 보안 승인) 정책을 적용합니다. 

이 문제는 OADP 1.1.6 및 OADP 1.2.2 릴리스에서 해결되어 사용자가 이러한 릴리스로 업그레이드하는 것이 좋습니다.

자세한 내용은 변경된 PSA 정책으로 인해 OCP 4.14에서 부분적으로 실패한 Restic 복원을 참조하십시오.

4.6.2. Backup CR 생성
링크 복사

Backup CR(사용자 정의 리소스)을 생성하여 Kubernetes 리소스, 내부 이미지 및 PV(영구 볼륨)를 백업 합니다.

사전 요구 사항

  • OADP(OpenShift API for Data Protection) Operator를 설치해야 합니다.
  • DataProtectionApplication CR은 Ready 상태여야 합니다.

  • 백업 위치 사전 요구 사항:

    • Velero용으로 S3 오브젝트 스토리지가 구성되어 있어야 합니다.
    • DataProtectionApplication CR에 백업 위치가 구성되어 있어야 합니다.

  • 스냅샷 위치 사전 요구 사항:

    • 클라우드 공급자에는 기본 스냅샷 API가 있거나 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
    • CSI 스냅샷의 경우 CSI 드라이버를 등록하려면 VolumeSnapshotClass CR을 생성해야 합니다.
    • DataProtectionApplication CR에 구성된 볼륨 위치가 있어야 합니다.

절차

  1. 다음 명령을 입력하여 backupStorageLocations CR을 검색합니다. 

    $ oc get backupStorageLocations -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
openshift-adp   velero-sample-1   Available   11s              31m
    Copy to Clipboard Toggle word wrap

  2. 다음 예와 같이 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
  labelSelector:
    5 
    
    matchLabels:
      app: <label_1>
      app: <label_2>
      app: <label_3>
  orLabelSelectors:
    6 
    
  - matchLabels:
      app: <label_1>
      app: <label_2>
      app: <label_3>
    Copy to Clipboard Toggle word wrap
    1
    백업할 네임스페이스의 배열을 지정합니다.
    2
    선택 사항: 백업에 포함할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: 'pods'의 경우 'po')이거나 정규화될 수 있습니다. 지정하지 않으면 모든 리소스가 포함됩니다.
    3
    선택 사항: 백업에서 제외할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: 'pods'의 경우 'po')이거나 정규화될 수 있습니다.
    4
    backupStorageLocations CR의 이름을 지정합니다.
    5
    지정된 라벨이 모두 있는 백업 리소스의 {key,value} 쌍의 맵입니다.
    6
    지정된 라벨이 하나 이상 있는 백업 리소스의 {key,value} 쌍의 맵입니다.

  3. Backup CR의 상태가 Completed 인지 확인합니다. 

    $ oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

4.6.3. CSI 스냅샷을 사용하여 영구 볼륨 백업
링크 복사

Backup CR을 생성하기 전에 클라우드 스토리지의 VolumeSnapshotClass CR(사용자 정의 리소스)을 편집하여 CSI(Container Storage Interface) 스냅샷을 사용하여 영구 볼륨을 백업 합니다. CSI 볼륨 스냅샷을 참조하십시오.

자세한 내용은 Backup CR 생성을 참조하십시오.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.
  • DataProtectionApplication CR에서 CSI를 활성화해야 합니다.

절차

  • metadata.labels.velero.io/csi-volumesnapshot-class: "true" 키-값 쌍을 VolumeSnapshotClass CR에 추가합니다. 

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: <volume_snapshot_class_name>
  labels:
    velero.io/csi-volumesnapshot-class: "true"
driver: <csi_driver>
deletionPolicy: Retain
    Copy to Clipboard Toggle word wrap

이제 Backup CR을 생성할 수 있습니다.

OADP를 사용하여 볼륨의 파일 시스템에서 Pod에 연결된 Kubernetes 볼륨을 백업하고 복원할 수 있습니다. 이 프로세스를 파일 시스템 백업(FSB) 또는 Pod 볼륨 백업(PVB)이라고 합니다. 이는 오픈 소스 백업 툴 Restic 또는 Kopia의 모듈을 사용하여 수행됩니다.

클라우드 공급자가 스냅샷을 지원하지 않거나 애플리케이션이 NFS 데이터 볼륨에 있는 경우 FSB를 사용하여 백업을 생성할 수 있습니다.

참고

Restic 은 기본적으로 OADP Operator에 의해 설치됩니다. 원하는 경우 Kopia 를 대신 설치할 수 있습니다.

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 제한 사항을 참조하십시오.

PodVolumeRestore가 …​/.snapshot: 읽기 전용 파일 시스템 오류로 인해 실패합니다.

…​/.snapshot 디렉터리는 여러 NFS 서버에서 사용하는 스냅샷 복사 디렉터리입니다. 이 디렉터리에는 기본적으로 읽기 전용 액세스 권한이 있으므로 Velero는 이 디렉터리로 복원할 수 없습니다.

.snapshot 디렉터리에 Velero 쓰기 액세스 권한을 부여하지 말고 이 디렉터리에 대한 클라이언트 액세스를 비활성화합니다.

사전 요구 사항

  • OADP(OpenShift API for Data Protection) Operator를 설치해야 합니다.
  • DataProtectionApplication CR에서 spec.configuration. nodeAgent.enable 을 false 로 설정하여 기본 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 
    
...
    Copy to Clipboard Toggle word wrap
    1
    OADP 버전 1.2 이상에서 spec 블록 내에 defaultVolumesToFsBackup: true 설정을 추가합니다. OADP 버전 1.1에서 defaultVolumesToRestic: true 를 추가합니다.

4.6.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 
    
...
    Copy to Clipboard Toggle word wrap
    1
    선택 사항: 후크가 적용되는 네임스페이스를 지정할 수 있습니다. 이 값을 지정하지 않으면 후크가 모든 네임스페이스에 적용됩니다.
    2
    선택 사항: 후크가 적용되지 않는 네임스페이스를 지정할 수 있습니다.
    3
    현재 Pod는 후크를 적용할 수 있는 유일한 지원 리소스입니다.
    4
    선택 사항: 후크가 적용되지 않는 리소스를 지정할 수 있습니다.
    5
    선택 사항: 이 후크는 레이블과 일치하는 오브젝트에만 적용됩니다. 이 값을 지정하지 않으면 후크가 모든 오브젝트에 적용됩니다.
    6
    백업 전에 실행할 후크 배열입니다.
    7
    선택 사항: 컨테이너를 지정하지 않으면 Pod의 첫 번째 컨테이너에서 명령이 실행됩니다.
    8
    추가되는 init 컨테이너의 진입점입니다.
    9
    오류 처리에 허용되는 값은 Fail 및 Continue 입니다. 기본값은 Fail 입니다.
    10
    선택 사항: 명령이 실행될 때까지 대기하는 시간입니다. 기본값은 30s 입니다.
    11
    이 블록은 백업 후 실행할 후크 배열과 pre-backup 후크와 동일한 매개변수를 정의합니다.

4.6.6. 스케줄 CR을 사용하여 백업 예약
링크 복사

schedule 작업을 사용하면 Cron 표현식에 지정된 특정 시간에 데이터 백업을 생성할 수 있습니다.

Backup CR 대신 Schedule CR(사용자 정의 리소스)을 생성하여 백업을 예약합니다.

주의

다른 백업이 생성되기 전에 백업이 완료될 수 있도록 백업 일정에 충분한 시간을 남겨 둡니다.

예를 들어 네임스페이스의 백업이 일반적으로 10분 정도 걸리는 경우 15분마다 백업을 더 자주 예약하지 마십시오.

사전 요구 사항

  • OADP(OpenShift API for Data Protection) Operator를 설치해야 합니다.
  • DataProtectionApplication CR은 Ready 상태여야 합니다.

절차

  1. backupStorageLocations CR을 검색합니다. 

    $ oc get backupStorageLocations -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
openshift-adp   velero-sample-1   Available   11s              31m
    Copy to Clipboard Toggle word wrap

  2. 다음 예와 같이 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
EOF
    Copy to Clipboard Toggle word wrap
1
백업을 예약하는 Cron 표현식(예: 0 7 * * * )은 7:00에 매일 백업을 수행합니다.
참고

특정 간격으로 백업을 예약하려면 다음 형식으로 &lt ;duration_in_minutes& gt;를 입력합니다. 

  schedule: "*/10 * * * *"
Copy to Clipboard Toggle word wrap

따옴표 사이에 분 값을 입력합니다(" ").

2
백업할 네임스페이스의 배열입니다.
3
backupStorageLocations CR의 이름입니다.
4
선택 사항: OADP 버전 1.2 이상에서 Restic을 사용하여 볼륨 백업을 수행할 때 defaultVolumesToFsBackup: true key-value 쌍을 구성에 추가합니다. OADP 버전 1.1에서 Restic을 사용하여 볼륨을 백업할 때 defaultVolumesToRestic: true key-value 쌍을 추가합니다.

  1. 예약된 백업이 실행된 후 Schedule CR의 상태가 Completed 인지 확인합니다. 

    $ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

4.6.7. 백업 삭제
링크 복사

Backup CR(사용자 정의 리소스)을 삭제하여 백업 파일을 제거할 수 있습니다.

주의

Backup CR 및 관련 오브젝트 스토리지 데이터를 삭제한 후에는 삭제된 데이터를 복구할 수 없습니다.

사전 요구 사항

  • 백업 CR을 생성했습니다.
  • Backup CR의 이름과 이를 포함하는 네임스페이스를 알고 있습니다.
  • Velero CLI 툴을 다운로드했습니다.
  • 클러스터에서 Velero 바이너리에 액세스할 수 있습니다.

절차

  • Backup CR을 삭제하려면 다음 작업 중 하나를 선택합니다.

    • Backup CR을 삭제하고 관련 오브젝트 스토리지 데이터를 유지하려면 다음 명령을 실행합니다. 

      $ oc delete backup <backup_CR_name> -n <velero_namespace>
      Copy to Clipboard Toggle word wrap

    • Backup CR을 삭제하고 관련 오브젝트 스토리지 데이터를 삭제하려면 다음 명령을 실행합니다. 

      $ velero backup delete <backup_CR_name> -n <velero_namespace>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <backup_CR_name>
      Backup 사용자 정의 리소스의 이름입니다.
      <velero_namespace>
      Backup 사용자 지정 리소스가 포함된 네임스페이스입니다.

4.6.8. Kopia 정보
링크 복사

Kopia는 데이터의 암호화된 스냅샷을 작성하고 선택한 원격 또는 클라우드 스토리지에 스냅샷을 저장할 수 있는 빠르고 안전한 오픈 소스 백업 및 복원 도구입니다.

Kopia는 네트워크 및 로컬 스토리지 위치와 다음을 포함한 많은 클라우드 또는 원격 스토리지 위치를 지원합니다.

  • Amazon S3 및 S3와 호환되는 모든 클라우드 스토리지
  • Azure Blob Storage
  • Google Cloud Storage 플랫폼

Kopia는 스냅샷을 위해 콘텐츠 주소 지정 가능 스토리지를 사용합니다.

  • 스냅샷은 항상 증분입니다. 이전 스냅샷에 이미 포함된 데이터는 리포지토리에 다시 업로드되지 않습니다. 파일은 수정된 경우에만 리포지토리에 업로드됩니다.
  • 저장된 데이터는 중복됩니다. 동일한 파일의 복사본이 여러 개 있으면 둘 중 하나만 저장됩니다.
  • 파일이 이동되거나 이름이 변경된 경우 Kopia는 동일한 콘텐츠가 있고 다시 업로드하지 않는다는 것을 인식할 수 있습니다.
4.6.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
# ...
Copy to Clipboard Toggle word wrap

4.7. OADP 복원
링크 복사

4.7.1. 애플리케이션 복원
링크 복사

Restore CR(사용자 정의 리소스)을 생성하여 애플리케이션 백업을 복원합니다. 복원 CR 생성을 참조하십시오.

Restore CR을 편집하여 Pod의 컨테이너에서 명령을 실행하기 위해 복원 후크를 생성할 수 있습니다. 복원 후크 생성 을 참조하십시오.

4.7.1.1. Restore CR 생성
링크 복사

Restore CR을 생성하여 Backup CR(사용자 정의 리소스)을 복원합니다.

사전 요구 사항

  • OADP(OpenShift API for Data Protection) Operator를 설치해야 합니다.
  • DataProtectionApplication CR은 Ready 상태여야 합니다.
  • Velero Backup CR이 있어야 합니다.
  • PV(영구 볼륨) 용량이 백업 시 요청된 크기와 일치해야 합니다. 필요한 경우 요청된 크기를 조정합니다.

절차

  1. 다음 예와 같이 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
    Copy to Clipboard Toggle word wrap
    1
    Backup CR의 이름입니다.
    2
    선택 사항: 복원 프로세스에 포함할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: Pod의 경우) 또는 정규화된일 수 있습니다. 지정하지 않으면 모든 리소스가 포함됩니다.
    3
    선택 사항: restorePVs 매개변수를 false 로 설정하여 VolumeSnapshot of Container Storage Interface(CSI) 스냅샷에서 PersistentVolumes 복원을 끄거나 VolumeSnapshotLocation 이 구성된 경우 기본 스냅샷에서 설정할 수 있습니다.

  2. 다음 명령을 입력하여 Restore CR의 상태가 Completed 인지 확인합니다. 

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 백업 리소스가 복원되었는지 확인합니다. 

    $ oc get all -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    백업한 네임스페이스입니다.

  4. Restic을 사용하여 DeploymentConfig 오브젝트를 복원하거나 post-restore 후크를 사용하는 경우 다음 명령을 입력하여 dc-restic-post-restore.sh cleanup 스크립트를 실행합니다. 

    $ bash dc-restic-post-restore.sh <restore-name>
    Copy to Clipboard Toggle word wrap
    참고

    복원 프로세스 중에 OADP Velero 플러그인은 DeploymentConfig 오브젝트를 축소하고 Pod를 독립 실행형 포드로 복원합니다. 이 작업은 클러스터가 복원 시 복원된 DeploymentConfig Pod를 즉시 삭제하고 Restic 및 복원 후 후크를 허용하여 복원된 Pod에서 작업을 완료하지 못하도록 하기 위해 수행됩니다. 아래에 표시된 정리 스크립트는 이러한 연결이 끊긴 Pod를 제거하고 적절한 복제본 수로 DeploymentConfig 오브젝트를 다시 확장합니다.

    예 4.1. dc-restic-post-restore.sh cleanup script

    #!/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}"
}

OADP_NAMESPACE=${OADP_NAMESPACE:=openshift-adp}

if [[ $# -ne 1 ]]; then
    echo "usage: ${BASH_SOURCE} restore-name"
    exit 1
fi

echo using OADP Namespace $OADP_NAMESPACE
echo restore: $1

label=$(label_name $1)
echo label: $label

echo Deleting disconnected restore pods
oc delete pods -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
    Copy to Clipboard Toggle word wrap
4.7.1.2. 복원 후크 생성
링크 복사

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
    Copy to Clipboard Toggle word wrap
    1
    선택 사항: 후크가 적용되는 네임스페이스 배열입니다. 이 값을 지정하지 않으면 후크가 모든 네임스페이스에 적용됩니다.
    2
    현재 Pod는 후크를 적용할 수 있는 유일한 지원 리소스입니다.
    3
    선택 사항: 이 후크는 라벨 선택기와 일치하는 오브젝트에만 적용됩니다.
    4
    선택 사항: 시간 초과는 Velero가 initContainers 가 완료될 때까지 대기하는 최대 시간을 지정합니다.
    5
    선택 사항: 컨테이너를 지정하지 않으면 Pod의 첫 번째 컨테이너에서 명령이 실행됩니다.
    6
    이는 추가되는 init 컨테이너의 진입점입니다.
    7
    선택 사항: 컨테이너가 준비될 때까지 대기하는 시간입니다. 컨테이너가 시작되고 동일한 컨테이너의 이전 후크가 완료될 때까지 충분히 길어야 합니다. 설정되지 않은 경우 복원 프로세스는 무기한 대기합니다.
    8
    선택 사항: 명령이 실행될 때까지 대기하는 시간입니다. 기본값은 30s 입니다.
    9
    오류 처리에 허용되는 값은 Fail and Continue 입니다.
    • continue: 명령 실패만 기록됩니다.
    • fail: Pod의 컨테이너에서 더 이상 복원 후크가 실행되지 않습니다. Restore CR의 상태는 PartiallyFailed 가 됩니다.

4.8. OADP 및 ROSA
링크 복사

4.8.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의 역할 및 정책 자격 증명을 설정해야 합니다.

이 프로세스는 다음 두 단계로 수행됩니다.

  1. AWS 인증 정보 준비
  2. OADP Operator를 설치하고 IAM 역할을 제공합니다.
4.8.1.1. OADP에 대한 AWS 인증 정보 준비
링크 복사

Amazon Web Services 계정은 OADP(OpenShift API for Data Protection) 설치를 허용하도록 준비하고 구성해야 합니다.

절차

  1. 다음 명령을 실행하여 다음 환경 변수를 생성합니다.

    중요

    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}"
    Copy to Clipboard Toggle word wrap
    1
    my-cluster 를 ROSA 클러스터 이름으로 교체합니다.

  2. AWS 계정에서 AWS S3에 대한 액세스를 허용하는 IAM 정책을 생성합니다.

    1. 다음 명령을 실행하여 정책이 존재하는지 확인합니다. 

      $ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaOadpVer1'].{ARN:Arn}" --output text)
      1
      Copy to Clipboard Toggle word wrap
      1
      RosaOadp 를 정책 이름으로 교체합니다.

    2. 다음 명령을 입력하여 정책 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
      Copy to Clipboard Toggle word wrap
      1
      SCRATCH 는 환경 변수에 대해 생성된 임시 디렉터리의 이름입니다.

    3. 다음 명령을 실행하여 정책 ARN을 확인합니다. 

      $ echo ${POLICY_ARN}
      Copy to Clipboard Toggle word wrap

  3. 클러스터에 대한 IAM 역할 신뢰 정책을 생성합니다.

    1. 다음 명령을 실행하여 신뢰 정책 파일을 생성합니다. 

      $ 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
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 역할을 생성합니다. 

      $ 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)
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하여 역할 ARN을 확인합니다. 

      $ echo ${ROLE_ARN}
      Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 IAM 역할에 IAM 정책을 연결합니다. 

    $ aws iam attach-role-policy --role-name "${ROLE_NAME}" \
  --policy-arn ${POLICY_ARN}
    Copy to Clipboard Toggle word wrap
4.8.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 인증 정보를 준비해야 합니다.

절차

  1. 다음 명령을 입력하여 AWS 토큰 파일에서 OpenShift Container Platform 시크릿을 생성합니다.

    1. 인증 정보 파일을 생성합니다. 

      $ cat <<EOF > ${SCRATCH}/credentials
  [default]
  role_arn = ${ROLE_ARN}
  web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
  region = <aws_region>
      1 
      
EOF
      Copy to Clipboard Toggle word wrap
      1
      & lt;aws_region >을 STS 끝점에 사용할 AWS 리전으로 바꿉니다.

    2. OADP의 네임스페이스를 생성합니다. 

      $ oc create namespace openshift-adp
      Copy to Clipboard Toggle word wrap

    3. OpenShift Container Platform 시크릿을 생성합니다. 

      $ oc -n openshift-adp create secret generic cloud-credentials \
  --from-file=${SCRATCH}/credentials
      Copy to Clipboard Toggle word wrap
      참고

      OpenShift Container Platform 버전 4.14 이상에서 OADP Operator는 OLM(Operator Lifecycle Manager) 및 CCO(Cloud Credentials Operator)를 통해 새로운 표준화된 STS 워크플로를 지원합니다. 이 워크플로우에서는 OpenShift Container Platform 웹 콘솔을 사용하여 OLM 관리 Operator를 설치하는 동안 위의 시크릿을 생성할 필요가 없습니다. 자세한 내용은 웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.

      이전 시크릿은 CCO에 의해 자동으로 생성됩니다.

  2. OADP Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub 로 이동합니다.
    2. OADP Operator 를 검색합니다.
    3. role_ARN 필드에 이전에 생성한 role_arn을 붙여넣고 설치를 클릭합니다.

  3. 다음 명령을 입력하여 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
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 애플리케이션의 스토리지 기본 스토리지 클래스를 확인합니다. 

    $ oc get pvc -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 스토리지 클래스를 가져옵니다. 

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

    참고

    다음 스토리지 클래스가 작동합니다.

    • gp3-csi
    • gp2-csi
    • gp3
    • gp2

    백업 중인 애플리케이션 또는 애플리케이션이 모두 CSI(Container Storage Interface)를 사용하는 PV(영구 볼륨)를 사용하는 경우 OADP DPA 구성에 CSI 플러그인을 포함하는 것이 좋습니다.

  6. DataProtectionApplication 리소스를 만들어 백업 및 볼륨 스냅샷이 저장되는 스토리지에 대한 연결을 구성합니다.

    1. 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
      Copy to Clipboard Toggle word wrap
      1
      ROSA는 내부 이미지 백업을 지원합니다. 이미지 백업을 사용하지 않으려면 이 필드를 false 로 설정합니다.
      2
      nodeAgent 속성과 관련된 중요한 노트를 참조하십시오.
      3
      uploader 유형입니다. 가능한 값은 restic 또는 kopia 입니다. 기본 제공 Data Mover는 uploaderType 필드의 값에 관계없이 Kopia를 기본 업로드기 메커니즘으로 사용합니다.

  1. 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
    Copy to Clipboard Toggle word wrap
    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
Copy to Clipboard Toggle word wrap

다음 구성에서는 다음을 수행합니다. 

restic:
  enable: false
Copy to Clipboard Toggle word wrap

백업 및 복원을 위해 두 개의 다른 클러스터를 사용하려면 클라우드 스토리지 CR과 OADP DataProtectionApplication 구성 둘 다에 동일한 AWS S3 스토리지 이름이 있어야 합니다.

4.8.1.3. 예: 선택적 정리를 사용하여 OADP ROSA STS에서 워크로드 백업
링크 복사
4.8.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) 구성이 작동합니다.

  1. 다음 명령을 실행하여 백업할 워크로드를 생성합니다. 

    $ oc create namespace hello-world
    Copy to Clipboard Toggle word wrap 
    $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 경로를 노출합니다. 

    $ oc expose service/hello-openshift -n hello-world
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 애플리케이션이 작동하는지 확인합니다. 

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
    Copy to Clipboard Toggle word wrap

    출력 예

    Hello OpenShift!
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 워크로드를 백업합니다. 

    $ 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
    Copy to Clipboard Toggle word wrap

  5. 백업이 완료될 때까지 기다린 후 다음 명령을 실행합니다. 

    $ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"
    Copy to Clipboard Toggle word wrap

    출력 예

    {
  "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
}
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 데모 워크로드를 삭제합니다. 

    $ oc delete ns hello-world
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 실행하여 백업에서 워크로드를 복원합니다. 

    $ cat << EOF | oc create -f -
  apiVersion: velero.io/v1
  kind: Restore
  metadata:
    name: hello-world
    namespace: openshift-adp
  spec:
    backupName: hello-world
EOF
    Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 복원이 완료될 때까지 기다립니다. 

    $ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"
    Copy to Clipboard Toggle word wrap

    출력 예

    {
  "completionTimestamp": "2022-09-07T22:25:47Z",
  "phase": "Completed",
  "progress": {
    "itemsRestored": 38,
    "totalItems": 38
  },
  "startTimestamp": "2022-09-07T22:25:28Z",
  "warnings": 9
}
    Copy to Clipboard Toggle word wrap

  9. 다음 명령을 실행하여 워크로드가 복원되었는지 확인합니다. 

    $ oc -n hello-world get pods
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                              READY   STATUS    RESTARTS   AGE
hello-openshift-9f885f7c6-kdjpj   1/1     Running   0          90s
    Copy to Clipboard Toggle word wrap

  10. 다음 명령을 실행하여 JSONPath를 확인합니다. 

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
    Copy to Clipboard Toggle word wrap

    출력 예

    Hello OpenShift!
    Copy to Clipboard Toggle word wrap

참고

문제 해결 팁은 OADP 팀의 문제 해결 설명서를 참조하십시오.

4.8.1.3.2. OADP 및 ROSA STS를 사용하여 백업 후 클러스터 정리
링크 복사

이 예제에서 OADP(OpenShift API for Data Protection) Operator를 백업 및 S3 버킷과 함께 설치 제거해야 하는 경우 다음 지침을 따르십시오.

절차

  1. 다음 명령을 실행하여 워크로드를 삭제합니다. 

    $ oc delete ns hello-world
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 DPA(데이터 보호 애플리케이션)를 삭제합니다. 

    $ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 클라우드 스토리지를 삭제합니다. 

    $ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
    Copy to Clipboard Toggle word wrap
    주의

    이 명령이 중단되면 다음 명령을 실행하여 종료자를 삭제해야 할 수 있습니다. 

    $ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
    Copy to Clipboard Toggle word wrap

  4. Operator가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 Operator를 제거합니다. 

    $ oc -n openshift-adp delete subscription oadp-operator
    Copy to Clipboard Toggle word wrap

  5. Operator에서 네임스페이스를 제거합니다. 

    $ oc delete ns openshift-adp
    Copy to Clipboard Toggle word wrap

  6. 백업 및 복원 리소스가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 리소스를 제거합니다. 

    $ oc delete backup hello-world
    Copy to Clipboard Toggle word wrap

  7. AWS S3에서 백업, 복원 및 원격 오브젝트를 삭제하려면 다음 명령을 실행합니다. 

    $ velero backup delete hello-world
    Copy to Clipboard Toggle word wrap

  8. 더 이상 CRD(Custom Resource Definitions)가 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 정의를 제거하십시오. 

    $ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
    Copy to Clipboard Toggle word wrap

  9. 다음 명령을 실행하여 AWS S3 버킷을 삭제합니다. 

    $ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
    Copy to Clipboard Toggle word wrap 
    $ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
    Copy to Clipboard Toggle word wrap

  10. 다음 명령을 실행하여 역할에서 정책을 분리합니다. 

    $ aws iam detach-role-policy --role-name "${ROLE_NAME}"  --policy-arn "${POLICY_ARN}"
    Copy to Clipboard Toggle word wrap

  11. 다음 명령을 실행하여 역할을 삭제합니다. 

    $ aws iam delete-role --role-name "${ROLE_NAME}"
    Copy to Clipboard Toggle word wrap

4.9. OADP 데이터 Mover
링크 복사

4.9.1. OADP Data Mover 소개
링크 복사

OADP Data Mover를 사용하면 오류, 실수로 삭제 또는 클러스터 손상이 발생할 경우 저장소에서 상태 저장 애플리케이션을 복원할 수 있습니다.

참고

OADP 1.1 Data Mover는 기술 프리뷰 기능입니다.

OADP 1.2 Data Mover는 기능 및 성능이 크게 개선되었지만 여전히 기술 프리뷰 기능입니다.

중요

OADP Data Mover는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

참고

마이그레이션 후 후크는 OADP 1.3 Data Mover에서 제대로 작동하지 않을 수 있습니다.

OADP 1.1 및 OADP 1.2 데이터 이동자는 동기 프로세스를 사용하여 애플리케이션 데이터를 백업 및 복원합니다. 프로세스는 동기적이므로 사용자는 데이터 Mover의 PVC(영구 볼륨 클레임)에 의해 관련 Pod의 영구 볼륨(PV)이 릴리스된 후에만 모든 복원 후 후크가 시작되도록 할 수 있습니다.

그러나 OADP 1.3 Data Mover는 비동기 프로세스를 사용합니다. 이러한 차이로 인해 Data Mover의 PVC에 의해 관련 PV를 릴리스하기 전에 복원 후 후크가 호출될 수 있습니다. 이 경우 Pod는 Pending 상태로 유지되며 후크를 실행할 수 없습니다. 후크 시도는 Pod가 릴리스되기 전에 시간 초과되어 PartiallyFailed 복원 작업을 수행할 수 있습니다.

4.9.1.1. OADP 데이터 Mover 사전 요구 사항
링크 복사
  • 별도의 네임스페이스에서 상태 저장 애플리케이션이 실행되고 있습니다.
  • OLM(Operator Lifecycle Manager)을 사용하여 OADP Operator를 설치했습니다.
  • 적절한 VolumeSnapshotClass 및 StorageClass 를 생성했습니다.
  • OLM을 사용하여volSync Operator를 설치했습니다.

4.9.2. CSI 스냅샷에 Data Mover 사용
링크 복사

OADP Data Mover를 통해 고객은 CSI(Container Storage Interface) 볼륨 스냅샷을 원격 오브젝트 저장소에 백업할 수 있습니다. Data Mover가 활성화되면 오류, 실수로 삭제 또는 클러스터 손상이 발생하는 경우 오브젝트 저장소에서 가져온 CSI 볼륨 스냅샷을 사용하여 상태 저장 애플리케이션을 복원할 수 있습니다.

Data Mover 솔루션은volSync의 Restic 옵션을 사용합니다.

Data Mover는 CSI 볼륨 스냅샷의 백업 및 복원만 지원합니다.

OADP 1.2에서 VSB(Data Mover VolumeSnapshotBackups ) 및 VolumeSnapshotRestores (VSR)는 VolumeSnapshotMover(VSM)를 사용하여 큐에 추가됩니다. VSM의 성능은 동시에 진행 중 VSB 및 VSR 수를 지정하여 향상됩니다. 모든 비동기 플러그인 작업이 완료되면 백업이 완료된 것으로 표시됩니다.

참고

OADP 1.1 Data Mover는 기술 프리뷰 기능입니다.

OADP 1.2 Data Mover는 기능 및 성능이 크게 개선되었지만 여전히 기술 프리뷰 기능입니다.

중요

OADP Data Mover는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

참고

Red Hat은 ODF CephFS 볼륨을 백업 및 복원하기 위해 OADP 1.2 Data Mover를 사용하는 고객은 성능을 개선하기 위해 OpenShift Container Platform 버전 4.12 이상을 업그레이드하거나 설치하는 것이 좋습니다. OADP Data Mover는 OpenShift Container Platform 버전 4.12 이상에서 CephFS shallow 볼륨을 활용할 수 있으며, 이 볼륨은 백업 시간을 개선할 수 있습니다.

사전 요구 사항

  • StorageClass 및 VolumeSnapshotClass CR(사용자 정의 리소스)에서 CSI를 지원하는지 확인했습니다.

  • 하나의 VolumeSnapshotClass CR에만 주석 snapshot.storage.kubernetes.io/is-default-class: "true" 가 있는지 확인했습니다.

    참고

    OpenShift Container Platform 버전 4.12 이상에서 이것이 유일한 기본 VolumeSnapshotClass 인지 확인합니다.

  • VolumeSnapshotClass CR의 deletionPolicy 가 Retain 으로 설정되어 있는지 확인했습니다.
  • 하나의 StorageClass CR에만 주석 storageclass.kubernetes.io/is-default-class: "true" 가 있는지 확인했습니다.
  • VolumeSnapshotClass CR에 velero.io/csi-volumesnapshot-class: "true" 레이블이 포함되어 있습니다.

  • OADP 네임스페이스에 oc annotate --overwrite namespace /openshift-adp volsync.backube/privileged-movers="true" 주석이 있는지 확인했습니다.

    참고

    OADP 1.1에서 위의 설정은 필수입니다.

    OADP 1.2에서는 대부분의 시나리오에서 privileged-movers 설정이 필요하지 않습니다. 컨테이너 권한 복원은volsync 사본에 적합해야 합니다. 일부 사용자 시나리오에서는 privileged-mover= true 설정이 해결되어야 하는 권한 오류가 있을 수 있습니다.

  • OLM(Operator Lifecycle Manager)을 사용하여 VolSync Operator를 설치했습니다.

    참고

    OADP Data Mover를 사용하려면volSync Operator가 필요합니다.

  • OLM을 사용하여 OADP Operator를 설치했습니다.

    참고

    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
    Copy to Clipboard Toggle word wrap

    이 시나리오에서는 백업이 성공적으로 완료되도록 볼륨 크기 조정 또는 다른 파일 시스템 유형(예: ext4 )을 사용하는 것이 좋습니다.

절차

  1. 다음과 같이 .yaml 파일을 생성하여 Restic 시크릿을 구성합니다. 

    apiVersion: v1
kind: Secret
metadata:
  name: <secret_name>
  namespace: openshift-adp
type: Opaque
stringData:
  RESTIC_PASSWORD: <secure_restic_password>
    Copy to Clipboard Toggle word wrap
    참고

    기본적으로 Operator는 dm-credential 이라는 시크릿을 찾습니다. 다른 이름을 사용하는 경우 dpa.spec.features.dataMover.credentialName 을 사용하여 DPA(Data Protection Application) CR을 통해 이름을 지정해야 합니다.

  2. 다음 예와 유사한 DPA CR을 생성합니다. 기본 플러그인에는 CSI가 포함됩니다.

    DPA(Data Protection Application) CR 예

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
  namespace: openshift-adp
spec:
  backupLocations:
    - velero:
        config:
          profile: default
          region: us-east-1
        credential:
          key: cloud
          name: cloud-credentials
        default: true
        objectStorage:
          bucket: <bucket_name>
          prefix: <bucket-prefix>
        provider: aws
  configuration:
    restic:
      enable: <true_or_false>
    velero:
       itemOperationSyncFrequency: "10s"
       defaultPlugins:
        - openshift
        - aws
        - csi
        - vsm
    1 
    
  features:
    dataMover:
      credentialName: restic-secret
      enable: true
      maxConcurrentBackupVolumes: "3"
    2 
    
      maxConcurrentRestoreVolumes: "3"
    3 
    
      pruneInterval: "14"
    4 
    
      volumeOptions:
    5 
    
      sourceVolumeOptions:
          accessMode: ReadOnlyMany
          cacheAccessMode: ReadWriteOnce
          cacheCapacity: 2Gi
      destinationVolumeOptions:
          storageClass: other-storageclass-name
          cacheAccessMode: ReadWriteMany
  snapshotLocations:
    - velero:
        config:
          profile: default
          region: us-west-2
        provider: aws
    Copy to Clipboard Toggle word wrap

    1
    OADP 1.2만 해당
    2
    OADP 1.2만 해당 선택 사항: 백업에 대해 대기열에 추가할 수 있는 스냅샷 수의 상한을 지정합니다. 기본값은 10입니다.
    3
    OADP 1.2만 해당 선택 사항: 복원을 위해 대기열에 지정할 수 있는 스냅샷 수의 상한을 지정합니다. 기본값은 10입니다.
    4
    OADP 1.2만 해당 선택 사항: 리포지토리에서 Restic 정리를 실행하는 사이의 일 수를 지정합니다. 정리 작업에서는 데이터를 사용 가능한 공간으로 다시 구성하지만 프로세스의 일부로 중요한 I/O 트래픽을 생성할 수도 있습니다. 이 옵션을 설정하면 더 이상 참조되지 않는 데이터에서 스토리지 소비와 액세스 비용 간의 절충이 가능합니다.
    5
    OADP 1.2만 해당 선택 사항: 백업 및 복원을 위해 VolumeSync 볼륨 옵션을 지정합니다.

    OADP Operator는 두 개의 CRD(사용자 정의 리소스 정의), VolumeSnapshotBackup 및 VolumeSnapshotRestore 를 설치합니다.

    VolumeSnapshotBackup CRD의 예

    apiVersion: datamover.oadp.openshift.io/v1alpha1
kind: VolumeSnapshotBackup
metadata:
  name: <vsb_name>
  namespace: <namespace_name>
    1 
    
spec:
  volumeSnapshotContent:
    name: <snapcontent_name>
  protectedNamespace: <adp_namespace>
    2 
    
  resticSecretRef:
    name: <restic_secret_name>
    Copy to Clipboard Toggle word wrap

    1
    볼륨 스냅샷이 존재하는 네임스페이스를 지정합니다.
    2
    OADP Operator가 설치된 네임스페이스를 지정합니다. 기본값은 openshift-adp 입니다.

    VolumeSnapshotRestore CRD의 예

    apiVersion: datamover.oadp.openshift.io/v1alpha1
kind: VolumeSnapshotRestore
metadata:
  name: <vsr_name>
  namespace: <namespace_name>
    1 
    
spec:
  protectedNamespace: <protected_ns>
    2 
    
  resticSecretRef:
    name: <restic_secret_name>
  volumeSnapshotMoverBackupRef:
    sourcePVCData:
      name: <source_pvc_name>
      size: <source_pvc_size>
    resticrepository: <your_restic_repo>
    volumeSnapshotClassName: <vsclass_name>
    Copy to Clipboard Toggle word wrap

    1
    볼륨 스냅샷이 존재하는 네임스페이스를 지정합니다.
    2
    OADP Operator가 설치된 네임스페이스를 지정합니다. 기본값은 openshift-adp 입니다.

  3. 다음 단계를 수행하여 볼륨 스냅샷을 백업할 수 있습니다.

    1. 백업 CR을 생성합니다. 

      apiVersion: velero.io/v1
kind: Backup
metadata:
  name: <backup_name>
  namespace: <protected_ns>
      1 
      
spec:
  includedNamespaces:
  - <app_ns>
      2 
      
  storageLocation: velero-sample-1
      Copy to Clipboard Toggle word wrap
      1
      Operator가 설치된 네임스페이스를 지정합니다. 기본 네임스페이스는 openshift-adp 입니다.
      2
      백업할 애플리케이션 네임스페이스 또는 네임스페이스를 지정합니다.

    2. 최대 10분 정도 기다린 후 다음 명령을 입력하여 VolumeSnapshotBackup CR 상태가 완료되었는지 확인합니다. 

      $ oc get vsb -n <app_ns>
      Copy to Clipboard Toggle word wrap 
      $ oc get vsb <vsb_name> -n <app_ns> -o jsonpath="{.status.phase}"
      Copy to Clipboard Toggle word wrap

      오브젝트는 DPA에서 구성된 오브젝트 저장소에서 생성됩니다.

      참고

      VolumeSnapshotBackup CR의 상태가 실패 가 되는 경우 문제를 해결하려면 Velero 로그를 참조하십시오.

  4. 다음 단계를 수행하여 볼륨 스냅샷을 복원할 수 있습니다.

    1. Velero CSI 플러그인에서 생성한 애플리케이션 네임스페이스 및 VolumeSnapshotContent 를 삭제합니다.

    2. Restore CR을 생성하고 restorePV 를 true 로 설정합니다.

      Restore CR의 예

      apiVersion: velero.io/v1
kind: Restore
metadata:
  name: <restore_name>
  namespace: <protected_ns>
spec:
  backupName: <previous_backup_name>
  restorePVs: true
      Copy to Clipboard Toggle word wrap

    3. 최대 10분 정도 기다린 후 다음 명령을 입력하여 VolumeSnapshotRestore CR 상태가 완료되었는지 확인합니다. 

      $ oc get vsr -n <app_ns>
      Copy to Clipboard Toggle word wrap 
      $ oc get vsr <vsr_name> -n <app_ns> -o jsonpath="{.status.phase}"
      Copy to Clipboard Toggle word wrap

    4. 애플리케이션 데이터 및 리소스가 복원되었는지 확인합니다.

      참고

      VolumeSnapshotRestore CR의 상태가 'Failed'가 되면 문제 해결을 위해 Velero 로그를 참조하십시오.

4.9.3. Ceph 스토리지에서 OADP 1.2 Data Mover 사용
링크 복사

OADP 1.2 Data Mover를 사용하여 CephFS, CephRBD 또는 둘 다 사용하는 클러스터의 애플리케이션 데이터를 백업하고 복원할 수 있습니다.

OADP 1.2 Data Mover는 대규모 환경을 지원하는 Ceph 기능을 활용합니다. 이러한 방법 중 하나는 OpenShift Container Platform 4.12 이상에서 사용할 수 있는 단순 복사 방법입니다. 이 기능은 소스 PVC(영구 볼륨 클레임)에 있는 것 이외의 StorageClass 및 AccessMode 리소스 백업 및 복원을 지원합니다.

중요

CephFS shallow copy 기능은 백업 기능입니다. 복원 작업의 일부가 아닙니다.

다음 사전 요구 사항은 Ceph 스토리지를 사용하는 클러스터에서 OADP(OpenShift API for Data Protection) 1.2 Data Mover를 사용하는 모든 데이터 백업 및 복원 작업에 적용됩니다.

  • OpenShift Container Platform 4.12 이상을 설치했습니다.
  • OADP Operator가 설치되어 있습니다.
  • 네임스페이스 openshift-adp에 시크릿 cloud-credentials 를 생성했습니다.
  • Red Hat OpenShift Data Foundation을 설치했습니다.
  • Operator Lifecycle Manager를 사용하여 최신volSync Operator를 설치했습니다.
4.9.3.2. OADP 1.2 Data Mover와 함께 사용할 사용자 정의 리소스 정의
링크 복사

Red Hat OpenShift Data Foundation을 설치하면 기본 CephFS 및 CephRBD StorageClass 및 VolumeSnapshotClass CR(사용자 정의 리소스)이 자동으로 생성됩니다. OADP(OpenShift API for Data Protection) 1.2 Data Mover와 함께 사용하려면 이러한 CR을 정의해야 합니다.

CR을 정의한 후 백업 및 복원 작업을 수행하기 전에 환경에 몇 가지 다른 변경을 수행해야 합니다.

4.9.3.2.1. OADP 1.2 Data Mover와 함께 사용할 CephFS 사용자 정의 리소스 정의
링크 복사

Red Hat OpenShift Data Foundation을 설치하면 기본 CephFS StorageClass 사용자 정의 리소스(CR) 및 기본 CephFS VolumeSnapshotClass CR이 자동으로 생성됩니다. OADP(OpenShift API for Data Protection) 1.2 Data Mover와 함께 사용할 이러한 CR을 정의할 수 있습니다.

절차

  1. 다음 예와 같이 VolumeSnapshotClass CR을 정의합니다.

    VolumeSnapshotClass CR의 예

    apiVersion: snapshot.storage.k8s.io/v1
deletionPolicy: Retain
    1 
    
driver: openshift-storage.cephfs.csi.ceph.com
kind: VolumeSnapshotClass
metadata:
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: true
    2 
    
  labels:
    velero.io/csi-volumesnapshot-class: true
    3 
    
  name: ocs-storagecluster-cephfsplugin-snapclass
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/snapshotter-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/snapshotter-secret-namespace: openshift-storage
    Copy to Clipboard Toggle word wrap

    1
    Retain 으로 설정해야 합니다.
    2
    true 로 설정해야 합니다.
    3
    true 로 설정해야 합니다.

  2. 다음 예와 같이 StorageClass CR을 정의합니다.

    StorageClass CR의 예

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ocs-storagecluster-cephfs
  annotations:
    description: Provides RWO and RWX Filesystem volumes
    storageclass.kubernetes.io/is-default-class: true
    1 
    
provisioner: openshift-storage.cephfs.csi.ceph.com
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node
  csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
  fsName: ocs-storagecluster-cephfilesystem
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate
    Copy to Clipboard Toggle word wrap

    1
    true 로 설정해야 합니다.

Red Hat OpenShift Data Foundation을 설치하면 기본 CephRBD StorageClass CR(사용자 정의 리소스) 및 기본 CephRBD VolumeSnapshotClass CR이 자동으로 생성됩니다. OADP(OpenShift API for Data Protection) 1.2 Data Mover와 함께 사용할 이러한 CR을 정의할 수 있습니다.

절차

  1. 다음 예와 같이 VolumeSnapshotClass CR을 정의합니다.

    VolumeSnapshotClass CR의 예

    apiVersion: snapshot.storage.k8s.io/v1
deletionPolicy: Retain
    1 
    
driver: openshift-storage.rbd.csi.ceph.com
kind: VolumeSnapshotClass
metadata:
  labels:
    velero.io/csi-volumesnapshot-class: true
    2 
    
  name: ocs-storagecluster-rbdplugin-snapclass
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/snapshotter-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/snapshotter-secret-namespace: openshift-storage
    Copy to Clipboard Toggle word wrap

    1
    Retain 으로 설정해야 합니다.
    2
    true 로 설정해야 합니다.

  2. 다음 예와 같이 StorageClass CR을 정의합니다.

    StorageClass CR의 예

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ocs-storagecluster-ceph-rbd
  annotations:
    description: 'Provides RWO Filesystem volumes, and RWO and RWX Block volumes'
provisioner: openshift-storage.rbd.csi.ceph.com
parameters:
  csi.storage.k8s.io/fstype: ext4
  csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
  imageFormat: '2'
  clusterID: openshift-storage
  imageFeatures: layering
  csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
  pool: ocs-storagecluster-cephblockpool
  csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate
    Copy to Clipboard Toggle word wrap

4.9.3.2.3. OADP 1.2 Data Mover와 함께 사용할 추가 사용자 정의 리소스 정의
링크 복사

기본 StorageClass 및 CephRBD VolumeSnapshotClass CR(사용자 정의 리소스)을 생성한 후 다음 CR을 생성해야 합니다.

  • shallow 복사 기능을 사용하도록 정의된 CephFS StorageClass CR
  • Restic Secret CR

절차

  1. CephFS StorageClass CR을 생성하고 다음 예와 같이 backingSnapshot 매개변수를 true 로 설정합니다.

    backingSnapshot 이 true로 설정된 CephFS StorageClass CR의 예

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ocs-storagecluster-cephfs-shallow
  annotations:
    description: Provides RWO and RWX Filesystem volumes
    storageclass.kubernetes.io/is-default-class: false
provisioner: openshift-storage.cephfs.csi.ceph.com
parameters:
  csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner
  clusterID: openshift-storage
  fsName: ocs-storagecluster-cephfilesystem
  csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
  backingSnapshot: true
    1 
    
  csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate
    Copy to Clipboard Toggle word wrap

    1
    true 로 설정해야 합니다.
    중요

    CephFS VolumeSnapshotClass 및 StorageClass CR의 값이 provisioner 에 대해 동일한지 확인합니다.

  2. 다음 예와 같이 Restic Secret CR을 구성합니다.

    Restic Secret CR의 예

    apiVersion: v1
kind: Secret
metadata:
  name: <secret_name>
  namespace: <namespace>
type: Opaque
stringData:
  RESTIC_PASSWORD: <restic_password>
    Copy to Clipboard Toggle word wrap

OADP(OpenShift API for Data Protection) 1.2 Data Mover를 사용하여 CephFS의 단순 복사 기능을 활성화하여 CephFS 스토리지를 사용하여 데이터를 백업하고 복원할 수 있습니다.

사전 요구 사항

  • 상태 저장 애플리케이션은 CephFS를 프로비저너로 사용하는 PVC(영구 볼륨 클레임)가 있는 별도의 네임스페이스에서 실행됩니다.
  • StorageClass 및 VolumeSnapshotClass CR(사용자 정의 리소스)은 CephFS 및 OADP 1.2 데이터 Mover에 대해 정의됩니다.
  • openshift-adp 네임스페이스에는 시크릿 cloud-credentials 가 있습니다.
4.9.3.3.1. CephFS 스토리지와 함께 사용할 DPA 생성
링크 복사

OADP(OpenShift API for Data Protection) 1.2 Data Mover를 사용하여 CephFS 스토리지를 사용하여 데이터를 백업하고 복원하기 전에 DPA(Data Protection Application) CR을 생성해야 합니다.

절차

  1. 다음 명령을 실행하여 VolumeSnapshotClass CR의 deletionPolicy 필드가 Retain 으로 설정되어 있는지 확인합니다. 

    $ oc get volumesnapshotclass -A  -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{"  "}{"Retention Policy: "}{.deletionPolicy}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 VolumeSnapshotClass CR의 레이블이 true 로 설정되어 있는지 확인합니다. 

    $ oc get volumesnapshotclass -A  -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{"  "}{"labels: "}{.metadata.labels}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 StorageClass CR의 storageclass.kubernetes.io/is-default-class 주석이 true 로 설정되어 있는지 확인합니다. 

    $ oc get storageClass -A  -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{"  "}{"annotations: "}{.metadata.annotations}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

  4. 다음 예와 유사한 DPA(Data Protection Application) CR을 생성합니다.

    DPA CR 예

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
  namespace: openshift-adp
spec:
  backupLocations:
    - velero:
        config:
          profile: default
          region: us-east-1
        credential:
          key: cloud
          name: cloud-credentials
        default: true
        objectStorage:
          bucket: <my_bucket>
          prefix: velero
       provider: aws
    configuration:
      restic:
        enable: false
    1 
    
      velero:
        defaultPlugins:
          - openshift
          - aws
          - csi
          - vsm
    features:
      dataMover:
        credentialName: <restic_secret_name>
    2 
    
        enable: true
    3 
    
        volumeOptionsForStorageClasses:
    4 
    
          ocs-storagecluster-cephfs:
            sourceVolumeOptions:
              accessMode: ReadOnlyMany
              cacheAccessMode: ReadWriteMany
              cacheStorageClassName: ocs-storagecluster-cephfs
              storageClassName: ocs-storagecluster-cephfs-shallow
    Copy to Clipboard Toggle word wrap

    1
    enable 필드에 대한 기본값이 없습니다. 유효한 값은 true 또는 false입니다.
    2
    OADP 1.2 Data Mover 및 Ceph로 작업할 수 있는 환경을 준비할 때 생성한 Restic 시크릿 을 사용합니다. Restic Secret 을 사용하지 않는 경우 CR은 이 매개변수에 기본값 dm-credential 을 사용합니다.
    3
    enable 필드에 대한 기본값이 없습니다. 유효한 값은 true 또는 false입니다.
    4
    선택적 매개변수입니다. 각 storageClass 볼륨에 대해 다른 VolumeOptionsForStorageClass 레이블 세트를 정의할 수 있습니다. 이 구성은 다양한 공급자가 있는 볼륨에 대한 백업을 제공합니다. 선택적 VolumeOptionsForStorageClass 매개변수는 일반적으로 CephFS와 함께 사용되지만 모든 스토리지 유형에 사용할 수 있습니다.

OADP(OpenShift API for Data Protection) 1.2 Data Mover를 사용하여 CephFS 스토리지의 부분 복사 기능을 활성화하여 CephFS 스토리지를 사용하여 데이터를 백업할 수 있습니다.

절차

  1. 다음 예와 같이 Backup CR을 생성합니다.

    Backup CR의 예

    apiVersion: velero.io/v1
kind: Backup
metadata:
  name: <backup_name>
  namespace: <protected_ns>
spec:
  includedNamespaces:
  - <app_ns>
  storageLocation: velero-sample-1
    Copy to Clipboard Toggle word wrap

  2. 다음 단계를 완료하여 VolumeSnapshotBackup CR의 진행 상황을 모니터링합니다.

    1. 모든 VolumeSnapshotBackup CR의 진행 상황을 확인하려면 다음 명령을 실행합니다. 

      $ oc get vsb -n <app_ns>
      Copy to Clipboard Toggle word wrap

    2. 특정 VolumeSnapshotBackup CR의 진행 상황을 확인하려면 다음 명령을 실행합니다. 

      $ oc get vsb <vsb_name> -n <app_ns> -ojsonpath="{.status.phase}`
      Copy to Clipboard Toggle word wrap
  3. VolumeSnapshotBackup CR의 상태가 Completed 가 될 때까지 몇 분 정도 기다립니다.
  4. Restic 시크릿에 제공된 오브젝트 저장소에 스냅샷이 하나 이상 있는지 확인합니다. /<OADP_namespace> 접두사가 있는 대상 BackupStorageLocation 스토리지 공급자에서 이 스냅샷을 확인할 수 있습니다.
4.9.3.3.3. OADP 1.2 Data Mover 및 CephFS 스토리지를 사용하여 데이터 복원
링크 복사

OADP(OpenShift API for Data Protection) 1.2 Data Mover를 사용하여 백업 프로세스에 CephFS 스토리지의 부분 복사 기능이 활성화된 경우 CephFS 스토리지를 사용하여 데이터를 복원할 수 있습니다. 단순 복사 기능은 복원 프로시저에서 사용되지 않습니다.

절차

  1. 다음 명령을 실행하여 애플리케이션 네임스페이스를 삭제합니다. 

    $ oc delete vsb -n <app_namespace> --all
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 백업 중에 생성된 VolumeSnapshotContent CR을 삭제합니다. 

    $ oc delete volumesnapshotcontent --all
    Copy to Clipboard Toggle word wrap

  3. 다음 예와 같이 Restore CR을 생성합니다.

    Restore CR의 예

    apiVersion: velero.io/v1
kind: Restore
metadata:
  name: <restore_name>
  namespace: <protected_ns>
spec:
  backupName: <previous_backup_name>
    Copy to Clipboard Toggle word wrap

  4. 다음을 수행하여 VolumeSnapshotRestore CR의 진행 상황을 모니터링합니다.

    1. 모든 VolumeSnapshotRestore CR의 진행 상황을 확인하려면 다음 명령을 실행합니다. 

      $ oc get vsr -n <app_ns>
      Copy to Clipboard Toggle word wrap

    2. 특정 VolumeSnapshotRestore CR의 진행 상황을 확인하려면 다음 명령을 실행합니다. 

      $ oc get vsr <vsr_name> -n <app_ns> -ojsonpath="{.status.phase}
      Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 애플리케이션 데이터가 복원되었는지 확인합니다. 

    $ oc get route <route_name> -n <app_ns> -ojsonpath="{.spec.host}"
    Copy to Clipboard Toggle word wrap

OADP(OpenShift API for Data Protection) 1.2 Data Mover를 사용하여 CephFS 및 CephRBD를 모두 사용하는 환경인 분할 볼륨이 있는 환경에서 데이터를 백업하고 복원할 수 있습니다.

사전 요구 사항

  • 상태 저장 애플리케이션은 CephFS를 프로비저너로 사용하는 PVC(영구 볼륨 클레임)가 있는 별도의 네임스페이스에서 실행됩니다.
  • StorageClass 및 VolumeSnapshotClass CR(사용자 정의 리소스)은 CephFS 및 OADP 1.2 데이터 Mover에 대해 정의됩니다.
  • openshift-adp 네임스페이스에는 시크릿 cloud-credentials 가 있습니다.
4.9.3.4.1. 분할 볼륨과 함께 사용할 DPA 생성
링크 복사

OADP(OpenShift API for Data Protection) 1.2 Data Mover를 사용하여 분할 볼륨을 사용하여 데이터를 백업하고 복원하기 전에 DPA(Data Protection Application) CR을 생성해야 합니다.

절차

  • 다음 예와 같이 DPA(Data Protection Application) CR을 생성합니다.

    분할 볼륨이 있는 환경의 DPA CR의 예

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
  namespace: openshift-adp
spec:
  backupLocations:
    - velero:
        config:
          profile: default
          region: us-east-1
        credential:
          key: cloud
          name: cloud-credentials
        default: true
        objectStorage:
          bucket: <my-bucket>
          prefix: velero
        provider: aws
  configuration:
    restic:
      enable: false
    velero:
      defaultPlugins:
        - openshift
        - aws
        - csi
        - vsm
  features:
    dataMover:
      credentialName: <restic_secret_name>
    1 
    
      enable: true
      volumeOptionsForStorageClasses:
    2 
    
        ocs-storagecluster-cephfs:
          sourceVolumeOptions:
            accessMode: ReadOnlyMany
            cacheAccessMode: ReadWriteMany
            cacheStorageClassName: ocs-storagecluster-cephfs
            storageClassName: ocs-storagecluster-cephfs-shallow
        ocs-storagecluster-ceph-rbd:
          sourceVolumeOptions:
            storageClassName: ocs-storagecluster-ceph-rbd
            cacheStorageClassName: ocs-storagecluster-ceph-rbd
          destinationVolumeOptions:
            storageClassName: ocs-storagecluster-ceph-rbd
            cacheStorageClassName: ocs-storagecluster-ceph-rbd
    Copy to Clipboard Toggle word wrap

    1
    OADP 1.2 Data Mover 및 Ceph로 작업할 수 있는 환경을 준비할 때 생성한 Restic 시크릿 을 사용합니다. 그러지 않으면 CR에서 이 매개변수에 기본값 dm-credential 을 사용합니다.
    2
    각 storageClass 볼륨에 대해 다른 VolumeOptionsForStorageClass 라벨을 정의할 수 있으므로 다른 공급자가 있는 볼륨에 백업할 수 있습니다. VolumeOptionsForStorageClass 매개변수는 CephFS와 함께 사용할 수 있습니다. 그러나 선택적 VolumeOptionsForStorageClass 매개변수를 모든 스토리지 유형에 사용할 수 있습니다.
4.9.3.4.2. OADP 1.2 Data Mover 및 분할 볼륨을 사용하여 데이터 백업
링크 복사

OADP(OpenShift API for Data Protection) 1.2 Data Mover를 사용하여 볼륨이 분할된 환경에서 데이터를 백업할 수 있습니다.

절차

  1. 다음 예와 같이 Backup CR을 생성합니다.

    Backup CR의 예

    apiVersion: velero.io/v1
kind: Backup
metadata:
  name: <backup_name>
  namespace: <protected_ns>
spec:
  includedNamespaces:
  - <app_ns>
  storageLocation: velero-sample-1
    Copy to Clipboard Toggle word wrap

  2. 다음 단계를 완료하여 VolumeSnapshotBackup CR의 진행 상황을 모니터링합니다.

    1. 모든 VolumeSnapshotBackup CR의 진행 상황을 확인하려면 다음 명령을 실행합니다. 

      $ oc get vsb -n <app_ns>
      Copy to Clipboard Toggle word wrap

    2. 특정 VolumeSnapshotBackup CR의 진행 상황을 확인하려면 다음 명령을 실행합니다. 

      $ oc get vsb <vsb_name> -n <app_ns> -ojsonpath="{.status.phase}`
      Copy to Clipboard Toggle word wrap
  3. VolumeSnapshotBackup CR의 상태가 Completed 가 될 때까지 몇 분 정도 기다립니다.
  4. Restic 시크릿에 제공된 오브젝트 저장소에 스냅샷이 하나 이상 있는지 확인합니다. /<OADP_namespace> 접두사가 있는 대상 BackupStorageLocation 스토리지 공급자에서 이 스냅샷을 확인할 수 있습니다.
4.9.3.4.3. OADP 1.2 Data Mover 및 분할 볼륨을 사용하여 데이터 복원
링크 복사

OADP(OpenShift API for Data Protection) 1.2 Data Mover를 사용하여 백업 프로세스에 CephFS 스토리지의 부분 복사 기능이 활성화된 경우 볼륨이 분할된 환경에서 데이터를 복원할 수 있습니다. 단순 복사 기능은 복원 프로시저에서 사용되지 않습니다.

절차

  1. 다음 명령을 실행하여 애플리케이션 네임스페이스를 삭제합니다. 

    $ oc delete vsb -n <app_namespace> --all
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 백업 중에 생성된 VolumeSnapshotContent CR을 삭제합니다. 

    $ oc delete volumesnapshotcontent --all
    Copy to Clipboard Toggle word wrap

  3. 다음 예와 같이 Restore CR을 생성합니다.

    Restore CR의 예

    apiVersion: velero.io/v1
kind: Restore
metadata:
  name: <restore_name>
  namespace: <protected_ns>
spec:
  backupName: <previous_backup_name>
    Copy to Clipboard Toggle word wrap

  4. 다음을 수행하여 VolumeSnapshotRestore CR의 진행 상황을 모니터링합니다.

    1. 모든 VolumeSnapshotRestore CR의 진행 상황을 확인하려면 다음 명령을 실행합니다. 

      $ oc get vsr -n <app_ns>
      Copy to Clipboard Toggle word wrap

    2. 특정 VolumeSnapshotRestore CR의 진행 상황을 확인하려면 다음 명령을 실행합니다. 

      $ oc get vsr <vsr_name> -n <app_ns> -ojsonpath="{.status.phase}
      Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 애플리케이션 데이터가 복원되었는지 확인합니다. 

    $ oc get route <route_name> -n <app_ns> -ojsonpath="{.spec.host}"
    Copy to Clipboard Toggle word wrap

4.9.4. OADP 1.1 Data Mover를 사용하여 백업 후 정리
링크 복사

OADP 1.1 Data Mover의 경우 백업을 수행한 후 데이터 정리를 수행해야 합니다.

정리는 다음 리소스를 삭제하는 것으로 구성됩니다.

  • 버킷의 스냅샷
  • 클러스터 리소스
  • 스케줄에 의해 실행되거나 반복적으로 실행되는 백업 프로시저 후VSB(volume snapshot backups)
4.9.4.1. 버킷에서 스냅샷 삭제
링크 복사

OADP 1.1 Data Mover는 백업 후 버킷에 하나 이상의 스냅샷을 남겨 둘 수 있습니다. 모든 스냅샷을 삭제하거나 개별 스냅샷을 삭제할 수 있습니다.

절차

  • 버킷의 모든 스냅샷을 삭제하려면 DPA(Data Protection Application) .spec.backupLocation.objectStorage.bucket 리소스에 지정된 /<protected_namespace > 폴더를 삭제합니다.

  • 개별 스냅샷을 삭제하려면 다음을 수행합니다.

    1. DPA .spec.backupLocation.objectStorage.bucket 리소스에 지정된 /<protected_namespace > 폴더를 찾습니다.
    2. /<volumeSnapshotContent name>-pvc 접두사가 있는 적절한 폴더를 삭제합니다. 여기서 < VolumeSnapshotContent_name >은 PVC당 Data Mover에 의해 생성된 VolumeSnapshotContent 입니다.
4.9.4.2. 클러스터 리소스 삭제
링크 복사

OADP 1.1 Data Mover는 CSI(Container Storage Interface) 볼륨 스냅샷을 원격 오브젝트 저장소에 성공적으로 백업할지 여부에 관계없이 클러스터 리소스를 남겨 둘 수 있습니다.

성공적인 백업 후 애플리케이션 네임스페이스에 남아 있는 VolumeSnapshotBackup 또는 VolumeSnapshotRestore CR을 삭제하고 Data Mover를 사용한 복원을 삭제할 수 있습니다.

절차

  1. Data Mover를 사용하는 백업 후 애플리케이션 PVC가 있는 네임스페이스인 애플리케이션 네임스페이스에 남아 있는 클러스터 리소스를 삭제합니다. 

    $ oc delete vsb -n <app_namespace> --all
    Copy to Clipboard Toggle word wrap

  2. Data Mover를 사용하는 복원 후에도 남아 있는 클러스터 리소스를 삭제합니다. 

    $ oc delete vsr -n <app_namespace> --all
    Copy to Clipboard Toggle word wrap

  3. 필요한 경우 백업 후에도 남아 있는 VolumeSnapshotContent 리소스를 삭제하고 Data Mover를 사용하는 위치를 복원합니다. 

    $ oc delete volumesnapshotcontent --all
    Copy to Clipboard Toggle word wrap

Data Mover를 사용하는 백업 및 복원 작업이 실패하거나 부분적으로만 성공하면 애플리케이션 네임스페이스에 존재하는 VolumeSnapshotBackup (VSB) 또는 VolumeSnapshotRestore CRD(사용자 정의 리소스 정의)를 정리하고 이러한 컨트롤러에서 생성한 추가 리소스를 정리해야 합니다.

절차

  1. 다음 명령을 입력하여 Data Mover를 사용한 백업 작업 후에도 남아 있는 클러스터 리소스를 정리합니다.

    1. 애플리케이션 네임스페이스에서 VSB CRD를 삭제하고 백업하고 복원할 애플리케이션 PVC가 있는 네임스페이스를 삭제합니다. 

      $ oc delete vsb -n <app_namespace> --all
      Copy to Clipboard Toggle word wrap

    2. VolumeSnapshot CR을 삭제합니다. 

      $ oc delete volumesnapshot -A --all
      Copy to Clipboard Toggle word wrap

    3. VolumeSnapshotContent CR을 삭제합니다. 

      $ oc delete volumesnapshotcontent --all
      Copy to Clipboard Toggle word wrap

    4. 보호된 네임스페이스에서 PVC를 삭제하고 Operator가 설치된 네임스페이스를 삭제합니다. 

      $ oc delete pvc -n <protected_namespace> --all
      Copy to Clipboard Toggle word wrap

    5. 네임스페이스에서 ReplicationSource 리소스를 삭제합니다. 

      $ oc delete replicationsource -n <protected_namespace> --all
      Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 Data Mover를 사용하여 복원 작업 후에도 남아 있는 클러스터 리소스를 정리합니다.

    1. VSR CRD를 삭제합니다. 

      $ oc delete vsr -n <app-ns> --all
      Copy to Clipboard Toggle word wrap

    2. VolumeSnapshot CR을 삭제합니다. 

      $ oc delete volumesnapshot -A --all
      Copy to Clipboard Toggle word wrap

    3. VolumeSnapshotContent CR을 삭제합니다. 

      $ oc delete volumesnapshotcontent --all
      Copy to Clipboard Toggle word wrap

    4. 네임스페이스에서 ReplicationDestination 리소스를 삭제합니다. 

      $ oc delete replicationdestination -n <protected_namespace> --all
      Copy to Clipboard Toggle word wrap

4.10. OADP 1.3 Data Mover
링크 복사

4.10.1. OADP 1.3 Data Mover 정보
링크 복사

OADP 1.3에는 CSI(Container Storage Interface) 볼륨 스냅샷을 원격 오브젝트 저장소로 이동하는 데 사용할 수 있는 기본 제공 데이터 Mover가 포함되어 있습니다. 기본 제공 Data Mover를 사용하면 오류, 실수로 삭제 또는 클러스터 손상이 발생하는 경우 원격 오브젝트 저장소에서 상태 저장 애플리케이션을 복원할 수 있습니다. Kopia 를 업로드기 메커니즘으로 사용하여 스냅샷 데이터를 읽고 통합 리포지토리에 씁니다.

OADP는 다음에서 CSI 스냅샷을 지원합니다.

  • Red Hat OpenShift Data Foundation
  • Kubernetes Volume Snapshot API를 지원하는 CSI(Container Storage Interface) 드라이버가 있는 기타 클라우드 스토리지 공급자
중요

OADP 내장 Data Mover는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

4.10.1.1. 기본 제공 데이터 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 

# ...
Copy to Clipboard Toggle word wrap

1
노드 에이전트를 활성화하는 플래그입니다.
2
uploader 유형입니다. 가능한 값은 restic 또는 kopia 입니다. 기본 제공 Data Mover는 uploaderType 필드의 값에 관계없이 Kopia를 기본 업로드기 메커니즘으로 사용합니다.
3
기본 플러그인 목록에 포함된 CSI 플러그인입니다.

기본 제공 Data Mover 기능에는 백업 및 복원을 관리하기 위해 CRD로 정의된 새로운 API 오브젝트 3개가 도입되었습니다.

  • DataDownload: 볼륨 스냅샷의 데이터 다운로드를 나타냅니다. CSI 플러그인은 복원할 볼륨당 하나의 DataDownload 오브젝트를 생성합니다. DataDownload CR에는 대상 볼륨, 지정된 데이터 Mover, 현재 데이터 다운로드의 진행 상황, 지정된 백업 리포지토리 및 프로세스가 완료된 후 현재 데이터 다운로드 결과가 포함됩니다.
  • DataUpload: 볼륨 스냅샷의 데이터 업로드를 나타냅니다. CSI 플러그인은 CSI 스냅샷당 하나의 DataUpload 오브젝트를 생성합니다. DataUpload CR에는 지정된 스냅샷, 지정된 데이터 Mover, 지정된 백업 리포지토리, 현재 데이터 업로드 진행률, 프로세스가 완료된 후 현재 데이터 업로드 결과가 포함됩니다.
  • BackupRepository: 백업 리포지토리의 라이프사이클을 나타내며 관리합니다. OADP는 네임스페이스에 대한 첫 번째 CSI 스냅샷 백업 또는 복원이 요청되면 네임스페이스당 백업 리포지토리를 생성합니다.

4.10.2. CSI 스냅샷 백업 및 복원
링크 복사

OADP 1.3 Data Mover를 사용하여 영구 볼륨을 백업하고 복원할 수 있습니다.

4.10.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에 추가했습니다.

절차

  1. 다음 예와 같이 Backup 오브젝트에 대한 YAML 파일을 생성합니다.

    Backup CR의 예

    kind: Backup
apiVersion: velero.io/v1
metadata:
  name: backup
  namespace: openshift-adp
spec:
  csiSnapshotTimeout: 10m0s
  defaultVolumesToFsBackup: false
  includedNamespaces:
  - mysql-persistent
  itemOperationTimeout: 4h0m0s
  snapshotMoveData: true
    1 
    
  storageLocation: default
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - dpa-sample-1
# ...
    Copy to Clipboard Toggle word wrap

    1
    CSI 스냅샷을 원격 오브젝트 스토리지로 이동하려면 true 로 설정합니다.
    참고

    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
    Copy to Clipboard Toggle word wrap

    이 시나리오에서는 백업이 성공적으로 완료되도록 볼륨 크기 조정 또는 다른 파일 시스템 유형(예: ext4 )을 사용하는 것이 좋습니다.

  2. 매니페스트를 적용합니다. 

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

    DataUpload CR은 스냅샷 생성이 완료된 후 생성됩니다.

검증

  • DataUpload CR의 status.phase 필드를 모니터링하여 스냅샷 데이터가 원격 오브젝트 저장소로 성공적으로 전송되었는지 확인합니다. 가능한 값은 진행 중 ,완료됨,실패 또는 취소됨 입니다. 오브젝트 저장소는 DataProtectionApplication CR의 backupLocations 스탠자에 구성됩니다.

    • 다음 명령을 실행하여 모든 DataUpload 오브젝트 목록을 가져옵니다. 

      $ oc get datauploads -A
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

    • 다음 명령을 실행하여 특정 DataUpload 오브젝트의 status.phase 필드 값을 확인합니다. 

      $ oc get datauploads <dataupload_name> -o yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      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"
      Copy to Clipboard Toggle word wrap

      1
      스냅샷 데이터가 원격 오브젝트 저장소로 성공적으로 전송되었음을 나타냅니다.
4.10.2.2. CSI 볼륨 스냅샷 복원
링크 복사

Restore CR을 생성하여 볼륨 스냅샷을 복원할 수 있습니다.

참고

OAPD 1.3 기본 제공 데이터 Mover를 사용하여 OADP 1.2의 reflectsync 백업을 복원할 수 없습니다. OADP 1.3으로 업그레이드하기 전에 Restic을 사용하여 모든 워크로드의 파일 시스템 백업을 수행하는 것이 좋습니다.

사전 요구 사항

  • cluster-admin 역할을 사용하여 클러스터에 액세스할 수 있습니다.
  • 데이터를 복원할 OADP Backup CR이 있습니다.

절차

  1. 다음 예와 같이 Restore CR에 대한 YAML 파일을 생성합니다.

    Restore CR의 예

    apiVersion: velero.io/v1
kind: Restore
metadata:
  name: restore
  namespace: openshift-adp
spec:
  backupName: <backup>
# ...
    Copy to Clipboard Toggle word wrap

  2. 매니페스트를 적용합니다. 

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

    복원이 시작될 때 DataDownload CR이 생성됩니다.

검증

  • DataDownload CR의 status.phase 필드를 확인하여 복원 프로세스의 상태를 모니터링할 수 있습니다. 가능한 값은 진행 중 ,완료됨,실패 또는 취소됨 입니다.

    • 모든 DataDownload 오브젝트 목록을 가져오려면 다음 명령을 실행합니다. 

      $ oc get datadownloads -A
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

    • 다음 명령을 입력하여 특정 DataDownload 오브젝트의 status.phase 필드 값을 확인합니다. 

      $ oc get datadownloads <datadownload_name> -o yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      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"
      Copy to Clipboard Toggle word wrap

      1
      CSI 스냅샷 데이터가 성공적으로 복원되었음을 나타냅니다.

4.11. 문제 해결
링크 복사

OpenShift CLI 툴 또는 Velero CLI 툴 을 사용하여 Velero 사용자 정의 리소스(CR)를 디버깅할 수 있습니다. Velero CLI 툴에서는 더 자세한 로그 및 정보를 제공합니다.

설치 문제,백업 및 복원 CR 문제 및 Restic 문제를 확인할 수 있습니다.

must-gather 툴 을 사용하여 로그 및 CR 정보를 수집할 수 있습니다.

다음을 통해 Velero CLI 툴을 가져올 수 있습니다.

  • Velero CLI 툴 다운로드
  • 클러스터의 Velero 배포에서 Velero 바이너리에 액세스

4.11.1. Velero CLI 툴 다운로드
링크 복사

Velero 문서 페이지의 지침에 따라 Velero CLI 툴을 다운로드하여 설치할 수 있습니다.

페이지에는 다음에 대한 지침이 포함되어 있습니다.

  • Homebrew를 사용하여 macOS
  • GitHub
  • Chocolatey를 사용하여 Windows

사전 요구 사항

  • DNS 및 컨테이너 네트워킹이 활성화된 Kubernetes 클러스터 v1.16 이상에 액세스할 수 있습니다.
  • kubectl 을 로컬로 설치했습니다.

절차

  1. 브라우저를 열고 Velero 웹 사이트에서 "Install the CLI" 로 이동합니다.
  2. macOS, GitHub 또는 Windows에 대한 적절한 절차를 따르십시오.
  3. OADP 및 OpenShift Container Platform 버전에 적합한 Velero 버전을 다운로드합니다.
4.11.1.1. OADP-Velero-OpenShift Container Platform 버전 관계
링크 복사
Expand
OADP 버전Velero 버전OpenShift Container Platform 버전

1.1.0

1.9

4.9 이상

1.1.1

1.9

4.9 이상

1.1.2

1.9

4.9 이상

1.1.3

1.9

4.9 이상

1.1.4

1.9

4.9 이상

1.1.5

1.9

4.9 이상

1.1.6

1.9

4.11 이상

1.1.7

1.9

4.11 이상

1.2.0

1.11

4.11 이상

1.2.1

1.11

4.11 이상

1.2.2

1.11

4.11 이상

1.2.3

1.11

4.11 이상

1.3.0

1.12

4.10 - 4.15

1.3.1

1.12

4.10 - 4.15

1.3.2

1.12

4.10 - 4.15

1.3.3

1.12

4.10 - 4.15

4.11.2. 클러스터의 Velero 배포에서 Velero 바이너리에 액세스
링크 복사

shell 명령을 사용하여 클러스터의 Velero 배포에서 Velero 바이너리에 액세스할 수 있습니다.

사전 요구 사항

  • DataProtectionApplication 사용자 정의 리소스의 상태는 Reconcile complete.

절차

  • 다음 명령을 입력하여 필요한 별칭을 설정합니다. 

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
    Copy to Clipboard Toggle word wrap

4.11.3. OpenShift CLI 툴을 사용하여 Velero 리소스 디버깅
링크 복사

OpenShift CLI 툴을 사용하여 Velero 사용자 정의 리소스(CR) 및 Velero Pod 로그를 확인하여 실패한 백업 또는 복원을 디버깅할 수 있습니다.

Velero CR

oc describe 명령을 사용하여 Backup 또는 Restore CR과 관련된 경고 및 오류 요약을 검색합니다. 

$ oc describe <velero_cr> <cr_name>
Copy to Clipboard Toggle word wrap
Velero 포드 로그

oc logs 명령을 사용하여 Velero 포드 로그를 검색합니다. 

$ oc logs pod/<velero>
Copy to Clipboard Toggle word wrap
Velero pod 디버그 로그

다음 예와 같이 DataProtectionApplication 리소스에서 Velero 로그 수준을 지정할 수 있습니다.

참고

이 옵션은 OADP 1.0.3부터 사용할 수 있습니다. 

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
spec:
  configuration:
    velero:
      logLevel: warning
Copy to Clipboard Toggle word wrap

다음 logLevel 값을 사용할 수 있습니다.

  • Trace
  • debug
  • info
  • 경고
  • error
  • fatal
  • panic

대부분의 로그에 debug 를 사용하는 것이 좋습니다.

4.11.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>
Copy to Clipboard Toggle word wrap

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql
Copy to Clipboard Toggle word wrap

도움말 옵션

velero --help 옵션을 사용하여 모든 Velero CLI 명령을 나열합니다. 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  --help
Copy to Clipboard Toggle word wrap
Describe 명령

velero describe 명령을 사용하여 Backup 또는 Restore CR과 관련된 경고 및 오류 요약을 검색합니다. 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> describe <cr_name>
Copy to Clipboard Toggle word wrap

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql
Copy to Clipboard Toggle word wrap

다음 유형의 복원 오류 및 경고는 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>
Copy to Clipboard Toggle word wrap

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
Copy to Clipboard Toggle word wrap

4.11.5. 메모리 또는 CPU 부족으로 인해 Pod 충돌 또는 재시작
링크 복사

메모리 또는 CPU 부족으로 인해 Velero 또는 Restic Pod가 충돌하는 경우 해당 리소스 중 하나에 대한 특정 리소스 요청을 설정할 수 있습니다.

4.11.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
    Copy to Clipboard Toggle word wrap

    1
    나열된 resourceAllocations 는 평균 사용량입니다.
4.11.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
    Copy to Clipboard Toggle word wrap

    1
    나열된 resourceAllocations 는 평균 사용량입니다.
중요

리소스 요청 필드의 값은 Kubernetes 리소스 요구 사항과 동일한 형식을 따라야 합니다. 또한 configuration.velero.podConfig.resourceAllocations 또는 configuration.restic.podConfig.resourceAllocations 를 지정하지 않으면 Velero Pod 또는 Restic Pod의 기본 리소스 사양은 다음과 같습니다. 

requests:
  cpu: 500m
  memory: 128Mi
Copy to Clipboard Toggle word wrap

4.11.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
Copy to Clipboard Toggle word wrap

원인

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
Copy to Clipboard Toggle word wrap
1
레이블, 주석, 이름 또는 네임스페이스와 같은 PVC 메타데이터를 사용하여 디렉터리 경로를 생성하기 위한 템플릿을 지정합니다. 메타데이터를 지정하려면 ${.PVC.<metadata>} 를 사용합니다. 예를 들어 폴더의 이름을 < pvc-namespace>-<pvc-name >로 지정하려면 ${.PVC.namespace}-${.PVC.name} 을 pathPattern 으로 사용합니다.

4.11.7. Velero 및 승인 Webhook 관련 문제
링크 복사

Velero는 복원 중 승인 Webhook 문제를 해결할 수 있는 기능이 제한되어 있습니다. 승인 Webhook가 있는 워크로드가 있는 경우 추가 Velero 플러그인을 사용하거나 워크로드를 복원하는 방법을 변경해야 할 수 있습니다.

일반적으로 승인 Webhook가 있는 워크로드에서는 먼저 특정 종류의 리소스를 생성해야 합니다. 승인 Webhook가 일반적으로 하위 리소스를 차단하기 때문에 워크로드에 하위 리소스가 있는 경우 특히 중요합니다.

예를 들어 service.serving.knative.dev 와 같은 최상위 오브젝트를 생성하거나 복원하면 일반적으로 하위 리소스가 자동으로 생성됩니다. 먼저 이 작업을 수행하는 경우 Velero를 사용하여 이러한 리소스를 생성하고 복원할 필요가 없습니다. 그러면 Velero가 사용할 수 있는 승인 Webhook에 의해 차단되는 하위 리소스의 문제를 방지할 수 있습니다.

4.11.7.1. 승인 Webhook를 사용하는 Velero 백업의 해결방법 복원
링크 복사

이 섹션에서는 승인 Webhook를 사용하는 여러 유형의 Velero 백업에 대한 리소스를 복원하는 데 필요한 추가 단계를 설명합니다.

4.11.7.1.1. Knative 리소스 복원
링크 복사

승인 Webhook를 사용하는 Knative 리소스를 백업하려면 Velero를 사용하여 문제가 발생할 수 있습니다.

승인 Webhook를 사용하는 Knative 리소스를 백업 및 복원할 때마다 최상위 서비스 리소스를 복원하여 이러한 문제를 방지할 수 있습니다.

절차

  • 최상위 서비스.serving.knavtive.dev Service 리소스를 복원합니다. 

    $ velero restore <restore_name> \
  --from-backup=<backup_name> --include-resources \
  service.serving.knavtive.dev
    Copy to Clipboard Toggle word wrap
4.11.7.1.2. IBM AppConnect 리소스 복원
링크 복사

승인 Webhook가 있는 IBM AppConnect 리소스를 복원하기 위해 Velero를 사용할 때 문제가 발생하는 경우 이 프로세스에서 검사를 실행할 수 있습니다.

절차

  1. 클러스터에 변경 승인 플러그인이 있는지 확인합니다 : MutatingWebhookConfiguration. 

    $ oc get mutatingwebhookconfigurations
    Copy to Clipboard Toggle word wrap
  2. 각 kind: MutatingWebhookConfiguration 의 YAML 파일을 검사하여 문제가 발생한 오브젝트의 규칙 블록 생성이 없는지 확인합니다. 자세한 내용은 공식 Kubernetes 설명서를 참조하십시오.
  3. 유형에 있는 spec.version: Configuration.appconnect.ibm.com/v1beta1 이 설치된 Operator에서 지원되는지 확인합니다.
4.11.7.2. OADP 플러그인의 알려진 문제
링크 복사

다음 섹션에서는 OADP(OpenShift API for Data Protection) 플러그인의 알려진 문제에 대해 설명합니다.

백업 및 백업 스토리지 위치(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…
Copy to Clipboard Toggle word wrap
4.11.7.2.1.1. 패닉 오류를 방지하기 위한 해결방법
링크 복사

Velero 플러그인 패닉 오류를 방지하려면 다음 단계를 수행합니다.

  1. 관련 라벨을 사용하여 사용자 지정 BSL에 레이블을 지정합니다. 

    $ oc label BackupStorageLocation <bsl_name> app.kubernetes.io/component=bsl
    Copy to Clipboard Toggle word wrap

  2. BSL 레이블이 지정된 후 DPA가 조정될 때까지 기다립니다.

    참고

    DPA 자체를 약간 변경하여 강제로 조정할 수 있습니다.

  3. 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'
    Copy to Clipboard Toggle word wrap
4.11.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.11.7.2.2.1. OpenShift ADP 컨트롤러 분할 오류 해결
링크 복사

DPA를 구성할 때 velero 또는 cloudstorage 를 정의해야 합니다. DPA에 두 API를 모두 정의하면 크래시 루프 분할 오류와 함께 openshift-adp-controller-manager Pod가 실패합니다.

4.11.7.3. Velero 플러그인에서 "received EOF, stop recv loop" 메시지를 반환
링크 복사
참고

Velero 플러그인은 별도의 프로세스로 시작됩니다. Velero 작업이 성공적으로 완료되거나 실패하면 종료됩니다. 디버그 로그에서 recv 루프 메시지를 중지하여 수신된 EOF 를 수신하면 플러그인 작업이 완료되었음을 나타냅니다. 이는 오류가 발생했음을 의미하지 않습니다.

4.11.8. 설치 문제
링크 복사

데이터 보호 애플리케이션을 설치할 때 유효하지 않은 디렉토리 또는 잘못된 인증 정보를 사용하여 발생한 문제가 발생할 수 있습니다.

4.11.8.1. 백업 스토리지에는 잘못된 디렉터리가 포함되어 있습니다.
링크 복사

Velero 포드 로그에 오류 메시지가 표시되고 Backup 스토리지에 잘못된 최상위 디렉터리가 포함되어 있습니다.

원인

오브젝트 스토리지에는 Velero 디렉터리가 아닌 최상위 디렉터리가 포함되어 있습니다.

해결책

오브젝트 스토리지가 Velero 전용이 아닌 경우 DataProtectionApplication 매니페스트에서 spec.backupLocations.velero.objectStorage.prefix 매개변수를 설정하여 버킷에 대한 접두사를 지정해야 합니다.

4.11.8.2. 잘못된 AWS 인증 정보
링크 복사

oadp-aws-registry Pod 로그에는 오류 메시지, InvalidAccessKeyId: 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
Copy to Clipboard Toggle word wrap

1
AWS 기본 프로필.
2
따옴표로 값을 묶지 마십시오(", '.).

4.11.9. OADP Operator 문제
링크 복사

OADP(OpenShift API for Data Protection) Operator는 해결할 수 없는 문제로 인해 문제가 발생할 수 있습니다.

4.11.9.1. OADP Operator가 자동으로 실패
링크 복사

OADP Operator의 S3 버킷은 비어 있을 수 있지만 oc get po -n <OADP_Operator_namespace> 명령을 실행하면 Operator의 상태가 Running 임을 확인할 수 있습니다. 이러한 경우 Operator는 실행 중이라고 잘못 보고하기 때문에 자동으로 실패했다고 합니다.

원인

클라우드 인증 정보가 충분하지 않은 권한을 제공하는 경우 문제가 발생합니다.

해결책

백업 스토리지 위치(BSL) 목록을 검색하고 인증 정보 문제는 각 BSL의 매니페스트를 확인합니다.

절차

  1. 다음 명령 중 하나를 실행하여 BSL 목록을 검색합니다.

    1. OpenShift CLI 사용: 

      $ oc get backupstoragelocation -A
      Copy to Clipboard Toggle word wrap

    2. Velero CLI 사용: 

      $ velero backup-location get -n <OADP_Operator_namespace>
      Copy to Clipboard Toggle word wrap

  2. BSL 목록을 사용하여 다음 명령을 실행하여 각 BSL의 매니페스트를 표시하고 각 매니페스트에 오류가 있는지 검사합니다. 

    $ oc get backupstoragelocation -n <namespace> -o yaml
    Copy to Clipboard Toggle word wrap

결과 예

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: ""
Copy to Clipboard Toggle word wrap

4.11.10. OADP 시간 초과
링크 복사

시간 제한을 늘리면 복잡하고 리소스를 많이 사용하는 프로세스가 조기 종료되지 않고 성공적으로 완료할 수 있습니다. 이 구성을 사용하면 오류, 재시도 또는 실패 가능성을 줄일 수 있습니다.

프로세스의 기본 문제를 숨길 수 있는 과도하게 긴 시간 초과를 구성하지 않도록 시간 초과 확장의 균형을 조정해야 합니다. 프로세스 및 전체 시스템 성능을 충족하는 적절한 시간 초과 값을 신중하게 고려하고 모니터링합니다.

다음은 이러한 매개변수를 구현하는 방법과 시기에 대한 지침이 포함된 다양한 OADP 시간 초과입니다.

4.11.10.1. Restic 타임아웃
링크 복사

시간 초과는 Restic 타임아웃을 정의합니다. 기본값은 1h 입니다.

다음 시나리오에 대해 Restic 타임아웃 을 사용합니다.

  • 500GB보다 큰 총 PV 데이터 사용량이 있는 Restic 백업의 경우

  • 다음 오류로 인해 백업이 시간 초과되는 경우: 

    level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete"
    Copy to Clipboard Toggle word wrap

절차

  • 다음 예와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.restic.timeout 블록에서 값을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: <dpa_name>
spec:
  configuration:
    restic:
      timeout: 1h
# ...
    Copy to Clipboard Toggle word wrap
4.11.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
# ...
    Copy to Clipboard Toggle word wrap
4.11.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
# ...
    Copy to Clipboard Toggle word wrap
4.11.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
# ...
    Copy to Clipboard Toggle word wrap
4.11.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
# ...
    Copy to Clipboard Toggle word wrap
4.11.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
# ...
    Copy to Clipboard Toggle word wrap
4.11.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
# ...
    Copy to Clipboard Toggle word wrap

4.11.11. CR 백업 및 복원 문제
링크 복사

백업 및 CR(사용자 정의 리소스)과 관련된 일반적인 문제가 발생할 수 있습니다.

4.11.11.1. 백업 CR은 볼륨을 검색할 수 없음
링크 복사

Backup CR에 오류 메시지 InvalidVolume.NotFound: 볼륨 'vol-xxxx'가 존재하지 않습니다.

원인

PV(영구 볼륨) 및 스냅샷 위치는 다른 지역에 있습니다.

해결책

  1. DataProtectionApplication 매니페스트에서 spec.snapshotLocations.velero.config.region 키 값을 편집하여 스냅샷 위치가 PV와 동일한 리전에 있도록 합니다.
  2. 새 Backup CR을 생성합니다.
4.11.11.2. 백업 CR 상태가 진행 중임
링크 복사

Backup CR의 상태는 InProgress 단계에 남아 있으며 완료되지 않습니다.

원인

백업이 중단되면 다시 시작할 수 없습니다.

해결책

  1. Backup CR의 세부 정보를 검색합니다. 

    $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
  backup describe <backup>
    Copy to Clipboard Toggle word wrap

  2. Backup CR을 삭제합니다. 

    $ oc delete backup <backup> -n openshift-adp
    Copy to Clipboard Toggle word wrap

    진행중인 Backup CR이 오브젝트 스토리지에 파일을 업로드하지 않았기 때문에 백업 위치를 정리할 필요가 없습니다.

  3. 새 Backup CR을 생성합니다.

  4. Velero 백업 세부 정보 보기 

    $ velero backup describe <backup-name> --details
    Copy to Clipboard Toggle word wrap
4.11.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
Copy to Clipboard Toggle word wrap

해결책

  1. Backup CR을 삭제합니다. 

    $ oc delete backup <backup> -n openshift-adp
    Copy to Clipboard Toggle word wrap
  2. 필요하면 BackupStorageLocation 에서 저장된 데이터를 정리하여 공간을 확보합니다.

  3. VolumeSnapshotClass 오브젝트에 velero.io/csi-volumesnapshot-class=true 라벨을 적용합니다. 

    $ oc label volumesnapshotclass/<snapclass_name> velero.io/csi-volumesnapshot-class=true
    Copy to Clipboard Toggle word wrap
  4. 새 Backup CR을 생성합니다.

4.11.12. Restic 문제
링크 복사

Restic을 사용하여 애플리케이션을 백업할 때 이러한 문제가 발생할 수 있습니다.

4.11.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를 추가하여 이 문제를 해결할 수 있습니다.

  1. NFS 데이터 볼륨에서 Restic 에 대한 추가 그룹을 생성합니다.
  2. 그룹 소유권이 상속되도록 NFS 디렉터리에 setgid 비트를 설정합니다.

  3. 다음 예와 같이 spec.configuration.restic.supplementalGroups 매개변수와 그룹 ID를 DataProtectionApplication 매니페스트에 추가합니다. 

    spec:
  configuration:
    restic:
      enable: true
      supplementalGroups:
      - <group_id>
    1
    Copy to Clipboard Toggle word wrap
    1
    보조 그룹 ID를 지정합니다.
  4. 변경 사항을 적용할 수 있도록 Restic Pod가 다시 시작될 때까지 기다립니다.
4.11.12.2. Restic Backup CR은 버킷을 꺼진 후 다시 생성할 수 없습니다.
링크 복사

네임스페이스에 대한 Restic Backup CR을 생성하고 오브젝트 스토리지 버킷을 비우고 동일한 네임스페이스에 Backup CR을 다시 생성하면 다시 만든 Backup CR이 실패합니다.

velero Pod 로그에는 다음과 같은 오류 메시지가 표시됩니다. stderr=Fatal: unable to open config file: criteria: specified key does not exist.\nIs there a repository at the following location?.

원인

Velero는 Restic 디렉터리가 오브젝트 스토리지에서 삭제되면 ResticRepository 매니페스트에서 Restic 리포지토리를 다시 생성하거나 업데이트하지 않습니다. 자세한 내용은 Velero issue 4421 을 참조하십시오.

해결책

  • 다음 명령을 실행하여 네임스페이스에서 관련 Restic 리포지토리를 제거합니다. 

    $ oc delete resticrepository openshift-adp <name_of_the_restic_repository>
    Copy to Clipboard Toggle word wrap

    다음 오류 로그에서 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
    Copy to Clipboard Toggle word wrap

4.11.13. must-gather 툴 사용
링크 복사

must-gather 툴을 사용하여 OADP 사용자 정의 리소스에 대한 로그, 메트릭 및 정보를 수집할 수 있습니다.

must-gather 데이터는 모든 고객 사례에 첨부되어야 합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

절차

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. 다음 데이터 수집 옵션 중 하나에 대해 oc adm must-gather 명령을 실행합니다.
4.11.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>
Copy to Clipboard Toggle word wrap

기본적으로 플래그 값은 false 로 설정됩니다. 안전하지 않은 TLS 연결을 허용하려면 값을 true 로 설정합니다.

4.11.13.2. must-gather 툴을 사용할 때 옵션 결합
링크 복사

현재 must-gather 스크립트를 결합할 수 없습니다(예: 비보안 TLS 연결을 허용하는 동안 시간 초과 임계값 지정). 다음 예와 같이 must-gather 명령줄에서 내부 변수를 설정하여 이러한 제한 사항을 해결할 수 있습니다. 

$ oc adm must-gather --image=brew.registry.redhat.io/rh-osbs/oadp-oadp-mustgather-rhel8:1.1.1-8  -- skip_tls=true /usr/bin/gather_with_timeout <timeout_value_in_seconds>
Copy to Clipboard Toggle word wrap

이 예제에서는 gather_with_timeout 스크립트를 실행하기 전에 skip_tls 변수를 설정합니다. 결과는 gather_with_timeout 및 gather_without_tls 의 조합입니다.

이렇게 지정할 수 있는 다른 변수는 다음과 같습니다.

  • logs_since 기본 값이 72h
  • request_timeout, 기본값 0s

4.11.14. OADP 모니터링
링크 복사

OpenShift Container Platform에서는 사용자와 관리자가 클러스터를 효과적으로 모니터링 및 관리할 수 있는 모니터링 스택을 제공하고, 이벤트가 발생하는 경우 경고 수신을 포함하여 클러스터에서 실행되는 사용자 애플리케이션 및 서비스의 워크로드 성능을 모니터링 및 분석할 수 있습니다.

4.11.14.1. OADP 모니터링 설정
링크 복사

OADP Operator는 Velero 서비스 끝점에서 지표를 검색하기 위해 OpenShift 모니터링 스택에서 제공하는 OpenShift 사용자 워크로드 모니터링을 활용합니다. 모니터링 스택을 사용하면 OpenShift Metrics 쿼리 프런트 엔드를 사용하여 사용자 정의 경고 규칙을 생성하거나 지표를 쿼리할 수 있습니다.

활성화된 사용자 워크로드 모니터링을 사용하면 Grafana와 같은 Prometheus 호환 타사 UI를 구성하고 사용하여 Velero 지표를 시각화할 수 있습니다.

메트릭을 모니터링하려면 사용자 정의 프로젝트를 모니터링하고 ServiceMonitor 리소스를 생성하여 openshift-adp 네임스페이스에 있는 이미 활성화된 OADP 서비스 끝점에서 해당 메트릭을 스크랩해야 합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • 클러스터 모니터링 구성 맵이 생성되어 있습니다.

절차

  1. openshift-monitoring 네임스페이스에서 cluster-monitoring-config ConfigMap 오브젝트를 편집합니다. 

    $ oc edit configmap cluster-monitoring-config -n openshift-monitoring
    Copy to Clipboard Toggle word wrap

  2. data 섹션의 config.yaml 필드에 enableUserWorkload 옵션을 추가하거나 활성화합니다. 

    apiVersion: v1
data:
  config.yaml: |
    enableUserWorkload: true
    1 
    
kind: ConfigMap
metadata:
# ...
    Copy to Clipboard Toggle word wrap
    1
    이 옵션을 추가하거나 true로 설정합니다.

  3. 다음 구성 요소가 openshift-user-workload-monitoring 네임스페이스에서 실행 중인지 확인하여 짧은 시간 동안 User Workload Monitoring Setup을 확인합니다. 

    $ oc get pods -n openshift-user-workload-monitoring
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  4. openshift-user-workload-monitoring 에 user-workload-monitoring-config ConfigMap이 있는지 확인합니다. 존재하는 경우 이 절차의 나머지 단계를 건너뜁니다. 

    $ oc get configmap user-workload-monitoring-config -n openshift-user-workload-monitoring
    Copy to Clipboard Toggle word wrap

    출력 예

    Error from server (NotFound): configmaps "user-workload-monitoring-config" not found
    Copy to Clipboard Toggle word wrap

  5. 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: |
    Copy to Clipboard Toggle word wrap

  6. 2_configure_user_workload_monitoring.yaml 파일을 적용합니다. 

    $ oc apply -f 2_configure_user_workload_monitoring.yaml
configmap/user-workload-monitoring-config created
    Copy to Clipboard Toggle word wrap
4.11.14.2. OADP 서비스 모니터 생성
링크 복사

OADP는 DPA가 구성될 때 생성되는 openshift-adp-velero-metrics-svc 서비스를 제공합니다. 사용자 워크로드 모니터링에서 사용하는 서비스 모니터는 정의된 서비스를 가리켜야 합니다.

다음 명령을 실행하여 서비스에 대한 세부 정보를 가져옵니다.

절차

  1. openshift-adp-velero-metrics-svc 서비스가 있는지 확인합니다. ServiceMonitor 오브젝트의 선택기로 사용할 app.kubernetes.io/name=velero 레이블이 포함되어야 합니다. 

    $ oc get svc -n openshift-adp -l app.kubernetes.io/name=velero
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
openshift-adp-velero-metrics-svc   ClusterIP   172.30.38.244   <none>        8085/TCP   1h
    Copy to Clipboard Toggle word wrap

  2. 기존 서비스 레이블과 일치하는 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"
    Copy to Clipboard Toggle word wrap

  3. 3_create_oadp_service_monitor.yaml 파일을 적용합니다. 

    $ oc apply -f 3_create_oadp_service_monitor.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    servicemonitor.monitoring.coreos.com/oadp-service-monitor created
    Copy to Clipboard Toggle word wrap

검증

  • OpenShift Container Platform 웹 콘솔의 관리자 화면을 사용하여 새 서비스 모니터가 Up 상태인지 확인합니다.

    1. 모니터링 → 대상 페이지로 이동합니다.
    2. 필터 가 선택되지 않았거나 사용자 소스가 선택되어 있는지 확인하고 텍스트 검색 필드에 openshift-adp 를 입력합니다.

    3. 서비스 모니터의 상태 상태가 Up 인지 확인합니다.

      그림 4.1. OADP 메트릭 대상

      OADP 메트릭 대상
      View larger image
      OADP 메트릭 대상
4.11.14.3. 경고 규칙 생성
링크 복사

OpenShift Container Platform 모니터링 스택을 사용하면 경고 규칙을 사용하여 구성된 경고를 수신할 수 있습니다. OADP 프로젝트에 대한 경고 규칙을 생성하려면 사용자 워크로드 모니터링으로 스크랩되는 지표 중 하나를 사용합니다.

절차

  1. 샘플 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
    Copy to Clipboard Toggle word wrap

    이 샘플에서는 다음 조건 아래에 경고가 표시됩니다.

    • 지난 2시간 동안 0보다 큰 새 오류 백업이 증가하고 상태가 최소 5분 동안 지속됩니다.
    • 첫 번째 증가 시간이 5분 미만이면 경고가 Pending 상태가 되고 그 후에는 실행 중 상태가 됩니다.

  2. openshift-adp 네임스페이스에 PrometheusRule 오브젝트를 생성하는 4_create_oadp_alert_rule.yaml 파일을 적용합니다. 

    $ oc apply -f 4_create_oadp_alert_rule.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    prometheusrule.monitoring.coreos.com/sample-oadp-alert created
    Copy to Clipboard Toggle word wrap

검증

  • 경고가 트리거되면 다음과 같은 방법으로 볼 수 있습니다.

    • 개발자 화면에서 모니터링 메뉴를 선택합니다.

    • 관리자 관점에서 모니터링 → 경고 메뉴의 필터 상자에서 사용자를 선택합니다. 그렇지 않으면 기본적으로 플랫폼 경고만 표시됩니다.

      그림 4.2. OADP 백업 실패 경고

      OADP 백업 실패 경고
      View larger image
      OADP 백업 실패 경고
4.11.14.4. 사용 가능한 메트릭 목록
링크 복사

이러한 지표는 OADP가 해당 유형과 함께 제공하는 메트릭 목록입니다.

Expand
메트릭 이름설명유형

kopia_content_cache_hit_bytes

캐시에서 검색된 바이트 수

카운터

kopia_content_cache_hit_count

캐시에서 콘텐츠를 검색한 횟수

카운터

kopia_content_cache_malformed

캐시에서 잘못된 콘텐츠를 읽은 횟수

카운터

kopia_content_cache_miss_count

캐시에서 콘텐츠를 찾을 수 없고 가져온 횟수

카운터

kopia_content_cache_missed_bytes

기본 스토리지에서 검색된 바이트 수

카운터

kopia_content_cache_miss_error_count

기본 스토리지에서 콘텐츠를 찾을 수 없는 횟수

카운터

kopia_content_cache_store_error_count

캐시에 콘텐츠를 저장할 수 없는 횟수

카운터

kopia_content_get_bytes

GetContent()를 사용하여 검색된 바이트 수

카운터

kopia_content_get_count

GetContent() 가 호출된 횟수

카운터

kopia_content_get_error_count

GetContent() 가 호출된 횟수이며 결과는 오류였습니다.

카운터

kopia_content_get_not_found_count

GetContent() 가 호출된 횟수와 결과를 찾을 수 없음

카운터

kopia_content_write_bytes

WriteContent()에 전달된 바이트 수

카운터

kopia_content_write_count

WriteContent() 호출 횟수

카운터

velero_backup_attempt_total

시도된 총 백업 수

카운터

velero_backup_deletion_attempt_total

시도된 총 백업 삭제 수

카운터

velero_backup_deletion_failure_total

실패한 백업 삭제 총 수

카운터

velero_backup_deletion_success_total

성공적인 백업 삭제 총 수

카운터

velero_backup_duration_seconds

백업 완료 시간(초)

히스토그램

velero_backup_failure_total

실패한 총 백업 수

카운터

velero_backup_items_errors

백업 중 발생한 총 오류 수

게이지

velero_backup_items_total

백업된 총 항목 수

게이지

velero_backup_last_status

백업의 마지막 상태입니다. 1의 값은 success, 0입니다.

게이지

velero_backup_last_successful_timestamp

백업이 성공적으로 실행된 마지막 시간, Unix 타임스탬프(초)

게이지

velero_backup_partial_failure_total

부분적으로 실패한 백업의 총 수

카운터

velero_backup_success_total

총 성공적인 백업 수

카운터

velero_backup_tarball_size_bytes

백업의 크기(바이트)

게이지

velero_backup_total

현재 존재하는 백업 수

게이지

velero_backup_validation_failure_total

총 검증 실패 백업 수

카운터

velero_backup_warning_total

경고된 총 백업 수

카운터

velero_csi_snapshot_attempt_total

총 CSI 시도 볼륨 스냅샷 수

카운터

velero_csi_snapshot_failure_total

총 CSI 실패 볼륨 스냅샷 수

카운터

velero_csi_snapshot_success_total

총 CSI 성공 볼륨 스냅샷 수

카운터

velero_restore_attempt_total

시도한 총 복원 수

카운터

velero_restore_failed_total

실패한 총 복원 수

카운터

velero_restore_partial_failure_total

부분적으로 실패한 복원의 총 수

카운터

velero_restore_success_total

성공적인 총 복원 수

카운터

velero_restore_total

현재 존재하는 복원 수

게이지

velero_restore_validation_failed_total

검증에 실패한 총 복원 수

카운터

velero_volume_snapshot_attempt_total

시도한 총 볼륨 스냅샷 수

카운터

velero_volume_snapshot_failure_total

실패한 총 볼륨 스냅샷 수

카운터

velero_volume_snapshot_success_total

총 볼륨 스냅샷 수

카운터

4.11.14.5. 모니터링 UI를 사용하여 메트릭 보기
링크 복사

OpenShift Container Platform 웹 콘솔의 관리자 또는 개발자 화면에서 메트릭을 볼 수 있습니다. openshift-adp 프로젝트에 액세스할 수 있어야 합니다.

프로세스

  • 모니터링 → 메트릭 페이지로 이동합니다.

    • 개발자 화면을 사용하는 경우 다음 단계를 따르십시오.

      1. 사용자 지정 쿼리 를 선택하거나 PromQL 표시 링크를 클릭합니다.
      2. 쿼리를 입력하고 Enter 를 클릭합니다.

    • 관리자 화면을 사용하는 경우 텍스트 필드에 표현식을 입력하고 Run Queries 를 선택합니다.

      그림 4.3. OADP 메트릭 쿼리

      OADP 메트릭 쿼리
      View larger image
      OADP 메트릭 쿼리

4.12. OADP와 함께 사용되는 API
링크 복사

이 문서에서는 OADP와 함께 사용할 수 있는 다음 API에 대한 정보를 제공합니다.

  • Velero API
  • OADP API

4.12.1. Velero API
링크 복사

Velero API 문서는 Red Hat이 아닌 Velero에서 유지 관리합니다. Velero API 유형에서 찾을 수 있습니다.

4.12.2. OADP API
링크 복사

다음 표에서는 OADP API의 구조를 제공합니다.

Expand
표 4.2. DataProtectionApplicationSpec
속성유형설명

backupLocations

[] BackupLocation

BackupStorageLocations 에 사용할 구성 목록을 정의합니다.

snapshotLocations

[] SnapshotLocation

VolumeSnapshotLocations 에 사용할 구성 목록을 정의합니다.

unsupportedOverrides

map [ UnsupportedImageKey ] string

개발을 위해 배포된 종속 이미지를 재정의하는 데 사용할 수 있습니다. 옵션은 veleroImageFqin,awsPluginImageFqin,openshiftPluginImageFqin,azurePluginImageFqin,gcpPluginImageFqin,csiPluginImageFqin,dataMoverImageFqin, resticRestoreImageFqin,kubevirtPluginImageFqin, operator-type.

podAnnotations

map [ string ] string

Operator에서 배포한 Pod에 주석을 추가하는 데 사용됩니다.

podDnsPolicy

DNSPolicy

Pod의 DNS 구성을 정의합니다.

podDnsConfig

PodDNSConfig

DNSPolicy 에서 생성된 항목에 더하여 Pod의 DNS 매개변수를 정의합니다.

backupImages

*bool

이미지 백업 및 복원을 활성화하기 위해 레지스트리를 배포할지 여부를 지정하는 데 사용됩니다.

configuration

*ApplicationConfig

데이터 보호 애플리케이션의 서버 구성을 정의하는 데 사용됩니다.

features

*Features

기술 프리뷰 기능을 활성화하는 DPA 구성을 정의합니다.

OADP API의 전체 스키마 정의.

Expand
표 4.3. 백업 위치
속성유형설명

velero

*velero.BackupStorageLocationSpec

Backup Storage 위치에 설명된 대로 볼륨 스냅샷을 저장할 위치입니다.

bucket

*CloudStorageLocation

[기술 프리뷰]는 백업 스토리지 위치로 사용하기 위해 일부 클라우드 스토리지 공급자에서 버킷 생성을 자동화합니다.

중요

bucket 매개변수는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

BackupLocation유형의 전체 스키마 정의입니다.

Expand
표 4.4. 스냅샷 위치
속성유형설명

velero

*VolumeSnapshotLocationSpec

Volume Snapshot Location 에 설명된 대로 볼륨 스냅샷을 저장할 위치입니다.

SnapshotLocation유형의 전체 스키마 정의입니다.

Expand
표 4.5. ApplicationConfig
속성유형설명

velero

*VeleroConfig

Velero 서버의 구성을 정의합니다.

Restic

*ResticConfig

Restic 서버에 대한 구성을 정의합니다.

ApplicationConfig유형의 전체 스키마 정의

Expand
표 4.6. VeleroConfig
속성유형설명

featureFlags

[] 문자열

Velero 인스턴스에 사용할 기능 목록을 정의합니다.

defaultPlugins

[] 문자열

다음 유형의 기본 Velero 플러그인을 설치할 수 있습니다. aws,azure,csi,gcp,kubevirt, openshift.

customPlugins

[]CustomPlugin

사용자 지정 Velero 플러그인 설치에 사용됩니다.

기본 및 사용자 지정 플러그인은 OADP 플러그인에설명되어 있습니다.

restoreResourcesVersionPriority

string

EnableAPIGroupVersions 기능 플래그와 함께 사용하기 위해 정의된 경우 생성된 구성 맵을 나타냅니다. 이 필드를 정의하면 Velero 서버 기능 플래그에 EnableAPIGroupVersions 가 자동으로 추가됩니다.

noDefaultBackupLocation

bool

기본 백업 스토리지 위치 없이 Velero를 설치하려면 설치를 확인하려면 noDefaultBackupLocation 플래그를 설정해야 합니다.

podConfig

*PodConfig

Velero 포드의 구성을 정의합니다.

logLevel

string

Velero 서버의 로그 수준(가장 세분화된 로깅에 debug 를 사용하고 Velero 기본값에 대해 설정되지 않은 상태로 유지됨). 유효한 옵션은 trace,debug,info,warning,error,fatal, panic 입니다.

VeleroConfig유형의 전체 스키마 정의

Expand
표 4.7. 사용자 지정 플러그인
속성유형설명

name

string

사용자 지정 플러그인의 이름입니다.

image

string

사용자 지정 플러그인의 이미지입니다.

CustomPlugin유형의 전체 스키마 정의.

Expand
표 4.8. ResticConfig
속성유형설명

enable

*bool

true 로 설정하면 Restic을 사용하여 백업 및 복원을 활성화합니다. false 로 설정하면 스냅샷이 필요합니다.

supplementalGroups

[]int64

Restic 포드에 적용할 Linux 그룹을 정의합니다.

timeout

string

Restic 타임아웃을 정의하는 사용자 제공 기간 문자열입니다. 기본값은 1hr (1시간)입니다. 기간 문자열은 10진수의 부호 있는 시퀀스이며 각각 선택적 분수와 300ms, -1.5h' 또는 2h45m 과 같은 단위 접미사가 있습니다. 유효한 시간 단위는 ns, us (or µs), ms, s, m, h 입니다.

podConfig

*PodConfig

Restic pod의 구성을 정의합니다.

ResticConfig유형의 전체 스키마 정의

Expand
표 4.9. PodConfig
속성유형설명

nodeSelector

map [ string ] string

Velero podSpec 또는 Restic podSpec 에 제공할 nodeSelector 를 정의합니다. 자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.

허용 오차

[] 톨러레이션

Velero 배포 또는 Restic daemonset에 적용할 허용 오차 목록을 정의합니다.

resourceAllocations

ResourceRequirements

Velero CPU 및 메모리 리소스 할당 설정에 설명된 대로 Velero Pod 또는 Restic Pod에 대한 특정 리소스 limits 및 requests 설정합니다.

labels

map [ string ] string

Pod에 추가할 레이블입니다.

PodConfig유형의 전체 스키마 정의

4.12.2.1. 노드 에이전트 및 노드 라벨 구성
링크 복사

OADP의 DPA는 nodeSelector 필드를 사용하여 노드 에이전트를 실행할 수 있는 노드를 선택합니다. nodeSelector 필드는 권장되는 노드 선택 제약 조건의 가장 간단한 형식입니다.

지정된 라벨은 각 노드의 라벨과 일치해야 합니다.

선택하는 노드에서 노드 에이전트를 실행하는 올바른 방법은 사용자 정의 라벨을 사용하여 노드에 레이블을 지정하는 것입니다. 

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
Copy to Clipboard Toggle word wrap

노드에 레이블을 지정하는 데 사용한 DPA.spec.configuration.nodeAgent.podConfig.nodeSelector 에서 동일한 사용자 지정 레이블을 사용합니다. 예를 들면 다음과 같습니다. 

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""
Copy to Clipboard Toggle word wrap

다음 예제는 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: ""
Copy to Clipboard Toggle word wrap
Expand
표 4.10. 기능
속성유형설명

dataMover

*DataMover

데이터 Mover의 구성을 정의합니다.

유형 Features에 대한 전체 스키마 정의입니다.

Expand
표 4.11. 데이터 이동자
속성유형설명

enable

bool

true 로 설정하면 볼륨 스냅샷 mover 컨트롤러와 수정된 CSI Data Mover 플러그인을 배포합니다. false 로 설정하면 이러한 항목이 배포되지 않습니다.

credentialName

string

Data Mover의 사용자 제공 Restic Secret 이름입니다.

timeout

string

VolumeSnapshotBackup 및 VolumeSnapshotRestore 에 대한 사용자 제공 기간 문자열입니다. 기본값은 10m (10분)입니다. 기간 문자열은 10진수의 부호 있는 시퀀스이며 각각 선택적 분수와 300ms, -1.5h' 또는 2h45m 과 같은 단위 접미사가 있습니다. 유효한 시간 단위는 ns, us (or µs), ms, s, m, h 입니다.

OADP API는 OADP Operator 에 더 자세히 설명되어 있습니다.

4.13. 고급 OADP 기능 및 기능
링크 복사

이 문서에서는 OADP(OpenShift API for Data Protection)의 고급 기능 및 기능에 대한 정보를 제공합니다.

4.13.1. 동일한 클러스터에서 다양한 Kubernetes API 버전 사용
링크 복사

4.13.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
Copy to Clipboard Toggle word wrap
4.13.1.2. API 그룹 버전 활성화 정보
링크 복사

기본적으로 Velero는 기본 Kubernetes API 버전을 사용하는 리소스만 백업합니다. 그러나 Velero에는 이러한 제한을 극복하는 Enable API Group Versions 기능도 포함되어 있습니다. 소스 클러스터에서 활성화하면 이 기능을 통해 Velero가 선호하는 Kubernetes API 그룹 버전뿐만 아니라 클러스터에서 지원되는 모든 Kubernetes API 그룹 버전을 백업합니다. 버전이 백업 .tar 파일에 저장되면 대상 클러스터에서 복원할 수 있습니다.

예를 들어 Example 이라는 API가 있는 소스 클러스터는 example.com/v1 및 example.com/v1beta2 API 그룹에서 사용할 수 있으며 example.com/v1 은 기본 API입니다.

API 그룹 버전 활성화 기능이 활성화되지 않으면 Velero는 예제에 대해 기본 API 그룹 버전만 백업합니다( Example, example.com/v1 ). 기능이 활성화된 경우 Velero는 example.com/v1beta2 도 백업합니다.

대상 클러스터에서 API 그룹 버전 활성화 기능이 활성화된 경우 Velero는 API 그룹 버전의 우선 순위 순서에 따라 복원할 버전을 선택합니다.

참고

Enable API Group Versions는 아직 베타 버전입니다.

Velero는 다음 알고리즘을 사용하여 API 버전에 우선순위를 할당하고 1 을 가장 높은 우선 순위로 할당합니다.

  1. 대상 클러스터의 기본 버전
  2. 기본 버전의 source_ cluster
  3. Kubernetes 버전 우선 순위가 가장 높은 일반 지원되지 않는 버전
4.13.1.3. API 그룹 버전 사용
링크 복사

Velero의 Enable API Group Versions 기능을 사용하여 선호하는 Kubernetes API 그룹 버전뿐만 아니라 클러스터에서 지원되는 모든 Kubernetes API 그룹 버전을 백업할 수 있습니다.

참고

Enable API Group Versions는 아직 베타 버전입니다.

프로세스

  • EnableAPIGroupVersions 기능 플래그를 구성합니다. 
apiVersion: oadp.openshift.io/vialpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      featureFlags:
      - EnableAPIGroupVersions
Copy to Clipboard Toggle word wrap

4.13.2. 한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원
링크 복사

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.13.2.1.1. Operator
링크 복사

백업 및 복원에 성공하려면 애플리케이션의 백업에서 Operator를 제외해야 합니다.

4.13.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.13.2.2. 백업할 Pod 볼륨 확인 정보
링크 복사

파일 시스템 백업(FSB)을 사용하여 백업 작업을 시작하기 전에 백업할 볼륨이 포함된 Pod를 지정해야 합니다. Velero는 이 프로세스를 적절한 Pod 볼륨을 "검색"이라고 합니다.

Velero는 Pod 볼륨을 결정하기 위해 다음 두 가지 접근 방식을 지원합니다. opt-in 또는 opt-out 접근 방식을 사용하여 Velero가 FSB, 볼륨 스냅샷 또는 Data Mover 백업을 결정할 수 있습니다. 

  • 옵트인 접근 방식: 옵트인 접근 방식을 사용하면 기본적으로 스냅샷 또는 데이터 Mover를 사용하여 볼륨이 백업됩니다. FSB는 주석으로 옵트인되는 특정 볼륨에서 사용됩니다.
  • 옵트아웃 접근 방식에서는 옵트아웃 접근 방식을 통해 기본적으로 FSB를 사용하여 볼륨이 백업됩니다. 스냅샷 또는 데이터 Mover는 주석으로 옵트아웃되는 특정 볼륨에서 사용됩니다.
4.13.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.13.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>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <your_volume_name_x>
    Pod 사양에 xth 볼륨의 이름을 지정합니다.
4.13.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>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <your_volume_name_x>
    Pod 사양에 xth 볼륨의 이름을 지정합니다.
참고

--default-volumes-to-fs-backup 플래그를 사용하여 velero install 명령을 실행하여 모든 Velero 백업에 대해 이 동작을 활성화할 수 있습니다.

4.13.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 Container Platform의 UID 및 GID 범위에 대한 자세한 내용은 OpenShift 및 UID에 대한 가이드를 참조하십시오.

4.13.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>
      Copy to Clipboard Toggle word wrap
참고

OADP 1.2 이상에서는 Velero Restic 옵션을 file-system-backup 이라고 합니다.

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 필드에 값이 설정되어 있으면 프록시가 사용됩니다.

절차

  1. 컨트롤 플레인 노드의 root로 디버그 세션을 시작합니다. 

    $ oc debug --as-root node/<node_name>
    Copy to Clipboard Toggle word wrap

  2. 디버그 쉘에서 root 디렉토리를 /host 로 변경합니다. 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap

  3. 클러스터 전체 프록시가 활성화된 경우 다음 명령을 실행하여 NO_PROXY,HTTP_PROXY 및 HTTPS_PROXY 환경 변수를 내보냅니다. 

    $ export HTTP_PROXY=http://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export NO_PROXY=<example.com>
    Copy to Clipboard Toggle word wrap

  4. 디버그 쉘에서 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
    Copy to Clipboard Toggle word wrap

    스크립트 출력 예

    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
    Copy to Clipboard Toggle word wrap

    이 예제에서는 컨트롤 플레인 호스트의 /home/core/assets/backup/ 디렉토리에 두 개의 파일이 생성됩니다.

    • snapshot_<datetimestamp>.db:이 파일은 etcd 스냅샷입니다. cluster-backup.sh 스크립트는 유효성을 확인합니다.

    • static_kuberesources_<datetimestamp>.tar.gz: 이 파일에는 정적 pod 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.

      참고

      etcd 암호화가 활성화되어 있는 경우 보안상의 이유로 이 두 번째 파일을 etcd 스냅 샷과 별도로 저장하는 것이 좋습니다. 그러나 이 파일은 etcd 스냅 샷에서 복원하는데 필요합니다.

      etcd 암호화는 키가 아닌 값만 암호화합니다. 이는 리소스 유형, 네임 스페이스 및 개체 이름은 암호화되지 않습니다.

5.2. 비정상적인 etcd 멤버 교체
링크 복사

이 문서는 비정상적인 단일 etcd 멤버를 교체하는 프로세스를 설명합니다.

이 프로세스는 시스템이 실행 중이 아니거나 노드가 준비되지 않았거나 etcd pod가 크래시 루프 상태에있는 등 etcd 멤버의 비정상적인 상태에 따라 다릅니다.

참고

대부분의 컨트롤 플레인 호스트가 손실된 경우 재해 복구 절차에 따라 이 절차 대신 이전 클러스터 상태로 복원 하십시오.

교체 중인 멤버 에서 컨트롤 플레인 인증서가 유효하지 않은 경우 이 절차 대신 만료된 컨트롤 플레인 인증서 복구 절차를 따라야 합니다.

컨트롤 플레인 노드가 유실되고 새 노드가 생성되는 경우 etcd 클러스터 Operator는 새 TLS 인증서 생성 및 노드를 etcd 멤버로 추가하는 프로세스를 진행합니다.

5.2.1. 사전 요구 사항
링크 복사

5.2.2. 비정상 etcd 멤버 식별
링크 복사

클러스터에 비정상적인 etcd 멤버가 있는지 여부를 확인할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 다음 명령을 사용하여 EtcdMembersAvailable 상태의 상태 조건을 확인하십시오. 

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}'
    Copy to Clipboard Toggle word wrap

  2. 출력을 확인합니다. 

    2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy
    Copy to Clipboard Toggle word wrap

    이 출력 예는 ip-10-0-131-183.ec2.internal etcd 멤버가 비정상임을 보여줍니다.

5.2.3. 비정상적인 etcd 멤버의 상태 확인
링크 복사

비정상적인 etcd 멤버를 교체하는 프로세스는 etcd가 다음의 어떤 상태에 있는지에 따라 달라집니다.

  • 컴퓨터가 실행 중이 아니거나 노드가 준비되지 않았습니다.
  • etcd pod가 크래시 루프 상태에 있습니다.

다음 프로세스에서는 etcd 멤버가 어떤 상태에 있는지를 확인합니다. 이를 통해 비정상 etcd 멤버를 대체하기 위해 수행해야하는 단계를 확인할 수 있습니다.

참고

시스템이 실행되고 있지 않거나 노드가 준비되지 않았지만 곧 정상 상태로 돌아올 것으로 예상되는 경우 etcd 멤버를 교체하기 위한 절차를 수행할 필요가 없습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 비정상적인 etcd 멤버를 식별하고 있습니다.

프로세스

  1. 시스템이 실행되고 있지 않은지를 확인합니다. 

    $ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running
    Copy to Clipboard Toggle word wrap

    출력 예

    ip-10-0-131-183.ec2.internal  stopped
    1
    Copy to Clipboard Toggle word wrap

    1
    이 출력은 노드와 노드 시스템의 상태를 나열합니다. 상태가 running이 아닌 경우 시스템은 실행되지 않습니다.

    시스템이 실행되고 있지 않은 경우, 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

  2. 노드가 준비되지 않았는지 확인합니다.

    다음 조건 중 하나에 해당하면 노드가 준비되지 않은 것입니다.

    • 시스템이 실행중인 경우 노드에 액세스할 수 있는지 확인하십시오. 

      $ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable
      Copy to Clipboard Toggle word wrap

      출력 예

      ip-10-0-131-183.ec2.internal	node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable
      1
      Copy to Clipboard Toggle word wrap

      1
      unreachable 상태의 노드가 나열되면 노드가 준비되지 않은 것 입니다.

    • 노드에 여전히 액세스할 수 있는 경우 노드가 NotReady로 나열되어 있는지 확인하십시오. 

      $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"
      Copy to Clipboard Toggle word wrap

      출력 예

      ip-10-0-131-183.ec2.internal   NotReady   master   122m   v1.25.0
      1
      Copy to Clipboard Toggle word wrap

      1
      노드가 NotReady로 표시되면 노드가 준비되지 않은 것입니다.

    노드가 준비되지 않은 경우 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

  3. etcd pod가 크래시 루프 상태인지 확인합니다.

    시스템이 실행되고 있고 노드가 준비된 경우 etcd pod가 크래시 루프 상태인지 확인하십시오.

    1. 모든 컨트롤 플레인 노드가 Ready 로 나열되어 있는지 확인합니다. 

      $ oc get nodes -l node-role.kubernetes.io/master
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                           STATUS   ROLES    AGE     VERSION
ip-10-0-131-183.ec2.internal   Ready    master   6h13m   v1.25.0
ip-10-0-164-97.ec2.internal    Ready    master   6h13m   v1.25.0
ip-10-0-154-204.ec2.internal   Ready    master   6h13m   v1.25.0
      Copy to Clipboard Toggle word wrap

    2. etcd pod의 상태가 Error 또는 CrashloopBackoff인지 확인하십시오. 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

      1
      이 pod의 상태는 Error이므로 etcd pod는 크래시 루프 상태입니다.

    etcd pod가 크래시 루프 상태인 경우etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

5.2.4. 비정상적인 etcd 멤버 교체
링크 복사

비정상적인 etcd 멤버의 상태에 따라 다음 절차 중 하나를 사용합니다.

다음에서는 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 경우의 비정상적인 etcd 멤버를 교체하는 프로세스에 대해 자세히 설명합니다.

참고

클러스터에서 컨트롤 플레인 머신 세트를 사용하는 경우 etcd 복구 프로시저의 "Troubleshooting the control Plane machine set"에서 "Recovering a degraded etcd Operator"를 참조하십시오.

사전 요구 사항

  • 비정상적인 etcd 멤버를 식별했습니다.

  • 시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.

    중요

    다른 컨트롤 플레인 노드의 전원이 꺼진 경우 기다려야 합니다. 비정상 etcd 멤버 교체가 완료될 때까지 컨트롤 플레인 노드의 전원을 꺼야 합니다.

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

  • etcd 백업이 수행되었습니다.

    중요

    이 절차를 수행하기 전에 문제가 발생할 경우 클러스터를 복원할 수 있도록 etcd 백업을 사용하십시오.

프로세스

  1. 비정상적인 멤버를 제거합니다.

    1. 영향을 받는 노드에 없는 Pod를 선택합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이러한 값은 절차의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. $ etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다. 

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d
      Copy to Clipboard Toggle word wrap

      출력 예

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346
      Copy to Clipboard Toggle word wrap

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

  2. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

    이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

    중요

    쿼럼 가드를 끄면 나머지 etcd 인스턴스가 재부팅되는 동안 구성 변경 사항을 반영하는 동안 클러스터에 연결할 수 없을 수 있습니다.

    참고

    두 멤버로 실행하는 경우 etcd는 추가 멤버 실패를 허용할 수 없습니다. 나머지 멤버 중 하나를 다시 시작하면 쿼럼이 중단되고 클러스터의 다운 타임이 발생합니다. 쿼럼 가드에서는 다운타임을 일으킬 수 있는 구성 변경으로 인해 etcd가 다시 시작되지 않도록 보호하므로 이 절차를 완료하려면 비활성화해야 합니다.

  3. 다음 명령을 실행하여 영향을 받는 노드를 삭제합니다. 

    $ oc delete node <node_name>
    Copy to Clipboard Toggle word wrap

    명령 예

    $ oc delete node ip-10-0-131-183.ec2.internal
    Copy to Clipboard Toggle word wrap

  4. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

  5. 다음 명령을 입력하여 컨트롤 플레인 머신 세트가 있는지 확인합니다. 

    $ oc -n openshift-machine-api get controlplanemachineset
    Copy to Clipboard Toggle word wrap

    • 컨트롤 플레인 머신 세트가 있는 경우 컨트롤 플레인 시스템을 삭제하고 다시 생성합니다. 이 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd는 자동으로 확장됩니다. 자세한 내용은 "시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체"를 참조하십시오.

      설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 컨트롤 플레인을 생성하는 데 사용된 것과 동일한 방법을 사용하여 새 컨트롤 플레인을 생성해야 합니다.

      1. 비정상 멤버의 컴퓨터를 가져옵니다.

        클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        1
        이는 비정상 노드의 컨트롤 플레인 시스템 ip-10-0-131-183.ec2.internal입니다.

      2. 비정상 멤버의 시스템을 삭제합니다. 

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

        비정상 멤버의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

      3. 새 머신이 생성되었는지 확인합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        1
        새 시스템 clustername-8qw5l-master-3이 생성되고 단계가 Provisioning에서 Running으로 변경되면 시스템이 준비 상태가 됩니다.

        새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아올 때 자동으로 동기화됩니다.

        참고

        시스템 세트에 사용하는 서브넷 ID를 확인하여 해당 ID가 올바른 가용성 영역에 속하는지 확인합니다.

    • 컨트롤 플레인 머신 세트가 없는 경우 컨트롤 플레인 시스템을 삭제하고 다시 생성합니다. 이 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd는 자동으로 확장됩니다.

      설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 컨트롤 플레인을 생성하는 데 사용된 것과 동일한 방법을 사용하여 새 컨트롤 플레인을 생성해야 합니다.

      1. 비정상 멤버의 컴퓨터를 가져옵니다.

        클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        1
        이는 비정상 노드의 컨트롤 플레인 시스템 ip-10-0-131-183.ec2.internal입니다.

      2. 시스템 설정을 파일 시스템의 파일에 저장합니다. 

        $ oc get machine clustername-8qw5l-master-0 \
        1 
        
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
        Copy to Clipboard Toggle word wrap
        1
        비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

      3. 이전 단계에서 만든 new-master-machine.yaml 파일을 편집하여 새 이름을 할당하고 불필요한 필드를 제거합니다.

        1. 전체 status 섹션을 삭제합니다. 

          status:
  addresses:
  - address: 10.0.131.183
    type: InternalIP
  - address: ip-10-0-131-183.ec2.internal
    type: InternalDNS
  - address: ip-10-0-131-183.ec2.internal
    type: Hostname
  lastUpdated: "2020-04-20T17:44:29Z"
  nodeRef:
    kind: Node
    name: ip-10-0-131-183.ec2.internal
    uid: acca4411-af0d-4387-b73e-52b2484295ad
  phase: Running
  providerStatus:
    apiVersion: awsproviderconfig.openshift.io/v1beta1
    conditions:
    - lastProbeTime: "2020-04-20T16:53:50Z"
      lastTransitionTime: "2020-04-20T16:53:50Z"
      message: machine successfully created
      reason: MachineCreationSucceeded
      status: "True"
      type: MachineCreation
    instanceId: i-0fdb85790d76d0c3f
    instanceState: stopped
    kind: AWSMachineProviderStatus
          Copy to Clipboard Toggle word wrap

        2. metadata.name 필드를 새 이름으로 변경합니다.

          이전 시스템과 동일한 기본 이름을 유지하고 종료 번호를 사용 가능한 다음 번호로 변경합니다. 이 예에서 clustername-8qw5l-master-0은 clustername-8qw5l-master-3으로 변경되어 있습니다.

          예를 들면 다음과 같습니다. 

          apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
          Copy to Clipboard Toggle word wrap

        3. spec.providerID 필드를 삭제합니다. 

            providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
          Copy to Clipboard Toggle word wrap

      4. 비정상 멤버의 시스템을 삭제합니다. 

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

      5. 시스템이 삭제되었는지 확인합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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-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
        Copy to Clipboard Toggle word wrap

      6. new-master-machine.yaml 파일을 사용하여 새 머신을 생성합니다. 

        $ oc apply -f new-master-machine.yaml
        Copy to Clipboard Toggle word wrap

      7. 새 머신이 생성되었는지 확인합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        1
        새 시스템 clustername-8qw5l-master-3이 생성되고 단계가 Provisioning에서 Running으로 변경되면 시스템이 준비 상태가 됩니다.

        새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아올 때 자동으로 동기화됩니다.

  6. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다. 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  8. 단일 노드 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]
    Copy to Clipboard Toggle word wrap

검증

  1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc -n openshift-etcd get pods -l k8s-app=etcd
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

    이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

  2. 정확히 세 개의 etcd 멤버가 있는지 확인합니다.

    1. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    2. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.

      주의

      올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다.

5.2.4.2. etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체
링크 복사

이 단계에서는 etcd pod가 크래시 루프 상태에 있는 경우 비정상 etcd 멤버를 교체하는 방법을 설명합니다.

전제 조건

  • 비정상적인 etcd 멤버를 식별했습니다.
  • etcd pod가 크래시 루프 상태에 있는것으로 확인되었습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

  • etcd 백업이 수행되었습니다.

    중요

    문제가 발생할 경우 클러스터를 복원할 수 있도록 이 프로세스를 수행하기 전에 etcd 백업을 수행해야합니다.

프로세스

  1. 크래시 루프 상태에 있는 etcd pod를 중지합니다.

    1. 크래시 루프 상태의 노드를 디버깅합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc debug node/ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      이를 비정상 노드의 이름으로 변경합니다.

    2. 루트 디렉토리를 /host 로 변경합니다. 

      sh-4.2# chroot /host
      Copy to Clipboard Toggle word wrap

    3. kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다. 

      sh-4.2# mkdir /var/lib/etcd-backup
      Copy to Clipboard Toggle word wrap 
      sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
      Copy to Clipboard Toggle word wrap

    4. etcd 데이터 디렉토리를 다른 위치로 이동합니다. 

      sh-4.2# mv /var/lib/etcd/ /tmp
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

  2. 비정상적인 멤버를 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다. 

      sh-4.2# etcdctl member remove 62bcf33650a7170a
      Copy to Clipboard Toggle word wrap

      출력 예

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346
      Copy to Clipboard Toggle word wrap

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

  3. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

    이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

  4. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

  5. etcd를 강제로 재배포합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 수행하면 모든 컨트롤 플레인 노드가 etcd pod가 작동하는지 확인합니다.

  6. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다. 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  8. 단일 노드 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]
    Copy to Clipboard Toggle word wrap

검증

  • 새 멤버가 사용 가능하고 정상적인 상태에 있는지 확인합니다.

    1. 실행중인 etcd 컨테이너에 다시 연결합니다.

      cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    2. 모든 멤버가 정상인지 확인합니다. 

      sh-4.2# etcdctl endpoint health
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

이 프로세스에서는 시스템이 실행되고 있지 않거나 노드가 준비되지 않았기 때문에 비정상 상태의 베어 메탈 etcd 멤버를 교체하는 단계를 자세히 설명합니다.

설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오. 그렇지 않으면 원래 생성하는 데 사용된 방법과 동일한 방법으로 새 컨트롤 플레인 노드를 생성해야 합니다.

사전 요구 사항

  • 비정상적인 베어 메탈 etcd 멤버를 식별했습니다.
  • 시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

  • etcd 백업이 수행되었습니다.

    중요

    문제가 발생할 경우 클러스터를 복원할 수 있도록 이 단계를 수행하기 전에 etcd 백업을 수행해야합니다.

절차

  1. 비정상 멤버를 확인하고 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      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>
      Copy to Clipboard Toggle word wrap

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
      Copy to Clipboard Toggle word wrap

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| 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 |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      Copy to Clipboard Toggle word wrap

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.

      주의

      올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다. 

      sh-4.2# etcdctl member remove 7a8197040a5126c8
      Copy to Clipboard Toggle word wrap

      출력 예

      Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b
      Copy to Clipboard Toggle word wrap

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| 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 |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

      중요

      멤버를 제거한 후 나머지 etcd 인스턴스가 재부팅되는 동안 잠시 동안 클러스터에 연결할 수 없습니다.

  2. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

    이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

  3. 다음 명령을 실행하여 제거된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2
      Copy to Clipboard Toggle word wrap

      이 프로세스의 앞부분에서 기록한 비정상 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
      Copy to Clipboard Toggle word wrap

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd

secret "etcd-peer-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-metrics-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

  4. 비정상 멤버의 컴퓨터를 가져옵니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc get machines -n openshift-machine-api -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

    1
    비정상 노드의 컨트롤 플레인 시스템 예cluster-control-plane-2.

  5. 다음 명령을 실행하여 Bare Metal Operator를 사용할 수 있는지 확인합니다. 

    $ oc get clusteroperator baremetal
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
baremetal   4.12.0    True        False         False      3d15h
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 이전 BareMetalHost 오브젝트를 제거합니다. 

    $ oc delete bmh openshift-control-plane-2 -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    출력 예

    baremetalhost.metal3.io "openshift-control-plane-2" deleted
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 실행하여 비정상 멤버의 시스템을 삭제합니다. 

    $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2
    Copy to Clipboard Toggle word wrap

    BareMetalHost 및 Machine 오브젝트를 제거한 후 머신 컨트롤러에서 Node 오브젝트를 자동으로 삭제합니다.

    어떤 이유로든 머신 삭제가 지연되거나 명령이 차단되고 지연되면 machine object finalizer 필드를 제거하여 강제로 삭제할 수 있습니다.

    중요

    Ctrl+c 를 눌러 머신 삭제를 중단하지 마십시오. 명령이 완료될 수 있도록 허용해야 합니다. 새 터미널 창을 열어 편집하여 종료자 필드를 삭제합니다.

    비정상 멤버의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

    1. 다음 명령을 실행하여 머신 구성을 편집합니다. 

      $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
      Copy to Clipboard Toggle word wrap

    2. Machine 사용자 정의 리소스에서 다음 필드를 삭제한 다음 업데이트된 파일을 저장합니다. 

      finalizers:
- machine.machine.openshift.io
      Copy to Clipboard Toggle word wrap

      출력 예

      machine.machine.openshift.io/examplecluster-control-plane-2 edited
      Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 시스템이 삭제되었는지 확인합니다. 

    $ oc get machines -n openshift-machine-api -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  9. 다음 명령을 실행하여 노드가 삭제되었는지 확인합니다. 

    $ oc get nodes

NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 3h24m v1.25.0
openshift-control-plane-1 Ready master 3h24m v1.25.0
openshift-compute-0       Ready worker 176m v1.25.0
openshift-compute-1       Ready worker 176m v1.25.0
    Copy to Clipboard Toggle word wrap

  10. 새 BareMetalHost 오브젝트와 시크릿을 생성하여 BMC 자격 증명을 저장합니다. 

    $ 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/sda
  userData:
    name: master-user-data-managed
    namespace: openshift-machine-api
EOF
    Copy to Clipboard Toggle word wrap
    참고

    사용자 이름과 암호는 다른 베어 메탈 호스트의 시크릿에서 찾을 수 있습니다. bmc:address 에 사용할 프로토콜은 다른 bmh 개체에서 가져올 수 있습니다.

    중요

    기존 컨트롤 플레인 호스트에서 BareMetalHost 오브젝트 정의를 재사용하는 경우 external Provisioned 필드를 true 로 설정하지 마십시오.

    기존 컨트롤 플레인 BareMetalHost 오브젝트는 OpenShift Container Platform 설치 프로그램에서 프로비저닝한 경우 외부Provisioned 플래그를 true 로 설정할 수 있습니다.

    검사가 완료되면 BareMetalHost 오브젝트가 생성되고 프로비저닝할 수 있습니다.

  11. 사용 가능한 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
    Copy to Clipboard Toggle word wrap

    1. 새 시스템이 생성되었는지 확인합니다. 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

      1
      새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비 상태가 됩니다.

      새 시스템을 생성하는 데 몇 분이 걸릴 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

    2. 베어 메탈 호스트가 프로비저닝되고 다음 명령을 실행하여 오류가 보고되지 않았는지 확인합니다. 

      $ oc get bmh -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      출력 예

      $ 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
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하여 새 노드가 추가되고 준비 상태에 있는지 확인합니다. 

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

      출력 예

      $ oc get nodes
NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 4h26m v1.25.0
openshift-control-plane-1 Ready master 4h26m v1.25.0
openshift-control-plane-2 Ready master 12m   v1.25.0
openshift-compute-0       Ready worker 3h58m v1.25.0
openshift-compute-1       Ready worker 3h58m v1.25.0
      Copy to Clipboard Toggle word wrap

  12. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

  13. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다. 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  14. 단일 노드 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]
    Copy to Clipboard Toggle word wrap

검증

  1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc -n openshift-etcd get pods -l k8s-app=etcd
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

    이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    정확히 세 개의 etcd 멤버가 있는지 확인하려면 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
    Copy to Clipboard Toggle word wrap

  2. 멤버 목록을 확인합니다. 

    sh-4.2# etcdctl member list -w table
    Copy to Clipboard Toggle word wrap

    출력 예

    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
|        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 |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    Copy to Clipboard Toggle word wrap

    참고

    이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.

  3. 다음 명령을 실행하여 모든 etcd 멤버가 정상인지 확인합니다. 

    # etcdctl endpoint health --cluster
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 모든 노드가 최신 버전인지 확인합니다. 

    $ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    Copy to Clipboard Toggle word wrap 
    AllNodesAtLatestRevision
    Copy to Clipboard Toggle word wrap

5.3. 호스팅된 클러스터에서 etcd 백업 및 복원
링크 복사

OpenShift Container Platform에서 호스팅되는 컨트롤 플레인을 사용하는 경우 etcd를 백업하고 복원하는 프로세스는 일반적인 etcd 백업 프로세스 와 다릅니다.

중요

호스트 컨트롤 플레인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

5.3.1. 호스팅된 클러스터에서 etcd의 스냅샷 찍기
링크 복사

호스팅된 클러스터의 etcd를 백업하는 프로세스의 일부로 etcd의 스냅샷을 만듭니다. 예를 들어 재해 복구 작업의 일부로 스냅샷을 복원할 수 있습니다.

중요

이 절차를 수행하려면 API 다운 타임이 필요합니다.

절차

  1. 다음 명령을 입력하여 호스팅 클러스터의 조정을 일시 중지합니다. 

    $ oc patch -n clusters hostedclusters/${CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 모든 etcd-writer 배포를 중지합니다. 

    $ oc scale deployment -n ${HOSTED_CLUSTER_NAMESPACE} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver
    Copy to Clipboard Toggle word wrap

  3. 각 etcd 컨테이너에서 exec 명령을 사용하여 etcd 스냅샷을 만듭니다. 

    $ oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db
$ oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db
    Copy to Clipboard Toggle word wrap

  4. 다음 예와 같이 나중에 검색할 수 있는 위치에 스냅샷 데이터를 복사합니다.

    참고

    다음 예제에서는 서명 버전 2를 사용합니다. us-east-2 리전과 같이 서명 버전 4를 지원하는 리전에 있는 경우 서명 버전 4를 사용합니다. 그렇지 않으면 서명 버전 2를 사용하여 스냅샷을 S3 버킷에 복사하는 경우 업로드가 실패하고 서명 버전 2는 더 이상 사용되지 않습니다.

    예제

    BUCKET_NAME=somebucket
FILEPATH="/${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"
CONTENT_TYPE="application/x-compressed-tar"
DATE_VALUE=`date -R`
SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}"
ACCESS_KEY=accesskey
SECRET_KEY=secret
SIGNATURE_HASH=`echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac ${SECRET_KEY} -binary | base64`

oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- curl -X PUT -T "/var/lib/data/snapshot.db" \
  -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \
  -H "Date: ${DATE_VALUE}" \
  -H "Content-Type: ${CONTENT_TYPE}" \
  -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \
  https://${BUCKET_NAME}.s3.amazonaws.com/${CLUSTER_NAME}-snapshot.db
    Copy to Clipboard Toggle word wrap

  5. 나중에 새 클러스터에서 스냅샷을 복원하려면 다음 예와 같이 호스팅된 클러스터 참조 암호화 시크릿을 저장합니다.

    예제

    oc get hostedcluster $CLUSTER_NAME -o=jsonpath='{.spec.secretEncryption.aescbc}'
{"activeKey":{"name":"CLUSTER_NAME-etcd-encryption-key"}}

# Save this secret, or the key it contains so the etcd data can later be decrypted
oc get secret ${CLUSTER_NAME}-etcd-encryption-key -o=jsonpath='{.data.key}'
    Copy to Clipboard Toggle word wrap

다음 단계

etcd 스냅샷을 복원하십시오.

5.3.2. 호스팅된 클러스터에서 etcd 스냅샷 복원
링크 복사

호스팅된 클러스터의 etcd 스냅샷이 있는 경우 복원할 수 있습니다. 현재는 클러스터 생성 중에만 etcd 스냅샷을 복원할 수 있습니다.

etcd 스냅샷을 복원하려면 create cluster --render 명령에서 출력을 수정하고 HostedCluster 사양의 etcd 섹션에 restoreSnapshotURL 값을 정의합니다.

사전 요구 사항

호스팅된 클러스터에서 etcd 스냅샷을 가져왔습니다.

절차

  1. aws CLI(명령줄 인터페이스)에서 인증 정보를 etcd 배포에 전달하지 않고 S3에서 etcd 스냅샷을 다운로드할 수 있도록 사전 서명된 URL을 생성합니다. 

    ETCD_SNAPSHOT=${ETCD_SNAPSHOT:-"s3://${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"}
ETCD_SNAPSHOT_URL=$(aws s3 presign ${ETCD_SNAPSHOT})
    Copy to Clipboard Toggle word wrap

  2. URL을 참조하도록 HostedCluster 사양을 수정합니다. 

    spec:
  etcd:
    managed:
      storage:
        persistentVolume:
          size: 4Gi
        type: PersistentVolume
        restoreSnapshotURL:
        - "${ETCD_SNAPSHOT_URL}"
    managementType: Managed
    Copy to Clipboard Toggle word wrap
  3. spec.secretEncryption.aescbc 값에서 참조하는 시크릿에 이전 단계에서 저장한 동일한 AES 키가 포함되어 있는지 확인합니다.

5.4. 재해 복구
링크 복사

5.4.1. 재해 복구 정보
링크 복사

재해 복구 문서에서는 관리자에게 OpenShift Container Platform 클러스터에서 발생할 수있는 여러 재해 상황을 복구하는 방법에 대한 정보를 제공합니다. 관리자는 클러스터를 작동 상태로 복원하려면 다음 절차 중 하나 이상을 수행해야합니다.

중요

재해 복구를 위해서는 하나 이상의 정상 컨트롤 플레인 호스트가 있어야 합니다.

이전 클러스터 상태로 복원

클러스터를 이전 상태로 복원하려는 경우 (예: 관리자가 일부 주요 정보를 삭제한 경우) 이 솔루션을 사용할 수 있습니다. 이에는 대부분의 컨트롤 플레인 호스트가 손실되고 etcd 쿼럼이 손실되고 클러스터가 오프라인인 상태에서도 사용할 수 있습니다. etcd 백업을 수행한 경우 이 절차에 따라 클러스터를 이전 상태로 복원할 수 있습니다.

해당하는 경우 만료된 컨트롤 플레인 인증서에서 복구해야 할 수도 있습니다.

주의

이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이 절차는 마지막 수단으로만 사용해야 합니다.

복원을 수행하기 전에 클러스터에 미치는 영향에 대한 자세한 내용은 클러스터 상태 복원을 참조하십시오.

참고

대다수의 마스터를 계속 사용할 수 있고 etcd 쿼럼이 있는 경우 절차에 따라 비정상적인 단일 etcd 멤버를 교체 합니다.

만료된 컨트롤 플레인 인증서 복구
컨트롤 플레인 인증서가 만료된 경우 이 솔루션을 사용할 수 있습니다. 예를 들어, 설치 후 24 시간 내에 발생하는 첫 번째 인증서 교체 전에 클러스터를 종료하면 인증서가 교체되지 않고 만료됩니다. 다음 단계에 따라 만료된 컨트롤 플레인 인증서를 복구할 수 있습니다.

5.4.2. 이전 클러스터 상태로 복원
링크 복사

클러스터를 이전 상태로 복원하려면 스냅샷을 생성하여 etcd 데이터를 백업해야 합니다. 이 스냅샷을 사용하여 클러스터 상태를 복구합니다. 자세한 내용은 " etcd 데이터 백업"을 참조하십시오.

5.4.2.1. 클러스터 상태 복원 정보
링크 복사

etcd 백업을 사용하여 클러스터를 이전 상태로 복원할 수 있습니다. 이를 사용하여 다음과 같은 상황에서 복구할 수 있습니다.

  • 클러스터에서 대부분의 컨트롤 플레인 호스트가 손실되었습니다(쿼럼 손실).
  • 관리자가 중요한 것을 삭제했으며 클러스터를 복구하려면 복원해야 합니다.
주의

이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이는 마지막 수단으로만 사용해야 합니다.

Kubernetes API 서버를 사용하여 데이터를 검색할 수 있는 경우 etcd를 사용할 수 있으며 etcd 백업을 사용하여 복원할 수 없습니다.

etcd를 복원하려면 클러스터를 효율적으로 복원하는 데 시간이 걸리며 모든 클라이언트가 충돌하는 병렬 기록이 발생합니다. 이는 kubelets, Kubernetes 컨트롤러 관리자, SDN 컨트롤러 및 영구 볼륨 컨트롤러와 같은 구성 요소 모니터링 동작에 영향을 줄 수 있습니다.

이로 인해 etcd의 콘텐츠가 디스크의 실제 콘텐츠와 일치하지 않을 때 Operator가 문제가 발생하여 디스크의 파일이 etcd의 콘텐츠와 충돌할 때 Kubernetes API 서버, Kubernetes 컨트롤러 관리자, Kubernetes 스케줄러 및 etcd의 Operator가 중단될 수 있습니다. 여기에는 문제를 해결하기 위해 수동 작업이 필요할 수 있습니다.

극단적인 경우 클러스터에서 영구 볼륨 추적을 손실하고, 더 이상 존재하지 않는 중요한 워크로드를 삭제하고, 시스템을 다시 이미지화하고, 만료된 인증서로 CA 번들을 다시 작성할 수 있습니다.

5.4.2.2. 이전 클러스터 상태로 복원
링크 복사

저장된 etcd 백업을 사용하여 이전 클러스터 상태를 복원하거나 대부분의 컨트롤 플레인 호스트가 손실된 클러스터를 복원할 수 있습니다.

참고

클러스터에서 컨트롤 플레인 머신 세트를 사용하는 경우 etcd 복구 프로시저의 "Troubleshooting the control Plane machine set"에서 "Recovering a degraded etcd Operator"를 참조하십시오.

중요

클러스터를 복원할 때 동일한 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를 중지할 필요가 없습니다. 다른 비 복구, 컨트롤 플레인 시스템을 삭제하고 하나씩 다시 생성할 수 있습니다.

절차

  1. 복구 호스트로 사용할 컨트롤 플레인 호스트를 선택합니다. 이는 복구 작업을 실행할 호스트입니다.

  2. 복구 호스트를 포함하여 각 컨트롤 플레인 노드에 SSH 연결을 설정합니다.

    복구 프로세스가 시작된 후에는 Kubernetes API 서버에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 다른 터미널에서 각 컨트롤 플레인 호스트에 대한 SSH 연결을 설정하는 것이 좋습니다.

    중요

    이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.

  3. etcd 백업 디렉토리를 복구 컨트롤 플레인 호스트에 복사합니다.

    이 단계에서는 etcd 스냅샷 및 정적 pod의 리소스가 포함된 backup 디렉터리를 복구 컨트롤 플레인 호스트의 /home/core/ 디렉터리에 복사하는 것을 전제로하고 있습니다.

  4. 다른 컨트롤 플레인 노드에서 고정 Pod를 중지합니다.

    참고

    복구 호스트에서 정적 Pod를 중지할 필요가 없습니다.

    1. 복구 호스트가 아닌 컨트롤 플레인 호스트에 액세스합니다.

    2. kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다. 

      $ sudo mv -v /etc/kubernetes/manifests/etcd-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

    3. etcd pod가 중지되었는지 확인합니다. 

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
      Copy to Clipboard Toggle word wrap

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

    4. kubelet 매니페스트 디렉토리에서 기존 Kubernetes API 서버 pod 파일을 이동합니다. 

      $ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

    5. Kubernetes API 서버 pod가 중지되었는지 확인합니다. 

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
      Copy to Clipboard Toggle word wrap

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

    6. etcd 데이터 디렉토리를 다른 위치로 이동합니다. 

      $ sudo mv -v /var/lib/etcd/ /tmp
      Copy to Clipboard Toggle word wrap

    7. /etc/kubernetes/manifests/keepalived.yaml 파일이 있고 노드가 삭제되면 다음 단계를 따르십시오.

      1. kubelet 매니페스트 디렉토리에서 /etc/kubernetes/manifests/keepalived.yaml 파일을 이동합니다. 

        $ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp
        Copy to Clipboard Toggle word wrap

      2. keepalived 데몬에서 관리하는 컨테이너가 중지되었는지 확인합니다. 

        $ sudo crictl ps --name keepalived
        Copy to Clipboard Toggle word wrap

        이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

      3. 컨트롤 플레인에 VIP가 할당되어 있는지 확인합니다. 

        $ ip -o address | egrep '<api_vip>|<ingress_vip>'
        Copy to Clipboard Toggle word wrap

      4. 보고된 각 VIP에 대해 다음 명령을 실행하여 제거합니다. 

        $ sudo ip address del <reported_vip> dev <reported_vip_device>
        Copy to Clipboard Toggle word wrap
    8. 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
  5. 복구 컨트롤 플레인 호스트에 액세스합니다.

  6. keepalived 데몬이 사용 중인 경우 복구 컨트롤 플레인 노드가 VIP를 소유하고 있는지 확인합니다. 

    $ ip -o address | grep <api_vip>
    Copy to Clipboard Toggle word wrap

    VIP 주소가 있는 경우 출력에 강조 표시됩니다. VIP가 잘못 설정되거나 구성되지 않은 경우 이 명령은 빈 문자열을 반환합니다.

  7. 클러스터 전체의 프록시가 활성화되어 있는 경우 NO_PROXY, HTTP_PROXY 및 https_proxy 환경 변수를 내보내고 있는지 확인합니다.

    작은 정보

    oc get proxy cluster -o yaml의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다. httpProxy, httpsProxy 및 noProxy 필드에 값이 설정되어 있으면 프록시가 사용됩니다.

  8. 복구 컨트롤 플레인 호스트에서 복원 스크립트를 실행하고 etcd 백업 디렉터리에 경로를 전달합니다. 

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/backup
    Copy to Clipboard Toggle word wrap

    스크립트 출력 예

    ...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
    Copy to Clipboard Toggle word wrap

    참고

    마지막 etcd 백업 후 노드 인증서가 업데이트된 경우 복원 프로세스에서 노드가 NotReady 상태가 될 수 있습니다.

  9. 노드가 Ready 상태에 있는지 확인합니다.

    1. 다음 명령을 실행합니다. 

      $ oc get nodes -w
      Copy to Clipboard Toggle word wrap

      샘플 출력

      NAME                STATUS  ROLES          AGE     VERSION
host-172-25-75-28   Ready   master         3d20h   v1.25.0
host-172-25-75-38   Ready   infra,worker   3d20h   v1.25.0
host-172-25-75-40   Ready   master         3d20h   v1.25.0
host-172-25-75-65   Ready   master         3d20h   v1.25.0
host-172-25-75-74   Ready   infra,worker   3d20h   v1.25.0
host-172-25-75-79   Ready   worker         3d20h   v1.25.0
host-172-25-75-86   Ready   worker         3d20h   v1.25.0
host-172-25-75-98   Ready   infra,worker   3d20h   v1.25.0
      Copy to Clipboard Toggle word wrap

      모든 노드가 상태를 보고하는 데 몇 분이 걸릴 수 있습니다.

    2. NotReady 상태인 노드가 있는 경우 노드에 로그인하고 각 노드의 /var/lib/kubelet/pki 디렉터리에서 모든 PEM 파일을 삭제합니다. 노드에 SSH를 사용하거나 웹 콘솔에서 터미널 창을 사용할 수 있습니다. 

      $  ssh -i <ssh-key-path> core@<master-hostname>
      Copy to Clipboard Toggle word wrap

      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
      Copy to Clipboard Toggle word wrap

  10. 모든 컨트롤 플레인 호스트에서 kubelet 서비스를 다시 시작합니다.

    1. 복구 호스트에서 다음 명령을 실행합니다. 

      $ sudo systemctl restart kubelet.service
      Copy to Clipboard Toggle word wrap
    2. 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.

  11. 보류 중인 CSR을 승인합니다.

    참고

    3개의 스케줄링 가능한 컨트롤 플레인 노드로 구성된 단일 노드 클러스터 또는 클러스터와 같이 작업자 노드가 없는 클러스터에는 승인할 보류 중인 CSR이 없습니다. 이 단계에서 나열된 모든 명령을 건너뛸 수 있습니다.

    1. 현재 CSR의 목록을 가져옵니다. 

      $ oc get csr
      Copy to Clipboard Toggle word wrap

      출력 예

      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 
      
...
      Copy to Clipboard Toggle word wrap

      1 2
      보류 중인 kubelet 서비스 CSR(사용자 프로비저닝 설치용)입니다.
      3 4
      보류 중인 node-bootstrapper CSR입니다.

    2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다. 

      $ oc describe csr <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

    3. 각각의 유효한 node-bootstrapper CSR을 승인합니다. 

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

    4. 사용자 프로비저닝 설치의 경우 각 유효한 kubelet 서비스 CSR을 승인합니다. 

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

  12. 단일 멤버 컨트롤 플레인이 제대로 시작되었는지 확인합니다.

    1. 복구 호스트에서 etcd 컨테이너가 실행 중인지 확인합니다. 

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
      Copy to Clipboard Toggle word wrap

      출력 예

      3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0
      Copy to Clipboard Toggle word wrap

    2. 복구 호스트에서 etcd pod가 실행 중인지 확인합니다. 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s
      Copy to Clipboard Toggle word wrap

      Pending 상태에 있거나 출력에 여러 실행중인 etcd pod가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.

  13. OVNKubernetes 네트워크 플러그인을 사용하는 경우 복구 컨트롤 플레인 호스트가 아닌 컨트롤 플레인 호스트와 연결된 노드 오브젝트를 삭제합니다. 

    $ oc delete node <non-recovery-controlplane-host-1> <non-recovery-controlplane-host-2>
    Copy to Clipboard Toggle word wrap

  14. 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>'
    Copy to Clipboard Toggle word wrap
    참고

    OVN-Kubernetes 컨트롤 플레인을 재배포하고 이전 명령을 사용하여 빈 출력을 반환하는 데 최소 5-10 분이 걸릴 수 있습니다.

  15. OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 모든 호스트에서 OVN(Open Virtual Network) Kubernetes Pod를 다시 시작합니다.

    참고

    승인 Webhook 확인 및 변경은 Pod를 거부할 수 있습니다. failurePolicy 를 Fail 로 설정하여 추가 Webhook를 추가하는 경우 Pod를 거부하고 복원 프로세스가 실패할 수 있습니다. 클러스터 상태를 복원하는 동안 Webhook를 저장하고 삭제하여 이 문제를 방지할 수 있습니다. 클러스터 상태가 성공적으로 복원되면 Webhook를 다시 활성화할 수 있습니다.

    또는 클러스터 상태를 복원하는 동안 failurePolicy 를 Ignore 로 일시적으로 설정할 수 있습니다. 클러스터 상태가 성공적으로 복원된 후 failurePolicy 를 Fail 로 설정할 수 있습니다.

    1. northbound 데이터베이스(nbdb) 및 southbound 데이터베이스(sbdb)를 제거합니다. SSH(Secure Shell)를 사용하여 복구 호스트와 나머지 컨트롤 플레인 노드에 액세스하고 다음 명령을 실행합니다. 

      $ sudo rm -f /var/lib/ovn/etc/*.db
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 모든 OVN-Kubernetes 컨트롤 플레인 Pod를 삭제합니다. 

      $ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하여 OVN-Kubernetes 컨트롤 플레인 Pod가 다시 배포되고 Running 상태에 있는지 확인합니다. 

      $ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                   READY   STATUS    RESTARTS   AGE
ovnkube-master-nb24h   4/4     Running   0          48s
      Copy to Clipboard Toggle word wrap

    4. 다음 명령을 실행하여 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
      Copy to Clipboard Toggle word wrap

    5. 다음 명령을 실행하여 OVN Pod의 상태를 확인합니다. 

      $ oc get po -n openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap

      1. OVN Pod가 종료 상태에 있는 경우 다음 명령을 실행하여 해당 OVN Pod를 실행 중인 노드를 삭제합니다. & lt;node >를 삭제 중인 노드의 이름으로 바꿉니다. 

        $ oc delete node <node>
        Copy to Clipboard Toggle word wrap

      2. 다음 명령을 실행하여 SSH를 사용하여 종료 상태의 OVN pod 노드에 로그인합니다. 

        $ ssh -i <ssh-key-path> core@<node>
        Copy to Clipboard Toggle word wrap

      3. 다음 명령을 실행하여 /var/lib/kubelet/pki 디렉토리에서 모든 PEM 파일을 이동합니다. 

        $ sudo mv /var/lib/kubelet/pki/* /tmp
        Copy to Clipboard Toggle word wrap

      4. 다음 명령을 실행하여 kubelet 서비스를 다시 시작합니다. 

        $ sudo systemctl restart kubelet.service
        Copy to Clipboard Toggle word wrap

      5. 다음 명령을 실행하여 복구 etcd 머신으로 돌아갑니다. 

        $ oc get csr
        Copy to Clipboard Toggle word wrap

        출력 예

        NAME        AGE    SIGNERNAME                         REQUESTOR                     CONDITION
csr-<uuid>   8m3s   kubernetes.io/kubelet-serving     system:node:<node_name>       Pending
        Copy to Clipboard Toggle word wrap

      6. 다음 명령을 실행하여 새 CSR을 모두 승인하고 csr-<uuid&gt;를 CSR 이름으로 교체하십시오. 

        oc adm certificate approve csr-<uuid>
        Copy to Clipboard Toggle word wrap

      7. 다음 명령을 실행하여 노드가 다시 있는지 확인합니다. 

        $ oc get nodes
        Copy to Clipboard Toggle word wrap

    6. 모든 ovnkube-node Pod가 다시 배포되어 다음 명령을 실행하여 Running 상태인지 확인합니다. 

      $ oc get  pods -n openshift-ovn-kubernetes | grep ovnkube-node
      Copy to Clipboard Toggle word wrap

  16. 복구되지 않는 다른 컨트롤 플레인 시스템을 삭제하고 하나씩 다시 생성합니다. 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd가 자동으로 확장됩니다.

    • 사용자가 프로비저닝한 베어 메탈 설치를 사용하는 경우 원래 사용했던 것과 동일한 방법을 사용하여 컨트롤 플레인 시스템을 다시 생성할 수 있습니다. 자세한 내용은 " 베어 메탈에 사용자 프로비저닝 클러스터 설치"를 참조하십시오.

      주의

      복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.

    • 설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오.

      주의

      복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.

      설치 관리자 프로비저닝 인프라에 베어 메탈 설치의 경우 컨트롤 플레인 머신이 다시 생성되지 않습니다. 자세한 내용은 " 베어 메탈 컨트롤 플레인 노드 교체"를 참조하십시오.

      1. 손실된 컨트롤 플레인 호스트 중 하나에 대한 시스템을 가져옵니다.

        cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예: 

        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
        Copy to Clipboard Toggle word wrap
        1
        이는 손실된 컨트롤 플레인 호스트 ip-10-0-131-183.ec2.internal 의 컨트롤 플레인 시스템입니다.

      2. 다음을 실행하여 손실된 컨트롤 플레인 호스트의 시스템을 삭제합니다. 

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

        손실된 컨트롤 플레인 호스트의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

      3. 다음을 실행하여 새 시스템이 생성되었는지 확인합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예: 

        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
        Copy to Clipboard Toggle word wrap
        1
        새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비 상태가 됩니다.

        새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

      4. 복구 호스트가 아닌 각 손실된 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.

  17. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

    이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

  18. 복구 호스트 내의 별도의 터미널 창에서 다음 명령을 실행하여 복구 kubeconfig 파일을 내보냅니다. 

    $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
    Copy to Clipboard Toggle word wrap

  19. etcd를 강제로 재배포합니다.

    복구 kubeconfig 파일을 내보낸 동일한 터미널 창에서 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 실행하면 기존 노드가 초기 부트 스트랩 확장과 유사한 새 pod를 사용하기 시작합니다.

  20. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

  21. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다. 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  22. 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    Copy to Clipboard Toggle word wrap

    etcd의 NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

    AllNodesAtLatestRevision
3 nodes are at revision 7
    1
    Copy to Clipboard Toggle word wrap
    1
    이 예에서 최신 버전 번호는 7입니다.

    출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

  23. etcd를 재배포한 후 컨트롤 플레인에 새 롤아웃을 강제 실행합니다. kubelet이 내부 로드 밸런서를 사용하여 API 서버에 연결되어 있으므로 Kubernetes API 서버는 다른 노드에 다시 설치됩니다.

    cluster-admin 사용자로 클러스터에 액세스할 수있는 터미널에서 다음 명령을 실행합니다.

    1. Kubernetes API 서버에 대해 새 롤아웃을 강제 적용합니다. 

      $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
      Copy to Clipboard Toggle word wrap

      모든 노드가 최신 버전으로 업데이트되었는지 확인합니다. 

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    2. Kubernetes 컨트롤러 관리자에 대해 새 롤아웃을 강제 적용합니다. 

      $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
      Copy to Clipboard Toggle word wrap

      모든 노드가 최신 버전으로 업데이트되었는지 확인합니다. 

      $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    3. Kubernetes 스케줄러에 대해 새 롤아웃을 강제 적용합니다. 

      $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
      Copy to Clipboard Toggle word wrap

      모든 노드가 최신 버전으로 업데이트되었는지 확인합니다. 

      $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

  24. 모든 컨트롤 플레인 호스트가 클러스터를 시작하여 참여하고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc -n openshift-etcd get pods -l k8s-app=etcd
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

복구 절차에 따라 모든 워크로드가 일반 작업으로 돌아가도록 하려면 Kubernetes API 정보를 저장하는 각 Pod를 다시 시작합니다. 여기에는 라우터, Operator 및 타사 구성 요소와 같은 OpenShift Container Platform 구성 요소가 포함됩니다.

참고

이전 절차 단계를 완료하면 모든 서비스가 복원된 상태로 돌아올 때까지 몇 분 정도 기다려야 할 수 있습니다. 예를 들어, OAuth 서버 pod가 다시 시작될 때까지 oc login을 사용한 인증이 즉시 작동하지 않을 수 있습니다.

즉각적인 인증을 위해 system:admin kubeconfig 파일을 사용하는 것이 좋습니다. 이 방법은 OAuth 토큰에 대해 SSL/TLS 클라이언트 인증서에 대한 인증을 기반으로 합니다. 다음 명령을 실행하여 이 파일로 인증할 수 있습니다. 

$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 인증된 사용자 이름을 표시합니다. 

$ oc whoami
Copy to Clipboard Toggle word wrap
5.4.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 형식이어야합니다.

절차

  1. SSH를 사용하여 각 컨트롤 플레인 노드에 연결합니다.

    복구 프로세스가 시작된 후에는 Kubernetes API 서버에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 별도의 터미널에서 액세스하려는 각 컨트롤 플레인 호스트에 SSH 연결을 사용하는 것이 좋습니다.

    중요

    이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.

  2. etcd 백업 디렉터리를 각 컨트롤 플레인 호스트에 복사합니다.

    이 절차에서는 etcd 스냅샷과 정적 pod의 리소스가 포함된 백업 디렉터리를 각 컨트롤 플레인 호스트의 /home/core/assets 디렉터리에 복사하는 것을 전제로 합니다. 아직 존재하지 않는 경우 이러한 assets 폴더를 생성해야 할 수도 있습니다.

  3. 모든 컨트롤 플레인 노드에서 정적 Pod를 중지합니다. 한 번에 하나의 호스트입니다.

    1. kubelet 매니페스트 디렉터리에서 기존 Kubernetes API Server 정적 Pod를 표시합니다. 

      $ mkdir -p /root/manifests-backup
$ mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /root/manifests-backup/
      Copy to Clipboard Toggle word wrap

    2. 명령을 사용하여 Kubernetes API 서버 컨테이너가 중지되었는지 확인합니다. 

      $ crictl ps | grep kube-apiserver | grep -E -v "operator|guard"
      Copy to Clipboard Toggle word wrap

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

    3. Kubernetes API Server 컨테이너가 계속 실행 중인 경우 다음 명령을 사용하여 수동으로 종료합니다. 

      $ crictl stop <container_id>
      Copy to Clipboard Toggle word wrap

    4. kube-controller-manager-pod.yaml,kube-scheduler-pod.yaml 및 마지막으로 etcd-pod.yaml 에 대해 동일한 단계를 반복합니다.

      1. 다음 명령을 사용하여 kube-controller-manager Pod를 중지합니다. 

        $ mv /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /root/manifests-backup/
        Copy to Clipboard Toggle word wrap

      2. 다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다. 

        $ crictl ps | grep kube-controller-manager | grep -E -v "operator|guard"
        Copy to Clipboard Toggle word wrap

      3. 다음 명령을 사용하여 kube-scheduler Pod를 중지합니다. 

        $ mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /root/manifests-backup/
        Copy to Clipboard Toggle word wrap

      4. 다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다. 

        $ crictl ps | grep kube-scheduler | grep -E -v "operator|guard"
        Copy to Clipboard Toggle word wrap

      5. 다음 명령을 사용하여 etcd pod를 중지합니다. 

        $ mv /etc/kubernetes/manifests/etcd-pod.yaml /root/manifests-backup/
        Copy to Clipboard Toggle word wrap

      6. 다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다. 

        $ crictl ps | grep etcd | grep -E -v "operator|guard"
        Copy to Clipboard Toggle word wrap

  4. 각 컨트롤 플레인 호스트에서 현재 etcd 데이터를 백업 폴더로 이동하여 저장합니다. 

    $ mkdir /home/core/assets/old-member-data
$ mv /var/lib/etcd/member /home/core/assets/old-member-data
    Copy to Clipboard Toggle word wrap

    이 데이터는 etcd 백업 복원이 작동하지 않고 etcd 클러스터를 현재 상태로 복원해야 하는 경우 유용합니다.

  5. 각 컨트롤 플레인 호스트에 대해 올바른 etcd 매개변수를 찾습니다.

    1. < 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: ").+(?=")'
      Copy to Clipboard Toggle word wrap

    2. < UUID&gt;의 값은 명령을 사용하여 컨트롤 플레인 호스트에서 생성할 수 있습니다. 

      $ uuidgen
      Copy to Clipboard Toggle word wrap
      참고

      < UUID> 의 값은 한 번만 생성되어야 합니다. 하나의 컨트롤 플레인 호스트에서 UUID 를 생성한 후 다른 컨트롤 플레인 호스트에서 다시 생성하지 마십시오. 모든 컨트롤 플레인 호스트의 다음 단계에서 동일한 UUID 를 사용합니다.

    3. ETCD_NODE_PEER_URL 의 값은 다음 예와 같이 설정해야 합니다. 

      https://<IP_CURRENT_HOST>:2380
      Copy to Clipboard Toggle word wrap

      올바른 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 '(?<=").+(?=")'
      Copy to Clipboard Toggle word wrap

    4. < 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
      Copy to Clipboard Toggle word wrap

      1
      각 컨트롤 플레인 호스트의 ETCD_NODE_PEER_URL 값을 지정합니다.

      & lt;ETCD_INITIAL_CLUSTER& gt; 값은 모든 컨트롤 플레인 호스트에서 동일하게 유지됩니다. 모든 컨트롤 플레인 호스트의 다음 단계에서 동일한 값이 필요합니다.

  6. 백업에서 etcd 데이터베이스를 다시 생성합니다.

    이러한 작업은 각 컨트롤 플레인 호스트에서 실행해야 합니다.

    1. 다음 명령을 사용하여 etcd 백업을 /var/lib/etcd 디렉토리에 복사합니다. 

      $ cp /home/core/assets/backup/<snapshot_yyyy-mm-dd_hhmmss>.db /var/lib/etcd
      Copy to Clipboard Toggle word wrap

    2. 계속하기 전에 올바른 etcdctl 이미지를 식별합니다. 다음 명령을 사용하여 Pod 매니페스트 백업에서 이미지를 검색합니다. 

      $ jq -r '.spec.containers[]|select(.name=="etcdctl")|.image' /root/manifests-backup/etcd-pod.yaml
      Copy to Clipboard Toggle word wrap 
      $ podman run --rm -it --entrypoint="/bin/bash" -v /var/lib/etcd:/var/lib/etcd:z <image-hash>
      Copy to Clipboard Toggle word wrap

    3. etcdctl 도구 버전이 백업이 생성된 etcd 서버의 버전인지 확인합니다. 

      $ etcdctl version
      Copy to Clipboard Toggle word wrap

    4. 현재 호스트에 올바른 값을 사용하여 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
      Copy to Clipboard Toggle word wrap
      참고

      etcd 데이터베이스를 다시 생성할 때는 따옴표가 필요합니다.

  7. 추가된 멤버 로그에 출력된 값을 기록합니다. 예를 들면 다음과 같습니다.

    출력 예

    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}
    Copy to Clipboard Toggle word wrap

    1. 컨테이너를 종료합니다.
    2. 다른 컨트롤 플레인 호스트에서 이러한 단계를 반복하여 추가된 멤버 로그에 출력된 값이 모든 컨트롤 플레인 호스트에 대해 동일한지 확인합니다.

  8. 재생성된 etcd 데이터베이스를 기본 위치로 이동합니다.

    이러한 작업은 각 컨트롤 플레인 호스트에서 실행해야 합니다.

    1. 재현된 데이터베이스(이전 etcdctl snapshot restore 명령으로 생성된 멤버 폴더)를 기본 etcd 위치 /var/lib/etcd:로 이동합니다. 

      $ mv /var/lib/etcd/restore-<UUID>/member /var/lib/etcd
      Copy to Clipboard Toggle word wrap

    2. /var/lib/etcd /member 폴더에서 /var/lib/etcd/member 폴더의 SELinux 컨텍스트를 복원합니다. 

      $ restorecon -vR /var/lib/etcd/
      Copy to Clipboard Toggle word wrap

    3. 남은 파일과 디렉터리를 제거합니다. 

      $ rm -rf /var/lib/etcd/restore-<UUID>
      Copy to Clipboard Toggle word wrap 
      $ rm /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db
      Copy to Clipboard Toggle word wrap
      중요

      완료되면 /var/lib/etcd 디렉토리에 폴더 멤버 만 포함되어야 합니다.

    4. 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.

  9. etcd 클러스터를 다시 시작하십시오.

    1. 다음 단계는 모든 컨트롤 플레인 호스트에서 실행해야 하지만 한 번에 하나의 호스트 를 실행해야 합니다.

    2. kubelet이 관련 컨테이너를 시작하도록 하려면 etcd 정적 Pod 매니페스트를 kubelet 매니페스트 디렉터리로 다시 이동합니다. 

      $ mv /tmp/etcd-pod.yaml /etc/kubernetes/manifests
      Copy to Clipboard Toggle word wrap

    3. 모든 etcd 컨테이너가 시작되었는지 확인합니다. 

      $ crictl ps | grep etcd | grep -v operator
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

      이 명령의 출력이 비어 있으면 몇 분 기다렸다가 다시 확인하십시오.

  10. etcd 클러스터의 상태를 확인합니다.

    1. 다음 명령을 사용하여 컨트롤 플레인 호스트에서 etcd 클러스터의 상태를 확인합니다. 

      $ crictl exec -it $(crictl ps | grep etcdctl | awk '{print $1}') etcdctl endpoint status -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         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 |        |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

  11. 다른 정적 pod를 다시 시작합니다.

    한 번에 하나의 호스트이지만 모든 컨트롤 플레인 호스트에서 다음 단계를 실행해야 합니다.

    1. Kubernetes API Server 정적 Pod 매니페스트를 kubelet 매니페스트 디렉터리로 다시 이동하여 kubelet이 명령을 사용하여 관련 컨테이너를 시작합니다. 

      $ mv /root/manifests-backup/kube-apiserver-pod.yaml /etc/kubernetes/manifests
      Copy to Clipboard Toggle word wrap

    2. 모든 Kubernetes API Server 컨테이너가 시작되었는지 확인합니다. 

      $ crictl ps | grep kube-apiserver | grep -v operator
      Copy to Clipboard Toggle word wrap
      참고

      다음 명령의 출력이 비어 있으면 몇 분 기다렸다가 다시 확인합니다.

    3. kube-controller-manager-pod.yaml 및 kube-scheduler-pod.yaml 파일에 대해 동일한 단계를 반복합니다.

      1. 다음 명령을 사용하여 모든 노드에서 kubelet을 다시 시작합니다. 

        $ systemctl restart kubelet
        Copy to Clipboard Toggle word wrap

      2. 다음 명령을 사용하여 나머지 컨트롤 플레인 Pod를 시작합니다. 

        $ mv /root/manifests-backup/kube-* /etc/kubernetes/manifests/
        Copy to Clipboard Toggle word wrap

      3. kube-apiserver,kube-scheduler 및 kube-controller-manager Pod가 올바르게 시작되었는지 확인합니다. 

        $ crictl ps | grep -E 'kube-(apiserver|scheduler|controller-manager)' | grep -v -E 'operator|guard'
        Copy to Clipboard Toggle word wrap

      4. 다음 명령을 사용하여 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
        Copy to Clipboard Toggle word wrap
5.4.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가 더 이상 존재하지 않는 장치를 참조할 수 있습니다.

    이 문제를 해결하려면 관리자가 다음을 수행해야 합니다.

    1. 잘못된 장치가 있는 PV를 수동으로 제거합니다.
    2. 각 노드에서 심볼릭 링크를 제거합니다.
    3. LocalVolume 또는 LocalVolumeSet 오브젝트를 삭제합니다 (스토리지 → 영구 스토리지 구성 → 로컬 볼륨을 사용하는 영구 스토리지 → Local Storage Operator 리소스 삭제참조).

5.4.3. 만료된 컨트롤 플레인 인증서 복구
링크 복사

5.4.3.1. 만료된 컨트롤 플레인 인증서 복구
링크 복사

클러스터는 만료된 컨트롤 플레인 인증서에서 자동으로 복구될 수 있습니다.

그러나 kubelet 인증서를 복구하려면 대기 중인 node-bootstrapper 인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 사용자 프로비저닝 설치의 경우 보류 중인 kubelet 서비스 CSR을 승인해야 할 수도 있습니다.

보류중인 CSR을 승인하려면 다음 단계를 수행합니다.

절차

  1. 현재 CSR의 목록을 가져옵니다. 

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

    1
    보류 중인 kubelet 서비스 CSR(사용자 프로비저닝 설치용)입니다.
    2
    보류 중인 node-bootstrapper CSR입니다.

  2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다. 

    $ oc describe csr <csr_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

  3. 각각의 유효한 node-bootstrapper CSR을 승인합니다. 

    $ oc adm certificate approve <csr_name>
    Copy to Clipboard Toggle word wrap

  4. 사용자 프로비저닝 설치의 경우 CSR을 제공하는 각 유효한 kubelet을 승인합니다. 

    $ oc adm certificate approve <csr_name>
    Copy to Clipboard Toggle word wrap

5.4.4. AWS 리전 내에서 호스팅된 클러스터의 재해 복구
링크 복사

호스팅된 클러스터의 재해 복구(DR)가 필요한 경우 호스팅된 클러스터를 AWS 내의 동일한 리전으로 복구할 수 있습니다. 예를 들어 관리 클러스터 업그레이드에 실패하고 호스팅된 클러스터가 읽기 전용 상태인 경우 DR이 필요합니다.

중요

호스트 컨트롤 플레인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

DR 프로세스에는 다음 세 가지 주요 단계가 포함됩니다.

  1. 소스 관리 클러스터에서 호스팅된 클러스터 백업
  2. 대상 관리 클러스터에서 호스팅된 클러스터 복원
  3. 소스 관리 클러스터에서 호스팅된 클러스터 삭제

워크로드는 프로세스 중에 계속 실행됩니다. 일정 기간 Cluster API를 사용할 수 없지만 작업자 노드에서 실행 중인 서비스에는 영향을 미치지 않습니다.

중요

다음 예제와 같이 소스 관리 클러스터와 대상 관리 클러스터에 모두 API 서버 URL을 유지하려면 --external-dns 플래그가 있어야 합니다.

예: 외부 DNS 플래그

--external-dns-provider=aws \
--external-dns-credentials=<AWS Credentials location> \
--external-dns-domain-filter=<DNS Base Domain>
Copy to Clipboard Toggle word wrap

이렇게 하면 서버 URL이 https://api-sample-hosted.sample-hosted.aws.openshift.com 로 끝납니다.

API 서버 URL을 유지하기 위해 --external-dns 플래그를 포함하지 않으면 호스팅 클러스터를 마이그레이션할 수 없습니다.

5.4.4.1. 환경 및 컨텍스트 예
링크 복사

복원할 클러스터가 3개 있는 경우를 고려해 보십시오. 두 개는 관리 클러스터이며 하나는 호스팅된 클러스터입니다. 컨트롤 플레인만 또는 컨트롤 플레인과 노드를 복원할 수 있습니다. 시작하기 전에 다음 정보가 필요합니다.

  • 소스 MGMT 네임스페이스: 소스 관리 네임스페이스
  • Source MGMT ClusterName: 소스 관리 클러스터 이름
  • Source MGMT Kubeconfig: 소스 관리 kubeconfig 파일
  • 대상 MGMT Kubeconfig: 대상 관리 kubeconfig 파일
  • HC Kubeconfig: 호스팅된 클러스터 kubeconfig 파일
  • SSH 키 파일: SSH 공개 키
  • pull secret: 릴리스 이미지에 액세스할 수 있는 풀 시크릿 파일
  • AWS 인증 정보
  • AWS 리전
  • 기본 도메인: 외부 DNS로 사용할 DNS 기본 도메인
  • S3 버킷 이름: etcd 백업을 업로드할 AWS 리전의 버킷

이 정보는 다음 예제 환경 변수에 표시됩니다.

환경 변수 예

SSH_KEY_FILE=${HOME}/.ssh/id_rsa.pub
BASE_PATH=${HOME}/hypershift
BASE_DOMAIN="aws.sample.com"
PULL_SECRET_FILE="${HOME}/pull_secret.json"
AWS_CREDS="${HOME}/.aws/credentials"
AWS_ZONE_ID="Z02718293M33QHDEQBROL"

CONTROL_PLANE_AVAILABILITY_POLICY=SingleReplica
HYPERSHIFT_PATH=${BASE_PATH}/src/hypershift
HYPERSHIFT_CLI=${HYPERSHIFT_PATH}/bin/hypershift
HYPERSHIFT_IMAGE=${HYPERSHIFT_IMAGE:-"quay.io/${USER}/hypershift:latest"}
NODE_POOL_REPLICAS=${NODE_POOL_REPLICAS:-2}

# MGMT Context
MGMT_REGION=us-west-1
MGMT_CLUSTER_NAME="${USER}-dev"
MGMT_CLUSTER_NS=${USER}
MGMT_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT_CLUSTER_NS}-${MGMT_CLUSTER_NAME}"
MGMT_KUBECONFIG="${MGMT_CLUSTER_DIR}/kubeconfig"

# MGMT2 Context
MGMT2_CLUSTER_NAME="${USER}-dest"
MGMT2_CLUSTER_NS=${USER}
MGMT2_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT2_CLUSTER_NS}-${MGMT2_CLUSTER_NAME}"
MGMT2_KUBECONFIG="${MGMT2_CLUSTER_DIR}/kubeconfig"

# Hosted Cluster Context
HC_CLUSTER_NS=clusters
HC_REGION=us-west-1
HC_CLUSTER_NAME="${USER}-hosted"
HC_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}"
HC_KUBECONFIG="${HC_CLUSTER_DIR}/kubeconfig"
BACKUP_DIR=${HC_CLUSTER_DIR}/backup

BUCKET_NAME="${USER}-hosted-${MGMT_REGION}"

# DNS
AWS_ZONE_ID="Z07342811SH9AA102K1AC"
EXTERNAL_DNS_DOMAIN="hc.jpdv.aws.kerbeross.com"
Copy to Clipboard Toggle word wrap

5.4.4.2. 백업 및 복원 프로세스 개요
링크 복사

백업 및 복원 프로세스는 다음과 같이 작동합니다.

  1. 관리 클러스터 1에서 소스 관리 클러스터로 간주할 수 있으며 컨트롤 플레인 및 작업자는 외부 DNS API를 사용하여 상호 작용합니다. 외부 DNS API에 액세스할 수 있으며 로드 밸런서는 관리 클러스터 사이에 있습니다.

    다이어그램은 외부 DNS API에 액세스하는 작업자와 로드 밸런서를 통해 컨트롤 플레인을 가리키는 외부 DNS API를 보여줍니다.
    View larger image
    다이어그램은 외부 DNS API에 액세스하는 작업자와 로드 밸런서를 통해 컨트롤 플레인을 가리키는 외부 DNS API를 보여줍니다.

  2. etcd, 컨트롤 플레인 및 작업자 노드가 포함된 호스팅 클러스터의 스냅샷을 생성합니다. 이 프로세스 중에 작업자 노드는 액세스할 수 없는 경우에도 외부 DNS API에 계속 액세스하려고 하며 워크로드가 실행되고 컨트롤 플레인은 로컬 매니페스트 파일에 저장되고 etcd는 S3 버킷으로 백업됩니다. 데이터 플레인이 활성화되고 컨트롤 플레인이 일시 중지되었습니다.

    298 OpenShift 백업 복원 0123 01
    View larger image
    298 OpenShift 백업 복원 0123 01

  3. 대상 관리 클러스터 2의 경우 S3 버킷에서 etcd를 복원하고 로컬 매니페스트 파일에서 컨트롤 플레인을 복원합니다. 이 프로세스 중에 외부 DNS API가 중지되고 호스트된 클러스터 API에 액세스할 수 없게 되고 API를 사용하는 모든 작업자는 매니페스트 파일을 업데이트할 수 없지만 워크로드가 계속 실행되고 있습니다.

    298 OpenShift 백업 복원 0123 02
    View larger image
    298 OpenShift 백업 복원 0123 02

  4. 외부 DNS API는 다시 액세스할 수 있으며 작업자 노드는 이를 사용하여 관리 클러스터 2로 이동합니다. 외부 DNS API는 컨트롤 플레인을 가리키는 로드 밸런서에 액세스할 수 있습니다.

    298 OpenShift 백업 복원 0123 03
    View larger image
    298 OpenShift 백업 복원 0123 03

  5. 관리 클러스터 2에서 컨트롤 플레인 및 작업자 노드는 외부 DNS API를 사용하여 상호 작용합니다. 리소스는 etcd의 S3 백업을 제외하고 관리 클러스터 1에서 삭제됩니다. mangagement 클러스터 1에서 호스트 클러스터를 다시 설정하려고 하면 작동하지 않습니다.

    298 OpenShift 백업 복원 0123 04
    View larger image
    298 OpenShift 백업 복원 0123 04

호스팅된 클러스터를 수동으로 백업 및 복원하거나 스크립트를 실행하여 프로세스를 완료할 수 있습니다. 스크립트에 대한 자세한 내용은 "호스트된 클러스터를 백업 및 복원하기 위해 스크립트 실행"을 참조하십시오.

5.4.4.3. 호스팅된 클러스터 백업
링크 복사

대상 관리 클러스터에서 호스팅된 클러스터를 복구하려면 먼저 관련 데이터를 모두 백업해야 합니다.

절차

  1. 다음 명령을 입력하여 소스 관리 클러스터를 선언할 configmap 파일을 생성합니다. 

    $ oc create configmap mgmt-parent-cluster -n default --from-literal=from=${MGMT_CLUSTER_NAME}
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 호스팅 클러스터 및 노드 풀에서 조정을 종료합니다. 

    $ PAUSED_UNTIL="true"
$ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
$ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator
    Copy to Clipboard Toggle word wrap 
    $ PAUSED_UNTIL="true"
$ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
$ oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
$ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator
    Copy to Clipboard Toggle word wrap

  3. 다음 bash 스크립트를 실행하여 etcd를 백업하고 S3 버킷에 데이터를 업로드합니다.

    작은 정보

    이 스크립트를 함수로 래핑하고 main 함수에서 호출합니다. 

    # ETCD Backup
ETCD_PODS="etcd-0"
if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
  ETCD_PODS="etcd-0 etcd-1 etcd-2"
fi

for POD in ${ETCD_PODS}; do
  # Create an etcd snapshot
  oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db
  oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db

  FILEPATH="/${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
  CONTENT_TYPE="application/x-compressed-tar"
  DATE_VALUE=`date -R`
  SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}"

  set +x
  ACCESS_KEY=$(grep aws_access_key_id ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
  SECRET_KEY=$(grep aws_secret_access_key ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
  SIGNATURE_HASH=$(echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac "${SECRET_KEY}" -binary | base64)
  set -x

  # FIXME: this is pushing to the OIDC bucket
  oc exec -it etcd-0 -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- curl -X PUT -T "/var/lib/data/snapshot.db" \
    -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \
    -H "Date: ${DATE_VALUE}" \
    -H "Content-Type: ${CONTENT_TYPE}" \
    -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \
    https://${BUCKET_NAME}.s3.amazonaws.com/${HC_CLUSTER_NAME}-${POD}-snapshot.db
done
    Copy to Clipboard Toggle word wrap

    etcd 백업에 대한 자세한 내용은 "호스트된 클러스터에서 etcd 백업 및 복원"을 참조하십시오.

  4. 다음 명령을 입력하여 Kubernetes 및 OpenShift Container Platform 오브젝트를 백업합니다. 다음 오브젝트를 백업해야 합니다.

    • HostedCluster 네임스페이스의 HostedCluster 및 NodePool 오브젝트
    • HostedCluster 네임스페이스의 HostedCluster 시크릿
    • HostedControl Plane 네임스페이스의 HostedControlPlane
    • 호스팅 된 컨트롤 플레인 네임스페이스의 클러스터
    • AWSCluster,AWSMachineTemplate, AWSMachine Template 네임스페이스의 AWSMachineTemplate
    • MachineDeployments,MachineSets, Hosted Control Plane 네임스페이스의 머신

    • 호스팅된 컨트롤 플레인 네임스페이스의 controlPlane 시크릿 

      $ mkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
$ chmod 700 ${BACKUP_DIR}/namespaces/

# HostedCluster
$ echo "Backing Up HostedCluster Objects:"
$ oc get hc ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
$ echo "--> HostedCluster"
$ sed -i '' -e '/^status:$/,$d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml

# NodePool
$ oc get np ${NODEPOOLS} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml
$ echo "--> NodePool"
$ sed -i '' -e '/^status:$/,$ d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml

# Secrets in the HC Namespace
$ echo "--> HostedCluster Secrets:"
for s in $(oc get secret -n ${HC_CLUSTER_NS} | grep "^${HC_CLUSTER_NAME}" | awk '{print $1}'); do
    oc get secret -n ${HC_CLUSTER_NS} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-${s}.yaml
done

# Secrets in the HC Control Plane Namespace
$ echo "--> HostedCluster ControlPlane Secrets:"
for s in $(oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} | egrep -v "docker|service-account-token|oauth-openshift|NAME|token-${HC_CLUSTER_NAME}" | awk '{print $1}'); do
    oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-${s}.yaml
done

# Hosted Control Plane
$ echo "--> HostedControlPlane:"
$ oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-${HC_CLUSTER_NAME}.yaml

# Cluster
$ echo "--> Cluster:"
$ CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
$ oc get cluster ${CL_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-${HC_CLUSTER_NAME}.yaml

# AWS Cluster
$ echo "--> AWS Cluster:"
$ oc get awscluster ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-${HC_CLUSTER_NAME}.yaml

# AWS MachineTemplate
$ echo "--> AWS Machine Template:"
$ oc get awsmachinetemplate ${NODEPOOLS} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-${HC_CLUSTER_NAME}.yaml

# AWS Machines
$ echo "--> AWS Machine:"
$ CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
for s in $(oc get awsmachines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --no-headers | grep ${CL_NAME} | cut -f1 -d\ ); do
    oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} awsmachines $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-${s}.yaml
done

# MachineDeployments
$ echo "--> HostedCluster MachineDeployments:"
for s in $(oc get machinedeployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
    mdp_name=$(echo ${s} | cut -f 2 -d /)
    oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-${mdp_name}.yaml
done

# MachineSets
$ echo "--> HostedCluster MachineSets:"
for s in $(oc get machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
    ms_name=$(echo ${s} | cut -f 2 -d /)
    oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-${ms_name}.yaml
done

# Machines
$ echo "--> HostedCluster Machine:"
for s in $(oc get machine -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
    m_name=$(echo ${s} | cut -f 2 -d /)
    oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-${m_name}.yaml
done
      Copy to Clipboard Toggle word wrap

  5. 다음 명령을 입력하여 ControlPlane 경로를 정리합니다. 

    $ oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all
    Copy to Clipboard Toggle word wrap

    해당 명령을 입력하여 ExternalDNS Operator에서 Route53 항목을 삭제할 수 있습니다.

  6. 이 스크립트를 실행하여 Route53 항목이 정리되었는지 확인합니다. 

    function clean_routes() {

    if [[ -z "${1}" ]];then
        echo "Give me the NS where to clean the routes"
        exit 1
    fi

    # Constants
    if [[ -z "${2}" ]];then
        echo "Give me the Route53 zone ID"
        exit 1
    fi

    ZONE_ID=${2}
    ROUTES=10
    timeout=40
    count=0

    # This allows us to remove the ownership in the AWS for the API route
    oc delete route -n ${1} --all

    while [ ${ROUTES} -gt 2 ]
    do
        echo "Waiting for ExternalDNS Operator to clean the DNS Records in AWS Route53 where the zone id is: ${ZONE_ID}..."
        echo "Try: (${count}/${timeout})"
        sleep 10
        if [[ $count -eq timeout ]];then
            echo "Timeout waiting for cleaning the Route53 DNS records"
            exit 1
        fi
        count=$((count+1))
        ROUTES=$(aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} --max-items 10000 --output json | grep -c ${EXTERNAL_DNS_DOMAIN})
    done
}

# SAMPLE: clean_routes "<HC ControlPlane Namespace>" "<AWS_ZONE_ID>"
clean_routes "${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}" "${AWS_ZONE_ID}"
    Copy to Clipboard Toggle word wrap

검증

모든 OpenShift Container Platform 오브젝트와 S3 버킷을 확인하여 모든 항목이 예상대로 표시되는지 확인합니다.

다음 단계

호스팅된 클러스터를 복원합니다.

5.4.4.4. 호스트 클러스터 복원
링크 복사

백업한 모든 오브젝트를 수집하여 대상 관리 클러스터에서 복원합니다.

사전 요구 사항

소스 관리 클러스터에서 데이터를 백업합니다.

작은 정보

대상 관리 클러스터의 kubeconfig 파일이 KUBECONFIG 변수에 설정된 대로 배치되거나 스크립트를 사용하는 경우 MGMT2_KUBECONFIG 변수에 배치되어 있는지 확인합니다. 내보내기 KUBECONFIG=<Kubeconfig FilePath > 또는 스크립트를 사용하는 경우 내보내기 KUBECONFIG=${MGMT2_KUBECONFIG} 를 사용합니다.

절차

  1. 다음 명령을 입력하여 새 관리 클러스터에 복원 중인 클러스터의 네임스페이스가 포함되어 있지 않은지 확인합니다. 

    # Just in case
$ export KUBECONFIG=${MGMT2_KUBECONFIG}
$ BACKUP_DIR=${HC_CLUSTER_DIR}/backup

# Namespace deletion in the destination Management cluster
$ oc delete ns ${HC_CLUSTER_NS} || true
$ oc delete ns ${HC_CLUSTER_NS}-{HC_CLUSTER_NAME} || true
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 삭제된 네임스페이스를 다시 생성합니다. 

    # Namespace creation
$ oc new-project ${HC_CLUSTER_NS}
$ oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 HC 네임스페이스에 보안을 복원합니다. 

    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 HostedCluster 컨트롤 플레인 네임스페이스의 오브젝트를 복원합니다. 

    # Secrets
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-*

# Cluster
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-*
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-*
    Copy to Clipboard Toggle word wrap

  5. AWS 인스턴스를 재사용하기 위해 노드와 노드 풀을 복구하는 경우 다음 명령을 입력하여 HC 컨트롤 플레인 네임스페이스의 오브젝트를 복원합니다. 

    # AWS
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-*
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-*
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-*

# Machines
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-*
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-*
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-*
    Copy to Clipboard Toggle word wrap

  6. 이 bash 스크립트를 실행하여 etcd 데이터 및 호스팅 클러스터를 복원하십시오. 

    ETCD_PODS="etcd-0"
if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
  ETCD_PODS="etcd-0 etcd-1 etcd-2"
fi

HC_RESTORE_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-restore.yaml
HC_BACKUP_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
HC_NEW_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-new.yaml
cat ${HC_BACKUP_FILE} > ${HC_NEW_FILE}
cat > ${HC_RESTORE_FILE} <<EOF
    restoreSnapshotURL:
EOF

for POD in ${ETCD_PODS}; do
  # Create a pre-signed URL for the etcd snapshot
  ETCD_SNAPSHOT="s3://${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
  ETCD_SNAPSHOT_URL=$(AWS_DEFAULT_REGION=${MGMT2_REGION} aws s3 presign ${ETCD_SNAPSHOT})

  # FIXME no CLI support for restoreSnapshotURL yet
  cat >> ${HC_RESTORE_FILE} <<EOF
    - "${ETCD_SNAPSHOT_URL}"
EOF
done

cat ${HC_RESTORE_FILE}

if ! grep ${HC_CLUSTER_NAME}-snapshot.db ${HC_NEW_FILE}; then
  sed -i '' -e "/type: PersistentVolume/r ${HC_RESTORE_FILE}" ${HC_NEW_FILE}
  sed -i '' -e '/pausedUntil:/d' ${HC_NEW_FILE}
fi

HC=$(oc get hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} -o name || true)
if [[ ${HC} == "" ]];then
    echo "Deploying HC Cluster: ${HC_CLUSTER_NAME} in ${HC_CLUSTER_NS} namespace"
    oc apply -f ${HC_NEW_FILE}
else
    echo "HC Cluster ${HC_CLUSTER_NAME} already exists, avoiding step"
fi
    Copy to Clipboard Toggle word wrap

  7. AWS 인스턴스를 재사용하기 위해 노드와 노드 풀을 복구하는 경우 다음 명령을 입력하여 노드 풀을 복원합니다. 

    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*
    Copy to Clipboard Toggle word wrap

검증

  • 노드가 완전히 복원되었는지 확인하려면 다음 기능을 사용하십시오. 

    timeout=40
count=0
NODE_STATUS=$(oc get nodes --kubeconfig=${HC_KUBECONFIG} | grep -v NotReady | grep -c "worker") || NODE_STATUS=0

while [ ${NODE_POOL_REPLICAS} != ${NODE_STATUS} ]
do
    echo "Waiting for Nodes to be Ready in the destination MGMT Cluster: ${MGMT2_CLUSTER_NAME}"
    echo "Try: (${count}/${timeout})"
    sleep 30
    if [[ $count -eq timeout ]];then
        echo "Timeout waiting for Nodes in the destination MGMT Cluster"
        exit 1
    fi
    count=$((count+1))
    NODE_STATUS=$(oc get nodes --kubeconfig=${HC_KUBECONFIG} | grep -v NotReady | grep -c "worker") || NODE_STATUS=0
done
    Copy to Clipboard Toggle word wrap

다음 단계

클러스터를 종료하고 삭제합니다.

5.4.4.5. 소스 관리 클러스터에서 호스팅된 클러스터 삭제
링크 복사

호스팅된 클러스터를 백업하고 이를 대상 관리 클러스터에 복원한 후 소스 관리 클러스터에서 호스팅된 클러스터를 종료하고 삭제합니다.

사전 요구 사항

데이터를 백업하고 이를 소스 관리 클러스터로 복원했습니다.

작은 정보

대상 관리 클러스터의 kubeconfig 파일이 KUBECONFIG 변수에 설정되어 있거나 스크립트를 사용하는 경우 MGMT_KUBECONFIG 변수에 배치되어 있는지 확인합니다. 내보내기 KUBECONFIG=<Kubeconfig FilePath > 또는 스크립트를 사용하는 경우 내보내기 KUBECONFIG=${MGMT_KUBECONFIG} 를 사용합니다.

절차

  1. 다음 명령을 입력하여 배포 및 상태 저장 세트 오브젝트를 확장합니다. 

    # Just in case
$ export KUBECONFIG=${MGMT_KUBECONFIG}

# Scale down deployments
$ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
$ oc scale statefulset.apps -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
$ sleep 15
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 NodePool 오브젝트를 삭제합니다. 

    NODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}')
if [[ ! -z "${NODEPOOLS}" ]];then
    oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
    oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS}
fi
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 machine 및 machineset 오브젝트를 삭제합니다. 

    # Machines
for m in $(oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
    oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
    oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
done

$ oc delete machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all || true
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 클러스터 오브젝트를 삭제합니다. 

    # Cluster
$ C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
$ oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
$ oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all
    Copy to Clipboard Toggle word wrap

  5. 이러한 명령을 입력하여 AWS 머신(Kubernetes 오브젝트)을 삭제합니다. 실제 AWS 머신 삭제에 대해 우려하지 마십시오. 클라우드 인스턴스는 영향을 받지 않습니다. 

    # AWS Machines
for m in $(oc get awsmachine.infrastructure.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
do
    oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
    oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
done
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 입력하여 Hosted ControlPlane 및 ControlPlane HC 네임스페이스 오브젝트를 삭제합니다. 

    # Delete HCP and ControlPlane HC NS
$ oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
$ oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all
$ oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || true
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 입력하여 HostedCluster 및 HC 네임스페이스 오브젝트를 삭제합니다. 

    # Delete HC and HC Namespace
$ oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || true
$ oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME}  || true
$ oc delete ns ${HC_CLUSTER_NS} || true
    Copy to Clipboard Toggle word wrap

검증

  • 모든 기능이 작동하는지 확인하려면 다음 명령을 입력합니다. 

    # Validations
$ export KUBECONFIG=${MGMT2_KUBECONFIG}

$ oc get hc -n ${HC_CLUSTER_NS}
$ oc get np -n ${HC_CLUSTER_NS}
$ oc get pod -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
$ oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}

# Inside the HostedCluster
$ export KUBECONFIG=${HC_KUBECONFIG}
$ oc get clusterversion
$ oc get nodes
    Copy to Clipboard Toggle word wrap

다음 단계

새 관리 클러스터에서 실행되는 새 OVN 컨트롤 플레인에 연결할 수 있도록 호스팅 클러스터에서 OVN Pod를 삭제합니다.

  1. 호스트 클러스터의 kubeconfig 경로를 사용하여 KUBECONFIG 환경 변수를 로드합니다.

  2. 다음 명령을 입력합니다. 

    $ oc delete pod -n openshift-ovn-kubernetes --all
    Copy to Clipboard Toggle word wrap
5.4.4.6. 호스팅된 클러스터를 백업하고 복원하는 스크립트 실행
링크 복사

호스팅된 클러스터를 백업하고 AWS의 동일한 리전 내에서 복원하는 프로세스를 신속하게 수행하려면 스크립트를 수정하고 실행할 수 있습니다.

절차

  1. 다음 스크립트의 변수를 정보로 교체합니다. 

    # Fill the Common variables to fit your environment, this is just a sample
SSH_KEY_FILE=${HOME}/.ssh/id_rsa.pub
BASE_PATH=${HOME}/hypershift
BASE_DOMAIN="aws.sample.com"
PULL_SECRET_FILE="${HOME}/pull_secret.json"
AWS_CREDS="${HOME}/.aws/credentials"
CONTROL_PLANE_AVAILABILITY_POLICY=SingleReplica
HYPERSHIFT_PATH=${BASE_PATH}/src/hypershift
HYPERSHIFT_CLI=${HYPERSHIFT_PATH}/bin/hypershift
HYPERSHIFT_IMAGE=${HYPERSHIFT_IMAGE:-"quay.io/${USER}/hypershift:latest"}
NODE_POOL_REPLICAS=${NODE_POOL_REPLICAS:-2}

# MGMT Context
MGMT_REGION=us-west-1
MGMT_CLUSTER_NAME="${USER}-dev"
MGMT_CLUSTER_NS=${USER}
MGMT_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT_CLUSTER_NS}-${MGMT_CLUSTER_NAME}"
MGMT_KUBECONFIG="${MGMT_CLUSTER_DIR}/kubeconfig"

# MGMT2 Context
MGMT2_CLUSTER_NAME="${USER}-dest"
MGMT2_CLUSTER_NS=${USER}
MGMT2_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT2_CLUSTER_NS}-${MGMT2_CLUSTER_NAME}"
MGMT2_KUBECONFIG="${MGMT2_CLUSTER_DIR}/kubeconfig"

# Hosted Cluster Context
HC_CLUSTER_NS=clusters
HC_REGION=us-west-1
HC_CLUSTER_NAME="${USER}-hosted"
HC_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}"
HC_KUBECONFIG="${HC_CLUSTER_DIR}/kubeconfig"
BACKUP_DIR=${HC_CLUSTER_DIR}/backup

BUCKET_NAME="${USER}-hosted-${MGMT_REGION}"

# DNS
AWS_ZONE_ID="Z026552815SS3YPH9H6MG"
EXTERNAL_DNS_DOMAIN="guest.jpdv.aws.kerbeross.com"
    Copy to Clipboard Toggle word wrap
  2. 로컬 파일 시스템에 스크립트를 저장합니다.

  3. 다음 명령을 입력하여 스크립트를 실행합니다. 

    source <env_file>
    Copy to Clipboard Toggle word wrap

    여기서: env_file 은 스크립트를 저장한 파일의 이름입니다.

    마이그레이션 스크립트는 다음 리포지토리에서 유지 관리됩니다. https://github.com/openshift/hypershift/blob/main/contrib/migration/migrate-hcp.sh.

Legal Notice
링크 복사

Copyright © 2025 Red Hat

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.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat