EVS has a wealth of features, as follows:

Multiple Configuration Specifications

eSurfing Cloud provides a variety of EVS configuration specifications for customers to choose from according to their business needs.

EVS supports multiple configuration specifications and can be mounted to cloud servers and used as data disks and system disks. EVS disks are classified into the following types by I/O performance: common I/O, high I/O, generic SSD, ultra-high I/O, and fast SSD. The following table shows the application scenarios of each EVS specification:

EVS Specifications	Scenario
Common I/O	Suitable for scenarios with large capacity, medium read/write rate, and fewer transactions, such as daily office applications and lightweight development and test environments.
High I/O	Suitable for mainstream high-performance and highly reliable application scenarios, such as common development and test environments and office applications that shall balance storage capacity and performance.
Generic SSD	Suitable for mainstream high-performance and low-latency interactive application scenarios, such as large-scale development and test environments, transcoding services, Web server logs, and high-performance system disks.
Ultra-high I/O	Suitable for read-write intensive applications with ultra high IOPS and ultra large bandwidth requirements, such as high-performance computing and IO-intensive latency-sensitive databases.
Fast SSD	Suitable for application scenarios with ultra-high IOPS, ultra-high bandwidth, and ultra-low latency, such as large OLTP databases, large NoSQL databases, and core mission critical systems.

Automatically Mounting to Cloud Servers

EVS can be mounted to and unmounted from elastic cloud servers.
Users can automatically add an EVS disk as a system disk when creating a cloud server. In this case, users do not need the mounting operation. If you need a data disk, you can add a data disk when creating a cloud server to automatically mount the data disk to the cloud server. If you order data disks separately, you must manually mount them to the cloud server. For more information, see Mounting EVS
A data disk that has been ordered separately can be unmounted from a cloud server. However, you must unmount the data disk only when the cloud server is running or shut down. A data disk that has been unmounted can be mounted again to any cloud server.

EVS Performance Monitoring

After the EVS service is enabled, users can use Cloud Eye to view the performance indicators of the EVS, including the read/write rate and read/write operation rate. Cloud Eye is an important performance monitoring service provided by eSurfing Cloud and can be enabled free of charge without the need of installing an additional plug-in.

Three-copy Redundancy

What is Three-copy Redundancy?

The three-copy technology is a data redundancy technology used in distributed storage systems. Each data block is saved in three copies, and these copies are stored on different nodes in the cluster to improve data reliability and fault tolerance.

The following shows the basic principles of the three-copy technology:

• Data replication: When data is written into a distributed storage system, the system automatically segment the data into data blocks and replicates it into three copies.

• Copy distribution: The three copies are distributed on different physical nodes or storage devices to reduce the correlation between copies. In this way, copies on other nodes are still available even if one storage node or device fails.

• Fault tolerance and data recovery: If one copy becomes unavailable or is corrupted (for example, due to a storage node failure or hardware failure), the system can use data from the other copies to achieve fault tolerance and data recovery. The system automatically detects and fixes data errors or losses in the copy.

The following figure shows the architecture of the three-copy technology:

How Does the Three-copy Technology Maintain Data Consistency?

Data consistency indicates that when an application writes one data copy to a storage system, the three data copies in the storage system must be consistent. In addition, when the application reads the data again, the data on any copy is consistent with the data previously written.

Data consistency is generally maintained from two perspectives:

When an application writes data, three copies of the data are written to the storage system. The storage system sends a write success response to the application only when all three copies are successfully written.
If a data copy cannot be read, the storage system automatically reads the data from other saved copies and writes the data again on the node with the sector error to automatically fix the corrupted copy to maintain data consistency.

Failure Effects and Troubleshooting

The storage system uses a distributed storage cluster. Each physical disk in the cluster stores multiple data blocks. The copies of each data block are distributed to different nodes in the cluster based on specific policies. When a storage server or physical disk in the storage system is faulty, data recovery automatically starts. Multiple storage nodes in the storage cluster participate in data recovery simultaneously. Only a small amount of data needs to be reconstructed on each storage node and multiple storage nodes work in parallel. This effectively avoids performance bottlenecks caused by massive data reconstruction on a single node and has little impact on upper-layer services.

What Are the Differences Among Three-copy Technology, Cloud Backup, and Snapshot?

Three-copy technology: Mainly used to improve the data reliability and fault tolerance to ensure the high availability and persistence of data. The three-copy technology is suitable for distributed storage systems to handle device or node failures.

Cloud backup: Mainly used to recover data when the primary storage system fails or data is lost. Cloud backup is often used in scenarios such as long-term data protection, disaster recovery, and data migration.

Snapshot: Mainly used for data recovery, version control, and testing. Snapshot can provide quick recovery points and data rollback capabilities, and save storage space because snapshots usually only record the difference part of the data.

Support for EVS Snapshots

EVS supports using EVS snapshots to quickly restore data and ensure stable service operation.

What Is An EVS Snapshot?

An EVS snapshot is a complete copy or image of the disk data taken at a specific time. It is a major disaster recovery approach, and you can use a snapshot to restore disk data to the time when the snapshot was created. You can create EVS snapshots through the web-based service management console or API interfaces.

EVS Snapshot Principle

EVS snapshots include full snapshots and incremental snapshots.
The first snapshot created for an EVS disk is a full snapshot, which does not include empty data blocks. Subsequent snapshots are incremental snapshots, which back up only changed data blocks since the last snapshot.
The specific principle is shown in the figure below:

EVS Snapshot Billing Description

The EVS snapshots are billed on a postpaid pay-as-you-go basis, and the snapshot storage fee is billed based on the actual capacity used. For the specific rates, see EVS Snapshot Billing Description.

Usage Scenarios of EVS Snapshots

Data protection and recovery: Snapshots can be used as a means of backing up and restoring data. If the data on an EVS disk is accidentally deleted, corrupted, or modified by mistake, you can use a snapshot to restore the data to the previous state.
Data recovery test: You can use snapshots to perform data recovery tests. Create a snapshot before performing any critical operation, and then roll back the disk data to the snapshot state at any time during the test to ensure the operational safety and reliability.
Data backup and archiving: By creating snapshots, you can regularly back up EVS disk data and keep the snapshot archive for long-term data retention and legal or regulatory compliance.
Deployment of multiple services in batches: You can quickly create multiple EVS disks with the same data from the same snapshot, so that you can provide data resources for multiple services at the same time, such as data mining, report query, development, and testing.

Differences between EVS Snapshots and VBS Backups

EVS snapshots and VBS backups are commonly used for data protection and recovery in cloud computing, and they differ in terms of functions and usage as described in the following table:

Difference	EVS Snapshot	VBS
Storage Location	Snapshots are saved on the same EVS disk with the raw data.	Backups are not saved on the same EVS disk with the raw data but in the OSS as backup files. They can be used for data recovery even if the EVS disk is corrupted.
Data Synchronization	A snapshot saves the data at a specified time on the EVS disk. You can set an automatic snapshot policy. If the EVS disk for creating a snapshot is deleted, the corresponding snapshot is also deleted automatically at the same time, or you need to delete it manually.After the OS is reinstalled or switched to another version, snapshots of system and data disks will not be deleted, and the snapshots of data disks can be used as normal. If a single disk snapshot is saved for the system disk, the OS reinstallation/switching may fail. We suggest that you manually delete the snapshot before OS reinstallation/switching. For more information, seeDelete a Snapshot.	A backup saves the data at a specified time on the EVS disk. You can set automatic backup. If the EVS disk for creating a backup is deleted, the corresponding backup is not deleted at the same time independently stored in a third-party storage medium.
Service Restoration	The EVS disk data is restored by rolling back to a snapshot or a new EVS disk is created with a snapshot as the data source for service restoration.	You can restore a backup file to an EVS disk or create a new EVS disk with a backup as the data source for service restoration.

Volume Backup Service (VBS)

EVS supports volume backup service to ensure data reliability and recoverability.

What is VBS?

VBS backs up data in an EVS to another storage medium or location. VBS is a data protection measure designed to address risks such as data corruption, accidental deletion, malicious operation or primary storage system failure to ensure data reliability and recoverability.

Features of VBS

The following shows the features of VBS:

Data protection: VBS provide an additional layer of protection against data loss or corruption.
Periodic backup: Backup operations are usually performed periodically. You can set the backup frequency and retention period as needed.
Incremental backup: Incremental backup often is used in VBS to back up only changed data to reduce backup time and storage space usage.
Data recovery: Backup data can be recovered when needed to roll back to the data state in a given point in time.

Scenario of VBS

VBS is widely used for disaster recovery, data protection and data migration:

Disaster recovery: When the primary storage system is faulty, data is lost, or a disaster event occurs, you can use the backup data for data recovery to resume normal operation of your business.
Long-term data protection: Backup data can be stored for an extended period of time as a long-term protection measure to meet legal compliance, contractual requirements, or data archiving requirements.
Data migration: Backup data can be used for data migration, migrating data from one cloud environment to another one, or from a cloud environment to an on-premises environment.

EVS Usage

For more information on the usage of VBS, see Volume Backup Service.

EVS Sharing

EVS can be shared to implement data sharing and collaboration among multiple instances.

What Is Shared EVS?

Shared EVS allows multiple cloud servers to access the same EVS concurrently, enabling data sharing and collaboration among multiple instances. Shared EVS is often used in data clusters, distributed file systems, and high availability architectures.

A shared EVS can be mounted to a maximum of 16 cloud servers at the same time. Cloud servers include elastic cloud servers and physical servers. Currently, EVS can share only data disks, but not system disks.

Note:

EVS sharing is implemented on cluster management systems. Sharing or collaboration is impossible when you directly mount EVS to multiple cloud servers or physical server, and data overwriting may occur. Common cluster management systems include Windows MSCS cluster and Veritas VCS cluster. The following figure shows the architecture:

Advantages of Shared EVS

Multiple mount points: A single shared EVS can be mounted to a maximum of 16 cloud servers at the same time, and can also be mounted to either an eSurfing Cloud server or physical server. Different types of workloads can be flexibly deployed.
High performance: High Input/Output Operations Per Second (IOPS) and low latency, meeting the requirements of modern applications.

Specifications and Performance of Shared EVS

The specifications and performance of a shared EVS are the same as that of a general EVS. For more information, see Specifications.

Data Sharing Principle of Shared EVS

In essence, a shared EVS means that multiple cloud servers execute read and write access on one EVS. However, a shared EVS disk is only a block storage device that provides shared access and does not have the ability to set read and write data rules. To ensure that cloud servers do not interfere with each other during access and ensure the read and write order and significance, read and write operations must be centrally managed and scheduled through a cluster. Therefore, you must deploy a cluster system by yourself, for example, Windows MSCS cluster, Linux RHCS cluster, and CFS cluster commonly seen in enterprise applications.

If a shared EVS is not managed in a cluster, the following problems may occur:

Read and write conflicts cause data inconsistency:

When two elastic cloud servers are mounted with the same shared EVS but are not managed in a cluster, the two cloud servers cannot detect whether each other's storage space has been used. As a result, the storage space may be repeatedly allocated and data errors may occur due to space allocation conflicts.

Data caching causes data inconsistency:

When two elastic cloud servers, cloud server A and cloud server B, are mounted with the same shared EVS but are not managed in a cluster system, cloud server A records the read data in the cache. Other processes on cloud server A can directly read the data in the cache to improve efficiency. If cloud server B modifies the data in the cache, cloud server A cannot detect the data change. In this case, if cloud server A continues to read data in the cache, the read data will be inconsistent.

In addition, this can also lead to reduced storage performance, lower read/write rate, and longer response time.

Usage of Shared EVS

Log in to the EVS console and create a EVS on the Create EVS page.
In the Create EVS window, in Advanced Settings , check Shared EVS checkbox to create an EVS that can be mounted to multiple servers.

After the EVS is created, select an elastic cloud server instance or physical server instance for the shared EVS you created from the EVS list and click Mount to mount the shared EVS to multiple elastic cloud servers or physical servers in the same availability zone.
Create a shared file system or other cluster system on multiple cloud server or dedicated server instances to share data.

Support for EVS Encryption

EVS disks support encryption to ensure data security and prevent from privacy breach.

What Is EVS Encryption?

If you need to encrypt the data stored on EVS disks according to classified protection compliance or security requirements, you can select the encryption option when you create an EVS disk to encrypt the newly created EVS disk.

Key Management

EVS adopts the industry-standard AES-256 algorithm to encrypt your EVS data with data keys. The keys used for EVS encryption are provided by the self-developed Key Management Service (KMS) of eSurfing Cloud. You can easily create and manage the keys to meet your needs of data encryption, decryption, and digital signature verification in a safe and convenient manner.

KMS uses the Hardware Security Module (HSM) to protect key security. All users' keys are protected by the root key in the HSM to prevent key exposure. KMS implements access control and log tracking on all key operations and provides usage records of all keys to meet audit and compliance requirements. With KMS, you can easily encrypt and decrypt small and large amounts of data.

How It Works

Before understanding how EVS encryption works, you first need to understand two concepts:

Default CMK (Default CMK): The service key that is automatically generated by the system and hosted under your account when you use KMS for EVS encryption for the first time through the corresponding cloud service.
Customer Master Key (Customer Master Key, CMK): The CMKs are classified into symmetric and asymmetric keys, which are mainly used to encrypt and protect data keys and generate envelopes, and can also be used to encrypt small amounts of data. You can call the CreateKey API of KMS to create a CMK.

When you use an encrypted EVS disk for the first time, the system automatically creates an only CMK in the corresponding region in the KMS and stores it in a key management service that is protected by strict physical and logical security controls.

Encrypted EVS disks in each region must be encrypted with a 256-bit data key (DK), which is regionally unique, that is, there is only one DK in each region. It is protected by the key management infrastructure provided by the KMS to effectively prevent unauthorized access. The DK for EVS encryption is only used in the memory of the host where the instance is located, and it is not stored in plaintext on any persistent media (even the EVS disk itself).

After you create an encrypted EVS disk and attach it to an instance, the following data will be associated with this key and encrypted:

Static data on EVS disks
Data transferred between EVS disks and instances (Data in the instance OS is not encrypted.)
A snapshot created by encrypting an EVS disk

Relationships between EVS Encryption and Snapshots, Backups, and Images:

The relationships between the EVS encryption and the ECS system disk, ECS data disks, snapshots, backups, and images are described as follows:

EVS encryption

When creating an EVS disk, you can choose whether to encrypt the disk. The encryption attribute cannot be changed once the disk is created.

ECS system disk encryption

When creating an ECS, you can directly choose to encrypt the system disk.

ECS data disk encryption

When creating an ECS, you can directly choose to encrypt the data disks.

EVS disk encryption and snapshots

Snapshots generated from encrypted EVS disks and the EVS disks created from these snapshots automatically inherit the encryption attribute.

EVS encryption and backups

Backups generated from encrypted EVS disks and the EVS disks created from these backups automatically inherit the encryption attribute.

Elastic Volume Service

Product Features