Bridge For WAN Replication
This feature is only available in NCache Enterprise Edition.
For large scale applications, distributed caches are used to improve performance, reliability and runtime scalability of your applications. So distributed caches can be a very important part of your disaster recovery plan, a disaster ranging from natural disasters to internal hardware disasters or software failure.
The best and most used disaster recovery plan is live data replication to other backup sites. So when needed, you can redirect your live users to your backup site without any error. However, this requires making sure that your active and backup caches are both synchronized at any time. If they are not synchronized, then that can affect your applications’ cache clients.
Data replication also solves the problem for you if you not only have disaster recovery plans but also want to deploy your application on geographically separated regions for widely spread customers. Here you can have two or more active sites which will deal with users of related regions and also can be used as backup of other region sites.
NCache provides you WAN replication through the Bridge feature. A bridge is created between two cluster caches and data is replicated from the source to the other site through that bridge.
Pluggable Caching Architecture: Caches are not aware of each other; they just know about the bridge and replicate their data to bridge. Due to this loose coupling, you can configure bridge between any two caches irrespective of their cache topology. You can freely remove caches configured with bridge.
Data Integrity: Operations performed at source cache are en-queued by the bridge maintaining the actual order in which they were performed at source cache. Bridge performs operations on target cache in the same order. Conflicts are resolved on target cache. In this way, caches eventually become consistent.
Dedicated Bridge Service: Bridge is also a stand-alone and dedicated service like cache service so your cache operations will not be affected if bridge operations are delayed due to latency in the network.
Configuring Bridge: You can configure your bridge on the same server where your cluster cache resides or you can create it on separate server node. Then you can add both of your cluster caches into bridge and data will be replicated between them.
Disaster Recovery: You can configure bridge between an active and passive data center for disaster recovery.
Dealing Geographically Spread Customer: You can have two active sites which will deal users of related regions and also can be used as backup of other region sites.
Asynchronous Replication: For WAN replication, asynchronous replication is used so that cache operations will not suffer in case of delays in bridge operations.
Queue Backup: Bridge is basically a two node clustered queue in which one node is active and other is passive having a backup of active queue to avoid data loss on bridge.
Connection Retries: Bridge also tries to replicate all operations by retrying when any connection failure occurs.
Configurable Queue Size: Bridge replicator queue size is configurable. You should configure the size of bridge queue by analyzing your cache load because every update will be replicated to the bridge queue and if it has less size, then your queue can end up full which can cause data loss.
Bridge Caches: You can use any topology for cluster caches that will be part of bridge. You can also use two different topology caches on each site in one bridge. However, the same topology on both sides is mostly used.
NCache has two kinds of bridge topologies:
This configuration is mostly used for creating backups for disaster recovery. In this configuration we have an active site, bridge and a passive site:
An active cache (replicated, partitioned, mirrored or partitioned-replica), where all clients connect and perform read and write operations.
A passive cache (replicated, partitioned, mirrored or partitioned-replica), where all operations performed on the active cache are replicated. Clients can connect to passive cache and perform both read and write operations but those operations are not replicated to the other cache. Modifications can be done at passive cache if required.
A bridge cache between the active cache and the passive cache.
Operations are replicated to the passive site from active site through bridge. No requests are directed to the passive site.
Bridge is created at the active site to reduce bridge replication cost from source to bridge.
If the active site goes down by any cause, you can redirect your requests to your passive site by making it active. Your passive site will behave as active and treat all requests without any failures.
When your old active site is ready and restarted than you can reform your configurations as it was before. Make both sites active and this will transfer all data from old passive to old active site. When all data is transferred then you can make configurations to your passive site and redirect all requests to the active site.
This configuration is used when you have active data centers in two regions and you want to synchronize caches from those regions. It has all the active sites on both ends of bridge. This bridge topology has two active caches but no passive cache.
Two active caches (replicated, partitioned, mirrored or partitioned-replica), where all clients connect and perform read and write operations. Here any updates to the cache are applied asynchronously to the other cache.
A bridge cache between both the active caches.
You can create bridge at any site because here both sites are active. Mostly bridge resides in the region of sites that have high user traffic to reduce bridge replication cost.
Communication is between two active caches so it is also possible that the same cached data is updated on both sites’ caches almost simultaneously which produce a conflict. To resolve this conflict, NCache provides configurable Conflict Resolver which resolves operation conflict on bridge time. By default, the latest operation "wins" and is applied on cache in case of conflict.
If any site goes down than you can redirect all request to other active site. When downed site is up again data is transferred from already running site to this site and can redirect that region's request to this site.
It is recommended that bridge caches have the same configurations other than topology to avoid issues. For example, if the data source is configured on one cache you should configure it on other cache too. This is because the same operation specifications from one site cache will be replicated to the other site.