正在浏览标签为 nginx 的文章

假设我这里有大量图像、CSS、javascript等静态文件,分别放在后端服务器  192.168.1.5 和 192.168.1.6上,那么我如何利用nginx的反向代理功能将不同的 http_user_agent 请求发送到指定的服务器上呢?如 "Mozilla" 转发到 192.168.1.5 ,MSIE  转发到 192.168.1.6 。

Nginx web 服务器支持if条件表达式,由此来跳转或者使用不同的配置变量。在本文中需要使用 $http_user_agent 变量,它标记了用户浏览器的类别,版本以及操作系统的一些信息,语法如下:

if ( condition ){
  do_something
}
if ( $http_user_agent = "wget" ){
   do_something
}
if ( $http_user_agent ~ MSIE ){
   return 403;
}

if指令会就检查后面表达式的值是否为真(true),如果为真,则执行后面大括号中的内容。以下是一些条件表达式的比较方法:
1、变量的完整比较可以使用=或!=操作符
2、 部分匹配可以使用正则表达式来表示,~或~*
3、~表示区分大小写
4、~*表示不区分大小写(firefox与FireFox是一样的)
5、!~与!~* 是取反操作,也就是不匹配的意思
6、检查文件是否存在使用 -f 或 !-f 操作符
7、检查目录是否存在使用-d或!-d操作符
8、检查文件,目录或符号连接是否存在使用-e或!-e操作符
9、检查文件是否可执行使用-x或!-x操作符
10、正则表达式的部分匹配可以使用括号,匹配的部分在后面可以用$1~$9变量代替,这些和apache一致。

例子:

编辑 /usr/local/nginx/conf/nginx.conf 文件
#vi /usr/local/nginx/conf/nginx.conf
设置upstream服务器:

upstream myproxybackend  {
       server 192.168.1.1;
       server 192.168.1.2;
       server 192.168.1.3;
       server 192.168.1.4;
}
 
upstream msiebackend  {
       server 192.168.1.6;
}
 
upstream mozillabackend  {
       server 192.168.1.5;
}

更新虚拟主机配置文件

server {
      access_log  logs/access.log;
      error_log   logs/error.log;
      index       index.html;
      listen      202.54.1.5:80 default;
      root        /usr/local/nginx/html;
      server_name example.com www.example.com 0.example.com;
 
     ## PROXY - Web
      location / {
        proxy_pass  http://myproxybackend;
        if ($http_user_agent ~ MSIE ) {
              proxy_pass  http://msiebackend;
        }
        if ($http_user_agent ~ Mozilla ) {
              proxy_pass  http://mozillabackend;
        }
 
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
# many more...
# many more...
}

最后重启/重新载入nginx
#/usr/local/nginx/sbin/nginx -s reload

原创文章,转载请注明: 转自 http://salogs.com

一、目的

利用autobench工具结合httperf命令对web服务器进行测试,得出该服务器可以承载的最大并发连接数与最佳并发数。

二、测试工具

工具介绍

1、Httperf

httperf 是一款高性能的HTTP测试工具,使用它我们可以准确定位服务器的并发连接能力。下面介绍一下它的主要特征

(1) 可以观察测试客户端(并非被测服务器)在发起压力测试时的负载情况。这样在测试高并发的情况下可以准确的分析问题。(被测服务器无法承载高并发还是测试客户端无法发起过多请求)
(2)支持HTTP/1.1和SSL
(3)可以生成可扩展的测试计划

下载http://code.google.com/p/httperf/downloads/list

安装
# tar xvzf httperf-0.9.0.tar.gz
# cd httperf-0.9.0
#./configure
# make && make install

更多的使用方法参见man page。

2、autobench

autobench 是一款基于httperf的Perl脚本。它会在一次测试中调用多次httperf来对web服务器进行测试,每次会按照给定的参数增加并发连接数,将httperf的测试结果保存为CSV格式的文件,该文件可以被Excel直接读取,方便生成测试报告。借助于autobench自带的bench2graph工具可以生成漂亮的测试结果对比图,如下:

results.gif

下载:http://www.xenoclast.org/autobench/downloads/

安装

# yum install gd gnuplot pcre pcre-devel texinfo -y
# tar zxvf autobench-2.1.2.tar.gz
# cd autobench-2.1.2
# make && make install
# sed -i 's/postscript color/png xffffff/g' /usr/local/bin/bench2graph (修改bench2graph脚本,否则生成的图像背景有问题)

使用方法:参见下文在实际测试中的使用

三、测试环境

系统环境
CentOS 5.3 64bit

web软件环境
httpd-2.0.6
php5.2.6+ eAccelerator
php-fpm  开启20个php-cgi进程
nginx-0.7.67

在测服务器并发能力时会将apache与nginx对比测试

硬件环境

CPU::E5504  2.00GHz
内存:1G
虚拟机环境

四、测试方法

1、  分别测试静态文件和动态php文件
2、  静态并发数从50开始,1500结束,增长幅度为50,动态5~100,增幅为5
3、  分别测试apache和nginx的并发能力,二者进行对比
4、  每次测试进行3次,最终结果求三次平均值
5、  每进行一次测试后均重启httpd或nginx(php-fpm)服务,释放内存后再进行下一轮测试
6、  为了减少磁盘IO,均关掉了访问日志

1、开始测试

(1)静态文件

测试命令

# autobench --single_host --host1=192.168.8.8 --port1=80 --uri1=/logo.gif  --quiet  --low_rate=50 --high_rate=1500 --rate_step=50 --num_call=1 --num_conn=2000 --timeout=10 --file /tmp/result.tsv

测试结果对比分析
static.png

测试结果总结:

Apache与Nginx在并发50~1500时表现得都还可以,只不过在并发数达到1500后Apache的响应时间变得很长,由于系统环境的制约,我没有再测试大于1500的并发连接情况,但可以对比看出nginx在1500个并发连接的情况下还能保持较低的响应时间。

(2)动态文件

测试命令

# autobench --single_host --host1=192.168.8.8 --port1=80 --uri1=/test.php --quiet --low_rate=5 --high_rate=100 --rate_step=5 --num_call=1 --num_conn=200 --timeout=10 --file /tmp/nginx_php1.tsv

测试结果数据

并发连接数 nginx实际并发数 apache实际并发数 nginx应答时间 apache应答时间
5.0 5.0 5.0 36.0 36.3
10.0 10.0 10.0 33.0 31.7
15.0 15.0 15.0 35.6 31.9
20.0 19.9 19.9 36.8 32.3
25.0 25.0 25.0 42.6 36.2
30.0 29.8 29.7 45.1 67.6
35.0 34.3 32.4 115.5 248.5
40.0 35.5 34.9 396.8 427.3
45.0 35.3 33.4 699.0 865.8
50.0 35.7 30.5 962.3 1394.0
55.0 35.5 33.3 1103.9 1354.7
60.0 35.7 32.9 1269.2 1471.3
65.0 34.9 33.5 1445.8 1573.6
70.0 37.6 29.7 1458.0 2049.5
75.0 37.2 35.9 1610.1 1496.8
80.0 23.9 31.2 1588.2 1993.3
85.0 24.7 33.2 1674.9 1880.2
90.0 37.1 34.5 1838.6 1946.0
95.0 35.0 30.3 2027.4 2387.2
100.0 35.3 36.4 1996.3 1904.5

测试数据

测试结果对比图
total_php-2.png

测试总结

由上面的报表以及这张曲线图可以看出,无论是apache还是nginx其php并发大于30其响应时间的就会直线上升,nginx略好于apache,因此可以判断这台服务器的php并发极限在30左右,当然这里指的php连接中是没有连接数据库的,也没有加入memcached等缓存机制。

(3)高并发下系统资源情况

CPU使用情况对比
cpu.png


内存使用情况对比

memory.png

系统负载对比
load.png

分析测试结果

CPU使用情况
在极限并发的情况下apache和nginx都占用很多CPU资源,这也是情理之中的事          情。nginx略好于apache平均占用90%而apache则在95%左右

内存使用情况
在内存对比中可以清楚的看到,nginx在极限并发的情况下内存控制得很好,到达一定程度后就不在变化了,而apache则会直线上升

负载情况
负载情况与内存情况类似,如果高并发时间很长的话apache服务器绝对会挂掉!nginx的负载也很高,但一直保持在10以下,这也和内存占用有关。

五、结论

利用httperf结合autobench可以很方便的测试出单台服务器的极限并发数,这样对服务器性能评估有很大帮助,借助于autobench的bench2graph脚本可以生成更为直观的对比图。

针对被测服务器,经过apache与nginx的对比发现,在静态文件的处理方面如果并发小于1500,apache和nginx之间的差距还是很小的。在动态php文件的并发测试中,nginx体现出其强大的性能优势,如果内存足够大,通过调整php-cgi数量,相信可以承载更多的并发连接。

六、附录

1、问题解决

(1)当运行时报如下错误

httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE

解决方法

其意思是说在httperf在发起连接请求时,单个进程已经无法再打开更多的文件描述符。在发起连接请求时httperf使用select()方法使用一个新的文件描述符。因此需要增加文件描述符限制

步骤1:编辑/etc/security/limits.conf 在最后添加下面两行内容
*       hard    nofile          102400
*       soft    nofile          102400

步骤2:编辑 /usr/include/bits/typesizes.h 文件修改__FD_SET_SIZE常量值,如下
#define __FD_SETSIZE            1024
修改为
#define __FD_SETSIZE            102400

步骤3:重新编译httperf

2、参考文章

http://www.cppblog.com/qiujian5628/archive/2008/03/10/44060.html
http://wiki.nginx.org/
http://www.joeandmotorboat.com/2008/02/28/apache-vs-nginx-web-server-performance-deathmatch/

原创文章,转载请注明: 转自 http://salogs.com

漏洞介绍:nginx是一款高性能的web服务器,使用非常广泛,其不仅经常被用作反向代理,也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题,默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析,这将导致严重的安全问题,使得恶意的攻击者可能攻陷支持php的nginx服务器。

漏洞分析:nginx默认以cgi的方式支持php的运行,譬如在配置文件当中可以以

location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}

的方式支持对php的解析,location对请求进行选择的时候会使用URI环境变量进行选择,其中传递到后端Fastcgi的关键变量 SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定,而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的,这里就是产生问题的点。而为了较好的支持PATH_INFO的提取,在PHP 的配置选项里存在cgi.fix_pathinfo选项,其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
那么假设存在一个http://www.80sec.com/80sec.jpg,我们以如下的方式去访问

http://www.80sec.com/80sec.jpg/80sec.php

将会得到一个URI
/80sec.jpg/80sec.php

经过location指令,该请求将会交给后端的fastcgi处理,nginx为其设置环境变量SCRIPT_FILENAME,内容为

/scripts/80sec.jpg/80sec.php

而在其他的webserver如lighttpd当中,我们发现其中的SCRIPT_FILENAME被正确的设置为

/scripts/80sec.jpg

所以不存在此问题。
后端的fastcgi在接受到该选项时,会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理,一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用,所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字,查找的方式也是查看文件是否存在,这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为

/scripts/80sec.jpg和80sec.php

最后,以/scripts/80sec.jpg作为此次请求需要执行的脚本,攻击者就可以实现让nginx以php来解析任何类型的文件了。

POC: 访问一个nginx来支持php的站点,在一个任何资源的文件如robots.txt后面加上/80sec.php,这个时候你可以看到如下的区别:

访问http://www.80sec.com/robots.txt

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
Content-Type: text/plain
Content-Length: 18
Last-Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes

访问访问http://www.80sec.com/robots.txt/80sec.php

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.6

其中的Content-Type的变化说明了后端负责解析的变化,该站点就可能存在漏洞。

漏洞厂商:http://www.nginx.org

解决方案:

我们已经尝试联系官方,但是此前你可以通过以下的方式来减少损失

关闭cgi.fix_pathinfo为0

或者

if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}

PS: 鸣谢laruence大牛在分析过程中给的帮助

转自:http://www.80sec.com/nginx-securit.html


看过这篇文章,和同事讨论了一下,其中上文提到的解决方法2,实际上还是无法解决问题的。如果允许用户上传,最好还是在允许上传文件的程序中判断用户上传的文件类型,如:是否为text/xxx类型的文件,如果是则还需要再判断该文件中是否有可执行的php脚本。

针对解决方法1,不建议修改,其可能会影响正常程序的运行。

以下是我们的处理方法:限制uploads目录下的php程序执行

...
    location ~ ^/.+\.php(/.*)?$ {
      set $script    $fastcgi_script_name;

      if ($script ~* "^/uploads/.+"){
        return 404;
      }
...

测试目的

(1)弄清楚HTTP Upstream 模块中Server指令的max_failsfail_timeout参数的关系、它们对后端服务器健康情况的检查起到了什么作用、它们的取值对Http proxy模块中的其它指令是否有直接或间接的影响等……

(2)测试HTTP Proxy模块中proxy_next_upstream、proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout指令的作用、对nginx性能的影响、对后端服务器响应的处理等……

测试方法

本文测试不会使用压力测试,所有的测试都是通过浏览器手动刷新来实现的。后端服务器使用简单的php程序来实现。

测试环境

Nginx负载均衡/反向代理服务器
系统:CentOS 5.4 64bit
Nginx:0.7.65
IP:192.168.108.10

后端web服务器
系统:CentOS 5.4 64bit
Web环境:apache+php
Web-1 IP:192.168.108.163
Web-2 IP:192.168.108.164

本次测试主要针对HTTP Upstream和HTTP Proxy模块进行,下面测试环境中http upstream 和http proxy模块参数的初始化设置,后文会针对测试的参数进行相应的修改:


upstream test  {
server 192.168.108.163 ;
server 192.168.108.164:80;
}

server {
listen          80;
server_name     .test.com;
index           index.php index.html index.htm;

location / {
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;

proxy_connect_timeout       10s;
proxy_read_timeout          2s;
#proxy_send_timeout          10s;
proxy_pass http://test;
}
}

提出server指令后面的参数部分,以下摘抄nginx wiki 内容

语法:server name [parameters]

parameters包含:

·weight = NUMBER - 设置服务器权重,默认为1。

·max_fails = NUMBER - 在一定时间内(这个时间在fail_timeout参数中设置)检查这个服务器是否可用时产生的最多失败请求数,默认为1,将其设置为0可以关闭检查,这些错误在proxy_next_upstream或fastcgi_next_upstream(404错误不会使max_fails增加)中定义。

·fail_timeout = TIME - 在这个时间内产生了max_fails所设置大小的失败尝试连接请求后这个服务器可能不可用,同样它指定了服务器不可用的时间(在下一次尝试连接请求发起之前),默认为10秒,fail_timeout与前端响应时间没有直接关系,不过可以使用proxy_connect_timeout和 proxy_read_timeout来控制。

·down - 标记服务器处于离线状态,通常和ip_hash一起使用。

·backup - (0.6.7或更高)只用于本服务器,如果所有的非备份服务器都宕机或繁忙。

关于max_fails参数的理解根据上面的解释,max_fails默认为1,fail_timeout默认为10秒,也就是说,默认情况下后端服务器在10秒钟之内可以容许有一次的失败,如果超过1次则视为该服务器有问题,将该服务器标记为不可用。等待10秒后再将请求发给该服务器,以此类推进行后端服务器的健康检查。但如果我将max_fails设置为0,则代表不对后端服务器进行健康检查,这样一来fail_timeout参数也就没什么意义了。那若后端服务器真的出现问题怎么办呢?上文也说了,可以借助proxy_connect_timeout和proxy_read_timeout进行控制。

下面介绍http proxy模块中的相关指令:

proxy_next_upstream
语法: proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off]
确定在何种情况下请求将转发到下一个服务器。转发请求只发生在没有数据传递到客户端的过程中。

proxy_connect_timeout
后端服务器连接的超时时间_发起握手等候响应超时时间

proxy_read_timeout
连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理(也可以说是后端服务器处理请求的时间)

proxy_send_timeout
后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

proxy_pass
这个指令设置被代理服务器的地址和被映射的URI

开始测试

情况1:后端程序执行时间超过或等于proxy_read_timeout设置值,max_fails=0 关闭后端服务器健康检查。

Nginx配置修改内容 server 192.168.108.163 max_fails = 0;
server 192.168.108.164 max_fails = 0;
proxy_next_upstream error timeout
proxy_read_timeout 2s
后端web服务器
Web1 test.php Web2 test.php
<?php
header('RS:Web1');
$t = 2;
sleep($t);
echo "sleep {$t}s<br>";
echo "web-1<br>";
?>
<?php
header('RS:Web2');
$t = 5;
sleep($t);
echo "sleep {$t}s<br>";
echo "web-2<br>";
?>
备注:

我这里的两台后端web服务器,他们的主页文件均为一个test.php程序,该程序分别sleep了2秒和5秒,等于和超过了proxy_read_timeout的时间,[max_fails=0] 即关闭后端服务器健康检查。[proxy_next_upstream error timeout] 说明碰到错误或超时的情况切到下一个后端服务器。如此设置后利用curl命令对nginx发起连接请求,看nginx会作何反应。

测试开始:

(1)curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 02:43:08 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive

4.008:0.002:4.007

说明:

连续请求3次后得到的http返回结果是一样的,均为504 Gateway Time-out 错误。这种情况只有在后端服务器都有问题的时才会出现这个错误,很显然我这里的proxy_read_timeout设置的时间太短,后端程序还没来得及把程序执行完,nginx就迫不及待的将请求甩给upstream定义的另一台服务器上了,当发现另外一台服务器同样2秒没有返回后,nginx这回没有服务器可用,只有返回504 Gateway Time-out 。这也是为什么最后的time_total时间是4秒。(经查看两台web服务器的访问日志得知,均有一条访问记录,且返回代码为200,说明nginx确实来过,但没有等到执行完成就匆匆的离去了)如果我有3台服务器,在保证任何不变的情况下,time_total时间一定会是6秒,因为nginx会一个接一个的将3台服务器都走一遍。

-----------------------------------------------------------------------------------------------------------------------

好了,确认是我proxy_read_timeout设置时间太短后,我将它的值设置为3秒,再通过curl命令访问:

(2)curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 03:07:58 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1

5.042:0.005:5.042

说明:通过3次连续请求,得到的结果是一样的,RS:Web1 也就是说我这三次的请求都甩到了web1上。但我web1中的程序只需要2秒后就可以返回结果,但为什么我通过nginx代理后时间总是我的 程序执行时间+proxy_read_timeout时间呢?

-----------------------------------------------------------------------------------------------------------------------

继续将proxy_read_timeout设置为4s

(3)curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 03:15:25 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1

6.004:0.000:6.004

三次请求后结果也是一样,这次花的时间更长了,但确实是程序执行时间+proxy_read_timeout 时间。但为什么每次都需要6秒呢?按照upstream中定义的权重应该是平分请求的,最起码应该有2秒的时候。经过分析得知:最终返回给用户请求的是web1,那么当再次请求的时候一定会分给web2,由于web2是sleep 5秒的,因此经过proxy_read_timeout的时间(4s)后会跳到web1,结果还是web1返回的请求,所花时间就是nginx在web2等待的时间+web1执行的时间,以此类推下一次nginx自然的还会分给web2……。如果有更多的后端web,则判断下一个请求服务器可以看当前返回给最终用户的是那台服务器,然后根据upstream中定义的顺序向下查询(权重一样的情况)

结论:

(1)上面的三次测试分别将proxy_read_timeout的值设置为2s、3s、4s的情况进行的。最终的测试结果也都在后面做了解释与说明。由于我关闭了后端服务器的健康检查(max_fails=0)因此判断后端服务器情况的唯一依据便是proxy_read_timeout参数,如果这个参数设置得过小,但后端程序的执行或多或少会超过这个时间的话,这种情况nginx的效率是非常低的。

(2)上面的测试都是后端服务器正常但执行超时的情况下nginx根据proxy_read_timeout和proxy_next_upstream的值来选择下一个服务器,那如果我后端服务器直接报错的情况呢?可以想到如果报错信息在proxy_next_upstream 中有定义的话nginx还会跳到下一台服务器。否则直接将保存信息返回给nginx从而最终呈献给用户

情况2:打开后端服务器健康检查,测试程序执行时间超过或等于proxy_read_timeout值或后端服务器直接报错的情况

Nginx配置修改内容 server 192.168.108.163 max_fails = 1;
server 192.168.108.164 max_fails = 1;
proxy_next_upstream error timeout http_500 http_502 http_504
proxy_read_timeout 2s
后端web服务器
Web1 test.php Web2 test.php
<?php
header('RS:Web1');
$t = 2;
sleep($t);
echo "sleep {$t}s<br>";
echo "web-1<br>";
?>
<?php
header('RS:Web2');
header('http/1.1 500 Internal Server Error ');
#$t = 5;
#sleep($t);
echo "sleep {$t}s<br>";
echo "web-2<br>";
?>
备注:

开启了后端服务器健康检查
proxy_read_timeout 2s (下面会随着测试变更)
Web1程序仍然sleep 2s
修改了Web2程序,让他直接返回500错误

测试开始:

(1)连续测试三次结果如下:

curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:48 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive

2.005:0.001:2.005

curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 502 Bad Gateway
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:50 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 173
Connection: keep-alive

0.001:0.001:0.001

curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:57 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive

2.005:0.001:2.005

说明:

第1次请求所用时间是2秒,web1执行超时,web2返回了500错误,upstream没有更多的后端,因此nginx直接把504扔出来了,同时标记web2,web1不可用。查看后端2台web服务器的访问日志,均有nginx代理的访问记录。
第2次请求时间很短,报502错误,说明没有可用的后端服务器接受请求。查看后端两台web服务器访问日志,没有任何变化,说明这两台服务器被nginx标记为不可用,没有把请求转向后端,直接返回用户502错误
第3次请求同第1次

(2)修改 proxy_read_timeout 3s 连续访问6次后结果以及2台web服务器的日志情况
curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:30:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1

2.003:0.001:2.002

访问日志

Web1
[18/May/2010:15:30:00
[18/May/2010:15:30:03
[18/May/2010:15:30:05
[18/May/2010:15:30:08
[18/May/2010:15:30:11
[18/May/2010:15:30:13

Web2

[18/May/2010:15:30:00
[18/May/2010:15:30:11

说明:

由访问日志可知:
第1次请求是被分到web2上的,由于它返回了500错误,因此请求被转到web1,并标记web2不可用。
第2次至第4次均将请求给了web1,第四次请求完毕后距第一请求已经过去了8秒。
第5次请求时已经是fail_timeout参数默认的10s也就是标记web2不可用的时间已经过去了,因此在第5次访问实际上和第一次情况是一样的。

结论:

(1proxy_next_upstream参数很有用,他可以避免很多错误
(2max_fails 参数在繁忙的大型系统中建议设置为3,如果没有几个后端服务器的话保持默认即可。
(3proxy_read_timeout要根据自身程序而定,不要过大,也不要太小。如果是php程序,请参照php.ini中的max_execution_time选项值。

原创文章,转载请注明:   转自 http://salogs.com

如今利用nginx做负载均衡的实例已经很多了,针对不同的应用场合,还有很多需要注意的地方,本文要说的就是在通过CDN 后到达nginx做负载均衡时请求头中的X-Forwarded-For项到底发生了什么变化。下图为简单的web架构图:

nginx_x_forwarded_for.png
nginx 负载均衡

先来看一下X-Forwarded-For的定义:
X-Forwarded-For:简称XFF头,它代表客户端,也就是HTTP的请求端真实的IP,只有在通过了HTTP 代理或者负载均衡服务器时才会添加该项。它不是RFC中定义的标准请求头信息,在squid缓存代理服务器开发文档中可以找到该项的详细介绍。
标准格式如下:
X-Forwarded-For: client1, proxy1, proxy2
从标准格式可以看出,
X-Forwarded-For头信息可以有多个,中间用逗号分隔,第一项为真实的客户端ip,剩下的就是曾经经过的代理或负载均衡的ip地址,经过几个就会出现几个。

按照上图的Web架构图,可以很容易的看出,当用户请求经过CDN后到达Nginx负载均衡服务器时,其X-Forwarded-For头信息应该为 客户端IP,CDN的IP 但实际情况并非如此,一般情况下CDN服务商为了自身安全考虑会将这个信息做些改动,只保留客户端IP。我们可以通过php程序获得X-Forwarded-For信息或者通过Nginx的add header方法来设置返回头来查看。

下面来分析请求头到达Nginx负载均衡服务器的情况;在默认情况下,Nginx并不会对X-Forwarded-For头做任何的处理,除非用户使用proxy_set_header 参数设置:
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

$proxy_add_x_forwarded_for变量包含客户端请求头中的"X-Forwarded-For",与$remote_addr用逗号分开,如果没有"X-Forwarded-For" 请求头,则$proxy_add_x_forwarded_for等于$remote_addr。

$remote_addr变量的值是客户端的IP

当Nginx设置X-Forwarded-For等于$proxy_add_x_forwarded_for后会有两种情况发生

1、如果从CDN过来的请求没有设置X-Forwarded-For头(通常这种事情不会发生),而到了我们这里Nginx设置将其设置为$proxy_add_x_forwarded_for的话,X-Forwarded-For的信息应该为CDN的IP,因为相对于Nginx负载均衡来说客户端即为CDN,这样的话,后端的web程序时死活也获得不了真实用户的IP的。

2、CDN设置了X-Forwarded-For,我们这里又设置了一次,且值为$proxy_add_x_forwarded_for的话,那么X-Forwarded-For的内容变成 ”客户端IP,Nginx负载均衡服务器IP“如果是这种情况的话,那后端的程序通过X-Forwarded-For获得客户端IP,则取逗号分隔的第一项即可

如上两点所说,如果我们知道了CDN设置了X-Forwarded-For信息,且只有客户端真实的IP的话,那么我们的Nginx负载均衡服务器可以不必理会该头,让它默认即可。

其实Nginx中还有一个$http_x_forwarded_for变量,这个变量中保存的内容就是请求中的X-Forwarded-For信息。如果后端获得X-Forwarded-For信息的程序兼容性不好的话(没有考虑到X-Forwarded-For含有多个IP的情况),最好就不要将X-Forwarded-For设置为 $proxy_add_x_forwarded_for。应该设置为$http_x_forwarded_for或者干脆不设置!

参考文章:http://en.wikipedia.org/wiki/X-Forwarded-For

原创文章,转载请注明: 转自 http://salogs.com


需求1:CDN小节点使用尽可能少的资源实现高可用和负载均衡
需求2:需要支持10多个HTTPS站点的反向代理
后端环境:nginx在前端做url_hash,后端缓存服务器使用squid和lighttpd分别处理动静态内容,服务器证书在nginx上
解决方案:
使用keepalived来实现前端3台nginx的高可用,DNS轮询来均摊负载。
每个https站点使用一个独立IP,非https站点分摊到这些IP上。
在每台机器的lo上绑定所有的IP来启动nginx服务。

架构图:

原理:
正常情况下负载均摊,每台机器只负担2-3个HTTPS站点,比如此时nginxA只负责192.168.0.101和192.168.0.102这2个HTTPS站点。当nginxB挂掉时,nginxA和nginxC会根据策略去分担192.168.0.103和192.168.0.104这2个站点的访问,这时nginxA上负担的站点就可能就是192.168.0.101、192.168.0.102和192.168.0.104了。

分配策略:

lo绑ip脚本:

#!/bin/sh
echo '2' > /proc/sys/net/ipv4/conf/lo/arp_announce
echo '1' > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo '2' > /proc/sys/net/ipv4/conf/all/arp_announce
echo '1' > /proc/sys/net/ipv4/conf/all/arp_ignore

ifconfig lo:1 198.188.225.101 netmask 255.255.255.255
ifconfig lo:2 198.188.225.102 netmask 255.255.255.255
ifconfig lo:3 198.188.225.103 netmask 255.255.255.255
ifconfig lo:4 198.188.225.104 netmask 255.255.255.255
ifconfig lo:5 198.188.225.105 netmask 255.255.255.255
ifconfig lo:6 198.188.225.106 netmask 255.255.255.255

Ngnix A配置文件范例:
! Configuration File for keepalived

global_defs {
notification_email {
du@nli0n@snda.com
}
notification_email_from nginx_ha1@snda.com
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id nginx_ha1
}

vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.101
192.168.0.102
}
}

vrrp_instance VI_2 {
state BACKUP
interface eth0
virtual_router_id 52
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.103
192.168.0.104
}
}

vrrp_instance VI_3 {
state BACKUP
interface eth0
virtual_router_id 53
priority 50
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.105
192.168.0.106
}
}

来自nginx wiki

The module ngx_http_core_module supports the built-in variables, whose names correspond with the names of variables in Apache.

First of all, these are the variables, which represent the lines of the title of the client request, for example:
$http_host
$http_user_agent
$http_referer
$http_via
$http_x_forwarded_for
$http_cookie
$content_length
$content_type

Furthermore, there are other variables:

$arg_PARAMETER, this variable contains the value of the GET request variable PARAMETER if present in the query string

$args, this variable is equal to arguments in the line of request;

$content_length, this variable is equal to line “Content-Length” in the header of request;

$content_type, this variable is equal to line “Content-Type” in the header of request;

$document_root, this variable is equal to the value of directive root for the current request;

$document_uri, the same as $uri;

$host, this variable is equal to line “Host” in the header of request or name of the server, to whom the request arrived, if there is no this line;

$is_args evaluates to “?” if $args is set, “” otherwise.

$limit_rate, the variable allows to limit connection rate;

$query_string, the same as $args;

$request_method, this variable is equal to the method of request, usually this “GET” or “POST”;

$remote_addr, this variable is equal to the address of client;

$remote_port, this variable is equal to the port of client;

$remote_user, this variable is equal to the name of user, authenticated by ngx_http_auth_basic_module;

$request_filename, this variable is equal to path to the file for the current request, formed from directives root or alias and URI request;

$request_body_file, client request body temporary filename;

$request_uri, this variable is equal to the complete initial URI together with the arguments;

$scheme, the HTTP scheme (http, https). Evaluated only on demand, for example:

rewrite ^(.+)$ $scheme://example.com$1 redirect;

$server_protocol, this variable is equal to the protocol of request, usually this “HTTP/1.0″ or “HTTP/1.1″;

$server_addr, the variable is equal to the server address, to whom arrived the request. As a rule, for obtaining the value of this variable is done one system call. In order to avoid system call, it is necessary to indicate addresses in directives listen and to use parameter bind;

$server_name, this variable is equal to the name of the server, to whom arrived the request;

$server_port, this variable is equal to the port of the server, to which the request arrived;

$uri, this variable is equal to current URI in the request, it can differ from initial, for example by internal redirects, or with the use of index it is file with internal redirects.

nginx的性能远远优于apache,但由于nagios的web界面中包含php和c-cgi程序,因此需要两套fcgi管理工具(并非必须)和两套解释器(必须)。php用php-cgi跑就可以,c-cgi我选用fcgiwrap。下面介绍安装/配置步骤。

环境介绍:

先前环境:apache+php+nagios 除了nagios 其余的都使用yum自动安装
目标环境:nginx+php5.2.10(php-fpm patch)+nagios 均为源码编译安装

php-fpm:是为PHP打的一个FastCGI管理补丁,可以平滑变更php.ini配置而无需重启php-cgi
Spawn-fcgi:是lighttpd的一个分支项目,是一个cgi进程的管理器

● php 打php-fpm补丁,编译时启用--enable-fastcgi --enable-fpm 参数,使用php-fpm管理php-cgi。php安装详细步骤参见 张宴文章:http://blog.s135.com/nginx_php_v5/
● c-cgi 使用 Spawn-fcgi 管理 ,利用fcgiwrap驱动。fcgiwrap 介绍参见 http://nginx.localdomain.pl/wiki/FcgiWrap

php-cgi 监听 127.0.0.1:9000
fcgiwrap 监听 127.0.0.1:10000

nagios 安装配置不是本文重点,略过。web 目录如下:
/usr/local/nagios/share

安装配置

yum install fcgi fcgi-devel -y

php-fpm 的配置与运行这里略过,下面主要讲解Spawn-fcgi+fcgiwrap 的安装与配置

spawn-fcgi

# wget http://www.lighttpd.net/download/spawn-fcgi-1.6.2.tar.gz
# tar -xvzf spawn-fcgi-1.6.2.tar.gz
# cd spawn-fcgi-1.6.2/
# ./configure
# make
# cp src/spawn-fcgi /usr/local/bin/

fcgiwrap

# wget http://github.com/gnosek/fcgiwrap/tarball/master
# tar -xvzf gnosek-fcgiwrap-28ac6f9aa5e7dadf9aaf2062ab003a0fb4c82ad8.tar.gz
# cd gnosek-fcgiwrap-28ac6f9aa5e7dadf9aaf2062ab003a0fb4c82ad8/
# make
# mv fcgiwrap /usr/local/bin/

创建一个shell脚本来用spawn-fcgi 启动fcgiwrap实例
# vi /usr/local/bin/c-fcgi.sh

#!/bin/sh
/usr/local/bin/spawn-fcgi -f /usr/local/bin/fcgiwrap -a 127.0.0.1 -p 10000 -F 3 -P /var/run/fastcgi-c.pid -u www -g www

# chmod +x /usr/local/bin/c-fcgi.sh

创建一个系统启动进程,方便使用service 和chkconfig 命令管理
# vi /etc/init.d/c-fcgi

#!/bin/bash
# c-fcgi - this script starts and stops the fcgiwrap instance
#
# chkconfig:   - 96 28
# description:  c-fcgi
# processname: c-fcgi

C_SCRIPT=/usr/local/bin/c-fcgi.sh

RETVAL=0

case "$1" in
start)
echo "Starting fastcgi"
$C_SCRIPT
RETVAL=$?
;;
stop)
echo "Stopping fastcgi"
killall -9 fcgiwrap
RETVAL=$?
;;
restart)
echo "Restarting fastcgi"
killall -9 fcgiwrap
$C_SCRIPT
RETVAL=$?
;;
*)
echo "Usage: c-fastcgi {start|stop|restart}"
exit 1
;;
esac
exit $RETVAL
# <span style="color: #0000ff;">chkconfig --add c-fcgi</span>
# <span style="color: #0000ff;">chkconfig c-fcgi on</span>
# <span style="color: #0000ff;">service c-fcgi start</span>

验证启动,是否提供了相应的端口
# netstat -tulnp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 127.0.0.1:9000              0.0.0.0:*                   LISTEN      32629/php-cgi
tcp        0      0 127.0.0.1:10000             0.0.0.0:*                   LISTEN      20039/fcgiwrap

# ps -ef | grep fcgiwrap | grep -v grep

www      20039     1  0 15:20 ?        00:00:00 /usr/local/bin/fcgiwrap
www      20040     1  0 15:20 ?        00:00:00 /usr/local/bin/fcgiwrap
www      20041     1  0 15:20 ?        00:00:00 /usr/local/bin/fcgiwrap

# ps -ef | grep php-cgi | grep -v grep

root     32629     1  0 13:37 ?        00:00:00 /usr/local/php/bin/php-cgi --fpm --fpm-config /usr/local/php/etc/php-fpm.conf
.
.
.
www      32642 32629  0 13:37 ?        00:00:00 /usr/local/php/bin/php-cgi --fpm --fpm-config /usr/local/php/etc/php-fpm.conf

我php-fpm配置启动32个php-cgi 实例

配置nginx

user                www www;
worker_cpu_affinity 0001 0010 0100 1000;
worker_processes        4;

# 可以在下方直接使用 [ debug | info | notice | warn | error | crit ]  参数
error_log   /usr/local/nginx/logs/nginx_error.log   crit;

pid     /var/run/nginx.pid;

#进程所能打开的最大文件描述符个数
worker_rlimit_nofile    51200;

events
{
# linux 2.6+ 版本以上的内核推荐使用 epoll 事件模式
use             epoll;

# 最大连接数=worker_processes*worker_connections/4
worker_connections  4096;
}

http
{
include     ./conf.d/mime.types;
default_type    application/octet-stream;

charset utf-8;

server_names_hash_bucket_size   128;
client_header_buffer_size       32k;
large_client_header_buffers     4   32k;
client_max_body_size            8m;

sendfile        on;
tcp_nopush  on;

keepalive_timeout   60;

tcp_nodelay     on;

# global fastcgi configure
include         ./conf.d/fastcgi_custom.conf;

# include fastcgi_params.conf
include               ./conf.d/fastcgi_params.conf;

# gzip configure
include         ./conf.d/gzip.conf;

#limit_zone  crawler  $binary_remote_addr  10m;

server
{
listen          80;
server_name     cacti.opt.jobkoo.com;
index           index.html index.htm index.php;
root            /data/www/cacti;

#limit_conn   crawler  20;

location ~ .*\.(php|php5)?$
{
fastcgi_pass        127.0.0.1:9000;
fastcgi_index       index.php;
}

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires     30d;
}

location ~ .*\.(js|css)?$
{
expires     1h;
}

log_format  access  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';
access_log  /usr/local/nginx/logs/access.log  access;
}

server
{
listen          80;
server_name     nagios.opt.jobkoo.com;
index           index.html index.htm index.php;
root            /usr/local/nagios/share/;

auth_basic      "Welcome to Jobkoo Nagios Monitor System!";
auth_basic_user_file    ./conf.d/htpasswd;

# 这个rewrite针对的是pnp插件的鼠标移动到图标后显示的浮动窗
rewrite     ^/nagios/pnp/(.*)\.php /pnp/$1.php break;

# 以 cgi 结尾的文件
location ~ \.cgi$ {
root    /usr/local/nagios/sbin;
rewrite ^/nagios/cgi-bin/(.*)\.cgi /$1.cgi break;

fastcgi_pass   127.0.0.1:10000;
fastcgi_index  index.cgi;

}

# 以 php/php5 结尾的文件
location ~ \.(php|php5)+$
{
fastcgi_pass        127.0.0.1:9000;
fastcgi_index       index.php;
}

log_format  wwwlogs  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';
access_log      /usr/local/nginx/logs/nagios.access.log  wwwlogs;
}

server
{
listen          80;
server_name     status.apt.jobkoo.com;

location / {
stub_status     on;
access_log      off;
}
}
}

/etc/nginx/conf.d 目录下的cgi 参数配置文件
#vi /etc/nginx/conf.d/fastcgi_custom.conf

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;

# vi /etc/nginx/conf.d/fastcgi_params.conf

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

设置nagios页面身份验证
# htpasswd -c /etc/nginx/conf.d/htpasswd admin
# cat /etc/nginx/conf.d/htpasswd
admin:QqbxsY3jdkOpQ

配置nagios

#vi /usr/local/nagios/etc/cgi.cfg
use_authentication=1

# service nagios start
# service nginx start

访问nagios页面
nagios_nginx.png

原创文章,转载请注明: 转自 http://salogs.com