Performing Planned Service Migration from an HyperMetro Data Center to the Remote DR Center

To implement a DR drill, migrate services from an HyperMetro data center to the remote DR center based on the recovery plan.

Prerequisites

Recovery plans have been created for protected groups.
Data has been tested and the data generated during tests has been cleared in the remote DR center.
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.
In a DR Star network, before performing planned migration, log in to DeviceManager and ensure that the running status of the DR Star network is Enabled.

Precautions

If the storage device is OceanStor Dorado V6 and the networking is HyperMetro (NAS) + asynchronous replication (NAS), and multiple protected groups share the same HyperMetro domain, after planned migration is performed for any protected group, planned migration cannot be performed for other protected groups.

Context

During a planned migration, services in an HyperMetro data center are migrated to the DR center by one click after the HyperMetro data center stops working. Then reprotection is performed for the services. Planned migration must be implemented if data or applications in the HyperMetro data center need to be migrated to the DR center due to non-disaster reasons such as power failure, upgrade, or maintenance. After the HyperMetro data center recovers, the services must be switched back to it.

You are advised to configure application-based protection policies for NAS File System to support one-click Planned Migration.
You are advised to configure LUN-based protection policies for other applications to enable automatic Planned Migration configuration on the storage system. You need to manually or use customized scripts to start and test the applications.
Figure 1 shows the state of data replication between storage arrays before the planned migration.
Figure 1 Data replication before the planned migration

Procedure

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.
    1. 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.
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.
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.
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.

In HyperMetro (NAS) and asynchronous replication (NAS) scenarios, the reprotection operation is not supported delete data after migration.

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.
Check the environment before perform reprotection.
- NAS file system:
  
  Ensure that underlying storage links and remote replication have been recovered.
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.
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.

Result

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

Figure 2 Data replication after the reprotection