In a Microsoft Windows IIS environment that is load balanced, the external load balancing hardware needs to know which servers, in the pool of servers, are available to send http traffic to for a particular website.
The rule, shown below, is a built in rule that requires each IIS Website on each IIS Web Server to have a http://healthcheck
The load balancer will check each website using the http://healthcheck
host header and look for an alive.html web page. Upon being able to access that alive.html web page, the load balancer will continue routing traffic to that particular website on that particular web server for another 60 seconds.
Using this built in rule administrators only have to add a healthcheck host header to each IIS Website.
This built in rule eliminates any need for administrators to create a separate and distinct set of rules for each IIS Website on each Server using the websites own distinct name.
Now, enters SharePoint 2010 and how it is incompatible with this rule.
For the sake of an easy example, let us declare that we have three Windows 2008 R2 Servers that are running SharePoint 2010 Standard Server.
We will call them SPServer1, SPServer2, SPServer3, and they are configured as follows.
SPServer1 runs the Central Administration Console, and contains all SharePoint Websites. But end users never Access the SharePoint Websites here.
SPServer2 contains all SharePoint Websites and serves as one of the servers end users can access through the load balancer.
SPServer3 contains all SharePoint Websites and serves as one of the servers end users can access through the load balancer.
In this SharePoint 2010 Farm, we have a website called mytestsite.mytestdomain.co
On SPServer1, the IIS Bindings for http://mytestsite.mytestdomain.comcontain
only the site name mytestsite.mytestdomain.co
m, port 80, and a blank IP Setting so that “Any Available” is used.
On SPServer2, the IIS Bindings for MyTestSite.mytestdomain.co
m contain the following host headers:
mytestsite1 port 80 ip address 192.168.4.101
mytestsite1.mytestdomain.com port 80 ip address 192.168.4.101
mytestsite port 80 ip address 192.168.4.101
mytestsite.mytestdomain.com port 80 ip address 192.168.4.101
healthcheck port 80 ip address 192.168.4.101
healthcheck.mytestdomain.com port 80 ip address 192.168.4.101
On SPServer3, the IIS Bindings for MyTestSite.mytestdomain.co
m contain the following host headers:
mytestsite2 port 80 ip address 192.168.4.102
mytestsite2.mytestdomain.com port 80 ip address 192.168.4.102
mytestsite port 80 ip address 192.168.4.102
mytestsite.mytestdomain.com port 80 ip address 192.168.4.102
healthcheck port 80 ip address 192.168.4.102
healthcheck.mytestdomain.com port 80 ip address 192.168.4.102
Domain Wide DNS contains an A-Record mytestsite.mytestdomain.co
IP 192.168.234.100 is the IP Address that sits on the load balancer and what end users will actually access when they point their web browsers to http://mytestsite.mytestdomain.com
SharePoint 2010 has alternate access mappings for the website mytestsite.mytestdomain.co
m as follows.
• Internal URL – http://mytestsite
• Zone – Default
• Public URL for Zone – http://mytestsite
Having provided those details let us examine how the load balancer routes end users to the actual site.
1. An end user enters http://mytestsite.mytestdomain.com
into the address bar of their web browser software.
2. The web browser software queries DNS to find the IP Address of that website.
3. DNS reports the IP Address of http://mytestsite.mytestdomain.com
to be 192.168.234.100
4. 192.168.234.100 is an IP Address that has been allocated for access to http://mytestsite.mytestdomain.com
on the load balancer.
5. The user is then taken to the load balancer.
6. When their web browser “hits” the load balancer, the load balancer looks to see which servers are serving up http://mytestsite.mytestdomain.com
7. Since http://healthcheck/alive.html
is present and accessible on both SPServer2 and SPServer3, the load balancer will pass the end user through to http://mytestsite1.mytestdomain.com
8. However, it will make sure that the end user’s web browser thinks it (the web browser) is actually going to http://mytestsite.mytestdomain.com
9. This is web browser behavior is possible because the host header mytestsite and mytestsite.mytestdomain.co
m exist on both SPServer2 and SPServer3
10. This is what allows the URL http://mytestsite.mytestdomain.com
to remain present in the end user’s web browser’s address bar, instead of switching out to http://mytestsite1.mytestdomain.com
All the material listed above, explains how the environment works, and the purpose of http://healthcheck/alive.html
as it pertains to both SPServer2 and SPServer3.
The only problem with all of this, is that SPServer1, SPServer2, and SPServer3 continuously generate 1000’s of warning messages in the application event log.
Multiple warning messages are logged every couple of minutes as shown below, which obviously chew up space by making the log file larger while consuming processor resources.
IIS doesn’t generate the log entries, but SharePoint 2010 does.
Conventional logic dictates that the only way to fix this type of issue is to do one of the following:
1. Eliminate the host header http://healthcheck
from each IIS Website
2. Add a host header entry for http://healthcheck
onto SPServer1 in addition to the headers that already exist on SPServer2 and SPServer2 and then create an alternate access mapping for http://healthcheck
in each SharePoint Website.
Unfortunately, executing # 1 will break the functionality of the load balancer and will prevent end users from getting to the site.
Executing # 2 is not possible because of a SharePoint 2010 product limitation that does not permit the same alternate access mapping to exist within multiple websites.
3. The only other way to fix this problem and eliminate all the excess log entries is to create a separate set of load balancer rules for every SharePoint Website.
However, making a rule change of that magnitude in the load balancer is unacceptable because a SharePoint farm that contains millions of SharePoint Websites will require countless man hours to build out millions of load balancer rule sets, one set for each website name.
Such a rule change will result in millions of sets of rules being created which will overtax the performance of the load balancer.
4. The only other possible way to fix this problem and eliminate all the excess log entries from constantly occurring is to create a separate set of load balancer rules for SharePoint Websites and make use of some kind of site name/hostname variable, so that the load balancer can use some kind of site name variable header rule to perform the same monitoring process that the http_alive rule currently provides.
Such a Site Name variable rule might look like this ¿ GET /alive.html HTTP/1.1\r\nConnection: Close\r\nHost: <%sitename%>/healthcheck\r
However the load balancer rule shown above does not work, and no such construct is currently promoted or supported by the load balancer vendors I have dealt with.
The folks who developed SharePoint really need to make some kind of programmatic adjustment to account for this issue, or at the very least, provide a mechanism to prevent these types of warning messages from being logged.