Session Replication

Session replication is a mechanism used to replicate the data stored
in a session across different instances. However, the replicated instance
must be part of the same cluster. When session replication is enabled in a
cluster environment, the entire session data is copied on a replicated instance.
However, the session replication operation does not copy the attributes that cannot be serialized in a session and any instance specific data.

Session replication along with load balancing provides good failover
capabilities for web applications.

Session Replication and Failover Operation

This section describes the session replication operation in detail.

At the end of a web request, the Web Server determines whether the session
data needs to be copied through the session replication configuration that
is stored in the server configuration file, the server.xml.

Consider a use case of four instances forming a cluster with session replication enabled on
the Administration Server.

The session replication process in a Web Server cluster of four instances
(A, B, C, and D) running on four nodes is as follows:

Instance A is backup of D, B is backup of A, C is backup of
B, and D is backup of C. This forms a complete backup ring.

Each instance in the cluster keeps track of a static list
of all the instances in the cluster and an active backup instance.

Depending on the configuration, session data is sent to the
backup instance synchronously at the end of each request.

The failover process in a Web Server clustered environmentis as follows:

The load balancer redirects all incoming web requests destined for
instance A to the remaining instances in the cluster and the backup ring is
re-configured as follows:

D detects that its backup A is down and selects the next instance
to A on the ordered list as its new backup instance.

B is selected and D establishes a new backup connection
to B. B now holds two backups: a read-only backup of A and an active backup
of D.

The
backup ring is now complete with B backing up to C, C backing up to D, and
D backing up to B.

When the failed instance A is made available again, it rejoins
the backup ring by sending its designated backup instance B a rejoin message
and establishes a backup connection to B.

When D detects that Ais online by either receiving a successful
ping return from A or by receiving a message from A, D then establishes a backup connection
to A and terminates its backup connection to B.

Web Server 7.0 does not support the following features in session replication:

Recovering
the simultaneous failures of two or more instances.

The interval between two failures must be greater than the
time needed for a resurrected instance to fully recover.

Session backup to more than one instance. In normal operation,
there are only two copies of any session: the primary session and a backup
session.

Session persistence: Sessions are only backed up in memory
of another instance for the purpose of failover

Web Server supports session replication for only Java web
applications. If you are using non-Java applications such as CGI or PHP, the
session data cannot be replicated.

Enabling Session Replication

You can enable session replication in a cluster using either the Admin Console
or the CLI. Before you enable session replication, make sure that your browser
is cookie enabled.

The server.xml file contains the information related
to session replication. A sample server.xml file with session
replication enabled is given below:

After modifying the sunweb.xml file, either
rebuild the web application or re-jar the application to create a web application
archive (a war file).

Restart all the instances to make the web application available
on all the instances.

The web application is accessible from all the nodes in the
cluster. To access the web application, in a browser, type the following:

http://webserver-name/webapplication-name/

Note –

A directory that is accessible to all nodes is the best way to
store the applications for deployment. This directory, however, need not be
accessible to the Administration Server. It is recommended to make directory-based
deployments of web applications that are more than 1 MB in size.

To create search
collections, ensure that the search collection resides in a common directory
that is accessible to all the nodes.