Почему я вижу повторные передачи по сети с использованием iperf3?
Я вижу повторные передачи между двумя модулями в кластере kubernetes, который я настраиваю. Я использую kube-маршрутизатор https://github.com/cloudnativelabs/kube-router для взаимодействия между хостами. Вот настройки:
host-a и host-b подключены к одним и тем же коммутаторам. Они находятся в одной сети L2. Оба подключены к вышеупомянутым коммутаторам с помощью связей LACP 802.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
Удаление кубического моста из уравнения приводит к нулевым повторным передачам. Я проверил хост-a для pod-b и видел те же повторные передачи.
Я запускаю dropwatch и вижу следующее на принимающем хосте (по умолчанию сервер 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 Stable 1632.3.0. Имя хоста Linux 4.14.19-coreos #1 SMP Ср. 14 февраля 03:18:05 UTC 2018 x86_64 GNU/Linux
Любая помощь или указатели будут высоко ценится.
обновление: пробовал с 1500 MTU, тот же результат. Значительные ретрансляции.
update2: кажется, что iperf3 -b 10G ... не дает проблем между модулями и непосредственно на хосте (2x 10 Гбит NIC в LACP Bond). Проблемы возникают при использовании iperf3 -b 11G между стручками, но не между хозяевами. Является ли iperf3 умным в отношении размера сетевой карты, но не может использовать локальный мост?
3 ответа
Похоже, что что-то (NIC или ядро?) Замедляет трафик при его выводе на bond0 интерфейс. В случае linux bridge (pod) "NIC" - это просто ветеран, который (когда я тестировал мой) достиг пика около 47 Гбит / с. Поэтому, когда iperf3 просят отправить пакеты bond0 Интерфейс, он переполняет интерфейс и заканчивается отброшенными пакетами (неясно, почему мы видим отбрасывание на принимающем хосте).
Я подтвердил, что если я подам заявление tc Класс qdisc для замедления интерфейса модуля до 10 Гбит / с, без потерь при простом запуске 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 с tc,
Обновление: Вот как можно замедлить трафик для всех, кроме локальной подсети с мостовым соединением.
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
Автор кубе-роутера здесь. Kube-router использует плагин Bridge CNI для создания kube-bridge. Его стандартная сеть linux ничего специально не настроила для работы в сети. Для kube-bridge установлено значение по умолчанию, равное 1500. У нас есть открытая ошибка для установки некоторого разумного значения.
https://github.com/cloudnativelabs/kube-router/issues/165
Как вы думаете, ошибки видны из-за меньшего MTU?
Нельзя, чтобы одно TCP-соединение превышало 10 ГБ с интерфейсом 20 ГБ. Теперь, если вы сделали iperf3 -P 2 это может работать в общей сложности 20 Гб, в зависимости от настройки /sys/class/net/bond0/bonding/xmit_hash_policy на обоих хостах - по умолчанию layer2+3, но если вы установите его layer3+4 (хэш на src/dst ip/port) должен распределить нагрузку между двумя сетевыми картами до полной скорости вашего соединения.
Я наткнулся на этот пост с похожей проблемой, но у меня возникают падения, когда я запускаю iperfs с 2+ параллельными потоками общим объемом менее 20 ГБ между 10 ГБ *2 связанными хостами в разных подсетях... Juniper повторил проблему, но не ' У меня пока нет хороших ответов:(Если они не могут понять это, возможно, Linux QoS - следующий шаг.