☰

似乎在 acl 匹配的后端和默认后端之间“随机”切换

tag-icon • tag-icon proxy load-balancing reverse-proxy haproxy socket
似乎在 acl 匹配的后端和默认后端之间“随机”切换

我有 HAProxy 作为代理：

  • NGinx 实例
  • 使用 socket.io（websockets）公开的多个动态服务前面的内部负载均衡器

我的问题是，有时我的连接正确地代理到我的 socket.io 集群，然后随机地回退到路由到 NGinx，这显然很烦人而且毫无意义，因为 NGinx 并不意味着处理该请求。

当请求以下格式的 URL 时会发生这种情况：

http://mydomain.com/backends/*

HAProxy 配置中有一个 ACL 与“/backends/*”路径匹配。

这是我的 HAProxy 配置的简化版本（删除了多余的不相关的条目并更改了名称）：

global
    daemon
    maxconn 4096
    user haproxy
    group haproxy
    nbproc 4 

defaults
    mode http
    timeout server 86400000
    timeout connect 5000
    log global


#this frontend interface receives the incoming http requests
frontend http-in
    mode http

    #process all requests made on port 80
    bind *:80

    #set a large timeout for websockets
    timeout client 86400000

    # Default Backend
    default_backend www_backend

    # Loadfire (socket cluster)
    acl is_loadfire_backends path_beg /backends
    use_backend loadfire_backend if is_loadfire_backends


# NGinx backend
backend www_backend
    server www_nginx localhost:12346 maxconn 1024


# Loadfire backend
backend loadfire_backend
    option forwardfor # This sets X-Forwarded-For
    option httpclose
    server loadfire localhost:7101 maxconn 2048

我真的很困惑为什么这种行为看起来是“随机的”，因为很难重现，也很难调试。

我很感激对此的任何见解。

答案1

问题是由于当多个 HTTP 请求通过同一个 TCP 连接传输时，第一个请求会经过 acl 匹配过程和上下文切换来获取后端，但对于后续连接则不会如此。

因此，为了解决这个问题，应该在前端部分执行以下操作之一：

option httpclose

或者

option http-server-close

以上方法对我有用（我选择后者，http-server-close）。

我发现这个文档条目非常有用： Google Docs 上有关 http-close-server 的 HAProxy 文档（其他条目也很有用）。

相关内容