集群心跳机制

所谓集群的一致性就是指集群中每个成员能够了解其他成员的状态,而且每个成员获得的集群中其他节点的状态和集群中其他节点成员列表信息(Node Membership)是一致的,这也是集群最基本的要求。Oracle集群管理软件是通过以下一些机制来实现集群一致性的:

机制1:确定节点和节点间的连通性(心跳),以便节点之间能够了解彼此的状态。
机制2:用一(几)个共享的位置来保存节点之间连通性信息,以便在集群需要进行重新配置(节点数量发生改变)时,能够做出正确的决定并记录集群最新的状态。
机制3:本地节点自我监控机制,以便当本地节点出现问题时能够主动离开集群,避免不一致的产生。
 
网络心跳 (Network HeartBeat,简称NHB)
首先是确定集群节点之间的连通性,以便节点之间能够了解彼此的状态,而对于Oracle集群,这是通过节点间的网络心跳来实现的。对于Oracle集群,ocssd.bin守护进程每秒钟向集群的其他节点发送网络心跳(当然是通过集群的私网)。例如:一个4节点的集群,集群的每一个节点每一秒钟都会向集群中的其他三个节点发送网络心跳信息,这也意味着每个节点每一秒钟也会接收到集群中的其他三个节点发送网络心跳。既然节点间互相发送网络心跳,就需要一种机制来确定节点之间的连通性,以及网络心跳出现问题时的处理机制。
网络心跳主要通过以下的 ocssd.bin线程实现:
发送进程(clssnmSendingThread):该线程每秒钟向集群中所有的节点发送网络心跳信息。
分析线程(clssnmPollingThread):该线程会分析接收到的网络心跳信息并进行处理,如果发现集群中的某一个(些)节点持续丢失网络心跳(超过misscount设置),就会通知集群进行重新配置。
集群重新配置线程(clssnmRcfgMgrThread):当clssnmPollingThread发现集群需要进行重新配置时,该进程负责对集群进行重新配置。
派遣进程(clssnmClusterListener):该线程负责接收从远程节点传递过来的信息,之后,根据信息的种类发送给相关的线程进行处理。
 
可以使用  pstack <ocssd.bin pid>   命令获得ocssd.bin的各个线程的名称。
 
发送线程负责每秒钟发送网络心跳到其他远程节点。派遣线程负责接收从远程节点发送过来的网络心跳信息(当然,这个线程也负责接收其他信息),并分发收到的信息给其他相关的线程。分析线程会处理由派遣线程接收大心跳信息,确认节点之间的连通性,当分析线程发现某些节点的连通性出现问题时,例如:连续一段时间内没有发现某一(几)个节点的网络心跳,集群就会进行重新配置(Reconfiguration)。而重新配置的结果往往就是某一(几)个节点离开集群,也就是经常提到的节点驱逐。
集群的重新配置是指集群中的节点成员数量发生了改变以后,为了更新集群节点列表和维持集群一致性而进行的一系列操作。有可能是某一(几)个节点加入集群,也有可能是某一(几)个节点离开集群。因此节点驱逐只是集群重新配置的一种情况。
 
由丢失网络心跳导致的从新配置实际上就是集群之间某些节点之间失去了私网的连通,这并不一定代表着某一个(些)节点真的出了问题。然而,节点间的通信问题的确会破坏集群的一致性,所以是需要处理的,而处理的结果就是某一(几)个节点离开集群。对于10g、11gR1和11.2.0.1版本的集群,这意味着节点重启。而从11.2.0.2开始,由于新特性rebootless restart的引入,对于丢失网络心跳导致的重新配置,只会发生GI重启。
 
由于丢失网络心跳导致的重新配置步骤:
1,当集群的某一个节点连续一段时间(超过集群misscount)丢失网络心跳之后,分析线程决定发起集群重新配置。
2,集群的重新配置管理节点(Reconfiguration Master,以下简称RM节点,这个节点通常是集群中节点号最小的节点)向集群中的所有节点发送重新配置消息。所有收到此消息的节点会回复该消息,并通知RM节点自己的状态。
3,接下来,RM节点基于每个节点的状态进行投票并检查是否有脑裂会发生。
4,对于检查脑裂,RM会查看网络心跳无法访问的节点的磁盘心跳信息,以便确认这个(些)节点的状态。如果发现无法访问的节点状态也是正常的,那么就可能发生脑裂,需要避免。
5,RM节点向表决盘的kill block中写入了”有毒(Poison Package)“的信息,需要重启的节点在访问表决盘时读取到”有毒“信息,完成对本节点的重启。如果RM节点发现某些节点以及离开集群,那么也会进行重新配置。
6,RM节点修改集群节点列表(主要是在表决盘中),重新配置完成。
 
对Oracle集群,脑裂是指集群的某些节点间的网络心跳丢失,但是节点间的磁盘心跳是正常的情况,当脑裂出现后,集群会分裂成为某干个子集群(Corhort)。对于这种情况的出现,集群需要进行重新配置,基本原则是:节点数多的子集群存活,如果子集群包含的节点数相同,那么包含最小编号节点的子集群存活。
 
磁盘心跳(Disk HeartBeat,DHB)
磁盘心跳的主要目的就是当集群脑裂时帮助制定脑裂的解决方案。Oracle集群的每一个节点每秒钟都会向集群的所有表决盘注册本地节点的磁盘心跳信息(也就是说,所有VF中的信息是相同的),同时也会将自己能够联系到的集群中其他节点的信息,或者说本节点认为集群中的成员列表信息写入到表决盘中。一旦发生脑裂,CSS的重新配置线程就可以通过表决盘中的信息了解集群中节点之间的连通性,从而决定集群会分裂成几个子集群,以及每个子集群包含的节点情况和每个节点的状态。
 
磁盘心跳主要通过以下的ocssd.bin线程实现:
磁盘心跳线程(clssnmvDiskPingThread):该线程负责向集群的表决盘中发送磁盘心跳信息。同时,该线程也负责读取表决盘中的kill block信息,以确定本地节点是否需要重新启动。
磁盘心跳监控线程(clssvmnDiskPingMonitorThread):该线程用于确定磁盘心跳线程是否能够正确地发送磁盘心跳,并且能够正确地发送磁盘心跳,并且能够正确地读取kill block中的信息。
kill block线程(clssnmvKillBlockThread):该线程负责监控VF的kill block信息。
 
Oracle规定,如果某个节点在short I/O timeout时间内一直无法访问某一个VF的话,对应的VF会被离线掉,而当大多数的VF([VF数量/2]+1)被离线掉时,该节点会被重新启动。因此配置奇数个VF要好一些,这也是Oracle推荐的配置方法。举个例子:如果配置了3块VF,那么代表需要[3/2]+1=2块VF能够正常工作。如果配置了4块VF,那么代表着需要[4/2]+1=3块VF能够正常工作。因此,我们看到在配置4块VF的情况下浪费了一块盘。Oracle制定这种规定的目的就是为了确保在出现需要通过VF的信息决定节点去留的情况下,至少有一个VF能被集群所有节点访问到。例如:一个两节点的集群(node1和node2)配置了3块VF(VF1、VF2和VF3),node1无法访问VF1,node2无法访问VF2,这意味着两个节点仍然同时能够访问VF3。而当集群中某一个节点无法访问大多数VF时,就意味着当需要通过VF中的信息决定去留的时候,可能会出现没有任何一个VF可被集群中的全部节点访问到的情况,这也意味着无法决定节点去留的时候,可能会出现没有任何一个VF可被集群中的全部节点访问的情况,这也意味着无法决定哪些节点应该离开集群,哪些节点应该被保留。例如:一个两个节点的集群(node1和node2)配置了3块VF(VF1、VF2和VF3),node1无法访问VF1和VF2,node2无法访问VF3,这意味着当出现网络问题时,集群无法通过VF的信息获得一致的所有节点的状态,也就无法完成集群的重新配置。
 
本地心跳(Local HeartBeat,简称LHB)
这种心跳机制是在11gR2版本中被引入的。这种心跳的作用是监控ocssd.bin进程以及本地节点的状态。在10g版本中,Oracle通过oclsomon和oprocd来实现。守护进程oclsomon.bin监控ocssd.bin进程的状态,oprocd.bin进程监控本节点是否出现了性能问题(例如,hang住)。从11.2.0.1版本开始,新的集群cssdagent和cssdmonitor被引入,它们的功能就是监控本地节点的ocssd.bin进程状态和本地节点的状态(是否hang住)。对于ocssd.bin进程的监控,GI是通过本地心跳来实现的,Oracle会在每一秒钟,在发送网络心跳的同时(同一个线程)向cssdagent和cssdmonitor发送本地ocssd.bin进程的状态(也就是本地心跳),如果本地心跳(到底misscount的时间),ocssdagent就会认为本地节点的ocssd.bin进程持续丢失本地心跳(到达misscount的时间),ocssdagent就会认为本地节点的ocssd.bin出现了问题,并重启该节点。oprocd进程同样也被整合到了cssdagent和cssdmonitor中,变成了其中的一个线程,而且监控节点是否hang住的方式也发生了改变,也就是说,对于版本11.2.0.1及以上版本的集群,修改节点的时间基本上不会再导致节点直接重启了,但是,仍然不建议在集群运行时大幅度(修改的幅度不要超过misscount)地修改系统时间。
 
对于10g版本,实际上并没有明确本地心跳的概念,但是实际上oprocd.bin进程从某种意义上来说承担了本地心跳的工作。这个进程存在于10.2.0.4+和11gR1版本中。而且没有安装在第三方集群管理软件的系统上。由于绝大部分的第三方集群管理软件都具有类似oprocd的功能,Oracle也就没有必要的再做重复的工作了。这个进程的目的是监控本地节点是否出现了hang住的情况,所以他由root用户启动,而且优先级级别为实时。该进程每秒钟都会被调用一次,而且设置了500ms的margin time 。换句话说,Oracle在默认情况下要求oprocd进程在1.5s之内被返回。而oprocd进程所做的事情只是返回以下系统时间。如果一个由root用户启动,而且优先级为实时的进程在1.5s之内无法返回系统时间的话,Oracle就会认为本地节点有严重的问题,并重启该节点。也正是以为oprocd进程会返回系统时间并进行相应的验证,Oracle一直推荐客户使用NTP的slew方式来微调系统时间,另外,在修改系统时间(理论上来说大于0.5s)之前,需要首先停止该节点上的CRS软件。
 
另外,在10g版本中还存在着一个oclsomon.bin进程,这个进程的作用是监控ocssd.bin进程的健康性,但是在绝大多数情况下,这个进程对集群的运行并不起多大作用。
 
 
 
 
 
 
 
 
 
 

猜你喜欢

转载自www.cnblogs.com/liang545621/p/9418233.html