By Rich Farrell
Network World, 9/22/97

Imagine if your Web site were like a supermarket checkout, and your customers always got in the slowest cashier's line. Before long, they'd grow frustrated and go elsewhere. But there are ways to build Web sites so everyone quickly gets what they came for. The secret is balancing the load to multiple Web servers, ensuring continued service. We looked at four load-balancing devices that enable you to split traffic over several machines, add and remove machines dynamically, and evaluate the relative capabilities and capacity of a machine before assigning traffic to it.

We tested Cisco Systems, Inc.'s Local Director; F5 Labs, Inc.'s BIG/ip2; RND Networks, Ltd.'s Web Server Director Pro; and HydraWEB Technologies, Inc.'s HydraWEB Load Manager. All of the products were good, and each one had features that made it suitable for particular network configurations. However, the full suite of redirection algorithms and the administration capabilities of Cisco's Local Director put it at the top of our list.

While none of the products are inexpensive, one may be better suited to smaller server farms than the others. HydraWEB is the only company that prices its product according to the number of servers it is balancing. A minimal configuration of four servers costs $7,990, or $12,980 for a redundant configuration.

Many similarities

None of these load-balancing devices should cause a performance bottleneck because their rated capacity goes well beyond the maximum physical load they can support (see table, page 58). For Web sites that run on 10M bit/sec networks or have slower Internet connections (T-1, for example, is 1.54M bit/sec), the most important factors in choosing one of these products are failover features, administration, security, monitoring and cost. It's also wise to look for the ability to balance traffic by port and reconfigure supported servers on the fly.

The products we tested publish a virtual IP address that looks like a single physical machine to network clients for each server farm they support. As clients send traffic to the virtual address, the load-balancing devices redirect the requests to any number of servers. In cases in which the machines support more than one virtual IP address (and thus multiple domain or machine names), the redirected traffic may be sent to different back-end machines for each virtual IP address or to different ports on the same machines.

TCP/IP-based protocols use ports to "listen'' for incoming traffic. On a Web server, port 80 is the default port on which the server expects to receive traffic from a Web client. Thus HTTP requests that specify only a host name and not a port (as in www.server.com) are handled by port 80. However, you can specify any port from zero to 65536 (as in www.server.com:9000).

All of these load balancers except BIG/ip2 can map incoming requests to a port other than port 80. With port mapping, you can equate port 80 in a virtual IP address to any other port of a Web server. This allows services to advertise a catchy domain name rather than the more complex name of the server that's actually fulfilling requests.

Unlike the others we tested, BIG/ip2 doesn't allow port redirection and, therefore, can't support multiple domain names for HTTP and other protocols. BIG/ip2, however, can enable or disable inbound traffic by port. For example, you can allow only HTTP on port 80 and only File Transfer Protocol on port 25.

A load balancer uses one of several algorithms to choose which Web server is best suited to handle a given request. Redirection algorithms used by the various products range from simple round-robin distribution to monitoring the number of active connections or even monitoring the system loads of the Web servers (see story, page 58). Local Director supports the broadest range of redirection algorithms, but it doesn't have an algorithm that runs a process on each of the real machines to directly assess the viability of the machines. Only HydraWEB has this feature.

Failover performance

Local Director, BIG/ip2 and HydraWEB provide failover by connecting two load balancers via a serial cable. Loss of one of the units is noticed by the other, and failover occurs automatically. Instead of a physical cable, Web Server Director broadcasts preferred routing instructions to the virtual IP addresses with secondary routes for failover situations, making it more fault-tolerant than the others.

What happens when the serial cable fails? With BIG/ip2 or HydraWEB, each of the two devices assumes primary control. This is a highly undesirable situation that would leave your Web site unavailable until the cable was replaced and the systems recovered. Cisco says when Local Director detects the failure of its cable, machines will not failover but generate SYSLOG messages about the failure. Standard monitoring of SYSLOG could detect this situation, and Local Director will continue to function until one of the boxes fails.

Each of the devices supports detection of failed Web servers behind the redirector device. In our tests, they all routed traffic to the remaining servers, avoiding the failed one. For this kind of failure, HydraWEB recovered in our testing within 10 seconds, BIG/ip2 in under 15, Web Server Director in less than 20 and Local Director in 45 seconds. Both Web Server Director and HydraWEB allow nondedicated servers to be configured as backup machines, taking over Web server duty when another machine goes out of service. Maintaining state Protocols such as FTP or SSL require all of a single client's packets in a single session to be continually handled by the same server. In order for this to happen, the load-balancing devices must maintain a table of this state information - IP addresses and source ports as well as destination and destination ports used. This information remains in the devices' memory for a configurable period of time. If the protocol being transferred does not require state, all the devices except RND's Web Server Director can be configured to not maintain the table of addresses and to let traffic go to different machines each time. RND says it plans to add that functionality.

Local Director allows you to configure the timeout value separately for each virtual server and port. Web Server Direc-tor allows the timer to be dropped to 1 second and in a future release, will allow it to be set to zero, indicating it's not to be used.

Systems administration and monitoring

All of the devices support large numbers of servers, which should be sufficient for any Web site. Local Director supports 10,240 virtual and real IP addresses; BIG/ip2 supports 255 virtual and real hosts, though the soon-to-be-released Version 1.7 is scheduled to support unlimited numbers of real and virtual hosts; Web Server Director supports more than 50,000 real machines and 500 virtual addresses; and HydraWEB supports unlimited varieties of both.

Local Director has a command-driven interface for maintenance and monitoring and can be administered via telnet. Configuration is straightforward, with just a few commands required to get online.

BIG/ip2 can be managed via telnet and an RS-232 console. Being Unix-based, it can be monitored using standard Unix tools. The virtual hosts are the names and IP addresses published to the Internet, from which the load-balancing devices redirect traffic to one or more real devices that service the requests. BIG/ip2 provides an easy-to-use graphical interface that supports Data Fellows, Inc.'s SSH encryption and is expected to release an X Window interface soon as well.

Web Server Director has the easiest and most intuitive systems administration interface and load-monitoring utilities. You can manage the device remotely using a graphical interface on a PC or via a console session.

Web Server Director is accessed via a graphical client. Initially, we used the console port to configure Web Server Director and to enable some IP addresses for the graphical client. We finished our configuration with the graphical user interface. Web Server Director can distribute traffic to remote servers anywhere on the Internet, while the other products only distribute traffic to servers on the local LAN.

HydraWEB has in-depth configur-ation options but the most technical of all interfaces. We could reach Hydra-WEB by telnet, but for security reasons, we recommend using one of the remote logon options, such as dial-up or a remote console, attached to the serial port. HydraWEB also notices whether a machine or one of its ports has stopped responding. HydraWEB supports a virtually unlimited number of servers, al-though licensing costs are less for small numbers of servers. Along with standard Unix tools for monitoring the device, HydraWEB has built-in facilities for e-mail and pager monitoring.

Accessing HydraWEB through an RS-232 port using its Proconsul interface lets you modify the local system, and Proconsul can be utilized with remote console devices. HydraWEB's shell access includes administrative services for managing HydraWEB and viewing system state. We also could set up accounts to allow nonprivileged users to monitor the device.

Security vs. access

BIG/ip2 and HydraWEB, being Unix-based products, allowed Unix-based security with products such as Free BSD S/Key or Security Dynamics Technology, Inc.'s SecurID. BIG/ip2 performs several firewall functions, such as IP and port control list, acting as a choke point to keep the servers behind it invisible to the external network. HydraWEB also supports dial-up.

Some Webmasters may wish to hide their web servers so their IP addresses and names are not published and the machines can't be accessed via telnet or ping. Other sites may want individual machines to be available directly by name or address for monitoring purposes or to make it easy to connect to individual machines.

Of the devices we tested, only BIG/ip2 never allows individual machines to be available to the network. HydraWEB normally is configured so the addresses of managed servers are hidden from the external network, but this is not required.