Distributed Applications (DAs) – Part II: How About DAD?

----------------------------------------------------------------------------------
Postings in the same series:
Part  I – Why use them?
Part III -  Do’s and Don’ts
Part IV – Tips & Tricks
----------------------------------------------------------------------------------

Before taking a deep dive into DAs and how to get the best out of them, one must understand how DAs are build. Of course, it’s done by the wizard named DAD (Distributed Application Designer). But what is really happening? What does DAD do?

Actually, DAD is a busy little fellow. While we’re dragging and dropping Objects in DAD, it’s is creating Objects, their related Discoveries, Monitors and the lot. Only when one understands what is happening, good DAs can be build, properly managed and – when needed – potential issues solved. This second posting in this series about DAs will be all about DAD. Let’s start.

Let’s build a DA
First I will create a simple DA with only one Component with one Object, a SQL Database. This DA will be saved into a MP of it’s own. Some information:

• DA Name: Business Critical Application;
• Component Name: Database 01;
• Object in Component: Opalis (SQL database);
• MP for this DA: _DAD DEMO

What has DAD done?
A lot actually. Every Component in a DA is looked upon as a Class. Also the DA itself, is looked upon as Class. So in this case we have one DA and one Component, so their are two Classes. But a Class can’t simply exist. It needs to be discovered. Therefore, per Class a Discovery is created as well. But some monitoring is required as well. So per Component a Monitor is created as well. (Later on in this series I will talk more about the kind of Monitor DAD has built and why.)

Of course, the reason why one builds a DA is to group some or more Objects (Classes) logically together. So there are some Relationships as well. Per Object (Class) a Relationship is created. In this case we have two Classes, so there are two Relationships as well. And last but not least, there are Dependencies as well of course.

The Dependencies tells the DA what other MPs it requires in order to function. Based on what Classes are put into a DA, like SQL databases, IIS websites, VMware VMs, Windows 2008 Servers and so on, the list of Dependencies will be built. By default there will be four Dependencies (all libraries) present in any DA, all coming from the core MPs of SCOM itself: System Library, System Center Core Library, Health Library and the Distributed Application Designer Library.

Breaking it down it looks like this:

• Classes
  • 01: Business Critical Application
  • 02: Database 01
• Discoveries
  • 01: Distributed Application Membership. Targeted against the DA itself. Discovers the DA Components which are member of this DA.
  • 02: Component Membership Discovery. Targeted against the DA Component Database 01. Discovers the Objects which are member of this Component.
• Monitors – Dependency
  • 01: Component Group Health Roll-up for type SQL 2008 DB. Targeted against the SQL database. This Monitor resides at the DA Component level, in this case at Database 01 level.
• Relationships
  • SCIMembership_<GUID>. This one has the DA itself (Business Critical Application) as source.
  • SCIMembership_<GUID>. This one has the DA Component (Database 01) as source.

The names of the Relationships can be a downside. Why? Normally one doesn’t need to alter the xml-code itself. But sometimes it’s needed. Since the Relationship names uses GUIDs names will look like this: SCMembership_69f8ba4473bf4275820d5ede9bbac4c1 which isn’t very easy to remember. Nor does the name tell you what source that particular Relationship uses.

This behavior (using GUIDs in names for Relationships but Monitors, Rules and Discoveries as well) is found throughout the SCOM Console when building anything. The only way to workaround it is to use the MP Authoring Console, or to edit the XML-code afterwards and replace all GUIDs by more friendly names. In the last case one can wreck the whole MP…

Ok. Now I know what DAD did. Now what? What is it to me?
Like stated before, DAs can really add value to your monitoring solution. But in order to get the most out of it, one requires a thorough understanding of DAs. Now we know that when a DA is build, new Classes have been added into SCOM. Classes with a State. Classes which can be used in other situations as well, like dashboards for instance.

Crucial to know is that per DA Component a Dependency Monitor is created. Since this Monitor is saved to the same unsealed MP where the DA resides, this Monitor can be tweaked and tuned as needed.  
    

All the tabs are highlighted since everything can be changed in order to fit your requirements.

This tweaking and tuning is crucial in order to get the ‘flow’ (or Health Rollup) going in some DAs. Let’s hang around the Dependency Monitor a little while longer. When taking a good look at Monitor targeted against the DA Component Database 01 one will notice that only the Parent Monitor Availability is ‘active’. The other Parent Monitors (Configuration, Performance and Security) are empty:

Don’t think this is because of the Object (the Opalis database), present in the DA Component Database 01, is only monitored on it’s availability. Take a look at the Health Explorer of this database:

As you can see, the database itself, present in the DA Component Database 01, is monitored on Performance as well. But the Dependency Monitor on that same DA Component only takes the Parent Monitor Availability into account. This is default behavior for any DA Component present in a DA. A Dependency Monitor will be created as well, ‘connected’ to Parent Monitor Availability.

Suppose the DBAs tell you they don’t give a you-know-what about the availability of the database but are far more interested in the DB space in the DB? You can change that now in the DA! Seriously!

How to use this knowledge to make your DAs better will be explained in the next posting in this series. It will be all about the Do’s, Don'ts and troubleshooting issues in DAs you might encounter. See you all next time!