FreeBSD链路聚合不比单链路快

我们在FreeBSD 9.3 server1中放置了一个4端口 Intel I340-T4网卡,并在 LACP mode中将其配置为 link aggregation,以减少将8到16 TiB数据从主文件服务器镜像到并行2-4个克隆所需的时间.我们期望获得高达4 Gbit / sec的总带宽,但无论我们尝试过什么,它的速度都不会超过1 Gbit / sec aggregate.2.

我们正在使用iperf3在静态LAN上测试它.第一个实例几乎达到千兆位,正如预期的那样,但当我们并行启动第二个时,两个客户端的速度下降到大约½Gbit/ sec.添加第三个客户端会将所有三个客户端的速度降低到〜⅓ Gbit / sec等.

我们已经注意设置iperf3测试,来自所有四个测试客户端的流量进入不同端口的中央交换机：

我们已经验证每个测试机器都有一个独立的路径返回到机架交换机,并且文件服务器,它的NIC和交换机都有带宽通过分解lagg0组并为其分配单独的IP地址来实现此目的.这个英特尔网卡上的四个接口中的每一个.在该配置中,我们确实实现了~4 Gbit / sec的聚合带宽.

当我们开始沿着这条路走下去的时候,我们用旧的SMC8024L2 managed switch做了这个.(PDF数据表,1.3 MB.)它不是当时最高端的开关,但它应该能够做到这一点.由于年龄的原因,我们认为转换可能是错误的,但升级到功能更强大的HP 2530-24G并未改变症状.

HP 2530-24G交换机声称有问题的四个端口确实配置为动态LACP中继：

# show trunks
Load Balancing Method:  L3-based (default)

  Port | Name                             Type      | Group Type    
  ---- + -------------------------------- --------- + ----- --------
  1    | Bart trunk 1                     100/1000T | Dyn1  LACP    
  3    | Bart trunk 2                     100/1000T | Dyn1  LACP    
  5    | Bart trunk 3                     100/1000T | Dyn1  LACP    
  7    | Bart trunk 4                     100/1000T | Dyn1  LACP

我们尝试过被动和主动LACP.

我们已经验证了所有四个NIC端口都在FreeBSD端获得流量：

$sudo tshark -n -i igb$n

奇怪的是,tshark表明,在只有一个客户端的情况下,交换机将1 Gbit / sec流分成两个端口,显然是在它们之间进行乒乓. (SMC和HP交换机都显示了这种行为.)

由于客户端的总带宽只汇集在一个地方 – 在服务器机架的交换机上 – 只为LACP配置了该交换机.

我们首先启动哪个客户端,或者我们启动它们的顺序并不重要.

FreeBSD方面的ifconfig lagg0说：

lagg0: flags=8843<UP,broADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 90:e2:ba:7b:0b:38
    inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa 
    nd6 options=29<PERFORMNUD,IFdisABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,disTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,disTRIBUTING>
    laggport: igb1 flags=1c<ACTIVE,disTRIBUTING>
    laggport: igb0 flags=1c<ACTIVE,disTRIBUTING>

我们在the FreeBSD network tuning guide中应用了尽可能多的建议,这对我们的情况很有意义. (其中大部分都是无关紧要的,例如关于增加最大FD的东西.)

我们已经尝试过turning off TCP segmentation offloading,结果没有变化.

我们没有第二个4端口服务器NIC来设置第二个测试.由于使用4个独立接口进行了成功测试,我们假设没有任何硬件损坏

我们看到这些道路向前发展,它们都没有吸引力：

>购买更大,更糟糕的开关,希望SMC的LACP实施很糟糕,并且新开关会更好. (升级到HP 2530-24G没有帮助.)
>更多地盯着FreeBSD lagg配置,希望我们错过了一些东西
>忘记链接聚合并使用循环DNS来实现负载平衡.
>更换服务器NIC并再次切换,这次使用10 GigE,大约是此LACP实验硬件成本的4倍.

脚注

>为什么不转到FreeBSD 10,你问？因为FreeBSD 10.0-RELEASE仍然使用ZFS池版本28,并且该服务器已经升级到ZFS池5000,这是FreeBSD 9.3中的一个新功能.在FreeBSD 10.1发布about a month hence之前,10.x行不会得到.不然,从源代码重建到10.0-STABLE前沿不是一个选项,因为这是一个生产服务器.
>请不要妄下结论.我们在问题后面的测试结果告诉您为什么这不是this question的副本.
> iperf3是纯粹的网络测试.虽然最终目标是尝试从磁盘填充4 Gbit / sec聚合管道,但我们尚未涉及磁盘子系统.
>可能是越野车或设计不佳,但不会比它离开工厂时更加破碎.
>我已经因为这样做而睁大眼睛了.

在系统和交换机上使用的负载均衡算法是什么？

我所有的经验都是在Linux和Cisco上,而不是FreeBSD和SMC,但同样的理论仍然适用.

Linux绑定驱动程序的LACP模式以及较早的Cisco交换机(如2950)上的默认负载平衡模式是仅基于MAC地址进行平衡.

这意味着如果您的所有流量都从一个系统(文件服务器)传输到另一个MAC(交换机上的默认网关或交换虚拟接口),那么源MAC和目标MAC将是相同的,因此只有一个从站使用.

从您的图表中看起来您不会将流量发送到默认网关,但我不确定测试服务器是否在10.0.0.0/24中,或者测试系统是否位于其他子网中并且是通过交换机上的三层接口.

如果您在交换机上路由,那么就是您的答案.

解决方案是使用不同的负载平衡算法.

我再次没有使用BSD或SMC的经验,但Linux和思科可以根据L3信息(IP地址)或L4信息(端口号)进行平衡.

由于每个测试系统必须具有不同的IP,请尝试基于L3信息进行平衡.如果仍然无效,请更改几个IP,看看是否更改了负载平衡模式.

FreeBSD链路聚合不比单链路快

相关推荐