This is the option I've set in my backend pool:

option                  ssl-hello-chk HEAD /rmo/login.rmo HTTP/1.0

and the configuration is:

apache[proxy]:443 -> jboss:8080 and if that fails apache shows a service is not available site which is at least in the browser a 503 error.

On 31.10.2014 10:57, Willy Tarreau wrote:
On Fri, Oct 31, 2014 at 10:44:30AM +0100, Sebastian Fohler wrote:
Hi Willy,

thank you for answering.
The problem is that the standard health check right now checks the URI
/.../<filename>
But as soon as the jboss backend fails, I get a 503 error page, which
still is responding to the health check.

I don't get it, are you using "option httpchk" ? If so, there's no way
it will consider a 503 as a valid response, or this is a bug!

So the failover I configured does not trigger.
Eighter I must be able to check the jboss directly, with a sepearte
check line or I need the "monitor fail" condition to be set to "if 503
erropage is showing up"
Is that discription better for understanding that problem?

No because I still don't understand the relation with monitor here.
Monitor is for *another* component to check haproxy, not for haproxy
to test something else.

For example, let's say you have the following architecture :

        +----------------------+
        | router + sla monitor |
        +----------------------+
                  |
                  |
                  V
        +--------------------+
        |      haproxy       |
        +--------------------+
            |            |
            |            |
            V            V
        +-------+    +-------+
        | srv1  |    | srv2  |
        +-------+    +-------+

Above, haproxy would be configured with *health checks* to check that
the servers are OK. In your case it would likely be "option httpchk".
Then you can have a "monitor fail" line in haproxy's frontend with a
rule saying that if there is no more server available behind, it should
report an error. That way the upper router periodically checks haproxy's
monitor and decides to advertise the route depending on *haproxy's*
status. Thus as I said, the monitor rule is for the frontend while the
health checks are for the backend.

Hoping this helps,
Willy


Reply via email to