V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
NGINX
NGINX Trac
3rd Party Modules
Security Advisories
CHANGES
OpenResty
ngx_lua
Tengine
在线学习资源
NGINX 开发从入门到精通
NGINX Modules
ngx_echo
kenshin912
V2EX  ›  NGINX

Nginx 负载均衡是否有时候会不起作用呢

  •  2
     
  •   kenshin912 · 2017-04-22 11:37:19 +08:00 · 8791 次点击
    这是一个创建于 2553 天前的主题,其中的信息可能已经有所发展或是发生改变。

    nginx.conf 配置如下:

    upstream A {
    server 10.x.x.x weight=3 max_fails=3 fail_timeout=0s;
    server 10.x.x.x max_fails=3 fail_timeout=0s;
    }
    

    上面一台称为 A1 服务器吧 , 配置较高 , 因此给了较高的权重 , A2 服务器配置较低 , 权重默认没动 .

    通过阿里云的监控发现 , A2 的 CPU 占用明显比 A1 高出不少 .

    我翻了 A1 和 A2 的 access_log 发现 , 某个请求到达 Nginx 后会一直分发到 A2 服务器 , A1 的 log 则一直没有该请求.

    但是也不是一直会这样 , 隔一段时间后 , A1 的 log 中再次发现有该请求过来 , 一段时间后再次消失.

    我好纳闷 , 这是什么鬼 ......

    有人知道这是为什么吗?谢谢啦.

    12 条回复    2017-04-24 13:33:08 +08:00
    ryd994
        1
    ryd994  
       2017-04-22 13:22:38 +08:00 via Android
    fail_timeout=0s
    这不太对吧……
    要关 fail 功能的话 max_fails=0

    不确定是否和问题有关
    kenshin912
        2
    kenshin912  
    OP
       2017-04-22 13:40:30 +08:00
    @ryd994
    fail_timeout=0s 应该是没问题的 , 我这边 nginx -t 一直是 OK 的 , 而且也用了这么长时间了 .

    现在唯一搞不懂的就是 , 为什么 A1 服务器上看 log , Nginx 并未将请求分发到 A1 而是全部分发到 A2 服务器了 .

    隔一段时间以后 , A1 的 log 中发现请求被 Nginx 分发过来了 , 持续一段时间后就没了 , 如此往复 .

    我在想是不是 Nginx 分发过来后 , A1 服务器是不是报了什么错误 , 导致 Nginx 认为 A1 有问题 , 进而将请求分发到 A2 服务器上. 隔一段时间后 , Nginx 再次尝试将请求分发到 A1 , 接着再报错再......

    可是奇怪的是 ,A1 和 A2 服务器的代码是一致的 , 唯一的区别是 A2 的 Apache 版本和 A1 不一致 , 并且开启了 HTTP2 .
    wtbhk
        3
    wtbhk  
       2017-04-22 14:48:02 +08:00
    @kenshin912 请求来源是同一个吗
    kenshin912
        4
    kenshin912  
    OP
       2017-04-22 15:24:08 +08:00
    @wtbhk
    是的 , 域名是 k.xxx.com , 解析到 Nginx 反向代理 , 反向代理分发到两台 Apache 服务器 .
    真的好奇怪啊...
    检查了配置文件 /usr/local/nginx/conf/vhost/xxx.conf

    server {
    listen 80;
    listen 443 ssl;
    server_name k.xxx.com
    ssl_certificate xxxxxxxxxxxxxxx.pem;
    ssl_certificate_key xxxxxxxxxxxxxx.key;
    access_log /xxxxx.log combined;
    location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    if ($remote_addr ~ "xx.xx.xx.xxx") {
    proxy_pass http://B;
    }
    proxy_pass http://A;
    }
    }
    upstream A 里面配置了 2 个服务器 , 真心没搞懂这是为什么.
    zhaohehedola
        5
    zhaohehedola  
       2017-04-22 15:27:53 +08:00
    会不会 A1 服务器 中间 挂掉 了一会?
    kenshin912
        6
    kenshin912  
    OP
       2017-04-22 15:34:04 +08:00
    @zhaohehedola
    这个倒没有 , A1 服务器一直很正常, 因为 log 里面还有其他的域名通过另一个反向代理请求进来 , log 也正常输出.
    反向代理 1 上的 log 如下:
    115.x.x.x - - [22/Apr/2017:13:31:26 +0800] "GET /xxxxxxxx.php?m=xxx&c=xxx&a=xxxxxxInfo HTTP/1.0" 200 43 "-"
    然后 A1 和 A2 两个服务器上的 log 应该都会有来自这个反向代理 1 的请求.
    实际上只有 A2 服务器上的 log 显示一直有该反向代理请求进来 , A1 服务器的 log 则是大部分时间没有来自该反向代理的请求.
    sagaxu
        7
    sagaxu  
       2017-04-22 15:42:22 +08:00   ❤️ 1
    交换 nginx 中 A1 和 A2 的配置,最简单就是把 nginx 配置中的 IP 互换,再观察一下效果
    kenshin912
        8
    kenshin912  
    OP
       2017-04-22 16:11:23 +08:00
    @sagaxu
    老哥稳 , 我对调了一下两个服务器的上下位置, tail -f 看了快 10 分钟的 log 了 , 竟然好了......
    这究竟是为啥呢 ......
    mazyi
        9
    mazyi  
       2017-04-22 16:15:22 +08:00 via iPhone   ❤️ 1
    @kenshin912 检查一下和两个 IP 的连通率
    kenshin912
        10
    kenshin912  
    OP
       2017-04-22 16:18:00 +08:00
    @mazyi
    走的是阿里云内网 IP , 一直都 OK 的 , 现在对调了下 upstream 里面两个应用服务器的上下位置, 竟然好了 , 真是无语 .
    也没搞懂为啥...
    ryd994
        11
    ryd994  
       2017-04-23 00:46:14 +08:00 via Android
    我也是觉得 Nginx 把 A1 fail 掉了,所以建议你先试试 max_fails=0
    kenshin912
        12
    kenshin912  
    OP
       2017-04-24 13:33:08 +08:00
    已经找到了原因 , 阿里云的安全设置中 , 防止 DDos 那里开启了每分钟 1500 个请求 , 超过就冻结 10 分钟...
    添加白名单后解决.
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1084 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 22:52 · PVG 06:52 · LAX 15:52 · JFK 18:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.