Designing Disaster Tolerant High Availability Clusters, 10th Edition, March 2003 (B7660-90013)

Cascading Failover in a Continental Cluster
Data Replication Procedures
Chapter 8384
Scenario 1—Primary Site within the Primary Cluster Fails
When a failure occurs at the primary site, the hosts are down or the
whole site is down, the application package is automatically failover to
the secondary site within the primary cluster. Until the problems at the
primary site are fixed, and data replication is reestablished, there is no
data protection for the package at the secondary site. Depending on the
type of failure and how quickly the primary site is back online, data
refresh to the recovery site is still needed. This scenario is illustrated in
Figure 8-10.
Figure 8-10 Failure of Primary Site in Primary Cluster
Establishing Data Replication from the Secondary to the
Recovery Site After Failover to the Secondary Site
After failover, the application is running on secondary site and writing
I/O to R2 devices. The data is not remotely protected. The procedure to
refresh the data from the secondary Symmetrix to the recovery
Symmetrix is the same as the one that is done in steady state. But the
procedure is now running on a system in the secondary site; therefore,
the options on some of the SYMCLI commands are different.
1. Split the BCV devices in the recovery Symmetrix from the mirror
group. This is required to preserve an old copy of the data just in
case a failure occurs during data synchronization between the
secondary Symmetrix and the recovery Symmetrix that may cause
data corruption on the R2 devices in the recovery Symmetrix.
# symmir -f <recbcvdev_textfile> -sid <recsymid> split