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.
Prerequisites
You have logged in to the DR management server.
Context
The management server provides the default recovery plan execution steps for different types of recovery, including testing, clearing, planned migration, fault recovery, reprotection, and backup restoration 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 1.
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
- On the menu bar, select Utilization > Data Restore.
- Select the recovery plan whose execution steps you want to self-define and click the Procedure tab below it.
- Click Edit.
The Edit dialog box is displayed.
- Select the phase whose steps you want to self-define, for example, test, or clear.
- Click Add.
The Add Step dialog box is displayed.
- Based on your requirements, self-define an execution script for recovery plans.
- When the protected object is a NAS file system or VMware VM, execution steps cannot be self-defined.
- When a customized script runs on the eReplication server, parameters cannot be transferred to the customized script.
- 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.
- When the protected object is a FusionCompute VM:
- Log in to the DR management server, place the self-defined execution script in a specified path.In Linux: The script is stored in $OceanStor BCManager Server installation root directory$/Runtime/LegoRuntime/tools/thirdParty/
- Script executed on the Server. The script execution path is $OceanStor BCManager Server install root path $/Runtime/LegoRuntime/.
- In active/standby deployment mode, the customized script executed on the server must be stored on both active and standby nodes.
- Set the owner and execute permission of the self-defined execution script.
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.
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.
- Log in to the DR management server, place the self-defined execution script in a specified path.
- When the protected object is an Oracle, IBM DB2, Microsoft SQL Server database, Microsoft Exchange Server, Local File System, or SAP HANA:
- log in to the service host where the protected object resides and obtain the script template for self-defining the execution script.
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).
- 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/sbin/thirdparty/sample and the script sample name is sample.sh.
- Place the self-defined execution script in a specified path.
- In Windows: the path is %OceanStor BCManager Agent install path%\bin\thirdparty\
- In Linux/UNIX: the path is /home/rdadmin/Agent/sbin/thirdparty/
- Set the owner and execute permission of the self-defined execution script.
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.
- log in to the service host where the protected object resides and obtain the script template for self-defining the execution script.
- When the protected object is a LUN:
- No host or host group is selected for planned migration, fault recovery, reprotection, or backup restoration:
- Log in to the DR management server, place the self-defined execution script in a specified path.In Linux: The script is stored in $OceanStor BCManager Server installation root directory$/Runtime/LegoRuntime/tools/thirdParty/
- When the script is executed on the Server, the current path is $OceanStor BCManager Server installation root directory$/Runtime/LegoRuntime/.
- For the active/standby deployment mode, the customized script executed on the Server must be stored on both the active and standby nodes.
- If the networking type of the protected object is storage replication (asynchronous), storage replication (synchronous), active-active + storage replication (asynchronous), SAN active-active + SAN cascading replication (active-active + asynchronous + asynchronous), SAN active-active + SAN cascading replication (active-active + synchronous + asynchronous), SAN active-active + SAN parallel replication (active-active + asynchronous + asynchronous) and SAN active-active + SAN parallel replication (active-active + synchronous + asynchronous). The following operations are supported:
- You can use the $BCM_MORPHOLOGICAL parameter in a customized script to obtain network information. For details, see Table 2.
- In the Planned migration process, you can determine whether to enable step Check mapping status between storage resource and host. The step is enabled by default. If this step is disabled, the customer needs to manually ensure that services at the production end are stopped during the planned migration.
- In the Planned migration process, you can determine whether to enable step Back up production data. By default, the step is disabled.
- In the Warning dialog box of Reprotection, you can choose whether to select Save user configuration data. By default, this option is not selected.
Table 2 Networking information description Networking Type
Complete Networking Information
Site Description
Switchover Direction
Networking Information Related to Switchover
Example
Return Code 0
Active/standby networking
Site-A->Site-B
The production site is Site-A, and the DR site is Site-B.
Positive: Switch to Site-B.
Site-A->Site-B
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '->Site-B$'
The DR site is Site-B.
Site-B->Site-A
The production site is Site-B, and the DR site is Site-A.
Negative: Switch back from Site-B.
Site-B->Site-A
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '->Site-A$'
The DR site is Site-A.
Geo-redundancy
Site-A:Site-B->Site-C
The production site is active-active Site-A:Site-B, and the DR site is Site-C.
Positive: Switch to Site-C.
Site-A:Site-B->Site-C
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '->Site-C$'
The DR site is Site-C.
Site-C->Site-B:Site-A
The production site is Site-C, and the DR site is active-active Site-B:Site-A.
Negative: Switch back from Site-C.
Site-C->Site-B:Site-A
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '^Site-C->'
The DR site is active-active Site-A:Site-B.
Geo-redundant multi-copy (parallel)
Site-D<-Site-A:Site-B->Site-C
The production site is active-active Site-A:Site-B, the DR site is Site-C, and the level-2 DR site is Site-D.
Positive: Switch to Site-C.
Site-A:Site-B->Site-C
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '->Site-C$'
The DR site is Site-C.
Site-D<-Site-A:Site-B->Site-C
The production site is active-active Site-A:Site-B, the DR site is Site-C, and the level-2 DR site is Site-D.
Positive: Switch to Site-D.
Site-B:Site-A->Site-D
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '->Site-D$'
The DR site is Site-D.
Site-C->Site-B:Site-A->Site-D
The production site is Site-C, the DR site is active-active Site-B:Site-A, and the level-2 DR site is Site-D.
Negative: Switch back from Site-C.
Site-C->Site-B:Site-A
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '^Site-C->'
The DR site is active-active Site-A:Site-B.
Site-D->Site-A:Site-B->Site-C
The production site is Site-D, the DR site is active-active Site-B:Site-A, and the level-2 DR site is Site-C.
Negative: Switch back from Site-D.
Site-D->Site-A:Site-B
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '^Site-D->'
The DR site is active-active Site-A:Site-B.
Geo-redundant multi-copy (cascading)
Site-A:Site-B->Site-C->Site-D
The production site is active-active Site-A:Site-B, the DR site is Site-C, and the level-2 DR site is Site-D.
Positive: Switch to Site-C.
Site-A:Site-B->Site-C
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '->Site-C$'
The DR site is Site-C.
Site-A:Site-B->Site-C->Site-D
The production site is active-active Site-A:Site-B, the DR site is Site-C, and the level-2 DR site is Site-D.
Positive: Switch to Site-D.
Site-A:Site-B->Site-C->Site-D
echo "$BCM_MORPHOLOGICAL" | grep -Eqe ':.*->Site-D$'
The DR site is Site-D.
Site-A:Site-B<-Site-C->Site-D
The production site is Site-C, the DR site is active-active Site-B:Site-A, and the level-2 DR site is Site-D.
Positive: Switch to Site-D.
Site-C->Site-D
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '^[^:]*->Site-D$'
The DR site is Site-D.
Site-D<-Site-C->Site-B:Site-A
The production site is Site-C, the DR site is active-active Site-B:Site-A, and the level-2 DR site is Site-D.
Negative: Switch back from Site-C.
Site-C->Site-B:Site-A
echo "$BCM_MORPHOLOGICAL" | grep -Eqe '^Site-C->.*:'
The DR site is active-active Site-A:Site-B.
- In the networking information related to switchover, only the sites related to the switchover process are transferred.
- The site name can contain only letters, digits, hyphens (-), and underscores (_), and cannot start with a hyphen (-). Use "->" to determine the networking. No exception occurs.
- Set the owner and execute permission of the self-defined execution script.
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.
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.
- Log in to the DR management server, place the self-defined execution script in a specified path.
- Test, cleanup, planned migration, fault recovery, reprotection, and backup restoration are performed on hosts or host groups:
- log in to the service host where the protected object resides and obtain the script template for self-defining the execution script.
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).
- 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/sbin/thirdparty/sample and the script sample name is sample.sh.
- Place the self-defined execution script in a specified path.
- In Windows: the path is %OceanStor BCManager Agent install path%\bin\thirdparty\
- In Linux/UNIX: the path is /home/rdadmin/Agent/sbin/thirdparty/
- Set the owner and execute permission of the self-defined execution script.
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.
- log in to the service host where the protected object resides and obtain the script template for self-defining the execution script.
- No host or host group is selected for planned migration, fault recovery, reprotection, or backup restoration:
- Enter Step Name and Script Name.
- 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.
- In the right group box, select or deselect Start the step to enable or disable a step and click Apply.
- 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.