ミニPCメディアサーバーではSMB共有とローカルマウントのどちらを選ぶべきか

1台のMini-PCでメディアライブラリを所有し、起動時の依存関係、権限、ネットワーク依存を最小限にしたい場合は、直接接続したストレージにローカルマウントを使用します。メディアファイルを独立したNASまたはファイルサーバーに置く必要がある場合、複数のシステムで共有する場合、またはMini-PCを再構築・交換してもそのまま残したい場合は、SMB共有を使用します。ほとんどのホームメディアサーバーでは、決め手となるのはSMBで映画を十分な速度でストリーミングできるかどうかではなく、ストレージの所有権と復旧です。

ここでいう「ローカルマウント」とは、内蔵SATA/NVMeやUSBエンクロージャーなど、Mini-PCに直接接続されたストレージ上のファイルシステムを意味します。SMB共有とは、メディアを別のマシンに置いたまま、メディアアプリケーションが読み取る前にMini-PCのオペレーティングシステムへマウントする構成です。サーバーがDocker上で動作している場合は、そのホストマウントをコンテナへバインドマウントできます。

プロトコルよりもストレージの所有者が多くを決める

ローカルマウントでは、Mini-PCが計算処理の所有者であると同時に、ストレージパスの所有者にもなります。サーバーが起動し、ディスクが正常なら、通常は別のホスト、DNSレコード、認証情報の交換、ネットワーク経路を待たずにメディアパスを利用できます。これは、1台で完結するメディアシステムに適しています。

SMB共有では、ファイルの所有権が別のNASまたはファイルサーバーに置かれます。Jellyfinのストレージに関するガイダンスでは、SambaまたはNFSストレージをオペレーティングシステムにマウントする一方、データベースはローカルに保持するよう示されています。この分離は有用なアーキテクチャ境界です。アプリケーションデータベースまでリモートにすることなく、メディアをリモートにできます。

したがって、選択は復旧に関する問いから始まります。Mini-PCを交換してもメディアライブラリがそのまま残り、別のホストですぐ再利用できる必要があるなら、SMBには大きな利点があります。Mini-PCとそのドライブを、復旧可能な一体型アプライアンスとして意図的に運用するなら、実際には必要のない要件を手放すことなく、ローカルストレージによって依存関係を減らせます。

ローカルストレージなら起動時の依存関係を大幅に減らせる

直接接続されたディスクは通常、ホストのローカルファイルシステムの起動シーケンスの一部として利用可能になります。メディアサーバーはそのファイルシステムがマウントされた後に起動でき、コンテナには同じ安定したホストパスを渡せます。NASの再起動やネットワークの起動遅延によって消える可能性のあるリモート共有もありません。

systemdはネットワークマウントとローカルファイルシステムを区別し、ネットワークマウントユニットをremote-fsターゲットの前後に適切に配置します。この違いは常時稼働のメディアサーバーにとって重要です。リモートファイルシステムが実際に利用可能になる前に、アプリケーションが想定されるライブラリパスをスキャンしないようにする必要があるためです。

ローカルだからといって自動的に安全とは限りません。緩んだUSBケース、故障したSATAケーブル、容量不足のディスク、破損したファイルシステムは、ネットワーク障害と同じようにライブラリを利用不能にする可能性があります。メリットはアクセス経路上のコンポーネントが少ないことであり、ストレージ障害を免れることではありません。

SMBによりライブラリをミニPCから独立させる

メディアストレージを現在のコンピューティングボックスの先でも使い続けるなら、SMBが最適です。NASが同じライブラリをJellyfinサーバー、ファイル管理用のデスクトップ、バックアップ処理、別のメディアホストに提供できるため、ディスクを物理的に移動する必要がありません。ミニPCを再構築しても、データ移行ではなくコンピューティング環境の復旧作業になります。

Dockerのバインドマウントはホストのパスをコンテナ内に公開するため、ホストにマウントした共有を別のファイルシステムパスと同じようにメディアコンテナへ提示できます。Dockerのバインドマウントモデルは読み取り専用マウントにも対応しており、メディアサーバーがライブラリファイルの読み取りだけを必要とし、元のファイルを変更すべきでない場合に便利です。

見落とされがちな条件は可用性です。Jellyfinは、タスクの実行中にメディアストレージを利用できない場合、スケジュールされたメンテナンスによってライブラリ項目が削除される可能性があると警告しています。そのため、ネットワーク共有には信頼性の高いマウント順序と障害処理が必要です。起動スクリプトにSMBパスを記述するだけでは、依存関係を堅牢にしたことにはなりません。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

ローカルでは権限がより単純だが、SMBではより明示的になる

ローカルストレージでは通常、メディアサーバーホストから見える権限レイヤーは1つです。つまり、ファイルシステムの所有権、モードビット、またはACLです。コンテナによってUID/GIDのマッピング問題が生じることはありますが、リモート共有のIDやアクセス ポリシーまで同時に調査する必要はありません。

TrueNASでは、SMBの共有レベルACLとファイルシステムACLを分けて管理できることが説明されています。現在のSMB共有とACLの管理に関するガイダンスからは、リモートパスのほうが明示的である一方、より多層的でもある理由が分かります。メディアホストが独自のローカルプロセス権限を適用する前に、ストレージサーバーが共有データセットをたどる、読み取る、変更することのできるアカウントを決定するためです。

この追加レイヤーは、複数のデバイスに異なる権限を与える必要がある場合に役立ちます。信頼できるメディアプロセスだけが利用する場合は、オーバーヘッドになります。権限が原因でスキャンの失敗やroot所有のファイルが繰り返し発生しているなら、リモートストレージをスケーラビリティ向上策として検討する前に、認証情報の経路を簡素化してください。

スキャンとストリーミングでは経路の異なる部分に負荷がかかる

映画の再生はほぼシーケンシャルで、安定したギガビット回線の一部しか使用しない場合があります。そのため、ネットワークとストレージサーバーに余裕があれば、SMB共有でもメディアを問題なくストリーミングできます。一方、ライブラリのスキャンでは、多数のメタデータ検索、ディレクトリ操作、アートワークの読み取り、小さなファイルへのアクセスが発生することがあり、遅延がより目立ちます。

Linux CIFSクライアントのドキュメントでは、SMB共有をLinuxファイルシステムにマウントするために使用されるカーネルクライアントについて説明しています。マウント後もメディアアプリケーションから見えるのはファイルシステムのパスですが、キャッシュされていない操作はネットワークを経由するたびにリモートサーバーの応答に依存します。

スキャンが遅いからといって、SMBが決定的に不適切だと判断しないでください。実際のネットワーク上で同じライブラリを比較し、NASのディスクレイテンシとリンク使用率を確認し、サムネイル、メタデータデータベース、トランスコードキャッシュが誤ってリモートに置かれていないかを確認してください。アプリケーションがリモート配置を明示的にサポートしている場合を除き、アプリケーションのデータベースと書き込み頻度の高いキャッシュデータはローカルに保持してください。

復旧によってシンプルさの勝者が逆転することがある

通常の運用ではローカルストレージの方がシンプルですが、メディアとコンピュートの復旧が連動する可能性があります。ミニPCが故障し、ライブラリが内蔵ドライブにある場合、再生を再開するには、ドライブを移設し、マウントを再作成するか、バックアップから復元する必要が生じることがあります。

SMBライブラリでは、データ経路がすでに別の場所にあるため、コンピュートの復旧を迅速化できます。交換用ホストにメディアアプリケーションをインストールし、設定を復元して、同じマウントポイントを再作成すれば、既存の共有に再接続できます。隣接するDASとNASストレージの比較では、所有形態のより広い違いを説明しています。ミニPCのメディアサーバーでは、この違いが具体的な復旧依存関係になります。

したがって、逆転条件は明確です。独立した復旧よりも1台で完結するシンプルさが重要なら、ローカルが有利です。ライブラリを特定の1台のメディアサーバーホストより長く使い続けたい場合や、複数のシステムから利用したい場合は、SMBによる追加の依存関係によって、復旧作業の総量が増えるどころか減る可能性があります。

ライブラリのライフサイクルに合わせてマウント方式を選ぶ

ミニPCを意図的にストレージアプライアンスとして使い、ドライブを簡単にバックアップでき、起動から再生までの経路を最短にしたい小規模な単一ホストのライブラリには、ローカルマウントを選択してください。常時稼働のNASに依存できない、ポータブルまたは構成の単純な環境にも適しています。

NASがすでにメディアを管理している場合、複数のシステムでファイルを必要とする場合、ストレージ容量をコンピュートとは独立して拡張したい場合、またはライブラリを移動せずにメディアサーバーのハードウェアを交換したい場合は、SMBを選択してください。マウントを起動時の必須依存関係として扱い、アプリケーションのデータベースとトランスコードキャッシュはローカルストレージに置いてください。

合成スループットの数値だけで、どちらかを選ばないでください。両方の方式で必要なビットレートを提供できるなら、ライブラリの実際の運用方法に合わせて、権限、マウントの可用性、復旧時の挙動が適切な方が、より優れた設計です。