Storage Disaster Recovery Service

Product Introduction

Issue 09 Date 2021-06-21

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2021. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.

Contents

1 SDRS Introduction...... 1 2 Product Advantages...... 3 3 Application Scenarios...... 5 4 Constraints...... 6 5 Supported OSs...... 8 6 Relationships with Other Services...... 9 7 Pricing Details...... 10 8 Basic Concepts...... 12 8.1 SDRS Basic Concepts...... 12 8.2 Region and AZ...... 15 9 Change History...... 18

1 SDRS Introduction

Storage DR Storage Disaster Recovery Service (SDRS) provides disaster recovery (DR) services for many cloud services, such as Elastic Cloud Server (ECS), Dedicated Distributed Storage Service (DSS) and Elastic Volume Service (EVS). SDRS uses multiple technologies, such as storage replication, data redundancy, and cache acceleration, to provide high data reliability and service continuity for users. SDRS protects service applications by replicating the server data and configurations to a DR site. It allows service applications to start at the DR site in the event that servers at the production site stop. This improves service availability and continuity.

Figure 1-1 Storage DR

DR and Backup Differences between 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.

2 Product Advantages

SDRS has the following advantages: ● Convenient service recovery SDRS provides a management console. You can configure and manage server replication and perform a planned failover 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 as required, 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. ● RPO target SDRS provides continuous and synchronous replication for servers to ensure zero recovery point objective (RPO). ● Crash consistency Storage-based, real-time data synchronization keeps crash consistency for your data across two AZs. Specifically, application data might not be consistent during a failover, but disk data is always consistent. ● 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. ● Efficient network switchover SDRS simplifies program resource management during failovers, including reserving IP addresses and MAC addresses, all of which facilitates efficient network switchovers. ● Excellent performance for the price

When services are running properly, servers at the DR site are stopped and thereby will not be billed. This greatly reduces the DR TCO.

3 Application Scenarios

Cross-AZ DR SDRS uses storage-layer synchronization and replication to provide cross-AZ DR to ensure data crash consistency and server-level protection with zero RPO. If a source AZ encounters a disaster (such as a fire or an earthquake) or a device fault (such as a software or hardware damage), replications running in the source AZ can quickly restore in the target AZ. For users of stateful applications, such as users of Microsoft Office 365, the data of these users must be stored on the disks of the servers with Microsoft Office 365 deployed. For such users, SDRS is suitable.

DR Drill DR drills can be used to simulate fault scenarios, specify the emergency recovery solutions, and verify whether the solutions are applicable and effective. The existing services will not be affected during the DR drill. When a real fault occurs, you can use the solutions to rapidly restore services, enhancing service continuity.

4 Constraints

Before using this service, you should be aware of the limitations listed in Table 4-1.

Table 4-1 Constraints

Constraint Description

Computing Constraints on the instance type ● Kunpeng ECSs are not supported. ● x86 ECSs with GPU-accelerated and FPGA-accelerated types are not supported.

Replication Constraints on servers ● The servers must be from different AZs of the same region. ● Bare Metal Server (BMS) is not supported. ● The following server types cannot be used to create protected instances: – Large Memory (Xen): This type of servers is bound to InfiniBand NICs. – Disk Intensive I (Xen): This type of servers has local disks. – Disk Intensive II (KVM): This type of ECSs has local disks.

Constraints on disks ● Disks which have been used to create replication pairs do not support deletion or data rollback using snapshots.

Storage Only servers using EVS or DSS can use this service.

Application Storage-based synchronous replication ensures disk data consistency but cannot ensure application consistency. If your applications support crash consistency, the applications can run and be replicated on devices supporting replication.

Deployment VPC migration: The servers at the production site and server at model the DR site are in the same VPC. NIC migration and multiple NICs are supported for each server.

Constraint Description

Service Tag Management Service (TMS) is supported only in API mode. interconnecti on

Backup and Only servers at the production site can be backed up and restoration restored. Servers at the DR site can only be backed up.

NO TE

If the AZ of the production site becomes faulty, you can use the DR drill function to restore the server services in the AZ.

Helpful Links What Should I Pay Attention to When Logging In to the Server After the First Time Ever I Executed a Planned Failover, Failover, or Disaster Recovery Drill?

5 Supported OSs

The following tables list the OS versions that have been verified in the lab. The site server running the following OSs supports SDRS.

Table 5-1 Supported OSs OS Type OS Version Bit

Windows Windows Server 2008 R2 64

Windows Server 2012 R2 64

Windows Server 2016 64

Red Hat Red Hat Enterprise Linux 6.10 64

Red Hat Enterprise Linux 7.5 64

CentOS CentOS 6.5 64

CentOS 6.8 64

CentOS 6.9 64

CentOS 7.2 64

CentOS 7.3 64

CentOS 7.4 64

SUSE SUSE Enterprise 12 SP2 64

Ubuntu Ubuntu 16.04 server 64

NO TE

● The OS images are from cloud platform public images. ● Applications and versions listed in Table 5-1 will be continuously updated.

6 Relationships with Other Services

Table 6-1 Relationships with other services Interactive Function Related Service Reference

You can use ECSs to create ECS ● Creating a Protected protected instances in SDRS. Instance

You can use EVS disks to create EVS ● Creating a Replication replication pairs in SDRS. Pair

You can use disks created using DSS ● Creating a Replication the exclusive physical storage Pair resources provided by DSS to create replication pairs in SDRS.

You can select a VPC for VPC ● Creating a Protection protection groups in SDRS. Group

You can use CTS to record SDRS CTS ● Interconnecting with operations for querying, CTS auditing, or backtracking later.

7 Pricing Details

Billing Modes SDRS supports two billing modes: prepayment (yearly/monthly subscription) and postpayment (pay-per-use subscription). ● With regards to prepayment (yearly/monthly subscription), you need to buy a resource package. The resource used is then offset by the quota provided by the resource package. Any subsequent resource that exceeds the quota is billed on a pay-per-use basis. ● With regards to pay-per-use subscription, prepayment is not required. After topping up your HUAWEI CLOUD account, the system determines costs by accurately calculating usage during the past hour. Fees are then deducted from your account balance.

Yearly/Monthly Subscription ● Billing item: resource package Only the ECS resource package is available.

NO TE

● An ECS resource package contains a specified number of ECSs. ● A resource package cannot be used across regions. ● You can purchase a yearly or monthly package and plan your resource quota and duration in advance. The yearly/monthly mode offers more preferences than the pay-per-use mode. – Resource packages are charged a one-time payment. You can choose whether the resource packages take effect immediately upon purchase or on a specified date. – During the validity period of a resource package, if you exceed the resource quota included in the package, you will be billed on a pay-per- use basis for the excess resources used. After a subscription month ends, the resource package resets.

NO TE

For example, you purchase a resource package containing 5 protected instances on 14:00 March third, 2020. The resource package takes effect immediately and has one year validity period. Then, you can use the resource package containing 5 protected instances in each subscription month (from the effective date of this month to the same date of next month), such as from 14:00 March third to 14:00 April third. If you use more than five protected instances, the excess resources used will be billed in pay-per-use mode. If you use less than five protected instances, the unused resources will be reset in next subscription month. – Renewal: If your purchased resource package is about to expire, you can renew the subscription to extend the validity period. The subscription renewal fee depends on the actual renewal duration. – Resource package unsubscription is not supported. After a resource package expires, you can still use SDRS, but you will be billed on a pay- per-use basis for the resources used. You must ensure that your account has a sufficient balance.

Pay-per-Use Subscription ● Billing item: protected instance usage duration ● You need to pay for the protected instance usage duration, which is calculated by hour, and does not include a minimum fee. ● Once subscribed, SDRS uses the pay-per-use mode by default (protected instance usage duration is rounded up to the closest hours). You can change your billing mode according to your own demands. For greater flexibility, you can apply for a yearly or monthly resource package in order to purchase your resource quota and protected instance usage duration in advance.

Helpful Links ● How Am I Billed for SDRS? ● How Do I Use a Resource Package?

8 Basic Concepts

8.1 SDRS Basic Concepts

Table 8-1 SDRS basic concepts Concep Description t

Producti A production site is the data center that independently carries on site 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.

Protecti Used to manage a group of servers to be replicated. One protection on group is for servers in one VPC. If you have multiple VPCs, you need group to create multiple protection groups.

Protecte Indicates a server and its replication server. A protected instance d belongs to one protection group. Therefore, the production site and instance DR site of the protected instance are the same as those of the protected instance's protection group.

Replicati Indicates a disk and its replication disk. A replication pair belongs to on pair one protection group and can be attached to a protected instance in this protection group.

Concep Description t

Planned You can temporarily stop servers at the production site and then failover 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.

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.

Enablin This operation can be performed after a protection group is created g or data synchronization stops. Once the protection is enabled, the protecti data synchronization starts, and the synchronization progress is on 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.

Enablin This operation can be performed after a failover. Once the protection g is enabled again, the data synchronization starts, and the protecti synchronization progress is displayed on the web page. This operation on affects all protected instances and replication pairs in the protection again group. When you click Reprotect after a failover, the status of the protection group changes to Re-protecting, and Disable Protection becomes unavailable.

Disablin Can be performed after the data synchronization is complete. Once g the protection is disabled, the data synchronization stops, and the protecti protection status of the protection group changes to Available. on

Attachin Indicates to attach the two disks in a replication pair to the two g a servers in a protected instance. replicati on pair to a protecte d instance

Concep Description t

Detachi Indicates to detach the two disks in a replication pair from the two ng a servers in a protected instance. replicati on pair from a protecte d instance

DR Indicates the data replication direction. The data replication is from directio the production site to the DR site when users create a protection n 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.

Protecti Indicates the status of a protection group when users perform an on operation on the protection group, such as creating or deleting a group protection group, enabling or disabling protection, or performing a status planned failover or failover. For details, see the protection group status section in the Appendixes of Storage Disaster Recovery Service API Reference.

Synchro Indicates the status of the data replication between the production nization and DR sites. status

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.

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.

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.

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.

Concep Description t

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.

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.

8.2 Region and AZ

Concept A region and availability zone (AZ) identify the location of a data center. You can create resources in a specific region and AZ. ● Regions are divided based on geographical location and network latency. Public services, such as Elastic Cloud Server (ECS), Elastic Volume Service (EVS), Object Storage Service (OBS), Virtual Private Cloud (VPC), Elastic IP (EIP), and Image Management Service (IMS), are shared within the same region. Regions are classified into universal regions and dedicated regions. A universal region provides universal cloud services for common tenants. A dedicated region provides specific services for specific tenants. ● An AZ contains one or more physical data centers. Each AZ has independent cooling, fire extinguishing, moisture-proof, and electricity facilities. Within an AZ, computing, network, storage, and other resources are logically divided into multiple clusters. AZs within a region are interconnected using high- speed optical fibers to support cross-AZ high-availability systems. Figure 8-1 shows the relationship between regions and AZs.

Figure 8-1 Regions and AZs

HUAWEI CLOUD provides services in many regions around the world. Select a region and AZ based on requirements. For more information, see HUAWEI CLOUD Global Regions.

Selecting a Region

When selecting a region, consider the following factors:

● Location It is recommended that you select the closest region for lower network latency and quick access. Regions within the Chinese mainland provide the same infrastructure, BGP network quality, as well as resource operations and configurations. Therefore, if your target users are on the Chinese mainland, you do not need to consider the network latency differences when selecting a region. – If your target users are in Asia Pacific (excluding the Chinese mainland), select the CN-Hong Kong, AP-Bangkok, or AP-Singapore region. – If your target users are in Africa, select the AF-Johannesburg region. – If your target users are in Europe, select the EU-Paris region. – If your target users are in Latin America, select the LA-Santiago region.

NO TE

The LA-Santiago region is located in Chile. ● Resource price Resource prices may vary in different regions. For details, see Product Pricing Details.

Selecting an AZ

When deploying resources, consider your applications' requirements on disaster recovery (DR) and network latency.

● For high DR capability, deploy resources in different AZs within the same region. ● For lower network latency, deploy resources in the same AZ.

Regions and Endpoints Before you use an API to call resources, specify its region and endpoint. For more details, see Regions and Endpoints.

9 Change History

Released On Description

2021-06-21 This issue is the ninth official release. Modified the following content: Deleted the RTO target in Product Advantages. Deleted the following content: Section "Compatible Applications and Versions"

2021-04-20 This issue is the eighth official release. Modified the following content: Deleted the description that general purpose SSD disks cannot be used to create replication pairs and that high I/O (performance-optimized I) and ultra- high I/O (latency-optimized) disks on SAP HANA ECSs, HPC ECSs, and HL1 ECSs cannot be used to create replication pairs in Constraints.

2020-06-20 This issue is the seventh official release. Modified the following content: Modified Constraints. Specifically, Kunpeng instances are not supported.

2020-04-29 This issue is the sixth official release. Modified the following content: Modified Constraints. Specifically, shared disks are supported.

2020-03-31 This issue is the fifth official release. Added the following content: Pricing Details

Released On Description

2019-07-25 This issue is the fourth official release. Modified the following content: Added the following restriction in Constraints: Servers at the production site can be backed up and restored. Servers at the DR site can be backed up only.

2019-07-25 This issue is the third official release. Modified the following content: Added the following restriction in Constraints: Servers at the production site can be backed up and restored. Servers at the DR site can be backed up only.

2019-05-30 This issue is the second official release. Added the following content: ● Region and AZ Modified the following content: ● Deleted the restriction that the specifications of the DR site server must be consistent with those of the production site server in Constraints.

2019-05-24 This issue is the first official release.