There are two basic Web server load balancing options: hardware-based and software-based. The latter have been slowly disappearing from the enterprise while the former have been gaining a larger presence.

Many software-based options have reached the end of their product life cycle. Macromedia ClusterCATS is among those end-of-life products; it has not been ported to IIS6. The primary software-based Web server load-balancing (actually failover rather than load-balancing) option with IIS6 is MS NLB.

ColdFusion Web sites on IIS5 running multiple servers clustered with ClusterCATS will soon need to transition to either MS NLB or a hardware-based solution. While clustering CF on JRun is always an option for the application servers, this does not provide a means to cluster Web servers. Since session traffic must pass through a Web server, something more robust than DNS round-robin and more application-oriented than MS NLB is desirable in the enterprise. ClusterCATS has an acronym suffix that stands for Content, Application & Transaction Smart. It is possible to replace ClusterCATS with a hardware-based solution that offers similar features, but with much greater load capacity and robustness.

Hardware-based options have been steadily improving over the past eight years. Most high-end hardware load balancing devices (HLDs) are now application-aware; they not only monitor the health of a Web server, but also the health of an application server. If a Web server is running, but an application server is stalled, most HLDs will redirect traffic away from the stalled server even though the Web server is alive. Only five years ago, in order to get a LocalDirector to react to monitor the health of a CF application, you had to use the ClusterCATS dynamic feedback protocol (dfp) agent to communicate the state of the application to the LocalDirector. Virtually all newer devices can monitor a content string produced by an application server and react to a problem faster than the dfp agent could register the status of an application.

Many HLDs have algorithms that can tell when there is a degradation in the performance of a server. Sometimes, a Web or application server in a pool may be handling sessions in a decreased capacity; most high-end HLDs are quite adept at ensuring that the best performing server is the one to which the inbound traffic is directed.

Some HLDs are also very adaptable to unique infrastructure requirements. They can operate at many layers of the OSI model. Figure 1 shows an HLD sitting on a network without operating as a bridge or a router; it is connected to a flat network by a single network interface card and consequently is about as easy to integrate as a PC. In this example, an F5 BIG-IP is managing session traffic both in front of the Web servers and between distributed Web servers and application servers.

Competition in the HLD space is very aggressive; manufacturers are offering trade-in options and competitive upgrades. There is even a large used hardware market where many a frugal network engineer and Webmaster have found a high-end HLD at a low-end price. Be careful though - caveat emptor - there's a lot of junk out there on the used market as well. And if you are running an enterprise operation, there is no replacement for the professional support team and the software upgrades that come with a new purchase.

Here are some tips to help you make the transition on your multi-server CF site from a software-based Web server load balancing solution to a hardware-based option.

1.  Carefully choose an HLD with the feature set that best matches your needs; some HLDs work better as routers than they do as bridges, for example. At least one high-end option can fit into your network with as little complication as adding a server. Look at your network infrastructure and decide what will fit best.

2.  Decide whether you need SSL termination at the HLD. Some HLDs can accelerate SSL traffic from a single virtual IP address (VIP) and direct traffic back to multiple servers in a pool, while some require that SSL traffic be terminated at the Web server. The former option requires only a single certificate for multiple servers, while the latter requires a certificate for each Web server.

3.  Keep the initial configuration simple. If you wish to integrate JRun connector-based application-level load balancing or session replication, you may wish to begin with a simple one-to-one Web server to CF server correlation and get that operational behind your new HLD before moving on to more complex configurations.

4.  If CF is distributed onto separate platforms from your Web servers, you may wish to use your new HLD to balance traffic in front of the Web server and also between the Web servers and the CF servers. See the clustering section of the Macromedia CF DevCenter for details on this option.

Hardware has always been a more robust Web server load balancing option; it is quickly becoming the only viable option in the enterprise. Mission-critical, multi-server CF sites with heavy traffic should include hardware-based load balancing.