SMBアクセスを壊さずにホームNASでジャンボフレームをテストする方法
検証済みの1500-MTUルートを維持しながら、隔離されたNAS経路の一つでジャンボフレームをテストします。
ホームネットワークでは、SMBアクセスがクライアントNIC、スイッチポート、VLAN、ブリッジ、仮想スイッチ、NASインターフェース、またはルータ経路を横断し、それぞれが同じフレーム制限を共有していない場合があります。したがって、安全な目標は単に2台のデバイスでMTUを9000に設定することではなく、動作する管理経路を保持し、テスト経路全体を両方向で検証し、変更前後で同じSMBワークロードを比較し、MTUの不一致を示す証拠があれば即座にロールバックすることです。
既知の良好な1500-MTUベースラインを記録する
NAS、テストクライアント、スイッチを現在の標準MTUで開始し、SMB共有がマウント、ブラウズ、読み取り、書き込み、再接続、通常のクライアント再起動に耐えられることを確認します。このベースラインは、推測なしに再現できなければならない回復状態です。
大きなMTUはパケット効率を変えるだけで、ストレージ、CPU、SMB、クライアントの制限を取り除くわけではありません。ZimaSpaceのジャンボフレームがNAS転送を改善しない理由の説明は、接続性のベースラインとワークロードのベースラインの両方が安全なテストに必要であるため、ここで役立ちます。
現在のインターフェースMTU、IPアドレス、VLAN、ブリッジメンバーシップ、SMBパス、測定された転送結果を保存します。また、MTU1500のままの別のデバイスからNASに到達できることを確認するか、唯一の管理インターフェースを変更する前にローカルコンソールアクセスを手配してください。
正確なSMBテスト経路のすべてのホップをマッピングする
選択したクライアントが実際にNASに到達するために使用する経路を描きます。物理スイッチポート、LAGまたはブリッジインターフェース、VLANサブインターフェース、ハイパーバイザースイッチ、USBイーサネットアダプター、ルーターインターフェース、およびSMBエンドポイントに関与するコンテナや仮想マシンのネットワーク層を含めます。
ジャンボ通信はエンドツーエンドのフレームサポートが必要です。なぜなら、レイヤー2デバイスが大きなフレームを転送できない場合、サイズ変更するのではなく破棄する可能性があるためです。したがって、経路上でサポートされる最小のポイントが使用可能なパケットサイズを定義します。
各ホップを確認済み、未知、またはテスト外としてマークします。隠れたブリッジ、スイッチポート、VLAN、またはルーティング境界が未知のままの場合はジャンボフレームを有効にせず、まず経路を簡素化するか、そのコンポーネントを標準MTU側に置いてください。
一つのテストエンドポイントの前にインフラを変更する
まずスイッチまたは隔離されたストレージVLANの最大フレーム許容量を増やします。スイッチの制限を上げると通常、他のデバイスに大きなフレーム送信を強制せずに大きなフレームを許可します。次にNASのテストインターフェースと1台のクライアントのみを変更し、他のクライアントと回復経路はそのままにします。
スイッチはMTU設定を異なる方法で実装しています。グローバル最大値を使うもの、個別インターフェースを設定するもの、ルーティングとスイッチングMTUを別々に扱うものがあります。あるインターフェースに表示される数値は別のデバイスの値と異なるレイヤーを示す場合もあります。
一度に一つの変更を適用し、記録してください。NASにインターフェースが1つしかない場合は、ロールバック方法なしにリモートで変更を始めないでください。メンテナンスウィンドウ、2つ目のNIC、直接コンソール、または独立して削除可能なテストVLANを使用してください。
SMBを開く前に両方向でパケットサイズを検証する
まず通常の小さなpingを繰り返して基本的な到達性を確認し、次に断片化を無効にした大きなパケットを送信します。IPv4 MTU9000の場合、一般的なテストペイロードは8972バイトです。IPとICMPヘッダーが残りの28バイトを使用するためです。
大きなパケットテストをクライアントからNASへ、NASからクライアントへ実行します。一方向の成功だけでは不十分です。非対称なVLAN処理、仮想スイッチ、または異なる戻り経路により、一方向は通るがもう一方は静かに破棄されることがあります。
大きなパケットが失敗した場合は、ペイロードを減らして成功するまで調整し、その上限に一致する設定またはサポートされる最大値を持つホップを特定します。断片化警告、タイムアウト、インターフェースエラーの増加なしに両方向で意図したパケットサイズが繰り返し成功するまでSMBベンチマークを続けないでください。
MTU1500とテストMTUで同じSMBワークロードを比較する
大きなローカルファイル1つ、同じクライアント、同じNAS共有、同じ送受信ストレージ、同じSMBセキュリティ設定を使用します。RAMキャッシュや短い書き込みバーストを超える十分な時間を実行し、スループット、CPU使用率、レイテンシ、再送、共有の正常な再接続を記録します。
実用的なコミュニティのトラブルシューティングパターンは、ジャンボフレームのオン・オフをテストすることであり、すべての速度変化をMTUのせいにしないことです。結果は、大きなパケット経路がクリーンでワークロードが他に変わらない場合にのみ重要です。
単一のピーク数値を受け入れるのではなく、以下の結果マップでA/Bテストを解釈してください：
| 観察された結果 | 考えられる意味 | 次のアクション |
|---|---|---|
| 大きなpingが失敗しSMBが停止する | エンドツーエンドのMTU不一致 | テストエンドポイントをロールバックし各ホップを検査する |
| 大きなpingは成功するがSMBが遅くなる | MTUは有効なボトルネックでないか、負荷でエラーが増加している | CPU、ストレージ、再送、インターフェースカウンターを確認する |
| SMBが安定したレイテンシとエラーなしで改善する | テストしたワークロードがこの正確な経路で恩恵を受けている | 通常のクライアントと回復テストで繰り返し、広範囲展開前に確認する |
| 実質的な変化なし | 標準フレームで既にワークロードを満たしている | 他の測定されたワークロードが恩恵を受けない限りMTU1500を維持する |
最初の接続性またはエラー境界でロールバックする
SMBマウントが不安定になる、大きなパケットがどちらかの方向で失敗する、再送やCRCエラーが増加する、通常のクライアントがアクセスを失う、またはテストで繰り返し可能なワークロードの利点が得られない場合はロールバックが必要です。ジャンボフレームテストは単に1つのベンチマークが完了しただけでは成功とは言えません。
まずテストクライアントをMTU1500に戻し、既知の良好な経路を通じて通信できるようにし、必要に応じてNASテストインターフェースを元に戻します。標準MTUのSMBアクセス、ブラウズ、書き込み、再接続動作が再度確認されてからテストVLANやスイッチのオーバーライドを削除してください。
選択した経路全体が文書化され、ロールバック経路が利用可能で、実際のNASワークロードがレイテンシや互換性を損なうことなく改善される場合にのみジャンボフレームを維持してください。そうでなければ、テストの正しい結果はMTU1500を維持し、運用コストに見合わない機能の調整を続けないことです。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
