-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Leon,
Leon Rosenberg wrote: > On 3/7/07, Christopher Schultz <[EMAIL PROTECTED]> wrote: >> Load balancing pretty much always comes down to either: >> 1. A single point of failure (Apache httpd, BigIP, or whatever). > > Loadbalancers usually come in pairs :-) Er, you can buy a single load balancer off the shelf. One input port, many output ports (virtually, that is). It's not uncommon to see a single device acting as a load balancer. Load-balanced /resources/, on the other hand, generally come in multiples (otherwise, what's the point?). If you had a pair of load balancers, how would you pick which one handles the request? ... R-R DNS, anyone? >> It seems to me that the most robust deployment for a webapp is: >> >> Random request distribution + Apache httpd + lb'd Tomcat > > paired firewalls + paired loadbalancers + tomcat cluster. > Performs much better as the above :-) Try it out, give it a chance. But the request has to come from somewhere and go to a single device. If you have pairs of things, you have to divide the traffic, which brings me back to R-R DNS. Otherwise, you have a set of hardware that never gets used. There's always the possibility of redirecting to another machine name, such as "rack0.foo.com" versus "rack1.foo.com", each of which point to a particular piece of load-balancing hardware (or logical equivalent such as a firewall /in front/ of a load balancer). I'm not sure how your "better" layout is any different than mine, except that you've replaced Apache-httpd-based-load-balancing with what looks like appliance-based-load-balancing and put firewalls out front (which is logically insignificant). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF71gr9CaO5/Lv0PARAitgAJ49c8f9YTEclevh6P54J3dIJmUbhQCeJgnT kZglVgOgx96gJ6hogCbjPtw= =lHsr -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
