nginx 健康检查方案

nginx 健康检查方案

ngx_http_proxy_module模块(自带) 超时时间设置

无特别场景需求都可直接采用默认60s
语法:  proxy_connect_timeout ``time``;
默认值: proxy_connect_timeout 60s;
作用域: http, server, location
该指令设置与upstream server的连接超时时间,有必要记住,这个超时不能超过75秒。这个时间Nginx与上游服务器
尝试建立连接,如果60s内都没有建立成功,则会放弃这个连接。
语法: proxy_read_timeout ``time``;
默认值: proxy_read_timeout 60s;
作用域: http, server, location
定义从后端服务器读取响应的超时。此超时是指相邻两次读操作之间的最长时间间隔,而不是整个响应传输完成的最长时间。如果后端服务器在超时时间段内没有传输任何数据,连接将被关闭(连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理(也可以说是后端服务器处理请求的时间))。
语法:	proxy_send_timeout time;
默认值: proxy_send_timeout 60s;
作用域: http, server, location
设置将请求传输到代理服务器的超时。仅在两个连续的写操作之间设置超时,而不是为整个请求的传输。如果代理服务器在此时间内未收到任何内容,则关闭连接。(后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据)。
语法: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...;
默认值: proxy_next_upstream error timeout;
作用域: http, server, location
后端返回状态码:指定在何种情况下一个失败的请求应该被发送到下一台后端服务器:

1、nginx 被动check 方法

Nginx(自带)有健康检查模块:ngx_http_upstream_module,可以做到基本的健康检查

参数:

max_fails:失败尝试最大次数;超出此处指定的次数时,server将被标记为不可用,默认为1

fail_timeout:后端服务器标记为不可用状态的连接超时时长,默认10s

backup: 将服务器标记为"备用",即所有服务器均不可用时才启用

例如:
server x.x.x.x:8080 max_fails=3 fail_timeout=30s;`
server x.x.x.x:8080 max_fails=3 fail_timeout=30s;`
说明:代表在30秒内某一应用失败3次,认为该应用宕机,后等待30秒,这期间内不会再把新请求发送到宕机应用,而是直接发到正常的那一台,等待的这30秒时间到后再有请求进来继续尝试连接宕机应用且仅尝试1次,如果还是失败,则继续等待30秒...以此循环,直到恢复。`

缺点:Nginx只有当有访问时后,才发起对后端节点探测。如果本次请求中,节点正好出现故障,Nginx依然将请求转交给故障的节点,然后再转交给健康的节点处理。所以不会影响到这次请求的正常进行。但是会影响效率,因为多了一次转发,而且自带模块无法做到预警。

2、nginx 主动check 方法

nginx_upstream_check_module模块对后端节点做主动健康检查(淘宝开发)
部署方式见:nginx_check 模块热部署文档

主动check:心跳检测,为非业务流量,nginx本身发起健康检测请求。

注意:check模块版本和Nginx版本要求有限制。做补丁包的时候注意版本选择

check指令只能出现在upstream中:
interval:向后端发送的健康检查包的间隔。
fall:如果连续失败次数达到fall_count,服务器就被认为是down。
rise:如果连续成功次数达到rise_count,服务器就被认为是up。
timeout:后端健康请求的超时时间。
default_down:设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的
 :健康检查包的类型,常用(tcp\http):
tcp:简单的tcp连接,连接成功,就说明后端正常(网络层探测,通过发送SYN握手报文来检测服务器端口是否存活)。
http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活
不常用:ajp\ssl_hello\mysql\fastcgi
说明:(将HTTP模式的负载均衡修改为TCP模式后,负载均衡将只检查监听端口状态,不检查HTTP状态,会导致负载均衡无法实时获知HTTP应用是否出现问题。)

TCP模式配置:

upstream xxxx {
    server ip:port;
    server ip:port;    
    check interval=5000 rise=2 fall=3 timeout=1000 type=tcp;
}

HTTP模式配置:(需要提供一个健康检查的url)

upstream xxxx {
    server ip:port;
    server ip:port;    
    check interval=5000 rise=2 fall=3 timeout=1000 type=http;
    check_http_send "HEAD / HTTP/1.0\r\n\r\n"; #默认用HEAD方式 请求缺省页
    check_http_expect_alive http_2xx http_3xx;
}
说明:每个5秒检测一次(单位为毫秒),请求2次正常则标记 realserver状态为up,如果检测 3 次都失败,则标记 realserver的状态为down,超时时间为1秒(单位为毫秒)。
check_http_send: http 请求方式 如:("GET /index.html HTTP/1.0\r\n\r\n")注意:请求的uri不宜过大
check_http_expect_alive: 定义健康的状态码
server 中配置可界面显示后端健康状态
location /status {
check_status;
access_log off;
}

3、目前环境配置建议:为保证业务流量无影响,优先采用主动check方式

模块部署方式见:nginx_check 模块热部署文档
1、后端应用未配置(提供)健康检查url情况
upstream xxxx {
    server ip:port;
    server ip:port;    
    check interval=5000 rise=2 fall=3 timeout=1000 type=tcp;
}
2、后端提供健康检查url 情况
upstream xxxx {
    server ip:port;
    server ip:port;    
    check interval=5000 rise=2 fall=3 timeout=1000 type=http;
    check_http_send "HEAD /url HTTP/1.0\r\n\r\n"; # /url指提供健康检查的url
    check_http_expect_alive http_2xx http_3xx;
}
server 中配置。用于界面显示后端健康状态
location /status {
check_status;
access_log off;
}

你可能感兴趣的:(nginx,运维,linux)