演算、ストレージ、バックアップに対応するJellyfinホームサーバーの完全なトポロジー

Jellyfinの完全なトポロジーでは、コンピュート、アクティブなアプリケーションデータ、大容量メディア、バックアップを分離しつつ、再生経路をできるだけ短く、検証しやすい状態に保ちます。

トポロジーは1台の筐体にも複数のマシンにも構築できます。重要なのは筐体の数ではなく、役割の違いです。コンピュートはクライアントに配信し、トランスコードを行う場合もあります。アプリ用ストレージには遅延の影響を受けやすいJellyfinの状態を保存し、メディアストレージは大容量ファイルを提供し、バックアップは障害時に保護すべきデータを守ります。共有構成で実測できる競合が生じた場合にのみ役割を分けましょう。ホストやネットワーク経由の転送が増えるたびに、新たな依存関係が加わるためです。

保存先を決める前に、4つのデータの役割を定義する

データを4つの役割に分類します。ソースメディア、Jellyfinの永続状態、再構築可能な作業データ、バックアップコピーです。ソースメディアは大容量を必要とします。永続状態にはデータベースとユーザー／サーバー設定が含まれます。作業データにはキャッシュとトランスコード出力が含まれます。バックアップは、ほかの役割のデータを復旧するためだけに存在します。

この分類により、「ストレージ」を区別のない単一のプールとして扱う、よくあるトポロジー上の誤りを防げます。大容量のHDDアレイは動画ファイルの保存には最適でも、頻繁にアクセスされるメタデータデータベースの保存先には向かないことがあります。一方、高速なSSDはアプリデータに便利ですが、大規模なコールドライブラリには高価で、必要もありません。

ZimaSpaceのメタデータ配置ガイドでも、同じように役割を分けています。アクティブなデータベースとキャッシュは高速ストレージに置き、移行のしやすさを考慮して、どのポータブルなサイドカーファイルやアートワークをメディアと一緒に置くかは別途決めます。

再生の主要経路はシンプルに保つ

重要な経路は、クライアント → ネットワーク → Jellyfinのコンピュートノード → メディアソースです。コンピュートとメディアが同じマシンにあれば、メディアへの転送はローカルで完結します。別々のマシンにある場合、コンピュートノードは、クライアントに結果を送る前に、配信またはトランスコードするすべてのデータをネットワーク経由で読み込む必要があります。

コンピュートとストレージを分離する設計では、ノード間リンクの帯域は最終的なクライアント向けビットレートだけでなく、ソースの総トラフィックを基準に決めましょう。トランスコードでは、ストレージから高ビットレートのソースを読み込みながら、クライアントには低ビットレートの出力を送ることがあります。そのため、ストレージリンクとクライアントリンクの役割は異なります。

管理、実験的な作業、オプションのサービスが再生経路に負荷をかける場合は、そこから切り離してください。2つ目の VLAN、独立したコンテナネットワーク、またはバックアップの時間帯を設定するだけで十分な場合もあります。ネットワークを物理的にもう1つ構築するのは、共有経路によってサービスの品質が実際に低下している場合に限られます。

メディアエンジンとサービスの分離を検証しやすい場所に処理能力を配置

実際に行う再生処理に合わせてコンピューティング性能を選びましょう。Direct Play では動画処理の負荷は小さい一方、クライアントとの互換性の問題、字幕の映像への焼き込み、HDR 変換、リモート再生時のビットレート制限などがあると、トランスコードが主な処理になる場合があります。

Jellyfin のハードウェア選定ガイドでは、ソフトウェアによる動画トランスコードは非常に高負荷になる場合があるため、新しいサーバーには最新のハードウェアアクセラレーションを推奨しています。また、CPU の役割と GPU のメディアエンジンの役割も区別しており、サーバーを CPU コア数だけで評価するよりも実用的です。

Jellyfin を写真のインデックス作成、バックアップ、ホームオートメーション、AI ワークロードと同じホストで動かす場合は、メディアサービスに明確な CPU、メモリ、デバイスアクセスの境界を設けてください。ZimaCube 2のような、より大規模なオールインワンノードで統合型トポロジーを構成できますが、1 台の筐体を単一の障害ドメインとみなすのではなく、アプリデータ、メディア、バックアップの役割を分ける必要があります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

Jellyfin のアクティブな状態データには SSD、ライブラリには大容量メディアストレージを使用

Jellyfin のデータベース、インデックス、キャッシュなど、頻繁にアクセスする状態データは、SSD または同等の低レイテンシストレージに配置してください。大容量の動画ライブラリは、HDD、NAS プール、または必要なシーケンシャル読み込み速度を維持できる別の媒体に保存してください。

Jellyfin は、これらのワークロードを明確に区別しています。ストレージに関するガイダンスによると、メディアファイルでは主にビットレートを上回るシーケンシャルスループットが必要ですが、Jellyfin 自体のファイルはランダムアクセスが多いため、SSD に配置するのが適しています。

ライブラリがリモートにある場合は、予測可能な方法でマウントし、Jellyfinサービスから見えるパスを記録しておきましょう。アプリケーションの状態データとメディアのパスを、文書化されていない一時マウントの連鎖に組み込まず、個別に復元できるようにしておくと、復旧がずっと簡単になります。

バックアップ先は別の場所にし、同じ障害領域内の別フォルダーにしない

稼働中のJellyfinの状態データと同じSSDや同じディスクプールに保存されたバックアップでは、そのストレージの障害に備えられません。別のディスクセット、別のマシン、オフラインまたは遠隔地のコピーなど、復旧対象となる障害が起きても残る保存先を選びましょう。

Jellyfinのバックアップと復元に関するドキュメントでは、データベース、メタデータ、字幕、トリックプレイが、それぞれ独立したバックアップ対象として説明されています。どれが重要で、どれを再構築できるのか、また増加に備えてバックアップ先にどれほどの容量が必要かを決めましょう。

メディアのバックアップは、巨大なライブラリがアプリケーションの状態データを大きく上回ることもあるため、別途方針を決める必要があります。かけがえのないホームビデオは、再入手できるメディアよりも厳重に保護しましょう。また、削除、破損、操作ミスへの備えが必要なら、パリティやRAIDの冗長性だけを唯一のバックアップコピーとして扱わないでください。

まず復旧を検証し、その後に構成を分離または拡張する

拡張する前に、代表的なローカル再生、強制トランスコードの代表例、Jellyfinの状態をクリーンな場所または予備のインスタンスに復元するテストの3つを行いましょう。これらのテストでは、それぞれ通常の再生経路、コンピュートの例外経路、復旧経路を確認できます。

既存の構成を変更する理由がある場合に限り、コンピュートとストレージを分離しましょう。たとえば、容量拡張用の筐体が必要な場合、メンテナンス時間を個別に設定したい場合、GPUの配置、騒音や熱の制約、継続的なI/O競合などが該当します。分離すると役割を切り分けやすくなりますが、再生のたびにネットワークとリモートマウントが関わるようになります。

各役割の担当者が明確になり、クリティカルパスを測定でき、想定する障害が起きてもバックアップが残り、次のコンポーネントを追加しても既知のボトルネックが解消されたり復旧性が向上したりしない状態になったら、拡張を止めましょう。この境界を守れば、負荷がかかる状況でも修理できる程度に、ホームサーバーの構成を理解しやすく保てます。