IT俱乐部 Nginx 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模块对后端节点做主动健康检查(淘宝开发)

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

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

check指令只能出现在upstream中:

  • interval:向后端发送的健康检查包的间隔。
  • fall:如果连续失败次数达到fall_count,服务器就被认为是down。
  • rise:如果连续成功次数达到rise_count,服务器就被认为是up。
  • timeout:后端健康请求的超时时间。
  • default_down:设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的

健康检查包的类型,常用(tcphttp):

  • tcp:简单的tcp连接,连接成功,就说明后端正常(网络层探测,通过发送SYN握手报文来检测服务器端口是否存活)。
  • http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活
  • 不常用:ajpssl_hellomysqlfastcgi
  • 说明:(将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.0rnrn"; #默认用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.0rnrn”)注意:请求的uri不宜过大
  • check_http_expect_alive: 定义健康的状态码
server 中配置可界面显示后端健康状态
location /status {
check_status;
access_log off;
}

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

后端应用未配置(提供)健康检查url情况

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

后端提供健康检查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.0rnrn"; # /url指提供健康检查的url
    check_http_expect_alive http_2xx http_3xx;
}
server 中配置。用于界面显示后端健康状态
location /status {
check_status;
access_log off;
}

总结

以上为个人经验,希望能给大家一个参考,也希望大家多多支持IT俱乐部。

本文收集自网络,不代表IT俱乐部立场,转载请注明出处。https://www.2it.club/server/nginx/10264.html
上一篇
下一篇
联系我们

联系我们

在线咨询: QQ交谈

邮箱: 1120393934@qq.com

工作时间:周一至周五,9:00-17:30,节假日休息

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

返回顶部