Balancing the TCP/IP load

By Ron Suciu
Network World, 12/21/98

A current challenge facing many network administrators is how to make their TCP/IP applications scalable and keep them available for users.

In today's marketplace, it is imperative that Web applications, telnet 3270 servers and batch file transfers are up and running at full capacity.

When there were problems with Web application's availability and traffic-load capabilities, early fixes were often implemented at the Domain Name System (DNS) server, where host names are translated into IP addresses.

One of the most popular methods of load balancing is a technique called Round Robin DNS. With Round Robin DNS, the DNS server selects servers with similar content, each having its own IP address, and rotates through those addresses as session requests come into the DNS server.

Round Robin DNS has the advantage of being transparent to the client and servers. It is also executed only once, at the start of the transaction. Unfortunately, Round Robin DNS is often unsuccessful because intermediate name servers and client software, including popular browsers, often cache the IP address returned by DNS or ignore the time-to-live (TTL) value. TTL is an IP data bit that indicates the length of time that an IP datagram can be forwarded to other routers before it is discarded.

As a result of IP address caching, the load-balancing function provided by the DNS server is bypassed, and the client continues to use the cached IP address instead of trying to reconnect. This results in a hot spot where an overutilized server continues to get additional connections.

Round Robin DNS has further limitations because it does not have the ability to differentiate by port, has no awareness of the availability of servers and cannot take into account existing workload on servers.

To remove the limitations of DNS load balancing, several other methods of TCP/IP load balancing have been developed. With these configurations, a separate load-balancing server (LBS) is placed in front of a cluster of servers. Name resolution requests are then sent by DNS to the LBS.

That allows the cluster of servers to have a single IP appearance, thus removing any dependence on DNS for load balancing. The servers' single IP address is called the cluster address.

Once the connection request is received at the LBS, there are several ways to direct the request to an appropriate server.

The simplest method is to use the redirection function of HTTP. Here, the load-balancing application uses HTTP to redirect the requesting client to a particular server within the cluster.

There are, however, several significant disadvantages to this technology. Only HTTP - Web - traffic is load balanced. Additional network traffic is generated to redirect the requesting client to the server. Bookmarking the URL returned after redirection will bypass load balancing on future connections.

A more flexible approach is for the LBS to inspect all incoming packets to the cluster address. The LBS examines the IP header of each packet sent to the cluster address to decide whether the packet belongs to an existing connection or represents a new connection request. If it's a new connection request, the LBS performs the load-balancing operation to determine which server to forward the request. If the packet is from an existing connection, the packet is forwarded to the same server chosen on the initial connection request.

These offerings can load balance HTTP or FTP traffic, as well as other standards-compliant types of TCP and User Datagram Protocol (UDP) traffic, including TN3270.

Because all incoming packets flow through the LBS, scalability can be limited based on how incoming packets are processed by the LBS. Some load-balancing applications use Network Address Translation (NAT), which modifies the source and destination IP address of the packet. The additional processing significantly increases the overhead of the incoming packet processing.

In many cases, the volume of outbound server-to-client traffic is substantially greater than the inbound traffic. For example, when you download Web page HTML and embedded images from a server, the outbound request is much smaller than the incoming images. Typically, images from the World Wide Web are at least 10 times the size of the client URLs. By utilizing NAT, additional processing is needed, significantly increasing the overhead of the incoming packet and forcing the server response to also flow through the LBS. This could potentially cause a bottleneck in the network.

Ideally, incoming packets for local servers should flow though the LBS with little or no packet manipulation and should require no proprietary agents in the servers. The outbound server responses should bypass the LBS and flow through a separate bandwidth connection.

Another key feature of any load-balancing scheme is the ability to tailor load-balancing algorithms to the applications. For example, balancing TN3270 servers is different from balancing Web servers.

Scaling TCP/IP applications will be a critical success factor for network administrators. If handled incorrectly, users will be forced to deal with slow response time or refused connections. In today's competitive market, network administrators must ensure their load-balancing solution is protocol-independent; scalable; highly available; able to accommodate various server capacity; and able to support any server platform from PC to mainframes.

Balancing the TCP/IP load

Related Links