• Hammer_T
    2019-01-22
    老师,如果用淘宝的 tengine 的 ngx_http_upstream_check_module 模块,他的默认规则是 check interval=3000 rise=2 fall=5 timeout=1000 type=tcp,也就是 每3秒钟检查一次,累计5次失败,就标记服务器为 down 剔除节点。我想问这种情况下,如果一个上游服务器出了问题,在把有问题的节点标记为 down 之前,是不是还是有 15s 的报错,

    作者回复: 这个模块我没有用过,不清楚它是否屏蔽了next_upstream指令,Nginx官方提供的next_upstream指令是可以在一台server出错时,及时的转换到下一个server返回,使客户端能够得到正确响应的。

    
     3
  • Jetson
    2019-01-08
    测试了一把,需要在upstream 中的每一条后端记录上添加这个指标 max_fails=1 fail_timeout=60s。然后可以实现异常后自动将其摘除60s。

    可以实现自动检测的 貌似可以用淘宝的模块nginx_upstream_check_module-master 实现

    作者回复: 淘宝的模块可以定期通过心跳检查上游,与本节课介绍方式不太一样:-)

    
     1
  • Jetson
    2019-01-08
    nginx 默认的proxy_next_upstream 应该是配置了error和timeout,max_fails=1 fail_timeout=10s。这样如果后端的设备不是全部故障的话,应该不会出现异常的页面吧。

    但是我这里使用了缓存后,就不会自动切换了,不知为何,配置如下。
    proxy_cache_path /home/yum_cache/ levels=1:2 keys_zone=cache1:1024m inactive=1d max_size=30g;

    upstream "yumproxy" {
         server 192.168.1.10:80;
         server 192.168.2.10:80 backup;
    }

    location ~ \.(php|xml)$ {
       proxy_set_header Host $host;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_pass http://yumproxy;
       proxy_cache cache1;
       proxy_cache_key $host$uri$is_args$args;
       access_log logs/cache.log main;
       proxy_cache_valid 200 304 301 302 1m;
       #在此指定时间过期后,会主动去源服务器更新数据信息
       proxy_cache_valid any 0s;
    }

    location / {
         proxy_pass http://yumproxy;
    }

    根据这个配置,如果主节点异常了,理论上backup的节点应该会被直接访问到,但是当我把主节点停掉的时候,再访问这个缓存节点的时候,就会出现502的错误。


    展开

    作者回复: 你用的是哪个版本的Nginx?我根据你的配置,在我的服务器上修改后,发现主节点异常后仍然正常跳到backup节点,没有收到502。
    我用的是最新的Nginx版本。

    
     1
  • 最纯净的感动
    2019-11-10
    老师你好,如果配置了ngx_http_upstream_module模块的upstream,nginx请求到后端rs集群不可用的节点时,请求就会被转发到下一正常节点,还需要配置 ngx_http_proxy_module模块的proxy_next_upstream指令吗?这两者的功能有什么区别呢?

    作者回复: 其实upstream默认自带next_upstream功能,各反向代理模块使用了它,并通过proxy_next_upstream这样的指令暴露出来了。
    所以,proxy_next_upstream 的默认配置很重要,例如:Default:     proxy_next_upstream error timeout; 你可以看到,它默认是开启的。

    
    
  • 深海极光
    2019-07-24
    老师还请教下,我用淘宝的tengine 测试在默认情况下出现一次超时,nginx认为服务不可用,我把不可用时间修改为1分钟,在这一分钟内,健康检查是3秒一次,成功的阀值为1,但是在一分钟内该机器还是不可用,没有看到流量进来,只有过了一分钟在有流量过来,我想问老师的是,这个healthcheck和nginx自身的容灾是独立的吗?谢谢
    
    
  • 深海极光
    2019-06-28
    老师请问下,nginx upstream server不可用是由不成功的请求次数max_fails(默认是1)即1次就不可用,不可用的时间是fail_timeout(默认是10秒)参数决定的,但是什么情况下算不成功的请求呢,官方文档说是proxy_next_upstream 来决定的,proxy_next_upstream 定义了这几种错误,error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 ,默认是error | timeout,即请求出现这两种情况时认为是不成功的请求,则找next server,如next server也不可用,那应该找backup了,但是如果proxy_next_upstream 配为off,是不是next server都不找了,直接到backup了,老师我这样理解对不,谢谢
    展开

    作者回复: 不是,off后backup也不会找,请求失败

    
    
  • 深海极光
    2019-06-16
    老师请问下nginx链接后端服务出现110 链接超时,有什么方法可以排查补,后端服务正常,但nginx不定期出现链接超时,链接超时时间都改为90秒了,超时的包也不好抓到,请问老师还有什么好办法不。谢谢了

    作者回复: 抓包从网络上找下原因吧。用tcpdump抓包,在wireshark在分析,基于会话和图标,基于相对时间,很容易看出到底是握手时缺了哪一个报文。可以参考我的《Web协议详解与抓包实战》第37课。

    
    
  • aoozoo
    2019-03-23
    测试环境和生产环境Nginx版本都为1.14
    
    
  • aoozoo
    2019-03-23
    老师,我今天遇到一个问题,我们生产环境的Nginx,upstream里面配置了两个上游服务,当其中一个上游服务,被stop之后,此上游服务器已经没有侦听此端口了,Nginx依然将请求转发至此故障节点,并直接给客户端响应502,而且是没两个请求,就有一个请求502.

    我特意测试过,在我搭建的测试环境,不对nginx做任何显示配置的情况下,nginx也会自动将请求转发至下一个后端节点处理,而不会返回502,这是nginx默认对reset错误的处理方法,我比对了生产的配置,并拿到测试环境测试,并不能在测试环境重现问题。

    生产的问题还没有得到解决,不知道老师是否能提供意见建议?
    展开

    作者回复: 似乎是proxy next upstream没有配对?

    
    
  • 一路向西
    2019-01-30
    陶老师,如果后端服务器出现问题,但是后来又恢复正常了,请求通过轮询还会再打到这台机器吗?这个检查后端机器的策略是什么呢?

    作者回复: 你配置了fail_timeout吗?认为上游服务不可用后,在fail_timeout秒内都不会再访问,fail_timeout秒后继续原策略。fail_timeout默认是10秒。

    
    
  • Panda
    2019-01-29
    应该是 proxy_next_upstream
    
    
  • Panda
    2019-01-29
    我们现在的生产环境架构就是多机的NGINX集群 next_proxy_upstream 很适合做对上游服务器的容错 让用户体验更好👍🏻
    
    
我们在线,来聊聊吧