FreeBSD 链路聚合不比单链路快
War*_*ung 10 freebsd bandwidth bonding lacp
我们把一个4端口英特尔I340-T4 NIC在一个FreeBSD 9.3服务器1，并且被配置为它的链路聚合在LACP模式以试图从主文件服务器降低所花费的反射镜8的时间数据的16个的TiB到2- 4 个平行克隆。我们期望获得高达 4 Gbit/sec 的聚合带宽，但无论我们尝试过什么，它的速度都不会超过 1 Gbit/sec 的聚合带宽。2
我们正在使用iperf3在静态 LAN 上对此进行测试。3第一个实例几乎达到了千兆位，正如预期的那样，但是当我们并行启动第二个实例时，两个客户端的速度下降到大约 ½ Gbit/秒。添加第三个客户端会将所有三个客户端的速度降低到 ~⅓ Gbit/sec，依此类推。
我们在设置iperf3测试时非常小心，以确保来自所有四个测试客户端的流量通过不同端口进入中央交换机：
我们已经验证了每台测试机器都有一条独立的路径返回到机架交换机，并且文件服务器、它的 NIC 和交换机都有带宽来通过拆分lagg0组并为每个机器分配一个单独的 IP 地址来实现这一点。此 Intel 网卡上的四个接口之一。在该配置中，我们确实实现了约 4 Gbit/sec 的聚合带宽。
当我们开始走这条路时，我们使用的是旧的SMC8024L2 管理型交换机。（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。
我们首先启动哪个客户端，或者我们以哪个顺序启动它们都无关紧要。
ifconfig lagg0 在 FreeBSD 方面说：
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,COLLECTING,DISTRIBUTING>
laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
我们已经尽可能多地应用了 FreeBSD 网络调整指南中对我们的情况有意义的建议。（其中大部分是无关紧要的，例如有关增加最大 FD 的内容。）
我们尝试关闭 TCP 分段卸载，结果没有变化。
我们没有第二个 4 端口服务器 NIC 来设置第二个测试。由于使用 4 个单独的接口成功测试，我们假设没有任何硬件损坏。3
我们看到了这些前进的道路，它们都没有吸引力：
买一个更大、更坏的交换机，希望 SMC 的 LACP 实施很糟糕，而新交换机会更好。（升级到 HP 2530-24G 没有帮助。）多看看 FreeBSD 的
lagg配置，希望我们错过了什么。4忘记链路聚合并使用轮询 DNS 来实现负载平衡。
更换服务器 NIC 并再次切换，这次使用10 GigE 的东西，大约是这个 LACP 实验的硬件成本的 4 倍。
脚注
你问为什么不迁移到 FreeBSD 10？因为 FreeBSD 10.0-RELEASE 仍然使用 ZFS 池版本 28，并且该服务器已升级到 ZFS 池 5000，这是 FreeBSD 9.3 中的一个新功能。该10. X线不会得到直到FreeBSD的10.1舰艇约一个月，因此。不，从源代码重建以进入 10.0-STABLE 的前沿不是一种选择，因为这是一个生产服务器。
请不要妄下结论。我们在问题后面的测试结果告诉您为什么这不是这个问题的重复。
iperf3是纯网络测试。虽然最终目标是尝试从磁盘填充 4 Gbit/sec 的聚合管道，但我们还没有涉及磁盘子系统。可能是越野车或设计不佳，但没有比出厂时更坏。
我已经因为那样做而变得斗鸡眼了。
系统和交换机上使用的负载平衡算法是什么？
我所有的经验都是在 Linux 和 Cisco 上，而不是在 FreeBSD 和 SMC 上，但同样的理论仍然适用。
Linux 绑定驱动程序的 LACP 模式以及旧版 Cisco 交换机（如 2950）上的默认负载平衡模式是仅基于 MAC 地址进行平衡。
这意味着，如果您的所有流量都从一个系统（文件服务器）发送到另一个 MAC（默认网关或交换机上的交换虚拟接口），则源 MAC 和目标 MAC 将相同，因此只有一个从属设备使用。
从您的图表来看，您似乎没有将流量发送到默认网关，但我不确定测试服务器是否位于 10.0.0.0/24 中，或者测试系统是否位于其他子网中并通过交换机上的三层接口。
如果您在交换机上进行路由，这就是您的答案。
解决这个问题的方法是使用不同的负载平衡算法。
同样，我没有 BSD 或 SMC 的经验，但 Linux 和 Cisco 可以根据 L3 信息（IP 地址）或 L4 信息（端口号）进行平衡。
由于每个测试系统必须具有不同的 IP，因此请尝试根据 L3 信息进行平衡。如果仍然不起作用，请更改一些 IP，看看是否更改了负载平衡模式。