Web farms in .NET and IIS part 2: Network Load Balancer

This post is direct continuation of the post on the general introduction into web farms. We briefly mentioned NLB in the previous post: it performs load balancing by manipulating the MAC address of the network adapters.

This product is in fact not the primary choice for load balancing nowadays. It is very easy to use but it lacks many features that a full blown load balancer has but it has its place, especially in conjunction with Application Request Routing ARR – more on that in the next post.

Web traffic is routed to all servers in the web farm but only one of them will actually respond while the others simply ignore the request. Therefore NLB doesn’t have any load balancing device in front of the web farm – the farm machines work together to “solve an issue”.

Network load balancer

You first need to activate NLB on each machine in the web farm. If you have Windows Server 2008 R2 then in the Start menu select Administrative Tools and then Server Manager. In the Server Manager window select the Features node and click the Add Features menu point in the Action menu. Select NLB in the list that appears:

NLB activation

Click Install and if the installation was successful then you’ll be greeted with the following message:

NLB activation success

The NLB manager will then be available through a simple search:

NLB among search results

I don’t actually have access to 2 or more private machines with Windows Server installed and I don’t want to misuse my company’s network either for my private blogging purposes so it’s probably best to point you to a video showing how to set up NLB. I’d suggest you to watch the video to get a general idea but make sure you read my comments below before you actually set up the NLB cluster:

How to set up NLB – a Youtube video

Let’s add some information to the setup process:

In the New Cluster: Host Parameters window you can choose the default state of the host when it comes online: started, stopped or suspended. Started is a good option of course. The ‘Retain suspended state after computer restarts’ checkbox is asking you if the host should be put into a suspended state in case it is rebooted. This is an interesting feature: say that you need to update one of the hosts and the updates require a machine restart. You may not want the host to jump back online again as the changes you made may be breaking ones that need to be tested first.

In the same window you can set the priority of the cluster member. Normally the first one you create will have priority 1, the next one will be priority 2 and so on. Keep in mind that the servers normally function as peers to each other so the default 1,2…n increments are fine.

In the New Cluster: Cluster Parameters window you need to select the Cluster operation mode: unicast, multicast or IGMP multicast. Normally it’s going to be unicast but in a virtual environment you’ll probably need to select multicast. If your network supports multicast then either of the multicast types will be the best solution. Make sure to ask your network engineers in the office if you’re not sure which option is applicable to you.

In the same window you can add a Full internet name. This is optional, you can even leave it blank. It gives you an administrative name for the NLB cluster.

In the New Cluster: Port Rules window you can define which ports will be balanced:

NLB port rules

Click ‘Edit’ and the Add/Edit Port Rule window will open:

NLB port rules

As this is a web farm you may as well choose to load balance port 80 only so set 80 in the From and To port range option:

NLB from port 80 to port 80

We are dealing with TCP so you may as well select TCP from the Protocols options:


In the same window you select affinity under the Filtering mode options – this becomes available because we select the Multiple host option as we have 2 hosts as opposed to the Single host option. The choices for affinity are none, single or network. Normally the default choice is None. This means that when a request comes from the certain IP address and we get a new request from the IP address then we don’t care which web server the client is routed to.

This is what you should aim for: no sticky sessions. You can store the session state on a different machine – this is a topic I’ll take up in this series on web farms. Avoiding sticky sessions makes load balancing more effective. With sticky sessions the load balancer is constrained to direct the same user to the same web server even if that server is under heavy load so we lose some of the efficiency of load balancing. The option ‘Single’ means that the user with the same IP address should always be directed to the same machine. The ‘Network’ option is the same as ‘Single’ but for a subgroup of users. This last option is very rarely used.

You can add another Port Rule for SSL: the From and To Port Range options will be set to 443.

All requests coming to a port not defined in this window will be ignored because NLB will not know how to load balance it.

Now you can press finish and the NLB manager will start creating our cluster. You’ll see that the status is Pending at first:

NLB cluster creation pending

Eventually the status will change to Converged which means we can add a new web server: right click the cluster name, which should be the name you provided in the Full internet name text box, and choose Add Host to Cluster which will lead you through the same windows as when you set up the first node above. Many values such as the port rules will already be populated based on your previous entries. The NLB manager will add this node to the cluster when you’re finished setting it up.

At the end of this process you should see two Converged web farm members in the NLB manager window. You can verify the setup by pinging the name of the cluster you chose in the Full internet name text box. Enter the following in the command prompt: ping
You should see that it answers with the IP of the cluster that you see in the NLB manager, e.g. nlb.mysite.com (123.456.789.10). You can now also navigate to nlb.mysite.com in a web browser and it will probably take you to the first priority web farm member, but this is not for certain: NLB can of course route the request to whichever member in the cluster. In case you set up the system with affinity then you should see that you get to the same cluster member upon subsequent requests.

Keep in mind that NLB has no concept of health checks so it will route to any member of the web farm regardless of the state of the members. Even if a bad server responds with a 503 NLB will not take any note of that and will happily route the request to that machine. This is especially harmful if you’ve set up affinity and the user is always directed to the same machine in the immediate future.

You can easily temporarily remove a cluster member, e.g. if you want to perform some patch on it. Right-click the cluster member node in the NLB manager, click Control Host and select Stop or Drainstop. Stopping means that the node will not accept any connections. Drainstop means that the node will not accept any new connections.

In the above scenario with 2 web farm members stopping one of the two nodes will make NLB route all the web traffic to the one available machine. That’s basically a very simple solution for high availability. NLB handles server failures automatically – when one fails then it does not take part in the decision process on which server should handle the request.

This concludes the introduction to NLB. In the next post we’ll look at ARR.

About Andras Nemes
I'm a .NET/Java developer living and working in Stockholm, Sweden.

3 Responses to Web farms in .NET and IIS part 2: Network Load Balancer

  1. Pingback: Web farms in .NET and IIS part 3: Application Request Routing ARR | Prashantsinh's Gadaria Blog

  2. givini says:

    I am trying to set load balancing with IIS ARR but getting this error when I try to login, It works find if I test it outside ARR

    Server Error in ‘/’ Application. No owin.Environment item was found in the context. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: System.InvalidOperationException: No owin.Environment item was found in the context.

    Source Error:

    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

  3. kiquenet says:

    Whats about Failover Cluster in Windows Server 2012 R2 (https://docs.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster) and Session ASP.NET ?

Leave a Reply to kiquenet Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog


Once Upon a Camayoc

Bite-size insight on Cyber Security for the not too technical.

%d bloggers like this: