In-Depth

Share the Load

Network Load Balancing in Windows 2000 makes your servers more efficient and your network faster. Here’s a quick-study on how to set it up.

• By J. Peter Bruzzese
• 01/01/2002

Network Load Balancing is one of two types of clustering services that Microsoft provides within Win2K. NLB can balance incoming IP traffic across anywhere from two to 32 nodes. Some of the most common uses of this type of cluster include Web servers, media servers and terminal service servers.

To load balance in times past, when cost was a factor, you’d simply configure your DNS with a round-robin strategy, which makes each Web server part of a pool. The DNS server would send each request for a particular site to a different Web server in the pool, thus load balancing the requests evenly. This is a great way to save some money, but it doesn’t provide the same availability that NLB provides because of DNS’ static nature. If a Web server in the pool fails, the DNS server will continue to send requests to the failed server until it’s removed.

Getting Your Hands Dirty
Let’s walk through a typical set-up of an NLB cluster. To start, you need at least two computers with Win2K Advanced Server (including Service Pack 2) installed. In a real environment, it’s unnecessary to include a domain controller (DC). In fact, it will throw off your traffic tests because a DC will be handling additional requests and, thus, taxing your system to begin with. However, in my practice environment, I’ve set up one of the two servers as a DC with DNS and made the second server a member server. Ensure that these systems are networked together using a hub. A crossover cable may work in our two-server scenario, but you don’t want to get comfortable with using a crossover cable between your cluster adapters. Apparently, this causes failures in systems trying to access the cluster because the NLB cluster servers need to be able to receive traffic directly in order to load balance the TCP services. Using a hub will also allow greater flexibility if you decide to expand upon the simple cluster and start adding other servers or clients to the mix. For the sake of our testing NLB, you don’t need to put additional NIC cards in your machines, although—in a real-world implementation—it would be best to segment your cluster traffic through its own card.

Once your servers are working together, go into your Local Area Connection properties by selecting Start | Settings | Network | Dial-up Connections. Right-click your Local Area Connection and select Properties. You’ll see the options shown in Figure 1. Notice that Network Load Balancing is already installed but not selected by default. (If you don’t see the NLB service, select Install, choose it from Services and add it.)

Figure 1. NLB is installed by default but disabled, so you’ll have to check the box.

Put a check in the NLB box and select Properties. This will take you to the first of three configuration tabs needed to establish the first node of your cluster. Figure 2 shows that quite a bit of information is needed.

Figure 2. The Cluster Parameters tab of NLB. This is where you do a lot of the heavy lifting for your configuration.

Notice that the Properties sheet requests a Primary IP Address, which I entered as 172.19.178.200. This is a virtual address. My actual adapter has the address 172.19.178.210, but the primary IP address is really the address of the cluster. The subnet mask is needed as well for the cluster. The Full Internet name is the Internet name for the cluster that will be accessed by the clients; for my test, I chose www.nlb.com. We’re going to leave the multicast support disabled for our practice cluster. (Microsoft recommends you use the multicast option for single NIC implementations of NLB; however, in a testing environment we worked with it both ways without a problem. You may want to remember this when troubleshooting your cluster.) The remote password allows you to associate a password for any remote management calls to the cluster. In that case, you would then want to enable Remote Control.

Next is the Host Parameters tab shown in Figure 3. Notice here that only four options are provided. You must first supply a Priority or Unique host ID. You can choose from one to 32, and each node of the cluster would be different. We chose 1 on this node and 2 on our second server. You can activate the cluster here and then provide the IP address and subnet mask of the NIC that will be handling traffic other than cluster traffic. This is necessary in the case of multiple cards or single cards with multiple addresses, so it’s important to provide the correct address; in our case, with a single NIC, the IP address of the card will suffice. Notice again that the IP address isn’t the same as the cluster’s virtual IP address.

Figure 3. The Host Parameters tab of NLB. Make sure each server in your cluster has a different host ID.

The final tab on the Properties sheet is Port Rules. As you can see from Figure 4, the Port Rules can get complex. Without going through each detail, there are a few settings important to us.

Figure 4. The Port Rules tab lets you configure port and protocol filters.

The port ranges can be left in the default settings for now and the protocol treaffic left at the default setting of “Both,” but these setting could be configured to maximize your control over the allowed protocols involved with your cluster. These settings allow you a great deal of flexibility for the services you want. You can specify a port number like 21 for FTP and then choose TCP only, so that only FTP traffic through TCP will be allowed, or you can specify UDP only, or both. This gives you any number of options for your cluster.

You can choose from three different filtering modes: Multiple, Single and Disabled. For our site, we’ll leave multiple hosts so the traffic is distributed evenly across all hosts in the cluster. Multiple hosts means that, on this cluster, we’ll have multiple servers that can handle requests. Single host specifies that a single server will handle all requests. Disabled means that regardless of whether the cluster’s active or not, this host won’t handle requests.

You can also choose a client affinity, which ensures that specific client requests are handled by specific cluster hosts. When a request comes in to the NLB service, it needs to know how to handle the balance of traffic, as noted by the various settings. None indicates that NLB doesn’t need to direct multiple requests from the same client to the same host (we want this setting for testing). Single indicates that multiple requests from the same client should be directed to a specific host. Class C directs multiple requests from the same TCP/IP class C range to the same host. This affinity reduces the range of IP addresses by which NLB balances clients and provides the best performance for clusters that serve the Internet.

Setting this to None causes the NLB service to use the next setting, which is Load weight. We’ll leave this to Equal, although we could set percentage ratios that would establish, for example, a 70-30 handling of requests between our two servers. You might do this when one server has greater processing power than the other or one has a heavier load already and you want to ease up on it. To finalize your selections, choose your options in the settings window and select Modify.

Choose OK, and your first cluster host is ready. Then use the same settings on the second server. The only differences will be on the Host Parameters tab, where you’ll need to choose a new unique number (two, in our case) and you’ll need to provide the IP address and subnet mask of this server’s NIC card.

With your two servers configured, there’s one more configuration change to make. In the Advanced Settings for your IP address settings on each of the servers, add the IP address for the cluster as an additional address to the card. The same IP address needs to be added to both servers.

Check it Out
Now your cluster should be in business. But how do you know? You can try Pinging your cluster’s virtual IP address. Alternatively, check your Event Viewer. You should see a message from the WLBS Source that looks like the message in Figure 5. It will be an Event 29, if you need to search for it.

Figure 5. This event is confirmation that load balancing has been properly set up on your network.

To perform a simple test of our load balancing, we created a Web page called home.html. We took the same page, put it on both Web servers, and then pointed off the default Web site toward home.html as the default site. The only change we made to the page was to put “server one” at the top of the page for our first server and “server two” at the top of the version for our second server. We then took a third system as a client machine and used Internet Explorer to connect to our site. The first server that came up for us was server two. To simulate a failed server, you can disable your Local Area Connection within network settings, then refresh the page on your client. (Because the content of the page has already been cached in your Temporary Internet files, you’ll need to delete those files on your client and then refresh the page.) Keep in mind that in a real-world implementation, you’d use the same pages so that users would never know that server two went down.

Want To Do More?
Another way of testing your cluster is by using a command-line utility called “WLBS,” which is a cluster and control utility that comes as part of Win2K Advanced Server. If you go to a command line and type “ wlbs,” you can see that you have a number of options. You can use this command locally or remotely. If you use it remotely, then you would need to provide the password that I specified earlier in the configuration settings.

To do a simple test, just type, “wlbs query.” This will show you that your cluster is functioning.

To see a bit more power behind WLBS, type, “wlbs display.”

There’s a great deal more you can learn about WLBS by going to your Advanced Servers Help and going to the Index tab and typing “ wlbs.exe.” This will show you all of the various command-line options and their purposes.

There are some great tests you can perform at this point. In fact, Microsoft provides a tool for flooding your cluster with requests so that you can see the enhancement that load balsncing provides as you continue to add servers. The tool is called the “Web Application Stress Tool,” and more information can be found at http://msdn.microsoft.com/library/default.asp?
url=/library/enus/dnduwon/html/d5wast_2.asp.