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