Community

To scope or not to scope (domain.xml)

reply from Brian Stansberry in Management Development - View the full discussion

Excellent question!  We need to agree on the definition of some terms.

 

To me a "domain" is a set of servers meant to be managed as a unit (acknowledgment: how things are "managed as a unit" is vague/fuzzy; a key task is to clarify exactly what that means.) The servers don't need to all have a homogenous profile, as people may wish to tier things. (In example above written for the clustering meeting the "DataGrid" profile was meant to describe a bunch of servers running Infinispan to serve as large scale grid storage behind a JEE tier.)

 

I see a domain as needing to allow multiple clusters, even ignoring the different tier idea. Mutliple clusters are a useful mechanism for a rolling upgrade; you subdivide your overall capacity into N smaller clusters, and then can upgrade those by taking a cluster at a time off line. This is needed instead of a rolling upgrade of 1 server at a time within the same cluster if the new version of the app can't co-exist with the old in the same cluster (e.g. incompatible state).

 

<domain>
   <profile name=”jee”>.... define a set of capabilities, configuration thereof</profile>

   <cluster name=”jee-1” mcast_addr=”234.5.6.7” default_stack=”udp” profile=”jee”/>

   <cluster name=”jee-2” mcast_addr=”235.6.7.8” default_stack=”udp” profile=”jee”/>

   <server name=”jee-1-1” bind_address=”192.168.0.100”>
       <cluster-ref name=”jee-1” cluster_address=”10.0.0.100”/>
   </server>

   <server name=”jee-1-2” bind_address=”192.168.0.101”>
      <cluster-ref name=”jee-1” cluster_address=”10.0.0.101”/>
   </server>

   <server name=”jee-2-1” bind_address=”192.168.0.102”>
       <cluster-ref name=”jee-2” cluster_address=”10.0.0.102”/>
   </server>

   <server name=”jee-2-1” bind_address=”192.168.0.103”>
      <cluster-ref name=”jee-2” cluster_address=”10.0.0.103”/>
   </server>

</domain>

 

Re: deployment, I don't see deploying to a domain. You'd deploy to a cluster, a server-group (if we end up with such a thing) or a standalone server.

 

The "profile" element I showed is problematic though, since if management actions are occuring against a cluster/server-group/standalone server, how are changes written back? Perhaps what I showed becomes a "proifile-template" and then the smaller groups declare a "profile" that extends the template.

Reply to this message by going to Community

Start a new discussion in Management Development at Community