Memory-to-memory topology: Client/server function with remote replicators
The following figure depicts the client/server with remote replicators topology. There is a tier of applications servers that host web applications using HTTP Session, and these sessions are replicated out as they are created and updated. There is a second tier of servers without a web application installed, where the session manager receives updates from the replication clients. The replicators facilitating the transfer of data reside with the replication servers
Benefits of the client/server with remote replicators configuration include:
- Isolation (for failure recovery): in this case we are isolating the handling
of backup data from local data; aside from isolating the moving parts in case
of a catastrophic failure in one of them, you again free up memory and processing
in the servers processing the web application, much the same as the isolating
of the replicators as showed in the topology for peer-to-peer function with
remote replicators.
- Isolation (for stopping and starting): you can recycle a backup without
affecting the servers running the application (when there are two or more
backups, failure recovery is possible), and conversely recycle an application
JVM without potentially losing that backup data for someone.
- Consolidation: there is most likely no need to have a one-to-one correspondence
between servers handling backups and those processing the applications; hence,
you are again reducing the number of places to which you transfer the data.
- Disparate hardware: while you run your web applications on cheaper hardware, you may have one or two more powerful computers in the back end of your enterprise that have the capacity to run a couple of session managers in replication server mode; allowing you to free up your cheaper web application hardware to process the web application.
You can define replicators on both the replication client and the server Java Virtual Machines (JVMs), however, replicators on both the clients and the servers is redundant. In the client/server topologies defining replicators only on the backup replication server JVMs is recommended.
It is good to spread out the replication clients as equally across the replicators as possible (by default they select the first replicator in the domain), because both replication servers are doing work and not acting as a hot standby.
Timing considerations: Start the replication servers first to avoid unexpected timing windows. The clients attempt to reconnect to the replication domain if you start the replication clients before the replications servers, even if the initial connection cannot be completed. However, if servers with the application come up, and requests on the applications occur before the replicators on the backup servers finish coming up, some expected client replication might not occur.
Memory-to-memory replication
Memory-to-memory topology: Peer-to-peer function with a local replicator
Memory-to-memory topology: Peer-to-peer function with remote/isolated replicators
Memory-to-memory topology: Client/server function with isolated replicators
Configuring memory-to-memory replication for the peer-to-peer function with a local replicator (default memory-to-memory replication)
Configuring memory-to-memory replication for peer-to-peer functions with remote/isolated replicators
Configuring memory-to-memory replication for the client/server function using isolated replicators
Configuring memory-to-memory replication for the client/server function using remote replicators