In diesem Artikel geht es um die Bereitstellung von geclusterten Windows-Storages. Um genau zu sein, werden die internen Festplatten zweier Windows Server zu einem übergreifenden Speicherpool zusammengefasst und beide Cluster-Knoten können diesen Speicher nutzen.

Es gibt hierzu auch einige Artikel von Microsoft, von verschiedenen MVPs oder IT’lern auf Youtube oder IT-Blogs. Ich beschreibe hier meine eigene Erfahrung und reihe mich damit in die o.g. Gruppe von möglichen Informationsquellen ein.

Für den Testaufbau verwende ich mein Notebook, das hat genug CPU-Kerne, Arbeitsspeicher und ausreichend Festplattenplatz. Ein Domain-Controller ist bereits als VM aufgesetzt und stellt das benötigte Active Directory bereit. Ebenso ist eine VM mit dem aktuellen Windows Admin Center verfügbar.

Vorwort

Im ersten Versuch war angedacht, dass die Umgebung mit dem aktuellen (2511) Windows Admin Center bereitgestellt wird. Was anfangs auch ganz zuverlässig wirkte, hatte aber später seine Stolpersteine und Hürden und war letztlich nicht von Erfolg gekrönt. Daher wurde der Versuch dann abgebrochen und auf Basis von PowerShell mit neuen VMs durchgeführt.
Ich lasse aber den WAC-Teil drin, sodass andere sich das anschauen dürfen und ggfs. versuchen es nachzustellen.

Cluster-VMs

Für die beiden Cluster-VMs werden folgende VM-Configs auf meinem lokalen Hypervisor angelegt:

Einstellung	Wert
Name	WAC-Versuch: HLMS2DN01 / HLMS2DN02 PowerShell-Versuch: HLMWS25N01 / HLMWS25N02
Generation	Generation 2
CPU	4 vCPU
RAM	16 GB fix
Festplatte (OS)	127 GB VHDX, dynamisch
Festplatte (Daten)	2-4 VHDX mit bspw. 20GB pro VHDX (fix, wenn möglich, ansonsten dynamisch)
Netzwerkadapter	3 NICs empfohlen: Management, S2D/Cluster, Live Migration
Betriebssystem	Windows Server 2025 Datacenter

Die Installation des Betriebssystems ist selbsterklärend, wichtig ist, dass nur darauf geachtet wird, die korrekte Festplatte auszuwählen.

Netzwerk

IP-Adressen

Für die Knoten und das Cluster werden IP-Adressen benötigt, hier empfiehlt es sich üblicherweise feste IP-Adressen zu nehmen.

Um einen Überblick über alle IP-Adressen in diesem Test-Szenario zu haben, habe ich hierfür eine Tabelle erstellt:

IP-Adresse	Virtuelles Switch	System/Funktion
192.168.210.11	vINT-HLM01	Domain-Controller
192.168.210.12	vINT-HLM01	Domain-Controller
192.168.210.13	vPRI-HLM01	Windows Admin Center
192.168.210.20	vPRI-HLM01	S2D-Node Cluster-IP
192.168.210.21	vPRI-HLM01	S2D-Node 01
192.168.210.22	vPRI-HLM01	S2D-Node 02
192.168.210.254	vPRI-HLM01	DEFAULT-GATEWAY
192.168.221.21	vPRI-HLM01-S2D-Storage01	S2D-Node 01 – Storage-Adapter 1
192.168.221.22	vPRI-HLM01-S2D-Storage01	S2D-Node 02 – Storage-Adapter 1
192.168.222.21	vPRI-HLM01-S2D-Storage02	S2D-Node 01 – Storage-Adapter 2
192.168.222.22	vPRI-HLM01-S2D-Storage02	S2D-Node 02 – Storage-Adapter 2

Virtuelle Switche

Wie aus der obigen Tabelle entnommen werden kann, wird nicht nur das Switch für den normalen Datenverkehr (bspw. zu den Domain-Controllern) benötigt, sondern auch für die Storage-Netzwerkkarten. Bei einem physikalischen zwei Knoten-Cluster würden die ohne Switch direkt verkabelt werden. Hier bei den VMs lässt sich nur mittels separatem virtuellen Switch quasi das “virtuelle Kabel” darstellen.

Netzwerkkarten

Standardmäßig werden die VMs mit einer Netzwerkkarte installiert, danach sollten aber die weiteren Netzwerkkarten noch hinzugefügt werden, also hat jede VM dann:

• 2x NIC für MGMT
• 2x NIC für Storage (ggfs. Live-Migration)

In der VM-Config sieht das so aus:

Im Betriebssystem dann je nach Tool dann so:

---

Es empfiehlt sich, dass die Adapter jetzt gleich korrekt benannt werden, sodass sie im späteren Verlauf ordentlich zu ihren Aufgaben zugewiesen werden können.

---

IP-Adresse via DHCP

Sofern im Servernetzwerk mit DHCP gearbeitet wird, kann es gerade bei den MGMT-Adaptern passieren, dass dann beide eine IP-Adresse erhalten. Im weiteren Verlauf der Einrichtung kann das unter Umständen zu Problemen führen, daher sollte DHCP deaktiviert werden. Dazu gibt es zwei Variaten:

1. DHCP auf den einzelnen Netzwerk-Adaptern deaktivieren
2. DHCP auf dem gesamten System deaktivieren

hier kurz beide Varianten erläutert:

Variante 1 – per Adapter

Per PowerShell-Befehl:

Get-NetIPInterface | Where-Object {$_.AddressFamily -eq "IPv4" -and $_.Dhcp -eq "Enabled"} | Set-NetIPInterface -Dhcp Disabled

---

Variante 2 – komplettes System

Per PowerShell den Registry-Eintrag anpassen oder setzen:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name EnableDHCP -Value 0

und danach einen Neustart durchführen.

---

WAC – Sonstige Vorbereitungen

Klar, die Systeme müssen:

• nach o.g. Tabelle umbenannt werden
• in das Active Directory aufgenommen werden und dort dann am besten in eine separate OU gesetzt werden
• die aktuellsten Windows Updates bekommen
• die korrekte Zeitzone eingestellt & Uhrzeit geprüft
• Ins Windows Admin Center aufgenommen werden
• Hyper-V Rolle installieren
• Netzwerk-Adapter bündeln

Aufnahme ins Windows Admin Center

Dazu im WAC anmelden und links oben auf [+ Add]-Button klicken, dann im DropDown-Menü den Eintrag [+ Add manually] auswählen.
Da die Systeme bereits in der Active Directory sind, kann danach gesucht werden, beide anhaken und auf den Button [Add] drücken.

---

Hyper-V Rolle installieren

Am Beispiel des Servers, der später der 1. Cluster-Knoten werden soll.

Wichtig: Da es sich um VMs handelt, muss zuerst noch die “Nested Virtualisation” aktiviert werden!

Im WAC auf den Server gehen und dort in der linken Menü-Spalte den Punkt “Virtual Switches” auswählen. Sofern die Hyper-V Rolle noch nicht installiert ist, wird ein großer blauer Button [Setup up virtual machine management] angezeigt; auf diesen Klicken, um zu beginnen.

Es wird aufgelistet, welche Dinge installiert werden:

• Install Hyper-V Feature
• Install Hyper-V Powershell
• Enable Hyper-V Hypervisor

Optional den Haken für den automatischen Neustart setzen und auf den Button [Setup] klicken.

eine mögliche Installationsalternative ist entweder über die Server-Manager-GUI oder über PowerShell:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools

---

Netzwerk-Adapter bündeln

Durch die vorherige Installation von Hyper-V lassen sich die Netzwerk-Adapter jetzt auf die moderne Weise bündeln. Das bedeutet anstelle von sog. “Teamings” werden jetzt mittels PowerShell-Befehl (weder in der Hyper-V GUI noch im Windows Admin Center ist ein grafischer Assistent dafür vorgesehen) die sog. “Switch Embedded Teamings” (= kurz “SET” bzw. “SET-Switche”) angelegt.

Management-Ports

Dafür wird zuerst nach den Namen der Adapter geschaut, danach ein Switch erstellt für die Management-Ports erstellt, dabei die Parameter verwendet:

• EnableEmbeddedTeaming = True
• AllowManagementOS = True

Anschließend wird das neu erstellte Switch sinnvoll umbenannt, sodass die Klammern aus dem Namen kommen (kein Muss, aber meine persönliche BestPractice). In der Regel sollte das virtuelle Switch dann die IP-Adresse des einen Netzwerk-Adapters erhalten haben.

Get-NetAdapter
New-VMSwitch -Name "MGMT-TEAM" -NetAdapterName "mgmt-NIC01","mgmt-NIC02" -EnableEmbeddedTeaming $true -AllowManagementOS $true
Rename-NetAdapter -Name "vEthernet (MGMT-TEAM)" -NewName "MGMT-TEAM"
Get-VMSwitch
Get-VMSwitchTeam -Name "MGMT-TEAM"

Hier als Bildablauf:

---

Sollte das “MGMT-TEAM” keine IP-Adresse erhalten haben, dann muss diese manuell festgelegt werden – entweder per GUI oder per PowerShell, bspw.:

New-NetIPAddress -InterfaceAlias "MGMT-TEAM" -IPAddress 192.168.210.21 -PrefixLength 24 -DefaultGateway 192.168.210.254

Set-DnsClientServerAddress -InterfaceAlias "MGMT-TEAM" -ServerAddresses 192.168.210.11

Das neuangelegte virtuelle Switch kann im WAC ausgelesen und rudimentär bearbeitet, sowie gelöscht werden:

---

Die Empfehlung ist jedoch, alle Änderungen über PowerShell auf dem System selbst durchzuführen.

Storage-Ports

Die Storage-Ports werden NICHT gebündelt, da hier (vor allem bei einer Hardware) mittels

• SMB over RDMA
• SMB-MultiChannel

eine deutlich bessere & effizientere Performance erzielt werden kann. Ein virtuelles Switch für die Port-Bündelung würde ein zusätzliches Layer bedeuten und somit wären diese Technologien nicht nutzbar.

WAC – Failover-Cluster

Nach diesen Vorbereitungen kann das Failover-Cluster über das WAC erstellt werden. Dazu im WAC auf das “All connections”-Menü klicken und den Eintrag “Server Manager” auswählen; dort dann den Server anklicken, welcher der erste Knoten werden soll – in meinem Fall also “hlms2dn01”.

Vorbereitung

Auf der linken Seite auf “Roles & Features” klicken, dann auf der rechten Seite “Failover Clustering” auswählen und den Button [+ Install] drücken.

Alternativ kann die Installation auch über PowerShell erfolgen:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
Get-WindowsFeature Failover-Clustering
Restart-Computer

---

Cluster erstellen

Danach im Hauptmenü des WAC auf den Button [+ Add] und dort auf den Eintrag “Add manually” klicken. Es öffnet sich im rechten Bereich eine Auswahl an Möglichkeiten, hier auf “Server Clusters” runterscrollen dort auf den blauen Button [Create new] klicken.

---

Es öffnet sich ein “Cluster Creation”-Assistent bei dem ein paar Dinge abgefragt werden:

1. Cluster Type
   • Hier wähle ich “Windows Server”
2. Workload Type
   • Hier wähle ich “Virtual machines”
3. Server Locations
   • All servers in one site

---

(1) Get started

Anschließend

Falls im Schritt “Install features” einige Rollen nicht installiert sind, kann das alternativ anstelle im WAC auch pro Node per PowerShell durchgeführt werden:

Install-WindowsFeature -Name Hyper-V, NetworkATC, FS-SMBBW, Failover-Clustering, Data-Center-Bridging, BitLocker, FS-FileServer, RSAT-Clustering-PowerShell, RSAT-AD-PowerShell -IncludeAllSubFeature -IncludeManagementTools -verbose

(2) Networking

---

da nur noch ein Switch für Compute & Storage auswählbar war, bin ich wieder auf den ersten Schritt und habe das Löschen des bestehenden vSwitches bestätigt. Zudem habe ich der 2. MGMT-NIC ebenfalls eine IP-Adresse gegeben (Node01: 192.168.210.31 / Node02: 192.168.210.32).

---

(3) Clustering

Leider geht es hier dann nicht mehr weiter – keine Rückmeldung vom Windows Admin Center.

WAC – Fazit

Deswegen an der Stelle ein CUT; die beiden Knoten werden neu aufgesetzt, sodass eine Einrichtung via PowerShell vorgenommen werden kann.

---

PS – Sonstige Vorbereitungen

Klar, die Systeme müssen:

• nach o.g. Tabelle umbenannt werden
• in das Active Directory aufgenommen werden und dort dann am besten in eine separate OU gesetzt werden
• die aktuellsten Windows Updates bekommen
• die korrekte Zeitzone eingestellt & Uhrzeit geprüft
• getrennte Netzwerkadapter deaktivieren
  • PowerShell: Get-NetAdapter | Where-Object {$_.status -eq "disconnected"} | Disable-NetAdapter
• Optional: eingehende RDP-Verbindung aktivieren per PowerShell:
  • Registry: Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" -Value 0
  • Firewall: Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
• Zeitserver prüfen (sollte in der AD der Domain-Controller sein)
  • PowerShell: w32tm /query /status
• Zeitserver (falls noch nicht in der AD) auf IP des Domain-Controller setzen:
  • PowerShell: w32tm /config /manualpeerlist:"Domain-Controller-IP" /syncfromflags:manual /update
• WinRM konfigurieren per PowerShell: winrm quickconfig

Tipp:
In einer VM-basierten Testumgebung (wie hier bei mir) kann man jetzt auch gerne einen Snapshot/Checkpoint erstellen, falls nachfolgende Schritte fehlschlagen sollten.

PS – Installation Rollen & Features

Folgende Rollen & Features werden jetzt auf beiden Nodes per PowerShell installiert:

• BitLocker
• Data center bridging (DCB)
• Failover clustering
• File server
• Hyper-V
• Hyper-V PowerShell
• RSAT-AD-Clustering-PowerShell module
• RSAT-AD-PowerShell module
• NetworkATC
• SMB bandwidth limit

Install-WindowsFeature -Name Hyper-V, NetworkATC, FS-SMBBW, Failover-Clustering, Data-Center-Bridging, BitLocker, FS-FileServer, RSAT-Clustering-PowerShell, RSAT-AD-PowerShell -IncludeAllSubFeature -IncludeManagementTools -verbose

Einige dieser Rollen & Features benötigen einen Server-Neustart; um diesen ganzen Prozess möglichst kurz zu halten, werden alle Rollen fertig installiert, sodass danach nur noch ein Neustart notwendig ist.

Optional kann auch noch geprüft werden, ob alle Rollen & Features ordentlich installiert wurden:

Get-WindowsFeature -Name Hyper-V, NetworkATC, FS-SMBBW, Failover-Clustering, Data-Center-Bridging, BitLocker, FS-FileServer, RSAT-Clustering-PowerShell,RSAT-AD-PowerShell -verbose

---

PS – Failover-Cluster

Vorbereitungen

Sofern es sich um eine Hardware handelt, sollte jetzt auf jedem Knoten die Remote-Management-Netzwerkadapter per Registry-Eintrag aus den für Cluster verfügbaren Netzwerkadaptern exkludiert werden, das sind

• bei DELL: Remote NDIS Compatible Device
• bei Lenovo: xyz
• bei HP: xyz

Diese Exklusion kann einfach per PowerShell erfolgen:

New-Item -Path HKLM:\system\currentcontrolset\services\clussvc\parameters
New-ItemProperty -Path HKLM:\system\currentcontrolset\services\clussvc\parameters 
-Name ExcludeAdaptersByDescription -Value "Name-of-Remote-Management-NIC"
Get-ItemProperty -Path HKLM:\system\currentcontrolset\services\clussvc\parameters 
-Name ExcludeAdaptersByDescription | Format-List ExcludeAdaptersByDescription

Danach die Cluster-Validierung starten per PowerShell; das reicht auf einem Knoten aus (bspw. auf Knoten 1):

Test-Cluster -Node HLMWS25N01,HLMWS25N02 -Include 'Storage Spaces Direct','Inventory', 'System Configuration'

Ergebnis in meinem Fall war:

Allerdings sind das nur Warnings, es kann also weiter gemacht werden. Trotzdem auf beiden Knoten nach Windows-Updates gesucht und installiert, der Report zeigt weiterhin an, dass auf einem Knoten etwas fehlt:

Aber, wie gesagt, nur eine Warnung, daher geht’s jetzt weiter.

Eine Übersicht aller Festplatten per PowerShell anzeigen lassen und sichergehen, dass alle im “Healthy”-Status sind, sowie eine gleiche gerade Anzahl der späteren Storage-Festplatten vorhanden sind:

Get-PhysicalDisk

---

Auf einem Knoten (bspw. dem ersten) per PowerShell-Befehl das Cluster – in meinem Fall mit dem Namen “HLMWS25CL01” und der festen IP gemäß obiger Tabelle – aber ohne Storage-Zuweisung (folgt später) erzeugen:

New-Cluster -Name HLMWS25CL01 -Node HLMWS25N01,HLMWS25N02 -StaticAddress 192.168.210.20 -NoStorage

---

Network ATC

In dieser Umgebung wird der Traffic von Management und Compute gebündelt, der Storage-Traffic soll über separate Schnittstellen (welche bei einer Hardware direkt verkabelt sind) laufen.

Das ganze wird am besten per PowerShell auf einem Knoten (bspw. der erste) angelegt – in der virtuellen Testumgebung funktioniert RDMA leider nicht und wird bei mir dann weggelassen:

$mgmt_compute_nics = @('mgmt-NIC01','mgmt-NIC02')
$storage_nics = @('s2d-NIC01','s2d-NIC02')
$storage_vlans =@(711) 
# Mmgt_Vlan is optional - only when required:
# $Mgmt_Vlan=202

# DCB Quality of Server (QoS)
$QoSOverride = New-NetIntentQoSPolicyOverrides
$QoSOverride.BandwidthPercentage_Cluster = 2
$QoSOverride.PriorityValue8021Action_Cluster = 5

# Jumbo packet settings
$MgmtAdapterPropertyOverrides = New-NetIntentAdapterPropertyOverrides
$MgmtAdapterPropertyOverrides.NetworkDirect = 0
$MgmtAdapterPropertyOverrides.JumboPacket = 1514
$StorAdapterPropertyOverrides = New-NetIntentAdapterPropertyOverrides
$StorAdapterPropertyOverrides.JumboPacket = 9014

# RDMA-Settings
# Intel E810/E823 network adapter supports iWARP and RoCEv2, while Mellanox/Nvidia supports only RoCEv2.
# iWARP = 1, RoCEv2 = 4
$StorAdapterPropertyOverrides.NetworkDirectTechnology = 0

# Storage-NIC IPS will not be set automatically with this:
$StorageOverride = New-NetIntentStorageOverrides
$StorageOverride.EnableAutomaticIPGeneration = $false

Management-Intent erstellen und anschließend prüfen:

Add-NetIntent -Name Management_Compute -Management -Compute -AdapterName $mgmt_compute_nics -ManagementVlan $Mgmt_Vlan -AdapterPropertyOverrides $MgmtAdapterPropertyOverrides

Get-NetIntentStatus | select IntentName, Host, ConfigurationStatus, ProvisioningStatus, RetryCount, Error, LastSuccess, LastUpdated, LastConfigApplied | ft

---

Danach Storage-Intent erstellen und ebenfalls prüfen:

Add-NetIntent -Name Storage -Storage -AdapterName $storage_nics -StorageVLANs $storage_vlans -QosPolicyOverrides $QoSOverride -AdapterPropertyOverrides $StorAdapterPropertyOverrides -StorageOverrides $Storageoverride

Get-NetIntentStatus -Name Storage | select IntentName, Host, ConfigurationStatus, ProvisioningStatus, RetryCount, Error, LastSuccess, LastUpdated, LastConfigApplied | ft

---

Wenn der Storage-Traffic nicht bloß über ein VLAN, sondern mehr (bspw. 2) abgebildet werden soll, dann muss die o.g. Variable so eingetragen werden:

$storage_vlans =@(711,712)

Beim Hinzufügen des Network-Intents bekommen die Storage-Netzwerkkarten dann automatisch die VLANs zugewiesen:

---

Dummerweise habe ich doch nicht an das RDMA-Thema gedacht und die Einrichtung hat dieses Ergebnis gebracht:

---

Storage-Intent – TroubleShooting

Selbst mit den Maßnahmen (Link: Deploy a virtual Azure Local | Microsoft Learn), die für eine virtuelle Azure Local (die grundlegende Technik darunter ist die selbe) von Microsoft vorgegeben werden, klappte bei mir die korrekte Einrichtung des Storage-Intents nicht.
Ich habe daher noch weiter recherchiert und auch mittels ChatGPT nach Lösungen gesucht.

Zuerst mal mit folgendem Befehl den Cluster-Report für Netzwerk erstellen lassen:

Test-Cluster -Node HLMWS25N01,HLMWS25N02 -Include 'Network'

Das Ergebnis zeigt an:

---

Bedeutend sind dabei die Warnungs:

Network Adapter 's2d-NIC02' on Node 'HLMWS25N01.HLM.adds' has RDMA enabled on the adapter, but SMB Client is does not view this adapter as RDMA Enabled
Network Adapter 's2d-NIC02' on Node 'HLMWS25N02.HLM.adds' has RDMA enabled on the adapter, but SMB Client is does not view this adapter as RDMA Enabled
Network Adapter 's2d-NIC01' on Node 'HLMWS25N01.HLM.adds' has RDMA enabled on the adapter, but SMB Client is does not view this adapter as RDMA Enabled
Network Adapter 's2d-NIC01' on Node 'HLMWS25N02.HLM.adds' has RDMA enabled on the adapter, but SMB Client is does not view this adapter as RDMA Enabled

Was bedeutet diese Validierungsmeldung also?

Kernaussage:

„RDMA ist auf dem Adapter aktiviert, aber der SMB-Client betrachtet diesen Adapter nicht als RDMA-fähig.“

Das bedeutet konkret:

• Eigenschaft auf NIC-Ebene → RDMA = Aktiviert
• Fähigkeitsprüfung des SMB-Clients → RDMA = Nicht nutzbar

Warum das in verschachteltem Hyper-V (Nested Hyper-V) auftritt

In einer verschachtelten Virtualisierungsumgebung:

• Das vNIC stellt RDMA-fähige Flags bereit
• Der Hyper-V-Synthetic-NIC-Treiber meldet RDMA = Aktiviert
• SMB versucht, SMB Direct zu initialisieren
• SMB kann RDMA jedoch nicht binden, weil:
  • keine physische NIC vorhanden ist
  • keine Hardware-Offloads verfügbar sind
  • kein SR-IOV zur Verfügung steht
• Daher stuft SMB den Adapter korrekt als nicht RDMA-fähig ein

Zusammengefasst:

• Der Adapter sagt: „Ich unterstütze RDMA“
• SMB sagt: „Ich kann RDMA tatsächlich nicht verwenden“

• ❌ Kein Cluster-Fehler
• ❌ Kein Storage-Fehler
• ❌ Keine Fehlkonfiguration für Labor-/Test-Umgebung
• ✔️ Erwarteter Zustand in “nested” (=verschachtelt) Hyper-V

Die Cluster-Validierung erkennt und meldet diese Inkonsistenz.

Eine Lösung soll sein:

Schritt 1 – RDMA deaktivieren (pro Node)

Per PowerShell auf jedem Knoten ausführen:

Get-NetAdapter -Name s2d-* | Disable-NetAdapterRdma -Confirm:$false

Schritt 2 – Prüfen, ob RDMA deaktiviert ist

Per PowerShell auf jedem Knoten ausführen:

Get-NetAdapterRdma

Schritt 3 – SMB-Verbindungen beenden

Per PowerShell auf jedem Knoten ausführen:

Get-SmbConnection | Close-SmbConnection -Force

Alternativ den Dienst durchstarten:

Restart-Service LanmanWorkstation -Force

Schritt 4 – Storage-Intent reparieren

Auf einer Node (bswp. Node1) per PowerShell:

Repair-ClusterStorageSpacesDirect -NetworkIntent

Schritt 5 – Cluster-Validation “Netzwerk” erneut durchführen

Per PowerShell auf Node 1:

Test-Cluster -Include "Network"

Erwartetet Ergebnis: ✅ Die RDMA inconsistency Warnung soll weg sein.

---

Der Validation-Report zeigt jetzt an:

Die Checks aus dem vorherigen Test sind jetzt ok:

aber es gibt jetzt eine Warnung bzgl. QoS:

---

Verifizieren der DataCenterBridging Einstellungen

Die per Variablen gesetzten QoS-Einstellungen für die Network-Intents können auch per PowerShell geprüft werden:

Get-NetQosPolicy
Get-NetQosTrafficClass
Get-NetQosFlowControl
Get-SmbClientNetworkInterface

---

Aktivieren von Storage Spaces Direct

Das Aktivieren von Storage Spaces Direct sollte immer in einer PowerShell-Konsole durchgeführt werden, die lokal auf einem der Nodes läuft (also bitte nicht per Remote-PowerShell).

Enable-ClusterStorageSpacesDirect -PoolFriendlyName 'HCIPOOL' -Verbose

---

Danach kann mit folgenden Befehlen noch geprüft werden:

Get-ClusterStorageSpacesDirect
Get-StoragePool
Get-ClusterPerformanceHistory

---

PS – Fazit

Abgesehen von der RDMA-Problematik aufgrund der virtuellen Umgebung hat die Einrichtung mittels PowerShell deutlich besser geklappt als mit dem Windows Admin Center.

Das Cluster ist aber noch nicht fertig; es fehlen noch:

1. Volumes für die Ablage der VMs
2. Last-/Performance-Test (VMFleet)
3. Quick- & Live-Migration von VMs
4. Wartungsmodus von Nodes
5. Bei Hardware: Monitoring & Verwaltung der Nodes mittels Windows Admin Center Extension

Diese Schritte werden jetzt auch auf der virtuellen Testumgebung versucht.

Weitere Aufgaben

Wie im “PS – Fazit” beschrieben, folgen jetzt die weiteren Aufgaben.

Anlage von Volumes

Bisher gibt es aus den Daten-Festplatten nur einen großen Speicherpool. So kann der aber nicht genutzt werden, es müssen noch passende Volumes angelegt werden. Das Anlegen der Volumes kann über das WAC oder PowerShell erfolgen. Dabei sollten folgende BestPractises eingehalten werden:

Anzahl der Daten-Kopien (gegen Datenverlust)

• 2-Node Cluster:
  • Test-Umgebung: 2-WayMirror (2 Kopien der Daten)
  • Prod-Umgebung: NestedMirror (4 Kopien der Daten)
• 3-Node (oder mehr) Cluster: 3-WayMirror (3 Kopien der Daten)

Anzahl der Volumes

Pro Knoten im Cluster sollte ein Volume erstellt werden, d.h. der Speicherplatz des Speicherpools muss entsprechend kalkuliert werden.

Reservere-Kapazität

Beim Kalkulieren der Volume-Größen, sollte bedacht werden, dass genug Speicherplatz für eine “in-place”-Reparatur möglich ist, sollte mal eine der unter dem Storage liegenden Festplatte ausfallen. Diese Reservekapazität sollte also die Größe einer der Storage-Festplatten haben – maximal Wert ist hierbei die Größe von 4 Storage-Festplatten. Optimal wäre eine Festplatte je Server pro Cluster.

Im Test-Szenario für diesen Artikel hat es 2x 4 Festplatten je 20GB:

2 x (4 x 20 GB) = 160 GB

Mit den o.g. BestPractices sollten also 2 x 20 GB = 40 GB als Reserve vorgehalten werden.

Hierzu kann gerne auch der s2d-Calculator zu Hilfe genommen werden:

---

Hinweis:
Ich musste hier mit 20 TB anstelle 20 GB die Beispiel-Kalkulation machen, da nur TB-Größen angenommen werden. und 20 GB Demo-Festplatte wären dann 0,02 TB, was mit den ganzen Abzügen bei einem Nested Mirror verwendbare 0,00 TB angezeigt hätte 😏

via WAC

Sofern nicht bereits geschehen, das Cluster und die Nodes aufnehmen, danach auf das Cluster verbinden.

Dann im linken Menü auf “Volumes” und dann rechts den “Inventory”-Reiter auswählen. Es sollte schon das zuvor angelegte “ClusterPerformanceHistory”-Volume vorhanden sein.

---

Das zweite Volume kann dann auf den zweiten Knoten geschoben werden – verschoben wird dabei aber nur der Besitzer des Volumes.

---

Test-Plattform

Für diese Testumgebung wurde ein Surface Laptop Studio 2 mit folgender Ausstattung verwendet:

• CPU: 13th Intel Core i7-13800H – 14 Cores @ 2.90 Ghz
• RAM: 64 GB (5200 MT/s) – 8x 8 GB
• Disk: 2 TB NVMe