Deploying components to a cluster  Implementing Sybase Failover for high availability systems

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:

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:

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:

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.

StepsEnabling 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:

  1. Select the Distributed checkbox on the General tab in the Web Application Properties dialog box.

  2. Install the Web application to one or more logical servers that are part of the cluster.

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

  4. On the All Properties tab, set the com.sybase.jaguar.webapplication.distribute.type property to “inmemory”.

  5. Synchronize the cluster.

StepsChanging the cache size

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

  1. In the master server installation for your cluster, create the directory ObjectCache in the Repository directory your EAServer installation if it does not exist.

  2. In this directory, create a text file named HttpSessionCache.props if it does not exist.

  3. 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
    
  4. Synchronize the cluster to apply the changes to other member servers.


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.

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

StepsConfiguring persistent session storage

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

  1. Select the Distributed checkbox on the General tab in the Web Application Properties dialog box.

  2. Install the Web application to one or more logical servers that are part of the cluster.

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

  4. Make sure the ServletPersistenceCache cache is installed in each logical server where the Web application is installed.

  5. If using a database other than Sybase Adaptive Server Enterprise or Adaptive Server Anywhere, create a table as described in “Creating the database table”.

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





Copyright © 2005. Sybase Inc. All rights reserved. Implementing Sybase Failover for high availability systems