Memory-to-memory topology: Peer-to-peer function with remote/isolated replicators
In this topology, the replicators are separated from the clustered servers running the deployed application.
This method increases the number of servers used, which can be a increased cost for any installation. However, if containable, the separation of replicators produces several benefits:
- A replicator can handle the activity from session managers in multiple
servers. A one-to-one correspondence between the replicators and servers can
often be unnecessary; having a primary server (with a second sever as a backup)
is often sufficient.
- Not running the replicator in the Java Virtual Machine (JVM) running the
application can free up some heap and central processing unit (CPU) for running
the application.
- Putting components into separate processes means that if one of the component processes fails, this failure does not affect the other components.
Replicators can often handle multiple servers (six to seven). By using this topology, you have two configuration options:
- Use one replicator, and keep the other as a backup on standby (remember,
if a replicator goes down, the session manager automatically switches to the
next replicator domain).
- Split your session manager/appservers between the two replicators.
Memory-to-memory replication
Memory-to-memory topology: Peer-to-peer function with a local replicator
Memory-to-memory topology: Client/server function with isolated replicators
Memory-to-memory topology: Client/server function with remote 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