Dell™ High Availability Solutions Guide for Microsoft® Hyper

Dell™ High Availability Solutions Guide for Microsoft® Hyper
Dell™ High Availability Solutions
®
Guide for Microsoft Hyper-V™ R2
A Dell Technical White Paper
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
THIS WHITE PAPER IS FOR INFORMATIONAL PURPOPERATING SYSTEMS ONLY, AND MAY CONTAIN
TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT
EXPRESS OR IMPLIED WARRANTIES OF ANY KIND.
© 2011 Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without
the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell.
Dell, the DELL logo, and the DELL badge, EqualLogic, Compellent and PowerVault are trademarks of
Dell Inc. Microsoft, Windows, Hyper-V, and Windows Server are either trademarks or registered
trademarks of Microsoft Corporation in the United States and/or other countries. Other trademarks and
trade names may be used in this document to refer to either the entities claiming the marks and names
or their products. Dell Inc. disclaims any proprietary interest in trademarks and trade names other than
its own.
October 2011
Page ii
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Contents
Getting Started with High Availability ................................................................................. 4
New Features in Windows Server 2008 R2 .......................................................................... 4
Cluster Shared Volume .............................................................................................. 4
Live Migration ........................................................................................................ 5
Clustering Implementations for High Availability ...................................................................... 5
Hyper-V Guest Clustering ............................................................................................. 5
Hyper-V Host Clustering ............................................................................................... 7
Planned and Unplanned Failover (Host Cluster Model Only) .................................................... 8
Planned Failover Using Live Migration ........................................................................... 8
Cluster Shared Volume .............................................................................................. 8
Planned Failover Using Quick Migration........................................................................ 10
Processor Compatibility Requirements ........................................................................ 11
Unplanned Failover ................................................................................................ 12
Comparison of Guest and Host Clustering ........................................................................ 14
Designing for High Availability ......................................................................................... 15
Node and Disk Majority versus Node Majority Cluster Configuration ........................................ 15
Storage Configuration ............................................................................................... 16
Sharing a LUN for Multiple HA VMs.............................................................................. 16
Storage Options for Hyper-V Host Clustering ................................................................. 17
Network Configuration ............................................................................................... 18
Cluster Network Types ............................................................................................ 18
Best Practice Recommendations ................................................................................ 20
Recommended Configurations ...................................................................................... 20
Design for iSCSI-Based Configurations .......................................................................... 21
Design for Fiber Channel Configurations ....................................................................... 22
Design for Direct-Attach SAS Configurations .................................................................. 23
Implementing High Availability in Hyper-V ......................................................................... 24
Implementing Hyper-V Host Clusters .............................................................................. 24
Preparing the Systems ............................................................................................ 24
Configure the Failover Clustering Feature and Hyper-V Role .............................................. 25
Creating Virtual Machines That Will be HA VMs .............................................................. 25
Creating Virtual Machines that will be HA VMs using CSV .................................................. 27
Enabling VMs as HA VMs ........................................................................................... 28
Page 1
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Migrating HA VMs across Hosts in the Cluster ................................................................. 28
Hyper-V Host Clusters on Server Core ............................................................................ 29
Setting up the Server Core System for Hyper-V and Failover Clustering ................................... 29
Setting up Remote Management to Server Core .............................................................. 29
Remote Management from Windows Server 2008 R2 Full Install ........................................... 30
Remote Management from Windows Vista..................................................................... 30
Administering High Availability for Hyper-V ........................................................................ 30
Changing the Configuration of HA VMs ............................................................................ 30
For Configuring Changes that Impact the VM's HW Profile ................................................. 30
For Configuring Changes that DO NOT Impact the VM's HW Profile ....................................... 31
Adding Passthrough Disks to HA VMs .............................................................................. 31
Sharing LUNs Between HA VMs ..................................................................................... 32
HA VM Resource Group Names ..................................................................................... 32
Cluster Resource Group for HA VMs Reported as "Partially Online" .......................................... 32
Configuring Rules for Associating Hosts to HA VMs ............................................................. 33
Setting Host Preferences for HA VMs ........................................................................... 33
Blocking HA VMs from Running on Certain Hosts ................................................................ 33
Converting an Existing Non-HA VM to a HA VM .................................................................. 33
Converting an HA VM to a Non-HA VM............................................................................. 34
Using SMB/CIFS Shares in Hyper-V .................................................................................... 35
Using Mount Points in Hyper-V ........................................................................................ 36
Hyper-V Host Clustering Data Template............................................................................. 37
References ................................................................................................................ 39
Glossary ................................................................................................................... 40
Tables
Table 1.
Comparison of Guest and Host Clustering ......................................................... 14
Table 2.
Comparison of Node Majority versus Node and Disk Majority .................................... 16
Table 3.
Determining if a LUN Can Be Shared.................................................................. 17
Table 4.
Storage Types For Hyper-V Clustering ................................................................ 18
Table 5.
Dedicated Network Ports for Hyper-V Host Cluster Nodes ........................................ 19
Table 6.
iSCSI-Based Configuration Network Requirements ................................................. 21
Table 7.
Fiber Channel-Based Configuration Network Requirements ...................................... 22
Table 8.
Direct-Attach SAS-Based Configuration Network Requirements ................................. 23
Table 9.
Hyper-V Host Cluster Summary ....................................................................... 37
Page 2
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Table 10.
Hyper-V Host Cluster Nodes ............................................................................ 37
Table 11.
Hyper-V Host Cluster Network ......................................................................... 38
Table 12.
Hyper-V Host Cluster HA VM Resource Group Information ........................................ 38
Figures
Figure 1.
Hyper-V Guest Clustering Within a Single Physical Server .......................................... 5
Figure 2.
Hyper-V Guest Clustering Across Two Standalone Physical Servers ............................... 6
Figure 3.
Hyper-V Host Clustering ................................................................................... 7
Figure 4.
Hyper-V Host Cluster With CSV Enabled Before Migration .......................................... 9
Figure 5.
Hyper-V Host Cluster With CSV Enabled After Migration ............................................ 9
Figure 6.
Hyper-V Host Cluster Before Migrating ............................................................... 10
Figure 7.
Hyper-V Host Cluster After Migrating ................................................................. 10
Figure 8.
Hyper-V Host Cluster With Both Servers Running ................................................... 12
Figure 9.
Hyper-V Host Cluster After One Server Fails ........................................................ 13
Figure 10.
iSCSI-Based Hyper-V Host Cluster Configuration ................................................ 21
Figure 11.
Fiber Channel-Based Hyper-V Host Cluster Configuration ...................................... 22
Figure 12.
SAS-Based Hyper-V Host Cluster Configuration .................................................. 23
Figure 13.
Typical VHD Configuration on Storage Disk Assigned with a Drive Letter ................... 36
Figure 14.
Typical VHD Configuration on Storage Disk Configured with a Mount Point ................ 36
Page 3
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Getting Started with High Availability
High Availability (HA) solutions are not new to Windows® environments. Microsoft has offered native
support for HA through its Microsoft Cluster Services (MSCS) in Windows 2000, Windows Server®
2003, and Windows Server 2003 R2, and with the Windows Failover Clustering (WFC) feature in
Windows Server 2008 and Windows Server 2008 R2. Failover clustering reduces the possibility that any
single point of failure in your virtualization environment will cause your workloads to become
unavailable. In a non-virtualized environment, HA implementation was traditionally only used for
environments that were hosting critical workloads because the loss of a non-critical service hosted on
any single physical server was considered acceptable.
However, in a virtualized environment in which a single physical server will host many virtual
machines, the loss of that physical server will result in the loss of service of multiple workloads. To
prevent this scenario, implementing HA should be a primary goal of any virtualization deployment
regardless of scale or scope, especially in a production environment.
This Dell® High Availability Solutions Guide for Microsoft Hyper-V™ white paper introduces different
options to implement HA for Hyper-V environments, and provides recommendations and best
practices for configuring your Hyper-V HA environments on Dell hardware.
This paper assumes that you have a basic understanding of Hyper-V, as well as the networking and
storage concepts of Hyper-V. If you have not already read them, Dell strongly recommends that you
review the following guides to get an in-depth understanding of Hyper-V solutions on Dell hardware:
•
•
•
Dell Solutions Overview Guide for Microsoft Hyper-V
Dell Networking Solutions Guide for Microsoft Hyper-V
Dell Storage Solutions Guide for Microsoft Hyper-V
New Features in Windows Server 2008 R2
Windows Server 2008 R2, Hyper-V uses Cluster Shared Volume (CSV) storage to simplify and enhance
multiple windows servers to access SAN storage. It also adds new features such as live migration
functionality, support for adding or removing storage from a virtual machine, and enhancements to
processor and networking support.
Cluster Shared Volume
Cluster Shared Volume (CSV) is available as part of the Windows Failover Clustering feature of Windows
Server 2008 R2. CSV is a volume that is simultaneously available to directly read from and write to by
all nodes in a Microsoft® Failover Cluster. This capability, referred to as Direct I/O, is made possible by
providing a distributed access file system, which allows each node to utilize its storage interconnect—
Internet SCSI (iSCSI), Fibre Channel, Serial Attached SCSI (SAS)—for communication with the volume on
the shared storage array. CSVs also provides the ability for multiple virtual machines (VMs) to share a
single shared storage volume while also allowing these VMs to migrate (live or quick) independently
between hosts in the cluster. In the event that a node loses its path(s) to the shared storage array,
CSVs provide the capability to reroute data over the network. CSV enables faster live migration and
easier storage management for Hyper-V when used in a cluster configuration.
Page 4
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Live Migration
Live migration allows you to transparently move running virtual machines from source node of the
failover cluster to the destination node in the same cluster without a dropped network connection or
perceived downtime. In this case there is no transfer of disk ownership between the nodes. Live
migration requires the failover clustering role to be added and configured on the servers running
Hyper-V. In addition, failover clustering requires shared storage for the cluster nodes.
Clustering Implementations for High Availability
Hyper-V HA implementations can broadly be categorized into Hyper-V Guest Clustering and Hyper-V
Host Clustering. The differences in the two types are based on where the clustering service is running
and what the clustering service is managing.
Hyper-V Guest Clustering
In a Guest Cluster implementation, the clustering service runs on the guest operating system in the
virtual machine. This type of clustering provides high availability for applications that are hosted
within the virtual machines.
As illustrated in Figure 1 and Figure 2, Hyper-V Guest Clustering can be implemented with the VMs
either deployed on a single physical server, or across multiple physical servers.
Figure 1.
Hyper-V Guest Clustering Within a Single Physical Server
In Figure 1, virtual machines A and B are running on the same server. In this scenario, the workloads
being managed by the clustering service in the guest operating systems in the VMs will not survive a
physical server outage or a crash of the parent partition. If the physical server or the Windows Server
2008 R2 instance running in the parent partition fail, all of the VMs running on this system fail,
causing the clustered workloads within the VMs to also fail.
Page 5
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Figure 2.
Hyper-V Guest Clustering Across Two Standalone Physical Servers
In Figure 2, the clustered virtual machines A and B are running on different physical servers. In this
scenario, the workloads being managed by the clustering software within the VMs are able to offer
continued service even in the case of an unplanned physical server downtime or parent partition
outage.
As in all cluster implementations, the Hyper-V Guest Cluster implementation also requires that the
cluster service running in all the guest operating systems has direct access to a common shared
storage. In the case of Hyper-V Guest Cluster, the only way to provision shared storage that is
accessible directly by multiple VMs is by using iSCSI-based storage (Direct Attached SAS and Fiber
Channel Arrays are not supported for Hyper-V Guest Clustering). With the iSCSI initiators running in
the guest operating systems, Hyper-V VMs can directly talk to the iSCSI storage without going through
the storage stack of the parent partition.
NOTE: The Dell Storage Solutions Guide for Microsoft Hyper-V provides more detailed information on
provisioning iSCSI storage disks directly to Guest operating systems.
Because configuring clustering within the guest operating systems in the VMs is no different than
configuring clustering on physical servers that are not virtualized, this solutions guide does not
discuss this model any further. For more information, refer to the Microsoft Failover Clustering
documentation for the guest operating system.
Page 6
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Hyper-V Host Clustering
In this implementation, the Hyper-V Host servers are clustered by leveraging the Windows Failover
Clustering features in Windows Server 2008 R2 x64 editions. Failover Clustering in Windows Server 2008 R2
is a robust and mature, third-generation clustering solution that has been significantly improved in
Windows Server 2008 R2. Leveraging this Failover Clustering feature allows Hyper-V to offer HA solutions
on a wide array of storage solutions including Direct-Attach SAS, iSCSI, and Fiber Channel storage
arrays.
Figure 3.
Hyper-V Host Clustering
Figure 3 illustrates a sample Hyper-V Host Cluster configuration with the Windows native cluster
service running in the Windows Server 2008 R2 x64 parent partition. In this scenario, the Failover
Clustering service in the parent partition will manage the VMs as the cluster resources. The VMs
running on either of these servers can be configured as highly available and do not require clustering
capabilities in the guest operating systems in the VMs. The only requirement is that all the virtual
machine files are on storage accessible by all the physical servers that are part of the cluster. (For
the remainder of this document, VMs managed by the cluster for high availability are referred to as HA
VMs.)
Hyper-V Host Clustering is the recommended mechanism to implement HA in a Hyper-V environment.
Clustering has many advantages including a wide array of configuration options, ease of management,
and scalability. In addition to providing HA, this solution also supports planned downtime activities
such as for physical server maintenance and enabling dynamic datacenter capabilities such as VM
workload balancing.
Page 7
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Windows Server 2008 R2 supports a maximum of 16 physical servers in a single Failover Cluster
configuration. Therefore, a single Hyper-V Host Cluster configuration can have a maximum of 16
physical servers. A maximum of 1000 virtual machines supported per single Failover Cluster
configuration, and each cluster node supported no more than 384 virtual machines, see Requirements
and Limits for Virtual Machines and Hyper-V in Windows Server 2008 R2. Hyper-V Host Clustering may
be implemented on the following editions of Windows Server 2008 R2:
•
•
Windows Server 2008 R2 x64 Enterprise Edition
Windows Server 2008 R2 x64 Datacenter Edition
Planned and Unplanned Failover (Host Cluster Model Only)
The Hyper-V Host Cluster model accommodates both planned and unplanned downtime. A planned
downtime is when a physical server that is part of a Hyper-V Host Cluster is taken offline by the
administrator for maintenance, such as a hardware upgrade or applying an OS patch. An unplanned
downtime is when a physical server that is part of a Hyper-V Host Cluster becomes offline
unexpectedly due to hardware failure, a parent partition crash, or other reason. Physical servers that
are part of a cluster are commonly referred to as cluster nodes.
Planned Failover Using Live Migration
Live migration provides the capability to move a virtual machine (VM) from one node in Windows Server
2008 R2 failover cluster to another node without a perceived interruption in service by
applications/clients connecting to the VM. Here is a high-level workflow of the VM migration process
during planned failover:
NOTE: On a server running Hyper-V, only one live migration either to or from the server can be in
progress at a given time. You cannot use live migration to move multiple virtual machines
simultaneously. Live Migration can occur between two different set of nodes in a cluster
simultaneously; a cluster will support number_of_nodes/2 simultaneous live migrations. For example,
an eight node cluster can support four simultaneous live migrations, with no more than one live
migration session active from every node of the cluster.
The cluster copies the initial memory state being used by the VM from the originating node to
destination node (through Live Migration network)
1. Any memory pages that were changed during the copy process (dirty pages) are
marked, and the pages are copied over as well. This iterative process continues until
the number of pages is relatively small.
2. The VM is paused on the originating node, and the state of the VM is copied to the
destination node where it is resumed.
Cluster Shared Volume
Hyper-V in Windows Server 2008 R2 has an add-on feature called Cluster Shared Volume (CSV) which
increases the availability and performance of Hyper-V virtual machines with improved management.
CSVs are the shared disks in Available Storage that can be accessed by all cluster nodes, using a single
consistent namespace for all volumes.
When CSV is enabled in failover cluster management GUI, the following folder is created:
%systemroot%:\ClusterStorage
Page 8
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
All the CSV LUNs appears within this folder in a volume(n) folder. For example,
C:\ClusterStorage\Volume1.
For live migration with CSV, there is no transfer of disk ownership between the nodes. The transition is
instantaneous so that a client accessing the VM does not lose the network connection.
Figure 4.
Hyper-V Host Cluster With CSV Enabled Before Migration
Figure 5.
Hyper-V Host Cluster With CSV Enabled After Migration
Page 9
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Planned Failover Using Quick Migration
To accommodate the planned downtime of a server, the administrator can choose to move all the
VMs from that server to the other servers in the Hyper- V Host Cluster. Here is a high-level workflow of
the VM migration process during planned failover:
1. VM in the originating node is placed in save state (the contents of memory are saved to
files located on SAN storage).
2. SAN storage disk ownership is moved from the originating node to the destination node.
3. VM is started on the destination node and state is restored from SAN storage.
NOTE: The difference between Quick and Live Migration is that Quick Migration saves the VM state,
moves cluster resources, and restores the VM, resulting in some system downtime.
Figure 6.
Hyper-V Host Cluster Before Migrating
Figure 7.
Hyper-V Host Cluster After Migrating
Page 10
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
This save and restore operation ensures that the state of the VM is retained during the migration
process. The guest operating system is unaware of this VM save and restore process, it is frozen during
the migration period. Microsoft calls this capability to migrate VMs across physical servers Quick
Migration.
Even though there is no loss of state or data during this process, it is not a live migration process.
The guest OS and the workloads within the VM will be offline and not available to users during the
migration period.
NOTE: Any active connections with the guest operating system in the VMs will be lost when the VM
undergoes migration. The connections have to be re-established after the migration is complete.
The offline duration period is typically between 15 seconds and a few minutes, depending mainly on
the following factors:
Amount of memory used by the guest operating system: This is the most important factor because the
time taken for VM migration is directly proportional to the amount of memory that is being used by the
guest operating system; the more memory being used by the guest OS at the time of the migration,
the longer the migration. Note that the amount of memory being used by the guest OS is not the
same as the amount allocated to the virtual machine. Unless the virtual machine is running a very
memory intensive workload, the memory utilized is usually much less than the memory allocated to the
VM.
Speed of the storage fabric: The connection speed to the storage array is a factor because the state of
the VM is transferred from the source node to the shared storage and then restored from shared
storage to the destination node over the storage fabric. So, it is very important that you plan your
network (in case of iSCSI) and storage deployment to ensure that there are no bottlenecks that could
impact quick migration times.
Processor Compatibility Requirements
Quick Migration is a stateful migration process and so requires that the processors on the source and
destination cluster nodes be compatible. Hypervisor-based virtualization software (such as Hyper-V)
allows certain CPU instructions from the virtual machines to execute directly on the physical
processors. Therefore, the state of a VM may have a dependency on a specific feature of the physical
processor.
Processor features vary between processor vendors, processor models, and processor families. During
a VM quick migration across physical servers that do not have identical processors, if the processor on
the destination node does not support a feature that is leveraged by the VM in the source node, it
can cause the VM state restore process to fail on the destination node.
NOTE: In the scenario where the processors on the cluster nodes are not feature compatible and
the VM fails to restore state on the destination node, the cluster service will attempt to restore the VM
(along with the saved state) on the originating cluster node if that node is still online. However, this
behavior is impacted if changes are made to the default settings for how the Failover Cluster service in
Windows Server 2008 R2 manages its resources.
Page 11
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
NOTE: If you have more than one processor family used by the nodes of your cluster, then live
migration may fail with the default settings. To allow live migration to succeed, each VM must have the
processor migration compatibility setting enabled. This setting can only be changed when the VM is
powered off. Dell strongly recommends that all of the nodes of a Hyper-V Host Cluster configuration
have identical processors.
Unplanned Failover
In the case of unplanned downtime, the nodes in the Hyper-V Host Cluster do not have the time to
initiate a VM Quick Migration. Instead, the cluster service automatically restarts all the HA VMs on
the other nodes of the cluster. In this unplanned failover scenario, the state of the VM is not
retained and there is the possibility for data loss. To the guest operating system, this is similar to an
unexpected restart of the operating system. The failover of VMs is automatically handled by the
cluster service, however, and workloads running within the VMs are back online in a short period of
time. Here is a high-level workflow of the unplanned failover scenario:
1. A node in the Hyper-V Host Cluster configuration fails. All states of the VM (including
guest OS and workloads within the VMs) that have not been committed to SAN storage
are lost.
2. Cluster service transfers ownership of SAN storage disk resources from the failed node to
other nodes in the Hyper-V Host Cluster.
3. VMs are restarted on the other nodes of the Hyper-V Host Cluster.
Figure 8.
Hyper-V Host Cluster With Both Servers Running
Page 12
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Figure 9.
Hyper-V Host Cluster After One Server Fails
Unlike the case of a planned failover, where the administrator chooses a specific destination node for
the VMs, in an unplanned scenario the cluster service will choose the appropriate destination server
for the VMs. If a specific cluster node is found to not have sufficient resources such as CPU or memory
to host the VMs, the cluster service will attempt to start the VM on another available node in the
cluster.
NOTE: Using the advanced features available in Windows Failover Clustering, rules may be set to
restrict certain VMs to only run on certain nodes of a Hyper-V Host Cluster. For more information, refer to
Administering High Availability for Hyper-V.
NOTE: Because the state of the VM is not retained during an unplanned failover, the processors
(and their features) on the originating and destination nodes do not have to match. However, Dell
strongly recommends that all servers in a Hyper-V Host Cluster have identical hardware to ensure that
it also supports planned migrations.
Page 13
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Comparison of Guest and Host Clustering
Table 1 highlights the key differences between Hyper-V Guest Clustering and Hyper- V Host
Clustering.
Table 1.
Comparison of Guest and Host Clustering
Category
Hyper-V Guest
Clustering
Hyper-V Host
Clustering
High Availability Scope
The applications
running on the guest
OS are the clustered
entities
The virtual machines
are the clustered
entities
HA is only for these
applications and not
for the VM itself
HA is for the virtual
machines as a whole
(including the guest
operating systems and
applications within the
VM)
Requires that the
guest OS is supported
by Hyper-V
Solution is Guest OS
independent because
the cluster software is
running in parent
partition
Guest OS
Requirements
Requires that the
guest OS has cluster
software capability
Requires that this
cluster software
supports iSCSI storage
Shared Storage Type
iSCSI only
Direct Attach SAS
iSCSI initiator runs in
the guest OS
iSCSI
Fiber Channel
SMB Share
Implementation
Application support
Clustering has to be
configured within
every VM
Clustering has to be
configured only in the
parent partition on
each host
May be more complex
to manage if several
VMs need to be made
into HA VMs
Implementation is
independent of the
number of VMs
Workloads within the
VM must be clusteraware
Workloads within VMs
do not have to be
cluster-aware
Page 14
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Category
Hyper-V Guest
Clustering
Hyper-V Host
Clustering
Maximum number of
physical servers in the
cluster
No direct dependency
on physical servers.
Limitations may apply
based on the
configuration
Maximum of 16
physical servers in a
single cluster
configuration
Quick Migration
Not Available
Supported
Live Migration
Not Available
Supported
NOTE: Based on the HA requirements, these models may be implemented in combination. However,
careful planning and consideration is needed before implementation, because such an implementation
will be fairly complicated to configure and manage.
Designing for High Availability
Planning and designing is a very crucial step in ensuring a highly available environment that also
provides the most isolation and best performance for the HA solution. This section provides guidance
for a few of the key scenarios in failover cluster configuration.
Node and Disk Majority versus Node Majority Cluster Configuration
As mentioned earlier, Hyper-V is dependent on the Failover Clustering feature to provide HA
capabilities. The Failover Clustering feature in Windows Server 2008 R2 offers multiple configuration
models for clustering up to 16 physical servers. The difference between the clustering models is in
which of the cluster resources get to vote to decide whether or not the cluster is in a highly available
state at any given time. The most common and recommended cluster configuration models are:
•
•
Node and Disk Majority Cluster
Node Majority Cluster
NOTE: A third type called Node and File Share may be suitable for certain scenarios. However, that
is beyond the scope of this document. For information on all the cluster models, please refer to
Microsoft website at www.microsoft.com/windowsserver2008/failover-clusters.mspx.
Node Majority Cluster is a configuration in which only the servers that are part of the cluster can
vote, and Node and Disk Majority is a configuration in which the servers and a single shared disk (SAN)
resource get to vote. The choice of the cluster model is dependent on the specific requirements of
the environment in which the cluster is being deployed.
Page 15
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Table 2.
Comparison of Node Majority versus Node and Disk Majority
Node Majority
Node and Disk
Majority
Number of Nodes
Recommended for
clusters with an odd
number of server
nodes
Recommended for
clusters with an even
number of server
nodes
Shared Storage
Shared storage is not
required for
configuring the
Failover Cluster
Minimum 500MB NTFS
shared disk as Witness
Disk for configuring
the Failover Cluster
Shared Storage is
required for HA VMs
Shared Storage is
required for HA VMs
More than 50% of the
nodes must be up for
the cluster to be
running
At least 50% of the
nodes and witness disk
must be available for
the cluster to be
running
Requirement to
Maintain High
Availability Status
If the witness disk is
not available, more
than 50% of the nodes
must be available for
the cluster to be
running
Storage Configuration
The Dell Storage Solutions Guide for Microsoft Hyper-V provides detailed information on the various
storage configuration options in Hyper-V as well as best practices for their implementing on Dell
storage arrays. This section discusses the storage considerations in a Hyper-V Host Cluster
environment.
Sharing a LUN for Multiple HA VMs
A key decision point for Hyper-V Host Clusters is whether each HA VM will have its own LUN or if
multiple HA VMs will share a single LUN. The main difference between these two configurations is in
how they handle failovers.
The NTFS file system grants access at a LUN, or volume, level and not a file level. Consequently,
when an HA VM is moved across physical servers, the ownership of all the storage LUNs that host that
HA VM's files will also transfer across physical servers. This behavior impacts both planned and
unplanned migrations.
Planned migration (quick migration) scenarios: if there is a need to quick migrate an HA VM
independent of other HA VMs, then that HA VM cannot share any of its LUNs with other HA VMs.
Page 16
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Unplanned migration scenarios: this might be a factor depending on the resource requirements for all
the HA VMs that share a LUN. If the cluster service is unable to successfully bring all the HA VMs (that
share the single LUN) online on another node, it will retry on all other available cluster nodes. If none
of the available cluster nodes can host all the HA VMs due to resource constraints, it is likely that none
of the HA VMs that share the single LUN will be brought online
Table 3 lists important factors to consider if you plan to share a LUN across multiple HA VMs:
Determining if a LUN Can Be Shared
Table 3.
Single LUN can be shared by
multiple HA VMs
Single LUN is required per HA VM
If the HA VMs are only using VHDbased virtual hard disks (and not
passthrough disks)
AND
If it is acceptable that all HA VMs
will move across hosts
simultaneously in planned failover
scenarios (Quick Migration)
If the HA VMs are using passthrough
disks (and not VHD-based virtual
hard disks)
OR
If there is a requirement to be able
to migrate HA VMs one at a time in
planned failover scenarios (Quick
Migration)
NOTE: Depending on the Disk I/O in the specific configuration, sharing a single LUN across multiple
HA VMs may also impact I/O performance.
Storage Options for Hyper-V Host Clustering
The type of storage that is used in a Hyper-V Host Cluster will mostly impact the design of the HyperV Host Cluster solution.
Storage type affects the following:
•
•
•
The number of network adapters on each Hyper-V host
The number of storage adapters on each Hyper-V Host
Quick Migration because the VM state is saved to disk over the storage fabric
Table 4 summarizes the different types of storage that support Hyper-V Host Clustering and Hyper-V
Guest Clustering. For a full list of supported storage hardware for Hyper-V, refer to the Dell Storage
Solutions Guide for Microsoft Hyper-V.
Page 17
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Table 4.
Storage Types For Hyper-V Clustering
Storage Type
Examples
Support for
Hyper-V
Host
Clustering
Support for
Hyper-V Guest
Clustering
External
Enclosures
(JBODs)
PowerVault™
MD1000, PowerVault
MD1120, PowerVault
MD1200/MD1220
No
No
SAS Arrays
PowerVault MD3000,
PowerVault
MD3200/MD3220
Yes
No
iSCSI Arrays
PowerVault
MD3000i,
PowerVault
MD3200i/MD3220i,
PowerVault
MD3600i/MD3620i,
EqualLogic™ PS
Series, Compellent
Storage Center iSCSI
Storage Arrays
Yes
Yes
Fiber Channel
Arrays
Compellent Storage
Center Fibre
Channel Storage
Arrays, PowerVault™
MD3600f/MD3620f
Yes
No
Network Configuration
The Dell Networking Solutions Guide for Microsoft Hyper-V provides detailed information on the
various networking configuration options in Hyper-V as well as implementation best practices. This
section discusses the networking considerations for a Hyper-V Host Cluster environment.
Cluster Network Types
In addition to storage resources, the cluster service also manages network resources on hosts that
are part of the cluster. The cluster utilizes and manages these network resources based on their
cluster use type as designated by the administrator when configuring the failover cluster. The cluster
use type is set using the Failover Cluster Management console and selecting the specific adapters
listed under Network. There are three cluster use types:
Internal Type: The cluster network resource is configured to allow the cluster to use the network and
disallow clients to connect through the network.
Enabled Type: The cluster network resource is configured allow the cluster to use the network and also
allow clients to connect through the network.
Disabled Type: The cluster network resource is configured to not allow the cluster to use this network.
Page 18
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
NOTE: These network types are defined by the Windows Failover Clustering feature in Windows
Server 2008 R2 and are not related to the Hyper-V network types that are defined in the Dell
Networking Solutions Guide for Microsoft Hyper-V.
In a recommended configuration, each node of a typical Hyper-V Host Cluster should have dedicated
network ports for the following:
Table 5.
Dedicated Network Ports for Hyper-V Host Cluster Nodes
Network Types
Descriptions, Configurations, and Best Practices
Network for Cluster
Private
One Gigabit (or Fast Ethernet) Ethernet network port for
hosting the Cluster Private network.
This network is dedicated for use by the cluster service to
check the health state of each cluster node.
Should be of cluster use type Internal.
Network for Cluster
Public and for Parent
Partition
Management
One Gigabit Ethernet network port for hosting the
Cluster Public network and for network access to the
Windows Server 2008 R2 parent partition.
This network will be used to:
– Manage the Hyper-V Host Cluster using the Failover
Management console
– Manage the Parent Partition and the Hyper-V Role
Should be of cluster use type Enabled.
Network for Virtual
Machine
One or more Gigabit Ethernet network ports to host
virtual machine networks.
Should be of cluster use type Disabled to ensure isolation
of the virtual machine network traffic.
Network for Storage
Two or more Gigabit Ethernet network ports to host iSCSI
storage network (for iSCSI-based configurations).
Should be of cluster use type Disabled to ensure isolation
of the storage network traffic.
NOTE: Even though Failover Cluster in Windows Server 2008 R2 does not require a dedicated cluster
private network because it can use the public network to monitor cluster heartbeat, Dell recommends
a dedicated cluster private network to ensure the reliability of the Hyper-V Host Cluster configuration.
Page 19
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Best Practice Recommendations
• Static IP addresses should be used for networks — especially the Cluster Private,
Cluster Public, Parent Partition, and any iSCSI Storage networks.
• Ensure that the Cluster Private network is on a separate subnet than all other networks
on the Hyper-V Hosts. It is recommended that each network type in Table 5 is on a
separate subnet.
• Ensure that the network configuration is completed (including assigning the appropriate
subnets and static IP addresses) on every Hyper-V Host before the Hyper-V Host Cluster
is configured.
NOTE: This s t e p is critical because in Windows Server 2008 R2, the Failover Cluster service
automatically identifies network resources during configuration and assigns them as cluster network
resources. It does this based on the subnet configurations and automatically selects at least one
network adapter from each subnet. Network resources cannot be manually added or removed as a
cluster resource using the Failover Cluster Management console.
•
•
After the Failover Cluster is configured, ensure that cluster network resources have
been configured as recommended in Table 5.
When using dual-port or quad-port network adapters, host the same network types on
different physical network adapters to ensure that there are redundant network paths
available to accommodate a single network adapter (NIC) HW failure. For example, in a
configuration with two iSCSI storage networks, instead of using two ports of the same
network adapter for hosting the iSCSI network, use network ports on two separate
network adapters. Follow similar best practices for Cluster Private/Public, and Virtual
Machine Networks.
Recommended Configurations
As mentioned in the Dell Solutions Overview Guide for Microsoft Hyper-V, Dell supports Hyper-V on a
very wide array of server, networking, and storage hardware. Even though the Failover Clustering
feature in Windows Server 2008 does not require that the hardware in a cluster configuration be
identical, Dell strongly recommends having identical hardware in any single Hyper-V Host Cluster
configuration. This will ensure that there are no compatibility issues (such as processor dependencies
to support Quick Migration) that could cause disruption in a production environment.
Dell offers a wide array of servers that have been specifically built with the goal of being able to host
virtualized workloads. These servers offer support for large amounts of physical memory, large
numbers of I/O slots for both network and storage, and a minimal power footprint. For a full list of
servers that Dell recommends for virtualization, go to www.dell.com/servers.
Page 20
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Design for iSCSI-Based Configurations
Table 6 summarizes the recommended network requirements for an iSCSI- based configuration for a
Hyper-V Host Cluster:
Table 6.
Minimum
Recommended
Ports
iSCSI-Based Configuration Network Requirements
Parent Partition
Management &
Cluster Public
Network
Cluster
Private
Network
iSCSI
Storage
Network
Virtual
Machine
Network
1 Port
1 Port
2 Ports
2Ports*
* Scale the number of network ports based on the number of VMs and workloads. Distribute VMs across
the associated virtual networks based on bandwidth requirements.
Figure 10 provides a sample configuration of the infrastructure and highlights the need for isolating
the traffic for management, storage, and workloads running within the virtual machines.
Figure 10.
iSCSI-Based Hyper-V Host Cluster Configuration
Page 21
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Design for Fiber Channel Configurations
Table 7 summarizes the recommended network requirements for a Fiber Channel- based configuration
for a Hyper-V Host Cluster:
Table 7.
Fiber Channel-Based Configuration Network Requirements
Network Connections
Parent
Partitions
Management
and Cluster
Public
Network
Cluster
Private
Network
Fiber
Channel
Connections
Virtual
Machine
Network
Storage I/O
Minimum
1 Port
1 Port
2 Ports*
2 Ports
Recommended
Ports
* Scale the number of network ports based on the number of VMs and workloads. Distribute VMs across
the associated virtual networks based on bandwidth requirements.
Figure 11 provides a sample configuration of the infrastructure and highlights the need for isolating
the traffic for management, storage, and workloads running within the virtual machines.
Figure 11.
Fiber Channel-Based Hyper-V Host Cluster Configuration
Page 22
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Design for Direct-Attach SAS Configurations
Table 8 summarizes the recommended network requirements for a Direct-Attach SAS-based
configuration for a Hyper-V Host Cluster. It is important to note that this is only guidance, and actual
deployment configuration will vary based on the existing infrastructure.
Table 8.
Direct-Attach SAS-Based Configuration Network Requirements
Network 10 Connections
Minimum
Recommended
Ports
SAS
Connections
Parent
Partitions
Management
and Cluster
Public
Network
Cluster
Private
Network
Virtual
Machine
Network
Storage I/O
1 Port
1 Port
2 Ports*
2 Ports
* Scale the number of network ports based on the number of VMs and workloads. Distribute VMs across
the associated virtual networks based on bandwidth requirements.
Figure 12 provides a sample configuration of the infrastructure and highlights the need for isolating
the traffic for management, storage, and workloads running within the virtual machines.
Figure 12.
SAS-Based Hyper-V Host Cluster Configuration
Page 23
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
NOTE: Even though it is possible to configure a 4-node Hyper-V Host Cluster with a Dell MD3000 SAS
Storage Array, Dell recommends only a 2-node Hyper-V Host Cluster with the MD3000 SAS Array. This is
to ensure that the configuration is more reliable. In a 4-node configuration, there is only one path from
any one node to the storage array and that does not provide multi-path resiliency for the solution.
Implementing High Availability in Hyper-V
This section covers the procedures for implementing High Availability in Microsoft Hyper-V. This
document only provides high-level guidance. For detailed instructions, please refer to Failover
Clustering in Windows Server 2008 R2 at www.microsoft.com/windowsserver2008R2/failoverclusters.mspx
Implementing Hyper-V Host Clusters
For any successful Hyper-V Host Cluster deployment, careful consideration must be given to the
network and storage configurations to ensure that there are no single points of failure and to ensure
that there is sufficient bandwidth for both network and storage traffic. For more information, see
Designing for High Availability.
This section discusses best practices for configuring a Hyper-V Host Cluster and provides high-level
steps to setup a Hyper-V Host cluster. For step-by-step instructions on configuring a Hyper-V Host
Cluster, refer to the Microsoft documentation Hyper-V Step-by-Step Guide: Hyper-V and Failover
Clustering at http://technet.microsoft.com.
Preparing the Systems
1. Install Windows Server 2008 R2 x64 Enterprise or DataCenter Editions on your servers.
2. Make sure that all the devices on the server have the latest supported drivers from
http://support.dell.com. Download the device drivers for Windows Server 2008 R2 x64.
NOTE: Dell does not support device drivers that are downloaded from 3rd party vendors. Only use
drivers from http://support.dell.com.
3. Configure the network connections and storage connections as planned.
NOTE: Make sure that the appropriate MPIO software for the storage array has been installed on
the nodes.
NOTE: For Node and Disk Majority configuration of the Failover cluster, make sure that the shared
LUN (minimum 500 MB) that will be used as the witness disk is configured as shared storage for all
servers.
Page 24
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Configure the Failover Clustering Feature and Hyper-V Role
1. Install the Failover Clustering feature on all the Windows Server 2008 R2 servers that will
be part of the Hyper-V Host Cluster. The feature can be enabled using the Add Feature
wizard in Server Manager.
2. The Failover Clustering feature in Windows Server 2008 R2 provides a new capability that
allows administrators to run a validation check on the planned configuration to
identify potential issues before actually creating the failover cluster. Open the Failover
Cluster console on any of the systems, run the Validate a Configuration wizard, and
make sure that the configuration with all the nodes meets all the requirements for a
Windows Failover Cluster.
NOTE: It is strongly recommended that you address all errors and warnings reported by the
validation wizard before configuring the failover cluster.
3. After all the requirements have been verified to be met, use the Failover Clus ter
Management console to c reate the failover cluster.
4. Enable the Hyper-V Role on each of the nodes of the fai lover cluster.
NOTE: For information on enabling the Hyper-V Role, refer to the Dell Solutions Overview Guide
for Microsoft Hyper-V.
5. Configure the Virtual Networks as planned on each Hyper-V server. Make sure that
Virtual Networks are created with the exact same names on all the servers in the
Hyper-V Host Cluster. For example, if any one cluster node has a virtual network called
TestNetwork, all the Hyper-V hosts in the cluster should have a Virtual Network with
the name TestNetwork. If not, when a HA VM fails over to a system that does not have
a Virtual Network with that name, the VM will not have network connectivity. In such a
scenario, the network connectivity will have to be enabled by manually configuring the
virtual network for the HA VM.
Creating Virtual Machines That Will be HA VMs
This section discusses the steps used to configure a new virtual machine that will be made into an
HA VM. There are different ways to create VMs for High Availability such as creating VMs on
traditional volume, on a cluster-shared volume, or converting existing VMs to HA VMs (see Converting
an Existing Non-HA VM to a HA VM).
Choosing the storage location that will host the virtual machine's files is the most important aspect
of configuring a HA VM. As mentioned earlier, Hyper- V requires that all the files and disks (VHD or
Passthrough) belonging to a HA VM are on shared storage (SAN) and are accessible to all nodes of the
Hyper-V Host Cluster. To create an HA VM, the following consoles are required:
•
•
•
Failover Cluster Management console (cluadmin.msc)
Disk Management console (diskmgmt.msc)
Storage array software console such as:
o Dell Modular Disk Storage Manager™ for PowerVault M3xxx FC, iSCIS, and SAS
storage arrays
o Dell EqualLogic Group Manager for Dell EqualLogic arrays
o Dell Compellent Storage Center for Dell Compellent Storage arrays
Page 25
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
It is recommended that this process be done one VM at a time to ensure that storage disk allocations
to VMs are correct. Storage configuration for a VM involves the following:
1
Use the SAN storage array software console to create the logical disks (LUNs) that are
required for the VM. Make sure all the disks on the SAN are configured to be available to all
the nodes of the cluster.
NOTE: For guidance on sizing storage for virtual machines, refer to the Dell Storage Solutions
Guide for Microsoft Hyper-V.
2
Use the Disk Management console on each of the server nodes to verify that the newly
provisioned storage LUN is visible to all nodes.
NOTE: The LUN may be in the offline state at this time on all the hosts.
•
•
If the LUN will be used as a passthrough disk for the VM, make sure to bring the LUN
Online on any one cluster node, Initialize it, and then take it Offline.
If the LUN will host the VM's VHD file, bring the disk Online on any one cluster node,
Initialize it, and Format it as NTFS.
NOTE: In scenarios when the Hyper-V Host Cluster is hosting a relatively large number of VHD-based
VMs, the cluster configuration may run out of drive letters in the parent partition. Hyper-V allows the
use of Mount Points to host storage LUNs to work around the drive letter limitation. Refer to Using
Mount Points in Hyper-V for more information.
3
Use the Failover Cluster Management console to add the storage LUNs as cluster resources.
Confirm that the newly provisioned storage disks are listed as Storage→Available Storage
disks and are not allocated to any specific Resource Groups.
NOTE: If the storage disks are not made cluster resources at this stage, the attempt to convert a
VM to an HA VM may result in an improper configuration.
4
5
6
When a storage disk is added as a cluster resource, the cluster will choose to bring the
storage disk online on any one of the cluster nodes.
Use the Failover Cluster Management console to identify the host that owns the newly
provisioned storage LUN.
Use the Hyper-V Manager console on that specific host to launch the New Virtual Machine
wizard.
NOTE: If the VM creation has to be done on a cluster node other than the cluster node that owns
the newly provisioned storage LUN, then the storage LUN has to be moved to the node on which you
are attempting to create the VM. Cluster disks in the Available Storage group can only be moved across
cluster nodes using the CLI. For example, the CLI command cluster group "Available Storage" /move
can be used to move storage disks across nodes in a two-node cluster.
7
In the Specify Name and Location screen of the New Virtual Machine wizard, select Store
the virtual machine in a different location and specify the path to the shared storage disk
that will host the virtual machine files (XML/BIN/VSV).
Page 26
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
NOTE: If the VM's boot disk will be a passthrough disk, the VM's files (XML/BIN/VSV) can either be
on another shared storage LUN or a file share. See Using SMB/CIFS Shares in Hyper-V for more
information on file shares.
At the Connect Virtual Hard Disk screen, choose the type of boot disk for the VM (VHD or
Passthrough). For VHD, specify the path to the shared storage LUN. For Passthrough disks,
select Attach a virtual hard disk later and attach the disk later by updating the hardware
configuration of the VM.
9 Follow the prompts of the wizard to complete the VM configuration.
10 The VM is now ready to be configured as an HA VM. The administrator may choose to install
the guest operating system at this time.
8
NOTE: Before a VM can be made an HA VM, the VM's DVD Drive should be detached from physical
optical drives or image files. If Integration Services were installed in the guest operating system, make
sure the Integration Services CD image is detached from the VM's DVD drive. If there is a specific
requirement that a VM's DVD Drive has to be in captured state, then make sure the DVD Drive is
attached to an image file via a UNC path that is accessible to all nodes of the cluster.
Creating Virtual Machines That Will be HA VMs, Using CSV
1. Launch Failover Cluster Management (FCM) console by clicking Start Administrative Tools
FCM.
2. In the FCM console left navigation panel, click on the cluster name.
3. In the FCM right navigation panel under Configure click Enable Cluster Shared Volumes… link.
4. If warning windows appear click OK. The cluster now supports CSV.
5. Use the SAN storage array software console to create the logical disks (LUNs) required for the
VM. Make sure all disks on the SAN are configured to be available to all nodes of the cluster.
6. Use the Disk Management console on each of the server nodes to verify that the newly
provisioned storage LUN is visible to all nodes.
7. Use the FCM console to add the storage LUNs as Cluster Shared Volumes. Confirm that the
newly provisioned storage disks are listed in Cluster Shared Volumes and are not allocated to
any specific Resource Groups.
8. When a storage disk is added as a Cluster Shared Volumes, the cluster will choose to bring the
storage disk online on any one of the cluster nodes.
9. Use the Failover Cluster Management console to identify the host that owns the newly
provisioned storage LUN.
10. Use the Hyper-V Manager or Failover Cluster Management console to launch the New Virtual
Machine wizard.
11. In Specify Name and Location screen of the New Virtual Machine wizard, select Store the
virtual machine in a different location and specify the path to the shared storage disk that
will host the virtual machine files.
12. At the Connect Virtual Hard Disk screen, choose the type of boot disk for the VM (VHD or
Passthrough). For VHD, specify the path to the C SV LUN. For Passthrough disks, select Attach
a virtual hard disk later and attach the disk later by updating the hardware configuration of
the VM.
13. Follow the wizard to complete the VM configuration.
The VM is now ready to be configured as an HA VM. The administrator may choose to install the guest
operating system at this time.
Page 27
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Enabling VMs as HA VMs
Virtual machines created on a host that is a part of a Hyper-V Host Cluster do not automatically
become HA VMs. The administrator has to choose to make VMs into HA VMs.
1
2
3
4
Make sure the VM that will be made an HA VM is either turned off or shut down.
Launch the Failover Cluster Management console for the system that is currently running
the VM.
On the console, click Configure a New Service or Application to launch the High
Availability Wizard.
When prompted by the wizard, choose Virtual Machine as the resource type and the
wizard will automatically list all the VMs that meet the basic requirements for an HA VM.
NOTE: If a specific VM is not listed here, make sure that VM has met all the pre-requisites for HA
VMs.
5
6
7
8
Select the appropriate VM and proceed with the configuration.
Upon completion, the High Availability wizard also generates a report of the HA VM
configuration that needs to be reviewed to make sure there were no issues.
The VM is now a HA VM and is ready to be turned on from either the Hyper-V Manager
console or the Failover Management console.
At the end of this configuration, the Failover Cluster Management console will list the
newly created Resource Group, Virtual Machine (n), for the HA VM. This Virtual
Machine (n) Resource Group will list all of the dependencies for the VM.
NOTE: It is recommended that you run the dependency report for the Resource Group to confirm
that the cluster service has made the right dependency mappings for the HA VM. Click on Show
Dependency Report available in the Failover Clustering console to generate this dependency report.
9
It is recommended t h a t y o u c h a n g e the name of the resource group from Virtual
Machine (n) to a name that more closely reflects the VM hosted within that group.
Migrating HA VMs across Hosts in the Cluster
With the VMs configured as HA VMs, they are now capable of handling both planned and unplanned
downtime scenarios. For unplanned downtime, the Failover Cluster service will take care of moving
the HA VMs on the other cluster nodes. For planned downtime scenarios, administrators can migrate
HA VMs to the other cluster nodes.
This activity is initiated from the Failover Cluster Management console.
1. Open the Windows Failover Cluster Management console and select the appropriate
Resource Group hosting the HA VM that needs to be migrated to another node.
2. Select Move virtual machine(s) to another node. The console will list the available target
nodes in the Hyper-V Host Cluster.
3. Select a target node and the HA VM will be migrated to, and started on, the target node
automatically.
Page 28
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Hyper-V Host Clusters on Server Core
Windows Server 2008 R2 offers a new installation option called Server Core that has a smaller
footprint installation on the operating system. The key benefits of choosing a Server Core
installation option include:
•
•
Reducing the amount of future patching due to its reduced footprint
Reducing attack surface because highly targeted roles such as InternetExplorer and
ExplorerShell are not available in a Core environment
Server Core does not present a local GUI interface. This may introduce some new challenges because
managing the system locally can only be done through a CLI. However, once a server running Server
Core has been set up for remote administration, all the roles and features installed on that server
(including Hyper-V and Failover Clustering) can be managed remotely using their respective GUIbased MMC consoles.
Setting up the Server Core System for Hyper-V and Failover Clustering
After the Server Core OS installation is complete, refer to the following documentation for guidance
on the initial configuration tasks as well as enabling the system for complete remote management:
•
•
•
Dell Solutions Overview Guide for Microsoft Hyper-V available at www.dell.com/hyperv
Server Core Installation Option of Windows Server 2008 R2 Step-By-Step Guide available
on the Microsoft website
Server Core Remote Management at http://technet.microsoft.com
To enable the Hyper-V Role and Failover Clustering features on all of the Server Core nodes, do the
following:
1. Use start /w ocsetup Microsoft-Hyper-Vto install the Hyper-V Role.
2. Use start /w ocsetup FailoverCluster-Coreto install the Failover Clustering
feature.
Refer to the following documents for configuring networking and shared storage on the Server Core
systems:
•
•
Dell Networking Solutions Guide for Microsoft Hyper-V available at
www.dell.com/hyper-v.
Dell Storage Solutions Guide for Microsoft Hyper-V available at www.dell.com/hyper-v.
Setting up Remote Management to Server Core
At a minimum, the following GUI consoles are required to remotely manage a Hyper-V Host Cluster:
•
•
Hyper-V Manager (virtmgmt.msc)
Failover Clustering Management (cluadmin.msc)
Both these consoles can be installed either on a Full install of Windows Server 2008 R2 (32-bit or
x64) or Vista (32-bit or x64) to remotely manage Hyper-V Host Clustering on Window Server 2008
Server Core.
Page 29
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Remote Management from Windows Server 2008 R2 Full Install
1. On the remote Windows Server 2008 R2 system (32-bit or x64), open Server Manager
(servermanager.msc), and click Add Features Wizard.
2. Under Select Features, choose the following:
–
Hyper-V Tools under Role Administration Tools.
–
Failover Clustering Tools under Feature Administration Tools.
3. Proceed with the installation of the selected features.
4. After installation is complete, the Hyper-V Tools and Failover Clustering Tools consoles are
available under Administrative Tools.
Remote Management from Windows Vista
1. Install the Remote Server Administration Tools (RSAT) for Windows Vista available for
download from the Microsoft website.
Separate packages are available for the x86 and x64 versions of Vista. RSAT is a collection of
tools that are meant to allow administrators to remotely manage the Windows server
environments including Windows Server 2008 R2.
2. To install the Hyper-V Manager MMC console on Vista, download the appropriate 32-bit or
x64 bit for KB952627.
3. Launch an MMC console (Start→Run and type MMC) and add the Failover Cluster
Management and Hyper-V Manager snap-ins to the MMC console.
Administering High Availability for Hyper-V
This section provides guidance on the common administrative tasks used to manage HA VMs in a
Hyper-V Host Cluster environment.
Changing the Configuration of HA VMs
Changes to a virtual machine configuration may or may not involve changing the hardware profile of
the VM. The steps required to successfully handle a configuration change for an HA VM differ
depending on whether or not the VM's hardware profile is changed.
For Configuring Changes that Impact the VM's HW Profile
These are the changes that require t h a t the VM be in an OFF or SHUTDOWN state. Examples of this
type of change include changing the number of virtual processors, changing virtual memory and
adding/removing network and storage controllers.
NOTE: We recommend that you use Failover Cluster Manager (FCM) instead of Hyper-V Manager when you change
the setting of a clustered virtual machine.
To successfully shut down or turn off an HA VM, use the VM control actions available in the Failover
Clustering MMC. Do not choose these actions from the Hyper-V Manager console because that will cause
the cluster service to automatically restart the HA VM to maintain its HA status. Once the HA VM is
shut down, use the Failover Clustering MMC to make a change, and then use the Failover Cluster
console to start the HA VM.
Page 30
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
NOTE: If you cluster your virtual machines and then use Hyper-V Manager to change the
configuration of one of those virtual machines, be sure to follow the procedure described below.
Otherwise, the settings of the virtual machine might not be up-to-date in the failover cluster, which
could cause problems during the next move, migration, or failover of that clustered virtual machine.
The high-level steps for making this type of configuration change for an HA VM are to refresh the
configuration:
•
•
•
•
Launch Failover Clustering MMC
Expand Services and Applications, and then click the virtual machine for which you want to
refresh the configuration.
In the Actions pane, scroll down, click More Actions, and then click Refresh virtual machine
configuration.
Click Yes to view the details of this action.
For Configuring Changes that DO NOT Impact the VM's HW Profile
These are the changes that can be done when the VM is running. Examples of this type of change
include changing the virtual network that a virtual network adapter is connected to or changing the
media type that is attached to a VM's DVD drive.
The Failover Cluster Management console provides an option on the right side Actions panel to
refresh virtual machine configuration for HA VMs. This option is meant to make sure that the cluster
service has the most up-to-date configuration information of the HA VM. Activity such as Quick
Migration of HA VMs may fail if the cluster service does not have the latest configuration information
of the HA VM. The Action option should be chosen whenever changes are made that DO NOT impact
the HA VM's HW profile.
Here are the high-level steps to make this type of configuration change for an HA VM:
1
2
Use the Hyper-V Manager console to update the HA VM's configuration information.
Use the Failover Cluster Management console to refresh virtual machine
configuration for that specific VM.
NOTE: The virtual machine will be taken offline for this action.
3
Validate the report generated by the wizard to confirm that the changes were
successful.
Adding Passthrough Disks to HA VMs
There are two prerequisites for adding additional passthrough disks:
•
•
The storage disk needs to already be a cluster resource as listed in Storage→Available
Storage in the Failover Cluster console.
The storage disk resource has to be owned by the same cluster node on which the HA
VM is currently running.
Ownership of HA resources can be verified using the Failover Cluster console. Check the Resource
Groups listed under Services and Applications to verify ownership of HA VMs and check the Storage
section to verify ownership of disk resources. If the physical disk resource listed under Available
Page 31
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Storage and the virtual machine resource are owned by separate nodes, one of the resources needs
to be moved so that they both are on the same node. If moving the VM is not a viable option, then
the storage resource can be moved using the CLI. For example, cluster group "Available
Storage"/move can be used to move storage disks across nodes.
Once the resources are owned by the same node, make sure the HA VM is either in the Offline or
Shutdown state and then proceed with adding the passthrough disk to the VM by updating the VM's
hardware configuration.
NOTE: In order to enable the above functionality, Hyper-V allows passthrough disks that are
already Available Storage cluster resources to be added to an HA VM. However, currently Hyper-V
does not check if a passthrough disk is already an allocated cluster resource before allowing it to be
added to an HA VM. Make sure that the correct passthrough disk is being attached.
NOTE: The passthrough disk cannot be expanded dynamically.
NOTE: Passthrough disks cannot be used as differencing disks.
NOTE: If a LUN will be used as a passthrough disk, the capability to take snapshots of that LUN is
lost.
Sharing LUNs Between HA VMs
Windows Failover Cluster allows multiple HA VMs to be hosted within the same Resource Group. This
is a critical requirement for scenarios such as when multiple HA VMs have VHD files on the same
storage LUN. However, careful consideration needs to be given before multiple HA VMs are hosted
within a single resource group, because resource groups failover as a single entity. All of the VMs
hosted on a single resource group will failover simultaneously.
Multiple VMs can share a storage LUN only if the VMs are using VHD based files rather than
passthrough disks. Use the following guidelines to add a new VM to an existing HA VM group:
1. If a Resource Group has not been created already, use the procedures from
“Implementing High Availability in Hyper-V” to create an HA VM, for example HA-VM1.
2. Create a new VM, for example HA-VM2, and place its VHD file on the same storage LUN
that was used by HA-VM1.
3. Use the Windows Failover Cluster console to make HA-VM2 also an HA VM.
4. The failover cluster service will automatically add HA-VM2 into the existing Resource
Group
HA VM Resource Group Names
By default, the cluster resource groups for HA VMs are created with generic names such as "Virtual
Machine (1)" and do not inherit the names of the VMs. This is expected behavior after 951308 QFE is
applied and was designed to avoid naming conflicts in resource groups as well as to accommodate the
scenario of a single resource group owning multiple HA VMs. Administrators can manually change
these Failover Cluster Resource Group names using the Failover Clustering MMC.
Cluster Resource Group for HA VMs Reported as "Partially Online"
When a Failover Cluster Resource Group contains more than one virtual machine and any of the
virtual machines are not in the Running state, the status of the Resource Group will be displayed as
Page 32
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Partially Online. Even a Resource Group with a single HA VM may report the status of Partially Online
when any of the dependent resources of that HA VM (such as a passthrough disk that is not hosting
the boot volume of the HA VM) is in an Offline state.
Configuring Rules for Associating Hosts to HA VMs
Failover Clustering in Windows Server 2008 R2 allows the administrator to set rules on how cluster
resources are managed among the nodes of the cluster. With Hyper-V HA VMs being managed by the
Failover Cluster as a cluster resource, rules can be set for resource groups that host HA VMs as well.
NOTE: Dell strongly recommends not changing the default settings except in special circumstances.
Setting Host Preferences for HA VMs
This capability in Failover Clustering allows the administrator to specify the order of preference for
cluster nodes that will host a HA VM. To set host preferences at a resource group level:
1. Open the Failover Clustering console, select Services and Applications, and right-click
the Resource Group that hosts the HA VM.
2. Select the General tab and set the order of preferences in the Preferred Owners list.
NOTE: The Failover tab allows the administrator to specify the failback behavior, which is based on
the Preferred Owners. It is recommended that failback be set to the default setting of Prevent Failback
in a production environment.
Blocking HA VMs from Running on Certain Hosts
This capability in Failover Clustering allows the administrator to block certain hosts from hosting a
specific HA VM. To block HA VMs at a resource group level:
1. Open the Failover Clustering console, select Services and Applications, and select the
Resource Group that hosts the HA VM.
2. Right-click the Virtual Machine resource, select the Advanced Policies tab and deselect the cluster nodes that should not host this specific virtual machine.
3. Repeat step 2 for all the other resources (Virtual Machine Configuration and Disk
Drives) in this resource group.
Converting an Existing Non-HA VM to a HA VM
The key requirement for a VM to be converted to a HA VM is that all of the VM’s files (including VHDs)
are on shared storage. “Implementing Hyper-V Host Clusters” walks through the high-level steps for
configuring HA VMs if the VM's files are already on shared storage and the disks can be made cluster
resources.
The following is high level guidance for converting a non-HA VM that has its files on a disk that cannot
be made a Windows Server 2008 R2 Failover Cluster resource, such as a local disk on a server or a disk
on an array that does not support Windows Server 2008 R2 Failover Clustering. In this scenario, the VM's
files have to be moved from the current location to storage LUN(s) that can be made cluster
resources. The recommended mechanism to move VM files is to use the Export/Import function in
Hyper-V.
Page 33
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
1. Provision a new storage LUN.
Bring the disk online on any one cluster node, initialize it, and format it as NTFS.
2. Use the Failover Cluster Management console to make this storage LUN a cluster
resource. Make sure that this LUN is listed under Storage→Available Storage.
3. From the Hyper-V Manager Console, select the non-HA VM, and export the VM files to
the newly provisioned storage LUN.
NOTE: If the storage LUN cluster resource is not owned by this node, the storage LUN will need to
be moved to the node that is currently running the VM before exporting the VM files.
NOTE: If you want the VM on CSV volume then you need to export the VM on cluster shared
volume, path appears on the system drive of the node, under the \ClusterStorage folder. All the LUN’s
in cluster shared volumes are mapped within this folder with a volume number.
4. After the export is complete, delete the existing non-HA VM using the Hyper-V Manager
console.
5. Use the import function to import the VM files from the shared storage LUN to the
same node.
6. Use the guidance provided under "Enabling VMs as HA VMs" to complete the
configuration of the HA VM.
Converting an HA VM to a Non-HA VM
To convert a HA VM to a non-HA VM requires that the VM files be exported before the files are removed
as cluster resources.
1. Use the Failover Cluster console to shut down or turn off the VM.
NOTE: Do not initiate these actions from the Hyper-V Manager console because the cluster service
will restart the VM to maintain the VM's HA state
2. From the Hyper-V Manager console, export the virtual machine to an alternate
location (such as a local hard disk). Once the export is complete, delete the existing
VM from Hyper-V Manager.
3. Use the Failover Clustering console to delete the VM resource group that is hosting the
HA VM. The VHD files have to be deleted manually from the shared storage.
4. From the Hyper-V Manager console, import the virtual machine from the location to
which it was exported in Step 2.
NOTE: If the resource group of an HA VM is deleted prior to exporting the VM files as
recommended above, Hyper-V Manager will de-register the VM and the VM will not be listed on the
console even though the files are still available on the disk. There is no mechanism to re-register the
VM. In such a scenario, the only recovery option is create a new virtual machine from the Hyper-V
Manager console and attach the VM to the existing VHD files or passthrough disks.
Page 34
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Using SMB/CIFS Shares in Hyper-V
Hyper-V allows the use of SMB/CIFS shares (file shares) to host VM resources such as ISO files or VHDs.
Use of SMB/CIFS shares is not recommended due to the performance limitations, but there might be
certain scenarios that benefit from their use. Consider the following when implementing SMB shares
in a HA environment:
•
•
•
•
Best practice recommendation when using an SMB share in Hyper-V HA environments is
to make sure that the file share is also a clustered resource so that it does not become
a single point of failure in the highly available environment.
It is strongly recommended that the file share be managed by a cluster that is separate
from the Hyper-V Host Cluster. If the file server resources are also hosted by the same
cluster, there may be issues during failover scenarios due to the file server resource not
being online when the dependent HA VM resources come online. This is especially true
when the same cluster node ends up owning the file server resource and the dependent
HA VM resource. For more information on configuring a file server cluster, download the
Microsoft document Step-by-Step Guide for Configuring a Two-Node File Server Failover
Cluster in Windows Server 2008 R2 from microsoft.com.
When a VM that uses file shares is made a HA VM, the High Availability Wizard might
generate a warning that the file shares are not clustered resources even when they are.
This is known behavior and this warning can be ignored.
When accessing SMB shares from the Hyper-V Hosts from UNC path, best practice is to
use the DNS name of the server hosting the share rather than the IP address of the
server hosting the share. For example, when mapping to a shared folder Share$ on
server FileServer.Domain.com, make sure that it is mapped using
\\FileServer.Domain.com\Share$.
NOTE: Hyper-V does not support file share access via a mapped drive.
•
Grant the appropriate permissions for the domain "Machine" account of all the Hyper-V
hosts that are part of the Hyper-V Host Cluster:
o The domain machine accounts (such as DOMAIN\COMPUTERNAME$) of all
Hyper-V cluster nodes are granted Full Control in the Share permissions of the
shared folder
o The domain machine accounts of all Hyper-V cluster nodes are granted Full
Control in the Security settings for the shared folder and all its files
•
In certain scenarios (such as remotely managing a Hyper-V server), the use of SMB
shares will require the use of constrained delegation. Refer to Step- by-Step Guide for
Configuring a Two-Node File Server Failover Cluster in Windows Server 2008 R2 from
microsoft.com.
Dell does not recommend the use of file shares to host VM files due to the performance
limitations. However, if you are using file shares, using a separate NIC is recommended.
•
Page 35
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Using Mount Points in Hyper-V
Failover Clustering in Windows Server 2008 R2 allows a single cluster with up to 16 nodes. Therefore,
you can have a single Hyper-V Host Cluster configuration of up to 16 servers. As shown in Figure 13,
one of the most common mechanisms to provision virtual disks to virtual machines is using VHD files
created on a formatted volume on a storage disk mounted in the parent partition with a drive
letter.
Figure 13.
Typical VHD Configuration on Storage Disk Assigned with a Drive Letter
In a Hyper-V Host Cluster configuration with many servers that host a large number of VHD-based
virtual machines, there may not be a sufficient number of drive letters (A-Z) in the parent partition
to host the storage LUNs. To work around this drive letter limitation, Hyper-V allows the use of Mount
Points to host storage LUNs.
Figure 14.
Typical VHD Configuration on Storage Disk Configured with a Mount Point
Page 36
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
In Figure 14, LUN A is not assigned a separate drive letter in the parent partition, but is instead
provisioned in the parent partition using the mount point C:\StorageDisk1. For specific step-by-step
information on configuring mount points, refer to the Microsoft documentation at
http://support.microsoft.com/kb/947021. Note that the use of mount points is an advanced
technique to provision storage, and careful consideration should be taken before using it broadly.
In a Hyper-V Host Cluster environment, there are two additional requirements prior to successfully
deploying HA VMs Hosts on mount points:
•
•
The Hyper-V and Failover Cluster Integration QFE (Microsoft KB951308 from
http://support.microsoft.com) has to be applied on all Hyper-V nodes as well as systems
running the Failover Cluster Management console. This is required for the High
Availability wizard to detect that virtual machine files are on a volume that is using a
mount point and not a drive letter.
If any one of the Hyper-V nodes has a volume using a mount point, it is essential that
all the Hyper-V nodes that are part of that Hyper-V Host Cluster have a folder with the
exact name so that a placeholder exists when the storage disk fails over to any of the
nodes. For example, in a configuration similar to that s h o w n in Figure 14, all nodes
should have a folder C:\StorageDisk1.
Hyper-V Host Clustering Data Template
The templates below provide guidance for data sheets that may be created to record information on
the Hyper-V Host Cluster deployment. Note that the sample information within the tables is only for
guidance.
Table 9.
Hyper-V Host Cluster Summary
Cluster Information
Cluster Solution
Hyper-V Host Cluster Name:
Hyper-V Host Cluster IP Address:
VM Workload Type:
Location:
Notes:
Table 10.
Node
Name
Hyper-V Host Cluster Nodes
Service
Tag
PowerEdge
Server
Model
Processor
Info
Full or
Core
Parent
Partition/
Public IP
Address
Private
IP
Address
Page 37
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Table 11.
Node Name
Table 12.
Hyper-V Host Cluster Network
Physical NIC
Information
Type
IP Address
LOM #1
Host
Management NIC
& Cluster Public
LOM #2
Hyper-V Virtual
Network
LOM #1
Hyper-V Virtual
Network
LOM #2
Live Migration
LOM #3
iSCSI Storage NIC
LOM #4
Cluster Private
LOM #5
iSCSI Storage NIC
Notes
Hyper-V Host Cluster HA VM Resource Group Information
VM Resource
Group
VMs in
Resource Group
Storage LUN
Resources
Group-A-VMs
VM#1
Cluster Disk 1
Notes
Cluster Disk 2
Group-B-VMs
VM#2
Cluster Disk 3
VM#3
Cluster Disk 3
Cluster Disk 4
Page 38
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
References
•
Dell Solutions for Windows Server 2008 R2 Hyper-V at www.dell.com/hyper-v
o Dell Virtualization Solutions Advisor Tool
o Dell Solutions Overview Guide for Microsoft Hyper-V
o Dell Networking Solutions Guide for Microsoft Hyper-V
o Dell Storage Solutions Guide for Microsoft Hyper-V
o Dell Virtualization Reference Architecture for Microsoft Hyper-V
Dell High Availability Cluster Solutions documentation at
http://docs.us.dell.com/support/edocs/systems/clusters
o HA Cluster Solutions featuring Dell Compellent Storage Center Fiber Channel Storage
o HA Cluster Solutions featuring Dell PowerVault Fiber Channel Storage
o HA Cluster Solutions featuring Dell PowerVault SAS/SATA Storage
o HA Cluster Solutions featuring Dell PowerVault and Dell Compellent Storage
Center iSCSI Storage
o HA Cluster Solutions featuring Dell|EqualLogic PS Series iSCSI Storage
•
•
•
•
•
•
Failover Clustering in Windows Server 2008 R2 at
www.microsoft.com/windowsserver2008/failover-clusters.mspx
Microsoft Step-by-Step Guide to Configure a Two-Node File Server Failover Cluster from
www.microsoft.com
Microsoft Step-by-Step Guide for Testing Hyper-V and Failover Clustering document at
www.microsoft.com
Hyper-V RTM Update - Microsoft KB950050 from http://support.microsoft.com
Hyper-V and Failover Cluster Integration QFE - Microsoft KB951308 from
http://support.microsoft.com
Requirements and Limits for Virtual Machines and Hyper-V in Windows Server 2008 R2
document at http://technet.microsoft.com/en-us/library/ee405267(WS.10).aspx
Page 39
Dell™ High Availability Solutions Guide for Microsoft® Hyper-V™
Glossary
Failover Clustering Console — The Microsoft Management Console (MMC) that is used to manage the
Failover Clustering feature (cluadmin.msc) in Windows Server 2008.
HA VM — A VM that has been configured as a Windows Failover Cluster resource.
Hyper-V Cluster Nodes — Windows Server 2008 R2 servers that have the Hyper-V role configured and are
part of a failover cluster.
Hyper-V Manager Console — The Microsoft Management Console (MMC) that is used to manage the
Hyper-V Virtualization Role on Windows Server 2008 R2.
LUN (Logical Unit Number) — In this solutions guide, a LUN refers to a unique disk that is provisioned
to a server from a storage enclosure or array.
MP IO — Multi-Path IO provides fault-tolerance and performance enhancements by implementing more
than one physical connection path from servers to storage.
Passthrough Disks — Physical disks (local disks or LUNs provisioned from SAN) that are configured
directly to VMs.
V M — A Hyper-V Virtual Machine.
Page 40
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising