oracle rac的voting disk在双活中易失效，因跨中心链路抖动会导致节点同时失联仲裁盘，无法区分故障类型而触发驱逐；须改用独立第三方quorum disk+afd，并保障仲裁链路低抖动。
Oracle RAC 本身不解决脑裂，必须依赖外部仲裁机制 —— Voting Disk 是它的“心跳裁判”，但仅靠本地 Voting Disk 在双活场景下会失效。
为什么 Oracle RAC 的 Voting Disk 在存储双活中容易失效
Oracle RAC 集群通过 Voting Disk 判断节点是否存活。在传统单中心部署中，所有节点挂载同一套共享存储（如 SAN），Voting Disk 存于其中，各节点通过读写该磁盘达成共识。
但在同城双活架构下，两个数据中心的 RAC 节点跨中心访问同一套存储时，一旦链路抖动或中断，节点可能同时失去对 Voting Disk 的访问能力 —— 此时集群无法判断是“对方挂了”还是“自己断连了”，直接触发强制驱逐（eviction），导致部分节点被踢出集群，甚至整个集群分裂停服。
常见错误现象包括：
ORA-15064: communication failure with the diskgroup-
CRS-2672: Attempting to start 'ora.cssd' on 'nodeX'后反复失败 - 集群日志中频繁出现
misscount超时、disk heartbeat lost
必须用第三方仲裁：Quorum Disk + ASM Filter Driver（AFD）组合
双活环境下，Voting Disk 必须从“单点共享存储”迁移到“独立第三方仲裁设备”，即部署一个跨中心可达、且与业务存储完全解耦的 Quorum Disk（仲裁盘）。它不参与数据 IO，只承载集群心跳和投票逻辑。
实操要点：
- 仲裁盘必须通过独立网络路径（如专用管理网段）挂载到所有 RAC 节点，不能复用存储网络或业务网络
- 推荐使用 iSCSI 或 NFS 方式提供仲裁盘，避免 FC-SAN 多路径在链路异常时引入不可控延迟
- 启用
ASM Filter Driver (AFD)管理仲裁盘设备路径，防止因 udev 规则错乱或设备名漂移导致节点识别不一致 - 创建仲裁盘时，必须指定
FORCE选项：crsctl add css votedisk /dev/afd/asm-quorum-disk -force - 确保所有节点能稳定 ping 通仲裁服务器 IP，并在
/etc/hosts中静态解析，禁用 DNS 查询
静态优先级（Site Preference）是 fallback，不是主策略
当仲裁服务器整体宕机或网络完全隔离时，RAC 集群会退回到基于节点权重的静态仲裁模式（site preference）。但这只是保底机制，不能作为日常依赖。
关键限制：
- 静态优先级由
crsctl set css votedisk -q和节点cssd启动参数控制，修改后需重启 CSS 进程，不可热生效 - 若两个站点同时失去仲裁连接，而优先级站点恰好发生假死（如 CPU 占满、CSSD hang），另一站点仍会静默等待，无法主动接管
- Oracle 官方明确不推荐仅靠静态优先级支撑双活 ——
ORA-29702错误就是典型征兆 - 必须配合应用层健康检查（如监听端口探测、SQL 查询响应）做二次决策，不能全信集群自身状态
最容易被忽略的细节：仲裁链路质量比存储带宽更重要
运维人员常花大力气优化存储复制带宽和延迟，却忽视仲裁链路的稳定性。实际上，Voting Disk 心跳包极小（KB 级），但要求超低抖动（Jitter
建议在仲裁链路上部署：
- 专用物理网卡 + 独立交换机（不与业务或存储混用）
- 启用 LLDP 和双向 ICMP 监控，用
fping -D -q -c 1000持续压测链路抖动 - 将
misscount从默认 30s 提高到 60s（crsctl set css misscount 60），但必须同步调大disktimeout至 200s，否则 CSSD 会先于仲裁判定失败 - 禁用 TCP Segmentation Offload（TSO）和 Generic Receive Offload（GRO），避免网卡驱动在高负载下丢心跳包
