スマートスイッチにリンク集約グループ（LAG）が設定されている場合、帯域幅のリンク集約（結合）が機能しない
私の質問は、スマートスイッチでリンク集約グループを設定すると、2つのマシン間の帯域幅が低下するのはなぜですか？
TP-LINK T1700X-16TSスマートスイッチを介して2つのボンディングされた10G CAT7ケーブルで接続された2台のマシン（ubuntu 18.04サーバーを実行するサーバー）間のスループット（帯域幅）が高まりました。ケーブルは、PCI-E x8に差し込まれている各マシン（各カードに2つのRJ45ポートがある）の単一のIntel X550-T2 NIC=）に接続されています。
最初に行ったのは、スイッチの構成で作成して、各マシンが接続されている2つのポートを含む静的LAGグループを作成しました。これが私の最初の間違いでした。
各ボックスで、インテルX550-T2カードの2つのポートを含むボンドを作成しました。私はnetplan（およびnetworkd）を使用しています。例えば。：
network:
ethernets:
ens11f0:
dhcp4: no
optional: true
ens11f1:
dhcp4: no
optional: true
bonds:
bond0:
mtu: 9000 #1500
dhcp4: no
interfaces: [ens11f0,ens11f1]
addresses: [192.168.0.10/24]
parameters:
mode: balance-rr
transmit-hash-policy: layer3+4 #REV: only good for xor ?
mii-monitor-interval: 1
packets-per-slave: 1
9000バイトのMTU（ジャンボパケット用）とbalance-rrに注意してください。
これらの設定があれば、iperf（iperf3）を使用してマシン間の帯域幅をテストできます。
iperf3 -s (on machine1)
iperf3 -c machine1 (on machine2)
1秒あたり9.9ギガビットのようなものを取得します（単一の10G接続の理論上の最大値に非常に近い）
でも何かがおかしい。私はラウンドロビンを使用していて、（理論的には）マシン間に2つの10Gケーブルがあります。 20Gの帯域幅が得られるはずですよね？
違う。
奇妙なことに、次にスマートスイッチからLAGグループを削除しました。これで、Linux側でインターフェースを結合しましたが、スイッチには結合がありません（LAGがありません）。
ここで再びiperf3を実行します。
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.77 GBytes 15.2 Gbits/sec 540 952 KBytes
[ 4] 1.00-2.00 sec 1.79 GBytes 15.4 Gbits/sec 758 865 KBytes
[ 4] 2.00-3.00 sec 1.84 GBytes 15.8 Gbits/sec 736 454 KBytes
[ 4] 3.00-4.00 sec 1.82 GBytes 15.7 Gbits/sec 782 507 KBytes
[ 4] 4.00-5.00 sec 1.82 GBytes 15.6 Gbits/sec 582 1.19 MBytes
[ 4] 5.00-6.00 sec 1.79 GBytes 15.4 Gbits/sec 773 708 KBytes
[ 4] 6.00-7.00 sec 1.84 GBytes 15.8 Gbits/sec 667 1.23 MBytes
[ 4] 7.00-8.00 sec 1.77 GBytes 15.2 Gbits/sec 563 585 KBytes
[ 4] 8.00-9.00 sec 1.75 GBytes 15.0 Gbits/sec 407 839 KBytes
[ 4] 9.00-10.00 sec 1.75 GBytes 15.0 Gbits/sec 438 786 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 17.9 GBytes 15.4 Gbits/sec 6246 sender
[ 4] 0.00-10.00 sec 17.9 GBytes 15.4 Gbits/sec receiver
ええと、今私は15.4 Gビット/秒（時には16.0まで）を取得します。
再送は私を心配しました（LAGをセットアップしたときにゼロになりました）が、今は少なくともいくつかの利点を得ています。
ジャンボパケットを無効にするか、MTUを1500に設定すると、約4〜5 Gbpsしか得られないことに注意してください。
代わりにリンクアグリゲーショングループをスマートスイッチに設定することで（私はこれは役立つと思いました）、パフォーマンスを制限する理由を知っていますか？一方、それらを設定しないと（正しく言えば、お金を節約でき、管理されていないスイッチを購入した可能性があります）、正しくルーティングされるパケットをさらに送信できますか？
スイッチのLAGグループのポイントは何ですか？私はどこか間違ったことをしていますか？なるべく16Gbps以上の帯域を増やしたいです。
edit
以下の私のコメントからのコピー（更新）：
私は、nc（netcat）を使用して60 GBのファイルをあるシステムのRAMディスクから別のシステムにコピーして、ボンディング接続で11Gbps（1.25 GiB /秒）の実際のアプリケーションを検証しました。ハッシュを使用してファイルの整合性を確認しました。これは、両側で同じファイルです。
一度に10Gポートの1つだけを使用して（またはbalance-xorなどを使用して結合して）、1.15 GiB /秒（約9.9 Gbps）を取得します。 iperfとncはどちらもデフォルトでTCP接続を使用します。これをローカルマシンに（ループバック経由で）コピーすると、速度は1.5 GiB /秒になります。スイッチのポート使用状況を見ると、おおよそのことがわかります送信側のTx側での使用量は等しく（iperfの場合は70％、ncファイルのコピーの場合は〜55％）、Rx側の2つの結合ポート間の使用量は等しくなります。
したがって、現在のセットアップ（balance-rr、MTU 9000、LAGグループがスイッチで定義されていない）では、10Gbpsを超える速度を達成できますが、ほとんど達成できません。
奇妙なことに、スイッチでLAGグループを定義すると、すべてが壊れます（iperfとファイル転送で0バイトが送信されるようになりました）。おそらく、新しい切り替え状況を把握するのに時間がかかるだけですが、何度も再実行し、スイッチを何度か再起動/リセットしました。それがなぜなのか、私にはわかりません。
編集2
Kernel.orgのドキュメントで実際にストライピングとバランスrrが単一ポートより高い帯域幅を許可することに言及しました。
https://www.kernel.org/doc/Documentation/networking/bonding.txt
具体的には
12.1.1 MT単一スイッチトポロジのボンディングモードの選択
この構成は、セットアップと理解が最も簡単ですが、ニーズに最適な結合モードを決定する必要があります。各モードのトレードオフは以下のとおりです。
balance-rr：このモードは、単一のTCP/IP接続が複数のインターフェース間でトラフィックをストライプ化できる唯一のモードです。したがって、これは、単一のTCP/IPストリームが複数のインターフェースに相当するスループットを利用できる唯一のモードです。ただし、これにはコストがかかります。一般に、ストライピングの結果、ピアシステムが順不同でパケットを受信し、セグメントを再送信することにより、TCP/IPの輻輳制御システムが作動します。
Net.ipv4.tcp_reordering sysctlパラメータを変更することにより、TCP/IPの輻輳制限を調整することが可能です。通常のデフォルト値は3ですが、TCPスタックは、並べ替えを検出すると、自動的にこれを増やすことができます。
順不同で配信されるパケットの割合は非常に変動しやすく、ゼロになる可能性が低いことに注意してください。並べ替えのレベルは、ネットワークインターフェイス、スイッチ、構成のトポロジなど、さまざまな要因によって異なります。一般的に言えば、高速ネットワークカードはより多くの並べ替えを生成し（パケットの結合などの要因により）、「多対多」トポロジは「多低速から1高速」構成よりも高速で並べ替えます。
多くのスイッチは、トラフィックをストライプ化するモードをサポートしていません（代わりに、IPまたはMACレベルのアドレスに基づいてポートを選択しています）。これらのデバイスの場合、スイッチを介してbalance-rrボンドに流れる特定の接続のトラフィックは、1つのインターフェースに相当する帯域幅を超えて使用しません。
たとえば、TCP/IP、UDP以外のプロトコルを使用していて、アプリケーションが順不同の配信を許容できる場合、このモードでは、インターフェースがボンドに追加されると、ほぼ線形にスケーリングする単一ストリームのデータグラムパフォーマンスが可能になります。
このモードでは、スイッチに「etherchannel」または「trunking」用に構成された適切なポートが必要です。
したがって、理論的には、balance-rr willは、単一のストライプ化を許可しますTCP接続のパケット。ただし、それらは順不同で到着する場合があります。
ただし、ほとんどのスイッチはストライピングをサポートしていないと記載されています。これは私のスイッチの場合のようです。実際のファイル転送中にトラフィックを監視すると、Rxパケット（つまり、sending_machine-> switch）が両方の結合ポートに均等に分散して到着します。ただし、Txパケット（switch-> receiveing_machine）は、ポートの1つだけを介して送信されます（90％以上の飽和を達成します）。
スイッチでリンクアグリゲーショングループを明示的に設定しないことで、より高いスループットを達成できますが、受信側のマシンがスイッチに1つのポートに送信し、次に別のポートに送信するように指示する方法などはわかりません。
結論：
スイッチリンクアグリゲーショングループは、パケット送信のラウンドロビン（ポートストライピング）をサポートしていません。したがって、それらを無視すると、スループットが高くなりますが、メモリ（ramdisk）への実際の書き込みは、メモリ、CPU処理、またはパケットの並べ替えの飽和点に達するようです。
並べ替えを増やしたり減らしたり、sysctlを使用してTCPのメモリバッファの読み取りと書き込みを行いましたが、パフォーマンスに変化はありませんでした。
Sudo sysctl -w net.ipv4.tcp_reordering=50
Sudo sysctl -w net.ipv4.tcp_max_reordering=1000
Sudo sysctl -w net.core.rmem_default=800000000
Sudo sysctl -w net.core.wmem_default=800000000
Sudo sysctl -w net.core.rmem_max=800000000
Sudo sysctl -w net.core.wmem_max=800000000
Sudo sysctl -w net.ipv4.tcp_rmem=800000000
Sudo sysctl -w net.ipv4.tcp_wmem=800000000
私が気づく唯一のパフォーマンスの変化は、以下のマシン間です。
1）より強力なプロセッサ（わずかに高いシングルコアクロック、L3キャッシュは問題ではありません）
2）より速いメモリ？ （または同じ容量のメモリの場合はDIMMを少なくしてください）
これは、バス、CPU、またはメモリの読み取り/書き込みを実行していることを意味しているようです。ラムディスク内でローカルに単純な「コピー」を行うと（例：dd if = file1 of = file2 bs = 1M）、最適速度は2.6 GHzで約2.3GiB /秒、2.4Ghzで2.2GiB /秒、オンで2.0GiB /秒になります。 2.2 GHz。さらに、2番目のメモリはメモリが低速ですが、問題ではないようです。
すべてTCP低速マシンから2.6 Ghzラムディスクへのコピーは1.15 GiB/s、2.4 Ghzから1.30 GiB/s、最高速マシンから中間マシンへのコピーは1.02 GiB/sになります。 、1.03 GiB/sなどの低速マシン（高速メモリ搭載）など.
最大の影響は、シングルコアCPUと受信側のメモリクロックにあるようです。 BIOS設定を比較していませんが、すべて同じBIOSバージョンを実行しており、同じマザーボード、Ethカードなどを使用しています。CAT7ケーブルまたはスイッチポートを再配置しても効果がないようです。
見つけた
http://louwrentius.com/achieving-340-mbs-network-file-transfers-using-linux-bonding.html
4つの1GbE接続でこれを行うのは誰ですか。個別のVLANを設定しようとしましたが、機能しませんでした（速度は向上しませんでした）。
最後に、同じ方法を使用して自分に送信すると、0.3 GiB-0.45 GiB/secのペナルティが発生するようです。そのため、私の観測値はthatよりも低くなりませんこのメソッドの「理論的な」最大値。
編集3（後世のために情報を追加）
スイッチにbalance-rrとLAGが設定されている場合でも、9.9 Gbpsが表示されているにもかかわらず、LAGがない場合よりもBalance-rrでの再試行が実際に多いことに気づきました。グループでは毎秒平均2500、なしでは平均1000！
ただし、グループが設定されていると、メモリへの実際のファイル転送速度は平均で1.15 GiB/s（9.9 Gbps）になります。マシンごとに1つのポートのみを接続した場合、同じ速度（1.15 GiB/s）で、再試行はほとんどありません。モードをbalance-xorに切り替えると、1.15 GiB/s（9.9 Gbps）になり、再送信されません。つまり、balance-rrモードは、出力をストライプして側を切り替えようとするものであり、これにより、多くの順序が乱れたパケットが発生していると思います。
メモリからメモリへの転送の最大（実際の）パフォーマンスはスイッチLAGとbalance-xorを使用した場合と同じかそれ以上であり、再送信（輻輳）が少ないため、それを使用しています。ただし、最終的な目標はNFSおよびMPI sendであるため、これらの状況でネットワーク速度を飽和および測定する方法を見つける必要があります。これは、MPI接続が実装されています...
最終編集
XORは常に同じ2つのピアの同じポートにハッシュされるため、1つのみを使用するため、balance-rr（スイッチ側にLAGが設定されていない）を使用することに戻りました。 balance-rrを使用して、2つ以上（ramからram）のファイル転送を同時に実行すると、理論上の最大値である20 Gbpsにかなり近い正味18〜19 Gbpsを得ることができます。
最終的な最終編集（数か月使用した後）
スイッチにLAGグループを設定する必要がありました。マシンにSSHで接続できないというエラーが発生したためです。パケットがアドレッシングに使用されるはずの場所でパケットが混乱したためと思います。現在、接続あたりの最大値は10GBPSしかありませんが、安定しています。
最終編集で述べたように、スイッチにリンクアグリゲーショングループが設定されている場合にラウンドロビンボンディングを使用してより高い帯域幅を取得できないのは、スイッチリンクアグリゲーショングループが単一のパケットのラウンドロビンストライピングを行わないためです。 TCP接続ですが、Linuxボンディングはそうです。これはkernel.orgのドキュメントで言及されています：
https://www.kernel.org/doc/Documentation/networking/bonding.txt
12.1.1 MT単一スイッチトポロジのボンディングモードの選択
この構成は、セットアップと理解が最も簡単ですが、ニーズに最適な結合モードを決定する必要があります。各モードのトレードオフは以下のとおりです。
balance-rr：このモードは、単一のTCP/IP接続が複数のインターフェース間でトラフィックをストライプ化できる唯一のモードです。したがって、これは、単一のTCP/IPストリームが複数のインターフェースに相当するスループットを利用できる唯一のモードです。ただし、これにはコストがかかります。一般に、ストライピングの結果、ピアシステムが順不同でパケットを受信し、セグメントを再送信することにより、TCP/IPの輻輳制御システムが作動します。
Net.ipv4.tcp_reordering sysctlパラメータを変更することにより、TCP/IPの輻輳制限を調整することが可能です。通常のデフォルト値は3ですが、TCPスタックは、並べ替えを検出すると、自動的にこれを増やすことができます。
順不同で配信されるパケットの割合は非常に変動しやすく、ゼロになる可能性が低いことに注意してください。並べ替えのレベルは、ネットワークインターフェイス、スイッチ、構成のトポロジなど、さまざまな要因によって異なります。一般的に言えば、高速ネットワークカードはより多くの並べ替えを生成し（パケットの結合などの要因により）、「多対多」トポロジは「多低速から1高速」構成よりも高速で並べ替えます。
多くのスイッチは、トラフィックをストライプ化するモードをサポートしていません（代わりに、IPまたはMACレベルのアドレスに基づいてポートを選択しています）。これらのデバイスの場合、スイッチを介してbalance-rrボンドに流れる特定の接続のトラフィックは、1つのインターフェースに相当する帯域幅を超えて使用しません。
たとえば、TCP/IP、UDP以外のプロトコルを使用していて、アプリケーションが順不同の配信を許容できる場合、このモードでは、インターフェースがボンドに追加されると、ほぼ線形にスケーリングする単一ストリームのデータグラムパフォーマンスが可能になります。
このモードでは、スイッチに「etherchannel」または「trunking」用に構成された適切なポートが必要です。
ポートを「トランキング」用に構成することについての最後の注意は奇妙です。LAGにポートを作成すると、スイッチからのすべての発信Txが単一のポートを通過するためです。 LAGを削除すると、各ポートで半分ずつ送受信されますが、順序が正しくないパケットが原因で、多くの再送信が発生します。ただし、帯域幅はまだ増えています。
あなたの文章には、あなたの考えを少し明確にできると思ういくつかの点があります。
- さりげなく言及しているので、通常のフレームとジャンボフレームを切り替えているので心配です。同じネットワーク/ネットブロックジャンボフレームと通常のフレームを混在させることはできません。ネットワーク全体がジャンボフレームまたは通常のフレームを送信することを意味します。つまり、そのネットワーク内のallインターフェイスを意味します。
- 集約リンクがある場合は、スイッチとシステム側の両方にリンクを配置する必要があります。他の厄介なことが起こる可能性があります。運が良ければ、スイッチはループを検出し、リンクの1つを無効にします。
- 速度が必要な場合は、おそらくロードバランシングではなく、リンク集約が必要です。
- 単一のUDPと主にTCP接続は、特定のしきい値を超えるとあまりスケーリングしません。複数の同時接続をテストする必要があります。
iperfを使用すると、 - これらの速度では、特に割り込み処理など、2つのリンクのリンク集約を処理するときに、他の制限要因にぶつかる可能性があります。
スイッチに関しては、私はTP-LINKをあまり知らないので、スイッチのトピックに入るのはここではトピック外です。あなたがプロとして働いているなら、より難解な機能や高性能ネットワークにより良い結果を得るために、より多くのトップティアのギアを使用するほうがよいという考えを残しておきます。
関連 サーバーがジャンボフレーム（MTU）を使用する必要があるかどうかを知る方法 および関連 ジャンボフレーム-MTU = 9000をVMマシンに設定できますか？
同じVLAN /インターフェイスのグループで9000と1500を混在させる場合：
サーバーが指定の構成で1500バイトを超えるパケットをクライアントに送信する場合、パケットは単にドロップされ、処理されません。これは、フラグメンテーションとは異なります
から serverfault
これを行うときは、NICが個別のネットブロックに存在することを確認してください。 Linuxを使用している場合、パケットはシステムのネットブロックの最初のNIC=を介してルーティングされるため、eth1のMTUが9000であっても、それらのパケットはeth0を介してルーティングされる可能性があります。
ストレージネットワークに個別のVLAN=を設定し、その動作を回避するためにeth1に個別のネットブロックを設定する必要がありました。MTUを9000に増やすと、その特定のシステムがかなり大きなファイルの数。