1. 为什么在ARM架构的CentOS 7.6上做网口bond值得单独拿出来讲在x86服务器上配bond很多人闭着眼睛都能敲完nmcli那几行命令。但一旦把同样的操作搬到ARM架构的CentOS 7.6上事情就没那么顺了。我前后在几台ARM服务器上折腾过网口绑定踩过的坑包括网卡命名规则跟x86不一样、ethtool对某些ARM板载网卡支持不完整、NetworkManager和network-scripts两套体系互相打架、bond模式选错导致交换机侧聚合失败等等。这些问题在x86上要么不会出现要么表现完全不同。这篇文章面向的是手里有ARM服务器、跑着CentOS 7.6、需要做网口bond的运维人员或系统工程师。不管你是刚接触bond的新手还是从x86转过来踩坑的老手我都会把整个流程拆开讲清楚从bond模式怎么选、ARM平台上的特殊注意事项、到两种配置方式nmcli和配置文件的完整操作、再到实际排查问题的思路。内容基于我在实际环境中的操作记录整理命令和参数都可以直接参考复现。先说清楚一个前提CentOS 7.6在ARM上的发行版通常是通过altarch仓库提供的内核版本一般是4.14系列。这个内核版本对大多数bond模式的支持是完整的但网卡驱动层面的差异才是真正影响bond能否正常工作的关键因素。所以下面我会先讲清楚原理和选型逻辑再进入实操。2. Bond核心原理与ARM平台上的关键差异2.1 Bond到底在做什么从生活类比说起网口bond也叫链路聚合、网卡绑定的本质是把多块物理网卡捆成一块逻辑网卡来用。你可以把它想象成高速公路原来只有一条车道车流量大了就堵现在把两三条车道合并成一条宽路车就能跑得更顺畅。如果其中一条车道塌了车还能走剩下的车道不至于完全堵死。在Linux内核层面bonding驱动提供了一个虚拟网络接口通常叫bond0然后把多块物理网卡比如eth0、eth1作为slave挂到这个虚拟接口上。内核根据配置的bond模式决定数据包怎么从这些slave网卡发出去以及怎么处理来自交换机的回包。2.2 七种bond模式的核心区别与选型逻辑Linux bonding驱动支持多种模式CentOS 7.6上常用的有下面这几种。我把它们的关键特性和适用场景整理成表格方便你对照选择模式编号模式名称是否需要交换机配合带宽叠加冗余能力典型场景mode0balance-rr需要是有对吞吐要求高、交换机支持静态聚合mode1active-backup不需要否强只求冗余、不追求带宽mode2balance-xor需要是有基于哈希的负载均衡mode3broadcast需要否有特殊容错场景mode4802.3ad需要是有标准LACP聚合最常用mode5balance-tlb不需要部分有发送方向负载均衡mode6balance-alb不需要部分有收发双向负载均衡选型的核心逻辑其实就两条你的交换机支不支持动态聚合协议LACP以及你更看重带宽还是冗余。如果交换机支持LACPmode4是首选标准化程度最高排障也最方便。如果交换机完全不配合mode1做冗余是最稳妥的mode6做负载均衡也可以但排查起来麻烦一些。注意mode4需要交换机侧也配置LACP聚合组两边模式必须匹配。我见过有人服务器配了mode4但交换机没配结果bond起来了但网络不通排查了半天才发现是交换机侧的问题。2.3 ARM架构下做bond的几个特殊坑ARM服务器跟x86服务器在bond配置上的差异主要集中在三个地方网卡命名规则不同。x86上常见的ens33、eno1这些命名方式在ARM平台上可能变成eth0、eth1也可能是基于PCIe拓扑的enP2p1s0之类。你得先用ip link或nmcli device status确认实际网卡名不能照搬x86的经验。网卡驱动对ethtool的支持程度参差不齐。有些ARM板载网卡尤其是国产网卡芯片的驱动对ethtool的-S、-i等参数支持不完整导致你没法用常规手段查看bond slave的详细状态。这种情况下得靠/proc/net/bonding/bond0和dmesg来排查。NetworkManager版本行为差异。CentOS 7.6的NetworkManager版本是1.18系列在ARM上某些操作比如nmcli con add type bond的默认参数可能跟x86上的表现不完全一致。我遇到过在ARM上创建bond时默认miimon值没生效的情况需要手动指定。实操心得在ARM平台上做bond之前先用lspci -nn | grep -i ethernet和ethtool -i eth0确认网卡型号和驱动版本。如果驱动是厂商自定义的建议先查一下该驱动对bonding的支持说明有些驱动需要额外加载参数才能正常工作。3. 配置前的环境确认与准备工作3.1 确认系统版本和内核信息动手之前先把底摸清楚。执行下面几条命令把输出记下来# 确认系统版本 cat /etc/centos-release # 输出示例CentOS Linux release 7.6.1810 (AltArch) # 确认内核版本 uname -r # 输出示例4.14.0-115.el7a.aarch64 # 确认架构 arch # 输出示例aarch64注意el7a这个标识它表示这是ARM架构的CentOS 7版本。如果你看到的是el7而不是el7a那可能是x86版本后续操作虽然大体相同但细节上可能有差异。3.2 确认网卡设备名称和状态# 列出所有网络接口 ip link show # 或者用nmcli查看设备状态 nmcli device status输出里你会看到类似eth0、eth1这样的物理网卡以及可能存在的lo回环接口。记下你要做bond的那两块网卡的准确名称。在ARM平台上有时候网卡名会是enP2p1s0f0这种长格式复制的时候别搞错了。同时确认这两块网卡当前没有被其他配置占用# 查看网卡是否已有IP配置 ip addr show eth0 ip addr show eth1如果它们已经有IP并且正在使用你需要先确认这些连接不会因为做bond而中断。如果是远程操作建议先接一个带外管理口或者本地终端避免配置过程中失联。3.3 确认bonding内核模块是否可用# 检查bonding模块是否已加载 lsmod | grep bonding # 如果没有加载手动加载 modprobe bonding # 确认模块信息 modinfo bonding | head -20CentOS 7.6默认是带bonding模块的一般不需要额外安装。但如果你的ARM系统是最小化安装可能需要确认一下kernel-modules包是否完整。3.4 确认NetworkManager服务状态CentOS 7.6默认使用NetworkManager来管理网络。先确认它的状态systemctl status NetworkManager如果NetworkManager是运行状态推荐用nmcli来配置bond这样配置能即时生效且持久化。如果你更习惯传统的network-scripts方式也可以停掉NetworkManager改用network服务但我不推荐这么做因为CentOS 7后期版本对network-scripts的支持在逐步弱化。注意不要同时用nmcli和手动编辑ifcfg文件来管理同一个连接容易产生冲突。选一种方式从头走到尾。4. 用nmcli配置bond的完整实操流程4.1 创建bond主接口假设我们要把eth0和eth1绑定成bond0使用mode4LACP。第一步是创建bond类型的连接nmcli con add type bond con-name bond0 ifname bond0 mode 802.3ad这条命令做了几件事创建了一个名为bond0的连接配置接口名也是bond0bond模式设为802.3ad也就是mode4。在ARM平台上我建议显式指定miimon参数因为默认值有时不会自动写入nmcli con add type bond con-name bond0 ifname bond0 mode 802.3ad miimon 100miimon 100表示每100毫秒检测一次链路状态这是最常用的值。检测频率太高会增加CPU负担太低则故障切换不够及时。100ms是一个经过验证的平衡点。4.2 配置bond的IP地址和网络参数bond0创建好之后给它配上IPnmcli con mod bond0 ipv4.addresses 192.168.1.100/24 nmcli con mod bond0 ipv4.gateway 192.168.1.1 nmcli con mod bond0 ipv4.dns 192.168.1.1 nmcli con mod bond0 ipv4.method manual如果你需要IPv6也可以加上nmcli con mod bond0 ipv6.addresses fd00::100/64 nmcli con mod bond0 ipv6.method manual4.3 把物理网卡添加为bond的slavenmcli con add type bond-slave con-name bond0-slave-eth0 ifname eth0 master bond0 nmcli con add type bond-slave con-name bond0-slave-eth1 ifname eth1 master bond0这两条命令分别把eth0和eth1挂到bond0下面。注意con-name我用了bond0-slave-eth0这种命名方式方便后续识别。4.4 启动bond并验证状态# 启动bond0 nmcli con up bond0 # 启动两个slave nmcli con up bond0-slave-eth0 nmcli con up bond0-slave-eth1启动之后用下面几条命令验证# 查看bond接口状态 cat /proc/net/bonding/bond0输出里你应该能看到Bonding Mode: IEEE 802.3ad Dynamic link aggregation以及两个slave接口的状态。关键要确认MII Status是upSlave Interface下面两个网卡都列出来了。# 查看IP是否生效 ip addr show bond0 # 查看bond连接状态 nmcli con show --active4.5 验证bond是否真正工作光看状态还不够得实际验证。最直接的方法是ping网关ping -c 4 192.168.1.1如果通了说明基本配置没问题。要进一步验证冗余能力可以拔掉一根网线或者用ip link set eth0 down模拟然后继续ping看网络是否中断。在mode4下如果交换机侧配置正确拔掉一根线应该几乎无感知。实操心得测试冗余的时候用ping -i 0.2把ping间隔调小这样能更精确地观察到切换时的丢包情况。正常情况下mode4切换应该只丢1-2个包如果丢包严重说明交换机侧可能没配好。5. 用配置文件方式配置bond备选方案5.1 什么情况下选择配置文件方式虽然nmcli是推荐方式但有些场景下你可能需要用传统的ifcfg文件来配置比如你的ARM系统上NetworkManager被禁用了或者你需要批量部署时用脚本直接写文件。另外有些老运维人员对ifcfg文件更熟悉排查问题时看文件内容比看nmcli输出更直观。5.2 创建bond0的ifcfg文件在/etc/sysconfig/network-scripts/目录下创建ifcfg-bond0cat /etc/sysconfig/network-scripts/ifcfg-bond0 EOF DEVICEbond0 NAMEbond0 TYPEBond BONDING_MASTERyes BOOTPROTOnone ONBOOTyes IPADDR192.168.1.100 PREFIX24 GATEWAY192.168.1.1 DNS1192.168.1.1 BONDING_OPTSmode4 miimon100 lacp_rate1 EOF这里lacp_rate1表示LACP报文每秒发送一次fast模式默认是30秒一次slow模式。fast模式对故障切换更敏感但会增加一点网络开销。如果你的交换机支持fast模式建议开启。5.3 修改物理网卡的ifcfg文件修改ifcfg-eth0cat /etc/sysconfig/network-scripts/ifcfg-eth0 EOF DEVICEeth0 NAMEeth0 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyes EOFifcfg-eth1同理把DEVICE和NAME改成eth1即可。5.4 重启网络服务并验证# 如果使用network服务 systemctl restart network # 如果使用NetworkManager systemctl restart NetworkManager重启后同样用cat /proc/net/bonding/bond0验证状态。注意在ARM平台上有时候systemctl restart network会卡住或者报错这通常是因为某些网卡驱动的初始化时间较长。如果遇到这种情况可以先systemctl stop network等几秒再start而不是直接restart。6. 常见问题排查与避坑指南6.1 bond起来了但网络不通这是最常见的问题排查思路按优先级排列第一检查交换机侧配置。如果用的是mode4交换机侧必须配置LACP聚合组且聚合组里的端口必须和服务器侧的slave网卡对应。我遇到过交换机侧配了聚合但端口划到了错误的VLAN导致bond起来但不通。第二检查bond模式是否匹配。服务器配mode4交换机配静态聚合mode0对应的两边不匹配就会出问题。确认方式是看/proc/net/bonding/bond0里的Bonding Mode和交换机文档。第三检查IP配置。确认bond0的IP、网关、子网掩码都正确。有时候从x86环境复制过来的配置忘了改IP。第四检查防火墙和SELinux。虽然不常见但SELinux在某些ARM发行版上的默认策略可能影响网络。可以临时setenforce 0测试一下。6.2 slave网卡显示MII Status down如果/proc/net/bonding/bond0里某个slave的MII Status是down说明内核认为这块网卡的链路没起来。排查步骤# 检查物理网卡本身的状态 ethtool eth0 # 检查网线是否插好看Link detected ethtool eth0 | grep Link detected # 检查网卡是否被up ip link show eth0如果ethtool显示Link detected: no那就是物理层问题——网线、光模块、交换机端口逐个排查。如果ethtool显示Link detected: yes但bond里还是down那可能是驱动层面的问题试试重新加载网卡驱动modprobe -r 驱动名 modprobe 驱动名6.3 ARM平台上ethtool输出异常前面提到过某些ARM板载网卡的驱动对ethtool支持不完整。如果你执行ethtool eth0报错或者输出明显不对可以试试用mii-tool替代mii-tool eth0或者直接看/sys/class/net/eth0/下面的文件cat /sys/class/net/eth0/operstate cat /sys/class/net/eth0/carrieroperstate显示up且carrier显示1说明链路是通的。6.4 重启后bond配置丢失这种情况通常是因为ONBOOTyes没设置或者NetworkManager没有把连接设为自动连接。用nmcli的话检查nmcli con show bond0 | grep autoconnect如果autoconnect是no改成yesnmcli con mod bond0 connection.autoconnect yes nmcli con mod bond0-slave-eth0 connection.autoconnect yes nmcli con mod bond0-slave-eth1 connection.autoconnect yes6.5 常见问题速查表现象可能原因排查命令解决方向bond起来但ping不通交换机侧未配聚合检查交换机配置配置交换机LACPslave状态down物理链路问题ethtool eth0检查网线/光模块重启后配置丢失autoconnect未开启nmcli con show设置autoconnect yesethtool报错驱动不支持mii-tool替代用sysfs查看状态切换丢包严重lacp_rate太慢查看bond参数改为fast模式bond0无法启动模块未加载lsmod | grep bondingmodprobe bonding实操心得排查bond问题时dmesg | grep -i bond和journalctl -u NetworkManager是最有用的两个日志来源。bonding驱动会在dmesg里打印状态变化NetworkManager的日志则能告诉你配置加载过程中出了什么问题。7. 性能验证与调优建议7.1 怎么验证bond的带宽叠加效果配置完bond之后很多人想知道带宽到底有没有叠加。最直接的方法是用iperf打流测试# 在服务端启动iperf iperf -s # 在客户端测试需要多线程才能跑满聚合带宽 iperf -c 服务端IP -P 4 -t 30-P 4表示用4个并行连接。为什么要多线程因为mode4的负载均衡是基于流的哈希单个TCP连接的流量只会走其中一条slave网卡。只有多个连接才能分布到不同的slave上从而验证带宽叠加。如果测试结果只有单块网卡的带宽可能的原因包括交换机侧聚合没配好、哈希算法导致流量集中在一块网卡上、或者测试工具本身是瓶颈。7.2 调整哈希算法mode4默认的哈希算法是layer2基于MAC地址你可以改成layer34基于IP和端口# 临时修改 echo layer34 /sys/class/net/bond0/bonding/xmit_hash_policy # 永久修改在BONDING_OPTS里加 BONDING_OPTSmode4 miimon100 lacp_rate1 xmit_hash_policylayer34layer34的负载均衡粒度更细适合流量类型多样的场景。但如果你的流量主要是单一大流改哈希算法也帮不上忙因为单条流的流量始终只会走一块网卡。7.3 ARM平台上的性能注意事项ARM服务器的网络性能跟x86有差异尤其是在小包处理和中断处理方面。如果你发现bond之后性能不升反降可以检查一下# 查看中断分布 cat /proc/interrupts | grep eth # 查看网卡队列数 ethtool -l eth0如果所有中断都集中在同一个CPU核心上可以考虑用irqbalance或者手动设置中断亲和性来分散负载。不过这个属于进阶调优一般场景下不需要动。8. 一些实际踩坑后的个人体会做bond这件事配置本身不难难的是排查问题。我印象最深的一次是在一台ARM服务器上配了mode4/proc/net/bonding/bond0显示一切正常两个slave都是up但网络就是不通。查了两个小时最后发现是交换机侧的聚合组里有一个端口被误配成了access模式而不是trunk模式。所以我的经验是bond出问题先查交换机再查服务器。服务器侧的配置就那么几行出错的概率远低于交换机侧。另一个体会是关于ARM平台的。ARM服务器在网卡驱动这块确实不如x86成熟有些问题你在x86上根本不会遇到。比如有一次ethtool -S eth0直接返回空导致我没法看网卡的统计信息。后来发现是驱动版本太老升级驱动之后就好了。所以如果你在ARM上做bond遇到奇怪的问题不妨先查查网卡驱动有没有更新版本。最后说一个细节做bond的时候两块slave网卡的速率和双工模式最好保持一致。如果一块是千兆一块是百兆bond虽然能起来但性能会受限于最慢的那块。用ethtool eth0 | grep Speed确认一下确保两块网卡协商出来的速率是一样的。
