编译添加fair模块
fair模式会按后端服务器的响应时间来分配请求,响应时间短的优先分配。
1、下载nginx-upstream-fair模块
https://github.com/gnosek/nginx-upstream-fair
2、将下载资源上传并进行重命名
unzip nginx-upstream-fair-master.zip
mv nginx-upstream-fair-master fair
3、查看nginx信息并进行重新编译
nginx -V
红框里的因为nginx以前就添加过模块不用在意,没有的添加上就可以
# 重新编译并添加fair模块
./configure --user=root --group=root \
--prefix=/home/utry/utry_workspace/nginx \
--with-http_stub_status_module \
--with-http_gzip_static_module \
--with-http_realip_module \
--with-http_sub_module \
--with-http_ssl_module \
--with-stream \
--add-module=/home/install/nginx/nginx-upstream-fair-master
# 编译
make
如果出现上述报错,解决方式如下:
在Nginx的源码中 src/http/ngx_http_upstream.h,找到ngx_http_upstream_srv_conf_s,在模块中添加default_port属性
重新编译即可
# 将objs下生成的nginx替换掉原来的
cp -a sbin/nginx sbin/nginx.old
\cp -rf objs/nginx sbin/nginx
执行热更新
make upgrade
编译添加nginx_upstream_check_module模块
这个模块是阿里的姚伟斌大佬开发的一个模块,nginx本身并不具备主动健康检查的能力,因此会有一定局限性,而此模块会定时向服务发送请求,不健康的服务会从服务列表中进行摘除。
- TCP层默认检查方案:
定时与后端服务建立一条tcp连接,链接建立成功则认为服务节点是健康的。 - HTTP层默认检查方案:TCP层检查有一定的局限性:
- 很多HTTP服务是带状态的,端口处于listen状态并不能代表服务已经完成预热;
- 不能真实反映服务内部处理逻辑是否产生拥堵。
- 这时可以选择http层健康检查,会向服务发送一个http请求GET / HTTP/1.0\r\n\r\n,返回状态是2xx或3xx时认为后端服务正常。
下载地址
wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master
打补丁进行编译
这一步很重要,如果不打补丁则无法使用check模块
# 打补丁,验证下来目前为止1.20.1以上的几个版本甚至到1.23.1均可使用此补丁
patch -p1 < nginx_upstream_check_module-master/check_1.20.1+.patch
# 添加check模块
./configure --user=root --group=root --prefix=/home/utry/utry_workspace/nginx \
--with-http_stub_status_module \
--with-http_gzip_static_module \
--with-http_realip_module \
--with-http_sub_module \
--with-http_ssl_module \
--with-stream \
--add-module=/home/utry/utry_workspace/nginx/fair \
--add-module=/home/utry/utry_workspace/nginx/nginx_upstream_check_module-0.3.0
# 编译
make
# 将objs下生成的nginx替换掉原来的
cp -a sbin/nginx sbin/nginx.old
\cp -rf objs/nginx sbin/nginx
进行热更新
make upgrade
check模块常用配置
check fall=3 interval=3000 rise=2 timeout=2000 type=http;
check_http_expect_alive http_2xx http_3xx ;
check_http_send "GET /checkAlive HTTP/1.0\\r\\n\\r\\n" ;
check 字段参数如下
Syntax: check interval=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=5 rise=2 timeout=1000 default_down=true type=tcp
check 字段各个参数含义如下:
- 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提供真实服务的端口一样。 - mysql: 向mysql服务器连接,通过接收服务器的greeting包来判断后端是否存活
- tcp:
Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]
Default: http_2xx | http_3xx
Context: upstream
该指令指定HTTP回复的成功状态,默认认为2XX和3XX的状态是健康的。
Syntax: check_shm_size size
Default: 1M
Context: http
所有的后端服务器健康检查状态都存于共享内存中,该指令可以设置共享内存的大小。默认是1M,如果你有1千台以上的服务器并在配置的时候出现了错误,就可能需要扩大该内存的大小。
Syntax: check_status [html|csv|json]
Default: check_status html
Context: location
显示服务器的健康状态页面。该指令需要在http块中配置。
location /status {
check_status json;
access_log off;
#allow 3.127.0.0;
#deny all;
}
演示机配置案例
初始默认状态均为down,当rise为1时候则显示为up,同时fall counts达到2次则表示检测到一台服务器宕机,则进行摘除,标记为down,所有请求将不会再向该台服务器转发
注意:fair模块跟check模块无法同时进行配置,如果同时配置则check模块会失效