As soon as you click OK on the Network Load Balancing Properties page, NLB begins converging the cluster, a process in which a server advertises its presence and configuration to other cluster members and all members agree how to share the load. To complete the server's NLB configuration, you add the VIP address as a second IP address under the Advanced section of TCP/IP properties for the load-balanced LAN connection.
To test load balancing, I installed an Active Server Pages (ASP)-based Web application to run from each of three clustered NetServer LH 6000 Web servers, and I used a Compaq ProLiant ML530 server to hold the applications' Microsoft SQL Server databases. I used Quest Software's Benchmark Factory to simulate loads from 16 client systems. My tests demonstrated that NLB allocated the workload among the three servers, but not equally. The disparity among server workloads happened because I configured NLB for single affinity and all traffic originated from only 16 computers, all of which were on one Class C network. When I set Affinity to None, the workload became uniform across cluster members.
Configuring Multicast Mode
NLB's multicast mode allows network traffic between clustered hosts. Multicast mode leaves the NIC's original MAC address in place and assigns a multicast MAC address for cluster traffic. Address Resolution Protocol (ARP) resolves the cluster adapter's dedicated IP address to the NIC's original MAC address and resolves the cluster's VIP to the multicast MAC address. For the ARP resolution process to work properly, the router upstream from the cluster must resolve the cluster IP address to the cluster's multicast MAC address.
Cisco routers that find a non-multicast IP address fail to cache the multicast MAC address. To work around this problem, you can add a static entry to the router's ARP cache, mapping the cluster's VIP address to the cluster's multicast MAC address. According to Microsoft documentation, multicast mode is NLB's preferred operation mode. However, because of the problem with Cisco routers, multicast isn't NLB's default operation mode.
To reconfigure the cluster from unicast mode to multicast mode, select the Multicast support check box on the Cluster Parameters tab of each cluster host and reboot the cluster servers. When I reconfigured the first server cluster, a "duplicate IP address" message informed me that the new multicast MAC address for the cluster's VIP conflicted with the unicast MAC address still in place on the other servers in the cluster. Shutting down and rebooting all the servers in the cluster solved the problem.
Load-Balanced Applications
NLB's Port Rules tab offers you several options (e.g., Filtering mode, Affinity) to configure load balancing for a particular application. Filtering mode determines whether NLB will allocate an application workload to multiple hosts or one host. When you select Multiple hosts filtering, NLB allocates application traffic among all the servers in the cluster in which the rule is active.
To override the default equal distribution of the workload and cause NLB to send more work to specified servers, configure the Load weight option on the Port Rules tab. NLB will sum the load weight for all active servers and allocate the workload in direct proportion to each server's share of the sum. For example, if you distribute a workload between two servers, you could set the first server's load weight to 50 and the second server's load weight to 100, and NLB would send one-third of the workload to the first server and two-thirds of the workload to the second server.
When you load-balance an application among multiple hosts, Affinity causes NLB to send all traffic from one IP address (Single Affinity) or from any address in the same Class C IP address space (Class C Affinity) to the same cluster host. These affinity options let one server track Web session details. Affinity's other setting, None, causes NLB to use the source IP address and the TCP or UDP port number to decide which cluster host will accept the packet.
Single-host filtering mode causes NLB to send all application traffic to one cluster member, regardless of where the application request originated. When configuring single-host filtering, you need to use the Handling priority option to assign each cluster server a unique priority for the port rule. Application traffic goes to the highest-priority server in the cluster in which the port rule is active.
Disabling a port rule on a load-balanced server causes NLB to reallocate application traffic to other active servers in the cluster. NLB rebalances multiple-host rules among remaining cluster members and directs single-host rules to the next-highest priority server in the cluster for that port rule. To disable a port rule on a server, open the Port Rules tab, select the port rule, select Disabled, and click Modify.
NLB can load-balance a variety of IP-based functions, including printing and read-only file serving, which use TCP and UDP port 139. These applications rely on NetBIOS access to the server, so the setup requires special considerations. Because the NetBIOS over TCP/IP (NetBT) protocol binds only to the first IP address on a NIC, the cluster VIP address must be the first (or only) address that you list in the TCP/IP configuration parameters for the cluster NIC. In this configuration, typical Server Message Block (SMB) communication through the cluster NIC to individual cluster servers is impossible, even in multicast mode. You need to configure another NIC with a unique IP address that will also bind to NetBT and provide a path for SMB traffic to reach individual servers in the cluster.
The cluster name isn't a NetBIOS name, and cluster servers neither register the cluster name with WINS nor respond to NetBIOS name resolution requests for the cluster name. Thus, client systems that need to access the cluster by a NetBIOS name must have another means to resolve a NetBIOS cluster name to the cluster's VIP. Win2K clients must use the cluster's VIP address to access NetBT-based applications because an additional security mechanism in Win2K compares the endpoint server's name to the NetBIOS name in the connection and rejects the connection when the names are different.
Remote Administration
The wlbs.exe utility and its subcommands let an administrator locally or remotely control NLB hosts and clusters. Because NLB doesn't monitor applications, you need to use other tools to monitor load-balanced applications and wlbs.exe when an application fails. If you're hosting multiple IP-based applications and only one application fails, wlbs.exe lets you use the Disable subcommand to disable the port rule for the failed application. Then, NLB reallocates the workload among remaining servers.
You can also use wlbs.exe to stop or drain cluster operations on one or all servers in the cluster. The Drain subcommand doesn't allow any new connections to the cluster or the specified cluster member but lets users remain connected so that they can complete their work.
Other wlbs.exe subcommands let you display cluster status information: Query tells you which servers are in the cluster, and Display lists detailed configuration information for one server in the cluster. You can run Display only from the server that you're seeking information about.
Testing Failover
While using Benchmark Factory to generate a workload to the cluster from one simulated user, I simulated failure of a cluster server by using wlbs.exe to remove and re-add one server to the cluster. From a computer connected to the clustered and nonclustered networks, I used Win2K's Performance Monitor to watch CPU utilization at each server in the cluster.
I set the default port rule to use single affinity. Single affinity causes NLB to allocate traffic from a particular IP address to the same server as long as the same set of servers is balancing the application's workload. When you add or remove servers from the cluster or disable a port rule at the server, the allocation algorithm might assign a different server to process requests from a particular IP address. My system's workload originated from one computer, so Performance Monitor showed that only one member of the NLB cluster was working. When I used wlbs.exe to stop that cluster member, the workload shifted to a different member of the cluster. After I used wlbs.exe to restart the stopped cluster member, it resumed processing the workload.
I set Affinity to None and performed another test. One computer generated a workload that NLB allocated among all cluster members. After I stopped one cluster member, that member's workload rotated among remaining cluster members. After I restarted the cluster member, workload distribution returned to its original pattern.
Understanding NLB Is Crucial
NLB works well, is easy to configure, and provides two modes for client-to-server affinity to preserve user sessions during a load-balanced application session. However, to avoid mistakes in your configuration, you need to understand how NLB works before you begin to use it. Learn how packets flow and how NLB processes application workloads, and you'll discover that NLB can help you create a scalable, fault-tolerant server system to support your applications.