AI

Ceph 성능 튜닝 방안

Gadget 2025. 10. 31. 09:25

Ceph, 그 압도적인 성능을 깨우다: 세부 튜닝 가이드

Ceph는 방대한 스케일과 놀라운 유연성을 자랑하는 오픈소스 분산 스토리지 시스템입니다. 하지만 Ceph를 단순히 설치하는 것만으로는 그 잠재력을 100% 발휘하기 어렵습니다. 수많은 컴포넌트와 복잡한 상호작용 속에서 최적의 성능을 끌어내기 위해서는 섬세한 튜닝이 필수적입니다.

이 블로그 게시물에서는 Ceph의 성능을 극한으로 끌어올릴 수 있는 다양한 튜닝 방안들을 심층적으로 다룰 것입니다. 각 섹션에서는 특정 컴포넌트나 영역에 초점을 맞춰, 이론적인 배경과 함께 실제 적용 가능한 튜닝 파라미터 및 그 효과를 설명합니다.

1. Ceph 성능 튜닝의 핵심 원리 이해

Ceph 성능 튜닝을 시작하기 전에, 몇 가지 핵심 원리를 이해하는 것이 중요합니다.

  • 병목 현상 식별: 튜닝의 시작은 항상 병목 현상을 식별하는 것입니다. CPU, RAM, 네트워크, 디스크 I/O 중 어느 부분이 제한 요인이 되는지 파악해야 효율적인 튜닝이 가능합니다. iostat, netstat, ceph -s, ceph health detail 등의 도구를 활용하여 시스템 상태를 지속적으로 모니터링해야 합니다.
  • 워크로드 특성: Ceph를 사용하는 애플리케이션의 워크로드 특성(랜덤/순차, 작은/큰 파일, 읽기/쓰기 비율)을 명확히 알아야 합니다. 워크로드에 따라 튜닝 방향이 달라집니다.
  • 트레이드오프: 성능 튜닝은 종종 트레이드오프를 수반합니다. 예를 들어, 강력한 일관성을 유지하면 쓰기 성능이 저하될 수 있고, 복제 수를 늘리면 안정성은 높아지지만 스토리지 효율성이 떨어집니다. 목표하는 성능 지표와 시스템 요구사항을 고려하여 균형점을 찾아야 합니다.
  • 점진적 적용 및 테스트: 튜닝 파라미터를 한 번에 많이 변경하지 않고, 하나씩 변경한 후 충분히 테스트하여 그 효과를 검증해야 합니다. 이는 문제 발생 시 원인을 쉽게 파악할 수 있도록 돕습니다.

2. 하드웨어 최적화: 성능 튜닝의 기초

아무리 소프트웨어 튜닝을 잘해도 기본적인 하드웨어 스펙이 부족하면 원하는 성능을 얻기 어렵습니다.

  • CPU: Ceph OSD(Object Storage Daemon)는 많은 CPU 리소스를 사용합니다. 특히 저널링, 데이터 압축, 해싱, 네트워크 처리 등에서 CPU 사용량이 높습니다.
  • 권장: OSD 당 1-2 코어 이상 할당을 권장하며, 고성능 워크로드의 경우 더 많은 코어가 필요할 수 있습니다.
  • 팁: NUMA(Non-Uniform Memory Access) 아키텍처 환경에서는 OSD 프로세스와 해당 디스크가 동일한 NUMA 노드에 할당되도록 구성하여 메모리 접근 지연을 줄이는 것이 좋습니다.
  • RAM: OSD는 캐싱, OSD맵 관리, 복제 버퍼링 등을 위해 상당한 RAM을 사용합니다.
  • 권장: OSD 당 최소 8GB 이상, 고성능 환경에서는 16GB 이상을 권장합니다. 특히 BlueStore를 사용하고 bluestore_cache_size_ssd 또는 bluestore_cache_size_hdd와 같은 캐시 파라미터를 높게 설정할 경우 RAM 요구량이 증가합니다.
  • 네트워크: Ceph는 데이터 복제, 마이그레이션, 클라이언트 통신 등 모든 작업이 네트워크를 통해 이루어지므로, 네트워크 대역폭과 지연 시간은 매우 중요합니다.
  • 권장: OSD 노드 간에는 최소 10GbE 이상의 전용 네트워크를 사용하는 것이 이상적입니다. 25GbE, 40GbE, 100GbE로 업그레이드하면 훨씬 높은 성능을 얻을 수 있습니다.
  • 팁:
  • 분리된 네트워크: Public Network (클라이언트 통신)와 Cluster Network (OSD 간 복제 및 통신)를 물리적으로 분리하면 병목 현상을 줄이고 보안을 강화할 수 있습니다.
  • NIC 본딩/팀 구성: 여러 NIC를 묶어 대역폭을 늘리고 페일오버를 구현합니다.
  • Jumbo Frames: MTU 값을 9000으로 설정하여 네트워크 오버헤드를 줄입니다. 모든 네트워크 장비 (스위치, NIC)에서 설정해야 합니다.
  • Flow Control: 혼잡 제어를 위해 스위치 포트에서 Flow Control을 활성화하는 것을 고려할 수 있습니다.
  • 스토리지 미디어: Ceph 성능의 가장 큰 영향을 미치는 요소 중 하나입니다.
  • OSD 디스크:
  • NVMe/SSD: 고성능 워크로드(랜덤 I/O, 낮은 지연 시간 요구)에 필수적입니다.
  • HDD: 대용량 순차 워크로드에 적합하지만, 랜덤 I/O 성능은 제한적입니다.
  • 저널/WAL/DB 디스크 (BlueStore):
  • BlueStore는 RocksDB를 사용하여 메타데이터(WAL, DB)를 저장합니다. OSD 디스크와 같은 미디어를 사용할 수도 있지만, 성능 향상을 위해 별도의 고속 미디어를 사용하는 것이 좋습니다.
  • WAL (Write Ahead Log): 쓰기 성능에 매우 중요합니다. NVMe 또는 고성능 SSD에 WAL을 할당하면 쓰기 성능을 크게 향상시킬 수 있습니다.
  • DB: 메타데이터 캐싱 및 검색에 사용됩니다. WAL과 마찬가지로 고성능 미디어에 할당하는 것이 유리합니다.
  • 권장: NVMe SSD에 WAL/DB를 할당하는 것이 BlueStore 성능 튜닝의 핵심 중 하나입니다.
  • OS 디스크: Ceph 프로세스 자체의 I/O는 많지 않지만, 운영체제 및 로깅을 위해 충분히 빠른 디스크를 사용해야 합니다.

3. 소프트웨어 및 OS 수준 튜닝

운영체제 수준의 설정은 Ceph의 성능에 직접적인 영향을 미칩니다.

3.1. 커널 튜닝 (/etc/sysctl.conf)

  • 네트워크 버퍼 크기 증가: 고성능 네트워크 환경에서 네트워크 드롭을 줄이고 처리량을 늘립니다. 
    net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.core.rmem_default = 268435456
net.core.wmem_default = 268435456
net.core.optmem_max = 268435456
net.ipv4.tcp_rmem = 4096 87380 268435456
net.ipv4.tcp_wmem = 4096 65536 268435456
net.ipv4.tcp_mem = 268435456 268435456 268435456
net.ipv4.tcp_notsent_lowat = 16384 # TCP send buffer low water mark
  • TCP Keepalive 설정: 연결 유지 및 비정상 종료 감지 시간을 조정합니다. 
    net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15
  • 파일 디스크립터 제한 증가: OSD는 많은 파일 디스크립터를 사용합니다. 
    fs.file-max = 262144
  • SWAP 비활성화 또는 최소화: Ceph는 디스크 I/O가 중요하므로, SWAP 사용은 성능 저하를 유발합니다. 
    vm.swappiness = 1 # 거의 사용하지 않도록 설정, 0은 완전히 비활성화
  • swapoff -a 명령으로 즉시 비활성화하고, /etc/fstab에서 관련 라인을 주석 처리하여 영구적으로 비활성화할 수 있습니다.
  • Transparent Huge Pages (THP) 비활성화: THP는 일반적으로 대규모 메모리 애플리케이션에 도움이 되지만, Ceph와 같은 특정 워크로드에서는 오히려 성능 저하를 유발할 수 있습니다. 
    echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled
echo 'never' > /sys/kernel/mm/transparent_hugepage/defrag
  • /etc/rc.local 또는 systemd 서비스를 통해 부팅 시 자동 적용되도록 설정하는 것이 좋습니다.

3.2. 디스크 I/O 스케줄러

  • CFQ (Completely Fair Queuing) vs. Noop/Deadline: OSD 디스크에 따라 최적의 I/O 스케줄러가 다릅니다.
  • NVMe/SSD: noop 또는 none (최신 커널에서는 none이 기본)이 가장 좋습니다. 디스크 자체에 내장된 스케줄러가 더 효율적입니다.
  • HDD: deadline 또는 mq-deadline (멀티큐 환경)이 일반적으로 좋습니다. 순차 I/O를 최적화하여 처리량을 늘리는 데 도움이 됩니다.
  • 설정 방법: 
    echo none > /sys/block/<device>/queue/scheduler
  • udev 규칙을 사용하여 부팅 시 자동 적용되도록 설정할 수 있습니다.

3.3. 파일 시스템

  • XFS: Ceph OSD를 위한 기본적이고 권장되는 파일 시스템입니다. 대규모 파일과 디렉토리 처리에 효율적이며, 안정성이 높습니다.
  • 마운트 옵션: noatime (액세스 시간 업데이트 비활성화)을 사용하여 I/O 오버헤드를 줄입니다. 
    /dev/sdX /var/lib/ceph/osd/ceph-X xfs defaults,noatime 0 0

3.4. Chrony/NTP 동기화

  • 클러스터 내 모든 노드의 시간이 정확하게 동기화되어야 합니다. 시간 불일치는 OSD 간 통신 오류, 복제 문제, 심각한 경우 데이터 일관성 문제로 이어질 수 있습니다. chrony 또는 ntpd를 사용하여 시간 동기화를 필수로 설정합니다.

4. Ceph 설정 파일 튜닝 (ceph.conf)

Ceph의 성능 튜닝에 있어 ceph.conf 파일은 가장 핵심적인 역할을 합니다.

4.1. [global] 섹션

  • osd_pool_default_size: 데이터 복제본 수. 높은 안정성을 위해 3을 권장하지만, 스토리지 효율성과 쓰기 성능에 영향을 미칩니다. (예: osd_pool_default_size = 3)
  • osd_pool_default_min_size: 쓰기 가능한 최소 복제본 수. (예: osd_pool_default_min_size = 2)
  • osd_crush_update_on_start: OSD 시작 시 CRUSH 맵을 업데이트할지 여부. 대규모 클러스터에서는 false로 설정하여 부팅 시간 단축. (예: osd_crush_update_on_start = false)
  • mon_osd_max_op_age: OSD 작업이 너무 오래 걸리면 경고를 발생시키는 시간. (예: mon_osd_max_op_age = 30)

4.2. [osd] 섹션 (BlueStore 전용)

BlueStore는 Ceph의 최신 스토리지 엔진으로, 기존 FileStore보다 훨씬 높은 성능을 제공합니다. 따라서 BlueStore 튜닝은 Ceph 성능 튜닝의 핵심입니다.

  • 블루스토어 캐시 튜닝:
  • bluestore_cache_size_ssd / bluestore_cache_size_hdd: NVMe/SSD 기반 OSD와 HDD 기반 OSD에 할당할 캐시 크기입니다. 데이터 블록 캐싱에 사용되며, RAM에 저장됩니다.
  • 권장: OSD 당 1GB ~ 4GB (워크로드에 따라 더 높게 설정 가능). RAM이 충분하다면 더 많은 캐시를 할당하여 읽기 성능을 높일 수 있습니다. (예: bluestore_cache_size_ssd = 4G)
  • bluestore_rocksdb_cache_size: RocksDB의 블록 캐시 크기입니다. 메타데이터 읽기 성능에 중요합니다. RAM에 저장됩니다.
  • 권장: OSD 당 512MB ~ 2GB. (예: bluestore_rocksdb_cache_size = 1G)
  • bluestore_throttle_bytes / bluestore_throttle_deferred_bytes: OSD 내에서 쓰기 작업을 제한하는 바이트 수. 너무 낮으면 성능 병목, 너무 높으면 메모리 사용량 증가.
  • 팁: 초기에는 기본값을 사용하고, ceph daemon osd.X perf dump 명령으로 throttle_op_bluestore_deferred_bytes와 같은 지표를 모니터링하며 조정합니다.
  • 블루스토어 압축:
  • bluestore_compression_mode: none, snappy, zlib, lz4, zstd 등. 워크로드와 CPU 리소스에 따라 선택합니다. snappy는 CPU 사용량이 낮고 합리적인 압축률을 제공하여 널리 사용됩니다. zstd는 더 높은 압축률을 제공하지만 CPU 사용량이 높습니다.
  • bluestore_compression_min_blob_size / bluestore_compression_max_blob_size: 압축을 적용할 최소/최대 블록 크기. 작은 블록에 압축을 적용하면 오버헤드가 더 클 수 있습니다.
  • 블루스토어 WAL/DB 설정 (별도 디바이스 사용 시):
  • bluestore_wal_path / bluestore_db_path: WAL 및 DB를 위한 별도의 디바이스 경로를 지정합니다. 이 경로들은 OSD 초기화 시 ceph-volume을 통해 설정됩니다.
  • 팁: ceph-volume lvm create --osd-id <id> --data <data_dev> --block.wal <wal_dev> --block.db <db_dev>
  • 블루스토어 동기화 간격:
  • bluestore_fsync_on_flush: 쓰기 작업 후 디스크 동기화를 강제할지 여부. true는 안정성을 높이지만 성능을 저하시킬 수 있습니다.
  • bluestore_commit_interval: WAL에 커밋되는 간격. 너무 길면 데이터 손실 위험 증가, 너무 짧으면 오버헤드 증가. (예: bluestore_commit_interval = 5s)
  • OSD 스케줄러 튜닝:
  • osd_op_queue: OSD가 처리할 작업 큐의 유형을 지정합니다. wpq (Workload Priority Queue)가 기본이며, 워크로드 우선순위 지정에 좋습니다. mclock_scheduler는 더 세밀한 QOS (Quality of Service) 제어를 제공합니다.
  • osd_op_num_shards / osd_op_num_threads_per_shard: 작업 큐 샤드 수 및 샤드당 스레드 수. OSD가 CPU 코어를 효율적으로 사용하도록 돕습니다.
  • 팁: 클러스터 규모와 CPU 코어 수에 따라 조정합니다. (예: osd_op_num_shards = 8, osd_op_num_threads_per_shard = 2)
  • osd_max_write_size: 한 번의 쓰기 작업으로 디스크에 전송되는 최대 데이터 크기. 너무 크면 지연 시간 증가, 너무 작으면 오버헤드 증가. (예: osd_max_write_size = 64M)
  • osd_client_op_priority / osd_recovery_op_priority: 클라이언트 작업과 복구 작업의 우선순위를 조정합니다. 복구 중에도 클라이언트 성능을 유지하려면 osd_client_op_priority를 높게 설정합니다. (기본 63, 1)
  • ms_bind_ipv4 / ms_bind_ipv6: Ceph 서비스가 특정 IP 주소에 바인딩되도록 합니다. 여러 네트워크 인터페이스가 있는 경우 유용합니다. (예: ms_bind_ipv4 = 192.168.100.10)
  • ms_bind_port_min / ms_bind_port_max: Ceph 서비스가 사용할 포트 범위를 제한합니다. (예: ms_bind_port_min = 6800, ms_bind_port_max = 7100)

4.3. [mon] 섹션

  • mon_data_size_warn: 모니터 데이터 디렉토리 크기가 이 값을 초과하면 경고 발생. (예: mon_data_size_warn = 10G)
  • mon_osd_down_out_interval / mon_osd_down_in_interval: OSD가 down 상태로 감지된 후 out으로 표시되는 시간 및 in으로 돌아오는 시간. 클러스터 안정성과 복구 시간에 영향. (예: mon_osd_down_out_interval = 600, mon_osd_down_in_interval = 900)

4.4. [mgr] 섹션

  • Ceph Manager는 클러스터 상태 및 메트릭 수집에 중요합니다. 특별한 성능 튜닝 파라미터는 없지만, dashboard 모듈 등을 통해 성능 모니터링에 활용됩니다.

5. Pool 및 Placement Group (PG) 튜닝

Ceph Pool과 PG 설정은 클러스터의 성능과 효율성에 직접적인 영향을 미칩니다.

  • PG 수 (pg_num, pgp_num): 가장 중요한 튜닝 파라미터 중 하나입니다.
  • pg_num: Pool 생성 시 지정하는 PG의 초기 개수입니다.
  • pgp_num: Placement Group for Placement (PGP) 수입니다. OSD 간 데이터 배포를 담당하며, pg_num과 동일하게 설정하는 것이 일반적입니다.
  • 너무 적으면: OSD 간 데이터 불균형, OSD 장애 시 복구 오버헤드 증가, 성능 저하.
  • 너무 많으면: 모니터 및 OSD의 메모리 사용량 증가, OSD맵 관리 오버헤드 증가, 복구 시간 증가.
  • 권장 계산식: (OSD_수 * 100) / 복제본_수로 시작하여, 2의 제곱수로 올림합니다. (예: 100 OSD, 3 복제본 -> (100 * 100) / 3 = 3333.3 -> 4096 PG)
  • 팁: PG 수는 생성 후 늘릴 수 있지만 줄이는 것은 어렵습니다. 신중하게 결정해야 합니다. ceph osd pool create ... --pg_num <num> --pgp_num <num>
  • 크러쉬(CRUSH) 맵:
  • Failure Domain: CRUSH 맵은 데이터를 물리적으로 분리된 장애 도메인(랙, 호스트 등)에 분산하여 내결함성을 제공합니다. 적절한 CRUSH 맵 설정은 데이터 가용성과 함께 복구 성능에도 영향을 미칩니다.
  • Replication/Erasure Coding: 복제본 수 또는 Erasure Coding 프로파일 설정은 스토리지 효율성, 성능, 내결함성 간의 트레이드오프를 결정합니다.
  • 복제본 (Replicated Pool): 쓰기 성능이 우수하지만 스토리지 효율성은 낮습니다 (예: 3 복제본 -> 3배 용량 필요).
  • 이레이저 코딩 (Erasure Coded Pool): 스토리지 효율성이 높지만 쓰기 성능이 낮고 복구 과정이 복잡합니다. 아카이브, 오브젝트 스토리지에 적합합니다.

6. 클라이언트 측 튜닝

Ceph 클라이언트(RBD, CephFS, S3/Swift API)에서도 성능을 최적화할 수 있는 설정들이 있습니다.

6.1. RBD (Ceph Block Device)

  • 캐싱:
  • rbd_cache = true: 클라이언트 측에서 RBD 캐싱을 활성화합니다.
  • rbd_cache_size: 캐시 크기를 지정합니다. (예: rbd_cache_size = 256M)
  • rbd_cache_max_dirty: 캐시에 저장될 수 있는 더티(아직 디스크에 쓰이지 않은) 데이터의 최대 크기. (예: rbd_cache_max_dirty = 128M)
  • rbd_cache_target_dirty: 캐시가 이 값에 도달하면 쓰기 작업을 시작합니다.
  • rbd_cache_writeback_timeout: 더티 데이터가 캐시에서 유지되는 최대 시간.
  • rbd_concurrent_management_ops: RBD 관리를 위한 동시 작업 수. (예: rbd_concurrent_management_ops = 20)
  • rbd_op_timeout: RBD 작업의 타임아웃 값. (예: rbd_op_timeout = 60)
  • 커널 RBD 모듈 (KVM/QEMU):
  • cache=writeback: VM 게스트에서 writeback 캐싱을 사용하도록 설정.
  • aio=threads: 비동기 I/O를 사용하도록 설정.

6.2. CephFS (Ceph File System)

  • client_cache_size_limit: 클라이언트 측 캐시 크기 제한.
  • client_snap_caps_per_client: 클라이언트가 가질 수 있는 스냅샷 기능 제한.
  • mount -o 옵션:
  • noatime: 액세스 시간 업데이트 비활성화.
  • lazytime: 액세스/수정 시간 업데이트 지연.
  • rw: 읽기/쓰기 모드.
  • _netdev: 네트워크 장치로 처리하여 부팅 시 네트워크 연결을 기다립니다.

6.3. S3/Swift (RGW - Rados Gateway)

  • RGW 캐싱: RGW는 자체적으로 Memcached나 Redis를 사용하여 메타데이터 캐싱을 지원합니다. 이를 통해 S3/Swift 요청 처리 속도를 높일 수 있습니다.
  • rgw_enable_cache
  • rgw_cache_uri
  • rgw_cache_memory_limit
  • RGW worker 스레드 수:
  • rgw_num_frontends: RGW 인스턴스 수.
  • rgw_thread_pool_size: 각 RGW 인스턴스의 워커 스레드 수.
  • RGW SSL 오프로딩: 대규모 TLS 트래픽이 발생하는 경우, 하드웨어 SSL 오프로더를 사용하거나 NGINX와 같은 프록시에서 SSL을 종료하여 RGW의 CPU 부하를 줄일 수 있습니다.
  • RGW Civetweb 튜닝:
  • rgw_max_client_req: 최대 동시 클라이언트 요청 수.
  • rgw_num_requests_to_dispatch: 한 번에 디스패치할 요청 수.

7. 모니터링 및 문제 해결 도구

튜닝은 모니터링 없이는 불가능합니다. 지속적인 모니터링을 통해 튜닝의 효과를 검증하고 새로운 병목 현상을 식별해야 합니다.

  • ceph -s / ceph status: 클러스터의 전반적인 상태 요약.
  • ceph health detail: 자세한 클러스터 상태 및 경고 메시지.
  • ceph osd tree: OSD 상태 및 계층 구조.
  • ceph osd dump: OSD 설정 및 상태.
  • ceph osd perf dump: 각 OSD의 성능 카운터. (예: ceph daemon osd.0 perf dump)
  • ceph mon stat / ceph mon dump: 모니터 상태.
  • ceph pg dump: PG 상태 및 분포.
  • ceph pg stat: PG 통계.
  • ceph quorum_status: 모니터 쿼럼 상태.
  • ceph tell mon.* mon_status: 특정 모니터의 상세 상태.
  • ceph tell osd.* bench: OSD 벤치마크 테스트 (주의: 클러스터에 부하를 줍니다).
  • ceph config show <daemon_type>.<id>: 특정 데몬의 현재 설정 확인.
  • iostat -xz 1: 디스크 I/O 통계.
  • netstat -s / sar -n DEV: 네트워크 통계.
  • top / htop: CPU, RAM 사용량.
  • dstat / grafana / prometheus: 시계열 데이터 기반의 고급 모니터링 솔루션. ceph-mgr의 prometheus 모듈과 grafana를 연동하면 Ceph 클러스터의 모든 메트릭을 시각화하여 쉽게 추이를 파악할 수 있습니다.

8. 결론

Ceph 성능 튜닝은 단일 설정 변경으로 마법처럼 성능이 향상되는 것이 아니라, 워크로드 특성을 이해하고, 하드웨어 및 소프트웨어 스택 전반에 걸쳐 체계적으로 접근해야 하는 지속적인 과정입니다.

이 가이드에서 제시된 튜닝 방안들은 시작점을 제공하지만, 여러분의 특정 환경과 워크로드에 맞춰 최적의 설정을 찾아나가는 것은 오직 실험과 측정을 통해서만 가능합니다. 항상 변경 사항을 기록하고, 벤치마크 툴(예: fio, rados bench)을 사용하여 튜닝 전후 성능을 비교하며, 모니터링을 통해 시스템의 건강 상태를 주시하는 것을 잊지 마십시오.

Ceph는 방대한 가능성을 가진 스토리지 시스템이며, 올바른 튜닝을 통해 여러분의 인프라에서 그 압도적인 성능을 깨울 수 있을 것입니다. Happy Tuning!

'AI'의 다른글

  • 현재글Ceph 성능 튜닝 방안

관련글

티스토리툴바