原文链接:http://nolinux.blog.51cto.com/4824967/1594029?utm_source=tuicool&utm_medium=referral
最近由于服务经常崩掉,所以打算做一个负载均衡,使用nginx,前两篇总结了nginx的使用,这个主要总结下健康检查
1:windows下nginx使用健康检查
windows下的nginx没有linux下的nginx社区环境好,故这里主要使用的是nginx自带的健康检查
ngx_http_proxy_module 模块和ngx_http_upstream_module模块(自带)
配置如下:
#error_log logs/error.log; #pid logs/nginx.pid;
#access_log logs/access.log main; sendfile on; #keepalive_timeout 0; #gzip on; location / {
# another virtual host using mix of IP-, name-, and port-based configuration # location / {
# ssl_certificate cert.pem; # ssl_session_cache shared:SSL:1m; # ssl_ciphers HIGH:!aNULL:!MD5; # location / { } |
严格来说,nginx自带是没有针对负载均衡后端节点的健康检查的,但是可以通过默认自带的ngx_http_proxy_module 模块和ngx_http_upstream_module模块中的相关指令来完成当后端节点出现故障时,自动切换到健康节点来提供访问。
这里列出这两个模块中相关的指令:
ngx_http_proxy_module 模块中的 proxy_connect_timeout 指令、proxy_read_timeout指令和proxy_next_upstream指令
1
2
3
|
语法: proxy_connect_timeout time ; 默认值:proxy_connect_timeout 60s; 上下文:http, server, location |
定义从后端服务器读取响应的超时。此超时是指相邻两次读操作之间的最长时间间隔,而不是整个响应传输完成的最长时间。如果后端服务器在超时时间段内没有传输任何数据,连接将被关闭。
1
2
3
|
语法: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...; 默认值: proxy_next_upstream error timeout; 上下文: http, server, location |
指定在何种情况下一个失败的请求应该被发送到下一台后端服务器:
1
2
3
4
5
6
7
8
9
|
error # 和后端服务器建立连接时,或者向后端服务器发送请求时,或者从后端服务器接收响应头时,出现错误 timeout # 和后端服务器建立连接时,或者向后端服务器发送请求时,或者从后端服务器接收响应头时,出现超时 invalid_header # 后端服务器返回空响应或者非法响应头 http_500 # 后端服务器返回的响应状态码为500 http_502 # 后端服务器返回的响应状态码为502 http_503 # 后端服务器返回的响应状态码为503 http_504 # 后端服务器返回的响应状态码为504 http_404 # 后端服务器返回的响应状态码为404 off # 停止将请求发送给下一台后端服务器 |
需要理解一点的是,只有在没有向客户端发送任何数据以前,将请求转给下一台后端服务器才是可行的。也就是说,如果在传输响应到客户端时出现错误或者超时,这类错误是不可能恢复的。
范例如下:
1
2
3
|
http { proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header; } |
ngx_http_upstream_module模块中的server指令
1
2
3
|
语法: server address [parameters]; 默认值: — 上下文: upstream |
范例如下:
1
2
3
4
|
upstream name { server 10.1.1.110:8080 max_fails=1 fail_timeout=10s; server 10.1.1.122:8080 max_fails=1 fail_timeout=10s; } |
下面是每个指令的介绍:
1
2
3
4
5
6
|
max_fails=number # 设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内,如果失败的次数达到此值,Nginx就认为服务器不可用。在下一个fail_timeout时间段,服务器不会再被尝试。 失败的尝试次数默认是1。设为0就会停止统计尝试次数,认为服务器是一直可用的。 你可以通过指令proxy_next_upstream、fastcgi_next_upstream和 memcached_next_upstream来配置什么是失败的尝试。 默认配置时,http_404状态不被认为是失败的尝试。 fail_timeout= time # 设定服务器被认为不可用的时间段以及统计失败尝试次数的时间段。在这段时间中,服务器失败次数达到指定的尝试次数,服务器就被认为不可用。默认情况下,该超时时间是10秒。 在实际应用当中,如果你后端应用是能够快速重启的应用,比如nginx的话,自带的模块是可以满足需求的。但是需要注意。如果后端有不健康节点,负载均衡器依然会先把该请求转发给该不健康节点,然后再转发给别的节点,这样就会浪费一次转发。 可是,如果当后端应用重启时,重启操作需要很久才能完成的时候就会有可能拖死整个负载均衡器。此时,由于无法准确判断节点健康状态,导致请求handle住,出现假死状态,最终整个负载均衡器上的所有节点都无法正常响应请求。由于公司的业务程序都是java开发的,因此后端主要是nginx集群和tomcat集群。由于tomcat重启应部署上面的业务不同,有些业务启动初始化时间过长,就会导致上述现象的发生,因此不是很建议使用该模式。 并且ngx_http_upstream_module模块中的server指令中的max_fails参数设置值,也会和ngx_http_proxy_module 模块中的的proxy_next_upstream指令设置起冲突。比如如果将max_fails设置为0,则代表不对后端服务器进行健康检查,这样还会使fail_timeout参数失效(即不起作用)。此时,其实我们可以通过调节ngx_http_proxy_module 模块中的 proxy_connect_timeout 指令、proxy_read_timeout指令,通过将他们的值调低来发现不健康节点,进而将请求往健康节点转移。 以上就是nginx自带的两个和后端健康检查相关的模块。 |
这就是windows下关于nginx自带的模块进行配置健康检查,其实在linux下也可以使用,其余的高级功能在这暂不介绍。
原文:https://www.cnblogs.com/xiaofengshan/p/13922603.html