Server Load Balancing: Help for Network Administrators

by Tony Bourke

Overview

Load balancing improves network performance by distributing traffic efficiently so that individual servers are not overwhelmed by sudden fluctuations in activity. Server Load Balancing is a guide to this critical component of high availability, clustering, and fault tolerance, all of which provide the infrastructure for reliable Internet sites and large corporate networks. Much of the information on load balancing comes from vendor-specific manuals that use inconsistent terminology and are often biased toward the products they cover. Server Load Balancing explains to engineers and technicians the concepts and terminology of load balancing and offers practical guidance for planning and implementing it in almost any environment. It includes a configuration guide with diagrams and sample configurations for installing, configuring, and maintaining products from the four major vendors:

• Alteon WebSystems
• Cisco's CSS Series (formerly ArrowPoint)
• F5's BIG-IP
• the Foundry ServerIron series

By comparing several load balancing products, you'll gain a deeper understanding of the technology and how best to use it to improve your network performance. No system administrator responsible for traffic management should be without this practical guide.

Product Details

ISBN-13:	9780596000509
Publisher:	O'Reilly Media, Incorporated
Publication date:	08/08/2001
Pages:	192
Product dimensions:	7.00(w) x 9.19(h) x 0.46(d)

About the Author

Tony Bourke is a private consultant specializing in Unix administration, networking, and load balancing. He has held positions at SiteSmith, GlobalCenter, and Digex. Tony has designed and implemented SLB and Unix architectures for many high-profile and high-traffic web sites. He has published articles in Sys Admin Magazine, Hostingtech Magazine, and Network World. He is one of the leading authorities on the topic of server load balancing and frequently speaks at conferences around the country. He can be reached at [e-mail].

Read an Excerpt

Chapter 7: NAT-Based SLB Network Architecture

NAT-based SLB network architecture is, by definition, any SLB network implementation where the IPs of the VIPs and real servers are on different subnets. It is named NAT because the load balancer NATs packets traveling between two subnets, much like a firewall or a router performing a NAT.

Implementation

The main difference between NAT- and flat-based architectures is that the SLB unit performs a NAT from one network to another. The best and most typical way to implement NAT-based SLB is with a route-path, two-armed configuration. In Figure 7-1, the SLB device translates normal routed IP addresses (represented by the nonrouted 192.168.0.0/24 IP space) into nonrouted IPs, on which the web servers sit....

...In this configuration the servers are on a separate VLAN from the VIP addresses on the load balancers. On the public network, the only floating IPs between the active and standby load balancers are the VIP addresses. There is no need for a floating default gateway (such as 192.168.0.10 in the flat-based example) on the public network, since the load balancers aren't acting as default routes on that network. The floating gateway is included on the private network (10.0.0.1 in the following figures). The load balancers can also function as firewalls because they have such tight control over traffic flow.

Sometimes NAT-based SLB is implemented, but, in this method, all devices share one LAN. The load balancers are configured for multiple networks on the same LAN, and they perform the NAT themselves. We see this type of configuration in Figure 7-2....

...The load balancers are configured for two subnets on the same LAN, one for the public interfaces for the VIPs, and another for the web server's private subnet. Even though everything is on the same LAN, the load balancer still performs the NAT.

From both a security and an architectural standpoint, it's better to use a two-armed configuration with two separate LANs (or two VLANs). Putting everything on one LAN defeats several of the security objectives and advantages of a NAT-based configuration. Keeping an actual barrier between the server and public network reinforces the overall security of a site. Traffic flow is easier to manage with two (V)LANs as well. There is a clear delineation and demarcation point for the two separate networks, making troubleshooting, in many cases, much easier.

Bridge-Path and DSR

Because NAT from one network to another is a Layer 3 function, bridge-path isn't an option for NAT-based SLB. For NAT to work, the load balancer must have interfaces on two networks, and bridge-path generally involves only one network.

DSR is not as common in a NAT-based scenario as it is in a flat-based setup, but it is possible. Unlike flat-based scenarios, a Layer 3 device is required in addition to the load balancer and Layer 2 infrastructure to work with DSR. As per a DSR scenario, the packets have already been rewritten on the way out of the actual servers with no need for any more processing. The Layer 3 device simply forwards the packets from one network to another--a process that is resource-intensive but saves the load balancer some work. In Figure 7-3, we see an example of a NAT-based configuration with DSR....

The redundancy component was removed to better show how DSR would fit into this type of scenario. A packet comes to the load balancer (step 1) and is sent to a web server, such as ws-3 (step 2). The web server then sends the packet out already rewritten (step 3), but it still needs to be forwarded to the public network so it can get to the Internet. The Layer 3 device forwards the packet unchanged to the public network and then on to its destination (step 4), without adding any additional load to the load balancer. The actual load on the Layer 3 device is minimal, since all it is doing is forwarding packets with no processing.

Why NAT-Based?

There are several advantages to NAT-based SLB, most of which involve the extra security that a NATed connection can provide, especially when the servers are on a nonrouted RFC 1918 address space. When dealing with servers on a nonrouted IP space, you have a great deal of control over how the servers are actually seen by the world.

This architecture lends itself well to a site where the majority of traffic is HTTP (or SSL). With the added security of the NATed IPs and the relatively low in-out ratio (approximately 10 packets out for every packet in with HTTP traffic, while hundreds of packets go out for every packet in with streaming), the NAT-based architecture can provide an additional measure of security and performance. Web and SSL applications both work well with NAT.

Traffic Flow

To understand how flat-based SLB works, let's take the example of a user with an IP address off 200.200.200.20. Table 7-1 illustrates the changes in IP source and destination addresses. The process takes four steps:

1. The user initiates an HTTP connection by typing the domain name of vip-1 (192.168.0.200) into the browser. The connection goes to the load balancer.

2. The load balancer takes the packet and rewrites the destination address, leaving the source address as it is. The new destination address is 10.0.0.100, which would be the web server ws-1.

3. The web server responds and sends traffic back to 200.200.200.20. The traffic passes through the load balancer, as it is the web server's default route.

4. The load balancer rewrites the packet on the way out with the source address 192.168.0.200. The packet travels back to the user and completes the journey.

Network Configuration

The following sections outline some basic IP configurations that may be used as examples for setup and installation of NAT-based SLB networks. The redundancy and wiring are typical for this type of scenario but are by no means the only ways to implement an SLB site. These configuration examples are used in the chapters involving specific vendor configurations.

Routers

The routers are configured exactly as in the flat-based topology (see Table 7-2). Two routers, one active and one standby, are configured with a floating IP address between them. The active unit is given a VRRP priority of 200, while the standby is given 100.

SLB Units

The SLB units are configured a bit differently in Table 7-3. The VLAN 1 configuration is identical to the flat-based network architecture, while in the NAT architecture, there is a whole other network configured on VLAN 2. Different products have different ways of denoting which interfaces are outside and which are internal. Switch-based load balancers allow you to set VLANs, while server-based load-balancers usually have those roles labeled in their Ethernet interfaces.

You may notice a similar numbering and configuration scheme of VLAN 2 to the routers r-1 and r-2. This is because the SLB units are acting as routers and are the default gateways for all web servers. Because of the similar function, it simplifies matters greatly to configure them like the routers.

Again, notice that there is no floating default route between the two load balancers on the public VLAN, while a shared IP is on the private VLAN. Since there are no servers on the public VLAN, there isn't a need for the load balancers to serve as a default route on that network.

Web Servers

In Table 7-4, the web servers are configured on the nonrouted IP address space rather than routable IP address space. Other than that difference, they are configured exactly as with the flat-based network architecture. The default routes are configured to point towards the load balancers.

VIP Configuration

The VIP configuration is shown in Table 7-5. The VIP is, of course, on the routable IP address space, while the real servers are located on the nonrouted IP address space. The SLB units serve to perform the NAT between the two networks.

Individual Pass-Through VIPs

Since the web servers aren't directly available to the Internet, it may be necessary to set up additional VIPs, each corresponding with an individual web server. This would allow a user to browse each individual server, which can be useful for troubleshooting and individual administration. This type of VIP is called an "individual pass-through" (see Table 7-6).

Switches

There are two ways to implement switches into a NAT-based scenario: using separate switches for the public network and server networks or using the same switches with VLAN separation. Which is more appropriate primarily depends on budgetary and security concerns.

One way to implement switches is to take a switch (or pair of switches) and divide it into two separate VLANs. By electronically separating the LANs, the traffic for each network is sequestered. Implementing VLANs often provides cost saving in equipment, additional flexibility in port configuration, and easier management, all while still offering a measure of security. Another way to implement switches is to use separate switches for the public LANs and the private server LAN. Some smaller switches do not offer the VLAN feature. If a site is using hubs rather than switches, there can be separate hubs for the public network and the private server network.

Some security experts are wary of having a single device separating two LANs electronically. They would prefer to have the two networks separated physically. If everything is protected by a firewall, this shouldn't be much of an issue. Again, it's up to each site's administrator to decide. In any case, the public network traffic should be separated in some manner from the private server network for security and troubleshooting reasons. Also, it just makes for a neater, cleaner network....

Table of Contents

	Preface	ix
I.	Concepts and Theories of Server Load Balancing	1
1.	Introduction to Server Load Balancing	3
	In the Beginning	4
	Evolution	7
	Other Technologies	8
2.	Concepts of Server Load Balancing	13
	Networking Basics	13
	Server Load Balancers	15
	Redundancy	16
	Provider Infrastructure	22
3.	Anatomy of a Server Load Balancer	24
	A Day in the Life of a Packet	25
	Direct Server Return	27
	Other SLB Methods	29
	Under the Hood	30
4.	Performance Metrics	32
	Connections Per Second	32
	Total Concurrent Connections	33
	Throughput	33
	Traffic Profiles	34
	The Wall	36
II.	Practice and Implementation of Server Load Balancing	39
5.	Introduction to Architecture	41
	Architectural Details	42
	Infrastructure	46
	Multipurpose Devices	49
	Cast of Characters	51
6.	Flat-Based SLB Network Architecture	54
	Implementation	54
	Traffic Flow	57
	Flat-Based Setup	58
	Security	60
7.	NAT-Based SLB Network Architecture	62
	Implementation	62
	Traffic Flow	66
	Network Configuration	66
	Security	70
III.	Configuring Server Load Balancers	73
8.	Alteon WebSystems	75
	Introduction to the CLI	76
	Getting Started	78
	Security	81
	Flat-Based SLB	84
	NAT-Based SLB	90
	Redundancy	95
	Additional Features	98
9.	Cisco's CSS (Formerly ArrowPoint) Configuration Guide	99
	Introduction to the CLI	100
	Getting Started	101
	Security	103
	Flat-Based SLB	104
	NAT-Based SLB	108
	Redundancy	114
	Syncing Configurations	117
	Administration Network	117
	Additional Features	118
10.	F5's BIG-IP	119
	Getting Started	119
	Flat-Based SLB	125
	NAT-Based SLB	126
	Redundancy	127
11.	Foundry ServerIron Series	129
	Command Line Interface (CLI)	130
	Flat-Based SLB	133
	NAT-Based SLB	135
	Redundancy	136
IV.	Appendixes	139
A.	Quick Command Guide	141
B.	Direct Server Return Configuration	151
C.	Sample Configurations	157
	Index	167