RAC 的一些概念和原理的知识.docx

RAC 的一些概念性和原理性的知识一集群环境下的一些特殊问题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左右的空间就够了。OCR健忘问题是由于每个节点都有配置信息的拷贝，修改节点的配置信息不同步引起的。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)OCRprocessOracleClusterware在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中的内容。VotingDiskVotingDisk这个文件主要用于记录节点成员状态，在出现脑裂时，决定那个Partion获得控制权，其他的Partion必须从集群中剔除。在安装Clusterware时也会提示指定这个位置。安装完成后可以通过如下命令来查看VotingDisk位置。$Crsctlquerycssvotedisk2.2.2Clusterware后台进程Clusterware由若干进程组成，其中最重要的3个是：CRSD,CSSD,EVMD.在安装clusterware的最后阶段，会要求在每个节点执行root.sh脚本，这个脚本会在/etc/inittab文件的最后把这3个进程加入启动项，这样以后每次系统启动时，Clusterware也会自动启动，其中EVMD和CRSD两个进程如果出现异常，则系统会自动重启这两个进程，如果是CSSD进程异常，系统会立即重启。1).OCSSDOCSSD这个进程是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).CRSDCRSD是实现高可用性(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).EVMDEVMD这个进程负责发布CRS产生的各种事件(Event).这些Event可以通过2种方式发布给客户：ONS和CalloutScript.用户可以自定义回调脚本，放在特定的目录下，这样当有某些事件发生时，EVMD会自动扫描该目录，并调用用户的脚本，这种调用是通过racgevt进程来完成的。EVMD进程除了复杂发布事件之外，它还是CRSD和CSSD两个进程之间的桥梁。CRS和CSS两个服务之前的通信就是通过EVMD进程完成的。4).RACGIMONRACGIMON这个进程负责检查数据库健康状态，负责Service的启动，停止，故障转移(Failover)。这个进程会建立到数据库的持久连接，定期检查SGA中的特定信息，该信息由PMON进程定时更新。5).OPROCDOPROCD这个进程也叫作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层路由转到节点14).因为在节点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和VIP6).客户端的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.Logocssd.Log:$ORA_CRS_HOME/log/hostname/cssd/ocsd.Logevmd.Log:$ORA_CRS_HOME/log/hostname/evmd/evmd.LogNodeapp日志位置：$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也有相关的日志。一. 概述在之前的文章：RAC 的一些概念性和原理性的知识/tianlesoftware/article/details/5331067 提到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如：oraclerac1 $ crsctl get css disktimeout200oraclerac1 $ crsctl get css misscount60这是这2个参数的默认值。二. MOS 上相关的几篇文章How to start/stop the 10g CRS ClusterWareID 309542.110g RAC: Steps To Increase CSS Misscount,Reboottime and Disktimeout ID 284752.1CSS Timeout Computation in OracleClusterware ID 294430.1RAC Assurance Support Team: RAC and OracleClusterware Starter Kit and Best Practices (Generic) ID 810394.12.1修改CSS Misscount 步骤： 1)Shut down CRS on all but one node. For exact steps use Note 309542.1 2)Execute crsctl as root to modify the misscount:$ORA_CRS_HOME/bin/crsctl set css misscount where is the maximum i/o latency to the voting disk +1 second 3)Reboot the node where adjustment was made 4)Start all other nodes shutdown in step 1With the Patch:4896338 for thereare two additional settings that can be tuned.This change is incorporated into the and patchsets.These following are only relevant on with Patch:4896338，In addition to MissCount, CSS now has two more parameters: 1)reboottime (default 3 seconds) - the amount of time allowed for a node to complete a reboot after the CSS daemon hasbeen evicted. (I.E. how long does ittake for the machine to completely shutdown when you do a reboot) 2)disktimeout (default 200 seconds) - the maximum amount of time allowed for a voting file I/O to complete; if thistime is exceeded the voting disk will be marked as offline. Note that this is also the amount of timethat will be required for initial cluster formation, i.e. when no nodes havepreviously been up and in a cluster.$CRS_HOME/bin/crsctl set css reboottime -force ( is seconds)$CRS_HOME/bin/crsctl set css disktimeout -force (is seconds)Confirm the new css misscount setting via ocrdump2.2 CSS Timeout Computation in OracleClusterware2.2.1 MISSCOUNTDEFINITION AND DEFAULT VALUES The CSS misscount parameterrepresents the maximum time, in seconds, that a network heartbeat can be missedbefore entering into a cluster reconfiguration to evict the node. The followingare the default values for the misscount parameter and their respectiveversions when using Oracle Clusterware* in seconds:OS10g (R1 &R2)11gLinux6030Unix3030VMS3030Windows3030 *CSS misscount default value when using vendor (non-Oracle)clusterware is 600 seconds. This is to allow the vendor clusterwareample time to resolve any possible split brain scenarios. On AIX platforms with HACMP starting with BP#1, themisscount is 30. This is documented inNote5516 CSS HEARTBEATMECHANISMS AND THEIR INTERRELATIONSHIP The synchronization servicescomponent (CSS) of the Oracle Clusterware maintains two heartbeat mechanisms1.) the disk heartbeat to the voting deviceand2.) the network heartbeat across theinterconnect which establish and confirm valid node membership in the cluster. Bothof these heartbeat mechanisms have an associated timeout value. The diskheartbeat has an internal i/o timeout interval (DTO Disk TimeOut), in seconds,where an i/o to the voting disk must complete. The misscount parameter (MC), asstated above, is the maximum time, in seconds, that a network heartbeatcan be missed. The disk heartbeat i/o timeout interval is directly related tothe misscount parameter setting. There has been some variation in thisrelationshipbetween versions as described below:9.x.x.xNOTE, MISSCOUNT WAS A DIFFERENT ENTITY IN THIS RELEASENo one should be on this versionDTO = MC - 15 secondsDTO = MC - 15 seconds+Unpublished Bug 3306964DTO = MC - 3 seconds with CRS II Merge patchDTO =Disktimeout (Defaults to 200 seconds) Normally OR Misscount seconds only during initial Cluster formation or Slightly before reconfigurationIOT = MC - 3 seconds +Fix for unpublishedBug 4896338IOT=Disktimeout(Defaults to 200 seconds) Normally OR Misscount seconds only during initial Cluster formation or Slightly before reconfigurationSame as above ( with PatchBug:489633810.1 - 11.1During node join and leave (reconfiguration) in a cluster we need to reconfigure, in that particular case we use Short Disk TimeOut (SDTO) which is in all versions SDTO = MC “ reboottime (usually 3 seconds) Misscountdrives cluster membership reconfigurations and directly effects theavailability of the cluster. In most cases, the default settings for MC shouldbe acceptable. Modifying the default value of misscount not onlyinfluences the timeout interval for the i/o to the voting disk, but alsoinfluences the tolerance for missed network heartbeats across the interconnect.2.2.3 LONG LATENCIES TOTHE VOTING DISKS If I/O latencies to the voting diskare greater than the default DTO calculations noted above, the cluster mayexperience CSS node evictions depending on (a)the Oracle Clusterware (CRS)version, (b)whether merge patch has been applied and (c)the state of theCluster. More details on this are covered in the section Change inBehavior with CRS Merge PATCH(4896338 on ). Theselatencies can be attributed to any number of problems in the i/o subsystem orproblems with any component in the i/o path. The following is a non exhaustivelist of reported problems which resulted in CSS node eviction due to latenciesto the voting disk longer than the default Oracle Clusterware i/o timeoutvalue(DTO):1.QLogic HBA cards with a LinkDown Timeout greater than the default misscount.2.Bad cables to the SAN/storagearray that effect i/o latencies3.SAN switch (like Brocade)failover latency greater than the default misscount4.EMC Clariion Array whentrespassing the SP to the backup SP greater than default misscount5.EMC PowerPath path errordetection and I/O repost and redirect greater than defaultmisscount6.NetApp Cluster (CFO) failoverlatency greater than default misscount7.Sustained high CPU load whicheffects the CSSD disk ping monitoring thread8.Poor SAN network configurationthat creates latencies in the I/O path. The mostcommon problems relate to multi-path IO software drivers, and thereconfiguration times resulting from a failure in the IO path. Hardwareand (re)configuration issues that introduce these latencies should becorrected. Incompatible failover times with underlying OS, network or storagehardware or software may be addressed given a complete understanding of theconsiderations listed below. Misscount should NOT be modified to workaround theabove-mentioned issues. Oracle support recommends that you apply thelatest patchset which changes the CSS behaviour.More details covered innext section.2.2.4 Change in BehaviorwithBug:4896338applied on top of Starting with +Bug:4896338,CSS will not evict the node from the cluster due to (DTO) I/O to voting disktaking more than misscount seconds unless it is during the initial clusterformation or slightly before reconfiguration. So if we have aN number ofnodes in acluster and one of the nodes takes more than misscountsecondsto access the voting disk, the node will not be evicted as long asthe access to the voting disk is completed within disktimeoutseconds.Consequently with thispatch, there is no need to increasethe misscount at all. Additionallythis merge patch introduces Disktimeout which is the amount of time thata lack of disk ping to voting disk(s) will be tolerated.Note: applying the patch will notchange your value for Misscount.The table below explains intheconditions under which the eviction will occurNetwork PingDisk PingRebootCompletes within misscount secondsCompletes withinMisscount secondsNCompletes within Misscount secondsTakes more than misscount seconds but less than Disktimeout secondsNCompletes within Misscount secondsTakes more than Disktimeout secondsYTakes more than Misscount SecondsCompletes within Misscount secondsY* By defaultMisscount is lessthan Disktimeout seconds2.2.5 CONSIDERATIONS WHENCHANGING MISSCOUNT FROM THE DEFAULT VALUE1.Customers drive SLA and clusteravailability. The customer ultimately defines Service Levels and availabilityfor the cluster. Before recommending any change to misscount, the full impactof that change should be described and the impact to cluster availabilitymeasured.2.Customers may have timeout andretry logic in their applications. The impact of delaying reconfiguration maycause artificial timeouts of the application, reconnect failures andsubsequent logon storms.3.Misscount timeout values areversion dependent and are subject to change. As we have seen, misscountcalculations are variable between releases and between versions within arelease. Creating a false dependency on misscount calculation in one versionmay not be appropriate for later versions.4.Internal I/O timeout interval(DTO) algorithms may change in later releases as stated above, there exists adirect relationship between the internal I/O timeout interval and misscount.This relationship is subject to change in later releases.5.An increase in misscount tocompensate for i/o latencies directly effects reconfiguration times for networkfailures. The network heartbeat is the primary indicator of connectivity withinthe cluster. Misscount is the tolerance level of missed check ins thattrigger c