【NGINX入门】8.Nginx的upstream 模块及参数测

2021-02-03 本文已影响0人笔名辉哥

1. 摘要

本文介绍Nginx的upstream模块的指令和参数说明。

 2. 配置示例及指令说明
   2.1 配置示例
  2.2 指令
  2.3 upstream相关变量
 3. 参数配置及测试
   3.1 max_fails 和 fail_timeout
   3.2 proxy_next_upstream
   3.3 nginx 与后端web连接时间的三个参数

2. 配置示例及指令说明

2.1 配置示例

2.2 指令

指令名称: upstream

语法：upstream name { … }
默认值：none
使用环境：http
功能：该指令是一个组合型指令它描述了一组服务器，这组服务器将会被指令 proxy_pass 和 fastcgi_pass 作为一个单独的实体使用，它们可以将 server 监听在不同的端口，而且还可以同时使用TCP和UNIX套接字监听。服务器可以设置不同的权重，如果没有设置权重，那么默认会将其设置为 1 。

指令名称: ip_hash

语法：ip_hash
默认值：none
使用环境：upstream
功能：如果使用了该指令，那么将会导致客户端的请求以用户端IP地址分布在 upstream 中的 server 之间。它的关键技术在于对这个请求客户端IP地址进行哈希计算，这种方法保证了客户端请求总是能够传递到同一台后台服务器，但是如果该服务器被认定为无效，那么这个客户端的请求将会被传递到其他服务器，因此，这种机制是一个高概率将客户端请求总是连接到同一台服务器。

Nginx 的 upstream 支持 5 种分配方式，其中有三种为 Nginx 原生支持的分配方式，后两种为第三方支持的分配方式。

轮询。upstream默认采用的就是轮询方式.
权重（weight）轮询模式的加强版，每个后端server 默认 weight=1
ip_hash 每个请求按照访问IP的hash结果分配这样每个访客会固定访问一个后端服务器，可以解决session 一致问题
fair 第三方分配方式。平地按照后端服务器的响应时间（rt）来分配请求，响应时间短即rt小的后端服务器优先分配请求。如果需要使用这种调度算法，必须下载Nginx的upstr_fair模块。
url_hash 平地按照后端服务器的响应时间（rt）来分配请求，响应时间短即rt小的后端服务器优先分配请求。如果需要使用这种调度算法，必须下载Nginx的upstr_fair模块。

指令名称: server

语法：server name [parameters]
默认值：none
使用环境：upstream
功能：该指令用于设置服务器的 name，对于 name，可以使用域名、ip地址、端口或是 UNIX 套接字，如果一个域名被解析到多个 IP 地址，那么所有的 IP 地址都将会被使用。
可选的 parameters 如下：

weight=NUMBER 用于设置服务器的权重。如果没有设置，那么它将会等于 1
max_fails=NUMBER 该参数用于对后端服务器进行检测，如果达到 NUMBER 次数依然失败，则该 server 会被暂停 fail_timeout 秒，如果没有设置该参数，那么尝试的次数为1，如果设置为 0 则关闭检测。失败的依据是根据 proxy_next_upstream 提供的。
fail_timeout=TIME 该参数用于设置客户端到达 max_fails 次数后，该server 被暂停的时间。如果没有设置该参数，那么默认为 10秒。
down：如果为某一个 server 设置了该参数，那么标记了这台 server 将永久离线。通常这个参数与 ip_hash 一同使用。
backup：该参数在 0.6.7 版本中提供，它是一个备用标识，如果出现所有的非备份服务器全部宕机或繁忙无法接受连接时，那么才会使用本服务器，该参数无法和 ip_hash 指令一起使用。

2.3 upstream相关变量

变量名：$upstream_addr

功能：该变量表示了处理该请求的 upstream 中 server 的地址

变量名：$upstream_cache_status

功能：该变量出现在 Nginx 0.8.3 版本中，可能的值如下：

MISS - 缓存中未被命中
EXPIRED - 生存期期满，请求被传递到后端服务器
UPDATING - 生存期满，陈旧的响应被使用，因为proxy/fastcgi_cache_use_stale 升级
STALE - 生存期期满，陈旧的响应被使用，因为 proxy/fastcgi_cache_use_stale
HIT - 缓存命中

变量名：$upstream_status

功能：该变量为 upstream 中 server 的响应状态

变量名：$upstream_response_time

功能：upstream server 响应的时间，单位为秒，能够精准到毫秒。如果有多个 server 响应回答，那么会用逗号和冒号分隔开

变量名： $upstream_http_$ HEADER

功能：HTTP 协议头。例如：$upstream_http_host

3. 参数配置及测试

参数相关说明介绍完毕，接下来重点测试部分参数：

1台反向代理（nginx/1.14.2）
2台后端web（apache+php）

首先，查看客户端发起一次连接请求的过程：

image

通过抓包，可以看到浏览器请求一次 nginx 反向代理：

（9、10、11）客户端 -> nginx TCP 三次握手成功
（12、13）12. 浏览器发起 GET 请求 13. 回复 ACK
（14、15、16）nginx -> 后端web服务三次握手成功
（17、18） nginx 向后端web服务发起 get 请求， web服务ACK回复nginx
（19、20）后端web服务返回请求数据给 nginx （这里返回HTTP状态为 304 Not Modified）
（21、22）nginx 连接后端服务采用的是HTTP1.0 ，后端服务主动发送FIN主动断开连接，后端web服务器从ESTABLISHED转为 TIME_WAIT
（23）nginx 将后端返回的结果，再返回给客户端浏览器

3.1 max_fails 和 fail_timeout

fail_timeout - 出错后，暂停server的时间。</pre>

配置如下图：

主机信息：
（1）当 max_fails 为 0 ， fail_timeout 为 0

已知，upstream默认采用轮询的方式，web2服务关闭

通过浏览器快速刷新4次，分析如下：

首先查看 nginx 日志：

一共发起了 4 次连接请求，根据 upstream默认轮询方式，有两次都轮询到了 192.168.118.17 （服务关闭）上。

查看 web1（192.168.118.16）日志：

一共发起了 4 次请求，而 web1 接收到了 4 次，也就是这 4 次请求，都是 web1 来响应的。

为什么 4 次请求都是 web1 响应的呢？

通过上图，当 nginx 首次轮询到 web2 时，连接失败，web2 返回 RST，nginx会再次发起请求到 web1 。

总结：
（1）max_fails = 0 and fail_timeout = 0 时，后端服务故障时，依然会轮询到故障主机，且没有暂停服务时间的限制。

（2） max_fails = 0 and fail_timeout = 5

已知，upstream默认采用轮询的方式，web2服务关闭，配置如下：

通过浏览器快速刷新，分析如下：

nginx 日志

通过错误日志可以看出，当 upstream 没有设置最大错误数（max_fails），无论后端server是否有效，都会轮询到该server上，fail_timeout 设置任何值都是无效的。

（3） max_fails = 3 and fail_timeout = 5

已知，upstream默认采用轮询的方式，web2服务关闭，配置如下：

image

通过浏览器快速刷新，分析如下：

nginx 日志

通过配置最大失败连接数为 3 时，当后端web2服务关闭后，nginx首次会尝试 max_fails 次，如果仍然没响应，则暂停该server fail_timeout 秒，然后每隔 fail_timeout 时间后尝试一次，失败则继续暂停 fail_timeout 秒。

（4） max_fails = 3 and fail_timeout = 0
这种方式和 max_fails = 0 and fail_timeout = 3 测试结果一致，不在举例。
通过上面 max_fails 和 fail_timeout 测试，当要实现失败后暂停服务时，max_fails 和 fail_timeout 任何一项都不能为 0 。
在测试中，无论怎么刷新，nginx总是能够返回正常服务的server 数据，这是为什么？明明已经轮询到服务失效的节点，这里并没有定义任何的 proxy_next_upstream

解释：
针对nginx负载均衡upstream容错机制的使用说明
（1）nginx 的 upstream 容错
Nginx默认判断失败节点状态是以和 timeout （上面的例子就为web2-timeout）状态为准，不以HTTP错误状态进行判断失败，因为HTTP只要能返回状态说明该节点还可以正常连接，除非添加了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的时间范围内节点被置为失效，除非所有节点都失效，否则该时间内，节点不进行恢复）对节点失败的尝试次数和失效时间进行设置，当超过最大尝试次数，则失效fail_timeout 时间，nginx每隔 fail_timeout时间尝试一次后端server 有没有恢复，直到所有后端服务失效，则返回错误页面给客户端；

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

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

运用场景：
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

3.2 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

接下来，测试 proxy_next_upstream 是否能够定义失败的标准：

image

web1 - sleep 1秒
web2 - 返回 500 状态码

nginx配置如下：

image

upstream 默认后端server失效标准： timeout 和 Connect refuse，在这里例子中，使用

proxy_next_upstream http_500 http_502 http_504

[root@localhost ~]# curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} http://192.168.118.15/test.php
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Thu, 14 Mar 2019 10:53:51 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.4.16
RS: Web1

1.006:0.000:1.006

三次都是返回 200 状态，说明 proxy_next_upstream 已经将后端server 返回 500 状态的主机拦截为失效。

3.3 nginx 与后端web连接时间的三个参数

proxy_connect_timeout : 后端服务器连接的超时时间发起握手等候响应超时时间
proxy_read_timeout: 连接成功后，等候后端服务器响应时间其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）
proxy_send_timeout : 后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

这里对 proxy_read_timeout 进行测试：

nginx 配置：

image

web1 - test.php - sleep 3
web2 - test.php - sleep 5

测试结果：

[root@localhost ~]# curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} http://192.168.118.15/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/1.14.2
Date: Thu, 14 Mar 2019 11:27:59 GMT
Content-Type: text/html
Content-Length: 537
Connection: keep-alive
ETag: "5c89b5df-219"

2.004:0.001:2.004

三次返回结果一致，每次请求均耗时 2秒，这是因为 proxy_read_timeout 设置为 2s ，而后端的程序: web1-sleep 3 、web2-sleep 5，都无法及时响应。

修改 proxy_read_time 为 3 秒，测试如下：

[root@localhost ~]# curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} http://192.168.118.15/test.php
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Thu, 14 Mar 2019 11:33:30 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.4.16
RS: Web1

3.004:0.001:3.004

[root@localhost ~]# curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} http://192.168.118.15/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/1.14.2
Date: Thu, 14 Mar 2019 11:33:35 GMT
Content-Type: text/html
Content-Length: 537
Connection: keep-alive
ETag: "5c89b5df-219"

3.005:0.001:3.005

当轮询到 web1 -sleep 3秒时，满足 proxy_read_timeout 返回 200 状态，当轮询到 web2 -sleep 5秒时，超过 proxy_read_timeout 返回 504 状态。

总结：
对于 max_fails 和 fail_timeout 必须连用，但是都不能为 0 ，否则失效检查被禁止，每次都会轮询到失败的节点。
proxy_next_upstream 的使用一定要谨慎，有时候程序员会通过 HTTP 状态码来传递信息，如果不小心禁止了会造成不必要的麻烦。
proxy_read_timeout 参数根据业务场景需要进行设定，不宜过长，也不宜过短。

4. 参考

（1）Nginx - upstream 模块及参数测试[参数解析很详细] https://www.cnblogs.com/hukey/p/10534021.html

（2）upstream模块官网
http://nginx.org/en/docs/http/ngx_http_upstream_module.html

【NGINX入门】8.Nginx的upstream 模块及参数测

1. 摘要

2. 配置示例及指令说明

2.2 指令

指令名称: upstream

指令名称: ip_hash

指令名称: server

2.3 upstream相关变量

变量名：$upstream_addr

变量名：$upstream_cache_status

变量名：$upstream_status

变量名：$upstream_response_time

变量名： $upstream_http_$ HEADER

3. 参数配置及测试

3.2 proxy_next_upstream

3.3 nginx 与后端web连接时间的三个参数

4. 参考

猜你喜欢

热点阅读

【NGINX入门】8.Nginx的upstream 模块及参数测

1. 摘要

2. 配置示例及指令说明

2.2 指令

指令名称: upstream

指令名称: ip_hash

指令名称: server

2.3 upstream相关变量

变量名：$upstream_addr

变量名：$upstream_cache_status

变量名：$upstream_status

变量名：$upstream_response_time

变量名：HEADER

3. 参数配置及测试

3.2 proxy_next_upstream

3.3 nginx 与后端web连接时间的三个参数

4. 参考

猜你喜欢

热点阅读

变量名： $upstream_http_$ HEADER