No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OceanStor BCManager 6.5.0 eReplication User Guide 02

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Executing Reprotection

Executing Reprotection

If planned migration or fault recovery has been performed for a recovery plan, you can execute reprotection for the recovery plan. Reprotection protects data at the original disaster recovery (DR) site once devices at the original production site recover from disasters, simplifying failback.

Prerequisites

If reprotection needs to be performed after fault recovery, clear the environment of the original primary end and the recover replications of the original DR site switch to production site before performing other operations.

  • You have logged in to the eReplication as a user with DR management permission.
  • Planned migration or fault recovery has been performed for at least one recovery plan on eReplication.
  • Before performing reprotection, check whether protected groups at the original production site are in the Invalid state.
  • Before reprotection, underlying storage links, remote replications, and consistency groups have been recovered.
Demands in protection objects are described as following table.

Protection Object

Description

FusionSphere VM

  • The FusionManager, FusionCompute, storage devices, and Virtual Replication Gateways (VRGs) at the original production site are in the normal state, and the original production site and original DR site communicate with each correctly.
  • If execute reprotection after executing planned migration, in array-based replication for DR, the storage device configuration of the original production site and original DR site must be correct.
    • All underlying storage units corresponding to protected groups have remote replications.
    • All remote replications have secondary LUNs that belong to storage devices at the original production site.
    • If there are multiple remote replications, they must belong to a same consistency group.
  • If execute reprotection after executing fault recovery, in array-based replication for DR, ensure that:
    • Remove the primary LUNs from the original remote replication at the original production site.
    • Remote replications are deleted from the production storage.
    • If protected groups of the recovery plan are created in consistency groups, consistency groups at the DR end are deleted and re-created. Besides, remote replications at the original DR site are added to the newly created consistency groups and data is synchronized.
    • Add an available LUN to the remote replication on the storage at the original DR site. Ensure that a new LUN or a LUN moved from other remote replication must have been mapped to the host. For the primary LUN on the original remote replication, check whether the LUN has been mapped to the host. If it has been mapped to the host, delete the VM, disk and data storage from the LUN.
  • If add or delete the disk in the protected VM, refresh the VM and execute this protected group of protected VMs reside manually.

VMware VM

The protected VMs' name cannot contain #. Otherwise, modifying the VMs configuration file while executing reprotection will fail.

Context

In order to ensure the previous configuration does not effect the execution of protected group and recovery plan, the system will automatically clear protection and recovery configuration (includes the protected policy, startup setting for recovery plan, self-defined execution script and execution steps) . Please re-configure protected policy and recovery policy after you execute reprotection to ensure the normal operation of DR services.

  • If the recovery plan is based on the snapshot or clone protection policy template, reprotection cannot be performed.
  • Reprotection is not supported in the following scenarios:
    • In solution based asynchronous replication (VIS) do not support reprotection.
    • In solution based mirroring (VIS) and asynchronous replication (SAN) do not support reprotection.
    • In solutions based cascading replication (synchronous and asynchronous) or parallel replication (synchronous and asynchronous), services switched to the remote DR site do not support reprotection.
    • In solutions based on cascading replication (asynchronous and asynchronous), services switched to the remote DR site do not support reprotection.
    • In solutions based on active-active (VIS) and asynchronous replication (SAN), services switched to the remote DR site do not support reprotection.

Procedure

  1. If the protected object is a VMware VM, to prevent unnecessary or incorrect data in the virtualization environment before and after the reprotection, perform the following operations. If the protected object is not a VMware VM, go to 2.

    • If you have performed planned migration from site A to site B:
      1. Before reportection, if the reportection has been performed, log in to the vCenter server at site B from vSphere Client and perform Rescan All in Storage for all ESXi hosts in the clusters where VMs have been migrated to ensure that no datastore information is left on the ESXi hosts. Otherwise, you can ignore this step.
      2. Perform 2 to 4.
      3. Log in to the vCenter server at site A from vSphere Client. Perform Rescan All in Storage for all ESXi hosts in the clusters where VMs have been migrated to ensure that no datastore information is left on the ESXi hosts.
      4. Return to the eReplication system and refresh vCenter server and storage resources at site A to obtain the latest information about the virtualization environment.
    • If you have performed fault recovery from site A to site B:
      1. Log in to the vCenter server at site A from vSphere Client.
      2. Shut down and unregister all VMs that are restored to site B.
      3. Remove datastores used by the migrated VMs from the EXSi hosts in the cluster where the migrated VMs reside.
      4. Detach LUNs from the removed datastores.
      5. Perform Rescan All in Storage to ensure that no datastore information is left on the ESXi hosts.
      6. Return to the eReplication system and refresh vCenter server and storage resources at site A and site B to obtain the latest information about the virtualization environment.
      7. Perform 2 to 4.

  2. On the menu bar, select Utilization > Data Recovery.
  3. Select the remote recovery plan for which you want to execute reprotection and click More > Reprotection on the Operation list.
  4. In the Warning dialog box that is displayed, read the content of the dialog box carefully and click OK.

    NOTE:

    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

  • After the reprotection starts, you can view the execution process and result. If the task is failed, you can solve the problem and execute the task again.
  • After the reprotection, it protects data at the original DR site once devices at the original production site recover from disasters, the original DR site is production site.
Translation
Download
Updated: 2019-05-21

Document ID: EDOC1100075861

Views: 14130

Downloads: 70

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next