问题来了 :
用户一套 11.2.0.3 的双节点 RAC 系统安装在 AIX7.1 上。两个节点启动之后,一定会有一个节点的 ora.crsd 资源处于 INTERMEDIATE 状态,换句话说:就是有一个节点的 crsd 启动不起来,那后面的 VIP, listener 等资源自然也就不能被启动了。但是让客户觉得奇怪的是问题并不固定在某一个节点上,有时是节点 1 ,有时会变成节点 2 。
分析过程
事实上上面的问题还是很清晰的,那么就直奔主题,先看看
crsd.log
里面是否出现了错误,导致了
crsd
资源无法被启动
;
上面的信息说明, crsd 进程的确尝试了和 gipcd 进程进行通信, 以便获取链接远程节点 xxxx-2 的相关信息,但是很遗憾并没有找到。
那为什么会找不到呢?难道是本地或者对端的gipc进程出了问题了吗?从我们前面看到的gipcd服务进程已经启动,首先这里我们就可以排除掉,那会不会还有别的情况呢?
这里要解释一下原理来帮助读者理解为什么 crsd 要和 gipcd 进行通信 。
原理解释
:
从
11gR2
版本的集群开始,
gipc
作为一个集群的新的资源(或者叫守护进程)被引入,它的功能是管理本地节点作为心跳网络
(
也称为集群的私网
)
的网卡,而且,本地节点的
gipc
进程还需要通过私网网卡和远程节点的私网网卡建立链接,而这样做的主要目的就是因为
Oracle
的集群管理软件从
11gR2
版本开始支持多块私有网卡。而
crsd
作为集群的应用程序资源管理组件,它需要和
gipc
进行通信来获得到远程节点的一个链接,以便和远程节点的
crsd
进行通信,完成自己的初始化过程。关于更多
gipc
的信息,可以参考《
Oracle RAC
核心技术详解》中对
gipc
的介绍。
悬念
既然知道了原理,那么接下来要做的就是看看在 gipc 层面出现了什么问题。以下是节点 1 的 gipcd.log 信息:
看起来网卡 en2 是作为私网网卡被使用的,而且它的状态也是正常的,但是这段信息 gipcdMonitorCssCheck:updating timeout node xxxx-2 引起了我的注意, gipc 尝试向远程节点发送了一些信息,却发生了超时。
gipc通信超时?难道是节点间的私网通信不通导致的?
答案是否定的!如果是节点间私网私信不通,那么一定这里我们就不会看到cssd进程正常了;对于CRS来说,cssd进程管理了RAC间的网络心跳,如果私网不通,那么意味着cssd进程在启动时根本无法构建集群,同时HAIP也将无法启动,crsctl stat res -t -init命令的输出也会截然不同。
知识点
:cssd加入集群是只需要boot ip能通信,一般就没有问题,而RAC上的ASM实例和DB实例需要HAIP(169.254系列ip)正常时才能正常启动(在HAIP未被禁用的情况下)。
思考
这个时候,就需要冷静一下,来思考是否有别的可能了。既然问题是信息发送不过去,而别的组件通信是正常的,而不同的组件之间通信时会使用不同的端口,消息的长度也可能不同,那么还有两种可能:
1.
UDP
或者
TCP
的端口范围有问题
2.
UDP
或者
TCP
的发送或者接收缓冲区大小有问题。
当然还可能是其他和网络相关的参数设置导致的,不过这种可能性要小很多。
分析到这里之后,在 MOS 上找了一下 AIX 环境中针对网络相关参数的推荐值,以下是一部分参数和它们的推荐值:
用户在检查了相关的参数之后,发现原来是
udp_sendspace
参数出现了问题,被设置成了
8192
。看到了这里,基本上就真相大白了
,
原来是这个参数太低,导致了
gipc
在发送一些信息给远程节点的
gipc
时信息被截断了,造成了这个问题
。
问题解决
用户在把这个值修改成 655360 , 并重新启动了两个节点的 gipcd.bin 进程之后,问题就被解决了。这里要说明一下的是,所谓重启 gipcd.bin 就是指使用操作系统的“ kill -9 <process id of gipcd.bin > ”命令来中止 gipcd.bin 进程,集群在发现这进程被终止之后,会自动启动新的进程。这种方式对集群的运行并没有影响 。
总结
+
+
后续与用户的沟通中我们了解到,原来用户的确是想把参数
udp_sendspace
从原来的
8192
改成
65536
,而且也确实改了,但是之前的修改在重启之后并没有生效,才导致了问题。
在此,小编正式提醒各位伙伴改参数的时候一定要特别注意,否则后续可能会有一系列的问题随之而来!!
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31547066/viewspace-2283439/,如需转载,请注明出处,否则将追究法律责任。