13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 스토리지 성능

  • [인프라] OpenStack Ceph 연동 실패 사례와 스토리지 성능 최적화 교훈

    [인프라] OpenStack Ceph 연동 실패 사례와 스토리지 성능 최적화 교훈

    목차

    [인프라] OpenStack Ceph 연동 실패 사례와 스토리지 성능 최적화 교훈

    OpenStack Ceph 연동은 프라이빗 클라우드를 운영할 때 한 번쯤 꼭 마주치는 주제입니다. 저도 홈랩과 실무 환경에서 OpenStack 스토리지 구성을 여러 번 만졌는데요, 처음엔 단순히 연결만 되면 끝일 줄 알았습니다. 그런데 실제로 써보니까 연동 성공과 제대로 빠르게 동작하는 상태는 완전히 다른 이야기더라고요. 특히 볼륨 생성은 되는데 체감이 느리거나, 가상머신 부팅이 들쭉날쭉하거나, 특정 시간대에 I/O가 몰리면 급격히 지연이 커지는 문제를 겪으면 그때부터 삽질이 시작됩니다. 혹시 지금 OpenStack Ceph 연동 이후 성능이 이상하게 답답하다고 느끼고 계신가요?

    여기서 중요한 포인트는, 원인이 Ceph 자체인지 OpenStack 설정인지, 아니면 둘 사이의 연결 방식인지 분리해서 봐야 한다는 점입니다. 이 글에서는 제가 직접 겪었던 OpenStack Ceph 연동 실패 패턴과 해결 방법을 정리했으니, 비슷한 상황이라면 참고하시길 바랍니다.

    OpenStack Ceph 연동 전체 아키텍처 다이어그램

    OpenStack 컴퓨트, 이미지, 블록 스토리지 서비스와 Ceph 클러스터 간 연결 구조를 한눈에 보여주는 아키텍처 이미지입니다.

    왜 OpenStack Ceph 연동에서 성능 문제가 자주 생길까

    쉽게 말해 OpenStack는 서비스를 제공하는 제어 평면(control plane)이고, Ceph는 실제 데이터를 저장하는 분산 스토리지(distributed storage) 역할을 합니다. 많이들 Cinder(신더, 블록 스토리지), Glance(글랜스, 이미지 서비스), Nova(노바, 컴퓨트)가 Ceph의 RBD(RADOS Block Device, 블록 디바이스 인터페이스)를 함께 쓰도록 구성하죠. 구조만 보면 깔끔합니다. 근데 여기서 병목이 생기는 지점이 꽤 많습니다.

    • 인증 설정은 맞는데 풀(pool) 권한이 어긋난 경우
    • 네트워크 분리가 부족해서 클라이언트 트래픽과 복제 트래픽이 섞이는 경우
    • 풀 설계가 서비스 특성과 맞지 않는 경우
    • 하이퍼바이저(hypervisor) 캐시 정책이 애매해서 지연이 커지는 경우
    • 작은 I/O가 많이 발생하는 워크로드를 고려하지 않은 경우

    저도 처음엔 Ceph 최적화라고 하면 OSD(Object Storage Daemon, 오브젝트 스토리지 데몬) 쪽만 보면 된다고 생각했었는데요, 막상 들여다보니 OpenStack 스토리지 설정에서 생기는 비효율이 꽤 컸습니다. 특히 이미지 업로드는 괜찮은데 볼륨 기반 부팅이 유독 느린 경우, 그 원인이 하나가 아니라 여러 레이어에 걸쳐 있는 경우가 많았습니다.

    구성 개념 먼저 정리해보겠습니다

    OpenStack Ceph 연동을 이해할 때는 각 서비스가 어느 풀을 쓰는지부터 정리하면 훨씬 덜 헷갈립니다.

    구성 요소 역할 Ceph 연동 포인트 체크 포인트
    Glance 이미지 저장 RBD 이미지 풀 이미지 업로드/변환 지연
    Cinder 볼륨 제공 RBD 볼륨 풀 볼륨 생성 속도, attach 지연
    Nova 가상머신 부팅 Ceph 백엔드 부트 부팅 시간, I/O 패턴
    Ceph MON/OSD 클러스터 관리/데이터 저장 스토리지 코어 복제 상태, 지연, 균형

    핵심은 이겁니다. OpenStack 스토리지 성능은 단순히 디스크가 빠르냐 느리냐로 끝나지 않습니다. 인증, 네트워크, 풀 설계, 복제 정책(replication policy), 클라이언트 설정이 다 같이 맞물립니다. 그래서 문제를 볼 때도 한 군데만 보면 안 되죠.

    제가 실제로 점검했던 사전 체크리스트

    본격적으로 손대기 전에 저는 항상 아래 순서대로 확인합니다. 이 순서를 안 지키면 괜히 OSD 튜닝만 하다가 시간을 많이 쓰게 되더라고요.

    1. Ceph 클러스터 상태가 HEALTH_OK 또는 경미한 경고 수준인지 확인합니다.
    2. Glance, Cinder, Nova가 각각 어떤 Ceph 사용자와 풀을 쓰는지 정리합니다.
    3. 스토리지 네트워크와 서비스 네트워크가 분리되어 있는지 확인합니다.
    4. 볼륨 생성, 이미지 업로드, 부팅 중 어디가 가장 느린지 구분합니다.
    5. 가상머신 내부 체감 속도와 백엔드 I/O 지표를 따로 봅니다.

    여기서 중요한 포인트! 사용자는 보통 “Ceph가 느리다”라고 말하지만, 실제로는 이미지 복사 경로가 비효율적이거나 캐시 정책이 안 맞아서 그렇게 느끼는 경우도 많습니다. 저도 예전에 이걸 구분 못 해서 하루를 날린 적이 있습니다. OpenStack Ceph 연동에서는 정말 이런 실수가 흔하거든요.

    실전 구현: OpenStack Ceph 연동 기본 점검과 설정

    아래 예시는 개념을 설명하기 위한 일반적인 형태입니다. 배포판이나 자동화 도구에 따라 파일 위치와 세부 항목은 조금 다를 수 있습니다. 그래도 큰 흐름은 비슷합니다.

    1. Ceph 클러스터 상태 확인

    ceph -s
ceph health detail
ceph osd tree
ceph osd df
rbd pool ls

    이 단계에서 저는 먼저 복제 지연이나 OSD 불균형부터 봅니다. 연동 전에 백엔드가 불안정하면 OpenStack 쪽에서 아무리 손봐도 체감이 안 좋아집니다.

    2. Ceph 사용자 권한 확인

    ceph auth list
ceph auth get client.glance
ceph auth get client.cinder
ceph auth get client.nova

    권한이 과하게 넓은 것도 문제지만, 더 자주 보는 건 풀 권한이 어설프게 빠져 있는 경우입니다. 그러면 기능은 되는 것처럼 보여도 특정 작업에서만 실패하거나 지연이 생깁니다.

    3. Cinder 백엔드 확인

    [ceph]
volume_driver = cinder.volume.drivers.rbd.RBDDriver
volume_backend_name = ceph
rbd_pool = volumes
rbd_user = cinder
rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_secret_uuid = YOUR_SECRET_UUID
rbd_flatten_volume_from_snapshot = false
rbd_max_clone_depth = 5
rbd_store_chunk_size = 8

    rbd_max_clone_depth 같은 항목은 운영 방식에 따라 영향을 줄 수 있습니다. 저는 예전에 스냅샷 기반 복제가 누적된 상태를 방치했다가, 특정 볼륨 체인에서 응답이 들쭉날쭉해지는 걸 본 적이 있습니다.

    4. Glance 백엔드 확인

    [glance_store]
default_backend = rbd
stores = rbd
rbd_store_pool = images
rbd_store_user = glance
rbd_store_ceph_conf = /etc/ceph/ceph.conf

    Glance(글랜스, 이미지 서비스)가 Ceph를 바로 쓰도록 해두면 이미지 관리가 단순해집니다. 다만 이미지 업로드와 변환 작업이 많은 환경이라면 여기서도 풀 설계와 I/O 패턴을 꼭 같이 봐야 합니다.

    OpenStack Ceph 연동 설정 흐름과 RBD 풀 구성 이미지

    OpenStack 서비스별로 어떤 Ceph 사용자와 풀을 사용하는지 보여주는 구성 다이어그램입니다.

    실패 사례: OpenStack Ceph 연동은 됐는데 성능이 안 나온 이유

    이제 제가 실제로 겪었던 전형적인 실패 패턴을 말씀드려볼게요. 처음엔 볼륨 생성도 되고 인스턴스도 뜨니까 성공한 줄 알았습니다. 그런데 실제로 써보니까 VM 부팅 시간이 일정하지 않았고, 동시에 여러 작업이 걸리면 체감 지연이 확 올라가더라고요. 여기서부터가 진짜 OpenStack Ceph 연동의 시작이었습니다.

    문제 1. 네트워크를 논리적으로만 나눠놓고 물리적으로는 섞어 썼던 경우

    Ceph는 복제와 복구 트래픽이 발생합니다. 그런데 클라이언트 액세스와 같은 대역을 공유하면 피크 시간에 지연이 커질 수 있습니다. 저도 홈랩에서 처음엔 VLAN만 나누면 충분하겠지 했었는데, 실제로는 업링크 혼잡이 생기면서 체감 성능이 꽤 흔들렸습니다.

    • 증상: 특정 시간대에 볼륨 attach와 부팅 지연 증가
    • 원인: 스토리지 트래픽과 일반 서비스 트래픽 경합
    • 대응: 스토리지 네트워크 경로를 분리하고 혼잡 구간을 줄임

    문제 2. 풀을 나누지 않고 한 곳에 몰아넣은 경우

    이미지, 볼륨, 테스트용 작업이 한 풀에 몰려 있으면 관찰도 어렵고 튜닝 포인트도 흐려집니다. Ceph 최적화는 결국 워크로드 분리가 기본이더라고요.

    • 증상: 어떤 작업이 느린지 구분이 잘 안 됨
    • 원인: 서비스별 I/O 특성 혼재
    • 대응: images, volumes 등 역할 단위로 풀을 분리해 관찰성 확보

    문제 3. 클론과 스냅샷 체인을 너무 방치한 경우

    처음엔 공간 절약 측면에서 좋아 보이는데, 운영 기간이 길어지면 관리 포인트가 늘어납니다. 특히 오래된 이미지 기반으로 파생된 체인이 많아지면, 성능과 운영 복잡도가 같이 올라갈 수 있습니다. OpenStack Ceph 연동 운영에서는 정말 흔한 문제입니다.

    문제 4. 성능 문제를 전부 Ceph 탓으로만 본 경우

    이거 정말 많이 봅니다. 근데 실제로는 하이퍼바이저 캐시 설정, 인스턴스 유형별 디스크 패턴, 백그라운드 작업 영향도 같이 봐야 하거든요. 저도 처음엔 Ceph OSD만 의심했었는데, 나중에 보니 OpenStack 스토리지 경로에서 이미지 변환과 attach 흐름이 더 큰 영향을 준 케이스가 있었습니다.

    ⚠️ 트러블슈팅: 제가 효과를 봤던 점검 순서

    문제가 생기면 아래 순서로 좁혀가면 좋습니다. 무작정 튜닝부터 하지 마세요. 저도 예전엔 그랬다가 더 꼬였습니다.

    1. Ceph 상태 확인
      클러스터 경고, 리밸런싱(rebalancing), 복구 상태를 먼저 확인합니다.
    2. 풀 단위 관찰
      어느 풀이 바쁜지, 이미지와 볼륨 중 어디서 병목이 생기는지 봅니다.
    3. OpenStack 작업별 분리
      이미지 업로드, 볼륨 생성, 인스턴스 부팅을 따로 테스트합니다.
    4. 동시 작업 테스트
      단건 테스트는 괜찮은데 동시성에서 무너지는 경우가 많습니다.
    5. 체인 정리 여부 검토
      오래된 스냅샷/클론 구조가 쌓였는지 확인합니다.
    openstack volume create --size 10 test-volume
openstack server create --flavor m1.small --image test-image --network private test-vm
rbd ls -p volumes
rbd info volumes/test-volume
ceph osd perf

    여기서 ceph osd perf 같은 기본 지표와 OpenStack 작업 시간을 같이 비교해보면 감이 옵니다. 절대적인 숫자보다 언제 느려지는지, 어떤 작업에서 흔들리는지를 보는 게 더 중요합니다.

    OpenStack Ceph 연동 장애 분석용 스토리지 성능 대시보드 이미지

    볼륨 생성과 가상머신 부팅 과정에서 지연이 발생하는 구간을 시각적으로 보여주는 대시보드 이미지입니다.

    Ceph 최적화 관점에서 배운 점

    이번 경험에서 가장 크게 느낀 건, Ceph 최적화는 단일 옵션 몇 개로 끝나는 작업이 아니라는 점이었습니다. 결국 아래 네 가지가 같이 맞아야 하더라고요.

    • 네트워크 분리: 복제와 클라이언트 경로를 명확히 구분
    • 풀 설계: 워크로드 성격에 맞춰 역할 분리
    • 운영 습관: 오래된 스냅샷/클론 체인 방치 금지
    • 관찰성: OpenStack 로그와 Ceph 상태를 함께 확인

    스토리지 성능은 숫자 하나로 판단하기 어렵습니다. 어떤 환경에서는 작은 랜덤 I/O가 문제고, 또 어떤 환경에서는 이미지 배포 흐름이 더 큰 병목이 됩니다. 그래서 저는 요즘은 성능 문제가 나오면 먼저 “이게 Ceph 문제인가, OpenStack 스토리지 경로 문제인가, 아니면 둘 다인가?”부터 구분합니다.

    검증 방법: 무엇을 확인해야 실제로 좋아졌다고 볼 수 있을까

    개선 후에는 꼭 검증이 필요합니다. 그냥 느낌상 빨라진 것 같다고 넘어가면 다음 장애 때 다시 원점으로 돌아갑니다.

    1. 동일한 이미지로 인스턴스 부팅 시간을 여러 번 비교합니다.
    2. 동시에 여러 볼륨을 생성해 지연 패턴이 안정적인지 봅니다.
    3. 이미지 업로드와 볼륨 생성이 겹칠 때도 성능 저하가 과도하지 않은지 확인합니다.
    4. Ceph 클러스터 상태가 테스트 중에도 안정적인지 체크합니다.

    제가 직접 해보니, 단건 테스트보다 동시성 테스트가 훨씬 유의미했습니다. 평소엔 괜찮다가도 작업이 몰리면 바로 티가 나거든요. 드디어 됐다! 싶은 순간도 보통 이 구간을 통과했을 때였습니다.

    openstack server list
openstack volume list
ceph -s
ceph df
rbd du -p volumes

    검증할 때는 결과만 보지 말고, 테스트 중간에 경고가 발생하지 않는지도 꼭 보세요. 여기서 안정적이면 그제야 실제 운영에 올릴 만한 상태라고 판단합니다.

    OpenStack Ceph 연동 최적화 전후 비교 요약 이미지

    최적화 이전과 이후의 지연 안정성 차이를 비교하고, 운영자가 점검해야 할 항목을 요약한 이미지입니다.

    실무적으로 정리하는 OpenStack 스토리지 운영 팁

    항목 권장 접근 피해야 할 패턴
    네트워크 스토리지 경로 분리 복제/서비스 트래픽 혼재
    풀 설계 서비스별 역할 분리 모든 워크로드를 단일 풀에 집중
    운영 관리 스냅샷/클론 주기적 점검 장기간 체인 방치
    검증 방식 동시성 포함 반복 테스트 단건 테스트만으로 판단

    이 표는 제가 나중에 운영 문서로도 정리해둔 기준입니다. 사실 OpenStack Ceph 연동은 한 번 붙이고 끝나는 프로젝트가 아니라, 붙인 뒤부터 운영 품질이 갈리는 영역입니다. 이전 글에서 다뤘던 기본 네트워크 설계와도 연결되는 부분이고, 다음 글에서는 Ceph 모니터링 포인트를 조금 더 깊게 다뤄볼 예정입니다.

    마무리: 연동 성공보다 중요한 건 안정적인 성능입니다

    오늘 정리한 실패 사례의 핵심은 단순합니다. OpenStack Ceph 연동이 되었더라도, 그 상태가 곧 최적 상태는 아니라는 점입니다. 저도 처음엔 연결만 되면 다 끝난 줄 알았는데, 실제 운영에서는 네트워크, 풀 설계, 스냅샷 체인, 작업 동시성까지 다 영향을 주더라고요. 삽질 좀 했습니다. 그래도 이런 과정을 겪고 나니 이제는 문제를 훨씬 빨리 좁힐 수 있게 됐습니다.

    혹시 지금 OpenStack 스토리지 성능 때문에 답답하셨다면, 오늘 내용처럼 어디서 느려지는지 분리해서 보는 것부터 시작해보세요. 그게 가장 현실적인 첫걸음입니다. 그리고 Ceph 최적화는 무조건 큰 튜닝보다, 구조를 바르게 잡는 쪽이 효과가 더 컸습니다. 이 부분은 정말 경험상 그렇습니다.

    연동 성공, 병목 원인 분리, 검증 절차, 운영 팁을 한 장으로 요약한 마무리 인포그래픽입니다.

    정리 FAQ

    Q. OpenStack Ceph 연동 후 가장 먼저 볼 것은 무엇인가요?

    A. Ceph 클러스터 상태와 OpenStack 서비스별 풀/사용자 매핑입니다. 이 두 가지가 기본입니다.

    Q. 스토리지 성능이 느리면 무조건 Ceph 튜닝부터 해야 하나요?

    A. 아닙니다. 네트워크 경합, 풀 분리 부족, 스냅샷 체인 누적, OpenStack 작업 흐름까지 같이 봐야 합니다.

    Q. OpenStack 스토리지 운영에서 가장 실수하기 쉬운 부분은 뭔가요?

    A. 연동 성공을 성능 검증 완료로 착각하는 부분입니다. 꼭 동시성 테스트까지 해보셔야 합니다.

  • [HomeLabs] TrueNAS 파일 시스템 성능 비교: ZFS, Btrfs, ext4 실측 벤치마크

    [HomeLabs] TrueNAS 파일 시스템 성능 비교: ZFS, Btrfs, ext4 실측 벤치마크

    목차

    TrueNAS 파일 시스템 성능 비교: ZFS, Btrfs, ext4 실측 벤치마크

    TrueNAS 파일 시스템 성능 이야기는 생각보다 단순하지 않더라고요. 저도 처음엔 “같은 SSD에 올리면 파일 시스템만 바꿔서 보면 되는 거 아닌가?” 싶었는데, 실제로 파고들어 보니 정말 그렇지 않더라고요. 특히 TrueNAS Scale은 기본 저장소 계층이 사실상 ZFS(OpenZFS, 오픈지에프에스) 중심으로 설계돼 있어서, Btrfs(비트리 에프에스)나 ext4(익스트포)를 TrueNAS 풀(pool, 스토리지 집합) 대체재처럼 다루면 바로 비교가 틀어집니다. 그래서 이번 글은 “TrueNAS에서 ZFS를 써야 하나?”라는 질문에 답하기 위해, 동일한 리눅스 계열 환경에서 ZFS, Btrfs, ext4를 같은 방식으로 벤치마크하고 그 결과를 NAS 성능 관점에서 해석하는 방향으로 정리해보겠습니다.

    제가 홈랩에서 이런 테스트를 할 때 가장 많이 보는 건 절대 수치 하나가 아니라 패턴입니다. 순차 읽기/쓰기, 작은 블록 랜덤 I/O, 스냅샷 이후 쓰기 지연, 체크섬(checksum, 데이터 무결성 검사용 해시) 오버헤드 같은 것들이요. 숫자 한 줄만 보면 쉬워 보이는데, 실제 운영에서는 그 숫자보다 “왜 이런 결과가 나왔는지”를 이해하는 쪽이 훨씬 중요하거든요.

    TrueNAS 파일 시스템 성능 비교를 위한 ZFS, Btrfs, ext4 개요 다이어그램

    TrueNAS 환경에서 ZFS를 기준으로 두고 Btrfs, ext4를 비교하는 전체 구조를 보여주는 개요 이미지입니다.

    TrueNAS 파일 시스템 성능 비교에서 먼저 짚어야 할 전제

    여기서 중요한 포인트가 하나 있습니다. TrueNAS의 저장소 풀은 ZFS 기반으로 다루는 것이 공식 문서 흐름과 기능 구조에 맞습니다. 스냅샷(snapshot, 시점 복제), 스크럽(scrub, 무결성 검사), 데이터셋(dataset, ZFS 하위 파일 시스템), 풀 업그레이드 같은 핵심 기능이 ZFS를 중심으로 설계돼 있거든요. 그래서 TrueNAS 파일 시스템 성능을 논할 때 Btrfs나 ext4를 TrueNAS 내부의 동등한 선택지처럼 비교하면 오해가 생기더라고요.

    쉽게 말해 이렇게 보시면 됩니다.

    • ZFS: TrueNAS의 본체에 가까운 기본 철학입니다.
    • Btrfs: 리눅스에서 ZFS와 비교 대상으로 자주 거론되는 COW(Copy-On-Write, 쓰기 시 새 블록 생성) 파일 시스템입니다.
    • ext4: 기능은 비교적 단순하지만 오버헤드가 낮아서 기준선(baseline)으로 보기 좋은 전통적인 저널링 파일 시스템입니다.

    그래서 이 글의 비교는 “TrueNAS에서 셋 중 하나를 선택한다”가 아니라, ZFS 벤치마크 결과가 왜 다르게 보이는지 이해하기 위한 상대 비교라고 보시면 정확합니다.

    ZFS, Btrfs, ext4를 쉽게 풀어보면

    저도 처음엔 이게 뭔가 싶었는데, 파일 시스템은 결국 “데이터를 어떤 방식으로 쓰고, 보호하고, 복구하느냐”의 차이더라고요.

    파일 시스템 핵심 구조 강점 성능 해석 포인트
    ZFS COW, 체크섬, 풀/데이터셋 통합 무결성, 스냅샷, 복제, 관리성 안전장치가 많아서 쓰기 오버헤드가 생길 수 있음
    Btrfs COW, 서브볼륨(subvolume, 하위 볼륨), 스냅샷 유연성, 리눅스 친화성 워크로드에 따라 COW 비용이 민감하게 드러남
    ext4 저널링(journaling, 메타데이터 기록) 단순함, 폭넓은 호환성 기능 오버헤드가 적어 순수 I/O 기준선으로 좋음

    ZFS는 파일 시스템과 볼륨 매니저(volume manager, 디스크 집합 관리)를 같이 들고 가는 느낌이더라고요. 그래서 스냅샷, 압축(compression, 데이터 압축), 스크럽 같은 기능이 아주 자연스럽게 붙습니다. 대신 메모리와 설계 이해도가 어느 정도 필요한 게 맞습니다.

    Btrfs 성능은 꽤 흥미로운데요. 같은 COW 계열이라도 구현 방식과 운영 습관에 따라 체감이 달라집니다. 스냅샷을 많이 쓰는 환경, 작은 파일이 자주 바뀌는 환경에서는 생각보다 결과가 요동치기도 하더라고요.

    ext4 NAS 구성을 따로 운영해보면, 기능보다 단순성과 예측 가능성이 장점으로 드러나더라고요. 다만 TrueNAS처럼 스토리지 무결성과 스냅샷 자동화까지 한 번에 챙기려는 목적이라면 결국 ZFS 쪽으로 다시 돌아오게 되는 경우가 많습니다.

    벤치마크 설계: 숫자보다 조건 통제가 먼저입니다

    벤치마크는 명령어보다 조건 통제가 더 중요합니다. 제가 직접 해보니 여기서 한 번 삐끗하면 결과가 완전히 엉뚱하게 나와요. 특히 ARC(Adaptive Replacement Cache, ZFS 메모리 캐시), 리눅스 페이지 캐시(page cache, 운영체제 파일 캐시), SSD SLC 캐시 같은 요소가 섞이면 파일 시스템 차이가 아니라 캐시 차이만 보게 되거든요.

    1. 동일한 하드웨어를 사용합니다. CPU, RAM, SSD/HDD, 컨트롤러를 고정합니다.
    2. 각 파일 시스템은 빈 디스크에서 새로 생성합니다.
    3. 같은 마운트 포인트 구조와 같은 테스트 파일 크기를 사용합니다.
    4. 벤치마크 전에 캐시 영향을 최소화합니다.
    5. 순차 읽기/쓰기와 랜덤 읽기/쓰기를 분리해서 봅니다.
    6. 스냅샷 이후 쓰기 성능도 따로 확인합니다.

    테스트 워크로드는 보통 아래 네 가지면 충분합니다.

    • 대용량 순차 읽기
    • 대용량 순차 쓰기
    • 4K 또는 16K 랜덤 읽기/쓰기
    • 동시 접속 환경을 가정한 mixed read/write

    혹시 이런 경험 있으신가요? 같은 장비인데 한 번은 ZFS가 느리고, 다른 날은 ext4가 이상하게 느립니다. 이런 경우 대부분 파일 시스템 문제가 아니라 캐시가 안 지워졌거나 테스트 순서가 꼬인 경우가 많더라고요. 저도 삽질 좀 했습니다 ㅎㅎ

    실전 구현: ZFS, Btrfs, ext4 테스트 환경 만들기

    여기서는 리눅스 셸 기준으로 예시를 잡겠습니다. TrueNAS 본체에서 ext4나 Btrfs를 운영용 풀로 올리는 흐름이 아니라, 동일한 리눅스 계열 테스트 노드에서 상대 비교를 수행하는 방식입니다.

    1. 디스크 확인

    lsblk -o NAME,SIZE,MODEL,FSTYPE,MOUNTPOINT
sudo wipefs -a /dev/sdb
sudo wipefs -a /dev/sdc
sudo wipefs -a /dev/sdd

    테스트용 디스크는 반드시 비워두세요. 기존 시그니처(signature, 디스크 식별 정보)가 남아 있으면 생성 단계에서 꼬일 수 있습니다.

    2. ext4 생성

    sudo mkfs.ext4 -F /dev/sdb
sudo mkdir -p /mnt/bench-ext4
sudo mount /dev/sdb /mnt/bench-ext4

    3. Btrfs 생성

    sudo mkfs.btrfs -f /dev/sdc
sudo mkdir -p /mnt/bench-btrfs
sudo mount /dev/sdc /mnt/bench-btrfs

    4. ZFS 풀 생성

    sudo zpool create bench /dev/sdd
sudo zfs create bench/data
sudo zfs set compression=lz4 bench/data

    ZFS는 풀과 데이터셋을 나눠서 보는 습관이 중요합니다. TrueNAS Scale에서도 운영 관점은 거의 이 사고방식으로 이어집니다.

    TrueNAS 파일 시스템 성능 테스트를 위한 ZFS 풀과 ext4, Btrfs 구성 이미지

    ZFS 풀과 데이터셋, ext4와 Btrfs 마운트 경로를 같은 조건으로 맞춘 테스트 구성 이미지입니다.

    5. fio 작업 파일 준비

    cat > fio-seq-write.fio <<'EOF'
[global]
ioengine=libaio
direct=1
runtime=60
time_based=1
group_reporting=1
size=8G
filename=testfile

[seqwrite]
bs=1M
rw=write
iodepth=32
EOF

    랜덤 I/O도 별도 job 파일로 분리하는 게 좋습니다.

    cat > fio-randrw.fio <<'EOF'
[global]
ioengine=libaio
direct=1
runtime=60
time_based=1
group_reporting=1
size=4G
filename=testfile

[randrw]
bs=4k
rw=randrw
rwmixread=70
iodepth=32
EOF

    6. 각 파일 시스템에서 동일하게 실행

    cd /mnt/bench-ext4 && fio ~/fio-seq-write.fio
cd /mnt/bench-btrfs && fio ~/fio-seq-write.fio
cd /bench/data && fio ~/fio-seq-write.fio

    경로는 배포판과 설정에 따라 달라질 수 있습니다. ZFS 데이터셋 마운트 경로는 zfs list로 먼저 확인하세요.

    ⚠️ 실제로 많이 겪는 문제와 트러블슈팅

    이 섹션은 꼭 넣고 싶었습니다. 벤치마크는 명령어보다 삽질 포인트가 더 중요하거든요.

    • 캐시 때문에 두 번째 결과가 더 잘 나오는 문제
      첫 번째 테스트가 디스크 성능이 아니라 캐시 예열 역할을 해버릴 수 있어요. 테스트 순서를 바꾸면서 여러 번 반복해서 평균적인 경향만 보세요.
    • ZFS 압축 설정을 빼먹는 문제
      TrueNAS에서 많이 쓰는 compression=lz4를 끄고 측정하면 실제 운영과 괴리가 생기더라고요. 반대로 비교를 엄격히 하려면 세 파일 시스템 모두 압축 없는 기준과 운영 기준을 나눠 보시는 게 좋습니다.
    • Btrfs에서 스냅샷 후 쓰기 지연이 체감되는 문제
      작은 파일이 자주 바뀌는 워크로드에서는 COW 영향이 꽤 보일 수 있어요. 로그성 데이터나 VM 이미지 파일은 별도로 성격을 나눠 측정해야 합니다.
    • ext4가 무조건 빠르다고 단정하는 문제
      순수 쓰기만 보면 그럴 때가 있지만, 스냅샷/체크섬/복구 편의성까지 포함하면 운영 총비용(total cost of operation, 실제 운영 부담)은 완전히 다른 얘기입니다.
    • TrueNAS에서 ext4, Btrfs를 그대로 대체재처럼 보는 문제
      이건 비교 관점 자체가 어긋난 경우예요. TrueNAS의 핵심 기능 체인은 ZFS를 전제로 보는 편이 맞습니다.

    저는 예전에 ARC를 충분히 비우지 않은 상태에서 ZFS 벤치마크를 돌리고 “이상하게 읽기가 너무 잘 나오네?” 하고 한참 들여다본 적이 있습니다. 나중에 보니 디스크가 아니라 메모리 읽기였어요. 드디어 원인을 찾았을 때 허탈하더라고요.

    검증과 결과 해석: 무엇을 보면 되는가

    TrueNAS 파일 시스템 성능을 해석할 때는 절대값보다 아래 순서로 보시면 훨씬 정확해요.

    1. 순차 읽기/쓰기: 대용량 미디어, 백업 파일, 아카이브 용도에 가깝습니다.
    2. 랜덤 I/O: VM, DB, 메타데이터가 많은 워크로드와 더 가깝습니다.
    3. 스냅샷 이후 성능 변화: 운영 환경에서 체감이 크게 나는 부분입니다.
    4. 복구와 무결성: 장애 이후 사람을 살리는 기능인지 봐야 합니다.

    제가 실제로 써보는 관점에서 정리하면 보통 이런 경향으로 읽혀요.

    항목 대체로 유리한 쪽 해석
    순차 쓰기 ext4 또는 튜닝된 ZFS 오버헤드가 적은 ext4가 기준선 역할을 잘함
    무결성 검증 ZFS 체크섬과 스크럽 체계가 강점
    스냅샷 관리 ZFS, Btrfs ext4는 기본 구조상 비교 우위가 적음
    운영 일관성 ZFS TrueNAS와의 결합도가 높아 관리 흐름이 자연스러움
    단순한 범용성 ext4 호환성과 익숙함이 장점

    ZFS 벤치마크를 볼 때 흔히 하는 오해가 하나 있어요. ext4보다 숫자가 조금 낮게 나오면 “ZFS가 느리다”라고 바로 결론 내리는 건데요. 사실 ZFS는 체크섬, 스냅샷, 풀 관리, 데이터 무결성 같은 운영 기능까지 포함한 저장소 플랫폼에 가깝습니다. 그래서 같은 MB/s라도 의미가 다르더라고요.

    TrueNAS 파일 시스템 성능과 ZFS 벤치마크 결과를 보여주는 대시보드 이미지

    순차 I/O와 랜덤 I/O 결과를 한눈에 비교하고, TrueNAS 스타일의 스토리지 대시보드 느낌을 함께 담은 이미지입니다.

    반대로 Btrfs 성능은 꽤 상황 의존적이더라고요. 스냅샷 활용과 유연한 운영이 장점이지만, NAS를 장기 보관 스토리지처럼 운영할 때는 ZFS의 관리 모델이 더 편하다고 느끼는 분이 많습니다. 저도 백업과 아카이브는 결국 ZFS 쪽으로 정착했었습니다.

    TrueNAS Scale 기준으로 보면 무엇을 선택해야 하나

    결론은 생각보다 명확해요. TrueNAS Scale을 메인 NAS로 운영한다면, 파일 시스템 선택 문제는 사실상 ZFS를 어떻게 잘 쓸 것인가의 문제에 가깝습니다. ext4와 Btrfs는 비교 대상으로는 유익하지만, TrueNAS 내부 운영 철학까지 합치면 ZFS가 중심입니다.

    • 백업 무결성이 최우선이면 ZFS
    • 스냅샷과 복제가 중요하면 ZFS
    • 순수 리눅스 범용 서버에서 단순 볼륨이 필요하면 ext4도 여전히 강력
    • 리눅스 네이티브 스냅샷 실험용이라면 Btrfs도 재미있음

    여기서 중요한 포인트! TrueNAS 파일 시스템 성능은 결국 “가장 빠른 파일 시스템”이 아니라 “내 데이터와 운영 방식에 맞는 저장소 모델”을 찾는 과정입니다. 숫자만 따라가면 나중에 복구, 스냅샷, 확장성에서 후회하는 경우가 꽤 많더라고요.

    TrueNAS 파일 시스템 성능 관점에서 ZFS, Btrfs, ext4를 요약한 인포그래픽

    ZFS, Btrfs, ext4의 장단점과 추천 사용 시나리오를 한 장으로 정리한 요약 이미지입니다.

    정리와 다음 단계

    이번 비교를 한 줄로 정리하면 이렇습니다. ext4는 기준선, Btrfs는 비교군, TrueNAS의 실전 선택은 ZFS입니다. 저도 처음엔 파일 시스템별 최고 속도만 보려고 했었는데, 실제로 써보니까 NAS는 속도보다 무결성, 스냅샷, 장애 대응이 훨씬 오래 남더라고요.

    다음 단계로는 아래 세 가지를 권합니다.

    1. 같은 SSD 또는 HDD로 직접 fio를 돌려 보세요.
    2. ZFS에서는 압축 on/off, 레코드 크기(recordsize, 블록 크기 정책), 동기 쓰기(sync) 조건을 나눠 보세요.
    3. 실사용 워크로드, 예를 들어 SMB 공유, 백업 저장소, VM 스토어를 따로 측정해 보세요.

    이전 글에서 다룬 스토리지 튜닝 내용이 있다면 같이 보셔도 좋고, 다음 글에서는 TrueNAS Scale에서 ZFS 튜닝: recordsize, compression, ARC를 어떻게 잡아야 하는가를 이어서 다뤄볼 예정입니다. 이 부분이 진짜 체감 성능에 더 크게 영향을 주거든요. 혹시 지금 벤치마크를 준비 중이시라면, 먼저 테스트 조건 통제부터 챙겨보세요. 그게 반은 먹고 들어갑니다. 진짜로요.

  • [Proxmox] ZFS vs Btrfs 비교: Proxmox 홈랩에서의 실측 성능과 데이터 무결성 분석

    [Proxmox] ZFS vs Btrfs 비교: Proxmox 홈랩에서의 실측 성능과 데이터 무결성 분석

    목차

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’ 주인장입니다.

    홈랩을 운영하다 보면 늘 새로운 기술에 대한 갈증과 함께 ‘어떻게 하면 더 효율적이고 안정적으로 운영할 수 있을까?’ 하는 고민에 빠지게 됩니다. 특히 스토리지 선택은 홈랩의 심장이나 다름없죠. Proxmox VE(Virtual Environment)를 사용하시는 분들이라면 한 번쯤은 ZFS와 Btrfs 사이에서 깊은 고민에 빠져보셨을 겁니다. 저도 처음엔 뭐가 뭔지 복잡하고, 어떤 게 제 홈랩 환경에 최적일지 갈피를 잡기 어려웠거든요. 스펙 시트만 봐서는 답이 안 나오더라고요.

    그래서 오늘은 제가 직접 Proxmox 홈랩에서 ZFS와 Btrfs 스토리지를 구성하고 사용해보면서 겪었던 경험과 함께, 실측 성능 (물론 ‘실측’이라는 게 제 개인적인 체감과 간단한 테스트 기준입니다만) 그리고 데이터 무결성 측면에서 두 파일 시스템을 꼼꼼하게 비교 분석해 보려고 합니다. 이 글이 여러분의 홈랩 스토리지 성능 고민과 ZFS, Btrfs 선택에 작은 이정표가 되었으면 좋겠네요. 삽질 끝에 얻은 저의 인사이트를 솔직하게 공유해 드릴게요! 🎉

    ZFS와 Btrfs는 Copy-on-Write(CoW) 개념을 기반으로 하는 최신 파일 시스템입니다. 이미지에서는 두 파일 시스템의 주요 특징과 구조를 시각적으로 비교하여 보여줍니다.

    ZFS와 Btrfs, 대체 뭐가 다른가요? (핵심 개념 파헤치기)

    본격적인 비교에 앞서, 두 파일 시스템의 핵심 개념을 먼저 짚고 넘어가야겠죠? 쉽게 말해 ZFS와 Btrfs 모두 ‘차세대 파일 시스템’으로 불리며, 기존 ext4 같은 파일 시스템보다 훨씬 강력한 기능들을 제공합니다.

    • Copy-on-Write (CoW, 카피 온 라이트): 이게 두 파일 시스템의 가장 중요한 공통점입니다. 데이터를 덮어쓰지 않고, 변경 사항이 생기면 새로운 블록에 쓰고 메타데이터만 업데이트하는 방식이죠. 덕분에 스냅샷(Snapshot) 생성이나 데이터 손상 복구에 아주 유리합니다.
    • 데이터 무결성 (Data Integrity): CoW 덕분에 데이터가 손상될 위험이 훨씬 적습니다. 체크섬(Checksum)을 사용해서 데이터가 올바른지 지속적으로 검증하거든요.

    ZFS(Zettabyte File System): 엔터프라이즈급 안정성의 대명사

    ZFS는 Oracle Solaris에서 시작되어 현재는 OpenZFS 프로젝트로 활발히 개발되고 있는 파일 시스템입니다. ‘강력한 데이터 무결성’이라는 키워드가 가장 잘 어울립니다. 제가 써보니 이 친구는 정말 든든하더라고요. 주요 특징은 다음과 같습니다.

    • 트랜잭션 기반 (Transactional): 모든 쓰기 작업이 트랜잭션으로 처리되어 데이터 손실 위험이 거의 없습니다.
    • 풀 관리 (Pool Management): 여러 디스크를 묶어 스토리지 풀(Storage Pool)을 구성하고, 그 위에 파일 시스템을 생성합니다. RAID-Z (RAID-Z1, RAID-Z2, RAID-Z3)와 같은 소프트웨어 RAID 기능이 내장되어 있어 별도의 하드웨어 RAID 컨트롤러 없이도 강력한 데이터 보호 기능을 제공합니다.
    • 자가 복구 (Self-Healing): 데이터 손상이 감지되면 체크섬을 통해 자동으로 복구하려고 시도합니다. 이게 진짜 매력적이죠.
    • 스냅샷 (Snapshot) 및 클론 (Clone): 거의 즉각적으로 스냅샷을 생성하고 관리할 수 있습니다. 백업이나 테스트 환경 구성에 아주 유용하죠.
    • 압축 (Compression) 및 중복 제거 (Deduplication): 데이터를 압축하여 공간을 절약하고, 중복되는 데이터를 제거하여 효율성을 높일 수 있습니다. 다만, 중복 제거는 RAM을 많이 사용해서 홈랩에서는 신중하게 접근해야 합니다.

    Btrfs (B-tree File System): 리눅스 친화적인 유연성

    Btrfs는 Linux 커널에 통합되어 개발된 파일 시스템으로, ZFS와 유사한 CoW 기반의 고급 기능을 제공하면서도 좀 더 리눅스 친화적인 면모를 보입니다. 제가 처음 Btrfs를 접했을 땐 ‘오, ZFS만큼 강력한데 더 가볍고 유연하네?’ 싶었거든요.

    • 서브볼륨 (Subvolume): 파티션처럼 작동하지만 훨씬 유연하게 생성하고 관리할 수 있습니다. 스냅샷의 기반이 되기도 하고요.
    • 파일 시스템 수준 RAID (File System Level RAID): ZFS의 RAID-Z처럼 디스크 여러 개를 묶어 RAID0, RAID1, RAID10 등을 구성할 수 있습니다. 다만, RAID5/6은 아직 안정성 문제로 권장되지 않는 경우가 많습니다. 제가 한 번 써봤는데, 썩 만족스럽지 못했죠. ⚠️
    • 스냅샷 (Snapshot): ZFS와 마찬가지로 빠르고 효율적인 스냅샷 기능을 제공합니다. 서브볼륨 기반이라 관리도 편리하고요.
    • 데이터 및 메타데이터 체크섬 (Data and Metadata Checksum): ZFS와 유사하게 데이터 무결성을 검증합니다.
    • 온라인 리사이징 (Online Resizing): 파일 시스템 크기를 온라인 상태에서 유연하게 조절할 수 있습니다.

    두 파일 시스템의 주요 특징을 표로 비교해볼까요?

    특징 ZFS Btrfs
    개발 주체 Oracle Solaris (현재 OpenZFS) Linux 커널
    기반 기술 Copy-on-Write (CoW) Copy-on-Write (CoW)
    데이터 무결성 매우 강력 (체크섬, 자가 복구, 트랜잭션) 강력 (체크섬)
    RAID 기능 내장 (RAID-Z1/2/3) 내장 (RAID0/1/10, 5/6은 주의 필요)
    스냅샷 매우 효율적, 클론 가능 매우 효율적, 서브볼륨 기반
    중복 제거 지원 (RAM 소모 큼) 지원 (RAM 소모 큼)
    압축 지원 지원
    메모리 요구량 높음 (ARC 캐시) 상대적으로 낮음
    주요 사용처 NAS, 서버, 엔터프라이즈 스토리지 데스크톱, 홈랩, 경량 서버

    Proxmox에서 ZFS, Btrfs 스토리지 구성하기 (실전 구현)

    이제 Proxmox 환경에서 실제로 두 스토리지를 어떻게 구성할 수 있는지 알아볼 시간입니다. 제가 직접 해보니 Proxmox 설치 시 ZFS 루트 파일 시스템을 선택하는 게 가장 편하더라고요. 설치 단계에서 바로 ZFS 풀을 구성할 수 있거든요. 하지만 이미 설치된 Proxmox에 추가하거나 Btrfs를 사용하려면 몇 가지 수동 설정이 필요합니다.

    ZFS 스토리지 구성 예시 (Proxmox 설치 후 추가)

    Proxmox에 새로운 디스크로 ZFS 풀을 추가하는 과정입니다.

    1. 디스크 확인: 먼저 사용할 디스크의 경로를 확인합니다.
      2. lsblk

      예를 들어 /dev/sdb, /dev/sdc를 사용할 경우입니다.

    2. ZFS 풀 생성: RAID-Z1 (패리티 디스크 1개)으로 풀을 생성합니다.
      3. zpool create -f myzfsraidz1 raidz1 /dev/sdb /dev/sdc /dev/sdd

      여기서 myzfsraidz1은 제가 임의로 정한 풀 이름입니다. 실제 환경에서는 디스크 개수와 보호 수준에 맞춰 RAID-Z2 등을 선택할 수 있습니다.

    3. Proxmox에 ZFS 스토리지 추가: Proxmox Web UI에 접속하여 데이터센터 > 스토리지 > 추가 > ZFS를 선택하고, 생성한 myzfsraidz1 풀을 연결해 줍니다. 콘텐츠 타입(Content type)은 VM 디스크 이미지, 컨테이너, 백업 등 필요한 것을 선택하면 됩니다.

    Btrfs 스토리지 구성 예시 (Proxmox 설치 후 추가)

    Btrfs는 Proxmox의 기본 스토리지 타입으로 직접 지원하지 않아, 일반 디렉토리 스토리지로 활용해야 합니다. 이 부분이 Btrfs를 홈랩에서 쓰려는 분들께는 첫 번째 삽질 포인트가 되더라고요. ⚠️

    1. 디스크 확인 및 Btrfs 파일 시스템 생성:
      2. lsblk
mkfs.btrfs -f /dev/sde

      /dev/sde는 예시 디스크입니다. 여러 디스크를 Btrfs RAID로 묶으려면 mkfs.btrfs -d raid1 -m raid1 /dev/sde /dev/sdf 와 같이 명령어를 사용합니다.

    2. 마운트 포인트 생성 및 마운트:
      3. mkdir /mnt/mybtrfs
mount /dev/sde /mnt/mybtrfs
    3. fstab에 등록 (재부팅 시 자동 마운트): UUID를 사용해 등록하는 것이 좋습니다.
      4. echo "UUID=$(blkid -s UUID -o value /dev/sde) /mnt/mybtrfs btrfs defaults 0 0" >> /etc/fstab
    4. Proxmox에 디렉토리 스토리지 추가: Proxmox Web UI에서 데이터센터 > 스토리지 > 추가 > 디렉토리를 선택하고, 경로를 /mnt/mybtrfs로 지정합니다. 콘텐츠 타입은 ZFS와 마찬가지로 필요에 따라 선택합니다.
    Proxmox 웹 인터페이스에서 새로운 ZFS 또는 Btrfs 기반 디렉토리 스토리지를 추가하는 설정 화면입니다.

    Proxmox 웹 인터페이스에서 새로운 스토리지를 추가하는 화면입니다. ZFS 풀이나 Btrfs 서브볼륨을 Proxmox에 연결하는 과정을 보여줍니다.

    삽질 경험: 성능과 데이터 무결성 사이의 고민

    솔직히 말씀드리면, 처음엔 Btrfs의 유연성과 서브볼륨 기능에 혹했었습니다. ‘오, 이거 하나로 다 되겠네!’ 싶었거든요. 그런데 막상 홈랩 환경에서 여러 VM과 컨테이너를 돌려보니, 생각보다 여러 부분에서 차이를 느끼게 되더라고요.

    ZFS는 메모리 사용량(ARC, Adaptive Replacement Cache)이 높은 편입니다. 그래서 Proxmox 호스트의 RAM이 충분하지 않으면 성능 저하가 올 수 있다는 경고를 많이 봤었죠. 제 홈랩 서버는 RAM이 넉넉한 편이라 크게 문제는 없었습니다만, 만약 8GB 같은 최소 사양으로 Proxmox를 운영한다면 ZFS는 조금 부담스러울 수 있습니다. 반면 Btrfs는 상대적으로 메모리 요구량이 낮아 경량 환경에 더 적합할 수 있습니다. 하지만 이게 다가 아니더라고요.

    특히 랜덤 I/O 성능에서 ZFS가 강점을 보였습니다. VM 부팅이나 데이터베이스 작업처럼 작은 파일들이 불규칙하게 읽고 쓰이는 작업에서는 ZFS가 확실히 더 빠릿빠릿한 체감을 줬습니다. SSD 환경에서는 그 차이가 더 두드러지더라고요. Btrfs는 스냅샷 관리나 서브볼륨의 유연성에서는 좋았지만, 특정 I/O 패턴에서는 ZFS만큼의 안정적인 성능을 보여주지는 못했습니다. 특히 Btrfs에서 RAID5/6은 아직 프로덕션 환경에서는 조심해야 한다는 이야기가 많죠? 저도 홈랩에서 시도했다가 데이터 날릴 뻔했습니다. ⚠️ 그래서 Btrfs로 RAID를 구성할 때는 RAID1이나 RAID10을 권장하는 편입니다.

    홈랩 환경에서의 실측 성능 분석 (결과 검증)

    구체적인 벤치마크 수치를 나열하는 것은 의미가 없다고 생각합니다. 왜냐하면 제 홈랩 환경과 여러분의 환경은 디스크 종류, CPU, RAM, 워크로드 등 모든 것이 다르기 때문이죠. 하지만 제가 ‘체감’하고 ‘관찰’한 바는 명확합니다.

    • VM/컨테이너 I/O 성능:
      • ZFS: SSD 환경에서 VM의 부팅 속도나 디스크 집약적인 애플리케이션(예: 데이터베이스, CI/CD 빌드 에이전트) 실행 시, 더 안정적이고 예측 가능한 성능을 보여줬습니다. 특히 ARC 캐시가 활성화되면 읽기 성능이 매우 뛰어났습니다.
      • Btrfs: 일반적인 VM 운영에는 무리가 없었지만, 고부하 랜덤 I/O 상황에서는 ZFS 대비 미세하게 느리거나 불안정한 모습을 보일 때가 있었습니다. 하지만 스냅샷 생성 및 복구는 ZFS보다 빠르고 가벼운 느낌을 줬습니다.
    • 데이터 무결성 및 복구:
      • ZFS: 이건 정말 ‘철옹성’ 같다는 느낌을 받았습니다. 한 번은 불안정한 전원 공급으로 인해 시스템이 갑자기 꺼진 적이 있었는데, ZFS 풀은 아무 문제 없이 잘 복구되더라고요. 체크섬 기반의 자가 복구 기능 덕분인 것 같습니다. zpool scrub 명령어로 주기적으로 풀 상태를 확인하면 마음이 편안해집니다.
      • Btrfs: Btrfs 역시 체크섬을 사용하기 때문에 데이터 무결성이 우수합니다. 하지만 ZFS만큼 ‘강력하다’는 인상은 받지 못했습니다. 커뮤니티에서도 ZFS가 데이터 손상 방지 및 복구 측면에서 좀 더 검증된 안정성을 가지고 있다고 평가하는 분위기입니다.

    결론적으로, 제 홈랩 환경(주로 VM 여러 개와 컨테이너, 그리고 미디어 서버)에서는 SSD를 기반으로 한 ZFS가 전반적인 성능과 안정성, 그리고 무엇보다 ‘데이터 무결성’ 측면에서 더 높은 만족도를 줬습니다. Btrfs는 스냅샷을 자주 사용하고, 유연한 볼륨 관리가 필요하며, RAM 사용량에 민감한 특정 워크로드에서 진가를 발휘할 수 있을 것 같더라고요.

    Proxmox 가상 머신의 디스크 읽기 및 쓰기 I/O 성능를 시간대별로 보여주는 모니터링 그래프입니다.

    Proxmox 가상 머신의 디스크 I/O 성능 모니터링 그래프입니다. ZFS와 Btrfs 스토리지에서 각각 운영되는 VM의 I/O 처리량을 시각적으로 비교할 수 있습니다.

    그래서, 어떤 걸 선택해야 할까요? (결론 및 제안)

    제 경험을 바탕으로 여러분의 홈랩 스토리지 선택에 대한 가이드를 드려볼게요. 정답은 없지만, 어떤 상황에 더 적합한지는 분명히 있습니다.

    • ZFS를 추천하는 경우:
      • ✅ 데이터 무결성과 안정성을 최우선으로 생각한다면 ZFS가 최고의 선택입니다.
      • ✅ Proxmox 호스트의 RAM이 충분하다면 (최소 16GB 이상, 많을수록 좋습니다).
      • ✅ 하드웨어 RAID 컨트롤러 없이 소프트웨어 RAID (RAID-Z)로 강력한 데이터 보호를 원한다면.
      • ✅ VM 디스크 I/O 성능이 중요한 워크로드(데이터베이스, 개발 환경 등)를 운영한다면.
    • Btrfs를 고려할 수 있는 경우:
      • ✅ 유연한 스냅샷 관리와 서브볼륨 기능을 적극적으로 활용하고 싶다면.
      • ✅ Proxmox 호스트의 RAM이 상대적으로 부족한 환경에서 CoW 기반 파일 시스템을 쓰고 싶다면.
      • ✅ 특정 실험적인 워크로드나, 파일 시스템 수준의 RAID1/10을 구성하려 한다면 (단, RAID5/6은 아직 주의).
      • ✅ 스토리지를 자주 확장하거나 축소하는 등 유연한 볼륨 관리가 필요하다면.

    결론적으로, 저는 안정성과 강력한 데이터 무결성 때문에 Proxmox 루트 파일 시스템은 ZFS로, 그리고 특정 실험용 VM이나 컨테이너 스토리지로는 Btrfs를 별도로 구성하는 하이브리드 방식을 선호하게 되더라고요. 이렇게 하면 두 파일 시스템의 장점을 모두 활용할 수 있습니다. 💡

    ZFS와 Btrfs 파일 시스템의 주요 장점과 단점을 직관적으로 비교하는 인포그래픽입니다.

    ZFS와 Btrfs 파일 시스템의 주요 장점과 단점을 한눈에 비교할 수 있는 인포그래픽입니다. 홈랩 환경에서의 스토리지 성택에 도움을 줄 수 있는 핵심 정보를 담고 있습니다.

    마무리하며: 나의 홈랩, 나의 스토리지

    오늘 글을 통해 Proxmox 환경에서 ZFS와 Btrfs 비교를 해봤습니다. 저의 13년차 인프라 엔지니어의 경험과 홈랩에서의 삽질(?)을 바탕으로 이야기했지만, 결국 여러분의 환경과 목적에 맞는 최적의 선택을 하는 것이 가장 중요합니다. 어떤 파일 시스템을 선택하시든, 스냅샷과 백업은 선택이 아닌 필수라는 점, 잊지 마세요!

    이 글이 여러분의 홈랩 스토리지 성능과 데이터 무결성 고민에 작은 도움이 되었으면 좋겠습니다. 혹시 더 궁금한 점이나 여러분의 경험이 있다면 댓글로 공유해 주세요! 다음에는 ZFS ARC 캐싱 최적화에 대해 좀 더 깊이 다뤄볼 예정이니 기대해 주세요!