首页 » ORACLE 9i-23c » RAC那些事,概念

RAC那些事,概念

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>

打赏

对不起,这篇文章暂时关闭评论。