The Tao of Network Load Balancing

Configuring NLB clusters to achieve balance in your IIS 5.0 Web farm

Windows 2000's Network Load Balancing (NLB) is a clustering technology that balances the network traffic of IP-based applications, such as Web, FTP, and VPN applications, across multiple servers. A software-based load-balancing solution available in Win2K Advanced Server and Win2K Datacenter Server, NLB streamlines administration by letting you manage a group of independent servers as one system. Administrators typically use NLB to evenly distribute Web client requests among Web servers, such as in a Microsoft Internet information Services (IIS) 5.0 server farm.

Load balancing is more than just distribution of Web traffic. Now is the time to dispel some common myths about load balancing in general and about NLB in particular. To attack these myths, I want to explore Win2K's NLB in depth to reveal the ease with which you can configure NLB and put this powerful utility into action.

The Benefits of NLB
Load-balanced servers (aka hosts) in an NLB cluster provide two important benefits. First, NLB scales IIS's performance by distributing client requests across multiple hosts within the cluster. As traffic increases, you can add servers (up to a maximum of 32 servers) to a cluster. You can add or remove hosts from a cluster without interrupting services. Second, NLB provides high availability (i.e., continuous service) by detecting server failures within a cluster and automatically repartitioning client traffic among the remaining available servers.

NLB distributes IP traffic to multiple instances of IIS, each running on a host within the cluster. NLB transparently partitions the client (i.e., user) requests among the hosts and lets the clients use one or more "virtual" IP addresses to access the cluster. To the clients, the cluster appears to be one server. Also, server programs aren't aware that they're running in an NLB cluster.

NLB hosts emit periodic "heartbeat" messages so that you can monitor all cluster members. These heartbeat messages impose very low overhead on the network. The software detects host failures within 5 seconds and accomplishes recovery within 10 seconds. If a load-balanced host goes down or if a new host goes online, NLB automatically and transparently redistributes the workload among available cluster hosts. (For more information about NLB, see "Related Articles.")

Dispelling NLB Myths
The performance and features of Win2K's NLB match, and in many cases exceed, the benefits of expensive hardware-based solutions (e.g., solutions from Cisco Systems and Nortel)—at a fraction of the cost. NLB's only real limitation is that a cluster can't have more than 32 servers, but large sites such as Dell (http://www.dell.com) and Microsoft (http://www.microsoft.com) typically use multiple clusters to overcome that limitation. Nevertheless, you'll encounter several pervasive myths about load balancing and about Win2K's NLB in particular:

You need load balancing only if you run a large site. You don't need to be running a huge Web site to justify implementing a load-balancing solution. In many cases, simply adding a second IIS server to create a Web farm can dramatically improve performance.

Win2K NLB doesn't measure up to hardware-based solutions. Some of the world's largest Web farms—http://www.dell.com, TV Guide Online, Microsoft's Web properties (i.e., http://www.microsoft.com, MSN, MSNBC, and the Expedia travel service)—use NLB. In Microsoft's load-balancing tests, which emulate scenarios in which a server farm handles more than 800 million customer requests per day, NLB demonstrated better than 200Mbps throughput. This performance is far superior to that of any hardware solution. Unlike hardware solutions, NLB avoids single points of failure by running in parallel on all of a cluster's hosts (i.e., servers). Most hardware solutions require an extra, underutilized server to avoid a single point of failure. The extra server operates in passive mode until a primary component fails.

NLB is difficult to install, configure, and manage. You don't install NLB; you simply enable and configure it. As you'll see, NLB is extremely easy to put into action and provides excellent control, including the ability to remotely manage—with password protection—the cluster from any point on your network.

NLB Requirements
Win2K AS is compatible with almost all Ethernet and Fiber Distributed Data Interface (FDDI) NICs, so NLB has no specific Hardware Compatibility List (HCL). Also, NLB doesn't require a second NIC for its heartbeat messages (although a second NIC might benefit performance). NLB is installed as a standard networking device driver under Win2K AS or Datacenter and requires static IP addresses for all cluster hosts.

NLB requires less than 1MB of disk space on each cluster server. If you use NLB's default parameters, the software consumes between 250KB and 4MB of RAM during operation, depending on the network load. You can modify these parameters to let NLB use as much as 15MB of RAM.

For optimum performance, you can install a second NIC on each NLB host. In this recommended configuration, one NIC carries all network traffic that results from client requests and the other NIC handles the network traffic between the server and the NLB software. Running NLB in a cluster in which hosts have only one NIC can be complicated. If you don't run in multicast mode, performance will suffer. Multicast mode instructs NLB to add a multicast media access control (MAC) address to the cluster adapters on all cluster hosts. If you run NLB with single NICs in multicast mode, you won't experience any shortcomings, but multicast mode requires special configurations in some routers. (For example, Cisco Systems' routers don't support the resolution of unicast IP addresses to multicast MAC addresses.)

Configuring NLB
When you install Win2K AS or Datacenter, you automatically install NLB. However, NLB isn't enabled by default. To enable NLB, open the Control Panel Networking and Dial-Up Connections applet, then open the Properties dialog box for the Local Area Connection on which you plan to install NLB. (Alternatively, you can click Start, Settings, Network and Dial-up Connections, choose the Local Area Connection, and click Properties.) In the Components checked are used by this connection section, select Network Load Balancing, as Figure 1, page 42, shows.

Click Properties to display the Network Load Balancing Properties dialog box, which contains three tabs: Cluster Parameters, Host Parameters, and Port Rules, as Figure 2 shows. On the Cluster Parameters tab, enter the Primary IP address (i.e., the NLB cluster's virtual IP—VIP—address). This IP address must be valid for your subnet (and obviously unique, except for other members of the cluster), and you must set it identically for all cluster hosts. The Subnet mask field resolves automatically. The Full Internet name is the primary name that you use for the NLB cluster, and you must set it identically for all cluster hosts. Your name-resolution system (e.g., DNS, WINS, HOSTS file) must be able to resolve this name to the cluster's primary IP address. For example, I have Win2K DNS configured to resolve cluster.tim.com to 192.168.1.100, which is my cluster's VIP address. However, if you're setting up NLB for the first time for testing purposes, you don't need to resolve the name to the address. As I demonstrate later in the "Putting NLB into Action" section, you can just use the provided test address (i.e., http://192.168.1.100/nlbtest.asp) of the cluster. Enabling Multicast support is essentially mandatory for single-NIC servers in an NLB cluster. I selected this option because I performed my tests on servers that have only one NIC each.

The final step on the Cluster Parameters tab is to decide whether to select the Remote control check box. When you enable remote control, you immediately receive the warning Please consult on-line help for security implications of using remote control commands. For security reasons, you must use a firewall to shield the NLB UDP control ports (i.e., the ports that receive remote-control commands) from external intrusion. By default, the control ports are ports 1717 and 2504 at the NLB cluster's IP address. I selected remote control for my test environment, which is protected by a simple hardware-based firewall solution from Linksys.

Now, move to the Host Parameters tab, which Figure 3 shows. For each host in the cluster, you must specify a unique host priority ID. The Priority (Unique host ID) field specifies the server order in which NLB tries to allocate traffic if a host goes offline. In my test environment, I simply set the IDs of my three hosts to 1, 2, and 3. The Dedicated IP address field and its associated Subnet mask field let you send some traffic to a specific host in the cluster. For example, you can enable Telnet access to one host in the cluster. These fields are optional; you'll most likely use the host's actual IP address (rather than its VIP address as a member of the NLB cluster).

Finally, go to the Port Rules tab, which Figure 4 shows. Port rules let you control the various types of TCP/IP traffic. An example of a port rule is disabling UDP on a certain range of ports. The number and types of port rules must be identical on each server in a cluster. Other than the default rule, which the software automatically configures, port rules are optional. (You can also change the default rule.) NLB gives you three Filtering modes—Multiple hosts, Single host, Disabled—with which to direct network traffic to specific ports on the VIP address.

The Multiple hosts mode. The Multiple hosts mode distributes network traffic over the hosts in the NLB cluster. You can specify a load weight to a specific host—a compelling feature if you have, for example, a beefy Web server (superior to the cluster's other machines) that services only HTTP on port 80. (By default, the load is equally distributed among the cluster's hosts). Additionally, the Multiple hosts filtering mode offers the capability to enable a server's affinity. If you select Single affinity, NLB uses one host to serve all requests from a specific client (after that client is load-balanced to a host within the cluster). In other words, the client sticks to the Web server, for example, on which his or her IIS session resides. The Class C affinity ensures that a client's proxy server doesn't confuse NLB by appearing to be different computers. You'll need to consult with your Web developers about your client affinity requirements. (Among other considerations, well-written Web applications don't require clients to establish and maintain a session on a single Web server, but HTTP over Secure Sockets Layer—HTTPS—does.) (.NET will automatically address session state with its ability to identify a session server behind the firewall; therefore, the need to be able to specify single affinity will be unnecessary.) I chose None because my NLB test environment was a simple Web page that doesn't require session state.

The Single host mode. The Single host mode redirects network traffic intended for an associated range of ports to a specific host in the NLB cluster. It works in conjunction with the Handling priority parameter to determine which host handles the ports' traffic in the event of a failure.

The Disabled mode. The Disabled mode blocks all network traffic on a range of ports. You can use this mode to build a basic firewall (most likely supplemental to a full-featured firewall) to prevent network access to specific ports.

On the Local Area Connection Properties page, you must configure TCP/IP for NLB. The following description configures NLB on one NIC, but configuration on multiple NICs is straightforward. Click Internet Protocol (TCP/IP), then click Properties. In the IP Address field, type the address that you entered as the Dedicated IP address on the Network Load Balancing Properties dialog box's Host Parameters tab. This address is probably already set because it's the machine's static IP address. When you press the Tab key, the subnet mask will resolve automatically. Click Advanced, then click Add. Enter the NLB cluster IP address in the IP address field. When you press Tab, the subnet mask will resolve automatically.

Putting NLB into Action
To help you test your load-balancing capability, I've written a simple Active Server Pages (ASP) file that introduces load on a server by iterating the ASP request object's SERVERVARIABLES collection. The SERVERVARIABLES collection is a list of configuration parameters and settings specific to the Web server upon which you iterate it. For example, on an IIS 5.0 Web server, SERVER_SOFTWARE returns "Microsoft-IIS/5.0." (You can download the nlbtest.asp file from the Windows 2000 Magazine Web site at http://www.win2000mag.com. Enter InstantDoc ID 21838.) The ASP file also displays the name of the server on which you execute it.

I've propagated the nlbtest.asp file to each of the three hosts in my cluster. To do so in your environment, go to a machine—preferably one outside the cluster. Start multiple instances of a Web browser and in each one, navigate to the nlbtest.asp page at the NLB cluster's IP address. In my case, the page's location is http://192.168.1.100/nlbtest.asp. NLB will send each subsequent browser request to a different host in the cluster, thereby balancing the load. You can confirm that NLB has load-balanced each request because NLB will output to each browser the specific name of each server on which it has run. As Figure 5 shows, the server name is different in all three browser instances.

Only the Beginning
This article barely scratches the surface of NLB's configurations and features. NLB doesn't only provide scalability and high availability to TCP/IP protocol services such as IIS. Enterprisewide TCP/IP services such as Lightweight Directory Access Protocol (LDAP), Win2K Server Terminal Services, proxy servers, VPNs, and streaming media services also benefit greatly from NLB. One of my enterprise clients even uses NLB to distribute the printing load among Win2K servers dedicated to hosting printers.