2.4. Ceph Object Gateway 고려 사항
스토리지 클러스터를 설계할 때 고려해야 할 또 다른 중요한 측면은 스토리지 클러스터가 하나의 데이터 센터 사이트에 있는지 또는 여러 데이터 센터 사이트를 대상으로 하는지를 결정하는 것입니다. 다중 사이트 스토리지 클러스터는 장기적인 정전, 경사, 허리케인, 범람 또는 기타 재해와 같은 지리적으로 분산된 페일오버 및 재해 복구의 이점을 제공합니다. 또한 다중 사이트 스토리지 클러스터에는 클라이언트 애플리케이션을 사용 가능한 가장 가까운 스토리지 클러스터로 보낼 수 있는 활성 활성 구성이 있을 수 있습니다. 이는 콘텐츠 제공 네트워크에 적합한 스토리지 전략입니다. 데이터를 가능한 한 클라이언트에 가깝게 배치하는 것이 좋습니다. 이는 스트리밍 4k 비디오와 같은 처리량 집약적인 워크로드에 중요합니다.
Red Hat은 Ceph의 스토리지 풀을 생성하기 전에 영역, 영역 그룹 및 영역 이름을 식별하는 것이 좋습니다. 영역 이름을 표준 이름 지정 규칙으로 사용하는 일부 풀 이름 앞에 추가합니다.
추가 리소스
- 자세한 내용은 Red Hat Ceph Storage Object Gateway 가이드 의 다중 사이트 구성 및 관리 섹션을 참조하십시오.
2.4.1. 관리 데이터 스토리지
Ceph Object Gateway는 인스턴스의 영역 구성에 정의된 일련의 풀에 관리 데이터를 저장합니다. 예를 들어 후속 섹션에서 설명하는 버킷, 사용자, 사용자 할당량 및 사용량 통계는 Ceph 스토리지 클러스터의 풀에 저장됩니다. 기본적으로 Ceph Object Gateway는 다음 풀을 생성하여 기본 영역에 매핑합니다.
-
.rgw.root -
.default.rgw.control -
.default.rgw.meta -
.default.rgw.log -
.default.rgw.buckets.index -
.default.rgw.buckets.data -
.default.rgw.buckets.non-ec
.default.rgw.buckets.index 풀은 Ceph Object Gateway에서 버킷이 생성된 후에만 생성되는 반면 .default.rgw.buckets.data 풀은 버킷에 업로드된 후 생성됩니다.
CRUSH 규칙 세트와 배치 그룹 수를 설정할 수 있도록 이러한 풀을 수동으로 생성하는 것이 좋습니다. 일반적인 구성에서 Ceph Object Gateway의 관리 데이터를 저장하는 풀은 종종 동일한 CRUSH 규칙 세트를 사용하고 관리 데이터에 10개의 풀이 있으므로 배치 그룹을 더 적게 사용합니다.
Red Hat은 .rgw.root 풀과 서비스 풀이 동일한 CRUSH 계층 구조를 사용하고 CRUSH 규칙에서 실패 도메인으로 노드를 사용하는 것이 좋습니다. Red Hat은 데이터 지속성을 위해 복제 를 사용하는 것이 좋습니다. .rgw.root 풀 및 서비스 풀에는 삭제되지 않는 것이 좋습니다.
mon_pg_warn_max_per_osd 설정은 기본적으로 풀에 너무 많은 배치 그룹을 할당하는 경우 경고합니다. 요구 사항과 하드웨어의 기능에 맞게 값을 조정할 수 있습니다. 여기서 n 은 OSD당 최대 PG 수입니다.
mon_pg_warn_max_per_osd = n
.rgw.root 를 포함한 서비스 풀의 경우 풀 계산기당 Ceph 배치 그룹(PG)의 권장 PG 수는 Ceph OSD당 대상 PG보다 훨씬 적습니다. 또한 계산기 4단계에서 Ceph OSD의 수가 설정되어 있는지 확인합니다.
가비지 컬렉션은 OMAP 대신 일반 RADOS 개체와 함께 .log 풀을 사용합니다. 향후 릴리스에서는 더 많은 기능이 .log 풀에 메타데이터를 저장합니다. 따라서 Red Hat은 .log 풀에 NVMe/SSD Ceph OSD를 사용하는 것이 좋습니다.
.rgw.root 풀
Ceph Object Gateway 구성이 저장된 풀입니다. 여기에는 영역, 영역 그룹 및 영역이 포함됩니다. 규칙에 따라 해당 이름이 영역 이름 앞에 추가되지 않습니다.
서비스 풀
서비스 풀은 서비스 제어, 가비지 수집, 로깅, 사용자 정보 및 사용과 관련된 오브젝트를 저장합니다. 규칙에 따라 이러한 풀 이름에는 풀 이름 앞에 영역 이름이 있습니다.
-
.ZONE_NAME.rgw.control: 제어 풀입니다. -
.ZONE_NAME.log: 로그 풀에는 create, read, update, delete와 같은 모든 버킷, 컨테이너 및 오브젝트 작업의 로그가 포함됩니다. -
.ZONE_NAME.rgw.buckets.index: 이 풀은 버킷의 인덱스를 저장합니다. -
.ZONE_NAME.rgw.buckets.data:이 풀은 버킷의 데이터를 저장합니다. -
.ZONE_NAME.rgw.meta: 메타데이터 풀은 user_keys 및 기타 중요한 메타데이터를 저장합니다. -
.ZONE_NAME.meta:users.uid: 사용자 ID 풀에는 고유한 사용자 ID 맵이 포함되어 있습니다. -
.ZONE_NAME.meta:users.keys: 키 풀에는 각 사용자 ID에 대한 액세스 키와 시크릿 키가 포함되어 있습니다. -
.ZONE_NAME.meta:users.email: 이메일 풀에는 사용자 ID와 연결된 이메일 주소가 포함되어 있습니다. -
.ZONE_NAME.meta:users.swift: Swift 풀에는 사용자 ID에 대한 Swift 하위 사용자 정보가 포함되어 있습니다.
추가 리소스
- 자세한 내용은 Red Hat Ceph Storage Object Gateway 가이드 의 풀 정보 섹션을 참조하십시오.
- 자세한 내용은 Red Hat Ceph Storage Storage Strategies Guide 를 참조하십시오.
2.4.2. 인덱스 풀
Ceph Object Gateway와 함께 사용할 OSD 하드웨어를 선택하는 경우 인덱스 풀을 저장하기 위해 SSD 또는 NVMe 드라이브 중 하나 이상의 고성능 드라이브가 있는 OSD 노드를 사용할 수 있습니다. 이는 버킷에 많은 오브젝트가 포함된 경우 특히 중요합니다.
Bluestore를 실행하는 Red Hat Ceph Storage의 경우 별도의 풀이 아닌 NVMe 드라이브를 block.db 장치로 배포하는 것이 좋습니다.
Ceph Object Gateway 인덱스 데이터는 개체 맵(OMAP)에만 작성됩니다. BlueStore의 OMAP 데이터는 OSD의 block.db 장치에 있습니다. NVMe 드라이브가 HDD OSD의 block.db 장치로 작동하고 인덱스 풀이 HDD OSD에서 지원되면 인덱스 데이터는 block.db 장치에만 기록됩니다. block.db partition/lvm이 블록의 4%에 올바르게 크기가 조정되는 한, 이 구성은 BlueStore에 필요한 모든 것입니다.
Red Hat은 인덱스 풀에 대한 HDD 장치를 지원하지 않습니다. 지원되는 구성에 대한 자세한 내용은 Red Hat Ceph Storage: 지원되는 구성 문서를 참조하십시오.
인덱스 항목은 약 200바이트의 데이터이며, rocksdb 에서 OMAP로 저장됩니다. 이는 간단한 양의 데이터이지만 Ceph Object Gateway를 사용하면 수십 또는 수백 만 개의 개체가 단일 버킷에 포함될 수 있습니다. 인덱스 풀을 고성능 스토리지 미디어의 CRUSH 계층 구조에 매핑함으로써 버킷에 많은 오브젝트가 포함된 경우 대기 시간이 크게 단축됩니다.
프로덕션 클러스터에서 일반적인 OSD 노드에는 OSD 저널과 동일한 물리 드라이브에 별도의 파티션 또는 논리 볼륨을 사용하는 인덱스 풀 또는 block.db 장치를 저장하기 위한 최소 하나의 SSD 또는 NVMe 드라이브가 있습니다.
2.4.3. 데이터 풀
데이터 풀은 Ceph Object Gateway가 특정 스토리지 정책에 대한 오브젝트 데이터를 저장하는 위치입니다. 데이터 풀은 서비스 풀의 PG 수를 줄이는 대신 PG(배포 그룹)를 완전히 보완합니다. 복제보다 훨씬 효율적이므로 데이터 풀에 삭제 코딩을 사용하는 것이 중요하며 데이터 지속성을 유지하면서 용량 요구 사항을 크게 줄일 수 있습니다.
삭제 코딩을 사용하려면 삭제 코드 프로필을 생성합니다. 자세한 내용은 Red Hat Ceph Storage Storage Strategies Guide 의 Erasure Code Profiles 섹션을 참조하십시오.
풀을 생성한 후에는 프로필을 변경할 수 없으므로 올바른 프로필을 선택하는 것이 중요합니다. 프로필을 수정하려면 다른 프로필을 사용하여 새 풀을 생성하고 이전 풀에서 새 풀로 오브젝트를 마이그레이션해야 합니다.
기본 구성은 두 개의 데이터 청크와 하나의 인코딩 청크로, 하나의 OSD만 손실될 수 있습니다. 복원력이 높은 경우 더 많은 수의 데이터 및 인코딩 청크를 고려하십시오. 예를 들어 일부 대규모 시스템은 8개의 데이터 청크와 3 인코딩 청크를 사용하므로 데이터 손실 없이 3개의 OSD가 실패할 수 있습니다.
각 데이터 및 인코딩 청크는 최소한 다른 노드나 호스트에 저장됩니다. 소규모 스토리지 클러스터의 경우 더 많은 수의 데이터 및 인코딩 청크에 대해 최소 CRUSH 장애 도메인으로 rack 을 사용할 수 없습니다. 따라서 데이터 풀은 일반적으로 host와 함께 별도의 CRUSH 계층 구조를 최소 CRUSH 장애 도메인으로 사용하는 것이 일반적입니다. Red Hat은 최소 장애 도메인으로 host를 권장합니다. 코드 청크 삭제가 동일한 호스트 내의 Ceph OSD에 저장되는 경우 실패한 저널 또는 네트워크 카드와 같은 호스트 실패로 인해 데이터가 손실될 수 있습니다.
데이터 풀을 생성하려면 풀 이름, PG 및 PGP의 수, 삭제 데이터 지속성 방법, 삭제 코드 프로필, 규칙 이름을 사용하여 ceph osd pool create 명령을 실행합니다.
2.4.4. 데이터 추가 풀
data_extra_pool 은 삭제 코딩을 사용할 수 없는 데이터를 위한 것입니다. 예를 들어 다중 파트 업로드를 사용하면 여러 부분의 동영상과 같은 큰 오브젝트를 업로드할 수 있습니다. 이 부분은 삭제 코딩 없이 먼저 저장해야 합니다. 삭제 코딩은 부분적인 업로드가 아닌 전체 오브젝트에 적용됩니다.
풀 계산기당 PG(배치 그룹)는 data_extra_pool 에 대한 풀당 PG 수를 더 적게 권장합니다. 그러나 PG 수는 서비스 풀과 동일한 PG 수이고 버킷 인덱스 풀과 동일합니다.
데이터 추가 풀을 생성하려면 풀 이름, PG 및 PGP 수, 복제된 데이터 지속성 방법 및 규칙 이름을 사용하여 ceph osd pool create 명령을 실행합니다. 예를 들면 다음과 같습니다.
# ceph osd pool create .us-west.rgw.buckets.non-ec 64 64 replicated rgw-service
