Ya know, I thought the HA guide would cover this relationship in one paragraph, but I don't see it with a quick perusal. Adding Paul to get his take on what we have or need.
On Mar 23, 2012, at 10:23 AM, Laird Nelson wrote:
> Hello; happy Friday. I'd like to know if there's an existing resource out there to help me better understand the relationships between domains, server instances, clusters, nodes and instances.
>
> I am working my way through the administration guide and the high-availability guide and the reference manual, and they are certainly helpful, but I was hoping for something a bit higher level to help my head get wrapped around the overall concept. Right now I'm finding that I have to kind of assemble all the raw materials together in my head myself.
>
> What I've gotten so far:
>
> A domain is a logical grouping--for configuration and auth purposes--of either standalone, shared or clustered server instances.
Yes, a "coarse-grained" means of scoping administration. Scoping auth is a good reason (different departments, for example).
> A server instance is an actual Glassfish program launched on a VM somewhere.
Yes, and it may or may not be running the DAS the way you describe it here.
> A server instance has exactly one domain associated with it.
Yes
> A server instance and a VM have a one-to-one relationship with each other.
I'm assuming you mean JVM. So yes, one JVM per instance. However, a virtual machine (virtualbox, vmware, etc) may run more than one instance, and those instances may belong to *different* domains.
> A domain has at least one server instance associated with it.
Yes, and that includes the DAS itself at a minimum.
> A domain has a DAS which is the special server instance where the domain's configuration is stored and manipulated.
I would say "managed" instead of manipulated, which sounds nefarious :-) As I mentioned, a domain may be just the DAS itself. If that is the case, it's either acting as the deployment target instance during development, or if your environment only needs one instance. In a multi-instance deployment (where the DAS manages multiple instances), I'd avoid deploying applications to the DAS instance itself.
> A cluster is a collection of server instances that are essentially interchangeable.
I'd re-phrase this. A cluster is a collection of instances that belong to a common domain, share a common configuration, are managed as one, and is a single target for deployment (all instances run the same set of applications). If you deploy an app to the cluster, all instances run that app. A cluster can also support session failover.
> A shared server instance is a server instance that shares a server configuration with another server instance. (But this is still overall managed by the DAS/domain, yes?)
I don't call them shared services instances, just "standalone" instances that share a common configuration. Make one change to the configuration and all instances inherit those changes (potentially requiring a restart). However, each instance is still it's own target, meaning each instances can run a different application. No session failover here since the instances are not clustered.
> A standalone server instance is a server instance that has its own server configuration. (But still managed by a DAS, right?)
Yes. But I look at a standalone instances as a deployment target, whether or not it has its own configuration or shares a configuration with other instances (as stated above).
> A clustered server instance is a server instance that belongs to a cluster.
Yes
> A node is another term for a host with Glassfish software on it. A node does NOT correlate one-to-one with a VM (you could have many VMs/server instances running on a node.
In GlassFish Server 3, it is a logical definition of a GlassFish installation on a presumably remote host. The DAS needs to know where GlassFish is installed on a remote host, so the DAS needs to know hostname (IP address), and installation path of GlassFish on that host. A node may be managed manually (CONFIG node), or centrally (SSH or DCOM nodes). Additional information related to security credentials is required for SSH/DCOM nodes.
>
> Please correct me where I've gotten things wrong. Any pointers to elsewhere are welcomed!
>
Hope this helps!
> Best,
> Laid
>
> --
> http://about.me/lairdnelson
>