SCAN 概念先介紹一下什么叫SCAN ，SCAN(Single Client Access Name)是Oracle 從11g R2開始推出的，客戶端可以通過SCAN 特性負(fù)載均衡地連接到RAC 數(shù)

SCAN 概念

先介紹一下什么叫SCAN ，SCAN(Single Client Access Name)是Oracle 從11g R2開始推出的，客戶端可以通過SCAN 特性負(fù)載均衡地連接到RAC 數(shù)據(jù)庫。SCAN 提供一個域名來訪問RAC ，域名可以解析1個到3個（注意，最多3個）SCAN IP，我們可以通過DNS 或者GNS 來解析實(shí)現(xiàn)。其中DNS 大家都很熟悉，這里不多說。GNS(Grid Naming Service)則是Oracle 11g R2的新功能，可以通過DHCP 服務(wù)為節(jié)點(diǎn)和SCAN 分配VIP 和SCAN IP。另外還有個優(yōu)點(diǎn)是，對于新加入集群的節(jié)點(diǎn)，它會自動分配VIP 地址，更新集群資源，客戶端依然通過SCAN 特性負(fù)載均衡地連接到新增集群節(jié)點(diǎn)上。DNS 和GNS 配置與解析相關(guān)內(nèi)容在下面還有說明。

除了DNS 和GNS 解析方法外，SCAN 也可以使用hosts 文件來解析，但用過的人都知道，此方法不僅在安裝RAC 的時候產(chǎn)生問題，后期使用也是存在問題的，比如SCAN 域名只能定義一個SCAN IP。所以這種方法也是Oracle 不推薦使用的。但盡管如此，我見過很多生產(chǎn)上依然這樣使用，也就是廢棄了11g 的新特性SCAN ，而是依然采用VIP 連接方式。

備注：有人可能會注意到《此方法不僅在安裝RAC 的時候產(chǎn)生問題》這句，RAC 安裝的時候的確會報錯，但這并不影響后期Oracle 的使用。

SCAN 最明顯的優(yōu)點(diǎn)就是，當(dāng)集群中新增加了節(jié)點(diǎn)或者刪除了節(jié)點(diǎn)，不需要額外維護(hù)客戶端。

PUBLIC IP, PRIVATE IP, VIP, SCAN VIP, GNS VIP, LOCAL_LISTENER, REMOTE_LISTENER , LOCAL LISTENER, SCAN LISTENER

在RAC 部署的時候，我們都會接觸到PUBLIC IP、PRIVATE I、VIP 等等，那下面就針對它們進(jìn)行介紹。 PUBLIC IP : 這是我們網(wǎng)卡上配置的真實(shí)IP 地址，我們稱為公共IP ，這個IP 的存在關(guān)系到下面介紹的VIP 能不能正確漂在其所在網(wǎng)卡上。注意，PUBLIC IP是不提供給客戶端去連接配置的，這并不是說通過PUBLIC IP 無法連接實(shí)例，而是它會存在節(jié)點(diǎn)服務(wù)器宕機(jī)的時候所有向它請求的客戶端都會有等待現(xiàn)象并且最后得到超時信息的缺點(diǎn)。

PRIVATE IP : 稱為私網(wǎng)IP （私有IP ），它是用于心跳同步的，也就是保證兩臺服務(wù)器數(shù)據(jù)同步。說道私網(wǎng)IP ，我簡單說下Oracle 另一個高可用性連接特性 – HAIP 。其實(shí)Cache Fusion會消耗節(jié)點(diǎn)服務(wù)器很大的私網(wǎng)資源，另外，私網(wǎng)間無法通信還會引起brain split(腦裂) ，以前為解決這種問題，我們可以采用網(wǎng)卡bonding 技術(shù)，而Oracle 在11g R2的時候HAIP 技術(shù)來實(shí)現(xiàn)，HAIP(Highly Available Virtual IP)用于節(jié)點(diǎn)間的私網(wǎng)通信，支持同時使用多個網(wǎng)絡(luò)連接來滿足網(wǎng)卡間的負(fù)載均衡，并且還提高了Cache Fusion資源通信能力。HAIP 技術(shù)并不是主要內(nèi)容，所以在這里點(diǎn)到為止。

VIP : RAC 的每個節(jié)點(diǎn)都需要有一個虛擬IP ，這就是VIP 。VIP 需要和PUBLIC IP同一個子網(wǎng)，它們是由GI 的Clusterware 來管理的。VIP 在其節(jié)點(diǎn)服務(wù)器發(fā)生故障的時候會自動漂移到另外正常的節(jié)點(diǎn)服務(wù)器上，如果RAC 是多個節(jié)點(diǎn)運(yùn)行的，那具體漂移到哪個活動的節(jié)點(diǎn)將由Clusterware 決定。VIP 發(fā)生漂移現(xiàn)象之后，其當(dāng)前的節(jié)點(diǎn)服務(wù)器LOCAL LISTENER是不會監(jiān)聽它的請求的，所以有客戶端向這個VIP 發(fā)送請求時，Clusterware 的FAN 會通知客戶端向別的VIP 發(fā)送請求，客戶端收到通知后通過Failover 機(jī)制把請求重

新發(fā)送到ADDRESS 列表中的其他VIP 上。雖然有這種較復(fù)雜的過程，但始終對客戶端是透明進(jìn)行的，而且這個過程完成時間非常短暫，客戶端也就幾乎感受不到有節(jié)點(diǎn)宕機(jī)。等故障節(jié)點(diǎn)恢復(fù)正常，漂移的VIP 也回到此節(jié)點(diǎn)上，繼續(xù)提供服務(wù)。

SCAN VIP : SCAN VIP就是我在剛開始常說的SCAN IP，也就是由DNS 或者GNS 、hosts 解析出來的IP 地址。上面也說過，SCAN VIP最多能有三個，它們循環(huán)地被客戶端所請求到。這里大家可能會存在這樣的問題，SCAN VIP只有三個，那RAC 是四節(jié)點(diǎn)或更多的節(jié)點(diǎn)情況怎么辦？存在這種問題的原因歸咎于對SCAN VIP的了解不足。其實(shí)，SCAN VIP數(shù)量和節(jié)點(diǎn)數(shù)是沒有任何關(guān)系的，SCAN VIP會落到哪個節(jié)點(diǎn)上都是隨機(jī)的。

GNS VIP : GNS VIP同SCAN VIP，也是Oracle 從11g R2開始提供的。GNS VIP是提供GNS 服務(wù)的IP 地址，它綁定到某個節(jié)點(diǎn)的PUBLIC IP所在網(wǎng)卡上，當(dāng)節(jié)點(diǎn)出現(xiàn)故障，GNS 資源會自動切換到其他正常的節(jié)點(diǎn)繼續(xù)提供GNS 解析服務(wù)。如果我們不使用GNS 解析方法，那么也不會存在GNS VIP。

LOCAL LISTENER : 本地監(jiān)聽器，RAC 的每個節(jié)點(diǎn)上都會有獨(dú)立的本地監(jiān)聽器，它會監(jiān)聽該節(jié)點(diǎn)的PUBLIC IP 和VIP ，而每個節(jié)點(diǎn)的實(shí)例在啟動的時候也向本地監(jiān)聽器進(jìn)行注冊，當(dāng)然它也會向SCAN 監(jiān)聽器注冊，當(dāng)VIP 或者PUBLIC IP(這種情況比較少見) 有連接請求的時候，本地監(jiān)聽器就接受處理并和本地實(shí)例建立連接。如果某個節(jié)點(diǎn)故障，其上面的VIP 會進(jìn)行漂移，但本地監(jiān)聽器并不會產(chǎn)生漂移。

SCAN LISTENER : SCAN 監(jiān)聽器，它是實(shí)現(xiàn)SCAN 負(fù)載均衡的原理所在。如果RAC 上有三個SCAN VIP，那么SCAN 監(jiān)聽器也有三個，它們各自監(jiān)聽SCAN VIP的連接請求。SCAN 監(jiān)聽器跟著SCAN VIP隨機(jī)分配到節(jié)點(diǎn)服務(wù)器上，如果某個節(jié)點(diǎn)發(fā)生故障，運(yùn)行在此節(jié)點(diǎn)上的SCAN VIP會進(jìn)行漂移，這時候SCAN 監(jiān)聽器也跟著漂移到正常的節(jié)點(diǎn)上，繼續(xù)為SCAN VIP監(jiān)聽連接請求，當(dāng)PMON 進(jìn)程下次動態(tài)更新實(shí)例信息到該SCAN 監(jiān)聽器之后，它又重新接受客戶端的連接。這和VIP 產(chǎn)生漂移的時候是有所區(qū)別的。

LOCAL_LISTENER : 這是Oracle 的參數(shù)，這個參數(shù)控制著本地監(jiān)聽器的注冊，因?yàn)楸镜乇O(jiān)聽器的工作機(jī)制關(guān)系，通過本地監(jiān)聽器的數(shù)據(jù)庫連接請求只會連接到本地節(jié)點(diǎn)的實(shí)例上。

REMOTE_LISTENER : 同LOCAL_LISTENER是Oracle 的參數(shù)，通過這個設(shè)置，任何實(shí)例都會向SCAN 監(jiān)聽器注冊，所以SCAN 監(jiān)聽器能夠負(fù)載均衡地分發(fā)連接請求到節(jié)點(diǎn)本地監(jiān)聽器上，也就是連接到其本地節(jié)點(diǎn)上實(shí)例上。

關(guān)于LOCAL_LISTENER與REMOTE_LISTENER的配置，在下面講動態(tài)注冊的時候再看一下。

SCAN 解析與配置

SCAN 是在安裝GI(Grid Infrastructure)時配置的，作為Clusterware 資源被管理。

忽略hosts 解析之后，有兩種方式配置和解析SCAN: DNS和GNS(Grid Naming Service)。

這里重點(diǎn)說一下DNS 解析SCAN 方式

使用DNS 解析SCAN 的時候，DNS 服務(wù)器會采用rr(round-robin)的方式循環(huán)解析為它準(zhǔn)備的3個IP 地

址，與Oracle 11g R2的客戶端配合使不同的客戶端能夠連接到不同的SCAN Listener上，這相當(dāng)于是Oracle 10g中配置的客戶端負(fù)載均衡（通過LOAD_BALANCE=yes配置）。

下面看一下客戶端通過SCAN 連接到數(shù)據(jù)庫的過程，首先由DNS 服務(wù)器解析SCAN 名稱，DNS 服務(wù)器返回SCAN 對應(yīng)的3個IP 地址的列表，客戶端會選擇使用其中一個SCAN VIP地址作為連接地址，將命名方法解析后的連接信息發(fā)送到SCAN VIP對應(yīng)的SCAN Listener上，SCAN Listener通過負(fù)載均衡機(jī)制再把請求轉(zhuǎn)發(fā)給比較空閑的服務(wù)器上的本地監(jiān)聽器，由本地監(jiān)聽器完成實(shí)例與客戶端之間的連接。

使用SCAN 連接數(shù)據(jù)庫實(shí)例，整個過程實(shí)現(xiàn)了客戶端的Failover(Oracle 10g R2是通過FAILOVER=on來配置) ，DNS 服務(wù)器返回的是一個SCAN VIP列表，客戶端會選擇其中一個連接到RAC ，如果這個IP 地址不能正常訪問，客戶端會選擇另一個IP 地址繼續(xù)連接，直到所有的地址都不能正常連接，才返回錯誤給客戶端，整個過程對客戶端程序來說依然是透明的。

需要注意的是，使用SCAN 連接到數(shù)據(jù)庫，不再需要客戶端能解析節(jié)點(diǎn)的PUBLIC IP和VIP ，只需要客戶端能夠通過DNS 服務(wù)器正常解析SCAN 就可以了。負(fù)載均衡工作交給服務(wù)器端的SCAN 實(shí)現(xiàn)。

至于GNS 解析SCAN ，因?yàn)槟壳癎NS 服務(wù)存在不穩(wěn)定的情況，也很少有企業(yè)將其投入到生產(chǎn)環(huán)境使用，而且其工作原理也較為復(fù)雜，所以在這里并不深入說明。

實(shí)例的動態(tài)注冊

上面已經(jīng)介紹了LOCAL_LISTENER和REMOTE_LISTENER兩個和動態(tài)注冊有關(guān)的參數(shù)，那我們看看它們在數(shù)據(jù)庫中的表現(xiàn)形式：

本地監(jiān)聽器注冊是由實(shí)例的LOCAL_LISTENER參數(shù)所控制的：

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 上的配置，當(dāng)然我已經(jīng)處理好IP 地址了。

LOCAL_LISTENER設(shè)置為向本地VIP 地址進(jìn)行注冊，由于本地監(jiān)聽器是在本地的PUBLIC IP和VIP 上監(jiān)聽，所以向VIP 監(jiān)聽注冊就能保證成功向本地監(jiān)聽器注冊。

查看本地監(jiān)聽器的狀態(tài)：

[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

– 這里注意：查看本地監(jiān)聽器信息的時候每個節(jié)點(diǎn)只能看到其上運(yùn)行的實(shí)例。

SCAN 監(jiān)聽器的注冊是由REMOTE_LISTENER參數(shù)控制的，任何實(shí)例都會向所有的SCAN 監(jiān)聽器注冊： SQL> show parameter remote_listener

NAME TYPE VALUE

———————————— ———————- ——————————

remote_listener string pos-cluster-scan:1521

下面是LISTENER_SCAN1的一個狀態(tài)信息，當(dāng)然你也可以查看LISTENER_SCAN2和LISTENER_SCAN3的狀態(tài)。

[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

由于任何實(shí)例啟動都會向所有的SCAN 監(jiān)聽器動態(tài)注冊，從LISTENER_SCAN1的SCAN 監(jiān)聽器運(yùn)行狀態(tài)來看，SERVICE pos包括了所有的實(shí)例名稱。

就像我昨天回答那位朋友的時候簡單說“是通過內(nèi)部機(jī)制”一樣，大家可能看到上面的內(nèi)容并不知道SCAN 監(jiān)聽器如何找到比較空閑的實(shí)例的。

其實(shí)SCAN 監(jiān)聽器是實(shí)時了解所有實(shí)例的運(yùn)行情況的，因此它能夠準(zhǔn)確地將連接重定向到空閑服務(wù)器的本地監(jiān)聽器上。

下面我們通過日志查看實(shí)例的動態(tài)注冊與動態(tài)更新

注意，如果你的RAC 是通過hosts 解析了SCAN 域名的，那么系統(tǒng)里就找不到上面的SCAN 監(jiān)聽器日志的路徑。

實(shí)例的動態(tài)注冊和動態(tài)更新過程是由實(shí)例的PMON 進(jìn)程完成的，正是因?yàn)镾CAN 監(jiān)聽器能夠?qū)崟r了解實(shí)例的負(fù)載情況，所以SCAN 監(jiān)聽器能夠負(fù)載均衡地將連接請求轉(zhuǎn)發(fā)給合適實(shí)例的本地監(jiān)聽器來處理。

這里談到負(fù)載均衡，那么就說下負(fù)載均衡中的優(yōu)先級

共享服務(wù)器配置中：

?

? ?

低負(fù)載節(jié)點(diǎn) 低負(fù)載實(shí)例 實(shí)例相關(guān)的低負(fù)載調(diào)度器

專用服務(wù)器配置中：

?

? 低負(fù)載節(jié)點(diǎn) 低負(fù)載實(shí)例

SCAN 兼容性配置

介紹SCAN 差不多了，這里還有個兼容性問題不能不說。

要完美實(shí)現(xiàn)SCAN 功能特性，其實(shí)對客戶端的要求也是存在的。下面看下不同版本和SCAN 之間的兼容性

注意：JDBC 是不支持TAF 的，所以通過JDBC 連接無法實(shí)現(xiàn)Failover ，那有沒有解決方法，我們可以使用應(yīng)用的連接池來實(shí)現(xiàn)，也就是當(dāng)連接的時候發(fā)現(xiàn)某些連接有故障，那自動切換到正常實(shí)例的連接。 最后我貼一下SCAN 配置信息的檢查方法和DNS 、GNS 方式SCAN 解析實(shí)例：

首先SCAN 配置信息的檢查。