In this post I’m going to talk about building a 2 node Windows Server 2012/R2 failover cluster and what type of witness configuration to choose to achieve cluster quorum when the cluster’s storage is a JBOD with Storage Spaces.
I’ve been messing about in the lab with a WS2012 R2 cluster, in particular, a Scale-Out File Server (SOFS) running on a failover cluster with Storage Spaces on a JBOD. What I’m discussing applies equally to:
- A Hyper-V cluster that uses a SAS attached JBOD with Storage Spaces as the cluster storage
- A SOFS based on a JBOD with Storage Spaces
Consider the build process of this 2 node cluster:
- You attach a JBOD with raw disks to each cluster member
- You build the cluster
- You prepare Storage Spaces in the cluster and create your virtual disks
Hmm, no witness was created to break the vote and get an uneven result. In fact, what happens is that the cluster will rig the vote to ensure that there is an uneven result. If you’ve got 2 just nodes in the cluster with no witness then one has a quorum vote and the other doesn’t. Imagine Node1 has a vote and Node2 does not have a vote. Now Node1 goes offline for whatever reason. Node2 does not have a vote and cannot achieve quorum; you don’t have a cluster until Node1 comes back online.
There are 2 simple solutions to this:
1) Create A File Share Witness
Create a file share on another highly available file server – uh … that’ll be an issue for small/medium business because all the virtual machines (including the file server) were going to be stored on the JBOD/Storage Spaces. You can configure the file share as a witness for the cluster.
2) (More realistically) Create a Storage Spaces Virtual Disk As A Witness Disk
Create a small virtual disk (2-way or 3-way mirror for JBOD fault tolerance) and use that disk for quorum as the witness disk. A 1 GB disk will do; the smallest my Storage Spaces implementation would do was 5 GB but that’s such a small amount anyway. This solution is pretty what you’d do in a single site cluster with traditional block storage.
We could go crazy talking about quorum options in cluster engineering. I’ve given you 2 simple options, with the virtual disk as a witness being the simplest. Now each node has a vote for quorum with a witness to break the vote, and the cluster can survive either node failing.
“A 1 GB disk will do; the smallest my Storage Spaces implementation would do was 5 GB but that’s such a small amount anyway.”
Hello Aidan,
What determines the smallest virtual disk your environment can make? I try to make a 1GB vdisk & it creates a 3GB one. Thanks!
Your choice of fault tolerance for the storage spaces virtual disk, and the underlying structure which then has to place interleaves on a minimum number of disks.
Thanks for the reply. My team had a customer ask why they couldn’t create a small vdisk off of their current config, so we then were able to duplicate this behavior. So from your reply, we tried to change the interleave from the default of 256k to 64k; hoping it would allow us to make a smaller minimum vdisk. However, as you can see below, we tried to make a 512MB vdisk but it ended up being 5GB. It seems no matter what we change, it goes off of 1GB minimum per column. How would we go about changing this? Is it even possible with this number of columns?
New-VirtualDisk -FriendlyName 512MB -StoragePoolFriendlyName Pool1 -AutoWriteCacheSize -Interleave 65536 -NumberOfColumns 5 -NumberOfDataCopies 2 -ProvisioningType Fixed -Size 512
FriendlyName ResiliencySettingName OperationalStatus HealthStatus IsManualAttach Size
———— ——————— —————– ———— ————– —-
512MB Mirror OK Healthy True 5 GB
PS C:\Windows\system32> Get-VirtualDisk -FriendlyName 512* | fl *
Usage : Other
NameFormat :
OperationalStatus : OK
HealthStatus : Healthy
ProvisioningType : Fixed
ParityLayout : Unknown
Access : Read/Write
UniqueIdFormat : Vendor Specific
DetachedReason : None
WriteCacheSize : 0
ObjectId : {1}\\SOFS-Cluster\root/Microsoft/Windows/Storage/Providers_v2\SPACES_VirtualDisk.ObjectId=”{2ef
fb6fc-4482-4f8b-a15b-db4307393b2a}:VD:{0d38164c-ed10-11e4-80bb-00155d020a2c}{0dcf6860-ed10-11e4
-80bc-00155d020a2d}”
PassThroughClass :
PassThroughIds :
PassThroughNamespace :
PassThroughServer :
UniqueId : 6068CF0D10EDE41180BC00155D020A2D
AllocatedSize : 5368709120
FootprintOnPool : 10737418240
FriendlyName : 512MB
Interleave : 65536
IsDeduplicationEnabled : False
IsEnclosureAware : False
IsManualAttach : True
IsSnapshot : False
LogicalSectorSize : 4096
Name :
NumberOfAvailableCopies :
NumberOfColumns : 5
NumberOfDataCopies : 2
OtherOperationalStatusDescription :
OtherUsageDescription :
PhysicalDiskRedundancy : 1
PhysicalSectorSize : 4096
RequestNoSinglePointOfFailure : False
ResiliencySettingName : Mirror
Size : 5368709120
UniqueIdFormatDescription :
PSComputerName :
CimClass : ROOT/Microsoft/Windows/Storage:MSFT_VirtualDisk
CimInstanceProperties : {ObjectId, PassThroughClass, PassThroughIds, PassThroughNamespace…}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties