2장. CRUSH 관리
CRUSH(Controlled Replication Underxtensible Hashing) 알고리즘은 컴퓨팅 데이터 스토리지 위치에 따라 데이터를 저장하고 검색하는 방법을 결정합니다.
충분히 발전된 기술은 매직과 구별할 수 없습니다. | ||
| -- Arthur C. Clarke | ||
2.1. CRUSH 소개
스토리지 클러스터의 CRUSH 맵은 CRUSH 계층 구조 내의 장치 위치와 Ceph가 데이터를 저장하는 방법을 결정하는 각 계층에 대한 규칙을 설명합니다.
CRUSH 맵에는 하나 이상의 노드 계층과 leaves가 포함되어 있습니다. Ceph에서 "buckets"라고 하는 계층의 노드는 해당 유형에 정의된 스토리지 위치 집계입니다. 예를 들어 행, 랙, 섀시, 호스트 및 장치입니다. 계층 구조의 각 리프는 스토리지 장치 목록에 있는 스토리지 장치 중 하나로 본질적으로 구성됩니다. 리프는 항상 하나의 노드 또는 "bucket"에 포함됩니다. CRUSH 맵에는 CRUSH가 데이터를 저장하고 검색하는 방법을 결정하는 규칙 목록도 있습니다.
클러스터에 OSD를 추가할 때 CRUSH 맵에 스토리지 장치가 추가됩니다.
CRUSH 알고리즘은 장치별 가중치 값에 따라 데이터 개체를 스토리지 장치에 분배하여 균일한 확률 분배를 적용합니다. CRUSH는 관리자가 정의하는 계층적 클러스터 맵에 따라 오브젝트 및 해당 복제본 또는 삭제-코딩 청크를 배포합니다. CRUSH 맵은 사용 가능한 스토리지 장치와 규칙에 대해 포함하는 논리 버킷과 규칙을 사용하는 각 풀을 확장함으로써 나타냅니다.
오류 도메인 또는 성능 도메인에서 배치 그룹을 OSD에 매핑하기 위해 CRUSH 맵은 생성된 CRUSH 맵의 유형에 따라 계층적 버킷 유형 목록을 정의합니다. 버킷 계층 구조를 생성하는 목적은 장애 도메인 또는 성능 도메인 또는 둘 다에 의해 리프 노드를 분리하는 것입니다. 장애 도메인에는 호스트, 섀시, 랙, 전력 분산 장치, pod, 행, 방, 데이터 센터가 포함됩니다. 성능 도메인에는 특정 구성의 장애 도메인 및 OSD가 포함됩니다. 예를 들어 SSD, SAS는 SSD 저널, SATA 드라이브 등으로 구동합니다. RHCS 3에서 장치에는 hdd,ssd 및 nvme 와 같은 클래스의 개념이 더 빠르게 장치 클래스를 사용하여 CRUSH 계층 구조를 빌드하도록 합니다.
OSD를 나타내는 리프 노드를 제외하고 나머지 계층 구조는 임의적이며 기본 유형이 요구 사항에 맞지 않는 경우 고유한 요구 사항에 따라 정의할 수 있습니다. CRUSH 맵 버킷 유형을 조직의 하드웨어 이름 지정 규칙에 수정하고 물리적 하드웨어 이름을 반영하는 인스턴스 이름을 사용하는 것이 좋습니다. 이름 지정 방법을 사용하면 클러스터를 보다 쉽게 관리하고 OSD 또는 기타 하드웨어 결함과 관리자가 호스트 또는 기타 하드웨어에 대한 원격 또는 물리적 액세스가 필요할 때 문제를 해결할 수 있습니다.
다음 예에서 버킷 계층 구조에는 4개의 리프 버킷(osd 1-4), 두 개의 노드 버킷(호스트much)과 1개의 랙 노드(rack 1)가 있습니다.
리프 노드는 CRUSH 맵 시작 부분에 장치 목록 아래에 선언된 스토리지 장치를 반영하므로 이를 버킷 인스턴스로 선언할 필요가 없습니다. 계층 구조의 두 번째 가장 낮은 버킷 유형은 일반적으로 장치를 집계합니다. 즉, 스토리지 미디어를 포함하는 컴퓨터이며 관리자가 "node", "server", "server", "host", "machine" 등과 같은 설명하려는 모든 용어를 사용합니다. 밀도가 높은 환경에서는 카드당 및 섀시당 여러 호스트/노드를 확인하는 것이 점점 더 일반적입니다. 예를 들어, 노드가 실패하는 경우 카드 또는 섀시를 가져와야 하는 경우 카드 및 섀시도 카드 및 섀시를 고려해야 합니다. 이로 인해 수많은 호스트/노드와 OSD가 다운될 수 있습니다.
버킷 인스턴스를 선언할 때 유형을 지정하고, 고유한 이름을 문자열로 지정하고, 음수 정수로 표시된 선택적 고유 ID를 할당하고, 항목의 총 용량 또는 기능에 대한 가중치를 지정하고, straw 와 같은 버킷 알고리즘을 지정하고, 일반적으로 0 으로 해시 알고리즘 rjenkins1 을 반영합니다. 버킷에는 하나 이상의 항목이 있을 수 있습니다. 항목은 노드 버킷 또는 leaves로 구성될 수 있습니다. 항목에 항목의 상대적 가중치를 반영하는 가중치가 있을 수 있습니다.
2.1.1. 동적 데이터 배치
Ceph 클라이언트 및 Ceph OSD는 모두 CRUSH 맵과 CRUSH 알고리즘을 사용합니다.
- Ceph 클라이언트: CRUSH 맵을 Ceph 클라이언트에 배포하면 Ceph 클라이언트가 OSD와 직접 통신할 수 있습니다. 즉, Ceph 클라이언트는 단일 장애 지점, 성능 병목 현상, 중앙 집중식 조회 서버의 연결 제한 및 스토리지 클러스터 확장성에 대한 물리적 제한으로 작동할 수 있는 중앙 집중식 오브젝트 조회 테이블을 방지합니다.
- Ceph OSD: CRUSH 맵을 Ceph OSD에 배포하면 OSD에서 복제, 백필링 및 복구를 처리할 수 있습니다. 즉, Ceph OSD는 Ceph 클라이언트를 대신하여 오브젝트 복제본(또는 코딩 청크)의 스토리지를 처리합니다. 또한 Ceph OSD에서 클러스터의 재조정(백분)을 재조정하고 오류를 동적으로 복구할 수 있을 만큼 충분한 정보를 알고 있음을 의미합니다.
2.1.2. 실패 도메인 설정
여러 오브젝트 복제본 또는 M pastsure 코딩 청크가 있으면 데이터 손실을 방지하는 데 도움이 되지만 고가용성을 처리하는 것만으로는 충분하지 않습니다. CRUSH는 Ceph Storage 클러스터의 기본 물리적 조직을 반영하여 장치 오류의 영향을 받을 수 있는 관련 소스를 모델링할 수 있습니다. 클러스터 토폴로지를 클러스터 맵으로 인코딩하면 CRUSH 배치 정책은 원하는 의사 임의 배포를 유지 관리하는 동안 다양한 장애 도메인에서 오브젝트 복제본 또는 삭제 코딩 청크를 분리할 수 있습니다. 예를 들어 동시 오류를 처리할 수 있는 가능성을 해결하려면 데이터 복제본 또는 삭제 코딩 청크가 서로 다른 보류, 랙, 전원 공급 장치, 컨트롤러 또는 물리적 위치를 사용하는 장치에 있는지 확인하는 것이 바람직할 수 있습니다. 이를 통해 데이터 손실을 방지하고 클러스터가 저하된 상태에서 작동할 수 있습니다.
2.1.3. 성능 도메인 설정
Ceph는 여러 계층을 지원하여 한 가지 유형의 하드웨어 성능 프로필을 다른 유형의 하드웨어 성능 프로필과 분리할 수 있습니다. 예를 들어 CRUSH는 하드 디스크 드라이브용 계층 구조와 SSD용 다른 계층 구조를 생성할 수 있습니다. 성능 도메인- 기본 하드웨어의 성능 프로파일을 고려하는 기능은 점점 더 널리 사용되고 있으며, 서로 다른 성능 특성을 지원할 필요성으로 인해 점점 더 널리 사용되고 있습니다. 운영 체제는 두 개 이상의 루트 유형 버킷이 있는 CRUSH 맵일 뿐입니다. 사용 사례 예는 다음과 같습니다.
- VM: OpenStack, CloudStack, ProxMox 또는 OpenNebula와 같은 클라우드 플랫폼에 대한 백엔드로 사용되는 Ceph 호스트는 XFS가 동시에 저널링 및 쓰기를 위해 고성능 SSD가 분할된 XFS 드라이브의 가장 안정적이고 성능이 뛰어난 파일 시스템을 사용하는 경향이 있습니다. 일관된 성능 프로필을 유지하려면 이러한 사용 사례는 CRUSH 계층 구조에서 유사한 하드웨어를 집계해야 합니다.
- 오브젝트 스토리지 : S3 및 Swift 인터페이스에 대한 오브젝트 스토리지 백엔드로 사용되는 Ceph 호스트는 VM에 적합하지 않을 수 있는 SATA 드라이브와 같은 저렴한 스토리지 미디어를 활용할 수 있으며, VM당 비용이 절감되는 한편, 클라우드 플랫폼의 볼륨 및 이미지를 저장하기 위한 더 경제적인 스토리지 호스트를 분리할 수 있습니다. HTTP는 오브젝트 스토리지 시스템의 병목 현상이 되는 경향이 있습니다.
- 콜드 스토리지: 콜드 스토리지(Fold storage)를 위해 설계된 시스템(Fold storage-infrequentrequentrequentrequently accessed data) 또는 성능 요구 사항을 완화하여 데이터 검색 기능을 설계하면 비용이 적게 드는 스토리지 미디어 및 삭제 코드를 활용할 수 있습니다. 그러나 코딩은 약간의 추가 RAM과 CPU가 필요할 수 있으므로 개체 스토리지 또는 VM에 사용되는 호스트의 RAM 및 CPU 요구 사항이 다릅니다.
-
SSD 지원 풀: SSD는 비용이 많이 들고 하드 디스크 드라이브보다 큰 이점을 제공합니다. SSD에는 검색 시간이 없으며 높은 처리량을 제공합니다. 클러스터는 저널링을 위해 SSD를 사용하는 것 외에도 SSD 지원 풀을 지원할 수 있습니다. 일반적인 사용 사례에는 고성능 SSD 풀이 포함됩니다. 예를 들어, Ceph Object Gateway의
.rgw.buckets.index풀을 SATA 드라이브 대신 SSD에 매핑할 수 있습니다. Red Hat은 인덱스 풀에 대한 HDD 장치를 지원하지 않습니다. 지원되는 구성에 대한 자세한 내용은 Red Hat Ceph Storage: 지원되는 구성 문서를 참조하십시오.
RHCS 3 이상 릴리스에서 CRUSH 맵은 장치 클래스의 개념을 지원합니다. Ceph는 스토리지 장치의 측면을 검색하고 hdd,ssd 또는 nvme 와 같은 클래스를 자동으로 할당할 수 있습니다. 그러나 CRUSH는 이러한 기본값으로 제한되지 않습니다. 예를 들어 CRUSH 계층 구조를 사용하여 다양한 유형의 워크로드를 분리할 수도 있습니다. 예를 들어 SSD는 저널 또는 write-ahead 로그, 버킷 인덱스 또는 원시 오브젝트 스토리지에 사용할 수 있습니다. CRUSH는 ssd-bucket-index 또는 ssd-object-storage 와 같은 다양한 장치 클래스를 지원할 수 있으므로 Ceph는 다양한 워크로드에 동일한 스토리지 미디어를 사용하지 않으므로 성능을 예측하고 일관되게 조정할 수 있습니다.
2.1.3.1. RHCS 3 및 later에서 다른 장치 클래스 사용
RHCS 3에서 성능 도메인을 생성하려면 장치 클래스 및 단일 CRUSH 계층 구조를 사용합니다. CLI를 사용하여 RHCS 2와 동일한 방식으로 OSD를 CRUSH 계층에 추가하기만 하면 됩니다. 다음 작업을 수행합니다.
각 장치에 클래스를 추가합니다. 예:
# ceph osd crush set-device-class <class> <osdId> [<osdId>] # ceph osd crush set-device-class hdd osd.0 osd.1 osd.4 osd.5 # ceph osd crush set-device-class ssd osd.2 osd.3 osd.6 osd.7
그런 다음 장치를 사용할 규칙을 만듭니다.
# ceph osd crush rule create-replicated <rule-name> <root> <failure-domain-type> <class> # ceph osd crush rule create-replicated cold default host hdd # ceph osd crush rule create-replicated hot default host ssd
마지막으로 규칙을 사용하도록 풀을 설정합니다.
ceph osd pool set <poolname> crush_rule <rule-name> ceph osd pool set cold_tier crush_rule cold ceph osd pool set hot_tier crush_rule hot
RHCS 3 이상을 사용하면 CRUSH 맵을 수동으로 편집할 필요가 없습니다.
