What Is Cloud Server Disaster Recovery?

Definition

Cloud Server Disaster Recovery (CSDR) provides remote disaster recovery protection for Elastic Cloud Servers (ECSs) and Bare Metal Servers (BMSs). Once the production center encounters a disaster, ECSs and BMSs protected by CSDR can be restored in the remote DR center.

In addition, ECSs and BMSs can be configured with active-active local storage to further guarantee zero data loss and service stoppage.

Table 1 compares characteristics of CSDR with those of traditional DR.

**Table 1** Characteristic comparison between CSDR and traditional DR
Characteristics	CSDR	Traditional DR
Service configuration	GUI-based service application and DR configuration, shortening the service enabling period from a week to half an hour	Login to multiple devices and systems, and several times of configurations, consuming several days
Security and performance	Storage array-based replication, free from agents and occupying no computing resources of ECSs/BMSs Real-time synchronization, ensuring zero data loss	Physical server deployment and agent installation on physical servers, deteriorating performance
Cost effectiveness	On-demand application and allocation and elastic expansion, reducing the initial investment	One-off purchase of DR-dedicated storage, requiring a comparatively high investment

Functions

CSDR functions:

Cross-region DR of ECSs/BMSs
Tenants can apply for CSDR and add multiple ECSs/BMSs to a CSDR service instance to ensure remote replication consistency. Remote replication DR can be implemented in synchronous or asynchronous mode. CSDR can automatically perform scheduled remote replication on arrays according to configured remote replication policies.
DR test of ECSs/BMSs
Tenants can apply for DR tests to verify the data availability in the DR center. DR tests have no impact on the production center.
Planned migration of ECSs/BMSs
In the production center, when a planned power-off (planned power outage, or routine O&M), a DR administrator can perform planned migration of ECSs/BMSs by one click, ensuring zero data loss.
Recovery of ECSs/BMSs in a malfunctioning data center to a remote center
When the production center malfunctions due to a power outage, fire, or another disaster, a DR administrator can perform fault migration on ECSs/BMSs by one click to fast recover ECSs/BMSs to a DR center, minimizing impacts on services.

Figure 1 illustrates the working process of CSDR.

Figure 1 Working process of CSDR

CSDR working process:

Two OpenStack systems are deployed in the local and remote centers respectively and they belong to different regions.
CSDR service instances are created on the production ECSs/BMSs or DR ECSs/BMSs. In normal situations, the production ECSs are running or stopped, the DR ECSs are stopped, the production BMSs are running, and the DR BMSs are running or stopped. Remote replication of data is performed between storage arrays.
DR tests and fault recovery can be performed to ensure service availability.

Restrictions

If multiple ECSs/BMSs are added to the same CSDR service instance, all associated EVS disks must be on the same production storage device.
ECSs/BMSs that mount the same shared disk must be in the same CSDR instance.

You cannot perform DR protection for only some EVS disks of an ECS. If storage active-active protection needs to be canceled for some EVS disks in CSDR instances, EVS disks must be detached from ECSs first. Otherwise, the DR protection cannot be canceled.
After a new EVS disk is attached to the ECS/BMS that has been configured with DR protection, you need to manually add DR protection for the newly attached EVS disk.
When applying for a DR test, configure a gateway IP address for a test NIC on the ECS if the test NIC is used to connect to the test network. In this way, the ECS can be accessed from other network segments.

When creating a CSDR instance, ensure that the production ECS is running or stopped and the DR ECS is stopped. The production BMSs are running, and the DR BMSs are running or stopped.