Objective

This document will provide the information required to deploy a highly available System Center Operations Manager 2007 Reporting solution. Before embarking on this, be sure to spend some time considering the true value in having a highly available reporting solution. Primarily the cost of implementing a high availability solution vs. the relatively short period of time you would be without reporting if you did not configure for high availability: If you lost the reporting server completely, restoring reporting services is very easy and very fast.

Introduction

The Reporting role in System Center Operations Manager 2007 (OpsMgr) presents a unique challenge. There currently exists no ‘official’ solution for configuring it for high availability. The primary challenge is reporting is comprised of two separate applications:

1. Reporting Data Warehouse – The Reporting Data Warehouse stores monitoring and alerting data for historical purposes.

2. Reporting Server – Operations Manager Reporting Server is installed into an instance of Microsoft SQL 2005 Reporting Services SP1. It is responsible for building and presenting the reports from data queried from the Reporting Data Warehouse.

The reporting data warehouse is a SQL 2005 database and therefore can benefit from database high availability solutions such as clustering. The reporting server is also a SQL 2005 service and generally speaking, can also benefit for SQL high availability solutions. The challenge is presented by the web service component used for communication between the operations manager console and the reporting; how is that service configured for high availability?

Recently I had time to explore possible solutions and was able to successfully create a highly available reporting solution. This document is not officially sanctioned by the product group although I hope to get there feedback soon however the solution works and does not involve any “proprietary” efforts.

Assumptions

There are three assumptions about the environment where this highly available reporting solution will be deployed:

1. Distributed management group. Each role has a dedicated server rather than an all-in-one deployment.

2. SQL environment is not shared with other applications. It is dedicated to OpsMgr, this includes the reporting server.

3. You have the appropriate service accounts, data warehouse read and write accounts.

4. DNS works correctly.

Architecture Overview

Scenairo

It is safe to assume a highly available reporting solution would only be deployed if the entire management group is configured for high availability. The above reference architecture is that of one configured for high availability. You may notice I did not specify what type of load balancer. Optimally, you would want an intelligent solution capable of balancing the load as well as automatically taken a failed node off-line.

Deployment

Second Report Server

1. Provision an additional SQL 2005 SP1 (or 2) server and join it to the same domain as the management group resides in.

2. Run the ‘Prerequisite Checker’ for 'Reporting' only. The assumption is the data warehouse is already on a highly available SQL server. Make any necessary changes.

3. Install Operations Manager 2007 Reporting. Deselect ‘Data Warehouse’.

4. When prompted for the name of the RMS, be sure to enter the FQDN.

5. When prompted for the SQL Server / Instance which hosts the data warehouse be sure to the FQDN.

6. Since this new server is dedicated to the ‘Reporting Service’, when asked for the ‘SQL Server Reporting Services Server’, simply select this server. It will appear in the drop down.

7. Enter data warehouse write account and the data warehouse read account when prompted. In the tested scenario, these were the same accounts used in the deployment of the first reporting server.

8. After installation is completed, launch the ‘Operations Console’ and go to ‘Administration / Settings / Reporting’ and verify the ‘Reporting Server’ URL correctly reports to the new server. It will have been changed during the installation.

9. On the RMS, restart the SDK and Config as well as the Health services. Then restart the reporting services on the new reporting server. Lastly, execute ‘IIS Reset’. If you went straight to Reporting in the operations console there would be no reports available. It takes a few minutes before it synchronizes. By executing the above mentioned services seems to speed it up. In the test environment, modestly sized, it took 20 minutes. Once all reports appear in the operations console you will have successfully deployed a second reporting server. Actually, all you have accomplished is replace the original reporting server. At this point you can leave as is or change the reporting server URL to that of the original server.

Load Balancing

These steps are generic and high level since there are many ways to implement load balancing. I will detail the solution implemented in the test lab. Feel free to free-style it.

1. Create two new host records in DNS. DNS best practices apply. In the test environment, the new FQDN for the primary reporting server was reporting-a.opsmgr.com and configured to resolve to the primary reporting server while the second reporting server was reporting-b.opsmgr.com and configured to resolve the newly provisioned reporting server.

2. Create a new ‘Reporting Server URL’ (reporting.opsmgr.com). This will be used in the ‘Reporting Server URL’ field in Administration / Settings / Reporting. Additionally, it needs to be configured to point to the Load Balancer.

3. In the test environment, an F5 load balancer was used. It was configured to evenly distribute incoming requests to http://reporting.opsmgr.com to reporting-a.opsmgr.com and reporting-b.opsmgr.com. Additionally, the F5 was configured to continually test both reporting-a.opsmgr.com and reporting-b.opsmgr.com and ensure they are alive. Use whatever method you think is best.

Configure Management Group

1. Launch the operations console and go to Administration / Settings / Reporting and enter the new reporting URL, in this case, http://reporting.opsmgr.com

2. On both Reporting Servers, restart the SQL Reporting service.

One area I need to do a little more testing is what services truly are required to be restarted. As you can see, I restarted all services for simplicity.

At this point, should either reporting servers fail, service will not be disrupted. You may have noticed this is very much like implementing a highly available, load balanced web solution. SQL 2005 Reporting Server, at a simple level, is just that, a web service. If the data warehouse fails, it already resides on a cluster.