This is
a pretty cool feature (at least in the theory, but I`ll explain later).
When you
create a Hyper-V cluster with Windows Server 2012, you get some additional benefits
of this technical wonder.
We`re
talking about VM Monitoring (light). Based on the behavior of a service running
within the guest OS (must be Windows Server 2012), you can let your hypervisors
in a cluster take actions to recover the services.
In a
nutshell, here`s what you will have to do.
1.
Create
a Hyper-V Cluster (use traditional
clustering or CA File Server over SMB) and deploy some VMs.
2.
Join
the VM to the same domain as your cluster – yes, this is a requirement, and
configure the firewall to allow an app through the firewall (enable the domain
profile).
You can also simplify this operation by firing
a simple line of PowerShell in the guest: Set-NetFirewallRule -DisplayGroup "Virtual Machine Monitoring"
-Enabled True
3.
Once
this is done, go back to the Failover Cluster Manager, right click your VM and
select ‘More Actions à Configure monitoring’
4.
If
you have followed the steps above, you should be able to communicate with your
VM and get a list of the available services. Note that it states that the VM
will be rebooted, which means that
you should configure some recovery actions on the services itself in the guest
OS. When the guest is not able to solve the problem, Hyper-V Cluster will take
over and reboot your VM.
So, what actions will Hyper-V Cluster take to
fix the issue with a faulty service within the guest OS?
First, it will restart the VM. If it can’t
solve the problem, the VM will be rebooted again and eventually moved to
another node in the cluster, if this is allowed by the failover policies on the
VM.
How does Hyper-V Cluster know that the service
has some problems?
The event ID 1250 is logged to the cluster,
telling that the VM is in a critical state. This is detected during some health
check interval in the cluster, and the actions can take place.
I mentioned earlier that this is a good thing
in theory. Let me explain.
This is about as far as you get from an
enterprise solution for monitoring and troubleshooting application issues. The
reason is simple, that you simply just can’t reboot a server without notice if
just a service fails. In an ideal world, everyone has dedicated servers for
their workloads. One server for this and another server for that. But sometimes
the ideal isn’t always possible and organizations have several applications on
a single server. You won’t reboot your SQL server because the print spooler
isn’t running.
And in some other organizations, you`ll need
some approval before you can reboot your servers, and you would like to have a
complete overview for the sake of SLA, and last but not least, you want to know
what the heck just happened, why it happened and what to do. Read: SC 2012
Operations Manager. J
But however, I really like this feature and I
find it quite useful for several scenarios and deployments. If I have a bunch
of web servers that are load balanced, I can reboot the one who`s having
problem, and hopefully the cluster will fix it. So I do definitively see the
bright side as well.
Enjoy testing this awesome feature in Windows
Server 2012.
Cheers,