Accessibility
 
 
ColdFusion Clustering in a Distributed Configuration
 By: Dave Gruber
Product Manager for Allaire's Web Systems Management Solutions

This article describes the recommended configuration for clustering in a distributed ColdFusion server environment where the Web servers are separated from the ColdFusion application servers.

Multiserver Processing

ColdFusion has offered clustering capabilities since Version 4.0, released in late 1998. Clustering enables multiple ColdFusion servers to be joined together to increase the capacity and availability of the site. The recent release of ColdFusion server, version 4.5.1, introduced support for running a distributed ColdFusion configuration within a clustered environment as a distributed ColdFusion server cluster. This new feature enables the separation of HTTP server processing from ColdFusion application server processing. In other words, the ColdFusion server can now run one system and the HTTP Web server on another.

Distributed ColdFusion Processing

There are a number of cases in which it is important to separate HTTP server processing from ColdFusion server processing by running in a distributed ColdFusion configuration. Here are some examples why a site may need to be implemented in a distributed configuration:
  1. The site may require a firewall between the Web server and the application server
  2. The site may require all database access to occur behind a firewall
  3. The site may have a significant amount of non-ColdFusion traffic and thus require significantly more HTTP-server capacity than ColdFusion-server capacity

Configuration Options

A distributed ColdFusion server cluster can operate in a one-to-one or a many-to-one configuration of Web servers to ColdFusion servers. Here's the simple configuration rule: the number of Web servers must be equal to or greater than the number of ColdFusion servers. Each Web server must point to a specific ColdFusion server. If you have more Web servers than ColdFusion servers, multiple Web servers will have to point to the same ColdFusion server. For example, if a configuration includes three Web servers and two ColdFusion servers, the first two Web servers point to the first ColdFusion servers, and the third Web server points to the other ColdFusion server. The frontend Web servers are then clustered together; that is, all three Web servers would form the cluster.

To ensure a highly available server infrastructure, be sure to run at least two ColdFusion servers for your site. Remember, even if you have a lightly loaded site, there will be times in which your application crashes or when you want to take an application server off-line for maintenance.

Load Balancing in a Distributed ColdFusion Server Cluster

To balance load correctly in a distributed ColdFusion server cluster, the round-trip-rime (RTT) load-balancing method should be used. This method measures the RTT of a request as it travels through the Web server to the ColdFusion server and back. It takes into account the load generated both by the HTTP requests (served only by the Web server) and by the ColdFusion server processing .CFM requests. The configuration for this method is described in the Administering ColdFusion Server manual. Other approaches are possible. For example, combining average request time with RTT gives more weight to the time required for processing on the distributed ColdFusion servers.

Session Management

If a developer needs variables to persist in the event of a failure, he or she should use client variables and store them in a remote data store. Detailed instructions on how to accomplish this can be found in the "Enabling External Client State Management" section of the Administering ColdFusion Server manual.

If you are using session-aware load balancing in your cluster because your application uses session variables, the same rules apply as in running a standard, nondistributed ColdFusion cluster. If the ColdFusion server fails for any reason, session variables will be lost. Clustering detects this condition and offers you the ability to display a custom URL notifying the user of the condition and providing further instructions on how to proceed. Again, this feature is identical to a standard nondistributed cluster. If you need to have your variables persist in the event of a failure, you will need to use client variables and store them in a remote data store. Detailed instructions on how to accomplish this can be found in the "Enabling External Client State Management" section of the Administering ColdFusion Server manual.

Failover in a Distributed ColdFusion Server Cluster

As in a standard cluster, there are two failure conditions to be concerned with: physical server failure and ColdFusion service failure. The Web servers are clustered together, so in the event that one fails, another healthy Web server in the cluster will assume the IP address of the failed server. This is a standard clustering feature.

To protect against a ColdFusion application server failure, you need to configure a ColdFusion URL probe for each of the Web servers. To create this probe, you'll need to use ColdFusion's ClusterCATS Explorer, the administrative interface to ClusterCATS, Allaire's Clustering solution. Once the probe is running, it will detect the failure of the ColdFusion server for any reason and will restrict the server, preventing additional requests from starting on the Web server and associated ColdFusion server. New requests will be redirected to another clustered Web server connected to a healthy ColdFusion server until the failed ColdFusion can once again be probed successfully.

(Note: The restart probe option is not available in a distributed ColdFusion server cluster configuration. This is the only clustering feature that is unavailable in this configuration. Therefore, in the event that ColdFusion fails, an email notification will be sent immediately, but the server will not be restarted by the probe.)

Specific Configuration Information

Specific detail on installing and configuring a distributed ColdFusion server cluster can be found in the following two Allaire Knowledgebase articles:

About the Author

Dave Gruber is currently the Product Manager for Allaire's Web Systems Management solutions, which includes Allaire's clustering solutions and the upcoming new Harvest product. Harvest will provide multiserver management and monitoring, application deployment capabilities, and service-level reporting.

Dave joined Allaire in the spring of 1999 with the acquisition of Bright Tiger Technologies. At Bright Tiger, Dave was the Director of Systems Engineering and was the product evangelist for the award winning ClusterCATS product, now shipping with Allaire's Enterprise class solutions.