Proxmox ZFS, 왜 선택해야 할까? 성능, 안정성, 운영 관점 분석

Proxmox ZFS를 처음 검토할 때는 보통 CPU나 메모리보다 스토리지에서 먼저 막히더라고요. VM은 뜨는데 백업이 길어지고, 디스크 한 장이 수상해 보여도 어디부터 봐야 할지 감이 안 잡히는 식입니다. 저도 처음엔 “여기까지 꼭 ZFS로 가야 하나?” 싶었는데, 오래 써보니 핵심은 최고 속도보다 문제가 생겼을 때 상태를 읽기 쉬운 구조를 만든다는 점이었습니다.

그래서 이 글은 “ZFS가 좋다더라” 수준에서 끝내지 않겠습니다. ZFS 성능이 어떤 워크로드에서 살아나는지, ZFS 안정성이 왜 높게 평가되는지, 그리고 Proxmox 스토리지를 설계할 때 초기에 뭘 잘못 고르면 나중에 오래 고생하는지까지 실무 기준으로 정리해보겠습니다. 결론부터 말하면 이 조합은 만능은 아니지만, 설계를 제대로 하면 꽤 오래 편합니다.

Proxmox 호스트, ZFS 풀(pool), VM 디스크, 백업 스토리지가 한눈에 보이는 구조도입니다.

왜 Proxmox ZFS를 많이 선택할까요

제가 Proxmox에서 ZFS를 높게 보는 이유는 기능 수보다 운영 일관성 때문입니다. VM 디스크가 어느 풀에 있고, 스냅샷이 어디 계층에서 관리되고, 장애가 났을 때 어떤 명령으로 상태를 확인해야 하는지가 한 체계 안에 들어옵니다. RAID 컨트롤러, 파일시스템, 논리 볼륨을 따로따로 추적할 때보다 훨씬 덜 산만하죠.

특히 Proxmox 같은 가상화 환경에서는 아래 세 가지가 크게 작용합니다.

• 스냅샷과 복제 흐름이 자연스럽습니다. 작업 전 스냅샷, 테스트 후 롤백, 다른 노드로 복제까지 같은 철학으로 움직입니다.
• 풀 상태를 읽기 쉽습니다. 디스크가 느린지, 깨졌는지, 일부만 이상한지 판단 포인트가 zpool status와 zpool iostat에 비교적 잘 드러납니다.
• 설계 실수가 초기에 드러납니다. 이건 불편해 보여도 사실 장점입니다. ZFS는 “대충 붙여도 되겠지”를 잘 용서하지 않거든요.

반대로 ZFS가 덜 맞는 환경도 분명합니다. 메모리 여유가 거의 없고, 디스크를 즉흥적으로 하나씩 늘려야 하고, 운영 점검을 거의 하지 않는 환경이라면 단순한 LVM 계열이 더 편할 때도 있습니다. 그래서 저는 Proxmox ZFS를 성능 기능이 아니라 운영 모델의 선택으로 보는 편입니다.

Proxmox ZFS를 이해할 때 먼저 봐야 할 구조

용어 정의보다 중요한 건 어느 계층이 성능과 장애 허용을 좌우하느냐입니다.

1. pool(풀)은 관리 단위입니다

여러 디스크 묶음 전체를 가리키는 가장 큰 저장소입니다. Proxmox에서는 여기 위에 VM 디스크, 컨테이너 루트 디스크, 스냅샷이 올라갑니다. 운영자가 보는 용량, 상태, scrub 대상도 이 계층입니다.

2. vdev는 성격을 결정합니다

실제로 성능과 복구 가능성은 pool보다 vdev 구조가 더 크게 좌우됩니다. mirror인지 RAIDZ1인지 RAIDZ2인지에 따라 랜덤 I/O 성격이 달라지고, 디스크 고장 시 복구 여유도 달라집니다. 같은 풀 이름이라도 내부 vdev 구성이 다르면 체감이 완전히 달라집니다.

3. dataset과 zvol은 용도가 다릅니다

파일 단위 관리에는 dataset이, 블록 디바이스처럼 쓰는 VM 디스크에는 zvol이 더 직접적입니다. Proxmox의 로컬 ZFS 스토리지는 VM 이미지와 컨테이너 데이터를 ZFS 계층에서 관리하며, VM 디스크는 보통 블록 볼륨 성격으로 다뤄집니다. 여기서 중요한 건 VM은 작은 랜덤 I/O가 많다는 점입니다. 그래서 파일 아카이브에 유리한 구성과 VM에 유리한 구성이 갈립니다.

4. scrub는 “점검”이지 “백업”이 아닙니다

scrub는 풀 데이터를 읽으면서 체크섬을 검증하고, 중복 데이터가 있는 구성에서는 손상 블록 복구에 도움을 줍니다. 이 기능이 강한 이유는 “데이터가 있다”와 “데이터가 멀쩡하다”를 구분해주기 때문입니다. 운영해보면 이 차이가 생각보다 큽니다.

제가 실무에서 특히 중요하게 보는 포인트는 이겁니다. ZFS는 데이터를 저장하는 시스템이면서, 동시에 상태를 해석할 단서를 남기는 시스템입니다. 장애를 없애준다기보다, 장애를 더 빨리 좁혀가게 해주는 쪽에 가깝습니다.

성능 관점에서 보면, Proxmox ZFS는 “빠르다”보다 “구조를 탄다”가 맞습니다

ZFS 성능을 한 줄로 단정하면 거의 항상 틀립니다. 같은 SSD라도 mirror인지 RAIDZ인지, sync 쓰기가 많은지, 압축이 잘 먹는지에 따라 결과가 크게 달라집니다. 제가 체감한 기준은 단순했습니다. VM이 많이 붙는 Proxmox 스토리지는 랜덤 I/O 관점에서 봐야 한다는 점입니다.

VM 스토리지에 mirror를 자주 권하는 이유는 단순히 “더 빠르다”여서가 아닙니다. 랜덤 I/O, 장애 추적, 디스크 교체 절차, 성능 편차 예측 가능성까지 합치면 운영 총비용이 낮기 때문입니다. RAIDZ는 용량 효율은 좋지만, VM 여러 대가 동시에 작은 블록을 읽고 쓰는 환경에서는 생각보다 거칠게 느껴질 수 있습니다.

그리고 실제로 많이 놓치는 설정이 몇 가지 있습니다.

• ashift: 물리 섹터 특성과 맞지 않으면 쓰기 증폭과 성능 손해를 볼 수 있습니다.
• compression=lz4: CPU 부담이 비교적 낮고 I/O를 줄여, 로그나 텍스트 비중이 있는 VM에서 체감이 좋아질 때가 많습니다.
• atime=off: 읽을 때마다 메타데이터 쓰기를 줄여 불필요한 I/O를 덜 만듭니다.
• autotrim=on: SSD 기반 풀이면 장기 운용 시 상태 유지에 도움이 됩니다.
• sync 특성: 데이터베이스, NFS, 일부 애플리케이션은 동기식 쓰기 비중이 높아 체감 성능이 갑자기 달라질 수 있습니다.

제 경험상 ZFS가 느리다고 말하는 사례 중 적지 않은 비중이, 사실은 RAIDZ를 VM 스토리지로 써서 랜덤 I/O가 막힌 경우이거나, 동기식 쓰기 워크로드를 일반 파일서버 감각으로 올린 경우였습니다. ZFS 자체보다 구조 선택이 원인인 경우가 많다는 얘기죠.

안정성은 왜 평가가 높을까요

ZFS 안정성이 높게 평가되는 이유는 “절대 안 깨진다”가 아니라, 깨졌을 때 조용히 넘어가지 않게 설계돼 있다는 데 있습니다. 체크섬 기반 검증, 중복 데이터에서의 복구 가능성, 풀 상태와 오류 카운트 노출이 합쳐지면서 운영자가 놓치기 쉬운 문제를 빨리 수면 위로 끌어올립니다.

저는 이 점을 꽤 높게 봅니다. SSD 한 장이 완전히 죽는 고전적인 장애보다, 간헐적 읽기 오류, 케이블 접촉 불량, 특정 시간대만 치솟는 I/O 지연 같은 애매한 문제가 실제 운영에서는 더 귀찮더라고요. 이럴 때 VM 내부 오류만 보면 원인 추적이 길어지는데, ZFS는 적어도 스토리지 계층에서 “뭔가 이상하다”는 신호를 먼저 주는 편입니다.

다만 여기에는 오해도 많습니다.

• 스냅샷은 백업이 아닙니다. 같은 풀 안에 있으면 풀 자체 장애나 운영 실수에서 자유롭지 않습니다.
• 구성이 잘못되면 보호도 없습니다. single disk 풀은 손상 감지는 해도, 복구할 다른 사본이 없으면 자동 복구를 기대하면 안 됩니다.
• 메모리가 부족하면 운영 체감이 나빠질 수 있습니다. 안정성과는 별개로 캐시 여유가 없으면 답답하다는 느낌이 반복될 수 있습니다.

그래서 저는 안정성을 이렇게 정의합니다. 장애를 막는 기술이라기보다, 장애를 설명하고 복구 경로를 남기는 기술입니다. 운영자 입장에서는 이 차이가 꽤 큽니다.

Proxmox 스토리지를 실제로 구성할 때 먼저 정할 것들

디스크를 꽂고 바로 zpool create부터 치면 나중에 되돌리기 정말 귀찮습니다. 저는 Proxmox ZFS를 만들기 전에 아래 세 가지부터 정합니다.

1. 이 풀이 VM용인지, 백업용인지
2. 확장을 같은 형태의 vdev 추가로 할 건지, 큰 디스크 교체 업그레이드로 갈 건지
3. 주 저장 장치가 SSD인지 HDD인지

이걸 먼저 정하면 mirror와 RAIDZ 판단이 훨씬 빨라집니다. 아래는 SSD 두 장을 VM용 mirror 풀로 만드는 예시입니다. 핵심은 /dev/sdX 대신 /dev/disk/by-id/를 쓰고, 필요한 속성을 생성 시점에 같이 넣는 겁니다.

lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL
ls -l /dev/disk/by-id/ | grep -E 'ata|nvme'

zpool create -f \
  -o ashift=12 \
  -o autotrim=on \
  -O compression=lz4 \
  -O atime=off \
  -O xattr=sa \
  tank mirror \
  /dev/disk/by-id/ata-Samsung_SSD_1 \
  /dev/disk/by-id/ata-Samsung_SSD_2

zpool status tank
zfs list

왜 이렇게 하느냐고요? 이유는 단순합니다.

• ashift=12: 4K 섹터 계열 장치에 무난하게 많이 쓰는 선택입니다.
• autotrim=on: SSD 풀이라면 장기 운영 시 도움이 됩니다.
• compression=lz4, atime=off: 실사용에서 무난한 기본값으로 많이 잡습니다.
• xattr=sa: 구형 풀이나 호환성을 직접 관리하는 환경에서는 명시해두면 확인이 쉽습니다. 다만 최신 OpenZFS 계열에서는 이미 기본값인 경우도 있어요.
• by-id 경로 사용: 재부팅이나 하드웨어 변경 후 /dev/sdX 순서 변동 리스크를 줄입니다.

그 다음은 Proxmox에 스토리지를 등록합니다. 웹 UI로 해도 되지만, 저는 설정 확인이 편해서 CLI도 같이 봅니다.

pvesm add zfspool tank-vm \
  -pool tank \
  -content images,rootdir \
  -sparse 1

pvesm status
cat /etc/pve/storage.cfg

zfspool: tank-vm
    pool tank
    content images,rootdir
    sparse 1

content images,rootdir는 VM 디스크와 컨테이너 루트 디스크를 저장하겠다는 의미고, sparse 1은 씬 프로비저닝과 연결됩니다. 저는 여기서 한 번 더 확인합니다. 이 풀이 VM용이면 images가 들어가 있는지, 백업용이면 아예 다른 저장소로 분리하는 게 맞는지를요.

스토리지 등록 화면이나 디스크 두 개를 미러로 묶는 구성을 설명하는 이미지가 들어가면 이해가 빨라집니다.

운영하면서 꼭 보는 명령어와 읽는 순서

스토리지는 만드는 순간보다, 느려졌을 때 어디를 먼저 보느냐가 더 중요합니다. 저는 보통 아래 순서대로 봅니다.

zpool status -v
zpool iostat -v 1
zfs get compression,atime,xattr,recordsize,volblocksize tank
pvesm status
journalctl -k -n 100 --no-pager

명령마다 해석 포인트가 다릅니다.

• zpool status -v: 첫 줄의 state를 봅니다. ONLINE이 아니면 성능 튜닝보다 상태 복구가 먼저입니다.
• zpool iostat -v 1: vdev와 개별 디스크 편중을 봅니다. 특정 장치만 유독 바쁘거나 응답이 수상하면 병목 가능성이 큽니다.
• zfs get ...: 의도한 속성이 실제로 적용됐는지 확인합니다. 생성 후 누락된 경우가 생각보다 흔합니다.
• pvesm status: Proxmox가 해당 스토리지를 usable하게 보고 있는지 확인합니다. ZFS는 정상인데 Proxmox 등록이 꼬인 경우도 있거든요.
• journalctl -k: 케이블, 컨트롤러, I/O 에러 같은 커널 레벨 힌트를 봅니다.

판단 순서도 중요합니다. 저는 늘 1) ONLINE 여부, 2) 오류 증가 여부, 3) 특정 디스크 편중, 4) 워크로드 특성 순서로 봅니다. 이 순서를 지키면 “ZFS가 느린가?” 같은 뭉뚱그린 질문이 “특정 디스크가 느린가?”, “sync 쓰기 때문에 밀리는가?” 같은 실행 가능한 질문으로 바뀝니다.

예를 들어 백업 시간대에 VM이 버벅인다면, CPU가 널널할 때 저는 먼저 zpool iostat -v 1를 켭니다. 여기서 디스크가 포화되면 원인은 거의 스토리지 계층입니다. 반대로 디스크가 한가하면 백업 방식, 네트워크, 게스트 내부 I/O 패턴을 봐야겠죠. 이거 진짜 편한 게, 잘못 의심할 대상을 빨리 지워준다는 점입니다.

⚠️ 제가 자주 본 주의사항과 트러블슈팅

매뉴얼에는 적혀 있어도 운영하다 보면 왜 이게 문제인지 체감이 늦게 오는 포인트가 있습니다. 아래는 제가 특히 자주 본 실패 모드입니다.

1. 디스크 이름만 믿고 작업하는 문제

근본 원인은 단순합니다. Linux의 /dev/sdX 이름은 영구 식별자가 아니기 때문입니다. 리부팅, HBA 변경, 디스크 추가 후 순서가 바뀌면 같은 sdb라고 믿고 작업했다가 다른 디스크를 건드릴 수 있습니다.

ls -l /dev/disk/by-id/ | grep -E 'ata|nvme'

zpool create -f tank mirror \
  /dev/disk/by-id/ata-Samsung_SSD_xxx \
  /dev/disk/by-id/ata-Samsung_SSD_yyy

이건 편의가 아니라 사고 방지 습관입니다. 저도 이 규칙을 안 지켰을 때 교체 작업에서 괜히 더 오래 붙잡힌 적이 있었습니다.

2. 용량 확장을 RAID 카드 감각으로 생각하는 문제

근본 원인은 vdev 구조를 나중에 자유롭게 바꿀 수 있을 거라는 기대입니다. ZFS는 하드웨어 RAID처럼 아무 디스크나 한 장씩 붙여 모양을 쉽게 바꾸는 방식과는 거리가 있습니다. 최근 OpenZFS에서는 RAIDZ 확장 기능이 들어왔지만, 여전히 시간도 걸리고 제약도 있어 처음 설계를 대충 해도 된다는 뜻은 아닙니다.

제가 운영 기준으로 내리는 판단은 이렇습니다.

3. 스냅샷을 백업처럼 쌓는 문제

근본 원인은 스냅샷의 비용이 낮아 보여서입니다. 너무 쉽게 찍히다 보니 보존 정책 없이 쌓이기 쉽습니다. 그런데 스냅샷이 많아질수록 운영자는 “무엇을 남길지”보다 “무엇을 지워도 되는지” 판단하는 데 시간을 쓰게 됩니다.

그래서 저는 스냅샷 규칙을 아주 단순하게 둡니다.

• 수동 스냅샷은 작업 전후처럼 목적이 분명할 때만 만듭니다.
• 자동 스냅샷은 보존 개수와 이름 규칙을 먼저 정합니다.
• 장기 보존은 스냅샷이 아니라 별도 백업 저장소로 보냅니다.

4. scrub를 안 돌려서 이상 징후를 늦게 보는 문제

근본 원인은 당장 눈에 띄는 장애가 없으니 미루게 된다는 점입니다. 그런데 ZFS의 장점은 문제가 터진 뒤보다, 아직 큰 사고가 되기 전에 상태를 읽는 데 있습니다. scrub를 미루면 그 장점을 스스로 줄이는 셈이죠.

zpool scrub tank
zpool status tank

scan: 항목에서 scrub 진행 여부와 마지막 완료 기록을 봅니다. 에러가 보이면 거기서 멈추지 말고, 디스크 SMART 정보와 커널 로그까지 같이 확인하는 게 좋습니다. 실제 원인이 ZFS보다 SSD 자체, 케이블, 전원, 컨트롤러인 경우도 꽤 많더라고요.

5. 동기식 쓰기 워크로드를 가볍게 보는 문제

근본 원인은 “일반 파일 복사도 괜찮았으니 서비스도 괜찮겠지”라는 추정입니다. 하지만 데이터베이스, NFS, 일부 애플리케이션은 sync 쓰기 비중이 높습니다. 이 경우 평소에는 조용하다가 특정 서비스만 유독 느려 보일 수 있습니다. 여기서 필요한 건 막연한 튜닝이 아니라, 그 서비스가 실제로 어떤 쓰기 패턴을 갖는지 확인하는 일입니다.

풀 상태가 ONLINE, DEGRADED로 바뀌는 모습과 디스크 교체 절차를 설명하는 시각 자료 위치입니다.

검증은 어떻게 해야 할까: “된다”보다 “운영 가능하다”를 확인해야 합니다

구성을 마쳤다면 단순 마운트 확인에서 끝내지 않는 게 좋습니다. 저는 최소한 아래 순서로 검증합니다.

1. Proxmox가 스토리지를 정상 인식하는지 확인합니다.
2. 테스트 VM 하나를 만들어 해당 ZFS 풀에 디스크를 올립니다.
3. 스냅샷 생성과 삭제가 정상 동작하는지 봅니다.
4. 백업 작업 중 체감 성능이 무너지는지 확인합니다.
5. zpool status와 zpool iostat로 상태와 편중을 읽습니다.

qm create 9000 --name zfs-test --memory 2048 --net0 virtio,bridge=vmbr0
qm set 9000 --scsi0 tank-vm:32
qm start 9000
qm snapshot 9000 baseline
qm listsnapshot 9000
vzdump 9000 --mode snapshot --storage <backup-storage-name>

이 단계에서 제가 보는 기준은 속도 숫자보다 일관성입니다.

• 스냅샷 생성이 안정적으로 되는지: 한 번 되고 한 번 실패하면 저장소 등록 방식이나 설정부터 다시 봐야 합니다.
• 백업 시 전체 VM 반응성이 무너지는지: 백업 저장소 분리, 시간대 분산, VM용 풀 구조 재검토가 필요할 수 있습니다.
• 장애 시 상태가 읽히는지: 홈랩이라면 테스트 디스크를 오프라인 처리해 출력이 어떻게 달라지는지 보는 공부가 꽤 도움이 됩니다.

제가 중요하게 보는 시나리오 하나를 들자면, 백업은 성공하는데 특정 시간대마다 게스트 OS가 갑자기 느려지는 경우입니다. 이때 많은 분들이 Proxmox 전체 문제로 보는데, 실제로는 백업 I/O와 VM I/O가 같은 풀에서 경쟁하는 구조 문제인 경우가 적지 않습니다. 이런 상황에선 튜닝보다 역할 분리가 더 크게 먹힙니다.

가상머신이 ZFS 스토리지에서 동작하고, 상태 명령어 결과가 정상인 모습을 함께 보여주는 검증 이미지입니다.

어떤 환경에 추천하고, 어디엔 덜 맞을까

이쯤 되면 선택 기준이 꽤 선명해집니다.

여기서 제가 실제로 가장 많이 권하는 구성은 이렇습니다.

• VM 중심: SSD 2개 이상 mirror 기반 ZFS
• 백업 중심: 별도 저장소, 필요하면 RAIDZ 계열 검토
• 역할 분리: OS용, VM용, 백업용을 가능하면 나눔

특히 “모든 걸 한 풀에 몰아넣는” 설계는 초반엔 단순해 보여도 운영 후반에는 원인 분리가 어려워집니다. 저도 결국은 VM 스토리지와 백업 스토리지를 분리했을 때 제일 편했습니다. 느려지는 이유를 읽기 쉬워졌거든요.

마무리: 제가 실제로 추천하는 선택 기준

Proxmox ZFS는 모든 서버에 자동 정답인 기술은 아닙니다. 그래도 VM 중심 운영, 스냅샷 활용, 상태 가시성, 장애 대응 속도를 중요하게 본다면 상당히 강한 선택지입니다. 현업과 홈랩에서 반복해서 느낀 건, ZFS는 초반 진입장벽 대신 장기 운영 편의성을 준다는 점이었어요.

그래서 제 권고는 분명합니다.

• VM 위주의 홈랩이나 소규모 가상화 서버라면, 먼저 mirror 기반 Proxmox ZFS를 검토하는 쪽이 무난합니다.
• 백업/아카이브 비중이 크고 용량 효율이 중요하다면, VM용 풀과 분리한 뒤 RAIDZ 계열을 고려하는 편이 낫습니다.
• 메모리 여유가 거의 없고 디스크 확장 계획이 자주 바뀌는 장비라면, ZFS를 억지로 넣기보다 더 단순한 스토리지 구성이 운영 비용이 낮습니다.

한 문장으로 요약하면 이렇습니다. 성능 수치만 보면 판단이 흔들릴 수 있지만, 운영 피로도까지 넣어 보면 Proxmox ZFS의 장점은 꽤 선명합니다. 특히 “장애가 났을 때 내가 빨리 읽고 대응할 수 있는가”를 중요한 기준으로 두신다면, 이 조합은 생각보다 만족도가 오래 갑니다.

Proxmox 스토리지 비교나 백업 분리 전략도 같이 보시면 판단이 더 쉬워집니다. 다음 글에서는 mirror와 RAIDZ를 실제 운영비 관점에서 더 세밀하게 비교해보겠습니다.

어떤 환경에 ZFS가 잘 맞는지, 미러와 RAIDZ 중 무엇을 고를지 한눈에 정리하는 요약 이미지입니다.

FAQ: 실무에서 자주 묻는 포인트

Proxmox에서 ZFS면 무조건 빠른가요?

아닙니다. 풀 구조, 디스크 종류, 워크로드 특성이 더 중요합니다. 특히 VM처럼 작은 랜덤 I/O가 많으면 mirror가 더 유리한 경우가 많습니다.

스냅샷만 있으면 백업은 필요 없나요?

아니요. 스냅샷은 같은 스토리지 안의 시점 보존이고, 백업은 별도 위치에 독립적으로 남겨두는 개념입니다. 둘은 대체 관계가 아닙니다.

처음 시작한다면 가장 무난한 구성은 뭔가요?

테스트와 실사용을 같이 염두에 둔다면, SSD 2개를 mirror로 묶은 ZFS 풀이 가장 이해하기 쉽고 운영 실수도 적습니다. 여기서 감을 잡고 역할 분리를 넓혀가는 편이 실패가 적더라고요.

RAIDZ를 VM 스토리지로 쓰면 안 되나요?

못 쓰는 건 아닙니다. 다만 VM 여러 대가 작은 블록을 자주 읽고 쓰는 환경에서는 기대한 체감이 안 나올 수 있습니다. 용량 효율보다 반응성이 중요하면 mirror 쪽이 대체로 덜 후회됩니다.

문제가 생기면 제일 먼저 뭘 봐야 하나요?

저는 zpool status -v로 상태를 먼저 보고, 그다음 zpool iostat -v 1로 병목과 편중을 확인합니다. 그 후에야 Proxmox 설정과 게스트 내부 문제를 의심합니다.