This post is the next in my series on using IT Analytics to analyze the performance of our Private Cloud at Bay Dynamics. In previous posts I've focused on analysis of my VMware infrastructure, but now I'll turn my attention to investigating the performance of our Hyper-V hosts.

We start with opening our SCOM Performance Cube and refine the metrics to data coming from System Center Virtual Machine Manager by choosing the MP named "System Center Virtualization Reports 2008". Adding the Entity Count and Sample Count to the pivot table gives me a high level picture of how much data I'm collecting from different objects within that MP. We have lots to choose from, including information on virtualization candidate servers, Hyper-V hosts, VM guests, and VMware ESX servers. See below:



In this case, I only want to look at my Hyper-V hosts, so I'll multi-select those five objects, right click, and filter my results to that selection.



Next I add the actual host name to the mix, and I can see the six Hyper-V hosts I'm collecting performance metrics for with this MP.



Now that I have a good set of metrics and hosts, I want to change my measures to show the actual minimum, average, and maximum values of each.



Now I've got some real numbers to chew on. To make the analysis easier, I'd like to see this as a chart. Choosing the Chart option at the top and adjusting the options to split that into three charts by Counter, I now have a much more visually informative perspective.



I see that one of the hosts, svsfhypv002, has the most available memory as well as good free space, but also has the highest variance in CPU % total run time. I'd like to drill into that further and see that data over time to help me determine if this host is a good candidate for a new set of VMs I need to provision.



Hmm, looks like things were stable in April with high available space and low CPU utilization, but there was a big change in May. My next thought is to see that % free space broken down by specific day to see the recent trend. Dragging in the date, I see:



Clearly there was additional load added to this server in early May. Fortunately I still have over 75% of the disk free and this is still a good candidate to host new Hyper-V VMs.

Once again, by leveraging my IT Analytics SCOM Performance cube, I was able to analyze trends in a fluid way, asking and answering my own questions on the fly in a matter of minutes. No guessing and no waiting, I have the information I need to make good decisions about loading and capacity of my virtual infrastructure!

This post is the next in my series on using IT Analytics to analyze the performance of our Private Cloud at Bay Dynamics. I'd like to revisit the topic of monitoring the Alerts coming from my VMware infrastructure as reported by the nworks Management Pack. This round I want to create a new SQL Server Reporting Services report that I can view either inside the System Center console or externally through a Web browser.

We'll start by launching the Report Builder from the IT Analytics Configuration Manager shown below:



For anyone that has created their own SSRS reports for SCOM or SCCM, the experience is essentially the same with one major difference - no writing SQL! Once Report Builder opens, I chose New Report, and selected "Create a dataset" as shown in the following dialog:



I navigate to the SystemCenter/ServiceManager folder, and from here I have a couple of options. IT Analytics based reports can start from either the IT Analytics Model, which is a SSRS Report Model that will work with older versions of Report Builder, but for this example we'll start with the ITAnalytics Data Source directly.



This is where things are VERY different than the status quo for SCOM reports. Instead of writing a SQL query (I'll spare the commentary about the complexity and risks involved), I pick my SCOM Alerts cube and literally drag and drop the measures and attributes I want in my dataset. In this case, I added the Management Pack name as a filter and restricted it to only show the nworks MP, then added Alert Count, Date, Severity, Host name, and the actual name of the alert.



That was where most usually struggle - getting a good dataset. The next part is the same regardless of where the dataset comes from. I assembled the output of my dataset into a chart and a table as shown below:



 I save the new report along side my other SCOM Alert related reports on the SSRS instance used by System Center Service Manager in the Configuration Manager folder.



After doing so, my new report shows up automatically in the System Center Service Manager Console.



Finally, opening the report gives me a great looking chart of Alerts by Severity, and a detailed table that breaks that down further by ESX Host, Alert Name, the date the alerts were raised.



That was easy, and it was FAST! Fast to render since the report used IT Analytics cubes as its source, and fast to author. I created a visually informative SQL Server Reporting Services report with very specific criteria on my own in just a few minutes. I used to have to pull my SQL guys off of what they were doing and have them go search around the OperationsManagerDW until they figured out what I was looking for. With a bit of luck and a lot of experience with the schema, they were able to get me what I needed within a few days. Not anymore. Now I'll make new reports, and update existing ones, any time I need them!

This post is the next in my series on using IT Analytics to analyze the performance of our Private Cloud at Bay Dynamics. In the previous post we uncovered a big spike in critical memory balloon alerts in early May reported from our nworks VMware Management Pack in System Center Operations Manager. My VMware Admin assures me that all is good and a shift in workload pressed the overcommitted memory on our ESX Cluster. I'd like to take a closer look at performance on that cluster though and see what's been happening.

To start, I open our SCOM Performance Cube and begin by dragging and dropping my way to find the VMware ESX Servers I'm concerned about, as well as filter down to pick a couple of specific counters out of the nworks MP. The resulting cube view is below, showing the minimum, average, and maximum value for CPU and Memory Used counters for the three ESX hosts in my cluster.



Now I want to visualize that in a chart, so with a couple of clicks from this position I've changed to Chart mode and turned on the multiple chart option so I could segment the CPU and Memory counters.



That's much easier to look at. No major anomalies pop out at me on first glance, other than one of my three hosts has a lighter CPU workload. Its interesting to note that the Memory Used Percentage stays above 90% on average for all of the hosts, which is consistent with the report from my VMware Admin that we're overcommitting the memory on that cluster and the memory balloon alerts indicated a shift in allocation of resources as we moved things around. Seeing the memory stay high is consistent with his explanation, but I still want to drill in and look at some specific dates. I right click on one of the hosts right in the chart and choose the drill into option, which shows me the same counters by date in May.



Again, things look pretty consistent, and I'm feeling better about the overall health of my ESX Hosts over the last month. I'll definitely hang on to these views though so I can keep an eye on how things are going moving forward.

I feel empowered. I trust my staff, but I'm no longer dependent on my VMware Admins to answer simple questions about how we're doing, and they can free up the hours a week they're spending writing queries and assembling data for me and focus on getting things done!