Forcing a Takeover on Systems That Use Sun StorageTek Availability Suite

You perform a takeover when applications need to be brought online on the secondary cluster regardless of whether the data is completely consistent between the primary volume and the secondary volume. The information in this section assumes that the protection group has been started.

The following steps occur after a takeover is initiated:

• If the former primary cluster, cluster-paris, can be reached and the protection group is not locked for notification handling or some other reason, the protection group is deactivated.

  For a reminder of which cluster is cluster-paris, see Example Sun Cluster Geographic Edition Cluster Configuration in Sun Cluster Geographic Edition System Administration Guide.

• Data volumes of the former primary cluster, cluster-paris, are taken over by the new primary cluster, cluster-newyork.

  ---

  Note –

  This data might not be consistent with the original primary volumes. Data replication from the new primary cluster, cluster-newyork, to the former primary cluster, cluster-paris, is stopped.

  ---

• The protection group is activated without data replication.

For details about the possible conditions of the primary and secondary cluster before and after takeover, see Appendix C, Takeover Postconditions, in Sun Cluster Geographic Edition System Administration Guide.

The following procedures describe the steps you must perform to force a takeover by a secondary cluster, and how to recover data afterward.

• How to Force Immediate Takeover of Sun StorageTek Availability Suite Services by a Secondary Cluster

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

How to Force Immediate Takeover of Sun StorageTek Availability Suite 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.

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 in Sun Cluster Geographic Edition System Administration Guide.

2. Initiate the takeover.

   # geopg takeover [-f] protectiongroupname

   -f

   Forces the command to perform the operation without your confirmation

   protectiongroupname

   Specifies the name of the protection group

Example 3–2 Forcing a Takeover by a Secondary Cluster

This example forces 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 in Sun Cluster Geographic Edition System Administration Guide.

phys-newyork-1# geopg takeover -f avspg

Next Steps

For information about the state of the primary and secondary clusters after a takeover, see Appendix C, Takeover Postconditions, in Sun Cluster Geographic Edition System Administration Guide.

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

When you run the geopg takeover command, 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 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 places them in 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 in 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 that is 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 completes 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 that are 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 when 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. Use 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 StorageTek Availability Suite 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 StorageTek Availability Suite Protection Group.