![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
© Copyright International Business Machines Corporation 2003. All rights reserved.
Macromedia® ColdFusion MX for IBM ® WebSphere® (hereafter called ColdFusion MX) provides an easy-to-learn markup language, CFML, that you can use to build powerful Internet applications. With this new ColdFusion MX offering, developers can now execute ColdFusion MX applications on IBM WebSphere Application Server Advanced Edition V4 (hereafter called Application Server). Application Server provides ColdFusion applications not only with a J2EETM environment, but also with WebSphere-specific functions and services, including cloning technology.
Cloning technology lets you configure clusters of application servers. In Application Server administration terms, a cluster is a server group that contains clones, where each clone represents an application server instance. A server group has a method that enables identical instances of application servers to contain the same enterprise applications. These enterprise applications can execute concurrently on either the same machine or remote machines. This type of configuration provides the following benefits:
- Performance and scaling. Additional clones provide increased throughput for applications. As client request demands change for particular applications, you can add and remove clones or take them online and offline to adjust to these demands. The result is that you keep the environment optimized to fulfill client requests in a timely manner.
- Reliability and failover. In the event that there is planned or unplanned downtime for machines in a cluster, request routers will continue to route client requests to only the clones that are available in the cluster. In addition, as application server clones are brought back online, requests will once again start routing requests to these clones.
- Load balancing and workload management. Client requests are automatically distributed across all application server clones in a cluster. Using the clones efficiently maximizes the performance of the resources in the environment.
Creating multiple application server clones on a single machine is commonly referred to as vertical scaling. Vertical scaling enables more efficient use of a machine's processing power. An instance of an application server runs in a single JavaTM Virtual Machine (JVM) process. However, in some cases, the inherent concurrency limitations of a JVM process prevents it from fully using the machine's processing power. Creating additional JVM processes lets each process manage its own thread pools, thereby reducing contention and concurrency issues.
Although vertical scaling can allow for a higher level of efficiency of a machine's processing power, it provides only a certain level of failover. If multiple clones are configured on the same machine, users will continue to get their requests serviced in the event that a JVM process goes down. However, in the event that there is total machine failure, no application server instances will be available.
Creating application server clones on multiple machines is commonly referred to as horizontal scaling. This type of configuration provides the highest level of scaling and failover.
It is also fairly common for environments to contain a mix of vertical and horizontal scaling.
This article provides step-by-step instructions on how to configure a WebSphere Application Server server group with clones, where each clone has ColdFusion MX installed. Using the WebSphere Application Server Administrative Console, the article demonstrates how to configure a horizontally cloned environment. Figure 1 depicts the environment that you will configure by walking through the sample below:
Figure 1. The configured environment
Figure 1 shows the Application Server installed
on two machines whose names are mjmnet and blabwin1,
where each machine respectively contains an application server clone
CFMX Server1 and CFMX Server2 that comprise the server group, CFMX
Cluster. Again, each of these clones has ColdFusion MX installed.
In addition, IBM HTTP Server, installed on a separate machine, ihs,
will route HTTP requests to both application server clones.
For simplicity, it is assumed that both mjmnet
and blabwin1 use a database installed on mjmnet
for the Application Server administrative database.
Complete the following steps to configure the environment depicted in Figure 1 above:
- Step 1: Rename the ColdFusion MX enterprise application
- Step 2: Create a server group
- Step 3: Create a new application server clone
- Step 4: Make necessary directory changes
- Step 5: Copy all enterprise applications to the remote machine
- Step 6: Modify the virtual host
- Step 7: Start the server group
- Step 8: Generate the Web server plug-in file
It is assumed that IBM HTTP Server and WebSphere Application Server are already installed on the machines, and that ColdFusion MX is already installed on one of the WebSphere installations.
Step 1: Renaming the ColdFusion MX enterprise application
For this example, ColdFusion MX is installed on
the mjmnet machine; the article refers to this machine
as the originator node machine.
ColdFusion MX is installed on the application
server, Default Server, by default. Default Server already has one
enterprise application called sampleApp installed.
You do not need to include this application when creating the application
server clones for ColdFusion MX.
Use the WebSphere Advanced Administrative Console to remove the sampleApp application from the originator node. Right-click mjmnet_sampleApp, and select Remove.
Figure 2.
The mjmnet machine is where ColdFusion
MX was initially installed and is comprised of the enterprise applications,
mjmnet/CFusion and mjmnet/CFIDE.
In the WebSphere Administrative Console, rename
the applications to cfusion and rds, respectively
(see Figure 3):
Figure 3.
Step 2: Creating a server group
Use the WebSphere Administrative Console to rename
the Default Server on the originator node, mjmnet,
to CFMX Server1 for clarity. In the Administrative
Console, select Default Server. In the General tab
view, enter CFMX Server1 as the name of the application
server.
Figure 4.
Create a server group and make CFMX Server1 the first member clone. In the WebSphere Administrative Console, right-click CFMX Server1, and select Create Server Group.
Figure 5.
The Server Group Properties dialog opens. In the
Server Group name field, enter CFMX Cluster. Click
OK.
Figure 6.
Step 3: Creating a new application server clone
Create a second application server clone on a
remote machine. For this example, the new clone, CFMX Server2,
is created on machine, blabwin1.
This step is the same as creating a new clone on the same machine for configuring a vertical scaling environment.
In the WebSphere Administrative Console, right-click on CFMX Cluster, and select New => Clone (see Figure 7):
Figure 7.
The Create Clone dialog opens. In the Name field,
enter CFMX Server2. In the Node to install server on
field, enter blabwin1. Click Create.
Figure 8.
The new clone is now created on machine, blabwin1.
Figure 9.
Step 4: Making necessary directory changes
When a new application server clone is created,
it models all of the properties of the first application server
clone in the server group. Therefore, depending on the operating
system and the location of the WebSphere Application Server installation
on the remote machine where a new clone has been created, you might
need to modify some of the directories of certain files. In this
example, the Application Server was installed in D:\WebSphere404\AppServer
on the mjmnet machine, while on the blabwin1
machine, the Application Server was installed in C:\WebSphere404\AppServer.
Therefore, you will need to modify any paths in the configuration
of CFMX Server2 that point to D:\WebSphere404\AppServer
to instead specify the correct path for the blabwin1
machine.
One directory that you need to update is the working
directory of the CFMX Server2, which is located in the General tab
view. Figure 10 below provides a view of the General tab with an
updated working directory value for CFMX Server2. For this example,
the value was changed from D:\WebSphere404\AppServer\bin
to C:\WebSphere404\AppServer\bin.
Figure 10.
You also need to modify the location of the standard
out and standard error directories which are located in the File
tab view of CFMX Server2. Figure 11 below provides a view of the
File tab with updated standard out and standard error file directories
for CFMX Server2. For this example, the values were changed from
D:\WebSphere404\AppServer\logs\Default_Server_stdout.log to
C:\WebSphere404\AppServer\logs\Default_Server_stdout.log
and from D:\WebSphere404\AppServer\logs\Default_Server_stderr.out
to C:\WebSphere404\AppServer\logs\Default_Server_stderr.log.
Figure 11.
Step 5: Copying all enterprise applications to the remote machine
When a new clone is created, IBM WebSphere Application
Server 4.0 does not automatically propagate all of the necessary
enterprise applications installed on a server group to the remote
machine. Therefore, you need to transfer the cfusion
and rds enterprise applications to the remote machine,
blabwin1, from the originator machine, mjmnet.
Using the Application Server EARExpander tool
on the originator machine, mjmnet, collapse the ColdFusion
MX applications, cfusion and rds, and
transfer them to the remote machine, blabwin1.
For this example, run the following commands:
- Change the directory to the WebSphere Application Server
\bindirectory:
cd D:\WebSphere404\AppServer\bin
- Collapse the ColdFusion MX application
cfusioninto a temp directory:
EARExpander -ear D:\Workbench\tmp\cfusion.ear -expandDir D:\WebSphere404\AppServer\installedApps\cfusion.ear -operation collapse
- Collapse the ColdFusion MX application
rdsinto a temp directory:
EARExpander -ear D:\Workbench\tmp\rds.ear -expandDir D:\WebSphere404\AppServer\installedApps\rds.ear -operation collapse
Figure 12.
Now, on the remote machine, blabwin1,
use the EARExpander tool again to expand the cfusion.ear
and rds.ear files into the
\installedApps directory. In this case, both EAR files will
be expanded into the C:\WebSphere404\AppServer\installedApps
directory.
For this example, run the following commands:
- Change directory to the WebSphere
\bindirectory:
CD C:\WebSphere404\AppServer\bin
- Expand the ColdFusion MX application
cfusioninto the\installedAppsdirectory:
EARExpander -ear C:\Workbench\tmp\cfusion.ear -expandDir C:\WebSphere404\AppServer\installedApps\cfusion.ear -operation expand -expansionFlags war
- Expand the ColdFusion MX application
rdsinto the\installedAppsdirectory:
EARExpander -ear C:\Workbench\tmp\rds.ear -expandDir C:\WebSphere404\AppServer\installedApps\rds.ear -operation expand -expansionFlags war
Figure 13.
Step 6: Modifying the virtual host
Each IBM WebSphere Application Server has its
own HTTP transport that receives and responds to HTTP requests.
The IBM HTTP Server uses the HTTP transport to send client requests
to a particular application server. This requires that each application
server have a unique hostname:port value pair for communication.
In the Application Server, the hostname:port value pair is configured
as a host alias in a virtual host entry. There must be a host alias
entry in a virtual host entry that matches the hostname:port
value used by the application server HTTP transport. When creating
new application server instances, WebSphere automatically allocates
an available port value for the machine. However, it does not automatically
update the virtual host entry when the application server is being
created since the Application Server does not know which virtual
host entries the applications are configured for.
ColdFusion MX by default uses the default_host
virtual host entry. Therefore, when creating new application server
clones that contain ColdFusion MX, you must configure any port value
that was automatically allocated for the HTTP transport of a new
clone as a host alias in the default_host virtual host
entry. The following steps describe how to to check the configuration
and make changes if necessary.
Select CFMX Server1. Click the Services tab, and select Web Container Service from the Services list. Then, click Edit Properties.
Figure 14.
Figure 15 displays the Web Container Service properties
panel for this example. You generally do not need to make changes
to these properties. Simply take note of the host and port value
that was automatically assigned to the Web Container.
Figure 15.
The HTTP transport hostname:port
value pair of *:9081 means that this application server
will accept requests for any hostname configured for this machine
on port 9081. Therefore, you must also configure this
value pair as a host alias in the default_host virtual
host entry. In the WebSphere Administrative Console, select Virtual
Hosts, then from the list of virtual host entries on the right,
select default_host. Then, if an entry for *:9081
is not included in the Host Aliases, click Add, and
enter the value *:9081. Click Apply.
Figure 16.
Step 7: Starting the server group
The CFMX Cluster is now configured and ready to
be started. Starting the server group will start all application
server clones. In the WebSphere Administrative Console, select CFMX
Cluster under Server Groups, and click the Start icon
in the menu bar. CFMX Server1 on machine mjmnet and
CFMX Server2 on machine blabwin1 will start.
Figure 17.
Step 8. Generating the Web server plug-in file
Now you need to provide the configuration information
of the CFMX Cluster to the Web server so that it knows where to
route client requests to. This involves generating the plugin-cfg.xml
file which contains the routing information that the IBM HTTP Server
requires.
To manually activate the generation task, select a node, for example mjmnet, and select Regen Webserver Plugin.
Figure 18.
The generated file is located in the \config\plugin-cfg.xml
directory. In this example, the file was generated in D:\WebSphere404\AppServer\config\plugin-cfg.xml.
Typically, the Web server is located on a remote machine for a production environment, similar to what is demonstrated here, but it can reside on the same machine where an IBM Application Server is installed.
If you are using the Web server on the same machine
as the IBM Application Server, and it is configured to already use
the plugin-cfg.xml file located in the \config
directory, then no further action is required. IBM HTTP Server will
automatically recognize that the plugin-cfg.xml file
has been updated, and will start using it. However, as is the case
for this example, IBM HTTP Server is installed on a separate machine.
Therefore, you will need to transfer the plugin-cfg.xml
file to the other machine and replace it with the one that is currently
being used. Once this is done, IBM HTTP Server will automatically
recognize that the plugin-cfg.xml file has been updated
and will start using it.
Managing ColdFusion MX applications
If user applications were already installed on the original application server where ColdFusion MX was installed prior to performing the configuration steps above for cloning, then no further steps will be necessary. All application servers in the cluster will be able to service client requests for the user applications.
However, if you decide to install, uninstall, or maintain your ColdFusion MX applications after the cloning process, you will need to make the necessary changes in each location that ColdFusion MX is installed.
For the scenario where you configure a vertical
scaling environment ColdFusion MX, keep in mind that all application
server clones are operating against the same ColdFusion MX installation
location; this is comprised of the cfusion.ear and
rds.ear enterprise applications located in the \installedApps
directory. This means that any administration performed by using
the ColdFusion administrator will take effect for any application
server clone running ColdFusion MX applications on the same machine.
If you configure a horizontal scaling environment, then any change made to the ColdFusion MX environment using the ColdFusion administrator for one application server clone will also need to be made using the ColdFusion administrator on all the remote application server clones.
Using the example configured above, if you make
a change using the ColdFusion MX administrator for CFMX Server1
(http://mjmnet:9080/cfmx/CFIDE/administrator/index.cfm),
then you will need to make the same change to CFMX Server2 on the
remote machine (http://blabwin1:9081/cfmx/CFIDE/administrator/index.cfm).
If your ColdFusion MX application uses the ColdFusion Server ODBC Server service, then refer to the ColdFusion MX documentation to learn how to configure this service on a remote machine in the event that horizontal cloning was performed.
Tuning WebSphere Application Server
For information on tuning Application Server, refer to the WebSphere Application Server Tuning Guide.
Advanced information on WebSphere Application Server workload management
This discussion on configuring a cluster of ColdFusion MX for WebSphere Application Server servers discussed how to take advantage of the IBM HTTP Server workload management, i.e., the load-balancing technology of routing HTTP client requests to multiple servers. For WebSphere Application Server 4.0, the Web server plug-in performs a round-robin selection policy (instead of a random selection policy), for determining which application server clone to send a client request to.
There is another form of workload management in the Application Server that is used for EJBs. If your ColdFusion MX application calls an EJB that is installed in a server group, then you can choose which selection policy to configure. The selection policies available include round-robin, random, round-robin prefer local, and random prefer local. Please see the WebSphere Application Server documentation for information on the available selection policies for EJB workload management.
You choose the selection policy for an EJB when the server group is being created, where the new Server Group will contain application server clones that are responsible for executing the EJB. The selection policy you choose is in effect for the EJB container on each of the application server clones configured in the server group.
Together, Macromedia ColdFusion MX for IBM WebSphere and IBM WebSphere Application Server provide a reliable and scalable environment for users with demanding needs. As described here in step-by-step detail, you can configure such an environment by using ColdFusion MX with Application Server's cloning technology to meet these demanding needs.
Michael Morton is a Senior Software Engineer at the IBM Research Triangle Park in North Carolina, and is an original member of the IBM WebSphere Application Server development team. His current assignments include being a product development architect for IBM WebSphere Application Server Base and Network Deployment Editions, and lead engineer responsible for the joint efforts between IBM and Macromedia. You can contact Michael at mortonmj@us.ibm.com.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
