Multi-Datacenter WAN Replication

Your application may be deployed to multiple data centers either for disaster recovery or for geographical load balancing of traffic. If your application is high traffic, it must use a distributed cache. In these situations, you need to ensure that your distributed cache can do WAN replication for high availability of data in case of disaster.

NCache provides Bridge to handle WAN replication of distributed caches. It forms a bridge in-between the distributed data centers and performs asynchronous replication of data so there is no performance degradation. Moreover, the bridge itself is a cluster of two servers for high availability purposes.

Active-Passive Configuration

You may have one active and one passive datacenter primarily for disaster recovery purposes. In this configuration, one active site contains the bridge and caches, while the passive contains only the caches. The active site asynchronously replicates the data through the bridge to the passive site, which acts as backup in case of disaster.

Active-Passive Configuration

Active-Active Configuration

You may have two active datacenters for a combination of regional load balancing and an implied disaster recovery purpose. One of the active sites contains the bridge and caches while one contains the caches only, similar to the active-passive configuration. However, the difference in this case is that both sites replicate data with one another as they are both actively serving client operations.

Active-Active Configuration

Handling 3+ Active-Active Datacenters

Apart from the aforementioned configurations, NCache also provides handling of three or more data centers. In this case, one of the sites is a bridge site, which contains the bridge and caches. The other sites only contain the caches. All the non-bridge sites are connected to the bridge site, so data is replicated to all sites simultaneously. You can also create a backup bridge on any of these sites to ensure high availability in case the bridge site goes down. For more detail on this configuration, you can head over to the blog Understanding Multi-Datacenter WAN Replication.

Handling 3+ Datacenters

Conflict Resolution in Active-Active

When you have multiple active sites, there is a chance that the same data could be updated simultaneously on each of those sites. By default, the conflict is resolved in NCache using the “last-update-wins” logic. However, you can also specify a custom conflict resolution handler that resolves the conflict by analyzing the data based on your logic.

The following code snippet shows a simplified implementation of the conflict resolver which is implemented on the cache:

public class Resolver : IBridgeConflictResolver
{
    public void Init(System.Collections.IDictionary parameters) {. . .}

    public ConflictResolution Resolve(ProviderBridgeItem oldEntry, ProviderBridgeItem newEntry)
    {
        var conflictResolution = new ConflictResolution();

        switch (oldEntry.BridgeItemVersion)
        {
            case BridgeItemVersion.OLD:  { /* Replace Item with New Entry */  }
            break;

            case BridgeItemVersion.LATEST:  {   /* Keep Old Entry  */  }
            break;

            case BridgeItemVersion.SAME:   { /* Your custom logic */  }
            break;
        }
        return conflictResolution;
        // Configure this implementation on cache
    }
    public void Dispose() {. . .}
}

For more detail on conflict resolution, you can refer to Conflict Resolution Docs.

Parallel & Bulk Async Replication

Replication across regionally distributed data centers can result in performance degradation because of latency. Hence, NCache bridge performs asynchronous WAN replication in parallel across all datacenters so your application doesn’t experience any downtime while waiting for the operations to be replicated.

Moreover, the bridge also sends multiple data items as a single bulk request to the other site, drastically reducing network trips across the WAN. As an add-on, the bridge has built-in replication as well: it is a 2-node cluster which self-replicates so it is highly available itself. For more detail on NCache bridge behavior, you can refer to NCache Bridge Architecture Docs.

Handling Disaster at Runtime

NCache seamlessly handles disaster situations in each of the aforementioned data center configurations.

  • Active-Passive: If passive goes down, the active site continues to serve client operations but no replication takes place until the passive site comes back up. Once it’s back, the passive site resyncs itself and WAN replication takes place. If the active site goes down, the traffic is routed to the passive site which temporarily acts as an active site as it is synced with the active site. Once the original active site is back up, it resynchronizes itself and becomes active again.
  • Active-Active: In this case, if the active site goes down, the traffic is routed to the other site which continues to serve the clients seamlessly as it is also an active site. Once the original site comes back, it resyncs itself automatically and WAN replication continues.
  • 3+ Active-Active:
    • Non-bridge active site goes down: the other sites continue to replicate one another and the traffic on this site is rerouted to the other connected sites without interrupting the users.
    • Bridge active site goes down: if the bridge active site goes down, it means that the WAN replication will not take place as the bridge is also down. So, one of the other running active sites temporarily acts as a bridge site. You can also create a backup bridge on one of the sites for such scenarios. Since NCache allows caches to connect to a bridge at runtime, there is no downtime at the client end. Once the original site is back, it automatically resyncs itself and the traffic is routed to this site, just as before.

What to Do Next?

Review NCache Features
Download NCache
Request a Personalized LIVE Demo

Signup for monthly email newsletter to get latest updates.

© Copyright Alachisoft 2002 - . All rights reserved. NCache is a registered trademark of Diyatech Corp.