Start/News/2-Node S2D Cluster
DATACENTER · 10 Min. Lesezeit · Engineering-Notes

2-NODE S2D
CLUSTER
BEIM KUNDEN
VOR ORT.

Beim Kunden eine eigene Hyperconverged-Plattform aufzubauen lohnt sich oft schon mit zwei Knoten. Microsoft Storage Spaces Direct für rund 40 VMs — mit RDMA-Direktverbindung, File Share Witness und realistischen IOPS-Erwartungen für SQL-Workloads.

NODE 1 NODE 2 RDMA · 25 GbE RDMA · 25 GbE 9× NVMe · Storage Pool A 9× NVMe · Storage Pool A (Mirror) FILE SHARE WITNESS · TWO-WAY MIRROR 2-Node-Topologie. Beide Knoten gleich bestückt, Storage als Two-Way-Mirror, Quorum durch externen File Share Witness im EGW-Datacenter.

Vorab: S2D ist eines der unterschätzten Microsoft-Features. Es liefert Hyperconverged-Setups, die mit deutlich teureren Lösungen wie Nutanix konkurrieren können — und das mit Windows-Server-Lizenzen, die Sie sowieso haben.

01 WARUM 2 KNOTEN

Der Kunde — ein mittelständischer Produktionsbetrieb — hatte rund 40 VMs in zwei klassischen Hypervisoren am End-of-Life. Cloud war keine Option (regulatorisch, Latency zur Produktions-IT). Drei oder mehr Nodes wären überdimensioniert. Zwei Knoten, mit File Share Witness in unserem Datacenter, treffen den Sweet-Spot.

02 HARDWARE-AUSWAHL

  • Dell PowerEdge R760xs pro Knoten — 2× Intel Xeon Gold, 512 GB RAM
  • 9× NVMe-SSDs pro Knoten als Mixed-Use Storage Pool
  • 2× 25 GbE Mellanox für RDMA-Direktverbindung (RoCE)
  • 2× 10 GbE für Client-Traffic (Trunk)
  • iDRAC + redundante Netzteile — Standard

Die Direktverbindung der zwei Knoten ohne Zwischenswitch war eine bewusste Entscheidung: weniger Latency, kein Switch-Failover-Drama, einfachere Konfiguration. Bei mehr als drei Knoten geht das nicht — bei zweien ist es perfekt.

03 KONFIGURATION

Storage Pool als Two-Way-Mirror, weil bei zwei Knoten Three-Way nicht geht. Das heißt: jeder Block existiert genau zweimal, auf beiden Nodes. Resilienz gegen Komplett-Ausfall eines Nodes ist gegeben, gegen Doppel-Fehler nicht. Der Trade-Off ist klar: 50 % der Brutto-Kapazität ist nutzbar, dafür eine extrem einfache Topologie.

Quorum löst der File Share Witness in unserem DC Wien. Damit haben wir den klassischen Split-Brain-Schutz, ohne einen dritten Knoten irgendwo aufstellen zu müssen.

04 REALE IOPS-ERWARTUNGEN

Wir messen seit dem Go-Live regelmäßig. SQL-Workloads des Kunden (gemischt OLTP + Reporting) sehen typischerweise:

  • Read-IOPS: stabil über 200 000 — das war erwartet, NVMe ist da konsequent
  • Write-IOPS: ~80 000 sustained — durch den Mirror halbiert sich der theoretische Wert
  • Latency P99: unter 1 ms — entscheidend für die Reporting-Queries des Kunden

Wichtig: das sind Werte unter Produktionslast, nicht aus einem synthetischen Benchmark.

05 WAS WIR GELERNT HABEN

  • Failover-Cluster-Manager-Updates müssen geplant werden — kein einfaches "Windows Update Tuesday".
  • S2D-Tooling in Windows Admin Center hat sich in den letzten Versionen stark verbessert. Lohnt sich.
  • NVMe-Firmware-Updates sind ein eigenes Kapitel. Wir orchestrieren das über Ansible.
  • Backup mit Veeam funktioniert ohne Drama, wenn man die VMs cluster-aware konfiguriert.

Wenn Sie eine ähnliche Plattform brauchen — am eigenen Standort oder in unserem Datacenter — sprechen Sie mit uns über die Kontakt-Seite oder telefonisch unter +43 (0)1 235 1277.