haproxy + CARP on FreeBSD

So you’ve decided you want a high availability cluster running on FreeBSD?

A common setup is to run haproxy + CARP together. The main drawback to this method that that it isn’t truly high availability. Here are some of the shortcomings of this approach:

  • You will need to upgrade the haproxy binary an awful lot, if your are doing SSL termination. You will need to fail-over the carp master when preforming maintenance on the host
    • What happens to existing in-flight requests?
    • Do you always have a service window?
  • If the haproxy process on the MASTER dies (or say isn’t accepting requests on a reload), those requests aren’t serviced
    • Additionally how does CARP know the status of the haproxy process? It doesn’t.
  • Only one haproxy instance is serving all of the requests at a time, so you aren’t really load balancing the requests

All of this stems from the fact that we are missing a layer of redundancy. We have redundancy at the physical layer with CARP. We have redundancy at the application (or transport) layer with haproxy.

What we need is redundancy at the network layer to complete the stack.

I am told you can solve this in linux with LVS, but currently (as far as I’m aware) there is no mechanism for this in the BSD world. Continue reading haproxy + CARP on FreeBSD