[CentOS] Load balancing...

Tue Mar 8 20:41:28 UTC 2011
Brian Mathis <brian.mathis at gmail.com>

On Tue, Mar 8, 2011 at 3:26 PM, Iain Morris <iain.t.morris at gmail.com> wrote:
> On Mon, Mar 7, 2011 at 3:44 AM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>>
>> On Mon, Mar 7, 2011 at 1:36 AM, David Brian Chait <dchait at invenda.com>
>> wrote:
>> >
>> >> On Mon, Mar 7, 2011 at 4:40 AM, Tim Dunphy <bluethundr at gmail.com>
>> >> wrote:
>> >> however for my purpose open and free HAProxy remains best choice!!
>> >
>> >> +1 for HAProxy; excellent piece of software.
>> >
>> > It really depends on your needs, if you are building a production ops
>> > environment then the last thing that you would want would be an
>> > unsupported/home grown solution. You need to consider the potential risks
>> > involved in implementing a poorly understood / virtually unsupported
>> > solution that in all likelihood only you would understand vs. a standard
>> > solution with an SLA behind it and an upgrade path going forward.
>>
>> Or in implementing an expensive, single point of failure third party
>> device that requires a centralized control infrastructure. It can turn
>> out to be a *very* expensive single point of failure, easily screwed
>> up by a single upgrade or a single power supply issues or a failure to
>> do failover networking to that device properly.
>>
>> Round-robin DNS is also, unfortunately, often mishandled. People
>> mistake changing the ordering of listed A records for round-robin and,
>> to quote Wikipedia:
>>
>>      > There is no standard procedure for deciding which address will
>> be used by the requesting application.
>>
>> No such procedure. Zip, zero, nada, it's all client dependent. And if
>> one of the IP's is on the same VLAN as the requesting host, you're
>> *especially* likely to get all the traffic locked to that host, and
>> DNS caches when you disable an IP can take rather unpredictable
>> amounts of time to expire because every smart aleck downstream is
>> doing their own caching and passing it along.
>
>
> I'm surprised to see so many choosing HAProxy over LVS, which seems fairly
> integrated into Red Hat's offerings, with full documentation and rpms in
> CentOS and RHN.  I've set up LVS before for an internal java application and
> it seemed straightforward after understanding arptables, etc.  Is HAProxy
> worth considering as a better option for this scenario?
>
> Regards,
> -Iain


I believe my post outlined a lot of the issues.  LVS works at the
IP-level, and as a result it cannot do intelligent things based on the
content of the connections.  A layer7 load balancer has a much better
ability to handle real sticky sessions, and make all kinds of
intelligent decisions based on the content, like serving images from
one server while sending the dynamic app requests to another.

I had initially looked as LVS (Piranha) specifically for the reasons
you mentioned, but in the current Internet landscape it has challenges
that just cannot be overcome.  For us the big issue was a client who
was load-balancing outgoing requests over multiple Class A subnets,
which completely destroyed any ability for LVS to be able to support
sticky sessions.