如何处理RAC网卡故障后的恢复_网卡重新激活与Clusterware网络识别

网卡恢复后需手动触发 Clusterware 网络重发现并校验 oifcfg 与 HAIP 配置：先 crsctl stop/start crs，再 oifcfg setif 更新网卡，放行 169.254.0.0/16 防火墙规则，确保私网 MTU 一致且 cvuqdisk 依赖的 ASM 就绪。

网卡 down 后 crsctl check cluster 显示节点不可达怎么办

oracle rac 的 clusterware 不会自动感知物理网卡重连或驱动重载，哪怕 ifconfig 或 ip link show 已显示网卡状态为 up，crsctl 仍可能持续报“crs-4638: oracle high availability services is online”但节点间无法通信。根本原因是 clusterware 在启动时读取并缓存了网络配置（尤其是 ocrconfig -showbackup 中记录的网络拓扑），后续不主动 re-scan。

实操建议：

• 先确认网卡是否真通：用 ping -I <em>public_ifname</em> <em>other_node_public_ip</em> 和 ping -I <em>private_ifname</em> <em>other_node_private_ip</em> 分别测试，避免只看 UP 状态就误判
• 强制触发 Clusterware 网络重发现：运行 crsctl stop crs -f（所有节点依次执行，非并行！），再 crsctl start crs；注意不要用 crsctl restart crs，它跳过网络初始化阶段
• 检查 OCR 中记录的网卡名是否与当前 ip link 输出一致：运行 oifcfg getif，若返回空或旧网卡名（如 eth0 但实际已是 ens192），需先 oifcfg delif -global 清空，再 oifcfg setif -global <em>new_ifname</em>/<em>subnet</em>:public 重新注册

私网网卡恢复后 cvuqdisk 报错或 cluvfy comp nodecon 失败

私网不通是 RAC 最典型的“假活”场景：CRS 进程在跑，VIP 漂移正常，但节点间心跳丢包，最终触发 evictions。而 cvuqdisk（CVU 依赖的共享磁盘校验模块）在私网异常时会反复重试连接，导致 cluvfy 卡住或直接失败。

实操建议：

• 不要等 cluvfy 自动超时，手动加 -verbose 参数定位卡点：cluvfy comp nodecon -n all -verbose，重点关注输出中“Checking interface xxx on subnet”后是否 hang 住
• 确认私网 MTU 是否一致：RAC 要求所有节点私网接口 MTU 完全相同（通常 1500），用 ip link show <em>priv_if</em> | grep mtu 核对，不一致会导致 ICMP 包被静默丢弃，ping 看似通但 GI 心跳失败
• cvuqdisk 报“Unable to open /dev/oracleasm/……”本质是 ASM 实例未就绪，此时应先查 crsctl stat res -t | grep asm，而非重装 cvuqdisk

ocrcheck 成功但 crsctl stat res -t 显示 ora.cluster_interconnect.haip OFFLINE

HAIP（High Availability IP）是 11.2+ RAC 私网冗余的关键组件，它不依赖物理网卡绑定，而是由 Clusterware 在私网子网上动态分配一个虚拟 IP（如 169.254.x.x）。一旦底层私网接口恢复但 HAIP 未重建，节点间仍无法通信，ora.cluster_interconnect.haip 就会卡在 OFFLINE。

实操建议：

• 检查 HAIP 子网是否被系统防火墙拦截：RHEL/CentOS 7+ 默认启用 firewalld，需放行 169.254.0.0/16 流量，命令：firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="169.254.0.0/16" accept'，然后 firewall-cmd --reload
• 手动触发 HAIP 重建（谨慎）：仅当确认私网已通且 oifcfg 正确时，执行 crsctl stop res ora.cluster_interconnect.haip -init，再 crsctl start res ora.cluster_interconnect.haip -init；切勿在私网未通时强启，会加剧脑裂风险
• 验证 HAIP 是否生效：在任一节点执行 oifcfg getif 应看到类似 eth1 192.168.10.0 global cluster_interconnect,asm，且 ip addr show 中能查到 169.254.x.x 地址

网卡恢复后 VIP 没漂回原节点，或 SCAN VIP 无法解析

VIP 是绑定在网卡上的，网卡 down 期间 VIP 会被移到其他节点；但网卡恢复后，Clusterware 默认不会自动“漂回”，除非该节点重启 CRS 或手动干预。SCAN VIP 则依赖 DNS 或 GNS，网卡故障常伴随本地 /etc/resolv.conf 或 GNS 配置失效。

实操建议：

• 强制 VIP 回迁（仅限业务低峰）：srvctl relocate vip -n <em>target_node</em> -i <em>vip_name</em>；注意 vip_name 是 srvctl config vip -n <em>node</em> 返回的完整名称（如 rac1-vip），不是 IP
• SCAN VIP 解析失败优先查本地 DNS 设置：确认 /etc/resolv.conf 中 nameserver 指向的是 GNS 地址（如 192.168.10.254）或外部 DNS，且该 DNS 确实已配置 SCAN 名称的 A 记录（非 CNAME）
• 临时绕过 DNS 测试：用 nslookup <em>scan_name</em> <em>gns_ip</em> 直接查 GNS，若通但系统解析不通，大概率是 resolv.conf 被 NetworkManager 覆盖，需设 PEERDNS=no 并重启 network 服务

网卡恢复不是终点，Clusterware 对网络状态的“记忆”比操作系统更顽固。最容易被忽略的是 oifcfg 缓存和 HAIP 子网的防火墙策略——这两处不处理，即使 ping 通、ifconfig up，RAC 依然算“半瘫痪”。