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).
DR (Cascading and Parallel Networks)

DR (Cascading and Parallel Networks)

This section describes DR methods provided by the Geo-Redundant Solution in cascading and parallel networks.

Self-defining Execution Steps in a Recovery Plan

During DR, if you want to reset the DR network or stop some services at the DR site to release system resources for smooth service recovery, you can self-define the execution steps on eReplication. This operation can be performed only on eReplication of the DR site.

Prerequisites

You have logged in to the DR management server at the DR site.

Context

The management server provides the default recovery plan execution steps for different types of recovery, including testing, clearing, planned migration, fault recovery, and reprotection, to ensure correct recovery and switchover. The existing functions of eReplication cannot meet all service recovery requirements. For example, during DR, the DR network of the DR site must be reset or non-critical services must be stopped at the DR site to release the system resources to recover critical services. Therefore, eReplication allows you to modify the steps of a recovery plan.

Execution steps in a recovery plan are classified into two types, as described in Table 6-8.
Table 6-8  Recovery plan execution steps

Type

Description

Default execution steps

For default recovery plan execution steps, eReplication defines which steps can be selected and which steps can be modified and provides default configurations to meet basic recovery requirements. You can modify the default recovery plan execution steps to control whether some steps take effect in recovery plan execution based on functions to be achieved using steps and service recovery requirements.

Self-defined execution steps

If the default recovery plan execution steps cannot meet recovery service requirements, you can self-define your recovery plan execution steps by adding script steps to flexibly meet recovery requirements in a wide range of scenarios. Note that you cannot add a step before the first or after the last step of the default recovery plan execution steps. You can modify or delete steps when site conditions change.

For testing and clearing, two opposite operations, if testing execution steps are self-defined, you must determine whether opposite operations must be performed during test environment clearing to correctly recover the environment. If opposite operations must be performed, ensure that opposite operations are added to the clearing process. For example, add setting the DR routing network into the testing process, and add clearing the DR routing network into the clearing process.

Procedure

  1. On the menu bar, select Utilization > Data Recovery.
  2. Select the recovery plan whose execution steps you want to self-define and click the Procedure tab below it.
  3. Click Edit.

    The Edit dialog box is displayed.

  4. Select the phase whose steps you want to self-define, for example, test, or clear.
  5. Click Add.

    The Add Step dialog box is displayed.

  6. Based on your requirements, self-define an execution script for recovery plans.

    A self-defined script is not provided by eReplication, so the script provider must ensure the script correctness. Before configuring the script, ensure that the script has been verified by tests.

    NOTE:

    When the protected object is a NAS file system or VMware VM, execution steps cannot be self-defined.

    1. The name of a self-defined execution script must contain 4 to 32 characters, including letters, digits, underscores (_) and hyphens (-), but cannot start with a hyphen (-). The script name extension must be .bat (for Windows) or .sh (for Linux/UNIX).

      When the protected object is an Oracle, IBM DB2, Microsoft SQL Server database, Microsoft Exchange Server, NTFS local file system, or LUN, log in to the host where the protected object resides and obtain the script template for self-defining the execution script.

      • In Windows, the script path is %OceanStor BCManager Agent install path%\bin\thirdparty\sample and the script sample name is sample.bat.
      • In Linux/UNIX, the script path is /home/rdadmin/Agent/bin/thirdparty/sample and the script sample name is sample.sh.

    2. Log in to the DR management server at the DR site or to the service host, place the self-defined execution script in a specified path.

      • When the protected object is a FusionSphere VM, the path for placing the script is as follows:
        • In Windows: the path is %OceanStor BCManager Server installation root directory%\Runtime\LegoRuntime\tools\.
        • In Linux: the path is $OceanStor BCManager Server install root path$/Runtime/LegoRuntime/tools/
      • When the protected object is an Oracle, IBM DB2, Microsoft SQL Server database, Microsoft Exchange Server, NTFS local file system, or LUN, the path for placing the script is as follows:
        • In Windows: the path is %OceanStor BCManager Agent install path%\bin\thirdparty\
        • In Linux/UNIX: the path is /home/rdadmin/Agent/bin/thirdparty/

    3. Set the owner and execute permission of the self-defined execution script.

      • When the protected object is a FusionSphere VM, the setting requirements are as follows:
        • In Windows, settings are not required.
        • In Linux/UNIX, run the chown ICUser:LEGO xxx.sh command to set the script owner to ICUser:LEGO. Run the chmod 500 xxx.sh command to set the script execute permission to 500,

          where xxx is the name of the self-defined script.

      • When the protected object is an Oracle, IBM DB2, Microsoft SQL Server database, Microsoft Exchange Server, NTFS local file system, or LUN, the setting requirements are as follows:
        • In Windows, settings are not required.
        • In Linux/UNIX, run the chown root xxx.sh command to set the script owner to root. Run the chmod 500 xxx.sh command to set the script execute permission to 500,

          where xxx is the name of the self-defined script.

        If you do not set the owner and execute permission of the self-defined script, the script may be modified by hackers, posing security risks.

  7. Enter Step Name and Script Name.
  8. Select Step Execution Policy and Step Location, and click OK.

    Step Execution Policy is described as follows:

    • After failure process to be continued: The recovery plan execution continues for DR after this step fails.
    • After failure process termination: The recovery plan execution stops for DR after this step fails.

    The value of Step Location can be Before the selected step or After the selected step. You can set the step execution sequence, but you cannot add a step before the first or after the last step of the default recovery plan execution steps.

  9. In the right group box, select or deselect Start the step to enable or disable a step and click Apply.
  10. Click Close.

Follow-up Procedure

After recovery plan execution steps are modified, the modification takes effect when the recovery plan is executed the next time. When a recovery plan is executed, eReplication combines the default recovery plan execution steps, self-defined recovery plan execution steps and sequentially performs the steps in workflow mode. You are advised to implement recovery plan testing and clearing immediately after the recovery plan execution steps are modified to ensure configuration correctness.

Self-defining Startup Parameters for a Protected Object

If upper-layer services have special requirements on the startup sequence of databases or VMs, or on the recovery network of VMs, you can modify startup parameters based on the existing network conditions before performing DR. The aim of doing this is to ensure that databases or VMs can start services after DR. This operation can be performed only in the DR management system at the DR site.

Prerequisites

  • You have logged in to the remote DR management system at the DR site.
  • The status of the recovery plan is Ready, Planned migration failed, Fault recovery failed, Reprotection completed, Clearing completed, Rollback failed, or Rollback completed.

Procedure

  1. On the menu bar, select Utilization > Data Recovery.
  2. When the protected objects are Oracle, IBM DB2, or Microsoft SQL Server databases, you can define the startup sequence of databases during DR.
    1. Select a recovery plan whose protected objects are databases and click the Protected Object tab.
    2. Click Startup Settings.

    3. If you choose to start databases during DR testing, fault recovery, or planned migration, you can set the database startup sequence.

      When multiple databases in a protected group are mutually dependent or upper-layer services have requirements on database startup sequence, you can set the startup sequence of databases. The default startup sequence number is 10. The database with a smaller number starts earlier. A smaller sequence number indicates a higher startup priority. Databases with the same priority start randomly.

    4. Click OK.
  3. When the protected objects are VMware VMs or FusionSphere VMs, you can define the startup sequence and DR network of VMs.
    1. Select a recovery plan whose protected objects are VMs and click the Protected Object tab.
    2. Click Startup Settings.



    3. Choose whether to start VMs during DR testing, fault recovery, or planned migration.

      • If you select Yes, you can set the VM startup sequence. The default startup sequence number is 10. The startup sequence number for a VM ranges from 1 to 512. A smaller sequence number indicates a higher startup priority. VMs with higher priorities start earlier. VMs with the same priority start randomly. Template VMs cannot be started during recovery. By default, they cannot be started or modified.
      • If you select No, the VMs cannot be started during DR testing, fault recovery, or planned migration.

    4. If you want to modify the configurations for VM DR network, select a VM to be modified and click Test Network Settings in the Operation column of the VM. In the Test Network Settings dialog box that is displayed, modify the configurations.

      • FusionSphere VMs

        If you specify a recovery network when recovering a VM, the system automatically assigns this network to the VM. If you do not specify a recovery network, the VM keeps original network settings after being recovered.

        • In the FusionManager scenario:



        • In the FusionCompute scenario:



        NOTE:
        • Before configuring this parameter for a VM, ensure that the VM at the production site has been configured with specifications attributes, or the template for creating the VM has been configured with specifications attributes. Only a VM that meets the prior requirements supports IP address customization. For details, see sections Configuring Specifications Attribute Customization for a Linux VM and Configuring Specifications Attribute Customization for a Windows VM in the document based on the actual version of FusionSphere.
          • If the version of FusionSphere is FusionSphere V100R005C00, see FusionCompute V100R005C00 Virtual Machine Management Guide.

          • If the version of FusionSphere is FusionSphere V100R005C10, see FusionCompute V100R005C10 Virtual Machine Management Guide.

          • If the version of FusionSphere is FusionSphere V100R006C00, see FusionSphere Product Documentation (Server Virtualization,FusionCompute V100R006C00U1).

        • In the FusionCompute scenario, you can modify configurations of the VM network in a batch.
          1. Click Export IP Configuration to export the configuration template.
          2. Modify the configurations of the VM network. If Enable IPv4 Address Settings is set to N, IPv4 address settings are disabled. For details about how to modify the configuration information, see Note in the configuration template.
          3. Click Import IP Configuration to import the configuration template.


        • Currently, IPv4 and IPv6 address settings are supported.
        • Before configuring the DR network for a Linux VM, go to /etc/init.d and check whether the passwd_conf and setpasswd.sh files exist. If yes, delete the files and then select the network adapter whose recovery network you want to configure and configure an IPv4 address or elastic IP address.
        • Before configuring the DR network for a Windows VM, go to the root directory of drive C and check whether the setpass.vbs and passwd.inf files exist. If yes, delete the files and then select the network adapter whose recovery network you want to configure and configure an IPv4 address or elastic IP address.
      • VMware VMs

        When recovering a VM, if you have specified a recovery network, the system automatically assigns this network to the VM. If you do not specify a recovery network, the VM keeps original network settings after being recovered.

        NOTE:

        Only Windows and Linux VMware VMs can be configured with the network recovery function. For details about supported versions of the two operating systems, see the Guest OS Customization Support Matrix, which can be obtained from the VMware official website.

        • For VMs running Windows, first enter the administrator authentication information about the VM operating system, then select a network adapter whose recovery network you want to configure, and choose to manually specify or automatically obtain the IP address/DNS server addresses based on your requirements.

          If you choose the latter, the system automatically assigns the IP address/DNS server addresses of the production network to the DR network.



        • For VMs running Linux, first select a network adapter whose recovery network you want to configure, then choose to manually specify or automatically obtain the IP address/DNS server addresses based on your requirements, and finally configure the global DNS server address.

          If you choose the latter, the system automatically assigns the IP address/DNS server addresses of the production network to the DR network.



DR Testing in the DR Center

This section describes how to test data in a same-city or remote DR center. DR tests are implemented by snapshot mapping at the DR site. The test is to verify that data or snapshots replicated to the DR center are available. The test process has no adverse impact on the production site. After a test is complete, clear the test data generated at the DR site and restore resources to the status before the test, to facilitate future DR or planned migration.

Prerequisites

  • The production center communicates with the same-city/remote DR center properly.
  • At least one recovery plan has been created on eReplication.
  • For details about requirements on storage licenses for the tested recovery plan, see Checking License Files.
  • For database applications, all check items related to DR environments are passed. For details about the check items, see Oracle, IBM DB2, Microsoft SQL Server, and Microsoft Exchange Server.
  • VMware VMs:
    • The name of a protect VM cannot contain pound signs (#). The VM configuration file cannot be modified during the recovery plan test if the protected VM name contains such signs.
    • If the networks of the ESXi clusters or hosts at the production site and DR site are not isolated, you can configure different recovery IP addresses for test VMs and production VMs on the Protected Object tab page of the recovery plan to avoid IP address conflicts and ensure service continuity at the production site.
  • If application data is automatically replicated by storage instead of being periodically replicated based on the schedule specified upon the protected group creation, the data replication must be stopped before you start the DR test to prevent possible test failures. You can use either of the following methods to stop storage-based replication on the device management software:
    • When the remote replication pair for the protected applications is in the synchronized state and the data is consistent, split the remote replication pair to temporarily stop data replication.
    • Change the remote replication policy to manual synchronization for the protected applications.
  • 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.

Context

Data testing in the DR center is used to verify data availability.
  • You are advised to configure application-based protection policies for Oracle, SQL Server, DB2, VMware vSphere VMs, FusionSphere VMs, and NAS file systems, streamlining the test procedure to only a few clicks.
  • You are advised to configure LUN-based protection policies for other applications to enable automatic test configuration on the storage system. For this purpose, you need to manually or use self-defined scripts to start and test applications.

In the DR test, snapshots at the DR site can be mapped only to initiators.

Procedure

  1. Log in to Fibre Channel switches one by one, check the information about each Fibre Channel port, and calculate the BER. If the BER is larger than 0.1%, check links and rectify link faults.

    BER = Total number of errors/(In bytes + Out bytes) x 100%

    NOTE:
    A large BER may result in a remote replication failure in a specified window or an unexpected remote replication disconnection.


  2. Log in to the eReplication DR management server in the same-city or remote DR center.
  3. Test a recovery plan.
    1. On the menu bar, select Utilization > Data Recovery.
    2. Select the recovery plan to be tested, and click Test in the Operation area.
    3. Perform different operations for different protected objects.

      NOTE:
      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 type of protected objects is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, or Microsoft Exchange Server, perform the following operations:
        1. Select a DR site.
        2. Select a DR host or host group.
          NOTE:
          • If a T series V2 or later storage array is deployed at the DR site, the selected host that you want to recover can only belong to one host group on the storage array, and the host group can only belong to one mapping view. Moreover, the storage LUN used by protected applications and its corresponding remote replication secondary LUN 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 6.5.0, deselect the option for enabling hosts' in-band commands.
          • 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.
        3. Click Test.
        4. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select 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..
      • If the type of protected objects is VMware VM, perform the following steps:
        1. Select a test cluster.

          VMs will be recovered in the test cluster. Select Test Site, Test vCenter, and Test Cluster.

          NOTE:

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

        2. Select a test network.

          The default test network is the network for resource mapping. If you want to change the default network, plan or select another network based on site requirements.

          NOTE:

          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.

        3. Select non-critical VMs.

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

        4. Click Test.
        5. 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.
        6. Click OK.
      • If the type of protected objects is FusionSphere VM, perform the following steps: OpenStack
        1. Select a cluster to be tested.

          VMs will be recovered in the test cluster. Set Test Site.

          NOTE:

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

        2. Select a testing network.

          The default test network is the network for resource mapping. If you want to change the default network, plan or select another network based on site requirements.

        3. Select an available powered-on host.

          The available powered-on host can provide resources for VMs.

        4. Select non-critical VMs.

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

        5. Click Test.
        6. 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.
        7. Click OK.

  4. After a test is complete, verify that applications are started in the remote DR center.

    Verify that applications are started and accessed successfully. If an application fails to be started or cannot execute read and write operations, contact Huawei technical support.

    • 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.
      NOTE:
      You can use self-developed scripts to scan for disks, start applications, and test applications.

  5. Clear the test data generated at the DR site and restore resources to the status before the test, to facilitate future DR or planned migration.

    • Programs and files on the file systems have been closed before the clearing is performed for protected groups of the local file system type.
    • 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.

    1. Select the recovery plan whose data needs to be cleared, and click More > Clear on the Operation list.
    2. Click OK.

Planned DR Migration

Planned migration must be implemented when data or applications in the production center need to be migrated to the same-city or remote DR center due to non-disaster reasons such as a power failure, upgrade, or maintenance. You can switch production services from the production center to the same-city or remote DR center for DR testing.

Planned Migration from the Production Center to the Same-City DR Center

Planned migration must be implemented if data or applications in the production center need to be switched to the DR center due to non-disaster reasons such as a power failure, upgrade, or maintenance. During planned migration, you can migrate services to the DR center with a few clicks. After the migration, perform reprotection to protect services in the DR center.

Prerequisites

  • The production and same-city DR centers communicate with each other properly. The management system and the DR environment in the same-city DR center are working normally.
  • During planned migration, the production VM cannot contain disks that are not in the protected group. Otherwise, the production VM may fail to be deleted.
  • 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.

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.
          NOTE:
          • In the SQL Server cluster, the cluster must be in Maintenance mode before deleting the mapped LUNs.
          • In the asynchronous replication scenario of the HANA database, you need to log in to the database to create a snapshot for restoring the database before stopping the service system and database applications. For details, seeCreating a HANA Snapshot File.
        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 Recovery.
        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:
      • If any VM names contain pound signs (#), change them and avoid the use of pound signs (#). Otherwise, VM configuration files cannot be modified during the planned migration.
      • 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 Defining Startup Parameters for a Protected Object.
      • When the asynchronous replication (NAS) DR solution is deployed, you need to create a share and configure permissions on DeviceManager of the storage array at the DR site. Permissions must be the same as those in the production center.
        NOTE:

        If you fail to create a share and configure permissions, the planned migration will fail.

    • When the type of protected objects is the FusionSphere VM, 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 Defining Startup Parameters for a Protected Object.
      • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.

  2. Perform the planned migration to migrate services from the production center to the same-city DR center.
    1. On the menu bar, select Utilization > Data Recovery.
    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 different types of protected objects.

      NOTE:
      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 type of protected objects is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, or Microsoft Exchange Server, perform the following operations:
        1. Select a DR site.
        2. Select a DR host or host group.
          NOTE:
          • If a T series V2 or later storage array is deployed at the DR site, the selected host that you want to recover can only belong to one host group on the storage array, and the host group can only belong to one mapping view. Moreover, the storage LUN used by protected applications and its corresponding remote replication secondary LUN 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 6.5.0, deselect the option for enabling hosts' in-band commands.
          • 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.
        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.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.

          NOTE:

          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.

          NOTE:

          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.

        3. Set Logical Port IP Address to recover hosts in the cluster to access DR file systems over the logical port.
          NOTE:

          In scenarios where the asynchronous replication (NAS) DR solution is deployed, you need to set Access Settings.

        4. Stop non-critical VMs when executing recovery.

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

        5. Click Planned Migration.
        6. 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.
        7. Click OK.
      • If the protected object type is FusionSphere VM, perform the following steps:
        1. Select the cluster you want to recover.

          VMs will be recovered to the cluster. Select DR Site.

        2. Select an available powered-on host.

          The host will provide resources for VMs.

        3. Select non-critical VMs.

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

        4. Click Planned Migration.
        5. 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.
        6. Click OK.
        NOTE:

        During the planned migration in host-based replication DR mode, if the migration task remains in the Stop the VM step for a long time, a possible cause is that the internal program of the operating system cannot be closed. You can log in to FusionCompute and then log in to the VM using Virtual Network Computing (VNC) as an administrator, identify the failure cause, and safely stop the VM. If the failure persists, forcibly stop the VM on FusionCompute. (Forcible VM stop may result in a planned migration failure.) After forcibly stopping the VM, go to the Recovery page, select the protected group of the VM, click Start on the Protected Object page, and select Consistency verification to synchronize data. After data synchronization, execute the planned migration again.

  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.
        NOTE:
        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.

    NOTE:
    • 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.
    • When the protection type is SAP HANA, you do not need to clear the data after the planned migration is complete.

  5. Check the environment before starting the reprotection.

    • Databases:

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

    • VMware VMs:
      • Ensure that all VM names contain no number sign (#). Otherwise, the VM configuration file cannot be modified during the testing of the recovery plan.
      • 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.
    • FusionSphere VMs:
      • FusionCompute, FusionManager, storage devices, and VRGs at the production site are in the normal state, and the production site and DR site communicate with each other correctly.
      • In scenarios that uses storage array-based replication, ensure that storage configurations between the original production and DR sites are correct.
        • Ensure that all underlying storage units corresponding to protected groups have remote replication pairs.
        • Ensure that all remote replication pairs have secondary LUNs that belong to storage devices at the original production site.
        • If there are multiple remote replication pairs, they must belong to the same consistency group.
      • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.

  6. Perform reprotection to protect services switched to the intra-city DR center.

    After you complete the planned migration, the service system is working in the intra-city DR center and protected groups become Invalid. You must perform reprotection to restore data replication from the intra-city DR center to the production center so that data can be synchronized back to the production 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 Recovery.
    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.

      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 is complete, the status of protected groups returns to normal and the network mode of the Geo-Redundant Solution switches between cascading and parallel. A cascading network will change to a parallel one in geo-redundant protection mode and vice versa.

Performing Planned Migration from the Intra-City DR Center to the Production Center

After services are switched from the production center to the same-city DR center through planned migration, the services must be switched back to the production center based on a drill plan.

Prerequisites

  • Planned migration and reprotection have been performed for the service system according to a recovery plan.
  • The production host is working properly and the service system in the original production center is in the standby state.

Procedure

  1. On eReplication in the remote DR center, select a recovery plan used to perform a failback, test the recovery plan, and clear data generated during the test.

    Before the services are switched back, you need to perform a DR test to verify the data availability to ensure success rate of service failback. After the test, clear test data to avoid failback failures caused by the test data. For details, see DR Testing in the DR Center.

  2. On eReplication in the same-city DR center, select recovery plans to be switched back, and perform a planned migration.

    This step aims to switch services back to the production center. After migration, data must be checked and test data must be cleared. For details, see 1 to 4 in Planned Migration from the Production Center to the Same-City DR Center.

    NOTE:
    • If the protected object type is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, or Microsoft Exchange Server, select hosts or host groups in the production center as the recovery target.
    • If the protected object type is VMware VM, select vCenter and clusters in the production center as the recovery target.
    • If the protected object type is FusionSphere VM, select site in the production center as the recovery target.

  3. On eReplication in the same-city DR center, select the recovery plans that have been switched back and perform reprotection.

    After you complete the planned migration, the application systems are working in the original production center and protected groups become Invalid. To ensure that the production center can be recovered from the DR center when an event (planned or unplanned) happens on it after failback, reprotection must be performed. The replication status from it to the same-city DR center must be established again to synchronize data and ensure services are protected. For details, see 5 to 6 in Planned Migration from the Production Center to the Same-City DR Center.

Result

After the reprotection is complete, the protected groups become normal. The solution network has been restored to the original state.

Performing Planned Migration from the Production Center to the Remote DR Center

This section describes how to perform planned service migration from the production center to the remote DR center on cascading and parallel networks.

Prerequisites

  • During planned migration, the production VM cannot contain disks that are not in the protected group. Otherwise, the production VM may fail to be deleted.
  • 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.
  • The production and remote DR centers communicate with each other properly. The management system and the DR environment in the remote DR center are working normally.
  • 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.

Context

  • The following DR scenarios do not support reprotection:
    • In the Geo-Redundant Solution based on cascading replication (synchronous and asynchronous) or parallel replication (synchronous and asynchronous), reprotection cannot be implemented after services are switched over to the remote DR center.
    • In the Geo-Redundant Solution based on cascading replication (asynchronous and asynchronous), reprotection cannot be implemented after services are switched over to the remote DR center.

After services in the production center are migrated to the remote DR center in a planned manner, protected groups become invalid. You need to manually configure the protected groups after services are migrated back to the production centers.

Procedure

  1. Perform the planned migration on eReplication in the remote DR center.

    Migrate services in the production center to the remote DR center. After the migration, test data and clear the data generated during tests. For details, see 1 to 4 in Planned Migration from the Production Center to the Same-City DR Center.

Result

After the planned migration is performed:
  • the service system in the production center is stopped as planned.
  • The remote DR center takes over services and provides the services to users.
  • The replication relationship remains unchanged between the production center and the same-city DR center.
  • In a cascading network, the replication relationship between the same-city DR center and remote DR center is split. In a parallel network, the replication relationship between the production center and remote DR center is split.
  • DR protected groups become invalid.
Planned Failback from the Remote DR Center to the Production Center (Cascading Network)

This section shows how to manually switch production services back from the remote DR center to the production center on a synchronous and asynchronous or asynchronous and asynchronous cascading network.

Prerequisites

  • eReplication in the remote DR center has been used to switch services from the production center to the remote DR center as planned.
  • If the network is in synchronous and asynchronous mode, synchronous remote replication has been performed between storage arrays in the production center and the same-city DR center. The production storage array is the source (primary) array of the synchronous replication. Asynchronous remote replication has been performed between the same-city and remote DR centers, and the asynchronous replication is in the Split state. The DR storage array in the same-city DR center is the source (primary) array.
  • If the network is in asynchronous and asynchronous mode, synchronous remote replication has been performed between storage arrays in the production center and the same-city DR center. The production storage array is the source (primary) array of the asynchronous replication. Asynchronous remote replication has been performed between the same-city and remote DR centers, and the asynchronous replication is in the Split state. The DR storage array in the same-city DR center is the source (primary) array.

Context

To perform failback in a cascading network, perform the following steps:
  1. Synchronize production data from the remote DR center to the same-city DR center.
  2. Restore asynchronous remote replication relationships between storage arrays from the same-city DR center to the remote DR center.
  3. Synchronize data from the same-city DR center to the production center.
  4. Restore synchronous or asynchronous remote replication relationships between storage arrays from the production center to the same-city DR center.
  5. Test production services on the host in the production center.
  6. On eReplication in the same-city DR center, restore DR configurations.

Procedure

  1. Perform primary/secondary switchover for consistency groups of remote replication between the production center and the same-city DR center and that between the same-city and remote DR centers.
    1. Log in to the management software of the storage array in the production center and perform primary/secondary switchover for consistency groups of remote replication.

      1. Log in to the management software of the storage array in the remote DR production and split consistency groups of the remote replication.
      2. Deselect Protection for Secondary Resource for consistency groups of remote replication.
      3. Perform primary/secondary switchover for consistency groups of remote replication between the production center and intra-city DR center.

    2. Log in to the management software of the storage array in the same-city DR center and perform primary/secondary switchover for the asynchronous remote replication between storage arrays in the same-city and remote DR centers.

    Figure 6-1 and Figure 6-2 show the remote replication relationships between storage arrays in the production, same-city DR, and remote DR centers before and after the primary/secondary switchover, respectively.
    Figure 6-1  Remote replication relationships before the primary/secondary switchover on a synchronous and asynchronous network

    Figure 6-2  Remote replication relationships before the primary/secondary switchover on an asynchronous and asynchronous network

    NOTE:

    Remote replication in the Split state will not synchronize data.

    Remote replication relationships must be set in the Split state before the primary/secondary switchover.

    In a remote replication relationship, the source array is the primary end and the target array is the secondary end.

    Figure 6-3 and Figure 6-4 show the remote replication relationships between storage arrays in the production, same-city DR, and remote DR centers before and after the primary/secondary switchover, respectively.
    • If the network is in synchronous and asynchronous mode, synchronous remote replication is performed between storage arrays in the production and same-city DR centers. The DR storage array in the same-city DR center is the source (primary) array of the replication, and the replication relationship is in the Split state. Asynchronous remote replication is performed between the same-city and remote DR centers, and the replication relationship is in the normal state. The DR storage array in the remote DR center is the source (primary) array of the replication.
    • If the network is in asynchronous and asynchronous mode, asynchronous remote replication is performed between storage arrays in the production and same-city DR centers and between those in the same-city and remote DR centers. The remote replication relationships are in the Normal state. Asynchronous remote replication is performed between the same-city and remote DR centers, and the replication relationship is in the Normal state. The DR storage array in the remote DR center is the source (primary) array of the replication.
    Figure 6-3  Remote replication relationships after the primary/secondary switchover on a synchronous and asynchronous network

    Figure 6-4  Remote replication relationships after the primary/secondary switchover on an asynchronous and asynchronous network

  2. Synchronize service data from the remote disaster recovery center to the storage array in the same-city disaster recovery center.
    1. Log in to a host or VM in the remote DR center and stop services.

      • If the protected objects are databases, close the application system and unmount disks.
      • If the protected objects are local file systems, stop programs and files on the DR host.
      • If the protected objects are VMware VMs, close VMs and uninstall datastores.

    2. Log in to the management software of the storage array in the remote DR center and delete mapping views between LUNs and the DR host.
    3. Select Enable Protection for Secondary Resource for consistency groups of asynchronous remote replication.
    4. Synchronize data for consistency groups of asynchronous remote replication.
  3. After data is synchronized, split asynchronous remote replication's consistency groups between storage arrays in the remote and same-city DR centers.
    1. Log in to the management software of the storage array in the remote DR center and split consistency groups of the asynchronous remote replication.
    2. Select Disable Protection for Secondary Resource for consistency groups of asynchronous remote replication.
  4. Log in to the storage array in the same-city DR center and restore the asynchronous remote replication relationship between storage arrays in the same-city and remote DR centers.
    1. Log in to the storage array in the same-city disaster recovery center and perform primary/secondary switchover for the asynchronous remote replication consistency group between storage arrays in the same-city disaster recovery center and the remote disaster recovery center.
    2. Select Enable Protection for Secondary Resource for consistency groups of asynchronous remote replication.
    3. Synchronize data for consistency groups of asynchronous remote replication.

    The asynchronous remote replication relationship between storage arrays in the same-city and remote DR centers is restored, and the storage array in the same-city DR center is the primary array of the replication.

  5. Log in to the management software of the storage array in the same-city DR center, and synchronize data for the synchronous remote replication's consistency groups between storage arrays in the same-city DR and production centers.
    1. Log in to the management software of the storage array in the same-city DR center, select Enable Protection for Secondary Resource for the synchronous or asynchronous replication's consistency groups between storage arrays in the same-city DR and production centers.
    2. Synchronize data for consistency groups of synchronous or asynchronous remote replication.

    Remote replication is restored between storage arrays in the remote DR, same-city DR, and production centers, and data is consistent between the three centers.

  6. After data is synchronized, log in to the storage array of the production center and perform primary/secondary switchover between storage arrays in the production and same-city DR centers.

    The storage array in the production center becomes the primary array of the replication.

    • If the network is in synchronous and asynchronous mode, the primary/secondary switchover can be directly performed.
    • If the network is in asynchronous and asynchronous mode, the three operations must be performed in sequence: primary/secondary switchover, Enable Protection for Secondary Resource selection, and data synchronization for consistency groups of asynchronous remote replication.

    Remote replication is successfully restored between the three data centers in a cascading network:

    • If the network is in cascading mode, asynchronous remote replication is performed between storage arrays in the production and same-city DR centers. The storage array in the production center is the primary array of the synchronous replication. Asynchronous remote replication is performed between storage arrays in the same-city and remote DR centers, and the storage array in the same-city DR center is the primary array of the replication.
    • If the network is in synchronous and asynchronous mode, asynchronous remote replication is performed between storage arrays in the production and remote DR centers. The storage array in the production center is the primary array of the replication. Asynchronous remote replication is performed between storage arrays in the same-city and remote DR centers, and the storage array in the same-city DR center is the primary array of the replication.

  7. Test production services in the production center.
    1. Log in to the management software of the storage array in the production center and restore mapping views between LUNs and the production host.
    2. Log in to the production host or VM, and test services.

      • If the protected objects are databases, mount disks, start application systems, and test services.
      • If the protected objects are local file systems, start programs and files on the DR host, and test services.
      • If the protected objects are VMware VMs, attach datastores, start VMs, and test services.

  8. Restore DR configurations.
    1. Log in to eReplication in the same-city DR center, refresh its managed storage arrays and hosts, delete invalid DR protected groups and recovery plans.
    2. Re-create DR protected groups and recovery plans.

Result

After service failback:
  • Services on the production center can be accessed properly.
  • In a cascading network in synchronous and asynchronous network, data is synchronously replicated from the production center to the same-city DR center, and is asynchronously replicated from the same-city DR center to the remote DR center.
  • In an asynchronous and asynchronous cascading network, data is synchronously replicated from the production center to the same-city DR center, and is asynchronously replicated from the same-city DR center to the remote DR center.
  • The DR management server completes the DR in the cascading network.
Planned Failback from the Remote DR Center to the Production Center (Parallel Network)

In an asynchronous and synchronous network, eReplication can be used to switch services from the remote DR center back to the production center. In a synchronous and asynchronous network, you need to manually perform a planned failback.

Prerequisites

  • eReplication in the remote DR center has been used to switch services from the production center to the remote DR center as planned.
  • On a synchronous and asynchronous parallel network, the disk array replication relationship has been properly set: Data is synchronously replicated from the production center to the same-city DR center, and is asynchronously replicated from the production center to the remote DR center (split).
  • On an asynchronous and asynchronous parallel network, the disk array replication relationship has been properly set: Data is asynchronously replicated from the production center to the same-city DR center, and is asynchronously replicated from the production center to the remote DR center (split).

Context

  • To perform a failback in an asynchronous and asynchronous network, perform the following steps on eReplication in the remote DR center:
    1. Perform reprotection to protect services migrated to the remote DR center again.
    2. Perform a test and clearing and verify data availability to ensure the success rate of service failback.
    3. Perform planned migration to switch the services back to the production center from the remote DR center.
    4. Perform reprotection to protect services switched back to the production center again.
  • To perform a failback on a synchronous and asynchronous network, perform the following steps:
    1. Synchronize production data from the DR center to the production center.
    2. Restore asynchronous remote replication between storage arrays from the production center to the remote DR center.
    3. Synchronize data from the production center to the same-city DR center.
    4. Restore synchronous remote replication between storage arrays from the production center to the same-city DR center.
    5. Test production services in the production center.
    6. Restore DR configurations on the DR management server in the same-city DR center.

Procedure

  • The following methods show how to switch production services back from the remote DR center to the production center on an asynchronous and asynchronous parallel network:
    1. On eReplication in the remote DR center, perform reprotection to protect services migrated to the remote DR center again.

      After you complete the planned migration, the application system is working in the remote DR center and protected groups become Invalid. Before service failback, reprotection needs to be implemented to reversely protect production services running on the remote DR center. Based on specified policies, service data generated in the remote DR center is automatically replicated to the original production center. For details, see 5 to 6 in Planned Migration from the Production Center to the Same-City DR Center.

    2. On eReplication in the remote DR center, perform a test and clearing and verify data availability to ensure the success rate of service failback.

      Before the services are switched back, you need to perform a DR test to verify the data availability to ensure success rate of service failback. After the test, clear test data to avoid failback failures caused by the test data. For details, see DR Testing in the DR Center.

    3. On eReplication in the remote DR center, perform planned migration to switch the services back to the production center from the remote DR center.

      This step aims to switch services back to the production center. After migration, data must be checked and test data must be cleared. For details, see 1 to 4 in Planned Migration from the Production Center to the Same-City DR Center.

      NOTE:
      • If the protected object type is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, or Microsoft Exchange Server, select hosts or host groups in the production center as the recovery target.
      • If the protected object type is VMware VM, select vCenter and clusters in the production center as the recovery target.
      • If the protected object type is FusionSphere VM, select site in the production center as the recovery target.

    4. On eReplication in the remote DR center, perform reprotection to protect services switched back to the production center again.

      After failback, the application system is running on the production center and protected groups become Invalid. In this case, reprotection needs to be implemented to protect services in the production center. Based on specified policies, service data generated in the production center is automatically replicated to the remote and same-city DR centers. For details, see 5 to 6 in Planned Migration from the Production Center to the Same-City DR Center.

  • The following content shows how to switch production services back from the remote DR center to the production center on a synchronous and asynchronous parallel network.
    1. On the production storage, split the synchronous remote replication from the production center to the same-city DR center and perform primary/secondary switchover for the replication.

      1. Log in to the management software of the storage array in the production center.
      2. Split the consistency groups of synchronous remote replication.
      3. Perform primary/secondary switchover for the consistency groups of the asynchronous remote replication.
      This substep aims to prepare for data synchronization from the remote DR center to the production center. Before the primary/secondary switchover, remote replication relationships between storage arrays in the production, same-city DR, and remote DR centers are shown in Figure 6-5:
      Figure 6-5  Original remote replication relationships

      • Synchronous remote replication is performed between storage arrays in the production center and the same-city DR center. The production storage array is the source (primary) array of the synchronous replication.
      • Asynchronous remote replication is performed between the production center and the remote DR center, and the asynchronous replication is in the Split state. The production storage array is the source (primary) array of the replication.
      NOTE:

      Remote replication in the Split state will not synchronize data.

      Remote replication relationships must be set in the Split state before the primary/secondary switchover.

      In a remote replication relationship, the source array is the primary end and the target array is the secondary end.

      After the synchronous remote replication consistency group is split and primary/secondary switchover is performed for the asynchronous remote replication consistency group in the production center, remote replication relationships between storage arrays in the production, same-city DR, and remote DR centers are shown in Figure 6-6:
      Figure 6-6  Remote replication relationships after primary/secondary switchover

      • Synchronous remote replication is in the Split state between the production center and the same-city DR center, and data synchronization is stopped.
      • The storage array in the remote DR center becomes the source array of the asynchronous remote replication.

    2. Synchronize service data from the remote DR center to the storage array in the production center.

      1. Log in to a host or VM in the remote DR center and stop services.
        • If the protected objects are databases, close the application system and unmount disks.
        • If the protected objects are local file systems, stop programs and files on the DR host.
        • If the protected objects are VMware VMs, close VMs and uninstall datastores.
      2. Log in to the management software of the storage array in the remote DR center and delete mapping views between LUNs and the DR host.
      3. Select Enable write protection for secondary LUN for consistency groups of asynchronous remote replication.
      4. Synchronize data for consistency groups of asynchronous remote replication.

    3. After data is synchronized, split the asynchronous remote replication from the remote DR center to the production center.

      1. Log in to the management software of the storage array in the remote DR center and split consistency groups of the asynchronous remote replication.
      2. Deselect Enable write protection for secondary LUN for consistency groups of asynchronous remote replication.

    4. Log in to the storage array in the production center and restore asynchronous remote replication between storage arrays in the production and remote DR centers.

      1. Log in to the management software of the storage array in the production center and perform primary/secondary switchover for consistency groups of asynchronous remote replication.
      2. Select Enable write protection for secondary LUN for consistency groups of asynchronous remote replication.
      3. Perform data synchronization for consistency groups of asynchronous remote replication.

        Asynchronous remote replication is restored between storage arrays in the production remote DR centers, and the storage array in the production center is the primary array of the asynchronous replication.

    5. Log in to the management software of the storage array in the production center and synchronize data for consistency groups of asynchronous remote replication to synchronize data from the production center to the same-city DR center.

      Data replication is implemented between storage arrays in the remote DR, production, and same-city DR centers, and data is consistent between the three centers.
      • Synchronous remote replication is performed between storage arrays in the production and same-city DR centers. The storage array in the production center is the primary array of the synchronous replication.
      • Asynchronous remote replication is performed between storage arrays in the production and remote DR centers. The storage array in the production center is the primary array of the asynchronous replication.

    6. Test production services in the production center.

      1. Log in to the management software of the storage array in the production center and restore mapping views between LUNs and the production host.
      2. Log in to the production host or VM, and test services.
        • If the protected objects are databases, mount disks, start application systems, and test services.
        • If the protected objects are local file systems, start programs and files on the DR host, and test services.
        • If the protected objects are VMware VMs, attach datastores, start VMs, and test services.

    7. Restore DR configurations.

      1. Log in to eReplication in the same-city DR center, refresh its managed storage array and host resources, and delete invalid DR protected groups and recovery plans.
      2. Re-create DR protected groups and recovery plans.

Result

  • After service failback in a synchronous and asynchronous parallel network:
    • Services on the production center can be accessed properly.
    • Data is synchronously replicated from the production center to the same-city DR center, and is asynchronously replicated from the production center to the remote DR center.
    • The DR management server completes the DR on the parallel network.
  • After service failback in an asynchronous and asynchronous parallel network:
    • Services on the production center can be accessed properly.
    • Data is synchronously replicated from the production center to the same-city DR center, and is asynchronously replicated from the production center to the remote DR center.
    • The DR management server completes the DR on the parallel network.

DR Switchover

If data or applications of the production center cannot be used due to disasters or faults, you can use recent data at the DR center to recover services. This operation can be performed only on eReplication at the DR center.

Performing Fault Recovery from the Production Center to the Intra-City DR Center

When the production center encounters a disaster, services in the production center can be switched to the same-city DR center using eReplication.

Prerequisites

  • Recovery plans have been created for protected groups.
  • Data has been tested and the data generated during the test has been cleared in the same-city 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.

Context

When the production center encounters an irrecoverable disaster, its services can be switched to the same-city DR center based on a remote recovery plan.
  • In a cascading network, services are switched to the same-city DR center and asynchronous data replication is periodically implemented from the same-city DR center to the remote DR center.
  • In a parallel network, services are switched to the same-city DR center and data is not automatically replicated from the same-city DR center to the remote DR center. Asynchronous replication must be manually configured from the same-city DR center to the remote DR center.

Procedure

  1. Optional: Perform configurations before the recovery.

    • When the protected objects are VMware VMs, perform the following configurations:
      • If any VM names contain number signs (#), change them and avoid the use of number signs (#). Otherwise, VM configuration files cannot be modified during the fault recovery.
      • Without configuration, the VM IP address for fault recovery is the same as that in the production center. You can configure one for fault recovery on the Protected Object tab page of the recovery plan. For details, see Defining Startup Parameters for a Protected Object.
      • When the asynchronous replication (NAS) DR solution is deployed, you need to create a share and configure permissions on DeviceManager of the storage array at the DR site. Permissions must be the same as those in the production center.
        NOTE:

        If you fail to create a share and configure permissions, faults cannot be rectified.

    • When the type of protected objects is FusionSphere VMs, perform the following configurations:
      • Without configuration, the VM IP address for fault recovery is the same as that in the production center. You can change it for the planned VM migration on the Protected Object tab page of the recovery policy. For details, see Defining Startup Parameters for a Protected Object.
      • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.

  2. Perform a fault recovery.

    NOTE:
    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.

    1. On the menu bar, select Utilization > Data Recovery.
    2. Select the recovery plan used for fault recovery and click More > Fault Recovery on the Operation list.
    3. Perform fault recovery based on the protected object type.

      • If the type of protected objects is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, or Microsoft Exchange Server, perform the following operations:
        1. Select a DR site.
        2. Select a DR host or host group.
          NOTE:
          • If a T series V2 or later storage array is deployed at the DR site, the selected host that you want to recover can only belong to one host group on the storage array, and the host group can only belong to one mapping view. Moreover, the storage LUN used by protected applications and its corresponding remote replication secondary LUN 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 6.5.0, deselect the option for enabling hosts' in-band commands.
          • 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.
        3. Click Fault Recovery.
        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.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 cluster. Select DR Site, DR vCenter, and DR Cluster.

          NOTE:

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

        2. Select a recovery network.

          The network is used to access recovered VMs.

          NOTE:

          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.

        3. Set Logical Port IP Address to recover hosts in the cluster to access DR file systems over the logical port.
          NOTE:

          In scenarios where the asynchronous replication (NAS) DR solution is deployed, you need to set Access Settings.

        4. Stop non-critical VMs when executing recovery.

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

        5. Click Fault Recovery.
      • If the protected object type is FusionSphere VM, perform the following steps:
        1. Select the cluster you want to recover.

          VMs will be recovered in the test cluster. Select DR Site.

        2. Select an available powered-on host.

          The available powered-on host can provide resources for VMs.

        3. Select non-critical VMs.

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

        4. Click Fault Recovery.
        5. 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.
        6. Click OK.

  3. In the production center, check the application startup status.

    After the fault recovery 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, you need to log in to the application host in the disaster recovery center, scan for disks, and start applications. Then check whether the applications are started successfully and data can be read and written correctly.
        NOTE:
        You can use self-developed scripts to scan for disks, start applications, and test applications.

  4. If the environment is networked in cascading mode, use the storage array management software in the same-city DR center to create asynchronous remote replication from the same-city DR center to the remote DR center.

    When creating the asynchronous replication relationship, you are advised to create LUNs in the storage array in the remote DR center for DR. If you use the original LUNs for DR, the original DR data will be overwritten.

  5. If the environment is networked in parallel mode, log in to eReplication in the same-city DR center to create DR protected groups and recovery plans from the same-city DR center to the remote DR center for the service system.

Result

After the production center is faulty, services are taken over the same-city DR center.

Fault Recovery from Production and Intra-City DR Centers to the Remote DR Center

If storage arrays in the production and same-city DR centers encounter unrecoverable faults and a DR host is deployed in the remote DR center, services can be switched 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 the test 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.

Procedure

  1. Optional: Perform configurations before the recovery.

    • When the protected objects are VMware VMs, perform the following configurations:
      • If any VM names contain number signs (#), change them and avoid the use of number signs (#). Otherwise, VM configuration files cannot be modified during the fault recovery.
      • Without configuration, the VM IP address for fault recovery is the same as that in the production center. You can configure one for fault recovery on the Protected Object tab page of the recovery plan. For details, see Defining Startup Parameters for a Protected Object.
      • When the asynchronous replication (NAS) DR solution is deployed, you need to create a share and configure permissions on DeviceManager of the storage array at the DR site. Permissions must be the same as those in the production center.
        NOTE:

        If you fail to create a share and configure permissions, faults cannot be rectified.

    • When the type of protected objects is FusionSphere VMs, perform the following configurations:
      • Without configuration, the VM IP address for fault recovery is the same as that in the production center. You can change it for the planned VM migration on the Protected Object tab page of the recovery policy. For details, see Defining Startup Parameters for a Protected Object.
      • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.

  2. Perform a fault recovery. When selecting a DR host to take over services in the remote DR center, ensure that data is tested on the selected host.

    Fault recovery uses the latest data generated in the remote DR center to enable fast service startup at the remote DR center. Before a fault recovery, at least one recovery plan test must be executed successfully. After fault recovery, data must be checked. For details, see 2 to 3 in Performing Fault Recovery from the Production Center to the Intra-City DR Center.

Result

After fault recovery:
  • The remote DR center provides services properly.
  • The protected groups and recovery plan become invalid.

System Reconstruction

After the production center is reconstructed, you need to reconstruct the DR mapping between the production center and DR center and migrate data back to the production center.

Reconstructing the Production Center Using Data of the Intra-City DR Center

When the production center encounters a disaster, data of the production center can be recovered from the same-city DR center to reconstruct the production service system.

Prerequisites

  • Software and hardware have been installed on production storage for service reconstruction and related license has been obtained.
  • The network has been established and is normal between production and DR storage.
  • LUNs have been configured on production storage.
  • The service system has been deployed in the production center.

Procedure

  1. Log in to storage arrays in the same-city DR center and create remote synchronous replication for LUNs on storage arrays from the same-city DR center to the production center.
  2. (Optional) Log in to storage arrays in the production center, and create asynchronous remote replication for LUNs on storage arrays from the production center to the remote DR center.

    This operation needs to be performed only when a parallel network is used.

  3. Re-create DR protected groups and recovery plans on the DR management server in the same-city DR center.
  4. Test recovery plans and clear data generated during tests on the DR management server in the same-city DR center.

Result

  • Reconstruct the production center using data of the same-city DR center.
  • If the original network is in cascading mode, synchronous replication is implemented from the same-city DR center (providing services) to the production center, and asynchronous replication is implemented from the same-city DR center to the remote DR center.
  • If the original network is in parallel mode, synchronous replication is implemented from the same-city DR center to the production center, and asynchronous replication is implemented from the production center to the remote DR center.
NOTE:

After the data reconstruction, you can perform planned migration to migrate service back to the production center from the same-city DR center.

Reconstructing the Same-city DR Center (Cascading Network)

To reconstruct the same-city DR center on a cascading network, create a synchronous remote replication relationship between the storage arrays in the production center and same-city DR center and an asynchronous remote replication relationship between the storage arrays in the same-city DR center and remote DR center, and reconfigure protected groups and recovery plans on the DR management server.

Prerequisites

  • Physical and logical links have been established between the production center and the same-city DR center and between the same-city DR center and the remote DR center.
  • The same LUNs have been created on the storage array in the same-city DR center as those in the production center.
  • The DR management server in the same-city DR center has been recovered, and the DR network communication is normal.

Procedure

  1. Log in to the storage array in the production center. Create a synchronous remote replication relationship between the storage arrays in the production center and same-city DR center.
  2. Log in to the storage array in the same-city DR center. Create an asynchronous remote replication relationship between the storage arrays in the same-city DR center and remote DR center.
  3. Log in to DR management server eReplication in the same-city DR center. Add hosts and storage arrays of the same-city DR center to the corresponding site.
  4. Delete the existing protected groups and recovery plans.
  5. Re-create protected groups and recovery plans.

Result

  • The synchronous remote replication relationship is restored between the storage arrays in the production center and same-city DR center, and the asynchronous remote replication relationship is restored between the storage arrays in the same-city DR center and remote DR center.
  • protected groups and recovery plans are re-created successfully on the cascading network. On the DR management server eReplication in the same-city DR center, you can see a complete DR topology and perform DR testing based on recovery plans.
Reconstructing the Same-city DR Center (Parallel Network)

To reconstruct the same-city DR center on a parallel network, create a synchronous remote replication relationship between the storage arrays in the production center and same-city DR center, and reconfigure protected groups and recovery plans on the DR management server.

Prerequisites

  • Physical and logical links have been established between the production center and the same-city DR center, and storage arrays have been added as remote devices for each other.
  • The same LUNs have been created on the storage array in the same-city DR center as those in the production center.
  • The DR management server in the same-city DR center has been recovered, and the DR network communication is normal.

Context

  • When the storage array in the same-city DR center encounters an unrecoverable fault, the same-city DR center needs to be reconstructed. Data is synchronized after a remote replication is established for the first time. You are advised to reconstruct the same-city DR center during off-peak hours.
  • All DR operations are performed on the DR management server in the same-city DR center.

Procedure

  1. On the storage array in the production center, create a synchronous remote replication relationship between the production center and the same-city DR center.
  2. Log in to the DR management server eReplication in the same-city DR center. Add hosts and storage arrays of the same-city DR center to the corresponding site.
  3. Delete the existing protected groups and recovery plans.
  4. Re-create protected groups and recovery plans.

Result

  • The synchronous remote replication relationship is restored between the storage arrays in the production center and same-city DR center.
  • protected groups and recovery plans are re-created successfully on the parallel network. On the DR management server eReplication in the same-city DR center, you can see a complete DR topology and perform DR testing based on recovery plans.
Fault Recovery of the Remote DR Center (Cascading Network)

When reconstructing the remote DR center on a cascading network, you need to restore asynchronous remote replication, add and refresh site resources, and create new protected groups and recovery plans.

Prerequisites

  • Physical and logical links have been ready between the remote and same-city DR centers.
  • Configurations of LUNs are the same on the storage arrays in the remote DR center and same-city DR center.

Procedure

  1. On the disk array in the same-city DR center, create asynchronous remote replication from the same-city DR center to the remote one.
  2. Synchronize data for consistency groups of asynchronous remote replication.
  3. Log in to the DR management server in the remote DR center and add new hosts and storage arrays to remote DR sites.
  4. Log in to the DR management server in the same-city DR center and refresh resources at the remote DR sites.
  5. Delete invalid DR protected groups and recovery plans.
  6. Re-create DR protected groups and recovery plans.

Result

  • Asynchronous remote replication is restored between storage arrays in the same-city and remote DR centers.
  • protected groups are restored based on the DR plan. You can see a clear and complete DR topology and perform DR testing.
Fault Recovery of the Remote DR Center (Parallel Network)

When reconstructing the remote DR center on a parallel network, you need to restore synchronous remote replication, add and refresh site resources, and create new protected groups and recovery plans.

Prerequisites

  • Physical and logical links have been ready between the remote DR center and the production center.
  • The configurations of LUNs are the same on the storage arrays in the remote DR center and the production center.

Procedure

  1. Log in to the storage array in the production center and create asynchronous remote replication from the production center to the remote DR center.
  2. Synchronize data for consistency groups of asynchronous remote replication.
  3. Log in to the eReplication DR management server in the remote DR center and add new hosts and storage arrays to the corresponding sites.
  4. Log in to the eReplication DR management server in the same-city DR center and refresh site resources in the remote DR center.
  5. Delete invalid protected groups and recovery plans.
  6. Re-create related protected groups and recovery plans.

Result

  • Asynchronous remote replication is restored between storage arrays in the production center and the remote DR center.
  • protected groups are restored based on the DR plan. You can see a clear and complete DR topology and perform DR testing.
Reconstructing a DR System by Using the Remote DR Center (Cascading Network)

To reconstruct a DR system by using the remote DR center on a cascading network, synchronize data from the remote DR center to the same-city DR center, synchronize data from the same-city DR center to the production center, and then reconfigure protected groups and recovery plans on DR management servers.

Prerequisites

  • Storage arrays have been configured in the production center and same-city DR center, and LUNs have been created.
  • Physical and logical links have been established between the production center and the same-city DR center and between the same-city DR center and the remote DR center.
  • The DR management network has been recovered between the production center and the same-city DR center.

Procedure

  1. Log in to the storage array in the remote DR center. Create an asynchronous remote replication relationship between the storage arrays in the remote DR center and same-city DR center.
  2. Synchronize service data from the remote DR center to the same-city DR center.
    1. Log in to the DR host in the remote DR center, shut shown the application, and unmount disks.
    2. Log in to the storage array in the remote DR center, and remove the mapping view between the DR host and LUNs.
    3. Perform data synchronization for consistency groups of asynchronous remote replication.
  3. Split the asynchronous remote replication relationship between the storage arrays in the remote DR center and same-city DR center.
    1. Log in to the storage array in the remote DR center.
    2. Split consistency groups of asynchronous remote replication.
    3. Select Enable Protection for Secondary Resource for consistency groups of asynchronous remote replication.
  4. Perform a primary/secondary switchover for consistency groups of asynchronous remote replication.
    1. Log in to the storage array in the remote DR center.
    2. Perform a primary/secondary switchover for consistency groups of asynchronous remote replication.

      The storage array in the remote DR center becomes the secondary storage array, and the storage array in the same-city DR center becomes the primary storage array.

    3. Log in to the storage array in the same-city DR center. Perform data synchronization for consistency groups of asynchronous remote replication.

      The same-city DR center has been reconstructed by using the remote DR center.

  5. Log in to the storage array in the same-city DR center. Create a synchronous remote replication relationship between the storage arrays in the same-city DR center and production center, and perform data synchronization for consistency groups of synchronous remote replication.

    Data has been synchronized to the production center.

  6. Log in to the storage array in the production center. Perform a primary/secondary switchover for consistency groups of synchronous remote replication.

    Data has been synchronized and remote replication relationships have been restored between the production center, same-city DR center, and remote DR center.

  7. Test services.
    1. Log in to the storage array in the production center, and re-create a mapping view between the production host and LUNs.
    2. Log in to the production host, mount disks, and start the application to test services.
  8. Restore DR configurations.
    1. Log in to the DR management server eReplication in the same-city DR center. Add the hosts and storage arrays in the production center and same-city DR center to the corresponding sites.
    2. Add the DR management server eReplication in the remote DR center as the remote site.
    3. Delete the existing protected groups and recovery plans.
    4. Re-create protected groups and recovery plans.
    5. Log in to the DR management server eReplication in the remote DR center, and update resources at the remote site.

Result

  • Data is synchronously replicated from the production center to the same-city DR center and is asynchronously replicated from the same-city DR center to the remote DR center.
  • protected groups and recovery plans are re-created on the DR management servers. You can see a complete DR topology and perform DR testing.
Reconstructing a DR System by Using the Remote DR Center (Parallel Network)

To reconstruct a DR system by using the remote DR center on a parallel network, synchronize data from the remote DR center to the production center, synchronize data from the production center to the same-city DR center, and then reconfigure protected groups and recovery plans on DR management servers.

Prerequisites

  • Storage arrays have been configured in the production center and same-city DR center, and LUNs have been created.
  • Physical and logical links have been established between the production center and the same-city DR center and between the production center and the remote DR center.
  • The DR management network has been recovered between the production center and the same-city DR center.

Procedure

  1. Log in to the storage array in the remote DR center. Create an asynchronous remote replication relationship between the storage arrays in the remote DR center and production center.
  2. Synchronize service data from the remote DR center to the production center.
    1. Log in to the DR host in the remote DR center, shut down the application, and unmount disks.
    2. Log in to the storage array in the remote DR center, and remove the mapping view between the DR host and LUNs.
    3. Perform data synchronization for consistency groups of asynchronous remote replication.
  3. Split the asynchronous remote replication relationship between the storage arrays in the remote DR center and production center.
    1. Log in to the storage array in the remote DR center.
    2. Split consistency groups of asynchronous remote replication.
    3. Select Enable write protection for secondary LUN for consistency groups of asynchronous remote replication.
  4. Perform a primary/secondary switchover for consistency groups of asynchronous remote replication.
    1. Log in to the storage array in the remote DR center.
    2. Perform a primary/secondary switchover for consistency groups of asynchronous remote replication.

      The storage array in the remote DR center becomes the secondary storage array, and the storage array in the production center becomes the primary storage array.

    3. Log in to the storage array in the production center.
    4. Select Enable write protection for secondary LUN for consistency groups of asynchronous remote replication.
    5. Perform data synchronization for consistency groups of asynchronous remote replication.

      The production center has been reconstructed by using the remote DR center.

  5. Log in to the storage array in the production center. Create a synchronous remote replication relationship between the storage arrays in the production center and same-city DR center.
  6. Perform data synchronization for consistency groups of synchronous remote replication.

    Data has been synchronized and remote replication relationships have been restored between the production center, same-city DR center, and remote DR center.

  7. Test services.
    1. Log in to the storage array in the production center, and re-create a mapping view between the production host and LUNs.
    2. Log in to the production host, mount disks, and start the application to test services.
  8. Restore DR configurations.
    1. Log in to the DR management server in the same-city DR center. Add the hosts and storage arrays in the production center and same-city DR center to the corresponding sites.
    2. Add the DR management server in the remote DR center as the remote site.
    3. Delete the existing protected groups and recovery plans.
    4. Re-create protected groups and recovery plans.
    5. Log in to the DR management server in the remote DR center, and update resources at the remote site.

Result

  • Data is synchronously replicated from the production center to the same-city DR center and is asynchronously replicated from the production center to the remote DR center.
  • protected groups and recovery plans are re-created on the DR management servers. You can see a complete DR topology and perform DR testing.

Test Report Management of Recovery Plans

This section describes how to view the test reports of recovery plans to know the test details.

Procedure

  1. Perform either of the following operations to go to the Recovery Plan Test Report page.

    • On the menu bar, choose Monitor > Report > Recovery Plan Test Report.
    • On the home page, click More in the lower right corner of the Recovery Plan Test Duration (Latest 3 Months) or Recovery Plan Test Status (Latest 3 Months) area.

  2. Select the recovery plan whose details you want to view. Table 6-9 lists the report parameters.

    Table 6-9  Parameters of a recovery plan test report

    Parameter

    Description

    Name

    Indicates the name of the recovery plan.

    Production Site

    Indicates the site where the protected objects in the group reside (the protected site). Service systems of enterprises are running on the site.

    DR Site

    Indicates the site running the DR system. This site provides DR backup services for the protected objects. If a disaster occurs, it can be used to recover services.

    Protected Object Type

    Indicates the types of protected objects in a protected group of the recovery plan. eReplication enables you to create protected groups based on the following applications:
    • Oracle
    • IBM DB2
    • Microsoft SQL Server
    • Microsoft Exchange Server
    • Local File system
    • NAS File System
    • VMware VM
    • LUN
    • FusionSphere VM
    • SAP HANA

    Avg. Test Time

    Indicates the average time required by tests of the recovery plan. If two tests have been conducted on the recovery plan, the value is the average value of the time required by the tests.

    If reprotection has been performed on the recovery plan, time values collected after the latest reprotection must be used.

    Max. Test Time

    Indicates the maximum time required by a test of the recovery plan. If two tests have been conducted on the recovery plan, the value is the maximum value of the time required by the tests.

    If reprotection has been performed on the recovery plan, time values collected after the latest reprotection must be used.

    Min. Test Time

    Indicates the minimum time required by a test of the recovery plan. If two tests have been conducted on the recovery plan, the value is the minimum value of the time required by the tests.

    If reprotection has been performed on the recovery plan, time values collected after the latest reprotection must be used.

    Execution Result

    Indicates the execution result of a recovery plan test.

  3. Optional: Click Export All to export the test reports and save them to a local computer.
Translation
Download
Updated: 2019-05-21

Document ID: EDOC1100075861

Views: 14229

Downloads: 70

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