5장. Ceph OSD 문제 해결
이 장에서는 Ceph OSD와 관련된 가장 일반적인 오류를 수정하는 방법에 대해 설명합니다.
사전 요구 사항
- 네트워크 연결을 확인합니다. 자세한 내용은 네트워킹 문제 해결을 참조하십시오.
-
ceph health
명령을 사용하여 Monitor에 쿼럼이 있는지 확인합니다. 명령에서 상태 상태(HEALTH_OK
,HEALTH_WARN
또는HEALTH_ERR
)를 반환하는 경우 모니터는 쿼럼을 구성할 수 있습니다. 그렇지 않은 경우 먼저 모니터 문제를 해결합니다. 자세한 내용은 Ceph 모니터 문제 해결을 참조하십시오.ceph 상태에 대한 자세한 내용은 Ceph 상태이해
를 참조하십시오. - 필요한 경우 재조정 프로세스를 중지하여 시간과 리소스를 절약할 수 있습니다. 자세한 내용은 중지 및 재조정 시작을 참조하십시오.
5.1. 가장 일반적인 Ceph OSD 오류
다음 표에는 ceph health detail
명령에서 반환하거나 Ceph 로그에 포함된 가장 일반적인 오류 메시지가 나열되어 있습니다. 표에서는 오류를 설명하고 문제를 해결하기 위해 특정 절차를 가리키는 해당 섹션에 대한 링크를 제공합니다.
사전 요구 사항
- Ceph OSD 노드에 대한 루트 수준 액세스.
5.1.1. Ceph OSD 오류 메시지
일반적인 Ceph OSD 오류 메시지 표와 잠재적인 수정 사항.
오류 메시지 | 참조 |
---|---|
| |
| |
| |
| |
| |
| |
| |
|
5.1.2. Ceph 로그의 일반적인 Ceph OSD 오류 메시지
Ceph 로그에 있는 일반적인 Ceph OSD 오류 메시지 표와 잠재적인 수정 사항에 대한 링크입니다.
오류 메시지 | 로그 파일 | 참조 |
---|---|---|
| 기본 클러스터 로그 | |
| 기본 클러스터 로그 | |
| 기본 클러스터 로그 | |
| OSD 로그 |
5.1.3. 전체 OSD
ceph health detail
명령은 다음과 유사한 오류 메시지를 반환합니다.
HEALTH_ERR 1 full osds osd.3 is full at 95%
이 값은 다음과 같습니다.
Ceph는 클라이언트가 전체 OSD 노드에서 I/O 작업을 수행하지 못하도록 데이터 손실을 방지합니다. 클러스터가 mon
메시지를 반환합니다. 기본적으로 이 매개 변수는 _osd_full_ratio
매개변수로 설정된 용량에 도달하면 HEALTH_ERR 전체 osds0.95
로 설정되어 클러스터 용량의 95%를 의미합니다.
이 문제를 해결하기 위해
원시 스토리지(%RAW USED
)의 백분율을 확인합니다.
ceph df
%RAW USED
가 70-75%를 초과하는 경우 다음을 수행할 수 있습니다.
- 불필요한 데이터를 삭제합니다. 이는 프로덕션 다운타임을 방지하기 위한 단기 솔루션입니다.
- 새 OSD 노드를 추가하여 클러스터를 확장합니다. 이는 Red Hat에서 권장하는 장기적인 솔루션입니다.
추가 리소스
- Red Hat Ceph Storage 문제 해결 가이드 의 전체 OSD.
- 자세한 내용은 전체 스토리지 클러스터에서 데이터 삭제를 참조하십시오.
5.1.4. Backfillfull OSDs
ceph health detail
명령은 다음과 유사한 오류 메시지를 반환합니다.
health: HEALTH_WARN 3 backfillfull osd(s) Low space hindering backfill (add storage if this doesn't resolve itself): 32 pgs backfill_toofull
이는 무엇을 의미합니까?
하나 이상의 OSD가 backfillfull 임계값을 초과하면 Ceph는 데이터가 이 장치로 재조정되지 않도록 합니다. 이는 재조정이 완료되지 않고 클러스터가 완전히 접근하고 있다는 조기 경고입니다. backfullfull 임계값의 기본값은 90%입니다.
이 문제를 해결하려면
풀별 사용률을 확인합니다.
ceph df
%RAW USED
가 70-75%를 초과하는 경우 다음 작업 중 하나를 수행할 수 있습니다.
- 불필요한 데이터를 삭제합니다. 이는 프로덕션 다운타임을 방지하기 위한 단기 솔루션입니다.
- 새 OSD 노드를 추가하여 클러스터를 확장합니다. 이는 Red Hat에서 권장하는 장기적인 솔루션입니다.
복구 프로세스를 계속할 수 있도록
backfull_toofull
에 중단된 PG가 포함된 OSD의 백필구문
ceph osd set-backfillfull-ratio VALUE
VALUE 의 범위는 0.0에서 1.0 사이입니다.
예
[ceph: root@host01/]# ceph osd set-backfillfull-ratio 0.92
추가 리소스
- Red Hat Ceph Storage 문제 해결 가이드 의 전체 OSDS.
- 자세한 내용은 전체 스토리지 클러스터에서 데이터 삭제를 참조하십시오.
5.1.5. 가까운 전체 OSD
ceph health detail
명령은 다음과 유사한 오류 메시지를 반환합니다.
HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%
이 값은 다음과 같습니다.
클러스터가 mon osd nearfull 비율 defaults 매개변수에 의해 설정된 용량에 도달하면 Ceph는
메시지를 반환합니다. 기본적으로 이 매개변수는 nearfull osd
s0.85
로 설정되어 클러스터 용량의 85%를 의미합니다.
Ceph는 가능한 한 최상의 방식으로 CRUSH 계층 구조를 기반으로 데이터를 배포하지만 동일한 배포를 보장할 수는 없습니다. uneven data distribution 및 nearfull osds
메시지의 주요 원인은 다음과 같습니다.
- OSD는 클러스터의 OSD 노드 간에 분산되지 않습니다. 즉, 일부 OSD 노드는 다른 OSD보다 훨씬 많은 OSD를 호스트하거나 CRUSH 맵에 있는 일부 OSD의 가중치는 용량에 적합하지 않습니다.
- PG(배치 그룹) 수는 OSD 수, 사용 사례, OSD당 대상 PG 및 OSD 사용률에 따라 적합하지 않습니다.
- 클러스터는 부적절한 CRUSH 튜닝 가능 항목을 사용합니다.
- OSD의 백엔드 스토리지는 거의 가득 차 있습니다.
이 문제를 해결하려면 다음을 수행하십시오.
- PG 수가 충분한지 확인하고 필요한 경우 늘리십시오.
- CRUSH 튜닝 가능 항목이 클러스터 버전에 가장 적합한지 확인하고 그렇지 않은 경우 조정합니다.
- 사용률에 따라 OSD의 가중치를 변경합니다.
OSD에서 사용하는 디스크에 남아 있는 공간 크기를 확인합니다.
OSD가 일반적으로 사용하는 공간 크기를 보려면 다음을 수행합니다.
[ceph: root@host01 /]# ceph osd df
특정 노드에서 OSD가 사용하는 공간 크기를 보려면 다음을 수행합니다.
거의 전체
OSD가 포함된 노드에서 다음 명령을 사용합니다.df
- 필요한 경우 새 OSD 노드를 추가합니다.
추가 리소스
- 전체 OSD
- Red Hat Ceph Storage 8용 스토리지 전략 가이드 의 OSD의 Weight by Utilization 섹션을 참조하십시오.
- 자세한 내용은 Red Hat Ceph Storage 8의 Storage Strategies 가이드의 CRUSH Tunables 섹션과 Red Hat Customer Portal의 OSD에서 CRUSH 맵 튜닝 가능 항목 수정이 미치는 영향을 테스트하는 방법을 참조하십시오.
- 자세한 내용은 배치 그룹 사용을 참조하십시오.
5.1.6. OSD 다운
ceph health detail
명령은 다음과 유사한 오류를 반환합니다.
HEALTH_WARN 1/3 in osds are down
이 값은 다음과 같습니다.
서비스 실패 또는 다른 OSD와의 통신 관련 문제로 인해 ceph-osd
프로세스 중 하나를 사용할 수 없습니다. 결과적으로 남아 있는 ceph-osd
데몬에서 이 실패를 모니터에 보고했습니다.
ceph-osd
데몬이 실행되지 않으면 기본 OSD 드라이브 또는 파일 시스템이 손상되거나 인증 키가 누락되어 데몬이 시작되지 않습니다.
대부분의 경우 ceph-osd
데몬이 실행 중이지만 여전히 down
으로 표시되는 경우 네트워킹 문제로 인해 상황이 발생합니다.
이 문제를 해결하기 위해
어떤 OSD가
다운
되었는지 확인합니다.[ceph: root@host01 /]# ceph health detail HEALTH_WARN 1/3 in osds are down osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080
ceph-osd
데몬을 다시 시작합니다. OSD_ID 를 다운된 OSD의 ID로 바꿉니다.구문
systemctl restart ceph-FSID@osd.OSD_ID
예
[root@host01 ~]# systemctl restart ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@osd.0.service
-
ceph-osd 를 시작할 수 없는 경우
ceph-osd
-
ceph-osd
데몬을 시작할 수 있지만아래로
표시된 경우ceph-osd
데몬이 실행 중이지만 여전히 'down' 로 표시됩니다.
-
ceph-osd 를 시작할 수 없는 경우
ceph-osd
데몬을 시작할 수 없습니다
- 여러 개의 OSD가 포함된 노드가 있는 경우(일반적으로 12개 이상) 기본 최대 스레드 수(PID 수)가 충분한지 확인합니다. 자세한 내용은 PID 수 감소를 참조하십시오.
-
OSD 데이터 및 저널 파티션이 올바르게 마운트되었는지 확인합니다.
ceph-volume lvm list
명령을 사용하여 Ceph Storage 클러스터와 연결된 모든 장치 및 볼륨을 나열한 다음 제대로 마운트되었는지 수동으로 검사할 수 있습니다. 자세한 내용은mount(8)
매뉴얼 페이지를 참조하십시오. -
ERROR: missing keyring이 있는 경우 인증 오류 메시지에 cephx를 사용할 수 없으며 OSD가 인증 인증
키링이 누락되어 있습니다. /var/lib/ceph/osd/ceph-1 오류 메시지에서 ERROR: unable to open OSD 슈퍼 블록을
열 수 없는 경우ceph-osd
데몬이 기본 파일 시스템을 읽을 수 없습니다. 이 오류 문제를 해결하고 해결하는 방법에 대한 지침은 다음 단계를 참조하십시오.-
해당 로그 파일을 확인하여 실패 원인을 확인합니다. 기본적으로 Ceph는 파일에 로깅이 활성화된 후
/var/log/ceph/CLUSTER_FSID/
디렉터리에 로그 파일을 저장합니다. -
EIO
오류 메시지는 기본 디스크의 실패를 나타냅니다. 이 문제를 해결하려면 기본 OSD 디스크를 교체합니다. 자세한 내용은 OSD 드라이브 교체를 참조하십시오. 로그에 다음과 같은 기타
FAILED 어설션
오류가 포함된 경우 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.FAILED assert(0 == "hit suicide timeout")
-
해당 로그 파일을 확인하여 실패 원인을 확인합니다. 기본적으로 Ceph는 파일에 로깅이 활성화된 후
기본 파일 시스템 또는 디스크의 오류가 있는지
dmesg
출력을 확인합니다.dmesg
다음과 유사한
오류 -5
오류 메시지는 기본 XFS 파일 시스템의 손상이라는 것을 나타냅니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 Red Hat 고객 포털에서 "xfs_log_force: error -5 returned"의 의미는 무엇입니까?xfs_log_force: error -5 returned
-
dmesg
출력에SCSI 오류 오류
메시지가 포함된 경우 Red Hat 고객 포털에서 SCSI 오류 코드 솔루션 찾기 솔루션을 참조하여 문제를 해결하는 가장 좋은 방법을 확인합니다. - 또는 기본 파일 시스템을 수정할 수 없는 경우 OSD 드라이브를 교체합니다. 자세한 내용은 OSD 드라이브 교체를 참조하십시오.
OSD가 다음과 같은 세그먼트 오류로 인해 실패한 경우 필요한 정보를 수집하고 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.
Caught signal (Segmentation fault)
ceph-osd
가 실행 중이지만 여전히 down
으로 표시됩니다.
해당 로그 파일을 확인하여 실패 원인을 확인합니다. 기본적으로 Ceph는 파일에 로깅이 활성화된 후
/var/log/ceph/CLUSTER_FSID/
디렉터리에 로그 파일을 저장합니다.로그에 다음과 유사한 오류 메시지가 포함된 경우 OSD Flapping을 참조하십시오.
wrongly marked me down heartbeat_check: no reply from osd.2 since back
- 다른 오류가 표시되면 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.
추가 리소스
- OSD 플로잉
- 오래된 배치 그룹
- 파일에 로깅할 수 있는 Ceph 데몬 로그 를 참조하십시오.
5.1.7. OSD 플로잉
ceph -w | grep osds
명령은 OSD를 다운
으로 반복적으로 표시한 다음 짧은 기간 내에 다시 가동
됩니다.
ceph -w | grep osds 2022-05-05 06:27:20.810535 mon.0 [INF] osdmap e609: 9 osds: 8 up, 9 in 2022-05-05 06:27:24.120611 mon.0 [INF] osdmap e611: 9 osds: 7 up, 9 in 2022-05-05 06:27:25.975622 mon.0 [INF] HEALTH_WARN; 118 pgs stale; 2/9 in osds are down 2022-05-05 06:27:27.489790 mon.0 [INF] osdmap e614: 9 osds: 6 up, 9 in 2022-05-05 06:27:36.540000 mon.0 [INF] osdmap e616: 9 osds: 7 up, 9 in 2022-05-05 06:27:39.681913 mon.0 [INF] osdmap e618: 9 osds: 8 up, 9 in 2022-05-05 06:27:43.269401 mon.0 [INF] osdmap e620: 9 osds: 9 up, 9 in 2022-05-05 06:27:54.884426 mon.0 [INF] osdmap e622: 9 osds: 8 up, 9 in 2022-05-05 06:27:57.398706 mon.0 [INF] osdmap e624: 9 osds: 7 up, 9 in 2022-05-05 06:27:59.669841 mon.0 [INF] osdmap e625: 9 osds: 6 up, 9 in 2022-05-05 06:28:07.043677 mon.0 [INF] osdmap e628: 9 osds: 7 up, 9 in 2022-05-05 06:28:10.512331 mon.0 [INF] osdmap e630: 9 osds: 8 up, 9 in 2022-05-05 06:28:12.670923 mon.0 [INF] osdmap e631: 9 osds: 9 up, 9 in
또한 Ceph 로그에 다음과 유사한 오류 메시지가 포함되어 있습니다.
2022-05-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down
2022-05-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2021-07-25 19:00:07.444113 front 2021-07-25 18:59:48.311935 (cutoff 2021-07-25 18:59:48.906862)
이 값은 다음과 같습니다.
OSD를 푸는 주요 원인은 다음과 같습니다.
- 스크럽 또는 복구와 같은 특정 스토리지 클러스터 작업은 예를 들어 큰 인덱스 또는 대규모 배치 그룹이 있는 오브젝트에 대해 이러한 작업을 수행하는 경우 비정상적으로 걸립니다. 일반적으로 이러한 작업이 완료되면 OSD 제거 문제가 해결됩니다.
-
기본 물리적 하드웨어 문제. 이 경우
ceph health details 명령은
느린 요청
오류 메시지도 반환합니다. - 네트워크에 문제가 있습니다.
Ceph OSD는 스토리지 클러스터의 사설 네트워크가 실패하거나 공용 클라이언트 연결 네트워크에 있는 대기 시간이 중요한 상황을 관리할 수 없습니다.
Ceph OSD는 개인 네트워크를 사용하여 하트비트 패킷을 서로 전송하여 해당 패킷이 up
및 in
임을 나타냅니다. 프라이빗 스토리지 클러스터 네트워크가 제대로 작동하지 않으면 OSD에서 하트비트 패킷을 전송하고 수신할 수 없습니다. 결과적으로 자신을 up
으로 표시하는 동안 서로 Ceph 모니터가 다운
된 것으로 보고합니다.
Ceph 구성 파일의 다음 매개 변수는 이 동작에 영향을 미칩니다.
매개변수 | 설명 | 기본값 |
---|---|---|
|
OSD가 Ceph 모니터에 OSD를 보고하기 전에 하트비트 패킷이 반환될 때까지 대기하는 시간입니다. | 20초 |
|
Ceph 모니터에서 OSD가 다운 상태가 되기 전에 다른 OSD가 | 2 |
이 표는 기본 구성에서 하나의 OSD만 첫 번째 OSD가 중단되는
경우 OSD가 down
으로 표시됨을 보여줍니다. 경우에 따라 단일 호스트에 네트워크 문제가 발생하면 전체 클러스터에 OSD가 발생할 수 있습니다. 호스트에 있는 OSD가 클러스터의 다른 OSD를 down
으로 보고하기 때문입니다.
OSD 제거 시나리오에는 OSD 프로세스가 시작된 다음 즉시 종료되는 상황이 포함되지 않습니다.
이 문제를 해결하기 위해
ceph 상태 세부 정보
명령의 출력을 다시 확인합니다.느린 요청
오류 메시지가 포함된 경우 이 문제를 해결하는 방법에 대한 자세한 내용은 에서 참조하십시오.ceph health detail HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests 30 ops are blocked > 268435 sec 1 ops are blocked > 268435 sec on osd.11 1 ops are blocked > 268435 sec on osd.18 28 ops are blocked > 268435 sec on osd.39 3 osds have slow requests
다운
으로 표시된 OSD와 노드가 어떤 노드에 있는지 확인합니다.ceph osd tree | grep down
- 그래프 OSD가 포함된 노드에서 네트워킹 문제를 해결하고 해결합니다.
또는
noup
및nodown
플래그를 설정하여 OSD를down
및up
으로 표시하도록 일시적으로 모니터를 강제 실행할 수 있습니다.ceph osd set noup ceph osd set nodown
중요noup
및nodown
플래그를 사용하면 문제의 근본 원인이 해결되지 않고 OSD만 작동하지 않습니다. 지원 티켓을 열려면 자세한 내용은 Red Hat 지원 문의 섹션을 참조하십시오.
OSD를 비우는 것은 Ceph OSD 노드, 네트워크 스위치 수준 또는 둘 다에서 MTU 구성 오류로 인해 발생할 수 있습니다. 이 문제를 해결하려면 MTU를 계획된 다운타임으로 코어 및 액세스 네트워크 스위치에서 포함하여 모든 스토리지 클러스터 노드의 균일한 크기로 설정합니다. 이 설정을 변경하면 네트워크 내의 문제를 숨길 수 있으며 실제 네트워크 불일치를 해결하지 않으므로 osd heartbeat min 크기를
조정하지 마십시오.
추가 리소스
- 자세한 내용은 Red Hat Ceph Storage 아키텍처 가이드의 Ceph하트비트 섹션을 참조하십시오.
- Red Hat Ceph Storage 문제 해결 가이드의 Slow 요청 또는 요청이 차단된 섹션을 참조하십시오.
5.1.8. 느린 요청 또는 요청이 차단됨
ceph-osd
데몬은 요청에 응답하기가 느리고 ceph health details
명령은 다음과 유사한 오류 메시지를 반환합니다.
HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests 30 ops are blocked > 268435 sec 1 ops are blocked > 268435 sec on osd.11 1 ops are blocked > 268435 sec on osd.18 28 ops are blocked > 268435 sec on osd.39 3 osds have slow requests
또한 Ceph 로그에는 다음과 유사한 오류 메시지가 포함됩니다.
2022-05-24 13:18:10.024659 osd.1 127.0.0.1:6812/3032 9 : cluster [WRN] 6 slow requests, 6 included below; oldest blocked for > 61.758455 secs
2022-05-25 03:44:06.510583 osd.50 [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]
이 값은 다음과 같습니다.
느린 요청이 있는 OSD는 osd_op_complaint_time
매개변수로 정의된 시간 내에 대기열의 I/O 작업(IOPS)을 서비스할 수 없는 모든 OSD입니다. 기본적으로 이 매개변수는 30초로 설정됩니다.
OSD에 요청이 느려지는 주요 원인은 다음과 같습니다.
- 디스크 드라이브, 호스트, 랙 또는 네트워크 스위치와 같은 기본 하드웨어 문제
- 네트워크에 문제가 있습니다. 이러한 문제는 일반적으로 플레이닝 OSD와 관련이 있습니다. 자세한 내용은 OSD 패칭 을 참조하십시오.
- 시스템 로드
다음 표에서는 느린 요청 유형을 보여줍니다. dump_historic_ops
관리 소켓 명령을 사용하여 느린 요청 유형을 확인합니다. 관리 소켓에 대한 자세한 내용은 Red Hat Ceph Storage 8 관리 가이드의 Ceph 관리 소켓 사용 섹션을 참조하십시오.
느린 요청 유형 | 설명 |
---|---|
| OSD는 작업을 위해 배치 그룹에서 잠금을 취득하기 위해 대기 중입니다. |
| OSD는 복제본 OSD가 해당 작업을 저널에 적용할 때까지 대기 중입니다. |
| OSD는 주요 작업 이정표에 도달하지 않았습니다. |
| OSD는 아직 지정된 횟수만큼 오브젝트를 복제하지 않았습니다. |
이 문제를 해결하기 위해
- 느린 또는 블록 요청이 있는 OSD가 일반적인 하드웨어(예: 디스크 드라이브, 호스트, 랙 또는 네트워크 스위치)를 공유하는지 확인합니다.
OSD가 디스크를 공유하는 경우:
smartmontools
유틸리티를 사용하여 디스크 또는 로그의 상태를 확인하여 디스크의 오류를 확인합니다.참고smartmontools
유틸리티는smartmontools
패키지에 포함되어 있습니다.OSD 디스크에서
iostat
유틸리티를 사용하여 OSD 디스크에서 I/O 대기 보고서(%iowai
)를 가져와서 디스크 부하가 많은지 확인합니다.참고iostat
유틸리티는 Cryostat 패키지에 포함되어
있습니다.
OSD가 다른 서비스와 노드를 공유하는 경우:
- RAM 및 CPU 사용률 확인
-
netstat
유틸리티를 사용하여 NIC(Network Interface Controller)에서 네트워크 통계를 확인하고 모든 네트워킹 문제를 해결합니다.
- OSD가 랙을 공유하는 경우 랙에 대한 네트워크 스위치를 확인합니다. 예를 들어 점보 프레임을 사용하는 경우 경로의 NIC에 점보 프레임이 설정되어 있는지 확인합니다.
- 느린 요청으로 OSD에서 공유하는 일반적인 하드웨어를 확인할 수 없거나 하드웨어 및 네트워킹 문제를 해결하고 해결하기 위해 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.
추가 리소스
- 자세한 내용은 Red Hat Ceph Storage 관리 가이드의 Ceph 관리소켓 사용 섹션을 참조하십시오.