Your application may be deployed to multiple data centers either for disaster recovery or for geographical load balancing of traffic. And, if your application is high traffic, it must use an in-memory distributed cache. In these situations, you need to ensure that your in-memory distributed cache can do WAN replication.
NCache provides Bridge Topology to handle WAN replication of in-memory distributed cache. Bridge Topology does asynchronous replication of data so there is no performance degradation of both caches and also your application.
Bridge Topology deals with two different cache clusters (in-memory distributed caches) in each location. Bridge Topology forms a Bridge in-between both caches and this Bridge is itself a cluster of two servers for high availability purposes.
When an operation is performed on one cache (source cache), it is asynchronously handed over to the Bridge. Bridge then adds this operation to its operations queue. Bridge then goes through each operation in the queue and performs it on the target cache so it is synchronized with the source cache and the WAN Replication is done. The Bridge ensures that:
You may have one active and one passive datacenter primarily for disaster recovery purposes. In this case, you have the following caches:
The cache could be any topologies that NCache supports and active and passive caches do not need to have the same caching topology although they’re usually the same topology.
If the active site goes down, you would typically route all the traffic to your application deployed on the passive disaster recovery site. This passive site application then starts using the in-memory distributed cache seamlessly because this cache is already synchronized with all the updates in the previously active site.
Later, when your originally active site comes back up, you can go through a few simple steps and reconfigure your Bridge to its original active-passive configuration without stopping either the cache or your application. And, these steps also ensure that the temporarily active cache’s data is now moved to the originally active cache.
You may have two active datacenters for a combination of regional load balancing and an implied disaster recovery purposes. In this case, you have the following caches:
The cache could be any topologies that NCache supports and both active caches do not need to have the same caching topology although they’re usually the same topology.
If the one of the active sites goes down, you would typically route all the traffic to your application running in the other active site. This traffic is handled seamlessly by this other active site because the in-memory distributed cache is already replicated through the WAN by the Bridge.
Later, when your downed active site comes back up, you can go through a few simple steps and add it back to the Bridge. When this happens, this newly added active cache receives all the cached data from to other active cache through the Bridge so both caches are synchronized. And, all of this happens automatically and without stopping your cache or your application.
If you have an active-passive Bridge configuration, you can easily switch it to active-active or reverse active-passive order (meaning make active cache passive and passive cache active) all at runtime and without stopping any of the caches or the Bridge.
This flexibility gives you the power to easily handle disaster recovery situations. For example, if your active cache in an active-passive goes down, the passive cache now becomes active. But, when the previously passive cache is brought back up, you can now easily reconfigure it to become active and the currently active cache to revert back to passive mode.
You can also choose to change an active-passive configuration to active-active without stopping the cache or your application.
Cache administrators can now temporarily disconnect caches from the bridge while bridge is running. When a cache is disconnected, no data is transferred between the bridge and the disconnected cache. Similarly, the cache on the other side of the bridge stops queuing data to the bridge as the disconnected cache is no more receiving any data. Cache can be reconnected at any time and everything resumes the way it used to be.