なぜジャンボフレームは高速なNAS転送なしに複雑さを増すのか？

ジャンボフレームは、同じデータを運ぶために必要なイーサネットフレームの数を減らすだけであり、NAS転送を速くするわけではないため、複雑さを増すことがあります。交渉されたリンク速度を上げたり、NASのディスク、ファイルシステム、SMBスタック、クライアントストレージ、CPU、PCIe経路、スイッチファブリックの制限を取り除くことはありません。

この変更にはエンドツーエンドの要件もあります。選択された経路上のすべてのインターフェースと転送機器が一貫して大きなフレームサイズを処理できなければなりません。したがって、小さな効率向上ははるかに大きな設定およびトラブルシューティングの範囲を伴うことがあります。

大きなMTUは実際に何を減らすのか？

標準的なイーサネットは一般的に1500バイトのIP MTUを使用しますが、ストレージネットワークでは9000バイト前後の値がよく使われます。大きなフレームは転送あたりのパケット数を減らします。これにより、大きなデータセットを移動する際のヘッダー数やパケット処理イベントの数が減少します。

利点は効率性であり、新たな物理的帯域幅ではありません。10GbEリンクは10GbEリンクのままですが、ネットワークスタックがすでにその作業を結合またはオフロードできない場合、ホストは同じペイロードの処理にかかるCPUサイクルや割り込みを減らせるかもしれません。

効果が最も重要になるのは、高いパケットレートで持続的に大きなブロックのトラフィックがある場合です。小さなファイル、ディレクトリ操作、メタデータの検索、アプリケーションの往復通信、ランダムなストレージI/Oは、MTUが大きくなったからといって単に連続した大量転送になるわけではありません。

なぜプロトコルのオーバーヘッドが小さくなってもNAS転送が速くならないのか？

NASのコピー速度は最も遅いアクティブな段階の速度で決まるため、フレームのオーバーヘッドが小さくなっても他のボトルネックは解消されません。HDDプール、暗号化プロセス、SMB署名経路、クライアントSSD、または2.5GbEインターフェースがすでに飽和している場合、パケットのオーバーヘッドを削減してもエンドツーエンドのスループットは向上しません。

現代のファイル転送は大きなTCPウィンドウ、非同期I/O、SMBクレジット、キャッシュ、および複数の未処理リクエストも使用します。これらの仕組みは、パケット処理を制限資源にせずに標準MTUリンクをすでに忙しく保つことができます。

ジャンボフレームを有効にしてベンチマークが改善した場合、それはテストされたパスがそのワークロードで恩恵を受けたことを示します。しかし、すべてのNAS操作、クライアント、ファイルサイズ、プロトコル、または同時ワークロードが同じ割合で改善することを証明するものではありません。

なぜすべてのデバイスが同じエンドツーエンドMTUをサポートしなければならないのか？

ジャンボフレームはクライアントNIC、仮想スイッチまたはブリッジ、物理スイッチポート、VLAN、NAS NIC、および選択されたパスのルーティング境界を通過しなければなりません。すべてのデバイスが同じMTUをサポートする必要があります。そうでなければ、パスにフレームを変更せずに転送できない小さいポイントが含まれています。

設定された数値は異なるレイヤーを示すこともあります。あるインターフェースはIP MTUを示し、別のものは最大レイヤー2フレームサイズを広告し、スイッチはVLANタグやカプセル化のための追加の余裕を必要とすることがあります。

ホームサーバーは隠れたパス要素を追加します：コンテナブリッジ、ハイパーバイザのvSwitch、LAGインターフェース、VPNトンネル、USB NIC、Wi-Fiブリッジ、管理ネットワーク。転送は図や単一スイッチの構成より多くのコンポーネントを通過することがあります。

パスMTUが送信者の期待より小さい場合に何が起こるのか？

送信者がパスのセグメントより大きなパケットを送信すると、ネットワークはそれを分割するか、より小さい制限を報告するか、破棄しなければなりません。MTUの不一致は、大きな転送を停止させることがありますが、小さなパケットや基本的な管理接続は引き続き動作します。

小さなping、ARP、DNS、および基本的な管理ページは動作することがありますが、大きなファイル転送が停止したりリセットされたりすることがあります。これにより、問題がSMB、NASアプリケーション、またはドライブにあるように見えますが、実際の障害はパケットサイズの境界で発生しています。

パスMTUディスカバリーは、制御メッセージが送信者に届くことに依存しています。これらのメッセージをフィルタリングしたり、IPv4のフラグメンテーション動作とIPv6のルーターによるフラグメンテーション禁止ルールを混在させると、単にリンクがダウンしているよりも診断が難しいブラックホール症状を引き起こすことがあります。

なぜ最新のオフロードは利点を縮小するのか？

ネットワークスタックは大きなバッファをNICに渡し、ハードウェアが後で分割または結合することを許可します。最新のオフロードはパケットごとのCPUコストを削減します。そのため、イーサネットが標準フレームを使用していても、OSはより少ない大きなソフトウェアオブジェクトを処理する場合があります。

TSO、GSO、GRO、LRO、チェックサムオフロード、RSS、およびマルチキューNICはパケット処理を分散または回避します。これらの機能はOS、ドライバー、仮想スイッチ、ワークロードによって異なりますが、1500バイトのフレーミングだけがCPUのボトルネックになる可能性を減らします。

ジャンボフレームは、特に古いまたはCPU制限のあるハードウェアで飽和した高速ストレージ経路において依然として役立ちます。正しいテストは、MTU変更前後のCPU使用率、パケット毎秒数、スループット、およびアプリケーションの遅延であり、大きなフレームが必ずしも高速であるという仮定ではありません。

ジャンボフレームの追加の複雑さはいつ価値があるのか？

ジャンボフレームは、既知のスイッチ、固定クライアント、高い持続スループット、および測定されたパケット処理限界を持つ制御されたストレージネットワークで最も効果的です。ジャンボフレームは制御されたストレージネットワークに適しています。未知のデバイスや経路が混在する家庭用LANには適していません。

ネットワークに管理されていないデバイス、Wi-Fiブリッジ、VPN、複数のVLANゲートウェイ、または一貫して設定・テストできないクライアントが含まれる場合は、MTUを1500のままにしてください。標準のMTUはサポートが容易であり、1GbE、2.5GbE、多くの10GbE NASのワークロードを十分に満たすことが多いです。

ネットワーク速度は完全なストレージ経路に合わせるべきです。まず安定した標準MTUの基準を確立し、パケット処理のオーバーヘッドがストレージやプロトコルの挙動に代わる制約であると測定で示された場合にのみジャンボフレームを有効にしてください。

よくある質問

ジャンボフレームはイーサネットのリンク速度を上げるか？

いいえ。ジャンボフレームは1フレームあたりのペイロードを増やし、フレームごとのオーバーヘッドを減らしますが、物理インターフェースの速度は交渉された速度のままです。

すべてのホームネットワーク機器がMTU 9000を使う必要があるか？

ジャンボフレーム経路上のデバイスのみが必要なフレームサイズをサポートすればよいです。標準MTUとジャンボフレームのネットワークを分けることは可能ですが、ルーティングや仮想境界は慎重に設計・テストする必要があります。

ジャンボフレームは小さなファイルの速度を速くできるか？

通常は大きな差はありません。小さなファイルの性能は、フレーム数よりもオープン・クローズ、メタデータ、往復回数、権限、ファイルシステムの挙動、ストレージの遅延に左右されます。

なぜpingは通るのにNASのコピーは失敗するのか？

通常のpingは小さいパケットです。経路のMTU不一致は大きなパケットにのみ影響するため、管理トラフィックは成功しても大量のTCP転送が停止またはリセットされることがあります。

最終的な結論

ジャンボフレームはパケット効率を最適化しますが、NASのすべてのレイヤーの性能を向上させるわけではありません。パケットごとの処理が実際のボトルネックであり、経路全体が一貫したMTUをサポートしている場合にのみ効果があります。混在したホームネットワークでは、標準フレームの方が故障モードが少なく、テストが簡単でクライアントの互換性も高いため、実際の転送速度は同等であることが多いです。