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 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. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > -- -- - Iain Morris iain.t.morris at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20110308/613d8f0a/attachment-0005.html>