2

Background

We are testing a pair of Windows 2008 R2 (IIS 7.5) web servers in conjunction with a hardware load balancer (external device) that splits port 80 traffic coming into a Virtual IP between the 2 servers.

There is a test website set up on both servers (each server has a duplicate copy). There is an address to access the site through the VIP, another address to access the site directly on server #1 and another for server #2.

In IIS, on both servers, the bindings are set up as follows (I am using a Shared Config, which is why both servers have all the bindings needed for both):

Type   Host Name                       Port   IP Address
HTTP   address-resolving-to-server-1   80     Public-IP-of-server-1
HTTP   address-resolving-to-server-2   80     Public-IP-of-server-2
HTTP   address-resolving-to-VIP        80     Public-IP-of-server-1 *
  • This might not be the right binding to allow traffic coming through the VIP to be split across the servers, but at least it was allowing the site to come up on the VIP.

Up until today this has been working fine – the test website could be accessed through all 3 addresses.

Reporting Services 2008 R2 is installed on both servers. The configuration has not been altered since running the installation wizard. The binding of the Report Server and Report Manager looks like this:

IP Address: All Assigned (recommended) TCP Port: 80 SSL Cert: none

Reporting Services is also working fine.

The Problem !!

A change was made in the configuration of Reporting Services on server #1, and since then the test website cannot be accessed through the load balancer. Web clients hang for about 30s, then return a 502 - Connection Failed error.

Accessing the test website directly on server #1 and directly on server #2, still works.

This is the configuration change that was made in Reporting Services:

Under the Report Server (Web Service URL) section, we clicked Advanced and edited the existing HTTP Identity record, and changed it from listening on “All Assigned” IP addresses to a specific Host Header Name (the NETBIOS name of the server).

Immediately after making this change, the test website could no longer be accessed through the load balancer, however it could still be accessed directly on server #1 and directly on server #2. Reporting Services continued to work after the change.

We set the configuration of Reporting Services back to the original settings, however the problem persists.

We have tried restarting all IIS related services, and even restarting the server, but this has made no difference.

There are no relevant errors in the Windows System or Application logs that we can see.

I think this issue must have something to do with "URL reservations" as described here but I am really confused why setting the RS binding back to the default has not fixed the issue. It seems like RS has permanently hosed the server!

3
  • What do the other bindings on IIS sites look like? Do you have the ability to capture traffic, to see what the load balancer is sending that's different from what direct access clients are sending - or even if the load balancer's communication is received at all? Commented Mar 1, 2012 at 0:43
  • There is only 1 test site, and the bindings are as above. I have checked the IIS logs, and since the issue there are no entries for requests using the address that goes through the LB, only requests using an address that directly hits a server.
    – Laurence
    Commented Mar 1, 2012 at 12:38
  • Did reporting services create its own site and bind, though? Commented Mar 1, 2012 at 16:38

1 Answer 1

0

Figured it out! It wasn't a directly a Windows, IIS or Reporting Services issue. Here's the answer in case it helps someone else:

The load balancer has a "health check" monitor built in that periodically checks it can access a particular file through the Default Website. The reconfiguration of RS must have caused the Default Website to be shut down (I guess because both RS and the Default Website were configured to listen on the same Host Header, IP and Port, and RS was chosen as the "winner").

So the load balancer health check started failing and automatically shut itself down! No traffic could go through it any more.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .