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.

Before using Session Replication and Failover features, it is necessary to synchronize machine times of all machines in a cluster over which Web Server nodes are installed. This time synchronization needs to done using some utility such as ntpdate on Solaris, and not manually.

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:

<cluster>
		<local-host>hostA</local-host>
			<instance>
         <host>hostB</host>
      </instance>
      <instance>
          <host>hostC</host>
      </instance>
       <instance>
          <host>hostD</host>
      </instance>
      <instance>
           <host>hostA</host>
    <session-replication/>
</cluster>
			

If you are using the default values for the following elements, the entry for these elements will not be available in the server.xml configuration file:

For more information about these session replication properties, see the Oracle iPlanet Web Server 7.0.9 Administrator’s Configuration File Reference.

Configuring a Web Application for Session Replication

To enable the server to replicate the session, the web application must also be enabled for session replication.

1. To enable session replication for a web application, modify the sun-web.xml configuration file located in the <web-application>/WEB-INF directory.

   The modification needed in the sunweb.xml is as follows:

   Change the element <session-manager/> to <session-manager persistence-type="replicated">

   The sample sun-web.xml file with session replication enabled is given below:

   <sun-web-app>
   		<session-config>
        <session-manager persistence-type="replicated">
        </session-manager>
     </session-config>
   </sun-web-app>

2. 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).

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

4. 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.

   ---