Sunday, August 15, 2010 10:23
Clustering in Hardware Virtualization Environments
So this is an interesting topic… Server virtualization technologies
have become so simple and efficient for most organizations.. Using the
advanced technologies to provide high availability like ( Hyper-V Live
and Quick migration or VMWare VMotion ) had make things easier to keep
your VMs HA and retain your SLA. Although that using Clustering
technologies have some recommendations based on the used technology.. MS
Exchange team already published recommendations for running Exchange in the Virtualization Environments.
Part of it was “We recommend using the built-in Exchange Server high
availability solutions for virtualized Exchange servers instead of
hypervisor-provided clustering or portability solutions (such as
Hyper-V’s quick migration feature). The features found in Exchange
Server (in particular, cluster continuous replication (CCR)) provide
greater benefits than those found in hypervisor solutions that move
virtual machines between physical root machines.
We do not recommend using hypervisor-based virtual machine migration
(such as Hyper-V’s quick migration) for virtualized Exchange servers.
In a virtual machine migration configuration, an unscheduled outage can
result in data loss. In a CCR environment, this type of data loss is
largely mitigated by a feature called transport dumpster. The
transport dumpster takes advantage of the redundancy in the environment
to reclaim some of the data affected by the failover.”
So what about the rest of technologies like File Server clusters or
DHCP. What if you want to implement DHCP and File Server Clusters (
Guest Clustering ) over Hyper-V hosts Cluster ( Cluster over Cluster ) ?
is that supported ? Do we have any limitations or well known problem with that ?
It takes some search and some support from Microsoft and hereunder the answer
This would be a combination of guest clustering and host clustering.
This scenario would be working as long as you pass the cluster
Here are some tips for combing guest and host clustering for your information.
• Affinity – It is recommended that the nodes of a guest cluster should
reside on different hosts to achieve the highest levels of
availability. If a host were to crash, having VM’s associated with the
same guest cluster distributed across multiple hosts will enable
applications to recover faster. To accomplish this, configure the
cluster group property AntiAffinityClassName. The host cluster will
attempt to keep VM’s with a consistent string value (such as the VM
name) off the same host. See this KB for additional details: http://support.microsoft.com/kb/296799
• Heartbeat Thresholds – It may be necessary to increase the cluster
heartbeat thresholds of a guest cluster when a mobile guest VM node is
being moved to a new host, through a process such as live migration.
During the migration of the VM it will be temporarily unavailable for a
brief period of time which cluster health detection may detect,
increasing the thresholds will mitigate clustering assuming the node is
down and incorrectly taking recovery actions. This can be
accomplished by increasing the SameSubnetThreshold and SameSubnetDelay
cluster common properties. See this document for additional details: http://technet.microsoft.com/en-us/library/dd197562(WS.10).aspx
So you can provide more redundancy for your VMs by providing a
combination of host and guest clustering and get rid of your down time.
Some useful links
Hyper-V Guest Clustering Step-by-Step Guide
Failover Clustering & NLB Documents and Resources
Hyper-V: Using Hyper-V and Failover Clustering