SQL Server Magazine

The Network Load Balancing (NLB) feature in Windows 2000 Advanced Server and Win2K Datacenter Server is a highly integrated version of the Windows NT Load Balancing Service (WLBS). NLB lets as many as 32 servers share the load of IP-based applications, such as Web, FTP, and VPN applications. NLB also lets you add and remove servers from an NLB cluster on the fly, and the feature then redistributes client workload among active members of the cluster. (For more information about load balancing IP-based applications, see Tao Zhou, "Web Server Load Balancers," April 2000.)

NLB is compatible with NT 4.0's WLBS but has several important differences. Win2K implements NLB as a driver between the NIC driver and the TCP/IP stack, and you activate NLB by selecting a check box at My Network Places, Properties, LAN Connection Properties on each server in the NLB cluster. (In contrast, NT 4.0 implements WLBS as a virtual NIC.) In addition, NLB works as soon as you configure it and doesn't require a reboot.

NLB uses a media access control (MAC) address-translation model to distribute an IP workload among cluster members. NLB uses a cluster MAC address in place of the preassigned MAC addresses that all NICs have. An Ethernet NIC driver operating at the Open System Interconnection (OSI) model's Layer 2 (i.e., the data-link layer) listens for its MAC address, forwards its packets up the protocol stack, and ignores other packets.

In Unicast mode, which disables network traffic between clustered hosts, NLB converts the cluster's Virtual IP (VIP) address, which you must specify as the same for all servers in the cluster, to a MAC address. NLB then replaces each server's MAC address with this new cluster MAC address. All servers in the cluster use the same MAC address, so every server receives and passes up the TCP/IP protocol stack every packet received at the cluster's IP address.

The next stop up the TCP/IP protocol stack from the NIC driver is the NLB driver, which uses a hashing algorithm to decide which server in the cluster will accept and process the packet. The NLB driver inspects the sender's IP address and the port to which the packet is addressed. Then, the NLB driver takes into account port rules and which servers in the cluster are active for the port rules. The NLB driver decides whether to send the packet up the TCP/IP stack to the application on the driver's server or to ignore the packet because another server in the cluster will accept it.

NLB's Architectural Limitations
The load-balancing process requires the NLB administrator to set up the server system in a specific way. The cluster's VIP address applies to all servers in the cluster, so all servers must be on the same IP subnet. Every server in a cluster needs to receive all network packets that the cluster receives, so all servers must be part of the same collision domain (i.e., servers need to connect to the same Ethernet hub) or must connect to a switch that will broadcast all packets to all ports on the switch. To force the switch to broadcast all packets to all ports, you need to configure NLB to prevent the switch from learning the cluster's MAC address.

The TCP/IP protocol stack intercepts packets addressed to a MAC address on the server that sends the packets; thus, the protocol stack doesn't send those packets to the network. NLB's Unicast mode requires that each server in the NLB cluster have two network adapters—a cluster adapter for load-balanced application traffic and an adapter for server-specific intracluster traffic. The second adapter's unique MAC address enables traffic between cluster members.

A server can't be a member of an NLB cluster and a server cluster at the same time. (Win2K server clusters support application failover for cluster-aware applications running on servers that share a common storage system.) Token-Ring networks don't support NLB.

NLB doesn't monitor applications to make sure they're running. At 1-second intervals, each server in an NLB cluster broadcasts a heartbeat message through the cluster adapter that the other servers in the cluster monitor. As long as a server broadcasts its heartbeat message, the server remains part of the cluster and must process its share of the workload—even if the application (e.g., Microsoft IIS) that is processing the packet fails. You need to use a separate application-monitoring tool to detect whether a load-balanced application has failed. (For information about using Perl scripts to monitor Web applications, see Curt Aubley and Troy Landry, "Monitoring Win2K Web Site Performance and Availability," http://www.win2000mag.com/, InstantDoc ID 8857.)

Configuring and Testing NLB
Win2K AS and Datacenter install NLB when you install a LAN connection. Understanding how NLB works and planning a network configuration to support NLB are the most difficult parts of NLB's setup process. After you set up the physical network configuration and supporting DNS (and WINS, if needed) entries, you can enable NLB for a NIC and configure each server in your cluster.

To test NLB, I used four Hewlett-Packard (HP) NetServer LH 6000 systems. Each system had six 550MHz Pentium III processors with 2MB of L2 cache and 1GB of SDRAM. After installing Win2K AS on each server, I copied to each server the Web application I had selected for testing. Each server had two HP 10/100 NICs, and I picked the first NIC (i.e., Local Area Connection) to connect to a segment of the Windows 2000 Magazine Lab's benchmark network and to serve as the load-balanced cluster adapter. I connected the second NIC in each server (i.e., Local Area Connection 2) to a second network segment.

To test NLB's Unicast mode, I selected the Network Load Balancing check box for my Local Area Connection NIC, then opened the Network Load Balancing Properties page (which you reach from LAN Connection Properties) and supplied the information that NLB needs to operate. The NLB Properties page has three tabs—Cluster Parameters, Host Parameters, and Port Rules. The Cluster Parameters tab, which Figure 1 shows, lets you identify the cluster and operating mode. The Host Parameters tab, which Figure 2 shows, lets you specify server-specific information. The Port Rules tab, which Figure 3, page 130, shows, lets you use a TCP or UDP port number to specify the application services that NLB will load-balance.

On the Cluster Parameters tab, I entered the IP address and fully qualified DNS name for the cluster. Application users use the cluster address and name to access a load-balanced application, so you need to enter the same address and name for each server in the NLB cluster. The Cluster Parameters tab refers to the IP address as the Primary IP address, but NLB users also refer to the address as the VIP address. To let users address the cluster by name, you need to create a DNS host entry for the cluster name and VIP. The Cluster Parameters tab also lets you enable multicast mode and remote control support.

On each server's Host Parameters tab, I entered a dedicated IP address and a unique host ID. NLB uses the unique host ID to prioritize servers in the cluster. The active server that has the highest priority (i.e., lowest number) takes responsibility for IP traffic that isn't load-balanced (i.e., IP traffic traveling to ports that port rules don't define). You can use the dedicated IP address to access individual servers in the cluster from nonclustered systems.

On the Port Rules tab, you define which IP applications NLB will load-balance. TCP and UDP port numbers direct packets to a particular application on a server. For example, Web servers usually listen for packets addressed to TCP port 80. For NLB to work properly, you need to configure every server in the cluster to load-balance the same set of applications. To configure NLB, you can use settings on the Port Rules tab. In my initial tests, I left the default port rule in place, balancing ports 0 to 65535 for TCP and UDP protocols with single IP address-based affinity.

   Prev. page   [1] 2     next page