13년차의 서버실

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

[태그:] TrueNAS

  • [Nas] TrueNAS CORE에서 Unraid로 마이그레이션: 1년 사용 후기 및 선택 기준

    [Nas] TrueNAS CORE에서 Unraid로 마이그레이션: 1년 사용 후기 및 선택 기준

    TrueNAS CORE에서 Unraid로 마이그레이션: 1년 사용 후기 및 결정 기준

    안녕하세요, 13년차 인프라 엔지니어 ‘서버실’입니다. 홈랩을 운영하면서 다양한 장비들을 써보고 또 바꿔보고 있는데요. 오늘은 제가 1년 전에 겪었던 큰 변화, 바로 TrueNAS CORE에서 Unraid로 NAS 운영체제(OS)를 마이그레이션한 경험에 대해 이야기해보려 합니다. 지금 TrueNAS와 Unraid 사이에서 고민하거나, NAS 환경에 변화를 주고 싶은 분들이라면 제 경험담이 참고가 될 거예요.

    솔직히 말씀드리면, TrueNAS CORE는 정말 훌륭한 NAS OS입니다. ZFS(Zettabyte File System)라는 강력한 파일 시스템을 기반으로 데이터 무결성과 안정성 면에서는 타의 추종을 불허하죠. 저도 오랫동안 TrueNAS CORE를 사용하면서 데이터 손실 걱정 없이 잘 지냈습니다. 하지만 홈랩 환경이라는 게 항상 똑같지 않잖아요? 이런저런 실험을 하다 보니, 좀 더 유연하고 다양한 컨테이너(Container) 환경을 쉽게 구축하고 싶다는 욕구가 생기더라고요. 특히 Docker나 가상 머신(Virtual Machine, VM)을 좀 더 자유롭게 쓰고 싶어졌습니다.

    처음엔 TrueNAS SCALE을 고려하기도 했지만, 당시에는 아직 안정화가 덜 됐다는 판단이 들어서 다른 대안을 찾아봤어요. 그러다 눈에 들어온 게 바로 Unraid였습니다. 근데 이게 FreeBSD 기반의 TrueNAS CORE와는 완전히 다른 Linux 기반이라, 마이그레이션 결정까지 꽤나 고민이 많았죠. 과연 이 결정이 옳았을까요? 지금부터 그 1년 간의 여정을 솔직하게 풀어보겠습니다.

    TrueNAS CORE와 Unraid의 아키텍처 및 주요 기능 차이 비교 다이어그램

    TrueNAS CORE와 Unraid의 핵심 아키텍처 및 기능 차이를 한눈에 볼 수 있는 다이어그램입니다. 각 시스템의 장단점이 명확히 드러나죠.

    TrueNAS CORE vs. Unraid: 핵심 개념 이해하기

    먼저, 두 NAS 운영체제의 핵심 개념부터 간단히 짚고 넘어갈게요. 마이그레이션을 고려한다면 반드시 알아야 할 차이점들입니다.

    • TrueNAS CORE (FreeBSD 기반, ZFS): TrueNAS CORE는 FreeBSD 운영체제 위에 ZFS(Zettabyte File System)를 핵심으로 사용합니다. ZFS는 RAID-Z1, RAID-Z2, RAID-Z3 등 다양한 방식의 RAID를 소프트웨어적으로 구현하며, 데이터 무결성(Data Integrity)과 스냅샷(Snapshot), 복제(Replication) 기능이 강력해요. 드라이브(Drive)를 추가할 때는 기존 VDEV(Virtual Device)에 새 드라이브를 추가하거나, 새로운 VDEV를 만들어 풀(Pool)에 통합하는 방식입니다. 한 번 구성된 풀은 드라이브를 유연하게 추가/교체하기가 쉽지 않다는 특징이 있어요.
    • Unraid (Linux 기반, Array/Cache Pool): Unraid는 경량 Linux 배포판을 기반으로 하며, 독자적인 패리티(Parity) 시스템을 사용합니다. TrueNAS처럼 전통적인 RAID 방식이 아니라, 개별 드라이브들을 묶어 하나의 큰 스토리지 배열(Array)을 만들고, 그 중 하나 또는 두 개를 패리티 드라이브(Parity Drive)로 지정해 데이터를 보호하는 방식이에요. 가장 큰 장점은 드라이브 용량에 관계없이 자유롭게 드라이브를 추가/제거할 수 있다는 점입니다. 또한, SSD를 이용한 캐시 풀(Cache Pool)을 별도로 구성하여 성능을 높이는 게 일반적입니다.

    쉽게 말해, TrueNAS는 ‘데이터 안정성’에 방점을 두고 탄탄하게 설계된 엔터프라이즈(Enterprise)급 스토리지 솔루션이고, Unraid는 ‘유연성과 확장성’에 초점을 맞춘 홈랩 친화적인 솔루션이라고 볼 수 있어요. 제가 Unraid로 눈을 돌린 것도 바로 이 유연성 때문이었습니다.

    Unraid로의 마이그레이션: 선택 기준 비교표

    어떤 NAS OS를 선택할지는 개인의 사용 목적과 환경에 따라 크게 달라집니다. 제가 TrueNAS CORE에서 Unraid로 넘어가기로 결정했던 주요 기준들을 정리해봤어요. 비슷한 고민을 하고 계신 분이라면 이 표가 참고가 될 거라고 생각합니다.

    고려 사항 TrueNAS CORE가 더 적합한 경우 Unraid가 더 적합한 경우 제가 Unraid를 선택한 이유
    데이터 무결성 & 안정성 최고 수준의 데이터 보호(ZFS), 기업용 환경, 미션 크리티컬(Mission-critical) 데이터 개별 드라이브 오류 보호(패리티), 일반적인 홈 미디어/파일 서버 홈랩 환경에서 극단적인 무결성보다 유연성이 더 필요하다고 판단
    드라이브 확장성 새 VDEV 구성 또는 풀 확장 시 복잡성, 유연성 부족, 동일 용량 드라이브 권장 용량 무관하게 자유로운 드라이브 추가/제거, 유휴 드라이브 활용 용이 다양한 용량의 드라이브를 보유하고 있어 유연한 확장이 절실
    Docker & 가상화 Jail/Plugin(컨테이너), bhyve(가상화) 지원하나 리소스 관리 및 생태계 제한적 Docker 및 KVM 기반 VM 지원이 강력, 플러그인 생태계 활발, GUI 친화적 Docker 컨테이너를 더 쉽게, 더 많이 활용하고 싶었음
    하드웨어 요구사항 ZFS 특성상 ECC RAM 필수 권장, CPU 성능 중요 ECC RAM 필수 아님(권장), 저전력 CPU로도 충분, USB 부팅 기존 하드웨어 재활용 시 ECC RAM 제약이 덜함
    운영 편의성 초기 설정 후 안정적, 학습 곡선(Learning Curve) 존재 직관적인 웹 UI, 플러그인으로 기능 확장 용이, 활발한 커뮤니티 더 빠르고 쉽게 새로운 서비스를 배포하고 싶었음

    실전 마이그레이션 준비 및 과정

    마이그레이션은 항상 신중해야 합니다. 특히 데이터가 걸려있는 작업이니까요. 제가 진행했던 과정을 간략하게 설명해 드릴게요. ⚠️ 가장 중요한 것은 데이터 백업입니다. 어떤 상황이 발생할지 모르니, 반드시 핵심 데이터는 별도의 공간에 백업해두세요. 저는 외부 USB 드라이브와 클라우드를 활용했습니다.

    1. 데이터 백업 및 TrueNAS 풀 내보내기

    기존 TrueNAS CORE 시스템에서 중요한 데이터를 백업했습니다. 그리고 기존 ZFS 풀을 안전하게 내보내는(Export) 작업을 진행했어요. 이건 필수 단계는 아니지만, 혹시 모를 상황에 대비하는 차원이었습니다.

    sudo zpool export my_data_pool
    

    my_data_pool은 본인의 ZFS 풀 이름으로 바꿔주시면 됩니다. 이 명령은 풀을 비활성화하고 시스템에서 분리해요.

    2. Unraid USB 부트 드라이브 생성

    Unraid는 USB 드라이브로 부팅하는 방식입니다. 공식 웹사이트에서 다운로드한 툴을 사용해 USB를 만들었어요. 💡 팁: 안정적인 부팅을 위해 가급적 검증된 USB 3.0 드라이브를 사용하는 게 좋습니다.

    3. 하드웨어 세팅 및 Unraid 초기 설정

    기존 TrueNAS 서버의 드라이브들을 물리적으로 Unraid 서버에 연결하고, Unraid USB로 부팅했습니다. Unraid 웹 UI에 접속해서 초기 설정을 진행했죠. 여기서 패리티 드라이브를 지정하고, 데이터 드라이브들을 배열(Array)에 추가합니다. 저는 기존의 모든 드라이브를 Unraid에 연결하고, 가장 큰 용량의 드라이브를 패리티 드라이브로 지정했어요.

    Unraid 웹 인터페이스 메인 대시보드 화면 및 드라이브 배열 구성

    Unraid의 깔끔한 웹 인터페이스입니다. 드라이브의 상태, 패리티 동기화 여부, 캐시 풀 등을 한눈에 확인할 수 있어요.

    4. 데이터 복사

    가장 시간이 오래 걸리는 작업입니다. 기존 TrueNAS에 있던 데이터 드라이브들을 Unraid 시스템에 임시로 연결하고, rsync 명령어를 이용해 데이터를 Unraid 배열로 복사했어요. 이 과정에서 여러 번의 삽질이 있었습니다.

    rsync -avh --progress /mnt/old_truenas_drive/MyData/ /mnt/user/data/MyData/
    

    -a (archive mode), -v (verbose), -h (human-readable), --progress (진행 상황 표시) 옵션은 대용량 파일 복사 시 정말 유용해요. 특히 TrueNAS의 ZFS 스냅샷 때문에 생긴 .zfs 폴더나 권한 문제 때문에 애를 먹기도 했습니다. Unraid의 사용자(User) 및 공유(Share) 권한 설정을 제대로 이해하는 게 중요하더라고요.

    삽질 경험 및 트러블슈팅

    마이그레이션이 늘 순탄하지만은 않죠. 저도 몇 가지 삽질을 경험했습니다.

    • ⚠️ ZFS 풀 마운트 문제: TrueNAS의 ZFS 풀을 Unraid(Linux)에서 직접 읽어오려고 시도했는데, 생각보다 쉽지 않더라고요. zfs-fuse 같은 도구를 써보려 했으나, 안정성과 성능 문제로 포기하고 결국 드라이브를 하나씩 연결해서 rsync로 복사하는 방식을 택했습니다. 이 과정에서 드라이브를 여러 번 뺐다 끼웠는데, 이게 물리적인 삽질이더라고요. 그냥 안전하게 네트워크로 데이터를 옮기거나, SATA 포트가 충분하다면 동시에 연결해서 옮기는 게 정신 건강에 이롭습니다.
    • 💡 Unraid 공유 권한 설정: Unraid는 공유 폴더(Share) 단위로 사용자 권한을 설정해요. 처음에는 TrueNAS의 복잡한 권한 체계에 익숙해져 있다 보니 Unraid의 비교적 단순한 권한 설정에서 헷갈렸습니다. 특히 Docker 컨테이너에서 접근할 볼륨(Volume) 권한을 제대로 설정하지 않아 컨테이너가 파일을 생성하지 못하는 문제가 발생했더라고요. Unraid의 Users 탭에서 사용자 생성 및 권한을, Shares 탭에서 각 공유 폴더의 접근 권한을 꼼꼼히 설정해야 합니다.
    • ✅ Docker 컨테이너 전환: TrueNAS의 Jail이나 플러그인으로 운영하던 서비스들을 Unraid의 Docker로 옮기는 과정은 생각보다 훨씬 수월했어요. Unraid의 Community Applications(CA) 플러그인 덕분인데, 이게 마치 앱스토어처럼 다양한 Docker 템플릿을 제공해서 클릭 몇 번으로 Plex, Nextcloud, Home Assistant 같은 서비스들을 쉽게 설치할 수 있더라고요. 처음엔 TrueNAS의 iocage 명령어나 플러그인 설정에 익숙했었는데, Unraid의 Docker 환경은 신세계였습니다.

    1년 사용 후기: 장점과 단점

    Unraid로 마이그레이션하고 1년이 지난 지금, 저는 매우 만족하고 있어요. 주요 장점과 단점을 정리해볼게요.

    장점

    • 경이로운 드라이브 확장성: 가장 큰 만족 부분이에요. 집에 굴러다니던 1TB, 2TB, 4TB 드라이브들을 모두 활용해서 큰 스토리지 풀을 만들 수 있었거든요. 용량 증설이 필요할 때마다 새 드라이브를 사서 꽂기만 하면 되니, 정말 편하더군요.
    • 압도적인 Docker 생태계: Community Applications 플러그인 덕분에 다양한 서비스를 매우 쉽게 설치하고 관리할 수 있어요. 웹 UI에서 Docker 컨테이너를 시작, 중지, 업데이트하는 게 직관적이고, 트러블슈팅도 로그 확인이 쉽습니다.
    • KVM 기반 가상화: 가상 머신 관리가 정말 편리해요. Windows Server나 Ubuntu Server 같은 VM을 몇 번의 클릭으로 설치하고, 웹 UI에서 자원 할당이나 콘솔 접속까지 가능합니다.
    • 저전력 운영: 모든 드라이브가 항상 스핀업(Spin up)되어 있지 않고, 필요할 때만 깨어나기 때문에 전기 요금 절감에도 도움이 돼요.

    단점 및 아쉬운 점

    • ZFS의 부재: 역시 ZFS 특유의 데이터 무결성 검증이나 스냅샷 기능이 아쉬울 때가 있어요. Unraid의 패리티 시스템도 훌륭하지만, ZFS만큼 강력하진 않다는 느낌을 받습니다. 중요한 데이터는 별도의 백업 전략을 더 철저히 세워야겠다고 느꼈어요.
    • 성능: 개별 드라이브에 직접 접근하는 방식이라, 단일 파일에 대한 순차 읽기/쓰기 성능은 RAID 시스템보다 떨어질 수 있어요. 하지만 캐시 풀을 적극적으로 활용하면 대부분의 홈랩 환경에서는 충분한 성능을 제공합니다.
    Unraid에서 실행 중인 Docker 컨테이너 및 리소스 모니터링 대시보드

    Unraid에서 다양한 Docker 컨테이너들이 안정적으로 동작하는 모습입니다. 각 컨테이너의 리소스 사용량도 한눈에 파악할 수 있어요.

    결론: 어떤 NAS OS를 선택해야 할까?

    1년 간의 Unraid 사용 경험을 바탕으로, 어떤 분들이 어떤 NAS OS를 선택해야 할지 명확하게 추천해 드릴게요.

    • 최고의 데이터 안정성과 무결성, 그리고 엔터프라이즈급 기능을 원한다면 TrueNAS CORE (또는 SCALE)를 선택하세요. 특히 중요한 업무용 데이터를 다루거나, ZFS의 강력한 기능을 적극 활용하고 싶다면 TrueNAS가 정답이에요. ECC RAM과 안정적인 하드웨어 투자가 필수적입니다.
    • 유연한 드라이브 확장성, 강력한 Docker 및 가상화 기능, 그리고 쉬운 홈랩 환경 구축을 원한다면 Unraid를 선택하세요. 다양한 용량의 드라이브를 활용하고 싶거나, 미디어 서버, 스마트 홈 허브 등 여러 서비스를 Docker로 쉽게 운영하고 싶다면 Unraid가 탁월한 선택이 될 거예요. 초보자도 비교적 쉽게 접근할 수 있어요.

    제 경우, 홈랩 환경에서는 유연성과 확장성, 그리고 Docker의 편리함이 데이터 무결성의 최우선 순위보다 더 중요했어요. 그래서 Unraid로의 마이그레이션은 저에게 아주 만족스러운 결정이었습니다. 물론 ZFS의 강력함은 여전히 인정하고 존경합니다만, 제 사용 패턴에는 Unraid가 더 잘 맞았던 거죠.

    어떤 선택이든 정답은 없습니다. 중요한 건 자신이 무엇을 가장 중요하게 생각하는지 명확히 파악하고 그에 맞는 도구를 선택하는 것이에요. 이 글이 여러분의 현명한 NAS OS 선택에 조금이나마 도움이 되었기를 바랍니다. 다음번에는 Unraid에서 Docker 컨테이너를 더 효율적으로 관리하는 실전 팁에 대해 다뤄보겠습니다. 그때까지 즐거운 홈랩 생활하세요! 🎉

    TrueNAS와 Unraid의 장단점 및 추천 사용 시나리오 요약 인포그래픽

    TrueNAS와 Unraid, 두 NAS 운영체제의 핵심 장단점과 각 OS에 적합한 사용 시나리오를 한눈에 비교할 수 있는 요약 인포그래픽입니다.

  • [NAS] TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석

    [NAS] TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석

    [NAS] TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석

    홈랩(Home Lab, 개인 실험실) NAS를 오래 굴리다 보면 결국 한 번은 맞닥뜨리는 문제가 있습니다. 분명 처음엔 넉넉하다고 생각했는데, 백업 데이터와 미디어 파일, VM 이미지가 쌓이면서 어느 순간 용량이 바닥을 보더라고요. 저도 TrueNAS ZFS 확장을 몇 번 직접 해보면서 느낀 건, 그냥 디스크 하나 더 꽂는다고 끝나는 구조가 아니라는 점이었습니다. 특히 TrueNAS ZFS 확장은 성능과 안정성을 같이 봐야 해서, 잘못 접근하면 NAS 용량 증설은 됐는데 ZFS 성능이 애매해지는 경우가 생깁니다.

    처음엔 저도 “디스크 추가만 하면 되겠지?”라고 생각했었는데, ZFS(제트에프에스, 파일시스템+볼륨 매니저 통합 구조)는 생각보다 설계 철학이 명확합니다. 그래서 오늘은 성능 저하 없이 용량을 늘리는 방법에 초점을 맞춰서, 어떤 방식이 안전한지, 어떤 방식은 조심해야 하는지, 그리고 실제로 확인해야 할 명령어까지 한 번에 정리해보겠습니다.

    TrueNAS ZFS 확장 개요를 보여주는 아키텍처 이미지

    TrueNAS ZFS 확장 전략을 한눈에 보여주는 개요 다이어그램입니다. 기존 풀, vdev, 디스크 추가 방향을 직관적으로 이해할 수 있게 배치하면 좋습니다.

    왜 TrueNAS ZFS 확장이 까다로운가

    쉽게 말해 ZFS는 단순히 디스크 몇 개를 묶는 수준이 아니라, vdev(Virtual Device, 가상 장치) 단위로 성능과 안정성을 관리합니다. 그리고 여러 vdev가 모여 하나의 pool(풀)을 만들죠. 여기서 중요한 포인트가 있습니다. 풀은 확장하기 쉬워 보여도, 기존 vdev 구조는 생각보다 보수적으로 다뤄야 한다는 점입니다.

    예를 들어 mirror(미러, 동일 데이터 복제) vdev 2개로 풀을 만들었다면, 나중에 같은 형태의 mirror vdev를 하나 더 추가하는 건 비교적 자연스럽습니다. 반면 RAIDZ(레이드지, 패리티 기반 보호) vdev 하나로 구성한 풀은, 전통적으로는 그 vdev에 디스크 하나만 툭 추가하는 방식이 깔끔하지 않았거든요. 여기서 많은 분들이 삽질을 시작합니다. 저도 처음엔 이게 뭔가 싶었는데, 구조를 이해하고 나니 왜 ZFS가 그렇게 동작하는지 보이더라고요.

    핵심 개념: 성능 저하 없이 용량 늘린다는 말의 의미

    “성능 저하 없이”라는 표현을 좀 더 정확히 풀어보겠습니다. ZFS에서 성능은 대체로 다음 요소에 영향을 받습니다.

    • vdev 개수: 일반적으로 vdev가 늘어나면 병렬성이 좋아질 수 있습니다.
    • 각 vdev의 디스크 수와 형태: mirror인지 RAIDZ인지에 따라 IOPS(Input/Output Operations Per Second, 초당 입출력 작업 수) 특성이 달라집니다.
    • 디스크 크기와 속도의 균형: 느린 디스크가 섞이면 전체 체감이 나빠질 수 있습니다.
    • 확장 과정 중 resilver(리실버, 데이터 재동기화) 부하: 이 과정에서 일시적으로 성능이 떨어질 수 있습니다.

    즉, 용량만 늘어나는 방식과 용량과 성능 특성을 함께 유지하는 방식은 다릅니다. 실제로 써보니까 가장 덜 후회하는 방법은 아래 두 가지였습니다.

    1. 기존과 동일한 성격의 vdev를 추가해서 풀 병렬성을 유지하는 방법
    2. 기존 디스크를 하나씩 더 큰 디스크로 교체한 뒤 자동 확장(autoexpand, 자동 확장)을 활용하는 방법

    반대로, 크기나 성능이 제각각인 디스크를 즉흥적으로 추가하면 NAS 용량 증설은 되더라도 장기적으로 운영이 피곤해집니다. 특히 장애 대응할 때 구조가 복잡해지더라고요.

    TrueNAS ZFS 확장 방법 비교

    방법 언제 적합한가 ZFS 성능 영향 장점 주의점
    동일한 새 vdev 추가 베이에 여유가 있고 구조를 깔끔하게 유지하고 싶을 때 대체로 유리 병렬성 유지, 확장 논리 명확 같은 급의 디스크를 여러 개 준비해야 함
    기존 디스크 순차 교체 후 확장 베이 여유가 없고 현재 구조를 유지해야 할 때 구조 유지 측면에서 안정적 기존 풀 레이아웃 유지 리실버 시간이 길고 교체 순서가 중요
    서로 다른 특성의 vdev 혼합 추가 임시 증설이 급할 때 예측 어려움 당장 공간 확보 가능 장기 운영, 장애 대응, 체감 성능 모두 애매해질 수 있음

    여기서 제 경험상 가장 추천하는 건 “같은 성격으로 확장하기”입니다. 처음 설계를 mirror로 했다면 mirror로, RAIDZ로 했다면 이후 확장 시에도 같은 패턴을 유지하는 쪽이 관리가 편합니다.

    TrueNAS ZFS 확장 구조에서 pool과 vdev 관계를 설명하는 이미지

    pool 아래에 여러 vdev가 있고, 각 vdev 아래에 디스크가 연결되는 구조를 시각적으로 보여주는 이미지가 들어가면 이해가 훨씬 빠릅니다.

    실전 1: 새 vdev 추가로 TrueNAS ZFS 확장하기

    이 방법은 제가 홈랩에서 가장 선호하는 방식입니다. 이유는 단순합니다. 설계 의도를 망가뜨리지 않고 확장할 수 있거든요. 예를 들어 2디스크 mirror vdev 두 개로 운영 중이었다면, 같은 2디스크 mirror vdev를 하나 더 추가하는 식입니다.

    확장 전 확인

    먼저 현재 풀 구성을 확인합니다.

    zpool status
    zpool list
    zpool iostat -v 1

    zpool status는 현재 풀과 vdev 상태를, zpool list는 용량과 사용률을, zpool iostat -v 1은 vdev별 I/O 흐름을 보는 데 유용합니다. 저는 확장 전에 이 세 개는 거의 습관처럼 확인합니다. 나중에 비교하기 좋거든요.

    절차

    1. 새 디스크를 장착하고 시스템이 정상 인식하는지 확인합니다.
    2. 기존 풀의 vdev 레이아웃과 동일한 방식으로 새 vdev를 구성합니다.
    3. TrueNAS GUI 또는 CLI(Command Line Interface, 명령줄 인터페이스)에서 풀에 추가합니다.
    4. 추가 직후 I/O 분산과 용량 변화를 확인합니다.

    CLI 예시는 아래처럼 볼 수 있습니다. 디바이스 이름은 환경마다 다르니 반드시 직접 확인하셔야 합니다.

    zpool add tank mirror /dev/disk/by-id/driveA /dev/disk/by-id/driveB

    예시에서 tank는 풀 이름입니다. 이 명령은 새 mirror vdev를 기존 풀에 추가하는 형태입니다. 한 번 추가한 vdev는 쉽게 되돌리기 어렵다는 점, 꼭 기억하셔야 합니다. 제가 예전에 이름 비슷한 디스크를 잘못 보고 진행했다가 식은땀 좀 흘렸습니다 ㅎㅎ

    이 방식이 성능 면에서 유리한 이유

    새 vdev가 추가되면 풀은 더 많은 vdev에 I/O를 분산할 수 있습니다. 물론 워크로드 특성에 따라 체감은 다르지만, 최소한 구조적으로 병렬 처리 경로를 늘리는 방향이라 논리가 깔끔합니다. 특히 VM 저장소나 작은 파일이 많은 환경에서는 이 차이가 은근히 보이더라고요.

    실전 2: 디스크를 하나씩 교체해서 NAS 용량 증설하기

    베이(Bay, 디스크 장착 슬롯)가 꽉 찬 경우에는 이 방법이 현실적입니다. 기존 풀 구조는 유지하면서 디스크 용량만 키우는 방식이죠. mirror든 RAIDZ든 많이 쓰는 패턴인데, 핵심은 한 번에 하나씩 교체하고, 각 교체마다 리실버가 완전히 끝날 때까지 기다리는 것입니다.

    기본 흐름

    1. 현재 상태를 확인합니다.
    2. 기존 디스크 하나를 오프라인 처리하거나 교체 절차에 맞춰 분리합니다.
    3. 더 큰 디스크로 교체합니다.
    4. 리실버 완료를 기다립니다.
    5. 다음 디스크로 같은 작업을 반복합니다.
    6. 모든 디스크가 교체된 뒤 풀 확장 여부를 확인합니다.
    zpool status
    zpool offline tank /dev/disk/by-id/old-drive
    zpool replace tank /dev/disk/by-id/old-drive /dev/disk/by-id/new-drive
    zpool status

    실제 명령은 환경과 장치 식별 방식에 따라 달라질 수 있습니다. 그래서 저는 항상 /dev/disk/by-id 경로처럼 상대적으로 식별이 명확한 쪽을 선호합니다. /dev/sdX 같은 이름은 재부팅이나 장치 순서에 따라 헷갈릴 수 있거든요.

    자동 확장 확인

    디스크를 모두 더 큰 용량으로 바꾼 뒤에도 풀 크기가 바로 기대만큼 안 늘어나는 경우가 있습니다. 이럴 때는 autoexpand(자동 확장) 설정과 풀 상태를 확인해봐야 합니다.

    zpool get autoexpand tank
    zpool set autoexpand=on tank
    zpool online -e tank /dev/disk/by-id/new-drive

    처음엔 저도 “왜 디스크는 바뀌었는데 용량이 그대로지?” 싶었는데, 이런 부분에서 한 번씩 막히더라고요. 특히 교체 직후 바로 결과만 보고 판단하면 놓치는 게 있습니다. 리실버가 완전히 끝났는지부터 확인하셔야 합니다.

    리실버 진행 상태, 풀 상태, 디스크 교체 흐름을 보여주는 운영 화면 이미지가 있으면 실전 감각이 살아납니다.

    TrueNAS GUI에서 볼 때 체크할 포인트

    CLI가 제일 명확하긴 하지만, 실제 운영에서는 TrueNAS GUI도 꽤 자주 보게 됩니다. 제가 보통 체크하는 항목은 이 정도입니다.

    • Pool 상태: ONLINE인지, DEGRADED인지
    • Disk 상태: 새 디스크가 정상 인식됐는지
    • 작업 진행률: 리실버가 끝났는지
    • Capacity 변화: 예상한 만큼 용량이 반영됐는지
    • Alert: SMART 관련 경고나 I/O 오류가 없는지

    GUI가 편하긴 한데, 중요한 작업일수록 CLI로 최종 확인하는 습관을 추천드립니다. 화면상으론 정상처럼 보여도 세부 상태는 zpool status 쪽이 더 직설적입니다.

    ⚠️ 주의사항과 트러블슈팅

    여기서부터는 정말 실전 얘기입니다. 이 부분 때문에 삽질 좀 했습니다 ㅎㅎ

    1. 디스크 하나만 추가해서 RAIDZ를 키우려는 시도

    많이 하는 착각입니다. 기존 RAIDZ vdev가 있다고 해서, 거기에 디스크 하나를 단순 추가하는 방식이 항상 안전하고 익숙한 운영 패턴은 아닙니다. 운영 환경에서는 지원 여부와 절차를 현재 문서로 꼭 재확인하셔야 하고, 검증된 방식은 동일한 새 vdev 추가 또는 순차 교체라고 보시는 게 안전합니다.

    2. 크기가 다른 디스크를 섞어 넣는 문제

    ZFS는 동작은 하더라도, 실제 활용 가능한 용량과 균형은 가장 작은 축에 맞춰 생각해야 하는 경우가 많습니다. 그리고 확장 계획이 지저분해집니다. 처음엔 급해서 그렇게 넣고 싶어지는데, 나중에 교체 주기 맞출 때 정말 귀찮아집니다.

    3. 리실버 중 성능 저하를 무시하는 문제

    성능 저하 없이라는 말은 확장 중에도 항상 아무 영향이 없다는 뜻은 아닙니다. 리실버 중에는 읽기/쓰기 지연이 늘 수 있습니다. 그래서 중요한 건 최종 구조가 성능 저하를 만들지 않는 방향이어야 한다는 겁니다. 저는 대용량 복제나 스크럽(scrub, 무결성 검사) 작업과 겹치지 않게 시간대를 따로 잡습니다.

    4. 백업 없이 확장 작업부터 들어가는 문제

    이건 정말 강조하고 싶습니다. ZFS가 안정적이라고 해도, 확장 작업은 결국 저장장치 구성 변경입니다. 디스크 자체 불량, 케이블 문제, 슬롯 접촉 불량 같은 변수는 늘 있습니다. 백업 없는 확장은 자신감이 아니라 도박에 가깝습니다.

    5. 디바이스 이름을 대충 보고 진행하는 문제

    /dev/sda, /dev/sdb 같은 이름만 믿고 교체하다가 엉뚱한 디스크를 건드리면 정말 아찔합니다. 가능하면 시리얼 기반 식별 경로를 쓰시고, 작업 전후로 꼭 대조해보세요. 저는 메모장에 디스크 시리얼과 베이 위치를 적어두고 합니다. 이거 진짜 편하더라고요.

    검증: 확장 후 무엇을 확인해야 하나

    확장이 끝났다고 바로 안심하시면 안 됩니다. 최소한 아래 항목은 체크하시는 게 좋습니다.

    1. 풀이 ONLINE 상태인지 확인
    2. 예상한 만큼 총 용량이 늘었는지 확인
    3. 각 vdev에 I/O가 비정상적으로 쏠리지 않는지 확인
    4. 에러 카운터가 증가하지 않는지 확인
    5. SMART 상태와 온도를 점검
    zpool status -v
    zpool list
    zpool iostat -v 5
    smartctl -a /dev/sdX

    zpool iostat -v 5는 5초 단위로 상태를 보기에 좋습니다. 제가 직접 해보니 확장 직후에는 단순히 용량만 보지 말고, 실제로 파일 복사나 백업 작업을 한 번 흘려보내면서 vdev 반응을 같이 보는 게 좋았습니다. 그래야 “늘긴 늘었는데 뭔가 이상하게 굼뜬다” 같은 문제를 빨리 잡을 수 있거든요.

    TrueNAS ZFS 확장 전후 용량과 성능 비교 이미지

    확장 전후의 총 용량, 사용률, I/O 분산 상태를 비교한 대시보드 이미지가 들어가면 결과 섹션의 설득력이 높아집니다.

    어떤 확장 전략이 가장 현실적인가

    환경별로 정리해보면 이렇습니다.

    상황 추천 전략 이유
    디스크 베이에 여유가 있음 동일한 새 vdev 추가 구조 확장이 자연스럽고 병렬성 유지에 유리
    베이가 꽉 참 디스크 순차 교체 현재 레이아웃을 유지하면서 용량만 키우기 좋음
    임시로 공간만 급함 가능하면 정식 확장 전 임시 데이터 정리 무리한 혼합 구성은 장기적으로 손해

    혹시 이런 경험 있으신가요? 급하게 공간이 필요해서 손에 잡히는 디스크부터 넣고 싶은 순간이요. 저도 그랬습니다. 그런데 ZFS는 급한 마음으로 건드릴수록 나중에 구조가 발목을 잡는 편이더라고요. 그래서 제 기준에선 “지금 가장 쉬운 방법”보다 “3년 뒤에도 설명 가능한 구조”가 더 중요했습니다.

    자주 묻는 질문

    Q1. 디스크 추가만 하면 자동으로 성능도 같이 좋아지나요?

    항상 그렇진 않습니다. 어떤 형태의 vdev를 추가했는지, 워크로드가 순차 읽기 위주인지, 랜덤 I/O 위주인지에 따라 다릅니다. 다만 동일한 성격의 vdev를 추가하는 방식은 구조적으로 예측 가능성이 높습니다.

    Q2. NAS 용량 증설 시 제일 먼저 볼 명령은 뭔가요?

    저는 zpool status부터 봅니다. 상태를 모르고 작업하는 건 위험합니다. 그다음 zpool list, 필요하면 zpool iostat -v를 봅니다.

    Q3. ZFS 성능을 위해 SSD 캐시만 추가하면 해결되나요?

    캐시 장치는 특정 워크로드에서 도움이 될 수 있지만, 기본 풀 구조가 좋지 않으면 근본 해결은 아닙니다. 먼저 풀 레이아웃과 vdev 구성을 정리하는 게 우선입니다. 캐시는 그 다음입니다.

    정리: TrueNAS ZFS 확장은 구조를 지키는 쪽이 결국 이깁니다

    오늘 정리한 내용을 한 줄로 줄이면 이렇습니다. TrueNAS ZFS 확장은 단순히 디스크 추가가 아니라, vdev 구조를 어떻게 유지하느냐의 문제입니다. 성능 저하 없이 가고 싶다면 검증된 방식으로 접근하시는 게 맞습니다. 즉, 베이에 여유가 있으면 동일한 새 vdev를 추가하고, 여유가 없으면 기존 디스크를 하나씩 더 큰 용량으로 교체하는 쪽이 가장 현실적입니다.

    저도 처음엔 용량만 보면 되는 줄 알았는데, 실제로 써보니까 결국 중요한 건 장기 운영의 일관성이었습니다. ZFS 성능, 장애 대응, 다음 증설 계획까지 생각하면 설계를 흐트러뜨리지 않는 게 제일 낫더라고요. 다음 글에서는 스크럽 주기, SMART 모니터링, 백업 전략까지 묶어서 홈랩 NAS 운영 체크리스트로 정리해보겠습니다. 이전 글에서 다뤘던 스토리지 모니터링 내용과 같이 보시면 더 도움이 되실 겁니다.

    TrueNAS ZFS 확장 전략을 요약한 인포그래픽 이미지

    추천 확장 방식, 피해야 할 방식, 점검 명령어를 한 장으로 정리한 요약 인포그래픽 이미지가 마무리용으로 잘 어울립니다.

  • [Nas] TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    [Nas] TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 많은 인프라 엔지니어들이 한 번쯤 고민해봤을 주제, VMware ESXi 가상머신(Virtual Machine, VM)을 TrueNAS iSCSI 스토리지로 마이그레이션(Migration, 이전)하는 성공 사례를 들려드리려고 합니다. 저도 홈랩을 운영하면서 스토리지 확장의 필요성을 절감했고, 이 과정에서 꽤나 삽질을 했거든요. 하지만 결국 성공했고, 그 경험을 여러분과 나누고 싶습니다. 💡

    기존에 사용하던 로컬 스토리지의 용량이 부족해지거나, 더 나은 성능과 유연성을 위해 중앙 집중식 스토리지로 옮겨야 할 때가 있죠. 특히 ESXi 스토리지 이전은 단순히 데이터 복사 이상의 복잡한 과정이 필요합니다. 이때 TrueNAS iSCSI는 비용 효율적이면서도 강력한 대안이 될 수 있습니다. iSCSI VM 마이그레이션을 고민 중이라면, 오늘 이야기가 큰 도움이 될 겁니다.

    ESXi와 TrueNAS iSCSI 스토리지를 활용한 가상머신 마이그레이션 전체 구성도입니다.

    1. 핵심 개념 이해: ESXi, TrueNAS, 그리고 iSCSI

    본격적인 마이그레이션에 앞서, 핵심 기술들이 무엇인지 간단히 짚고 넘어갈게요. “아, 이건 또 뭐야?” 싶으실 수도 있지만, 기본을 알아야 삽질을 줄일 수 있거든요. 😉

    • VMware ESXi (이엑스아이): VMware에서 개발한 베어메탈(Bare-metal) 하이퍼바이저(Hypervisor)입니다. 쉽게 말해, 물리 서버 위에 직접 설치되어 여러 가상머신을 효율적으로 운영할 수 있게 해주는 소프트웨어죠. 저희 서버실의 모든 가상머신은 ESXi 위에서 돌아가고 있습니다.
    • TrueNAS (트루나스): 오픈소스 네트워크 스토리지(Network Attached Storage, NAS) 운영체제입니다. 강력한 ZFS 파일 시스템을 기반으로 데이터 무결성과 유연성을 제공하며, 파일 공유는 물론 iSCSI와 같은 블록 스토리지 서비스도 지원합니다. 저의 홈랩에서는 TrueNAS Core 버전을 사용하고 있습니다.
    • iSCSI (아이 스카시, Internet Small Computer System Interface): IP 네트워크를 통해 SCSI(Small Computer System Interface) 명령을 전송하는 기술 표준입니다. 원격 서버에 마치 로컬 디스크처럼 블록 스토리지(Block Storage)를 연결할 수 있게 해줍니다. NAS iSCSI 설정은 ESXi가 TrueNAS의 스토리지를 마치 물리 디스크처럼 인식하게 만드는 핵심 단계라고 할 수 있죠.

    2. TrueNAS iSCSI 타겟 설정: 스토리지 준비하기

    이제 TrueNAS에서 ESXi가 사용할 iSCSI 스토리지를 만들어볼 차례입니다. “어렵지 않을까?” 걱정 마세요. 제가 직접 해보니 몇 가지 단계만 잘 따라가면 됩니다.

    단계별 TrueNAS iSCSI 설정

    1. ZFS 데이터셋(Dataset) 생성: 먼저 iSCSI 타겟으로 사용할 ZFS 데이터셋을 만듭니다. 저는 pool01/iscsi-vm이라는 데이터셋을 만들었어요.
    2. iSCSI 서비스 활성화: TrueNAS 웹 GUI에서 Services -> iSCSI로 이동하여 서비스를 활성화하고, Start Automatically를 체크해줍니다.
    3. 포털(Portal) 생성: iSCSI 통신에 사용할 IP 주소와 포트를 지정합니다. Sharing -> Block Shares (iSCSI) -> Portals 탭에서 Add를 클릭하고 TrueNAS의 IP 주소를 입력합니다.
    4. 이니시에이터(Initiator) 및 인증 설정 (선택 사항): 보안을 위해 특정 ESXi 호스트만 접근하도록 제한하거나, CHAP(Challenge-Handshake Authentication Protocol) 인증을 설정할 수 있습니다. 저는 홈랩이라 간단히 모든 이니시에이터(ALL Initiators)를 허용했지만, 프로덕션 환경에서는 반드시 제한해야 합니다.
    5. 익스텐트(Extent, LUN) 생성: 실제 스토리지 공간을 정의합니다. Extents 탭에서 Add를 클릭하고, 이전에 생성한 ZFS 데이터셋을 경로로 지정합니다. 이 익스텐트가 ESXi에 LUN(Logical Unit Number)으로 보이게 됩니다.
    6. 타겟(Target) 생성 및 연결: 마지막으로 익스텐트와 포털을 연결하여 타겟을 만듭니다. Targets 탭에서 Add를 클릭하고, 이름을 지정한 후 생성한 포털과 익스텐트를 연결합니다.

    이렇게 하면 TrueNAS에서 iSCSI 타겟 설정이 완료됩니다. 생각보다 간단하죠? ✅

    TrueNAS 웹 인터페이스에서 iSCSI 타겟을 설정하는 화면

    TrueNAS 웹 인터페이스에서 iSCSI 타겟을 설정하는 모습입니다.

    3. ESXi iSCSI 이니시에이터 설정: 서버 연결하기

    이제 ESXi 호스트가 TrueNAS의 iSCSI 스토리지를 인식하도록 설정해야 합니다. vSphere Client를 이용하면 GUI 환경에서 쉽게 설정할 수 있습니다.

    단계별 ESXi 설정

    1. iSCSI 소프트웨어 어댑터 활성화: vSphere Client에서 ESXi 호스트를 선택하고 Configure -> Storage Adapters로 이동합니다. Add Software Adapter를 클릭하여 Software iSCSI 어댑터를 추가합니다.
    2. 동적 검색(Dynamic Discovery) 설정: 새로 추가된 iSCSI 어댑터를 선택하고 Adapters 탭에서 Dynamic Discovery를 클릭, Add를 눌러 TrueNAS의 iSCSI 포털 IP 주소를 입력합니다.
    3. 네트워크 리스캔(Rescan): Storage Adapters 뷰로 돌아와 Rescan Adapters를 클릭합니다. 잠시 후 TrueNAS의 iSCSI LUN이 새로운 디바이스로 나타나는 걸 확인할 수 있어요.
    4. 새로운 데이터스토어(Datastore) 생성: Storage -> Datastores 탭으로 이동하여 New Datastore를 클릭합니다. VMFS 타입을 선택하고, 방금 검색된 TrueNAS iSCSI LUN을 선택하여 데이터스토어를 생성합니다. 원하는 이름을 지정하고 VMFS 버전을 선택하면 됩니다.

    자, 이제 ESXi 호스트가 TrueNAS의 iSCSI 스토리지를 사용할 준비가 끝났습니다. “진짜 되는 거야?” 싶으시겠지만, 여기까지 잘 오셨다면 거의 다 된 겁니다! 🎉

    4. 가상머신 마이그레이션: iSCSI 스토리지 이전의 핵심

    가장 중요한 단계, 가상머신 마이그레이션입니다. ESXi 환경에서는 Storage vMotion(스토리지 v모션)이라는 멋진 기능 덕분에 가상머신을 끄지 않고도 스토리지를 이전할 수 있습니다. 하지만 vCenter Server가 없는 홈랩 환경에서는 콜드 마이그레이션(Cold Migration, VM 종료 후 이전)을 해야 할 수도 있어요.

    Storage vMotion을 이용한 마이그레이션 (vCenter Server 환경)

    1. vSphere Client에서 마이그레이션할 가상머신을 선택합니다.
    2. 가상머신을 오른쪽 클릭하고 Migrate를 선택합니다.
    3. Change storage only 옵션을 선택한 후 Next를 클릭합니다.
    4. 대상 데이터스토어로 TrueNAS iSCSI를 통해 생성한 새 데이터스토어를 선택합니다.
    5. 설정을 확인하고 Finish를 클릭하면 마이그레이션이 시작됩니다.

    콜드 마이그레이션을 이용한 마이그레이션 (vCenter Server 없는 환경)

    1. 마이그레이션할 가상머신을 종료(Power Off)합니다.
    2. vSphere Client에서 가상머신을 선택하고 Migrate를 선택합니다.
    3. Change storage only 또는 Change compute resource and storage 옵션을 선택합니다. (호스트도 변경할 경우)
    4. 대상 데이터스토어로 TrueNAS iSCSI 데이터스토어를 선택하고 마이그레이션을 진행합니다.

    마이그레이션 진행 상황은 vSphere Client의 Recent Tasks에서 확인할 수 있습니다. 저도 처음엔 “이게 진짜 되는 건가?” 반신반의했는데, 진행률이 올라가는 걸 보니 너무 뿌듯하더라고요. 😊

    VMware vSphere Client에서 가상머신 스토리지 마이그레이션이 진행되는 화면입니다.

    5. iSCSI 마이그레이션 중 겪었던 문제들과 해결법 ⚠️

    “13년차 엔지니어도 삽질을 하나요?” 네, 물론이죠! 저도 이 과정에서 몇 번의 난관에 부딪혔고, 덕분에 많은 것을 배웠습니다. 😅

    • 네트워크 설정 문제: 처음에는 마이그레이션 속도가 너무 느려서 답답했어요. 알고 보니 ESXi의 iSCSI 전용 VMkernel 어댑터에 점보 프레임(Jumbo Frames)을 설정하지 않았더라고요. MTU(Maximum Transmission Unit) 값을 9000으로 올리니 속도가 훨씬 빨라졌습니다. TrueNAS와 ESXi 양쪽 모두 설정해야 한다는 점을 잊지 마세요! 💡

      \n# ESXi CLI에서 MTU 설정 예시 (vmnic0이 iSCSI용 NIC일 경우)\nesxcli network ip interface set -i vmkX -m 9000\n    
    • iSCSI 타겟/이니시에이터 불일치: TrueNAS에서 설정한 iSCSI ACL(Access Control List)이나 CHAP 인증 정보가 ESXi와 일치하지 않아 연결이 안 되는 경우가 있었습니다. “왜 안 되는 거야!” 하며 몇 시간을 헤맸는데, 결국 사소한 오타 때문이었죠. 설정값을 꼼꼼히 확인하는 것이 정말 중요합니다.
    • TrueNAS 방화벽: 간혹 TrueNAS의 내장 방화벽이 iSCSI 트래픽을 막는 경우가 있어요. iSCSI 기본 포트(3260)가 열려 있는지 확인하거나, ESXi 호스트의 IP를 허용 목록에 추가해야 합니다.

    이런 문제들을 해결하면서 “아, 이래서 경험이 중요하구나” 싶더라고요. 멘토처럼 알려드리는 제 글이 여러분의 삽질을 조금이나마 줄여주기를 바랍니다.

    6. iSCSI 마이그레이션 검증: 드디어 성공했습니다! 🎉

    모든 설정과 마이그레이션이 끝나고, 이제 결과를 확인할 차례입니다. “잘 작동하는지”를 보는 건 엔지니어의 가장 큰 기쁨이죠.

    1. vSphere Client에서 확인: 마이그레이션된 가상머신의 Summary 탭을 확인하면 스토리지가 새로운 TrueNAS iSCSI 데이터스토어로 변경된 것을 볼 수 있어요. 가상머신을 구동해보세요!
    2. TrueNAS 대시보드 확인: TrueNAS 웹 GUI의 Reporting 또는 Dashboard에서 iSCSI 서비스의 활성화 여부, 연결된 이니시에이터 수, 그리고 스토리지 I/O(Input/Output) 성능 그래프를 통해 실제 데이터 통신이 이루어지고 있는지 확인할 수 있습니다.
    3. 성능 모니터링: 가상머신 내부에서 디스크 I/O 벤치마크 툴(예: CrystalDiskMark, fio)을 사용하여 성능이 예상대로 나오는지 확인해보는 것도 좋습니다.

    제가 직접 확인해보니, 기존 로컬 스토리지 대비 디스크 I/O 성능이 크게 개선된 것을 체감할 수 있었습니다. 특히 여러 가상머신이 동시에 디스크를 사용하는 환경에서 더욱 빛을 발하더라고요. iSCSI VM 마이그레이션은 정말 성공적인 선택이었습니다!

    TrueNAS 대시보드에서 iSCSI 스토리지의 실시간 성능을 모니터링하는 대시보드

    TrueNAS 대시보드에서 iSCSI 스토리지의 실시간 성능을 모니터링하는 모습입니다.

    7. 마무리: ESXi iSCSI 마이그레이션 과정에서 얻은 교훈

    VMware ESXi 가상머신을 TrueNAS iSCSI 스토리지로 마이그레이션하는 과정은 쉽지 않았지만, 그만큼 얻은 것도 많습니다. 유연한 스토리지 확장, 향상된 성능, 그리고 무엇보다 “내가 해냈다!”는 성취감이 가장 큰 소득이었죠.

    이 경험을 통해 저는 다음과 같은 교훈을 얻었습니다.

    • 사전 계획의 중요성: 네트워크 구성, IP 주소 할당, 인증 방식 등 모든 설정을 미리 계획하는 것이 삽질을 줄이는 지름길입니다.
    • 문서화의 생활화: 삽질 과정을 기록하고 해결책을 문서화하면 다음번에 비슷한 문제가 발생했을 때 시간을 크게 절약할 수 있습니다. (사실 저도 이 글을 쓰면서 다시 한번 정리하는 거거든요 ㅎㅎ)
    • 오픈소스의 힘: TrueNAS 같은 오픈소스 솔루션은 상용 제품 못지않은 강력한 기능을 제공하며, 홈랩 환경에서 다양한 실험을 가능하게 합니다.

    혹시 여러분도 가상머신 스토리지 마이그레이션을 고민하고 계셨다면, TrueNAS iSCSI를 한 번 고려해보세요. 물론 처음엔 헷갈릴 수 있지만, 제 경험담이 여러분의 길을 밝혀주는 작은 등불이 되기를 바랍니다. 다음번에는 ESXi와 TrueNAS를 활용한 고가용성(High Availability) 구성에 대해서도 다뤄볼 예정이니 기대해주세요! 👍

  • [Nas] NAS 전력 소비 최적화: 전기세 절감 및 효율적인 운영 가이드

    [Nas] NAS 전력 소비 최적화: 전기세 절감 및 효율적인 운영 가이드

    NAS 전력 소비 최적화: 전기세 절감 및 효율적인 운영 가이드

    안녕하세요. 13년차 인프라 엔지니어, 여러분의 홈랩 멘토 ’13년차의 서버실’입니다. 오늘은 많은 분들이 궁금해하는 NAS(Network Attached Storage)의 전력 소비 최적화, 즉 NAS 전기세 절감 방법을 얘기해볼게요. 홈랩을 운영하다 보면 24시간 켜두는 장비들이 많아지는데, 이 녀석들이 생각보다 꽤 많은 전기를 잡아먹더라고요. 특히 NAS는 데이터를 항상 안전하게 보관해야 하니 켜두는 시간이 길어질 수밖에 없는데, 그렇다고 전기세 폭탄을 맞을 수는 없겠죠? 제가 13년간 쌓아온 경험과 홈랩에서의 직접적인 실험을 바탕으로, NAS 절전을 실현하는 현실적인 방법들을 공유해드릴게요. Synology, TrueNAS 등 어떤 NAS를 사용하시든 도움이 될 만한 내용들로 가득 채웠으니, 끝까지 함께 해주세요!

    NAS 전력 소비 최적화 개요

    NAS 전력 소비, 왜 신경 써야 할까?

    NAS는 개인 클라우드, 미디어 서버, 백업 스토리지 등 다양한 용도로 활용되면서 24시간 켜두는 경우가 많습니다. 장시간 운영되는 만큼, 전력 소비는 곧 전기세로 직결되죠. 단순히 몇 천 원 아끼는 수준을 넘어, 몇 년간 누적되면 상당한 금액이 될 수 있어요. 게다가 전력 소비를 줄이는 것은 곧 장비의 발열 감소로 이어져 부품 수명 연장에도 긍정적인 영향을 미칩니다. 환경적인 측면에서도 에너지 효율을 높이는 게 중요하고요. 특히 홈랩 환경에서는 전기 요금이 고정 지출로 꾸준히 발생하기 때문에, NAS 절전은 선택이 아닌 필수예요. 제가 처음 홈랩을 시작했을 때, 몇 대의 NAS와 서버를 24시간 돌리면서 전기 계량기가 쉴 새 없이 돌아가는 걸 보고 적잖이 당황했거든요. 그때부터 ‘어떻게 하면 이 녀석들의 전력 소비를 줄일 수 있을까?’ 고민하기 시작했습니다.

    NAS 전력 소비 최적화, 무엇부터 시작할까?

    NAS 전력 소비 최적화는 크게 두 가지 방향으로 접근할 수 있어요. 첫째는 NAS 하드웨어 자체의 전력 효율을 높이는 것이고, 둘째는 소프트웨어적인 설정을 통해 절전을 강화하는 것입니다. 물론, NAS를 어떤 용도로 사용하느냐에 따라 최적화 방법은 달라질 수 있어요. 예를 들어, 항상 데이터를 써야 하는 서비스(예: Plex 서버의 실시간 트랜스코딩)를 운영한다면 무작정 절전 모드로만 돌리기는 어렵겠죠. 하지만 대부분의 경우, 유휴 시간(Idle time)을 활용한 절전은 충분히 가능합니다.

    1. 하드웨어 레벨에서의 최적화

    가장 근본적인 방법은 전력 효율이 좋은 NAS 하드웨어를 선택하는 거예요. 이미 NAS를 가지고 계신 분들이라면, 기존 장비에서 할 수 있는 최적화에 집중해야겠죠.

    • HDD vs SSD: SSD는 HDD에 비해 전력 소비가 훨씬 적습니다. OS나 자주 접근하는 데이터를 SSD에 설치하고, 대용량 데이터 저장용으로는 HDD를 사용하는 하이브리드 구성도 고려해볼 만해요.
    • 저전력 CPU/칩셋: NAS 제조사들은 저전력 설계를 강조하는 모델들을 출시합니다. 인텔의 저전력 프로세서(예: Celeron, Atom)나 ARM 기반 칩셋을 사용한 모델들이 상대적으로 전력 소비가 낮아요.
    • RAM 용량: 과도한 RAM은 불필요한 전력 소비를 유발할 수 있습니다. NAS 운영체제와 사용할 서비스에 필요한 만큼의 RAM만 장착하는 게 좋아요.
    • 확장 장치 최소화: 불필요한 외장 하드나 USB 장치 연결은 전력 소비를 늘립니다. 꼭 필요한 장치만 연결하고, 사용하지 않을 때는 분리하는 습관을 들이세요.

    2. 소프트웨어 레벨에서의 절전 설정 (Synology & TrueNAS 중심)

    대부분의 NAS 운영체제(OS)는 다양한 절전 기능을 제공해요. 이를 잘 활용하면 NAS 전기세 절감의 핵심을 잡을 수 있습니다. 제가 주로 사용하는 Synology DSM과 TrueNAS CORE를 중심으로 설명드릴게요.

    Synology 절전 설정 가이드

    Synology NAS는 사용자 친화적인 인터페이스 덕분에 절전 설정을 비교적 쉽게 할 수 있어요. 제가 사용하는 DS218+ 모델을 기준으로 설명드리겠습니다. (모델별로 메뉴 위치나 옵션이 약간 다를 수 있습니다.)

    1. HDD 최대 절전 모드 (HDD Hibernation): 가장 효과적인 절전 기능 중 하나예요. 일정 시간 동안 NAS에 접근이 없으면 HDD를 회전시키지 않고 저전력 상태로 진입시킵니다.
      • 설정 경로: 제어판 > 하드웨어 및 전원 > HDD 최대 절전 모드
      • 설정 팁: 너무 짧은 시간으로 설정하면 잦은 HDD 회전으로 오히려 전력 소비가 늘거나 데이터 접근 시 딜레이가 발생할 수 있어요. 보통 15분~30분 정도를 권장합니다. 파일 서버처럼 자주 접근하는 환경이라면 이 옵션을 비활성화하거나 매우 길게 설정해야 할 수도 있어요.
    2. 예약된 작업 (Scheduled Task): NAS를 사용하지 않는 특정 시간에는 전원을 끄고, 필요할 때 자동으로 켜지도록 설정할 수 있습니다. Synology 절전의 핵심 기능이죠.
      • 설정 경로: 제어판 > 전원 > 전원 스케줄
      • 설정 팁: 예를 들어, 밤 12시부터 아침 7시까지는 NAS 전원을 끄고, 아침 7시에 자동으로 켜지도록 설정하면 밤새 낭비되는 전력을 크게 아낄 수 있어요. 물론, 밤중에 백업이나 외부 접속이 필요한 경우에는 이 설정을 조정해야 합니다.
    3. 저전력 모드/고성능 모드: 일부 모델에서는 CPU 성능과 전력 소비 간의 균형을 조절하는 옵션을 제공합니다. NAS 전력 소비 최적화를 위해 사용 빈도가 낮은 시간에는 저전력 모드로 설정하는 걸 고려해볼 만해요.
      • 설정 경로: 제어판 > 하드웨어 및 전원 > 일반 탭 (모델에 따라 다름)

    Synology DSM에서 HDD 최대 절전 모드 설정 화면 예시

    TrueNAS CORE 절전 설정 가이드

    TrueNAS 절전은 Synology에 비해 조금 더 수동 설정이 필요해요. TrueNAS CORE는 전문적인 사용자들을 위한 OS이기 때문에 직관적이지는 않지만, 강력한 커스터마이징을 통해 절전을 구현할 수 있습니다. TrueNAS는 ZFS 파일 시스템을 사용하기 때문에 HDD의 ‘Spin Down’ (회전 중지) 개념이 Synology와는 조금 다르게 접근될 수 있어요. ZFS는 데이터 무결성을 위해 HDD를 항상 활성 상태로 유지하려는 경향이 있기 때문입니다.

    1. Spin Down 설정: TrueNAS에서도 HDD의 Spin Down 기능을 설정할 수 있어요. 하지만 ZFS의 특성상 잦은 Spin Down/Spin Up은 오히려 HDD 수명에 좋지 않다는 의견도 있으므로 신중하게 접근해야 합니다.
      • 설정 경로: System Settings > Advanced (또는 Services > Shell 에서 직접 설정)
      • 설정 방법: sysctl 명령어나 loader.conf 파일을 통해 vfs.zfs.prefetch_disable 같은 ZFS 관련 커널 파라미터를 조정하여 Spin Down을 유도할 수 있어요. 하지만 이는 매우 고급 설정이며, 잘못 건드리면 데이터 손실 위험이 있으므로 매우 주의해야 합니다. 제 홈랩에서는 기본 설정을 유지하거나, 꼭 필요한 경우에만 아주 긴 시간(예: 24시간 이상)으로 설정해두는 편이에요.
    2. Cron Job을 이용한 예약 재부팅/종료: Synology의 예약된 작업처럼, TrueNAS에서도 Cron Job을 이용하여 특정 시간에 NAS를 재부팅하거나 종료하도록 스케줄링할 수 있어요.
      • 설정 방법: Shell (또는 SSH)에 접속하여 crontab -e 명령어를 사용하여 원하는 시간에 shutdown -p now (종료) 또는 reboot 명령어가 실행되도록 설정합니다.
      • 예시: 매일 새벽 3시에 NAS를 종료하고 싶다면, crontab -e 편집기에서 0 3 * * * /sbin/shutdown -p now 와 같이 추가하세요.
    3. 서비스 관리: 사용하지 않는 서비스(예: Plex, Docker 컨테이너 등)는 중지하거나 비활성화하여 불필요한 CPU 및 디스크 I/O를 줄이는 게 TrueNAS 절전에 도움이 돼요.

    TrueNAS CORE Shell에서 Cron Job 설정 예시 (명령어 기반)

    실제 경험 기반의 트러블슈팅 및 주의사항

    NAS 전력 소비 최적화를 진행하다 보면 예상치 못한 문제에 부딪히기도 합니다. 제가 겪었던 몇 가지 상황과 해결책을 공유해드릴게요.

    • ⚠️ HDD 최대 절전 모드 진입 실패: 분명히 설정 시간은 지났는데 HDD가 계속 돌고 있다면?
      • 원인: SMB/AFP/NFS 등의 네트워크 공유 폴더에 지속적인 접근이 있거나, Plex/Download Station 같은 패키지 서비스가 백그라운드에서 디스크 I/O를 발생시키고 있을 수 있어요. Plex의 경우 라이브러리 스캔이 백그라운드에서 실행되면 HDD가 깨어납니다.
      • 해결책: Synology DSM의 리소스 모니터 (Resource Monitor)나 iotop (SSH 접속 후) 명령어를 사용하여 어떤 프로세스가 디스크를 사용하고 있는지 확인하고 해당 서비스를 일시 중지하거나 설정을 조정해줘야 해요. Synology의 경우, 일부 패키지는 자체적인 절전 방해 설정을 가지고 있을 수 있습니다.
    • ⚠️ 잦은 HDD Spin Down/Up으로 인한 노이즈 및 수명 저하 우려: 너무 짧은 시간으로 절전 모드를 설정하면, 잦은 HDD의 기동/정지음으로 인한 스트레스와 실제 수명 저하가 걱정될 수 있어요.
      • 해결책: 앞서 언급했듯, HDD 절전 모드 시간은 넉넉하게 설정하는 게 좋아요. 개인적으로는 15분~30분 이상을 권장하며, 데이터 접근 빈도가 높다면 과감히 비활성화하는 것도 방법입니다. NAS 전기세 절감보다는 안정성과 편의성을 우선하는 게 현명할 때도 있거든요.
    • ⚠️ 예약 종료 후 부팅 실패: 예약 종료 후 다음 날 NAS가 켜지지 않는 경우가 간혹 발생합니다.
      • 원인: ACPI(Advanced Configuration and Power Interface) 관련 문제거나, 전원 공급 장치(PSU)의 Wake-on-LAN(WOL) 기능 문제일 수 있어요.
      • 해결책: BIOS/UEFI 설정에서 ACPI S3/S4 모드 관련 설정을 확인하고, NAS 자체의 WOL 설정을 확인해봐야 해요. Synology의 경우 ‘Power On After Power Loss’ 옵션을 활성화하는 게 도움이 될 수 있습니다.

    전력 소비량 측정 및 검증

    실제로 얼마나 전력을 절감했는지 확인하는 것은 매우 중요해요. 그래야 동기 부여도 되고, 어떤 설정이 효과적인지 알 수 있으니까요.

    1. 스마트 플러그 활용: 가장 간편하고 현실적인 방법이에요. NAS 전원 코드에 스마트 플러그를 연결하여 실시간 전력 소비량과 누적 사용량을 측정할 수 있습니다. 다양한 스마트 플러그 앱에서 그래프 형태로 제공해주기 때문에 추이를 파악하기 좋아요.
    2. NAS 자체 모니터링 기능: Synology DSM이나 TrueNAS CORE 자체적으로도 시스템 리소스 및 전력 소비량에 대한 모니터링 기능을 제공하는 경우가 있습니다. (모델 및 OS 버전에 따라 다름)
    3. 전기 계량기 확인: 홈랩 전체의 전력 소비량을 파악하고 싶다면, 집의 메인 전기 계량기나 분전함에 설치된 전력 측정 장치를 활용할 수 있어요.

    제가 스마트 플러그로 측정한 결과, Synology NAS의 HDD 최대 절전 모드와 예약된 작업 기능을 적극적으로 활용했을 때, 유휴 시간 기준 평균 10~20W 정도의 전력 소비를 줄일 수 있었습니다. 24시간 작동하는 NAS임을 감안하면, 하루에 240Wh~480Wh, 한 달이면 약 7.2kWh~14.4kWh를 절약하는 셈이죠. 현재 전기 요금 단가를 생각하면 무시할 수 없는 수준입니다! 🎉

    스마트 플러그로 측정한 NAS의 시간별 전력 소비량 그래프 (절전 설정 적용 후)

    마무리하며: 현명한 NAS 운영을 위한 제언

    오늘은 NAS 전력 소비 최적화를 통해 NAS 전기세를 절감하고 효율적인 운영을 하는 방법에 대해 알아봤어요. 핵심은 하드웨어 선택과 소프트웨어 설정, 그리고 꾸준한 모니터링입니다.

    가장 중요한 건 ‘나의 NAS 사용 패턴’을 이해하는 거예요. 항상 고성능을 요구하는 작업을 하지 않는다면, 적극적으로 절전 기능을 활용하는 게 좋습니다. Synology의 직관적인 설정과 TrueNAS의 강력한 커스터마이징 옵션을 잘 조합하면, 성능 저하를 최소화하면서도 상당한 NAS 절전 효과를 얻을 수 있어요.

    제가 오늘 공유해드린 정보들이 여러분의 홈랩 운영에 도움이 되기를 바랍니다. 혹시 더 궁금한 점이나 여러분만의 절전 팁이 있다면 언제든지 댓글로 공유해주세요! 다음 글에서는 NAS의 성능을 한층 더 끌어올릴 수 있는 네트워크 구성 팁에 대해 다룰 예정이니 많이 기대해주세요. 😉

    NAS 전력 소비 최적화 핵심 요약

  • [HomeLabs] UPS와 홈서버 연동: Proxmox/TrueNAS 자동 종료 설정 완벽 가이드

    [HomeLabs] UPS와 홈서버 연동: Proxmox/TrueNAS 자동 종료 설정 완벽 가이드

    UPS와 홈서버 연동: Proxmox/TrueNAS 자동 종료 설정 완벽 가이드

    안녕하세요, 13년차의 서버실 주인장입니다. 홈랩을 운영하면서 가장 신경 쓰이는 부분이 뭘까요? 저는 주저 없이 전원 문제라고 말할 수 있어요. 특히 갑작스러운 정전은 애지중지 키워온 홈서버의 하드웨어뿐만 아니라, 그 안에 담긴 소중한 데이터까지 한순간에 날려버릴 수 있는 무서운 재앙이거든요.

    제가 처음 홈랩을 구성하고 몇 달 뒤였을 겁니다. 한창 드라마를 보는데 갑자기 집 전체가 퍽! 하고 암전되더라고요. 순간 ‘아, 망했다!’ 싶었죠. 다행히 서버는 무사했지만, 그날 이후로 UPS(무정전 전원 장치)의 필요성을 뼈저리게 느꼈습니다. 단순히 전원을 공급해주는 것을 넘어, 정전 시 서버를 안전하게 종료시키는 자동화가 정말 중요하다는 걸 깨달았죠.

    오늘은 저처럼 홈랩을 운영하시는 분들을 위해, UPS와 홈서버(특히 Proxmox VE와 TrueNAS)를 연동해서 정전 시 자동으로 시스템이 종료되도록 설정하는 방법을 차근차근 알려드릴게요. 13년 동안 이런저런 삽질을 하면서 터득한 경험을 바탕으로, 여러분은 좀 더 쉽게 성공하시길 바랍니다! 💡

    홈랩 UPS 연동 아키텍처: 정전 시 서버들을 안전하게 지키는 핵심 구성입니다.

    UPS와 NUT(Network UPS Tools)는 뭐 하는 건가요?

    먼저 핵심 개념부터 짚고 넘어갈게요. ‘UPS’는 다들 아실 겁니다. 쉽게 말해 보조 배터리 같은 역할을 하면서, 정전이 되면 일정 시간 동안 서버에 전원을 공급해주는 장치죠. 하지만 UPS의 진짜 가치는 단순히 전원을 유지하는 것을 넘어, 서버에게 “야, 지금 전기가 나갔어! 얼른 마무리하고 꺼져야 해!”라고 알려줄 수 있을 때 빛을 발합니다.

    이때 필요한 게 바로 NUT(Network UPS Tools)예요. NUT는 UPS와 서버 간의 통신을 담당하는 오픈소스 소프트웨어 스위트(Software Suite)입니다. UPS의 상태(배터리 잔량, 전원 상태 등)를 모니터링하고, 특정 조건(예: 배터리 잔량 20% 미만)이 되면 연결된 서버들에게 종료 신호를 보내는 역할을 하죠.

    • UPS 서버 (Server): 물리적인 UPS 장치에 직접 연결되어 UPS 상태를 읽어오는 역할을 해요. 보통 USB 케이블로 연결하죠. 이 서버에 upsd (UPS Daemon)가 실행되면서 다른 클라이언트들에게 UPS 정보를 제공합니다.
    • UPS 클라이언트 (Client): UPS 서버로부터 UPS 상태 정보를 받아, 특정 조건이 되면 스스로 종료하거나 미리 설정된 작업을 수행합니다. Proxmox VE나 TrueNAS 같은 홈서버들이 여기에 해당해요. upsmon (UPS Monitor)이 이 역할을 담당합니다.

    저는 보통 라즈베리 파이 같은 저전력 장치나, 최소한의 리소스를 할당한 가상 머신에 NUT 서버를 구성합니다. 아무래도 UPS가 서버 전체를 위한 장치이니, 그 정보를 관리하는 서버는 가급적 안정적이고 전력을 덜 먹는 게 좋더라고요.

    실전 구현: NUT 서버와 클라이언트 설정

    자, 이제 실전입니다. 저는 제가 직접 구성한 환경을 기준으로 설명해 드릴게요. UPS는 APC BR1500MS 같은 모델을 많이 쓰시는데, USB로 연결되는 대부분의 UPS는 NUT와 호환되니 크게 걱정하지 않으셔도 돼요. 제가 사용했던 UPS도 USB로 연결되는 모델이었거든요.

    1. NUT 서버 설정 (Debian/Ubuntu 기반 VM 또는 Raspberry Pi)

    먼저, UPS에 USB로 직접 연결될 NUT 서버를 설정해봅시다. 저는 Proxmox 위에 데비안(Debian) 가상 머신을 하나 띄워서 사용했어요.

    패키지 설치:

    sudo apt update
    sudo apt install nut

    /etc/nut/ups.conf 설정:
    이 파일은 UPS 장치의 종류와 연결 방식을 NUT에게 알려줍니다. UPS 모델에 따라 드라이버(driver)가 달라질 수 있으니, NUT 공식 문서를 참고해서 맞는 드라이버를 찾아주세요. 저는 usbhid-ups 드라이버를 사용했어요.

    [myups]
      driver = usbhid-ups
      port = auto
      desc = "My HomeLab UPS"
      # mincharge = 80  # 배터리 최소 충전량 (예: 80% 미만이면 경고)
      # override.battery.charge.low = 20 # 배터리 잔량 20% 미만 시 저전압 경고

    /etc/nut/nut.conf 설정:
    NUT의 동작 모드를 설정합니다. 여기서는 STANDALONE 대신 SERVER로 설정해야 다른 서버들이 이 UPS 정보를 가져갈 수 있어요.

    MODE=SERVER

    /etc/nut/upsd.users 설정:
    클라이언트들이 UPS 정보를 모니터링할 때 사용할 사용자 계정을 정의합니다. 보안을 위해 강력한 비밀번호를 사용하는 것이 좋겠죠.

    [upsmon]
      password = YourStrongPasswordHere
      actions = SET
      instcmds = ALL
      upsmon master

    /etc/nut/upsd.conf 설정:
    NUT 데몬이 어떤 IP 주소와 포트(기본 3493)에서 클라이언트의 연결을 받을지 설정합니다. 저는 홈랩 내부에서만 사용할 것이므로 내부 IP를 바인딩했어요.

    LISTEN 0.0.0.0 3493 # 모든 인터페이스에서 수신 (혹은 특정 내부 IP)

    NUT 서비스 재시작 및 확인:

    sudo systemctl restart nut-server nut-client
    sudo systemctl enable nut-server nut-client
    sudo upsc myups@localhost # UPS 정보 확인. 'myups'는 ups.conf에 설정한 이름입니다.

    upsc myups@localhost 명령어를 실행했을 때, UPS의 다양한 정보(배터리 잔량, 전압 등)가 잘 출력된다면 NUT 서버 설정은 성공입니다! 🎉

    NUT 서버 설정의 핵심, ups.conf 파일입니다. UPS 모델에 맞는 드라이버를 찾는 것이 정말 중요해요.

    2. Proxmox VE 클라이언트 설정

    이제 Proxmox VE 서버가 NUT 서버로부터 UPS 정보를 받아 정전 시 자동으로 종료되도록 설정해볼까요? Proxmox는 Debian 기반이라 NUT 클라이언트 설정이 비교적 간단해요.

    패키지 설치:

    apt update
    apt install nut

    /etc/nut/nut.conf 설정:
    Proxmox는 NUT 서버가 아닌 클라이언트 역할을 하므로 MODE=NETCLIENT로 설정합니다.

    MODE=NETCLIENT

    /etc/nut/upsmon.conf 설정:
    이 파일에서 어떤 UPS 서버를 모니터링할지, 그리고 어떤 조건에서 종료할지 정의합니다. MONITOR 라인에 NUT 서버의 IP 주소, UPS 이름, 사용자 이름, 비밀번호를 입력하세요.

    MONITOR [email protected] 1 upsmon YourStrongPasswordHere master
    # (192.168.1.100은 NUT 서버의 IP 주소로 바꿔주세요)
    
    MINWARNTIME 300   # UPS 경고 발생 후 최소 5분 대기
    FINALDELAY 5      # 시스템 종료까지 추가 대기 시간 (초)
    SHUTDOWNCMD "/sbin/shutdown -h now" # 종료 명령
    NOTIFYCMD "/usr/sbin/upssched-cmd" # 알림 스크립트 (선택 사항)
    
    NOTIFYFLAG ONLINE SYSLOG+WALL
    NOTIFYFLAG ONBATT SYSLOG+WALL
    NOTIFYFLAG LOWBATT SYSLOG+WALL
    NOTIFYFLAG FSD SYSLOG+WALL
    
    # Proxmox의 경우, 가상머신 및 컨테이너를 먼저 종료해야 합니다.
    # 저는 아래와 같이 별도 스크립트를 만들어서 사용했어요.
    # /etc/nut/upsmon.conf 에 직접 넣기보다는, SHUTDOWNCMD가 실행할 스크립트 안에 넣는 것이 좋습니다.
    # (예시: /etc/nut/ups_shutdown.sh)
    # SCRIPT: /etc/nut/ups_shutdown.sh
    # (스크립트 예시는 뒤에서 설명합니다)

    Proxmox 특화: 가상 머신/컨테이너(VM/CT) 종료 스크립트
    Proxmox는 단순히 shutdown -h now만 실행하면 호스트만 꺼지고 VM/CT는 강제 종료될 수 있어요. 이를 방지하려면 VM/CT를 먼저 안전하게 종료하는 스크립트를 작성하여 SHUTDOWNCMD에 연결해야 합니다. 저는 다음과 같은 스크립트를 사용했습니다.

    #!/bin/bash
    
    logger -t ups_shutdown "UPS shutting down Proxmox and VMs/CTs..."
    
    # 모든 VM 및 CT 목록 가져오기
    vms=$(qm list | awk 'NR>1 {print $1}')
    cts=$(pct list | awk 'NR>1 {print $1}')
    
    # VM 종료
    for vmid in $vms
    do
      status=$(qm status $vmid | awk '{print $2}')
      if [ "$status" = "running" ]; then
        logger -t ups_shutdown "Shutting down VM $vmid..."
        qm shutdown $vmid --timeout 30
        sleep 5
        if [ "$(qm status $vmid | awk '{print $2}')" = "running" ]; then
          logger -t ups_shutdown "VM $vmid did not shut down gracefully, stopping..."
          qm stop $vmid
        fi
      fi
    done
    
    # CT 종료
    for ctid in $cts
    do
      status=$(pct status $ctid | awk '{print $2}')
      if [ "$status" = "running" ]; then
        logger -t ups_shutdown "Shutting down CT $ctid..."
        pct shutdown $ctid --timeout 30
        sleep 5
        if [ "$(pct status $ctid | awk '{print $2}')" = "running" ]; then
          logger -t ups_shutdown "CT $ctid did not shut down gracefully, stopping..."
          pct stop $ctid
        fi
      fi
    done
    
    logger -t ups_shutdown "All VMs/CTs processed. Shutting down Proxmox host."
    sleep 10 # VM/CT 종료 대기 시간을 충분히 줍니다.
    /sbin/shutdown -h now

    이 스크립트를 /etc/nut/ups_shutdown.sh 로 저장하고 실행 권한을 부여한 뒤,

    sudo chmod +x /etc/nut/ups_shutdown.sh

    /etc/nut/upsmon.conf 파일의 SHUTDOWNCMD를 다음과 같이 수정하세요.

    SHUTDOWNCMD "/etc/nut/ups_shutdown.sh"

    NUT 클라이언트 서비스 재시작 및 확인:

    systemctl restart nut-client
    systemctl enable nut-client
    upsc [email protected] # NUT 서버의 UPS 정보 확인

    3. TrueNAS 클라이언트 설정

    TrueNAS는 NUT 클라이언트 기능이 웹 인터페이스에 통합되어 있어 설정이 훨씬 간편합니다. 제가 써보니 이 부분이 정말 편하더라고요!

    1. TrueNAS 웹 UI에 접속하세요.
    2. 좌측 메뉴에서 Services (서비스)를 클릭합니다.
    3. 서비스 목록에서 UPS를 찾아 Configure (설정) 버튼을 클릭하세요.
    4. 설정 창에서 다음 정보를 입력합니다:
      • UPS Type (UPS 유형): Slave (클라이언트 역할을 하므로)
      • Remote Host (원격 호스트): NUT 서버의 IP 주소 (예: 192.168.1.100)
      • Remote Port (원격 포트): 3493 (기본값)
      • Identifier (식별자): NUT 서버의 ups.conf에 설정한 UPS 이름 (예: myups)
      • Monitor User (모니터 사용자): upsmon (upsd.users에 설정한 사용자)
      • Monitor Password (모니터 비밀번호): YourStrongPasswordHere (upsd.users에 설정한 비밀번호)
      • Shutdown Mode (종료 모드): UPS reaches low battery (UPS 배터리가 부족할 때)
      • Shutdown Timer (종료 타이머): 120 (배터리 부족 감지 후 120초 뒤 종료)
    5. Save (저장) 버튼을 클릭하세요.
    6. 서비스 목록으로 돌아가서 UPS 서비스를 Enabled (활성화)로 설정하고 Start (시작) 버튼을 클릭합니다.

    TrueNAS 로그를 확인하여 UPS 서비스가 정상적으로 시작되었는지, NUT 서버와 통신하는지 확인해 보세요. /var/log/messages나 웹 UI의 시스템 로그에서 관련 메시지를 찾을 수 있어요.

    TrueNAS의 UPS 설정 화면입니다. 웹 UI 덕분에 직관적으로 설정할 수 있어요.

    ⚠️ 주의사항 및 트러블슈팅 (제 삽질 경험 공유)

    제가 이 설정을 하면서 겪었던 몇 가지 삽질 경험과 주의사항을 알려드릴게요. 여러분은 저처럼 고생하지 마시길!

    1. 방화벽 문제: NUT 서버와 클라이언트 간에 3493번 포트 통신이 제대로 되는지 꼭 확인하세요. 특히 NUT 서버로 설정한 VM이나 물리 장치에 ufw나 firewalld 같은 방화벽이 있다면 3493번 포트를 열어줘야 해요. sudo ufw allow 3493/tcp 같은 명령어로 열 수 있습니다. 저는 처음에 이걸 놓쳐서 ‘왜 연결이 안 되지?’ 하고 한참을 헤맸습니다. ㅠㅠ
    2. USB 드라이버 문제: UPS가 USB로 NUT 서버에 제대로 인식되지 않는 경우가 간혹 있어요. lsusb 명령어로 UPS 장치가 목록에 뜨는지 확인하고, dmesg | grep -i usb 명령어로 커널 로그를 확인해서 드라이버 로딩에 문제가 없는지 봐야 합니다. 간혹 특정 UPS 모델은 추가적인 드라이버나 커널 모듈이 필요할 수 있거든요.
    3. ups.conf 드라이버 오설정: 가장 흔한 실수 중 하나예요. UPS 모델에 맞는 정확한 드라이버를 사용해야 합니다. nut-drivers 패키지 설치 후 man ups.conf나 NUT 공식 문서를 참고하는 게 가장 정확합니다.
    4. 종료 스크립트 테스트: 실제 정전 상황을 흉내 내기 어렵다면, 강제로 lowbatt 신호를 보내는 방식으로 테스트할 수 있어요. sudo upsmon -c fsd (Force Shutdown) 같은 명령어를 사용하거나, upsmon.conf에서 SHUTDOWNCMD를 테스트용 스크립트로 바꿔서 실행해 보는 것도 좋은 방법입니다. 절대 운영 중인 서버에서 바로 테스트하지 마세요! 중요한 데이터가 날아갈 수 있습니다. 테스트는 항상 충분히 백업된 환경이나 테스트용 서버에서 진행하시고, 스크립트 실행 권한(chmod +x)도 잊지 마세요!
    5. Proxmox VM/CT 종료 순서: 위에서 설명했듯이 Proxmox는 호스트만 종료하면 VM/CT가 강제 종료돼요. 반드시 qm shutdown, pct shutdown 명령어를 사용하여 순차적으로 종료하는 스크립트를 사용해야 합니다.

    검증 및 결과: 이제 안심하고 홈랩을!

    모든 설정이 끝났다면, 이제 정말 잘 작동하는지 확인해야겠죠? 저는 조심스럽게 UPS의 전원 코드를 뽑아서 실제 정전 상황을 시뮬레이션해봤습니다. (물론 중요한 작업은 모두 백업해두고, 아주 짧게 시도했어요.)

    결과는? 🎉 대성공이었습니다!

    UPS가 배터리 모드로 전환되고, 설정해둔 MINWARNTIME이 지나자 Proxmox와 TrueNAS가 순차적으로 종료되기 시작했어요. Proxmox의 경우, 제가 만들어둔 스크립트 덕분에 VM과 CT들이 먼저 안전하게 꺼진 후 호스트가 종료되는 것을 로그로 확인할 수 있었습니다. TrueNAS도 깔끔하게 종료되었고요.

    로그 확인은 journalctl -u nut-client.service (Proxmox/Debian)나 /var/log/messages (TrueNAS)를 통해 할 수 있습니다. 여기에 UPS 상태 변화와 종료 명령이 정상적으로 기록되어 있다면 안심해도 좋아요.

    시스템 로그에서 확인하는 자동 종료 과정. 이 메시지를 보면 정말 뿌듯하더라고요!

    마무리하며: 홈랩의 든든한 보험, UPS 연동

    오늘은 홈랩의 안정성을 한 단계 끌어올리는 UPS 홈서버 연동, 특히 Proxmox UPS와 TrueNAS UPS 자동 종료 설정에 대해 알아봤습니다. 처음에는 NUT 설정이 조금 복잡하게 느껴질 수도 있지만, 한 번 제대로 설정해두면 갑작스러운 정전에도 소중한 장비와 데이터를 안전하게 지킬 수 있어요. 이건 마치 홈랩을 위한 든든한 보험 같은 존재랄까요?

    저도 처음엔 ‘이거까지 해야 하나?’ 싶었는데, 한번 정전을 겪고 나니 이제는 홈랩의 필수 요소라고 생각합니다. 여러분도 이 가이드를 통해 성공적으로 UPS 연동을 마치시고, 마음 편히 홈랩을 즐기시길 바랍니다. 다음번에는 또 다른 흥미로운 홈랩 이야기로 찾아올게요! 그때까지 즐거운 삽질(?) 되세요! 😉

    UPS 연동의 핵심 가치: 안전한 홈랩, 데이터 보호, 그리고 마음의 평화!

  • [HomeLabs] 홈랩 NAS OS 비교: TrueNAS, Unraid, OpenMediaVault 선택 가이드

    NAS OS, 뭘 골라야 할지 모르겠다면 — 이 글이 딱입니다

    홈랩을 처음 시작하거나, 기존 홈서버를 업그레이드하려고 할 때 가장 먼저 맞닥뜨리는 고민이 있죠. 바로 “NAS OS를 뭘 써야 하지?”라는 질문입니다.

    저도 딱 그랬거든요. 13년 전에 처음 홈랩을 꾸릴 때, 지금처럼 선택지가 많지 않았는데도 뭘 써야 할지 한참 고민했었습니다. 지금은 오히려 선택지가 너무 많아서 더 헷갈리는 상황이 됐더라고요. 홈랩 NAS OS 비교를 제대로 해놓은 한국어 글이 정말 드물어서, 제가 직접 써봤던 경험을 토대로 정리해 드리려고 합니다.

    오늘 다룰 세 가지는 TrueNAS, Unraid, OpenMediaVault(OMV)입니다. 이 셋이 현재 홈서버 커뮤니티에서 가장 널리 쓰이는 NAS 전용 OS들이에요. 각각 철학도 다르고, 강점도 다르고, 적합한 사용자 유형도 다릅니다. 끝까지 읽으시면 본인 상황에 맞는 선택이 보일 거예요.

    TrueNAS, Unraid, OpenMediaVault — 홈랩 NAS OS 3대장의 구조와 특성을 한눈에 비교한 다이어그램


    먼저 알아야 할 개념들 — NAS OS가 뭐가 다른 거야?

    일반 OS(Ubuntu, Windows)에 Samba나 NFS 서버를 올려도 NAS는 됩니다. 근데 왜 굳이 NAS 전용 OS를 쓰냐고요? 쉽게 말해서, 파일 서버에 특화된 기능들이 처음부터 내장되어 있기 때문입니다.

    • 스토리지 풀(Storage Pool): 여러 개의 디스크를 하나의 논리적 공간으로 묶는 기능
    • RAID / 패리티(Parity): 디스크 장애 시 데이터를 보호하는 기술
    • 스냅샷(Snapshot): 특정 시점의 파일 시스템 상태를 저장해두는 기능
    • SMB / NFS / AFP 공유: Windows, Linux, macOS와 파일을 주고받는 프로토콜
    • WebUI: 터미널 없이 웹 브라우저로 관리하는 인터페이스

    이런 것들을 일반 OS에서 직접 구성하려면 시간이 꽤 걸리는데, NAS OS는 이걸 다 묶어서 제공해 줍니다. 물론 각 OS마다 접근 방식이 완전히 다르거든요. 그게 핵심 차이입니다.


    TrueNAS — 기업급 신뢰성을 홈랩에

    TrueNAS가 뭔지 간단히

    TrueNAS는 iXsystems라는 회사에서 만든 오픈소스 NAS OS입니다. 예전에 FreeNAS라는 이름으로 불렸는데, 2020년에 TrueNAS CORE(FreeBSD 기반)와 TrueNAS SCALE(Linux/Debian 기반)로 분리됐어요.

    • TrueNAS CORE: FreeBSD 기반, ZFS 파일시스템, 오랜 역사와 안정성
    • TrueNAS SCALE: Linux(Debian) 기반, ZFS + 쿠버네티스(Kubernetes) 앱 지원

    핵심은 ZFS(제트파일시스템)입니다. ZFS는 데이터 무결성 검증, 스냅샷, 압축, 중복 제거 등 엔터프라이즈급 기능을 모두 갖춘 파일시스템이에요. 실제로 기업 스토리지에서도 쓰이는 기술이거든요.

    직접 써본 느낌

    제가 처음 TrueNAS CORE를 설치했을 때, 솔직히 WebUI가 좀 무겁다는 느낌을 받았습니다. 근데 한 번 익숙해지니까 이게 진짜 탄탄하더라고요. ZFS 풀을 구성하고 스냅샷 자동화 설정해두면, 데이터 보호 측면에서는 진짜 안심이 됩니다. 실제로 디스크 하나가 죽었을 때 데이터 손실 없이 교체한 경험이 있어요. 그때 TrueNAS 믿음이 생겼습니다 ㅎㅎ.

    TrueNAS 장단점

    • ✅ ZFS의 강력한 데이터 무결성 보호
    • ✅ 스냅샷, 복제(Replication) 기능이 훌륭함
    • ✅ 기업급 안정성, 오랜 커뮤니티
    • ✅ SCALE 버전은 Docker/쿠버네티스 앱 지원
    • ⚠️ ZFS 특성상 ECC 메모리 권장 (없어도 쓸 수는 있지만…)
    • ⚠️ RAM을 꽤 먹음 — ZFS ARC 캐시가 메모리를 적극 활용함
    • ⚠️ 디스크를 나중에 개별로 추가하기가 까다로움 (풀 단위로 관리)
    • ⚠️ 초보자에게는 진입 장벽이 있음

    이런 분께 추천

    데이터 보호를 최우선으로 생각하시는 분, 스냅샷과 복제를 활용한 백업 체계를 구축하고 싶은 분, 그리고 서버 하드웨어에 투자할 여유가 있는 분께 딱 맞습니다.


    Unraid — 유연함의 끝판왕

    Unraid는 왜 독특한가

    Unraid는 Lime Technology라는 회사의 상용 소프트웨어입니다. 무료가 아니에요 — 라이선스 구매가 필요합니다. 근데 홈랩 커뮤니티에서 엄청난 인기를 끌고 있는 이유가 있습니다.

    Unraid의 핵심 철학은 “다른 크기의 디스크를 자유롭게 섞어 쓸 수 있다”는 겁니다. 일반 RAID는 같은 크기의 디스크로 묶어야 하는데, Unraid는 그냥 디스크를 하나씩 배열(Array)에 추가하면 돼요. 4TB 하나, 8TB 하나, 12TB 하나 — 이렇게 섞어도 됩니다. 패리티(Parity) 디스크가 보호해주는 구조거든요.

    그리고 Docker 컨테이너와 VM(가상머신) 지원이 정말 잘 되어 있어요. Community Applications(CA)라는 앱 스토어 개념이 있어서, 클릭 몇 번으로 Plex, Jellyfin, Home Assistant 같은 앱을 설치할 수 있습니다. 처음 써봤을 때 “이거 진짜 편하다”는 생각이 절로 들더라고요.

    Unraid의 WebUI — 디스크 배열(Array), Docker 컨테이너, VM을 하나의 인터페이스에서 관리할 수 있다

    Unraid 장단점

    • ✅ 다른 크기의 디스크를 자유롭게 혼합 가능
    • ✅ 디스크 개별 추가/제거가 매우 유연함
    • ✅ Docker + VM 지원이 홈랩에 최적화
    • ✅ Community Applications(커뮤니티 앱 스토어)로 앱 설치 간편
    • ✅ WebUI가 직관적이고 초보자도 접근하기 쉬움
    • ⚠️ 유료 라이선스 필요 (USB 기반 라이선스 구조)
    • ⚠️ 배열 디스크가 개별 파일시스템(XFS/BTRFS)으로 관리됨 — ZFS 같은 통합 무결성 검증 없음
    • ⚠️ 패리티 검사(Parity Check) 중에는 성능이 떨어짐
    • ⚠️ 오픈소스가 아님

    이런 분께 추천

    다양한 크기의 디스크를 점진적으로 추가하며 스토리지를 늘리고 싶은 분, NAS + 미디어 서버 + 홈 자동화를 한 박스에서 다 해결하고 싶은 분, 그리고 설정의 편의성을 중요하게 생각하는 분께 강력 추천합니다.


    OpenMediaVault — 가볍고 오픈소스, 입문자의 친구

    OMV는 어떤 OS인가

    OpenMediaVault(이하 OMV)는 Debian Linux 기반의 완전 오픈소스 NAS OS입니다. 무료예요. FreeNAS(현 TrueNAS)의 초기 개발자 중 한 명이 만든 프로젝트라는 배경이 있습니다.

    OMV의 가장 큰 특징은 가볍다는 겁니다. 라즈베리 파이(Raspberry Pi)에도 설치할 수 있어요. 실제로 홈랩 입문자들이 라즈베리 파이 4에 OMV를 올려서 간단한 파일 서버를 구축하는 사례가 많습니다. 저도 테스트용으로 Pi에 올려봤는데, 설치 자체는 정말 간단하더라고요.

    플러그인(Plugin) 시스템으로 기능을 확장하는 구조입니다. OMV-Extras라는 서드파티 플러그인 저장소를 추가하면 Docker(Portainer), ZFS, 다양한 기능들을 추가할 수 있어요.

    OMV 장단점

    • ✅ 완전 무료 오픈소스
    • ✅ 저사양 하드웨어에서도 동작 (라즈베리 파이 포함)
    • ✅ Debian 기반이라 Linux 친숙한 분들에게 편함
    • ✅ 플러그인으로 기능 확장 가능
    • ✅ 기본 NAS 기능(SMB, NFS, FTP, rsync)은 충실하게 지원
    • ⚠️ 고급 스토리지 기능(ZFS 등)은 플러그인으로 추가해야 함
    • ⚠️ Unraid나 TrueNAS에 비해 커뮤니티 규모가 작음
    • ⚠️ Docker 환경 구성이 다른 OS에 비해 번거로울 수 있음
    • ⚠️ 대규모 스토리지 환경에는 적합하지 않을 수 있음

    이런 분께 추천

    예산이 빠듯한 입문자, 라즈베리 파이나 구형 PC를 활용하고 싶은 분, 단순 파일 공유 서버로만 쓸 분께 딱입니다. Linux를 어느 정도 다뤄본 분이라면 더욱 편하게 쓸 수 있어요.


    세 OS 한눈에 비교 — 어디서 뭐가 다른지

    TrueNAS vs Unraid vs OpenMediaVault 주요 항목 비교 — 홈랩 NAS OS 선택의 핵심 기준을 정리했다

    항목 TrueNAS CORE/SCALE Unraid OpenMediaVault
    기반 OS FreeBSD / Debian Linux Slackware Linux Debian Linux
    가격 무료 (오픈소스) 유료 (라이선스 구매 필요) 무료 (오픈소스)
    파일시스템 ZFS (기본) XFS / BTRFS (배열), ZFS(캐시) EXT4, XFS, BTRFS, ZFS(플러그인)
    디스크 혼합 어려움 (풀 단위 관리) 매우 자유로움 ⭐ 가능 (개별 마운트)
    Docker 지원 SCALE 버전 지원 기본 내장, 매우 편리 ⭐ 플러그인으로 가능
    VM 지원 SCALE 버전 지원 기본 내장 제한적
    데이터 무결성 ZFS 기반, 매우 강력 ⭐ 패리티 보호, 보통 파일시스템 의존
    최소 RAM 8GB 이상 권장 4GB 이상 권장 1GB도 가능 (Pi 등)
    진입 장벽 중~상 중 (WebUI 직관적) 하~중
    적합한 사용자 데이터 보호 중시, 중급 이상 홈랩 올인원, 중급 입문자, 저사양 환경

    실제 설치 — 이것만 알면 삽질 줄어듭니다

    TrueNAS 설치 시 주의사항

    TrueNAS는 설치 디스크(OS용)와 데이터 디스크를 반드시 분리해야 합니다. OS용으로 SSD나 USB를 별도로 쓰세요. 저도 처음에 이걸 몰라서 데이터 디스크에 OS 깔려고 했다가 낭패를 봤습니다 ㅎㅎ.

    # TrueNAS 설치 후 ZFS 풀 상태 확인
    zpool status
    
    # 풀 생성 예시 (RAIDZ1, 3개 디스크)
    zpool create tank raidz1 /dev/da1 /dev/da2 /dev/da3

    ⚠️ ZFS와 ECC 메모리 논쟁: 공식적으로 iXsystems는 ECC 메모리를 권장합니다. 단, 실제로 ECC 없이 쓰는 홈랩 유저도 많아요. 중요한 데이터라면 ECC를 갖추는 게 마음 편합니다.

    Unraid 설치 시 주의사항

    Unraid는 USB 드라이브에서 부팅하는 독특한 구조입니다. 라이선스가 USB 장치에 묶이거든요. 고품질 USB를 쓰세요 — 싸구려 USB 썼다가 부팅 안 되는 상황이 생길 수 있습니다.

    # Unraid에서 Docker 컨테이너 상태 확인 (터미널)
    docker ps
    
    # Unraid 배열 상태 확인
    mdcmd status
    
    # 디스크 목록 확인
    lsblk

    💡 팁: Unraid에서 캐시 풀(Cache Pool)을 SSD로 구성하면, 빠른 쓰기 후 배열로 이동하는 방식으로 성능을 크게 높일 수 있어요. 이걸 Mover라고 부릅니다.

    OpenMediaVault 설치 시 주의사항

    OMV는 Debian 설치하듯 진행됩니다. 라즈베리 파이에 설치할 때는 공식 스크립트를 사용해요.

    # 라즈베리 파이에 OMV 설치 스크립트 (공식 지원)
    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash
    
    # OMV-Extras 플러그인 추가 (Docker 등 확장 기능용)
    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | sudo bash
    
    # OMV 서비스 상태 확인
    systemctl status openmediavault-engined

    ⚠️ OMV 메이저 버전 업그레이드 시 플러그인 호환성 문제가 간혹 발생합니다. 업그레이드 전에는 꼭 백업하세요.


    설치 후 기본 검증 — 이것만 확인하세요

    NAS OS 설치 완료 후 WebUI에서 스토리지 풀 상태, 공유 폴더, 서비스 상태를 확인하는 화면

    어떤 OS를 설치했든, 기본 동작 확인은 이렇게 해보세요.

    1. 스토리지 풀/배열 상태 확인: 모든 디스크가 정상적으로 인식되었는지, RAID/패리티 구성이 올바른지 확인
    2. SMB 공유(Samba) 테스트: Windows 파일 탐색기에서 \\NAS-IP\공유폴더로 접근되는지
    3. NFS 공유 테스트: Linux 클라이언트에서 마운트 확인
    4. 읽기/쓰기 속도 테스트: 대용량 파일 복사로 기본 성능 확인
    5. 스냅샷 또는 백업 설정: 데이터 보호 체계가 실제로 동작하는지
    # Linux에서 NFS 마운트 테스트
    sudo mount -t nfs NAS-IP:/mnt/pool/share /mnt/test
    df -h /mnt/test
    
    # 간단한 쓰기 속도 테스트
    dd if=/dev/zero of=/mnt/test/testfile bs=1G count=1 oflag=direct
    
    # SMB 연결 테스트 (smbclient)
    smbclient //NAS-IP/share -U username

    여기까지 다 됐다면 🎉 기본 설정은 완료입니다. 다음은 서비스별 세부 튜닝과 백업 자동화 설정이 남아 있어요. 이 부분은 다음 글에서 각 OS별로 자세히 다룰 예정입니다.


    자주 묻는 질문 (FAQ)

    Q. TrueNAS와 Unraid 중 뭐가 더 낫나요?

    데이터 보호와 스토리지 신뢰성이 최우선이면 TrueNAS, 다양한 앱을 돌리는 올인원 홈서버를 원하고 디스크를 유연하게 추가하고 싶다면 Unraid가 더 맞습니다. 둘 다 훌륭한 선택이에요.

    Q. OpenMediaVault는 홈랩에서 쓰기 부족하지 않나요?

    단순 파일 공유 목적이라면 전혀 부족하지 않습니다. 단, 고급 스토리지 기능이나 Docker 환경이 복잡해지면 다른 OS로 넘어가는 분들도 있어요. 입문용으로는 충분히 좋습니다.

    Q. 나중에 OS를 바꿀 수 있나요?

    기술적으로는 가능하지만, 데이터 마이그레이션이 필요합니다. 특히 ZFS 풀은 TrueNAS에서 Unraid로 바로 이전이 안 돼요. 처음 선택을 신중하게 하시는 게 좋습니다.

    Q. 하드웨어 최소 사양은 어떻게 되나요?

    OpenMediaVault는 라즈베리 파이 4(4GB RAM)에서도 잘 돌아갑니다. TrueNAS는 8GB RAM 이상, Unraid는 4GB 이상을 권장하는데, 실제로 Docker나 VM을 많이 돌리면 16GB 이상이 편합니다.


    마무리 — 결국 정답은 “내 상황에 맞는 것”

    13년 동안 다양한 NAS OS를 써온 결론을 한 줄로 정리하면 이렇습니다.

    “데이터 보호 최우선 → TrueNAS, 유연한 올인원 홈랩 → Unraid, 가볍게 시작 → OpenMediaVault”

    사실 어떤 OS를 선택하든, 제대로 백업 체계를 갖추는 게 가장 중요합니다. NAS OS가 아무리 좋아도 백업이 없으면 소용없거든요. 3-2-1 백업 규칙(원본 1개 + 로컬 사본 1개 + 오프사이트 사본 1개)은 어떤 OS에서든 지켜주세요.

    저는 현재 메인 NAS는 TrueNAS SCALE로, 미디어 서버 겸 실험용 박스는 Unraid로 운영하고 있습니다. 두 개를 같이 쓰는 것도 방법이에요 ㅎㅎ.

    다음 글에서는 TrueNAS SCALE에서 ZFS 스냅샷 자동화와 원격 복제 설정하는 방법을 자세히 다룰 예정입니다. 궁금한 점은 댓글로 남겨주세요. 제가 직접 경험한 범위 안에서는 최대한 답변 드리겠습니다! 😄

  • [NAS] TrueNAS ZFS 스냅샷과 복제: 데이터 보호 전략

    [NAS] TrueNAS ZFS 스냅샷과 복제: 데이터 보호 전략

    데이터 유실의 악몽, 여러분은 준비되셨나요?

    안녕하세요, 13년차 인프라 엔지니어입니다. 서버실 관리하며 수많은 데이터 유실 사고를 직간접적으로 경험했어요. 실수로 파일을 지우거나, 하드디스크가 갑자기 고장 나거나, 심지어 랜섬웨어 공격까지… 상상만 해도 끔찍하죠?

    그래서 홈랩에서 TrueNAS를 운영하면서 데이터 보호에 정말 신경을 많이 씁니다. RAID만 믿고 있으면 안 된다는 걸 너무 잘 알거든요. RAID는 디스크 고장으로부터는 지켜주지만, 실수나 논리적 오류(Logical Error), 랜섬웨어 같은 위협에는 무력합니다. 이럴 때 필요한 게 바로 ZFS의 스냅샷(Snapshot)과 복제(Replication) 기능입니다. 제가 직접 써보니 이거 진짜 물건이더라고요!

    오늘은 여러분의 소중한 데이터를 지켜줄 TrueNAS ZFS 스냅샷과 복제 전략을 제 경험을 바탕으로 자세히 이야기해보겠습니다. 삽질하며 배운 노하우도 아낌없이 공유해 드릴게요!

    이 다이어그램은 TrueNAS ZFS 스냅샷과 복제 아키텍처의 개요를 보여줍니다. 로컬 TrueNAS에서 생성된 ZFS 스냅샷이 원격 TrueNAS로 복제되는 과정을 시각화했습니다.

    ZFS 스냅샷과 복제, 이게 뭔가요?

    처음엔 ZFS라는 이름도 생소하고, 스냅샷이니 복제니 하는 용어들이 헷갈리더라고요. 제가 직접 경험한 것을 바탕으로 쉽게 설명해 드릴게요.

    1. ZFS 스냅샷(Snapshot): 시간 여행 기능

    ZFS 스냅샷은 특정 시점의 파일 시스템 상태를 읽기 전용(Read-only)으로 저장하는 기능입니다. 비유하자면, 게임을 하다가 중요한 순간에 ‘저장’ 버튼을 누르는 것과 같아요. 언제든지 그 저장 지점으로 돌아갈 수 있거든요. 근데 일반적인 백업과는 좀 다릅니다. 변경된 데이터만 저장하는 CoW(Copy-on-Write) 방식을 사용해서 용량 효율이 정말 좋고, 생성도 눈 깜짝할 사이에 이루어져요. 제가 써보니 수백 GB짜리 데이터셋도 TrueNAS ZFS 스냅샷 뜨는데 1초도 안 걸리더라고요. 신기했습니다!

    • 즉시 생성 & 낮은 오버헤드: 순식간에 만들어지고 시스템 성능에 거의 영향을 주지 않습니다.
    • 공간 효율성: 변경된 블록만 저장하므로 추가 용량이 최소화됩니다.
    • 데이터 복구 용이성: 특정 시점으로 쉽게 롤백(Rollback)하거나, 스냅샷에서 파일을 직접 복사할 수 있습니다.
    • 불변성(Immutability): 생성된 스냅샷은 변경할 수 없어서 랜섬웨어 공격으로부터 안전합니다.

    2. ZFS 복제(Replication): 원격지 백업의 완성

    ZFS 복제는 이렇게 만들어진 스냅샷을 다른 ZFS 시스템(다른 TrueNAS 서버나 원격 서버)으로 전송(Transfer)하는 기능입니다. 게임 저장 파일을 친구 집 컴퓨터에 똑같이 복사해두는 것과 비슷해요. 내 컴퓨터가 고장 나도 친구 컴퓨터의 저장 파일로 다시 시작할 수 있는 거죠.

    TrueNAS 복제 기능은 ZFS의 델타(Delta) 전송을 활용합니다. 첫 번째 복제 때는 전체 스냅샷을 보내지만, 그 이후부턴 이전 스냅샷과 현재 스냅샷 간의 변경된 부분(Incremental changes)만 전송합니다. 실제로 홈랩에서 써보니 처음 한 번만 오래 걸리고 그 다음부턴 정말 빠르더라고요. 네트워크 트래픽도 확 줄고요. 이게 바로 재해 복구(Disaster Recovery, DR) 전략의 핵심입니다.

    • 원격지 백업: 로컬 시스템에 문제가 생겨도 원격지에 안전한 사본이 있습니다.
    • 대역폭 효율성: 증분(Incremental) 복제를 통해 네트워크 사용량을 최소화합니다.
    • 자동화 가능: TrueNAS UI에서 스케줄링하여 자동으로 복제를 수행할 수 있습니다.
    • 완전한 복구: 원격지에서 전체 데이터셋을 복구하거나, 특정 스냅샷으로 롤백하여 복구할 수 있습니다.

    TrueNAS ZFS 스냅샷 & 복제, 제가 직접 해보니

    이제 직접 TrueNAS에서 스냅샷과 복제 설정을 해볼 시간입니다. 처음엔 메뉴가 좀 복잡해 보여서 삽질 좀 했지만, 한 번 해보면 어렵지 않아요. 저를 따라오시면 금방 하실 수 있을 겁니다. 제가 쓰는 TrueNAS SCALE 기준으로 설명해 드릴게요.

    1. 자동 스냅샷 태스크 설정하기

    가장 먼저 할 일은 원하는 데이터셋에 주기적으로 ZFS 스냅샷을 찍도록 설정하는 겁니다. 저는 매일 밤 12시에 스냅샷을 찍고, 최근 7일치 스냅샷을 보관하도록 설정했어요.

    1. TrueNAS 웹 UI에 접속합니다.
    2. 왼쪽 메뉴에서 ‘Data Protection’ > ‘Snapshots’로 이동합니다.
    3. 우측 상단의 ‘ADD’ 버튼을 클릭합니다.
    4. 설정 화면에서 다음 항목들을 채워줍니다.
      • Dataset: 스냅샷을 찍을 데이터셋을 선택합니다. (예: Pool명/데이터셋명)
      • Recursive: 하위 데이터셋까지 스냅샷을 찍을지 여부입니다. 저는 보통 체크합니다.
      • Naming Schema: 스냅샷 이름 규칙입니다. 기본값 auto-%Y-%m-%d_%H-%M을 사용해도 충분합니다.
      • Schedule: 스냅샷을 찍을 주기입니다. 저는 ‘Daily’로 설정하고 ‘Time’을 ’00:00’으로 지정했습니다.
      • Keep for: 스냅샷을 얼마나 보관할지 설정합니다. 저는 ‘7 Days’로 설정했습니다.
    5. ‘SAVE’ 버튼을 클릭하여 저장합니다.

    ✅ 이제 지정된 시간에 자동으로 ZFS 스냅샷이 생성되고 오래된 스냅샷은 자동으로 삭제될 겁니다. ‘Snapshots’ 메뉴에서 생성된 스냅샷 목록을 확인할 수 있습니다.

    TrueNAS 웹 UI에서 ZFS 자동 스냅샷 태스크를 설정하는 화면입니다. 데이터셋, 스케줄, 보관 기간 등을 지정하여 원하는 스냅샷 정책을 만들 수 있습니다.

    2. ZFS 복제 태스크 설정하기 (원격 백업)

    스냅샷만으로는 부족합니다. 메인 TrueNAS 서버 자체가 망가지면 스냅샷도 소용없거든요. 그래서 저는 집의 다른 미니 PC에 TrueNAS를 설치해서 원격 복제 타겟으로 사용하고 있습니다. 물론 클라우드 스토리지(S3 등)로 복제하는 방법도 있지만, 저는 로컬 네트워크에서 빠르고 안정적인 TrueNAS 복제를 선호해서 이렇게 구성했어요.

    복제를 위해서는 먼저 원격 TrueNAS 서버에 SSH 접속을 위한 SSH Key를 설정해야 합니다. 보안상 ID/PW 방식보다는 SSH Key 방식을 추천합니다. 이 부분은 한 번 설정해두면 정말 편합니다.

    1. SSH Key 생성:
      • 복제를 시작할 TrueNAS(소스)에서 왼쪽 메뉴 ‘System Settings’ > ‘SSH Keypairs’로 이동합니다.
      • ‘ADD’를 클릭하고 키 이름을 지정한 후 ‘GENERATE KEYPAIR’를 선택하여 새 키를 생성합니다.
      • 생성된 Public Key 내용을 복사해둡니다.
    2. 원격 TrueNAS에 Public Key 등록:
      • 원격 TrueNAS(타겟) 웹 UI에 접속합니다.
      • ‘System Settings’ > ‘Users’로 이동하여 복제에 사용할 유저(예: root)를 선택하고 ‘EDIT’합니다.
      • ‘SSH Public Keys’ 필드에 아까 복사해둔 Public Key 내용을 붙여넣고 저장합니다.
      • 💡 팁: SSH 서비스가 활성화되어 있는지 확인하세요. ‘System Settings’ > ‘Services’에서 SSH 서비스를 ‘Running’ 상태로 변경하고 ‘Start Automatically’를 체크합니다.
    3. 복제 태스크 설정:
      • 다시 소스 TrueNAS로 돌아와서 ‘Data Protection’ > ‘Replication Tasks’로 이동합니다.
      • 우측 상단의 ‘ADD’ 버튼을 클릭합니다.
      • 설정 화면에서 다음 항목들을 채워줍니다.
        • Source: 복제할 데이터셋을 선택합니다. (예: Pool명/데이터셋명)
        • Destination: 원격 TrueNAS의 IP 주소와 SSH 포트(기본값 22)를 입력합니다. (예: ssh://192.168.1.100)
        • SSH Key: 아까 생성한 SSH Keypair를 선택합니다.
        • Remote Hostname: 원격 TrueNAS의 호스트명이나 IP를 다시 확인합니다.
        • Remote ZFS Filesystem: 원격 TrueNAS에서 ZFS 스냅샷이 저장될 데이터셋 경로를 지정합니다. (예: remote_pool/replicated_data)
        • Naming Schema: 원격지에 생성될 스냅샷 이름 규칙입니다. 소스와 동일하게 설정하는 것이 좋습니다.
        • Schedule: 복제 주기를 설정합니다. 저는 스냅샷 주기와 비슷하게 ‘Daily’로 설정했습니다.
        • Liveness Check: 원격지가 살아있는지 확인할 주기입니다.
        • Enable Replication: 체크박스를 활성화합니다.
      • ‘SAVE’ 버튼을 클릭하여 저장합니다.

    🎉 드디어 복제 태스크 설정이 완료되었습니다! 첫 복제는 소스 데이터셋의 크기에 따라 시간이 좀 걸릴 수 있습니다. ‘Replication Tasks’ 목록에서 진행 상황을 확인할 수 있어요. 완료되면 원격 TrueNAS에서도 복제된 스냅샷과 데이터셋을 확인할 수 있을 겁니다.

    ⚠️ 삽질 경험 & 주의사항

    제가 TrueNAS ZFS 복제를 세팅하면서 겪었던 몇 가지 삽질과 주의사항을 공유해 드릴게요. 여러분은 저처럼 고생하지 마시라고요!

    • SSH Key 설정 오류: 가장 많이 겪는 문제입니다. Public Key를 잘못 복사하거나, 원격 TrueNAS의 유저에게 Key가 제대로 등록되지 않았을 때 복제가 실패합니다. ‘System Settings’ > ‘Users’에서 해당 유저의 SSH Public Keys 필드에 제대로 들어갔는지 꼭 확인하세요. 줄 바꿈이나 공백 하나에도 민감하니까요.
    • 네트워크 문제: 소스 TrueNAS와 타겟 TrueNAS 간의 네트워크 연결이 불안정하거나 방화벽(Firewall)이 SSH 포트(기본 22)를 막고 있는 경우가 있습니다. ping 명령어로 연결 확인하고, 방화벽 설정을 꼭 확인해 주세요. 예를 들어, 소스 TrueNAS에서 원격 TrueNAS로 Ping 테스트를 해볼 수 있습니다.
      
      ping 192.168.1.100
      

      혹은 SSH 서비스가 제대로 실행 중인지 원격 TrueNAS에서 확인하는 것도 중요합니다.

    • 데이터셋 경로 오류: 원격 TrueNAS의 ‘Remote ZFS Filesystem’ 경로를 잘못 지정하면 복제가 실패합니다. 반드시 원격 TrueNAS에 해당 풀(Pool)이 존재해야 하고, 원하는 데이터셋 경로가 유효한지 확인해야 합니다. 저는 실수로 존재하지 않는 데이터셋에 복제하려고 해서 한참 헤맸던 기억이 있거든요.
    • 스냅샷 보존 정책: ZFS 스냅샷과 복제 태스크의 보존 정책(Keep for)을 잘 설정해야 합니다. 너무 짧게 설정하면 중요한 스냅샷이 삭제될 수 있고, 너무 길게 설정하면 스토리지 공간을 너무 많이 차지하게 됩니다. 데이터의 중요도와 스토리지 용량을 고려해서 적절한 기간을 설정하는 것이 중요합니다.
    • 초기 복제 시간: 첫 복제는 전체 데이터를 전송하므로 시간이 오래 걸릴 수 있습니다. 데이터 양이 많다면 네트워크 대역폭과 시간을 충분히 확보하고 시작하는 것이 좋습니다. 저는 1TB 넘는 데이터를 첫 TrueNAS 복제할 때 거의 하루 종일 걸리더라고요.

    이런 문제들 때문에 저도 초기에는 꽤나 애를 먹었습니다. 에러 메시지를 꼼꼼히 읽어보고, TrueNAS 포럼이나 커뮤니티를 검색해보는 것이 큰 도움이 됩니다. 결국 해결하고 나면 그렇게 뿌듯할 수가 없어요! 🎉

    ✅ 복제 결과 확인 및 데이터 복구 테스트

    설정이 끝났다고 마냥 손 놓고 있으면 안 되겠죠? 실제로 잘 작동하는지, 그리고 만약의 사태가 발생했을 때 제대로 복구할 수 있는지 검증(Verification)하는 과정이 정말 중요합니다. 제가 직접 해본 검증 방법들을 알려드릴게요.

    1. 원격 TrueNAS에서 스냅샷 확인

    가장 기본적인 확인 절차입니다. 원격 TrueNAS 웹 UI에 접속해서 ‘Data Protection’ > ‘Snapshots’ 메뉴로 이동해 보세요. 소스 TrueNAS에서 복제된 스냅샷들이 보인다면 일단 복제는 성공적으로 진행되고 있다는 뜻입니다.

    또한, ‘Storage’ > ‘Pools’ 메뉴에서 해당 데이터셋을 클릭하고 ‘Snapshots’ 탭으로 이동하면 해당 데이터셋의 스냅샷 목록을 볼 수 있습니다. 제가 확인해보니 소스에서 찍힌 ZFS 스냅샷 이름과 동일하게 잘 복제되어 있더라고요.

    2. 파일 복구 시뮬레이션

    실제로 데이터를 잃어버렸을 때 어떻게 복구하는지 미리 경험해보는 것이 좋습니다. 저는 테스트용 파일을 만들고 삭제한 다음, 스냅샷으로 복구하는 시뮬레이션을 해봤어요.

    1. 원격 TrueNAS의 복제된 데이터셋에 접속합니다. (SMB/NFS 등으로 마운트)
    2. 테스트용 파일을 몇 개 생성합니다.
    3. 강제로 이 파일들을 삭제하거나 내용을 변경합니다.
    4. ‘Storage’ > ‘Pools’에서 해당 데이터셋을 선택하고 ‘Snapshots’ 탭으로 이동합니다.
    5. 복구하고 싶은 시점의 ZFS 스냅샷을 선택하고 ‘Rollback’ 버튼을 클릭합니다. ⚠️ 롤백은 현재 상태를 스냅샷 시점으로 되돌리는 것이므로, 신중하게 진행해야 합니다. 보통은 스냅샷을 Clone(클론)하여 새로운 데이터셋으로 만든 후, 필요한 파일만 복사하는 방식을 더 많이 사용합니다.
    6. 아니면 스냅샷 내부로 들어가 필요한 파일만 복사해 올 수도 있습니다. 스냅샷은 읽기 전용으로 마운트될 수 있거든요.

    제가 해보니 롤백은 너무 강력한 기능이라 신중해야 하고, 보통은 스냅샷을 마운트해서 특정 파일만 가져오는 게 훨씬 안전하고 편리했습니다. 💡

    TrueNAS 웹 UI에서 복제된 ZFS 데이터셋의 스냅샷 목록을 확인하고, 필요시 롤백 또는 클론 기능을 사용하는 화면입니다.

    마무리하며: 데이터 보호는 선택이 아닌 필수

    TrueNAS의 ZFS 스냅샷과 복제 기능은 정말 강력한 데이터 보호 및 재해 복구 전략을 구축할 수 있게 해줍니다. 저도 처음엔 설정이 좀 복잡하게 느껴졌지만, 한 번 제대로 구축해두니 마음이 정말 편안하더라고요. 홈랩의 소중한 사진, 영상, 문서 파일들이 안전하게 보호되고 있다는 생각에 뿌듯했습니다.

    데이터 유실은 언제든 일어날 수 있는 일입니다. 중요한 건 문제가 생겼을 때 얼마나 빨리, 그리고 얼마나 완벽하게 복구할 수 있느냐입니다. ZFS 스냅샷은 로컬에서의 빠른 복구를, ZFS 복제는 원격지 재해 발생 시의 데이터 복구를 보장해 줍니다.

    여러분도 오늘 제가 공유해드린 내용을 바탕으로 TrueNAS ZFS 스냅샷과 복제 기능을 꼭 활용해 보셨으면 좋겠습니다. 혹시 설정 중에 궁금한 점이나 막히는 부분이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 최대한 도와드리겠습니다!

    다음 글에서는 이렇게 복제된 데이터를 활용하여 다른 용도로 쓰는 방법이나, 클라우드 스토리지로의 복제 등 좀 더 심화된 내용들을 다뤄볼까 합니다. 기대해 주세요!

    TrueNAS ZFS 스냅샷과 복제 기능이 제공하는 핵심 장점들을 요약한 인포그래픽입니다.

  • [Nas] TrueNAS SMB 성능 최적화: 고속 파일 공유를 위한 설정 가이드

    [Nas] TrueNAS SMB 성능 최적화: 고속 파일 공유를 위한 설정 가이드

    안녕하세요! 13년차 서버실 지킴이, 13년차 인프라 엔지니어입니다. 오늘은 홈랩(Homelab)에서 많은 분들이 겪는 고질적인 문제, 바로 TrueNAS SMB 성능 최적화에 대해 이야기해보려고 해요. NAS 파일 공유 속도가 답답해서 속 터지는 경험, 혹시 저만 해본 건 아니겠죠? 저도 처음 TrueNAS를 구축하고 파일을 옮기는데, ‘이게 뭔가 싶을 정도로’ 느려서 한참을 삽질했던 기억이 납니다. 😅

    특히 고용량 파일이나 다수의 작은 파일을 자주 주고받아야 할 때, 느린 SMB(Server Message Block) 속도는 정말이지 작업 효율을 떨어뜨리는 주범이 됩니다. 그래서 오늘은 제가 직접 경험하고 설정하면서 얻은 TrueNAS 네트워크 최적화와 SMB 설정 노하우를 아낌없이 공유해 드릴게요. 여러분의 TrueNAS가 쾌적한 고속 파일 공유 서버로 거듭나도록 도와드리겠습니다!

    홈랩에서 TrueNAS SMB 성능을 최적화하기 위한 기본적인 네트워크 구성도입니다. 10GbE 스위치와 클라이언트, TrueNAS 간의 연결을 보여줍니다.

    TrueNAS SMB, 왜 느릴까요? 핵심 개념부터 알아보기

    우선, SMB(Server Message Block)가 뭔지 간단히 짚고 넘어갈까요? 쉽게 말해, 윈도우나 macOS 같은 운영체제에서 네트워크를 통해 파일이나 프린터를 공유하기 위해 사용하는 통신 프로토콜입니다. 우리가 흔히 ‘네트워크 드라이브’나 ‘공유 폴더’라고 부르는 것들이 바로 이 SMB를 통해 작동하더라고요.

    그럼 왜 TrueNAS의 SMB 성능이 기대만큼 나오지 않을까요? 원인은 다양한데, 크게 몇 가지로 나눠볼 수 있어요.

    • 네트워크 병목(Network Bottleneck): 가장 흔한 원인 중 하나예요. 1기가비트 이더넷(Gigabit Ethernet, GbE) 환경에서는 이론상 최대 125MB/s의 속도를 내지만, 실제로는 100~110MB/s 정도가 한계거든요. 10기가비트 이더넷(10GbE)으로 업그레이드하면 훨씬 빨라집니다.
    • 디스크 I/O 성능(Disk I/O Performance): 아무리 네트워크가 빨라도 디스크 자체가 느리면 소용없어요. 특히 HDD(Hard Disk Drive)는 SSD(Solid State Drive)에 비해 랜덤 I/O 성능이 현저히 떨어지더라고요.
    • CPU 및 RAM(CPU & RAM): SMB 서비스 자체도 어느 정도의 CPU 연산과 RAM을 사용합니다. 특히 동시 접속자 수가 많거나 암호화 기능을 사용하면 더 많은 자원이 필요해요.
    • TrueNAS 설정 문제: 오늘 다룰 핵심이죠. TrueNAS 내부의 SMB 설정이나 ZFS 데이터셋(Dataset) 설정에 따라 성능이 크게 달라질 수 있습니다.

    이런 요소들을 종합적으로 고려해서 최적의 TrueNAS SMB 성능을 끌어내는 것이 우리의 목표입니다.

    고속 파일 공유를 위한 준비물과 사전 점검 💡

    본격적인 설정에 들어가기 전에, 몇 가지 준비물과 사전 점검 사항을 확인해 봅시다. 제가 처음엔 이런 것들을 간과하고 무작정 설정만 바꾸려다가 꽤나 삽질 좀 했거든요. ㅎㅎ

    1. 하드웨어 점검

    • 10기가비트 이더넷(10GbE) 환경:
      • TrueNAS 서버 NIC(네트워크 인터페이스 카드): 서버에 10GbE NIC가 장착되어 있는지 확인하세요. 저는 인텔 X540-T2 같은 NIC를 주로 사용하는데, 안정적이고 성능도 괜찮더라고요.
      • 클라이언트 PC NIC: 파일을 주고받을 클라이언트 PC에도 10GbE NIC가 있어야 합니다.
      • 10GbE 스위치(Switch): 모든 10GbE 장비가 연결될 스위치 역시 10GbE를 지원해야 해요. 저렴한 언매니지드(Unmanaged) 스위치도 괜찮지만, 장기적으로는 관리형(Managed) 스위치가 유용할 때가 많습니다.
    • 스토리지(Storage):
      • 성능이 중요한 공유라면 SSD 풀(Pool)을 사용하는 게 좋습니다. 특히 NVMe SSD는 압도적인 성능을 보여주더라고요.
      • HDD 풀이라도 스트라이프(Stripe)나 미러(Mirror) 구성보다는 RAID-Z1, Z2 같은 방식이 쓰기 성능에 유리할 수 있습니다.

    2. 네트워크 케이블 확인

    10GbE 환경에서는 CAT6a 이상의 이더넷 케이블을 사용하는 게 중요합니다. CAT5e나 CAT6 케이블은 짧은 거리에서는 작동할 수 있지만, 장거리에서는 신뢰성과 성능 저하를 일으킬 수 있어요. 저는 처음에 집에 있던 오래된 CAT5e 케이블로 연결했다가 속도가 안 나와서 애를 먹었는데, 케이블을 바꾸니 바로 해결되더라고요! 😅

    TrueNAS SMB 성능 최적화를 위한 설정 가이드

    이제 본격적으로 TrueNAS 설정에 들어가 볼까요? 여기서는 TrueNAS SCALE SMB를 기준으로 설명하지만, CORE 버전에서도 유사한 설정들이 많으니 참고하시면 됩니다.

    1. SMB 서비스 설정

    TrueNAS 웹 UI에 접속하여 서비스(Services) 메뉴에서 SMB(CIFS) 서비스를 찾아 설정합니다.

    1. 고급 설정 활성화: SMB 서비스 설정 화면에서 ‘고급 옵션 표시(Show Advanced Options)’를 클릭하세요.
    2. 서버 최소/최대 프로토콜(Server Minimum/Maximum Protocol):
      • Server Minimum Protocol: SMB2 (SMB1은 보안에 취약하고 성능도 좋지 않습니다. 레거시 시스템이 아니라면 사용하지 마세요.)
      • Server Maximum Protocol: SMB3_11 또는 SMB3 (최신 프로토콜을 사용하는 게 성능과 보안에 모두 유리합니다.)
    3. 보조 매개변수(Auxiliary Parameters): 여기에 성능 향상을 위한 추가 옵션들을 넣어줄 거예요. 한 줄씩 추가합니다.
    4. 
      # 비동기 I/O (Asynchronous I/O)를 위한 설정
      aio_pthread_cases = 100
      aio_pthread_read_cases = 100
      aio_pthread_write_cases = 100
      
      # SMB Multi-channel (멀티채널) 활성화 (TrueNAS SCALE만 해당, CORE는 Link Aggregation 사용)
      # 여러 네트워크 인터페이스를 사용하여 대역폭을 늘리고 지연 시간을 줄입니다.
      # 클라이언트와 서버 모두 Multi-channel을 지원해야 합니다.
      server multi channel = yes
      
      # 메타데이터 캐싱 최적화 (Disk I/O 감소)
      cache_read_metadata = yes
      
      # 엄격한 할당 비활성화 (쓰기 성능 향상, 주의 필요)
      # 클라이언트가 요청한 크기만큼 블록을 미리 할당하지 않도록 합니다.
      # 파일 시스템 단편화가 증가할 수 있으나, 쓰기 성능 향상에 기여할 수 있습니다.
      strict allocate = no
              

      💡 팁: strict allocate = no는 파일 시스템 단편화를 유발할 수 있으니, 아주 민감한 환경이 아니라면 기본값(yes)을 유지하는 것도 좋은 선택입니다. 저는 홈랩 환경에서 쓰기 성능을 끌어올리기 위해 사용하곤 하는데, 환경에 따라 선택하시면 됩니다.

    5. 저장(Save) 버튼을 눌러 설정을 적용합니다.

    TrueNAS 웹 UI에서 SMB 서비스의 고급 설정을 변경하는 화면입니다. 보조 매개변수에 주요 최적화 옵션들이 입력되어 있습니다.

    2. 네트워크 인터페이스(NIC) 설정

    네트워크 인터페이스 설정도 TrueNAS 네트워크 최적화의 핵심입니다.

    1. 점보 프레임(Jumbo Frames) 활성화:
      • 네트워크(Network) → 인터페이스(Interfaces) 메뉴로 이동하여 사용할 10GbE NIC를 선택합니다.
      • MTU(Maximum Transmission Unit) 값을 9000으로 변경합니다. (기본값은 1500입니다.)
      • ⚠️ 중요: TrueNAS 서버, 스위치, 클라이언트 PC의 모든 장비가 동일하게 MTU 9000을 지원하고 설정되어야 합니다! 하나라도 다르면 오히려 통신 오류나 성능 저하가 발생할 수 있어요. 제가 이 부분에서 삽질 좀 했거든요. 스위치와 TrueNAS는 설정했는데 클라이언트 MTU를 잊어서 한참을 헤맸던 기억이 나네요.
    2. Link Aggregation(링크 어그리게이션) 또는 SMB Multi-channel(멀티채널):
      • TrueNAS CORE: 여러 개의 1GbE NIC를 묶어 대역폭을 확장하는 Link Aggregation(LACP)을 주로 사용합니다. 스위치에서 LACP 설정을 해주어야 해요.
      • TrueNAS SCALE: SMB Multi-channel을 적극 활용하는 게 좋습니다. 위에 SMB 보조 매개변수에서 server multi channel = yes를 설정했다면, TrueNAS 서버에 여러 개의 NIC가 연결되어 있고 클라이언트도 Multi-channel을 지원하면 자동으로 대역폭을 합쳐서 사용해요. 훨씬 간편하고 효과적입니다.

    3. ZFS 데이터셋(Dataset) 설정 (⚠️ 매우 중요!)

    SMB 공유에 사용할 ZFS 데이터셋의 설정도 성능에 큰 영향을 미칩니다. 특히 동기 쓰기(Synchronous Write)와 관련된 설정은 데이터 안전성과 성능 사이의 트레이드오프가 존재하므로 신중해야 합니다.

    1. 데이터셋(Datasets) 메뉴로 이동하여 공유할 데이터셋을 선택합니다.
    2. 고급 옵션(Advanced Options)에서 동기화(Sync) 설정을 확인합니다.
      • Sync: Standard (기본값)
        • 대부분의 경우 이 설정이 가장 안전하고 균형 잡힌 성능을 제공해요.
        • 데이터 무결성(Data Integrity)을 보장하며, 쓰기 작업이 완료되기 전에 데이터가 디스크에 기록되었는지 확인합니다.
      • Sync: Always (가장 안전하지만, 성능 저하)
        • 모든 쓰기 작업이 디스크에 기록될 때까지 기다리므로, 전력 손실 등의 상황에서도 데이터 손실 위험이 거의 없습니다. 하지만 쓰기 성능은 가장 낮아요.
      • Sync: Disabled (최대 성능, 데이터 손실 위험)
        • 쓰기 작업이 디스크에 기록되었는지 확인하지 않고, 운영체제 캐시에서 쓰기 완료를 보고합니다. 이로 인해 쓰기 성능은 가장 뛰어나지만, 전력 손실이나 시스템 크래시 시 데이터 손실 또는 손상 위험이 매우 높습니다.
        • ⚠️ 경고: 이 옵션은 극단적인 성능이 필요하고 데이터 손실 위험을 감수할 수 있는 경우에만 사용해야 합니다. 절대 중요한 데이터에 사용하지 마세요! 저는 특정 임시 파일 공유나 벤치마크 테스트 시에만 제한적으로 사용해봤습니다.

    주의사항 및 트러블슈팅: 제가 겪었던 삽질들 😱

    자, 이렇게 설정하면 웬만해선 TrueNAS SMB 성능이 확 올라갈 겁니다. 하지만 저처럼 예상치 못한 문제에 부딪힐 수도 있겠죠? 제가 겪었던 몇 가지 삽질 경험과 해결 팁을 공유해 드릴게요.

    1. 점보 프레임 설정 후 오히려 속도가 느려지거나 접속 불가

    앞서 강조했지만, MTU 9000은 TrueNAS, 스위치, 클라이언트 모두 동일하게 설정되어야 해요. 저는 스위치와 TrueNAS는 설정했지만, 윈도우 클라이언트 PC의 NIC 드라이버 설정에서 MTU를 바꾸는 걸 깜빡해서 한참을 헤맸어요. 윈도우에서는 PowerShell이나 NIC 속성에서 설정할 수 있습니다.

    
    # 현재 MTU 확인 (Windows)
    Get-NetAdapterAdvancedProperty -Name "이더넷 어댑터 이름" | Where-Object {$_.DisplayName -eq "Jumbo Packet"}
    
    # MTU 9000으로 설정 (Windows)
    Set-NetAdapterAdvancedProperty -Name "이더넷 어댑터 이름" -RegistryKeyword "JumboPacket" -RegistryValue 9000
    

    2. 클라이언트 PC의 SMB 캐싱 문제

    가끔 클라이언트 PC에서 이전에 연결했던 SMB 공유의 캐시가 남아있어 성능 측정이 정확하지 않은 경우가 있어요. 이럴 때는 클라이언트 PC를 재부팅하거나, 네트워크 드라이브 연결을 완전히 끊고 다시 연결해보세요.

    3. TrueNAS 리소스 부족

    SMB 성능은 네트워크뿐만 아니라 TrueNAS 서버 자체의 리소스(CPU, RAM)에도 영향을 받습니다. 특히 TrueNAS SCALE SMB는 컨테이너 기반으로 작동하므로, 시스템 리소스 할당이 중요할 수 있어요. TrueNAS 대시보드에서 CPU 사용률, RAM 사용률, 디스크 I/O 등을 모니터링하면서 병목 지점을 찾아보세요.

    TrueNAS 웹 UI에서 시스템 리소스 사용 현황을 모니터링하는 대시보드 화면입니다. CPU, RAM, 네트워크 트래픽 등의 지표를 확인할 수 있습니다.

    검증 및 결과 확인 🎉

    자, 이제 설정도 끝났으니 실제로 NAS 파일 공유 속도가 얼마나 빨라졌는지 확인해 볼 시간입니다! 저는 주로 두 가지 툴을 사용해서 성능을 측정합니다.

    1. iPerf3를 이용한 네트워크 대역폭 테스트

    SMB 성능은 결국 네트워크 대역폭에 크게 좌우됩니다. iPerf3는 네트워크 자체의 최대 처리량을 측정하는 데 정말 유용해요. TrueNAS SCALE에서는 앱(Apps)으로 iPerf3를 설치하거나, CLI에서 직접 실행할 수 있습니다.

    
    # TrueNAS 서버에서 iPerf3 서버 실행
    iperf3 -s
    
    # 클라이언트 PC에서 iPerf3 클라이언트 실행 (TrueNAS 서버 IP로)
    iperf3 -c [TrueNAS_IP] -P 8 -t 30
    

    이렇게 측정했을 때 10GbE 환경이라면 9~9.5Gbps 정도가 나와야 정상입니다. 만약 1Gbps에 머무르거나 그 이하로 나온다면, 네트워크 케이블, NIC 드라이버, 스위치 설정 등을 다시 점검해 봐야 합니다.

    2. CrystalDiskMark (Windows) 또는 Blackmagic Disk Speed Test (macOS)

    실제 SMB 공유 폴더에 파일을 읽고 쓰는 성능을 측정하는 데 정말 유용한 툴들이예요. 클라이언트 PC에서 공유 폴더를 네트워크 드라이브로 연결한 후 테스트를 진행합니다.

    • CrystalDiskMark: 윈도우 환경에서 가장 널리 사용되는 디스크 벤치마크 툴입니다. 순차 읽기/쓰기, 랜덤 읽기/쓰기 성능을 직관적으로 보여줍니다.
    • Blackmagic Disk Speed Test: macOS 사용자에게 정말 좋은 선택지예요. 비디오 편집 워크로드에 초점을 맞춰 성능을 측정합니다.

    설정 전후로 이 툴들을 돌려보면 확연히 빨라진 TrueNAS SMB 성능을 체감하실 수 있을 거예요. 저는 순차 읽기/쓰기 속도가 110MB/s에서 700~800MB/s (10GbE 환경, SSD 풀)까지 올라가는 걸 보고 쾌재를 불렀습니다! 🎉

    TrueNAS SMB 성능 최적화 전후의 CrystalDiskMark 벤치마크 결과 비교표입니다. 순차 읽기/쓰기 속도 변화를 보여줍니다.

    마무리하며: 쾌적한 홈랩을 위한 끊임없는 탐구

    오늘은 제가 13년차 인프라 엔지니어로 홈랩을 운영하면서 겪었던 TrueNAS SMB 성능 최적화 과정을 공유해 드렸습니다. NAS 파일 공유 속도를 높이기 위해 SMB 설정부터 네트워크 환경, 그리고 ZFS 데이터셋 설정까지 다양한 요소를 고려해야 한다는 걸 다시 한번 깨달으셨을 거예요. 때로는 복잡하고 삽질의 연속일 수 있지만, 드디어 원하는 성능이 나왔을 때의 그 쾌감은 정말 최고랍니다! 😄

    오늘 다룬 내용 외에도 ZFS 캐싱(L2ARC, SLOG)을 활용하거나, 더 고급스러운 네트워크 튜닝을 통해 TrueNAS 네트워크 최적화를 시도해 볼 수도 있어요. 하지만 오늘 제가 알려드린 기본 설정만으로도 대부분의 홈랩 환경에서는 충분히 만족할 만한 TrueNAS SMB 성능 향상을 경험하실 수 있을 겁니다. 여러분의 쾌적한 홈랩 생활에 제 경험이 조금이나마 도움이 되었기를 바랍니다!

    다음번에는 TrueNAS SCALE의 컨테이너 앱 활용법 같은 재미있는 주제로 찾아올게요. 그때까지 즐거운 홈랩 라이프 보내세요! 👋