Ted-knight와 ZimaCube 2: 한 단계씩 구축하는 AI 지원 NAS

ted-knight를 만나보세요

Ted-knight는 Pioneer Program에서 가장 체계적으로 ZimaCube 2를 구축하고 있는 사람 중 한 명입니다. 그의 ZimaCube 2 Build는 하나의 최종 구성에 맞춰 정리된 프로젝트가 아닙니다. 대신 여러 단계로 나뉘며, 다음 계층을 추가하기 전에 각 계층을 테스트합니다.

이 빌드의 목표는 간단합니다. 오늘날 중요한 데이터를 맡길 수 있는 NAS를 구축하면서도, 향후 셀프 호스팅, 미디어, 로컬 AI 및 기타 워크로드를 수용할 수 있는 여지를 남기는 것입니다. 이를 위해 ted는 스토리지 아키텍처, ZFS, btrfs, RAM 및 NVMe 업그레이드, OCuLink 확장, 벤치마킹, ZimaOS 통합, Immich 마이그레이션을 거쳤고, 이 머신이 앞으로 어떤 모습으로 발전할지에 대한 로드맵도 점점 구체화하고 있습니다.

그는 ZimaCube 2 Standard로 시작했습니다. Intel Core i3-1215U 시스템에 8GB DDR5와 256GB NVMe 시스템 드라이브가 탑재된 모델입니다. 하지만 원래 구성은 오래 유지되지 않았습니다.

더 많은 서비스를 추가하기 전에 스토리지 기반 구축하기

Ted가 가장 먼저 우선한 일은 서버를 애플리케이션으로 가득 채우는 것이 아니었습니다. 다양한 종류의 데이터가 어디에 저장되어야 하는지 결정하는 일이었습니다.

결과적으로 이 시스템은 각기 다른 역할을 의도적으로 맡은 여러 스토리지 계층으로 구성되었습니다. ZimaOS는 별도의 256GB Kingston NVMe에 그대로 유지됩니다. Crucial P510 2TB NVMe는 AppData, Docker 이미지, 데이터베이스 및 기타 활성 워크로드를 위한 btrfs 계층인 Arctic-Storage가 되었습니다. 2TB NVMe 드라이브 4개는 약 5.5TB의 사용 가능한 공간을 제공하는 ZFS RAIDZ1 풀 glacier를 구성합니다. 이후 4TB Seagate IronWolf 드라이브 4개는 대용량 미디어와 사용 빈도가 낮은 데이터를 위한 12TB btrfs RAID5 풀이 되었습니다.

이 아키텍처의 핵심은 모든 드라이브를 동일하게 작동시키는 것이 아니라, 스토리지를 워크로드에 맞추는 데 있습니다. 랜덤 I/O가 많은 데이터베이스는 고속 P510에 두고, ZFS 체크섬과 중복성의 이점을 누릴 수 있는 대규모 순차 워크로드와 데이터는 glacier에 저장할 수 있습니다. 대용량 미디어는 더 높은 용량의 IronWolf 계층으로 옮길 수 있습니다.

Thunderbolt 4가 작동하지 않았을 때 아키텍처가 바뀌다

ted의 프로젝트에서 가장 유용한 부분 중 하나는 실패한 실험도 문서에 그대로 남아 있다는 점입니다.

원래 계획은 Aoostar TB4S-OC 4-NVMe 인클로저를 Thunderbolt 4를 통해 ZimaCube 2에 연결하는 것이었습니다. Ted는 다양한 40Gbps 케이블과 두 Thunderbolt 포트, 외부 전원, 기본 커널 동작까지 테스트했지만 인클로저는 여전히 안정적인 PCIe 연결을 설정하지 못했습니다.

조사 결과는 결국 ZimaOS의 Thunderbolt 구성과 인클로저 내부 ASMedia ASM2462PDX 컨트롤러의 상호 작용을 가리켰습니다. ted는 원래 계획을 계속 억지로 추진하는 대신 아키텍처를 변경했습니다.

PCIe x4-OCuLink 어댑터를 슬롯 1에 장착했습니다. Aoostar 인클로저는 Thunderbolt에서 직접 OCuLink 연결로 전환되었습니다. Thunderbolt 구성에서 연결을 막았던 터널링 및 인증 문제 없이, 첫 부팅에서 NVMe 드라이브 4개가 모두 인식되었습니다.

이 변경 사항은 이후 계획에도 영향을 미쳤습니다. 이제 슬롯 1은 스토리지가 차지하고 있으며, 두 Thunderbolt 포트는 직접 네트워킹이나 다른 eGPU 구성 같은 향후 실험을 위해 비워 두었습니다. 연결 실패는 단순히 문제 해결 기록의 각주로 남지 않았고, 시스템 전체의 로드맵을 바꿨습니다.

어떤 계층이 더 빨랐는지 가정하는 대신 스토리지 벤치마킹하기

스토리지가 준비되자 ted는 이를 측정했습니다.

그의 Phase 1.5 작업은 다음을 사용합니다. fio glacier ZFS RAIDZ1 풀을 Arctic-Storage와 비교하여 “NVMe”를 하나의 성능 범주로 취급하지 않도록 했습니다. 콜드 벤치마크에서 glacier는 순차 쓰기 1,726 MB/s와 순차 읽기 2,591 MB/s를 기록했으며, 단일 드라이브인 Arctic 계층은 랜덤 I/O에서 훨씬 강력해 초기 위치에서 랜덤 4K 읽기 205,588 IOPS에 도달했습니다.

ZFS ARC가 개입했을 때 더 흥미로운 결과가 나타났습니다. glacier에서 반복적으로 읽은 데이터는 NVMe 드라이브에 다시 접근하지 않고 RAM에서 제공될 수 있었습니다. 이전 16GB 메모리 구성에서 웜 랜덤 읽기 성능은 콜드 결과인 14,781 IOPS 대신 약 83,929 IOPS에 도달했습니다.

이 결과는 이후 또 다른 하드웨어 결정에도 영향을 주었습니다. Ted는 16GB DDR5 모듈 2개를 사용해 시스템 메모리를 32GB로 업그레이드하면서 싱글 채널에서 듀얼 채널 메모리로 전환했습니다. 업그레이드 후 웜 ARC 랜덤 읽기 성능은 다시 증가해 126,816 IOPS에 도달했으며, 이는 이전 결과보다 측정 기준 51% 향상된 수치입니다.

벤치마크 결과는 Crucial P510의 초기 장착 위치에도 의문을 제기했습니다. Standard 모델의 7번 베이에서는 브리지로 인해 순차 처리량이 제한되었습니다. Ted는 드라이브를 온보드 M.2 슬롯으로 옮겼고, 순차 읽기 속도가 874 MB/s에서 1,677 MB/s로 증가했으며 랜덤 4K 읽기 성능은 205,588 IOPS에서 403,078 IOPS로 향상되었습니다.

교훈은 단순히 한 슬롯이 더 빠르다는 것이 아니었습니다. 측정 결과에 따라 어떤 작업 부하를 어디에 배치할지, 실제로 어떤 업그레이드가 가치 있는지가 달라졌습니다.

ZimaOS에서 ZFS 함께 사용하기

이 구성은 ZimaOS가 기본적으로 관리하는 영역과 숙련된 사용자가 그 아래에 추가할 수 있는 영역 사이의 흥미로운 경계도 보여 줍니다.

Ted는 Arctic-Storage와 IronWolf 풀에 의도적으로 btrfs를 사용합니다. 이 볼륨들은 ZimaOS와 자연스럽게 통합되기 때문입니다. glacier 풀은 다릅니다. 이 풀은 명령줄에서 ZFS RAIDZ1로 만들어졌으며, ted에게 ZFS 데이터셋, 체크섬, ARC 캐싱, 스냅샷과 함께 계획한 일부 작업 부하에 더 잘 맞는 스토리지 모델을 제공했습니다.

이러한 유연성에는 한 가지 아쉬운 점이 있습니다. 명령줄에서 만든 ZFS 풀은 인터페이스에서 기본 ZimaOS 스토리지 볼륨으로 표시되지 않습니다.

Ted의 우회 방법은 간단하면서도 실용적입니다. 그는 개별 ZFS 데이터셋을 다음 경로 아래의 심볼릭 링크로 노출합니다. /DATAglacier 문서, 미디어, 백업, VM 스토리지 같은 경로를 ZimaOS Files 앱 안에 표시하면서도 기본 풀은 ZFS로 관리할 수 있습니다.

그는 메모리 표시와 관련된 또 다른 문제도 발견했습니다. ZFS ARC가 유휴 메모리를 채우고 있을 때 ZimaOS는 RAM의 상당 부분을 “사용 중”으로 표시할 수 있습니다. 살펴보면 btop 그리고 ARC 통계를 함께 보면 더 유용한 사실을 알 수 있습니다. 캐시는 사용할 수 있는 메모리가 있기 때문에 메모리를 사용하며, 애플리케이션에 더 많은 메모리가 필요해지면 ZFS가 캐시를 해제할 수 있습니다.

이것이 바로 Pioneer 빌드에서 중요한 피드백입니다. Ted는 ZimaOS에서 작동하는 기능만 보여 주는 것이 아니라, 고급 스토리지 구성이 현재 UI의 한계에 도달하는 지점과 그 상황에서 어떻게 대처하는지도 기록하고 있습니다.

기존 Immich 라이브러리를 기록 손실 없이 옮기기

대체할 수 없는 데이터가 저장되기 시작하면 스토리지 아키텍처의 의미가 훨씬 커집니다.

ted에게 그 테스트 대상은 Immich였습니다. 그는 이미 구형 DIY ZimaOS 서버에서 Immich 인스턴스를 실행하고 있었으며, 처음부터 다시 시작하지 않고 ZimaCube 2로 옮기고 싶어 했습니다.

마이그레이션 대상은 사진 14,505장과 동영상 925개로, 총 134GiB였습니다. 하지만 중요한 데이터는 이미지 파일에만 국한되지 않았습니다. 앨범, 사람 정보, 얼굴 인식, 추억, 공유 링크 및 기타 메타데이터는 PostgreSQL에 저장되어 있었습니다.

LAN을 통해 ZimaOS 파일 앱을 사용하여 ted는 두 항목을 모두 복사했습니다. /DATA/Gallery/immich 그리고 전체 /DATA/AppData/immich 디렉터리와 다음을 포함한 pgdata. 복사하기 전에 원본 Immich 인스턴스를 중지하여 PostgreSQL 데이터가 일관된 상태로 유지되도록 했습니다.

마이그레이션 후에도 계정, 앨범, 얼굴 정보, 추억, 라이브러리가 그대로 유지되었으며, 보고된 데이터 손실은 전혀 없었습니다. 이후 Ted는 성공적으로 로그인되었다고 해서 모든 항목이 보존되었다고 가정하지 않고 PostgreSQL 데이터베이스를 직접 확인했습니다.

같은 방식으로 이전할 계획이라면, ZimaCube 2 Immich 마이그레이션 가이드에서 동일한 핵심 사항을 설명합니다. 미디어 라이브러리만 옮기는 것으로는 충분하지 않으며, 데이터베이스도 함께 옮겨야 합니다.

134GiB 마이그레이션에서 725GiB 규모의 셀프 호스팅 사진 및 동영상으로

Immich 단계는 기존 서버 마이그레이션이 성공했다고 끝난 것이 아니었습니다.

기존 ZimaOS 라이브러리를 옮기는 작업으로 시작했지만, ted의 사진과 동영상을 보관하는 기본 공간으로 iCloud를 사용하던 방식에서 훨씬 더 크게 벗어나는 전환이 되었습니다. 그의 iPhone은 기존 iCloud 라이브러리의 원본을 ZimaCube 2에서 실행 중인 Immich로 전송하기 시작했습니다.

해당 단계가 끝날 무렵, 서버에는 총 725GiB에 달하는 자산 63,665개가 저장되어 있었습니다. 사진은 55,604장, 동영상은 8,061개였습니다. iCloud 전송만 약 655GB를 차지했으며, 그중 대부분은 4K 동영상이 차지했습니다.

목표는 모든 Apple 클라우드 서비스를 대체할 수 있는 것처럼 가장하는 것이 아니었습니다. Ted는 기기 백업, 메시지 및 기타 iOS 전용 데이터는 더 작은 iCloud 요금제에 유지하는 것이 합리적이라고 판단했습니다. 변화의 초점은 더 분명했습니다. 대용량 사진 및 동영상 라이브러리를 자신이 관리하는 스토리지로 옮기면서도 여전히 유용한 클라우드 서비스는 유지하는 것입니다.

이 결정은 새로운 책임도 만들었습니다. 자체 호스팅 사진 라이브러리가 클라우드 사본보다 안전해지려면 제대로 백업되어야 합니다. 따라서 Ted의 마이그레이션 기록은 TrueNAS의 두 번째 사본까지 확장되며, 아직 로드맵에 남아 있는 더 광범위한 3-2-1 백업 단계의 기반을 마련합니다.

ZimaOS가 쉽게 해 주는 것과 나머지를 측정하며 구축하기

Ted는 의도적으로 ZimaOS를 선택했습니다. Synology를 수년간 사용했고 CasaOS도 오랫동안 사용해 온 그는, 빌드에 더 고급 작업이 필요할 때에도 기본 시스템에 접근할 수 있으면서 더 깔끔한 Docker 중심 애플리케이션 모델을 원했습니다.

프로젝트의 여러 부분은 이러한 균형을 활용합니다. 기본 제공 AppData 마이그레이션 도구는 모든 앱을 다시 구축하지 않고 Docker 애플리케이션 데이터를 시스템 드라이브에서 Arctic-Storage로 옮겼습니다. Files 앱은 Immich 마이그레이션에 사용된 LAN 워크플로를 제공했습니다. 다음과 같은 기본 도구를 포함해 fio, zpool, zfs, nvme, 그리고 iostat 그래픽 계층 아래에서 스토리지 아키텍처를 측정하고 관리할 수 있게 했습니다.

다른 부분에서는 경험이 아직 덜 통합된 지점이 드러납니다. CLI로 생성한 ZFS 스토리지는 심볼릭 링크 우회 방법이 필요합니다. ARC 때문에 표준 RAM 수치를 쉽게 잘못 해석할 수 있습니다. Thunderbolt 동작으로 인해 하드웨어를 다시 설계해야 했습니다.

이러한 관찰 덕분에 이 프로젝트는 모든 실험이 첫 시도부터 성공하는 쇼케이스보다 더 가치 있습니다. Ted는 단순한 ZimaOS 경험과 누군가 그 경계를 넘기로 결정했을 때 시작되는 더 깊은 홈랩 작업 사이의 경계를 기록하고 있습니다.

이미 구축된 것과 아직 로드맵에 남아 있는 것

ted의 저장소 제목은 목적지를 AI 기반의 소박한 NAS로 설명하지만, 이 프로젝트는 의도적으로 여러 단계에 걸쳐 구축되고 있습니다.

기반은 이미 갖춰졌습니다. 계층형 스토리지가 실행 중입니다. glacier ZFS RAIDZ1 풀이 운영되고 있습니다. Arctic-Storage는 온보드 M.2 슬롯으로 이동했습니다. 메모리는 32GB 듀얼 채널로 확장되었습니다. IronWolf RAID5 풀이 존재합니다. 스토리지 벤치마크가 완료되었습니다. Immich 마이그레이션과 더 광범위한 iCloud 사진 통합이 완료되었습니다.

미디어 계층은 아직 확장 중입니다. IronWolf 풀은 대용량 미디어용으로 생성되었으며, Jellyfin과 더 광범위한 *arr 스택은 현재 Phase 2 작업의 일부로 남아 있습니다.

AI 계층은 아직 앞으로 남아 있습니다. Ted의 로드맵에서는 현재 CPU만 사용하는 Ollama 테스트를 4a단계에 배치하고, 이후 4b단계에서 RTX 4090 eGPU 경로를 진행하며, 5단계에서는 로컬 스토리지 전체에 대한 시맨틱 검색을 수행할 예정입니다.

이러한 구분은 중요합니다. ZimaCube 2는 스토리지 배치, 메모리 용량, PCIe 관련 결정, 워크로드 계획을 통해 이미 로컬 AI를 위한 준비를 진행하고 있지만, GPU 추론을 완료된 결과로 제시할 단계에는 아직 이르지 않았습니다.

지금 이러한 미래 방향을 살펴보는 독자를 위해, 당사의 ZimaCube 2 로컬 AI 가이드에서는 Ollama, 메모리, PCIe 확장, 향후 GPU 업그레이드가 유사한 홈랩 로드맵에 어떻게 포함될 수 있는지 살펴봅니다.

근거가 달라지면 바뀌는 구축

ted의 프로젝트에서 가장 일관되게 나타나는 패턴은 ZFS, Immich 또는 특정 하드웨어가 아닙니다. 실제로 어떤 일이 발생했는지 측정한 뒤 결정을 바꾸려는 태도입니다.

Thunderbolt 인클로저가 작동하지 않아 스토리지 경로를 OCuLink로 변경했습니다.

P510은 7번째 베이에서 잠재 성능을 발휘할 수 없었기 때문에 온보드 M.2 슬롯으로 이동했습니다.

ZFS ARC의 성능이 예상보다 우수했기 때문에 메모리는 단순히 용량을 늘리는 것이 아니라 성능을 향상하는 요소가 되었습니다.

134GiB 규모의 Immich 마이그레이션은 데이터베이스 손실 없이 완료되었고, 이에 따라 iCloud에서 수백 GB를 더 옮기는 실험으로 확장되었습니다.

각 단계에는 측정 결과, 명령어, 실수, 그리고 다음 단계에 대한 업데이트된 가정이 남습니다. 따라서 동일한 스토리지 구성을 그대로 구축하지 않는 사람에게도 이 저장소는 유용합니다.

이야기는 아직 쓰이는 중입니다

ted-knight와 Zima의 이야기는 아직 쓰이는 중입니다. ZimaCube 2는 8GB Standard 모델로 시작했지만, 이제 btrfs, ZFS RAIDZ1, OCuLink NVMe 확장, 32GB 듀얼 채널 메모리, IronWolf RAID5 아카이브, 수백 GB의 개인 미디어를 보관하는 셀프 호스팅 Immich 라이브러리를 갖춘 다중 계층 스토리지 시스템으로 발전했습니다.

다음 단계는 의도적으로 아직 열려 있습니다. Jellyfin과 미디어 스택, 더욱 강력한 백업 워크플로, CPU만 사용하는 로컬 AI, 향후 GPU 경로, 시맨틱 검색, 그리고 그 과정에서 실제 측정 결과에 따라 ted가 재고하게 될 모든 사항이 포함됩니다.

해당 단계들이 로드맵에서 실제 결과로 진행되는 과정을 확인하려면 GitHub에서 ted-knight의 진행 중인 ZimaCube 2 구축을 팔로우하세요.