Accessibility
Michael Collins

Michael Collins

Adobe Systems

Created:
9 January 2006
User Level:
Beginner
Products:
Coldfusion

Case Study on Implementing ColdFusion Failover

If you ever set up a ColdFusion production environment, you undoubtedly considered how to manage failover with ColdFusion servers. Several solutions exist and any of us who have dealt with that situation could write a book on all the possibilities.

In this case study, I examine the strategy of an Adobe customer, Recruitmax, based in Jacksonville, Florida. Recruitmax sells several award-winning human resource software products entirely written in ColdFusion. The key to Recruitmax's growth has been its ability to tailor their ColdFusion-based products to each of their individual clients. Their ability to customize their products easily has been rewarded with tremendous growth. Along with the growth came the need for planning a new architecture for managing failover with ColdFusion.

This is a case study of their solution.

ColdFusion MX7

ColdFusion Failover and Session Replication

Before diving into the case study, I want to review the main components of their solution. The main goal of supporting a 24/7 environment is creating a situation where you can remove one or more servers and still have users interact with the web-based application in a seamless fashion. The ability of one server to pick up the user's requests is called failover and the ability to regain a user's session is called session replication. Through ColdFusion, you can set up failover and session replication to occur when you use the connector-based clustering feature set. Let's take brief look at the most important parts of ColdFusion clustering, especially in relation to the Recruitmax solution.

ColdFusion Clusters and Session Replication

You can define clusters with the ColdFusion Administrator using the ColdFusion MX 7.x Multi-Instance version or within the JRun 4.x Management Console. Once you define a cluster, ColdFusion MX tracks which servers are in a cluster through the cluster name. The servers operate as individual server instances and you can continue to access them individually using the internal JRun web server.

As soon as you define a cluster, sessions on all cluster members begin to replicate using the JRun in-memory session replication technology. Server instances that are members of the cluster can be on the same physical server or another remote physical server. For more information about how to set up ColdFusion MX clusters, see Enabling Clustering for Load Balancing and Failover in the ColdFusion LiveDocs.

ColdFusion Web Server Connectors and Failover

To benefit from failover in your cluster, you must use a ColdFusion connector that bridges a ColdFusion MX server instance to an internal or external web server. If you don't use clustering, you would normally have to configure the connector between one website and one ColdFusion MX server instance. With clustering, you use the cluster name instead of using a ColdFusion MX server instance name. If you use the Web Server Configuration Tool, the cluster name appears in the same list as the server instance names.

The Web Server Configuration Tool operates exactly as if you were setting up a single ColdFusion MX instance. After setting up each website as you would with one instance, the connectors will operate with their built-in intelligence to assess whether a server is down, and then route requests to other cluster members. When the server returns online, the connector discovers its online status and returns it to its routing table. For more information about configuring web servers, see Enabling Clustering for Load Balancing and Failover in the ColdFusion LiveDocs.

Understanding Load Balancing Routers and HTTP Probes

Just about every enterprise environment has a load balancing router in front of their web servers. ColdFusion clustering works well with this environment. You must set up each web server with a connector to communicate to your defined cluster. For instance, if you have three physical web servers running IIS, you will need to define a connector for each server that links to your cluster name. The ColdFusion cluster may be on one server or perhaps three servers. For best results, Adobe recommends that you use sticky sessions when distributing load with your load balancing router.

Another popular feature of load balancing routers, such as some Cisco products, are HTTP probes. You define an HTTP probe in the router to make a call to a web server of your choosing and get some defined results. If the results are not as expected, you can take an action, such as running a script file or executable. There are too many vendors and products to list instructions on defining HTTP probes. Find documentation appropriate for your vendor through their website and then look for information on setting up HTTP probes.

The Recruitmax Failover Solution

Now that you've learned about some of the most important factors for clustering servers, let's look at how Recruitmax puts ColdFusion clustering to work.

Recruitmax administers hundreds of ColdFusion servers to support their customer base. Their customers have each taken one of their core products and customized the ColdFusion code to meet their organizations' requirements. This level of customization gives Recruitmax tremendous opportunities for tailoring products to exact customer specifications, but it also introduces some administrative challenges to ensure server uptime.

By combining ColdFusion clustering features with Cisco router HTTP probes, Recruitmax found that that when issues arise, their applications keep on ticking, allowing end users to continue working seamlessly.

According to Rick Bohm, a software engineer in charge of the Recruitmax Data Center, "We have seen a 300% overall performance increase after implementing ColdFusion MX clustering together with HTTP probes." They began seeing these improvements after implementing the ColdFusion MX connector-based load balancing together with the probes.

Recruitmax set up the probes to make requests to each member of a cluster using the internal JRun web server. If the probe does not return the expected status code, it is instructed to restart the ColdFusion instance that reported the issue. While it restarts the instance, the connector redistributes the load to the other cluster members. Because sessions have been replicated, users can continue working without interruption.

The connector itself offers server-issue detection based on network connectivity, while the HTTP probe goes much deeper into the application to determine better the health of all major components of any application. The probes they use are custom-written CFML pages that look at several factors to determine whether the server is stable.

When the probe triggers a restart process, the connector's session replication is used to ensure that all current user session data exists on all cluster members.

Recruitmax has experienced many benefits from implementing clustering with ColdFusion MX 7. They can administer servers much more easily and with more control, keeping their customers satisfied with reliable stability. End users do not experience interruption in an application if an issue occurs.

Where to Go from Here

The goal of this case study was to show you how one customer successfully uses ColdFusion clustering. If you wish to use any of the techniques in this article, go to the ColdFusion Developer Center Clustering topic page. The articles you find there will be extremely useful to help you learn how to set up your own ColdFusion MX failover architecture.

For more assistance with setting up your own environment, you may also contact Adobe Support.

About the author

Michael Collins started at Macromedia in 1999 within Professional Services, assisting customers with their performance tuning, load testing, architecture planning, code reviews, and customized training. He is currently a senior technical support engineer at Adobe Systems, assisting Gold Server Support customers utilizing ColdFusion, JRun, and Flex.