Home > Storage > ObjectScale and ECS > Product Documentation > Dell ECS: High Availability Design > Site-wide data protection
Beyond system availability and data durability designed within a single site, ECS also includes protection against a complete site-wide failure. This protection is accomplished in a multisite deployment by federating multiple VDCs or sites and configuring geo-replication.
Federating sites involves providing replication and management endpoints for communication between sites. Once sites are federated, they can be managed as a single infrastructure.
Replication group policies determine how data is protected and where it can be accessed from. ECS supports both active geo-replication and passive geo-replication.
Active geo-replication provides active/active access to data, allowing data to be read and written from any site within its defined replication group. When replicating an all-flash system such as EXF900 across sites, consider the potential performance impacts over the WAN. Large ingest might put high load on the link, causing saturation or delayed RPO. Also, a user or application might experience higher latency times on remote reads and writes, compared to local requests. Another scenario to consider is if partial garbage collection fails and there is large ingest from both the local and replicated sites. In such case, the system might soon reach 90 percent and, thus, stop writing and reclaiming data.
Note: With partial garbage collection, when a chunk is two-thirds garbage, reclaim the chunk by merging the valid parts with other partially filled chunks to a new chunk, and then reclaim space.
The replication can also be configured as passive, which designates two to four source sites and one or two sites to be used only as a replication target. The replication targets are used for recovery purposes only. Replication targets block direct client access for create, update, and delete operations.
The benefits of passive geo-replication include:
ECS provides geo-replication configuration options at the bucket level, allowing the administrator to configure different levels of replication for different buckets.
The following figure shows an example of how an administrator could configure the replication of three buckets:
As a best practice, configure replication groups for specific replication paths. As an example, the preceding figure shows that there is a replication group that replicates data between London and Berlin. That group should be used for all buckets that require replication only between London and Berlin.
Geo-replication protects data by storing a primary copy of the data at the local site and a secondary copy of data at one or more remote sites. The number of copies and the amount of space the secondary copy takes are determined based on the number of sites configured in the replication group, how data is written across sites, and whether Replicate to All Sites is enabled.
Each site is responsible for local data protection, meaning that both the local and secondary copies individually protect the data using erasure coding, triple mirroring, or both methods. The erasure coding schemes at each site do not have to be the same. One site can use the default erasure coding scheme of 12+4 while the other site uses the cold storage erasure coding scheme of 10+2.
Replicated data is encrypted (AES256) and compressed before being sent to the other site through HTTP.
ECS use strong consistency to protect data. To maintain consistency between sites, there must be an authority that is responsible for maintaining the latest version of metadata. The authority is defined at the site level and determines ownership of namespaces, buckets, and objects. Ownership information is first stored on the owner site but is also replicated to the other sites as part of the ECS metadata.
There are authoritative versions of the bucket and object owners.
Namespace owner:
Bucket owner:
Object owner: