2

I am running some tests on the "uri whole" load balancing algorithm on HAProxy. My OS is Ubuntu 16.04.2 LTS and my release is HA-Proxy version 1.7.7-1ppa1~xenial 2017/06/27.

EDIT: I am using Server-Sent-Events (SSE) for long running requests.

Here is my backend configuration:

backend Proxy
    mode http
    balance uri whole
    hash-type consistent
    http-reuse safe
    http-request set-header X-Forwarded-Port %[dst_port]
    http-request add-header X-Forwarded-Proto https if { ssl_fc }
    option  http-server-close
    option httpchk
    http-check expect ! rstatus ^503
    timeout tunnel 24h
    server xxxx 192.168.0.10:8080 check maxconn 2 maxqueue 1
    server yyyy 192.168.0.11:8080 check maxconn 2 maxqueue 1

This is what I observe:

1 - Request A is sent to one of these servers, depending the hash after the question mark and some other options. Let's say on server xxxx.

2 - Next request targetting the exact same URI will go on server xxxx with a maxconn at 2.

3 - The third will stays in queue.

4 - The fourth will not reach anything and I got a "503 Service Unavailable - No server is available to handle this request." from HAProxy. The only way to send requests to the other server is to mark server xxxx as "Down" or "Maintenance". Same thing without the "hash-type consistent" or with a "backup" option.

5 - All health checks are sent to the same server.

My questions regarding points 4 and 5:

  • I thought "uri whole" was a load balancing algorithm. Should the 4th request not be balanced on server yyyy if server xxxx is unavailable to handle it (I understand that the hash does not change)?

  • To bypass this behaviour, I tried to configure health check to tell HAProxy to mark "Down" a server answering a 503 code. It does not work... Am I missing something in my backend definition?

  • Even the health checks are stick to one server. That's not useful... Is there something I don't understand here?

My objective here is to balance the 4rth request (and ideally the 3rd) on the second server :)

Thank you for your help!

  • @Stefan Hi, as you guessed we are using long-running requests (SSE protocol). I'll add it in my question. Concerning the 503, I was suspecting that was the reason but I was not sure. Thank you! – Guillaume Sep 29 '17 at 13:29
0

It sounds like request 1 and 2 still have a connection open to the backend (long-running request?). Request 3 is queued (only 2 connections allowed), request 4 is dropped because you limited the queue to one request.

The backend is not down - there are still two connections open.

Marking a backend as down on 503 doesn't trigger because the 503 comes from haproxy, not the backend.

Sorry if that doesn't actually solve your problem, but maybe it helps you understand it better :)

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.