This ensures that more than 50% of the nodes will have an up-to-date copy of the configuration information.

The cluster service does not start (and bring resources online) if there are 50% or less of the configured nodes up and running. The cluster service waits, trying to restart, until a quorum is established when more nodes join. This feature guarantees that the cluster has the latest and most up-to-date configuration. This also means that, in a geographically dispersed cluster, you must distribute the nodes evenly between two data centers and have an arbitrator node in a third site or separate protected area to be able to survive a single data center failure.

Node Majority with File Share Witness

The file share witness feature is an improvement to the Node Majority quorum model. This feature lets you use a file share that is external to the cluster as an additional "vote" to determine the status of the cluster in a Node Majority quorum cluster deployment.

Consider a two-node Node Majority quorum cluster. Because an Node Majority quorum cluster can only run when the majority of the cluster nodes are available, a two-node Node Majority quorum cluster is unable to sustain the failure of any cluster node. This is because the majority of a two-node cluster is two. To sustain the failure of any one node in an Node Majority quorum cluster, you must have at least three devices that can be considered as available. The file share witness feature enables you to use an external file share as a witness. This witness acts as the third available device in a two-node Node Majority quorum cluster. Therefore, with this feature enabled, a two-node Node Majority quorum cluster can sustain the failure of a single cluster node. Additionally, the file share witness feature provides the following two functions:

•It helps protect the cluster against a problem that is known as a split brain. This problem occurs if the two nodes in a Node Majority quorum cluster cannot communicate with each other. In this situation, each cluster node is unable to determine whether the loss of communication occurred because the other cluster node failed, or whether the loss of communication occurred because of a problem with the network. The file share witness can designate one of the cluster nodes as the surviving cluster node. That cluster node can then determine that it should continue to run the cluster. In this scenario, the surviving cluster node can determine that the other cluster node failed, or that the other cluster node was not sanctioned by the file share witness.

•It helps protect the cluster against a problem that is known as a partition in time. This problem occurs if the following conditions are true:

◦

◦

◦

Cluster node A is running, but cluster node B is not running.

Cluster node A stops running.

Cluster node B tries to run the cluster.

In this situation, cluster node B may not have the cluster state information that was updated on cluster node A. Therefore, cluster node B may run the cluster by using incorrect state information. The file share witness feature helps prevent this problem by detecting that the cluster state has changed. The file share witness feature prevents the cluster node that contains outdated cluster state information from running the cluster.

NOTE: See Microsoft documentation for more details on Microsoft Failover quorum configuration.

Cluster Shared Volume for Windows Server 2012

Cluster Shared Volume is a feature of Microsoft Failover Cluster which allows all nodes in the cluster with the ability to directly access the same volume without changing ownership of the disk resource. The result of the feature is that all nodes in a cluster can use the same volume to host actively running Virtual Machines at the same time. CSV manages storage access differently than regular clustered disks. CSV Volume is a shared disk containing NTFS partitions. CSV gives you the ability to store multiple VHDs on a single LUN and run the associated VMs on any cluster node.

Planning for HP 3PAR Cluster Extension 13