4.5. 문제 해결

OpenShift CLI 툴 또는 Velero CLI 툴 을 사용하여 Velero 사용자 정의 리소스(CR)를 디버깅할 수 있습니다. https://access.redhat.com/documentation/en-us/openshift_container_platform/4.10/html-single/backup_and_restore/#migration-debugging-velero-resources_oadp-troubleshooting Velero CLI 툴에서는 더 자세한 로그 및 정보를 제공합니다.

설치 문제,백업 및 복원 CR 문제 , Restic 문제를 확인할 수 있습니다.

must-gather 툴을 사용하여 로그, CR 정보 및 Prometheus 지표 데이터를 수집할 수 있습니다.

다음을 통해 Velero CLI 툴을 가져올 수 있습니다.

  • Velero CLI 툴 다운로드
  • 클러스터의 Velero 배포에서 Velero 바이너리에 액세스

4.5.1. Velero CLI 툴 다운로드

Velero 설명서 페이지의 지침에 따라 Velero CLI 툴을 다운로드하여 설치할 수 있습니다.

페이지에는 다음에 대한 지침이 포함되어 있습니다.

  • Homebrew를 사용하여 macOS
  • GitHub
  • Chocolatey를 사용하여 Windows

사전 요구 사항

  • DNS 및 컨테이너 네트워킹이 활성화된 Kubernetes 클러스터 v1.16 이상에 액세스할 수 있습니다.
  • kubectl 을 로컬로 설치했습니다.

절차

  1. 브라우저를 열고 Verleo 웹 사이트에서 "Install the CLI" 로 이동합니다.
  2. macOS, GitHub 또는 Windows에 대한 적절한 절차를 따르십시오.
  3. 다음 표에 따라 OADP 및 OpenShift Container Platform 버전에 적합한 Velero 버전을 다운로드합니다.

    표 4.2. OADP-Velero-OpenShift Container Platform 버전 관계

    OADP 버전Velero 버전OpenShift Container Platform 버전

    1.0.0

    1.7

    4.6 이상

    1.0.1

    1.7

    4.6 이상

    1.0.2

    1.7

    4.6 이상

    1.0.3

    1.7

    4.6 이상

    1.1.0

    {velero-version}

    4.9 이상

    1.1.1

    {velero-version}

    4.9 이상

    1.1.2

    {velero-version}

    4.9 이상

4.5.2. 클러스터의 Velero 배포에서 Velero 바이너리에 액세스

shell 명령을 사용하여 클러스터의 Velero 배포에서 Velero 바이너리에 액세스할 수 있습니다.

사전 요구 사항

  • DataProtectionApplication 사용자 정의 리소스의 상태는 Reconcile complete.

절차

  • 다음 명령을 입력하여 필요한 별칭을 설정합니다.

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'

4.5.3. OpenShift CLI 툴을 사용하여 Velero 리소스 디버깅

OpenShift CLI 툴을 사용하여 Velero 사용자 정의 리소스(CR) 및 Velero Pod 로그를 확인하여 실패한 백업 또는 복원을 디버깅할 수 있습니다.

Velero CR

oc describe 명령을 사용하여 Backup 또는 Restore CR과 관련된 경고 및 오류 요약을 검색합니다.

$ oc describe <velero_cr> <cr_name>
Velero 포드 로그

oc logs 명령을 사용하여 Velero 포드 로그를 검색합니다.

$ 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

대부분의 로그에 debug 를 사용하는 것이 좋습니다.

4.5.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

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.5.5. Velero 및 승인 Webhook 관련 문제

Velero는 복원 중 승인 Webhook 문제를 해결할 수 있는 기능이 제한되어 있습니다. 승인 Webhook가 있는 워크로드가 있는 경우 추가 Velero 플러그인을 사용하거나 워크로드를 복원하는 방법을 변경해야 할 수 있습니다.

일반적으로 승인 Webhook가 있는 워크로드에서는 먼저 특정 종류의 리소스를 생성해야 합니다. 승인 Webhook가 일반적으로 하위 리소스를 차단하기 때문에 워크로드에 하위 리소스가 있는 경우 특히 중요합니다.

예를 들어 service.serving.knative.dev 와 같은 최상위 오브젝트를 생성하거나 복원하면 일반적으로 하위 리소스가 자동으로 생성됩니다. 먼저 이 작업을 수행하는 경우 Velero를 사용하여 이러한 리소스를 생성하고 복원할 필요가 없습니다. 그러면 Velero가 사용할 수 있는 승인 Webhook에 의해 차단되는 하위 리소스의 문제를 방지할 수 있습니다.

4.5.5.1. 승인 Webhook를 사용하는 Velero 백업의 해결방법 복원

이 섹션에서는 승인 Webhook를 사용하는 여러 유형의 Velero 백업에 대한 리소스를 복원하는 데 필요한 추가 단계를 설명합니다.

4.5.5.1.1. Knative 리소스 복원

승인 Webhook를 사용하는 Knative 리소스를 백업하려면 Velero를 사용하여 문제가 발생할 수 있습니다.

승인 Webhook를 사용하는 Knative 리소스를 백업 및 복원할 때마다 최상위 서비스 리소스를 복원하여 이러한 문제를 방지할 수 있습니다.

절차

  • 최상위 서비스.serving.knavtive.dev Service 리소스를 복원합니다.

    $ velero restore <restore_name> \
      --from-backup=<backup_name> --include-resources \
      service.serving.knavtive.dev
4.5.5.1.2. IBM AppConnect 리소스 복원

승인 Webhook가 있는 IBM AppConnect 리소스를 복원하기 위해 Velero를 사용할 때 문제가 발생하는 경우 이 프로세스에서 검사를 실행할 수 있습니다.

절차

  1. 클러스터에 변경 승인 플러그인이 있는지 확인합니다 : MutatingWebhookConfiguration.

    $ oc get mutatingwebhookconfigurations
  2. kind: MutatingWebhookConfiguration 의 YAML 파일을 검사하여 문제가 발생한 오브젝트의 규칙 블록 생성이 없는지 확인합니다. 자세한 내용은 공식 Kuberbetes 설명서를 참조하십시오.
  3. 유형에 있는 spec.version: Configuration.appconnect.ibm.com/v1beta1 이 설치된 Operator에서 지원되는지 확인합니다.

4.5.6. 설치 문제

데이터 보호 애플리케이션을 설치할 때 유효하지 않은 디렉토리 또는 잘못된 인증 정보를 사용하여 발생한 문제가 발생할 수 있습니다.

4.5.6.1. 백업 스토리지에는 잘못된 디렉터리가 포함되어 있습니다.

Velero 포드 로그에 오류 메시지가 표시되고 Backup 스토리지에 잘못된 최상위 디렉터리가 포함되어 있습니다.

원인

오브젝트 스토리지에는 Velero 디렉터리가 아닌 최상위 디렉터리가 포함되어 있습니다.

해결책

오브젝트 스토리지가 Velero 전용이 아닌 경우 DataProtectionApplication 매니페스트에서 spec.backupLocations.velero.objectStorage.prefix 매개변수를 설정하여 버킷에 대한 접두사를 지정해야 합니다.

4.5.6.2. 잘못된 AWS 인증 정보

oadp-aws-registry Pod 로그에는 오류 메시지, InvalidAccessKeyId: AWS Access Key Id가 저희 레코드에 존재하지 않습니다.

Velero Pod 로그에 오류 메시지 NoCredentialProviders: no valid providers in chain.

원인

Secret 오브젝트를 생성하는 데 사용되는 credentials-velero 파일이 잘못 포맷됩니다.

해결책

다음 예와 같이 credentials-velero 파일이 올바르게 포맷되어 있는지 확인합니다.

credentials-velero 파일 예

[default] 1
aws_access_key_id=AKIAIOSFODNN7EXAMPLE 2
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

1
AWS 기본 프로필.
2
따옴표로 값을 묶지 마십시오(", '.).

4.5.7. CR 백업 및 복원 문제

백업 및 CR(사용자 정의 리소스)과 관련된 일반적인 문제가 발생할 수 있습니다.

4.5.7.1. 백업 CR은 볼륨을 검색할 수 없음

Backup CR에 오류 메시지 InvalidVolume.NotFound: 볼륨 'vol-xxxx'가 존재하지 않습니다.

원인

PV(영구 볼륨) 및 스냅샷 위치는 다른 지역에 있습니다.

해결책

  1. DataProtectionApplication 매니페스트에서 spec.snapshotLocations.velero.config.region 키 값을 편집하여 스냅샷 위치가 PV와 동일한 리전에 있도록 합니다.
  2. Backup CR을 생성합니다.

4.5.7.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 backup <backup> -n openshift-adp

    진행중인 Backup CR이 오브젝트 스토리지에 파일을 업로드하지 않았기 때문에 백업 위치를 정리할 필요가 없습니다.

  3. Backup CR을 생성합니다.

4.5.7.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 backup <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. Backup CR을 생성합니다.

4.5.8. Restic 문제

Restic을 사용하여 애플리케이션을 백업할 때 이러한 문제가 발생할 수 있습니다.

4.5.8.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.restic.supplementalGroups 매개변수와 그룹 ID를 DataProtectionApplication 매니페스트에 추가합니다.

    spec:
      configuration:
        restic:
          enable: true
          supplementalGroups:
          - <group_id> 1
    1
    보조 그룹 ID를 지정합니다.
  4. 변경 사항을 적용할 수 있도록 Restic Pod가 다시 시작될 때까지 기다립니다.

4.5.8.2. Restic Backup CR은 버킷을 꺼진 후 다시 생성할 수 없습니다.

네임스페이스에 대한 Restic Backup CR을 생성하고 오브젝트 스토리지 버킷을 비우고 동일한 네임스페이스에 Backup CR을 다시 생성하면 다시 만든 Backup CR이 실패합니다.

velero Pod 로그에는 다음과 같은 오류 메시지가 표시됩니다. stderr=Fatal: unable to open config file: criteria: specified key does not exist.\nIs there a repository at the following location?.

원인

Velero는 Restic 디렉터리가 오브젝트 스토리지에서 삭제되면 ResticRepository 매니페스트에서 Restic 리포지토리를 다시 생성하거나 업데이트하지 않습니다. 자세한 내용은 Velero issue 4421 을 참조하십시오.

해결책

  • 다음 명령을 실행하여 네임스페이스에서 관련 Restic 리포지토리를 제거합니다.

    $ oc delete resticrepository openshift-adp <name_of_the_restic_repository>

    다음 오류 로그에서 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.5.9. must-gather 툴 사용

must-gather 툴을 사용하여 OADP 사용자 정의 리소스에 대한 로그, 메트릭 및 정보를 수집할 수 있습니다.

must-gather 데이터는 모든 고객 사례에 첨부되어야 합니다.

사전 요구 사항

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

절차

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. 다음 데이터 수집 옵션 중 하나에 대해 oc adm must-gather 명령을 실행합니다.

    $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.1

    데이터는 must-gather/must-gather.tar.gz 로 저장됩니다. Red Hat 고객 포털에서 해당 지원 사례에 이 파일을 업로드할 수 있습니다.

    $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.1 \
      -- /usr/bin/gather_metrics_dump

    이 작업에는 오랜 시간이 걸릴 수 있습니다. 데이터는 must-gather/metrics/prom_data.tar.gz 로 저장됩니다.

Prometheus 콘솔을 사용하여 메트릭 데이터 보기

Prometheus 콘솔을 사용하여 메트릭 데이터를 볼 수 있습니다.

절차

  1. prom_data.tar.gz 파일의 압축을 풉니다.

    $ tar -xvzf must-gather/metrics/prom_data.tar.gz
  2. 로컬 Prometheus 인스턴스를 생성합니다.

    $ make prometheus-run

    이 명령은 Prometheus URL을 출력합니다.

    출력 결과

    Started Prometheus on http://localhost:9090

  3. 웹 브라우저를 시작하고 URL로 이동하여 Prometheus 웹 콘솔을 사용하여 데이터를 확인합니다.
  4. 데이터를 보고 나면 Prometheus 인스턴스 및 데이터를 삭제합니다.

    $ make prometheus-cleanup