The following is Part II of my three-part series on Hyper-V. You'll recall in <a href="http://egroup.jasonmangone.com/a-look-at-hyper-v-2012-part-i" target="_blank">Part I</a>, I evaluated the install process, hardware considerations, networking and virtual switches. Here. I'll take a deeper dive into failover clustering, clustered shared volumes and storage.

<strong>Failover Clustering</strong>
In order to get all of the benefits of High Availability and similar features that require the use of shared storage between your Hyper-V hosts in a “cluster,” you must install the Failover Clustering role on your Hyper-V hosts. This is, as the name indicates, what allows you the ability to “cluster” the hosts together.

Installing this role is just as easy as installing the Hyper-V role - simply check the box under the Features in the add new roles/features wizard, and it will run through the install. It's worth noting that the server on which you are installing the role <strong>must</strong> be a member of the domain at the time of installation, or it won't go through with the install.

Once the feature is installed and the server is rebooted, you must run through the Pre-Cluster Validation report, which will check out the hardware, drivers, etc. and alert you to anything that would prevent your cluster from working and/or being supported by Microsoft. See <a href="http://egroup.jasonmangone.com/a-look-at-hyper-v-2012-part-i" target="_blank">Part I</a> for the importance of having HCL-listed hardware.

From here, you create a new cluster, give it a name, an IP address, etc. and add your single node into it. Rinse and repeat to add additional hosts.

Any network interfaces that have an IP address assigned to them (as is usually the case for interfaces or NIC teams that are used for management, cluster heartbeats, or iSCSI storage access) will show up as Networks in the Failover Clustering management interface. You can rename them to be more readable, and as long as the subnets stay the same across hosts, all hosts can share those networks without having to do anything special to keep the names consistent.

Jumping ahead to the future state of a common Hyper-V 2012 deployment <strong>without</strong> System Center Virtual Machine Manager (SCVMM, which we'll mention in more detail later), the Failover Clustering management utility is where you will be able to migrate your virtual machines across nodes in your cluster.

<strong>Clustered Shared Volumes</strong>
To briefly define a “Clustered Shared Volume” to someone familiar with ESXi, consider it the equivalent of a VMFS datastore. It's essentially a unit of storage that is able to be accessed by multiple hosts at the same time, just like the VMware File System (VMFS) allows. It's similar to a clustered file system given the nature of its functionality, but it still runs Microsoft's well known NTFS as the underlying file system.

In order to add a CSV to a cluster, you present the storage as appropriate for your configuration and vendor's best practices, and it becomes available to the “Add Disk” wizard, as available and cluster-capable storage. Once it has been added, you can then right click it and select “Add to Clustered Shared Volume."

<strong>Storage</strong>
One of the bigger advantages VMware/ESXi still has over Hyper-V is its built-in, native multipathing capability. For those unfamiliar, NMP allows the use, failover, failback, and in some cases, load balancing/load distribution of all the paths to your shared storage array.

The only equivalent utility natively available in Hyper-V 2012 is the MPIO driver, which combines its use with the built-in iSCSI initiator. Microsoft has its own "generic device specific module," and you should check with your storage manufacturer to verify that using the Microsoft DSM is supported for access to the storage (EMC VNX IS supported).

For those who are familiar with and have used the VMware NMP beyond “install and let it run,” you know how incredibly valuable and efficient it is in nearly all deployment use cases (aside from NFS, which is a different beast entirely).

It's worth noting that storage vendors such as EMC provide their own multipathing plugins or software that you can use to provide highly enhanced, optimized path management, load balancing, and failover. In EMC's case, this software is their PowerPath V/E, or Virtual Edition, and it makes a great add-on to any Hyper-V 2012 + EMC Storage deployment.

Stay tuned tomorrow for Part III which will take a look at performance and management features with a final conclusion wrap up.