Re: Load balancing...

[Iain Morris <iain.t.morris@xxxxxxxxx>]

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

On Mon, Mar 7, 2011 at 3:44 AM, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:

On Mon, Mar 7, 2011 at 1:36 AM, David Brian Chait <dchait@xxxxxxxxxxx> wrote:
>
>> On Mon, Mar 7, 2011 at 4:40 AM, Tim Dunphy <bluethundr@xxxxxxxxx> 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.

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

--
-- -
Iain Morris
iain.t.morris@xxxxxxxxx

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos