After active-active data centers recover from a fault, services will be migrated back to them.
Prerequisites
- Application-based protection policies and recovery plans have been configured for database applications or VMware vSphere on physical machines.
- LUN-based protection policies and recovery plans have been configured for other applications.
- For protected groups that use asynchronous remote replication, the DR center has at least one copy of intact service data.
- The datastore name cannot contain Chinese characters.
Context
Services are migrated from HyperMetro data centers to the DR center due to a recoverable fault such as an unexpected power failure. After the HyperMetro data centers recover from the fault, you must synchronize data generated during the DR from the DR center to the HyperMetro data centers and migrate services back to the HyperMetro data centers.
Figure 1 shows the state of data replication between storage arrays before failback.
Procedure
- In HyperMetro (SAN) and asynchronous replication (SAN) scenarios, you can use eReplication to migrate back services as follows:
- Check the environment before starting the reprotection.
- Log in to a service host in an HyperMetro data center and stop services.
- For databases: Manually stop applications in the production center and unmount host disks. Then log in to the storage array management software of the HyperMetro data centers, and remove mappings of LUNs used by applications from hosts.
- For VMware VMs: Use vSphere Client to connect to VMware vCenter in the production center. Power off protected VMs, remove them from the list, and uninstall datastores used by the VMs.
- Suspend HyperMetro pairs that are at active end of storage arrays in the HyperMetro data centers.
- Log in to a service host in an HyperMetro data center and stop services.
- Perform reprotection to protect services migrated to the remote DR center.
After the planned migration is complete, the application system is working at the remote DR site and protected groups become Invalid. You must perform reprotection to recover the replication status and synchronize data from the remote DR center to the HyperMetro data centers.
To ensure the normal running of protected groups and recovery plans after reprotection, the system automatically clears protected and recovered configurations, including startup configurations of protection policies and recovery plans, self-defined execution scripts, and self-defined execution steps. In addition, reconfiguration of protection and recovery policies is recommended to ensure the continuity of DR services.
- On the menu bar, select Utilization > Data Restore.
- Select the recovery plan and click More > Reprotection on the Operation list.
If the protected objects are VMware VMs and services are recovered from site A to site B, perform the following steps to clear redundant and incorrect data in the virutalization environment before and after the reprotection:
- Log in to the vCenter server at site A using vSphere Client.
- Close and migrate all VMs that are recovered to site B by recovery plan registration.
- On ESXi hosts in the cluster from which VMs are migrated, uninstall datastores used by the VMs one by one.
- For LUNs used by the uninstalled datastores, detach the LUNs from the datastores.
- Click Storage. All storage devices are displayed. In the row where each storage device resides, click Rescan All to ensure that no datastore exists on ESXi hosts.
- Return to eReplication, and refresh vCenter servers and storage resources on both sites to obtain the latest VM environment information.
- Perform reprotection.
- Carefully read the content in the Confirm dialog box that is displayed and click OK to confirm the information.
If Save user configuration data is selected, self-defined protection policies and recovery settings, such as self-defined recovery steps, will be retained. Ensure that the configuration data has no adverse impact on service running after reprotection.
Figure 3 shows the state of data replication between storage arrays after the reprotection.
- Test recovery plans and clear data generated during tests.
Before services are migrated back, perform a DR test to verify data availability to ensure service failback success rate. After the test, clear test data to avoid failback failures caused by the test data. For details, see DR Testing.
- Perform planned migration.
Migrate services back to the HyperMetro data centers. After the migration, check data and clear test data. For details, see 1 to 4 in Performing Planned Service Migration from an HyperMetro Data Center to the Remote 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 4 shows the state of data replication between storage arrays after the planned migration.
- Perform reprotection again.
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 remote DR center after an event (planned or unplanned) happens, reprotection must be performed and the replication status from HyperMetro data centers to the remote 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 see 5 to 6 in Performing Planned Service Migration from an HyperMetro Data Center to the Remote DR Center.
Figure 5shows the state of data replication between storage arrays after the reprotection.
- Check the environment before starting the reprotection.
----End