负载,
nginx,
upstream
本帖最后由 freyson 于 2010-9-6 16:28 编辑
nginx的upstrean目前支持4种方式的分配
1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
weight
指定轮询机率，weight和访问比率成正比，用于后端服务器性能不均的情况。
2、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
3、fair（第三方）
按后端服务器的相应时间来分配请求，相应时间短的优先分配。
下面我就给出fari的配置使用方法：
对于upstream_fair的负载，好处是，能自动识别真实服务器的是否坏了，如果坏了可以转发到别的服务器上，但是弊端必须要能监控到所有真实机，不然具体那一台服务器损坏我们不能确定，而且我看了网上的一些介绍，对于upstream_fair的很少。
给出一个官方的地址，上面有介绍如何去安装使用，http://nginx.localdomain.pl/wiki/UpstreamFair
我看了一下他官网上给出了，nginx0.6.31版本下的默认负载和fair负载的对比，我贴出来
default load balancer ¶
Document Path: /
Document Length: 3585 bytes
Concurrency Level: 500
Time taken for tests: 9.172814 seconds
Complete requests: 50000
Failed requests: 0
Write errors: 0
Total transferred: 192084569 bytes
HTML transferred: 179282265 bytes
Requests per second: 5450.89 [#/sec] (mean)
Time per request: 91.728 [ms] (mean)
Time per request: 0.183 [ms] (mean, across all concurrent requests)
Transfer rate: 20449.78 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 31 294.4 2 3012
Processing: 3 43 284.0 16 3043
Waiting: 2 41 283.9 14 3042
Total: 7 75 463.5 17 6045
Percentage of the requests served within a certain time (ms)
50% 17
66% 19
75% 20
80% 21
90% 24
95% 31
98% 88
99% 3024
100% 6045 (longest request)
upstream_fair ¶
Document Path: /
Document Length: 3585 bytes
Concurrency Level: 500
Time taken for tests: 9.289024 seconds
Complete requests: 50000
Failed requests: 0
Write errors: 0
Total transferred: 192073046 bytes
HTML transferred: 179271510 bytes
Requests per second: 5382.70 [#/sec] (mean)
Time per request: 92.890 [ms] (mean)
Time per request: 0.186 [ms] (mean, across all concurrent requests)
Transfer rate: 20192.76 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 35 349.8 2 8999
Processing: 1 35 235.8 16 3034
Waiting: 0 33 235.8 14 3030
Total: 8 71 451.2 17 9019
Percentage of the requests served within a certain time (ms)
50% 17
66% 19
75% 21
80% 22
90% 27
95% 32
98% 90
99% 3020
100% 9019 (longest request)
具体使用那一种负载，我们可以视应用的使用情况来定。
安装配置
首先下载upstream_fair的插件
http://github.com/gnosek/nginx-upstream-fair/tarball/master
然后把文件解压后存放到nginx的安装目录下
1、安装
./configure --prefix=/usr/local/nginx --with-http_stub_status_module --add-module=/backup/nginx-0.7.61/gnosek-nginx-upstream-fair
make && make install
然后配置
nginx.conf文件
upstream www.xxxxx.net {
server 192.168.168.29 ;
server 192.168.168.20 ;
fair;
}
upstream_fair不会影响网络的流量，这个给出一个完全的示例，比较好的把负载均衡器和upstream_fair结合起来。
upstream testing {
# fair;
server 127.0.0.1:81 max_fails=3 weight=2;
server 127.0.0.1:81 max_fails=3 weight=2;
server 127.0.0.1:81 max_fails=3 weight=2;
server 127.0.0.1:81 max_fails=3 weight=2;
server 127.0.0.1:81 max_fails=3 weight=2;
server 127.0.0.1:81 max_fails=3 weight=2;
}
这个模块不能分发nginx的来源，他只能将传入的请求发送到最不繁忙的后端服务器，而不是分配请求。
在这里我们要用到upstream_fair_shm_size的大小，一般我们这里默认的视32K
（对于共享内存大小的存储到后端，在大多数系统默认为8页。也就是32K
我们重新启动就可以使用upstream_fair模块了
4、url_hash（第三方）
按访问url的hash结果来分配请求，是每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
5、每个设备的状态设置
down 表示当前的server暂时不参与负载
weight 默认为1，weight越大，负载的权重就越大。
max_fails 允许请求失败的次数默认为1，当超过最大次数时，返回proxy_next_upstream模块定义的错误
fail_timeout max_fails次失败后，暂停的时间。
backup 其他所有的非backup机器down或者忙的时候，请求backup机器，所以这台机器严厉会最轻。
nginx支持同时设置多组的负载均衡，用来给不用的server来使用。
client_body_in_file_only 设置为on，可以讲client post 过来的数据纪录到文件中用来做debug
client_body_temp_path 设置纪录文件的目录，可以设置最多3曾目录
local 对url进行匹配，可以进行重定向或者进行新的代理 负载均衡
6、各个负载的弊端：
使用这种的负载方法，我发现一个问题，就是用户登陆，操作一段时间后注销，然后在用另外一个用户登录,切换至另一个界面会显示为上一次登录用户的信息!在apache下是不会出现这个问题的,这个问题是session出现的问题，如果使用ip_hash和upstream_hash（也就是默认的）都可以来解决session共享的问题。但是他们又有如下的弊端。
ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用：
1/ nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用
的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。
2/ nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一
台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，或者再搭一个squid，然后指向应用服务器。最好的办法是用 location作一次分流，将需要session的部分请求通过ip_hash分流，剩下的走其它后端去。
当前位置：
论坛首页 »
自由讨论区 »
Tomcat, WebLogic及J2EE讨论区
»
发起投票
技术讨论
加好友
发消息
2014-4-27 8:56:55 |
赞(
操作
