Nginx之负载节点状态监测

前言

nginx做负载均衡性能很好，但是负载中的节点有异常怎么处理呢？

当然是nginx发现某一个节点为异常节点后自动将请求转移至其他节点直至转移到一个正常节点。

为了实现这一步有如下两个解决方案可供选择，推荐方案一（不需要安装module）。

下面进行两个解决方案的详细赘述。

一、使用nginx的upstream自带属性进行配置

配置示例

upstream circle_server {
  ...
  server 192.168.0.88:8080 max_fails=1 fail_timeout=10;
  ...
}

默认：fail_timeout为10s,max_fails为1次。

原理解析：

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

同时，upstream还有其他属性，见文章尾部。

二、使用nginx_upstream_check_module模块进行负载监测

1.官方地址

https://github.com/yaoweibin/nginx_upstream_check_module

2.安装nginx_upstream_check_module模块

系统如果已经安装nginx，则需要采取打补丁的方式安装该模块

查看安装版本

/application/nginx/sbin/nginx -v

下载补丁包

wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master

解压下载的补丁包

unzip master

重新编译nginx

因为是对nginx打补丁，需要对应安装版本的软件包

cd nginx-1.15.12
patch -p1 < ../nginx_upstream_check_module-master/check_1.14.0+.patch 

编译参数要和以前一样，最后加上 --add-module=…/nginx_upstream_check_module-master/

./configure --user=www --group=www --prefix=/application/nginx-1.15.2 --with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module --add-module=../nginx_upstream_check_module-master/

安装

make && make install

配置

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访问
       }
    }
}

3. 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。

三、upstream知识扩充

upstream 参数
nginx关于upstream参数官方文档：http://nginx.org/en/docs/http/ngx_http_upstream_module.html

server

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除 配置如下:

upstream names{
server 127.0.0.1:8050 ;
server 127.0.0.1:8060 ;
}

weight(权重)

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

upstream tuling {
server 127.0.0.1:8050 weight=5;
server 127.0.0.1:8060 weight=1;
}

max_conns

可以根据服务的好坏来设置最大连接数，防止挂掉，比如1000，我们可以设置800

upstream tuling {
server 127.0.0.1:8050 weight=1 max_fails=1 fail_timeout=20;
server 127.0.0.1:8060 weight=1;
}

max_fails、 fail_timeout

max_fails:失败多少次 认为主机已挂掉则，踢出，公司资源少的话一般设置2~3次，多的话设置1次

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

upstream tuling {
server 127.0.0.1:8050 weight=1 max_fails=1 fail_timeout=20;
server 127.0.0.1:8060 weight=1;
}

//关闭掉8050的服务 你会发现在20秒内还是访问8060的，20s后才会访问8050

记得修改完nginx.conf 后，./sbin/nginx -s reload 重启nginx ,然后我们可以让8050关闭来演示

负载均衡算法

轮询+weight   默认的

ip_hash : 基于Hash 计算

应用场景：保持session 一至性

url_hash: (第三方)

应用场景：静态资源缓存,节约存储，加快速度

least_conn 最少链接

least_time 最小的响应时间,计算节点平均响应时间，然后取响应最快的那个，分配更高权重。

下面是ip_hash,url_hash的示意图

下面是nginx大概的参数流程（粗略）