☰

当多个并发进程正在传输数据时，LACP 绑定似乎更倾向于一个接口

tag-icon • tag-icon networking bonding lacp
当多个并发进程正在传输数据时，LACP 绑定似乎更倾向于一个接口

这可能是一个非常简单的问题（即我从根本上错过了一些东西，这只是我的错/缺乏知识/假设）。

因此，我有一台带有 2 条 25GbE 光纤的机器，通过带有两个 VLAN 的 LACP（思科交换机）绑定到 bond0。

当我启动 5 或 6 个并发 rsync 将不同数据从一个源传输到目标路径时，我有点惊讶地发现这些数据几乎完全有利于一个物理接口（~900MiB/s）。我假设负载会在构成键合的两个界面之间有所分配。显示每个接口的网络流量的 Grafana 图表图像

我完全意识到数据包不会跨接口拆分为单个流，但由于我的 rsync 都是独立的进程，我预计至少有一个或两个使用第二个物理接口......

作为参考，使用中的 netplan 配置的“粗略”轮廓（即删除了我认为敏感的信息）：

network:
 version: 2
 renderer: networkd
 ethernets:
  eno1:
   dhcp4: false
   dhcp6: false
   optional: true
   link-local: []
  ens5f0np0:
   dhcp4: false
   dhcp6: false
   optional: true
  ens5f1np1:
   dhcp4: false
   dhcp6: false
   optional: true   
 bonds:
  bond0:
   dhcp4: false
   dhcp6: false
   interfaces: [ens5f0np0, ens5f1np1]
   mtu: 9000
   parameters:
    mode: 802.3ad
    lacp-rate: fast
    mii-monitor-interval: 100
 vlans:
  bond0.xxx:
   id: xxx
   link: bond0
   addresses: [ip]
   gateway4: ip
   mtu: 1500
   nameservers:
    search: [domains]
    addresses: [ips]
  bond0.xxx:
   id: xxx
   link: bond0
   addresses: [ip]
   mtu: 9000
   routes:
   - to: random subnet
     via: local subnet ip
   - to: random subnet
     via: local subnet ip
   - to: random subnet
     via: local subnet ip

问题是，虽然 rsync 是不同的进程，但源 IP 和目标 IP 是相同的（每个 rsync 都在一个位置读取一个大子文件夹，并复制到一个公共位置），并且在绑定处完成的散列基本上意味着它是否将所有这些视为相同的流量？源数据位于 1 个 VLAN 中的一台服务器上，目标服务器位于另一个 VLAN 中。

如果这是我的错/不正确的假设，我仍然想学习所有相同的内容，因为我认为不同的 rsyncs 将构成不同的数据“流”。

答案1

默认情况下LACP将使用第 2 层 XOR政策：

传出流量的从站选择是根据传输哈希策略完成的，该策略可能会从默认简单异或策略 通过xmit_hash_policy下面记录的选项。

第2层

使用硬件 MAC 地址和数据包类型 ID 字段的 XOR 来生成哈希值。公式为

hash = 源 MAC XOR 目标 MAC XOR 数据包类型 ID
从机编号 = 哈希模从机计数

该算法会将所有流量放置在同一个从属设备上的特定网络对等点上。

使用默认值layer2或layer2+3使用每个单个 IP 地址的对等系统之间的设置，从解析为单个源 MAC 地址的单个源 IP 地址到解析为单个目标 MAC 地址的单个目标 IP 地址的流量将始终散列到相同的界面。

您应该使用layer3+4算法将在接口的计算中包括端口：

3+4层

该策略使用上层协议信息（如果可用）来生成哈希值。这允许到特定网络对等点的流量跨越多个从站，尽管单个连接不会跨越多个从站。

ip link的xmit_hash_policy选项转化为网络计划的transmit_hash_policy范围。所以你应该在配置中添加这个附加参数：

    transmit_hash_policy: layer3+4

如果流量要通过隧道传输到同一目的地的单个地址，encap3+4则可以考虑改为。

需要更多关注这项政策因为在出现碎片的情况下它不完全符合 LACP。由于第 4 层的协议 (TCP/UDP...) 端口不包含在片段中，因此这可能会使第一个片段和后续片段使用不同的接口，并使连接在到达时遭受不需要的数据包重新排序。只要所有涉及的系统具有相同的 MTU (9000)，这就不成问题，因为 TCP 会尝试避免碎片：

此算法不完全符合 802.3ad。包含分段和未分段数据包的单个 TCP 或 UDP 会话将看到跨两个接口的数据包条带化。这可能会导致交货无序。 [...]

相关内容