the data in the primary site's EVA is not consistent and is not usable until the full copy (resynchronization) completes.
It is recommended to wait until the resynchronization is complete before failing back the packages to the primary site. The state of the DR group in the primary site’s EVA can be checked either via Command View (CV) EVA or SSSU command. If the state of each Vdisk in the DR group is shown “Normal”, then the resynchronization is complete, and the user can move the packages back to the primary site.
Scenario 2
The primary site HP StorageWorks EVA disk array experienced a catastrophic hardware failure and all data was lost on the array.
Failback to the Primary Site
In this scenario the disk array is repaired or a new EVA array is commissioned at the primary site. Before the application can fail back to the primary site, the EVA in the recovery site (now is the source storage) needs to establish the replication relationship with the new EVA in the primary site (now is the destination storage). Refer to the procedure named “Return Operations to Replaced New Storage Hardware” in the “Continuous Access EVA Operation Guide” to rebuild the DR groups configured in the EVA. Once the DR groups
Scenario 3
The primary site has lost power, which only impact the systems in the source disk site. The source disk site is down but the EVA disk array and Continuous Access links to the recovery site are up and running.
Failback in Scenario 3
In this scenario the EVA disk arrays in both sites are up and running. The Continuous Access links are functional. When the recovery packages are up and running on the recovery site, Continuous Access EVA automatically switches the replication direction; the new data written on the recovery site's EVA is replicated to the primary site's EVA.
After the source disk site is back online, the packages can be failed back to the primary site.
Reconfiguring Recovery Group Site Identities in Continentalclusters after a Recovery
In a disaster scenario where the primary site goes out of operation, and there was no loss of data on the disk array or the servers. After the recovery is completed the recovered application can continue to run at the recovery site without requiring to fail back when the source disk site becomes available at a later point in time.
This will avoid further downtime for the recovered application. But it will also be desired to have the same level of recovery capabilities for the applications in their new site, as they had in their original primary site.
As described in the above scenario, Continentalclusters can be reconfigured to provide monitoring and recovery for the application now running on its target disk site. This is done by switching the identities of the sites in the applications context. (that is, the old (or original) primary site will become the recovery site and the old (or original) recovery site will become the primary site. This type of reconfiguration for Continentalclusters is possible only in a two cluster and two site configuration.
Continentalclusters solutions using HP StorageWorks EVA disk arrays will need no disk array replication related tasks during the reconfigurations. Once the primary site EVA Disk array comes back online, the HP StorageWorks EVA Continuous Access will automatically resynchronize the data making the recovery site as “source” and the old primary site as “destination”.
Completing and Running Continentalclusters Solution with Continuous Access EVA 253