Frank DeRienzo, MBA, MCSE
Principal Technical Support Engineer
Macromedia, Inc.

This article contains an example-based ColdFusion 5 upgrade procedure illustrating the transition from ClusterCATS load balancing to hardware-based load balancing incorporating CF 5 server monitoring. Included in this article is the configuration of Cisco Local Director (CLD) running the dynamic feedback protocol (dfp) to receive real-time intelligent load and state information from each CF 5 server dfp agent. Also included is an example of the configuration of other layer-two hardware load balancing devices that do not support dfp. Featured in the latter genre is F-5 BIG-IP now configurable as a layer-two switch.

The advent of ColdFusion 5 makes the transition from a ColdFusion cluster running in the active mode to a ColdFusion server farm running behind a hardware load-balancing device easier than ever before. If your Web site is growing beyond the management capabilities of the software-based ClusterCATS load balancing solution, there are a number of hardware load balancing options available. CF 5 continues support of the dynamic feedback protocol to intelligently convey CF load and server status to Cisco Local Director. Among other hardware options options, F-5 recently added layer-two support with their release of 4.0 Software for BIG-IP; this means that BIG-IP can drop into a flat network where your hardware-based virtual server is on the same subnet as the real servers or nodes in the Web server farm.

The combination of ColdFusion 5 monitoring for high availability with BIG-IP running 4.0 now provides an excellent platform option when moving from a cluster to a hardware-balanced server farm on a flat network. Further integration of BIG-IP with Macromedia’s application servers is ongoing. Our developer’s have begun dialog that should result in significant compatibility enhancements. By implementing either of the following example-based procedures, you will not only build a foundational platform for a world-class enterprise Web site, you will also position yourself to take advantage of any future upgrade options that become available as Macromedia continues to integrate with hardware load balancing solutions.

When should I consider making transition from software load-balancing using ClusterCATS to a hardware-based solution?

As a software-based load balancing option, ClusterCATS (CC) is designed to cover a specific niche. Macromedia has set a limit on the number of production servers in a ClusterCATS cluster to 8 across each hosting up to 6 virtual servers or to put it another way, 6 clusters across 8 servers. This is a hard limit to calculate because there are so many other variables such as the type of application, amount of load, length of sessions, etc., but it is safe to say that if your site is growing beyond the need for 8 production servers, it is time to consider a hardware solution incorporating the ColdFusion 5 monitoring option to provide resilient server level clustering features such as the Web server probes, application server probes, custom probes, alarms and dfp load balancing algorithms.

What is the difference between layer-three and layer-two, and what does it have to do with CC clustering?

Cisco Local Director is traditionally a layer-two device. BIG-IP has traditionally been a layer-three device. A layer-two device can drop into a flat network while a layer-three device is designed to route traffic across interfaces. As a layer-three device, BIG-IP has always had two interfaces each homed on a different subnet. The external interface (usually exp0) receives traffic from your external network where it also hosts your virtual server. The internal BIG-IP interface (usually exp1) faces the Web server farm and provides it with a default gateway from its private network through BIG-IP to the external network. Using layer-three, the Web server farm is essentially segregated onto it’s own private network.

Click thumbnail to view diagram.

As a layer-two device, BIG-IP running 4.0 can imitate CLD by placing one IP address onto both its internal and external interfaces essentially acting as a bridge instead of a router. This eliminates the need to place the Web server farm onto its own private network while also maintaining that capability if desired.

The transition from a cluster of Web servers running CC to a layer-two hardware load balancing solution requires fewer DNS and network configuration changes than would be needed to place in a layer-three device. Your current public Web server addresses do not need to be changed to accommodate a layer-two device whereas they would have to be changed to private addresses to accommodate layer-three where the only public addresses appear on the external interface of the device.

Most hardware load balancing devices are switch-based and work well as layer-two devices. In order to drop BIG-IP into a flat network, you will need to be running the very latest software available from F-5. If you need to upgrade an existing BIG-IP, go to http://tech.f5.com/home/BIG-IP/solutions/general/sol1114.html for information about upgrading to 4.0. You will also need a patch called PTF1 which will bring you to 4.0PTF1. If you are upgrading an existing BIG-IP with the intention of placing it as a layer-two device, I recommend booting the BIG-IP from the 4.0 upgrade CD (you may have to change a setting in the bios to boot from the CDROM) and choosing to completely overwrite your configuration with the upgrade. Remnants of any previous (layer-three) configuration will only complicate your efforts.

Example-based instructions for configuring CF 5 and Layer-two Hardware Load Balancing Devices

As an example Web site configuration, picture the following transition model:

The current configuration consists of a cluster of 4 servers running 4.5.1 SP2 with DNS Round-Robin as the initial means of distribution. A good backup for DNS is to have a hosts file configured on each server. The following hosts file serves to illustrate our 4 servers and their upstream router or default gateway.

10.64.22.230 barth.qa.nashua.macromedia.com barth
10.64.22.231 brunner.qa.nashua.macromedia.com brunner
10.64.22.232 pascal.qa.nashua.macromedia.com pascal
10.64.22.233 jansen.qa.nashua.macromedia.com jansen
10.64.22.1 upstream.qa.nashua.macromedia.com upstream

The above addresses illustrated in the hosts file also have both forward and reverse DNS entries on the DNS server. The Round-Robin A-records are only forward entries, not reverse entries. They cannot be illustrated in a hosts file, but would appear in DNS:

www.qa.nashua.macromedia.com 10.64.22.230
www.qa.nashua.macromedia.com 10.64.22.231
www.qa.nashua.macromedia.com 10.64.22.232
www.qa.nashua.macromedia.com 10.64.22.233

Click thumbnail to view diagram.

Next, picture this same Web site behind a layer two switch illustrated by the following hosts file:

10.64.22.234 hld.qa.nashua.macromedia.com hld 
10.64.22.235 www.qa.nashua.macromedia.com www
10.64.22.230 barth.qa.nashua.macromedia.com barth
10.64.22.231 brunner.qa.nashua.macromedia.com brunner
10.64.22.232 pascal.qa.nashua.macromedia.com pascal
10.64.22.233 jansen.qa.nashua.macromedia.com jansen
10.64.22.1 upstream.qa.nashua.macromedia.com upstream

Notice that the DNS Round-robin entries are eliminated; instead, the virtual server on the layer two switch (www.qa.nashua.macromedia.com) is bound to each of the CF5 Web servers and distributes traffic to them using algorithms and means of state verification.

Click thumbnail to view diagram.