nginx后端节点的健康检查和nginx平滑升级方式
作者:新手小白*
简介:
本文主要介绍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
2、ngx_http_upstream_module
用于定义可由proxy_pass,fastcgi_pass等指令引用的服务器组。
此模块下常用指令如下:
upstream server ip_hash
默认负载均衡配置
http {
upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://myapp1;
}
}
}此时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.故障转移(了解)
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 停止将请求发送给下一台后端服务器
从以上几个指令可以看出,在默认配置下,后端节点一旦出现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.失败次数中的失败是怎么定义的?官网解释是指由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中。
下载地址1:https://github.com/yaoweibin/nginx_upstream_check_module
#打补丁 #注意不同版本对应的补丁 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 .
打完补丁后,可进行如下配置:
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;
}
}
}其中:
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的状态是健康的。例子如下:
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 /index.html 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;
}
}以上我们同时使用了nginx原生的及淘宝的健康检查模块,但是淘宝的间隔时是毫秒级,而且可以自定义监控url,定制监控页,响应速度快,比原生的敏感度要高。
三、使用阿里巴巴的tengine实现后端节点状态检查
1、安装tengine
unzip tengine-3.1.0.zip cd tengine-3.1.0/ ./configure --prefix=/usr/local/tengine --add-module=/root/tengine-3.1.0/modules/ngx_http_upstream_check_module && make && make install
2、修改配置文件
user nginx;
worker_processes 1;
error_log logs/error.log info;
error_log "pipe:rollback logs/error_log interval=1d baknum=7 maxsize=2G";
pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log logs/access.log main;
access_log "pipe:rollback logs/access_log interval=1d baknum=7 maxsize=2G" main;
sendfile on;
keepalive_timeout 65;
gzip on;
upstream webs {
server 192.168.166.10:80;
server 192.168.166.13:80;
check interval=5000 rise=1 fall=3 timeout=4000 type=http default_down=false;
check_http_send "HEAD /index.html HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://webs;
}
location /status {
check_status html;
access_log off;
allow all;
deny all;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}3.1 Nginx平滑升级原理
- 在不停掉老进程的情况下,启动新进程。
- 老进程负责处理仍然没有处理完的请求,但不再接受处理请求。
- 新进程接受新请求。
- 老进程处理完所有请求,关闭所有连接后,停止。
3.2 Nginx信号
3.2.1主进程支持的信号
TERM,INT:立刻退出;QUIT:等待工作进程结束后再退出;KILL:强制终止进程;HUP:重新加载配置文件,使用新的配置启动工作进程,并逐步关闭旧进程;USR1:重新打开日志文件;USR2:启动新的主进程,实现热升级;WINCH:逐步关闭工作进程。
3.2.2 工作进程支持的信号
TERM,INT:立刻退出;QUIT:等待请求处理结束后再退出;USR1:重新打开日志文。
3.3 平滑升级实战
3.3.1 Nginx添加新模块
在已编译安装Nginx的基础上添加–with-http_image_filter_module模块。
(1)进入Nginx解压目录
[root@nginx-proxy ~]# cd /usr/local/nginx-1.18.0/
(2)查看Nginx已安装的模块
[root@nginx-proxy nginx-1.18.0]# /usr/local/nginx/sbin/nginx -V nginx version: nginx/1.18.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) configure arguments: --prefix=/usr/local/nginx --pid-path=/var/run/nginx/nginx.pid --lock-path=/var/lock/nginx.lock --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --with-http_gzip_static_module --http-client-body-temp-path=/var/temp/nginx/client --http-proxy-temp-path=/var/temp/nginx/proxy --http-fastcgi-temp-path=/var/temp/nginx/fastcgi --http-uwsgi-temp-path=/var/temp/nginx/uwsgi --http-scgi-temp-path=/var/temp/nginx/scgi
(3)添加新模块
[root@nginx-proxy nginx-1.18.0]# ./configure --prefix=/usr/local/nginx --pid-path=/var/run/nginx/nginx.pid --lock-path=/var/lock/nginx.lock --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --with-http_gzip_static_module --http-client-body-temp-path=/var/temp/nginx/client --http-proxy-temp-path=/var/temp/nginx/proxy --http-fastcgi-temp-path=/var/temp/nginx/fastcgi --http-uwsgi-temp-path=/var/temp/nginx/uwsgi --http-scgi-temp-path=/var/temp/nginx/scgi --with-http_image_filter_module
(4)进行make操作
按照原来的编译参数安装 nginx 的方法进行安装,只需要到 make,千万不要 make install 。如果make install 会将原来的配置文件覆盖。下面给Nginx添加–with-http_image_filter_module模块。
[root@nginx-proxy nginx-1.18.0]# make
(5)备份原Nginx二进制文件
[root@nginx-proxy nginx-1.18.0]# mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak #备份的命令必须在当前路径下
(6)复制新的nginx二进制文件,进入新的nginx源码包
[root@nginx-proxy nginx-1.18.0]# cp /usr/local/nginx-1.18.0/objs/nginx /usr/local/nginx/sbin/
(7)测试新版本的nginx是否正常
[root@nginx-proxy nginx-1.18.0]# /usr/local/nginx/sbin/nginx -t nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
(8)给nginx发送平滑迁移信号
若不清楚Nginx.pid的路径,可查看nginx配置文件,里面有对应的路径。
[root@nginx-proxy logs]# kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
(9)查看nginx pid,会出现一个nginx.pid.oldbin
即在不停掉老进程的情况下启动新进程。
[root@nginx-proxy ~]# ll /usr/local/nginx/logs/ total 8 -rw-r--r-- 1 root root 5 Sep 25 13:32 nginx.pid -rw-r--r-- 1 root root 5 Sep 25 13:27 nginx.pid.oldbin
(10)关闭旧的Nginx进程
[root@nginx-proxy ~]# kill -WINCH `cat /usr/local/nginx/logs/nginx.pid.oldbin`
(11)结束工作进程,完成此次升级
[root@nginx-proxy ~]# kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`
(12)验证Nginx是否升级成功
[root@nginx-proxy ~]# /usr/local/nginx/sbin/nginx -V
3.3.2 Nginx版本升级
安装Nginx1.6版本
(1)下载Nginx1.6/1.18版本包
[root@zrs ~]# wget http://nginx.org/download/nginx-1.6.3.tar.gz [root@zrs ~]# wget http://nginx.org/download/nginx-1.18.0.tar.gz
(2)安装依赖环境
[root@zrs ~]# yum install -y gcc gcc-c++ pcre-devel openssl-devel zlib-devel
(3)进行安装
[root@zrs ~]# tar zxf nginx-1.6.3.tar.gz -C /usr/local/ [root@zrs ~]# cd /usr/local/nginx-1.6.3/ [root@zrs nginx-1.6.3]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module [root@zrs nginx-1.6.3]# make && make install [root@zrs nginx-1.6.3]# useradd -M -s /sbin/nologin nginx
(4)启动Nginx服务
[root@zrs nginx-1.6.3]# /usr/local/nginx/sbin/nginx #启动Nginx服务 [root@zrs nginx-1.6.3]# netstat -lntp | grep 'nginx' #检测是否开启 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3633/nginx: master [root@zrs nginx-1.6.3]# /usr/local/nginx/sbin/nginx -t #检测Nginx的配置是否正确 nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
(5)查看Nginx版本和模块
[root@zrs nginx-1.6.3]# /usr/local/nginx/sbin/nginx -V nginx version: nginx/1.6.3 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) configure arguments: --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module
升级Nginx1.6
将 nginx1.6版本进行升级(升级为Nginx1.18版本)并在不影响业务的情况下添加 SSL 和 pcre 模块。
(1)升级
[root@zrs ~]# tar xzf nginx-1.18.0.tar.gz -C /usr/local/ [root@zrs ~]# cd /usr/local/nginx-1.18.0/ [root@zrs nginx-1.18.0]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module --with-pcre #升级并添加相关模块
(2)进行make
注意:这里不能进行,make install 操作,否则将会被覆盖,可能会影响线上业务。
[root@zrs nginx-1.18.0]# make
(3)拷贝Nginx1.18版本的二进制文件到1.6版本
[root@zrs ~]# mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak #先备份一份 [root@zrs ~]# cp /usr/local/nginx-1.18.0/objs/nginx /usr/local/nginx/sbin/
(4)启动新的主进程,实现热升级
[root@zrs ~]# kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid)
(5)查看升级后的版本
[root@zrs ~]# /usr/local/nginx/sbin/nginx -V
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。
