Chinaunix首页 | 论坛 | 博客
  • 博客访问: 302024
  • 博文数量: 63
  • 博客积分: 1997
  • 博客等级: 上尉
  • 技术积分: 690
  • 用 户 组: 普通用户
  • 注册时间: 2007-09-29 11:17
文章分类

全部博文(63)

文章存档

2010年(26)

2009年(37)

我的朋友

分类:

2010-09-06 16:16:34

nginx的upstrean目前支持4种方式的分配


1、轮询(默认)

每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。

weight

指定轮询机率,weight和访问比率成正比,用于后端服务器性能不均的情况。


2、ip_hash

每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。


3、fair(第三方)

按后端服务器的相应时间来分配请求,相应时间短的优先分配。

下面我就给出fari的配置使用方法:


对于upstream_fair的负载,好处是,能自动识别真实服务器的是否坏了,如果坏了可以转发到别的服务器上,但是弊端必须要能监控到所有真实机,不然具体那一台服务器损坏我们不能确定,而且我看了网上的一些介绍,对于upstream_fair的很少。

给出一个官方的地址,上面有介绍如何去安装使用,


我看了一下他官网上给出了,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的插件

然后把文件解压后存放到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 {

     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,就不能根据iphash。譬如使用 的是squid为最前端,那么nginxip时只能得到squid的服务器ip地址,用这个地址来作分流是肯定错乱的。


2/ nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡,将请求又通过另外的方式分流了,那么某个客户端的请求肯定不能定位到同一 session应用服务器上。这么算起来,nginx后端只能直接指向应用服务器,或者再搭一个squid,然后指向应用服务器。最好的办法是用 location作一次分流,将需要session的部分请求通过ip_hash分流,剩下的走其它后端去。


阅读(2910) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~