Using NLB

You can use the Application Center New Cluster Wizard to quickly set up and configure NLB, without any manual configuration tasks. If the default settings applied by the wizard are not sufficient, you can use the Application Center user interface to modify them after creating the cluster, or the NLB configuration dialog box in the Properties dialog box for the appropriate network adapter. Application Center also provides seamless integration with NLB so that you can use the Application Center user interface to complete common administrative tasks, such as setting members online and offline.

If you previously configured NLB prior to creating a cluster in Application Center, you should reconfigure the settings through the wizard. Alternatively, if you select Keep existing settings in the wizard, Application Center will use your existing NLB settings and replicate them to members.

If you want to modify the settings applied by the New Cluster Wizard, you should do so before adding any members. By doing so, the members that you add acquire the proper settings. If you modify settings after adding members, you might disrupt the cluster.

For NLB to function properly on an Application Center cluster, each member must have a minimum of two network adapters: one that handles communication with clients and one that handles intracluster communication (between cluster members). Typically, some form of load balancing is implemented for the network adapter that handles communication with clients. This load-balanced adapter must have at least one static IP address that is used as the cluster IP address, or virtual IP address. If you have an NLB cluster with multiple cluster IP addresses, you can use the Application Center user interface to add and remove all but the primary IP address.

Application Center does not support single-host failover port rules in NLB. By default, NLB is configured in Unicast mode. To enable Multicast mode, you must configure NLB in Multicast mode manually before starting the New Cluster Wizard. Then, you should select Keep existing settings when the wizard detects your NLB installation. Or, you can create an NLB cluster in Unicast mode and after the cluster is created, but before adding members, enable Multicast in the NLB configuration dialog box for the appropriate network adapter. Then, you can begin adding members. In this manner, members that you add subsequently acquire the appropriate settings (including NLB configuration in Multicast mode).

In Unicast mode, NLB overwrites the network adapter's media access control (MAC) address with its own virtual media access control address by using the registry. Some network adapter drivers do not allow their media access control address to be overwritten in the registry. In this case, use a different network adapter (one that allows its media access control address to be overwritten in the registry) or use Multicast mode, which adds a virtual media access control address to the existing network adapter's media access control address.

 Note   Application Center does not synchronize the NLB remote control password, port, and NLB Remote Control Enabled property. You must set these values manually on each member.

NLB Background

NLB distributes incoming client requests for TCP and Universal Datagram Protocol (UDP) protocols, including HTTP, across multiple members. Unlike other load balancers, which require dedicated hardware, NLB is a software-based load balancer that resides on each member.

Periodically, each member transmits an NLB exchange message over the load-balanced adapters. This message is used to coordinate actions between each member. By default, the period of message exchange is 1 second. As the state of the cluster changes (for example, you add or remove members or set members offline or online), the message exchanges for NLB are disrupted. After a certain number of failed-message exchanges, NLB initiates a process to determine the current state of the cluster so that it can load balance the cluster properly. By default, NLB initiates this process after five failed-message exchanges. NLB automatically redistributes requests among the active, remaining members. This redistribution ensures that non-active members do not receive any requests, and requests are only processed by active members.

Each member in an NLB cluster receives all incoming requests. NLB uses a fully distributed algorithm to determine which member processes the request; all other members discard the request. This method of load balancing is more efficient than using traditional load balancing devices, because filtering unwanted requests is faster than routing them.

Client Affinity

NLB offers three types of client affinity to minimize response time to clients and provide generic support for preserving session state. Each affinity specifies a different method for distributing client requests. In Application Center, the New Cluster Wizard sets affinity to Single by default. Later, you can use the cluster Properties dialog box to modify the affinity. The following table describes the three types of affinity.

Affinity	Description
None	Multiple requests from the same client can access any member; useful for clusters that do not store session state information on individual members.
Single	Multiple requests from the same client must access the same member; useful for clusters within an intranet.
Class C	Multiple requests from the same TCP/IP Class C address range must access the same member; useful for clusters on the Internet.

No Affinity

With No affinity, NLB does not associate clients with a particular member. Every client request can be load balanced to any member. This affinity provides the best performance but might disrupt clients with established sessions, because subsequent requests might be load balanced to other members where the session information does not exist.

Single Affinity

In Single affinity, NLB associates clients with particular members by using the client's IP address. Thus, requests coming from the same client IP address always reach the same member. This affinity provides the best support for clients that use sessions on an intranet. These clients cannot use No affinity because their sessions could be disrupted. Additionally, these clients cannot use Class C affinity because intranet clients typically have IP addresses within a narrow range. It is likely that this range is so narrow that all clients on an intranet have the same Class C address, which means that one member might process all of the requests while other members remain idle.

Class C Affinity

With Class C affinity, NLB associates clients with particular members by using the Class C portion of the client's IP address. Thus, clients coming from the same Class C address range always access the same member. This affinity provides the best performance for clusters serving the Internet.

 Note   It is not efficient for Internet clients to use Single affinity because, in Single affinity, NLB load balances each client by the client's entire IP address, which can span a broad range. By using Class C affinity, NLB associates clients with only the same Class C portion of the IP address with particular members. Therefore, you essentially reduce the range of IP addresses by which NLB load balances clients.

Related Topics

• For more information about NLB, see the NLB Help for the appropriate network adapter.

• For more information about configuring communication for NLB, see Establish Communication in NLB Clusters.

• For more information about NLB configuration in the New Cluster Wizard, see Cluster Creation Process.

• For more information about specifying a different affinity, see Modify Affinity.

Did you find this information useful? Please send your suggestions and comments about the documentation to acdocs@microsoft.com.