HAIP启动失败：先看日志再动网卡
oracle rac私网心跳异常，最典型的表征就是ora.cluster_interconnect.haip资源反复尝试启动后进入failed或offline状态，进而拖垮ora.asm和数据库实例。这不是网络连不通的简单问题，而是haip在初始化阶段就卡住了。
关键动作不是立刻改网卡或重启CRS，而是先确认HAIP是否真的被创建出来：
执行ifconfig -a | grep 169.254，看有没有ethX:1或enp0s9:1这类带冒号的子接口和对应IP；没有，说明HAIP根本没起来查$GRID_HOME/log/<hostname>/cssd/ocssd.log，搜索no network HB或clssnmvDHBValidateNCopy，若出现“has a disk HB, but no network HB”，基本锁定HAIP通信层失败用crsctl stat res -t -init确认ora.cssd是否ONLINE——如果CSSD都起不来，说明底层心跳协议（UDP多播/单播）压根没通，HAIP连入场机会都没有
UDP通信不通：防火墙、MTU、路由三连查
HAIP依赖底层UDP通信完成节点间心跳包交换，而这个UDP通道极易被系统级策略掐断。很多DBA以为关了firewalld就万事大吉，其实远不止如此。
iptables -L -n必须检查，尤其INPUT链中是否有REJECT或DROP规则匹配UDP端口（默认12345–12350）或目标为169.254.0.0/16的包私网网卡MTU值不一致是隐形杀手：一个节点设mtu 1500，另一个设mtu 9000（Jumbo Frame），会导致HAIP握手包被静默丢弃。统一执行ip link set dev eth1 mtu 1500arping -I eth1 -c 3 169.254.10.10（任一HAIP地址）测试二层可达性；若失败，检查是否启用了rp_filter（反向路径过滤）：sysctl net.ipv4.conf.eth1.rp_filter应为0或2，不能是1
冗余网卡配置错：oifcfg setif顺序与ASM依赖关系
加第二块私网网卡不是配好IP就完事了。HAIP能否接管新网卡，取决于oifcfg注册顺序和集群当前状态。常见错误是直接oifcfg setif后不重启HAS，导致GPnP配置未生效。
新增网卡前，先用oifcfg getif确认当前私网接口列表；新增时务必指定准确子网，例如oifcfg setif -global enp0s9/10.10.10.0:cluster_interconnect，子网掩码必须和实际IP匹配，否则HAIP拒绝绑定修改后必须停启HAS：crsctl stop has → 等ps -ef | grep -i "cssd\|ohasd"全退出 → crsctl start has；仅crsctl restart resource ora.cluster_interconnect.haip无效若已有ASM磁盘组使用了旧私网路径（如+DATA基于eth1），新增网卡不会自动迁移IO路径；HAIP只是提供通信通道，ASM实例仍通过原始私网IP访问OCR/Voting Disk，这点常被误认为“加了网卡就负载均衡了”
禁用HAIP不是退路，而是隔离手段
当所有网络排查无果，且业务无法长时间停机时，临时禁用HAIP可快速恢复集群功能。但它不是修复方案，而是把问题从“Oracle集群层”下放到“OS网络层”，后续仍需补操作系统级bonding或teamd。
禁用命令是crsctl modify resource "ora.cluster_interconnect.haip" -attr "ENABLED=0"，不是删掉资源；之后crsctl stop resource ora.cluster_interconnect.haip再crsctl start has禁用后，gv$cluster_interconnects将为空，ASM实例会回落到使用oifcfg getif中注册的原始私网IP（如10.10.10.11）通信，此时必须确保该IP在所有节点间UDP双向可达注意：19c GI中禁用HAIP后，ora.asm可能仍报ORA-15032或ORA-15063，需同步检查asmcmd dsget输出是否含正确磁盘路径，避免OCR位置解析失败
HAIP本身不处理物理链路切换延迟，它依赖CSSD的超时机制触发漂移。真正影响RAC稳定性的，往往是那几毫秒的UDP丢包窗口和内核参数对net.ipv4.udp_mem的默认限制——这些细节，比选几块网卡更值得花时间抠。
评论(0)