Plexのアプリデータをネットワーク共有上に置いても安定して動作しますか？
Plexはネットワーク共有からメディアを安定して読み取れますが、サーバーの稼働中のアプリデータやデータベースまでその共有上に置くとなると、話は別です。多くのホームサーバーでは、Plexのアプリデータにはローカルの永続ストレージを使い、大容量のメディアファイルにはSMBまたはNFSを使う構成が、より安全な初期設定です。
違いはワークロードの特性にあります。メディア再生は主に大きなデータを順番に読み取る処理ですが、Plexのアプリデータにはデータベース、メタデータ、環境設定、多数の小さな更新が含まれます。これらは、遅延、再接続、ファイルシステムのロックにより大きな影響を受けます。ネットワーク上に置いた設定データが、管理された環境で機能する場合もあります。しかし、ローカルSSDと同等とみなすのではなく、テストによって信頼性を確認すべきです。
Plexのアプリデータとメディアストレージを分ける
まず、どのPlexデータを指しているのかを明確にします。映画、テレビ番組、音楽のファイルはNAS共有上に置き、サーバーアプリケーション、データベース、メタデータは計算ホスト上に残せます。この2種類のデータをまとめて移動すると、リモートメディアをマウントするだけの場合よりも、はるかに大きな信頼性の問題が生じます。
Plexは、メディアフォルダー自体ではなく、データベースにライブラリの状態を保存します。実用的な分析では、PlexはデータとメタデータにSQLiteデータベースを使用していると説明されています。つまり、アプリデータのパスには、通常の動画ストレージにはないトランザクション処理が関係します。
以降のテストでは、「ネットワークメディア」と「ネットワーク上のアプリデータ」を別々の設計として扱ってください。メディアだけがリモートにある場合は、共有の可用性とスループットをテストします。稼働中のPlex設定をリモートに置く場合は、データベースの動作、メタデータの遅延、共有が一時的に消えたときの挙動もテストする必要があります。
Plexのアプリデータがストレージに求めるものを理解する
Plexのアプリデータには多数の小さなファイルと、サーバーの稼働中に開かれて更新されるデータベースが含まれます。そのため、メディアストリーム自体をネットワークで処理するのが容易な場合でも、ポスターの閲覧、ライブラリの変更、視聴状態、環境設定、メタデータ処理には低遅延のアクセスが必要になることがあります。
SQLiteはファイルシステムのロックに依存するため、ストレージの仕組みが重要です。SQLiteのロックに関する公式ドキュメントでも、ネットワークファイルシステムのロックは、一部のNFSやWindowsネットワークファイルシステム実装で不安定だったり、存在しなかったりする可能性があると警告されています。これは、単純な帯域幅不足とは異なるリスクです。
だからといって、すべてのネットワーク共有がすぐにPlexを破損させるわけではありません。ただし、1回正常に起動しただけで適合性を証明することはできません。1回のセッションでは高速に動作する設計でも、同時更新、再接続、サーバーの再起動、ストレージのフェイルオーバーでは脆弱になる可能性があります。
ネットワーク共有が機能する条件を知る
アプリデータのパスをネットワーク上に置く構成が最も妥当なのは、安定した有線LAN上に共有があり、Plexの起動前にマウントされ、アプリケーションが期待する所有権とロックのセマンティクスが維持され、メタデータ処理の応答性を保てる程度に遅延がローカルストレージに近い場合です。
実際のPlex導入例では、この分離が明確に示されています。メディアライブラリはNFSを基盤とするPlexデータ共有に置きながら、Plexの設定ボリュームとトランスコードボリュームは選択したノード上にローカルで保持できます。同じ記事では、設定ボリューム自体をNFS上に置いた場合に、大幅なパフォーマンス問題が発生したと報告されています。
それでも、移動性や集中管理されたストレージのためにアプリデータをネットワーク上に置く必要がある場合は、最初のテストを元に戻せる状態にしてください。検証済みのバックアップを用意し、マウントとサーバーの識別情報を固定したうえで、リモートパスを唯一の稼働コピーにする前に、通常の閲覧、ライブラリ更新、再起動、バックアップと復元の動作を確認します。
NFSやSMBが弱点になり得る理由を知る
注意すべき障害の種類は、遅延、中断、ロックの3つです。往復遅延が大きいとメタデータ中心の処理が遅く感じられ、マウントが切断されるとアプリケーションのパス自体が消える可能性があります。また、ロックに一貫性がないと、通常のファイルコピーが正常に見えていても、データベースに影響することがあります。
これらのリスクは、メディア共有の問題とは異なる形で現れることがよくあります。メディア共有が見つからない場合は、通常、ファイルを利用できない状態になります。一方、アプリデータ共有の問題は、ポスターの読み込みが遅い、データベースエラーが発生する、サーバーが新規初期化されたように見える、再起動後に状態が正常に戻らない、といった形で現れることがあります。
対策として、共有を書き込み可能な全開放状態にしたり、データベースの保護機能を無効にしたり、空のフォールバックディレクトリを使ってPlexを強制起動したりしないでください。ネットワークパスが正しく存在しない場合はサービスを停止し、マウントを復元して、次の書き込みが行われる前に元のアプリデータツリーであることを確認します。
よりシンプルな構成のために、アプリデータはローカル、メディアはネットワークに置く
小規模なホームサーバーでは、PlexのアプリデータをローカルSSDなどの低遅延な永続ストレージに置き、大容量のメディアをNASに保存する構成が、通常はよりシンプルで信頼性の高い境界になります。これにより、データベース処理をプロセスの近くに置きながら、大規模なライブラリを個別に拡張できます。
この分離はトラブルシューティングも容易にします。Plexの起動は遅いもののメディアのスループットに問題がない場合は、ローカルのアプリストレージを調べられます。ライブラリ項目を利用できなかったり、高ビットレートのストリームが停止したりする場合は、同じ共有がデータベースまで遅延させているのではないかと悩まずに、ネットワーク上のメディアパスを調べられます。
ZimaSpaceによるNASの共有アクセスの比較は、ホームサーバーの設計でSMBやNFSをどこに配置するかを決める際に役立ちます。Plexでは、ネットワークアクセスに価値がある場所に共有レイヤーを使い、すべてのアプリケーション状態に自動的に適用しないようにしましょう。
Plexの状態を任せる前に共有をテストする
稼働中のアプリデータを移動する前に、唯一の稼働状態を移動するのではなく、候補となる共有にコピーまたは復元したテスト用データを用意します。メンテナンス時間中にそのテストコピーでPlexを起動し、起動時間、データベースエラー、ライブラリの応答性、共有の遅延を記録します。
次に、ネットワークファイルシステムの弱点が現れやすい操作を繰り返します。ライブラリを更新し、視聴状態を変更し、Plexを再起動し、ホストを再起動します。また、サービスの起動前に共有が利用できない場合に何が起きるかを一時的に確認します。目的は障害を発生させることではなく、Plexが誤ったパスや空のフォールバックパスに書き込まないことを証明することです。
繰り返しのテストで、データベースの警告やメタデータの大幅な速度低下がなく、同じサーバー識別情報とライブラリ状態が戻る場合にのみ、ネットワーク上に置く構成を採用してください。アプリデータをローカルに戻すことで問題が解消し、ネットワーク上のメディアも正常なままであれば、実現可能性の答えは出ています。データベースはローカルに置き、大容量のメディアはリモートに残しましょう。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
