说实话端口链路聚合这玩意儿我第一次真正意识到它值钱是在一次数据库备份调优的场景里。当时某台业务服务器的千兆网卡流量已经跑到了 95% 以上备份任务从深夜一路跑到凌晨都搞不完可服务器上明明还有一块网卡闲着利用率不到 5%。那会儿我脑子里第一个冒出来的解决办法就是把两块网卡绑成一个逻辑接口这就是今天想跟你好好聊的端口链路聚合也叫链路聚合、网卡绑定、Bonding、Teaming不同厂商叫法不一样本质上是同一件事。端口链路聚合做的事情并不复杂把两台设备之间的多条物理链路捆绑成一条逻辑链路。它带来的好处有两个一是带宽叠加比如把两个千兆口聚合成一个逻辑口理论带宽就变成了 2Gbps二是链路冗余物理链路里任何一条断开流量会自动切换到存活的那条链路上业务不会因为一根网线被拔掉就中断。这篇文章我会把链路聚合从原理到实操完整拆一遍。你会看到静态聚合和 LACP 动态聚合到底怎么选、交换机侧和服务器侧的配置如何对齐、用什么方法验证聚合是真的生效了以及我在实际维护中踩过的几个典型坑。无论你是在管物理服务器、做虚拟化集群还是想在家里 NAS 上折腾链路聚合这篇文章的思路都适用。1. 链路聚合的价值在哪里先看清楚它解决什么问题1.1 带宽叠加与链路冗余一次解决两个痛点先说带宽叠加。别把链路聚合想得太神它不是一个 1Gbps 的端口加另一个 1Gbps 的端口就简单等于一个 2Gbps 的端口。逻辑链路确实拥有 2Gbps 的汇聚带宽但具体能跑多快取决于你跑的是什么样的流量。如果是单条 TCP 连接比如你从服务器上拉一个大文件这种单流传输走的是哈希计算选中的某一条物理链路最多只能跑满一个物理口的带宽。只有当系统里同时存在大量并发连接时流量才会被分散到不同的物理口上聚合带宽的优势才真正体现出来。这一点后面在验证部分我还会详细说。再说冗余。链路聚合的冗余逻辑很有意思因为聚合组里的成员口之间互为备份当一个物理口出现故障流量会自动重新哈希到其他健康的成员口上。这个过程对上层业务基本是透明的因为逻辑接口始终处于 up 状态应用的 TCP 连接不会因为底层链路切换而断开。这一点比“两块网卡配两个 IP靠路由切换”的方案要优雅得多也快得多。最早链路聚合的标准是 IEEE 802.3ad后来更新成了 802.1AX。标准的核心工作包括在聚合组里维护成员端口状态、根据哈希规则把流量分布到各成员口、以及对端设备通过协议报文协商聚合参数。理解了这个标准再看下面两种模式的区别就很容易了。1.2 两种主流模式静态手工聚合与 LACP 动态协商链路聚合按协商方式分成两大类一类是静态手工聚合另一类是基于 LACP 的动态聚合。静态手工聚合的逻辑最简单两台设备上手动把端口加到同一个聚合组里配置对了就能通配错了只能自己背锅。它不跑任何协商协议所以只要两端配置一致链路就能起来。缺点是如果某条物理链路故障设备无法通过协议感知端口状态变化其实也能感知因为端口物理 down 了聚合组也知道要把流量切走。但它无法判断对端是不是还正常比如网线接触不良导致端口处于半连通状态这种时候静态聚合基本没有容错能力。LACP全称 Link Aggregation Control Protocol是标准里推荐的方式。启用 LACP 的两个设备之间会定时交换 LACPDU 报文报布里带着端口优先级、系统优先级、端口号这些信息双方通过这些报文协商出谁是主端口、谁是备份端口。一旦某条物理链路故障LACP 能迅速感知并把故障端口从聚合组里剔除流量自动切换到其他正常端口。用一个表格把两种模式放在一起看差异就很直观了对比维度静态手工聚合LACP 动态聚合协商机制无协议交互定时交换 LACPDU配置复杂度较低略高需配置主备/活动状态故障感知仅感知端口物理状态可感知对端状态和链路质量适用场景对端设备不支持 LACP 或必须用最简单方式生产环境首选排错难度不易定位逻辑层问题可通过协议状态快速定位我自己在维护环境里凡是能做 LACP 的都尽量用 LACP静态手工聚合只用来应急或者对端设备确实不支持。不是因为静态聚合不行而是生产环境里多一层协议状态就多一个排障抓手尤其是跨机房跨设备的长链路LACP 的状态信息能帮你省掉大量排查时间。1.3 核心名词扫盲聚合组、成员口、主接口、LACPDU这块给刚入门的朋友扫个盲后面配置的时候你看到这些词就不会懵。聚合组Aggregation Group是所有成员口组成的集合比如你把交换机的两个口和服务器网卡的两个口绑在一起这四个端口分别属于两端各自的一个聚合组。逻辑上每个设备上只有一个聚合接口对外呈现服务器端叫 bond0交换机端叫聚合口或端口通道名字不同含义一样。成员口就是聚合组里的物理端口它们可以是电口也可以是光口但一个聚合组里最好保持速率和双工模式一致否则会因为成员口速率不一致导致流量分配异常。主接口对应两端协商出来的主用物理口LACP 会根据系统优先级和端口优先级选出一个主端口其他端口进入备用或分发状态。如果主端口挂了备用端口自动顶上。LACPDU 是 LACP 的控制报文默认周期性地在两端的聚合口之间发送。报文里携带的设备优先级、端口优先级、系统 ID 等信息决定了对端如何判断哪些端口能够加入聚合组。理解了这些名词下面看配置就会顺手很多。2. 动手前的规划这些检查没做就等着返工2.1 链路聚合不能保证单条流跑满先搞懂哈希机制链路聚合的流量分配机制核心是一个哈希函数。设备会根据报文里的某些字段比如源 MAC、目的 MAC、源 IP、目的 IP、四层端口等通过计算得到结果然后根据结果把这条数据流映射到某一根物理链路上。用高速公路打比方聚合链路相当于一条四车道的公路但每一辆车从头到尾只能在一条车道上开不能拆成两半同时走两条车道。所以只有当车流量足够多、足够分散时四条车道才能都被用起来。如果你这条路一天只跑一辆顶级大货车那其他三条车道只能是空的。这个机制引出一个特别重要的结论如果你的业务是单线程大文件传输、单连接数据库复制这类单一流量模型链路聚合几乎不能带来带宽提升。判断一个场景适不适合上链路聚合先问自己我这里是不是有很多并发连接用户访问数量多不多如果答案是肯定的链路聚合才有实际意义。哈希策略也不是越复杂越好。有些设备支持基于 MAC、基于 IP、基于四层端口组合等不同策略选策略时要结合网内流量类型。如果大多数流量是同一对服务器之间的东西向流量哈希因子里没有足够多的变量就很容易出现某个物理口拥塞、其他口闲置的状况。后面第五部分我会讲怎么调优这个问题。2.2 交换机侧与服务器侧的环境检查清单在我见过的问题里相当大一部分不是配置写错而是环境检查没做全。这里列一份我每次做链路聚合前都会过一遍的清单检查项检查标准漏掉可能出的问题物理端口速率所有成员口速率一致建议相同类型聚合失败或流量不均双工模式两端必须都是全双工且一致高延迟、丢包、协商错误VLAN 配置成员口的 VLAN 划分一致聚合口起来了但二层不通对端设备能力确认是否支持 LACP、支持多少条聚合协商不上端口起不来链路物理路径多条链路是否走同一设备、是否跨板卡单点故障时冗余失效服务器网卡固件网卡驱动和固件是否支持 bonding绑定模式异常网卡脱离端口归属确认拔线前确认物理口与逻辑口对应关系误操作导致业务中断其中最容易踩的坑是 VLAN 配置不一致。有一次我给某个客户做链路聚合交换机侧聚合口是 trunk 口放行了 VLAN 10 和 20服务器侧却忘了配置虚拟接口的 VLAN 标签结果聚合链路虽然起来了但 VLAN 10 的流量完全不通。这种问题不会让端口 down表现是“聚合正常但业务异常”排查起来特别迷惑。2.3 一个规划案例数据库服务器做 LACP 接入拿一个典型场景来举例。假设你需要把一台数据库服务器接入机房网络服务器上有两个千兆电口交换机是机架顶部的一台三层交换机业务特点是存在大量来自应用服务器的并发 SQL 查询同时还有定时的数据同步任务。在这种场景下我会这样规划两个千兆口加入同一个聚合组采用 LACP 动态模式交换机侧和服务器侧都配置为 LACP 主动模式。数据库服务器两个口分别插到交换机的两个不同端口上中间不能串接其他设备。VLAN 规划上数据库 VLAN 和应用 VLAN 分开聚合口以 trunk 模式放行需要的 VLAN。这套方案的收益点有两个一是并发查询流量能被哈希到两条物理链路上避免了单口拥塞二是任何一条物理链路故障时应用流量自动切换数据库连接不会中断省去了在应用层做连接池重连的麻烦。3. 配置实操交换机和服务器两边如何对齐3.1 交换机侧聚合配置的通用逻辑不同品牌的交换机配置命令风格相差很大有的叫 Eth-Trunk有的叫 Port-Channel有的叫 Bond 接口。但核心逻辑高度一致总共四步创建聚合口、把物理口加入聚合口、配置聚合口属性、确认成员口状态。以最常见的命令行风格示例配置一个 LACP 动态聚合口大致长这样interface port-channel 1 switchport mode trunk switchport trunk allowed vlan 10,20 lacp mode active ! interface GigabitEthernet0/1 channel-group 1 mode active ! interface GigabitEthernet0/2 channel-group 1 mode active这段配置里port-channel 1 是逻辑聚合口把它设为 trunk 模式放行 VLAN 10 和 20。两个物理口都用 channel-group 1 mode active 加入聚合组mode active 表示对端主动发送 LACPDU也就是 LACP 的主动模式。有一点特别重要被加入聚合组的物理口上不应该再保留独立的 VLAN、端口模式等配置否则交换机大概率会报配置冲突。有的设备允许把端口加入聚合组后自动继承聚合口上的二层属性有的设备要求你先去把物理口上的配置清干净再执行加入命令。建议在配置前先检查一下物理口配置避免中途报错。配置完成后观察聚合口状态确认两个成员口都处于 Selected 或者 Up 状态。如果某个端口一直处于 Standby 或 Down说明协商有问题不要急着继续配服务器端先把这个状态解决掉。3.2 服务器侧 bonding 配置mode 4 是最佳选择服务器端的网口绑定在大多数系统里都是通过 bonding 驱动实现的。我自己的习惯是能上 LACP 环境就一律用 mode 4也就是 802.3ad 动态链路聚合模式。服务器网口绑定的配置方式因系统而异但核心参数是一致的。下面是一个通用风格的配置示意# bond0 逻辑接口 BOND_DRIVER_OPTSmode4 miimon100 xmit_hash_policylayer34参数分解一下mode4 表示使用 802.3ad 动态链路聚合和交换机的 LACP 对接miimon100 表示每 100 毫秒检查一次物理链路状态这个值用来感知网线断开和链路故障xmit_hash_policylayer34 表示哈希策略使用 IP 地址加四层端口作为哈希因子对流量的均衡效果通常比默认的 layer2 策略更好。配置完逻辑接口后需要把两个物理网口作为 slave 添加到 bond0 里。这里有个容易犯的错绑定模式下物理网口本身不应该配置独立的 IP 地址所有 IP 配在 bond0 上。如果你在 eth0 和 eth1 上还留着 IP就会出现地址冲突或者流量完全不走聚合口的问题。下面是几种常见 bonding 模式的对比方便你理解为什么默认不要乱改模式名称特点适用场景mode 0balance-rr轮询逐包分发带宽利用高但可能乱序特定高性能场景较少直接用mode 1active-backup主备模式不叠加带宽仅冗余无法使用 LACP 的高可用场景mode 4802.3adLACP 动态协商带宽叠加 冗余生产环境首选mode 6balance-alb自适应负载均衡无需交换机支持交换机不支持 LACP 时特别提醒一句很多人听“绑定”就以为带宽一定翻倍不做 LACP 协议对接直接配了 mode 1结果带宽完全没变化。mode 1 是主备切换不是负载均衡两块网卡只有一块在干活另一块只在故障时顶上。想让带宽叠加要么用 mode 0、mode 6 这类不需要交换机支持的均衡模式要么就用 mode 4 加 LACP没有第三条路。3.3 配置匹配自检对照检查不出幺蛾子链路聚合出问题有一大半是因为两端配置不对齐。我在做完两边配置后会习惯性做一遍匹配自检最常见的就是这几项。先看模式匹配LACP 对 LACP静态对静态。LACP 主动模式对被动模式可以协商但主动汰被动要保证至少有一端是 active。如果交换机是 active服务器端却配成了 mode 1两边就会互不承认端口状态迟迟起不来。再看速率和双工匹配全部成员口必须统一速率双工都设为全双工。半双工模式下跑聚合是非常糟糕的会产生大量冲突和重传。然后是 VLAN 匹配交换机的聚合口放行了哪些 VLAN服务器侧对应的 vlan 子接口也要对得上两边 mismatch 的报错不会直接在聚合状态里显示出来但业务流量就是不通。还有一个细节是 STP 与聚合的配合。有的交换机默认在聚合口上启用了生成树协议端口从阻塞到转发需要几十秒这就导致链路聚合看起来“通了”但实际流量无法立刻走。如果设备支持把聚合口设置为 Portfast 或边缘端口特性可以让端口状态快速切换到转发。3.4 其他场景交换机互联和虚拟化平台的对接链路聚合不只在服务器接入点有用。两台交换机之间如果存在多条物理链路同样需要做成聚合链路口否则生成树协议会把多余的链路阻塞掉带宽白白浪费。交换机互联场景下的聚合配置思路差不多唯一要特别注意的是如果两台交换机属于不同厂商尽量都采用 LACP 标准模式静态聚合在跨厂商场景下可能会因为参数理解差异导致协商不上。虚拟化平台和物理交换机的对接又是另一种情况。虚拟交换机上的上行链路可以做链路聚合然后在物理交换机侧配置对应的聚合口。这里的关键是虚拟交换机里的负载均衡策略要和物理交换机侧的哈希策略匹配否则会出现虚拟机的流量集中在某一条物理上行链路上其他链路浪费。我见过某次虚拟化集群里物理端口利用率一条 90%、一条 3%就是因为虚拟交换机默认策略和物理侧哈希算法不匹配调完策略流量分布立刻均衡了。4. 验证与排错确认聚合生效和问题定位4.1 查看端口聚合状态交换机和服务器分别怎么看配置完并不代表万事大吉验证这一环必须做细。交换机侧查看聚合状态关注的是成员口状态和 LACP 协商结果。常见的输出会显示每个成员口是否处于 Selected 状态这个状态表示端口已经被选定为聚合口的活动成员。某个口是 Standby说明它被 LACP 协商为备份可以接受但如果你配置的是双链路负载均衡两个口都应该是 Selected只有协议不可用或成员口参数不一致时才会出现 Standby。服务器侧验证就直观得多了。在服务器上你能直接查看绑定接口的运行信息重点关注两个数据当前绑定的物理口数量和绑定模式是否生效。如果只显示一个口另一个口处于 down 状态那一定是线缆或对端端口出了问题如果模式显示不是 802.3ad检查一下驱动参数是不是被覆盖了。连通性测试是必须做的。先 ping 对端网关确认二层通了再用大包测试比如 ping -s 1400 连续发几百个包观察有没有丢包。大包更能暴露链路质量问题因为大包更容易触发重组和缓冲问题小包测试往往掩盖了真实状况。4.2 带宽实测方法不能只测单线程很多人在验证链路聚合效果时习惯用文件拷贝或者 iperf 默认参数测单线程测出来的结果只有 1Gbps就以为聚合没生效。我在前面已经说了原因哈希机制决定单条流只会走一条物理链路。所以验证聚合带宽必须用多路并发流量。实际操作时我会同时发起多条测试流比如从同一台测速工具上开 8 个并发连接打到对端同一台机器上。流量分散后再观察两个物理口会发现两边的速率都有增长两个口加起来能接近聚合后的理论带宽。这时候才能确认聚合带宽真的生效了。还有一个小技巧在测速过程中切回交换机侧看成员口实时流量如果你发现其中一个口始终跑满另一个口在 50% 以下波动说明哈希策略分布不均需要调整哈希因子后重测。这个对比数据能帮你判断问题出在业务侧还是配置侧。4.3 常见问题速查表几个真实踩坑现场把我在实际维护中遇到的典型问题整理成一张速查表应该能帮你省不少时间现象可能原因排查方法解决办法聚合口起了但业务不通两端 VLAN 不一致或类型不匹配对比两端的 VLAN 放行列表统一 VLAN 配置和端口类型带宽始终只有单口速率单流传输或哈希因子不足检查并发数是否足够提高并发调整哈希策略一拔网线业务就断冗余切换失败或 STP 阻塞查看聚合口成员状态变化检查 LACP 超时和 STP 配置聚合口一直处于 downLACP 模式不匹配或物理口故障检查对端端口状态统一模式更换线缆两个口只有一个是 Selected速率不一致或端口优先级导致备用对比成员口速率双工统一物理口参数调整优先级重启后聚合配置丢失服务器侧配置未持久化检查网络配置开机自启写入持久化配置并确认服务自启这里分享一个具体案例。有个环境聚合口状态显示两个成员口都正常但测试发现两个物理口的流量分布极不均匀一个口 900Mbps另一个口只有 50Mbps。我排查后发现这个业务主要是多台应用服务器访问一台数据库服务器源 IP 很多但目的 IP 只有固定两个四层端口也相对固定。哈希因子的有效变量不够大量流被算到了同一个口。后来我把哈希策略从默认的 layer2 改成了 layer34加入端口因子之后流量分布马上改善。可见哈希策略真的不能从模板里复制完就不管。5. 一些经验心得链路聚合别用错地方5.1 别把聚合当成“无缝切换”切换时间要有预期链路聚合确实能扛住单条物理链路故障但这个过程不是零毫秒。LACP 默认的收敛时间可能达到几秒在慢速模式下检测到链路故障再切换流量可能需要三到五秒。对普通业务来说几秒的中断可能无感或可接受但对敏感的核心交易类应用这个时间窗口是没法接受的。如果要加速 LACP 切换可以把 LACP 定时器调成 fast 模式。代价是控制报文交互更频繁会略微增加设备 CPU 开销。更稳妥的做法是在上层再用一套高可用机制兜底比如集群的虚拟 IP 漂移、数据库的双机热备、负载均衡器会话保持等。链路聚合承担的是物理链路冗余不是应用高可用的全部。5.2 哈希不均时怎么调优哈希不均是我在链路聚合排障中遇到最多的一个问题尤其是东西向流量集中的场景。前面已经提到哈希因子的丰富程度决定了流量分布的质量。你首先要做的是搞清楚你的主要流量构成是用户访问虚拟IP的南北向流量还是服务器之间的东西向流量源 IP、目的 IP、四层端口的变化程度分别有多大根据这些特征去调整哈希策略。如果流量集中在同一对 IP 之间四层端口变化较多就选 layer34如果大多是广播域内的二层流量就只能依赖 MAC 哈希效果会差一些。另一个可行办法是在业务层面增加并发度比如应用连接池调大、多线程传输、客户端并发连接数增加让流数量多起来哈希分布更均匀。对于确实无法带来多流的场景比如专线对传大文件我一般会建议直接放弃链路聚合改用其他方式提升带宽比如换成更高带宽的物理端口。链路聚合不是银弹用错地方只会增加配置和维护成本。5.3 什么时候根本不该用链路聚合链路聚合看起来很美好但不是所有场景都适合。如果设备之间只有两条链路而且这两条链路走了不同的物理路径比如一条走厂房 A 的光缆、一条走厂房 B 的光缆从业务连续性角度看这样的两条链路做聚合并不合理因为一旦其中一条路径上的某台设备故障聚合并不能保证另一条链路完好无损。另外如果你的核心诉求只是高可用而不需要带宽叠加比如前端接入服务器只有几百 Mbps 的并发流量两块千兆网卡绑成 mode 1 就足够了完全不需要上 LACP。因为 LACP 模式还要考虑协议协商和哈希均衡维护成本比主备模式高收益却未必体现得出来。最后说一个我自己踩过坑后的体会链路聚合的收益很大程度取决于你对流量的理解。你去动它之前必须搞清楚业务流是单流大文件还是多流小包点是固定五元组还是变化频繁。这个问题想清楚链路聚合的配置过程就会非常顺利想不清楚就会陷入“明明配置没错但带宽就是不涨”的怪圈。多花十分钟做流量特征分析比后面排障两小时划算得多。
说实话端口链路聚合这玩意儿我第一次真正意识到它值钱是在一次数据库备份调优的场景里。当时某台业务服务器的千兆网卡流量已经跑到了 95% 以上备份任务从深夜一路跑到凌晨都搞不完可服务器上明明还有一块网卡闲着利用率不到 5%。那会儿我脑子里第一个冒出来的解决办法就是把两块网卡绑成一个逻辑接口这就是今天想跟你好好聊的端口链路聚合也叫链路聚合、网卡绑定、Bonding、Teaming不同厂商叫法不一样本质上是同一件事。端口链路聚合做的事情并不复杂把两台设备之间的多条物理链路捆绑成一条逻辑链路。它带来的好处有两个一是带宽叠加比如把两个千兆口聚合成一个逻辑口理论带宽就变成了 2Gbps二是链路冗余物理链路里任何一条断开流量会自动切换到存活的那条链路上业务不会因为一根网线被拔掉就中断。这篇文章我会把链路聚合从原理到实操完整拆一遍。你会看到静态聚合和 LACP 动态聚合到底怎么选、交换机侧和服务器侧的配置如何对齐、用什么方法验证聚合是真的生效了以及我在实际维护中踩过的几个典型坑。无论你是在管物理服务器、做虚拟化集群还是想在家里 NAS 上折腾链路聚合这篇文章的思路都适用。1. 链路聚合的价值在哪里先看清楚它解决什么问题1.1 带宽叠加与链路冗余一次解决两个痛点先说带宽叠加。别把链路聚合想得太神它不是一个 1Gbps 的端口加另一个 1Gbps 的端口就简单等于一个 2Gbps 的端口。逻辑链路确实拥有 2Gbps 的汇聚带宽但具体能跑多快取决于你跑的是什么样的流量。如果是单条 TCP 连接比如你从服务器上拉一个大文件这种单流传输走的是哈希计算选中的某一条物理链路最多只能跑满一个物理口的带宽。只有当系统里同时存在大量并发连接时流量才会被分散到不同的物理口上聚合带宽的优势才真正体现出来。这一点后面在验证部分我还会详细说。再说冗余。链路聚合的冗余逻辑很有意思因为聚合组里的成员口之间互为备份当一个物理口出现故障流量会自动重新哈希到其他健康的成员口上。这个过程对上层业务基本是透明的因为逻辑接口始终处于 up 状态应用的 TCP 连接不会因为底层链路切换而断开。这一点比“两块网卡配两个 IP靠路由切换”的方案要优雅得多也快得多。最早链路聚合的标准是 IEEE 802.3ad后来更新成了 802.1AX。标准的核心工作包括在聚合组里维护成员端口状态、根据哈希规则把流量分布到各成员口、以及对端设备通过协议报文协商聚合参数。理解了这个标准再看下面两种模式的区别就很容易了。1.2 两种主流模式静态手工聚合与 LACP 动态协商链路聚合按协商方式分成两大类一类是静态手工聚合另一类是基于 LACP 的动态聚合。静态手工聚合的逻辑最简单两台设备上手动把端口加到同一个聚合组里配置对了就能通配错了只能自己背锅。它不跑任何协商协议所以只要两端配置一致链路就能起来。缺点是如果某条物理链路故障设备无法通过协议感知端口状态变化其实也能感知因为端口物理 down 了聚合组也知道要把流量切走。但它无法判断对端是不是还正常比如网线接触不良导致端口处于半连通状态这种时候静态聚合基本没有容错能力。LACP全称 Link Aggregation Control Protocol是标准里推荐的方式。启用 LACP 的两个设备之间会定时交换 LACPDU 报文报布里带着端口优先级、系统优先级、端口号这些信息双方通过这些报文协商出谁是主端口、谁是备份端口。一旦某条物理链路故障LACP 能迅速感知并把故障端口从聚合组里剔除流量自动切换到其他正常端口。用一个表格把两种模式放在一起看差异就很直观了对比维度静态手工聚合LACP 动态聚合协商机制无协议交互定时交换 LACPDU配置复杂度较低略高需配置主备/活动状态故障感知仅感知端口物理状态可感知对端状态和链路质量适用场景对端设备不支持 LACP 或必须用最简单方式生产环境首选排错难度不易定位逻辑层问题可通过协议状态快速定位我自己在维护环境里凡是能做 LACP 的都尽量用 LACP静态手工聚合只用来应急或者对端设备确实不支持。不是因为静态聚合不行而是生产环境里多一层协议状态就多一个排障抓手尤其是跨机房跨设备的长链路LACP 的状态信息能帮你省掉大量排查时间。1.3 核心名词扫盲聚合组、成员口、主接口、LACPDU这块给刚入门的朋友扫个盲后面配置的时候你看到这些词就不会懵。聚合组Aggregation Group是所有成员口组成的集合比如你把交换机的两个口和服务器网卡的两个口绑在一起这四个端口分别属于两端各自的一个聚合组。逻辑上每个设备上只有一个聚合接口对外呈现服务器端叫 bond0交换机端叫聚合口或端口通道名字不同含义一样。成员口就是聚合组里的物理端口它们可以是电口也可以是光口但一个聚合组里最好保持速率和双工模式一致否则会因为成员口速率不一致导致流量分配异常。主接口对应两端协商出来的主用物理口LACP 会根据系统优先级和端口优先级选出一个主端口其他端口进入备用或分发状态。如果主端口挂了备用端口自动顶上。LACPDU 是 LACP 的控制报文默认周期性地在两端的聚合口之间发送。报文里携带的设备优先级、端口优先级、系统 ID 等信息决定了对端如何判断哪些端口能够加入聚合组。理解了这些名词下面看配置就会顺手很多。2. 动手前的规划这些检查没做就等着返工2.1 链路聚合不能保证单条流跑满先搞懂哈希机制链路聚合的流量分配机制核心是一个哈希函数。设备会根据报文里的某些字段比如源 MAC、目的 MAC、源 IP、目的 IP、四层端口等通过计算得到结果然后根据结果把这条数据流映射到某一根物理链路上。用高速公路打比方聚合链路相当于一条四车道的公路但每一辆车从头到尾只能在一条车道上开不能拆成两半同时走两条车道。所以只有当车流量足够多、足够分散时四条车道才能都被用起来。如果你这条路一天只跑一辆顶级大货车那其他三条车道只能是空的。这个机制引出一个特别重要的结论如果你的业务是单线程大文件传输、单连接数据库复制这类单一流量模型链路聚合几乎不能带来带宽提升。判断一个场景适不适合上链路聚合先问自己我这里是不是有很多并发连接用户访问数量多不多如果答案是肯定的链路聚合才有实际意义。哈希策略也不是越复杂越好。有些设备支持基于 MAC、基于 IP、基于四层端口组合等不同策略选策略时要结合网内流量类型。如果大多数流量是同一对服务器之间的东西向流量哈希因子里没有足够多的变量就很容易出现某个物理口拥塞、其他口闲置的状况。后面第五部分我会讲怎么调优这个问题。2.2 交换机侧与服务器侧的环境检查清单在我见过的问题里相当大一部分不是配置写错而是环境检查没做全。这里列一份我每次做链路聚合前都会过一遍的清单检查项检查标准漏掉可能出的问题物理端口速率所有成员口速率一致建议相同类型聚合失败或流量不均双工模式两端必须都是全双工且一致高延迟、丢包、协商错误VLAN 配置成员口的 VLAN 划分一致聚合口起来了但二层不通对端设备能力确认是否支持 LACP、支持多少条聚合协商不上端口起不来链路物理路径多条链路是否走同一设备、是否跨板卡单点故障时冗余失效服务器网卡固件网卡驱动和固件是否支持 bonding绑定模式异常网卡脱离端口归属确认拔线前确认物理口与逻辑口对应关系误操作导致业务中断其中最容易踩的坑是 VLAN 配置不一致。有一次我给某个客户做链路聚合交换机侧聚合口是 trunk 口放行了 VLAN 10 和 20服务器侧却忘了配置虚拟接口的 VLAN 标签结果聚合链路虽然起来了但 VLAN 10 的流量完全不通。这种问题不会让端口 down表现是“聚合正常但业务异常”排查起来特别迷惑。2.3 一个规划案例数据库服务器做 LACP 接入拿一个典型场景来举例。假设你需要把一台数据库服务器接入机房网络服务器上有两个千兆电口交换机是机架顶部的一台三层交换机业务特点是存在大量来自应用服务器的并发 SQL 查询同时还有定时的数据同步任务。在这种场景下我会这样规划两个千兆口加入同一个聚合组采用 LACP 动态模式交换机侧和服务器侧都配置为 LACP 主动模式。数据库服务器两个口分别插到交换机的两个不同端口上中间不能串接其他设备。VLAN 规划上数据库 VLAN 和应用 VLAN 分开聚合口以 trunk 模式放行需要的 VLAN。这套方案的收益点有两个一是并发查询流量能被哈希到两条物理链路上避免了单口拥塞二是任何一条物理链路故障时应用流量自动切换数据库连接不会中断省去了在应用层做连接池重连的麻烦。3. 配置实操交换机和服务器两边如何对齐3.1 交换机侧聚合配置的通用逻辑不同品牌的交换机配置命令风格相差很大有的叫 Eth-Trunk有的叫 Port-Channel有的叫 Bond 接口。但核心逻辑高度一致总共四步创建聚合口、把物理口加入聚合口、配置聚合口属性、确认成员口状态。以最常见的命令行风格示例配置一个 LACP 动态聚合口大致长这样interface port-channel 1 switchport mode trunk switchport trunk allowed vlan 10,20 lacp mode active ! interface GigabitEthernet0/1 channel-group 1 mode active ! interface GigabitEthernet0/2 channel-group 1 mode active这段配置里port-channel 1 是逻辑聚合口把它设为 trunk 模式放行 VLAN 10 和 20。两个物理口都用 channel-group 1 mode active 加入聚合组mode active 表示对端主动发送 LACPDU也就是 LACP 的主动模式。有一点特别重要被加入聚合组的物理口上不应该再保留独立的 VLAN、端口模式等配置否则交换机大概率会报配置冲突。有的设备允许把端口加入聚合组后自动继承聚合口上的二层属性有的设备要求你先去把物理口上的配置清干净再执行加入命令。建议在配置前先检查一下物理口配置避免中途报错。配置完成后观察聚合口状态确认两个成员口都处于 Selected 或者 Up 状态。如果某个端口一直处于 Standby 或 Down说明协商有问题不要急着继续配服务器端先把这个状态解决掉。3.2 服务器侧 bonding 配置mode 4 是最佳选择服务器端的网口绑定在大多数系统里都是通过 bonding 驱动实现的。我自己的习惯是能上 LACP 环境就一律用 mode 4也就是 802.3ad 动态链路聚合模式。服务器网口绑定的配置方式因系统而异但核心参数是一致的。下面是一个通用风格的配置示意# bond0 逻辑接口 BOND_DRIVER_OPTSmode4 miimon100 xmit_hash_policylayer34参数分解一下mode4 表示使用 802.3ad 动态链路聚合和交换机的 LACP 对接miimon100 表示每 100 毫秒检查一次物理链路状态这个值用来感知网线断开和链路故障xmit_hash_policylayer34 表示哈希策略使用 IP 地址加四层端口作为哈希因子对流量的均衡效果通常比默认的 layer2 策略更好。配置完逻辑接口后需要把两个物理网口作为 slave 添加到 bond0 里。这里有个容易犯的错绑定模式下物理网口本身不应该配置独立的 IP 地址所有 IP 配在 bond0 上。如果你在 eth0 和 eth1 上还留着 IP就会出现地址冲突或者流量完全不走聚合口的问题。下面是几种常见 bonding 模式的对比方便你理解为什么默认不要乱改模式名称特点适用场景mode 0balance-rr轮询逐包分发带宽利用高但可能乱序特定高性能场景较少直接用mode 1active-backup主备模式不叠加带宽仅冗余无法使用 LACP 的高可用场景mode 4802.3adLACP 动态协商带宽叠加 冗余生产环境首选mode 6balance-alb自适应负载均衡无需交换机支持交换机不支持 LACP 时特别提醒一句很多人听“绑定”就以为带宽一定翻倍不做 LACP 协议对接直接配了 mode 1结果带宽完全没变化。mode 1 是主备切换不是负载均衡两块网卡只有一块在干活另一块只在故障时顶上。想让带宽叠加要么用 mode 0、mode 6 这类不需要交换机支持的均衡模式要么就用 mode 4 加 LACP没有第三条路。3.3 配置匹配自检对照检查不出幺蛾子链路聚合出问题有一大半是因为两端配置不对齐。我在做完两边配置后会习惯性做一遍匹配自检最常见的就是这几项。先看模式匹配LACP 对 LACP静态对静态。LACP 主动模式对被动模式可以协商但主动汰被动要保证至少有一端是 active。如果交换机是 active服务器端却配成了 mode 1两边就会互不承认端口状态迟迟起不来。再看速率和双工匹配全部成员口必须统一速率双工都设为全双工。半双工模式下跑聚合是非常糟糕的会产生大量冲突和重传。然后是 VLAN 匹配交换机的聚合口放行了哪些 VLAN服务器侧对应的 vlan 子接口也要对得上两边 mismatch 的报错不会直接在聚合状态里显示出来但业务流量就是不通。还有一个细节是 STP 与聚合的配合。有的交换机默认在聚合口上启用了生成树协议端口从阻塞到转发需要几十秒这就导致链路聚合看起来“通了”但实际流量无法立刻走。如果设备支持把聚合口设置为 Portfast 或边缘端口特性可以让端口状态快速切换到转发。3.4 其他场景交换机互联和虚拟化平台的对接链路聚合不只在服务器接入点有用。两台交换机之间如果存在多条物理链路同样需要做成聚合链路口否则生成树协议会把多余的链路阻塞掉带宽白白浪费。交换机互联场景下的聚合配置思路差不多唯一要特别注意的是如果两台交换机属于不同厂商尽量都采用 LACP 标准模式静态聚合在跨厂商场景下可能会因为参数理解差异导致协商不上。虚拟化平台和物理交换机的对接又是另一种情况。虚拟交换机上的上行链路可以做链路聚合然后在物理交换机侧配置对应的聚合口。这里的关键是虚拟交换机里的负载均衡策略要和物理交换机侧的哈希策略匹配否则会出现虚拟机的流量集中在某一条物理上行链路上其他链路浪费。我见过某次虚拟化集群里物理端口利用率一条 90%、一条 3%就是因为虚拟交换机默认策略和物理侧哈希算法不匹配调完策略流量分布立刻均衡了。4. 验证与排错确认聚合生效和问题定位4.1 查看端口聚合状态交换机和服务器分别怎么看配置完并不代表万事大吉验证这一环必须做细。交换机侧查看聚合状态关注的是成员口状态和 LACP 协商结果。常见的输出会显示每个成员口是否处于 Selected 状态这个状态表示端口已经被选定为聚合口的活动成员。某个口是 Standby说明它被 LACP 协商为备份可以接受但如果你配置的是双链路负载均衡两个口都应该是 Selected只有协议不可用或成员口参数不一致时才会出现 Standby。服务器侧验证就直观得多了。在服务器上你能直接查看绑定接口的运行信息重点关注两个数据当前绑定的物理口数量和绑定模式是否生效。如果只显示一个口另一个口处于 down 状态那一定是线缆或对端端口出了问题如果模式显示不是 802.3ad检查一下驱动参数是不是被覆盖了。连通性测试是必须做的。先 ping 对端网关确认二层通了再用大包测试比如 ping -s 1400 连续发几百个包观察有没有丢包。大包更能暴露链路质量问题因为大包更容易触发重组和缓冲问题小包测试往往掩盖了真实状况。4.2 带宽实测方法不能只测单线程很多人在验证链路聚合效果时习惯用文件拷贝或者 iperf 默认参数测单线程测出来的结果只有 1Gbps就以为聚合没生效。我在前面已经说了原因哈希机制决定单条流只会走一条物理链路。所以验证聚合带宽必须用多路并发流量。实际操作时我会同时发起多条测试流比如从同一台测速工具上开 8 个并发连接打到对端同一台机器上。流量分散后再观察两个物理口会发现两边的速率都有增长两个口加起来能接近聚合后的理论带宽。这时候才能确认聚合带宽真的生效了。还有一个小技巧在测速过程中切回交换机侧看成员口实时流量如果你发现其中一个口始终跑满另一个口在 50% 以下波动说明哈希策略分布不均需要调整哈希因子后重测。这个对比数据能帮你判断问题出在业务侧还是配置侧。4.3 常见问题速查表几个真实踩坑现场把我在实际维护中遇到的典型问题整理成一张速查表应该能帮你省不少时间现象可能原因排查方法解决办法聚合口起了但业务不通两端 VLAN 不一致或类型不匹配对比两端的 VLAN 放行列表统一 VLAN 配置和端口类型带宽始终只有单口速率单流传输或哈希因子不足检查并发数是否足够提高并发调整哈希策略一拔网线业务就断冗余切换失败或 STP 阻塞查看聚合口成员状态变化检查 LACP 超时和 STP 配置聚合口一直处于 downLACP 模式不匹配或物理口故障检查对端端口状态统一模式更换线缆两个口只有一个是 Selected速率不一致或端口优先级导致备用对比成员口速率双工统一物理口参数调整优先级重启后聚合配置丢失服务器侧配置未持久化检查网络配置开机自启写入持久化配置并确认服务自启这里分享一个具体案例。有个环境聚合口状态显示两个成员口都正常但测试发现两个物理口的流量分布极不均匀一个口 900Mbps另一个口只有 50Mbps。我排查后发现这个业务主要是多台应用服务器访问一台数据库服务器源 IP 很多但目的 IP 只有固定两个四层端口也相对固定。哈希因子的有效变量不够大量流被算到了同一个口。后来我把哈希策略从默认的 layer2 改成了 layer34加入端口因子之后流量分布马上改善。可见哈希策略真的不能从模板里复制完就不管。5. 一些经验心得链路聚合别用错地方5.1 别把聚合当成“无缝切换”切换时间要有预期链路聚合确实能扛住单条物理链路故障但这个过程不是零毫秒。LACP 默认的收敛时间可能达到几秒在慢速模式下检测到链路故障再切换流量可能需要三到五秒。对普通业务来说几秒的中断可能无感或可接受但对敏感的核心交易类应用这个时间窗口是没法接受的。如果要加速 LACP 切换可以把 LACP 定时器调成 fast 模式。代价是控制报文交互更频繁会略微增加设备 CPU 开销。更稳妥的做法是在上层再用一套高可用机制兜底比如集群的虚拟 IP 漂移、数据库的双机热备、负载均衡器会话保持等。链路聚合承担的是物理链路冗余不是应用高可用的全部。5.2 哈希不均时怎么调优哈希不均是我在链路聚合排障中遇到最多的一个问题尤其是东西向流量集中的场景。前面已经提到哈希因子的丰富程度决定了流量分布的质量。你首先要做的是搞清楚你的主要流量构成是用户访问虚拟IP的南北向流量还是服务器之间的东西向流量源 IP、目的 IP、四层端口的变化程度分别有多大根据这些特征去调整哈希策略。如果流量集中在同一对 IP 之间四层端口变化较多就选 layer34如果大多是广播域内的二层流量就只能依赖 MAC 哈希效果会差一些。另一个可行办法是在业务层面增加并发度比如应用连接池调大、多线程传输、客户端并发连接数增加让流数量多起来哈希分布更均匀。对于确实无法带来多流的场景比如专线对传大文件我一般会建议直接放弃链路聚合改用其他方式提升带宽比如换成更高带宽的物理端口。链路聚合不是银弹用错地方只会增加配置和维护成本。5.3 什么时候根本不该用链路聚合链路聚合看起来很美好但不是所有场景都适合。如果设备之间只有两条链路而且这两条链路走了不同的物理路径比如一条走厂房 A 的光缆、一条走厂房 B 的光缆从业务连续性角度看这样的两条链路做聚合并不合理因为一旦其中一条路径上的某台设备故障聚合并不能保证另一条链路完好无损。另外如果你的核心诉求只是高可用而不需要带宽叠加比如前端接入服务器只有几百 Mbps 的并发流量两块千兆网卡绑成 mode 1 就足够了完全不需要上 LACP。因为 LACP 模式还要考虑协议协商和哈希均衡维护成本比主备模式高收益却未必体现得出来。最后说一个我自己踩过坑后的体会链路聚合的收益很大程度取决于你对流量的理解。你去动它之前必须搞清楚业务流是单流大文件还是多流小包点是固定五元组还是变化频繁。这个问题想清楚链路聚合的配置过程就会非常顺利想不清楚就会陷入“明明配置没错但带宽就是不涨”的怪圈。多花十分钟做流量特征分析比后面排障两小时划算得多。
