Chapter 7: Load Balancing, Failover, and Component Availability

Deploying Web applications to a cluster

Web applications can be distributed by deploying them to an EAServer cluster. A distributed Web application can provide better performance since multiple machines can handle more load than one. Clusters also provide high availability: if one machine goes off-line, clients can connect to another server in the cluster.

Clustered Web application requirements

To deploy your Web application in a cluster, you must have a mechanism to support load balancing (and optionally failover), configure a mechanism to replicate HTTP session data between servers in the cluster, and make sure your code supports distributed deployment.

Load balancing and failover

Since the HTTP protocol does not support failover and load-balancing, you must configure a system to redirect client requests that use one logical host name to the cluster servers. You can do this using one of the following solutions:

Use the EAServer Web server redirector plug-in, running in Apache or another supported Web server. For information on this option, see the EAServer Installation Guide for your platform. This option allows load-balancing, but not high availability. The Web server can be a single point of failure in your configuration.
Use Round Robin DNS (RRDNS). RRDNS is a standard feature in many operating systems, and no extra hardware is required. RRDNS allows HTTP requests to be routed in a round-robin fashion to different Web servers. For information on the advantages and disadvantages of RRDNS, see the O’Reilly article Web Applications Load Balancing. RRDNS provides load balancing, but not high availability. The RRDNS service can be a single point of failure.
Use another third-party address-redirection system that performs HTTP load-balancing and failover, such as:
- The BIG-IP hardware load redirector, from F5 Networks
- The Local Director hardware load redirector, from Cisco Systems
- If you have a cluster of Windows 2000 Advanced servers, you can use built in features for network load balancing across a cluster. Similar functionality is available for NT. For more information, see the Microsoft MSDN article Building a Highly Available and Scalable Web Farm.

Session data replication

If a Web application is distributed and running in a cluster, EAServer replicates session data to all servers in the cluster, using one of the following mechanisms:

Persistent storage: EAServer stores session data in a persistent data store to support shared sessions and session failover.
In-memory replication: EAServer replicates session data between pairs of servers, each of which acts as a backup for the other. This feature can improve performance by avoiding the overhead of writing to the database.

You must configure one of these options, as described below.

Coding considerations

No changes are required to your servlet and JSP implementation code to support distributed sessions, as long as:

You are managing session data using the servlet session APIs or some other mechanism where storage is not tied to the host server (such as an EJB session or entity bean).
You use a database (or an EJB entity bean that connects to a database) to store global data. You can use the Web application’s environment properties to store global read-only data.

Since session data is bound to a single user, you cannot use sessions to store global read-write data. Many applications use ServletContext properties to store global data, but the ServletContext is not global to a distributed application and cannot be used as a read-write shared-memory store.

Configuring in-memory HTTP session replication

EAServer can distribute HTTP session data using in-memory replication rather than database storage. This feature can improve performance by avoiding the overhead of writing to the database. This mechanism uses the mirror-pair replication model described in “Requirements for in-memory stateful failover” in Chapter 29, “Configuring Persistence Mechanisms,” in the EAServer Programmer’s Guide.

Enabling in-memory replication for a Web application

These steps must be performed in EAServer Manager, while connected to the primary server for your EAServer cluster:

Select the Distributed checkbox on the General tab in the Web Application Properties dialog box.
Install the Web application to one or more logical servers that are part of the cluster.
Configure mirror pairs for the cluster as described in “Cluster configuration for in-memory failover” in Chapter 29, “Configuring Persistence Mechanisms,” in the EAServer Programmer’s Guide.
On the All Properties tab, set the com.sybase.jaguar.webapplication.distribute.type property to “inmemory”.
Synchronize the cluster.

Changing the cache size

The default cache size and entry time out values are unlimited. To change these settings:

In the master server installation for your cluster, create the directory ObjectCache in the Repository directory your EAServer installation if it does not exist.
In this directory, create a text file named HttpSessionCache.props if it does not exist.
Edit HttpSessionCache.props in a text editor, and enter the following lines:
```
com.sybase.jaguar.objectcache.name=HttpSessionCache
com.sybase.jaguar.objectcache.size=size
com.sybase.jaguar.objectcache.timeout=timeout
com.sybase.jaguar.objectcache.sync=mirror
```
Where timeout is the timeout value, in seconds, and size is the size in megabytes, kilobytes, or bytes with the syntax shown in the following table:
Syntax

To indicate
nM or nm
n megabytes, for example:

512M
nK or nk
n kilobytes, for example:

1024K
n
n bytes, for example:

536870912
Synchronize the cluster to apply the changes to other member servers.

Syntax	To indicate
`nM` or `nm`	n megabytes, for example: 512M
`nK` or `nk`	n kilobytes, for example: 1024K
`n`	n bytes, for example: 536870912

Configuring persistent session storage

When using this option to replicate session data, EAServer stores all session data in a remote database, connecting through the predefined JDBC connection cache ServletPersistenceCache. All servers in the cluster share the same database. Sybase recommends that you configure this cache to connect to an enterprise-grade database server. The database cannot be shared between servers that are not running in the same EAServer cluster.

The sample ServletPersistenceCache properties must be changed As preconfigured, the ServletPersistenceCache connects to the sample database that is included with the EAServer sample applications. This sample uses the evaluation version of Adaptive Server Anywhere, which does not allow connections from multiple hosts. You must use another database that allows connections from multiple hosts, and supports the number of connections required by your cluster.

Configuring persistent session storage

These steps must be performed in EAServer Manager, while connected to the primary server for your EAServer cluster:

Select the Distributed checkbox on the General tab in the Web Application Properties dialog box.
Install the Web application to one or more logical servers that are part of the cluster.
Configure the properties of the connection cache named ServletPersistenceCache to connect to the database that you use for persistent session storage. This cache must use JDBC and have cache-by-name access allowed. See Chapter 4, “Database Access,” for instructions.
Make sure the ServletPersistenceCache cache is installed in each logical server where the Web application is installed.
If using a database other than Sybase Adaptive Server Enterprise or Adaptive Server Anywhere, create a table as described in “Creating the database table”.
Synchronize the EAServer cluster to propagate the configuration changes to other servers in the cluster. See “Synchronization” for more information.

Creating the database table

If you are storing session data in a database other than Sybase Adaptive Server Enterprise or Adaptive Server Anywhere, you must manually create the table that stores the session data. Create a table named ps_HttpSession with the following schema:

Column	Data format
ps_key (primary key).	Variable length binary, 255 bytes maximum length, cannot be null.
ps_size	Integer, cannot be null.
ps_bin1	Variable length binary, 255 bytes maximum length, can be null.
ps_bin2	Variable length binary, 255 bytes maximum length, can be null.
ps_bin3	Variable length binary, 255 bytes maximum length, can be null.
ps_bin4	Variable length binary, 255 bytes maximum length, can be null.
ps_data	Binary large object. This type must be functionally equivalent to a Sybase image type. The JDBC driver used by the specified connection cache must allow access to the ps_data column using the JDBC setBytes and getBytes methods.

The following table definitions can be used for creating an Oracle 8.1.7 database:

PS_KEY RAW (255) NOT NULL, PS_SIZE NUMBER NOT NULL, PS_BIN1 RAW (255), PS_BIN2 RAW (255), PS_BIN3 RAW (255), PS_BIN4 RAW (255), PS_DATA LONG RAW