7 linux 配置链路聚合_linux – 在智能交换机上设置链路聚合组(L...

我的问题是：为什么在智能交换机上设置链路聚合组会降低两台机器之间的带宽？

我终于通过TP-LINK T1700X-16TS智能交换机通过2条绑定的10G CAT7电缆连接两台机器(运行ubuntu 18.04服务器的服务器)之间的吞吐量(带宽)更高.电缆连接到每台机器中的单个intel X550-T2 NIC(每个卡上有2个RJ45端口),插入PCI-E x8.

我做的第一件事就是在交换机配置中创建静态LAG组,其中包含每台机器连接的两个端口.这最终成了我的第一个错误.

在每个盒子上,创建了一个包含intel X550-T2卡上两个端口的绑定.我正在使用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)

我得到的是每秒9.9 Gbits(非常接近单个10G连接的理论最大值)

但是有些事情是错的.我正在使用循环法,我在机器之间有两根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 Gbits / sec(有时高达16.0).

重新发送令我担心(当我设置LAG时,我得到零),但现在我至少获得了一些优势.

注意,如果我禁用巨型数据包或将MTU设置为1500,我只能获得大约4Gbps到5Gbps.

有谁知道为什么在智能交换机上设置链路聚合组(我认为应该有帮助),而不是限制性能？另一方面,没有设置它们(我可以节省我的钱并购买一个非管理型交换机！)让我发送更多正确路由的数据包？

交换机的LAG组有什么意义？我在某处做错了吗？如果可能的话,我想增加带宽甚至超过16Gbps.

编辑

从下面的评论中复制(更新)：

我通过绑定连接验证了实际应用程序11Gbps(1.25 GiB /秒),使用nc(netcat)将60 GB文件从一个系统上的ramdisk复制到另一个系统.我使用哈希验证了文件的完整性,它是双方的同一个文件.

一次只使用一个10G端口(或使用balance-xor等绑定),我得到1.15 GiB /秒(约9.9 Gbps).默认情况下,iperf和nc都使用TCP连接.将其复制到本地计算机(通过环回)获得1.5 GiB /秒的速度.查看交换机上的端口使用情况,我发现发送方Tx端的使用率基本相同(在iperf情况下为70％,在nc文件复制情况下为~55％),并且在2个绑定端口之间使用相同Rx方面.

因此,在当前的设置(balance-rr,MTU 9000,交换机上没有定义LAG组),我可以实现超过10Gbps,但只能勉强实现.

奇怪的是,在交换机上定义LAG组现在会破坏所有内容(iperf和文件传输现在发送0个字节).可能只需要时间来找出新的切换情况,但我重新运行了很多次并重新启动/重置了几次开关.所以,我不确定为什么会这样.

编辑2

我实际上发现在kernel.org文档中提到条带化和balance-rr允许高于单端口带宽.

特别

12.1.1 MT Bonding Mode Selection for Single Switch Topology

This configuration is the easiest to set up and to understand,

although you will have to decide which bonding mode best suits your

needs. The trade offs for each mode are detailed below:

balance-rr: This mode is the only mode that will permit a single

TCP/IP connection to stripe traffic across multiple interfaces. It

is therefore the only mode that will allow a single TCP/IP stream to

utilize more than one interface’s worth of throughput. This comes at

a cost, however: the striping generally results in peer systems

receiving packets out of order, causing TCP/IP’s congestion control

system to kick in, often by retransmitting segments.

It is possible to adjust TCP/IP’s congestion limits by altering the

net.ipv4.tcp_reordering sysctl parameter. The usual default value is

3. But keep in mind TCP stack is able to automatically increase this when it detects reorders.

Note that the fraction of packets that will be delivered out of

order is highly variable, and is unlikely to be zero. The level of

reordering depends upon a variety of factors, including the

networking interfaces, the switch, and the topology of the

configuration. Speaking in general terms, higher speed network

cards produce more reordering (due to factors such as packet

coalescing), and a “many to many” topology will reorder at a higher

rate than a “many slow to one fast” configuration.

Many switches do not support any modes that stripe traffic (instead

choosing a port based upon IP or MAC level addresses); for those

devices, traffic for a particular connection flowing through the

switch to a balance-rr bond will not utilize greater than one

interface’s worth of bandwidth.

If you are utilizing protocols other than TCP/IP, UDP for example,

and your application can tolerate out of order delivery, then this

mode can allow for single stream datagram performance that scales

near linearly as interfaces are added to the bond.

This mode requires the switch to have the appropriate ports

configured for “etherchannel” or “trunking.”

因此,从理论上讲,balance-rr将允许我对单个TCP连接的数据包进行条带化.但是,它们可能会无序到达,等等.

但是,它提到大多数交换机不支持条带化.我的开关似乎就是这种情况.在真实文件传输期间观察流量时,Rx分组(即sending_machine-> switch)均匀地分布在两个绑定端口上.但是,Tx数据包(switch-> receiving_machine)仅通过其中一个端口(并达到90％或更高饱和度).

通过不在交换机中明确设置链路聚合组,我能够实现更高的吞吐量,但我不确定接收机器如何告诉交换机向下发送一个端口,从另一个端口发送,等等.

结论：

交换机链路聚合组不支持用于发送分组的循环(即端口条带化).因此,忽略它们可以让我获得高吞吐量,但实际写入内存(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或内存读/写. ramdisk中本地的简单“复制”(例如dd if = file1 of = file2 bs = 1M)导致2.6 Ghz的最佳速度约为2.3GiB /秒,2.4 Ghz时的最佳速度为2.2GiB / sec,以及2.0 GiB /秒的最佳速度2.2 Ghz.第二个还有较慢的内存,但似乎并不重要.

从较慢的机器到2.6 Ghz ramdisk的所有TCP副本都是1.15 GiB / s,从2.4 Ghz到1.30 GiB / s,从最快的机器到中间机器以1.02 GiB / s到达较慢的机器(具有更快的内存)以1.03 GiB / s等

最大的影响似乎是接收端的单核CPU和内存时钟.我没有比较BIOS设置,但所有都运行相同的BIOS版本并使用相同的主板,eth卡等.重新排列CAT7电缆或交换机端口似乎没有效果.

我找到了

谁通过四个1GbE连接执行此操作.我尝试设置单独的VLAN,但它不起作用(没有提高速度).

最后,使用相同的方法发送给自己似乎调用0.3 GiB – 0.45 GiB /秒的惩罚.因此,我的观察值并不比该方法的“理论”最大值低得多.

编辑3

(为后代添加更多信息)

即使在开关上设置了balance-rr和LAG,我也意识到尽管看到9.9 Gbps,但balance-rr中的重试实际上高于没有LAG的情况！每组平均2500个,平均1000个没有！

但是,在设置组的情况下,我将平均实际文件传输速度内存提供到1.15 GiB / s(9.9 Gbps)的内存.如果我只在每台机器上插入一个端口,我看到相同的速度(1.15 GiB / s),并且很少重试.如果我将模式切换到balance-xor,我得到1.15 GiB / s(9.9 Gbps),并且没有重新发送.因此,balance-rr模式试图对输出进行条带化以切换事物,这就是我猜测会导致大量无序数据包.

由于我使用交换机LAG和balance-xor对内存到内存传输的最大(真实世界)性能相似或更高,同时具有较少的重新发送(拥塞),我正在使用它.但是,由于最终的目标是NFS和MPI发送,我将需要以某种方式找到一种方法来饱和并测量这些情况下的网络速度,这可能取决于MPI连接的实现方式……

最终编辑

我回到使用balance-rr(在交换机侧没有设置LAG),因为XOR将始终散列到相同的两个对等端的相同端口.所以它只会使用其中一个端口.使用balance-rr,如果我同时运行2个或更多(ram to ram)文件传输,我可以获得18-19 Gbps的净值,非常接近20 Gbps的理论最大值.