Setting up Availability group for report server databases

Question

I am reading msdn article on using SSRS with AG and have few doubts on setting up the same:

• Server A - Will host Report Server services with scale out deployment
• Server N1 - Node 1 with ReportServer and ReportServerTempdb database serving as primary replica
• Server N2 - Node 2 is secondary replica of the ReportServer and ReportServerTempdb

Above nodes will be part of multi-subnet cluster with N1 in DC1 and N2 in DC2.

I am thinking to create the listener first with 2 IPs for those multi-subnet so that we can use same while installing reporting services and point the listener name in instance and it's report server database to it so that it is aware of primary replica even after fail-over.

Is my above understanding correct? Is that how it's suppose to work?

Secondly, document says automatic fail-over is not supported even when I use sync mode between N1 and N2? Is that true? And why would that be the case only with SSRS? Also if it is, can we automate the fail-over or does it have to be manual every-time since I am thinking data source application string can use the option MultiSubnetFailover=true ?

Appreciate your inputs.

Answer 1

The reason the documentation states that automatic failover is not supported is that there are post-failover tasks that must be carried out to ensure the Report Server is completely online. See this section for information on exactly what tasks need to be completed. Essentially it boils down to needing to stop the SQL Agent on the old primary and restart the Report Server service.

I am thinking to create the listener first with 2ips for those multi subnet so that we can use same while installing reporting services and point the listener name in instance and it's report server database to it so that it is aware of primary replica even after failover. Is my above understanding correct? Is that how it's suppose to work?

Yes, build your AG and configure the listener first, then when you'r configuring the report server you can point it at the listener.

Secondly, document says automatic failover is not supported even when I use sync mode between N1 and N2 ? Is that true? And why would that be the case only with SSRs? Also if it is , can we automate the faiover or does it have to be manual everytime since I am thinking data source application string can use the option multi subnet failover = true ?

There seems to be some crossover here where you're talking about report data sources and Report Server databases. RS databases are the databases used by report server to manage and maintain the report server. They're typically named ReportServer and ReportServerTempDB. These databases do not support automatic failover because there are post-failover tasks you must complete to bring the service back to a 100% normal state.

These tasks can be automated through scripts easily enough, but that is is what the documentation means by not supported. For your report data sources, these only need AG specific parameters in the connection string (such as MultiSubnetFailover or ApplicationIntent) if the source databases are in an AG as well. If they are then adding those keys to your connection strings will ensure the reports continue working post-failover. They should handle failover automatically.

Something to note is this line from the documentation:

The use of MultiSubnetFailover, with the report server databases, is not supported.

What this means for you, given you have a multi-subnet cluster, is that you should set the RegisterAllProvidersIP setting to 0. This setting is 1 by default and means that each IP assigned to the listener is registered in DNS. If MultiSubnetFailover is enabled, the client will try to connect to each IP in parallel and return the connection from the first IP that responds. As this setting is not supported by the RS service for connections to the RS databases, after a failover you will likely encounter timeouts trying to connect.

The solution is to set RegisterAllProvidersIP to 0 and set a low TTL for that host record. This ensures that only the active IP is registered with DNS for the listener, and after failover the new IP is registered with DNS. This means new connections to the listener use the correct IP and you avoid timeouts.

Answer 2

why would that be the case only with SSRS?

As addition note to the Handy's answer, one of the main reason, SSRS dependencies are not only in ReportServer and ReportServerTempDB databases, but also on SQL Server Agent which host all the subscription configuration of the SSRS and which would not be a scope of AG replication.

So, you got covered ReportServer and ReportServerTempDB databases only by AG synchronization not the SQL Agent Jobs that are created by SSRS for each subscription (following is the sample screenshot of Agent Job that created by SSRS).

However, SSRS will re-create all the jobs on new primary replica (after fail-over event) but you must restart SSRS Service for this to happen.