存储延迟必然触发节点驱逐，只要voting disk i/o超disktimeout，cssd即启动驱逐流程且无视网络状态；需查ocssd.log中“lost 2 disk heartbeats”及iostat的%util>95或await>50ms来确证。
存储延迟直接触发节点驱逐，不是“可能”，而是“必然”——只要 voting disk I/O 超过 disktimeout，CSSD 就会启动驱逐流程，且不看网络是否正常。
查证是否真由存储延迟引发驱逐
别急着调参数。先确认是不是 voting disk 本身拖慢了心跳：
打开被驱逐节点的 ocssd.log（路径：$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>），搜索关键词：Lost 2 disk heartbeats 或 disk heartbeat timeout。
如果出现，再结合 iostat -x 1 看 ASM 磁盘组的 %util > 95 或 await > 50ms，基本坐实是存储 I/O 延迟导致。
- 注意：单纯出现
missed heartbeat from node X不代表驱逐，必须看到node eviction initiated或Eviction initiated for node X才是真正触发点 - 若日志中同时报
IPC Receiver dump detected或大量minact-scn: useg scan erroring out，说明实例已卡死，存储延迟只是表象，根因可能是 SGA 过大但_lm_tickets太小（SGA >100GB 时建议设为 5000）
定位投票盘所在磁盘组与I/O瓶颈源头
voting disk 不一定在 OCR 磁盘组里，得用命令确认：crsctl query css votedisk 输出的路径指向哪个 ASM 磁盘组（比如 +VOTE），再查该磁盘组底层物理盘：asmcmd lsdg 看 STATE 和 OFFLINE_DISKS；asmcmd ls -l 进入磁盘组目录，用 ls -l 查文件归属磁盘
- 重点检查对应物理盘的
iostat -x 1输出：重点关注r_await/w_await（单次 IO 延迟）、svctm（服务时间）、%util（设备饱和度） - 常见陷阱：voting disk 和 OCR 放在同一磁盘组，而该组又混布了高 IOPS 的业务数据文件，导致心跳写入被排队挤压
- VMware 环境下务必确认：磁盘控制器类型（建议 LSI Logic SAS）、
disk.EnableUUID=true已启用、共享磁盘已设为“多写入器”模式
安全调整 disktimeout 与 misscount 的硬约束
disktimeout 和 misscount 必须同步改，且严格满足：disktimeout > misscount，否则磁盘心跳永远来不及响应，节点必被误驱逐。
- 查当前值：
crsctl get css misscount、crsctl get css disktimeout - 典型安全值（仅适用于已确认 I/O 延迟在 200–400ms 区间的场景）：
crsctl set css disktimeout 600（单位毫秒）、crsctl set css misscount 300 - 改完必须重启 CSSD：
crsctl stop crs && crsctl start crs（注意：这会重启整个集群，选窗口期操作） - 严禁单独调
misscount：它只管网络心跳容忍时间，对磁盘心跳无效；单调它等于给 CSSD 下了“睁眼瞎”指令
根本解法：隔离投票盘 I/O 路径
调参只是止痛，不是治病。真正要杜绝驱逐，得让 voting disk 的心跳 I/O 不受业务干扰：
- 物理层面：把 voting disk 单独放在低负载、低延迟的 SSD 存储上（不要和 ASM DATA 磁盘组共盘）
- ASM 层面：创建独立磁盘组（如
+VOTE），仅放 voting disk 和 OCR，禁止用户数据写入 - 网络层面：若使用 iSCSI，确保 voting disk 的网卡、交换机端口、存储端口全程独占，不与业务流量混跑
- VMware 场景额外检查：
Memory Hot Add是否禁用（启用会导致 NUMA 绑定异常，间接拖慢 ASM I/O 调度）
驱逐日志里一旦出现连续 Lost disk heartbeats，说明存储路径已经不可信——此时任何参数调整都只是延缓下次崩溃的时间，而非修复问题本身。
