Export (0) Print
Expand All
20 out of 25 rated this helpful - Rate this topic

What's New in Failover Clustering in Windows Server 2012 R2

Published: June 24, 2013

Updated: July 31, 2013

Applies To: Windows Server 2012 R2



This topic describes the Failover Clustering functionality that is new or changed in Windows Server 2012 R2.

Failover clusters provide high availability and scalability to many server workloads. These include server applications such as Microsoft Exchange Server, Hyper-V, Microsoft SQL Server, and file servers. The server applications can run on physical servers or virtual machines. In a failover cluster, if one or more of the clustered servers (nodes) fails, other nodes begin to provide service. This process is known as failover. For an overview of the Failover Clustering feature, see Failover Clustering Overview.

The following table and sections summarize key Failover Clustering functionality in Windows Server 2012 R2 that is new or changed since Windows Server 2012.

 

Feature/Functionality New or Improved Description

Shared virtual hard disk (for guest clusters)

New

Enables you to use .vhdx files as shared storage in a guest cluster.

Virtual machine drain on shutdown

New

Enables a Hyper-V host to automatically live migrate running virtual machines if the computer is shut down.

Virtual machine network health detection

New

Enables a Hyper-V host to automatically live migrate virtual machines if a network disconnection occurs on a protected virtual network.

Optimized CSV placement policies

Improved

Distributes CSV ownership evenly across the failover cluster nodes.

Increased CSV resiliency

Improved

Multiple Server service instances per cluster node and CSV monitoring of the Server service provide greater resiliency.

CSV cache allocation

Improved

Increases the amount of RAM that you can allocate as CSV cache.

CSV diagnosibility

Improved

Enables you to view the state of a CSV on a per node basis, and the reason for I/O redirection.

CSV interoperability

Improved

Adds CSV support for other Windows Server 2012 R2 features.

Deploy an Active Directory-detached cluster

New

Enables you to deploy a failover cluster with less dependency on Active Directory Domain Services.

Dynamic witness

New

Dynamically adjusts the witness vote based on the number of voting nodes in current cluster membership.

Quorum user interface improvements

Improved

Enables you to easily view the assigned quorum vote and the current quorum vote for each node in Failover Cluster Manager.

Force quorum resiliency

New

Enables automatic recovery in the case of a partitioned failover cluster.

Tie breaker for 50% node split

New

Enables one side of a cluster to continue to run in the case of a cluster split where neither side would normally have quorum.

Configure the Global Update Manager mode

New

Helps the cluster to continue to function if there is a delay with one or more nodes.

Cluster node health detection

Improved

Increases the resiliency to temporary network failures for virtual machines that are running on a Hyper-V cluster.

Turn off IPsec encryption for inter-node cluster communication

New

Helps prevent a cluster from being affected by high latency Group Policy updates.

Cluster dashboard

New

Provides a convenient way to check the health of all managed failover clusters in Failover Cluster Manager.

The following section provides a summary of new highly available virtual machine functionality in Windows Server 2012 R2.

You can now share a virtual hard disk file (in the .vhdx file format) between multiple virtual machines. You can use these .vhdx files as shared storage for a virtual machine failover cluster, also known as a guest cluster. For example, you can create shared .vhdx files for data disks and for the disk witness. (You would not use a shared .vhdx file for the operating system virtual hard disk.)

What value does this change add?

In Windows Server 2012, you could deploy guest clusters using shared storage that was provided by virtual Fibre Channel or iSCSI to the guest operating system. In these configurations, the underlying storage was exposed to the user of a virtual machine. In private or public cloud deployments, there is often the need to hide the details of the underlying fabric from the user or tenant administrator. Shared .vhdx storage provides that layer of abstraction.

This change also enables easier deployment of guest cluster configurations. A shared .vhdx file configuration is easier to deploy than solutions like virtual Fibre Channel or iSCSI. When you configure a virtual machine to use a shared .vhdx file, you do not have to make storage configuration changes such as zoning and LUN masking.

What works differently?

In Windows Server 2012, shared virtual hard disks are not available. Windows Server 2012 R2 adds this functionality.

In Windows Server 2012 R2, virtual SCSI disks now appear as virtual SAS disks when you add a SCSI hard disk to a virtual machine. This includes both shared and non-shared virtual hard disk files. For example, if you view the disk in Server Manager, the bus type is listed as SAS.

For more information about shared virtual hard disks, see Virtual Hard Disk Sharing Overview and Deploy a Guest Cluster Using a Shared Virtual Hard Disk.

In Windows Server 2012 R2, if you shut down a Hyper-V failover cluster node without first putting the node into maintenance mode to drain any running clustered roles, the cluster now automatically live migrates all running virtual machines to another host before the computer shuts down.

noteNote
Make sure that there is not more than one virtual machine in a virtual machine clustered role. Starting with Windows Server 2012, we do not support this configuration. An example of this scenario is where multiple virtual machines have files on a common physical disk that is not part of Cluster Shared Volumes. A single virtual machine per clustered role improves the management experience and the functionality of virtual machines in a clustered environment, such as virtual machine mobility.

What value does this change add?

This change provides a safety mechanism to help ensure that a server shutdown (or any action that shuts down the Cluster service) does not cause unplanned downtime for running virtual machines. This increases the availability of applications that run within the guest operating system.

ImportantImportant
We still recommend that you put a node into maintenance mode or move all virtual machines to other nodes before you shut down a cluster node. This is the safest way to drain any running clustered roles.

What works differently?

In Windows Server 2012, if you shut down a cluster node without first draining the node, the virtual machines are put into a saved state, and then moved to other nodes and resumed. This means that there is an interruption to the availability of the virtual machines. If it takes too long to save state the virtual machines, they may be turned off, and then restarted on another node. In Windows Server 2012 R2, the cluster automatically live migrates all running virtual machines before shutdown.

To enable or disable this functionality, configure the DrainOnShutdown cluster common property. By default, this property is enabled (set to a value of "1").

To view the property value, start Windows PowerShell as an administrator, and then enter the following command:

(Get-Cluster).DrainOnShutdown

Network health detection and recovery is now available at the virtual machine level for a Hyper-V host cluster. If a network disconnection occurs on a protected virtual network, the cluster live migrates the affected virtual machines to a host where that external virtual network is available. For this to occur there must be multiple network paths between cluster nodes.

noteNote
If there are no available networks that connect to other nodes of the cluster, the cluster removes the node from cluster membership, transfers ownership of the virtual machine files, and then restarts the virtual machines on another node.

What value does this change add?

This change increases the availability of virtual machines when there is a network issue. If live migration occurs, there is no downtime because live migration maintains the session state of the virtual machine.

What works differently?

In Windows Server 2012, if there is a network disconnection at the virtual machine level, the virtual machine continues to run on that computer even though the virtual machine may not be available to users.

In Windows Server 2012 R2, there is now a Protected network check box in the virtual machine settings. This setting is available in the advanced features of the network adapter. By default, the setting is enabled. You can configure this setting on a per network basis for each virtual machine. Therefore, if there is a lower priority network such as one used for test or for backup, you can choose not to live migrate the virtual machine if those networks experience a network disconnection.

Protected network setting for a virtual machine

Figure 1.  Protected network setting

The following section provides a summary of new CSV functionality in Windows Server 2012 R2.

CSV ownership is now automatically distributed and rebalanced across the failover cluster nodes.

What value does this change add?

In a failover cluster, one node is considered the owner or "coordinator node" for a CSV. The coordinator node owns the physical disk resource that is associated with a logical unit (LUN). All I/O operations that are specific to the file system are through the coordinator node. Distributed CSV ownership increases disk performance because it helps to load balance the disk I/O.

Because CSV ownership is now balanced across the cluster nodes, one node will not own a disproportionate number of CSVs. Therefore, if a node fails, the transition of CSV ownership to another node is potentially more efficient.

This functionality is useful for a Scale-Out File Server that uses storage spaces because it ensures that storage spaces ownership is distributed.

What works differently?

In Windows Server 2012, there is no automatic rebalancing of coordinator node assignment. For example, all LUNs could be owned by the same node. In Windows Server 2012 R2, CSV ownership is evenly distributed across the failover cluster nodes based on the number of CSVs that each node owns.

Additionally in Windows Server 2012 R2, ownership is automatically rebalanced when there are conditions such as a CSV failover, a node rejoins the cluster, you add a new node to the cluster, you restart a cluster node, or you start the failover cluster after it has been shut down.

Windows Server 2012 R2 includes the following improvements to increase CSV resiliency:

  • Multiple Server service instances per failover cluster node. There is the default instance that handles incoming traffic from Server Message Block (SMB) clients that access regular file shares, and a second CSV instance that handles only inter-node CSV traffic. This inter-node traffic consists of metadata access and redirected I/O traffic.

  • CSV health monitoring of the Server service

What value does this change add?

A CSV uses SMB as a transport for I/O forwarding between the nodes in the cluster, and for the orchestration of metadata updates. If the Server service becomes unhealthy, this can impact I/O performance and the ability to access storage. Because a cluster node now has multiple Server service instances, this provides greater resiliency for a CSV if there is an issue with the default instance. Additionally, this change improves the scalability of inter-node SMB traffic between CSV nodes.

If the Server service becomes unhealthy, it can impact the ability of the CSV coordinator node to accept I/O requests from other nodes and to perform the orchestration of metadata updates. In Windows Server 2012 R2, if the Server service becomes unhealthy on a node, CSV ownership automatically transitions to another node to ensure greater resiliency.

What works differently?

In Windows Server 2012, there was only one instance of the Server service per node. Also, there was no monitoring of the Server service.

In Windows Server 2012 R2, you can now allocate a higher percentage of the total physical memory to the CSV cache. CSV cache enables the server to use system memory as a write-through cache.

What value does this change add?

Increasing the CSV cache limit is especially useful for Scale-Out File Server scenarios. Because Scale-Out File Servers are not typically memory constrained, you can accomplish large performance gains by using the extra memory for the CSV cache.

TipTip
We recommend that you enable the CSV cache for all clustered Hyper-V and Scale-Out File Server deployments, with greater allocation for a Scale-Out File Server deployment.

What works differently?

In Windows Server 2012, you could allocate only 20% of the total physical RAM to the CSV cache. You can now allocate up to 80%.

In Windows Server 2012, the CSV cache was disabled by default. In Windows Server 2012 R2, it is enabled by default. Also, the name of the private property of the cluster Physical Disk resource has been changed from CsvEnableBlockCache to EnableBlockCache.

You must still allocate the size of the block cache to reserve. To do this, set the value of the BlockCacheSize cluster common property. (The name of this property was changed from SharedVolumeBlockCacheSizeInMB in Windows Server 2012.) For more information, see Enable the CSV cache for read-intensive workloads.

You can now view the state of a CSV on a per node basis. For example, you can see whether I/O is direct or redirected, or whether the CSV is unavailable. If a CSV is in I/O redirected mode, you can also view the reason.

What value does this change add?

This change enables you to optimize your cluster configuration because you can easily determine the state of a CSV.

What works differently?

You can use the new Windows PowerShell cmdlet Get-ClusterSharedVolumeState to view the state information (such as direct or redirected) and the redirection reason. For the state information, see the StateInfo property. For the I/O redirection reason, see the FileSystemRedirectedIOReason property and the BlockRedirectedIOReason property.

In Windows Server 2012 R2, CSV functionality has been enhanced to include support for the following features:

  • Resilient File System (ReFS)

  • Deduplication

  • Parity storage spaces

  • Tiered storage spaces

  • Storage Spaces write-back caching

What value does this change add?

This added support expands the scenarios in which you can use CSVs, and enables you to take advantage of the efficiencies that are introduced in these features.

What works differently?

ReFS, deduplication, and parity storage spaces were not supported by CSVs in Windows Server 2012. Tiered storage spaces and Storage Spaces write-back caching are new in Windows Server 2012 R2.

In Windows Server 2012 R2, you can deploy a failover cluster without dependencies in Active Directory Domain Services (AD DS) for network names. This is referred to as an Active Directory-detached cluster. When you deploy a cluster by using this method, the cluster network name (also known as the administrative access point) and network names for any clustered roles with client access points are registered in Domain Name System (DNS). However, no computer objects are created for the cluster in AD DS. This includes both the computer object for the cluster itself (also known as the cluster name object or CNO), and computer objects for any clustered roles that would typically have client access points in AD DS (also known as virtual computer objects or VCOs).

noteNote
The cluster nodes must still be joined to an Active Directory domain.

What value does this change add?

With this deployment method, you can create a failover cluster without the previously required permissions to create computer objects in AD DS or the need to request that an Active Directory administrator pre-stages the computer objects in AD DS. Also, you do not have to manage and maintain the cluster computer objects for the cluster. For example, you can avoid the possible issue where an Active Directory administrator accidentally deletes the cluster computer object, which impacts the availability of cluster workloads.

What works differently?

The option to create an Active Directory-detached cluster is not available in Windows Server 2012. In Windows Server 2012, you can only deploy a failover cluster where the network names for the cluster are in both DNS and AD DS.

An Active Directory-detached cluster uses Kerberos authentication for intra-cluster communication. However, when authentication against the cluster network name is required, the cluster uses NTLM authentication.

ImportantImportant
We do not recommend this deployment method for any scenario that requires Kerberos authentication.

To deploy this type of cluster, you must use Windows PowerShell. For deployment information and details about what is supported and not supported with this deployment method, see Deploy an Active Directory-Detached Cluster.

The following section provides a summary of improvements to cluster quorum functionality in Windows Server 2012 R2.

In Windows Server 2012 R2, if the cluster is configured to use dynamic quorum (the default), the witness vote is also dynamically adjusted based on the number of voting nodes in current cluster membership. If there are an odd number of votes, the quorum witness does not have a vote. If there is an even number of votes, the quorum witness has a vote.

The quorum witness vote is also dynamically adjusted based on the state of the witness resource. If the witness resource is offline or failed, the cluster sets the witness vote to "0."

What value does this change add?

Dynamic witness significantly reduces the risk that the cluster will go down because of witness failure. The cluster decides whether to use the witness vote based on the number of voting nodes that are available in the cluster.

This change also greatly simplifies quorum witness configuration. You no longer have to determine whether to configure a quorum witness because the recommendation in Windows Server 2012 R2 is to always configure a quorum witness. The cluster automatically determines when to use it.

ImportantImportant
In Windows Server 2012 R2, we recommend that you always configure a quorum witness.

What works differently?

In Windows Server 2012, you had to determine when to configure a witness, and had to manually adjust the quorum configuration if node membership changed to keep the total number of votes at an odd number. This included every time you added or evicted cluster nodes.

Now, you no longer need to manually adjust the quorum configuration if node membership changes. By default, the cluster determines quorum management options, including the quorum witness.

Windows Server 2012 R2 also includes the new WitnessDynamicWeight cluster common property that you can use to view the quorum witness vote.

To view the property value, start Windows PowerShell as an administrator, and then enter the following command:

(Get-Cluster).WitnessDynamicWeight

A value of "0" indicates that the witness does not have a vote. A value of "1" indicates that the witness has a vote.

In Windows Server 2012 R2, you can now view the assigned quorum vote and the current quorum vote for each cluster node in the Failover Cluster Manager user interface (UI). Also, the quorum mode terminology has been simplified.

What value does this change add?

You can now easily determine in the UI which nodes have a vote, and whether that vote is active. When you click Nodes in Failover Cluster Manager, you can see the vote assignments.

Node vote assignment in the UI

Figure 2. Node vote assignment

What works differently?

In Windows Server 2012, you had to run the Validate Quorum Configuration validation report or use Windows PowerShell to view the vote status. You can still use these methods in Windows Server 2012 R2.

In Windows Server 2012 R2, the Validate Quorum Configuration report and the parameters for the Set-ClusterQuorum Windows PowerShell cmdlet are simplified to no longer use quorum mode terminology such as node majority (no witness), node majority with witness (disk or file share) or no majority (disk witness only).

In Windows Server 2012 R2, after there is an issue where you manually force quorum to start the cluster, for example you use the /fq switch when you start the Cluster service, the cluster automatically detects any partitions when connectivity is restored. The partition that you started with force quorum is now deemed authoritative. When failover cluster communication is resumed, the partitioned nodes automatically restart the Cluster service, and rejoin the cluster. The cluster is brought back into a single view of membership.

What value does this change add?

This change enables automatic recovery in the case of a partitioned failover cluster where a subset of nodes was started by forcing quorum. A partitioned failover cluster is also known as a split cluster or a "split-brain" cluster.

noteNote
A partitioned cluster occurs when a cluster breaks into subsets that are not aware of each other. For example, you have a multi-site cluster with three nodes in one site, and two nodes in the other. A network issue disrupts cluster communication. The site with three nodes stays running because it has quorum. The two node site without quorum shuts down. You determine that the site with three nodes does not have external connectivity, while the two node site does. Therefore, to restore service to users, you use the /fq switch to start the two node site. When network connectivity is restored, you have a partitioned cluster.

What works differently?

If there is a partitioned cluster in Windows Server 2012, after connectivity is restored, you must manually restart any partitioned nodes that are not part of the forced quorum subset with the /pq switch to prevent quorum. Ideally, you should do this as quickly as possible.

In Windows Server 2012 R2, both sides have a view of cluster membership and they will automatically reconcile when connectivity is restored. The side that you started with force quorum is deemed authoritative and the partitioned nodes automatically restart with the /pq switch to prevent quorum.

As an enhancement to dynamic quorum functionality, a cluster can now dynamically adjust a running node's vote to keep the total number of votes at an odd number. This functionality works seamlessly with dynamic witness. To maintain an odd number of votes, a cluster will first adjust the quorum witness vote through dynamic witness. However, if a quorum witness is not available, the cluster can adjust a node's vote. For example:

  1. You have a six node cluster with a file share witness. The cluster stretches across two sites with three nodes in each site. The cluster has a total of seven votes.

  2. The file share witness fails. Because the cluster uses dynamic witness, the cluster automatically removes the witness vote. The cluster now has a total of six votes.

  3. To maintain an odd number of votes, the cluster randomly picks a node to remove its quorum vote. One site now has two votes, and the other site has three.

  4. A network issue disrupts communication between the two sites. Therefore, the cluster is evenly split into two sets of three nodes each. The partition in the site with two votes goes down. The partition in the site with three votes continues to function.

In addition to this automatic functionality, there is a new cluster common property that you can use to determine which site survives if there is a 50% node split where neither site has quorum. Instead of the cluster randomly picking a node to remove its quorum vote, you can set the LowerQuorumPriorityNodeID property to predetermine which node will have its vote removed.

What value does this change add?

With this functionality, one side of the cluster continues to run in the case of a 50% node split where neither side would normally have quorum.

By optionally setting the LowerQuorumPriorityNodeID property, you can control which side stays up in this scenario. For example, you can specify that the primary site stays running and that a disaster recovery site shuts down.

What works differently?

In Windows Server 2012, if there is a 50% split where neither site has quorum, both sides will go down.

In Windows Server 2012 R2, you can assign the LowerQuorumPriorityNodeID cluster common property to a cluster node in the secondary site so that the primary site stays running. Set this property on only one node in the site.

To set the property, start Windows PowerShell as an administrator, and then enter the following command, where "1" is the example node ID for a node in the site that you consider less critical:

(Get-Cluster).LowerQuorumPriorityNodeID = 1
TipTip
To determine a node ID, start Windows PowerShell as an administrator, and then enter the following command, where "Node1" represents the name of a cluster node:

(Get-ClusterNode –Name "Node1").Id

You can also use the following command to return all the cluster node names, node IDs and the node state:

Get-ClusterNode | ft

When a state change occurs such as a cluster resource is taken offline, the nodes in a failover cluster must be notified of the change and acknowledge it before the cluster commits the change to the database. The Global Update Manager is responsible for managing these cluster database updates. In Windows Server 2012 R2, you can configure how the cluster manages global updates. By default, the Global Update Manager uses the following modes for failover cluster workloads in Windows Server 2012 R2:

  • All (write) and Local (read). In this mode, all cluster nodes must receive and process the update before the cluster considers the change committed. When a database read request occurs, the cluster reads the data from the cluster database on the local node. In this case, the local read is expected to be consistent because all nodes receive and process the updates. This is the default setting for all workloads besides Hyper-V.

    noteNote
    This is how global updates work for all workloads in Windows Server 2012.

  • Majority (read and write). In this new mode, a majority of the running cluster nodes must receive and process the update before the cluster commits the change to the database. When a database read request occurs, the cluster compares the latest timestamp from a majority of the running nodes, and uses the data with the latest timestamp. This is the default setting for Hyper-V failover clusters.

noteNote
There is also a new "Majority (write) and Local (read)" mode. However, this mode is not used by default for any workloads. See the "What works differently" section for more information.

What value does this change add?

The new configuration modes for Global Update Manager significantly improve cluster database performance in scenarios where there is significant network latency between the cluster nodes, for example with a stretch multi-site cluster. By association, this increases the performance of cluster workloads such as SQL Server or Exchange Server in these scenarios. Without this feature, the cluster database performs at the pace of the slowest node.

The new configuration modes can also help if there are delays that are associated with software or hardware issues. For example, a local registry update may be delayed on a node that has a hardware issue. By using a Global Update Manager mode that performs updates that are based on a majority of nodes, the cluster does not have to wait for all nodes to be notified of and acknowledge the state change before it is ready to process the next transaction.

What works differently?

In Windows Server 2012, you cannot configure the Global Update Manager mode. For all cluster workloads in Windows Server 2012, all cluster nodes must receive and process the update before the cluster considers the change committed. In Windows Server 2012 R2, you can configure the Global Update Manager mode, with three possible values. In Windows Server 2012 R2, the majority (read and write) mode is now the default mode for Hyper-V failover clusters.

You can configure the Global Update Manager mode by using the new DatabaseReadWriteMode cluster common property. To view the Global Update Manager mode, start Windows PowerShell as an administrator, and then enter the following command:

(Get-Cluster).DatabaseReadWriteMode

The following table shows the possible values.

 

Value Description

0 = All (write) and Local (read)

  • Default setting in Windows Server 2012 R2 for all workloads besides Hyper-V.

  • All cluster nodes must receive and process the update before the cluster commits a change to the database.

  • Database reads occur on the local node. Because the database is consistent on all nodes, there is no risk of out of date or "stale" data.

1 = Majority (read and write)

  • Default setting in Windows Server 2012 R2 for Hyper-V failover clusters.

  • A majority of the cluster nodes must receive and process the update before the cluster commits the change to the database.

  • For a database read, the cluster compares the latest timestamp from a majority of the running nodes, and uses the data with the latest timestamp.

2 = Majority (write) and Local (read)

  • A majority of the cluster nodes must receive and process the update before the cluster commits the change to the database.

  • Database reads occur on the local node. Because the cluster does not compare the latest timestamp on a majority of nodes, the data may be out of date or "stale."

WarningWarning
Do not use either of the majority modes (1 or 2) for scenarios that require strong consistency guarantees from the cluster database. For example, do not use these modes for a Microsoft SQL Server failover cluster that uses AlwaysOn availability groups, or for Microsoft Exchange Server.

By default, cluster nodes exchange heartbeats every one second. The number of heartbeats that can be missed before failover occurs is known as the heartbeat threshold. In Windows Server 2012 R2, the default heartbeat threshold has been increased for Hyper-V failover clusters.

What value does this change add?

This change provides increased resiliency to temporary network failures for virtual machines that are running on a Hyper-V cluster. For example, you may not want the cluster to perform recovery actions if your network often experiences short term network interruptions. For an application that is running on a virtual machine, a short network failure is often fairly seamless because of the TCP reconnect window.

What works differently?

By default, in Windows Server 2012, a node is considered down if it does not respond within five seconds. In Windows Server 2012 R2, the default threshold value for a Hyper-V failover cluster has been increased to 10 seconds for cluster nodes in the same subnet, and 20 seconds for cluster nodes in different subnets.

The following table lists the default values in Windows Server 2012 R2.

 

Cluster Common Property Default for All Clustered Roles Except Hyper-V Default for Hyper-V Clustered Role

SameSubnetThreshold

5 seconds

10 seconds

CrossSubnetThreshold

5 seconds

20 seconds

ImportantImportant
We recommend the following:

  • Do not configure a heartbeat threshold value that is greater than 20 seconds because this can exceed the TCP time-out window. A value greater than 20 seconds does not increase availability and it impacts the time it takes other nodes of the cluster to detect that the node is down.

  • Do not increase the heartbeat threshold from its default value for a Scale-Out File Server. A Scale-Out File Server already provides seamless recovery. If a node is considered down, the node fails over and recovers the SMB sessions on another node. This recovery action needs to occur within the SMB session time-out period. If you increase the heartbeat threshold, node detection will take longer. If it exceeds the SMB session time-out values, the recovery may no longer be seamless.

In Windows Server 2012 R2, you can now turn off Internet Protocol security (IPsec) encryption for inter-node cluster communication such as the cluster heartbeat.

What value does this change add?

The processing of high latency Group Policy updates can cause Active Directory Domain Services (AD DS) to become temporarily unavailable. In this situation, because IPsec encryption relies on access to AD DS, IPsec encryption is interrupted until the updates are complete. If cluster communication uses IPsec encryption, this interruption prevents inter-node cluster communication (including heartbeat messages) from being sent. If the delay exceeds the cluster heartbeat threshold for a cluster node, the cluster removes the node from cluster membership. If this occurs on multiple nodes at the same time, it could cause the cluster to lose quorum.

By turning off IPsec encryption for inter-node cluster communication, this traffic remains uninterrupted. Therefore, the ability of the cluster to provide high availability for its clustered roles is not impacted by high latency Group Policy updates.

What works differently?

You can now use the NetFTIPSecEnabled cluster common property to turn off IPsec encryption on port 3343 for inter-node cluster communication. By default, the NetFTIPSecEnabled setting is enabled (set to "1"). A value of "1" means that IPsec encryption for inter-node communication is enabled if there is an existing Group Policy setting that enforces IPsec.

To change the value to "0", which overrides any Group Policy setting and turns off IPsec encryption for inter-node cluster communication, start Windows PowerShell as an administrator, and then enter the following command:

(Get-Cluster). NetFTIPSecEnabled = 0
WarningWarning
We recommend that you turn off IPsec encryption for inter-node cluster communication only if you experience issues because of high latency Group Policy updates. If you do turn off the setting, make sure that you thoroughly test the change because it may affect cluster performance.

Failover Cluster Manager now includes a cluster dashboard that enables you to quickly view the health status of all managed failover clusters. You can view the name of the failover cluster together with an icon that indicates whether the cluster is running, the number and status of clustered roles, the node status, and the event status.

What value does this change add?

If you manage multiple failover clusters, this dashboard provides a convenient way for you to quickly check the health of the failover clusters.

What works differently?

In Windows Server 2012, you had to click each failover cluster name to view status information. Now, when you click Failover Cluster Manager in the navigation tree, there is a Clusters dashboard in the middle pane that shows all managed clusters.

Cluster dashboard showing two managed clusters

Figure 3. Cluster dashboard

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.