10 April 2012 blogs Steven Dwyer 4 min read
We have a two-fold motivation for today’s blog post. First, it lets us close a small gap we have noticed in the monitoring of clusters and cluster shared volumes. Second, it lets us demonstrate some interesting tricks in creating relationships within Operations Manager.
First, a bit of context. Microsoft provides the “Server Failover Cluster Management Pack” to monitor most aspects of clusters. However, the support for cluster shared volumes (CSVs) within the cluster is a little weak. You can find some monitoring of CSVs under the nodes in the cluster where they seem to be treated identically to local storage, albeit with rather confusing names.
You can find additional monitoring of CSVs under the resource groups for the cluster, where the CSV is given a much friendlier name. However, this monitoring only indicates whether or not the CSV is online.
Where, then, does one go to find cluster shared volumes monitored as a distinct entity? To the new “Windows Server Operating System Management Pack”. Kevin Holman has a nice blog post describing the discoveries and monitors that have been added to this management pack specifically for cluster shared volumes.
Unfortunately, however, the new monitors sit all by themselves in the Server OS MP and never unite with the cluster itself in the Failover Cluster MP. We thought it would be nice if the monitors for the CSVs could contribute to the health of the cluster. All we need to do is to create a relationship between the cluster and the cluster shared volumes, and then write a dependency monitor to roll up the health state.
Matthew Long recently had a good blog post entitled “Scripting Relationship Discovery in Operations Manager 2007 / 2012” and we’ll use that as a basis for our own management pack and relationship discovery.
Our plan is to use a script to create a containment relationship between Microsoft.Windows.Cluster and Microsoft.Windows.Server.ClusterSharedVolumeMonitoring.ClusterSharedVolume. Reading Matthew’s post, the key items are:
1. Create instances of both classes.
2. Create an instance of the relationship class that is used to link the two classes.
3. Assign the two instances created in (1) to the relationship and then submit it to Operations Manager.
The relevant lines of code are:
What is missing in the code snippet above is filling in the properties of the oCluster and oClusterSharedVolume objects. Do we have to fill in every single property of the class (such as the VendorID and IsRunningMixedVersion on the Microsoft.Windows.Cluster class), or can we “cheat”?
It turns out, we can get away with cheating. The only properties we need to fill in are those marked as Key=”true” within the Microsoft management packs. That makes sense because we are not submitting discovery data for the classes themselves, just for the relationship between them. The only thing Operations Manager should need to create the relationship is the keys. This allows us to get away with a much smaller script and keeps us from having to replicate all the details of the discoveries that were already written in the Microsoft management packs.
Thankfully, the cluster shared volume class contains the name of the cluster which is also used as the key in the cluster class, so we don’t even need to interact with the system the discovery is running on. We can simply copy all of the properties out of the targeted CSV class using the $Target/ notation. For example:
When the script runs every four hours, it will create a containment relationship between clusters and cluster shared volumes. Add in a few dependency monitors as we have done and voila, the cluster shared volumes now appear in the health explorer for the cluster and roll their state upwards.