Configuring Quorum on Storage Spaces For A 2 Node WS2012 (and WS2012 R2) Cluster

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.

3 Replies to “Configuring Quorum on Storage Spaces For A 2 Node WS2012 (and WS2012 R2) Cluster”

  1. “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
        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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.