SSD 메타데이터와 HDD 데이터를 사용하는 듀얼 스토리지 Jellyfin 설정

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

A Dual-Storage Jellyfin Setup With SSD Metadata and HDD Data - Zima Store Online

강력한 이중 스토리지 Jellyfin 구성에서는 지연 시간에 민감한 애플리케이션 상태와 활성 메타데이터를 SSD에 저장하고, 대용량 미디어 파일은 용량 효율적인 HDD 스토리지에 보관합니다.

모든 Jellyfin 파일에 가장 빠른 장치가 필요하다는 뜻은 아닙니다. 데이터베이스, 아트워크 인덱스, 썸네일, 캐시는 작은 조회를 많이 발생시키고, 영화와 음악은 주로 대규모 순차 읽기를 수행하며, 트랜스코딩 임시 공간은 일시적이고 쓰기 작업이 많을 수 있습니다. 각 역할에 지연 시간, 용량, 내구성, 백업 및 복구 방식이 작업 흐름에 맞는 스토리지 계층을 배정한 다음, 스캔과 재생 중 전체 구성을 테스트하세요.

SSD와 HDD에 서로 다른 역할 부여하기

운영 체제 또는 컨테이너 앱 데이터, Jellyfin 데이터베이스, 구성 파일, 활성 메타데이터, 인덱스, 캐시는 SSD에 저장하세요. 영화, 에피소드, 음악, 홈 비디오 같은 대용량 파일은 HDD 풀에 보관합니다. 트랜스코딩 저장 공간은 별도로 결정하세요. 여유 공간과 내구성이 충분하다면 SSD를 사용할 수 있고, 동시 트랜스코딩으로 쓰기 작업이 많아진다면 다른 고속 임시 저장 경로를 사용할 수도 있습니다.

실용적인 홈랩 SSD 워크로드 가이드도 같은 역할 구분을 제시합니다. 데이터베이스와 활성 애플리케이션은 지연 시간이 낮은 플래시 스토리지의 이점을 얻지만, 더 빠른 스토리지가 존재한다는 이유만으로 용량 계층에 NVMe급 성능이 필요한 것은 아닙니다.

단순히 폴더 이름만으로 구분하지 마세요. 일부 “메타데이터”는 원본 데이터이거나 수동으로 관리한 정보이므로 백업할 가치가 있지만, 이미지 캐시는 다시 생성할 수 있습니다. 어떤 SSD 콘텐츠를 장애 후 반드시 복원해야 하고 어떤 콘텐츠를 미디어에서 다시 구축할 수 있는지 알고 있어야 복구 가능한 구성이 됩니다.

무작위 접근이 많은 앱 상태는 SSD에 저장하기

Jellyfin의 탐색, 검색, 사용자 상태 업데이트, 아트워크 조회, 데이터베이스 트랜잭션, 다양한 라이브러리 작업은 순차적인 영화 읽기에 비해 지연 시간에 민감합니다. 이러한 앱 데이터 작업 세트를 HDD에서 SSD로 옮기면 기계식 탐색 비용이 줄고, 작은 메타데이터 I/O와 대용량 미디어 읽기 간 간섭도 감소합니다.

최신 Jellyfin 성능 가이드는 느린 메타데이터 스토리지를 앱 데이터가 작은 읽기를 많이 수행하기 때문에 라이브러리 탐색이 느려지는 직접적인 원인으로 지목합니다. ZimaSpace의 SSD와 HDD의 Jellyfin 비교 분석도 같은 역할 분리를 보여 줍니다. 앱 상태는 SSD의 낮은 지연 시간으로 이점을 얻고, 대용량 미디어는 HDD에 그대로 둘 수 있습니다.

SSD 용량은 미디어 용량이 아니라 실제 앱 상태 증가량과 여유 공간을 기준으로 정하세요. 데이터베이스 증가, 활성화한 경우 메타데이터·트릭플레이·아트워크, 외부로 내보내기 전에 로컬에 생성하는 백업, 그리고 의도적으로 그곳에 배치한 가장 큰 임시 작업을 위한 여유 공간을 남겨 두세요. 여유 공간이 거의 없는 작은 SSD보다, 안정적인 여유 공간을 확보한 조금 더 큰 SSD가 낫습니다.

다른 요구 사항이 없다면 대용량 미디어는 HDD에 보관하기

HDD는 여전히 합리적인 미디어 계층입니다. 영화 스트리밍은 대개 정상적인 최신 디스크 처리량보다 훨씬 낮은 비트레이트로 지속적인 순차 읽기를 수행하기 때문입니다. 미디어 파일 자체에서는 SSD 인터페이스 속도가 중요해지기 훨씬 전에 달러당 용량, 드라이브 베이, 이중화, 백업이 더 중요한 요소가 되는 경우가 많습니다.

최근 한 Jellyfin NAS 운영자는 SSD 컨테이너와 HDD 미디어 구성에서 SSD를 사용하면 탐색은 빠르지만, 절전 중인 하드 드라이브가 재생을 위해 깨어나는 데 15~20초가 걸린다고 설명합니다. 이는 실제 트레이드오프가 지속 대역폭이 아니라 첫 읽기 지연 시간과 전원 관리 동작에 있음을 보여 줍니다.

스핀다운 절약보다 즉시 재생 시작이 중요하다면 일반적인 시청 시간 동안 미디어 디스크를 깨워 두거나 전원 정책을 조정하세요. 조용하고 저전력으로 작동하는 것이 더 중요하다면 처음 재생할 때 발생하는 깨우기 지연을 받아들이면 됩니다. 스핀업 대기 한 번을 피하기 위해 모든 미디어를 SSD로 옮기는 것은 대개 Jellyfin의 요구 사항이 아니라 용량 비용에 관한 결정입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

작지만 중요한 복구 단위인 SSD 보호하기

SSD에는 HDD 풀보다 훨씬 적은 데이터가 들어 있을 수 있지만, 서버가 동일한 Jellyfin 인스턴스처럼 작동하게 만드는 상태가 저장되어 있습니다. 앱 데이터 SSD가 고장 나면 모든 영화가 그대로 남아 있어도 사용자, 시청 기록, 구성, 재생 목록, 직접 관리한 메타데이터를 잃을 수 있습니다. 이 작은 복구 단위를 자주 백업하고 SSD의 장애 도메인 외부에 보관하세요.

이중 계층 구성은 SSD에 저장된 애플리케이션 상태에 자체적으로 검증된 복원 경로가 있을 때 가장 효과적입니다. 복원 테스트 작업 흐름은 복사한 파일을 증거로 간주하지 말고 격리된 대상에서 애플리케이션을 검증해야 한다고 강조합니다. 서버별 상태를 버전 관리되는 SSD 백업으로 보존하고, 마이그레이션이나 재구축에 도움이 될 때만 선택한 미디어 사이드카 파일을 유지하세요.

단순히 백업을 피하려고 SSD를 미러링하지 마세요. 이중화는 장치 하나가 고장 났을 때 다운타임을 줄일 수 있지만, 잘못된 업그레이드, 실수로 인한 삭제, 데이터베이스 손상, 호스트 손실을 복구해 주지는 않습니다. 버전이 관리되는 복구 지점을 유지하고, 격리된 Jellyfin 인스턴스로 복원하는 테스트를 한 번 수행하세요.

혼합 I/O 작업이 스토리지 분리를 무력화하지 않게 하기

앱 상태 I/O는 SSD에 두고 대용량 미디어 전송은 HDD에 둘 때 이 구성이 가장 유용합니다. 백업, 다운로드, 압축 해제, 미디어 분석, 트랜스코딩 쓰기 작업이 동시에 하나의 장치를 대상으로 하면 이러한 분리가 무너질 수 있습니다. 반복적으로 실행되는 각 작업이 어디에 쓰는지 결정하고, 필요하다면 시청량이 가장 많은 시간대를 피해 무거운 작업을 예약하세요.

이중 스토리지를 사용하는 홈랩은 스토리지 큐가 드러나는 것과 같은 종류의 혼합 무작위 I/O 워크로드에서 테스트해야 합니다. 정확한 벤치마크 수치가 Jellyfin에 그대로 적용되지는 않지만 작동 원리는 같습니다. 동시에 발생하는 작은 데이터베이스 작업은 긴 순차 미디어 읽기와 지연 시간에 매우 다르게 반응합니다.

한 번의 일반적인 동시 작업 상황에서 대시보드 로드, 검색, 재생 시작, 스캔 시간, HDD 대기열, SSD 지연 시간을 측정하세요. 탐색은 빠르지만 재생이 절전 디스크에서 깨어나는 동안에만 지연된다면 구성이 의도대로 작동하는 것입니다. 백업이나 가져오기 중 두 계층 모두 느려진다면 더 빠른 플래시를 구매하기 전에 공유 컨트롤러, 네트워크 또는 작업 예약 병목을 해결하세요.

실제로 한계에 도달한 계층을 확장하기

Jellyfin 앱 상태, 메타데이터 또는 임시 공간이 여유 공간 기준에 가까워지거나, 함께 호스팅하는 다른 데이터베이스에 동일한 저지연 계층이 필요할 때 SSD 용량을 추가하세요. 미디어 보관량이 풀의 한도에 도달하면 HDD 용량을 추가합니다. 분리된 미디어 경로가 측정 결과 병목으로 나타날 때만 네트워크를 업그레이드하세요.

최근 미디어 서버 스토리지 계층 가이드도 같은 워크로드 구분을 제시합니다. SSD 용량은 지연 시간에 민감한 서버 데이터를 담당하고, HDD 용량은 대규모 미디어 라이브러리를 담당해야 합니다. 실제 용량 또는 지연 시간 한계에 도달한 계층을 확장하세요.

SSD가 복구를 위한 여유 공간과 함께 활성 앱 작업 세트를 수용하고, HDD 풀이 일반적인 미디어 수요를 처리하며, 백업이 두 역할을 적절히 보호하고, 정상적인 최악의 동시 작업도 목표 지연 시간 안에 들어오면 멈추세요. 이중 스토리지 구성의 성공 기준은 사용 가능한 모든 커넥터에 드라이브를 연결하는 것이 아니라 각 계층에 하나의 명확한 역할을 부여하는 것입니다.