To see how these elements are implemented in leading distributed load-balancing products, we tested Alteon WebSystems' WebOS on its Aceswitch 180 and Acedirector 3, Coyote Point Systems' Equalizer and Envoy, F5 Networks' 3/DNS, RadWare's WSD-DS and WSD-NP, and Resonate's Global Dispatch in our Real-World Labs®. We evaluated each product's underlying technology as well as its ability to create a highly available Web site from multiple geographically dispersed sites. The Alteon, Coyote Point and RadWare products are software options or add-ons to local load-balancing products, and are capable of load-balancing traffic in the traditional sense; the F5 and Resonate Global Dispatch entries work in conjunction with traditional load-balancers or the hosts themselves.
Unfortunately, we were unable to test solutions from ArrowPoint Communications, Cisco Systems, Foundry Networks and IPivot. Foundry declined to participate in our tests, citing only a partial implementation of a distributed solution. Cisco is perpetually in the middle of a product cycle, and neither ArrowPoint nor IPivot shipped their products to us before test time. We can only hope for more participation next time.
F5's 3/DNS solution took home our Editor's Choice award, edging out RadWare's WSD-DS and WSD-NP products. 3/DNS offered the most mature configuration and management utilities. Although predominantly command-line-based, 3/DNS was capable of propagating configuration changes throughout the site. Its emphasis on security, including SSH and an SSL (Secure Sockets Layer) Web user interface, makes 3/DNS ideal for sensitive installations; other products addressed security with Secure SNMP or obscure distributed protocols for site-to-site communication.
RadWare's extensive configuration options and redirection methods give the administrator full control over Web-site behavior and contributed to its close second-place finish. And though we liked the management ability of RadWare's ConfigWare most, we'd like to see some of 3/DNS's features--especially the configuration synchronization--added in future revisions.
Our rankings for the rest of the pack may differ from your preferences depending on the needs of your network. For example, Alteon WebSystems' switches may be more well-suited to your network than the Resonate Software solution. Perhaps the relatively simple configuration and ease of use of Coyote Point Systems' Equalizer may be more to your liking. Form factor and footprint also may influence your decision. The products we tested range from the very small (RadWare's devices) to the very large (F5 3/DNS's humongous 4U footprint).
Traditional load-balancing relies on use of a VIP (Virtual IP) address. The VIP address is bound to the site's domain name and all clients request content and services from the VIP address rather than the individual servers behind it. Basically, a single IP address, the VIP, acts as an entry point to your server farm, simplifying the way the world accesses your Web services.
When you move to a distributed setting--i.e., multiple VIP addresses masked as a single domain name, a la www.site.com--you run into some new problems. To mask each site's VIP address, the DNS record for www.site. com should hold one entry for each site's VIP address. This way, a DNS server cycles through the site's VIP addresses, returning them in a different order for each query of www.site. com. Sounds peachy, doesn't it? Of course, it's not that simple. There are two immediate problems with this approach. First, the global site is no longer load-balanced effectively because Web clients arbitrarily choose any IP address in the host record, conceivably revisiting the chosen IP for the entire HTTP session, and potentially later sessions as well.
Second, no matter how remote a site failure is, it will leave some percentage of your site visitors closer to the bit bucket than your valuable online product sales or customer support. There is no efficient way to direct traffic around a server failure using DNS without manipulating the host records.
Why are we concerned with DNS in the first place? Well, the DNS protocol is ideally suited to this purpose because it directs clients to a specific host before any content is requested, and it distributes the load for any IP-based service. However, as you well know, clients use DNS to resolve a site's real IP address before using TCP to retrieve content via HTTP. If we give out all the VIP addresses of a site we (1) can't control what a client does in the future, (2) might give out a VIP address of a site that is no longer functioning or is down, and (3) make no effort whatsoever to avoid a busy VIP address.
Distributed load-balancing products use DNS to dictate client behavior to a distributed site with multiple VIP addresses. To make changes to the DNS records for a global site's domain name, the product must act as the authoritative domain name server for the site's domain or host record. As clients request the host record for a domain name, the load-balancer simultaneously monitors each site in the global site and removes sites as they fail from the lists of possible responses. At the same time, the load-balancer calculates which nonfailure site can best handle the client. The product actively monitors each site, so it directs requests around busy servers in an effort to serve clients faster. The best site can be chosen by weighing various network metrics, such as ICMP (Internet Control Message Protocol) ping, hop count and site properties, including server load, connections and state (up/down).
A load-balancer solution's ability to manage more than one domain also is very valuable because HTTP redirects are only capable of directing clients to the appropriate server after they have connected and cause even more delay with each new TCP connection that is required. DNS is very efficient and directs HTTP traffic without any downside. If site content is better served from particular servers in each site, then additional domains such as images.site.com and cgi.site.com can direct HTTP traffic from the initial DNS lookup, avoiding the need for HTTP redirects. If you spend some time configuring these products, you can tweak the living guts out of your Web site's performance.
As a whole, this product category functioned adequately, leaving us quite satisfied. Therefore, we were able to focus on managing a global site. Unfortunately, our initial enthusiasm dimmed quickly when we began looking at the products' management capabilities. In most cases we found ourselves visiting each machine via a console, telnet connection or Web user interface. RadWare and F5 Networks are a step ahead of the rest of the group. Each has a standalone management application capable of managing all devices in the site simultaneously from a single location. These applications provide an above-average command-line interface. RadWare's ConfigWare had the best GUI by far, providing the most help in configuring and maintaining the global site we created. F5 offers SeeIT monitoring software--Microsoft IIS required--but it offered little help in managing an entire site from one location.