ColdFusion Article

ColdFusion MX standalone and previous versions of ColdFusion limited administrators to using a single instance of ColdFusion. If one application caused server failure, it would affect all other applications running in the server. ColdFusion MX for J2EE allows administrators to create multiple instances of ColdFusion on a single server, which reduces the chances of a single application causing complete server failure. By extending ColdFusion applications across multiple servers, administrators can leverage the clustering capability of their J2EE application server. Enterprise level J2EE application servers can provide load balancing and failover from the webserver to the application server, including in-memory replication of session data between servers.

Clustering Architecture
JRun 4 provides a low-cost, easy-to-implement solution for building scalable clusters of ColdFusion applications. JRun 4 introduced a new state-of-the-art clustering architecture that ColdFusion MX can utilize. Deploying ColdFusion MX on JRun and creating clusters is simple with JRun 4. You create multiple JRun instances and create clusters using the JRun Management Console (JMC). The JMC is a web-based administration console, which is very similar to the ColdFusion Administrator.

The following figure is a sample clustering architecture that uses ColdFusion MX for J2EE:

Clustering Levels
With ColdFusion MX for J2EE on JRun, you can implement clustering at three levels to offer the maximum level of reliability, scalability, and performance. As the figure 1 shows, ColdFusion MX for J2EE on JRun provides three clustering levels:

• Web server clustering
• Connector clustering
• Object clustering (session replication)

The following sections describe these clustering levels in detail.

Web server clustering. Web server clustering is a technique in which two or more web servers that support one or more fully qualified host names are grouped together as a cluster of servers. The cluster collectively accommodates increases in load and provides system redundancy. Clustering for scalability works by distributing load across each server in the cluster (load-balancing) using an unintelligent-but-regular distribution sequence (round-robin DNS and routers) or a predefined threshold or algorithm. You specify and can adjust the distribution sequence or algorithm for each server in the cluster. With JRun 4, you cluster web servers using a software-based solution such as ClusterCATS, a hardware-based solution such as a router or bridge (Cisco Local Director, Cisco CSS, or F5 Big IP), or a combination of the two. ClusterCATS integrates directly with Cisco LocalDirector and CSS by providing intelligent load information from the JRun server through the dynamic feedback protocol (DFP).

Connector clustering. A native web server connection module or connector, is already compiled for the specific web server, hardware architecture, and operating system. For example, JRun uses Apache modules to create connectors for the Apache web server for each possible hardware architecture and operating system that JRun supports. JRun ships with several different connectors that plug into the major web servers on the market (Apache, Iplanet, and IIS). In JRun 4, you can connect multiple instances of ColdFusion MX for J2EE to one web server and load balance incoming requests. Out of the box, Macromedia provides three different algorithms for load-balancing (round-robin, weighted round-robin, and weighted random). As the web server receives requests, the connector directs the requests to JRun based on the algorithms. If a JRun server fails, the connector uses automatic failover to transfer requests to a running server. In-memory session replication within the JRun server preserves state information when a failure occurs.

Object clustering. ColdFusion MX for J2EE provides in-memory replication of session data to provide failover functionality for ColdFusion pages that use the session scope. In a clustered environment, you may want session information to be immediately available to other servers in the cluster. The underlying clustering architecture for JRun is built on a Jini-based architecture. The use of Jini allows the JRun clustering portion to be lightweight, have a small footprint, yet remain robust. Object clustering not only provides session replication, it also provides load-balancing and automatic failover of requests sent by clients (for example, ColdFusion Pages, JavaServer Pages (JSPs), Servlets, or regular Java clients) to server objects, such as Enterprise JavaBeans, JMS queues and topics, JNDI trees, or other services.

*Note: The session replication feature is only available in the second release of ColdFusion MX for J2EE. If you are running the original release then you will need to upgrade to the second or later release to take advantage of in-memory session replication.

1. Install JRun 4 on each server you plan to cluster.
2. Create any number of JRun instances.
3. Install ColdFusion MX for J2EE/JRun as a WAR file on each physical server that you plan to cluster.
4. Copy and extract the WAR file to the JRun server directory of each instance that you plan to cluster.
5. Start all servers in the cluster.
6. Configure ColdFusion MX for J2EE through the wizard.
7. Configure server settings in the ColdFusion Administrator.
8. Create a cluster and add the servers to the cluster.
9. Configure session replication if necessary.
10. Restart all servers in the cluster.
11. Configure an external webserver to the cluster.
12. Perform any ColdFusion Administrator configurations (mappings, database connections, and so forth) and deploy your ColdFusion application.
13. Test the cluster.

Follow these detailed steps for building and deploying a ColdFusion MX for J2EE cluster:

1. Install JRun 4 on all servers that you plan to cluster; follow the JRun instructions. After installing JRun 4, start the Admin server for each server in the cluster.
2. To create JRun instances, open the JMC, click Create New Server, and follow the instructions in the wizard:

To manage remote servers from the JMC, start a server on the remote computer and register the server in the JMC. You must start the remote server to register it from a remote JMC

After registering a remote server, you can create new instances on the remote server and administer the settings for all servers from one JMC.

Figure 4. View of all servers that are available from within the JMC.

3. Install ColdFusion MX for J2EE on each server in the cluster using the WAR deployment option. The installer will install to a temporary location. In the next step, you will take the installed files and deploy them onto JRun. Choose a context root other than /. For this example, I used /cfusion.
4. Deploy the WAR file to each JRun server in the cluster.
1. Locate the cfusion.war file that the ColdFusion MX for J2EE installer created.
2. Create a /cfusion folder for each server root in the cluster.
   ({jrun-root}/servers/cfmxjrun1/cfusion, {jrun-root}/servers/cfmxjrun2/cfusion, and so forth).
3. Copy the cfusion.war file to each /cfusion folder you created in step b.
4. Use either Winzip or JAR to extract this WAR file to the /cfusion folder
   (for example: c:\JRun4\servers\cfmxjrun1\cfusion>jar xvf cfusion.war).
5. After extracting, the folder should contain the following folders: CFIDE, META-INF, and WEB-INF. It should also contain several html and cfm files.
6. Delete cfusion.war from the /cfusion folder.
5. Start all JRun instances that will be part of the cluster.
6. Using the built-in JRun webserver, open a web browser to walk through the ColdFusion MX for J2EE configuration wizard at: http://server:port/contextroot. For this example, you must configure each of the four servers in the cluster:
   http://localhost:8101/cfusion, http://localhost:8102/cfusion, http://192.168.1.71:8101/cfusion, and http://192.168.1.71:8102/cfusion. Use the following steps for each server:
1. Enter the serial number.
2. Do not enable RDS.
3. Install the JDBC services if you need them.
4. Do not install the example applications on a production server.
5. If the ColdFusion Administrator appears after completing the wizard, your ColdFusion install was successful.
7. Log into the ColdFusion Administrator. Click the Memory Variables link under the Server Settings section.
1. Check the box for Use J2EE Session Variables and click Submit Changes.
2. Repeat steps 6 and 7 for all servers that you will cluster.
8. To create the cluster, go into the JMC and click Create New Cluster. Add the appropriate servers to the cluster. Enter a name for the cluster, and choose the servers that will be a part of the cluster.

Figure 6. Selecting servers that will be a part of the JRun cluster.

9. If the application uses session variables, you can configure session replication to synchronize session state across the cluster for failover. The following procedure explains how to configure session replication.
1. Within the JMC, expand the clustername in the left frame.
2. Click on one of the servers in the cluster.
3. In the right frame, click the ColdFusion MX application.
4. Click the checkbox for Enable Session Replication.
5. Add the * to the New Replication Buddy and click Add.
6. Click Apply.
7. Open the {jrun-root}\servers\{server-name}\cfmx\WEB-INF\jrun-web.xml and modify the <persistence-config> entry to false, as follows:
   <persistence-config><active>false</active></persistence-config>
8. Perform steps 9-1 through 9-8 for all servers in the cluster.
10. In the JMC, restart all servers in the cluster.
11. To connect your web server to the cluster, run the Web Server Configuration tool, as follows:
    1. For the installer to modify the application appropriate XML configuration files, all clustered servers must be running.
    2. If you have JRun servers on multiple computers, do not choose the default JRun host or localhost; instead use the host name of one of the servers in the cluster.
    3. Select the cluster name from the JRun Server properties pop-up menu.
    4. Select the appropriate web server.
    5. Select the site or Configuration Directory.
    6. Click OK.

       The installer makes all configuration changes and restarts the web server.

Figure 7. GUI based JRun webserver configuration tool.

You can use the command-line webserver configuration tool to install the webserver connector in an environment where a GUI is not available. For syntax details, refer to the ColdFusion documentation. The following example shows one way to configure Apache in a Unix environment: java -jar /opt/jrun4/lib/wsconfig.jar -host 10.1.1.1 -cluster ClusterName -ws Apache -dir /etc/httpd/conf -v

12. Copy your ColdFusion Application to the ColdFusion application root of every server in the cluster
    ({jrun-root}/servers/{servername}/cfusion/). Create data sources, mappings, and any other settings to the ColdFusion Administrator for every server in the cluster. To simplify this process, you can deploy to one server and create a ColdFusion archive and deploy it to the rest of the servers in the cluster. See the section later in this article on deploying ColdFusion CAR files.
13. Test your cluster. Browse a ColdFusion page through the external webserver (such as http://server/cfusion/mypage.cfm) If you have an application that uses session variables, you can shut the server down after invoking a page and redirect your request to another running server; all while preserving the session data. To find out which server handles your request, you can add the following code, which displays the JRun servername.

<cfobject action="create" type="java" class="jrunx.kernel.JRun" name="jr">
<cfset servername = jr.getServerName()>
<cfoutput>#servername#</cfouput>

The process routes all incoming requests through the external webserver in a round-robin fashion across all JRun servers in the cluster. In addition, the process assigns all subsequent incoming requests a jsessionid for session tracking directs them to the same JRun server by using sticky sessions.

Application Considerations for ColdFusion MX Clusters:
Take the following into consideration when creating ColdFusion MX Clusters:

Consider the overhead when replicating session data. An unclustered ColdFusion instance does not limit a developer to the amount of data that can be stored in the session scope. In a cluster, using in-memory session replication the session data for a particular user must be replicated each time it is modified. If you store a significant amount of information in the session scope, it can degrade performance. There is no official rule to the amount that the session scope can store, but consider it when you are developing the application. If you plan to store a significant amount of information in the session scope, perform load testing within a cluster to ensure stability and performance.

You cannot cluster session-based persistent ColdFusion Components. You cannot store ColdFusion components in the session scope when using clustering and session failover. Currently ColdFusion MX does not support serialization of CFCs; therefore, you cannot replicate their state across a ColdFusion MX cluster. The following code demonstrates storing an instance of a components in the session scope.

<cfset session.securitycomp=CreateObject("component","directory.componentname")>

This code will work until a server within the cluster fails. When a server fails and incoming requests fail over to another server, the server will lose the session scope stored in the CFC and throw errors to the logs.

Separate static and dynamic content to improve performance. With ColdFusion MX for J2EE, all requests to the webserver to http://server/cfusion (context root) will go to JRun regardless of the extension (.cfm, .htm, .gif, .jpg). If images and static content exist in /cfusion, all static content will go to the JRun connector back to the webserver. This defeats the purpose of high-performance caching built into the web server. Therefore, we recommend that you place all static content in a folder outside of the /cfusion folder within the webserver root. For example, put all html in a /html folder and place all images underneath the web server root. In a site with a significant amount of static content you will see a significant improvement in throughput and pages/sec by separating the content; in some cases, the performance improves 200-300%.

Using CAR files to simplify deploying clusters. ColdFusion MX can archive and deploy applications into a ColdFusion Archive CAR file. The Archives and Deployment page includes tools that let you archive and deploy ColdFusion applications, configuration settings, data source information, and other types of information to back up your files quickly and easily. The complete list of archived information includes the following: Name and file location, Server settings, ColdFusion mappings, Data sources, Verity collections, Scheduled tasks, Java applets, and CFX tags. After archiving an application and all of its settings, you can easily deploy the application across a cluster of ColdFusion MX servers, easing the administrative overhead of configuring each setting on every server.

Sample cluster configurations
The following sample cluster configurations will help you plan your strategy.

Configuration 1: One webserver and two ColdFusion MX for J2EE servers (a single machine for session failover).

Using a single server, ColdFusion MX for J2EE administrators can create multiple instances of ColdFusion on a single machine, thereby reducing the chances of a single application causing complete server failure. You can cluster multiple instances together to act as one instance with in-memory replication of session data enabling session failover. Figure 8 shows a configuration that provides load balancing and failover on the application server using the connector clustering. It provides session failover when a JRun instance fails, but does not provide failover if the web server fails.

Figure 8. Sample Configuration 1: One webserver for two ColdFusion MX for J2EE servers (a single machine for session failover).

Configuration 2: Two web servers (ClusterCATS) and two ColdFusion MX for J2EE servers

This configuration provides load-balancing and failover for the web server and application server. Load-balancing on the web server uses round-robin DNS. Macromedia ClusterCATS, available with JRun 4.0 as a separate download, provides failover capabilities. Load-balancing and failover on the application server uses connector clustering in JRun. See figure 9.

Figure 9. Sample Configuration 2: Two web servers (ClusterCATS) and two ColdFusion MX for J2EE  servers.

Configuration 3: Hardware load Balancing, two web server, and two ColdFusion MX for J2EE servers

This configuration provides load-balancing and failover on the web server and application server. A hardware-based device provides load-balancing and failover. There are several options for hardware-based load balancing; a few examples are Cisco Local Director, CSS, F5 BigIP, Nortel ACEDirector, and Foundry Networks ServerIron XL. You create load-balancing and failover for the application through JRun connector clustering.

Figure 10. Sample Configuration 3.

ColdFusion MX for J2EE may seem challenging at first, but once you become familiar with JRun and the configuration details of ColdFusion MX for J2EE you will find it to be much more flexible than ColdFusion MX standalone or ColdFusion 5. From multiple instances on a single machine to ColdFusion MX clusters spanning multiple machines, the configuration options are unlimited with ColdFusion MX for J2EE.