Recovery domain

Start of changeA recovery domain is a subset of cluster nodes that are grouped together in a cluster resource group (CRG) for a common purpose such as performing a recovery action or synchronizing events.End of change

A domain represents those nodes of the cluster from which cluster resource can be accessed. This subset of cluster nodes that is assigned to a particular cluster resource group either supports the primary point of access, secondary (backup) point of access, replicate point of access, or peer point of access.

The four types of roles a node can have in a recovery domain are:

Primary
The cluster node that is the primary point of access for the resilient cluster resource.
  • For a data CRG, the primary node contains the principle copy of a resource.
  • For an application CRG, the primary node is the system on which the application is currently running.
  • For a device CRG, the primary node is the current owner of the device resource.
    Note: Start of changeWhen using geographic mirroring, the nodes in the recovery domain of a device CRG require a site name and data port IP addresses. See Site name and data port IP addresses for details.End of change
  • Start of changeFor a peer CRG, the primary node is not supported.End of change

Start of changeIf the primary node for a CRG fails, or a manual switchover is initiated, then the primary point of access for that CRG is moved to the first backup nodeEnd of change

Backup
The cluster node that will take over the role of primary access if the present primary node fails or a manual switchover is initiated.
  • Start of changeFor a data CRG, this cluster node contains a copy of that resource which is kept current with replication.End of change
  • Start of changeFor a peer CRG, the backup node is not supported.End of change
Replicate
Start of changeA cluster node that has copies of cluster resources, but is unable to assume the role of primary or backup. Failover or switchover to a replicate node is not allowed. If you ever want a replicate node to become a primary, you must first change the role of the replicate node to that of a backup node.
  • For peer CRGs, nodes defined as replicate represent the inactive access point for cluster resources.
End of change
Start of changePeerEnd of change
Start of changeA cluster node which is not ordered and can be an active access point for cluster resources. When the CRG is started, all the nodes defined as peer will be an active access point.
  • For a peer CRG, the access point is controlled entirely by the management application and not the system. The peer role is only supported by the peer CRG.
End of change

Primary-backup model

For nodes that participate in a primary-backup model, each node in the recovery domain has a role with respect to the current operational environment of the cluster. This is called its current role in the recovery domain. As the cluster goes through operational changes such as nodes ending, nodes starting, and nodes failing, the node's current role is changed accordingly. Each node in the recovery domain also has a role with respect to the preferred or ideal cluster environment. This is called its preferred role in the recovery domain. The preferred role is a static definition that is initially set when the cluster resource group is created. As the cluster environment changes, this role is not changed. The preferred role is only changed when nodes are added or removed from the recovery domain, or when a node is removed from the cluster. You can also manually change the preferred roles.

Conceptually, you can view the recovery domain within a primary-backup model as follows:

Table 1. Node roles for primary-backup CRGs
Node Current role Preferred role
A Backup 1 Primary
B Backup 2 Backup 1
C Primary Backup 2
D Replicate Replicate

Start of changeIn this example, Nodes A, B, C, and D provide an example of a CRG that is a primary-backup model. Node C is serving as the current primary node. Because it has a preferred role of the second backup, Node C's current role as primary results from two failover or switchover actions. Upon the first failover or switchover action, the primary role moved from Node A to Node B since Node B is defined as the first backup. The second failover or switchover triggered Node C to become the primary node since it is defined as the second backup node. Node D current and preferred role is that of replicate. A replicate node cannot be the assume the point of access during a failover or switchover unless its role is changed manually to either primary or backup.End of change

Note: The role of each node in the recovery domain can also be changed manually. The example illustrates how the roles in the recovery domain change when switchover or failover actions occur and no manual changes are made to the designation of the roles in the recovery domain.

Peer model

Start of changeFor peer model, a node within a cluster resource groups can have one of two roles: peer or replicate. End of change

Start of change
Table 2. Node roles for peer CRGs
Node Current role Preferred role
A Peer Peer
B Peer Peer
C Peer Peer
D Replicate Replicate
End of change

Start of change Nodes A, B, and C are defined in the recovery domain as peer nodes. When a failure occurs on Node A, it is communicated to all nodes in recovery domain regardless of current role. These nodes resumes the operation at the point when Node A failed. Node D contains the data, but cannot resume the operation since it is defined as Replicate.End of change

Any number of nodes can be designated as the peer or replicate. Peer nodes are not ordered and can become an active access point for the cluster resources. Replicates are not ordered and cannot become an active access point for the cluster resource unless the Change Cluster Resource Group (QcstChangeClusterResourceGroup) API is used to change its role from replicate to peer.

Related tasks
Change the recovery domain for a cluster resource group
Perform a switchover