The client/server configuration, used to attain session
affinity, consists of a cluster of servers that are configured as
client only and server only. Using the client/server configuration
has benefits such as isolating the handling of backup data from local
data, recycling backup servers without affecting the servers running
the application, and removing the need for a one-to-one correspondence
between servers to attain session affinity.
The following figure depicts the client/server mode. There is a
tier of applications servers that host web applications using HTTP
sessions, 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.
Benefits of the client/server 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.
- Isolation for stopping and starting
- You can recycle a backup server 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.
Timing consideration: Start the backup application servers
first to avoid unexpected timing windows. The clients attempt to replicate
information and HTTP sessions to the backup servers as soon as they
come up. As a result, HTTP sessions that are created prior to the
time at which the servers come up might not replicate successfully.