검색

2.5. CRUSH 계층 구조 개발

download PDF

스토리지 관리자는 Ceph 스토리지 클러스터 및 오브젝트 게이트웨이를 배포할 때 일반적으로 Ceph Object Gateway에는 기본 영역 그룹과 영역이 있습니다. Ceph 스토리지 클러스터에는 기본 풀이 있으므로 기본 CRUSH 계층 구조와 함께 CRUSH 맵과 기본 CRUSH 규칙이 사용됩니다.

중요

기본 rbd 풀은 기본 CRUSH 규칙을 사용할 수 있습니다. Ceph 클라이언트가 클라이언트 데이터를 저장하는 데 기본 규칙 또는 계층을 삭제하지 마십시오.

프로덕션 게이트웨이는 일반적으로 게이트웨이의 사용 및 지리적 위치에 따라 이름이 지정된 사용자 지정 영역, 영역 그룹 및 영역을 사용합니다. 또한 Ceph 스토리지 클러스터에는 CRUSH 계층 구조가 여러 개의 CRUSH 맵이 있습니다.

  • 서비스 풀: 하나 이상의 CRUSH 계층 구조는 서비스 풀 및 잠재적으로 데이터를 위한 것입니다. 서비스 풀에는 .rgw.root 및 영역과 연결된 서비스 풀이 포함됩니다. 서비스 풀은 일반적으로 단일 CRUSH 계층 구조에 속하며 데이터 지속성에 복제를 사용합니다. 데이터 풀은 CRUSH 계층 구조를 사용할 수도 있지만, 일반적으로 이 풀은 데이터 지속성을 위해 삭제 코딩으로 구성됩니다.
  • 인덱스: CRUSH 계층 구조 SHOULD 는 CRUSH 계층 구조가 SSD 또는 NVMe 드라이브와 같은 고성능 미디어에 매핑되는 인덱스 풀에 사용됩니다. 버킷 인덱스는 성능 장애일 수 있습니다. Red Hat은 이 CRUSH 계층 구조에서 SSD 또는 NVMe 드라이브를 사용하는 것이 좋습니다. Ceph OSD 저널에 사용되는 SSD 또는 NVMe 드라이브에서 인덱스의 파티션을 생성합니다. 또한 인덱스는 버킷 분할을 사용하여 구성해야 합니다.
  • 배치 풀: 각 배치 대상의 배치 풀에는 버킷 인덱스, 데이터 버킷, 버킷 추가 기능이 포함됩니다. 이러한 풀은 별도의 CRUSH 계층 구조에 속할 수 있습니다. Ceph Object Gateway는 여러 스토리지 정책을 지원할 수 있으므로 스토리지 정책의 버킷 풀은 IOPS에 최적화된 IOPS, 처리량 최적화 및 용량 최적화와 같은 다양한 사용 사례를 반영하여 다양한 CRUSH 계층 구조와 연관될 수 있습니다. 버킷 인덱스 풀 SHOULD 는 자체 CRUSH 계층 구조를 사용하여 버킷 인덱스 풀을 SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어에 매핑합니다.

2.5.1. CRUSH 루트 생성

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

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

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

다음 예제에서 data0, data 1data2 라는 호스트는 동일한 물리적 호스트를 가리키는 여러 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
}

2.5.2. CRUSH 맵에서 논리 호스트 이름 사용

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-ssddata2-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
}
중요

논리 호스트 이름을 사용하는 경우 OSD 시작 스크립트가 시작 시 실제 호스트 이름을 사용하지 못하도록 다음 설정 중 하나가 Ceph 구성 파일에 있는지 확인합니다. 따라서 CRUSH 맵에서 데이터를 찾지 못합니다.

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 맵이 실제 호스트 이름이 아닌 논리 호스트 이름을 사용할 때 예상 방법 중 하나를 사용하지 않는 경우 Ceph Storage Cluster는 OSD가 실제 호스트 이름에 매핑된다고 가정하고, Ceph Storage Cluster는 CRUSH 맵에서 실제 호스트 이름을 찾을 수 없으며 Ceph Storage 클러스터 클라이언트는 OSD와 해당 데이터를 찾을 수 없습니다.

2.5.3. CRUSH 규칙 생성

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

참고

기본 rbd 풀에서 이 규칙을 사용할 수 있습니다. 다른 풀에서 고객 데이터를 저장하는 데 기본 규칙을 삭제하지 마십시오.

CRUSH 규칙에 대한 자세한 내용은 Red Hat Ceph Storage 7용 Red Hat Ceph Storage Strategies GuideCRUSH 규칙 섹션을 참조하십시오. CRUSH 맵을 수동으로 편집하려면 Red Hat Ceph Storage 7용 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
}
참고

위 예제에서 데이터가 세 번 복제되는 경우 클러스터에 비슷한 개수의 OSD 노드를 포함하는 랙이 3개 이상 있어야 합니다.

작은 정보

복제된 설정 유형은 데이터 지속성, 복제본 수 또는 삭제 코딩과 관련이 없습니다. 복제 만 지원됩니다.

다음 예제에서는 데이터 풀을 저장할 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
}
참고

위 예에서 풀이 기본값보다 많은 수의 데이터 및 인코딩 청크를 사용하여 삭제 코딩을 사용하는 경우 클러스터에 유사한 수의 OSD 노드가 포함된 랙이 있어야 삭제 코딩 청크를 용이하게 합니다. 소규모 클러스터의 경우 이는 실용적이지 않을 수 있으므로 위 예제는 host 를 CRUSH 장애 도메인으로 사용합니다.

다음 예제에서는 인덱스 풀을 저장할 CRUSH 계층 구조의 규칙을 보여줍니다. 이 예에서 루트 인덱스 는 기본 CRUSH 계층 구조 역할을 합니다. rgw-index 를 사용하여 rgw-servicergw-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
}

추가 리소스

  • CRUSH 계층 구조에 대한 자세한 내용은 Red Hat Ceph Storage Storage Strategies GuideCRUSH 관리 섹션을 참조하십시오.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.