RAC負載均衡命令展示
不管是大型的數據中心，還是個人的數據庫學習，我們都可以看到負載均衡的應用。那么，現在我們就來介紹一下RAC的負載均衡問題。為了更好的為大家將這部分知識內容總結好，我們根據一個例子來幫助大家將配置過程進行分解，希望大家能掌握其中的要點。
RAC負載均衡主要是指新會話連接到RAC數據庫時,如何判定這個新的連接要連到哪個節點進行工作｡在RAC中,負載均衡分為兩種,一種是基于客戶端連接的,另外一種是基于服務器端的｡
客戶端的負載均衡配置相對簡單,只需要在tnsnames.ora中添加LOAD_BALANCE=ON這么一個選項即可｡比如下面的TNS:
- RAC =
- (DESCRIPTION =
- (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
- (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
- (LOAD_BALANCE = ON)
- (FAILOVER = ON)
- (CONNECT_DATA =
- (SERVER = DEDICATED)
- (SERVICE_NAME = rac)
- )
- )
這樣當客戶端連接RAC數據庫時,會隨機在TNS里面挑個監聽地址進行連接｡在Oracle10g以前,假如有節點宕機或者類似事故時,客戶端可能還是選擇連接到這個節點,這樣會發生較長時間的TCP等待超時｡而在10g以后,由于VIP和FAN的引入,這樣的情況可以得到很大程度的改善｡客戶端的負載均衡在通常情況下能夠較好地工作,但是由于連接是在客戶端隨機發起的,這樣客戶端并不知道RAC各節點的負荷及連接數情況,有可能負荷大的節點還會源源不斷地增加新的連接,導致RAC節點無法均衡工作｡
從Oracle 10g開始,服務器端的負載均衡可以根據RAC中各節點的負荷及連接數情況,而判定將新的客戶端連接分配到負荷最小的節點上去｡RAC中各節點的PMON 進程每3秒會將各自節點的負荷(包括LOAD､***LOAD､CPU使用率)及連接數更新到service_register里面,然后假如節點的負荷有發生變化,將會通知到監聽程序,由監聽程序再決定新的客戶端連接分配至哪個節點｡假如RAC中一個節點的監聽失敗了,PMON每一分鐘會去檢查一次是否已經恢復正常｡
服務器端的監聽配置是在各節點的tnsnames.ora里面添加一個連接到各個節點監聽的條目,然后再在初始化參數里面設置 remote_listeners這個參數｡比如:
- LISTENERS_RAC =
- (ADDRESS_LIST =
- (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
- (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
- )
- ALTER SYSTEM SET REMOTE_LISTENER = LISTENERS_RAC;
這樣服務器端的LOAD BALANCE便配置完成｡
但是有時候由于PMON取節點負荷的延遲,導致客戶端連接可能還是會連接到負荷較大的節點上,這時候便可以在服務器各節點的listener.ora里面加入PREFER_LEAST_LOADED_NODE=OFF這么一行,這樣服務器端的負載均衡將不再根據節點的負荷來進行分配,而是根據節點的連接數進行分配,達到各個節點連接數比較平衡的效果｡
另外一個不得不說的便是并行操作,假如有個會話連接以后要進行并行操作｡由于連接時是按負荷或連接數連接,這樣可能連接時各個節點連接數和負荷等比較平衡,但是這個并行會話啟動多個并行進程以后,那么這個節點的負荷及連接數就會有可能上升得比較快｡如果在RAC中開啟了節點并行,那么有可能會把并行進程分配到多個節點運行以達到負載均衡的效果｡
從Oracle 10.2開始,Oracle引入了Load Balance Advisor,對負載均衡有了進一步的改進｡結合Service,可以對不同的SERVICE設置不同的負載均衡策略｡Load Balance Advisor的配置可以通過DBMS_SERVICE包對SERVICE進行更改而完成｡在Load Balance Advisor首先必須柚肧ERVICE負載均衡的目標,目標分為3種:
GOAL_NONE Disables the load balancing advisory
GOAL_SERVICE_TIME The LBA calculates a weighted moving average of the total elapsed time for completed work plus the bandwidth that's available to the service to calculate the service goodness. This goal is ideal for services whose workload may change dramatically over a short period of time, e.g. an application that services a “clicks and mortar" store that provides customer self-service through an internet-based shopping web site.
GOAL_THROUGHPUT The LBA calculates a weighted moving average of throughput (i.e. the rate at which work is completed) in addition to the bandwidth available to the service to calculate the service goodness. This goal is best suited for long-duration tasks that are typically queued to run serially, e.g. scheduled jobs that handle large batches of transactions.
另外可以額外設置連接的負載均衡:
CLB_GOAL_SHORT The Load Balancing Advisory will be used for connection load balancing only if it is enabled (i.e. set to other than GOAL_NONE). If the LBA has been disabled, connection load balancing will utilize abridged advice determined by CPU utilization.
CLB_GOAL_LONG Connection load balancing will be determined by first tallying the total number of connections per instance, and then by counting the number of sessions per each service. Oracle recommends using this setting for services whose applications tend to connect for long periods of time (e.g. Oracle Forms). The Load Balancing Advisory can be used in conjunction with this setting as long as the connection pool has been sized to accommodate “gravitation “ within the pool without adding or subtracting connections. Oracle recommends this option as the most efficient design.
