6.3. 클러스터 경고 해결


Red Hat Ceph Storage 클러스터에서 OpenShift Data Foundation 사용자 인터페이스에서 해당 표시를 높일 수 있다는 한정된 상태 경고가 있습니다. 이러한 경고는 고유 식별자가 있는 상태 경고로 정의됩니다. 식별자는 도구에서 상태 점검을 감지하고 의미를 반영하는 방식으로 제시할 수 있도록 설계된 terse pseudo-human-readable 문자열입니다. 자세한 내용과 문제 해결을 위해 상태 경고를 클릭합니다.

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

CephClusterCriticallyFull

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

CephClusterErrorState

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

CephClusterNearFull

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

CephClusterReadOnly

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

CephClusterWarningState

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

CephDataRecoveryTakingTooLong

데이터 복구가 너무 오래 활성 상태였습니다.

CephMdsMissingReplicas

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

CephMgrIsAbsent

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

CephMgrIsMissingReplicas

Ceph 관리자에 복제본이 없습니다. 이 경우 상태 보고를 통해 ceph status 명령에서 보고한 일부 정보가 누락되거나 오래되었습니다. 또한 Ceph 관리자는 Ceph의 기존 기능을 확장하려는 관리자 프레임워크를 담당합니다.

CephMonHighNumberOfLeaderChanges

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

CephMonQuorumAtRisk

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

CephMonQuorumLost

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

CephMonVersionMismatch

실행 중인 Ceph Mon 구성 요소의 다양한 버전이 있습니다.

CephNodeDown

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

CephOSDCriticallyFull

백엔드 OSD(Object Storage Device)의 사용률은 80%를 초과했습니다. 일부 공간을 즉시 확보하거나 스토리지 클러스터 또는 연락처 지원을 확장합니다.

CephOSDDiskNotResponding

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

CephOSDDiskUnavailable

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

CephOSDFlapping

Ceph 스토리지 OSD 플랫폼.

CephOSDNearFull

OSD 스토리지 장치 중 하나가 가득 차 있습니다.

CephOSDSlowOps

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

CephOSDVersionMismatch

실행 중인 Ceph OSD 구성 요소의 다양한 버전이 있습니다.

CephPGRepairTakingTooLong

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

CephPoolQuotaBytesCriticallyExhausted

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

CephPoolQuotaBytesNearExhaustion

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

PersistentVolumeUsageCritical

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

PersistentVolumeUsageNearFull

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

6.3.1. CephClusterCriticallyFull

meaning

스토리지 클러스터 사용률이 80%를 초과했으며 85%로 읽기 전용이 됩니다. 사용률이 85%를 초과하면 Ceph 클러스터가 읽기 전용이 됩니다. 일부 공간을 확보하거나 스토리지 클러스터를 즉시 확장합니다. 이 경고 전에 개체 스토리지 장치(OSD) 장치와 관련된 경고를 일반적으로 확인할 수 있습니다.

보안 등급

높은

진단

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

완화 방법

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

6.3.2. CephClusterErrorState

meaning

이 경고는 스토리지 클러스터가 불가피한 시간 동안 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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

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

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

완화 방법

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

    $ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.3. CephClusterNearFull

meaning

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

보안 등급

심각

진단

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

완화 방법

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

6.3.4. CephClusterReadOnly

meaning

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

보안 등급

심각

진단

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

완화 방법

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

6.3.5. CephClusterWarningState

meaning

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

보안 등급

높은

진단

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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

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

    $ oc logs pod/${MYPOD}
    중요

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

완화 방법

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

6.3.6. CephDataRecoveryTakingTooLong

meaning

데이터 복구 속도가 느리다. 모든 OSD(Object Storage Device)가 실행 중인지 확인합니다.

보안 등급

높은

진단

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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

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

    $ oc logs pod/${MYPOD}
    중요

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

완화 방법

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

6.3.7. CephMdsMissingReplicas

meaning

스토리지 메타데이터 서비스(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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

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

    $ oc logs pod/${MYPOD}
    중요

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

완화 방법

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

6.3.8. CephMgrIsAbsent

meaning

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가 다시 시작될 때까지 기다립니다.

      $ 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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

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

    $ oc logs pod/${MYPOD}
    중요

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

완화 방법

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

6.3.9. CephMgrIsMissingReplicas

meaning

이 경고를 해결하려면 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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

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

    $ oc logs pod/${MYPOD}
    중요

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

완화 방법

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

6.3.10. CephMonHighNumberOfLeaderChanges

meaning

Ceph 클러스터에는 스토리지 클러스터에 대한 중요한 정보를 저장하는 중복 모니터 포드 세트가 있습니다. 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 웹 콘솔을 사용하여 영향을 받는 모니터 Pod의 로그를 엽니다. 가능한 원인에 대한 자세한 내용은 로그에 반영됩니다.
  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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
    • 준비 상태 프로브를 확인합니다.
    $ oc describe pod/${MYPOD}
    Pod status: 보류 중이 아니라 실행되지 않음
    • 애플리케이션 또는 이미지 문제를 확인합니다.
    $ oc logs pod/${MYPOD}
    중요

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

완화 방법

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

6.3.11. CephMonQuorumAtRisk

meaning

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

보안 등급

높은

진단

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

일반 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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.
$ oc describe pod/${MYPOD}
Pod status: 보류 중이 아니라 실행되지 않음
  • 애플리케이션 또는 이미지 문제를 확인합니다.
$ oc logs pod/${MYPOD}
중요

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

완화 방법

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

6.3.12. CephMonQuorumLost

meaning

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

보안 등급

높은

중요

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

진단

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

또는 일반 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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.
$ oc describe pod/${MYPOD}
Pod status: 보류 중이 아니라 실행되지 않음
  • 애플리케이션 또는 이미지 문제를 확인합니다.
$ oc logs pod/${MYPOD}
중요

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

완화 방법

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

6.3.13. CephMonVersionMismatch

meaning

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

보안 등급

중간

진단

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,InstallPlan Mising ,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/ocs4/ocs-must-gather-rhel8:v4.6

6.3.14. CephNodeDown

meaning

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 명령을 사용하여 포드를 다시 예약하지 않은 이유로 이벤트를 확인합니다.

  3. 실패한 OSD Pod의 이벤트를 설명합니다.

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

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

    events 섹션에서 리소스가 충족되지 않는 것과 같은 실패 이유를 찾습니다.

    또한 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/ocs4/ocs-must-gather-rhel8:v4.6

6.3.15. CephOSDCriticallyFull

meaning

OSD(Object Storage Device) 중 하나가 매우 완전합니다. 클러스터를 즉시 확장합니다.

보안 등급

높은

진단

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

이는 OpenShift Data Foundation 클러스터에만 적용되며 읽기 전용 모드인 것은 아닙니다. 읽기 전용 모드에서는 데이터 삭제, 즉 PVC(영구 볼륨 클레임), PV(영구 볼륨) 또는 둘 다를 삭제하는 작업이 포함됩니다.

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

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

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

완화 방법

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

    $ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.16. CephOSDDiskNotResponding

meaning

디스크 장치가 응답하지 않습니다. 모든 OSD(Object Storage Device)가 실행 중인지 확인합니다.

보안 등급

중간

진단

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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

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

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

완화 방법

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

    $ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.17. CephOSDDiskUnavailable

meaning

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

보안 등급

높은

진단

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

    oc describe node <node_name>

6.3.18. CephOSDFlapping

meaning

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

보안 등급

높은

진단

Red Hat Ceph Storage 문제 해결 가이드의 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 status: 보류 중이 아님, 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

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

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

완화 방법

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

    $ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.19. CephOSDNearFull

meaning

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

보안 등급

높은

완화 방법

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

6.3.20. CephOSDSlowOps

meaning

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

보안 등급

중간

진단

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

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

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

    Pod 이름에 OSD 수가 표시됩니다. 예를 들어 rook-ceph-osd-0-5d86d4d4-zlqkx 에서 OSD입니다.

완화 방법

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

6.3.21. CephOSDVersionMismatch

meaning

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

보안 등급

중간

진단

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,InstallPlan Mising ,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.22. CephPGRepairTakingTooLong

meaning

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

보안 등급

높은

진단

일관성 없는 배치 그룹(PG)을 확인하고 복구합니다. 자세한 내용은 Red Hat Knowledgebase 솔루션 에서 Ceph의 일관성 없는 배치 그룹 처리에서 참조하십시오.

6.3.23. CephPoolQuotaBytesCriticallyExhausted

meaning

하나 이상의 풀에 도달했거나 매우 근접하여 할당량에 도달했습니다. 이 오류 조건을 트리거할 임계값은 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.24. CephPoolQuotaBytesNearExhaustion

meaning

하나 이상의 풀이 구성된 완전성 임계값에 도달합니다. 이 경고 조건을 트리거할 수 있는 임계값 중 하나는 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.25. PersistentVolumeUsageCritical

meaning

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

보안 등급

높은

완화 방법

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

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

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

6.3.26. PersistentVolumeUsageNearFull

meaning

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

보안 등급

높은

완화 방법

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

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

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

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat, Inc.