web-dev-qa-db-ja.com

iperf3を使用してネットワーク全体で再送信が発生するのはなぜですか？

設定しているkubernetesクラスター内の2つのポッド間で再送信が発生しています。ホスト間のネットワークにkube-router https://github.com/cloudnativelabs/kube-router を使用しています。設定は次のとおりです。

Host-aとHost-bは同じスイッチに接続されています。それらは同じL2ネットワーク上にあります。両方ともLACP802.3adボンドで上記のスイッチに接続されており、これらのボンドは正常に機能しています。

pod-aとpod-bは、それぞれHost-aとHost-bにあります。ポッド間でiperf3を実行していて、再送信を確認しています。

root@pod-b:~# iperf3 -c 10.1.1.4
Connecting to Host 10.1.1.4, port 5201
[  4] local 10.1.2.5 port 55482 connected to 10.1.1.4 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  1.15 GBytes  9.86 Gbits/sec  977   3.03 MBytes
[  4]   1.00-2.00   sec  1.15 GBytes  9.89 Gbits/sec  189   3.03 MBytes
[  4]   2.00-3.00   sec  1.15 GBytes  9.90 Gbits/sec   37   3.03 MBytes
[  4]   3.00-4.00   sec  1.15 GBytes  9.89 Gbits/sec  181   3.03 MBytes
[  4]   4.00-5.00   sec  1.15 GBytes  9.90 Gbits/sec    0   3.03 MBytes
[  4]   5.00-6.00   sec  1.15 GBytes  9.90 Gbits/sec    0   3.03 MBytes
[  4]   6.00-7.00   sec  1.15 GBytes  9.88 Gbits/sec  305   3.03 MBytes
[  4]   7.00-8.00   sec  1.15 GBytes  9.90 Gbits/sec   15   3.03 MBytes
[  4]   8.00-9.00   sec  1.15 GBytes  9.89 Gbits/sec  126   3.03 MBytes
[  4]   9.00-10.00  sec  1.15 GBytes  9.86 Gbits/sec  518   2.88 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  11.5 GBytes  9.89 Gbits/sec  2348             sender
[  4]   0.00-10.00  sec  11.5 GBytes  9.88 Gbits/sec                  receiver

iperf Done.

ここでデバッグしようとしている問題は、同じiperf3をHost-aとHost-bで直接（kube-routerが作成するブリッジインターフェイスではなく）実行したときに再送信が表示されないことです。したがって、ネットワークパスは次のようになります。

pod-a -> kube-bridge -> Host-a -> L2 switch -> Host-b -> kube-bridge -> pod-b

方程式からkube-bridgeを削除すると、再送信はゼロになります。 Host-aからpod-bをテストし、同じ再送信を確認しました。

私はdropwatchを実行していて、receiveingホスト（デフォルトではiperf3サーバー）で次のことを確認しています。

% dropwatch -l kas
Initalizing kallsyms db
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring
2 drops at ip_rcv_finish+1f3 (0xffffffff87522253)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
1 drops at __brk_limit+35f81ba4 (0xffffffffc0761ba4)
16991 drops at skb_release_data+9e (0xffffffff874c6a4e)
1 drops at tcp_v4_do_rcv+87 (0xffffffff87547ef7)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
2 drops at ip_rcv_finish+1f3 (0xffffffff87522253)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
3 drops at skb_release_data+9e (0xffffffff874c6a4e)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
16091 drops at skb_release_data+9e (0xffffffff874c6a4e)
1 drops at __brk_limit+35f81ba4 (0xffffffffc0761ba4)
1 drops at tcp_v4_do_rcv+87 (0xffffffff87547ef7)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
2 drops at skb_release_data+9e (0xffffffff874c6a4e)
8463 drops at skb_release_data+9e (0xffffffff874c6a4e)
2 drops at skb_release_data+9e (0xffffffff874c6a4e)
2 drops at skb_release_data+9e (0xffffffff874c6a4e)
2 drops at tcp_v4_do_rcv+87 (0xffffffff87547ef7)
2 drops at ip_rcv_finish+1f3 (0xffffffff87522253)
2 drops at skb_release_data+9e (0xffffffff874c6a4e)
15857 drops at skb_release_data+9e (0xffffffff874c6a4e)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
1 drops at __brk_limit+35f81ba4 (0xffffffffc0761ba4)
7111 drops at skb_release_data+9e (0xffffffff874c6a4e)
9037 drops at skb_release_data+9e (0xffffffff874c6a4e)

送信側では低下が見られますが、ここで見られる量には何もありません（出力の行ごとに最大1〜2、これは正常であると思います）。

また、9000 MTUを使用しています（スイッチへのbond0インターフェイスとブリッジで）。

CoreOS Container Linux Stable1632.3.0を実行しています。 Linuxホスト名4.14.19-coreos＃1 SMP Wed Feb 14 03:18:05 UTC 2018 x86_64 GNU/Linux

任意のヘルプやポインタをいただければ幸いです。

update：1500 MTUで試行しましたが、同じ結果です。重要な再送信。

update2：は、iperf3 -b 10G ...がポッド間およびホスト上で直接問題を引き起こさないようです（2x 10Gbit NIC in LACPボンド）。ポッド間でiperf3 -b 11Gを使用するが、ホスト間ではnotを使用すると、問題が発生します。iperf3はNICサイズについて賢いですかしかし、地元の橋渡しされたvethにはできませんか？

linuxnetworkingdockerbridge
1
dlamotte

何か（NICまたはカーネル？）がbond0インターフェイスに出力されるときに、トラフィックの速度が低下しているようです。 Linuxブリッジ（ポッド）の場合、「NIC」は単にvethであり、（私がテストしたとき）47Gbps付近でピークに達しました。したがって、iperf3がbond0インターフェイスからパケットを送信するように要求されると、インターフェイスをオーバーランし、パケットがドロップされてしまいます（受信ホストでドロップが発生する理由は不明です）。

tc qdiscクラスを適用してポッドインターフェイスを10gbpsに遅くしても、他のポッドに対してiperf3を実行するだけでは損失がないことを確認しました。

tc qdisc add dev eth0 root handle 1:0 htb default 10
tc class add dev eth0 parent 1:0 classid 1:10 htb rate 10Gbit

これは、帯域幅設定なしで実行されたiperf3が、NICのオーバーランによって再送信されないようにするのに十分でした。 NIC with tcで出力されるフローを遅くする方法を探しています。

pdate：ローカルブリッジサブネット以外のすべてのトラフィックを遅くする方法は次のとおりです。

tc qdisc add dev eth0 root handle 1:0 htb default 10
tc class add dev eth0 classid 1:5 htb rate 80Gbit
tc class add dev eth0 classid 1:10 htb rate 10Gbit
tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 10.81.18.4/24 classid 1:5
0
dlamotte

kube-routerの作者はこちら。 Kube-routerは、BridgeCNIプラグインを使用してkube-bridgeを作成します。その標準的なLinuxネットワークは、ポッドネットワーク用に特別に調整されたものは何もありません。 kube-bridgeはデフォルト値の1500に設定されています。いくつかの適切な値に設定するための未解決のバグがあります。

https://github.com/cloudnativelabs/kube-router/issues/165

表示されるエラーはMTUが少ないことが原因だと思いますか？

1
Murali-Reddy

one TCP接続が20Gbのボンディングされたインターフェイスで10Gbを超えることはできません。ここで、iperf3 -P 2を実行すると、合計で動作する可能性があります。 20Gb、両方のホストの/sys/class/net/bond0/bonding/xmit_hash_policyの設定に応じて-デフォルトはlayer2+3ですが、layer3+4（src/dst ip/portのハッシュ）に設定すると、ボンドのフルスピードまで2つのNIC間でロードします。

私は同様の問題でこの投稿に出くわしましたが、異なるサブネット内の10Gb * 2結合ホスト間で合計20Gb未満の未満の2+並列ストリームでiperfsを実行するとドロップが発生します...ジュニパー問題を再現しましたが、まだ良い答えはありません:(彼らがそれを理解できない場合は、おそらくLinuxQoSが次のステップです。

0
GraemeD