bcache 대 dm-cache: 리눅스에서의 SSD 캐싱

SSD는 빠르지만 기가바이트당 가격이 비쌉니다. HDD는 저렴하지만 속도가 느립니다. 리눅스는 이 두 가지를 결합할 수 있는 두 가지 커널 수준 도구인 bcache와 dm-cache를 제공합니다. 두 도구 모두 SSD를 대용량 HDD 앞에 투명한 캐시로 사용하지만, 아키텍처, 설정 요구 사항, 그리고 가장 뛰어난 성능을 발휘하는 환경이 다릅니다.

bcache의 작동 원리

Bcache는 2013년 6월 출시된 리눅스 커널 3.10 버전부터 포함되어 있습니다. 블록 레이어에서 작동하므로 UUID를 지원하는 모든 파일 시스템과 호환됩니다.

내부적으로 bcache는 하이브리드 B+ 트리/로그 구조를 사용합니다. SSD 저장 공간을 지우기 블록 경계에 맞춰 정해진 크기의 버킷(128KB~2MB)으로 분할합니다. 이를 통해 무작위 쓰기 작업을 순차적 쓰기로 변환하여 쓰기 증폭을 줄이고 SSD 수명을 연장합니다. 4MB를 초과하는 순차 I/O 작업은 자동으로 캐시를 우회하여, SSD가 가장 큰 가치를 발휘하는 무작위 액세스 패턴에 집중할 수 있도록 합니다.

또한 bcache는 SSD 지연 시간을 실시간으로 모니터링합니다. 읽기 지연 시간이 2ms를 초과하거나 쓰기 지연 시간이 20ms를 넘으면, 캐시 장치가 병목 현상이 되는 것을 방지하기 위해 트래픽을 제한합니다.

설정

설치 bcache-tools을 설치한 후, 백업 장치와 캐시 장치를 포맷하십시오:

make-bcache -B /dev/sdb          # format HDD as backing device
make-bcache -C /dev/sdc          # format SSD as cache device
echo <UUID> > /sys/block/bcache0/bcache/attach   # attach cache

실행 시 튜닝은 /sys/block/bcache<N>/bcache/ sysfs 인터페이스를 통해 수행되며, 여기서 캐싱 모드, 순차 I/O 임계값 및 지연 시간 목표를 조정할 수 있습니다. RAID 어레이의 경우 --data-offset 를 사용하여 스트라이프 너비에 맞춰 정렬하십시오.

주의할 점: 설정 과정은 데이터 손실을 동반합니다. 두 장치 모두 bcache 타깃으로 포맷되어야 하므로, 기존 파일 시스템을 먼저 지우지 않고는 bcache를 추가할 수 없습니다. 또한 bcache 장치는 생성 후 크기를 조정할 수 없습니다.

성능

Bcache의 쓰기 통합 기능 덕분에 강력한 무작위 쓰기 성능을 보여줍니다. 벤치마크 결과, 일반 SSD 단독 사용 시 12,200 IOPS에 비해 약 18,500의 무작위 4K 쓰기 IOPS를 기록했습니다. 적절한 하드웨어를 사용하면 무작위 읽기 처리량은 약 1,000,000 IOPS에 달할 수 있습니다.

암호화된 워크로드의 경우, 기본 드라이브를 개별적으로 암호화하는 대신 /dev/bcache<N> 장치 위에 dm-crypt 레이어를 적용하는 것이 좋습니다. 이는 bcache가 암호화 전에 여전히 쓰기 작업을 통합할 수 있기 때문에 일반적으로 더 나은 성능을 제공합니다.

dm-cache의 작동 원리

dm-cache는 기존 논리 볼륨 위에 위치하는 Device Mapper 타깃입니다. dm-cache는 원본 장치(HDD), 캐시 장치(SSD 또는 NVMe), 블록 위치와 더티 상태를 추적하는 메타데이터 장치라는 세 가지 하위 장치를 사용합니다. 기본 캐시 정책은 smq(Stochastic Multi-Queue)로, 혼합 워크로드에서 자주 사용되는 데이터를 식별합니다.

주요 장점: dm-cache는 기존 데이터를 파괴하지 않고 가동 중인 LVM 볼륨 위에 레이어링할 수 있습니다. 또한 표준 LVM 명령어를 사용하여 크기를 조정할 수 있습니다.

LVM을 이용한 설정

dm-cache를 구성하는 실용적인 방법은 lvmcache. 수동 dmsetup 설정이 가능하지만 오류가 발생하기 쉽고 재부팅 시 유지되지 않습니다. LVM 방식:

1. HDD와 SSD 모두에 물리적 볼륨(PV)을 생성합니다.
2. 두 PV를 하나의 볼륨 그룹(VG)에 추가합니다.
3. 세 개의 논리 볼륨을 생성합니다: 데이터 저장용(HDD) 하나, 캐시용(SSD) 하나, 메타데이터용(SSD) 하나.
4. 캐시 및 메타데이터 LV를 결합하여 캐시 풀을 만듭니다:
   lvconvert --type cache-pool --poolmetadata <meta_lv> <cache_lv>
5. 풀을 소스(origin)에 연결합니다:
   lvconvert --type cache --cachepool <pool_lv> <data_lv>

주의할 점: 파일 시스템을 UUID가 아닌 /dev/mapper/ 경로를 통해 마운트해야 하며, UUID로는 마운트하지 마십시오. UUID로 마운트하면 캐시 계층을 우회하여 원본 장치에 직접 접근할 수 있습니다.

성능 및 메모리

90/10 읽기/쓰기 Zipf 워크로드 하의 쓰기 후 캐시(writeback) 모드에서, dm-cache는 약 193 MB/s의 읽기 속도와 대략 21 MB/s의 쓰기 속도를 달성했습니다. 또 다른 벤치마크에서, 100GB HDD를 10GB NVMe 파티션으로 캐싱했을 때 무작위 쓰기 IOPS가 118에서 798로 증가했습니다.

대가는 메모리입니다. dm-cache의 메타데이터 오버헤드는 블록 크기에 따라 달라집니다. 512바이트 블록 크기의 경우 캐시 100GB당 16GB 이상의 RAM을 소모할 수 있습니다. 이를 4,096바이트로 늘리면 메모리 사용량이 100GB당 약 2GB로 줄어듭니다. 평균 I/O 크기에 가까운 블록 크기를 선택하고(64KB가 합리적인 시작점입니다), 32KB에서 1GB 범위 내에서 64섹터(32KB)의 배수가 되도록 설정하십시오.

메타데이터는 FLUSH 또는 FUA 쓰기 작업이 수행될 때마다, 또는 최소한 초당 한 번씩 플러시됩니다. 고가용성을 위해 단일 장애 지점을 방지할 수 있도록 메타데이터 장치를 미러링하십시오.

캐싱 모드

bcache와 dm-cache 모두 동일한 핵심 캐싱 모드를 지원합니다. 선택에 따라 성능과 데이터 안전성 모두에 영향을 미칩니다.

두 도구 모두에서 Writethrough가 안전한 기본 설정입니다. Writeback은 더 빠르지만 실질적인 위험을 수반합니다. 플러시되지 않은 데이터를 보유한 상태에서 SSD가 고장 나면 해당 데이터는 영구적으로 손실되며 파일 시스템이 손상될 수 있습니다. 중복 SSD가 있거나 가끔 발생하는 데이터 손실을 감수할 수 있는 경우에만 Writeback을 사용하십시오.

bcache 대 dm-cache: 어떤 것을 사용할까

새 시스템을 처음부터 구축하고 가능한 최고의 무작위 I/O 성능을 원할 때는 bcache를 사용하십시오. 이는 데이터베이스 및 VM 스토리지와 같은 쓰기 집약적 워크로드와 무작위 쓰기 성능 저하가 심각한 RAID 6 어레이에 더 적합한 선택입니다.

이미 가동 중인 서버에 캐싱 기능을 추가해야 할 때는 dm-cache를 사용하십시오. LVM과의 통합 덕분에 다운타임이나 데이터 마이그레이션 없이 캐시를 연결할 수 있습니다. 이는 읽기 작업이 많은 워크로드나, 스토리지 크기를 실시간으로 조정하거나 재구성할 수 있는 유연성이 필요한 환경에 더 적합합니다.

결론

두 도구 모두 동일한 문제를 해결하지만, 각각 다른 상황에 적합합니다. Bcache는 새로 구축하는 시스템에 있어 성능 면에서 가장 적합한 선택입니다. dm-cache는 기존 LVM 시스템에 있어 실용적인 선택입니다. 어떤 것을 선택하든, SSD의 안정성을 확신할 때까지는 writethrough 모드로 시작하고, 쓰기 성능이 필요할 경우 writeback 모드로 전환하십시오.

SSD 캐싱 구성이 적용된 전용 서버가 필요하시다면, FDC의 전용 서버 옵션을 확인해 보시기 바랍니다.