Management Pack Tuning: Logical Disk Fragmentation is High

One of the first floods of warnings new SCOM admins often get in their inbox is Logical Disk Fragmentation is High.

Here is how it usually goes down:
1. You import the Microsoft Windows Server Management packs on Monday.

2. You spend a day or two tuning out the memory and CPU spikes that fall into a range that you would consider noise.

3. By the end of the week you are feeling pretty good about yourself and decide to setup some notification channels and subscriptions for some peace of mind over the weekend.

4. You wake up Saturday morning to find your inbox or console full of Disk Fragmentation warnings.
What have you done wrong? Nothing, it is just that by default the Windows Server MP runs its disk fragmentation check every Saturday at 3:00 AM so unless you preemptively made the necessary overrides to your environment you will be treated to this nice little surprise. Certainly not the end of the world, but here is where many admins screw up. SCOM offers the wonderful functionality of being able to fix the fragmentation problem with two clicks via the Logical Disk Defragmentation task.

You have fragmented disks, you can defrag them in two clicks, how is this not a good thing?

The first question you have to ask before even thinking about defraging a server via SCOM is if the fragmented server is virtual or physical.? If the server is physical the answer to if you should defrag is–maybe. If the server is virtual– the answer is no.

For a good explanation of the implications of defraging a virtual server I would recommend Cormac Hogan’s September 20, 2011 post on the VMware vSphere Blog.

The post is specific to why this is a really bad idea for VMware shops, but much of the reasoning is applicable to any virtualized server.

The key points that apply to any virtualized servers are that:

1. You are unlikely to see any benefits from defraging virtual disks since generally multiple VM’s run on any given datastore/storage pool in an enterprise environment.

2. If any of your disks are thin provisioned the defrag process will cause your VMDK/VHD to expand and to unnecessarily chew up space. (If you were to defrag a large number of thin provisioned servers at the same time you could theoretically cause an outage if any of your datastores/storage pools are oversubscribed.)

3. Defragging creates more I/O which could result in a temporary drop in performance for the duration of the defrag.

 

On The Importance Of Building Test Environments

One of the things I didn’t quite grasp when I first started using SCOM a few years back was the importance of test environments. SCOM was this bright and shiny new tool that was going to help proactively monitor our servers, increase uptime, and as long as I only installed Microsoft approved Management Packs everything would be alright. This was admittedly extremely naive– but it was good starting point. I was enthusiastic as well as fortunate enough to learn that this was a terrible idea long before making a critical mistake.

SCOM is an incredibly powerful tool, but it has to be used and implemented intelligently:

-Installation guides must be read.

-MP’s should be evaluated in Test or Dev environments first (If you don’t have a test environment build one)

-Blogs should be scoured for relevant info.

-Management Packs should be installed in production because they provide value not just because you happen to have the associated product installed.

Anytime an engineer or admin asks to have a shiny new management pack installed in production and doesn’t want to test it first I remember this slide from a talk I stumbled across from Microsoft’s Management Pack University entitled “Getting Manageability Right” given by Nistha Soni, a program manager on the Ops Manager team at Microsoft:

Getting Managability Right Nista Soni

The talk was for the different Microsoft product teams to help them think about how to build better management packs that are useful to their customers. If a MP reduces total cost of ownership this is a good thing, if it increases TCO then we have a problem. This slide was referencing an iteration of a Microsoft MP–name omitted to protect the guilty– which provided feedback that while potentially useful for a developer at Microsoft, was also inundating their customers/operators with alerts.

Building a useful MP is a delicate balancing act and its important to remember that even the ones made by Microsoft are essentially a work in progress. Each successive iteration tends to get better, but if you just import into production without testing and research you are asking for trouble.

The talk itself is an interesting look at how Microsoft thinks about monitoring and building management packs and is still available here.

The contents of this site are provided “AS IS” with no warranties, or rights conferred. Example code could harm your environment, and is not intended for production use. Content represents point in time snapshots of information and may no longer be accurate. (I work @ MSFT. Thoughts and opinions are my own.)