How to Force Immediate Takeover of Sun StorEdge Availability Suite 3.2.1 Services by a Secondary Cluster

Before You Begin

Before you force the secondary cluster to assume the activity of the primary cluster, ensure that the following conditions are met:

• Sun Cluster Geographic Edition software is up and running on the cluster.

• The cluster is a member of a partnership.

• The Configuration status of the protection group is OK on the secondary cluster.

Steps

1. Log in to a node in the secondary cluster.

   You must be assigned the Geo Management RBAC rights profile to complete this procedure. For more information about RBAC, see Sun Cluster Geographic Edition Software and RBAC.

2. Initiate the takeover.

   # geopg takeover [-f] protection-group-name

   -f

   Forces the command to perform the operation without your confirmation

   protection-group-name

   Specifies the name of the protection group

Example 8–2 Forcing a Takeover by a Secondary Cluster

The following example illustrates how to force the takeover of avspg by the secondary cluster cluster-newyork.

phys-newyork-1 is the first node of the secondary cluster. For a reminder of which node is phys-newyork-1, see Example Sun Cluster Geographic Edition Cluster Configuration.

phys-newyork-1# geopg takeover -f avspg

Actions Performed by the Sun Cluster Geographic Edition Software During a Takeover

When the geopg takeover command executes, the software confirms that the volume sets are in a Replicating or Logging state on the secondary cluster.

If the original primary cluster, cluster-paris, can be reached, the software performs the following actions:

• Removes affinities and resource dependencies between all of the application resource groups in the protection group and the internal resource group if the protection group was active

• Takes the application resource groups offline and put into an unmanaged state

• Unmounts the primary volumes that correspond to the device groups in the protection group

• Stops data replication by placing all volume sets into logging mode

• Reverses the role of all volume sets

On the original secondary cluster, cluster-newyork, the software performs the following actions:

• Places all volume sets into logging mode

• Reverses the role of all volume sets

• Runs the script specified in the RoleChange_ActionCmd property

• If the protection group was active on the original secondary cluster before the takeover, brings all application resource groups online and adds affinities and resource dependencies between the application resource group and the internal resource group

If the command executes successfully, the secondary cluster, cluster-newyork, becomes the new primary cluster for the protection group. Volume sets associated with a device group in the protection group have their role reversed according to the role of the protection group on the local cluster. If the protection group was active on the original secondary cluster before the takeover, the application resource groups are brought online on the new primary cluster. If the original primary cluster can be reached, it becomes the new secondary cluster of the protection group. Replication of all volume sets associated with the device groups of the protection group is stopped.

After a successful takeover, data replication is stopped. If you want to continue to suspend replication, specify the -n option any time you use the geopg start command. This option prevents the start of data replication from the new primary cluster to the new secondary cluster.

This command returns an error if any of the previous operations fails. Execute the geoadm status command to view the status of each component. For example, the Configuration status of the protection group might be set to Error, depending on the cause of the failure. The protection group might be activated or deactivated.

If the Configuration status of the protection group is set to Error, revalidate the protection group by using the procedures described in How to Validate a Sun StorEdge Availability Suite 3.2.1 Protection Group.

If the configuration of the protection group is not the same on each partner cluster, you need to resynchronize the configuration by using the procedures described in How to Resynchronize a Sun StorEdge Availability Suite 3.2.1 Protection Group.