新しいネットワークに移行した後にPlex環境を再構築する方法

Plexのアプリケーション状態を保持し、記録した新しいネットワーク契約で以前の契約を置き換え、内側から外側へアクセスを検証します。

この再構築は、既存のPlexサーバーとメディアライブラリを、以前とは異なるルーター、アドレス範囲、Wi-Fi構成、インターネット接続側を持つ家へ移した家庭を対象としています。継続的な作業は、今もローカルおよびリモートで再生できるようにすることです。変わった依存関係は、クライアントがサーバーを見つける方法、ストレージのマウント方法、外部からの通信がサーバーに到達する方法です。データベース、メディアパス、またはサービス権限が維持されていない場合は、ネットワーク作業を中断し、まずそれらを復旧してください。

ネットワークを再構築する前に、稼働中のPlex状態を凍結する

新しいネットワークへの移行は、必ずしもPlexの移行を意味しません。同じホスト、アプリケーション状態、メディアストレージが無傷で移行されたなら、周辺のネットワーク契約が変わっても、サーバーは引き続き基準となるシステムであるべきです。2台目のサーバーを作成したり、新しいライブラリスキャンを開始したり、利用できないフォルダーを早く削除したりすると、ルーティングの変更がアプリケーション移行に変わり、視聴履歴、カスタムメタデータ、ライブラリIDの保持が難しくなります。

変更を始める前に、データの役割を分けます。永続的なアプリケーション状態には、データベース、メタデータ、環境設定、サーバーIDが含まれます。ユーザー向けの継続性は、Plexデータベースに保存されている視聴履歴や評価にも左右されます。メディアファイルは別の、通常ははるかに大きな役割を持ちます。トランスコードファイル、再生成できるサムネイル、その他の一時的な派生データは、再構築可能なキャッシュです。アプリケーション状態は稼働中のディレクトリ外にバックアップし、失うと取り戻せないメディアは損失の影響に応じて保護します。また、使い捨てのキャッシュを主要データとして扱い、バックアップ容量を費やさないでください。

以前の構成がメモ、スクリーンショット、またはルーターのエクスポートに残っているうちに、旧構成から新構成へのワークシートを作成します。サーバーのホスト名とネットワークインターフェースの識別情報、以前のアドレスとサブネット、DHCP予約、ローカル名、ストレージのマウントパス、サービスアカウント、クライアントセグメント、リモートアクセス方法、共有ユーザーの想定を記録します。目的は、以前の設定をすべてコピーすることではありません。Plexとそのクライアントが実際にどのような前提に依存していたのかを特定することです。

LANを再割り当てする前に、管理されたベースラインを取得します。サーバーをローカルで開き、想定されるライブラリとアカウントIDを確認し、既知のアイテムを1つ再生して、アプリケーション状態の一貫したコピーを作成します。新しいトポロジーの検証が完了するまで、古いコピーは変更せずに保管します。このベースラインですでにデータベースの破損、マウントの欠落、ファイルアクセスの拒否が示されている場合は中止してください。これらはアプリケーションまたはストレージの復旧に関する問題であり、新しいルーターにさらにルールが必要であることを示すものではありません。

新しいLANの取り決めを選び、その後でサーバーに安定したIDを付与する

最初のトポロジー上の判断は、新しいLANを以前のLANに合わせるか、新しいアドレス計画を確立するかです。以前の設計が文書化され、安全で、競合がなかった場合は、以前のサブネット、無線ネットワーク名、関連する予約を再利用すると変更を減らせます。提供されたルーターで以前の範囲を再現できない場合、以前の設計で信頼済みデバイスとゲストデバイスが混在していた場合、または同じプライベート範囲が接続先の業務用VPNや別の拠点と競合する場合は、新しいプレフィックスのほうがすっきりします。どちらを選んでも、意図的に決めたものであれば有効です。

1つの管理元のもとで、サーバーに安定したローカルIDを1つ割り当てます。一般的なホームネットワークでは、ルーターのDHCPサービスからアドレスを発行し、サーバーの稼働中のネットワークインターフェースにDHCP予約を紐付けます。これにより、DHCPサーバーは以後の要求でも、そのインターフェースに同じ事前設定アドレスを提供できます。予約と、動的プール内の管理されていない手動アドレスを併用しないでください。2つの管理元が、最終的に異なるデバイスへ同じアドレスを割り当てる可能性があります。サーバーで手動アドレスを使う必要がある場合は、プールの範囲外に置き、ゲートウェイ、プレフィックス、DNS設定をアドレスと併せて記録します。

アドレス計画が安定してから、ローカル名を追加します。その名前は、Plexの管理または再生を許可されたクライアントネットワークから、予約済みアドレスに解決される必要があります。これにより、ブックマーク、ストレージマウント、将来のアドレス変更に読みやすい取り決めを提供できますが、名前解決が不確かな場合でも、制御の基準はアドレスのままです。ファームウェアのリセットやデバイスの再検出後に変わる可能性がある、ルーターが自動生成するニックネームに依存しないでください。

この段階は、制御された再接続を1回行って完了します。サーバーのリースを更新するか、1度だけ再起動し、許可されたクライアントから選択したローカル名を解決して、その名前とアドレスが同じホストに到達することを確認します。まだリモートアクセスは設定しないでください。リースサイクルを維持できていないアドレスを対象にしたリモートルールは、開始が遅れた将来の障害にすぎません。

新しいセグメントを中心にクライアントディスカバリーを設計する

安定したサーバーアドレスで解決できるのは到達性であり、必ずしもディスカバリーではありません。異なるサブネット上にある Plex 環境では、Web インターフェースを公開できても、自動サーバーディスカバリーには失敗することがあります。ルーターとゲストネットワークは境界を定義し、ローカルディスカバリートラフィックを通過させない場合があります。そのため、許可された経路上のブラウザーからローカルエンドポイントにアクセスできても、テレビにはサーバーが一覧表示されないことがあります。これらは別々の2つの契約として扱ってください。1つはルーティングされたサービス経路、もう1つはサーバーを通知する利便性レイヤーです。

ルールを開放する前に、クライアントをゾーンごとに分類します。リビングのテレビとメイン LAN 上の有線サーバーは、同じ信頼済みメディアゾーンに所属させられます。家庭用 Wi-Fi のスマートフォンは、同じゾーンまたはルーティングされたクライアントセグメントに所属させられます。ゲスト Wi-Fi と信頼できないデバイスは、意図的に昇格させない限り分離したままにしてください。新しい住居で VLAN、メッシュのゲストネットワーク、または追加のルーターを使用する場合は、すべてのネットワーク名が同じ LAN を表すと仮定せず、各ホップを図にしてください。

分離されたクライアントが本当に Plex を必要とする場合は、まず最小限のルーティング経路を確立します。そのクライアントゾーンから安定したサーバーエンドポイントへのサービス接続を許可し、管理アクセスは再生よりも厳しく制限します。クライアント側の利用体験に必要で、どのアナウンスが中継されるかを理解している場合に限り、ディスカバリーリレーまたはプロキシを追加してください。1つのアプリを表示させるためにゲストネットワークと信頼済みネットワークを広範囲にフラット化すると、その影響は引っ越し後も残るアーキテクチャ上のトレードオフになります。

2つ1組で検証します。メインLANでは、自動検出とローカルエンドポイントへの直接アクセスの両方を確認します。分離された各ゾーンでは、まず明示的なエンドポイントを試し、次に検出を試します。直接アクセスは成功して検出だけが失敗する場合、残る判断事項はアナウンスに関するものです。直接アクセスも失敗する場合は、Plexに触れる前にルーティングまたはポリシーを修正します。少なくとも1つの分離ネットワークを陰性テストとして残してください。サーバーへの到達が想定されていないネットワークでは、引き続き失敗する必要があります。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ライブラリを再作成せずにストレージパスと権限を再接続する

ネットワークの移行によって、サーバーからストレージへの接続方法も変わる可能性があります。メディアが別のNASに保存されている場合、アドレスで共有をマウントしていた場合、またはコンテナがホストパス経由でメディアを受け取っている場合は、特に重要です。Plexにライブラリの検査を依頼する前に、オペレーティングシステムまたはコンテナのレイヤーでストレージマウントを再確立します。可能であれば、移行前にアプリケーションが使用していたものと同じ安定したマウントパスを提示し、データベースが引き続き同じメディアツリーを参照できるようにします。

アプリケーションの状態、メディア、キャッシュの権限は分けて管理します。Plexサービスには、永続状態への読み書き権限、メディアへの読み取り権限（Plexを通じてメディアを明示的に変更するワークフローの場合を除く）、そしてキャッシュまたは一時トランスコード先への書き込み権限が必要です。すべてのバックアップ共有やアーカイブ共有に対する広範な書き込み権限は必要ありません。専用のサービスユーザーを使うことで、その境界が明確になり、再生が管理者の個人的なパスワードに依存することも避けられます。

メディア共有のアドレスが新しくなった場合は、各ライブラリパスを個別に編集するのではなく、マウント定義またはローカル名を更新します。認証情報が変わった場合は、サービスレベルのシークレットを更新し、Plexの起動前にマウントが利用可能であることを確認します。これにより、アプリケーションデータベースはライブラリの整理を担い、ホストはネットワークストレージを担うという役割分担を維持できます。また、環境を再接続する場所を1か所に集約できるため、復旧もしやすくなります。

管理者アカウントだけでなく、サービスの実行ユーザーでテストします。Plexは専用ユーザーで実行できるため、管理者なら読み取れるマウント済みドライブやフォルダーでも、そのユーザーにはアクセスが拒否される場合があります。各メディアのルートから既知のファイルを1つ読み取り、元に戻せるメタデータ変更を1つ行い、一時データが意図したキャッシュパスにのみ保存されることを確認します。ライブラリが突然空になった場合は、削除や再作成を行う前に停止してください。保存しておいたベースラインと照合して、マウント、パス、権限を確認します。利用できないツリーを、新しいライブラリと取り違えてはいけません。

新しいインターネットエッジ向けのリモートアクセスを選択する

リモートアクセスは、以前のルーターからそのままコピーするのではなく、新しいインターネットエッジ向けに再設計する必要があります。ISPの引き渡し地点から、すべてのルーティングデバイスを経由してPlexホストに至る経路を図にします。新しいルーターのWAN側に表示されるアドレスと、外部から確認したパブリックアドレスを比較してください。別のルーターやキャリアグレードNATが上流にある場合、ISPが外側の変換レイヤーを管理しているため、内側のルーターだけに転送ルールを設定してもエンドツーエンドのインバウンド経路は作れません。

2つの運用モデルのいずれかを選びます。管理されたインバウンドマッピングは、パブリックエッジを自分で管理しており、プライベートネットワーク用クライアントなしで通常のPlexクライアントを接続する必要があり、1つの明示的なサービス公開を維持する意思がある家庭に適しています。マッピング先は予約済みのサーバーアドレスにし、ホストのファイアウォールでは必要な通信のみを許可します。テストを通すためだけに、サーバーをDMZに置いたり、広範な自動マッピングを許可したりしないでください。

プライベートトンネルまたはオーバーレイは、信頼できるリモートデバイスが少数ある場合、設定できない上流ネットワークを利用している場合、またはパブリックなリスナーを公開したくない家庭に適しています。これは依存先をインバウンド転送から認証済みのプライベートパスへ移しますが、すべてのリモート再生デバイスがそのパスに参加するか、そこへ到達できなければなりません。どちらのモデルも普遍的に安全または簡単だと考えるのではなく、実際のクライアント構成に基づいて判断してください。

直接接続がパブリック名に依存し、ISPによってパブリックアドレスが変更される可能性がある場合は、その名前の更新担当を決めます。ダイナミックDNSクライアントを使えば、レコードを現在のWANアドレスに合わせて維持できます。このWAN IDはサーバーのローカルDNS名とは分けてください。これらはエッジの異なる側を解決するものです。そのうえで、スマートフォンの自宅Wi-Fiをオフにするか、別の外部接続を使い、想定したユーザーとしてサインインして、再生が選択した構成を通ることを確認します。自宅内からのテストに成功しても、パブリックエッジが検証されたことにはなりません。

一度にすべてではなく、段階的に再構築を検証する

エンドツーエンドの再生テストで証明できるのは、たまたま1つの経路が機能したということだけです。リング型テストでは、複雑なシステムをサブシステムに分解し、失敗した層を切り分けることで、無作為な変更を試すのではなく、障害の原因を特定できます。サービスのすぐそばから始め、アプリケーションの状態、ローカルアドレス、ローカル名、同一LANでの再生、ルーティングされたクライアントゾーン、そして最後にインターネット境界へと、依存関係を一度に1つずつ外側へ確認します。最初に失敗したリングを記録し、複数の層を同時に変更せず、それ以前の合格結果を維持します。

リング1～3に合格してリング4に失敗した場合は、別のライブラリを再構築するのではなく、ルーター交換後のリモートアクセスに注目します。

難しい形式をテストする前に、接続確認には同じ既知のメディア項目を使用します。これにより、ネットワーク検証を新しいトランスコードやクライアント互換性の変数から切り離せます。各経路を確認できたら、代表的なダイレクトプレイ項目と、サーバーの通常の変換処理を実行する項目を追加します。目的は新しい環境の性能を測定することではなく、ネットワークを移行しても、確立済みのワークフローがひそかに別の経路へ変更されたり制限されたりしていないことを示すことです。

ネガティブテストも含めます。ゲストクライアントは引き続きサーバーを管理できない状態にします。制限付きアカウントには、割り当てられたライブラリだけが表示されるようにします。オフサイトテストでは、選択したリモートパスを意図的に無効にした場合に失敗することを確認します。これらの結果により、アクセスだけでなく境界も維持されていることを証明できます。将来ルーターを交換する際に、想定された分離状態と障害を区別できるよう、マトリックスをネットワーク用ワークシートと一緒に保存します。

新しいネットワークを復旧可能なベースラインにする

再構築が完了するのは、今夜の映画を再生できたときではなく、新しいネットワークを復元できるようになったときです。ルーターとLANの役割、サーバーの予約、ローカル名とパブリック名、クライアントゾーン、ストレージのマウント、サービスID、リモートアクセスの方式、検証日を設定記録に更新します。秘密情報はワークシート自体に記載せず、パスワードマネージャーまたは保護された設定ストアで管理してください。

アプリケーション状態とメディアは、別々の復旧作業として保護します。アプリケーション状態は頻繁に変更されますが、定期的なバージョン付きコピーを作成できる程度に小容量です。メディアには容量を考慮したスケジュールが必要になる場合がありますが、かけがえのない家族の録画には、プライマリサーバーの障害範囲外に独立したバックアップコピーを用意してください。ディスクの冗長化によって、1台のデバイスが故障した後もサービスをオンラインに保てる場合はありますが、誤って削除したファイル、破損したデータベース、盗難に遭ったサーバー、または損傷した自宅を復旧することはできません。

使い捨ての復元テストを実行します。アプリケーション状態のコピーを分離された場所または一時インスタンスに復元し、メディアパスのテスト用ビューに接続して、想定したサーバーID、ライブラリ、メタデータが表示されることを確認します。テストによって稼働中のデータベースに書き込んだり、本番サーバーの名前を変更したりしてはいけません。復元に使用した入力と結果を記録し、この検証に合格するまで以前の基準環境を保持します。

拡張する範囲と停止する境界を、今のうちに決めます。新しいクライアントゾーンで必要になった場合にのみ、セグメント間の検出を追加します。ISP側の境界または家庭内の信頼モデルが変わった場合は、外部からの直接公開を見直します。計測した需要、または復旧上の依存関係によって別のノードが正当化される場合にのみ、コンピュートとストレージを分離します。データベースの整合性、ストレージのマウント、サービス権限、または復元テストが失敗した場合は、ネットワークルールの追加を止め、アプリケーションまたはストレージの復旧に移行します。

最終セットアップルール

移転後のPlex再構築を成功させるには、サーバーの状態を保持しながら、古いネットワーク前提を、管理下にある1つのルールと繰り返し実行できる1つのテストに置き換えます。安定したID、クライアントの接続経路、リモートアクセス、最小範囲の権限、そして使い捨ての復元がすべて通過した場合にのみ、新しい基準を受け入れてください。有効な小規模テストでは、選択したデータを別の場所に復元し、本番環境に触れずに内容と権限を比較できます。それ以外の場合は、トポロジーを拡張するのではなく、最初に失敗した層で停止します。