本篇內(nèi)容主要講解“Oracle RAC LoadBalance有什么用”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Oracle RAC LoadBalance有什么用”吧!

創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的槐蔭網(wǎng)站設(shè)計(jì)、移動媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

Load Balance就是把負(fù)載平均的分配到集群中的各個(gè)節(jié)點(diǎn)，從而提高整體的吞吐能力。Oracle10gRAC提供了兩種不同的方法來分散負(fù)載：

1.通過Connection Balancing，按照某種算法把用戶分配到不同的節(jié)點(diǎn)。也可認(rèn)為是純技術(shù)的分散負(fù)載。

2.通過Service，在應(yīng)用層上進(jìn)行分散，也可認(rèn)為是面象業(yè)務(wù)的分散負(fù)載。

一．Connection Balancing
Connection Balancing這種負(fù)載均衡是在用戶連接這個(gè)層次進(jìn)行的，也就是在用戶請求建立連接時(shí)，根據(jù)每個(gè)節(jié)點(diǎn)的負(fù)載決定把連接分配給哪個(gè)實(shí)例，而一旦連接建立之后，會話的所有操作就都在這個(gè)實(shí)例上完成，而不會再分派給其他節(jié)點(diǎn)了。
ConnectionBalancing有客戶端和服務(wù)端兩種實(shí)現(xiàn)方法。

1.1客戶端均衡（Client-SideLB）

客戶端均衡（Client-SideLB）是Oracle8使用的方法，配置方法是在客戶端的tnsnames.ora文件中加入：LOAD_BALANCE=YES條目。
當(dāng)客戶端發(fā)起連接時(shí)，會從地址列表中隨機(jī)的選取一個(gè)，在使用隨即算法把連接 請求分配到各個(gè)實(shí)例。

一個(gè)Clint-SideLB的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文件中

這種方法缺點(diǎn)很明顯，因?yàn)樵诜峙溥B接時(shí)沒有考慮每個(gè)節(jié)點(diǎn)的真實(shí)負(fù)載，最后分配結(jié)果不一定是平衡的；并且隨即算法需要長時(shí)間片，如果在短時(shí)間內(nèi)同時(shí)發(fā)起多個(gè)連接，這些連接有可能都被分配到一個(gè)節(jié)點(diǎn)上，甚至更壞的情況下，連接可能被分配到故障節(jié)點(diǎn)上。因此Oracle引入了服務(wù)端均衡(Sevice-SideLB)方式。


1.2服務(wù)器端均衡（Server-SideLB）

Server-Side LB是從Oracle9引入的。它的實(shí)現(xiàn)依賴于Listener收集負(fù)載信息。
在數(shù)據(jù)庫運(yùn)行過程中，PMON后臺進(jìn)程會收集系統(tǒng)的負(fù)載信息，然后登記到Listener中。最少1分鐘，最多10分鐘PMON就要做一個(gè)信息更新，并且如果節(jié)點(diǎn)的負(fù)載越高，更新頻率就越高，以保證Listener能掌握每個(gè)節(jié)點(diǎn)準(zhǔn)確的負(fù)載情況。如果Listener關(guān)閉了，PMON進(jìn)程會每隔1秒鐘檢查Listener是否重啟。除了這個(gè)自動的定時(shí)的更新任務(wù)外，用戶也可以使用alter  system register命令來手工進(jìn)行這個(gè)過程。
這個(gè)自動更新動作，可以從Listener的日志中看到，比如下面這個(gè)Listener日志片段很清楚的記錄了這些動作。注意，實(shí)例啟動時(shí)PMON進(jìn)程進(jìn)行的第一次登記過程叫作Server-register，而后的更新過程叫作service-update。

[root@rac1log]#pwd
/u01/app/oracle/product/10.2.0/db_1/network/log
[root@rac1log]#more*.log
.....
27-FEB-201002:15:10*service_register*rac1*0
27-FEB-201002:15:11*service_update*rac1*0
27-FEB-201002:15:11*service_update*rac1*0
27-FEB-201002:15:23*service_update*+ASM1*0
27-FEB-201002:15:32*service_update*+ASM1*0
.....

Listener日志雖然記錄了PMON進(jìn)程的注冊和更新動作，但是注冊的內(nèi)容卻沒有體現(xiàn)，要想獲得這些內(nèi)容，可以通過跟蹤10257時(shí)間來獲得，這個(gè)事件就是跟蹤PMON活動。
Event="10257 trace name context forever,levl16"

關(guān)于event的具體使用，參考我的blog：
http://blog.csdn.net/tianlesoftware/archive/2009/12/13/4977827.aspx


PMON進(jìn)程不僅會向本地的Listener注冊，還可以向其他節(jié)點(diǎn)上的Listener注冊。但到底要想何處注冊，是由Remote_Listeners和Local_Listener兩個(gè)參數(shù)決定。Local_Listener不用設(shè)置，而Remote_Listener需要設(shè)置，參數(shù)值是一個(gè)tnsnames項(xiàng)。


有了PMON的自動注冊機(jī)制后，集群的每個(gè)節(jié)點(diǎn)的Listener都掌握所有節(jié)點(diǎn)的負(fù)載情況，當(dāng)收到客戶端連接請求時(shí)，就會把連接轉(zhuǎn)給負(fù)載最小的節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)有可能是自己也有可能是其他節(jié)點(diǎn)，也就是Listener會轉(zhuǎn)發(fā)用戶的請求。
Listener的節(jié)點(diǎn)選擇方法根據(jù)用戶所請求的連接方式會有所不同：
1).如果用戶請求的是Delicate專有連接，Listener首先選擇負(fù)載最小的節(jié)點(diǎn)，如果多個(gè)節(jié)點(diǎn)負(fù)載相同，則從節(jié)點(diǎn)選擇負(fù)載最小的實(shí)例。
2).如果用戶請求的是ShreServer共享功能連接，除了做節(jié)點(diǎn)負(fù)載比較和實(shí)例負(fù)載比較之外，還要在所選擇實(shí)例上，選擇負(fù)載最小的Dispatcher進(jìn)行轉(zhuǎn)發(fā)。

Server-Side LB和Client-Side LB不是互斥的，它們可以一起工作，這時(shí)用戶的連接請求會先從地址列表中隨機(jī)選取一個(gè)地址，然后向該地址的Listener發(fā)出請求；Listener接到請求后，根據(jù)各節(jié)點(diǎn)負(fù)載情況挑選出最合適的節(jié)點(diǎn)轉(zhuǎn)發(fā)連接請求。

1、服務(wù)器端的負(fù)載均衡需要配置remote_listener參數(shù)，而該參數(shù)的值依賴于tnsnames.ora的連接字符串。
2、對于基于服務(wù)器端的連接負(fù)載均衡，監(jiān)聽器會根據(jù)當(dāng)前節(jié)點(diǎn)、實(shí)例上的連接負(fù)載情況進(jìn)行轉(zhuǎn)發(fā)到空閑的實(shí)例
3、轉(zhuǎn)發(fā)的依據(jù)僅僅是當(dāng)前節(jié)點(diǎn)監(jiān)聽的連接數(shù)量的多少，而非當(dāng)前實(shí)例的過度負(fù)載
4、從上面的測試可以得出，各個(gè)節(jié)點(diǎn)的連接并不算均衡，是相對的均衡，因此應(yīng)結(jié)合客戶端連接負(fù)載協(xié)同工作
5、對于當(dāng)前實(shí)例的過度負(fù)載的情形，應(yīng)結(jié)合配置service方法來實(shí)現(xiàn)負(fù)載均衡

注意事項(xiàng)：無論在配置Client-Side LB還是Server-side LB時(shí)，都需要從各個(gè)節(jié)點(diǎn)實(shí)例的listener.ora文件中刪除缺省產(chǎn)生的SID_LIST_LISTENER_NodeName條目，這樣才能保證Listener獲得的信息是動態(tài)注冊的，而不是從文件中讀取的靜態(tài)信息。

1.3兩種LB的配置方法
對于Client-SideLB，需要在客戶的tnsnames條目中加入LOAD_BALANCE=YES；
對于Server-sideLB，需要配置REMOTE_LISTENER這個(gè)參數(shù)。

注意事項(xiàng)：在配置LB時(shí)，需要從各個(gè)節(jié)點(diǎn)實(shí)例的listener.ora文件中刪除缺省產(chǎn)生的SID_LIST_LISTENER_NodeName條目，這樣才能保證Listener獲得的信息是動態(tài)注冊的，而不是從文件中讀取的靜態(tài)信息。

我們要刪除：
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分散負(fù)載
先來分析下Connection Balancing方法的不足之處。Oracle的集群是"共享一切"的架構(gòu)，所有的節(jié)點(diǎn)都共享一份磁盤數(shù)據(jù)。實(shí)例間通過CacheFusion機(jī)制進(jìn)行數(shù)據(jù)同步，所以RAC的性能在很大程度上受限于Cache Fusion的性能。因此，要提高RAC的性能，可以從兩方面入手：
1.提高Cache Fusion的能力，這個(gè)可以使用更好的互聯(lián)設(shè)備，比如G級的private network，或者使用Infiniband等DRA技術(shù)。
2.可以盡量減少CacheFusion的流量，減少實(shí)例間的互相依賴。而Service就是后一種思路基礎(chǔ)刪發(fā)展出來的。

在來看一下與Service非常類似的Partition技術(shù)。如果一個(gè)表中的數(shù)量巨大，Oracle會建議采用PartitionTable，把數(shù)據(jù)按照一定的規(guī)律（比如時(shí)間）分散到多個(gè)物理段上，這樣訪問數(shù)據(jù)時(shí)就限制在某些局部的Segment上。

把"分散數(shù)據(jù)"的思想進(jìn)一步提升，在RAC環(huán)境上，如果能夠把數(shù)據(jù)按照應(yīng)用進(jìn)行分離。比如：一個(gè)ERP應(yīng)用包括生產(chǎn)，銷售，供應(yīng)鏈管理多個(gè)模塊。假設(shè)這個(gè)數(shù)據(jù)庫采用了2個(gè)節(jié)點(diǎn)的RAC，在沒有進(jìn)行“分散數(shù)據(jù)”之前，兩個(gè)用戶都使用銷售模塊，那么這兩個(gè)用戶就可能被分配到兩個(gè)節(jié)點(diǎn)上，在操作過程中，銷售數(shù)據(jù)就要在CacheFusion的作用下，不斷在兩個(gè)字節(jié)間傳遞。如果又來了另外兩個(gè)生產(chǎn)模塊的用戶，在兩個(gè)用戶被分配到兩個(gè)節(jié)點(diǎn)上，在操作過程中，生產(chǎn)部分又要在CacheFusion的協(xié)助下在兩個(gè)實(shí)例間同步。

可見，如果僅有Connection Balancing一種機(jī)制，表面上看起來用戶是被分散到了不同的Instance上，似乎負(fù)載被分散了。但是這種分散是沒有結(jié)合每個(gè)用戶的業(yè)務(wù)需求下進(jìn)行的，是一種純技術(shù)手段。這種分散反而可能加重了系統(tǒng)間的負(fù)擔(dān)。

如果換一種思路，假如把銷售模塊的用戶都分配到節(jié)點(diǎn)1上，生產(chǎn)模塊的用戶都分配到節(jié)點(diǎn)2上，再假設(shè)這兩個(gè)模塊之間的數(shù)據(jù)不交叉。這時(shí)銷售模塊的數(shù)據(jù)都集中在節(jié)點(diǎn)1上，生產(chǎn)模塊的數(shù)據(jù)都集中在節(jié)點(diǎn)2上，Cache Fusion的工作量就會急劇較少，就能從根本上解決了性能問題。

這個(gè)思想就是借助Service分散負(fù)載的基本思想。通過把應(yīng)用按照功能模塊進(jìn)行劃分成Service，進(jìn)而把每個(gè)Service固定在某個(gè)RAC節(jié)點(diǎn)上，從而從根本上體統(tǒng)系統(tǒng)的性能。這種分散負(fù)載的方法不是僅靠DBA進(jìn)行配置就能完成的，需要DBA和開發(fā)人員合作，在了解業(yè)務(wù)數(shù)據(jù)特點(diǎn)之后才可能看到效果。

在RAC環(huán)境下，Service并不是必須的，但是如果能借助Service對應(yīng)的劃分，相信對整個(gè)系統(tǒng)性能的提升是有很大好處的。使用Service還有另一個(gè)好處：可以在數(shù)據(jù)庫內(nèi)部創(chuàng)建Service TAF參數(shù)，如果客戶通過Service連接數(shù)據(jù)庫，客戶端的tnsnames.ora中就不再需要FAIL-OVER的許多設(shè)置。只需要添加如下條目即可：

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)
   )
  )

到此，相信大家對“Oracle RAC LoadBalance有什么用”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！