How NLB will work with IIS-7 web services?

Question

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!

Answer 1

Short: NLB doesn't care.

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

As long as the network 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 that matches its port rules.

Every node has to 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.

• 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 to explode in a shower of sparks)
• 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, 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 sensitivity, 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 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 run NLB underneath the ARR boxes.

Answer 2

• 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.