Dienstag, 25. Dezember 2012

Step-by-Step: Building a FREE Hyper-V Server 2012 Cluster

“The FREE Hyper-V Server 2012 sounds AWESOME! With the same features and scalability as the Hyper-V role in the full Windows Server 2012 OS, I could really use this to virtualize my application workloads very cost effectively. But … I need high availability too! HOW EASY IS IT TO CONFIGURE HYPER-V SERVER 2012 IN A CLUSTER?- Kris”

Great question, Kris! Configuring our FREE Hyper-V Server 2012 in a highly available cluster can be really easy. In this article, I’ll step through the configuration of a Hyper-V host cluster configuration that uses Hyper-V Server 2012 so that you'll have the details to step through this process in your own lab environment.

In Part 2 of this article series, I’ll finish up with the steps needed to provision and test a highly available virtual machine within your new cluster.

Let’s start with a common scenario …

In this article, we’ll be building a small 2-node Hyper-V Server 2012 host cluster, but the same steps below can be applied to much larger cluster configurations – the FREE Hyper-V Server 2012, like Windows Server 2012, supports up to 64 physical nodes and up to 8,000 virtual machines per cluster.

To build the operating system on each of the Hyper-V hosts, we can leverage the Getting Started Guide to perform the following basic post-installation configuration tasks using the SConfig.cmd script:

Set static IP address information on each NIC

I’d recommend at least three (3) physical NICs for each cluster host as follows:

One NIC for cluster management and storage

Connect to a local storage subnet and do not set a default gateway address

Note that NIC teaming should not be used for storage networks using iSCSI. Instead, if more bandwidth and/or resiliency is needed than a single NIC can provide, consider using multiple NICs or iSCSI HBAs with MPIO configured.

One NIC or NIC Team for live migration traffic

Connect to a local live migration subnet and do net set a default gateway address

Note: If you are interested in leveraging NIC teaming on your Hyper-V hosts to create high bandwidth resilient network connections for live migration and client network traffic interfaces, see this study guide on configuring NIC teaming from our “Early Experts” study group.

Set a desired computer name on each host

Join each host to an Active Directory domain

Note that Active Directory is required for normal operation of Failover Clustering in Hyper-V Server 2012 and Windows Server 2012. However, the product team has enhanced clustering a bit so that a cluster can now be brought online in disaster recovery situations where Active Directory may not be available on the network.

Enable Remote Management and Remote Desktop

Once you’ve gone through these steps, you should now have two standalone Hyper-V hosts that are ready to be configured as part of a cluster.

But wait! I need Shared Storage, Don’t I?

Yes, indeed – for Hyper-V Host Clusters you’ll need to provide shared storage in one way or another that each Hyper-V host can access for storing highly available VM’s. Commonly, shared storage between Hyper-V hosts in a cluster can be provided via:

If you already have an investment in FC or iSCSI SAN storage, Windows Server 2012 and Hyper-V Server 2012 will certainly continue to support those array options as shared storage solutions – in fact, with new features, like support for Offloaded Data Transfer (ODX), newer intelligent SAN arrays can perform amazingly better than ever with Windows Server 2012 and Hyper-V Server 2012!

However, if you haven’t invested yet in an intelligent SAN array for shared storage, SAS and SMB 3.0 can be cost-effective shared storage alternatives worth your consideration for a Hyper-V host cluster.

SAS? SMB? I don’t recognize those as shared storage options for VMs!

Support for shared SAS enclosures and SMB 3.0 shared folders as shared storage options for VMs in a cluster is new with Windows Server 2012 and Hyper-V Server 2012. Both options can provide cost effective alternatives to more expensive intelligent SAN arrays.

SAS enclosures are supported as shared storage in a failover cluster via our new Storage Spacessubsystem in Windows Server 2012 and Hyper-V Server 2012. Along with OEM partners, we’ve demonstrated SAS solutions based on Storage Spaces that have achieved ~1 Million IOPs using commodity storage components.

SMB 3.0 has been enhanced in Windows Server 2012 and Hyper-V Server 2012 for large amounts of random IO in big files, such as what you’d typically find with VM’s hosted in a shared folder, andcontinuous availability of shared folders when configured in a Windows Server 2012 file services cluster. In fact, when leveraging hardware that supports SMB Direct, our testing has shown that SMB storage traffic can be within 2% of the performance of direct attached storage!

Both of these options can simplify shared storage configurations tremendously by leveraging commodity storage components over easily configured interfaces.

It’s SMB 3.0 for ME!

I already have a Windows Server 2012 Failover Cluster that supports a number of clustered File Services roles in my environment, so I’ll be using SMB 3.0 shared folders as shared storage locations for my Hyper-V host cluster in this article. I’ll create two “continuously available” shared folders on one of my clustered File Services roles as follows:

\\CAFSC01\HVCVMWitness – this clustered shared folder will be used as a witness by the new Hyper-V host cluster. A witness is a special resource that is used when a physical cluster node fails to determine which node is the “surviving” node to which clustered resources should failover. In particular, it’s important to use a witness resource when you have an even number of physical nodes within your cluster, as we do in this 2-node cluster scenario.

\\CAFSC01\HVCVMStorage – this is a shared folder that I will use as a storage location for highly available virtual machines that I provision in the Hyper-V host cluster.

Note that each of your Hyper-V Server 2012 computer accounts in Active Directory will need to be granted Full Permissions to each of these shared folders and the underlying NTFS folder structure.

Let’s Build Our Hyper-V Host Cluster!

OK … now that we’ve got the basic infrastructure needs addressed, let’s start off by installing the Failover Clustering feature on each Hyper-V host and configuring an external Virtual Network Switch for VM network traffic. Then we can move on to validating and configuring our new cluster.

Note: We can configure a Hyper-V host cluster remotely by using the Failover Cluster Manager GUI tool from a remote Windows Server 2012 management host or a Windows 8 admin client with the Remote Server Admin Toolkit (RSAT) installed. However, in this article, I’ll make the assumption that you’ll be doing all of the cluster configuration from the Hyper-V Server 2012 host consoles directly using PowerShell … It’s really very easy!

On our Hyper-V Server 2012 consoles, we can configure our new Hyper-V host cluster by using a bit of PowerShell as follows:

Install the Failover Clustering feature on each Hyper-V Server 2012 host using the Install-WindowsFeature cmdlet:

Configure an external virtual network switch on each Hyper-V Server 2012 host. Be sure to use exactly the same virtual switch name on each host. You can use the Get-NetAdapterName cmdlet first to verify the name of each network adapter to make sure you select the correct NIC for binding to the new virtual switch.

Get-NetAdapterNameNow that I know the name of my network adapter, I’m going to use the New-VMSwitch cmdlet to configure a new external switch named KEMLABNET01.

Next, let’s validate the configuration of our Hyper-V Server 2012 hosts to make sure they are compatible with a cluster configuration by using the Test-Cluster cmdlet. For my new cluster, my individual Hyper-V host computer names are KEMLABHV06 and KEMLABHV07.

That’s it! Our new Hyper-V host cluster is now built!

This command should show that our Cluster Group resource group is online on one of our nodes. Note that the Available Storage cluster resource group may show as Offline because in our configuration above, we aren’t using any shared disk storage – just SMB 3.0 shared folders!

What’s Next? Your Turn!

Complete the process outlined above to build out your own Hyper-V Host Cluster

In Part 2 of this article series, I’ll step through provisioning and testing new virtual machines that are highly available on our new Hyper-V host cluster.

In the meantime …

Be sure to check out our “Early Experts” study group and our new “Virtualizer Quest" athttp://aka.ms/EarlyExpertsVirtualizer. The Virtualizer Quest includes structured study guides that walk through configuring the other new features associated with the Hyper-V role in Windows Server 2012 and Hyper-V Server 2012.

Are you ready to Cluster?

Did the article help you prepare for clustering Hyper-V hosts in your environment? Be sure to leave your feedback, questions and comments below!

This article is Part 2 in a two-part series on building a FREE Hyper-V Server 2012 Cluster to support highly available virtual machines as a foundation to a Private Cloud solution. If you missed it, be sure to check outPart 1 of this article series on the initial steps for building Hyper-V Server 2012 hosts in a Failover Cluster configuration.

In this article, we’ll walk through provisioning highly available virtual machines on our new FREE Hyper-V Server 2012 cluster and testing Live Migration failover scenarios.

It’s Time to Build Highly Available VMs!

Now that we have our Hyper-V failover cluster up and running, it’s time to provision our virtual machines in a highly available configuration. Once provisioned in this manner, highly available virtual machines can failover to other physical nodes within our cluster in both planned and unplanned failover scenarios.

If you’ve installed the Hyper-V Manager and Failover Cluster Manager GUI tools on a Windows Server 2012management server or Windows 8 admin workstation, you can easily perform these steps remotely using these tools. See my article on the Remote Server Admin Toolkit for Windows Server 2012 to learn how to setup a Windows 8 admin workstation for remote management of Windows Server 2012 and Hyper-V Server 2012 hosts.

However, in this article, we’ll assume that you’ll be performing these tasks from the console of your Hyper-V Server 2012 hosts using our built-in Hyper-V cmdlets and Failover Clustering cmdlets in PowerShell 3.0. PowerShell 3.0 ROCKS and is really quite easy to use for these tasks as you’ll see below.

Here’s the steps that we’ll be using to build each highly available virtual machine:

Create new Virtual Hard Disks (VHDs or VHDXs) in a shared storage location that is accessible to your clustered configuration.

As you may recall from my Part 1 article, we’re using the new SMB 3.0 shared application folder functionality to provide a shared storage location for our highly available VM’s. To create a new virtual hard disk in this shared location, I’ll use the New-VHD cmdlet in PowerShell 3.0:

New-VHD -Path \\CAFSC01\HVCVMStorage\HAVM01.VHDX -Dynamic -Size 127GB

Now that we have our Virtual Hard Disk(s) sitting in a shared storage location that is accessible from our clustered hosts, next we’ll use the New-VM cmdlet to provision each new Virtual Machine in the same shared storage location:

After each new Virtual Machine is provisioned, we can use additional cmdlets, such as Set-VM, Add-VMDvdDrive and Add-VMHardDiskDrive, to set additional VM settings and/or attach additional virtualized storage devices, as necessary.

Since my new Virtual Machine in this example is using a blank Virtual Hard Disk for its storage, I’ll attach an ISO image as a DVD boot device to this VM so that I can install Windows Server 2012 when this VM starts up for the first time:

Add-VMDvdDrive -VMName HAVM01 -Path \\CAFSC01\ISO\WS2012RTM.ISO

Since the Failover Cluster manages the startup and failover of highly available VMs, we’ll want to disable the Hyper-V Automatic Start Options for each of our VMs in this scenario. This will prevent Hyper-V from trying to directly manage the startup of these VMs and instead rely on the cluster for startup and failover tasks:

Set-VM -Name HAVM01 -AutomaticStartAction Nothing

Our VM’s are now setup with the necessary VM configuration settings. To add our new VMs to the cluster and make them highly available, we’ll now use the Add-ClusterVirtualMachineRole cmdlet as follows:

Add-ClusterVirtualMachineRole -VirtualMachine HAVM01

Once you’ve setup your new highly available VM’s you can check their status and bring them online with the following cmdlets:Get-ClusterGroup

Start-ClusterGroup –Name “HAVM01”

Your Virtual Machines will start up and you can now connect to their consoles via the VMConnect.execommand-line tool from a remote Windows Server 2012 management server or Windows 8 admin workstation. VMConnect is included with the Hyper-V Management GUI tools.

VMConnect.exe <Hyper-V Host> <Virtual_Machine_Name>

We can use our VMConnect remote console connection to complete the installation and configuration of the Guest OS within each new virtual machine.

We’re finished … Let’s Test!

Our highly available VMs are up and running in our cluster, so let’s test our failover cluster with a Live Migration planned failover using the Move-ClusterVirtualMachineRole cmdlet. I’ll move one of my highly available VMs to the second physical node in my cluster live while it’s running with the following command line syntax:

Move-ClusterVirtualMachineRole -Name "HAVM01" -Node KEMLABHV07

Now it’s Your Turn! Are you Clustered Yet?

Download our FREE Hyper-V Server 2012 using the link below and step through the commands in Part 1 andPart 2 (this article) of this article series to build your own Hyper-V Cluster with highly available VMs.