If you can afford it, go with hardware load balancing. it's easier to setup and configure. it's also more reliable and robust. of course, you have to open up your wallet and let the money fall out.
if you really want sophisticated load balancing that allows you to schedule a server to go down, i would recomend Resonate. I've used them in the past and their product is solid. peter On 5/12/05, Will Hartung <[EMAIL PROTECTED]> wrote: > > From: "Harry Mantheakis" <[EMAIL PROTECTED]> > > Sent: Thursday, May 12, 2005 1:51 AM > > > What load balancing system would you recommend? (Is there some consensus, > > cost issues aside, as to what the best type of load balancing system is?) > > I wish I could say. > > We use a pair of redundant BigIP's from F5 (which are eleventy zillion > dollars), so, they're quite sophisticated. > > I know Cisco has some as well (which are probably eleventy and a half > zillion dollars). > > 3 common paths are to use Apache's mod_proxy, mod_jk, or the Tomcat balancer > app. > > I don't think any of them provide sticky sessions (though, obviously, the > Tomcat webapp could probably be reasonably modified to support that -- but I > don't know if anyone uses the Tomcat balancer in production). > > I don't think any of them let you easily bring down an individual server on > your own, though you might be able to reconfigure mod_proxy "on the fly" > with Apache and do a graceful restart after you've taken your "downed" > server out of the mix in the httpd.conf file. The children should finish > their requests normally and safely. > > The biggest problem with load balancing and such is that it opens up a HUGE > kettle of fish with regards to testing and such. > > For example, you'll get it all set up, type http://myhost/webapp/page.jsp > and it'll magically appear and then you'll go "Yea, but WHERE did it come > from"? > > We modified all of our JSPs, for example, to put the host of the server they > came from in an HTML comment. > > It really starts getting confusing. > > You should have a good set of web based tests for your application so that > you can be sure that it's still working the same when you add the new > servers. Then you can start testing things like yanking network cables from > your tomcat servers to see if failover happens (or not), and other effects, > and then decide if you're happy with it. You also can see if you perhaps > gained any capacity by splitting the tomcats (if you're app is DB bound, > then the bottleneck may be your DB server and the extra tomcat may not help > you at all, for example). > > But, either way, testing is the key here to make sure everything is working > as planned (and unplanned) since the new configuration is that much more > complicated than it was before. > > Regards, > > Will Hartung > ([EMAIL PROTECTED]) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
