Designing Disaster Recovery Clusters using Metroclusters and Continentalclusters, Reprinted October 2011 (5900-1881)

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 re-build and the destination storage is
synchronized with the source storage, the packages can be failed back to the primary site.
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