Load balancers used to be fairly simple, distributing user requests from the Internet to a group of servers instead of just one. Between the drive to differentiate themselves and the increasing sophistication of Web sites and enterprise intranets, current load balancers add a plethora of additional features, from SSL off-loading to Web application acceleration to content inspection and security filters that guard against hackers exploiting known vulnerabilities to gain control of Web servers or applications.
F5 Networks' BIG-IP 6800 Local Traffic Manager and the Zeus Technologies' ZXTM (Zeus Extensible Traffic Manager) 7000 represent the two basic types of load balancers: switch-based and router-based. The BIG-IP is based on a gigabit switch with 16 10/100/1000 copper Ethernet ports and four SFP (small form-factor pluggable) GBIC (gigabit interface converter) optical ports; the ZXTM is a dual-Opteron server that has four 10/100/1000 Ethernet ports (plus an additional management-only port).
Switch-based systems were originally harder to configure and less extensible than the router-based systems that ran a full operating system, but those days are past. The BIG-IP runs a full-fledged operating system and has many optional components available for added functionality. The biggest differences these days are the number of Ethernet ports available and the cost.
A big part of your buying decision will hinge on whether you are supporting clustered Web applications for internal use -- there are still very few businesses with multiple gigabit Internet connections. If you are supporting multiple internal Web applications or a complex cluster architecture, the BIG-IP can make life easier because it easily supports multiple subnets and clusters.
Many vendors publish performance statistics that are essentially meaningless, such as hundreds of thousands of simultaneous connections. These statistics are often generated using zero-byte packet sizes, which never occur in the real world. In real life, you're more likely to saturate your network connection before you see performance degradation based on hardware limitations. The possible exception to this is when you are doing operations that require substantial processing. Operations such as SSL encryption, header rewriting, sticky sessions for e-commerce, cluster routing based on URL, content, or cookies, and parsing requests for out-of-bounds information can bog down a load balancer fairly quickly.
In my testing with these two systems, however, using real-world type traffic, I found that a single gigabit pipeline became saturated before the systems slowed due to performance limitations -- even with processor-intensive operations. So although you might bog down one of these systems by using small packets to set up a lot of simultaneous connections, if the connections are actually doing something, you're more likely to saturate your Internet connection than to see utilization hit a wall on either of these load balancers.
My testing involved setting up several servers with the same Web site, a demo version of an e-commerce application. Each load balancer was used to create a virtual cluster of the servers, which varied in processor number and power. I then used an Ixia 400T traffic generator and IxLoad software to simulate a large number of users accessing the site. Both load balancers were able to keep actual loads on the servers consistent even though the servers' processing capabilities varied considerably. I then enabled a number of features such as SSL sessions and application security, and attempted to overload the load balancers by simulating many simultaneous users. In both cases, overloading these systems was possible only with artificially small sessions. When simulating traffic, the gigabit connection became saturated before the limitations of the BIG-IP 6800 or ZXTM 7000 were reached.
Both products offer a wide array of features, including service-level management and bandwidth shaping, DoS (denial of service) protection, session persistence based on URL, cookies, header information, and other methods, and support for Web services as well as XML, XPath, and XSLT. Their application acceleration capabilities include compression for many Web applications, not just HTML, and both units can balance loads across multiple sites as well as multiple servers at a single site. F5 and Zeus both supply scripting languages and APIs for integration with corporate applications.
Some of these features are options that cost extra. Zeus has an advantage here, as more features are included in the base price, although F5's versions of the features are usually more sophisticated and easier to deploy. For instance, the ZXTM 7000 includes HTTP filtering to protect against exploits, but you must download a definitions file from the Zeus Web site and add definitions manually. F5's ASM (Application Security Module) protects against more kinds of attacks and has an automatic update service. On the other hand, the ASM costs an additional $US12,500.