users@glassfish.java.net

Questions about clustering domains

From: Comerford, Sean <Sean.Comerford_at_espn.com>
Date: Tue, 20 Jul 2010 22:36:39 -0400

Glassfish team - so here at ESPN we’re using the clustering functionality built into GF 2.1 (and eagerly anticipating the arrival of 3.1 so we can get it along with all the EE 6 goodness... so pls keep up the hard work on that ;-).

All told, ESPN has dozens of distinct web apps and we run them in (literally) 100’s of distinct instances.

Currently only a handful of our most high traffic services have actually been migrated to Glassfish. So right now our DAS is only managing approximately 25-30 instances in 4 or 5 different clusters (and seems to be doing it just fine).

But the services we have migrated are working great and we are planning to eventually migrate ALL services once 3.1 is production ready.

As we plan, we have some questions around how to best handle such a large # of clusters (dozens) and instances (anywhere from 150-500+).

Questions:

 1. Is there a technical or even recommended limit to the # of both clusters and instances a DAS manages?
 2. If so, what is that limit(s) in 2.1 and what will it be in 3.1?
 3. Do the clustering features being used matter in the equation? That is to say: ESPN is only really using the DAS as a “configuration controller”. It manages and is the central repository for server configs (domain.xml), applications, container managed resources (i.e. JDBC config), stopping, starting, etc but we do NOT use any of the more sophisticated / intensive clustering features such as load balancing, session replication, etc. Given this, at one point should we worry our cluster is “too big”?
 4. Has there been any thought to making a DAS able to manage another DAS? That is if a single DAS could manage all our JDBC configs in a single place and propagate those to other DAS, that would serve as a workaround for any potential limitations to the # of instances a given DAS can handle.

Sorry for the verbosity of this email but any clarifications / pointers to doc would be highly beneficial.

And keep up the great work on 3.x :-)

--
Sean Comerford, Software Engineer
ESPN.com Site Architecture Group
Office: 860.766.6454    Cell: 860.329.5842