Oracle_11gR2_SCAN_详解
在Oracle 11gR2以前,如果数据库采用了RAC 架构,在客户端的tnsnames 中,需要配置多个节点的连接信息,从而实现诸如负载均衡,failover 等等RAC 的特性。因此,当数据库RA
在Oracle 11gR2以前,如果数据库采用了RAC 架构,在客户端的tnsnames 中,需要配置多个节点的连接信息,从而实现诸如负载均衡,failover 等等RAC 的特性。因此,当数据库RAC 集群需要添加或删除节点时,需要及时对客户端机器的tns 进行更新,以免出现安全隐患。 在11gR2中,为了简化该项配置工作,引入了SCAN (Single Client Access Name)的特性,该特性的好处在于,在数据库与客户端之间,添加了一层虚拟的服务层,就是所谓的scan ip 以及scan ip listener ,在客户端仅需要配置scan ip的tns 信息,通过scan ip listener,连接后台集群数据库。这样,不论集群数据库是否有添加或者删除节点的操作,均不会对client 产生影响。
下面,具体介绍下SCAN (Single Client Access Name)的架构以及配置。
首先,简要的看下在11gR2中,安装RAC 发生的巨大变化,在10g 以及11gR1的时代,安装RAC 的步骤是先安装CRS ,再安装DB ,而到了11gR2的时代,crs 与asm 被集成在一起,合称为GRID ,必须先安装GRID 后,才能继续安装DB ,否则,你就跟11gR2的RAC 无缘咯,呵呵。
而被11gR2引入的SCAN ,就是包含在安装grid 的过程中。SCAN 的定义,有两种途径:
1. 在DNS 中定义域名。
2. 通过oracle 提供的Grid Naming Server(GNS)实现DHCP
,自定义。
如果通过dns 来定义,则需要在网络中定义3个SCAN IP地址,指向同一个域名,这3个ip 地址必须处于同一个子网内,同时域名不能太长,否则您打字也麻烦不是,哈哈。另外,SCAN IP是由oracle clusterware 管理的,因此在主机的集群软件(如IBM HACMP,HP SERVICE GUARD)中不能将此ip 配置进去,类似于10g 中的vip ,在grid 安装前,此IP 是无法ping 通的。
范例:
scan-ip.dbaleading.com IN A 192.168.1.111
IN A 192.168.1.112
IN A 192.168.1.113
如果使用GNS 的方式,则必须有DHCP 服务,在cluster 的配置过程中,将会自动向DHCP 服务器申请3个IP 地址作为SCAN IP使用。
除了SCAN IP,在cluster 的配置过程中,SCAN IP LISTENER服务也会被建立,每个SCAN IP对应一个SCAN IP LISTENER,并且,为了提升高可用性,3个SCAN IP以及其对应的SCAN IP
LISTENER 将被独立的分配到各个节点上。如果cluster 中其中某个运行scan ip 的节点出现异常,则其余两个正常的scan ip 节点将自动接管。注意,此处有个注意点,如果客户端是11gR2的版本,则客户端只需在tns 中配置域名解析,即可实现failover ,如果客户端版本低于11gR2,则无法通过域名解析出3个SCAN IP 地址,因此如果要实现
,failover ,必须在客户端的tns 中配置3个SCAN IP 的地址进行解析,这也是为何oracle 强烈建议在使用11gR2数据库时,客户端也最好使用11gR2的原因。
范例:
$srvctl config scan_listener
SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521 SCAN Listener LISTENER_SCAN2 exists. Port: TCP:1521 SCAN Listener LISTENER_SCAN3 exists. Port: TCP:1521 $srvctl config scan SCAN name: scan-ip, Network:
1/192.168.1.0/255.255.255.0/
SCAN VIP name: scan1, IP:
/scan-ip.dbaleading.com/192.168.1.111
SCAN VIP name: scan2, IP:
/scan-ip.dbaleading.com/192.168.1.112
SCAN VIP name: scan3, IP:
/scan-ip.dbaleading.com/192.168.1.113
上回中,介绍了11gR2中 SCAN IP 的配置,以及 SCAN IP LISTENER 的配置及其作用。本章中,我们来详细了解下,SCAN IP 在数据库中的配置方法,以及如何用SCAN IP,配置oracle 所谓的自动负载平衡(该功能的实际使用,我们将在后续的章节中详细讨论)。
看了第一篇中的SCAN IP 介绍,相信很多朋友都有这样一个疑问,既然SCAN IP 是跟数据库instance 无关的,例如一个12节点的RAC 或者24节点的RAC ,
,都只有3个SCAN IP ,并且SCAN IP 是随机分布在各个instance 的,那么,SCAN IP LISTENER如何监听各个节点的数据库呢,同时,该怎么配置哪个instance 去哪个SCAN IP LISTENER注册呢。下面将一一解答。
首先,补充一个概念,在11gR2中,SCAN IP是作为一个新增IP 出现的,原有的CRS 中的VIP 仍然存在,从这里,就能看出一点端倪,在11gR2的RAC 架构中,SCAN IP 并非独立存在的,而是和原有的 VIP结合在一起的。那么他们是如何工作的呢,先来看下下面这个工作原理图:
从这个原理图,可以看出,scan ip其实是ora cle在客户端与数据库之间,新加的一个连接层,当有客户端访问时,连接到 SCAN IP LISTENER, 而SCAN IP LISTENER接收到连接请求时,会根据 LBA 算法(所谓LBA 算法,就是least loaded instance),将该客户端的连接请求,转发给对应的instance 上的VIP LISTENER,从而完成了整个客户端与服务器的连接过程。简化如下: client -> scan listener -> local listener -> local instance
了解了这个过程以后,对SCAN IP 的整体架构,就全部清楚了。剩下的,我们再来讲一些技术细节。
SCAN IP 和 SCAN LISTENER 是独立于RAC 的各个节点的,而每个节点的 VIP ,
,VIP LISTENER 是跟instance 绑定的,每个节点的VIP LISTENER ,会监听自己所属节点的instance 。
因此,在数据库中,我们需要设置remote_listener参数,这个参数设置很有讲究,因为scan ip有3个,scan listener也有三个,但是他们对应的是同一个域名,因此,在数据库中,我们需要使用easy connect naming method方式,就是在sqlnet.ora 的配置文件中,必须有
NAMES.DIRECTORY_PATH=(tnsnames,ezconnect)存在。
另外,配置remote_listener的方式也有讲究,以前的版本中,我们通常是在tnsnames.ora 中写好remote_listener的地址以及端口,但是对于scan listener ,不能这么做,必须按照标准格式,设置成REMOTE_LISTENER=SCAN:PORT的形式,以我的测试系统为例,就是
REMOTE_LISTENER=scan-ip.dbaleading.com:1521,而不需要在tnsnames.ora 中进行额外设置。
经过以上设置后,RAC 数据库的每个节点的PMON 进程,会用广播的方式向每个SCAN LISTENER 进行注册,同时CRS 的后台进程ONS ,会采集各个节点的负载状况,通知scan listener,以便scan listener根据负载情况,将新连接分配到当前负载最低的节点上。
以上,就是11gR2 RAC中,新增的SCAN IP 以及 SCAN LISTENER的全部内容了,在下面一章中,我们将针对该新特性,开展一些拓展性的思考以及讨论。