Oracle RAC CSS提供2种后台服务包括群组管理(Group Managment简称GM)和节点监控(Node Monitor简称NM)，其中GM管理组(group)和锁(lock)服务。在集群中任意时刻总有一个节点会充当GM主控节点(master node)。集群中的其他节点串行地将GM请求发送到主控节点(master node)，而master node将集群成员变更信息广播给集群中的其他节点。组成员关系(group membership)在每次发生集群重置(cluster reconfiguration)时发生同步。每一个节点独立地诠释集群成员变化信息。
而节点监控NM服务则负责通过skgxn(skgxn-libskgxn.a，提供节点监控的库)与其他厂商的集群软件保持节点信息的一致性。此外NM还提供对我们熟知的网络心跳(Network heartbeat)和磁盘心跳(Disk heartbeat)的维护以保证节点始终存活着。当集群成员没有正常Network heartbeat或Disk heartbeat时NM负责将成员踢出集群，被踢出集群的节点将发生节点重启(reboot)。
NM服务通过OCR中的记录(OCR中记录了Interconnect的信息)来了解其所需要监听和交互的端点，将心跳信息通过网络发送到其他集群成员。同时它也监控来自所有其他集群成员的网络心跳Network heartbeat，每一秒钟都会发生这样的网络心跳，若某个节点的网络心跳在misscount(by the way:10.2.0.1中Linux上默认misscount为60s，其他平台为30s，若使用了第三方vendor clusterware则为600s，但10.2.0.1中未引入disktimeout；10.2.0.4以后misscount为60s,disktimeout为200s；11.2以后misscount为30s:CRS-4678: Successful get misscount 30 for Cluster Synchronization Services,CRS-4678: Successful get disktimeout 200 for Cluster Synchronization Services)指定的秒数中都没有被收到的话，该节点被认为已经”死亡”了。NM还负责当其他节点加入或离开集群时初始化集群的重置(Initiates cluster reconfiguration)。
在解决脑裂的场景中，NM还会监控voting disk以了解其他的竞争子集群(subclusters)。关于子集群我们有必要介绍一下，试想我们的环境中存在大量的节点，以Oracle官方构建过的128个节点的环境为我们的想象空间，当网络故障发生时存在多种的可能性，一种可能性是全局的网络失败，即128个节点中每个节点都不能互相发生网络心跳，此时会产生多达128个的信息”孤岛”子集群。另一种可能性是局部的网络失败，128个节点中被分成多个部分，每个部分中包含多于一个的节点，这些部分就可以被称作子集群(subclusters)。当出现网络故障时子集群内部的多个节点仍能互相通信传输投票信息(vote mesg),但子集群或者孤岛节点之间已经无法通过常规的Interconnect网络交流了，这个时候NM Reconfiguration就需要用到voting disk投票磁盘。
因为NM要使用voting disk来解决因为网络故障造成的通信障碍，所以需要保证voting disk在任意时刻都可以被正常访问。在正常状态下，每个节点都会进行磁盘心跳活动，具体来说就是会到投票磁盘的某个块上写入disk心跳信息，这种活动每一秒钟都会发生，同时CSS还会每秒读取一种称作”kill block”的”赐死块”，当”kill block”的内容表示本节点被驱逐出集群时，CSS会主动重启节点。
为了保证以上的磁盘心跳和读取”kill block”的活动始终正常运作CSS要求保证至少(N/2+1)个投票磁盘要被节点正常访问，这样就保证了每2个节点间总是至少有一个投票磁盘是它们都可以正常访问的，在正常情况下(注意是风平浪静的正常情况)只要节点所能访问的在线voting disk多于无法访问的voting disk，该节点都能幸福地活下去，当无法访问的voting disk多于正常的voting disk时，Cluster Communication Service进程将失败并引起节点重启。所以有一种说法认为voting disk只要有2个足以保证冗余度就可以了，没有必要有3个或以上voting disk，这种说法是错误的。Oracle推荐集群中至少要有3个voting disks。
补充1：
Question:
有同学问那么voting disk  必须是奇数个呢？
Answer:
实际上我们仅仅是推荐使用奇数个vote disk ，而非必须是奇数个。10gR2中vote disk的数目上限是32个。
Question
我们可以使用2或4个vote disk吗？
Answer:
可以的。 但是2、4这样的数目在“至少(N/2+1)个投票磁盘要被节点正常访问”这一disk heartbeat的硬性算法下是不利的：
当我们使用2个vote disk 时，不能发生任意个vote disk的心跳失败
当我们使用3个vote disk 时，不能发生大于1个的vote disk心跳失败
当我们使用4个vote disk 时，不能发生大于1个的vote disk心跳失败 ，这和3个时的容错率是一样，但是因为我们有更多的vote disk，这会导致管理成本和引入的风险增长
当我们使用5个vote disk 时，不能发生大于2个的vote disk心跳失败
当我们使用6个vote disk 时，仍然不能发生大于2个的vote disk心跳失败， 同样的因为比5时多出一个 ，也会引入不合理的管理成本和风险
补充2：
Question:
若节点间的网络心跳正常，且节点所能正常心跳的vote disk 大于 不能正常访问的 ，如3个votedisk 时 恰巧有1个vote disk 的disk heartbeat 超时，此时Brain split 会发生吗？
Answer:
这种情况即不会触发Brain Split，也不会引发节点驱逐协议(eviction protocol)。 当单个或小于(N/2+1)个的voting disk心跳失败(disk heartbeat failure)时，这种心跳失败可能是由于短期内节点访问voting disk发生I/O error错误而引起的，此时css会立刻将这些失败的voting disk标记为OFFLINE。虽然有一定数量的voting disk OFFLINE了，但是我们仍有至少(N/2+1)个投票磁盘可用，这保证了eviction protocol不会被调用，所以没有节点会被reboot重启。紧接着node monitor模块的Disk ping Monitor Thread(DPMT-clssnmDiskPMT)会重复尝试访问这些失败的OFFLINE voting disk，若这些投票磁盘变得再次可I/O访问且经过验证其上的数据也没有讹误，那么css会再次将此voting disk标记为ONLINE；但是如果在45s( 这里的45s是基于misscount和 内部算法获得的) 内仍不能正常访问相关的voting disk，那么DMPT将在cssd.log中生成警告信息

    

连铸服务器异常，是因为该服务器的的节点出错（ＲＡＣ下面介绍），节点出错主要为２个方面１；为裂脑现象 ２节点失去半数以上vote disk连接导致节点出错；  
１脑裂原因：
服务器无法连接，ORA报警：SELECT A.OWNER,  A.OBJECT_NAME,  B.SESSION_ID, 
B.ORACLE_USERNAME,  B.OS_USER_NAME,  B.PROCESS, 
B.LOCKED_MODE,  C.SID, 
C.SERIAL#,  C.PROGRAM 
FROM ALL_OBJECTS A,  V$LOCKED_OBJECT B,  SYS.GV_$SESSION C 
WHERE ( A.OBJECT_ID = B.OBJECT_ID )  AND (B.PROCESS = C.PROCESS ) 
AND A.OBJECT_NAME='TAB_NAME';  
然后杀掉这个线程。 
alter system kill session 'sid,serial#' immediate; 
 该问题主要由另一个ORA-03135引起,主要原因为最近局里网络不稳定,如集群中任一主机PUBLIC端口断掉会导致与之绑定的VIP消失,造成假DOWN情况称为裂脑;
裂脑现象：.是由于集群中的节点之间无法正常通讯而导致的集群中出现的不一致的现象 
如果出现这种情况，Oracle RAC会终止一个节点，来保证集群的一致性．裂脑产生后终止实例原则是根据裂脑现象残生的子集群进行投票选择终止的节点，投票规则节点数少终止，一致时node ID小的节点存活． 节点：（real application clusters简称ＲＡＣ）简单说就是ＯＲＡ提供一个简单应用平台（ＢＢＳ性质一样吧），支持所有类型的应用系统，无论是事务处理型应用还是分析型应用。所有应用共享同样的服务器和存储资源。出现任何的服务器 或磁盘故障，系统会自动重新接管发生故障的功能。 集群：集群是一些相互独立的计算机，这些计算机作为一个整体对外提供服务．连铸为列．ＤＢ１和ＤＢ２和磁盘阵列构成集群（通过软件），想ＡＰＰ提供数据服务．
上诉可以看出裂脑现象可以导致服务起崩溃（线程被杀），导致裂脑主要是多个节点数据不同步，上诉网络不稳定为一个原因．
还有节点的buffer cache不一致，当需要ＣＡＣＨＥ同步操作时会出现裂脑现象，同时服务器无法启动，现象：双节点RAC数 据库，只能启动一个节点，无论哪个节点先启动，另外一个节点就无法正常启动了！，无法启动的表现就是可以mount，alter database open就hang在那不动，没有任何报错信息，只有后台进程QMNC进程无法启动，重新启动的信息，还有MMNL absent for 1474 secs; Foregrounds taking over的信息给出．