[CentOS] load balancer recommendations

Sun Jan 20 02:42:53 UTC 2013
Brian Mathis <brian.mathis+centos at betteradmin.com>

On Sat, Jan 19, 2013 at 3:35 PM, Boris Epstein <borepstein at gmail.com> wrote:
> Hello all,
>
> The question is not necessarily CentOS-specific - but there are lots of
> bright people on here, and - quite possibly - the final implementation will
> be on CentOS hence I figured I'd ask it here. Here is the situation.
>
> I need to configure a Linux-based network load balancer (NLB) solution. The
> idea is this. Let us say I have a public facing load balancer machine with
> an public IP of, say, 50.50.50.50. It is to receive the traffic (let's say,
> HTTP traffic) and then route it to two private HTTP servers, let's say,
> 192.168.10.10 and 192.168.10.11. It has to have persistence - i.e., be
> state- and session-aware. If for whatever reason one of the servers goes
> down the remaining pool shares all the traffic in some fashion (be it eound
> robin, saturation based, whatever).
>
> We have tried Vyatta ( http://vyatta.org/ ) and ZeroShell (
> http://www.zeroshell.org/ ) and both are very good but their NLB seems to
> be externally facing (i.e., you have several internet connections and are
> trying to divide your traffic between them). What we need is an "internally
> facing" one, if I may say so.
>
> Any advice on what may help us would be greatly appreciated.
>
> Thanks.
>
> Boris.


Add another vote for HAproxy.  It's excellent at what it does, as long
as it meets your requirements.  It's main purpose is to load balance
HTTP traffic, and it can maintain session using a cookie.  It will
monitor each server and remove it from rotation if it goes down.  It
also has methods to place servers into maintenance mode.

It doesn't really handle SSL (though they have been working on it for
newer versions), but that can be handled by using Apache or nginx as
the front-end termination point for SSL, and reverse proxy into
haproxy.

It also does generic TCP load balancing, but I don't use it so can't
comment on that.


❧ Brian Mathis