Among the many features provided by Macromedia's Web server clustering solution, ClusterCATS provides a feature called session-awareness. Session-awareness ensures that when a session begins on a particular clustered Web server, it will remain on that server until it is complete.

ClusterCATS load balancing will not threaten to move any session from a particular server in a session-aware or sticky cluster to a different server in that cluster. Subsequent inbound sessions are prone to redirection based on intervention queued by the intelligent decisions of the clustered server's load-balancing algorithm. This algorithm works together with load information provided by the rest of the clustered servers.

In ColdFusion 5.0, session-awareness has been enhanced from previous versions by incorporating interaction between cookies and the HTTP referred_by field; the referred_by field adjudicates in the absence of cookies.

Two general approaches exist to maintaining a ColdFusion session state. The first technique is to have a common state repository using Client Variables and persist all per-client data. If the storage is shared, any server can serve the client. This approach provides better reliability and does not require session-awareness when the Web servers are clustered.

The second technique is to use session variables. When you place servers running with session variables into a cluster, session-awareness binds the client to the server that contains its in-memory state. This approach provides better performance.

In practice, some combination of client and session variables may be optimal. This article provides two session-aware management tips. The article assumes that you are using session variables in a clustered environment and require session-awareness. The first example-based procedure will demonstrate how to customize an error message to help your customers refill their shopping cart if state is lost due to a disk crash or hardware failure. The second procedure describes how to allow third-party sites to set up resilient, failover-enabled links to content on your session-aware cluster.

Our working example
When session-awareness is used in conjunction with DNS RoundRobin distribution, the URL line in the client browser will actually change from the RoundRobin name to the actual name of the sticky server as each session is locked down onto a particular server. Let's illustrate using the following fully qualified host names and IP addresses properly configured in DNS:

When a browser hits stickypage.cfm at www.central-orders.com in a session-aware cluster, the URL line in the browser will change to either www1.central-orders.com or www2.central-orders.com matching the server on which the session is locked. If a session is started on www1.central-orders.com, it will remain immune to any redirection away from www1.central-orders.com, triggered by the load-balancing algorithm.

Figure 1: ClusterCATS changes the URL line.

Part I: Editing the error URL message
Continuing to follow our example, if www1.central-orders.com crashes or disappears then its IP address (192.168.25.1) would failover to its cluster-mate www2.central-orders.com, interrupting the sticky session. In this case the browser will pop up a message as follows:

stickypage.cfm is not currently available in cluster central_orders

Following our example, trying to browse stickypage.cfm on server www1.central-orders.com in the completely busy cluster central_orders returns the error stickypage.cfm is not currently available in cluster central_orders. We do not like this error and would like it to read:

Wow! Bang! Something very bad just happened to the Web server hosting your session. Please go back to www.central-orders.com and refill your shopping cart on a new server. We apologize for the inconvenience.

In the following procedure, you will add a value called "ErrorUrl" to each desired ClusterCATS server registry key. This value will specify the name of the file, sorry.htm, relative to the server's document root. The registry editing procedure is different for Window NT and Solaris/Linux platforms.

For Windows NT:

For UNIX:

NOTE: Solaris/Linux versions of ClusterCATS uses a file called bt.registry that is similar to the Windows NT registry. The following procedure requires that you manually edit the file. Be careful because this ordinary text file requires precise formatting requirements.

Part II. Enabling third-party sites to set up resilient links to a session-aware cluster
To illustrate this scenario, we will add some third-party servers to our example as shown in the following diagram:

Figure 2: Third-party server opens a session.

As soon as any browsing customer hits a link on a third-party server that points to your session-aware site, that third-party server has opened a session. All subsequent hits through that same third-party link will be redirected to the same server in your cluster. If that server fails, the link on the third-party server will receive the customized error URL from the previous step. To provide uninterrupted service in the event of a server failure running CF 4.5X in this sticky session-state scenario, you must provide a nonsticky redirection page to connect the third-party link to your session-aware cluster. The best way to set this up is to add to our example. Go to your DNS server and add two more entries to facilitate adding a non-session-aware cluster to your Web server:

The following diagram illustrates this technique:

Figure 3: How to place a redirection page at the document root.

This technique works with ColdFusion 4.5.X, but it does not work with ColdFusion 5.0. In ColdFusion 5.0, ClusterCATS uses an enhanced means of maintaining session-awareness. For ColdFusion 5.0, the recommended solution is to either provide a link on a customized error URL page as illustrated in the first part of the article, or operate using the server-monitoring agent rather than clustering.

The following article provides information about the server-monitoring agent:
http://www.allaire.com/Handlers/index.cfm?ID=21570