Right when I think there couldn't possibly be another option to think about with our new clustered ISA servers, I'm presented with one more fork in the road.
We just added two NLB'd IIS boxes. However, I didn't realize that ISA had a webfarm publishing feature and I'm looking for some opinions on publishing the NLB'd IIS boxes as a single server or breaking the nlb cluster and then publishing the servers as a web farm.
Advantages of one over the other seem subtle. The web farm route has cookie-based affinity which I'm not entirely sold on anyway since cookieless sessions may be in our future. The NLB'd IIS route would have a little better redundancy the odds of two servers failing at the same time isn't exactly high. Seems like a coin toss but maybe there's some administrative advantages that aren't obvious to me.
Yes, the HTTP connectivity verifier is better than the NLB mechanism on the Web Farm. The HTTP server could be down on one of farm members but the NIC is still alive, so NLB would still think that the array was intact, when in fact the service was down.
Thanks Tom, that's the option I took. Doing so greatly simplified site deployment to the two servers in that farm. I don't have to worry about multiple ips or ports (for ssl) on those boxes. Another option I liked is that when adding certificates to the listener, ISA confirms that the cert is correctly installed on all ISAs in the array - something else the NLB'd webservers wouldn't do for you..
Ok I did end up finding probably the most important reason (to me) for NLB'ing IIS rather than using an ISA web farm -uniformity between standalone ssl sites and NLB'd ssl sites. If you host your ssl certificates on the ISA server and you publish your servers as a farm, you must either A)create an internal cert for each server in the farm or B)bridge https to http. Both cases present problems from a programmability standpoint. In asp.net, the Request property, IsSecureConnection, can be used to see if the current request was made over ssl. In case B, this property will always be false since the webserver never sees more than an http connection from ISA. In case B, even if you bridge https to https connections, link translation is occuring. In our case we were redirecting to ssl when ssl is not detected. Several hours and an http sniffer later we discovered that we were experiencing the endless loop found here - http://support.microsoft.com/kb/924373.
While there are work arounds, at this point we were way beyond the little bit of port/ip configuration that came with simple server publishing rules and an NLB cluster. And even if that weren't the case, I was definately looking to avoid special development considerations just for a farm. Ideally an asp.net site will run the exact same on the NLB cluster as it would on a stand alone box.
Eh I'm still fighting with it Tom so if you have any suggestions, I'm all ears.
Here's where I'm at. I did re-enable nlb on the custer and I have a server publishing rule for https, mapping port 443 to 8443 on the server. No I'm not using the orginal client ip address as it looks like this would require bi-directional affinity (I received a publishing rule error and an NLB warning). SSL is working fine but I'm still having the endless loop problem even though the following condition is not met in my case (from the kb article...):
• You create a Web publishing rule for the Web server that redirects HTTP requests to HTTPS.
On the web publishing rule, I'm NOT redirecting to https.
Ok the only thing that ended up working is the "do nothing" mapping. Disabling global link translation did not work. This is a pretty ugly hack IMO - I can see this being a cool feature WHEN YOU NEED IT, but to do it to all sites by default is pretty silly. I guess I'm stuck adding a "do nothing" mapping for each one of my ssl sites.
Arg! Very confusing. If you think this represents a bug, you should give PSS a call. They won't charge you for it if it turns out to be a bug, and you'll help them with the core design as we proceed to the Forefront Threat Management Gateway.
From: United Kingdom
I also run into issues when the published servers need to run a protocol that is not web based - in this scenario ISA cannot use WPLB and hence you need NLB on the backend servers to provide fault tolerance. Exchange POP3/IMAP is a good example of this type of need.
However, I see no reason why you can't get the benefits of WPLB and *still* have NLB on the published servers. In this way, ISA provides the intelligence for web based services, but NLB provides LB and HA for other non-web services.
You bring up a good point, and something we should take to the product team. I've had several people ask about having the same kind of ISA based load balancing for non-Web connections. I think it's a great idea, but I don't know if we have time for it to be included in the RTM version of the TMG next year.
Tom, I considered contacting technical support, but considering there's already a kb article that makes no admittance of a bug, I didn't think that would get me anywhere.
Jason, Ironically I am actually using a farm for http traffic and a server publishing rule with nlb for https traffic, but I'm not sure I'll keep it that way. I'm leaning towards a simple web publishing rule for the nlb for simplicity. I guess I'll just have to weigh the pros and cons of it.