RAC的一些概念和原理性知识多方总结【1】

对于RAC来说，最重要的还是要理解内部原理和体系结构。安装不是非常难的事情。重要的还是体系结构以及内部原理，排错和维护都离不开它们。

实例概念：一组进程和对应的数据结构

数据库是一个容器，实例相当于从容器里提取数据的手

单实例：一台机器上一个库只能对应一个实例

Rac：一个库可以对应多个实例，并行。

每个实例运行在一个物理机器上，可以负载均衡，发生故障可以有状态切换。

需要能让多个机器同时读写的共享磁盘，可以由操作系统提供（AIX concurrent vg,Linux GPFS,）但concurrent vg是操作系统的双机软件中的组件所以必须安装ha软件。可以用oracle的ASM。crs为oracle的集群软件，提供ip切换等集群功能。

ASM功能类似LVM为os提供存储管理功能，但是是不可管理，把lun划给即可。

集群分类

1、高性能计算

计算任务分配到不同计算机节点来提高整体计算能力，主要应用在科学计算领域。主要利用的是并行计算。

2、负载均衡集群（LB）

  把业务的负载流量尽可能的平均合理的分配到集群的各个节点上，每个节点都可以处理一部分负载，并且可以根据负载情况进行动态的平衡。负载均衡算法不是简单的平均，而是根据每个节点的可用资源或网络的特殊情况来进行优化分配。因此分配+合理才是负载均衡的核心。

3、高可用性（HA）

  侧重于提高系统的可用性，集成硬件和软件的容错性来实现整体服务的高可用性。如果某个节点发生故障，另外的节点代替他。

RAC是真正的LB和HA的复合体。从某种意义上说，只有最终应用（数据库）才能实现真正意义上的LB，而绝大多数的集群都是HA。

一、集群环境的特殊问题

1.1、并发控制

集群环境中，存在共享存储的问题。集群中各个节点对共享存储是对等的，所有节点对数据有相同的访问权限，因此需要某种机制来控制节点对数据的访问。

在RAC中，采用的是DLM（Distribute Lock Management）机制来进行实例间的并发控制。

1.2、健忘症（Amnesia）

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

如果节点1因为正常的维护需要关机，节点2修改了配置，然后关闭节点2.启动节点1，因为之前节点2做的配置修改没有同步到节点1，所以将节点1启动以后，他仍然使用旧的配置文件，造成配置丢失。

1.3、脑裂（split brain）

集群中，节点之间需要通过某种机制（心跳）了解彼此的健康情况，以确保各个节点协调工作。假设只是心跳出现故障，各个节点还在正常的工作，每个节点都认为其他节点宕机，自己是整个集群的唯一健在者，因此需要获得整个集群的“控制权”。存储是共享的，这就意味着灾难，这种情况就是“脑裂”。

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

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

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

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

1.4、IO隔离（IO Fencing）、

集群出现故障，必须判断哪个节点应该获得集群的控制权，哪个节点需要被踢出。这是投票需要解决的问题。

仅仅将他们踢出还不足够，因为他们可能还在继续运行（只是离开了这个集群），需要保证他们不再访问共享数据。这就是IO隔离要解决的问题。

IO Fencing实现有硬件和软件方式。各个集群厂商使用的方式不同，有些需要硬件的支持（主要是存储设备是否支持某些协议）。Oracle RAC使用的是软件的方式，直接重启故障节点。

无论采用哪种方式，IO Fencing的目的就是保证故障节点不能继续访问共享数据。

有一些存储设备支持SCSI Reserve/Release命令，正常节点使用SCSI Reserve命令锁住存储设备，故障节点发现存储被锁定，就知道自己已经被踢出了cluster，自行重启，这种机制叫做自杀机制（suicide）。例如Sun和Veritas的集群使用的就是这种机制。

无论软件还是硬件，大致原理就是：正常节点通过某种方式告知故障节点，故障节点会进行重启。告知的方式有硬件和软件之分，硬件更加安全一些。

二、RAC 集群

2.1、Clusterware

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

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

在Oracle 10G之前，RAC所需要的集群件依赖与硬件厂商，比如SUN,HP,Veritas. 从Oracle 10.1版本中，Oracle 推出了自己的集群产品。Cluster Ready Service(CRS),从此RAC 不在依赖与任何厂商的集群软件。在Oracle 10.2版本中，这个产品改名为：Oracle Clusterware.

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

2.2 Clusterware 组成

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

2.2.1 磁盘文件:

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

2.2.1.1 OCR

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

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

1). OCR key

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

2) OCR process

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

在每个节点的内存中都有一份OCR内容的拷贝，这份拷贝叫作OCR Cache。每个结点都有一个OCR Process来读写OCR Cache，但只有一个节点的OCR process能读写OCR Disk中的内容，这个节点叫作OCR Master结点。这个节点的OCR process负责更新本地和其他结点的OCR Cache内容。

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

2.2.1.2 Voting Disk

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

$Crsctl query css votedisk

2.2.2 Clusterware 后台进程

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

1) 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.

2) CRSD

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

Oracle Clusterware是位于集群层的组件，它要为应用层资源(CRS Resource) 提供"高可用(HA) "，所以，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中的。

3) EVMD

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

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

4) RACGIMON

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

未完待续

RAC的一些概念和原理性知识多方总结【2】 

http://www.db2china.net/home/space.php?uid=170085&do=blog&id=34961