服务器、交换机的链路聚合和负载均衡配置详解
一. 什么是 Bond 聚合链路?有什么优点?
Bond就是把多张物理网卡捆绑成一张逻辑网卡,实现冗余和负载均衡。Bond接口对上层网络栈呈现一个虚拟网卡,多条物理网线同时参与转发。
核心优点:
- 冗余备份:物理链路或网卡故障时,业务流量自动切换到其他健康链路,业务无感知。
- 带宽聚合:多链路并行承载流量,提升总体吞吐(取决于模式和流量类型)。例如2条10Gbps链路可在支持负载均衡时达到近20Gbp带宽。
- 负载均衡:据哈希算法分散流量到不同链路,减轻单链路压力。
二. Bond的工作模式
Linux 内核 Bonding 提供了 7 种模式(mode),数字 0~6,各模式适用不同场景。
- mode=0 (balance-rr):轮询分发数据包,所有链路都干活,带宽叠加效果好。缺点:包可能乱序,且交换机必须做静态链路聚合。
- mode=1 (active-backup):主备模式,仅有一块被称为主网卡(Primary)的物理成员接口处于 Active 状态,用于承载全部的出入站网络流量,其余物理网卡全部处于待命(Backup)状态,不收发任何业务数据。交换机无需配置,简单可靠,但不加带宽。
- mode=2 (balance-xor):默认使用源 MAC 地址与目的 MAC 地址进行 XOR 计算并取模。相同的 MAC 对所产生的数据流始终落入固定的网卡中,属于流级负载均衡,完美避免了 Mode 0 的乱序报文问题。交换机需配静态聚合。
- mode=3 (broadcast):每个包都向所有接口发送,做到完全冗余,但是接收端需要进行大量的去重过滤极其消耗主机的 CPU 与总线带宽资源,用于极特殊场景。交换机需配静态聚合。
- mode=4 (802.3ad / LACP):动态链路聚合,服务器与交换机会协商聚合,自动管理链路增减,带宽叠加且故障自愈。交换机必须启用 LACP。
- mode=5 (balance-tlb):自适应发送负载均衡,出站流量根据每个成员物理网卡的实时负载大小(以及协商速率)进行动态散列分发。入站流量则固定由当前指定的 Active 主网卡来接收。交换机无需配置。
- mode=6 (balance-alb):在 mode 5 基础上增加了接收负载均衡。其核心原理是通过 ARP 欺骗与拦截机制实现的。当本地服务器向外发送 ARP 响应(ARP Reply)时,Bonding 驱动会强行拦截这些报文,并用不同的物理成员网卡的硬件 MAC 地址来重写 ARP 报文中的源 MAC 地址,从而使外部不同的网络客户端(Clients)在进行 ARP 缓存时,将该服务器的 IP 地址映射到不同的物理网卡 MAC 上。在复杂的虚拟机桥接、容器网络等场景下,MAC 重写会导致严重的网络寻址混乱,建议谨慎使用。交换机无需配置
生产环境主流选择:追求带宽与标准化的场景用
mode=4 (LACP);设备不支持 LACP 时可以用mode=1做纯冗余;想要高吞吐和冗余且设备不支持LACP可以做mode=0。
| 模式编号 | 模式名称 | 交换机配置要求 | 负载均衡方向 | 乱序风险 |
|---|---|---|---|---|
| Mode 0 | balance-rr | 必须配置静态 Trunk | 双向包级 | 高(易导致 TCP 性能退化) |
| Mode 1 | active-backup | 无任何要求 | 无(仅单网卡承载) | 无 |
| Mode 2 | balance-xor | 必须配置静态 Trunk | 出站流级 | 无 |
| Mode 3 | broadcast | 必须配置静态 Trunk | 双向广播(无分流) | 无 |
| Mode 4 | 802.3ad | 必须配置动态 LACP | 双向流级 | 无 |
| Mode 5 | balance-tlb | 无任何要求 | 仅出站流级 | 无 |
| Mode 6 | balance-alb | 无任何要求 | 双向流级 | 无 |
三. LACP 配置模式
LACP(链路聚合控制协议)是 mode=4 背后的标准协议,它能自动检测链路状态并协商聚合。
- 动态 LACP(主动/被动):服务器与交换机自动握手。通常我们设置服务器端为 active 模式(主动发出协商包LACPDU ),交换机侧设为 active 或 passive,只要有一端是 active 就能协商成功。
- 静态 LACP:其实是不协商的“静态聚合”(即 mode=0/2 需要的交换机配置)。它没有协议数据单元(PDU)交互,全靠管理配置“强制捆绑”。
在 Linux bond 配置中,mode=4 要求交换机接口启用 LACP,我们需要关注 lacp_rate 参数(慢速每30秒发一次,快速每秒发一次,通常设 fast)。
LACP选举机制
LACP的选举机制是链路聚合功能的核心,决定了聚合组中哪些成员端口成为活动端口、如何选举主动端以及如何实现链路故障时的快速切换。
LACP优先级
LACP优先级分为系统LACP优先级和接口LACP优先级两个层面,二者分工不同:
系统LACP优先级是为了区分链路聚合两端设备优先级的高低而配置的参数。系统优先级高的设备将被选作主动端(Actor),由它来决定两端设备的活动接口。在两端设备中选择系统LACP优先级较小一端作为主动端,如果系统LACP优先级相同(缺省均为32768)则选择MAC地址较小的一端作为主动端。
接口LACP优先级可以通过配置接口LACP优先级(缺省为32768)来区分不同接口被选为活动接口的优先程度,优先级高的接口将优先被选为活动接口。当聚合组中的成员接口数量超过最大活动接口数上限(通常为8个)时,系统依据接口优先级来选择哪些接口成为活动接口。接口优先级数值越小,优先级越高。
1 | 配置系统LACP优先级(系统视图): |
LACP抢占
LACP抢占功能可以保持接口LACP优先级最高的接口为活动接口。例如:当一条高优先级的接口因故障切换为非活动状态而后又恢复时,如果配置了抢占,则高优先级的接口将重新成为活动接口;如果未配置抢占,该接口不能重新成为活动接口。
抢占延时即抢占等待时间,是指在LACP模式的Eth-Trunk中非活动接口切换为活动接口需要等待的时间。配置抢占延时可以避免由于某些链路状态频繁变化而导致Eth-Trunk数据传输不稳定的情况。
1 | interface eth-trunk 1 |
LACP报文超时时间
LACP协议通过定期发送LACPDU报文来检测成员链路的通断状态。LACP报文超时时间是指本端成员接口在未收到对端LACPDU的情况下,等待多长时间后将链路标记为Down状态。
LACP超时时间分为两种模式:
| 模式 | 对端发送LACPDU周期 | 本端超时时间 | 特点 |
|---|---|---|---|
| fast | 1秒 | 3秒 | 响应快,占用系统资源较多 |
| slow | 30秒 | 90秒 | 资源消耗少,响应较慢 |
缺省情况下,Eth-Trunk接口接收报文的超时时间是90秒。
链路聚合组的每个成员接口每秒最多处理20个LACP协议报文,设备全局每秒最多处理100个LACP协议报文,超过的协议报文将会被丢弃。
1 | 配置方法: |
华为交换机LACP配置实例
场景1:静态聚合(配合服务器 bond mode 0)
1 | interface Eth-Trunk1 |
场景2:LACP 动态聚合(配合服务器 bond mode 4)
1 | interface Eth-Trunk1 |
四. 服务器bond参数与配置
Bond 配置参数
| 参数 | 含义 | 常用值/建议 |
|---|---|---|
| miimon | 链路监测周期(毫秒) | 100 (每100ms检查一次MII状态) |
| arp_interval | miimon的替代,使用 ARP 监控的间隔(毫秒),需配合arp_ip_target | 可设 1000 |
| arp_ip_target | ARP 监控的目标IP(通常为网关) | 网关例如192.168.0.1 |
| updelay | 检测到链路恢复后,延迟多少毫秒才启用接口 | 200 (防止频繁抖动),默认0 |
| downdelay | 检测到链路中断后,延迟多少毫秒才断开接口 | 200,默认0 |
| primary | 指定主接口(仅 mode=1 有效),主接口恢复后会切回 | 例如eth1 |
| primary_reselect | 主接口恢复后的重新选择策略 | always (总是切回), better, failure(绝不切回) |
| lacp_rate | LACP 协议报文发送速率 (mode=4) | fast (每秒1个), slow (30秒1个) |
| xmit_hash_policy | 发送时选择链路的哈希策略 | layer3+4, layer2+3, layer2 (和交换机保持一致建议 layer2+3) |
最佳实践:生产环境优先用 miimon 做链路监控,简单可靠。mode=4 时设置 xmit_hash_policy=layer2+3, bond_updelay=200 bond_downdelay=200 。
服务器配置bond
以debian配置bond4为例:
1 | vim /etc/network/interfaces |
服务器 Bond 的验证
1 | # 1. 查看bond状态、成员接口、模式、哈希策略 |
五. 负载算法
交换机的负载均衡方式
- dst-ip(目的IP地址)模式:根据目的IP地址进行负载分担。
- dst-mac(目的MAC地址)模式:根据目的MAC地址进行负载分担。
- src-ip(源IP地址)模式:根据源IP地址进行负载分担。
- src-mac(源MAC地址)模式:根据源MAC地址进行负载分担。
- src-dst-ip(源IP地址异或目的IP地址)模式:根据源IP异或目的IP地址的结果进行负载分担。
- src-dst-mac(源MAC地址异或目的MAC地址)模式:根据源MAC异或目的MAC地址的结果进行负载分担。
实际业务中用户需要根据业务流量特征选择配置合适的负载分担方式。业务流量中某种参数变化越频繁,选择与此参数相关的负载分担方式就越容易实现负载均衡。例如,如果报文的IP地址变化较频繁,那么选择基于dst-ip、src-ip或src-dst-ip的负载分担模式更有利于流量在各物理链路间合理的负载分担;如果报文的MAC地址变化较频繁,IP地址比较固定,那么选择基于dst-mac、src-mac或src-dst-mac的负载分担模式更有利于流量在各物理链路间合理的负载分担。
服务器bond的负载均衡方式
- layer2:仅以源/目的MAC地址(XOR)加上类型字段哈希,是默认且802.3ad兼容。所有发往同一对MAC地址的流始终走同一路径。适合局域网中主要是MAC地址唯一性的场景。
- layer3+4:使用IP地址和TCP/UDP端口做哈希,可使针对同一目标IP的不同会话分布到不同端口,提高并行度(单连接依旧固定)。此策略不完全符合802.3ad规范(可能出现数据包乱序)但常用于服务器到多客户端的场景。
- layer2+3:结合MAC和IP信息进行哈希。对非IP流采用layer2策略,对IP流则加入IP地址,能够在一定程度上兼顾IP路由场景的均衡性。802.3ad兼容。
- encap2+3/encap3+4:对隧道流量(如VXLAN)友好,哈希使用隧道内层地址(需要内核skb_flow_dissect支持)。当主机有大量隧道封装流量时,可考虑启用这些策略提高均衡性。
通常生产环境建议交换机选择src-dst-ip,服务器选择配置layer2+3。



