一集群环境下的一些特殊问题
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》