Storage Spaces Direct (S2D) und darauf basierende Failover-Cluster lösen nach einem Datenträgerausfall oder einer Wartungspause automatisch eine Resynchronisation aus – den sogenannten Repair-Prozess, der redundante Daten auf dem verbliebenen oder neu eingesetzten Datenträger wiederherstellt. Wie viel CPU- und I/O-Kapazität dieser Prozess gegenüber aktiven Workloads erhält, steuert die Queue Depth des virtuellen Disk-Repair-Warteschlangenmodells.

Entgegen der naheliegenden Erwartung arbeitet Windows hier nicht mit abstrakten Stufen wie "low", "medium" oder "high", sondern mit einem numerischen Tiefenwert üblicherweise von 1 bis 16, der die Parallelität der abgearbeiteten Repair-I/Os steuert. Der Standardwert liegt bei 4 – eine Einstellung, die grob dem mittleren Bereich entspricht und produktive Workloads schonen soll.

Konfiguration per PowerShell

Den aktuellen Wert setzen Sie mit folgendem PowerShell-Befehl, wobei der FriendlyName des jeweiligen Storage-Subsystems einzutragen ist: 

Set-StorageSubSystem -FriendlyName "Clustered Windows Storage" -VirtualDiskRepairQueueDepth 8

Ein höherer Wert steigert den Repair-Durchsatz, belastet aber I/O-Subsystem und CPU stärker – auf produktiven Systemen unter Last kann das zu merklichen Latenzzuwächsen führen.

Umgekehrt riskiert ein zu niedriger Wert, dass der Rebuild-Prozess bei einem zweiten Laufwerksausfall noch nicht abgeschlossen ist: ein klassisches Resilienz-Problem in größeren RAID-ähnlichen Spiegelungsverbünden. Den gesetzten Wert verifizieren Sie anschließend mit:

Get-StorageSubSystem | Select-Object FriendlyName, VirtualDiskRepairQueueDepth

Empfehlung für die Praxis

Die richtige Queue Depth ist eine Abwägung zwischen Wiederherstellungszeit und Produktivlast. In Wartungsfenstern oder bei unkritischen Systemen lohnt ein temporäres Hochschrauben auf 12 bis 16, um den Rebuild-Prozess zügig abzuschließen und das Resilienz-Fenster – also die Phase erhöhter Ausfallgefahr – so kurz wie möglich zu halten.

Im laufenden Betrieb unter Volllast empfiehlt sich hingegen ein konservativerer Wert zwischen 2 und 6. Da der Befehl ohne Neustart sofort greift, lässt sich der Wert auch dynamisch anpassen: Repair-Phase mit hoher Tiefe starten, bei steigender Systemlast zurückschrauben, nach Abschluss wieder auf den Standardwert setzen.

Besonderheiten ab Windows Server 2022

Ab Windows Server 2022 hat Microsoft den Unterbau von Storage Spaces Direct weiter optimiert, insbesondere im Bereich Caching und I/O-Optimierung. Das System ist nun intelligenter darin, freie Ressourcen im I/O-Pfad selbstständig zu erkennen. Dennoch bleibt die manuelle Steuerung über die "VirtualDiskRepairQueueDepth" ein wichtiges Werkzeug für Notfälle.

Ein wichtiger Aspekt bei modernen Setups mit NVMe-Speicher und RDMA-Netzwerkverbindungen: Bevor Sie den Wert auf das Maximum von 12 oder 16 schrauben, sollten Sie sicherstellen, dass die Hardware-Warteschlangen Ihrer Controller nicht bereits durch die Produktivlast gesättigt sind.

In High-Performance-Szenarien kann eine zu hohe Queue Depth paradoxerweise dazu führen, dass sich Repair-I/Os und Applikations-I/Os gegenseitig blockieren. Hier gilt: In modernen All-Flash-Systemen (AFM) ist ein moderater Wert von 8 oft der "Sweet Spot", der den Rebuild massiv beschleunigt, ohne die NVMe-Latenzen für die virtuellen Maschinen in kritische Bereiche zu treiben.

Monitoring nicht vernachlässigen

Die Anpassung der Repair-Queue-Depth sollte nie ohne begleitendes Monitoring erfolgen. Entscheidend ist nicht allein der schnellere Rebuild, sondern wie sich die Änderung auf Latenzen und Durchsatz der Produktiv-Workloads auswirkt – insbesondere die Latenzen auf physischer Datenträgerebene (etwa Avg. Disk sec/Read und Avg. Disk sec/Write). Einen ersten Überblick liefert "Get-StorageJob", das Fortschritt und Aktivität laufender Repair-Prozesse sichtbar macht.

Für eine belastbare Bewertung sollten Administratoren zusätzlich Performance-Daten heranziehen. Relevante Indikatoren sind insbesondere die Latenzen auf physischer Datenträgerebene sowie die Auslastung der CSV-Volumes. Diese lassen sich über die Leistungsüberwachung (PerfMon) oder die Cluster-Performance-Historie erfassen. Steigen die Antwortzeiten für Lese- oder Schreibzugriffe unter erhöhter Queue Depth deutlich an, ist der gewählte Wert zu aggressiv und sollte entsprechend reduziert werden.

Weitere Inhalte zum Thema Storage finden Sie in

IT-Administrator September 2025: Storage-Management

Die letzten Jahre waren von einem massiven Datenwachstum in Unternehmen geprägt. In der September-Ausgabe widmet sich IT-Administrator dem Thema Storage und zeigt, wie Sie einen hochverfügbaren Speicher mit Storage Spaces Direct planen und mit dem Azure Storage Explorer Ihre Daten im Blick behalten.

Bestellen Sie hier das Einzelheft, Abonnenten finden alle Artikel außerdem im Heftarchiv.