The designation "hardware load balancing device" (HLD) is a broad generalization. There are many HLD's offering many different features. On the high-end of the HLD spectrum, names come to mind such as Cisco, F-5 and Alteon, to name but a few. This article provides configuration details that guide you through one basic way and two optional ways of setting up ClusterCATS on servers running in distributed mode behind a HLD.
By Frank DeRienzo
Principal Technical Support Engineer
The designation, hardware load balancing device (HLD) is a broad generalization. There are many HLD's offering many different features. On the high-end of the HLD spectrum, names come to mind such as Cisco, F-5 and Alteon, to name but a few. This article provides configuration details that guide you through one basic way and two optional ways of setting up ClusterCATS (CC) on servers running in distributed mode (DM) behind a HLD.
This article is broken into three sections:
- The first section of this article will offer configuration details for setting up the HLD to perform all load-balancing and failover functions. ClusterCATS will provide web server recovery in the event of a hang or crash, automatic e-mail alerts for server problems and daily server status reports. This first option I will call passive CC HLD integration; it has become the preferred HLD/CC integration option because most of the newer versions/revisions of HLD's and their commensurate firmware and software have substantially improved methods of load-balancing and failover.
- To cover the increasingly rare instances where your HLB may look and run like a chain toilet, Macromedia offers another ClusterCATS integration option. An example of a limiting characteristic of an older chain-toilet load balancing device, may be the blind channeling of client load/sessions to the web-server farm with incredible pressure through an old pipe in a manner similar to (but one hopes more scalable than) DNS Round-Robin. In these increasingly rare cases you will want to use the second configuration option in this article: active CC HLD integration and push secondary corrective load-leveling decisions onto CC.
- Lastly, in section three, this article discusses a third possible option for running a Solaris or Linux-based ColdFusion cluster - this time behind a midrange HLD, one that is neither antique, homemade or cutting edge, but runs with some limited functionality.
Note: This article does not apply to the custom integration of CF/CC with Cisco LocalDirector (CLD).
I. Option 1. Passive CC HLD integration in DM: The HLD will actively distribute load to the front-end distributed web servers based on packet flow. CC will provide web server recovery in the event of a hang or crash, automatic e-mail alerts for server problems and daily server status reports.
Note about option one: If you are running ColdFusion 5 (or are running ColdFusion 4.5.x and are able to upgrade to ColdFusion 5), instead of clustering, you may wish to use the Server Monitoring option with your high-end HLD. ColdFusion 5 Server Monitoring provides all the server level capabilities of CC without the overhead of a cluster.
To integrate CC with an HLD:
A. Configure the load balancing device or software product as recommended by the manufacturer. You may also wish to peruse the ColdFusion or JRun Support Centers to see if there is a recommended procedure for your specific HLD: www.macromedia.com/support.
B. Behind an HLD in DM, you should place the two front-end web servers into a cluster. You must use static web site IP addresses and CC failover (high-availability) must be turned off. During ColdFusion installation, select no server failover. If you are running NT 4.0, do not set up your Web servers with dynamic IP addresses. Your HLD will be providing failover services. Dynamic IP addressing is only used with CC's implementation of failover. If you are adding an HLD to a CF/JR and CC cluster that is already set up with dynamic Web site IP addresses on NT 4.0, you must switch to static Web site IP addresses and disable CC failover.