企业官网建设流程全解析

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 -r

CentOS 7.6的内核版本一般是3.10.0-957系列，ARM架构的话通常是aarch64。确认一下你的系统是不是这个版本，因为不同小版本的内核在网卡驱动上可能有差异。

然后确认网卡硬件情况：

lspci | grep -i ethernet ip link show

lspci能看到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驱动支持多种工作模式，每种模式的行为和适用场景都不一样。选错模式可能会导致网络性能下降，甚至出现网络不通的情况。下面这张表把常见的几种模式对比一下：

在ARM服务器上，我一般推荐用mode=4（802.3ad）或者mode=1（active-backup）。mode=4是标准方案，需要交换机支持LACP协议，配置好之后带宽叠加和冗余都能实现。mode=1配置最简单，不需要交换机做任何额外配置，但只有一块网卡在工作，带宽没有叠加。

如果你的交换机支持LACP，而且你对带宽有要求，那就选mode=4。如果交换机不方便改配置，或者你只是想做个冗余，那就选mode=1。mode=6看起来很美，不需要交换机配合就能实现负载均衡，但在某些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（如果交换机端口配了VLAN，bond口也要对应配置）
• 当前网络是否在运行中（如果是生产环境，配置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.conf：

options bonding max_bonds=2 mode=4 miimon=100

这里解释一下几个参数：max_bonds=2表示最多创建2个bond接口，mode=4表示默认使用802.3ad模式，miimon=100表示每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-bond0：

DEVICE=bond0 NAME=bond0 TYPE=Bond BONDING_MASTER=yes BOOTPROTO=none ONBOOT=yes IPADDR=192.168.1.100 PREFIX=24 GATEWAY=192.168.1.1 DNS1=8.8.8.8 BONDING_OPTS="mode=4 miimon=100 lacp_rate=1"

这里BONDING_OPTS里的参数需要根据你选的模式来调整。如果是mode=4，建议加上lacp_rate=1，表示每秒发送一次LACPDU报文，加快链路聚合的协商速度。如果是mode=1，那BONDING_OPTS只需要mode=1 miimon=100就够了。

3.3 配置物理网卡从接口

接下来配置两块物理网卡的配置文件。假设是eth0和eth1，分别编辑/etc/sysconfig/network-scripts/ifcfg-eth0和ifcfg-eth1：

DEVICE=eth0 NAME=eth0 TYPE=Ethernet BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes

eth1的配置类似，把DEVICE和NAME改成eth1就行。这里的关键是MASTER=bond0和SLAVE=yes，这两个参数告诉系统这块网卡是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不通，先检查交换机配置。mode=4需要交换机端口配置LACP，如果交换机没配，bond起不来。mode=1不需要交换机配置，但如果两块网卡都插在同一个交换机上，而交换机没做任何配置，那应该能正常工作。

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里的参数拼错了，或者MASTER=bond0写成了MASTER=bond1。这种问题看日志就能发现。

另一个原因是网卡被NetworkManager接管了。如果NetworkManager还在运行，它可能会跟network服务冲突，导致bond配置不生效。确认一下NetworkManager是不是已经停掉了。

还有一种情况是网卡驱动不支持bonding。虽然大部分网卡都支持，但有些特殊的ARM网卡可能不支持。可以用ethtool -k eth0看看网卡支持的功能，如果tx-checksumming这些基本功能都不支持，那bonding可能也用不了。

4.2 bond起来了但网络不通

bond接口能起来，/proc/net/bonding/bond0也显示正常，但就是ping不通网关。这个问题一般出在交换机侧。

如果是mode=4，交换机端口必须配置LACP。如果交换机没配，或者配的是静态聚合，那bond虽然能起来，但流量发不出去。这时候需要登录交换机检查配置。

如果是mode=1，交换机不需要特殊配置，但要注意两块网卡不能插在同一个交换机端口上（那是不可能的），也不能插在做了端口隔离的交换机上。有些交换机默认开启端口隔离，同一个VLAN下的端口不能互相通信，这会影响bond的故障切换。

还有一个可能的原因是ARP缓存问题。bond切换网卡后，MAC地址可能会变（取决于fail_over_mac参数），交换机那边的ARP表没更新，导致流量发不回来。可以尝试在交换机上清除ARP缓存，或者在bond配置里加上fail_over_mac=1，让bond始终使用当前活跃网卡的MAC地址。

4.3 性能不达预期怎么排查

bond配好了，网络也通了，但测速发现带宽没有叠加，还是单块网卡的速率。这个问题在ARM平台上比较常见，排查思路如下。

首先确认交换机的聚合配置是否正确。mode=4需要交换机配置LACP，而且交换机的哈希算法要跟服务器端的哈希算法匹配。服务器端可以用xmit_hash_policy参数来调整哈希策略：

BONDING_OPTS="mode=4 miimon=100 lacp_rate=1 xmit_hash_policy=layer3+4"

layer3+4表示根据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 常见问题速查表

提示：在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之前，最好先确认一下固件层面的网络配置，避免重复配置导致网络异常。