Anleitung: Storage Spaces Direct auf Cluster mit zwei Knoten einrichten

Um einen ersten Eindruck von diesem Feature zu bekommen, reicht bereits ein virtuelles Labor. Es kann die meisten physischen System­voraus­setzungen nachbilden und auch Ausfälle simulieren. Installiert man es auf einem Notebook, dann eignet es sich zudem für Demos, um S2D den Kunden, Kollegen oder Workshop-Teilnehmern näher­zubringen.

Generell ist es sinnvoll, Storage Spaces Direct unter Windows Server Core zu konfigurieren. In diesem Lab jedoch kommt aus Gründen der Flexibilität die vertraute Desktop Experience zum Einsatz. Zudem entfallen hier die unter reellen Bedingungen eventuell nötigen SSDs oder NVMe als Cache-Speicher, auch wird in dieser virtuellen Umgebung der MediaType (SSD oder HDD) nicht angepasst. RDMA-fähige Netzwerk­karten bleiben ebenfalls außen vor.

Benötigte VMs, virtuelle Festplatten und Netzwerke

Mein mobiles Dell-Labor basiert auf Windows 10 1607 mit einer zügigen 480GB SanDisk Extreme Pro SSD als Unterbau, 32GB RAM und einem SLAT-fähigen i7-Prozessor. Für die Nested Virtualization aktiviere ich Hyper-V und erstelle zu Beginn zwei virtuelle Switche, einmal für den externen Zugriff und zum anderen für ein internes Netzwerk. Auf dieser Basis werden nun drei virtuelle Maschinen erzeugt:

• 1 x Gen2 v8 VM mit dynamischem Arbeitsspeicher für die Active Directory Domain Services und DNS
• 2 x Gen2 v8 VM mit statischem Arbeitsspeicher für die Knoten von Storage Spaces Direct

An den SCSI-Controller der S2D-Knoten werden neben dem Systemlaufwerk vier weitere fixe virtuelle Festplatten angehängt, eine spätere BusType Verifizierung zeigt hier korrekt die nötige SAS Schnittstelle an. Diese bilden die spätere Grundlage des lokalen Cluster-Speichers. Danach müssen präparierte VMs für Storage Spaces Direct mit Windows Server 2016 Datacenter installiert und auf Updates hin überprüft werden.

Simulierte Netzwerk­karten und Netzwerke der S2D-Knoten richte ich wie folgt mittels Hot-add ein und versuche mich dabei reellen Bedingungen mit zwei physischen 10Gbps-NICs im converged Design anzunähern:

Das emulierte klassische NIC Teaming (LBFO) kann in einer reellen Umgebung durch ein Switch Embedded Teaming (SET) ersetzt werden. SET ist dann auch in der Lage RDMA-NICs zusammenzufassen. Ein Labor LBFO-Team erstelle ich wie folgt:

New-NetLbfoTeam "tNIC" `
-TeamMembers "sim-pNIC-01-10-A", "sim-pNIC-02-10-A" `
-TeamNicName "tNIC" -TeamingMode SwitchIndependent `
-LoadBalancingAlgorithm TransportPorts

Die virtuellen Netzwerkadapter (vNICs) der Parent Partition werden später an den Hyper-V Switch angeschlossen, welcher mit o.g. Team (tNIC) verbunden ist.

Die Knoten werden dann in die Domäne aufgenommen. Für eine verschachtelte Virtualisierung bereite ich zu Beginn den virtuellen Prozessor vor:

Set-VMProcessor -VMName S2D-NODE-A -ExposeVirtualizationExtensions $true

Hyper-V und Failover-Clustering installieren, Cluster formen

Danach wird Hyper-V auf beiden Knoten aktiviert, die später angewandte Variable $Node verwende ich in weiteren Cmdlets. Für folgende Aufgaben kann natürlich auch die GUI des Server- oder Failovercluster-Manager herhalten:

Install-WindowsFeature -Name Hyper-V -ComputerName S2D-NODE-A `   -IncludeManagementTools -IncludeAllSubFeature

Nach einem Neustart erstelle ich den virtuellen Hyper-V Switch inkl. QoS und erzeuge erforderliche vNICs in der Parent Partition nach folgendem Muster wie eingangs erwähnt:

New-VMSwitch "HVvSwitch" –NetAdapterName "tNIC" –MinimumBandwidthMode Weight –AllowManagementOS $false Set-VMSwitch -Name "HVvSwitch" `   -DefaultFlowMinimumBandwidthWeight 40 Add-VMNetworkAdapter –ManagementOS –Name "Management" `   –SwitchName "HVvSwitch" Set-VMNetworkAdapter -ManagementOS -Name "Management" `   -MinimumBandwidthWeight 10

Wenn alle IPs konfiguriert wurden und der Domain join erfolgt ist, wird das Feature Failover-Clustering auf beiden Knoten aktiviert:

$Node = "S2D-NODE-A","S2D-NODE-B" foreach ($n in $Node) {  Install-WindowsFeature -Name Failover-Clustering `   -ComputerName $n -IncludeManagementTools }

Anschließend sollten die Knoten der Validierung standhalten:

Test-Cluster -Node $Node -Include "Storage Spaces Direct",`
"Netzwerk","Hyper-V-Konfiguration","Inventar","Systemkonfiguration"

Nun lässt sich der Cluster bilden:

New-Cluster -Name S2D -Node $Node -NoStorage -StaticAddress 172.16.5.25 `
-IgnoreNetwork "192.168.4.0/24","10.12.0.0/24"

Schließlich werden die Cluster-Netzwerke umbenannt und ihre Verwendung konfiguriert, bei Live-Migrationen verwende ich die vNICs des Storage. Um den Cloud-Zeugen zu etablieren binde ich Azure Deutschland im Quorum ein:

Set-ClusterQuorum -CloudWitness -Cluster S2D -AccountName "witness" `
-Endpoint "core.cloudapi.de" -AccessKey "sxQXi4a/XXXXXXXXXXX …  XXX89YTPw=="

Wichtig dabei ist aber, dass die Azure Subscription nicht unbeobachtet abläuft. Sinnvoll kann dann die Konfiguration eines File-share Witness bei einem 2-Knoten Cluster sein.

Für ein Windows Server 2016 VM Load Balancing (Node Fairness) belasse ich alle Werte auf Standard.

Storage Spaces Direct aktivieren und Volumes anlegen

S2D wird mit folgender Funktion aktiviert. Es bildet automatisch einen Cluster-Pool und weist auf den fehlenden Cache-Speicher hin:

Enable-ClusterStorageSpacesDirect

Der Cache kann hier mit dem Schalter -CacheState Disabled explizit abgeschaltet werden. Als Alias dient Enable-ClusterS2D und der Schalter -Verbose liefert in der Konsole mehr Informationen bei Aktivierung.

Anschließend lassen sich mit dem Cmdlet Get-ClusterS2D die Einstellungen für Storage Spaces Direct abrufen. Neue gespiegelte Cluster-Volumes (Spaces) legt man letztendlich an mit:

New-Volume -StoragePoolFriendlyName "S2D*" -FriendlyName Volume01 `
-FileSystem CSVFS_ReFS -Size 35GB

New-Volume -StoragePoolFriendlyName "S2D*" -FriendlyName Volume02 `
-FileSystem CSVFS_ReFS -Size 35GB

Dabei werden gleichzeitig die Cluster Shared Volumes erzeugt, auf denen später die hochverfügbaren virtuellen Maschinen Platz finden, beispielsweise unter C:\ClusterStorage\Volume01.