确认是cssd主动驱逐而非系统崩溃：先查ocssd.log中“node eviction initiated”或“reboot advisory”时间是否早于系统重启记录，再结合crsctl stat res -t全offline与ps检查cssd进程状态综合判断。
不是“自动下线”，而是被 cssd 主动驱逐（eviction）——节点没死，是集群认为它失联了，强制踢出。
怎么确认是 CSSD 驱逐而非系统崩溃
别只看系统重启时间，得比对日志和进程状态：
- 查
ocssd.log：搜索node eviction initiated或reboot advisory，如果出现时间早于dmesg或/var/log/messages里的 reboot 记录，就是集群主动驱逐 - 运行
crsctl stat res -t：若所有资源全为OFFLINE，但crsctl check cluster -all显示节点 “ONLINE”，说明节点已注册但未加入通信环，卡在中间态 - 执行
ps -ef | grep cssd：若cssd进程消失或僵死，而ohasd还在，大概率是心跳中断后 CSSD 主动终止自身
Flex Cluster 下驱逐的三大隐性根源
Flex 架构放大了底层不稳的影响，尤其 hub/leaf 分离后，问题更容易被掩盖：
-
voting disk所在 ASM 磁盘组 IO 延迟高：iostat -x 1中%util > 95或await > 50ms→ 磁盘心跳超时，调大disktimeout无效 - 私网“假通”：NIC offload（如
ethtool -K eth1 gro on）导致 TCP 重传异常，ping通但traceroute -n <private_ip></private_ip>路径不稳定 -
ora.cluster_interconnect.haip没起来：ip a | grep 169.254无输出 → HAIP 失效，hub node 间心跳断，leaf node 会因依赖 hub 而集体失联
Flex Cluster 特有风险点：leaf node 间接引发 hub 驱逐
leaf node 本身不参与 voting，但它通过 hub node 访问数据；一旦 leaf node 上应用异常占用大量私网带宽或触发内核资源争用（如 UDP socket flood），可能拖垮所在 hub node 的网络栈，导致该 hub node 被其他 hub node 驱逐：
- 检查
netstat -s | grep -i "receiving errors"和cat /proc/net/snmp | grep -i "Udp:"，确认是否有 UDP 接收溢出 - leaf node 上运行中间件时，若未限制其网络连接数或未关闭 Nagle 算法，可能加剧私网拥塞
- hub node 的
cssd日志中若频繁出现missed heartbeat from node X，但 X 是 leaf node，则说明问题不在 X 本身，而在它所连接的 hub 节点负载过高
Flex Cluster 的分层设计让故障定位更隐蔽：leaf node 不挂，不代表 hub node 安全；hub node 没报错，也不代表私网链路健康。真正要盯的，是 HAIP 是否在线、voting disk 的 IO 响应、以及 traceroute 到每个私网 IP 的路径稳定性——这些细节一漏，驱逐就成常态。
