大话ORACLE RAC.docx
- 文档编号:1424829
- 上传时间:2023-05-01
- 格式:DOCX
- 页数:13
- 大小:26.78KB
大话ORACLE RAC.docx
《大话ORACLE RAC.docx》由会员分享,可在线阅读,更多相关《大话ORACLE RAC.docx(13页珍藏版)》请在冰点文库上搜索。
大话ORACLERAC
大话ORACLERAC
什么是集群
集群(Cluster)是由两台或多台节点机(服务器)构成的一种松散耦合的计算节点集合,为用户提供网络服务或应用程序(包括数据库、Web服务和文件服务等)的单一客户视图。
集群系统一般通过两台或多台节点服务器系统通过相应的硬件及软件互连,每个群集节点都是运行其自己进程的独立服务器。
这些进程可以彼此通信,对网络客户机来说就像是形成了一个单一系统,协同起来向用户提供应用程序、系统资源和数据。
除了作为单一系统提供服务,集群系统还具有恢复服务器级故障的能力。
集群系统还可通过在集群中继续增加服务器的方式,从内部增加服务器的处理能力,并通过系统级的冗余提供固有的可靠性和可用性。
集群的分类:
1、高性能计算集群:
高性能计算集群采用将计算任务分配到不同节点来提高整体计算能力主要应用在科学计算领域。
2、负载均衡集群LB:
负载均衡集群为企业需求提供更实用的系统。
该系统使各节点的负载流量可以在服务器集群中尽可能平均合理地分摊处理。
该负载需要均衡计算的应用程序处理端口负载或网络流量负载。
这样的系统非常适合于运行同一组应用程序的大量用户。
每个节点都可以处理一部分负载,并且可以在节点之间动态分配负载,以实现平衡。
对于网络流量也如此。
通常,网络服务器应用程序接受了大量入网流量,无法迅速处理,这就需要将流量发送给在其它节点。
负载均衡算法还可以根据每个节点不同的可用资源或网络的特殊环境来进行优化。
3、高可用性集群HA:
为保证集群整体服务的高可用,考虑计算硬件和软件的容错性。
如果高可用性群集中的某个节点发生了故障,那么将由另外的节点代替它。
整个系统环境对于用户是一致的。
实际应用中HA与LB经常是同时具备,ORACLERAC就同时具备HA和LB。
集群环境的特殊问题
1、并发控制
在集群环境中,关键数据都必须是共享存放的。
各个节点都对数据有平等的访问权利。
因此必须要有某种机制控制节点对数据的访问。
2、健忘症Amnesia
这个问题发生在集群环境配置文件不是集中存放,而是 每个节点都有一个本地副本。
在集群正常运行时,用户可以在任务节点更改集群的配置,并且更改会自动同步到其它节点。
在特殊的情况下比如:
两个节点的集群,节点1因为正常维护需要关闭,然后在节点2修改了某些配置,然后关闭节点2,启动节点1。
因为在节点2修改的配置内容没有同步到节点1,所以节点1启动后,它仍然是用旧的配置文件工作,这时就会造成配置丢失,也就是所谓的“健忘症“。
3、脑裂SplitBrain
在集群里,节点间需要通过心跳机制了解彼此的健康状况,以确保各节点协调工作。
假设只是“心跳”出现故障,但各个节点还在正常运行。
这时每个节点都认为其它节点宕机,自己是集群中唯一健在者,自己应该获得整个集群的控制权。
在集群环境里,存储设备是共享的,这就意味着数据灾难,这种状况就是“脑裂”。
解决这个问题的算法通常就是投票算法。
集群中各节点通过心跳来通报彼此的健康状况,假设每收到一个节点的通报代表一票。
对于一个三节点的集群,正常运行时每个节点都会有3票。
假设节点1的心跳出现故障,但是节点1还在运行:
这时整个集群就分裂成二个小的partition。
节点1自己一个partition,节点2和节点3是一个partition。
这就必须剔除一个partition。
这时节点2和节点3所在的partition每个节点有二票,节点1只有一票。
所以节点2和节点3组成的小集群获得控制权,节点1被踢出。
如果集群只有二个节点,上面的算法就没用了,这时必须引入第三个设备QuorumDevice。
QuorumDevice通过采用共享磁盘,也叫QuorumDisk。
这个QuorumDisk也代表一票。
当心跳出现故障时,两个节点同时去争取QuorumDisk这一票,最早到达的请求被满足,后到达的节点无法获得这一票。
这时最先获得QuorumDisk的节点就获得两票,而另一个节点就只有一票,票少的被踢出集群。
4、IO隔离IOFencing
这个问题是上一个问题的延伸。
当集群系统出现脑裂时,必须判断那些节点获得控制权,那些节点要踢出集群。
但这样还不够,还必须保证被赶出集群的节点不能操作共享数据。
这就是IO隔离要解决的问题。
IOFencing的实现有硬件方式和软件方式,ORACLERAC采用的是软件方式,直接重启故障节点。
集群软件
理解了前面的内容,有助于理解ORACLERAC的架构及各个组件的功能。
集群最终的目的是为了向客户端提供单一视图并提供HA及LB。
在集群中每个节点都能处理客户端的请求。
所以每个节点至少要运行一个实例。
在单实例环境中,ORACLE实例通过OSKernel访问硬件并通过进程调度多个进程对硬件资源的使用,但在集群环境下存储设备是共享使用,ORACLE实例不仅需要协调节点内多进程的共享使用,还需要协调主机间进程的共享使用。
这种需求靠传统的OSkernel就无法满足了,这就需要集群软件来实现。
集群软件主要有SunCluster,IBMHACMP等,ORACLE也推出了自己的集群软件Clusterware
ORACLEClusterware组成
ORACLEClusterware有以下几个组件
1、OCROracleClusterRegistry为了解决集群“健忘”的问题,最简单的解决办法就是整个集群只有一份配置,所有节点共用这份配置。
ORACLE采用的方法就是把这个配置文件放在共享存储上,这个文件就是OCRDISK。
节点通过OCRProcess读写OCR。
但只有一个节点能够读写OCRDISK叫OCRMaster节点,其它节点通过本节点的OCRprocess向masternode的OCRprocess提交请求,由masterOCRProcess完成物理读写,并同步所有节点OCRcache中的内容。
2、VotingDisk这个文件主要用于记录节点中成员状态,在出现脑裂时,仲裁那个Partition获得集群的控制权
3、ClusterSynchronizationService(css):
CSS服务通过多种心跳机制实时监控集群的健康状态,提供脑裂保护等集群服务功能
CSS服务有二个心跳机制:
私有网络的NetworkHeartbeat用于监控节点之间的健康状态(超时阈值参数MisCountMC),通过VotingDisk的DiskHeartbeat(超时阈值参数IOtimeoutIOT)。
用于监控是否有访问共享存储的IO故障如HBA卡故障,SAN交换机或者存储的线缆损坏导致I/O超时。
这两个心跳机制决定节点是否应驱逐。
下面描述了驱逐行为发生的条件:
(1)、都不超时,不会驱逐
(2)、网络PING在MC时间内完成,磁盘ping超过了MC,但是在IOT内成,也不会驱逐
(3)、网络ping在MC时间内完成,磁盘ping超过了IOT,则节点被驱逐
(4)、网络ping超过MC设置,磁盘ping在MC内完成,节点也会被驱逐
4、ClusterReadyService CRS管理的任何事物被称之为资源,它们可以是一个数据库、一个实例、一个监听、一个虚拟IP(VIP)地址、一个应用进程等等。
CRS是根据存储于OCR中的资源配置信息来管理这些资源的。
这包括启动、关闭、监控及故障切换(start、stop、monitor及failover)操作。
当一资源的状态改变时,CRS进程生成一个事件。
当你安装RAC时,CRS进程监控Oracle的实例、监听等等,并在故障发生时自动启动这些组件。
默认情况下,CRS进程会进行5次重启操作,如果资源仍然无法启动则不再尝试。
集群的高可用HA就靠它了
5、EventManagerService 负责发布CRS产生的各种事件
6、 OracleNotificationService(ONS):
FAN FastApplicationNotification事件的发布及订阅服务
7、RACG 为clusterware进行功能扩展以支持Oracle的特定需求。
它在FAN事件发生时执行服务器端的调用脚本(servercalloutscript)
8、ProcessMonitorDaemon:
监视集群和提供I/O隔离(fencing)
下表是Clusterware后台进程列表,其中带(r)的进程表示需要以root用户运行
Clusterware组件
Linux/unix进程
Windows服务
Windows进程
ProcessMonitorDaemon
oprocd(r)
OraFenceService
RACG
racgmain
racgimon
racgmain.exe
racgimon.exe
OracleNonificationService(ONS)
ons
EventManager
evmd(r)
evmd.bin
evmlogger
OracleEVMService
evmlogger.exe
evmd.exe
ClusterReady
crsd.bin(r)
OracleCRSService
crsd.exe
ClusterSynchronizationServices
init.cssd(r)
ocssd(r)
ocssd.bin
OracleCSService
ocssd.exe
RAC与Clusterware的交互
Clusterware要决定集群组成、成员身份、成员状态,Clusterware并不关心上一层应用到底是数据库或是WEB应用。
它只负责收集集群节点状态完整视图,并向上层提供这个视图。
而RAC要依赖于Clusterware,它需要从Clusterware获得这个视图,根据这个视图调整自己。
但是RAC也不完成依赖于Clusterware,很多时候RAC是两腿走路:
先看Clusterware能不能解决问题,如果不能,RAC自己进行IMR(instancemembershiprecover)
Clusterware层
所有节点的Clusterware组成一个集群,并构成一个集群成员列表(Clustermembershiplist)第个节点会分配一个成员ID(NodeId)这些Clusterware之间互相通信以了解彼此的状态,并从中选出一个节点作为MasterNode,MasterNode负责管理集群状态的变迁。
当有节点加入或离开集群时,集群的状态会发生变迁,最终达到一个新的稳定状态。
每个集群的稳定状态用一个数值表示,这个数值叫做ClusterIncarnationNumber。
达到新稳定状态时,这个数值会改变。
RAC中的各个实例也构成了一个实例成员列表(Instancemembershiplist),每个实例也使用Clusterware层的nodeid作为身份标识,这个ID在集群生命周期内是不会变的。
RACInstance在启动时会把LMON、DBWR等需要操作共享存储的进程作为一个组注册到Clusterware中,并从Clusterware获得nodeid作为组ID。
RAC集群与节点集群是两个层次的集群,两个集群都有脑裂、IO隔离等问题。
这两个集群都有各自的故障检测机制。
如果在RAC这一层检测到节点故障,RAC集群会做如下工作
(1)暂停对外服务
(2)RAC通知Clusterware,并等待Clusterware完成集群重构,达到新的稳态。
(3)Clusterware完成重构后,会通知上层的RAC集群,RAC集群收到这个信息后开始自己的重构。
RAC层
RAC的集群状态是通过LMON进程提供的,这个进程提供了CGS(ClusterGroupService)和NM(NodeManagement)两个服务。
最底层的是NM服务,它是RAC集群和Clusterware集群的通信通道,通过它把本节点的资源(ClusterResource)状态登记到本地的Clusterware,然后由后者提供给其它节点的Clusterware,NM还要从Clusterware获得其它节点的资源状态。
1、NM组
第个RAC实例都有许多进程在工作,比如DBWR,LGWR,LMON等,其中任何一个进程出现故障,这个节点的其它活动进程都应受到限制,否则有可能破坏共享磁盘上的数据。
因此,RAC实例的所有进程都是作为一个组(NMGROUP)注册到Clusterware中的,其中的LMON作为组里的PrimaryMember注册并获得MemberID,而其它进程作为这个组的SlaveMember并以相同的MemberID注册到Clusterware。
整个集群的节点成员信息是通过一个位图Bitmap来维护的。
每个节点对应一个位bit,0代表节点DOWN,1代表UP,整个有一个有效/无效标志位。
这个位图在整个集群作为一个全局资源被永久记录,当有新的节点加入集群时,该节点需要读入这个位图,找到自己对应的位bit,把值从0设为1,并且把位图的无效标识设为1,这时虽然位图的内容是正确的,但状态是无效的,其它节点会定时读入这个位图,一旦发现这个位图的状态是无效,就会触发集群的重构。
达到新的稳定状态后,再把位图状态置为有效。
当集群重构完成后,NM会把这个事件传递给CGS层,CGS负责同步所有节点间的重构。
正常实例的启动、关闭过程中,Clusterware、NM都会获得通知。
但如果是实例异常关闭,Clusterware,NM就会不知道,这时就需要CGS提供的IMR功能进行感知。
然后进行重构。
IMR是由CGS提供的重构机制,用于确认实例之间的连通性、快速地排除故障节点以减少到数据的损害。
这个过程中,每个实例都要作出投票,投票的内容就是它所认为的整个集群现在状态,然后由一个实例根据这些投票,重新规划出一个新的集群(最大的subgroup)并把这个投票结果(votingresult)记录到控制文件,其它节点读取这个结果,确认自己是否属于集群,如果不属于,就要自动退出。
如果属于,则参与执行重构过程。
投票过程中,所有的成员节点都尝试获得控制文件中的一个字段(CFVRR,ControlFileVoteResultRecord)进行更新,但只会有一个成员获得,这个成员会记录其它成员的投票内容。
比如一个3节点的RAC,如果实例3的LMON异常,这时CFVRR记录如下:
seq# inst# bitmap
2 0 110
2 1 110
2 2 001
这时实例3无法获得其它两个节点的状态,最终重构的结果就是实例1、2组成新的集群,节点3被赶出集群。
如果IMR发现出现split-brain,即集群中出现两个group,这时IMR先会通知CM,然后等待CM解决这个脑裂,等待时间是_IMR_SPLITBRAIN_RES_WAIT,缺省600毫秒。
超时后IMR自己执行节点排除。
在CGS完成节点的重构之后,GCS、GES才进行数据层面的重构,也就是CrashRecover。
2、重构触发类型
(1)有节点加入或离开集群而触发重构,由NM触发。
(2)NetworkHeartbeat异常:
因为LMON或者GCS、GES通信异常,由IMR触发。
(3)ControlfileHeartbeat异常:
第个实例的CKPT进程每3分钟都会更新控件文件的一个数据块,叫做CheckpointProgressRecord,并且是每个实例对应一个,因此不会出现争夺现象。
由IMR触发。
RAC下的并发控制
RealApplicationCluster真正应用集群不是双机热备,一台机器在空闲中等待。
它是Share-Disk的集群架构。
原来在单台机器中的并发,被扩大到多台计算机上的进程并发。
因此一个事务在获取TX锁时,还必须检查其它机器上是否有事务对同样的数据获取TX锁。
因此RAC必须有一个在多台计算机上检测并发的机制,它就是分布式锁管理器(DistributedLockManagement)。
可以把DLM看成是一个“仲裁”,它记录着那个节点正在用哪种方式操作哪个数据,并负责协调各个节点间的竟争。
任何节点在修改数据前必须向DLM申请对数据所在的“数据块”的操作权限。
选择数据块是性能方面权衡的结果
DLM中的资源和锁
DLM中协调各节点对资源使用的功能叫同步,所有资源访问都是需要同步的,节点间的同步是为了保证数据一到处性,有得必有失,同步需要在节点间传输数据及访问DLM,这会影响集群的性能。
如果同步非常频繁那么将严重影响集群的性能。
为了将同步活动降到最低又正好满足需要。
DLM根据资源数量、活动密集程度将资源分成两类。
分别是CacheFusionResource、None-CacheFusionResource。
CacheFusionResource特指数据块资源,包括普通数据块、索引数据块、段头、UNDO数据块。
非数据块资源全部都归类为None-CacheFusionResource,包括数据文件、控制文件、数据字典视图、LibraryCache、RowCache等。
对应两种资源,DLM提供的锁也分成两种,PCMLOCK和Non-PCMLock。
它们都是全局锁(GlobalLock)--PCMmeans ParallelCacheManagement
NoneCacheFusion资源
典型的None-CacheFusion资源包括Sharepool的RowCache和LibraryCache内容。
librarycache中存放的是所有SQL语句、执行计划、包等对象,以及这些对象所引用的对象。
当一个语句或包编译时,它们所引用的所有对象都会加一个LibraryCacheLock ,在执行时,所有这些引用的对象都要被加一个LibraryCachePin,以保证语句在执行时这些对象的结构不会被修改。
编译完成后,加在引用对象上的Librarycachelock会由原来的share或exlusive模式变成null模式。
Null模式的Librarycachelock相当于一个触发器,当这些对象的定义被修改后引用它的对象将被置为无效,必须重新编译。
在RAC环境下,这个问题进一步延伸。
比如每个节点上都有某个表的引用对象,无论任何一个节点对这个表的修改,都有把所有节点上对该表有引用的对象置为无效。
因此除了传统的Librarycachelock这外,每个节点上要有一个进程叫LCK0,对本实例的Librarycache中的对象加一个Share-mode的IV(Invalidation)InstanceLock,如果某个用户想要修改 对象定义,必须获取一个Exclusive模式的IV锁,这会通知本地的LCK0释放Share-mode锁,本地LCK0在释放这个锁这前,会通知其它节点上的LCK0将该节点上的Librarycache中的所有相关对象置为失效。
这是一种广播机制。
这些通信过程是由实例的LMD进程完成的。
Rowcache中存放的是数据字典,其目的是编译过程减少对磁盘的访问。
其内容也需要在所有的实例中同步,其同步机制和Librarycache是一样的,也是由LCK0进程完成。
可以看出None-CacheFusion资源也以下特点。
1、资源数量有限:
比如RowCache存放的是对象定义,LibraryCache存放的是SQL代码、执行计划等。
在一个生产系统中,表、视图、存储过程、包的数量是有限的,SQL语句虽然比较多,但数量也是有限的。
如果大部分SQL语句没有使用绑定变量或存储过程和包中使用大量动态SQL这不论在单实例或RAC环境下都产大问题。
2、资源被修改的频率很少:
可以相一下生产系统第天会有多少次机会执行Altertable这种DDL操作。
一般也是应用程序升级才执行一次。
因为资源有这些特点,ORACLE采用了于广播的机制。
第个节点上的变化都马上通知所有节点。
CacheFusion资源
和SharePool的资源比起来,BufferCache的数据块数量更多,修改更加密集。
如果每次数据块修改都在集群内广播,这种方式比较消耗资源,也不一定高效。
因此对于数据块这种资源,RAC采用的是CacheFusion机制,使用PCMLock。
PCMLock有3种模式:
Shared、Exlusive、Null,RAC用数据块状态(bufferState)来描述数据块上的锁类型。
二者的关系如下
PCMLockMode BufferState 说明
X XCUR 数据块上的锁是X模式且是最新版本current
S SCUR 数据块上的锁是S模式且是最新版本
NULL CR 实例对数据块没有加任何模式的PCM锁
实例在读取数据块时加的锁是S模式的,数据块的状态是SCUR。
某个实例要修改数据块时必须获取这个数据块的X锁,因为X和S模式不相容,其它实例必须放弃这个数据块的S锁进入NULL状态。
数据块的状态由GRDGlobalResourceDirectory实现。
它记录了数据块在集群间的分布。
每个实例的SGA中都有GRD,但都是部分的GRD,所有实例的GRD汇总在一起就是完整的GRD。
RAC会根据每个资源的名称从集群中选择一个节点作为它的MasterNode,而其它节点叫做ShadowNode。
MasterNode的GRD记录了该资源在所有节点上的使用信息,而ShadowNode只记录该资源在本节点的使用信息。
GRD中记录的是数据块地址DataBlockAddress和PCMLock信息,这种锁有三个属性:
Mode、Role、PI。
Mode属性用于模式锁的模式,有三种分别是
(1)Exclusive(X)持有这种锁的实例可以对这个数据块进行修改。
集群
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 大话ORACLE RAC 大话 ORACLE