这是我的conf:
upstream prod_example_com { server app-a-1:51000; server app-a-2:51000; server app-a-3:51000; } server { # link: http://wiki.Nginx.org/MailCoreModule#server_name server_name example.com www.example.com *.example.com; #----- # Upstream logic #----- set $upstream_type prod_example_com; #----- include include.d/common.conf; # Configure logging access_log /var/log/Nginx/example/access/access.log access; error_log /var/log/Nginx/example/error.log error; location / { # link: http://wiki.Nginx.org/HttpProxyModule#proxy_pass proxy_pass http://$upstream_type$request_uri; # link: http://wiki.Nginx.org/HttpProxyModule#proxy_set_header proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~* \.(js|css|png|jpg|jpeg|gif|ico)${ # link: http://wiki.Nginx.org/HttpProxyModule#proxy_pass proxy_pass http://$upstream_type$request_uri; # link: http://wiki.Nginx.org/HttpProxyModule#proxy_set_header 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_hide_header expires; proxy_hide_header Cache-Control # Even tho this reads like the older Syntax,it is handled internally by Nginx to set max age to now + 1 year expires max; # Allow intermediary caches the ability to cache the asset add_header Cache-Control "public"; } }
我已经尝试过像this这样的类似帖子的建议.显然我的Nginx版本太旧了,不支持Nginx docs中概述的health_checks.我也尝试在app上显式设置max_fails = 2和fail_timeout = 120- a-3上游定义,但如果app-a-3脱机,这些似乎都不能避免每个请求额外延迟5-7秒.
– 更新 –
根据请求,当app-a-3完全关闭时,这是针对单个请求的output.我能看到的与众不同的是初始事件和后续事件之间的3秒滞后.
– 更新#2 –
看起来几年前,Nginx决定创建Nginx Plus,它增加了积极的健康检查,但是每年支持合同.根据我读过的一些文章,Nginx厌倦了让公司赚到数百万美元,并且得不到任何回报.
正如评论中所提到的那样,我们正在引导并且不会让$$抛出1,350美元的合约.我确实找到了提供功能的repo.想知道是否有人有任何经验吗?稳定?高性能?
在最糟糕的情况下,我将不得不咬紧牙关并为Linode“节点平衡器”支付额外的20美元/月,我非常确定它是基于Nginx Plus.唯一的问题是除了一些通用选项之外没有对配置的控制,因此无法通过一个平衡器支持多个vhost文件,并且所有节点必须位于同一数据中心.
– 更新#3 –
这里有一些siege results.似乎第二个节点配置错误,因为它只能处理第一个和第三个节点正在处理的大约75%的请求.另外我觉得很奇怪,当我将第二个节点脱机时,性能就像我将第三个(性能更好)节点脱机一样糟糕.逻辑将决定如果我删除弱链接(第二个节点),我会获得更好的性能,因为剩下的两个节点分别比弱链路表现更好.
简而言之:
node 1,2,3 + my Nginx = 2037 requests node 1,2 + my Nginx = 733 requests node 1,3 + my Nginx = 639 requests (huh? these two perform better individually so together should be somewhere around ~1500 requests,based on 2000 requests when all nodes are up) node 1,3 + Linode Load Balancer = 790 requests node 1,3 + Linode Load Balancer = 1,988 requests
大多数负载平衡器具有轮询机制和/或心跳,用于抢先检查关闭服务器.您可能想要查看这些选项.轮询通常不会每分钟超过一次或两次对Web服务器运行,但是服务器关闭情况的心跳检查可能每隔一秒左右.
Nginx不是最复杂的负载平衡器.如果您遇到此类问题,可能需要查看其他选项.
编辑:这样的事可能吗? http://www.howtoforge.com/setting-up-a-high-availability-load-balancer-with-haproxy-heartbeat-on-debian-lenny对于小型安装,不需要单独的服务器,只需将其放在Web服务器盒上即可.这提供了负载平衡,但没有缓存.还有一些HA解决方案可以控制鱿鱼或清漆以响应心跳.