Oracle 11g RAC features

  1. 云栖社区>
  2. 博客>
  3. 正文

Oracle 11g RAC features

cloud_ruiy 2015-01-19 14:58:00 浏览1044
展开阅读全文

<一,>

oracle 11g r2 RAC提供了以下功能:

  1. 高可用:shared-everything 模式保证了单节点的故障不会停止服务,集群中的其他节点将快速接管
  2. 可扩展性:多节点分担负载,可以提供远超单机数据库能提供的处理能力。且增删节点可以在线完成,不需要停机
  3. 易用性:多个数据库可以加入到一个集群中
  4. 低成本:RAC可以部署在标准硬件上,硬件上节省的成本抵消了购买license的成本
Oracle 11g r2 还提供了一个叫RAC One Node的新功能。Oracle发现一些RAC的部署纯粹只是为了高可用,而虚拟化越来越多的被用户所使用,并成为了一个新的趋势。Oracle One Node建立在以下基础之上:Oracle Clusterware、Oracle ASM、Oracle database。
 
我们再来看一眼RAC的结构图
相比较单机数据库,RAC需要一个共享存储;一个私有网络来进行集群内部通讯;一个公有网络来连接应用和客户端;配置虚拟IP来提高节点故障时的连接速度,当一个节点出现故障,它的虚拟ip立即指向其他节点的ip上(若不配置vip,当一个节点发生故障时,新的连接将会发生等待,直到与该节点ip的通讯出现time out)
 

Failover的连接配置

 
有两种连接方式可以实现数据库连接的failover
 

1. TAF(Transparent Application Failover)

让我们看一下官方文档。TAF让Oracle Net将一个失效的连接从故障点转移到另一个监听上,用户能使用这个新的连接来继续未完成的工作,这是一个client端的功能。
TAF可以配置为使用client端的(Transparent Network Substrate)TNS连接字符串来连接,或者使用server端的服务。如果两种方式同时使用,则使用server端的服务配置。
TAF可以工作在两种模式下:session failover和select failover。前者在failover时会重建失败的连接,后者则能够继续进程中未完成的查询(如果failover前一个session正在从一个 游标中获取数据,则新的session将在相同的snapshot下重新运行select语句,并返回余下的行)。如果failover 时,session执行了DML操作且未提交,则failover后,若不执行rollback回滚而执行新的操作,将会收到一条错误信息ORA-25402: transaction must roll back
TAF在dataguard中使用,可以自动进行failover
 
一个典型的使用了TAF的TNS连接串如下:
NEWSDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dyora)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
(RETRIES = 180)
(DELAY = 5)
)
)
)
 
failover_mode参数 说明
BACKUP 备用连接的网络服务名。若使用了preconnect的连接方法,则需要指定这个参数
DELAY 连接重试的时间间隔(秒)。如果指定了RETRIES参数,若不指定该参数,默认为1秒。若注册了callback,该参数将被忽略
METHOD 设置failover方法。basic: failover时才尝试连接备用实例的监听;preconnect: 每次连接数据库时,都会在备用实例上也产生一个连接,以实现更快的切换
RETRIES failover后,尝试连接的次数。如果指定了DELAY参数,则RETRIES默认为5次。若注册了callback,则该参数将被忽略
TYPE OCI默认提供了3种类型:session: 若用户连接丢失,将在备用节点上重新创建;select: 除了重建连接外,将继续从打开的游标中获取数据,如果采用这种方式,普通select操作也将在客户端产生开销;none: 默认值,也可显示指定来禁用failover功能

2. FCF(Fast Connect Failover)

oracle11g提供了FCF方式连接数据库,它支持JDBC Thin和JDBC OCI驱动;与连接缓存(implicit connection cache)协同工作提供更高的连接性能和高可用;可以在应用代码中设置,无需另外配置
需要的条件:启用了隐含连接缓存,FCF需要与JDBC的连接缓存机制共同工作,为应用管理连接以确保高可用;应用使用服务名而非服务标识符来连接数据库;JDBC运行的节点上配置并启用了Oracle Notification Service (ONS);JDBC例程运行的java虚拟机必须包含oracle.ons.oraclehome并指向ORACLE_HOME
例子:
配置ONS
ods.setONSConfiguration("nodes=racnode1.example.com:4200,racnode2.example.com:4200");
启用FCF
// declare datasource
ods.setUrl(
"jdbc:oracle:oci:@(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=cluster_alias)
(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service_name)))");
ods.setUser("scott");
ods.setConnectionCachingEnabled(true);
ods.setFastConnectionFailoverEnabled(true):
ctx.bind("myDS",ods);
ds=(OracleDataSource) ctx.lookup("MyDS");
try {
ds.getConnection(); // transparently creates and accesses cache
catch (SQLException SE {
}
}
 
看糊涂了?上面的java代码包含一个异常处理。工作过程如下:
1. 一个实例宕掉了,在缓存中留下一些过期连接
2. RAC产生一个事件,并将其发送给包含JDBC的java虚拟机
3. JVM中的后台线程找出所有受到该RAC事件影响的所有连接,通过sql异常(ORA-17008)通知它们关闭连接,并回滚事务
4. 连接接收到sql异常并重新执行失败的操作
 
FCF与TAF相比有如下不同:
1. FCF支持应用级别的连接重试,由应用来决定failover时如何处理,是重新执行,还是抛出异常;TAF只能在OCI/NET的层面进行重新连接
2. FCF与连接缓存很好地结合起来,让连接缓存管理器来管理缓存,失败的连接在缓存中会自动失效。而TAF在网络层面做预连接,当一个连接失效,连接缓存不能检测到
3. FCF基于Oracle RAC事件,可以快速为活跃/闲置的连接检测到故障
4. FCF通过实例的UP事件实现负载均衡,分配到在线的RAC实例中
 
oracle建议不要在一个应用中同时使用TAF和FCF
<二,>
 http://blog.sina.com.cn/s/blog_5fe8502601016atb.html
<三,>

Grid Infrastructure共享组件

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

OCR和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。

配置Voting Disks

 
若一个节点在指定时间内(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

 

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更具性能优势。

Grid Infrastructure引入了ASM集群文件系统(ACFS),消除了存储通用用途文件的限制。ASM使用stripe-and-mirror-everything方式来提供最佳性能。

ASM和ACFS的使用不受集群的限制;单实例oracle同样可以通过它得到很多好处。技术上,Oracle ASM被应用为一种特殊的Oracle实例,它有自己的SGA,但没有持续的字典。在RAC中,每个集群节点有且只有一个单独的ASM实例。当启动的时候,每个实例会通过集群软件中的初始化参数在Grid Infrastructure检测到ASM磁盘组资源。每个实例将挂载这些磁盘组。通过赋予正确的权限(ASM11.2中引入了访问控制列表 (ACLs))数据库可以访问它们自己的数据文件。使用ASM需要应用OMF,这意味着不同的数据库文件管理方式。RDBMS实例中的初始化参数,例如 db_create_file_dest和db_create_online_dest_n,还有db_recovery_file_dest,指定了相 关的文件存储在哪个磁盘组中。当需要创建一个新的文件时,OMF将以以下格式来创建:+diskGroupName/dbUniqueName/file_type/file_type_tag.file.incarnation 给个例子:+DATA/oradb/datafile/users.293.699134381

ASM允许你执行许多在线操作,在ASM11.1及更高版本中,可以以滚动方式(rolling fashion)进行升级,最小化对数据库的影响。

ASM在裸分区级别上进行操作;为了降低产品系统的开销,应该避免使用LVM2逻辑卷。在NFS上ASM同样是被支持的。但是,代替直接挂载文件管理器给出的目录,需要用dd工具创建的零填补文件作为ASM卷。使用NFS的时候,你需要和供货商协商,让他们提供最佳实践的文档。

有特殊需求的环境,比如大于10TB数据量的海量数据库,可以在磁盘组级别从可定制的盘区(extent)大小上得到好处。一个通用的存储优化技术包括只使用磁盘边缘位置,比使用其他位置能提供更高的性能。ASM的智能数据分布允许管理员来定义具备更高速度和带宽的热点区域。经常访问的文件可以放置到这些位置来提高性能。硬盘制造商即将推出扇区大小为4k的硬盘,存储密度增加,且更快,容量更大。ASM为此做好了准备,它提供了磁盘组的一个属性,叫sector size,可以设置为512字节或4k。

大部分安装中,一个典型的工作流程:存储管理员提供集群的所有节点上用来做ASM disk的存储;系统管理员为这些新的块设备创建分区,做多路径配置,使用ASMlib或udev将这些分区后的块设备标记为候选磁盘;移交到数据库小组后,Oracle管理员可以配置ASM disk和ASM磁盘组。这些操作都可以在线完成,不需要重启服务器。

 

ASM disk

.
ASM disk是ASM的基本组成单位。当一块ASM候补磁盘被添加到磁盘组中时,元数据信息被写入到它的头部,使得ASM实例能认出这块磁盘并挂载到磁盘组中。在存储阵列中,磁盘故障经常发生。个别磁盘被高强度使用,它们发生故障是很正常的。大多数情况下,磁盘阵列能根据使用的保护级别,通过镜像磁盘或奇偶校验信息来恢复发生故障的磁盘数据。
ASM中的磁盘故障不经常发生,因为大多数情况下都是使用经过磁盘阵列保护的LUN。但是,如果当一个ASM保护的磁盘组中的磁盘发生了故障,需要紧急替换故障的磁盘以免它被丢弃。在ASM 11.1中引入一个新的参数叫做磁盘修复时间(disk repair time),使管理员可以修复短暂的磁盘故障,而不需要进行一个全局的调整操作。当一个磁盘被从一个磁盘组中添加或删除时,会发生重新调整操作,对磁盘组中的成员重新进行条带。根据ASM磁盘组的大小,这个调整可能会很耗时。若管理员能幸运地在重新调整操作发生之前使故障的ASM磁盘回到磁盘组中,磁盘组将能很快恢复到正常状态,因为只需要应用有数据改变的区域(dirty region)的日志即可,不需要对整体全新进行调整。
根据存储后台的使用,LUN可以通过阵列的RAID级别得到保护,也可以是一个没有经过保护的存储的集合(JBOD)。
 
************************************************************************************************************************************************************************************************
ASMLib和udev
 
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是一个内核模块,在内部分配自己的内存结构,它可以在单路径和多路径下配置。
************************************************************************************************************************************************************************************************
 

ASM Disk Group

 
ASM磁盘组有三个冗余级别:外部冗余;一般冗余;高度冗余
当创建一个外部冗余的磁盘组时,ASM让存储阵列来承担数据保护的责任,不会做任何的镜像。它会在磁盘组中的ASM disk间做默认盘区大小为1M的条带。写入错误会迫使ASM磁盘被卸载。这将产生严重的后果,因为该磁盘上的盘区没有任何可用的拷贝,整个磁盘组都会变得不可用。
在普通冗余级别下,ASM将条带和镜像每个盘区,在一个盘区写入到磁盘中时,会有另一个盘区写入另一个故障组来提供冗余。在ASM11.2中,单个的文件可以用来做条带和镜像;默认做一个双向的的镜像。普通冗余可以容忍磁盘组中的一个ASM磁盘发生故障。
高度冗余提供了更高级别的保护,它默认提供条带和镜像,创建主盘区的两个额外的拷贝,可以容忍磁盘组中两个ASM磁盘的故障。
 

Failure Group

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。

ASM安装与管理选项

 
在Oracle 11.1以前,最佳实践是以单独地安装ASM,这提供了可以单独升级集群软件和ASM的好处。比如,集群软件和ASM可以升级到11.1.0.7,而数据库还保留在原来的版本。这个最佳实践中,有三个标准的Oracle安装目录:集群软件、ASM、数据库
如果需要的话,ASM 11.1可以安装在与安装RDBMS不同的操作系统用户下,Oracle对此解释说,数据库与存储管理间的角色独立是很多站点的通用实践。
可以通过SQL*Plus、企业管理器(dbconsole)或者DBCA来管理ASM。
在Oracle 11g Release 2中,ASM现在已经是Grid Infrastructure的一部分,不管在单实例还是RAC环境中。一个新的配置助手asmca接受并扩展了11.1的DBCA中提供的功能。ASM也不再可以从RDBMS Oracle home以外的地方启动。asmca增加了对另一个叫做ASM Cluster File System的ASM新特性的支持。
一个叫SYSASM的新的超级用户角色的引入使角色分离成为可能,就像Oracle 9i以后的SYSDBA一样。你可以将SYSASM权限绑定在不同于SYSOPER和SYSDBA用户的角色中。

网友评论

登录后评论
0/500
评论
cloud_ruiy
+ 关注