dev2dev 首页 > 资源中心 > 专家Blog > 专家Blog文章
均衡支持RAC的JDBC连接池
均衡支持RAC的JDBC连接池
我的大部分时间都花在开发J2EE系统或者修补出了问题的J2EE系统上，但是有些时候我更像是在管理J2EE系统，或是对其进行故障诊断，而不是进行J2EE开发。目前我的一个客户遇到了一个有意思的问题，是有关Oracle RAC及其自动化的负载均衡和故障恢复功能的，这些功能迫切需要WebLogic Server为其提供方便，以便安全地重新设置JDBC连接池。
简要地说，这位客户安装了一个3节点的RAC（即：共享一个SAN存储设备的3个独立的Oracle实例），它的性能很好，利用率也非常高——在大多数时候。遗憾的是，一个RAC节点出现了故障，而客户机连接被重新配置到其他两个节点上（当然，这对于WebLogic Server来说是透明的）。当出现故障的节点经过修复重新接入RAC集群后，却无法在3个节点中均衡连接了。
我们都知道，将池的最小和最大容量设置为同一个比较大的值（在线程数的50%到100%之间，IMO），并避免各种形式的收缩和增长等等，这是一种常见的连接池最佳实践。在服务器启动时设置所需的连接池，然后在服务器的生存期就不需要再管它了。
发现问题了吗？
启动时设置的池连接平均地分布在3个RAC节点中（我们假设有60个连接，即每个节点有20个连接）。当节点#2出现故障时，它的20个连接被重新配置到节点#1和#3上，使它们中的每个节点都有30个连接（在理想情况下）。节点#2又重新接入……然后……没有下文了。这60个连接舒服地呆在它们所在的地方，而节点#2得不到任何连接。
每当重新均衡连接后遇到这种情况，这位客户就反复重新启动WebLogic Server。这可不太好。
“Greg，有没有更好的方法？”
“让我看看吧。”我有些迟疑地回答。
您可能认为，将池中的初始和最大连接数设置为同一个值是造成这种问题的原因——在某种意义上您是正确的——但是有足够的理由可以避免固定的收缩/增长周期，而您又不想仅仅为了有助于重新均衡而吞下苦果！除此之外，将初始连接值设置为小于最大值只在下面这种情况下才会有帮助：服务器负载经历大的周期性的变化，致使一段时间内连接数远远低于最少连接数而足以引发收缩，然后又超过最少连接数，致使池又开始增长，而且（可能）把一些连接转移到现在恢复了的节点#2上。这种情况下，重新均衡连接要花非常长的时间，尤其是因为RAC还没有智能化到可以基于当前的连接数指派新连接。
除此之外，该客户还遇到了持续的（长达几个小时）大容量时期，期间他们的8台WebLogic Server上负载非常大（每秒数百个连接），如果此时有一个RAC节点出现暂时性的故障，他们根本没有机会基于收缩/增长进行重新均衡。
WebLogic Server的reset命令看起来似乎可以解决这个问题，但是事实证明它根本没有用。它只是丢弃池中现有的所有连接，然后再重新建立“初始”的连接数，而不考虑当前正在使用（保留下来）的连接。
shrink命令要好一些。如果当前的连接数超过了“初始”值，它会试图关闭连接以使当前的连接数等于初始（最小）值，并优先照顾当前所保留（使用）的连接。
我想到了下面的方法：
- 将最大连接数增加为原来的至少2倍（对于上面的例子，最大连接数由60变为120）
- 将初始/最小连接数也增加到同一值（120）。WebLogic创建60个新连接，或多或少均衡了3个RAC节点。
- 等待30秒左右，使保留的连接分布在新的更大的池中。
- 再将初始容量降为60（或者更低，只要负载允许）。
- 执行shrink命令。
- 假定当前使用的连接数低于新的初始值，将最大值降为初始值（60）。此处要小心——若最大值低于当前使用的连接数，会导致强行关闭连接。
- 重复上面的过程3到5次，就又接近平均分布了。（数学不太好的人是不是有点糊涂了？）
这几步很容易在控制台中手动完成（尽管可能有些乏味，而且易于出错），也很容易使用wlshell或WLST等编写脚本。如果您还需要帮助的话，请给我发电子邮件。
很明显，大家都想不采用这些步骤而只是重新均衡连接，这需要一个新的WebLogic Server命令。它能够重新设置一段时间内的所有连接，在此之前等待任何保留的连接再释放到池中。有点像是一个更友好的RESET命令。
怎么样？还有人有更简单的方法吗？我洗耳恭听。
原文出处：http://dev2dev.bea.com/blog/gnyberg/archive/2005/05/balancing_racba.html
作者其它文章
|
