Start/News/2-Node S2D Cluster
DATACENTER · 2 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 9× NVMe Ein Storage Pool über beide Knoten · Two-Way Mirror FILE SHARE WITNESS 2-Node-Topologie. Beide Knoten gleich bestückt, Storage als ein clusterweiter Pool, Volumes als Two-Way-Mirror, Quorum über 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 auf Basis von Windows Server Datacenter, das in vielen Umgebungen ohnehin lizenziert ist.

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, keine Switch-Failover-Probleme, 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 (NVMe ist da konsequent)
  • Write-IOPS: ca. 80 000 sustained. Jeder Schreibvorgang landet wegen des Mirrors auf beiden Knoten, die effektive Schreibrate liegt also rund bei der Hälfte der Roh-Leistung.
  • 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 spontanes "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 Überraschungen, wenn man die VMs cluster-aware konfiguriert.

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