Glossary

Active-Active Disaster Recovery

Active-active disaster recovery runs two or more sites at the same time, both serving live production traffic and both holding current data. If one site is lost, the other is already running — there is no standby to bring up.

It is the fastest recovery model available, and the one with the strictest engineering constraints.

What makes it active-active

Every other disaster recovery model keeps a second site in reserve. Active-active does not have a reserve site — it has two production sites.

Three things have to be true:

• Both sites take real user traffic under normal conditions, not just health checks. A site that only receives synthetic requests is a hot standby, not an active site.
• Both sites hold data that is current, either because writes commit at both before being acknowledged, or because they replicate fast enough that the gap is acceptable.
• Either site can carry the whole load. Two sites at 60% capacity each look fine until one disappears and the survivor has to absorb 120% of what it was sized for.

That last point is where most designs fail in practice. Sizing each site for half the load makes the economics work and makes the outage a second outage.

The data problem is the whole problem

Running application servers in two places is straightforward. Having both places agree on the state of your data is not.

Synchronous replication. A write is committed at both sites before the application is told it succeeded. Nothing is ever lost, because nothing is ever acknowledged until both copies exist. The cost is that every single write pays the round trip between sites.

Asynchronous replication. The write is acknowledged locally and shipped to the second site immediately afterwards. Latency stays local, but there is always a window of recent writes that exist in one place only. If that site is the one that fails, those writes are gone.

There is no third option, and no product removes the trade-off. What varies is how small the window gets and how honestly it is reported.

Why distance sets the design

Light travels through fibre at roughly 200,000 km per second — about 5 microseconds per kilometre. A round trip between sites 100 km apart therefore costs about 1 ms in physics alone, before any switch, firewall or storage controller touches the packet.

This creates a direct conflict. Synchronous replication wants the sites close together; protection against regional events — flooding, grid failure, a storm system — wants them far apart. Metro-distance pairs get zero data loss and share some regional risk. Continental pairs are independent of each other and cannot be synchronous.

Organisations that need both usually build three sites: two close together running synchronously, and a third at distance receiving asynchronous copies.

Split brain, and why you need an odd number

With two sites and a broken link between them, each site sees the other as failed. Both conclude they are the survivor. Both keep accepting writes. When the link returns there are two divergent versions of the data and no automatic way to reconcile them.

This is split brain, and it is the failure mode that active-active designs spend the most effort avoiding. The standard answer is a quorum: a third location — often just a small witness or arbitrator, not a full site — that votes on which side stays live. A site that cannot reach the witness stops serving writes rather than risk diverging.

The practical implication is that a genuine two-site active-active design is really a three-location design. The third location does not need capacity or data. It needs to be independent of the other two.

What actually happens when a site fails

There is no activation procedure, which is the point. What still has to happen:

• Detection. Something has to decide the site is genuinely down rather than briefly unreachable. Declare too fast and you fail over on a transient; too slow and the detection window becomes your outage.
• Traffic steering. Users are moved to the surviving site by DNS, anycast routing or a global load balancer. DNS is the slowest of these — clients and resolvers cache records past their TTL regardless of what the TTL says.
• Session and state handling. In-flight transactions on the lost site are gone. Users on it get errors and have to retry. Whether that means a re-login or a lost shopping cart depends on how session state was designed, not on the DR architecture.
• Capacity absorption. The survivor takes all the load. If it was not sized for that, this is where the failover becomes visible to customers.

Recovery is measured in seconds to minutes. It is not instant, and vendors that describe it as instant are describing the storage layer rather than the user experience.

What it costs and who pays it

Two full production environments, plus the network between them, plus the engineering to keep both correct. The bandwidth is not incidental — synchronous replication needs low latency and enough capacity to carry every write, sustained, with headroom for peaks.

The offset compared with a hot site is that neither site is idle. You are paying for capacity you use, rather than for a duplicate that produces nothing. The extra cost over a single site is the overprovisioning needed so that either one can run alone, plus the inter-site link, plus the operational discipline.

Organisations choose it when downtime is measured in revenue per minute or in regulatory exposure: payment processing, trading systems, telecoms, large-scale online services, and healthcare systems where records have to be reachable continuously. Below that threshold, a hot site gives most of the benefit for a fraction of the complexity.

What the storage layer has to provide

Scality RING supports synchronous stretched configurations, where a write is committed at both sites before it is acknowledged, giving zero data loss. Scality's engineering guidance for this puts the practical envelope at 10 Gb/s or better between sites and under 5 ms of latency — which is the distance constraint above, expressed as a supported configuration. Beyond that range, replication is asynchronous.

Scality ARTESCA replicates asynchronously between two sites, with objects appearing at the destination shortly after they are written at the source.

One caveat applies to every active-active design regardless of platform: replication is faithful. It copies ransomware encryption, accidental deletion and bad application writes to the second site as reliably as it copies good data. Both RING and ARTESCA support S3 Object Lock in governance and compliance modes for exactly this reason — active-active protects against a site being lost, not against the data being wrong.