Überblick: Windows Server 2016 Storage Spaces Direct im 2-Node-Cluster

S2D nutzt dafür bekannte Technologien und Features von Windows Server wie das Failover-Clustering, Cluster Shared Volumes, SMB und PowerShell. Shared Storage in Form von kostspieligen proprietären Appliances mit dazugehörigem SAN sind somit nicht mehr erforderlich, um einen Hyper-V-Cluster zu implementieren.

Die kleinste Konfiguration in einem Cluster mit 2 Knoten eignet sich zudem gut für den Einsatz in Zweig­nieder­lassungen oder in kleineren und mittleren Unter­nehmen.

Es gibt zwei Einsatz­szenarien für Storage Spaces Direct: Zum einen die Ein­richtung eines eigen­ständigen Storage-Tiers und eines separaten Hyper-V Clusters (disaggregiert), zum anderen die Kombination von Hyper-V mit gemeinsamen Speicher auf der gleichen Hardware (Hyper-converged).

Cluster-Design und Hardware-Umgebung

Bei einer Hyper-converged Infrastructure (HCI) entfällt die Rolle des Scale-out File Server (SoFS), und virtuelle Maschinen werden hochverfügbar auf dem "lokalen" Cluster Shared Volume (CSV) abgelegt. Ermöglicht wird das durch den virtuellen Software Storage Bus (SSB), welcher den physischen Speicher der Cluster-Knoten für alle Nodes sichtbar und zugänglich macht.

Durch den Knotenverbund über SMB 3.1.1, idealerweise mit redundanten RDMA Karten (Remote Direct Memory Access), und lokalem Massenspeicher entfällt auch die bei 2012 SoFS nötige SAS-Kreuzverkabelung mit Shared JBODs. Live Migrationen sind ebenfalls performant über die RDMA-Infrastruktur möglich.

Skalieren (Scale-out) müssen die Knoten im HCI-Design dann als komplette Einheit. Für die Intra-Cluster-Kommunikation sind mindestens 10 Gbps-NICs erforderlich. Storage Spaces Direct lassen sich im Cluster-Verbund aus 2 bis 16 Knoten mit Windows Server 2016 Datacenter und lokalem SATA-, SAS- am "einfachen" SAS HBA oder NVMe-Speicher betreiben. Kommen beispielsweise SSDs oder NVMe als Cache plus HDDs zum Einsatz, dann besteht eine minimale hybride Konfiguration aus zwei SSDs oder NVMe und vier HDDs pro Host.

Architektur eines Hyper-converged Stack mit 2 Knoten

In diesem Blog-Post richte ich den Fokus auf das Layout für eine Hyper-converged Infrastructure, wo die Knoten auch die Rolle des Microkernel-Hypervisor Hyper-V erhalten. Storage und virtuelle Workloads sind somit auf den Nodes im Hyper-V Cluster vereint und stellen eine kompakte Einheit dar. Dadurch lassen sich auch die zusätzlichen Kosten für die Infrastruktur einer disaggregierten Lösung einsparen.

Betrachtet man den Hyper-converged Stack, bestehend aus zwei identischen Knoten mit SSDs für das Caching und HDDs für VHDs, dann erstrecken sich darüber die Storage Spaces Direct. Die Hosts erhalten eine Version von Windows Server 2016 Datacenter (Core oder Desktop Experience) und werden dem Active Directory hinzugefügt.

Danach wird die Hypervisor-Ebene mit der Aktivierung von Hyper-V eingezogen, um virtuelle Maschinen später im CSV ablegen zu können und hochverfügbar vorzuhalten. Die Hosts sind untereinander mit RDMA-Adaptern verbunden, welche entweder RoCE (RDMA over Converged Ethernet) oder iWARP (internet Wide Area RDMA Protocol) sprechen und niedrige Latenzen gewährleisten.

Auf beiden Knoten wird außerdem das Feature Failover-Clustering installiert und ein Zwei-Knoten-Verbund ohne Storage gebildet. SMB-Multichannel im selben Subnet vereinfacht die Konfiguration. Der Cluster-Witness kann dabei in der Azure Cloud (Deutschland) liegen. Eine Validierung des Clusters ist wie immer auch hier wichtig.

Danach aktiviert man den Software Storage Bus mit dem PowerShell-Cmdlet Enable-ClusterStorageSpacesDirect, um die physischen Platten beider Hosts für das Cluster zugänglich zu machen.

Dabei wird automatisch ein Pool gebildet, wobei die performanten Flash-Speicher für das Read-Write-Caching und die HDDs als Kapazitäts­speicher dienen. Automatisch erkannte SSDs oder NVMe werden bei ein Hybrid-Entwurf nicht für die Kapazitätsberechnung herangezogen. Anschließend erstellt man Zwei-Wege Mirror Storage Spaces (Virtual Disks), die mit ReFS formatiert und als Cluster Shared Volumes eingerichtet werden.