浅谈Oracle RAC(6) 之实战：节点reboot问题的调查方法

编者按：

本文作者系肖遥（花名），现任甲骨文技术支持工程师 ，目前专注于Oracle RAC领域。个人主页:

https://blog.csdn.net/weixin_50510978，经其本人授权发布。

【免责声明】本号文章仅代表个人观点，与任何公司无关。

我们在上面的博文中介绍了CSS组件。今天我们继续围绕CSS组件的节点排除问题来总结一下常用的故障调查方法。

我们都知道CSS组件维护集群关系的两个最重要的手段就是NHB和DHB。这也就意味着如果CSS组件的NHB和DHB的任何一个出现问题，都没有办法让集群确认到各个节点的关联信息，那么CSS组件会被Abort掉，节点会被排除出集群。

1.丢失NHB

各个节点的CSS组件之间丢失NHB又可分为私网通信故障和节点夯两个场景。

1.1 私网通信故障

我们以两个节点node1和node2构成的RAC为例，当节点间的私网通信出现故障时，node1上的CSSD无法与node2上的CSSD通信，同时node2上的CSSD也无法与node1上的CSSD通信。所以在两个节点的GI告警日志中都会分别打印出丢失NHB的信息。最终其中一个子集群会被排除出集群。

例如在节点2上会打印如下信息。

[OCSSD(9187)]CRS-1612: Network communication with node node1(1) has been missing for 50% of the timeout interval.  If this persists, removal ... from cluster will occur in xxxx seconds
[OCSSD(9187)]CRS-1611: Network communication with node node1 (1) has been missing for 75% of the timeout interval.  If this persists, removal ...  from cluster will occur in xxx seconds
[OCSSD(9187)]CRS-1610: Network communication with node node1 (1) has been missing for 90% of the timeout interval.  If this persists, removal ... from cluster will occur in xxxx seconds

同时在节点1上的GI告警日志中也会出现打印这样的信息。

如果我们查看被排除节点的CSSD的追踪日志，就会发现CSSD因为丢失NHB而被Abort的信息。

例如:

[CSSD]clssnmvDHBValidateNcopy: node 1, node1, has a disk HB, but no network HB, DHB has rcfg xxxx, wrtcnt, xxxx, LATS xxxx, lastSeqNo xxxx, uniqueness xxxx, timestamp xxxx
[CSSD]clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 2 nodes with leader 2, node2, is smaller than cohort of 2 nodes led by node 1, node1, based on map type 2
...
[CSSD]###################################
[CSSD]clssscExit: CSSD aborting from thread clssnmRcfgMgrThread
[CSSD]###################################
[CSSD]clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally

看到这里，其实我们就可以说大概率上来说是由于网络问题引起的了。为了佐证我们的判断，这时候我们需要查看OS命令监控到的私网通信的信息。很多朋友可能习惯性的去用ping命令来查看私网通信问题，这是非常不严谨的。因为在私网通信时可能存在丢包的现象，ping命令没有问题，但是丢包现象却能引起CSSD之间无法正确确认到NHB。所以我们在查看私网通信问题时往往使用的命令是netstat -s。比如查看netstat -s的以下项目是否有问题则是非常有帮助的。

“udpInOverflowsudpInOverflows”,
“packet receive errors”,
 “fragments dropped” 
 或者 “outgoing packet drop”

另外GI重启时都会去扫描/etc/oracle/lastgasp 或者 /var/opt/oracle/lastgasp的log。并将节点重启的信息打印到GI告警日志中。

1.2 节点夯

我们依然以两个节点node1和node2构成的RAC为例。当node1夯住时，node2的CSSD无法与node1上的CSSD进行NHB，这时候node2的GI告警日志中依然会打印CRS-1612等与node1之间丢失NHB的信息。但是节点1中，因为节点夯，所以CSSD被夯住而无法正常工作，所以节点1的GI告警日志中就不会输出任何丢失NHB的信息。那么最终节点1会被排除出集群。

这里面的节点夯其实也分为几个场景。

1.2.1

OS资源不足造成CSSD无法工作，但是cssdagent或者cssdmonitor都还可以正常工作。这时候cssdagent或者cssdmonitor向CSSD发送LHB(local heart beat)时发生LHB丢失。这时候cssdagent或者cssdmonitor会将CSSD强制停止。那么在GI告警日志中会输出扫描lastgasp 日志的信息。

例如:

CRS-8011:reboot advisory message from host: node1, component: cssagent, with timestamp: xxxxxx

1.2.2

如果cssdagent和cssdmonitor都无法工作的时候，代表整个集群的任何进程都被夯住，这时候从GI的日志中已经无法查看到任何有用的信息。我们只能从其它节点的GI日志去查看节点是否被集群排除掉的信息。

当然，调查节点重启时，查看GI的日志只是辅助的信息，最终还是需要查看OS资源监测的信息来确定。

2.丢失DHB

CSSD定期向共享磁盘上的投票盘发送DHB。Linux操作系统中，一般使用ioctl命令对投票盘进行IO操作。如果投票盘IO丢失时，在集群的告警日志中会有CRS-1615，CRS-1614，CRS-1613的告警信息输出。他们分别代表投票盘IO丢失时间超过了timeout值的50%, 75%, 90%。

CRS-1615:No I/O has completed after 50% of the maximum interval. Voting file "string" will be considered not functional in "number" milliseconds
CRS-1614:No I/O has completed after 75% of the maximum interval. Voting file "string" will be considered not functional in "number" milliseconds
CRS-1613:No I/O has completed after 90% of the maximum interval. Voting file "string" will be considered not functional in "number" milliseconds

当超过半数的投票盘的IO丢失都达到了设定的timeout值时，CSS会被abort。

ERROR: clssnmDiskPMT: Aborting, 2 of 3 voting disks unavailable
ERROR: ###################################
ERROR: clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread
ERROR: ###################################

这个时候从OS的角度我们需要查看iostat命令的信息来佐证上面的结果是否是一个真实的IO问题。

3.其他原因

除了丢失NHB和DHB造成CSSD被Abort之外，一些阻塞CSSD进程的配置或者命令也会造成节点重启。比如在较低版本中，pstack命令会阻塞CSSD进程。另外THP(Transport Huge Page)也会阻塞CSSD进程。所以在RAC环境中，我们不能配置THP。

当然CSS上面也并不排除bug的存在，但是在高版本的RAC中，CSS上的bug几乎已经看不到了。

4.关于OS资源监测工具

我们在调查GI问题时，OS资源监测信息是特别重要的。甲骨文为我们提供了OSWatcher监测工具。所以在任何RAC环境中，安装并运行OSWatcher则是非常必要的。有些用户在出现问题时往往无法提供OS资源监测的任何信息却试图通过GI日志来做结论性判断其实是本末倒置。

如果RAC环境中没有安装OSWatcher的时候，有时候也可以使用CHMOS信息来进行调查。CHMOS可以监控CPU,内存，网络通信等信息。但是CHMOS只是对OSWatcher的一个补充工具，有时候无法替代OSW的作用。另外CHMOS的信息也是有保存期限的。所以一旦出现reboot问题，如果想要通过CHMOS调查OS的信息，要急时使用以下命令获取CHMOS的信息。

oclumon dumpnodeview -allnodes -v -s "start time" -e "end time" > /tmp/chm.log

今天先写到这里，希望今天的内容能对关注RAC实战的同学有所帮助。