nginx负载均衡宕机配置.docx
《nginx负载均衡宕机配置.docx》由会员分享，可在线阅读，更多相关《nginx负载均衡宕机配置.docx（9页珍藏版）》请在冰豆网上搜索。
nginx负载均衡宕机配置
nginx-负载均衡宕机配置
1. 摘要
（1） 结论
详细描述了nginx记录失效节点的6种状态（timeout、connectrefuse、500、502、503、504，后四项5XX需要配置proxy_next_upstream中的状态才可以生效）、失效节点的触发条件和节点的恢复条件、所有节点失效后nginx会进行恢复并进行重新监听。
（2） Nginx 负载均衡方式介绍
Nginx的负载均衡方式一共有4种：
rr（轮询模式）、ip_hash、fair、url_hash。
（3） Ngxin负载均衡和相关反向代理配置内容
Nginx负载均衡和与容错相关的反向代理的配置。
（4） 获取后端流程
后端server的自动容错流程图。
（5） 测试环境和测试结果
针对几种错误方式进行自动容错测试。
2. 结论
（1） nginx 判断节点失效状态
Nginx 默认判断失败节点状态以connectrefuse和timeout状态为准，不以HTTP错误状态进行判断失败，因为HTTP只要能返回状态说明该节点还可以正常连接，所以nginx判断其还是存活状态；除非添加了proxy_next_upstream指令设置对404、502、503、504、500和timeout等错误进行转到备机处理，在next_upstream过程中，会对fails进行累加，如果备用机处理还是错误则直接返回错误信息（但404不进行记录到错误数，如果不配置错误状态也不对其进行错误状态记录），综述，nginx记录错误数量只记录timeout 、connectrefuse、502、500、503、504这6种状态，timeout和connectrefuse是永远被记录错误状态，而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将重新恢复所有节点进行探测
● down- 标记服务器处于离线状态，通常和ip_hash一起使用。
● backup-（0.6.7或更高）如果所有的非备份服务器都宕机或繁忙，则使用本服务器（无法和ip_hash指令搭配使用）。
示例配置
upstream backend {
server 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
语法：
upstreamname{…}
默认值：
none
使用字段：
http
这个字段设置一群服务器，可以将这个字段放在proxy_pass和fastcgi_pass指令中作为一个单独的实体，它们可以可以是监听不同端口的服务器，并且也可以是同时监听TCP和Unixsocket的服务器。
服务器可以指定不同的权重，默认为1。
示例配置
upstreambackend{
serverweight=5;
server127.0.0.1:
8080 max_fails=3 fail_timeout=30s;
serverunix:
/tmp/backend3;
}
请求将按照轮询的方式分发到后端服务器，但同时也会考虑权重。
在上面的例子中如果每次发生7个请求，5个请求将被发送到，其他两台将分别得到一个请求，如果有一台服务器不可用，那么请求将被转发到下一台服务器，直到所有的服务器检查都通过。
如果所有的服务器都无法通过检查，那么将返回给客户端最后一台工作的服务器产生的结果。
2） 变量
版本0.5.18以后，可以通过log_module中的变量来记录日志：
log_formattiming'$remote_addr-$remote_user[$time_local] $request'
'upstream_response_time$upstream_response_time'
'msec$msecrequest_time$request_time';
log_formatup_head'$remote_addr-$remote_user[$time_local] $request'
'upstream_http_content_type$upstream_http_content_type';
● $upstream_addr
前端服务器处理请求的服务器地址
● $upstream_cache_status
0.8.3版本中其值可能为：
MISS
EXPIRED-expired。
请求被传送到后端。
UPDATING-expired。
由于proxy/fastcgi_cache_use_stale正在更新，将使用旧的应答。
STALE-expired。
由于proxy/fastcgi_cache_use_stale，后端将得到过期的应答。
HIT
● $upstream_status
前端服务器的响应状态。
● $upstream_response_time
前端服务器的应答时间，精确到毫秒，不同的应答以逗号和冒号分开。
● $upstream_http_$HEADER
随意的HTTP协议头，如：
$upstream_http_host
● $upstream_http_host
3） Proxy指令：
proxy_next_upstream
语法:
proxy_next_upstream
[error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off]
默认值：
proxy_next_upstreamerrortimeout
使用字段：
http,server,location
确定在何种情况下请求将转发到下一个服务器：
error- 在连接到一个服务器，发送一个请求，或者读取应答时发生错误。
timeout- 在连接到服务器，转发请求或者读取应答时发生超时。
invalid_header- 服务器返回空的或者错误的应答。
http_500- 服务器返回500代码。
http_502- 服务器返回502代码。
http_503- 服务器返回503代码。
http_504- 服务器返回504代码。
http_404- 服务器返回404代码。
off- 禁止转发请求到下一台服务器。
转发请求只发生在没有数据传递到客户端的过程中。
其中记录到nginx后端错误数量的有500、502、503、504、timeout，404不记录错误。
proxy_connect_timeout
语法：
proxy_connect_timeouttimeout_in_seconds
默认值：
proxy_connect_timeout60s
使用字段：
http,server,location
指定一个连接到代理服务器的超时时间，单位为秒，需要注意的是这个时间最好不要超过75秒。
这个时间并不是指服务器传回页面的时间（这个时间由proxy_read_timeout声明）。
如果你的前端代理服务器是正常运行的，但是遇到一些状况（例如没有足够的线程去处理请求，请求将被放在一个连接池中延迟处理），那么这个声明无助于服务器去建立连接。
可以通过指定时间单位以免引起混乱，支持的时间单位有”s”（秒）,“ms”（毫秒）,“y”（年）,“M”（月）,“w”（周）,“d”（日）,“h”（小时）,和 “m”（分钟）。
这个值不能大于597小时。
proxy_read_timeout
语法：
proxy_read_timeouttime
默认值：
proxy_read_timeout60s
使用字段：
http,server,location
决定读取后端服务器应答的超时时间，单位为秒，它决定nginx将等待多久时间来取得一个请求的应答。
超时时间是指完成了两次握手后并且状态为established的超时时间。
相对于proxy_connect_timeout，这个时间可以扑捉到一台将你的连接放入连接池延迟处理并且没有数据传送的服务器，注意不要将此值设置太低，某些情况下代理服务器将花很长的时间来获得页面应答（例如如当接收一个需要很多计算的报表时），当然你可以在不同的location里面设置不同的值。
可以通过指定时间单位以免引起混乱，支持的时间单位有”s”（秒）,“ms”（毫秒）,“y”（年）,“M”（月）,“w”（周）,“d”（日）,“h”（小时）,和 “m”（分钟）。
这个值不能大于597小时。
proxy_send_timeout
语法：
proxy_send_timeoutseconds
默认值：
proxy_send_timeout60s
使用字段：
http,server,location
设置代理服务器转发请求的超时时间，单位为秒，同样指完成两次握手后的时间，如果超过这个时间代理服务器没有数据转发到被代理服务器，nginx将关闭连接。
可以通过指定时间单位以免引起混乱，支持的时间单位有”s”（秒）,“ms”（毫秒）,“y”（年）,“M”（月）,“w”（周）,“d”（日）,“h”（小时）,和 “m”（分钟）。
这个值不能大于597小时。
5. 获取后端流程
GET_RR_PEER：
通过RR算法获取后端流程
K:
是判断peer是否宕机和判断失效状态算法
FAIL:
尝试次数用尽有，跳转到失败流程，如果有备机，备机再尝试监听，如果监听失败则返回NGX_BUSY,成功则返回当前状态。
6. 测试环境
操作系统：
centos5.6
Cpu:
16核
内存：
32g
Web 服务器:
nginx
Web 应用服务器：
tomcat（2台）
7. 测试结果
● 设置tomcat1超时时间，造成超时状态（总有一台server为有效状态）：
Tomcat1的connectionTimeout 设置为-1，永远超时，nginx设置tomcat1和tomcat2权重为10，tomcat1的max_fails为10，fail_timeout=120；在连接tomcat1的10次后，返回给nginx为10次超时，ngxin判断tomcat1为失效，然后将tomcat1超时时间恢复为1000重新启动tomcat1，在这段时间内nginx判断tomcat1还是失效状态，所以在2分钟后，nginx继续监听到tomcat1正常后，那么nginx会将tomcat1判断为有效，将连接继续均匀分配到2个tomcat上。
● 设置tomcat1连接数量，造成超时状态（总有一台server为有效状态）：
Tomcat1的线程数量设置为1，nginx设置tomcat1和tomcat2权重为10，tomcat1的max_fails为10，fail_timeout=120；在连接tomcat1超过线程接受数量后，tomcat1会返回超时状态，在返回给nginx10次超时状态后，ngxin判断tomcat1为失效，然后将tomcat线程数量恢复为700,重新启动tomcat1，在这段时间内nginx判断tomcat1还是失效状态，超过2分钟失效后，nginx继续监听到tomcat1正常后，那么nginx会将tomcat1判断为有效，将连接继续均匀分配到2个tomcat上。
● 设置tomcat1关闭，造成拒绝状态（总有一台server为有效状态）：
Tomcat1为关闭，nginx设置tomcat1和tomcat2权重为10，tomcat1的max_fails为10，fail_timeout=120；在连接tomcat1的10次后，nginx收到tomcat1返回connectrefuse状态，ngxin判断tomcat1为失效，然后重新启动tomcat1，在这段时间内nginx判断tomcat1还是失效状态，超过2分钟失效后，nginx继续监听到tomcat1正常后，那么nginx会将tomcat1判断为有效，将连接继续均匀分配到2个tomcat上。
● 设置tomcat1在nginx1标记失效，tomcat1恢复正常，在nginx失效范围内，将全部服务变为失效，然后重启：
Tomcat1为关闭，nginx设置tomcat1和tomcat2权重为10，tomcat1的max_fails为10，fail_timeout=120；在连接tomcat1的10次后，nginx收到tomcat1返回connectrefuse状态，ngxin判断tomcat1为失效，然后重新启动tomcat1，在这段时间内nginx判断tomcat1还是失效状态，然后将tomcat2关闭，然后重启tomcat2，由于所有服务均失效，所以nginx 将所有服务重新置为有效进行监听，然后将2连接均匀分布到了tomcat1和tomcat2上。
● http错误状态，nginx是否记录失效：
nginx设置tomcat1和tomcat2权重为10，tomcat1的max_fails为10，fail_timeout=120；配置proxy_next_upstream500、404、502、503、504、timeout后，当HTTP状态为500、502、503、504（timeout和refuse默认是记录失效的）时，nginx会判断该次请求为失败记录失败状态，其他所有HTTP均不记录失败
升级会员 