11gR2 新特性: Rebootless Restart

众所周知,当集群出现问题时,例如某个节点丢失网络心跳,或者不能够访问表决盘,或者节点出现了严重的性能问题等,CRS会选择将某个节点的OS 重启,以便保证集群的一致性。当然,大部分的重启都是由CRS的核心进程ocssd.bin发起的。 但是,如果CRS 只是节点上的应用之一或者私网和存储的问题只是短时间的出现,那么重启节点的行为就会导致节点上所有的应用全部停止,这在很多系统上并不是我们希望看到的。

所以从版本11.2.0.2 开始,oracle新特性rebootless restart被介绍。当出现以下情况的时候,集群件(GI)会重新启动集群管理软件,而不是将节点重启。
1.当某个节点连续丢失网络心跳超过misscount时。
2.当某个节点不能访问大多数表决盘(VF)时。
3.当member kill 被升级成为node kill的时候。
在之前的版本,以上情况,集群管理软件(CRS)会直接重启节点。

之后,我们通过几个例子了解上面提到的几种情况。
1.当某个节点连续丢失网络心跳超过misscount的情况
2010-08-13 17:00:26.213: [    CSSD][4073040800]clssnmPollingThread: node <nodename> (1) at 50% heartbeat fatal, removal in 14.540 seconds
……
2010-08-13 17:00:33.227: [    CSSD][4073040800]clssnmPollingThread: node <nodename> (1) at 75% heartbeat fatal, removal in 7.470 seconds
……
2010-08-13 17:00:38.236: [    CSSD][4073040800]clssnmPollingThread: node <nodename> (1) at 90% heartbeat fatal, removal in 2.460 seconds, seedhbimpd 1 ?本地节点report 远程节点丢失本地心跳
……
2010-08-13 17:00:40.707: [    CSSD][4052061088](:CSSNM00008: )clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 1 nodes with leader 2, <nodename>, is smaller than cohort of 1 nodes led by node 1, <nodename>, based on map type 2 ? 为了避免split-brain ,本地节点重新启动GI。
2010-08-13 17:00:40.707: [    CSSD][4052061088]###################################
2010-08-13 17:00:40.707: [    CSSD][4052061088]clssscExit: CSSD aborting from thread clssnmRcfgMgrThread 
2010-08-13 17:00:40.707: [    CSSD][4052061088]###################################
2.当某个节点不能访问大多数表决盘(VF)的情况
2010-08-13 18:31:23.782: [    CSSD][150477728]clssnmvDiskOpen: Opening /dev/sdb8
2010-08-13 18:31:23.782: [   SKGFD][150477728]Handle 0xf43fc6c8 from lib :UFS:: for disk :/dev/sdb8:

2010-08-13 18:31:23.782: [    CLSF][150477728]Opened hdl:0xf4365708 for dev:/dev/sdb8:
2010-08-13 18:31:23.787: [   SKGFD][150477728]ERROR: -9(Error 27072, OS Error (Linux Error: 5: Input/output error ? 访问表决盘出错。
Additional information: 4
Additional information: 720913
Additional information: -1)
)
2010-08-13 18:31:23.787: [    CSSD][150477728](:CSSNM00060: )clssnmvReadBlocks: read failed at offset 17 of /dev/sdb8
……
2010-08-13 18:34:38.206: [    CSSD][4110736288](:CSSNM00018: )clssnmvDiskCheck: Aborting, 0 of 1 configured voting disks available, need 1 ?在经过long disk timeout时间之后,GI被重新启动。
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################
2010-08-13 18:34:38.206: [    CSSD][4110736288]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread 
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################

3.member kill 被升级成为node kill的情况。
2013-01-14 23:49:52.093: [    CSSD][45]clssgmmkLocalKillThread: Time up. Timeout 30500 Start time 130388522 End time 130419022 Current time 130419087 ?member kill 超时发生
2013-01-14 23:49:52.093: [    CSSD][45]clssgmmkLocalKillResults: Replying to kill request from remote node 1 kill id 1 Success map 0x00000000 Fail map 0x00000000
……
2013-01-14 23:49:52.235: [    CSSD][31](:CSSNM00005: )clssnmvDiskKillCheck: Aborting, evicted by node <nodename>, number 1, sync 239654498, stamp 130416886 ?该节点被驱逐出集群,也就是重启GI
2013-01-14 23:49:52.235: [    CSSD][31]###################################
2013-01-14 23:49:52.235: [    CSSD][31]clssscExit: CSSD aborting from thread clssnmvKillBlockThread
2013-01-14 23:49:52.235: [    CSSD][31]###################################
2013-01-14 23:49:52.235: [    CSSD][31](:CSSSC00012: )clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally

从上面的输出,我们能看到三种情况中ocssd.bin进程都能够正常地工作,当出现问题时,能过做出正确的决定。所以,rebootless restart能够保证由ocssd.bin主动发起的重启。但是,如果是由于ocssd.bin 出现问题(例如:挂起),或者操作系统性能引起的重启,rebootless restart是无法起作用的,因为,对于这种情况ocssd.bin已经不能正常工作,节点重启仍然不可避免。具体关于如何诊断节点重启的问题,请参考之前的文章 “11gR2 如何诊断节点重启问题”。

GI 在重启集群之前,首先要对集群进行graceful shutdown, 基本的步骤如下。
1.停止本地节点的所有心跳(网络心跳,磁盘心跳和本地心跳)。
2.通知cssd agent,ocssd.bin即将停止
3.停止所有注册到css的具有i/o能力的进程,例如 lmon。
4.cssd通知crsd 停止所有资源,如果crsd不能成功的停止所有的资源,节点重启仍然会发生。
5.Cssd等待所有的具有i/o能力的进程退出,如果这些进程在short i/o timeout时间内不能不能全部推迟,节点重启仍然会发生。
6.通知cssd agent 所有的有i/o能力的进程全部退出。
7.Ohasd 重新启动集群。
8.本地节点通知其他节点进行集群重配置。

综上所述,对于11.2.0.2 及以上版本的集群,如果您发现了节点重启,那么,ocssd.bin 挂���或者操作系统性能的问题应该是首先检查的内容。当然,如果rebootless restart的gracefull shutdown 不能在指定的时间内完成,节点重启仍然会发生,这需要查看ocssd.log进行诊断。

 

原文地址:https://www.cnblogs.com/l10n/p/9418198.html