Figure 5 - Failure of Primary Site in Primary Cluster

After failover, the application is running on secondary site and writing I/O to destination devices. The data is not remotely protected. The procedure to refresh the data from the secondary disk array to the recovery disk array is the same as the one that is done normally for refreshing the data on the recovery site. Follow the step in the previous section, “Refreshing data on the Recovery Site.”

Failback from the Secondary Site to the Primary Site

Once the problems at the primary site have been fixed, the application can fail back to the primary site, however, usually the current state of the replication group will not be in an automated state for Metrocluster. Therefore, a user needs to consult the specific data replication technology to restore the device back to a Metrocluster supported state. The following steps are required to move the package back to the primary site.

1.Set the primary replication group between primary disk array and secondary disk array into a “synchronized” state where the consistent data has been copied back to the source device and replication is enabled to copy data from source to destination.

2.Now, halt the application package:

#cmhaltpkg <package_name>

3.Split the local mirror (device B’) in the secondary disk array from the primary replication group to save a consistent copy of the data.

4.Start the application package on the primary site. Use the following command for all hosts in the primary cluster that may run this package:

#cmmodpkg -e -n <host_name> <package_name>

Then run the package with the following command:

# cmmodpkg -e <package_name>

The package will now start up on its primary host. Metrocluster will initialize a failback. The failback will synchronize the primary devices from the secondary devices. Until the synchronization is complete, the package application may run at a lower performance level.

5.Check the replication pair state between the primary disk array and the secondary disk array.

9