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

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

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

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

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

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

참고:

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

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

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

예를 들어 SSD 저널이 있는 SAS 디스크의 계층 구조(sd), 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

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

초기 클러스터를 생성하면 Ceph에 default 라는 루트 버킷이 있고 초기 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는 기본적으로 알고리즘을 straw 로 설정합니다. Ceph는 성능 및 재구성 효율성 간의 절충을 나타내는 네 가지 버킷 알고리즘을 지원합니다. 사용할 버킷 유형이 확실하지 않은 경우 straw 버킷을 사용하는 것이 좋습니다. 버킷 알고리즘은 다음과 같습니다.

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 계층에 OSD를 추가하는 것은 OSD를 시작하고(대부분의) Ceph 에서배치 그룹을 OSD에 할당하는 마지막 단계입니다.

CRUSH 계층 구조에 추가하기 전에 OSD를 준비해야 합니다. 배포 유틸리티(Ansible 자동화 애플리케이션)는 이 단계를 수행합니다. 자세한 내용은 OSD 추가/제거를 참조하십시오.

CRUSH 계층 구조로 표시되지 않으므로 ceph osd crush add 명령을 사용하면 원하는 위치에서 OSD를 CRUSH 계층에 추가할 수 있습니다. 지정한 위치는 실제 위치를 반영 해야 합니다. 하나 이상의 버킷을 지정하면 명령에서 지정한 가장 구체적인 버킷에 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

Ansible 자동화 애플리케이션과 같은 배포 유틸리티에서 기본 CRUSH 위치의 CRUSH 맵에 OSD를 추가하거나 클러스터 토폴로지가 변경되면 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> <osdId> [<osdId>...]

예:

# ceph osd crush set-device-class hdd osd.0 osd.1
# ceph osd crush set-device-class ssd osd.2 osd.3
# ceph osd crush set-device-class bucket-index osd.4

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

# ceph osd crush rm-device-class <class> <osdId> [<osdId>...]

예:

# ceph osd crush rm-device-class hdd osd.0 osd.1
# ceph osd crush rm-device-class ssd osd.2 osd.3
# ceph osd crush rm-device-class bucket-index osd.4

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

# ceph osd crush class rename <oldName> <newName>

예:

# 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 osd crush class ls-osd hdd

출력은 단순히 OSD 번호 목록입니다. 예:

0
1
2
3
4
5
6

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

# ceph osd crush rule ls-by-class <class>

예:

# ceph osd crush rule ls-by-class hdd

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

ceph osd crush reweight {name} {weight}

다음과 같습니다.

이 설정은 OSD를 추가하거나 OSD를 추가한 직후 CRUSH 가중치를 조정할 때 사용됩니다. 일반적으로 OSD의 라이프 사이클은 변경되지 않습니다.

ceph osd crush reweight 을 사용하면 시간이 오래 걸릴 수 있습니다. 다음을 실행하여 버킷(row, rack, node 등)에서 모든 Ceph OSD 가중치를 설정(또는 재설정)할 수 있습니다.

osd crush reweight-subtree <name>

여기서,

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

에서 ceph osd 및 ceph osd 의 목적으로 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 osd test-reweight-by-utilization 110 .5 4 --no-increasing

다음과 같습니다.

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

OSD 수가 적은 CRUSH 계층에서는 일부 OSD에서 다른 OSD보다 더 많은 PG를 가져올 수 있으므로 부하가 증가할 수 있습니다. 다음을 실행하여 이러한 상황을 해결하기 위해 PG 배포로 OSD를 다시 정렬할 수 있습니다.

osd reweight-by-pg <poolname>

다음과 같습니다.

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 {rulename} {root} {bucket-type} {firstn|indep}

Ceph는 지정한 유형의 리프와 버킷 1개를 선택하여 규칙을 생성합니다.

예:

ceph osd crush rule create-simple deleteme default host firstn

다음 규칙을 생성합니다.

{ "rule_id": 1,
  "rule_name": "deleteme",
  "ruleset": 1,
  "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 osd crush rule create-replicated fast default host ssd

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

ceph osd crush rule create-erasure {rulename} {profilename}

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

ceph osd crush rule rm {name}

버전 0.48 이전의 Ceph 클라이언트 및 데몬은 튜닝 가능 항목을 탐지하지 않으며 버전 0.48 이상과 호환되지 않습니다. 튜닝 가능한 CRUSH 값을 조정하는 기능도 주요 Ceph 릴리스와 함께 개선되었습니다.

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

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

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

# ceph osd crush tunables <profile>

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

모든 클라이언트가 최근 코드를 실행 중인지 확인할 수 있는 경우 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)을 사용자가 지정한 파일 이름으로 분해(-d)합니다.

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

crushtool -c {decompiled-crush-map-filename} -o {compiled-crush-map-filename}

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

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

ceph osd setcrushmap -i  {compiled-crushmap-filename}

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

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

하드웨어 장애는 예외가 아니라 기대치를 기대할 수 있습니다. 위의 시나리오를 방지하기 위해 복구 프로세스는 합리적으로 가능한 한 빨리 회복해야합니다. 클러스터의 크기, 하드웨어 구성 및 배치 그룹 수가 총 복구 시간에 중요한 역할을 합니다.

Ceph에서 나머지 150개의 배치 그룹을 9개의 나머지 OSD에 무작위로 저장할 수 있습니다. 따라서 나머지 OSD는 각 오브젝트 복사본을 다른 모든 OSD에 전송하고, 나머지 OSD는 이제 150개의 배치 그룹 중 일부가 할당되어 있으므로 일부 새 오브젝트도 받을 수 있습니다.

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

그러나 동일한 Ceph 클러스터를 OSD 10개 대신 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 중 하나라도 실패하면 하나의 배치 그룹의 마지막 오브젝트가 손실될 수 있습니다(즉, 남아 있는 복사본이 1개뿐인 8 pgs/8ds ). 따라서 다소 더 큰 클러스터(예: 50개의 OSD)로 시작하는 것이 좋습니다.

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

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

Ceph는 핫스팟을 피하려고 합니다. 즉, 일부 OSD는 다른 OSD보다 훨씬 더 많은 트래픽을 수신합니다. CRUSH는 배치 그룹에 오브젝트를 균등하게 할당하므로 배치 그룹을 OSD(ps random)에 할당할 때 기본 OSD 저장소 오브젝트를 클러스터에 균등하게 분산하고 핫 스팟 및 네트워크 초과 구독 문제는 데이터 배포로 인해 개발되지 않습니다.

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

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

OSD보다 넓게 많은 배치 그룹이 하나 또는 두 개의 순서가 있는 경우 배포도 가능해야 합니다. 예를 들어 OSD 3개, OSD 10용 512개 또는 1024개의 배치 그룹 등 여러 개의 배치 그룹이 있습니다.

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

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

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

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

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

자세한 내용은 Red Hat Customer Portal 의 풀당 Ceph PG(배치 그룹) 를 참조하십시오.

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

osd pool default pg num = 1024
osd pool default pgp num = 1024

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

소규모 클러스터는 많은 수의 배치 그룹의 이점을 얻을 수 없습니다. OSD 수가 증가함에 따라 pg_num 및 pgp_num 에 대한 올바른 값을 선택하는 것이 더 중요해졌습니다. 클러스터의 동작에 상당한 영향을 미치고 문제가 발생할 때 데이터의 내구성이 향상되기 때문입니다(즉, 심각한 이벤트가 데이터 손실로 이어질 가능성이 큽니다). 소규모 클러스터에서 PG 계산기 를 사용하는 것이 중요합니다.

OSD 50개가 넘는 OSD가 있는 경우 OSD당 약 50~100개의 배치 그룹을 사용하여 리소스 사용량, 데이터 지속성 및 배포를 분산하는 것이 좋습니다. OSD가 50개 미만인 경우 작은 클러스터용 PG 개수 중에서 선택하는 것이 좋습니다. 단일 개체 풀의 경우 다음 수식을 사용하여 기준선을 가져올 수 있습니다.For a single pool of objects, you can use the following formula to get a baseline:

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

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

그런 다음 Ceph 클러스터를 설계하여 데이터 지속성, 데이터 배포 및 리소스 사용량을 최소화하는 방법에 적합한지 확인해야 합니다.

결과는 두 개의 가장 가까운 전력으로 반올림됩니다. 반올림은 선택 사항이지만 CRUSH에서 배치 그룹 간 오브젝트 수의 균형을 조정하는 것이 좋습니다.

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

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

OSD당 약 41개의 배치 그룹으로 평가되는 200개의 OSD에 분산된 8192 배치 그룹이 있습니다. 또한 각 풀이 배치 그룹을 생성하기 때문에 클러스터에서 사용할 수 있는 풀 수도 고려해야 합니다. 합리적인 최대 PG 수가 있는지 확인하십시오.

여러 데이터 풀을 사용하여 오브젝트를 저장하는 경우, 적절한 총 배치 그룹에 도달하도록 풀당 배치 그룹 수와 OSD당 배치 그룹 수의 균형을 조정해야 합니다. 목표는 시스템 리소스에 대한 비용 절감 또는 피어링 프로세스가 너무 느리지 않고 OSD당 상당히 낮은 분산을 달성하는 것입니다.

10개 풀로 구성된 예시적인 Ceph Storage 클러스터에서는 10개의 OSD에 512개의 배치 그룹이 있는 각 풀에는 총 5개의 OSD가 있으며 OSD당 512개 이상의 배치 그룹이 분배됩니다. 하드웨어 구성에 따라 너무 많은 리소스를 사용하지 않을 수 있습니다. 반면, 각각 512개의 배치 그룹이 있는 1,000개의 풀을 생성하면 OSD에서 각각 ~50,000개의 배치 그룹을 처리하고 더 많은 리소스가 필요합니다. OSD당 너무 많은 배치 그룹으로 작업하면 특히 재조정 또는 복구 중에 성능이 크게 저하될 수 있습니다.

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

mon_max_pg_per_osd

Red Hat Ceph Storage 클러스터의 각 풀에는 PGs의 pg_autoscale_mode 속성이 있으며, 이는 ,on 또는 warn 입니다.

pg_autoscale_mode 의 기본값은 warn 모드입니다.

SIZE 는 풀에 저장된 데이터의 양입니다. TARGET SIZE 는 관리자가 지정한 데이터의 양이며, 결국 이 풀에 저장됩니다. 시스템은 계산에 두 값 중 더 큰 값을 사용합니다.

RATE 는 풀에서 사용하는 원시 스토리지 용량의 양을 결정하는 풀의 곱값입니다. 예를 들어 3 개의 복제본 풀에는 3.0 의 비율이 있으며 k=4,m=2 pastsure coded 풀에는 1.5 의 비율이 있습니다.

RAW CAPACITY 는 풀 데이터를 저장하는 OSD의 총 원시 스토리지 용량입니다. RATIO 는 풀이 소비하는 총 용량의 비율, 즉 비율 = 크기 * 비율 / 원시 용량입니다.

TARGET RATIO 는 관리자가 지정한 스토리지의 비율이므로 대상 비율이 설정된 다른 풀과 관련하여 소비할 것으로 예상됩니다. 대상 크기 바이트와 비율을 모두 지정하면 비율이 우선합니다.

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

BIAS 는 PG 자동 스케일러가 PG 수의 수에 따라 일부 풀을 다른 풀보다 더 빠르게 스케일링하는 데 사용하는 풀 속성입니다. 기본적으로 기본 PG 수보다 풀에 더 많은 PG를 제공하는 데 사용되는 멀티플라이어입니다. 이 속성은 크기가 작을 수 있지만 크기가 많지만 많은 오브젝트가 있으므로 성능 향상을 위해 더 빠르게 스케일링하는 것이 중요합니다. BIAS의 기본값은 1.0입니다. ceph osd pool set pool-name pg_autoscale_bias 4 명령을 실행하여 이 값을 설정할 수 있습니다. 허용되는 값은 0에서 1000 사이입니다. 그러나 CephFS 메타데이터 풀 및 Ceph Object Gateway 인덱스 풀에 대해 기본적으로 BIAS의 값을 4.0으로 설정하는 것이 좋습니다.

PG_NUM 은 풀에 대한 현재 PG 수 또는 pg_num 변경이 진행 중인 경우 풀의 현재 PG 수입니다. NEW PG_NUM (있는 경우)은 제안된 PG(pg_num)입니다. 항상 2의 힘이며 제안된 값은 항상 현재 값과 3배 이상 다릅니다.

NovaCronSCALE 는 pg_autoscale_mode 풀이며, ,off 또는 warn 입니다.

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

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

새로 생성된 풀은 전체 클러스터 용량의 작은 부분을 소비하며 적은 수의 PG가 필요한 시스템에 나타납니다. 그러나 대부분의 경우 클러스터 관리자는 시간이 지남에 따라 대부분의 시스템 용량을 사용할 것으로 예상되는 풀을 인식합니다. 이 정보를 Red Hat Ceph Storage에 대상 크기 라고 하는 경우 이러한 풀은 처음부터 더 적절한 PG(pg_num)를 사용할 수 있습니다. 이 접근 방식은 pg_num 의 후속 변경 및 이러한 조정을 할 때 데이터 이동과 관련된 오버헤드를 방지합니다.

다음과 같은 방법으로 풀의 대상 크기를 지정할 수 있습니다.

풀에서 배치 그룹 수를 설정하려면 풀을 만들 때 배치 그룹 수를 지정해야 합니다. 자세한 내용은 풀 만들기를 참조하십시오. 풀을 생성한 후 배치 그룹 수를 변경하려면 다음을 실행합니다.

ceph osd pool set {pool-name} pg_num {pg_num}

배치 그룹 수를 늘리면 클러스터가 재조정하기 전에 배치(pgp_num)에 대해 배치 그룹 수를 늘려야 합니다. pgp_num 은 pg_num 과 같아야 합니다. pgp_num 은 CRUSH 알고리즘에 의한 배치 그룹에 의해 고려될 배치 그룹의 수입니다. pg_num 이 증가하면 배치 그룹을 분할하지만, 배치 그룹(즉, pgp_num )이 증가할 때까지 데이터가 최신 배치 그룹으로 마이그레이션되지 않습니다. 배치를 위한 배치 그룹 수를 늘리려면 다음을 실행합니다.

ceph osd pool set {pool-name} pgp_num {pgp_num}

PG 수를 줄이면 pgp_num 이 자동으로 조정됩니다.

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

ceph osd pool get {pool-name} pg_num

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

ceph pg dump [--format {format}]

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

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

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

비활성 배치 그룹은 최신 데이터가 제공될 OSD를 기다리고 있으므로 읽기 또는 쓰기 작업을 처리할 수 없습니다.

불명확 한 배치 그룹에는 원하는 횟수를 복제하지 않는 오브젝트가 포함되어 있습니다. 그들은 회복되어야 합니다.

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

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

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

ceph pg map {pg-id}

예:

ceph pg map 1.6c

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

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

특정 배치 그룹의 통계를 검색하려면 다음을 실행합니다.

ceph pg {pg-id} query

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

ceph pg scrub {pg-id}

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

클러스터가 하나 이상의 오브젝트를 손실하고 손실된 데이터를 검색하기로 결정한 경우, unfound 오브젝트를 손실된 것으로 표시해야합니다.

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

현재 지원되는 유일한 옵션은 "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 <name>

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

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

ceph osd erasure-code-profile get <name>

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

ceph osd erasure-code-profile ls

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

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

jerasure 플러그인을 사용하여 새로운 Agesure 코드 프로필을 만들려면 다음 명령을 실행하십시오.

ceph osd erasure-code-profile set <name> \
     plugin=jerasure \
     k=<data-chunks> \
     m=<coding-chunks> \
     technique=<reed_sol_van|reed_sol_r6_op|cauchy_orig|cauchy_good|liberation|blaum_roth|liber8tion> \
     [crush-root=<root>] \
     [crush-failure-domain=<bucket-type>] \
     [directory=<directory>] \
     [--force]

다음과 같습니다.

jerasure 플러그인을 사용하면 Ceph가 여러 OSD에 Agesure-coded 오브젝트를 저장할 때 하나의 OSD가 손실되는 것을 복구하려면 다른 모든 것에서 읽기가 필요합니다. 예를 들어 k=8 및 m=4 로 jerasure 를 구성하는 경우 하나의 OSD를 손실하려면 다른 사람의 수를 복구해야 합니다.

lrc 삭제 코드 플러그인은 로컬 패리티 청크를 생성하여 더 적은 OSD를 사용하여 복구할 수 있습니다. 예를 들어 k=8,m=4 및 l=4 를 사용하여 lrc 를 구성하는 경우 4개 OSD마다 추가 패리티 청크가 생성됩니다. Ceph가 단일 OSD를 손실하면 4개의 OSD만 사용하여 개체 데이터를 복구할 수 있습니다.

모든 호스트가 동일한 스위치에 연결된 경우 흥미로운 사용 사례는 아니지만 lrc agesure 코드 플러그인을 사용할 때 랙 간 대역폭 사용량 감소를 실제로 관찰할 수 있습니다.

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     k=4 m=2 l=3 \
     crush-failure-domain=host
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

1.2 버전에서는 기본 OSD가 손실된 청크와 동일한 랙에 있는 경우에만 대역폭 감소를 확인할 수 있습니다.

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     k=4 m=2 l=3 \
     crush-locality=rack \
     crush-failure-domain=host
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

ceph osd erasure-code-profile set <name> \
     plugin=lrc \
     k=<data-chunks> \
     m=<coding-chunks> \
     l=<locality> \
     [crush-root=<root>] \
     [crush-locality=<bucket-type>] \
     [crush-failure-domain=<bucket-type>] \
     [directory=<directory>] \
     [--force]

chunk nr    01234567
step 1      _cDD_cDD
step 2      cDDD____
step 3      ____cDDD

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=DD_ \
     layers='[ [ "DDc", "" ] ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=__DD__DD \
     layers='[
               [ "_cDD_cDD", "" ],
               [ "cDDD____", "" ],
               [ "____cDDD", "" ],
             ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=__DD__DD \
     layers='[
               [ "_cDD_cDD", "" ],
               [ "cDDD____", "" ],
               [ "____cDDD", "" ],
             ]' \
     crush-steps='[
                     [ "choose", "rack", 2 ],
                     [ "chooseleaf", "host", 4 ],
                    ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=DD_ \
     layers='[ [ "DDc", "plugin=isa technique=cauchy" ] ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=__DD__DD \
     layers='[
               [ "_cDD_cDD", "plugin=isa technique=cauchy" ],
               [ "cDDD____", "plugin=isa" ],
               [ "____cDDD", "plugin=jerasure" ],
             ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

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

chunk nr    01234567

step 1      _cDD_cDD
step 2      cDDD____
step 3      ____cDDD

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

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

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

는 유형 랙 의 두 개의 크루쉬 버킷을 선택하고 각각에 대해 4 개의 OSD를 선택합니다. 각 OSD는 서로 다른 유형의 host 에 있습니다.

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