올해 처음으로 홈 스토리지 서버를 직접 만들기로 했다. 오픈소스 소프트웨어로 개인 데이터와 업무 데이터를 모두 저장하는 32TB 시스템이다.

서버 본체는 531달러가 들었고, 디스크 4개를 732달러에 구매해 총비용은 1,263달러였다. 완제품 스토리지 서버와 가격은 비슷하지만 성능과 커스터마이징 측면에서는 훨씬 뛰어나다.

이번 글에서는 부품을 어떻게 골랐는지, 어떤 실수를 했는지, 그리고 직접 만들어 보고 싶은 분들을 위해 무엇을 추천하는지 차근차근 설명해보려 한다.

영상으로 보고 싶다면 YouTube에 올려둔 영상을 참고하면 된다.

배경

왜 NAS 서버를 만드는가?

NAS는 네트워크 결합 스토리지의 약자다. NAS 서버의 주된 역할은 데이터를 저장하고 네트워크상의 다른 컴퓨터에서 쓸 수 있게 하는 것이다.

그런데 왜 굳이 데이터를 위해 서버 한 대를 따로 둬야 할까? 어차피 모든 컴퓨터가 데이터를 저장하지 않나?

나는 데이터 저장을 다른 시스템과 분리하는 것이 도움이 된다고 생각한다. 메인 워크스테이션과 노트북을 2~3년마다 업그레이드하는데, 그때마다 데이터를 옮기는 일이 항상 번거로웠다. 전용 스토리지 서버가 있으면 대부분의 데이터 마이그레이션이 필요 없어지고 시스템 간 파일 공유도 훨씬 쉬워진다.

그리고 나는 데이터가 정말 많다. 자타공인 데이터 호더라서 지금까지 찍은 모든 디지털 사진, 지난 20년간 주고받은 모든 이메일, 개인 프로젝트의 모든 소스 코드를 보관한다. 현재 총용량은 8.5TB다.

가장 큰 비중을 차지하는 건 DVD와 블루레이 컬렉션이다. 좋아하는 콘텐츠를 스트리밍 서비스에만 의존하고 싶지 않아서 영화나 드라마는 지금도 실물 디스크로 구매한다. 새 디스크를 사면 바로 원본 이미지를 추출하고 스트리밍용 비디오 파일도 만든다. 원본 ISO와 스트리밍용 MP4를 합치면 디스크 한 장에 60GB가 들기도 한다.

홈랩이란?

“홈랩”은 최근 몇 년 사이 널리 쓰이게 된 구어적 표현이다.

홈랩은 집 안에 마련한, 사무실이나 데이터센터에서나 볼 법한 IT 하드웨어나 소프트웨어를 실험해볼 수 있는 공간을 말한다. 새로운 직무 기술을 연습하는 환경이 될 수도 있고, 그냥 흥미로운 기술을 가지고 놀아보는 놀이터가 될 수도 있다.

왜 직접 NAS를 만드는가?

홈랩 세계가 처음이거나 PC를 직접 조립해본 경험이 없다면 직접 NAS를 만들지 않는 것을 추천한다.

비슷한 기능을 더 쉽게 배울 수 있는 완제품 솔루션이 있다.

이번 홈랩 NAS를 만들기 전까지 나는 4베이 Synology DS412+를 7년간 사용했다. 솔직히 Synology는 정말 마음에 들었다. 내가 했던 최고의 구매 중 하나였다. NAS 서버의 세계로 부드럽게 입문시켜 줬고, NAS가 뭔지 잘 모르겠다면 나도 Synology부터 시작해보라고 권하고 싶다.

몇 달 전, Synology가 부팅에 실패하고 딸깍거리는 소리를 내기 시작했다. 이 작은 장치 하나에 얼마나 의존하고 있었는지 깨닫자 등줄기에 식은땀이 흘렀다. Synology 서버는 사용자가 직접 수리할 수 없고, 보증 기간이 지나 부품을 고장 내면 서버 전체를 교체해야 한다. 그리고 나처럼 멍청하게 Synology 전용 저장 포맷을 썼다면 다른 Synology 시스템 없이는 데이터에 접근할 수 없다. (수정: Hacker News의 댓글 덕분에 Synology가 아닌 시스템에서도 Synology Hybrid RAID 볼륨을 복구할 수 있다는 것을 알게 됐다.)

다행히 기존 Synology는 내부를 청소하고 디스크를 다시 장착하니 복구됐지만, 중요한 경고가 됐다. 개방형 저장 포맷을 오픈소스로 구현한 TrueNAS로 갈아타기로 결심했다.

TrueNAS와 ZFS

TrueNAS(구 FreeNAS)는 스토리지 서버용 운영체제 중 가장 인기 있는 것 중 하나다. 오픈소스이고 거의 20년 가까이 유지돼 와서 믿을 만한 선택으로 보였다.

TrueNAS는 스토리지 서버를 위해 특별히 설계된 파일시스템인 ZFS를 사용한다. NTFS나 ext4 같은 전통적인 파일시스템은 저수준 디스크 I/O를 관리하는 데이터 볼륨 위에서 동작한다. 반면 ZFS는 파일 단위 로직부터 디스크 I/O까지 스택 전체를 직접 관리한다. 이 포괄적인 제어 덕분에 다른 파일시스템보다 더 강력하고 성능도 뛰어나다.

ZFS의 멋진 기능 몇 가지를 꼽자면 다음과 같다:

• 여러 물리적 디스크를 하나의 파일시스템으로 묶기
• 데이터 손상을 자동으로 복구
• 디스크에 있는 데이터의 특정 시점 스냅샷 생성 (OS X의 Time Machine과 유사)
• 디스크에 저장된 데이터를 선택적으로 암호화하거나 압축

이 시스템을 만들기 전까지 ZFS를 써본 적이 없어서 직접 써보는 것이 기대됐다.

스토리지 계획

필요 용량 가늠하기

Synology NAS를 샀을 때 처음에는 4TB 드라이브 3개를 장착하고 네 번째 슬롯은 비워뒀다. Synology Hybrid RAID 기준으로 사용 가능한 공간은 7TB였다. 3년 뒤 공간이 부족해져 네 번째 드라이브를 추가했고, 사용 가능한 공간은 10TB가 됐다.

새 빌드에서도 같은 전략을 쓰기로 했다. 당장 필요한 용량을 충족하면서 나중에 확장할 여유를 두는 것이다. 대략적인 목표는 20TB의 사용 가능한 공간으로 시작해, 나중에 디스크를 추가하면 최대 30TB까지 늘릴 수 있는 시스템이었다.

ZFS는 기존 풀에 새 드라이브를 추가하는 것을 허용하지 않는다고 알려져 있지만, 해당 기능은 현재 활발히 개발 중이다. 스토리지를 확장해야 할 때쯤이면 TrueNAS에서도 쓸 수 있게 되길 기대한다.

업데이트 (2025-01-25): 이 기능은 이제 사용 가능하며 최신 ZFS 버전에 포함됐지만, 아직 TrueNAS에서 직접 테스트해볼 기회는 없었다.

작은 디스크 여러 개 vs. 큰 디스크 적은 수

ZFS는 디스크 장애에 대비해 설계돼서 데이터 블록마다 중복 저장한다. 이 때문에 사용 가능한 총 용량은 단순히 각 디스크 용량을 합한 값이 아니다.

ZFS는 디스크들의 “풀”로 파일시스템을 만든다. 풀에 디스크가 많을수록 ZFS가 저장 공간을 더 효율적으로 활용한다. 예를 들어 ZFS에 10TB 드라이브 2개를 주면 전체 디스크 용량의 절반만 사용할 수 있다. 대신 4TB 드라이브 5개를 쓰면 14TB를 사용할 수 있다. 전체 디스크 공간은 두 경우 모두 동일하지만, 더 작은 드라이브 5개를 쓰면 사용 가능한 공간이 40% 더 많아진다.

NAS 서버를 만들 때는 큰 디스크를 적은 수로 쓸지, 작은 디스크를 많은 수로 쓸지 결정해야 한다. 작은 드라이브가 보통 $/TB 측면에서는 더 저렴하지만, 운영 비용은 더 많이 든다. 4TB 드라이브 2개는 8TB 드라이브 1개보다 전기를 두 배로 쓴다.

나는 서버의 물리적 크기를 최소화하고 싶어서 더 크고 적은 수의 드라이브를 선택했다.

raidz 1, 2, 3 중 무엇으로 할까?

ZFS는 raidz1, raidz2, raidz3라는 다양한 중복성 옵션을 제공한다. 가장 큰 차이는 안정성이다. raidz1은 디스크 한 개가 고장 나도 데이터를 잃지 않는다. raidz2는 두 개가 동시에 고장 나도, raidz3는 세 개가 동시에 고장 나도 버틸 수 있다.

안정성을 높이는 대신 사용 가능한 용량을 포기해야 한다. 4TB 하드 5개가 있을 때 각 ZFS 모드에서 얻을 수 있는 사용 가능 용량은 다음과 같다:

나는 raidz1을 선택했다. 디스크가 몇 개 안 될 때는 두 개가 동시에 고장 날 확률이 꽤 낮다고 봤다.

ZFS가 백업 전략이 될 수는 없다는 점을 명심하자. ZFS는 디스크 장애로부터 보호해주지만, 실수로 인한 삭제, 악성코드, 물리적 도난 등 ZFS가 막아주지 못하는 위협은 많다. 나는 restic으로 중요한 데이터를 모두 암호화된 클라우드 백업으로 복제해 둔다.

ZFS의 가치는 드라이브 하나가 죽었을 때 클라우드 백업까지 꺼내지 않아도 된다는 데 있다. 두 개가 동시에 고장 나면 백업에서 복구해야 한다. 귀찮은 일이겠지만, raidz2를 위해 사용 가능한 용량의 20%를 포기할 정도는 아니라고 판단했다.

물리적 드라이브 수가 많을수록 디스크 장애에 더 보수적으로 대비해야 한다. 풀이 20개 디스크로 구성됐다면 아마 raidz2나 raidz3를 썼을 것이다.

동시 다발적 디스크 고장 방지

단순하게 생각하면 두 디스크가 동시에 고장 날 확률은 극히 낮아 보인다. Backblaze 통계에 따르면 고품질 드라이브의 연간 고장률은 0.5~4%다. 연간 4%라면 일주일 기준으로는 0.08%다. 두 개가 동시에 고장 나는 일은 3만 년에 한 번꼴이니 괜찮지 않을까?

문제는 디스크 고장이 통계적으로 독립적이지 않다는 데 있다. 한 디스크가 고장 나면 옆에 있는 디스크의 고장 위험도 크게 높아진다. 특히 같은 모델, 같은 제조 배치에서 나온 디스크가 같은 워크로드를 처리했다면 더욱 그렇다.

게다가 ZFS 풀을 재구성하는 과정은 살아남은 모든 디스크에 평소보다 큰 부담을 준다. 정상 사용 환경에서는 몇 달 더 버틸 디스크가 풀 재구성이라는 추가 부하 때문에 죽어버릴 수도 있다.

이런 위험을 고려해 동시 고장 위험을 조금이라도 줄이기 위해 할 수 있는 일을 했다. 서로 다른 제조사의 서로 다른 모델 두 가지를 골랐다. 같은 제조 배치에서 나온 디스크를 받을 확률을 줄이기 위해 서로 다른 판매처에서 구매했다. 얼마나 효과가 있을지는 모르겠지만 비용이 크게 들지 않으니 해볼 만하다고 생각했다.

부품 선택 과정

메인보드

첫 번째 결정은 메인보드 크기였다. 나는 Synology DS412+의 콤팩트한 크기를 항상 마음에 들어 했다. mini-ITX 메인보드로 컴퓨터를 만들어본 적이 없는데, 이번이 좋은 기회라고 생각했다.

ASUS Prime A320I-K를 선택한 이유는 몇 가지다:

• SATA 포트가 4개 있어 디스크 4개를 메인보드에 바로 연결할 수 있다.
• Radeon 그래픽을 지원해 별도 그래픽 카드를 살 필요가 없다.
• 가격이 98달러로 저렴하다.

경고: 이 메인보드 선택은 후회한다. 자세한 내용은 아래를 참고하자.

B450도 고려했는데, 거의 비슷하면서 가격은 두 배 가까이 비쌌다. 주요 장점은 오버클로킹 지원이 더 좋다는 것이었는데, 나에게는 필요 없었다.

CPU

내가 읽은 바에 따르면 ZFS는 CPU를 많이 쓰지 않는다. 저렴한 Dell OptiPlex 7040 미니 PC에 TrueNAS를 설치해 간단히 테스트해봤는데 CPU를 거의 쓰지 않아서 저전력 모델을 써도 안전해 보였다.

CPU를 고를 때 가장 중요하게 본 기준은 A320 메인보드의 온보드 HDMI 출력을 쓸 수 있도록 Radeon 그래픽을 지원하는가였다.

결국 AMD Athlon 3000G로 정했다. 105달러에 불과하면서 Radeon 그래픽을 지원하고 CPU 벤치마크도 준수한 가성비 좋은 제품이다.

케이스

지난번 VM 서버를 만들 때 Fractal Design 케이스를 썼다. 내가 써본 케이스 중 가장 마음에 들어서 이번에도 Fractal Design을 선택했다.

콤팩트한 mini-ITX 케이스인 Fractal Design Node 304 Black으로 갔다. 타워보다는 큐브에 가까운 디자인이 마음에 들었고, 드라이브 베이가 6개라 필요한 만큼으로 시작하고 나중에 확장할 여유도 있다.

디스크 (데이터용)

케이스에 드라이브 베이가 6개 있으므로, 처음에는 8TB 디스크 4개로 시작하기로 했다. raidz1 기준으로 22.5TB를 쓸 수 있다. 나중에 확장할 때는 디스크를 하나 추가하면 30.9TB, 두 개를 추가하면 37TB까지 늘어난다.

8TB급에서는 7200RPM 미만인 드라이브가 거의 없고, 10,000RPM까지 올라가기도 한다. 내 NAS에서는 네트워크가 병목이라 7200RPM 이상은 의미가 없다. 10,000RPM 드라이브는 더 시끄럽고 전력도 더 먹을 뿐 실질적인 성능 이득은 없다.

처음에는 Backblaze 하드 드라이브 통계를 보고 고장률이 높은 디스크를 피하려 했지만, 그쪽에서 쓰는 드라이브는 가격대가 높은 편이었다. 한때 고장률이 0.5%로 인상적인 400달러짜리 드라이브도 고려했지만, 고장률을 몇 퍼센트 낮추자고 두 배나 더 쓰는 건 비합리적이었다.

마지막으로 피해야 할 함정은 기와식 자기 기록(SMR) 기술이다. ZFS는 SMR 드라이브에서 성능이 크게 떨어지므로 NAS를 만든다면 알려진 SMR 드라이브는 피해야 한다. 드라이브에 CMR(기존 자기 기록)이라고 표기돼 있다면 ZFS에 적합한 제품이다.

나는 Toshiba N300과 Seagate IronWolf를 선택했다. TrueNAS 포럼과 reddit에서 두 모델 모두 평가가 좋았고, 180~190달러로 용량 대비 괜찮은 가격이었다.

디스크 (OS용)

TrueNAS는 전용 OS 디스크가 필요하지만, 요구 사양은 높지 않다. 최소 2GB만 있으면 되고, 평소 OS 디스크를 자주 읽고 쓰지도 않는다.

나는 Kingston A400을 선택했다. 120GB M.2 디스크가 고작 32달러로 믿을 수 없을 만큼 저렴했기 때문이다. M.2 디스크는 정말 좋다! 케이블도 필요 없고 메인보드에 그대로 꽂아 나사 하나만 조이면 끝이다. 공간도 거의 차지하지 않고 다시 만질 일도 없다.

메모리

리서치를 하다 보면 ZFS는 디스크 용량 1TB당 RAM 1GB가 필요하다는 ‘법칙’을 자주 접하게 된다. ZFS 개발자인 Richard Yao에 따르면 그건 미신이다. 데이터 중복 제거 같은 RAM을 많이 먹는 기능도 있지만, 메모리가 넉넉하지 않아도 ZFS는 충분히 잘 동작한다.

솔직히 메모리 쇼핑은 정말 지루하다. 더 체계적인 과정을 갖고 싶었지만, 신뢰할 만한 벤치마크나 사용기를 찾기 어려웠다. 내가 쓴 과정은 다음과 같다:

1. ASUS A320I-K 메인보드와 호환되는 RAM 목록을 확인한다.
2. 32GB 또는 64GB 옵션 중 스틱 2개로 구성된 것만 추린다.
3. 믿을 만한 브랜드(Corsair, Crucial, G.SKILL, Kingston, Samsung, Patriot, Mushkin, HyperX)만 남긴다.
4. 150달러 이하인 옵션만 남긴다.

그 과정을 거쳐 CORSAIR Vengeance LPX 32GB CMK32GX4M2A2400C14 (2 x 16GB)(128달러)를 골랐다.

파워서플라이(PSU)

용량 측면에서는 사실상 어떤 소비자용 PSU라도 충분했다. PCPartPicker에 따르면 내 시스템은 218W만 있으면 된다. 300~400W급을 고르고 싶었지만, 반모듈러 옵션 중에는 더 낮은 용량이 없었다. 그래서 500W짜리 EVGA 110-BQ-0500-K1을 선택했다.

90도 SATA 케이블

90도 SATA 케이블이라는 걸 이번에 처음 사봤다. 메인보드와 PSU 사이에 표준 SATA 케이블을 꽂을 공간이 부족하다는 걸 보고 나서야 필요하다는 걸 알았다. 이 슬림한 90도 케이블이 문제를 해결해줬다.

빠진 것들

가격, 복잡성, 물리적 공간 때문에 의도적으로 제외한 부품들이 몇 가지 있다.

그래픽 카드(GPU)

물리적 공간과 메인보드 포트 모두 부족해서 별도 그래픽 카드는 넣고 싶지 않았다. 외부 카드 없이도 그래픽을 처리할 수 있는 메인보드와 CPU 조합을 선택했다.

호스트 버스 어댑터(HBA)

많은 NAS 빌드에는 호스트 버스 어댑터(HBA)가 포함된다. HBA는 메인보드의 PCI 슬롯에 꽂아 메인보드가 지원할 수 있는 디스크 수를 늘려주는 칩이다.

ZFS는 HBA 펌웨어를 다시 플래싱해야 한다는 번거롭고 헷갈리는 과정이 필요하다고 알려져 있다 (수정: 재플래싱은 RAID HBA에만 필요하다고 한다). 당장은 HBA 없이 가기로 했다. ASUS A320I-K에는 SATA 포트가 4개 있어 당장 필요한 용도에는 충분하다. 나중에 HBA가 필요할 때를 대비해 PCI 슬롯 하나는 비워뒀다.

ECC RAM

다양한 TrueNAS 빌드를 조사하면서 ECC RAM(오류 정정 코드 RAM)은 데이터 손상을 막기 위해 필수라는 글을 여러 번 봤다. 결국 ECC RAM 대신 일반 소비자용 RAM을 쓰기로 했다.

당연히 서버가 RAM에서 데이터를 손상시키는 건 원치 않지만, 지난 30년간 ECC RAM 없이 컴퓨터를 써오면서 데이터 손상을 체감한 적은 한 번도 없었다. 하루 종일 많은 사용자가 무거운 부하를 거는 서버라면 ECC RAM이 들어간 빌드를 선택했겠지만, 가정용으로는 일반 소비자용 RAM으로도 충분하다고 본다.

SLOG 디스크

많은 ZFS 빌드에는 SLOG(Separate Intent Log, 별도 인텐트 로그)라고 불리는 별도의 전용 SSD가 포함된다.

아이디어는 SSD에 쓰는 것이 여러 개의 회전식 디스크에 쓰는 것보다 몇 배는 빠르다는 데 있다. 애플리케이션이 데이터를 쓰면 ZFS가 SSD에 빠르게 쓰고 애플리케이션에 쓰기가 성공했다고 알린 뒤, 비동기적으로 데이터를 SSD에서 스토리지 풀로 옮긴다. SLOG는 쓰기 속도를 크게 향상시킨다.

나는 포트와 드라이브 베이 제약 때문에 SLOG 디스크를 넣지 않기로 했다. SLOG를 추가하려면 유일한 PCI 슬롯 하나를 포기하거나 6개 드라이브 베이 중 하나를 포기해야 했다. 나중에 용량을 확장할 여지를 남겨두는 편이 낫다고 판단했다.

부품 목록

* 주의: 이 메인보드는 AMD Athlon 3000G CPU와 바로 호환되지 않을 수 있다. 자세한 내용은 아래를 참고하자.

완제품과 비교

비교를 위해 비슷한 가격대의 완제품 솔루션을 몇 가지 가져와 봤다.

내 빌드의 총비용은 완제품과 비슷하지만 가성비는 더 좋다. RAM은 8배나 많고, 폐쇄적이고 특정 업체에 종속된 OS 플랫폼에 갇히지도 않는다.

빌드 사진

TinyPilot으로 서버 만들기

이 블로그를 오래 읽은 분이라면 내가 서버를 만들고 관리하기 위해 Raspberry Pi로 만든 도구를 기억할 수도 있다. TinyPilot이라는 이름이다. 이번이 TinyPilot으로 만든 세 번째 서버이자, 새로운 TinyPilot Voyager 2로 만든 첫 번째 서버였다.

편향된 얘기겠지만, Voyager 2로 서버를 만드는 과정은 정말 재미있었다! 서버에 키보드나 모니터를 한 번도 연결할 필요가 없었다. 웹 브라우저에서 비디오 출력을 보고, BIOS로 부팅하고, TrueNAS 설치 이미지를 마운트할 수 있었다.

한 가지 아쉬웠던 점은 BIOS 업그레이드였다. TinyPilot은 .img나 .iso 같은 디스크 이미지를 마운트할 수 있지만, 아직 원시 파일을 대상 컴퓨터와 공유하는 기능은 없다. ASUS BIOS 업그레이드용 .CAP 파일을 로드해야 할 때, 순수 TinyPilot 빌드를 고집하지 못하고 부끄럽게도 USB 메모리를 썼다. 다음 BIOS 업그레이드 때는 TinyPilot이 이 시나리오도 처리할 수 있도록 지원하고 싶다.

이 BIOS 버전은 호환이 안 되는 걸까? 아니면 내가 바보인 걸까?

모든 부품을 장착하고 전원을 켰는데 화면에 아무것도 나오지 않았다.

어라! 메인보드의 온보드 비디오 요구사항을 잘못 이해한 걸까? 평소처럼 진단을 시작했다. RAM을 다시 꽂고, CPU를 다시 꽂고, 케이블을 모두 확인했지만 결과는 같았다.

허겁지겁 검색해보니 ASUS Prime A320I-K는 Athlon 3000G와 함께 동작하려면 BIOS 업그레이드가 필요하다는 얘기가 있었다. 부품을 고를 때 그 경고를 본 기억이 났는데 그냥 넘겨버렸었다. “BIOS 업데이트쯤이야, 별거 아니지!”라고 생각했던 것이다.

CPU 없이 BIOS를 어떻게 업그레이드할지는 생각하지 못했다.

다행히 2017년 홈랩 VM 서버에 있던 Ryzen 7 CPU가 호환된다고 나와 있었다. 그 서버에서 CPU와 GPU를 빌려와 새 NAS 서버를 부팅시키는 데 성공했다!

이상하게도 빌린 부품으로 부팅에 성공한 뒤에도 메인보드는 BIOS 버전이 2203이라고 표시했는데, ASUS는 이 버전이 AMD Athlon 3000G CPU와 호환된다고 주장한다. 그래도 최신 BIOS인 5862로 업데이트했다.

5862로 업그레이드한 뒤에도 여전히 부팅이 안 됐다. 그제야 HDMI 케이블을 서버의 DisplayPort 단자에 꽂고 있었다는 걸 깨달았다.

이 부품 빌려오기 소동이 애초에 필요했던 걸까? 두 가지 가능성이 있다:

• 내가 멍청해서 BIOS를 업그레이드한 뒤에야 HDMI 케이블이 메인보드의 DisplayPort 단자에 꽂혀 있었다는 걸 알아차린 것이다.
• ASUS가 멍청해서 Athlon 3000G가 BIOS 버전 2203과 호환된다고 잘못 표기한 것이다.

보통이라면 내 탓을 하겠지만, ASUS BIOS가 워낙 불안정해서 ASUS 쪽 문제일 수도 있다. 어쨌든 빌린 부품 없이 NAS를 부팅하는 데 성공해서 안도했다.

성능 벤치마크

이번 글을 쓰면서 놀랐던 점 중 하나는 NAS 성능을 측정할 만한 좋은 벤치마크 도구를 찾을 수 없었다는 것이다. NAS 자체에서 로컬 디스크 I/O를 측정하는 도구는 있지만 실제 사용 환경을 반영하지 못한다. 내 사용량의 대부분은 네트워크를 통하므로, 로컬 디스크 벤치마크는 네트워크 스택의 병목을 완전히 놓치게 된다.

그래서 그냥 간단한 벤치마크를 직접 만들었다. 랜덤 파일 데이터를 두 세트 생성한 뒤 robocopy로 메인 데스크톱과 NAS 사이의 읽기/쓰기 속도를 측정했다. 결코 엄밀한 테스트는 아니었다. 독립된 네트워크에서 한 것도 아니고 테스트 중에 데스크톱의 다른 프로세스를 모두 끈 것도 아니다. 비교를 위해 예전 Synology DS412+에서도 동일한 테스트를 수행했다.

첫 번째 파일 세트는 1GiB 파일 20GiB 분량이었고, 다른 하나는 1MiB 파일 3GiB 분량이었다. 암호화된 볼륨과 암호화되지 않은 볼륨 모두에서 세 번씩 시도한 평균을 냈다.

성능은 111MiB/s(931Mbps)에서 정점을 찍었는데, 이는 1Gbps에 의심스러울 정도로 가깝다. 이는 스위치, 데스크톱, NAS 서버 모두 1Gbps 이더넷 포트를 갖고 있어 네트워크 하드웨어가 병목임을 시사한다.

읽기 성능

암호화되지 않은 볼륨에서는 7년이나 된 낡은 Synology가 반짝이는 새 TrueNAS 빌드를 앞서는 모습을 보고 놀랐다. Synology는 작은 파일 읽기에서 31% 더 빨랐고 큰 파일에서는 10% 더 빨랐다.

Synology의 영광은 오래가지 못했다. 암호화가 걸리자 완전히 무너졌기 때문이다. Synology의 읽기 속도는 암호화된 볼륨에서 67~75% 떨어진 반면, TrueNAS는 암호화의 영향을 전혀 받지 않았다. 덕분에 암호화된 볼륨에서는 TrueNAS가 작은 파일에서 2.3배, 큰 파일에서 3배 더 빨랐다. 내 데이터 대부분은 암호화된 볼륨에 있어 이 테스트가 내 일반적인 사용 환경을 더 정확히 반영한다.

쓰기 성능

예전 Synology가 읽기에서는 TrueNAS를 앞섰지만 쓰기에서는 그렇지 않았다. 암호화되지 않은 볼륨에서도 TrueNAS는 작은 파일에서 77% 더 빨랐고, 1GiB 파일에서는 두 시스템이 비슷했다.

다시 말하지만 암호화를 켜면 Synology의 쓰기 성능은 급격히 떨어진다. 암호화가 활성화된 상태에서는 TrueNAS가 작은 파일에서 5.2배, 큰 파일에서 3.2배 더 빨랐다.

전력 소모

Kill A Watt P4460 계측기로 예전 Synology와 새 TrueNAS 서버의 전력 소모를 측정했다:

새 서버는 예전 Synology보다 60% 더 많은 전력을 쓴다. 좀 의외였다. kWh당 약 0.17달러를 내니 서버 유지비는 한 달에 약 7.20달러다.

무엇이 전력 소모를 높이는지는 잘 모르겠지만, 한 가지 가능성은 PSU다. Synology는 다른 부품에 딱 맞춰진 PSU를 썼을 테지만, 내 500W PSU는 필요한 용량의 15%만 쓰는 시스템에서는 효율이 떨어질 가능성이 크다.

마무리 생각

메인보드

ASUS Prime A320I-K에 대한 가장 큰 불만은 호환성이 제한적이라는 점이었지만, 내가 착각했을 수도 있다.

그 외에도 BIOS가 마음에 들지 않았다. 업그레이드 유틸리티가 완전히 고장 나 있었다. 최신 BIOS 버전을 다운로드해 설치해야 하는데, 업그레이드를 시도하면 최신 BIOS를 이미 쓰고 있다고 계속 말했다. 결국 파일을 직접 다운로드해 USB 메모리에 넣어 수동으로 업그레이드해야 했다.

또한 A320I-K가 최대 32GB RAM만 지원한다는 것도 놓쳤다. 메모리를 확장할 일이 있을지 모르겠지만, 좀 더 여유를 두는 게 좋았을 것이다.

Realtek 네트워크 드라이버 수정

시스템에 네트워크 부하가 심할 때 메인보드의 이더넷 어댑터가 가끔 죽는 것을 발견했는데, reddit의 /u/trevaar님이 친절하게 이유를 설명해줬다. 알고 보니 A320I-K의 Realtek NIC용 FreeBSD 드라이버에 안정성 문제가 있지만, 다음 임시 해결책으로 공식 드라이버를 로드할 수 있다:

1. TrueNAS 웹 대시보드에서 System > Tunables로 이동한다.
2. 다음 두 설정을 추가한다:

   Variable	Value	Type
   if_re_load	YES	loader
   if_re_name	/boot/modules/if_re.ko	loader

케이스

Fractal Design Node 304에는 실망했다. VM 서버를 Fractal Design Meshify C로 만들 때는 계속 감탄하게 만드는 처음 보는 기능들이 있었는데, 이번 빌드에서는 정반대였다. “왜 이 케이스에서는 이런 게 문제지? 예전에는 한 번도 문제된 적이 없는데?”라는 생각이 계속 들었다.

겉보기에는 멋지지만 작업하기는 불편했다. 문서도 거의 없고 케이스의 일부 메커니즘이 직관적이지 않았다.

이번이 첫 mini-ITX 빌드라 케이스 디자이너들이 크기를 최소화하기 위해 희생해야 하는 부분이 있다는 건 알지만, 어쩌면 내가 너무 가혹하게 평가하는 것일 수도 있다.

CPU

Athlon 3000G에는 만족하지만, 내 용도에는 터무니없이 과분한 성능이었다. TrueNAS 대시보드를 보면 지난 한 달간 CPU 부하가 99% 유휴 상태였다고 나온다:

CPU에서 가장 중요했던 점은 AMD Radeon 비디오 기술을 지원해 GPU가 필요 없었다는 것이다. 105달러에 훌륭한 선택이었다.

디스크 (데이터용)

디스크는 아직 평가하기 이르니 5년 뒤에 다시 확인해주길 바란다. 지금까지는 잘 동작하고 있다.

가장 걱정했던 건 소음이었는데 전혀 들리지 않는다. 성능 벤치마크를 돌릴 때만 소리가 들렸다. 흥미롭게도 읽기나 쓰기 중이 아니라 테스트 사이에 파일을 삭제할 때 가장 시끄러웠다.

파워서플라이(PSU)

시스템이 유휴 상태에서 60W를 쓰는 것을 보고 더 낮은 용량의 파워서플라이에 좀 더 신경 쓸 걸 그랬나 싶었다. 500W는 필요한 용량의 두 배가 넘으니, 300~400W급 PSU였다면 유휴 전력 소모를 줄일 수 있었을지도 모른다.

디스크 (OS용)

Kingston A400은 잘 동작하고 있다. TrueNAS가 OS 디스크에 거는 부하가 워낙 적어서 할 일이 거의 없다. 90GB가 비어 있으니 더 작은 드라이브를 써도 됐을 것이다.

TrueNAS 리포팅을 보면 OS 디스크 활동이 거의 없다. 오류 검사를 위한 기본 예약 작업으로 매주 아주 작은 I/O 읽기가 있을 뿐이다.

TrueNAS

나는 더 성숙한 FreeBSD 기반인 TrueNAS Core 13을 쓰고 있다. 다른 선택지는 Debian 기반인 TrueNAS Scale로, 하드웨어와 소프트웨어 호환성이 더 넓다.

TrueNAS를 시작하면서 Synology의 웹 UI를 이기기는 어려울 거라는 걸 알고 있었다. 네트워크 장비 중 가장 우아하고 직관적인 인터페이스다. 기반 파일시스템의 기술적인 세부사항을 사용자가 신경 쓰지 않게 깔끔한 UI를 정말 잘 만들어놨다.

TrueNAS는 나름의 해커 감성이 있지만 Synology에 비하면 사용성이 크게 떨어진다. 인터페이스는 커맨드 라인 외의 것에는 경멸이라도 하는 사람이 디자인한 것처럼 보인다.

TrueNAS에서는 새 볼륨을 만들고 네트워크에 공유하기까지 여러 번 시도해야 했다. 서로 연결되지 않은 여러 메뉴를 오가야 하고 다음에 무엇을 해야 하는지에 대한 힌트도 없다. 반면 Synology는 필요한 모든 설정을 안내하는 매끄러운 UI 흐름이 있다.

서드파티 앱 설치도 TrueNAS에서 훨씬 더 어려웠다. 나는 영화와 TV 컬렉션을 스트리밍하기 위해 Plex Media Server를 쓰는데, Plex는 TrueNAS에서 미리 구성된 플러그인이다. 가장 설치하기 쉬운 앱 중 하나여야 하는데 문서 여기저기를 뒤지며 한 시간을 씨름해야 했다. 반면 Synology에서는 마법사를 몇 번 클릭하면 2분 만에 설치가 끝난다.

나는 플랫폼 종속보다 더 중요하게 생각하는 것이 거의 없고 오픈소스 소프트웨어를 응원하고 싶어서 TrueNAS를 계속 쓸 것이다. 이념적이지 않은 친구에게 NAS를 추천한다면 Synology를 권할 것이다.

ZFS

ZFS는 멋지지만 RAID 외에는 대부분의 기능을 쓸 일이 없었다.

사람들이 스냅샷 얘기를 많이 하는데 나는 필요성을 못 느꼈다. 이미 restic 백업 솔루션에 스냅샷이 있다. 그리 편리하진 않지만 restic을 2년간 쓰면서 스냅샷에서 데이터를 복구해야 했던 건 한 번뿐이었다.

한 가지 흥미로운 기능은 암호화된 스냅샷이다. 데이터 볼륨을 복호화하지 않고도 스냅샷을 뜰 수 있다. 암호화된 채로 보관하고 싶은데 자주 접근할 필요는 없는 데이터가 있어서, 복호화하지 않고 정기적으로 백업할 수 있다면 유용할 것 같다.

총평

전반적으로 새 NAS가 마음에 들고 이번 빌드를 통해 많이 배웠다. 이게 NAS를 처음 접한 경험이었다면 끔찍하고 혼란스러웠겠지만, Synology로 부드럽게 입문한 덕분에 관련 기술을 익힐 수 있었다. 이제 보조 바퀴를 뗀 느낌이고 ZFS와 TrueNAS의 고급 기능을 만져볼 준비가 됐다.

영상

2.5년 후 업데이트

2024년 11월 기준으로 이 스토리지 서버를 약 2.5년간 사용했다. 그간의 사용 소감을 정리해본다.

여전히 NAS에 만족한다

여전히 NAS가 마음에 든다. Synology의 사용자 경험이 그립긴 하지만 TrueNAS에서 더 통제권을 갖고 있다는 느낌이 든다.

Toshiba N300 디스크 중 하나에서 딸깍거리는 소리가 나기 시작했다

NAS를 만든 지 약 18개월 뒤, Toshiba N300 디스크 중 하나에서 딸깍거리는 소리가 나기 시작했다. SMART 테스트에서는 문제가 없다고 나왔지만, 딸깍거리는 디스크를 계속 쓰는 건 위험하다고 판단했다.

8TB Seagate IronWolf로 교체한 뒤로는 아무 문제가 없다.

랙 마운트 섀시로 교체했다

NAS를 만든 지 1년 뒤 서버 랙을 구매했고 모든 인프라를 랙으로 옮기기 시작했다.

NAS용으로는 Sliger CX3701 10베이 서버 섀시를 구매했다. 섀시 자체는 마음에 들고 추천할 만하지만, 메인보드의 유일한 PCI 슬롯을 더 많은 SATA 포트를 확보하는 데 쓸 것이 확실할 때만 추천한다. 그래픽이나 10G 네트워킹에 PCI 슬롯이 필요하다면 mini-ITX 메인보드는 보통 SATA 포트가 4개뿐이라 10개 베이 중 4개만 쓸 수 있다.

Sliger 서버 섀시로 옮기면서 PSU도 새로 필요했는데, Sliger는 SFX와 SFX-L 폼팩터 PSU만 지원하기 때문이다. SilverStone 300W 80 Plus Bronze ST30SF-V2로 갔다. 시스템이 최대 150W 정도만 쓰는데 500W PSU를 쓰고 있었으니 300W로 줄일 수 있어 다행이었다.

TrueNAS Scale로 전환했다

TrueNAS Scale 쪽에 더 많은 투자가 이뤄지는 것처럼 보여서 TrueNAS Scale로 갈아탔다. 가장 큰 차이는 Core는 FreeBSD 기반이고 Scale은 Linux Debian 기반이라는 점이다.

바꾼 뒤로는 큰 차이를 못 느꼈고, Scale의 웹 UI가 살짝 더 나은 정도다. 그리고 평소 Linux에서 작업하는 편이라 FreeBSD보다는 터미널 사용이 더 편하다.

10Gbps 광 NIC를 추가했다

서버 랙을 구성하면서 10Gbps 포트가 있는 스위치를 골랐으니 NAS에도 10Gbps NIC를 사기로 했다.

안타깝게도 그 NIC는 동작하지 않았고, 두 개를 더 시도해봤지만 세 개 모두 동작하지 않았다.

결국 메인보드 호환성 문제라는 결론을 내리고 Gigabyte B550I Aorus Pro로 업그레이드했고(아래 참고), 그제야 Mellanox ConnectX-3 EN CX311A NIC가 동작했다.

그래도 10Gbps NIC로 TrueNAS를 설정하는 데 애를 먹었다. 계속 메인보드의 온보드 LAN을 기본으로 잡았기 때문이다. NAS의 고정 IP를 10Gbps NIC로 옮기려 하자 Kubernetes가 이미 그 IP를 사용 중이라며 계속 오류를 냈다. 고정 IP 할당을 원자적으로 옮길 방법을 찾을 수 없어 BIOS에서 메인보드 LAN을 비활성화해야 했다. 그래도 IP를 옮길 수 없어서 결국 NAS에 새로운 고정 IP를 할당해야 했다.

Gigabyte B550I Aorus Pro 메인보드로 교체했다

위에서 언급했듯 10Gbps NIC와의 호환성 문제를 해결하기 위해 Gigabyte B550I Aorus Pro AX 메인보드로 업그레이드했다.

메인보드는 괜찮다. ASUS Prime A320I-K보다 조금 더 마음에 든다:

• 장점
  • 자체 I/O 쉴드가 있다.
  • SATA 포트가 바로 위를 향하고 있어 특수한 직각 SATA 커넥터가 필요 없다.
  • RAM 슬롯이 더 쓰기 편하다.
  • CPU 마운트가 더 다루기 쉽다.
  • 팬 핀이 더 편리한 위치에 있다.
• 단점
  • 지금까지 본 M.2 슬롯 중 가장 헷갈리고 설명서에도 설명이 전혀 없다. YouTube에서 영상을 찾아봐야 했다.
  • BIOS로 부팅하는 속도가 ASUS Prime A320I-K보다 확실히 느리다.

후회: mini-ITX는 확장에 한계가 있다

가장 후회되는 점은 케이스와 메인보드를 mini-ITX 폼팩터로 선택한 것이다.

mini-ITX 메인보드에는 PCI 슬롯이 하나뿐이다. 대부분 SATA 포트도 4개뿐이고, 온보드 그래픽을 지원하면서 더 많은 포트를 가진 제품은 본 적이 없다. 즉, 디스크를 4개 이상 추가하기 위해 HBA를 쓰고 싶다면 남은 PCI 슬롯이 없게 된다.

내 경우 10Gbps 네트워크 카드를 설치하고 싶었지만, 그러면 새 섀시와 메인보드를 사지 않는 한 디스크 4개에 갇히게 된다.

다시 한다면 3.5인치 하드 드라이브를 6~8개 장착할 수 있는 랙 마운트 섀시와, PCI 슬롯이 여러 개거나 최소 SATA 포트가 8개인 메인보드를 샀을 것이다.

Blogging for Devs Community 멤버들에게 이 글의 초안에 대한 피드백을 주셔서 감사드립니다.