Macromedia
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.
To complete this tutorial you will need to install the following software and files:
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.
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.
Figure 1. The Packaging and Deployment and Enterprise Managers in ColdFusion Administrator
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.
Select Enterprise Manager > Instance Manager.
Figure 2. Creating a new instance in the Instance Manager
Specify the following in the Add New ColdFusion Server area:
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.
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.
Figure 3. Configuring a cluster with weighted round robin request distribution
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.
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.
Figure 4. Creating a WAR package to deploy on another J2EE application server
To add a new archive definition and create an archive file:
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.