스토리지 전략 가이드

Ceph 클라이언트 및 Ceph OSD는 모두 CRUSH 맵과 CRUSH 알고리즘을 사용합니다.

여러 오브젝트 복제본 또는 M 삭제 코딩 청크가 있으면 데이터 손실을 방지할 수 있지만 고가용성을 해결하기에는 충분하지 않습니다. CRUSH는 Ceph Storage 클러스터의 기본 물리적 조직을 반영하여 관련 장치 장애의 잠재적 소스를 모델링할 수 있습니다. 클러스터의 토폴로지를 클러스터 맵에 인코딩하여 CRUSH 배치 정책은 원하는 의사 무작위 배포를 유지 관리하면서 다른 장애 도메인에서 오브젝트 복제본 또는 삭제 코딩 청크를 분리할 수 있습니다. 예를 들어 동시 오류 가능성을 해결하기 위해 데이터 복제본 또는 삭제 코딩 청크가 서로 다른 보류, 랙, 전원 공급 장치, 컨트롤러 또는 물리적 위치를 사용하는 장치에 있는지 확인하는 것이 바람직할 수 있습니다. 이렇게 하면 데이터 손실을 방지하고 클러스터가 성능 저하된 상태로 작동할 수 있습니다.

Ceph는 여러 계층을 지원하여 한 가지 유형의 하드웨어 성능 프로필을 다른 유형의 하드웨어 성능 프로파일과 분리할 수 있습니다. 예를 들어 CRUSH는 하드 디스크 드라이브에 대해 하나의 계층 구조와 SSD의 다른 계층 구조를 생성할 수 있습니다. 성능 도메인 - 기본 하드웨어의 성능 프로파일을 고려한 계층 구조에서는 다양한 성능 특성을 지원해야 하므로 점점 더 인기가 있습니다. 운영적으로는 root 유형 버킷이 두 개 이상인 CRUSH 맵일 뿐입니다. 사용 사례 예는 다음과 같습니다.

CRUSH 맵은 장치 클래스의 개념을 지원합니다. Ceph는 스토리지 장치의 측면을 검색하고 hdd,ssd 또는 nvme 와 같은 클래스를 자동으로 할당할 수 있습니다. 그러나 CRUSH는 이러한 기본값으로 제한되지 않습니다. 예를 들어 CRUSH 계층 구조를 사용하여 다양한 유형의 워크로드를 분리할 수도 있습니다. 예를 들어, SSD는 저널 또는 쓰기 로그, 버킷 인덱스 또는 원시 오브젝트 스토리지에 사용할 수 있습니다. CRUSH는 ssd-bucket-index 또는 ssd-object-storage 와 같은 다양한 장치 클래스를 지원할 수 있으므로 Ceph는 다른 워크로드에 동일한 스토리지 미디어를 사용하지 않으므로 성능을 예측 가능하고 일관되게 만들 수 있습니다.

백그라운드에서 Ceph는 각 장치 클래스에 대한 CRUSH 루트를 생성합니다. 이러한 루트는 OSD에서 장치 클래스를 설정하거나 변경하는 경우에만 수정해야 합니다. 다음 명령을 사용하여 생성된 루트를 볼 수 있습니다.

[ceph: root@host01 /]# ceph osd crush tree --show-shadow
ID   CLASS  WEIGHT    TYPE NAME
-24    ssd   4.54849  root default~ssd
-19    ssd   0.90970      host ceph01~ssd
  8    ssd   0.90970          osd.8
-20    ssd   0.90970      host ceph02~ssd
  7    ssd   0.90970          osd.7
-21    ssd   0.90970      host ceph03~ssd
  3    ssd   0.90970          osd.3
-22    ssd   0.90970      host ceph04~ssd
  5    ssd   0.90970          osd.5
-23    ssd   0.90970      host ceph05~ssd
  6    ssd   0.90970          osd.6
 -2    hdd  50.94173  root default~hdd
 -4    hdd   7.27739      host ceph01~hdd
 10    hdd   7.27739          osd.10
-12    hdd  14.55478      host ceph02~hdd
  0    hdd   7.27739          osd.0
 12    hdd   7.27739          osd.12
 -6    hdd  14.55478      host ceph03~hdd
  4    hdd   7.27739          osd.4
 11    hdd   7.27739          osd.11
-10    hdd   7.27739      host ceph04~hdd
  1    hdd   7.27739          osd.1
 -8    hdd   7.27739      host ceph05~hdd
  2    hdd   7.27739          osd.2
 -1         55.49022  root default
 -3          8.18709      host ceph01
 10    hdd   7.27739          osd.10
  8    ssd   0.90970          osd.8
-11         15.46448      host ceph02
  0    hdd   7.27739          osd.0
 12    hdd   7.27739          osd.12
  7    ssd   0.90970          osd.7
 -5         15.46448      host ceph03
  4    hdd   7.27739          osd.4
 11    hdd   7.27739          osd.11
  3    ssd   0.90970          osd.3
 -9          8.18709      host ceph04
  1    hdd   7.27739          osd.1
  5    ssd   0.90970          osd.5
 -7          8.18709      host ceph05
  2    hdd   7.27739          osd.2
  6    ssd   0.90970          osd.6

CRUSH 위치는 CRUSH 맵의 계층 구조 측면에서 OSD의 위치입니다. 명령줄 인터페이스에서 CRUSH 위치를 표현하면 CRUSH 위치 지정자는 OSD의 위치를 설명하는 이름/값 쌍 목록의 형태를 취합니다. 예를 들어 OSD가 특정 행, rack, 섀시 및 호스트에 있고 기본 CRUSH 트리의 일부인 경우 CRUSH 위치는 다음과 같이 설명될 수 있습니다.

root=default row=a rack=a2 chassis=a2a host=a2a1

참고:

CRUSH 계층 구조에 버킷 인스턴스를 추가하려면 버킷 이름과 해당 유형을 지정합니다. 버킷 이름은 CRUSH 맵에서 고유해야 합니다.

ceph osd crush add-bucket {name} {type}

예를 들어 다른 하드웨어 성능 프로필의 경우 여러 계층 구조를 사용하려는 경우 하드웨어 유형 또는 사용 사례에 따라 버킷 이름을 지정하는 것이 좋습니다.

예를 들어 솔리드 스테이트 드라이브(sd)를 위한 계층 구조, SSD 저널이 있는 SAS 디스크의 계층 구조(hdd-journal) 및 SATA 드라이브의 다른 계층 구조(hdd)를 생성할 수 있습니다.

ceph osd crush add-bucket ssd-root root
ceph osd crush add-bucket hdd-journal-root root
ceph osd crush add-bucket hdd-root root

Ceph CLI 출력:

added bucket ssd-root type root to crush map
added bucket hdd-journal-root type root to crush map
added bucket hdd-root type root to crush map

계층 구조에 필요한 각 버킷 유형의 인스턴스를 추가합니다. 다음 예제에서는 SSD 호스트 랙이 있는 행에 대한 버킷과 오브젝트 스토리지의 호스트 랙을 추가하는 방법을 보여줍니다.

ceph osd crush add-bucket ssd-row1 row
ceph osd crush add-bucket ssd-row1-rack1 rack
ceph osd crush add-bucket ssd-row1-rack1-host1 host
ceph osd crush add-bucket ssd-row1-rack1-host2 host
ceph osd crush add-bucket hdd-row1 row
ceph osd crush add-bucket hdd-row1-rack2 rack
ceph osd crush add-bucket hdd-row1-rack1-host1 host
ceph osd crush add-bucket hdd-row1-rack1-host2 host
ceph osd crush add-bucket hdd-row1-rack1-host3 host
ceph osd crush add-bucket hdd-row1-rack1-host4 host

이러한 단계를 완료하면 트리를 확인하십시오.

ceph osd tree

계층 구조는 그대로 유지됩니다. CRUSH 맵에 버킷을 추가한 후 계층 구조 위치로 이동해야 합니다.

초기 클러스터를 생성할 때 Ceph에는 default 라는 루트 버킷이 있는 기본 CRUSH 맵이 있고 초기 OSD 호스트가 기본 버킷에 표시됩니다. CRUSH 맵에 버킷 인스턴스를 추가하면 CRUSH 계층에 표시되지만 특정 버킷에 표시되지는 않습니다.

버킷 인스턴스를 CRUSH 계층 구조의 특정 위치로 이동하려면 버킷 이름과 해당 유형을 지정합니다. 예를 들면 다음과 같습니다.

ceph osd crush move ssd-row1 root=ssd-root
ceph osd crush move ssd-row1-rack1 row=ssd-row1
ceph osd crush move ssd-row1-rack1-host1 rack=ssd-row1-rack1
ceph osd crush move ssd-row1-rack1-host2 rack=ssd-row1-rack1

이러한 단계를 완료하면 트리를 볼 수 있습니다.

ceph osd tree

CRUSH 계층에서 버킷 인스턴스를 제거하려면 버킷 이름을 지정합니다. 예를 들면 다음과 같습니다.

ceph osd crush remove {bucket-name}

또는 다음을 수행합니다.

ceph osd crush rm {bucket-name}

상위 수준 버킷(예: 기본과 같은 루트)을 제거하는 경우 풀이 해당 버킷을 선택하는 CRUSH 규칙을 사용하는지 확인합니다. 이 경우 CRUSH 규칙을 수정해야 합니다. 그러지 않으면 피어링이 실패합니다.

Ceph CLI를 사용하여 버킷을 생성할 때 Ceph는 기본적으로 알고리즘을 straw2 로 설정합니다. Ceph는 각각 성능과 재구성 효율성 간의 절충을 나타내는 네 가지 버킷 알고리즘을 지원합니다. 어떤 버킷 유형을 사용할지 확실하지 않은 경우 straw2 버킷을 사용하는 것이 좋습니다. 버킷 알고리즘은 다음과 같습니다.

ceph osd crush tree 명령은 트리 뷰에서 CRUSH 버킷 및 항목을 출력합니다. 이 명령을 사용하여 특정 버킷의 OSD 목록을 확인합니다. ceph osd 트리 와 유사한 출력을 출력합니다.

추가 세부 정보를 반환하려면 다음을 실행합니다.

# ceph osd crush tree -f json-pretty

이 명령은 다음과 유사한 출력을 반환합니다.

[
    {
        "id": -2,
        "name": "ssd",
        "type": "root",
        "type_id": 10,
        "items": [
            {
                "id": -6,
                "name": "dell-per630-11-ssd",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 6,
                        "name": "osd.6",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.099991,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -7,
                "name": "dell-per630-12-ssd",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 7,
                        "name": "osd.7",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.099991,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -8,
                "name": "dell-per630-13-ssd",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 8,
                        "name": "osd.8",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.099991,
                        "depth": 2
                    }
                ]
            }
        ]
    },
    {
        "id": -1,
        "name": "default",
        "type": "root",
        "type_id": 10,
        "items": [
            {
                "id": -3,
                "name": "dell-per630-11",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 0,
                        "name": "osd.0",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.449997,
                        "depth": 2
                    },
                    {
                        "id": 3,
                        "name": "osd.3",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.289993,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -4,
                "name": "dell-per630-12",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 1,
                        "name": "osd.1",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.449997,
                        "depth": 2
                    },
                    {
                        "id": 4,
                        "name": "osd.4",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.289993,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -5,
                "name": "dell-per630-13",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 2,
                        "name": "osd.2",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.449997,
                        "depth": 2
                    },
                    {
                        "id": 5,
                        "name": "osd.5",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.289993,
                        "depth": 2
                    }
                ]
            }
        ]
    }
]

CRUSH 계층 구조에 Ceph OSD를 추가하는 것은 OSD를 시작하기 전에 최종 단계이며 Ceph는 OSD 에배치 그룹을 할당합니다.

CRUSH 계층에 추가하기 전에 Ceph OSD를 준비해야 합니다. Ceph Orchestrator와 같은 배포 유틸리티는 이 단계를 수행할 수 있습니다. 예를 들어 단일 노드에 Ceph OSD를 생성합니다.

ceph orch daemon add osd HOST:_DEVICE_,[DEVICE]

CRUSH 계층 구조는 표기법이므로 ceph osd crush add 명령을 사용하면 원하는 곳에 CRUSH 계층 구조에 OSD를 추가할 수 있습니다. 지정한 위치는 실제 위치를 반영해야 합니다. 하나 이상의 버킷을 지정하면 명령에서 지정된 가장 구체적인 버킷에 OSD를 배치하고 지정한 다른 버킷 아래에 해당 버킷을 이동합니다.

CRUSH 계층 구조에 OSD를 추가하려면 다음을 수행합니다.

ceph osd crush add ID_OR_NAME WEIGHT [BUCKET_TYPE=BUCKET_NAME ...]

다음 예제에서는 osd.0 을 계층 구조에 추가합니다.

ceph osd crush add osd.0 1.0 root=default datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

스토리지 클러스터 토폴로지가 변경되면 CRUSH 계층 구조에서 OSD를 이동하여 실제 위치를 반영할 수 있습니다.

CRUSH 계층 구조 내에서 OSD를 이동하려면 다음을 수행합니다.

ceph osd crush set ID_OR_NAME WEIGHT root=POOL_NAME  [BUCKET_TYPE=BUCKET_NAME...]

CRUSH 계층 구조에서 OSD를 제거하는 것은 클러스터에서 OSD를 제거하려는 첫 번째 단계입니다. CRUSH 맵에서 OSD를 제거하면 CRUSH에서 배치 그룹과 데이터를 적절하게 재조정하는 OSD를 다시 계산합니다. 자세한 내용은 OSD 추가/제거를 참조하십시오.

실행 중인 클러스터의 CRUSH 맵에서 OSD를 제거하려면 다음을 실행합니다.

ceph osd crush remove NAME

OSD의 장치 클래스를 설정하려면 다음을 실행합니다.

ceph osd crush set-device-class  CLASS OSD_ID [OSD_ID..]

[ceph: root@host01 /]# ceph osd crush set-device-class hdd osd.0 osd.1
[ceph: root@host01 /]# ceph osd crush set-device-class ssd osd.2 osd.3
[ceph: root@host01 /]# ceph osd crush set-device-class bucket-index osd.4

OSD의 장치 클래스를 제거하려면 다음을 실행합니다.

ceph osd crush rm-device-class CLASS OSD_ID [OSD_ID..]

[ceph: root@host01 /]# ceph osd crush rm-device-class hdd osd.0 osd.1
[ceph: root@host01 /]# ceph osd crush rm-device-class ssd osd.2 osd.3
[ceph: root@host01 /]# ceph osd crush rm-device-class bucket-index osd.4

해당 클래스를 사용하는 모든 OSD의 장치 클래스 이름을 변경하려면 다음을 실행합니다.

ceph osd crush class rename OLD_NAME NEW_NAME

[ceph: root@host01 /]# ceph osd crush class rename hdd sas15k

CRUSH 맵의 장치 클래스를 나열하려면 다음을 실행합니다.

ceph osd crush class ls

출력은 다음과 같습니다.

[
    "hdd",
    "ssd",
    "bucket-index"
]

특정 클래스에 속하는 모든 OSD를 나열하려면 다음을 실행합니다.

ceph osd crush class ls-osd CLASS

[ceph: root@host01 /]# ceph osd crush class ls-osd hdd

출력은 OSD 번호 목록일 뿐입니다. 예를 들면 다음과 같습니다.

0
1
2
3
4
5
6

동일한 클래스를 참조하는 모든 CRUSH 규칙을 나열하려면 다음을 실행합니다.

ceph osd crush rule ls-by-class CLASS

[ceph: root@host01 /]# ceph osd crush rule ls-by-class hdd

CRUSH 맵 내에서 OSD CRUSH 가중치를 Terabytes로 설정하려면 다음 명령을 실행합니다.

ceph osd crush reweight _NAME_ _WEIGHT_

다음과 같습니다.

이 설정은 OSD를 생성하거나 OSD를 추가한 직후 CRUSH 가중치를 조정할 때 사용됩니다. 일반적으로 OSD 수명 동안 변경되지 않습니다.

ceph osd crush reweight 을 사용하는 것은 시간이 많이 소요될 수 있습니다. 다음을 실행하여 버킷(행, 랙, 노드 등)에서 모든 Ceph OSD 가중치를 설정(또는 재설정)할 수 있습니다.

osd crush reweight-subtree NAME

여기서,

name 은 CRUSH 버킷의 이름입니다.

ceph osd in 및 ceph osd out 의 목적을 위해 OSD는 클러스터에 있거나 클러스터 외부에 있습니다. 이렇게 하면 모니터가 OSD 상태를 기록합니다. 그러나 OSD가 클러스터에 있지만 수정하기 전까지 (예: 스토리지 드라이브 교체, 컨트롤러 변경 등)에 의존하지 않도록 오작동이 발생할 수 있습니다.

다음을 실행하여 특정 OSD의 가중치를 늘리거나 줄일 수 있습니다(즉, Terabytes의 가중치를 변경하지 않고).

ceph osd reweight ID WEIGHT

다음과 같습니다.

CRUSH는 새 데이터 오브젝트 PG 및 PG를 OSD에 할당하는 쓰기 요청에 대한 균일한 확률 분배를 위해 설계되었습니다. 그러나 클러스터가 어쨌든 불균형이 될 수 있습니다. 이는 여러 가지 이유로 발생할 수 있습니다. 예를 들면 다음과 같습니다.

다음을 실행하여 사용률을 통해 OSD를 다시 지정할 수 있습니다.

ceph osd reweight-by-utilization [THRESHOLD_] [WEIGHT_CHANGE_AMOUNT] [NUMBER_OF_OSDS] [--no-increasing]

[ceph: root@host01 /]# ceph osd test-reweight-by-utilization 110 .5 4 --no-increasing

다음과 같습니다.

가중치를 할당하는 이 또는 기타 가중치 명령을 실행하면 이 명령에 의해 할당된 가중치(예: osd reweight-by-utilization,osd crush weight,osd weight,in 또는 out)가 재정의됩니다.

OSD 수가 적은 CRUSH 계층 구조에서는 일부 OSD에서 다른 OSD보다 더 많은 PG를 얻을 수 있으므로 로드가 증가할 수 있습니다. 다음을 실행하여 PG 배포를 통해 OSD를 재중량하여 이러한 상황을 해결할 수 있습니다.

osd reweight-by-pg POOL_NAME

다음과 같습니다.

CRUSH 트리 버킷은 리프 가중치의 합계여야 합니다. CRUSH 맵 가중치를 수동으로 편집하는 경우 다음을 실행하여 CRUSH 버킷 트리가 버킷 아래의 리프 OSD의 합계를 정확하게 반영하도록 해야 합니다.

osd crush reweight-all

명령줄에서 CRUSH 규칙을 나열하려면 다음을 실행합니다.

ceph osd crush rule list
ceph osd crush rule ls

특정 CRUSH 규칙의 내용을 덤프하려면 다음을 실행합니다.

ceph osd crush rule dump NAME

CRUSH 규칙을 추가하려면 규칙 이름, 사용할 계층의 루트 노드, 복제할 버킷 유형(예: 'rack', 'row' 등) 및 버킷 선택을 위한 모드를 지정해야 합니다.

ceph osd crush rule create-simple RUENAME ROOT BUCKET_NAME FIRSTN_OR_INDEP

Ceph는 chooseleaf 를 사용하여 규칙을 만들고 지정한 유형의 버킷을 1개 만듭니다.

[ceph: root@host01 /]# ceph osd crush rule create-simple deleteme default host firstn

다음 규칙을 생성합니다.

{ "id": 1,
  "rule_name": "deleteme",
  "type": 1,
  "min_size": 1,
  "max_size": 10,
  "steps": [
        { "op": "take",
          "item": -1,
          "item_name": "default"},
        { "op": "chooseleaf_firstn",
          "num": 0,
          "type": "host"},
        { "op": "emit"}]}

복제된 풀에 대한 CRUSH 규칙을 생성하려면 다음을 실행합니다.

ceph osd crush rule create-replicated NAME ROOT FAILURE_DOMAIN CLASS

다음과 같습니다.

[ceph: root@host01 /]# ceph osd crush rule create-replicated fast default host ssd

삭제 코딩 풀과 함께 사용할 CRUSH 규칙을 추가하려면 규칙 이름과 삭제 코드 프로필을 지정할 수 있습니다.

ceph osd crush rule create-erasure RULE_NAME PROFILE_NAME

[ceph: root@host01 /]# ceph osd crush rule create-erasure default default

규칙을 제거하려면 다음을 실행하고 CRUSH 규칙 이름을 지정합니다.

ceph osd crush rule rm NAME

CRUSH를 조정하기 전에 모든 Ceph 클라이언트와 모든 Ceph 데몬이 동일한 버전을 사용하는지 확인해야 합니다. 최근에 업그레이드한 경우 데몬을 다시 시작하고 클라이언트를 다시 연결했는지 확인합니다.

CRUSH 튜닝 가능 항목을 조정하는 가장 간단한 방법은 알려진 프로필로 변경하는 것입니다. 다음은 다음과 같습니다.

명령을 사용하여 실행 중인 클러스터에서 프로필을 선택할 수 있습니다.

# ceph osd crush tunables PROFILE

일반적으로 업그레이드 후 CRUSH 튜닝 가능 항목을 설정하거나 경고가 표시되는 경우 설정해야 합니다. 버전 v0.74부터 CRUSH 튜닝 가능 항목이 최적 값으로 설정되지 않으면 Ceph에서 상태 경고를 발행합니다. v0.73의 경우 최적 값이 기본값입니다.

기존 클러스터에서 튜닝 가능 항목을 조정하여 경고를 제거할 수 있습니다. 이로 인해 일부 데이터 이동(예: 10% 정도)이 발생합니다. 이는 기본 경로이지만 데이터 이동이 성능에 영향을 줄 수 있는 프로덕션 클러스터를 관리해야 합니다. 다음을 사용하여 최적의 튜닝 가능 항목을 활성화할 수 있습니다.

ceph osd crush tunables optimal

상황이 좋지 않고(예: 너무 많은 로드) 진행되지 않았거나 클라이언트 호환성 문제(이전 커널 cephfs 또는 rbd 클라이언트 또는 pre-bobtail librados 클라이언트)가 있는 경우 이전 프로필로 다시 전환할 수 있습니다.

ceph osd crush tunables PROFILE

예를 들어 사전 v0.48(Argonaut) 값을 복원하려면 다음을 실행합니다.

[ceph: root@host01 /]# ceph osd crush tunables legacy

모든 클라이언트가 최신 코드를 실행 중인지 확인할 수 있는 경우 CRUSH 맵을 추출하고 값을 수정한 후 클러스터에 다시 삽입하여 튜닝 가능 항목을 조정할 수 있습니다.

참조의 경우 CRUSH 튜닝 가능 항목의 레거시 값은 다음을 사용하여 설정할 수 있습니다.

crushtool -i /tmp/crush --set-choose-local-tries 2 --set-choose-local-fallback-tries 5 --set-choose-total-tries 19 --set-chooseleaf-descend-once 0 --set-chooseleaf-vary-r 0 -o /tmp/crush.legacy

또한 특수 --enable-unsafe-tunables 옵션이 필요합니다. 또한, 위에서 언급했듯이 기능 비트가 완전히 적용되지 않으므로 기존 값으로 되돌리는 후 이전 버전의 ceph-osd 데몬을 계속 실행하십시오.

클러스터의 CRUSH 맵을 가져오려면 다음을 실행합니다.

ceph osd getcrushmap -o COMPILED_CRUSHMAP_FILENAME

Ceph는 컴파일된 CRUSH 맵을 지정한 파일 이름에 출력(-o)합니다. CRUSH 맵은 컴파일된 양식이므로 편집하기 전에 먼저 컴파일해야 합니다.

CRUSH 맵을 컴파일하려면 다음을 실행합니다.

crushtool -d COMPILED_CRUSHMAP_FILENAME -o DECOMPILED_CRUSHMAP_FILENAME

Ceph는 컴파일된 CRUSH 맵을 컴파일하고 출력(-o)을 지정한 파일 이름으로 전송합니다.

클러스터에 CRUSH 맵을 설정하려면 다음을 실행합니다.

ceph osd setcrushmap -i COMPILED_CRUSHMAP_FILENAME

Ceph는 클러스터의 CRUSH 맵으로 지정한 파일 이름의 컴파일된 CRUSH 맵을 입력합니다.

CRUSH 맵을 컴파일하려면 다음을 실행합니다.

crushtool -c DECOMPILED_CRUSHMAP_FILENAME -o COMPILED_CRUSHMAP_FILENAME

Ceph는 컴파일된 CRUSH 맵을 지정한 파일 이름에 저장합니다.

Ceph는 영구적으로 데이터 손실을 방지하기 위해 노력합니다. 그러나 OSD가 실패하면 데이터가 완전히 복구될 때까지 영구 데이터 손실 위험이 증가합니다. 영구 데이터 손실은 드물지만 여전히 가능합니다. 다음 시나리오에서는 Ceph가 다음 세 개의 데이터 사본으로 단일 배치 그룹에서 데이터를 영구적으로 손실하는 방법을 설명합니다.

하드웨어 오류는 예외가 아니라 예상입니다. 앞서 언급한 시나리오를 방지하려면 이상적으로 복구 프로세스가 합리적으로 가능한 한 빨리 처리되어야 합니다. 클러스터 크기, 하드웨어 구성 및 배치 그룹 수가 총 복구 시간에 중요한 역할을 합니다.

Ceph는 나머지 9개의 OSD에 무작위로 남아 있는 150개의 배치 그룹을 저장할 수 있습니다. 따라서 나머지 OSD는 다른 모든 OSD에 오브젝트 복사본을 전송하고 새 오브젝트도 수신할 수 있습니다. 나머지 OSD는 현재 할당된 150개의 배치 그룹 중 일부를 담당합니다.

총 복구 시간은 풀을 지원하는 하드웨어에 따라 다릅니다. 예를 들어 10개의 OSD 클러스터에서 호스트에 1TB SSD가 있는 OSD가 1개 있고 10GB/s 스위치가 각각 10개의 호스트를 연결하는 경우 복구 시간은 M 분입니다. 반대로 호스트에 두 개의 SATA OSD가 포함되어 있고 1GB/s 스위치가 5개의 호스트를 연결하는 경우 복구 시간이 크게 더 오래 걸립니다. 이 크기의 클러스터에서는 배치 그룹 수가 데이터 지속성에 거의 영향을 미치지 않습니다. 배치 그룹 수는 128 또는 8192일 수 있으며 복구 속도가 느리거나 빠르지 않습니다.

그러나 동일한 Ceph 클러스터를 10개의 OSD 대신 20개의 OSD로 늘리면 복구 속도를 높이고 데이터 지속성을 크게 향상시킬 수 있습니다. 이유가 무엇입니까? 각 OSD는 이제 150개가 아닌 75개의 배치 그룹에만 참여하고 있습니다. 20개의 OSD 클러스터에는 복구하기 위해 동일한 양의 복사 작업을 수행하려면 나머지 19개의 OSD 모두 필요합니다. 10개의 OSD 클러스터에서 각 OSD는 약 100GB를 복사해야 했습니다. 20개의 OSD 클러스터에서 각 OSD는 각각 50GB만 복사해야 합니다. 네트워크가 병목인 경우 복구 속도가 두 배 빠르게 수행됩니다. 즉, OSD 수가 증가함에 따라 복구 시간이 줄어듭니다.

위에서 설명한 10 개의 OSD 클러스터에서 OSD가 실패하면 약 8 개의 배치 그룹 (즉 75 pgs / 9 osds 가 복구되는)은 하나의 남아 있는 사본 만 가질 수 있습니다. 8개의 나머지 OSD 중 하나라도 실패하면 하나의 배치 그룹의 마지막 개체가 손실될 가능성이 높습니다(즉, 하나의 남은 사본만 복구되는 8 pgs / 8 osds ). 따라서 다소 큰 클러스터부터 시작하는 것이 좋습니다(예: 50개의 OSD).

클러스터 크기가 20개의 OSD로 증가하면 3개의 OSD가 손실되어 배치 그룹 수가 삭제됩니다. 두 번째 OSD 손실은 8 대신 약 2 개의 (즉 35 pgs / 19 osds )의 성능이 저하되고 세 번째 OSD는 보존 복사본을 포함하는 두 개의 OSD 중 하나 인 경우에만 데이터가 손실됩니다. 즉, 복구 기간 동안 하나의 OSD를 손실할 가능성이 0.0001% 인 경우 클러스터의 8 * 0.0001% 가 10 개의 OSD가 있는 클러스터의 0.0001%에서 20 OSD가 있는 클러스터의 0.0001% 로 이동합니다. 512 또는 4096개의 배치 그룹을 갖는 것은 데이터 지속성과 관련된 한 50개의 OSD가 있는 클러스터에서 거의 동일합니다.

클러스터에 OSD를 추가할 때 새 OSD를 배치 그룹 및 오브젝트로 채우는 데 시간이 오래 걸릴 수 있습니다. 그러나 오브젝트의 저하는 없으며 OSD를 추가하면 데이터 지속성에 영향을 미치지 않습니다.

Ceph는 핫 스팟을 피하기 위해 노력합니다. 즉, 일부 OSD는 다른 OSD보다 훨씬 많은 트래픽을 수신합니다. CRUSH는 배치 그룹이 OSD( 임의로 의사)에 할당될 때 기본 OSD는 클러스터 및 핫 스팟 및 네트워크 초과 구독 문제 때문에 데이터 배포로 인해 균등하게 분산되도록 오브젝트를 배치 그룹에 균등하게 할당하는 것이 좋습니다.

CRUSH는 각 오브젝트의 배치 그룹을 계산하지만 실제로 이 배치 그룹 내 의 각 OSD에 저장되는 데이터 양을 알 수 없으므로 배치 그룹과 OSD 수 간의 비율은 데이터 배포에 상당한 영향을 미칠 수 있습니다.

예를 들어 3개의 복제본 풀에 10개의 OSD가 있는 배치 그룹이 하나뿐인 경우 CRUSH에 다른 선택 항목이 없기 때문에 Ceph는 3개의 OSD만 사용하여 데이터를 저장합니다. 더 많은 배치 그룹을 사용할 수 있으면 CRUSH가 OSD에 오브젝트를 균등하게 분산할 가능성이 높습니다. CRUSH는 OSD에 배치 그룹을 균등하게 할당합니다.

OSD보다 배치 그룹이 하나 이상 있는 경우 배포도 수행해야 합니다. 예를 들어 3개의 OSD에 대한 256개의 배치 그룹, 10개의 OSD용 512 또는 1024 배치 그룹 등입니다.

OSD와 배치 그룹 간의 비율은 일반적으로 오브젝트 스트라이핑과 같은 고급 기능을 구현하는 Ceph 클라이언트의 통합 데이터 배포 문제를 해결합니다. 예를 들어 4TB 블록 장치는 4MB 오브젝트로 분할될 수 있습니다.

CRUSH는 오브젝트 크기를 고려하지 않기 때문에 OSD와 배치 그룹 간의 비율은 다른 경우의 짝수 없이 데이터 배포를 처리하지 않습니다. librados 인터페이스를 사용하여 비교적 작은 오브젝트를 저장하고 일부 매우 큰 오브젝트를 사용하면 데이터 배포가 취소될 수 있습니다. 예를 들어 총 4GB의 4GB의 4K 개체는 10개의 OSD에서 1000개의 배치 그룹에 균등하게 분배됩니다. 각 OSD에서 4GB / 10 = 400MB 를 사용합니다. 400MB 개체가 풀에 추가되면 개체가 배치된 배치 그룹을 지원하는 3개의 OSD는 400MB + 400MB = 800MB 로 채워지고 나머지 7개는 400MB로만 채워집니다.

각 배치 그룹의 경우 OSD 및 Ceph 모니터는 복구 중에 메모리, 네트워크 및 CPU가 항상 필요합니다. 배치 그룹 내에서 오브젝트를 클러스터링하여 이러한 오버헤드를 공유하는 것이 배치 그룹이 존재하는 주요 이유 중 하나입니다.

배치 그룹 수를 최소화하면 상당한 양의 리소스가 절약됩니다.

배치 그룹(PG) 계산기는 사용자의 배치 그룹 수를 계산하고 특정 사용 사례를 해결합니다. PG 계산기는 일반적으로 동일한 규칙(CRUSH 계층)을 사용하는 많은 풀이 있는 Ceph Object Gateway와 같은 Ceph 클라이언트를 사용할 때 유용합니다. 소규모 클러스터에 대한 배치 그룹 수의 지침을 사용하여 PG를 수동으로 계산하고 배치 그룹 수 를 계산할 수 있습니다. 그러나 PG 계산기는 PG를 계산하는 데 선호되는 방법입니다.

자세한 내용은 Red Hat 고객 포털 의 풀 계산기당 Ceph PG(배치 그룹) 를 참조하십시오.

풀을 생성할 때 풀에 대한 여러 배치 그룹도 생성합니다. 배치 그룹 수를 지정하지 않으면 Ceph에서 기본값인 8 을 사용합니다. 이 값은 매우 낮습니다. 풀의 배치 그룹 수를 늘릴 수 있지만 적절한 기본값도 설정하는 것이 좋습니다.

osd pool default pg num = 100
osd pool default pgp num = 100

배치 그룹 수(total)와 오브젝트( PG 분할에서 사용)에 사용되는 배치 그룹 수를 모두 설정해야 합니다. 둘 다 동등해야 합니다.

소규모 클러스터는 많은 수의 배치 그룹의 이점을 누릴 수 없습니다. OSD의 수가 증가함에 따라 pg_num 및 pgp_num 에 대한 올바른 값을 선택하는 것은 클러스터의 동작과 문제가 발생했을 때 데이터의 지속성에 상당한 영향을 미치기 때문에 더 중요합니다. 소규모 클러스터와 함께 PG 계산기 를 사용하는 것이 중요합니다.

OSD가 50개 이상 있는 경우 리소스 사용량, 데이터 지속성 및 배포의 균형을 유지하기 위해 OSD당 약 50~100개의 배치 그룹을 사용하는 것이 좋습니다. 50개 미만의 OSD가 있는 경우 PG Count for Small Clusters 중에서 선택하는 것이 좋습니다. 단일 오브젝트 풀의 경우 다음 공식을 사용하여 기준선을 얻을 수 있습니다.

                (OSDs * 100)
   Total PGs =  ------------
                 pool size

여기서 풀 크기는 복제된 풀의 복제본 수 또는 삭제 코드 풀에 대한 K+M 합계입니다( ceph osd erasure-code-profile get).

그런 다음 데이터 지속성, 데이터 배포 및 리소스 사용량을 최소화하도록 Ceph 클러스터를 설계한 방식과 관련하여 결과가 적합한지 확인해야 합니다.

결과는 두 개의 가장 가까운 거력으로 반올림되어야 합니다. 반올림은 선택 사항이지만 CRUSH는 배치 그룹 간에 오브젝트 수를 균등하게 조정하는 것이 좋습니다.

200개의 OSD와 풀 크기가 3개의 복제본이 있는 클러스터의 경우 다음과 같이 PG 수를 추정합니다.

   (200 * 100)
   ----------- = 6667. Nearest power of 2: 8192
        3

8192개의 배치 그룹이 200개의 OSD에 분산되어 있어 OSD당 약 41개의 배치 그룹으로 평가됩니다. 각 풀은 배치 그룹도 생성하므로 클러스터에서 사용할 수 있는 풀 수도 고려해야 합니다. 적절한 최대 배치 그룹 수가 있는지 확인합니다.

오브젝트 저장을 위해 여러 데이터 풀을 사용하는 경우 풀당 배치 그룹 수와 OSD당 배치 그룹 수를 적절한 총 배치 그룹 수에 도달하도록 해야 합니다. 목표는 시스템 리소스에 부담을 주거나 피어링 프로세스를 너무 느리게 만들지 않고도 OSD당 상당히 낮은 분산을 달성하는 것입니다.

10개의 풀로 구성된 Ceph Storage Cluster는 10개의 OSD에 512개의 배치 그룹이 있는 각 풀은 10개의 OSD를 통해 분배되는 총 5,120개의 배치 그룹 또는 OSD당 512개의 배치 그룹이 있습니다. 하드웨어 구성에 따라 리소스가 너무 많이 사용되지 않을 수 있습니다. 반대로 각각 512개의 배치 그룹을 사용하여 1,000개의 풀을 생성하는 경우 OSD는 각각 ~50,000개의 배치 그룹을 처리하고 더 많은 리소스가 필요합니다. OSD당 너무 많은 배치 그룹으로 작동하면 특히 재조정 또는 복구 중에 성능이 크게 저하될 수 있습니다.

Ceph Storage 클러스터에는 OSD당 기본 최대 300개의 배치 그룹이 있습니다. Ceph 구성 파일에서 다른 최대값을 설정할 수 있습니다.

mon pg warn max per osd

Red Hat Ceph Storage 클러스터의 각 풀에는 PG의 pg_autoscale_mode 속성이 있으며, 이는 ,on 또는 warn 로 설정할 수 있습니다.

자동 스케일러는 bulk 플래그를 사용하여 PG를 완전히 보완하여 시작해야 하는 풀을 결정하고 풀의 사용량이 짝수하지 않은 경우에만 축소됩니다. 그러나 풀에 대량 플래그가 없는 경우 풀은 최소 PG로 시작하고 풀에 더 많은 사용량이 있는 경우에만 풀이 시작됩니다.

풀, 상대 사용률 및 스토리지 클러스터의 PG 수에 대한 제안된 변경 사항을 볼 수 있습니다.

SIZE 는 풀에 저장된 데이터의 양입니다.

TARGET 크기 (있는 경우)는 관리자가 이 풀에 저장하려는 것으로 예상한 데이터의 양입니다. 시스템은 계산에 두 값 중 더 큰 값을 사용합니다.

RATE 는 풀에서 사용하는 원시 스토리지 용량을 결정하는 풀의 승수입니다. 예를 들어 3 개의 복제본 풀의 비율은 3.0 인 반면 k=4,m=2 삭제 풀의 비율은 1.5 입니다.

RAW CAPACITY 는 풀의 데이터를 저장하는 OSD의 총 원시 스토리지 용량입니다.

RATIO 는 풀이 소비하는 총 용량의 비율, 즉 ratio = size * rate / raw capacity입니다.

TARGET RATIO (있는 경우)는 관리자가 대상 비율이 설정된 다른 풀과 상대적으로 사용할 것으로 예상되는 스토리지의 비율입니다. 대상 크기 바이트와 비율이 모두 지정된 경우 비율이 우선합니다. 풀을 만드는 동안 지정하지 않으면 TARGET RATIO 의 기본값은 0 입니다. 풀에서 --target_ratio 를 더 많이 제공할수록 풀에 필요한 PG가 커집니다.

EFFECTIVE RATIO 는 두 가지 방법으로 조정한 후 대상 비율입니다. 1. 대상 크기 세트가 있는 풀에서 사용할 수 있는 용량을 뺀 것입니다. 2. 대상 비율이 설정된 풀 간 대상 비율을 표준화하여 나머지 공간을 전체적으로 대상으로 지정합니다. 예를 들어, 대상 비율이 1.0인 4 풀의 유효 비율은 0.25입니다. 시스템은 실제 비율보다 크고 계산을 위해 효과적인 비율을 사용합니다.

BIAS 는 특정 풀에 얼마나 많은 PG가 있어야 하는지에 대한 이전 정보를 기반으로 풀 PG를 수동으로 조정하는 데 사용됩니다. 기본적으로 풀을 만들 때 지정하지 않는 한 1.0인 경우 값이 설정됩니다. 풀에서 --bias 를 더 많이 제공할수록 풀에 필요한 PG가 커집니다.

PG_NUM 은 풀의 현재 PG 수 또는 pg_num 변경이 진행 중인 경우 풀이 작업 중인 PG 수입니다. NEW PG_NUM 은 제안된 PG 수(pg_num)입니다. 이는 항상 2의 힘이며 제안된 값이 현재 값과 3배 이상 달라질 때만 존재합니다.

AUTOSCALE 은 pg_autoscale_mode 풀이며 ,off 또는 warn 에 있습니다.

BULK 는 PG를 완전히 보완하여 시작해야 하는 풀을 결정하는 데 사용됩니다. 사용량 비율이 풀에서 교차하는 경우에만 BULK 가 축소됩니다. 풀에 이 플래그가 없는 경우 풀은 최소 양의 PG로 시작하고 풀에 더 많은 사용량이 있을 때만 사용됩니다.

BULK 값은 true,false,1 또는 0 입니다. 여기서 1 은 true 와 같고 0 은 false 와 동일합니다. 기본값은 false입니다.

풀 생성 중 또는 후에 BULK 값을 설정합니다.

일괄 플래그를 사용하는 방법에 대한 자세한 내용은 풀 생성 및 배치 그룹 자동 확장 모드를 참조하십시오.

클러스터에서 클러스터 사용량에 따라 PG를 자동으로 확장할 수 있도록 허용하는 것이 PG의 스케일링을 위한 가장 간단한 방법입니다. Red Hat Ceph Storage는 전체 시스템에 사용 가능한 총 스토리지와 대상 PG 수를 사용하고, 각 풀에 저장되는 데이터를 비교하고, 그에 따라 PG를 승인합니다. 이 명령은 현재 PG 수(pg_num)가 계산되거나 제안된 PG 번호에서 3번 이상인 풀만 변경합니다.

OSD당 PG의 대상 수는 mon_target_pg_per_osd 구성 가능을 기반으로 합니다. 기본값은 100 으로 설정됩니다.

모든 풀에 대해 자동 스케일러를 동시에 활성화하거나 비활성화하려면 noautoscale 글로벌 플래그를 사용할 수 있습니다. 이 글로벌 플래그는 일부 OSD가 반송되거나 클러스터가 유지보수 중인 경우 스토리지 클러스터를 업그레이드하는 동안 유용합니다. 활동 전에 플래그를 설정하고 활동이 완료되면 설정을 해제할 수 있습니다.

기본적으로 noautoscale 플래그는 off 로 설정됩니다. 이 플래그를 설정하면 모든 풀에 pg_autoscale_mode 가 off 로 표시되고 모든 풀이 자동 스케일러를 비활성화합니다.

ceph osd pool create 명령에 선택적 --target-size-bytes <bytes > 인수를 추가하여 생성 시 풀의 대상 크기를 설정할 수도 있습니다.

선택적 --target-size-ratio <ratio > 인수를 ceph osd pool create 명령에 추가하여 생성 시 풀의 대상 크기를 설정할 수도 있습니다.

풀에서 배치 그룹 수를 설정하려면 풀을 생성할 때 배치 그룹 수를 지정해야 합니다. 자세한 내용은 풀 생성 을 참조하십시오. 풀에 배치 그룹을 설정하면 배치 그룹 수를 늘릴 수 있습니다(하지만 배치 그룹 수를 줄일 수는 없습니다). 배치 그룹 수를 늘리려면 다음을 실행합니다.

ceph osd pool set POOL_NAME pg_num PG_NUM

배치 그룹 수를 늘리면 클러스터가 재조정되기 전에 배치 그룹(pgp_num)을 늘려야 합니다. pgp_num 은 pg_num 과 같아야 합니다. 배치에 대한 배치 그룹 수를 늘리려면 다음을 실행합니다.

ceph osd pool set POOL_NAME pgp_num PGP_NUM

풀의 배치 그룹 수를 가져오려면 다음을 실행합니다.

ceph osd pool get POOL_NAME pg_num

storag 클러스터에서 배치 그룹에 대한 통계를 가져오려면 다음을 실행합니다.

ceph pg dump [--format FORMAT]

유효한 형식은 plain (기본값) 및 json 입니다.

지정된 상태의 모든 배치 그룹에 대한 통계를 가져오려면 다음을 실행합니다.

ceph pg dump_stuck {inactive|unclean|stale|undersized|degraded [inactive|unclean|stale|undersized|degraded...]} INTERVAL

비활성 배치 그룹은 최신 데이터가 있고 in이 될 OSD를 대기하기 때문에 읽기 또는 쓰기를 처리할 수 없습니다.

Unclean 배치 그룹에는 원하는 횟수만큼 복제되지 않는 오브젝트가 포함됩니다. 복구해야 합니다.

오래된 배치 그룹은 알 수 없음 상태가 됩니다. 호스트하는 OSD는 잠시 동안 모니터 클러스터에 보고되지 않았습니다( mon_osd_report_timeout로 구성).

유효한 형식은 plain (기본값) 및 json 입니다. 임계값은 배치 그룹이 반환된 통계(기본값 300초)에 포함하기 전에 정지되는 최소 시간(초)을 정의합니다.

특정 배치 그룹에 대한 배치 그룹 맵을 가져오려면 다음을 실행합니다.

ceph pg map PG_ID

[ceph: root@host01 /]# ceph pg map 1.6c

Ceph는 배치 그룹 맵, 배치 그룹 및 OSD 상태를 반환합니다.

osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

배치 그룹을 스크럽하려면 다음을 실행합니다.

ceph pg scrub PG_ID

Ceph는 기본 및 모든 복제본 노드를 확인하고, 배치 그룹에 모든 오브젝트 카탈로그를 생성하고 이를 비교하여 오브젝트가 누락되거나 일치하지 않으며 내용이 일관되게 유지되도록 합니다. 모든 복제본이 일치한다고 가정하면 최종 의미 체계 sweep은 모든 스냅샷 관련 오브젝트 메타데이터를 일관되게 유지합니다. 오류는 로그를 통해 보고됩니다.

클러스터에서 하나 이상의 오브젝트가 손실되고 손실된 데이터에 대한 검색을 중단하려면 unfound 오브젝트를 lost 로 표시해야 합니다.

가능한 모든 위치를 쿼리하고 개체가 손실된 경우 손실된 오브젝트를 포기해야 할 수 있습니다. 이는 클러스터가 쓰기 자체를 복구하기 전에 수행된 쓰기에 대해 학습할 수 있는 비정상적인 실패 조합일 수 있습니다.

현재 지원되는 유일한 옵션은 "revert"이며, 이는 이전 버전의 오브젝트로 롤백되거나 (새 오브젝트인 경우) 완전히 잊어 버립니다. "unfound" 오브젝트를 "lost"로 표시하려면 다음을 실행합니다.

ceph pg PG_ID mark_unfound_lost revert|delete

새 삭제 코드 프로필을 생성하려면 다음을 수행합니다.

ceph osd erasure-code-profile set NAME \
         [<directory=DIRECTORY>] \
         [<plugin=PLUGIN>] \
         [<stripe_unit=STRIPE_UNIT>] \
         [<_CRUSH_DEVICE_CLASS_>]\
         [<_CRUSH_FAILURE_DOMAIN_>]\
         [<key=value> ...] \
         [--force]

다음과 같습니다.

삭제 코드 프로필을 제거하려면 다음을 수행합니다.

ceph osd erasure-code-profile rm RULE_NAME

풀에서 프로필을 참조하는 경우 삭제가 실패합니다.

삭제 코드 프로필을 표시하려면 다음을 수행합니다.

ceph osd erasure-code-profile get NAME

모든 삭제 코드 프로필의 이름을 나열하려면 다음을 수행합니다.

ceph osd erasure-code-profile ls

jerasure 플러그인은 가장 일반적이고 유연한 플러그인입니다. Ceph 삭제 코딩 풀의 기본값이기도 합니다.

jerasure 플러그인은 JerasureH 라이브러리를 캡슐화합니다. 매개변수에 대한 자세한 내용은 jerasure 문서를 참조하십시오.

jerasure 플러그인을 사용하여 새 삭제 코드 프로필을 생성하려면 다음 명령을 실행합니다.

ceph osd erasure-code-profile set NAME \
     plugin=jerasure \
     k=DATA_CHUNKS \
     m=DATA_CHUNKS \
     technique=TECHNIQUE \
     [crush-root=ROOT] \
     [crush-failure-domain=BUCKET_TYPE] \
     [directory=DIRECTORY] \
     [--force]

다음과 같습니다.

기본 CRUSH 규칙은 다른 호스트에 있는 OSD를 제공합니다. 예를 들면 다음과 같습니다.

chunk nr    01234567

step 1      _cDD_cDD
step 2      cDDD____
step 3      ____cDDD

각 청크마다 정확히 8 개의 OSD가 필요합니다. 호스트가 두 개의 인접한 랙에 있는 경우 첫 번째 랙에 처음 4개의 청크를 배치하고 두 번째 랙에서 마지막 네 개의 청크를 배치할 수 있습니다. 단일 OSD 손실에서 복구하려면 두 랙 사이의 대역폭을 사용할 필요가 없습니다.

예를 들면 다음과 같습니다.

crush-steps='[ [ "choose", "rack", 2 ], [ "chooseleaf", "host", 4 ] ]'

유형 랙 의 두 개의 CRUSH 버킷을 선택하는 규칙을 만들고 각 버킷에 대해 호스트 유형의 다른 버킷에 있는 4개의 OSD를 선택합니다.

세분화된 제어를 위해 규칙을 수동으로 생성할 수도 있습니다.