Oracle RAC load blance
首先声明 本文基本是阅读 大话RAC 后的笔记。OK, 进入正题。
Oracle 10g RAC中采取两种方式提供负载均衡。第一种是connection blance。在用户连接的时候,根据随机算法把用户的连接定向到不同的节点。第二种是通过service,在应用层面上进行负载均衡。打个比方,一个ERP系统中包括多个模块,为多个部门服务。比如销售模块,人力资源管理模块。如果通过service进行负载均衡,我们可以定义一个 sales service代理销售模块,并且该service运行在节点1上,这样使用销售模块的人就会连接到节点1上。同理,定义一个HR service,代理人力资源模块,这样使用人力资源模块模块的人就会连接到节点2上。概况一下,第一种负载均衡是纯技术的负载均衡,第二种是面向业务的负载均衡。
connection blance这种负载均衡有两种实现方法,一种是在客户端实现,另一种是在服务器端实现。客户端实现非常简单,就是在tnsname.ora配置文件中的加上load_blance=yes这样的条目。但这种方法的缺点很明显。分配的时候并没有考虑两个节点的真实负载,所以分配结果不一定平衡,并且随机算法需要长时间片,如果短时间发起大量连接,就有可能都分配到同一个节点。更坏的结果是连接有可能被分配给故障节点。所以这种方式仅作了解,我们应该使用服务器端实现的负载均衡。而服务器端的负载均衡配置及原理也非常简单。 它的原理是由 PMON进程向listener定期的报告本节点的负载情况。listener了解了各个节点的负载情况后,会根据实际负载把收到的连接请求定向到负载较低的节点上去。如果你查看listener的log会发现很多service_update的条目,这些就是PMON在定期的汇报。 在服务器端实现负载均衡非常简单,只要配置remote_listener参数即可,这样每一个listener都会知道每一个节点的负载情况。
在了解了上面的connection blance之后,也许你在想这样已经足够好了,为什么还要发展service这种load blance呢? 这就要分析RAC的本质了。RAC通过cache fusion模式来保证数据同步及一致。而cache fusion也是有一定开销的。 所以,如果有多个session需要同步的访问同一份数据,还是让他们都通过一个instance来访问比较好,这样会减少cache fusion的开销。让我们用ERP系统为例,若多个人同时访问销售模块,而通过connection blance把它们分散到不同的节点上,这时整个系统就需要通过cache fusion来频繁的交换数据以保证数据的一致性。 但如果通过service,他们都连接到同一个节点,就减去了cache fusion的开销。