导致集群重启_Oracle clusterware集群心跳简介

在oracle clusterware中，会存在3种心跳：

网络心跳--NHB

能够最直接的体现节点的存活情况，主要用于发送集群中各节点的状态信息，节点会将自身状态信息向其他节点进行广播，并接收其他节点的心跳信息，心跳间隔为1s，默认超时时间为30s。11.2及以上版本集群中使用UDP协议。

磁盘心跳--DHB

主要用于集群的脑裂决策及用于网络心跳故障时判断节点的存活情况，节点会将自身信息及当前的时间戳信息写入voting disk，并读取其他节点的心跳信息，心跳间隔为1s。默认情况下，用于cluster reconfiguration时，超时时间为27s，其他大部分时候为200s，小部分情况下使用一些特殊时限。

本地心跳--LHB

严格的说，集群中还有一个本地心跳，用于cssd进程与cssdmonitor和cssdagent进程之间的内部通信，以确认cssd进程是否工作正常，心跳间隔为1s。很少有资料提及这种类型的心跳，也很少在日志中"高调现身"。

下面，我们通过一个小实验，简单看一下网络心跳故障场景下，网络心跳和磁盘心跳的工作情况，并引出不常见的本地心跳进行一次观察。

------- START -------

cssd默认的日志级别不会输出正常情况下网络心跳的工作情况，如果想进行观察，可以使用命令：

crsctl set log css "CSSD:3"

提高日志级别来进行观察。提高日志级别后，我们可以在ocssd.log日志中观察到以下输出：

我们可以看到，日志输出了当前的网络心跳misstime。如果在日志级别3下进行网络心跳丢失的测试，可以清晰的看到misstime不断增大的情况。

但是日志级别3日志量增大很多，而且默认的日志级别2已能够满足日常的问题定位，我们在日志级别2下进行实验，日志级别3下的输出有兴趣的同学可自行测试。

实验环境

OS : Oracle Linux 6

GI : 11.2.0.4.0 双节点

使节点2操作系统陷入hang，随后断开两节点私网连接。

大约15s后，节点1 ocssd.log中开始出现我们熟悉的日志：

节点1发现节点2网络心跳丢失，但依然存在磁盘心跳，节点1开始出现节点2网络心跳丢失告警。节点1依然不断的在将自身的状态信息广播至其他节点。

达到网络心跳超时时间，将节点2标记为removal(此时网络不可达)。

节点1从磁盘心跳确认节点2依然存活，为避免发生脑裂，将节点2驱逐。

节点1开始驱逐节点2，并开始检查节点2磁盘心跳，以确认节点2是否被成功驱逐并完成重启。

虽然与本次分享无关，但还是截出了一段有意思的日志，cssd的日志很清晰的显示，节点1 cssd进程向VD中写入kill block，节点2 cssd读取到此block后将会"自杀"。

从节点2的日志中，也可以看到节点2的cssd进程接收到了节点1的kill信息，开始终止cssd进程。

节点1不断检查节点2的磁盘心跳，以确认节点2是否被成功驱逐并完成重启。因为我们需要引出本地心跳而做的特殊处理(使节点2主机hang)，在磁盘心跳1466174599, 487814, 543出现后，节点2的磁盘心跳信息未再发生改变，可以猜测，节点2的cssd进程未重启。持续30s未改变后，节点1判断节点2丢失了磁盘心跳，认为节点2已经down，开始reconfig工作。

而此时，发现节点2主机发生了重启。

查看节点2 oracssdagent_root.log可以发现以下日志：

日志太长，文本贴出一条完整的如下：

2016-06-25 22:43:40.934: [ USRTHRD][2222589696] (:CLSN00111:)clsnproc_needreboot: Impending reboot at 75% of limit 28500; disk timeout 28110, network timeout 28500, last heartbeat from CSSD at epoch seconds 1466174599.467, 21471 milliseconds ago based on invariant clock 487703; now polling at 100 ms

本地心跳丢失，cssdagent在本地心跳超时后重启节点(主机)。

根据上面的日志信息及超时百分比和相应时间估算，估计本地心跳超时时间为28s左右。

整个实验的过程可以总结为：

两节点间私网通信中断，导致网络心跳丢失，节点1在网络心跳超时后，将节点2驱逐，正常情况下，节点2 cssd会发生重启，进而导致节点2集群软件重启，但因节点2主机hang，cssd进程无法及时完成重启，造成cssdagent进程认为cssd进程工作异常而进行节点(主机)重启。从实验中，我们可以看到各类心跳的工作。

-------- END --------

对于集群心跳丢失问题的基本核查：

网络心跳问题。

最常见，但涉及面太广，也最复杂。网络心跳问题主要会集中在几个方面：

1. 首先要提的是，集群中一个节点日志中出现网络心跳问题日志输出，不能说明一定存在网络心跳问题，进而导致节点驱逐。需要结合存活节点及被驱逐节点的集群日志进行分析，如果被驱逐节点在存活节点出现网络心跳问题前已"死亡"，那么存活节点的网络心跳问题日志输出及随后的reconfig也只是例行公事，节点2的"死亡"与节点1并没有关系，需要核查节点2自身为何"死亡"；

2. 网络问题。例如网络设备问题如设备故障、性能问题、配置问题，防火墙，主机设备问题如网卡故障，操作系统配置问题如UDP缓冲区配置等。特别说明的是，因为网络心跳使用的是UDP协议，排查网络问题时除了连通性，还需要关注UDP的通信质量；

3. 主机问题。例如主机CPU高消耗，其他性能问题，平台相关的参数未配置，操作系统缺少必要补丁等；

磁盘心跳问题。

相对少见，常见的原因有存储问题，主机性能问题，操作系统缺少必要补丁等。

以上两种心跳问题不会引发节点重启(11.2.0.2版本开始，受rebootless restart特性影响)。

本地心跳问题。

这个无法讨论，但我们可以知道，cssdagent或cssdmonitor进程引发节点(主机)重启的主要因素为主机问题如CPU高消耗、主机性能问题、平台相关参数未配置或其他一些因素导致cssd线程hang。

当然，每一种心跳问题都还可能因bug而导致异常。

我的分享结束，谢谢各位！

题外话，11.2.0.2版本开始，集群已不会轻易重启节点主机。如果发现节点重启，并从主机或集群日志中发现重启为cssdagent或cssdmonitor触发，首先需要核查的是主机问题，而不是集群自身。

2016-06-26 17:13:47.236: [ CSSD][3248703232]clssnmCheckKillStatus: Node 2, rac-node2, down, due to observed lack of DHBs, LATS 3229224, current time 3289294

2016-06-26 17:13:47.236: [ CSSD][3248703232]clssnmCheckKillStatus: Node 2, rac-node2, down, LATS(3229224),timeout(60070)

2016-06-26 17:00:48.046: [ CSSD][3248703232]clssnmCheckKillStatus: Node 2, rac-node2, down, due to successful termination

2016-06-26 17:00:48.046: [ CSSD][3248703232]clssnmCheckKillStatus: Node 2, rac-node2, down, LATS(2510104),timeout(0)

2016-06-26 17:07:28.026: [ CSSD][3248703232]clssnmCheckKillStatus: Node 2, rac-node2, down, due to timeout of DHB; last NHB TOD invariant clock 2795154, TOD invariant clock 2795754

2016-06-26 17:07:28.026: [ CSSD][3248703232]clssnmCheckKillStatus: Node 2, rac-node2, down, LATS(2880764),timeout(29320)