• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Quorum Storage

USMCGrunt

2[H]4U
Joined
Mar 19, 2010
Messages
3,103
So here I thought I understood the basics of setting up VMs and getting them to work together when the Failover Cluster validator throws a totally new term at me and has me rethinking our plans.

My question is, are Quorum drives still necessary for VMs running on Server 2012R2? I was under the assumption that in Failover Clusters, the drives kept eachother updated in a similar manner in which AD keeps all domain controllers updated. It appears that assumption was wrong and that a NAS or SAN of some sort is necessary in order to properly utilize VMs/Failover.

The original idea was to migrate my company's three very over-utilized servers to a pair of servers, have 3-4 VMs running and the servers would run redundant to eachother so that if one went down for some reason, the other could take over.
 
So you currently have a pair of physical machines in a failover cluster that you want to virtualize?

First, do you still need failover clustering inside the VMs? Both VMware and Hyper-V offer High Availability for the VMs so if the host they're on goes down, they will automatically restart on another host. Hyper-V will even go so far as to failover a VM on another host if the VM's vSwitch loses physical connectivity. In the case of a hardware failure, a VM can be powering up within a few minutes.

Second, if you still want to do in guest clustering, you'll not only need a quorum drive (can be a block device they both see or a SMB3 share) but some other form of shared storage for the cluster's data to reside on so they both can see it.

Third, if these happen to be SQL 2012 VMs, have you looked into Always On Availability Groups? This would still require a quorum disk but the VMs would replicate their DBs to each other so you don't need a shared disk for the data.
 
Currently, there are three servers running on the network and they are very overwhelmed by the roles they must perform and the traffic they must handle. My intentions were to buy a pair of servers and run 3-4 VMs on one server and have the other setup to run as a redundant in case the primary goes down. I had made the assumption, dangerous as that is, that Failover Clustering is what was required to make this happen. Is there a more effective method that clustering to accomplish this?
 
Then your options are Hyper-V HA through failover clustering, in guest clustering with shared storage, 3rd party clustering software, or Hyper-V replica with automated takeover via SCOM and SCORCH or scripts but only if you're not clustering the hosts (which you should).

You can also do "cluster in a box" by having two nodes on the same host sharing a VHDX but then you can't live migrate IIRC and it only protects you against planned failures. If the host dies, it takes both VMs with it.

If you're clustering sql 2012 then I'd recommend Always On Availability groups but you'd still need a quorum disk or share.
 
share on sofs works just fine

alwayson ag have some performance issues with replication however (encryption is single threaded) so cannot manage to push 1+ GB/sec

Then your options are Hyper-V HA through failover clustering, in guest clustering with shared storage, 3rd party clustering software, or Hyper-V replica with automated takeover via SCOM and SCORCH or scripts but only if you're not clustering the hosts (which you should).

You can also do "cluster in a box" by having two nodes on the same host sharing a VHDX but then you can't live migrate IIRC and it only protects you against planned failures. If the host dies, it takes both VMs with it.

If you're clustering sql 2012 then I'd recommend Always On Availability groups but you'd still need a quorum disk or share.
 
I posted this issue in Spiceworks asking the same thing and managed to grab a free license for StarWind vSAN. Haven't messed with it yet but it's more hopeful than trying to get 30k in funding for servers, sans, and related infrastructure.
 
You only need a quorum disk if you have an even number of nodes, ie 2 or 4 server cluster needs a quorum disk.

If you have an odd number of nodes in your cluster then you would use node majority, not node plus disk majority.

*EDIT*

Here are some links you can read on MS Failover

http://technet.microsoft.com/en-us/library/cc731739.aspx
http://technet.microsoft.com/en-us/library/jj612870.aspx

Thanks for the links, I'll read up on them. We WILL have an even number of nodes, its a small enough company that a third isn't needed as well as can't really be afforded.
 
this is not true anymore

windows server 2012 r2 has dynamic witness feature so it will either use quorum or not

http://windowsitpro.com/windows-server-2012-r2/failover-clustering

http://technet.microsoft.com/en-us/library/dn265972.aspx

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

You only need a quorum disk if you have an even number of nodes, ie 2 or 4 server cluster needs a quorum disk.

If you have an odd number of nodes in your cluster then you would use node majority, not node plus disk majority.

*EDIT*

Here are some links you can read on MS Failover

http://technet.microsoft.com/en-us/library/cc731739.aspx
http://technet.microsoft.com/en-us/library/jj612870.aspx
 
with the product you use being a virtual san i guess you don't need anything except a basic 2-node setup

quorum lun would be created as a virtual resource and cluster heartbeat networks would be used to simulate it to prevent brain split issues

Thanks for the links, I'll read up on them. We WILL have an even number of nodes, its a small enough company that a third isn't needed as well as can't really be afforded.
 
Back
Top