Plexのアプリデータ、キャッシュ、バックアップを分離する方法
耐久性の高いPlex構成では、ストレージ階層を割り当てる前に、アプリデータ、再構築可能なキャッシュ、一時作業領域、バックアップコピーを分離します。
この設計では、コンテナやホストを置き換えてもデータベースとメタデータを保持できる一方、復旧に影響を与えずにキャッシュやトランスコードデータを削除できるようにします。バックアップは、稼働中の状態とは異なる障害経路に置く必要があります。これらの役割を明確にすれば、SSDの容量を、不要な大容量コピーではなく、遅延に敏感な状態データのために確保できます。
永続性のある低遅延経路にサーバーの状態を置く
Plexのデータベース、メタデータ、環境設定、IDに紐付いた状態はサーバーを構成する要素であり、実行環境を置き換えても保持されるべきです。この役割では、容量の大きさよりも、予測可能な遅延と復旧可能性が重視されます。
アクセスパターンがI/Oに敏感な場合、データベースのワークロードはストレージの遅延と帯域幅の影響を強く受けます。そのため、測定結果がそれを裏付ける場合は、アクティブなアプリケーション状態を高速な階層に配置するのが適切です。
Plexの状態データはコンテナイメージとは独立してマウントし、所有権、バックアップ、復元の手順を文書化します。永続的なアプリデータのレイアウトが、ストレージ設計の安定した中心となります。
キャッシュとトランスコードデータを再構築可能なものとして分類する
キャッシュは応答性を高め、トランスコード用の領域は高速な一時書き込みを必要とする場合がありますが、どちらもライブラリの正式なコピーとして扱うべきではありません。これらを失ってもパフォーマンスが低下するだけで、サーバーの識別情報が失われないようにします。
キャッシュされたページはストレージの読み取りを繰り返さずに済む一方で再構築可能です。そのため、キャッシュはPlexのデータベースやメタデータの状態とは異なる耐久性クラスに置くべきです。
一時データは安全に削除できる経路に置き、特定の復旧要件がない限り、高コストな長期バックアップの対象から除外します。
バックアップを異なる障害経路に置く
稼働中のPlex状態と同じ場所に保存したバックアップは、一部のアプリケーション上のミスからは保護できますが、デバイスの喪失、プールの破損、ホスト障害には対応できません。復旧用コピーは障害境界を越えて配置する必要があります。
バックアップシステムにはそれぞれ異なる容量要件と変動特性があるため、バックアップ先はアプリデータ用デバイスの未使用領域ではなく、独立したストレージの役割として容量を設計します。
少なくとも1つのコピーを稼働中の状態デバイスの外部に保持し、どの程度の時間で復元できるかを定義します。スナップショットは有用ですが、唯一の復旧経路ではありません。
置き換えテストでレイアウトを検証する
適切な役割マップがあれば、障害発生時にパスを再分類することなく、実行環境を置き換え、状態データを再接続し、キャッシュを再生成し、バックアップから復元できます。
文書化した状態データとバックアップの場所だけを使用して使い捨てホスト上にPlexを再構築し、その後、キャッシュのパスを意図的に消去します。サーバーの識別情報やライブラリが失われる場合は、役割が正しく分離されていません。
正常に完了した復元を、今後のストレージアップグレードにおけるトポロジーの契約として利用します。
おすすめ商品
NAS＆サーバー設定
もっと読む
AIに似た分析と自動化がJellyfinのストレージおよびコンピューティング要件をどう変えるか
自動化と関連するAI分析では、通常のJellyfin再生に加えて、スキャン、派生データ、CPU/GPU処理、キャッシュ、作業用領域、バックグラウンドスケジューリングが追加されます。
小さなアパートや賃貸住宅のネットワークにJellyfinを統合する方法
安定したローカルアドレス、最小限の配線、静音ハードウェア、CGNATを考慮したリモートアクセス、そして元に戻せる変更を軸に、賃貸住宅に適したJellyfinネットワークを構築しましょう。
1台のJellyfinホストでサポートできるユーザー数とバックグラウンドジョブ数はどれくらいですか？
Jellyfinユーザーとバックグラウンドジョブを1つの共有ワークロード予算として扱い、再生遅延、キュー、またはリソース圧迫が繰り返し発生した時点で容量の限界とします。
