sadly
(sadly)
管理员
 
管理员
UID 1
精华
4
积分 2043
帖子 2032
金钱 1544 喜悦币
威望 40
人脉 459
阅读权限 200
注册 1970-1-1
来自 北京 三元桥
状态 离线
|
[广告]: q
m
软件方式的web负载测试
软件方式的web负载测试
http://blogger.org.cn/blog/more.asp?name=lhwork&id=22003
考试院的weblogic集群年前做完了，但是前端的负载却没有弄好，在家里也把人休息腻味了，免得生锈了，所以提前回来做两天有关的技术试验。
web的负载均衡虽然做了好多年，但是目前的应用还是基于L7硬件方式的负载均衡，考试院没有此类设备，必须依靠软件方式来解决负载问题。
通过一天的技术试验总结如下。
试验环境如下：
10.0.4.5 10.0.4.13 10.0.4.14
-------+-----------+--------------+---------
| | |
+--+--+ +--+--+-----+-+-+ +
| WC1 | | WL1 | | WL2 |
+-----+ +------+-----+------+
NFS server 2台weblogic节点
DB server
weblogic console
其中10.0.4.5 通过前端防火墙做了NAT映射外部公网IP，试验目的是通过10.0.4.5做负载或者应用重定向，将客户的web请求向两台weblogic负载节点转发，目前weblogic集群上已有发布的的java app产品。
一、PROXY反向代理方式的试验
proxy可以选用的方式有apache、squid等，这里以前者为主，参考APACHE2.2 中文DOC中mod_proxy部分，其中google中关于apache反向代理的有关文章也非常多，个人认为比较有用的几个：
Apache 2.2 中文版参考手册
http://doc.chinahtml.com/Manual/ApacheManual/mod/mod_proxy.html
基于Apache mod_proxy的反向代理缓存加速实现
http://www.chedong.com/tech/cache.html#apache
实验: 使用 Apache 反向代理实现负载均衡及热备
http://www.blogjava.net/thinkbase/archive/2006/10/11/74276.html
使用apache的mod_proxy来实现，实现过程如下，普通默认方式安装apache-2.2.4即可支持proxy，也可以哟通过httpd -l来看支持的加载模块，做反向代理修改httpd.conf即可；
首先使用最简单的mod_proxy配置；
引用
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://10.0.4.13:81
ProxyPass / http://10.0.4.14:82
这种配置反向代理仅仅作用于http://10.0.4.13:81，并不像DNS轮询配置那样的简单，不行。
然后使用另外一种配置；
引用
<VirtualHost *:80>
ServerAdmin wp1998@e21.edu.cn
ServerName localhost
ErrorLog logs/localhost-error_log
CustomLog logs/localhost-access_log common
# 这里类似定义一个负载的组，在组里面BalancerMember 定义节点
<Proxy balancer://ksyCluster>
BalancerMember http://10.0.4.13:81
# samx是声明启动这个节点所需的最小的连接数，loadfactor是判断负载的因子，取值在1－100之间，在apache的文档里有比较详细的说明
BalancerMember http://10.0.4.14:82 smax=1 loadfactor=2
</proxy>
# 这里定义一个访问的区域，因为我不需要本地的server-status也被代理转发了，所以这里定义server-status不使用proxy，一个!即可；
<Location /server-status>
ProxyPass !
</Location>
# 定义一个访问区域，proxypass定义了这个区域使用反向代理到上面定义的负载组，stickysession=JSESSIONID表示保持sesession会话的种类，我想应该是JSESSIONID或者PHPsessionid；
<Location />
ProxyPass balancer://ksyCluster/ stickysession=JSESSIONID
</Location>
</VirtualHost>
以上配置只能在虚拟主机区域内配置有效，经过试验证明用户的请求是可以均匀的指向到两个节点上；
但是实验中存在一个问题，在登陆到java应用中做一个web操作（验证一个用户）的时候，web目的始终指向到10.0.4.13或者10.0.4.14，仿佛没有经过10.0.4.5的proxy，因为java应用脚本不是我开发的，所以原因还是不太清楚，我估计可能是脚本内使用了重定向语句，类似php的header("localtion: URL....")，突破了proxy。
二、网络层协议负载方式的试验
使用网络层负载和proxy方式不同，倒是和我们目前使用的硬件负载均衡器的方式相同；
haproxy
http://http://haproxy.1wt.eu/
Balance/BalanceNG
http://www.inlab.de/balance.html
今天我试验的是haproxy，一个专门做TCP/HTTP负载均衡的软件，比较小安装也很简单。首先按照范例写了一个配置文件；
引用
global
log 127.0.0.1 local0 debug
maxconn 6000
daemon
listen appli1-rewrite 0.0.0.0:80
mode http
log global
cookie SERVERID rewrite
balance roundrobin
option httpchk
contimeout 5000
clitimeout 50000
srvtimeout 50000
server wl1 10.0.4.13:81 cookie check inter 2000 rise 2 fall 5
server wl2 10.0.4.14:82 cookie check inter 2000 rise 2 fall 5
使用haproxy -f test.cfg来启动之后，检查负载2节点指向正常，同时也未发生第一次proxy方式出现的问题，我想是由于这是从网络应用层指向的原因。haproxy的功能还不仅仅如此，目前还可以通过content内容匹配来做过指向的条件，可以说已经较为强大了。
综上，如果从web应用负载的角度来说应该选择后者，通过网络协议来实现负载和应用脚本没有太大关系，方式直接而且效率提高不少，但是proxy方式也有自己的优势，比如在域名空间的统一控制方面，他可以将分布在不同web服务器上的站点在一个域名区域下统一起来；再如cache加速也是proxy方式的一个极大优势，通过apache的mod_cache或者squid能够针对web的静态文件提高极大的处理效率。
个人认为一个完整的负载网站应该将这两者结合起来，集群的负载均衡器（硬或软）－》cache（squid）－》web应用服务器，按照这样的层次来布局才是超大规模站点所选。
相关的技术试验继续进行中。。。
| 
以PHP在中国的繁荣发展为己任
QQ:824008 MSN:sadly@phpx.com |
|
