自宅ルーターのフェイルオーバー中にNFSマウントがハングするのはなぜですか？
ホームルーターのフェイルオーバー中にNFSマウントがハングすることがあります。これは、ゲートウェイ、送信元アドレス、またはTCP状態が変化した経路で、既存のNFSリクエストが再試行を続けるためです。
ZimaSpaceホームサーバーでは、共有先が1台のNASにあり、別のノードからアプリ、メディアサービス、またはバックアップジョブがマウントしている場合があります。ルーターのフェイルオーバーによって基本的なインターネット接続は維持されても、既存のNFSセッションが孤立することがあります。すぐにNASを再起動するのではなく、ルートの状態、NFSの再試行動作、切り替え前後の経路を比較するのが有効です。
NFSの障害とルーター全体の障害を切り分ける
NASにIPアドレスで引き続き到達できること、また既存のマウントがハングしている間に新しいTCP接続を確立できることを確認します。
ネットワークとファイアウォールの問題に関する、焦点を絞ったNFSトラブルシューティングブログは、基礎プロトコルの定義だけでなく同じ細かな問題を扱っているため、この分岐の切り分けに役立ちます。
新しい接続も失敗する場合は、まずネットワーク経路を修復します。既存のマウントだけがハングする場合は、NFSの再試行と古いトランスポート状態を調べます。
ハードマウントが待ち続ける理由を理解する
共有がハードマウントされているか、またNFSが同じリクエストを再試行している間にアプリケーションがブロックしているかを確認します。
サーバーが消失してもアプリケーションを待機させ続ける方法に関する、焦点を絞った独立系のNFSベストプラクティスブログは、基礎プロトコルの定義だけでなく同じ細かな問題を扱っているため、この分岐の切り分けに役立ちます。
重要なデータについては、フェイルオーバーの問題を隠すためだけにソフトマウントへ切り替えないでください。到達性を修復し、重要度の低い共有にはオートマウントの境界を使用します。
ゲートウェイ変更後に古いTCP状態が残っていないか確認する
NFSクライアントからの再送をキャプチャし、フェイルオーバー前後の次のホップを比較します。
セッションがリセットされるまでTCP再送が続いた事例に関する、焦点を絞ったパケットレベルのトラブルシューティング事例は、基礎プロトコルの定義だけでなく同じ細かな問題を扱っているため、この分岐の切り分けに役立ちます。
パケットが新しい経路を通っているにもかかわらず古い接続が回復しない場合は、スタックしたクライアント状態を安全に解放してから、新しいマウントをテストします。
フェイルオーバー後のルートとトランスポートの違いを確認する
ルーターの切り替え前後で、送信元IP、ゲートウェイ、インターフェース、パスMTUを比較します。
サーバーの到達性とトランスポートの問題に関する、焦点を絞った実用的なNFSトラブルシューティングガイドは、基礎プロトコルの定義だけでなく同じ細かな問題を扱っているため、この分岐の切り分けに役立ちます。
フェイルオーバーによって送信元サブネットやMTUが変わる場合、NASのダッシュボードにアクセスできても、ファイアウォールとエクスポートの設定を調整する必要があることがあります。
ホームサーバーを再起動せずにスタックしたマウントを解放する
マウントを使用しているアプリケーションを停止し、ブロックされているプロセスを特定します。通常のアンマウントが完了しない場合に限り、制御された遅延アンマウントまたは強制アンマウントを使用します。
再起動せずにスタックしたNFSマウントを解放する方法に関する、焦点を絞ったLinuxトラブルシューティング記事は、基礎プロトコルの定義だけでなく同じ細かな問題を扱っているため、この分岐の切り分けに役立ちます。
最初の対応としてNASを強制終了したり、マウントディレクトリを削除したりしないでください。どのリクエストがスタックしたのかを示すログを保存します。
重要度の低いリモート共有にはオートマウントを使用する
メディアや補助的なバックアップパスには、必要なときだけマウントする方式を検討します。ルーター経路の障害によって、関係のない起動処理やサービスの開始までブロックされるのを防げます。
x-systemd.automountで初回アクセス時にNFSをマウントする方法に関する、焦点を絞った実用的なLinuxチュートリアルは、基礎プロトコルの定義だけでなく同じ細かな問題を扱っているため、この分岐の切り分けに役立ちます。
2回のフェイルオーバーサイクル後に再テストします。期待される結果は、セッションが正常に回復するか、制限時間内に再マウントされることであり、システム全体がハングすることではありません。
ホームサーバーの実際の経路を再テストする
1つの変数を変更した後は、別の経路を使う可能性のある異なるテストへ切り替えず、同じクライアントから同じNASまたはセルフホスト環境のワークフローを繰り返します。
関連するホームサーバーのネットワーク経路についてのZimaSpaceガイドは、最終確認を同じセルフホスト環境に結び付けるのに役立ちます。
再接続、サービスの再起動、そして2回目の制御された転送またはリクエストの後も元の症状が解消されたままであることを確認して、初めて修正完了となります。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
