The New WLBS

Installing NLB in IIS 6.0 and IIS 5.0 clusters

In "Load Balancing Down on the Web Farm," February 2002, InstantDoc ID 23572, I explored the ins and outs of Windows NT Load Balancing Service (WLBS) 2.0, which adds fault tolerance for IIS 4.0 installations. WLBS's successor—Network Load Balancing (NLB)—is currently available only with IIS 5.0 on Windows 2000 Advanced Server or Win2K Datacenter Server. However, Microsoft will also offer NLB with the new "locked-down-for-security" IIS 6.0. I show you how NLB compares with WLBS; then, I show you how to configure both NLB and the TCP/IP stack.

NLB and WLBS
NLB has several improvements over WLBS, most noticeably in the service setup. The software is installed with the OS, so you don't have headaches with network bindings. To get NLB up and running, you simply select the service in the TCP/IP properties; supply the proper addresses, port rules, and priorities; then tune the server's TCP/IP stack for NLB.

If NLB's improved setup runs circles around WLBS, WLBS continues to lead in cost. Table 1 shows some of the initial WLBS and NLB deployment costs. The table shows three OS options—NT 4.0, Enterprise Edition (NTS/E), Win2K Server with Microsoft Application Center 2000 installed, and Win2K AS. All the prices you see in the table are street prices on a per-server basis. You might pay less if you have an existing Microsoft Select, Volume, Open, or Academic agreement.

So, which option should you choose? If you're looking for additional features that Application Center provides, such as COM component object instantiation load balancing and content deployment, then the equivalent pricing steers you toward that OS option. If you don't need those features and you'd rather have the additional processors and memory available to the Web server, consider the Win2K AS option. Similarly, if you already have a server running Win2K and you'd just like to add Application Center to the mix, the Win2K AS option might be better. (Although last month I strongly suggested that you run only like software and like hardware between cluster hosts for maximum uptime, Microsoft contends that you can have a mix of WLBS and NLB servers in the same cluster. The examples I use here demonstrate that the version of NLB included with Windows .NET Enterprise Server is compatible with the version of NLB that Application Center provides.) At the time of this writing, the latest version of NLB was in .NET Enterprise Server, build 3505.

Here's one more purchase factor to consider: If you're going to authenticate Web users, Win2K requires an Internet Connector License. This requirement is likely to continue when .NET Enterprise Server appears. This license costs about $1500 beyond the prices you see in Table 1. The NT 4.0 option doesn't require such a license. (For more information about Internet Connector Licenses, see the Microsoft article "Internet Connector License Types for Windows 2000" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q272235.)

NLB Configuration Options
NLB supports several different configurations, such as support for one or more network adapters. The service can also support 2 to 32 hosts in the cluster, each with multiple NICs. (For more information about NLB, see Tim Huckaby's Windows 2000 Magazine article "The Tao of Network Load Balancing," September 2001, InstantDoc ID 21838.) To decide which configuration option is right for you, ask yourself this question: Do you expect heavy network traffic on the virtual IP interface? By heavy, I mean that the expected NIC traffic on the virtual IP (VIP) adapter would be heavy enough to potentially interfere with usual cluster heartbeat communications. (For more information about cluster heartbeat communications, see "Load Balancing Down on the Web Farm.") You might also have some security requirements that prohibit you from having cluster communications on the same interface. If the answer to the question is yes, think about setting up NLB with two NICs rather than one. If the answer is no, you should be completely satisfied with a single-NIC installation of NLBS. Last month, I showed you how to configure WLBS for dual NICs; this time, I show you the single-NIC installation of NLB. For information about dual-NIC NLB installation, see the Web-exclusive sidebar "Installing NLB on a Dual-NIC System," which is available at http://www.windowswebsolutions.com, InstantDoc ID 23885.

In addition to deciding how many NICs to use, you also need to decide which load-balancing mode to use. Like WLBS, NLB has two modes—Unicast and Multicast. Deciding between these modes sounds rather trivial, but you need to choose the best option for your network. In single-NIC installations, the default mode—Unicast—uses the derived media access control (MAC) address for all cluster-host and dedicated-host communications. The Multicast mode uses both the derived MAC address and the dedicated MAC address on the same NIC. Not all routers and switches support the Multicast feature. Likewise, network adapters that use teaming also have problems with the Multicast mode.

If the cluster hosts need to be able to communicate among themselves or you expect cluster traffic to be high, you might need multiple NICs. The default Unicast mode in multiple-NIC configurations is compatible with most routers and lets you separate the cluster traffic from the dedicated cluster-host traffic. Keep in mind that all hosts in an NLB cluster see the same traffic regardless of whether you have 2 hosts or 32 hosts in the cluster. An algorithm that every server in the cluster runs helps decide which server responds to the client request.

Setting Up NLB
Now that you know the NLB options and versions, let's install the service. Win2K AS and Datacenter have almost identical screens and installation instructions. I performed my setup on a .NET Enterprise Server machine. You'll be able to configure and change the private and virtual interfaces without having to reboot your servers. To demonstrate the heterogeneous design of WLBS and NLB, the second machine in my cluster runs Win2K Server Service Pack 2 (SP2) and Application Center. Figure 1 shows this cluster's setup.

First, verify that NLB is installed on your server by right-clicking My Network Places, then selecting Properties. Right-click Local Area Connection, then select Properties. NLB should appear in the Components checked are used by this connection list. Now, follow the appropriate instructions for one or two NICs to set up NLB for the first time.

In the Local Area Connection Properties dialog box, select the Network Load Balancing Service check box, then click Properties. In the Network Load Balancing Properties dialog box, you configure settings for the cluster, the host, and the ports in use.

Configuring cluster parameters. To begin NLB configuration, click the Cluster Parameters tab, which Figure 2, page 9, shows. In the Cluster IP configuration section, enter the VIP address for the cluster. As you enter the IP address, notice that the network address changes with each octet you enter. This network address is really a MAC address that's permanently assigned to a NIC. (The NLB load-balancing mode that you select later determines what you do with this address.) Each octet is converted to its hexadecimal equivalent on the fly, creating that unique network MAC address. This uniqueness is important in a switched environment because some switches don't work well when more than one switched port claims to own the same network address. Some switches let you disable the system's ability to learn network MAC addresses.

Next, enter the appropriate subnet mask for the VIP address. (You'll supply the default gateway information later.) Then, in the Full Internet name text box, enter the cluster's Fully Qualified Domain Name (FQDN—e.g., cluster.domain.com). Note that for a production server, you'll need to perform name resolution (e.g., DNS) on this FQDN before you put NLB into production.

Now you need to decide which cluster operation mode to use—Unicast or Multicast. (Note that the first network adapter is always the cluster adapter.) Notice the IGMP multicast option. This option is useful only if you're using Multicast mode and NLB traffic is overwhelming your network switch.

If you want to let administrators use the NLB command-line tools to remotely administer the cluster, select the Allow remote control check box and provide a password. Enabling this option lets you perform simple administrative tasks for your NLB cluster, such as starting and stopping the cluster, removing a host from the cluster for maintenance, and displaying cluster diagnostics. Using this remote command-line option doesn't preclude your using Win2K Server Terminal Services to remotely administer the cluster.

Configuring host parameters. In the Network Load Balancing Properties dialog box, click the Host Parameters tab, which Figure 3, page 9, shows. First, configure the cluster host's Priority. This value determines the host's priority in the cluster. The lower the number, the more requests a cluster member tends to fulfill for a client. The default value is 1. If you plan to add additional hosts to a cluster, you'll need to increment those values accordingly. Next, enter the host adapter's dedicated IP address and subnet mask. Finally, you need to decide whether to set the initial cluster state to active. Selecting the Set initial host state to active check box tells NLB to insert the host into the cluster immediately.

Configuring port rules. Switch to the Port Rules tab, which Figure 4 shows. This tab lets you tune the load-balancing algorithm. You can filter requests based on ports, protocols, and client IP addresses. The default filter is for balancing any request for any ports within the range of 0 to 65,535 for both TCP- and UDP-based requests.

The filtering mode also influences which client answers a request. One option is to use multiple hosts and balance client requests among all cluster hosts. Another option is to use the Single mode to force all client requests to a specific cluster host until that host fails. On failure, the remaining hosts in the cluster use their Priority value to determine which cluster host assumes the traffic from the failed host. Another option is to tell the cluster not to service traffic for certain ports and protocols.

In the Multiple mode, affinity options help cluster hosts decide what traffic they should answer. (For more information about affinity, see "Load Balancing Down on the Web Farm.") The Class C option directs traffic from the same Class C address space to the same cluster host. Single mode ensures that all traffic from the same IP address reaches the same cluster host. If affinity is important to you, consider the Single option first. I use Single mode on my servers so that I can use cookies.

When you've made the affinity and port-rule changes, click OK to save your changes. When you receive a warning about adding the new TCP/IP addresses in the TCP/IP configuration, click OK to acknowledge the warning. Now that you've configured NLB, you need to tell the TCP/IP stack what's going on. After the adapters complete the new bindings, the IP Address Properties dialog box will appear. Supply the same configuration information for the VIP address here that you supplied on the Cluster Parameters tab. The static IP address for the first adapter should always be the virtual (i.e., cluster) IP address.

Configuring the TCP/IP Stack
After you've completed the basic TCP/IP information, you need to tell the TCP/IP stack about the host's private, dedicated IP address. In the Internet Protocol (TCP/IP) Properties dialog box, click Advanced. In the Advanced TCP/IP Settings dialog box, enter the private, dedicated IP address and its subnet mask. Don't supply the default gateway for your internal network as an additional default gateway: Using multiple default gateways can create a routing nightmare for your network teams, and providing the internal default gateway could make it easier for intruders to get to your intranet. Instead, you can add the route for the internal network as a static route. The desired result is to leave the default route pointing to the untrusted network. With the stack configured, you've completed the initial NLB configuration.

After the TCP/IP stack has reconfigured itself, you can verify that NLB is installed and working properly. To do so, you can use NLB's command-line operation, which is the same as WLBS's tool. Open a command prompt, then type

C:> wlbs query

to return the status of the cluster, as known to the current (i.e., local) host. Figure 5 shows typical output from the Wlbs Query command. Other important WLBS and NLB command-line commands include Stop, Start, and Display. You can always type

wlbs

at the command line to get a description of each command and its syntax.

Other Load-Balancing Options
Now that you have a basic understanding of WLBS and NLB, let me throw a wrench in the works. Other load-balancing options exist besides software clustering. You can also use hardware options that take more than just the TCP/IP stack into account.

For example, Cisco System's content-switching solutions (formerly the ArrowPoint product line) and F5 Networks' BIG-IP Controller product line are two products with which I've had some experience. Both products work at the higher-level layers (i.e., from the Network Layer, layer 4, and up) to ensure a balanced solution. The products can also detect unresponsive Web services and take action—a feat that WLBS and NLB currently can't provide. Cisco's solutions and BIG-IP Controller also handle cookies more smoothly. The costs for these products might seem steep initially, but when you consider that you need only a regular server license rather than Microsoft's costly Win2K AS license for each server in your cluster, the price becomes more attractive.

Your specific implementation will determine what kind of load-balancing solution you can run—hardware or software. If you decide on a software solution, you can put together a reliable and effective load-balancing solution by using the basic Microsoft clustering software—NLB and WLBS—to maximize the uptime of your IIS servers.