JW Devlog

[HomeLab] TrueNAS RAID-Z2 스토리지 구축기

9 min read

개요

처음 홈서버를 시작했을 때는 라즈베리파이에 외장 디스크를 붙여 파일 서버로 쓰는 구성이었다. 단순했지만 24시간 운영하다 보니 어느 순간 물리적 디스크 결함이 발생했고, 파일시스템이 마운트조차 되지 않는 상태가 됐다.

다행히 PC에 백업본이 남아 있어 데이터를 복구할 수 있었다. 그러나 만약 체계적인 백업 정책 없이 운영했다면 모든 데이터를 잃을 뻔한 상황이었다.

그 이후로 스토리지를 설계할 때 “장애는 반드시 발생한다”는 전제를 가장 먼저 세운다. 이중화와 정합성 검증은 선택이 아니라 기본값이 되어야 한다고 생각하게 됐다.

설계 결정: TrueNAS + ZFS

스토리지 레이어를 다시 구성하면서 세 가지를 요구사항으로 잡았다.

  1. 디스크 복수 장애에도 데이터가 살아있을 것
  2. 데이터 정합성을 OS 레벨에서 검증할 것
  3. Linux/Windows 클라이언트를 모두 지원할 것

TrueNAS를 선택한 이유는 ZFS 때문이다. ZFS는 파일시스템과 볼륨 매니저를 통합하여 데이터 쓰기 시점에 체크섬을 기록하고, 읽을 때마다 검증한다. 조용한 데이터 손상(silent corruption)을 감지하고 RAID 패리티로 자동 복구까지 해준다. 기존 Linux mdraid는 이 수준의 정합성 보장을 제공하지 않는다.

RAID-Z2 구성

HDD 4장을 하나의 RAID-Z2 vdev로 구성했다.

RAID-Z2는 패리티 디스크가 2개인 구조다. 4장 중 어느 2장이 동시에 죽어도 데이터를 읽고 쓸 수 있다. 가용 용량은 전체의 절반(4장 중 2장 분량)이 된다.

RAID-Z2 (4 disks)
├── 패리티: 2장 분량
└── 실제 가용 용량: 2장 분량

RAID-Z1(패리티 1개)도 고려했지만, 디스크 1장 장애 후 리빌드 기간 중 또 다른 장애가 발생하면 데이터를 잃는다. HDD는 리빌드 중 스트레스로 추가 장애가 날 확률이 높기 때문에 패리티를 하나 더 여유를 두는 것이 합리적이라고 판단했다.

프로토콜 분리: NFS와 SMB

NAS를 구성한 뒤, 홈랩 내 여러 클라이언트에서 접근할 방법을 설계했다.

NFS (Linux 서버 간)

  • 커널 레벨에서 처리되어 오버헤드가 적다
  • Proxmox의 LXC/VM 스토리지를 NAS에서 마운트할 때 사용
  • 인증은 IP 기반 export 설정으로 관리

SMB (Windows 데스크탑)

  • Windows 탐색기에서 네트워크 드라이브로 직접 마운트
  • 개인 자료 백업, 미디어 파일 접근용

두 프로토콜을 동일한 ZFS 데이터셋 위에서 동시에 서비스하는 구성이기 때문에, 어느 클라이언트에서 쓰든 데이터는 같은 위치에 저장된다.

현재 운영 구조

TrueNAS는 Proxmox 위에 LXC로 올라가 있다. VM으로 올릴 경우 QEMU의 가상 디스크 레이어를 거치게 되어 ZFS가 실제 디스크를 직접 관리하지 못한다. LXC에 디스크를 직접 연결하면 이 문제를 피할 수 있다.

WTR PRO의 SATA 컨트롤러 패스스루 제약

WTR PRO(AMD Ryzen 5825U 기반)는 SATA 컨트롤러가 SoC에 통합되어 있다. 이 컨트롤러를 통째로 IOMMU 그룹으로 VM/LXC에 넘기면 호스트가 해당 SoC 기능에 접근하지 못하게 되는데, 문제는 열 관리 시스템(thermal management)도 같은 경로로 연결되어 있다는 점이다. 결과적으로 Proxmox 호스트가 CPU 온도를 읽지 못하고 부스트 클럭을 강제로 억제하는 스로틀링이 발생한다.

Proxmox 커뮤니티에서도 여러 건 보고된 문제로, Aoostar 측도 하드웨어 설계상 수정이 불가능하다고 공식 확인했다.

혼합 패스스루 구성

이 제약 때문에 4개의 HDD를 단일 방식으로 연결하지 않고 혼합 구성을 적용했다.

  • SATA 컨트롤러 (PCI 디바이스): hostpci0으로 IOMMU 그룹 단위 패스스루. 해당 컨트롤러에 연결된 디스크는 TrueNAS가 직접 인식하며 SMART 정보도 온전히 읽힌다.
  • 나머지 HDD: /dev/disk/by-id 경로로 LXC에 개별 마운트. 내장 SATA 컨트롤러는 호스트에 유지해 CPU 열 관리가 정상 동작하도록 한다.
Proxmox Host
└── TrueNAS LXC
    └── ZFS Pool (RAID-Z2)
        ├── HDD 1  (/dev/disk/by-id/... 개별 패스스루)
        ├── HDD 2  (/dev/disk/by-id/... 개별 패스스루)
        ├── HDD 3  (SATA Controller passthrough)
        └── HDD 4  (SATA Controller passthrough)

개별 디스크 패스스루는 SMART 모니터링이 일부 제한될 수 있고, 디스크 교체 시 by-id 경로가 바뀌는 점을 주의해야 한다. 그러나 컨트롤러 전체를 넘기지 않으므로 호스트의 열 관리에는 영향을 주지 않는다.

ZFS 스냅샷 자동화

RAID-Z2가 하드웨어 장애를 감내하는 레이어라면, 스냅샷은 실수나 논리적 손상으로부터 보호하는 레이어다. 파일을 잘못 삭제하거나 덮어쓴 경우, RAID는 아무런 도움이 되지 않는다.

TrueNAS의 ZFS 스냅샷 기능을 활용해 정기 스냅샷 자동화 정책을 설정했다. 데이터의 중요도와 변경 빈도에 따라 주기와 보존 기간을 다르게 적용했다.

  • 자주 변경되는 데이터 (작업 디렉토리 등): 매일 스냅샷, 7일 보존
  • 중요도 높은 장기 보관 데이터 (사진, 문서): 주 1회 스냅샷, 4주 보존

보존 기간이 지난 스냅샷은 자동으로 삭제되어 스토리지 용량을 과도하게 점유하지 않도록 관리된다. 스냅샷 자체는 copy-on-write 구조라 변경된 블록만 추가 기록하므로 공간 효율도 좋다.

정리

디스크 장애를 직접 겪고 나서야 이중화의 필요성이 피부로 와 닿았다. RAID-Z2 구성은 단순히 “디스크를 묶는 것”이 아니라, 어디까지의 장애를 감내할 것인지 명시적으로 결정하는 작업이다. 지금은 2장 동시 장애까지 허용하도록 설계했고, ZFS의 정기 scrub으로 데이터 정합성을 주기적으로 검증하고 있다. 스냅샷 자동화로 논리적 데이터 손상까지 대비하고 나서야 비로소 “백업이 있다”고 말할 수 있게 됐다.

Recent writing

그래프 뷰

백링크