13년차의 서버실

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

[태그:] SLOG

  • [Proxmox] ZFS 스토리지 1년 운영 회고: 성능, 안정성, 그리고 후회되는 점

    [Proxmox] ZFS 스토리지 1년 운영 회고: 성능, 안정성, 그리고 후회되는 점

    목차

    [Proxmox] ZFS 스토리지 1년 운영 회고: 성능, 안정성, 그리고 후회되는 점

    안녕하세요, 13년차 서버실 주인장입니다. 오늘은 제가 홈랩에서 Proxmox VE (Virtual Environment)와 ZFS를 조합한 스토리지 시스템을 1년간 운영해본 솔직한 경험담을 풀어볼게요. 많은 분들이 홈랩 서버를 구축하거나 작은 규모의 프로덕션 환경에서 가상화를 고민할 때, 스토리지 구성이 가장 큰 고민이 되더라고요. 저 역시 그랬거든요. 특히 데이터의 안정성과 성능이라는 두 마리 토끼를 잡으려다 보면, Proxmox ZFS 스토리지 조합이 매력적인 선택지로 다가오기 마련입니다.

    13년차 인프라 엔지니어로서 직접 경험한 Proxmox ZFS 스토리지의 성능, 안정성, 그리고 솔직히 ‘아, 이건 좀 후회된다’ 싶었던 점들까지 가감 없이 공유해드리겠습니다. 제 삽질 경험이 여러분의 시행착오를 줄이는 데 조금이나마 도움이 되었으면 좋겠어요. 💡

    왜 Proxmox ZFS를 선택했을까?

    제가 Proxmox ZFS 스토리지 조합을 선택한 이유는 명확했어요. 바로 데이터 무결성(Data Integrity)과 유연한 스토리지 관리 기능 때문이었죠. ZFS는 단순한 파일 시스템을 넘어, 자체적으로 볼륨 관리 기능과 RAID 기능을 포함하고 있습니다. 특히 다음과 같은 점들이 저를 매료시켰어요.

    • Copy-on-Write (CoW): 데이터를 덮어쓰지 않고 새로운 블록에 저장하기 때문에, 데이터 손상 위험이 현저히 줄어들더라고요.
    • 스냅샷(Snapshots): 특정 시점의 파일 시스템 상태를 저장할 수 있어서, VM이나 컨테이너 백업 및 롤백이 정말 편리합니다. Proxmox와의 연동은 정말 환상적이었죠.
    • 데이터 스크러빙(Data Scrubbing): 주기적으로 데이터의 무결성을 검사하고 손상된 데이터를 자동으로 복구합니다. 이 덕분에 몇 번 안심했네요.
    • RAID-Z: 소프트웨어 RAID 기능으로, 하드웨어 RAID 컨트롤러 없이도 안정적인 다중 디스크 구성을 할 수 있어요.

    Proxmox는 이런 ZFS의 강력한 기능을 웹 UI에서 손쉽게 관리할 수 있도록 통합해놨어요. 처음엔 CLI(Command Line Interface)로만 ZFS를 다루다가, Proxmox의 간편함에 감탄했었죠.

    저의 Proxmox ZFS 스토리지 구성

    제 홈랩 서버는 인텔 i5-8500 CPU에 32GB RAM을 사용하고 있어요. 스토리지 구성은 다음과 같았습니다.

    1. 데이터 풀 (Data Pool): 4TB HDD 4개로 RAIDZ1 풀 구성
    2. L2ARC (Level 2 Adaptive Replacement Cache): 250GB SATA SSD 1개
    3. SLOG (Separate Log Device): 처음에는 없었으나, 나중에 128GB NVMe SSD 추가

    처음엔 RAIDZ1으로도 충분하다고 생각했어요. 디스크 하나가 죽어도 데이터 손실 없이 버틸 수 있으니까요. L2ARC는 저렴한 SATA SSD로 시작해서 캐싱 효과를 보려고 했고, SLOG는 VM의 쓰기 성능에 큰 영향을 준다고 해서 나중에 추가해봤습니다. 이 구성으로 1년 동안 다양한 VM (Ubuntu, Windows Server), 컨테이너 (Docker, LXC), 그리고 여러 서비스들을 운영했어요.

    제 Proxmox ZFS 홈랩 스토리지 구성 다이어그램입니다. HDD로 데이터 풀을 구성하고, SSD를 L2ARC와 SLOG로 활용했어요.

    1년 운영 후 성능 분석

    실제로 1년간 Proxmox ZFS 스토리지를 사용해보니, 예상보다 훨씬 만족스러운 부분도 있었고, 아쉬운 부분도 명확했습니다.

    ARC (Adaptive Replacement Cache) 효과

    ZFS는 시스템 RAM을 캐시로 정말 활용하는 ARC (Adaptive Replacement Cache) 덕분에 자주 접근하는 데이터는 정말 빠르게 읽을 수 있더라고요. 32GB RAM 중 상당 부분을 ARC가 사용했는데, 웹서버나 DB 서버처럼 특정 데이터를 반복적으로 요청하는 VM에서는 HDD임에도 불구하고 SSD에 버금가는 읽기 성능을 보여주더라고요. ARC hit ratio가 90% 이상을 유지할 때는 정말 쾌적했습니다. 🎉

    L2ARC (Level 2 ARC)의 활용

    RAM이 아무리 많아도 모든 데이터를 캐시할 수 없죠. 그래서 저렴한 SATA SSD를 L2ARC (Level 2 ARC)로 추가해봤는데, 생각보다 효과가 좋더라고요. 주로 사용되는 VM이나 컨테이너의 데이터가 L2ARC에 캐시되면서, 초기 로딩 시간이나 간헐적인 I/O 성능이 눈에 띄게 개선되는 걸 체감했습니다. 물론 NVMe SSD만큼은 아니지만, 비용 대비 성능 향상은 정말 분명했어요.

    SLOG (Separate Log Device)의 중요성

    가장 큰 성능 향상을 가져온 건 바로 SLOG (Separate Log Device)였습니다. 처음에는 SLOG 없이 운영했는데, VM의 동기 쓰기(Synchronous Write) 작업이 많아지자 I/O 대기 시간이 길어지는 문제가 발생하더라고요. 특히 데이터베이스나 로그를 많이 쓰는 서비스에서 체감 성능 저하가 심했습니다. 나중에 NVMe SSD를 SLOG로 추가하고 나니, 쓰기 성능이 정말 비약적으로 향상되었어요. VM I/O가 많은 경우에는 SLOG용 NVMe SSD는 거의 필수라고 생각합니다. 신세계를 경험했네요! ✨

    결론적으로, 일반적인 웹서버, 개발 환경 VM, 파일 서버 등을 돌리는 데는 Proxmox ZFS 스토리지가 충분한 성능을 제공했어요. 물론 고성능 NVMe RAID 풀에 비할 바는 아니지만, 홈랩 환경에서는 정말 차고 넘치는 수준이었죠.

    Proxmox 웹 UI ZFS 스토리지 대시보드 및 성능 모니터링 화면

    Proxmox 웹 UI에서 ZFS 스토리지의 상태와 성능을 모니터링하는 화면입니다. ARC Hit Ratio와 I/O 대역폭을 확인할 수 있어요.

    예상치 못한 안정성 경험 (그리고 삽질)

    ZFS의 가장 큰 장점 중 하나는 바로 데이터 무결성(Data Integrity)이잖아요? 실제로 1년간 운영하면서 이 부분에서 몇 번 감탄했어요.

    주기적인 Pool Scrub의 위력

    저는 한 달에 한 번씩 zpool scrub 명령어를 통해 풀 스크럽(Pool Scrub)을 돌렸습니다. 이게 정말 중요하더라고요. 한번은 스크럽 중 미세한 데이터 불일치를 감지하고 자동으로 복구하는 걸 로그를 통해 확인했어요. 만약 ZFS가 아니었다면 알지도 못하고 지나갈 뻔한 문제였죠. ⚠️

    디스크 장애와 RAIDZ1의 복구 경험

    불행인지 다행인지, 1년 사이에 4개 중 하나의 HDD가 고장 났어요. S.M.A.R.T. 경고가 뜨고, zpool status 명령어로 확인해보니 DEGRADED 상태가 되었더군요. 하지만 RAIDZ1으로 구성했기에 디스크 하나가 죽어도 데이터는 안전하게 보호되었습니다. 데이터를 잃을 걱정 없이 새 디스크를 주문할 수 있었죠.

    새 디스크가 도착하고 교체하는 과정에서 제가 삽질 좀 했습니다. 🤦‍♂️ 핫스왑(Hot-swap)이 되는 케이스가 아니라서 서버를 끄고 디스크를 교체했는데, 그 과정에서 명령어 사용이 미숙해서 잠시 헤맸어요. 정확한 zpool replace 명령어를 아는 게 정말 중요하더라고요.

    # 1. zpool status 명령어로 죽은 디스크의 경로 확인
# 예: /dev/sdb
root@proxmox:~# zpool status storage_pool

# 2. 새 디스크를 서버에 장착 (예: /dev/sdc)

# 3. 죽은 디스크를 새 디스크로 교체 시작
root@proxmox:~# zpool replace storage_pool /dev/sdb /dev/sdc

# 4. 교체 진행 상황 확인
root@proxmox:~# zpool status storage_pool
# reslivering이 완료되면 'ONLINE' 상태로 돌아옵니다.

    교체 후 리실버링(Resilvering)이 완료되고 풀이 다시 ONLINE 상태가 되었을 때의 안도감이란… 드디어 됐다! ✅ ZFS는 똑똑하지만, 관리자의 정확한 명령이 필수라는 걸 다시 한번 느꼈어요.

    후회되는 점과 개선 방향

    솔직히 1년간 Proxmox ZFS 스토리지를 운영하면서 후회되는 점도 몇 가지 있습니다.

    1. 초기 RAIDZ1 선택의 아쉬움: 처음에 RAIDZ1으로 구성한 게 살짝 아쉬워요. 디스크 하나만 더 추가해서 4TB HDD 5개로 RAIDZ2로 갔다면, 디스크 두 개가 동시에 고장 나도 버틸 수 있어 안정성이 훨씬 높았을 텐데 말이죠. 홈랩이긴 하지만, 중요한 데이터가 많아질수록 RAIDZ2의 안정성이 더 매력적으로 느껴집니다.
    2. SLOG/L2ARC 초기 계획 미흡: SLOG와 L2ARC를 처음부터 제대로 고려하지 못한 것도 후회돼요. 저렴한 SATA SSD로 시작했지만, 나중엔 고성능 NVMe SSD의 필요성을 절실히 느꼈거든요. 초기 투자 비용을 아끼려다 나중에 더 큰 비용과 시간을 들여 업그레이드했습니다.
    3. 디스크 종류 혼용: 데이터 풀은 HDD, L2ARC는 SATA SSD, SLOG는 NVMe SSD… 성능 때문에 다양한 디스크를 섞어 썼는데, 관리 복잡도가 올라가고 벤더별 드라이버 관리나 S.M.A.R.T. 모니터링이 조금 번거로워졌어요.

    다음 번에 Proxmox ZFS 스토리지를 구성한다면, 저는 다음과 같은 방향으로 개선할 생각이에요.

    • 안정성을 최우선으로 하여 RAIDZ2 또는 미러(Mirror) 구성 고려.
    • 처음부터 고성능 NVMe SSD를 SLOG 및 L2ARC로 할당하여 최대 성능 확보.
    • 가급적 동일한 벤더의 디스크를 사용하여 관리 편의성 증대.
    Proxmox ZFS 운영 문제점과 해결책 비교표

    Proxmox ZFS 운영 시 발생할 수 있는 주요 문제점과 제가 경험했던 해결책을 비교 정리한 표입니다.

    Proxmox ZFS 스토리지 운영 팁

    1년간 운영하면서 얻은 몇 가지 꿀팁을 공유해드릴게요.

    1. RAM은 많을수록 좋습니다.
      ZFS는 정말 RAM을 좋아합니다. ARC (Adaptive Replacement Cache) 효율을 높이려면 시스템 RAM을 최대한 많이 확보하세요. 최소 16GB, 가능하다면 32GB 이상을 추천합니다.
    2. SLOG는 선택 아닌 필수?
      VM I/O가 많거나 동기 쓰기(Synchronous Write)가 중요한 서비스(예: 데이터베이스)를 운영한다면 SLOG용 NVMe SSD는 꼭 고려하세요. 체감 성능이 확 달라집니다. 특히 저가형 NVMe라도 없어서는 안 될 부분이에요.
    3. 주기적인 스크럽은 생명입니다.
      데이터 무결성을 지키려면 zpool scrub 명령어를 통해 주기적으로 풀 스크럽을 해주세요. 저는 cron으로 매월 첫째 주 일요일 새벽 3시에 돌리도록 설정했어요. 자고 일어났을 때 스크럽 완료 메시지를 보면 왠지 모르게 뿌듯하더라고요. 😊
      4. # cron 설정 예시 (매월 첫째 주 일요일 새벽 3시)
0 3 1-7 * 0 /usr/sbin/zpool scrub storage_pool
    4. 백업은 언제나 중요합니다.
      아무리 ZFS가 튼튼해도 백업은 필수예요. Proxmox의 내장 백업 기능을 활용하거나, zfs send/receive를 이용해 다른 곳으로 스냅샷을 보내는 방식으로 이중 백업 체계를 갖추세요. 데이터는 언제나 소중하니까요.
    ZFS 풀 스크럽 진행 과정을 보여주는 콘솔 화면

    ZFS 풀 스크럽(scrub)이 진행되는 콘솔 화면이에요. 주기적인 스크럽은 데이터 무결성을 유지하는 데 필수적입니다.

    마무리하며

    1년간 Proxmox ZFS 스토리지를 운영해보면서 성능과 안정성 모두 만족스러웠습니다. 특히 데이터 무결성에 대한 ZFS의 강력한 보장은 인프라 엔지니어로서 큰 신뢰를 줬어요. 하지만 완벽한 시스템은 없다는 것, 그리고 초기 설계의 중요성을 다시 한번 깨달았습니다. 제 삽질 경험과 팁들이 Proxmox ZFS 스토리지 구성을 고민하고 계신 여러분께 조금이나마 도움이 되었으면 좋겠어요.

    다음 글에서는 Proxmox ZFS 스냅샷과 복제(Replication) 기능을 활용한 백업 전략에 대해 더 자세히 다뤄볼 예정입니다. 기대해주세요! 👋

  • [Nas] TrueNAS SCALE ZFS 성능 벤치마크: 하드웨어별 최적화 전략

    [Nas] TrueNAS SCALE ZFS 성능 벤치마크: 하드웨어별 최적화 전략

    목차

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 많은 홈랩 유저와 중소기업에서 사랑받는 TrueNAS SCALE, 그중에서도 ZFS 성능 벤치마크와 최적화 전략에 대해 이야기해보려고 해요. 제가 직접 여러 하드웨어 조합으로 삽질하면서 얻은 경험들을 솔직하게 풀어보겠습니다. 혹시 NAS 속도가 답답하다고 느끼셨다면, 이 글이 좋은 가이드가 될 겁니다.

    저도 처음 TrueNAS를 구축했을 때, ‘이 정도면 충분하겠지?’ 했는데 막상 데이터를 쓰고 읽으려니 생각보다 느려서 당황했던 기억이 있거든요. 특히 가상 머신(Virtual Machine)이나 컨테이너(Container)를 돌리거나, 여러 사람이 동시에 접근할 때는 그 느림이 더 확 체감되더라고요. 결국 ‘이건 안 되겠다!’ 싶어서 하드웨어부터 소프트웨어 설정까지 뜯어고쳤죠. 그 과정을 통해 어떤 요소들이 ZFS 성능에 가장 큰 영향을 미치는지 몸소 깨달을 수 있었습니다.

    TrueNAS SCALE의 ZFS 스토리지 아키텍처와 성능에 영향을 미치는 요소들을 시각화한 다이어그램입니다.

    ZFS 성능의 핵심 요소 이해하기

    TrueNAS SCALE의 핵심은 ZFS (Zettabyte File System)입니다. ZFS는 단순히 파일을 저장하는 것 이상의 강력한 데이터 무결성(Data Integrity), 스냅샷(Snapshot), 복제(Replication) 기능을 제공하지만, 그만큼 성능 최적화가 중요하죠. ZFS 성능에 영향을 미치는 주요 개념들을 먼저 짚고 넘어가 볼까요?

    • ARC (Adaptive Replacement Cache, 적응형 교체 캐시): ZFS가 시스템 RAM을 사용하여 자주 접근하는 데이터를 캐싱하는 방식입니다. RAM이 많을수록 캐시 히트율(Cache Hit Ratio)이 높아져 읽기 성능이 비약적으로 향상되죠.
    • L2ARC (Level 2 Adaptive Replacement Cache, 2단계 적응형 교체 캐시): ARC가 부족할 때 SSD 같은 고속 스토리지를 2차 캐시로 활용하는 기능입니다. 주로 읽기(Read) 성능 향상에 기여합니다.
    • SLOG (Separate Intent Log, 분리된 의도 로그) / ZIL (ZFS Intent Log): ZFS는 동기 쓰기(Synchronous Write) 작업을 할 때 데이터를 먼저 ZIL에 기록하여 데이터 무결성을 보장합니다. 이 ZIL을 전용 고속 저장 장치(보통 NVMe SSD)에 분리하여 사용하는 것이 SLOG입니다. SLOG는 쓰기(Write) 성능, 특히 동기 쓰기 성능을 크게 개선해줍니다.
    • VDEV (Virtual Device, 가상 장치): ZFS 풀(Pool)을 구성하는 기본 단위입니다. 여러 디스크를 RAIDZ, 미러(Mirror), 스트라이프(Stripe) 등으로 묶어 VDEV를 만듭니다. VDEV 구성 방식에 따라 성능 특성이 달라집니다.

    하드웨어별 최적화 전략: 뭘 업그레이드해야 할까요?

    NAS 성능은 단순히 디스크 개수를 늘린다고 좋아지는 게 아닙니다. 각 하드웨어 요소들이 ZFS의 특징과 맞물려 복합적으로 작용하거든요. 제가 경험했던 대표적인 하드웨어별 최적화 포인트를 알려드릴게요.

    1. CPU: 뇌가 좋아야 모든 게 빠르다

    ZFS는 데이터 무결성 검사(Checksum), 압축(Compression), 중복 제거(Deduplication) 등 다양한 연산 작업을 수행합니다. 이 모든 작업에 CPU 파워가 필요하죠. 특히 여러 클라이언트가 동시에 접근하거나, 가상 머신이 많이 돌아가는 환경에서는 고성능 CPU가 필수입니다. 저는 처음엔 저전력 CPU를 썼다가 병목 현상 때문에 고생 좀 했습니다. 결국 코어(Core) 수가 많고 클럭(Clock)이 높은 CPU로 바꿨더니 전체적인 응답성이 확 좋아지더라고요.

    2. RAM: 많을수록 좋은 ZFS의 친구

    앞서 설명했듯이 ZFS는 RAM을 ARC로 활용합니다. RAM이 많으면 많을수록 디스크에 접근할 필요 없이 캐시에서 데이터를 바로 읽어올 확률이 높아져요. TrueNAS 공식 권장 사양은 8GB지만, 최소 16GB, 가능하다면 32GB 이상을 권장합니다. 저도 8GB에서 32GB로 업그레이드하고 나서 웹 인터페이스 반응 속도부터 파일 접근 속도까지 전반적인 성능 향상을 체감했습니다. 물론 ECC RAM(Error-Correcting Code RAM)을 사용하면 데이터 무결성을 더욱 확보할 수 있어 서버용으로는 거의 필수라고 봅니다.

    3. 네트워크: 병목 없는 고속도로

    아무리 NAS 내부 성능이 좋아도 네트워크 속도가 느리면 그걸 제대로 활용할 수 없어요. 특히 10기가비트 이더넷 (10GbE)은 대용량 파일 전송이나 여러 클라이언트가 동시에 고대역폭을 요구할 때 빛을 발합니다. 저도 처음엔 기가비트(1GbE)로 만족했지만, VM 백업이나 4K 영상 편집 작업을 하면서 10GbE NIC (Network Interface Card)의 필요성을 절실히 느꼈습니다. 10GbE 환경을 구축하려면 NAS뿐만 아니라 스위치(Switch)와 클라이언트 PC도 10GbE를 지원해야 한다는 점, 꼭 기억하세요!

    4. 스토리지: ZFS 성능의 핵심

    ZFS 성능의 가장 큰 변수는 역시 스토리지 구성입니다.

    4.1. 메인 풀 (Main Pool)

    • HDD (Hard Disk Drive): 대용량 저장에 유리하지만, 무작위 읽기/쓰기(Random Read/Write) 성능은 떨어집니다. 주로 RAIDZ1/2/3나 미러링(Mirroring)으로 구성합니다.
    • SSD (Solid State Drive): HDD보다 훨씬 빠른 읽기/쓰기 속도와 낮은 지연 시간(Latency)을 제공합니다. 가상 머신 스토리지나 고성능이 필요한 데이터 저장에 적합합니다.

    제 경험상, 홈랩에서는 메인 풀을 HDD로 구성하더라도, 중요한 서비스나 가상 머신 이미지는 별도의 SSD 풀에 두는 것이 성능 체감에 정말 효과적이었습니다.

    4.2. SLOG/ZIL 전용 장치

    동기 쓰기 성능을 높이는 가장 확실한 방법은 NVMe SSD를 SLOG 전용 장치로 사용하는 것입니다. SLOG는 쓰기 캐시 역할을 하므로, 매우 낮은 지연 시간과 높은 내구성(Endurance)을 가진 SSD가 필요합니다. 일반적으로 DRAM이 내장된 엔터프라이즈급 NVMe SSD가 권장되지만, 홈랩에서는 고성능 컨슈머 NVMe SSD도 충분히 효과를 볼 수 있습니다. 제가 직접 벤치마크해보니, SLOG 유무에 따라 동기 쓰기 성능이 수십 배 이상 차이 나는 걸 확인했습니다. ⚠️ 다만 주의할 점은, SLOG 장치는 갑작스러운 전원 손실에도 데이터가 안 날아가도록 전력 손실 보호(Power Loss Protection, PLP) 기능이 있는 제품을 선택해야 한다는 것입니다.

    4.3. L2ARC 전용 장치

    L2ARC는 읽기 캐시이므로, 꼭 최고 성능의 NVMe SSD를 사용할 필요는 없습니다. SATA SSD나 여유 있는 NVMe SSD를 활용해도 충분히 효과를 볼 수 있어요. 다만, L2ARC는 콜드 캐시(Cold Cache) 상태에서 효과가 미미하고, 시스템 RAM(ARC)을 먼저 채우기 때문에, RAM이 충분한 상태에서 L2ARC를 추가하는 것이 좋습니다. 제가 사용해 본 결과, L2ARC는 큰 데이터셋을 반복적으로 읽을 때 정말 유용하더라고요.

    실전 벤치마크와 최적화 과정

    이제 실제 성능을 측정하고 최적화하는 과정을 살펴볼게요. TrueNAS SCALE에서는 다양한 벤치마크 툴을 활용할 수 있습니다.

    1. 벤치마크 툴 준비

    TrueNAS SCALE은 Debian 기반이라 익숙한 리눅스 툴들을 사용할 수 있습니다.

    • fio (Flexible I/O Tester): 디스크 I/O 성능을 측정하는 데 가장 널리 사용되는 툴입니다. 순차 읽기/쓰기, 랜덤 읽기/쓰기, IOPS, 대역폭 등 다양한 시나리오를 테스트할 수 있죠.
    • iperf3: 네트워크 대역폭을 측정하는 툴입니다. 클라이언트와 서버 간의 실제 네트워크 속도를 확인할 때 유용해요.
    • arcstat: ZFS ARC 캐시의 상태를 실시간으로 모니터링합니다. 캐시 히트율, 메모리 사용량 등을 확인할 수 있습니다.

    TrueNAS SCALE 쉘(Shell)에서 fio를 설치하려면 다음 명령어를 사용합니다.

    
sudo apt update
sudo apt install fio

    2. ZFS 풀 구성 및 SLOG/L2ARC 추가

    ZFS 풀을 생성할 때, VDEV 구성은 매우 중요합니다. 미러(Mirror) 구성은 IOPS 성능이 좋고 복구 시간이 짧지만 용량 효율이 낮고, RAIDZ는 용량 효율이 좋지만 IOPS 성능이 미러보다 떨어지고 복구 시간이 길 수 있거든요. 저는 홈랩에서 가상 머신을 많이 돌리기 때문에 IOPS를 우선시해서 미러 구성을 선호하는 편입니다.

    SLOG와 L2ARC는 TrueNAS SCALE 웹 UI에서 간단하게 추가할 수 있습니다. ‘Storage’ > ‘Pools’ > ‘ADD’ 버튼 옆의 ‘…’ 메뉴 > ‘Add Vdevs’를 통해 캐시(Cache)나 로그(Log) VDEV를 추가할 수 있습니다.

    TrueNAS SCALE 웹 UI에서 ZFS 풀에 SLOG (Log Vdev)를 NVMe SSD로 추가하는 설정 화면

    TrueNAS SCALE 웹 UI에서 ZFS 풀에 SLOG (Log Vdev)를 추가하는 화면입니다.

    3. fio를 이용한 디스크 벤치마크 (Disk Benchmark with fio)

    fio 명령어를 이용해 다양한 시나리오로 ZFS 풀의 성능을 측정합니다. 예를 들어, 4KB 랜덤 쓰기 IOPS를 측정하는 명령어는 다음과 같습니다.

    
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --numjobs=4 --size=1G --time_for_run=60 --group_reporting --direct=1 --filename=/mnt/YourPoolName/fio_test_file
    • --name=random-write: 테스트 이름
    • --ioengine=posixaio: I/O 엔진
    • --rw=randwrite: 랜덤 쓰기 (randread는 랜덤 읽기, write는 순차 쓰기, read는 순차 읽기)
    • --bs=4k: 블록 사이즈 (Block Size)
    • --numjobs=4: 동시에 실행할 작업 수
    • --size=1G: 각 작업이 생성할 파일 크기
    • --time_for_run=60: 60초 동안 테스트 실행
    • --group_reporting: 모든 작업의 결과를 합쳐서 보여줌
    • --direct=1: O_DIRECT 플래그를 사용하여 OS 캐시를 우회
    • --filename=/mnt/YourPoolName/fio_test_file: 테스트 파일 경로

    SLOG를 추가하기 전후, L2ARC를 추가하기 전후로 이 테스트를 반복하면서 성능 변화를 기록해보세요. 순차 쓰기/읽기와 랜덤 쓰기/읽기를 모두 테스트하는 것이 정말 중요합니다.

    4. iperf3를 이용한 네트워크 벤치마크 (Network Benchmark with iperf3)

    NAS와 클라이언트 PC 양쪽에서 iperf3를 실행하여 실제 네트워크 대역폭을 측정합니다.

    NAS (서버 모드):

    
iperf3 -s

    클라이언트 PC (클라이언트 모드):

    
iperf3 -c [NAS의 IP 주소] -P 8
    • -s: 서버 모드
    • -c [IP 주소]: 클라이언트 모드로 지정된 IP에 연결
    • -P 8: 8개의 병렬 스트림(Parallel Stream)으로 테스트 (더 정확한 최대 대역폭 측정)

    이 테스트를 통해 1GbE, 2.5GbE, 10GbE 등 실제 네트워크 속도가 얼마나 나오는지 확인할 수 있습니다. 저도 이 테스트를 통해 ‘아, 디스크가 문제가 아니라 네트워크가 병목이었구나!’ 하고 깨달았던 적이 많습니다.

    fio 디스크 벤치마크 및 iperf3 네트워크 벤치마크 결과 대시보드

    ZFS 풀의 fio 벤치마크 결과와 iperf3 네트워크 벤치마크 결과를 보여주는 통합 대시보드 예시입니다.

    ⚠️ 실제 겪었던 삽질과 트러블슈팅

    제가 벤치마크와 최적화 과정을 거치면서 겪었던 몇 가지 문제점과 해결책들입니다. 아마 여러분도 비슷한 상황을 만날 수 있을 거예요.

    1. ‘SLOG를 추가했는데 왜 쓰기 성능이 그대로죠?’: 동기 쓰기(Synchronous Write)를 하는 애플리케이션(예: 데이터베이스, 가상 머신)이 아니면 SLOG 효과를 보기 어렵습니다. 비동기 쓰기(Asynchronous Write) 위주라면 SLOG보다 메인 풀 디스크 자체의 성능이 더 중요하거든요. 또한, SLOG 용량은 보통 RAM의 몇 배 정도로 충분하며, 너무 큰 SLOG는 오히려 낭비일 수 있습니다.
    2. ‘L2ARC를 추가했는데 RAM 사용량이 줄지 않아요!’: L2ARC는 ARC가 ‘꽉 찬’ 후에 활성화되기 시작합니다. 그리고 L2ARC 자체도 RAM을 인덱싱(Indexing)하는 데 사용하므로, L2ARC를 추가한다고 해서 RAM 사용량이 드라마틱하게 줄어들지는 않아요. 오히려 L2ARC 인덱스 때문에 RAM 사용량이 소폭 늘 수도 있습니다. L2ARC의 실제 효과를 보려면 충분한 RAM이 먼저 갖춰져야 합니다.
    3. ’10GbE를 달았는데 왜 속도가 안 나오죠?’: 네트워크 케이블, 스위치, 클라이언트 PC의 NIC가 모두 10GbE를 지원하는지 확인하세요. 특히 저가형 케이블이나 오래된 스위치는 실제 대역폭을 저하시킬 수 있어요. 그리고 CPU 사용량이 100%에 근접하는지 확인해보세요. NAS의 CPU가 병목일 수도 있으니까요.
    4. ‘ZFS 압축(Compression)을 켰더니 오히려 느려졌어요!’: 압축률이 낮은 데이터를 압축하거나, CPU 성능이 충분하지 않은 상태에서 고압축률 알고리즘을 사용하면 압축/해제 오버헤드 때문에 성능이 저하될 수 있습니다. lz4처럼 가벼운 압축 알고리즘은 성능 저하가 적으면서도 효과가 좋은 편이니, 테스트해보고 적용하는 것을 추천합니다.

    성능 벤치마크 결과 요약 및 최적화 팁

    다양한 테스트를 통해 제가 내린 결론은 다음과 같습니다.

    하드웨어 요소 ZFS 성능 기여 최적화 팁
    CPU 전반적인 시스템 응답성, ZFS 연산 처리 코어 수와 클럭이 높은 CPU 사용 (가상화, 다중 사용자 환경 시 중요)
    RAM 읽기 캐시(ARC) 성능, 시스템 안정성 최소 16GB, 가능하면 32GB 이상. ECC RAM 권장
    네트워크 클라이언트-NAS 간 데이터 전송 속도 10GbE NIC 및 인프라 구축. iperf3로 병목 확인
    SLOG (NVMe SSD) 동기 쓰기(Synchronous Write) 성능 필수: PLP 기능 있는 고성능 NVMe SSD 사용 (VM, DB 등)
    L2ARC (SSD) 반복적인 읽기(Read) 성능 RAM이 충분할 때 추가. SATA/NVMe SSD 활용 가능
    메인 풀 (HDD/SSD) 기본 저장 용량 및 성능 사용 목적에 따라 RAIDZ 또는 미러 구성. 고성능 요구 시 SSD 풀 별도 구성
    TrueNAS SCALE ZFS 성능 최적화 전략 요약 인포그래픽: CPU, RAM, 네트워크, 스토리지

    TrueNAS SCALE ZFS 성능 최적화를 위한 하드웨어별 전략을 한눈에 볼 수 있는 요약 인포그래픽입니다.

    마무리하며: 나만의 최적화를 찾아서

    TrueNAS SCALE ZFS 성능 최적화는 단순히 비싼 하드웨어를 때려 박는다고 끝나는 문제가 아닙니다. 자신의 사용 패턴과 예산에 맞춰 가장 큰 병목 구간을 찾아 해결하는 것이 정말 중요해요. 저도 처음엔 뭐가 문제인지 몰라 무작정 SSD를 사기도 하고, RAM을 증설하기도 했었죠. 하지만 벤치마크 툴을 사용해서 정확히 어떤 부분이 부족한지 확인하고, 그에 맞는 하드웨어나 설정을 변경하는 과정을 통해 훨씬 만족스러운 결과를 얻을 수 있었습니다.

    이 글에서 소개한 내용들이 여러분의 TrueNAS SCALE 환경을 더 빠르고 효율적으로 만드는 데 도움이 되었으면 좋겠네요. 삽질은 인프라 엔지니어의 숙명이지만, 그 삽질이 누군가에게는 귀한 경험이 될 수 있다는 걸 알기에 오늘도 이렇게 키보드를 두드립니다. 다음번에는 TrueNAS SCALE에서 컨테이너와 가상 머신을 더 효율적으로 운영하는 방법에 대해 다뤄볼까 합니다. 기대해주세요!