Three-site passive federated deployment with ADO-enabled buckets
When ECS is deployed in a three-site passive configuration, the TSO behavior is the same as described in
Three-site active federated deployment with ADO-enabled buckets, with one difference. If a network connection fails between an active site and the passive site, ECS always marks the passive site as TSO (not the active site).
When the network connection fails between the two active sites, the following normal TSO behavior occurs:
ECS marks one of the active sites as TSO (unavailable), for example, owner Site B.
Read/write/update requests are rendered from the site that is up (Site A).
For a read request, Site A requests the object from the passive site (Site C).
Site C decodes (undo XOR) the XOR chunks and sends to Site A.
Site A reconstructs a copy of the object to honor the read request.
In the case of a write/update request, Site A becomes the owner of the object and keeps the ownership after the outage.
The following illustration shows a passive configuration in a normal state; users can read and write to active Sites A and B and the data and metadata is replicated one way to the passive Site C. Site C XORs the data from the active sites.
Figure 1. Passive replication in normal state
The following illustration shows the workflow for a write request that is made during a TSO in a three-site passive configuration.
Figure 2. TSO for passive replication
Data is not available for the Topic
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please select whether the article was helpful or not.
Comments cannot contain these special characters: <>()\