검색

4.11. 문제 해결

download PDF

OpenShift CLI 툴 또는 Velero CLI 툴 을 사용하여 Velero 사용자 정의 리소스(CR)를 디버깅할 수 있습니다. Velero CLI 툴에서는 더 자세한 로그 및 정보를 제공합니다.

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

must-gather 을 사용하여 로그 및 CR 정보를 수집할 수 있습니다.

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

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

4.11.1. Velero CLI 툴 다운로드

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

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

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

사전 요구 사항

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

절차

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

4.11.1.1. OADP-Velero-OpenShift Container Platform 버전 관계

OADP 버전Velero 버전OpenShift Container Platform 버전

1.1.0

1.9

4.9 이상

1.1.1

1.9

4.9 이상

1.1.2

1.9

4.9 이상

1.1.3

1.9

4.9 이상

1.1.4

1.9

4.9 이상

1.1.5

1.9

4.9 이상

1.1.6

1.9

4.11 이상

1.1.7

1.9

4.11 이상

1.2.0

1.11

4.11 이상

1.2.1

1.11

4.11 이상

1.2.2

1.11

4.11 이상

1.2.3

1.11

4.11 이상

1.3.0

1.12

4.10 - 4.15

1.3.1

1.12

4.10 - 4.15

1.3.2

1.12

4.10 - 4.15

1.3.3

1.12

4.10 - 4.15

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

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

사전 요구 사항

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

절차

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

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

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

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

Velero CR

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

$ oc describe <velero_cr> <cr_name>
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.11.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.11.5. 메모리 또는 CPU 부족으로 인해 Pod 충돌 또는 재시작

메모리 또는 CPU 부족으로 인해 Velero 또는 Restic Pod가 충돌하는 경우 해당 리소스 중 하나에 대한 특정 리소스 요청을 설정할 수 있습니다.

4.11.5.1. Velero Pod에 대한 리소스 요청 설정

oadp_v1alpha1_dpa.yaml 파일에서 configuration.velero.podConfig.resourceAllocations 사양 필드를 사용하여 Velero Pod에 대한 특정 리소스 요청을 설정할 수 있습니다.

절차

  • YAML 파일에서 cpumemory 리소스 요청을 설정합니다.

    Velero 파일의 예

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    configuration:
      velero:
        podConfig:
          resourceAllocations: 1
            requests:
              cpu: 200m
              memory: 256Mi

    1
    나열된 resourceAllocations 는 평균 사용량입니다.

4.11.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.11.6. StorageClass가 NFS인 경우 PodVolumeRestore가 완료되지 않음

Restic 또는 Kopia 를 사용하여 NFS 복원 중에 볼륨이 두 개 이상 있는 경우 복원 작업이 실패합니다. PodVolumeRestore 는 다음 오류와 함께 실패하거나 마지막으로 실패하기 전에 복원하려고 합니다.

오류 메시지

Velero: pod volume restore failed: data path restore failed: \
Failed to run kopia restore: Failed to copy snapshot data to the target: \
restore error: copy file: error creating file: \
open /host_pods/b4d...6/volumes/kubernetes.io~nfs/pvc-53...4e5/userdata/base/13493/2681: \
no such file or directory

원인

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

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

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

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

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

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

4.11.7.1.1. Knative 리소스 복원

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

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

절차

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

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

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

절차

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

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

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

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

4.11.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.11.7.2.1.1. 패닉 오류를 방지하기 위한 해결방법

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

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

    $ oc label BackupStorageLocation <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.11.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.11.7.2.2.1. OpenShift ADP 컨트롤러 분할 오류 해결

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

4.11.7.3. Velero 플러그인에서 "received EOF, stop recv loop" 메시지를 반환

참고

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

4.11.8. 설치 문제

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

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

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

원인

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

해결책

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

4.11.8.2. 잘못된 AWS 인증 정보

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

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

원인

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

해결책

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

credentials-velero 파일 예

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

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

4.11.9. OADP Operator 문제

OADP(OpenShift API for Data Protection) Operator는 해결할 수 없는 문제로 인해 문제가 발생할 수 있습니다.

4.11.9.1. OADP Operator가 자동으로 실패

OADP Operator의 S3 버킷은 비어 있을 수 있지만 oc get po -n <OADP_Operator_namespace> 명령을 실행하면 Operator의 상태가 Running 임을 확인할 수 있습니다. 이러한 경우 Operator는 실행 중이라고 잘못 보고하기 때문에 자동으로 실패했다고 합니다.

원인

클라우드 인증 정보가 충분하지 않은 권한을 제공하는 경우 문제가 발생합니다.

해결책

백업 스토리지 위치(BSL) 목록을 검색하고 인증 정보 문제는 각 BSL의 매니페스트를 확인합니다.

절차

  1. 다음 명령 중 하나를 실행하여 BSL 목록을 검색합니다.

    1. OpenShift CLI 사용:

      $ oc get backupstoragelocation -A
    2. Velero CLI 사용:

      $ velero backup-location get -n <OADP_Operator_namespace>
  2. BSL 목록을 사용하여 다음 명령을 실행하여 각 BSL의 매니페스트를 표시하고 각 매니페스트에 오류가 있는지 검사합니다.

    $ oc get backupstoragelocation -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.11.10. OADP 시간 초과

시간 제한을 늘리면 복잡하고 리소스를 많이 사용하는 프로세스가 조기 종료되지 않고 성공적으로 완료할 수 있습니다. 이 구성을 사용하면 오류, 재시도 또는 실패 가능성을 줄일 수 있습니다.

프로세스의 기본 문제를 숨길 수 있는 과도하게 긴 시간 초과를 구성하지 않도록 시간 초과 확장의 균형을 조정해야 합니다. 프로세스 및 전체 시스템 성능을 충족하는 적절한 시간 초과 값을 신중하게 고려하고 모니터링합니다.

다음은 이러한 매개변수를 구현하는 방법과 시기에 대한 지침이 포함된 다양한 OADP 시간 초과입니다.

4.11.10.1. Restic 타임아웃

시간 초과는 Restic 타임아웃을 정의합니다. 기본값은 1h 입니다.

다음 시나리오에 대해 Restic 타임아웃 을 사용합니다.

  • 500GB보다 큰 총 PV 데이터 사용량이 있는 Restic 백업의 경우
  • 다음 오류로 인해 백업이 시간 초과되는 경우:

    level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete"

절차

  • 다음 예와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.restic.timeout 블록에서 값을 편집합니다.

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      configuration:
        restic:
          timeout: 1h
    # ...

4.11.10.2. Velero 리소스 시간 초과

resourceTimeout 은 Velero CRD(사용자 정의 리소스 정의) 가용성, volumeSnapshot 삭제 및 리포지토리 가용성과 같이 시간 초과가 발생하기 전에 여러 Velero 리소스를 대기하는 시간을 정의합니다. 기본값은 10m 입니다.

다음 시나리오에 대해 resourceTimeout 을 사용합니다.

  • 총 PV 데이터 사용량이 1TB 이상인 백업의 경우 이 매개 변수는 Velero가 백업을 완료로 표시하기 전에 CSI(Container Storage Interface) 스냅샷을 정리하거나 삭제하려고 할 때 시간 초과 값으로 사용됩니다.

    • 이 정리의 하위 작업은 VSC 패치를 시도하며 이 시간 초과는 해당 작업에 사용할 수 있습니다.
  • Restic 또는 Kopia에 대한 파일 시스템 기반 백업에 대한 백업 리포지토리를 생성하거나 확인하려면 다음을 수행합니다.
  • CR(사용자 정의 리소스) 또는 리소스를 백업에서 복원하기 전에 클러스터에서 Velero CRD를 사용할 수 있는지 확인하려면 다음을 수행합니다.

절차

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

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      configuration:
        velero:
          resourceTimeout: 10m
    # ...

4.11.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.11.10.4. CSI 스냅샷 시간 초과

CSISnapshotTimeout 은 오류를 시간 초과로 반환하기 전에 CSI VolumeSnapshot 상태가 ReadyToUse 상태가 될 때까지 대기하는 시간을 지정합니다. 기본값은 10m 입니다.

다음 시나리오에 CSISnapshotTimeout 을 사용합니다.

  • CSI 플러그인 사용
  • 스냅샷에 10분 이상 걸릴 수 있는 대용량 스토리지 볼륨의 경우. 로그에 시간 초과가 있는 경우 이 시간 제한을 조정합니다.
참고

일반적으로 기본 설정은 대규모 스토리지 볼륨을 수용할 수 있으므로 CSISnapshotTimeout 의 기본값을 조정할 필요가 없습니다.

절차

  • 다음 예제와 같이 Backup CR 매니페스트의 spec.csiSnapshotTimeout 블록에서 값을 편집합니다.

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
     name: <backup_name>
    spec:
     csiSnapshotTimeout: 10m
    # ...

4.11.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.11.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.11.10.7. 항목 작업 제한 시간 - 백업

ItemOperationTimeout 은 비동기 BackupItemAction 작업을 대기하는 데 사용되는 시간을 지정합니다. 기본값은 1h 입니다.

다음 시나리오에는 ItemOperationTimeout 백업을 사용합니다.

  • Data Mover 1.2.x만 사용할 수 있습니다.
  • Data Mover가 BackupStorageLocation 에 업로드 및 다운로드되는 경우 . 시간 초과에 도달하면 백업 작업이 완료되지 않으면 실패로 표시됩니다. 스토리지 볼륨 크기 때문에 시간 초과 문제로 인해 데이터 Mover 작업이 실패하는 경우 이 시간 초과 설정을 늘려야 할 수 있습니다.

절차

  • 다음 예제와 같이 Backup CR 매니페스트의 Backup.spec.itemOperationTimeout 블록에서 값을 편집합니다.

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
     name: <backup_name>
    spec:
     itemOperationTimeout: 1h
    # ...

4.11.11. CR 백업 및 복원 문제

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

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

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

원인

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

해결책

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

4.11.11.2. 백업 CR 상태가 진행 중임

Backup CR의 상태는 InProgress 단계에 남아 있으며 완료되지 않습니다.

원인

백업이 중단되면 다시 시작할 수 없습니다.

해결책

  1. Backup CR의 세부 정보를 검색합니다.

    $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
      backup describe <backup>
  2. Backup CR을 삭제합니다.

    $ oc delete backup <backup> -n openshift-adp

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

  3. Backup CR을 생성합니다.
  4. Velero 백업 세부 정보 보기

    $ velero backup describe <backup-name> --details

4.11.11.3. Backup CR 상태는 PartiallyFailed에 남아 있습니다.

Restic이 사용되지 않은 Backup CR의 상태는 PartiallyFailed 단계에 남아 있으며 완료되지 않습니다. 관련 PVC의 스냅샷이 생성되지 않습니다.

원인

CSI 스냅샷 클래스를 기반으로 백업을 생성하지만 라벨이 누락된 경우 CSI 스냅샷 플러그인이 스냅샷을 생성하지 못합니다. 결과적으로 Velero pod는 다음과 유사한 오류를 기록합니다.

+

time="2023-02-17T16:33:13Z" level=error msg="Error backing up item" backup=openshift-adp/user1-backup-check5 error="error executing custom action (groupResource=persistentvolumeclaims, namespace=busy1, name=pvc1-user1): rpc error: code = Unknown desc = failed to get volumesnapshotclass for storageclass ocs-storagecluster-ceph-rbd: failed to get volumesnapshotclass for provisioner openshift-storage.rbd.csi.ceph.com, ensure that the desired volumesnapshot class has the velero.io/csi-volumesnapshot-class label" logSource="/remote-source/velero/app/pkg/backup/backup.go:417" name=busybox-79799557b5-vprq

해결책

  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.11.12. Restic 문제

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

4.11.12.1. root_squash가 활성화된 NFS 데이터 볼륨에 대한 Restic 권한 오류

Restic pod 로그에 오류 메시지 controller=pod-volume-backup error="fork/exec/usr/bin/restic: permission denied" 가 표시됩니다.

원인

NFS 데이터 볼륨에 root_squash 가 활성화된 경우 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.11.12.2. Restic Backup CR은 버킷을 꺼진 후 다시 생성할 수 없습니다.

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

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

원인

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

해결책

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

    $ oc delete resticrepository openshift-adp <name_of_the_restic_repository>

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

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

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

사전 요구 사항

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

절차

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

4.11.13.1. 안전하지 않은 TLS 연결로 must-gather 사용

사용자 정의 CA 인증서가 사용되는 경우 must-gather Pod가 velero logs/describe 의 출력을 가져오지 못합니다. 안전하지 않은 TLS 연결과 함께 must-gather 툴을 사용하려면 gather_without_tls 플래그를 must-gather 명령에 전달할 수 있습니다.

절차

  • 다음 명령을 사용하여 값이 true 로 설정된 gather_without_tls 플래그를 must-gather 툴로 전달합니다.
$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_without_tls <true/false>

기본적으로 플래그 값은 false 로 설정됩니다. 안전하지 않은 TLS 연결을 허용하려면 값을 true 로 설정합니다.

4.11.13.2. must-gather 툴을 사용할 때 옵션 결합

현재 must-gather 스크립트를 결합할 수 없습니다(예: 비보안 TLS 연결을 허용하는 동안 시간 초과 임계값 지정). 다음 예와 같이 must-gather 명령줄에서 내부 변수를 설정하여 이러한 제한 사항을 해결할 수 있습니다.

$ oc adm must-gather --image=brew.registry.redhat.io/rh-osbs/oadp-oadp-mustgather-rhel8:1.1.1-8  -- skip_tls=true /usr/bin/gather_with_timeout <timeout_value_in_seconds>

이 예제에서는 gather_with_timeout 스크립트를 실행하기 전에 skip_tls 변수를 설정합니다. 결과는 gather_with_timeoutgather_without_tls 의 조합입니다.

이렇게 지정할 수 있는 다른 변수는 다음과 같습니다.

  • logs_since 기본 값이 72h
  • request_timeout, 기본값 0s

4.11.14. OADP 모니터링

OpenShift Container Platform에서는 사용자와 관리자가 클러스터를 효과적으로 모니터링 및 관리할 수 있는 모니터링 스택을 제공하고, 이벤트가 발생하는 경우 경고 수신을 포함하여 클러스터에서 실행되는 사용자 애플리케이션 및 서비스의 워크로드 성능을 모니터링 및 분석할 수 있습니다.

추가 리소스

4.11.14.1. OADP 모니터링 설정

OADP Operator는 Velero 서비스 끝점에서 지표를 검색하기 위해 OpenShift 모니터링 스택에서 제공하는 OpenShift 사용자 워크로드 모니터링을 활용합니다. 모니터링 스택을 사용하면 OpenShift Metrics 쿼리 프런트 엔드를 사용하여 사용자 정의 경고 규칙을 생성하거나 지표를 쿼리할 수 있습니다.

활성화된 사용자 워크로드 모니터링을 사용하면 Grafana와 같은 Prometheus 호환 타사 UI를 구성하고 사용하여 Velero 지표를 시각화할 수 있습니다.

메트릭을 모니터링하려면 사용자 정의 프로젝트를 모니터링하고 ServiceMonitor 리소스를 생성하여 openshift-adp 네임스페이스에 있는 이미 활성화된 OADP 서비스 끝점에서 해당 메트릭을 스크랩해야 합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • 클러스터 모니터링 구성 맵이 생성되어 있습니다.

절차

  1. openshift-monitoring 네임스페이스에서 cluster-monitoring-config ConfigMap 오브젝트를 편집합니다.

    $ oc edit configmap cluster-monitoring-config -n openshift-monitoring
  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.11.14.2. OADP 서비스 모니터 생성

OADP는 DPA가 구성될 때 생성되는 openshift-adp-velero-metrics-svc 서비스를 제공합니다. 사용자 워크로드 모니터링에서 사용하는 서비스 모니터는 정의된 서비스를 가리켜야 합니다.

다음 명령을 실행하여 서비스에 대한 세부 정보를 가져옵니다.

절차

  1. openshift-adp-velero-metrics-svc 서비스가 있는지 확인합니다. ServiceMonitor 오브젝트의 선택기로 사용할 app.kubernetes.io/name=velero 레이블이 포함되어야 합니다.

    $ oc get svc -n openshift-adp -l app.kubernetes.io/name=velero

    출력 예

    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.11.14.3. 경고 규칙 생성

OpenShift Container Platform 모니터링 스택을 사용하면 경고 규칙을 사용하여 구성된 경고를 수신할 수 있습니다. OADP 프로젝트에 대한 경고 규칙을 생성하려면 사용자 워크로드 모니터링으로 스크랩되는 지표 중 하나를 사용합니다.

절차

  1. 샘플 OADPBackupFailing 경고를 사용하여 PrometheusRule YAML 파일을 생성하고 4_create_oadp_alert_rule.yaml 로 저장합니다.

    샘플 OADPBackupFailing 경고

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: sample-oadp-alert
      namespace: openshift-adp
    spec:
      groups:
      - name: sample-oadp-backup-alert
        rules:
        - alert: OADPBackupFailing
          annotations:
            description: 'OADP had {{$value | humanize}} backup failures over the last 2 hours.'
            summary: OADP has issues creating backups
          expr: |
            increase(velero_backup_failure_total{job="openshift-adp-velero-metrics-svc"}[2h]) > 0
          for: 5m
          labels:
            severity: warning

    이 샘플에서는 다음 조건 아래에 경고가 표시됩니다.

    • 지난 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.11.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.11.14.5. 모니터링 UI를 사용하여 메트릭 보기

OpenShift Container Platform 웹 콘솔의 관리자 또는 개발자 화면에서 메트릭을 볼 수 있습니다. openshift-adp 프로젝트에 액세스할 수 있어야 합니다.

절차

  • 모니터링 메트릭 페이지로 이동합니다.

    • 개발자 화면을 사용하는 경우 다음 단계를 따르십시오.

      1. 사용자 지정 쿼리 를 선택하거나 PromQL 표시 링크를 클릭합니다.
      2. 쿼리를 입력하고 Enter 를 클릭합니다.
    • 관리자 화면을 사용하는 경우 텍스트 필드에 표현식을 입력하고 Run Queries 를 선택합니다.

      그림 4.3. OADP 메트릭 쿼리

      OADP 메트릭 쿼리
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.