Udostępnij za pośrednictwem

Multiple Management Groups, Single Data Warehouse (part 1)

  • Artykuł

In this series, I’m going to talk about multiple Management Groups sharing a single Data Warehouse.  I’ll try to clarify two common questions that come out of this scenario.

Part 1 – Operations Manager Reporting Instance
Where do these components get installed?

Part 2 – ReportServer and ReportServerTempDB
Where do these databases reside?

Before I get started, I want to make one thing clear about clustered configurations.  The SCOM Report Server role is not cluster-aware, so the Report Server role cannot be installed in a clustered configuration.  The SSRS Instance cannot participate in a scaled-out deployment.  Nor is the reporting databases hosted in a clustered configuration officially supported.  This article by the MOM Team has served as the official statement on these configurations.

Note: Sharing an existing data warehouse is as simple as installing the Report Server role in the next management group and pointing it to the existing data warehouse.  All the required pointers will be setup automatically by the installation process, and the data warehouse will be shared automatically without additional configuration.

Here we go with part 1…

Throughout this post, I’ll talk about the SCOM Reporting Instance.  When I mention the SCOM Reporting Instance, I am referring to three components that make up SCOM Reporting.

Components of a SCOM Reporting Instance

· SCOM Report Server role

· SQL Server Report Server (SSRS) instance

· Computer

You might be wondering why I include “computer” as a component.  No kidding, we need a computer?  I added this as a component to help the reader visualize the concept, which you’ll understand in just a moment.

There is a dependency between each of these components. We must think of the composition of the SCOM Reporting Instance as a single package that cannot be split. Also, a SCOM Reporting Instance cannot coexist with another SCOM Reporting Instance serving another Management Group.

During the installation of the SCOM Report Server role, SSRS security is reconfigured to make use of SCOM security features (User Roles) which are implemented in the SDK. Because of this, only one installation of the SCOM Report Server role can exist on a computer.

Since the SCOM Report Server role installation has a dependency on a local installation of a SSRS instance, we can deduce that there is a 1:1:1 relationship between the SCOM Report Server role, the SSRS instance and the computer in which these components are installed.

We can also determine from these rules that the 1:1:1 relationship is strict, and that these components can neither be split, nor can these components be mixed and matched with other SCOM Reporting Instance components serving other Management Groups.

Of course, we need not be concerned about these rules in single Management Group scenarios that are not sharing a Data Warehouse.  But if you are sharing a Data Warehouse amongst two or more Management Groups, these rules apply.

Customers often get hung up on the “unique computer” for each SCOM Reporting Instance rule. Often I hear customers asking if they can combine SCOM Reporting Instances in a multiple Management Group scenario. This isn’t possible, as a SCOM Reporting Instance cannot coexist with another SCOM Reporting Instance serving another Management Group.

Another point of confusion for customers is they have installed a SCOM Reporting Instance for the first Management Group on the server hosting the Data Warehouse. Later, they have deployed additional Management Groups and want to share the Data Warehouse. This is fine. But, again, the rules state that we cannot install another SCOM Reporting Instance on the server hosting the Data Warehouse. We must find another server to install the SCOM Reporting Instance. Additionally, each subsequent Management Group deployed that will share the Data Warehouse will require yet another unique server to install the SCOM Reporting Instance.

In case there are any lingering questions, I provided a simple table that should solidify these rules.

image

I hope this clarifies the SCOM Reporting Instance and where these components are installed.

Comments

  • Anonymous
    January 01, 2003
    Hi Marnix, This is a good question, and I don't recall reading about the shared Data Warehouse upgrade procedures in the R2 Upgrade Guide.  I haven't personally tested this scenario, and this is obviously quite a repro setup.  I have the question in with the Product Group and will update this comment when I have some answers. Thanks, Jonathan

  • Anonymous
    January 01, 2003
    @KAP That is correct.  Unfortunately this all comes down to the fact that the Report Server role is not cluster aware, and needs to be on the same server as the SSRS instance. -Jonathan

  • Anonymous
    January 01, 2003
    By the way - the concept of shared DW does not change from OpsMgr 2007 to OpsMgr 2012. Same rules apply.

  • Anonymous
    January 01, 2003
    That is correct.  A separate RS installation for each MG.  When you do the RS installation process on the second MG, input the Data Warehouse information you currently have up and running.  The DW will automatically become shared at that point.  You will not overwrite or cause any interference with the MG that is already writing to the DW.

  • Anonymous
    January 01, 2003
    @KAP The Report Server role is not cluster aware, so it's not advisable to install in a cluster configuration.  Also, the SSRS instance needs to reside on the same machine as the Report Server role, as it's outlined above.  It's not possible to select a remote SSRS instance while installing the Report Server role. -Jonathan

  • Anonymous
    January 01, 2003
    Hi Jonathan, Let's say that I will have 2 RS for SCOM, is there any way to change in the SCOM console the references for the reporting services server? Thanks, Artur.

  • Anonymous
    January 01, 2003
    Chris - on the supported configurations page, it states 769Kbps connectivity to DW (technet.microsoft.com/.../jj656654.aspx). I understand links between datacenters are getting VERY fast these days, but I'm still a little apprehensive about sharing a DW across a datacenter link. However, I think the worst that would happen is, your management servers may get backlogged - just ignore backlogs in this case. I believe standard SQL ports are required, and this is pointed out on the page referenced above. Hope that helps!

  • Anonymous
    January 01, 2003
    @Chris P - are you talking about connected MG's for the 2 "base" MG's and a "rollup" MG? Sure this will work, but it only applies to monitoring data - alerts and what not. There is no consideration of historical data when contemplating connected MG's. Also, there is no rollup of historical data to a "central" MG. A DW is either shared, or it's not. In the case of shared DW, then you just need a single DW, and you'll need to install a report server role in each MG regardless.

  • Anonymous
    January 01, 2003
    @Marnix Although this may work (SQL 2005 SSRS w/ SQL 2008 DW), I haven't personally tested this configuration and there are no plans to include this as a supported upgrade path at this time.  Currently, customer needs to upgrade both SQL roles to the same version. -Jonathan

  • Anonymous
    January 01, 2003
    Arturlr, I have done this in a lab, and it worked fine.  But this configuration is not documented anywhere, so I don't think it's officially supported. -Jonathan

  • Anonymous
    June 22, 2009
    Good article Jonathan. Thanks. A year ago I bumped into a situation with multiple MGs (five in total) and one DW. Got it working but took me a while to figure it out. This article could have spared me a lot of time then.

  • Anonymous
    July 10, 2009
    Hi Jonathan. How to go about it when upgrading the SQL Server of OpsMgr R2 to SQL 2008? Suppose the OpsMgrDW database server is 2008, does the SRS instances, based on SQL 2005 still work than?

  • Anonymous
    September 16, 2009
    The comment has been removed

  • Anonymous
    September 18, 2009
    Thanks Jonathan for the information. So just to confirm, I can install OpsDB and DWDB on the SQL cluster using a tool called DBcreatewizard.exe and I have to install the report server and sql on a standalone server (extra SQL licence). Otherwise installing the reporting role on the cluster would mean SCOM files are installed on the cluster.

  • Anonymous
    April 13, 2010
    So if understand this article I need a separate RS for each management group MG1, MG2 etc. I can then in turn share my common DW throughout each management group with DW1 for MG1 and MG2. During instillation how do I share the DW? That seems to be the part I am struggling with. Also will this over write the original DW counters? I am sort of new to this so bear with me. I know you are spot on with the 1:1:1 because when I setup a separate instance on the same server and re-ran the install it made a new DW for that instance and failed to install reporting into MG2. My original reporting environment seems un-affected.  Please advise.

  • Anonymous
    April 14, 2010
    The comment has been removed

  • Anonymous
    December 28, 2012
    Hi, in SCOM 2012 we are looking to deploy 3 MGs. 2 are the base MGs where all the agents will report to and 3rd one is a central MG that everything will roll up to. My question is regarding the DW deployment and the data sync. I guess each MG will need to have a DW database but will the connection actually push data from 2 base MGs into the central MG? Also regarding reporting - im planning on installing reporting only in central MG - would that work?

  • Anonymous
    March 19, 2013
    Hi Jonathan, Sorry for late reply and thanks for your feedback. I am getting back to implementing this into production soon and just wanted to find out few more things. What is the acceptable network latency between 2 management groups to even consider sharing a DW? What firewall ports would need to be opened for 1 MG to share data with another MG behind a firewall? Thanks again!