The reason for deploying an application to multiple data centers is either to provide for disaster recovery or for geographical load balancing of traffic. On top of this if the application experiences high traffic the use of an In-Memory Data Grid is recommended. However in such cases your in-memory data grid should also be able to provide WAN replication.
The Bridge Topology feature is available in TayzGrid to provide WAN replication. Data is replicated asynchronously so that there is no performance degradation for both caches and the client application.
Bridge Topology deals with two different Java In-Memory Data Grid clusters in each location. Bridge Topology forms a Bridge in-between both data grid clusters and this Bridge is itself a cluster of two servers for high availability purposes.
Any operation performed on the source data grid is added asynchronously to the Bridge. This operation is added to the operations queue of the Bridge. Each operation in the operations queue is performed by the Bridge on the target data grid cluster. This ensures that the source and target data grids are synchronized and WAN replication is maintained. The role of the Bridge is to ensure that:
You may have one active and one passive datacenter primarily for disaster recovery purposes. In this case, you have the following In-Memory Data Grids:
Both the active and passive data grids can use any of the data grid topologies that TayzGrid supports. It is not necessary for both to share the same data grid topology although in practice they are usually the same.
In the case of failure of an active site, all traffic for your application is typically routed to the passive disaster recovery site. The passive site application can start using the In-Memory Data Grid seamlessly as all updates have already been synchronized from the active site.
On the resumption of services on the original active site, only a few simple steps are required to reconfigure the Bridge to its original active-passive configuration. These steps do not require the stoppage of either the data gird or the application. Also, these steps ensure that whatever updates have been made in the data grid of the disaster recovery site are now replicated back to the data grid of the active site.
You may have two active datacenters for a combination of regional load balancing and an implied dis aster recovery purpose. In this case, you have the following data grids:
Both the active data grids can use any of the data grid topologies that TayzGrid supports. It is not necessary for both to share the same data grid topology although in practice they are usually the same.
If one of the active sites goes down, traffic is typically automatically routed to the application on the other active site. In such a case the additional traffic is handled seamlessly as the In-Memory Data Grid has already been synchronized through the WAN Replication feature provided 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 data grid receives all the data from to other active data grid through the Bridge so both data grids are synchronized. All of this happens automatically and without having to stop your data grid 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 data grid passive and passive data grid active) all at runtime and without stopping any of the data grids or the Bridge.
This flexibility gives you the power to easily handle disaster recovery situations. For example, if your active data grid in an active-passive goes down, the passive data grid now becomes active. But, when the previously passive data grid is brought back up, you can now easily reconfigure it to become active and the currently active data grid to reverts back to passive mode.
You can also choose to change an active-passive configuration to active-active without stopping the data grid or your application.