If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
Introduction
You probably know that with Windows Server 2008 R2, you could create clusters of up to 16 nodes. If you wanted to run a Hyper-V failover cluster, you could have up to 1,000 virtual machines across all the nodes in the cluster. The only limitation was that any single node in the cluster was limited to running a max of 384 VMs. In Windows Server 2012, you can have up to 64-nodes in the cluster and up to 4,000 VMs across the entire cluster. And that’s not all; a single node in the cluster can now run a max of 1,024 virtual machines. Note that the 4000 VM limit is independent of the number of nodes in the cluster. Regardless of whether there are two nodes or 64 nodes, you are still limited to 4000 VMs. But hey, that’s a lot of VMs.
Windows Server 2012 also enables you to save money on software, because Failover Clustering is now included in Windows Server 2012 Standard Edition. You’ll remember that prior to Windows Server 2012, Failover Clustering was only available in Windows Server Enterprise and Datacenter, which are considerably more expensive. By the way, also note that that Windows Server 2012 doesn’t include an Enterprise version – there are only Windows Server 2012 Standard and Enterprise to choose from. That should simplify your decision-making. Now that Failover Clustering is available in Standard Edition, even small and medium businesses can take advantage of virtualization and high availability of the feature without breaking the bank.
Updating a Failover Cluster Has Never Been Easier!
If you’ve deployed failover clustering in the past, you know that applying security updates and other fixes to cluster nodes has always been a challenge. It was a complex process that either required you to do it manually or have some pretty fancy scripting skills. Well, your life just got a little easier. In Windows Server 2012, there is a new Cluster-Aware Updating (CAU) feature that automates the cluster updating process.
Cluster-Aware Updating can be initiated manually, where the cluster admin starts an update using either the CAU User Interface or using PowerShell cmdlets. Another option is to run updates on a pre-configured schedule. Cluster-Aware Updating works with Windows Update or Windows Server Update Services (WSUS). When CAU runs, it moves all VMs from a node in the cluster, using either Quick or Live Migration, then places the nodes in Maintenance Mode so that workloads aren’t moved to it during the update, and then downloads and installs updates and will reboot the node if required. When the update process is complete, it will take the node out of Maintenance Mode and migrate the workloads to the updated node. The process repeats itself until all nodes in the cluster have been updated.
Hyper-V and Failover Clustering – Two Great Tastes that Taste Great Together
Microsoft has done a great deal of work to integrate Failover Clustering and Hyper-V in Windows Server 2012. This is important because Windows Server 2012 is considered a cloud operating system and Failover Clustering of Hyper-V arrays is a critical piece of the Infrastructure as a Service (IaaS) component of Windows Server 2012 in the cloud.
Windows Server 2012 imbues Hyper-V Failover Clusters with the following capabilities:
- Enhanced Virtual Machine Mobility
VM mobility is critical in a private cloud environment – and represents the heart of cloud computing. Windows Server 2012 Failover Clustering enables several VM mobility options and supports Live Migration, Quick Migration, Storage Migration and Hyper-V Replica. You could do Quick migration with Windows Server 2008. You could do Live Migration with Windows Server 2008 R2. With Windows Server 2012, you can still do Quick Migration and Live Migration, but the latter has been improved so that you can do more than one simultaneous Live Migration at a time within the same cluster.
Windows Server 2012 also has two new VM migration capabilities: Storage Migration and Hyper-V Replica. Storage Migration allows you to move VM storage to a different location while keeping the VM compute component on the same node in the cluster. You can even do this while the virtual machine is still running. Another new and cool VM mobility feature is Hyper-V Replica, which is a disaster recovery tool. With Hyper-V Replica, you can replicate VMs between source and destination Hyper-V servers, which can be located anywhere. Changes to the VMs are replicated to the Replica Hyper-V servers every 5 minutes. If there is a failure on the primary Hyper-V server, you can quickly start the VM on the replica Hyper-V server and the data loss will be limited to less than the last five minutes.
- Intelligent Monitoring of Applications Hosted on Guest VMs
Hyper-V and Failover Clustering make possible higher availability to workloads running in VMs by providing a way for you to monitor applications running inside the VMs from the host Hyper-V server. Using this method of host-based monitoring, Hyper-V and Failover Clustering can detect whether services that are running in the VMs are running correctly and if they are not, enable automatic actions such as restarting the entire virtual machine or just restarting the service running in the VM.
- New Guest Clustering Options
You can create a guest cluster by running the Failover Clustering Role in the VMs that are running in your physical cluster. In fact, you can create a guest cluster on Hyper-V servers that aren’t even members of a physical cluster. Prior to Windows Server 2012, storage for guest clusters could only use iSCSI for shared storage. With Windows Server 2012, you can use up to 4 Virtual Fibre Channel HBAs per node in your guest cluster. Note that the HBA on the Hyper-V host must meet certain requirements, such as support for NPIV. NPIV (N_Port ID Virtualization) is used to expose the Guest ports on the HBA to the Hyper-V server.
- Improved Placement after Failover
Moving large numbers of VMs from one or more nodes in a cluster to other nodes used to be difficult prior to Windows Server 2012. Now moving VMs can be triggered and done on a controlled basis or in response to a failure. Windows Server 2012 has the intelligence to determine the resources (such as memory) that are available on each cluster node before making placement decisions.
- Prioritized VM Failover
You can set VM priorities to control the order in which virtual machines fail over or power up. This enables you to give higher priority VMs the resources they need while lower priority VMs are given resources as they become available. This makes for an efficient transition process for cluster workloads.
New Active Directory Support and Integration
With Failover Clustering in Windows Server 2008, the creation of a Client Access Point (CAP) in a cluster resulted in computer objects being created in Active Directory. These cluster related objects became the new security context for the cluster. This meant that the cluster service did not run in the context of a domain user account. With Windows Server 2012, that changes. The cluster service runs using a local system account on each cluster node.
There are a number of areas where Windows Server 2012 Failover Clustering works better with Active Directory, too. Some of these include:
- Support for Read Only Domain Controllers (RODCs) – In Windows Server 2012, you can use RODCs to support your Failover Clusters. This makes it possible for you to put clusters in DMZs and Branch Offices in a more secure fashion.
- The ability to easily recover from the accidental deletion of a Virtual Computer Object (VCO) – If the computer VCO corresponding to a Client Access Point is deleted, you can initiate a repair action to automatically recreate the computer object in Active Directory.
- Smart placement of computer objects – The CNO is created in the same OU as the nodes in the cluster and the VCOs are created in the same OU as the CNO. That means no mixing and matching.
- Starting the Cluster without Active Directory accessible – Prior to Windows Server 2012, the Failover Clustering service had to connect to a domain controller before it could start. As you can imagine, this could be challenging if you were running your DCs in VMs. The situation was even worse when the virtualized domain controllers were located on a Cluster Shared Volume (CSV) that used NTLM to authenticate with a domain controller. In Windows Server 2012, this problem is fixed. The cluster nodes don’t need to communicate with domain controllers in order to start up and enable the CSVs.
- Protection against accidental deletion of the Cluster Name Object (CNO). When you create clusters in Windows Server 2012, the Computer Object matching the Cluster Name Object is marked so that accidental deletion is prevented and it requires the Domain Admin to take additional action to delete it.
Summary
In this first part of a two-part article, we took a look at some of the new and cool features that are included in the Windows Server 2012 Failover Clustering Role. In the second part of this article, we’ll finish up with the introduction to new features and then in subsequent articles, we’ll go into detail discussing many of these features so that you can get a taste of how amazing Windows Server 2012 really is and how it makes cloud computing possible in your own datacenter. See you then! –Deb.
If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
