LIT-ceph-overview

요약

Ceph는 Object, Block, File 스토리지를 하나의 통합 시스템으로 제공하는 오픈소스 분산 스토리지 플랫폼이다. RADOS라는 자율적 분산 객체 저장소를 기반으로 하며, CRUSH 알고리즘으로 중앙 조회 테이블 없이 데이터 위치를 결정한다. 현재 Red Hat/IBM이 활발히 지원하고 있으며, 전 세계 3,000개 이상의 클러스터에서 1 엑사바이트 이상이 배포된 프로덕션 검증 시스템이다.

핵심 포인트

아키텍처 개요

Ceph의 기반은 RADOS (Reliable Autonomic Distributed Object Store) 이다. 모든 데이터는 최종적으로 RADOS 객체로 저장되며, 이 위에 3가지 클라이언트 인터페이스가 구축된다:

RGW (RADOS Gateway): S3/Swift 호환 오브젝트 스토리지
RBD (RADOS Block Device): 스냅샷/클로닝 지원 블록 스토리지
CephFS: POSIX 호환 분산 파일 시스템

이 구조 덕분에 하나의 클러스터에서 오브젝트, 블록, 파일 스토리지를 모두 제공할 수 있다. GlusterFS가 파일 스토리지에 특화된 것과 대조적이다.

4가지 데몬

데몬	역할	비고
MON (Monitor)	클러스터 맵 유지, Paxos 합의	과반수 쿼럼 필요
OSD	데이터 저장, 복제, 복구, 스크러빙	1 OSD ≈ 1 디스크
MGR (Manager)	모니터링, REST API, 플러그인	Dashboard 등 제공
MDS	CephFS 메타데이터 관리	다중 활성 인스턴스 확장 가능

GlusterFS의 3 프로세스(glusterd, glusterfsd, client) 대비 컴포넌트가 더 많지만, 그만큼 각 컴포넌트의 책임이 명확히 분리되어 있다.

CRUSH 알고리즘

CRUSH(Controlled Replication Under Scalable Hashing)는 Ceph의 핵심이다. GlusterFS의 DHT와 유사하게 중앙 조회 테이블 없이 데이터 위치를 결정하지만, 결정적인 차이가 있다:

장애 도메인 인식: 복제본이 서로 다른 호스트, 랙, 데이터센터에 배치되도록 CRUSH Map의 계층 구조를 활용
CRUSH Map: 6개 섹션(Tunables, Devices, Types, Buckets, Rules, Class)으로 구성된 클러스터 토폴로지 맵
디바이스 클래스: HDD, SSD, NVMe 등을 구분하여 데이터 배치 정책에 활용

GlusterFS의 DHT는 32비트 해시 공간의 범위를 brick에 할당하는 비교적 단순한 모델인 반면, CRUSH는 계층적 토폴로지와 장애 도메인을 고려한 더 정교한 배치를 수행한다. 이것이 Ceph가 대규모 클러스터에서 더 유리한 근본 이유이다. [추론]

Cluster Map (5개 맵)

Monitor가 관리하는 클러스터 상태 정보:

Monitor Map — 모니터 노드 정보
OSD Map — OSD 인벤토리, 풀 정의, PG 수
PG Map — Placement Group 상태/사용률
CRUSH Map — 물리적 토폴로지
MDS Map — 메타데이터 서버 상태

Placement Groups (PGs)

PG는 RADOS 객체와 OSD 사이의 간접(indirection) 레이어이다. 객체를 개별적으로 OSD에 매핑하면 관리가 불가능해지므로, 객체들을 PG로 그룹핑한 후 PG를 OSD에 매핑한다. PG ID는 hash(객체명) mod PG수 + 풀ID로 계산된다.

이 간접 레이어 덕분에 OSD 추가/제거 시 모든 객체가 아닌 일부 PG만 이동하면 되어 리밸런싱 비용이 크게 줄어든다.

데이터 보호: 복제 vs Erasure Coding

복제 (Replication):

Acting Set의 Primary OSD가 쓰기를 수락하고 다른 OSD에 복제
R3(3개 복제본) 권장. R2는 장기적으로 데이터 유실 위험
단순하고 빠르지만 스토리지 오버헤드가 큼 (R3 = 3배)

Erasure Coding (EC):

K+M 청크로 분할 (K개 데이터 + M개 패리티)
M개 장애까지 허용하면서 공간 효율적
Tentacle 릴리스의 FastEC로 소규모 I/O 성능이 2~3배 향상
6+2 EC에서 R3의 약 50% 성능, 공간은 33%만 사용

BlueStore (스토리지 백엔드)

Ceph의 현재 기본 OSD 백엔드이다. 이전 FileStore가 로컬 파일 시스템(XFS) 위에서 동작하여 이중 쓰기 문제가 있었던 것과 달리, BlueStore는 로우 블록 디바이스에 직접 쓴다.

RocksDB(BlueFS 위) 로 메타데이터 관리
3단계 디바이스 티어링: WAL(고속) → DB(SSD) → SLOW(HDD)
체크섬 기반 종단 간 데이터 무결성
투명한 압축 (다중 알고리즘)
FileStore 대비 대폭적인 성능 향상

인증: CephX

Kerberos와 유사한 인증 프로토콜이다. 클라이언트가 Monitor에 세션 키를 요청하고, 이를 통해 OSD 접근 티켓을 획득한다. 티켓 만료 기능으로 탈취에 대비한다.

데이터 무결성: Scrubbing

일일 경량 스크럽: 크기/메타데이터 불일치 감지
주간 심층 스크럽: 체크섬 대비 비트 단위 데이터 비교

현재 상태 (2026년 기준)

Ceph는 GlusterFS와 대조적으로 매우 활발하게 개발/지원되고 있다:

최신 안정 릴리스: Tentacle (v20.2.0), 2025년 11월 출시
매년 새로운 안정 릴리스 주기 (3월 목표)
Red Hat/IBM 상용 지원 지속
Proxmox VE, OpenStack, Kubernetes(Rook) 등 주요 플랫폼과 통합
Bloomberg, DigitalOcean, CERN, 320개+ 통신사에서 프로덕션 운영

GlusterFS와의 핵심 차이점

항목	Ceph	GlusterFS
스토리지 타입	Object + Block + File 통합	File 전용
메타데이터	MDS (CephFS용), CRUSH 맵	없음 (DHT)
데이터 배치	CRUSH (계층적 토폴로지, 장애 도메인)	DHT (선형 해싱)
스토리지 백엔드	BlueStore (로우 디바이스 직접)	로컬 FS (XFS 등)
컴포넌트 수	4종 (MON, OSD, MGR, MDS)	3종 (glusterd, glusterfsd, client)
상용 지원	Red Hat/IBM 활발	EOL (2024.12.31)
복잡도	높음 (운영 전문성 필요)	낮음 (상대적으로 단순)
대규모 확장	우수	소중규모에서 우수

나의 생각

Ceph의 통합 스토리지 접근(Object + Block + File)은 인프라 단순화에 큰 장점이다. 하나의 클러스터로 다양한 워크로드를 처리할 수 있어 별도 스토리지 시스템을 운영할 필요가 줄어든다.
CRUSH의 장애 도메인 인식은 단순한 consistent hashing보다 훨씬 정교하다. 랙 단위, 데이터센터 단위로 복제본을 분산시킬 수 있어 물리적 장애에 대한 내성이 높다.
단점은 명확한 운영 복잡도이다. MON, OSD, MGR, MDS 4종 데몬을 관리해야 하고, CRUSH Map 설계, PG 수 튜닝 등 전문 지식이 필요하다. GlusterFS가 "설치해서 바로 쓸 수 있는" 느낌이라면, Ceph는 "제대로 설계해야 성능이 나오는" 시스템이다. [추론]
BlueStore의 로우 디바이스 직접 접근 설계는 성능 측면에서 올바른 방향이다. 파일 시스템 레이어를 제거함으로써 이중 쓰기 문제를 근본적으로 해결했다.
FastEC의 등장으로 Erasure Coding의 실용성이 크게 높아졌다. R3 대비 1/3 공간으로 절반의 성능을 제공하므로, 용량 효율이 중요한 환경에서 현실적인 선택지가 되었다.
GlusterFS가 EOL된 현시점에서, 분산 파일 스토리지가 필요한 새 프로젝트는 Ceph(CephFS)가 사실상 유일한 오픈소스 선택지라고 봐도 무방하다. [추론]

요약