Por que estou vendo retransmissões pela rede usando iperf3?

Question

Estou vendo retransmissões entre dois pods em um cluster do kubernetes que estou configurando. Estou usando o link do Kube-router para a rede entre os hosts. Aqui está a configuração:

host-a e host-b estão conectados aos mesmos comutadores. Eles estão na mesma rede L2. Ambos estão conectados aos switches acima com ligações LACP 802.3ad e essas ligações estão ativas e funcionando corretamente.

pod-a e pod-b estão em host-a e host-b respectivamente. Estou rodando iperf3 entre os pods e vejo retransmissões.

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.

A captura aqui que estou tentando depurar é que não vejo retransmissões quando executo o mesmo iperf3 em host-a e host-b diretamente (não na interface de ponte criada pelo kube-router). Então, o caminho da rede é algo parecido com isto:

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

Remover a ponte kube da equação resulta em zero retransmissões. Eu testei o host-a para o pod-b e vi as mesmas retransmissões.

Eu tenho executado dropwatch e vendo o seguinte no host que recebe (o servidor iperf3 por padrão):

% 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)

O lado emissor vê quedas, mas nada nas quantias que estamos vendo aqui (1-2 max por linha de saída; o que eu espero que seja normal).

Além disso, estou usando 9000 MTU (na interface bond0 para o switch e na bridge).

Estou executando o CoreOS Container Linux Stable 1632.3.0. Nome do host Linux 4.14.19-coreos # 1 SMP quarta-feira, 14 de fevereiro 03:18:05 UTC 2018 x86_64 GNU / Linux

Qualquer ajuda ou ponteiros seria muito apreciada.

update: tentou com 1500 MTU, mesmo resultado. Retransmissões significativas.

update2: aparece que iperf3 -b 10G ... não gera problemas entre os pods e diretamente no host (2x 10 Gbit NIC no LACP Bond). Os problemas surgem quando usamos iperf3 -b 11G entre os pods, mas não entre os hosts. O iperf3 é inteligente em relação ao tamanho da NIC, mas não consegue no veth local em ponte?

    

Answer 1

Parece que algo (NIC ou kernel?) está reduzindo o tráfego quando está sendo enviado para a interface bond0 . No caso da bridge linux (pod), o "NIC" é simplesmente um veth que (quando eu testei o meu) atingiu um pico em torno de 47Gbps. Então, quando iperf3 é solicitado a enviar pacotes pela interface bond0 , ele sobrecarrega a interface e termina com pacotes descartados (não está claro porque vemos quedas no host de recebimento).

Confirmei que, se eu aplicar uma classe tc qdisc para diminuir a velocidade da interface do pod para 10gbps, não haverá perda quando simplesmente executar iperf3 no outro pod.

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

Isso foi o suficiente para garantir que um iperf3 executado sem uma configuração de largura de banda não incorresse em retransmissões devido ao overrunning da NIC. Estarei procurando uma maneira de diminuir a velocidade de fluxos que sairiam da NIC com tc .

update: Veja como diminuir o tráfego para tudo, exceto a sub-rede com ponte local.

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

    

Answer 2

autor de kube-router aqui. O Kube-router depende do plug-in Bridge CNI para criar a ponte kube. Sua rede linux padrão nada especificamente ajustada para redes de pods. kube-bridge é definida para o valor padrão que é 1500. Temos um bug aberto para definir um valor razoável.

link

Você acha que erros vistos são devidos a menos MTU?

    

Answer 3

Você não pode ter uma conexão TCP um superior a 10 Gb com uma interface de 20 Gb. Agora, se você fez um iperf3 -P 2 , pode funcionar para um total de 20Gb, dependendo da configuração de /sys/class/net/bond0/bonding/xmit_hash_policy em ambos os hosts - o padrão é layer2+3 , mas se você definir como layer3+4 (hash on src / dst ip / port) ele deve distribuir a carga entre as duas NICs até a velocidade máxima do seu título.

Eu tropecei neste post com um problema semelhante, mas estou com problemas quando executo o iperfs com 2+ fluxos paralelos de menos do que 20Gb no total entre 10Gb * 2 hosts conectados em diferentes sub-redes. .. Juniper replicou o problema, mas ainda não tem boas respostas :( Se eles não conseguirem descobrir, talvez o Linux QoS seja o próximo passo.