WEBLOGIC连接Oracle RAC 的负载均衡测试

要进行压力测试，中间件使用WEBLOGIC 816，数据库版本为11.1.0.6 RAC，压力测试工具为LOADRUNNER 8.0。测试单实例与RAC环境各个节点的负载情况。 在WEBLOGIC上配置了一个多池，利用WEBLOGIC提供的负载均衡策略，将并发均衡的分别到两个节点上。但是测试发现，一旦运行 了一段时间，所有的压力都会加载到一个节点上，而另一个节点上机会没有任何的压力。通过数据库中查询到的结 果如下：SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 6
1 ACTIVE 1
2 ACTIVE 147
2 INACTIVE 3WEBLOGIC的并发设置为150，而LOADRUNNER并发为200，Oracle每 个实例的SESSION为600。可以看到，基本上压力完 全集中在实例2上。实例1上处于空闲状态，如果压力测试运行时间足够长，可能在短时间内实例1上的ACTIVE连接能达到二、三十左右，但是很快又全部释放。SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;INST_ID STATUS COUNT(*)
---------- -------- ----------
1 ACTIVE 20
1 INACTIVE 54
2 ACTIVE 121
2 INACTIVE 28测试了多次，结果都很类 似，压力几乎完全集中到一个节点上。不过不见得每次压力都是在节点2上， 很有可能在WEBLOGIC服务重启之后，下次测试开始，所有 的压力都集中到节点1上。这说明问题应该不是两个节点的硬件处 理不平衡造成的。这个测试的是长时间运行 的查询，而对于快速相应的INSERT语句，可以看到两个节点 上都有很少的ACTIVE的会话。这时因为事务处理很短暂，不 可能在短时间内使得WEBLOGIC的并发跑满，因此这种情况 没有问题。SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 50
1 ACTIVE 1
2 ACTIVE 1
2 INACTIVE 98对于长时间查询的情况，WEBLOGIC的LOAD-BALANCING策略似乎存在问题，导致两个节点压力出现倾斜。开始认为可能是由于WEBLOGIC的版本太低导致了问题的产生，于是将WEBLOGIC升级到了最新的版本10.3，可是测试结果依旧。由于前面测试使用的都是WEBLOGIC的LOAD-BALANCING策略进行的，尝试了一下HING-AVAILABILITY策略，发现这个策略倒是和它本身的名称更相符一些，但是也存在一定的问题。 这个策略会优先MULIT POOL中的第一个连接池，如果第一个连接池可以连接，就不使用第二个连接池。即使并发用户太多，导致很多连接超时的错误，WEBLOGIC也不会去尝试使用第二个连接池。当后台关闭实例1，导致连接池1的连接失败，这时WEBLOGIC开 始使用第二个连接池。一旦实例1启动，WEBLOGIC检测到连接池1可用，马上所有的连接都会从连接池2上转移到连接池1，恢复到实例1关 闭之前的情况。基于上面的情况，感觉WEBLOGIC只是实现 了连接池的优先级设置，而不是真正意义上的HIGH-AVAILABILITY。扯远了，下面继续说WEBLOGIC的LOAD-BALANCING。由于升级到最新版本都无法解决这个问题，只好在网络上搜索，结果发现不少相似的 案例。不过没有发现解决方案。不过在metalink里面的一篇文章提到可以在WEBLOGIC里面的URL=”jdbc:oracle:thin@”后面直接使用Oracle的tnsnames.ora中 的配置。比如这里配置URL=”jdbc:oracle:thin@(DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=172.0.2.58) (PORT=1521)) (ADDRESS=(PROTOCOL=TCP) (HOST=172.0.2.59) (PORT=1521)) (LOAD_BALANCE=yes)(CONNECT_DATA=(SERVER=DEDICATED) (SERVICE_NAME=rac11g.us.oracle.com))”这种方式实际上绕过了WEBLOGIC的负载均衡机制，而直接使用了RAC的负载均衡策略，结果测试结果如下：SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;INST_ID STATUS COUNT(*)
---------- -------- ----------
1 ACTIVE 75
1 INACTIVE 6
2 ACTIVE 75
2 INACTIVE 5Oracle的负载均衡的实现还是比较好的，基本上两个节点的负载差别很小。对于负载较小的情况也同样适用：SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 8
1 ACTIVE 1
2 ACTIVE 2
2 INACTIVE 7测试结果发现，要想在任 何情况下都获得比较理想的负载均衡，最好使用Oracle的负 载均衡策略，而不要使用WEBLOGIC的多池提供的LOAD-BALANCING策略。http://blog.csdn.net/cnham/article/details/5323041

原文：http://blue-prince.spaces.live.com/blog/cns!12D6E6CCFACF4283!1058.entry

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首先必须设置SERVICE负载均衡的目标，目标分为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.