HP-UX OSRA for Web Services 2.5 Blueprint and Configuration Guide

3 Load Balancing and Cluster Configuration
This chapter explains concepts for application server and web server integration and describes
the steps required to successfully configure some of the integration options. The chapter discusses
the following topics:
• “Web Services Sessions” (page 25)
• “Horizontal Scaling of Web and Application Servers” (page 26)
Web Services Sessions
A session is a series of requests to the web server and the application server originating from the
same web browser. Applications use sessions to keep track of individual users. A large amount
of session information can be generated during a session. This information includes a unique
session ID, individual user identification and state information including, security information,
personal information, status, and so on.
For example, during a session the web services software canuse an online shopping cart to keep
track of a customer's potential purchases. If particular shopping items, shopping carts, and session
IDs are not all linked together, the wrong items can end up in the wrong cart.
Application server software distinguishes users by their unique session IDs. The session ID can
be stored in a web browser as a cookie, or can be delivered back and forth between the web
browser, web server, and application server throughout the session. In some cases, requests are
made over HTTPS or Secure Socket Layer (SSL) connections. These sessions can use SSL
information for session identification.
Session State Replication
Failover and load balancing require the session state to be replicated on different servers in a
cluster. Session state replication enables a client to get session information from another server
in the cluster when the original server on which the client established a session fails. The state
can be system state or application state (application state contains the objects and data stored in
an HTTP session, while the system state contains status of the environment that the application
is running in). The goal of session replication is to maintain session details if a cluster member
becomes unavailable.
Maintaining session persistence in a cluster can be a simple scenario where session information
is stored on a single server, while other cluster members are unaware of any of this session
information.
A cluster can be implemented so that each cluster member is aware of the session state of other
cluster members, with the session state periodically propagated to all (or preferably, one or two)
cluster members. This type of session is known as a replicated session.
There are three ways to implement replicated session persistence:
• Memory-to-memory replication, where the individual objects in the session are serialized
to a backup server (or servers) as they change.
• File system replication, where session information is written to and read from a centralized
file system.
• Database replication, where session data is stored in a relational database.
Database and file system replication limits scalability when storing large or numerous objects
in the session. Every time a user adds an object to the session, all the objects in the session are
serialized and written to the database or shared file system.
There are cases where session data is not replicated. In these sessions, all web requests are directed
to the same web or application server by load balancing hardware or software. These sessions
are called sticky sessions or session affinity.
Web Services Sessions 25