백업 및 복원


OpenShift Container Platform 4.13

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이 포함되어 있으며 OCP 4.11 이상에는 존재하지 않는 API 그룹 snapshot.storage.k8s.io/v1beta1 이 예상됩니다.

중요

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

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

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

    • Amazon Web Services
    • Microsoft Azure
    • Google Cloud Platform
    • CSI 스냅샷 지원 클라우드 스토리지(예: Ceph RBD 또는 Ceph FS)
참고

스냅샷을 사용하여 PV를 백업하지 않으려면 기본적으로 OADP Operator에서 설치하는 Restic 을 사용할 수 있습니다.

1.2.2. 애플리케이션 백업 및 복원

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

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}'

    출력 예

    2022-08-05T14:37:50Zuser@user:~ $ 1

    1
    클러스터를 정상적으로 다시 시작할 수 있도록 지정된 날짜 또는 그 이전에 클러스터를 다시 시작하도록 계획합니다. 클러스터가 재시작되면 프로세스에서 kubelet 인증서를 복구하기 위해 보류 중인 인증서 서명 요청(CSR)을 수동으로 승인해야 할 수 있습니다.
  2. 클러스터의 모든 노드를 예약 불가로 표시합니다. 클라우드 공급자의 웹 콘솔에서 이 작업을 수행하거나 다음 반복문을 실행하여 수행할 수 있습니다.

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

    출력 예

    ci-ln-mgdnf4b-72292-n547t-master-0
    node/ci-ln-mgdnf4b-72292-n547t-master-0 cordoned
    ci-ln-mgdnf4b-72292-n547t-master-1
    node/ci-ln-mgdnf4b-72292-n547t-master-1 cordoned
    ci-ln-mgdnf4b-72292-n547t-master-2
    node/ci-ln-mgdnf4b-72292-n547t-master-2 cordoned
    ci-ln-mgdnf4b-72292-n547t-worker-a-s7ntl
    node/ci-ln-mgdnf4b-72292-n547t-worker-a-s7ntl cordoned
    ci-ln-mgdnf4b-72292-n547t-worker-b-cmc9k
    node/ci-ln-mgdnf4b-72292-n547t-worker-b-cmc9k cordoned
    ci-ln-mgdnf4b-72292-n547t-worker-c-vcmtn
    node/ci-ln-mgdnf4b-72292-n547t-worker-c-vcmtn cordoned

  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 --force ; done
  4. 클러스터의 모든 노드를 종료합니다. 클라우드 공급자 웹 콘솔의 웹 콘솔에서 또는 다음 반복문을 실행하여 이 작업을 수행할 수 있습니다. 이러한 방법 중 하나를 사용하여 노드를 종료하면 Pod가 정상적으로 종료되어 데이터 손상 가능성을 줄일 수 있습니다.

    참고

    할당된 API VIP가 있는 컨트롤 플레인 노드가 루프에서 처리된 마지막 노드인지 확인합니다. 그렇지 않으면 shutdown 명령이 실패합니다.

    $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 1; done 1
    1
    -h 1 은 컨트롤 플레인 노드가 종료되기 전에 이 프로세스가 지속됩니다. 10개 이상의 노드가 있는 대규모 클러스터의 경우 -h 10 이상으로 설정하여 모든 컴퓨팅 노드를 먼저 종료할 시간이 있는지 확인합니다.

    출력 예

    Starting pod/ip-10-0-130-169us-east-2computeinternal-debug ...
    To use host binaries, run `chroot /host`
    Shutdown scheduled for Mon 2021-09-13 09:36:17 UTC, use 'shutdown -c' to cancel.
    Removing debug pod ...
    Starting pod/ip-10-0-150-116us-east-2computeinternal-debug ...
    To use host binaries, run `chroot /host`
    Shutdown scheduled for Mon 2021-09-13 09:36:29 UTC, use 'shutdown -c' to cancel.

    참고

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

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

    중요

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

2.3. 추가 리소스

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

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

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

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

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

3.1. 전제 조건

3.2. 클러스터를 다시 시작

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

전제 조건

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

프로세스

  1. 외부 스토리지 또는 LDAP 서버와 같은 클러스터의 종속 장치를 시작합니다.
  2. 모든 클러스터 시스템을 시작합니다.

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

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

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

    $ oc get nodes -l node-role.kubernetes.io/master

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

    NAME                           STATUS   ROLES    AGE   VERSION
    ip-10-0-168-251.ec2.internal   Ready    master   75m   v1.26.0
    ip-10-0-170-223.ec2.internal   Ready    master   75m   v1.26.0
    ip-10-0-211-16.ec2.internal    Ready    master   75m   v1.26.0
  4. 컨트롤 플레인 노드가 준비되지 않은 경우 승인해야하는 보류중인 인증서 서명 요청(CSR)이 있는지 확인합니다.

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

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

      $ oc describe csr <csr_name> 1
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
    3. 각각의 유효한 CSR을 승인합니다.

      $ oc adm certificate approve <csr_name>
  5. 컨트롤 플레인 노드가 준비되면 모든 작업자 노드가 준비되었는지 확인합니다.

    $ oc get nodes -l node-role.kubernetes.io/worker

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

    NAME                           STATUS   ROLES    AGE   VERSION
    ip-10-0-179-95.ec2.internal    Ready    worker   64m   v1.26.0
    ip-10-0-182-134.ec2.internal   Ready    worker   64m   v1.26.0
    ip-10-0-250-100.ec2.internal   Ready    worker   64m   v1.26.0
  6. 작업자 노드가 준비되지 않은 경우 승인해야하는 보류중인 인증서 서명 요청(CSR)이 있는지 확인합니다.

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

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

      $ oc describe csr <csr_name> 1
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
    3. 각각의 유효한 CSR을 승인합니다.

      $ oc adm certificate approve <csr_name>
  7. 클러스터가 제대로 시작되었는지 확인합니다.

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

      $ oc get clusteroperators

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

      NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
      authentication                             4.13.0    True        False         False      59m
      cloud-credential                           4.13.0    True        False         False      85m
      cluster-autoscaler                         4.13.0    True        False         False      73m
      config-operator                            4.13.0    True        False         False      73m
      console                                    4.13.0    True        False         False      62m
      csi-snapshot-controller                    4.13.0    True        False         False      66m
      dns                                        4.13.0    True        False         False      76m
      etcd                                       4.13.0    True        False         False      76m
      ...
    2. 모든 노드가 Ready 상태에 있는지 확인합니다.

      $ oc get nodes

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

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

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

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

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

4장. OADP 애플리케이션 백업 및 복원

4.1. 데이터 보호를 위한 OpenShift API 소개

OADP(OpenShift API for Data Protection) 제품은 OpenShift Container Platform에서 고객 애플리케이션을 보호합니다. OpenShift Container Platform 애플리케이션, 애플리케이션 관련 클러스터 리소스, 영구 볼륨 및 내부 이미지를 다루는 포괄적인 재해 복구 보호 기능을 제공합니다. OADP는 컨테이너화된 애플리케이션과 VM(가상 머신)을 모두 백업할 수 있습니다.

그러나 OADP는 etcd 또는 {OCP-short} Operator의 재해 복구 솔루션 역할을 하지 않습니다.

OADP 지원은 고객 워크로드 네임스페이스 및 클러스터 범위 리소스에 제공됩니다.

전체 클러스터 백업복원 은 지원되지 않습니다.

4.1.1. OpenShift API for Data Protection API

OADP(OpenShift API for Data Protection)는 여러 가지 접근 방식을 통해 백업을 사용자 지정하고 불필요하거나 부적절한 리소스가 포함되지 않도록 하는 API를 제공합니다.

OADP는 다음 API를 제공합니다.

4.1.1.1. OpenShift API for Data Protection 지원
표 4.1. 지원되는 OADP 버전

버전

OCP 버전

정식 출시일 (GA)

완전 지원 종료

유지 관리 종료

Extended Update Support (EUS)

EUS (Extended Update Support Term 2)

1.3

  • 4.12
  • 4.13
  • 4.14
  • 4.15

2023년 11월 29일

2024년 7월 10일

1.5 릴리스

2025년 10월 31일

EUS는 OCP 4.14에 있어야 합니다.

2026년 10월 31일

EUS 용어 2는 OCP 4.14에 있어야 합니다.

4.1.1.1.1. 지원되지 않는 OADP Operator 버전
표 4.2. 이전 버전의 OADP Operator는 더 이상 지원되지 않음

버전

정식 출시일 (GA)

완전 지원 종료

유지 관리 종료

1.2

2023년 6월 14일

2023년 11월 29일

2024년 7월 10일

1.1

2022년 9월 01일

2023년 6월 14일

2023년 11월 29일

1.0

2022년 2월 9일

2022년 9월 01일

2023년 6월 14일

EUS에 대한 자세한 내용은 확장 업데이트 지원을 참조하십시오.

EUS 용어 2에 대한 자세한 내용은 Extended Update Support Term 2 를 참조하십시오.

추가 리소스

4.2. OADP 릴리스 정보

4.2.1. OADP 1.3 릴리스 노트

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

4.2.1.1. OADP 1.3.6 릴리스 노트

OADP(OpenShift API for Data Protection) 1.3.6은 컨테이너의 상태 등급을 새로 고치기 위해 릴리스되는 컨테이너 전용(CGO) 릴리스입니다. OADP 1.3.5에 비해 제품 자체의 코드가 변경되지 않았습니다.

4.2.1.2. OADP 1.3.5 릴리스 노트

OADP(OpenShift API for Data Protection) 1.3.5는 컨테이너의 상태 등급을 새로 고치기 위해 릴리스되는 컨테이너 전용(CGO) 릴리스입니다. 제품 자체에서 OADP 1.3.4에 비해 코드가 변경되지 않았습니다.

4.2.1.3. OADP 1.3.4 릴리스 노트

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

4.2.1.3.1. 해결된 문제

backup spec.resourcepolicy.kind 매개변수가 대소문자를 구분하지 않음

이전에는 backup spec.resourcepolicy.kind 매개변수가 하위 수준 문자열에서만 지원되었습니다. 이번 수정으로 이제 대소문자를 구분하지 않습니다. OADP-2944

olm.maxOpenShiftVersion을 사용하여 OCP 4.16 버전으로 클러스터를 업그레이드하지 마십시오.

클러스터 operator-lifecycle-manager Operator는 마이너 OpenShift Container Platform 버전 간에 업그레이드할 수 없습니다. olm.maxOpenShiftVersion 매개변수를 사용하면 OADP 1.3이 설치된 경우 OpenShift Container Platform 4.16 버전으로 업그레이드할 수 없습니다. OpenShift Container Platform 4.16 버전으로 업그레이드하려면 OCP 4.15 버전의 OADP 1.3을 OADP 1.4로 업그레이드하십시오. OADP-4803

BSL 및 VSL이 클러스터에서 제거됨

이전에는 DPA(데이터 보호 애플리케이션)가 backupLocations 또는 snapshotLocations 섹션에서 Backup Storage Locations(BSL) 또는 Volume Snapshot Locations(VSL)를 제거하도록 수정된 경우 DPA가 삭제될 때까지 BSL 또는 VSL이 클러스터에서 제거되지 않았습니다. 이번 업데이트를 통해 BSL/VSL이 클러스터에서 제거됩니다. OADP-3050

DPA는 시크릿 키를 조정하고 검증합니다.

이전에는 DPA(데이터 보호 애플리케이션)가 잘못된 VSL(volume Snapshot Locations) 시크릿 키 이름에 성공적으로 조정되었습니다. 이번 업데이트를 통해 DPA는 VSL에서 조정하기 전에 시크릿 키 이름을 검증합니다. OADP-3052

Velero의 클라우드 인증 정보 권한이 제한됨

이전에는 Velero의 클라우드 인증 정보 권한이 0644 권한으로 마운트되었습니다. 결과적으로 소유자와 그룹을 제외한 /credentials/cloud 파일을 읽을 수 있어 스토리지 액세스 키와 같은 중요한 정보에 더 쉽게 액세스할 수 있었습니다. 이번 업데이트를 통해 이 파일의 권한이 0640으로 업데이트되고 소유자 및 그룹을 제외한 다른 사용자가 이 파일에 액세스할 수 없습니다.

ArgoCD 관리 네임스페이스가 백업에 포함된 경우 경고가 표시됩니다.

ArgoCD 및 Velero가 동일한 네임스페이스를 관리하면 백업 작업 중에 경고가 표시됩니다. OADP-4736

이 릴리스에 포함된 보안 수정 목록은 RHSA-2024:9960 권고에 설명되어 있습니다.

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

4.2.1.3.2. 확인된 문제

Cryostat 애플리케이션 Pod는 복원 후 CrashLoopBackoff 상태로 들어갑니다.

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

defaultVolumesToFSBackup 및 defaultVolumesToFsBackup 플래그는 동일하지 않습니다.

dpa.spec.configuration.velero.defaultVolumesToFSBackup 플래그가 backup.spec.defaultVolumesToFsBackup 플래그와 동일하지 않으므로 혼동이 발생할 수 있습니다. OADP-3692

복원이 실패로 표시되더라도 PodVolumeRestore가 작동합니다.

podvolumerestore 는 복원이 실패로 표시된 경우에도 데이터 전송을 계속합니다. OADP-3039

Velero가 initContainer 사양 복원을 건너뛸 수 없음

Velero는 필요하지 않은 경우에도 restore-wait init 컨테이너를 복원할 수 있습니다. OADP-3759

4.2.1.4. OADP 1.3.3 릴리스 노트

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

4.2.1.4.1. 해결된 문제

네임스페이스 이름이 37자를 초과하면 OADP가 실패합니다.

37자 이상이 있고 새 DPA를 생성할 때 네임스페이스에 OADP Operator를 설치할 때 cloud-credentials 보안에 레이블이 지정됩니다. 이번 릴리스에서는 이 문제가 해결되었습니다. OADP-4211

OADP 이미지 PullPolicy가 Always로 설정

이전 버전의 OADP에서는 adp-controller-manager 및 Velero Pod의 이미지 PullPolicy가 Always 로 설정되었습니다. 이는 레지스트리에 대한 네트워크 대역폭이 제한될 수 있는 에지 시나리오에서 문제가 발생하여 Pod를 다시 시작한 후 복구 시간이 느려졌습니다. OADP 1.3.3에서 openshift-adp-controller-manager 및 Velero Pod의 이미지 PullPolicy는 IfNotPresent 로 설정됩니다.

이 릴리스에 포함된 보안 수정 목록은 RHSA-2024:4982 권고에 설명되어 있습니다.

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

4.2.1.4.2. 확인된 문제

Cryostat 애플리케이션 pod는 OADP를 복원한 후 CrashLoopBackoff 상태로 들어갑니다.

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

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.ParseMulti partForm 을 사용하여 명시적으로 또는 Request.FormValue,Request.PostFormValue 또는 Request.FormFile.FormFile을 사용하여 명시적으로 다중 파트 양식을 구문 분석할 때 구문 분석 양식의 총 크기에 대한 제한은 단일 양식 줄을 읽는 동안 사용되는 메모리에 적용되지 않습니다. 이렇게 하면 긴 줄이 포함된 악의적인 입력으로 인해 임의로 많은 양의 메모리를 할당하여 메모리 소모가 발생할 수 있습니다. 이 취약점은 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.ClientAuthorization 또는 Cryostat와 같은 중요한 헤더를 전달하지 않습니다. 악의적인 HTTP 리디렉션으로 인해 중요한 헤더가 예기치 않게 전달될 수 있습니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.

자세한 내용은 CVE-2023-45289 를 참조하십시오.

CVE-2024-24783: oadp-velero-container: Golang crypto/x509: 알 수 없는 공개 키 알고리즘이 있는 인증서의 패닉 확인

이전 버전의 OADP에 영향을 미치는 crypto/x509 Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. 알 수 없는 공개 키 알고리즘이 포함된 인증서 체인을 확인하면 Certificate.Verify 에 패닉 상태가 됩니다. 이는 Config.ClientAuth 를 VerifyClientCert 또는 RequireAnd VerifyClientCert 로 설정하는 모든 암호화/tls 클라이언트 및 서버에 영향을 미칩니다. 기본 동작은 TLS 서버가 클라이언트 인증서를 확인하지 않는 것입니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.

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

CVE-2024-24784: oadp-velero-plugin-container: Golang net/mail: 표시 이름의 댓글이 잘못 처리됨

이전 버전의 OADP에 영향을 미치는 net/mail Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. ParseAddressList 함수는 주석을 잘못 처리하고, 괄호 안의 텍스트, 이름을 표시합니다. 이는 주소 구문 분석기를 따르는 잘못된 정렬이므로 다른 구문 분석을 사용하는 프로그램에서 서로 다른 신뢰 결정을 내릴 수 있습니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.

자세한 내용은 CVE-2024-24784 를 참조하십시오.

CVE-2024-24785: oadp-velero-container: Golang: html/template: MarshalJSON 메서드에서 반환된 오류는 템플릿을 이스케이프할 수 있습니다.

이전 버전의 OADP에 영향을 미치는 html/template Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. MarshalJSON 메서드에서 반환된 오류에 사용자 제어 데이터가 포함된 경우 HTML/template 패키지의 컨텍스트 자동 이스케이프 동작을 분할하여 후속 작업이 예기치 않은 콘텐츠를 템플릿에 삽입할 수 있습니다. 이 취약점은 OADP 1.3.2에서 해결되었습니다.

자세한 내용은 CVE-2024-24785 를 참조하십시오.

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

4.2.1.5.2. 확인된 문제

Cryostat 애플리케이션 pod는 OADP를 복원한 후 CrashLoopBackoff 상태로 들어갑니다.

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

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-frequencygc-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
kopiarestic 와 같은 파일 시스템 백업을 사용하는 백업 애플리케이션만 백업 및 복원 작업을 지원합니다.

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

performance issues when restoring resources for the first time

existing-resource-policy 없이 처음으로 Cryostat 리소스를 복원할 때 두 번째 및 세 번째 시도 중에 업데이트를 위해 설정된 existing-resource-policy를 사용하여 복원하는 데 걸리는 두 배의 시간이 걸립니다. OADP-3071

Datadownload 작업이 관련 PV를 릴리스하기 전에 복원 후 후크가 실행될 수 있습니다.

Data Mover 작업의 비동기적 특성으로 인해 관련 Pod PV(영구 볼륨 클레임)를 PVC(영구 볼륨 클레임)에서 릴리스하기 전에 후크를 시도할 수 있습니다.

GCP-Workload Identity Federation VSL 백업 PartiallyFailed

VSL 백업은 GCP 워크로드 ID가 GCP에 설정된 경우 부분적으로Failed 됩니다.

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

4.2.1.7.4. 업그레이드 노트
참고

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

4.2.1.7.4.1. OADP 1.2에서 1.3으로 변경

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

OADP(OpenShift API for Data Protection) 1.3은 VolumeSnapshotMover(VSM) 또는volsync Data Mover 대신 Velero 기본 제공 데이터 Mover를 사용합니다.

이렇게 하면 다음이 변경됩니다.

  • spec.features.dataMover 필드와 VSM 플러그인은 OADP 1.3과 호환되지 않으며 DPA( DataProtectionApplication ) 구성에서 구성을 제거해야 합니다.
  • volsync Operator는 더 이상 Data Mover 기능에 필요하지 않으며 제거할 수 있습니다.
  • 사용자 정의 리소스 정의 volumesnapshotbackups.datamover.oadp.openshift.iovolumesnapshotrestores.datamover.oadp.openshift.io 는 더 이상 필요하지 않으며 제거할 수 있습니다.
  • OADP-1.2 Data Mover에 사용된 시크릿은 더 이상 필요하지 않으며 제거할 수 있습니다.

OADP 1.3은 Restic에 대한 대체 파일 시스템 백업 툴인 Kopia를 지원합니다.

  • Kopia를 사용하려면 다음 예와 같이 새 spec.configuration.nodeAgent 필드를 사용합니다.

    예제

    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
    # ...

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

    예제

    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
    # ...

참고

향후 OADP 릴리스에서는 kopia 툴이 기본 uploaderType 값이 될 계획입니다.

4.2.1.7.4.2. OADP 1.2 기술 프리뷰 데이터에서 업그레이드

OADP(OpenShift API for Data Protection) 1.2 Data Mover 백업을 OADP 1.3으로 복원 할 수 없습니다. 애플리케이션 데이터 보호의 격차를 방지하려면 OADP 1.3으로 업그레이드하기 전에 다음 단계를 완료합니다.

프로세스

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

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

Restic 파일 시스템 백업의 기본 시간 초과 값은 1시간입니다. OADP 1.3.1 이상에서는 Restic 및 Kopia의 기본 시간 초과 값은 4시간입니다.

중요

OADP 1.2 데이터 관리 백업을 복원하려면 OADP를 제거하고 OADP 1.2를 설치 및 구성해야 합니다.

4.2.1.7.4.3. DPA 구성 백업

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

프로세스

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

    예제

    $ oc get dpa -n openshift-adp -o yaml > dpa.orig.backup

4.2.1.7.4.4. OADP Operator 업그레이드

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

프로세스

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

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

프로세스

  1. Operators설치된 Operators 를 클릭하고 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
    # ...

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

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

      업데이트된 DPA 예

      spec:
        configuration:
          nodeAgent:
            enable: true
            uploaderType: kopia
          velero:
            defaultPlugins:
            - csi
            - openshift
      # ...

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

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

프로세스

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

    $ oc get all -n openshift-adp

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s

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

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'

    출력 예

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

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.
  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true

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

예제

$ velero backup create example-backup --include-namespaces mysql-persistent --snapshot-move-data=true

예제

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: example-backup
  namespace: openshift-adp
spec:
  snapshotMoveData: true
  includedNamespaces:
  - mysql-persistent
  storageLocation: dpa-sample-1
  ttl: 720h0m0s
# ...

4.3. OADP 성능

4.4. OADP 기능 및 플러그인

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

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

4.4.1. OADP 기능

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

Backup

OADP를 사용하여 OpenShift Platform의 모든 애플리케이션을 백업하거나 유형, 네임스페이스 또는 레이블별로 리소스를 필터링할 수 있습니다.

OADP는 Kubernetes 오브젝트 및 내부 이미지를 오브젝트 스토리지에 아카이브 파일로 저장하여 백업합니다. OADP는 기본 클라우드 스냅샷 API 또는 CSI(Container Storage Interface)를 사용하여 스냅샷을 생성하여 PV(영구 볼륨)를 백업합니다. 스냅샷을 지원하지 않는 클라우드 공급자의 경우 OADP는 Restic을 통해 리소스 및 PV 데이터를 백업합니다.

참고

백업 및 복원에 성공하려면 애플리케이션의 백업에서 Operator를 제외해야 합니다.

Restore

백업에서 리소스 및 PV를 복원할 수 있습니다. 백업의 모든 오브젝트를 복원하거나 네임스페이스, PV 또는 라벨별로 오브젝트를 필터링할 수 있습니다.

참고

백업 및 복원에 성공하려면 애플리케이션의 백업에서 Operator를 제외해야 합니다.

스케줄
지정된 간격으로 백업을 예약할 수 있습니다.
후크
후크를 사용하여 Pod의 컨테이너에서 명령을 실행할 수 있습니다(예: fsfreeze 파일 시스템). 백업 또는 복원 전이나 후에 실행되도록 후크를 구성할 수 있습니다. 복원 후크는 init 컨테이너 또는 애플리케이션 컨테이너에서 실행될 수 있습니다.

4.4.2. OADP 플러그인

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

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

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

AWS

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

AWS S3

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

AWS EBS

azure

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

Microsoft Azure Blob 스토리지

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

Microsoft Azure Managed Disks

gcp

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

Google Cloud Storage

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

Google Compute Engine Disks

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.4.3. OADP Velero 플러그인 정보

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

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

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

4.4.3.1. 기본 Velero 클라우드 공급자 플러그인

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

  • AWS (Amazon Web Services)
  • GCP( Google Cloud Platform)
  • Azure (Microsoft Azure)
  • OpenShift (OpenShift Velero 플러그인)
  • CSI (컨테이너 스토리지 인터페이스)
  • KubeVirt (KubeVirt)

배포 중에 oadp_v1alpha1_dpa.yaml 파일에 원하는 기본 플러그인을 지정합니다.

파일 예

다음 .yaml 파일은 openshift,aws,azure, gcp 플러그인을 설치합니다.

 apiVersion: oadp.openshift.io/v1alpha1
 kind: DataProtectionApplication
 metadata:
   name: dpa-sample
 spec:
   configuration:
     velero:
       defaultPlugins:
       - openshift
       - aws
       - azure
       - gcp
4.4.3.2. 사용자 정의 Velero 플러그인

배포 중에 oadp_v1alpha1_dpa.yaml 파일을 구성할 때 플러그인 이미지이름을 지정하여 사용자 정의 Velero 플러그인을 설치할 수 있습니다.

배포 중에 oadp_v1alpha1_dpa.yaml 파일에 원하는 사용자 지정 플러그인을 지정합니다.

파일 예

다음 .yaml 파일은 기본 openshift,azure, gcp 플러그인 및 이름이 custom-plugin-example 이고 quay.io/example-repo/custom-velero-plugin 이미지가 있는 사용자 정의 플러그인을 설치합니다.

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: dpa-sample
spec:
 configuration:
   velero:
     defaultPlugins:
     - openshift
     - azure
     - gcp
     customPlugins:
     - name: custom-plugin-example
       image: quay.io/example-repo/custom-velero-plugin
4.4.3.3. Velero 플러그인에서 "received EOF, stop recv loop" 메시지를 반환
참고

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

4.4.4. OADP에서 지원되는 아키텍처

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

  • AMD64
  • ARM64
  • PPC64le
  • s390x
참고

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

4.4.5. IBM Power 및 IBM Z에 대한 OADP 지원

OADP(OpenShift API for Data Protection)는 플랫폼에서 사용할 수 없습니다. 다음 정보는 IBM Power® 및 IBM Z®에만 관련이 있습니다.

  • OADP 1.1.7은 IBM Power® 및 IBM Z® 모두에 대해 OpenShift Container Platform 4.11에 대해 성공적으로 테스트되었습니다. 다음 섹션에서는 이러한 시스템의 백업 위치 측면에서 OADP 1.1.7에 대한 테스트 및 지원 정보를 제공합니다.
  • OADP 1.2.3은 IBM Power® 및 IBM Z® 모두에 대해 OpenShift Container Platform 4.12, 4.13, 4.14 및 4.15에 대해 성공적으로 테스트되었습니다. 다음 섹션에서는 이러한 시스템의 백업 위치 측면에서 OADP 1.2.3에 대한 테스트 및 지원 정보를 제공합니다.
  • OADP 1.3.6은 IBM Power® 및 IBM Z® 모두에 대해 OpenShift Container Platform 4.12, 4.13, 4.14 및 4.15에 대해 성공적으로 테스트되었습니다. 다음 섹션에서는 이러한 시스템의 백업 위치 관점에서 OADP 1.3.6에 대한 테스트 및 지원 정보를 제공합니다.
4.4.5.1. IBM Power를 사용하여 대상 백업 위치에 대한 OADP 지원
  • OpenShift Container Platform 4.11 및 4.12로 실행 중인 IBM Power®는 OADP(OpenShift API for Data Protection) 1.1.7을 사용하여 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트에는 AWS S3 대상만 포함되었지만 Red Hat은 OpenShift Container Platform 4.11 및 4.12를 사용하여 IBM Power® 실행을 지원하며 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OADP 1.1.7도 지원합니다.
  • OpenShift Container Platform 4.12, 4.13, 4.14, 4.15 및 OADP 1.2.3에서 실행되는 IBM Power®는 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트는 AWS S3 대상만 포함했지만 Red Hat은 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OpenShift Container Platform 4.12, 4.13. 4.14, 4.15 및 OADP 1.2.3을 사용하여 IBM Power® 실행을 지원합니다.
  • OpenShift Container Platform 4.12, 4.13, 4.14, 4.15 및 OADP 1.3.6에서 실행 중인 IBM Power®는 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트에는 AWS S3 대상만 포함되었지만 Red Hat은 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OpenShift Container Platform 4.12, 4.13, 4.14, 4.15, OADP 1.3.6을 사용하여 IBM Power® 실행을 지원합니다.
4.4.5.2. OADP 테스트 및 IBM Z를 사용하여 대상 백업 위치 지원
  • OpenShift Container Platform 4.11 및 4.12로 실행 중인 IBM Z®는 OADP(OpenShift API for Data Protection) 1.1.7을 사용하여 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트에는 AWS S3 대상만 포함되었지만 Red Hat은 OpenShift Container Platform 4.11 및 4.12를 사용하여 IBM Z® 실행을 지원하며 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OADP 1.1.7도 지원합니다.
  • OpenShift Container Platform 4.12, 4.13, 4.14, 4.15 및 OADP 1.2.3에서 실행 중인 IBM Z®는 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트는 AWS S3 대상만 포함했지만 Red Hat은 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OpenShift Container Platform 4.12, 4.14, 4.15 및 OADP 1.2.3을 사용하여 IBM Z® 실행을 지원합니다.
  • OpenShift Container Platform 4.12, 4.13, 4.14 및 4.15에서 실행 중인 IBM Z®는 AWS S3 백업 위치 대상에 대해 성공적으로 테스트되었습니다. 이 테스트는 AWS S3 대상만 포함했지만 Red Hat은 AWS가 아닌 모든 S3 백업 위치 대상에 대해 OpenShift Container Platform 4.12, 4.13 4.14, 4.15 및 1.3.6을 사용하여 IBM Z® 실행을 지원합니다.
4.4.5.2.1. IBM Power(R) 및 IBM Z(R) 플랫폼을 사용하는 OADP의 알려진 문제
  • 현재 IBM Power® 및 IBM Z® 플랫폼에 배포된 단일 노드 OpenShift 클러스터에 대한 백업 방법 제한 사항이 있습니다. 현재 NFS 스토리지만 이러한 플랫폼의 단일 노드 OpenShift 클러스터와 호환됩니다. 또한 Kopia 및 Restic과 같은 파일 시스템 백업(FSB) 메서드만 백업 및 복원 작업에 지원됩니다. 현재 이 문제에 대한 해결방법이 없습니다.

4.4.6. OADP 플러그인의 알려진 문제

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

4.4.6.1. 시크릿이 누락되어 이미지 스트림 백업 중 Velero 플러그인 패닉

백업 및 백업 스토리지 위치(BSL)가 데이터 보호 애플리케이션(DPA)의 범위 외부에서 관리되는 경우, OADP 컨트롤러는 DPA 조정에서 관련 oadp-<bsl_name>-<bsl_provider>-registry-secret 을 생성하지 않습니다.

백업이 실행되면 다음 패닉 오류와 함께 이미지 스트림 백업에 OpenShift Velero 플러그인이 패닉됩니다.

024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item"
backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io,
namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked:
runtime error: index out of range with length 1, stack trace: goroutine 94…
4.4.6.1.1. 패닉 오류를 방지하기 위한 해결방법

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

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

    $ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl
  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'
4.4.6.2. OpenShift ADP 컨트롤러 분할 오류

cloudstoragerestic 이 활성화된 DPA를 구성하는 경우 openshift-adp-controller-manager Pod가 충돌하고 크래시 루프 세그먼트 오류로 인해 Pod가 실패할 때까지 무기한 재시작합니다.

상호 배타적 필드이므로 velero 또는 cloudstorage 를 정의할 수 있습니다.

  • velerocloudstorage 가 모두 정의되어 있는 경우 openshift-adp-controller-manager 가 실패합니다.
  • velero 또는 cloudstorage 가 정의되지 않은 경우 openshift-adp-controller-manager 가 실패합니다.

이 문제에 대한 자세한 내용은 OADP-1054 를 참조하십시오.

4.4.6.2.1. OpenShift ADP 컨트롤러 분할 오류 해결

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

4.5. OADP 사용 사례

4.5.1. 데이터 보호 및 {odf-first}용 OpenShift API를 사용한 백업

다음은 애플리케이션을 백업하기 위해 OADP 및 {odf-short}을 사용하는 사용 사례입니다.

4.5.1.1. OADP 및 {odf-short}을 사용하여 애플리케이션 백업

이 사용 사례에서는 OADP를 사용하여 애플리케이션을 백업하고 {odf-first}에서 제공하는 오브젝트 스토리지에 백업을 저장합니다.

  • OBC(오브젝트 버킷 클레임)를 생성하여 백업 스토리지 위치를 구성합니다. {odf-short}을 사용하여 Amazon S3 호환 오브젝트 스토리지 버킷을 구성합니다. {odf-short}은 MultiCloud Object Gateway(NooBaa MCG) 및 Ceph Object Gateway(RGW), 개체 스토리지 서비스라고도 합니다. 이 사용 사례에서는 NooBaa MCG를 백업 스토리지 위치로 사용합니다.
  • aws 공급자 플러그인을 사용하여 OADP와 함께 NooBaa MCG 서비스를 사용합니다.
  • BPA(데이터 보호 애플리케이션)를 백업 스토리지 위치(BSL)로 구성합니다.
  • 백업 CR(사용자 정의 리소스)을 생성하고 백업할 애플리케이션 네임스페이스를 지정합니다.
  • 백업을 생성하고 확인합니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • {odf-short} Operator를 설치했습니다.
  • 별도의 네임스페이스에서 실행 중인 데이터베이스가 있는 애플리케이션이 있습니다.

절차

  1. 다음 예와 같이 OBC 매니페스트 파일을 생성하여 NooBaa MCG 버킷을 요청합니다.

    OBC의 예

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: test-obc 1
      namespace: openshift-adp
    spec:
      storageClassName: openshift-storage.noobaa.io
      generateBucketName: test-backup-bucket 2

    1
    오브젝트 버킷 클레임의 이름입니다.
    2
    버킷의 이름입니다.
  2. 다음 명령을 실행하여 OBC를 생성합니다.

    $ oc create -f <obc_file_name> 1
    1
    오브젝트 버킷 클레임 매니페스트의 파일 이름을 지정합니다.
  3. OBC를 생성할 때 {odf-short}은 오브젝트 버킷 클레임과 동일한 이름의 시크릿구성 맵 을 생성합니다. 시크릿에 는 버킷 인증 정보가 있으며 구성 맵에 는 버킷에 액세스하는 데 필요한 정보가 있습니다. 생성된 구성 맵에서 버킷 이름과 버킷 호스트를 가져오려면 다음 명령을 실행합니다.

    $ oc extract --to=- cm/test-obc 1
    1
    test-obc 는 OBC의 이름입니다.

    출력 예

    # BUCKET_NAME
    backup-c20...41fd
    # BUCKET_PORT
    443
    # BUCKET_REGION
    
    # BUCKET_SUBREGION
    
    # BUCKET_HOST
    s3.openshift-storage.svc

  4. 생성된 보안 에서 버킷 인증 정보를 가져오려면 다음 명령을 실행합니다.

    $ oc extract --to=- secret/test-obc

    출력 예

    # AWS_ACCESS_KEY_ID
    ebYR....xLNMc
    # AWS_SECRET_ACCESS_KEY
    YXf...+NaCkdyC3QPym

  5. 다음 명령을 실행하여 openshift-storage 네임스페이스의 s3 경로에서 S3 끝점의 공용 URL을 가져옵니다.

    $ oc get route s3 -n openshift-storage
  6. 다음 명령에 표시된 대로 오브젝트 버킷 인증 정보를 사용하여 cloud-credentials 파일을 만듭니다.

    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
  7. 다음 명령에 표시된 대로 cloud-credentials 파일 콘텐츠를 사용하여 cloud-credentials 시크릿을 생성합니다.

    $ oc create secret generic \
      cloud-credentials \
      -n openshift-adp \
      --from-file cloud=cloud-credentials
  8. 다음 예와 같이 DPA(Data Protection Application)를 구성합니다.

    DPA 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: oadp-backup
      namespace: openshift-adp
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - aws
            - openshift
            - csi
          defaultSnapshotMoveData: true 1
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: noobaa
              s3Url: https://s3.openshift-storage.svc 2
              s3ForcePathStyle: "true"
              insecureSkipTLSVerify: "true"
            provider: aws
            default: true
            credential:
              key: cloud
              name:  cloud-credentials
            objectStorage:
              bucket: <bucket_name> 3
              prefix: oadp

    1
    OADP Data Mover를 사용하여 CSI(Container Storage Interface) 스냅샷을 원격 오브젝트 스토리지로 이동하려면 true로 설정합니다.
    2
    {odf-short} 스토리지의 S3 URL입니다.
    3
    버킷 이름을 지정합니다.
  9. 다음 명령을 실행하여 DPA를 생성합니다.

    $ oc apply -f <dpa_filename>
  10. 다음 명령을 실행하여 DPA가 성공적으로 생성되었는지 확인합니다. 예제 출력에서 status 오브젝트에 type 필드가 Reconciled 으로 설정되어 있음을 확인할 수 있습니다. 즉, DPA가 성공적으로 생성됩니다.

    $ oc get dpa -o yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        namespace: openshift-adp
        #...#
      spec:
        backupLocations:
        - velero:
            config:
              #...#
      status:
        conditions:
        - lastTransitionTime: "20....9:54:02Z"
          message: Reconcile complete
          reason: Complete
          status: "True"
          type: Reconciled
    kind: List
    metadata:
      resourceVersion: ""

  11. 다음 명령을 실행하여 백업 스토리지 위치(BSL)를 사용할 수 있는지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE   DEFAULT
    dpa-sample-1   Available   3s               15s   true

  12. 다음 예와 같이 백업 CR을 구성합니다.

    백업 CR의 예

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <application_namespace> 1

    1
    애플리케이션을 백업할 네임스페이스를 지정합니다.
  13. 다음 명령을 실행하여 backup CR을 생성합니다.

    $ oc apply -f <backup_cr_filename>

검증

  • 다음 명령을 실행하여 백업 오브젝트가 Completed 단계에 있는지 확인합니다. 자세한 내용은 예제 출력을 참조하십시오.

    $ oc describe backup test-backup -n openshift-adp

    출력 예

    Name:         test-backup
    Namespace:    openshift-adp
    # ....#
    Status:
      Backup Item Operations Attempted:  1
      Backup Item Operations Completed:  1
      Completion Timestamp:              2024-09-25T10:17:01Z
      Expiration:                        2024-10-25T10:16:31Z
      Format Version:                    1.1.0
      Hook Status:
      Phase:  Completed
      Progress:
        Items Backed Up:  34
        Total Items:      34
      Start Timestamp:    2024-09-25T10:16:31Z
      Version:            1
    Events:               <none>

4.5.2. OADP(OpenShift API for Data Protection) 복원 사용 사례

다음은 OADP를 사용하여 다른 네임스페이스로 백업을 복원하는 사용 사례입니다.

4.5.2.1. OADP를 사용하여 애플리케이션을 다른 네임스페이스로 복원

OADP를 새 대상 네임스페이스 test-restore-application 에 사용하여 애플리케이션 백업을 복원합니다. 백업을 복원하려면 다음 예와 같이 복원 사용자 정의 리소스(CR)를 생성합니다. restore CR에서 소스 네임스페이스는 백업에 포함된 애플리케이션 네임스페이스를 나타냅니다. 그런 다음 프로젝트를 새 복원 네임스페이스로 변경하고 리소스를 확인하여 복원을 확인합니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • 복원할 애플리케이션의 백업이 있습니다.

절차

  1. 다음 예와 같이 복원 CR을 생성합니다.

    복원 CR의 예

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: test-restore 1
      namespace: openshift-adp
    spec:
      backupName: <backup_name> 2
      restorePVs: true
      namespaceMapping:
        <application_namespace>: test-restore-application 3

    1
    복원 CR의 이름입니다.
    2
    백업 이름을 지정합니다.
    3
    namespaceMapping 은 소스 애플리케이션 네임스페이스를 대상 애플리케이션 네임스페이스에 매핑합니다. 백업한 애플리케이션 네임스페이스를 지정합니다. test-restore-application 은 백업을 복원하려는 대상 네임스페이스입니다.
  2. 다음 명령을 실행하여 복원 CR을 적용합니다.

    $ oc apply -f <restore_cr_filename>

검증

  1. 다음 명령을 실행하여 복원이 완료된 단계에 있는지 확인합니다.

    $ oc describe restores.velero.io <restore_name> -n openshift-adp
  2. 다음 명령을 실행하여 복원된 네임스페이스 test-restore-application 로 변경합니다.

    $ oc project test-restore-application
  3. 다음 명령을 실행하여 영구 볼륨 클레임(pvc), 서비스(svc), 배포, 시크릿, 구성 맵과 같은 복원된 리소스를 확인합니다.

    $ oc get pvc,svc,deployment,secret,configmap

    출력 예

    NAME                          STATUS   VOLUME
    persistentvolumeclaim/mysql   Bound    pvc-9b3583db-...-14b86
    
    NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
    service/mysql      ClusterIP   172....157     <none>        3306/TCP   2m56s
    service/todolist   ClusterIP   172.....15     <none>        8000/TCP   2m56s
    
    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/mysql   0/1     1            0           2m55s
    
    NAME                                         TYPE                      DATA   AGE
    secret/builder-dockercfg-6bfmd               kubernetes.io/dockercfg   1      2m57s
    secret/default-dockercfg-hz9kz               kubernetes.io/dockercfg   1      2m57s
    secret/deployer-dockercfg-86cvd              kubernetes.io/dockercfg   1      2m57s
    secret/mysql-persistent-sa-dockercfg-rgp9b   kubernetes.io/dockercfg   1      2m57s
    
    NAME                                 DATA   AGE
    configmap/kube-root-ca.crt           1      2m57s
    configmap/openshift-service-ca.crt   1      2m57s

4.5.3. 백업 중 자체 서명된 CA 인증서 포함

DPA(Data Protection Application)에 자체 서명된 CA(인증 기관) 인증서를 추가한 다음 애플리케이션을 백업할 수 있습니다. {odf-first}에서 제공하는 NooBaa 버킷에 백업을 저장합니다.

4.5.3.1. 애플리케이션 및 자체 서명된 CA 인증서 백업

{odf-short}에서 제공하는 s3.openshift-storage.svc 서비스는 자체 서명된 서비스 CA로 서명된 TLS(Transport Layer Security Protocol) 인증서를 사용합니다.

알 수 없는 기관 오류로 서명된 인증서 를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스)의 백업 스토리지 위치(BSL) 섹션에 자체 서명된 CA 인증서를 포함해야 합니다. 이 경우 다음 작업을 완료해야 합니다.

  • OBC(오브젝트 버킷 클레임)를 생성하여 NooBaa 버킷을 요청합니다.
  • 버킷 세부 정보를 추출합니다.
  • DataProtectionApplication CR에 자체 서명된 CA 인증서를 포함합니다.
  • 애플리케이션을 백업합니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • {odf-short} Operator를 설치했습니다.
  • 별도의 네임스페이스에서 실행 중인 데이터베이스가 있는 애플리케이션이 있습니다.

절차

  1. 다음 예와 같이 OBC 매니페스트를 생성하여 NooBaa 버킷을 요청합니다.

    ObjectBucketClaim CR의 예

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: test-obc 1
      namespace: openshift-adp
    spec:
      storageClassName: openshift-storage.noobaa.io
      generateBucketName: test-backup-bucket 2

    1
    오브젝트 버킷 클레임의 이름을 지정합니다.
    2
    버킷의 이름을 지정합니다.
  2. 다음 명령을 실행하여 OBC를 생성합니다.

    $ oc create -f <obc_file_name>
  3. OBC를 생성할 때 {odf-short}은 오브젝트 버킷 클레임과 동일한 이름의 시크릿ConfigMap 을 생성합니다. 보안 오브젝트에는 버킷 인증 정보가 포함되어 있으며 ConfigMap 오브젝트에는 버킷에 액세스하는 데 필요한 정보가 포함되어 있습니다. 생성된 구성 맵에서 버킷 이름과 버킷 호스트를 가져오려면 다음 명령을 실행합니다.

    $ oc extract --to=- cm/test-obc 1
    1
    OBC의 이름은 test-obc 입니다.

    출력 예

    # BUCKET_NAME
    backup-c20...41fd
    # BUCKET_PORT
    443
    # BUCKET_REGION
    
    # BUCKET_SUBREGION
    
    # BUCKET_HOST
    s3.openshift-storage.svc

  4. 보안 오브젝트에서 버킷 인증 정보를 가져오려면 다음 명령을 실행합니다.

    $ oc extract --to=- secret/test-obc

    출력 예

    # AWS_ACCESS_KEY_ID
    ebYR....xLNMc
    # AWS_SECRET_ACCESS_KEY
    YXf...+NaCkdyC3QPym

  5. 다음 예제 구성을 사용하여 오브젝트 버킷 자격 증명으로 cloud-credentials 파일을 생성합니다.

    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
  6. 다음 명령을 실행하여 cloud-credentials 파일 콘텐츠를 사용하여 cloud-credentials 시크릿을 생성합니다.

    $ oc create secret generic \
      cloud-credentials \
      -n openshift-adp \
      --from-file cloud=cloud-credentials
  7. 다음 명령을 실행하여 openshift-service-ca.crt 구성 맵에서 서비스 CA 인증서를 추출합니다. 인증서를 Base64 형식으로 인코딩하고 다음 단계에서 사용할 값을 기록해야 합니다.

    $ oc get cm/openshift-service-ca.crt \
      -o jsonpath='{.data.service-ca\.crt}' | base64 -w0; echo

    출력 예

    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0...
    ....gpwOHMwaG9CRmk5a3....FLS0tLS0K

  8. 다음 예와 같이 버킷 이름 및 CA 인증서를 사용하여 DataProtectionApplication CR 매니페스트 파일을 구성합니다.

    Example DataProtectionApplication CR

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: oadp-backup
      namespace: openshift-adp
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - aws
            - openshift
            - csi
          defaultSnapshotMoveData: true
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: noobaa
              s3Url: https://s3.openshift-storage.svc
              s3ForcePathStyle: "true"
              insecureSkipTLSVerify: "false" 1
            provider: aws
            default: true
            credential:
              key: cloud
              name:  cloud-credentials
            objectStorage:
              bucket: <bucket_name> 2
              prefix: oadp
              caCert: <ca_cert> 3

    1
    insecureSkipTLSVerify 플래그는 true 또는 false 로 설정할 수 있습니다. "true"로 설정하면 SSL/TLS 보안이 비활성화됩니다. false 로 설정하면 SSL/TLS 보안이 활성화됩니다.
    2
    이전 단계에서 추출한 버킷의 이름을 지정합니다.
    3
    이전 단계에서 Base64 로 인코딩된 인증서를 복사하여 붙여넣습니다.
  9. 다음 명령을 실행하여 DataProtectionApplication CR을 생성합니다.

    $ oc apply -f <dpa_filename>
  10. 다음 명령을 실행하여 DataProtectionApplication CR이 성공적으로 생성되었는지 확인합니다.

    $ oc get dpa -o yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        namespace: openshift-adp
        #...#
      spec:
        backupLocations:
        - velero:
            config:
              #...#
      status:
        conditions:
        - lastTransitionTime: "20....9:54:02Z"
          message: Reconcile complete
          reason: Complete
          status: "True"
          type: Reconciled
    kind: List
    metadata:
      resourceVersion: ""

  11. 다음 명령을 실행하여 백업 스토리지 위치(BSL)를 사용할 수 있는지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE   DEFAULT
    dpa-sample-1   Available   3s               15s   true

  12. 다음 예제를 사용하여 Backup CR을 구성합니다.

    Backup CR의 예

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <application_namespace> 1

    1
    애플리케이션을 백업할 네임스페이스를 지정합니다.
  13. 다음 명령을 실행하여 Backup CR을 생성합니다.

    $ oc apply -f <backup_cr_filename>

검증

  • 다음 명령을 실행하여 Backup 오브젝트가 Completed 단계에 있는지 확인합니다.

    $ oc describe backup test-backup -n openshift-adp

    출력 예

    Name:         test-backup
    Namespace:    openshift-adp
    # ....#
    Status:
      Backup Item Operations Attempted:  1
      Backup Item Operations Completed:  1
      Completion Timestamp:              2024-09-25T10:17:01Z
      Expiration:                        2024-10-25T10:16:31Z
      Format Version:                    1.1.0
      Hook Status:
      Phase:  Completed
      Progress:
        Items Backed Up:  34
        Total Items:      34
      Start Timestamp:    2024-09-25T10:16:31Z
      Version:            1
    Events:               <none>

4.6. OADP 설치 및 구성

4.6.1. OADP 설치 정보

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

참고

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

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

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

참고

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

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

중요

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

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

참고

CloudStorage API는 CloudStorage 오브젝트를 사용하고 OADP에서 CloudStorage API를 사용하여 BackupStorageLocation 으로 사용할 S3 버킷을 자동으로 생성하도록 하는 경우 기술 프리뷰 기능입니다.

CloudStorage API는 기존 S3 버킷을 지정하여 BackupStorageLocation 오브젝트를 수동으로 생성할 수 있도록 지원합니다. S3 버킷을 자동으로 생성하는 CloudStorage API는 현재 AWS S3 스토리지에만 활성화됩니다.

스냅샷 또는 FSB(파일 시스템 백업)를 사용하여 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인 경우 오브젝트 스토리지에서 File System Backup: Kopia 또는 Restic을 사용하여 애플리케이션을 백업하여 애플리케이션을 백업할 수 있습니다.

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

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

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

4.6.1.1.1. 지원되는 백업 스토리지 공급자

다음 AWS S3 호환 오브젝트 스토리지 공급자는 AWS 플러그인을 통해 백업 스토리지 위치로 사용하기 위해 OADP에서 완전히 지원합니다.

  • MinIO
  • MCG(Multicloud Object Gateway)
  • AWS(Amazon Web Services) S3
  • IBM Cloud® Object Storage S3
  • Ceph RADOS Gateway(Ceph Object Gateway)
  • Red Hat Container Storage
  • {odf-full}
  • GCP(Google Cloud Platform)
  • Microsoft Azure
참고

GCP(Google Cloud Platform) 및 Microsoft Azure에는 자체 Velero 오브젝트 저장소 플러그인이 있습니다.

4.6.1.1.2. 지원되지 않는 백업 스토리지 공급자

다음 AWS S3 호환 오브젝트 스토리지 공급자는 백업 스토리지 위치로 사용하기 위해 AWS 플러그인을 통해 Velero와 함께 작업하는 것으로 알려져 있지만 이는 지원되지 않으며 Red Hat에서 테스트하지 않았습니다.

  • IBM Cloud
  • Oracle Cloud
  • DigitalOcean
  • MCG(Multicloud Object Gateway)를 사용하여 설치하지 않는 한 NooBaa
  • Tencent Cloud
  • Ceph RADOS v12.2.7
  • Quobyte
  • Cloudian HyperStore
참고

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

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

4.6.1.1.3. 알려진 제한이 있는 백업 스토리지 공급자

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

  • Swift - 백업 스토리지의 백업 스토리지 위치로 사용하기 위해 작동하지만 파일 시스템 기반 볼륨 백업 및 복원에는 Restic과 호환되지 않습니다.
4.6.1.2. OpenShift Data Foundation에서 재해 복구를 위해 MCG(Multicloud Object Gateway) 구성

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

주의

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

참고

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

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

절차

4.6.1.3. OADP 업데이트 채널 정보

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

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

  • stable 채널이 더 이상 사용되지 않습니다. stable 채널에는 OADP.v1.1.z 용 OADP ClusterServiceVersionOADP.v1.0.z 의 이전 버전의 패치(z-stream 업데이트)가 포함되어 있습니다.
  • stable-1.0 채널은 더 이상 사용되지 않으며 지원되지 않습니다.
  • stable-1.1 채널은 더 이상 사용되지 않으며 지원되지 않습니다.
  • stable-1.2 채널은 더 이상 사용되지 않으며 지원되지 않습니다.
  • stable-1.3 채널에는 최신 OADP 1.3 ClusterServiceVersionOADP.v1.3.z 가 포함되어 있습니다.
  • stable-1.4 채널에는 최신 OADP 1.4 ClusterServiceVersionOADP.v1.4.z 가 포함되어 있습니다.

자세한 내용은 OpenShift Operator 라이프 사이클 을 참조하십시오.

어떤 업데이트 채널을 사용할 수 있습니까?

  • stable 채널이 더 이상 사용되지 않습니다. stable 채널을 이미 사용 중인 경우 OADP.v1.1.z 에서 업데이트를 계속 받을 수 있습니다.
  • OADP 1.y를 설치하고 패치를 계속 받을 stable-1.y 업데이트 채널을 선택합니다. 이 채널을 선택하면 버전 1.y.z에 대한 모든 z-stream 패치가 제공됩니다.

언제 업데이트 채널을 전환해야합니까?

  • OADP 1.y가 설치되어 있고 해당 y-stream용 패치를 받으려면 stable 업데이트 채널에서 stable -1.y 업데이트 채널로 전환해야 합니다. 그런 다음 버전 1.y.z에 대한 모든 z-stream 패치를 받게 됩니다.
  • OADP 1.0이 설치되어 있고 OADP 1.1로 업그레이드하려는 경우 패치는 stable-1.0 업데이트 채널에서 stable-1.1 업데이트 채널로 전환해야 합니다. 그런 다음 버전 1.1.z에 대한 모든 z-stream 패치를 받게 됩니다.
  • OADP 1. y 가 0보다 크고 OADP 1.0으로 전환하려면 OADP Operator를 제거한 다음 stable-1.0 업데이트 채널을 사용하여 다시 설치해야 합니다. 그런 다음 버전 1.0.z에 대한 모든 z-stream 패치를 받게 됩니다.
참고

업데이트 채널을 전환하여 OADP 1.y에서 OADP 1.0으로 전환할 수 없습니다. Operator를 제거한 다음 다시 설치해야 합니다.

4.6.1.4. 여러 네임스페이스에 OADP 설치

여러 프로젝트 소유자가 자체 OADP 인스턴스를 관리할 수 있도록 OADP(OpenShift API for Data Protection)를 동일한 클러스터의 여러 네임스페이스에 설치할 수 있습니다. 이 사용 사례는 파일 시스템 백업(FSB) 및 CSI(Container Storage Interface)에서 검증되었습니다.

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

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

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

4.6.1.5.1. 구성에 대한 CPU 및 메모리 요구 사항
구성 유형[1] 평균 사용량[2] 대규모 사용resourceTimeouts

CSI

Velero:

cpu- 요청 200m, 제한 1000m

memory - 256Mi 요청, 제한 1024Mi

Velero:

CPU- 요청 200m, 제한 2000m

memory- requests 256Mi, Limits 2048Mi

해당 없음

Restic

[3] Restic:

CPU- 요청 1000m, 제한 2000m

memory - 16Gi 요청, 32Gi 제한

[4] Restic:

CPU - 2000m 요청, 8000m 제한

Memory - 16Gi 요청, 제한 40Gi

900m

[5] 데이터 관리

해당 없음

해당 없음

10m - 평균 사용량

60m - 대규모 사용

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

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

4.6.1.5.2. 대규모 사용을 위한 nodeagent CPU

테스트 결과 NodeAgent CPU를 늘리면 OADP(OpenShift API for Data Protection)를 사용할 때 백업 및 복원 시간을 크게 향상시킬 수 있습니다.

중요

Kopia의 적극적인 리소스 사용으로 인해 프로덕션 워크로드를 실행하는 노드의 프로덕션 환경에서 제한 없이 Kopia를 사용하지 않는 것이 좋습니다. 그러나 너무 낮은 제한으로 Kopia를 실행하면 CPU 제한 및 백업 속도가 느려지고 복원 상황이 발생합니다. 테스트 결과 20개 코어 및 32Gi 메모리가 있는 Kopia를 실행하면 100GB 이상의 데이터, 여러 네임스페이스 또는 2000개 이상의 Pod가 단일 네임스페이스에서 백업 및 복원 작업을 지원했습니다.

이러한 리소스 사양을 사용하여 CPU 제한 또는 메모리 포화 상태로 감지된 테스트입니다.

rook-ceph Pod에서 CPU 및 메모리 리소스 변경 절차에 따라 Ceph MDS Pod 에서 이러한 제한을 설정할 수 있습니다.

제한을 설정하려면 스토리지 클러스터 CR(사용자 정의 리소스)에 다음 행을 추가해야 합니다.

   resources:
     mds:
       limits:
         cpu: "3"
         memory: 128Gi
       requests:
         cpu: "3"
         memory: 8Gi

4.6.2. OADP Operator 설치

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

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

사전 요구 사항

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

절차

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
  3. OADP Operator 를 선택하고 설치를 클릭합니다.
  4. 설치를 클릭하여 openshift-adp 프로젝트에서 Operator를 설치합니다.
  5. Operators설치된 Operators 를 클릭하여 설치를 확인합니다.
4.6.2.1. OADP-Velero-OpenShift Container Platform 버전 관계
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

1.4.0

1.14

4.14 이상

1.4.1

1.14

4.14 이상

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

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

참고

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

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

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

4.6.3.1. Amazon Web Services 구성

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

사전 요구 사항

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

절차

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

    $ BUCKET=<your_bucket>
  2. REGION 변수를 설정합니다.

    $ REGION=<your_region>
  3. AWS S3 버킷을 생성합니다.

    $ aws s3api create-bucket \
        --bucket $BUCKET \
        --region $REGION \
        --create-bucket-configuration LocationConstraint=$REGION 1
    1
    us-east-1LocationConstraint를 지원하지 않습니다. 리전이 us-east-1인 경우 --create-bucket-configuration LocationConstraint=$REGION을 생략합니다.
  4. IAM 사용자를 생성합니다.

    $ aws iam create-user --user-name velero 1
    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
  6. 정책을 연결하여 velero 사용자에게 최소한의 필요한 권한을 부여합니다.

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero \
      --policy-document file://velero-policy.json
  7. velero 사용자에 대한 액세스 키를 생성합니다.

    $ aws iam create-access-key --user-name velero

    출력 예

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

  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

    Data Protection Application을 설치하기 전에 credentials-velero 파일을 사용하여 AWS에 대한 Secret 오브젝트를 생성합니다.

4.6.3.2. 백업 및 스냅샷 위치 및 시크릿 정보

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

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.

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

스냅샷 위치

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

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

FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

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

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

  • 백업 위치에 대한 사용자 지정 보안( DataProtectionApplication CR에서 지정)
  • DataProtectionApplication CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
중요

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

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

4.6.3.2.1. 기본 보안 생성

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

Secret 의 기본 이름은 cloud-credentials 입니다.

참고

DataProtectionApplication 사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret 이 지정되지 않은 경우 기본 이름이 사용됩니다.

설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 이름으로 Secret 을 생성할 수 있습니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
  • Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

절차

  • 기본 이름으로 보안을 생성합니다.

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

Data Protection Application을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 Secret 을 참조합니다.

4.6.3.2.2. 다양한 자격 증명에 대한 프로필 생성

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

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

절차

  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>
  2. credentials-velero 파일을 사용하여 Secret 오브젝트를 생성합니다.

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero 1
  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"
4.6.3.2.3. AWS를 사용하여 백업 스토리지 위치 구성

다음 예제 절차에 표시된 대로 AWS 백업 스토리지 위치(BSL)를 구성할 수 있습니다.

사전 요구 사항

  • AWS를 사용하여 오브젝트 스토리지 버킷을 생성했습니다.
  • OADP Operator가 설치되어 있습니다.

절차

  • 사용 사례에 적용할 수 있는 값으로 BSL CR(사용자 정의 리소스)을 구성합니다.

    백업 스토리지 위치

    apiVersion: oadp.openshift.io/v1alpha1
    kind: BackupStorageLocation
    metadata:
      name: default
      namespace: openshift-adp
    spec:
      provider: aws 1
      objectStorage:
        bucket: <bucket_name> 2
        prefix: <bucket_prefix> 3
      credential: 4
        key: cloud 5
        name: cloud-credentials 6
      config:
        region: <bucket_region> 7
        s3ForcePathStyle: "true" 8
        s3Url: <s3_url> 9
        publicUrl: <public_s3_url> 10
        serverSideEncryption: AES256 11
        kmsKeyId: "50..c-4da1-419f-a16e-ei...49f" 12
        customerKeyEncryptionFile: "/credentials/customer-key" 13
        signatureVersion: "1" 14
        profile: "default" 15
        insecureSkipTLSVerify: "true" 16
        enableSharedConfig: "true" 17
        tagging: "" 18
        checksumAlgorithm: "CRC32" 19

    1 1
    오브젝트 저장소 플러그인의 이름입니다. 이 예제에서 플러그인은 aws 입니다. 이 필드는 필수입니다.
    2
    백업을 저장할 버킷의 이름입니다. 이 필드는 필수입니다.
    3
    백업을 저장할 버킷 내 접두사입니다. 이 필드는 선택 사항입니다.
    4
    백업 스토리지 위치에 대한 자격 증명입니다. 사용자 지정 인증 정보를 설정할 수 있습니다. 사용자 정의 인증 정보가 설정되지 않은 경우 기본 인증 정보의 시크릿이 사용됩니다.
    5
    시크릿 인증 정보 데이터 내의 입니다.
    6
    인증 정보가 포함된 시크릿의 이름입니다.
    7
    버킷이 있는 AWS 리전입니다. s3ForcePathStyle이 false인 경우 선택 사항입니다.
    8
    가상 호스트 버킷 주소 지정 대신 경로 스타일 주소 지정을 사용할지 여부를 결정하는 부울 플래그입니다. MinIO 또는 NooBaa와 같은 스토리지 서비스를 사용하는 경우 true 로 설정합니다. 이 필드는 선택적 필드입니다. 기본값은 false입니다.
    9
    명시적성을 위해 AWS S3 URL을 지정할 수 있습니다. 이 필드는 주로 MinIO 또는 NooBaa와 같은 스토리지 서비스를 위한 것입니다. 이 필드는 선택적 필드입니다.
    10
    이 필드는 주로 MinIO 또는 NooBaa와 같은 스토리지 서비스에 사용됩니다. 이 필드는 선택적 필드입니다.
    11
    오브젝트 업로드에 사용할 서버 측 암호화 알고리즘의 이름입니다(예: AES256 ). 이 필드는 선택적 필드입니다.
    12
    AWS KMS 키 ID를 지정합니다. 예제에 표시된 대로 별칭(예: alias/<KMS-key-alias-name > ) 또는 전체 ARN 을 지정하여 S3에 저장된 백업의 암호화를 활성화할 수 있습니다. kmsKeyIdcustomerKeyEncryptionFile 과 함께 사용할 수 없습니다. 이 필드는 선택적 필드입니다.
    13
    SSE-C 고객 키가 있는 파일을 지정하여 S3에 저장된 백업의 고객 키 암호화를 활성화합니다. 파일에는 32바이트 문자열이 포함되어야 합니다. customerKeyEncryptionFile 필드는 velero 컨테이너 내에서 마운트된 시크릿을 가리킵니다. velero cloud-credentials 시크릿에 다음 키-값 쌍을 추가합니다. customer-key: <your_b64_encoded_32byte_string>. customerKeyEncryptionFile 필드는 kmsKeyId 필드와 함께 사용할 수 없습니다. 기본값은 빈 문자열("")이며 이는 SSE-C 가 비활성화되어 있습니다. 이 필드는 선택적 필드입니다.
    14
    서명된 URL을 생성하는 데 사용되는 서명 알고리즘의 버전입니다. 서명된 URL을 사용하여 백업을 다운로드하거나 로그를 가져옵니다. 유효한 값은 14 입니다. 기본 버전은 4 입니다. 이 필드는 선택적 필드입니다.
    15
    인증 정보 파일에 있는 AWS 프로필의 이름입니다. 기본값은 default입니다. 이 필드는 선택적 필드입니다.
    16
    오브젝트 저장소에 연결할 때 TLS 인증서를 확인하지 않으려면 insecureSkipTLSVerify 필드를 true 로 설정합니다(예: MinIO를 사용한 자체 서명 인증서의 경우). true 로 설정하는 것은 중간자 공격에 취약하며 프로덕션 워크로드에는 권장되지 않습니다. 기본값은 false입니다. 이 필드는 선택적 필드입니다.
    17
    인증 정보 파일을 공유 구성 파일로 로드하려면 enableSharedConfig 필드를 true 로 설정합니다. 기본값은 false입니다. 이 필드는 선택적 필드입니다.
    18
    AWS S3 오브젝트에 주석을 달 태그를 지정합니다. 키-값 쌍으로 태그를 지정합니다. 기본값은 빈 문자열("")입니다. 이 필드는 선택적 필드입니다.
    19
    오브젝트를 S3에 업로드하는 데 사용할 체크섬 알고리즘을 지정합니다. 지원되는 값은 CRC32 , CRC32 C,SHA1, SHA256 입니다. 필드를 빈 문자열("")으로 설정하면 체크섬 검사를 건너뜁니다. 기본값은 CRC32 입니다. 이 필드는 선택적 필드입니다.
4.6.3.2.4. 추가 데이터 보안을 위한 OADP SSE-C 암호화 키 생성

AWS(Amazon Web Services) S3는 Amazon S3 관리 키(SSE-S3)를 Amazon S3의 모든 버킷의 기본 암호화 수준으로 적용하여 서버 측 암호화를 적용합니다.

OADP(OpenShift API for Data Protection)는 클러스터에서 스토리지로 데이터를 전송할 때 SSL/TLS, HTTPS, velero-repo-credentials 시크릿을 사용하여 데이터를 암호화합니다. AWS 인증 정보가 손실되거나 도난된 경우 백업 데이터를 보호하려면 추가 암호화 계층을 적용합니다.

velero-plugin-for-aws 플러그인은 몇 가지 추가 암호화 방법을 제공합니다. 해당 구성 옵션을 검토하고 추가 암호화를 구현하는 것이 좋습니다.

SSE-C(고객 제공 키)와 함께 서버 측 암호화를 사용하여 고유한 암호화 키를 저장할 수 있습니다. 이 기능은 AWS 인증 정보가 노출되는 경우 추가 보안을 제공합니다.

주의

암호화 키를 안전하고 안전한 방식으로 저장해야 합니다. 암호화 키가 없는 경우 암호화된 데이터 및 백업을 복구할 수 없습니다.

사전 요구 사항

  • OADP 마운트를 /credentials 의 Velero pod에 포함하는 시크릿을 만들려면 cloud-credentials : cloud-credentials 에 다음과 같은 기본 시크릿 이름을 사용하고 다음 라벨 중 하나를 비워 둡니다.

참고

다음 절차에는 인증 정보를 지정하지 않는 spec:backupLocations 블록의 예가 포함되어 있습니다. 이 예제에서는 OADP 시크릿 마운트를 트리거합니다.

  • cloud-credentials 와 다른 이름으로 백업 위치가 필요한 경우 인증 정보 이름이 포함되지 않은 다음 예제의 스냅샷 위치를 추가해야 합니다. 예제에는 인증 정보 이름이 없기 때문에 스냅샷 위치는 cloud-credentials 를 스냅샷 생성의 시크릿으로 사용합니다.

인증 정보가 지정되지 않은 DPA의 스냅샷 위치 예

 snapshotLocations:
  - velero:
      config:
        profile: default
        region: <region>
      provider: aws
# ...

절차

  1. SSE-C 암호화 키를 생성합니다.

    1. 임의의 번호를 생성하고 다음 명령을 실행하여 sse.key 라는 파일로 저장합니다.

      $ dd if=/dev/urandom bs=1 count=32 > sse.key
    2. Base64를 사용하여 sse.key 를 인코딩하고 다음 명령을 실행하여 결과를 sse_encoded.key 라는 파일로 저장합니다.

      $ cat sse.key | base64 > sse_encoded.key
    3. 다음 명령을 실행하여 sse_encoded.key 라는 파일을 customer-key 라는 새 파일에 연결합니다.

      $ ln -s sse_encoded.key customer-key
  2. OpenShift Container Platform 시크릿을 생성합니다.

    • 처음에 OADP를 설치하고 구성하는 경우 다음 명령을 실행하여 AWS 인증 정보 및 암호화 키 시크릿을 동시에 생성합니다.

      $ oc create secret generic cloud-credentials --namespace openshift-adp --from-file cloud=<path>/openshift_aws_credentials,customer-key=<path>/sse_encoded.key
    • 기존 설치를 업데이트하는 경우 다음 예와 같이 DataProtectionApplication CR 매니페스트의 cloud-credential 시크릿 블록 값을 편집합니다.

      apiVersion: v1
      data:
        cloud: W2Rfa2V5X2lkPSJBS0lBVkJRWUIyRkQ0TlFHRFFPQiIKYXdzX3NlY3JldF9hY2Nlc3Nfa2V5P<snip>rUE1mNWVSbTN5K2FpeWhUTUQyQk1WZHBOIgo=
        customer-key: v+<snip>TFIiq6aaXPbj8dhos=
      kind: Secret
      # ...
  3. 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 backupLocations 블록에서 customerKeyEncryptionFile 속성 값을 편집합니다.

    spec:
      backupLocations:
        - velero:
            config:
              customerKeyEncryptionFile: /credentials/customer-key
              profile: default
    # ...
    주의

    기존 설치에서 시크릿 인증 정보를 올바르게 마운트하려면 Velero 포드를 다시 시작해야 합니다.

    설치가 완료되었으며 OpenShift Container Platform 리소스를 백업하고 복원할 수 있습니다. AWS S3 스토리지에 저장된 데이터는 새 키로 암호화되며 추가 암호화 키 없이는 AWS S3 콘솔 또는 API에서 다운로드할 수 없습니다.

검증

추가 키를 포함하지 않고 암호화된 파일을 다운로드할 수 없는지 확인하려면 테스트 파일을 만들고 업로드한 다음 다운로드하려고 합니다.

  1. 다음 명령을 실행하여 테스트 파일을 생성합니다.

    $ echo "encrypt me please" > test.txt
  2. 다음 명령을 실행하여 테스트 파일을 업로드합니다.

    $ aws s3api put-object \
      --bucket <bucket> \
      --key test.txt \
      --body test.txt \
      --sse-customer-key fileb://sse.key \
      --sse-customer-algorithm AES256
  3. 파일을 다운로드해 보십시오. Amazon 웹 콘솔 또는 터미널에서 다음 명령을 실행합니다.

    $ s3cmd get s3://<bucket>/test.txt test.txt

    파일이 추가 키로 암호화되므로 다운로드에 실패합니다.

  4. 다음 명령을 실행하여 추가 암호화 키로 파일을 다운로드합니다.

    $ aws s3api get-object \
        --bucket <bucket> \
        --key test.txt \
        --sse-customer-key fileb://sse.key \
        --sse-customer-algorithm AES256 \
        downloaded.txt
  5. 다음 명령을 실행하여 파일 내용을 읽습니다.

    $ cat downloaded.txt

    출력 예

    encrypt me please

추가 리소스

다른 명령을 실행하여 Velcro로 백업된 추가 암호화 키가 있는 파일을 다운로드할 수도 있습니다. Velero에서 지원하는 파일은 SSE-C 암호화 키로 파일 다운로드를 참조하십시오.

4.6.3.2.4.1. Velero에서 지원하는 파일의 SSE-C 암호화 키로 파일 다운로드

SSE-C 암호화 키를 확인하는 경우 Velcro로 백업된 파일의 추가 암호화 키로 파일을 다운로드할 수도 있습니다.

절차

  • 다음 명령을 실행하여 Velero에서 백업한 파일의 추가 암호화 키로 파일을 다운로드합니다.
$ aws s3api get-object \
  --bucket <bucket> \
  --key velero/backups/mysql-persistent-customerkeyencryptionfile4/mysql-persistent-customerkeyencryptionfile4.tar.gz \
  --sse-customer-key fileb://sse.key \
  --sse-customer-algorithm AES256 \
  --debug \
  velero_download.tar.gz
4.6.3.3. 데이터 보호 애플리케이션 구성

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

4.6.3.3.1. Velero CPU 및 메모리 리소스 할당 설정

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector> 1
            resourceAllocations: 2
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.
참고

Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.

Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.

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

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

4.6.3.3.2. 자체 서명된 CA 인증서 활성화

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.velero.objectStorage.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string> 1
            config:
              insecureSkipTLSVerify: "false" 2
    ...
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.6.3.3.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용

별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

    1. aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.

      $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
    2. 다음 명령을 실행하여 별칭이 작동하는지 확인합니다.

      예제

      $ velero version
      Client:
      	Version: v1.12.1-OADP
      	Git commit: -
      Server:
      	Version: v1.12.1-OADP

    3. 이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.

      $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
      
      $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
      $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
    4. 백업 로그를 가져오려면 다음 명령을 실행합니다.

      $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

      이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.

    5. Velero 포드가 다시 시작되면 /tmp/your-cacert.txt 파일이 사라지고 이전 단계의 명령을 다시 실행하여 /tmp/your-cacert.txt 파일을 다시 생성해야 합니다.
    6. 다음 명령을 실행하여 /tmp/your-cacert.txt 파일이 여전히 있는지 확인할 수 있습니다.

      $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
      /tmp/your-cacert.txt

향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.

4.6.3.4. 데이터 보호 애플리케이션 설치

DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application )를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치에서 동일한 자격 증명을 사용하는 경우 기본 이름 cloud-credentials 를 사용하여 보안을 생성해야 합니다.
  • 백업 및 스냅샷 위치에서 다른 자격 증명을 사용하는 경우 백업 및 스냅샷 위치 자격 증명에 대한 별도의 프로필이 포함된 기본 이름 cloud-credentials시크릿 을 생성해야 합니다.

    참고

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

절차

  1. Operators설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp 1
    spec:
      configuration:
        velero:
          defaultPlugins:
            - openshift 2
            - aws
          resourceTimeout: 10m 3
        nodeAgent: 4
          enable: true 5
          uploaderType: kopia 6
          podConfig:
            nodeSelector: <node_selector> 7
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket_name> 8
              prefix: <prefix> 9
            config:
              region: <region>
              profile: "default"
              s3ForcePathStyle: "true" 10
              s3Url: <s3_url> 11
            credential:
              key: cloud
              name: cloud-credentials 12
      snapshotLocations: 13
        - name: default
          velero:
            provider: aws
            config:
              region: <region> 14
              profile: "default"
            credential:
              key: cloud
              name: cloud-credentials 15
    1
    OADP의 기본 네임스페이스는 openshift-adp 입니다. 네임스페이스는 변수이며 구성 가능합니다.
    2
    openshift 플러그인은 필수입니다.
    3
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    4
    관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
    5
    nodeAgent 를 활성화하고 파일 시스템 백업을 수행하려면 이 값을 true 로 설정합니다.
    6
    업로드로 kopia 또는 restic 을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다. nodeAgent 는 데몬 세트를 배포합니다. 즉, nodeAgent Pod가 각 작동 중인 노드에서 실행됩니다. Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 파일 시스템 백업을 구성할 수 있습니다.
    7
    Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
    8
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    9
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
    10
    S3 오브젝트에 대해 경로 스타일 URL을 강제 적용할지 여부를 지정합니다(부울). AWS S3에는 필요하지 않습니다. S3 호환 스토리지에만 필요합니다.
    11
    백업을 저장하는 데 사용 중인 오브젝트 저장소의 URL을 지정합니다. AWS S3에는 필요하지 않습니다. S3 호환 스토리지에만 필요합니다.
    12
    생성한 Secret 오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본값 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
    13
    CSI 스냅샷 또는 FSB(File System Backup)를 사용하여 PV를 백업하지 않는 한 스냅샷 위치를 지정합니다.
    14
    스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.
    15
    생성한 Secret 오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본값 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 스냅샷 위치에 사용자 지정 이름이 사용됩니다. 백업 및 스냅샷 위치에서 다른 인증 정보를 사용하는 경우 credentials-velero 파일에 별도의 프로필을 생성합니다.
  4. 생성을 클릭합니다.

검증

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

    $ oc get all -n openshift-adp

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s

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

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'

    출력 예

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

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.
  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true

4.6.3.4.1. 노드 에이전트 및 노드 라벨 구성

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

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

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

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""

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

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""

다음 예제는 nodeSelector 의 안티 패턴이며 'node-role.kubernetes.io/infra: ""''node-role.kubernetes.io/worker: ""' 둘 다 노드에 있지 않으면 작동하지 않습니다.

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
            node-role.kubernetes.io/worker: ""
4.6.3.5. MD5 체크섬 알고리즘을 사용하여 백업 스토리지 위치 구성

DPA(Data Protection Application)에서 백업 스토리지 위치(BSL)를 구성하여 Amazon Simple Storage Service(Amazon S3) 및 S3 호환 스토리지 공급자 모두에 MD5 체크섬 알고리즘을 사용할 수 있습니다. 체크섬 알고리즘은 Amazon S3에 오브젝트를 업로드하고 다운로드하는 체크섬을 계산합니다. 다음 옵션 중 하나를 사용하여 DPA의 spec.backupLocations.velero.config.checksumAlgorithm 섹션에서 checksumAlgorithm 필드를 설정할 수 있습니다.

  • CRC32
  • CRC32C
  • SHA1
  • SHA256
참고

checksumAlgorithm 필드를 빈 값으로 설정하여 MD5 체크섬 검사를 건너뛸 수도 있습니다.

checksumAlgorithm 필드의 값을 설정하지 않으면 기본값은 CRC32 로 설정됩니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • Amazon S3 또는 S3 호환 오브젝트 스토리지를 백업 위치로 구성했습니다.

절차

  • 다음 예와 같이 DPA에서 BSL을 구성합니다.

    데이터 보호 애플리케이션 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - name: default
        velero:
          config:
            checksumAlgorithm: "" 1
            insecureSkipTLSVerify: "true"
            profile: "default"
            region: <bucket_region>
            s3ForcePathStyle: "true"
            s3Url: <bucket_url>
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: velero
          provider: aws
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - aws
          - csi

    1
    checksumAlgorithm 을 지정합니다. 이 예에서는 checksumAlgorithm 필드가 빈 값으로 설정됩니다. 다음 목록에서 옵션을 선택할 수 있습니다. CRC32 , CRC32 C,SHA1,SHA256.
중요

If you are using Noobaa as the object storage provider, and you do not set the spec.backupLocations.velero.config.checksumAlgorithm field in the DPA, an empty value of checksumAlgorithm is added to the BSL configuration.

빈 값은 DPA를 사용하여 생성된 BSL에만 추가됩니다. 이 값은 다른 방법을 사용하여 BSL을 생성하는 경우 추가되지 않습니다.

4.6.3.6. 클라이언트 버스트 및 QPS 설정으로 DPA 구성

버스트 설정은 제한을 적용하기 전에 velero 서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.

버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero 서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burstdpa.configuration.velero.client-qps 필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.

절차

  • 다음 예와 같이 DPA에서 client-burstclient-qps 필드를 구성합니다.

    데이터 보호 애플리케이션 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500 1
          client-qps: 300 2
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    1
    client-burst 값을 지정합니다. 이 예에서 client-burst 필드는 500으로 설정됩니다.
    2
    client-qps 값을 지정합니다. 이 예에서 client-qps 필드는 300으로 설정됩니다.
4.6.3.7. 두 개 이상의 BSL로 DPA 구성

DPA를 두 개 이상의 BSL로 구성하고 클라우드 공급자가 제공하는 자격 증명을 지정할 수 있습니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성해야 합니다.

절차

  1. 두 개 이상의 BSL로 DPA를 구성합니다. 다음 예제를 참조하십시오.

    DPA 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    #...
    backupLocations:
      - name: aws 1
        velero:
          provider: aws
          default: true 2
          objectStorage:
            bucket: <bucket_name> 3
            prefix: <prefix> 4
          config:
            region: <region_name> 5
            profile: "default"
          credential:
            key: cloud
            name: cloud-credentials 6
      - name: odf 7
        velero:
          provider: aws
          default: false
          objectStorage:
            bucket: <bucket_name>
            prefix: <prefix>
          config:
            profile: "default"
            region: <region_name>
            s3Url: <url> 8
            insecureSkipTLSVerify: "true"
            s3ForcePathStyle: "true"
          credential:
            key: cloud
            name: <custom_secret_name_odf> 9
    #...

    1
    첫 번째 BSL의 이름을 지정합니다.
    2
    이 매개 변수는 이 BSL이 기본 BSL임을 나타냅니다. Backup CR 에 BSL이 설정되지 않은 경우 기본 BSL이 사용됩니다. 하나의 BSL만 기본값으로 설정할 수 있습니다.
    3
    버킷 이름을 지정합니다.
    4
    Velero 백업의 접두사를 지정합니다(예: velero ).
    5
    버킷의 AWS 리전을 지정합니다.
    6
    생성한 기본 Secret 오브젝트의 이름을 지정합니다.
    7
    두 번째 BSL의 이름을 지정합니다.
    8
    S3 끝점의 URL을 지정합니다.
    9
    시크릿 의 올바른 이름을 지정합니다(예: custom_secret_name_odf ). Secret 이름을 지정하지 않으면 기본 이름이 사용됩니다.
  2. 백업 CR에 사용할 BSL을 지정합니다. 다음 예제를 참조하십시오.

    백업 CR의 예

    apiVersion: velero.io/v1
    kind: Backup
    # ...
    spec:
      includedNamespaces:
      - <namespace> 1
      storageLocation: <backup_storage_location> 2
      defaultVolumesToFsBackup: true

    1
    백업할 네임스페이스를 지정합니다.
    2
    스토리지 위치를 지정합니다.
4.6.3.7.1. DataProtectionApplication CR에서 CSI 활성화

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi 1
    1
    csi 기본 플러그인을 추가합니다.
4.6.3.7.2. DataProtectionApplication에서 노드 에이전트 비활성화

백업에 Restic,Kopia 또는 DataMover 를 사용하지 않는 경우 DataProtectionApplication CR(사용자 정의 리소스)에서 nodeAgent 필드를 비활성화할 수 있습니다. nodeAgent 를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.

절차

  1. nodeAgent 를 비활성화하려면 enable 플래그를 false 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: false  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 비활성화합니다.
  2. nodeAgent 를 활성화하려면 enable 플래그를 true 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: true  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 활성화합니다.

DataProtectionApplication CR에서 nodeAgent 필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.

4.6.4. IBM Cloud를 사용하여 OpenShift API for Data Protection 구성

IBM Cloud 클러스터에 OpenShift API for Data Protection(OADP) Operator를 설치하여 클러스터에서 애플리케이션을 백업 및 복원합니다. 백업을 저장하도록 IBM Cloud Object Storage(COS)를 구성합니다.

4.6.4.1. COS 인스턴스 구성

OADP 백업 데이터를 저장하기 위해 IBM COS(Cloud Object Storage) 인스턴스를 생성합니다. COS 인스턴스를 생성한 후 HMAC 서비스 자격 증명을 구성합니다.

사전 요구 사항

  • IBM Cloud Platform 계정이 있습니다.
  • IBM Cloud CLI 를 설치했습니다.
  • IBM Cloud에 로그인되어 있습니다.

절차

  1. 다음 명령을 실행하여 IBM Cloud Object Storage(COS) 플러그인을 설치합니다.

    $ ibmcloud plugin install cos -f
  2. 다음 명령을 실행하여 버킷 이름을 설정합니다.

    $ BUCKET=<bucket_name>
  3. 다음 명령을 실행하여 버킷 리전을 설정합니다.

    $ REGION=<bucket_region> 1
    1
    버킷 리전을 지정합니다(예: eu-gb ).
  4. 다음 명령을 실행하여 리소스 그룹을 생성합니다.

    $ ibmcloud resource group-create <resource_group_name>
  5. 다음 명령을 실행하여 대상 리소스 그룹을 설정합니다.

    $ ibmcloud target -g <resource_group_name>
  6. 다음 명령을 실행하여 대상 리소스 그룹이 올바르게 설정되었는지 확인합니다.

    $ ibmcloud target

    출력 예

    API endpoint:     https://cloud.ibm.com
    Region:
    User:             test-user
    Account:          Test Account (fb6......e95) <-> 2...122
    Resource group:   Default

    예제 출력에서 리소스 그룹은 Default 로 설정됩니다.

  7. 다음 명령을 실행하여 리소스 그룹 이름을 설정합니다.

    $ RESOURCE_GROUP=<resource_group> 1
    1
    리소스 그룹 이름을 지정합니다(예: "default" ).
  8. 다음 명령을 실행하여 IBM Cloud service-instance 리소스를 생성합니다.

    $ ibmcloud resource service-instance-create \
    <service_instance_name> \1
    <service_name> \2
    <service_plan> \3
    <region_name> 4
    1
    service-instance 리소스의 이름을 지정합니다.
    2
    서비스 이름을 지정합니다. 또는 서비스 ID를 지정할 수 있습니다.
    3
    IBM Cloud 계정의 서비스 계획을 지정합니다.
    4
    지역 이름을 지정합니다.

    명령 예

    $ ibmcloud resource service-instance-create test-service-instance cloud-object-storage \ 1
    standard \
    global \
    -d premium-global-deployment 2

    1
    서비스 이름은 cloud-object-storage 입니다.
    2
    -d 플래그는 배포 이름을 지정합니다.
  9. 다음 명령을 실행하여 서비스 인스턴스 ID를 추출합니다.

    $ SERVICE_INSTANCE_ID=$(ibmcloud resource service-instance test-service-instance --output json | jq -r '.[0].id')
  10. 다음 명령을 실행하여 COS 버킷을 생성합니다.

    $ ibmcloud cos bucket-create \//
    --bucket $BUCKET \//
    --ibm-service-instance-id $SERVICE_INSTANCE_ID \//
    --region $REGION

    $BUCKET,$SERVICE_INSTANCE_ID$REGION 과 같은 변수는 이전에 설정한 값으로 교체됩니다.

  11. 다음 명령을 실행하여 HMAC 자격 증명을 만듭니다.

    $ ibmcloud resource service-key-create test-key Writer --instance-name test-service-instance --parameters {\"HMAC\":true}
  12. HMAC 인증 정보에서 액세스 키 ID와 시크릿 액세스 키를 추출하여 credentials-velero 파일에 저장합니다. credentials-velero 파일을 사용하여 백업 스토리지 위치에 대한 시크릿을 생성할 수 있습니다. 다음 명령을 실행합니다.

    $ cat > credentials-velero << __EOF__
    [default]
    aws_access_key_id=$(ibmcloud resource service-key test-key -o json  | jq -r '.[0].credentials.cos_hmac_keys.access_key_id')
    aws_secret_access_key=$(ibmcloud resource service-key test-key -o json  | jq -r '.[0].credentials.cos_hmac_keys.secret_access_key')
    __EOF__
4.6.4.2. 기본 보안 생성

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

참고

DataProtectionApplication 사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret 이 지정되지 않은 경우 기본 이름이 사용됩니다.

설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 이름으로 Secret 을 생성할 수 있습니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
  • Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

절차

  • 기본 이름으로 보안을 생성합니다.

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

Data Protection Application을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 Secret 을 참조합니다.

4.6.4.3. 다른 인증 정보의 보안 생성

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

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

절차

  1. 클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한 credentials-velero 파일을 생성합니다.
  2. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
  3. 오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.
  4. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
  5. 다음 예제와 같이 사용자 지정 이름으로 SecretDataProtectionApplication CR에 추가합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            provider: <provider>
            default: true
            credential:
              key: cloud
              name: <custom_secret> 1
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
    1
    사용자 지정 이름으로 백업 위치 보안.
4.6.4.4. 데이터 보호 애플리케이션 설치

DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application )를 설치합니다.

사전 요구 사항

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

    참고

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

절차

  1. Operators설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      namespace: openshift-adp
      name: <dpa_name>
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - aws
          - csi
      backupLocations:
        - velero:
            provider: aws 1
            default: true
            objectStorage:
              bucket: <bucket_name> 2
              prefix: velero
            config:
              insecureSkipTLSVerify: 'true'
              profile: default
              region: <region_name> 3
              s3ForcePathStyle: 'true'
              s3Url: <s3_url> 4
            credential:
              key: cloud
              name: cloud-credentials 5
    1
    IBM Cloud를 백업 스토리지 위치로 사용하는 경우 공급자가 aws 입니다.
    2
    IBM Cloud Object Storage(COS) 버킷 이름을 지정합니다.
    3
    COS 리전 이름을 지정합니다(예: eu-gb ).
    4
    COS 버킷의 S3 URL을 지정합니다. 예: http://s3.eu-gb.cloud-object-storage.appdomain.cloud. 여기서 eu-gb 는 지역 이름입니다. 버킷 리전에 따라 지역 이름을 바꿉니다.
    5
    액세스 키와 HMAC 인증 정보의 시크릿 액세스 키를 사용하여 생성한 시크릿의 이름을 정의합니다.
  4. 생성을 클릭합니다.

검증

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

    $ oc get all -n openshift-adp

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s

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

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'

    출력 예

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

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.
  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true

4.6.4.5. Velero CPU 및 메모리 리소스 할당 설정

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector> 1
            resourceAllocations: 2
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.
참고

Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.

Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.

4.6.4.6. 노드 에이전트 및 노드 라벨 구성

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

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

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

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""

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

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""

다음 예제는 nodeSelector 의 안티 패턴이며 'node-role.kubernetes.io/infra: ""''node-role.kubernetes.io/worker: ""' 둘 다 노드에 있지 않으면 작동하지 않습니다.

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
            node-role.kubernetes.io/worker: ""
4.6.4.7. 클라이언트 버스트 및 QPS 설정으로 DPA 구성

버스트 설정은 제한을 적용하기 전에 velero 서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.

버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero 서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burstdpa.configuration.velero.client-qps 필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.

절차

  • 다음 예와 같이 DPA에서 client-burstclient-qps 필드를 구성합니다.

    데이터 보호 애플리케이션 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500 1
          client-qps: 300 2
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    1
    client-burst 값을 지정합니다. 이 예에서 client-burst 필드는 500으로 설정됩니다.
    2
    client-qps 값을 지정합니다. 이 예에서 client-qps 필드는 300으로 설정됩니다.
4.6.4.8. 두 개 이상의 BSL로 DPA 구성

DPA를 두 개 이상의 BSL로 구성하고 클라우드 공급자가 제공하는 자격 증명을 지정할 수 있습니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성해야 합니다.

절차

  1. 두 개 이상의 BSL로 DPA를 구성합니다. 다음 예제를 참조하십시오.

    DPA 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    #...
    backupLocations:
      - name: aws 1
        velero:
          provider: aws
          default: true 2
          objectStorage:
            bucket: <bucket_name> 3
            prefix: <prefix> 4
          config:
            region: <region_name> 5
            profile: "default"
          credential:
            key: cloud
            name: cloud-credentials 6
      - name: odf 7
        velero:
          provider: aws
          default: false
          objectStorage:
            bucket: <bucket_name>
            prefix: <prefix>
          config:
            profile: "default"
            region: <region_name>
            s3Url: <url> 8
            insecureSkipTLSVerify: "true"
            s3ForcePathStyle: "true"
          credential:
            key: cloud
            name: <custom_secret_name_odf> 9
    #...

    1
    첫 번째 BSL의 이름을 지정합니다.
    2
    이 매개 변수는 이 BSL이 기본 BSL임을 나타냅니다. Backup CR 에 BSL이 설정되지 않은 경우 기본 BSL이 사용됩니다. 하나의 BSL만 기본값으로 설정할 수 있습니다.
    3
    버킷 이름을 지정합니다.
    4
    Velero 백업의 접두사를 지정합니다(예: velero ).
    5
    버킷의 AWS 리전을 지정합니다.
    6
    생성한 기본 Secret 오브젝트의 이름을 지정합니다.
    7
    두 번째 BSL의 이름을 지정합니다.
    8
    S3 끝점의 URL을 지정합니다.
    9
    시크릿 의 올바른 이름을 지정합니다(예: custom_secret_name_odf ). Secret 이름을 지정하지 않으면 기본 이름이 사용됩니다.
  2. 백업 CR에 사용할 BSL을 지정합니다. 다음 예제를 참조하십시오.

    백업 CR의 예

    apiVersion: velero.io/v1
    kind: Backup
    # ...
    spec:
      includedNamespaces:
      - <namespace> 1
      storageLocation: <backup_storage_location> 2
      defaultVolumesToFsBackup: true

    1
    백업할 네임스페이스를 지정합니다.
    2
    스토리지 위치를 지정합니다.
4.6.4.9. DataProtectionApplication에서 노드 에이전트 비활성화

백업에 Restic,Kopia 또는 DataMover 를 사용하지 않는 경우 DataProtectionApplication CR(사용자 정의 리소스)에서 nodeAgent 필드를 비활성화할 수 있습니다. nodeAgent 를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.

절차

  1. nodeAgent 를 비활성화하려면 enable 플래그를 false 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: false  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 비활성화합니다.
  2. nodeAgent 를 활성화하려면 enable 플래그를 true 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: true  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 활성화합니다.

DataProtectionApplication CR에서 nodeAgent 필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.

4.6.5. Microsoft Azure를 사용하여 데이터 보호를 위한 OpenShift API 구성

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

참고

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

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

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

4.6.5.1. Microsoft Azure 구성

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

사전 요구 사항

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

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

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

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

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

4.6.5.2. 백업 및 스냅샷 위치 및 시크릿 정보

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

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.

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

스냅샷 위치

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

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

FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

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

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

  • 백업 위치에 대한 사용자 지정 보안( DataProtectionApplication CR에서 지정)
  • DataProtectionApplication CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
중요

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

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

4.6.5.2.1. 기본 보안 생성

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

Secret 의 기본 이름은 cloud-credentials-azure 입니다.

참고

DataProtectionApplication 사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret 이 지정되지 않은 경우 기본 이름이 사용됩니다.

설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 이름으로 Secret 을 생성할 수 있습니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
  • Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

절차

  • 기본 이름으로 보안을 생성합니다.

    $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero

Data Protection Application을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 Secret 을 참조합니다.

4.6.5.2.2. 다른 인증 정보의 보안 생성

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

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

절차

  1. 클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한 credentials-velero 파일을 생성합니다.
  2. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.

    $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
  3. 오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.
  4. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
  5. 다음 예제와 같이 사용자 지정 이름으로 SecretDataProtectionApplication CR에 추가합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            config:
              resourceGroup: <azure_resource_group>
              storageAccount: <azure_storage_account_id>
              subscriptionId: <azure_subscription_id>
              storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
            credential:
              key: cloud
              name: <custom_secret> 1
            provider: azure
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
      snapshotLocations:
        - velero:
            config:
              resourceGroup: <azure_resource_group>
              subscriptionId: <azure_subscription_id>
              incremental: "true"
            provider: azure
    1
    사용자 지정 이름으로 백업 위치 보안.
4.6.5.3. 데이터 보호 애플리케이션 구성

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

4.6.5.3.1. Velero CPU 및 메모리 리소스 할당 설정

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector> 1
            resourceAllocations: 2
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.
참고

Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.

Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.

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

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

4.6.5.3.2. 자체 서명된 CA 인증서 활성화

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.velero.objectStorage.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string> 1
            config:
              insecureSkipTLSVerify: "false" 2
    ...
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.6.5.3.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용

별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

    1. aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.

      $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
    2. 다음 명령을 실행하여 별칭이 작동하는지 확인합니다.

      예제

      $ velero version
      Client:
      	Version: v1.12.1-OADP
      	Git commit: -
      Server:
      	Version: v1.12.1-OADP

    3. 이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.

      $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
      
      $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
      $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
    4. 백업 로그를 가져오려면 다음 명령을 실행합니다.

      $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

      이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.

    5. Velero 포드가 다시 시작되면 /tmp/your-cacert.txt 파일이 사라지고 이전 단계의 명령을 다시 실행하여 /tmp/your-cacert.txt 파일을 다시 생성해야 합니다.
    6. 다음 명령을 실행하여 /tmp/your-cacert.txt 파일이 여전히 있는지 확인할 수 있습니다.

      $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
      /tmp/your-cacert.txt

향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.

4.6.5.4. 데이터 보호 애플리케이션 설치

DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application )를 설치합니다.

사전 요구 사항

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

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

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

절차

  1. Operators설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp 1
    spec:
      configuration:
        velero:
          defaultPlugins:
            - azure
            - openshift 2
          resourceTimeout: 10m 3
        nodeAgent: 4
          enable: true 5
          uploaderType: kopia 6
          podConfig:
            nodeSelector: <node_selector> 7
      backupLocations:
        - velero:
            config:
              resourceGroup: <azure_resource_group> 8
              storageAccount: <azure_storage_account_id> 9
              subscriptionId: <azure_subscription_id> 10
              storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
            credential:
              key: cloud
              name: cloud-credentials-azure  11
            provider: azure
            default: true
            objectStorage:
              bucket: <bucket_name> 12
              prefix: <prefix> 13
      snapshotLocations: 14
        - velero:
            config:
              resourceGroup: <azure_resource_group>
              subscriptionId: <azure_subscription_id>
              incremental: "true"
            name: default
            provider: azure
            credential:
              key: cloud
              name: cloud-credentials-azure 15
    1
    OADP의 기본 네임스페이스는 openshift-adp 입니다. 네임스페이스는 변수이며 구성 가능합니다.
    2
    openshift 플러그인은 필수입니다.
    3
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    4
    관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
    5
    nodeAgent 를 활성화하고 파일 시스템 백업을 수행하려면 이 값을 true 로 설정합니다.
    6
    업로드로 kopia 또는 restic 을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다. nodeAgent 는 데몬 세트를 배포합니다. 즉, nodeAgent Pod가 각 작동 중인 노드에서 실행됩니다. Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 파일 시스템 백업을 구성할 수 있습니다.
    7
    Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
    8
    Azure 리소스 그룹을 지정합니다.
    9
    Azure 스토리지 계정 ID를 지정합니다.
    10
    Azure 서브스크립션 ID를 지정합니다.
    11
    이 값을 지정하지 않으면 기본값 cloud-credentials-azure 이 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
    12
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    13
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
    14
    CSI 스냅샷 또는 Restic을 사용하여 PV를 백업하는 경우 스냅샷 위치를 지정할 필요가 없습니다.
    15
    생성한 Secret 오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본 이름, cloud-credentials-azure 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
  4. 생성을 클릭합니다.

검증

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

    $ oc get all -n openshift-adp

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s

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

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'

    출력 예

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

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.
  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true

4.6.5.5. 클라이언트 버스트 및 QPS 설정으로 DPA 구성

버스트 설정은 제한을 적용하기 전에 velero 서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.

버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero 서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burstdpa.configuration.velero.client-qps 필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.

절차

  • 다음 예와 같이 DPA에서 client-burstclient-qps 필드를 구성합니다.

    데이터 보호 애플리케이션 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500 1
          client-qps: 300 2
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    1
    client-burst 값을 지정합니다. 이 예에서 client-burst 필드는 500으로 설정됩니다.
    2
    client-qps 값을 지정합니다. 이 예에서 client-qps 필드는 300으로 설정됩니다.
4.6.5.5.1. 노드 에이전트 및 노드 라벨 구성

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

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

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

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""

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

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""

다음 예제는 nodeSelector 의 안티 패턴이며 'node-role.kubernetes.io/infra: ""''node-role.kubernetes.io/worker: ""' 둘 다 노드에 있지 않으면 작동하지 않습니다.

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
            node-role.kubernetes.io/worker: ""
4.6.5.5.2. DataProtectionApplication CR에서 CSI 활성화

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi 1
    1
    csi 기본 플러그인을 추가합니다.
4.6.5.5.3. DataProtectionApplication에서 노드 에이전트 비활성화

백업에 Restic,Kopia 또는 DataMover 를 사용하지 않는 경우 DataProtectionApplication CR(사용자 정의 리소스)에서 nodeAgent 필드를 비활성화할 수 있습니다. nodeAgent 를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.

절차

  1. nodeAgent 를 비활성화하려면 enable 플래그를 false 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: false  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 비활성화합니다.
  2. nodeAgent 를 활성화하려면 enable 플래그를 true 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: true  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 활성화합니다.

DataProtectionApplication CR에서 nodeAgent 필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.

4.6.6. Google Cloud Platform을 사용하여 데이터 보호를 위한 OpenShift API 구성

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

참고

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

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

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

4.6.6.1. GCP(Google Cloud Platform) 구성

OADP(Data Protection)를 OpenShift API용으로 GCP(Google Cloud Platform)를 구성합니다.

사전 요구 사항

절차

  1. GCP에 로그인합니다.

    $ gcloud auth login
  2. BUCKET 변수를 설정합니다.

    $ BUCKET=<bucket> 1
    1
    버킷 이름을 지정합니다.
  3. 스토리지 버킷을 생성합니다.

    $ gsutil mb gs://$BUCKET/
  4. PROJECT_ID 변수를 활성 프로젝트로 설정합니다.

    $ PROJECT_ID=$(gcloud config get-value project)
  5. 서비스 계정을 생성합니다.

    $ gcloud iam service-accounts create velero \
        --display-name "Velero service account"
  6. 서비스 계정을 나열합니다.

    $ gcloud iam service-accounts list
  7. email 값과 일치하도록 SERVICE_ACCOUNT_EMAIL 변수를 설정합니다.

    $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
        --filter="displayName:Velero service account" \
        --format 'value(email)')
  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
    )
  9. velero.server 사용자 정의 역할을 생성합니다.

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  10. 프로젝트에 IAM 정책 바인딩을 추가합니다.

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  11. IAM 서비스 계정을 업데이트합니다.

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  12. IAM 서비스 계정 키를 현재 디렉터리의 credentials-velero 파일에 저장합니다.

    $ gcloud iam service-accounts keys create credentials-velero \
        --iam-account $SERVICE_ACCOUNT_EMAIL

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

4.6.6.2. 백업 및 스냅샷 위치 및 시크릿 정보

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

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.

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

스냅샷 위치

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

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

FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

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

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

  • 백업 위치에 대한 사용자 지정 보안( DataProtectionApplication CR에서 지정)
  • DataProtectionApplication CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
중요

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

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

4.6.6.2.1. 기본 보안 생성

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

Secret 의 기본 이름은 cloud-credentials-gcp 입니다.

참고

DataProtectionApplication 사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret 이 지정되지 않은 경우 기본 이름이 사용됩니다.

설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 이름으로 Secret 을 생성할 수 있습니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
  • Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

절차

  • 기본 이름으로 보안을 생성합니다.

    $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero

Data Protection Application을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 Secret 을 참조합니다.

4.6.6.2.2. 다른 인증 정보의 보안 생성

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

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

절차

  1. 클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한 credentials-velero 파일을 생성합니다.
  2. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.

    $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
  3. 오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.
  4. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
  5. 다음 예제와 같이 사용자 지정 이름으로 SecretDataProtectionApplication CR에 추가합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            provider: gcp
            default: true
            credential:
              key: cloud
              name: <custom_secret> 1
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
      snapshotLocations:
        - velero:
            provider: gcp
            default: true
            config:
              project: <project>
              snapshotLocation: us-west1
    1
    사용자 지정 이름으로 백업 위치 보안.
4.6.6.3. 데이터 보호 애플리케이션 구성

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

4.6.6.3.1. Velero CPU 및 메모리 리소스 할당 설정

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector> 1
            resourceAllocations: 2
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.
참고

Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.

Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.

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

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

4.6.6.3.2. 자체 서명된 CA 인증서 활성화

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.velero.objectStorage.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string> 1
            config:
              insecureSkipTLSVerify: "false" 2
    ...
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.6.6.3.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용

별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

    1. aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.

      $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
    2. 다음 명령을 실행하여 별칭이 작동하는지 확인합니다.

      예제

      $ velero version
      Client:
      	Version: v1.12.1-OADP
      	Git commit: -
      Server:
      	Version: v1.12.1-OADP

    3. 이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.

      $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
      
      $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
      $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
    4. 백업 로그를 가져오려면 다음 명령을 실행합니다.

      $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

      이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.

    5. Velero 포드가 다시 시작되면 /tmp/your-cacert.txt 파일이 사라지고 이전 단계의 명령을 다시 실행하여 /tmp/your-cacert.txt 파일을 다시 생성해야 합니다.
    6. 다음 명령을 실행하여 /tmp/your-cacert.txt 파일이 여전히 있는지 확인할 수 있습니다.

      $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
      /tmp/your-cacert.txt

향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.

4.6.6.4. Google 워크로드 ID 페더레이션 클라우드 인증

Google Cloud 외부에서 실행되는 애플리케이션은 사용자 이름 및 암호와 같은 서비스 계정 키를 사용하여 Google Cloud 리소스에 액세스할 수 있습니다. 이러한 서비스 계정 키는 올바르게 관리되지 않는 경우 보안 위험이 될 수 있습니다.

Google의 워크로드 ID 페더레이션을 사용하면 IAM(Identity and Access Management)을 사용하여 서비스 계정을 가장하는 기능을 포함하여 외부 ID IAM 역할을 제공할 수 있습니다. 이렇게 하면 서비스 계정 키와 관련된 유지 관리 및 보안 위험이 제거됩니다.

워크로드 ID 페더레이션은 인증서 암호화 및 암호 해독, 사용자 속성 추출 및 검증을 처리합니다. ID 페더레이션은 인증을 외부화하고 STS(Security Token Services)에 전달하여 개별 개발자의 요구 사항을 줄입니다. 리소스에 대한 액세스 권한 부여 및 제어는 애플리케이션의 책임이 그대로 유지됩니다.

볼륨을 백업할 때 Google 워크로드 ID 페더레이션 인증을 사용하여 GCP의 OADP는 CSI 스냅샷만 지원합니다.

Google 워크로드 ID 페더레이션 인증을 사용하는 GCP의 OADP는 VSL(volume Snapshot Locations) 백업을 지원하지 않습니다. 자세한 내용은 Google 워크로드 ID 페더레이션의 알려진 문제를 참조하십시오.

Google 워크로드 ID 페더레이션 클라우드 인증을 사용하지 않는 경우 데이터 보호 애플리케이션 설치를 계속합니다.

사전 요구 사항

  • GCP 워크로드 ID가 구성되어 있는 수동 모드로 클러스터를 설치했습니다.
  • Cloud Credential Operator 유틸리티(ccoctl) 및 관련 워크로드 ID 풀에 액세스할 수 있습니다.

절차

  1. 다음 명령을 실행하여 oadp-credrequest 디렉터리를 생성합니다.

    $ mkdir -p oadp-credrequest
  2. 다음과 같이 CredentialsRequest.yaml 파일을 생성합니다.

    echo 'apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: oadp-operator-credentials
      namespace: openshift-cloud-credential-operator
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: GCPProviderSpec
        permissions:
        - compute.disks.get
        - compute.disks.create
        - compute.disks.createSnapshot
        - compute.snapshots.get
        - compute.snapshots.create
        - compute.snapshots.useReadOnly
        - compute.snapshots.delete
        - compute.zones.get
        - storage.objects.create
        - storage.objects.delete
        - storage.objects.get
        - storage.objects.list
        - iam.serviceAccounts.signBlob
        skipServiceCheck: true
      secretRef:
        name: cloud-credentials-gcp
        namespace: <OPERATOR_INSTALL_NS>
      serviceAccountNames:
      - velero
    ' > oadp-credrequest/credrequest.yaml
  3. 다음 명령을 실행하여 ccoctl 유틸리티를 사용하여 oadp-credrequest 디렉터리에서 CredentialsRequest 오브젝트를 처리합니다.

    $ ccoctl gcp create-service-accounts \
        --name=<name> \
        --project=<gcp_project_id> \
        --credentials-requests-dir=oadp-credrequest \
        --workload-identity-pool=<pool_id> \
        --workload-identity-provider=<provider_id>

    다음 단계에서 manifests/openshift-adp-cloud-credentials-gcp-credentials.yaml 파일을 사용할 수 있습니다.

  4. 다음 명령을 실행하여 네임스페이스를 생성합니다.

    $ oc create namespace <OPERATOR_INSTALL_NS>
  5. 다음 명령을 실행하여 네임스페이스에 인증 정보를 적용합니다.

    $ oc apply -f manifests/openshift-adp-cloud-credentials-gcp-credentials.yaml
4.6.6.4.1. Google 워크로드 ID 페더레이션 알려진 문제
  • GCP 워크로드 ID 페더레이션이 구성된 경우 VSL(volume Snapshot Location) 백업은 부분적으로Failed 단계로 완료됩니다. Google 워크로드 ID 페더레이션 인증은 VSL 백업을 지원하지 않습니다.
4.6.6.5. 데이터 보호 애플리케이션 설치

DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application )를 설치합니다.

사전 요구 사항

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

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

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

절차

  1. Operators설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: <OPERATOR_INSTALL_NS> 1
    spec:
      configuration:
        velero:
          defaultPlugins:
            - gcp
            - openshift 2
          resourceTimeout: 10m 3
        nodeAgent: 4
          enable: true 5
          uploaderType: kopia 6
          podConfig:
            nodeSelector: <node_selector> 7
      backupLocations:
        - velero:
            provider: gcp
            default: true
            credential:
              key: cloud 8
              name: cloud-credentials-gcp 9
            objectStorage:
              bucket: <bucket_name> 10
              prefix: <prefix> 11
      snapshotLocations: 12
        - velero:
            provider: gcp
            default: true
            config:
              project: <project>
              snapshotLocation: us-west1 13
            credential:
              key: cloud
              name: cloud-credentials-gcp 14
      backupImages: true 15
    1
    OADP의 기본 네임스페이스는 openshift-adp 입니다. 네임스페이스는 변수이며 구성 가능합니다.
    2
    openshift 플러그인은 필수입니다.
    3
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    4
    관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
    5
    nodeAgent 를 활성화하고 파일 시스템 백업을 수행하려면 이 값을 true 로 설정합니다.
    6
    업로드로 kopia 또는 restic 을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다. nodeAgent 는 데몬 세트를 배포합니다. 즉, nodeAgent Pod가 각 작동 중인 노드에서 실행됩니다. Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 파일 시스템 백업을 구성할 수 있습니다.
    7
    Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
    8
    인증 정보가 포함된 시크릿 키입니다. Google 워크로드 ID 페더레이션 클라우드 인증의 경우 service_account.json 을 사용합니다.
    9
    인증 정보가 포함된 시크릿 이름입니다. 이 값을 지정하지 않으면 기본값 cloud-credentials-gcp 가 사용됩니다.
    10
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    11
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
    12
    CSI 스냅샷 또는 Restic을 사용하여 PV를 백업하지 않는 한 스냅샷 위치를 지정합니다.
    13
    스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.
    14
    생성한 Secret 오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본 이름, cloud-credentials-gcp 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
    15
    Google 워크로드 ID 페더레이션은 내부 이미지 백업을 지원합니다. 이미지 백업을 사용하지 않으려면 이 필드를 false 로 설정합니다.
  4. 생성을 클릭합니다.

검증

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

    $ oc get all -n openshift-adp

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s

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

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'

    출력 예

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

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.
  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true

4.6.6.6. 클라이언트 버스트 및 QPS 설정으로 DPA 구성

버스트 설정은 제한을 적용하기 전에 velero 서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.

버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero 서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burstdpa.configuration.velero.client-qps 필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.

절차

  • 다음 예와 같이 DPA에서 client-burstclient-qps 필드를 구성합니다.

    데이터 보호 애플리케이션 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500 1
          client-qps: 300 2
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    1
    client-burst 값을 지정합니다. 이 예에서 client-burst 필드는 500으로 설정됩니다.
    2
    client-qps 값을 지정합니다. 이 예에서 client-qps 필드는 300으로 설정됩니다.
4.6.6.6.1. 노드 에이전트 및 노드 라벨 구성

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

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

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

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""

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

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""

다음 예제는 nodeSelector 의 안티 패턴이며 'node-role.kubernetes.io/infra: ""''node-role.kubernetes.io/worker: ""' 둘 다 노드에 있지 않으면 작동하지 않습니다.

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
            node-role.kubernetes.io/worker: ""
4.6.6.6.2. DataProtectionApplication CR에서 CSI 활성화

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi 1
    1
    csi 기본 플러그인을 추가합니다.
4.6.6.6.3. DataProtectionApplication에서 노드 에이전트 비활성화

백업에 Restic,Kopia 또는 DataMover 를 사용하지 않는 경우 DataProtectionApplication CR(사용자 정의 리소스)에서 nodeAgent 필드를 비활성화할 수 있습니다. nodeAgent 를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.

절차

  1. nodeAgent 를 비활성화하려면 enable 플래그를 false 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: false  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 비활성화합니다.
  2. nodeAgent 를 활성화하려면 enable 플래그를 true 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: true  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 활성화합니다.

DataProtectionApplication CR에서 nodeAgent 필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.

4.6.7. Multicloud Object Gateway를 사용하여 데이터 보호를 위한 OpenShift API 구성

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

참고

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

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

중요

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

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

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

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

4.6.7.1. 멀티 클라우드 오브젝트 게이트웨이 인증 정보 검색

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

참고

MCG Operator는 더 이상 사용되지 않지만 OpenShift Data Foundation에서 MCG 플러그인을 계속 사용할 수 있습니다. 플러그인을 다운로드하려면 Red Hat OpenShift Data Foundation 을 다운로드하여 운영 체제에 적합한 MCG 플러그인을 다운로드합니다.

절차

  1. NooBaa 사용자 정의 리소스에서 describe 명령을 실행하여 S3 엔드포인트 AWS_ACCESS_KEY_IDAWS_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

    Data Protection Application을 설치할 때 credentials-velero 파일을 사용하여 Secret 오브젝트를 생성합니다.

4.6.7.2. 백업 및 스냅샷 위치 및 시크릿 정보

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

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.

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

스냅샷 위치

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

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

FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

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

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

  • 백업 위치에 대한 사용자 지정 보안( DataProtectionApplication CR에서 지정)
  • DataProtectionApplication CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
중요

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

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

4.6.7.2.1. 기본 보안 생성

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

Secret 의 기본 이름은 cloud-credentials 입니다.

참고

DataProtectionApplication 사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret 이 지정되지 않은 경우 기본 이름이 사용됩니다.

설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 이름으로 Secret 을 생성할 수 있습니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
  • Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

절차

  • 기본 이름으로 보안을 생성합니다.

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

Data Protection Application을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 Secret 을 참조합니다.

4.6.7.2.2. 다른 인증 정보의 보안 생성

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

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

절차

  1. 클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한 credentials-velero 파일을 생성합니다.
  2. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
  3. 오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.
  4. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
  5. 다음 예제와 같이 사용자 지정 이름으로 SecretDataProtectionApplication CR에 추가합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: <region_name> 1
              s3Url: <url>
              insecureSkipTLSVerify: "true"
              s3ForcePathStyle: "true"
            provider: aws
            default: true
            credential:
              key: cloud
              name:  <custom_secret> 2
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
    1
    오브젝트 스토리지 서버 설명서의 이름 지정 규칙에 따라 리전을 지정합니다.
    2
    사용자 지정 이름으로 백업 위치 보안.
4.6.7.3. 데이터 보호 애플리케이션 구성

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

4.6.7.3.1. Velero CPU 및 메모리 리소스 할당 설정

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector> 1
            resourceAllocations: 2
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.
참고

Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.

Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.

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

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

4.6.7.3.2. 자체 서명된 CA 인증서 활성화

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.velero.objectStorage.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string> 1
            config:
              insecureSkipTLSVerify: "false" 2
    ...
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.6.7.3.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용

별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

    1. aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.

      $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
    2. 다음 명령을 실행하여 별칭이 작동하는지 확인합니다.

      예제

      $ velero version
      Client:
      	Version: v1.12.1-OADP
      	Git commit: -
      Server:
      	Version: v1.12.1-OADP

    3. 이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.

      $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
      
      $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
      $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
    4. 백업 로그를 가져오려면 다음 명령을 실행합니다.

      $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

      이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.

    5. Velero 포드가 다시 시작되면 /tmp/your-cacert.txt 파일이 사라지고 이전 단계의 명령을 다시 실행하여 /tmp/your-cacert.txt 파일을 다시 생성해야 합니다.
    6. 다음 명령을 실행하여 /tmp/your-cacert.txt 파일이 여전히 있는지 확인할 수 있습니다.

      $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
      /tmp/your-cacert.txt

향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.

4.6.7.4. 데이터 보호 애플리케이션 설치

DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application )를 설치합니다.

사전 요구 사항

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

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

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

절차

  1. Operators설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp 1
    spec:
      configuration:
        velero:
          defaultPlugins:
            - aws 2
            - openshift 3
          resourceTimeout: 10m 4
        nodeAgent: 5
          enable: true 6
          uploaderType: kopia 7
          podConfig:
            nodeSelector: <node_selector> 8
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: <region_name> 9
              s3Url: <url> 10
              insecureSkipTLSVerify: "true"
              s3ForcePathStyle: "true"
            provider: aws
            default: true
            credential:
              key: cloud
              name: cloud-credentials 11
            objectStorage:
              bucket: <bucket_name> 12
              prefix: <prefix> 13
    1
    OADP의 기본 네임스페이스는 openshift-adp 입니다. 네임스페이스는 변수이며 구성 가능합니다.
    2
    스토리지 위치에 해당하는 오브젝트 저장소 플러그인이 필요합니다. 모든 S3 공급자의 경우 필요한 플러그인은 aws 입니다. Azure 및 GCP 오브젝트 저장소의 경우 azure 또는 gcp 플러그인이 필요합니다.
    3
    openshift 플러그인은 필수입니다.
    4
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    5
    관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
    6
    nodeAgent 를 활성화하고 파일 시스템 백업을 수행하려면 이 값을 true 로 설정합니다.
    7
    업로드로 kopia 또는 restic 을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다. nodeAgent 는 데몬 세트를 배포합니다. 즉, nodeAgent Pod가 각 작동 중인 노드에서 실행됩니다. Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 파일 시스템 백업을 구성할 수 있습니다.
    8
    Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
    9
    오브젝트 스토리지 서버 설명서의 이름 지정 규칙에 따라 리전을 지정합니다.
    10
    S3 끝점의 URL을 지정합니다.
    11
    생성한 Secret 오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본값 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 지정 이름이 사용됩니다.
    12
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    13
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
  4. 생성을 클릭합니다.

검증

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

    $ oc get all -n openshift-adp

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s

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

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'

    출력 예

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

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.
  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true

4.6.7.5. 클라이언트 버스트 및 QPS 설정으로 DPA 구성

버스트 설정은 제한을 적용하기 전에 velero 서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.

버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero 서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burstdpa.configuration.velero.client-qps 필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.

절차

  • 다음 예와 같이 DPA에서 client-burstclient-qps 필드를 구성합니다.

    데이터 보호 애플리케이션 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500 1
          client-qps: 300 2
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    1
    client-burst 값을 지정합니다. 이 예에서 client-burst 필드는 500으로 설정됩니다.
    2
    client-qps 값을 지정합니다. 이 예에서 client-qps 필드는 300으로 설정됩니다.
4.6.7.5.1. 노드 에이전트 및 노드 라벨 구성

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

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

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

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""

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

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""

다음 예제는 nodeSelector 의 안티 패턴이며 'node-role.kubernetes.io/infra: ""''node-role.kubernetes.io/worker: ""' 둘 다 노드에 있지 않으면 작동하지 않습니다.

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
            node-role.kubernetes.io/worker: ""
4.6.7.5.2. DataProtectionApplication CR에서 CSI 활성화

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi 1
    1
    csi 기본 플러그인을 추가합니다.
4.6.7.5.3. DataProtectionApplication에서 노드 에이전트 비활성화

백업에 Restic,Kopia 또는 DataMover 를 사용하지 않는 경우 DataProtectionApplication CR(사용자 정의 리소스)에서 nodeAgent 필드를 비활성화할 수 있습니다. nodeAgent 를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.

절차

  1. nodeAgent 를 비활성화하려면 enable 플래그를 false 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: false  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 비활성화합니다.
  2. nodeAgent 를 활성화하려면 enable 플래그를 true 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: true  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 활성화합니다.

DataProtectionApplication CR에서 nodeAgent 필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.

4.6.8. OpenShift Data Foundation으로 데이터 보호를 위한 OpenShift API 구성

OADP Operator를 설치하고 백업 위치와 스냅샷 위치를 구성하여 OpenShift Data Foundation을 사용하여 OADP(OpenShift API for Data Protection)를 설치합니다. 그런 다음 Data Protection Application을 설치합니다.

참고

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

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

중요

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

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

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

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

4.6.8.1. 백업 및 스냅샷 위치 및 시크릿 정보

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

백업 위치

AWS S3 호환 오브젝트 스토리지를 Multicloud Object Gateway, Red Hat Container Storage; Ceph Object Gateway, {odf-full}; 또는 MinIO와 같은 백업 위치로 지정합니다.

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

스냅샷 위치

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

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

FSB(File System Backup)를 사용하는 경우 FSB가 오브젝트 스토리지에서 파일 시스템을 백업하므로 스냅샷 위치를 지정할 필요가 없습니다.

보안

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

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

  • 백업 위치에 대한 사용자 지정 보안( DataProtectionApplication CR에서 지정)
  • DataProtectionApplication CR에서 참조하지 않는 스냅샷 위치에 대한 기본 보안입니다.
중요

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

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

4.6.8.1.1. 기본 보안 생성

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

백업 스토리지 공급자에 aws,azure 또는 gcp 와 같은 기본 플러그인이 없으면 Secret 의 기본 이름은 cloud-credentials 입니다. 이 경우 기본 이름은 공급자별 OADP 설치 절차에 지정됩니다.

참고

DataProtectionApplication 사용자 정의 리소스 (CR)에는 기본 보안이 필요합니다. 그렇지 않으면 설치에 실패합니다. 백업 위치 Secret 이 지정되지 않은 경우 기본 이름이 사용됩니다.

설치 중에 백업 위치 자격 증명을 사용하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 이름으로 Secret 을 생성할 수 있습니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지의 경우 동일한 인증 정보를 사용해야 합니다.
  • Velero에 대한 오브젝트 스토리지를 구성해야 합니다.
  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

절차

  • 기본 이름으로 보안을 생성합니다.

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

Data Protection Application을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 Secret 을 참조합니다.

4.6.8.1.2. 다른 인증 정보의 보안 생성

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

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

절차

  1. 클라우드 공급자의 적절한 형식으로 스냅샷 위치에 대한 credentials-velero 파일을 생성합니다.
  2. 기본 이름으로 스냅샷 위치에 대한 보안을 생성합니다.

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
  3. 오브젝트 스토리지에 적합한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.
  4. 사용자 지정 이름으로 백업 위치에 대한 보안을 생성합니다.

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
  5. 다음 예제와 같이 사용자 지정 이름으로 SecretDataProtectionApplication CR에 추가합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            provider: <provider>
            default: true
            credential:
              key: cloud
              name: <custom_secret> 1
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
    1
    사용자 지정 이름으로 백업 위치 보안.
4.6.8.2. 데이터 보호 애플리케이션 구성

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

4.6.8.2.1. Velero CPU 및 메모리 리소스 할당 설정

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector> 1
            resourceAllocations: 2
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.
참고

Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.

Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.

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

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

4.6.8.2.1.1. 수집된 데이터를 기반으로 Ceph CPU 및 메모리 요구 사항 조정

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

4.6.8.2.1.1.1. 구성에 대한 CPU 및 메모리 요구 사항

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

구성 유형요청최대 제한

CPU

3으로 변경됨

최대 제한 3

메모리

8Gi로 변경됨

최대 제한 128Gi

4.6.8.2.2. 자체 서명된 CA 인증서 활성화

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.velero.objectStorage.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string> 1
            config:
              insecureSkipTLSVerify: "false" 2
    ...
    1
    Base64 인코딩 CA 인증서 문자열을 지정합니다.
    2
    insecureSkipTLSVerify 구성은 "true" 또는 "false" 로 설정할 수 있습니다. "true" 로 설정하면 SSL/TLS 보안이 비활성화됩니다. "false" 로 설정하면 SSL/TLS 보안이 활성화됩니다.
4.6.8.2.2.1. Velero 배포에 별칭이 지정된 velero 명령과 함께 CA 인증서 사용

별칭을 생성하여 시스템에 로컬로 설치하지 않고 Velero CLI를 사용할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

    1. aliased Velero 명령을 사용하려면 다음 명령을 실행합니다.

      $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
    2. 다음 명령을 실행하여 별칭이 작동하는지 확인합니다.

      예제

      $ velero version
      Client:
      	Version: v1.12.1-OADP
      	Git commit: -
      Server:
      	Version: v1.12.1-OADP

    3. 이 명령으로 CA 인증서를 사용하려면 다음 명령을 실행하여 Velero 배포에 인증서를 추가할 수 있습니다.

      $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
      
      $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
      $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
    4. 백업 로그를 가져오려면 다음 명령을 실행합니다.

      $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

      이러한 로그를 사용하여 백업할 수 없는 리소스에 대한 오류 및 경고를 볼 수 있습니다.

    5. Velero 포드가 다시 시작되면 /tmp/your-cacert.txt 파일이 사라지고 이전 단계의 명령을 다시 실행하여 /tmp/your-cacert.txt 파일을 다시 생성해야 합니다.
    6. 다음 명령을 실행하여 /tmp/your-cacert.txt 파일이 여전히 있는지 확인할 수 있습니다.

      $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
      /tmp/your-cacert.txt

향후 OpenShift API for Data Protection(OADP) 릴리스에서는 이 단계가 필요하지 않도록 Velero 포드에 인증서를 마운트할 계획입니다.

4.6.8.3. 데이터 보호 애플리케이션 설치

DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application )를 설치합니다.

사전 요구 사항

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

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

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

절차

  1. Operators설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp 1
    spec:
      configuration:
        velero:
          defaultPlugins:
            - aws 2
            - kubevirt 3
            - csi 4
            - openshift 5
          resourceTimeout: 10m 6
        nodeAgent: 7
          enable: true 8
          uploaderType: kopia 9
          podConfig:
            nodeSelector: <node_selector> 10
      backupLocations:
        - velero:
            provider: gcp 11
            default: true
            credential:
              key: cloud
              name: <default_secret> 12
            objectStorage:
              bucket: <bucket_name> 13
              prefix: <prefix> 14
    1
    OADP의 기본 네임스페이스는 openshift-adp 입니다. 네임스페이스는 변수이며 구성 가능합니다.
    2
    스토리지 위치에 해당하는 오브젝트 저장소 플러그인이 필요합니다. 모든 S3 공급자의 경우 필요한 플러그인은 aws 입니다. Azure 및 GCP 오브젝트 저장소의 경우 azure 또는 gcp 플러그인이 필요합니다.
    3
    선택 사항: kubevirt 플러그인은 OpenShift Virtualization과 함께 사용됩니다.
    4
    CSI 스냅샷을 사용하여 PV를 백업하는 경우 csi 기본 플러그인을 지정합니다. csi 플러그인은 Velero CSI 베타 스냅샷 API 를 사용합니다. 스냅샷 위치를 구성할 필요가 없습니다.
    5
    openshift 플러그인은 필수입니다.
    6
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    7
    관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
    8
    nodeAgent 를 활성화하고 파일 시스템 백업을 수행하려면 이 값을 true 로 설정합니다.
    9
    업로드로 kopia 또는 restic 을 입력합니다. 설치 후에는 선택을 변경할 수 없습니다. 기본 제공 DataMover의 경우 Kopia를 사용해야 합니다. nodeAgent 는 데몬 세트를 배포합니다. 즉, nodeAgent Pod가 각 작동 중인 노드에서 실행됩니다. Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 파일 시스템 백업을 구성할 수 있습니다.
    10
    Kopia 또는 Restic을 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia 또는 Restic은 모든 노드에서 실행됩니다.
    11
    백업 공급자를 지정합니다.
    12
    백업 공급자에 기본 플러그인을 사용하는 경우 Secret 의 올바른 기본 이름(예: cloud-credentials-gcp )을 지정합니다. 사용자 지정 이름을 지정하면 사용자 지정 이름이 백업 위치에 사용됩니다. Secret 이름을 지정하지 않으면 기본 이름이 사용됩니다.
    13
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    14
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
  4. 생성을 클릭합니다.

검증

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

    $ oc get all -n openshift-adp

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s

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

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'

    출력 예

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

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.
  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true

4.6.8.4. 클라이언트 버스트 및 QPS 설정으로 DPA 구성

버스트 설정은 제한을 적용하기 전에 velero 서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.

버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero 서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burstdpa.configuration.velero.client-qps 필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.

절차

  • 다음 예와 같이 DPA에서 client-burstclient-qps 필드를 구성합니다.

    데이터 보호 애플리케이션 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500 1
          client-qps: 300 2
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    1
    client-burst 값을 지정합니다. 이 예에서 client-burst 필드는 500으로 설정됩니다.
    2
    client-qps 값을 지정합니다. 이 예에서 client-qps 필드는 300으로 설정됩니다.
4.6.8.4.1. 노드 에이전트 및 노드 라벨 구성

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

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

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

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""

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

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""

다음 예제는 nodeSelector 의 안티 패턴이며 'node-role.kubernetes.io/infra: ""''node-role.kubernetes.io/worker: ""' 둘 다 노드에 있지 않으면 작동하지 않습니다.

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
            node-role.kubernetes.io/worker: ""
4.6.8.4.2. OpenShift Data Foundation에서 재해 복구에 대한 오브젝트 버킷 클레임 생성

OpenShift Data Foundation에서 MCG(Multicloud Object Gateway) 버킷 backupStorageLocation 에 클러스터 스토리지를 사용하는 경우 OpenShift 웹 콘솔을 사용하여 OBC(Object Bucket Claim)를 생성합니다.

주의

OBC(Object Bucket Claim)를 구성하지 않으면 백업을 사용할 수 없습니다.

참고

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

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

4.6.8.4.3. DataProtectionApplication CR에서 CSI 활성화

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi 1
    1
    csi 기본 플러그인을 추가합니다.
4.6.8.4.4. DataProtectionApplication에서 노드 에이전트 비활성화

백업에 Restic,Kopia 또는 DataMover 를 사용하지 않는 경우 DataProtectionApplication CR(사용자 정의 리소스)에서 nodeAgent 필드를 비활성화할 수 있습니다. nodeAgent 를 비활성화하기 전에 OADP Operator가 유휴 상태이고 백업을 실행하지 않는지 확인합니다.

절차

  1. nodeAgent 를 비활성화하려면 enable 플래그를 false 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: false  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 비활성화합니다.
  2. nodeAgent 를 활성화하려면 enable 플래그를 true 로 설정합니다. 다음 예제를 참조하십시오.

    Example DataProtectionApplication CR

    # ...
    configuration:
      nodeAgent:
        enable: true  1
        uploaderType: kopia
    # ...

    1
    노드 에이전트를 활성화합니다.

DataProtectionApplication CR에서 nodeAgent 필드를 활성화하고 비활성화하는 작업을 설정할 수 있습니다. 자세한 내용은 "작업을 사용하여 Pod에서 작업 실행"을 참조하십시오.

4.6.9. OpenShift Virtualization을 사용하여 데이터 보호를 위한 OpenShift API 구성

OADP Operator를 설치하고 백업 위치를 구성하여 OpenShift Virtualization을 사용하여 OADP(OpenShift API for Data Protection)를 설치할 수 있습니다. 그런 다음 데이터 보호 애플리케이션을 설치할 수 있습니다.

OpenShift API for Data Protection 을 사용하여 가상 머신을 백업하고 복원합니다.

참고

OpenShift Virtualization을 사용한 OpenShift API for Data Protection에서는 다음과 같은 백업 및 복원 스토리지 옵션을 지원합니다.

  • CSI(Container Storage Interface) 백업
  • DataMover를 사용한 CSI(Container Storage Interface) 백업

다음 스토리지 옵션은 제외됩니다.

  • 파일 시스템 백업 및 복원
  • 볼륨 스냅샷 백업 및 복원

자세한 내용은 파일 시스템 백업: Kopia 또는 Restic을 사용하여 애플리케이션 백업을 참조하십시오.

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

4.6.9.1. OpenShift Virtualization을 사용하여 OADP 설치 및 구성

클러스터 관리자는 OADP Operator를 설치하여 OADP를 설치합니다.

Operator는 Velero 1.14 를 설치합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

절차

  1. 스토리지 공급자의 지침에 따라 OADP Operator를 설치합니다.
  2. kubevirtopenshift OADP 플러그인으로 DPA(Data Protection Application)를 설치합니다.
  3. Backup CR(사용자 정의 리소스)을 생성하여 가상 머신을 백업합니다.

    주의

    Red Hat 지원은 다음 옵션으로 제한됩니다.

    • CSI 백업
    • DataMover를 사용한 CSI 백업.

Restore CR을 생성하여 Backup CR을 복원합니다.

4.6.9.2. 데이터 보호 애플리케이션 설치

DataProtectionApplication API의 인스턴스를 생성하여 DPA( Data Protection Application )를 설치합니다.

사전 요구 사항

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

    참고

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

절차

  1. Operators설치된 Operators 를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 의 경우 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.
  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp 1
    spec:
      configuration:
        velero:
          defaultPlugins:
            - kubevirt 2
            - gcp 3
            - csi 4
            - openshift 5
          resourceTimeout: 10m 6
        nodeAgent: 7
          enable: true 8
          uploaderType: kopia 9
          podConfig:
            nodeSelector: <node_selector> 10
      backupLocations:
        - velero:
            provider: gcp 11
            default: true
            credential:
              key: cloud
              name: <default_secret> 12
            objectStorage:
              bucket: <bucket_name> 13
              prefix: <prefix> 14
    1
    OADP의 기본 네임스페이스는 openshift-adp 입니다. 네임스페이스는 변수이며 구성 가능합니다.
    2
    kubevirt 플러그인은 OpenShift Virtualization에 필수입니다.
    3
    백업 공급자의 플러그인을 지정합니다(예: gcp ).
    4
    CSI 스냅샷을 사용하여 PV를 백업하려면 csi 플러그인이 필요합니다. csi 플러그인은 Velero CSI 베타 스냅샷 API 를 사용합니다. 스냅샷 위치를 구성할 필요가 없습니다.
    5
    openshift 플러그인은 필수입니다.
    6
    Velero CRD 가용성, volumeSnapshot 삭제, 백업 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 분을 지정합니다. 기본값은 10m입니다.
    7
    관리 요청을 서버로 라우팅하는 관리 에이전트입니다.
    8
    nodeAgent 를 활성화하고 파일 시스템 백업을 수행하려면 이 값을 true 로 설정합니다.
    9
    Built-in DataMover를 사용하려면 업로드기로 kopia 를 입력합니다. nodeAgent 는 데몬 세트를 배포합니다. 즉, nodeAgent Pod가 각 작동 중인 노드에서 실행됩니다. Backup CR에 spec.defaultVolumesToFsBackup: true 를 추가하여 파일 시스템 백업을 구성할 수 있습니다.
    10
    Kopia를 사용할 수 있는 노드를 지정합니다. 기본적으로 Kopia는 모든 노드에서 실행됩니다.
    11
    백업 공급자를 지정합니다.
    12
    백업 공급자에 기본 플러그인을 사용하는 경우 Secret 의 올바른 기본 이름(예: cloud-credentials-gcp )을 지정합니다. 사용자 지정 이름을 지정하면 사용자 지정 이름이 백업 위치에 사용됩니다. Secret 이름을 지정하지 않으면 기본 이름이 사용됩니다.
    13
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    14
    버킷이 여러 용도로 사용되는 경우 Velero 백업의 접두사를 지정합니다.
  4. 생성을 클릭합니다.

검증

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

    $ oc get all -n openshift-adp

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s

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

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'

    출력 예

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

  3. 유형이 Reconciled 으로 설정되어 있는지 확인합니다.
  4. 백업 스토리지 위치를 확인하고 다음 명령을 실행하여 PHASE 가 사용 가능한지 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true

주의

VM이 재부팅된 직후 Microsoft Windows 가상 머신(VM)의 백업을 실행하는 경우 부분적으로Failed 오류와 함께 백업이 실패할 수 있습니다. 이는 VM이 부팅된 직후 Microsoft Windows Volume shadow Copy Service(VSS) 및 게스트 에이전트(GA) 서비스가 준비되지 않았기 때문입니다. VSS 및 GA 서비스가 준비되지 않아 백업이 실패합니다. 이러한 경우 VM이 부팅된 후 몇 분 후에 백업을 다시 시도합니다.

4.6.9.3. 단일 VM 백업

여러 VM(가상 머신)이 있고 그 중 하나만 백업하려는 경우 라벨 선택기를 사용하여 백업에 포함해야 하는 VM을 필터링할 수 있습니다. app: vmname 레이블을 사용하여 VM을 필터링할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • 네임스페이스에 여러 VM이 실행되고 있습니다.
  • kubevirt 플러그인을 DPA( DataProtectionApplication ) CR(사용자 정의 리소스)에 추가했습니다.
  • BackupStorageLocation CR을 DataProtectionApplication CR에 구성했으며 BackupStorageLocation 을 사용할 수 있습니다.

절차

  1. 다음 예에 표시된 대로 Backup CR을 구성합니다.

    Backup CR의 예

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: vmbackupsingle
      namespace: openshift-adp
    spec:
      snapshotMoveData: true
      includedNamespaces:
      - <vm_namespace> 1
      labelSelector:
        matchLabels:
          app: <vm_app_name> 2
      storageLocation: <backup_storage_location_name> 3

    1
    VM을 생성한 네임스페이스의 이름을 지정합니다.
    2
    백업해야 하는 VM 이름을 지정합니다.
    3
    BackupStorageLocation CR의 이름을 지정합니다.
  2. Backup CR을 생성하려면 다음 명령을 실행합니다.

    $ oc apply -f <backup_cr_file_name> 1
    1
    Backup CR 파일의 이름을 지정합니다.
4.6.9.4. 단일 VM 복원

Backup CR(사용자 정의 리소스)의 라벨 선택기를 사용하여 단일 VM(가상 머신)을 백업한 후 Restore CR을 생성하여 백업을 가리킬 수 있습니다. 이 복원 작업에서는 단일 VM을 복원합니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • 라벨 선택기를 사용하여 단일 VM을 백업했습니다.

절차

  1. 다음 예와 같이 Restore CR을 구성합니다.

    CR 복원

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: vmrestoresingle
      namespace: openshift-adp
    spec:
      backupName: vmbackupsingle 1
      restorePVs: true

    1
    단일 VM의 백업 이름을 지정합니다.
  2. 단일 VM을 복원하려면 다음 명령을 실행합니다.

    $ oc apply -f <restore_cr_file_name> 1
    1
    Restore CR 파일의 이름을 지정합니다.
4.6.9.5. 여러 VM의 백업에서 단일 VM 복원

여러 VM(가상 머신)이 포함된 백업이 있고 하나의 VM만 복원하려는 경우 Restore CR에서 LabelSelectors 섹션을 사용하여 복원할 VM을 선택할 수 있습니다. VM에 연결된 PVC(영구 볼륨 클레임)가 올바르게 복원되고 복원된 VM이 프로비저닝 상태에 있지 않도록 하려면 app: <vm_name > 및 kubevirt.io/created-by 레이블을 모두 사용합니다. kubevirt.io/created-by 레이블과 일치하려면 VM의 UID 를 사용합니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • 백업해야 하는 VM에 레이블이 지정되어 있습니다.
  • 여러 VM의 백업이 있습니다.

절차

  1. 여러 VM을 백업하기 전에 다음 명령을 실행하여 VM에 레이블을 지정했는지 확인합니다.

    $ oc label vm <vm_name> app=<vm_name> -n openshift-adp
  2. 다음 예와 같이 Restore CR에서 라벨 선택기를 구성합니다.

    CR 복원

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: singlevmrestore
      namespace: openshift-adp
    spec:
      backupName: multiplevmbackup
      restorePVs: true
      LabelSelectors:
        - matchLabels:
            kubevirt.io/created-by: <datavolume_uid> 1
        - matchLabels:
            app: <vm_name> 2

    1
    복원할 VM 의 UID를 지정합니다. 예를 들어 b6…​53a-ddd7-4d9d-9407-a0c…​e5.
    2
    복원할 VM의 이름을 지정합니다. 예를 들면 test-vm 입니다.
  3. VM을 복원하려면 다음 명령을 실행합니다.

    $ oc apply -f <restore_cr_file_name> 1
    1
    Restore CR 파일의 이름을 지정합니다.
4.6.9.6. 클라이언트 버스트 및 QPS 설정으로 DPA 구성

버스트 설정은 제한을 적용하기 전에 velero 서버로 보낼 수 있는 요청 수를 결정합니다. 버스트 제한에 도달한 후 초당 쿼리(QPS) 설정에 따라 초당 전송할 수 있는 추가 요청 수를 결정합니다.

버스트 및 QPS 값으로 DPA(Data Protection Application)를 구성하여 velero 서버의 버스트 및 QPS 값을 설정할 수 있습니다. DPA의 dpa.configuration.velero.client-burstdpa.configuration.velero.client-qps 필드를 사용하여 burst 및 QPS 값을 설정할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.

절차

  • 다음 예와 같이 DPA에서 client-burstclient-qps 필드를 구성합니다.

    데이터 보호 애플리케이션 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500 1
          client-qps: 300 2
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    1
    client-burst 값을 지정합니다. 이 예에서 client-burst 필드는 500으로 설정됩니다.
    2
    client-qps 값을 지정합니다. 이 예에서 client-qps 필드는 300으로 설정됩니다.
4.6.9.6.1. 노드 에이전트 및 노드 라벨 구성

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

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

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

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""

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

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""

다음 예제는 nodeSelector 의 안티 패턴이며 'node-role.kubernetes.io/infra: ""''node-role.kubernetes.io/worker: ""' 둘 다 노드에 있지 않으면 작동하지 않습니다.

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
            node-role.kubernetes.io/worker: ""
4.6.9.7. 증분 백업 지원 정보

OADP는 컨테이너화된 워크로드와 OpenShift Virtualization 워크로드 모두에 대해 블록Filesystem 영구 볼륨의 증분 백업을 지원합니다. 다음 표에는 파일 시스템 백업(FSB), CSI(Container Storage Interface) 및 CSI 데이터 Mover에 대한 지원이 요약되어 있습니다.

표 4.4. 컨테이너화된 워크로드에 대한 OADP 백업 지원 매트릭스
볼륨 모드FSB - ResticFSB - KopiaCSICSI 데이터 Mover

파일 시스템

S [1], I [2]

S [1], I [2]

S [1]

S [1], I [2]

블록

N [3]

N [3]

S [1]

S [1], I [2]

표 4.5. OpenShift Virtualization 워크로드에 대한 OADP 백업 지원 매트릭스
볼륨 모드FSB - ResticFSB - KopiaCSICSI 데이터 Mover

파일 시스템

N [3]

N [3]

S [1]

S [1], I [2]

블록

N [3]

N [3]

S [1]

S [1], I [2]

  1. 지원되는 백업
  2. 증분 백업 지원
  3. 지원되지 않음
참고

CSI Data Mover 백업은 uploaderType 과 관계없이 Kopia를 사용합니다.

중요

Red Hat은 OADP 버전 1.3.0 이상과 OpenShift Virtualization 버전 4.14 이상만 지원합니다.

1.3.0 이전 OADP 버전은 OpenShift Virtualization의 백업 및 복원에 지원되지 않습니다.

4.6.10. 두 개 이상의 Backup Storage 위치를 사용하여 OADP(OpenShift API for Data Protection) 구성

DPA(Data Protection Application)에서 하나 이상의 백업 스토리지 위치(BSL)를 구성할 수 있습니다. 백업을 생성할 때 백업을 저장할 위치를 선택할 수도 있습니다. 이 구성을 사용하면 다음과 같은 방법으로 백업을 저장할 수 있습니다.

  • 다른 리전으로
  • 다른 스토리지 공급자로 전환

OADP는 두 개 이상의 BSL을 구성하기 위한 여러 자격 증명을 지원하므로 모든 BSL과 함께 사용할 인증 정보를 지정할 수 있습니다.

4.6.10.1. 두 개 이상의 BSL로 DPA 구성

DPA를 두 개 이상의 BSL로 구성하고 클라우드 공급자가 제공하는 자격 증명을 지정할 수 있습니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성해야 합니다.

절차

  1. 두 개 이상의 BSL로 DPA를 구성합니다. 다음 예제를 참조하십시오.

    DPA 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    #...
    backupLocations:
      - name: aws 1
        velero:
          provider: aws
          default: true 2
          objectStorage:
            bucket: <bucket_name> 3
            prefix: <prefix> 4
          config:
            region: <region_name> 5
            profile: "default"
          credential:
            key: cloud
            name: cloud-credentials 6
      - name: odf 7
        velero:
          provider: aws
          default: false
          objectStorage:
            bucket: <bucket_name>
            prefix: <prefix>
          config:
            profile: "default"
            region: <region_name>
            s3Url: <url> 8
            insecureSkipTLSVerify: "true"
            s3ForcePathStyle: "true"
          credential:
            key: cloud
            name: <custom_secret_name_odf> 9
    #...

    1
    첫 번째 BSL의 이름을 지정합니다.
    2
    이 매개 변수는 이 BSL이 기본 BSL임을 나타냅니다. Backup CR 에 BSL이 설정되지 않은 경우 기본 BSL이 사용됩니다. 하나의 BSL만 기본값으로 설정할 수 있습니다.
    3
    버킷 이름을 지정합니다.
    4
    Velero 백업의 접두사를 지정합니다(예: velero ).
    5
    버킷의 AWS 리전을 지정합니다.
    6
    생성한 기본 Secret 오브젝트의 이름을 지정합니다.
    7
    두 번째 BSL의 이름을 지정합니다.
    8
    S3 끝점의 URL을 지정합니다.
    9
    시크릿 의 올바른 이름을 지정합니다(예: custom_secret_name_odf ). Secret 이름을 지정하지 않으면 기본 이름이 사용됩니다.
  2. 백업 CR에 사용할 BSL을 지정합니다. 다음 예제를 참조하십시오.

    백업 CR의 예

    apiVersion: velero.io/v1
    kind: Backup
    # ...
    spec:
      includedNamespaces:
      - <namespace> 1
      storageLocation: <backup_storage_location> 2
      defaultVolumesToFsBackup: true

    1
    백업할 네임스페이스를 지정합니다.
    2
    스토리지 위치를 지정합니다.
4.6.10.2. 두 개의 BSL 사용 사례

이 사용 사례에서는 두 개의 클라우드 인증 정보를 사용하여 두 개의 스토리지 위치로 DPA를 구성합니다. 기본 BSL을 사용하여 데이터베이스와 함께 애플리케이션을 백업합니다. OADP는 백업 리소스를 기본 BSL에 저장합니다. 그런 다음 두 번째 BSL을 사용하여 애플리케이션을 다시 백업합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • AWS S3 및 MCG(Multicloud Object Gateway)의 두 개의 백업 스토리지 위치를 구성해야 합니다.
  • Red Hat OpenShift 클러스터에 배포된 데이터베이스가 있는 애플리케이션이 있어야 합니다.

절차

  1. 다음 명령을 실행하여 기본 이름으로 AWS S3 스토리지 공급자에 대한 첫 번째 보안을 생성합니다.

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=<aws_credentials_file_name> 1
    1
    AWS S3의 클라우드 인증 정보 파일의 이름을 지정합니다.
  2. 다음 명령을 실행하여 사용자 지정 이름으로 MCG의 두 번째 보안을 생성합니다.

    $ oc create secret generic mcg-secret -n openshift-adp --from-file cloud=<MCG_credentials_file_name> 1
    1
    MCG의 클라우드 인증 정보 파일의 이름을 지정합니다. mcg-secret 사용자 정의 시크릿의 이름을 확인합니다.
  3. 다음 예와 같이 두 개의 BSL로 DPA를 구성합니다.

    DPA 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: two-bsl-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - name: aws
        velero:
          config:
            profile: default
            region: <region_name> 1
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name> 2
            prefix: velero
          provider: aws
      - name: mcg
        velero:
          config:
            insecureSkipTLSVerify: "true"
            profile: noobaa
            region: <region_name> 3
            s3ForcePathStyle: "true"
            s3Url: <s3_url> 4
          credential:
            key: cloud
            name: mcg-secret 5
          objectStorage:
            bucket: <bucket_name_mcg> 6
            prefix: velero
          provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
          - openshift
          - aws

    1
    버킷의 AWS 리전을 지정합니다.
    2
    AWS S3 버킷 이름을 지정합니다.
    3
    MCG 문서의 이름 지정 규칙에 따라 리전을 지정합니다.
    4
    MCG의 S3 끝점 URL을 지정합니다.
    5
    MCG 스토리지의 사용자 정의 시크릿 이름을 지정합니다.
    6
    MCG 버킷 이름을 지정합니다.
  4. 다음 명령을 실행하여 DPA를 생성합니다.

    $ oc create -f <dpa_file_name> 1
    1
    구성한 DPA의 파일 이름을 지정합니다.
  5. 다음 명령을 실행하여 DPA가 조정되었는지 확인합니다.

    $ oc get dpa -o yaml
  6. 다음 명령을 실행하여 BSL을 사용할 수 있는지 확인합니다.

    $ oc get bsl

    출력 예

    NAME   PHASE       LAST VALIDATED   AGE     DEFAULT
    aws    Available   5s               3m28s   true
    mcg    Available   5s               3m28s

  7. 기본 BSL을 사용하여 백업 CR을 생성합니다.

    참고

    다음 예제에서는 storageLocation 필드가 백업 CR에 지정되지 않습니다.

    백업 CR의 예

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup1
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <mysql_namespace> 1
      defaultVolumesToFsBackup: true

    1
    클러스터에 설치된 애플리케이션의 네임스페이스를 지정합니다.
  8. 다음 명령을 실행하여 백업을 생성합니다.

    $ oc apply -f <backup_file_name> 1
    1
    백업 CR 파일의 이름을 지정합니다.
  9. 다음 명령을 실행하여 백업이 기본 BSL로 완료되었는지 확인합니다.

    $ oc get backups.velero.io <backup_name> -o yaml 1
    1
    백업 이름을 지정합니다.
  10. MCG를 BSL로 사용하여 백업 CR을 생성합니다. 다음 예제에서는 백업 CR 생성 시 두 번째 storageLocation 값이 지정됩니다.

    백업 CR의 예

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup1
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <mysql_namespace> 1
      storageLocation: mcg 2
      defaultVolumesToFsBackup: true

    1
    클러스터에 설치된 애플리케이션의 네임스페이스를 지정합니다.
    2
    두 번째 스토리지 위치를 지정합니다.
  11. 다음 명령을 실행하여 두 번째 백업을 생성합니다.

    $ oc apply -f <backup_file_name> 1
    1
    백업 CR 파일의 이름을 지정합니다.
  12. 다음 명령을 실행하여 스토리지 위치를 MCG로 사용하여 백업이 완료되었는지 확인합니다.

    $ oc get backups.velero.io <backup_name> -o yaml 1
    1
    백업 이름을 지정합니다.

4.6.11. 두 개 이상의 Volume Snapshot Location으로 OADP(OpenShift API for Data Protection) 구성

스냅샷을 다른 클라우드 공급자 지역에 저장하도록 하나 이상의 볼륨 스냅샷 위치(VSL)를 구성할 수 있습니다.

4.6.11.1. 두 개 이상의 VSL로 DPA 구성

두 개 이상의 VSL로 DPA를 구성하고 클라우드 공급자가 제공하는 인증 정보를 지정합니다. 영구 볼륨과 동일한 리전에 스냅샷 위치를 구성해야 합니다. 다음 예제를 참조하십시오.

DPA 예

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
#...
snapshotLocations:
  - velero:
      config:
        profile: default
        region: <region> 1
      credential:
        key: cloud
        name: cloud-credentials
      provider: aws
  - velero:
      config:
        profile: default
        region: <region>
      credential:
        key: cloud
        name: <custom_credential> 2
      provider: aws
#...

1
리전을 지정합니다. 스냅샷 위치는 영구 볼륨과 동일한 리전에 있어야 합니다.
2
사용자 정의 인증 정보 이름을 지정합니다.

4.7. OADP 설치 제거

4.7.1. 데이터 보호를 위한 OpenShift API 설치 제거

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

4.8. OADP 백업

4.8.1. 애플리케이션 백업

빈번한 백업은 백업 스토리지 위치에 스토리지를 사용할 수 있습니다. 로컬이 아닌 백업(예: S3 버킷)을 사용하는 경우 백업, 보존 시간, PV(영구 볼륨)의 데이터 양을 확인합니다. 수행된 모든 백업은 만료될 때까지 유지되므로 일정의 라이브(TTL) 설정도 확인합니다.

Backup 사용자 정의 리소스(CR)를 생성하여 애플리케이션을 백업할 수 있습니다. 자세한 내용은 Backup CR 생성을 참조하십시오.

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

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

중요

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

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

참고

CloudStorage API는 CloudStorage 오브젝트를 사용하고 OADP에서 CloudStorage API를 사용하여 BackupStorageLocation 으로 사용할 S3 버킷을 자동으로 생성하도록 하는 경우 기술 프리뷰 기능입니다.

CloudStorage API는 기존 S3 버킷을 지정하여 BackupStorageLocation 오브젝트를 수동으로 생성할 수 있도록 지원합니다. S3 버킷을 자동으로 생성하는 CloudStorage API는 현재 AWS S3 스토리지에만 활성화됩니다.

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

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

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

중요

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

4.8.1.1. 백업을 실행하고 복원하기 전에 리소스 미리 보기

OADP는 유형, 네임스페이스 또는 레이블을 기반으로 애플리케이션 리소스를 백업합니다. 즉, 백업이 완료된 후 리소스를 볼 수 있습니다. 마찬가지로 복원 작업이 완료된 후 네임스페이스, 영구 볼륨(PV) 또는 라벨을 기반으로 복원된 오브젝트를 볼 수 있습니다. 리소스를 미리 미리 보려면 백업 및 복원 작업을 예행히 실행할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.

절차

  1. 실제 백업을 실행하기 전에 백업에 포함된 리소스를 미리 보려면 다음 명령을 실행합니다.

    $ velero backup create <backup-name> --snapshot-volumes false 1
    1
    --snapshot-volumes 매개변수 값을 false 로 지정합니다.
  2. 백업 리소스에 대한 자세한 내용을 보려면 다음 명령을 실행합니다.

    $ velero describe backup <backup_name> --details 1
    1
    백업 이름을 지정합니다.
  3. 실제 복원을 실행하기 전에 복원에 포함된 리소스를 미리 보려면 다음 명령을 실행합니다.

    $ velero restore create --from-backup <backup-name> 1
    1
    백업 리소스를 검토하기 위해 생성된 백업의 이름을 지정합니다.
    중요

    velero restore create 명령은 클러스터에 복원 리소스를 생성합니다. 리소스를 검토한 후 복원의 일부로 생성된 리소스를 삭제해야 합니다.

  4. 복원 리소스에 대한 자세한 내용을 보려면 다음 명령을 실행합니다.

    $ velero describe restore <restore_name> --details 1
    1
    복원의 이름을 지정합니다.

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

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

4.8.1.2. 확인된 문제

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

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

4.8.2. 백업 CR 생성

Backup CR(사용자 정의 리소스)을 생성하여 Kubernetes 이미지, 내부 이미지 및 PV(영구 볼륨)를 Backup 합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
  • DataProtectionApplication CR은 Ready 상태에 있어야 합니다.
  • 백업 위치 사전 요구 사항:

    • Velero에 대해 구성된 S3 오브젝트 스토리지가 있어야 합니다.
    • DataProtectionApplication CR에 구성된 백업 위치가 있어야 합니다.
  • 스냅샷 위치 사전 요구 사항:

    • 클라우드 공급자에는 기본 스냅샷 API가 있거나 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
    • CSI 스냅샷의 경우 CSI 드라이버를 등록하려면 VolumeSnapshotClass CR을 생성해야 합니다.
    • DataProtectionApplication CR에 구성된 볼륨 위치가 있어야 합니다.

절차

  1. 다음 명령을 입력하여 backupStorageLocations CR을 검색합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
    openshift-adp   velero-sample-1   Available   11s              31m

  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 5
      labelSelector: 6
        matchLabels:
          app: <label_1>
          app: <label_2>
          app: <label_3>
      orLabelSelectors: 7
      - matchLabels:
          app: <label_1>
          app: <label_2>
          app: <label_3>
    1
    백업할 네임스페이스 배열을 지정합니다.
    2
    선택 사항: 백업에 포함할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: 'pods'의 경우')이거나 정규화된 것일 수 있습니다. 지정하지 않으면 모든 리소스가 포함됩니다.
    3
    선택 사항: 백업에서 제외할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: 'pods'의 경우')이거나 정규화된 것일 수 있습니다.
    4
    backupStorageLocations CR의 이름을 지정합니다.
    5
    ttl 필드는 생성된 백업의 보존 시간과 백업 데이터를 정의합니다. 예를 들어 Restic을 백업 도구로 사용하는 경우 백업이 만료될 때까지 백업된 데이터 항목과 PV(영구 볼륨)의 데이터 콘텐츠가 저장됩니다. 그러나 이러한 데이터를 저장하면 대상 백업 위치에 더 많은 공간이 사용됩니다. 추가 스토리지는 만료되지 않은 다른 완료된 백업이 시간 초과되었을 수 있기 전에 생성되는 빈번한 백업과 함께 사용됩니다.
    6
    지정된 라벨이 모두 있는 백업 리소스의 {key,value} 쌍의 맵입니다.
    7
    지정된 라벨이 하나 이상 있는 백업 리소스의 {key,value} 쌍의 맵입니다.
  3. Backup CR의 상태가 Completed 인지 확인합니다.

    $ oc get backups.velero.io -n openshift-adp <backup> -o jsonpath='{.status.phase}'

4.8.3. CSI 스냅샷을 사용하여 영구 볼륨 백업

Backup CR을 생성하기 전에 클라우드 스토리지의 VolumeSnapshotClass CR(사용자 정의 리소스)을 편집하여 CSI(Container Storage Interface) 스냅샷을 사용하여 영구 볼륨을 백업 합니다. CSI 볼륨 스냅샷을 참조하십시오.

자세한 내용은 Backup CR 생성을 참조하십시오.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.
  • DataProtectionApplication CR에서 CSI를 활성화해야 합니다.

절차

  • volume Class CR에 metadata.labels.velero.io/csi-volumesnapshot-class: "true" 키-값 쌍을 추가합니다.

    설정 파일 예

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshotClass
    metadata:
      name: <volume_snapshot_class_name>
      labels:
        velero.io/csi-volumesnapshot-class: "true" 1
      annotations:
        snapshot.storage.kubernetes.io/is-default-class: true 2
    driver: <csi_driver>
    deletionPolicy: <deletion_policy_type> 3

    1
    true 로 설정해야 합니다.
    2
    true 로 설정해야 합니다.
    3
    OADP는 CSI 및 Data Mover 백업 및 복원에 대한 RetainDelete 삭제 정책 유형을 지원합니다. OADP 1.2 Data Mover의 경우 삭제 정책 유형을 Retain 으로 설정합니다.

다음 단계

  • 이제 Backup CR을 생성할 수 있습니다.

4.8.4. 파일 시스템 백업을 사용하여 애플리케이션 백업: Kopia 또는 Restic

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(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
  • DataProtectionApplication CR에서 spec.configuration. nodeAgent.enablefalse 로 설정하여 기본 nodeAgent 설치를 비활성화해서는 안 됩니다.
  • spec.configuration.nodeAgent.uploaderTypeDataProtectionApplication CR에서 kopia 또는 restic 으로 설정하여 업로드로 Kopia 또는 Restic을 선택해야 합니다.
  • DataProtectionApplication CR은 Ready 상태에 있어야 합니다.

절차

  • 다음 예와 같이 Backup CR을 생성합니다.

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      labels:
        velero.io/storage-location: default
      namespace: openshift-adp
    spec:
      defaultVolumesToFsBackup: true 1
    ...
    1
    OADP 버전 1.2 이상에서 spec 블록 내에 defaultVolumesToFsBackup: true 설정을 추가합니다. OADP 버전 1.1에서 defaultVolumesToRestic: true 를 추가합니다.

4.8.5. 백업 후크 생성

백업을 수행할 때 백업 중인 Pod에 따라 Pod 내의 컨테이너에서 실행할 하나 이상의 명령을 지정할 수 있습니다.

사용자 정의 작업 처리(사전 후크) 전에 또는 모든 사용자 정의 작업이 완료된 후 및 사용자 지정 작업에 의해 지정된 추가 항목이 백업(후크)되도록 명령을 구성할 수 있습니다.

Backup CR(사용자 정의 리소스)을 편집하여 Pod의 컨테이너에서 명령을 실행하는 백업 후크를 생성합니다.

절차

  • 다음 예제와 같이 Backup CR의 spec.hooks 블록에 후크를 추가합니다.

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      namespace: openshift-adp
    spec:
      hooks:
        resources:
          - name: <hook_name>
            includedNamespaces:
            - <namespace> 1
            excludedNamespaces: 2
            - <namespace>
            includedResources: []
            - pods 3
            excludedResources: [] 4
            labelSelector: 5
              matchLabels:
                app: velero
                component: server
            pre: 6
              - exec:
                  container: <container> 7
                  command:
                  - /bin/uname 8
                  - -a
                  onError: Fail 9
                  timeout: 30s 10
            post: 11
    ...
    1
    선택 사항: 후크가 적용되는 네임스페이스를 지정할 수 있습니다. 이 값을 지정하지 않으면 후크가 모든 네임스페이스에 적용됩니다.
    2
    선택 사항: 후크가 적용되지 않는 네임스페이스를 지정할 수 있습니다.
    3
    현재 Pod는 후크를 적용할 수 있는 유일한 지원 리소스입니다.
    4
    선택 사항: 후크가 적용되지 않는 리소스를 지정할 수 있습니다.
    5
    선택 사항: 이 후크는 라벨과 일치하는 오브젝트에만 적용됩니다. 이 값을 지정하지 않으면 후크가 모든 오브젝트에 적용됩니다.
    6
    백업 전에 실행할 후크 배열입니다.
    7
    선택 사항: 컨테이너를 지정하지 않으면 Pod의 첫 번째 컨테이너에서 명령이 실행됩니다.
    8
    추가되는 init 컨테이너의 진입점입니다.
    9
    오류 처리에 허용되는 값은 FailContinue 입니다. 기본값은 Fail 입니다.
    10
    선택 사항: 명령을 실행할 때까지 대기하는 시간입니다. 기본값은 30s 입니다.
    11
    이 블록은 사전 백업 후크와 동일한 매개변수를 사용하여 백업 후 실행할 후크 배열을 정의합니다.

4.8.6. 스케줄 CR을 사용하여 백업 예약

schedule 작업을 사용하면 Cron 표현식에 지정된 특정 시간에 데이터 백업을 생성할 수 있습니다.

Backup CR 대신 Schedule CR(사용자 정의 리소스)을 생성하여 백업을 예약합니다.

주의

다른 백업이 생성되기 전에 백업이 완료될 때까지 백업 일정에 충분한 시간을 남겨 둡니다.

예를 들어 네임스페이스 백업에 일반적으로 10분이 걸리는 경우 15분마다 백업을 더 자주 예약하지 마십시오.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
  • DataProtectionApplication CR은 Ready 상태에 있어야 합니다.

절차

  1. backupStorageLocations CR을 검색합니다.

    $ oc get backupStorageLocations -n openshift-adp

    출력 예

    NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
    openshift-adp   velero-sample-1   Available   11s              31m

  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 5
    EOF
    참고

    특정 간격으로 백업을 예약하려면 다음 형식으로 &lt ;duration_in_minutes& gt;를 입력합니다.

      schedule: "*/10 * * * *"

    따옴표 사이에 분 값을 입력합니다(" ").

    1
    백업을 예약하는 Cron 표현식(예: 0 7 * * * *)은 7:00에 매일 백업을 수행합니다.
    2
    백업할 네임스페이스 배열입니다.
    3
    backupStorageLocations CR의 이름입니다.
    4
    선택 사항: OADP 버전 1.2 이상에서 Restic을 사용하여 볼륨 백업을 수행할 때 defaultVolumesToFsBackup: true key-value 쌍을 구성에 추가합니다. OADP 버전 1.1에서 Restic을 사용하여 볼륨을 백업할 때 defaultVolumesToRestic: true key-value 쌍을 추가합니다.
    5
    ttl 필드는 생성된 백업의 보존 시간과 백업 데이터를 정의합니다. 예를 들어 Restic을 백업 도구로 사용하는 경우 백업이 만료될 때까지 백업된 데이터 항목과 PV(영구 볼륨)의 데이터 콘텐츠가 저장됩니다. 그러나 이러한 데이터를 저장하면 대상 백업 위치에 더 많은 공간이 사용됩니다. 추가 스토리지는 만료되지 않은 다른 완료된 백업이 시간 초과되었을 수 있기 전에 생성되는 빈번한 백업과 함께 사용됩니다.
  3. 예약된 백업이 실행된 후 Schedule CR의 상태가 Completed 인지 확인합니다.

    $ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'

4.8.7. 백업 삭제

DeleteBackupRequest CR(사용자 정의 리소스)을 생성하거나 다음 절차에 설명된 대로 velero backup delete 명령을 실행하여 백업을 삭제할 수 있습니다.

백업 방법에 따라 볼륨 백업 아티팩트는 다른 시간에 삭제됩니다.

  • Restic: 백업 삭제 후 다음 전체 유지 관리 주기에서 아티팩트가 삭제됩니다.
  • CSI(Container Storage Interface): 백업을 삭제할 때 아티팩트가 즉시 삭제됩니다.
  • Kopia: 아티팩트는 백업 삭제 후 Kopia 리포지토리의 세 가지 유지 관리 주기 후에 삭제됩니다.
4.8.7.1. DeleteBackupRequest CR을 생성하여 백업 삭제

DeleteBackupRequest CR(사용자 정의 리소스)을 생성하여 백업을 삭제할 수 있습니다.

사전 요구 사항

  • 애플리케이션의 백업을 실행했습니다.

절차

  1. DeleteBackupRequest CR 매니페스트 파일을 생성합니다.

    apiVersion: velero.io/v1
    kind: DeleteBackupRequest
    metadata:
      name: deletebackuprequest
      namespace: openshift-adp
    spec:
      backupName: <backup_name> 1
    1
    백업 이름을 지정합니다.
  2. DeleteBackupRequest CR을 적용하여 백업을 삭제합니다.

    $ oc apply -f <deletebackuprequest_cr_filename>
4.8.7.2. Velero CLI를 사용하여 백업 삭제

Velero CLI를 사용하여 백업을 삭제할 수 있습니다.

사전 요구 사항

  • 애플리케이션의 백업을 실행했습니다.
  • Velero CLI를 다운로드하여 클러스터의 Velero 바이너리에 액세스할 수 있습니다.

절차

  • 백업을 삭제하려면 다음 Velero 명령을 실행합니다.

    $ velero backup delete <backup_name> -n openshift-adp 1
    1
    백업 이름을 지정합니다.
4.8.7.3. Kopia 리포지토리 유지 관리 정보

Kopia 리포지토리 유지 관리에는 다음 두 가지 유형이 있습니다.

빠른 유지 관리
  • 매시간 을 실행하여 인덱스 Blob(n) 수를 낮게 유지합니다. 많은 수의 인덱스가 Kopia 작업의 성능에 부정적인 영향을 미칩니다.
  • 동일한 메타데이터의 다른 사본이 있는지 확인하지 않고 리포지토리에서 메타데이터를 삭제하지 않습니다.
완전 유지 관리
  • 더 이상 필요하지 않은 리포지토리 콘텐츠의 가비지 컬렉션을 수행하기 위해 24시간마다 실행됩니다.
  • 전체 유지 관리 작업인 snapshot-gc 는 스냅샷 매니페스트에서 더 이상 액세스할 수 없는 모든 파일 및 디렉터리 목록을 찾아 삭제된 것으로 표시합니다.
  • 전체 유지 관리는 클러스터에서 활성 상태인 모든 스냅샷의 모든 디렉터리를 검사해야 하므로 리소스 비용이 많이 드는 작업입니다.
4.8.7.3.1. OADP에서 Kopia 유지 관리

repo-maintain-job 작업은 다음 예와 같이 OADP가 설치된 네임스페이스에서 실행됩니다.

pod/repo-maintain-job-173...2527-2nbls                             0/1     Completed   0          168m
pod/repo-maintain-job-173....536-fl9tm                             0/1     Completed   0          108m
pod/repo-maintain-job-173...2545-55ggx                             0/1     Completed   0          48m

백업 오브젝트 스토리지에서 정리 및 아티팩트 제거에 대한 자세한 내용은 repo-maintain-job 의 로그를 확인할 수 있습니다. 다음 전체 사이클 유지 관리로 인해 repo-maintain-job 에서 다음 예에 표시된 대로 노트를 찾을 수 있습니다.

not due for full maintenance cycle until 2024-00-00 18:29:4
중요

백업 오브젝트 스토리지에서 오브젝트를 삭제하려면 전체 유지 관리 주기를 성공적으로 실행해야 합니다. 즉, 백업 오브젝트 스토리지의 모든 아티팩트가 삭제될 때까지 최대 72시간을 기대할 수 있습니다.

4.8.7.4. 백업 리포지토리 삭제

백업을 삭제한 후 관련 아티팩트를 삭제하기 위해 Kopia 리포지토리 유지 관리 주기가 완료되면 메타데이터 또는 매니페스트 오브젝트에서 더 이상 백업을 참조하지 않습니다. 그런 다음 backuprepository CR(사용자 정의 리소스)을 삭제하여 백업 삭제 프로세스를 완료할 수 있습니다.

사전 요구 사항

  • 애플리케이션의 백업을 삭제했습니다.
  • 백업이 삭제된 후 최대 72시간 동안 대기했습니다. 이 시간 프레임을 사용하면 Kopia에서 리포지토리 유지 관리 사이클을 실행할 수 있습니다.

절차

  1. 백업에 대한 백업 리포지토리 CR의 이름을 가져오려면 다음 명령을 실행합니다.

    $ oc get backuprepositories.velero.io -n openshift-adp
  2. 백업 리포지토리 CR을 삭제하려면 다음 명령을 실행합니다.

    $ oc delete backuprepository <backup_repository_name> -n openshift-adp 1
    1
    이전 단계에서 백업 리포지토리의 이름을 지정합니다.

4.8.8. Kopia 정보

Kopia는 데이터의 암호화된 스냅샷을 작성하고 선택한 원격 또는 클라우드 스토리지에 스냅샷을 저장할 수 있는 빠르고 안전한 오픈 소스 백업 및 복원 도구입니다.

Kopia는 네트워크 및 로컬 스토리지 위치와 다음을 포함한 많은 클라우드 또는 원격 스토리지 위치를 지원합니다.

  • Amazon S3 및 S3와 호환되는 모든 클라우드 스토리지
  • Azure Blob Storage
  • Google Cloud Storage 플랫폼

Kopia는 스냅샷을 위해 콘텐츠 주소 지정 가능 스토리지를 사용합니다.

  • 스냅샷은 항상 증분입니다. 이전 스냅샷에 이미 포함된 데이터는 리포지토리에 다시 업로드되지 않습니다. 파일은 수정된 경우에만 리포지토리에 업로드됩니다.
  • 저장된 데이터는 중복됩니다. 동일한 파일의 복사본이 여러 개 있으면 둘 중 하나만 저장됩니다.
  • 파일이 이동되거나 이름이 변경된 경우 Kopia는 동일한 콘텐츠가 있고 다시 업로드하지 않는다는 것을 인식할 수 있습니다.
4.8.8.1. Kopia와 OADP 통합

OADP 1.3은 Restic 외에도 Pod 볼륨 백업의 백업 메커니즘으로 Kopia를 지원합니다. 설치 시 DataProtectionApplication CR(사용자 정의 리소스)에서 uploaderType 필드를 설정하여 설치 시 하나 이상을 선택해야 합니다. 가능한 값은 restic 또는 kopia 입니다. uploaderType 을 지정하지 않으면 OADP 1.3의 기본값은 Kopia를 백업 메커니즘으로 사용합니다. 데이터는 통합 리포지토리로 작성 및 읽습니다.

다음 예제에서는 Kopia를 사용하도록 구성된 DataProtectionApplication CR을 보여줍니다.

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: dpa-sample
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
# ...

4.9. OADP 복원

4.9.1. 애플리케이션 복원

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

Restore CR을 편집하여 Pod의 컨테이너에서 명령을 실행하기 위해 복원 후크를 생성할 수 있습니다. 복원 후크 생성 을 참조하십시오.

4.9.1.1. 백업을 실행하고 복원하기 전에 리소스 미리 보기

OADP는 유형, 네임스페이스 또는 레이블을 기반으로 애플리케이션 리소스를 백업합니다. 즉, 백업이 완료된 후 리소스를 볼 수 있습니다. 마찬가지로 복원 작업이 완료된 후 네임스페이스, 영구 볼륨(PV) 또는 라벨을 기반으로 복원된 오브젝트를 볼 수 있습니다. 리소스를 미리 미리 보려면 백업 및 복원 작업을 예행히 실행할 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.

절차

  1. 실제 백업을 실행하기 전에 백업에 포함된 리소스를 미리 보려면 다음 명령을 실행합니다.

    $ velero backup create <backup-name> --snapshot-volumes false 1
    1
    --snapshot-volumes 매개변수 값을 false 로 지정합니다.
  2. 백업 리소스에 대한 자세한 내용을 보려면 다음 명령을 실행합니다.

    $ velero describe backup <backup_name> --details 1
    1
    백업 이름을 지정합니다.
  3. 실제 복원을 실행하기 전에 복원에 포함된 리소스를 미리 보려면 다음 명령을 실행합니다.

    $ velero restore create --from-backup <backup-name> 1
    1
    백업 리소스를 검토하기 위해 생성된 백업의 이름을 지정합니다.
    중요

    velero restore create 명령은 클러스터에 복원 리소스를 생성합니다. 리소스를 검토한 후 복원의 일부로 생성된 리소스를 삭제해야 합니다.

  4. 복원 리소스에 대한 자세한 내용을 보려면 다음 명령을 실행합니다.

    $ velero describe restore <restore_name> --details 1
    1
    복원의 이름을 지정합니다.
4.9.1.2. Restore CR을 생성

Restore CR을 생성하여 Backup CR(사용자 정의 리소스)을 복원합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
  • DataProtectionApplication CR은 Ready 상태에 있어야 합니다.
  • Velero Backup CR이 있어야 합니다.
  • PV(영구 볼륨) 용량이 백업 시 요청된 크기와 일치해야 합니다. 필요한 경우 요청된 크기를 조정합니다.

절차

  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
    1
    백업 CR의 이름입니다.
    2
    선택 사항: 복원 프로세스에 포함할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: Pod의 경우) 또는 정규화된일 수 있습니다. 지정하지 않으면 모든 리소스가 포함됩니다.
    3
    선택 사항: restorePVs 매개변수를 false 로 설정하여 VolumeSnapshot of Container Storage Interface(CSI) 스냅샷에서 PersistentVolumes 복원을 끄거나 VolumeSnapshotLocation 이 구성된 경우 기본 스냅샷에서 설정할 수 있습니다.
  2. 다음 명령을 입력하여 Restore CR의 상태가 Completed 인지 확인합니다.

    $ oc get restores.velero.io -n openshift-adp <restore> -o jsonpath='{.status.phase}'
  3. 다음 명령을 입력하여 백업 리소스가 복원되었는지 확인합니다.

    $ oc get all -n <namespace> 1
    1
    백업한 네임스페이스입니다.
  4. 볼륨과 함께 DeploymentConfig 를 복원하거나 복원 후 후크를 사용하는 경우 다음 명령을 입력하여 dc-post-restore.sh 정리 스크립트를 실행합니다.

    $ bash dc-restic-post-restore.sh -> dc-post-restore.sh
    참고

    복원 프로세스 중에 OADP Velero 플러그인은 DeploymentConfig 오브젝트를 축소하고 Pod를 독립 실행형 포드로 복원합니다. 이 작업은 클러스터가 복원 시 복원된 DeploymentConfig Pod를 즉시 삭제하지 않고 복원 및 복원 후 후크로 복원된 Pod에서 작업을 완료할 수 있도록 하기 위해 수행됩니다. 아래에 표시된 정리 스크립트는 이러한 연결이 끊긴 Pod를 제거하고 적절한 복제본 수로 DeploymentConfig 오브젝트를 다시 확장합니다.

    예 4.1. DC-restic-post-restore.sh → dc-post-restore.sh 정리 스크립트

    #!/bin/bash
    set -e
    
    # if sha256sum exists, use it to check the integrity of the file
    if command -v sha256sum >/dev/null 2>&1; then
      CHECKSUM_CMD="sha256sum"
    else
      CHECKSUM_CMD="shasum -a 256"
    fi
    
    label_name () {
        if [ "${#1}" -le "63" ]; then
    	echo $1
    	return
        fi
        sha=$(echo -n $1|$CHECKSUM_CMD)
        echo "${1:0:57}${sha:0:6}"
    }
    
    if [[ $# -ne 1 ]]; then
        echo "usage: ${BASH_SOURCE} restore-name"
        exit 1
    fi
    
    echo "restore: $1"
    
    label=$(label_name $1)
    echo "label:   $label"
    
    echo Deleting disconnected restore pods
    oc delete pods --all-namespaces -l oadp.openshift.io/disconnected-from-dc=$label
    
    for dc in $(oc get dc --all-namespaces -l oadp.openshift.io/replicas-modified=$label -o jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{","}{.metadata.annotations.oadp\.openshift\.io/original-replicas}{","}{.metadata.annotations.oadp\.openshift\.io/original-paused}{"\n"}')
    do
        IFS=',' read -ra dc_arr <<< "$dc"
        if [ ${#dc_arr[0]} -gt 0 ]; then
    	echo Found deployment ${dc_arr[0]}/${dc_arr[1]}, setting replicas: ${dc_arr[2]}, paused: ${dc_arr[3]}
    	cat <<EOF | oc patch dc  -n ${dc_arr[0]} ${dc_arr[1]} --patch-file /dev/stdin
    spec:
      replicas: ${dc_arr[2]}
      paused: ${dc_arr[3]}
    EOF
        fi
    done
4.9.1.3. 복원 후크 생성

Restore CR(사용자 정의 리소스)을 편집하여 Pod의 컨테이너에서 명령을 실행할 복원 후크를 생성합니다.

다음 두 가지 유형의 복원 후크를 생성할 수 있습니다.

  • init 후크는 애플리케이션 컨테이너가 시작되기 전에 설정 작업을 수행하기 위해 Pod에 init 컨테이너를 추가합니다.

    Restic 백업을 복원하면 복원 후크 init 컨테이너 앞에 restic-wait init 컨테이너가 추가됩니다.

  • exec 후크는 복원된 Pod의 컨테이너에서 명령 또는 스크립트를 실행합니다.

절차

  • 다음 예제와 같이 Restore CR의 spec.hooks 블록에 후크를 추가합니다.

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore>
      namespace: openshift-adp
    spec:
      hooks:
        resources:
          - name: <hook_name>
            includedNamespaces:
            - <namespace> 1
            excludedNamespaces:
            - <namespace>
            includedResources:
            - pods 2
            excludedResources: []
            labelSelector: 3
              matchLabels:
                app: velero
                component: server
            postHooks:
            - init:
                initContainers:
                - name: restore-hook-init
                  image: alpine:latest
                  volumeMounts:
                  - mountPath: /restores/pvc1-vm
                    name: pvc1-vm
                  command:
                  - /bin/ash
                  - -c
                timeout: 4
            - exec:
                container: <container> 5
                command:
                - /bin/bash 6
                - -c
                - "psql < /backup/backup.sql"
                waitTimeout: 5m 7
                execTimeout: 1m 8
                onError: Continue 9
    1
    선택 사항: 후크가 적용되는 네임스페이스 배열입니다. 이 값을 지정하지 않으면 후크가 모든 네임스페이스에 적용됩니다.
    2
    현재 Pod는 후크를 적용할 수 있는 유일한 지원 리소스입니다.
    3
    선택 사항: 이 후크는 라벨 선택기와 일치하는 오브젝트에만 적용됩니다.
    4
    선택 사항: 시간 초과는 Velero가 initContainers 가 완료될 때까지 대기하는 최대 시간을 지정합니다.
    5
    선택 사항: 컨테이너를 지정하지 않으면 Pod의 첫 번째 컨테이너에서 명령이 실행됩니다.
    6
    이는 추가 중인 init 컨테이너의 진입점입니다.
    7
    선택 사항: 컨테이너가 준비될 때까지 대기하는 시간입니다. 컨테이너가 시작되고 동일한 컨테이너의 이전 후크가 완료될 때까지 충분히 길어야 합니다. 설정하지 않으면 복원 프로세스가 무기한 대기합니다.
    8
    선택 사항: 명령을 실행할 때까지 대기하는 시간입니다. 기본값은 30s 입니다.
    9
    오류 처리에 허용되는 값은 FailContinue 입니다.
    • continue: 명령 실패만 기록합니다.
    • 실패: Pod의 모든 컨테이너에서 복구 후크를 더 이상 실행하지 않습니다. Restore CR의 상태는 partiallyFailed 입니다.
중요

FSB(파일 시스템 백업) 복원 작업 중에 ImageStream 을 참조하는 Deployment 리소스가 제대로 복원되지 않습니다. FSB를 실행하는 복원된 Pod 및 postHook 은 조기에 종료됩니다.

이는 복원 작업 중에 OpenShift 컨트롤러에서 업데이트된 ImageStreamTag 해시로 Deployment 리소스의 spec.template.spec.containers[0].image 필드를 업데이트하기 때문에 발생합니다. 이번 업데이트에서는 새 Pod의 롤아웃을 트리거하여 velero 가 FSB를 실행하는 Pod와 복원 후 후크를 종료합니다. 이미지 스트림 트리거에 대한 자세한 내용은 "이미지 스트림 변경에 대한 업데이트 트리거"를 참조하십시오.

이 동작에 대한 해결방법은 2단계 복원 프로세스입니다.

  1. 먼저 Deployment 리소스를 제외한 복원을 수행합니다. 예를 들면 다음과 같습니다.

    $ velero restore create <RESTORE_NAME> \
      --from-backup <BACKUP_NAME> \
      --exclude-resources=deployment.apps
  2. 첫 번째 복원이 성공한 후 다음 리소스를 포함하여 두 번째 복원을 수행합니다. 예를 들면 다음과 같습니다.

    $ velero restore create <RESTORE_NAME> \
      --from-backup <BACKUP_NAME> \
      --include-resources=deployment.apps

4.10. OADP 및 ROSA

4.10.1. OADP를 사용하여 ROSA 클러스터에서 애플리케이션 백업

ROSA(Red Hat OpenShift Service) 클러스터에서 OADP(OpenShift API for Data Protection)를 사용하여 애플리케이션 데이터를 백업하고 복원할 수 있습니다.

ROSA는 애플리케이션을 구축하고 배포하여 고객에게 가치를 제공할 수 있는 완전한 턴키 애플리케이션 플랫폼입니다.

ROSA는 다양한 AWS(Amazon Web Services) 컴퓨팅, 데이터베이스, 분석, 머신러닝, 네트워킹, 모바일 및 기타 서비스와 원활한 통합을 제공하여 고객에게 차별화된 경험의 구축 및 제공을 가속화합니다.

AWS 계정에서 직접 서비스에 등록할 수 있습니다.

클러스터를 생성한 후 OpenShift Container Platform 웹 콘솔 또는 Red Hat OpenShift Cluster Manager 를 통해 클러스터를 작동할 수 있습니다. ROSA를 OpenShift API 및 CLI(명령줄 인터페이스) 툴과 함께 사용할 수도 있습니다.

ROSA 설치에 대한 자세한 내용은 AWS(ROSA) 대화형 방법에 대한 Red Hat OpenShift Service 설치를 참조하십시오.

OADP(OpenShift API for Data Protection)를 설치하기 전에 Amazon Web Services API를 사용할 수 있도록 OADP의 역할 및 정책 자격 증명을 설정해야 합니다.

이 프로세스는 다음 두 단계로 수행됩니다.

  1. AWS 인증 정보 준비
  2. OADP Operator를 설치하고 IAM 역할을 제공합니다.
4.10.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}"
    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
      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
      1
      SCRATCH 는 환경 변수에 대해 생성된 임시 디렉터리의 이름입니다.
    3. 다음 명령을 실행하여 정책 ARN을 확인합니다.

      $ echo ${POLICY_ARN}
  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
    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)
    3. 다음 명령을 실행하여 역할 ARN을 확인합니다.

      $ echo ${ROLE_ARN}
  4. 다음 명령을 실행하여 IAM 역할에 IAM 정책을 연결합니다.

    $ aws iam attach-role-policy --role-name "${ROLE_NAME}" \
      --policy-arn ${POLICY_ARN}
4.10.1.2. OADP Operator 설치 및 IAM 역할 제공

AWS STS(보안 토큰 서비스)는 IAM 또는 페더레이션 사용자를 위한 단기 자격 증명을 제공하는 글로벌 웹 서비스입니다. STS가 있는 ROSA(OpenShift Container Platform)는 ROSA 클러스터에 권장되는 인증 정보 모드입니다. 이 문서에서는 AWS STS를 사용하여 ROSA에 OADP(OpenShift API for Data Protection)를 설치하는 방법을 설명합니다.

중요

Restic은 지원되지 않습니다.

CSI(Container Storage Interface) 스냅샷이 지원되지 않는 파일 시스템을 백업할 때 Kopia 파일 시스템 백업(FSB)이 지원됩니다.

예제 파일 시스템에는 다음이 포함됩니다.

  • Amazon Elastic File System (EFS)
  • 네트워크 파일 시스템(NFS)
  • emptyDir 볼륨
  • 로컬 볼륨

볼륨 백업의 경우 AWS STS를 사용하여 ROSA의 OADP는 기본 스냅샷 및 CSI(Container Storage Interface) 스냅샷만 지원합니다.

STS 인증을 사용하는 Amazon ROSA 클러스터에서는 다른 AWS 리전에서 백업 데이터를 복원할 수 없습니다.

Data Mover 기능은 현재 ROSA 클러스터에서 지원되지 않습니다. 데이터 이동을 위해 기본 AWS S3 툴을 사용할 수 있습니다.

사전 요구 사항

  • 필요한 액세스 및 토큰이 있는 OpenShift Container Platform ROSA 클러스터 자세한 내용은 OADP에 대한 AWS 인증 정보 준비 절차를 참조하십시오. 백업 및 복원을 위해 두 개의 다른 클러스터를 사용하려면 각 클러스터에 대해 ROLE_ARN 을 포함한 AWS 인증 정보를 준비해야 합니다.

절차

  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
      1
      & lt;aws_region >을 STS 끝점에 사용할 AWS 리전으로 바꿉니다.
    2. OADP의 네임스페이스를 생성합니다.

      $ oc create namespace openshift-adp
    3. OpenShift Container Platform 시크릿을 생성합니다.

      $ oc -n openshift-adp create secret generic cloud-credentials \
        --from-file=${SCRATCH}/credentials
      참고

      OpenShift Container Platform 버전 4.14 이상에서 OADP Operator는 OLM(Operator Lifecycle Manager) 및 CCO(Cloud Credentials Operator)를 통해 새로운 표준화된 STS 워크플로를 지원합니다. 이 워크플로우에서는 OpenShift Container Platform 웹 콘솔을 사용하여 OLM 관리 Operator를 설치하는 동안 위의 시크릿을 생성할 필요가 없습니다. 자세한 내용은 웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.

      이전 시크릿은 CCO에 의해 자동으로 생성됩니다.

  2. OADP Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub 로 이동합니다.
    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
  4. 다음 명령을 입력하여 애플리케이션의 스토리지 기본 스토리지 클래스를 확인합니다.

    $ oc get pvc -n <namespace>

    출력 예

    NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    applog   Bound    pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8   1Gi        RWO            gp3-csi        4d19h
    mysql    Bound    pvc-16b8e009-a20a-4379-accc-bc81fedd0621   1Gi        RWO            gp3-csi        4d19h

  5. 다음 명령을 실행하여 스토리지 클래스를 가져옵니다.

    $ oc get storageclass

    출력 예

    NAME                PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    gp2                 kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   true                   4d21h
    gp2-csi             ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3                 ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3-csi (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h

    참고

    다음 스토리지 클래스가 작동합니다.

    • gp3-csi
    • gp2-csi
    • gp3
    • gp2

    백업 중인 애플리케이션 또는 애플리케이션이 모두 CSI(Container Storage Interface)를 사용하는 PV(영구 볼륨)를 사용하는 경우 OADP DPA 구성에 CSI 플러그인을 포함하는 것이 좋습니다.

  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
      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
    1
    ROSA는 내부 이미지 백업을 지원합니다. 이미지 백업을 사용하지 않으려면 이 필드를 false로 설정합니다.
    2
    nodeAgent 속성과 관련된 중요한 노트를 참조하십시오.
    3
    credentialsFile 필드는 Pod에 버킷 인증 정보의 마운트된 위치입니다.
    4
    enableSharedConfig 필드를 사용하면 snapshotLocations 에서 버킷에 대해 정의된 인증 정보를 공유하거나 재사용할 수 있습니다.
    5
    AWS 인증 정보 파일에 설정된 프로필 이름을 사용합니다.
    6
    리전을 AWS 리전 으로 지정합니다. 이는 클러스터 리전과 동일해야 합니다.

    이제 애플리케이션 백업에 설명된 대로 OpenShift Container Platform 애플리케이션을 백업 하고 복원할 준비가 되었습니다.

중요

OADP가 ROSA 환경에서 Restic을 지원하지 않기 때문에 resticenable 매개변수는 이 구성에서 false 로 설정됩니다.

OADP 1.2를 사용하는 경우 이 구성을 교체합니다.

nodeAgent:
  enable: false
  uploaderType: restic

다음 구성에서는 다음을 수행합니다.

restic:
  enable: false

백업 및 복원을 위해 두 개의 다른 클러스터를 사용하려면 클라우드 스토리지 CR과 OADP DataProtectionApplication 구성 둘 다에 동일한 AWS S3 스토리지 이름이 있어야 합니다.

4.10.1.3. 예: 선택적 정리를 사용하여 OADP ROSA STS에서 워크로드 백업
4.10.1.3.1. OADP 및 ROSA STS로 백업 수행

다음 예제 hello-world 애플리케이션에는 PV(영구 볼륨)가 연결되어 있지 않습니다. ROSA(Red Hat OpenShift Service on AWS) STS를 사용하여 OADP(OpenShift API for Data Protection)를 사용하여 백업을 수행합니다.

DPA(Data Protection Application) 구성이 작동합니다.

  1. 다음 명령을 실행하여 백업할 워크로드를 생성합니다.

    $ oc create namespace hello-world
    $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
  2. 다음 명령을 실행하여 경로를 노출합니다.

    $ oc expose service/hello-openshift -n hello-world
  3. 다음 명령을 실행하여 애플리케이션이 작동하는지 확인합니다.

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

    출력 예

    Hello OpenShift!

  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
  5. 백업이 완료될 때까지 기다린 후 다음 명령을 실행합니다.

    $ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"

    출력 예

    {
      "completionTimestamp": "2022-09-07T22:20:44Z",
      "expiration": "2022-10-07T22:20:22Z",
      "formatVersion": "1.1.0",
      "phase": "Completed",
      "progress": {
        "itemsBackedUp": 58,
        "totalItems": 58
      },
      "startTimestamp": "2022-09-07T22:20:22Z",
      "version": 1
    }

  6. 다음 명령을 실행하여 데모 워크로드를 삭제합니다.

    $ oc delete ns hello-world
  7. 다음 명령을 실행하여 백업에서 워크로드를 복원합니다.

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Restore
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        backupName: hello-world
    EOF
  8. 다음 명령을 실행하여 복원이 완료될 때까지 기다립니다.

    $ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"

    출력 예

    {
      "completionTimestamp": "2022-09-07T22:25:47Z",
      "phase": "Completed",
      "progress": {
        "itemsRestored": 38,
        "totalItems": 38
      },
      "startTimestamp": "2022-09-07T22:25:28Z",
      "warnings": 9
    }

  9. 다음 명령을 실행하여 워크로드가 복원되었는지 확인합니다.

    $ oc -n hello-world get pods

    출력 예

    NAME                              READY   STATUS    RESTARTS   AGE
    hello-openshift-9f885f7c6-kdjpj   1/1     Running   0          90s

  10. 다음 명령을 실행하여 JSONPath를 확인합니다.

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

    출력 예

    Hello OpenShift!

참고

문제 해결 팁은 OADP 팀의 문제 해결 설명서를 참조하십시오.

4.10.1.3.2. OADP 및 ROSA STS를 사용하여 백업 후 클러스터 정리

이 예제에서 OADP(OpenShift API for Data Protection) Operator를 백업 및 S3 버킷과 함께 설치 제거해야 하는 경우 다음 지침을 따르십시오.

절차

  1. 다음 명령을 실행하여 워크로드를 삭제합니다.

    $ oc delete ns hello-world
  2. 다음 명령을 실행하여 DPA(데이터 보호 애플리케이션)를 삭제합니다.

    $ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
  3. 다음 명령을 실행하여 클라우드 스토리지를 삭제합니다.

    $ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
    주의

    이 명령이 중단되면 다음 명령을 실행하여 종료자를 삭제해야 할 수 있습니다.

    $ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
  4. Operator가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 Operator를 제거합니다.

    $ oc -n openshift-adp delete subscription oadp-operator
  5. Operator에서 네임스페이스를 제거합니다.

    $ oc delete ns openshift-adp
  6. 백업 및 복원 리소스가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 리소스를 제거합니다.

    $ oc delete backups.velero.io hello-world
  7. AWS S3에서 백업, 복원 및 원격 오브젝트를 삭제하려면 다음 명령을 실행합니다.

    $ velero backup delete hello-world
  8. 더 이상 CRD(Custom Resource Definitions)가 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 정의를 제거하십시오.

    $ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
  9. 다음 명령을 실행하여 AWS S3 버킷을 삭제합니다.

    $ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
    $ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
  10. 다음 명령을 실행하여 역할에서 정책을 분리합니다.

    $ aws iam detach-role-policy --role-name "${ROLE_NAME}"  --policy-arn "${POLICY_ARN}"
  11. 다음 명령을 실행하여 역할을 삭제합니다.

    $ aws iam delete-role --role-name "${ROLE_NAME}"

4.11. OADP 및 AWS STS

4.11.1. OADP를 사용하여 AWS STS에서 애플리케이션 백업

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

참고

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

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

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

AWS STS(AWS STS) 클러스터에 OADP를 수동으로 설치할 수 있습니다. Amazon AWS는 사용자가 제한된 임시 자격 증명을 요청할 수 있는 웹 서비스로 AWS STS를 제공합니다. STS를 사용하여 신뢰할 수 있는 사용자에게 API 호출, AWS 콘솔 또는 AWS CLI(명령줄 인터페이스)를 통해 리소스에 대한 임시 액세스를 제공합니다.

OADP(OpenShift API for Data Protection)를 설치하기 전에 Amazon Web Services API를 사용할 수 있도록 OADP의 역할 및 정책 자격 증명을 설정해야 합니다.

이 프로세스는 다음 두 단계로 수행됩니다.

  1. AWS 인증 정보를 준비합니다.
  2. OADP Operator를 설치하고 IAM 역할을 부여합니다.
4.11.1.1. OADP의 AWS STS 인증 정보 준비

Amazon Web Services 계정은 OADP(OpenShift API for Data Protection) 설치를 허용하도록 준비하고 구성해야 합니다. 다음 절차를 사용하여 AWS 인증 정보를 준비합니다.

절차

  1. 다음 명령을 실행하여 cluster_name 환경 변수를 정의합니다.

    $ export CLUSTER_NAME= <AWS_cluster_name> 1
    1
    변수는 임의의 값으로 설정할 수 있습니다.
  2. 다음 명령을 실행하여 AWS_ACCOUNT_ID, OIDC_ENDPOINT 와 같은 클러스터 의 모든 세부 정보를 검색합니다.

    $ export CLUSTER_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')
    
    export AWS_CLUSTER_ID=$(oc get clusterversion version -o jsonpath='{.spec.clusterID}{"\n"}')
    
    export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed 's|^https://||')
    
    export REGION=$(oc get infrastructures cluster -o jsonpath='{.status.platformStatus.aws.region}' --allow-missing-template-keys=false || echo us-east-2)
    
    export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
    
    export ROLE_NAME="${CLUSTER_NAME}-openshift-oadp-aws-cloud-credentials"
  3. 다음 명령을 실행하여 모든 파일을 저장할 임시 디렉터리를 생성합니다.

    $ export SCRATCH="/tmp/${CLUSTER_NAME}/oadp"
    mkdir -p ${SCRATCH}
  4. 다음 명령을 실행하여 수집된 모든 세부 정보를 표시합니다.

    $ echo "Cluster ID: ${AWS_CLUSTER_ID}, Region: ${REGION}, OIDC Endpoint:
    ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"
  5. AWS 계정에서 AWS S3에 대한 액세스를 허용하는 IAM 정책을 생성합니다.

    1. 다음 명령을 실행하여 정책이 존재하는지 확인합니다.

      $ export POLICY_NAME="OadpVer1" 1
      1
      변수는 임의의 값으로 설정할 수 있습니다.
      $ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='$POLICY_NAME'].{ARN:Arn}" --output text)
    2. 다음 명령을 입력하여 정책 JSON 파일을 생성한 다음 정책을 생성합니다.

      참고

      정책 ARN을 찾을 수 없는 경우 명령에서 정책을 생성합니다. 정책 ARN이 이미 존재하는 경우 if 문이 의도적으로 정책 생성을 건너뜁니다.

      $ if [[ -z "${POLICY_ARN}" ]]; then
      cat << EOF > ${SCRATCH}/policy.json
      {
      "Version": "2012-10-17",
      "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:CreateBucket",
           "s3:DeleteBucket",
           "s3:PutBucketTagging",
           "s3:GetBucketTagging",
           "s3:PutEncryptionConfiguration",
           "s3:GetEncryptionConfiguration",
           "s3:PutLifecycleConfiguration",
           "s3:GetLifecycleConfiguration",
           "s3:GetBucketLocation",
           "s3:ListBucket",
           "s3:GetObject",
           "s3:PutObject",
           "s3:DeleteObject",
           "s3:ListBucketMultipartUploads",
           "s3:AbortMultipartUpload",
           "s3:ListMultipartUploadParts",
           "ec2:DescribeSnapshots",
           "ec2:DescribeVolumes",
           "ec2:DescribeVolumeAttribute",
           "ec2:DescribeVolumesModifications",
           "ec2:DescribeVolumeStatus",
           "ec2:CreateTags",
           "ec2:CreateVolume",
           "ec2:CreateSnapshot",
           "ec2:DeleteSnapshot"
         ],
         "Resource": "*"
       }
      ]}
      EOF
      
      POLICY_ARN=$(aws iam create-policy --policy-name $POLICY_NAME \
      --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \
      --tags Key=openshift_version,Value=${CLUSTER_VERSION} Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=oadp \
      --output text) 1
      fi
      1
      SCRATCH 는 파일을 저장하기 위해 생성된 임시 디렉터리의 이름입니다.
    3. 다음 명령을 실행하여 정책 ARN을 확인합니다.

      $ echo ${POLICY_ARN}
  6. 클러스터에 대한 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
    2. 다음 명령을 실행하여 클러스터에 대한 IAM 역할 신뢰 정책을 생성합니다.

      $ ROLE_ARN=$(aws iam create-role --role-name \
        "${ROLE_NAME}" \
        --assume-role-policy-document file://${SCRATCH}/trust-policy.json \
        --tags Key=cluster_id,Value=${AWS_CLUSTER_ID}  Key=openshift_version,Value=${CLUSTER_VERSION} Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=oadp --query Role.Arn --output text)
    3. 다음 명령을 실행하여 역할 ARN을 확인합니다.

      $ echo ${ROLE_ARN}
  7. 다음 명령을 실행하여 IAM 역할에 IAM 정책을 연결합니다.

    $ aws iam attach-role-policy --role-name "${ROLE_NAME}" --policy-arn ${POLICY_ARN}
4.11.1.1.1. Velero CPU 및 메모리 리소스 할당 설정

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

사전 요구 사항

  • OADP(Data Protection) Operator가 설치되어 있어야 합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector> 1
            resourceAllocations: 2
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi
    1
    Velero podSpec에 제공할 노드 선택기를 지정합니다.
    2
    나열된 resourceAllocations 는 평균 사용량입니다.
참고

Kopia는 OADP 1.3 이상 릴리스에서 옵션입니다. Kopia를 파일 시스템 백업에 사용할 수 있으며, Kopia는 기본 제공 Data Mover 사례에서만 사용할 수 있습니다.

Kopia는 Restic보다 리소스 집약적이므로 그에 따라 CPU 및 메모리 요구 사항을 조정해야 할 수 있습니다.

4.11.1.2. OADP Operator 설치 및 IAM 역할 제공

AWS STS(보안 토큰 서비스)는 IAM 또는 페더레이션 사용자를 위한 단기 자격 증명을 제공하는 글로벌 웹 서비스입니다. 이 문서에서는 AWS STS 클러스터에 OADP(OpenShift API for Data Protection)를 수동으로 설치하는 방법을 설명합니다.

중요

Restic 및 Kopia는 OADP AWS STS 환경에서 지원되지 않습니다. Restic 및 Kopia 노드 에이전트가 비활성화되어 있는지 확인합니다. 볼륨 백업의 경우 AWS STS의 OADP는 기본 스냅샷 및 CSI(Container Storage Interface) 스냅샷만 지원합니다.

STS 인증을 사용하는 AWS 클러스터에서는 다른 AWS 리전에서 백업 데이터를 복원할 수 없습니다.

데이터 Mover 기능은 현재 AWS STS 클러스터에서 지원되지 않습니다. 데이터 이동을 위해 기본 AWS S3 툴을 사용할 수 있습니다.

사전 요구 사항

  • 필요한 액세스 및 토큰이 있는 OpenShift Container Platform AWS STS 클러스터 자세한 내용은 OADP에 대한 AWS 인증 정보 준비 절차를 참조하십시오. 백업 및 복원을 위해 두 개의 다른 클러스터를 사용하려면 각 클러스터에 대해 ROLE_ARN 을 포함한 AWS 인증 정보를 준비해야 합니다.

절차

  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
      EOF
    2. OADP의 네임스페이스를 생성합니다.

      $ oc create namespace openshift-adp
    3. OpenShift Container Platform 시크릿을 생성합니다.

      $ oc -n openshift-adp create secret generic cloud-credentials \
        --from-file=${SCRATCH}/credentials
      참고

      OpenShift Container Platform 버전 4.14 이상에서 OADP Operator는 OLM(Operator Lifecycle Manager) 및 CCO(Cloud Credentials Operator)를 통해 새로운 표준화된 STS 워크플로를 지원합니다. 이 워크플로우에서는 OpenShift Container Platform 웹 콘솔을 사용하여 OLM 관리 Operator를 설치하는 동안 위의 시크릿을 생성할 필요가 없습니다. 자세한 내용은 웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.

      이전 시크릿은 CCO에 의해 자동으로 생성됩니다.

  2. OADP Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub 로 이동합니다.
    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
  4. 다음 명령을 입력하여 애플리케이션의 스토리지 기본 스토리지 클래스를 확인합니다.

    $ oc get pvc -n <namespace>

    출력 예

    NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    applog   Bound    pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8   1Gi        RWO            gp3-csi        4d19h
    mysql    Bound    pvc-16b8e009-a20a-4379-accc-bc81fedd0621   1Gi        RWO            gp3-csi        4d19h

  5. 다음 명령을 실행하여 스토리지 클래스를 가져옵니다.

    $ oc get storageclass

    출력 예

    NAME                PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    gp2                 kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   true                   4d21h
    gp2-csi             ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3                 ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3-csi (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h

    참고

    다음 스토리지 클래스가 작동합니다.

    • gp3-csi
    • gp2-csi
    • gp3
    • gp2

    백업 중인 애플리케이션 또는 애플리케이션이 모두 CSI(Container Storage Interface)를 사용하는 PV(영구 볼륨)를 사용하는 경우 OADP DPA 구성에 CSI 플러그인을 포함하는 것이 좋습니다.

  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
            restic:
              enable: false
      EOF
      1
      이미지 백업을 사용하지 않으려면 이 필드를 false 로 설정합니다.
  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
        features:
          dataMover:
             enable: false
        backupLocations:
        - bucket:
            cloudStorageRef:
              name: ${CLUSTER_NAME}-oadp
            credential:
              key: credentials
              name: cloud-credentials
            prefix: velero
            default: true
            config:
              region: ${REGION}
        configuration:
          velero:
            defaultPlugins:
            - openshift
            - aws
          nodeAgent: 2
            enable: false
            uploaderType: restic
        snapshotLocations:
          - velero:
              config:
                credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials 3
                enableSharedConfig: "true" 4
                profile: default 5
                region: ${REGION} 6
              provider: aws
    EOF
    1
    이미지 백업을 사용하지 않으려면 이 필드를 false 로 설정합니다.
    2
    nodeAgent 속성과 관련된 중요한 노트를 참조하십시오.
    3
    credentialsFile 필드는 Pod에 버킷 인증 정보의 마운트된 위치입니다.
    4
    enableSharedConfig 필드를 사용하면 snapshotLocations 에서 버킷에 대해 정의된 인증 정보를 공유하거나 재사용할 수 있습니다.
    5
    AWS 인증 정보 파일에 설정된 프로필 이름을 사용합니다.
    6
    리전을 AWS 리전 으로 지정합니다. 이는 클러스터 리전과 동일해야 합니다.

    이제 애플리케이션 백업에 설명된 대로 OpenShift Container Platform 애플리케이션을 백업 하고 복원할 준비가 되었습니다.

중요

OADP 1.2를 사용하는 경우 이 구성을 교체합니다.

nodeAgent:
  enable: false
  uploaderType: restic

다음 구성에서는 다음을 수행합니다.

restic:
  enable: false

백업 및 복원을 위해 두 개의 다른 클러스터를 사용하려면 클라우드 스토리지 CR과 OADP DataProtectionApplication 구성 둘 다에 동일한 AWS S3 스토리지 이름이 있어야 합니다.

4.11.1.3. 선택적 정리를 사용하여 OADP AWS STS에서 워크로드 백업
4.11.1.3.1. OADP 및 AWS STS로 백업 수행

다음 예제 hello-world 애플리케이션에는 PV(영구 볼륨)가 연결되어 있지 않습니다. AWS(Amazon Web Services)를 사용하여 OADP(OpenShift API for Data Protection)로 백업을 수행합니다.

DPA(Data Protection Application) 구성이 작동합니다.

  1. 다음 명령을 실행하여 백업할 워크로드를 생성합니다.

    $ oc create namespace hello-world
    $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
  2. 다음 명령을 실행하여 경로를 노출합니다.

    $ oc expose service/hello-openshift -n hello-world
  3. 다음 명령을 실행하여 애플리케이션이 작동하는지 확인합니다.

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

    출력 예

    Hello OpenShift!

  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
  5. 백업이 완료될 때까지 기다린 후 다음 명령을 실행합니다.

    $ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"

    출력 예

    {
      "completionTimestamp": "2022-09-07T22:20:44Z",
      "expiration": "2022-10-07T22:20:22Z",
      "formatVersion": "1.1.0",
      "phase": "Completed",
      "progress": {
        "itemsBackedUp": 58,
        "totalItems": 58
      },
      "startTimestamp": "2022-09-07T22:20:22Z",
      "version": 1
    }

  6. 다음 명령을 실행하여 데모 워크로드를 삭제합니다.

    $ oc delete ns hello-world
  7. 다음 명령을 실행하여 백업에서 워크로드를 복원합니다.

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Restore
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        backupName: hello-world
    EOF
  8. 다음 명령을 실행하여 복원이 완료될 때까지 기다립니다.

    $ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"

    출력 예

    {
      "completionTimestamp": "2022-09-07T22:25:47Z",
      "phase": "Completed",
      "progress": {
        "itemsRestored": 38,
        "totalItems": 38
      },
      "startTimestamp": "2022-09-07T22:25:28Z",
      "warnings": 9
    }

  9. 다음 명령을 실행하여 워크로드가 복원되었는지 확인합니다.

    $ oc -n hello-world get pods

    출력 예

    NAME                              READY   STATUS    RESTARTS   AGE
    hello-openshift-9f885f7c6-kdjpj   1/1     Running   0          90s

  10. 다음 명령을 실행하여 JSONPath를 확인합니다.

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

    출력 예

    Hello OpenShift!

참고

문제 해결 팁은 OADP 팀의 문제 해결 설명서를 참조하십시오.

4.11.1.3.2. OADP 및 AWS STS를 사용하여 백업 후 클러스터 정리

이 예제에서 OADP(OpenShift API for Data Protection) Operator를 백업 및 S3 버킷과 함께 설치 제거해야 하는 경우 다음 지침을 따르십시오.

절차

  1. 다음 명령을 실행하여 워크로드를 삭제합니다.

    $ oc delete ns hello-world
  2. 다음 명령을 실행하여 DPA(데이터 보호 애플리케이션)를 삭제합니다.

    $ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
  3. 다음 명령을 실행하여 클라우드 스토리지를 삭제합니다.

    $ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
    중요

    이 명령이 중단되면 다음 명령을 실행하여 종료자를 삭제해야 할 수 있습니다.

    $ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
  4. Operator가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 Operator를 제거합니다.

    $ oc -n openshift-adp delete subscription oadp-operator
  5. 다음 명령을 실행하여 Operator에서 네임스페이스를 제거합니다.

    $ oc delete ns openshift-adp
  6. 백업 및 복원 리소스가 더 이상 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 리소스를 제거합니다.

    $ oc delete backups.velero.io hello-world
  7. AWS S3에서 백업, 복원 및 원격 오브젝트를 삭제하려면 다음 명령을 실행합니다.

    $ velero backup delete hello-world
  8. 더 이상 CRD(Custom Resource Definitions)가 필요하지 않은 경우 다음 명령을 실행하여 클러스터에서 해당 정의를 제거하십시오.

    $ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
  9. 다음 명령을 실행하여 AWS S3 버킷을 삭제합니다.

    $ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
    $ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
  10. 다음 명령을 실행하여 역할에서 정책을 분리합니다.

    $ aws iam detach-role-policy --role-name "${ROLE_NAME}"  --policy-arn "${POLICY_ARN}"
  11. 다음 명령을 실행하여 역할을 삭제합니다.

    $ aws iam delete-role --role-name "${ROLE_NAME}"

4.12. OADP 데이터 Mover

4.12.1. OADP Data Mover 정보

OADP(OpenShift API for Data Protection)에는 CSI(Container Storage Interface) 볼륨 스냅샷을 원격 오브젝트 저장소로 이동하는 데 사용할 수 있는 기본 제공 데이터 Mover가 포함되어 있습니다. 기본 제공 Data Mover를 사용하면 오류, 실수로 삭제 또는 클러스터 손상이 발생하는 경우 원격 오브젝트 저장소에서 상태 저장 애플리케이션을 복원할 수 있습니다. Kopia 를 업로드기 메커니즘으로 사용하여 스냅샷 데이터를 읽고 통합 리포지토리에 씁니다.

OADP는 다음에서 CSI 스냅샷을 지원합니다.

  • {odf-full}
  • Kubernetes Volume Snapshot API를 지원하는 CSI(Container Storage Interface) 드라이버가 있는 기타 클라우드 스토리지 공급자
4.12.1.1. Data Mover 지원

OADP 1.3에 기술 프리뷰로 도입된 OADP 내장 데이터 Mover는 이제 컨테이너화된 및 가상 머신 워크로드 모두에 대해 완전히 지원됩니다.

지원됨

OADP 1.3으로 가져온 데이터 Mover 백업은 OADP 1.3, 1.4 이상을 사용하여 복원할 수 있습니다. 이는 지원됩니다.

지원되지 않음

Data Mover 기능을 사용하여 OADP 1.1 또는 OADP 1.2로 가져온 백업은 OADP 1.3 이상을 사용하여 복원할 수 없습니다. 따라서 지원되지 않습니다.

OADP 1.1 및 OADP 1.2는 더 이상 지원되지 않습니다. OADP 1.1 또는 OADP 1.2의 DataMover 기능은 기술 프리뷰였으며 지원되지 않았습니다. OADP 1.1 또는 OADP 1.2로 가져온 DataMover 백업은 이후 버전의 OADP에서 복원할 수 없습니다.

4.12.1.2. 기본 제공 데이터 Mover 활성화

기본 제공 데이터 Mover를 활성화하려면 CSI 플러그인을 포함하고 DataProtectionApplication CR(사용자 정의 리소스)에서 노드 에이전트를 활성화해야 합니다. 노드 에이전트는 데이터 이동 모듈을 호스팅하는 Kubernetes 데몬 세트입니다. 여기에는 데이터 Mover 컨트롤러, 업로드자 및 리포지토리가 포함됩니다.

DataProtectionApplication 매니페스트의 예

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: dpa-sample
spec:
  configuration:
    nodeAgent:
      enable: true 1
      uploaderType: kopia 2
    velero:
      defaultPlugins:
      - openshift
      - aws
      - csi 3
      defaultSnapshotMoveData: true
      defaultVolumesToFSBackup: 4
      featureFlags:
      - EnableCSI
# ...

1
노드 에이전트를 활성화하는 플래그입니다.
2
uploader 유형입니다. 가능한 값은 restic 또는 kopia 입니다. 기본 제공 Data Mover는 uploaderType 필드의 값에 관계없이 Kopia를 기본 업로드기 메커니즘으로 사용합니다.
3
기본 플러그인 목록에 포함된 CSI 플러그인입니다.
4
OADP 1.3.1 이상에서는 fs-backup 을 옵트아웃하는 볼륨에만 Data Mover를 사용하는 경우 true 로 설정합니다. 볼륨에 대해 기본적으로 Data Mover를 사용하는 경우 false 로 설정합니다.
4.12.1.3. 기본 제공 데이터 Mover 컨트롤러 및 CRD(사용자 정의 리소스 정의)

기본 제공 Data Mover 기능에는 백업 및 복원을 관리하기 위해 CRD로 정의된 새로운 API 오브젝트 3개가 도입되었습니다.

  • DataDownload: 볼륨 스냅샷의 데이터 다운로드를 나타냅니다. CSI 플러그인은 복원할 볼륨당 하나의 DataDownload 오브젝트를 생성합니다. DataDownload CR에는 대상 볼륨, 지정된 데이터 Mover, 현재 데이터 다운로드의 진행 상황, 지정된 백업 리포지토리 및 프로세스가 완료된 후 현재 데이터 다운로드 결과가 포함됩니다.
  • DataUpload: 볼륨 스냅샷의 데이터 업로드를 나타냅니다. CSI 플러그인은 CSI 스냅샷당 하나의 DataUpload 오브젝트를 생성합니다. DataUpload CR에는 지정된 스냅샷, 지정된 데이터 Mover, 지정된 백업 리포지토리, 현재 데이터 업로드 진행률, 프로세스가 완료된 후 현재 데이터 업로드 결과가 포함됩니다.
  • BackupRepository: 백업 리포지토리의 라이프사이클을 나타내며 관리합니다. OADP는 네임스페이스에 대한 첫 번째 CSI 스냅샷 백업 또는 복원이 요청되면 네임스페이스당 백업 리포지토리를 생성합니다.
4.12.1.4. 증분 백업 지원 정보

OADP는 컨테이너화된 워크로드와 OpenShift Virtualization 워크로드 모두에 대해 블록Filesystem 영구 볼륨의 증분 백업을 지원합니다. 다음 표에는 파일 시스템 백업(FSB), CSI(Container Storage Interface) 및 CSI 데이터 Mover에 대한 지원이 요약되어 있습니다.

표 4.6. 컨테이너화된 워크로드에 대한 OADP 백업 지원 매트릭스
볼륨 모드FSB - ResticFSB - KopiaCSICSI 데이터 Mover

파일 시스템

S [1], I [2]

S [1], I [2]

S [1]

S [1], I [2]

블록

N [3]

N [3]

S [1]

S [1], I [2]

표 4.7. OpenShift Virtualization 워크로드에 대한 OADP 백업 지원 매트릭스
볼륨 모드FSB - ResticFSB - KopiaCSICSI 데이터 Mover

파일 시스템

N [3]

N [3]

S [1]

S [1], I [2]

블록

N [3]

N [3]

S [1]

S [1], I [2]

  1. 지원되는 백업
  2. 증분 백업 지원
  3. 지원되지 않음
참고

CSI Data Mover 백업은 uploaderType 과 관계없이 Kopia를 사용합니다.

4.12.2. CSI 스냅샷 데이터 이동 백업 및 복원

OADP 1.3 Data Mover를 사용하여 영구 볼륨을 백업하고 복원할 수 있습니다.

4.12.2.1. CSI 스냅샷을 사용하여 영구 볼륨 백업

OADP 데이터 Mover를 사용하여 CSI(Container Storage Interface) 볼륨 스냅샷을 원격 오브젝트 저장소에 백업할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할을 사용하여 클러스터에 액세스할 수 있습니다.
  • OADP Operator가 설치되어 있습니다.
  • CSI 플러그인을 포함하고 DataProtectionApplication CR(사용자 정의 리소스)에 노드 에이전트를 활성화했습니다.
  • 별도의 네임스페이스에서 영구 볼륨이 실행되는 애플리케이션이 있습니다.
  • metadata.labels.velero.io/csi-volumesnapshot-class: "true" 키-값 쌍을 VolumeSnapshotClass CR에 추가했습니다.

절차

  1. 다음 예와 같이 Backup 오브젝트에 대한 YAML 파일을 생성합니다.

    Backup CR의 예

    kind: Backup
    apiVersion: velero.io/v1
    metadata:
      name: backup
      namespace: openshift-adp
    spec:
      csiSnapshotTimeout: 10m0s
      defaultVolumesToFsBackup: 1
      includedNamespaces:
      - mysql-persistent
      itemOperationTimeout: 4h0m0s
      snapshotMoveData: true 2
      storageLocation: default
      ttl: 720h0m0s 3
      volumeSnapshotLocations:
      - dpa-sample-1
    # ...

    1
    fs-backup 에서 옵트아웃하는 볼륨에만 Data Mover를 사용하는 경우 true 로 설정합니다. 볼륨에 대해 기본적으로 Data Mover를 사용하는 경우 false 로 설정합니다.
    2
    CSI 스냅샷을 원격 오브젝트 스토리지로 이동하려면 true 로 설정합니다.
    3
    ttl 필드는 생성된 백업의 보존 시간과 백업 데이터를 정의합니다. 예를 들어 Restic을 백업 도구로 사용하는 경우 백업이 만료될 때까지 백업된 데이터 항목과 PV(영구 볼륨)의 데이터 콘텐츠가 저장됩니다. 그러나 이러한 데이터를 저장하면 대상 백업 위치에 더 많은 공간이 사용됩니다. 추가 스토리지는 만료되지 않은 다른 완료된 백업이 시간 초과되었을 수 있기 전에 생성되는 빈번한 백업과 함께 사용됩니다.
    참고

    XFS 파일 시스템을 사용하여 볼륨을 포맷하고 볼륨이 100%인 경우 장치 오류에 남아 있는 공간이 없는 상태에서 백업이 실패합니다. 예를 들면 다음과 같습니다.

    Error: relabel failed /var/lib/kubelet/pods/3ac..34/volumes/ \
    kubernetes.io~csi/pvc-684..12c/mount: lsetxattr /var/lib/kubelet/ \
    pods/3ac..34/volumes/kubernetes.io~csi/pvc-68..2c/mount/data-xfs-103: \
    no space left on device

    이 시나리오에서는 백업이 성공적으로 완료되도록 볼륨 크기 조정 또는 다른 파일 시스템 유형(예: ext4 )을 사용하는 것이 좋습니다.

  2. 매니페스트를 적용합니다.

    $ oc create -f backup.yaml

    DataUpload CR은 스냅샷 생성이 완료된 후 생성됩니다.

검증

  • DataUpload CR의 status.phase 필드를 모니터링하여 스냅샷 데이터가 원격 오브젝트 저장소로 성공적으로 전송되었는지 확인합니다. 가능한 값은 진행 중 ,완료됨,실패 또는 취소됨 입니다. 오브젝트 저장소는 DataProtectionApplication CR의 backupLocations 스탠자에 구성됩니다.

    • 다음 명령을 실행하여 모든 DataUpload 오브젝트 목록을 가져옵니다.

      $ oc get datauploads -A

      출력 예

      NAMESPACE       NAME                  STATUS      STARTED   BYTES DONE   TOTAL BYTES   STORAGE LOCATION   AGE     NODE
      openshift-adp   backup-test-1-sw76b   Completed   9m47s     108104082    108104082     dpa-sample-1       9m47s   ip-10-0-150-57.us-west-2.compute.internal
      openshift-adp   mongo-block-7dtpf     Completed   14m       1073741824   1073741824    dpa-sample-1       14m     ip-10-0-150-57.us-west-2.compute.internal

    • 다음 명령을 실행하여 특정 DataUpload 오브젝트의 status.phase 필드 값을 확인합니다.

      $ oc get datauploads <dataupload_name> -o yaml

      출력 예

      apiVersion: velero.io/v2alpha1
      kind: DataUpload
      metadata:
        name: backup-test-1-sw76b
        namespace: openshift-adp
      spec:
        backupStorageLocation: dpa-sample-1
        csiSnapshot:
          snapshotClass: ""
          storageClass: gp3-csi
          volumeSnapshot: velero-mysql-fq8sl
        operationTimeout: 10m0s
        snapshotType: CSI
        sourceNamespace: mysql-persistent
        sourcePVC: mysql
      status:
        completionTimestamp: "2023-11-02T16:57:02Z"
        node: ip-10-0-150-57.us-west-2.compute.internal
        path: /host_pods/15116bac-cc01-4d9b-8ee7-609c3bef6bde/volumes/kubernetes.io~csi/pvc-eead8167-556b-461a-b3ec-441749e291c4/mount
        phase: Completed 1
        progress:
          bytesDone: 108104082
          totalBytes: 108104082
        snapshotID: 8da1c5febf25225f4577ada2aeb9f899
        startTimestamp: "2023-11-02T16:56:22Z"

      1
      스냅샷 데이터가 원격 오브젝트 저장소로 성공적으로 전송되었음을 나타냅니다.
4.12.2.2. CSI 볼륨 스냅샷 복원

Restore CR을 생성하여 볼륨 스냅샷을 복원할 수 있습니다.

참고

OAPD 1.3 기본 제공 데이터 Mover를 사용하여 OADP 1.2의 reflectsync 백업을 복원할 수 없습니다. OADP 1.3으로 업그레이드하기 전에 Restic을 사용하여 모든 워크로드의 파일 시스템 백업을 수행하는 것이 좋습니다.

사전 요구 사항

  • cluster-admin 역할을 사용하여 클러스터에 액세스할 수 있습니다.
  • 데이터를 복원할 OADP Backup CR이 있습니다.

절차

  1. 다음 예와 같이 Restore CR에 대한 YAML 파일을 생성합니다.

    CR 복원

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: restore
      namespace: openshift-adp
    spec:
      backupName: <backup>
    # ...

  2. 매니페스트를 적용합니다.

    $ oc create -f restore.yaml

    복원이 시작될 때 DataDownload CR이 생성됩니다.

검증

  • DataDownload CR의 status.phase 필드를 확인하여 복원 프로세스의 상태를 모니터링할 수 있습니다. 가능한 값은 진행 중 ,완료됨,실패 또는 취소됨 입니다.

    • 모든 DataDownload 오브젝트 목록을 가져오려면 다음 명령을 실행합니다.

      $ oc get datadownloads -A

      출력 예

      NAMESPACE       NAME                   STATUS      STARTED   BYTES DONE   TOTAL BYTES   STORAGE LOCATION   AGE     NODE
      openshift-adp   restore-test-1-sk7lg   Completed   7m11s     108104082    108104082     dpa-sample-1       7m11s   ip-10-0-150-57.us-west-2.compute.internal

    • 다음 명령을 입력하여 특정 DataDownload 오브젝트의 status.phase 필드 값을 확인합니다.

      $ oc get datadownloads <datadownload_name> -o yaml

      출력 예

      apiVersion: velero.io/v2alpha1
      kind: DataDownload
      metadata:
        name: restore-test-1-sk7lg
        namespace: openshift-adp
      spec:
        backupStorageLocation: dpa-sample-1
        operationTimeout: 10m0s
        snapshotID: 8da1c5febf25225f4577ada2aeb9f899
        sourceNamespace: mysql-persistent
        targetVolume:
          namespace: mysql-persistent
          pv: ""
          pvc: mysql
      status:
        completionTimestamp: "2023-11-02T17:01:24Z"
        node: ip-10-0-150-57.us-west-2.compute.internal
        phase: Completed 1
        progress:
          bytesDone: 108104082
          totalBytes: 108104082
        startTimestamp: "2023-11-02T17:00:52Z"

      1
      CSI 스냅샷 데이터가 성공적으로 복원되었음을 나타냅니다.
4.12.2.3. OADP 1.3 삭제 정책

삭제 정책은 시스템에서 데이터를 제거하는 규칙을 결정하며 보존 기간, 데이터 민감도 및 규정 준수 요구 사항과 같은 요인에 따라 삭제 시기와 방법을 지정합니다. 규정을 준수하고 중요한 정보를 보존하면서 효과적으로 데이터 제거를 관리합니다.

4.12.2.3.1. OADP 1.3 삭제 정책 지침

OADP 1.3의 다음 삭제 정책 지침을 검토하십시오.

  • OADP 1.3.x에서는 모든 유형의 백업 및 복원 방법을 사용할 때 VolumeSnapshotClass CR(사용자 정의 리소스)에서 deletionPolicy 필드를 Retain 또는 Delete 로 설정할 수 있습니다.

4.12.3. Kopia 해시, 암호화 및 분할 알고리즘 덮어쓰기

DPA(Data Protection Application)의 특정 환경 변수를 사용하여 Kopia 해시, 암호화 및 분할 알고리즘의 기본값을 재정의할 수 있습니다.

4.12.3.1. Kopia 해시, 암호화 및 분할 알고리즘을 재정의하도록 DPA 구성

OADP(OpenShift API for Data Protection) 옵션을 사용하여 해시, 암호화 및 분할에 대한 기본 Kopia 알고리즘을 재정의하여 Kopia 성능을 개선하거나 성능 지표를 비교할 수 있습니다. DPA의 spec.configuration.velero.podConfig.env 섹션에서 다음 환경 변수를 설정할 수 있습니다.

  • KOPIA_HASHING_ALGORITHM
  • KOPIA_ENCRYPTION_ALGORITHM
  • KOPIA_SPLITTER_ALGORITHM

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성했습니다.
참고

DPA(Data Protection Application)의 분할, 해시 및 암호화를 위한 Kopia 알고리즘의 구성은 초기 Kopia 리포지토리 생성 중에만 적용되며 나중에 변경할 수 없습니다.

다른 Kopia 알고리즘을 사용하려면 오브젝트 스토리지에 이전 Kopia 리포지토리가 포함되어 있지 않은지 확인합니다. Backup Storage Location(BSL)에서 새 오브젝트 스토리지를 구성하거나 BSL 구성에서 오브젝트 스토리지에 대한 고유한 접두사를 지정합니다.

절차

  • 다음 예와 같이 해시, 암호화 및 분할에 대한 환경 변수를 사용하여 DPA를 구성합니다.

    DPA 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    #...
    configuration:
      nodeAgent:
        enable: true 1
        uploaderType: kopia 2
      velero:
        defaultPlugins:
        - openshift
        - aws
        - csi 3
        defaultSnapshotMoveData: true
        podConfig:
          env:
            - name: KOPIA_HASHING_ALGORITHM
              value: <hashing_algorithm_name> 4
            - name: KOPIA_ENCRYPTION_ALGORITHM
              value: <encryption_algorithm_name> 5
            - name: KOPIA_SPLITTER_ALGORITHM
              value: <splitter_algorithm_name> 6

    1
    nodeAgent 를 활성화합니다.
    2
    uploaderTypekopia 로 지정합니다.
    3
    csi 플러그인을 포함합니다.
    4
    해시 알고리즘을 지정합니다. 예를 들면 BLAKE3-256 입니다.
    5
    암호화 알고리즘을 지정합니다. 예를 들어 CHACHA20-POLY1305-HMAC-SHA256.
    6
    splitter 알고리즘을 지정합니다. 예를 들어 DYNAMIC-8M-RABINKARP.
4.12.3.2. Kopia 해시, 암호화 및 분할 알고리즘을 재정의하는 사용 사례

사용 사례 예제에서는 해시, 암호화 및 분할에 Kopia 환경 변수를 사용하여 애플리케이션 백업을 수행하는 방법을 보여줍니다. 백업을 AWS S3 버킷에 저장합니다. 그런 다음 Kopia 리포지토리에 연결하여 환경 변수를 확인합니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • AWS S3 버킷이 백업 스토리지 위치로 구성되어 있습니다.
  • 클라우드 공급자가 제공하는 인증 정보를 사용하여 시크릿을 생성했습니다.
  • Kopia 클라이언트를 설치했습니다.
  • 별도의 네임스페이스에서 영구 볼륨이 실행되는 애플리케이션이 있습니다.

절차

  1. 다음 예와 같이 DPA(Data Protection Application)를 구성합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
    name: <dpa_name> 1
    namespace: openshift-adp
    spec:
    backupLocations:
    - name: aws
      velero:
        config:
          profile: default
          region: <region_name> 2
        credential:
          key: cloud
          name: cloud-credentials 3
        default: true
        objectStorage:
          bucket: <bucket_name> 4
          prefix: velero
        provider: aws
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
      velero:
        defaultPlugins:
        - openshift
        - aws
        - csi 5
        defaultSnapshotMoveData: true
        podConfig:
          env:
            - name: KOPIA_HASHING_ALGORITHM
              value: BLAKE3-256 6
            - name: KOPIA_ENCRYPTION_ALGORITHM
              value: CHACHA20-POLY1305-HMAC-SHA256 7
            - name: KOPIA_SPLITTER_ALGORITHM
              value: DYNAMIC-8M-RABINKARP 8
    1
    DPA의 이름을 지정합니다.
    2
    백업 스토리지 위치의 리전을 지정합니다.
    3
    기본 Secret 오브젝트의 이름을 지정합니다.
    4
    AWS S3 버킷 이름을 지정합니다.
    5
    csi 플러그인을 포함합니다.
    6
    해시 알고리즘을 BLAKE3-256 으로 지정합니다.
    7
    암호화 알고리즘을 CHACHA20-POLY1305-HMAC-SHA256 로 지정합니다.
    8
    splitter 알고리즘을 DYNAMIC-8M-RABINKARP 로 지정합니다.
  2. 다음 명령을 실행하여 DPA를 생성합니다.

    $ oc create -f <dpa_file_name> 1
    1
    구성한 DPA의 파일 이름을 지정합니다.
  3. 다음 명령을 실행하여 DPA가 조정되었는지 확인합니다.

    $ oc get dpa -o yaml
  4. 다음 예와 같이 backup CR을 생성합니다.

    백업 CR의 예

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <application_namespace> 1
      defaultVolumesToFsBackup: true

    1
    클러스터에 설치된 애플리케이션의 네임스페이스를 지정합니다.
  5. 다음 명령을 실행하여 백업을 생성합니다.

    $ oc apply -f <backup_file_name> 1
    1
    백업 CR 파일의 이름을 지정합니다.
  6. 다음 명령을 실행하여 백업이 완료되었는지 확인합니다.

    $ oc get backups.velero.io <backup_name> -o yaml 1
    1
    백업 이름을 지정합니다.

검증

  1. 다음 명령을 실행하여 Kopia 리포지토리에 연결합니다.

    $ kopia repository connect s3 \
      --bucket=<bucket_name> \ 1
      --prefix=velero/kopia/<application_namespace> \ 2
      --password=static-passw0rd \ 3
      --access-key="<aws_s3_access_key>" \ 4
      --secret-access-key="<aws_s3_secret_access_key>" \ 5
    1
    AWS S3 버킷 이름을 지정합니다.
    2
    애플리케이션의 네임스페이스를 지정합니다.
    3
    리포지토리에 연결할 Kopia 암호입니다.
    4
    AWS S3 액세스 키를 지정합니다.
    5
    AWS S3 스토리지 공급자 시크릿 액세스 키를 지정합니다.
    참고

    AWS S3 이외의 스토리지 공급자를 사용하는 경우 버킷 끝점 URL 매개변수인 --endpoint 를 명령에 추가해야 합니다.

  2. 다음 명령을 실행하여 Kopia에서 DPA에 구성된 환경 변수를 사용하는지 확인합니다.

    $ kopia repository status

    출력 예

    Config file:         /../.config/kopia/repository.config
    
    Description:         Repository in S3: s3.amazonaws.com <bucket_name>
    # ...
    
    Storage type:        s3
    Storage capacity:    unbounded
    Storage config:      {
                           "bucket": <bucket_name>,
                           "prefix": "velero/kopia/<application_namespace>/",
                           "endpoint": "s3.amazonaws.com",
                           "accessKeyID": <access_key>,
                           "secretAccessKey": "****************************************",
                           "sessionToken": ""
                         }
    
    Unique ID:           58....aeb0
    Hash:                BLAKE3-256
    Encryption:          CHACHA20-POLY1305-HMAC-SHA256
    Splitter:            DYNAMIC-8M-RABINKARP
    Format version:      3
    # ...

4.12.3.3. Kopia 해시, 암호화 및 분할 알고리즘 벤치마킹

Kopia 명령을 실행하여 해시, 암호화 및 분할 알고리즘을 벤치마킹할 수 있습니다. 벤치마킹 결과에 따라 워크로드에 가장 적합한 알고리즘을 선택할 수 있습니다. 이 절차에서는 클러스터의 Pod에서 Kopia 벤치마킹 명령을 실행합니다. 벤치마킹 결과는 CPU 속도, 사용 가능한 RAM, 디스크 속도, 현재 I/O 로드 등에 따라 다를 수 있습니다.

사전 요구 사항

  • OADP Operator가 설치되어 있습니다.
  • 별도의 네임스페이스에서 영구 볼륨이 실행되는 애플리케이션이 있습니다.
  • CSI(Container Storage Interface) 스냅샷을 사용하여 애플리케이션 백업을 실행합니다.
참고

DPA(Data Protection Application)의 분할, 해시 및 암호화를 위한 Kopia 알고리즘의 구성은 초기 Kopia 리포지토리 생성 중에만 적용되며 나중에 변경할 수 없습니다.

다른 Kopia 알고리즘을 사용하려면 오브젝트 스토리지에 이전 Kopia 리포지토리가 포함되어 있지 않은지 확인합니다. Backup Storage Location(BSL)에서 새 오브젝트 스토리지를 구성하거나 BSL 구성에서 오브젝트 스토리지에 대한 고유한 접두사를 지정합니다.

절차

  1. 다음 예와 같이 must-gather Pod를 구성합니다. OADP 버전 1.3 이상에 oadp-mustgather 이미지를 사용하고 있는지 확인합니다.

    Pod 구성 예

    apiVersion: v1
    kind: Pod
    metadata:
      name: oadp-mustgather-pod
      labels:
        purpose: user-interaction
    spec:
      containers:
      - name: oadp-mustgather-container
        image: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
        command: ["sleep"]
        args: ["infinity"]

    참고

    Kopia 클라이언트는 oadp-mustgather 이미지에서 사용할 수 있습니다.

  2. 다음 명령을 실행하여 Pod를 생성합니다.

    $ oc apply -f <pod_config_file_name> 1
    1
    Pod 구성에 대한 YAML 파일의 이름을 지정합니다.
  3. Kopia가 리포지토리에 연결할 수 있도록 Pod의 SCC(보안 컨텍스트 제약 조건)가 anyuid 인지 확인합니다.

    $ oc describe pod/oadp-mustgather-pod | grep scc

    출력 예

    openshift.io/scc: anyuid

  4. 다음 명령을 실행하여 SSH를 통해 포드에 연결합니다.

    $ oc -n openshift-adp rsh pod/oadp-mustgather-pod
  5. 다음 명령을 실행하여 Kopia 리포지토리에 연결합니다.

    sh-5.1# kopia repository connect s3 \
      --bucket=<bucket_name> \ 1
      --prefix=velero/kopia/<application_namespace> \ 2
      --password=static-passw0rd \ 3
      --access-key="<access_key>" \ 4
      --secret-access-key="<secret_access_key>" \ 5
      --endpoint=<bucket_endpoint> \ 6
    1
    오브젝트 스토리지 공급자 버킷 이름을 지정합니다.
    2
    애플리케이션의 네임스페이스를 지정합니다.
    3
    리포지토리에 연결할 Kopia 암호입니다.
    4
    오브젝트 스토리지 공급자 액세스 키를 지정합니다.
    5
    오브젝트 스토리지 공급자 시크릿 액세스 키를 지정합니다.
    6
    버킷 끝점을 지정합니다. AWS S3를 스토리지 공급자로 사용하는 경우 버킷 끝점을 지정할 필요가 없습니다.
    참고

    다음은 예제 명령입니다. 명령은 오브젝트 스토리지 공급자에 따라 다를 수 있습니다.

  6. 해시 알고리즘을 벤치마크하려면 다음 명령을 실행합니다.

    sh-5.1# kopia benchmark hashing

    출력 예

    Benchmarking hash 'BLAKE2B-256' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'BLAKE2B-256-128' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'BLAKE2S-128' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'BLAKE2S-256' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'BLAKE3-256' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'BLAKE3-256-128' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'HMAC-SHA224' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'HMAC-SHA256' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'HMAC-SHA256-128' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'HMAC-SHA3-224' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'HMAC-SHA3-256' (100 x 1048576 bytes, parallelism 1)
         Hash                 Throughput
    -----------------------------------------------------------------
      0. BLAKE3-256           15.3 GB / second
      1. BLAKE3-256-128       15.2 GB / second
      2. HMAC-SHA256-128      6.4 GB / second
      3. HMAC-SHA256          6.4 GB / second
      4. HMAC-SHA224          6.4 GB / second
      5. BLAKE2B-256-128      4.2 GB / second
      6. BLAKE2B-256          4.1 GB / second
      7. BLAKE2S-256          2.9 GB / second
      8. BLAKE2S-128          2.9 GB / second
      9. HMAC-SHA3-224        1.6 GB / second
     10. HMAC-SHA3-256        1.5 GB / second
    -----------------------------------------------------------------
    Fastest option for this machine is: --block-hash=BLAKE3-256

  7. 암호화 알고리즘을 벤치마크하려면 다음 명령을 실행합니다.

    sh-5.1# kopia benchmark encryption

    출력 예

    Benchmarking encryption 'AES256-GCM-HMAC-SHA256'... (1000 x 1048576 bytes, parallelism 1)
    Benchmarking encryption 'CHACHA20-POLY1305-HMAC-SHA256'... (1000 x 1048576 bytes, parallelism 1)
         Encryption                     Throughput
    -----------------------------------------------------------------
      0. AES256-GCM-HMAC-SHA256         2.2 GB / second
      1. CHACHA20-POLY1305-HMAC-SHA256  1.8 GB / second
    -----------------------------------------------------------------
    Fastest option for this machine is: --encryption=AES256-GCM-HMAC-SHA256

  8. splitter 알고리즘을 벤치마크하려면 다음 명령을 실행합니다.

    sh-5.1# kopia benchmark splitter

    출력 예

    splitting 16 blocks of 32MiB each, parallelism 1
    DYNAMIC                     747.6 MB/s count:107 min:9467 10th:2277562 25th:2971794 50th:4747177 75th:7603998 90th:8388608 max:8388608
    DYNAMIC-128K-BUZHASH        718.5 MB/s count:3183 min:3076 10th:80896 25th:104312 50th:157621 75th:249115 90th:262144 max:262144
    DYNAMIC-128K-RABINKARP      164.4 MB/s count:3160 min:9667 10th:80098 25th:106626 50th:162269 75th:250655 90th:262144 max:262144
    # ...
    FIXED-512K                  102.9 TB/s count:1024 min:524288 10th:524288 25th:524288 50th:524288 75th:524288 90th:524288 max:524288
    FIXED-8M                    566.3 TB/s count:64 min:8388608 10th:8388608 25th:8388608 50th:8388608 75th:8388608 90th:8388608 max:8388608
    -----------------------------------------------------------------
      0. FIXED-8M                  566.3 TB/s   count:64 min:8388608 10th:8388608 25th:8388608 50th:8388608 75th:8388608 90th:8388608 max:8388608
      1. FIXED-4M                  425.8 TB/s   count:128 min:4194304 10th:4194304 25th:4194304 50th:4194304 75th:4194304 90th:4194304 max:4194304
      # ...
     22. DYNAMIC-128K-RABINKARP    164.4 MB/s   count:3160 min:9667 10th:80098 25th:106626 50th:162269 75th:250655 90th:262144 max:262144

4.13. 문제 해결

OpenShift CLI 툴 또는 Velero CLI 툴 을 사용하여 Velero 사용자 정의 리소스(CR)를 디버깅할 수 있습니다. Velero CLI 툴에서는 자세한 로그 및 정보를 제공합니다.

설치 문제,백업 및 복원 CR 문제Restic 문제를 확인할 수 있습니다.

must-gather 을 사용하여 로그 및 CR 정보를 수집할 수 있습니다.

Velero CLI 툴은 다음을 통해 얻을 수 있습니다.

  • Velero CLI 툴 다운로드
  • 클러스터의 Velero 배포에서 Velero 바이너리에 액세스

4.13.1. Velero CLI 툴 다운로드

Velero 문서 페이지의 지침에 따라 Velero CLI 툴을 다운로드하여 설치할 수 있습니다.

페이지에는 다음에 대한 지침이 포함되어 있습니다.

  • macOS에서 Homebrew를 사용
  • GitHub
  • Chocolatey를 사용하여 Windows

사전 요구 사항

  • DNS 및 컨테이너 네트워킹이 활성화된 Kubernetes 클러스터 v1.16 이상에 액세스할 수 있습니다.
  • kubectl 을 로컬로 설치했습니다.

절차

  1. 브라우저를 열고 Velero 웹 사이트에서 "Install the CLI" 로 이동합니다.
  2. macOS, GitHub 또는 Windows에 대한 적절한 절차를 따르십시오.
  3. OADP 및 OpenShift Container Platform 버전에 적합한 Velero 버전을 다운로드합니다.
4.13.1.1. OADP-Velero-OpenShift Container Platform 버전 관계
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

1.4.0

1.14

4.14 이상

1.4.1

1.14

4.14 이상

4.13.2. 클러스터의 Velero 배포에서 Velero 바이너리에 액세스

쉘 명령을 사용하여 클러스터의 Velero 배포의 Velero 바이너리에 액세스할 수 있습니다.

사전 요구 사항

  • DataProtectionApplication 사용자 정의 리소스의 상태는 Reconcile complete 입니다.

절차

  • 다음 명령을 입력하여 필요한 별칭을 설정합니다.

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'

4.13.3. OpenShift CLI 툴을 사용하여 Velero 리소스 디버깅

OpenShift CLI 툴을 사용하여 Velero CR(사용자 정의 리소스) 및 Velero Pod 로그를 확인하여 실패한 백업을 디버그하거나 복원할 수 있습니다.

Velero CR

oc describe 명령을 사용하여 Backup 또는 Restore CR과 관련된 경고 및 오류 요약을 검색합니다.

$ oc describe <velero_cr> <cr_name>
Velero Pod 로그

oc logs 명령을 사용하여 Velero pod 로그를 검색합니다.

$ oc logs pod/<velero>
Velero Pod 디버그 로그

다음 예와 같이 DataProtectionApplication 리소스에서 Velero 로그 수준을 지정할 수 있습니다.

참고

이 옵션은 OADP 1.0.3부터 사용할 수 있습니다.

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
spec:
  configuration:
    velero:
      logLevel: warning

다음 logLevel 값을 사용할 수 있습니다.

  • trace
  • debug
  • info
  • 경고
  • error
  • fatal
  • panic

대부분의 로그에 디버그 를 사용하는 것이 좋습니다.

4.13.4. Velero CLI 툴을 사용하여 Velero 리소스 디버깅

BackupRestore CR(사용자 정의 리소스)을 디버그하고 Velero CLI 툴을 사용하여 로그를 검색할 수 있습니다.

Velero CLI 툴은 OpenShift CLI 툴보다 자세한 정보를 제공합니다.

구문

oc exec 명령을 사용하여 Velero CLI 명령을 실행합니다.

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> <command> <cr_name>

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

도움말 옵션

velero --help 옵션을 사용하여 모든 Velero CLI 명령을 나열합니다.

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  --help
Describe 명령

velero describe 명령을 사용하여 Backup 또는 Restore CR과 관련된 경고 및 오류 요약을 검색합니다.

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> describe <cr_name>

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

다음 유형의 복원 오류 및 경고는 velero describe 요청 출력에 표시됩니다.

  • Velero: Velero 자체 작업과 관련된 메시지 목록(예: 클라우드 연결, 백업 파일 읽기 등)
  • 클러스터: 클러스터 범위 리소스 백업 또는 복원과 관련된 메시지 목록입니다.
  • 네임스페이스: 네임스페이스에 저장된 리소스 백업 또는 복원과 관련된 메시지 목록

이러한 카테고리 중 하나에 있는 하나 이상의 오류로 인해 복원 작업에서 PartiallyFailed 의 상태를 수신하고 완료 하지 않습니다. 경고로 인해 완료 상태가 변경되지 않습니다.

중요
  • 리소스별 오류( 클러스터네임스페이스 오류)의 경우 restore describe --details 출력에 Velero가 복원에 성공한 모든 리소스를 나열하는 리소스 목록이 포함됩니다. 이러한 오류가 있는 모든 리소스의 경우 리소스가 실제로 클러스터에 있는지 확인합니다.
  • describe 명령의 출력에서 Velero 오류가 있지만 리소스별 오류가 없는 경우 워크로드를 복원하는 실제 문제 없이 복원이 완료될 수 있지만 복원 후 애플리케이션을 신중하게 검증할 수 있습니다.

    예를 들어 출력에 PodVolumeRestore 또는 노드 에이전트 관련 오류가 포함된 경우 PodVolumeRestoresDataDownloads 의 상태를 확인합니다. 이러한 항목이 실패하거나 계속 실행되지 않은 경우 볼륨 데이터가 완전히 복원되었을 수 있습니다.

Logs 명령

velero logs 명령을 사용하여 Backup 또는 Restore CR의 로그를 검색합니다.

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> logs <cr_name>

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

4.13.5. 메모리 또는 CPU 부족으로 인해 Pod 충돌 또는 재시작

메모리 또는 CPU 부족으로 인해 Velero 또는 Restic Pod가 충돌하는 경우 해당 리소스 중 하나에 대한 특정 리소스 요청을 설정할 수 있습니다.

4.13.5.1. Velero Pod에 대한 리소스 요청 설정

oadp_v1alpha1_dpa.yaml 파일에서 configuration.velero.podConfig.resourceAllocations 사양 필드를 사용하여 Velero Pod에 대한 특정 리소스 요청을 설정할 수 있습니다.

절차

  • YAML 파일에서 cpumemory 리소스 요청을 설정합니다.

    Velero 파일의 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    configuration:
      velero:
        podConfig:
          resourceAllocations: 1
            requests:
              cpu: 200m
              memory: 256Mi

    1
    나열된 resourceAllocations 는 평균 사용량입니다.
4.13.5.2. Restic Pod에 대한 리소스 요청 설정

configuration.restic.podConfig.resourceAllocations 사양 필드를 사용하여 Restic Pod에 대한 특정 리소스 요청을 설정할 수 있습니다.

절차

  • YAML 파일에서 cpumemory 리소스 요청을 설정합니다.

    Restic 파일 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    configuration:
      restic:
        podConfig:
          resourceAllocations: 1
            requests:
              cpu: 1000m
              memory: 16Gi

    1
    나열된 resourceAllocations 는 평균 사용량입니다.
중요

리소스 요청 필드의 값은 Kubernetes 리소스 요구 사항과 동일한 형식을 따라야 합니다. 또한 configuration.velero.podConfig.resourceAllocations 또는 configuration.restic.podConfig.resourceAllocations 를 지정하지 않으면 Velero Pod 또는 Restic Pod의 기본 리소스 사양은 다음과 같습니다.

requests:
  cpu: 500m
  memory: 128Mi

4.13.6. StorageClass가 NFS인 경우 PodVolumeRestore가 완료되지 않음

Restic 또는 Kopia 를 사용하여 NFS 복원 중에 볼륨이 두 개 이상 있는 경우 복원 작업이 실패합니다. PodVolumeRestore 는 다음 오류와 함께 실패하거나 마지막으로 실패하기 전에 복원하려고 합니다.

오류 메시지

Velero: pod volume restore failed: data path restore failed: \
Failed to run kopia restore: Failed to copy snapshot data to the target: \
restore error: copy file: error creating file: \
open /host_pods/b4d...6/volumes/kubernetes.io~nfs/pvc-53...4e5/userdata/base/13493/2681: \
no such file or directory

원인

NFS 마운트 경로는 복원할 두 볼륨의 고유하지 않습니다. 결과적으로 velero 잠금 파일은 복원 중에 NFS 서버에서 동일한 파일을 사용하므로 PodVolumeRestore 가 실패합니다.

해결 방법

deploy/class.yaml 파일에서 nfs-subdir-external-provisionerStorageClass 를 정의하는 동안 각 볼륨에 고유한 pathPattern 을 설정하여 이 문제를 해결할 수 있습니다. 다음 nfs-subdir-external-provisioner StorageClass 예제를 사용합니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  pathPattern: "${.PVC.namespace}/${.PVC.annotations.nfs.io/storage-path}" 1
  onDelete: delete
1
레이블, 주석, 이름 또는 네임스페이스와 같은 PVC 메타데이터를 사용하여 디렉터리 경로를 생성하기 위한 템플릿을 지정합니다. 메타데이터를 지정하려면 ${.PVC.<metadata>} 를 사용합니다. 예를 들어 폴더의 이름을 < pvc-namespace>-<pvc-name >로 지정하려면 ${.PVC.namespace}-${.PVC.name}pathPattern 으로 사용합니다.

4.13.7. Velero 및 승인 Webhook 관련 문제

Velero는 복원 중에 승인 Webhook 문제를 해결할 수 있는 제한된 기능을 제공합니다. 승인 Webhook가 있는 워크로드가 있는 경우 추가 Velero 플러그인을 사용하거나 워크로드를 복원하는 방법을 변경해야 할 수 있습니다.

일반적으로 승인 Webhook가 있는 워크로드에는 특정 종류의 리소스를 먼저 생성해야 합니다. 이는 승인 Webhook가 일반적으로 하위 리소스를 차단하므로 워크로드에 하위 리소스가 있는 경우 특히 그러합니다.

예를 들어 service.serving.knative.dev 와 같은 최상위 오브젝트를 생성하거나 복원하면 일반적으로 하위 리소스가 자동으로 생성됩니다. 이 작업을 먼저 수행하는 경우 Velero를 사용하여 이러한 리소스를 생성하고 복원할 필요가 없습니다. 이렇게 하면 Velero가 사용할 수 있는 승인 Webhook에 의해 하위 리소스 문제가 차단되지 않습니다.

4.13.7.1. 승인 Webhook를 사용하는 Velero 백업에 대한 해결 방법 복원

이 섹션에서는 승인 Webhook를 사용하는 Velero 백업의 여러 유형의 리소스를 복원하는 데 필요한 추가 단계에 대해 설명합니다.

4.13.7.1.1. Knative 리소스 복원

Velero를 사용하여 승인 Webhook를 사용하는 Knative 리소스를 백업하는 데 문제가 발생할 수 있습니다.

승인 Webhook를 사용하는 Knative 리소스를 백업하고 복원할 때마다 최상위 서비스 리소스를 먼저 복원하여 이러한 문제를 방지할 수 있습니다.

절차

  • 최상위 수준의 service.serving.knavtive.dev Service 리소스를 복원합니다.

    $ velero restore <restore_name> \
      --from-backup=<backup_name> --include-resources \
      service.serving.knavtive.dev
4.13.7.1.2. IBM AppConnect 리소스 복원

승인 Webhook가 있는 IBM AppConnect 리소스를 복원하기 위해 Velero를 사용할 때 문제가 발생하면 이 절차에서 검사를 실행할 수 있습니다.

절차

  1. 클러스터에 변경 승인 플러그인이 있는지 확인합니다 : MutatingWebhookConfiguration.

    $ oc get mutatingwebhookconfigurations
  2. 종류의 YAML 파일을 검사합니다. MutatingWebhookConfiguration 은 규칙이 문제가 발생하는 오브젝트 생성을 차단하지 않도록 합니다. 자세한 내용은 공식 Kubernetes 설명서를 참조하십시오.
  3. 백업 시간에 사용된 Configuration.appconnect.ibm.com/v1beta1spec.version 이 설치된 Operator에서 지원되는지 확인합니다.
4.13.7.2. OADP 플러그인의 알려진 문제

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

4.13.7.2.1. 시크릿이 누락되어 이미지 스트림 백업 중 Velero 플러그인 패닉

백업 및 백업 스토리지 위치(BSL)가 데이터 보호 애플리케이션(DPA)의 범위 외부에서 관리되는 경우, OADP 컨트롤러는 DPA 조정에서 관련 oadp-<bsl_name>-<bsl_provider>-registry-secret 을 생성하지 않습니다.

백업이 실행되면 다음 패닉 오류와 함께 이미지 스트림 백업에 OpenShift Velero 플러그인이 패닉됩니다.

024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item"
backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io,
namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked:
runtime error: index out of range with length 1, stack trace: goroutine 94…
4.13.7.2.1.1. 패닉 오류를 방지하기 위한 해결방법

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

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

    $ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl
  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'
4.13.7.2.2. OpenShift ADP 컨트롤러 분할 오류

cloudstoragerestic 이 활성화된 DPA를 구성하는 경우 openshift-adp-controller-manager Pod가 충돌하고 크래시 루프 세그먼트 오류로 인해 Pod가 실패할 때까지 무기한 재시작합니다.

상호 배타적 필드이므로 velero 또는 cloudstorage 를 정의할 수 있습니다.

  • velerocloudstorage 가 모두 정의되어 있는 경우 openshift-adp-controller-manager 가 실패합니다.
  • velero 또는 cloudstorage 가 정의되지 않은 경우 openshift-adp-controller-manager 가 실패합니다.

이 문제에 대한 자세한 내용은 OADP-1054 를 참조하십시오.

4.13.7.2.2.1. OpenShift ADP 컨트롤러 분할 오류 해결

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

4.13.7.3. Velero 플러그인에서 "received EOF, stop recv loop" 메시지를 반환
참고

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

4.13.8. 설치 문제

Data Protection Application을 설치할 때 유효하지 않은 디렉토리를 사용하거나 잘못된 인증 정보를 사용하여 발생한 문제가 발생할 수 있습니다.

4.13.8.1. 백업 스토리지에 잘못된 디렉터리가 포함되어 있습니다.

Velero Pod 로그에 오류 메시지가 표시되고 Backup 스토리지에 잘못된 최상위 디렉터리가 포함되어 있습니다.

원인

오브젝트 스토리지에는 Velero 디렉터리가 아닌 최상위 디렉터리가 포함되어 있습니다.

해결 방법

오브젝트 스토리지가 Velero 전용이 아닌 경우 DataProtectionApplication 매니페스트에 spec.backupLocations.velero.objectStorage.prefix 매개변수를 설정하여 버킷의 접두사를 지정해야 합니다.

4.13.8.2. 잘못된 AWS 인증 정보

oadp-aws-registry Pod 로그에 오류 메시지 InvalidAccessKeyId: The AWS Access Key Id가 기록에 존재하지 않습니다.

Velero Pod 로그에 오류 메시지 NoCredentialProviders: no valid providers in chain.

원인

Secret 오브젝트를 생성하는 데 사용되는 credentials-velero 파일이 잘못 포맷됩니다.

해결 방법

다음 예와 같이 credentials-velero 파일이 올바르게 포맷되었는지 확인합니다.

credentials-velero 파일의 예

[default] 1
aws_access_key_id=AKIAIOSFODNN7EXAMPLE 2
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

1
AWS 기본 프로필.
2
따옴표로 값을 묶지 마십시오(", ').

4.13.9. OADP Operator 문제

OADP(OpenShift API for Data Protection) Operator는 해결할 수 없는 문제로 인해 문제가 발생할 수 있습니다.

4.13.9.1. OADP Operator가 자동으로 실패

OADP Operator의 S3 버킷은 비어 있을 수 있지만 oc get po -n <OADP_Operator_namespace> 명령을 실행하면 Operator의 상태가 Running 임을 확인할 수 있습니다. 이러한 경우 Operator는 실행 중이라고 잘못 보고하기 때문에 자동으로 실패했다고 합니다.

원인

클라우드 인증 정보가 충분하지 않은 권한을 제공하는 경우 문제가 발생합니다.

해결 방법

백업 스토리지 위치(BSL) 목록을 검색하고 인증 정보 문제는 각 BSL의 매니페스트를 확인합니다.

절차

  1. 다음 명령 중 하나를 실행하여 BSL 목록을 검색합니다.

    1. OpenShift CLI 사용:

      $ oc get backupstoragelocations.velero.io -A
    2. Velero CLI 사용:

      $ velero backup-location get -n <OADP_Operator_namespace>
  2. BSL 목록을 사용하여 다음 명령을 실행하여 각 BSL의 매니페스트를 표시하고 각 매니페스트에 오류가 있는지 검사합니다.

    $ oc get backupstoragelocations.velero.io -n <namespace> -o yaml

결과 예

apiVersion: v1
items:
- apiVersion: velero.io/v1
  kind: BackupStorageLocation
  metadata:
    creationTimestamp: "2023-11-03T19:49:04Z"
    generation: 9703
    name: example-dpa-1
    namespace: openshift-adp-operator
    ownerReferences:
    - apiVersion: oadp.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: DataProtectionApplication
      name: example-dpa
      uid: 0beeeaff-0287-4f32-bcb1-2e3c921b6e82
    resourceVersion: "24273698"
    uid: ba37cd15-cf17-4f7d-bf03-8af8655cea83
  spec:
    config:
      enableSharedConfig: "true"
      region: us-west-2
    credential:
      key: credentials
      name: cloud-credentials
    default: true
    objectStorage:
      bucket: example-oadp-operator
      prefix: example
    provider: aws
  status:
    lastValidationTime: "2023-11-10T22:06:46Z"
    message: "BackupStorageLocation \"example-dpa-1\" is unavailable: rpc
      error: code = Unknown desc = WebIdentityErr: failed to retrieve credentials\ncaused
      by: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n\tstatus
      code: 403, request id: d3f2e099-70a0-467b-997e-ff62345e3b54"
    phase: Unavailable
kind: List
metadata:
  resourceVersion: ""

4.13.10. OADP 시간 초과

시간 제한을 늘리면 복잡하고 리소스를 많이 사용하는 프로세스가 조기 종료되지 않고 성공적으로 완료할 수 있습니다. 이 구성을 사용하면 오류, 재시도 또는 실패 가능성을 줄일 수 있습니다.

프로세스의 기본 문제를 숨길 수 있는 과도하게 긴 시간 초과를 구성하지 않도록 시간 초과 확장의 균형을 조정해야 합니다. 프로세스 및 전체 시스템 성능을 충족하는 적절한 시간 초과 값을 신중하게 고려하고 모니터링합니다.

다음은 이러한 매개변수를 구현하는 방법과 시기에 대한 지침이 포함된 다양한 OADP 시간 초과입니다.

4.13.10.1. Restic 타임아웃

spec.configuration.nodeAgent.timeout 매개변수는 Restic 타임아웃을 정의합니다. 기본값은 1h 입니다.

다음 시나리오에서는 nodeAgent 섹션에서 Restic timeout 매개변수를 사용합니다.

  • 500GB보다 큰 총 PV 데이터 사용량이 있는 Restic 백업의 경우
  • 다음 오류로 인해 백업이 시간 초과되는 경우:

    level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete"

절차

  • 다음 예와 같이 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트의 spec.configuration.nodeAgent.timeout 블록에서 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
          timeout: 1h
    # ...
4.13.10.2. Velero 리소스 시간 초과

resourceTimeout 은 Velero CRD(사용자 정의 리소스 정의) 가용성, volumeSnapshot 삭제 및 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 시간을 정의합니다. 기본값은 10m 입니다.

다음 시나리오에 대해 resourceTimeout 을 사용합니다.

  • 총 PV 데이터 사용량이 1TB 이상인 백업의 경우 이 매개 변수는 Velero가 백업을 완료로 표시하기 전에 CSI(Container Storage Interface) 스냅샷을 정리하거나 삭제하려고 할 때 시간 초과 값으로 사용됩니다.

    • 이 정리의 하위 작업은 VSC 패치를 시도하며 이 시간 초과는 해당 작업에 사용할 수 있습니다.
  • Restic 또는 Kopia에 대한 파일 시스템 기반 백업에 대한 백업 리포지토리를 생성하거나 확인하려면 다음을 수행합니다.
  • CR(사용자 정의 리소스) 또는 리소스를 백업에서 복원하기 전에 클러스터에서 Velero CRD를 사용할 수 있는지 확인하려면 다음을 수행합니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.resourceTimeout 블록에서 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      configuration:
        velero:
          resourceTimeout: 10m
    # ...
4.13.10.3. 데이터 Mover 시간 초과

timeoutVolumeSnapshotBackupVolumeSnapshotRestore 를 완료하는 사용자 제공 타임아웃입니다. 기본값은 10m 입니다.

다음 시나리오에 대해 Data Mover 시간 초과 를 사용합니다.

  • VolumeSnapshotBackups (VSB) 및 VolumeSnapshotRestores (VSR)를 생성하는 경우 10분 후에 시간 초과됩니다.
  • 총 PV 데이터 사용량이 500GB 이상인 대규모 환경의 경우 1h 에 시간 제한을 설정합니다.
  • VolumeSnapshotMover (VSM) 플러그인 사용
  • OADP 1.1.x에서만 사용

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.features.dataMover.timeout 블록에서 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      features:
        dataMover:
          timeout: 10m
    # ...
4.13.10.4. CSI 스냅샷 시간 초과

CSISnapshotTimeout 은 오류를 시간 초과로 반환하기 전에 CSI VolumeSnapshot 상태가 ReadyToUse 상태가 될 때까지 대기하는 시간을 지정합니다. 기본값은 10m 입니다.

다음 시나리오에 CSISnapshotTimeout 을 사용합니다.

  • CSI 플러그인 사용
  • 스냅샷에 10분 이상 걸릴 수 있는 대용량 스토리지 볼륨의 경우. 로그에 시간 초과가 있는 경우 이 시간 제한을 조정합니다.
참고

일반적으로 기본 설정은 대규모 스토리지 볼륨을 수용할 수 있으므로 CSISnapshotTimeout 의 기본값을 조정할 필요가 없습니다.

절차

  • 다음 예제와 같이 Backup CR 매니페스트의 spec.csiSnapshotTimeout 블록에서 값을 편집합니다.

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
     name: <backup_name>
    spec:
     csiSnapshotTimeout: 10m
    # ...
4.13.10.5. Velero 기본 항목 작업 시간 초과

DefaultItemOperationTimeout은 시간 초과 전에 비동기 BackupItemActionsRestoreItemActions 가 완료될 때까지 대기하는 시간을 정의합니다. 기본값은 1h 입니다.

다음 시나리오에 defaultItemOperationTimeout 을 사용합니다.

  • Data Mover 1.2.x만 사용할 수 있습니다.
  • 특정 백업 또는 복원이 완료될 때까지 대기해야 하는 시간을 지정하려면 다음을 수행합니다. OADP 기능의 컨텍스트에서 이 값은 CSI(Container Storage Interface) 데이터 Mover 기능과 관련된 비동기 작업에 사용됩니다.
  • defaultItemOperationTimeoutdefaultItemOperationTimeout 을 사용하여 DPA(Data Protection Application)에 정의되면 백업 및 복원 작업에 모두 적용됩니다. itemOperationTimeout 을 사용하여 다음 "Item operation timeout - restore" 섹션과 "Item operation timeout - backup" 섹션에 설명된 대로 해당 CR의 백업 또는 복원만 정의할 수 있습니다.

절차

  • 다음 예제와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.defaultItemOperationTimeout 블록에서 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      configuration:
        velero:
          defaultItemOperationTimeout: 1h
    # ...
4.13.10.6. 항목 작업 시간 초과 - 복원

ItemOperationTimeoutRestoreItemAction 작업을 기다리는 데 사용되는 시간을 지정합니다. 기본값은 1h 입니다.

다음 시나리오에는 복원 ItemOperationTimeout 을 사용합니다.

  • Data Mover 1.2.x만 사용할 수 있습니다.
  • Data Mover가 BackupStorageLocation 에 업로드 및 다운로드되는 경우 . 시간 초과에 도달하면 복원 작업이 완료되지 않으면 실패로 표시됩니다. 스토리지 볼륨 크기 때문에 시간 초과 문제로 인해 데이터 Mover 작업이 실패하는 경우 이 시간 초과 설정을 늘려야 할 수 있습니다.

절차

  • 다음 예제와 같이 Restore CR 매니페스트의 Restore.spec.itemOperationTimeout 블록에서 값을 편집합니다.

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
     name: <restore_name>
    spec:
     itemOperationTimeout: 1h
    # ...
4.13.10.7. 항목 작업 제한 시간 - 백업

ItemOperationTimeout 은 비동기 BackupItemAction 작업을 대기하는 데 사용되는 시간을 지정합니다. 기본값은 1h 입니다.

다음 시나리오에는 ItemOperationTimeout 백업을 사용합니다.

  • Data Mover 1.2.x만 사용할 수 있습니다.
  • Data Mover가 BackupStorageLocation 에 업로드 및 다운로드되는 경우 . 시간 초과에 도달하면 백업 작업이 완료되지 않으면 실패로 표시됩니다. 스토리지 볼륨 크기 때문에 시간 초과 문제로 인해 데이터 Mover 작업이 실패하는 경우 이 시간 초과 설정을 늘려야 할 수 있습니다.

절차

  • 다음 예제와 같이 Backup CR 매니페스트의 Backup.spec.itemOperationTimeout 블록에서 값을 편집합니다.

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
     name: <backup_name>
    spec:
     itemOperationTimeout: 1h
    # ...

4.13.11. CR 문제 백업 및 복원

BackupRestore CR(사용자 정의 리소스)에서 이러한 일반적인 문제가 발생할 수 있습니다.

4.13.11.1. 백업 CR에서 볼륨을 검색할 수 없음

Backup CR에 InvalidVolume.NotFound: 볼륨 'vol-xxxx'가 존재하지 않는 오류 메시지가 표시됩니다.

원인

영구 볼륨(PV) 및 스냅샷 위치는 서로 다른 지역에 있습니다.

해결 방법

  1. 스냅샷 위치가 PV와 동일한 지역에 있도록 DataProtectionApplication 매니페스트에서 spec.snapshotLocations.velero.config.region 키의 값을 편집합니다.
  2. 백업 CR을 만듭니다.
4.13.11.2. 백업 CR 상태가 진행 중인 상태로 유지됨

Backup CR의 상태는 InProgress 단계에 남아 있으며 완료되지 않습니다.

원인

백업이 중단되면 다시 시작할 수 없습니다.

해결 방법

  1. Backup CR의 세부 정보를 검색합니다.

    $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
      backup describe <backup>
  2. Backup CR을 삭제합니다.

    $ oc delete backups.velero.io <backup> -n openshift-adp

    진행 중인 Backup CR이 오브젝트 스토리지에 파일을 업로드하지 않았기 때문에 백업 위치를 정리할 필요가 없습니다.

  3. 백업 CR을 만듭니다.
  4. Velero 백업 세부 정보 보기

    $ velero backup describe <backup-name> --details
4.13.11.3. Backup CR 상태는 PartiallyFailed에 남아 있습니다.

Restic이 사용되지 않은 Backup CR의 상태는 PartiallyFailed 단계에 남아 있으며 완료되지 않습니다. 관련 PVC의 스냅샷이 생성되지 않습니다.

원인

CSI 스냅샷 클래스를 기반으로 백업을 생성하지만 라벨이 누락된 경우 CSI 스냅샷 플러그인이 스냅샷을 생성하지 못합니다. 결과적으로 Velero pod는 다음과 유사한 오류를 기록합니다.

+

time="2023-02-17T16:33:13Z" level=error msg="Error backing up item" backup=openshift-adp/user1-backup-check5 error="error executing custom action (groupResource=persistentvolumeclaims, namespace=busy1, name=pvc1-user1): rpc error: code = Unknown desc = failed to get volumesnapshotclass for storageclass ocs-storagecluster-ceph-rbd: failed to get volumesnapshotclass for provisioner openshift-storage.rbd.csi.ceph.com, ensure that the desired volumesnapshot class has the velero.io/csi-volumesnapshot-class label" logSource="/remote-source/velero/app/pkg/backup/backup.go:417" name=busybox-79799557b5-vprq

해결 방법

  1. Backup CR을 삭제합니다.

    $ oc delete backups.velero.io <backup> -n openshift-adp
  2. 필요하면 BackupStorageLocation 에서 저장된 데이터를 정리하여 공간을 확보합니다.
  3. VolumeSnapshotClass 오브젝트에 velero.io/csi-volumesnapshot-class=true 라벨을 적용합니다.

    $ oc label volumesnapshotclass/<snapclass_name> velero.io/csi-volumesnapshot-class=true
  4. 백업 CR을 만듭니다.

4.13.12. Restic 문제

Restic으로 애플리케이션을 백업할 때 이러한 문제가 발생할 수 있습니다.

4.13.12.1. root_squash가 활성화된 NFS 데이터 볼륨에 대한 Restic 권한 오류

Restic pod 로그에 오류 메시지 controller=pod-volume-backup error="fork/exec/usr/bin/restic: permission denied" 가 표시됩니다.

원인

NFS 데이터 볼륨에 root_squash 가 활성화된 경우 Resticnfsnobody 에 매핑되고 백업을 생성할 수 있는 권한이 없습니다.

해결 방법

Restic 에 대한 추가 그룹을 생성하고 DataProtectionApplication 매니페스트에 그룹 ID를 추가하여 이 문제를 해결할 수 있습니다.

  1. NFS 데이터 볼륨에 Restic 에 대한 추가 그룹을 생성합니다.
  2. 그룹 소유권이 상속되도록 NFS 디렉터리에 setgid 비트를 설정합니다.
  3. 다음 예와 같이 spec.configuration.nodeAgent.supplementalGroups 매개변수와 그룹 ID를 DataProtectionApplication 매니페스트에 추가합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    # ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
          supplementalGroups:
          - <group_id> 1
    # ...
    1
    보조 그룹 ID를 지정합니다.
  4. 변경 사항을 적용할 수 있도록 Restic Pod가 다시 시작될 때까지 기다립니다.
4.13.12.2. Restic Backup CR은 버킷이 제거된 후에는 다시 생성할 수 없습니다.

네임스페이스에 대한 Restic Backup CR을 생성하고 오브젝트 스토리지 버킷을 비우고 동일한 네임스페이스에 대한 Backup CR을 다시 생성하면 다시 생성되는 Backup CR이 실패합니다.

velero Pod 로그에 다음 오류 메시지가 표시됩니다. stderr=Fatal: 구성 파일을 열 수 없습니다. Stat: 지정된 키가 존재하지 않습니다.\nIs 다음 위치에 리포지토리가 있습니까?

원인

Restic 디렉터리가 오브젝트 스토리지에서 삭제되는 경우 Velero는 ResticRepository 매니페스트에서 Restic 리포지토리를 다시 생성하거나 업데이트하지 않습니다. 자세한 내용은 Velero issue 4421 을 참조하십시오.

해결 방법

  • 다음 명령을 실행하여 네임스페이스에서 관련 Restic 리포지토리를 제거합니다.

    $ oc delete resticrepository openshift-adp <name_of_the_restic_repository>

    다음 오류 로그에서 mysql-persistent 은 문제가 있는 Restic 리포지토리입니다. 저장소 이름은 명확성을 위해 이탈리아에 표시됩니다.

     time="2021-12-29T18:29:14Z" level=info msg="1 errors
     encountered backup up item" backup=velero/backup65
     logSource="pkg/backup/backup.go:431" name=mysql-7d99fc949-qbkds
     time="2021-12-29T18:29:14Z" level=error msg="Error backing up item"
     backup=velero/backup65 error="pod volume backup failed: error running
     restic backup, stderr=Fatal: unable to open config file: Stat: The
     specified key does not exist.\nIs there a repository at the following
     location?\ns3:http://minio-minio.apps.mayap-oadp-
     veleo-1234.qe.devcluster.openshift.com/mayapvelerooadp2/velero1/
     restic/mysql-persistent\n: exit status 1" error.file="/remote-source/
     src/github.com/vmware-tanzu/velero/pkg/restic/backupper.go:184"
     error.function="github.com/vmware-tanzu/velero/
     pkg/restic.(*backupper).BackupPodVolumes"
     logSource="pkg/backup/backup.go:435" name=mysql-7d99fc949-qbkds

4.13.13. must-gather 툴 사용

must-gather 툴을 사용하여 OADP 사용자 정의 리소스에 대한 로그, 메트릭 및 정보를 수집할 수 있습니다.

must-gather 데이터는 모든 고객 사례에 첨부되어야 합니다.

다음 데이터 수집 옵션을 사용하여 must-gather 툴을 실행할 수 있습니다.

  • 전체 must-gather 데이터 수집은 OADP Operator가 설치된 모든 네임스페이스에 대한 Prometheus 메트릭, Pod 로그 및 Velero CR 정보를 수집합니다.
  • 필수 must-gather 데이터 수집은 특정 기간(예: 1시간 또는 24시간) 동안 Pod 로그 및 Velero CR 정보를 수집합니다. Prometheus 지표 및 중복 로그는 포함되지 않습니다.
  • 시간 초과가 포함된 must-gather 데이터 수집 많은 실패 Backup CR이 있는 경우 데이터 수집에 시간이 오래 걸릴 수 있습니다. 시간 초과 값을 설정하여 성능을 향상시킬 수 있습니다.
  • Prometheus 지표 데이터 덤프는 Prometheus에서 수집한 지표 데이터가 포함된 아카이브 파일을 다운로드합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.
  • OADP 1.3과 함께 RHEL(Red Hat Enterprise Linux) 9.x를 사용해야 합니다.

절차

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. 다음 데이터 수집 옵션 중 하나에 대해 oc adm must-gather 명령을 실행합니다.

    • Prometheus 지표를 포함한 전체 must-gather 데이터 수집

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3

      데이터는 must-gather/must-gather.tar.gz 로 저장됩니다. Red Hat 고객 포털에서 해당 지원 사례에 이 파일을 업로드할 수 있습니다.

    • 특정 기간 동안 Prometheus 메트릭이 없는 필수 must-gather 데이터 수집

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 \
        -- /usr/bin/gather_<time>_essential 1
      1
      시간을 시간 단위로 지정합니다. 허용되는 값은 1h,6h,24h,72h 또는 all 입니다 (예: gather_1h_essential 또는 gather_all_essential ).
    • 시간 초과가 있는 must-gather 데이터 수집:

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 \
        -- /usr/bin/gather_with_timeout <timeout> 1
      1
      시간 초과 값을 초 단위로 지정합니다.
    • Prometheus 지표 데이터 덤프:

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_metrics_dump

      이 작업에는 오랜 시간이 걸릴 수 있습니다. 데이터는 must-gather/metrics/prom_data.tar.gz 로 저장됩니다.

4.13.13.1. 안전하지 않은 TLS 연결로 must-gather 사용

사용자 정의 CA 인증서가 사용되는 경우 must-gather Pod가 velero logs/describe 의 출력을 가져오지 못합니다. 안전하지 않은 TLS 연결과 함께 must-gather 툴을 사용하려면 gather_without_tls 플래그를 must-gather 명령에 전달할 수 있습니다.

절차

  • 다음 명령을 사용하여 값이 true 로 설정된 gather_without_tls 플래그를 must-gather 툴로 전달합니다.
$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_without_tls <true/false>

기본적으로 플래그 값은 false 로 설정됩니다. 안전하지 않은 TLS 연결을 허용하려면 값을 true 로 설정합니다.

4.13.13.2. must-gather 툴을 사용할 때 옵션 결합

현재 must-gather 스크립트를 결합할 수 없습니다(예: 비보안 TLS 연결을 허용하는 동안 시간 초과 임계값 지정). 다음 예와 같이 must-gather 명령줄에서 내부 변수를 설정하여 이러한 제한 사항을 해결할 수 있습니다.

$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- skip_tls=true /usr/bin/gather_with_timeout <timeout_value_in_seconds>

이 예제에서는 gather_with_timeout 스크립트를 실행하기 전에 skip_tls 변수를 설정합니다. 결과는 gather_with_timeoutgather_without_tls 의 조합입니다.

이렇게 지정할 수 있는 다른 변수는 다음과 같습니다.

  • logs_since 기본 값이 72h
  • request_timeout, 기본값 0s

DataProtectionApplication CR(사용자 정의 리소스)이 s3UrlinsecureSkipTLS: true 로 구성된 경우 CR은 CA 인증서가 누락되어 필요한 로그를 수집하지 않습니다. 해당 로그를 수집하려면 다음 옵션을 사용하여 must-gather 명령을 실행합니다.

$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_without_tls true

4.13.14. OADP 모니터링

OpenShift Container Platform에서는 사용자와 관리자가 클러스터를 효과적으로 모니터링 및 관리할 수 있는 모니터링 스택을 제공하고, 이벤트가 발생하는 경우 경고 수신을 포함하여 클러스터에서 실행되는 사용자 애플리케이션 및 서비스의 워크로드 성능을 모니터링 및 분석할 수 있습니다.

추가 리소스

4.13.14.1. OADP 모니터링 설정

OADP Operator는 Velero 서비스 끝점에서 지표를 검색하기 위해 OpenShift 모니터링 스택에서 제공하는 OpenShift 사용자 워크로드 모니터링을 활용합니다. 모니터링 스택을 사용하면 OpenShift Metrics 쿼리 프런트 엔드를 사용하여 사용자 정의 경고 규칙을 생성하거나 지표를 쿼리할 수 있습니다.

활성화된 사용자 워크로드 모니터링을 사용하면 Grafana와 같은 Prometheus 호환 타사 UI를 구성하고 사용하여 Velero 지표를 시각화할 수 있습니다.

메트릭을 모니터링하려면 사용자 정의 프로젝트를 모니터링하고 ServiceMonitor 리소스를 생성하여 openshift-adp 네임스페이스에 있는 이미 활성화된 OADP 서비스 끝점에서 해당 메트릭을 스크랩해야 합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • 클러스터 모니터링 구성 맵이 생성되어 있습니다.

절차

  1. openshift-monitoring 네임스페이스에서 cluster-monitoring-config ConfigMap 오브젝트를 편집합니다.

    $ oc edit configmap cluster-monitoring-config -n openshift-monitoring
  2. data 섹션의 config.yaml 필드에 enableUserWorkload 옵션을 추가하거나 활성화합니다.

    apiVersion: v1
    data:
      config.yaml: |
        enableUserWorkload: true 1
    kind: ConfigMap
    metadata:
    # ...
    1
    이 옵션을 추가하거나 true로 설정합니다.
  3. 다음 구성 요소가 openshift-user-workload-monitoring 네임스페이스에서 실행 중인지 확인하여 짧은 시간 동안 User Workload Monitoring Setup을 확인합니다.

    $ oc get pods -n openshift-user-workload-monitoring

    출력 예

    NAME                                   READY   STATUS    RESTARTS   AGE
    prometheus-operator-6844b4b99c-b57j9   2/2     Running   0          43s
    prometheus-user-workload-0             5/5     Running   0          32s
    prometheus-user-workload-1             5/5     Running   0          32s
    thanos-ruler-user-workload-0           3/3     Running   0          32s
    thanos-ruler-user-workload-1           3/3     Running   0          32s

  4. openshift-user-workload-monitoringuser-workload-monitoring-config ConfigMap이 있는지 확인합니다. 존재하는 경우 이 절차의 나머지 단계를 건너뜁니다.

    $ oc get configmap user-workload-monitoring-config -n openshift-user-workload-monitoring

    출력 예

    Error from server (NotFound): configmaps "user-workload-monitoring-config" not found

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

  6. 2_configure_user_workload_monitoring.yaml 파일을 적용합니다.

    $ oc apply -f 2_configure_user_workload_monitoring.yaml
    configmap/user-workload-monitoring-config created
4.13.14.2. OADP 서비스 모니터 생성

OADP는 DPA가 구성될 때 생성되는 openshift-adp-velero-metrics-svc 서비스를 제공합니다. 사용자 워크로드 모니터링에서 사용하는 서비스 모니터는 정의된 서비스를 가리켜야 합니다.

다음 명령을 실행하여 서비스에 대한 세부 정보를 가져옵니다.

절차

  1. openshift-adp-velero-metrics-svc 서비스가 있는지 확인합니다. ServiceMonitor 오브젝트의 선택기로 사용할 app.kubernetes.io/name=velero 레이블이 포함되어야 합니다.

    $ oc get svc -n openshift-adp -l app.kubernetes.io/name=velero

    출력 예

    NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
    openshift-adp-velero-metrics-svc   ClusterIP   172.30.38.244   <none>        8085/TCP   1h

  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"

  3. 3_create_oadp_service_monitor.yaml 파일을 적용합니다.

    $ oc apply -f 3_create_oadp_service_monitor.yaml

    출력 예

    servicemonitor.monitoring.coreos.com/oadp-service-monitor created

검증

  • OpenShift Container Platform 웹 콘솔의 관리자 화면을 사용하여 새 서비스 모니터가 Up 상태인지 확인합니다.

    1. 모니터링대상 페이지로 이동합니다.
    2. 필터 가 선택되지 않았거나 사용자 소스가 선택되어 있는지 확인하고 텍스트 검색 필드에 openshift-adp 를 입력합니다.
    3. 서비스 모니터의 상태 상태가 Up 인지 확인합니다.

      그림 4.1. OADP 메트릭 대상

      OADP 메트릭 대상
4.13.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

    이 샘플에서는 다음 조건 아래에 경고가 표시됩니다.

    • 지난 2시간 동안 0보다 큰 새 오류 백업이 증가하고 상태가 최소 5분 동안 지속됩니다.
    • 첫 번째 증가 시간이 5분 미만이면 경고가 Pending 상태가 되고 그 후에는 실행 중 상태가 됩니다.
  2. openshift-adp 네임스페이스에 PrometheusRule 오브젝트를 생성하는 4_create_oadp_alert_rule.yaml 파일을 적용합니다.

    $ oc apply -f 4_create_oadp_alert_rule.yaml

    출력 예

    prometheusrule.monitoring.coreos.com/sample-oadp-alert created

검증

  • 경고가 트리거되면 다음과 같은 방법으로 볼 수 있습니다.

    • 개발자 화면에서 모니터링 메뉴를 선택합니다.
    • 관리자 관점에서 모니터링경고 메뉴의 필터 상자에서 사용자를 선택합니다. 그렇지 않으면 기본적으로 플랫폼 경고만 표시됩니다.

      그림 4.2. OADP 백업 실패 경고

      OADP 백업 실패 경고

추가 리소스

4.13.14.4. 사용 가능한 메트릭 목록

이러한 지표는 OADP가 해당 유형과 함께 제공하는 메트릭 목록입니다.

메트릭 이름설명유형

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.13.14.5. 모니터링 UI를 사용하여 메트릭 보기

OpenShift Container Platform 웹 콘솔의 관리자 또는 개발자 화면에서 메트릭을 볼 수 있습니다. openshift-adp 프로젝트에 액세스할 수 있어야 합니다.

절차

  • 모니터링 → 메트릭 페이지로 이동합니다.

    • 개발자 화면을 사용하는 경우 다음 단계를 따르십시오.

      1. 사용자 지정 쿼리 를 선택하거나 PromQL 표시 링크를 클릭합니다.
      2. 쿼리를 입력하고 Enter 를 클릭합니다.
    • 관리자 화면을 사용하는 경우 텍스트 필드에 표현식을 입력하고 Run Queries 를 선택합니다.

      그림 4.3. OADP 메트릭 쿼리

      OADP 메트릭 쿼리

4.14. OADP와 함께 사용되는 API

이 문서에서는 OADP와 함께 사용할 수 있는 다음 API에 대한 정보를 제공합니다.

  • Velero API
  • OADP API

4.14.1. Velero API

Velero API 문서는 Red Hat이 아닌 Velero에서 유지 관리합니다. Velero API 유형에서 찾을 수 있습니다.

4.14.2. OADP API

다음 표에서는 OADP API의 구조를 제공합니다.

표 4.8. DataProtectionApplicationSpec
속성유형설명

backupLocations

[] BackupLocation

BackupStorageLocations 에 사용할 구성 목록을 정의합니다.

snapshotLocations

[] SnapshotLocation

VolumeSnapshotLocations 에 사용할 구성 목록을 정의합니다.

unsupportedOverrides

map [ UnsupportedImageKey ] 문자열

개발을 위해 배포된 종속 이미지를 재정의하는 데 사용할 수 있습니다. 옵션은 veleroImageFqin,awsPluginImageFqin,openshiftPluginImageFqin,azurePluginImageFqin,gcpPluginImageFqin, csiPluginImageFqin , csiPluginImageFqin , csiPluginImageFqin ,csiPluginImageFqin, dataMoverImageFqin,resticRestoreImageFqin,kubevirtPluginImageFqin, operator-type.

podAnnotations

map [ string ] string

Operator에서 배포한 Pod에 주석을 추가하는 데 사용됩니다.

podDnsPolicy

DNSPolicy

Pod의 DNS 구성을 정의합니다.

podDnsConfig

PodDNSConfig

DNSPolicy 에서 생성된 Pod 외에도 Pod의 DNS 매개변수를 정의합니다.

backupImages

*bool

이미지 백업 및 복원을 활성화하기 위해 레지스트리를 배포할지 여부를 지정하는 데 사용됩니다.

구성

*ApplicationConfig

데이터 보호 애플리케이션의 서버 구성을 정의하는 데 사용됩니다.

기능

*기능

기술 프리뷰 기능을 활성화하는 DPA에 대한 구성을 정의합니다.

OADP API에 대한 스키마 정의를 완료합니다.

표 4.9. BackupLocation
속성유형설명

Velero

*velero.BackupStorageLocationSpec

백업 스토리지 위치에 설명된 대로 볼륨 스냅샷을 저장할 위치입니다.

bucket

*CloudStorageLocation

[기술 프리뷰] 백업 스토리지 위치로 사용하기 위해 일부 클라우드 스토리지 공급자에서 버킷 생성을 자동화합니다.

중요

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

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

BackupLocation유형의 스키마 정의를 완료합니다.

표 4.10. SnapshotLocation
속성유형설명

Velero

*VolumeSnapshotLocationSpec

볼륨 스냅샷 위치에 설명된 대로 볼륨 스냅샷을 저장할 위치입니다.

SnapshotLocation유형의 스키마 정의를 완료합니다.

표 4.11. ApplicationConfig
속성유형설명

Velero

*VeleroConfig

Velero 서버에 대한 구성을 정의합니다.

restic

*ResticConfig

Restic 서버에 대한 구성을 정의합니다.

ApplicationConfig유형의 스키마 정의를 완료합니다.

표 4.12. VeleroConfig
속성유형설명

featureFlags

[] string

Velero 인스턴스에 사용할 기능 목록을 정의합니다.

defaultPlugins

[] string

다음과 같은 기본 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유형의 스키마 정의를 완료합니다.

표 4.13. CustomPlugin
속성유형설명

name

string

사용자 정의 플러그인의 이름입니다.

image

string

사용자 지정 플러그인의 이미지입니다.

CustomPlugin유형의 스키마 정의를 완료합니다.

표 4.14. ResticConfig
속성유형설명

enable

*bool

true 로 설정하면 Restic을 사용하여 백업 및 복원을 활성화합니다. false 로 설정하면 스냅샷이 필요합니다.

supplementalGroups

[]int64

Restic Pod에 적용할 Linux 그룹을 정의합니다.

timeout

string

Restic 타임아웃을 정의하는 사용자 제공 기간 문자열입니다. 기본값은 1hr (1시간)입니다. 기간 문자열은 가능한 부호 있는 10진수 순서이며, 각각 300ms, -1.5h' 또는 2h45m 과 같은 선택적 분수 및 단위 접미사가 있습니다. 유효한 시간 단위는 ns,us (또는 ECDHE s), ms,s,m, h 입니다.

podConfig

*PodConfig

Restic Pod의 구성을 정의합니다.

ResticConfig유형의 스키마 정의를 완료합니다.

표 4.15. PodConfig
속성유형설명

nodeSelector

map [ string ] string

Velero podSpec 또는 Restic podSpec 에 제공할 nodeSelector 를 정의합니다. 자세한 내용은 노드 에이전트 및 노드 라벨 구성을 참조하십시오.

허용 오차

[]톨러레이션

Velero 배포 또는 Restic 데몬 세트에 적용할 허용 오차 목록을 정의합니다.

resourceAllocations

resourceRequirements

Velero CPU 및 메모리 리소스 할당 설정에 설명된 대로 Velero Pod 또는 Restic Pod에 대한 특정 리소스 limitsrequests 설정합니다.

labels

map [ string ] string

Pod에 추가할 레이블입니다.

4.14.2.1. 노드 에이전트 및 노드 라벨 구성

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

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

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

$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""

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

configuration:
  nodeAgent:
    enable: true
    podConfig:
      nodeSelector:
        node-role.kubernetes.io/nodeAgent: ""

다음 예제는 nodeSelector 의 안티 패턴이며 'node-role.kubernetes.io/infra: ""''node-role.kubernetes.io/worker: ""' 둘 다 노드에 있지 않으면 작동하지 않습니다.

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
            node-role.kubernetes.io/worker: ""

PodConfig유형의 스키마 정의를 완료합니다.

표 4.16. 기능
속성유형설명

dataMover

*DataMover

데이터 Mover의 구성을 정의합니다.

기능유형에 대한 전체 스키마 정의 입니다.

표 4.17. DataMover
속성유형설명

enable

bool

true 로 설정하면 볼륨 스냅샷 이동기 컨트롤러와 수정된 CSI Data Mover 플러그인을 배포합니다. false 로 설정하면 배포되지 않습니다.

credentialName

string

데이터 Mover의 사용자 제공 Restic Secret 이름.

timeout

string

VolumeSnapshotBackupVolumeSnapshotRestore 의 사용자가 제공하는 기간 문자열입니다. 기본값은 10m (10분)입니다. 기간 문자열은 가능한 부호 있는 10진수 순서이며, 각각 300ms, -1.5h' 또는 2h45m 과 같은 선택적 분수 및 단위 접미사가 있습니다. 유효한 시간 단위는 ns,us (또는 ECDHE s), ms,s,m, h 입니다.

OADP API는 OADP Operator 에 자세히 설명되어 있습니다.

4.15. 고급 OADP 기능 및 기능

이 문서에서는 OADP(OpenShift API for Data Protection)의 고급 기능 및 기능에 대한 정보를 제공합니다.

4.15.1. 동일한 클러스터에서 다른 Kubernetes API 버전으로 작업

4.15.1.1. 클러스터의 Kubernetes API 그룹 버전 나열

소스 클러스터는 이러한 버전 중 하나가 기본 API 버전인 API의 여러 버전을 제공할 수 있습니다. 예를 들어 Example 이라는 API가 있는 소스 클러스터는 example.com/v1example.com/v1beta2 API 그룹에서 사용할 수 있습니다.

Velero를 사용하여 이러한 소스 클러스터를 백업하고 복원하는 경우 Velero는 Kubernetes API의 기본 버전을 사용하는 해당 리소스의 버전만 백업합니다.

위 예제로 돌아가려면 example.com/v1 이 기본 API인 경우 Velero는 example.com/v1 을 사용하는 리소스의 버전만 백업합니다. 또한 Velero가 대상 클러스터에서 리소스를 복원하려면 대상 클러스터에 example.com/v1 이 사용 가능한 API 리소스 세트에 등록되어 있어야 합니다.

따라서 기본 API 버전이 사용 가능한 API 리소스 세트에 등록되어 있는지 확인하려면 대상 클러스터에서 Kubernetes API 그룹 버전 목록을 생성해야 합니다.

절차

  • 다음 명령을 실행합니다.
$ oc api-resources
4.15.1.2. API 그룹 버전 활성화 정보

기본적으로 Velero는 Kubernetes API의 기본 버전을 사용하는 리소스만 백업합니다. 그러나 Velero에는 이러한 제한을 해결하는 기능인 Enable API Group Versions 도 포함되어 있습니다. 소스 클러스터에서 활성화되면 Velero가 기본 기능뿐만 아니라 클러스터에서 지원되는 모든 Kubernetes API 그룹 버전을 백업합니다. 백업 .tar 파일에 버전이 저장된 후 대상 클러스터에서 복원할 수 있습니다.

예를 들어 Example 이라는 API가 있는 소스 클러스터는 example.com/v1example.com/v1beta2 API 그룹에서 사용할 수 있으며 example.com/v1 은 기본 API입니다.

API 그룹 버전 사용 기능을 활성화하지 않으면 Velero는 예제 용으로 기본 API 그룹 버전만 백업합니다. 이 버전은 example.com/v1 입니다. 이 기능을 활성화하면 Velero도 example.com/v1beta2 를 백업합니다.

대상 클러스터에서 API 그룹 버전 활성화 기능이 활성화되면 Velero는 API 그룹 버전의 우선 순위에 따라 복원할 버전을 선택합니다.

참고

Enable API Group Versions는 아직 베타 버전입니다.

Velero는 다음 알고리즘을 사용하여 1 을 가장 우선 순위로 사용하여 API 버전에 우선순위를 할당합니다.

  1. 대상 클러스터의 기본 버전
  2. source_ 클러스터의 기본 버전
  3. Kubernetes 버전 우선순위가 가장 높은 일반 지원 버전

추가 리소스

4.15.1.3. Enable API Group Versions 사용

Velero의 Enable API Group Versions 기능을 사용하여 기본 버전뿐만 아니라 클러스터에서 지원되는 모든 Kubernetes API 그룹 버전을 백업할 수 있습니다.

참고

Enable API Group Versions는 아직 베타 버전입니다.

절차

  • EnableAPIGroupVersions 기능 플래그를 구성합니다.
apiVersion: oadp.openshift.io/vialpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      featureFlags:
      - EnableAPIGroupVersions

추가 리소스

4.15.2. 한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원

4.15.2.1. 한 클러스터에서 데이터 백업 및 다른 클러스터에서 복원 정보

OADP(OpenShift API for Data Protection)는 동일한 OpenShift Container Platform 클러스터에서 애플리케이션 데이터를 백업하고 복원하도록 설계되었습니다. MTC(Migration Toolkit for Containers)는 하나의 OpenShift Container Platform 클러스터에서 다른 클러스터로 애플리케이션 데이터를 포함한 컨테이너를 마이그레이션하도록 설계되었습니다.

OADP를 사용하여 하나의 OpenShift Container Platform 클러스터에서 애플리케이션 데이터를 백업하고 다른 클러스터에 복원할 수 있습니다. 그러나 이러한 작업은 MTC를 사용하거나 OADP를 사용하여 동일한 클러스터에서 백업 및 복원하는 것보다 더 복잡합니다.

OADP를 사용하여 한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원하려면 OADP를 사용하여 동일한 클러스터에서 데이터를 백업하고 복원하는 데 적용되는 사전 요구 사항 및 절차 외에 다음 요인을 고려해야 합니다.

  • Operator
  • Velero 사용
  • UID 및 GID 범위
4.15.2.1.1. Operator

백업 및 복원에 성공하려면 애플리케이션의 백업에서 Operator를 제외해야 합니다.

4.15.2.1.2. Velero 사용

OADP가 구축된 Velero는 기본적으로 클라우드 공급자 간에 영구 볼륨 스냅샷 마이그레이션을 지원하지 않습니다. 클라우드 플랫폼 간에 볼륨 스냅샷 데이터를 마이그레이션하려면 파일 시스템 수준에서 볼륨 콘텐츠를 백업하는 Velero Restic 파일 시스템 백업 옵션을 활성화 하거나 CSI 스냅샷에 대해 OADP Data Mover를 사용해야 합니다.

참고

OADP 1.1 및 이전 버전에서는 Velero Restic 파일 시스템 백업 옵션을 restic 이라고 합니다. OADP 1.2 이상에서는 Velero Restic 파일 시스템 백업 옵션을 file-system-backup 이라고 합니다.

  • 또한 Velero의 파일 시스템 백업을 사용하여 AWS 리전 간에 데이터를 마이그레이션하거나 Microsoft Azure 리전 간에 데이터를 마이그레이션해야 합니다.
  • Velero는 소스 클러스터보다 이전 Kubernetes 버전의 클러스터로 데이터 복원을 지원하지 않습니다.
  • 이론적으로 소스보다 최신 Kubernetes 버전이 있는 대상으로 워크로드를 마이그레이션할 수 있지만 각 사용자 지정 리소스에 대한 클러스터 간 API 그룹의 호환성을 고려해야 합니다. Kubernetes 버전 업그레이드에서 코어 또는 네이티브 API 그룹의 호환성을 중단하는 경우 먼저 영향을 받는 사용자 정의 리소스를 업데이트해야 합니다.
4.15.2.2. 백업할 Pod 볼륨 확인 정보

파일 시스템 백업(FSB)을 사용하여 백업 작업을 시작하기 전에 백업할 볼륨이 포함된 Pod를 지정해야 합니다. Velero는 이 프로세스를 적절한 Pod 볼륨을 "검색"이라고 합니다.

Velero는 Pod 볼륨을 결정하기 위해 다음 두 가지 접근 방식을 지원합니다. opt-in 또는 opt-out 접근 방식을 사용하여 Velero가 FSB, 볼륨 스냅샷 또는 Data Mover 백업을 결정할 수 있습니다. 

  • 옵트인 접근 방식: 옵트인 접근 방식을 사용하면 기본적으로 스냅샷 또는 데이터 Mover를 사용하여 볼륨이 백업됩니다. FSB는 주석으로 옵트인되는 특정 볼륨에서 사용됩니다.
  • 옵트아웃 접근 방식에서는 옵트아웃 접근 방식을 통해 기본적으로 FSB를 사용하여 볼륨이 백업됩니다. 스냅샷 또는 데이터 Mover는 주석으로 옵트아웃되는 특정 볼륨에서 사용됩니다.
4.15.2.2.1. 제한
  • FSB는 hostpath 볼륨 백업 및 복원을 지원하지 않습니다. 그러나 FSB는 로컬 볼륨 백업 및 복원을 지원합니다.
  • Velero는 생성하는 모든 백업 리포지토리에 정적, 공통 암호화 키를 사용합니다. 이 정적 키는 백업 스토리지에 액세스할 수 있는 모든 사용자가 백업 데이터를 해독할 수 있음을 의미합니다. 백업 스토리지에 대한 액세스를 제한하는 것이 중요합니다.
  • PVC의 경우 Pod 일정을 변경할 때마다 모든 증분 백업 체인이 유지됩니다.

    emptyDir 볼륨과 같이 PVC가 아닌 Pod 볼륨의 경우(예: ReplicaSet 또는 배포) Pod가 삭제되거나 다시 생성되는 경우 해당 볼륨의 다음 백업은 증분 백업이 아닌 전체 백업이 됩니다. Pod 볼륨의 라이프사이클이 해당 Pod에 의해 정의되는 것으로 가정합니다.

  • 백업 데이터를 점진적으로 유지할 수 있지만 데이터베이스와 같은 대용량 파일을 백업하는 데 시간이 오래 걸릴 수 있습니다. FSB는 중복 제거를 사용하여 백업해야 하는 차이점을 찾기 때문입니다.
  • FSB는 Pod가 실행 중인 노드의 파일 시스템에 액세스하여 볼륨에서 데이터를 읽고 씁니다. 이러한 이유로 FSB는 PVC에서 직접 마운트하지 않고 Pod에서 마운트된 볼륨만 백업할 수 있습니다. 일부 Velero 사용자는 Velero 백업을 수행하기 전에 이러한 PVC 및 PV 쌍을 마운트하도록 BusyBox 또는 Alpine 컨테이너와 같은 스테이징 Pod를 실행하여 이 제한을 극복했습니다.
  • FSB에서는 < hostPath>/<pod UID > 아래에 볼륨을 마운트할 것으로 예상하고, < hostPath >를 구성할 수 있습니다. 예를 들어 vCluster와 같은 일부 Kubernetes 시스템은 < pod UID > 하위 디렉터리 아래에 볼륨을 마운트하지 않으며 VFSB는 예상대로 작동하지 않습니다.
4.15.2.2.2. 옵트인 방법을 사용하여 Pod 볼륨 백업

옵트인 방법을 사용하여 파일 시스템 백업(FSB)에서 백업해야 하는 볼륨을 지정할 수 있습니다. backup.velero.io/backup-volumes 명령을 사용하여 이 작업을 수행할 수 있습니다.

절차

  • 백업할 볼륨이 하나 이상 포함된 각 Pod에서 다음 명령을 입력합니다.

    $ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \
      backup.velero.io/backup-volumes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>

    다음과 같습니다.

    <your_volume_name_x>
    Pod 사양에 xth 볼륨의 이름을 지정합니다.
4.15.2.2.3. 옵트아웃 방법을 사용하여 Pod 볼륨 백업

옵트아웃 접근 방식을 사용하는 경우 몇 가지 예외가 있지만 FSB(File System Backup)를 사용하여 모든 Pod 볼륨이 백업됩니다.

  • 기본 서비스 계정 토큰, 시크릿 및 구성 맵을 마운트하는 볼륨입니다.
  • hostPath 볼륨

옵트아웃 방법을 사용하여 백업 하지 않는 볼륨을 지정할 수 있습니다. backup.velero.io/backup-volumes-excludes 명령을 사용하여 이 작업을 수행할 수 있습니다.

절차

  • 백업하지 않으려는 볼륨이 하나 이상 포함된 각 Pod에서 다음 명령을 실행합니다.

    $ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \
      backup.velero.io/backup-volumes-excludes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>

    다음과 같습니다.

    <your_volume_name_x>
    Pod 사양에 xth 볼륨의 이름을 지정합니다.
참고

--default-volumes-to-fs-backup 플래그를 사용하여 velero install 명령을 실행하여 모든 Velero 백업에 대해 이 동작을 활성화할 수 있습니다.

4.15.2.3. UID 및 GID 범위

한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원하는 경우 UID(사용자 ID) 및 GID(그룹 ID) 범위에서 문제가 발생할 수 있습니다. 다음 섹션에서는 이러한 잠재적인 문제 및 완화 방법에 대해 설명합니다.

문제 요약
대상 클러스터에 따라 네임스페이스 UID 및 GID 범위가 변경될 수 있습니다. OADP는 OpenShift UID 범위 메타데이터를 백업하고 복원하지 않습니다. 백업 애플리케이션에 특정 UID가 필요한 경우 범위를 사용할 수 있는지 확인합니다. OpenShift의 UID 및 GID 범위에 대한 자세한 내용은 A Guide to OpenShift and UIDs 를 참조하십시오.
문제에 대한 자세한 설명

쉘 명령 oc create namespace 를 사용하여 OpenShift Container Platform에서 네임스페이스를 생성할 때 OpenShift Container Platform은 사용 가능한 UID 풀, 추가 그룹(GID) 범위 및 고유한 SELinux MCS 레이블에서 네임스페이스에 고유한 UID(사용자 ID) 범위를 할당합니다. 이 정보는 클러스터의 metadata.annotations 필드에 저장됩니다. 이 정보는 다음 구성 요소로 구성된 SCC(보안 컨텍스트 제약 조건) 주석의 일부입니다.

  • openshift.io/sa.scc.mcs
  • openshift.io/sa.scc.supplemental-groups
  • openshift.io/sa.scc.uid-range

OADP를 사용하여 네임스페이스를 복원하면 대상 클러스터에 대해 재설정하지 않고 metadata.annotations 의 정보를 자동으로 사용합니다. 결과적으로 다음 중 하나라도 해당하는 경우 워크로드가 백업된 데이터에 액세스할 수 없을 수 있습니다.

  • 다른 SCC 주석이 있는 기존 네임스페이스가 있습니다(예: 다른 클러스터에). 이 경우 OADP는 복원하려는 네임스페이스 대신 백업 중에 기존 네임스페이스를 사용합니다.
  • 백업 중에 레이블 선택기가 사용되었지만 워크로드가 실행되는 네임스페이스에 레이블이 없습니다. 이 경우 OADP는 네임스페이스를 백업하지 않지만 백업 네임스페이스의 주석이 포함되지 않은 복원 중에 새 네임스페이스를 생성합니다. 그러면 새 UID 범위가 네임스페이스에 할당됩니다.

    이는 OpenShift Container Platform에서 영구 볼륨 데이터가 백업된 이후 변경된 네임스페이스 주석을 기반으로 Pod에 securityContext UID를 할당하는 경우 고객 워크로드에 문제가 될 수 있습니다.

  • 컨테이너의 UID가 더 이상 파일 소유자의 UID와 일치하지 않습니다.
  • OpenShift Container Platform이 백업 클러스터 데이터와 일치하도록 대상 클러스터의 UID 범위를 변경하지 않았기 때문에 오류가 발생합니다. 결과적으로 백업 클러스터에는 대상 클러스터와 다른 UID가 있으므로 애플리케이션이 대상 클러스터에서 데이터를 읽거나 쓸 수 없습니다.

    완화 방법
    다음 완화 방법 중 하나를 사용하여 UID 및 GID 범위 문제를 해결할 수 있습니다.
  • 간단한 완화 방법:

    • Backup CR에서 라벨 선택기를 사용하여 백업에 포함할 오브젝트를 필터링하는 경우 이 라벨 선택기를 작업 공간이 포함된 네임스페이스에 추가해야 합니다.
    • 동일한 이름의 네임스페이스를 복원하기 전에 대상 클러스터에서 기존 네임스페이스 버전을 제거합니다.
  • 고급 완화 방법:

한 클러스터에서 데이터를 백업하고 다른 클러스터에서 데이터를 복원하는 데 있는 문제를 해결하면서 OpenShift Container Platform의 UID 및 GID 범위에 대한 자세한 내용은 OpenShift 및 UID에 대한 가이드를 참조하십시오.

4.15.2.4. 한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원

일반적으로 하나의 OpenShift Container Platform 클러스터의 데이터를 백업하고 동일한 클러스터에 데이터를 백업하고 복원하는 것과 동일한 방식으로 다른 OpenShift Container Platform 클러스터에 복원합니다. 그러나 한 OpenShift Container Platform 클러스터에서 데이터를 백업하고 다른 OpenShift Container Platform 클러스터에서 복원할 때 프로세스에 몇 가지 추가 사전 요구 사항과 차이점이 있습니다.

사전 요구 사항

  • 플랫폼(예: AWS, Microsoft Azure, GCP 등)에서 백업 및 복원을 위한 모든 관련 사전 요구 사항은 이 가이드의 관련 섹션에 설명되어 있습니다.

절차

  • 플랫폼에 지정된 절차를 추가합니다.

    • 백업 저장소 위치(BSL) 및 볼륨 스냅샷 위치에 다른 클러스터의 리소스를 복원하는 것과 동일한 이름과 경로가 있는지 확인합니다.
    • 클러스터 전체에서 동일한 오브젝트 스토리지 위치 인증 정보를 공유합니다.
    • 최상의 결과를 얻으려면 OADP를 사용하여 대상 클러스터에 네임스페이스를 생성합니다.
    • Velero file-system-backup 옵션을 사용하는 경우 다음 명령을 실행하여 백업 중에 사용할 --default-volumes-to-fs-backup 플래그를 활성화합니다.

      $ velero backup create <backup_name> --default-volumes-to-fs-backup <any_other_options>
참고

OADP 1.2 이상에서는 Velero Restic 옵션을 file-system-backup 이라고 합니다.

4.15.3. OADP 스토리지 클래스 매핑

4.15.3.1. 스토리지 클래스 매핑

스토리지 클래스 매핑을 사용하면 다양한 유형의 데이터에 적용해야 하는 스토리지 클래스를 지정하는 규칙 또는 정책을 정의할 수 있습니다. 이 기능은 액세스 빈도, 데이터 중요 및 비용 고려 사항에 따라 스토리지 클래스를 결정하는 프로세스를 자동화합니다. 특성 및 사용 패턴에 대해 데이터가 가장 적합한 스토리지 클래스에 저장되도록 하여 스토리지 효율성 및 비용 효율성을 최적화합니다.

change-storage-class-config 필드를 사용하여 데이터 오브젝트의 스토리지 클래스를 변경할 수 있으므로 요구 사항과 액세스 패턴에 따라 다양한 스토리지 계층 간에 데이터를 이동하여 비용 및 성능을 최적화할 수 있습니다.

4.15.3.1.1. Migration Toolkit for Containers를 사용한 스토리지 클래스 매핑

MTC(Migration Toolkit for Containers)를 사용하여 하나의 OpenShift Container Platform 클러스터에서 다른 클러스터로 애플리케이션 데이터를 포함한 컨테이너를 마이그레이션하고 스토리지 클래스 매핑 및 변환을 수행할 수 있습니다. 동일한 클러스터 내에서 마이그레이션하여 PV(영구 볼륨)의 스토리지 클래스를 변환할 수 있습니다. 이를 위해서는 MTC 웹 콘솔에서 마이그레이션 계획을 생성하고 실행해야 합니다.

4.15.3.1.2. OADP로 스토리지 클래스 매핑

Velero 플러그인 v1.1.0 이상과 함께 OpenShift API for Data Protection(OADP)을 사용하여 Velero 네임스페이스의 구성 맵에 스토리지 클래스 매핑을 구성하여 복원 중에 PV(영구 볼륨)의 스토리지 클래스를 변경할 수 있습니다.

OADP를 사용하여 ConfigMap을 배포하려면 change-storage-class-config 필드를 사용합니다. 클라우드 공급자에 따라 스토리지 클래스 매핑을 변경해야 합니다.

절차

  1. 다음 명령을 실행하여 스토리지 클래스 매핑을 변경합니다.

    $ cat change-storageclass.yaml
  2. 다음 예와 같이 Velero 네임스페이스에 구성 맵을 생성합니다.

    예제

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: change-storage-class-config
      namespace: openshift-adp
      labels:
        velero.io/plugin-config: ""
        velero.io/change-storage-class: RestoreItemAction
    data:
      standard-csi: ssd-csi

  3. 다음 명령을 실행하여 스토리지 클래스 매핑 기본 설정을 저장합니다.

    $ oc create -f change-storage-class-config

4.15.4. 추가 리소스

5장. 컨트롤 플레인 백업 및 복원

5.1. etcd 백업

etcd는 모든 리소스 개체의 상태를 저장하는 OpenShift Container Platform의 키-값 형식의 저장소입니다.

클러스터의 etcd 데이터를 정기적으로 백업하고 OpenShift Container Platform 환경 외부의 안전한 위치에 백업 데이터를 저장하십시오. 설치 후 24 시간 내에 발생하는 첫 번째 인증서 교체가 완료되기 전까지 etcd 백업을 수행하지 마십시오. 인증서 교체가 완료되기 전에 실행하면 백업에 만료된 인증서가 포함됩니다. etcd 스냅샷에 I/O 비용이 높기 때문에 사용량이 많지 않은 시간 동안 etcd 백업을 수행하는 것이 좋습니다.

클러스터를 업그레이드한 후 etcd 백업을 수행해야 합니다. 이는 클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 하므로 중요합니다. 예를 들어 OpenShift Container Platform 4.y.z 클러스터는 4.y.z에서 가져온 etcd 백업을 사용해야 합니다.

중요

컨트롤 플레인 호스트에서 백업 스크립트를 실행하여 클러스터의 etcd 데이터를 백업합니다. 클러스터의 각 컨트롤 플레인 호스트마다 백업을 수행하지 마십시오.

etcd 백업 후 이전 클러스터 상태로 복원할 수 있습니다.

5.1.1. etcd 데이터 백업

다음 단계에 따라 etcd 스냅샷을 작성하고 정적 pod의 리소스를 백업하여 etcd 데이터를 백업합니다. 이 백업을 저장하여 etcd를 복원해야하는 경우 나중에 사용할 수 있습니다.

중요

단일 컨트롤 플레인 호스트의 백업만 저장합니다. 클러스터의 각 컨트롤 플레인 호스트에서 백업을 수행하지 마십시오.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 클러스터 전체의 프록시가 활성화되어 있는지 확인해야 합니다.

    작은 정보

    oc get proxy cluster -o yaml의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다. httpProxy, httpsProxynoProxy 필드에 값이 설정되어 있으면 프록시가 사용됩니다.

절차

  1. 컨트롤 플레인 노드의 root로 디버그 세션을 시작합니다.

    $ oc debug --as-root node/<node_name>
  2. 디버그 쉘에서 root 디렉토리를 /host 로 변경합니다.

    sh-4.4# chroot /host
  3. 클러스터 전체 프록시가 활성화된 경우 다음 명령을 실행하여 NO_PROXY,HTTP_PROXYHTTPS_PROXY 환경 변수를 내보냅니다.

    $ export HTTP_PROXY=http://<your_proxy.example.com>:8080
    $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
    $ export NO_PROXY=<example.com>
  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

    스크립트 출력 예

    found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
    found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
    found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
    found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
    ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
    etcdctl version: 3.4.14
    API version: 3.4
    {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
    {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
    {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
    {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
    {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
    {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
    Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
    {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
    snapshot db and kube resources are successfully saved to /home/core/assets/backup

    이 예제에서는 컨트롤 플레인 호스트의 /home/core/assets/backup/ 디렉토리에 두 개의 파일이 생성됩니다.

    • snapshot_<datetimestamp>.db:이 파일은 etcd 스냅샷입니다. cluster-backup.sh 스크립트는 유효성을 확인합니다.
    • static_kuberesources_<datetimestamp>.tar.gz: 이 파일에는 정적 pod 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.

      참고

      etcd 암호화가 활성화되어 있는 경우 보안상의 이유로 이 두 번째 파일을 etcd 스냅 샷과 별도로 저장하는 것이 좋습니다. 그러나 이 파일은 etcd 스냅 샷에서 복원하는데 필요합니다.

      etcd 암호화는 키가 아닌 값만 암호화합니다. 이는 리소스 유형, 네임 스페이스 및 개체 이름은 암호화되지 않습니다.

5.1.2. 추가 리소스

5.2. 비정상적인 etcd 멤버 교체

이 문서는 비정상적인 단일 etcd 멤버를 교체하는 프로세스를 설명합니다.

이 프로세스는 시스템이 실행 중이 아니거나 노드가 준비되지 않았거나 etcd pod가 크래시 루프 상태에있는 등 etcd 멤버의 비정상적인 상태에 따라 다릅니다.

참고

대부분의 컨트롤 플레인 호스트가 손실된 경우 재해 복구 절차에 따라 이 절차 대신 이전 클러스터 상태로 복원 하십시오.

교체 중인 멤버 에서 컨트롤 플레인 인증서가 유효하지 않은 경우 이 절차 대신 만료된 컨트롤 플레인 인증서 복구 절차를 따라야 합니다.

컨트롤 플레인 노드가 유실되고 새 노드가 생성되는 경우 etcd 클러스터 Operator는 새 TLS 인증서 생성 및 노드를 etcd 멤버로 추가하는 프로세스를 진행합니다.

5.2.1. 사전 요구 사항

5.2.2. 비정상 etcd 멤버 식별

클러스터에 비정상적인 etcd 멤버가 있는지 여부를 확인할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 다음 명령을 사용하여 EtcdMembersAvailable 상태의 상태 조건을 확인하십시오.

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}'
  2. 출력을 확인합니다.

    2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy

    이 출력 예는 ip-10-0-131-183.ec2.internal etcd 멤버가 비정상임을 보여줍니다.

5.2.3. 비정상적인 etcd 멤버의 상태 확인

비정상적인 etcd 멤버를 교체하는 프로세스는 etcd가 다음의 어떤 상태에 있는지에 따라 달라집니다.

  • 컴퓨터가 실행 중이 아니거나 노드가 준비되지 않았습니다.
  • etcd pod가 크래시 루프 상태에 있습니다.

다음 프로세스에서는 etcd 멤버가 어떤 상태에 있는지를 확인합니다. 이를 통해 비정상 etcd 멤버를 대체하기 위해 수행해야하는 단계를 확인할 수 있습니다.

참고

시스템이 실행되고 있지 않거나 노드가 준비되지 않았지만 곧 정상 상태로 돌아올 것으로 예상되는 경우 etcd 멤버를 교체하기 위한 절차를 수행할 필요가 없습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 비정상적인 etcd 멤버를 식별하고 있습니다.

프로세스

  1. 시스템이 실행되고 있지 않은지를 확인합니다.

    $ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running

    출력 예

    ip-10-0-131-183.ec2.internal  stopped 1

    1
    이 출력은 노드와 노드 시스템의 상태를 나열합니다. 상태가 running이 아닌 경우 시스템은 실행되지 않습니다.

    시스템이 실행되고 있지 않은 경우, 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

  2. 노드가 준비되지 않았는지 확인합니다.

    다음 조건 중 하나에 해당하면 노드가 준비되지 않은 것입니다.

    • 시스템이 실행중인 경우 노드에 액세스할 수 있는지 확인하십시오.

      $ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable

      출력 예

      ip-10-0-131-183.ec2.internal	node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable 1

      1
      unreachable 상태의 노드가 나열되면 노드가 준비되지 않은 것 입니다.
    • 노드에 여전히 액세스할 수 있는 경우 노드가 NotReady로 나열되어 있는지 확인하십시오.

      $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"

      출력 예

      ip-10-0-131-183.ec2.internal   NotReady   master   122m   v1.26.0 1

      1
      노드가 NotReady로 표시되면 노드가 준비되지 않은 것입니다.

    노드가 준비되지 않은 경우 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

  3. etcd pod가 크래시 루프 상태인지 확인합니다.

    시스템이 실행되고 있고 노드가 준비된 경우 etcd pod가 크래시 루프 상태인지 확인하십시오.

    1. 모든 컨트롤 플레인 노드가 Ready 로 나열되어 있는지 확인합니다.

      $ oc get nodes -l node-role.kubernetes.io/master

      출력 예

      NAME                           STATUS   ROLES    AGE     VERSION
      ip-10-0-131-183.ec2.internal   Ready    master   6h13m   v1.26.0
      ip-10-0-164-97.ec2.internal    Ready    master   6h13m   v1.26.0
      ip-10-0-154-204.ec2.internal   Ready    master   6h13m   v1.26.0

    2. etcd pod의 상태가 Error 또는 CrashloopBackoff인지 확인하십시오.

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      출력 예

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m 1
      etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
      etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m

      1
      이 pod의 상태는 Error이므로 etcd pod는 크래시 루프 상태입니다.

    etcd pod가 크래시 루프 상태인 경우etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

5.2.4. 비정상적인 etcd 멤버 교체

비정상적인 etcd 멤버의 상태에 따라 다음 절차 중 하나를 사용합니다.

5.2.4.1. 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체

다음에서는 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 경우의 비정상적인 etcd 멤버를 교체하는 프로세스에 대해 자세히 설명합니다.

참고

클러스터가 컨트롤 플레인 머신 세트를 사용하는 경우 보다 간단한 etcd 복구 프로세스의 "컨트롤 플레인 머신 세트 해결"의 "분명된 etcd Operator 복구"를 참조하십시오.

사전 요구 사항

  • 비정상적인 etcd 멤버를 식별했습니다.
  • 시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.

    중요

    다른 컨트롤 플레인 노드의 전원이 꺼진 경우 기다려야 합니다. 비정상 etcd 멤버 교체가 완료될 때까지 컨트롤 플레인 노드의 전원을 꺼야 합니다.

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

    중요

    문제가 발생할 경우 클러스터를 복원할 수 있도록 이 프로세스를 수행하기 전에 etcd 백업을 수행해야합니다.

프로세스

  1. 비정상적인 멤버를 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      출력 예

      etcd-ip-10-0-131-183.ec2.internal                3/3     Running     0          123m
      etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
      etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    3. 멤버 목록을 확인합니다.

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
      | 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. $ etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d

      출력 예

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다.

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      이제 노드 쉘을 종료할 수 있습니다.

  2. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

    중요

    쿼럼 가드를 끄면 나머지 etcd 인스턴스가 재부팅되는 동안 구성 변경 사항을 반영하는 동안 클러스터에 연결할 수 없을 수 있습니다.

    참고

    두 멤버로 실행하는 경우 etcd는 추가 멤버 실패를 허용할 수 없습니다. 나머지 멤버 중 하나를 다시 시작하면 쿼럼이 중단되고 클러스터의 다운 타임이 발생합니다. 쿼럼 가드에서는 다운타임을 일으킬 수 있는 구성 변경으로 인해 etcd가 다시 시작되지 않도록 보호하므로 이 절차를 완료하려면 비활성화해야 합니다.

  3. 다음 명령을 실행하여 영향을 받는 노드를 삭제합니다.

    $ oc delete node <node_name>

    명령 예

    $ oc delete node ip-10-0-131-183.ec2.internal

  4. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다.

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1
      1
      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.

      출력 예

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
      etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
      etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다.

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
      2. 서빙 시크릿을 삭제합니다.

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
      3. 메트릭 시크릿을 삭제합니다.

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
  5. 컨트롤 플레인 시스템을 삭제하고 다시 생성합니다. 이 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd는 자동으로 확장됩니다.

    설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 마스터를 만드는 데 사용된 방법과 동일한 방법을 사용하여 새 마스터를 만들어야 합니다.

    1. 비정상 멤버의 컴퓨터를 가져옵니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

      $ oc get machines -n openshift-machine-api -o wide

      출력 예

      NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
      clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
      clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
      clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
      clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
      clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
      clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

      1
      이는 비정상 노드의 컨트롤 플레인 시스템 ip-10-0-131-183.ec2.internal입니다.
    2. 비정상 멤버의 시스템을 삭제합니다.

      $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
      1
      비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

      비정상 멤버의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

    3. 새 시스템이 생성되었는지 확인합니다.

      $ oc get machines -n openshift-machine-api -o wide

      출력 예

      NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
      clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
      clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
      clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   running 1
      clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
      clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
      clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

      1
      새 시스템 clustername-8qw5l-master-3이 생성되고 단계가 Provisioning에서 Running으로 변경되면 시스템이 준비 상태가 됩니다.

      새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

      참고

      시스템 세트에 사용하는 서브넷 ID를 확인하여 해당 ID가 올바른 가용성 영역에 속하는지 확인합니다.

  6. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  7. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

    $ oc get etcd/cluster -oyaml
  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]

검증

  1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    출력 예

    etcd-ip-10-0-133-53.ec2.internal                 3/3     Running     0          7m49s
    etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
    etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m

    이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.
  2. 정확히 세 개의 etcd 멤버가 있는지 확인합니다.

    1. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    2. 멤버 목록을 확인합니다.

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 5eb0d6b8ca24730c | started |  ip-10-0-133-53.ec2.internal |  https://10.0.133.53:2380 |  https://10.0.133.53:2379 |
      | 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.

      주의

      올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다.

5.2.4.2. etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체

이 단계에서는 etcd pod가 크래시 루프 상태에 있는 경우 비정상 etcd 멤버를 교체하는 방법을 설명합니다.

전제 조건

  • 비정상적인 etcd 멤버를 식별했습니다.
  • etcd pod가 크래시 루프 상태에 있는것으로 확인되었습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • etcd 백업이 수행되었습니다.

    중요

    문제가 발생할 경우 클러스터를 복원할 수 있도록 이 프로세스를 수행하기 전에 etcd 백업을 수행해야합니다.

프로세스

  1. 크래시 루프 상태에 있는 etcd pod를 중지합니다.

    1. 크래시 루프 상태의 노드를 디버깅합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

      $ oc debug node/ip-10-0-131-183.ec2.internal 1
      1
      이를 비정상 노드의 이름으로 변경합니다.
    2. 루트 디렉토리를 /host 로 변경합니다.

      sh-4.2# chroot /host
    3. kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.

      sh-4.2# mkdir /var/lib/etcd-backup
      sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
    4. etcd 데이터 디렉토리를 다른 위치로 이동합니다.

      sh-4.2# mv /var/lib/etcd/ /tmp

      이제 노드 쉘을 종료할 수 있습니다.

  2. 비정상적인 멤버를 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      출력 예

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
      etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
      etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    3. 멤버 목록을 확인합니다.

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
      | b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.

      sh-4.2# etcdctl member remove 62bcf33650a7170a

      출력 예

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다.

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      이제 노드 쉘을 종료할 수 있습니다.

  3. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

  4. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다.

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1
      1
      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.

      출력 예

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
      etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
      etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다.

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
      2. 서빙 시크릿을 삭제합니다.

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
      3. 메트릭 시크릿을 삭제합니다.

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
  5. etcd를 강제로 재배포합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 수행하면 모든 컨트롤 플레인 노드가 etcd pod가 작동하는지 확인합니다.

  6. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  7. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

    $ oc get etcd/cluster -oyaml
  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]

검증

  • 새 멤버가 사용 가능하고 정상적인 상태에 있는지 확인합니다.

    1. 실행중인 etcd 컨테이너에 다시 연결합니다.

      cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다.

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    2. 모든 멤버가 정상인지 확인합니다.

      sh-4.2# etcdctl endpoint health

      출력 예

      https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms
      https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms
      https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms

5.2.4.3. 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 베어 메탈 etcd 멤버 교체

이 절차에서는 시스템이 실행되고 있지 않거나 노드가 준비되지 않았기 때문에 비정상 베어 메탈 etcd 멤버를 교체하는 단계를 자세히 설명합니다.

설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오. 그렇지 않으면 원래 생성하는 데 사용된 것과 동일한 방법을 사용하여 새 컨트롤 플레인 노드를 생성해야 합니다.

사전 요구 사항

  • 비정상적인 베어 메탈 etcd 멤버를 식별했습니다.
  • 시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • etcd 백업이 수행되었습니다.

    중요

    문제가 발생하면 클러스터를 복원할 수 있도록 이 절차를 수행하기 전에 etcd 백업을 수행해야 합니다.

절차

  1. 비정상 멤버를 확인하고 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

      출력 예

      etcd-openshift-control-plane-0   5/5   Running   11   3h56m   192.168.10.9   openshift-control-plane-0  <none>           <none>
      etcd-openshift-control-plane-1   5/5   Running   0    3h54m   192.168.10.10   openshift-control-plane-1   <none>           <none>
      etcd-openshift-control-plane-2   5/5   Running   0    3h58m   192.168.10.11   openshift-control-plane-2   <none>           <none>

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

      $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
    3. 멤버 목록을 확인합니다.

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      | ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
      | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
      | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/   | false |
      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.

      주의

      올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다.

      sh-4.2# etcdctl member remove 7a8197040a5126c8

      출력 예

      Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다.

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      | ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      | cc3830a72fc357f9 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
      | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+

      이제 노드 쉘을 종료할 수 있습니다.

      중요

      멤버를 제거한 후 나머지 etcd 인스턴스가 재부팅되는 동안 클러스터에 연결할 수 없을 수 있습니다.

  2. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

  3. 다음 명령을 실행하여 제거된 비정상 etcd 멤버의 이전 암호를 제거하십시오.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다.

      $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2

      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.

      etcd-peer-openshift-control-plane-2             kubernetes.io/tls   2   134m
      etcd-serving-metrics-openshift-control-plane-2  kubernetes.io/tls   2   134m
      etcd-serving-openshift-control-plane-2          kubernetes.io/tls   2   134m
    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다.

        $ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd
        
        secret "etcd-peer-openshift-control-plane-2" deleted
      2. 서빙 시크릿을 삭제합니다.

        $ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd
        
        secret "etcd-serving-metrics-openshift-control-plane-2" deleted
      3. 메트릭 시크릿을 삭제합니다.

        $ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd
        
        secret "etcd-serving-openshift-control-plane-2" deleted
  4. 비정상 멤버의 컴퓨터를 가져옵니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc get machines -n openshift-machine-api -o wide

    출력 예

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                               PROVIDERID                                                                                              STATE
    examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned 1
    examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
    examplecluster-control-plane-2    Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
    examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
    examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

    1
    이는 비정상 노드의 컨트롤 플레인 시스템( 예:cluster-control-plane-2) 입니다.
  5. 다음 명령을 실행하여 Bare Metal Operator를 사용할 수 있는지 확인합니다.

    $ oc get clusteroperator baremetal

    출력 예

    NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    baremetal   4.13.0    True        False         False      3d15h

  6. 다음 명령을 실행하여 이전 BareMetalHost 오브젝트를 제거합니다.

    $ oc delete bmh openshift-control-plane-2 -n openshift-machine-api

    출력 예

    baremetalhost.metal3.io "openshift-control-plane-2" deleted

  7. 다음 명령을 실행하여 비정상 멤버의 시스템을 삭제합니다.

    $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2

    BareMetalHost Machine 오브젝트를 제거한 후 머신 컨트롤러는 Node 오브젝트를 자동으로 삭제합니다.

    머신 삭제가 어떤 이유로든 지연되거나 명령이 지연되고 지연되면 머신 오브젝트 종료자 필드를 제거하여 삭제를 강제 수행할 수 있습니다.

    중요

    Ctrl+c 를 눌러 머신 삭제를 중단하지 마십시오. 명령이 완료되도록 허용해야 합니다. 새 터미널 창을 열어 종료자 필드를 편집하고 삭제합니다.

    비정상 멤버의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

    1. 다음 명령을 실행하여 머신 구성을 편집합니다.

      $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
    2. Machine 사용자 정의 리소스에서 다음 필드를 삭제한 다음 업데이트된 파일을 저장합니다.

      finalizers:
      - machine.machine.openshift.io

      출력 예

      machine.machine.openshift.io/examplecluster-control-plane-2 edited

  8. 다음 명령을 실행하여 시스템이 삭제되었는지 확인합니다.

    $ oc get machines -n openshift-machine-api -o wide

    출력 예

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                                 PROVIDERID                                                                                       STATE
    examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
    examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
    examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
    examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

  9. 다음 명령을 실행하여 노드가 삭제되었는지 확인합니다.

    $ oc get nodes
    
    NAME                     STATUS ROLES   AGE   VERSION
    openshift-control-plane-0 Ready master 3h24m v1.26.0
    openshift-control-plane-1 Ready master 3h24m v1.26.0
    openshift-compute-0       Ready worker 176m v1.26.0
    openshift-compute-1       Ready worker 176m v1.26.0
  10. BMC 인증 정보를 저장할 새 BareMetalHost 오브젝트와 시크릿을 생성합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: openshift-control-plane-2-bmc-secret
      namespace: openshift-machine-api
    data:
      password: <password>
      username: <username>
    type: Opaque
    ---
    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: openshift-control-plane-2
      namespace: openshift-machine-api
    spec:
      automatedCleaningMode: disabled
      bmc:
        address: redfish://10.46.61.18:443/redfish/v1/Systems/1
        credentialsName: openshift-control-plane-2-bmc-secret
        disableCertificateVerification: true
      bootMACAddress: 48:df:37:b0:8a:a0
      bootMode: UEFI
      externallyProvisioned: false
      online: true
      rootDeviceHints:
        deviceName: /dev/disk/by-id/scsi-<serial_number>
      userData:
        name: master-user-data-managed
        namespace: openshift-machine-api
    EOF
    참고

    사용자 이름과 암호는 다른 베어 메탈 호스트의 시크릿에서 확인할 수 있습니다. bmc:address 에서 사용할 프로토콜을 다른 bmh 오브젝트에서 가져올 수 있습니다.

    중요

    기존 컨트롤 플레인 호스트에서 BareMetalHost 오브젝트 정의를 재사용하는 경우 external Provisioned 필드를 true 로 설정하지 마십시오.

    기존 컨트롤 플레인 BareMetalHost 오브젝트에 OpenShift Container Platform 설치 프로그램에서 프로비저닝한 경우 external 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
    1. 새 시스템이 생성되었는지 확인합니다.

      $ oc get machines -n openshift-machine-api -o wide

      출력 예

      NAME                                   PHASE     TYPE   REGION   ZONE   AGE     NODE                              PROVIDERID                                                                                            STATE
      examplecluster-control-plane-0         Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned 1
      examplecluster-control-plane-1         Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
      examplecluster-control-plane-2         Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
      examplecluster-compute-0               Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
      examplecluster-compute-1               Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

      1
      새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비됩니다.

      새 머신을 생성하는 데 몇 분이 걸립니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

    2. 다음 명령을 실행하여 베어 메탈 호스트가 프로비저닝되고 오류가 보고되지 않았는지 확인합니다.

      $ oc get bmh -n openshift-machine-api

      출력 예

      $ oc get bmh -n openshift-machine-api
      NAME                      STATE                  CONSUMER                       ONLINE ERROR AGE
      openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
      openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
      openshift-control-plane-2 provisioned            examplecluster-control-plane-3 true          47m
      openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
      openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m

    3. 다음 명령을 실행하여 새 노드가 추가되었고 준비 상태인지 확인합니다.

      $ oc get nodes

      출력 예

      $ oc get nodes
      NAME                     STATUS ROLES   AGE   VERSION
      openshift-control-plane-0 Ready master 4h26m v1.26.0
      openshift-control-plane-1 Ready master 4h26m v1.26.0
      openshift-control-plane-2 Ready master 12m   v1.26.0
      openshift-compute-0       Ready worker 3h58m v1.26.0
      openshift-compute-1       Ready worker 3h58m v1.26.0

  12. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  13. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

    $ oc get etcd/cluster -oyaml
  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]

검증

  1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    출력 예

    etcd-openshift-control-plane-0      5/5     Running     0     105m
    etcd-openshift-control-plane-1      5/5     Running     0     107m
    etcd-openshift-control-plane-2      5/5     Running     0     103m

    이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    정확히 세 개의 etcd 멤버가 있는지 확인하려면 실행중인 etcd 컨테이너에 연결하여 영향을 받는 노드에 없는 pod 이름을 전달합니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
  2. 멤버 목록을 확인합니다.

    sh-4.2# etcdctl member list -w table

    출력 예

    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    |        ID        | STATUS  |        NAME        |        PEER ADDRS         |       CLIENT ADDRS        |    IS LEARNER    |
    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 |   false |
    | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 |   false |
    | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 |     false |
    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+

    참고

    이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.

  3. 다음 명령을 실행하여 모든 etcd 멤버가 정상인지 확인합니다.

    # etcdctl endpoint health --cluster

    출력 예

    https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms
    https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms
    https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms

  4. 다음 명령을 실행하여 모든 노드가 최신 버전인지 확인합니다.

    $ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    AllNodesAtLatestRevision

5.2.5. 추가 리소스

5.3. 재해 복구

5.3.1. 재해 복구 정보

재해 복구 문서에서는 관리자에게 OpenShift Container Platform 클러스터에서 발생할 수있는 여러 재해 상황을 복구하는 방법에 대한 정보를 제공합니다. 관리자는 클러스터를 작동 상태로 복원하려면 다음 절차 중 하나 이상을 수행해야합니다.

중요

재해 복구를 수행하려면 하나 이상의 정상 컨트롤 플레인 호스트가 있어야 합니다.

이전 클러스터 상태로 복원

클러스터를 이전 상태로 복원하려는 경우 (예: 관리자가 일부 주요 정보를 삭제한 경우) 이 솔루션을 사용할 수 있습니다. 이에는 대부분의 컨트롤 플레인 호스트가 손실되고 etcd 쿼럼이 손실되고 클러스터가 오프라인인 상태에서도 사용할 수 있습니다. etcd 백업을 수행한 경우 이 절차에 따라 클러스터를 이전 상태로 복원할 수 있습니다.

해당하는 경우 만료된 컨트롤 플레인 인증서에서 복구해야 할 수도 있습니다.

주의

이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이 절차는 마지막 수단으로만 사용해야 합니다.

복원을 수행하기 전에 클러스터에 미치는 영향에 대한 자세한 내용은 클러스터 상태 복원을 참조하십시오.

참고

대다수의 마스터를 계속 사용할 수 있고 etcd 쿼럼이 있는 경우 절차에 따라 비정상적인 단일 etcd 멤버를 교체 합니다.

만료된 컨트롤 플레인 인증서 복구
컨트롤 플레인 인증서가 만료된 경우 이 솔루션을 사용할 수 있습니다. 예를 들어, 설치 후 24 시간 내에 발생하는 첫 번째 인증서 교체 전에 클러스터를 종료하면 인증서가 교체되지 않고 만료됩니다. 다음 단계에 따라 만료된 컨트롤 플레인 인증서를 복구할 수 있습니다.

5.3.2. 이전 클러스터 상태로 복원

클러스터를 이전 상태로 복원하려면 스냅샷을 생성하여 etcd 데이터를 백업해야 합니다. 이 스냅샷을 사용하여 클러스터 상태를 복구합니다. 자세한 내용은 " etcd 데이터 백업"을 참조하십시오.

5.3.2.1. 클러스터 상태 복원 정보

etcd 백업을 사용하여 클러스터를 이전 상태로 복원할 수 있습니다. 이를 사용하여 다음과 같은 상황에서 복구할 수 있습니다.

  • 클러스터에서 대부분의 컨트롤 플레인 호스트가 손실되었습니다(쿼럼 손실).
  • 관리자가 중요한 것을 삭제했으며 클러스터를 복구하려면 복원해야 합니다.
주의

이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이는 마지막 수단으로만 사용해야 합니다.

Kubernetes API 서버를 사용하여 데이터를 검색할 수 있는 경우 etcd를 사용할 수 있으며 etcd 백업을 사용하여 복원할 수 없습니다.

etcd를 복원하려면 클러스터를 효율적으로 복원하는 데 시간이 걸리며 모든 클라이언트가 충돌하는 병렬 기록이 발생합니다. 이는 kubelets, Kubernetes 컨트롤러 관리자, SDN 컨트롤러 및 영구 볼륨 컨트롤러와 같은 구성 요소 모니터링 동작에 영향을 줄 수 있습니다.

이로 인해 etcd의 콘텐츠가 디스크의 실제 콘텐츠와 일치하지 않을 때 Operator가 문제가 발생하여 디스크의 파일이 etcd의 콘텐츠와 충돌할 때 Kubernetes API 서버, Kubernetes 컨트롤러 관리자, Kubernetes 스케줄러 및 etcd의 Operator가 중단될 수 있습니다. 여기에는 문제를 해결하기 위해 수동 작업이 필요할 수 있습니다.

극단적인 경우 클러스터에서 영구 볼륨 추적을 손실하고, 더 이상 존재하지 않는 중요한 워크로드를 삭제하고, 시스템을 다시 이미지화하고, 만료된 인증서로 CA 번들을 다시 작성할 수 있습니다.

5.3.2.2. 이전 클러스터 상태로 복원

저장된 etcd 백업을 사용하여 이전 클러스터 상태를 복원하거나 대부분의 컨트롤 플레인 호스트가 손실된 클러스터를 복원할 수 있습니다.

참고

클러스터에서 컨트롤 플레인 머신 세트를 사용하는 경우 보다 간단한 etcd 복구 절차는 "컨트롤 플레인 머신 세트 문제 해결"을 참조하십시오.

중요

클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 합니다. 예를 들어 OpenShift Container Platform 4.7.2 클러스터는 4.7.2에서 가져온 etcd 백업을 사용해야 합니다.

사전 요구 사항

  • 설치 중에 사용된 인증서 기반 kubeconfig 파일을 통해 cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • 복구 호스트로 사용할 정상적인 컨트롤 플레인 호스트가 있어야 합니다.
  • 컨트롤 플레인 호스트에 대한 SSH 액세스.
  • 동일한 백업에서 가져온 etcd 스냅샷과 정적 pod 리소스가 모두 포함된 백업 디렉토리입니다. 디렉토리의 파일 이름은 snapshot_<datetimestamp>.dbstatic_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
    3. etcd pod가 중지되었는지 확인합니다.

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

    4. kubelet 매니페스트 디렉토리에서 기존 Kubernetes API 서버 pod 파일을 이동합니다.

      $ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
    5. Kubernetes API 서버 pod가 중지되었는지 확인합니다.

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

    6. etcd 데이터 디렉토리를 다른 위치로 이동합니다.

      $ sudo mv -v /var/lib/etcd/ /tmp
    7. /etc/kubernetes/manifests/keepalived.yaml 파일이 있고 노드가 삭제되면 다음 단계를 따르십시오.

      1. kubelet 매니페스트 디렉토리에서 /etc/kubernetes/manifests/keepalived.yaml 파일을 이동합니다.

        $ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp
      2. keepalived 데몬에서 관리하는 컨테이너가 중지되었는지 확인합니다.

        $ sudo crictl ps --name keepalived

        이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

      3. 컨트롤 플레인에 VIP가 할당되어 있는지 확인합니다.

        $ ip -o address | egrep '<api_vip>|<ingress_vip>'
      4. 보고된 각 VIP에 대해 다음 명령을 실행하여 제거합니다.

        $ sudo ip address del <reported_vip> dev <reported_vip_device>
    8. 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
  5. 복구 컨트롤 플레인 호스트에 액세스합니다.
  6. keepalived 데몬이 사용 중인 경우 복구 컨트롤 플레인 노드가 VIP를 소유하고 있는지 확인합니다.

    $ ip -o address | grep <api_vip>

    VIP 주소가 있는 경우 출력에 강조 표시됩니다. VIP가 잘못 설정되거나 구성되지 않은 경우 이 명령은 빈 문자열을 반환합니다.

  7. 클러스터 전체의 프록시가 활성화되어 있는 경우 NO_PROXY, HTTP_PROXYhttps_proxy 환경 변수를 내보내고 있는지 확인합니다.

    작은 정보

    oc get proxy cluster -o yaml의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다. httpProxy, httpsProxynoProxy 필드에 값이 설정되어 있으면 프록시가 사용됩니다.

  8. 복구 컨트롤 플레인 호스트에서 복원 스크립트를 실행하고 etcd 백업 디렉터리에 경로를 전달합니다.

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/backup

    스크립트 출력 예

    ...stopping kube-scheduler-pod.yaml
    ...stopping kube-controller-manager-pod.yaml
    ...stopping etcd-pod.yaml
    ...stopping kube-apiserver-pod.yaml
    Waiting for container etcd to stop
    .complete
    Waiting for container etcdctl to stop
    .............................complete
    Waiting for container etcd-metrics to stop
    complete
    Waiting for container kube-controller-manager to stop
    complete
    Waiting for container kube-apiserver to stop
    ..........................................................................................complete
    Waiting for container kube-scheduler to stop
    complete
    Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
    starting restore-etcd static pod
    starting kube-apiserver-pod.yaml
    static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
    starting kube-controller-manager-pod.yaml
    static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
    starting kube-scheduler-pod.yaml
    static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

    참고

    마지막 etcd 백업 후 노드 인증서가 업데이트된 경우 복원 프로세스에서 노드가 NotReady 상태가 될 수 있습니다.

  9. 노드가 Ready 상태인지 확인합니다.

    1. 다음 명령을 실행합니다.

      $ oc get nodes -w

      샘플 출력

      NAME                STATUS  ROLES          AGE     VERSION
      host-172-25-75-28   Ready   master         3d20h   v1.26.0
      host-172-25-75-38   Ready   infra,worker   3d20h   v1.26.0
      host-172-25-75-40   Ready   master         3d20h   v1.26.0
      host-172-25-75-65   Ready   master         3d20h   v1.26.0
      host-172-25-75-74   Ready   infra,worker   3d20h   v1.26.0
      host-172-25-75-79   Ready   worker         3d20h   v1.26.0
      host-172-25-75-86   Ready   worker         3d20h   v1.26.0
      host-172-25-75-98   Ready   infra,worker   3d20h   v1.26.0

      모든 노드에서 상태를 보고하는 데 몇 분이 걸릴 수 있습니다.

    2. 노드가 NotReady 상태에 있는 경우 노드에 로그인하고 각 노드의 /var/lib/kubelet/pki 디렉터리에서 모든 PEM 파일을 제거합니다. 노드에 SSH를 실행하거나 웹 콘솔에서 터미널 창을 사용할 수 있습니다.

      $  ssh -i <ssh-key-path> core@<master-hostname>

      샘플 pki 디렉터리

      sh-4.4# pwd
      /var/lib/kubelet/pki
      sh-4.4# ls
      kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
      kubelet-client-current.pem              kubelet-server-current.pem

  10. 모든 컨트롤 플레인 호스트에서 kubelet 서비스를 다시 시작합니다.

    1. 복구 호스트에서 다음 명령을 실행합니다.

      $ sudo systemctl restart kubelet.service
    2. 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
  11. 보류 중인 CSR을 승인합니다.

    참고

    3개의 스케줄링 가능한 컨트롤 플레인 노드로 구성된 단일 노드 클러스터 또는 클러스터와 같이 작업자 노드가 없는 클러스터에는 승인할 보류 중인 CSR이 없습니다. 이 단계에서 나열된 모든 명령을 건너뛸 수 있습니다.

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

      $ oc get csr

      출력 예

      NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
      csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
      csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
      csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
      csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
      ...

      1 2
      보류 중인 kubelet 서비스 CSR(사용자 프로비저닝 설치용)입니다.
      3 4
      보류 중인 node-bootstrapper CSR입니다.
    2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.

      $ oc describe csr <csr_name> 1
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
    3. 각각의 유효한 node-bootstrapper CSR을 승인합니다.

      $ oc adm certificate approve <csr_name>
    4. 사용자 프로비저닝 설치의 경우 각 유효한 kubelet 서비스 CSR을 승인합니다.

      $ oc adm certificate approve <csr_name>
  12. 단일 멤버 컨트롤 플레인이 제대로 시작되었는지 확인합니다.

    1. 복구 호스트에서 etcd 컨테이너가 실행 중인지 확인합니다.

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

      출력 예

      3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

    2. 복구 호스트에서 etcd pod가 실행 중인지 확인합니다.

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      출력 예

      NAME                                             READY   STATUS      RESTARTS   AGE
      etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

      Pending 상태에 있거나 출력에 여러 실행중인 etcd pod가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.

  13. OVNKubernetes 네트워크 플러그인을 사용하는 경우 복구 컨트롤 플레인 호스트가 아닌 컨트롤 플레인 호스트와 연결된 노드 오브젝트를 삭제합니다.

    $ oc delete node <non-recovery-controlplane-host-1> <non-recovery-controlplane-host-2>
  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>'
    참고

    OVN-Kubernetes 컨트롤 플레인을 재배포하고 이전 명령을 사용하여 빈 출력을 반환하는 데 최소 5-10 분이 걸릴 수 있습니다.

  15. OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 모든 호스트에서 OVN(Open Virtual Network) Kubernetes Pod를 다시 시작합니다.

    참고

    승인 Webhook 확인 및 변경은 Pod를 거부할 수 있습니다. failurePolicyFail 로 설정하여 추가 Webhook를 추가하는 경우 Pod를 거부하고 복원 프로세스가 실패할 수 있습니다. 클러스터 상태를 복원하는 동안 Webhook를 저장하고 삭제하여 이 문제를 방지할 수 있습니다. 클러스터 상태가 성공적으로 복원되면 Webhook를 다시 활성화할 수 있습니다.

    또는 클러스터 상태를 복원하는 동안 failurePolicyIgnore 로 일시적으로 설정할 수 있습니다. 클러스터 상태가 성공적으로 복원된 후 failurePolicyFail 로 설정할 수 있습니다.

    1. northbound 데이터베이스(nbdb) 및 southbound 데이터베이스(sbdb)를 제거합니다. SSH(Secure Shell)를 사용하여 복구 호스트와 나머지 컨트롤 플레인 노드에 액세스하고 다음 명령을 실행합니다.

      $ sudo rm -f /var/lib/ovn/etc/*.db
    2. 다음 명령을 실행하여 모든 OVN-Kubernetes 컨트롤 플레인 Pod를 삭제합니다.

      $ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes
    3. 다음 명령을 실행하여 OVN-Kubernetes 컨트롤 플레인 Pod가 다시 배포되고 Running 상태에 있는지 확인합니다.

      $ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes

      출력 예

      NAME                   READY   STATUS    RESTARTS   AGE
      ovnkube-master-nb24h   4/4     Running   0          48s

    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
    5. 다음 명령을 실행하여 OVN Pod의 상태를 확인합니다.

      $ oc get po -n openshift-ovn-kubernetes
      1. OVN Pod가 종료 상태에 있는 경우 다음 명령을 실행하여 해당 OVN Pod를 실행 중인 노드를 삭제합니다. & lt;node >를 삭제 중인 노드의 이름으로 바꿉니다.

        $ oc delete node <node>
      2. 다음 명령을 실행하여 SSH를 사용하여 종료 상태의 OVN pod 노드에 로그인합니다.

        $ ssh -i <ssh-key-path> core@<node>
      3. 다음 명령을 실행하여 /var/lib/kubelet/pki 디렉토리에서 모든 PEM 파일을 이동합니다.

        $ sudo mv /var/lib/kubelet/pki/* /tmp
      4. 다음 명령을 실행하여 kubelet 서비스를 다시 시작합니다.

        $ sudo systemctl restart kubelet.service
      5. 다음 명령을 실행하여 복구 etcd 머신으로 돌아갑니다.

        $ oc get csr

        출력 예

        NAME        AGE    SIGNERNAME                         REQUESTOR                     CONDITION
        csr-<uuid>   8m3s   kubernetes.io/kubelet-serving     system:node:<node_name>       Pending

      6. 다음 명령을 실행하여 새 CSR을 모두 승인하고 csr-<uuid&gt;를 CSR 이름으로 교체하십시오.

        oc adm certificate approve csr-<uuid>
      7. 다음 명령을 실행하여 노드가 다시 있는지 확인합니다.

        $ oc get nodes
    6. 다음 명령을 실행하여 모든 ovnkube-node Pod가 다시 배포되고 Running 상태에 있는지 확인합니다.

      $ oc get pods -n openshift-ovn-kubernetes | grep ovnkube-node
  16. 복구되지 않는 다른 컨트롤 플레인 시스템을 삭제하고 하나씩 다시 생성합니다. 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd가 자동으로 확장됩니다.

    • 사용자가 프로비저닝한 베어 메탈 설치를 사용하는 경우 원래 사용했던 것과 동일한 방법을 사용하여 컨트롤 플레인 시스템을 다시 생성할 수 있습니다. 자세한 내용은 " 베어 메탈에 사용자 프로비저닝 클러스터 설치"를 참조하십시오.

      주의

      복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.

    • 설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오.

      주의

      복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.

      설치 관리자 프로비저닝 인프라에 베어 메탈 설치의 경우 컨트롤 플레인 머신이 다시 생성되지 않습니다. 자세한 내용은 " 베어 메탈 컨트롤 플레인 노드 교체"를 참조하십시오.

      1. 손실된 컨트롤 플레인 호스트 중 하나에 대한 머신을 가져옵니다.

        cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다.

        $ oc get machines -n openshift-machine-api -o wide

        출력 예:

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
        clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        1
        이는 손실된 컨트롤 플레인 호스트인 ip-10-0-131-183.ec2.internal 의 컨트롤 플레인 시스템입니다.
      2. 다음을 실행하여 손실된 컨트롤 플레인 호스트의 시스템을 삭제합니다.

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
        1
        손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

        손실된 컨트롤 플레인 호스트의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

      3. 다음을 실행하여 새 시스템이 생성되었는지 확인합니다.

        $ oc get machines -n openshift-machine-api -o wide

        출력 예:

        NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
        clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 1
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        1
        새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비됩니다.

        새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

      4. 복구 호스트가 아닌 손실된 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.
  17. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

  18. 복구 호스트 내의 별도의 터미널 창에서 다음 명령을 실행하여 복구 kubeconfig 파일을 내보냅니다.

    $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
  19. etcd를 강제로 재배포합니다.

    복구 kubeconfig 파일을 내보낸 동일한 터미널 창에서 다음 명령을 실행합니다.

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 실행하면 기존 노드가 초기 부트 스트랩 확장과 유사한 새 pod를 사용하기 시작합니다.

  20. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  21. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

    $ oc get etcd/cluster -oyaml
  22. 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    etcd의 NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1
    1
    이 예에서 최신 버전 번호는 7입니다.

    출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

  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

      모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

      AllNodesAtLatestRevision
      3 nodes are at revision 7 1
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    2. Kubernetes 컨트롤러 관리자에 대해 새 롤아웃을 강제 적용합니다.

      $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

      모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

      $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

      AllNodesAtLatestRevision
      3 nodes are at revision 7 1
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    3. Kubernetes 스케줄러에 대해 새 롤아웃을 강제 적용합니다.

      $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

      모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

      $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

      AllNodesAtLatestRevision
      3 nodes are at revision 7 1
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

  24. 모든 컨트롤 플레인 호스트가 클러스터를 시작하여 참여하고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    출력 예

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

복구 절차에 따라 모든 워크로드가 일반 작업으로 돌아가도록 하려면 Kubernetes API 정보를 저장하는 각 Pod를 다시 시작합니다. 여기에는 라우터, Operator 및 타사 구성 요소와 같은 OpenShift Container Platform 구성 요소가 포함됩니다.

참고

이전 절차 단계를 완료하면 모든 서비스가 복원된 상태로 돌아올 때까지 몇 분 정도 기다려야 할 수 있습니다. 예를 들어, OAuth 서버 pod가 다시 시작될 때까지 oc login을 사용한 인증이 즉시 작동하지 않을 수 있습니다.

즉각적인 인증을 위해 system:admin kubeconfig 파일을 사용하는 것이 좋습니다. 이 방법은 OAuth 토큰에 대해 SSL/TLS 클라이언트 인증서에 대한 인증을 기반으로 합니다. 다음 명령을 실행하여 이 파일로 인증할 수 있습니다.

$ export KUBECONFIG=<installation_directory>/auth/kubeconfig

다음 명령을 실행하여 인증된 사용자 이름을 표시합니다.

$ oc whoami
5.3.2.3. etcd 백업에서 수동으로 클러스터 복원

"이전 클러스터 상태로 복원" 섹션에 설명된 복원 절차:

  • UPI 설치 시 컨트롤 플레인 노드에 대한 Machine 또는 ControlPlaneMachineset 을 생성하지 않으므로 UPI 설치 방법을 사용하여 설치된 클러스터에 대한 2개의 컨트롤 플레인 노드를 완전히 다시 생성해야 합니다.
  • 새 단일 멤버 etcd 클러스터를 시작한 /usr/local/bin/cluster-restore.sh 스크립트를 사용하여 세 멤버로 확장합니다.

이와 반대로 이 절차는 다음과 같습니다.

  • 컨트롤 플레인 노드를 다시 생성할 필요가 없습니다.
  • 3개의 멤버 etcd 클러스터를 직접 시작합니다.

클러스터에서 컨트롤 플레인에 MachineSet 을 사용하는 경우 etcd 복구 절차를 위해 "Restoring to a previous cluster state"를 사용하는 것이 좋습니다.

클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 합니다. 예를 들어 OpenShift Container Platform 4.7.2 클러스터는 4.7.2에서 가져온 etcd 백업을 사용해야 합니다.

사전 요구 사항

  • cluster-admin 역할(예: kubeadmin 사용자)을 사용하여 사용자로 클러스터에 액세스합니다.
  • 호스트 사용자를 사용하여 모든 컨트롤 플레인 호스트에 대한 SSH 액세스 ( 예: 기본 코어 호스트 사용자)
  • 이전 etcd 스냅샷과 동일한 백업의 정적 pod 리소스가 모두 포함된 백업 디렉터리입니다. 디렉토리의 파일 이름은 snapshot_<datetimestamp>.dbstatic_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/
    2. 명령을 사용하여 Kubernetes API 서버 컨테이너가 중지되었는지 확인합니다.

      $ crictl ps | grep kube-apiserver | grep -E -v "operator|guard"

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

    3. Kubernetes API Server 컨테이너가 계속 실행 중인 경우 다음 명령을 사용하여 수동으로 종료합니다.

      $ crictl stop <container_id>
    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/
      2. 다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다.

        $ crictl ps | grep kube-controller-manager | grep -E -v "operator|guard"
      3. 다음 명령을 사용하여 kube-scheduler Pod를 중지합니다.

        $ mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /root/manifests-backup/
      4. 다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다.

        $ crictl ps | grep kube-scheduler | grep -E -v "operator|guard"
      5. 다음 명령을 사용하여 etcd pod를 중지합니다.

        $ mv /etc/kubernetes/manifests/etcd-pod.yaml /root/manifests-backup/
      6. 다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다.

        $ crictl ps | grep etcd | grep -E -v "operator|guard"
  4. 각 컨트롤 플레인 호스트에서 현재 etcd 데이터를 백업 폴더로 이동하여 저장합니다.

    $ mkdir /home/core/assets/old-member-data
    $ mv /var/lib/etcd/member /home/core/assets/old-member-data

    이 데이터는 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: ").+(?=")'
    2. < UUID&gt;의 값은 명령을 사용하여 컨트롤 플레인 호스트에서 생성할 수 있습니다.

      $ uuidgen
      참고

      < UUID> 의 값은 한 번만 생성되어야 합니다. 하나의 컨트롤 플레인 호스트에서 UUID 를 생성한 후 다른 컨트롤 플레인 호스트에서 다시 생성하지 마십시오. 모든 컨트롤 플레인 호스트의 다음 단계에서 동일한 UUID 를 사용합니다.

    3. ETCD_NODE_PEER_URL 의 값은 다음 예와 같이 설정해야 합니다.

      https://<IP_CURRENT_HOST>:2380

      올바른 IP는 특정 컨트롤 플레인 호스트의 < ETCD_NAME >에서 명령을 사용하여 찾을 수 있습니다.

      $ echo <ETCD_NAME> | \
        sed -E 's/[.-]/_/g' | \
        xargs -I {} grep {} /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd.env | \
        grep "IP" | grep -Po '(?<=").+(?=")'
    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

      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
    2. 계속하기 전에 올바른 etcdctl 이미지를 식별합니다. 다음 명령을 사용하여 Pod 매니페스트 백업에서 이미지를 검색합니다.

      $ jq -r '.spec.containers[]|select(.name=="etcdctl")|.image' /root/manifests-backup/etcd-pod.yaml
      $ podman run --rm -it --entrypoint="/bin/bash" -v /var/lib/etcd:/var/lib/etcd:z <image-hash>
    3. etcdctl 도구 버전이 백업이 생성된 etcd 서버의 버전인지 확인합니다.

      $ etcdctl version
    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
      참고

      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}

    1. 컨테이너를 종료합니다.
    2. 다른 컨트롤 플레인 호스트에서 이러한 단계를 반복하여 추가된 멤버 로그에 출력된 값이 모든 컨트롤 플레인 호스트에 대해 동일한지 확인합니다.
  8. 재생성된 etcd 데이터베이스를 기본 위치로 이동합니다.

    이러한 작업은 각 컨트롤 플레인 호스트에서 실행해야 합니다.

    1. 재현된 데이터베이스(이전 etcdctl snapshot restore 명령으로 생성된 멤버 폴더)를 기본 etcd 위치 /var/lib/etcd:로 이동합니다.

      $ mv /var/lib/etcd/restore-<UUID>/member /var/lib/etcd
    2. /var/lib/etcd /member 폴더에서 /var/lib/etcd/member 폴더의 SELinux 컨텍스트를 복원합니다.

      $ restorecon -vR /var/lib/etcd/
    3. 남은 파일과 디렉터리를 제거합니다.

      $ rm -rf /var/lib/etcd/restore-<UUID>
      $ rm /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db
      중요

      완료되면 /var/lib/etcd 디렉토리에 폴더 멤버 만 포함되어야 합니다.

    4. 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
  9. etcd 클러스터를 다시 시작하십시오.

    1. 다음 단계는 모든 컨트롤 플레인 호스트에서 실행해야 하지만 한 번에 하나의 호스트 를 실행해야 합니다.
    2. kubelet이 관련 컨테이너를 시작하도록 하려면 etcd 정적 Pod 매니페스트를 kubelet 매니페스트 디렉터리로 다시 이동합니다.

      $ mv /tmp/etcd-pod.yaml /etc/kubernetes/manifests
    3. 모든 etcd 컨테이너가 시작되었는지 확인합니다.

      $ crictl ps | grep etcd | grep -v operator

      출력 예

      38c814767ad983       f79db5a8799fd2c08960ad9ee22f784b9fbe23babe008e8a3bf68323f004c840                                                         28 seconds ago       Running             etcd-health-monitor                   2                   fe4b9c3d6483c
      e1646b15207c6       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd-metrics                          0                   fe4b9c3d6483c
      08ba29b1f58a7       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd                                  0                   fe4b9c3d6483c
      2ddc9eda16f53       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcdctl

      이 명령의 출력이 비어 있으면 몇 분 기다렸다가 다시 확인하십시오.

  10. etcd 클러스터의 상태를 확인합니다.

    1. 다음 명령을 사용하여 컨트롤 플레인 호스트에서 etcd 클러스터의 상태를 확인합니다.

      $ crictl exec -it $(crictl ps | grep etcdctl | awk '{print $1}') etcdctl endpoint status -w table

      출력 예

      +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT         |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      | https://10.0.89.133:2379 | 682e4a83a0cec6c0 |   3.5.0 |   67 MB |      true |      false |         2 |        218 |                218 |        |
      |  https://10.0.92.74:2379 | 450bcf6999538512 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
      | https://10.0.93.129:2379 | 358efa9c1d91c3d6 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
      +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

  11. 다른 정적 pod를 다시 시작합니다.

    한 번에 하나의 호스트이지만 모든 컨트롤 플레인 호스트에서 다음 단계를 실행해야 합니다.

    1. Kubernetes API Server 정적 Pod 매니페스트를 kubelet 매니페스트 디렉터리로 다시 이동하여 kubelet이 명령을 사용하여 관련 컨테이너를 시작합니다.

      $ mv /root/manifests-backup/kube-apiserver-pod.yaml /etc/kubernetes/manifests
    2. 모든 Kubernetes API Server 컨테이너가 시작되었는지 확인합니다.

      $ crictl ps | grep kube-apiserver | grep -v operator
      참고

      다음 명령의 출력이 비어 있으면 몇 분 기다렸다가 다시 확인합니다.

    3. kube-controller-manager-pod.yamlkube-scheduler-pod.yaml 파일에 대해 동일한 단계를 반복합니다.

      1. 다음 명령을 사용하여 모든 노드에서 kubelet을 다시 시작합니다.

        $ systemctl restart kubelet
      2. 다음 명령을 사용하여 나머지 컨트롤 플레인 Pod를 시작합니다.

        $ mv /root/manifests-backup/kube-* /etc/kubernetes/manifests/
      3. kube-apiserver,kube-schedulerkube-controller-manager Pod가 올바르게 시작되었는지 확인합니다.

        $ crictl ps | grep -E 'kube-(apiserver|scheduler|controller-manager)' | grep -v -E 'operator|guard'
      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
5.3.2.4. 추가 리소스
5.3.2.5. 영구 스토리지 상태 복원을 위한 문제 및 해결 방법

OpenShift Container Platform 클러스터에서 모든 형식의 영구저장장치를 사용하는 경우 일반적으로 클러스터의 상태가 etcd 외부에 저장됩니다. StatefulSet 오브젝트에서 실행 중인 Pod 또는 데이터베이스에서 실행 중인 Elasticsearch 클러스터일 수 있습니다. etcd 백업에서 복원하면 OpenShift Container Platform의 워크로드 상태도 복원됩니다. 그러나 etcd 스냅샷이 오래된 경우 상태가 유효하지 않거나 오래되었을 수 있습니다.

중요

PV(영구 볼륨)의 내용은 etcd 스냅샷의 일부가 아닙니다. etcd 스냅샷에서 OpenShift Container Platform 클러스터를 복원할 때 중요하지 않은 워크로드가 중요한 데이터에 액세스할 수 있으며 그 반대의 경우로도 할 수 있습니다.

다음은 사용되지 않는 상태를 생성하는 몇 가지 예제 시나리오입니다.

  • MySQL 데이터베이스는 PV 오브젝트에서 지원하는 pod에서 실행됩니다. etcd 스냅샷에서 OpenShift Container Platform을 복원해도 스토리지 공급자의 볼륨을 다시 가져오지 않으며 pod를 반복적으로 시작하려고 하지만 실행 중인 MySQL pod는 생성되지 않습니다. 스토리지 공급자에서 볼륨을 복원한 다음 새 볼륨을 가리키도록 PV를 편집하여 이 Pod를 수동으로 복원해야 합니다.
  • Pod P1에서는 노드 X에 연결된 볼륨 A를 사용합니다. 다른 pod가 노드 Y에서 동일한 볼륨을 사용하는 동안 etcd 스냅샷을 가져오는 경우 etcd 복원이 수행되면 해당 볼륨이 여전히 Y 노드에 연결되어 있으므로 Pod P1이 제대로 시작되지 않을 수 있습니다. OpenShift Container Platform은 연결을 인식하지 못하고 자동으로 연결을 분리하지 않습니다. 이 경우 볼륨이 노드 X에 연결된 다음 Pod P1이 시작될 수 있도록 노드 Y에서 볼륨을 수동으로 분리해야 합니다.
  • etcd 스냅샷을 만든 후 클라우드 공급자 또는 스토리지 공급자 인증 정보가 업데이트되었습니다. 이로 인해 해당 인증 정보를 사용하는 CSI 드라이버 또는 Operator가 작동하지 않습니다. 해당 드라이버 또는 Operator에 필요한 인증 정보를 수동으로 업데이트해야 할 수 있습니다.
  • etcd 스냅샷을 만든 후 OpenShift Container Platform 노드에서 장치가 제거되거나 이름이 변경됩니다. Local Storage Operator는 /dev/disk/by-id 또는 /dev 디렉터리에서 관리하는 각 PV에 대한 심볼릭 링크를 생성합니다. 이 경우 로컬 PV가 더 이상 존재하지 않는 장치를 참조할 수 있습니다.

    이 문제를 해결하려면 관리자가 다음을 수행해야 합니다.

    1. 잘못된 장치가 있는 PV를 수동으로 제거합니다.
    2. 각 노드에서 심볼릭 링크를 제거합니다.
    3. LocalVolume 또는 LocalVolumeSet 오브젝트를 삭제합니다 (스토리지영구 스토리지 구성로컬 볼륨을 사용하는 영구 스토리지Local Storage Operator 리소스 삭제참조).

5.3.3. 만료된 컨트롤 플레인 인증서 복구

5.3.3.1. 만료된 컨트롤 플레인 인증서 복구

클러스터는 만료된 컨트롤 플레인 인증서에서 자동으로 복구될 수 있습니다.

그러나 kubelet 인증서를 복구하려면 대기 중인 node-bootstrapper 인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 사용자 프로비저닝 설치의 경우 보류 중인 kubelet 서비스 CSR을 승인해야 할 수도 있습니다.

보류중인 CSR을 승인하려면 다음 단계를 수행합니다.

절차

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

    $ oc get csr

    출력 예

    NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
    csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
    csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending
    csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 2
    csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    ...

    1
    보류 중인 kubelet 서비스 CSR(사용자 프로비저닝 설치용)입니다.
    2
    보류 중인 node-bootstrapper CSR입니다.
  2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.

    $ oc describe csr <csr_name> 1
    1
    <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
  3. 각각의 유효한 node-bootstrapper CSR을 승인합니다.

    $ oc adm certificate approve <csr_name>
  4. 사용자 프로비저닝 설치의 경우 CSR을 제공하는 각 유효한 kubelet을 승인합니다.

    $ oc adm certificate approve <csr_name>

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.