2.5. CRUSH 계층 구조 개발

관리 노드의 명령줄에서 각 CRUSH 계층 구조에 대한 CRUSH 맵에 CRUSH 루트를 생성합니다. 데이터 스토리지 풀을 잠재적으로 제공할 수 있는 서비스 풀에는 CRUSH 계층 구조가 하나 이상 있어야 합니다. SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어에 매핑되는 버킷 인덱스 풀에 대한 CRUSH 계층 구조가 하나 이상 있어야 합니다.

CRUSH 계층 구조에 대한 자세한 내용은 Red Hat Ceph Storage Storage Strategies Guide 8 의 CRUSH 계층 구조 섹션을 참조하십시오.

CRUSH 맵을 수동으로 편집하려면 Red Hat Ceph Storage Storage Strategies Guide 8 의 CRUSH 맵 편집 섹션을 참조하십시오.

다음 예제에서 data0, data 1 및 data2 라는 호스트는 동일한 물리적 호스트를 가리키는 여러 CRUSH 계층 구조가 있으므로 data0-sas-ssd,data0-index 등의 확장된 논리 이름을 사용합니다.

일반적인 CRUSH 루트는 저널의 SAS 드라이브 및 SSD로 노드를 나타낼 수 있습니다. 예를 들면 다음과 같습니다.

##
# SAS-SSD ROOT DECLARATION
##

root sas-ssd {
  id -1   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item data2-sas-ssd weight 4.000
  item data1-sas-ssd weight 4.000
  item data0-sas-ssd weight 4.000
}

버킷 인덱스의 CRUSH 루트 는 SSD 또는 NVMe 드라이브와 같은 고성능 미디어를 나타냅니다. OSD 저널을 저장하는 SSD 또는 NVMe 미디어에 파티션을 생성하는 것이 좋습니다. 예를 들면 다음과 같습니다.

##
# INDEX ROOT DECLARATION
##

root index {
  id -2    # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item data2-index weight 1.000
  item data1-index weight 1.000
  item data0-index weight 1.000
}

RHCS 3 이상 릴리스에서 CRUSH는 RHCS 2 및 이전 릴리스에서 지원되지 않는 스토리지 장치 "클래스"의 개념을 지원합니다. NVMe, SSD 또는 HDD와 같이 여러 스토리지 장치가 포함된 호스트 또는 노드가 있는 RHCS 3 클러스터에서는 장치 클래스가 있는 단일 CRUSH 계층 구조를 사용하여 스토리지 장치의 클래스를 구분합니다. 이렇게 하면 논리 호스트 이름을 사용할 필요가 없습니다. RHCS 2 및 이전 릴리스에서는 각 장치 클래스에 대해 여러 CRUSH 계층 구조 및 논리 호스트 이름을 사용하여 CRUSH 계층 구조의 호스트 또는 노드를 구분합니다.

RHCS 3 이상 릴리스에서 CRUSH는 RHCS 2 및 이전 릴리스에서 지원되지 않는 스토리지 장치 "class"의 개념을 지원합니다. NVMe, SSD 또는 HDD와 같이 스토리지 장치의 여러 클래스가 포함된 호스트 또는 노드가 있는 RHCS 3 클러스터에서는 장치 클래스와 함께 단일 CRUSH 계층 구조를 사용하여 스토리지 장치의 다른 클래스를 구분합니다. 이렇게 하면 논리 호스트 이름을 사용할 필요가 없습니다. RHCS 2 및 이전 릴리스에서는 각 장치 클래스에 대해 여러 CRUSH 계층 구조 및 논리 호스트 이름을 사용하여 CRUSH 계층 구조의 호스트 또는 노드를 구분합니다.

CRUSH 맵에서 호스트 이름은 고유해야 하며 한 번만 사용해야 합니다. 호스트가 여러 CRUSH 계층 구조 및 사용 사례를 제공하는 경우 CRUSH 맵은 실제 호스트 이름이 한 번만 사용되는지 확인하기 위해 논리 호스트 이름을 사용할 수 있습니다. 예를 들어 노드에는 SSD, SSD 저널이 있는 SAS 드라이브, 공동 배치된 저널이 있는 SATA 드라이브와 같은 여러 개의 드라이브 클래스가 있을 수 있습니다. RHCS 2 및 이전 릴리스에서 동일한 호스트에 대해 여러 CRUSH 계층 구조를 생성하려면 계층에서 실제 호스트 이름 대신 논리 호스트 이름을 사용해야 버킷 이름이 CRUSH 계층 구조 내에서 고유합니다. 예를 들어 호스트 이름이 data2 인 경우 CRUSH 계층 구조에서 data2-sas-ssd 및 data2-index 와 같은 논리 이름을 사용할 수 있습니다.

host data2-sas-ssd {
  id -11   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item osd.0 weight 1.000
  item osd.1 weight 1.000
  item osd.2 weight 1.000
  item osd.3 weight 1.000
}

앞서 언급한 예에서 호스트 data2 는 논리 이름 data2-sas-ssd 를 사용하여 SSD의 저널이 있는 SAS 드라이브를 하나의 계층 구조로 매핑합니다. osd.0 부터 osd.3 까지 OSD ID는 높은 처리량 하드웨어 구성에서 SSD 저널을 사용하는 SAS 드라이브를 나타냅니다. 이러한 OSD ID는 다음 예의 OSD ID와 다릅니다.

다음 예에서 호스트 data2 는 논리 이름 data2-index 를 사용하여 버킷 인덱스의 SSD 드라이브를 두 번째 계층 구조에 매핑합니다. OSD ID osd.4 는 버킷 인덱스 풀에 독점적으로 사용되는 SSD 드라이브 또는 기타 고속 스토리지 미디어를 나타냅니다.

host data2-index {
  id -21   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item osd.4 weight 1.000
}

CRUSH 맵에서 앞의 예와 같이 논리 호스트 이름을 사용하는 경우 OSD 시작 스크립트가 초기화 시 실제 호스트 이름에 따라 호스트를 식별하지 못하도록 합니다. Ceph 구성 파일의 [global] 섹션에 다음 설정을 추가합니다.

osd_crush_update_on_start = false

논리적 호스트 이름을 정의하는 또 다른 방법은 Ceph 구성 파일의 [osd.<ID>] 섹션에 있는 각 OSD에 대한 CRUSH 맵의 위치를 정의하는 것입니다. OSD 시작 스크립트에서 정의하는 모든 위치를 재정의합니다. 앞서 언급한 예제에서 항목은 다음과 같을 수 있습니다.

[osd.0]
osd crush location = "host=data2-sas-ssd"

[osd.1]
osd crush location = "host=data2-sas-ssd"

[osd.2]
osd crush location = "host=data2-sas-ssd"

[osd.3]
osd crush location = "host=data2-sas-ssd"

[osd.4]
osd crush location = "host=data2-index"

기본 CRUSH 계층 구조와 마찬가지로 CRUSH 맵에는 기본 CRUSH 규칙도 포함되어 있습니다.

CRUSH 규칙에 대한 자세한 내용은 Red Hat Ceph Storage 8용 Red Hat Ceph Storage 전략 가이드 의 CRUSH 규칙 섹션을 참조하십시오. CRUSH 맵을 수동으로 편집하려면 Red Hat Ceph Storage 8용 Red Hat Ceph Storage Storage Strategies Guide 의 CRUSH 맵 편집 섹션을 참조하십시오.

각 CRUSH 계층 구조에 대해 CRUSH 규칙을 생성합니다. 다음 예제에서는 .rgw.root 를 포함하여 서비스 풀을 저장할 CRUSH 계층 구조의 규칙을 보여줍니다. 이 예제에서 루트 sas-ssd 는 기본 CRUSH 계층 구조로 사용됩니다. 이름 rgw-service 를 사용하여 기본 규칙과 구분합니다. step take sas-ssd line은 CRUSH 루트 생성 에서 생성된 sas-ssd 루트를 사용하도록 풀에 지시합니다. 여기서 하위 버킷에는 SAS 드라이브가 포함된 OSD 및 높은 처리량 하드웨어 구성 저널에 대해 SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어가 포함됩니다. 단계 chooseleaf 의 유형 랙 부분은 실패 도메인입니다. 다음 예제에서는 랙입니다.

##
# SERVICE RULE DECLARATION
##

rule rgw-service {
 type replicated
 min_size 1
 max_size 10
 step take sas-ssd
 step chooseleaf firstn 0 type rack
 step emit
}

다음 예제에서는 데이터 풀을 저장할 CRUSH 계층 구조의 규칙을 보여줍니다. 이 예에서 루트 sass d 는 기본 CRUSH 계층 구조로 사용됩니다. 서비스 규칙과 동일한 CRUSH 계층 구조입니다. rgw-throughput 을 사용하여 기본 규칙과 rgw-service 를 구분합니다. step take sas-ssd line은 CRUSH 루트 생성 에서 생성된 sas-ssd 루트를 사용하도록 풀에 지시합니다. 여기서 하위 버킷에는 SAS 드라이브가 포함된 OSD 및 높은 처리량 하드웨어 구성에서 SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어가 포함됩니다. 단계 chooseleaf 의 유형 호스트 부분은 실패 도메인입니다. 다음 예제에서는 호스트입니다. 규칙은 동일한 CRUSH 계층 구조이지만 다른 오류 도메인을 사용합니다.

##
# THROUGHPUT RULE DECLARATION
##

rule rgw-throughput {
 type replicated
 min_size 1
 max_size 10
 step take sas-ssd
 step chooseleaf firstn 0 type host
 step emit
}

다음 예제에서는 인덱스 풀을 저장할 CRUSH 계층 구조의 규칙을 보여줍니다. 이 예에서 루트 인덱스 는 기본 CRUSH 계층 구조 역할을 합니다. rgw-index 를 사용하여 rgw-service 및 rgw-throughput 과 구별합니다. step take index 행은 CRUSH 루트 생성 에서 생성된 인덱스 루트를 사용하도록 지시합니다. 하위 버킷에는 SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어 또는 OSD 저널도 저장하는 SSD 또는 NVMe 드라이브의 파티션이 포함되어 있습니다. 단계 chooseleaf 의 유형 랙 부분은 실패 도메인입니다. 다음 예제에서는 랙입니다.

##
# INDEX RULE DECLARATION
##

rule rgw-index {
 type replicated
 min_size 1
 max_size 10
 step take index
 step chooseleaf firstn 0 type rack
 step emit
}

예를 들어 1.75x 스토리지 오버헤드가 있는 다른 호스트의 OSD와 호스트 손실을 허용하기 위해 8+6 EC 인코딩의 일반 CRUSH 규칙은 호스트 4개로 분할됩니다.

rule ecpool-86
{
    ...
    step take default class hdd
    step choose indep 4 type host
    step choose indep 4 type osd
    step emit
}

이는 4개의 호스트 간에 최대 16개의 OSD로 나뉩니다. 그러나 재조정할 다른 호스트가 있는 경우 OSD가 표시되지 않으므로 제대로 작동하지 않습니다.

CRUSH MSR 규칙은 일반 규칙의 첫 번째 접근 방식과 달리 깊이 있는 첫 번째 접근 방식을 사용하여 위의 문제를 해결합니다. 각 선택 사항에 대해 규칙은 다음 선택을 계속하기 전에 모든 단계를 재귀적으로 대체합니다. 위의 사용 사례는 다음 MSR 규칙에 충족할 수 있습니다.

rule ecpool-86
{
    type msr_indep
    ...
    step take default class hdd
    step choosemsr 4 type host
    step choosemsr 4 type osd
    step emit
}

out으로 표시된 OSD는 사용 가능한 추가 항목이 있는 한 다른 호스트에 비례하여 다시 매핑됩니다.

crush-osds-per-failure-domain 값을 사용하여 erasure-code 프로필을 생성하면 일반 CRUSH 규칙 대신 CRUSH MSR 규칙 유형이 생성됩니다. 일반 CRUSH 규칙은 OSD가 없는 경우 이전 단계를 재시도할 수 없습니다. 그러나 MSR 규칙은 OSD가 발생할 때 이전 단계를 모두 재시도하여 실패 도메인당 여러 OSD를 지원합니다.

예를 들어 1.75x 스토리지 오버헤드가 있는 다른 호스트의 OSD와 호스트 손실을 허용하기 위해 8+6 EC 인코딩의 일반 CRUSH 규칙은 호스트 4개로 분할됩니다.

rule ecpool-86
{
    ...
    step take default class hdd
    step choose indep 4 type host
    step choose indep 4 type osd
    step emit
}

이는 4개의 호스트 간에 최대 16개의 OSD로 나뉩니다. 그러나 재조정할 다른 호스트가 있는 경우 OSD가 표시되지 않으므로 제대로 작동하지 않습니다.

CRUSH MSR 규칙은 일반 규칙의 첫 번째 접근 방식과 달리 깊이 있는 첫 번째 접근 방식을 사용하여 위의 문제를 해결합니다. 각 선택 사항에 대해 규칙은 다음 선택을 계속하기 전에 모든 단계를 재귀적으로 대체합니다. 위의 사용 사례는 다음 MSR 규칙에 충족할 수 있습니다.

rule ecpool-86
{
    type msr_indep
    ...
    step take default class hdd
    step choosemsr 4 type host
    step choosemsr 4 type osd
    step emit
}

out으로 표시된 OSD는 사용 가능한 추가 항목이 있는 한 다른 호스트에 비례하여 다시 매핑됩니다.