一个
rac
只能启动一个节点
crs
的问题，目前怀疑是多播问题造成。
前几日在历史库测试
PSU
升级，在完成一个节点软件升级后对第二节点
GI
进行升级时，
CRS
可以正常成功关闭，之后报出了
Error : The opatch Applicable check failed
，于是尝试重新启动
CRS
，但很明显
CRS
无法正常启动。
通过日志查看，发现
CRS-5818:Aborted command 'start' for resource 'ora.cssd'.
在启动
CSSD
资源无法成功，并且从当前的进程情况可以确认
CSS
存在问题。
于是从当时的
CSSD
日志可以看出，
CSSD
在启动时，在准备与远程节点的过程中创建本地通信接口时失败了，具体的日志分析如下：
-
从
gpnp profile
中获取集群的私网信息。
2.
以下开始准备和远程节点通信，并
created local interface for node 'nghis-db2',
但在进行绑定
endpoint (localAddr 'mcast://224.0.0.251:42424/192.169.1.40')
失败了，该本地地址为一个
mcast
地址。
当时看到
No buffer space available (74)
，认为是怀疑是
udp_sendspace
和
udp_recvspace
不够大，查询发现分别为
65536
和
655360
，这实际应用是足够了。不出意料，将该两个参数调大之后重启
CRS
依然无法解决，而在
MOS
上关于该错误的大部分都指向了
BUG,11gR2 Grid Infrastructure Node May not Join the Cluster After Evicted With Error sgipcnUdpSend "No buffer space available (74)" (
文档
ID 1352887.1)
。
但当前的现象与该文档描述不符合，
当前的操作是
sgipcnMctBind
文档中的是
sgipcnUdpSend
3.
更新接口状态，依然无法创建本地接口，即无法与远程节点通信，于是执行了
disable interface
并
clean disabled insterface
4.
重新开始
add interface
，但仍然失败。
5.
之后连续每隔
1
分钟报出了
has a disk HB, but no network HB
，说明此时私网上应该出现了联通性的故障。
于是我们测试了私网地址的联通是否有问题，使用
traceroute
检查，然而并没有联通性问题。
于是就很不理解了，在心跳网卡既然没有问题，为何无法检测到网络心跳。此时问题应该还是出现在以上出现
No buffer space available (74)
的
gipcmodNetworkProcessBind
的过程，对比了节点
1
正常启动
gipchaWorkerCreateInterface
的过程，一共添加了
4
个地址：
1.
udp://192.169.1.39:13034 ——
私网地址
2.
mcast://224.0.0.251:42424/192.169.1.39 —–
多播地址
3.
mcast://230.0.1.0:42424/192.169.1.39 —–
多播地址
4.
udp://192.169.1.127:42424 ——-
广播地址
很明显节点
2
在以上的过程中应该是在添加第二个地址，多播地址
mcast://224.0.0.251:42424/192.169.1.40
时出现了问题。
通过多播检测工具检测私网网卡的多播地址联通性，发现都是检测失败，而测试节点
1
的是成功的，于是怀疑问题应该是出现在节点
2
的多播地址上。
有怀疑是
HAIP
问题，于是尝试将
HAIP disable
掉，并将私网网卡上的
169 ip
依然无法解决。
禁止
haip
命令：
oracle/app/11.2.0.4/grid/bin/crsctl modify res ora.cluster_interconnect.haip -attr "ENABLED=0" -init
最后同事提议使出杀手锏
—
重启主机，由于这套库是历史库，没有实时的业务，确定无影响后就进行了重启主机，重启主机后
CRS
能正常启动，
CSS
也正常通过过了
gipchaWorkerCreateInterfac
步骤。
再次检测私网网卡的多播地址联通性，这次是成功了。
至此，问题解决了，但因为是通过重启主机解决，始终感觉这并不是最终的原因。多播检测不通，是否意味着网络确实是存在问题？这点也不敢断论。
