Planned Migration from an Active-Active Data Center to the Remote DR Center

To implement DR testing, you can migrate services from an active-active data center to the remote DR center based on recovery plans.

Procedure

1. Perform pre-migration configurations.
   • When the protected objects are databases, pre-migration configurations can be performed in the following two modes.
     • Method one: Manually stop applications and delete mapping views.
       1. Manually stop the service system and database applications and uninstall disks on the production host.
       2. Delete LUN mappings (to application hosts at the production sites) from the storage array in the production center.
       3. Log in to eReplication at the DR site, click Resources, select the site and the storage device, and refresh the storage device status, to ensure that all LUN mappings are removed.
     • Method two: Edit planned migration procedures. Before the planned migration, applications on hosts are automatically stopped and mapping views are automatically deleted.
       1. Log in to eReplication at the DR site, and on the menu bar select On the menu bar, select Utilization > Data Restore.
       2. Select the recovery plan and click the Procedure tab.
       3. Click Edit.
       4. From the drop-down list, select Planned Migration.
       5. Click Stop production service and click Start the step.
       6. Click Apply.
   • When the type of protected objects is VMware VMs, perform the following configurations:
     • Without configuration, the VM IP address for the planned migration is the same as that in the production center. You can configure one for the planned migration on the Protected Object tab page of the recovery plan. For details, see Self-defining Startup Parameters for a Protected Object.

2. Perform planned migration.
   1. On the menu bar, select Utilization > Data Restore.
   2. Select the recovery plan used to perform the planned migration and click More > Planned Migration on the Operation list.
   3. Perform the planned migration based on protected objects.
      

      If Huawei UltraPath has been installed on the Linux-based DR host, ensure that I/O suspension time is not 0 and all virtual devices generated by UltraPath have corresponding physical devices. For details, see the OceanStor UltraPath for Linux xxx User Guide.

      • If the protected object type is Oracle,perform the following operations:
        1. Select DR Site.
        2. Select Available DR Hosts or Host Groups.
        

        • If the storage array used at the DR site is T series V2 or later, the to-be-recovered host selected by a user can belong to only one host group on the storage array, and the host group can belong to only one mapping view. Moreover, the storage LUN used by protected applications and its corresponding secondary remote replication LUNs must belong to one LUN group, and the LUN group must reside in the same mapping view as the host group. If the storage array version is T series V2R2, deselect Enable Inband Command to change the mapping view attribute after the mapping view is created.
        • If the storage array is T series V2R2 or later, or 18000 series, automatic host adding and storage mapping are provided. Ensure that the storage is connected to hosts' initiators properly. In this manner, the system can automatically create hosts, host groups, LUN groups, and mapping views on the storage. The creation principles are as follows:

          

        3. Click Planned Migration.
        4. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation.
        5. Click OK.
      • If the type of protected objects is VMware VM, perform the following steps:
        1. Select a recovery cluster.

           VMs will be recovered to the recovery cluster. Select DR Site, DR vCenter, and DR Cluster.

           

           Upon the first network recovery, you need to set the cluster information.

        2. Select a recovery network.

           The recovery network is used to access recovered VMs.

           

           • If Production Resource and DR Resource are not paired, select Production Resource and DR Resource, and click Add to the mapping view to pair them.
           • If Keep the mac unchange is selected, the system checks whether the MAC addresses of production VMs conflict with those of all VMs in the DR vCenter. If the MAC addresses do not conflict, the system retains the MAC addresses of the VMs in the DR vCenter. Otherwise, the recovery task fails.
           • If Keep the mac unchange is not selected and the mounted VM is stopped, the MAC address of the VM mounted to the vCenter remains unchanged.After the VM is started, vCenter automatically assigns a MAC address to the VM.
        3. Stop non-critical VMs when executing recovery.

           In the Available VMs list, select non-critical VMs to stop them to release computing resources.

        4. Click Planned Migration.
      • Stop services in the HyperMetro data center and migrate them to the remote DR center. Figure 2shows the state of data replication between storage arrays after the migration.
        Figure 2 Data replication after the planned migration
        

3. After the migration is complete, verify that applications are started and data is consistent in the DR center.

   After the planned migration is complete, check whether the applications and data are normal. If an application or data encounters an exception, contact Huawei technical support.

   • Note the following when checking the startup status of applications.
   • If the protection policies are based on applications, check whether the applications are started successfully and data can be read and written correctly.
   • If the protection policies are based on LUNs, log in to the application host in the DR center, scan for disks, and start applications. Then check whether the applications are started successfully and data can be read and written correctly.
     

     You can use self-developed scripts to scan for disks, start applications, and test applications.

   • You can check data consistency by viewing the last entry of data written to the production and DR centers. If the last entry of data written to the production and DR centers is the same, the data consistency is ensured.

4. Delete data after migration.

   If storage array-based remote replication DR is used, snapshots are created automatically on the storage array at the DR site to back up DR data during the planned migration. If snapshots are not automatically deleted after the planned migration is complete, manually delete them to release storage space.

   

   A snapshot name is a string of 31 characters named in the following format: DRdata_LUNID_YYYYMMDDHHMMSS_BAK, where YYYYMMDDHHMMSS is the backup time and LUNID may be the snapshot ID (a number ranging from 1 to 65535). This naming format enables you to quickly find the snapshots that you want to delete from the storage array at the DR site.

5. Check the environment before perform reprotection.
   • Databases:

     Ensure that underlying storage links, remote replication pairs, and consistency groups have been recovered.

   • VMware VMs:
     • Ensure that underlying storage links, remote replication pairs, and consistency groups have been recovered.
     • On the original production array, unmap the volumes corresponding to the applications to be restored.

6. Perform reprotection to protect services migrated to the remote DR center.

   After the planned migration is complete, the service system is working in the remote DR center and protected groups become Invalid. You must perform reprotection to recover the replication relationship between the remote DR center and the HyperMetro data center and synchronize data from the remote DR center to the HyperMetro data center.

   

   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, re-configuration of protection and recovery policies is recommended to ensure the continuity of DR services.

   1. On the menu bar, select Utilization > Data Restore.
   2. Select the recovery plan and click More > Reprotection on the Operation list.

      If the protected objects are VMware VMs and services are recovered through a planned migration, perform the following steps to clear redundant and incorrect data in the virtualization environment before and after the reprotection.

      1. If reprotection was performed, use vSphere Client to log in to vCenter at site B. Click Storage list, and click Rescan All of storage devices one by one, to ensure that no datastore exists on ESXi hosts. Otherwise, skip this step.
      2. On eReplication, perform reprotection.
      3. Log in to the in the vCenter server at site A using vSphere Client. In the Storage list, right-click storage devices and select Rescan All from the drop-down list one by one, to ensure that no residuals exist on ESXi hosts in the cluster where the migrated VMs reside.
      4. Return to eReplication, and update vCenter servers and storage resources of site A to obtain the latest VM environment information.
   3. Carefully read the content of 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 Data replication after the reprotection