Overview of Deployment Scenarios

SSRS has two main deployment scenarios. The first is possibly the simplestthe single-server deployment. In this scenario, a single machine is responsible for hosting both major components of SSRSthe database and the Report Server.

The second major scenario is the scale-out deployment, in which the database is on one machine, possibly a clustered virtual machine, and the Report Server is on another machine or on a web farm.

Advantages/Disadvantages of the Standard Model

The standard model, or single-server deployment model, might sound simple and easy to do at first, and it is certainly the way to do it for a development workstation, or a simple trial or proof of concept. However, you should consider a couple of things when debating whether to use this model in a production environment.

Performance Impact of the Standard Model

The primary consideration for most administrators after cost is performance. Having both the database and the Report Server on the same machine might sound tempting on the financial front because SSRS is included with the SQL Server Relational Engine; however, both the relational engine and Report Server love RAM and CPU cycles. SSRS is going to use all the RAM it can get or whatever it needs (the lower of the two numbers ) to render a report. Rendering reports , and especially rendering large reports, also chews up lots of CPU cycles. Adding this overhead to an older machine that is already struggling with the database server is not advisable.

Disk Space Requirements for SSRS

Anyone who has known a DBA, or who has been one, knows there is one thing all DBAs lovestorage. They just can't seem to get enough of it, even in today's environments with large Storage Area Networks (SANs) and hundreds of spindlesthe DBA always wants more. This is for good reason.

SSRS, like most databases, installs with a very small footprint. It's almost, and possibly is, negligible. However, depending on how SSRS is used, the disk space requirements can grow pretty large. To understand how space is used inside the SSRS database, an overview of the different types of objects and how they are stored is required.

By now, it should be understood that the SSRS database holds the RDL files, data sources, models, and all metadata, such as folders and access control lists (ACLs). This might seem like a lot to store, but, in reality, this is rather small, and only in the most extreme cases should this cause issues. Session state information for SSRS is stored in the Report Server temporary database. Because only one row is generated per user session, this should not get very large, and grows at a predictable rate.

Other things stored in the database can, however, grow to be very large. Resources for reports are stored in the catalog as a binary large object (BLOB). It's a sure bet that your friendly neighborhood DBA hates BLOBs. When a BLOB is stored initially with the report RDL, it might not be such a big deal; however, if a resource is stored as part of a report in an archive solution, this can get very large very quickly. Cached reports or temporary snapshots are stored in the Report Server temporary database as a BLOB in intermediate format. Because cached reports include raw query results, the BLOB can get pretty large. Another disk space consideration when using cached reports with parameterized reports is that a separate copy of the cached report is generated for each combination of report parameters. The bottom line is that if you are using temporary snapshots, prepare to use disk space. On the same token as temporary snapshots are report history snapshots. The only difference between them is that report history is saved inside the Report Server database and not the Report Server temporary database.

Availability Impact of Standalone Deployment

If the performance impact of the single-server deployment can be shrugged off, the availability impact of it can't be. Having one machine be the central data store and Report Server creates a single point of failure in an enterprise environment. This makes having a backup essential to save the system from some unforeseen calamity. Not much more can be said about it. It is up to the administrator to decide how critical the functionality SSRS provides is. If it can be down for as much time as needed to restore from tape, or if SSRS is not yet important enough to be deployed in a redundant manner, then a standalone deployment should suffice.

Advantages/Disadvantages of the Scale-Out Model

The scale-out model of deployment has two main advantages over the standalone modelperformance and availability. However, it has one major downsidecost. Because in the scale-out model, the database server is separate from the web server, the performance penalty of combining the database engine with the Report Server's rendering engine gets nullified. In addition, the database can be clustered in a virtual server to provide a highly availability.

With modern SAN technologies, the database can even be replicated to a remote site. SSRS's application server lives on a separate server. The server is simply the first node in what could become a network load balanced (NLB) cluster. The cluster gives the ability to scale out for performance/availability or both. Scaling out also helps with dispersing the workload generated by scheduled subscriptions because each machine on the cluster looks for events that trigger a subscription to process. The cluster also allows one node to be removed for upgrades/maintenance and then be placed back online when the maintenance is complete.

Note

NLB clusters are not a function of SSRS; rather, they are a function of the OS or hardware. SSRS is just an application that can be placed on an existing NLB cluster.

All of this flexibility comes at a priceliterally. The only editions to support a scale-out deployment are Developer and Enterprise Editions. Microsoft does not offer support for Developer Edition, and does not license it for use in a production environment. Second, every machine in a scale-out deployment has to be licensed separately for Enterprise Edition. More than anything, the cost of a scale out is what keeps most shops from adopting it.