コンピュート、ストレージ、バックアップ向けの完全なJellyfinホームサーバートポロジー

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Complete Jellyfin Home Server Topology for Compute, Storage, and Backup - Zima Store Online

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

このトポロジーは1つの筐体にも複数のマシンにも構築できます。重要なのは筐体の台数ではなく役割の違いです。コンピュートはクライアントにサービスを提供し、トランスコードを行う場合があります。アプリストレージには遅延の影響を受けやすいJellyfinの状態を保存し、メディアストレージは大容量ファイルを供給します。バックアップは障害後も維持すべきデータを保護します。共有設計によって測定可能な競合が発生する場合にのみ役割を分割してください。ホストやネットワークホップを増やすたびに、依存関係も増えるためです。

保存場所を選ぶ前に4つのデータ役割を定義する

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

この分類により、「ストレージ」を区別のない1つのプールとして扱うという、よくあるトポロジー上の誤りを防げます。大容量HDDアレイは動画ファイルの保存先としては優れていても、頻繁にアクセスされるメタデータデータベースの保存先としては不向きな場合があります。一方、高速SSDはアプリデータには便利ですが、大容量の低頻度アクセスライブラリには高価で不要です。

ZimaSpaceのメタデータ配置ガイドも同じ役割分担を採用しています。アクティブなデータベースとキャッシュは高速ストレージに置き、移行のしやすさを考慮して、移植可能なサイドカーやアートワークをメディアと一緒に保存するかどうかは別途判断します。

主要な再生経路をシンプルに保つ

重要な経路は、クライアント → ネットワーク → Jellyfinコンピュート → メディアソースです。コンピュートとメディアが同じマシンにある場合、メディアへのホップはローカルになります。分離されている場合、コンピュートノードは配信またはトランスコードするすべてのバイトをネットワーク経由で読み取り、その結果をクライアントに送信する必要があります。

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

競合が発生する場合は、管理、実験、オプションサービスを再生経路から分離してください。セカンダリVLAN、別のコンテナネットワーク、またはバックアップ時間帯のスケジュール設定だけで十分な場合もあります。共有経路によってサービス品質が実際に低下する場合にのみ、完全に別の物理ネットワークを追加する価値があります。

メディアエンジンとサービス分離を検証しやすい場所にコンピュートを配置する

コンピュートは、実際に実行する再生処理に基づいて選定してください。ダイレクトプレイでは動画処理能力はほとんど必要ありませんが、互換性のないクライアント、字幕の焼き付け、HDR変換、リモート再生時のビットレート制限によって、トランスコードが主要な処理になることがあります。

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

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

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

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

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

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

ライブラリがリモートにある場合は、予測可能な方法でマウントし、Jellyfinサービスから見えるパスを文書化してください。アプリ状態のパスとメディアのパスを、文書化されていない一時マウントの連鎖に埋め込むのではなく、個別に復元できるようにしておくと、復旧がはるかに容易になります。

バックアップは同じ障害ドメイン内の別フォルダーではなく、別の保存先にする

ライブ状態のJellyfinと同じSSD、または同じディスクプールに保存されたバックアップは、そのストレージ障害から保護してくれません。バックアップ先は、別のディスクセット、別のマシン、オフラインまたはオフサイトのコピーなど、復旧対象の障害モードに耐えられるものである必要があります。

Jellyfinのバックアップと復元に関するドキュメントでは、データベース、メタデータ、字幕、トリックプレイを別々のバックアップ内容のカテゴリとして扱っています。どれが重要で、どれが再構築可能か、また増加に必要な保存先容量がどの程度かを決めてください。

大容量ライブラリはアプリケーション状態を大きく上回る可能性があるため、メディアのバックアップは別途ポリシーを決める必要があります。代替可能なメディアよりも、かけがえのないホームビデオをより厳重に保護してください。削除、破損、操作ミスまで想定する場合、パリティやRAIDの冗長性だけを唯一のバックアップコピーと見なしてはいけません。

トポロジーを分割または拡張する前に、まず復旧を検証する

拡張する前に、代表的なローカルストリーム、強制的にトランスコードした代表的なストリーム、クリーンな場所または予備インスタンスへのJellyfin状態の復元という3つのテストを実行してください。これらのテストでは、それぞれ主要な再生経路、コンピュートの例外経路、復旧経路を検証できます。

コンピュートとストレージの分離は、既存の構成を変更する理由がある場合にのみ行ってください。たとえば、容量拡張用エンクロージャの必要性、独立したメンテナンス時間帯、GPUの配置、騒音や熱の制約、継続的なI/O競合などです。分離設計によって役割の独立性は高められますが、ネットワークとリモートマウントがすべての再生に関わることにもなります。

各役割の責任者が明確で、重要な経路を測定でき、バックアップが想定する障害に耐え、次のコンポーネントを追加しても既知のボトルネックの解消や復旧性の向上につながらない状態になったら、拡張を止めてください。その境界を守ることで、負荷がかかった状況でも修復できるほど、ホームサーバーのトポロジーを理解しやすく保てます。