Wouldn't it be nice to get all the high-availability and scalability benefits of a cluster of multiple servers without the need to purchase multiple machines? How about being able to manage a number of isolated, performance tuned applications on one piece of hardware instead of taking up many machines in your server room?

ColdFusion MX 7 Enterprise Edition introduces the new Enterprise Manager, which will do those things and more. It makes load balancing, application isolation, and deployment management as easy as creating a datasource in the ColdFusion Administrator. In this article, we'll introduce you to the Enterprise Manager and explain how it will make managing and deploying ColdFusion applications easier and more powerful than ever before.

Background
Before ColdFusion 4.0, no high availability (HA) features were built into ColdFusion. One could use a hardware load-balancer to distribute requests to web servers, but this was an expensive option back in 1996. ClusterCats, introduced with ColdFusion 4.0, provided clustering and load-balancing right out of the box for customers who purchased ColdFusion Enterprise. With the introduction of ColdFusion MX, ColdFusion was once again without built-in HA features. The move to Java/J2EE brought many benefits, yet precluded the continued use of ClusterCats.

One of the main benefits of the move to J2EE is the ability of ColdFusion to take advantage of features provided by the underlying app server. Since ColdFusion is a certified J2EE application, it can run on any certified and many non-certified J2EE application servers. The two most prominent of these are BEA Weblogic and IBM Websphere. Both provide robust HA features and multiple instance support. They are, however, an additional expense above the price of ColdFusion itself and will require you to become familiar with their proprietary administrative functions.

As most of you reading the article already know, the underlying app server for ColdFusion is JRun, Macromedia's popular and easy-to-use J2EE server. JRun is a full-featured J2EE app server with clustering and multi-instance support. However, if you're not familiar with J2EE or the management/configuration of JRun, getting up and running with multi-instances and clustering may be a difficult task. In addition to a good understanding of JRun you will need to understand the basics of J2EE and the Java Runtime Environment (JRE). For the average ColdFusion user, there are several layers between you and a HA environment.

Our goal with ColdFusion MX 7 was to reintroduce HA features in a way that was intuitive and easy for the typical ColdFusion customer. The Enterprise Manager, found in the CF Administrator of ColdFusion MX 7 Enterprise, provides an easy-to-use GUI for configuring multiple servers and for managing clusters. ColdFusion users can get all the benefits of clustering and multiple instances right from the comfortable confines of the CF Admin without the need for any J2EE or JRE expertise.

Multiple ColdFusion Instances
Multiple instances (sometimes known as multiple servers) refer to J2EE servers' ability to deploy multiple copies of an application server to a single computer. Technically, a new JVM (Java Virtual Machine) is deployed per server instance. The benefit is simply that each new application server has its own process to use and a failure of one server cannot affect other servers; this is usually referred to as process isolation. In ColdFusion MX 6.1 Enterprise, it was possible to configure multiple ColdFusion servers, though it was a highly manual process and required the use of the JMC and knowledge of J2EE. With ColdFusion MX 7 creating multiple ColdFusion servers on a single computer is done via a simple interface in the CF Administrator. Each new ColdFusion server has its own CF Admin and is configured separately just as if this were a copy of ColdFusion running on a completely different physical computer. A single machine can now host any number of individual ColdFusion servers, bound only by processing power and RAM. Many new deployment options are available where individual applications, which were once directories, can now be deployed as separate processes. Clustering can also be used across physical machines as well as across instances deployed on the same machine or any combination of physical and logical servers.

Deployment Scenario
Until ColdFusion MX 6.1 Enterprise, a computer could have only one instance of the ColdFusion server process. This means that the file system was the only method for logically separating applications. Moreover, this type of partitioning gave you no flexibility with respect to the runtime aspects of the ColdFusion server process. It was really just a way to keep an application's templates and other resources together in a directory structure, and there was no way to control an application's access to the ColdFusion runtime. With 6.1, it was possible to configure JRun to host multiple instance of ColdFusion, and with ColdFusion MX 7 this is even further simplified thanks to the new ColdFusion Enterprise Manager.

It's easy to imagine that many ColdFusion servers sitting on corporate intranets host a great number of applications, each with their own users and load demands. If you are running ColdFusion MX or earlier, there is no way to ensure that one busy app on a server doesn't use all of the available resources. If ColdFusion is configured for 10 simultaneous requests and one app is so busy that those threads are always servicing clients of that app, then other apps will seem slow or non-responsive. To fix this situation before the release of ColdFusion MX 7, it would have required a new piece of server hardware and a separate ColdFusion license. With multiple ColdFusion instances, this is an easy problem to solve without the added expense and maintenance of multiple physical servers. Simply create one ColdFusion instance with 10 available threads for the busy app and another ColdFusion instance to host all of the lower demand apps. Now all apps on the server will appear responsive and spikes in demand in one app won't affect the availability of others. As demand grows in particular sections of your website, you can easily create new instances to meet this demand and get a lot more value out of a single piece of server hardware and a single ColdFusion MX 7 Enterprise license.

HA in Detail
Below you'll find a high-level description of some of the HA features available in ColdFusion MX 7 Enterprise. This isn't meant to be an exhaustive analysis of how to use these features in a particular environment. However, it should help you understand the basics of HA computing. The multi-instance feature alone should be enough to justify the move to ColdFusion MX 7 Enterprise, especially for sites that host multiple applications on a single physical server. And if your server environment hosts mission-critical applications where 100 percent uptime is the goal, then the clustering features of ColdFusion MX 7 are a must-have.

Load Balancing
Load balancing is the simpler of the two HA methods. It refers to the act of distributing requests across n number of computers, based on an algorithm for determining load. This can be as simple as round-robin (which isn't technically load balanced) where requests are sent to each computer in turn or more complex methods based on, for example, CPU utilization. In this case, some method for reporting load on a CPU has to be communicated back to the load-balancing software. The clustering features in the ColdFusion Enterprise Manager can be configured to act as a simple load balancer, handing out requests to the cluster members. There are three algorithms to choose from: round robin, weighted round robin, and random round robin. Strictly speaking these are not load balanced. However you can use weighted round robin (WRR) to simulate a more complex load-balancer. WRR allows you to 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, the cluster can be configured to send a proportionally higher volume of requests to those more robust machines. Random round robin simply routes requests randomly among the cluster participants.