CSV ownership onbalans in Hyper-V clusters: oorzaken en oplossingen

1. Wat CSV ownership werkelijk betekent

Een Cluster Shared Volume is één NTFS- of ReFS-volume dat alle cluster-nodes gelijktijdig kunnen lezen en schrijven. Achter die simpele beschrijving zit een coordinator-rol. Eén node, de coordinator-node, bezit de metadata-operaties van het volume. Ruimte alloceren, een VHD uitbreiden, een snapshot maken, attributen wijzigen, dat loopt allemaal via de coordinator. Andere nodes doen direct I/O voor normale reads en writes, en omzeilen de coordinator daarmee volledig.

Dit werkt goed wanneer het cluster gebalanceerd is. De coordinator-rol voor één CSV vraagt een kleine hoeveelheid CPU en geheugen op de eigenaar, dus de load verdeelt zich vanzelf. Het werkt slecht wanneer één node alle CSV's tegelijk bezit. Die node doet dan metadata-werk voor elke workload in het cluster, en elke operatie die wél via redirected I/O loopt (wat automatisch gebeurt als direct I/O onmogelijk is) gaat via die node.

Twee situaties forceren redirected I/O. De storage-connectiviteit naar het volume is op de lokale node verloren (de node heeft geen direct pad, dus I/O wordt over het clusternetwerk gerouteerd naar de coordinator, die het pad nog wel heeft). Of de operatie is er een die altijd via de coordinator loopt (de meeste metadata-operaties, sommige snapshot-werkzaamheden, backup-software die het volume in bepaalde modi benadert).

Redirected I/O wordt ondersteund en is veilig. Het is ook significant trager dan direct I/O en kan cluster-netwerken verzadigen als je het laat lopen.

2. Waarom ownership scheef raakt, drie praktijkpatronen

Patroon 1: de Patch Tuesday-parade

CAU (Cluster Aware Updating) draint een node, patcht hem, brengt hem terug, draint de volgende. Elke node geeft zijn CSV's aan welke node op dat moment capaciteit heeft, meestal de net gepatchte node, die de laagste load heeft. Aan het eind van de run bezit de laatst-gepatchte node de meeste of alle CSV's.

Patroon 2: de middernachtelijke failover

Een ongeplande failover (meestal een NIC-firmware glitch, storage-pad dat flapt, of een host die kort zijn quorum-stem kwijt was) verplaatst alle CSV's van de falende node naar één andere node. Niemand merkt het 's ochtends, want de workloads draaien. De onbalans blijft staan tot de volgende interventie.

Patroon 3: de "ik zet 't later wel terug" debug-sessie

Een engineer pinde alle CSV's op één node om een node-specifiek probleem uit te sluiten tijdens een incident, loste het issue op, en heeft de pin nooit ongedaan gemaakt. We vinden PreferredOwners-waarden op CSV-resources maanden na het oorspronkelijke incident, met de engineer die ze instelde inmiddels niet meer in dienst.

3. De performance-impact, met cijfers

Op een four-node Hyper-V cluster met een gemiddelde VDI-workload heeft ClusterTriage in een recente Hyper-V cluster assessment de impact gemeten.

Workload: 220 VDI-desktops, mix van boot storm en steady state. Cluster: 4 × Dell R7625, S2D, all-NVMe, 25 GbE storage.

State A: CSV's gebalanceerd (3 per node, 12 CSV's totaal)
  Gemiddelde read-latency:  0.62 ms
  P99 read-latency:          2.1 ms
  Coordinator CPU:           5-8% per node

State B: Eén node bezit alle 12 CSV's (post-patch, geen rebalance)
  Gemiddelde read-latency:  1.08 ms
  P99 read-latency:          9.4 ms (4.5x slechter)
  Coordinator CPU:          22-28% op de eigenaar
  Storage-clusternetwerk:    verzadigd tijdens boot storm

Het cluster was in State B technisch gezond. Niets alarmeerde. Het enige symptoom aan gebruikerszijde was klachten over inlogtijden, die het ops-team aan het onderzoeken was onder de werkhypothese dat er een netwerkprobleem in de VDI-farm zat. De fix kostte acht minuten.

Een kanttekening bij waar deze cijfers vandaan komen: dit was een S2D-cluster, all-NVMe, en S2D is waar onbalans het hardst aankomt. Op S2D houdt de eigenaar-node ook de CSV read-cache en een groot deel van de storage-netwerk-routing vast, dus alle CSV's op één node stapelen concentreert metadata, cache-localiteit en routing tegelijk op dezelfde plek. Op een klassieke SAN houdt elke node zijn eigen directe pad naar de LUN, dus steady-state reads blijven direct ongeacht wie de CSV bezit, en de read-latency-straf is doorgaans een stuk kleiner. Wat op SAN wél pijn doet is de metadata-load op de coordinator en alles wat in redirected I/O belandt, met een node die een storage-pad verliest als veelvoorkomende trigger. De onbalans is op beide architecturen het corrigeren waard, verwacht alleen dat hij op verschillende plekken opduikt: steady-state read-latency op S2D, metadata-zware operaties en pad-failures op SAN.

4. Ownership en traffic diagnosticeren

Drie views geven het volledige beeld:

# Verdeling van ownership
Get-ClusterSharedVolume |
    Select-Object Name, OwnerNode, State |
    Group-Object OwnerNode |
    Sort-Object Count -Descending |
    Select-Object Name, Count

# Redirected I/O, alles wat niet 'Direct' is, is verdacht
Get-ClusterSharedVolume | ForEach-Object {
    [PSCustomObject]@{
        Name       = $_.Name
        Owner      = $_.OwnerNode
        IOMode     = $_.SharedVolumeInfo.Partition.IsBlockIOMode  # $true = direct
        Redirected = $_.SharedVolumeInfo.RedirectedAccess
    }
}

# Coordinator CPU per node, uitvoeren tijdens een normale werkdag
Get-Counter -Counter '\Cluster Shared Volume(*)\IO Read Bytes/sec' `
    -SampleInterval 5 -MaxSamples 12

Het ClusterTriage Cluster Assessment-rapport bevat een one-liner per CSV: owner, mode (direct of redirected), gemiddelde read-latency over het inventarisatie-venster, en een vlag als PreferredOwners op iets anders dan default staat.

5. Handmatige rebalance, de veilige procedure

Een handmatige rebalance is veilig tijdens kantoortijden. Move-ClusterSharedVolume draagt de coordinator-rol over zonder verstoring van draaiende VM's, het volume blijft beschikbaar. Het enige wat gebeurt is een korte pauze in metadata-operaties op die CSV, in milliseconden gemeten.

# Bepaal welke CSV te verplaatsen
Get-ClusterSharedVolume |
    Select-Object Name, OwnerNode |
    Group-Object OwnerNode |
    Where-Object Count -gt 3

# Verplaats één CSV naar een specifieke node
Move-ClusterSharedVolume -Name 'CSV-VDI-Pool-03' -Node 'HV02'

# Verplaatsen en verifiëren
Move-ClusterSharedVolume -Name 'CSV-VDI-Pool-03' -Node 'HV02' -PassThru |
    Select-Object Name, OwnerNode, State

Wil je een node drainen, bijvoorbeeld voor onderhoud, verplaats dan zijn CSV's expliciet, in plaats van te vertrouwen op automatische balancing:

$sourceNode  = 'HV01'
$targetNodes = (Get-ClusterNode |
    Where-Object {$_.State -eq 'Up' -and $_.Name -ne $sourceNode}).Name

$i = 0
Get-ClusterSharedVolume | Where-Object OwnerNode -eq $sourceNode | ForEach-Object {
    $target = $targetNodes[$i % $targetNodes.Count]
    Write-Host "Moving $($_.Name) from $sourceNode to $target"
    Move-ClusterSharedVolume -Name $_.Name -Node $target
    $i++
}

6. Rebalance automatiseren

Microsoft introduceerde automatische CSV-balancing in Windows Server 2016. Het staat default aan en werkt in de meeste omgevingen goed. Je kunt het verifiëren en bijsturen:

(Get-Cluster).CsvBalancer

# Waarden:
#   0 = uit
#   1 = altijd balanceren (default)
#   2 = balanceren alleen bij overschrijden van threshold

# Direct herevalueren forceren
(Get-Cluster).CsvBalancer = 1
$cluster = Get-Cluster
$cluster.CsvBalancer = $cluster.CsvBalancer

Twee gevallen waarin automatische balancing niet doet wat je wilt. CSV-resources met expliciete PreferredOwners, de balancer respecteert die. En heterogene node-sizing, de balancer behandelt nodes als gelijken, dus als één node de helft van RAM/CPU van de anderen heeft, verdeelt gelijk balanceren de load slecht.

Voor beide gevallen is een geplande PowerShell-rebalance na onderhoudsvensters het veiligere patroon. ClusterTriage levert dit als onderdeel van het remediation-rapport bij elke opdracht waar onbalans een bevinding is.

7. Drie manieren om te rebalancen: CSV-ownership, VMM en VM-uitlijning

'Rebalancing' wordt gebruikt voor drie verschillende operaties die elk een ander probleem oplossen, en het loont om precies te zijn over welke je bedoelt.

• Native CSV-balancing (CsvBalancer en Move-ClusterSharedVolume, hierboven) verplaatst de coordinator-rol tussen nodes. Het spreidt metadata-load en, op S2D, cache-localiteit. Het verplaatst geen VM's en heeft geen mening over waar een VM draait ten opzichte van de CSV waarop hij staat.
• VMM Dynamic Optimization verplaatst VM's tussen hosts om CPU en geheugen te balanceren. Het is compute-bewust en storage-blind: het migreert een VM met Live Migration naar een node die de CSV van die VM niet bezit, wat op S2D stilletjes redirected reads en cross-node storage-verkeer toevoegt. Goed voor compute-hotspots, maar het kan tegelijk tegen storage-localiteit in werken.
• VM's uitlijnen met hun storage verplaatst VM's de andere kant op: naar de node die de CSV bezit waarop hun schijven staan, zodat reads direct blijven en het coordinator-pad kort is. Dit is de as die noch CsvBalancer noch VMM raakt. ClusterTriage draait dit vanuit een site-bewust placement-script, gebouwd op het oorspronkelijke align-VMs-with-storage idee van Darryl van der Peijl, met WhatIf-veiligheid en een before/after-weergave.

De drie zijn complementair, niet concurrerend. Een gezond patroon: laat CsvBalancer de coordinator-ownership gelijk houden, laat VMM (als je het draait) compute-hotspots afhandelen, en draai na onderhoud een uitlijn-ronde zodat VM's bij hun storage staan in plaats van waar de laatste failover ze achterliet. De volledige uitwerking van onze uitlijn-aanpak staat in VMs uitlijnen met hun storage, en het oorspronkelijke idee waarop het voortbouwt is het align VMs with storage script van Darryl van der Peijl.

8. CSV BlockCache en waarom dat de wiskunde verandert

CSV BlockCache is een read-side memory-cache op iedere node. Aangezet, verlaagt het de kosten van redirected reads dramatisch, omdat de meeste vanuit lokaal RAM worden geserveerd. Het lost onbalans niet op, maar het verzacht wel de gevolgen ervan.

(Get-Cluster).BlockCacheSize   # waarde in MB, 0 = uit

# Aanzetten met 2 GB per node, pas aan op je RAM-budget
(Get-Cluster).BlockCacheSize = 2048

# Per-CSV cache-status verifiëren
Get-ClusterSharedVolume | ForEach-Object {
    $_ | Select-Object Name,
        @{N='CacheEnabled';E={$_.SharedVolumeInfo.Partition.IsCsvCacheEnabled}}
}

Dimensioneer BlockCache vanuit je steady-state RAM-headroom, niet vanuit de N-1 geëvacueerde toestand. Verifieer dat VM-dichtheid nog comfortabel past onder failover-condities. Wij adviseren typisch 1 tot 4 GB per node op Hyper-V clusters en 4 tot 16 GB op storage-zware workloads.

Volledige context over BlockCache trade-offs zit in Hyper-V cluster assessment: 10 issues die we steeds vinden in 2026, issue 7.

9. Herhaling voorkomen

Het ClusterTriage remediation-patroon voor CSV ownership onbalans heeft vier delen.

1. Verwijder expliciete PreferredOwners op elke CSV, tenzij er een gedocumenteerde reden is. De meeste die wij vinden zijn residu van debugsessies.
2. Zet CSV BlockCache aan op 1 tot 4 GB per node en verifieer enabled state op elke CSV-partitie.
3. Voeg een geplande rebalance toe als post-maintenance stap in elk runbook. CAU's post-update tasklist is de juiste plek, gebruik je geen CAU, dan moet je patch-automatisering het regelen.
4. Monitor de ownership-verdeling als metriek. We voegen een script van vijf regels toe aan ops-dashboards: aantal CSV's per node, alarm als één node meer dan (totaal / nodes) + 1 bezit.

CSV ownership onbalans is het schoolvoorbeeld van een bevinding die monitoring-tools missen omdat elk individueel onderdeel er gezond uitziet. Het zichtbaar maken is precies waar een onafhankelijke Hyper-V cluster assessment voor is.

Plan een Hyper-V cluster assessment kennismaking →