我们正在使用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,看看是否更改了负载平衡模式.
