Plexでストレージを2階層に分ける構成では、レイテンシに敏感なデータベースやメタデータをSSDに置き、大容量のメディアファイルは容量重視のHDDストレージに保存します。
この分離が有効なのは、アプリデータの保存先を独立してバックアップでき、メディアの転送速度がすでにHDDアレイの範囲内に収まっている場合です。ナビゲーションやメンテナンスを改善するために、SSDへ映画ライブラリを保存する必要はありません。また、ソースファイルをHDDに保存しているからといって、データベースまでHDDに置く必要もありません。2つの階層は、役割も復旧計画も分けて扱いましょう。
データベースとメタデータは低レイテンシの階層に置く
検索、ブラウジング、アートワーク、データベースのメンテナンスでは、多数の小さな読み書きが発生します。こうした処理は、シーケンシャルな映画ストリーミングよりも、シークレイテンシの低減による恩恵が大きくなります。
多くの場合、最も大きな効果が得られるのは、レイテンシに敏感な状態データを機械式ストレージから移すことです。ここでSSDとHDDのランダムアクセス特性の違いが最も顕著に現れます。
PlexのアプリデータをSSD階層に置き、ライブラリの表示、検索、メンテナンスのレイテンシを測定します。データベースの拡大と生成メタデータに備えて、十分な空き容量を確保してください。
大容量メディアは容量重視のストレージに保存する
動画の再生はほぼシーケンシャルなため、合計スループットと信頼性が要件を満たせば、HDDから配信できます。すべてのメディアをフラッシュストレージに移しても、ユーザー体験よりコストの変化のほうが大きいことがよくあります。
階層型のメディアサーバーのストレージ設計では、アプリの状態データに求められる低レイテンシと、大容量メディア向けの容量を分けることで、それぞれのデバイスを用途に応じて評価できます。
複数のメディアを同時に読み込む際の最大速度を測定し、現実的な断片化やバックグラウンド処理がある状態でHDDプールと比較します。その経路が実際にボトルネックになっている場合に限り、メディアストレージをアップグレードしてください。
2つの役割を別々にバックアップする
Plexの状態データは比較的小容量ですが、正確に再現するのは困難です。一方、メディアは大容量で、別のバックアップや冗長化の方針が適している場合があります。両者を同じように扱うと、高速ストレージを無駄にしたり、データベースの保護が不十分になったりするおそれがあります。
バックアップの容量と変化量は、各データセットの変更速度と、再構築にかかるコストを反映させる必要があります。
視聴状況や設定の変更が反映される頻度でアプリデータをバックアップし、交換にかかるコストと容量に応じてメディアを保護します。アプリ状態のコピーを少なくとも1つ、SSDデバイスの外部に保管してください。メディアセンターのストレージの役割を分けることで、SSDは遅延に敏感な状態データを保護し、HDDの容量は大容量メディアの保存に専念できます。
各層の障害を個別に検証する
一方の層の喪失が、予期した障害にとどまらず、復旧不能なサーバー障害へ連鎖するなら、このアーキテクチャは役に立ちません。SSDとHDDの役割ごとに、個別のテストと復元手順が必要です。
管理された復元テストにより、コピーした状態データが交換後に意図したメディアパスへ再接続できることを確認できます。
Plexの状態を一時的なSSDパスに復元し、テスト用のメディアを一部接続します。メディア層が一時的に利用できない場合のサーバーの挙動を記録しておけば、次回の障害を分類しやすくなります。
NASとサーバーのセットアップ
続きを読む

寮のサーバーは、睡眠や勉強、ビデオ通話の妨げにならないほど静かに動作しますか?
はい。低消費電力のハードウェアを使い、ストレージの振動を抑え、負荷の高い処理をスケジュールし、部屋で騒音を確認すれば、寮のサーバーは目立たずに運用できます。

寮の部屋から初めてのアパートへ持ち運べる学生向けホームラボ
サービスを部屋ごとのネットワークから切り離し、ハードウェアを最小限に抑え、状態をバックアップし、スムーズな移設をリハーサルして、学生のホームラボを持ち運びやすく保ちましょう。

アカウントや個人ファイルを共有せずに、ルームメイトと1台のホームサーバーを共有する方法
ルームメイト一人ひとりに名前付きのIDとプライベートストレージを用意し、共有権限は必要なものだけ付与しましょう。管理、バックアップ、利用終了時の対応はそれぞれ分けて管理します。



