Planning for Scale-Out Deployment
A report server scale-out deployment is two or more report server instances that share a single report server database. A scale-out deployment enables you to increase the number of users who concurrently access reports and improve the availability of the report server. By using this deployment topology, it is recommended that you configure report server instances with identical settings, although it is not required. You can configure each server for specific capabilities and run them as independent instances, such as when you might want to isolate interactive report processing from scheduled or subscription report processing.
The following list summarizes the scenarios supported in a scale-out deployment:
Run report server instances in a load-balanced solution to support high-volume, on-demand reporting.
Increase the availability of the report server.
Isolate service features on specific computers to allow for maximum use of all available system resources, yet still store and retrieve the same data from the same report server database.
The following requirements apply to a scale-out deployment.
Requirement |
Description |
|---|---|
Edition requirements |
Scale-out deployment is supported in the following editions: Enterprise, Developer, and Evaluation. Standard, Workgroup, and Express editions do not support a scale-out deployment. |
Version requirements |
All of the report servers must be the same major version, and they must have the same updates and service packs. |
Domain requirements |
All of the report servers must be in the same domain or in a trusted domain. |
Authentication requirements |
Report server instances in a scale-out deployment must have the same type of authentication extension. If you created a custom authentication extension, you must deploy and use that extension on all nodes. You should configure the same authentication types on each node in a scale-out deployment. Because of this restriction, you cannot configure a scale-out deployment to support simultaneous intranet and extranet access to the same report server database through separate report server instances where each instance is configured for different authentication types and authorization rules. The reason for this restriction is that Reporting Services does not synchronize custom permission settings between the different authentication types. If you break permission inheritance and create role-assignments on specific items, access-denied errors will occur when the item is accessed by a user who was authenticated through the other authentication provider. To work around this issue, you would have to duplicate every item-specific role assignment through both servers to get dual security policies for both authentication extensions. This labor-intensive and error-prone practice is likely to result in access-denied errors. For this reason, the scenario is not supported. |
The remaining sections in this topic provide more detail about supported scenarios.
Scale-out Deployment for Load-Balanced Solutions
After you configure a report server scale-out deployment, the report server nodes can be load balanced in a Network Load Balanced (NLB) cluster to support high-volume reporting. You can use a software or hardware solution to implement the NLB cluster. Deploying Reporting Services in an NLB cluster is only necessary to increase the responsiveness of the report server or to increase the number of interactive reports that can be processed concurrently. Scheduled reports and subscription processing are faster on a scale-out deployment, but do not require an NLB cluster to get faster performance.
To create and configure the NLB cluster, you must use software and tools that support that functionality. There are load balancing features in Microsoft Windows Server operating systems and in third-party applications. By itself, Reporting Services does not provide load balancing features or the ability to define a single virtual server URL to access multiple report server nodes. The hardware or software solution you select must provide a way to define a virtual server name that provides a single point of entry to all the nodes in a report server scale-out.
Reporting Services is not aware of Microsoft Cluster Services. If you use Microsoft Cluster Services, review the following information:
If Reporting Services runs on an Active-Passive cluster with Microsoft Cluster Services, the Report Server service runs and handles requests on each cluster node on which the service is deployed.
When a report server database is hosted on a SQL Server that is part of a failover cluster, the report server must be configured to use the virtual name of the failover cluster to connect to the report server database. Otherwise, the report server will be unable to connect to the report server database when a failover occurs.
You cannot deploy a report server on Microsoft Cluster Services through SQL Server failover clustering. However, you can install the report server with the files-only option during a SQL Server installation.
To configure your deployment
Configure two or more servers to run in an NLB cluster.
Configure a separate server to host the report server database.
Install and configure a report server scale-out deployment by installing a report server instance on each node in the NLB cluster. For more information about how to install the report servers and join them to a scale-out deployment, see How to: Configure a Report Server Scale-Out Deployment (Reporting Services Configuration).
Configure view state validation and check report server configuration. For more information, see How to: Configure a Report Server on a Network Load Balancing Cluster.
On each node in the scale-out deployment, configure the Hostname property of the report server to use the URL name of the NLB. This step configures the URLs that are generated by the report server to point to the NLB instead of a specific server. For more information, see How to: Configure a Report Server on a Network Load Balancing Cluster.
Scale-out Deployment for Improved Performance of Service Features
One technique for improving report server performance is to configure a scale-out deployment that assigns specific types of processing to each report server. For example, you can configure one report server to handle scheduled report and subscription processing and a second report server for interactive reporting. Because the report servers run in the same scale-out deployment, each server processes the same set of reports.
To configure your deployment
Install and configure a report server scale-out deployment. For instructions, see How to: Configure a Report Server Scale-Out Deployment (Reporting Services Configuration).
On the server that is used for interactive reporting, turn off scheduled report and subscription processing.
On the other server that is used for background processing, turn off the Report Server Web service and Report Manager.
For more information about how to turn off specific features, see How to: Turn Reporting Services Features On or Off.
Issues to Consider with Scale-out Deployments
Different versions of the operating system support different cultures and collations.
If your scale-out deployment includes computers running different versions of the operating system, they may also support different cultures and collations. This may result in inconsistent reports or report errors when reports are being processed and rendered.
When designing a report, the report author can configure properties of the report or report objects that affect the culture that is used when processing and rendering the report. This can result in inconsistent data in reports or errors because different versions of the operating systems support different cultures and reports may not consistently be processed by the same server in a scale-out deployment.
For example, your scale-out deployment may include a Windows 2003 server and another that is Windows 2008 server. In a scale out deployment, Reporting Services assumes your networking environment will use software or hardware to load balance requests to the different servers. However, Reporting Services does not require or assume your load balancing solution is directing all the requests in a particular user's session to a single server. The load balancer is free to send one page request to the Windows 2008 server and the next page request to the Windows 2003 server. In this example, a report being processed relies on a collation that is supported on the Windows 2008 Server but not the Windows 2003 server. This inconsistent availability of the expected collation during report processing and rendering may cause inconsistent report results. The following are some examples of the symptoms you may experience:
Report processing that needs to perform additional grouping, sorting, or filtering may use the incorrect collation for comparisons leading to incorrect results.
The HideDuplicates functionality might use the wrong collation, resulting in incorrect results for hidden and shown values.
The Lookup, LookupSet, and MultiLookup functionality might use the wrong collation, resulting in incorrect results.
Any property that interacts with culture and language can be affected by processing on different operating systems. The following is a list of some, but not all of properties that are affected:
The language property of a report
The collation property of a dataset
The LableLocId and ValueLocID properties of report items
To work around the issue, consider any of the following:
Use the same version of the operating system on all servers in your scale out deployments
If you have different operating system versions, only use cultures in your report authoring that are use supported on all servers.
Setup affinity in your load balancing solution so that all requests for a particular report and user session go to the same server.