Powershell verwaltet die Storage Spaces bei Windows 2012, Teil 2
11. Juni 2012
Auf den ersten Blick könnte man die Storage Spaces des Windows Server 2012 als ein "SAN für arme Leute" halten. Doch die bei den Storage Spaces enthaltenen Funktionen gehen weit über diese Einschätzung hinaus. Zusammen mit der Version 2.2 des Protokolls Server Message Block (SMB) und mit der native iSCSI-Unterstützung bekommen die Anwender der neuen Server-Plattform in den Genuss von vielen Funktionen, die zuvor nur bei den teuren NAS- und SAN-Geräten geboten sind. Daher werden die Dateidienste bei Windows künftig auf der Basis von günstigen JBOD-Speicher (Just A Bunch Of Disks) zu einem „Speicher Erster Klasse“. Und die Verwaltung der Funktionen lässt sich über die Powershell auch elegant automatisieren.
Mit Windows Server 2012 halten die Storage Spaces Einzug in das Speichersubsystem. Damit wird eine Speichervirtualisierung im Rahmen des Betriebssystems geboten – und damit sollen teure Investitionen in SAN- oder NAS-Geräte nicht mehr unbedingt nötig sein.
Dazu hat Microsoft den Servermanager als grafisches Interface aufgepeppt, über den sich auch ein Thin Provisioning von Speicherkapazität erreichen lässt. Das Arbeiten mit den Storage Spaces und dem Server-Manager hat bereits der erste Teil dieses Beitrags verdeutlicht. Wie die Verwaltung der Storage Spaces mit Hilfe der Powershell funktioniert, zeigt dieser zweite Teil.
Das Anlegen eines neuen Storage Pools, der dazu drei Festplatten heranzieht, schaut in der Powershell wie folgt aus:
$phyDisks = Get-PhysicalDisk
$storSub = Get-StorageSubSystem
New-StoragePool -FriendlyName "Stuff" -PhysicalDisks $phyDisks[0] , –
$phyDisks[1], $phyDisks[2] -StorageSubSystemFriendlyName $storSub.FriendlyName
Um dann virtuelle Datenträger im Pool anzulegen, eignen sich die folgenden Befehle:
New-VirtualDisk -StoragePoolFriendlyName "Stuff" -ResiliencySettingName Mirror -Size 10TB -Provisioningtype Thin -FriendlyName "Data1"
New-VirtualDisk -StoragePoolFriendlyName "Stuff" -ResiliencySettingName Parity -Size 10TB -Provisioningtype Thin -FriendlyName "Data2"
Die Ausgabe der Ergebnisse übernimmt das Cmdlet Get-VirtualDisk. Damit lassen sich viele Informationen über einen virtuellen Datenträger (Virtual Disk) anzeigen. Zum Beispiel könnte man mit dem folgenden Befehl Informationen über die Anzahl der Datenkopien für eine gespiegelte Konfiguration (sprich beim Speicherlayout Mirror) sowie seinen Betriebszustand abfragen:
PS C:\ > Get-VirtualDisk -FriendlyName Data1 | fl
Die folgende Liste gibt ein Beispiel für die zugehörige Ausgabe:
NumberOfAvailableCopies : 0
NumberOfColumns : 1
NumberOfDataCopies : 2
OperationalStatus : OK
Server Message Block – nun die optimierte Version
Damit Microsoft die Storage Spaces effizient aufbauen konnte, waren Optimierungen am Protokoll Server Message Block (SMB) nötig. Dieses Protokoll kommt auf allen Microsoft-Plattformen schon seit langem zum Einsatz – und wurde auch schon für andere Betriebssystemplattformen adaptiert (wie etwa bei Samba auf Unix/Linux).
Mit dem Windows Server 2012 kommt nun die Version 2.2 von SMB zum Einsatz. Sie löst damit die bisherige Version 2.1 ab. Auch wenn das nur eine marginale Änderung in Bezug auf die Versionsnummer darstellt, so kommen dabei doch eine Vielzahl von zusätzlichen Funktionalitäten und auch Performance-Verbesserungen beim SMB zum Tragen.
Der generelle Datendurchsatz bei SMB wurde massiv verbessert: Der Zugriff auf die Daten über das SMB 2.2 ist nahezu genauso schnell wie ein direkter Zugriff auf den Speicher. Dazu wurden einige Änderungen beim SMB eingeführt, wie etwa die Funktionalität des „SMB Multi-Channel“.
Damit ist an in der Lage, mehrere TCP-Verbindungen über verschiedenen Netzwerkkarten für eine einzige SMB-Session aufzubauen. Diese Änderung führt dazu, dass man eine Art der Bandbreiten-Aggregation hin bekommt. Denn mehrere Netzwerkkarten und CPUs können dann für die Arbeit herangezogen werden, die im Bereich der Datenübertragung über das Netzwerk anfällt, wenn das „Receive-Side Scaling“ (RSS) zum Einsatz kommt und mehrere Netzwerkkarten benutzt werden. Das funktioniert auch für das native „NIC Teaming“, über das der Windows Server 2012 verfügt.
Aber auch das Thema Hochverfügbarkeit für Freigaben im Zusammenspiel mit dem Failover Clustering wurde deutlich verbessert. Es gibt nun einen neuen Modus, Active-Active benannt, mit dem ein Cluster Shared Volume (CSV) aus Freigaben aufgebaut werden kann, das für alle Knoten eines Clusters erreichbar ist.
Mehrere Hosts im Cluster können dabei gleichzeitig das CSV für wichtige Arbeitslasten – wie etwa virtuelle Maschinen eines Hyper-V auf einer Freigabe oder sogar für die Datenbanken des SQL Servers nutzen. Mit diesen „Active-Active Freigaben“ wird garantiert, dass keine Ausfallzeiten auftreten und dass es keinen Verlust der Verbindungen im Falle eines Failovers gibt.
Eine weitere Verbesserung beim Windows Server 2012 betrifft den Bereich iSCSI. Als Bestandteil der File Services unter den File and Storage Services gibt es einen iSCSI-Rollendienst. Wenn der installiert ist, kann der Windows Server 2012 als ein iSCSI-Target fungieren. Damit kann er auf den Speicher sowohl von der Dateiebene aus (mit SMB) oder auf der Blockebene (mit iSCSI) zugreifen. Die iSCSI Targets auf einem Server sind üblicherweise virtuelle Festplatten (VHDs, Virtual Hard Disks). Dabei ist eine vollständige Konfiguration des Zugriffs und der Authentifizierungsdienste möglich.
Chkdsk und sein zusätzlicher Nutzen
Wer die Dateidienste eines Windows Servers verwendet, der steht heutzutage vor einer Herausforderung – vor allem, wenn er NTFS einsetzt. NTFS besitzt üblicherweise sehr große Volumes mit sehr vielen Dateien. Wenn etwas im Dateisystem schief läuft, muss der Administrator das Tool Chkdsk einsetzen und damit die nötigen Reparaturen ausführen.
Nun erledigt Chkdsk seine Aufgaben recht gut – aber es sind in der Regel sehr umfangreiche und arbeitsintensive Aufgaben. Das Tool muss durch den kompletten Inhalt auf der Festplatte gehen und nach Problemen suchen. Dann sind die nötigen Reparaturen auszuführen. Das alles dauert eine sehr lange Zeit – auch wegen der Charakteristika der Festplatten und ihren vergleichsweise langsamen Zugriffszeiten.
Dabei kann es bei großen Volumes und vielen Dateien dazu kommen, dass es sogar mehrere Tage dauert, ehe Chkdsk die Probleme behoben hat. Und für die Zeitspanne der Reparaturarbeiten nimmt Chkdsk das betreffende Volume auch offline. Das führt dazu, dass viele Unternehmen dazu übergegangen sind, die NTFS-Volumens nicht zu großwerden zu lassen – nur so lässt sich sicherstellen, dass Chkdsk in einer einigermaßen verträglichen Zeit mit der Reparatur des Volumes fertig wird und dass man nicht mit zu lagen Offline-Zeiten umgehen muss.
Ein Ansatz zur Problemlösung wird das Resilient File System (ReFS) sein, das in den folgenden Versionen von Windows immer stärker zum Einsatz kommen wird. Dabei wird der Ansatz verfolgt, generell weniger „zerschossene Informationen“ zuzulassen. Aber auch das NTFS wird noch zuverlässiger und verfügt über einen gewissen Selbstheilungsmechanismus. Doch der Einsatz von Chkdsk bei NTFS wird nicht komplett auszuschließen sein.
Chkdsk arbeitet sehr langsam. Der Grund liegt in den großen Speichergeräten und der dadurch zeitaufwendigen Analysephase. So muss Chkdsk die komplette Festplatte mit allen Inhalten analysieren, um die Fehler zu erkennen. Sind Probleme gefunden – das wird nur bei einer verschwindend geringen Anzahl der aktuellen Dateien sein – so behebt Chkdsk diese Fehler . Diese Aktion ist dagegen recht schnell – sie liegen üblicherweise im Sekundenbereich.
Doch der generelle Nachteil ergibt sich aus dem Grundprinzip von Chkdsk. Es nimmt das betreffende Volume offline – und zwar für das Durchsuchen (sprich das Überprüfen des „Gesundheitszustandes“) und das Fehlerbeheben.
Beim Windows Server 2012 werden die Aufgaben von Chkdsk in zwei Phasen unterteilt. Der erste Teil kümmert sich um das Scannen der Festplatte und der Dateninhalte – hier wird nach Fehlern gesucht. Wird ein Problem erkannt, bekommt es eine Markierung und damit wird angezeigt, dass hier später eine Fehlerbehebung stattzufinden hat. Doch dabei bleibt das Volume noch online. Es muss auch nicht offline genommen werden, weil noch keine Reparaturaktionen ausgeführt werden.
Sind dann alle Inhalte analysiert und gilt es dann die Probleme zu beheben, wird Chkdsk erneut gestartet – und zwar im „Spotfix Mode“. Dabei wird das Volume, an dem die Fehlerbehebung ausgeführt wird, dann offline genommen – doch das nur für wenige Sekunden und nicht mehr für ganze Tage. Über Parameter lässt sich bei Chkdsk angeben, ob nur der Scan-Prozess ablaufen soll.
Die neuen Befehle sehen wie folgt aus:
Chkdsk /scan J:
Bei diesem Scan-Vorgang von Chkdsk bleibt das Volume online, sprich es treten keine Ausfallzeiten dadurch mehr auf. Der zweite Teil dagegen wird das Volume offline nehmen – oder beim nächsten Neustart ausgeführt:
Chkdsk /spotfix J:
Diese Aktionen lassen sich auch über die Powershell anstoßen – wie im Folgenden gezeigt:
Repair-Volume -Scan D
Repair-Volume -SpotFix D
Werden CSVs genutzt, reduziert sich die Ausfallzeit beim Lauf der Spotfix-Aktion auf Null. Denn mit einem CSV kommt eine weitere Ebene an Abstraktion zwischen Festplatte und Datenzugriff ins Spiel. Zudem können bei einem CSV die Ein-Ausgabeoperationen für etwa 20 Sekunden pausieren.
Das bedeutet, dass beim Lauf der Spotfix-Aktion das CSV die Ein-Ausgabevorgänge auf das Volume pausieren lässt und in der Zwischenzeit das Volume offline nimmt und die Fehlerbehebung ausführt. Die Anwender werden dies beim Zugriff auf ein CSV nur aufgrund einer kurzen Zugriffsverzögerung mitbekommen. Ein Verlust der logischen Verbindung zu den Dateien wird dabei nicht auftreten.
