6.3. 클러스터 경고 해결
Red Hat Ceph Storage 클러스터가 OpenShift Data Foundation 사용자 인터페이스에 표시될 수 있는 제한된 상태 경고 세트가 있습니다. 이러한 경고는 고유 식별자가 있는 상태 경고로 정의됩니다. 식별자는 툴에서 상태 점검을 감지하여 의미를 반영하는 방식으로 제공할 수 있도록 하기 위한 의사 사람이 읽을 수 있는 문자열입니다. 자세한 내용 및 문제 해결을 위해 상태 경고를 클릭합니다.
상태 경고 | 개요 |
---|---|
스토리지 클러스터 사용률은 80%를 초과했습니다. | |
스토리지 클러스터는 10분 이상 오류 상태입니다. | |
스토리지 클러스터가 전체 용량에 가까워지고 있습니다. 데이터 삭제 또는 클러스터 확장이 필요합니다. | |
스토리지 클러스터는 이제 읽기 전용이며 즉시 데이터 삭제 또는 클러스터 확장이 필요합니다. | |
스토리지 클러스터는 10분 이상 경고 상태입니다. | |
데이터 복구는 너무 오래 지속되었습니다. | |
MDS 데몬의 Ceph 메타데이터 서비스(MDS) 캐시 사용량이 | |
MDS 데몬의 Ceph MDS CPU 사용량이 적절한 성능을 위해 임계값을 초과했습니다. | |
스토리지 메타데이터 서비스에 필요한 최소 복제본을 사용할 수 없습니다. 스토리지 클러스터의 작동에 영향을 미칠 수 있습니다. | |
Ceph Manager는 Prometheus 대상 검색에서 사라졌습니다. | |
Ceph 관리자가 복제본이 누락되어 있습니다. 이pts 상태 보고 및 | |
Ceph 모니터 리더는 비정상적으로 변경되고 있습니다. | |
스토리지 클러스터 쿼럼이 낮습니다. | |
스토리지 클러스터의 모니터 Pod 수로는 충분하지 않습니다. | |
다양한 버전의 Ceph Mon 구성 요소가 실행되고 있습니다. | |
스토리지 노드가 중단되었습니다. 노드를 즉시 확인합니다. 경고에는 노드 이름이 포함되어야 합니다. | |
백엔드 OSD(오브젝트 스토리지 장치)의 사용률은 80%를 초과했습니다. 일부 공간을 즉시 확보하거나 스토리지 클러스터를 확장하거나 지원 팀에 문의하십시오. | |
디스크 장치가 호스트 중 하나에 응답하지 않습니다. | |
호스트 중 하나에서 디스크 장치에 액세스할 수 없습니다. | |
Ceph 스토리지 OSD 풀링. | |
OSD 스토리지 장치 중 하나가 완전히 가까워지고 있습니다. | |
OSD 요청은 처리하는 데 시간이 너무 오래 걸립니다. | |
다양한 버전의 Ceph OSD 구성 요소가 실행되고 있습니다. | |
자동 복구 작업에는 시간이 너무 오래 걸립니다. | |
스토리지 풀 할당량 사용량은 90%를 초과했습니다. | |
스토리지 풀 할당량 사용량은 70%를 초과했습니다. | |
특정 Pod의 OSD 컨테이너의 CPU 사용량이 80%를 초과하여 OSD 성능에 영향을 미칠 수 있습니다. | |
영구 볼륨 클레임 사용량이 용량의 85%를 초과했습니다. | |
영구 볼륨 클레임 사용량이 용량의 75%를 초과했습니다. |
6.3.1. CephClusterCriticallyFull
의미 | 스토리지 클러스터 사용률은 80%를 초과하여 85%로 읽기 전용입니다. 사용률이 85%를 초과하면 Ceph 클러스터가 읽기 전용입니다. 일부 공간을 확보하거나 스토리지 클러스터를 즉시 확장합니다. 일반적으로 이 경고에 앞서 전체 또는 전체 오브젝트 스토리지 장치(OSD)와 관련된 경고를 볼 수 있습니다. |
보안 등급 | 높음 |
진단
- Scaling storage
- 클러스터 유형에 따라 스토리지 장치, 노드 또는 둘 다를 추가해야 합니다. 자세한 내용은 스토리지 확장 가이드를 참조하십시오.
완화 방법
- 정보 삭제
- 클러스터를 확장할 수 없는 경우 정보를 삭제하여 일부 공간을 확보해야 합니다.
6.3.2. CephClusterErrorState
의미 |
이 경고는 스토리지 클러스터가 허용되지 않는 시간 동안 |
보안 등급 | 심각 |
진단
- Pod 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
$ oc get pod | grep rook-ceph
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
oc get pod | grep {ceph-component}
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
oc get pod | grep rook-ceph-osd
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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는 캐시에서 사용되지 않는 메타데이터를 트리밍하고 클라이언트 캐시의 캐시된 항목을 회수하여 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 할당을 늘려야 합니다. |
보안 등급 | 높음 |
진단
워크로드
완화 방법
할당된 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 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
oc get pod | grep rook-ceph-mds
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
oc get pod | grep rook-ceph-mgr
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
oc get pod | grep rook-ceph-mgr
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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 팀으로 에스컬레이션해야 합니다.
진단
영향을 받는 모니터 Pod의 로그를 출력하여 문제에 대한 자세한 정보를 수집합니다.
$ oc logs <rook-ceph-mon-X-yyyy> -n openshift-storage
<rook-ceph-mon-X-yyyy>
- 영향을 받는 모니터 Pod의 이름을 지정합니다.
- 또는 Openshift 웹 콘솔을 사용하여 영향을 받는 모니터 포드의 로그를 엽니다. 가능한 원인에 대한 자세한 내용은 로그에 반영됩니다.
일반 Pod 문제 해결 단계를 수행합니다.
- Pod 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
oc get pod | grep {ceph-component}
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
oc get pod | grep rook-ceph-mon
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
oc get pod | grep {ceph-component}
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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 업그레이드가 진행 중인지 확인합니다.
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
상태가 표시됩니다. 즉, 카탈로그 소스가 정상입니다.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는 노드 오류를 처리하도록 설계된 경우에도 스토리지 작업이 계속 작동하지만 스토리지 기능에 영향을 미치는 다른 노드의 위험을 최소화하려면 문제를 해결하는 것이 좋습니다. |
보안 등급 | 중간 |
진단
실행 중이고 실패한 모든 Pod를 나열합니다.
oc -n openshift-storage get pods
중요OSD(Object Storage Device) Pod가 새 노드에 예약되도록 OpenShift Data Foundation 리소스 요구 사항을 충족하는지 확인합니다. Ceph 클러스터에서 오류가 발생하지만 OSD를 복구하는 데 몇 분이 걸릴 수 있습니다. 이 복구 작업을 수행하려면 OSD Pod가 새 작업자 노드에 올바르게 배치되었는지 확인합니다.
이전에 실패한 OSD Pod가 실행 중인지 확인합니다.
oc -n openshift-storage get pods
이전에 실패한 OSD Pod가 예약되지 않은 경우
describe
명령을 사용하여 Pod가 다시 예약되지 않은 이유에 대한 이벤트를 확인합니다.실패한 OSD 포드에 대한 이벤트를 설명합니다.
oc -n openshift-storage get pods | grep osd
실패한 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
실패한 노드가 있는지 확인합니다.
작업자 노드 목록을 가져오고 노드 상태를 확인합니다.
oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'
실패에 대한 자세한 정보를 얻기 위해
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 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
$ oc get pod | grep rook-ceph
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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.20. CephOSDFlapping
의미 | 스토리지 데몬은 지난 5분 동안 5회 다시 시작되었습니다. Pod 이벤트 또는 Ceph 상태를 확인하여 원인을 확인합니다. |
보안 등급 | 높음 |
진단
Red Hat Ceph Storage 문제 해결 가이드의 OSD Flapping OSD 섹션의 단계를 따르십시오.
또는 일반적인 Pod 문제 해결 단계를 따르십시오.
- Pod 상태: 보류 중
리소스 문제, PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제가 있는지 확인합니다.
$ oc project openshift-storage
$ oc get pod | grep rook-ceph
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의 이름을 지정합니다.
리소스 제한 사항 또는 보류 중인 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)는 |
보안 등급 | 중간 |
진단
느린 요청에 대한 자세한 내용은 Openshift 콘솔을 사용하여 확인할 수 있습니다.
OSD pod 터미널에 액세스하고 다음 명령을 실행합니다.
$ ceph daemon osd.<id> ops
$ ceph daemon osd.<id> dump_historic_ops
참고포드 이름에 OSD 수가 표시됩니다. 예를 들어
rook-ceph-osd-0-5d86d4d8d4-zlqkx
에서 <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 업그레이드가 진행 중인지 확인합니다.
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
상태가 표시됩니다. 즉, 카탈로그 소스가 정상입니다.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
의미 |
하나 이상의 풀에 도달했거나 할당량에 매우 근접합니다. 이 오류 조건을 트리거하는 임계값은 |
보안 등급 | 높음 |
완화 방법
풀 할당량을 조정합니다. 다음 명령을 실행하여 풀 할당량을 완전히 제거하거나 축소합니다.
ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>
할당량 값을 0
으로 설정하면 할당량이 비활성화됩니다.
6.3.26. CephPoolQuotaBytesNearExhaustion
의미 |
하나 이상의 풀은 구성된 완전성 임계값에 도달하는 것입니다. 이 경고 조건을 트리거할 수 있는 임계값 중 하나는 |
보안 등급 | 높음 |
완화 방법
풀 할당량을 조정합니다. 다음 명령을 실행하여 풀 할당량을 완전히 제거하거나 축소합니다.
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 사용량이 높으면 처리 요구 사항이 증가하여 스토리지 성능이 저하될 수 있습니다. |
보안 등급 | 높음 |
진단
- Kubernetes 대시보드 또는 해당 대시보드로 이동합니다.
- Workloads 섹션에 액세스하여 OSD 경고와 관련된 관련 Pod를 선택합니다.
- 지표 탭을 클릭하여 OSD 컨테이너의 CPU 지표를 확인합니다.
- 경고 구성에 지정된 대로 CPU 사용량이 상당한 기간 동안 80%를 초과하는지 확인합니다.
완화 방법
OSD CPU 사용량이 일관되게 높은 경우 다음 단계를 수행하는 것이 좋습니다.
- 전체 스토리지 클러스터 성능을 평가하고 CPU 사용량에 기여하는 OSD를 식별합니다.
- 기존 노드에 새 스토리지 장치를 추가하거나 새 스토리지 장치가 있는 새 노드를 추가하여 클러스터의 OSD 수를 늘립니다. 부하를 배포하고 전체 시스템 성능을 개선하는 데 도움이 되는 지침은 스토리지 확장 가이드를 검토하십시오.
6.3.28. PersistentVolumeUsageCritical
의미 | PVC(영구 볼륨 클레임)는 전체 용량에 도달하고 있으며 적시에 참여하지 않은 경우 데이터 손실이 발생할 수 있습니다. |
보안 등급 | 높음 |
완화 방법
PVC 크기를 확장하여 용량을 늘립니다.
- OpenShift 웹 콘솔에 로그인합니다.
-
스토리지
PersistentVolumeClaim 을 클릭합니다. -
프로젝트 드롭다운 목록에서
openshift-storage
를 선택합니다. -
확장하려는 PVC에서 작업 메뉴( Cryostat)
Expand PVC 를 클릭합니다. - 총 크기를 원하는 크기로 업데이트합니다.
- 확장 을 클릭합니다.
또는 공간을 차지할 수 있는 불필요한 데이터를 삭제할 수도 있습니다.
6.3.29. PersistentVolumeUsageNearFull
의미 | PVC(영구 볼륨 클레임)는 전체 용량에 도달하고 있으며 적시에 참여하지 않은 경우 데이터 손실이 발생할 수 있습니다. |
보안 등급 | 높음 |
완화 방법
PVC 크기를 확장하여 용량을 늘립니다.
- OpenShift 웹 콘솔에 로그인합니다.
-
스토리지
PersistentVolumeClaim 을 클릭합니다. -
프로젝트 드롭다운 목록에서
openshift-storage
를 선택합니다. -
확장하려는 PVC에서 작업 메뉴( Cryostat)
Expand PVC 를 클릭합니다. - 총 크기를 원하는 크기로 업데이트합니다.
- 확장 을 클릭합니다.
또는 공간을 차지할 수 있는 불필요한 데이터를 삭제할 수도 있습니다.