前言
对于集群的节点驱逐问题来说,我们可以通过集群心跳机制分为三大类:
1. 网络问题导致网络心跳超时发生的节点驱逐
2. 存储设备或链路问题导致磁盘心跳超时发生的节点驱逐
3. 服务器资源不足/CSSD进程故障导致本地心跳超时发生的节点驱逐
本文主要在上述三个心跳机制的方向下,简述几种常见的节点驱逐现象及成因,示例部分情况下的日志信息及排查方法,如有疏漏感谢指出。
1.网络心跳超时导致的集群节点驱逐
节点驱逐现象:
一般为集群软件重启(11.2及以上版本),操作系统重启(10g及11.1版本)。
机制原理:
集群的网络心跳由各节点的CSSD进程集群通过私网(Privat IP)网卡通信实现,网络心跳的timeout时间基于misscount参数,默认为30s,也就是说集群节点间cssd进程失联超过30s就会发生网络心跳超时导致的节点驱逐。对于我们常见的2节点集群,节点驱逐的规则一般为节点编号较小的节点保留,也就是说一般情况下的网络心跳超时存活的都是节点编号为1的节点。而在12.2版本出现了基于权重的节点驱逐特性,可以根据用户配置的权重或资源保证特定节点的存活。2节点及以上的更多节点的集群则是以节点数量作为优先存活标准。总的来说判断优先级为:节点数量>节点权重(12.2版本以上)>节点编号。
日志示例:
排查日志一般为cssd进程日志以及集群alert日志
cssd进程日志:
WARNING: clssnmPollingThread: node <node> (1) at 75% heartbeat fatal, eviction in 7.960 seconds
集群alert日志:
[cssd(264805)]CRS-1610:Network communication with node <node name> (1) missing for 90% of timeout interval. Removal of this node from cluster in 2.110 seconds
一般网络心跳问题需排查私网心跳网卡(Private IP 网卡)之间的链路可用性,排查私网网卡间通信是否存在丢包或者包重组现象。需要注意的是网络心跳问题排查时,需要排查故障节点的全部日志以确定是由于网络心跳超时导致的节点驱逐问题。例如在发生本地心跳超时的时候(11.2版本为例),故障节点并不会向远端节点发送本地故障节点信息。也就是说在远端节点发现的日志信息为网络心跳超时,想要排查根本原因还是要需要排查故障节点,对比日志告警时间以确认问题根源。
2.磁盘心跳超时导致的集群节点驱逐
节点驱逐现象:
一般为集群软件重启(11.2及以上版本),操作系统重启(10g及11.1版本)。
机制原理:
集群的磁盘心跳是指在于节点与OCR/VF磁盘之间的通信,一般基于disktimeout参数,默认为200s。
日志示例:
排查日志一般为CSSD进程日志、集群alert日志,系统message日志
cssd进程日志:
2012-03-27 22:05:48.693: [ CSSD][1100548416](:CSSNM00018:)clssnmvDiskCheck: Aborting, 0 of 3 configured voting disks available, need 2
2012-03-27 22:05:48.693: [ CSSD][1100548416]###################################
2012-03-27 22:05:48.693: [ CSSD][1100548416]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread
在11.2以上的环境下,如果磁盘故障持续存在,我们可以在集群alert日志中发现不断尝试重启失败的日志:
[cssd(3824)]CRS-1714:Unable to discover any voting files, retrying discovery in 15 seconds; Details at (:CSSNM00070:) in /opt/ora11grid/log/nodename/cssd/ocssd.log
系统message日志:
Mar 27 22:03:58 choldbr132p kernel: Error:Mpx:All paths to Symm 000190104720 vol 0c71 are dead.
Mar 27 22:03:58 choldbr132p kernel: Error:Mpx:Symm 000190104720 vol 0c71 is dead.
Mar 27 22:03:58 choldbr132p kernel: Buffer I/O error on device sdbig, logical block 0
磁盘心跳超时问题非常明确,排查存储设备及存储链路。
3.本地心跳超时导致的集群节点驱逐
节点驱逐现象:
一般为操作系统级别的重启
机制原理:
本地心跳实际上属于11.2之后的概念,其主要是对于cssd进程及操作系统资源的监控(心跳)。对于10g及11.1版本来说实际没有严格意义上的本地心跳,这部分版本通过oprocd以及oclsomon进程实现本地心跳的功能。而这两个进程的功能在11.2版本之后整合到cssdagent以及cssdmonitor中,由网络心跳message发送线程同时向本地cssdagent和cssdmonitor进程注册cssd进程的状态,一旦本地心跳超时则认为本地节点的cssd进程出现问题,则重启该节点,oprocd进程则作为其中的一个线程存在。需要注意的是此种重启方式不会通知远端节点,所以远端节点的日志中一般出现的是网络心跳超时告警。同时对于本地数据库服务器建议留有资源监控软件,一般常用的是Oracle的OSWatcher,操作系统资源日志对于分析本地心跳超时/操作系统重启原因十分重要。
日志示例:
排查日志一般为cssdagent/cssgmonitor、系统message、OSW日志等
cssdagent/cssdmonitor日志:
2021-04-23 09:45:32.044 : USRTHRD:12461824: [ INFO] (:CLSN00121:)clsnproc_reboot: Impending reboot at 75% of limit 28130; disk timeout 28130, network timeout 25930, last heartbeat from CSSD at epoch seconds 1619142310.896, 21151 milliseconds ago based on invariant clock 3804808287; now polling at 100 ms
本地心跳超时及数据库服务器操作系统重启问题主要排查方向为操作系统资源使用情况以及cssd进程故障,如是否存在系统资源如CPU、内存资源耗尽的情况,CSSD进程是否存在bug等(检查cssd进程日志)。
PS:对于集群问题来说,在上述三个方向的前提下,每个版本由于不同的特性排查的手段需要灵活变通。例如在10g及11.1环境下的集群,无论是任何心跳问题都会重启问题节点的操作系统。而在11.2版本以上的集群由于rebootless restart新特性的出现,集群软件将会首先尝试关闭产生I/O的相关进程及资源,只有在无法停止这些资源的情况下会重启操作系统,当前这个前提是cssd进程存活且正常运行。
附:
1.关于oprocd进程
在Oracle 10g版本的集群中,操作系统及cssd进程的监控分别由oprocd进程以及oclsomon进程实现,oprocd进程的实现方式非常简单,即调用返回系统时间,如果在规定timeout时间内返回成功则判定系统正常,失败则重启节点。但实际上由于默认情况下的oprocd进程的margin time为500ms,timeout time为1000ms,也就是说如果oprocd进程如果在1.5s内无法得到相应的返回时间的话,就会默认认为操作系统存在问题,从而重启整个节点。对于生产环境来说其实这个timeout时间并不合理,所以Oracle也推荐修改diagwait参数为13,从而调整margin time 为10s。对由oprocd进程以及oclosomon进程发起的集群重启,我们可以在/etc/oracle/oprocd目录下以及$CRS_HOME/log/nodename/cssd/oclsomon目录下找到进程日志。
其实从这里我们也可以发现,为什么不要在集群运行的情况下调整系统时间。对于10g版本来说,由于oprocd进程的功能包含margin参数,也就是时间偏差值,也就说在默认情况下,不停止CRS软件,修改时间超过0.5s就会导致节点重启。所以Oracle官方不推荐在不关闭CRS的情况下修改系统时间,且在使用NTP进行时间同步时,推荐使用slew的同步方式平滑变更时间。11.2及以上版本虽然该机制有所改变,但是也不建议在集群运行时大跨度的修改时间,尤其是超出集群misscount的时间长度。
2.参考文献
Troubleshooting 10g and 11.1 Clusterware Reboots (Doc ID 265769.1)
Troubleshooting Clusterware Node Evictions (Reboots) (Doc ID 1050693.1)
标签:心跳,三种,Oracle,集群,日志,超时,进程,节点 From: https://blog.51cto.com/u_13482808/6454134