I've been doing a great deal of research and experimentation on this, and I'm really running into a wall:
I'm trying to set up HAProxy as the reverse proxy for a high-availability environment. All traffic going into and out of this environment is SSL encrypted, so the original design was to have HAProxy do the SSL termination and pass the traffic into the enclave in the clear, and translate back the other way. So far, so good, there's lots of stellar documentation on that.
The problem is this: the sheer volume of traffic is too much for the single SSL terminating HAProxy box to handle, necessitating the need for more than one SSL terminating reverse proxy.
Okay I've looked high and low on this, and found many articles that seemed to be leading in the right direction, but always ended up with 1 primary HAProxy, and 1 backup, (e.g. all the heartbeat and keepalived solutions out there, such as here and here), or ignore SSL termination altogether, and talk about DNS round-robining to your load balancers.
So I guess what I was really looking for is the ability for more than one haproxy ssl terminating box to share the load simultaneously. Is there a way to do this outside of DNS round robins?
I guess I thought that there would be a way that they could share the same virtual ip address, and have traffic split among them simultaneously, all cluster-like. If one box goes down, then failover can be addressed with the above keepalived method, or something else. This appears to not be a common use case… is it even possible?
(There is, of course the issue of how to share SSL sessions between HAProxy processes, but if that's not possible, re-establishing a new session once in a while isn't a killer in this case.)
Thanks in advance!
Best Answer
Two haproxy instances can share load by using 2 virtual IPs with each instance the master for one of those. Round robin DNS roughly balances between the 2 virtual IPs (and consequently between the two haproxy instances). This method also works with SSL. One reason to think twice about this active-active setup though is if one instance can't cope with the total traffic alone then it will be overloaded if either instance goes down. Fundamentally that can only be solved by having spare 'wasted' capacity or accepting a temporary performance hit.
Alternatively you can stick an haproxy balancing in TCP mode infront of your SSL terminating proxies. One TCP session will stick to a backend so you don't need to worry too much about renegotiation.