Windows Server 2008 R2 : Deploying Network Load Balancing Clusters (part 1)

NLB Applications and Services

NLB is well equipped to distribute user connections and create fault tolerance for a number of different applications and network services. Because NLB does not replicate data across cluster nodes—and neither does failover clustering for that matter—using applications that require access to local data that is dynamic or frequently changes is not recommended for NLB clusters.

Applications well suited for NLB clusters are web-based applications and services, proxy services, virtual private network, SMTP gateways, streaming media, and Remote Desktop Services Session Host server systems. Many other applications and services can also run well on NLB clusters, but the preceding list is what most organizations utilize NLB clusters for.

NLB clusters are based on client connections made to a specific DNS name, IP address, and TCP and/or UDP port using either IPv4 or IPv6. It’s important to read the vendor’s application documentation regarding how the client communicates with the application and how this communication can be configured on load-balancing devices or services such as Microsoft Windows Server 2008 R2 NLB clusters. For instance, certain applications use cookies or other stateful session information that can be used to identify a client throughout the entire session and it is important that the client maintains a connection to the same cluster node during the entire session. Other applications, such as a website that serves up static pages, can respond to a single client’s requests from multiple nodes in the NLB cluster. For a web-based application, such as an e-commerce application, an encrypted SSL session, or an application that is authenticated by the actual web server, the NLB cluster would need to direct all communication between the client and a specific cluster node. Considering these types of scenarios in advance helps determine how the NLB cluster will be defined.

Installing the Network Load Balancing Feature

Before an NLB cluster can be created, the feature needs to be installed on all servers that will participate in the cluster. To install the Network Load Balancing feature, perform the following steps:

Creating Port Rules

When an NLB cluster is created, one general port rule is also created for the cluster. The NLB cluster port rule or rules define what type of network traffic the cluster will load-balance across the cluster nodes and how the connections will be managed. The Port Rules Filtering option defines how the traffic will be balanced across each individual node. As a best practice, limiting the allowed ports for the clustered IP addresses to only those needed by the cluster load-balanced applications can improve overall cluster performance and security. In an NLB cluster, because each node can answer for the clustered IP address, all inbound traffic is received and processed by each node. When a node receives the request, it either handles the request or drops the packet if another node has already established a session or responded to the initial request.

When an administrator discards the default NLB cluster port rule and creates a rule that only allows specific ports to the clustered IP address or addresses, plus an additional rule to block all other traffic destined for the cluster IP address, each cluster node can quickly eliminate and drop packets that do not meet the allow port rule and in effect improve network performance of the cluster. The security benefit of this configuration also removes any risk of attacks on any other port using the cluster IP address.

Port Rules Filtering Mode and Affinity

Within an NLB cluster port rule, the NLB administrator must configure the appropriate filtering mode. This allows the administrator to specify whether only one node or multiple nodes in the cluster can respond to requests from a single client throughout a session. There are three filtering modes: Single Host, Disable This Port Range, and Multiple Host.

Single Host Filtering Mode

The Single Host filtering mode ensures that all traffic sent to the cluster IP address that matches a port rule with this filtering mode enabled is handled exclusively in the cluster by one particular cluster node.

Disable This Port Range Filtering Mode

The Disable This Port Range filtering mode tells the cluster which ports are not active on the cluster IP address. Any traffic requests received on the cluster IP address that match a port rule with this filtering mode result in the network packets getting automatically discarded or dropped. Administrators should configure specific port rules and use this filter mode for ports and port ranges that do not need to be load-balanced across the cluster nodes.

Multiple Hosts Filtering Mode

The Multiple Host filtering mode is probably the most commonly used filtering mode and is also the default. This mode allows traffic to be handled by all the nodes in the cluster. When traffic is balanced across multiple nodes, the application requirements define how the Affinity mode should be set. There are three types of multiple host affinities:

• None— This affinity type can send unique clients’ requests to all the servers in the cluster during the entire span of the session. This can speed up server response times but is well suited only for serving static data to clients. This affinity type works well for general web browsing, read-only file data, and FTP servers.

• Network— This affinity type routes traffic from a particular class C address space to a single NLB cluster node. This mode is not used too often but can accommodate client sessions that use stateful applications and when different client requests are serviced by down-level proxy servers. This is a useful affinity type for companies that direct traffic from several remote offices, through proxies before connecting to the services, and/or applications managed by the port rules in the NLB cluster.

• Single— This affinity type is the most widely used. After the initial request is received by the cluster nodes from a particular client, that node will handle every request from that client until the session is completed. This affinity type can accommodate sessions that require stateful data such as an encrypted SSL web application or a Remote Desktop session. This is the default filtering mode on a port rule and is well suited to handle almost any NLB clustered service or application.

Using Cluster Operation Mode

There are three different cluster operation modes: Unicast, Multicast, and IGMP Multicast. Most traditional network traffic is unicast traffic where clients and servers maintain a one-to-one network connection. Multicast networking allows a server to send out information to one multicast address that is then processed by a number of clients. To receive multicast data, a client joins a multicast group associated with the multicast address and one data feed or transmission is presented to the group by the server, thereby streamlining and improving network performance of the application. Multicast traffic is usually one direction and when the multicast client joins the group, it begins to receive the transmission. Common applications that use multicast are streaming music and video websites, Internet radio, and Internet training or online noninteractive courses. IGMP Multicast can be used in place of multicast and enhances overall network performance when multicast is required. Selecting this management protocol allows for the multicast clients to register with the IGMP Multicast server and afterward, the multicast traffic will only be sent to the switch ports or trunks that connect to the multicast clients, reducing traffic on the remaining ports of the network switches. One more important point to mention about multicast traffic is that the network switches and routers that the traffic will pass through must support multicast traffic and allow it. Many enterprise class switches and routers have multicast support disabled by default.

Configuring Network Cards for NLB

Configuring the network cards on the NLB cluster nodes is the first step in building the cluster. Although these steps can be performed during cluster creation using the NLB Manager, the same result can be achieved by editing the TCP/IP properties of each of the cluster node’s network cards. Best practice for NLB cluster nodes running in Unicast mode is to have two network cards to allow host communication to occur on one NIC while cluster communication is isolated on the cluster NIC. Multiple NICS can also add greater flexibility when it comes to controlling traffic and managing network security.