This section describes how to perform planned migration if data or applications at the production site need to be recovered from DR sites due to power failure, upgrade, or maintenance. During planned migration, the latest service data changes will be synchronized to DR sites. Ensure that the management and storage networks between sites are normal.
Prerequisites
- You have logged in to eReplication as a user with the DR management permission.
- The production site and DR site communicate with each other correctly. The management system and the DR environment at the DR site are working correctly.
- At least one recovery plan has been created in the system.
- In the geo-redundant DR solution, before performing planned migration in a DR Star network, log in to DeviceManager and ensure that the running status of the protected group on the DR Star network is Enabled.
- If information about storage devices, hosts, or VMs is modified at either production or DR site, manually refresh the information. For details, see Refreshing Resource Information.
- In the Oracle application, the database is disabled but the cluster is enabled by default on the eReplication Agent. If you need to disable the cluster, modify the configuration of disabling clusters. For details, see Changing the Configuration of Stopping the Oracle Cluster.
The following table describes the requirements for each protection type.
Protected Object
|
Requirement
|
Oracle/IBM DB2/Microsoft SQL Server/Microsoft Exchange Server/SAP HANA
|
- Databases on DR hosts must be the same as those on production hosts, including the instance names, database names, and storage paths in use.
- Applications running at the production site have been manually shut down and disks are offline. LUNs of the applications that need to be recovered have been unmapped from production storage arrays; you can also modify the execution steps in a recovery plan to enable the Stop production service step.
|
FusionCompute VM
|
- If the VM IP address for VM recovery is not configured, the IP address of the VM after planned migration is the same as that at the production end. If you want to configure a different IP address, configure one on the Protected Object tab page.
- If disks are added to or deleted from the protected VM, refresh the VM information and manually execute the protected group where the VM resides.
|
VMware VM
|
If the VM IP address for VM recovery is not configured, the IP address of the VM after planned migration is the same as that at the production end. If you want to configure a different IP address, configure one on the Protected Object tab page.
|
Context
If the VM where the production site resides is configured with an IP address and the VM where the DR site resides is not configured with an NIC after planned migration, the IP address of the VM where the DR site resides is described as follows:
If no DR test is performed before the planned migration, the migration has a higher rate to fail. A migration failure will interrupt DR services. For this reason, at least one recovery plan test must be executed successfully before the planned migration.
Planned migration cannot be performed for recovery plans that are based on snapshot or clone protection policy templates.
The planned migration duration depends on the service data to be migrated. The larger the data volume, the longer the planned migration duration.
In the geo-redundant DR solution, services can be migrated from the production center to the intra-city or remote DR center as planned.
Procedure
- On the menu bar, select Utilization > Data Restore.
- Select the remote recovery plan for which you want to perform planned migration. In the Operation area, choose More > Planned Migration.
- Perform planned migration based on protected object types.
If Huawei UltraPath has been installed on the Linux-based DR host, ensure that I/O suspension time is not 0, and virtual devices generated by UltraPath have corresponding physical devices. For more details, see the OceanStor UltraPath for Linux xxx User Guide.
- If the protected object type is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, FusionCompute VM, Microsoft Exchange Server, or SAP HANA, perform the following operations:
- If the protection type is database, applications running at the production site have been manually shut down and disks are offline. LUNs of the applications that need to be recovered have been unmapped from production storage arrays; you can also modify the execution steps in a recovery plan to enable the Stop production service step.
- Select DR Site.
- Choose Host (Group) > Available DR Hosts or Host Groups (This operation is optional when the protected object type is LUN).
- 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 V200R001C00, deselect Enable Inband Command to change the mapping view attribute after the mapping view is created.
- For flash storage 6.1.6 and later versions, automatic host adding and storage mapping are provided. Ensure that the storage is connected properly to host initiators. 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:

- If the protected object type is LUN and no DR host or host group is selected, you need to manually map the DR LUN to the DR host.
- Click Planned Migration.
- 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.
- Click OK.
- If the type of protected objects is VMware VM, perform the following operations:
- Select the cluster you want to recover.
VMs will be recovered in the recovery cluster. Select a DR Site, a DR vCenter, and a DR Cluster.
Upon the first test network selection, you need to set the cluster information.
- Select a recovery network.
The default recovery network is the network for resource mapping. If you want to change it, plan or select another network based on site requirements.
- If Production Resource and DR Resource are not paired, select Production Resource and DR Resource, and click Add to the mapping view for pairing.
- 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.
- Select non-critical VMs.
In the Available VMs list, select and shut down non-critical VMs to release computing resources.
- Click Planned Migration.
- Carefully read the contents of the Warning dialog box. Then click the check box next to the statement I have read and understand the consequences associated with performing this operation to confirm the information.
- Click OK.
- If the type of protected objects is FusionCompute VM, perform the following operations:
- Select the cluster you want to recover.
VMs will be recovered in the recovery cluster. You need to select a DR site.
- Select an available powered-on host.
If the host is powered on, it provides resources for the VM to be restored.
- Select non-critical VMs.
In the Available VMs list, select and shut down non-critical VMs to release computing resources.
- Click Planned Migration.
- Carefully read the contents of the Warning dialog box. Then click the check box next to the statement I have read and understand the consequences associated with performing this operation to confirm the information.
- Click OK.
- Wait until the migration progress reaches the step of Delete Production VM.
- Check application startup and data consistency in the DR center.
If the application or data is abnormal, click Run and then Stop. Contact Huawei technical support for subsequent processing.
- Note the following when checking application startup.
- 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 is the same, the data consistency is ensured.
- If the applications and data at the DR site are running properly, click Run.
- Carefully read the contents of the Warning dialog box. Then click the check box next to the statement I have read and understand the consequences associated with performing this operation to confirm the information.
- Click Continue to complete the subsequent operations.
After you click Continue, if the production VM fails to be deleted, you cannot pause the planned migration again.
- Wait until the migration is complete.
- If the protected object type is NAS file system, perform the following operations:
- Carefully read the contents of the Warning dialog box. Then click the check box next to the statement I have read and understand the consequences associated with performing this operation to confirm the information.
- Click OK.
Operation Result
After the planned migration starts, you can view the execution progress and result. If a planned migration recovery plan fails to be executed, locate the fault and execute it again.
Follow-up Procedure
If the DR technology in use is remote array replication, the system automatically creates snapshots on the storage array at the DR site during planned migration to back up DR data. 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 following naming 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.
After the planned migration is complete, services are running at the DR site. To switch services back to the original production site, perform the following steps:
- Perform Executing Reprotection.
Before service switchback, you need to perform this operation to implement reverse protection for services running at the DR site. Service data generated at the DR site is automatically replicated to the original production site based on a specified policy.
- Perform Testing a Recovery Plan.
After the reprotection is complete, service data is reversely replicated to the original production site. Before services are switched back to the original production site, a DR test must be performed to verify data availability to ensure the success rate of service switchback.
- Perform Clearing Test Data.
This step automatically deletes the test data generated during the DR test to ensure that the service switchback success rate is not affected by the test data generated during the DR test.
- Perform Planned Migration.
When services need to be switched back to the original production site, perform planned migration. Services are automatically migrated to the original production site.
- Perform Executing Reprotection.
Perform reprotection again to ensure that services switched back to the original production site can be recovered from the DR site when planned or unexpected events occur.
For a recovery plan whose protected object type is FusionCompute VM (non-OpenStack architecture), after the planned migration is successfully executed, you can export the configuration file to view the resource mapping information of FusionCompute VMs before and after the planned migration. To export the configuration file, perform the following steps:
- Select the recovery plan for which the planned migration is successfully performed and click the Protected Object tab.
- Click
Export to export the configuration file to the local host.
Copyright © Huawei Technologies Co., Ltd.