Oracle RAC断网测试VIP漂移未触发原因

有件事你可能不知道：VIP不漂移的常见原因

有件事你可能不知道：过去好几个排障群里问“为什么VIP不漂移”的案例，绕了一圈回来，最终原因都挺一致的——RAC压根不觉得那次是“故障”。 断网测试中VIP不动，大概率不是Oracle没检测到网络故障，而是集群根本没把这次“断网”识别为需要触发failover的事件。它根本没进入故障判定流程。

为什么ifconfig down公网网卡后VIP纹丝不动

Oracle RAC默认只检查网卡是否UP、IP是否配置，并不会主动去探测网卡能不能通外网。直接执行ifconfig eth0 down，虽然物理链路断了，但Clusterware看到的是“网卡已关闭”。这属于预期内的管理操作，不会触发驱逐，也不会触发VIP漂移。

• 它和真实线缆拔掉或交换机端口down有本质区别：后者网卡仍然是UP的，只是收不到包，cssd才会走心跳超时逻辑。
• 像srvctl stop nodeapps -n或crsctl stop crs这类显式停止命令，也会抑制VIP漂移，因为资源状态被标记为“人为停用”，不是“故障”。
• 验证方式：在节点上执行oifcfg getif，确认public网卡名是否还在输出中。如果已经消失，说明Clusterware已经把它从心跳路径里剔除了，自然不判故障。

虚拟机环境里拔网线为啥也不漂移

VMware/KVM这类虚拟化平台，当你在宿主机侧拔掉vNIC的物理连线时，客户机操作系统通常收不到链路状态变化的通知（carrier down）。ethtool eth0仍然显示“Link detected: yes”，网卡持续UP而且能ARP、能ping通本机。RAC就认为“一切正常”。

• 这也是12c引入ping target功能的根本原因：靠主动探活远端地址，来补足本地检测的盲区。
• 检查是否启用：srvctl config network -k 1，看输出里有没有Ping Targets字段。
• 未启用时，哪怕你拔了线、客户端连不上VIP，crsctl check cluster依然返回SUCCESS，ocssd.log里也看不到missed heartbeat。

misscount设得太大，反而会掩盖真实断网

哪怕心跳真的丢了，如果misscount值设置得特别大（比如120秒），而你的断网测试只维持了20秒，cssd会安静地等满120秒才启动驱逐。这期间VIP完全不响应。

• 查当前值：crsctl get css misscount
• 默认30秒（11gR2+），虚拟化环境建议45–60秒。但绝不能盲目堆高；超过90秒基本就失去了快速故障转移的意义。
• 注意：这个参数所有节点必须一致，否则集群起不来；修改后需要crsctl stop crs && crsctl start crs全量重启。
• 别只盯着misscount——disktimeout必须大于它。否则磁盘心跳永远赶不上网络心跳超时，节点反而更容易被误驱逐。

真正该测的不是“断网”，而是“心跳不可达”

想验证VIP漂移机制是否有效，跳过网卡层，直接模拟心跳失败更可靠。

• 在目标节点防火墙里，丢弃发往其他节点public IP的UDP 12345端口（cssd心跳端口）：iptables -A OUTPUT -d -p udp --dport 12345 -j DROP
• 或者临时重定向voting disk路径（需ASM未mount），让磁盘心跳超时，触发更深层的驱逐。
• 观察$GRID_HOME/log//cssd/ocssd.log，搜索missed heartbeat和node eviction initiated，这些才是VIP开始漂移前的真实信号。
• 漂移发生后，立刻在新节点跑arping -U -c 3 -I eth0 ，否则客户端可能因为ARP缓存旧MAC地址而连不上。

断网测试失效，原因往往是测试方式和RAC故障检测机制错位。与其反复拔线，不如直击心跳路径，再配合ping target和ARP刷新，才能让VIP在真实故障中稳稳接住流量。