Udostępnij za pośrednictwem

Configuring a Report Server Scale-Out Deployment

  • Artykuł

A scale-out deployment refers to an installation configuration that has multiple report server instances sharing a single report server database. This deployment model is used when you want to run Reporting Services in a server cluster. Configuring the report server nodes to use a shared database is a prerequisite to running the report servers in a cluster.

Requirements for a scale-out deployment include the following:

  • The Reporting Services edition must be Enterprise, Developer, or Evaluation. Standard edition does not support a scale-out deployment. You can create a scale-out deployment using a combination of editions as long as the edition supports the scale-out feature.
  • All of the report servers must be in the same domain or in a trusted domain.
  • All of the report servers must be the same version (SQL Server 2005 or Service Pack 1).

A report server scale-out can include report server instances that are all configured to run in native mode, or instances that are all configured to run in SharePoint integrated mode. You cannot create a scale-out deployment that includes report server instances that run in different modes. For more information about server modes, see Deployment Modes for Reporting Services.

Important

To run a report server scale-out deployment on a server cluster, you must also have software and tools that you can use to create and manage a server cluster. Reporting Services does not provide this functionality. For more information about running Reporting Services in a server cluster, see Planning a Reporting Services Deployment in SQL Server Books Online.

Deployment Steps for Report Server Scale-Out

Deployment steps include installation, configuration through the Reporting Services Configuration tool, and manual editing of the report server configuration files. If you are using Microsoft Application Center, you must exclude configuration files from replication operations.

Pre-installation Steps for an Application Center Deployment

If you are using Application Center to manage server clusters, you must define filters to exclude the report server configuration file (RSReportServer.config) from replication operations. Use the files-only installation option to install the report server instances you want to use. This allows you to set the filter prior to configuring the report server instances that will be included in the cluster.

  1. To set the filter, open the Application Center 2000 console, right-click Synchronizations, and select Properties.
  2. Define a filter that excludes RSReportServer.config. The default path is c:\Program Files\Microsoft SQL Server\MSSQLn\Reporting Services\ReportServer\RSReportServer.config.

Creating and Configuring Report Server Instances

You can install Reporting Services on nodes that are already part of a server cluster. Follow these steps to install and enable Reporting Services functionality:

  1. Install and configure a report server scale-out deployment. For more information, see How to: Configure a Report Server Scale-Out Deployment (Reporting Services Configuration).
  2. Run the SQL Server Surface Area Configuration tool to verify that Reporting Services is enabled. The Report Server Windows service must be enabled and running. The service is both enabled and running if you chose the autostart option in Setup. For more information, see SQL Server Surface Area Configuration.
  3. Configure view state validation by editing the Web.config file for Report Manager for every report server instance in the deployment. This step occurs after all of the nodes in the scale-out are installed and initialized, and before you edit the Reporting Services configuration files. Once incoming requests are load-balanced across the nodes, view state validation must be configured correctly. Otherwise, you will see many exceptions due to failed state validation. For more information, see the Configuring View State Validation section in this topic.
  4. If you are using Secure Sockets Layer (SSL), verify the SSL certificates are installed in the IIS application pools you are using, and that the virtual directories are configured to use SSL. Use the Virtual Directory pages in the Reporting Services Configuration tool to specify SSL connection for both Report Manager and the report server. Before continuing to the next step, verify that the report servers are configured correctly by opening Report Manager through an https:// connection. For more information about using SSL with a report server, see Configuring a Report Server for Secure Sockets Layer (SSL) Connections.
  5. Back up all configuration files in case you need to roll back later. In subsequent steps, you will modify the configuration files. If you make a mistake, you can roll back to the copies that you create in this step. Configuration files that you must back up include RSReportServer.config, RSWebApplication.config, and the Web.config files for both the report server and Report Manager.
  6. If you are using a virtual server as a single point of access to a Network Load Balanced (NLB) cluster, perform the following additional steps:
    1. Edit the Reporting Services configuration files to specify the virtual server name. For more information, see the Specifying the Virtual Server Name in Reporting Services Configuration Files section in this topic.
    2. In IIS, configure redirection to the URL of the virtual server. To configure redirection, set options on the Home Directory tab on Web Site Properties.
    3. Verify that you can access the scale-out deployment through the virtual server name (for example, https://MyReportPortal/reportserver and https://MyReportPortal/reports). You can check which node actually processes reports by looking at the report server log files or by checking the RS execution log (the execution log table contains a column called InstanceName which will show which instance processed a particular request). For more information, see Reporting Services Log Files in SQL Server Books Online.

Configuring View State Validation

To complete scale-out deployment, you must edit configuration files to enable view state for interactive HTML reports that are viewed in Report Manager.

In Microsoft .NET Framework 2.0, view state validation is enabled by default and uses ASP.NET process identity information to perform validation. Validation by process identity does not work in a cluster or scale-out scenario where the process identity varies for each node. As an alternative, you can generate a validation key to support view state validation and manually configure each report server node to use it.

The following steps include references to generating keys for the <machineKey> element. There are a variety of ways to generate key values, and the approaches for doing so are described in the .NET Framework documentation. For more information about configuring view state validation for a network of Web services, see the .NET Framework reference documentation for the <machineKey> element.

  1. Generate a validation key. You can use the autogenerate functionality provided by the .NET Framework or you can create the key some other way. Do not use the AutoGenerate option when setting the validationKey attribute.
  2. Generate a decryption key. For the decryption key, you can create an explicit value or set decryptionKey to AutoGenerate.
  3. Open the Web.config file for Report Manager and set the <machineKey> element. You must specify the validation key, decryption key, and the type of encryption used for validation of data. The following example illustrates the entries you must provide (these example values are not valid; avoid copying these entries into your configuration files): <machineKey validationKey="53ab8bv3ebc93bb826a7b3v37b903a9d5d4a0" decryptionKey="26165b97a9d5d4a0" validation="SHA1"/>
  4. Repeat these steps for each report server in the scale-out deployment. Verify that all Web.Config files in the \Reporting Services\Report Manager folders contain identical <machineKey> elements in the <system.web> section.

Specifying the Virtual Server Name in Reporting Services Configuration files

If you configure the report server scale-out deployment to run on an NLB cluster, you must manually update report server URL settings in the configuration files to use the virtual server name. For more information about the Reporting Services configuration files, see Reporting Services Configuration Files in SQL Server Books Online.

  1. Use a text editor to open the RSWebApplication.config file.

  2. Set the <ReportServerUrl> to the virtual server name and remove the entry for <ReportServerVirtualDirectory>. This step ensures that all requests coming through Report Manager are load-balanced to the report servers that are running in the scale-out deployment. The following example illustrates the syntax you should use; it specifies the virtual server name and report server virtual directory:

    <ReportServerUrl>https://MyReportPortal/reportserver</ReportServerUrl>
<ReportServerVirtualDirectory></ReportServerVirtualDirectory>

  3. Open the RSReportServer.config file.

  4. Set the <UrlRoot> to the virtual server address. This step ensures that all hyperlinks in reports point back to the scale-out deployment and are load-balanced accordingly. This setting is also used to complete report delivery. The following example illustrates the syntax you should use:

    <ReportServerUrl>https://MyReportPortal/reportserver</ReportServerUrl>

  5. Repeat these steps for each report server in the scale out deployment.

If you start the Reporting Services Configuration tool after making these changes, the tool might change the <ReportServerUrl> settings to the default value. Always keep a backup copy of the configuration files in case you need to replace them with the version that contains the settings you want to use.

See Also

Concepts

Reporting Services Component Overview

Other Resources

Installing SQL Server Reporting Services

Help and Information

Getting SQL Server 2005 Assistance