我有以下负载平衡配置：
upstream upstream {
ip_hash;
keepalive 1000;
server 10.10.10.1;
server 10.10.10.2;
server 10.10.10.3;
}
server {
listen 443;
server_name example.com;
ssl_certificate /etc/nginx/certs/cert.crt;
ssl_certificate_key /etc/nginx/certs/cert.key;
ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
location / {
client_max_body_size 80m;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 90;
proxy_pass http://upstream;
}
}
虽然我的后端节点稳定,但一切正常.但是,当我关闭其中一个节点(例如10.10.10.2)时,NGINX将继续向其发送流量,即使请求保持超时(因为服务器已关闭).我已经尝试设置max_fails和fail_timeout参数,但行为仍然相同.
NGINX是否能够自动检测服务器是否已关闭而不是在那里发送流量？我错过了什么配置？
什么是keepalive？
keepalive背后的想法是解决在高延迟网络上建立TCP连接的延迟.建立TCP连接需要3次握手,因此,当客户端和服务器之间存在可感知的延迟时,keepalive会通过重用现有连接来大大加快速度.
为什么大家会把nginx放在他们的后端？
Nginx非常有效地处理成千上万的连接,而许多后端因此不会加快速度,人们经常将nginx放在他们真正的Web服务器前面以加快速度,因此云与用户之间的连接将是缓存keepalive以便后续重用.
请注意,根据http://nginx.org/r/keepalive,nginx甚至不支持上游keepalive,因为如上所述,如果你有亚毫秒的延迟,它更有可能使用更多的上游资源而不是加速任何处理.在所有主机之间(例如,在nginx和上游服务器之间).
你看到它的去向吗？
通过在LAN上使用过多的keepalive连接,每个上游服务器只需几百个连接,即使您没有像您所描述的那样遇到问题,也可能只会使速度变慢,而不是更快.
服务/端口关闭时会发生什么？
通常,当主机上的给定端口不可用时,主机立即返回TCP reset packet,known as RST,它立即告诉客户端(例如,nginx)发生了什么,让它立即采取适当的行动. (除了RST之外的分组也可以用于相同的效果,例如,当到主机的路由不可用时.)
If we stop the service on the backend,nginx handles it correctly. The issue only reproduces when stopping the entire VM. – Ramiro Berrelleza Oct 27 at 22:48
您的上述评论可能表明缺少及时连接拒绝的数据包肯定会混淆nginx – 您的设置似乎可能只是丢弃nginx发送的数据包.如果没有对请求做出任何回应,那么如何才能知道您的后端服务是否不可用,而不仅仅是展示企业级行为？
应该怎么做？
>首先,正如已经提到的,即使你没有遇到你描述的问题,你也可能只是通过在局域网上使用上游保持活动功能来减慢速度,特别是在这么高的情况下.
>否则,您可能需要配置您的设置(防火墙,路由器,虚拟化环境等)以返回适用于不可用主机的数据包,这肯定会使nginx按预期工作,因为您已经测试了TCP RST数据包时发生的情况,事实上,由主持人归来.
>另一种选择是调整nginx中的各种超时,以考虑上游消失而无踪迹的可能性,并补偿您的网络无法生成适当的控制数据包.
这可能包括connect(2)超时,用于建立新的TCP连接,通过http://nginx.org/r/proxy_connect_timeout在毫秒范围内(例如,如果您的所有服务器都在本地网络上,并且您没有运行具有企业级多秒延迟的企业级软件),以及正在进行的read(2)和send(2)操作的超时,分别通过http://nginx.org/r/proxy_read_timeout和http://nginx.org/r/proxy_send_timeout,这取决于后端应用程序应该响应请求的速度.您可能还希望在上游上下文中增加server指令的fail_timeout参数,如http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server所示.
