Network Load Balancing (NLB)

 <  Day Day Up  >  

Before we discuss the changes to NLB for Windows Server 2003, an oddity in Microsoft's support for NLB needs to be pointed out. Microsoft does not publish an HCL or catalog for NLB. Microsoft assumes that you are using server class components, because some workstation/client class components have limitations that make them unsuited for NLB. It is unlikely you will ever run into problems on your production systems, but if you have a test environment with less than

top-of-the line components, you could run into unexpected problems. For example, there are some low-end NICs that lack the necessary functionality to fully work with NLB. Yet, there are no easy methods to troubleshooting such a problem. Your support provider should have access to an unsupported tool that can detect NICs that do not have the proper functionality.

New Management UI

Windows Server 2003 introduces a management GUI for NLB cluster. The GUI can be used to create and maintain clusters.

note

The GUI can sometimes get confused . When you get suspicious of the result, it's often best to kill the GUI and restart it to verify the display.


The GUI program is called NLBMGR.EXE, and a shortcut is present in the Administrative Tools menu. Care must be exercised when using both the GUI and the CLI to manage a cluster. NLBMGR.EXE does not refresh its cluster view, so if you perform a change via the CLI while it is active, it will have a stale view and will get confused. Clusters can be managed using both interfaces; however, make sure that you use only one interface at a time and whenever you use the CLI, make sure the GUI is not active.

Virtual Cluster

A very common deployment scenario for NLB cluster involves a large cluster with multiple applications sharing the resources. Until Windows Server 2003, such a cluster had a big inconvenience: it had only one VIP (Virtual IP) and one set of port rules. So it was not possible to separately administer the multiple applications. In Windows Server 2003, Microsoft adds the capability to have multiple VIPs assigned to one cluster, and each VIP in turn can have its own port rules and can be started and stopped independently.

note

When using the GUI to configure an NLB cluster, a distinction is made between the first cluster VIP and the additional cluster VIP. However, for application purposes, there are no differences and this is just a GUI oddity.


Because each VIP is actually a separate IP address and port rule, it's possible to have each IP registered under different names in DNS and therefore allow a service provider more discretion in segregating clients . Furthermore, because the port rules are independent, it's possible to tailor the port rule for the application, or even drain and stop load balancing of an application while other applications are unaffected.

Unicast Warning

NLB clusters have been designed from the beginning to use unicast IP addresses. Unfortunately, having multiple machines answer to the same IP unicast address is a misuse of the IP design ”multicast IP addresses were meant for that, but infrastructure limitations greatly diminish their usefulness . At the MAC (Media Access Control) layer, NLB allows use of either unicast or multicast addresses; however, infrastructure limitations also limit the widespread use of multicast MAC addresses. Because of those limitations, NLB has to accommodate unicast IP addresses and unicast MAC addresses. However, when doing so, it is possible to get into a situation where NLB cluster members cannot talk to one another. Because NLB cannot predict the future configuration changes, NLBMGR displays a worrisome message every time it is started on an NLB machine with all its NICs bound to NLB (see Figure 13.2). The message does not mean that the current setup has the problem, but rather that the current setup could have the problem if unicast MAC addresses are used.

Figure 13.2. Unicast warning.


IGMP Support

In an effort to improve the usefulness of multicast MAC addresses, Windows Server 2003 NLB has been modified to support IGMP (Internet Group Management Protocol) and attempt to solve the switch-flooding problem. Switches are L2 (Layer-2) snooping intelligent devices and associate a MAC address for a server with the port on which it is connected. Switches monitor the traffic passing through their ports to determine what MAC addresses are associated with a port, and then only forward traffic destined for that MAC address via that port. However, when a switch notices a multicast MAC address, it forwards the packets destined to that multicast address to all ports. This, in turn, defeats the purpose of a switch and potentially floods the downstream NICs with the traffic destined for the NLB hosts . Because NLB clusters are meant to service high volumes of requests , the amount of traffic that is forwarded to those nonNLB downstream nodes can be quite large and overwhelming. Hence, the name "switch flooding." Note that switch flooding does not occur if the NLB cluster members are the only nodes plugged into a switch or if using a nonintelligent device such as a hub.

IGMP is an IP specification used for communication between a set of computers and an upstream switch for the purpose of forming multicast groups. After the switch knows what ports to associate with a multicast group, it doesn't have to forward the multicast messages to other ports, and that prevents the flooding.

With the addition of IGMP support, NLB now also generates a multicast IP address to associate with the multicast MAC address. The MAC address used by NLB can be obtained using the NLB IP2MAC command:

 E:\>nlb ip2mac 157.54.160.55 WLBS Cluster Control Utility V2.4 (c) 1997-2002 Microsoft Corporation. Cluster:                 157.54.160.55 Unicast MAC:             02-bf-9d-36-a0-37 Multicast MAC:           03-bf-9d-36-a0-37 IGMP Multicast MAC:      01-00-5e-7f-a0-37 

The multicast IP address and the multicast MAC addresses are related . The multicast MAC address generated by NLB is of the form 01-00-5e-xx-xx-xx . To determine the last three octets of the IP address, a multicast IP group address has to be chosen so that it will not interfere with the Internet traffic and also will not hinder any multicast applications that are running on hosts that are part of the subnet on which the NLB cluster resides. The address range 239.255.x.x is used because it's defined to be administratively scoped (that is, any IGMP join messages sent to an address in this range would not be forwarded by border gateway routers preventing interference with any traffic on the Internet).

note

IGMP support does not change anything with regard to the incompatibility between NLB clusters and layer-3 switches. Layer-3 switches should not be used to connect NLB cluster members.


Enabling IGMP support is a simple check box in the NLBMGR GUI. It is available only to clusters that use multicast MAC addresses.

Miscellaneous

Because of the history of NLB, prior to Windows Server 2003, the CLI was actually WLBS (Windows Load Balancing Service). In Windows Server 2003, both NLB and WLBS are available as CLI and have the same syntax and features. However, help still mentions only the WLBS command.

Microsoft has provided a WMI provider for NLB since Windows 2000. However, with Windows Server 2003 and the introduction of the WMIC command, WMI becomes a lot more useful. Oddly enough, NLB has two WMI providers, one that is documented and provides almost everything needed, and one that is undocumented and provides the necessary functionality for NLBMGR, which is a WMI consumer. The undocumented provider provides only one class called NLBSNIC .

 <  Day Day Up  >  


Windows Server 2003 on Proliants. Deployment Techniques and Management Tools for System Administrators
Windows Server 2003 on Proliants. Deployment Techniques and Management Tools for System Administrators
ISBN: B004C77T6A
EAN: N/A
Year: 2004
Pages: 214

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net