Planning a Deployment Topology
SQL Server 2008 Reporting Services (SSRS) offers several approaches for deploying server components. The following sections in this topic provide an overview of deployment topologies for Reporting Services in both native mode and SharePoint integrated mode.
Note
The diagrams in this topic do not include deployment configurations with Windows SharePoint Services (WSS) 3.0 or Microsoft Office SharePoint Server (MOSS) 2007. However, you can use the same deployment topologies shown in this document by configuring either WSS or MOSS on the same computer as your report server or servers, or by configuring WSS or MOSS in a separate application tier. For more information about planning for SharePoint integration and considerations for SharePoint deployment topologies, see the Planning for SharePoint Integration section under this topic.
Hardware and software requirements are an important consideration for planning your deployment topology. These requirements affect the components that you run on your server. In addition to reviewing the deployment topologies in this topic, use the information in Hardware and Software Requirements for Installing SQL Server 2008 and Estimating Report Server Database Requirements as a guideline for the requirements to run Reporting Services.
The report server databases in the following diagrams represent the reportserver and reportservertempdb databases that Reporting Services uses to store metadata and object definitions. Report data can come from other databases or data sources on the same computer that hosts the report server databases or from other computers. For more information, see Report Server Database and Data Sources Supported by Reporting Services.
Single Server Deployment
In a single server deployment configuration, the report server instance runs on the same computer as the Database Engine that hosts the report server database. The following diagram is an example of a single server deployment configuration.
.gif "Single server deployment configuration")
The single server deployment configuration is recommended in the following circumstances:
For small to moderate report volumes where demand for report processing is evenly spaced throughout the day and the number of concurrent sessions is easily handled by the processing capability of the computer.
When you are a developer and need to develop custom solutions that integrate with SSRS.
When you are evaluating the software.
This deployment configuration is the easiest to install and maintain. The default installation options result in this deployment topology. If you find that this deployment configuration meets the needs of your organization, you should continue with this deployment configuration, knowing that you can upgrade hardware or add additional server instances later if report demand increases.
Standard Server Deployment
In a standard server deployment, the report server instance runs on a different computer than the SQL Server Database Engine instance that hosts the report server database. The following diagram is an example of a standard server deployment configuration.
.gif "Standard server deployment configuration")
The standard deployment configuration is recommended in the following circumstances:
- For moderate report volumes where demand for report processing is evenly spaced throughout the day and the number of concurrent sessions is easily handled by the processing capability of the computers.
The standard deployment scenario offers improved performance over the single server deployment, because the report server and the Database Engine compete for processing resources such as CPU time, memory, and disk access when they are hosted on the same computer. Some report server operations are resource-intensive, so running the report server on a separate computer can reduce the competition for processing resources. Additionally, the footprint of a report server database might be small at first, but disk space requirements and I/O subsystem utilization can grow significantly at run time.
When you are deciding whether to choose a single server deployment or a standard server deployment, consider the following points based on your hardware configuration:
Processing resources
Memory resources
Disk space availability
I/O capacity
If you find that this deployment configuration meets the needs of your organization, you should continue with this deployment configuration, knowing that you can upgrade hardware or add additional server instances later if report demand increases.
Standard Scale-Out Server Deployment
In a standard scale-out server deployment, multiple report servers share a single report server database. The report server database should be installed on a remote SQL Server instance. The following diagram is an example of a standard scale-out server deployment configuration with the report server database on a remote SQL Server instance.
.gif "Standard scale-out deployment configuration")
Deploy Reporting Services in a scale-out deployment to provide a highly available and scalable report server installation. In a scale-out deployment, each report server in the deployment is referred to as a node. Nodes participate in the scale-out if the report server is configured to use the same report server database as another report server. Report server nodes can be load balanced to support high-volume interactive reporting.
A scale-out server deployment configuration is recommended in the following circumstances:
For high-volume reporting, where activity is measured in concurrent users or in the complexity of reports that take a long time to process or render.
For high-availability scenarios, where it is important that the reporting environment does not encounter unplanned downtime or become unavailable.
When you want to improve the performance of scheduled operations and subscription delivery.
Scale-out deployment is not supported in all editions of SQL Server. All report server nodes in a deployment must run the same version and service pack level of SQL Server. For more information about SQL Server 2008 editions, see Editions and Components of SQL Server 2008 and Features Supported by the Editions of SQL Server 2008. For more information about scale-out deployments and using Network Load Balanced (NLB) clusters, see Planning for Scale-Out Deployment under this topic.
As another option, you might decide to host the report server database on a SQL Server instance that is part of a failover cluster. The following diagram is an example of a scale-out server deployment configuration where the report server databases are on an instance that is part of a failover cluster.
.gif "Standard scale-out deployment with failover")
By hosting your report server databases on an instance that is part of a failover cluster, you can enhance the fault tolerance of your reporting environment. Failover clustering is also possible for standard deployments, but typically there is less need for failover clustering when the environment is not configured for high-availability scenarios, such as environments with scale-out deployments. For more information, see Hosting a Report Server Database in a SQL Server Failover Cluster.
Advanced Scale-Out Server Deployment
In addition to the standard scale-out deployment, you might determine that your reporting environment would benefit from a more advanced scale-out deployment configuration. For example, you might decide to use the load-balanced report servers for interactive report processing and add a separate report server computer to process only scheduled reports. The following diagram is an example of this advanced scale-out server deployment configuration.
.gif "Advanced scale-out deployment configuration")
This advanced scale-out deployment benefits from the same advantages as the standard scale-out deployment, but the environment is optimized for performance by separating the load balanced report servers, which handle interactive report processing, from a report server that handles only scheduled reports.
See Also