Mit Windows Server 2012 hat Microsoft Storage Spaces eingeführt. Dabei handelt es sich um virtuellen Speicherplatz, der sich auf mehrere physische Datenträger erstrecken kann. Der Platz basiert auf Speicherpools (Storage Pools), die wiederum auf die einzelnen physischen Datenträger eines Servers aufbauen.
Der Vorteil dabei ist, dass Administratoren sehr einfach den Speicherplatz erhöhen können, indem sie weitere physische Datenträger in das System integrieren. Bei diesem Vorgang müssen weder neue Freigaben erstellt noch Daten kopiert werden, alles läuft im Hintergrund ab, ist skalierbar, ausfallsicher und leistungsstark.
Mit Windows Server 2016 werden diese Möglichkeiten noch erweitert und auf weitere Server verteilt. Die neue Server-Version erlaubt das Ausdehnen von Storage Spaces auf physischer Festplatten mehrerer Server in einem Cluster.
Storage Spaces mit Windows Server 2012 und Windows Server 2012 R2 – SSD einbinden
Mit Windows Server 2012 R2 hat Microsoft Storage Spaces erweitert und bietet die Möglichkeit in dieser Technologie schnelle SSD mit herkömmlichen Festplatten zu vermischen. Die Technik wird weiterhin in Windows Server 2016 unterstützt, zusammen mit der neuen Technik „Storage Spaces Direct“.
Windows erkennt Dateien, die häufig in Verwendung sind und speichert diese automatisch im SSD-Bereich des Storage Space. Weniger verwendete Dateien werden auf die langsamen Festplatten ausgelagert. Natürlich können Administratoren auch manuell steuern, welche Art von Dateien auf schnellen Datenträgern zur Verfügung stehen sollen und welche auf langsame Festplatten ausgelagert werden können. Diese Technik wird Storage Tiers genannt.
Neben der einfachen Verwaltung und der besseren Leistung bieten Storage Spaces aber auch mehr Ausfallsicherheit. Denn Administratoren können für die verschiedenen Storage Spaces unterschiedliche Redundanz- und Leistungsoptionen konfigurieren. Zusätzlich lassen sich Hot-Spare- und Hot-Plug-Szenarien mit der Technologie einfacher umsetzen als bei herkömmlichen Systemen. Storage Spaces können auch mit Hardware-Raid-Systemen und SANs kombiniert werden, auch bezüglich der Redundanz des einzelnen Storage Space.
Storage Spaces mit Windows Server 2016 noch weiter ausbauen
Mit Windows Server 2016 geht Microsoft also noch einen Schritt weiter. Die einzelnen Datenträger eines Storage Space müssen sich nicht mehr auf dem lokalen Server befinden, sondern können auch an verschiedenen Servern angeschlossen werden. Diese Funktion erlaubt Software-Defined-Storage-Funktionen, die bisher in dieser Form mit Windows-Servern nicht möglich waren. Diese Technik wird offiziell als Storage Space Direct bezeichnet.
Auf Basis eines Storage Space erstellen Administratoren mit der Datenträgerverwaltung in Windows Server 2016 herkömmliche Volumes. Diese verhalten sich auf den Servern wie lokale Laufwerke, bauen aber auf den Storage Space auf. Der Storage Space wiederum verwendet physische Datenträger, die auf verschiedenen Servern verteilt sein können, zum Beispiel auf den verschiedenen Knoten eines Clusters.
Microsoft integriert in Windows Server 2016 darüber hinaus noch die Möglichkeit komplette Festplatten, auch innerhalb eines Storage Pools, auf andere Server zu replizieren. Diese Replikation erfolgt synchron und blockbasiert. Unternehmen erhalten auf diesem Weg die Möglichkeit Geo-Cluster aufzubauen. Bei diesen Clustern sind Clusterknoten über die ganze Welt verteilt. Damit ein einheitlicher Datenbestand vorliegt, müssen die Daten des Clusters repliziert werden. Dazu ist Windows Server 2016 als erste Serverversion von Microsoft in der Lage.
Ab Windows Server 2016 ist es nicht mehr notwendig, dass die einzelnen Knoten eines Windows-Clusters physisch mit dem Datenträger verbunden sind. Daher lassen sich jetzt auch verschiedene Systeme und Festplatten-Standards miteinander vermischen.
Ein weiterer Vorteil von Storage Space Direct ist die Unterstützung von Nano-Servern mit Windows Server 2016. Administratoren können auf diesem Weg Cluster auf Basis von Nano-Servern aufbauen und sehr kleine aber effiziente Hyper-V-Cluster erstellen. Sobald der Cluster aufgebaut ist, lässt sich die Funktion mit Enable-ClusterStorageSpacesDirect in der PowerShell aktivieren.
Um Storage Spaces Direct in produktiven Umgebungen zu verwenden, benötigen Unternehmen spezielle Hardware, vor allem kompatible Netzwerkkarten, die RDMA beherrschen. In Testumgebungen lassen sich aber auch virtuelle Server, virtuelle Festplatten und virtuelle Netzwerkkarten ohne besondere Hardware nutzen.
Hyper-V in direkter Konkurrenz zu VMware Virtual SAN
Mit Storage Spaces Direct tritt Microsoft in Konkurrenz mit VMware Virtual SAN. Auch hier können Laufwerke auf mehrere Server verteilt sein. Im Fokus dieser Technologie stehen vor allem Virtualisierungsumgebungen. Der gemeinsame Speicher eines Clusters für Hyper-V kann jetzt also auf verschiedene Standorte repliziert werden und so mehr Standorte und Niederlassungen abdecken.
Außerdem stellen die Speicherorte der virtuellen Festplatten der VMs eines Hyper-V-Clusters keinen Single-Point-of-Failure mehr dar, wenn sie auf einem Storage Space Direct positioniert sind, dessen Festplatten sich auch noch auf verschiedene Server replizieren. Auf dieser Basis lassen sich VMs nicht nur speichern, sondern Unternehmen können auch Hyper-V-Replikation zusammen mit Storage Spaces Direct und Volume Replication nutzen. Als Dateisystem sollte NTFS oder besser das ReFS-Dateisystem eingesetzt werden. Dieses ist stabiler und bereits für Storage Spaces vorbereitet.
In einer solchen Struktur lassen sich gemeinsame Datenträger realisieren, ohne dass es einen gemeinsamen Datenspeicher gibt im Cluster gibt, an dem alle Server angeschlossen sind. Jeder Server hat seine eigenen lokalen Festplatten, die wiederum in einen Storage Space Direct angebunden werden und im Cluster zur Verfügung stehen. Die Daten werden zwischen den Servern repliziert. Dazu ist allerdings nur Windows Server 2016 in der Lage. Der Datenaustausch findet nicht über Netzwerkprotokolle statt, sondern mit SMB 3.
In diesem Bereich unterstützt Windows Server 2016 auch eine verbesserte Version von RDMA. Bei dieser Technologie kann der Arbeitsspeicher von Windows-Servern über das Netzwerk repliziert werden. Das funktioniert aber nur mit kompatiblen Netzwerkkarten. Der Datenverkehr findet parallel mit mehreren SMB-Verbindungen statt. Natürlich sollte das Netzwerk an dieser Stelle entsprechend performant sein.
Storage Spaces Direct mit Windows Server 2016 testen und vorbereiten
Um Storage Spaces Direct mit Windows Server 2016 zu testen, benötigen Administratoren eine Active Directory-Domäne, idealerweise in einer Testumgebung. Der einfachste Weg für den Test besteht darin, dass ein Hyper-V-Host auf Basis von Windows Server 2016 installiert wird. Auf diesem Host werden vier VMs erstellt, die wiederum einen Cluster mit Storage Spaces Direct bieten. Hier sollten Generation 2-VMs auf Basis eines Hyper-V-Hosts mit Windows Server 2016 verwendet werden. Voraussetzung ist der Betrieb von Windows Server 2016 in den VMs, auf dem Host kann generell auch Windows Server 2012 R2 installiert werden. Microsoft plant in Zukunft auch die Unterstützung von Szenarien mit weniger Knoten, aktuell werden aber mindestens vier Knoten benötigt.
Auf den vier VMs installieren Administratoren Windows Server 2016. Außerdem muss jeder VM der Zugriff auf die virtuelle Switch des Hyper-V-Hosts gegeben werden, damit die VMs untereinander und mit dem Netzwerk kommunizieren können. Zusätzlich müssen jeder VM neben der Systemfestplatte mindestens zwei weitere virtuelle Festplatten zugewiesen werden. Die Festplatten werden als VHDX-Datei dem virtuellen SCSI-Controller zugewiesen. Verwenden Administratoren eine Generation 2-VM, integriert Hyper-V automatisch einen virtuellen SCSI-Controller mit einer Festplatte für das Betriebssystem. Die beiden zusätzlichen Festplatten werden als Datenträger für Storage Space Direct verwendet.
Zusätzlich erstellen Administratoren auf dem Hyper-V-Host einen weiteren virtuellen Switch mit dem Status „Internal“. Auch dieser Switch wird jedem virtuellen Server zugewiesen. Diese Switches dienen der Kommunikation der VMs untereinander und mit dem Hyper-V-Host.
Die einfachste Konfiguration um Storage Space Direct zu betreiben, ist also ein Hyper-V-Host mit vier virtuellen Servern und jeweils zwei virtuellen Festplatten. Natürlich lassen sich auch mehr virtuelle Festplatten verwenden, zwei sind Mindestvoraussetzung für den Betrieb.
Notwendige Rollen und Features für Storage Spaces Direct installieren
Auf allen Servern, die Mitglied des Clusters für Storage Spaces Direct werden sollen, müssen Administratoren die Serverrolle Dateiserver und die Clusterfeatures installieren. Am einfachsten geht das in der PowerShell mit dem Befehl:
Install-WindowsFeature -Name File-Services, Failover-Clustering -IncludeManagementTools
Außerdem müssen in der Datenträgerverwaltung die Festplatten für Storage Spaces Direct als online und initialisiert angezeigt werden. Partitionen dürfen nicht erstellt werden. Nach der Installation der Rolle und des Clusterfeatures sowie der Initialisierung der Festplatten können die Server neu gestartet werden – das müssen sie aber nicht. Wenn ein Neustart notwendig ist, erscheint in der PowerShell die entsprechende Meldung.
Cluster für Storage Spaces Direct vorbereiten und installieren
Im nächsten Schritt werden die Clusterknoten in der PowerShell auf Clustertauglichkeit und Unterstützung für Storage Spaces Direct unterstützt. Der Befehl dazu lautet:
Test-Cluster -Node <Knoten1,Knoten2,Knoten3,Knoten4> -Include “Storage Spaces Direct”,Inventory,Network,”System Configuration”
Hier tragen Administratoren die Namen der vier Knoten ein. Die Überprüfung muss auf einem einzelnen Knoten gestartet werden, der die Konfiguration und Unterstützung für Storage Spaces Direct auf allen anderen Knoten über das Netzwerk testet.
Zuerst sollte die Namensauflösung mit nslookup geprüft werden, damit sichergestellt ist, dass der Test auch alle Clusterknoten erreichen kann. In Testumgebungen spielen Warnungen keine Rolle, da diese die Installation des Clusters nicht verhindern. Nur Fehler dürfen keine erscheinen. In produktiven Umgebungen sollte den Warnungen natürlich nachgegangen werden, damit die Leistung des Clusters nicht beeinträchtigt wird.
Wenn der Test für alle vier Knoten erfolgreich absolviert wurde, wird im Anschluss der Cluster erstellt. Auch hier wird am besten die PowerShell verwendet:
New-Cluster -Name <ClusterName> -Node <Knoten1,Knoten2,Knoten3,Knoten4> -NoStorage
In Test- sowie in vielen produktiven Umgebungen wird mit DHCP für die Zuweisung des Clusters gearbeitet. Soll eine statische IP-Adresse verwendet werden, lautet der Befehl:
New-Cluster -Name <ClusterName> -Node <Knoten1,Knoten2,Knoten3,Knoten4> -NoStorage -StaticAddress <X.X.X.X>
Cluster nach der Erstellung überprüfen und Storage Spaces Direct aktivieren
Nachdem der Cluster erstellt wurde, zeigt die PowerShell den Namen des Cluster an. In der Testumgebung können Warnmeldungen ignoriert werden. In der Praxis sollten Administratoren die Protokolldatei überprüfen.
Im nächsten Schritt werden mit Get-ClusterNetwork die Netzwerke des Clusters angezeigt. Die PowerShell muss Netzwerke für die Verbindung der Clusterknoten (Cluster) und für die Verbindung ins Internet anzeigen. Storage Space Direct wird schliesslich mit dem CMDlet Enable-ClusterStorageSpacesDirect aktiviert. Der Befehl sollte keine Fehler anzeigen.
Über den Failover Cluster Manager lässt sich der Cluster bereits verwalten. Hier sollten alle Knoten angezeigt werden und funktional sein.
Geben Administratoren auf einem Clusterknoten in der PowerShell den Befehl Get-Physicaldisk ein, werden alle Festplatten aller Clusterknoten angezeigt sowie die Information, dass diese poolfähig sind. Die Festplatten dürfen dazu über keine eigenen Partitionen verfügen.
Storage Pools und Storage Spaces erstellen
Der Cluster innerhalb eines Clusters mit Storage Spaces Direct hat zunächst keinen gemeinsamen Datenspeicher. Sobald der Cluster erstellt, und Storage Spaces Direct aktiviert ist, wird der notwendige Storage Pool erstellt, und danach die Storage Spaces.
In physischen Umgebungen lassen sich hier auch Storage Tiers erstellen. Dabei handelt es sich um die erwähnte Vermischung von SSD-Festplatten und HDD-Festplatten. In Testumgebungen ist das aber nicht notwendig. Hier reicht die Erstellung eines einzelnen Storage Pools aus. Administratoren haben die Möglichkeit einen Storage Pool in der PowerShell zu erstellen oder im Failover Cluster Manager über den Bereich Storage\Pools.
In der PowerShell lautet die Syntax:
New-StoragePool -StorageSubSystemName <FQDN des Subsystems> -FriendlyName <StoragePoolName> -WriteCacheSizeDefault 0 -FaultDomainAwarenessDefault StorageScaleUnit -ProvisioningTypeDefault Fixed -ResiliencySettingNameDefault Mirror -PhysicalDisk (Get-StorageSubSystem -Name <FQDN des Subsystems> | Get-PhysicalDisk)
Sobald der Storage Pool im Cluster angezeigt wird, können Administratoren über das Kontextmenü der Pools im Failover Cluster Manager neue virtuelle Festplatten, auch Storage Spaces genannt, erstellen. Im Assistenten lässt sich auch die Verfügbarkeit und das Storage Layout des neuen Storage Space festlegen. Dieser baut auf den erstellten Storage Pool auf.
Scale-Out-File-Server erstellen
Über den Assistenten zum Erstellen neuer Clusterrollen können Administratoren einen neuen Scale-Out-File-Server im Cluster erstellen. Sobald dieser zur Verfügung steht, und auch Zugriffspunkte festgelegt wurden, lassen sich Freigaben auf dem Server zur Verfügung stellen.
Virtueller Cluster: Shared VHDX versus Storage Spaces Direct
Arbeiten Unternehmen in virtuellen Clustern mit Storage Spaces Direct statt mit den Shared VHDX, die bereits in Windows Server 2012 R2 zur Verfügung standen, stellt sich die Frage der Vorteile für den Einsatz. Shared-VHDX-Festplatten eignen sich auch in Windows Server 2016 hervorragend als gemeinsamen Datenspeicher für einen Cluster.
Auf diese virtuellen Festplatten dürfen mehrere Clusterknoten gleichzeitig zugreifen. Fällt ein Knoten aus, können andere Knoten den Besitz übernehmen. Alle Clusterrollen, die Daten auf der Shared-VHDX speichern, können weiter auf die Daten zugreifen. Storage Space Direct-Szenarien erlauben Clusterrollen den Zugriff auf alle Festplatten aller Knoten.
Dabei werden die Daten in einem sicheren Storage Pool gespeichert und auf alle Knoten repliziert. Welche Variante einsetzen, müssen Administratoren gut planen. Sind auf den Knoten mehrere Festplatten verfügbar, sind Storage Spaces Direct den Shared-VHDX-Festplatten überlegen.
Weitere Artikel zum Thema Windows Server 2016:
- Windows Server 2016: Docker mit Windows
- Software Defined Storage: Storage Spaces Direct in Windows Server 2016
- Nano Server mit Windows Server 2016 – Grundlagen, Installation, Einrichtung
- Jetzt evaluieren: Windows Server 2016 und System Center 2016 TP5
- Windows Server Container in Microsoft Azure in betreiben
- Windows Server Container: Verwaltung mit PowerShell und Skripten
- Windows Server 2016 – Die Neuerungen in der Praxis
- Windows Server 2016 – Die Neuerungen im Überblick
- Docker und Windows Server 2016 – Das müssen Profis wissen
- Windows Server Container-Host installieren und einrichten
- Windows Server 2016: Docker mit Windows
Neueste Kommentare
3 Kommentare zu Software Defined Storage: Storage Spaces Direct in Windows Server 2016
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Hallo ein sehr informativer Artikel, den ich nachgestellthabe. Bei mir hat alles geklappt bishin zum Storagespacesdirekt und konnte auch eine Clusterfreigabe veröffentlichen. Leider bekomme ich jetzt aber keinen Quorumzeugen zustande. Vileicht könnten Sie mir da behilflich sein.
Vielen Dank im Voraus.
Ich habe diese Anleitung 1:1 befolgt, aber wenn ich StorageSpacesDirect aktivieren möchte, bekomme ich die Meldung enable-clusterstoragespacesdirect : feature s2d is not supported on node xxxx
Was mache ich falsch? :(
Das ist ein komplexes Thema und lässt sich so einfach nicht beantworten. Allerdings scheint die Meldung darauf hinzudeuten, dass der Knoten nicht die notwendige Konfiguration aufweist.
Vielleicht hilft das:
https://goo.gl/3cAZ6p
https://goo.gl/XE3ut5