Plan for a cluster administrative domain

Start of change The cluster administrative domain requires planning to manage resources that are shared among nodes within a cluster administrative domain. End of change

When you create a cluster administrative domain, a peer CRG is created automatically to represent that domain. You can manage a cluster administrative domain using APIs, CL commands and iSeries™ Navigator.

Start of change A cluster administrator can create a cluster administrative domain and then can add monitored resources that are shared among nodes. The i5/OS™ Cluster provides a list of system resources that can be shared among nodes within a cluster administrative domain, represented by monitored resource entries (MREs). See Monitored resources for a complete list of system resources that can be monitored. End of change

When designing a cluster administrative domain, you should answer the following questions:

What resources will be shared?: You will need to determine which system resources need to be shared. You can select attributes for each of these resources to customize what is shared amongst nodes. Applications that run on multiple nodes may need specific environment variables to run properly. In addition data that spans several nodes may also require certain user profiles to be accessed. You should be aware of the operational requirements for your applications and data before you determine what resources will be shared.
What nodes will be included in the cluster administrative domain?: You should determine what nodes in a cluster are to be managed by the cluster administrative domain. Nodes cannot be in multiple cluster administrative domains. For example, if you have four nodes in a cluster (Node A, Node B, Node C and Node D). Nodes A and B can be in one cluster administrative domain and Nodes C and D can be in another. However you cannot have Node B and C in another cluster administrative domain.
What will be the naming convention for cluster administrative domains?: Depending on the complexity and size of your clustered environment, you may want to establish a standard naming convention for peer CRGs and cluster administrative domains. Since a peer CRG is created to represent a cluster administrative domain, you will want to differentiate a peer CRG from those that are monitoring resources in your cluster. For example, peer CRGs that represent a cluster administrative domains can be named ADMDMN1, ADMDMN2, and so forth, while other peer CRGs can be named PEER1. You can also use the List Cluster Resource Group Information (QcstListClusterResourceGroupIn) API to determine whether the peer CRG is used as a cluster administrative domain.