Oracle高可用环境之RAC常用组件详解(2)

Grid Infrastructure使用两种类型的共享设备来管理集群资源和节点：OCR(Oracle Cluster Registry)和表决磁盘。Oracle 11.2引入一个新的文件，称作Oracle Local Registry(OLR)，它只允许存放在本地。

OCR为所有节点所共享，包含了集群资源的所有信息和 Grid Infrastructure需要的操作许可。为了实现共享，OCR需要存放在裸设备、共享块设备、类似OCFS2的集群文件系统或者ASM上。在Grid Infrastructure中，只有通过升级而来的系统才支持非ASM管理的OCR，如果是新的安装，你必须使用集群文件系统或者ASM。在RAC10和11.1中，OCR可以有1个镜像，而到了11.2，则增加到了5个拷贝。

Grid Infrastructure每4个小时自动备份一次OCR，并保留一些备份用以恢复。RAC11.1中引入一个选项来手动备份Cluster Registy，以root用户运行诊断程序时将执行附加的完整性检查。Clusterware11.1通过Oracle Universal Installer简化了Cluster Registry在共享的块设备上的部署，在此之前，需要手动进行一个移动OCR到块设备上的过程。当你在Red Hat 4或SLES10上，在RAC11.1中使用裸设备，需要通过udev来手动对裸设备进行配置。Oracle Support中对这个配置过程提供了说明，单路径和多路径连接共享存储的方法有所不同。

在一些罕见的情况中，OCR可能会被毁坏，此时就需要从备份中来还原。根据毁坏的严重性，可能从一个镜像中来还原就足够了，也可能需要从备份中来还原。只能通过Oracle提供的工具来管理和维护OCR，如果直接对OCR中的内容进行转储和修改，造成的配置问题Oracle将不予支持。

Oracle 11.2中引入另一个集群配置文件，叫OLR。这个文件在每个节点的Grid Infrastructure安装目录中都有自己单独的拷贝。OLR存储了集群启动初期OHAS使用的重要的安全环境。定位voting盘时需要用到OLR和网格即插即用配置文件，如果它们存储在ASM中，GPnP的profile中的discovery相关字符串将被集群同步进程用来寻找它们。在集群软件启动的后期，cssd进程将启动ASM实例来连接OCR文件。然而，它们的路径存储在/etc/ocr.loc文件中，和RAC11.1中一样。当然，如果voting文件和OCR如果存储在一个共享的集群文件系统上，ASM实例不需要也不会启动，除非其他资源需要使用到ASM。

若一个节点在指定时间内(countdown-threshold)无法响应其他节点的心跳请求，这个节点将被踢出集群。

与OCR类似，voting disk和它的镜像都必须存放在共享存储上(11.1中支持3个voting disks，11.2中增加到15个)。和OCR一样，Grid Infrastructure只在升级的系统上支持裸设备，新安装的只支持集群文件系统或ASM。块设备和裸设备在Oracle12中将不再支持。

Oracle强烈建议在不同的位置上使用至少3个voting disks。当使用ASM管理voting disks时，你需要注意磁盘组和故障组的冗余级别。注意，voting disk的所有拷贝都在一个磁盘组里面，你不能将voting disks分布在多个磁盘组中。当使用外部冗余的磁盘组，你只能有1个voting disk。使用normal redundancy冗余级别需要至少3个故障组来存储3个voting disks，high redundancy冗余级别更加灵活，它支持多达5个voting disks。

ASM是oracle10.1中开始引入的，它是Oracle的物理数据库结构上的一个支持集群的逻辑卷管理器。可以存储在ASM中的文件包括控制文件、数据库文件和在线重做日志(还有spfile和归档日志)。直到11g r2，都不能存储任何类型的操作系统文件。ASM建立在ASM disk、Failure groups、ASM disk groups概念的基础上的。

几个ASM disk构成一个ASM disk group。与LVM类似，一个ASM disk就相当于LVM里的一个physical volume。与LVM不同的是，共享一个共同的故障点(例如磁盘控制器)的几个ASM disk可以组成一个failure group。一个ASM disk group可以用来存储物理数据库结构：数据文件、控制文件、redo日志和其他一些文件类型。与linux里的逻辑卷管理器(LVM)相比较，disk group上面没有再创建逻辑卷，取而代之的是，数据库中的所有文件进行了逻辑分组放在disk group上的一个目录里。ASM中不需要文件系统，这也是为何ASM相对传统的LVM更具性能优势。

ASM disk是ASM的基本组成单位。当一块ASM候补磁盘被添加到磁盘组中时，元数据信息被写入到它的头部，使得ASM实例能认出这块磁盘并挂载到磁盘组中。在存储阵列中，磁盘故障经常发生。个别磁盘被高强度使用，它们发生故障是很正常的。大多数情况下，磁盘阵列能根据使用的保护级别，通过镜像磁盘或奇偶校验信息来恢复发生故障的磁盘数据。

ASM中的磁盘故障不经常发生，因为大多数情况下都是使用经过磁盘阵列保护的LUN。但是，如果当一个ASM保护的磁盘组中的磁盘发生了故障，需要紧急替换故障的磁盘以免它被丢弃。在ASM 11.1中引入一个新的参数叫做磁盘修复时间(disk repair time)，使管理员可以修复短暂的磁盘故障，而不需要进行一个全局的调整操作。当一个磁盘被从一个磁盘组中添加或删除时，会发生重新调整操作，对磁盘组中的成员重新进行条带。根据ASM磁盘组的大小，这个调整可能会很耗时。若管理员能幸运地在重新调整操作发生之前使故障的ASM磁盘回到磁盘组中，磁盘组将能很快恢复到正常状态，因为只需要应用有数据改变的区域(dirty region)的日志即可，不需要对整体全新进行调整。

根据存储后台的使用，LUN可以通过阵列的RAID级别得到保护，也可以是一个没有经过保护的存储的集合(JBOD)。

ASMLib和udev都解决了设备名固定的问题。在linux中，设备的检测和枚举的顺序并不是固定的。这和在Solaris中不一样，举个例子，除非一个磁盘在阵列中从物理上移动了，否则设备名(例如c0t0d1p1)不会改变。没做多路径的存储阵列的重新配置在linux中会有很大的问题：一个设备原先在操作系统中显示为/dev/sda可能会在重启后被重新映射为/dev/sdg，仅仅是因为操作系统检测到它比上一次启动时晚了一点。基于设备名的裸设备映射注定是要失败的。

首先看看udev的解决方法。一个SCSI设备的world-wide-ID(WWID)不会发生改变，在udev中利用了这一点制定一个规则，这个规则创建一个映射，它定义设备/dev/raw/raw1总是指向SCSI ID是xxxx的LUN中。udev的主要问题是，它的配置不够直观和易用。由于udev不能复制配置，在集群中的每个节点上管理员都需要去维护udev配置。(我们可以使用udevinfo -q path -n dev/sda1 来查看/dev/sda1对应的udev设备名，该路径在/sys下)

配置了多路径的存储则不会有这个问题，因为另一个软件层(比如，devicemapper-multipath包)或供货商指定的软件会创建一个逻辑设备。

ASMLib提供了另一种方式。ASMLib工具可以在http://oss.oracle.com中免费下载，它使ASM磁盘的管理变得非常简单。ASMLib由3个RPM包组成：一个内核模块、实际ASMLib和支持工具。在使用一个LUN作为ASM disk前，你可以使用ASMLib工具通过将元数据信息添加到磁盘头部来标记它，然后ASMLib就可以识别出这个新的LUN，将其作为添加到ASM disk group的一个可能的候选。重启的时候，ASMLib将扫描磁盘头部的信息来识别ASM disk，不管物理设备名在启动过程中变成了什么。它保证了设备名的稳定性，而且成本非常低。ASMLib是一个内核模块，在内部分配自己的内存结构，它可以在单路径和多路径下配置。

Failure group是一个逻辑的磁盘组，当其中一个组件发生故障，整个磁盘组都将不可用。打个比方，属于一个SCSI控制器的磁盘组成一个failure group，如果这个控制器发生故障，所有的磁盘都不可用。在normal和high冗余中，ASM使用failure group来存储数据的镜像拷贝。如果没有明确配置，每个ASM disk组成自己的failure group。Normal redundancy磁盘组需要由至少2个failure group来组成，high redundancy磁盘组需要至少3个。然后，建议使用比这个最小值更多的fail group来提供额外的数据保护。

ASM默认从一个ASM disk group中的primary extent中读取，在一个extended distance集群中，如果primary extent在远程的存储阵列上，可能会导致性能问题。ASM 11.1引入了一个首选的镜像读取来解决这个问题：每个ASM实例都可以被指定从本地extent的拷贝中读取，不管它是primary extent还是copied extent。