Failover clustering is the feature in Windows Server that gives us high availability (HA) – that is, it allows us to make single instance services highly available. Possible implementations include clusters of Hyper-V hosts and traditional active/passive SQL clusters. Today I’ll go over the number of improvements that have been added to failover clustering in Windows Server 2012 R2.
In Windows Server 2012, the correct process to shut down a host was to (a) pause the host, which would cause the VMs to move via Live Migration (or Quick Migration for low priority VMs by default) and (b) shut down the host. Some would just shut down the host and get an unexpected and unpleasant result – all of the VMs would use Quick Migration to move to other hosts in the cluster. In Windows Server 2012 R2, a clustered node will use Live Migration to drain the VMs before shutting down. This can be slower than Quick Migration on densely populated hosts, but it gives administrators the experience they are expecting. Failback will not happen by default, but it can be configured.
Clustering will check the health of a destination host before moving a VM to another host.
A cluster will check the health of a virtual switch network connection on a destination host before moving virtual machines to that host. This will prevent movement of VMs to a host that cannot connect services to the network.
A cluster will automatically balance ownership of CSVs across all nodes in the cluster.
There is much more recorded information when adding or removing a cluster node, and when the state of a clustered resource changes.
A number of storage features are now supported by CSV:
By default, a failover cluster (all kinds) in WS2012 will perform a heartbeat once per second, with a five second timeout. Some felt that occasional glitches in networking could lead to a heavy response: automated failover of virtual machines that were working just fine. In WS2012 R2, a failover cluster will change this when you first add a VM as a highly available resource. The cluster heartbeat timeout will be automatically increased to ten seconds, meaning that brief issues with packet loss on the cluster networks will not failover virtual machines. This Hyper-V cluster timeout will be 20 seconds when the cluster nodes span more than one subnet.
The validation process has been improved in several ways:
The GUM manages the process of synchronizing settings across all nodes in a cluster. Changes are sent out to all nodes; prior to WS2012 R2, every node must acknowledge the change before it is implemented. In very large (up to 64 nodes in a cluster) or multi-site clusters this change process could be interfered with by cluster network congestion. In WS2012 R2, the GUM requires only a majority of nodes to acknowledge the update. Updates to application clusters are typically uncommon. Therefore this feature change is implemented only in Hyper-V clusters – that is, when you add the first virtual machine resource to a cluster of Hyper-V nodes.
In all previous versions of clustering, you had to manually change the use of a witness based on the number of nodes (odd or even) in the cluster to break the quorum vote (used to determine if a fragment of the cluster continue operating). Now with WS2012 R2 you will always configure the witness disk. The cluster will decide if it should use the witness or not based on the odd/even count of nodes to ensure that there are an uneven number of quorum votes.
Multi-site clusters are often split 50/50 across two sites. This can cause an issue when half of the cluster goes offline. WS2012 R2 clusters can survive losing 50% of the cluster at once. One site will automatically lose (non-authoritative site), using a LowerQuorumPriorityNodeID cluster quorum property. This will be useful where the company needs a multi-site cluster and cannot deploy a file-share witness in a third site.
A new ForceQuorum setting will allow you to set an authoritative site on a site in a multi-site cluster for when a split-brain situation happens – that is, when communications break down between sites, and the cluster nodes must decide which site should remain active.
A SQL server cluster can be deployed without the use of Active Directory computer objects. This assumes the SQL Server databases will use SQL authentication, and not Windows authentication.
A guest cluster allows you to make services highly available within the guest OS of 2 or more virtual machines. These virtual machines typically need access to some kind of shared storage. Initially this required complicated networking for iSCSI communications. Windows Server 2012 allows us to use SMB 3.0 or virtual fiber channel. This was a great step forward but it introduces a challenge in cloud computing. The boundary between the virtual layer (the tenant) and the physical layer (the service provider) is blurred. This blurring is particularly challenging because facilitating shared storage with iSCSI, SMB 3.0, or fiber channel requires infrastructure engineering and therefore contradicts the self-service requirement of a cloud.
Windows Server 2012 R2 adds a virtual alternative to offer shared storage. Up to 8 virtual machines can be connected to shared VHDX files. This gives us an all-virtualization solution that is suitable for self-service in a cloud. The shared VHDX must be stored on an SMB 3.0 share or a CSV. The hosts that are running the virtual machines must be clustered. The clustered hosts must not necessarily in the same cluster; this scenario requires storing the shared VHDX file(s) on an SMB 3.0 share that is used by all of the involved host clusters.