.
ECS enables simultaneous access to data via several standard industry protocols.
For object, ECS supports APIs including Amazon S3, OpenStack Swift, and EMC Atmos. Customers can also interact with the same data via HDFS, compatible with Hadoop 2.x distributions including Cloudera, Hortonworks, and Pivotal.
The object interfaces of ECS are, by design, accessible using off-the-shelf tools rather than ECS custom tools or commands. The object interfaces implement existing APIs, so any application developed to work with the existing object API should be able to work with ECS.
Extensions to the existing APIs have been implemented in a way that does not interfere with the existing API, yet still enables application developers to take advantage of some ECS specific capabilities.
For object, ECS supports APIs including Amazon S3, OpenStack Swift, and EMC Atmos. Customers can also interact with the same data via HDFS, compatible with Hadoop 2.x distributions including Cloudera, Hortonworks, and Pivotal.
The object interfaces of ECS are, by design, accessible using off-the-shelf tools rather than ECS custom tools or commands. The object interfaces implement existing APIs, so any application developed to work with the existing object API should be able to work with ECS.
Extensions to the existing APIs have been implemented in a way that does not interfere with the existing API, yet still enables application developers to take advantage of some ECS specific capabilities.
It’s common in the industry for customers to segregate data into sites. Each site has its own namespace and the system replicates sites asynchronously. Failover is handled by reconfiguring DNS name resolution. The drawback is that sites are vertical silos, completely unaware of each other’s namespaces. You need to re-direct traffic in the event of a failure. In contrast, ECS offers a global namespace that spans across sites. This means a bucket can be accessed from many end points and different sites.
To address the issues of segregated namespaces, many object platforms feature a global namespace with read-only replicas that are eventually consistent. The issue with this, is that one site is primary and if that site fails, you only have read access─writes will queue up. You can read from any site, but only one site can be written to. In contrast, ECS provides both a global namespace and read/write access from every site.
With eventual consistency, the responsibility of avoiding the “stale read” is left to the application developer. In contrast, ECS implements strong consistency. This means regardless of the end point used for data access, the most recent version of the object is returned. This makes the developer’s job a lot easier and supports “Anywhere Access” to data.
To address the issues of segregated namespaces, many object platforms feature a global namespace with read-only replicas that are eventually consistent. The issue with this, is that one site is primary and if that site fails, you only have read access─writes will queue up. You can read from any site, but only one site can be written to. In contrast, ECS provides both a global namespace and read/write access from every site.
With eventual consistency, the responsibility of avoiding the “stale read” is left to the application developer. In contrast, ECS implements strong consistency. This means regardless of the end point used for data access, the most recent version of the object is returned. This makes the developer’s job a lot easier and supports “Anywhere Access” to data.
Some object storage solutions use a distributed erasure coding scheme to efficiently store data. With distributed erasure coding, fragments and parity are spread across multiple sites. The drawback is that a disk or a node failure requires reconstruction over the wide area network (WAN). This increases WAN traffic and affects access and performance.
In contrast ECS features a hybrid encoding approach. It is a higher performance than geo erasure-code. All nodes and disk failures are repaired within the zone, without any WAN traffic.
For full data center failures, ECS needs to mirror data only for the case of two VDCs with replication. For three or more VDCs, ECS can offer significantly low overhead while protecting against complete loss of a site.
In contrast ECS features a hybrid encoding approach. It is a higher performance than geo erasure-code. All nodes and disk failures are repaired within the zone, without any WAN traffic.
For full data center failures, ECS needs to mirror data only for the case of two VDCs with replication. For three or more VDCs, ECS can offer significantly low overhead while protecting against complete loss of a site.
Many types of failures can occur in large, scalable systems. ECS uses several approaches to provide resilience when failures do occur.
As shown earlier, the erasure coding allows the ECS to reconstruct objects within a storage pool, if the pool loses a disk, even if it loses an entire node. In a storage pool containing four nodes, ECS can continue operation even with the failure of one node. In a storage pool containing eight nodes, ECS can continue to operate even with the failure of two nodes.
In a replication group, ECS also handles network and VDC failures to continue uninterrupted service.
When two VDCs are in a replication group and if network connectivity is interrupted between the two VDCs, each VDC will operate independently. During the connectivity outage, each VDC allows applications to read, write, and update objects despite the inability to communicate with an object or bucket owner. If the same object is updated at more than one site during the failure, ECS decides which version to use based on object ownership.
Note that with two VDCs in a replication group, mirrored copies are maintained in each site. If one VDC fails, the other VDC has a full copy of all data written to either site and can continue operating.
With more than two VDCs ECS uses an XOR scheme across chunks from different VDCs to efficiently store protected data. This enables it to offer low storage overhead which improves with increasing number of sites in a replication group. If one of the multiple VDCs fails, ECS can reconstruct all data within the failed VDC using available chunks in the other VDCs
As shown earlier, the erasure coding allows the ECS to reconstruct objects within a storage pool, if the pool loses a disk, even if it loses an entire node. In a storage pool containing four nodes, ECS can continue operation even with the failure of one node. In a storage pool containing eight nodes, ECS can continue to operate even with the failure of two nodes.
In a replication group, ECS also handles network and VDC failures to continue uninterrupted service.
When two VDCs are in a replication group and if network connectivity is interrupted between the two VDCs, each VDC will operate independently. During the connectivity outage, each VDC allows applications to read, write, and update objects despite the inability to communicate with an object or bucket owner. If the same object is updated at more than one site during the failure, ECS decides which version to use based on object ownership.
Note that with two VDCs in a replication group, mirrored copies are maintained in each site. If one VDC fails, the other VDC has a full copy of all data written to either site and can continue operating.
With more than two VDCs ECS uses an XOR scheme across chunks from different VDCs to efficiently store protected data. This enables it to offer low storage overhead which improves with increasing number of sites in a replication group. If one of the multiple VDCs fails, ECS can reconstruct all data within the failed VDC using available chunks in the other VDCs
The table illustrates ECS storage overhead in a single and multi-site configurations. With ECS, erasure coding is used within each site resulting in a local overhead of 1.33x at every site.
For two sites, since a full mirrored copy is required at each site, the overhead doubles to 2.67x.
With three or more sites, efficiency improves because XOR’d chunks are used instead of a full mirror.
Overhead is particularly significant when dealing with geo-scale and analytics where large volumes of data are involved. In particular note that alternative solutions are not competitive in terms of space efficiency. For example, by default HDFS has an overhead of 3.0x.
For two sites, since a full mirrored copy is required at each site, the overhead doubles to 2.67x.
With three or more sites, efficiency improves because XOR’d chunks are used instead of a full mirror.
Overhead is particularly significant when dealing with geo-scale and analytics where large volumes of data are involved. In particular note that alternative solutions are not competitive in terms of space efficiency. For example, by default HDFS has an overhead of 3.0x.
To manage ECS, launch the ECS Portal, via a web browser, using the Public IPs of any one of the nodes. The default credentials are (root/ChangeMe). Supported web browsers are Firefox version 21.0, Chrome version 27, and Internet Explorer versions 9 and 10.
The portal provides access to all the commonly-used management and monitoring functionality.
In addition, a documented REST API is included with the product
The portal provides access to all the commonly-used management and monitoring functionality.
In addition, a documented REST API is included with the product
Users of ECS can be management users, object users, or both. Management users have access to the ECS portal. Object users have access to the ECS object interfaces for S3, OpenStack Swift, EMC Atmos, Centera CAS, and HDFS. If a user requires access to both the ECS portal and the ECS object interfaces, that user must be created as both a management user and an object user.
A management user can have either or both of the following roles:
•System Admin, who has access to all ECS menus and functions
•Namespace Admin, who manages all object users and buckets within the namespace
An object user can use his/her preferred native object interface (e.g., the standard S3 API) to perform data access operations such as reading, writing, or listing objects in buckets. They can also create or delete buckets.
A management user can have either or both of the following roles:
•System Admin, who has access to all ECS menus and functions
•Namespace Admin, who manages all object users and buckets within the namespace
An object user can use his/her preferred native object interface (e.g., the standard S3 API) to perform data access operations such as reading, writing, or listing objects in buckets. They can also create or delete buckets.
Monitoring data is available from both the ECS portal and the ECS REST API. ECS monitoring provides a broad collection of data to track performance and utilization. ECS retains data for seven days for use in the monitoring reports─this is not configurable. Reports are available for usage data, such as storage metering, capacity utilization, and chunking. Reporting also includes information on data traffic, hardware resources, and process health. In addition, the state of data protection can be assessed using reports for erasure coding, recovery, and replication services. ECS also provides event reporting to audit the activity of the appliance.
Thanks for this marvelous intro!
ReplyDeleteThis comment has been removed by the author.
ReplyDelete