什么是集群 　

集群（Cluster）是由两台或多台节点机（服务器）构成的一种松散耦合的计算节点集合，为用户提供网络服务或应 用程序(包括数据库、Web服务和文件服务等)的单一客户视图。集群系统一般通过两台或多台节点服务器系统通过相应的硬件及软件互连，每个群集节点都是运 行其自己进程的独立服务器。这些进程可以彼此通信，对网络客户机来说就像是形成了一个单一系统，协同起来向用户提供应用程序、系统资源和数据。除了作为单 一系统提供服务，集群系统还具有恢复服务器级故障的能力。集群系统还可通过在集群中继续增加服务器的方式，从内部增加服务器的处理能力，并通过系统级的冗 余提供固有的可靠性和可用性。

集群的分类：

1、高性能计算集群：

高性能计算集群采用将计算任务分配到不同节点来提高整体计算能力主要应用在科学计算领域。

2、负载均衡集群LB：

负载均衡集群为企业需求提供更实用的系统。该系统使各节点的负载流量可以在服务器集群中尽可能平均合理地分摊处理。 该负载需要均衡计算的应用程序处理端口负载或网络流量负载。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以 在节点之间动态分配负载，以实现平衡。对于网络流量也如此。通常，网络服务器应用程序接受了大量入网流量，无法迅速处理，这就需要将流量发送给在其它节 点。负载均衡算法还可以根据每个节点不同的可用资源或网络的特殊环境来进行优化。

3、高可用性集群HA：

为保证集群整体服务的高可用，考虑计算硬件和软件的容错性。如果高可用性群集中的某个节点发生了故障，那么将由另外的节点代替它。整个系统环境对于用户是一致的。

实际应用中HA与LB经常是同时具备,ORACLE RAC就同时具备HA和LB。

集群环境的特殊问题

1、并发控制

在集群环境中，关键数据都必须是共享存放的 。各个节点都对数据有平等的访问权利 。因此必须要有某种机制控制节点对 数据的访问。

2、健忘症 Amnesia 

在特殊的情况下比如：两个节点的集群，节点1因为正常维护需 要关闭，然后在节点2修改了某些配置，然后关闭节点2，启动节点1。因为在节点2修改的配置内容没有同步到节点1，所以节点1启动后，它仍然是用旧的配置 文件工作，这时就会造成配置丢失，也就是所谓的“健忘症“ 。

这个问题发生在集群环境配置文件不是集中存放，而是每个节点都有一个本地副本。在集群正常运行时，用户可以在任务节点更改集群的配置，并且更改会自动同步到其它节点。

3、脑裂Split Brain

在集群里，节点间需要通过心跳机制了解彼此的健康状况，以确保各节点协调工作。假设只是“心跳”出现故障，但各个节 点还在正常运行 。这时每个节点都认为其它节点宕机，自己是集群中唯一健在者，自己应该获得整个集群的控制权。在集群环境里，存储设备是共享的，这就意味着数据灾难，这种 状况就是“脑裂”。

解决这个问题的算法通常就是投票算法。集群中各节点通过心跳来通报彼此的健康状况，假设每收到一个节点的通报代表 一票。对于一个三节点的集群，正常运行时 每个节点都会有3票。假设节点1 的心跳出现故障，但是节点1还在运行：这时整个集群就分裂成二个小的partition。节点1自己一个partition，节点2和节点3是一个 partition。 这就必须剔除一个partition。这时节点2和节点3所在的partition 每个节点有二票，节点1只有一票。所以节点2和节点3组成的小集群获得控制权，节点1被踢出。

如果集群只有二个节点，上面的算法就没用了，此时子集群内数目相等，则拥有最低节点号的子集群(Sub-cluster with lowest node number)将获得控制权，即总是1号节点会获胜。
关于节点间的脑裂问题，可参见笔者的如下文章

http://czmmiao.iteye.com/blog/1577531

4、IO 隔离 IO Fencing

这个问题是上一个问题的延伸。当集群系统出现脑裂时，必须判断那些节点获得控制权，那些节点要踢出集群。但这样还不够，还必须保证被赶出集群的节点不能操作共享数据。这就是IO隔离要解决的问题。

IO Fencing的实现有硬件方式和软件方式。对于支持SCSI Reserve/Release命令的存储设备，可以用SG命令实现。正常节点使用SCSI Reserve命令“锁住”存储设备，故障节点发现存储设备被锁住后，就知道自己已经被赶出了集群，就会自行重启，以恢复正常工作，这种机制叫 suicide。Sun和Veritas使用的是这种机制。
利用STONITH是另一种方式，这种方式直接操作电源开关。当一个节点发送故障时，另一个节点如果能侦测到，就会通过串行口发出命令，控制故障节点的电源开关，通过暂时断电而后又加上点的方式使得故障节点被重启。这种方式需要硬件支持。

ORACLE RAC采用的是软件方式，直接重启故障节点。无论采用哪种方式，IO Fencing目的都是相同的，为了保证故障节点不能再继续访问数据。

集群软件 

集群层由各个节点上的集群软件组成，集群软件在集群环境的作用和地位与OS Kernel在单机系统中的地位和作用是一样的。在单机系统中，硬件资源是由OS Kernel管理的，应用软件是不能访问硬件的，必须通过OS Kernel提供的API接口间接访问。OS Kernel除了要完成用户请求，还要通过进程调度等机制来控制每台主机多进程对资源的使用。但是到了集群环境，硬件尤其是存储设备是共享使用的，不仅需 要协调每台主机内多进程的共享使用，还需要协调主机间进程的共享使用。这种需要传统的OS Kernel就无法满足了，这就需要集群软件的介入。

ORACLE Clusterware有以下几个组件

1、OCR(Oracle Cluster Registry)

负责维护整个集群的配置信息，包括RAC以及Clusterware资源，包括的信息有节点成员、数据库、实例、服务、监听器、应用程序等。

为了解决集群“健忘”的问题,最简单的解决办法就是整个集群只有一份配置，所有节点共用这份配置。ORACLE采用 的方法就是把这个配置文件放在共享存储上，这个文件就是OCR DISK。 节点通过OCR Process读写OCR。 但只有一个节点能够读写OCR DISK 叫OCR Master节点，其它节点通过本节点的OCR process 向master node的OCR process提交请求，由master OCR Process完成物理读写，并同步所有节点OCR cache中的内容。就OCR而言，每个集群都会有一个Master节点，这个节点一半来说是集群中生存时间最长的那个节点(生存时间最长也就意味着该节 点越稳定)。

我们在安装Clusterware的在选择OCR的存储位置时，如果选择"Normal Redundancy"，则会存储两份相互镜像的OCR。如果选择"External Redundancy"则表明存储本身已经坐了冗余配置，不需要创建镜像OCR。该位置会记录在/etc/oracle/ocr.loc(Linux)或 /var/opt/oracle/ocr.loc(Solaris)中。

OCR key:整个OCR 的信息是树形结构，有3个大分支。分别是SYSTEM,DATABASE 和CRS。每个分支下面又有许多小分支。这些记录的信息只能由root用户修改。

2、Voting Disk 这个文件也要放在共享存储上，主要用于管理集群的节点成员身份，根据这里的记录判断哪些节点是集群的成员。并在出现脑裂时，仲裁哪个Partition获得集群的控制权。关于Voting Disk的跟多资料可以参见笔者的如下文章:
http://czmmiao.iteye.com/blog/1577531

集群架构如下

Clusterware后台进程 
Clusterware 由若干进程组成，其中最重要的3个是：CRSD,CSSD,EVMD. 在安装clusterware的最后阶段，会要求在每个节点执行root.sh 脚本， 这个脚本会在/etc/inittab 文件的最后把这3个进程加入启动项，这样以后每次系统启动时，Clusterware 也会自动启动，其中EVMD和CRSD 两个进程如果出现异常，则系统会自动重启这两个进程，如果是CSSD 进程异常，系统会立即重启。
OCSSD 
OCSSD 这个进程是Clusterware最关键的进程，如果这个进程出现异常，会导致系统重启，这个进程提供CSS(Cluster Synchronization Service)服务。 CSS 服务通过多种心跳机制实时监控集群状态，提供脑裂保护等基础集群服务功能。
CSS 服务有2种心跳机制： 一种是通过私有网络的Network Heartbeat，另一种是通过Voting Disk的Disk Heartbeat.
这2种心跳都有最大延时，对于Disk Heartbeat， 这个延时叫作IOT (I/O Timeout);对于Network Heartbeat, 这个延时叫MC(Misscount)。 这2个参数都以秒为单位，缺省时IOT大于MC，在默认情况下，这2个参数是Oracle 自动判定的，并且不建议调整。可以通过如下命令来查看参数值：
$crsctl get css disktimeout
$crsctl get css misscount 
注：除了Clusterware 需要这个进程，在单节点环境中如果使用了ASM，也需要这个进程；这个进程用于支持ASM Instance 和RDBMS Instance之间的通信。 如果在使用了ASM的节点上安装RAC，会遇到一个问题：RAC节点要求只有一个OCSSD进程，并且应该是运行$CRS_HOME目录下的，这时就需要先停止ASM，并通过$ORACLE_HOME/bin/localcfig.Sh delete 删除之前的inittab 条目。之前安装ASM时，也使用这个脚本来启动OCSSD：

$ORACLE_HOME/bin/localconfig.Sh add. 
CRSD 
CRSD是实现"高可用性(HA)"的主要进程，它提供的服务叫作CRS(Cluster Ready Service) 服务。
Oracle Clusterware是位于集群层的组件，它要为应用层资源(CRS Resource) 提供"高可用性服务"，所以， Oracle Clusterware 必须监控这些资源，并在这些资源运行异常时进行干预，包括关闭，重启进程或者转移服务。CRSD进程提供的就是这些服务。
所有需要 高可用性 的组件，都会在安装配置的时候，以CRS Resource的形式登记到OCR中，而CRSD 进程就是根据OCR中的内容，决定监控哪些进程，如何监控，出现问题时又如何解决。也就是说，CRSD 进程负责监控CRS Resource 的运行状态，并要启动，停止，监控，Failover这些资源。 默认情况下，CRS 会自动尝试重启资源5次，如果还是失败，则放弃尝试。
CRS Resource 包括GSD(Global Serveice Daemon),ONS(Oracle Notification Service),VIP, Database, Instance 和 Service. 这些资源被分成2类：
GSD，ONS,VIP 和 Listener 属于Noteapps类
Database，Instance 和Service 属于 Database-Related Resource 类。
我们可以这样理解： Nodeapps 就是说每个节点只需要一个就够了，比如每个节点只有一个Listener，而Database-Related Resource 就是说这些资源和数据库有关，不受节点的限制，比如一个节点可以有多个实例，每个实例可以有多个Service。
GSD，ONS,VIP 这3个服务是在安装Clusterware的最后，执行VIPCA 时创建并登记到OCR中的。 而Database， Listener， Instance 和Service 是在各自的配置过程中自动或者手动登记到OCR中的。
EVMD 
EVMD 这个进程负责发布CRS 产生的各种事件(Event). 这些Event可以通过2种方式发布给客户：ONS 和 Callout Script. 用户可以自定义回调脚本，放在特定的目录下，这样当有某些事件发生时，EVMD会自动扫描该目录，并调用用户的脚本，这种调用是通过racgevt进程来完成的。
EVMD 进程除了复杂发布事件之外，它还是CRSD 和CSSD 两个进程之间的桥梁。 CRS 和CSS 两个服务之前的通信就是通过EVMD 进程完成的。
RACGIMON 
RACGIMON 这个进程负责检查数据库健康状态，负责Service的启动，停止，故障转移(Failover)。 这个进程会建立到数据库的持久连接，定期检查SGA中的特定信息，该信息由PMON 进程定时更新。
OPROCD 
OPROCD 这个进程也叫作 Process Monitor Daemon. 如果在非Linux 平台上，并且没有使用第三方的集群软件时，就会看到这个进程。 这个进程用来检查节点的Processor Hang(CPU 挂起), 如果调度时间超过1.5秒， 就会认为CPU 工作异常，会重启节点。 也就是说这个进程提供 "IO 隔离" 的功能。 从其在Windows 平台上的服务名： OraFnceService 也可以看出它的功能。 而在Linux 平台上， 是利用Hangcheck-timer 模块来实现"IO 隔离"的。

 

参考至:《大话Oracle RAC》张晓明著
              http://blog.csdn.net/java3344520/article/details/6251237
             http://hi.baidu.com/%CC%D8%B0%AE%C0%B6%C1%AB%BB%A8/blog/item/6ada7a367587d81bbaa167fb.html

本文原创，转载请注明出处、作者

如有错误，欢迎指正

邮箱:czmcj@163.com