当后端失败时,Haproxy粘滞会话不会redirect到不同的服务器

我有我的haproxy LB的以下configuration:

global daemon maxconn 2048 # SSL ca-base /etc/ssl/certs crt-base /etc/ssl/private ssl-default-bind-ciphers ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM; defaults log global mode http option forwardfor # handle incoming requests to port 80 (http) frontend www-http bind 1.2.3.4:80 reqadd X-Forwarded-Proto:\ http default_backend www-backend # handle incoming requests to port 443 (https) frontend www-https bind 1.2.3.4:443 ssl crt /etc/ssl/private/example.com.pem reqadd X-Forwarded-Proto:\ https default_backend www-backend backend www-backend # always use https redirect scheme https if !{ ssl_fc } # RR algorithm for load balancing balance roundrobin option httpclose # tracke which backend served specific user cookie _rails_srv insert # sticky sessions appsession _rails_session len 64 timeout 24h server s1 4.5.6.7:80 check cookie s1 server s2 7.8.9.0:80 check cookie s2 

它绑定到后端的2个Rails应用程序服务器,并且我使用Rails( _rails_session )提供的会话cookie来处理会话粘性。

它工作得很好,直到其中一台服务器出现故障,然后那些正在试图访问该服务器的失败服务器的现有会话的客户端将获得500个服务器错误响应,而不是被redirect到另一个正在运行的后端。

我认为Haproxy会在检测到故障时自动将stream量redirect到其他服务器。 我在configuration中做错了什么? 谢谢。

显然,你缺lessredispatch选项。

从文档 :

选项redispatch / no option redispatch:在连接失败的情况下启用或禁用会话重新分配

在HTTP模式下,如果一个cookie指定的服务器closures,客户端肯定会坚持下去,因为他们无法刷新cookie,所以他们将不能再访问服务。

指定“选项redispatch”将允许代理破坏其持久性并将其重新分发到工作的服务器。