CephFS vs Ceph RBD: 파일 시스템과 블록 스토리지 비교 분석

개요 (Introduction)

Ceph는 고가용성, 확장성, 안정성을 제공하는 오픈소스 분산 스토리지 시스템이다. Ceph는 다양한 방식의 스토리지 인터페이스를 제공하며, 대표적으로 Ceph RBD (RADOS Block Device)와 CephFS (Ceph Filesystem)가 있다. 이 문서에서는 두 기술을 파일 시스템과 블록 스토리지라는 관점에서 비교하고, POSIX 호환성, 데이터 일관성, 마운트 충돌 여부 등 실제 운영환경에서 중요한 개념들을 예시와 함께 쉽게 설명한다.

---

블록 스토리지와 파일 시스템의 개념적 차이

1 구조와 접근 방식 비교

항목	블록 스토리지 (Ceph RBD)	파일 시스템 (CephFS)
접근 단위	블록 단위 (raw 디바이스)	파일 단위
마운트 방식	블록 디바이스 → 파일시스템 생성 후 마운트	파일시스템 자체를 네이티브로 마운트
사용 예시	VM 디스크, 데이터베이스 볼륨	웹 서버 공유 디렉토리, 로그 공유 디렉토리
동시 마운트	불가 (RWO)	가능 (RWX)

2 POSIX 호환성과 파일 잠금(rwx가 가능한 이유)

• POSIX 파일시스템은 표준화된 파일 접근, 퍼미션, 락(locking) 메커니즘을 제공한다.
• CephFS는 완전한 POSIX 호환 파일시스템으로, flock, fcntl, setuid, chmod, chown 등 모든 표준 기능을 지원한다.
• Ceph RBD는 블록 장치일 뿐이므로 POSIX 파일시스템이 아니다. 위에 ext4, xfs 등을 직접 포맷해 사용해야 하며, 동시 마운트 시 파일시스템 충돌 위험이 존재한다.

파일 잠금 예시

int fd = open("test.txt", O_WRONLY);
flock(fd, LOCK_EX); // 배타적 락 적용

setuid 예시

# 소유자 권한으로 실행되도록 설정 (예: 루트 권한 승격)
chmod u+s /usr/bin/some_binary

3 Inode와 메타데이터

• Inode는 파일의 메타데이터(소유자, 권한, 크기 등)를 저장하는 구조체다.
• CephFS는 자체 MDS(Metadata Server)를 통해 Inode를 통합 관리하며 동기화를 유지한다.
• Ceph RBD는 Inode를 직접 가지진 않으며, 위에 포맷된 ext4, xfs 등에서 OS가 관리하게 된다.

4 블록 스토리지가 데이터 액세스 속도 빠른 이유

파일 시스템의 경우 두 개 이상의 서버가 같은 파일 시스템을 마운트했을 때
락을 사용하면, 파일 시스템은 다음과 같은 동작을 수행

1. 락이 설정된 파일에 대해 다른 모든 서버에게 즉시 잠금 정보를 전달
2. 다른 서버가 그 파일에 접근할 때마다 잠금 상태를 확인하는 추가 작업 수행

서버 A가 락을 걸면, 분산 파일 시스템 특성상 모든 마운트한 서버에 락 상태가 전파되고 확인 절차가 추가되므로, 서버 B도 영향을 받아 속도가 느려지게된다.

---

파일 시스템과 블록 스토리지: 실전 구성 예시

1 Ceph RBD 구성 흐름

# 1. RBD 볼륨 생성
rbd create my-volume --size 1024

# 2. 매핑 (block device로 연결)
rbd map my-volume

# 3. 파일 시스템 생성
mkfs.ext4 /dev/rbd0

# 4. 마운트
mount /dev/rbd0 /mnt/rbd

2 CephFS 구성 흐름

# 1. 커널 클라이언트 사용 마운트
mount -t ceph 192.168.0.10:6789:/ /mnt/cephfs -o name=admin,secretfile=/etc/ceph/admin.secret

---

마운트 시 고려해야 할 옵션들

1 파일 시스템 생성 시 옵션 (예: mkfs.ext4)

옵션	설명
-b <블록 크기>	블록 크기 (예: 4096)
-i <inode 비율>	inode당 바이트 수 지정
-m <예약 비율>	루트용 예약 공간 비율 설정 (기본 5%)

mkfs.ext4 -b 4096 -i 16384 -m 1 /dev/rbd0

2 마운트 시 옵션들 (보안/성능/기능)

옵션	설명
defaults	기본 옵션 세트 (rw, suid 등 포함)
ro, rw	읽기 전용 / 읽기쓰기 마운트
noexec	바이너리 실행 방지
nosuid	setuid 비트 무시
nodev	장치 파일 사용 제한
discard	SSD Trim 및 RBD에서 유용
relatime	접근 시간 최소화 (성능 ↑)

mount -o noatime,nosuid,nodev /dev/rbd0 /mnt/rbd

---

AccessMode 차이 (RWO vs RWX)

AccessMode	설명	예시
RWO	하나의 노드에서만 읽기/쓰기 가능 (Ceph RBD 등)	VM 디스크, 단일 DB 볼륨
RWX	여러 노드에서 동시 읽기/쓰기 가능 (CephFS 등)	공유 로그 디렉토리, NFS 대체

---

일관성과 충돌 예시

1 Ceph RBD 충돌 예시

• 서버 A에서 마운트 후 데이터 생성
• 서버 B가 동일 볼륨을 마운트하면, 데이터 손상 및 OS 캐시 충돌 가능

# 서버 A
mount /dev/rbd0 /mnt/rbd
rm /mnt/rbd/test.log

# 서버 B (여전히 파일이 존재하거나 FS 에러 발생 가능)
ls /mnt/rbd

2 CephFS 예시

• 동시 마운트 가능, 파일 잠금도 작동

# 서버 A
flock /mnt/cephfs/myfile -c "echo A writing..."

# 서버 B (락이 걸려 대기 또는 에러 반환)
flock /mnt/cephfs/myfile -c "echo B writing..."

---

결론 요약

항목	Ceph RBD (블록)	CephFS (파일)
접근 단위	블록	파일
AccessMode	RWO	RWX
락 및 충돌 제어	OS 파일시스템에 의존	POSIX 락, MDS 제어
동시 마운트	위험 (데이터 손상 우려)	안전 (공유 및 동기화)
일관성 유지	캐시 불일치 가능	MDS 통해 일관성 유지
기능 확장성	제한적	POSIX 기능 완전 지원 (setuid 등)

---

이 문서는 파일시스템(CephFS)과 블록스토리지(Ceph RBD)의 구조적 차이, POSIX 기능 지원 여부, 실제 사용 시 고려사항 및 마운트 옵션 등을 개념과 코드 예시를 통해 직관적으로 정리하였다. Kubernetes 및 실습 환경에서의 충돌 테스트와 구성은 별도 문서에서 다룰 예정이다.