Oracle RAC集群的私网（private network）用于节点间的缓存融合、心跳检测和全局资源协调，重要性甚至高于公网。如果私网只依赖一块物理网卡，一旦网线松动、网卡驱动异常或交换机端口故障，Cache Fusion流量就会中断，轻则节点被驱逐，重则整个集群发生脑裂。因此，在生产环境中对私网进行网卡绑定已成为常规做法。但绑定不是万能的，错误选择绑定模式或忽略交换机配置，反而可能带来更隐蔽的问题。下面从RAC对私网的特殊要求开始，逐步讲解如何正确实施网卡绑定。
RAC私网对链路绑定的特殊要求
RAC的私网并不只是普通的心跳网络，它承担着大量Cache Fusion块传输任务。当一个节点修改了数据块，需要把最新的块镜像通过私网发送给其他节点，以便对方完成一致性读取或写入。这种流量具有突发性强、数据包尺寸不一、对延迟极度敏感等特点。如果私网出现丢包或延迟抖动，Global Cache等待事件会迅速飙升，应用侧可能表现为批量任务突然变慢。
更重要的是，私网数据包必须保证顺序。Cache Fusion协议在传输数据块时依赖TCP或UDP之上的上层协议，乱序到达会触发重传或校验失败。Linux的balance-rr模式虽然能把流量均匀分发到所有物理网卡，但它会打乱数据包的发送顺序，因为不同网卡的传输队列完成时间可能不同。这就导致RAC私网使用balance-rr后，反而出现更严重的性能抖动。因此，RAC私网绑定不能只考虑带宽叠加，还要优先保证顺序性和故障切换时间。
另外，RAC的CSS（Cluster Synchronization Services）会对私网链路进行持续探测，默认的misscount通常为30秒左右。如果绑定模式在物理链路故障后切换时间过长，比如超过10秒，可能触发节点驱逐。所以，选择绑定模式时需要把切换速度作为重要指标，active-backup模式虽然简单，但它的切换时间依赖于miimon检测频率，一般可以控制在1秒以内，配合适当参数可以满足RAC要求。
绑定模式对比与选型建议
Linux bonding支持多种模式，常见的有mode=0（balance-rr）、mode=1（active-backup）、mode=2（balance-xor）、mode=4（802.3ad）和mode=6（balance-alb）。在RAC私网场景下，通常只在active-backup和802.3ad之间做选择，偶尔会用到balance-xor。下面逐个分析它们的特点。
active-backup模式把两块网卡设置为主备关系，同一时间只有一块网卡工作，另一块处于待命状态。它的优点是配置简单，不依赖交换机特殊功能，任何普通二层交换机都能支持。缺点是带宽只有单块网卡的容量，无法叠加吞吐。但对于很多中小规模RAC环境来说，万兆网卡的单口带宽已经足够Cache Fusion使用，active-backup提供的高可用切换能力比带宽叠加更实际。切换时间主要由miimon参数决定，设置为100毫秒时，故障检测和切换通常在1秒内完成，不会触发CSS驱逐。
802.3ad模式也叫LACP动态链路聚合，需要交换机端口配置为LACP协商模式，并且RAC各节点连接的交换机端口必须属于同一个聚合组。该模式的优点是可以在保持数据包顺序的前提下叠加带宽，通常用于双万兆网卡绑定，能获得接近20Gbps的私网吞吐。缺点是配置复杂度高，如果交换机未正确启用LACP，或者链路聚合哈希算法与绑定xmit_hash_policy不匹配，会出现流量只走一条链路或干脆无法通信的情况。在RAC部署中，如果选择802.3ad，务必在正式上线前进行拔线测试，确认切换和恢复行为符合预期。
balance-xor模式根据源目MAC地址或IP地址做异或运算来选择发送网卡，不需要交换机支持聚合，但带宽叠加效果有限，且不同流量可能被分配到不同链路，对RAC私网而言并不比active-backup有明显优势。balance-rr模式虽然带宽叠加最好，但乱序问题已经让它被排除在RAC私网候选之外。综合来看，如果交换机不支持LACP，优先选active-backup；如果交换机支持且确实需要更高带宽，选802.3ad并做好端到端验证。
基于Linux bonding的完整配置步骤
下面以Oracle Linux 7/8或RHEL系操作系统为例，演示如何把两块物理网卡eth1和eth2绑定成bond0，并设置为active-backup模式。先确认系统已经加载bonding模块，可以用modprobe bonding命令加载，也可以直接编辑模块配置文件让它开机自动生效。
第一步，创建/etc/sysconfig/network-scripts/ifcfg-bond0文件，内容如下：
DEVICE=bond0 TYPE=Bond BONDING_MASTER=yes BOOTPROTO=none ONBOOT=yes IPADDR=192.168.10.11 NETMASK=255.255.255.0 BONDING_OPTS="mode=1 miimon=100" USERCTL=no
第二步，修改物理网卡eth1和eth2的配置文件，将它们作为bond0的从属网卡。以eth1为例，修改/etc/sysconfig/network-scripts/ifcfg-eth1：
DEVICE=eth1 TYPE=Ethernet BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no
eth2的配置与eth1相同，只需把DEVICE=eth2修改即可。配置完成后执行systemctl restart network或者重启节点。需要注意的是，在RAC环境中修改私网配置前，建议先停止集群相关资源，避免网络中断导致节点被驱逐。如果是已上线的集群，可以逐节点操作，等一个节点恢复加入集群后再处理下一个节点。
第三步，如果交换机不支持LACP但选择了active-backup，不需要任何交换机配置。如果选择802.3ad，则需要在交换机端口上配置动态聚合，并将两台物理交换机（如果有堆叠或VPC）纳入同一个端口通道。交换机侧的聚合模式必须与服务器侧一致，否则bond0可能一直处于down状态。
配置完成后，可以通过cat /proc/net/bonding/bond0查看绑定状态，确认Currently Active Slave和Backup Slave是否符合预期。例如输出中会显示eth1为Active，eth2为Backup，miimon为100ms。还可以使用ip link show bond0查看链路层状态，以及ethtool bond0检查速率和双工模式。
验证、优化与常见故障处理
验证绑定是否真正生效，不能只看配置文件，必须进行实际故障切换测试。可以在RAC运行负载的情况下，拔掉当前活动网卡的网线，观察集群alert日志是否出现私网短暂超时后又恢复正常。正常情况下，active-backup模式会在1秒内完成切换，Cache Fusion流量不会长时间中断。如果拔线后节点被驱逐，说明切换时间超过了CSS容忍范围，需要检查miimon参数是否生效，或者物理链路检测是否被延迟。
MTU设置是私网绑定中容易忽略的问题。Oracle官方建议私网使用较大的MTU（如9000字节的巨型帧）来减少包数量和CPU开销，但前提是交换机端口的MTU必须同步修改。如果bond0设置为9000，而交换机端口仍为1500，会出现大量分片重组失败或丢包，性能反而下降。可以通过两端ping大包测试确认MTU路径是否畅通，命令如下：
ping -M do -s 8972 192.168.10.12
如果ping不通，说明链路中存在MTU不一致，需要检查交换机、bond0和物理网卡的MTU设置。同时，RAC的interconnect网卡MTU调整后，建议在集群所有节点保持一致，否则跨节点通信会因MTU不匹配而出现异常。
另一个常见故障是交换机聚合口“假活”。在802.3ad模式下，服务器侧显示bond0处于up状态，但交换机侧端口通道未正确协商，导致部分流量被丢弃。这种情况需要登录交换机查看端口通道的成员状态，确认所有物理端口都处于bundled状态，并且LACP协商成功。如果交换机只支持静态聚合，而服务器使用LACP动态协商，也会出现类似问题。解决方法是让两端使用相同的聚合协议，或直接改用active-backup模式绕过聚合依赖。
性能优化方面，如果使用802.3ad，建议设置xmit_hash_policy=layer3+4，让哈希算法基于IP地址和端口信息分配流量，这样更有利于Cache Fusion多连接场景下的负载均衡。对于active-backup模式，可以适当调整miimon=50来加快故障检测，但不要设置过小，否则会消耗更多CPU资源。最后，所有配置变更完成后，建议重启一次节点并观察RAC资源是否正常启动，确保bonding配置在系统重启后依然有效。
