검색

4.13. 고급 OADP 기능 및 기능

download PDF

이 문서에서는 OADP(OpenShift API for Data Protection)의 고급 기능 및 기능에 대한 정보를 제공합니다.

4.13.1. 동일한 클러스터에서 다양한 Kubernetes API 버전 작업

4.13.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.13.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입니다.

Enable API Group Versions 기능을 활성화하지 않으면 Velero는 예의 기본 API 그룹 버전( 예: example.com/v 1)만 백업합니다. 기능이 활성화된 경우 Velero도 example.com/v1beta2 를 백업합니다.

대상 클러스터에서 Enable API Group Versions 기능이 활성화되면 Velero는 API 그룹 버전의 우선 순위 순서에 따라 복원할 버전을 선택합니다.

참고

API 그룹 버전 활성화는 아직 베타 버전입니다.

Velero는 다음 알고리즘을 사용하여 API 버전에 우선 순위를 지정하고 1 를 최상위 우선 순위로 할당합니다.

  1. 대상 클러스터의 기본 버전
  2. source_ 클러스터의 기본 버전
  3. Kubernetes 버전 우선 순위가 가장 높은 일반적인 지원되지 않는 버전

4.13.1.3. API 그룹 버전 사용

Velero의 Enable API Group Versions 기능을 사용하여 기본 설정뿐만 아니라 클러스터에서 지원되는 모든 Kubernetes API 그룹 버전을 백업할 수 있습니다.

참고

API 그룹 버전 활성화는 아직 베타 버전입니다.

절차

  • EnableAPIGroupVersions 기능을 구성합니다.
apiVersion: oadp.openshift.io/vialpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      featureFlags:
      - EnableAPIGroupVersions

4.13.2. 한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원

4.13.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.13.2.1.1. Operator

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

4.13.2.1.2. Velero 사용

OADP가 구축된 Velero는 기본적으로 클라우드 공급자 간에 영구 볼륨 스냅샷 마이그레이션을 지원하지 않습니다. 클라우드 플랫폼 간에 볼륨 스냅샷 데이터를 마이그레이션하려면 파일 시스템 수준에서 볼륨 콘텐츠를 백업하는 Velero Restic 파일 시스템 백업 옵션을 활성화 하거나 CSI 스냅샷에 대해 OADP Data Mover를 사용해야 합니다.

참고

OADP 1.1 및 이전 버전에서는 Velero Restic 파일 시스템 백업 옵션을 restic 이라고 합니다. OADP 1.2 이상에서는 Velero Restic 파일 시스템 백업 옵션을 file-system-backup 이라고 합니다.

  • 또한 Velero의 파일 시스템 백업을 사용하여 AWS 리전 간에 데이터를 마이그레이션하거나 Microsoft Azure 리전 간에 데이터를 마이그레이션해야 합니다.
  • Velero는 소스 클러스터보다 이전 Kubernetes 버전의 클러스터로 데이터 복원을 지원하지 않습니다.
  • 이론적으로 소스보다 최신 Kubernetes 버전이 있는 대상으로 워크로드를 마이그레이션할 수 있지만 각 사용자 지정 리소스에 대한 클러스터 간 API 그룹의 호환성을 고려해야 합니다. Kubernetes 버전 업그레이드에서 코어 또는 네이티브 API 그룹의 호환성을 중단하는 경우 먼저 영향을 받는 사용자 정의 리소스를 업데이트해야 합니다.

4.13.2.2. 백업할 Pod 볼륨 확인 정보

파일 시스템 백업(FSB)을 사용하여 백업 작업을 시작하기 전에 백업할 볼륨이 포함된 Pod를 지정해야 합니다. Velero는 이 프로세스를 적절한 Pod 볼륨을 "검색"이라고 합니다.

Velero는 Pod 볼륨을 결정하기 위해 다음 두 가지 접근 방식을 지원합니다.

  • 옵트인 접근 방식: 옵트인 접근 방식을 사용하려면 적극적으로 - 옵트인( opt-in ) - 백업에 볼륨(볼륨)을 포함해야 합니다. 볼륨 이름으로 백업할 볼륨이 포함된 각 Pod에 레이블을 지정하여 이 작업을 수행합니다. Velero가 PV(영구 볼륨)를 찾으면 볼륨을 마운트된 Pod를 확인합니다. Pod에 볼륨 이름으로 레이블이 지정되면 Velero가 Pod를 백업합니다.
  • 옵트아웃 접근 방식에서는 옵트아웃 접근 방식을 사용하여 백업에서 볼륨을 제외하도록 적극적으로 지정해야 합니다. 볼륨 이름으로 백업하지 않는 볼륨이 포함된 각 Pod에 레이블을 지정하여 이 작업을 수행합니다. Velero가 PV를 찾으면 볼륨을 마운트된 Pod를 확인합니다. Pod에 볼륨 이름으로 레이블이 지정되면 Velero에서 Pod를 백업하지 않습니다.
4.13.2.2.1. 제한
  • FSB는 hostpath 볼륨 백업 및 복원을 지원하지 않습니다. 그러나 FSB는 로컬 볼륨 백업 및 복원을 지원합니다.
  • Velero는 생성하는 모든 백업 리포지토리에 정적, 공통 암호화 키를 사용합니다. 이 정적 키는 백업 스토리지에 액세스할 수 있는 모든 사용자가 백업 데이터를 해독할 수 있음을 의미합니다. 백업 스토리지에 대한 액세스를 제한하는 것이 중요합니다.
  • PVC의 경우 Pod 일정을 변경할 때마다 모든 증분 백업 체인이 유지됩니다.

    emptyDir 볼륨과 같이 PVC가 아닌 Pod 볼륨의 경우(예: ReplicaSet 또는 배포) Pod가 삭제되거나 다시 생성되는 경우 해당 볼륨의 다음 백업은 증분 백업이 아닌 전체 백업이 됩니다. Pod 볼륨의 라이프사이클이 해당 Pod에 의해 정의되는 것으로 가정합니다.

  • 백업 데이터를 점진적으로 유지할 수 있지만 데이터베이스와 같은 대용량 파일을 백업하는 데 시간이 오래 걸릴 수 있습니다. FSB는 중복 제거를 사용하여 백업해야 하는 차이점을 찾기 때문입니다.
  • FSB는 Pod가 실행 중인 노드의 파일 시스템에 액세스하여 볼륨에서 데이터를 읽고 씁니다. 이러한 이유로 FSB는 PVC에서 직접 마운트하지 않고 Pod에서 마운트된 볼륨만 백업할 수 있습니다. 일부 Velero 사용자는 Velero 백업을 수행하기 전에 이러한 PVC 및 PV 쌍을 마운트하도록 BusyBox 또는 Alpine 컨테이너와 같은 스테이징 Pod를 실행하여 이 제한을 극복했습니다.
  • FSB에서는 < hostPath>/<pod UID > 아래에 볼륨을 마운트할 것으로 예상하고, < hostPath >를 구성할 수 있습니다. 예를 들어 vCluster와 같은 일부 Kubernetes 시스템은 < pod UID > 하위 디렉터리 아래에 볼륨을 마운트하지 않으며 VFSB는 예상대로 작동하지 않습니다.
4.13.2.2.2. 옵트인 방법을 사용하여 Pod 볼륨 백업

옵트인 방법을 사용하여 파일 시스템 백업(FSB)에서 백업해야 하는 볼륨을 지정할 수 있습니다. backup.velero.io/backup-volumes 명령을 사용하여 이 작업을 수행할 수 있습니다.

절차

  • 백업할 볼륨이 하나 이상 포함된 각 Pod에서 다음 명령을 입력합니다.

    $ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \
      backup.velero.io/backup-volumes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>

    다음과 같습니다.

    <your_volume_name_x>
    Pod 사양에 xth 볼륨의 이름을 지정합니다.
4.13.2.2.3. 옵트아웃 방법을 사용하여 Pod 볼륨 백업

옵트아웃 접근 방식을 사용하는 경우 몇 가지 예외가 있지만 FSB(File System Backup)를 사용하여 모든 Pod 볼륨이 백업됩니다.

  • 기본 서비스 계정 토큰, 시크릿 및 구성 맵을 마운트하는 볼륨입니다.
  • hostPath 볼륨

옵트아웃 방법을 사용하여 백업 하지 않는 볼륨을 지정할 수 있습니다. backup.velero.io/backup-volumes-excludes 명령을 사용하여 이 작업을 수행할 수 있습니다.

절차

  • 백업하지 않으려는 볼륨이 하나 이상 포함된 각 Pod에서 다음 명령을 실행합니다.

    $ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \
      backup.velero.io/backup-volumes-excludes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>

    다음과 같습니다.

    <your_volume_name_x>
    Pod 사양에 xth 볼륨의 이름을 지정합니다.
참고

--default-volumes-to-fs-backup 플래그를 사용하여 velero install 명령을 실행하여 모든 Velero 백업에 대해 이 동작을 활성화할 수 있습니다.

4.13.2.3. UID 및 GID 범위

한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원하는 경우 UID(사용자 ID) 및 GID(그룹 ID) 범위에서 문제가 발생할 수 있습니다. 다음 섹션에서는 이러한 잠재적인 문제 및 완화 방법에 대해 설명합니다.

문제 요약
대상 클러스터에 따라 네임스페이스 UID 및 GID 범위가 변경될 수 있습니다. OADP는 OpenShift UID 범위 메타데이터를 백업하고 복원하지 않습니다. 백업 애플리케이션에 특정 UID가 필요한 경우 범위를 사용할 수 있는지 확인합니다. OpenShift의 UID 및 GID 범위에 대한 자세한 내용은 A Guide to OpenShift and UIDs 를 참조하십시오.
문제에 대한 자세한 설명

쉘 명령 oc create namespace 를 사용하여 OpenShift Container Platform에서 네임스페이스를 생성할 때 OpenShift Container Platform은 사용 가능한 UID 풀, 추가 그룹(GID) 범위 및 고유한 SELinux MCS 레이블에서 네임스페이스에 고유한 UID(사용자 ID) 범위를 할당합니다. 이 정보는 클러스터의 metadata.annotations 필드에 저장됩니다. 이 정보는 다음 구성 요소로 구성된 SCC(보안 컨텍스트 제약 조건) 주석의 일부입니다.

  • openshift.io/sa.scc.mcs
  • openshift.io/sa.scc.supplemental-groups
  • openshift.io/sa.scc.uid-range

OADP를 사용하여 네임스페이스를 복원하면 대상 클러스터에 대해 재설정하지 않고 metadata.annotations 의 정보를 자동으로 사용합니다. 결과적으로 다음 중 하나라도 해당하는 경우 워크로드가 백업된 데이터에 액세스할 수 없을 수 있습니다.

  • 다른 SCC 주석이 있는 기존 네임스페이스가 있습니다(예: 다른 클러스터에). 이 경우 OADP는 복원하려는 네임스페이스 대신 백업 중에 기존 네임스페이스를 사용합니다.
  • 백업 중에 레이블 선택기가 사용되었지만 워크로드가 실행되는 네임스페이스에 레이블이 없습니다. 이 경우 OADP는 네임스페이스를 백업하지 않지만 백업 네임스페이스의 주석이 포함되지 않은 복원 중에 새 네임스페이스를 생성합니다. 그러면 새 UID 범위가 네임스페이스에 할당됩니다.

    이는 OpenShift Container Platform에서 영구 볼륨 데이터가 백업된 이후 변경된 네임스페이스 주석을 기반으로 Pod에 securityContext UID를 할당하는 경우 고객 워크로드에 문제가 될 수 있습니다.

  • 컨테이너의 UID가 더 이상 파일 소유자의 UID와 일치하지 않습니다.
  • OpenShift Container Platform이 백업 클러스터 데이터와 일치하도록 대상 클러스터의 UID 범위를 변경하지 않았기 때문에 오류가 발생합니다. 결과적으로 백업 클러스터에는 대상 클러스터와 다른 UID가 있으므로 애플리케이션이 대상 클러스터에서 데이터를 읽거나 쓸 수 없습니다.

    완화 방법
    다음 완화 방법 중 하나를 사용하여 UID 및 GID 범위 문제를 해결할 수 있습니다.
  • 간단한 완화 방법:

    • Backup CR에서 라벨 선택기를 사용하여 백업에 포함할 오브젝트를 필터링하는 경우 이 라벨 선택기를 작업 공간이 포함된 네임스페이스에 추가해야 합니다.
    • 동일한 이름의 네임스페이스를 복원하기 전에 대상 클러스터에서 기존 네임스페이스 버전을 제거합니다.
  • 고급 완화 방법:

한 클러스터에서 데이터를 백업하고 다른 클러스터에서 데이터를 복원하는 데 있는 문제를 해결하면서 OpenShift Container Platform의 UID 및 GID 범위에 대한 자세한 내용은 OpenShift 및 UID에 대한 가이드를 참조하십시오.

4.13.2.4. 한 클러스터에서 데이터를 백업하고 다른 클러스터로 복원

일반적으로 하나의 OpenShift Container Platform 클러스터의 데이터를 백업하고 동일한 클러스터에 데이터를 백업하고 복원하는 것과 동일한 방식으로 다른 OpenShift Container Platform 클러스터에 복원합니다. 그러나 한 OpenShift Container Platform 클러스터에서 데이터를 백업하고 다른 OpenShift Container Platform 클러스터에서 복원할 때 프로세스에 몇 가지 추가 사전 요구 사항과 차이점이 있습니다.

사전 요구 사항

  • 플랫폼(예: AWS, Microsoft Azure, GCP 등)에서 백업 및 복원을 위한 모든 관련 사전 요구 사항은 이 가이드의 관련 섹션에 설명되어 있습니다.

절차

  • 플랫폼에 지정된 절차를 추가합니다.

    • 백업 저장소 위치(BSL) 및 볼륨 스냅샷 위치에 다른 클러스터의 리소스를 복원하는 것과 동일한 이름과 경로가 있는지 확인합니다.
    • 클러스터 전체에서 동일한 오브젝트 스토리지 위치 인증 정보를 공유합니다.
    • 최상의 결과를 얻으려면 OADP를 사용하여 대상 클러스터에 네임스페이스를 생성합니다.
    • Velero file-system-backup 옵션을 사용하는 경우 다음 명령을 실행하여 백업 중에 사용할 --default-volumes-to-fs-backup 플래그를 활성화합니다.

      $ velero backup create <backup_name> --default-volumes-to-fs-backup <any_other_options>
참고

OADP 1.2 이상에서는 Velero Restic 옵션을 file-system-backup 이라고 합니다.

4.13.3. 추가 리소스

API 그룹 버전에 대한 자세한 내용은 동일한 클러스터에서 다양한 Kubernetes API 버전 작업을 참조하십시오.

OADP Data Mover에 대한 자세한 내용은 CSI 스냅샷에 Data Mover 사용을 참조하십시오.

OADP에서 Restic을 사용하는 방법에 대한 자세한 내용은 Restic을 사용하여 애플리케이션 백업을 참조하십시오.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.