Nginx负载均衡监测节点状态

Nginx负载均衡监测节点状态

v插件(ngx_http_upstream_check_module)

  • upstream_check_module介绍:

该模块可以为Tengine提供主动式后端服务器健康检查的功能。

该模块在Tengine-1.4.0版本以前没有默认开启,它可以在配置编译选项的时候开启:./configure--with-http_upstream_check_module

  • upstream_check_module官方文档

http://tengine.taobao.org/document_cn/http_upstream_check_cn.html

  • upstream_check_module下载地址

https://github.com/yaoweibin/nginx_upstream_check_module

  • 给nginx打上补丁的安装
unzip nginx_upstream_check_module-master.zipuseradd nginx -s /sbin/nologin -Mtar xf nginx-1.9.2.tar.gzcd nginx-1.9.2patch  -p0</root/nginx_upstream_check_module-master/check_1.9.2+.patch./configure \--prefix=/application/nginx-1.9.2 \--user=nginx \--group=nginx \--with-http_ssl_module \--with-http_stub_status_module \--add-module=/root/nginx_upstream_check_module-mastermakemake installln -s /application/nginx-1.9.2//application/nginx
  • patch参数说明

-p0 选项要从当前目录查找目的文件(夹)

-p1 选项要忽略掉第一层目录,从当前目录开始查找。

在这里以实例说明:

old/modules/pcitable

如果使用参数-p0,那就表示从当前目录找一个叫做old的文件夹,在它下面寻找modules下的pcitable文件来执行patch操作。

如果使用参数-p1,那就表示忽略第一层目录(即不管old),从当前目录寻找modules的文件夹,在它下面找pcitable。这样的前提是当前目录必须为modules所在的目录。

  • upstream_check_module语法

Syntax: checkinterval=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=5rise=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。

例:

http {
    upstream cluster1 {
        # simple round-robin
        server 192.168.0.1:80;
        server 192.168.0.2:80;
 
        check interval=3000 rise=2 fall=5timeout=1000 type=http;
        check_http_send "HEAD /HTTP/1.0\r\n\r\n";
        check_http_expect_alive http_2xxhttp_3xx;
    }
 
    upstream cluster2 {
        # simple round-robin
        server 192.168.0.3:80;
        server 192.168.0.4:80;
 
        check interval=3000 rise=2 fall=5timeout=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_2xxhttp_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;
        }
    }
}
  • 配置
http {
    upstream dynamic_pools {
       server192.168.10.30;
       server192.168.10.31;
       check interval=3000 rise=2 fall=5timeout=1000;
# interval检测间隔时间,单位为毫秒,rsie请求2次正常的话,标记此realserver的状态为up,fall表示请求5次都失败的情况下,标记此realserver的状态为down,timeout为超时时间,单位为毫秒。
    }
    server {
        listen       80;
        server_name  www.etiantian.org;
        location / {
           proxy_pass http://dynamic_pools;
            includeproxy.conf;
        }
        location /nstatus {
            check_status;
            access_log off;  #不记录访问日志
            allow192.168.10.0/24;  #允许的ip地址(段)
            deny all;  #除过允许的ip地址(段)拒绝所有ip访问
       }
    }
}
  • 浏览器访问

时间: 2024-10-18 13:19:15

Nginx负载均衡监测节点状态的相关文章

NGINX 负载均衡监测节点状态 之 十一

1.监测负载均衡节点作用 用于提供主动式后端服务器健康检查,通过它可以检测后端realserver的健康状态,如果后端realserver不可用,则所有的请求就不会转发到该节点上. 2.依赖模块nginx_upstream_check_module 编译安装方法: ./configure xxxxxxxxxxxxxxx --add-module=/app/software/nginx_upstream_check_module-master/ 备注:可直接使用淘宝团队开发的NGINX程序包 ht

配置 Nginx 负载均衡监测节点状态

淘宝技术团队开发了一个 Tengine ( Nginx 的分支 ) 模块 nginx_upstream_check_module ,用于提供主动式后端服务器健康检查,通过它可以检测后端 realserver 的健康状态,如果后端 realserver 不可用,则所有的请求就不会转发到该节点上,需要通过打补丁的方式将该模块添加到 Nginx 中. 1.安装 nginx_upstream_check_module 模块 cd /usr/local/srcwget https://codeload.g

Nginx负载均衡监控节点状态

利用第三方插件监控(淘宝开发的Tengine) 模块:nginx_upstream_check_module 实现web界面 下载补丁包 wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master 解压缩 unzip master drwxr-xr-x 6 root root   4096 11月 10 18:58 nginx_upstream_check_module-master cd n

企业级Nginx负载均衡与keepalived高可用实战(二)keepalived篇

1.Keepalived高可用软件 1.1.Keepalived介绍 Keepalived软件起初是专门为LVS负载均衡软件设计的,用来管理并监控LVS集群系统中各个服务节点的状态,后来又加入了可以实现高可用的VRRP功能.因此,Keepalived除了能够管理LVS软件外,还可以作为其他服务(例如:Nginx,Haproxy,MySQL等)的高可用解决方案软件. Keepalived软件主要是通过VRRP协议实现高可用功能的.VRRP是Virtual Router Redundancy Pro

lvs、haproxy、nginx 负载均衡的比较分析

lvs.haproxy.nginx 负载均衡的比较分析 对软件实现负载均衡的几个软件,小D详细看了一下,从性能和稳定上还是LVS最牛,基本达到了F5硬件设备的60%性能,其他几个10%都有点困难. 不过就因为LVS忒牛了,配置也最麻烦了,而且健康检测需要另外配置Ldirector,其他HAPROXY和NGINX自己就用,而且配置超级简单. 所以小D建议,如果网站访问量不是门户级别的用HAPROXY或者NGINX就OK了,到了门户级别在用LVS+Idirector吧 哈哈 lvs和nginx都可以

Nginx 负载均衡

原文地址:http://nginx.com/resources/admin-guide/load-balancer/ Nginx Load Balancing nginx 负载均衡 This section describes how to use NGINX and NGINX Plus as a load balancer. 本章将讨论如何使用Nginx和Nginx加做负载均衡器. In This Section 本章包括 Load balancing overview 负载均衡概览 Pro

解析Nginx负载均衡

摘要:对于一个大型网站来说,负载均衡是永恒的话题.随着硬件技术的迅猛发展,越来越多的负载均衡硬件设备涌现出来,如F5 BIG-IP.Citrix NetScaler.Radware等等,虽然可以解决问题,但其高昂的价格却往往令人望而却步,因此负载均衡软件仍然是大部分公司的不二之选.nginx作为webserver的后起之秀,其优秀的反向代理功能和灵活的负载均衡策略受到了业界广泛的关注.本文将以工业生产为背景,从设计实现和具体应用等方面详细介绍nginx负载均衡策略. 关键字:nginx 负载均衡

nginx负载均衡集群中的session共享说明

在网站使用nginx+php做负载均衡情况下,同一个IP访问同一个页面会被分配到不同的服务器上,如果session不同步的话,就会出现很多问题,比如说最常见的登录状态. 下面罗列几种nginx负载均衡中session同步的方式 1)不使用session,换用cookiesession是存放在服务器端的,cookie是存放在客户端的,我们可以把用户访问页面产生的session放到cookie里面,就是以cookie为中转站.你访问web服务器A,产生了session然后把它放到cookie里面,当

解析 Nginx 负载均衡

nginx的负载均衡策略可以划分为两大类:内置策略和扩展策略.内置策略包含加权轮询和ip hash,在默认情况下这两种策略会编译进nginx内核,只需在nginx配置中指明参数即可.扩展策略有很多,如fair.通用hash.consistent hash等,默认不编译进nginx内核.由于在nginx版本升级中负载均衡的代码没有本质性的变化,因此下面将以nginx1.0.15稳定版为例,从源码角度分析各个策略. 2.1.           加权轮询(weighted round robin)