3.3. Ceph 스토리지 클러스터의 낮은 수준의 모니터링


스토리지 관리자는 낮은 수준의 관점에서 Red Hat Ceph Storage 클러스터의 상태를 모니터링할 수 있습니다. 일반적으로 낮은 수준의 모니터링에는 Ceph OSD가 올바르게 피어링되었는지 확인하는 작업이 포함됩니다. 피어링 오류가 발생하면 배치 그룹이 성능이 저하된 상태에서 작동합니다. 이 성능 저하 상태는 하드웨어 오류, 중단된 Ceph 데몬, 네트워크 대기 시간 또는 완전한 사이트 중단과 같은 다양한 문제로 인해 발생할 수 있습니다.

3.3.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.

3.3.2. 배치 그룹 세트 모니터링

CRUSH가 배치 그룹을 Ceph OSD에 할당할 때 풀의 복제본 수를 확인하고 각 배치 그룹을 Ceph OSD에 할당하여 배치 그룹을 다른 Ceph OSD에 할당합니다. 예를 들어 풀에 배치 그룹의 복제본이 세 개 필요한 경우 CRUSH가 osd.1,osd.2osd.3 에 각각 할당할 수 있습니다. CRUSH는 실제로 CRUSH 맵에 설정한 실패 도메인을 고려하기 위한 의사랜덤 배치를 검색하므로 대규모 클러스터에서 가장 가까운 Ceph OSD에 할당된 배치 그룹은 거의 볼 수 없습니다. 특정 배치 그룹의 복제본을 동작 설정으로 포함해야 하는 Ceph OSD 세트를 나타냅니다. 경우에 따라 활성 집합의 OSD가 다운되었거나 그렇지 않으면 배치 그룹의 개체에 대한 요청을 서비스할 수 없습니다. 이러한 상황이 발생하면 패닉을 일으키지 마십시오. 일반적인 예는 다음과 같습니다.

  • OSD를 추가 또는 제거했습니다. 그런 다음 CRUSH가 배치 그룹을 다른 Ceph OSD에 다시 할당하여 작동 중인 세트의 구성을 변경하고 "백필" 프로세스를 사용하여 데이터 마이그레이션을 생성합니다.
  • Ceph OSD가 다운 되어 이제 복구 중입니다.
  • 작업 세트의 Ceph OSD가 다운 되거나 서비스 요청을 할 수 없으며 다른 Ceph OSD에서 일시적으로 업무를 수행한다고 가정합니다.

Ceph에서는 요청을 실제로 처리하는 Ceph OSD 세트인 Up Set 을 사용하여 클라이언트 요청을 처리합니다. 대부분의 경우 up set 및 Acting Set은 사실상 동일합니다. Ceph가 데이터를 마이그레이션하는 경우 Ceph OSD가 복구 중이거나 문제가 있음을 나타낼 수 있습니다. 즉, Ceph는 일반적으로 이러한 시나리오에서 "더하기 오래된" 메시지와 함께 HEALTH WARN 상태를 에코합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 노드에 대한 루트 수준 액세스입니다.

절차

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

    예제

    [root@host01 ~]# cephadm shell

  2. 배치 그룹 목록을 검색하려면 다음을 수행합니다.

    예제

    [ceph: root@host01 /]# ceph pg dump

  3. 지정된 배치 그룹에 대해 동작 집합 또는 Up Set 에 있는 Ceph OSD를 확인합니다.

    구문

    ceph pg map PG_NUM

    예제

    [ceph: root@host01 /]# ceph pg map 128

    참고

    Up Set 및 Acting Set이 일치하지 않는 경우, 스토리지 클러스터의 자체 또는 스토리지 클러스터에 잠재적인 문제가 있음을 나타내는 표시일 수 있습니다.

3.3.3. Ceph OSD 피어링

배치 그룹에 데이터를 작성하려면 먼저 활성 상태여야 하며 클린 상태에 있어야 합니다. Ceph가 배치 그룹의 현재 상태, 즉 작동 세트의 첫 번째 OSD인 배치 그룹의 기본 OSD, 보조 OSD 및 tertiary OSD와의 피어를 확인하여 배치 그룹의 현재 상태에 대한 계약을 설정합니다. PG의 복제본이 세 개 있는 풀을 가정합니다.

그림 3.1. 피어링

피어링

3.3.4. 배치 그룹 상태

ceph 상태,ceph -s 또는 ceph -w 와 같은 명령을 실행하는 경우 클러스터가 항상 HEALTH OK 를 에코하는 것은 아닙니다. OSD가 실행 중인지 확인한 후 배치 그룹 상태도 확인해야 합니다. 클러스터가 여러 배치 그룹 피어링 관련 상황에서 HEALTH OK 를 echo 하지 않을 것으로 예상해야 합니다.

  • 아직 풀과 배치 그룹을 만들었지만 아직 피어링되지 않았습니다.
  • 배치 그룹은 복구됩니다.
  • 클러스터에서 OSD를 추가하거나 제거했습니다.
  • CRUSH 맵을 방금 수정했으며 배치 그룹이 마이그레이션되고 있습니다.
  • 배치 그룹의 다른 복제본에는 일치하지 않는 데이터가 있습니다.
  • Ceph에서 배치 그룹의 복제본을 스크럽합니다.
  • Ceph에는 백필 작업을 완료하기에 충분한 스토리지 용량이 없습니다.

계속되는 상황 중 하나가 Ceph에서 WARN을 에코 하게 되는 경우 패닉 상태가 발생하지 않습니다. 대부분의 경우 클러스터가 자체적으로 복구됩니다. 경우에 따라 조치를 취해야 할 수도 있습니다. 모니터링 배치 그룹의 중요한 측면은 클러스터가 가동 및 실행되고 모든 배치 그룹이 활성 상태이고 바람직하게는 정리 상태에 있는지 확인하는 것입니다.

모든 배치 그룹의 상태를 보려면 다음을 실행합니다.

예제

[ceph: root@host01 /]# ceph pg stat

그 결과 배치 그룹 맵 버전, vNNNNNN, 총 배치 그룹 수, x, y 의 수(예: active+clean )와 같은 특정 상태에 있는지 확인해야 합니다.

vNNNNNN: x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail
참고

Ceph에서 배치 그룹의 여러 상태를 보고하는 것이 일반적입니다.

스냅 샷 trimming PG States

스냅샷이 존재하는 경우 두 개의 추가 PG 상태가 보고됩니다.

  • snaptrim : 현재 PG가 트리밍 중입니다.
  • snaptrim_wait : PG는 트리밍 대기 중입니다.

출력 예:

244 active+clean+snaptrim_wait
 32 active+clean+snaptrim

Ceph는 배치 그룹 상태 외에도 사용되는 데이터 양, aa, 남아 있는 스토리지 용량, bb, 배치 그룹의 총 스토리지 용량도 에코합니다. 이 숫자는 몇 가지 경우에 중요할 수 있습니다.

  • 가까운 전체 비율 또는 전체 비율에 도달하고 있습니다.
  • CRUSH 구성의 오류로 인해 데이터가 클러스터에 배포되지 않습니다.

배치 그룹 ID

배치 그룹 ID는 풀 이름이 아닌 풀 번호, 그 뒤에 마침표(.) 및 배치 그룹 ID-​a 16진수로 구성됩니다. ceph osd lspools 출력에서 풀 번호와 해당 이름을 볼 수 있습니다. 기본 풀 이름은 데이터 이름,메타데이터rbd 는 각각 0,12 풀에 해당합니다. 정규화된 배치 그룹 ID의 형식은 다음과 같습니다.

구문

POOL_NUM.PG_ID

출력 예:

0.1f
  • 배치 그룹 목록을 검색하려면 다음을 수행합니다.

    예제

    [ceph: root@host01 /]# ceph pg dump

  • 출력을 JSON 형식으로 포맷하고 파일에 저장하려면 다음을 수행합니다.

    구문

    ceph pg dump -o FILE_NAME --format=json

    예제

    [ceph: root@host01 /]# ceph pg dump -o test --format=json

  • 특정 배치 그룹을 쿼리합니다.

    구문

    ceph pg POOL_NUM.PG_ID query

    예제

    [ceph: root@host01 /]#  ceph pg 5.fe query
    {
        "snap_trimq": "[]",
        "snap_trimq_len": 0,
        "state": "active+clean",
        "epoch": 2449,
        "up": [
            3,
            8,
            10
        ],
        "acting": [
            3,
            8,
            10
        ],
        "acting_recovery_backfill": [
            "3",
            "8",
            "10"
        ],
        "info": {
            "pgid": "5.ff",
            "last_update": "0'0",
            "last_complete": "0'0",
            "log_tail": "0'0",
            "last_user_version": 0,
            "last_backfill": "MAX",
            "purged_snaps": [],
            "history": {
                "epoch_created": 114,
                "epoch_pool_created": 82,
                "last_epoch_started": 2402,
                "last_interval_started": 2401,
                "last_epoch_clean": 2402,
                "last_interval_clean": 2401,
                "last_epoch_split": 114,
                "last_epoch_marked_full": 0,
                "same_up_since": 2401,
                "same_interval_since": 2401,
                "same_primary_since": 2086,
                "last_scrub": "0'0",
                "last_scrub_stamp": "2021-06-17T01:32:03.763988+0000",
                "last_deep_scrub": "0'0",
                "last_deep_scrub_stamp": "2021-06-17T01:32:03.763988+0000",
                "last_clean_scrub_stamp": "2021-06-17T01:32:03.763988+0000",
                "prior_readable_until_ub": 0
            },
            "stats": {
                "version": "0'0",
                "reported_seq": "2989",
                "reported_epoch": "2449",
                "state": "active+clean",
                "last_fresh": "2021-06-18T05:16:59.401080+0000",
                "last_change": "2021-06-17T01:32:03.764162+0000",
                "last_active": "2021-06-18T05:16:59.401080+0000",
    ....

추가 리소스

3.3.5. 배치 그룹 생성 상태

풀을 생성하면 지정한 배치 그룹 수가 생성됩니다. Ceph는 하나 이상의 배치 그룹을 생성할 때 생성을 에코합니다. 생성된 OSD는 배치 그룹의 acting Set에 속하는 OSD를 피어링합니다. 피어링이 완료되면 배치 그룹 상태가 active+clean 이어야 합니다. 즉, Ceph 클라이언트가 배치 그룹에 쓰기를 시작할 수 있습니다.

PG 생성

3.3.6. 배치 그룹 피어링 상태

Ceph가 배치 그룹을 피어링하는 경우 Ceph는 배치 그룹의 복제본을 배치 그룹의 오브젝트 및 메타데이터 의 상태에 대한 동의 로 저장하는 OSD를 가져옵니다. Ceph가 피어링을 완료하면 배치 그룹을 저장하는 OSD가 배치 그룹의 현재 상태에 대해 동의합니다. 그러나 피어링 프로세스 완료는 각 복제본에 최신 콘텐츠가 있음을 의미하는 것은 아닙니다.

신뢰할 수 있는 기록

Ceph는 대기 세트의 모든 OSD가 쓰기 작업이 될 때까지 클라이언트에 쓰기 작업을 인식하지 않습니다. 이 관행은 마지막으로 성공한 피어링 작업 이후 최소 하나의 동작 세트의 멤버가 모든 인식된 쓰기 작업의 레코드를 갖도록 보장합니다.

Ceph는 확인된 각 쓰기 작업의 정확한 레코드를 사용하여 배치 그룹의 새로운 권한 있는 기록을 구성하고 배포할 수 있습니다. 완료되면 OSD의 배치 그룹의 사본을 최신으로 가져오는 완료 및 완전히 정렬된 작업 집합입니다.

3.3.7. 배치 그룹 활성 상태

Ceph가 피어링 프로세스를 완료하면 배치 그룹이 활성화 될 수 있습니다. 활성 상태는 배치 그룹의 데이터를 일반적으로 기본 배치 그룹 및 읽기 및 쓰기 작업에 대한 복제본에서 사용할 수 있음을 의미합니다.

3.3.8. 배치 그룹 정리 상태

배치 그룹이 정리 상태에 있으면 기본 OSD와 복제본 OSD가 성공적으로 피어링되고 배치 그룹의 스프레이 복제본이 없습니다. Ceph는 배치의 모든 오브젝트를 올바른 횟수만큼 복제했습니다.

3.3.9. 배치 그룹 성능 저하 상태

클라이언트가 기본 OSD에 오브젝트를 쓸 때 기본 OSD는 복제본 OSD에 복제본을 작성합니다. 기본 OSD에서 오브젝트를 스토리지에 기록한 후 기본 OSD가 복제본 OSD에서 복제본 오브젝트를 성공적으로 생성할 때까지 배치 그룹은 성능이 저하된 상태로 유지됩니다.

배치 그룹이 active+degraded 될 수 있는 이유는 아직 모든 객체를 보유하지 않더라도 OSD를 활성화 할 수 있기 때문입니다. OSD가 다운 되면 Ceph는 OSD에 할당된 각 배치 그룹을 성능 저하 로 표시합니다. Ceph OSD가 다시 온라인 상태가 되면 Ceph OSD를 다시 피어링해야 합니다. 그러나 클라이언트는 활성 상태인 경우에도 성능이 저하된 배치 그룹에 새 개체를 쓸 수 있습니다.

OSD가 다운 되고 성능이 저하 된 상태가 지속되면 Ceph에서 다운 OSD를 클러스터 외부에서 표시하고 다운 OSD에서 데이터를 다른 OSD로 다시 매핑할 수 있습니다. 표시된 후 표시된 시간은 mon_osd_ down _ out _interval 에 의해 제어되며 기본적으로 600 초로 설정됩니다.

Ceph에서 배치 그룹에 있어야 한다고 생각하는 하나 이상의 오브젝트를 찾을 수 없기 때문에 배치 그룹도 성능이 저하 될 수 있습니다. unfound 개체를 읽거나 쓸 수는 없지만 성능이 저하된 배치 그룹의 다른 모든 오브젝트에 계속 액세스할 수 있습니다.

예를 들어 세 개의 복제본 풀에 9개의 OSD가 있는 경우 다음과 같습니다. OSD 번호 9가 다운되면 OSD 9에 할당된 PG가 성능 저하 상태가 됩니다. OSD 9가 복구되지 않으면 스토리지 클러스터와 스토리지 클러스터의 균형을 유지합니다. 이 시나리오에서 PG는 성능이 저하된 다음 활성 상태로 복구됩니다.

3.3.10. 상태 복구 배치 그룹

Ceph는 하드웨어 및 소프트웨어 문제가 지속적으로 발생하는 규모에 따라 내결함성을 위해 설계되었습니다. OSD가 다운 되면 해당 콘텐츠는 배치 그룹의 다른 복제본의 현재 상태 뒤에 있을 수 있습니다. OSD가 백업 되면 현재 상태를 반영하도록 배치 그룹의 콘텐츠를 업데이트해야 합니다. 이 기간 동안 OSD는 복구 상태를 반영할 수 있습니다.

하드웨어 장애로 인해 여러 Ceph OSD가 잘못될 수 있기 때문에 복구가 쉽지 않은 경우가 있습니다. 예를 들어 랙 또는 cache의 네트워크 스위치가 실패할 수 있으며 이로 인해 여러 호스트 시스템의 OSD가 스토리지 클러스터의 현재 상태 뒤에 떨어질 수 있습니다. 오류가 해결되면 OSD의 각 OSD를 복구해야 합니다.

Ceph는 새 서비스 요청 간의 리소스 경합과 배치 그룹을 복구하고 배치 그룹을 현재 상태로 복원하는 필요성 간의 리소스 경합을 균형을 유지하는 다양한 설정을 제공합니다. osd 복구 지연 시작 설정을 사용하면 OSD에서 복구 프로세스를 시작하기 전에 일부 재생 요청을 다시 시작, 재 피어링 및 처리할 수 있습니다. osd 복구 스레드 설정은 기본적으로 하나의 스레드로 복구 프로세스의 스레드 수를 제한합니다. osd 복구 스레드 시간 초과 는 여러 Ceph OSD가 실패할 수 있으므로 정지된 속도로 다시 시작 및 재피어할 수 있기 때문에 스레드 시간 초과를 설정합니다. osd 복구 max active 설정은 Ceph OSD가 동시에 작동하는 복구 요청 수를 제한하여 Ceph OSD가 서비스를 제공하지 못하도록 합니다. osd recovery max chunk 설정은 네트워크 혼잡을 방지하기 위해 복구된 데이터 청크의 크기를 제한합니다.

3.3.11. 백 채우기 상태

새 Ceph OSD가 스토리지 클러스터에 참여하면 CRUSH는 클러스터의 OSD에서 새로 추가된 Ceph OSD로 배치 그룹을 다시 할당합니다. 새 OSD가 다시 할당된 배치 그룹을 즉시 수락하도록 강제하면 새 Ceph OSD에 과도한 부하를 줄 수 있습니다. OSD를 배치 그룹으로 백필하면 이 프로세스가 백그라운드에서 시작될 수 있습니다. 백필링이 완료되면 새 OSD가 준비되면 새 OSD가 요청을 제공하기 시작합니다.

백필 작업 중에 여러 상태 중 하나가 표시될 수 있습니다.

  • backfill_wait 는 백필 작업이 보류 중이지만 아직 진행 중이 아님을 나타냅니다.
  • 백필( backfill )은 백필 작업이 진행 중임을 나타냅니다.
  • backfill_too_full 은 백필 작업이 요청되었지만 스토리지 용량이 부족하여 완료할 수 없음을 나타냅니다.

배치 그룹을 다시 채울 수 없는 경우 불완전한 것으로 간주될 수 있습니다.

Ceph는 Ceph OSD, 특히 새 Ceph OSD에 배치 그룹을 다시 할당하는 것과 관련된 부하 급증을 관리하는 다양한 설정을 제공합니다. 기본적으로 osd_max_backfills 는 최대 동시 백필 수를 Ceph OSD에서 10으로 설정합니다. OSD가 전체 비율에 도달하면 osd 백필 전체 비율을 사용하면 Ceph OSD에서 전체 비율에 도달하면 백필 요청을 거부할 수 있습니다. OSD에서 백필 요청을 거부하는 경우 osd backfill 재시도 간격을 사용하면 OSD에서 기본적으로 요청을 10초 후에 재시도할 수 있습니다. OSD는 osd backfill 검사 minosd backfill 검사 max 를 설정하여 기본적으로 64 및 512로 검사 간격을 관리할 수도 있습니다.

일부 워크로드의 경우 일반 복구를 완전히 방지하고 대신 백필을 사용하는 것이 좋습니다. 백그라운드에서 백필링되므로 I/O가 OSD의 개체를 계속 진행할 수 있습니다. osd_min_pg_log_entries 옵션을 1 로 설정하고 osd_max_pg_log_entries 옵션을 2 로 설정하여 복구 대신 백필을 강제 적용할 수 있습니다. 이러한 상황이 워크로드에 적합한 경우 Red Hat 지원 계정 팀에 문의하십시오.

3.3.12. 배치 그룹 다시 매핑된 상태

배치 그룹이 변경되는 서비스를 설정하면 데이터가 새로운 동작 세트로 설정된 이전 동작에서 마이그레이션됩니다. 새로운 기본 OSD가 서비스 요청에 시간이 걸릴 수 있습니다. 따라서 배치 그룹 마이그레이션이 완료될 때까지 이전 주에서 계속 요청을 서비스하도록 요청할 수 있습니다. 데이터 마이그레이션이 완료되면 매핑은 새 작동 세트의 기본 OSD를 사용합니다.

3.3.13. 배치 그룹 오래된 상태

Ceph는 하트비트를 사용하여 호스트 및 데몬이 실행 중인지 확인하는 동안 ceph-osd 데몬도 시기 적절하게 통계를 보고하지 않는 고정 상태가 될 수 있습니다. 예를 들어, 일시적인 네트워크 오류입니다. 기본적으로 OSD 데몬은 배치 그룹, up thru, boot 및 failure 통계를 반 초 단위로 보고합니다. 즉, 0.5 이며 이는 하트비트 임계값보다 더 자주 발생합니다. 배치 그룹의 기본 OSD 가 모니터에 보고되지 않거나 다른 OSD에서 기본 OSD 다운 을 보고한 경우 모니터에서 배치 그룹 stale 를 표시합니다.

스토리지 클러스터를 시작하면 피어 프로세스가 완료될 때까지 오래된 상태를 확인하는 것이 일반적입니다. 오래된 상태의 배치 그룹을 확인하여 스토리지 클러스터가 실행된 후 해당 배치 그룹의 기본 OSD가 다운되었거나 배치 그룹 통계를 모니터에 보고하지 않음을 나타냅니다.

3.3.14. 배치 그룹 잘못된 위치 상태

PG가 OSD에 일시적으로 매핑되는 몇 가지 임시 백필링 시나리오가 있습니다. 임시 상황이 더 이상 발생하지 않아야 하는 경우 PG는 여전히 임시 위치에 있고 적절한 위치에 있지 않을 수 있습니다. 이 경우, 그들은 잘못된 것으로 간주됩니다. 올바른 수의 추가 사본이 실제로 존재하지만 하나 이상의 복사본이 잘못된 위치에 있기 때문입니다.

예를 들어 OSD 0,1,2가 3개 있으며 모든 PG는 이러한 세 가지 변경 사항에 매핑됩니다. 다른 OSD(OSD 3)를 추가하면 일부 PG는 이제 다른 하나의 OSD 대신 OSD 3에 매핑됩니다. 그러나 OSD 3가 다시 입력될 때까지 PG는 이전 매핑에서 I/O를 계속 제공할 수 있는 임시 매핑을 제공합니다. 이 기간 동안 PG는 3개의 사본이 있기 때문에 임시 매핑이 있지만 성능 저하 가 없기 때문에 PG가 잘못 배치되어 있습니다.

예제

pg 1.5: up=acting: [0,1,2]
ADD_OSD_3
pg 1.5: up: [0,3,1] acting: [0,1,2]

[0,1,2]는 임시 매핑이므로 up 세트는 작동 세트와 같지 않으며 PG는 [0,1,2]이 여전히 세 복사본이므로 성능이 저하되지는 않습니다.

예제

pg 1.5: up=acting: [0,3,1]

이제 OSD 3이 백필되어 있으며 임시 매핑이 제거되고 성능이 저하되지 않고 잘못 배치되지 않습니다.

3.3.15. 배치 그룹 불완전한 상태

PG는 불완전 한 콘텐츠가 있고 피어링에 실패할 때 불완전한 상태가 됩니다. 즉, 현재 복구 수행에 충분한 완전한 OSD가 없는 경우입니다.

OSD 1, 2, 3은 OSD 1, 4, 3으로 전환하고 OSD 1, 4, 3으로 전환한 다음 osd.1 은 OSD 1, 2, 3의 임시 동작 세트를 요청한다는 것을 의미합니다. 이 기간 동안 OSD 1, 2, 3이 모두 아래로 내려지면 osd.4 가 모든 데이터를 완전히 다시 채우지 않았을 수 있는 유일한 왼쪽입니다. 현재 PG는 복구 수행에 충분한 완전한 OSD가 없음을 나타냅니다.

또는 osd.4 가 관련이 없고 작동 중인 세트가 OSD 1, 2 및 3인 경우, PG는 작동 세트가 변경된 이후 해당 PG에서 해당 PG에서 아무것도 듣지 않았음을 나타내는 오래된 것으로 나타났습니다. OSD가 새 OSD에 알 수 없는 이유는 다음과 같습니다.

3.3.16. 중단된 배치 그룹 확인

배치 그룹은 active+clean 상태가 아니기 때문에 반드시 문제가 되는 것은 아닙니다. 일반적으로 배치 그룹이 중단될 때 Ceph를 자체 복구할 수 있는 기능이 작동하지 않을 수 있습니다. 정지 상태에는 다음이 포함됩니다.

  • unclean: 배치 그룹에는 원하는 횟수를 복제하지 않은 오브젝트가 포함되어 있습니다. 그들은 회복되어야 합니다.
  • inactive: 배치 그룹은 최신 데이터가 있는 OSD가 백업 될 때까지 대기하고 있기 때문에 읽기 또는 쓰기를 처리할 수 없습니다.
  • stale : 배치 그룹은 호스트한 OSD가 잠시 동안 모니터 클러스터에 보고되지 않았으며 mon osd 보고서 시간 제한 설정으로 구성할 수 없기 때문에 알 수 없는 상태입니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 노드에 대한 루트 수준 액세스입니다.

절차

  1. 정지된 배치 그룹을 식별하려면 다음을 실행합니다.

    구문

    ceph pg dump_stuck {inactive|unclean|stale|undersized|degraded [inactive|unclean|stale|undersized|degraded...]} {<int>}

    예제

    [ceph: root@host01 /]# ceph pg dump_stuck stale
    OK

3.3.17. 개체의 위치 찾기

Ceph 클라이언트는 최신 클러스터 맵을 검색하고 CRUSH 알고리즘은 오브젝트를 배치 그룹에 매핑하는 방법을 계산한 다음 배치 그룹을 동적으로 할당하는 방법을 계산합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 노드에 대한 루트 수준 액세스입니다.

절차

  1. 오브젝트 위치를 찾으려면 오브젝트 이름과 풀 이름이 필요합니다.

    구문

    ceph osd map POOL_NAME OBJECT_NAME

    예제

    [ceph: root@host01 /]# ceph osd map mypool myobject

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.