【问题标题】:HAproxy 1.5.8 How do I configure Cookie based stickiness?HAproxy 1.5.8 如何配置基于 Cookie 的粘性?
【发布时间】:2014-11-23 21:25:48
【问题描述】:

我们的应用程序需要基于 cookie 的粘性会话,因此我们希望使用 HAproxy 来平衡传入 IIS 服务器场的流量。

我们正在使用以下配置,该配置似乎在实验室工作(循环工作正常并保留会话),但在超过 3k 并发用户的生产中应用时失败:

前端 Front_http

bind :80
mode http
default_backend backend_http
stats enable
capture cookie ASP.NET_SessionId len 32
maxconn 10000

前端 Front_https

mode http
default_backend backend_https
bind *:443 ssl crt /etc/haproxy/cert.pem 
capture cookie ASP.NET_SessionId len 32
maxconn 10000

后端 backend_http

 balance roundrobin
 option forwardfor
 stick-table type ip size 20k expire 5m
 appsession ASP.NET_SessionId len 64 timeout 5m request-learn prefix
 server Server_1 192.168.10.81:80 cookie Server_1
 server Server_2 192.168.10.81:80 cookie Server_2
 server Server_3 192.168.10.81:80 cookie Server_3

后端 backend_https

 balance roundrobin
 option forwardfor
 stick-table type ip size 20k expire 5m
 appsession ASP.NET_SessionId len 64 timeout 5m request-learn prefix
 server Server_1 192.168.10.81:80 cookie Server_1 ssl verify none
 server Server_2 192.168.10.81:80 cookie Server_2 ssl verify none
 server Server_3 192.168.10.81:80 cookie Server_3 ssl verify none
 http-request set-header X-Forwarded-Port %[dst_port]
 http-request add-header X-Forwarded-Proto https if { ssl_fc }

从 HAProxy 1.5.8 文档中,我了解到基于 cookie 的粘性是通过命令“appsession”实现的,但我不了解其他命令所扮演的角色,例如“capture cookie”或“stick-table”,它们是否必要使用appsession时根本没有?任何人都可以帮助我了解它们的工作原理,并在您发现我们的配置有任何问题时提出建议。

【问题讨论】:

    标签: cookies sticky


    【解决方案1】:

    首先,您能否解释一下您当前的配置“不起作用”或您面临哪些问题?

    您当前的配置存在一些问题: - appsession 粘性不抵抗重新加载。这意味着每次重新加载 HAProxy 后都会失去粘性 - 您的 SSL 后端可能有错字,因为您将 SSL 流量转发到端口 80,这与您用于清除 HTTP 的端口相同。

    HAProxy 允许通过多种方式进行基于 cookie 的持久性。

    • cookie 插入:HAProxy 为自己设置一个 cookie:

      backend mybk
        [...]
        cookie SERVERID insert indirect nocache
        [...]
        server s1 10.0.0.1:80 check cookie s1
        server s2 10.0.0.2:80 check cookie s2
      
    • cookie 前缀:HAProxy 使用现有的 cookie(通常是应用程序之一)并以服务器名称作为其值的前缀:

      backend mybk
        [...]
        cookie ASP.NET_SessionId prefix nocache
        [...]
        server s1 10.0.0.1:80 check cookie s1
        server s2 10.0.0.2:80 check cookie s2
      
    • stick table:HAProxy学习并使用应用程序cookie,无需修改:

      backend mybk
        [...]
        stick-table type string len 64 size 100k expire 15m
        stick store-response res.cookie(ASP.NET_SessionId)
        stick match req.cookie(ASP.NET_SessionId)
        [...]
        server s1 10.0.0.1:80 check 
        server s2 10.0.0.2:80 check
      

    注意:您应该使用 peers 部分来保持 2 个 HAProxy 之间的数据同步以及重新加载配置时 注意 2:expire 参数应与您的应用程序 cookie 超时匹配

    最后但并非最不重要的一点是,HAProxy 将在您的日志行中报告有关基于 cookie 的持久性的标志(了解带有 cookie 关键字的标志)。 这样,您将知道请求的状态(是否有 cookie、是否有效等...)以及 HAProxy 采取的操作(插入新 cookie 等...)

    您可以查看此博客页面以获取有关 HAProxy 的更多信息: http://blog.haproxy.com/2012/03/29/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/

    巴蒂斯特

    【讨论】:

    • 非常感谢您的完整解释。 “不工作”是指浏览速度缓慢,最终客户端收到 http 错误 504 和 500。我们监控了新启动会话的平衡,看起来很平衡,但是在某一点上,其中一个 IIS 似乎比其他 IIS 有更多的会话并停止响应,后来又出现了另一个 IIS。不过,我不得不说,我们的平台在 Azure 中,后来我们得知 Azure 出现严重中断可能会影响 IIS,所以也许这毕竟与 HAproxy 无关。
    • 我正在审查我的配置,因为根据您的解释,有些事情对我来说看起来很奇怪,我将坚持您建议的一种方法来实现粘性,并且仅在 Azure 问题出现时再次测试真的解决了。此外,由于这是在 Azure 中实现的,因此存在网络限制,无法实现高可用性拓扑。
    • 504 表示服务器响应速度太慢。 “超时服务器”是这里的关键。 500 是由您的应用程序服务器生成的,HAProxy 无法修复它们 :)
    • haproxy 1.7 它是 req.cook 和 res.cook 与示例中的 .cookie
    • 在 @ChrisDaMour 的 cmets 之后:在 HaProxy 1.5 上,它也是 .cook 而不是 .cookie
    猜你喜欢
    • 2015-05-12
    • 1970-01-01
    • 2014-06-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多