9.2. 대부분의 일반적인 Ceph 배치 그룹 오류
다음 표에는 ceph 상태 세부 정보
명령에서 반환한 가장 일반적인 오류 메시지가 나열되어 있습니다. 테이블에서는 오류를 설명하고 문제를 해결하기 위해 특정 절차를 가리키는 해당 섹션에 대한 링크를 제공합니다.
또한 최적 상태가 아닌 배치 그룹을 나열할 수 있습니다. 자세한 내용은 9.3절. “오래된
배치,비활성
또는 불명확한 상태로
배치 그룹 나열” 을 참조하십시오.
9.2.1. 사전 요구 사항
- 실행 중인 Red Hat Ceph Storage 클러스터.
- 실행 중인 Ceph 개체 게이트웨이.
9.2.2. 배치 그룹 오류 메시지
일반적인 배치 그룹 오류 메시지의 테이블과 잠재적인 수정 사항.
오류 메시지 | 보기 |
---|---|
| |
| |
| |
| |
| |
| |
|
9.2.3. 오래된 배치 그룹
ceph health
명령은 일부 PG(배치 그룹)를 오래된
것으로 나열합니다.
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
이 의미
Monitor(모니터링)는 배치 그룹 작동 세트의 기본 OSD에서 상태 업데이트를 수신하지 못하거나 다른 OSD에서 기본 OSD가 다운
되었음을 보고한 경우 배치 그룹을 오래된
것으로 표시합니다.
일반적으로 PG는 스토리지 클러스터 를 시작한 후 피어링 프로세스가 완료될 때까지 오래된
상태로 들어갑니다. 그러나 PG가 예상보다 오래
지속되면 해당 PG의 기본 OSD가 다운
되었거나 PG 통계를 모니터에 보고하지 않음을 나타낼 수 있습니다. 오래된
PG를 저장하는 기본 OSD가 백업
되면 Ceph가 PG를 복구하기 시작합니다.
mon_osd_report_timeout
설정은 OSD에서 PGs 통계를 모니터에 보고하는 빈도를 결정합니다. 기본값으로 이 매개 변수는 0.5
로 설정되므로 OSD에서 반마다 통계를 보고합니다.
이 문제를 해결하려면
오래된 PG와
저장된
OSD를 식별합니다. 오류 메시지에는 다음 예와 유사한 정보가 포함됩니다.예제
# ceph health detail HEALTH_WARN 24 pgs stale; 3/300 in osds are down ... pg 2.5 is stuck stale+active+remapped, last acting [2,0] ... osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080 osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539 osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861
-
down
으로 표시된 OSD의 문제를 해결합니다. 자세한 내용은 Down OSDs를 참조하십시오.
추가 리소스
- Red Hat Ceph Storage 4의 관리 가이드에 있는 Monitoring Placement Group(모니터링 배치 그룹) 섹션
9.2.4. 일관되지 않은 배치 그룹
일부 배치 그룹은 active + clean + 불일치로
표시되며 ceph 상태 세부 정보
에서는 다음과 유사한 오류 메시지를 반환합니다.
HEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors
이 의미
Ceph가 배치 그룹에서 하나 이상의 오브젝트 복제본에서 불일치를 감지하면 배치 그룹을 일관되지 않게
표시합니다. 가장 일반적인 비일관성은 다음과 같습니다.
- 오브젝트의 크기가 올바르지 않습니다.
- 복구가 완료된 후 하나의 복제본에서 오브젝트가 누락됩니다.
대부분의 경우 배치 그룹 내에서 스크럽 중 오류로 인해 불일치가 발생합니다.
이 문제를 해결하려면
일관되지 않은
상태인 배치 그룹을 확인합니다.# ceph health detail HEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors
배치 그룹이
일치하지 않는
이유를 확인합니다.배치 그룹에서 심층 스크럽 프로세스를 시작합니다.
[root@mon ~]# ceph pg deep-scrub ID
ID
를일치하지 않는
배치 그룹의 ID로 바꿉니다. 예를 들면 다음과 같습니다.[root@mon ~]# ceph pg deep-scrub 0.6 instructing pg 0.6 on osd.0 to deep-scrub
ceph -w
의 출력을 검색하여 해당 배치 그룹과 관련된 메시지를 검색합니다.ceph -w | grep ID
ID
를일치하지 않는
배치 그룹의 ID로 바꿉니다. 예를 들면 다음과 같습니다.[root@mon ~]# ceph -w | grep 0.6 2015-02-26 01:35:36.778215 osd.106 [ERR] 0.6 deep-scrub stat mismatch, got 636/635 objects, 0/0 clones, 0/0 dirty, 0/0 omap, 0/0 hit_set_archive, 0/0 whiteouts, 1855455/1854371 bytes. 2015-02-26 01:35:36.788334 osd.106 [ERR] 0.6 deep-scrub 1 errors
출력에 다음과 유사한 오류 메시지가 포함된 경우
일치하지 않는
배치 그룹을 복구할 수 있습니다. 자세한 내용은 일치하지 않는 배치 그룹 복구를 참조하십시오.PG.ID shard OSD: soid OBJECT missing attr , missing attr _ATTRIBUTE_TYPE PG.ID shard OSD: soid OBJECT digest 0 != known digest DIGEST, size 0 != known size SIZE PG.ID shard OSD: soid OBJECT size 0 != known size SIZE PG.ID deep-scrub stat mismatch, got MISMATCH PG.ID shard OSD: soid OBJECT candidate had a read error, digest 0 != known digest DIGEST
출력에 다음과 유사한 오류 메시지가 포함된 경우 데이터가 손실될 수 있으므로
일치하지 않는
배치 그룹을 복구하는 것은 안전하지 않습니다. 이러한 상황에서 지원 티켓을 여십시오. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.PG.ID shard OSD: soid OBJECT digest DIGEST != known digest DIGEST PG.ID shard OSD: soid OBJECT omap_digest DIGEST != known omap_digest DIGEST
추가 리소스
- Red Hat Ceph Storage 문제 해결 가이드 의 배치 그룹 불일치 나열.
- Red Hat Ceph Storage 아키텍처 가이드의 Ceph데이터 무결성 섹션.
- Red Hat Ceph 스토리지 구성 가이드 의 OSD 스크루빙 섹션.
9.2.5. 불명확한 배치 그룹
ceph 상태
명령은 다음과 유사한 오류 메시지를 반환합니다.
HEALTH_WARN 197 pgs stuck unclean
이 의미
Ceph 구성 파일의 mon_pg_stuck_threshold
매개변수에 지정된 시간(초)에 대해 active+clean
상태를 달성하지 않은 경우
Ceph는 배치 그룹을 불명확하게 표시합니다. mon_pg_stuck_threshold
의 기본값은 300
초입니다.
배치 그룹이 불명확하면 osd_pool_default_size
매개변수에 지정된 횟수를 복제하지 않는 오브젝트가 포함됩니다
. osd_pool_default_size
의 기본값은 3
이므로 Ceph에서 세 개의 복제본을 만듭니다.
일반적으로 불 명확한
배치 그룹은 일부 OSD가 다운
될 수 있음을 나타냅니다.
이 문제를 해결하려면
다운
된 OSD 확인 :# ceph osd tree
- OSD 문제를 해결하고 수정합니다. 자세한 내용은 Down OSDs 를 참조하십시오.
9.2.6. 비활성 배치 그룹
ceph 상태
명령은 다음과 유사한 오류 메시지를 반환합니다.
HEALTH_WARN 197 pgs stuck inactive
이 의미
Ceph 구성 파일의 mon_pg_stuck_threshold
매개변수에 지정된 시간 동안 활성화되지 않은 경우 Ceph는 배치 그룹을 비활성
상태로 표시합니다. mon_pg_stuck_threshold
의 기본값은 300
초입니다.
일반적으로 비활성
배치 그룹은 일부 OSD가 다운
될 수 있음을 나타냅니다.
이 문제를 해결하려면
다운
된 OSD 확인 :# ceph osd tree
- OSD 문제를 해결하고 수정합니다.
추가 리소스
- 배치 그룹이 오래된 비활성 상태 또는 불명확한 상태 나열
- 자세한 내용은 Down OSDs 를 참조하십시오.
9.2.7. 배치 그룹이 종료되었습니다
ceph 상태 세부 정보
명령은 일부 배치 그룹이 다운
되었음을 보고합니다.
HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down ... pg 0.5 is down+peering pg 1.4 is down+peering ... osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651
이 의미
피어링 프로세스를 차단하여 배치 그룹이 활성화되고 사용할 수 없게 되는 경우도 있습니다. 일반적으로 OSD가 실패하면 피어링 오류가 발생합니다.
이 문제를 해결하려면
피어링 프로세스 차단을 결정합니다.
[root@mon ~]# ceph pg ID query
ID
를 배치 그룹의 ID 로
교체합니다. 예를 들면 다음과 같습니다.
[root@mon ~]# ceph pg 0.5 query { "state": "down+peering", ... "recovery_state": [ { "name": "Started\/Primary\/Peering\/GetInfo", "enter_time": "2012-03-06 14:40:16.169679", "requested_info_from": []}, { "name": "Started\/Primary\/Peering", "enter_time": "2012-03-06 14:40:16.169659", "probing_osds": [ 0, 1], "blocked": "peering is blocked due to down osds", "down_osds_we_would_probe": [ 1], "peering_blocked_by": [ { "osd": 1, "current_lost_at": 0, "comment": "starting or marking this osd lost may let us proceed"}]}, { "name": "Started", "enter_time": "2012-03-06 14:40:16.169513"} ] }
recovery_state
섹션에는 피어 프로세스가 차단된 이유에 대한 정보가 포함되어 있습니다.
-
출력에
osds 오류 메시지로 인해 피어링이 차단된
경우 OSD를 Down 으로 참조하십시오. - 다른 오류 메시지가 표시되면 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 서비스에 문의하십시오.
추가 리소스
- Red Hat Ceph Storage 관리 가이드의 CephOSD 피어링 섹션.
9.2.8. 찾을 수 없는 오브젝트
ceph 상태
명령은 unfound
키워드를 포함하는 다음과 유사한 오류 메시지를 반환합니다.
HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
이 의미
Ceph는 이러한 개체 또는 최신 사본이 존재할 때
개체를 찾을 수 없지만 찾을 수 없습니다. 결과적으로 Ceph는 이러한 오브젝트를 복구할 수 없으며 복구 프로세스를 진행할 수 없습니다.
예제 상황
배치 그룹은 osd.1 및
에 데이터를 저장합니다.
osd.
2
-
OSD.1
이줄어듭니다
. -
OSD.2
는 몇 가지 쓰기 작업을 처리합니다. -
OSD.1
이
표시됩니다. -
osd.1과
사이의 피어링 프로세스가 시작되고osd.
2osd.1
에 누락된 오브젝트는 복구를 위해 대기열에 추가됩니다. -
Ceph에서 새 개체를 복사하기 전에
osd.2
가중단
됩니다.
결과적으로 osd.1
은 이러한 오브젝트가 있음을 알 수 있지만 오브젝트 복사본이 있는 OSD는 없습니다.
이 시나리오에서 Ceph는 실패한 노드에 다시 액세스할 수 있을 때까지 대기 중이며 찾을 수 없는
개체가 복구 프로세스를 차단합니다.
이 문제를 해결하려면
찾을 수
없는 개체를
포함하는 배치 그룹을 확인합니다.[root@mon ~]# ceph health detail HEALTH_WARN 1 pgs recovering; 1 pgs stuck unclean; recovery 5/937611 objects degraded (0.001%); 1/312537 unfound (0.000%) pg 3.8a5 is stuck unclean for 803946.712780, current state active+recovering, last acting [320,248,0] pg 3.8a5 is active+recovering, acting [320,248,0], 1 unfound recovery 5/937611 objects degraded (0.001%); **1/312537 unfound (0.000%)**
배치 그룹에 대한 자세한 정보를 나열합니다.
[root@mon ~]# ceph pg ID query
ID
를 찾을 수없는 개체가 포함된 배치 그룹의 ID로 바꿉니다.
예를 들면 다음과 같습니다.[root@mon ~]# ceph pg 3.8a5 query { "state": "active+recovering", "epoch": 10741, "up": [ 320, 248, 0], "acting": [ 320, 248, 0], <snip> "recovery_state": [ { "name": "Started\/Primary\/Active", "enter_time": "2015-01-28 19:30:12.058136", "might_have_unfound": [ { "osd": "0", "status": "already probed"}, { "osd": "248", "status": "already probed"}, { "osd": "301", "status": "already probed"}, { "osd": "362", "status": "already probed"}, { "osd": "395", "status": "already probed"}, { "osd": "429", "status": "osd is down"}], "recovery_progress": { "backfill_targets": [], "waiting_on_backfill": [], "last_backfill_started": "0\/\/0\/\/-1", "backfill_info": { "begin": "0\/\/0\/\/-1", "end": "0\/\/0\/\/-1", "objects": []}, "peer_backfill_info": [], "backfills_in_flight": [], "recovering": [], "pg_backend": { "pull_from_peer": [], "pushing": []}}, "scrub": { "scrubber.epoch_start": "0", "scrubber.active": 0, "scrubber.block_writes": 0, "scrubber.finalizing": 0, "scrubber.waiting_on": 0, "scrubber.waiting_on_whom": []}}, { "name": "Started", "enter_time": "2015-01-28 19:30:11.044020"}],
might_have_unfound
섹션에는 Ceph가 발견되지않은 오브젝트
를 찾으려고 하는 OSD가 포함되어 있습니다.-
이미 probed
상태는 Ceph가 해당 OSD에서 발견되지않은 개체를
찾을 수 없음을 나타냅니다. -
osd가 down 상태이면
Ceph가 OSD에 연결할 수 없음을 나타냅니다.
-
-
down
으로 표시된 OSD의 문제를 해결합니다. 자세한 내용은 Down OSDs 를 참조하십시오. -
OSD가 중단되는 문제를 해결할 수 없는 경우 지원 티켓을
엽니다
. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.