The information provided here includes:
Cluster Administrative Domain will allow a cluster administrator to maintain a consistent opertational environment across the cluster or a subset of the cluster. A cluster node can only belong to a single administrative domain. Within this domain, the user can specify objects or attributes of the operational environment which will be maintained (replicated) synchronously across the nodes in the domain. Examples of objects/attributes which will be replicated in V5R4 (minimal set) include:
Any family resource group API may be called on any node in the cluster which has the System Automation Manager installed with a valid license key.
All family resource group APIs require:
Quorum. is a mechanism used to determine when functions are allowed. There are two types of quorum: configuration and operational.
Configuration quorum. determines when configuration changes can be done on a resource
Operational quorum. determines when operational changes (ie online and offline) can be done on a resource.
Resource Monitoring and Control (RMC). provides global access for configuring, monitoring and controlling resources in a cluster.
System Automation Manager (SAM). provides relationships management between cluster resource groups. SAM will manage the relationships of the cluster resource group by starting, stopping, switching and failing over them in the defined order.
RMC resource or resource. is a name for an instance created by a resource class
resource class. An abstract representation of a physical or logical entity which defines a set of attributes and provides a common set of operations. For example IBM.ClusterResourceGroupData is a class the represents a data cluster resource group. This concept is not equivalent to a C++ class.
There will be no authority checking to the cluster resource group when using the Family Resource Group APIs. The authority is managed by authorizing users to the resource classes as specified in each Family Resource Group API.
Document how Admin Domain and Fpad play together.
Talk about CRG quorum
When a partition is detected, each partition is designated as a primary or secondary partition for each family resource group defined in the cluster. The primary partition contains the node that has the current node role of primary. All other partitions are secondary. The primary partition may not be the same for all family resource groups. The restrictions for each API when in a partition state are:
Need to update based on operational and configuration quorum. SAMs primary and secondary partition are the same between these quorum. At least not yet. Operational quorum is based on CRGs and which node is the primary. Op quorum is based on resource in the rg. If all resources in rg have quorum the rg has quorum. COnf quorum is based on RM (on number of nodes in cluster etc...). This will have to change. When it does update this section to be correct.
By applying these restrictions, family resource groups can be resynchronized when the cluster is no longer partitioned. As nodes rejoin the cluster from a partitioned status, the version of the family resource group in the primary partition will be copied to nodes in a secondary partition.
The Integrated Operating Environments APIs are:
Top | Cluster APIs | APIs by category |