Jellyfinに専用のデータベースまたはストレージホストを使うべきなのはどんなときですか？

多くのJellyfin家庭環境では、データベースホストより先にメディアストレージのホストを分けましょう。本番アプリケーションの状態は低遅延のローカルSSDに置き、容量、復旧、設置場所の要件に応じて大容量メディアを分離します。

これはマシンの台数ではなく、データの役割に関する判断です。Jellyfinには、遅延に敏感な設定やデータベースの状態、再生成可能なキャッシュ、一時的なトランスコードデータ、大容量で主にシーケンシャルにアクセスされるメディアファイルがあります。これらのデータは、ストレージ、バックアップ、障害の境界をそれぞれ別にすることで利点が得られます。2台目のホストが役立つのは、ある役割の容量や復旧に明確な利点をもたらし、従来はローカルにあった依存先を不安定なネットワーク経由に変えずに済む場合に限られます。

マシンを分ける前に、データの役割を分ける

まず、データの役割を4つに分けましょう。正となるアプリケーションの状態、再生成可能な派生データ、一時作業領域、メディアです。データベース、ユーザー情報、視聴状況、プレイリスト、設定、選択したメタデータは、復旧単位に含まれます。キャッシュやトランスコードのデータは、通常は再生成できます。映画や音楽のファイルはサイズの大きな元データであり、その保護方針はアプリケーションのデータベースとはまったく異なる場合があります。

最新のJellyfinデータベースのメンテナンスガイドでは、統合された10.11のデータベースを、破棄してよいキャッシュではなく、運用中の状態として説明しています。そのため、ホストの配置は所有権と復旧要件の確認から始めるべきです。「Jellyfin」という名前のディレクトリをすべて同じ共有ストレージに置くことから始めてはいけません。

ホストを決める前に、まず役割を整理しましょう。現在のサーバーに、アプリケーションの状態を保存する十分なSSD容量とバックアップ体制があるなら、別の場所に移すことにアーキテクチャ上の利点はありません。メディアライブラリがローカルのドライブベイ、電力、冷却能力、または障害分離の限界を超えているなら、アプリケーションはローカルに残したまま、メディアの役割をNASやストレージサーバーに移す明確な理由があります。

外部データベースの利用経路が正式にサポートされていない限り、本番データベースはローカルに置く

Jellyfin 10.11では大規模なEF Coreへの移行が完了しましたが、だからといって、独立したPostgreSQLサーバーが本番環境の標準構成になるわけではありません。実験的なPostgreSQLアダプターは存在しますが、別のサービス、認証情報、バージョン互換性、バックアップの順序、ネットワークへの依存が追加されます。一般的な家庭環境では、こうしたコストは専用データベースホストの理論上の整然さを上回ります。

実験版のPostgreSQLリリース自体が、このアダプターは評価用であり、本番環境向けではないと警告しています。この実験的なデータベースの境界は、立ち止まるべきサインです。構成をよりエンタープライズらしく見せるためだけに、サポート対象外のバックエンドを家庭内の復旧計画の前提にしてはいけません。

本番環境では、ローカル保存だからといって無保護でよいわけではありません。アプリケーションの状態を信頼性の高いSSDストレージに置き、別の障害ドメインにバックアップし、同じバージョンのJellyfinで復元できることを確認しましょう。データベースサービスを分離するのは、選んだバックエンドが使用中のリリースでサポートされており、独立して運用でき、復旧上のメリットが新たなネットワーク依存やバージョン間の連携を上回る場合に限りましょう。

容量やドライブ構成上の必要性に応じて、メディアを別のストレージホストに移す

大容量メディアは、アクセスのパターンが異なります。Direct Playでは主に、大きなファイルを再生時のビットレートでシーケンシャルに読み取るため、ネットワーク、マウント、ディスクが合計ストリーム分の速度を維持できれば、NASでメディアを快適に配信できます。メディアを分離すれば、コンピュートノードをコンパクトに保ちながら、ストレージホスト側で大容量のプールやベイの追加、または異なるバックアップ設計に対応できます。

最近の家庭用環境では、JellyfinのDockerデータをSSDに、メディアをHDDに保存しており、実用的なSSDにアプリ、HDDにメディアを置く構成を示しています。再生開始時には、トレードオフがはっきり表れます。アプリのデータがSSD上にあるため閲覧は速いままですが、スリープ中のHDDは起動待ち時間を増やすことがあります。

ドライブの拡張、設置場所の音響環境、冗長性、または複数サービスのストレージを考慮すると、別のストレージホストを使うメリットがある場合に選びましょう。1台の筐体で容量とバックアップの要件を満たせるなら、メディアはローカルに保管しましょう。目的もなく分割すると、ユーザー体験は実質的に変わらないまま、DNS、マウント、権限、ネットワーク障害、起動順序への対応が増えます。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

ストレージネットワークを、見えないケーブルではなく必須の依存要素として扱う

メディアを別のホストに移すと、Jellyfinはスキャンや通常の動作を始める前にマウントが存在することに依存します。NASが見つからない場合、空のマウントポイントが有効なディレクトリのように見えることがあり、ネットワークが遅かったり不安定だったりすると、ストレージの問題が再生の遅延につながることもあります。そのため、構成にはフェイルクローズの起動ルールと、測定可能な帯域幅の目標が必要です。

コミュニティの事例によると、適切なネットワーク容量を確保すれば、通常の家庭内ネットワーク経由で別のNASからメディアを配信しても問題なく動作します。最近のある議論では、多くのユーザーがまさにこの構成を利用し、再生の問題も起きていませんでした。NASを分離したメディアストレージから得られる大切な教訓は、ネットワーク経由での接続は有効な選択肢である一方、追加コストがないものと考えず、メディア配信経路の一部として扱うべきだということです。

最も遅い区間を検証しましょう。ストレージプール、NASのNIC、スイッチ、サーバーのNIC、マウントプロトコル、同時ストリーム数の要件を確認します。想定されたメディアのマウント先がない場合は、Jellyfinを停止するか、ライブラリへの破壊的なメンテナンスを一時停止しましょう。2台目のホストが信頼性の向上につながるのは、その障害が明確に分かり、影響範囲が限定される場合だけです。障害がひそかに空のライブラリへと変わってしまう構成では、信頼性は向上しません。

分離を判断するための復旧・拡張テスト

ホストを追加する前に、Jellyfinのコンピュートノードが失われた場合と、メディアストレージノードが失われた場合の2つの事態を想定して復旧をリハーサルしましょう。テスト済みの復元優先の復旧ワークフローから、設定、永続データ、バージョン管理されたサービス定義、復元順序は、バックアップファイルがあるからといって復旧できると思い込まず、セットで検証する必要があることが分かります。ストレージホストのテストでも、正本となるメディアデータを書き換えたり削除したりせず、Jellyfinが予測どおりに機能低下することを確認しましょう。

ZimaSpaceのJellyfinストレージ復旧監査でも、同じ所有権の確認を行います。インシデントが発生する前に、すべての永続パスについて、明確な役割、バックアップ範囲、復元方法を定めておく必要があります。

アプリの状態、メディア容量、バックアップ、通常時のピークI/Oがすべて十分に収まるなら、ホストは1台にまとめましょう。容量やストレージのライフサイクルが制約になったら、メディアストレージを分離します。データベースプロバイダーが本番環境でサポートされ、個別に復旧できるようになるまでは、データベース専用ホストは高度な例外として扱いましょう。目指すべきは、役割を明確に説明でき、復元できる構成です。追加できる箱の数を最大化することではありません。