Nginx 负载均衡 后端 监控检测 nginx_upstream_check_module 模块的使用

在使用nginx 的负载均衡 中,我们通常会使用到 Nginx 自带的 ngx_http_proxy_module 健康检测模块。

ngx_http_proxy_module 自带的 健康检测模块参数如下:

weight   : 轮询权值也是可以用在ip_hash的,默认值为1

max_fails : 允许请求失败的次数,默认为1。当超过最大次数时,返回proxy_next_upstream 模块定义的错误。

fail_timeout : 有两层含义,一是在 30s 时间内最多容许 2 次失败;二是在经历了 2 次失败以后,30s时间内不分配请求到这台服务器。

backup : 预留的备份机器。当其他所有的非backup机器出现故障的时候,才会请求backup机器,因此这台机器的压力最轻。

max_conns: 限制同时连接到某台后端服务器的连接数,默认为0即无限制。因为queue指令是commercial,所以还是保持默认吧。

proxy_next_upstream : 这个指令属于 http_proxy 模块的,指定后端返回什么样的异常响应时,使用另一个realserver

例子如下:

upstream login {

server 172.16.0.1:8081 max_fails=3 fail_timeout=30s;

nginx_upstream_check_module 是专门提供负载均衡器内节点的健康检查的外部模块,由淘宝的姚伟斌大神开发。tengine 默认自带了这个模块。

check 模块的参数只能出现在upstream中,参数如下:

interval : 向后端发送的健康检查包的间隔。

fall : 如果连续失败次数达到fall_count,服务器就被认为是down。

rise : 如果连续成功次数达到rise_count,服务器就被认为是up。

timeout : 后端健康请求的超时时间。

default_down : 设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的。

type:健康检查包的类型,现在支持以下多种类型

tcp:简单的tcp连接,如果连接成功,就说明后端正常。

http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活。

ajp:向后端发送AJP协议的Cping包,通过接收Cpong包来判断后端是否存活。

ssl_hello:发送一个初始的SSL hello包并接受服务器的SSL hello包。

mysql: 向mysql服务器连接,通过接收服务器的greeting包来判断后端是否存活。

fastcgi:发送一个fastcgi请求,通过接受解析fastcgi响应来判断后端是否存活

port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口,比如后端提供的是443端口的应用,你可以去检查80端口的状态来判断后端健康状况。默认是0,表示跟后端server提供真实服务的端口一样。

check_http_expect_alive 指定HTTP回复的成功状态,默认认为 2XX 和 3XX 的状态是健康的。

这里我们也可以设置其他的。比如 404 403 等。

例子如下:(我们可以两个模块一起使用)

upstream login {

server 172.16.0.1:8081 max_fails=3 fail_timeout=30s;

check interval=5000 rise=2 fall=3 timeout=1000 type=http;

check_http_send "HEAD / HTTP/1.0\r\n\r\n";

check_http_expect_alive http_2xx http_3xx http_4xx;

}

设置好 upstream 以后我们可以在 server 里面设置 status 来查看状态。

location /status {

check_status;

access_log off;

allow 172.16.0.0/16;

deny all;

}

时间: 2024-09-30 05:10:19

Nginx 负载均衡 后端 监控检测 nginx_upstream_check_module 模块的使用的相关文章

nginx负载均衡+keepalive心跳检测

环境标准: 一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一 内核:2.6.32-642.el6.x86_64 系统:CentOS release 6.8 (Final) ip: web01:10.0.0.8 nginx 解析手机端 均做了nginx的负载均衡但是只均衡一台机器可以后续往里填 web02:10.0.0.200 nginx 解析电脑端 均做了nginx的负载均衡但是只均衡一台机器可以后续往里填 lb01

nginx负载均衡后端RS中获取真实ip

前端proxy配置 #################### worker_processes  1; events { worker_connections  1024; } http { include       mime.types; default_type  application/octet-stream; sendfile        on; keepalive_timeout  65; upstream backend { server 10.0.0.3:80    max_

Nginx负载均衡-day

1 Nginx负载均衡实战 Nginx的负载均衡可以用自带的upstream模块完成,本身还自带健康检查,非常简单.不但可以负载web,还可以负载fastcgi.memcached,功能非常强大 1.1 环境准备 #需要准备四台服务器.LB01.LB02.RS01.RS02 LB01: ip: eth0:172.16.50.1 eth1:10.0.0.1 LB02: ip: eth0:172.16.50.2 eth1:10.0.0.2 RS01: ip: eth0:10.0.0.80 RS01:

Nginx负载均衡组件模块

Nginx负载均衡组件模块 实现Nginx负载均衡的组件主要有两个: n  ngx_http_proxy_module proxy代理模块,用于把请求后抛给服务器节点或upstream服务器池 n  ngx_http_upstream_module 负载均衡模块,可以实现网站的负载均衡功能及节点的健康检查 1.upstream模块 upstream模块允许Nginx定义一组或多组节点服务器组,使用时可以通过proxy_pass代理方式把网站的请求发送到事先定义好的对应upstream组的名字上,

nginx实现负载均衡、状态检测

upstream.health-check模块实现负载均衡.状态检测 拓扑图: 服务器A增加一个网卡,与服务器B和服务器C通信,地址如上图 服务器A: 配置地址,查看如下: 源码安装nginx-1.0.11 yum --disablerepo=\* --enablerepo=c6-media install pcre-devel openssl-devel -y   安装必要的软件包 1.[[email protected] ~]# tar -zxvf nginx-1.0.11.tar.gz  

nginx、Apache负载均衡后端主机tomcat,并实现session保持

一.实验环境准备 1.主机规划 Apache主机 172.18.12.20 TomcatA 172.18.12.21 TomcatB 172.18.12.22 2.tomcat主机安装和配置 # yum install -y java-1.7.0-openjdk java-1.7.0-openjdk-devel # vim /etc/profile.d/java.sh # yum install -y tomcat tomcat-lib tomcat-webapps tomcat-admin-w

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

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

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/

Nginx负载均衡与反向代理—《亿级流量网站架构核心技术》

当我们的应用单实例不能支撑用户请求时,此时就需要扩容,从一台服务器扩容到两台.几十台.几百台.然而,用户访问时是通过如http://www.XX.com的方式访问,在请求时,浏览器首先会查询DNS服务器获取对应的IP,然后通过此IP访问对应的服务.因此,一种方式是www.XX.com域名映射多个IP,但是,存在一个最简单的问题,假设某台服务器重启或者出现故障,DNS会有一定的缓存时间,故障后切换时间长,而且没有对后端服务进行心跳检查和失败重试的机制.因此,外网DNS应该用来实现用GSLB(全局负