DR Testing

This section describes how to test data in the remote DR center. During DR tests, snapshot mappings in the DR center are used to verify usability of data or snapshots replicated to the DR center. The test process has no adverse impact on the production site. After the test is complete, the test data generated at the DR site needs to be cleared and resources need to be restored to the status before the test to facilitate future DR or planned migration.

Prerequisites

The datastore name cannot contain Chinese characters.

The production center communicates with the same-city and remote DR centers 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.
To database applications, all check items related to DR environments are passed. For details about the check items, see Oracle, IBM DB2, and Microsoft SQL Server.
If the protected objects are FusionCompute VMs:
- If storage array-based replication is used for DR, secondary LUNs of the remote replication pairs of the recovery plan have been mapped to VMs at the DR site.
- If networks of the production site and DR site are not isolated, you can configure recovery IP addresses different from those of the production VMs for the test VMs on the Protected Object tab page to avoid IP address conflicts and ensure service continuity at the production site.
- 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.
VMware VMs:
- 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.

HyperMetro (NAS) + asynchronous replication (NAS) does not support DR testing.

Context

Data testing in the DR center is used to check data availability.

You are advised to configure application-based protection policies for Oracle, SQL Server, DB2, VMware vSphere VMs, and FusionCompute VMs to support one-click testing.

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

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%

A large BER may result in a remote replication failure in a specified window or an unexpected remote replication disconnection.
Log in to the eReplication DR management server in the remote DR center.
Test the recovery plan.
1. On the menu bar, select Utilization > Data Restore.
2. Select the recovery plan to be tested, and click Test in the Operation area.
3. Perform operations based on the different protected objects.
  
  If Huawei UltraPath has been installed on the Linux-based DR host, ensure that I/O suspension time is not 0 and all virtual devices generated by UltraPath have corresponding physical devices. For details, see the OceanStor UltraPath for Linux xxx User Guide.
  - If the protected object type is Oracle, IBM DB2, or Microsoft SQL Server, perform the following:
    1. Select DR Site.
    2. Select Available DR Hosts or Host Groups.
      If the storage array used at the DR site is T series V2 or later, the to-be-recovered host selected by a user can belong to only one host group on the storage array, and the host group can belong to only one mapping view. Moreover, the storage LUN used by protected applications and its corresponding secondary remote replication LUNs must belong to one LUN group, and the LUN group must reside in the same mapping view as the host group. If the storage array version is T series V2R2, deselect Enable Inband Command to change the mapping view attribute after the mapping view is created.
      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. The creation principles are as follows:
    1. Click Test.
    2. 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.
    3. Click OK.
  - 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.
      
      Upon the first test network selection, you need to set the test cluster information.
    1. 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.
      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.
      During a DR test, do not select Keep the mac unchange. Otherwise, the MAC addresses of the production VM and DR VM conflict and the IP addresses cannot be pinged.
    1. Select non-critical VMs.
      In the Available VMs list, select non-critical VMs to stop them to release computing resources.
    2. Click Test.
    3. 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.
    4. Click OK.
  - If the type of protected objects is FusionCompute VM (non-OpenStack architecture), perform the following steps:
    1. Select a cluster to be tested.
      VMs will be recovered in the test cluster. Set Test Site.
      Upon the first test network selection, you need to set the test cluster information.
      After the DR test, if the protected object type is VMware VM, the VM name registered on the test vCenter is in the format of Protected VM name_4-digit random number_Drilling_Recovery plan name.
    1. 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.
    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 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.
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.
  
  You can use self-developed scripts to scan for disks, start applications, and test applications.
The test data generated at the DR site needs to be cleared and resources need to be restored to the status before the test to facilitate future DR or planned migration.
- In the Oracle application, the database is disabled but the cluster is enabled by default on the eReplication Agent. If you need to disable clusters, modify the configuration of disabling clusters. For details, see Changing the Configuration of Stopping the Oracle Cluster.
- If the protected group contains FusionCompute VMs and deleting a datastore fails during test data clearing, check whether non-DR VMs or disks exist on the datastore. If non-DR VMs or disks exist, migrate or delete them from the datastore.
- 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.