Oracle RAC LoadBalance 使用詳解

LoadBalance 就是把負載平均的分配到叢集中的各個節點，從而提高整體的吞吐能力。 Oracle 10g RAC 提供了兩種不同的方法來分散負載：

1. 透過Connection Balancing，按照某種演算法把使用者分配到不同的節點。也可認為是純技術的分散負載。

2. 透過Service，在應用層上進行分散，也可認為是面象業務的分散負載。

[@more@]

一．Connection Balancing

Connection Balancing 這種負載均衡是在使用者連線這個層次進行的，也就是在使用者請求建立連線時，根據每個節點的負載決定把連線分配給哪個例項，而一旦連線建立之後，會話的所有操作就都在這個例項上完成，而不會再分派給其他節點了。

Connection Balancing 有客戶端和服務端兩種實現方法。
1.1 客戶端均衡（Client-Side LB）

客戶端均衡（Client-Side LB）是Oracle 8 使用的方法，配置方法是在客戶端的tnsnames.ora 檔案中加入：

LOAD_BALANCE=YES 條目。當客戶端發起連線時，會從地址列表中隨機的選取一個，在使用隨即演算法把連線 請求分配到各個例項。

一個Clint-Side LB的TNS 配置檔案如下：

RAC =

(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 = RAC)

)

)

)

注： rac1-vip 需要新增到hosts 檔案中
這種方法缺點很明顯，因為在分配連線時沒有考慮每個節點的真實負載，最後分配結果不一定是平衡的；並且隨即演算法需要長時間片，如果在短時間內同時發起多個連線，這些連線有可能都被分配到一個節點上，甚至更壞的情況下，連線可能被分配到故障節點上。因此Oracle 引入了服務端均衡(Sevice-Side LB)方式。
1.2 伺服器端均衡（Server-Side LB）
Server-Side LB 是從Oracle 9引入的。 它的實現依賴於Listener收集負載資訊。 在資料庫執行過程中，PMON後臺程式會收集系統的負載資訊，然後登記到Listener中。 最少1分鐘，最多10分鐘PMON就要做一個資訊更新，並且如果節點的負載越高，更新頻率就越高，以保證Listener能掌握每個節點準確的負載情況。如果Listener關閉了，PMON程式會每隔1秒鐘檢查Listener是否重啟。除了這個自動的，定時的更新任務外，使用者也可以使用alter system register 命令來手工進行這個過程。
這個自動更新動作，可以從Listener的日誌中看到，比如下面這個Listener日誌片段很清楚的記錄了這些動作。注意，例項啟動時PMON程式進行的第一次登記過程叫作Server-register，而後的更新過程叫作service-update。

[root@rac1 log]# pwd

/u01/app/oracle/product/10.2.0/db_1/network/log

[root@rac1 log]# more *.log

.....

27-FEB-2010 02:15:10 * service_register * rac1 * 0

27-FEB-2010 02:15:11 * service_update * rac1 * 0

27-FEB-2010 02:15:11 * service_update * rac1 * 0

27-FEB-2010 02:15:23 * service_update * +ASM1 * 0

27-FEB-2010 02:15:32 * service_update * +ASM1 * 0

.....

Listener 日誌雖然記錄了PMON 程式的註冊和更新動作，但是註冊的內容卻沒有體現，要想獲得這些內容，可以透過跟蹤10257 時間來獲得，這個事件就是跟蹤PMON活動。

Event="10257 trace name context forever,levl 16"
PMON 程式不僅會向本地的Listener註冊，還可以向其他節點上的Listener註冊。但到底要想何處註冊，是由Remote_Listeners 和Local_Listener 兩個引數決定。 Local_Listener 不用設定，而Remote_Listener 需要設定，引數值是一個tnsnames項。

[oracle@rac1 ~]$ set ORACLE_SID=RAC1

[oracle@rac1 ~]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Fri Mar 5 00:52:19 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> conn / as sysdba

Connected.

SQL> show parameter listener

NAME TYPE VALUE

local_listener string

remote_listener string LISTENERS_RAC

SQL>

本機的tnsnames.ora 中對應的LISTENERS_RAC 內容如下：

LISTENERS_RAC =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))

)

有了PMON的自動序號產生器制後，叢集的每個節點的Listener都掌握所有節點的負載情況，當收到客戶端連線請求時，就會把連線轉給負載最小的節點，這個節點有可能是自己也有可能是其他節點，也就是Listener 會轉發使用者的請求。

Listener的節點選擇方法根據使用者所請求的連線方式會有所不同：

1). 如果使用者請求的是Delicate 專有連線，Listener首先選擇負載最小的節點，如果多個節點負載相同，則從節點選擇負載最小的例項。

2). 如果使用者請求的是Shre Server共享功能連線，除了做節點負載比較和例項負載比較之外，還要在鎖選擇例項上，選擇負載最小的Dispatcher進行轉發。

Server-Side LB 和Client-Side LB 不是互斥的，它們可以一起工作，這是使用者的連線請求會先從地址列表中隨機選取一個地址，然後向改地址的Listener 發出請求；Listener 接到請求後，根據各節點負載情況挑選出最合適的節點轉發連線請求。

1.3 兩種LB 的配置方法

對於Client-Side LB，需要在客戶的tnsnames條目中加入LOAD_BALANCE=YES，對於Server-side LB，需要配置REMOTE_LISTENER這個引數。、

注意事項：在配置LB時，需要從各個節點例項的listener.ora檔案中刪除預設產生的

SID_LIST_LISTENER_NodeName條目，這樣才能保證Listener獲得的資訊是動態註冊的，而不是從檔案中讀取的靜態資訊。

我們要刪除：

SID_LIST_LISTENER_RAC1 =

(SID_LIST =

(SID_DESC =

(SID_NAME = PLSExtProc)

(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)

(PROGRAM = extproc)

)

)

僅保留：

LISTENER_RAC1 =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521)(IP = FIRST))

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.85.10.119)(PORT = 1521)(IP = FIRST))

)

)

二. 利用Service分散負載

先來分析下Connection Balancing 方法的不足之處。 Oracle 的叢集是"共享一切"的架構，所有的節點都共享一份磁碟資料。例項間透過Cache Fusion機制進行資料同步，所以RAC的效能在很大程度上受限於Cache Fusion的效能。 因此，要提高RAC的效能，可以從兩方面入手：
1. 提高Cache Fusion的能力，這個可以使用更好的互聯裝置，比如G級的private network，或者使用Infiniband等DRA技術。

2. 可以儘量減少Cache Fusion的流量，減少例項間的互相依賴。而Service就是後一種思路基礎刪發展出來的。

在來看一下與Service非常類似的Partition技術。如果一個表中的數量巨大，Oracle會建議採用Partition Table，把資料按照一定的規律（比如時間）分散到多個物理段上，這樣訪問資料時就限制在某些區域性的Segment上。

把"分散資料"的思想進一步提升，在RAC環境上，如果能夠把資料按照應用進行分離。比如： 一個ERP 應用包括生產，銷售，供應鏈管理多個模組。假設這個資料庫採用了2個節點的RAC，在沒有進行“分散資料”之前，兩個使用者都使用銷售模組，那麼這兩個使用者就可能被分配到兩個節點上，在操作過程中，銷售資料就要在Cache Fusion的作用下，不斷在兩個位元組間傳遞。如果又來了另外兩個生產模組的使用者，在兩個使用者被分配到兩個節點上，在操作過程中，生產部分又要在Cache Fusion的協助下在兩個例項間同步。

可見，如果僅有Connection Balancing一種機制，表面上看起來使用者是被分散到了不同的Instance上，似乎負載被分散了。 但是這種分散是沒有結合每個使用者的業務需求下進行的，是一種純技術手段。這種分散反而可能加重了系統間的負擔。

如果換一種思路，假如把銷售模組的使用者都分配到節點1上，生產模組的使用者都分配到節點2上，在假設這兩個模組之間的資料交叉不。 這時銷售模組的資料都集中在節點1上，生產模組的資料都集中在節點2上， Cache Fusion的工作量就會急劇較少，就能從根本上解決了效能問題。

9irac好像有

(LOAD_BALANCE=ON)
(FAILOVER=ON）

10gr2有(LOAD_BALANCE = yes)