With this article, I’m starting a new series of short not-longer-than-5-minutes lessens on SCOM platform architecture. The plan is to make knowledge burst from zero to full in-depth understanding of the platform. Each lesson will cover a single aspect of the platform’s mechanics or principles. Let’s begin.

Before SCOM can start monitoring a computer, application, appliance, or any other subject, it needs to create its Health Model. Health Model is tree of objects making a virtual representation of “physical” or “real” objects (I made “physical” and “real” in quotes, because they also can be virtual, but in a different way). For example, a storage appliance has the main enclosure, which is a host for controllers, power supplies, and physical disks. At logical level, controllers create arrays and hosted partitions (i.e. partition exists within an array).

Similarly, SCOM will create an root object of an appliance (enclosure) class, which will be a host for subordinate objects of “controller”, “power supply”, and “disk” classes, as well as objects of “array” classes. As partitions exist only in an array, each object of the “array” class, will be a host for a set of object of the “partition” class.

Health Model plays a significant role in SCOM architecture:

• First, it makes a visual decomposition of a complex monitored subject for presentation layer.
• Second, it makes related alerts specific. In other words, it’s not a “something wrong at the appliance” type of alert, but “something wrong at the appliances at the disk #3”.
• At the same time Health Model helps automatically scale up monitoring. When an example “Physical disk status” monitor is defined for a physical disk of a storage appliance class, SCOM will automatically runs a monitor instance for each physical disk object. No need to define monitoring for each object/class instance.
• Health Model is also a versioned inventory, or a kind of CMDB to certain extend. It collects and keeps history of object properties such as serial number, size, volume, address, and other information. All property changes are written into Data Warehouse and can be traced. Deleted objects are kept in Data Warehouse as well.
• I used the “host/hosted” word a lot for a reason. Another function of Health Model is object lifecycle control. In the given example deleting hosting array will automatically delete hosted partition objects (which make sense, as in the real storage appliance, partitions are defined within an array). Similarly, removing the entire appliance, will delete all subordinated object such as disks, arrays, controllers, etc.

Describing the Health Model, I was mentioning terms like “class”, “object”, and “class instance”. They are fairly intuitive, therefore their exact definition is not required to understand the concept of Health Model. However, classes is another key concept of SCOM. This is why I’m touching them in the next part.