ARM架构CentOS 7.6网口bond配置实战与优化指南

1. 项目背景与需求拆解1.1 为什么要在ARM架构的CentOS 7.6上做网口bond在ARM服务器上跑CentOS 7.6这个组合本身就有点意思。ARM架构的服务器这几年在数据中心里越来越常见尤其是那些对功耗敏感、需要高密度部署的场景。但ARM平台跟传统的x86平台在硬件层面有不少差异网卡驱动、中断处理、PCIe拓扑这些都可能不一样所以很多在x86上跑得好好的网络配置方案搬到ARM上就得重新验证一遍。网口bond链路聚合这个需求说白了就是把多块物理网卡绑成一块逻辑网卡来用。为什么要这么做两个核心原因带宽叠加和链路冗余。带宽叠加很好理解比如你有两块千兆网卡绑在一起理论上能跑到两千兆当然实际能不能跑到要看交换机的配置和流量特征。链路冗余更关键生产环境里一块网卡挂了或者网线松了如果没做bond业务直接就断了做了bond之后流量自动切到另一块网卡上业务基本无感知。在ARM服务器上做bond还有一个比较特殊的场景有些ARM服务器板载的网口数量有限或者板载网口的控制器型号比较特殊需要额外插PCIe网卡来扩展网络接口。这时候把板载网口和扩展网口做bond既能提升带宽又能保证冗余是个很实用的方案。1.2 适用人群与前置知识这篇内容主要面向几类人一是在ARM服务器上做系统运维的工程师二是需要给ARM平台做网络高可用方案的架构师三是正在从x86往ARM迁移、需要重新验证网络配置的技术人员。如果你之前只在x86上做过bond配置那ARM平台上的一些细节差异值得你花时间看看。前置知识方面你需要对Linux网络基础有一定了解知道什么是网卡、IP地址、子网掩码、网关这些基本概念。另外对CentOS 7的网络管理方式要熟悉知道NetworkManager和network这两种服务的关系。如果你用过nmcli或者手动编辑过ifcfg-*文件那看这篇内容会很顺畅。如果这些都不太熟也没关系我会把每一步都拆开讲清楚。1.3 环境说明与前置检查在开始配置之前有几项环境信息需要先确认清楚。这些信息直接决定了后面bond配置能不能成功所以千万别跳过。首先确认系统版本和内核版本cat /etc/centos-release uname -rCentOS 7.6的内核版本一般是3.10.0-957系列ARM架构的话通常是aarch64。确认一下你的系统是不是这个版本因为不同小版本的内核在网卡驱动上可能有差异。然后确认网卡硬件情况lspci | grep -i ethernet ip link showlspci能看到PCIe网卡的型号ip link show能看到当前系统识别到的所有网络接口。ARM服务器上常见的网卡有板载的千兆网口也有通过PCIe插槽扩展的万兆网卡。你需要确认至少有两块可用的物理网卡而且它们的状态是UP的。还有一个很重要的检查项确认网卡驱动是否正常加载。有些ARM服务器上的网卡驱动需要额外安装或者内核自带的驱动版本比较老功能受限。可以用ethtool来查看网卡的基本信息ethtool eth0 ethtool eth1如果ethtool显示的信息不完整或者提示不支持某些功能那可能需要更新驱动。不过对于bond配置来说只要网卡能正常收发数据驱动基本就没问题。注意在ARM平台上有些网卡的命名规则跟x86不太一样。x86上常见的ens33、enp3s0这种命名方式在ARM上可能变成eth0、eth1这种传统命名。所以看到eth0不要觉得奇怪这是正常的。2. Bond模式选型与核心原理2.1 七种bond模式的区别与适用场景Linux的bonding驱动支持多种工作模式每种模式的行为和适用场景都不一样。选错模式可能会导致网络性能下降甚至出现网络不通的情况。下面这张表把常见的几种模式对比一下模式编号模式名称工作原理是否需要交换机配合适用场景mode0balance-rr轮询方式发送数据包需要静态聚合对带宽要求高、能接受乱序mode1active-backup主备模式只有一块网卡工作不需要高可用优先、带宽要求不高mode2balance-xor根据哈希算法选择网卡需要静态聚合需要负载均衡且流量特征固定mode3broadcast所有网卡发送相同数据需要静态聚合特殊容错场景mode4802.3ad动态链路聚合需要LACP标准方案、交换机支持LACPmode5balance-tlb发送负载均衡不需要下载带宽要求高mode6balance-alb收发都负载均衡不需要通用场景、无需交换机配置在ARM服务器上我一般推荐用mode4802.3ad或者mode1active-backup。mode4是标准方案需要交换机支持LACP协议配置好之后带宽叠加和冗余都能实现。mode1配置最简单不需要交换机做任何额外配置但只有一块网卡在工作带宽没有叠加。如果你的交换机支持LACP而且你对带宽有要求那就选mode4。如果交换机不方便改配置或者你只是想做个冗余那就选mode1。mode6看起来很美不需要交换机配合就能实现负载均衡但在某些ARM网卡上兼容性不太好可能会出现流量分配不均的问题所以我不太推荐在生产环境用。2.2 为什么ARM平台上要特别注意bond配置ARM平台跟x86平台在bond配置上的差异主要来自几个方面。首先是网卡驱动的实现不同有些ARM服务器用的网卡控制器是集成在SoC里的驱动可能没有x86上那些独立网卡那么成熟。其次是中断处理机制不同ARM用的是GIC通用中断控制器跟x86的APIC不一样这会影响多队列网卡的中断分发进而影响bond的负载均衡效果。还有一个容易被忽略的点ARM服务器的PCIe拓扑可能跟x86不一样。x86服务器上CPU和PCIe插槽之间的拓扑比较规整网卡到CPU的路径比较短。ARM服务器上有些PCIe控制器是挂在NUMA节点上的如果两块做bond的网卡挂在不同的NUMA节点上跨节点通信的延迟会增加bond的性能可能会受影响。所以在ARM上做bond我建议尽量选同一型号、同一批次的网卡最好插在同一个PCIe控制器下的插槽上。如果做不到那至少在配置完之后要做个简单的性能测试确认bond的实际吞吐量符合预期。2.3 配置前的信息收集清单动手之前先把这些信息收集齐后面配置的时候会用到两块物理网卡的名称比如eth0、eth1网卡的MAC地址后面配置bond的时候可能需要指定交换机的型号和支持的聚合协议LACP还是静态聚合业务需要的IP地址、子网掩码、网关是否需要配置VLAN如果交换机端口配了VLANbond口也要对应配置当前网络是否在运行中如果是生产环境配置bond可能会导致短暂断网提示如果是远程配置生产服务器的bond一定要先确认有带外管理比如IPMI或串口可用否则配置过程中网络断了就彻底失联了。这个坑我踩过当时只能让机房的人帮忙重启。3. 实操过程与核心环节实现3.1 加载bonding内核模块CentOS 7.6默认应该已经加载了bonding模块但为了保险起见先确认一下lsmod | grep bonding如果没有输出说明模块没加载手动加载一下modprobe bonding为了让模块在重启后自动加载需要创建一个配置文件echo bonding /etc/modules-load.d/bonding.conf如果你需要指定bonding模块的参数比如max_bonds最大bond数量或者mode默认模式可以创建/etc/modprobe.d/bonding.confoptions bonding max_bonds2 mode4 miimon100这里解释一下几个参数max_bonds2表示最多创建2个bond接口mode4表示默认使用802.3ad模式miimon100表示每100毫秒检测一次链路状态。miimon这个参数很关键它决定了链路故障检测的灵敏度。设得太小会增加系统开销设得太大故障切换会变慢。100毫秒是个比较平衡的值生产环境常用。3.2 创建bond配置文件CentOS 7有两种网络管理方式NetworkManager和传统的network服务。在服务器上我一般推荐用传统的network服务配置更直观出问题也好排查。先确认一下当前用的是哪个systemctl status NetworkManager systemctl status network如果NetworkManager是active的可以把它停掉改用network服务systemctl stop NetworkManager systemctl disable NetworkManager systemctl enable network systemctl start network然后创建bond接口的配置文件/etc/sysconfig/network-scripts/ifcfg-bond0DEVICEbond0 NAMEbond0 TYPEBond BONDING_MASTERyes BOOTPROTOnone ONBOOTyes IPADDR192.168.1.100 PREFIX24 GATEWAY192.168.1.1 DNS18.8.8.8 BONDING_OPTSmode4 miimon100 lacp_rate1这里BONDING_OPTS里的参数需要根据你选的模式来调整。如果是mode4建议加上lacp_rate1表示每秒发送一次LACPDU报文加快链路聚合的协商速度。如果是mode1那BONDING_OPTS只需要mode1 miimon100就够了。3.3 配置物理网卡从接口接下来配置两块物理网卡的配置文件。假设是eth0和eth1分别编辑/etc/sysconfig/network-scripts/ifcfg-eth0和ifcfg-eth1DEVICEeth0 NAMEeth0 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyeseth1的配置类似把DEVICE和NAME改成eth1就行。这里的关键是MASTERbond0和SLAVEyes这两个参数告诉系统这块网卡是bond0的从接口。注意物理网卡的配置文件里不要配IP地址IP要配在bond0上。如果之前eth0上配了IP记得删掉否则会出现IP冲突。3.4 重启网络服务并验证配置完成后重启网络服务systemctl restart network然后检查bond状态cat /proc/net/bonding/bond0这个文件会显示bond的详细信息包括当前模式、链路状态、从接口列表等。重点看几个地方Bonding Mode是不是你设置的模式Currently Active Slave显示当前活跃的网卡MII Status应该是up。再用ip addr show bond0确认IP地址配置正确用ping测试网络连通性ping -c 4 192.168.1.1 ping -c 4 8.8.8.8如果ping不通先检查交换机配置。mode4需要交换机端口配置LACP如果交换机没配bond起不来。mode1不需要交换机配置但如果两块网卡都插在同一个交换机上而交换机没做任何配置那应该能正常工作。3.5 故障切换测试配置完成后一定要做故障切换测试。这个测试的目的是验证当一块网卡故障时流量能不能自动切到另一块网卡上。测试方法很简单在持续ping的过程中拔掉一块网卡的网线观察ping有没有中断。ping -c 100 192.168.1.1然后在另一个终端里把eth0的网卡down掉ip link set eth0 down观察ping的输出如果只丢了1-2个包就恢复了说明故障切换正常工作。如果ping直接断了那说明配置有问题需要检查miimon参数和交换机配置。测试完之后把网卡重新up起来ip link set eth0 up然后再看/proc/net/bonding/bond0确认eth0重新加入了bond。4. 常见问题与排查技巧实录4.1 bond接口起不来怎么办这是最常见的问题。bond0接口起不来通常有几个原因。先看systemctl status network的输出有没有报错信息。然后检查/var/log/messages看看有没有bonding相关的错误日志。一个很典型的原因是配置文件语法错误。比如BONDING_OPTS里的参数拼错了或者MASTERbond0写成了MASTERbond1。这种问题看日志就能发现。另一个原因是网卡被NetworkManager接管了。如果NetworkManager还在运行它可能会跟network服务冲突导致bond配置不生效。确认一下NetworkManager是不是已经停掉了。还有一种情况是网卡驱动不支持bonding。虽然大部分网卡都支持但有些特殊的ARM网卡可能不支持。可以用ethtool -k eth0看看网卡支持的功能如果tx-checksumming这些基本功能都不支持那bonding可能也用不了。4.2 bond起来了但网络不通bond接口能起来/proc/net/bonding/bond0也显示正常但就是ping不通网关。这个问题一般出在交换机侧。如果是mode4交换机端口必须配置LACP。如果交换机没配或者配的是静态聚合那bond虽然能起来但流量发不出去。这时候需要登录交换机检查配置。如果是mode1交换机不需要特殊配置但要注意两块网卡不能插在同一个交换机端口上那是不可能的也不能插在做了端口隔离的交换机上。有些交换机默认开启端口隔离同一个VLAN下的端口不能互相通信这会影响bond的故障切换。还有一个可能的原因是ARP缓存问题。bond切换网卡后MAC地址可能会变取决于fail_over_mac参数交换机那边的ARP表没更新导致流量发不回来。可以尝试在交换机上清除ARP缓存或者在bond配置里加上fail_over_mac1让bond始终使用当前活跃网卡的MAC地址。4.3 性能不达预期怎么排查bond配好了网络也通了但测速发现带宽没有叠加还是单块网卡的速率。这个问题在ARM平台上比较常见排查思路如下。首先确认交换机的聚合配置是否正确。mode4需要交换机配置LACP而且交换机的哈希算法要跟服务器端的哈希算法匹配。服务器端可以用xmit_hash_policy参数来调整哈希策略BONDING_OPTSmode4 miimon100 lacp_rate1 xmit_hash_policylayer34layer34表示根据IP地址和端口号做哈希这样不同的连接会分配到不同的网卡上。默认的layer2只根据MAC地址做哈希如果所有流量都来自同一个源MAC那就会全部走同一块网卡带宽自然叠加不起来。然后检查网卡的中断分布。ARM平台上多队列网卡的中断可能都集中在同一个CPU上导致单个CPU成为瓶颈。可以用mpstat -P ALL 1看看各个CPU的利用率如果某个CPU的%soft很高那可能就是中断集中了。这时候需要调整中断亲和性把不同队列的中断分配到不同的CPU上。最后检查NUMA拓扑。如果两块网卡挂在不同的NUMA节点上跨节点通信会增加延迟。可以用lscpu和lspci -vv查看网卡挂载的NUMA节点尽量让bond的流量在同一个NUMA节点内处理。4.4 常见问题速查表问题现象可能原因排查方法解决方案bond0接口不存在配置文件错误或模块未加载lsmod | grep bonding加载模块检查ifcfg-bond0bond0起不来NetworkManager冲突systemctl status NetworkManager停用NetworkManager网络不通交换机未配LACP登录交换机检查配置LACP或改用mode1故障切换不生效miimon参数过大cat /proc/net/bonding/bond0减小miimon值带宽不叠加哈希策略不当ethtool -S bond0调整xmit_hash_policy性能差中断集中或NUMA跨节点mpstat -P ALL 1调整中断亲和性提示在ARM平台上如果遇到bond相关的问题先确认内核版本和网卡驱动版本。有些问题在新版内核里已经修复了升级内核可能比折腾配置更省事。5. 生产环境中的经验与优化建议5.1 配置备份与回滚方案在生产环境做bond配置一定要先备份原有的网络配置文件。我一般会把/etc/sysconfig/network-scripts/整个目录打包备份tar czf /root/network-backup-$(date %Y%m%d).tar.gz /etc/sysconfig/network-scripts/如果配置过程中出了问题网络断了可以通过带外管理或者本地终端恢复备份tar xzf /root/network-backup-20240101.tar.gz -C / systemctl restart network另外建议在配置bond之前先在一个非生产环境或者虚拟机上验证一遍。ARM平台的虚拟化环境比如KVM on ARM也可以用来做初步验证虽然虚拟网卡跟物理网卡有差异但至少能验证配置文件语法和基本流程。5.2 监控bond状态的关键指标bond配好之后日常运维需要关注几个关键指标。首先是链路状态/proc/net/bonding/bond0里的MII Status和Link Failure Count能反映链路是否正常。如果Link Failure Count持续增长说明网卡或者网线有问题需要及时处理。其次是流量分布。如果bond的流量严重不均一块网卡跑满另一块几乎空闲那说明哈希策略需要调整。可以用cat /proc/net/bonding/bond0里的Slave Interface部分查看每块网卡的收发统计。还有一个指标是bond的切换次数。如果Active Slave频繁切换说明链路不稳定可能是网线接触不良或者交换机端口有问题。这种情况需要排查物理层而不是调整bond配置。5.3 ARM平台特有的优化技巧在ARM服务器上跑bond有几个优化技巧值得一试。首先是调整网卡的中断合并参数。ARM CPU的核心数通常比x86少中断处理的开销相对更大。可以用ethtool -C eth0 rx-usecs 100来增加中断合并的延迟减少中断次数降低CPU开销。其次是调整TCP参数。ARM平台的内存带宽和缓存结构跟x86不同默认的TCP缓冲区大小可能不是最优的。可以在/etc/sysctl.conf里调整net.core.rmem_max 16777216 net.core.wmem_max 16777216 net.ipv4.tcp_rmem 4096 87380 16777216 net.ipv4.tcp_wmem 4096 65536 16777216这些参数增加了TCP读写缓冲区的最大值对于高带宽的bond链路来说能减少丢包和重传。最后是考虑使用多队列网卡。如果ARM服务器上的网卡支持多队列大部分万兆网卡都支持可以开启多队列让每个CPU核心处理一个队列的中断提升并行处理能力。可以用ethtool -L eth0 combined 8来设置队列数具体数值根据CPU核心数来定。5.4 从bond到team的演进思考CentOS 7.6里除了bonding还有team驱动。team是Red Hat推的新一代链路聚合方案功能更灵活支持更多模式。但在ARM平台上team的兼容性还不如bonding成熟而且team的配置方式跟bonding完全不同学习成本更高。我个人的建议是如果bonding能满足需求就继续用bonding。bonding在ARM平台上的验证更充分社区支持也更好。如果将来有更复杂的需求比如需要动态调整聚合策略再考虑迁移到team。不过迁移之前一定要做充分的测试因为team和bonding在故障切换行为上有差异可能会影响业务的连续性。在实际运维中我还遇到过一种情况有些ARM服务器的固件或者BIOS里有个选项可以设置网卡的聚合模式。如果固件层面已经做了聚合操作系统层面再做bond就会冲突。所以配置bond之前最好先确认一下固件层面的网络配置避免重复配置导致网络异常。