为何Oracle RAC在断网测试中未能按预期触发VIP漂移

VIP不漂移主因是RAC未触发failover：ifconfig down网卡属管理操作，非故障；真实断网需通过心跳超时（如丢UDP 12345包）或启用ping target探测远端可达性来验证。

断网测试中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 <other_node_public_ip> -p udp --dport 12345 -j DROP</other_node_public_ip>
• 或临时重定向voting disk路径（需ASM未mount），让磁盘心跳超时，触发更底层的驱逐
• 观察$GRID_HOME/log/<host>/cssd/ocssd.log，搜索missed heartbeat和node eviction initiated，这才是VIP开始漂移前的真实信号
• 漂移发生后立刻在新节点跑arping -U -c 3 -I eth0 <vip_address>，否则客户端可能因ARP缓存旧MAC而连不上

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