码迷,mamicode.com
首页 > Web开发 > 详细

Nginx负载均衡upstream容错机制(ngx_http_proxy_module)梳理

时间:2018-01-03 21:09:10      阅读:259      评论:0      收藏:0      [点我收藏+]

标签:成功率   sock   oca   ack   ken   两台   容灾   nginx   案例分析   

 

熟练掌握Nginx负载均衡的使用对运维人员来说是极其重要的!下面针对Nignx负载均衡upstream容错机制的使用做一梳理性说明:

一、nginx的upstream容错

1)nginx 判断节点失效状态
Nginx默认判断失败节点状态以connect refuse和time out状态为准,不以HTTP错误状态进行判断失败,因为HTTP只要能返回状态说明该节点还可以正常连接,所以nginx判断其还是存活状态;除非添加了proxy_next_upstream指令设置对404、502、503、504、500和time out等错误进行转到备机处理,在next_upstream过程中,会对fails进行累加,如果备用机处理还是错误则直接返回错误信息(但404不进行记录到错误数,如果不配置错误状态也不对其进行错误状态记录),综述,nginx记录错误数量只记录timeout 、connect refuse、502、500、503、504这6种状态,timeout和connect refuse是永远被记录错误状态而502、500、503、504只有在配置proxy_next_upstream后nginx才会记录这4种HTTP错误到fails中,当fails大于等于max_fails时,则该节点失效

2)nginx 处理节点失效和恢复的触发条件
nginx可以通过设置max_fails(最大尝试失败次数)fail_timeout(失效时间,在到达最大尝试失败次数后,在fail_timeout的时间范围内节点被置为失效,除非所有节点都失效,否则该时间内,节点不进行恢复)对节点失败的尝试次数和失效时间进行设置,当超过最大尝试次数或失效时间未超过配置失效时间,则nginx会对节点状会置为失效状态,nginx不对该后端进行连接,直到超过失效时间或者所有节点都失效后,该节点重新置为有效,重新探测;

3)所有节点失效后nginx将重新恢复所有节点进行探测
如果探测所有节点均失效,备机也为失效时,那么nginx会对所有节点恢复为有效,重新尝试探测有效节点,如果探测到有效节点则返回正确节点内容,如果还是全部错误,那么继续探测下去,当没有正确信息时,节点失效时默认返回状态为502,但是下次访问节点时会继续探测正确节点,直到找到正确的为止。

4)通过proxy_next_upstream实现容灾和重复处理问题
ngx_http_proxy_module 模块中包括proxy_next_upstream指令
语法: 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

其中:
error   表示和后端服务器建立连接时,或者向后端服务器发送请求时,或者从后端服务器接收响应头时,出现错误。
timeout   表示和后端服务器建立连接时,或者向后端服务器发送请求时,或者从后端服务器接收响应头时,出现超时。
invalid_header   表示后端服务器返回空响应或者非法响应头
http_500   表示后端服务器返回的响应状态码为500
http_502   表示后端服务器返回的响应状态码为502
http_503   表示后端服务器返回的响应状态码为503
http_504   表示后端服务器返回的响应状态码为504
http_404   表示后端服务器返回的响应状态码为404
off   表示停止将请求发送给下一台后端服务器

运用场景

1)proxy_next_upstream http_500 | http_502 | http_503 | http_504 |http_404;
当其中一台返回错误码404,500...等错误时,可以分配到下一台服务器程序继续处理,提高平台访问成功率,多可运用于前台程序负载,设置

2、proxy_next_upstream off
因为proxy_next_upstream 默认值: proxy_next_upstream error timeout;

场景:
当访问A时,A返回error timeout时,访问会继续分配到下一台服务器处理,就等于一个请求分发到多台服务器,就可能出现多次处理的情况,
如果涉及到充值,就有可能充值多次的情况,这种情况下就要把proxy_next_upstream关掉即可
proxy_next_upstream off

案例分析(nginx proxy_next_upstream导致的一个重复提交错误):
一个请求被重复提交,原因是nginx代理后面挂着2个服务器,请求超时的时候(其实已经处理了),结果nigix发现超时,有把请求转给另外台服务器又做了次处理。

解决办法:
proxy_next_upstream:off

二、nginx负载均衡
Nginx的负载均衡方式这里介绍4种:rr(轮询模式)、ip_hash、fair、url_hash;
Nginx自带的2种负载均衡为rr和ip_hash,fair和url_hash为第三方的插件,nginx在不配置负载均衡的模式下,默认采用rr负载均衡模式。
1)RR负载均衡模式:
每个请求按时间顺序逐一分配到不同的后端服务器,如果超过了最大失败次数后(max_fails,默认1),在失效时间内(fail_timeout,默认10秒),该节点失效权重变为0,超过失效时间后,则恢复正常,或者全部节点都为down后,那么将所有节点都恢复为有效继续探测,一般来说rr可以根据权重来进行均匀分配。
2)Ip_hash负载均衡模式:
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题,但是ip_hash会造成负载不均,有的服务请求接受多,有的服务请求接受少,所以不建议采用ip_hash模式,session共享问题可用后端服务的session共享代替nginx的ip_hash。
3)Fair(第三方)负载均衡模式:
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
4)url_hash(第三方)负载均衡模式:
和ip_hash算法类似,是对每个请求按url的hash结果分配,使每个URL定向到一个同 一个后端服务器,但是也会造成分配不均的问题,这种模式后端服务器为缓存时比较好。

三、Nginx负载均衡配置
Nginx的负载均衡采用的是upstream模块,其中默认的采用的负载均衡模式是轮询模式rr(round_robin),具体配置如下:
1)指令:
ip_hash
语法:ip_hash
默认值:none
使用字段:upstream
这个指令将基于客户端连接的IP地址来分发请求。
哈希的关键字是客户端的C类网络地址,这个功能将保证这个客户端请求总是被转发到一台服务器上,但是如果这台服务器不可用,那么请求将转发到另外的服务器上,这将保证某个客户端有很大概率总是连接到一台服务器。
无法将权重(weight)与ip_hash联合使用来分发连接。如果有某台服务器不可用,你必须标记其为"down",如下例:

upstream backend {
  ip_hash;
  server   backend1.kevin.com;
  server   backend2.kevin.com;
  server   backend3.kevin.com  down;
  server   backend4.kevin.com;
}

server
语法:server name [parameters]
默认值:none
使用字段:upstream
指定后端服务器的名称和一些参数,可以使用域名,IP,端口,或者unix socket。如果指定为域名,则首先将其解析为IP。
[1]  weight = NUMBER - 设置服务器权重,默认为1。
[2]  max_fails = NUMBER - 在一定时间内(这个时间在fail_timeout参数中设置)检查这个服务器是否可用时产生的最多失败请求数,默认为1,将其设置为0可以关闭检查,这些错误在proxy_next_upstream或fastcgi_next_upstream(404错误不会使max_fails增加)中定义。
[3]  fail_timeout = TIME - 在这个时间内产生了max_fails所设置大小的失败尝试连接请求后这个服务器可能不可用,同样它指定了服务器不可用的时间(在下一次尝试连接请求发起之前),默认为10秒,fail_timeout与前端响应时间没有直接关系,不过可以使用proxy_connect_timeout和proxy_read_timeout来控制。
[4]  down - 标记服务器处于离线状态,通常和ip_hash一起使用。
[5]  backup - (0.6.7或更高)如果所有的非备份服务器都宕机或繁忙,则使用本服务器(无法和ip_hash指令搭配使用)。

实例配置

upstream  backend  {
  server   backend1.kevin.com    weight=5;
  server   127.0.0.1:8080          max_fails=3  fail_timeout=30s;
  server   unix:/tmp/backend3;
}

注意:如果你只使用一台上游服务器,nginx将设置一个内置变量为1,即max_fails和fail_timeout参数不会被处理。
结果:如果nginx不能连接到上游,请求将丢失。
解决:使用多台上游服务器。

upstream
语法:upstream name { … }
默认值:none
使用字段:http
这个字段设置一群服务器,可以将这个字段放在proxy_pass和fastcgi_pass指令中作为一个单独的实体,它们可以可以是监听不同端口的服务器,并且也可以是同时监听TCP和Unix socket的服务器。
服务器可以指定不同的权重,默认为1。
示例配置

upstream backend {
  server kevin.com weight=5;
  server 127.0.0.1:8080       max_fails=3  fail_timeout=30s;
  server unix:/tmp/backend3;
}

请求将按照轮询的方式分发到后端服务器,但同时也会考虑权重。
在上面的例子中如果每次发生7个请求,5个请求将被发送到backend1.kevin.com,其他两台将分别得到一个请求,如果有一台服务器不可用,那么请求将被转发到下一台服务器,直到所有的服务器检查都通过。如果所有的服务器都无法通过检查,那么将返回给客户端最后一台工作的服务器产生的结果。

 

 

 

 

Nginx负载均衡upstream容错机制(ngx_http_proxy_module)梳理

标签:成功率   sock   oca   ack   ken   两台   容灾   nginx   案例分析   

原文地址:https://www.cnblogs.com/kevingrace/p/8185218.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!