6.3. 클러스터 경고 해결


Red Hat Ceph Storage 클러스터가 OpenShift Data Foundation 사용자 인터페이스에 표시될 수 있는 제한된 상태 경고 세트가 있습니다. 이러한 경고는 고유 식별자가 있는 상태 경고로 정의됩니다. 식별자는 툴에서 상태 점검을 감지하여 의미를 반영하는 방식으로 제공할 수 있도록 하기 위한 의사 사람이 읽을 수 있는 문자열입니다. 자세한 내용 및 문제 해결을 위해 상태 경고를 클릭합니다.

표 6.1. 클러스터 상태 경고 유형
상태 경고개요

CephClusterCriticallyFull

스토리지 클러스터 사용률은 80%를 초과했습니다.

CephClusterErrorState

스토리지 클러스터는 10분 이상 오류 상태입니다.

CephClusterNearFull

스토리지 클러스터가 전체 용량에 가까워지고 있습니다. 데이터 삭제 또는 클러스터 확장이 필요합니다.

CephClusterReadOnly

스토리지 클러스터는 이제 읽기 전용이며 즉시 데이터 삭제 또는 클러스터 확장이 필요합니다.

CephClusterWarningState

스토리지 클러스터는 10분 이상 경고 상태입니다.

CephDataRecoveryTakingTooLong

데이터 복구는 너무 오래 지속되었습니다.

CephMdsCacheUsageHigh

MDS 데몬의 Ceph 메타데이터 서비스(MDS) 캐시 사용량이 mds_cache_memory_limit 의 95%를 초과했습니다.

CephMdsCpuUsageHigh

MDS 데몬의 Ceph MDS CPU 사용량이 적절한 성능을 위해 임계값을 초과했습니다.

CephMdsMissingReplicas

스토리지 메타데이터 서비스에 필요한 최소 복제본을 사용할 수 없습니다. 스토리지 클러스터의 작동에 영향을 미칠 수 있습니다.

CephMgrIsAbsent

Ceph Manager는 Prometheus 대상 검색에서 사라졌습니다.

CephMgrIsMissingReplicas

Ceph 관리자가 복제본이 누락되어 있습니다. 이pts 상태 보고 및 ceph status 명령에서 보고한 일부 정보가 누락되거나 오래된 정보를 발생시킵니다. 또한 Ceph 관리자는 Ceph의 기존 기능을 확장하기 위한 관리자 프레임워크를 담당합니다.

CephMonHighNumberOfLeaderChanges

Ceph 모니터 리더는 비정상적으로 변경되고 있습니다.

CephMonQuorumAtRisk

스토리지 클러스터 쿼럼이 낮습니다.

CephMonQuorumLost

스토리지 클러스터의 모니터 Pod 수로는 충분하지 않습니다.

CephMonVersionMismatch

다양한 버전의 Ceph Mon 구성 요소가 실행되고 있습니다.

CephNodeDown

스토리지 노드가 중단되었습니다. 노드를 즉시 확인합니다. 경고에는 노드 이름이 포함되어야 합니다.

CephOSDCriticallyFull

백엔드 OSD(오브젝트 스토리지 장치)의 사용률은 80%를 초과했습니다. 일부 공간을 즉시 확보하거나 스토리지 클러스터를 확장하거나 지원 팀에 문의하십시오.

CephOSDDiskNotResponding

디스크 장치가 호스트 중 하나에 응답하지 않습니다.

CephOSDDiskUnavailable

호스트 중 하나에서 디스크 장치에 액세스할 수 없습니다.

CephOSDFlapping

Ceph 스토리지 OSD 풀링.

CephOSDNearFull

OSD 스토리지 장치 중 하나가 완전히 가까워지고 있습니다.

CephOSDSlowOps

OSD 요청은 처리하는 데 시간이 너무 오래 걸립니다.

CephOSDVersionMismatch

다양한 버전의 Ceph OSD 구성 요소가 실행되고 있습니다.

CephPGRepairTakingTooLong

자동 복구 작업에는 시간이 너무 오래 걸립니다.

CephPoolQuotaBytesCriticallyExhausted

스토리지 풀 할당량 사용량은 90%를 초과했습니다.

CephPoolQuotaBytesNearExhaustion

스토리지 풀 할당량 사용량은 70%를 초과했습니다.

OSDCPULoadHigh

특정 Pod의 OSD 컨테이너의 CPU 사용량이 80%를 초과하여 OSD 성능에 영향을 미칠 수 있습니다.

PersistentVolumeUsageCritical

영구 볼륨 클레임 사용량이 용량의 85%를 초과했습니다.

PersistentVolumeUsageNearFull

영구 볼륨 클레임 사용량이 용량의 75%를 초과했습니다.

6.3.1. CephClusterCriticallyFull

의미

스토리지 클러스터 사용률은 80%를 초과하여 85%로 읽기 전용입니다. 사용률이 85%를 초과하면 Ceph 클러스터가 읽기 전용입니다. 일부 공간을 확보하거나 스토리지 클러스터를 즉시 확장합니다. 일반적으로 이 경고에 앞서 전체 또는 전체 오브젝트 스토리지 장치(OSD)와 관련된 경고를 볼 수 있습니다.

보안 등급

높음

진단

Scaling storage
클러스터 유형에 따라 스토리지 장치, 노드 또는 둘 다를 추가해야 합니다. 자세한 내용은 스토리지 확장 가이드를 참조하십시오.

완화 방법

정보 삭제
클러스터를 확장할 수 없는 경우 정보를 삭제하여 일부 공간을 확보해야 합니다.

6.3.2. CephClusterErrorState

의미

이 경고는 스토리지 클러스터가 허용되지 않는 시간 동안 ERROR 상태이고 스토리지 가용성을 반영합니다. 이 전에 트리거된 다른 경고가 있는지 확인하고 먼저 해당 경고 문제를 해결합니다.

보안 등급

심각

진단

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    $ oc get pod | grep rook-ceph
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a rook-ceph that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.

    $ oc logs pod/${MYPOD}
    중요
    • 노드가 할당된 경우 노드에서 kubelet을 확인합니다.
    • 실행 중인 Pod의 기본 상태, 노드에서 노드 유사성 및 리소스 가용성이 확인되면 Ceph 툴을 실행하여 스토리지 구성 요소의 상태를 가져옵니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.3. CephClusterNearFull

의미

스토리지 클러스터 사용률은 75%를 초과하여 85%로 읽기 전용입니다. 일부 공간을 확보하거나 스토리지 클러스터를 확장합니다.

보안 등급

심각

진단

Scaling storage
클러스터 유형에 따라 스토리지 장치, 노드 또는 둘 다를 추가해야 합니다. 자세한 내용은 스토리지 확장 가이드를 참조하십시오.

완화 방법

정보 삭제
클러스터를 확장할 수 없는 경우 일부 공간을 확보하기 위해 정보를 삭제해야 합니다.

6.3.4. CephClusterReadOnly

의미

스토리지 클러스터 사용률은 85%를 초과했으며 이제 읽기 전용입니다. 일부 공간을 확보하거나 스토리지 클러스터를 즉시 확장합니다.

보안 등급

심각

진단

Scaling storage
클러스터 유형에 따라 스토리지 장치, 노드 또는 둘 다를 추가해야 합니다. 자세한 내용은 스토리지 확장 가이드를 참조하십시오.

완화 방법

정보 삭제
클러스터를 확장할 수 없는 경우 일부 공간을 확보하기 위해 정보를 삭제해야 합니다.

6.3.5. CephClusterWarningState

의미

이 경고는 스토리지 클러스터가 허용되지 않는 시간 동안 경고 상태에 있음을 반영합니다. 스토리지 작업이 이 상태에서 계속 작동하지만 클러스터가 오류 상태가 되지 않도록 오류를 수정하는 것이 좋습니다. 이 전에 트리거되었을 수 있는 다른 경고를 확인하고 먼저 해당 경고 문제를 해결합니다.

보안 등급

높음

진단

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep {ceph-component}
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.6. CephDataRecoveryTakingTooLong

의미

데이터 복구 속도가 느리다. 모든 OSD(오브젝트 스토리지 장치)가 실행 중인지 확인합니다.

보안 등급

높음

진단

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-osd
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.7. CephMdsCacheUsageHigh

의미

스토리지 메타데이터 서비스(MDS)에서 캐시 사용량을 mds_health_cache_threshold 또는 mds_cache_memory_limit 에 의해 설정된 캐시 제한의 150% 아래에 캐시 사용량을 유지할 수 없는 경우 MDS는 캐시가 너무 큰 것을 나타내는 상태 경고를 모니터에 보냅니다. 결과적으로 MDS 관련 작업이 느려집니다.

보안 등급

높음

진단

MDS는 캐시에서 사용되지 않는 메타데이터를 트리밍하고 클라이언트 캐시의 캐시된 항목을 회수하여 mds_cache_memory_limit 예약을 유지하려고 합니다. 여러 클라이언트가 파일을 늘리기 때문에 MDS가 클라이언트에서 느린 회수로 인해 이 제한을 초과할 수 있습니다.

완화 방법

MDS 캐시에 대해 충분한 메모리가 프로비저닝되었는지 확인합니다. mds_cache_memory_limit 를 늘리려면 MDS Pod의 메모리 리소스를 ocs-storageCluster 에서 업데이트해야 합니다. 다음 명령을 실행하여 MDS Pod의 메모리를 설정합니다(예: 16GB).

$ oc patch -n openshift-storage storagecluster ocs-storagecluster \
    --type merge \
    --patch '{"spec": {"resources": {"mds": {"limits": {"memory": "16Gi"},"requests": {"memory": "16Gi"}}}}}'

OpenShift Data Foundation은 mds_cache_memory_limit 를 MDS Pod 메모리 제한의 절반으로 자동으로 설정합니다. 이전 명령을 사용하여 메모리를 8GB로 설정하면 Operator에서 MDS 캐시 메모리 제한을 4GB로 설정합니다.

6.3.8. CephMdsCpuUsageHigh

의미

스토리지 메타데이터 서비스(MDS)는 파일 시스템 메타데이터를 제공합니다. MDS는 모든 파일 생성, 이름 변경, 삭제 및 업데이트 작업에 중요합니다. MDS에는 기본적으로 두 개 또는 세 개의 CPU가 할당됩니다. 메타데이터 작업이 너무 많지 않은 한 문제가 발생하지 않습니다. 메타데이터 작업 부하가 이 경고를 트리거할 수 있을 만큼 증가하면 기본 CPU 할당이 로드에 대처할 수 없음을 의미합니다. CPU 할당을 늘려야 합니다.

보안 등급

높음

진단

워크로드 포드 를 클릭합니다. 해당 MDS Pod를 선택하고 지표 탭을 클릭합니다. 그러면 할당되고 사용된 CPU가 표시됩니다. 기본적으로 사용된 CPU가 6시간 동안 할당된 CPU의 67%인 경우 경고가 실행됩니다. 이 경우 완화 섹션의 단계를 수행합니다.

완화 방법

할당된 CPU를 늘려야 합니다.

다음 명령을 사용하여 MDS에 할당된 CPU 수를 설정합니다(예: 8).

$ oc patch -n openshift-storage storagecluster ocs-storagecluster \
    --type merge \
    --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "8"},
    "requests": {"cpu": "8"}}}}}'

6.3.9. CephMdsMissingReplicas

의미

스토리지 메타데이터 서비스(MDS)에 필요한 최소 복제본을 사용할 수 없습니다. MDS는 메타데이터를 제출해야 합니다. MDS 서비스의 저하는 스토리지 클러스터가 작동하는 방식에 영향을 미칠 수 있으며( CephFS 스토리지 클래스와 관련된) 가능한 한 빨리 수정해야 합니다.

보안 등급

높음

진단

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-mds
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.10. CephMgrIsAbsent

의미

Ceph 관리자가 클러스터 모니터링을 실행하지 않습니다. PVC(영구 볼륨 클레임) 생성 및 삭제 요청은 가능한 한 빨리 해결되어야 합니다.

보안 등급

높음

진단

  • rook-ceph-mgr Pod가 실패했는지 확인하고 필요한 경우 다시 시작합니다. Ceph mgr pod 재시작에 실패하면 일반 Pod 문제 해결을 수행하여 문제를 해결합니다.

    • Ceph mgr Pod가 실패했는지 확인합니다.

      $ oc get pods | grep mgr
    • 자세한 내용은 Ceph mgr Pod를 설명합니다.

      $ oc describe pods/<pod_name>
      <pod_name>
      이전 단계의 rook-ceph-mgr Pod 이름을 지정합니다.

      리소스 문제와 관련된 오류를 분석합니다.

    • Pod를 삭제하고 Pod가 다시 시작될 때까지 기다립니다.

      $ oc get pods | grep mgr

일반적인 Pod 문제 해결을 위해 다음 단계를 따르십시오.

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-mgr
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.11. CephMgrIsMissingReplicas

의미

이 경고를 해결하려면 Ceph 관리자의 사라지는 원인을 확인하고 필요한 경우 다시 시작해야 합니다.

보안 등급

높음

진단

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-mgr
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.12. CephMonHighNumberOfLeaderChanges

의미

Ceph 클러스터에는 스토리지 클러스터에 대한 중요한 정보를 저장하는 중복 모니터 Pod 세트가 있습니다. 스토리지 클러스터에 대한 정보를 얻으려면 Pod를 주기적으로 동기화합니다. 가장 업데이트된 정보를 가져오는 첫 번째 모니터 Pod는 리더가 되고 다른 모니터 Pod는 리더에게 요청한 후 동기화 프로세스를 시작합니다. 하나 이상의 모니터 Pod의 네트워크 연결 또는 다른 종류의 문제의 문제로 리더의 비정상적인 변경이 발생합니다. 이 상황은 스토리지 클러스터 성능에 부정적인 영향을 미칠 수 있습니다.

보안 등급

중간

중요

모든 네트워크 문제를 확인합니다. 네트워크 문제가 있는 경우 다음 문제 해결 단계를 진행하기 전에 OpenShift Data Foundation 팀으로 에스컬레이션해야 합니다.

진단

  1. 영향을 받는 모니터 Pod의 로그를 출력하여 문제에 대한 자세한 정보를 수집합니다.

    $ oc logs <rook-ceph-mon-X-yyyy> -n openshift-storage
    <rook-ceph-mon-X-yyyy>
    영향을 받는 모니터 Pod의 이름을 지정합니다.
  2. 또는 Openshift 웹 콘솔을 사용하여 영향을 받는 모니터 포드의 로그를 엽니다. 가능한 원인에 대한 자세한 내용은 로그에 반영됩니다.
  3. 일반 Pod 문제 해결 단계를 수행합니다.

    Pod 상태: 보류 중
  4. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep {ceph-component}
  5. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  6. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
    Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
    • 준비 상태 프로브를 확인합니다.
    $ oc describe pod/${MYPOD}
    Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
    • 애플리케이션 또는 이미지 문제를 확인합니다.
    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.13. CephMonQuorumAtRisk

의미

중복을 제공하기 위해 여러 MON이 함께 작동합니다. 각 MON은 메타데이터 사본을 보관합니다. 클러스터는 3 MONs로 배포되며 쿼럼 및 스토리지 작업을 실행하기 위해 2개 이상의 MON이 실행 중이어야 합니다. 쿼럼이 손실되면 데이터에 대한 액세스가 위험할 수 있습니다.

보안 등급

높음

진단

Ceph MON Quorum을 복원합니다. 자세한 내용은 문제 해결 가이드 의 OpenShift Data Foundation의 ceph-monitor 쿼럼 복원을 참조하십시오. Ceph MON Quorum 복원에 실패하면 일반 포드 문제 해결을 수행하여 문제를 해결합니다.

일반 Pod 문제 해결을 위해 다음을 수행합니다.

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-mon
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.
$ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.
$ oc logs pod/${MYPOD}
중요

노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.14. CephMonQuorumLost

의미

Ceph 클러스터에는 스토리지 클러스터에 대한 중요한 정보를 저장하는 중복 모니터 Pod 세트가 있습니다. 스토리지 클러스터에 대한 정보를 얻으려면 Pod를 주기적으로 동기화합니다. 가장 업데이트된 정보를 가져오는 첫 번째 모니터 Pod는 리더가 되고 다른 모니터 Pod는 리더에게 요청한 후 동기화 프로세스를 시작합니다. 하나 이상의 모니터 Pod의 네트워크 연결 또는 다른 종류의 문제의 문제로 리더의 비정상적인 변경이 발생합니다. 이 상황은 스토리지 클러스터 성능에 부정적인 영향을 미칠 수 있습니다.

보안 등급

높음

중요

모든 네트워크 문제를 확인합니다. 네트워크 문제가 있는 경우 다음 문제 해결 단계를 진행하기 전에 OpenShift Data Foundation 팀으로 에스컬레이션해야 합니다.

진단

Ceph MON Quorum을 복원합니다. 자세한 내용은 문제 해결 가이드 의 OpenShift Data Foundation의 ceph-monitor 쿼럼 복원을 참조하십시오. Ceph MON Quorum 복원에 실패하면 일반 포드 문제 해결을 수행하여 문제를 해결합니다.

또는 일반적인 Pod 문제 해결을 수행합니다.

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep {ceph-component}
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.
$ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.
$ oc logs pod/${MYPOD}
중요

노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.15. CephMonVersionMismatch

의미

일반적으로 이 경고는 오랜 시간이 걸리는 업그레이드 중에 트리거됩니다.

보안 등급

중간

진단

ocs-operator 서브스크립션 상태 및 Operator Pod 상태를 확인하여 Operator 업그레이드가 진행 중인지 확인합니다.

  1. ocs-operator 서브스크립션 상태를 확인합니다.

    $ oc get sub $(oc get pods -n openshift-storage | grep -v ocs-operator) -n openshift-storage -o json | jq .status.conditions

    상태 조건 유형은 CatalogSourcesUnhealthy,InstallPlanMissing,InstallPlanPending, InstallPlanFailed 입니다. 각 유형의 상태는 False 여야 합니다.

    출력 예:

    [
      {
        "lastTransitionTime": "2021-01-26T19:21:37Z",
        "message": "all available catalogsources are healthy",
        "reason": "AllCatalogSourcesHealthy",
        "status": "False",
        "type": "CatalogSourcesUnhealthy"
      }
    ]

    예제 출력에는 CatalogSourcesUnHealthly 유형의 False 상태가 표시됩니다. 즉, 카탈로그 소스가 정상입니다.

  2. OCS Operator Pod 상태를 확인하여 진행 중인 OCS Operator 업그레이드가 있는지 확인합니다.

    $ oc get pod -n openshift-storage | grep ocs-operator OCSOP=$(oc get pod -n openshift-storage -o custom-columns=POD:.metadata.name --no-headers | grep ocs-operator) echo $OCSOP oc get pod/${OCSOP} -n openshift-storage oc describe pod/${OCSOP} -n openshift-storage

    'ocs-operator'가 진행 중이라고 판단되면 5분 정도 기다린 후 이 경고가 자체적으로 해결되어야 합니다. 대기하거나 다른 오류 상태 조건이 표시되면 문제 해결을 계속합니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.16. CephNodeDown

의미

Ceph pod를 실행하는 노드가 다운되었습니다. Ceph는 노드 오류를 처리하도록 설계된 경우에도 스토리지 작업이 계속 작동하지만 스토리지 기능에 영향을 미치는 다른 노드의 위험을 최소화하려면 문제를 해결하는 것이 좋습니다.

보안 등급

중간

진단

  1. 실행 중이고 실패한 모든 Pod를 나열합니다.

    oc -n openshift-storage get pods
    중요

    OSD(Object Storage Device) Pod가 새 노드에 예약되도록 OpenShift Data Foundation 리소스 요구 사항을 충족하는지 확인합니다. Ceph 클러스터에서 오류가 발생하지만 OSD를 복구하는 데 몇 분이 걸릴 수 있습니다. 이 복구 작업을 수행하려면 OSD Pod가 새 작업자 노드에 올바르게 배치되었는지 확인합니다.

  2. 이전에 실패한 OSD Pod가 실행 중인지 확인합니다.

    oc -n openshift-storage get pods

    이전에 실패한 OSD Pod가 예약되지 않은 경우 describe 명령을 사용하여 Pod가 다시 예약되지 않은 이유에 대한 이벤트를 확인합니다.

  3. 실패한 OSD 포드에 대한 이벤트를 설명합니다.

    oc -n openshift-storage get pods | grep osd
  4. 실패한 OSD Pod를 하나 이상 찾습니다.

    oc -n openshift-storage describe pods/<osd_podname_ from_the_ previous step>

    이벤트 섹션에서 리소스와 같은 실패 이유를 찾습니다.

    또한 rook-ceph-toolbox 를 사용하여 복구를 볼 수 있습니다. 이 단계는 선택 사항이지만 대규모 Ceph 클러스터에 유용합니다. toolbox에 액세스하려면 다음 명령을 실행합니다.

    TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
    oc rsh -n openshift-storage $TOOLS_POD

    rsh 명령 프롬프트에서 다음을 실행하고 io 섹션에서 "recovery"를 확인합니다.

    ceph status
  5. 실패한 노드가 있는지 확인합니다.

    1. 작업자 노드 목록을 가져오고 노드 상태를 확인합니다.

      oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'
    2. 실패에 대한 자세한 정보를 얻기 위해 NotReady 상태인 노드를 설명합니다.

      oc describe node <node_name>

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.17. CephOSDCriticallyFull

의미

OSD(오브젝트 스토리지 장치) 중 하나가 매우 가득 차 있습니다. 즉시 클러스터를 확장합니다.

보안 등급

높음

진단

스토리지 공간을 확보하기 위해 데이터 삭제
데이터를 삭제할 수 있으며 클러스터는 자체 복구 프로세스를 통해 경고를 해결합니다.
중요

이는 읽기 전용 모드가 아닌 가까운 또는 가득 차 있는 OpenShift Data Foundation 클러스터에만 적용됩니다. 읽기 전용 모드에서는 데이터 삭제, 즉 PVC(영구 볼륨 클레임), PV(영구 볼륨) 또는 둘 다 삭제가 포함된 변경 사항을 방지합니다.

스토리지 용량 확장
현재 스토리지 크기는 1TB 미만

먼저 확장할 수 있는 능력을 평가해야 합니다. 1TB의 스토리지가 추가될 때마다 클러스터에 최소 2개의 vCPU 및 8GiB 메모리가 있는 노드가 3개 있어야 합니다.

애드온을 통해 스토리지 용량을 4TB로 늘릴 수 있으며 클러스터는 자체 복구 프로세스를 통해 경고를 해결합니다. 최소 vCPU 및 메모리 리소스 요구 사항이 충족되지 않으면 클러스터에 3개의 작업자 노드를 추가해야 합니다.

완화 방법

  • 현재 스토리지 크기가 4TB인 경우 Red Hat 지원에 문의하십시오.
  • 선택 사항: 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.18. CephOSDDiskNotResponding

의미

디스크 장치가 응답하지 않습니다. 모든 OSD(오브젝트 스토리지 장치)가 실행 중인지 확인합니다.

보안 등급

중간

진단

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    $ oc get pod | grep rook-ceph
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a rook-ceph that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.

    $ oc logs pod/${MYPOD}
    중요
    • 노드가 할당된 경우 노드에서 kubelet을 확인합니다.
    • 실행 중인 Pod의 기본 상태, 노드에서 노드 유사성 및 리소스 가용성이 확인되면 Ceph 툴을 실행하여 스토리지 구성 요소의 상태를 가져옵니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.19. CephOSDDiskUnavailable

의미

호스트 중 하나에서 디스크 장치에 액세스할 수 없으며 해당 OSD(오브젝트 스토리지 장치)는 Ceph 클러스터에 의해 표시됩니다. 이 경고는 Ceph 노드가 10분 이내에 복구되지 않으면 발생합니다.

보안 등급

높음

진단

실패한 노드 확인
  1. 작업자 노드 목록을 가져오고 노드 상태를 확인합니다.
oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'
  1. 실패에 대한 자세한 정보를 얻기 위해 NotReady 상태의 노드를 설명합니다.

    oc describe node <node_name>

6.3.20. CephOSDFlapping

의미

스토리지 데몬은 지난 5분 동안 5회 다시 시작되었습니다. Pod 이벤트 또는 Ceph 상태를 확인하여 원인을 확인합니다.

보안 등급

높음

진단

Red Hat Ceph Storage 문제 해결 가이드의 OSD Flapping OSD 섹션의 단계를 따르십시오.

또는 일반적인 Pod 문제 해결 단계를 따르십시오.

Pod 상태: 보류 중
  1. 리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.

    $ oc project openshift-storage
    $ oc get pod | grep rook-ceph
  2. MYPOD 를 문제 Pod로 식별되는 Pod의 변수로 설정합니다.

    # Examine the output for a rook-ceph that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 사항 또는 보류 중인 PVC를 찾습니다. 그렇지 않으면 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중, 실행 중이 아니지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제를 확인합니다.

    $ oc logs pod/${MYPOD}
    중요
    • 노드가 할당된 경우 노드에서 kubelet을 확인합니다.
    • 실행 중인 Pod의 기본 상태, 노드에서 노드 유사성 및 리소스 가용성이 확인되면 Ceph 툴을 실행하여 스토리지 구성 요소의 상태를 가져옵니다.

완화 방법

로그 정보 디버깅
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.21. CephOSDNearFull

의미

백엔드 스토리지 장치 OSD(Object Storage Device)의 사용률은 호스트에서 75%를 초과했습니다.

보안 등급

높음

완화 방법

클러스터의 일부 공간을 확보하거나 스토리지 클러스터를 확장하거나 Red Hat 지원에 문의하십시오. 스토리지 확장에 대한 자세한 내용은 스토리지 확장 가이드를 참조하십시오.

6.3.22. CephOSDSlowOps

의미

느린 요청이 있는 OSD(Object Storage Device)는 osd_op_complaint_time 매개변수로 정의된 시간 내에 대기열의 I/O 작업(IOPS)을 서비스할 수 없는 모든 OSD입니다. 기본적으로 이 매개변수는 30초로 설정됩니다.

보안 등급

중간

진단

느린 요청에 대한 자세한 내용은 Openshift 콘솔을 사용하여 확인할 수 있습니다.

  1. OSD pod 터미널에 액세스하고 다음 명령을 실행합니다.

    $ ceph daemon osd.<id> ops
    $ ceph daemon osd.<id> dump_historic_ops
    참고

    포드 이름에 OSD 수가 표시됩니다. 예를 들어 rook-ceph-osd-0-5d86d4d8d4-zlqkx 에서 &lt;0& gt;은 OSD입니다.

완화 방법

OSD에서 요청이 느려지는 주요 원인은 다음과 같습니다.

  • 디스크 드라이브, 호스트, 랙 또는 네트워크 스위치와 같은 기본 하드웨어 또는 인프라와 관련된 문제입니다. Openshift 모니터링 콘솔을 사용하여 클러스터 리소스에 대한 경고 또는 오류를 찾습니다. 이를 통해 OSD에서 느린 작업의 근본 원인을 파악할 수 있습니다.
  • 네트워크에 문제가 있습니다. 이러한 문제는 일반적으로 플레이닝 OSD와 관련이 있습니다. Red Hat Ceph Storage 문제 해결 가이드의 OSD Flapping OSD 섹션을 참조하십시오.
  • 네트워크 문제인 경우 OpenShift Data Foundation 팀으로 에스컬레이션합니다.
  • 시스템 로드. Openshift 콘솔을 사용하여 OSD 포드의 지표와 OSD를 실행 중인 노드를 검토합니다. 더 많은 리소스를 추가하거나 할당하는 것이 가능한 해결책이 될 수 있습니다.

6.3.23. CephOSDVersionMismatch

의미

일반적으로 이 경고는 오랜 시간이 걸리는 업그레이드 중에 트리거됩니다.

보안 등급

중간

진단

ocs-operator 서브스크립션 상태 및 Operator Pod 상태를 확인하여 Operator 업그레이드가 진행 중인지 확인합니다.

  1. ocs-operator 서브스크립션 상태를 확인합니다.

    $ oc get sub $(oc get pods -n openshift-storage | grep -v ocs-operator) -n openshift-storage -o json | jq .status.conditions

    상태 조건 유형은 CatalogSourcesUnhealthy,InstallPlanMissing,InstallPlanPending, InstallPlanFailed 입니다. 각 유형의 상태는 False 여야 합니다.

    출력 예:

    [
      {
        "lastTransitionTime": "2021-01-26T19:21:37Z",
        "message": "all available catalogsources are healthy",
        "reason": "AllCatalogSourcesHealthy",
        "status": "False",
        "type": "CatalogSourcesUnhealthy"
      }
    ]

    예제 출력에는 CatalogSourcesUnHealthly 유형의 False 상태가 표시됩니다. 즉, 카탈로그 소스가 정상입니다.

  2. OCS Operator Pod 상태를 확인하여 진행 중인 OCS Operator 업그레이드가 있는지 확인합니다.

    $ oc get pod -n openshift-storage | grep ocs-operator OCSOP=$(oc get pod -n openshift-storage -o custom-columns=POD:.metadata.name --no-headers | grep ocs-operator) echo $OCSOP oc get pod/${OCSOP} -n openshift-storage oc describe pod/${OCSOP} -n openshift-storage

    'ocs-operator'가 진행 중이라고 판단되면 5분 정도 기다린 후 이 경고가 자체적으로 해결되어야 합니다. 대기하거나 다른 오류 상태 조건이 표시되면 문제 해결을 계속합니다.

6.3.24. CephPGRepairTakingTooLong

의미

자동 복구 작업에는 시간이 너무 오래 걸립니다.

보안 등급

높음

진단

일치하지 않는 배치 그룹(PG)을 확인하고 복구하십시오. 자세한 내용은 Ceph의 Red Hat 지식베이스 솔루션 Handle Inconsistent placement groups in Ceph에서 참조하십시오.

6.3.25. CephPoolQuotaBytesCriticallyExhausted

의미

하나 이상의 풀에 도달했거나 할당량에 매우 근접합니다. 이 오류 조건을 트리거하는 임계값은 mon_pool_quota_crit_threshold 구성 옵션으로 제어됩니다.

보안 등급

높음

완화 방법

풀 할당량을 조정합니다. 다음 명령을 실행하여 풀 할당량을 완전히 제거하거나 축소합니다.

ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>

할당량 값을 0 으로 설정하면 할당량이 비활성화됩니다.

6.3.26. CephPoolQuotaBytesNearExhaustion

의미

하나 이상의 풀은 구성된 완전성 임계값에 도달하는 것입니다. 이 경고 조건을 트리거할 수 있는 임계값 중 하나는 mon_pool_quota_warn_threshold 구성 옵션입니다.

보안 등급

높음

완화 방법

풀 할당량을 조정합니다. 다음 명령을 실행하여 풀 할당량을 완전히 제거하거나 축소합니다.

ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>

할당량 값을 0 으로 설정하면 할당량이 비활성화됩니다.

6.3.27. OSDCPULoadHigh

의미

OSD는 데이터 배치 및 복구를 관리하는 Ceph 스토리지의 중요한 구성 요소입니다. OSD 컨테이너의 CPU 사용량이 높으면 처리 요구 사항이 증가하여 스토리지 성능이 저하될 수 있습니다.

보안 등급

높음

진단

  1. Kubernetes 대시보드 또는 해당 대시보드로 이동합니다.
  2. Workloads 섹션에 액세스하여 OSD 경고와 관련된 관련 Pod를 선택합니다.
  3. 지표 탭을 클릭하여 OSD 컨테이너의 CPU 지표를 확인합니다.
  4. 경고 구성에 지정된 대로 CPU 사용량이 상당한 기간 동안 80%를 초과하는지 확인합니다.

완화 방법

OSD CPU 사용량이 일관되게 높은 경우 다음 단계를 수행하는 것이 좋습니다.

  1. 전체 스토리지 클러스터 성능을 평가하고 CPU 사용량에 기여하는 OSD를 식별합니다.
  2. 기존 노드에 새 스토리지 장치를 추가하거나 새 스토리지 장치가 있는 새 노드를 추가하여 클러스터의 OSD 수를 늘립니다. 부하를 배포하고 전체 시스템 성능을 개선하는 데 도움이 되는 지침은 스토리지 확장 가이드를 검토하십시오.

6.3.28. PersistentVolumeUsageCritical

의미

PVC(영구 볼륨 클레임)는 전체 용량에 도달하고 있으며 적시에 참여하지 않은 경우 데이터 손실이 발생할 수 있습니다.

보안 등급

높음

완화 방법

PVC 크기를 확장하여 용량을 늘립니다.

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 스토리지 PersistentVolumeClaim 을 클릭합니다.
  3. 프로젝트 드롭다운 목록에서 openshift-storage 를 선택합니다.
  4. 확장하려는 PVC에서 작업 메뉴( Cryostat) Expand PVC 를 클릭합니다.
  5. 총 크기를 원하는 크기로 업데이트합니다.
  6. 확장 을 클릭합니다.

또는 공간을 차지할 수 있는 불필요한 데이터를 삭제할 수도 있습니다.

6.3.29. PersistentVolumeUsageNearFull

의미

PVC(영구 볼륨 클레임)는 전체 용량에 도달하고 있으며 적시에 참여하지 않은 경우 데이터 손실이 발생할 수 있습니다.

보안 등급

높음

완화 방법

PVC 크기를 확장하여 용량을 늘립니다.

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 스토리지 PersistentVolumeClaim 을 클릭합니다.
  3. 프로젝트 드롭다운 목록에서 openshift-storage 를 선택합니다.
  4. 확장하려는 PVC에서 작업 메뉴( Cryostat) Expand PVC 를 클릭합니다.
  5. 총 크기를 원하는 크기로 업데이트합니다.
  6. 확장 을 클릭합니다.

또는 공간을 차지할 수 있는 불필요한 데이터를 삭제할 수도 있습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.