SSDにメタデータ、HDDにデータを保存するデュアルストレージ構成のJellyfin環境

強力なデュアルストレージのJellyfin構成では、遅延の影響を受けやすいアプリケーションの状態やアクティブなメタデータをSSDに置き、大容量のメディアファイルは容量効率に優れたHDDストレージに保持します。

重要なのは、Jellyfinのすべてのファイルに最速のデバイスが必要ということではありません。データベース、アートワークのインデックス、サムネイル、キャッシュでは小さな検索が多数発生します。一方、映画や音楽は主に大きなシーケンシャル読み取りで処理され、トランスコード用の一時領域は一時的なもので、書き込み負荷が高くなる場合があります。各役割に対して、ワークフローに合った遅延、容量、耐久性、バックアップ、復旧特性を持つストレージ階層を割り当て、スキャンや再生中に全体の構成をテストしてください。

SSDとHDDに異なる役割を割り当てる

SSDには、オペレーティングシステムまたはコンテナのアプリデータ、Jellyfinのデータベース、設定、アクティブなメタデータ、インデックス、キャッシュを配置します。映画、エピソード、音楽、ホームビデオの大容量ファイルは、HDDプールに保持してください。トランスコード用ストレージは別途判断します。容量と耐久性に余裕があればSSDを使えますが、同時トランスコードによる書き込みが大きくなる場合は、別の高速な一時領域を使う方法もあります。

実用的なホームラボ向けSSDワークロードガイドでも同じ役割分担が示されています。データベースやアクティブなアプリケーションは低遅延のフラッシュストレージの恩恵を受けますが、高速なストレージが存在するからといって、容量階層にNVMeクラスの性能が必要になるわけではありません。

単にフォルダー名だけで分けないでください。一部の「メタデータ」は正式なデータや手動で整理したデータであり、バックアップする価値がありますが、画像キャッシュは再生成できます。障害後にSSDのどの内容を復元する必要があり、どの内容をメディアから再構築できるかを把握しておくと、構成を復旧可能な状態にできます。

ランダムアクセスの多いアプリケーション状態をSSDに置く

Jellyfinのブラウジング、検索、ユーザー状態の更新、アートワークの検索、データベーストランザクション、多くのライブラリ操作は、映画のシーケンシャル読み取りに比べて遅延の影響を受けやすい処理です。このアプリデータのワーキングセットをHDDからSSDに移すと、機械式ドライブのシークコストをなくし、小さなメタデータI/Oと大容量メディアの読み取りが互いに干渉するのを抑えられます。

最新のJellyfinパフォーマンスガイドでは、アプリデータで小さな読み取りが多数発生するため、遅いメタデータストレージがライブラリ閲覧の動作遅延を直接引き起こす原因として挙げられています。ZimaSpaceのSSDとHDDにおけるJellyfinの違いに関する分析でも同じ役割分担に至っています。アプリケーション状態の遅延にはSSDが有効ですが、大容量メディアはHDDに置いたままで構いません。

SSDの容量はメディア容量ではなく、実際のアプリケーション状態の増加量に余裕を加えて決めてください。データベースの増加、メタデータ、トリックプレイやアートワークを有効にした場合のデータ、外部へエクスポートする前にローカルで作成するバックアップ、意図的に配置する最大の一時処理に備えて、空き容量を残します。容量が小さく満杯に近いSSDより、適度な空き容量を安定して確保できる大きめのSSDの方が優れています。

別の要件がない限り、大容量メディアはHDDに保持する

映画のストリームは通常、正常な最新ディスクのスループットを大きく下回るビットレートの、持続的なシーケンシャル読み取りです。そのため、メディアファイル自体については、SSDのインターフェース速度が重要になるよりも前に、容量あたりの価格、ドライブベイ、冗長性、バックアップが判断を左右することが多くあります。

最近のJellyfin NAS運用者は、SSDからはすばやく閲覧できる一方、再生時にスリープ中のハードドライブを起動する必要があると15～20秒待たされる、コンテナをSSD、メディアをHDDに配置する構成を紹介しています。これは実際のトレードオフが持続帯域幅ではなく、最初の読み取り時の遅延と電源管理の動作にあることを示しています。

すぐに再生を開始できることがスピンダウンによる節電より重要なら、通常の視聴時間帯はメディアディスクを起動状態に保つか、電源ポリシーを調整してください。静かで低消費電力の動作を優先するなら、最初の再生時に起動待ちが発生することを受け入れます。1回のスピンアップ待ちを避けるためだけにすべてのメディアをSSDへ移すのは、通常、Jellyfinの要件ではなく容量コストに関する判断です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

小容量だが重要な復旧単位としてSSDを保護する

SSDにはHDDプールよりはるかに少ないデータしか入っていない場合でも、サーバーを同じJellyfinインスタンスとして動作させる状態が保存されています。アプリデータ用SSDが故障すると、映画がすべて無事でも、ユーザー、視聴履歴、設定、プレイリスト、整理したメタデータが失われる可能性があります。この小さな復旧単位を頻繁に、かつSSDの障害ドメイン外へバックアップしてください。

デュアル階層構成は、SSD上のアプリケーション状態に独自の復元経路を用意している場合に最も効果を発揮します。復元テストのワークフローでは、コピーしたファイルを証拠とみなすのではなく、隔離した環境でアプリケーションを検証することが重視されています。サーバー固有の状態はバージョン管理されたSSDバックアップとして保持し、移行や再構築に役立つ場合に限って、選択したメディアのサイドカー情報を保存します。

バックアップを避けるためだけにSSDをミラーリングしないでください。冗長化によって1台のデバイス故障後のダウンタイムは短縮できますが、アップグレードの失敗、誤削除、データベースの破損、ホストの喪失から復旧できるわけではありません。バージョン管理された復旧ポイントを保持し、隔離したJellyfinインスタンスへ1度復元するテストを行ってください。

混在I/Oのジョブによってストレージ分離を無効にしない

この構成は、アプリケーション状態のI/OをSSDに、大容量メディアの転送をHDDに維持したときに最も有効です。バックアップ、ダウンロード、展開、メディア解析、トランスコードの書き込みをすべて同じデバイスに同時に行うと、その分離が崩れる可能性があります。繰り返し実行する各ジョブの書き込み先を決め、必要に応じて、視聴が最も集中する時間帯を避けて負荷の高い処理をスケジュールしてください。

デュアルストレージのホームラボでは、ストレージキューが顕在化するような混在ランダムI/Oワークロードと同じ種類の負荷でテストする必要があります。ベンチマークの正確な数値はJellyfinにはそのまま当てはまりませんが、仕組みは同じです。同時に発生する小さなデータベース操作は、長いシーケンシャルなメディア読み取りとは遅延に対する反応が大きく異なります。

通常の処理が重なる状況で、ダッシュボードの読み込み、検索、再生開始、スキャン時間、HDDのキュー、SSDの遅延を測定してください。閲覧は高速なままで、再生時だけスリープ中のディスクを待つなら、その構成は意図どおりに機能しています。バックアップやインポート中に両方の階層が遅くなるなら、より高速なフラッシュストレージを購入する前に、共有コントローラー、ネットワーク、またはスケジュールのボトルネックを解消してください。

実際に限界へ達している階層を拡張する

Jellyfinのアプリケーション状態、メタデータ、または一時領域が空き容量のしきい値に近づいた場合、あるいは同じ低遅延階層を別の同居データベースが必要とする場合は、SSDの容量を追加します。メディアの保存量がプールの上限に達した場合は、HDDの容量を追加します。分離されたメディア経路が測定上のボトルネックになった場合に限り、ネットワークをアップグレードしてください。

最近のメディアサーバーのストレージ階層ガイドでも、同じワークロードの違いが示されています。SSDの容量は遅延の影響を受けやすいサーバーデータに使い、HDDの容量は大規模なメディアライブラリに使うべきです。実際に測定した容量または遅延の限界に達している階層を拡張してください。

SSDが復旧用の余裕を残してアクティブなアプリケーションのワーキングセットを保持し、HDDプールが通常のメディア需要を処理でき、両方の役割を適切にバックアップし、通常想定される最悪の重複処理でも遅延目標を満たせるなら、そこで止めます。デュアルストレージ構成の成功とは、利用可能なすべてのコネクターにドライブを接続することではなく、各階層に明確な役割を1つずつ持たせることです。