Determine primary and secondary cluster partitions

Start of change In order to determine the types of cluster resource group actions that you can take within a cluster partition, you need to know whether the partition is a primary or a secondary cluster partition. When a partition is detected, each partition is designated as a primary or secondary partition for each cluster resource group defined in the cluster. End of change

Start of change For primary-backup model, 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 cluster resource groups. End of change

A peer model has the following partition rules:

If the recovery domain nodes are fully contained within one partition, it will be the primary partition.
If the recovery domain nodes span a partition, there will be no primary partition. Both partitions will be secondary partitions.
If the cluster resource group is active and there are no peer nodes in the given partition, the cluster resource group will be ended in that partition.
Operational changes are allowed in a secondary partition as long as the restrictions for the operational changes are met.
No configuration changes are allowed in a secondary partition.

The restrictions for each Cluster Resource Group API are:

Table 1. Cluster Resource Group API Partition Restrictions
Cluster Resource Group API	Allowed in primary partition	Allowed in secondary partitions
Add Node to Recovery Domain	X
Add CRG Device Entry
Change Cluster Resource Group	X
Change CRG Device Entry	X	X
Create Cluster Resource Group
Delete Cluster Resource Group	X	X
Distribute Information	X	X
End Cluster Resource Group¹	X
Initiate Switchover	X
List Cluster Resource Groups	X	X
List Cluster Resource Group Information	X	X
Remove Node from Recovery Domain	X
Remove CRG Device Entry	X
Start Cluster Resource Group¹	X
Note: Allowed in all partitions for peer cluster resource groups, but only affects the partition running the API.

By applying these restrictions, cluster resource groups can be synchronized when the cluster is no longer partitioned. As nodes rejoin the cluster from a partitioned status, the version of the cluster resource group in the primary partition is copied to nodes from a secondary partition.

Start of change When merging two secondary partitions for peer model, the partition which has cluster resource group with status of Active will be declared the winner. If both partitions have the same status for cluster resource group, the partition which contains the first node listed in the cluster resource group recovery domain will be declared the winner. The version of the cluster resource group in the winning partition will be copied to nodes in another partition. End of change

When a partition is detected, the Add Cluster Node Entry, Adjust Cluster Version, and the Create Cluster API cannot be run in any of the partitions. The Add Device Domain Entry API can only be run if none of the nodes in the device domain are partitioned. All of the other Cluster Control APIs may be run in any partition. However, the action performed by the API takes affect only in the partition running the API.