File Share Witness vs Cloud Witness vs Disk Witness: welk type past bij jouw cluster?

1. Korte primer, quorum en Dynamic Quorum

Een cluster stemt over zijn eigen gezondheid. Elke draaiende node krijgt een stem, de witness (indien geconfigureerd) krijgt een stem, en het cluster heeft een meerderheid van stemmen nodig om te blijven draaien. Verlies van de meerderheid betekent dat de Cluster Service stopt om split-brain te voorkomen.

Dynamic Quorum (geïntroduceerd in Windows Server 2012 R2, sindsdien default aan) past het aantal stemmen aan terwijl nodes het cluster verlaten. Verlies één node uit een vijf-node cluster, het cluster reduceert het stemmenaantal en draait door. In een twee-node cluster met witness kun je elk van beide nodes verliezen en op één node plus de witness overleven. Verlies de witness en één node tegelijk, en Dynamic Witness heeft het stemgewicht van de witness al aangepast om de overlevingskans te maximaliseren.

De witness bestaat om patstellingen op te breken, en om een meerderheid te behouden bij even-aantallen waar natuurlijke meerderheden onmogelijk zijn. Zonder witness in een even-node cluster legt elke 50/50 splitsing het cluster plat.

2. De drie witness-types in vogelvlucht

Witness-type	Waar het zit	Best voor	Slechtst voor
Disk Witness	Gedeelde SAN-LUN zichtbaar voor alle nodes	Single-site clusters met SAN waar de witness-LUN op onafhankelijke storage staat ten opzichte van de data	Multisite/stretched clusters (kan geen sites overspannen), S2D-clusters (geen shared SAN), kleine clusters waar de SAN het datapad is
File Share Witness	Netwerk-SMB share op een server buiten het cluster	Two-site clusters waar de share in een derde site staat, disconnected omgevingen, grote omgevingen met een witness-fileserver	Single-site als de share in hetzelfde fault domain als het cluster zit
Cloud Witness	Azure Storage Account, benaderd via HTTPS	Elk cluster met betrouwbare Azure-connectivity, inclusief two-node, stretched, en disaster recovery clusters	Clusters zonder toegestane uitgaande Azure-connectivity

3. File Share Witness, waar het past en waar het faalt

De File Share Witness is de oudste non-disk witness en nog steeds het juiste antwoord in disconnected of strict-policy omgevingen. Het is ook het type waar wij de meeste configuratiefouten vinden, omdat het eruitziet als "gewoon een fileshare" en zo behandeld wordt.

Wat het werkelijk is: een klein bestand op een SMB-share dat het cluster periodiek aanraakt om zijn quorum-stem op te eisen. De share zelf hoeft niet hoogbeschikbaar te zijn, wel beschikbaar, punt. En cruciaal: in een ander fault domain dan een van de cluster-nodes.

Wat we in ClusterTriage Hyper-V cluster assessments vinden:

• File Share Witness op één fysieke server, geen UPS, in hetzelfde rack als de helft van het cluster. De rack-PDU is dan een single point of failure voor het hele cluster.
• File Share Witness op een NAS die zelf een single-node appliance is. Reboot de NAS voor firmware, verlies de witness tijdens een kritiek onderhoudsvenster.
• File Share Witness op een van de cluster-nodes zelf. We hebben dit in productie gezien. De beheerder kwam fileservers tekort en "had nog ruimte op HV03". Dat is geen witness, dat is een permanent kapotte configuratie.
• FSW-pad geconfigureerd met een NetBIOS-naam die naar meerdere IP's verwijst (DFS-namespace), waarbij sommige targets in de verkeerde site staan.

Vereisten voor een bruikbare File Share Witness:

• Gehost op Windows Server 2012 R2 of nieuwer (oudere versies missen de vereiste SMB-features).
• SMB 3.0 of nieuwer, niet op een NAS die alleen SMB 2.x spreekt.
• In een fault domain dat echt onafhankelijk is van het cluster: ander rack, andere voedingsfeed, idealiter een andere site.
• Cluster computer-object met Full Control op de share-map (niet alleen Read/Write).
• Share-pad gebruikt een stabiele naam, FQDN of korte naam die niet afhankelijk is van DNS-aliases.

4. Cloud Witness, de moderne default

Cloud Witness werd geïntroduceerd in Windows Server 2016 en is het witness-type dat ClusterTriage voor vrijwel elke moderne deployment met toegestane Azure-connectivity aanbeveelt. Het is een klein bestand in een Azure Storage Account, door iedere node benaderd via HTTPS naar *.blob.core.windows.net.

Waarom dit het standaardantwoord is:

• Per definitie buiten het fault domain van het cluster. Wat er bij de klant ook afbrandt, de witness in Azure blijft staan.
• Kost in wezen niets, fracties van een eurocent per maand voor de storage, geen egress want het bestand is minuscuul.
• Werkt voor two-node, multi-node en stretched clusters identiek.
• Vereist geen aparte fileserver, share-rechten, of DNS-configuratie.

Wanneer het het verkeerde antwoord is:

• Het cluster staat in een netwerksegment zonder uitgaand internet en het securitybeleid verbiedt het toevoegen ervan. Hard-air-gapped omgevingen.
• Het cluster draait op een hardwareplatform dat Azure niet betrouwbaar kan bereiken (zeldzaam, maar we hebben het op industriële control-systems gezien).
• Latency van cluster naar Azure overschrijdt de cluster-heartbeat threshold, extreem zeldzaam, vereist intercontinentale links zonder peering.

Configuratie is één PowerShell-commando (zie de configuratiesectie hieronder). De enige echte planningsbeslissing is welke Azure-subscription en welke storage account-regio. Kies er een dicht bij het cluster, bij voorkeur met een stabiele verbinding.

5. Disk Witness, nog steeds relevant in specifieke gevallen

Disk Witness is ouder dan de andere twee en blijft de enige optie in enkele specifieke scenario's. Het is een kleine clustered disk-resource, typisch een 1 GB LUN, die voor iedere node via de SAN zichtbaar is.

Wanneer dit nog steeds het juiste antwoord is:

• Single-site cluster met shared SAN-storage waar de SAN echt onafhankelijke storage-paden levert ten opzichte van de data-LUN's (andere storage-controllers, idealiter andere fysieke arrays).
• De klant heeft sterk geïnvesteerd in SAN-gebaseerde clustering en er is geen operationele bereidheid voor Azure-connectivity.

Wanneer het het verkeerde antwoord is:

• Stretched/multisite, Disk Witness kan geen sites overspannen.
• S2D / Azure Local, er is geen shared SAN.
• Witness-LUN op dezelfde SAN-array als de CSV's. Verlies de array, verlies de witness, verlies het cluster. We zien dit verrassend vaak.
• Witness-LUN op een SAN-volume met eigen quorum-logica (sommige active/passive arrays doen onverwachte dingen tijdens controller-failover).

6. Beslissingsmatrix per topologie

Topologie	Eerste keuze	Acceptabel alternatief	Vermijden
Two-node, single site, SAN	Cloud Witness	Disk Witness op onafhankelijke SAN	FSW op de SAN-attached fileserver
Two-node, single site, S2D	Cloud Witness	FSW op onafhankelijke infrastructuur	Wat dan ook op de cluster-nodes zelf
3 tot 8 nodes, single site, SAN	Cloud Witness	FSW of Disk Witness op onafhankelijke storage	Disk Witness op dezelfde array als CSV's
3 tot 8 nodes, single site, S2D / Azure Local	Cloud Witness	FSW in een ander fault domain	Wat dan ook intern aan het cluster
Two-site stretched cluster	Cloud Witness	FSW in een derde fysieke site	FSW in een van de twee cluster-sites
Disconnected / air-gapped	FSW op onafhankelijke storage en voeding	Disk Witness op onafhankelijke SAN (indien van toepassing)	Witness op cluster-nodes of gedeeld fault domain

7. Vijf configuratiefouten die we blijven tegenkomen

1. Witness in hetzelfde fault domain als het cluster. FSW op een fileserver in hetzelfde rack met dezelfde PDU. Disk Witness op dezelfde SAN als de CSV's. De witness bestaat, maar voegt geen resilience toe.
2. Cluster computer-object heeft geen Full Control op de fileshare. De witness lijkt geconfigureerd, quorum-operaties falen wanneer het cluster hem probeert op te eisen.
3. Cloud Witness in een Azure-regio die geografisch ver weg ligt. Witness-latency piekt tijdens regio-issues. Kies een regio dicht bij het cluster.
4. Helemaal geen witness op een twee-node cluster. Dynamic Quorum doet z'n best, dat is niet genoeg voor enige vorm van voorspelbare uitkomst.
5. Witness geconfigureerd maar Dynamic Witness uit. Dan kan het cluster het witness-gewicht niet aanpassen wanneer de topologie degradeert. Wij zien dit op oudere clusters die via upgrades zijn meegenomen.

8. PowerShell, configureren en verifiëren

Huidige status inspecteren:

# Huidige quorum-configuratie
Get-ClusterQuorum | Format-List *

# Witness-resource detail
Get-ClusterResource | Where-Object {$_.OwnerGroup -eq 'Cluster Group'} |
    Format-Table Name, State, OwnerNode, ResourceType

# Verifieer Dynamic Quorum en Dynamic Witness
(Get-Cluster).DynamicQuorum
(Get-Cluster).WitnessDynamicWeight

Cloud Witness instellen:

# Vereist de Azure storage account-naam en een van de access keys
Set-ClusterQuorum -CloudWitness `
    -AccountName 'sthcwitnessprodweu' `
    -AccessKey '...' `
    -Endpoint 'core.windows.net'

# Verifiëren
Get-ClusterResource 'Cloud Witness' | Format-List *
Test-NetConnection sthcwitnessprodweu.blob.core.windows.net -Port 443

File Share Witness instellen:

# Vereist Full Control op de share voor het cluster-computer-account
Set-ClusterQuorum -FileShareWitness '\\fs01.corp.example\witness$\hv-cluster'

# Verifiëren
Get-ClusterResource 'File Share Witness' | Format-List *

# Share-permissies vanuit een cluster-node verifiëren
Get-Acl '\\fs01.corp.example\witness$\hv-cluster' | Format-List Access

Disk Witness instellen:

# Witness-LUN moet al een clustered disk-resource zijn
Get-ClusterAvailableDisk | Add-ClusterDisk
Set-ClusterQuorum -DiskWitness 'Cluster Disk Witness'

End-to-end valideren:

Test-Cluster -Include 'Inventory','Quorum Configuration','Network' `
    -ReportName witness-check

De conclusie

Voor vrijwel elk modern cluster dat ClusterTriage beoordeelt, is Cloud Witness het juiste antwoord en de implementatie kost één commando. De meest voorkomende Cluster Assessment-bevinding is niet "geen witness", het is "witness die geen resilience toevoegt omdat hij een fault domain deelt met het cluster". Die kloof dichten is een van de remediation-stappen met de hoogste hefboom in een typische opdracht.

Een witness in hetzelfde fault domain als het cluster is geen witness, het is decoratie.

De ClusterTriage Hyper-V cluster assessment bevat witness-topologie-analyse in de standaardscope. Als de witness niet past bij de topologie, wordt dat gedocumenteerd met severity die schaalt met de blast radius, en de remediation-stap wordt opgenomen in de actielijst.

Plan een Hyper-V cluster assessment kennismaking →