Site Contents
Home
My Blog
ColdFusion
JRun
Flex
Wireless & Networking
Hardware & Gadgets
HDTV
Software Picks
Pictures
Contact Me
Search


My Articles & Papers
Flex Performance
Server/Client
mm.com Under the Hood
Multiple Instances of CFMX
Multiple Instance Config
NLB with ColdFusion
Clustering CFMX for J2EE
Multi-Tier Hardware LB w CFMX
Cisco CSS & Coldfusion MX
JRun 4 Jini based Clustering
WiFi Growth

2ID Tacweb

Other Hobbys
Body-For-Life Challenge

Personal Projects
Family Pool
Deck Gate

username:
password:
 

 
Clustering ColdFusion MX 6.1 Enterprise on JRun

ColdFusion MX 6.0 standalone opened new doors for integrating ColdFusion applications with J2EE, but ColdFusionMX 6.1 takes this integration to another level by allowing developers to deploy ColdFusion directly to J2EE Application Servers such as Macromedia JRun, BEA Weblogic and IBM Websphere. ColdFusion MX 6.1 comes packaged with a full version of JRun 4 and offers the ability during the install to deploy ColdFusion on top of JRun. By deploying directly to an enterprise application server, ColdFusion MX for J2EE can take advantage of the underlying infrastructure that provides multi-level clustering.

ColdFusion MX 6.1 standard 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:

Figure 1: Sample clustering architecture that uses ColdFusion MX for J2EE
Figure 1: 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.

Building and Deploying a ColdFusion MX 6.1 Enterprise Cluster
To build and deploy a ColdFusion MX for J2EE cluster, use the following steps:

  1. Install JRun 4 or CFMX 6.1 (JRun install) on each server you plan to cluster.
  2. Start all servers in the cluster.
  3. Configure ColdFusion MX through the wizard.
  4. Configure server settings in the ColdFusion Administrator.
  5. Create a cluster and add the servers to the cluster.
  6. Configure session replication if necessary.
  7. Restart all servers in the cluster.
  8. Configure an external webserver to the cluster.
  9. Perform any ColdFusion Administrator configurations (mappings, database connections, and so forth) and deploy your ColdFusion application.
  10. Test the cluster.

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

  1. Install ColdFusion MX 6.1 with the J2EE Configuration (ColdFusion MX with JRun 4) on all servers that you plan to cluster
Figure 2. Choose the J2EE Configuration in the Install Wizard
 
  1. During the install choose the Built in webserver as shown in figure 2
 
Figure 3. Installation Wizard choosing the webserver (choose Built-in)
 
  1. Follow the prompts for the installer and complete the install for CFMX 6.1
  2. When prompted launch the Configuration Wizard after the installer finishes, enter you CF Admin password and follow the prompts in the wizard to complete the install.
  3. On windows five different services will be installed as shown below
    1. ColdFusion MX ODBC Agent
    2. ColdFusion MX ODBC Server
    3. Macromedia JRun Admin Server - JRun Management Console (JMC) htttp://127.0.0.1:8000/
    4. Macromedia JRun CFusion Server - ColdFusion Server
    5. Macromedia JRun Default Server - Default JRun Server
    Only services a, b, d are needed for CFMX to run correctly, the JRun Admin server and Default server can be shut down unless you need to use the JMC to administer JRun
  4. On unix you can use the following command to start and stop the JRun servers
    /jrun4/bin/jrun -nohup -start <servername>
    /jrun4/binjrun -stop <servername>
    /jrun4/bin/jrun -nohup -start cfusion
  5. Using either the service control panel or command line start the Admin server for each server in the cluster.
    /jrun4/bin/jrun -nohup -start admin
  6. If you want to use multiple instances on a single server or cluster instances on a single server see this article (start at step 7) otherwise to cluster across multiple servers continue to step 9.
  7. Open the JRun Management Console (JMC) http://server:8000/ on one of your servers that you will be clustering. This will be the JMC that will be used to create and control the cluster of JRun instances.
  8. Before you can create the cluster you will need to register the remote JRun instance in the JMC. Earlier when you installed ColdFusion MX 6.1 with the J2EE option it created a JRun server named cfusion. If you are clustering JRun instances each instance has to have a unique name. You will need to rename one of the servers from cfusion to something else, in this example I use the name cfusion2.

    To change the name of a JRun server you will need to make two changes.
    1. Rename the directory {jrun-root}/servers/cfusion to {jrun-root}/servers/cfusion2
    2. Modify the cfusion entry in {jrun-root}/lib/servers.xml
      <server>
        <name>cfusion2</name>
        <directory>{jrun.home}/servers/cfusion2</directory>
      </server>

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

Figure 3. Registering a remote JRun application server through the JMC.
Figure 4. Registering a remote JRun application server through the JMC. To register the remote server you only need the remote servers Host Name, JRun Server Name, and JNDI Port.

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.
Figure 5. View of all servers that are available from within the JMC.
  1. Start all JRun instances that will be part of the cluster.
  2. 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.
  3. 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 5. Creating a Cluster in the JRun JMC

Figure 6. Creating a Cluster in the JRun JMC.
Figure 6. Selecting servers that will be a part of the JRun cluster.
Figure 7. Selecting servers that will be a part of the JRun cluster.
  1. 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. (depending on how ColdFusion is deployed you may need to first click the cfusion-ear link first then ColdFusion MX link)
    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 14a through 14g for all servers in the cluster.
  2. If you configured session replication in step 14 then you will need to modify the classpath in {jrun-root}/bin/jvm.config file. When CFMX 6.1 is installed it makes some changes to the jvm.config files classpath that prevents session replication from working properly. To get it working remove the following entries that are highlighted in red

    # JVM classpath
    java.class.path={application.home}/servers/lib ,{application.home}/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/lib/cfusion.jar,{application.home}/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/lib,{application.home}/lib/jrun.jar ,{application.home}/lib

  3. In the JMC, at the command line or in the services panel, restart all servers in the cluster.
  4. 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.
Figure 8. 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. For all other environments see the ColdFusion documentation.

java -jar /opt/jrun4/lib/wsconfig.jar -host 
 192.168.1.45 -cluster ClusterName -ws Apache -dir /etc/httpd/conf 
 -map .cfm,.cfc,.cfml,.jsp,.jws -coldfusion -v
  1. Copy your ColdFusion Application to your webserver root of every server in the cluster. If you are running in distributed mode (JRun and the Webserver on different physical machines) you will need to copy the ColdFusion content from the web server to the application server with the same directory structure used on the web server.
  2. Next create data sources, mappings, and any other settings to the ColdFusion Administrator for every server in the cluster.
  3. Test your cluster. Browse a ColdFusion page through the external webserver (such as http://server/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>JRun Server Name: #servername#</cfoutput>

    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.

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 9 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).
Figure 9. 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 10.

Figure 9. Sample Configuration 2: Two webservers (ClusterCATS) and two ColdFusion MX for J2EE  servers.
Figure 10. 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.
Figure 11. Sample Configuration 3.

ColdFusion MX 6.1 Enterprise with the J2EE configuration 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 standard 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 6.1 Enterprise.