Chapter 4. Reporting Services Deployment Scenarios

In This Chapter

• High-Availability Deployment Considerations

• Internet Deployment Considerations

• Minimum Hardware Requirements

• Software Requirements

• Key Features of SSRS by SQL Server 2005 Editions

• Licensing

This chapter provides an overview of Reporting Services deployment scenarios (including Internet deployment), discusses SSRS' hardware and software requirements, licensing, and security around Reporting Services deployments. More technical details of security are covered in Chapter 18, "Securing Report Server Items."

An example of SSRS deployment is depicted in Figure 4.1. When an administrator installs SSRS, she has a choice to install one or more client- and server-side components outlined in Table 4.1.

Figure 4.1. Deployment scenarios.

Table 4.1. Reporting Services Deployable Elements

Component	Approximate Size (MB) 32-bit Platform	Typical Install Location Prerequisites	Notes
Report Designer	105	Developer's Workstation, Visual Studio 2005, .NET Framework	Visual Studio 2005 add-on that enables visual development and publishing of reports
Business Intelligence Development Studio (BIDS)	20	Developer's Workstation, .NET Framework	Visual Studio 2005 shell that includes only Business Intelligence projects
SSRS administrative utilities	1	Server/Client, .NET Framework	Configuration and scripting utilities
Books-On-Line	100	Server/Client	Help file with many useful development- related materials and code snippets
Report Server	60	IIS Server, .NET Framework	Integrated set of Windows and web software component that processes and delivers reports
Report Manager	9	IIS Server, Report Server, .NET Framework	Web-based report management and viewing tool
Report Server catalog	Initially empty database, final size depends on the number of reports deployed, caching, and snapshot settings	SQL Server 2005 standalone or cluster	Combination of two databases that store report definitions, settings, caching data, and so on

Note

Although the test (staging) environment might not be as "powerful" as production, it is best to have a total match for the most effective and realistic scalability testing.

In the Enterprise Production Environment, support for web farms and scale-up capabilities of Enterprise Edition comes in very handy for high-volume reporting. Web farm deployment is very flexible and allows administrators to add capacity to a Report Server web farm as demand grows. In addition, if one of the servers in the web farm fails, the remaining servers will pick up the load. Thus, a web farm provides high availability for a report processing layer, but not the SSRS catalog.

To achieve complete high availability for a reporting solution, a company can install a Reporting Services catalog on a SQL Server 2005 cluster.

For an environment that does not have high performance or availability requirements, you can simplify deployment and use a single Report Server instance with a catalog placed in a nonclustered instance of SQL Server 2005.

You can further simplify deployment in a development environment, install all the Reporting Services components on a single server, and install development tools on a set of workstations.

If a developer or a user needs to be completely mobile, he can install all the necessary components and a subset of data sources on a laptop, as depicted in the Development Environment box in Figure 4.1.

Note

There is no separate Books-On-Line for SSRS. Books-On-Line covers all the SQL Server 2005 components: Reporting Services, SQL Server engine, T-SQL, and so on .

SSRS is a fairly memory- and CPU- intensive application. It is hard to be precise with the exact hardware configuration that an administrator might need for her installation. Table 4.2 presents approximate CPU needs that depend on the number of concurrent users.

Table 4.2. Estimates of Reporting Server CPUs Needs

Concurrent Users	Approximate Number of CPUs
<150	1
<700	2
700 > <2000	4-8
2000> <4000	8-16
4000>	16+

Table 4.2 provides estimates for a 3-GHz 32-bit Intel Xeon CPU server and is based on SSRS performance for rendering a report of an average layout complexity, which retrieves approximately 5,000 rows of data from a data source, and provides users with HTML output and reasonable completion times of no more than 25-30 seconds. The data source used in this analysis is well tuned and available without significant latency.

Please keep in mind that your results will likely be different from the result in the table. A test is the best way to determine precise configuration needs that are the best suitable for your deployment scenario.

Configuration tips that you might want to consider when deploying SSRS (or specifically a Report Server) are as follows :

1. A 32-bit instance of a Report Server can use memory up to 3GB (requires the /3GB switch in boot.ini). Because of this, efficient hardware use would be at 4GB per instance (3GB for a Report Server and 1GB for OS). To effectively utilize servers with larger amounts of memory, consider installing multiple instances of SSRS per server.

2. For performance, start with scaling up ( fastest CPU available, 4GB of RAM, and capable IO subsystem), then move to scale out, and add capacity as necessary (add Report Servers to a web farm). Host the Report Server catalog in a SQL Server instance on a separate box from your data sources (transactional, data warehouse, or line-of-business database) or at least make sure that a SQL Server instance can handle additional workload.

3. For scale-up scenarios, SSRS 2005 supports a 64-bit platform for both x64 (Opteron, Athlon64, and Xeon EMT64T CPUs) and IA64 (Itanium CPU). A 64-bit platform overcomes the 4GB memory limitation of the 32-bit platform and should be considered for reporting applications with high memory demand. A reporting application that renders a fair amount of or large Microsoft Excel or PDF reports is an example of a high memory demand application.

4. For reliability, use redundant components: at least two SSRS web servers and a database cluster for the Reporting Services catalog database, redundant disk arrays, and network pathways . Although high availability requires at least two servers, three is a better number. With three servers, you can do maintenance on one of the servers and still have a high-availability configuration running in your environment.

5. For cost evaluation and decision about buying more servers with a smaller number of CPUs versus fewer servers with a larger number of CPUs in each, consider the price of the hardware, the additional costs associated with extra servers, and the cost of a reporting solution failure. As the number of servers grow, so does the server management overhead and other costs, such as cost of additional space, cooling, and energy costs.