Oracle 23ai RAC 不原生支持微隔离网络，其高可用性提升依赖严格隔离三类网络平面、启用QUIC心跳及FAN事件；需在OS/防火墙层最小化放行、禁用冗余通道并验证QUIC运行状态。
Oracle 23ai RAC 本身不提供“微隔离网络”这一原生概念——它没有类似 Kubernetes NetworkPolicy 或云厂商安全组的细粒度网络访问控制能力。所谓“微隔离”在 RAC 场景中，是运维人员对网络平面职责、流量路径和故障域的**主动收敛与强化约束**，而非开箱即用的功能。真正的高可用提升点，来自对三个网络平面的严格隔离、QUIC 心跳的启用，以及 FAN 事件的精准触发。
为什么不能直接配置“微隔离网络”
Oracle RAC 的网络模型是固定三层结构（Public / Private / VIP/SCAN），所有组件（CSS、CRS、ASM、DB）都依赖这三类网络协同工作。你无法在 crsctl 或 srvctl 中设置“仅允许 node1-priv 到 node2-priv 的端口 6200 TCP 流量”这类规则——RAC 不解析或干预 IP 层 ACL。所谓“微隔离”，实际是：在操作系统/防火墙层做最小化放行 + 在集群配置层禁用冗余通道 + 验证 QUIC 是否真正在跑。
必须做的三件事：QUIC 心跳、FAN 事件、私网专用子网
-
QUIC 心跳不是可选插件，而是 23ai 默认启用但易被静默降级的关键链路：检查是否生效，运行
crsctl stat res -t | grep -i quic。若无输出或显示OFFLINE，说明回退到了 UDP 模式。此时需确认：/etc/sysconfig/iptables或nft list ruleset是否放行了 UDP/6200；lsmod | grep quic是否加载了quic_kmod；节点间能否nc -u node2 6200通；否则脑裂判断将依赖旧版 UDP 心跳，在丢包率 >5% 时极易误判。 -
INSTANCE_UNREACHABLE事件必须显式启用，否则应用层永远等 TCP 超时：执行EXEC DBMS_SERVER_ALERT.SET_THRESHOLD('INSTANCE_UNREACHABLE','ENABLED');。注意该语句只影响当前实例，双节点需分别执行；且客户端 JDBC 驱动版本必须 ≥ojdbc11-23.5.0.0，低版本即使数据库发了事件也完全无视。 -
私网（Private Network）必须物理/逻辑独占，禁止复用公网网卡或混用 VLAN：例如
ens224专用于心跳，其ip a输出里不应出现任何inet公网地址；/etc/hosts中的node1-priv解析必须指向该网卡的纯私有 IP（如10.0.0.200），不能是192.168.1.10这类常被 NAT 或防火墙策略干扰的地址。
容易被忽略的验证点：私网 MTU 和时钟源
QUIC 依赖稳定的 UDP 传输，而私网若存在 MTU 不一致（如一端 1500，另一端 9000），会导致 QUIC 握手包被分片后丢弃，集群日志中仅报 WARNING: QUIC heartbeat disabled，无 ERROR。同样，23ai 已弃用 CTSS，强制依赖 NTP 或 PTP，chronyc tracking 显示 offset >50ms 就可能引发 CSS 同步异常，间接导致 QUIC 心跳被驱逐。这两项不验证，前面所有配置都白搭。
