浅谈RAC – 节点排除的故障调查方法
我们在上面的博文中介绍了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实战的同学有所帮助。