Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We'are going to join 2 (two) IIS7 web-servers into NLB with the same web-service published (2 instances of the same web-service one per web-server).

  • Do I understand correctly, that NLB will work for my web-services, deligating web-requests to one or another instance?
  • How will NLB work if one of web-service instance becomes unavailable (i.e. starts to throw SOAP exceptions or HTTP errors)?
  • Will NLB take into account the average web-service response time to decide web-service instance to deligate processing?

Thank you in advance!

share|improve this question
up vote 3 down vote accepted

Short: NLB doesn't care.

NLB doesn't give a rat's donkey about your application. User-mode problems are so user-mode.

As long as the network stack is able to send and receive NLB broadcasts (or multicasts!), NLB will keep on accepting traffic.

Longer: NLB really doesn't care.

NLB runs as a Layer 2 NDIS filter, and simply runs its hash algorithm across all incoming traffic, and accepts the bits that match its port rules.

Every node must see all incoming traffic (multicast/broadcast by the switch), and every node drops packets that don't meet its hash criteria.

NLB is a statistical load balancer. Not a caring one.

  • It's not important to it that your app is throwing 500s.
  • It's oblivious to the fact that your user-mode listener process has crashed.
  • It's unaware that your app is running slowly.

It just. Doesn't. Care.

The best-case failure for NLB is for (one of):

  • the box to die completely from a power failure
  • the network cable to be cut or unplugged
    • (possibly by a vacuum cleaner)
    • (or the NIC exploding in a shower of sparks)
    • (or being stolen by a passing thief)
    • (or any form of physical network interruption)
  • the box to bluescreen

Any of these stop the network stack from processing incoming packets, and from sending "I'm alive!" broadcast messages to other NLB nodes, which causes the cluster to get all introspective for a little while (seconds), figure out what nodes are still present, and re-converge.

Then, when the remaining nodes are clear on how many of them there are, they'll start their hashing again, and drop any new packets they're not interested in.

If you need

  • health monitoring,
  • careful application of load to underutilized servers,
  • and response-time-based intelligent decisions

NLB is not the solution for you. If your app is OK with that, or knows enough about NLB to run NLB STOP when there's a problem at the app layer, then it's probably fine. But very few apps do that (ISA/TMG spring to mind).

Looks like I wrote about this a while ago here.

Looking Elsewhere If you're looking for a low-cost (read: free) Windows-based solution, consider Application Request Routing for IIS 7+ - it has most of the health monitoring features it sounds like you're looking for.

You wouldn't run it on the same box as the applications, generally, though, and for availability, you'd typically want to run NLB underneath ARR, to combine network-level availability of the load balancers with app-layer smarts at that level.

share|improve this answer
  • Edited to say my answer applies to generic network load balancing, not Microsoft's NLB service!

The answer really depends on how sophisticated your load balancer is. The simplest set up would be a load balancer sending requests to one web server on another on a round robin basis, and using ping to determine if a host was up or down.

You can use more complex health checks that your load balanced servers need to pass before they are put into the load balanced pool.

To perform a health check you would typically configure a page on your web server that is dependent on all aspects of your web server working. Perhaps some php that looks up something in the database and then writes 'OK' on the screen if everything worked. Then you would configure your Load balancer health check to look at this page and make sure it says 'OK'

If a health check fails, then the server than failed the check will be removed from the pool and no traffic will be sent to it. If all of your servers fail it is usually possible to have your load balancer serve a holding page.

Again depending on how sophisticated your load balancer is, you can use various load balancing mechanisms. You can indeed load balance based on server load, number of connections to the server, you can have some servers receive more load than others, you can have 'sticky' sessions whereby the same client is always sent to the same web server. There are lots of possibilities.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.