NLB cluster requirements

NLB is available on all versions of the Windows Server 2003 platform (Standard, Web, Enterprise, and Datacenter). When configuring NLB as part of Application Center 2000, you will need to meet other requirements beyond the ones listed in this section. For example, in such a configuration, two network adapters on each cluster node are required. For details, refer to the product's documentation.

It is possible to run multiple version clusters. For example, you can use a mix of Windows Server 2003 Enterprise Server and Windows Server 2003 Datacenter Server and Windows 2000 Network Load Balancing, as well as the Windows Load Balancing Service operating on Windows NT 4.0 servers. However, running Network Load Balancing on a server cluster is not supported.

NLB places a number of requirements on the network infrastructure (such as routers and switches) as well as on the network adapters installed in the cluster nodes. NLB can run on servers connected to FDDI, Ethernet, or Gigabit Ethernet networks, but it does not operate on Token Ring networks.

As mentioned previously, when using unicast mode, the MAC address of a network adapter is substituted with one generated by NLB, which may not be supported by some network adapters. Such adapters need to be replaced prior to cluster setup. Alternatively, configuration can be changed to multicast mode, which retains the original MAC address and eliminates the need for replacement.

Having the same unicast MAC address (when in unicast mode) used across multiple network adapters might create problems when adapters are connected directly to the same switch. To prevent these problems, NLB (by default, when operating in unicast mode) does not use the cluster-shared MAC address for the outgoing packets. Instead, it creates yet another one, which is a combination of the "shared" MAC address and cluster node priority. As a result, the switch never learns the cluster MAC address. When a client request arrives with the frame destination set to the cluster MAC address, the switch forwards it to all of its ports (because no port is associated with this MAC address). As a result, each cluster node receives the frame (as intended). This behavior is controlled by the value of the registry entry MaskSourceMAC (of REG_DWORD type). The entry resides, along with other NLB settings, in the registry location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ WLBS\Parameters\Interface\{Interface_GUID}, where {Interface_GUID} represents the GUID of the cluster network adapter. Setting this entry to 1 causes the behavior described previously. Setting it to 0 places the cluster MAC address back in the outgoing packets.

This process, known as switch flooding, works well provided that the switch is used exclusively for clustered servers. Otherwise, other nonclustered systems connected to the same switch will also receive cluster-bound traffic. Network congestion then becomes even more of an issue in situations where multiple clusters share the same switch. As a workaround, a network hub can be placed between a switch port and the clustered nodes. After you disable the

MaskSourceMAC registry entry (by changing its value to 0), the cluster MAC address will become associated with the single switch port (the one connected to the hub), thus preventing switch flooding. This solution, however, introduces individual points of failure (a hub, its connection to a switch, and the single port on the switch) that negatively impacts the level of high availability (the very reason for using NLB clustering). A preferred approach is to use a dedicated switch for the cluster nodes, configure VLANs on the existing switch, or configure NLB in multicast mode.

When operating in multicast mode, switch flooding can be prevented by enabling the Internet Group Management Protocol (IGMP) multicast feature. IGMP is used by network hosts to advertise their multicast addresses to switches in which they have direct contact. In order for this feature to work, monitoring of the IGMP packets needs to be configured on the switch. This way, a frame targeting a specific multicast MAC address can be forwarded to the appropriate ports, rather than flooding all of them. Once the IGMP setting is enabled on the cluster nodes, the switch updates take place every 60 seconds.

As explained previously, in both unicasting and multicasting configuration it is possible to avoid switch flooding by configuring a separate VLAN for switch ports connected to cluster nodes (assuming that the switch has VLAN capabilities and unused router interfaces are available).

NLB uses Address Resolution Protocol packets to update the ARP cache on routers with IP Address and MAC address pairs of the cluster's network adapters. The MAC address can be either unicast or multicast, depending on the cluster mode. Some routers, however, have problems processing ARP updates that contain different MAC address information in the ARP portion of the frame and the Ethernet header. Others (most notably some of Cisco routers) do not accept ARP updates that map a unicast (cluster) IP address to a multicast MAC address (this happens when a cluster operates in multicast mode). Either one of these problems can be solved by using a static ARP entry, which can be created on a router.

TCP/IP should be the only network protocol bound to a cluster's network adapters. Dedicated and cluster IP addresses should be statically assigned. Both need to be entered in the NLB configuration and TCP/IP properties of the cluster network adapter (this is done automatically if you follow Microsoft recommendations and use NLB Manager for cluster management).

All dedicated and clustered IP addresses should belong to the same IP subnet and share the same subnet mask. In addition, the dedicated IP address should appear first in the list of IP addresses in the TCP/IP properties dialog box (on top of the cluster IP address). Otherwise, outbound connections from a cluster node would use a cluster "virtual" IP address as the source and the returning packet would be load balanced and could possibly be redirected to a different node. The only exception applies to configuring NLB for clustered Virtual Private Network connections. In such cases, no dedicated IP address should be used at all — only a virtual cluster IP address should appear in the TCP/IP properties dialog box for a cluster network adapter.

As with server clusters, NLB places special demands on the applications and services it supports. These applications must be IP-based and communicate using TCP connections or UDP streams. They cannot depend on server names for establishing remote connections. They also should not require exclusive locks (for write access) on resources located on cluster nodes that might be simultaneously used by other clients. In general, data used by clustered applications and services can be located on the backend servers (shared among the nodes) or directly on the server nodes. In the first case, shared backend servers should be able to handle simultaneous access from cluster nodes. In the second case, some type of content replication mechanism should be put in place (to make the content of the nodes identical). One such mechanism, which is almost completely automated, is provided by Application Center 2000. The Content Replication System available on the Site Server offers similar, although more limited, functionality. With .NET Web applications, which no longer rely on a registry to store component configuration information, content deployment in many cases is as simple as file copy (hence the term XCOPYdeployment). Very common is a hybrid approach, whereby the static content (such as HTML pages on a Web server) is synchronized across cluster nodes, while dynamic data is kept on a backend server.

Was this article helpful?

0 0


  • mark
    What mac address does nlb cluster use?
    7 years ago

Post a comment