☰

FreeBSD 链路聚合并不比单链路快

tag-icon • tag-icon freebsd bandwidth bonding lacp
FreeBSD 链路聚合并不比单链路快

我们放了一个4端口英特尔 I340-T4在 FreeBSD 9.3 服务器1中安装 NIC并对其进行配置链路聚合在LACP 模式试图减少将 8 到 16 TiB 数据从主文件服务器镜像到 2-4 个并行克隆所需的时间。我们原本希望获得高达 4 Gbit/秒的聚合带宽，但无论我们怎么尝试，它都不会比 1 Gbit/秒的聚合速度更快。2

我们正在使用iperf3在静态 LAN 上进行测试。3第一个实例几乎达到了千兆位，正如预期的那样，但是当我们并行启动第二个实例时，两个客户端的速度下降到大约 ½ Gbit/秒。添加第三个客户端会使所有三个客户端的速度降至约⅓ Gbit/秒，依此类推。

我们在设置iperf3测试时非常小心，所有四个测试客户端的流量都通过不同的端口进入中央交换机：

LACP 测试设置

我们已经验证了每台测试机器都有一条独立的路径返回机架交换机，并且文件服务器、其 NIC 和交换机都具有足够的带宽，可以通过拆分组lagg0并为此 Intel 网卡上的四个接口分配单独的 IP 地址来实现这一点。在这种配置下，我们确实实现了约 4 Gbit/秒的总带宽。

当我们开始走这条路的时候，我们用的是旧的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 lagg0FreeBSD 方面则表示：

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

我们看到了这些前进的道路，但没有一条具有吸引力：

  1. 购买更大、更强大的交换机，希望 SMC 的 LACP 实现很糟糕，而新的交换机会更好。（升级到 HP 2530-24G 没有帮助。）

  2. 再看看 FreeBSDlagg配置，希望我们错过了什么。4

  3. 忘记链路聚合，而是使用循环 DNS 来实现负载平衡。

  4. 更换服务器网卡并再次切换，这次使用10 GigE大约是这个 LACP 实验的硬件成本的 4 倍。

脚注

  1. 您可能会问，为什么不迁移到 FreeBSD 10？因为 FreeBSD 10.0-RELEASE 仍然使用 ZFS 池版本 28，而此服务器已升级到 ZFS 池 5000，这是 FreeBSD 9.3 中的一项新功能。10.X直到 FreeBSD 10.1 发布后，产品线才会实现该功能大约一个月后。并且，从源代码重建以进入 10.0-STABLE 前沿不是一个选项，因为这是一个生产服务器。

  2. 请不要妄下结论。我们后面的测试结果会告诉你为什么这不是这个问题。

  3. iperf3是纯网络测试。虽然最终目标是尝试从磁盘填充 4 Gbit/sec 聚合管道，但我们尚未涉及磁盘子系统。

  4. 可能有缺陷或设计不良，但不会比出厂时更严重。

  5. 我这样做已经让我斜视了。

答案1

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

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

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

这意味着如果所有流量都从一个系统（文件服务器）发送到另一个 MAC（默认网关或交换机上的交换虚拟接口），那么源 MAC 和目标 MAC 将相同，因此只会使用一个从属设备。

从您的图表上看，您似乎没有将流量发送到默认网关，但我不确定测试服务器是否位于 10.0.0.0/24，或者测试系统是否位于其他子网中并通过交换机上的第 3 层接口进行路由。

如果您正在交换机上进行路由，那么这就是您的答案。

解决这个问题的方法是使用不同的负载平衡算法。

再次声明，我没有使用 BSD 或 SMC 的经验，但 Linux 和 Cisco 可以根据 L3 信息（IP 地址）或 L4 信息（端口号）进行平衡。

由于每个测试系统必须具有不同的 IP，请尝试根据 L3 信息进行平衡。如果这仍然不起作用，请更改一些 IP，看看是否能改变负载平衡模式。

相关内容