Hello!

I have a small question on 'idiomatic' haproxy configuration, when
serving multiple independent applications from
a a shared group of webservers and if I should define each
application/virtual directory as a dedicated backend or not.
I apologize if I'm missing something obvious from the documentation.

The story:  I'm doing a test deployment of HAProxy in front of a few
IIS applications running on a small cluster of webservers.
Each webserver hosts every application, so: haproxy -> [
webserver1(app1, app2, ...), webserver2(app1, app2, ...), ... ]
My first approach was to define the whole cluster as a single backend,
something like:
--
frontend haproxy_test 172.20.253.20:80
    default_backend  ws_test

backend ws_test
    option  httpchk HEAD /status-check
    server  www1 www1:80 check
    server  www2 www2:80 check
    ...
--

This approach, however, will not cause haproxy to remove individually
failed applications from the load balance set,
in the case where an application has failed but the server is otherwise OK.

I then decided to define a backend per application and conditionally
use that backend based on the URL, something like:
--
frontend haproxy_test 172.20.253.20:80
    default_backend  ws_test
        
    acl ws_service1            path_beg        -i /service1
    ...

    use_backend ws_service1 if ws_service1
    ....

backend ws_service1
    option httpchk HEAD /service1/status-check
    server www1 www1:80 check
    ...

backend ws_service2
    option httpchk HEAD /service2/status-check
    server www1 www1:80 check
    ...
--

Is the second approach the way to go?  This complicates the haproxy
config as the number of applications and servers grow, but,
as far as I understand, increases the reliability of the frontend by
not causing a single failed application to mark the entire frontend as
offline.
Would you rather make the /status-check of the root of the webserver
be responsible for checking the health of every sub-application?

Many, many thanks,

regards,
Sölvi Páll Á.

Reply via email to