Network Load Balancing Architecture

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

This section discusses Network Load Balancing and its role in providing failover support for IP-based applications and services that require high scalability and availability.

Network Load Balancing

Network Load Balancing provides failover support for IP-based applications and services that require high scalability and availability. NLB allows IT staff to incrementally scale-out up to 32 servers as demand increases. NLB is ideally suited to improving the availability of Web servers, media servers, terminal servers and e-commerce sites. Load balancing these services ensures there is no single point of failure and that there is no performance bottleneck.

Many of the concepts that apply to Server cluster also apply to NLB. NLB nodes work together to provide availability for critical IP-based resources, which can include: TCP, UDP and GRE traffic requests.

Failover and Failback Using a Virtual IP Address

As shown on Figure 7 below, NLB uses a virtual IP address. Client requests are directed to this virtual IP address which allows for transparent failover and failback. When a load balanced resource fails on one server, the remaining servers in the group take over the workload of the failed server. When the failed server comes back online, the server can automatically rejoin the cluster group and NLB starts to automatically distribute the load to the server. Failover takes less than 10 seconds in most cases.

Figure 7: Network load balancing overview

No Clustered Storage Devices

NLB does not use clustered storage devices. Each server runs a copy of the IP-based application or service that is being load balanced, and the data necessary for the application or service to run is stored on local drives.

Directing Traffic to a Specific Server

Although NLB is normally used to distribute the workload for an application or service, NLB can also be used to direct a specific type of traffic to a particular server. For example, IT staff may want to load balance HTTP and FTP traffic to a group of servers, but may also want a single server to handle media services traffic. In this latter case, NLB allows traffic to flow to a designated server and only reroutes traffic to another server in case of failure.

No Hardware Changes Required

NLB runs as a network driver and requires no hardware changes to install and run. Its operations are transparent to the IP networking stack. Because NLB is IP-based, IP networking must be installed on all load-balanced computers.

NLB Network Adapters

To provide high performance throughput and responsiveness, NLB normally uses two network adapters.

• Cluster adapterhandles network traffic for the cluster.

• Dedicated adapterhandles client-to-cluster network traffic, and other traffic originating outside the cluster network.

NLB uses unicast or multicast broadcasts to direct incoming traffic to all servers in the cluster. The NLB driver on each host acts as a filter between the cluster adapter and the TCP/IP stack, allowing only traffic bound for the designated host to be received. NLB only controls the flow of TCP, UDP and GRE traffic on specified ports. It does not control the flow of TCP, UDP and GRE traffic on non-specified ports, and it does not control the flow of other incoming IP traffic. All traffic that is not controlled is passed through without modification to the IP stack.

Using a Single NLB Network Adapter

NLB can work with a single network adapter. When it does so, there are limitations.

Unicast mode. With a single adapter in unicast mode, node-to-node communications are not possible, meaning nodes within the cluster cannot communicate with each other. Servers can, however, communicate with servers outside the cluster subnet.

Multicast mode. With a single adapter in multicast mode, node-to-node communications are possible, as are communications with servers outside the cluster subnet. However, the configuration is not optimal for handling moderate-to-heavy traffic from outside the cluster subnet to specific cluster hosts.

For handling node-to-node communications and moderate to heavy traffic, two adapters should be used.

Optimizing NLB Servers

As with Server cluster, servers that use NLB can benefit from optimization. Servers should be optimized for their role, the types of applications they will run and the anticipated local storage they will use.

While IT staff may want to build redundancy into the local hard drives on NLB servers, this adds to the expense of the server without significant availability gains in most instances. Because of this, NLB servers often have drives that do not use RAID and do not provide fault tolerance; the idea being that if a drive causes a server failure, other servers in the NLB cluster can quickly take over the workload of the failed server.

Synchronizing Data

If it seems odd to not use RAID, keep in mind that servers using NLB are organized as clones with identical copies of data on each server. Because many different servers have the same data, maintaining the data with RAID sets is not as important as it is with server clusters. A key consideration IT staff does have to make when using NLB, however, is data synchronization. The state of the data on each server must be maintained so that the clones are updated whenever changes are made. This need to synchronize data periodically is an overhead that needs to be considered when designing the server architecture.