Nginx被动健康检查和主动健康检查

1.被动健康检查

Nginx自带有健康检查模块:ngx_http_upstream_module,可以做到基本的健康检查,配置如下:

upstream cluster{
    server 172.16.0.23:80  max_fails=1 fail_timeout=10s;
    server 172.16.0.24:80  max_fails=1 fail_timeout=10s;   # max_fails=1和fail_timeout=10s 表示在单位周期为10s钟内,中达到1次连接失败,那么接将把节点标记为不可用,并等待下一个周期(同样时常为fail_timeout)再一次去请求,判断是否连接是否成功。   # fail_timeout为10s,max_fails为1次。 
}

server {
    listen 80;
    server_name xxxxxxx.com;
    location / {
      proxy_pass         http://cluster;
    }
}

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

2.主动健康检查(需使用第三方模块)

主动地健康检查,nignx定时主动地去ping后端的服务列表,当发现某服务出现异常时,把该服务从健康列表中移除,当发现某服务恢复时,又能够将该服务加回健康列表中。淘宝有一个开源的实现nginx_upstream_check_module模块
官网:http://tengine.taobao.org/document_cn/http_upstream_check_cn.html

http {
    upstream cluster1 {
        # simple round-robin
        server 192.168.0.1:80;
        server 192.168.0.2:80;

        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;
    }

    upstream cluster2 {
        # simple round-robin
        server 192.168.0.3:80;
        server 192.168.0.4:80;

        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_keepalive_requests 100;
        check_http_send "HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx;
    }

    server {
        listen 80;

        location /1 {
            proxy_pass http://cluster1;
        }

        location /2 {
            proxy_pass http://cluster2;
        }

        location /status {
            check_status;

            access_log   off;
            allow SOME.IP.ADD.RESS;
            deny all;
        }
    }
}

3.集成第三方模块部署

3.1、下载nginx_upstream_check_module模块

    #进入nginx安装目录
    cd /usr/local/nginx

    #下载nginx_upstream_check_module模块
    wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master
    #wget https://github.com/yaoweibin/nginx_upstream_check_module/archive/master.zip

    #解压
    unzip master

cd nginx-1.12 # 进入nginx的源码目录
# -p0,是“当前路径” -p1,是“上一级路径”
patch -p1 < ../nginx_upstream_check_module-master/check_1.11.5+.patch
#nginx -V 可以查看原有配置 输出 ./configure --prefix=/usr/local/nginx
#增加upstream_check模块
./configure --prefix=/usr/local/nginx --add-module=../nginx_upstream_check_module-master
make
/usr/local/nginx/sbin/nginx -t # 检查下是否有问题

注意 check版本和Nginx版本要求有限制 1.12以上版本的nginx,补丁为check_1.11.5+.patch 具体参考github https://github.com/yaoweibin/nginx_upstream_check_module

3.2.修改配置文件,让nginx_upstream_check_module模块生效

http {
    upstream cluster1 {
        # simple round-robin
        server 192.168.0.1:80;
        server 192.168.0.2:80;

        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;
    }

    upstream cluster2 {
        # simple round-robin
        server 192.168.0.3:80;
        server 192.168.0.4:80;

        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_keepalive_requests 100;
        check_http_send "HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx;
    }

    server {
        listen 80;

        location /1 {
            proxy_pass http://cluster1;
        }

        location /2 {
            proxy_pass http://cluster2;
        }

        location /status {
            check_status;

            access_log   off;
            allow SOME.IP.ADD.RESS;
            deny all;
        }
    }
}

3.3重载nginx

访问http://nginx/nstatus
人为把其中的一个节点关掉刷新http://nginx/nstatus

udp反向代理时健康检查的问题,另一位大神在上面nginx_upstream_check_module的基础上作了修改,实现了在第4层的代理tcp和udp时的健康检查。

https://github.com/zhouchangxun/ngx_healthcheck_module

原文地址:https://www.cnblogs.com/linyouyi/p/11502282.html

时间: 2024-10-07 15:52:58

Nginx被动健康检查和主动健康检查的相关文章

nginx 健康检查和负载均衡机制分析

nginx 是优秀的反向代理服务器,这里主要讲它的健康检查和负载均衡机制,以及这种机制带来的问题.所谓健康检查,就是当后端出现问题(具体什么叫出现问题,依赖 于具体实现,各个实现定义不一样),不再往这个后端分发请求,并且做后续的检查,直到这个后端恢复正常.所谓负载均衡,就是选择后端的方式,如何(根据后 端的能力)将请求均衡的分发到后端.此外,当请求某个后端失败时,要将该请求分发到其它后端(redispatch).这里以 ngx_http_upstream_round_robin(简称RR)做为负

nginx对后端节点的健康检查

最近梳理了下手头的业务,发现nginx层配有几种健康检查方式,在这里做个总结,记录下nginx做负载均衡时对后端节点的健康检查方式: 1.ngx_http_proxy_module 模块中的下面三个指令(nginx自带模块) proxy_connect_timeout 60s 设置与后端服务器建立连接的超时时间.应该注意这个超时一般不可能大于75秒 proxy_read_timeout 60s 定义从后端服务器读取响应的超时.此超时是指相邻两次读操作之间的最长时间间隔,而不是整个响应传输完成的最

分析shell实现nginx反向代理后端realserver健康检查

今天阅读老男孩教育博客http://oldboy.blog.51cto.com/ 中一篇关于shell实现nginx反向代理后端realserver健康检查的文章,根据其中一个学员朋友的思路自己写了一个脚本. 一.nginx.conf部分内容如下:     upstream rs_pools {     server 10.0.0.8:80 weight=5;     server 10.0.0.9:80 weight=5;     server 10.0.0.10:80 weight=5;  

【安全】华为应对APT新思路:&quot;被动堵&quot;变&quot;主动围&quot;

[IT168 应用]8月15日消息,日前,华为参加2014趋势CIO峰会上,与近300位全球云计算领导厂商.国内领先行业,知名企业的CIO.CSO就云数据中心安全架构.大数据安全.移动设备安全管理等热点话题进行讨论.华为还分享了华为安全解决方案如何利用大数据分析技术和安全协防理念,帮助企业构筑纵深防御体系,应对APT攻击,保护关键信息资产的安全. 当前,一种有组织.针对特定目标.破坏力大.持续时间长的新型威胁出现,使企业网络安全面临前所未有的挑战.这种攻击也被称为APT(Advanced Per

如何利用nginx_upstream_check_module-master对nginx的后端机器进行健康状态检查

用nginx做前端反向代理,如果后端服务器宕掉的话,nginx是不会把这台realserver踢出upstream的,还会把请求转发到后端的这台realserver上面.所以当某台机器出现问题时,我们会看到nginx的日志会有一段转发失败然后转发正常的日志.这次借助与淘宝技术团队开发的nginx模快nginx_upstream_check_module来检测后方realserver的健康状态,如果后端服务器不可用,则会将其踢出upstream,所有的请求不转发到这台服务器.当期恢复正常时,将其加

nginx自动检测后台服务器健康状态

转自http://www.iyunv.com/thread-38535-1-1.html 公司业务线上对后端节点的健康检查是通过nginx_upstream_check_module模块做的,这里我将分别介绍这三种实现方式以及之间的差异性. 一.ngx_http_proxy_module 模块和ngx_http_upstream_module模块(自带)       严格来说,nginx自带是没有针对负载均衡后端节点的健康检查的,但是可以通过默认自带的ngx_http_proxy_module

nginx下后端节点realserverweb健康检测模块ngx_http_upstream_check_module

本文章收录做资料使用,非本人原创,特此说明. 公司前一段对业务线上的nginx做了整理,重点就是对nginx上负载均衡器的后端节点做健康检查.目前,nginx对后端节点健康检查的方式主要有3种,这里列出: 1.ngx_http_proxy_module 模块和ngx_http_upstream_module模块(自带) 官网地址:http://nginx.org/cn/docs/http/ngx_http_proxy_module.html#proxy_next_upstream 2.nginx

jetty 在请求URI里传入非法字符,jetty会断开连接,导致nginx认为该节点不健康

jetty 在请求URI里传入非法字符(如直接一个16进制字节A1,非%A1,用抓包TCP工具发送),jetty抛出如下错误 8.1.0.RC1. 8.1.18.v20150929. 9.3好的 如果前面代理用nginx的proxy_next_upstream,会认为该节点失效,如果请求刷的厉害,有可能所有节点都被刷成不健康状态:导致nginx返回给用户502: org.eclipse.jetty.util.Utf8Appendable$NotUtf8Exception: Not valid U

用ORACHK自己主动化检查数据库系统的健壮性

1.orachk工具主要用途 (1)主动检查您的整个软件在操作系统.CRS.数据库.高可用等层面中的严重问题,以便于IT部门整改,提升系统的稳定性 (2)对于您系统中存在的风险提供简单化和合理化的诊断和分析建议. (3)对系统中存在的健康风险提供汇总信息,而且可以向下钻取到特定的问题和相应的解决方式 (4)对检查结果进行量化评分(100分制),内容很的全面,通过得分直观推断健康程度 2.执行注意要点 (1)orachk不支持在root用户下执行,须要在oracle或grid用户下执行 (2)假设