There are two main high availability technologies incorporated into the Windows Server 2008 R2 platform. The first, known as Failover Clustering, tends to receive more attention, thanks to a wider range of scenarios, where its benefits can be fully realized. Its somewhat neglected sibling, Network Load Balancing, is less versatile, it deserves its share of accolades, since it offers functionality that cannot be easily facilitated through other, native to the operating systems means. The purpose of this article is to give it the overdue credit it deserves by describing its features in a comprehensive manner. This will include the latest improvements introduced in Windows Server 2008 R2 Service Pack 1.
The less versatile of the two main high availability technologies in Windows Server 2008 R2, Network Load Balancing offers functionality that cannot be easily facilitated through other native OS means. This article examines its features and how to deploy it.
Let’s start by pointing out a few unique characteristics of Network Load Balancing (NLB) that distinguish it from Failover Clustering. First and foremost, it is important to realize that its primary purpose is to provide high availability through multi-instancing rather than automatic failover, although there is a built-in, heartbeat-based mechanism that detects a server failure and redirects new request to surviving nodes. This results directly from the underlying mechanism on which this technology is based. More specifically, an NLB cluster consists of a number (up to 32, inclusively) of servers, running in parallel and hosting identically configured (and sharing at least one common IP address) instances of a service or an application, which availability you want to ensure. This contrasts with the clustering design, where only one instance of a specific clustered resource is active at a time. Such principle implies, in turn, that highly available applications or services either have to be stateless or their state data must reside on a separate system, shared across all of NLB nodes.
This effectively limits applicability of this approach, but there are workarounds we will shortly describe that help remediate this limitation. Since from the client perspective it is not relevant which node responds to incoming requests, they can be load balanced according to a predefined algorithm, as long as its outcome is deterministic and consistent cluster-wide.
To comply with these requirements, the NLB component is implemented as a packet filter driver named nlb.sys, positioned below IP stack and above network device driver in regard to the OSI model, running on all cluster nodes with to the same configuration settings, which determine how incoming traffic targeting shared IP addresses is handled. By applying the same selection algorithm (based on so-called port rules), only one node becomes responsible for processing any given incoming packet and responding to it. The others are simply discarding it. Note that the resulting selection is not affected in any way by performance or utilization levels but instead it is the function of statically defined parameters. You can, however, designate individual nodes that should handle larger percentage of traffic than their counterparts by assigning to them higher host-level weight values.
Each port rule consists of criteria that determines its applicability by taking into consideration source and target IP addresses, port range and transport layer protocol (TCP, UDP or both). If a match is found, the algorithm applies arbitrarily selected filtering mode. Depending on the mode selection, IP traffic is blocked, processed by a single node (one with the highest priority value, which is equal to the unique identifier defined as part of host configuration), or handled in a distributed mode according to the value of weight parameter (another host-level setting, which, as we mentioned above, is used to calculate weighted average that determines percentage of traffic processed by a given node) and one of three affinity settings — None, Single or Network.