本篇内容主要讲解“Oracle RAC LoadBalance有什么用”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Oracle RAC LoadBalance有什么用”吧!
Load Balance就是把负载平均的分配到集群中的各个节点,从而提高整体的吞吐能力。Oracle10gRAC提供了两种不同的方法来分散负载:
1.通过Connection Balancing,按照某种算法把用户分配到不同的节点。也可认为是纯技术的分散负载。
2.通过Service,在应用层上进行分散,也可认为是面象业务的分散负载。
一.Connection Balancing
Connection Balancing这种负载均衡是在用户连接这个层次进行的,也就是在用户请求建立连接时,根据每个节点的负载决定把连接分配给哪个实例,而一旦连接建立之后,会话的所有操作就都在这个实例上完成,而不会再分派给其他节点了。
ConnectionBalancing有客户端和服务端两种实现方法。
1.1客户端均衡(Client-SideLB)
客户端均衡(Client-SideLB)是Oracle8使用的方法,配置方法是在客户端的tnsnames.ora文件中加入:LOAD_BALANCE=YES条目。
当客户端发起连接时,会从地址列表中随机的选取一个,在使用随即算法把连接 请求分配到各个实例。
一个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文件中
这种方法缺点很明显,因为在分配连接时没有考虑每个节点的真实负载,最后分配结果不一定是平衡的;并且随即算法需要长时间片,如果在短时间内同时发起多个连接,这些连接有可能都被分配到一个节点上,甚至更坏的情况下,连接可能被分配到故障节点上。因此Oracle引入了服务端均衡(Sevice-SideLB)方式。
1.2服务器端均衡(Server-SideLB)
Server-Side LB是从Oracle9引入的。它的实现依赖于Listener收集负载信息。
在数据库运行过程中,PMON后台进程会收集系统的负载信息,然后登记到Listener中。最少1分钟,最多10分钟PMON就要做一个信息更新,并且如果节点的负载越高,更新频率就越高,以保证Listener能掌握每个节点准确的负载情况。如果Listener关闭了,PMON进程会每隔1秒钟检查Listener是否重启。除了这个自动的定时的更新任务外,用户也可以使用alter system register命令来手工进行这个过程。
这个自动更新动作,可以从Listener的日志中看到,比如下面这个Listener日志片段很清楚的记录了这些动作。注意,实例启动时PMON进程进行的第一次登记过程叫作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进程的注册和更新动作,但是注册的内容却没有体现,要想获得这些内容,可以通过跟踪10257时间来获得,这个事件就是跟踪PMON活动。
Event="10257 trace name context forever,levl16"
关于event的具体使用,参考我的blog:
http://blog.csdn.net/tianlesoftware/archive/2009/12/13/4977827.aspx
PMON进程不仅会向本地的Listener注册,还可以向其他节点上的Listener注册。但到底要想何处注册,是由Remote_Listeners和Local_Listener两个参数决定。Local_Listener不用设置,而Remote_Listener需要设置,参数值是一个tnsnames项。
有了PMON的自动注册机制后,集群的每个节点的Listener都掌握所有节点的负载情况,当收到客户端连接请求时,就会把连接转给负载最小的节点,这个节点有可能是自己也有可能是其他节点,也就是Listener会转发用户的请求。
Listener的节点选择方法根据用户所请求的连接方式会有所不同:
1).如果用户请求的是Delicate专有连接,Listener首先选择负载最小的节点,如果多个节点负载相同,则从节点选择负载最小的实例。
2).如果用户请求的是ShreServer共享功能连接,除了做节点负载比较和实例负载比较之外,还要在所选择实例上,选择负载最小的Dispatcher进行转发。
Server-Side LB和Client-Side LB不是互斥的,它们可以一起工作,这时用户的连接请求会先从地址列表中随机选取一个地址,然后向该地址的Listener发出请求;Listener接到请求后,根据各节点负载情况挑选出最合适的节点转发连接请求。
1、服务器端的负载均衡需要配置remote_listener参数,而该参数的值依赖于tnsnames.ora的连接字符串。
2、对于基于服务器端的连接负载均衡,监听器会根据当前节点、实例上的连接负载情况进行转发到空闲的实例
3、转发的依据仅仅是当前节点监听的连接数量的多少,而非当前实例的过度负载
4、从上面的测试可以得出,各个节点的连接并不算均衡,是相对的均衡,因此应结合客户端连接负载协同工作
5、对于当前实例的过度负载的情形,应结合配置service方法来实现负载均衡
注意事项:无论在配置Client-Side LB还是Server-side LB时,都需要从各个节点实例的listener.ora文件中删除缺省产生的SID_LIST_LISTENER_NodeName条目,这样才能保证Listener获得的信息是动态注册的,而不是从文件中读取的静态信息。
1.3两种LB的配置方法
对于Client-SideLB,需要在客户的tnsnames条目中加入LOAD_BALANCE=YES;
对于Server-sideLB,需要配置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的集群是"共享一切"的架构,所有的节点都共享一份磁盘数据。实例间通过CacheFusion机制进行数据同步,所以RAC的性能在很大程度上受限于Cache Fusion的性能。因此,要提高RAC的性能,可以从两方面入手:
1.提高Cache Fusion的能力,这个可以使用更好的互联设备,比如G级的private network,或者使用Infiniband等DRA技术。
2.可以尽量减少CacheFusion的流量,减少实例间的互相依赖。而Service就是后一种思路基础删发展出来的。
在来看一下与Service非常类似的Partition技术。如果一个表中的数量巨大,Oracle会建议采用PartitionTable,把数据按照一定的规律(比如时间)分散到多个物理段上,这样访问数据时就限制在某些局部的Segment上。
把"分散数据"的思想进一步提升,在RAC环境上,如果能够把数据按照应用进行分离。比如:一个ERP应用包括生产,销售,供应链管理多个模块。假设这个数据库采用了2个节点的RAC,在没有进行“分散数据”之前,两个用户都使用销售模块,那么这两个用户就可能被分配到两个节点上,在操作过程中,销售数据就要在CacheFusion的作用下,不断在两个字节间传递。如果又来了另外两个生产模块的用户,在两个用户被分配到两个节点上,在操作过程中,生产部分又要在CacheFusion的协助下在两个实例间同步。
可见,如果仅有Connection Balancing一种机制,表面上看起来用户是被分散到了不同的Instance上,似乎负载被分散了。但是这种分散是没有结合每个用户的业务需求下进行的,是一种纯技术手段。这种分散反而可能加重了系统间的负担。
如果换一种思路,假如把销售模块的用户都分配到节点1上,生产模块的用户都分配到节点2上,再假设这两个模块之间的数据不交叉。这时销售模块的数据都集中在节点1上,生产模块的数据都集中在节点2上,Cache Fusion的工作量就会急剧较少,就能从根本上解决了性能问题。
这个思想就是借助Service分散负载的基本思想。通过把应用按照功能模块进行划分成Service,进而把每个Service固定在某个RAC节点上,从而从根本上体统系统的性能。这种分散负载的方法不是仅靠DBA进行配置就能完成的,需要DBA和开发人员合作,在了解业务数据特点之后才可能看到效果。
在RAC环境下,Service并不是必须的,但是如果能借助Service对应的划分,相信对整个系统性能的提升是有很大好处的。使用Service还有另一个好处:可以在数据库内部创建Service TAF参数,如果客户通过Service连接数据库,客户端的tnsnames.ora中就不再需要FAIL-OVER的许多设置。只需要添加如下条目即可:
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有什么用”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。