Load balancers from F5 Networks and Zeus Technology tip the scales

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.