5장. Ceph OSD 문제 해결
이 장에서는 Ceph OSD와 관련된 가장 일반적인 오류를 수정하는 방법에 대해 설명합니다.
사전 요구 사항
- 네트워크 연결을 확인합니다. 자세한 내용은 네트워킹 문제 해결을 참조하십시오.
-
ceph health
명령을 사용하여 모니터에 쿼럼이 있는지 확인합니다. 명령에서 상태(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 OSD
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가 백필 전체 임계값을 초과한 경우 Ceph는 데이터가 이 장치로 재조정되지 않도록 합니다. 이는 재조정이 완료되지 않고 클러스터가 완전히 접근하고 있다는 초기 경고입니다. 백전체 임계값의 기본값은 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 문제 해결 가이드 의 nearfull OSDS
- 자세한 내용은 전체 스토리지 클러스터에서 데이터 삭제를 참조하십시오.
5.1.5. nearfull OSD
ceph health detail
명령은 다음과 유사한 오류 메시지를 반환합니다.
HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%
이 의미는 무엇입니까?
클러스터가 mon osd nearfull ratio defaults
매개변수에 의해 설정된 용량에 도달하면 Ceph에서 nearfull osds
메시지를 반환합니다. 기본적으로 이 매개변수는 0.85
로 설정되어 클러스터 용량의 85%를 의미합니다.
Ceph는 가능한 최상의 방식으로 data를 배포하지만 동일한 배포를 보장할 수는 없습니다. Even data distribution 및 nearfull osds
메시지의 주요 원인은 다음과 같습니다.
- OSD는 클러스터의 OSD 노드 간에 균형을 맞추지 않습니다. 즉, 일부 OSD 노드는 다른 것보다 훨씬 더 많은 OSD를 호스팅하거나 DestinationRule 맵의 일부 OSD의 가중치는 용량에 적합하지 않습니다.
- PG(배치 그룹) 수는 OSD 수, 사용 사례, OSD당 대상 PG 및 OSD 사용률에 따라 적합하지 않습니다.
- 클러스터는 부적절한 DestinationRule 튜닝 가능 항목을 사용합니다.
- OSD의 백엔드 스토리지는 거의 가득 차 있습니다.
이 문제를 해결하려면 다음을 수행하십시오.
- PG 수가 충분한지 확인하고 필요한 경우 늘립니다.
- 클러스터 버전에 최적으로 DestinationRule 튜닝 가능 항목을 사용하는지 확인하고 그렇지 않은 경우 조정할 수 있습니다.
- 사용률에 따라 OSD의 가중치를 변경합니다.
OSD에서 사용하는 디스크에 남은 공간을 결정합니다.
일반적으로 OSD에서 사용하는 공간 크기를 보려면 다음을 수행합니다.
[ceph: root@host01 /]# ceph osd df
특정 노드에서 OSD가 사용하는 공간을 보려면 다음을 수행합니다. OSD가
거의 모든
노드를 포함하는 노드에서 다음 명령을 사용합니다.df
- 필요한 경우 새 OSD 노드를 추가합니다.
추가 리소스
- 전체 OSD
- Red Hat Ceph Storage 6의 스토리지 전략 가이드에서 OSD의 Weight by Utilization 섹션을 참조하십시오.
- 자세한 내용은 Red Hat Ceph Storage 6의 Storage Strategies 가이드의ECDHE Tunable s 섹션 및 Red Hat Ceph Storage의 OSD 간 PG 배포에서 미치는 영향을 어떻게 테스트할 수 있습니까?
- 자세한 내용은 배치 그룹 승격 을 참조하십시오.
5.1.6. Downward 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
데몬을 시작할 수 있지만down
으로 표시되면ceph-osd
데몬의 단계가 실행 중이지만 여전히 '다운'으로 표시됩니다.
-
ceph-osd
데몬을 시작할 수 없음
- 여러 OSD(일반적으로 초과)를 포함하는 노드가 있는 경우 기본 최대 스레드(PID 수)가 충분한지 확인합니다. 자세한 내용은 PID 수 할당 을 참조하십시오.
-
OSD 데이터 및 저널 파티션이 올바르게 마운트되었는지 확인합니다.
ceph-volume lvm list
명령을 사용하여 Ceph Storage Cluster와 연결된 모든 장치 및 볼륨을 나열한 다음 제대로 마운트되었는지 수동으로 검사할 수 있습니다. 자세한 내용은mount(8)
매뉴얼 페이지를 참조하십시오. -
ERROR: missing keyring이 있는 경우 인증 오류 메시지에 cephx를 사용할 수 없는
경우 OSD는 누락된 인증 키입니다. /var/lib/ceph/osd/ceph-1 오류 메시지에 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 Customer Portal의 SCSI 오류 코드 솔루션 찾기 솔루션을 참조하여 문제를 해결하는 가장 좋은 방법을 결정합니다. - 또는 기본 파일 시스템을 수정할 수 없는 경우 OSD 드라이브를 교체합니다. 자세한 내용은 OSD 드라이브 교체를 참조하십시오.
다음과 같은 세그먼트 장애로 OSD가 실패한 경우 필요한 정보를 수집하고 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 팀에 문의하십시오.
Caught signal (Segmentation fault)
ceph-osd
가 실행 중이지만 여전히 down
으로 표시됩니다.
해당 로그 파일을 확인하여 실패 원인을 확인합니다. 기본적으로 Ceph는 파일에 로깅된 후
/var/log/ceph/CLUSTER_FSID/
디렉터리에 로그 파일을 저장합니다.로그에 다음과 유사한 오류 메시지가 포함된 경우 Flapping OSD 를 참조하십시오.
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를 반복적으로 down
으로 표시한 다음 짧은 시간 내에 다시 표시합니다.
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 detail
명령은느린 요청
오류 메시지도 반환합니다. - 네트워크에 문제가 있습니다.
Ceph OSD는 스토리지 클러스터의 프라이빗 네트워크가 실패하거나 공용 클라이언트 방향 네트워크에 있는 대기 시간이 많은 상황을 관리할 수 없습니다.
Ceph OSD는 사설 네트워크를 사용하여 서로 하트비트 패킷을 전송하여 실행 중임을 나타냅니다.
개인 스토리지 클러스터 네트워크가 제대로 작동하지 않으면 OSD에서 하트비트 패킷을 보내고 수신할 수 없습니다. 결과적으로 서로 Ceph 모니터가
중단되
는 것으로 보고되는 반면, 자체적으로 up
으로 표시됩니다.
Ceph 구성 파일의 다음 매개변수는 이 동작에 영향을 미칩니다.
매개변수 | 설명 | 기본값 |
---|---|---|
|
OSD를 Ceph 모니터로 보고하기 전에 하트비트 패킷이 반환될 때까지 OSD가 대기하는 시간입니다. | 20초 |
|
Ceph Monitors가 OSD를 아래로 표시하기 전에 다른 OSD를 | 2 |
이 표에는 기본 구성에서 Ceph Monitor가 첫 번째 OSD에 대한 세 가지 보고서만 다운된 경우 OSD를
으로 표시합니다. 경우에 따라 단일 호스트에서 네트워크 문제가 발생하는 경우 전체 클러스터에 대해 OSD가 발생할 수 있습니다. 이는 호스트에 있는 OSD가 클러스터의 다른 OSD를 down
down
으로 보고하기 때문입니다.
샘플링 OSD 시나리오에는 OSD 프로세스가 시작된 후 즉시 종료되는 상황이 포함되지 않습니다.
문제 해결 방법
ceph health detail
명령 출력을 다시 확인합니다.느린 요청
오류 메시지가 포함된 경우 이 문제 해결 방법에 대한 자세한 내용은 을 참조하십시오.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가
down
으로 표시되는지 그리고 해당 OSD가 상주하는 노드를 확인합니다.ceph osd tree | grep down
- OSD가 포함된 노드에서 네트워킹 문제를 해결하고 수정합니다.
또는
noup
및nodown
플래그를 설정하여 일시적으로 OSD를아래로
표시하고up
으로 표시하는 것을 중지할 수 있습니다.ceph osd set noup ceph osd set nodown
중요noup
및nodown
플래그를 사용하면 문제의 근본 원인이 해결되지 않고 OSD만 플레치되지 않습니다. 지원 티켓을 열려면 자세한 내용은 Red Hat 지원 문의 섹션을 참조하십시오.
Ceph OSD 노드, 네트워크 스위치 수준 또는 둘 다에서 MTU 구성이 잘못되어 있을 수 있습니다. 이 문제를 해결하려면 다운타임이 예정되어 있는 코어 및 액세스 네트워크 스위치를 포함하여 MTU를 모든 스토리지 클러스터 노드의 균일한 크기로 설정합니다. 이 설정을 변경하면 네트워크 내에서 문제를 숨길 수 있으므로 osd heartbeat min 크기를
조정하지 마십시오. 실제 네트워크 불일치는 해결되지 않습니다.
추가 리소스
- 자세한 내용은 Red Hat Ceph Storage 아키텍처 가이드의 Ceph하트비트 섹션을 참조하십시오.
- Red Hat Ceph Storage 문제 해결 가이드의 Slow 요청 또는 요청 차단 섹션을 참조하십시오.
5.1.8. 느린 요청 또는 요청이 차단됨
ceph-osd
데몬은 요청에 응답하는 속도가 느리고 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
또한 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
매개변수에 의해 정의된 시간 내에 대기열의 IOPS(초당 I/O 작업)를 서비스할 수 없는 모든 OSD입니다. 기본적으로 이 매개변수는 30초로 설정됩니다.
OSD 요청 속도가 느린 주요 원인은 다음과 같습니다.
- 디스크 드라이브, 호스트, 랙 또는 네트워크 스위치와 같은 기본 하드웨어 문제
- 네트워크에 문제가 있습니다. 이러한 문제는 일반적으로 플레치 OSD와 연결됩니다. 자세한 내용은 Flapping OSD 를 참조하십시오.
- 시스템 로드
다음 표에서는 느린 요청 유형을 보여줍니다. dump_historic_ops
관리 소켓 명령을 사용하여 느린 요청 유형을 확인합니다. 관리 소켓에 대한 자세한 내용은 Red Hat Ceph Storage 6 관리 가이드의 Ceph 관리 소켓 사용 섹션을 참조하십시오.
느린 요청 유형 | 설명 |
---|---|
| OSD는 작업용 배치 그룹에 잠금을 얻기 위해 대기 중입니다. |
| OSD는 복제 OSD가 저널에 작업을 적용하기 위해 대기 중입니다. |
| OSD가 주요 작업 이정표에 도달하지 못했습니다. |
| OSD는 아직 지정된 수의 오브젝트를 복제하지 않았습니다. |
문제 해결 방법
- 느린 또는 블록 요청이 있는 OSD가 디스크 드라이브, 호스트, 랙 또는 네트워크 스위치와 같은 일반적인 하드웨어를 공유하는지 확인합니다.
OSD가 디스크를 공유하는 경우:
smartmontools
유틸리티를 사용하여 디스크 또는 로그의 상태를 확인하여 디스크의 오류를 확인합니다.참고smartmontools
유틸리티는smartmontools
패키지에 포함되어 있습니다.iostat
유틸리티를 사용하여 OSD 디스크의 I/O 대기 보고서(%iowai
)를 가져와서 디스크 부하가 많은지 확인합니다.참고iostat
유틸리티는sysstat
패키지에 포함되어 있습니다.
OSD가 노드를 다른 서비스와 공유하는 경우:
- RAM 및 CPU 사용률 확인
-
netstat
유틸리티를 사용하여 NIC(Network Interface Controller)의 네트워크 통계를 확인하고 네트워킹 문제를 해결합니다.
- OSD가 랙을 공유하는 경우 랙에 대해 네트워크 스위치를 확인합니다. 예를 들어 점보 프레임을 사용하는 경우 경로의 NIC에 점보 프레임이 설정되어 있는지 확인합니다.
- OSD에서 느린 요청과 함께 공유하는 일반적인 하드웨어를 결정할 수 없거나 하드웨어 및 네트워킹 문제를 해결하고 수정하려면 지원 티켓을 엽니다. 자세한 내용은 서비스 관련 Red Hat 지원 문의를 참조하십시오.
추가 리소스
- 자세한 내용은 Red Hat Ceph Storage 관리 가이드의 Ceph 관리소켓 사용 섹션을 참조하십시오.