High Availability for SQL Server Reporting Services 2014 (SSRS)


Situation:

One of my client has a scale-out deployment of SSRS 2014 reporting services. They have two SSRS servers that are connected with the single SQL DB Server. However, reporting services URL were not configured on NLBs, therefore, every time there is an issue with any of the report server, users need to use second server URL to view the business reports.


Solution:
Network load balancer(NLB) can be use for providing the high-availability across the SSRS deployment. NLB allows us to use single URL to access reports from any of the report server and also its provides load balancing across the report servers. NLB solution can be hardware based or it can be software based. Let's take an example of below typical NLB configuration for Reporting services:




Two scale-out deployments of SSRS hosts SSRS01 & SSRS02 are connected with SQL Server DB server. Both host share the single reporting database through this DB server. Without the NLB configuration, users will be able to access the same reports from their reporting URLs. i.e. http://ServerSSRS01:80/Reports and http://ServerSSRS02:80/Reports. However, the problem with this deployment, if one of the server is down then users will not be automatically routed to the second URL and additionally, this configuration does not support load balancing as well.  

NLB provides us a flexibility to configure a single URL http://reportingService.mydomain.com that point to both the reporting service URLs. This NLB configuration allows us to reach all connected SSRS servers through the single IP. If one of the server fails, all incoming requests will be diverted to remaining LIVE servers. This design would ensure that all critical reports will be available 24x7 for business users and decision makers. 



Comments

Post a Comment

Popular posts from this blog

Property Size is not available for Database '[tempdb]'

Image
Situation: Many times, DBA try to view the TEMPDB properties but they get the following error: The user is unable to view the TEMPDB property even if he has proper rights on the SQL Server instance. In fact, sometimes SYSADMIN role user is also unable to view the property and getting the same error. Solution: For user databases, this error can be resolved by changing the database ownership. We can run this command to check the Database ownership: sp_hepldb 'database name' user databases ownership can be SET by using the following command: USE 'db name' go sp_changedbowner 'sa' However, you can not change ownership of SYSTEM databases (tempdb, master, model & msdb) through the sp_changedbowner command. 'sa' is the default owner of all the system databases. I workaround this problem and found that this error frequently arises when tempdb is highly utilised and lots of contention is there on tempdb. In this scenario, SQL server...
Read more

Split backup files for faster SQL Backups

Image
Situation: SQL backups for large database are always be a challenging task. Depending upon the available system resources, a typical 5 TB database backup may take 6 - 7 hrs to complete. In addition to this, it is very difficult for DBAs to copy a single large backup file over the network. Solution: SQL Server provides a flexibility to split single backup file to multiple files. This would allow SQL server to split the workload by creating multiple threads. The advantages of this is backups will run faster and creates smaller files that can be easily copied across the network. Additionally, in most of the cases, Database administrator takes compressed backups which reduce the backup file size. However, for large database backups, overall backups time would be large as SQL server uses single thread to complete the backup operation. In a critical production environment it is always be a requirement to complete the backups before business starts next day. This would ensure the succe...
Read more

Resolve SQL Server I/O bottleneck issues

Image
Situation: Nowadays, most of the SQL Server environment is running on virtualized environment.  VMWare, Hyperviser, Xen, Elastic compute cloud etc. are the most popular virtualization platform available in the market. As per the recommended best practice, we should have separate dedicated drives for  SQLTemp, SQLData, SQLLog, SQLBinary & SQLBackups. All these drives should be presented as individual LUNs to provide the best I/O throughput to the SQL Server. In-spite of implementing these best practices, SQL Server frequently encounters disk I/O latencies issues in most of the environments. We can see following error in the SQL Server error logs: SQL Server has encountered xxx occurrence(s) of I/O requests taking longer than 50 seconds to complete on file [D:\MSSQL\MSSQL.1\MSSQL\Data\MyProdDB.mdf] in database [database].  The OS file handle is 0x00000000.  The offset of the latest long I/O is: 0x00000000000000 Solution: There are many...
Read more