Network Load Balancing: New Features | Introducing Microsoft Windows Server(TM) 2003

Windows Clustering technologies have been enhanced. A wider range of NLB scenarios and topologies can now be deployed.

Network Load Balancing Manager

In Windows 2000, to create an NLB cluster users had to separately configure each machine in the cluster. Not only was this additional work, but it also opened up the possibility of user error because identical cluster parameters and port rules had to be configured on each machine. A new utility in Windows Server 2003 called the Network Load Balancing Manager helps solve some of these problems by providing a single point of configuration and management of NLB clusters. The NLB Manager lets you do the following:

Create new NLB clusters and automatically propagate cluster parameters and port rules to all hosts in the cluster. You can also propagate host parameters to specific hosts in the cluster.
Add and remove hosts to and from NLB clusters.
Automatically add cluster IP addresses to TCP/IP.
Manage existing clusters by simply connecting to them or by loading their host information from a file and saving this information to a file for later use.
Configure NLB to load-balance multiple Web sites or applications on the same NLB cluster. This includes adding all cluster IP addresses to TCP/IP and controlling traffic sent to specific applications on specific hosts in the cluster.
Diagnose improperly configured clusters.

Virtual Clusters

In Windows 2000, users could load-balance multiple Web sites or applications on the same NLB cluster simply by adding the IP addresses corresponding to those Web sites or applications to TCP/IP on each host in the cluster. This is because NLB on each host load-balanced all IP addresses in TCP/IP except the dedicated IP address. The shortcomings of this feature in Windows 2000 were as follows :

Port rules specified for the cluster were automatically applied to all Web sites or applications load-balanced by the cluster.
All the hosts in the cluster had to handle traffic for all the Web sites and applications hosted on them.
To block out traffic for a specific application on a specific host, traffic for all applications on that host had to be blocked.

A new feature in Windows Server 2003 called virtual clusters overcomes these deficiencies by providing per-IP port rules capability. This allows the user to

Configure different port rules for different cluster IP addresses, wherein each cluster IP address corresponds to a Web site or application being hosted on the NLB cluster. This is in contrast to NLB in Windows 2000, wherein port rules were applicable to an entire host and not to specific IP addresses on that host.
Filter out traffic sent to a specific Web site or application on a specific host in the cluster. This allows individual applications on hosts to be taken off line for upgrades, restarts, and other purposes, without affecting other applications being load-balanced on the rest of the NLB cluster.
Specify which host in the cluster should service traffic sent to a specific Web site or application being hosted on the cluster. This way, not all hosts in the cluster need to handle traffic for all applications being hosted on that cluster.

Multi-NIC Support

Windows 2000 allowed the user to bind NLB to only one network card in the system. Windows Server 2003 allows the user to bind NLB to multiple network cards, thus removing the limitation. This now enables users to

Host multiple NLB clusters on the same hosts while leaving them on entirely independent networks. This can be achieved by binding NLB to different network cards in the same system.
Use NLB for firewall and proxy load balancing in scenarios in which load balancing is required on multiple fronts of a proxy or firewall.

Bidirectional Affinity

The addition of the multi-NIC support feature enabled several other scenarios in which there was a need for load balancing on multiple fronts of an NLB cluster. The most common use of this feature will be to cluster Internet Security and Acceleration (ISA) servers for proxy and firewall load balancing. The two most common scenarios in which NLB will be used together with ISA are

Web publishing.

In the Web publishing scenario, the ISA cluster typically resides between the Internet and the front-end Web servers. In this scenario, the ISA servers will have NLB bound only to the external interface, so there will be no need to use the bidirectional affinity feature.
Server publishing.

In the server publishing scenario, the ISA cluster will reside between the Web servers in the front and the published servers in the back. Here NLB will have to be bound to both the external interface (facing the Web servers) and the internal interface ( facing the published servers) of each ISA server in the cluster.

This scenario increases the level of complexity: now, when connections from the Web servers are being load-balanced on the external interface of the ISA cluster and then forwarded by one of the ISA servers to a published server, NLB has to ensure that the response from the published server is always routed to the same ISA server that handled the corresponding request from the Web server because this is the only ISA server in the cluster that has the security context for that particular session. So NLB has to make sure that the response from the published server doesn't get load-balanced on the internal interface of the ISA cluster because this interface is also clustered using NLB.

Bidirectional affinity makes multiple instances of NLB on the same host work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in the cluster.

Limiting Switch Flooding Using IGMP Support

The NLB algorithm requires every host in the NLB cluster to see every incoming packet destined for the cluster. NLB accomplishes this by never allowing the switch to associate the cluster's media access control (MAC) address with a specific port on the switch. However, the unintended side effect of this requirement is that the switch ends up flooding all of its ports with all incoming packets meant for the NLB cluster. This can certainly be a nuisance and a waste of network resources. To arrest this problem, a new feature called Internet Group Management Protocol support (IGMP support) has been introduced in Windows Server 2003.

IGMP support helps to limit the flooding to only those ports on the switch that have NLB machines connected to them. This way, non-NLB machines do not see traffic intended only for the NLB cluster, while at the same time all NLB machines see traffic meant for the cluster. This satisfies the requirements of the algorithm. IGMP support can be enabled only when NLB is configured in multicast mode.

Multicast mode has its own drawbacks, which are discussed extensively in knowledge base articles available on Microsoft.com. You should be aware of the shortcomings of multicast mode before deploying IGMP support.

Switch flooding can also be limited when using unicast mode by creating virtual LANs (VLANs) in the switch and putting the NLB cluster on its own VLAN. Unicast mode does not have the same drawbacks as multicast mode does, so limiting switch flooding using this approach might be preferable.

Top