3. Bond模式详解：Balance-slb模式原理与适用场景
好，咱们接着聊Bond模式。前面说了主备模式，说白了就是一条路走到黑，另一条路闲着。那Balance-slb模式呢？它才是真正意义上的“链路聚合”——多条链路同时干活，带宽叠加，流量分担。
我个人习惯把Balance-slb叫做“基于源MAC的负载均衡”。为什么叫这个？因为它选路的依据，就是数据包的源MAC地址和目的MAC地址。你想想看，交换机看到一对MAC地址，就把它们绑定到一条链路上，后续这对MAC的通信都走这条路。
3.1 Balance-slb的核心原理
Balance-slb的全称是Source Load Balancing，也就是源端负载均衡。它的哈希算法很简单：
hash = (src_mac XOR dst_mac) % slave_count嗯，这里要注意：它只用到MAC地址，不看IP，更不看端口。所以同一个虚拟机发往同一个网关的流量，永远走同一条链路。这既是优点，也是局限。
我在项目中遇到过这样一个场景：两个虚拟机做数据库主从同步，流量特别大。结果发现一条链路跑满了，另一条链路几乎空着。为什么？因为这对主从的MAC地址是固定的，哈希结果永远不变，所有流量都挤在一条链路上。
关键点：Balance-slb的负载均衡粒度是“流”，而不是“包”。同一个流（相同源目MAC）的所有报文，都会走同一条链路。这保证了报文不乱序，但牺牲了均衡性。
3.2 适用场景分析
那Balance-slb到底适合什么场景？我总结了三类：
- 虚拟机密度高、MAC地址多的场景——比如OpenStack计算节点，上面跑着几十上百台VM。每个VM的MAC都不同，哈希结果自然分散，链路利用率就高。
- 东西向流量为主的环境——虚拟机之间互相通信，源目MAC变化多，负载均衡效果好。我见过一个部署了200台VM的集群，用Balance-slb把4条10G链路跑到了平均75%的利用率，相当不错。
- 对端交换机不支持LACP的场景——有些老旧交换机只支持静态聚合，或者压根不支持聚合。这时候Balance-slb就是救命稻草，它不需要对端配合，自己就能干活。
我的建议：如果你不确定对端交换机是否支持LACP，先用Balance-slb准没错。它兼容性最好，配置也最简单。
3.3 避坑指南
我曾经踩过一个坑，说出来你可能不信。有一次给客户做网络改造，用了Balance-slb模式，结果发现某个业务总是丢包。排查了半天，最后发现是对端交换机的MAC地址表老化时间太短。
为什么会这样？因为Balance-slb模式下，OVS发出的报文源MAC是固定的（比如物理网卡的MAC），但目的MAC会变。交换机学习MAC地址时，如果老化时间太短，频繁刷新，就会导致流量中断。嗯，这个坑我印象特别深。
另外还有一个要注意的点：Balance-slb不支持VLAN感知。如果你在Bond接口上配置了多个VLAN，每个VLAN的流量还是会按照MAC地址哈希。这可能导致某些VLAN的流量集中到一条链路上。
警告：不要在Balance-slb模式下使用“源MAC固定、目的MAC单一”的流量模型。比如一个NFS服务器挂载给多个客户端，所有客户端都访问同一个服务器MAC，哈希结果会全部命中同一条链路，带宽瓶颈瞬间出现。
3.4 配置示例
配置Balance-slb其实很简单，就一行命令的事：
ovs-vsctl add-bond br0 bond0 eth0 eth1 bond_mode=balance-slb如果你想查看当前Bond的负载情况，可以用：
ovs-appctl bond/show bond0输出里会显示每条链路的流量统计，以及哈希分布情况。我习惯在配置完Bond后，先跑一个压力测试，看看链路利用率是否均匀。如果发现某条链路明显偏高，那就得检查一下MAC地址的分布了。
3.5 性能对比
最后给个表格，直观对比一下Balance-slb和其他模式：
| 特性 | Balance-slb | Active-backup | LACP (balance-tcp) |
|---|---|---|---|
| 带宽利用率 | 中（依赖MAC分布） | 低（单链路） | 高（基于L4哈希） |
| 对端要求 | 无 | 无 | 支持LACP |
| 配置复杂度 | 低 | 低 | 中 |
| 适用场景 | 多VM、东西向流量 | 高可用、低带宽需求 | 高性能、数据中心 |
说白了，Balance-slb是个“万金油”模式。它不像主备那样浪费带宽，也不像LACP那样依赖交换机。如果你刚开始接触OVS Bond，从Balance-slb入手准没错。等你把它的脾气摸透了，再考虑升级到LACP也不迟。