RDMA, SMB Direct, CSV und S2D systematisch überprüfen

SQL-Datenbankkorruptionen in virtuellen Maschinen lassen schnell den Verdacht aufkommen, dass der darunterliegende Storage fehlerhaft arbeitet. Doch ein zeitlicher Zusammenhang ist noch kein technischer Beweis.

Dieser Praxisbericht zeigt, wie wir einen Windows-Server-2019-Failovercluster mit Storage Spaces Direct, SMB Direct und RDMA über RoCE v2 Schritt für Schritt untersucht haben. Dabei konnten mehrere naheliegende Hypothesen überprüft, wichtige Infrastrukturkomponenten vermessen und die weitere Ursachenanalyse auf die noch offenen Fehlerdomänen ausgerichtet werden.

Hinweis zur Anonymisierung: Sämtliche Hostnamen, VM-Namen, Datenbanknamen, IP-Adressen, Gerätenamen, Seriennummern und kundenspezifischen Infrastrukturinformationen wurden für diesen Artikel anonymisiert oder abstrahiert. Die Diagramme dienen der technischen Veranschaulichung und bilden die reale Umgebung nicht vollständig ab.

Die untersuchte Hyper-V- und S2D-Umgebung

Untersucht wurde ein produktiver Hyper-V-Failovercluster auf Basis von Windows Server 2019 Datacenter.

  • vier Hyper-V- und S2D-Knoten
  • Storage Spaces Direct
  • mehrere Cluster Shared Volumes
  • zwei dedizierte 25-Gbit/s-Storage-Netzwerke pro Knoten
  • RDMA-fähige Ethernet-Adapter
  • RoCE v2 als RDMA-Transport
  • Priority Flow Control und Enhanced Transmission Selection
  • SMB Direct und SMB Multichannel
  • mehrere SQL-Server-VMs
  • getrennte VHDX-Dateien für Betriebssystem, SQL-Systemdatenbanken, Benutzerdatenbanken und Transaktionsprotokolle

Der Cluster war einige Monate vor dem Auftreten der untersuchten Datenbankprobleme zusammen mit den zugehörigen Storage-Switches in ein anderes Rechenzentrum umgezogen worden.

Später wurden in mehreren SQL-Server-VMs Datenbankinkonsistenzen beziehungsweise Korruptionen festgestellt. Davon waren insbesondere Datenbankdateien auf separaten virtuellen Festplatten betroffen.

Verursacht eine Störung im S2D-, CSV-, SMB-Direct- oder RDMA-Datenpfad die beobachteten SQL-Probleme?

image-4-1024x681 SQL-Datenbankkorruption auf Hyper-V und S2D analysieren


End-to-End-Datenpfad

Abbildung 1: Vereinfachter Datenpfad einer SQL-Server-VM über Hyper-V, Cluster Shared Volumes, SMB Direct und RDMA bis zum Storage-Spaces-Direct-Pool.

Alt-Text: Architekturdiagramm einer SQL-Server-VM auf Hyper-V mit VHDX-Dateien, Cluster Shared Volume, SMB Direct, zwei RDMA-Netzen und Storage Spaces Direct.

Warum hohe I/O-Latenz nicht automatisch Datenkorruption bedeutet

Bei Datenbankkorruptionen werden häufig Begriffe wie „Storageproblem“, „mangelnde I/O-Leistung“ oder „Netzwerkfehler“ verwendet, bevor ein belastbarer technischer Zusammenhang hergestellt wurde.

Hohe I/O-Latenz

Eine I/O-Anforderung wird erfolgreich abgeschlossen, benötigt aber ungewöhnlich lange.

I/O-Timeout oder wiederholter I/O

Eine Anforderung kann nicht rechtzeitig abgeschlossen werden oder eine zunächst fehlgeschlagene Operation wird erneut ausgeführt.

Transportstörung

Eine SMB-, RDMA- oder Netzwerkverbindung fällt aus, wird unterbrochen oder muss neu aufgebaut werden.

Datenkorruption und Datenbankinkonsistenz

Gelesene Daten entsprechen nicht dem erwarteten Inhalt oder der erwarteten Prüfsumme. SQL Server kann zusätzlich ungültige Seiten, Zuordnungen oder interne Datenbankstrukturen erkennen.

Diese Zustände können miteinander zusammenhängen, müssen es aber nicht. Eine langsame I/O-Operation allein beweist keine Datenkorruption. Umgekehrt bedeutet ein aktuell gesunder Storage Pool nicht, dass es früher keine kurzzeitige Störung gegeben haben kann.

Troubleshooting entlang des vollständigen S2D-Datenpfads

  1. SQL Server und Datenbankintegrität
  2. Gastbetriebssystem und virtuelle Maschine
  3. VHDX-Dateien und virtuelle Storage-Controller
  4. Hyper-V-Storage-Stack
  5. Cluster Shared Volumes
  6. SMB Direct und SMB Multichannel
  7. RDMA und RoCE v2
  8. Storage Spaces Direct
  9. physische Datenträger
  10. beteiligte Netzwerk-Switches

Nicht jede Ebene konnte im ersten Durchlauf abschließend bewertet werden. Ziel war zunächst, den Zustand der Infrastruktur zu vermessen und nach belastbaren Fehlerindikatoren zu suchen.

image-3-1024x683 SQL-Datenbankkorruption auf Hyper-V und S2D analysieren

Troubleshooting Journey

Abbildung 2: Der Analysepfad von der gemeldeten SQL-Korruption über Storage, CSV, SMB Direct und RDMA bis zur weiterführenden Untersuchung auf SQL- und Anwendungsebene.

Alt-Text: Ablaufdiagramm einer Ursachenanalyse bei SQL-Datenbankkorruption mit Prüfungen von S2D, CSV, RDMA, SMB Direct, Netzwerk und historischen Ereignissen.

Storage Spaces Direct mit PowerShell überprüfen

Zunächst wurde der aktuelle Zustand des S2D-Subsystems untersucht. Dabei waren der Poolzustand, die Redundanz, die physischen Laufwerke und eventuell laufende Reparaturvorgänge besonders relevant.

Storage Pool, virtuelle Datenträger und Storage-Jobs anzeigen

Get-StoragePool -IsPrimordial $false |
    Format-List FriendlyName,
                HealthStatus,
                OperationalStatus,
                IsReadOnly,
                Size,
                AllocatedSize

Get-VirtualDisk |
    Format-Table FriendlyName,
                 ResiliencySettingName,
                 HealthStatus,
                 OperationalStatus,
                 DetachedReason,
                 Size,
                 FootprintOnPool -AutoSize

Get-StorageJob |
    Format-Table Name,
                 IsBackgroundTask,
                 JobState,
                 PercentComplete,
                 BytesProcessed,
                 BytesTotal,
                 ElapsedTime -AutoSize

Physische S2D-Datenträger prüfen

Get-PhysicalDisk |
    Sort-Object FriendlyName |
    Format-Table FriendlyName,
                 SerialNumber,
                 FirmwareVersion,
                 MediaType,
                 Usage,
                 HealthStatus,
                 OperationalStatus,
                 CannotPoolReason,
                 Size -AutoSize

Storage Reliability Counter auslesen

Get-PhysicalDisk |
    Get-StorageReliabilityCounter |
    Select-Object DeviceId,
                  Temperature,
                  TemperatureMax,
                  Wear,
                  PowerOnHours,
                  ReadErrorsTotal,
                  ReadErrorsUncorrected,
                  WriteErrorsTotal,
                  WriteErrorsUncorrected,
                  ReadLatencyMax,
                  WriteLatencyMax,
                  FlushLatencyMax |
    Format-Table -AutoSize

Ergebnis der S2D-Momentaufnahme

  • Der S2D-Pool wurde als gesund gemeldet.
  • Die virtuellen Datenträger waren online.
  • Es liefen keine Storage-Jobs.
  • Es lag kein Zustand mit reduzierter oder fehlender Redundanz vor.
  • Die produktiven Poollaufwerke meldeten keine nicht korrigierbaren Lese- oder Schreibfehler.
  • Einzelne korrigierte Leseereignisse waren vorhanden, jedoch keine nicht korrigierbaren Fehler.

Diese Ergebnisse belegten einen aktuell gesunden S2D-Zustand. Die Momentaufnahme beweist jedoch nicht rückwirkend, dass während des Incident-Zeitraums niemals eine transiente Storage-Störung aufgetreten ist.

Cluster Shared Volumes und Redirected I/O untersuchen

Im nächsten Schritt wurden Status, Eigentümerknoten und Erreichbarkeit der Cluster Shared Volumes sowie relevante Failover-Clustering-Ereignisse geprüft.

CSV-Status anzeigen

Get-ClusterSharedVolume |
    Format-List Name,
                State,
                OwnerNode,
                SharedVolumeInfo

Relevante Failover-Clustering-Ereignisse suchen

$Start = Get-Date '2026-07-01 00:00:00'

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-FailoverClustering/Operational'
    StartTime = $Start
} -ErrorAction SilentlyContinue |
    Where-Object {
        $_.Id -in 5120, 5142, 1135
    } |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  MachineName,
                  Message |
    Sort-Object TimeCreated

Im untersuchten und noch vorhandenen Ereignisbestand wurden keine passenden Ereignisse gefunden. Damit gab es in den verfügbaren Daten keine Hinweise auf protokollierte CSV-Kommunikationsverluste, nicht erreichbare CSVs oder relevante Knotenausfälle.

Aufbewahrungszeitraum der Ereignisprotokolle kontrollieren

Ein leeres Suchergebnis ist nur dann historisch aussagekräftig, wenn das Ereignisprotokoll den vollständigen Untersuchungszeitraum abdeckt.

$LogNames = @(
    'System',
    'Microsoft-Windows-FailoverClustering/Operational'
)

foreach ($LogName in $LogNames) {
    $LogInfo = Get-WinEvent -ListLog $LogName
    $Oldest  = Get-WinEvent -LogName $LogName `
                            -Oldest `
                            -MaxEvents 1 `
                            -ErrorAction SilentlyContinue

    [pscustomobject]@{
        LogName       = $LogName
        OldestEvent   = $Oldest.TimeCreated
        RecordCount   = $LogInfo.RecordCount
        MaximumSizeMB = [math]::
            $LogInfo.MaximumSizeInBytes / 1MB,
            2
        )
        IsEnabled     = $LogInfo.IsEnabled
    }
}

RoCE v2, PFC und ETS auf den Clusterknoten prüfen

Da die Umgebung RoCE v2 verwendete, musste die Data-Center-Bridging-Konfiguration auf den Hyper-V-Knoten überprüft werden.

Priority Flow Control anzeigen

Get-NetQosFlowControl |
    Sort-Object Priority |
    Format-Table Priority,
                 Enabled,
                 PolicySet -AutoSize

ETS-Traffic-Classes anzeigen

Get-NetQosTrafficClass |
    Format-Table Name,
                 Algorithm,
                 Priority,
                 BandwidthPercentage -AutoSize

QoS-Konfiguration der RDMA-Adapter prüfen

Get-NetAdapterQos `
    -Name 'STORAGE-A','STORAGE-B' |
    Format-List *

In der untersuchten Konfiguration wurde der SMB-Traffic einer dedizierten Priorität zugeordnet. PFC war ausschließlich für diese Priorität aktiviert. Beide Storage-Adapter zeigten eine symmetrische Hostkonfiguration und für SMB stand eine eigene ETS-Traffic-Class zur Verfügung.

Eine plausible Hostkonfiguration beweist allerdings nicht, dass die beteiligten Switches ebenfalls konsistent konfiguriert sind. Bei geswitchtem RoCE v2 müssen PFC, ETS, Queue-Zuordnung, Queue-Drops, Pause Frames, CRC- und FEC-Fehler, MTU und Link-Stabilität entlang des vollständigen Netzwerkpfades betrachtet werden.

SMB Direct und SMB Multichannel im S2D-Cluster nachweisen

Dass eine Netzwerkkarte als RDMA-fähig angezeigt wird, beweist allein noch nicht, dass der S2D-Datenpfad tatsächlich RDMA verwendet. Deshalb wurden die SMB-Instanzen CSV und SBL separat untersucht.

Storage Bus Layer prüfen

Get-SmbMultichannelConnection `
    -SmbInstance SBL `
    -IncludeNotSelected |
    Format-Table ServerName,
                 ClientInterfaceFriendlyName,
                 ClientIpAddress,
                 ServerIpAddress,
                 CurrentChannels,
                 Selected,
                 Failed,
                 ClientRdmaCapable,
                 ClientRSSCapable -AutoSize

CSV-Verbindungen prüfen

Get-SmbMultichannelConnection `
    -SmbInstance CSV `
    -IncludeNotSelected |
    Format-Table ServerName,
                 ClientInterfaceFriendlyName,
                 ClientIpAddress,
                 ServerIpAddress,
                 CurrentChannels,
                 Selected,
                 Failed,
                 ClientRdmaCapable,
                 ClientRSSCapable -AutoSize

Aktive SBL-Sitzungen anzeigen

Get-SmbConnection -SmbInstance SBL |
    Format-Table ServerName,
                 ShareName,
                 Dialect,
                 NumOpens,
                 ContinuouslyAvailable -AutoSize

Zu jedem Peer-Knoten bestanden Verbindungen über beide Storage-Netze. Die RDMA-fähigen Transportkandidaten waren ausgewählt, während die TCP- beziehungsweise RSS-Kandidaten nicht ausgewählt waren. Die Managementschnittstelle wurde nicht als aktiver S2D-Storage-Pfad verwendet.

Ein dauerhafter Fehler wie „RDMA ist deaktiviert“, „nur ein Storage-Netz wird verwendet“ oder „S2D läuft über das Managementnetz“ ließ sich für den Messzeitpunkt somit nicht bestätigen.

RDMA-Aktivität, Durchsatz und SMB-Direct-Stalls messen

Verfügbare SMB-Direct-Counter ermitteln

Get-Counter -ListSet '*SMB Direct*' |
    Select-Object -ExpandProperty PathsWithInstances

RDMA- und Send-Stalls kontrollieren

Get-Counter `
    '\SMB Direct Connection(_Total)\Stalls (RDMA Read)/sec'

Get-Counter `
    '\SMB Direct Connection(_Total)\Stalls (Send Queue)/sec'

Get-Counter `
    '\SMB Direct Connection(_Total)\Stalls (Send Credit)/sec'

Bei der Stichprobe lagen alle drei Werte bei null.

RDMA-Datenverkehr nachweisen

Get-Counter `
    '\SMB Direct Connection(_Total)\Bytes RDMA Read/sec'

Get-Counter `
    '\SMB Direct Connection(_Total)\Bytes RDMA Written/sec'

Beide Counter lieferten Messwerte. Damit war aktive RDMA-Kommunikation zum Messzeitpunkt nachgewiesen.

Paketfehler und verworfene Pakete prüfen

$Adapters = 'STORAGE-A','STORAGE-B'

Get-NetAdapterStatistics -Name $Adapters |
    Format-Table Name,
                 ReceivedBytes,
                 SentBytes,
                 ReceivedDiscardedPackets,
                 OutboundDiscardedPackets,
                 ReceivedPacketErrors,
                 OutboundPacketErrors -AutoSize

Die Windows-Adapterstatistiken zeigten in der Momentaufnahme keine Paketfehler und keine verworfenen Pakete.

Die Messung belegt, dass SMB Direct und RDMA zum Prüfzeitpunkt aktiv und ohne sichtbare Stalls arbeiteten. Eine kurze Momentaufnahme kann sporadische Fehler unter anderen Lastbedingungen jedoch nicht ausschließen.

image-2-1024x684 SQL-Datenbankkorruption auf Hyper-V und S2D analysieren

Infrastructure Health Assessment

Abbildung 3: Zusammenfassung der zum Untersuchungszeitpunkt geprüften Infrastrukturkomponenten. Ein positiver Status beschreibt die jeweilige Momentaufnahme und ist kein rückwirkender Beweis für den gesamten Incident-Zeitraum.

Alt-Text: Dashboard mit Prüfergebnissen zu Storage Spaces Direct, virtuellen und physischen Datenträgern, CSV, SMB Direct, RDMA, RoCE und Netzwerkadaptern.

Historische Hyper-V-StorageVSP-Latenzen richtig einordnen

Im Hyper-V-StorageVSP-Protokoll waren zahlreiche Ereignisse mit der ID 9 vorhanden. Diese Meldungen dokumentierten VHDX-I/O-Anforderungen, die teilweise mehr als 30 Sekunden bis zum Abschluss benötigten.

Betroffen waren das Betriebssystem, SQL-Systemdatenbanken, Benutzerdatenbanken und SQL-Transaktionsprotokolle. Auf den ersten Blick wirkte dieser Befund wie eine plausible Erklärung für die gemeldeten SQL-Probleme.

Den korrekten StorageVSP-Kanalnamen ermitteln

Get-WinEvent -ListLog '*StorageVSP*' |
    Format-Table LogName,
                 RecordCount -AutoSize

In der untersuchten Umgebung lautete der technische Kanalname Microsoft-Windows-Hyper-V-StorageVSP-Admin. Der Kanal verwendet vor Admin einen Bindestrich und keinen Schrägstrich.

StorageVSP-Ereignisse anzeigen

Get-WinEvent `
    -LogName 'Microsoft-Windows-Hyper-V-StorageVSP-Admin' |
    Where-Object {
        $_.Id -eq 9
    } |
    Select-Object -First 20 `
                  TimeCreated,
                  Id,
                  Message

Nur den relevanten Incident-Zeitraum prüfen

$Start = Get-Date '2026-07-01 00:00:00'

Get-WinEvent `
    -LogName 'Microsoft-Windows-Hyper-V-StorageVSP-Admin' |
    Where-Object {
        $_.Id -eq 9 -and
        $_.TimeCreated -ge $Start
    } |
    Select-Object TimeCreated,
                  Id,
                  Message |
    Sort-Object TimeCreated

Die vorhandenen StorageVSP-Ereignisse stammten aus einem wesentlich früheren Zeitraum. Seit Beginn des untersuchten aktuellen Zeitfensters wurden keine entsprechenden Ereignisse gefunden. Außerdem lagen die historischen Ereignisse vor dem Rechenzentrumsumzug und deutlich vor den gemeldeten SQL-Korruptionen.

Die älteren Ereignisse belegen frühere I/O-Verzögerungen, aber keinen kausalen Zusammenhang mit den später aufgetretenen Datenbankproblemen.

image-1-1024x677 SQL-Datenbankkorruption auf Hyper-V und S2D analysieren

Incident-Timeline

Abbildung 4: Zeitliche Trennung zwischen historischen Hyper-V-StorageVSP-Latenzereignissen und den wesentlich später gemeldeten SQL-Datenbankproblemen.

Alt-Text: Zeitstrahl mit historischen Storage-Latenzereignissen, einer längeren Phase ohne vergleichbare Meldungen und später auftretenden SQL-Datenbankproblemen.

Kann deaktiviertes IPv6 einen S2D-Cluster beeinflussen?

Während der Netzwerkanalyse fiel auf, dass die IPv6-Protokollbindung auf sämtlichen Hostschnittstellen deaktiviert war. Betroffen waren die Managementschnittstellen, die 10-Gbit/s-Adapter und beide 25-Gbit/s-Storage-Adapter.

IPv6-Bindungen mit PowerShell prüfen

Get-NetAdapterBinding |
    Where-Object {
        $_.ComponentID -eq 'ms_tcpip6'
    } |
    Format-Table Name,
                 Enabled -AutoSize

Für den untersuchten Messzeitpunkt gab es keinen belastbaren Hinweis darauf, dass die deaktivierte IPv6-Bindung die SQL-Probleme verursachte. Die SBL- und CSV-Verbindungen waren aktiv, beide IPv4-Storage-Netze wurden verwendet und SMB Direct transportierte Daten über RDMA.

Die vollständig deaktivierte IPv6-Bindung bleibt dennoch eine Designabweichung. Eine Anpassung sollte getrennt von der laufenden Incident-Analyse, nach Prüfung der Herstellervorgaben und in einem geplanten Wartungsfenster erfolgen.

SQL-Korruption Schicht für Schicht analysieren

image-5-1024x678 SQL-Datenbankkorruption auf Hyper-V und S2D analysieren

Layered Root Cause Analysis

Abbildung 5: Schichtenmodell der Ursachenanalyse von SQL Server über Hyper-V, CSV, SMB Direct und RDMA bis zum physischen S2D-Storage.

Alt-Text: Mehrschichtiges Analysemodell mit SQL Server, virtueller Maschine, Hyper-V, CSV, SMB Direct, RDMA über RoCE, Storage Spaces Direct und SSD-Pool.

SQL Server und Datenbankintegrität

  • SQL-Fehler 823, 824 und 825
  • Page-Checksum-Fehler
  • DBCC-CHECKDB-Ergebnisse
  • betroffene Datenbankseiten und Dateien
  • Zeitpunkt der ersten nachweisbaren Inkonsistenz
  • SQL-I/O-Latenzen je Datenbankdatei

Gastbetriebssystem und VHDX-Dateien

  • Dateisystemereignisse im Gast
  • virtuelle Storage-Controller
  • VHDX- und AVHDX-Ketten
  • vorhandene Checkpoints
  • Backup- und VSS-Aktivität
  • Antivirus und Filtertreiber

Hyper-V, CSV, SMB Direct und RDMA

  • Hyper-V-StorageVSP-Ereignisse
  • CSV-Zustand und Redirected I/O
  • Besitzwechsel des CSV
  • Hostwechsel der betroffenen VM
  • ausgewählte Multichannel-Verbindungen
  • aktive RDMA-Kanäle und Datenverkehr
  • Stalls und Verbindungsfehler

RoCE-Fabric und physischer Storage

  • PFC je Priorität
  • ETS-Traffic-Classes
  • Queue-Drops und Pause Frames
  • CRC-, Symbol- und FEC-Fehler
  • Switch-Firmware, Kabel und Transceiver
  • physische Laufwerke und Storage-Reliability-Counter
  • Repair-, Rebuild- und Rebalance-Vorgänge

Entscheidungsbaum für S2D-, RDMA- und SQL-Probleme

image-6-1024x683 SQL-Datenbankkorruption auf Hyper-V und S2D analysieren

S2D Troubleshooting Decision Tree

Abbildung 6: Entscheidungsbaum zur systematischen Eingrenzung von CSV-, SMB-Direct-, RDMA-, Netzwerk-, S2D- und SQL-Problemen.

Alt-Text: Entscheidungsbaum für die Diagnose eines vermuteten Storage-Problems mit Prüfpfaden für CSV, Clusterereignisse, SMB Direct, RDMA, Netzwerk, Storage Pool und SQL Server.

  1. Konkreten SQL-Fehler identifizieren: Fehlernummer, Zeitstempel, Datenbank und betroffene Datei dokumentieren.
  2. Zeitgleiche Ereignisse suchen: Host-, Gast-, Cluster-, Storage- und Switchdaten im selben Zeitfenster untersuchen.
  3. Aktuellen Datenpfad messen: SBL, CSV, SMB Direct, RDMA und Storage Pool anhand aktiver Verbindungen und Counter überprüfen.
  4. Reproduzierbarkeit feststellen: Bei einem reproduzierbaren Fehler alle Ebenen parallel erfassen.
  5. Gemeinsame Fehlerdomäne suchen: Host, CSV, S2D-Knoten, Storage-Netz, VHDX, Datenbank und Wartungsaktivität miteinander korrelieren.

Ergebnisse der S2D- und RDMA-Analyse

  • Der S2D-Pool war zum Prüfzeitpunkt gesund.
  • Die virtuellen Datenträger waren online.
  • Es liefen keine Storage-Reparaturjobs.
  • Die produktiven Laufwerke meldeten keine nicht korrigierbaren Medienfehler.
  • Die Cluster Shared Volumes waren erreichbar.
  • Beide 25-Gbit/s-Storage-Netze wurden für SBL und CSV verwendet.
  • SMB Direct war aktiv.
  • RDMA-Datenverkehr war messbar.
  • Die Managementschnittstelle wurde nicht als aktiver Storage-Pfad verwendet.
  • Die Stichprobe zeigte keine RDMA-, Send-Queue- oder Send-Credit-Stalls.
  • Die Windows-NIC-Statistiken meldeten keine Paketfehler oder Discards.
  • Die StorageVSP-Latenzereignisse lagen außerhalb des aktuellen Incident-Zeitraums.
  • Die deaktivierte IPv6-Bindung war eine Designabweichung, ließ sich jedoch nicht mit den SQL-Problemen korrelieren.

Grenzen der durchgeführten Momentaufnahme

Aus positiven Prüfergebnissen folgt nicht, dass die Infrastruktur mit absoluter Sicherheit niemals beteiligt war.

  • Ereignisprotokolle können bereits überschrieben worden sein.
  • Switch-Counter können zwischenzeitlich zurückgesetzt worden sein.
  • Ohne kontinuierliche Aufzeichnung bleiben kurze Störungen möglicherweise unsichtbar.
  • Ein Problem kann nur bei einem bestimmten Lastprofil auftreten.
  • Die Umgebung kann sich nach einem transienten Fehler selbst erholt haben.
  • Ein Infrastrukturfehler kann auf SQL- oder Gastebene anders sichtbar werden.

Zum Untersuchungszeitpunkt konnte kein belastbarer Nachweis für eine aktive Störung in Storage Spaces Direct, Cluster Shared Volumes, SMB Direct oder RDMA erbracht werden.

SQL Server als nächste Fehlerdomäne untersuchen

Da die geprüften Infrastrukturkomponenten keine hinreichende Erklärung lieferten, muss die weiterführende Analyse bei den konkreten SQL-Fehlern beginnen.

SQL-Fehlerprotokoll durchsuchen

EXEC xp_readerrorlog 0, 1, N'Error: 823';
EXEC xp_readerrorlog 0, 1, N'Error: 824';
EXEC xp_readerrorlog 0, 1, N'Error: 825';
EXEC xp_readerrorlog 0, 1, N'I/O requests taking longer';

SQL-I/O-Latenz je Datenbankdatei auslesen

SELECT
    GETDATE() AS CollectionTime,
    DB_NAME(vfs.database_id) AS DatabaseName,
    mf.name AS LogicalFileName,
    mf.physical_name,
    vfs.num_of_reads,
    vfs.io_stall_read_ms,
    CASE
        WHEN vfs.num_of_reads = 0 THEN 0
        ELSE vfs.io_stall_read_ms / vfs.num_of_reads
    END AS AvgReadLatencyMs,
    vfs.num_of_writes,
    vfs.io_stall_write_ms,
    CASE
        WHEN vfs.num_of_writes = 0 THEN 0
        ELSE vfs.io_stall_write_ms / vfs.num_of_writes
    END AS AvgWriteLatencyMs
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
INNER JOIN sys.master_files AS mf
    ON vfs.database_id = mf.database_id
   AND vfs.file_id = mf.file_id
ORDER BY AvgWriteLatencyMs DESC;

Die entscheidende Frage lautet nun nicht nur, ob der Storage langsam war. Entscheidend ist, welcher konkrete SQL-Fehler wann, in welcher Datenbankdatei, auf welchem VM-Knoten, auf welchem Hyper-V-Host und auf welchem CSV auftrat.

Lessons Learned aus dem S2D-Troubleshooting

  • Eine plausible Hypothese ist noch kein Befund. Rechenzentrumsumzug, RoCE-Fabric und SQL-Korruption können zeitlich zusammenpassen, ohne kausal verbunden zu sein.
  • „RDMA aktiviert“ reicht nicht als Prüfung. Ausgewählte Pfade, aktive Kanäle, RDMA-Datenverkehr, Stalls und Verbindungsfehler müssen gemessen werden.
  • Historische Ereignisse benötigen Kontext. Ein alter I/O-Ausreißer ist kein Beweis für einen wesentlich späteren Incident.
  • Ein gesunder S2D-Pool schließt frühere Störungen nicht aus. Transiente Probleme können nachträglich nicht mehr im aktuellen Health State sichtbar sein.
  • Switchdaten gehören zu jeder RoCE-Analyse. Hostseitige Counter allein reichen nicht aus.
  • Konfigurationsänderungen und Beweissicherung müssen getrennt werden. Änderungen während der Analyse können neue Einflussfaktoren erzeugen.
  • Ausschlussdiagnostik ist ein valides Ergebnis. Jeder sauber dokumentierte Ausschluss reduziert die Fehlerdomäne.

Fazit: Kein belastbarer Nachweis für einen aktiven S2D- oder RDMA-Fehler

Der untersuchte Cluster zeigte zum Zeitpunkt der Diagnose ein konsistentes Bild. Storage Spaces Direct war gesund, die Cluster Shared Volumes waren erreichbar, SMB Direct war aktiv und beide RDMA-Netze wurden verwendet.

In der Messstichprobe waren keine RDMA-Stalls, Paketfehler oder Discards sichtbar. Die vorhandenen massiven StorageVSP-Latenzereignisse gehörten zu einem wesentlich älteren Vorfall. Die deaktivierte IPv6-Bindung entsprach nicht dem empfohlenen Sollzustand, konnte aber nicht als Ursache der SQL-Korruption bestätigt werden.

Damit ließ sich die anfängliche These eines offensichtlichen S2D-, SMB-Direct- oder RDMA-Fehlers nicht erhärten. Die Untersuchung ist dennoch nicht abgeschlossen. Der Schwerpunkt verschiebt sich auf die SQL- und VM-Ebene sowie auf eine zeitgenaue Korrelation mit Host-, CSV-, Storage- und Switchdaten.

Die wichtigste Erkenntnis: Infrastrukturprobleme sollten nicht aufgrund ihrer Plausibilität angenommen werden. Sie müssen anhand von Ereignissen, Messwerten und einer gemeinsamen Zeitachse nachgewiesen werden.

Weiterführende Microsoft-Dokumentation

Über den Autor

Oliver Sommer

Senior System Consultant mit Schwerpunkt auf Microsoft-Infrastrukturen, Windows Server, Hyper-V, Failover Clustering, Storage Spaces Direct, Microsoft Intune, Azure und PowerShell-Automatisierung.

Alle technischen Bezeichnungen der ursprünglichen Kundenumgebung wurden anonymisiert. Die gezeigten Befehle sind Beispiele und müssen vor dem Einsatz in einer produktiven Umgebung geprüft werden.
Dieser Beitrag wurde unter Verwendung von KI-Tools erstellt und redaktionell geprüft.