Session Persistence

Many of today's most challenging load balancing issues involve recognizing and understanding the nature of individual application requests and responses. ZXTM can read and understand requests, and then direct appropriately, maintaining application sessions where required.

Quick Links

How does ZXTM manage persistent sessions? 

Session persistence classes
Click the image to enlarge

Many complex applications maintain a large amount of information about each user. For example, an e-commerce application may have to store the details of the items that each user has in their shopping basket, as well as their payment status.

Such applications often store their state locally, and hence do not run well in a clustered environment. Sharing and updating the state across all the application servers in the cluster may be difficult or even impossible. To deal with this problem, the front-end load balancer must ensure that all requests in the same user's 'session' are routed to the same back-end application server.

ZXTM can achieve this in a variety of ways. The simplest and most transparent way is to employ ZXTM's Session Affinity, which allows individual URL mappings to be specified as 'sticky'. All requests that match a particular criteria can be directed to the same cluster of machines, and sessions are automatically honored.

How can I remove back-ends from the cluster without disrupting sessions? 

Draining a node of connections
Click the image to enlarge

Session persistence is a powerful tool, until you need to remove or shut down a back-end server machine. Once the machine is unavailable, all the existing sessions to that machine will fail.

ZXTM also allows you to indicate that a back-end machine should stop receiving new connections; this is referred to as 'draining connections' from the back-end. When ZXTM is draining a machine, it stops sending new connections to that machine. However, it will forward established session connections to the machine so that the session is not disrupted.

ZXTM indicates how long each back-end has been idle for. This helps you judge whether or not all existing sessions have timed out, and hence when it is safe to remove the back-end from the cluster.

© Zeus Technology Ltd