Planned Failback of Services in the Same-City DR Center

Prerequisites

• Planned migration and reprotection have been successfully performed for service systems according to a recovery plan.
• The production hosts are working properly and the service system in the original production center is in the standby state.
• If the information about storage devices, hosts, or VMs is modified at the production or DR site, manually refresh the information. For details, see Refreshing Resource Information.
• The datastore name cannot contain Chinese characters.

Context

Figure 1 shows the state of data replication between storage arrays before failback.

Procedure

• In the HyperMetro (SAN)+synchronous replication (SAN)+asynchronous replication (SAN) scenario, you can use eReplication to migrate back services The procedure is as follows:
  1. On eReplication in the same-city DR center, select a recovery plan used to perform a failback, test the recovery plan, and clear data generated during the test.

     Before services are migrated back, perform a DR test to verify data availability to ensure service failback success rate. After the test is complete, clear the test data generated from the DR test to prevent the test data from adversely affecting the service failback rate. For details, see DR Testing.

  2. On eReplication in the same-city DR center, select recovery plans to be switched back and perform a planned migration.

     Migrate services back to the active-active data center. After the migration, check data and clear test data. For details, see 1 to 4 in Planned Migration from an Active-Active Data Center to the Same-City DR Center.

     

     • When the protected object type is Oracle, select hosts or host groups in the original production center as recovery targets.
     • If the protected object type is VMware VM, select vCenter and clusters in the original production center as recovery targets.

       You can select Synchronize HyperMetro to enable HyperMetro synchronization.

     Figure 2 shows the state of data replication between storage arrays after the migration.

     Figure 2 Data replication after the migration

     

  3. On eReplication at the Same-city DR center, select the recovery plan and perform reprotection.

     After the planned migration is complete, application systems are working in HyperMetro data centers and protected groups become Invalid. To ensure that services migrated back to the original HyperMetro data centers can be recovered at the Same-city DR center after an event (planned or unplanned) happens, reprotection must be performed and the replication status from HyperMetro data centers to the Same-city DR center must be recovered to synchronize data generated at the HyperMetro data centers to the remote DR site and to ensure that services are protected. For details, see 5 to 6 in Performing Planned Service Migration from an HyperMetro Data Center to the Remote DR Center.

     Figure 3 shows the state of data replication between storage arrays after the reprotection.

     Figure 3 Data replication after the reprotection

     

  4. Ensure that communication among sites is normal.
     1. Log in to the storage array management software in active data center B, and ensure that the status of the HyperMetro pair between active data center B and active data center A is normal and that asynchronous replication links between active data center B and site C are normal.
     2. Log in to eReplication at active data center B, and ensure that status of HyperMetro (SAN)+synchronous replication (SAN)+asynchronous replication (SAN) protected groups is normal and the topology structure has been restored to the original networking status.