SQL Server Cluster: Probleme mit UniqueIDs in Virtualisierungsumgebungen

Neulich hatte ich einen spannenden Fall bei einem Kunden: Die Cluster-Validierung für ein neues SQL Server Failover Cluster Instanz (FCI) schlug fehl, ohne dass auf den ersten Blick ersichtliche Gründe vorlagen. Nach genauerer Analyse zeigte sich das Problem: Beide Knoten des Clusters hatten identische UniqueIDs für ihre lokalen Platten – ein typisches, aber leicht zu übersehenes Problem in Virtualisierungsumgebungen.

Warum treten diese Probleme auf, und wie kann man sie verhindern? Denn gerade in Hyper-V- und VMware-Umgebungen sind identische UniqueIDs auf virtuellen Festplatten keine Seltenheit. In diesem Beitrag zeige ich dir, was dahintersteckt und welche Maßnahmen du ergreifen kannst, um solche Probleme von Anfang an zu vermeiden.

1. Das Problem: Identische UniqueIDs im Cluster-Storage

Was passiert?

• Bei der Cluster-Validierung von Windows Failover Clustern, sei es für reine SQL Server FCIs oder Always On-Verfügbarkeitsgruppen, kann es vorkommen, dass Storage-Volumes oder virtuelle Disks identische UniqueIDs aufweisen.
• Windows Failover Clustering verlässt sich genau auf diese UniqueIDs, um Storage-Ressourcen eindeutig zu identifizieren.
• Sind die UniqueIDs nicht eindeutig, scheitert die Cluster Validierung, da die vorherigen Prüfungen nicht erfolgreich durchgeführt werden können.

Fehlermeldung, in meinem Fall:

List Disks To Be Validated
Description: List disks that will be validated for cluster compatibility.
Start: 19.03.2025 12:16:00.
Failed while verifying removal of any Persistent Reservation on physical disk {d6c11058-b3fb-4969-b059-f978d9eaa837} at node node1.sub.domain.de.
Failed while verifying removal of any Persistent Reservation on physical disk {d6c11058-b3fb-4969-b059-f978d9eaa837} at node node1.sub.domain.de.
Stop: 19.03.2025 12:16:00.

2. Warum tritt dieses Problem besonders in virtualisierten Umgebungen auf?

In physischen Umgebungen wird sichergestellt, dass jedes SAN- oder NAS-Storage eine eindeutige LUN-ID besitzt. In virtualisierten Umgebungen treten jedoch häufig folgende Probleme auf:

• Klonen von VMs oder Platten führen zu identischen UniqueIDs.
• Snapshots oder Replikationen von VMs überschreiben die ursprünglichen IDs.
• Automatisierte Provisionierungstools erstellen VMs mit duplizierten Speichergeräten.

📌 Tipp: Falls dein Cluster auf gemeinsamem Storage (z. B. vSAN, iSCSI oder Fibre Channel) läuft, solltest du explizit prüfen, ob alle Disks eindeutige IDs besitzen.

3. Wie du das Problem erkennen kannst

Disk-IDs in Windows PowerShell überprüfen

Get-Disk | Select-Object Number, FriendlyName, UniqueId

Falls mehrere Datenträger dieselbe UniqueID haben, besteht Handlungsbedarf.

Alternativ mit diskpart die Disk-IDs überprüfen

Starte diskpart als Admin:

diskpart

Wähle eine der betroffenen Platten (z. B. C:)

list disk
select disk 0  # oder die entsprechende Nummer

Lass dir die UniqueID für die ausgewählte Disk anzeigen

uniqueid disk

4. Lösungsansätze: So verhinderst du Storage-Identitätskonflikte

1. Vor der Cluster-Einrichtung prüfen:

• Verwende Get-Disk, um sicherzustellen, dass alle Datenträger eine eindeutige UniqueID haben.
• Falls sich IDs überschneiden, sollten die betroffenen Platten neu provisioniert oder ihre UniqueIDs geändert werden (bspw mit diskpart – siehe oben).

2. Storage-Provisioning optimieren:

• Stelle sicher, dass jede virtuelle Festplatte eine neue ID erhält.
• Falls du Disks aus Snapshots oder Klonen erstellst, ändere manuell die UniqueID.

3. IDs in VMware vSphere oder Hyper-V prüfen: Falls du VMware einsetzt, kannst du über esxcli storage core device list die Storage-IDs abfragen.

4. Windows Disk Signature neu generieren (falls erforderlich): Falls zwei Datenträger dieselbe ID haben, kannst du sie mit diskpart anpassen:

uniqueid disk id=xxxxxxxxx

Dann klappt es auch mit der Cluster-Validierung und einem funktionierenden SQL Server Failover Cluster steht nichts mehr im Wege.

Fazit: Frühzeitig prüfen, bevor es knallt!

Das Problem mit identischen UniqueIDs in Cluster-Storage-Umgebungen kann SQL Server-Clustern unerwartete Probleme bereiten. Durch frühzeitige Überprüfung, sauberes Storage-Provisioning und eindeutige Disk-IDs kannst du Failover-Fehler vermeiden. 🚀

• Prüfe vor der Cluster-Einrichtung, ob alle Storage-Devices eindeutige IDs haben.
• Nutze PowerShell & Cluster-Logs, um Probleme frühzeitig zu erkennen.
• Falls nötig, ändere die UniqueID betroffener Datenträger.
• Dokumentiere deine Storage-Prozesse, um identische IDs in Zukunft zu vermeiden.

Hast du bereits Erfahrungen mit diesem Problem gemacht? Lass es mich wissen – ich freue mich auf den Austausch! 😊

Björn Peters

Björn arbeitet auch weiterhin aus Griechenland als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.