> 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?
The number will be different between GlassFish 2.1.1 and GlassFish 3.1.
For GlassFish 2.1.1, we tested on a T2000 and cap out at about 20 dual-node clusters with in-memory replication. That's 40 instances. The limit is not exact in that it depends on how long you are willing to wait for the DAS to start up, etc. However, we formally support what we've tested, and we've tested 40 instances.
> 2. If so, what is that limit(s) in 2.1 and what will
> it be in 3.1?
For GlassFish 3.1, we are increasing our testing to 100 instances across 10 10-node clusters.
> 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”?
HA vs non-HA clusters don't really matter in your case (although we will cap out at 10-node HA clusters). We're still engineering 3.1, so it's a bit premature to give any more information than I've already given - our target of 100 instances as described above.
> 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.
>
We've been thinking about how to manage large deployments more efficiently, but it won't be a feature in 3.1. There are technical and usability issues to address. We can consider approaches for later releases.
> Sorry for the verbosity of this email but any
> clarifications / pointers to doc would be highly
> beneficial.
>
Great topic, no problem!
> 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
> [att1.html]
John Clingan
GlassFish Principal Product Manager
[Message sent by forum member 'jclingan']
http://forums.java.net/jive/thread.jspa?messageID=478417