When a Web server application maintains state information about a client session across multiple TCP connections, it is important that all TCP connections for the client are directed to the same cluster host.

Network Load Balancing can load-balance any application or service that uses TCP/IP as its network protocol and is associated with a specific TCP or UDP port. The distributed algorithm, which is used to determine which host responds to a TCP connection request or incoming UDP packet, can include the port rule in the decision. Including the port rule in the decision means that for any client, different members of the Network Load Balancing cluster may service connection requests or packets addressed to different port rule on the virtual IP address.

Note

• While configuring a Network Load Balancing cluster, consider the type of application or service that the server is providing, and then select the appropriate configuration for Network Load Balancing hosts.
  
  

Client State

Network Load Balancing Parameters

The sections in this document provide in-depth information about how Network Load Balancing works in an optimal environment. An optimal environment for Network Load Balancing is defined as follows:

• Two or more network adapters in each cluster host are used.
  
  
• The Transmission Control Protocol/Internet Protocol (TCP/IP) network protocol is the only protocol used on the cluster adapter. Other protocols, such as Internetwork Packet Exchange (IPX), should not be added to this adapter.
  
  
• Within a given cluster, all cluster hosts must operate in either unicast or multicast mode, but not both.
  
  
• Network Load Balancing should not be enabled on a computer that is part of a server cluster.
  
  
• All hosts in a cluster must belong to the same subnet and the cluster’s clients must be able to access this subnet.
  
  
• The appropriate hardware resources should be used. The goal in tuning Network Load Balancing and the applications it load-balances is to determine which hardware resource will experience the greatest demand, and then to adjust the configuration to relieve that demand and maximize total throughput.
  
  
• Cluster parameters, port rules, and host parameters are correctly configured: 
  
  
  • Cluster parameters and port rules for each unique virtual IP address are identical across all hosts. Each unique virtual IP address must be configured with the same port rules across all hosts that service that virtual IP address. However, if you have multiple virtual IP addresses configured on a host, each of those virtual IP addresses can have a different set of port rules.
    
    
  • Port rules are set for all ports used by the load-balanced application. For example, FTP uses port 20, port 21, and ports 1024–65535. 
    
    
  • The dedicated IP address is unique and the cluster IP address is added to each cluster host.
    
    
• Network performance should be optimized by limiting switch port flooding.
  
  
• Windows Internet Name Service (WINS), Dynamic Host Configuration Protocol (DHCP), and Domain Name System (DNS) services can be run on Network Load Balancing cluster hosts; however, the interface to which Network Load Balancing is bound cannot use a DHCP address.
  
  

The Network Load Balancing driver is installed on a computer configured with Transmission Control Protocol/Internet Protocol (TCP/IP) and is bound to a single network interface called the cluster adapter. The driver is configured with a single IP address, the cluster primary IP address, on a single subnet for all of the member servers (or hosts) on the cluster. Each host has an identical media access control (MAC) address that allows the hosts to concurrently receive incoming network traffic for the cluster’s primary IP address (and for additional IP addresses on multihomed hosts).

Incoming client requests are partitioned and load-balanced among the cluster hosts by the Network Load Balancing driver, which acts as a rule-based filter between the network adapter’s driver and the TCP/IP stack. Each host receives a designated portion of the incoming network traffic.

Network Load Balancing is a distributed architecture, with an instance of the driver installed on each cluster host. Throughput is maximized to all cluster hosts by eliminating the need to route incoming packets to individual cluster hosts, through a process called filtering. Filtering out unwanted packets in each host improves throughput; this process is faster than routing packets, which involves receiving, examining, rewriting, and resending the packets.

Another key advantage to the fully distributed architecture of Network Load Balancing is the enhanced availability resulting from (n-1) way failover in a cluster with n hosts. In contrast, dispatcher-based solutions create an inherent single point of failure that you must eliminate by using a redundant dispatcher that provides only one-way failover. Dispatcher-based solutions offer a less robust failover solution than does a fully distributed architecture.

The Network Load Balancing driver uses a fully distributed filtering algorithm to statistically map incoming client requests to the cluster hosts, based upon their IP address, port, and other information.

When receiving an incoming packet, all hosts within the cluster simultaneously perform this mapping to determine which host should handle the packet. Those hosts not required to service the packet simply discard it. The mapping remains constant unless the number of cluster hosts changes or the filter processing rules change.

The filtering algorithm is much more efficient in its packet handling than centralized load balancers, which must modify and retransmit packets. Efficient packet handling allows for a much higher aggregate bandwidth to be achieved on industry standard hardware.

The distribution of client requests that the statistical mapping function effects is influenced by the following:

• Host priorities
  
  
• Multicast or unicast mode
  
  
• Port rules
  
  
• Affinity
  
  
• Load percentage distribution
  
  
• Client IP address
  
  
• Client port number
  
  
• Other internal load information
  
  

The statistical mapping function does not change the existing distribution of requests unless the membership of the cluster changes or you adjust the load percentage.

Network Load Balancing requires at least one network adapter; and different hosts in a cluster can have a different number of adapters, but all must use the same network IP transmission mode, either unicast or multicast.

Unicast mode is the default mode, but you can configure the Network Load Balancing driver to operate in either mode.

When you enable unicast support, the unicast mode changes the cluster adapter’s MAC address to the cluster MAC address. This cluster address is the same MAC address that is used on all cluster hosts. When this change is made, clients can no longer address the cluster adapters by their original MAC addresses.

When you enable multicast support, Network Load Balancing adds a multicast MAC access to the cluster adapters on all of the cluster hosts. At the same time, the cluster adapters retain their original MAC addresses.

Note

• The Network Load Balancing driver does not support a mixed unicast and multicast environment. All cluster hosts must be either multicast or unicast; otherwise, the cluster will not function properly.
  
  

If clients are accessing a Network Load Balancing cluster through a router when the cluster has been configured to operate in multicast mode, be sure that the router meets the following requirements:

• Accepts an Address Resolution Protocol (ARP) reply that has one MAC address in the payload of the ARP structure but appears to arrive from a station with another MAC address, as judged by the Ethernet header.
  
  
• Accepts an ARP reply that has a multicast MAC address in the payload of the ARP structure.
  
  

If your router does not meet these requirements, you can create a static ARP entry in the router. For example, some routers require a static ARP entry because they do not support the resolution of unicast IP addresses to multicast MAC addresses.

The Network Load Balancing architecture with a single MAC address for all cluster hosts maximizes use of the subnet’s hub and/or switch architecture to simultaneously deliver incoming network traffic to all cluster hosts.

Your network configuration will typically include routers, but may also include layer 2 switches (collapsed backbone) rather than the simpler hubs or repeaters that are available. Cluster configuration, when using hubs, is predictable because the hubs distribute IP traffic to all ports.

Note

• If client-side network connections at the switch are significantly faster than server-side connections, incoming traffic can occupy a prohibitively large portion of server-side port bandwidth.
  
  

Network Load Balancing requires only a single network adapter, but for optimum cluster performance, you should install a second network adapter on each Network Load Balancing host. In this configuration, one network adapter handles the network traffic that is addressed to the server as part of the cluster. The other network adapter carries all of the network traffic that is destined to the server as an individual computer on the network, including cluster communication between hosts.

Note

• Network Load Balancing with a single network adapter can provide full functionality if you enable multicast support for this adapter.
  
  

When you are implementing a Network Load Balancing solution, the Internet Protocol transmission mode that is selected and the number of network adapters that are required are dependent upon the following network requirements:

• Layer 2 switches or hubs
  
  
• Peer-to-peer communication between hosts
  
  
• Maximized communication performance
  
  

For example, a cluster supporting a static Hypertext Markup Language (HTML) Web application can have a requirement to synchronize the Web site copies of a large number of cluster hosts. This scenario requires interhost peer-to-peer communications. You select the number of network adapters and the IP communications mode to meet this requirement.

There is no restriction on the number of network adapters, and different hosts can have a different number of adapters. You can configure Network Load Balancing to use one of four different models.

Single Network Adapter in Unicast Mode

Single Network Adapter in Multicast Mode

Multiple Network Adapter in Unicast Mode

Multiple Network Adapter in Multicast Mode

Comparison of Modes

The Network Load Balancing cluster is assigned a primary Internet Protocol (IP) address. This IP address represents a virtual IP address to which all of the cluster hosts respond, and the remote control program that is provided with Network Load Balancing uses this IP address to identify a target cluster.

Primary IP address

The primary IP address is the virtual IP address of the cluster and must be set identically for all hosts in the cluster. You can use the virtual IP address to address the cluster as a whole. The virtual IP address is also associated with the Internet name that you specify for the cluster.

Dedicated IP address

You can also assign each cluster host a dedicated IP address for network traffic that is designated for that particular host only. Network Load Balancing never load-balances the traffic for the dedicated IP addresses, it only load-balances incoming traffic from all IP addresses other than the dedicated IP address.

The following figure shows how IP addresses are used to respond to client requests.

Network Load Balancing Cluster

When the virtual IP address is resolved to the station address (MAC address), this MAC address is common for all hosts in the cluster. You can enable client connections to only the required cluster host when more packets are sent. The responding host then substitutes a different MAC address for the inbound MAC address in the reply traffic. The substitute MAC address is referred to as the Source MAC address. The following table shows the MAC addresses that will be generated for a cluster adapter.

In the unicast mode of operation, the Network Load Balancing driver disables the onboard MAC address for the cluster adapter. You cannot use the dedicated IP address for interhost communications because all of the hosts have the same MAC address.

In multicast mode of operation, the Network Load Balancing driver supports both the onboard and the multicast address. If your cluster configuration will require connections from one cluster host to another, for example, when making a NetBIOS connection to copy files, use multicast mode or install a second network adapter.

If the cluster hosts were attached to a switch instead of a hub, the use of a common MAC address would create a conflict because Layer 2 switches expect to see unique source MAC addresses on all switch ports. To avoid this problem, Network Load Balancing uniquely modifies the source MAC address for outgoing packets, for example, a cluster MAC address of 02-BF-1-2-3-4 is set to 02-p-1-2-3-4, where p is the host’s priority within the cluster.

This technique prevents the switch from learning the cluster’s inbound MAC address, and as a result, incoming packets for the cluster are delivered to all of the switch ports. If the cluster hosts are connected to a hub instead of to a switch, you can disable masking of the source MAC address in unicast mode to avoid flooding upstream switches. You disable Network Load Balancing by setting the Network Load Balancing registry parameter MaskSourceMAC to 0. The use of an upstream level three switch will also limit switch flooding.

The unicast mode of Network Load Balancing induces switch flooding to simultaneously deliver incoming network traffic to all of the cluster hosts. Also, when Network Load Balancing uses multicast mode, switches often flood all of the ports by default to deliver multicast traffic. However, the multicast mode of Network Load Balancing gives the system administrator the opportunity to limit switch flooding by configuring a virtual LAN within the switch for the ports corresponding to the cluster hosts.

Port rules are created for individual ports and for groups of ports that Network Load Balancing requires for particular applications and services. The filter setting then defines whether the Network Load Balancing driver will pass or block the traffic.

The Network Load Balancing driver controls the distribution and partitioning of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) traffic from connecting clients to selected hosts within a cluster by passing or blocking the incoming data stream for each host. Network Load Balancing does not control any incoming IP traffic other than TCP and UDP for ports that a port rule specifies.

You can add port rules or update parameters by taking each host out of the cluster in turn, updating its parameters, and then returning it to the cluster. The host joining the cluster handles no traffic until convergence is complete. The cluster does not converge to a consistent state until all of the hosts have the same number of rules. For example, if a rule is added, it does not take effect until you have updated all of the hosts have been updated and they have rejoined the cluster.

Note

• Internet Group Membership Protocol (IGMP), ARP, or other IP protocols are passed unchanged to the TCP/IP protocol software on all of the hosts within the cluster.
  
  

Port rules define individual ports or groups of ports for which the driver has a defined action. You need to consider certain parameters when creating the port rules, such as the:

• TCP or UDP port range for which you should apply this rule.
  
  
• Protocols for which this rule should apply (TCP, UDP, or both).
  
  
• Filtering mode chosen: multiple hosts, single host, or disabled.
  
  

When defining the port rules, it is important that the rules be exactly the same for each host in the cluster because if a host attempts to join the cluster with a different number of rules from the other hosts, the cluster will not converge. The rules that you enter for each host in the cluster must have matching port ranges, protocol types, and filtering modes.

Filtering Modes

Load Weighting

Priority

In a load-balanced multiserver environment, managing and resolving client, application, and session state for individual clients can be complex. By default, in a Network Load Balancing solution, different hosts in the cluster can service multiple client connections.

When a client creates an initial connection to a host in the cluster, the application running on this host holds the client state. If the same host does not service subsequent connections from the client, errors can occur if the application instances do not share the client state between hosts.

For example, application development for an ASP-based Web site can be more difficult if the application must share the client state among the multiple hosts in the cluster. If all of the client connections can be guaranteed to go to the same server, you can solve the difficulties with the application that is not sharing the client state among host instances.

By using a Network Load Balancing feature called affinity, you can ensure that the same cluster host handles all of the TCP connections from one client IP address. Affinity allows you to scale applications that manage session state spanning multiple client connections. In a Network Load Balancing cluster, with affinity enabled, initial client connection requests are distributed according to the cluster configuration, but after you have established the initial client request the same host will service all of the subsequent requests from that client.

Clients can have many TCP connections to a Network Load Balancing cluster; the load-balancing algorithm will potentially distribute these connections across multiple hosts in the cluster.

If server applications have client or connection state information, this state information must be made available on all of the cluster hosts to prevent errors. If you cannot make state information available on all of the cluster hosts, you cannot use client affinity to direct all of the TCP connections from one client IP address to the same cluster host. Directing TCP connections from the IP address to the same host allows an application to maintain state information in the host memory.

For example, if a server application (such as a Web server) maintains state information about a client’s site navigation status that spans multiple TCP connections, it is critical that all of the TCP connections for this client state information be directed to the same cluster host to prevent errors.

Affinity defines a relationship between client requests from a single client address or from a Class C network of clients (where IP addresses range from 192.0.0.1 to 223.255.255.254) and one of the cluster hosts. Affinity ensures that requests from the specified clients are always handled by the same host. The relationship lasts until convergence occurs (namely, until the membership of the cluster changes) or until you change the affinity setting. There is no time-out — the relationship is based only on the client IP address.

You can distribute incoming client connections based on the algorithm as determined by the following client affinity settings:

No Affinity

Single Affinity

Class C Affinity

Network Load Balancing cluster hosts exchange heartbeat messages to maintain consistent data about the cluster’s membership. By default, when a host fails to send out heartbeat messages within five seconds, it is deemed to have failed. Once a host has failed, the remaining hosts in the cluster perform convergence and do the following:

• Establish which hosts are still active members of the cluster.
  
  
• Elect the host with the highest priority as the new default host.
  
  
• Ensure that all new client requests are handled by the surviving hosts.
  
  

In convergence, surviving hosts look for consistent heartbeats. If the host that failed to send heartbeats once again provides heartbeats consistently, it rejoins the cluster in the course of convergence. When a new host attempts to join the cluster, it sends heartbeat messages that also trigger convergence. After all cluster hosts agree on the current cluster membership, the client load is redistributed to the remaining hosts, and convergence completes.

The following figure shows how the client load is evenly distributed among four cluster hosts before convergence takes place:

Network Load Balancing Cluster Before Convergence

The following figure shows a failed host and how the client load is redistributed among the three remaining hosts after convergence.

Network Load Balancing Cluster After Convergence

Convergence generally only takes a few seconds, so interruption in client service by the cluster is minimal. During convergence, hosts that are still active continue handling client requests without affecting existing connections. Convergence ends when all hosts report a consistent view of the cluster membership and distribution map for several heartbeat periods.

By editing the registry, you can change both the number of missed messages required to start convergence and the period between heartbeats. However, be aware that making the period between heartbeats too short increases network overhead on the system. Also be aware that reducing the number of missed messages increases the risk of erroneous host evictions from the cluster.

Note

• Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
  
  

Compatible applications must have the following requirements in order to work with Network Load Balancing:

• TCP connections or UDP data streams.
  
  
• Synchronization of data. If client data that resides on one of the hosts changes as a result of a client transaction, applications must provide a means of synchronizing data updates if that data is shared on multiple instances across the cluster.
  
  
• Single or Class C affinity. If session state is an issue, applications must use single or Class C affinity or provide a means (such as a client cookie or reference to a back-end database) of maintaining session state in order to be uniformly accessible across the cluster.
  
  

As highlighted in the previous two bullets, before using Network Load Balancing, you must consider an application’s requirements regarding client state. Network Load balancing can accommodate both stateless and stateful connections. However, certain factors must be considered for a stateful connection.

Application servers maintain two kinds of stateful connections:

• Interclient state. A state whose data updates must be synchronized with transactions that are performed for other clients, such as merchandise inventory at an e-commerce site. Because any host within the cluster can service client traffic, information that must be persistent across multiple requests or that must be shared among clients needs to be shared in a location that is accessible from all cluster hosts. Updates to information that is shared among the hosts needs to be synchronized, for example by using a back-end database server.
  
  
• Intraclient state. A state that must be maintained for a given client throughout a session (that can span multiple connections), such as a shopping cart process at an e-commerce site.
  
  

Network Load Balancing can be used with applications that maintain either type of state, although applications requiring interclient state are typically best accommodated with server clusters rather than Network Load Balancing. While intraclient state can be accommodated through the Network Load Balancing affinity settings, interclient state, on the other hand, requires additional components outside of Network Load Balancing.

Interclient State

Intraclient State

Applications that are not compatible with Network Load Balancing have one or more of the following characteristics:

• They bind to actual computer names (examples of such applications are Exchange Server and Distributed File System).
  
  
• They have files that must be continuously open for writing (for example, Exchange Server). In a Network Load Balancing cluster, multiple instances of an application (on different cluster hosts) should not have a file simultaneously opened for writing unless the application was designed to synchronize file updates. This is generally not the case.
  
  

CPU Overhead

Throughput and Response Time

Switch Occupancy