High availability clustering ColdFusion: Using ColdFusion Enterprise Manager

ColdFusion is increasingly in use in large enterprise environments many of which inevitably employ clustering of resources to provide redundancy and scalability. ColdFusion employs the underlying J2EE clustering paradigms and via Enterprise Manager in ColdFusion Administrator GUI provides a way to cluster our ColdFusion instances.

For ColdFusion developers and engineers it is important to consider clustering from the start when planning for ColdFusion applications. It is almost certain that enterprise applications will be clustered at some point and failure to plan with clustering in mind can cause difficulties later on.

By the end of this article you will be able to create instances in ColdFusion and cluster them.

In essence clustering means combining two or more resources (members) so that they appear as a single resource. The main reasons for clustering are redundancy, so that failure of one resource does not result in the failure of the application and scalability, which enables an application to handle more users as traffic increases by adding cluster members. One other important benefit in clustering ColdFusion is encapsulation. Encapsulation enables you to keep discrete applications or processes in their own dedicated instance. This might be done for security reasons or to segregate load intensive processes such as scheduled tasks. These two principle needs are addressed by clusters that support failover and load balancing.

Note: as you learn more about clustering, you may well hear the term Load Balancer to describe a piece of hardware or software used in clustering. In fact, Microsoft's own software clustering mechanism is called Network Load Balancing or "NLB". These are misnomers because load balancing is a feature of clustering along with fail-over.

Failover

Typically, failover is the most basic need for clustering. In my opinion, every web application needs redundancy so that if something fails the whole application does not fail and become unavailable to users. This level of redundancy is often known as High Availability or HA. Some developers believe that HA is not necessary when an application has a low number of users. If there are any users at all, that shows a need for the application and if there is a need, then the application needs to be available. The good news is that the ColdFusion clustering mechanism supports failover at the instance level. At a conceptual level an instance in ColdFusion Enterprise is equivalent to a stand-alone server in ColdFusion standard; it is a fully encapsulated.

Consider an example of failover in a web application, at the hardware level. In this example the second ColdFusion server in a two server cluster has failed and the clustering mechanism is sending requests to the ColdFusion server that is still responding (See Figure 1). Once you move from one to two of anything, there is a paradigm shift in terms of the availability of the application. If your ColdFusion application is hosted in a data center it is good practice to ask about the levels of HA-redundancy. In particular you should know what their Service Level Agreement (SLA) states. For instance, if a router or switch should fail, how long will it take to be replaced?

Load-Balancing – In load balancing, cluster members are added to enable the application as a whole to handle more users. Typically you will want the load to be distributed evenly around all cluster members. There are several methods or algorithms for load balancing that are used to allocate the load.

The round robin algorithm cycles each request from each user from server to server. As mentioned above, in ColdFusion Enterprise an instance is equivalent to a server, so this concept applies to ColdFusion instances also.

If you are using the Session scope in your ColdFusion application it is not ideal to have users cycling from server to server with each request because they will lose their session information. In this case it is better to keep a user on a particular server once they are assigned there. You can do this by enabling sticky sessions (See Figure 3).

In my experience, round robin with sticky sessions is the most effective algorithm as there is a fairly well balanced distribution of load and the chance of a user losing their session is minimized. The only time that would happen is if one server (instance) were to fail completely.

From a ColdFusion perspective, there have been two iterations of software clustering. The first version of clustering for ColdFusion was called ClusterCATS. This was a proprietary software level clustering and it embraced the concept of a central management piece, which controlled and monitored the cluster. This basically enabled fail-over at the web server level if a cluster member failed. ClusterCATS was a full software based clustering paradigm in its own right with no need for any additional software or hardware device.

The current version of software level clustering in ColdFusion via Enterprise Manager is based on J2EE clustering and is not a full clustering system; it is peer-to-peer at the ColdFusion server-instance level. In its basic form there is no need for a management role, however you will find the use of a management role will make building out clusters at the server-instance level easier and more intuitive. This is an opinion I formed after creating many ColdFusion clusters and it is also based on how clusters are created in JRun. The admin instance in JRun is used purely to create instances and to cluster them, it is not a member of any cluster. The key point is that the current clustering paradigm, which is based on the J2EE-JavaEE specifications is not a full clustering paradigm and will still require the use of a software or hardware clustering device to enable failover at the web server level. This implies a need for an external web server in production environments. JRun web server (JWS) is a built-in web server that comes with ColdFusion Enterprise; however JWS is not recommended for production use. Figure 4 illustrates such a configuration, which uses round robin with sticky sessions. In order to cluster the ColdFusion servers there must be an external clustering mechanism either hardware or software.

In the preceding sections I discussed the theory and purpose of clustering and how that relates to ColdFusion. I also highlighted the differences between the peer-to-peer J2EE clustering employed in ColdFusion and other forms of clustering. This section describes the installation of ColdFusion 8 Enterprise along with the creation and clustering of two instances. This cluster will be a vertical cluster on a single ColdFusion server. In a future article I will discuss "horizontal" clustering where a single cluster can span multiple physical ColdFusion servers.

Installing ColdFusion 8 Enterprise

Having installed ColdFusion many times I have discovered what I believe is the best way to install ColdFusion Enterprise in preparation for clustering. The first instance created, cfusion will serve as a master instance from which the other instances and also the cluster itself is created.

Make sure that you select the second option during the install "Multiserver configuration" (See Figure 5)

Next make sure to use the built-in web server for the install process as shown in Figure 6

Creating Instances

Once the installation use ColdFusion Administrator to access the cfusion instance. This will be used as the master instance from which you will create the cluster instances and the cluster itself. Note the Enterprise Manager section on the bottom left navigation menu as shown in Figure 7

Once the instance creation is complete, a screen like the one in Figure 8 is displayed

For instances created by the cfusion instance the Enterprise Manager section is not present in the left navigation menu. This makes the ongoing creation of instances and clusters more logical since being able to create instances-clusters from an instance could become confusing.

Figure 9 shows the Instance Manager section on the "cfusion" master instance after adding the second instance using the same procedure used to the first instance. You could add other instances at this point using the same procedure…

Deploying ColdFusion Archives

You can use ColdFusion Archives, or CAR files to rapidly create multiple identical instances. Using ColdFusion Administrator, view one of the instances and from the left navigation select Packaging & Deployment > ColdFusion Archives, then browse to where your .car file is located or type in the path to it as shown in Figure 10.

Follow the on-screen instructions to deploy the CAR file (see Figure 11) and a confirmation will be displayed (see Figure 12)

Clustering the created instances

The next steps are to create a cluster, add the instances you created and choose the algorithm to be used. First create the cluster;- typically it is good to give the cluster members and cluster names that are related (see Figure 13). All names must be unique.

Next add the servers/instances to the cluster (See Figure 14)

Figure 14 shows the selection of the Round Robin algorithm with sticky sessions and session replication. It is important to also ensure that Use J2EE Session Variables is selected on all instances to enable session replication functions as shown in Figure 15…

One last important point, after adding the instances it is important to restart them. Once they have restarted check the {instance}out.log for each to ensure they can see the cluster (See Figure 16).

Where to go from here

This article examined clustering and high availability (HA) in the context of web applications and in particular ColdFusion 8 Enterprise. Using a real-world you saw how to install ColdFusion 8 Enterprise on Windows, create the instances and then cluster those instances using the Enterprise Manager in the ColdFusion Administrator.