High Availability – Frequently Asked Questions about Failover Clustering and Reporting Services

In SSRS high availability is achieved through a Scale-out deployment that is placed behind a Network Load Balancer (NLB).  The NLB is then responsible for routing requests to Report Server nodes that are responding to requests. 

High Availability Documentation Reference: https://msdn.microsoft.com/en-us/library/bb522745.aspx

However, many customers are interested in using Windows Failover Clustering with SSRS, since this is how they deploy their SQL Servers.  This article discusses Windows Failover Clustering in regards to SSRS.

Windows offers built-in Failover Clustering capability.  SSRS does not natively support Windows Failover Clustering.  The use of Failover Clustering with SSRS service is possible using standard capabilities of Windows Failover Clustering; however it may not be desirable as explained below.

Standard features of Windows Failover Clustering include a Generic Service and a Generic Script cluster resource.  Each of these resources can be used in conjunction with SSRS to achieve failover during a server down situation.  The Generic Service cluster resources can be used to determine whether the service is running or not and to failover to another cluster node when the service stops running for whatever reason.  This option has the limitation that it will not detect service hangs.  The Generic Script cluster resource allows the IT administrator to monitor any desired attribute of the service (performance counters, response time, service started/stopped, etc.) to determine when to failover to another cluster node.    Using a Generic Script resource allows you to overcome the limitations of the Generic Service resource, at additional implementation cost.

Generic Script Resource: https://msdn.microsoft.com/en-us/library/aa373089(VS.85).aspx

Generic Script Resource Example: https://msdn.microsoft.com/en-us/library/aa372844(VS.85).aspx

When configuring a failover group, a Network resource (IP Address, NetBIOS name) is usually added to ensure that client machine configurations to not need to change in case of failover.  During an actual failover, the network resource is moved first to the new active cluster node, and then any other resources are moved based on the failover group dependency tree.    This means that during the failover there is some time during which users will receive errors when accessing SSRS since the network names will resolve to a computer where the SSRS service is in the process of starting.  This is expected given the design of failover clustering.

Though a failover clustered SSRS deployment is achievable, it may not be desirable.  There are a number of factors to consider:

a. Impact on other applications that share the SQL Server: One common idea is to put SSRS in the same cluster group as SQL Server.  If SQL Server is hosting multiple application databases, other than just the SSRS databases, a failure in SSRS may cause a significant failover impact to the entire environment.  This consideration should be carefully evaluated before deploying SSRS in the same cluster group as SQL Server.   We generally recommend that SSRS should be isolated from a high availability viewpoint from the SQL Server to minimize impact.

b. SSRS failing over independently of SQL Server:   Another idea is to put SSRS in a different cluster group as SQL Server.  When using this configuration after a failover different cluster nodes could be running SSRS and SQL Server.  If you use this configuration, ensure you have sufficient licenses to cover each cluster node with a running component of SQL Server (i.e. each RS server & each SQL Server). 

c. Scalability of SSRS: in a failover cluster, only one SSRS server is handling requests.  In the NLB scenario, multiple nodes are handling requests, which will result in increased capacity.  

Some additional considerations:

Passive SSRS server: Customers sometimes want to know what a ‘Passive’ SSRS server looks like, or how to tell that SSRS is ‘Passive’.   This has to do with the failover clustering licensing terms that come with the SQL Server box.   For SSRS, since we don’t implement a cluster resource ourselves, the way to make SSRS ‘Passive’ is to stop the SSRS service.   Reason for this that if SSRS is running, it is going to do work on behalf of the overall deployment so it will be ‘Active’.  So if you’re looking to get the licensing benefit of failover clustering for HA with SSRS, then you need to ensure that the SSRS service is stopped on all your passive cluster nodes.  

Scale-out availability in Enterprise Edition:   Customers sometimes discover that they need to purchase Enterprise Edition to have a scale-out deployment of SSRS.   This is important to know if you’re trying to build a failover cluster with SSRS.  SQL Server offers failover clustering support with Standard Edition.   This will mean that if you’re using Standard edition SSRS, you will need to handle the backup & restore of the symmetric key in the report server database in order to achieve a failover. This can be difficult since the symmetric key needs to be protected (it encrypts users names & passwords  stored in the report server database).  So you don’t want just anyone being able to get a copy of it and knowing the password used to encrypt the symmetric key itself.  Due to this, I would say that if you want to try to do a failover cluster deployment with SSRS, use Enterprise Edition. 

 

To summarize, failover clustering with SSRS is possible, though there are a number of considerations and manual steps involved on your part.  SSRS is designed to achieve High Availability through a Scale-Out architecture.  As our documentation and best practices point out, that is your best option for achieving High Availability with Reporting Services.

Take care and good luck,

-Lukasz