Session Persistence

This chapter explains how the Traffic Manager is used to provide persistent sessions (also known as sticky sessions) between clients and back-end servers.

What Is Session Persistence?

Many classes of requests from clients can be load-balanced across a pool of back-end servers. Multiple requests from one client can be shared across the back ends with no disruption to service. However, there are certain exceptions, such as server applications which depend upon storing information about a client locally, which may not readily be load-balanced in this way. These include:

•Web mail applications that track a user’s login by storing files on disk.

•Shopping carts that store the contents of a client’s cart on disk or in memory.

•Programs or protocols with a higher start-up time than normal (such as Java applications or SSL connections).

In these situations, the Traffic Manager can ensure that requests are mapped to the same back-end server for each request, for the duration of the client’s session:

When the Traffic Manager receives a new connection, it uses its load balancing logic to choose a node for that connection. The Traffic Manager then records the chosen node in a session persistence map.

When another connection in the same session is received, the Traffic Manager uses the node that was chosen previously.

In this way, all connections in the same ‘session’ are pinned to the same back-end node. The session persistence class in use defines how a session is identified, and you can refine this decision using several TrafficScript methods.

Session persistence classes can be used to direct all requests in a client session to the same node. This may be necessary for complex applications, where an application session may be maintained over a number of separate connections. Examples of this include Web-based shopping carts, and many complex UDP-based protocols.

Session persistence should only be used when necessary. It effectively bypasses the load-balancing process for all but new sessions, so unless it is necessary to send all requests from the same client to the same back-end node, response times will be better without session persistence.