Load-Balancing Switches: Balancing Act

For the majority of folk across the globe, the web commands in our lives. We are increasingly becoming dependent on the web and staying connected for the big part has become normal. With the quantity of web businesses rocketing daily and more folk choosing to home work, the necessity for a trusty web connection is at a new high. Staying connected and avoiding down time has become critical because down-time causes massive monetary losses to firms and people. In this post we introduce the theorem, significance and advantages of load balancing for the Net. Let us start with a real understanding of what net load balancing truly means. PC networks route many billions of information packets every 2nd. For this information to be routed efficiently, networks need to operate at perfect potency. Enter load balancing as the perfect solution to helping networks operate more effectively. Thru the even distribution of the processing and traffic across the network, the technology guarantees that one single medium isn't over taxed. Net servers use load distribution technology to help in the even distribution of traffic across countless servers. What this achieves is an effective employment of the available bandwidth. There's increased potency leading to quicker access to the numerous web sites hosted by the servers. Net load balancing is done in one of 2 ways : inwards bound and outward bound. Let us inspect each type individually to more clearly comprehend how they function. Incoming balancing supports multiple servers but to all external appearances shows up as only 1 system. Load balancing for incoming traffic uses dynamic DNS thru one of 2 ways.

It can either be joined into the system or provided thru an external service. The benefit to having it built into the system is savings and better control.

Balancing for incoming traffic processes traffic from remote users. Thru the utilising of multiple servers it assists in increasing bandwidth, providing better connectivity and low down-time. This technique helps augment the potency of the info retrieval process. Outgoing balancing technology especially helps to process distribution of traffic in an even and efficient demeanour over the network. This helps to meet the objectives of connectivity and high speed performance for worldwide users.

Load distribution for outgoing traffic offers one or two benefits including practically uninterrupted connectivity, reinforced bandwidth potency and the capability to utilise various web technologies. In addition, it is actually possible to implement flexible load balancing options. To summarise, the even distribution of processing and communication activities across the network to reduce one server being overloaded is the first purpose of net load balancing. This alternative approach helps to improve the performance of busy web sites by the fairly straightforward process of accelerating the website servers in use.

When traffic is uniformly distributed across a cluster of back end servers, the potency of the site is improved enormously.

Load-balancing devices are becoming more common to support high-traffic Web sites that can't process all requests on a single server.

Rather than move to more powerful hardware, it makes sense to create clusters, or farms, of servers. In fact, with new functionality that can send traffic to a given server or farm based on the URL, it's possible to have a single Web site that is spread across several different clusters of servers.

As Web sites grow in size, complexity and traffic flow, load-balancing devices are also evolving to keep up. From a relatively simple setup with a single virtual cluster that has a few physical servers attached to it, Web sites are moving toward a much more complex model that may include several virtual clusters serving specific areas of the Web site--one for static content, one for e-commerce transactions, one for surveys, as well as virtual clusters of other devices such as Internet routers, VPN routers or firewalls.

Last year, our review of load-balancing products covered both switches and routers and included five products. This year, there are at least eight switch candidates and more routers, so we decided to split the review in two and cover switches and routers separately.

The products we received were the Alteon Systems AD3 and Foundry Networks ServerIronXL eight-port 10/100 switches, and the RadWare four-port Web Server Director (WSD) Pro+. All three have more functionality than the products reviewed last year, including features such as geographic load balancing; routing of traffic based on cookies, the URL, or SSL session IDs; load balancing of outbound traffic as well as inbound; and improved management utilities.

Each product has strengths that make it appropriate for some contexts. A simple comparison is difficult--looking at a strict cost per port, the Foundry switch is less than half the price per port of the Alteon, but the Alteon includes one gigabit uplink port and a more mature feature set. Each is much less per port than the RadWare. However, this doesn't tell the whole story. If you're looking for basic URL-sorting functionality to enable Web caching, the Intel 550T has a much lower price per port.

All the switches have considerable functionality not addressed in this review, ranging from extensive filtering capabilities to the ability to combat denial-of-service attacks. Also, RadWare's WSD is more geared toward the ISP, providing, for example, the ability to route to up to 10,000 URLs, compared with 256 URLs for the ServerIron and 64 URLs for the AD3. It also comes with a site visit from one of their engineers.

This review is broken into the same areas as the scorecard: documentation, administration, setup, feature set and price/performance. Each of these categories will be examined separately, and each product contrasted with the others.

Setup

Setup of all three devices is similar. The serial interface is used with a terminal program to set the basic TCP/IP information, and then all subsequent configurations can be performed either via a terminal connection using the serial interface or a Telnet connection, or via a Web browser connection. All three devices provide a simple interface for entering the basic information.

RadWare sends a technician to configure its units. In the case of this unit, the company sent a technical-support engineer who was knowledgeable in the setup of WSD and load balancing, and Layer 4 routers in general. He was able to get the WSD configured for testing quickly and efficiently, and he also gave a quick tour of the available features. We would not have allowed this if it had not been part of the typical user experience.

Setting up all three devices was complicated in part because the subject is complex and the setup methods are difficult. At a minimum, you must have a virtual cluster and some real servers under it. The virtual cluster and servers are on a separate subnet from the clients. The Alteon switch also has a group function that contains real servers. You must define a group of real servers and assign one or more groups to a virtual cluster.

We were able to do the basic configuration of the box and set up the virtual cluster used in our testing quickly and fairly easily on all three devices. The WSD, of course, was the easiest to set up, since the technician was there to prompt us at all points with the correct way to configure the device. We did the steps ourselves, though, and found that the configuration was easier for us to figure out on our own as well.

Administration

Representatives from both Alteon and Foundry told us their customers have requested command-line interface (CLI) functionality and don't seem to be interested in browser-based administration. We have to wonder if this input is coming from administrators or from IT managers--if we were running an IT department, we would want to ensure that new administrators required as little training as possible, giving the current and projected shortfalls in staffing throughout the industry.

Alteon and Foundry provide a CLI that is similar to the industry-standard Cisco CLI, although we found that navigational usages varied considerably. For example, the ServerIron uses exit to go back up the menu tree, while the AD3 uses "..". The WSD doesn't use a tree at all--commands must be entered completely at a command line. Rather than something like "configuration, IP, address, 192.72.155.10" as separate commands, the whole line must be entered at once. This introduces a greater chance for error. However, since the WSD has a really good browser interface that encompasses all of its features, this is less of an issue.

We also found with the ServerIron and the AD3 there were a number of features only accessible from the CLI--they could not be configured through the browser interface. The Alteon seemed to have most, though not all of its functionality available through the browser interface, but there were a few commands that didn't seem to "take" when done through the browser, even when we were careful to apply the changes and rebooted the switch afterward. Telnetting to the switch and making the changes through the CLI worked quickly and easily, once we figured out the syntax for entering the commands.

Feature Set

In addition to simply farming out all requests to a Web site to a virtual cluster, these products allow requests to be separated in several ways, so that a Web server can be partitioned on several servers or farms, each one providing a different function--perhaps one caching static content, one handling CGI scripts and one doing database lookups for e-commerce.

The products also allow for persistence, which makes sure that a client engaged in a series of transactions is always connected to the same server in a cluster for the duration of the sessions. The first generation of this technology used the client's IP address to determine if a persistent connection should be set up.

The problem is that with so many networks using network address translation (NAT), there is no guarantee that all requests from a single IP address are really from a single client--they might be from dozens to thousands of clients. The newer versions of persistent connection support look for a cookie header or SSL session ID.

URL-based routing lets the switch determine which server or farm should get the request based on the URL that the client has requested and route it appropriately. This can be done by the path (all items with /homepage in the URL go to a particular cluster), by file name (all URLs that have filename.gif in the path) or by port (simply all requests to port 80, the default HTTP port or some other port).

Cookie-based routing allows a cookie to be placed on the client system that can signal the switch as to which server or cluster it needs to communicate with. The cookie is stored on the client system and puts information in the header of the packet sent to the Web site that allows the switch to determine where the request should be directed, and ensures that a client is directed to the same server for the duration of a transaction. All three products support cookie-based routing.

SSL session ID switching allows the switch to determine that a secure socket layer connection has been established between a client and a specific server, and routes specific requests from that client to the same server to maintain a persistent connection for the entire length of a transaction. Foundry, Alteon and RadWare all support SSL session ID switching.

Redundancy

All the switches allow for redundant devices. Active/active devices allow for two devices to handle different virtual clusters and fail over the load if either device fails. Active/passive devices allow for a second device to function as a hot spare and take over if the primary device fails. Alteon and RadWare provide active/active functionality, while Foundry allows for active/passive redundancy. These functions were not tested, since we had only one of each device.

Cache Redirection

As Web servers become steadily more loaded, one way to ease the burden is to create cache servers. Cache servers hold the static content of a Web site and are optimized to serve that content rapidly. The problem then becomes how to separate the content of a Web site that is static and can be cached from the content that requires response from the client or the server, and then how to direct the client to the cache server rather than to the regular Web server.

All these switches can determine by the URL a client asks for whether the client should be directed to the cache or to the server that handles the dynamic content. They can do this by examining the requested URL. For example, a Web site could be set up so that all static content was in a /static directory. They can also look at the type of file requested--all *.JPG files would be from the cache, while all *.CGI or *.ASP files would be from the active server.

Firewall/Router Load Balancing

In addition to balancing loads across a cluster of Web servers, it's often desirable to balance loads in the other direction as well--to create a virtual cluster of firewalls, routers or VPN devices. Both the Alteon and Foundry switches offer this functionality, although it's much easier to find and configure on the Foundry switch. This feature allows you to create groups of routers and give them relative weights (for instance, if one is a T-1 and the other is a T-3).

Algorithms

The actual load-balancing process relies on an algorithm to tell it how to distribute requests to the actual servers in a virtual cluster. The three types of algorithms are static, dynamic and agent-based. A typical static algorithm is round-robin, simply sending each request to the next server in the group. A static algorithm is not very effective in balancing loads between servers in a cluster, since it is extremely unlikely that loads will be static.

A dynamic algorithm sends the next request to the server that is least loaded. Two typical dynamic algorithms are fastest response and least users. They send the next request to the server that responds fastest or to the one with the least number of current users, respectively.

Agent-based algorithms use load-reporting software on the servers to determine the actual load on each server. They produce the most accurate results when balancing load.

Health Checking And Failover

Each switch has a number of ways of checking to see if servers in a virtual cluster are healthy, and what to do about it if they are not. All three support PING and ICMP checks to see if the server responds. The Alteon can also check specific ports (such as port 80 for HTTP) to make sure a service is alive, check URLs to make sure that a given part of the Web server is still alive, and check to ensure that remote authentication dial-in user service (RADIUS) and Internet message access protocol (IMAP) servers are still operational. The Foundry can also check for specific URLs and for DNS responses and HTTP responses from a server. The RadWare can check specific ports or specific URLs.

The RadWare product has a couple of interesting features for gracefully shutting down and restoring servers in a cluster. If you need to take a server offline and just shut it down, clients currently connected will experience failures. The WSD allows you to designate a server in the cluster as about to be shut down--it will not receive any new requests, and you can allow the existing clients to disconnect on their own, then bring the server down when it is free.

The WSD also allows for the gradual reintroduction of a server into the cluster. When a server is brought back online, rather than it receiving a deluge of traffic all at once since it would be the least heavily loaded, you can designate that it receive traffic more gradually, so it isn't hit with an immediate high load.

Bypassing The Switch

Each company refers to this differently--Alteon calls it direct-server return, Foundry calls it direct cache-server return and RadWare calls it triangulation--but the idea is the same. When requests are directed through the switch to a server, the normal assumption would be that the reply from the server to the client would also go through the switch. However, it's possible to set things up so the server can reply directly to the client, bypassing the switch and sending return traffic directly to the router, which reduces the traffic on the switch and allows the switch to handle the difficult tasks.

Geographic Load Balancing

Geographic load balancing provides the ability to have Web servers at several distinct geographic locations. The switch will determine which site is closest to the user and route requests to the appropriate server. This is a complex process that involves testing response time back to the user and can be modified by creating varying costs for each route to designate a preferred route and a secondary one. Alteon doesn't support URL-based routing when in global mode; RadWare and Foundry support only failover.

Geographic load balancing is quite complex to configure and requires multiple devices. It was not tested, since we had only one of each device. If this is a capability you are interested in, take a look at the documentation and also make sure to discover whether all sites require the same device or whether a less expensive device is available for the remote servers.

Additional Features

There are a number of features that are not mentioned in this article; some shared by all the products, some unique to one of them. They all have the standard set of Layer 3 and 4 functionality, including network address translation (NAT) and virtual LANs (VLANs).

Documentation

Documentation is not the strongest suit of any of these devices. The Alteon switch was the only product that came with printed documentation, and it consisted of a user guide and three addendums, which made it difficult to pick out which document had the latest information on any particular feature.

The documentation was also typical of the CLI-first attitude. The manuals generally discuss administration through the command-line interface, rather than the Web interface. Unfortunately, the commands are not always exactly the same between the command-line interface and the Web interface. Although at least with the Web interface, it is generally possible to find what you're looking for more easily than referring back to the documentation for the particulars of syntax of commands.

The Foundry CD-ROM contains the documentation for all Foundry products, which can make picking the correct set a little confusing. We found ourselves printing out the 200 or so pages of the two PDF files in order to be able to peruse them at our convenience. We'd like at least the option of printed documentation.

The RadWare documentation does a good job of documenting the GUI interface, but relegates the CLI interface documentation to an appendix. Again, there was no printed documentation, which was an inconvenience as we ended up printing out a couple of hundred pages.

Price/Performance

Testing of the devices was more limited than we would have liked. None of the load simulation tools available are set up to simulate a live Web site in ways that are useful for testing load-balancing devices.

In addition to the basic testing we performed, we'll try to give you a feel for what the various benchmarks you might see actually mean, and what they might or might not indicate in terms of performance on an actual Web site.

While there are tools that will simulate lots of clients attaching to a Web site, they all do the same very basic attach and detach, which is not at all characteristic of the real world. The ideal tool would simulate a number of different users at different IP addresses doing different things: viewing a GIF file, listening to a sound file, downloading an executable, conducting an e-commerce transaction, filling out a form and so on.

While it's possible to create this kind of simulation using scripting tools, that method requires dozens, hundreds or even thousands of PCs running the scripts to produce traffic at real-world levels, to say nothing of being able to stress the capacities of the switches.

In addition, the creation of benchmarks that adequately characterize these switches is a separate problem. Ironically, both Foundry and Alteon sent us copies of Tolly Group studies that showed that their switch was superior to the others' (two different studies). The two studies differed in the ways they tested the switches: One essentially tested the maximum number of connections that could be set up in a second, while the second tested how many simultaneous connections could be maintained.

Either might be significant depending on the type of Web site it was supporting, and neither necessarily reflects anything more than the architecture of the box. The Alteon has a 64,000 simultaneous session limit per port, so a very large number of requests from a single user can overwhelm the ports, while the Foundry session table is a per switch table and can go up to 1 million sessions. In a real-world scenario, neither is very likely to provide a major advantage.

When a browser opens a connection to a Web site, it can open many TCP connections to that site. Many benchmarks use TCP open/close sessions--simple open and close sessions with no content--which don't really mean anything in the real world, since an actual user would never attach to a web site and immediately close the session without even viewing the home page. A "Web session" is purely dependent on the file size being retrieved. Grabbing a 1-KB file will consume less time than grabbing a 1-MB file. So, there is no correlation between Web sessions per second and TCP sessions per second.

Some benchmarks say that a particular product can "set up and tear down xxx,000 sessions per second." These numbers are reached using Netcom's Smart-TCP application and the SmartBits network traffic generator, which does nothing more than open a session and immediately close it. Successful open/close combinations are then measured per second. Again, this in no way reflects real-world scenarios.

Another issue is that a single user may, in the course of browsing a Web site, open as many as 1,000 TCP sessions, each with a different sized "payload." The way the Alteon and Foundry switches keep track of sessions, this would create 1,000 entries. On the other hand, with the RadWare device, all 1,000 sessions would be a single entry in the client table.

With the RadWare product, the client table can have 200,000 simultaneous entries, which could equate up to millions of TCP sessions. The Foundry product can handle 1,000,000 simultaneous sessions, while the Alteon can handle 512,000 simultaneous sessions. This is probably more critical than the number of sessions per second, even if they were calculated at a given useful file size. The reason is that most Web sites are behind an Internet connection.

With a T1, the connection would support 48 connections per second, supposing an average of 4 KB for files transferred, and 24 connections per second for 8-KB average files.

A T3 would support 1,400 connections per second for 4K files and 700 connections per second for 8-KB files. Even an OC3 would support only 4,500 connections per second for 4-KB files and 2,240 connections per second for 8-KB files.

All of these devices have their strengths. The AD3 offers an extensive and mature feature set, with a reasonable price and high performance.

The ServerIronXL has the lowest price and the most ports, but it doesn't offer quite the level of functionality of the other two. It may very well be sufficient for many corporate sites, though.

The WSD is expensive, but it brings features to the table that will be desirable for ISPs or very large sites with multiple Web servers. It offers an excellent administrative utility and a simple configuration process, plus on-site installation support. It is our score-card winner by a scant point.

Before you write to tell us that your favorite product was left out of this review, here's the procedure we used: We posted notification of this upcoming review on our Web site in September. Cabletron, Cisco, Arrowpoint and Holontech declined to participate. Bay Networks and Packet Engines/Alcatel did not respond or did not have suitable products available in time for the review.

A separate review of load-balancing routers, both routing appliances and software-only products will follow shortly.

Logan G. Harbaugh is a technology editor at Information Week, a sister publication of InternetWeek. He can be reached at lharbaugh@cmp.com