검색

3.2. Ceph 스토리지 클러스터의 하위 수준 모니터링

download PDF

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

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

CRUSH가 Ceph OSD에 배치 그룹을 할당하면 풀의 복제본 수를 살펴보고 배치 그룹을 Ceph OSD에 할당하여 배치 그룹을 다른 Ceph OSD에 할당합니다. 예를 들어 풀에 배치 그룹의 세 개의 복제본이 필요한 경우 CRUSH에서 각각 osd.1,osd.2osd.3 에 할당할 수 있습니다. CRUSH는 실제로 CRUSH 맵에 설정한 장애 도메인을 고려하여 대규모 클러스터에서 가장 가까운 인접한 Ceph OSD에 할당된 배치 그룹이 거의 없습니다. Acting Set 로서 특정 배치 그룹의 복제본을 포함해야 하는 Ceph OSD 세트를 참조합니다. 경우에 따라 Acting Set의 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.2.2. Ceph OSD 피어링

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

그림 3.1. 피어링

피어링

3.2.3. 배치 그룹 상태

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

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

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

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

예제

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

결과는 배치 그룹 맵 버전, vNNNN, 총 배치 그룹 수, x 및 배치 그룹 yactive+clean 과 같은 특정 상태에 있음을 나타냅니다.

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

Ceph는 일반적으로 배치 그룹의 여러 상태를 보고합니다.

스냅샷 Trimming PG 상태

스냅샷이 있으면 두 개의 추가 PG 상태가 보고됩니다.

  • snaptrim : PG가 현재 트리밍되고 있습니다.
  • snaptrim_wait : PG가 트리밍되기를 기다리고 있습니다.

출력 예:

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

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

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

배치 그룹 ID

배치 그룹 ID는 풀 이름이 아닌 풀 번호와 마침표(.) 및 배치 그룹 ID-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.2.4. 배치 그룹 상태 생성

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

PG 생성

3.2.5. 배치 그룹 피어링 상태

Ceph가 배치 그룹을 피어링하는 경우 Ceph에서는 배치 그룹의 복제본을 저장하는 OSD 를 배치 그룹의 개체 및 메타데이터 상태에 대한 계약으로 가져옵니다. Ceph가 피어링을 완료하면 배치 그룹을 저장하는 OSD가 배치 그룹의 현재 상태에 대해 동의합니다. 그러나 피어링 프로세스가 완료되는 것은 각 복제본에 최신 콘텐츠가 있음을 의미하지는 않습니다.

권한 있는 내역

Ceph 는 작동 중인 세트의 모든 OSD가 쓰기 작업을 유지할 때까지 클라이언트에 대한 쓰기 작업을 인식하지 않습니다. 이 방법은 동작 세트의 적어도 한 멤버가 마지막 성공적인 피어링 작업 이후 승인된 모든 쓰기 작업에 대한 레코드를 갖도록 합니다.

Ceph에서 승인한 각 쓰기 작업에 대한 정확한 기록을 통해 Ceph는 배치 그룹의 새로운 권한 있는 기록을 구성하고 배포할 수 있습니다. 완료되면 OSD의 배치 그룹 복사본을 최신 상태로 가져오는 전체 정렬된 작업 세트가 수행됩니다.

3.2.6. 배치 그룹 활성 상태

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

3.2.7. 배치 그룹 정리 상태

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

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

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

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

OSD가 중단되고 성능이 저하된 상태가 지속되는 경우 Ceph는 다운 된 OSD를 클러스터 외부로 표시하고 다운 OSD의 데이터를 다른 OSD로 다시 매핑할 수 있습니다. down 및 marked out 사이의 시간은 mon_osd_down_out_interval 에 의해 제어되며, 이는 기본적으로 600 초로 설정됩니다.

Ceph가 배치 그룹에 있다고 생각하는 하나 이상의 오브젝트를 찾을 수 없으므로 배치 그룹은 성능이 저하 될 수도 있습니다. unfound 오브젝트를 읽거나 쓸 수는 없지만 성능이 저하된 배치 그룹의 다른 모든 오브젝트에 계속 액세스할 수 있습니다.

예를 들어, 9개의 OSD가 있는 경우 세 가지 방법으로 복제본 풀입니다. OSD 번호 9가 다운되면 OSD 9에 할당된 PG가 degraded 상태가 됩니다. OSD 9가 복구되지 않으면 스토리지 클러스터와 스토리지 클러스터가 재조정됩니다. 이 시나리오에서는 PG가 성능이 저하된 다음 활성 상태로 복구됩니다.

3.2.9. 배치 그룹 상태 복구

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

하드웨어 장애로 인해 여러 Ceph OSD의 계단식 장애가 발생할 수 있으므로 복구가 항상 간단한 것은 아닙니다. 예를 들어 랙 또는 장에 대한 네트워크 스위치가 실패할 수 있으므로 여러 호스트 머신의 OSD가 스토리지 클러스터의 현재 상태가 대체될 수 있습니다. 오류가 해결되면 각 OSD를 복구해야 합니다.

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

3.2.10. 뒤로 채우기 상태

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

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

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

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

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

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

3.2.11. 배치 그룹 재맵됨 상태

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

3.2.12. 배치 그룹 오래된 상태

Ceph는 하트비트를 사용하여 호스트와 데몬이 실행 중인지 확인하지만 ceph-osd 데몬은 적절한 방식으로 통계를 보고하지 않는 정지 상태에 도달할 수도 있습니다. 예를 들어 일시적인 네트워크 오류입니다. 기본적으로 OSD 데몬은 하트비트 임계값보다 더 자주 0.5 인 배치 그룹( thru, boot 및 failure 통계)을 보고합니다. 배치 그룹의 동작 세트의 기본 OSD 가 모니터에 보고되지 않거나 다른 OSD가 기본 OSD 다운을 보고한 경우 모니터는 배치 그룹이 오래된 배치 그룹을 표시합니다.

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

3.2.13. 배치 그룹이 잘못 배치됨

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

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

예제

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]는 여전히 3 개의 사본이므로 성능이 저하 되지 않습니다.

예제

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

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

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

PG는 불완전한 콘텐츠와 피어링이 실패할 때, 즉 복구 수행에 충분한 완전한 OSD가 없을 때 불완전한 상태가 됩니다.

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

또는 osd.4 가 관련이 없고 작동 세트가 OSD 1, 2, 3이 중단될 때 간단히 OSD 1, 2, 3인 경우, PG는 동작 세트가 변경되었기 때문에 mons가 해당 PG에서 들어가지 않았음을 나타냅니다. 새 OSD에 알릴 OSD가 남아 있지 않은 이유입니다.

3.2.15. 정지된 배치 그룹 확인

배치 그룹은 active+clean 상태가 아니기 때문에 반드시 문제가 되지는 않습니다. 일반적으로 배치 그룹이 중단되면 Ceph의 자체 복구 기능이 작동하지 않을 수 있습니다. 중단된 상태는 다음과 같습니다.

  • Unclean: 배치 그룹에는 원하는 횟수만큼 복제되지 않는 오브젝트가 포함됩니다. 복구해야 합니다.
  • 비활성: 배치 그룹은 최신 데이터가 있는 OSD가 백업될 때까지 대기 중이거나 쓰기를 처리할 수 없습니다.
  • Old: 호스트하는 OSD가 잠시 동안 모니터 클러스터에 보고되지 않았으며 mon osd report timeout 설정을 사용하여 구성할 수 있으므로 배치 그룹은 알 수 없는 상태입니다.

사전 요구 사항

  • 실행 중인 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.2.16. 오브젝트의 위치 찾기

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

사전 요구 사항

  • 실행 중인 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.