I have three back end servers load balanced using HAProxy.

When all 3 of those are up i see each servers Id (1,2,3) consecutively in the HTTPS response. IE 1,2,3,1,2,3. As expected.

However, if i take one back end server down i then only see one server id repeatedly.

I.e if I take server 1 down I then only see server id 2 (2,2,2,2...) when I should see server id's 2,3 (2,3,2,3,2,3.....)

I have tried both leastconn and round robin balancing and both exhibit the same behaviour

Why does HAProxy behave this way? How do I alter my HAProxy config to load balance across the remaining alive back end servers?

HA proxy version is 1.6.9. Server for HA proxy is ubuntu 14.04.

The HTTP being served is an API that returns some JSON over HTTPS. Its a restful API so there is no session persistence required or wanted.

The configuration for haproxy is below.

    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    maxconn 3072
    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private
    # Default ciphers to use on SSL-enabled listening sockets.
    # For more information, see ciphers(1SSL). This list is from:
    #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
    ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH$
    ssl-default-bind-options no-sslv3
    log     global
    mode    http
    option  httplog
    option  dontlognull
    option dontlog-normal
    option redispatch
    retries 3
    maxconn 3072
    timeout connect 5000
    timeout client  10000
    timeout server  10000

frontend apis-frontend
    bind x.x.x.x:443 ssl verify none crt /etc/haproxy/xxx
    mode http
    option forwardfor
    default_backend apis

backend apis
    balance leastconn
    mode http
    option httpchk GET /
    server 1 x.x.x.x:443 ssl verify none check
    server 2 x.x.x.x:443 ssl verify none check
    server 3 x.x.x.x:443 ssl verify none check

listen stats
    bind *:8181
    mode http
    stats enable
    stats uri /
    stats realm Haproxy\ Statistics
    stats auth xx

Edit: added stats.


edit: load balancing behaviour in different browsers

After a request to test from a different ip. I noticed the second ip load balanced as expected. I then tried from the first IP but using different browsers edge and firefox. Both edge and firefox load balance as expected.

However the original browser chrome still stick to one back end server. Even after closing all chrome windows and restarting chrome

  • can you show how the apis is configured into the backend – silviud Oct 1 '16 at 13:31
  • Do you mean the back-end haproxy config? That's there just scroll down. – Simon Hodkinson Oct 1 '16 at 14:34
  • yes - sorry . if you take one server down and you look at the stats page (append ;csv) what do you see ? normally for http I use rr as balance algo. – silviud Oct 1 '16 at 15:06
  • no problem! thank you for taking an interest. I have added the stats to the question. – Simon Hodkinson Oct 1 '16 at 15:35
  • I'm no haproxy expert. But when I look at the stats web page it looks like it thinks its load balancing to both the remaining servers. However it definitely isn't as I only see one server id. – Simon Hodkinson Oct 1 '16 at 15:37

After much further testing the behaviour indicated only appears when using Google's Chrome browser. Why chrome shows this behaviour is undetermined.

The observed behaviour was not a HAProxy issue.

This tested multiple times with other browsers and other clients. Final proof being live service for several hours.

The HAProxy config above has now been running for several hours and is fairly distributing traffic amongst the three servers. This is evidenced from our DB records which records server id. Over a period of several hours each server was assigned the same number of requests within +- 50 from circa 4,500 requests.

More importantly, given the original question, it also continues to distribute fairly in the event of failure of one of the servers, amongst the other two. Again evidenced by our DB records which record server id. When measured over 15 minutes a clear pattern of equally balanced server ids can be seen in our DB records.

A poignant reminder to design testing to pin point where an issue lies, before assuming the issue lies with the part(s) of the solution you don't know very well, yet.

Thank you for the many replies it took for that realisation to dawn.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.