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
- January 01, 2002
You’ve heard the expression, “Two are better than one”? If two are better
than one, 32 are tons better. That’s the concept behind the Windows 2000
service that allows you to balance your workload across anywhere from
two to 32 machines—Network Load Balancing Service.
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
|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.
|Network Load Balancing shouldn’t be confused
with the newer Component Load Balancing (CLB), which a
feature of Microsoft Application Center 2000. A COM+ application
cluster will handle load balancing for applications that
support COM+ by sending application requests to the node
with the lowest processing load. If you’re interested
in pursuing CLB, Microsoft provides some great articles
on the architecture being used and a step-by-step for
implementation. One way of establishing CLB services is
to start with an NLB 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
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
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
|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?