Planned Migration of Services in the Production Center

Prerequisites

• The production and DR centers communicate properly. The management system and the DR environment in the DR center are working properly.
• Recovery plans for services to be migrated have been created on eReplication, which have succeeded in at least one test.
  

  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.

• 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.
• Planned migration cannot be performed in an ADG environment where Broker has been configured.

Context

For Oracle, you are advised to configure application-based protection policies to support planned migration by one click.

Procedure

1. Perform the planned migration to migrate services from the production center to the DR center.
   1. On the menu bar, select Utilization > Data Restore.
   2. Select the recovery plan and click More > Planned Migration on the Operation list.
   3. Perform the planned migration based on different protected object types.
   • If the protected object type is Oracle, perform the following steps:
     1. Select DR Site.
     2. Select Host (Group) > Available DR Hosts or Host Groups (This operation is optional when the protected object type is LUN).
     3. Click Planned Migration.
        

        Before clicking Planned migration, you can click the Procedure tab, click Edit, select Planned migration, and enable or disable configurable steps as required. The procedure is as follows:

        • Create standby ADG snapshot (Configurable): This step is disabled by default.
        • Test database connection (Configurable): This step is enabled by default.
     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.

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

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

4. Check the environment before starting reprotection.

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

   

   If the reprotection fails, you can retry the reprotection from the failure point.

5. Perform reprotection to protect services switched to the DR center.

   After the planned migration is complete, the application system is working in the DR center and protected groups become Invalid. You must perform reprotection to recover the replication status and synchronize the data from the DR center to the production center. Then, the original DR center becomes the new production center.

   

   To ensure that the protection and restoration configurations before reprotection do not affect the running of the protected group and recovery plan after reprotection, the system automatically clears the protection and restoration configurations after reprotection. After performing reprotection, reconfigure the protection and recovery policies to ensure that DR services are running properly.

   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.
      • During reprotection after planned migration, BCManager proactively splits the synchronous replication pair from the standby database to the active database. In a scenario with a large number of replication pairs, after planned migration and reprotection are complete, reprotection takes a long time after another planned migration.

Operation Result

After the reprotection is complete, the protected groups become normal.