Hey again, everyone. My name is Evans Nicholson,
and I am a Technical Marketing Engineer here at Hewlett Packard Enterprise.
Today I have the privilege of introducing to you Hyper-V Analytics for HPE InfoSight.
This new functionality provides Hyper-V customers with end-to-end visibility
into their virtualized environments. Cross-stack Analytics for VMware has been
a customer favorite for many years, and now Hyper-V customers
will get to experience this as well. Hyper-V analytics enables seamless
troubleshooting by visualizing relationships between clusters, hosts,
VMs, and storage. With the help of HPE InfoSight, Hyper-V administrators
can now quickly identify overloaded hosts or noisy neighbors, find inactive VMs, or
even uncover underlying storage issues. The goal is to simplify VM management
and to provide deep insights for performance troubleshooting.
This video is pretty long. So here's a menu with timestamps in case you are here
looking for something in particular.
First, I am going to show you how to get started using Hyper-V Analytics.
I will go over the Toolkit installation, explain how Nimble Storage plays a role
in all of this, and then I will show you how to actually use this information
once it's up on the HPE InfoSight web portal.
Sound good? All right, let's get to it then.
The first thing you need to do is install the InfoSight Collector Toolkit.
This is done on a Windows VM or a physical host. And it can be done via PowerShell
or the GUI installer as I am showing now. Of course, there are some minimum requirements
for this VM, and those can be found in the installation guide.
So I am not going to go over that right now. One important thing to note
is that you need to be on the same domain as the Hyper-V clusters or hosts
that you want to include in this collection. Here you have a chance to
change the default port used to communicate out; otherwise, you can leave
the default, which is 21334. We need to enter in an account
with domain admin privileges here. And then we are done with the install part.
Now we move on to the discovery and registration process. I will do this
via the GUI again, but you could do this via PowerShell, if you want.
We will start by adding in Hyper-V clusters or hosts by searching
the domain for those objects with the Hyper-V role enabled.
You can cancel out of this if you want and enter things in manually, or you could just
wait until it's done and point and click.
So this takes a few seconds, and then you can see our Hyper-V cluster
populated in the top pane. Once we start getting data, you will be able
to see recent collections here. You also have the ability to stop or start
collections from our Hyper-V cluster in this section, so there is nothing
running on the Hyper-V host or clusters themselves, we are just getting statistics
and configuration data from them via remote calls. Stats and config
data is compressed and stored on the collector VM. Then NimbleOS pulls that data
where it's staged on Nimble disks until it's time to send Hyper-V data,
along with DNA and Auto Supports up to InfoSight.
Now let's find Nimble arrays to complete this collection process.
NimbleOS runs the Hyper-V Analytics master software and controls the final push
to InfoSight. So we need to associate an array with our hosts and
clusters. Just like in the previous step, we can expand advanced
to manually enter in a Nimble management IP address. You can always refresh
the collector info and displays if you are not seeing what you expect from here.
Okay, so now we have got everything set up to start getting Hyper-V information
from our clusters and hosts up into InfoSight. Before I show you InfoSight,
I want to quickly show you how you can see and interact with this collector VM
from the actual Nimble array GUI. Logging on to the Nimble GUI,
if we navigate to Monitor, then Stack Vision we will see a list of your Hyper-V
toolkit collector VMs.
Here we can see that we have recent config and stats polling times.
So that means we are successfully getting info from that collector to the Nimble array.
if we want, we can also trigger a manual pull for both config and stats
by clicking here. Again, you really only need to do this if you are troubleshooting.
And I just mention this to give you more info and
visibility about how this all works together.
Okay, now we get to the fun part. True cross-stack analytics for Hyper-V,
as seen in the HPE InfoSight web portal. Hyper-V Analytics. So let's start with clusters.
Before I get started, let me mention that anything in blue text
on the InfoSight portal is a hyperlink. They are all over the place and
you really can't miss them. The cluster is the highest level for Hyper-V.
For our purposes, there is no concept of something like vCenter or Datacenter,
like we have in VMware. So cluster is the top-level object
for Hyper-V Analytics. In our case, we only have one cluster, but if we had multiples,
that'd be listed on this page, one cluster per card.
You can sort hosts by CPU or memory, which is helpful if you have a large number of hosts
and you are interested in one resource or another. We can also immediately see
any overutilized host from this view. So if the top host is overutilized for CPU,
for example, I could click on the hostname to drill down and investigate further.
That's one of those deep links I was talking about.
The secondary dropdown list lets us filter either either by cluster or
standalone hosts.
Now let's move on to the host main menu. You can see the same secondary drop-
down here showing clusters or standalone. Just like all classic InfoSight
dashboards, you can sort and search any of these columns.
As you might imagine, there are some slight differences between VMware and
Hyper-V virtualization terms, and I will explain those as we run across them.
And the first up is Guest Runtime. For Hyper-V hosts, this is the percentage of
CPU time used to run VMs or cycles running within a VM. So here, for the top host,
60% of total CPU resources are being used, but only about 20%
for Hyper-V processing.
Now let's take a look at that host in a little more detail. Now we are looking
at averages for the past week. We can change the time frame by selecting here,
or we can click and drag to zoom in. This is helpful when you want to examine
a sudden CPU spike or any other performance issue you notice or
something particular that you are interested in, a particular timeframe.
It looks like between 1:20 and 1:30 something happened to spike CPU usage on this host.
Since the green line below indicating average guest runtime did not also go up,
it appears something else other than Hyper-V caused the Windows host
to increase CPU usage. When these charts are zoomed all the way in, you can get down
to one minute granularity, which is really nice, very accurate.
Now let's move over to storage. You can see we have a column for clustered shared volumes
versus standalone. CSVs are volumes which are mapped
to all hosts in a cluster, and standalone ones are mapped to only one host from Nimble.
You can see many deep links on this page, so as I mentioned before,
we can go in a number of different directions now.
But I will just choose this top one and drill down to see what we can see.
Now we are looking at latency, IOPS, and throughput for this particular
Hyper-V clustered shared volume. Operations are broken out into
read and write actions, and you can zoom in or change the time frame here as well,
just like we did for the Hyper-V host view.
The capacity tab shows you historical space utilization, and although there is
not much to see here, it can be helpful to recognize growth patterns over time.
I mentioned before the ability to jump from virtualization storage to Nimble Storage,
and that's exactly what I am going to do now. Clicking here takes me
to a storage-centric view in InfoSight. If, for example, I notice the Hyper-V storage
filling faster than I expected, I could go here to check to see if dedupe is enabled, for instance.
I could also check to see if we have snapshots
set up for data protection, if that's something I am interested
in confirming.
This is what we mean by cross-stack. We have just crossed from
the virtualization stack to the storage stack. We can connect the dots because with
HPE InfoSight, we have visibility into more than one technology or silo.
I will hit the back button in the browser to go back to the Hyper-V analytics.
And just like that, I am back to virtualization. So I got a little
sidetracked as I thought I might. But let's get back to the tour and
check out one last main menu, which is VMs.
The summary tab gives us a nice overview of our entire Hyper-V VM footprint.
As with a lot of the other views, we have the secondary dropdown menu,
which allows us to filter by cluster or standalone host.
Here's a good example of a VM where the disks are spread across several Hyper-V volumes,
spanning two different Nimble arrays. Clicking on the black text
allows you to access a sub-menu where you can jump to these objects if you want.
So let's check on a VM in more detail. I'll do that by clicking on its name,
and this takes me to a performance view for the VM. This should look familiar to you by now,
but as an overview, we can see latency, IOPs, and CPU usage
over the past week. On the CPU chart, we see a few Hyper-V specific terms
I need to mention. Guest Run Time is the percentage of CPU resources used
to actually do things inside the VM. This is the actual processing the
servers are doing for their application workloads. Hypervisor Run Time is the amount of CPU
used to run this Windows Server in a virtualized way.
You can think of this as the virtualization overhead or
the virtualization tax on this particular server. These two added together equal
Total Run Time. This is different than what we see for VMware and InfoSight,
so I just wanted to point this out. I actually like this breakdown because
you can see the tax or the penalty of running a workload on a VM versus
a physical server. Now, I have been in conversations in the past
with developers talking about performance issues, and sometimes the fact is brought up
that this is a VM versus a physical server. Not so much anymore,
but it's still an issue. So this stat is nice to have if you are in those kinds
of conversations because you can, for CPU anyway, show the virtualization overhead.
You can quantify it.
Remember, I picked this VM because it has disks spanning two volumes.
We can see this in the Hyper-V storage dropdown. Let's go back to the main VM page and
walk through a scenario. I think it's important to talk about
real-world use cases for this kind of stuff. We can show you these GUIs and show you stats
all day long, but the question is, how do I really use this?
How is this going to make my job easier? And that's what I am going to attempt to show you
now. We are going to do a little scenario here, so let's imagine that we are hearing from
a team responsible for running a music application called Volume Dynamics.
I am going to go over to the performance tab now and do some troubleshooting.
So I am going to find their VMs. We have got a list of all the VMs running
this Volume Dynamics application. I will sort by the highest average latency
and take a look at this one VM.
What's immediately obvious to me is there is a large increase in overall latency
starting on May 4th. I can also see IOPS dropping at the same time,
so there is something definitely going on. Let's go to one of my favorite sections,
which is the VHD tab. Here we can see performance stats
per VHD. Remember, we are troubleshooting this VM,
which is experiencing an overall performance issue, and we are seeing high latency numbers.
We know that this top disk is used by our third-party backup software.
If we see high latency on that particular disk versus others,
we know that we should focus on backups as a probable source of the performance issues.
And now, even though we are using block Hyper-V storage, we are now
looking at performance stats for this one file. What's interesting is we see latency
go up on May 4th, while at the same time IOPS and throughput drop.
Just like we saw on the other screen, this really means that we are seeing
a performance hit due to the latency. We can now focus on
a possible change in our backup software starting May 4th, which has caused an issue
with this VM and more than likely caused an issue with the Volume Dynamics
application as a whole. At least it's not helping things,
so it's something we should look into. Let's hit the back button in the browser and
go back to VM performance and then back again to our filtered VM view.
The VMs dashboard has one more dropdown list I want to go over.
Here, we can access helpful tools that VMware customers have been telling us
they love for a long time. First off is VM Capacity Trend,
which is used to show VM space utilization.
This will help you identify which VMs are using the most space and see
VM capacity trending over time.
VM I/O Contention Treemap is used to visualize I/O and latency
for a given host or cluster. The view is called a heat map.
The larger the box, the more IOPS and the darker the color, the more latency.
It is meant to show you hotspots with Hyper-V storage objects with regards to
which volumes are busy and which volumes are experiencing the most latency.
One of the things the last three contention trend graphs have in common
is that they all enable you to identify “Noisy Neighbors”. I am not talking about
the kind of noisy neighbor that's playing drums too loud all the time.
I am talking about a VM that's using up most of the resources, effectively starving out
the other VMs. Here we see I/O Contention for a given Hyper-V storage volume.
The top pane shows the busiest VMs in blue, the bottom pane shows
VM latency in red. We call this the shower tile view, but to be honest,
I think it’d be kind of weird if my shower looked like this.
But anyway, just like we have seen on many of the other screens, I can click and drag
to focus in a specific timeframe or a certain issue I'd like to examine.
So speaking of that, let's examine this dark red box as an example.
It looks like this VM had a higher than normal latency spike right around 4 o’clock.
At this level, we are showing 15-minute granularity, but I could zoom in more
and get down to one minute. VM Memory Contention is the same concept
as I/O Contention, but of course we are focusing on memory instead of I/O.
It's also done per Hyper-V host or cluster versus storage.
Same concept, though.
Last but not least is CPU Contention Trend. For each Hyper-V host, the top pane shows
VM CPU usage in blue and then any VMs suffering from CPU Ready in red at the bottom.
CPU Ready means there is processing to do, but the VM is having to wait
on CPU resources from the Hyper-V host. Many times, CPU Ready is due to
a noisy neighbor who's hogging resources. But luckily that's not the case here.
No one's playing drums too loud next door.
Well, I hope you have enjoyed this overview and guided tour,
personal guided tour, of Hyper-V Analytics, the newest addition to HPE InfoSight.
My name is Evans Nicholson. I am a Technical Marketing Engineer,
and I will see you next time.