2層ストレージ構成のPlexでは、遅延の影響を受けやすいデータベースとメタデータをSSDに置き、大容量のメディアファイルは容量重視のHDDストレージに保持します。
この分離は、アプリデータのパスを独立してバックアップし、メディアのスループットがすでにHDDアレイの性能内に収まっている場合に有効です。ナビゲーションやメンテナンスを改善するために、SSDが映画ライブラリ全体を保持する必要はありません。また、HDDが元ファイルを保存しているからといって、データベースまでHDDに置く必要もありません。2つの階層は別々の役割として扱い、それぞれに個別の復旧計画を用意してください。
データベースとメタデータを低遅延層に置く
検索、ブラウジング、アートワーク、データベースのメンテナンスでは、小さな読み書きが多数発生します。そのため、連続再生される映画ストリームよりも、シーク遅延の低減による恩恵が大きくなります。
通常、最も大きな改善が得られるのは、機械式ストレージから遅延の影響を受けやすいデータを移動した場合です。ここではSSDとHDDのランダムアクセス性能の違いが最も明確に表れます。
PlexのアプリデータをSSD層に配置し、ライブラリの起動、検索、メンテナンスにかかる遅延を測定します。データベースの増加と生成されるメタデータに備え、十分な空き容量を確保してください。
大容量メディアは容量重視のストレージに保持する
動画再生は基本的にシーケンシャル処理であり、総スループットと信頼性がワークロードを満たしていれば、HDDから配信できます。すべてのメディアをフラッシュストレージに移しても、ユーザー体験よりコストのほうが大きく変わることがよくあります。
階層化されたメディアサーバーのストレージ設計では、アプリ状態に必要な低遅延と、大容量メディアに必要な容量を分離し、それぞれのデバイスを実際に提供するワークロードに基づいて評価できます。
同時に発生するメディア読み取りのピークレートを測定し、現実的な断片化やバックグラウンド処理を考慮したHDDプールの性能と比較してください。メディアストレージのアップグレードは、その経路が実際にボトルネックになった場合にのみ行います。
2つの役割を異なる方法でバックアップする
Plexの状態データは比較的小容量ですが、完全に同じ状態へ再構築するのは困難です。一方、メディアは大容量で、異なるバックアップや冗長化戦略が必要になる場合があります。両方を同じように扱うと、高速ストレージを無駄にしたり、データベースの保護が不十分になったりする可能性があります。
容量と変更頻度を考慮して、各データセットの変更速度と再構築にかかるコストに見合ったバックアップを行う必要があります。
視聴履歴や設定の変更に対応できる頻度でアプリデータをバックアップし、メディアは交換コストと容量に応じて保護してください。アプリ状態のコピーは、少なくとも1つをSSDデバイスの外部に保管します。メディアセンターのストレージ役割を分離することで、SSDは遅延の影響を受けやすい状態データを保護し、HDDの容量は大容量メディアに集中させられます。
各階層の障害を個別に検証する
一方の階層を失ったときに、復旧不能なサーバーへ連鎖的に障害が広がるのではなく、想定どおりの障害になることを確認できて初めて、このアーキテクチャは有用になります。SSDとHDDの役割には、それぞれ個別のテストと復元手順が必要です。
管理された復元テストにより、交換後にコピーした状態データを想定したメディアパスへ再接続できることを確認できます。
Plexの状態データを使い捨て可能なSSDパスへ復元し、メディアの一部をテスト用に接続します。メディア層が一時的に利用できない場合のサーバーの動作を記録しておくと、次回の障害を分類しやすくなります。
NAS&サーバー設定
もっと読む

AIに似た分析と自動化がJellyfinのストレージおよびコンピューティング要件をどう変えるか
自動化と関連するAI分析では、通常のJellyfin再生に加えて、スキャン、派生データ、CPU/GPU処理、キャッシュ、作業用領域、バックグラウンドスケジューリングが追加されます。

小さなアパートや賃貸住宅のネットワークにJellyfinを統合する方法
安定したローカルアドレス、最小限の配線、静音ハードウェア、CGNATを考慮したリモートアクセス、そして元に戻せる変更を軸に、賃貸住宅に適したJellyfinネットワークを構築しましょう。

1台のJellyfinホストでサポートできるユーザー数とバックグラウンドジョブ数はどれくらいですか?
Jellyfinユーザーとバックグラウンドジョブを1つの共有ワークロード予算として扱い、再生遅延、キュー、またはリソース圧迫が繰り返し発生した時点で容量の限界とします。

