Tap the power of Windows network load balancing

Admins seeking a secret weapon in Windows environments should look no further than network load balancing, an often underutilized capability built right into Windows Server, and one that’s easy to take advantage of.

Primarily used for stateless applications, such as a Web server running IIS (Internet Information Services), NLB can be put to work in a variety of settings to leverage high availability and load balancing in otherwise unconsidered spots. Here’s a look at what makes NLB tick and where you can take advantage of its underlying power.

[ Read the InfoWorld Test Center’s first-look review of Windows 8. | Learn all about the forthcoming Windows 8 Server in InfoWorld’s “Windows Server 8 Deep Dive” PDF special report. | Stay abreast of key Microsoft technologies in our Technology: Microsoft newsletter. ]

The value of network load balancing NLB’s value resides in clustering. With it, you can create a cluster of machines aimed at providing high availability and load balancing. The concept is simple: Rather than point to a specific system, you configure your DNS record to point at an NLB cluster’s FQDN (fully qualified domain name). Assuming the cluster has two or more servers responding to a given request, NLB ensures the load is evenly distributed to each server; in the event of a failure, NLB directs requests to the remaining functional servers. From the client or user perspective, the transition is seamless (although the experience does depend on the application, the protocol, the affinity settings and the nature of the transition).

NLB’s simplicity is what differentiates it from other clustering solutions such as failover clustering in Windows Server Enterprise Edition. Foremost is the fact that NLB does not use clustered storage devices, like a shared storage array. Each server runs a copy of the IP-based application or service, and the data for those applications or services is held on the local machines. It’s not active/passive clustering; instead, all machines in the cluster can function and serve clients equally to balance the load.

NLB can be used with a single network adapter, but the better setup uses two network adapters to separate the NLB network from your public LAN. Some admins wonder whether RAID is necessary for these systems. Because each NLB member is an exact clone with identical data, RAID isn’t required. In many cases, servers in the cluster are providing services, not necessarily data itself; again, RAID or fault-tolerant disks aren’t the most important concern.

Where to take advantage of network load balancing NLB provides obvious benefit to websites with IIS. With NLB, you can scale out to 32 servers. Other IP-based applications and services can also benefit from NLB, including media servers, terminal servers, and e-commerce sites.

NLB can come in handy in less obvious ways as well. For example, with SharePoint 2010, you might have Web front-end servers that you want to be a little more redundant, although this may prove difficult if you’re using Cisco switches. With Exchange 2010, you can use NLB to establish a CAS Array for your Client Access Server role to provide high availability for CAS services. However, note that you cannot use NLB if your CAS servers are co-lacated with Mailbox servers that are members of an Exchange DAG.

You can also use NLB for additional Hub Transport balancing support (requires SP1 or later), which is necessary only if there’s an SMTP application in your environment that requires it. If you’re using edge transport servers within an on-premises environment, you can configure a cloned edge and use NLB. Learn more about NLB for hub transport servers through TechNet.

Note: While NLB is supported for Exchange server load balancing with the Hub/Edge Transport and CAS server roles, it is not necessarily recommended.  Generally Microsoft recommends a hardware load balancer because of limitations with NLB and Exchange, for example there may be performance issues, NLB doesn’t detect service outages and port flooding is, at times, an issue.  To understand load balancing recommendations a bit better you can read up through TechNet.  Some would say NLB isn’t really appropriate for most, if not all Exchange implementations — so it is essential that I mention that fact.  However, it is being utilized and is, in some cases, supported and so it warrants mentioning that as well.

As opposed to NLB, Microsoft recommends using a hardware load balancer, and it is good to be aware of the circumstances: for example, as mentioned above, when the CAS server is part of a DAG (Database Availability Group) you cannot use NLB. Servers that are already part of a Windows failover cluster (as in the case of a DAG member) cannot also be part of an NLB cluster.

There are other reasons, in an Exchange environment or otherwise, where a hardware load balancer is recommended because of the size and configuration of the network and the other solutions you have in play. You’ll have to do your due diligence and confirm that NLB is the right choice for your environment. 

The main thrust of this post is to help folks remember this forgotten solution that has many uses, especially if you have a Web farm or terminal services that require both load balancing and high availability through server redundancy.  If NLB is a good fit for you and your environment, go for it!

This article, “Tap the power of Windows network load balancing,” was originally published at InfoWorld.com. Read more of J. Peter Bruzzese’s Enterprise Windows blog and follow the latest developments in Windows at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.