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

SSDとHDDを組み合わせたJellyfinの優れた構成では、レイテンシーの影響を受けやすいアプリの状態データと使用中のメタデータをSSDに保存し、大容量のメディアファイルは容量効率に優れたHDDストレージに保管します。

Jellyfinのファイルをすべて最速のデバイスに保存する必要はありません。データベース、アートワークのインデックス、サムネイル、キャッシュでは小さな検索が頻繁に発生します。映画や音楽は主に大容量の連続読み込みで、トランスコード用の作業領域は一時的なもので、書き込みが集中することもあります。それぞれの用途に合わせて、レイテンシー、容量、耐久性、バックアップ、復旧方法に適したストレージ層を選び、スキャンと再生を同時に行って構成をテストしてください。

SSDとHDDで役割を分ける

SSDには、オペレーティングシステムやコンテナのアプリデータ、Jellyfinのデータベース、設定、使用中のメタデータ、インデックス、キャッシュを保存します。映画、エピソード、音楽、ホームビデオなどの大容量ファイルはHDDプールに保管します。トランスコード用ストレージは別途検討してください。容量と耐久性に余裕があればSSDを使用できます。複数のトランスコード処理で書き込みが増える場合は、別の高速な作業用ストレージを使うこともできます。

実用的なホームラボ向けのSSDのワークロードガイドでも、同じように役割を分けています。データベースや実行中のアプリケーションには低レイテンシーのフラッシュストレージが適しています。一方、より高速なストレージがあるからといって、大容量データ用のストレージにNVMeクラスの性能が必要とは限りません。

フォルダー名だけで保存先を分けないでください。一部の「メタデータ」は信頼できる唯一のデータや手動で整理したデータであり、バックアップする価値があります。一方、画像キャッシュは再生成できます。故障後にSSDの内容のうち何を復元し、何をメディアから再構築できるか把握しておけば、復旧可能な構成にできます。

ランダムアクセスが発生するアプリの状態データをSSDに保存する

Jellyfinでの閲覧、検索、ユーザー状態の更新、アートワークの検索、データベースのトランザクション、その他の多くのライブラリ操作は、映画の連続読み込みに比べてレイテンシーの影響を受けやすい処理です。アプリデータのワーキングセットをHDDからSSDに移すことで、機械的なシークのコストをなくし、メタデータの細かなI/Oと大容量メディアの読み込みとの干渉を抑えられます。

最新のJellyfinパフォーマンスガイドでは、メタデータの保存先が遅いことが、ライブラリの閲覧を遅くする直接的な原因として挙げられています。アプリデータは小さな読み込みを頻繁に行うためです。ZimaSpaceのJellyfinにおけるSSDとHDDの比較分析も同じ役割分担を示しています。アプリの状態データにはSSDが適していますが、大容量のメディアはHDDに保存できます。

SSDの容量はメディア容量ではなく、実際のアプリケーションデータの増加量と余裕分をもとに決めてください。データベースの増大、必要に応じて有効化するメタデータ、トリックプレイ用データやアートワーク、エクスポート前にローカルで作成するバックアップ、意図的に配置する最大規模の一時的な処理に備えて、空き容量を確保しましょう。空き容量に余裕のない小容量SSDより、安定した空き容量を保てる少し大きめのSSDのほうが適しています。

別の要件で判断が変わらない限り、大容量のメディアはHDDに保存する

HDDはメディア用ストレージとして今も合理的な選択肢です。映画のストリーミングは通常、持続的なシーケンシャル読み取りであり、そのビットレートは正常な最新ディスクの転送速度を大きく下回るからです。メディアファイル自体にSSDのインターフェース速度が重要になる前に、容量あたりの価格、ドライブベイ数、冗長性、バックアップが判断を左右することがほとんどです。

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

スピンダウンによる省電力よりもすぐに再生できることを優先するなら、通常の視聴時間帯はメディアディスクを起動状態に保つか、電源管理ポリシーを調整してください。静音性と低消費電力を優先するなら、最初の再生時に起動待ちが発生することを受け入れましょう。起動時の一時停止を避けるためだけにすべてのメディアを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インスタンスへの復元をテストしましょう。

混合I/Oジョブでストレージの分離を台無しにしない

アプリ状態のI/OをSSDに、大容量メディアの転送をHDDに置くと、この構成のメリットを最も活かせます。バックアップ、ダウンロード、展開処理、メディア分析、トランスコードの書き込みがすべて同時に1台のデバイスを対象にすると、この分離が崩れる場合があります。定期的に実行する各ジョブの書き込み先を決め、必要に応じて、負荷の高い処理は視聴が最も多い時間帯を避けてスケジュールしましょう。

デュアルストレージのホームラボでは、ストレージキューが顕在化する混合ランダムI/Oワークロードと同種の負荷でテストしましょう。ベンチマークの具体的な数値をJellyfinにそのまま当てはめることはできませんが、その仕組みは参考になります。同時に発生する小規模なデータベース処理と、長いシーケンシャルメディア読み込みでは、レイテンシへの反応が大きく異なります。

通常の負荷が重なる状況で、ダッシュボードの読み込み、検索、再生開始、スキャン時間、HDDのキュー、SSDのレイテンシを測定しましょう。ブラウジングが高速なままで、再生時にスリープ中のディスクだけが待ち時間の原因なら、構成は設計どおりに機能しています。バックアップやインポート中に両方の階層が遅くなるなら、高速なフラッシュストレージを買う前に、共有コントローラー、ネットワーク、またはスケジュール設定のボトルネックを解消しましょう。

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

Jellyfinのアプリ状態、メタデータ、またはスクラッチ領域が空き容量のしきい値に近づいたときや、同居する別のデータベースにも同じ低レイテンシ階層が必要なときは、SSDの容量を増やしましょう。メディアの保存量がプールの上限に達したときは、HDDの容量を増やします。分離したメディア経路が実測上のボトルネックになった場合にのみ、ネットワークをアップグレードしてください。

最近のメディアサーバー向けストレージ階層ガイドでも、同じワークロードの違いが示されています。SSDの容量はレイテンシに敏感なサーバーデータに、HDDの容量は大規模なメディアライブラリに使います。実測した容量またはレイテンシの限界に達している階層を拡張しましょう。

SSDがアクティブなアプリのワーキングセットと復旧用の余裕を確保し、HDDプールが通常のメディア需要に対応でき、バックアップが両方の役割を適切にカバーし、通常発生する最悪の重複負荷でもレイテンシ目標内に収まる状態になったら、そこで止めましょう。デュアルストレージ構成の成功とは、利用可能なコネクターすべてにドライブを接続することではなく、各層の役割が明確に分かれていることです。