论文部分内容阅读
摘 要：本文结合实际工程，详细介绍了C/S架构的系统使用群集负载机制存在性能问题时，可以采取的解决方案即F5负载均衡在实际工程中的应用。
关键词：C/S架构； 群集； F5负载均衡
一. F5负载均衡
负载均衡，英文名称为Load Balance，其意思就是将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。当某台SERVER设备发生故障，F5 将自动发现并不再把流量发送到这台故障的SERVER上，从而实现SERVER的高可用。
二.优化测试与方案实施中发现与解决的问题
第一阶段： 调整Weblogic配置参数
资源管理系统出现异常时最大的特点为：单个SERVER异常时，影响其它SERVER上的在用用户与用户的登录操作。在前期过程中，一直致力于单SERVER的参数的调整与优化，以避免单个SERVER的异常，其中包括 -Xmx2048m（最大堆内存）、-Xp8196K（堆碎片）、-Xloratio0.3 （大对象区比率），经反复的调整优化测试，相应的参数能够使系统相对平稳安全运行，但因大业务使用的需求，系统异常情况并未得到有效解决。因此又对针对Weblogic的Cluster集群机制进行了研究。
根据已有的资源系统C/S架构，客户端使用T3协议访问服务器上部署的应用，Cluster群集机制在8.1版本的使用上，存在性能问题，当群集中任何一个SERVER出现异常时，会导致整个系统运行缓慢。
为此，我们在测试环境进行了大量的测试，针对现有的资源管理系统客户端配置多个T3地址串的情况，测试发现异常SERVER及配置T3地址数量对用户登录耗时影响很大。以下是测试数据：
1.测试环境现状介绍：
测试环境为集群环境，两台主机，IP地址以192.168.1.1和192.168.1.2为例，每台主机部署3个应用服务，每个应用服务有自己的端口号
客户端单个T3地址样例：t3：// 192.168.1.1：9931
客户端T3地址串样例：t3：// 192.168.1.1：9931， 192.168.1.1：9932， 192.168.1.2：9922
2.测试用例
测试情况用例
2.1所有SERVER均正常，测试资源客户端配置SERVER由少到多对登录的影响
配1个T3地址 时间： 4s 5s 6s
配2个T3地址 时间：10s 9s 7s
配6个T3地址 時间：20s 15s 22s
以上数据，除去网络环境等因素影响，证明客户端配置SERVER的数量，会影响用户的登录时长。客户端配的T3地址串中SERVER数量越多，客户端登录越耗时。
2.2测试资源客户端配T3地址串中有shutdown状态的SERVER对登录影响
配2个T3地址1开1停 时间 ：12s
配3个T3地址2开1停 时间：9s 18s 14s 14s
配4个T3地址2开2停 时间：28s 28s 60s
配6个T3地址2开4停 时间：55s 52s
除去网络环境因素影响，多SERVER配置中，状态异常的SERVER或者繁忙的SERVER越多，登录耗时越长。也证明了客户端配置T3地址串后，会以某种机制询访T3串中的每个服务地址，异常SERVER对询访影响很大，但它位于T3串的前后位置对耗时几乎无任何影响。
针对上述的问题及规律，又进行了客户端询访机制的优化，客户端有一个参数控制程序对SERVER的询访时间：weblogic.jndi.requestTimeout ，默认时间为5s，这个时间压缩到1s。经测试该参数调整对上述两种场景的登录耗时有优化作用。
第二阶段：实现对F5负载均衡的支持
在经测试确定客户端进行随机分配并进入指定的SERVER的方案不可靠之后，经与F5设备厂家、Weblogic厂家多次沟通与测试，采用F5实现负载均衡的方案，实现基于T3协议的客户端与集群服务器之间的负载均衡。
首先通过现场研发8.1版本的Weblogic补丁，解除了F5负载均衡要求应用服务器上应用服务端口号和F5端口号一致的限制，在 F5侧配置客户端访问的T3协议地址，并建立该地址与资源12个SERVER服务间的映射关系。在功能上实现了现有环境对F5负载均衡的支持。
测试中发现，F5能将用户请求的数据流随机分配到某个SERVER上，通过该设备的这种机制实现了系统负载的均衡，在使用中，由于对Weblogic SERVER状态判断上有缺陷：只能发现SERVER宕掉，不能发现SERVER无响应，有时SERVER依然是Running状态，但是用户已经反映系统慢了，在这种情况下，系统整体性能会一直受影响。
第三阶段：实现了对Weblogic SERVER各种异常的发现
F5在运行过程中，需要轮询已在设备上配置的SERVER列表，有问题的SERVER会被踢出，再进行用户请求数据的分配时，只按踢出后的SERVER列表进行随机分配，实现系统的稳定安全运行，保证用户系统操作的有效性。
通过修改F5健康检查机制，同时能发现Weblogic SERVER宕掉和系统无响应两种情况。但是在Weblogic SERVER无响应的情况下，F5健康检查机制的发现时间较长，加上踢出SERVER列表中有问题的SERVER，时间在5分钟以上，这期间整个系统性能受影响，影响用户的使用。
第四阶段：把系统性能受影响时间控制在1分钟以内
优化F5对Weblogic SERVER的健康检查脚本，缩短F5设备对列表中异常SERVER的监控与处理时间。号线系统厂家针对异常SERVER的监控新开发了一个JSP页面，在F5上配置对该页面的调用，发现3次调用无响应，视为异常SERVER，F5设备会直接将其从列表踢除，这样实现了从发现到处置Weblogic SERVER异常的时间在1分钟以内。
第五阶段：应用程序端及其它方面进行的调整优化
分析以前系统异常情况，多是因内存溢出（OOM）或者大对象区空间不足GC忙于回收。号线系统厂家在尽可能不影响用户使用情况下，对此进行了代码层面与数据库查询SQL方面的优化，减少频发的大对象。
开发用于监控各SERVER状态的JSP页面，在主机上配置TIMER，通访问调用此页面，发现异常SERVER，先执行kill -3 生成便于日后分析的Heapdump、Javacore文件，之后执行kill -9 杀掉异常SERVER，根据Weblogic配置的Auto Restart 功能参数将异常SERVER进行重起，保证不影响系统性能，实现无人值守时，仍能处置异常。同时该JSP页面也被使用在F5的监控中调用中。
配置第三方监控软件，对发现异常SERVER，新增javacore 、heapdump文件发送告知短信给相关负责人与维护人员，第一时间发现问题并处理。
结论
任何类型的系统故障都可能意味着收入、信誉和客户满意的巨大损失。资源管理系统使用F5负载均衡，系统宕机和系统慢问题得到了很好地解决。该问题的解决对改进用户满意度、降低反应性IT支持成本、提高 IT 生产力有着至关重要的作用。
关键词：C/S架构； 群集； F5负载均衡
一. F5负载均衡
负载均衡，英文名称为Load Balance，其意思就是将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。当某台SERVER设备发生故障，F5 将自动发现并不再把流量发送到这台故障的SERVER上，从而实现SERVER的高可用。
二.优化测试与方案实施中发现与解决的问题
第一阶段： 调整Weblogic配置参数
资源管理系统出现异常时最大的特点为：单个SERVER异常时，影响其它SERVER上的在用用户与用户的登录操作。在前期过程中，一直致力于单SERVER的参数的调整与优化，以避免单个SERVER的异常，其中包括 -Xmx2048m（最大堆内存）、-Xp8196K（堆碎片）、-Xloratio0.3 （大对象区比率），经反复的调整优化测试，相应的参数能够使系统相对平稳安全运行，但因大业务使用的需求，系统异常情况并未得到有效解决。因此又对针对Weblogic的Cluster集群机制进行了研究。
根据已有的资源系统C/S架构，客户端使用T3协议访问服务器上部署的应用，Cluster群集机制在8.1版本的使用上，存在性能问题，当群集中任何一个SERVER出现异常时，会导致整个系统运行缓慢。
为此，我们在测试环境进行了大量的测试，针对现有的资源管理系统客户端配置多个T3地址串的情况，测试发现异常SERVER及配置T3地址数量对用户登录耗时影响很大。以下是测试数据：
1.测试环境现状介绍：
测试环境为集群环境，两台主机，IP地址以192.168.1.1和192.168.1.2为例，每台主机部署3个应用服务，每个应用服务有自己的端口号
客户端单个T3地址样例：t3：// 192.168.1.1：9931
客户端T3地址串样例：t3：// 192.168.1.1：9931， 192.168.1.1：9932， 192.168.1.2：9922
2.测试用例
测试情况用例
2.1所有SERVER均正常，测试资源客户端配置SERVER由少到多对登录的影响
配1个T3地址 时间： 4s 5s 6s
配2个T3地址 时间：10s 9s 7s
配6个T3地址 時间：20s 15s 22s
以上数据，除去网络环境等因素影响，证明客户端配置SERVER的数量，会影响用户的登录时长。客户端配的T3地址串中SERVER数量越多，客户端登录越耗时。
2.2测试资源客户端配T3地址串中有shutdown状态的SERVER对登录影响
配2个T3地址1开1停 时间 ：12s
配3个T3地址2开1停 时间：9s 18s 14s 14s
配4个T3地址2开2停 时间：28s 28s 60s
配6个T3地址2开4停 时间：55s 52s
除去网络环境因素影响，多SERVER配置中，状态异常的SERVER或者繁忙的SERVER越多，登录耗时越长。也证明了客户端配置T3地址串后，会以某种机制询访T3串中的每个服务地址，异常SERVER对询访影响很大，但它位于T3串的前后位置对耗时几乎无任何影响。
针对上述的问题及规律，又进行了客户端询访机制的优化，客户端有一个参数控制程序对SERVER的询访时间：weblogic.jndi.requestTimeout ，默认时间为5s，这个时间压缩到1s。经测试该参数调整对上述两种场景的登录耗时有优化作用。
第二阶段：实现对F5负载均衡的支持
在经测试确定客户端进行随机分配并进入指定的SERVER的方案不可靠之后，经与F5设备厂家、Weblogic厂家多次沟通与测试，采用F5实现负载均衡的方案，实现基于T3协议的客户端与集群服务器之间的负载均衡。
首先通过现场研发8.1版本的Weblogic补丁，解除了F5负载均衡要求应用服务器上应用服务端口号和F5端口号一致的限制，在 F5侧配置客户端访问的T3协议地址，并建立该地址与资源12个SERVER服务间的映射关系。在功能上实现了现有环境对F5负载均衡的支持。
测试中发现，F5能将用户请求的数据流随机分配到某个SERVER上，通过该设备的这种机制实现了系统负载的均衡，在使用中，由于对Weblogic SERVER状态判断上有缺陷：只能发现SERVER宕掉，不能发现SERVER无响应，有时SERVER依然是Running状态，但是用户已经反映系统慢了，在这种情况下，系统整体性能会一直受影响。
第三阶段：实现了对Weblogic SERVER各种异常的发现
F5在运行过程中，需要轮询已在设备上配置的SERVER列表，有问题的SERVER会被踢出，再进行用户请求数据的分配时，只按踢出后的SERVER列表进行随机分配，实现系统的稳定安全运行，保证用户系统操作的有效性。
通过修改F5健康检查机制，同时能发现Weblogic SERVER宕掉和系统无响应两种情况。但是在Weblogic SERVER无响应的情况下，F5健康检查机制的发现时间较长，加上踢出SERVER列表中有问题的SERVER，时间在5分钟以上，这期间整个系统性能受影响，影响用户的使用。
第四阶段：把系统性能受影响时间控制在1分钟以内
优化F5对Weblogic SERVER的健康检查脚本，缩短F5设备对列表中异常SERVER的监控与处理时间。号线系统厂家针对异常SERVER的监控新开发了一个JSP页面，在F5上配置对该页面的调用，发现3次调用无响应，视为异常SERVER，F5设备会直接将其从列表踢除，这样实现了从发现到处置Weblogic SERVER异常的时间在1分钟以内。
第五阶段：应用程序端及其它方面进行的调整优化
分析以前系统异常情况，多是因内存溢出（OOM）或者大对象区空间不足GC忙于回收。号线系统厂家在尽可能不影响用户使用情况下，对此进行了代码层面与数据库查询SQL方面的优化，减少频发的大对象。
开发用于监控各SERVER状态的JSP页面，在主机上配置TIMER，通访问调用此页面，发现异常SERVER，先执行kill -3 生成便于日后分析的Heapdump、Javacore文件，之后执行kill -9 杀掉异常SERVER，根据Weblogic配置的Auto Restart 功能参数将异常SERVER进行重起，保证不影响系统性能，实现无人值守时，仍能处置异常。同时该JSP页面也被使用在F5的监控中调用中。
配置第三方监控软件，对发现异常SERVER，新增javacore 、heapdump文件发送告知短信给相关负责人与维护人员，第一时间发现问题并处理。
结论
任何类型的系统故障都可能意味着收入、信誉和客户满意的巨大损失。资源管理系统使用F5负载均衡，系统宕机和系统慢问题得到了很好地解决。该问题的解决对改进用户满意度、降低反应性IT支持成本、提高 IT 生产力有着至关重要的作用。