Jellyfinに専用の演算リソース、ストレージ、またはネットワークが必要になるのはどんなとき？

共有リソースによって繰り返し発生する競合、許容できない障害の連鎖、または明確に定義できない成長要因が生じる場合、Jellyfinには専用のコンピュート、ストレージ、またはネットワークが必要です。

専用化したからといって、必ずしも高速になるわけではありません。まずは共有構成を基準にし、再生、スキャン、トランスコード、バックアップ、その他のサービスを同時に実行したときの実際のワークロードを確認してください。基準を満たせない役割だけを分離し、その後、クライアントからメディアおよび復旧用コピーまでの新しい経路を検証します。

トランスコードのキューが繰り返し発生する場合はコンピュートを専用化する

同時に実行される変換数を数え、使用中のコーデック、トーンマッピング、字幕処理でハードウェアアクセラレーションが利用できるか確認してください。近隣のサービスがCPUやGPUの時間を消費している間、Jellyfinでトランスコードのキューが定期的に発生するなら、専用のコンピュートノードによって遅延を予測しやすくできます。

ほとんどのクライアントがダイレクトプレイを使用し、共有ホストに余裕があるなら、コンピュートは共有したままで構いません。複数ストリームの混在ワークロードに関する議論が示すように、重要なのは表面的なストリーム数よりも、実際のトランスコードの種類です。

状態データと大容量メディアに異なる保証が必要な場合はストレージを専用化する

ディスク遅延、ドライブのスピンアップ、またはメンテナンスジョブが再生に影響する場合は、Jellyfinのデータベースとキャッシュを大容量メディアから分離してください。容量の拡張とディスク交換が主な成長要因なら、専用NASが有効です。一方、アプリケーションの状態データや一時作業には、ローカルSSDのほうが適しています。

単に機器を増やすためだけにストレージを分割しないでください。新しいトポロジーでは、安定したマウント、独立したバックアップ先、そして永続的な各役割に対する復元手順を用意する必要があります。

共有経路がボトルネックの場合はネットワークを専用化する

Jellyfin、クライアント、ストレージ、リモートユーザー間の経路を測定してください。バックアップ、ファイル転送、または別のサービスが同じリンクを飽和させ、再生の停止を引き起こす場合は、専用インターフェースやVLANを導入する価値があります。ボトルネックがWANのアップロード帯域やクライアントのコーデックにあるなら、LANポートを増やしても結果は変わりません。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

最後の判断基準として障害の連鎖を確認する

共有ホスト、ストレージプール、またはスイッチを再起動した場合に何が起きるかを確認してください。1回の復元で簡単に対応でき、影響範囲も許容できるなら役割をまとめて構いません。一方、1つの障害によってサービスと唯一の復旧用コピーの両方が失われるなら、分離してください。

測定したピーク負荷を処理でき、復旧テストも済んでいて、次のアップグレードがまだ1つのコンポーネントで済むなら、共有リソースを選びます。同じ競合や障害が繰り返されるなら、専用リソースを選びます。再生、復旧、または拡張性のいずれも改善しない分離は、そこで止めてください。