7장. Ceph 배치 그룹 문제 해결


이 섹션에서는 Ceph PG(배치 그룹)와 관련된 가장 일반적인 오류를 수정하는 방법에 대해 설명합니다.

사전 요구 사항

  • 네트워크 연결을 확인합니다.
  • 모니터가 쿼럼을 구성할 수 있는지 확인합니다.
  • 정상적인 모든 OSD가 upin 이고 백필링 및 복구 프로세스가 완료되었는지 확인합니다.

7.1. 가장 일반적인 Ceph 배치 그룹 오류

다음 표에는 ceph health detail 명령에서 반환하는 가장 일반적인 오류 메시지가 나와 있습니다. 이 표에서는 오류를 설명하고 문제를 해결하기 위해 특정 절차를 가리키는 해당 섹션에 대한 링크를 제공합니다.

또한 최적이 아닌 상태로 고정되는 배치 그룹을 나열할 수 있습니다. 자세한 내용은 7.2절. “오래된,비활성 상태 또는 불명확한 상태로 설정된 배치 그룹 나열 을 참조하십시오.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 실행 중인 Ceph 오브젝트 게이트웨이.

7.1.1. 배치 그룹 오류 메시지

공통 배치 그룹 오류 메시지 및 잠재적인 수정으로 구성된 테이블입니다.

오류 메시지참조

HEALTH_ERR

PGS 다운

배치 그룹이 다운

PGS inconsistent

일관되지 않은 배치 그룹

스크럽 오류

일관되지 않은 배치 그룹

HEALTH_WARN

PGS 오래된

오래된 배치 그룹

unfound

unfound 오브젝트

7.1.2. 오래된 배치 그룹

ceph 상태 명령은 일부 PG(배치 그룹)를 오래된 상태로 나열합니다.

HEALTH_WARN 24 pgs stale; 3/300 in osds are down

이 의미는 무엇입니까?

모니터는 배치 그룹의 작동 세트의 기본 OSD에서 상태 업데이트를 받지 못하거나 기본 OSD가 다운 된 것으로 보고되는 경우 배치 그룹을 오래된 것으로 표시합니다.

일반적으로 스토리지 클러스터를 시작한 후 피어링 프로세스가 완료될 때까지 PG가 오래된 상태로 들어갑니다. 그러나 PG가 예상보다 오래 유지되는 경우 해당 PG의 기본 OSD가 다운 되었거나 PG 통계를 모니터에 보고하지 않음을 나타낼 수 있습니다. 오래된 PG를 저장하는 기본 OSD가 백업 되면 Ceph가 PG를 복구하기 시작합니다.

mon_osd_report_timeout 설정은 OSD가 모니터에 PGs 통계를 보고하는 빈도를 결정합니다. 기본적으로 이 매개변수는 0.5 로 설정되어 있습니다. 즉, OSD는 절반마다 통계를 보고합니다.

문제 해결 방법

  1. 오래된 PG와 해당 OSD가 저장되는 PG를 식별합니다. 오류 메시지에는 다음 예와 유사한 정보가 포함됩니다.

    예제

    [ceph: root@host01 /]# 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

  2. 아래로 표시된 OSD의 문제를 해결합니다. 자세한 내용은 Down OSDs 를 참조하십시오.

추가 리소스

7.1.3. 일관되지 않은 배치 그룹

일부 배치 그룹은 활성 + 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가 배치 그룹에 있는 하나 이상의 오브젝트 복제본에서 불일치를 감지하면 배치 그룹을 일관되지 않은 것으로 표시합니다. 가장 일반적인 불일치는 다음과 같습니다.

  • 오브젝트에는 잘못된 크기가 있습니다.
  • 복구가 완료된 후 하나의 복제본에서 개체가 누락됩니다.

대부분의 경우, 스크럽하는 동안 오류는 배치 그룹 내에서 불일치를 발생시킵니다.

문제 해결 방법

  1. Cephadm 쉘에 로그인합니다.

    예제

    [root@host01 ~]# cephadm shell

  2. 일관되지 않은 상태에 있는 배치 그룹을 확인합니다.

    [ceph: root@host01 /]# 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
  3. 배치 그룹이 일관성이 없는 이유를 확인합니다.

    1. 배치 그룹에서 딥 검사 프로세스를 시작합니다.

      구문

      ceph pg deep-scrub ID

      일관되지 않은 배치 그룹의 ID 로 ID를 바꿉니다. 예를 들면 다음과 같습니다.

      [ceph: root@host01 /]# ceph pg deep-scrub 0.6
      instructing pg 0.6 on osd.0 to deep-scrub
    2. ceph -w 의 출력에서 해당 배치 그룹과 관련된 메시지를 검색합니다.

      구문

      ceph -w | grep ID

      일관되지 않은 배치 그룹의 ID 로 ID를 바꿉니다. 예를 들면 다음과 같습니다.

      [ceph: root@host01 /]# ceph -w | grep 0.6
      2022-05-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.
      2022-05-26 01:35:36.788334 osd.106 [ERR] 0.6 deep-scrub 1 errors
  4. 출력에 다음과 유사한 오류 메시지가 포함된 경우 일관성 없는 배치 그룹을 복구할 수 있습니다. 자세한 내용은 일관성 없는 배치 그룹을 참조하십시오.

    구문

    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

  5. 출력에 다음 메시지와 유사한 오류 메시지가 포함된 경우 데이터를 손실할 수 있으므로 일관되지 않은 배치 그룹을 복구하는 것이 안전하지 않습니다. 이 경우 지원 티켓을 엽니 다. 자세한 내용은 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

추가 리소스

7.1.4. 불명확한 배치 그룹

ceph health 명령은 다음과 유사한 오류 메시지를 반환합니다.

HEALTH_WARN 197 pgs stuck unclean

이 의미는 무엇입니까?

Ceph 구성 파일의 mon_pg_stuck_threshold 매개변수에 지정된 초 동안 active+clean 상태를 달성하지 않은 경우 배치 그룹을 불명확 하게 표시합니다. mon_pg_stuck_threshold 의 기본값은 300 초입니다.

배치 그룹이 불명확한 경우 osd_pool_default_size 매개변수에 지정된 횟수를 복제하지 않는 오브젝트가 포함됩니다. osd_pool_default_size 의 기본값은 3 이며, 이는 Ceph에서 세 개의 복제본을 생성합니다.

일반적으로 불명확한 배치 그룹은 일부 OSD가 다운 될 수 있음을 나타냅니다.

문제 해결 방법

  1. 어떤 OSD가 다운 되었는지 확인합니다.

    [ceph: root@host01 /]# ceph osd tree
  2. OSD의 문제를 해결하고 해결합니다. 자세한 내용은 Down OSD 를 참조하십시오.

7.1.5. 비활성 배치 그룹

ceph health 명령은 다음과 유사한 오류 메시지를 반환합니다.

HEALTH_WARN 197 pgs stuck inactive

이 의미는 무엇입니까?

Ceph 구성 파일의 mon_pg_stuck_threshold 매개변수에 지정된 초 동안 활성화되지 않은 경우 배치 그룹을 비활성 으로 표시합니다. mon_pg_stuck_threshold 의 기본값은 300 초입니다.

일반적으로 비활성 배치 그룹은 일부 OSD가 다운 될 수 있음을 나타냅니다.

문제 해결 방법

  1. 어떤 OSD가 다운 되었는지 확인합니다.

    # ceph osd tree
  2. OSD의 문제를 해결하고 해결합니다.

추가 리소스

7.1.6. 배치 그룹이 다운됨

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 실패로 인해 피어링이 실패합니다.

문제 해결 방법

피어링 프로세스를 차단하는 작업을 결정합니다.

구문

ceph pg ID query

ID아래 배치 그룹의 ID로 바꿉니다.

예제

[ceph: root@host01 /]#  ceph pg 0.5 query

{ "state": "down+peering",
  ...
  "recovery_state": [
       { "name": "Started\/Primary\/Peering\/GetInfo",
         "enter_time": "2021-08-06 14:40:16.169679",
         "requested_info_from": []},
       { "name": "Started\/Primary\/Peering",
         "enter_time": "2021-08-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": "2021-08-06 14:40:16.169513"}
   ]
}

recovery_state 섹션에는 피어링 프로세스가 차단되는 이유에 대한 정보가 포함되어 있습니다.

추가 리소스

7.1.7. unfound 오브젝트

ceph health 명령은 unfound 키워드를 포함하는 다음 것과 유사한 오류 메시지를 반환합니다.

HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)

이 의미는 무엇입니까?

Ceph는 이러한 오브젝트 또는 최신 복사본이 존재하는지 알 때 개체를 unfound 로 표시하지만 찾을 수 없습니다. 따라서 Ceph는 이러한 오브젝트를 복구할 수 없으며 복구 프로세스를 진행할 수 없습니다.

예시 설명

배치 그룹은 osd.1osd.2 에 데이터를 저장합니다.

  1. OSD.1다운 됩니다.
  2. OSD.2 에서는 일부 쓰기 작업을 처리합니다.
  3. OSD.1 이 시작됩니다.
  4. osd.1osd.2 간의 피어링 프로세스가 시작되고 osd.1 에서 누락된 오브젝트는 복구를 위해 큐에 추가됩니다.
  5. Ceph가 새 오브젝트를 복사하기 전에 osd.2다운 됩니다.

결과적으로 osd.1 은 이러한 오브젝트가 있음을 알고 있지만 오브젝트 복사본이 있는 OSD는 없습니다.

이 시나리오에서는 Ceph가 실패한 노드에 다시 액세스할 때까지 대기 중이며, unfound 오브젝트는 복구 프로세스를 차단합니다.

문제 해결 방법

  1. Cephadm 쉘에 로그인합니다.

    예제

    [root@host01 ~]# cephadm shell

  2. unfound 오브젝트가 포함된 배치 그룹을 확인합니다.

    [ceph: root@host01 /]# 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%)**
  3. 배치 그룹에 대한 자세한 정보를 나열합니다.

    구문

    ceph pg ID query

    unfound 오브젝트가 포함된 배치 그룹의 ID 로 ID를 바꿉니다.

    예제

    [ceph: root@host01 /]# 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": "2021-08-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": "2021-08-28 19:30:11.044020"}],

    might_have_unfound 섹션에는 Ceph가 unfound 오브젝트를 찾으려고 하는 OSD가 포함되어 있습니다.

    • 이미 프로브된 상태는 Ceph가 해당 OSD에서 unfound 오브젝트를 찾을 수 없음을 나타냅니다.
    • osd is down 상태는 Ceph가 해당 OSD에 연결할 수 없음을 나타냅니다.
  4. 아래로 표시된 OSD의 문제를 해결합니다. 자세한 내용은 Down OSD 를 참조하십시오.
  5. OSD를 중단하는 문제를 해결할 수 없는 경우 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 팀에 문의하십시오.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.