★ FEATURED ARTICLE 按理说把两块网卡绑在一起带宽翻倍链路冗余是件挺简单的事。但我第一次给生产服务器配置 Linux 网卡 bond 模式时就翻过车双千兆 bond 选成了 mode0balance-rr割接后小流量一切正常一到晚高峰业务侧疯狂反馈丢包、卡顿。抓包一看同一个 TCP 连接的数据包被打散到两条物理链路上到对端后乱序、重传把原本好好的链路给“忙”坏了。后来我把 7 种 bond 模式逐一研究并实测了一遍才意识到每个模式背后的约束条件、适用的交换机配置、该配的检测参数都不是默认值能替代的。这篇文章就把 7 种模式的原理、配置、选型逻辑和踩坑经验一次说清楚适合 Linux 运维、网络工程师、虚拟化管理员参考。1. 为什么服务器要把多块网卡“绑”成一张 bond 接口1.1 单块网卡撑不住时通常有两条路服务器缺带宽时最简单的方案是换一块更高速率的网卡千兆不够上万兆单万兆不够上 40G。但更换网卡往往伴随着服务器停机、驱动兼容、预算审批等一堆事情而且一旦网卡坏了整个网络入口就完全断掉。另一个思路是加网卡、不换带宽等级服务器本来就有多个 PCIe 插槽插两块甚至四块网卡的成本比换高速网卡低得多这时就需要一种机制让系统把多块物理网卡当成一块逻辑网卡来用。Linux 内核里的 bonding 模块干的就是这件事它创建出来的虚拟接口叫 bond0通过配置不同的 mode决定数据包在成员网卡之间怎么走。很多人会问我直接给两块网卡配两个 IP不也能同时用吗能同时用但应用层看到的就不是一个统一的网络入口了。比如连接数据库的连接串只能写一个 IP断网卡时不会自动切到另一个 IP再比如路由表里可能同时出现两条默认路由出口行为变得不可控。bond 的核心价值在于向上层提供一个稳定的逻辑接口对外只有一个 IP、一个 MAC 地址物理层怎么切换、怎么负载均衡上层应用完全不用关心。你可以把它理解成一支车队单辆车容量不够就多派几辆车但调度中心必须统一编号、统一指派路线否则货容易送错。bond 就是那个调度中心。1.2 bond 解决的三个核心问题带宽、冗余、负载均衡bond 接口要解决的事情归纳起来是三个带宽叠加、链路冗余、负载均衡。带宽叠加指多条物理链路同时转发让总吞吐超过单块网卡的上限链路冗余指某块网卡或某根网线故障时其余成员网卡自动接管业务不中断负载均衡则是让流量相对均匀地分散到各成员网卡上避免一块网卡被打满、其他网卡闲着。但这里有个非常容易误解的点不是所有模式都能同时做到这三件事。7 种模式的差异本质上是“在什么层面做负载均衡”“是否需要交换机配合”“是否允许短时间内乱序”这几个问题上的取舍。有些模式看起来能叠加带宽但对交换机有硬性要求有些模式只能做冗余带宽完全不加有些模式对某些驱动和虚拟化环境兼容性很差。所以选模式不是拍脑袋挑一个数字而是先想清楚你的业务最缺什么。下面的第 2 节就把 7 种模式逐个拆开讲。2. 7种bond模式的原理、限制和适用场景逐一说透2.0 总览这些模式在“是否依赖交换机”上有根本分歧在讲每个模式之前先放一张总览表方便后面读细节时对照。这张表里最重要的两列是“带宽叠加能力”和“交换机要求”因为绝大多数线上事故都是这两列没对齐导致的。模式内核名称工作方式带宽叠加交换机要求典型场景0balance-rr按包轮询分发可以需配置静态链路聚合特殊高速转发普通 TCP 业务慎用1active-backup主备切换否无高可用冗余最常用2balance-xor按 MAC 哈希分发可以需配置静态链路聚合内网多客户端访问服务器3broadcast所有包从所有网口发否需配置静态链路聚合特殊容错场景很少见4802.3adLACP 动态协商可以需支持 802.3ad/LACP生产环境带宽叠加首选5balance-tlb发送均衡接收由主网卡仅发送方向无出站流量大的备份/上传业务6balance-alb发送接收均衡可以无不想改交换机又要双向增带宽后面每个模式我都会按“工作原理、优点、缺点、适用场景”四条线展开但不会写成一模一样的模板因为有些模式的坑特别值得单独多说几句。2.1 mode0 balance-rr最直观但别急着用balance-rr 是 Round Robin 轮询第一个包走 eth0第二个包走 eth1第三个包再走 eth0以此类推实现最彻底的负载均衡。从理想效果看四块千兆网卡绑成 mode0总带宽看起来是 4Gbps理论转发能力确实可以叠加。但问题也出在“彻底”这两个字上同一个 TCP 连接的数据包会被分散到两条甚至更多物理链路上经过交换机不同的端口后到达对端时延和路径不完全一致接收端看到的报文顺序是乱的。TCP 协议对乱序非常敏感一旦乱序就触发重复确认和重传严重时实际吞吐比单块网卡还差。我在开头说的那次事故就是 mode0 在双千兆下的典型表现小流量时乱序概率低问题不明显晚高峰流量一上来TCP 重传率直接飙到 20%业务卡成狗。此外mode0 还要求交换机把多个端口配置成静态链路聚合比如 Cisco 的 on 模式、华为的手工链路聚合否则交换机上同一 MAC 地址会反复从一个端口漂移到另一个端口二层转发表不断抖动。除非你明确知道自己要的是“逐包负载均衡”并且对乱序不敏感否则普通业务不要选 0。2.2 mode1 active-backup简单可靠的“主备”方案active-backup 是很多人最熟悉的一种 bond同一时刻只有一块网卡在工作其他网卡处于备份状态。一旦 active 网卡的链路断开系统从备份网卡里挑一块接替切换时会把 bond 接口的 MAC 地址切到新网卡上对外 IP 和 MAC 不变。因为同一时间只有一条链路在转发所以不存在乱序也不需要交换机做任何链路聚合配置两个口可以分别接到两台交换机上一旦某台交换机整机故障另一条链路还能继续工作。它的最大缺点是不增加带宽两块千兆绑成 mode1总带宽还是千兆。但这恰恰是它的优点结构简单、行为可预期、故障域最小。很多对带宽要求不高、但对连续性要求极高的场景比如数据库心跳、管理网络、keepalived 节点之间的同步链路选 mode1 比选任何花哨的聚合模式都稳。配置时还可以通过 primary 参数指定主用网卡正常情况下流量固定走 eth0eth0 故障切到 eth1恢复后会自动切回。2.3 mode2 balance-xor静态聚合里的“均衡器”balance-xor 的原理是按哈希值选择出口默认的 xmit_hash_policy 是 layer2也就是拿源 MAC 和目的 MAC 做异或再按低位选择网卡。和 mode0 的逐包轮询不一样mode2 对同一个通信对端来说哈希结果是固定的A 主机到 B 主机的所有流量都会走同一条链路不会乱序。这一点让它比 balance-rr 靠谱得多尤其是在大量客户端访问少数服务器、且流量相对分散的内网环境里它能比较均匀地把不同主机的流量分摊到不同网卡上。但 mode2 有几个前提。一是交换机上要把这些端口配置成静态链路聚合不然二层 MAC 表会抖动二是哈希算法的均匀程度依赖流量模型如果全网只有一台客户端在猛灌流量那所有数据都哈希到同一块网卡其他网卡闲着。另一个坑是默认 layer2 哈希只认 MAC如果所有流量经过三层路由后源 MAC 都是网关的 MAC那么到不同目标 IP 的流量可能还是被分到同一条链路。遇到这种情况可以把 xmit_hash_policy 改成 layer23 或 layer34让 IP 甚至端口参与哈希但交换机侧的负载均衡 Hash 也要对应调整。2.4 mode3 broadcast特殊场景才考虑的广播模式broadcast 模式的机制非常“暴力”每个报文从所有成员网卡各发一份接收端会收到重复帧代价是带宽完全不可能叠加链路容量直接打对折甚至更低但换来的是极高的容错性只要还有一块网卡活着报文就还能发出去因为每块网卡都发送了完整副本。这种模式需要交换机把多个端口配置成静态聚合否则重复帧和同一 MAC 从多口出现的现象会让二层网络很难受。生产环境里 mode3 极少见我见过它出现在一些对丢包零容忍、对带宽不敏感的特殊系统里比如某些定制化组播、金融行情分发、工业控制协议。这个模式下应用层必须能处理重复数据或者干脆就是无状态广播协议。对绝大多数 Linux 服务器来说如果既想要冗余又不想付带宽代价mode1 是更好的选择如果既要冗余又要带宽mode4 是更好的选择。mode3 更像是一种“执着于不丢包”的偏门方案不建议常规业务使用。2.5 mode4 802.3ad业界标准的 LACP 动态聚合mode4 是 802.3ad 标准动态链路聚合也就是 LACP。它和 mode0、mode2 最大的区别在于聚合关系不是“本地说了算”而是通过 LACPDU 协议报文和对端交换机协商出来的。两端模式匹配、速率双工一致、成员口都在同一个 Eth-Trunk 或 PortChannel 里链路才会被选中成为 active任何一端配置不匹配聚合都不会成立。这种协商机制避免了很多“配了 bond 但交换机不知道”的问题是生产环境里做带宽叠加最推荐的方式。bond 的 802.3ad 模式底下还可以调整负载均衡哈希策略常见三种layer2、layer23、layer34。默认是 layer2只看 MAC如果你的网络是三层环境或者希望不同端口/不同会话能分散到不同物理链路建议改成 layer23 或 layer34。需要特别提醒虽然 mode4 能叠加带宽但这里叠加的是“多连接并发带宽”。单个 TCP 连接由于哈希固定只会走其中一条成员链路所以拿 iperf3 单线程测速是跑不满聚合带宽的必须用多并发流来测。这一点很多第一次配 bond 的人都会误会。2.6 mode5 balance-tlb发送均衡接收还是单点balance-tlb 是自适应发送负载均衡TTLB 会自动根据每块成员网卡的实时负载情况把发送流量分摊到不同的物理网卡上但接收方向仍然由当前 active 网卡单独承担。换句话说出站带宽可以叠加入站带宽不能叠加。这个模式最大的好处是交换机不需要任何链路聚合配置只要把两块网卡接到同一个二层广播域里就行对现有网络改造成本几乎为零。它适合什么场景出站流量明显大于入站的业务。比如服务器往备份存储推数据、往对象存储上传日志、数据库向从库同步 binlog、视频推流等。这类流量方向单一出站是瓶颈入站反而没多少mode5 能用很轻的成本把出站带宽翻倍。要留意的是因为发送流量会从不同物理网卡出来交换机会看到同一个 MAC 地址出现在多个端口上有些交换机默认开启端口安全或 MAC 防漂移策略会把这类报文直接丢弃所以接 mode5 前要先在交换机侧确认没有这类限制。2.7 mode6 balance-alb不需要交换机支持的“双向均衡”balance-alb 可以理解为 balance-tlb 的增强版发送方向依然做自适应负载均衡接收方向额外通过 ARP 协商实现负载均衡。它会让 bond 在回应不同 ARP 请求时交替使用不同成员网卡的 MAC 地址作为源 MAC这样一来对端主机的 ARP 缓存里同一个 IP 可能在不同时间对应不同的 MAC流量就会被分散到多块物理网卡上。发送和接收两条方向都能叠加带宽而且不需要交换机配置任何链路聚合协议。听起来是不是很完美但代价是复杂度和兼容性问题。它要求网卡驱动必须支持动态修改 MAC 地址还要能发出 RARP 通告绝大多数物理网卡没问题但部分虚拟化环境、半虚拟化网卡、SR-IOV VF 可能不支持或行为异常。另外ARP 表中的 MAC 频繁变化对某些安全设备和防火墙来说可能触发告警如果网络里有 ARP 检测策略需要提前放行。如果不想改交换机又必须双向增带宽mode6 是可以尝试的方案但在上线前一定要做兼容性测试和长时间稳定性压测不要直接上生产。3. 不同发行版下的bond配置实战从加载模块到开机自启3.1 加载 bonding 模块先搞清楚内核参数配置 bond 的第一步是确保内核加载了 bonding 模块。大多数 Linux 发行版都自带这个模块但参数需要在模块加载时指定。最简单的动态加载方式是这样# 查看模块是否已加载 lsmod | grep bonding # 动态加载 bonding 模块指定 mode1 miimon100 modprobe bonding mode1 miimon100 # 如果模块已加载可以动态创建一个 bond 接口 echo bond0 /sys/class/net/bonding_masters # 查看当前 bond 接口信息 cat /proc/net/bonding/bond0生产环境不能只靠命令因为重启后就没了。通常的做法是写进/etc/modprobe.d/bonding.confalias bond0 bonding options bonding mode1 miimon100这里的miimon100表示每 100 毫秒检测一次链路状态是链路检测的关键参数。如果网卡不支持 MII 链路检测或者需要检测三层可达性可以改用arp_interval100 arp_ip_target192.168.1.1但 arp_ip_target 最多只能配 16 个 IP。要注意如果用options bonding mode...写在 modprobe 配置里它会对所有 bond 接口生效。如果你在同一台机器上有两个 bond 且模式不同就别在 modprobe 里写死 mode等 bond 接口创建后再通过/sys/class/net/bondX/bonding/mode动态设置或者直接在网络服务的配置里指定。3.2 CentOS/RHEL 用 ifcfg 绑定的完整示例含 NetworkManager 避坑CentOS 7/8 是 bond 配置最常见的环境。虽然现在都在推 NetworkManager但传统 ifcfg 方式在运维脚本里仍然大量存在而且能用network.service管理。以两块网卡 eth0、eth1 绑成 mode1bond0 配置 192.168.1.10/24 为例/etc/sysconfig/network-scripts/ifcfg-bond0DEVICEbond0 TYPEBond BONDING_MASTERyes NAMEbond0 BOOTPROTOnone ONBOOTyes IPADDR192.168.1.10 PREFIX24 BONDING_OPTSmodeactive-backup miimon100 primaryeth0/etc/sysconfig/network-scripts/ifcfg-eth0DEVICEeth0 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyes/etc/sysconfig/network-scripts/ifcfg-eth1DEVICEeth1 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyes然后执行systemctl restart network注意几个容易翻车的地方。第一个是 slave 网卡上千万不要配 IP也不要把NM_CONTROLLEDyes否则 NetworkManager 会把这些网卡当成普通有线连接接管掉重启后 bond 的成员关系可能丢失。第二个是如果服务器原本由 NetworkManager 管理建议要么直接用nmcli的 bond 命令配置要么在 slave 配置里明确写NM_CONTROLLEDno避免两套网络服务抢网卡。第三个是BONDING_OPTS里的 mode 参数既可以用数字1也可以用内核名称active-backup两种写法都行但要注意 802.3ad 模式对应写802.3ad而不是数字 4 时不同发行版的解析能力略有差异写成内核名称更保险。如果你更习惯用 NetworkManager也可以直接用一组命令完成nmcli con add type bond ifname bond0 mode active-backup miimon 100 primary eth0 nmcli con add type ethernet ifname eth0 master bond0 nmcli con add type ethernet ifname eth1 master bond0 nmcli con mod bond-bond0 ipv4.addresses 192.168.1.10/24 ipv4.method manual nmcli con up bond-bond0这种方式在 RHEL/CentOS 8 以上更推荐因为配置会自动纳入 NetworkManager 统一管理开机能自启。3.3 Ubuntu 用 netplan 配置 bond顺便把开机自启一起解决Ubuntu Server 18.04 以上默认用 netplan 管理网络。netplan 可以把 bond 配置得很干净而且直接生成 systemd-networkd 的配置天然解决开机自启问题。以两块网卡 enp1s0、enp2s0 绑成 mode4 为例配置写在/etc/netplan/01-netcfg.yamlnetwork: version: 2 renderer: networkd ethernets: enp1s0: dhcp4: no enp2s0: dhcp4: no bonds: bond0: interfaces: [enp1s0, enp2s0] addresses: - 192.168.1.10/24 routes: - to: default via: 192.168.1.1 parameters: mode: 802.3ad mii-monitor-interval: 100 lacp-rate: fast transmit-hash-policy: layer34写完执行netplan apply然后用ip link show bond0和cat /proc/net/bonding/bond0验证。netplan 里mode: 802.3ad对应内核的 mode4如果想用 mode1就写mode: active-backup。lacp-rate: fast表示 LACP 报文每秒发一次故障收敛更快默认是 slow30 秒生产环境建议显式设成 fast。如果你是老一点、还在用/etc/network/interfaces的 Ubuntu 或 Debian也可以写auto bond0 iface bond0 inet static address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 bond-slaves enp1s0 enp2s0 bond-mode 802.3ad bond-miimon 100 bond-lacp-rate 1bond-lacp-rate 1同样表示 fast 模式。这个写法在 systemd-networkd 环境里也能被兼容但 netplan 毕竟是现在 Ubuntu 的默认方案能用新不用旧。4. 模式选型带宽、冗余和交换机能力怎么平衡4.1 按业务场景选型虚拟化、数据库、Web、存储先给一个最容易上手的原则拿不准就选 mode1或者选 mode4。这两个模式是生产环境里最成熟、踩坑资料最多的选择。但如果你遇到的场景比较具体可以这样分虚拟化宿主机上跑 KVM/VMware 虚拟机时流量模型通常是“多虚拟机并发”出站和入站都有压力且宿主机一般接在支持 LACP 的接入交换机上优先用 mode4并把 xmit_hash_policy 调成 layer34让不同虚拟机之间的连接哈希到不同物理链路上。数据库双机、keepalived 这类场景带宽需求不是第一位的稳定性和故障切换的确定性才是所以 mode1 更合适还可以配 primary 让主备角色清晰。Web 前端/负载均衡服务器则是典型的双向流量均衡需求有 LACP 就上 mode4没有的话可以评估 mode6。存储和备份服务器多为出站流量大、入站回包小尤其像 NFS 大量并发连接时mode4 能发挥惰性如果是单任务大文件备份、且无法支持多线程那任何 bond 都不会让单流超过单网卡带宽。4.2 最容易被忽略的交换机侧配置很多人配 bond 只在服务器上折腾忘了交换机也是聚合的一半。mode0、2、3 都需要交换机把对应端口配成静态链路聚合mode4 需要交换机启用 LACPCisco 上是 channel-protocol lacp华为/H3C 上是链路聚合模式为 lacpmode1、5、6 虽然不需要聚合但要保证所有 slave 网卡接到同一个二层广播域里也就是同一台交换机或同一个堆叠系统。别把一块网卡接到交换机 A、另一块接到没堆叠的交换机 B否则 mode6 的 ARP 负载均衡会让两台交换机都学到同一个 IP 对应不同的 MAC流量会变得很诡异。交换机上还要留意端口安全和 MAC 漂移策略。很多接入交换机默认会限制一个端口下 MAC 地址数量或者检测到同一 MAC 从多个端口出现时直接丢弃。mode5、mode6 特别容易触发这种保护机制上线前最好先把成员端口的安全策略关掉或者将 bond 的 MAC 加入白名单。另外如果交换机是堆叠环境聚合成员口应该尽量分布在不同的堆叠成员交换机上这样即使某一台设备出问题聚合链路还能继续工作。4.3 快速决策逻辑把需求翻译成模式如果你不想背每种模式的细节可以按下面的问题做排除法。第一问只做冗余带宽够不够够就用 mode1。第二问需要增加带宽交换机能不能支持 LACP能就用 mode4。第三问交换机不支持 LACP但能做静态链路聚合用 mode2别用 mode0 和 mode3因为前者乱序严重后者浪费带宽。第四问交换机什么聚合都不想做但还需要带宽叠加出站为主用 mode5双向都要用 mode6但上线前必须验证网卡驱动和上层防火墙对 ARP 变化的容忍度。这个逻辑比死记表格要实用得多我在评审 bond 方案时基本按这套顺序问自己。5. 踩坑实录配置bond后最容易翻车的四个问题5.1 mode4 链路明明起来了业务却频繁丢包有次给一组 KVM 宿主机配 mode4配完之后cat /proc/net/bonding/bond0显示 MII Status 全是 upbond0 也能 ping 通。但跑业务时总有人反映访问偶发变慢登录机器用 iperf3 多线程测速发现带宽比单块网卡还差而且观察成员网卡统计只有其中一块在持续转发另一块几乎没流量。排查链路是这么走的先用ip -d link show bond0确认 mode 确实是 802.3ad再用ethtool enp2s0 | grep Speed确认两端速率都是千兆且双工一致最后登上交换机看 LACP 协商状态发现交换机上这几个端口根本没被加进同一个 Eth-TrunkLACP 协商当然不成功。因为 802.3ad 模式下如果协商失败bond 会退化成类似主备方式只保留一块成员口转发。所以后面的验收流程里我每次都会加一步看交换机侧成员口是否都处于 Selected 状态不要只看服务器端“看起来 up”。如果你用的是 Cisco命令是show etherchannel summary华为/H3C 是display eth-trunk verbose。5.2 miimon 检测不到链路故障拔线后切换花了 30 秒另一个非常典型的坑是 miimon 检测到了 false positive。某台数据库服务器做了 mode1 冗余有一次计划内切换拔掉 active 网卡的网线后业务中断了整整 30 秒才恢复。按理说miimon100应该 1 秒内完成切换为什么这么慢查下来发现服务器网卡到接入交换机之间还隔着一台光纤收发器。拔掉的是光纤收发器到交换机那侧的线服务器网卡到光纤收发器之间其实是电气链路正常的所以网卡的 MII 状态一直显示 upbond 根本不知道远端已经断了。直到交换机侧的链路超时机制触发才通过其他机制感知到故障。这个案例说明链路检测层级的选取非常重要。如果接入链路中间有光电转换器、汇聚交换机等设备纯 MII 检测是不够的需要在 bond 里增加arp_interval和arp_ip_target用三层可达性兜底。当然增加 ARP 检测也要小心目标 IP 要选真正稳定的网关或对端地址否则误判反而更频繁。5.3 重启后 bond 丢失被 NetworkManager“抢走”的从设备还有一个出现频率极高的重启故障服务器配置好 bond 后一切正常但只要一重启ip addr看不到 bond0或者 bond0 在但从设备没有加入。日志里能看到 NetworkManager 把 eth0、eth1 识别成了普通有线连接并且自己生成了独立连接配置这和传统 network.service 管理的 bond 产生了冲突。解决这个问题有两种思路。如果你打算继续用传统 network.service就在 slave 网卡的 ifcfg 文件里明确写NM_CONTROLLEDno同时确认 systemd 中NetworkManager.service和network.service的启用关系。如果你想用 NetworkManager 管理那就别混着写 ifcfg直接像第 3.2 节那样用nmcli con add type bond和nmcli con add type ethernet master bond0建配置让 NM 自己维护 slave 和 bond 的关系。最怕的就是两套配置都写一半重启后互相打架。5.4 balance-rr 单 TCP 流速度上不去还疯狂重传开头说的 mode0 翻车案例在这里补一下现场数据双千兆 bond用 iperf3 单线程打流理论上应该接近 2Gbps实际只有三四百兆而且 TCP 重传率非常高。抓包后看到同一 seq 的包从 eth0、eth1 先后到达对端不断回 DUP ACK发送端触发快速重传窗口一直缩吞吐自然崩了。这不是 bug是 balance-rr 的固有特性。逐包轮询会把单个 TCP 流的报文分配到多条链路上而多条链路的物理路径延迟不一致就会乱序。TCP 协议为了确保数据顺序会牺牲吞吐来等待重排。后来的处理方式是把业务切到 mode4并把 hash policy 改成 layer34让不同 TCP 连接被分散到不同物理链路同一连接始终走同一条链路重传率立刻降下来了。这个案例给我的教训是选 bond 模式前一定要问业务一句“你的流量是多连接还是单连接”。单连接大流场景任何基于连接的负载均衡都不能叠加带宽只能靠换更大带宽的网卡或者应用层拆流。6. 验证验收如何确认 bond 真的在干活而不是“假聚合”6.1 用 /proc/net/bonding 和 ethtool 确认状态配置完 bond 之后第一件事不是急着跑业务而是确认状态。打开/proc/net/bonding/bond0重点看这几个关键字段Bonding Mode显示的是不是预期模式MII Status是否全部为 upActive Slave是不是预期的 active 网卡Slave Interface列表里成员网卡是否都在。如果是 mode4还要看LACP rate是否为 fastTransmit Hash Policy是否符合你的预期。ip -d link show bond0也能看到 bond 的模式和成员关系配合ethtool eth0检查每块物理网卡的速率、双工、link detected 是否正常。这里有个很容易误判的点在 bond 接口上执行ethtool bond0看到的 Speed 不一定是所有成员网卡的聚合值它经常只反映某一块 active 网卡或第一个 slave 的速率不能作为聚合成功的依据。真正需要确认的是每个 slave 网卡的状态以及交换机侧聚合组是否完整。6.2 拔线测试与带宽实测iperf3 的正确用法bond 验收的核心是“破坏性测试”和“压测”。拔线测试要分两种情况看如果是 mode1/5/6拔掉 active 网卡的线bond 应该自动切换ping 业务 IP 的丢包数越少越好切换时间通常在秒以内如果是 mode4拔掉一根成员口的线聚合组里其他成员口会继续转发业务基本无感。拔线前建议开一个持续 ping让人在旁边盯输出同时用watch -n 1 cat /proc/net/bonding/bond0观察切换过程。带宽实测别只会跑iperf3 -c server -t 30这条命令默认单线程在 mode2/4 下很难压出聚合带宽。正确做法是用-P参数开多并发流例如# 服务端 iperf3 -s # 客户端开 8 个并发流测 30 秒 iperf3 -c 192.168.1.10 -P 8 -t 30 -i 2想要更贴近真实业务可以用-R测反向或者用--bidir同时测双向。观察每块物理网卡的实时流量可以用sar -n DEV 1或ifstat如果多块 slave 网卡的流量都明显上涨说明负载均衡在生效如果只有一块在涨要么哈希策略没选对要么交换机聚合没配好。6.3 我的最后一条建议管好 bond本质上是一道“模式 链路检测 交换机聚合 哈希策略”的联合工程题任何一个环节没对齐线上就会以各种奇怪的方式表现出来。我现在的习惯是每次配置完 bond都会做一次完整的拔线演练和多线程压测并把结果记录到主机信息表里注明模式、miimon、哈希策略、交换机型号和聚合状态。凡涉及 bond 变更一定先备份 ifcfg 和 modprobe 配置再在测试机里把相同模式跑一遍。虚拟机和物理机上的 bond 行为差异很大尤其是半虚拟化网卡和虚拟交换机对 mode6 的支持并不总是可靠真正的生产验收还是要以物理机实测为准。这套流程走完bond 才会真正成为你能放心依赖的底层能力。
阅读完成 · 觉得有帮助？
