May 7, 2009 at 10:31 am
Hi,
I'm looking at upgrading a scaled out, balanced SSRS 2005 system to SSRS 2008.
The existing system consists of a switch which provides a single virtual URL for clients to connect to.
The switch forwards requests via HTTPS to one of two servers running IIS and SSRS 2005.
In turn the SSRS services both reference a single ReportServer database which sits on another server exclusively running a clustered instance of SQL Server 2005.
The switch itself is also mirrored, and in this way the entire system has no single point of failure.
It's important for the switch to be able to ascertain the state of the 2 SSRS servers. For example, if a server is inaccessible then there is no point in the switch blindly forwarding on requests to it.
This status check is accomplished by the switch polling via HTTPS for the presence of a single text file, present on the hard drives of both servers, and served up via IIS.
If IIS stops working, then the text file is not available to the switch, and the switch knows to re-route all traffic to the other SSRS server. This arrangement has proved effective.
Now.... with SSRS 2008 there is no IIS, SSRS uses HTTP.SYS for its web server requirements.
My question is, what would be the best way for the switch to judge the status of an SSRS 2008 server?
I can't see how the switch can check for a report, since access to SSRS requires AD authentication.
Can a text file be served directly up by HTTP.SYS ? This doesn't give the actual state of SSRS I know, but it's certainly a better option than the switch just PINGing the SSRS servers.
Anyone have any ideas of the best way to approach this?
Thank you.
May 7, 2009 at 7:55 pm
I would recommend checking out these resources if you have not looked at them already:
SQL Server 2008 Upgrade Technical Reference Guide - This 490-page document covers the essential phases and steps to upgrade existing instances of SQL Server 2000 and 2005 to SQL Server 2008 by using best practices. These include preparation tasks, upgrade tasks, and post-upgrade tasks. It is intended to be a supplement to SQL Server 2008 Books Online.
Scaling Up Reporting Services 2008 vs. Reporting Services 2005: Lessons Learned
Reporting Services Scale-Out Architecture
----------------------------------------------------------------------------------------
Dan English - http://denglishbi.wordpress.com
May 8, 2009 at 3:09 am
Thanks for those links Dan.
Although they make for very useful reading for my upgrade, there is nothing specifically in them about NLB.
The SQLCAT team ran their test with a single SSRS application server (so no NLB).
In a link on from that article they do have a diagram of an SSRS architecture using NLB, but they go on to say that round-robin is used to balance the load between servers.
Although this would work for load balancing, this would fall apart in a situation where one of the SSRS servers is unavailable, as a round-robin system will blindly continue to pass a proportion of client requests on to that AWOL server. There is no service availability checking taking place.
I'm surprised that more information isn't available on this subject. I'm going to look into this some more.
May 8, 2009 at 5:54 am
Then you might want to check out this documentation from BOL:
SQL Server 2008 Books Online (April 2009)
How to: Configure a Report Server on a Network Load Balancing Cluster
----------------------------------------------------------------------------------------
Dan English - http://denglishbi.wordpress.com
May 8, 2009 at 10:40 am
Thank you again for that, more interesting reading.
I think I'm now some way towards filling in the missing piece of the puzzle, I'll describe here in case anyone else hits this issue.
I eliminate the option of the NLB device just PINGing the SSRS servers because a response to a PING does not necessarily mean that the server is full up and available and that the SSRS service is active.
That leaves two options to explore, assuming that the SSRS servers are configured with SSL:-
1) Have the switch \ NLB device send an HTTP probe to the SSRS server and when it replies with a HTTP Code 304 (redirect to SSL), that code would be the successful probe result.
If HTTP were enabled on that server though then the probe would fail (as the 304 response isn't returned but 200 instead).
2) Check for port 443 (SSL) being open.
I'm going to test both methods and see which works best. I'll post the results here.
January 20, 2011 at 6:24 am
any luck.? Have exactly same problem. Your advise will be greatly appreciated.
January 20, 2011 at 7:40 am
Hi Ravindra, after some experimentation I did manage to get this working satisfactorily with our existing Cisco infrastructure.
It was possible to configure a probe (I believe that is the correct terminology in Cisco-talk) on the NLB device to scan both of the SSRS Servers on port 443 (SSL).
Obviously port 443 being open means that SSRS is available on that server; and port 443 not being available means that there is a problem and therefore the NLB should route all requests to the surviving node.
The probe continues to check both nodes even if one is not available and it is able to re-instate traffic once the node does become available again.
It all works perfectly.
After a lot of testing we've been running live on this setup for over a year now with no problems.
I guess if you are not using SSL, you could use the same approach but with port 80 (HTTP). Haven't tried this myself but I see no reason why it wouldn't work.
Hope that helps you Ravindra.
January 20, 2011 at 8:45 am
[font="Arial"]Hi Andy,
Thanks for the quick response.
Am using 80 ports intially for testing in dev
Problem is.
1. If we stop IIS admin and www service then our request are getting routed to other server/node.
2. If we stop only SSRS service the request are not getting routed to other server instead when we launch the report it fails.
And want to make 2 server Active-Active instead of Acive-passive.
CLB(cisco load balancer) setting: Round Bobin and port 80 is used to route. But all the request always go to only server. Tried from few other IP as well.
Any suggestion am i missing something.
Your response will be greatly appreciated
January 21, 2011 at 9:36 am
Hi Ravindra, are you using Reporting Services 2005 or Reporting Services 2008?
January 23, 2011 at 12:01 am
Its SQl Server reporting service 2008 Integrated with share point 2007
January 25, 2011 at 8:25 am
Ah right, I was confused why you had IIS running on the Reporting Services server along with the Reporting Services service.
Obviously IIS is not necessary for Reporting Services 2008, only 2005 – but I am guessing that the addition of SharePoint means that you need IIS on this server too.
It’s a bit more tricky this configuration as you’ve discovered.
If you have IIS on the server then you are quite right, the Reporting Services service could fail, IIS could keep running, and so your switch would think that everything was fine because it was still getting a response to probing port 80 which IIS was still holding open – even though the Reporting Services service is dead as a DoDo.
I didn’t have this problem to contend with since in all the Reporting Services deployments that I have worked with, the SSRS 2008 Servers only ever had the Reporting Services service running on them, nothing else.
I wonder, if your switch is particularly smart, could you configure it to check for a response to a probe to an actual URL. The URL would then need to be the URL to one of your reports.
This should work, if either IIS or SSRS services fail, the report won’t be served and the switch will know about it and act accordingly.
However I do think it is asking a lot of a switch to do this, whether you can configure this level of detail into a probe I don’t know I’m afraid. I’m suspecting not but might be worth posting a question on a Cisco forum to see if anyone there can advise.
Do let us know how you get on with this Ravindra, I wish you good luck.
May 24, 2011 at 9:07 pm
Andy,
Did you need to install a certificate (for SSL) on the Load Balancer server or did you only have to install it on the two Reporting Services boxes?
We are setting up a similar scale - out deployment on SSRS 2008 (native mode). We also have a very thin .NET application that sits in the DMZ and communicates directly with a Load Balancer SSRSNLB which in turn points to two reporting services boxes SSRS01 and SSRS02.
On the following article (http://msdn.microsoft.com/en-us/library/ms345223%28v=SQL.100%29.aspx) it mentions installing a certificate on each of the SSRS boxes however I cannot find any whitepapers on how to set it up in a load balanced environment. SSRSNLB is a cisco hardware loadbalancer.
Thanks,
Burzin
June 2, 2011 at 5:27 am
Hi Burzin,
When using https with NLB and SSRS, the trick is to create the certificate for the name of the NLB URL as opposed to the physical names of the servers.
So in an environment with physical servers RS-SERVER-A and RS-SERVER-B with a NLB URL https:\\ABC-Reporting what you would do is…
1)Create certificate for https:\\ABC-Reporting
2)Install this certificate on both RS-SERVER-A and RS-SERVER-B
3)Do NOT create and install a certificate for https:\\RS-SERVER-A or https:\\RS-SERVER-B
4)Manually edit the RSREPORTSERVER.CONFIG file to reflect the NLB’s URL. SSRS by default will configure itself to use the machine name like https:\\RS-SERVER-A\Reports - so just change this to https:\\ABC-Reporting\Reports.
A certificate does not get installed on the NLB, only the servers (at least with the CISCO device we used in my shop).
Hope that helps you.
June 4, 2011 at 12:19 am
Hi Andy,
Thanks for your response. I believe the difference between my setup and yours is that the SSRS load balancer is not in a DMZ but inside our corporate firewall. In your case the NLB is public internet facing and since it directly makes a call from the DMZ to inside the firewall your require the call to the individual SSRS servers to be encrypted hence the certificate and the https configuration.
We have a custom .Net application in the DMZ which calls the NLB URL with Https/443. We installed a certificate on the NLB although translated the incoming communication i.e. .NET app (DMZ) coming in over port 443 into an http port 80 communication to the SSRS servers.
I would like to share more about architecture we implemented with you. Here is my personal email burzind@gmail.com.
Basically from Front end to back we have a Cisco Load Balancer in the DMZ which points to two IIS .NET apps that provides a skin over SSRS. The two IIS web servers call the SSRS Load Balancer (inside firewall) using Https call. The SSRS load balancer in turn translates it to a simple http call to the physical ssrs boxes.
I should have a couple of high level diagrams if you are interested.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply