Oracle 11g RAC SCAN ip的原理及配置

SCAN概念
先介绍一下什么叫SCAN，SCAN(Single Client Access Name)是Oracle从11g R2开始推出的，客户端可以通过SCAN特性负载均衡地连接到RAC数据库。SCAN提供一个域名来访问RAC，域名可以解析1个到3个（注意，最多3 个）SCAN IP，我们可以通过DNS或者GNS来解析实现。其中DNS大家都很熟悉，这里不多说。GNS(Grid Naming Service)则是Oracle 11g R2的新功能，可以通过DHCP服务为节点和SCAN分配VIP和SCAN IP。另外还有个优点是，对于新加入集群的节点，它会自动分配VIP地址，更新集群资源，客户端依然通过SCAN特性负载均衡地连接到新增集群节点上。 DNS和GNS配置与解析相关内容在下面还有说明。
除了DNS和GNS解析方法外，SCAN也可以使用 hosts文件来解析，但用过的人都知道，此方法不仅在安装RAC的时候产生问题，后期使用也是存在问题的，比如SCAN域名只能定义一个SCAN IP。所以这种方法也是Oracle不推荐使用的。但尽管如此，我见过很多生产上依然这样使用，也就是废弃了11g的新特性SCAN，而是依然采用VIP 连接方式。

备注：有人可能会注意到《此方法不仅在安装RAC的时候产生问题》这句，RAC安装的时候的确会报错，但这并不影响后期Oracle的使用。

SCAN最明显的优点就是，当集群中新增加了节点或者删除了节点，不需要额外维护客户端。

PUBLIC IP, PRIVATE IP, VIP, SCAN VIP, GNS VIP, LOCAL_LISTENER, REMOTE_LISTENER , LOCAL LISTENER, SCAN LISTENER
在RAC部署的时候，我们都会接触到PUBLIC IP、PRIVATE I、VIP等等，那下面就针对它们进行介绍。
PUBLIC IP : 这是我们网卡上配置的真 实IP地址，我们称为公共IP，这个IP的存在关系到下面介绍的VIP能不能正确漂在其所在网卡上。注意，PUBLIC IP是不提供给客户端去连接配置的，这并不是说通过PUBLIC IP无法连接实例，而是它会存在节点服务器宕机的时候所有向它请求的客户端都会有等待现象并且最后得到超时信息的缺点。

PRIVATE IP : 称为私网IP（私有IP），它是用于心跳同步的，也就是保证两台服务器数 据同步。说道私网IP，我简单说下Oracle另一个高可用性连接特性 –HAIP。其实Cache Fusion会消耗节点服务器很大的私网资源，另外，私网间无法通信还会引起brain split(脑裂)，以前为解决这种问题，我们可以采用网卡bonding技术，而Oracle在11g R2的时候HAIP技术来实现，HAIP(Highly Available Virtual IP)用于节点间的私网通信，支持同时使用多个网络连接来满足网卡间的负载均衡，并且还提高了Cache Fusion资源通信能力。HAIP技术并不是主要内容，所以在这里点到为止。

VIP : RAC 的每个节点都需要有一个虚拟IP，这就是VIP。VIP需要和PUBLIC IP同一个子网，它们是由GI的Clusterware来管理的。VIP在其节点服务器发生故障的时候会自动漂移到另外正常的节点服务器上，如果RAC是 多个节点运行的，那具体漂移到哪个活动的节点将由Clusterware决定。VIP发生漂移现象之后，其当前的节点服务器LOCAL LISTENER是不会监听它的请求的，所以有客户端向这个VIP发送请求时，Clusterware的FAN会通知客户端向别的VIP发送请求，客户端 收到通知后通过Failover机制把请求重新发送到ADDRESS列表中的其他VIP上。虽然有这种较复杂的过程，但始终对客户端是透明进行的，而且这 个过程完成时间非常短暂，客户端也就几乎感受不到有节点宕机。等故障节点恢复正常，漂移的VIP也回到此节点上，继续提供服务。

SCAN VIP : SCAN VIP就是我在刚开始常说的SCAN IP，也就是由DNS或者GNS、hosts解析出来的IP地址。上面也说过，SCAN VIP最多能有三个，它们循环地被客户端所请求到。这里大家可能会存在这样的问题，SCAN VIP只有三个，那RAC是四节点或更多的节点情况怎么办？存在这种问题的原因归咎于对SCAN VIP的了解不足。其实，SCAN VIP数量和节点数是没有任何关系的，SCAN VIP会落到哪个节点上都是随机的。

GNS VIP : GNS VIP同SCAN VIP，也是Oracle从11g R2开始提供的。GNS VIP是提供GNS服务的IP地址，它绑定到某个节点的PUBLIC IP所在网卡上，当节点出现故障，GNS资源会自动切换到其他正常的节点继续提供GNS解析服务。如果我们不使用GNS解析方法，那么也不会存在GNS VIP。

LOCAL LISTENER : 本地监听器，RAC的每个节点上都会有独立的本地监听器， 它会监听该节点的PUBLIC IP和VIP，而每个节点的实例在启动的时候也向本地监听器进行注册，当然它也会向SCAN监听器注册，当VIP或者PUBLIC IP(这种情况比较少见)有连接请求的时候，本地监听器就接受处理并和本地实例建立连接。如果某个节点故障，其上面的VIP会进行漂移，但本地监听器并不 会产生漂移。

SCAN LISTENER : SCAN监听器，它是实现SCAN负载均衡的原理所在。如 果RAC上有三个SCAN VIP，那么SCAN监听器也有三个，它们各自监听SCAN VIP的连接请求。SCAN监听器跟着SCAN VIP随机分配到节点服务器上，如果某个节点发生故障，运行在此节点上的SCAN VIP会进行漂移，这时候SCAN监听器也跟着漂移到正常的节点上，继续为SCAN VIP监听连接请求，当PMON进程下次动态更新实例信息到该SCAN监听器之后，它又重新接受客户端的连接。这和VIP产生漂移的时候是有所区别的。

LOCAL_LISTENER : 这是Oracle的参数，这个参数控制着本地监听器的注册，因为本地监听器的工作机制关系，通过本地监听器的数据库连接请求只会连接到本地节点的实例上。

REMOTE_LISTENER :  同LOCAL_LISTENER是Oracle的参数，通过这个设置，任何实例都会向SCAN监听器注册，所以SCAN监听器能够负载均衡地分发连接请求到节点本地监听器上，也就是连接到其本地节点上实例上。

关于LOCAL_LISTENER与REMOTE_LISTENER的配置，在下面讲动态注册的时候再看一下。

SCAN解析与配置
SCAN是在安装GI(Grid Infrastructure)时配置的，作为Clusterware资源被管理。
忽略hosts解析之后，有两种方式配置和解析SCAN: DNS和GNS(Grid Naming Service)。

这里重点说一下DNS解析SCAN方式
使用DNS解析SCAN的时候，DNS服务器会采用 rr(round-robin)的方式循环解析为它准备的3个IP地址，与Oracle 11g R2的客户端配合使不同的客户端能够连接到不同的SCAN Listener上，这相当于是Oracle 10g中配置的客户端负载均衡（通过LOAD_BALANCE=yes配置）。

下面看一下客户端通过SCAN连接到数据库的过程， 首先由DNS服务器解析SCAN名称，DNS服务器返回SCAN对应的3个IP地址的列表，客户端会选择使用其中一个SCAN VIP地址作为连接地址，将命名方法解析后的连接信息发送到SCAN VIP对应的SCAN Listener上，SCAN Listener通过负载均衡机制再把请求转发给比较空闲的服务器上的本地监听器，由本地监听器完成实例与客户端之间的连接。

使用SCAN连接数据库实例，整个过程实现了客户端 的Failover(Oracle 10g R2是通过FAILOVER=on来配置)，DNS服务器返回的是一个SCAN VIP列表，客户端会选择其中一个连接到RAC，如果这个IP地址不能正常访问，客户端会选择另一个IP地址继续连接，直到所有的地址都不能正常连接，才 返回错误给客户端，整个过程对客户端程序来说依然是透明的。

需要注意的是，使用SCAN连接到数据库，不再需要客户端能解析节点的PUBLIC IP和VIP，只需要客户端能够通过DNS服务器正常解析SCAN就可以了。负载均衡工作交给服务器端的SCAN实现。

至于GNS解析SCAN，因为目前GNS服务存在不稳定的情况，也很少有企业将其投入到生产环境使用，而且其工作原理也较为复杂，所以在这里并不深入说明。

SCAN概念：
    先介绍一下什么叫SCAN，SCAN(Single Client Access Name)是Oracle从11g R2开始推出的，客户端可以通过SCAN特性负载均衡地连接到RAC数据库。所以在Oracle 11gR2 中，引入了SCAN（Single ClientAccess Name）的特性。SCAN是一个域名，可以解析至少1个IP，最多解析3个SCAN IP，客户端可以通过这个SCAN 名字来访问数据库，另外SCAN ip必须与public ip和VIP在一个子网。
SCAN提供一个域名来访问RAC，域名可以解析1个到3个（注意，最多3个）SCAN IP，我们可以通过DNS或者GNS来解析实现。其中DNS大家都很熟悉，这里不多说。GNS(Grid Naming Service)则是Oracle 11g R2的新功能，可以通过DHCP服务为节点和SCAN分配VIP和SCAN IP。另外还有个优点是，对于新加入集群的节点，它会自动分配VIP地址，更新集群资源，客户端依然通过SCAN特性负载均衡地连接到新增集群节点上。DNS和GNS配置与解析相关内容在下面还有说明。
     除了DNS和GNS解析方法外，SCAN也可以使用hosts文件来解析，但用过的人都知道，此方法不仅在安装RAC的时候产生问题，后期使用也是存在问题的，比如SCAN域名只能定义一个SCAN IP。所以这种方法也是Oracle不推荐使用的。
但尽管如此，很多生产上依然这样使用，也就是废弃了11g的新特性SCAN，而是依然采用VIP连接方式。

SCAN ip 工作原理：

启用SCAN 之后，会在数据库与客户端之间，添加了一层虚拟的服务层，就是SCAN IP和SCAN IP Listener，在客户端仅需要配置SCAN IP的tns信息，通过SCANIP Listener，连接后台集群数据库。这样，不论集群数据库是否有添加或者删除节点的操作，均不会对客户端产生影响，也就不需要修改配置。

配置SCAN有3种方法：
1. 使用/etc/hosts文件
这个是我们目前用的最多的方式，但是缺点只能对应一个SCAN IP，该方法Oracle 不推荐，但是简单，不需要单独的DNS 服务器，使用该方法，客户端还是需要VIP来链接。 Oracle 推荐使用其他的2种方法来实现SCAN 功能。
2. 在DNS中定义域名，只需要在DNS中配置即可实现SCAN 功能。

3. 通过Grid Naming Server（GNS），需要配置DNS 和DHCP才能实现SCAN 功能。

配置好之后，直接在客户端的tnsnames里写SCAN NAME就可以了，如下：

RACSCAN =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan.gns.cndba.com)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = dave)

)

)

 

以后RAC 增加删除节点，客户端都不需要修改。

实例的动态注册
上面已经介绍了LOCAL_LISTENER和REMOTE_LISTENER两个和动态注册有关的参数，那我们看看它们在数据库中的表现形式：
本地监听器注册是由实例的LOCAL_LISTENER参数所控制的：
SQL> set line 150
SQL> show parameter local_listener

NAME                                 TYPE                   VALUE
———————————— ———————- ——————————
local_listener                       string                 (DESCRIPTION=(ADDRESS_LIST=(AD
                                                            DRESS=(PROTOCOL=TCP)(HOST=192.
                                                            168.0.194)(PORT=1521))))
– 这是我管理的一套RAC上的配置，当然我已经处理好IP地址了。

LOCAL_LISTENER设置为向本地VIP地址进行注册，由于本地监听器是在本地的PUBLIC IP和VIP上监听，所以向VIP监听注册就能保证成功向本地监听器注册。

查看本地监听器的状态：
[grid@pos2 ~]$ lsnrctl status listener

LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 23-OCT-2012 12:01:21

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))
STATUS of the LISTENER
————————
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 – Production
Start Date                19-JUL-2012 15:31:45
Uptime                    95 days 20 hr. 29 min. 35 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/11.2.0/grid/network/admin/listener.ora
Listener Log File         /u01/app/grid/diag/tnslsnr/pos2/listener/alert/log.xml
Listening Endpoints Summary…
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.0.192)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.0.194)(PORT=1521)))
Services Summary…
Service "+ASM" has 1 instance(s).
  Instance "+ASM2", status READY, has 1 handler(s) for this service…
Service "pos" has 1 instance(s).
  Instance "pos2", status READY, has 1 handler(s) for this service…
Service "posXDB" has 1 instance(s).
  Instance "pos2", status READY, has 1 handler(s) for this service…
The command completed successfully
– 这里注意：查看本地监听器信息的时候每个节点只能看到其上运行的实例。

SCAN监听器的注册是由REMOTE_LISTENER参数控制的，任何实例都会向所有的SCAN监听器注册：
SQL> show parameter remote_listener

NAME                                 TYPE                   VALUE
———————————— ———————- ——————————
remote_listener                      string                 pos-cluster-scan:1521

下面是LISTENER_SCAN1的一个状态信息，当然你也可以查看LISTENER_SCAN2和LISTENER_SCAN3的状态。
[grid@pos2 ~]$ lsnrctl status listener_scan1

LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 23-OCT-2012 12:06:56

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))
STATUS of the LISTENER
————————
Alias                     LISTENER_SCAN1
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 – Production
Start Date                19-JUL-2012 15:31:45
Uptime                    95 days 20 hr. 35 min. 10 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/11.2.0/grid/network/admin/listener.ora
Listener Log File         /u01/app/11.2.0/grid/log/diag/tnslsnr/pos2/listener_scan1/alert/log.xml
Listening Endpoints Summary…
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_SCAN1)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.0.195)(PORT=1521)))
Services Summary…
Service "pos" has 2 instance(s).
  Instance "pos1", status READY, has 1 handler(s) for this service…
  Instance "pos2", status READY, has 1 handler(s) for this service…
Service "posXDB" has 2 instance(s).
  Instance "pos1", status READY, has 1 handler(s) for this service…
  Instance "pos2", status READY, has 1 handler(s) for this service…
The command completed successfully

由于任何实例启动都会向所有的SCAN监听器动态注册，从LISTENER_SCAN1的SCAN监听器运行状态来看，SERVICE pos包括了所有的实例名称。

就像我昨天回答那位朋友的时候简单说“是通过内部机制”一样，大家可能看到上面的内容并不知道SCAN监听器如何找到比较空闲的实例的。
其实SCAN监听器是实时了解所有实例的运行情况的，因此它能够准确地将连接重定向到空闲服务器的本地监听器上。

下面我们通过日志查看实例的动态注册与动态更新

1）本地监听器动态注册日志：

[grid@pos2 ~]$ cd $ORACLE_BASE/diag/tnslsnr/pos2/listener/alert

[grid@pos2 alert]$ grep service_register log_1.xml | head -3

 <txt>18-JUN-2012 13:58:23 * service_register * LsnrAgt * 0

 <txt>18-JUN-2012 13:58:30 * service_register * +ASM2 * 0

 <txt>18-JUN-2012 15:54:15 * service_register * pos2 * 0

-- 之所以选择log_1.xml历史文件是因为发现我的log.xml里基本都是更新日志，没有注册日志。

 

2）本地监听器动态更新日志：

[grid@pos2 alert]$ grep service_update log.xml | head -3

 <txt>16-OCT-2012 16:07:09 * service_update * pos2 * 0

 <txt>16-OCT-2012 16:07:33 * service_update * pos2 * 0

 <txt>16-OCT-2012 16:08:03 * service_update * pos2 * 0

 

3）SCAN监听器动态注册日志：

[grid@rac1 ~]$ cd $ORACLE_BASE/diag/tnslsnr/rac1/listener_scan2/alert/

[grid@rac1 ~]$ grep service_register log.xml | head -3

 <txt>13-AUG-2012 05:25:00 * service_register * LsnrAgt * 0

 <txt>13-AUG-2012 20:29:07 * service_register * luocs1 * 0

 <txt>13-AUG-2012 20:58:05 * service_register * luocs1 * 0

-- 这是我另一套测试RAC环境。

 

4）SCAN监听器动态更新日志：

[grid@rac1 ~]$ grep service_update log.xml | head -3

 <txt>13-AUG-2012 20:29:19 * service_update * luocs1 * 0

 <txt>13-AUG-2012 20:30:19 * service_update * luocs1 * 0

 <txt>13-AUG-2012 20:30:46 * service_update * luocs1 * 0

注意，如果你的RAC是通过hosts解析了SCAN域名的，那么系统里就找不到上面的SCAN监听器日志的路径。

实例的动态注册和动态更新过程是由实例的PMON进程完成的，正是因为SCAN监听器能够实时了解实例的负载情况，所以SCAN监听器能够负载均衡地将连接请求转发给合适实例的本地监听器来处理。