Step 1: Create a Protection Group
Scenarios
You can specify two AZs as the source and target AZs, and create a protection group. Then, you can create protected instances and replication pairs in this protection group.
Verify the servers at the production and DR sites before you create a protection group. In this version, only the VPC migration deployment model is supported. Specifically, the servers at the production and DR sites must be in different AZs but in the same VPC.
-
Procedure
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
+Procedure
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
- Click Create Protection Group.
The Create Protection Group page is displayed.
Figure 2 Creating a protection group
- Configure the basic information about the protection group listed in Table 1.
All the parameters in the following table are mandatory.
diff --git a/docs/sdrs/umn/en-us_topic_0108560208.html b/docs/sdrs/umn/en-us_topic_0108560208.html index fb6d6d379..c3d812e62 100644 --- a/docs/sdrs/umn/en-us_topic_0108560208.html +++ b/docs/sdrs/umn/en-us_topic_0108560208.html @@ -9,9 +9,9 @@Figure 1 Performing a failover
-Notes
For Linux servers with Cloud-Init installed, if you have changed hostname of the production site server before you perform a failover for the first time, this modification will not synchronize to the DR site server.
-To resolve this problem, see What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Planned Failover or Failover?
+To resolve this problem, see What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Switchover or Failover?
-Prerequisites
- You have confirmed with customer service that the servers and disks at the production site are faulty, and the deployed services are unavailable.
- The protection group has replication pairs.
- Protection is enabled for the protection group, and the protection group is in the Protecting, Planned failover failed, or Failover failed state.
Prerequisites
- You have confirmed with customer service that the servers and disks at the production site are faulty, and the deployed services are unavailable.
- The protection group has replication pairs.
- Protection is enabled for the protection group, and the protection group is in the Protecting, Switchover failed, or Failover failed state.
Procedure
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
- In the pane of the desired protection group, click Protected Instances.
The operation page for the protection group is displayed.
@@ -21,7 +21,7 @@
Related Operations
- After the failover is complete, the status of the protection group changes to Failover complete. Then, you need to switch to the protected instance details page and start the DR site server.
- After the failover is complete, the protection group is in the Protection disabled state. You need to enable protection again to start data synchronization. For details, see Performing Reprotection.
- After the failover is complete, the NIC and IP address information of the servers at the DR site (original production site) will not be displayed. For details, see Why NICs of DR Site Servers Are Not Displayed After I Perform a Failover?
Related Operations
- After the failover is complete, the status of the protection group changes to Failover complete. Then, you need to switch to the protected instance details page and manually start the DR site server.
- After the failover is complete, the protection group is in the Protection disabled state. You need to enable protection again to start data synchronization. For details, see Performing Reprotection.
- After the failover is complete, the NIC and IP address information of the servers at the DR site (original production site) will not be displayed. For details, see Why NICs of DR Site Servers Are Not Displayed After I Perform a Failover?
diff --git a/docs/sdrs/umn/en-us_topic_0109956554.html b/docs/sdrs/umn/en-us_topic_0109956554.html index 8284dded9..8d384d980 100644 --- a/docs/sdrs/umn/en-us_topic_0109956554.html +++ b/docs/sdrs/umn/en-us_topic_0109956554.html @@ -1,7 +1,7 @@What Are the Differences Between DR and Backup?
-Differences between disaster recovery (DR) and backup are as follows:- DR is used to prevent impacts on the systems caused by natural disasters, such as fires and earthquakes. A production site and its DR site must be located with a certain secure distance. Backup is to prevent impacts on the systems caused by inappropriate manual operations, virus infection, and logic errors. It is used to restore the service system data. Usually, a system and its backup are deployed in the same data center.
- A DR system protects data but more focuses on protecting service continuity. A data backup system only ensures that data generated at different time points can be restored. Generally, the system performs the full backup for the first time, which takes a long period of time. The subsequent backup is incremental and can be completed within a short period of time.
- The highest DR standard is to implement zero RPO. You can set a maximum of 24 automatic backup policies at different time points in one day to restore data to different backup points.
- If a disaster occurs, such as earthquakes or fires, a DR system takes only several minutes to perform a failover, but a backup system takes several hours or even dozens of hours to restore the data.
Differences between disaster recovery (DR) and backup are as follows:- DR is used to prevent impacts on the systems caused by natural disasters, such as fires and earthquakes. A production site and its DR site must be located with a certain secure distance. Backup is to prevent impacts on the systems caused by inappropriate manual operations, virus infection, and logic errors. It is used to restore the service system data. Usually, a system and its backup are deployed in the same data center.
- A DR system protects data but focuses more on protecting service continuity. A data backup system only ensures that data generated at different time points can be restored. Generally, the system performs the full backup for the first time, which takes a long period of time. The subsequent backup is incremental and can be completed within a short period of time.
- The highest DR standard is to implement zero RPO. You can set a maximum of 24 automatic backup policies at different time points in one day to restore data to different backup points.
- If a disaster occurs, such as earthquakes or fires, a DR system takes only several minutes to perform a failover, but a backup system takes several hours or even dozens of hours to restore the data.
diff --git a/docs/sdrs/umn/en-us_topic_0110037558.html b/docs/sdrs/umn/en-us_topic_0110037558.html index a8497d0a5..35911e363 100644 --- a/docs/sdrs/umn/en-us_topic_0110037558.html +++ b/docs/sdrs/umn/en-us_topic_0110037558.html @@ -3,7 +3,7 @@Step 2: Create a Protected Instance
Scenarios
You can create protected instances using the servers that you want to perform DR protection. If the current production site encounters an unexpected large-scale server failure, you can call the related protection group API to perform a failover, ensuring that services running on protected instances are not affected.
Select a protection group for each server to be replicated and create a protected instance using the server. When you create a protected instance, the server and disk will be created at the DR site for the production site server and disk. The server specifications can be configured as required. Specifically, the specifications of the DR site server can be different from those of the production site server. The disks of the production site and DR site are of the same specifications and can automatically form a replication pair.
-The server at the DR site is in the Stopped state after the protected instance created. These automatically created resources, including the DR site servers and disks, cannot be used before a planned failover or failover.
+The server at the DR site is in the Stopped state after the protected instance created. These automatically created resources, including the DR site servers and disks, cannot be used before a switchover or failover.
Figure 1 Creating a protected instance
Notes
- If a production site server has been added to an ECS group, you are not allowed to specify a DeH to create the DR site server for the production site server.
- When a protected instance is created, the default name of the server at the DR site is the same as that of the server at the production site, but their IDs are different.
- To modify a server name, switch to the protected instance details page and click the server name to switch to the server details page.
- After you create a protected instance and enable protection for the protection group, modifications to the Hostname, Name, Agency, ECS Group, Security Group, Tags, and Auto Recovery configurations of the production site server will not synchronize to the DR site server. You can log in to the management console and manually add the configuration items to the servers at the DR site.
- If protection is enabled for servers created during capacity expansion of an Auto Scaling (AS) group, these servers cannot be deleted when the capacity of the AS group is reduced.
- If the server at the production site runs Windows and you choose the key login mode, ensure that the key pair of the server exists when you create a protected instance. Otherwise, the server at the DR site may fail to create, causing the protected instance creation failure.
If the key pair of the server at the production site has been deleted, create a key pair with the same name.
diff --git a/docs/sdrs/umn/en-us_topic_0110037559.html b/docs/sdrs/umn/en-us_topic_0110037559.html index b39e73f4a..9a6914d48 100644 --- a/docs/sdrs/umn/en-us_topic_0110037559.html +++ b/docs/sdrs/umn/en-us_topic_0110037559.html @@ -14,11 +14,11 @@- On the Replication Pairs tab, click Create Replication Pair.
The Create Replication Pair page is displayed.
Figure 1 Creating a replication pair
- Configure the basic information about the replication pair listed in Table 1.
-
Table 1 Parameter description Parameter
+Table 1 Parameter description Parameter
Description
+Description
Example Value
+Example Value
Step 3: Enable Protection
Scenarios
If you want to enable protection for all resources in a specified protection group, you can perform steps provided in this section.
-When data is written to the disks of the production site server, SDRS synchronizes the data to the disks of the DR site server in real time. Both the production site and DR site can use Cloud Server Backup Service (CSBS) and Volume Backup Service (VBS) to back up the servers and disks.
+When data is written to the disks of the production site server, SDRS synchronizes the data to the disks of the DR site server in real time. Both the production site and DR site can use Cloud Server Backup Service (CSBS) and Volume Backup Service (VBS) to back up the servers and disks.
Figure 1 Enabling protection
Prerequisites
- The protection group has replication pairs.
- The protection group is in the Available or Enabling protection failed state.
- After you create a protected instance and enable protection on servers at the production site, modifications to the Hostname, Name, Security Group, Agency, ECS Group, Tags, and Auto Recovery configurations of servers on the production site will not synchronize to the servers at the DR site. You can manually add the configuration items to the servers at the DR site on the management console.
Modifying Specifications of a Protected Instance - - +Modifying Specifications of a Protected Instance
-Scenarios
If the specifications of an existing protected instance cannot meet the service requirements, you can perform steps provided in this section to modify the server specifications, including the vCPU and memory.
The following scenarios may involve:
- Modifying the specifications of both the production and DR site servers
- Modifying the specifications of the production site server only
- Modifying the specifications of the DR site server only
Prerequisites
- The protection group is in the Available or Protecting state.
- The protected instance is in the Available, Protecting, or Modifying specifications failed.
- Servers of which the specifications to be modified are stopped.
-Prerequisites
- The protection group is in the Available or Protecting state.
- The protected instance is in the Available, Protecting, or Modifying specifications failed.
- Servers of which the specifications to be modified are stopped.
- - \ No newline at end of file + diff --git a/docs/sdrs/umn/en-us_topic_0110981899.html b/docs/sdrs/umn/en-us_topic_0110981899.html index af6d55b35..bf83eb866 100644 --- a/docs/sdrs/umn/en-us_topic_0110981899.html +++ b/docs/sdrs/umn/en-us_topic_0110981899.html @@ -12,7 +12,7 @@Procedure
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
+Procedure
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
- In the pane of the protection group for which the protected instance specifications are to be modified, click Protected Instances.
The operation page for the protection group is displayed.
- - On the Protected Instances tab, locate the row containing the target protected instance, click More in the Operation column, and choose Modify Production Site Server Specifications or Modify DR Site Server Specifications from the drop-down list. Figure 1 Modifying specifications-
- In the displayed dialog box, select new server type, vCPU, and memory specifications.
- (Optional) If you need to modify the specifications of both the production site server and DR site server, select Modify the specifications of both the production and DR site servers. After you select this item, the system will modify the specifications of both the production site server and DR site server to the same specifications.Figure 2 Modifying the specifications of both the production site server and DR site server+
- On the Protected Instances tab, locate the row containing the target protected instance, click More in the Operation column, and choose Modify Production Site Server Specifications or Modify DR Site Server Specifications from the drop-down list. Figure 1 Modifying specifications+
- In the displayed dialog box, select new server type, vCPU, and memory specifications.
- (Optional) If you need to modify the specifications of both the production site server and DR site server, select Modify the specifications of both the production and DR site servers. After you select this item, the system will modify the specifications of both the production site server and DR site server to the same specifications.Figure 2 Modifying the specifications of both the production site server and DR site server
This item is deselected by default, indicating that the system modifies the specifications of only the production site server or DR site server.
- Click OK.
To ensure proper server running, do not perform any operations to the servers during specification modifications.
@@ -49,5 +22,4 @@Parent topic: Managing Protected Instances
Computing
Constraints on server types:
-- x86 ECSs with GPU-accelerated and FPGA-accelerated types are not supported.
+- GPU-accelerated, FPGA-accelerated, and C6 ECSs are not supported.
- Kunpeng ECSs are not supported.
- x86 ECSs with GPU-accelerated and FPGA-accelerated types are not supported.
- If the AZ of the production site becomes faulty, you can use the DR drill function to restore the server services in the AZ.
Restrictions on Logging In to a Server After You Perform a Planned Failover, Failover, or DR Drill for the First Time
- For servers with Cloud-Init/Cloudbase-Init installed, after you perform a planned failover, failover, or DR drill for the first time, Cloud-Init/Cloudbase-Init will start when the servers start for the first time to inject the initial data. The password or key pair for logging in to the production site server, DR site server, or DR drill server will change.
- For servers without Cloud-Init/Cloudbase-Init installed, the password or key pair for logging in to the production site, DR site server, or DR drill server will not change after you perform a planned failover or failover for the first time.
The following describes an example of server login restrictions after you perform a planned failover or failover for the first time. For details about the login restrictions for the DR drill server, see the login restrictions for the DR site server in this scenario.
-Server A and server B are deployed. After the first time planned failover or failover, the production site server and DR site server are listed in Table 2.
+Constraints on Logging In to the Server After a Switchover, Failover, or DR Drill Is Executed First Time Ever
After you have performed a switchover, failover, or DR drill for the first time:
+If your servers are installed with Cloud-Init/Cloudbase-Init, Cloud-Init/Cloudbase-Init will start along with the server's first startup to inject the initial data. In this case, the password or key pair used to log in to the production site server, DR site server, or drill server will change.
+If your servers are not installed with Cloud-Init/Cloudbase-Init, the password or key pair used to log in to the production site server, DR site server, or drill server will not change.
+
The following uses a switchover or failover as the example operation. For the login constraints on drill servers, see those for DR site servers.
+In the following example, Server A and server B are deployed. Table 2 shows the servers before and after the operation.
-Table 2 Production site and DR site servers after a planned failover or failover N/A
+-Table 2 Servers before and after a switchover or failover N/A
Production Site Server
In this case, the detailed login restrictions are as follows:
-Scenario 1: Server A runs Windows and does not have Cloudbase-Init installed. After the first time planned failover or failover:- If you choose to use a password for the server login, use the password of server A to log in to the production site server B or DR site server A.
- If you choose to use a key pair for the server login, use the password obtained from server A to log in to the production site server B or DR site server A.
From the second time planned failover or failover, the login password or key pair of the server without Cloudbase-Init installed will remain the same. Take servers listed in Table 2 as an example.
-You can use the password of server A to log in to the production site server or DR site server.
+Detailed login constraints are described as follows:
+Scenario 1: Server A runs Windows and does not have Cloudbase-Init installed. After the first time switchover or failover:-- If your servers use password for login, you can use the password of Server A to log in to the production site server (Server B) or DR site server (Server A).
- If your servers use key pair for login, you can use the obtained password of Server A to log in to the production site server (Server B) or DR site server (Server A).
After the first time switchover or failover, the password or key pair remains the same for the subsequent switchovers or failovers. Take servers listed in Table 2 as an example.
+You can use the password of Server A to log in to the production site server or DR site server.
Scenario 2: Server A runs Windows and already has Cloudbase-Init installed. After the first time planned failover or failover:- If you choose to use a password for the server login, check whether Cloudbase-Init is started.
If Cloudbase-Init is not started (normally within three to five minutes after the production site server starts), you can use the password of server B for the login.
-After the Cloudbase-Init is started, the login password of server B set before the planned failover or failover becomes invalid. You need to reset the login password of server B and then use the new password to log in to server B.
- - If you choose to use a key pair for the server login, check whether Cloudbase-Init is started.
If Cloudbase-Init is not started (normally within three to five minutes after the production site server starts), you can use the password of server B for the login.
-After the Cloudbase-Init is started, the login password of server B obtained before the planned failover or failover becomes invalid. You need to obtain the login password of server B again.
+Scenario 2: Server A runs Windows and already has Cloudbase-Init installed. After the first time switchover or failover:- When your servers use password for login,
If Cloudbase-Init is not started (normally within 3 to 5 minutes after the production site server starts), you can use the password of Server B for login.
+After Cloudbase-Init is started, the login password of Server B becomes invalid. Reset the password and use the new password for login.
+ - When your servers use key pair for login,
If Cloudbase-Init is not started (normally within 3 to 5 minutes after the production site server starts), you can use the obtained login password of Server B for login.
+After Cloudbase-Init is started, the obtained login password of Server B becomes invalid. Obtain the password again.
- -From the second time planned failover or failover, the login password or key pair of the server with Cloudbase-Init installed will remain the same. Take servers listed in Table 2 as an example.
-- Login using a password: Reset the password of server B and use the new password to log in to server B after the first time planned failover or failover.
- Login using a key pair: Obtain the password of server B and use the obtained password to log in to server B after the first time planned failover or failover.
After the first time switchover or failover, the password or key pair remains the same for the subsequent switchovers or failovers. Take servers listed in Table 2 as an example.
+- Login using a password: Reset the password of Server B and use the new password for login.
- Login using a key pair: Obtain the password of Server B again and use the obtained password to log in to Server B.
Scenario 3: Server A runs Linux. After the first time planned failover or failover:- If you choose to use a password for the server login, use the password of server A to log in to the production site server B or DR site server A.
If the login password of server A is not changed before the planned failover or failover, use the login password configured when server A is created after the planned failover or failover.
-If the login password of server A is changed before the planned failover or failover, use the new login password after the planned failover or failover.diff --git a/docs/sdrs/umn/en-us_topic_0122528555.html b/docs/sdrs/umn/en-us_topic_0122528555.html index b4c441a48..fd64e5cf2 100644 --- a/docs/sdrs/umn/en-us_topic_0122528555.html +++ b/docs/sdrs/umn/en-us_topic_0122528555.html @@ -13,7 +13,7 @@ For ECSs running OSs other than CoreOS, the login password does not change after the first-time planned failover or failover.
-For ECSs running CoreOS, the login password of server A will restore to the initial one after the first-time planned failover or failover. Therefore, you need to use the login password configured when server A is created to log in to production site server A or DR site server B.
+Scenario 3: Server A runs Linux. After the first time switchover or failover:- If your servers use password for login, you can use the password of Server A to log in to the production site server (Server B) or disaster recovery site server (Server A). Specifically:
If the login password of Server A is not changed before the operation, use this password for login.
+If the login password of server A has been changed before the operation, use the new password for login.- For ECS OSs other than CoreOS, the login password does not change after the first time switchover or failover.
+For ECSs running CoreOS, the login password of Server A will restore to the initial one after the first time switchover or failover. In this case, use the login password configured when Server A is created to log in to production site Server A or DR site Server B.
- If you choose to use a key pair for the server login, use the key pair of server A to log in to the production site server B or DR site server A in SSH mode.
- If your server uses key pair for login, use the SSH key pair of Server A to log in to production site Server B or DR site Server A.
- If your servers use password for login, you can use the password of Server A to log in to the production site server (Server B) or disaster recovery site server (Server A). Specifically:
- When you create a DR drill, if the DR site server runs Linux and uses the key login mode, the key pair information will not be displayed on the details page of the DR drill server after the DR drill server is created. You can use the key pair of the DR site server to log in to the DR drill server.
- After you create a DR drill, modifications to the Hostname, Name, Agency, ECS Group, Security Group, Tags, and Auto Recovery configurations of the DR site server before the drill will not synchronize to the DR drill server. You can log in to the management console and manually add the configuration items to the drill server.
- If the synchronization progress of replication pairs in the protection group is not 100%, the created DR drill server may fail to start. You are advised to perform a DR drill after all replication pairs are synchronized.
Prerequisites
- The protection group is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Planned failover failed, Re-enabling protection failed, or Failover failed state.
- Do not perform a DR drill before the first time data synchronization between the production site server and DR site server completes. Otherwise, the drill server may not start properly.
Prerequisites
- The protection group is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Switchover failed, Re-enabling protection failed, or Failover failed state.
- Do not perform a DR drill before the first time data synchronization between the production site server and DR site server completes. Otherwise, the drill server may not start properly.
Procedure
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
- In the pane of the protection group to which a DR drill is to be added, click DR Drills.
The operation page for the protection group is displayed.
diff --git a/docs/sdrs/umn/en-us_topic_0288665269.html b/docs/sdrs/umn/en-us_topic_0288665269.html index d0e71ad3d..d11d04751 100644 --- a/docs/sdrs/umn/en-us_topic_0288665269.html +++ b/docs/sdrs/umn/en-us_topic_0288665269.html @@ -1,196 +1,173 @@ - - - - - - - - - - - - - - - - - - - - - - - -Change History - - +Change History
-Released On
+- - - \ No newline at end of file + diff --git a/docs/sdrs/umn/public_sys-resources/icon-arrowdn.gif b/docs/sdrs/umn/public_sys-resources/icon-arrowdn.gif index 84eec9be2..379428032 100644 Binary files a/docs/sdrs/umn/public_sys-resources/icon-arrowdn.gif and b/docs/sdrs/umn/public_sys-resources/icon-arrowdn.gif differ diff --git a/docs/sdrs/umn/public_sys-resources/icon-arrowrt.gif b/docs/sdrs/umn/public_sys-resources/icon-arrowrt.gif index 39583d168..6aaaa11c2 100644 Binary files a/docs/sdrs/umn/public_sys-resources/icon-arrowrt.gif and b/docs/sdrs/umn/public_sys-resources/icon-arrowrt.gif differ diff --git a/docs/sdrs/umn/sdrs_06_0400.html b/docs/sdrs/umn/sdrs_06_0400.html index e16d67314..8cda7a67e 100644 --- a/docs/sdrs/umn/sdrs_06_0400.html +++ b/docs/sdrs/umn/sdrs_06_0400.html @@ -12,11 +12,11 @@Released On
Description
+Description
2024-09-20
+2025-10-20
Optimized some descriptions.
+Optimized some descriptions.
2023-10-20
+2024-09-20
Optimized some descriptions.
+Optimized some descriptions.
2022-08-31
+2023-10-20
Deleted parameter descriptions related to yearly/monthly billing.
+Optimized some descriptions.
2021-11-17
+2022-08-31
Modified the following content:
-Added a note in What Are the Precautions If the Production Site Server Uses the Key Login Mode?
+Deleted the yearly/monthly billing from corresponding parameter descriptions.
2019-11-19
+2021-11-17
Modified the following content:
-- Added a parameter example in Disaster Recovery Drill.
- Added a parameter example in Creating a Replication Pair.
Modified the following content:
+Added a note in What Are the Precautions If I Log In to the Production Site Server Using a Key Pair?.
2019-09-10
+2019-11-19
Modified the following content:
-Modified the table heading and parameter example in Managing Protected Instance Tags.
+Modified the following content:
+- Added a parameter example in Performing a DR Drill.
- Added a parameter example in Creating a Replication Pair.
2019-08-29
+2019-09-10
Added the following content:
-- Added the tag function in Managing Protected Instance Tags.
- What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Switchover or Failover?
Modified the following content:
-- Modified Enable Protection Again to Reprotect in Performing Reprotection.
- Deleted the restriction that the specifications of the DR site server must be consistent with those of the production site server in SDRS Usage Restrictions.
Modified the following content:
+Modified the table heading and parameter example in Managing Protected Instance Tags.
2019-06-10
+2019-08-29
Accepted for RM-487 and RM-351.
+Added the following content:
+- Added the tag function in Managing Protected Instance Tags.
- What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Switchover or Failover?
Modified the following content:
+- Modified Enable Protection Again to Reprotect in Performing Reprotection.
- Deleted the restriction that the specifications of the DR site server must be consistent with those of the production site server in Constraints.
2019-06-05
+2019-06-10
Modified the following content:
-- Added scenario diagrams in Supported DR Scenarios.
Accepted for RM-487 and RM-351.
2019-05-24
+2019-06-05
Added the following content:
- -Modified the following content:
-- Modified the scenario descriptions in Modifying Specifications of a Protected Instance.
- Added scenario descriptions in Disaster Recovery Drill.
Modified the following content:
+- Added scenario diagrams in Supported DR Scenarios.
2019-05-09
+2019-05-24
Deleted the following content:
-- What Are the Standards of DR?
- What Can I Do If an Error Occurred When I Expand the Replica Pair Capacity?
- What Can I Do When My Protection Group Quotas Are Insufficient?
Modified the following content:
-- Added a note in Disaster Recovery Drill.
- Adjusted the structure in Management.
- Optimized descriptions in Modifying Specifications of a Protected Instance.
- Replaced screenshots in Deleting a Replication Pair.
Added the following content:
+ +Modified the following content:
+- Modified the scenario descriptions in Modifying Specifications of a Protected Instance.
- Added scenario descriptions in Performing a DR Drill.
2019-04-17
+2019-05-09
Modified the following content:
-- Modified the description in section "Compatible Applications and Versions."
- Deleted the description of the scenario and modified the prerequisites in Step 2: Create Protected Instances.
- Modified the description of the scenario and prerequisites in Disaster Recovery Drill.
- Added a note in Deleting a DR Drill.
Deleted the following content:
+- What Are the Standards of DR?
- What Can I Do If an Error Occurred When I Expand the Replication Pair Capacity?
- What Can I Do When My Protection Group Quotas Are Insufficient?
Modified the following content:
+- Added a note in Performing a DR Drill.
- Adjusted the structure in Management.
- Optimized descriptions in Modifying Specifications of a Protected Instance.
- Replaced screenshots in Deleting a Replication Pair.
2019-03-30
+2019-04-17
Added the following content:
-- Section "SDRS Compatible Applications and Versions"
- Descriptions of the DR drill function in Disaster Recovery Drill.
- Managing DR Drills
- What Can I Do If the NIC Names of the DR Drill Server and Production Site Server Are Different?
Modified the following content:
-- Modified descriptions of modifying the specifications of the production site server and DR site server in Modifying Specifications of a Protected Instance.
- Deleted concepts of the source end, target end, preferred end, and added the concepts of the production site and DR site.
Deleted the following content:
-- Section "Performing a Switchback"
- Section "Performing a Failback"
Modified the following content:
+- Modified the description in section "Compatible Applications and Versions."
- Deleted the description of the scenario and modified the prerequisites in Step 2: Create a Protected Instance.
- Modified the description of the scenario and prerequisites in Performing a DR Drill.
- Added a note in Deleting a DR Drill.
2018-11-08
+2019-03-30
Added the following content: +Added the following content:
+- Section "Compatible Applications and Versions"
- Descriptions of the DR drill function in Performing a DR Drill.
- Managing DR Drills
- What Can I Do If the NIC Names of the DR Drill Server and Production Site Server Are Different?
Modified the following content:
+- Modified descriptions of modifying the specifications of the production site server and DR site server in Modifying Specifications of a Protected Instance.
- Deleted concepts of the source end, target end, preferred end, and added the concepts of the production site and DR site.
Deleted the following content:
+- Section "Performing a Planned Failback"
- Section "Performing a Failback"
2018-11-08
+Added the following content:2018-11-07
+2018-11-07
Accepted in OTC 3.2
+Accepted in OTC 3.2
2018-10-27
+2018-10-27
Added the following content:
-A note in Creating a Replication Pair
-Modified the following content:
-- Note descriptions in Performing a Switchover
- Note descriptions in Expanding Capacity of a Replication Pair
Added the following content:
+A note in Creating a Replication Pair
+Modified the following content:
+- Note descriptions in Performing a Switchover
- Note descriptions in Expanding Replication Pair Capacity
2018-10-23
+2018-10-23
Added the following content:
-- Example scenarios in section SDRS Application Scenarios
- A note in Step 2: Create Protected Instances
- A note in Detaching a Replication Pair
- A note in Expanding Capacity of a Replication Pair
Modified the following content:
-- Descriptions in Performing a Switchover
- A note in Performing a Failover
Added the following content:
+- A usage example in Application Scenarios
- A note in Step 2: Create a Protected Instance
- A note in Detaching a Replication Pair
- A note in Expanding Replication Pair Capacity
Modified the following content:
+- A note in Performing a Switchover
- A note in Performing a Failover
2018-09-29
+2018-09-29
Modified the following content:
-Prerequisites in Expanding Capacity of a Replication Pair
+Modified the following content:
+Prerequisites in Expanding Replication Pair Capacity
2018-09-25
+2018-09-25
Added the following content:
-- A note in Configuration Process
- A prerequisite in Detaching a Replication Pair
Added the following content:
+- A note in Configuration Process
- A prerequisite in Detaching a Replication Pair
2018-09-11
+2018-09-11
Added the following content:
-- Figure in Performing a Switchover
- Screenshots in Step 1: Create a Protection Group, Step 2: Create Protected Instances, Modifying Specifications of a Protected Instance, Deleting a Protected Instance, Attaching a Replication Pair, and Detaching a Replication Pair
- A note in Deleting a Replication Pair
- A note in Performing a Failover
Added the following content:
+- The figure in Performing a Switchover
- Screenshots in Step 1: Create a Protection Group, Step 2: Create a Protected Instance, Modifying Specifications of a Protected Instance, Deleting a Protected Instance, Attaching a Replication Pair, and Detaching a Replication Pair
- A note in Deleting a Replication Pair
- A note in Performing a Failover
2018-09-03
+2018-09-03
Added the following content:
-- SDRS Application Scenarios
- A limitation in Step 2: Create Protected Instances
Modified the following content:
- - -Deleted the following content:
-- Section "Adding a NIC"
- Section "Deleting a NIC"
Added the following content:
+- Application Scenarios
- A limitation in Step 2: Create a Protected Instance
Modified the following content:
+ + +Deleted the following content:
+- Section "Adding a NIC"
- Section "Deleting a NIC"
2018-08-08
+2018-08-08
Modified the following content:
- +Modified the following content:
+2018-06-30
+2018-06-30
This issue is the first official release.
+This issue is the first official release.
- What Are the Differences Between DR and Backup?
-
- What Can I Do When the EIP Cannot Be Pinged After I Perform a Planned Failover for a Protection Group Containing a SUSE Server?
+- What Can I Do When the EIP Cannot Be Pinged After I Perform a Switchover for a Protection Group Containing a SUSE Server?
- What Can I Do If the NIC Names of the DR Drill Server and Production Site Server Are Different?
-
- What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Planned Failover or Failover?
+- What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Switchover or Failover?
- Why NICs of DR Site Servers Are Not Displayed After I Perform a Failover?
diff --git a/docs/sdrs/umn/sdrs_06_0402.html b/docs/sdrs/umn/sdrs_06_0402.html index 60727835a..961e6e5ef 100644 --- a/docs/sdrs/umn/sdrs_06_0402.html +++ b/docs/sdrs/umn/sdrs_06_0402.html @@ -1,11 +1,11 @@ -
What Can I Do When the EIP Cannot Be Pinged After I Perform a Planned Failover for a Protection Group Containing a SUSE Server?
-Symptom
The production site server in a protection group runs the SUSE OS. After users enable protection and perform a planned failover for the protection group, the EIP of the server cannot be pinged.
+What Can I Do When the EIP Cannot Be Pinged After I Perform a Switchover for a Protection Group Containing a SUSE Server?
+-Symptom
The production site server in a protection group runs the SUSE OS. After users enable protection and perform a switchover for the protection group, the EIP of the server cannot be pinged.
Root Cause
After the planned failover, the server NIC name may already change. If the NIC has an EIP bound, the EIP cannot be pinged.
+-Root Cause
After the switchover, the server NIC name may already change. If the NIC has an EIP bound, the EIP cannot be pinged.
Handling Method
After the planned failover, delete the /etc/udev/rules.d/70-persistent-net.rules file on the DR site server and then restart it. The procedure is as follows.
+Handling Method
After the switchover, delete the /etc/udev/rules.d/70-persistent-net.rules file on the DR site server and then restart it. The procedure is as follows.
- Log in to the DR site server.
- Log in to the management console and click Elastic Cloud Server under Computing.
- In the server list, select the DR site server.
- Locate the row containing the server and click Remote Login in the Operation column.
Log in to the server as prompted.
- Run the following command to delete the file:
rm /etc/udev/rules.d/70-persistent-net.rules
diff --git a/docs/sdrs/umn/sdrs_06_0404.html b/docs/sdrs/umn/sdrs_06_0404.html index a62537387..1391e85d5 100644 --- a/docs/sdrs/umn/sdrs_06_0404.html +++ b/docs/sdrs/umn/sdrs_06_0404.html @@ -1,20 +1,20 @@ -What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Planned Failover or Failover?
-Symptom
Users have changed hostname of the production site server before they perform a planned failover or failover for the first time. After the planned failover or failover, users start the DR site server and find that hostname of the DR site server is not updated accordingly.
+What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Switchover or Failover?
+-Symptom
Users have changed hostname of the production site server before they perform a switchover or failover for the first time. After the switchover or failover, users start the DR site server and find that hostname of the DR site server is not updated accordingly.
Possible Causes
For Linux servers, if you have changed hostname of the production site server before you perform a planned failover or failover for the first time, this modification will not synchronize to the DR site server.
+-Possible Causes
For Linux servers, if you have changed hostname of the production site server before you perform a switchover or failover for the first time, this modification will not synchronize to the DR site server.
Prerequisites
- The production site server is a Linux server with Cloud-Init installed.
- hostname of the production site server has been changed.
-Prerequisites
- The production site server is a Linux server with Cloud-Init installed.
- hostname of the production site server has been changed.
Solution 1 (If You Have Not Performed a Planned Failover or Failover)
Set preserve_hostname: false to preserve_hostname: true in the Cloud-Init configuration file /etc/cloud/cloud.cfg to ensure that hostname of the production site server and DR site server are the same after you enable protection.
+Solution 1 (If You Have Not Performed a Switchover or Failover)
Set preserve_hostname: false to preserve_hostname: true in the Cloud-Init configuration file /etc/cloud/cloud.cfg to ensure that hostname of the production site server and DR site server are the same after you enable protection.
The procedure is as follows:
- Log in to the production site server.
- Run the following command to edit the /etc/cloud/cloud.cfg configuration file:
sudo vim /etc/cloud/cloud.cfg
- Modify preserve_hostname.
- If preserve_hostname: false is already available in the /etc/cloud/cloud.cfg configuration file, change it to preserve_hostname: true.
- If preserve_hostname: false is unavailable in the /etc/cloud/cloud.cfg configuration file, add preserve_hostname: true before cloud_init_modules.
- Perform a planned failover or failover.
After the planned failover or failover, hostname of the DR site server and production site server are the same.
+ - Perform a switchover or failover.
After the switchover or failover, hostname of the DR site server and production site server are the same.
Solution 2 (If You Have Performed a Planned Failover or Failover)
If you have not modified configuration file /etc/cloud/cloud.cfg before the planned failover or failover, log in to the DR site server and manually change hostname of the DR site server to that of the production site server.
+Solution 2 (If You Have Performed a Switchover or Failover)
If you have not modified configuration file /etc/cloud/cloud.cfg before the switchover or failover, log in to the DR site server and manually change hostname of the DR site server to that of the production site server.
diff --git a/docs/sdrs/umn/sdrs_06_0410.html b/docs/sdrs/umn/sdrs_06_0410.html index fe299cd39..44414f0c1 100644 --- a/docs/sdrs/umn/sdrs_06_0410.html +++ b/docs/sdrs/umn/sdrs_06_0410.html @@ -1,7 +1,8 @@What Is DR?
-Disaster recovery (DR) is a broad concept. In a broad sense, disaster recovery is a systematic project that includes all contents related to service continuity. Regarding IT, DR provides a computing system that protects user service systems from various disasters. DR is the ability to provide continuous services after an accident, such as a fire, earthquake, or power outage. This is achieved by setting up two or more IT systems with the same functions in dispersed areas. If one system stops, the services can quickly recover on the other system and continue to run properly.
+Disaster recovery (DR) is a broad concept.
+- In a broad sense, DR is a systematic project that includes all abilities related to business continuity. Regarding IT, DR provides a computing system that protects user service systems from various disasters.
- DR is the ability to provide continuous services after an accident, such as a fire, earthquake, or power outage. This is achieved by setting up two or more IT systems with the same functions in dispersed areas. If one system stops, the services can quickly recover on the other system and continue to run properly.
The purpose of DR is to ensure maximum service continuity in the event of a natural or human-caused disaster on production systems.
diff --git a/docs/sdrs/umn/sdrs_06_0430.html b/docs/sdrs/umn/sdrs_06_0430.html index 2205dcacd..900fa068e 100644 --- a/docs/sdrs/umn/sdrs_06_0430.html +++ b/docs/sdrs/umn/sdrs_06_0430.html @@ -2,15 +2,15 @@What Are the Highlights of SDRS?
SDRS provides the following features:
-- Convenient service recovery
SDRS provides a management console. You can configure and manage server replication and perform a planned failover or failover.
+- Convenient service recovery
SDRS provides a management console. You can configure and manage server replication and perform a switchover or failover.
- Server replication
You can establish a replication relationship between the production site and the DR site.
- Replication on demand
You can replicate servers in an AZ to another AZ, thereby reducing the costs and complexity of maintaining another data center.
- Zero impact on applications
Applications running on servers can be replicated, and the replication will not have any impact on the applications.
- - High RTO and RPO standard
For SDRS, recovery time objective (RTO) refers to the period from the time when users perform a planned failover or failover at the production site to the time when the servers at the DR site start to run. This period does not include the time spent on DNS configuration, security group configuration, or customer script execution, and is shorter than 30 minutes.
+ - High RTO and RPO standard
For SDRS, recovery time objective (RTO) refers to the period from when users perform a switchover or failover at the production site to the time when the servers at the DR site start to run. This period does not include the time spent on DNS configuration, security group configuration, or customer script execution, and is shorter than 30 minutes.
SDRS provides continuous and synchronous replication for servers to ensure zero recovery point objective (RPO).
- Crash consistency
Real-time data synchronization based on storage ensures that data synchronized across two AZs maintains crash consistency.
- Seamless DR drills
You can easily perform DR drills without affecting ongoing replication.
- - Flexible failover
You can perform a planned failover for an expected service interruption to prevent data loss, or perform a failover for unexpected failures to restore services quickly.
+ - Flexible failover
You can perform switchovers for expected interruptions with zero data loss, or failovers for unexpected failures to recover services quickly.
- Efficient network switchover
SDRS simplifies program resource management during failovers, including reserving IP addresses and MAC addresses, all of which facilitates efficient network switchovers.
- Cost effectiveness
When services are running properly, servers at the DR site are stopped and thereby will not be billed. This greatly reduces the DR TCO.
What Are RPO and RTO?
Recovery Point Objective (RPO): the maximum data loss amount tolerated by the system.
Recovery Time Objective (RTO): the maximum service interruption duration tolerated by the system. It refers to the requirement for the recovery duration of an information system failure or service function failure caused by a disaster.
-Figure 1 RPO and RTO+
Figure 1 shows an example of RPO and RTO.
+diff --git a/docs/sdrs/umn/sdrs_faq_0004.html b/docs/sdrs/umn/sdrs_faq_0004.html index 2c8ec8ed3..d1198281a 100644 --- a/docs/sdrs/umn/sdrs_faq_0004.html +++ b/docs/sdrs/umn/sdrs_faq_0004.html @@ -1,7 +1,7 @@Why NICs of DR Site Servers Are Not Displayed After I Perform a Failover?
-SDRS performs planned failovers or failovers for protection groups. After a planned failover or failover, the production site and DR site exchange. When the production site is functional, users can perform a planned failover according to plans. When a fault occurs at the production site, users need to perform a failover.- During a planned failover, NICs of the production site servers and DR site servers will exchange. In this way, servers can be accessed using the same IP addresses and MAC addresses after the planned failover.
- During a failover, production site servers do not work properly, NICs of the production site servers will be migrated to the DR site servers. The primary NICs of the DR site servers will enter the to-be-used state. Therefore, after a failover, the original production site servers will not have NICs. When users perform reprotection for the protection group after the original production site servers restore, the primary NICs in the to-be-used state detached from the original DR site servers will be attached to the original production site servers. Then, the NICs of the production site servers and DR site servers are exchanged.
SDRS performs switchovers or failovers for protection groups. After a switchover or failover, the production site and DR site exchange. When the production site is functional, users can perform a switchover according to plans. When a fault occurs at the production site, users need to perform a failover.- During a switchover, NICs of the production site servers and DR site servers will exchange. In this way, servers can be accessed using the same IP addresses and MAC addresses after the switchover.
- During a failover, production site servers do not work properly, NICs of the production site servers will be migrated to the DR site servers. The primary NICs of the DR site servers will enter the to-be-used state. Therefore, after a failover, the original production site servers will not have NICs. When users perform reprotection for the protection group after the original production site servers restore, the primary NICs in the to-be-used state detached from the original DR site servers will be attached to the original production site servers. Then, the NICs of the production site servers and DR site servers are exchanged.
diff --git a/docs/sdrs/umn/sdrs_pro_0000.html b/docs/sdrs/umn/sdrs_pro_0000.html index 6e67b18cf..e2712f393 100644 --- a/docs/sdrs/umn/sdrs_pro_0000.html +++ b/docs/sdrs/umn/sdrs_pro_0000.html @@ -6,7 +6,7 @@-- What Is SDRS?
- - Product Advantages
+ - SDRS Advantages
- Application Scenarios
diff --git a/docs/sdrs/umn/sdrs_pro_0008.html b/docs/sdrs/umn/sdrs_pro_0008.html
index c7c7ff7fa..776ae45ac 100644
--- a/docs/sdrs/umn/sdrs_pro_0008.html
+++ b/docs/sdrs/umn/sdrs_pro_0008.html
@@ -8,12 +8,12 @@
For more information about the DR drill function, see Performing a DR Drill.
DR Site Is Faulty
- Description
The DR site has a fault. Services at the production site are not affected, but the planned failover cannot be performed.
+-DR Site Is Faulty
Replication Link Is Faulty
- Description
The replication link between the production site and DR site becomes faulty. Services at the production site are not affected, but the planned failover cannot be performed.
+-Replication Link Is Faulty
- Description
The replication link between the production site and DR site becomes faulty. Services at the production site are not affected, but a switchover cannot be performed.
Figure 3 Replication link being faulty
- Solution
You do not need to perform any operations. The DR protection will automatically restore once the replication link fault is rectified.
For more information about the failover function, see Performing a Failover.
Storage Resource at the DR Site Is Faulty
- Description
The storage resource at the DR site has a fault. Services at the production site are not affected, but the planned failover or failover cannot be performed.
+Storage Resource at the DR Site Is Faulty
diff --git a/docs/sdrs/umn/sdrs_pro_0012.html b/docs/sdrs/umn/sdrs_pro_0012.html index 8b44fc9a8..5133deb94 100644 --- a/docs/sdrs/umn/sdrs_pro_0012.html +++ b/docs/sdrs/umn/sdrs_pro_0012.html @@ -5,7 +5,7 @@-
-
- SDRS Basic Concepts
+ - SDRS Concepts
- Region and AZ
diff --git a/docs/sdrs/umn/sdrs_pro_0013.html b/docs/sdrs/umn/sdrs_pro_0013.html
index b2e5673cf..1d23187d9 100644
--- a/docs/sdrs/umn/sdrs_pro_0013.html
+++ b/docs/sdrs/umn/sdrs_pro_0013.html
@@ -1,8 +1,8 @@
- - For high DR capability, deploy resources in different AZs within the same region.
- For lower network latency, deploy resources in the same AZ.
- When you create a DR drill, if the DR site server runs Linux and uses the key login mode, the key pair information will not be displayed on the details page of the DR drill server after the DR drill server is created. You can use the key pair of the DR site server to log in to the DR drill server.
- After you create a DR drill, modifications to the Hostname, Name, Agency, ECS Group, Security Group, Tags, and Auto Recovery configurations of the DR site server before the drill will not synchronize to the DR drill server. You can log in to the management console and manually add the configuration items to the drill server.
- If the synchronization progress of replication pairs in the protection group is not 100%, the created DR drill server may fail to start. You are advised to perform a DR drill after all replication pairs are synchronized. -
- The protection group is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Planned failover failed, Re-enabling protection failed, or Failover failed state.
- Do not perform a DR drill before the first time data synchronization between the production site server and DR site server completes. Otherwise, the drill server may not start properly.
- The protection group is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Switchover failed, Re-enabling protection failed, or Failover failed state.
- Do not perform a DR drill before the first time data synchronization between the production site server and DR site server completes. Otherwise, the drill server may not start properly.
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
- In the pane of the protection group to which a DR drill is to be added, click DR Drills.
The operation page for the protection group is displayed.
diff --git a/docs/sdrs/umn/sdrs_ug_pg_0000.html b/docs/sdrs/umn/sdrs_ug_pg_0000.html index cd9aa9135..aee58c768 100644 --- a/docs/sdrs/umn/sdrs_ug_pg_0000.html +++ b/docs/sdrs/umn/sdrs_ug_pg_0000.html @@ -6,7 +6,7 @@- Disabling Protection
- - Performing a Planned Failover
+ - Performing a Switchover
- Performing a Failover
diff --git a/docs/sdrs/umn/sdrs_ug_pg_0002.html b/docs/sdrs/umn/sdrs_ug_pg_0002.html
index d93b3e622..534464f61 100644
--- a/docs/sdrs/umn/sdrs_ug_pg_0002.html
+++ b/docs/sdrs/umn/sdrs_ug_pg_0002.html
@@ -1,9 +1,9 @@
- - Check the status to ensure that all the servers in the protection group are stopped before the planned failover.
- During the planned failover, do not start the servers in the protection group. Otherwise, the planned failover may fail.
- Once a planned failover is complete, data synchronization will not stop, only the synchronization direction will reverse.
- After the planned failover is complete, the status of the protection group changes to Protecting. Then, you need to switch to the protected instance details page and start the production site server.
- Check the status to ensure that all the servers in the protection group are stopped before a switchover.
- During a switchover, do not start the servers in the protection group. Or, the switchover may fail.
- Once a switchover is complete, data synchronization will not stop, only the synchronization direction will reverse.
- Once a switchover is complete, the status of the protection group changes to Protecting. Then, you need to go to the protected instance details page and start the production site server.
- All the servers in the protection group are stopped.
- The protection group has replication pairs.
- Protection is enabled for the protection group, and the protection group is in the Protecting or Planned failover failed state.
- All the servers in the protection group are stopped.
- The protection group has replication pairs.
- Protection is enabled for the protection group, and the protection group is in the Protecting or Switchover failed state.
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
- - In the pane of the desired protection group, click Protected Instances.
- On the operation page of the protection group, click Execute Planned Failover in the upper right corner.
- In the displayed dialog box, check whether all the servers in this protection group are stopped.
- If yes, go to step 6.
- If no, select the servers to be stopped and click Stop.
- In the Execute Planned Failover dialog box, click Execute Planned Failover. diff --git a/docs/sdrs/umn/sdrs_ug_pi_0002.html b/docs/sdrs/umn/sdrs_ug_pi_0002.html index 52e633676..393ac02b3 100644 --- a/docs/sdrs/umn/sdrs_ug_pi_0002.html +++ b/docs/sdrs/umn/sdrs_ug_pi_0002.html @@ -1,43 +1,16 @@ - - - - - - - - - - - - - - - - - - - - - - - - -
During the planned failover, do not start the servers in the protection group. Otherwise, the planned failover may fail.
+- In the pane of the desired protection group, click Protected Instances.
- In the upper right corner of the page, click Execute Switchover.
- In the displayed dialog box, check whether all the servers in this protection group are stopped.
- If yes, go to step 6.
- If no, select the servers to be stopped and click Stop.
- In the displayed dialog box, click Execute Switchover.
During a switchover, do not start the servers in the protection group. Or, the switchover may fail.
Deleting a Protected Instance - - +Deleting a Protected Instance
-Scenarios
If you do not need a protected instance, delete it to cancel the protection relationship between the servers and the protection group.
+-Scenarios
If you do not need a protected instance, you can delete it to cancel the protection relationship between the servers and the protection group.
When you delete a protected instance, the production site server in the protected instance will not be deleted, and services at the production site will not be affected.
Prerequisites
The protected instance is in the Available, Protecting, Failover complete, Creation failed, Enabling protection failed, Disabling protection failed, Switchover failed, Failover failed, Deletion failed, Re-enabling protection failed, Modifying specifications failed, Invalid, or Faulty state.
+-Prerequisites
The protected instance is in the Available, Protecting, Failover complete, Creation failed, Enabling protection failed, Disabling protection failed, Switchover failed, Failover failed, Deletion failed, Re-enabling protection failed, Modifying specifications failed, Invalid, or Faulty state.
- - \ No newline at end of file + diff --git a/docs/sdrs/umn/sdrs_ug_pi_0005.html b/docs/sdrs/umn/sdrs_ug_pi_0005.html index eb2b5bd90..c1ccdd5d8 100644 --- a/docs/sdrs/umn/sdrs_ug_pi_0005.html +++ b/docs/sdrs/umn/sdrs_ug_pi_0005.html @@ -3,7 +3,7 @@Procedure
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
- - In the pane of the protection group for which the protected instance is to be deleted, click Protected Instances.
The protection group details page is displayed.
+Procedure
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
+ - In the pane of the protection group for which the protected instance is to be deleted, click Protected Instances.
The operation page for the protection group is displayed.
- On the Protected Instances tab, locate the row containing the protected instance to be deleted, click More in the Operation column, and choose Delete from the drop-down list.
To delete protected instances in batches, select the target protected instances and click Delete above the protected instance list.
The Delete Protected Instance page is displayed.
-Figure 1 Deleting a protected instance+
Figure 1 Deleting a protected instance
- On the Delete Protected Instance page, select the desired operation.
- If you select Delete DR site server, do not perform any other operations on the DR site server or its related resources when the system is deleting the DR site server.
- Delete DR site server
- If you do not select this option, the protection relationship between the protected instance and protection group will be canceled, but the DR site server and disks attached to the server will be retained.
- If you select this option, the protection relationship between the protected instance and protection group will be canceled, and the DR site server and disks attached to the server will be deleted.
Parent topic: Managing Protected Instances
Detaching a Replication Pair
-Scenarios
You can perform steps provided in this section to detach a replication pair from a protected instance. Then, data of the servers in the protected instance will not be written in to the disks in the replication pair.
Prerequisites
- The protection group is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Planned failover failed, or Failover failed state.
- The protected instance is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Planned failover failed, Failover failed, Deletion failed, Re-enabling protection failed, Modifying specifications failed, Invalid, or Faulty state.
- The replication pair is in the Available, Protecting, Failover complete, Attaching failed, Detaching failed, Enabling protection failed, Disabling protection failed, Planned failover failed, Failover failed, Deletion failed, Re-enabling protection failed, Expansion failed, Invalid, or Faulty state.
- The replication pair has been attached to a protected instance.
- Disks in the In-use state have been attached to the production and DR site servers.
Prerequisites
- The protection group is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Switchover failed, or Failover failed state.
- The protected instance is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Switchover failed, Failover failed, Deletion failed, Re-enabling protection failed, Modifying specifications failed, Invalid, or Faulty state.
- The replication pair is in the Available, Protecting, Failover complete, Attaching failed, Detaching failed, Enabling protection failed, Disabling protection failed, Switchover failed, Failover failed, Deletion failed, Re-enabling protection failed, Expansion failed, Invalid, or Faulty state.
- The replication pair has been attached to a protected instance.
- Disks in the In-use state have been attached to the production and DR site servers.
diff --git a/docs/sdrs/umn/sdrs_ug_rp_0001.html b/docs/sdrs/umn/sdrs_ug_rp_0001.html index cb1d03a81..5d7961360 100644 --- a/docs/sdrs/umn/sdrs_ug_rp_0001.html +++ b/docs/sdrs/umn/sdrs_ug_rp_0001.html @@ -14,11 +14,11 @@ - A system disk (mounted on the /dev/sda or /dev/vda mount point) can be detached from a server only when the server is in the Stopped state. Therefore, stop the server before detaching the system disk.
- A data disk can be detached from a server online or offline, specifically, when the server is in the Stopped or Running state.
For details about how to detach a disk online, see in the Elastic Cloud Server User Guide.
- On the Replication Pairs tab, click Create Replication Pair.
The Create Replication Pair page is displayed.
Figure 1 Creating a replication pair- Configure the basic information about the replication pair listed in Table 1.
-
Table 1 Parameter description Parameter
+Table 1 Parameter description Parameter
Description
+Description
Example Value
+Example Value
-Scenarios
If a replication pair is no longer used, you can release the associated virtual resources by deleting the replication pair from the system.
When you delete a replication pair, the production site disk in the replication pair will not be deleted. You can decide whether to delete the DR site disk.
Prerequisites
- The protection group is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Planned failover failed, Failover failed, Deletion failed, or Re-enabling protection failed state.
- The replication pair is in the Available, Protecting, Failover complete, Creation failed, Enabling protection failed, Disabling protection failed, Planned failover failed, Failover failed, Deletion failed, Re-enabling protection failed, Attaching failed, Expansion failed, Invalid, or Faulty state.
- The replication pair is not attached to any protected instance. For details about how to detach a replication pair, see Detaching a Replication Pair.
Prerequisites
- The protection group is in the Available, Protecting, Failover complete, Enabling protection failed, Disabling protection failed, Switchover failed, Failover failed, Deletion failed, or Re-enabling protection failed state.
- The replication pair is in the Available, Protecting, Failover complete, Creation failed, Enabling protection failed, Disabling protection failed, Switchover failed, Failover failed, Deletion failed, Re-enabling protection failed, Attaching failed, Expansion failed, Invalid, or Faulty state.
- The replication pair is not attached to any protected instance. For details about how to detach a replication pair, see Detaching a Replication Pair.
Procedure
- Log in to the management console.
- Click Service List and choose Storage > Storage Disaster Recovery Service.
The Storage Disaster Recovery Service page is displayed.
- In the pane of the protection group, click Replication Pairs.
The operation page for the protection group is displayed.
Performing a Planned Failover
-Scenarios
After you perform a planned failover, services at the production site are failed over to the DR site, and services at the DR site are failed over to the production site. Table 1 shows the direction change.
+Performing a Switchover
+Scenarios
After you perform a switchover, services at the production site are switched to the DR site, and services at the DR site are switched over to the production site. Table 1 shows the direction change.
-Table 1 DR direction change after a planned failover -
+ -After the planned failover, data synchronization continues, but the DR direction is changed (from the DR site to the production site). You can perform a planned failover when you are certain that the production site will encounter an interruption. For example, if the production site (AZ1) is going to encounter a power failure, you can perform a planned failover to fail over services in AZ1 to the DR site (AZ2). The planned failover will not affect data synchronization of the protection group.
-SDRS will migrate NICs on the server during the planned failover. After the planned failover, the IP, EIP, and MAC addresses of the production site server will be migrated to the DR site server, so that the IP, EIP, and MAC addresses remain the same.
- -After the switchover, data synchronization continues, but the DR direction is changed from the DR site to the production site. You can perform a switchover when you are certain that the production site will encounter an interruption. For example, if the production site (AZ1) is going to encounter a power failure, you can perform a switchover to switch services in AZ1 to the DR site (AZ2). The switchover does not affect data synchronization of the protection group.
+SDRS will migrate NICs on the server during the switchover. Once completed, the IP, EIP, and MAC addresses of the production site server will be migrated to the DR site server, so that the IP, EIP, and MAC addresses remain the same.
+- Figure 1 Performing a planned failover+
Figure 1 Performing a switchoverNotes
For Linux servers with Cloud-Init installed, if you have changed hostname of the production site server before you perform a planned failover for the first time, this modification will not synchronize to the DR site server.
-To resolve this problem, see What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Planned Failover or Failover?
+-Notes
For Linux servers with Cloud-Init installed, if you have changed hostname of the production site server before you perform a switchover for the first time, this modification will not synchronize to the DR site server.
+To resolve this problem, see What Can I Do If hostname of the Production Site Server and DR Site Server Are Different After a Switchover or Failover?
Prerequisites
Prerequisites
Procedure
- Disabling Protection
SDRS Basic Concepts
+SDRS Concepts
-Table 1 SDRS basic concepts Concept
+Table 1 SDRS concepts Concept
Description
Production site
A production site is the data center that independently carries services in normal cases. For SDRS, it is the AZ where your servers locate. This parameter is specified when you create a protection group.
+Data center that independently runs services in normal cases. For SDRS, it is the AZ where your servers locate. This parameter is specified when you create a protection group.
DR site
A DR site is the data center that does not carry services when the production site works properly. It is used to back up data in real time. When the production site fails (planned or unexpected), the DR site can take over the services after a failover. It can reside in the same city as the service management center or in another city.
-In this version, the production and DR sites must be in different AZs in the same region.
+Data center that does not run services when the production site works properly. It is used to back up data in real time. When the production site fails (planned or unexpected), the disaster recovery site can take over services after a switchover or failover. It can reside in the same city as the service management center or in another city.
+The production site and DR site must be in two AZs of a same region.
Protection group
Used to manage a group of servers to be replicated. One protection group is for servers in one VPC. If you have multiple VPCs, you need to create multiple protection groups.
+Manage the servers you want to replicate. One protection group manages servers in one VPC. If you have multiple VPCs, you need to create multiple protection groups.
Protected instance
Indicates a server and its replication server. A protected instance belongs to one protection group. Therefore, the production site and DR site of the protected instance are the same as those of the protected instance's protection group.
+A protected instance consists of one server and its replicated server. One protected instance belongs to one protection group only. The AZs of instance servers are the same as those of the protection group's production site and DR site.
Replication pair
Indicates a disk and its replication disk. A replication pair belongs to one protection group and can be attached to a protected instance in this protection group.
+A replication pair consists of one EVS disk and its replicated disk. One replication pair belongs to one protection group and can be attached to a protected instance in this group.
Planned failover
+Switchover
You can temporarily stop servers at the production site and then perform a planned failover to fail over services from the production site to the DR site. After the planned failover, data synchronization continues, but the DR direction is changed (from the DR site to the production site). Servers and disks at the DR site are ready to start.
+Temporarily stop servers at the production site and switch over services to the DR site for planned outages. After the switchover, data synchronization continues, but the DR direction is changed (from the DR site to the production site). Servers and disks at the DR site are ready to start.
Failover
The system forcibly stops the servers and disks at the production site and sets the servers and disks at the DR site to ready-to-start state. This action affects all the protected instances in the protection group. After the failover, you need to start the servers at the DR site. The protection group status changes to Failover complete, and data synchronization of the protection group stops. You need to enable protection again to restore data synchronization.
+A failover forcibly stops the servers and disks at the production site and sets the servers and disks at the DR site to ready-to-start state. This operation affects all the protected instances in the protection group. After a failover, you need to manually start the servers at the DR site. In addition, the protection group status changes to Failover complete, and data synchronization of the protection group stops. You need to enable reprotection to recover data synchronization.
Enabling protection
This operation can be performed after a protection group is created or data synchronization stops. Once the protection is enabled, the data synchronization starts, and the synchronization progress is displayed on the web page. This operation affects all protected instances and replication pairs in the protection group.
-When you click Enable Protection, the status of the protection group changes to Synchronizing, and Disable Protection is not available.
+Protection can be enabled after a protection group is created or data synchronization stops. Once protection is enabled, data synchronization starts, and you can view the synchronization progress on the console. This operation affects all the protected instances and replication pairs in the protection group.
+After you click Enable Protection, the status of the protection group changes to Synchronizing, and Disable Protection is not available.
Enabling protection again
+Reprotection
This operation can be performed after a failover. Once the protection is enabled again, the data synchronization starts, and the synchronization progress is displayed on the web page. This operation affects all protected instances and replication pairs in the protection group.
-When you click Reprotect after a failover, the status of the protection group changes to Re-protecting, and Disable Protection becomes unavailable.
+Reprotection can be enabled after a failover. Once reprotection is enabled, data synchronization starts, and you can view the synchronization progress on the console. This operation affects all the protected instances and replication pairs in the protection group.
+After you click Reprotect, the status of the protection group changes to Reprotecting, and Disable Protection becomes unavailable.
Disabling protection
@@ -63,60 +63,60 @@Attaching a replication pair to a protected instance
Indicates to attach the two disks in a replication pair to the two servers in a protected instance.
+Attach the two disks in a replication pair to the servers in a protected instance.
Detaching a replication pair from a protected instance
Indicates to detach the two disks in a replication pair from the two servers in a protected instance.
+Detach the two disks in a replication pair from the servers in a protected instance.
DR direction
Indicates the data replication direction. The data replication is from the production site to the DR site when users create a protection group.
-After you perform a planned failover, services at the production site are failed over to the DR site, and services at the DR site are failed over to the production site.
+Data replication direction. After you create a protection group, data is replicated from the production site to the DR site.
+After you perform a switchover, services at the production site are switched to the DR site, and services at the DR site are switched over to the production site.
Protection group status
Indicates the status of a protection group when users perform an operation on the protection group, such as creating or deleting a protection group, enabling or disabling protection, or performing a planned failover or failover.
-For details, see the protection group status section in the Appendixes of Storage Disaster Recovery Service API Reference.
+Status of a protection group, after you create, delete, switch over, fail over, enable protection for, or disable protection for a protection group.
+For details, see section "Protection Group Status" in the Appendixes of Storage Disaster Recovery Service API Reference.
Synchronization status
Indicates the status of the data replication between the production and DR sites.
+Data replication status between the production and DR sites.
VPC
Indicates the VPC of the protection group. A VPC facilitates internal network management and configuration, allowing secure and quick modifications to networks. The servers in the same VPC can communicate with each other, but those in different VPCs cannot communicate with each other by default.
+VPC of the protection group. A VPC facilitates internal network management and configuration, allowing secure and quick modifications to networks. By defaults, servers in the same VPC can communicate with each other, but those in different VPCs cannot.
VBD
Virtual Block Device (VBD) is the default type of disks. Disks of the VBD type support only simple Small Computer System Interface (SCSI) read and write commands. This disk type applies to enterprise office applications as well as development and testing scenarios.
+Virtual Block Device (VBD) is the default disk device type. VBD disks only support basic Small Computer System Interface (SCSI) read/write commands. Such disks are suitable for enterprise office applications as well as development and test environments.
SCSI
SCSI is another disk type. Disks of this type support transparent SCSI command transmission to allow the server OS to directly access the underlying storage media. In addition to simple SCSI read and write commands, SCSI disks also support advanced SCSI commands, for example, persistent lock reservation command, suitable for using the lock mechanism to ensure data security for cluster applications.
+SCSI is another disk device type. SCSI disks support transparent SCSI command transmission, which allows the server OS to directly access the underlying storage media. In addition to basic SCSI read/write commands, SCSI disks support advanced SCSI commands, such as persistent SCSI reservations, which are used for clustered applications to guarantee data security.
RPO
Indicates recovery point objective. It is a service switchover policy, minimizing data loss during DR switchover. The data recovery point is used as the objective to ensure that the data used for DR switchover is the latest backup data.
+Recovery point objective. It is a service switchover policy with minimal data loss. Data recovery points are used as objectives to ensure that the data used for DR switchovers is the latest backup data.
RTO
Indicates recovery time objective. It is the target time on the recovery of interrupted key businesses to an acceptable level. RTO is set to minimize an interruption's impacts on the services. For SDRS, recovery time objective (RTO) refers to the period from the time when users perform a planned failover or failover at the production site to the time when the servers at the DR site start to run. This period does not include the time spent on DNS configuration, security group configuration, or customer script execution, and is within 30 minutes.
+Recovery time objective. It is the target time spent for critical services to recover to an acceptable level. RTO is set to minimize the impacts on the services. For SDRS, RTO refers to the period of time from when you perform a switchover or failover at the production site to the time when the servers at the disaster recovery site start to run. This period does not include the time spent on DNS configuration, security group configuration, or customer script execution, and is within 30 minutes.
DR drill
Is to verify that a DR site server can take over services from a production site server once a failover is performed.
-In DR drills, you can simulate fault recovery scenarios and formulate emergency recovery plans. When a real fault occurs, the plans can be used to quickly recover services, improving service continuity.
+Verify that DR site servers can take over services from production site servers after a failover.
+By running DR drills, you can simulate recovery scenarios and formulate recovery plans. When a fault occurs, you can use the plans to recover services as quickly as possible.
Figure 1 shows the relationship between regions and AZs.
-Selecting a Region
Select a region closest to your target users for lower network latency and quick access.
+Selecting a Region
You are advised to select a region close to you or your target users. This helps ensure low access latency.
-Selecting an AZ
When deploying resources, consider your applications' requirements on disaster recovery (DR) and network latency.
Regions and Endpoints
Before you use an API to call resources, specify its region and endpoint. For more details, see Regions and Endpoints.
+Regions and Endpoints
Before you use an API to call resources, specify its region and endpoint. For more details, see Regions and Endpoints.
diff --git a/docs/sdrs/umn/sdrs_ug_cts_0001.html b/docs/sdrs/umn/sdrs_ug_cts_0001.html index 3e893b9b5..66ddaceca 100644 --- a/docs/sdrs/umn/sdrs_ug_cts_0001.html +++ b/docs/sdrs/umn/sdrs_ug_cts_0001.html @@ -59,7 +59,7 @@failoverProtectionGroup
Performing a planned failover
+Reprotecting a protection group
protectionGroup
Prerequisites
Prerequisites
Procedure
- SDRS Basic Concepts
- Description
- Description
- Convenient service recovery
- When your servers use password for login,
- On the Replication Pairs tab, click Create Replication Pair.
