Object Storage - The Near Future of Storage Systems

Nine years ago, International Telecommunications Day was renamed International Telecommunications and Information Society Day. For the golden billion, the future has already arrived: the Internet has become one of the most important parts of our life. Enormous amounts of information are created and consumed worldwide every second, and the market for all sorts of online services is one of the fastest growing.

One of the main trends of recent times has been the development of cloud technologies. They are used everywhere, from file hosting services and video hosting sites to mobile applications, service ordering services and internal corporate systems. The overwhelming majority of such projects operate with unstructured information, and the capacity of file storages increases annually by about 53%. And with the growth of generated and stored information, the requirements for data storage systems are transformed.

According to Cisco's forecast , in 2016 the volume of global Internet traffic will reach 1.1 zettabyte (an average of 91.3 exabytes per month). And by 2018, half of the global Internet traffic will be in the content delivery network. The mobile segment is also in a phase of rapid development. According to the same Cisco , in 2014, mobile traffic grew by 69%, reaching 2.5 exabytes. And in 2012, half of the mobile traffic was video.
')
With the growth of volumes of stored and transmitted information, in addition to reliability, simplicity of architecture, ease of scaling and high performance come to the fore. However, the complexity of architectures (locking, replication, high availability) and access in distributed networks, a large variety of equipment and technologies for storing different types of data, reduce the effectiveness of traditional file storage systems and make them too expensive to maintain and scale.

For example, when storing textual and visual information (graphics, video) usually use two databases: separately for text and for content. But with a size of hundreds of terabytes, the performance and fault-tolerant content databases are significantly reduced.



In addition, traditional file storages have the following disadvantages:

• Limit on the number and maximum size of files
• Presence of locks
• Long listing, scanning, etc.
• Lack of the ability to create geo-distributed storage with a single entry point
• Lack of versioning and data generation
• The need for backup operations
• The presence of file table restrictions
• Different speed of work of different file systems with different file sizes
• Low security and data protection
• The complexity of working with metadata
• Significant restrictions on the creation of horizontally expandable storage
• Low flexibility and scalability
• Instability of network file systems due to unstable communication links

Given the development of mobile services, storage systems are increasingly being subject to the following requirements:

• minimization of traffic between client devices and storage,
• minimizing the use of client device resources,
• ability to work with a secure API (inability to work via file or block access)
• work through the global network.

As a result, object storage systems lacking the disadvantages of file storage, providing high performance and fault tolerance when working with large amounts of unstructured data, are becoming increasingly popular. One such solution is EMC Elastic Cloud Storage (ECS).

Elastic Cloud Storage Architecture

EMC ECS is a software-defined storage that can be supplied as a software solution or as a software / hardware system.

The system is based on a software module for storing unstructured data. It can be installed on any standard equipment. At the moment, the storage module provides object data management and HDFS.



Important features of ECS are the unlimited scalability of the system by simply adding new nodes. And by eliminating a single point of failure, high availability is ensured.

ECS provides simultaneous access to data through various interfaces, as well as compatibility with APIs such as Amazon S3, OpenStack Swift, EMC Atmos, and Centera CAS. In addition, API extensions are supported: Byte-Range updates, Atomic appends, Rich ACLs, etc.

The data storage module can log, snapshot and track versioning. All data is stored in logical containers - chunks (chunk). The size of each chunk is 128 MB. In this case, all data protection operations are carried out with chunks, and not with the objects themselves.

Information about the stored objects - their names and addresses of the chunks - is stored in the index. In addition, each object receives a unique name, and the namespace itself is the same for all nodes of the system, wherever they are. The index is also stored in chunks, and its current copies are available at each node of the system.

Since ECS works on standard equipment, a number of solutions have been applied to increase productivity:

• Procedures such as blocking during I / O operations and checking cache memory are excluded. This is achieved by refraining from modifying and rewriting data in chunks, the information is only being added. Deletion of unused data is carried out only in the background.
• The recording of the same object can be carried out simultaneously by all nodes of the system on different sets of disks. Increasing the number of disks and network adapters only increases overall system performance.
• Buffering of small objects is applied: they are written to discs not individually, but in batches. This reduces the number of recording procedures.

Algorithms for writing, reading and updating data

Let's take a closer look at how to write, read and update data in ECS.

Record Algorithm:

1. The storage module receives a request to write an object.
2. At the same time, three copies of the object are recorded in different channels on different nodes. In this case, more than 30 MB of data of one object is not recorded in one chunk, this is done to increase productivity when working with large objects.
3. After that, the index records the name of the object and the address of the chunks.
4. At the same time, three copies of the index itself are recorded in different chunks of different nodes. In this case, select those nodes in which there are no copies of the object.
5. In case of successful recording of all chunks, the storage module confirms the fact of recording the object.
6. When the size of each chunk is 128 MB, the storage module starts the process “Erasure code” (discussed below).
7. After completing the Erasure code, the three saved copies of the object are deleted in the background.

Algorithm of reading:



Everything is simple here: after receiving a read request, the storage module receives from the index information about the location of the object, reads it and sends it to the user.

Since in ECS the data is not overwritten and does not change, the update of existing objects is carried out in a range of bytes. After that, the storage module updates the information about the object in the index, and the old version is marked for subsequent background deletion.

Erasure process code

This process applies only to fully filled chunks. It performs data coding to protect against loss and reduce redundancy. Only the index is not encoded, as the system constantly refers to it. Therefore, index protection is performed using triple replication to different chunks and in-memory caching.

The Erasure process is based on the Reed-Solomon algorithm. A chunk is divided into 16 modules, 12 data modules and 4 code modules, which are written to different nodes. Moreover, the greater the number of nodes, the higher the fault tolerance. Note that the blocks are written in one instance.



The decoding procedure is used only for recovering from failures; this is not required for read operations. Moreover, to read small objects, the system does not even need to contact all chunks containing it. All this has a positive effect on overall system performance.

Data protection and access from multiple sites

ECS uses distributed data protection consisting of two components: a security module and a redundancy management mechanism. To protect against site failure, each chunk is backed up:



The redundancy management mechanism works in the background. To reduce the number of copies between sites, data compression is applied using the XOR operation.



After creating the data set E, the original sets A and D are deleted. In the event of a failure at one of the sites, that dataset is retrieved that has become unavailable. To do this, the second of the original sets is again sent to the site where the compressed set is stored. Recovered from a copy set is copied to another site.



Unlike traditional systems in which data is replicated to multiple sites, in ECS, redundancy decreases as the number of sites increases.



As a result of all the measures applied, the data is saved even if one site fails entirely. And in a system of 8 or more sites, a painless failure of two nodes on each site is possible. Also, each site allows local rebuild, which reduces the load on the network and increase performance in case of failure.

The mechanism of distributed protection, in addition to its main function, in combination with the global namespace allows you to record and read data from any of the sites, regardless of their actual location. At the same time, ECS provides strict data consistency between all sites.

ECS Appliance

Often, many companies create object storages on their own, based on standard equipment and Open Source products. The reason is obvious - savings. However, the maximum cheapness can turn into low reliability. In addition, support for the performance of both equipment and Open Source solutions entirely falls on the users themselves.

As already mentioned, ECS can be supplied as an ECS Appliance hardware and software system. It is completely made of standard elements: 4 server nodes in 2U and 3.5-inch SATA drives. While available 2 configurations.

U-Series - data discs are located in the connected disk shelves.



Five configurations are available, differing in the number of servers and disks.



C-Series - data discs are located in the servers themselves. Expansion is made by the same type 2U modules.



With this type of delivery, support is provided for both software and hardware. Storage scaling is possible either by simply adding new ECS Appliance racks or third-party hardware. However, in the latter case, the user does the deployment and configuration of ECS.

Conclusion

The rapid growth of online services storing ever increasing volumes of unstructured data suggests that in the coming years object storage systems will dominate. Their economic efficiency, unlimited scalability, high fault tolerance and performance will contribute to this.