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!