ANBOB™

rac 全名Real Application Clusters，是ORACLE DATABASE 上的一个组件， 用共享存储的结构可以把1个数据库运行在多个分别计算的节点instance中 ，来提高了数据库的可用性，可以安装在企业版或标准版中，rac 出生于2001年的9I release 1, 以它的前身是oracle parallel server,rac 引入cache fusion机制提高实例间的资源同步。

cluster(集群)从功能分应该分
1，HA高可用就是批供7*24小时的不间断服务；
2，LB负载均衡，把繁重的任务分散到多个节点；
3，超集运算，用多台机器运算模拟大量的运算如行星的活动轨迹。
rac 同时具备前两种

集群从可用性上分
1,ACTIVE-ACTIVE 这种模式可以所有节点同时提供服务，同时因为都是活动的操作的又是同一个数据库，node之间要互相知道对方的健康利用的是一种心跳机制，如果之间出现了通讯故障，整个集群就分成了多个独立部分，就遇到了最大的难题split-brain(脑裂)和IO-FENCING(IO隔离)。

2，Active/passive 这种模式是只有一个node是可以服务的，其它的做为备用，只用当NODE1发生故障是才启用备用NODE，veritas,IBM的HACMP都可以做这个的集群，有点类似Data Guard的角色转换当然11G前的逻辑 DG和11GR2的DG也可以做到双活。

RAC 就具备以上特性，对于第二种只有当两个节点时active_instance_count=1

RAC从软件架构上分
1，集群件，如Clusterware
2，DLM(分布式锁管理)
3，instance

要想控制多个OS的资源，只用OS控制已经无法办到，引入了集群件，层次上可以分三层

RAC
————-
集群件
————
OS

RAC与Clusterware是两个概念，RAC只是运行在集群件上的软件，集群件有多种选择，不一定用ORACLE的可以用SUN CLUSTER、veritas cluster等。ORACLE自己的集群件，10GR1前叫cluster manager只能用于linux、winNT,10GR1改叫CRS，10GR2改叫Clusterware,11G又改叫Grid Infrastructure（GI） ,GI还引入了ASM,clusterware不仅可以用于ORACLE数据库还可以用于WEB的集群。

RAC的前身是OPS,所以他们有很多相同的地方，也有人说开始改名只是出于商业目的

RAC必须解决的问题,并发、健忘、脑裂、IO分离

【并发】

单实例时只用LOCK,LATCH,甚至更轻量级的mutex,合起来都是是Local lock.管理单实例的并发，LOCK是一种enqueue队列机制，latch是一种抢占机制，如果有拿到就会不停的尝试spin，之间不释放cpu. (有点像买火车票前者是去窗口排队后者是打电话或网购);

到了RAC是多个实例并发所以要引入另一种锁机制DLM,DLM名称在OPS时叫PCM，RAC中改为了CACHE FUSION.DLM就是控制实例间的资源竞争问题，节点间的资源要同步,RAC控制资源的粒度是以block为单位的，在DLM中根据资源的数量和密集程度又分为了cache fusion resource和no-cache fusion resource，对就这两种资源也有两种锁叫pcm lock,no-pcm lock

cache fusion resource是指数据块这种资源如table block,index block,undo block,segment header
no-cache fusion resource是指非数据块的资源如datafile ,control file,shared_pool中的（library cache,row cache）,数据字典视图

DLM 是一种Global lock,管理多实例的并发，与local lock的区别是，local是用户进程和后台进程使用，global 只是后台进程使用。

no-cache fusion resouce比如library cache中的对象定义和row cache中的sql,执行计划这类数量有限，修改频率低的,是有后台的LMD进程以广播的方式传给其节点，现在每个节点自己的LCK进程修改自己实例中与之相关的对象失效。

cache fusion resource如buffer cache修改密集就不适合用广播方式而cache fusion机制，用的就是PCM LOCK（cache fusion lock）

PCL LOCK有三种模式:Exclusive,Shared,Null,分别对应三种数据块上的状态前后顺序如xcur,scur,cr可以从v$bh中查看

select count(*)cnt,status from v$bh group by status;

Cache fusion解决集群节点间的数据库拷贝分布是通过GRD(global resource directory)实现的，GRD的实现分布在每个节点的SGA中，每个节点又是只是一部份，合起来才是完整的GRD,从所有节点中选一个做Master Node记录所有节点资源使用信息如PCM LOCK，而其它节点叫shadow node只记录自己节点上的PCM LOCK。GRD的内容结构是data block address,node location,mode,role,scn,Past image;而mode ,role,PI是PCM LOCK的三个属性

整个Cache fusion是有GCS（global cache service）,GES(global enqueue service)服务组成
GCS是负责数据块在实例间传送对应进程LMSN，GES负责锁管理对应进程LMD

GRD,GCS,GES共同完成了RAC的核心cache fusion

clusterware 运行需要两个文件，OCR DISK AND VOTING DISK
【健忘】
因为所有节点都可以修改集群件，如果node1修改了配置然后关闭，后来node2再次修改然后关闭，当node1时就会根据以前的配置把node2的配置冲掉，这种现象就叫健忘，解决办法就是把配置文件只有一个放到共享设备上，所以引入 OCR（Oracle Cluster Registry）disk解决健忘问题，OCR 是以MAP的数据结构key-value形式存在的，记录了整个集群的配置，11G前必须放到共享RAW device,shared block device,或OCFS，11G RAC如果是从10G升级而来还可以保留在原RAW如果是安装11G RAC从DBCA中可以看到不再支持RAW，建议使用ASM，11G R1及以前OCR最多可以有一个镜像文件到了11GR2 支持5个。查看ocr路径 /etc/oracle/ocr.loc，每个节点内存都有OCR的镜像叫做CRS cache，是有ocr后台进程来更新的，并是所有ocr process都可以操作ocr disk,只有一个ocr process可以更新ocr disk,这个节点叫 ocr master node;每个节点之间也是有OCR process互相通信更新各自的CRS cache。OCR 文件总共有三个分支system,database,CRS.

【脑裂】
在集群正在工作的时间因内部通讯故障，集群被拆分成几个部分，每个部分又都尝试接管其它部分的资源，而应用又可以分别连到这几个部分，但是这几部分又不能同步所以有可以会把不同的数据写入到磁盘中，它们都会认为连接不上的对方已不存在，这种现象叫脑裂。RAC解决这个问题引入了一个表决设备就是voting disk,裁决集群的成员，集群中所有节点共享voting disk，如果哪个node发送heartbeets（心跳）到interconnect 和 VD 失败那么它就被逐出集群，如果节点之间不能通讯，但是都可以连接VD,那么就利用搞票机制，比如集群中如果用三个nodes,node1 and node2 可以互通也可以连VD,node3与组织失去联系但是也可以连VD，2票比1票，node3将被T，如果是两个nodes,那就看谁先抢到VD,那就是2:1，票少的被T出。同时CLUSTERWARE 会利用shoot the other node in the head （STONITH）一种软请求要求被T出者自行了断(reboot)，并且11g GI已经支持IPMI智能平台管理接口向对方的硬件发送闪断电源的方式让它重启。VD到了11G R2 GI已可以支持VD及镜像多大15个，远大于11R1之前的3个。vd和OCR一样也是非ASM只支持升级到11G的集群，到oracle 12 block and raw device都将不在支持。

voting disk在10g r1只能放在raw 中，支持多路径冗余防止逻辑磁盘故障，到了10 R2可以直接VD 放到在block device中，到了11G R1安装已完全允许VD AND OCR安装到block device中，完全抛弃了RAW。

【IO Fencing分离】
因为像ocr,vd,datafile controlfile,redo file,undo file,spfile这些都是在共享设备上，如果发生了脑裂只T出集群有时还往往不够，还是有可能操作IO 文件，就像上面提到的IPMI也是一种IO-Fencing的手段，IO Fencing分两种硬件或软件
硬件可以通过scisi reserve command锁定设备，确认nodo 1出现问题就自杀，sun 和veritas 就是这么做的。
软件如STONITH,IPMI.oracle 10g时linux利用hangcheck-time 模块，这种模块不受系统负载影响，11g.1增加了oprocd进程，11g.2就不在利用hangcheck-timer,GI用cssdagent和cssdmonitor进程替换了以前的oprocd进程的工作,windows服务名是orafenceservice。

单实例时用到的网络也就TCP/IP协议，而RAC又引入了VIP,ip 与vip的区别是IP是绑定在网卡上的，而VIP是注册在OCR中有crs维护，在网卡上只是浮动批定的绑定在public 网卡上所以必须和public 是同一个子网段，当发现节点1死去，节点1vip可以浮动指定到节点2上。FAILOVER就是建立在VIP上的。IP是利用传输层的TCP超时，VIP是应用层的返回异常。TCP/IP是基于OS kernel阀值不统一。

TCP/IP模型
数据传输是垂直经过TCP/IP协议层层打包再层层解包。
如客户端应用层的sqlplus 发起建立connect
经过传输层tcp 确定本地端口多少远端端口多少，验证数据完整性如果没收到重发，重发数次后返回应用层超时错误，
再经过网络层IP，确定本地IP与远端IP，不关心数据完整性只管传,
经过链路层MAC 确认本地与远端MAC,
层层打包，发到对方，层层解包经过对方的TCP层时会验证完整性，如果有异常按原路返回通过来源重发，最后到达应用层的LISTENER.走的是一个U型线

VIP
比如OCR检测到NODE 2出现故障然后clusterware 重组，把ocr文件中的vip2指到了node1 的public 网卡上。同样是客记端sqlplus 向NODE2发起请求，再经过IP层时被指向了NODE1，NODE1 listener上没有VIP2上的监听，因为每个节点的监听只监听自己public和vip,就会抛出异常，客户端捕获这个异常再重新发往NODE1.

FAILOVER故障转移
10G时
client-side connect time failover 只在建立连接时，如果第一下失败尝试下一下
TAF transparent application failover 连接中就可以跳转，无提交事务必须rollback.配置中有4个子项（method,type,delay,retries），method分base异常时跳转，preconnect创建连接时就每个实例创建一个;type也分两种select对于select操作中途失败后到新的instance不会重复执行select sql，而是继续返回剩余部分,session 是切换实例后select sql会重复执行。
server-side TAF，只是把TAF配置放到的SERVER端
11G增加了Fast Connect Failover,支持JDBC OCI和JDBC thin驱动，配置在应用代码中，应用使用服务名连接数据库，JDBC运行的节点上配置并启用了Oracle Notification Service (ONS)；这样应用中就可以try{xxx} cache {do something};

客户端要定期检查服务来判断服务器状态本质是个pull模型，在10g引入了push机制-FAN(FAST Application Notification),当服务器发生变化时服务器会主去通知客户端，CLIENT得知server 变化，就是依赖ONS（Oracle Notification Service）实现的。

LOAD BALANCE负载均衡
10G时
client-side LB 创建连接时随机分配不论好坏。
server-side LB 根据pmon进程定期更新Listener提供当时的负载情况。pmon也可以向远程listener注册利用remote_listener 系统参数。
11G
引入了SCAN (Single Client Access Name)我认为这应该算是一种LB,配置SCAN方法有DNS,GNS,network file

–参考并推荐<大话RAC>

打赏

微信扫一扫，打赏作者吧～