File Share Witness vs Cloud Witness vs Disk Witness: Which Type Fits Your Cluster?
Quorum is the invisible thing keeping a Windows Server Failover Cluster alive when nodes go away. Witness configuration is also one of the top three areas where CloudLabs Hyper-V Cluster Health Checks find quiet resilience gaps. The witness exists, the cluster reports healthy, validation passes, and one fault domain still takes the cluster down because the witness sits exactly in the wrong place.
This article compares the three witness types in production terms: failure modes, topology fit, the configuration mistakes we keep finding, and the decisions you want to get right once.
- Short primer, quorum and Dynamic Quorum
- The three witness types at a glance
- File Share Witness, where it fits and where it fails
- Cloud Witness, the modern default
- Disk Witness, still relevant in specific cases
- Decision matrix per topology
- Five configuration mistakes we keep running into
- PowerShell, configuring and verifying
1. Short primer, quorum and Dynamic Quorum
A cluster votes on its own health. Every running node gets a vote, the witness (if configured) gets a vote, and the cluster needs a majority of votes to stay alive. Loss of majority means the Cluster Service stops to prevent split-brain.
Dynamic Quorum (introduced in Windows Server 2012 R2, default on since) adjusts the vote count as nodes leave the cluster. Lose one node from a five-node cluster, the cluster reduces vote count and keeps running. In a two-node cluster with witness you can lose either node and survive on the remaining node plus the witness. Lose the witness and a node simultaneously, and Dynamic Witness has already adjusted the witness vote weight to maximise survival odds.
The witness exists to break tie votes, and to keep a majority alive in even-numbered counts where natural majorities are impossible. Without a witness in an even-node cluster, any 50/50 split takes the cluster down.
2. The three witness types at a glance
| Witness type | Where it lives | Best for | Worst for |
|---|---|---|---|
| Disk Witness | Shared SAN LUN visible to all nodes | Single-site clusters with SAN where the witness LUN is on independent storage relative to the data | Multisite/stretched clusters (cannot span sites), S2D clusters (no shared SAN), small clusters where the SAN is the data path |
| File Share Witness | Network SMB share on a server outside the cluster | Two-site clusters with the share in a third site, disconnected environments, large environments with a witness fileserver | Single site if the share sits in the same fault domain as the cluster |
| Cloud Witness | Azure Storage Account, reached over HTTPS | Any cluster with reliable Azure connectivity, including two-node, stretched, and disaster recovery clusters | Clusters with no permitted outbound Azure connectivity |
3. File Share Witness, where it fits and where it fails
The File Share Witness is the oldest non-disk witness and still the right answer in disconnected or strict-policy environments. It is also the type where we find the most configuration mistakes, because it looks like "just a file share" and gets treated that way.
What it actually is: a small file on an SMB share that the cluster periodically touches to claim its quorum vote. The share itself does not need to be highly available, just available, period. And critically: in a different fault domain than any of the cluster nodes.
What we find in CloudLabs Hyper-V Cluster Health Checks:
- File Share Witness on a single physical server, no UPS, in the same rack as half the cluster. The rack PDU then becomes a single point of failure for the entire cluster.
- File Share Witness on a NAS that is itself a single-node appliance. Reboot the NAS for firmware, lose the witness during a critical maintenance window.
- File Share Witness on one of the cluster nodes itself. We have seen this in production. The admin was short on fileservers and "had room left on HV03". That is not a witness, that is a permanently broken configuration.
- FSW path configured with a NetBIOS name resolving to multiple IPs (DFS namespace), where some targets sit in the wrong site.
Requirements for a usable File Share Witness:
- Hosted on Windows Server 2012 R2 or newer (older versions miss the required SMB features).
- SMB 3.0 or newer, not on a NAS that only speaks SMB 2.x.
- In a fault domain genuinely independent from the cluster: different rack, different power feed, ideally a different site.
- Cluster computer object with Full Control on the share folder (not just Read/Write).
- Share path uses a stable name, FQDN or short name not dependent on DNS aliases.
4. Cloud Witness, the modern default
Cloud Witness was introduced in Windows Server 2016 and is the witness type CloudLabs recommends for nearly every modern deployment with permitted Azure connectivity. It is a small file in an Azure Storage Account, reached by every node over HTTPS to *.blob.core.windows.net.
Why this is the default answer:
- By definition outside the cluster's fault domain. Whatever burns down at the customer site, the witness in Azure keeps running.
- Costs essentially nothing, fractions of a cent per month for storage, no egress because the file is tiny.
- Works for two-node, multi-node, and stretched clusters identically.
- Requires no separate fileserver, share permissions, or DNS configuration.
When it is the wrong answer:
- The cluster sits in a network segment without outbound internet and security policy forbids adding it. Hard-air-gapped environments.
- The cluster runs on a hardware platform that cannot reliably reach Azure (rare, but we have seen it on industrial control systems).
- Latency from cluster to Azure exceeds the cluster heartbeat threshold, extremely rare, requires intercontinental links without peering.
Configuration is one PowerShell command (see the configuration section below). The only real planning decision is which Azure subscription and which storage account region. Pick one close to the cluster, preferably with a stable link.
5. Disk Witness, still relevant in specific cases
Disk Witness is older than the other two and remains the only option in a few specific scenarios. It is a small clustered disk resource, typically a 1 GB LUN, visible to every node through the SAN.
When this is still the right answer:
- Single-site cluster with shared SAN storage where the SAN genuinely delivers independent storage paths relative to the data LUNs (different storage controllers, ideally different physical arrays).
- The customer is heavily invested in SAN-based clustering and there is no operational appetite for Azure connectivity.
When it is the wrong answer:
- Stretched/multisite, Disk Witness cannot span sites.
- S2D / Azure Local, there is no shared SAN.
- Witness LUN on the same SAN array as the CSVs. Lose the array, lose the witness, lose the cluster. We see this surprisingly often.
- Witness LUN on a SAN volume with its own quorum logic (some active/passive arrays do unexpected things during controller failover).
6. Decision matrix per topology
| Topology | First choice | Acceptable alternative | Avoid |
|---|---|---|---|
| Two-node, single site, SAN | Cloud Witness | Disk Witness on independent SAN | FSW on the SAN-attached fileserver |
| Two-node, single site, S2D | Cloud Witness | FSW on independent infrastructure | Anything on the cluster nodes themselves |
| 3 to 8 nodes, single site, SAN | Cloud Witness | FSW or Disk Witness on independent storage | Disk Witness on the same array as the CSVs |
| 3 to 8 nodes, single site, S2D / Azure Local | Cloud Witness | FSW in a different fault domain | Anything internal to the cluster |
| Two-site stretched cluster | Cloud Witness | FSW in a third physical site | FSW in either of the two cluster sites |
| Disconnected / air-gapped | FSW on independent storage and power | Disk Witness on independent SAN (where applicable) | Witness on cluster nodes or shared fault domain |
Witness topology is a subject monitoring stays silent on. The cluster is healthy, validation passes, the report is green. Only during a real failure does it surface that the witness shared a fault domain with half the cluster.
A CloudLabs Hyper-V Cluster Health Check tests witness placement against your actual topology and documents the gap with severity and remediation steps.
Schedule a Health Check intro call →7. Five configuration mistakes we keep running into
- Witness in the same fault domain as the cluster. FSW on a fileserver in the same rack with the same PDU. Disk Witness on the same SAN as the CSVs. The witness exists, but adds no resilience.
- Cluster computer object lacks Full Control on the file share. The witness looks configured, quorum operations fail when the cluster tries to claim it.
- Cloud Witness in an Azure region geographically far away. Witness latency spikes during regional issues. Pick a region close to the cluster.
- No witness at all on a two-node cluster. Dynamic Quorum does its best, that is not enough for any predictable outcome.
- Witness configured but Dynamic Witness off. The cluster then cannot adjust witness weight as topology degrades. We see this on older clusters carried through multiple upgrades.
8. PowerShell, configuring and verifying
Inspect current state:
# Current quorum configuration
Get-ClusterQuorum | Format-List *
# Witness resource detail
Get-ClusterResource | Where-Object {$_.OwnerGroup -eq 'Cluster Group'} |
Format-Table Name, State, OwnerNode, ResourceType
# Verify Dynamic Quorum and Dynamic Witness
(Get-Cluster).DynamicQuorum
(Get-Cluster).WitnessDynamicWeightConfigure Cloud Witness:
# Requires the Azure storage account name and one of the access keys
Set-ClusterQuorum -CloudWitness `
-AccountName 'sthcwitnessprodweu' `
-AccessKey '...' `
-Endpoint 'core.windows.net'
# Verify
Get-ClusterResource 'Cloud Witness' | Format-List *
Test-NetConnection sthcwitnessprodweu.blob.core.windows.net -Port 443Configure File Share Witness:
# Requires Full Control on the share for the cluster computer account
Set-ClusterQuorum -FileShareWitness '\\fs01.corp.example\witness$\hv-cluster'
# Verify
Get-ClusterResource 'File Share Witness' | Format-List *
# Verify share permissions from a cluster node
Get-Acl '\\fs01.corp.example\witness$\hv-cluster' | Format-List AccessConfigure Disk Witness:
# Witness LUN must already be a clustered disk resource
Get-ClusterAvailableDisk | Add-ClusterDisk
Set-ClusterQuorum -DiskWitness 'Cluster Disk Witness'End-to-end validation:
Test-Cluster -Include 'Inventory','Quorum Configuration','Network' `
-ReportName witness-checkThe bottom line
For nearly every modern cluster CloudLabs reviews, Cloud Witness is the right answer and implementation takes one command. The most common Health Check finding is not "no witness", it is "witness that adds no resilience because it shares a fault domain with the cluster". Closing that gap is one of the highest-leverage remediation steps in a typical engagement.
A witness in the same fault domain as the cluster is not a witness, it is decoration.
The CloudLabs Hyper-V Cluster Health Check includes witness topology analysis in standard scope. If the witness does not fit the topology, that is documented with severity scaling to blast radius, and the remediation step lands on the action list.
Schedule a Hyper-V Cluster Health Check intro call →
Frequently asked questions
Strictly speaking no, because odd node counts give natural majorities. But the moment you lose one node, you are in a two-node state where Dynamic Quorum substantially improves survival odds with a witness. We always configure a witness, regardless of node count.
No, a cluster has only one witness at a time. You can switch types with Set-ClusterQuorum without downtime.
Dynamic Witness adjusts the witness vote weight as soon as the cluster detects unreachability. The cluster keeps running as long as a majority of remaining votes (nodes plus any witness) holds. The witness is automatically reweighted as soon as connectivity returns.
Yes, the -Endpoint parameter supports different Azure cloud endpoints. For Azure Government use core.usgovcloudapi.net, for Azure China core.chinacloudapi.cn. Sovereign clouds with data residency requirements can use Cloud Witness as long as the Azure tenant lives in the correct cloud.
Negligibly under normal operation. The cluster only touches the witness during quorum events (node failure, reboot, witness state change). For stretched clusters with latency between sites, witness location matters for failover times, but not for steady-state performance.
File Share Witness vs Cloud Witness vs Disk Witness: welk type past bij jouw cluster?
Quorum is het onzichtbare stuk dat een Windows Server Failover Cluster overeind houdt wanneer nodes verdwijnen. Witness-configuratie is ook een van de top drie gebieden waar CloudLabs Hyper-V Cluster Health Checks stille resilience-gaten vinden. De witness bestaat, het cluster rapporteert gezond, validatie komt door, en één fault domain legt het cluster alsnog plat omdat de witness precies op de verkeerde plek staat.
Dit artikel vergelijkt de drie witness-types in productie-termen: failure modes, topologie-fit, de configuratiefouten die wij blijven vinden, en de beslissingen die je in één keer goed wilt maken.
- Korte primer, quorum en Dynamic Quorum
- De drie witness-types in vogelvlucht
- File Share Witness, waar het past en waar het faalt
- Cloud Witness, de moderne default
- Disk Witness, nog steeds relevant in specifieke gevallen
- Beslissingsmatrix per topologie
- Vijf configuratiefouten die we blijven tegenkomen
- PowerShell, configureren en verifiëren
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 CloudLabs Hyper-V Cluster Health Checks 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 resolvet (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 CloudLabs 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 |
Witness-topologie is een onderwerp waarop monitoring stilzwijgt. Het cluster is gezond, validatie komt door, het rapport is groen. Pas bij een echte storing blijkt dat de witness in hetzelfde fault domain zat als de helft van het cluster.
Een CloudLabs Hyper-V Cluster Health Check toetst witness-plaatsing tegen je werkelijke topologie en documenteert de gap met severity en remediation-stappen.
Plan een Health Check kennismaking →7. Vijf configuratiefouten die we blijven tegenkomen
- 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.
- 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.
- Cloud Witness in een Azure-regio die geografisch ver weg ligt. Witness-latency piekt tijdens regio-issues. Kies een regio dicht bij het cluster.
- Helemaal geen witness op een twee-node cluster. Dynamic Quorum doet z'n best, dat is niet genoeg voor enige vorm van voorspelbare uitkomst.
- 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).WitnessDynamicWeightCloud 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 443File 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 AccessDisk 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-checkDe conclusie
Voor vrijwel elk modern cluster dat CloudLabs beoordeelt, is Cloud Witness het juiste antwoord en de implementatie kost één commando. De meest voorkomende Health Check-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 CloudLabs Hyper-V Cluster Health Check 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 Health Check kennismaking →
Veelgestelde vragen
Strikt genomen nee, omdat oneven nodes natuurlijke meerderheden geven. Maar zodra je één node verliest, zit je in een twee-node toestand waar Dynamic Quorum de overlevingskansen flink verbetert mét een witness. Wij configureren altijd een witness, ongeacht het aantal nodes.
Nee, een cluster heeft maar één witness tegelijk. Je kunt wel switchen tussen types met Set-ClusterQuorum, zonder downtime.
Dynamic Witness past het stemgewicht van de witness aan zodra het cluster detecteert dat hij onbereikbaar is. Het cluster blijft draaien zolang een meerderheid van de overige stemmen (nodes plus eventuele witness) intact is. De witness wordt automatisch weer meegerekend zodra connectivity terug is.
Ja, het -Endpoint parameter ondersteunt verschillende Azure-cloud endpoints. Voor Azure Government gebruik je core.usgovcloudapi.net, voor Azure China core.chinacloudapi.cn. Sovereign clouds met data residency-eisen kunnen Cloud Witness gebruiken zolang de Azure-tenant in de juiste cloud zit.
Verwaarloosbaar in normale werking. Het cluster raakt de witness alleen aan tijdens quorum-events (node-failure, reboot, witness-state verandering). Voor stretched clusters met latency tussen sites is de witness-locatie wel belangrijk voor failover-tijden, maar niet voor steady-state performance.