RAC 的一些概念性和原理性的知识

一集群环境下的一些特殊问题

1.1并发控制

在集群环境中，关键数据通常是共享存放的，比如放在共享磁盘上。而各个节点的对数据有相同的访问权限，这时就必须有某种机制能够控制节点对数据的访问。OracleRAC是利用DLM(DistributeLockManagement)机制来进行多个实例间的并发控制。

1.2健忘症(Amnesia)

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

有一种特殊情况：节点A正常关闭，在节点B上修改配置，关闭结点A，启动结点B。这种情况下，修改的配置文件是丢失的，就是所谓的健忘症。

1.3脑裂(SplitBrain)

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

解决这个问题的通常办法是使用投票算法(QuorumAlgorithm).它的算法机理如下：

集群中各个节点需要心跳机制来通报彼此的"健康状态"，假设每收到一个节点的"通报"代表一票。对于三个节点的集群，正常运行时，每个节点都会有3票。当结点A心跳出现故障但节点A还在运行，这时整个集群就会分裂成2个小的partition。节点A是一个，剩下的2个是一个。这是必须剔除一个partition才能保障集群的健康运行。

对于有3个节点的集群，A心跳出现问题后，B和C是一个partion，有2票，A只有1票。按照投票算法，B和C组成的集群获得控制权，A被剔除。

如果只有2个节点，投票算法就失效了。因为每个节点上都只有1票。这时就需要引入第三个设备：QuorumDevice.QuorumDevice通常采用饿是共享磁盘，这个磁盘也叫作Quorumdisk。这个QuorumDisk也代表一票。当2个结点的心跳出现问题时，2个节点同时去争取QuorumDisk这一票，最早到达的请求被最先满足。故最先获得QuorumDisk的节点就获得2票。另一个节点就会被剔除。

1.4IO隔离(Fencing)

当集群系统出现"脑裂"问题的时候，我们可以通过"投票算法"来解决谁获得集群控制权的问题。但是这样是不够的，我们还必须保证被赶出去的结点不能操作共享数据。这就是IOFencing要解决的问题。

IOFencing实现有硬件和软件2种方式：

软件方式：对于支持SCSIReserve/Release命令的存储设备，可以用SG命令来实现。正常的节点使用SCSIReserve命令"锁住"存储设备，故障节点发现存储设备被锁住后，就知道自己被赶出了集群，也就是说自己出现了异常情况，就要自己进行重启，以恢复到正常状态。这个机制也叫作Sicide(自杀).Sun和Veritas使用的就是这种机制。

硬件方式：STONITH(ShootTheOtherNodeintheHead)，这种方式直接操作电源开关，当一个节点发生故障时，另一个节点如果能侦测到，就会通过串口发出命令，控制故障节点的电源开关，通过暂时断电，而又上电的方式使故障节点被重启动，这种方式需要硬件支持。

二RAC集群

2.1Clusterware

在单机环境下，Oracle是运行在OSKernel之上的。OSKernel负责管理硬件设备，并提供硬件访问接口。Oracle不会直接操作硬件，而是有OSKernel代替它来完成对硬件的调用请求。

在集群环境下，存储设备是共享的。OSKernel的设计都是针对单机的，只能控制单机上多个进程间的访问。如果还依赖OSKernel的服务，就无法保证多个主机间的协调工作。这时就需要引入额外的控制机制，在RAC中，这个机制就是位于Oracle和OSKernel之间的Clusterware，它会在OSKernel之前截获请求，然后和其他结点上的Clusterware协商，最终完成上层的请求。

在Oracle10G之前，RAC所需要的集群件依赖与硬件厂商，比如SUN,HP,Veritas.从Oracle10.1版本中，Oracle推出了自己的集群产品.ClusterReadyService(CRS),从此RAC不在依赖与任何厂商的集群软件。在Oracle10.2版本中，这个产品改名为：OracleClusterware。

所以我们可以看出，在整个RAC集群中，实际上有2个集群环境的存在，一个是由Clusterware软件组成的集群，另一个是由Database组成的集群。

2.2Clusterware组成

OracleCluster是一个单独的安装包，安装后，在每个结点上的OracleClusterware会自动启动。OracleClusterware的运行环境由2个磁盘文件(OCR,VotingDisk)，若干进程和网络元素组成。

2.2.1磁盘文件:

Clusterware在运行期间需要两个文件：OCR和VotingDisk.这2个文件必须存放在共享存储上。OCR用于解决健忘问题，VotingDisk用于解决健忘问题。Oracle建议使用裸设备来存放这2个文件，每个文件创建一个裸设备，每个裸设备分配100M左右的空间就够了。

2.2.1.1OCR

健忘问题是由于每个节点都有配置信息的拷贝，修改节点的配置信息不同步引起的。Oracle采用的解决方法就是把这个配置文件放在共享的存储上，这个文件就是OCRDisk。

OCR中保存整个集群的配置信息，配置信息以"Key-Value"的形式保存其中。在Oracle10g以前，这个文件叫作ServerManageabilityRepository(SRVM).在Oracle10g，这部分内容被重新设计，并重名为OCR.在OracleClusterware安装的过程中，安装程序会提示用户指定OCR位置。并且用户指定的这个位置会被记录在/etc/oracle/ocr.Loc(LinuxSystem)或者/var/opt/oracle/ocr.Loc(SolarisSystem)文件中。而在Oracle9iRAC中，对等的是srvConfig.Loc文件。OracleClusterware在启动时会根据这里面的内容从指定位置读入OCR内容。

1).OCRkey

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

2)OCRprocess

OracleClusterware在OCR中存放集群配置信息，故OCR的内容非常的重要，所有对OCR的操作必须确保OCR内容完整性，所以在ORACLEClusterware运行过程中，并不是所有结点都能操作OCRDisk.

在每个节点的内存中都有一份OCR内容的拷贝，这份拷贝叫作OCRCache。每个结点都有一个OCRProcess来读写OCRCache，但只有一个节点的OCRprocess能读写OCRDisk中的内容，这个节点叫作OCRMaster结点。这个节点的OCRprocess负责更新本地和其他结点的OCRCache内容。

所有需要OCR内容的其他进程，比如OCSSD,EVM等都叫作ClientProcess，这些进程不会直接访问OCRCache，而是像OCRProcess发送请求，借助OCRProcess获得内容，如果想要修改OCR内容，也要由该节点的OCRProcess像Masternode的OCRprocess提交申请，由MasterOCRProcess完成物理读写，并同步所有节点OCRCache中的内容。

2.2.1.2VotingDisk

VotingDisk这个文件主要用于记录节点成员状态，在出现脑裂时，决定那个Partion获得控制权，其他的Partion必须从集群中剔除。在安装Clusterware时也会提示指定这个位置。安装完成后可以通过如下命令来查看VotingDisk位置。

$Crsctlquerycssvotedisk

2.2.2Clusterware后台进程

Clusterware由若干进程组成，其中最重要的3个是：CRSD,CSSD,EVMD.在安装clusterware的最后阶段，会要求在每个节点执行root.sh脚本，这个脚本会在/etc/inittab文件的最后把这3个进程加入启动项，这样以后每次系统启动时，Clusterware也会自动启动，其中EVMD和CRSD两个进程如果出现异常，则系统会自动重启这两个进程，如果是CSSD进程异常，系统会立即重启。

1).OCSSD

OCSSD这个进程是Clusterware最关键的进程，如果这个进程出现异常，会导致系统重启，这个进程提供CSS(ClusterSynchronizationService)服务。CSS服务通过多种心跳机制实时监控集群状态，提供脑裂保护等基础集群服务功能。

CSS服务有2种心跳机制：一种是通过私有网络的NetworkHeartbeat，另一种是通过VotingDisk的DiskHeartbeat.

这2种心跳都有最大延时，对于DiskHeartbeat，这个延时叫作IOT(I/OTimeout);对于NetworkHeartbeat,这个延时叫MC(Misscount)。这2个参数都以秒为单位，缺省时IOT大于MC，在默认情况下，这2个参数是Oracle自动判定的，并且不建议调整。可以通过如下命令来查看参数值：

$crsctlgetcssdisktimeout

$crsctlgetcssmisscount

注：除了Clusterware需要这个进程，在单节点环境中如果使用了ASM，也需要这个进程；这个进程用于支持ASMInstance和RDBMSInstance之间的通信。如果在使用了ASM的节点上安装RAC，会遇到一个问题：RAC节点要求只有一个OCSSD进程，并且应该是运行$CRS_HOME目录下的，这时就需要先停止ASM，并通过$ORACLE_HOME/bin/localcfig.Shdelete删除之前的inittab条目。之前安装ASM时，也使用这个脚本来启动OCSSD：$ORACLE_HOME/bin/localconfig.Shadd.

2).CRSD

CRSD是实现"高可用性(HA)"的主要进程，它提供的服务叫作CRS(ClusterReadyService)服务。

OracleClusterware是位于集群层的组件，它要为应用层资源(CRSResource)提供"高可用性服务"，所以，OracleClusterware必须监控这些资源，并在这些资源运行异常时进行干预，包括关闭，重启进程或者转移服务。CRSD进程提供的就是这些服务。

所有需要高可用性的组件，都会在安装配置的时候，以CRSResource的形式登记到OCR中，而CRSD进程就是根据OCR中的内容，决定监控哪些进程，如何监控，出现问题时又如何解决。也就是说，CRSD进程负责监控CRSResource的运行状态，并要启动，停止，监控，Failover这些资源。默认情况下，CRS会自动尝试重启资源5次，如果还是失败，则放弃尝试。

CRSResource包括GSD(GlobalServeiceDaemon),ONS(OracleNotificationService),VIP,Database,Instance和Service.这些资源被分成2类：

GSD，ONS,VIP和Listener属于Noteapps类

Database，Instance和Service属于Database-RelatedResource类。

我们可以这样理解：Nodeapps就是说每个节点只需要一个就够了，比如每个节点只有一个Listener，而Database-RelatedResource就是说这些资源和数据库有关，不受节点的限制，比如一个节点可以有多个实例，每个实例可以有多个Service。

GSD，ONS,VIP这3个服务是在安装Clusterware的最后，执行VIPCA时创建并登记到OCR中的。而Database，Listener，Instance和Service是在各自的配置过程中自动或者手动登记到OCR中的。

3).EVMD

EVMD这个进程负责发布CRS产生的各种事件(Event).这些Event可以通过2种方式发布给客户：ONS和CalloutScript.用户可以自定义回调脚本，放在特定的目录下，这样当有某些事件发生时，EVMD会自动扫描该目录，并调用用户的脚本，这种调用是通过racgevt进程来完成的。

EVMD进程除了复杂发布事件之外，它还是CRSD和CSSD两个进程之间的桥梁。CRS和CSS两个服务之前的通信就是通过EVMD进程完成的。

4).RACGIMON

RACGIMON这个进程负责检查数据库健康状态，负责Service的启动，停止，故障转移(Failover)。这个进程会建立到数据库的持久连接，定期检查SGA中的特定信息，该信息由PMON进程定时更新。

5).OPROCD

OPROCD这个进程也叫作ProcessMonitorDaemon.如果在非Linux平台上，并且没有使用第三方的集群软件时，就会看到这个进程。这个进程用来检查节点的ProcessorHang(CPU挂起),如果调度时间超过1.5秒，就会认为CPU工作异常，会重启节点。也就是说这个进程提供"IO隔离"的功能。从其在Windows平台上的服务名：OraFnceService也可以看出它的功能。而在Linux平台上，是利用Hangcheck-timer模块来实现"IO隔离"的。

2.3VIP原理和特点

Oracle的TAF就是建立在VIP技术之上的。IP和VIP区别在与：IP是利用TCP层超时，VIP利用的是应用层的立即响应。VIP它是浮动的IP.当一个节点出现问题时会自动的转到另一个节点上。

假设有一个2个节点的RAC，正常运行时每个节点上都有一个VIP。VIP1和VIP2.当节点2发生故障，比如异常关系。RAC会做如下操作：

1).CRS在检测到rac2节点异常后，会触发Clusterware重构，最后把rac2节点剔除集群，由节点1组成新的集群。

2).RAC的Failover机制会把节点2的VIP转移到节点1上，这时节点1的PUBLIC网卡上就有3个IP地址：VIP1,VIP2,PUBLICIP1.

3).用户对VIP2的连接请求会被IP层路由转到节点1

4).因为在节点1上有VIP2的地址，所有数据包会顺利通过路由层，网络层，传输层。

5).但是，节点1上只监听VIP1和publicIP1的两个IP地址。并没有监听VIP2，故应用层没有对应的程序接收这个数据包，这个错误立即被捕获。

6).客户段能够立即接收到这个错误，然后客户段会重新发起向VIP1的连接请求。

VIP特点：

1).VIP是通过VIPCA脚本创建的

2).VIP作为Nodeapps类型的CRSResource注册到OCR中，并由CRS维护状态。

3).VIP会绑定到节点的public网卡上，故public网卡有2个地址。

4).当某个节点发生故障时，CRS会把故障节点的VIP转移到其他节点上。

5).每个节点的Listener会同时监听public网卡上的publicip和VIP

6).客户端的tnsnames.Ora一般会配置指向节点的VIP.

2.4Clusterware的日志体系

OracleClusterware的辅助诊断，只能从log和trace进行。而且它的日志体系比较复杂。

alert.log:

$ORA_CRS_HOME/log/hostname/alert.Log,这是首选的查看文件。

Clusterware后台进程日志：

crsd.Log:$ORA_CRS_HOME/log/hostname/crsd/crsd.Log

ocssd.Log:$ORA_CRS_HOME/log/hostname/cssd/ocsd.Log

evmd.Log:$ORA_CRS_HOME/log/hostname/evmd/evmd.Log

Nodeapp日志位置：

$ORA_CRS_HOME/log/hostname/racg/

这里面放的是nodeapp的日志，包括ONS和VIP，比如：ora.Rac1.ons.Log

工具执行日志：

$ORA_CRS_HOME/log/hostname/client/

Clusterware提供了许多命令行工具：

比如ocrcheck,ocrconfig,ocrdump,oifcfg和clscfg,这些工具产生的日志就放在这个目录下

还有$ORACLE_HOME/log/hostname/client/和

$ORACLE_HOME/log/hostname/racg也有相关的日志。

注：本片文章整理子张晓明的《大话OracleRAC》

<!--EndFragment-->