Accessibility

Managing Clusters with Enterprise Manager and Packaging Applications in ColdFusion MX 7

Geoffrey Greene

Macromedia

Erik Tierney

Macromedia

Before Macromedia ColdFusion 4.0, ColdFusion had no built-in High Availability (HA) features. Administrators could use a hardware load-balancer to distribute requests to web servers, but this was an expensive option (ColdFusion 4.0 was released in 1996). We introduced ClusterCats with ColdFusion 4.0, which provided clustering and load-balancing out of the box for customers who bought Macromedia ColdFusion Enterprise. Then, with the introduction of ColdFusion MX, ColdFusion again had no built-in HA features—while the move to Java/J2EE in ColdFusion MX brought many benefits, it excluded ClusterCats.

One of the main benefits of moving to J2EE was that it gave ColdFusion the ability to take advantage of features provided by the underlying application server. Since ColdFusion is a certified J2EE application, it can run on any certified (any many non-certified) J2EE application server. The two most prominent application servers are BEA WebLogic and IBM WebSphere. Both of these provide robust HA features and multiple instance support, but add to your budget cost. Meanwhile, if you buy Macromedia ColdFusion Enterprise version, you have to get an application server too.

Most of you already know that Macromedia JRun, a popular and easy-to-use J2EE server, is the underlying application server for ColdFusion. JRun is a full-featured J2EE application server with clustering and multiple-instance support. However, if you’re not familiar with J2EE, the JRun Management Console (JMC) can seem daunting. Setting up a new application server and deploying ColdFusion to it requires some knowledge of J2EE concepts. And clustering inside JRun is entirely proprietary; it is yet another area of knowledge to master. Likewise, if you deploy to BEA WebLogic or IBM WebSphere, you must also become familiar with their administrative functions to deploy instances and manage HA features individually, as these are not part of the J2EE specification.

With ColdFusion MX 7, our goal was to make it easy for you to use multiple instances and to reintroduce HA features. Thus, we created the ColdFusion Enterprise Manager, a feature that is part of the ColdFusion Administrator. It’s available to users who have installed the Enterprise version of ColdFusion MX 7 and provides a user interface for configuring multiple servers and managing clusters.

Requirements

To complete this tutorial you will need to install the following software and files:

ColdFusion MX 7

Note that ColdFusion MX 7 makes connector and application server clustering available to you, but it does not give you front-end web server clustering. If you have two web servers in front of your application server cluster, you must use a domain name server (DNS) or other hardware. This article explains how to use one web server with multiple ColdFusion instances.


Installing ColdFusion MX 7 Enterprise Manager

To use the Enterprise Manager, you must purchase and install ColdFusion MX 7, Enterprise version. During the install process, you must install ColdFusion selecting the multiserver option. Once you have installed ColdFusion, open the ColdFusion Administrator (by default, this is http://hostname:8300/CFIDE/administrator). Select Enterprise Manager from the menu options and you will see the choices for creating instances and clusters.

The Packaging and Deployment and Enterprise Managers in ColdFusion Administrator

Figure 1. The Packaging and Deployment and Enterprise Managers in ColdFusion Administrator

Configuring Multiple ColdFusion Instances

The term, multiple instances (sometime called multiple servers), refers to the ability of J2EE servers to deploy multiple copies of an application server to a single computer. Technically, you deploy one new JVM (Java Virtual Machine) per server instance. The benefit is simply that each new application server has its own process to use; when one server fails, the failing server won’t affect other processes. This is called process isolation. In ColdFusion MX 6.1 Enterprise edition, you could configure multiple ColdFusion servers, though it was a highly manual process and required that you use the Java Management Console (JMC) and understand J2EE. With ColdFusion MX 7, you can create multiple ColdFusion servers on a single computer through the ColdFusion Administrator, with no manual steps. Each new ColdFusion server instance has its own ColdFusion Administrator. In short, each server has its own separate configuration, as if it were a ColdFusion server running on another physical computer. It is possible to configure a cluster comprised of servers that reside on a single computer too.

Creating multiple instances is easy. Use the following steps.

  1. Ensure that you have installed ColdFusion MX 7 using the multiserver configuration.
  2. Open the ColdFusion MX Administrator for the cfusion server in a browser (with a default installation, this is located at: http://hostname:8300/CFIDE/administrator).
  3. Select Enterprise Manager > Instance Manager.

    Creating a new instance in the Instance Manager

    Figure 2. Creating a new instance in the Instance Manager

  4. Click Add New Instance.
  5. Specify the following in the Add New ColdFusion Server area:

    • Server name
    • (Optional) Directory that contains the server instance. The ColdFusion MX Administrator fills in the default automatically (jrun_root/servers/servername).
    • (Optional) Create from EAR/WAR. If you use the J2EE Packaging feature to create a J2EE archive file with your application's files (including CFM, CFC, and CFR files) and data sources, use this field to specify the EAR or WAR filename and create a server instance with your application deployed automatically.
    • (Optional, Windows only) Specify whether to create a Windows service for the server instance and whether to define the Windows service with an auto restart recovery option.
  6. Click Submit.

    The ColdFusion MX Administrator creates a server instance with ColdFusion MX deployed in it and starts the server instance. The ColdFusion MX application that it deploys is based on the application archive file specified in the Create from EAR/WAR field or on the cfusion server instance (if you don't specify an EAR or WAR file).

    Creating a JRun server instance and deploying the ColdFusion MX application can take a few minutes.

  7. Click Return to Instance Manager.

Configuring Load Balancing

Of the two HA methods, load balancing is simpler to implement and configure. You use it to distribute requests across a number of computers, based on an algorithm for determining load. You can distribute requests with a simple method, such as a round-robin configuration (which isn’t technically load balanced), which sends requests to each computer in a sequence. Or, you could use a more complex distribution method based on CPU utilization. If you distribute load based on CPU utilization, you must use some sort of method to report the CPU load back to the load-balancing software. You can configure JRun clustering features to act as a simple load balancer, handing requests to the cluster members. There are three algorithms you can use to distribute load: round robin, weighted round robin and random round robin. Strictly speaking, these are not load balanced options. However you can use weighted round robin (WRR) to simulate a more complex load-balance configuration. By using WRR, you apply a weight to each machine in the cluster so that in a mixed-hardware environment where some machines may be more powerful than others, JRun sends a proportional request volume to more robust machines. Random round robin (RRR) distributes requests machines in the cluster randomly. As I mentioned earlier, round robin (RR) distributes requests sequentially to cluster participants.

Configuring a cluster with weighted round robin request distribution

Figure 3. Configuring a cluster with weighted round robin request distribution

Configuring Clustering

Load balancing is not usually "application aware," its job is simply to route incoming requests. Session replication does not make the cluster application aware. The connector only routes requests if the server is running; the connector does not evaluate application status. The only approach that is application-aware is to use hardware. The cluster manager copies session data to each node in the cluster so that your application users do not experience any change in state, in the event of a server failure. You can configure sessions to be “sticky,” in which case, your setup routes a particular user to the same node for the duration of the session. In any event, sticky sessions or not, replicated data is always up to date on every node at the moment your application requests it.

Another thing to note is that there are no changes in the way you use the session object in your CFML code to take advantage of session replication. The cluster manager works under the covers and is entirely invisible to your application. An important aspect of session replication to keep in mind, however, is that since this feature is not part of the J2EE specification, the behavior of session replication is not consistent across the range of app servers that support it. Some application servers (such as IBM Websphere) explicitly document the fact that they will only replicate instances of classes found in the JDK. This means that if you develop an application that uses a session object that you may deploy on another app server other than JRun at some point, be conservative about the type of objects you store in session. Anytime the session changes it must replicate all of the session data for that request. This process can cause a lot of overhead if you store a lot of data in a session.

Protecting Applications with WAR and EAR Packaging and Sourceless Deployment

The J2EE specification defines the constituents that comprise a web application. This is a collection (in J2EE terminology) of servlets, JSP files, Java classes, HTML files, images, and other content. The specification defines, specifically, XML deployment descriptors and a directory structure so you can port WAR files between J2EE application servers. The EAR file is a superset of the WAR file and defines an additional collection of J2EE assets. These are (again, in J2EE terminology) EJBs, data sources, JNDI contexts, and WAR files. An EAR file can contain one or more WAR files. Luckily for our purposes, this discussion is largely academic.

ColdFusion MX 7 (all editions) automates the task of creating J2EE archives. From the ColdFusion Administrator inside any edition of ColdFusion MX 7, you can create a WAR or EAR file from a specified set of application directories. Whether your choose EAR or WAR is entirely driven by the deployment environment (for example, Tomcat is a servlet engine and only accepts WAR files). To deploy a WAR/EAR, however, you need an Enterprise license.

One of the new options we developed for ColdFusion MX 7 is the ability to write a ColdFusion application and deploy it without distributing the source code when you create an EAR or WAR file. If you select this option, called the Sourceless Deployment option, the CFML files that comprise your ColdFusion application are excluded from the archive, but your application will still run (the package contains only Java bytecode in this instance). The EAR or WAR package option protects your intellectual property more than previously possible, in ColdFusion. Humans cannot read the Java bytecode. And even when a user decompiles the bytecode, it unpacks to Java bytecode, which is still very different from CFML.

We created this option by compiling the ColdFusion files into Java bytecode. If you expand the archive, you can still see your application’s directory structure and files (images, style sheets, and so forth), even if users cannot access the files that comprise your application. However, if a user deploys the archive and tries to open any CFML files, he or she will see Java bytecode, not CFML. Give it a try, you’ll see bytecode completely obscures your application logic.

 Creating a WAR package to deploy on another J2EE application server

Figure 4. Creating a WAR package to deploy on another J2EE application server

To add a new archive definition and create an archive file:

  1. Open the ColdFusion MX Administrator.
  2. Specify a unique name for the archive file (no extension) in the Archive Name field.
  3. Click Add. The Add New Archive screen appears.
  4. On the Add New Archive screen, specify archive settings such as: Include CFML Source, Include ColdFusion MX Administrator, Data Sources (to include), and more.
  5. Click Create. ColdFusion creates an EAR or WAR file in the specified application distribution directory.

In this article, you have learned the basics of clustering and instance management for high availability with the Enterprise Manager, available in ColdFusion MX 7 Enterprise edition. ColdFusion MX 7 simplifies the process for setting up and managing clustering, load balancing, and failovers. This article also introduced sourceless deployment packaging options. We hope you find the Enterprise Management feature a powerful and enjoyable experience.

About the authors

Geoffrey is a former senior software developer at Macromedia, who previously worked on the ColdFusion MX for J2EE product series.
Eric has worked at Macromedia since 2001. He is one of the senior engineers for ColdFusion, and has worked on every release since ColdFusion 5.