七种模式详解与生产环境配置实战)
1. 双网卡绑定到底解决什么问题很多运维同行第一次接触bond都是被同一个场景逼出来的机房里一台服务器插了两块网卡分别接在两台接入交换机上结果某天一台交换机重启或者一条网线被误拔业务直接断了。明明有两块网卡、两条链路为什么没有起到冗余作用因为默认情况下两块网卡是各自独立的内核协议栈会按路由表选一条出口另一条基本闲置链路切换全靠人工介入业务感知到的就是实打实的中断。双网卡绑定bonding要解决的核心问题就三个冗余、带宽、负载。把多块物理网卡聚合成一块逻辑网卡对外只暴露一个IP和MAC底层由内核的bonding驱动统一调度。链路层面任何一条物理链路挂掉流量自动切到剩余链路切换时间通常在毫秒级上层应用基本无感带宽层面某些模式可以把多块网卡的吞吐叠加起来比如四块千兆网卡聚合成接近四千兆的通道负载层面多块网卡可以分摊流量避免单块网卡成为瓶颈。这套机制适合谁我把它分成三类人。第一类是刚接手机房或者虚拟化平台的运维需要给核心业务做链路冗余这是最刚需的场景。第二类是搭建高可用集群的工程师比如数据库主从、负载均衡后端网络层不能有单点。第三类是准备考网络相关认证或者做实验的同学bond是绕不开的基础知识点理解它对后面学网桥、VLAN、聚合交换机配置都有帮助。需要提前说清楚一个认知bond不是万能的。它解决的是本机网卡到交换机这一段的冗余如果两块网卡接的是同一台交换机那交换机本身挂了照样断。所以真正要发挥价值通常要配合交换机侧的链路聚合比如静态聚合或动态协商让两端都感知到这是一条逻辑链路。这一点后面会展开讲。2. 七种bond模式的核心差异与选型逻辑bonding驱动支持多种工作模式模式编号从0到6每种模式的冗余能力、带宽叠加能力、对交换机的要求都不一样。选错模式是新手最容易踩的坑所以这一节把每种模式的底层逻辑讲透。2.1 mode 0 平衡轮询带宽叠加但需要交换机配合mode 0也就是balance-rr数据包按顺序轮流从每块网卡发出。假设两块千兆网卡理论上出口带宽接近两千兆。它的负载方式是逐包轮询第一个包走eth0第二个包走eth1第三个包又走eth0如此循环。问题在于同一个TCP连接的数据包如果从不同物理链路出去到达对端时可能乱序。对端网卡和协议栈要重新排序乱序严重时性能反而下降。所以mode 0对交换机有要求两端必须做链路聚合让交换机知道这些网卡属于同一个逻辑链路否则交换机可能把从不同口收到的同一MAC的包当成MAC漂移触发告警甚至阻断。我实测下来的经验是mode 0适合大文件传输、备份流量这类对单连接顺序不敏感、但需要总吞吐的场景。如果是大量小连接轮询反而可能因为乱序拖慢速度。2.2 mode 1 主备最稳的冗余方案mode 1也就是active-backup同一时刻只有一块网卡处于active状态其余都是backup。active网卡挂了bonding驱动把MAC和IP迁移到backup网卡上对外看起来还是同一个逻辑接口。这个模式最大的好处是不需要交换机做任何特殊配置两块网卡可以接在不同交换机上甚至接在不同品牌的交换机上都没问题。因为同一时刻只有一个口在收发交换机不会看到MAC漂移。切换时间取决于链路检测机制用MII监控的话通常在几百毫秒以内。代价是带宽不叠加一块千兆active另一块千兆backup纯闲置。所以mode 1的定位很明确要冗余不要带宽。数据库服务器、认证服务器、核心网关这类对稳定性要求极高、流量又没到网卡上限的场景mode 1是首选。2.3 mode 2 平衡异或与mode 4 动态聚合mode 2是balance-xor按源MAC和目标MAC做异或运算决定走哪块网卡。同一个目标MAC的流量固定走同一块网卡所以单连接不会乱序但不同目标之间能分摊。它同样需要交换机做聚合配置。mode 4是802.3ad也就是标准的动态链路聚合基于LACP协议。这是企业环境里最推荐的模式前提是交换机支持LACP并且配置正确。它的负载算法比mode 2更丰富可以按源MAC、目标MAC、源IP、目标IP、源端口、目标端口的组合做哈希。两端通过LACPDU报文协商链路状态变化能实时感知。mode 4的坑在于哈希算法决定了单条连接的带宽上限。比如按源IP目标IP哈希那么两台主机之间的一条连接永远走同一块网卡最多只能跑满一块网卡的带宽。想要单连接突破单卡上限得用支持逐包分发的模式但那样又会乱序。这是物理规律没有两全其美的方案。2.4 mode 3、5、6 的适用边界mode 3是broadcast所有包从所有网卡发出冗余性最强但浪费带宽实际生产几乎不用只在极特殊的容错场景出现。mode 5是balance-tlb自适应发送负载均衡不需要交换机配置。它根据每块网卡的当前负载分配发送流量接收流量仍然只走active网卡。如果active网卡接收失败另一块接管接收。适合下载少、上传多的场景。mode 6是balance-alb在mode 5基础上增加了接收负载均衡通过ARP协商让不同对端把包发到不同网卡。同样不需要交换机配置是不用交换机配合时带宽利用率最高的模式。但它的接收均衡依赖ARP对某些网络环境兼容性一般。下面这张表把关键差异列清楚选型时直接对照模式名称冗余带宽叠加需交换机配置典型场景0balance-rr有是需要大流量备份1active-backup有否不需要核心业务冗余2balance-xor有是需要多目标负载3broadcast有否不需要特殊容错4802.3ad有是需要LACP企业标准聚合5balance-tlb有发送叠加不需要上传为主6balance-alb有收发叠加不需要无交换机配合提示生产环境如果交换机可控优先选mode 4交换机不可控或跨设备接法选mode 1保稳追求无配置下的带宽利用选mode 6。3. 动手前的准备工作与关键参数确认bond配置失败十有八九不是命令写错而是准备工作没做。我见过太多人上来就改配置文件结果网络断了连不上机器只能去机房接显示器。这一节把动手前必须确认的东西列全。3.1 确认网卡名称与驱动状态第一步永远是看清楚机器上有哪些网卡。用ip link或者nmcli device status都能列出来。注意现在很多发行版用一致性网络设备命名网卡名可能是eno1、ens33、enp3s0这种不再是eth0、eth1。配置文件里的DEVICE字段必须和实际名称完全一致大小写都不能错。ip link show # 或者 nmcli device status同时确认bonding模块是否可用modinfo bonding如果这条命令报模块不存在说明内核没带bonding驱动需要装对应内核模块包。主流发行版默认都带但精简版系统可能没有。3.2 确认交换机侧配置这一步最容易被忽略。如果打算用mode 4交换机上必须先把对应的两个口配成LACP聚合组并且聚合组的模式要和服务器端匹配。交换机侧没配服务器侧配了mode 4结果就是链路起不来或者起来了但流量异常。如果用的是mode 1交换机侧不需要任何配置但要注意两块网卡接的交换机之间最好有互联否则备卡所在的交换机如果和主卡交换机不通切换后流量出不去。我个人的习惯是动手前先和网络同事确认交换机端口配置把聚合组编号、模式、VLAN信息都对齐再动服务器。这个沟通成本远比事后排查低。3.3 备份现有网络配置改网络配置前把当前配置备份一份。不同发行版配置文件位置不同传统RHEL/CentOS/etc/sysconfig/network-scripts/ifcfg-*新版用NetworkManager/etc/NetworkManager/system-connections/Debian/Ubuntu/etc/network/interfaces或/etc/netplan/# 备份示例 cp -r /etc/sysconfig/network-scripts /root/network-scripts.bak注意如果是远程SSH操作强烈建议开一个带外管理通道比如IPMI、串口或者让同事在机房待命。bond配置过程中网络会短暂中断配错了就彻底失联。3.4 规划IP与网关归属bond的逻辑接口需要配IP物理网卡不再配IP。原来配在eth0上的IP要迁移到bond0上。网关也配在bond0上。物理网卡的配置文件里只保留MASTERbond0和SLAVEyes不要有IPADDR、GATEWAY这些字段否则会冲突。如果原来有多个IP或者策略路由迁移时要一并考虑。我建议先在测试环境走一遍确认路由、DNS、防火墙规则都正常再上生产。4. 两种主流配置方式实操配置bond有两条路传统配置文件方式和NetworkManager方式。老系统用前者新系统推荐后者。两种都讲按你的环境选。4.1 传统ifcfg配置文件方式以RHEL/CentOS系为例假设两块网卡是ens33和ens34要做mode 1主备。先创建bond0的配置文件/etc/sysconfig/network-scripts/ifcfg-bond0DEVICEbond0 TYPEBond BONDING_MASTERyes BOOTPROTOstatic IPADDR192.168.1.100 NETMASK255.255.255.0 GATEWAY192.168.1.1 DNS1223.5.5.5 ONBOOTyes BONDING_OPTSmode1 miimon100 primaryens33这里几个参数要解释清楚。mode1是主备模式。miimon100表示每100毫秒用MII机制检测一次链路状态数值越小检测越灵敏但开销越大100是常用值。primaryens33指定ens33为首选active网卡不写的话由驱动自己选。然后改两块物理网卡的配置。ifcfg-ens33DEVICEens33 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyesifcfg-ens34同理只是DEVICE改成ens34。改完后重启网络systemctl restart network # 或者 nmcli connection reload验证cat /proc/net/bonding/bond0这个文件会显示当前active的网卡、每块网卡的状态、链路检测统计。看到Currently Active Slave: ens33就说明起来了。4.2 NetworkManager的nmcli方式新系统上NetworkManager是默认网络管理工具用nmcli配置更干净。还是ens33和ens34做mode 1。# 创建bond接口 nmcli connection add type bond con-name bond0 ifname bond0 \ bond.options modeactive-backup,miimon100 # 配置IP nmcli connection modify bond0 ipv4.addresses 192.168.1.100/24 nmcli connection modify bond0 ipv4.gateway 192.168.1.1 nmcli connection modify bond0 ipv4.dns 223.5.5.5 nmcli connection modify bond0 ipv4.method manual # 把物理网卡加入bond nmcli connection add type ethernet con-name bond0-slave1 ifname ens33 master bond0 nmcli connection add type ethernet con-name bond0-slave2 ifname ens34 master bond0 # 启动 nmcli connection up bond0nmcli的好处是配置即时生效不用重启整个网络服务而且配置持久化在/etc/NetworkManager/system-connections/下重启不丢。4.3 mode 4的配置差异如果要用mode 4配置里改两处。bond.options改成bond.options mode802.3ad,miimon100,lacp_ratefast,xmit_hash_policylayer34lacp_ratefast表示每秒发一次LACPDU默认slow是每30秒一次fast切换更快。xmit_hash_policylayer34表示按IP和端口做哈希负载更均匀。交换机侧要配成LACP active模式两端才能协商成功。验证mode 4是否协商成功看/proc/net/bonding/bond0里的LACP rate和Aggregator ID如果聚合器ID一致且状态是up说明协商正常。5. 链路切换验证与性能测试配置完不验证等于没配。这一节讲怎么确认冗余真的生效、带宽到底叠加了多少。5.1 主动断链测试最直接的验证方法就是拔网线或者down掉一块网卡。远程操作的话用ip link set ens33 down模拟。# 查看当前active cat /proc/net/bonding/bond0 | grep Currently Active # down掉active网卡 ip link set ens33 down # 再查看应该切到ens34 cat /proc/net/bonding/bond0 | grep Currently Active同时开一个持续的ping观察丢包情况。mode 1切换通常丢1到3个包业务基本无感。如果丢包严重或者切换后不通检查备卡链路、交换机端口、以及备卡所在交换机是否有到网关的路径。5.2 带宽叠加验证mode 0、2、4、6理论上能叠加带宽但验证时要注意方法。用单条scp或者单条iperf连接往往只能跑满一块网卡的带宽因为哈希算法把这条连接固定到了一块网卡上。要验证总带宽得开多条并发连接。# 服务端 iperf3 -s # 客户端开4条并发 iperf3 -c 192.168.1.100 -P 4如果4条并发加起来接近4倍单卡带宽说明聚合生效。如果还是单卡带宽检查哈希策略和交换机聚合配置。5.3 监控与日志bond的状态变化会记录在内核日志里用dmesg或者journalctl -k能看到。比如dmesg | grep -i bond会看到类似bond0: link status definitely up for interface ens33的记录。生产环境建议把bond状态纳入监控定期采集/proc/net/bonding/bond0的内容active网卡变化时告警。6. 踩坑实录与排查速查bond的坑集中在几个地方我把这些年遇到的和同行反馈的整理成速查表。现象可能原因排查方向bond0起不来物理网卡配置有IP冲突检查slave配置是否残留IPADDR切换后不通备卡交换机无上行路径确认两台交换机互联mode 4协商失败交换机未配LACP核对交换机聚合组配置带宽不叠加哈希策略导致单连接单卡改xmit_hash_policy或开多连接重启后配置丢失NetworkManager覆盖用nmcli持久化配置MAC地址漂移告警mode 0/2未配交换机聚合改用mode 1或配交换机几个独家经验。第一miimon和downdelay要配合用。miimon检测到链路down后如果立即切换可能因为链路抖动导致频繁切换。加downdelay200表示检测到down后等200毫秒再切避免抖动误判。第二mode 1的primary网卡要选链路质量好的那块。如果primary那块经常抖动会频繁切换反而影响稳定性。第三虚拟化环境里bond要慎用mode 0。虚拟交换机对乱序包的处理和物理交换机不同mode 0在虚机里可能表现很差建议用mode 1或mode 4。第四改完配置先别急着重启网络。用nmcli connection up单独拉起bond0确认没问题再重启整个网络服务减少断网时间。第五记录交换机端口和bond的对应关系。时间久了很容易忘记哪块网卡接的哪个交换机口出故障时抓瞎。我习惯在机柜标签和文档里都记一份。7. 生产环境的扩展思路bond配好只是起点生产环境还要考虑和上层技术的配合。比如bond0上再建VLAN子接口bond0.100对应VLAN 100这样一条聚合链路能承载多个网段。再比如bond0加入网桥给虚拟机用这时候要注意网桥的STP和bond的模式是否冲突。还有一点bond的配置文件在不同发行版之间不通用。CentOS的ifcfg格式搬到Ubuntu的netplan上直接报错。跨平台迁移时要么重写配置要么用配置管理工具比如Ansible做模板化下发把发行版差异抽象掉。我个人的体会是bond这东西配置本身不难难的是把服务器侧、交换机侧、上层应用三者的预期对齐。服务器侧想要冗余交换机侧没配聚合结果就是单点应用侧以为带宽叠加了实际哈希把流量固定到一块卡上。所以每次上bond我都会拉着网络和应用的人一起过一遍拓扑确认每一层的预期一致这比事后排查省太多事。最后分享一个小技巧如果拿不准用哪个模式先用mode 1把冗余做起来业务稳定后再评估要不要升级到mode 4做带宽叠加。冗余是底线带宽是锦上添花顺序别搞反。
