简介
本文主要介绍nginx后端节点的健康检查，在此之前我们先来介绍下nignx反向代理主要使用的模块。
nginx原生模块介绍
我们在使用nginx做反向代理都会使用到以下两个模块：
1.ngx_http_proxy_module
定义允许将请求传递到另一台服务器。此模块下常用指令如下：
proxy_pass
proxy_cache
proxy_connect_timeout
proxy_read_timeout
proxy_send_timeout
proxy_next_upstream
- 1
- 2
- 3
- 4
- 5
- 6
2.ngx_http_upstream_module
用于定义可由proxy_pass，fastcgi_pass等指令引用的服务器组。此模块下常用指令如下：
upstream
server
ip_hash
- 1
- 2
- 3
默认负载均衡配置
http {
upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://myapp1;
}
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
此时nginx默认的负载均衡策略是轮询外，还有其他默认参数，如下：
http {
upstream myapp1 {
server srv1.example.com weight=1 max_fails=1 fail_timeout=10;
server srv2.example.com weight=1 max_fails=1 fail_timeout=10;
server srv3.example.com weight=1 max_fails=1 fail_timeout=10;
}
server {
listen 80;
proxy_send_timeout=60;
proxy_connect_timeout=60;
proxy_read_timeout=60;
proxy_next_upstream=error timeout;
location / {
proxy_pass http://myapp1;
}
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
其中：
1.故障转移
Syntax: proxy_read_timeout time;
Default:
proxy_read_timeout 60s;
Context: http, server, location
定义从代理服务器读取响应的超时。 仅在两个连续的读操作之间设置超时，而不是为整个响应的传输。 如果代理服务器在此时间内未传输任何内容，则关闭连接。
Syntax: proxy_connect_timeout time;
Default:
proxy_connect_timeout 60s;
Context: http, server, location
定义与代理服务器建立连接的超时。 应该注意，此超时通常不会超过75秒。
Syntax: proxy_send_timeout time;
Default:
proxy_send_timeout 60s;
Context: http, server, location
设置将请求传输到代理服务器的超时。 仅在两个连续的写操作之间设置超时，而不是为整个请求的传输。 如果代理服务器在此时间内未收到任何内容，则关闭连接
Syntax: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | non_idempotent | off ...;
Default:
proxy_next_upstream error timeout;
Context: http, server, location
指定在何种情况下一个失败的请求应该被发送到下一台后端服务器：
error 和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现错误
timeout 和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现超时
invalid_header 后端服务器返回空响应或者非法响应头
http_500 后端服务器返回的响应状态码为500
http_502 后端服务器返回的响应状态码为502
http_503 后端服务器返回的响应状态码为503
http_504 后端服务器返回的响应状态码为504
http_404 后端服务器返回的响应状态码为404
off 停止将请求发送给下一台后端服务器
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
从以上几个指令可以看出，在默认配置下，后端节点一旦出现error和timeout情况时，nginx会通过proxy_next_upstream进行故障转移，将发往不健康节点的请求，自动转移至健康节点。其中timeout设置和proxy_send_timeout time、proxy_connect_timeout time、proxy_read_timeout time有关。除了error、timeout，我们可以设置更详细的触发条件，如http_502、http_503等。
注意：只有在没有向客户端发送任何数据以前，将请求转给下一台后端服务器才是可行的。也就是说，如果在传输响应到客户端时出现错误或者超时，这类错误是不可能恢复的。
2.健康检查
Syntax: server address [parameters];
Default: —
Context: upstream
max_fails=number 设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内，如果失败的次数达到此值，Nginx就认为服务器不可用。此时在接下来的fail_timeout时间段，服务器不会再被尝试。失败的尝试次数默认是1。设为0就会停止统计尝试次数，即不对后端节点进行健康检查。认为服务器是一直可用的。
fail_timeout=time 设定服务器被认为不可用的时间段以及统计失败尝试次数的时间段。在这段时间中，服务器失败次数达到指定的尝试次数，服务器就被认为不可用。
默认情况下，该超时时间是10秒。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
以上有几点需要解释：
1.失败次数中的失败是怎么定义的？
官网解释是指由proxy_next_upstream，fastcgi_next_upstream，uwsgi_next_upstream，scgi_next_upstream，memcached_next_upstream和grpc_next_upstream指令定义，也是前面说的error、time、http_xxx状态码等。
2.如果mail_fail为0，此时健康检查无效。因此此时整个nginx，只会由proxy_next_upstream判断，进行相关故障转移。
小结
在使用nginx上述的两个模块由以下缺点：
1.fail_time内的失败检测，超时时间以系统设置为主，效率低，等待超时影响性能；
2.后端一旦有问题，除后端禁用的fail_time时间段，其他时间nginx会把请求转发给不健康节点的，然后再转发给别的服务器，这样以来就浪费了一次转发。
因此除了上面介绍的nginx自带模块，还有一个更专业的模块，来专门提供负载均衡器内节点的健康检查的。这个就是淘宝技术团队开发的nginx模块。
nginx_upstream_check_module模块
借助淘宝技术团队开发的nginx模快nginx_upstream_check_module来检测后方realserver的健康状态，如果后端服务器不可用，则会将其踢出upstream，所有的请求不转发到这台服务器。当期恢复正常时，将其加入upstream。
在淘宝自己的tengine上是自带了该模块的，大家可以访问淘宝Tengine官网来获取该版本的nginx，也可以到Gitbub
如果没有使用淘宝的tengine的话，可以通过补丁的方式来添加该模块到我们自己的nginx
中。
#打补丁
#注意不同版本对应的补丁
cd nginx-1.6.0
patch -p1 < ../nginx_upstream_check_module-master/check_1.5.12+.patch
./configure --user=nginx --group=nginx --prefix=/usr/local/nginx1.6 --sbin-path=/usr/local/nginx1.6 --conf-path=/usr/local/nginx1.6/nginx.conf --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --with-http_ssl_module --with-http_stub_status_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_sub_module --with-pcre=/usr/local/src/nginx/pcre-8.36 --with-zlib=/usr/local/src/nginx/zlib-1.2.8 --add-module=/usr/local/src/nginx/ngx_cache_purge-2.1 --add-module=/usr/local/src/nginx/headers-more-nginx-module-master --add-module=/usr/local/src/nginx/nginx_upstream_check_module-master
make
不要执行make install命令
cd /usr/local/nginx1.6
备份命令
cp nginx nginx.bak
nginx -s stop
cp -r /usr/local/src/nginx/nginx-1.6.0/objs/nginx .
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
打完补丁后，可进行如下配置：
http {
upstream cluster {
# simple round-robin
server 192.168.0.1:80;
server 192.168.0.2:80;
check interval=5000 rise=1 fall=3 timeout=4000;
#check interval=3000 rise=2 fall=5 timeout=1000 type=ssl_hello;
#check interval=3000 rise=2 fall=5 timeout=1000 type=http;
#check_http_send "HEAD / HTTP/1.0\r\n\r\n";
#check_http_expect_alive http_2xx http_3xx;
}
server {
listen 80;
location / {
proxy_pass http://cluster;
}
location /status {
check_status;
access_log off;
allow SOME.IP.ADD.RESS;
deny all;
}
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
其中：
Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]
Default: 如果没有配置参数，默认值是：interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp
Context: upstream
该指令可以打开后端服务器的健康检查功能。指令后面的参数意义是：
interval：向后端发送的健康检查包的间隔,单位为毫秒。
fall(fall_count): 如果连续失败次数达到fall_count，服务器就被认为是down。
rise(rise_count): 如果连续成功次数达到rise_count，服务器就被认为是up。
timeout: 后端健康请求的超时时间，单位毫秒。
default_down: 设定初始时服务器的状态，如果是true，就说明默认是down的，如果是false，就是up的。默认值是true，也就是一开始服务器认为是不可用，要等健康检查包达到一定成功次数以后才会被认为是健康的。
type：健康检查包的类型，现在支持以下多种类型：
tcp：简单的tcp连接，如果连接成功，就说明后端正常。
ssl_hello：发送一个初始的SSL hello包并接受服务器的SSL hello包。
http：发送HTTP请求，通过后端的回复包的状态来判断后端是否存活。
mysql: 向mysql服务器连接，通过接收服务器的greeting包来判断后端是否存活。
ajp：向后端发送AJP协议的Cping包，通过接收Cpong包来判断后端是否存活。
port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口，比如后端提供的是443端口的应用，你可以去检查80端口的状态来判断后端健康状况。默认是0，表示跟后端server提供真实服务的端口一样。该选项出现于Tengine-1.4.0。
Syntax: check_keepalive_requests request_num
Default: 1
Context: upstream
该指令可以配置一个连接发送的请求数，其默认值为1，表示Tengine完成1次请求后即关闭连接。
Syntax: check_http_send http_packet
Default: "GET / HTTP/1.0\r\n\r\n"
Context: upstream
该指令可以配置http健康检查包发送的请求内容。为了减少传输数据量，推荐采用"HEAD"方法。
当采用长连接进行健康检查时，需在该指令中添加keep-alive请求头，如："HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n"。 同时，在采用"GET"方法的情况下，请求uri的size不宜过大，确保可以在1个interval内传输完成，否则会被健康检查模块视为后端服务器或网络异常。
Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]
Default: http_2xx | http_3xx
Context: upstream
该指令指定HTTP回复的成功状态，默认认为2XX和3XX的状态是健康的。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
例子如下：
server{
listen 80;
upstream test{
server 192.168.3.12:8080 weight=5 max_fails=3 fail_timeout=10s;
server 192.168.3.13:8080 weight=5 max_fails=3 fail_timeout=10s;
check interval=5000 rise=1 fall=3 timeout=4000 type=http default_down=false;
check_http_send "HEAD /test.jsp HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://test;
proxy_next_upstream error timeout http_500 http_502 http_503;
}
#后端阶段健康状态监控
location /status {
check_status;
access_log off;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
以上我们同时使用了nginx原生的及淘宝的健康检查模块，但是淘宝的间隔时是毫秒级，而且可以自定义监控url，定制监控页，响应速度快，比原生的敏感度要高。
</article>