2

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!

1 Answer 1

3

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.

3
  • Thanks for the reply! Boxes aren't in short supply; I can add another couple nodes so the group has the capacity to handle a failure of a single node. I had thought about adding another HAProxy in front of the SSL terminators, but since the HTTP packet is encrypted at that point, there's no way to set a sticky session since it's in TCP mode, (at least, as far as I know - is there another way to do this)?
    – Decker
    Dec 11, 2014 at 19:36
  • Well, I guess there's static routing based on source ip but that seems like it may be worse in terms of asymmetrically loading the SSL terminators than DNS round robin would be, since people behind NATs would all appear to be the same person... thoughts?
    – Decker
    Dec 11, 2014 at 19:45
  • If you use client side keep alive the TCP session will stay open and to the same terminator.
    – JamesRyan
    Dec 11, 2014 at 21:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .