如何配置RAC私网互联_私有IP网段与冗余网卡绑定实战

私网IP应选10.0.0.0/8或172.16.0.0/12中未被占用的子网如10.10.20.0/24，避开OCR/Voting Disk所在网段及169.254.0.0/16；须用HAIP实现双网卡冗余，禁用bonding，配置arp_ignore=1、arp_announce=2，并验证UDP 12599端口双向连通性。

私网IP网段选哪个才不和OCR/Voting Disk冲突

给Oracle RAC规划私网，第一步就得把网段选对。这里有个铁律：私网必须是独立的网段，绝不能和公网、存储网络混在一起，更要命的是，必须完全避开OCR和Voting Disk所在的网段。一旦撞车，集群启动时cssd进程立马就会给你颜色看，不是报crs-4678: failed to start css daemon，就是抛出ora-15018: diskgroup cannot be created。新手最容易栽的坑，就是随手配个192.168.1.0/24，结果回头一查，发现OCR盘正好通过NFS挂载在同一个网段，导致crsctl check cluster命令怎么跑都是失败。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

具体怎么操作？记住下面几点：

• 首选大网段：优先从10.0.0.0/8或172.16.0.0/12这两个大地址池里，挑一个当前业务没用过的子网。比如10.10.20.0/24就是个不错的选择，当然，前提是得确认10.0.0.0/8这个范围里没有其他办公或业务网段已经占用了。
• 务必确认OCR/Voting Disk路径：选好网段后，必须核实OCR和Voting Disk的存储路径是否落在这个网段内。方法很简单，运行ocrcheck -config查看输出的Device/File Name，再用df -h命令看看挂载点对应的IP；如果用的是ASM磁盘组，那就通过asmcmd lsdg和ls -l /dev/oracleasm/disks/来反推后端存储的IP地址。
• 避开特殊网段：千万别用169.254.0.0/16这个链路本地地址段。在RHEL 7及以后的系统里，默认是禁用该网段的ARP响应的，这会导致oifcfg getif命令根本识别不到你的私网接口。

绑定双网卡做冗余私网要改哪些配置

想让RAC私网更可靠，加一块网卡做冗余是常规操作。但这里有个关键误区：冗余可不是简单地把两张物理网卡都配上同一个网段的IP地址。如果真这么干，等着你的就是ARP冲突和心跳包乱序，crsctl stat res -t命令里ora.cluster_interconnect.haip资源的状态，大概率会一直显示OFFLINE，或者反复在INTERMITTENT状态跳动。

正确的做法，是围绕Oracle的HAIP（高可用IP）特性来配置：

• 启用HAIP，放弃静态IP：必须让Oracle的HAIP来自动管理虚拟IP，千万别手动去配置类似10.10.20.100/24这样的静态地址。
• 用接口，而非IP：使用oifcfg setif命令时，是指定接口和网段，而不是具体的IP。例如：oifcfg setif -global eth2/10.10.20.0:cluster_interconnect，然后再为第二张网卡执行oifcfg setif -global eth3/10.10.20.0:cluster_interconnect。
• 验证配置：配置完成后，运行oifcfg getif应该能看到两行记录，网段相同但接口不同。再用ifconfig | grep -A2 “haip”命令检查，应该能看到类似eth2:1或eth3:1这样带有haip别名的临时IP出现。
• 注意服务干扰：在重启集群就绪服务（CRS）之前，记得先停掉所有节点上的NetworkManager服务，因为它可能会劫持HAIP发出的ARP通告，导致通信异常。

Linux系统层网卡绑定要不要用bonding mode=1

答案是：不要用。RAC的HAIP机制本身已经实现了链路检测和故障切换的功能，如果在底层再套一层Linux的bonding，反而会干扰HAIP自身的判断逻辑。举个例子，如果bond0状态显示是up的，但其中一条物理链路（sla ve）实际已经断开，HAIP可能还会继续往这条失效的链路上发送心跳包，结果就是cvuqdisk的校验失败率直线飙升。

那么，系统层面该怎么配？

• 保持网卡独立：私网的物理网卡（比如eth2和eth3）就保持独立配置，不要创建bond0或使用teamd，让HAIP直接管理这两块网卡。
• 硬件强制的例外：如果某些刀片服务器或交换机的硬件架构强制要求做bonding，那么只允许使用mode=1（主备模式）。并且，必须关闭miimon链路检测，或者将其间隔设置为100毫秒以上，否则HAIP自身的misscount超时机制会和bonding的快速探测产生冲突。
• 内核参数必须调：/proc/sys/net/ipv4/conf/all/arp_ignore和arp_announce这两个内核参数，必须分别设置为1和2。这能防止HAIP管理的虚拟IP去响应非本接口发来的ARP请求，避免地址冲突。

验证私网连通性不能只ping

私网配好了，用ping 10.10.20.11测试能通，是不是就万事大吉了？远远不够。因为HAIP节点间通信使用的是UDP端口12599，并且要求双向低延迟，单纯的ICMP ping测试根本发现不了端口级别的阻塞或者TCP/UDP协议栈的配置问题。

所以，一套完整的验证流程必不可少：

• 测试UDP连通性：使用nc -u -w1 10.10.20.11 12599命令进行UDP连通性测试（测试前需要在目标节点上用nc -u -l 12599启动监听）。
• 运行集群验证工具：执行cluvfy comp nodecon -n all -verbose进行完整的节点连通性校验。要特别关注Node connectivity passed for subnet和Check for multiple interfaces on the same subnet这两项的结果。
• 抓包分析：在私网接口上执行tcpdump -i eth2 ‘udp port 12599’ -c 20进行抓包，最好在互联的两个节点上同时进行，观察是否存在单向流量。
• 查看日志线索：多留意/var/log/oracle/crsd/crsd.log日志文件，里面如果出现IPC timeout或missed heartbeat的记录，往往比crsctl check cluster命令的输出更能提前暴露问题。

最后，需要警惕一种更隐蔽的情况：HAIP地址漂移的时机，可能与OCR磁盘的I/O路径产生耦合。比如，当私网延迟突然增大，HAIP还没来得及切换，但OCR的读写操作已经开始超时。这时候，单纯调大misscount参数可能只是掩盖了底层的网络抖动。真正的排查，还得结合netstat -s | grep -i “retransmit”这类命令，查看网络重传统计，进行综合判断。