System Center Operations Manager 2007

Implementing High Availability Reporting

Version 1.0

Walter Chomak

Senior Consultant

Microsoft Consulting Services

East Region Technology Team

[email protected]
Contents
Objective.....................................................................................................................................................3
Introduction.................................................................................................................................................3
Assumptions................................................................................................................................................3
Architecture Overview.................................................................................................................................4
Scenario.......................................................................................................................................................4
Deployment.................................................................................................................................................5
Second Reporting Server.........................................................................................................................5
Load Balancing.........................................................................................................................................5
Configure Management Group................................................................................................................6
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

Scenario
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 Reporting 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
specify 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 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

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.