Raphael Burri's blog

Mostly about Systemcenter Operations Manager 2012

Dynamic Group Membership authoring and performance impact on RMS

Posted by rburri on January, 14 2009

Introduction

Operations Manager is very flexible about creating dynamic groups based on membership formulas. Such groups can easily be created in the console’s authoring pane and may contain just about any object, SCOM has discovered. For advanced grouping algorithms the management pack XML will have to be written/edited by hand since the GUI wizard does not support contains/contained type rules. If you are not so comfortable with writing management pack XML code, the semi-GUI based method could be used:

1. Prepare the groups using the autoring wizard

2. Export the resulting management pack

3. Edit and add the formulas as required using your favourite XML editor

4. Reimport the management pack

Such groups can serve for overrides, console views, console scopes, alert subscriptions and much more. All in all very powerful and flexible. This logic can be applied not only to the groups visible in the operator GUI. The group populator comes in particularly handy when designing dynamic distributed applications.  Populating distributed application elements works just the same.

Grouping options

The membership of a dynamic group is defined by applying at least one of the following methods. All of them can be freely combined and nested:

Contains/Contained evaluation performance

However; adding many dynamic groups to your SCOM could have a negative impact on the performance of the Root Management server. All groups are (internally) hosted by the RMS and it does all the dynamic group membership calculation. I have seen dramatic performance degradation even on mid-sized SCOM installations. Eventually this led to the GroupPopulator module (Microsoft.SystemCenter.GroupPopulator) being way behind the discovery process.

After some investigation it turned out that the use of the Contains/Contained expressions was causing the problem. Group calculation has to walk down (contains) or up (contained) the hosting and containment relationships for every object of the grouping class in order to decide if it is to become a member of the dynamic group or not. In a deep class hierarchy this query can become quite heavy.

If using that type of dynamic inclusion rules, there are two simple points to watch out for.

  • Choose grouping class (MonitoringClass) as specific as possible

Select the grouping class (MonitoringClass)  so that the group calculator does not have to evaluate too many objects. Avoid using System.Entitywhenever feasible. If your group must contain objects of different classes, rather use several membership rules (MembershipRule).

  • Set maximal query depth (maxDepth) attribute

All four (not)contained/(not)contains rules do support limiting the search depth of the query. The optional attribute maxDepth is used for that. Whenever possible think about how deep the module must look for and set the maxDepth attribute to that value. Quite often a “1” might be sufficient – for example to query for direct members of an object. Above examples all have the attribute set.

Real world examples

A very useful and neat example to show what can be done by using dynamic groups, was published by Tim McFadden. In his post he explains how to create a group that contains both server and health watcher objects. Great for using in subscriptions in order to receive alerts about failed health services as well. Tim uses two membership rules (one for the windows computers, the other one for the health service watchers) and does show how contained/contains can build up onto each other. The result could look like this: HealthServiceContainment.Group.DiscoveryRule.xml

Brian Wren writes about how to programmatically create groups that can make use of dynamic grouping formulas.

Brian also has a detailed post on how to create dynamic component groups for distributed apllications.

To create groups based on the AD security group membership of an agent system, follow Steve Rachui’s how-to.

Remark on MPVerify

Unfortunately the current version of MPVerify.exe (SP1) is unable to check if the inner logic of group calculation discovery rules is valid. The same is true for MPSeal.exe.  It is crucial that even after successfully checking or sealing a management pack, you go back to your RMS’ event log to look for any warning or error messages thrown by the GroupPopulator.

  • Event ID 4509 (The constructor for the managed module type “Microsoft.EnterpriseManagement.Mom.DatabaseQueryModules.GroupCalculationModule” threw an exception)

 

 

 

Happy grouping!

3 Responses to “Dynamic Group Membership authoring and performance impact on RMS”

  1. Raphael,

    You could also use the ComputerGroup class instead of the InstanceGroup class. If you look in Microsoft’s own MP’s, ComputerGroups are used regularly.

    Do you ever use ComputerGroups? I asked Kevin Holman about this. According to him and his collegue’s the only difference is that ComputerGroups can use health roll-up from its members and Instance Groups can not.

    Below is an extraction from the IIS 2003 Management Pack. You can see that this group doesn’t have a DiscoveryType. The Exchange 2007 Management Pack uses the same construction, but DiscoveryType is filled with the Group object itself. Odd…..


    CLASS DEFINITION SECTION

    DISCOVERY SECTION

    Discovery

    $MPElement$
    $Target/Id$

    $MPElement[Name="Windows!Microsoft.Windows.Computer"]$
    $MPElement[Name="SC!Microsoft.SystemCenter.ComputerGroupContainsComputer"]$

    $MPElement[Name="Microsoft.Windows.InternetInformationServices.2003.ServerRole"]$

    • rburri said

      Michiel
      Yes, the same technique works very well for ComputerGroups as well – or any other group and even ServiceComponentGroup (distributed application component). The main difference is that InstanceGroups do not inherit a strictly defined relationship. ComputerGroups normally contain computers. The relationship is defined in Microsoft.SystemCenter.Library: Microsoft.SystemCenter.ComputerGroupContainsComputer
      InstanceGroups can contain anything (Microsoft.SystemCenter.InstanceGroup.Library: Microsoft.SystemCenter.InstanceGroupContainsEntities).

      Rolling health up is possible on any containment (or hosting) relationship. As far as I know there is no difference between the two.

      I choose InstanceGroups is I need to group non-computer objects. ComputerGroups for computers and ServiceComponentGroups to build dynamic distributed applications. You can also check out a commented example for that here: http://www.systemcentercentral.com/

      Raphael

  2. […] Dynamic group Membership authoring and performance impact on RMS – by Raphael Burri […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: