Storage Spaces Direct (die gängige Abkürzung lautet S2D) ist eine Ausweitung des seit Windows Server 2012 angebotenen Storage-Spaces-Konzepts auf ganze Server-Cluster. Storage Spaces ermöglicht es, lokal in einem Computer verbaute Festplatten zu einem Speicherpool zusammenzufassen. Ein solcher bietet durch Blockspiegelung und Parität einen Schutz gegen den Ausfall einzelner Platten. Außerdem können vorhandene SSD- oder NVMe-Datenträger eingesetzt werden, um Zugriffe auf den Poolspeicher mittels Caching zu beschleunigen.

Mit S2D sind die auf lokalen Festplatten der Server gespeicherten Daten nicht nur gegen den Ausfall eines einzelnen Datenträgers, sondern auch gegen den Verlust eines ganzen Cluster-Knotens geschützt. S2D bildete von Anfang an die Storage-Grundlage für Azure Stack HCI, weshalb sich die gesamte Dokumentation dazu unter "Azure Stack HCI" finden lässt [1]. Doch auch mit dem üblichen Windows Server 2022 können Sie den vollen Leistungsumfang von S2D ausschöpfen. Hier gehört S2D allerdings zu den Datacenter Features – das heißt, in einem Cluster, der S2D aktiviert hat, muss jeder Knoten mit Windows Server Datacenter lizenziert sein.

Für Storage Spaces Direct hat Microsoft zwei Einsatzszenarien vorgesehen: Eine konvergente Bereitstellung präsentiert die mittels S2D gebildeten Cluster-Datenträger über Scale-Out Fileserver (SOFS) als SMB3-Applikationsfreigaben. In diesen können Hyper-V-Hosts die Daten ihrer VMs ablegen. Für Microsoft SQL Server ist die Speicherung von Datenbankdateien in SOFS-Freigaben ebenfalls unterstützt. Die Hyper-V-Hosts oder SQL-Server selbst brauchen daher keine eigenen Datenträger zum Speichern von Nutzdaten. Bei dieser Bereitstellungsart lässt sich die Compute-Leistung unabhängig von der Storage-Leistung skalieren, je nachdem, welche Ressource zuerst ausgebaut werden muss.

Bei einer hyperkonvergenten Bereitstellung wird der gesamte von einem Cluster gebildete S2D-Speicher innerhalb dieses Clusters konsumiert. Die Cluster Shared Volumes werden nicht freigegeben, sondern dienen lediglich dem Speichern der Hyper-V-VMs. Idealerweise ist die Hardware- und Festplattenausstattung aller Cluster-Knoten dabei identisch, sodass die Skalierung von Compute und Storage linear durch Hinzufügen neuer Knoten zum Cluster erfolgt.

Azure Stack HCI unterstützt ausschließlich die hyperkonvergente Bereitstellung, wie das "HC" im Namen schon vermuten lässt. Unabhängig von der Art der S2D-Bereitstellung sind dem Wachstum gewisse Grenzen gesetzt. Ein S2D-Cluster kann mindestens zwei und maximal 16 Knoten umfassen. Dies ist der Hauptgrund für konvergente Bereitstellungen, denn ein Hyper-V-Cluster ohne S2D lässt sich auf bis zu 64 Knoten ausbauen. Außerdem können mehrere Hyper-V-Cluster auf SOFS-Freigaben zugreifen. Der gesamte Speicher eines S2D-Pools kann maximal 4 PByte betragen. Bei Azure Stack HCI liegt diese Grenze bei 16 PByte, ist also derzeit rechnerisch nicht erreichbar. Pro Knoten werden höchstens 400 TByte an lokalen Festplatten für S2D berücksichtigt.

Die beiden Speichergrenzwerte bestehen unverändert seit Windows Server 2019; unter Windows Server 2016 betrugen sie jeweils ein Viertel des jetzigen Werts. Im Maximalausbau eines S2D-Clusters steuert jeder Knoten also 250 TByte an Festplattenspeicher zum Pool bei. Gehen wir von heute verfügbaren 16-TByte-Laufwerken aus, müssen pro Knoten 16 dieser Platten verbaut werden, was das Fassungsvermögen eines üblichen 2HE-Rackservers leicht übersteigen dürfte. Außerdem verfälscht eine solch vereinfachte Rechnung die Realität des Software-defined-Storage-Konzepts.

Arbeiten Sie mit robusten und hochperformanten Mixed-Use-SSDs in Ihren Servern, ist es durchaus möglich, einen S2D-Pool aus identischen Datenträgern zu erzeugen. Anders als bei einigen Konkurrenzprodukten ist bei S2D ein Cache-Tier nämlich nicht zwingend vorgeschrieben. Weisen alle verbauten Datenträger zudem ein ähnliches Performanceverhalten auf, bringt ein Caching keinen nennenswerten Performancegewinn.

Anders sieht es aus, wenn Sie für den Capacity-Tier preiswerte und verhältnismäßig große magnetische Festplatten (HDD) einsetzen. Hier reicht das reine Verteilen der I/O-Operationen auf mehrere Datenträger nicht aus, um eine Performance zu erreichen, die Sie heutzutage von einer Enterprise-Virtualisierungsplattform erwarten. Eine Beschleunigung durch Solid-State-Laufwerke ist also unumgänglich. Microsoft unterstützt für S2D vier Klassen von Datenträgern:

1. Drehende magnetische Festplatten (HDD)

2. Solid State Drives (SSD)

3. Non-Volatile Memory Express-Laufwerke (NVMe)

4. Persistent Memory (pMem).

Bei Ihrer Planung können Sie davon ausgehen, dass die Datenträgertechnologie umso schneller arbeitet, je weiter unten sie auf dieser Liste steht. pMem spielt dabei eine besondere Rolle, denn diese Speichertechnologie unterscheidet sich von allen anderen in der Art der Bereitstellung (RAM-Disk anstatt "echte" Disk) [2]. Der bekannteste Vertreter der pMem-Technologie ist Intel Optane. pMem-Bereitstellungen sind im Bereich der Standardserver derzeit noch selten anzutreffen, daher ist es vor allem wichtig, dass Sie sich mit den unterstützten Konstellationen aus HDD, SSD und NVMe vertraut machen. Diese sind wie folgt:

- Haben Sie nur Flash-Technik (SSD oder NVMe) im Einsatz, bildet S2D einen Capacity-Tier aus allen unterstützten Laufwerken.

- Verwenden Sie eine Mischung aus SSD und NVMe, wird SSD für Capacity und NVMe für Cache eingeteilt. Letzterer ist ein reiner Schreibcache, Lesezugriffe werden innerhalb einer All-Flash-Bereitstellung standardmäßig nicht zwischengespeichert.

- Nutzen Sie einen Mix aus HDD und SSD oder HDD und NVMe, wird HDD für Capacity und Flash für Cache verwendet; dabei werden sowohl Schreib- als auch Lesezugriffe gepuffert.

- Die komplexeste aller Hybrid-Konfigurationen beinhaltet alle drei Laufwerkstypen: HDD, SSD und NVMe. In diesem Fall übernimmt NVMe die Cache-Funktion und die beiden anderen Technologien bilden einen Hot-/Cold-Capacity-Tier, wie er aus den herkömmlichen Storage Spaces bekannt ist: Blöcke, auf die häufig zugegriffen wird, wandern mit der Zeit von HDD auf SSD, während Blöcke mit geringer Zugriffsfrequenz aus dem SSD-Tier auf HDD ausgelagert werden.

Ein Sonderfall ist die seit einiger Zeit in Azure Stack HCI unterstützte Ein-Server-Konfiguration. Hier müssen alle Laufwerke dieselbe Speichertechnologie aufweisen und Cache ist nicht vorgesehen.

Haben Sie bestimmt, welche Technologien in Ihrer S2D-Bereitstellung die Rollen von Capacity und Cache übernehmen werden, müssen Sie eine bestimmte Mindest-Stückzahl an Laufwerken jeder Art bereitstellen. Pro Server benötigen Sie mindestens vier Laufwerke der Capacity-Klasse und mindestens zwei Laufwerke der Cache-Klasse. S2D bildet feste Zuordnungen zwischen Capacity- und

Cache-Laufwerken, daher ist es von Vorteil, wenn die Anzahl der Capacity-Laufwerke ein ganzes Vielfaches der Anzahl der Cache-Platten beträgt.

Es gibt aber eine Ausnahme: Sie können in einer von Microsoft unterstützten Art und Weise S2D auch auf virtualisierten Servern bereitstellen. In diesem Fall liegt die Mindestanzahl der benötigten Festplatten bei zwei. Sie werden in der Regel als HDD erkannt, können aber einen Capacity-Tier ohne Cache unter S2D bilden.

Alle für S2D verwendeten Festplattenlaufwerke müssen direkt per SATA, SAS oder PCIe angeschlossen sein. Abstraktionen wie SAN oder RAID sind nicht unterstützt. Auch externe Diskgehäuse mit "Shared SAS" oder gar SAS-Switche gehören nicht zu den möglichen Konfigurationen. Ein direkt per SAS oder SATA angeschlossenes JBOD hingegen wird unterstützt und kann eingesetzt werden, um auf die notwendige Anzahl der Disks zu kommen.

Aus Performancegründen sollten Sie besonders bei vielen Laufwerken pro Server darauf achten, die Anschlüsse auf mehrere SATA- beziehungsweise SAS-Controller zu verteilen. Bei NVMe und pMem ergibt sich die Verteilung automatisch, da sie gar nicht erst von den klassischen Storage-Bustechnologien Gebrauch machen. Müssen Sie hingegen eine "Sparkonfiguration" bauen, verfügen viele RAID-Controller führender Serverhersteller über die Intelligenz, auf der gleichen Karte sowohl RAID 1 für das Boot-Medium als auch SATA-Pass-Through für die S2D-Laufwerke zu implementieren. Für endgültige Klarheit sorgt hier der Windows Server Catalog. Suchen Sie dort nach Hardwarekomponenten und Systemen, die für Software-Defined Data Center (SDDC) in Premium oder Standard zertifiziert sind.

Software-defined Storage aller Hersteller bietet als eines der wichtigsten Features die Absicherung gegenüber dem Ausfall von Teilen der Speicherinfrastruktur, verbunden mit der Performanceverbesserung durch das Aufteilen der I/O-Vorgänge auf mehrere Festplatten oder sogar Controller. Storage Spaces Direct ist da keine Ausnahme. Anders als beim herkömmlichen RAID legen Sie das Redundanzverhalten Ihres Speichers nicht für den gesamten Plattenverbund einheitlich fest, sondern definieren die gewünschte Redundanz je nach Umfang und Zweck der gespeicherten Daten. Bei S2D verfügt jedes Volume, das Sie innerhalb des Speicherpools in Ihrem S2D-Cluster anlegen, über eigene Einstellungen hinsichtlich der Datenredundanz. Grundsätzlich stehen Ihnen für jedes Volume zwei Möglichkeiten zur Verfügung, die Speicherblöcke auf physikalische Laufwerke und Clusterknoten zu verteilen:

- Spiegelung: Dabei wird jeder Speicherblock einmal auf einen anderen Knoten im Cluster gespiegelt (two-way mirror) oder, falls Ihr Cluster drei oder mehr Knoten umfasst, sogar auf zwei weitere Knoten (three-way mirror). Ein Volume mit Drei-Wege-Spiegelung kann den Ausfall von zwei Hardwarekomponenten (zwei Server oder ein Server und eine Festplatte in einem anderen Server) tolerieren, belegt aber naturgemäß den dreifachen Platz auf den Festplattenlaufwerken. Da Spiegelung den geringsten Performance-Overhead aller Redundanzverfahren in S2D mit sich bringt, bietet sich dieses Verfahren normalerweise an, wenn ausreichend physikalische Festplattenkapazität zur Verfügung steht.

- Parität: Diese Variante, auch "erasure coding" genannt, ist aus dem herkömmlichen RAID wohlbekannt und weist in S2D die gleichen Merkmale auf wie die Hardwareimplementierung: hoher Bedarf an Rechenleistung, langsame Random Writes und deutlich verringerte Performance bei Verlust einer Komponente. Microsoft verwendet bei S2D die duale Parität, was funktional RAID 6 entspricht.

Bei sechs oder mehr Knoten im Cluster können Sie mittels des Features "Begrenzte Zuordnung" [3], das mit Server 2019 hinzugekommen ist, die Verteilung der dreifach gespiegelten Volumes auf eine Teilmenge der Clusterknoten einschränken. Derart gestaltete Volumes tolerieren tendenziell größere Ausfälle im Cluster, erfordern jedoch einen höheren Verwaltungsaufwand.

Der Festplattenbedarf für die gleiche Nettokapazität eines Volumes ist je nach verwendetem Verfahren stark unterschiedlich. Verbraucht Drei-Wege-Spiegelung immer den dreifachen Platz (Storage-Effizienz von 33 Prozent), hängt die Storage-Effizienz eines Dual-Parity-Volumes von der Anzahl der Knoten im Cluster ab. Da stets zwei Paritätsblöcke verwendet werden, brauchen Sie für dieses Verfahren mindestens vier Server. Dabei wird die Hälfte des beanspruchten Plattenplatzes produktiv verwendet (pro zwei Datenblöcke fallen zwei Paritätsblöcke an). Weist Ihr Cluster hingegen das Maximum von 16 Knoten auf, "bedienen" je zwei Paritätsblöcke ganze 14 Datenblöcke, und die Storage-Effizienz steigt auf 87,5 Prozent. Allerdings sinkt die Performance für solch ein Volume sowohl beim zufälligen Schreiben als auch unter Ausfallbedingungen sehr stark. Dabei entsteht auch ein hoher Rechenaufwand, der insbesondere in hyperkonvergenten Szenarien nicht zu unterschätzen ist, da die von S2D beanspruchte CPU-Leistung den virtuellen Maschinen im Cluster fehlt.

Die beiden Redundanzverfahren lassen sich auch miteinander kombinieren. Die Variante "mirror-accelerated parity" teilt das Volume in einen gespiegelten und einen durch duale Parität abgesicherten Teil. Das Größenverhältnis zwischen den beiden können Sie bei der Anlage des Volumes festlegen. Neu geschriebene Blöcke landen zunächst im gespiegelten Teil und die am wenigsten beanspruchten Blöcke wandern allmählich in den Parity-Teil. Es findet also ein Tiering innerhalb eines Volumes statt. Mit solchen Volumes wird der Einsatz von ReFS als Dateisystem gegenüber NTFS dringend empfohlen, weil ReFS über eine Intelligenz verfügt, die das richtige Platzieren der Speicherblöcke optimiert. NTFS hingegen "sieht" die darunterliegende Struktur nicht.

In kleinen Clustern mit nur zwei Knoten können Sie auf "nested resiliency" zurückgreifen. Dabei werden alle Blöcke einmal zwischen den beiden Knoten gespiegelt. Um den Ausfall eines Servers und einer Festplatte ebenfalls tolerieren zu können, wird jeder Block noch einmal lokal gespiegelt (Storage-Effizienz des gesamten Volumes beträgt somit 25 Prozent) oder mit Parität versehen (Storage-Effizienz hängt von der Anzahl der Capacity-Festplatten ab, und es sind mindestens vier Platten pro Knoten erforderlich).

Um Ihre Volumes optimal zu planen, sollten Sie also eine gute Vorstellung davon haben, wieviel Speicherplatz Ihre Work-loads netto benötigen werden und welches Performanceprofil sie aufweisen. Für produktive VMs und wichtige Datenbanken sollten Sie keine Kompromisse eingehen und mit Drei-Wege-Spiegelung arbeiten. Test-VMs und nicht-persistente VDIs platzieren Sie am besten auf Volumes mit Zwei-Wege-Spiegelung. Backup- und Archivdaten können von der hohen Speichereffizienz der "dual parity" profitieren.

Bei der Planung sollten Sie sich auch um die Anzahl der zu erstellenden Volumes Gedanken machen. Die höchste Performance erhalten Sie bei S2D, wenn die Anzahl der Volumes gleichen Typs der Anzahl der Knoten im Cluster entspricht. Betreiben Sie also beispielsweise 150 virtuelle Maschinen in einem Fünf-Knoten-Cluster, sollten Sie optimalerweise fünf gespiegelte Volumes anlegen, auf denen jeweils 30 VMs Platz finden. Mit steigender Anzahl an Knoten erfolgt diese Aufteilung allerdings auf Kosten der Flexibilität in der Platzierung Ihrer Workloads, insbesondere wenn Sie Thin Provisioning oder differenzierende Disks verwenden, die unabhängig voneinander und oft auch unerwartet wachsen können.

Für den Einsatz in einem Storage-Spaces-Direct-Cluster empfiehlt Microsoft das ReFS-Dateisystem, da dieses enger mit der S2D-Intelligenz unter den Volumes verzahnt ist als das herkömmliche NTFS. Bevor Sie sich für ReFS entscheiden, müssen Sie klären, ob das bei Ihnen eingesetzte Datensicherungssystem solche Volumes überhaupt sichern kann. Für das automatische Auffangen von physikalisch defekten Laufwerken und Speicherblöcken innerhalb eines Servers erwartet Microsoft, dass Sie in jedem Tier mindestens so viel Kapazität extra bereitstellen wie ein einzelnes Festplattenlaufwerk des Tiers groß ist.

Wenn Sie einen S2D-Cluster planen, das bis zum Ende seiner Betriebsdauer unverändert läuft, sollten Sie definitiv alle Knoten identisch ausstatten. Das betrifft sowohl die Serverhardware selbst als auch die Art, Anzahl und Größe der verbauten Speicherlaufwerke. In solch einem Cluster haben Sie eine optimale Ressourcen-Verteilung auf alle Knoten und können darüber hinaus auf alle Automatismen von S2D zurückgreifen, welche die Zuweisung von Laufwerken zu den einzelnen Storage-Tiern an der Modellbezeichnung der jeweiligen Festplatte festmachen.

In der Praxis kann es passieren, dass Sie ausgefallene Sto-rage-Laufwerke oder ganze Server während der Lebenszeit des Clusters austauschen müssen. Dabei werden Sie möglicherweise nicht die gleichen Modelle oder nicht einmal die gleichen Größen nachkaufen können. Grundsätzlich stellt dies für S2D kein Problem dar, sie sollten jedoch einige Einschränkungen beherzigen:

- Alle Server im Cluster müssen über die gleichen Plattentechnologien verfügen. Es ist nicht unterstützt, in einigen Knoten HDD und SSD, in anderen HDD und NVMe und wiederum in anderen SSD und NVMe zu kombinieren.

- Alle Server im Cluster müssen die gleiche Anzahl Platten von jedem Typ aufweisen. Es ist nicht möglich, in einigen Knoten fünf HDD und zwei NVMe, in anderen aber vier HDD und drei NVMe zu verwenden.

- Verschiedene Plattengrößen zwischen Servern sind grundsätzlich unterstützt. Volumes mit Spiegelung werden so verteilt, dass die überschüssige Kapazität einiger Knoten möglichst ausgenutzt wird. Volumes mit Parität hingegen orientieren sich nach dem Server mit dem kleinsten Capacity-Tier, überschüssige Kapazitäten werden nicht für solche Volumes beansprucht.

Unterschiede in der CPU- und RAM-Ausstattung der Cluster-Knoten spielen funktional bei Storage Spaces Direct keine Rolle, sie können jedoch zu unausgeglichener Performance im Cluster führen, insbesondere im Zusammenspiel mit den virtuellen Maschinen, die im Cluster ausgeführt werden.

Um die Zusammenhänge zwischen den Workloads und den physischen Festplatten noch einmal zu veranschaulichen, nehmen wir an, dass Sie für 150 VMs ein Sieben-Knoten-Cluster benötigen. 100 der VMs sind gemischte produktive Workloads, die standardmäßig mit einer Festplattengröße von 120 GByte daherkommen. Weitere 48 sind Test-VMs, ebenfalls mit 120-GByte-Platte, die zwar eine gute Performance, nicht jedoch dieselbe Redundanz wie die produktiven Maschinen erwarten. Die restlichen zwei VMs beherbergen ein Archiv, das zusätzlich zu den 120 GByte Speicher noch 200 GByte an Datenbank-Plattenplatz und 3 TByte an Archiv-Plattenkapazität pro VM benötigt.

Die Systemplatten aller produktiven VMs und die Datenbankplatten der Archiv-VMs platzieren Sie am besten auf Vol-umes mit Drei-Wege-Spiegelung. Davon benötigen Sie also netto 12,24 TByte, was in etwa auf brutto 37 TByte Plattenplatz hinausläuft. Da auch die RAM-Abbilddateien der VMs ebenfalls auf diesen Vol-umes landen sollten, benötigen Sie vermutlich rund 40 TByte Bruttoplattenplatz. Für die Test-VMs stellen Sie Volumes mit Zwei-Wege-Spiegelung bereit. Der Nettobedarf liegt hier bei 5,8 TByte, was mit RAM-Abbilddateien auf circa 12 TByte Brutto-Kapazität hinausläuft. Für die Archivplatten eignet sich die doppelte Parität in der Regel recht gut, sodass die benötigten 6 TByte Nettospeicherplatz mit rund 8,5 TByte zu Buche schlagen. Die Storage-Effizienz liegt bei (7-2) / 7 = 71,4 Prozent.

Im Capacity-Tier müssen wir also insgesamt circa 60,5 TByte brutto bereitstellen, was bei sieben Knoten auf 8,5 TByte pro Knoten hinausläuft. Möchten Sie dies mit den gängigen 960-GByte-SSDs lösen, benötigen Sie dafür zehn Stück pro Host, da Sie rechnerisch noch die Kapazität eines Laufwerks hinzurechnen müssen. Um die optimale Zuordnung im Cache zu erreichen, können Sie entweder mit fünf oder mit zwei NVMe-Datenträgern pro Host arbeiten. Alternativ nehmen Sie zwölf kleinere SSDs für Capacity (beispielsweise 800 GByte), was Ihnen eine Konfiguration mit drei oder vier Cache-Platten ermöglicht.

Haben Sie diese Laufwerke zu einem S2D-Pool zusammengefasst, stellen Sie daraus zwei Dual-Parity-Volumes mit jeweils 3 TByte (Archiv), sieben Volumes mit Drei-Wege-Spiegelung à 1,75 TByte (Produktion) und sieben Volumes mit Zwei-Wege-Spiegelung à 820 GByte (Test) bereit. Wenn Sie krumme Zahlen bei den Vol-ume-Größen vermeiden möchten, müssen Sie entsprechend aufrunden, bevor Sie die Anzahl und Größe der zu bestellenden Festplattenlaufwerke bestimmen.

Doch auch mit Aufrunden bleibt die Planung des S2D-Speicherplatzes keine exakte Wissenschaft, und Sie sollten gegenüber dem mindestens benötigten Speicherplatz eine gewisse Reserve einplanen. Cosmos Darwin, der für S2D zuständige Principal Program Manager bei Microsoft, bietet auf seiner Website [4] einen Kalkulator an, mit dem Sie sich den ersten Eindruck über die Ausnutzung des physischen Festplattenplatzes in einem S2D-Cluster verschaffen können.

Ein Volume pro Host zu haben, ist aus Performancesicht zwar vorteilhaft, jedoch nicht immer praktikabel. Bei diesem Ansatz wird mit wachsender Anzahl an Clusterknoten der produktiv bereitgestellte Speicherplatz immer weiter zerstückelt, was die Platzierung von besonders großen virtuellen Festplatten erschweren oder gar unmöglich machen kann. Testen Sie daher immer die tatsächlich erzielbare Performance zunächst mit einer geringeren Anzahl an Volumes. Ist sie für Ihren konkreten Fall bereits ausreichend, sollten Sie die Vol-umes nicht weiter verteilen, sondern einfach vergrößern, um die größtmögliche Flexibilität bei der Platzierung von Workloads zu erhalten.

Am Anfang wurden hyperkonvergente Storage-Konzepte von vielen Administratoren mit der Begründung abgelehnt, der Speicher wäre nur so schnell wie das Netzwerk. Diese Erkenntnis geht jedoch auf eine Zeit zurück, in der das Netzwerk in der Regel aus 1-GBit/s-Adaptern bestand und der Storage-Traffic über die gleichen Switches lief wie der produktive Datenverkehr. Inzwischen sind 10-GBit/s-Adapter Usus, 25 GBit/s guter Mainstream und 100-GBit/s-Schnittstellen für anspruchsvolle Rechenzentren erschwinglich geworden.

Eine moderne Netzwerkschnittstelle ist im Schnitt also etwa so schnell wie ein NVMe-Datenträger, womit eine Leistungsparität zwischen Storage und Netzwerk hergestellt wäre. Durch die Verwendung von Remote Direct Memory Access (RDMA) ist es zudem gelungen, den Overhead bei der Kommunikation zwischen Servern nahezu auf Null zu reduzieren, was einen weiteren Vorsprung in der Leistung hyperkonvergenter Storage-Systeme gegenüber klassischem SAN verspricht, dessen Daten viele Hardware- und Treiberschichten passieren müssen. Damit Sie diese Vorteile realisieren können, muss die Netzwerk-Ausstattung Ihres S2D-Clusters hohen Ansprüchen genügen:

- 10-GBit/s-Adapter sind Pflicht, ab vier Clusterknoten und für All-Flash-Bereitstellungen werden 25-GBit/s-Netzwerkkarten empfohlen.

- Redundante Anbindungen sind dringend angeraten.

- Für größere Deployments ab vier Cluster-Knoten sollte RDMA zum Einsatz kommen.

Unter hoher Auslastung ist RDMA ein entscheidender Faktor, um maximale Performance aus dem hyperkonvergenten Storage herauszuholen. Microsoft empfiehlt das leichter einzurichtende iWARP-Protokoll gegenüber dem theoretisch qualitativ hochwertigeren, aber anspruchsvolleren RoCE. iWARP (internet Wide Area RDMA Protocol) basiert auf dem verbindungsorientierten TCP-Transport und baut in mehreren Schichten darauf auf, während RoCE (RDMA over Converged Ethernet) das InfiniBand-Protokoll in UDP-Paketen transportiert. Die Protokollunterstützung variiert zwischen Herstellern: Chelsio unterstützt traditionell ausschließlich iWARP, Mellanox und Broadcom ausschließlich RoCE, bei Intel unterstützen die X722-Adapter ausschließlich iWARP, die E810-Karten hingegen bieten sowohl iWARP als auch RoCE.

Neben den benötigten Adaptern und Kabeln müssen natürlich auch Switchports in ausreichender Geschwindigkeit und Menge bereitstehen. Grundsätzlich unterstützt S2D auch "switchless interconnect", allerdings unter der Bedingung, dass jeder Server mit jedem anderen Knoten im Cluster eine direkte Verbindung hat, die dazu noch durch ein eigenes IP-Adress-Subnetz gekennzeichnet ist. Möchten Sie Ihren S2D-Cluster gegen den Ausfall eines Netzwerkports oder eines DAC-Kabels absichern, benötigen Sie mindestens zwei Ports pro Serverpaar. Bei drei Knoten muss jeder Server damit über vier Ports allein für S2D verfügen, bei vier Clusterknoten sind es bereits sechs Ports pro Server.

Doch auch in einem geswitchten LAN sollten Sie die S2D-Netzwerke durch IP-Konfigurationen voneinander isolieren, damit jeder Server im Cluster stets über die Verbindungswege zu den anderen Knoten Bescheid weiß. Gerade beim Einsatz von RDMA ist es nicht unbedingt empfehlenswert, S2D-Verbindungen zu routen, obwohl dies im Prinzip möglich wäre.

Sind Ihre Server fertig installiert und verkabelt, die Switches für das gewünschte RDMA-Protokoll vorbereitet und die Festplatten geleert, ist ein S2D-Cluster in der Regel schnell eingerichtet. Nehmen Sie alle Knoten des zukünftigen Clusters in Ihre Active-Directory-Domäne auf und sorgen Sie dafür, am besten mit Gruppenrichtlinien, dass die für die Einrichtung und Verwaltung verwendeten Accounts lokale Administrator-Rechte auf allen Knoten erhalten. Fügen Sie jedem Knoten die Features "Hyper-V" und "Fail-over Clustering" hinzu:

Falls als RDMA-Protokoll RoCE eingesetzt werden soll, aktivieren Sie noch das Datacenter-Bridging-Feature mit Add-WindowsFeature -Name Data-Center-Bridging. Falls Sie eine konvergente Bereitstellung mit einem Scale-Out-Dateiserver planen, benötigen Sie noch die "File Server"-Rolle: Add-WindowsFeature -Name FS-FileServer. Bilden Sie das Cluster mit dem Failover-Clustermanager oder mittels PowerShell ("Test-Cluster" beziehungsweise "New-Cluster"). Richten Sie nun einen Cluster-Zeugen ein – da in der Regel in einem S2D-Cluster kein blockbasierter Storage zu finden sein wird, eignet sich ein Dateifreigaben-Zeuge am besten.

Ist Ihr Cluster fertig, führen Sie auf einem der Knoten den Befehl Enable-ClusterStorageSpacesDirect aus. In dieser einfachsten Variante wird das Kommando versuchen, Ihren Storage-Pool aus den verfügbaren Disks automatisch zu konfigurieren. Sie können dieses Verhalten beeinflussen, beispielsweise mit "-AutoConfig $false", um den Pool manuell zu konfigurieren, oder mit "-CacheDeviceModel <Modell>", um in einem All-Flash-Szenario die SSDs einer bestimmten Modellreihe als Cache zu deklarieren; die restlichen SSDs bilden dann den Capacity-Tier. Der Befehl bietet noch weitere Parameter, die unter [5] dokumentiert sind.

Die Bereitstellungsanleitung inklusive hilfreicher PowerShell-Beispiele, so etwa zur Befreiung der Festplatten von Altlasten, steht unter [6] zur Verfügung. Ist die Aktivierung von S2D abgeschlossen, finden Sie Ihre lokalen Festplatten zu einem großen Speicherpool zusammengefasst vor, aus dem Sie nun die Volumes in den gewünschten Konfigurationen bereitstellen können.

Die herkömmlichen grafischen Verwaltungswerkzeuge für ein Hyper-V-Cluster – also Failovercluster-Manager und Hyper-V-Manager – bieten wenig in Bezug auf Überwachung und Verwaltung von Storage Spaces Direct. Der Failovercluster-Manager zeigt immerhin den Storage-Pool und die ihm zugeordneten physischen und virtuellen Laufwerke korrekt an, verwalten lassen sie sich damit aber nicht. Auch der Server-Manager, mit dem Sie sonst Storage-Spaces-Laufwerke verwalten können, beherrscht lediglich die Anzeige der Pools und Volumes. Die Bordmittel von Windows Server erlauben die Verwaltung von S2D ausschließlich per PowerShell.

Für hyperkonvergente Cluster bietet der System Center Virtual Machine Manager (SCVMM) umfassende Verwaltungsfunktionen für S2D und die Volumes darin. Bei konvergenten Bereitstellungen ist der Aufwand für den SCVMM unter Umständen nicht gerechtfertigt, vor allem wenn der S2D-Speicher gar nicht für Hyper-V zum Einsatz kommt. Abhilfe schafft das Windows Admin Center (WAC), das die Verwaltung (hyper-)konvergenter Cluster mit grafischen Mitteln ermöglicht.

Es sind nicht alle Operationen mittels WAC möglich. Zum Beispiel können Sie bei der Anlage eines Volumes nur zwischen "Drei-Wege-Spiegelung" und "Durch Spiegelung beschleunigte Parität" auswählen. Für andere Konfigurationen sind Sie auf die PowerShell angewiesen. Falls Sie beispielsweise mehrere Disks vorfinden, die nicht in einem ordnungsgemäßen Zustand sind, können Sie S2D über das gesamte Cluster mit Repair-ClusterStorageSpacesDirect reparieren.

Ein weiterer Betriebsaspekt von S2D verdient besondere Erwähnung: rollierende Updates unter Verwendung von Cluster Aware Update (CAU). Wenn CAU bei einem Knoten ankommt, um ihn zu patchen, wird dieser in den Wartungsmodus versetzt. Führt dies bei einem herkömmlichen Cluster einfach zur Evakuierung der darauf laufenden Workloads, startet S2D mit der Umverteilung der Speicherblöcke auf Festplatten in anderen Knoten, was das Patchen effektiv verhindert. Dazu bedienen sich viele Admins des von Ben Thomas [7] beschriebenen Workarounds unter Verwendung von Pre- und Post-Patch-Skripten in CAU.

Das Pre-Patch-Skript nimmt das Versetzen des Knotens in den Wartungsmodus und den Ausgleich im Storage vorweg, sodass CAU einen zum Patchen bereiten Host vorfindet. Das Post-Patch-Skript prüft, ob der Knoten noch in Wartung ist, und beendet die Wartung explizit. Denken Sie daran, dass die Skripte auf jedem Host benötigt werden; sie sollten also in einem Cluster-Volume liegen oder auf jeden Host kopiert werden.

Storage Spaces Direct ist eine faszinierende und inzwischen ausgereifte Technologie, mit der sich lokal verbaute Laufwerke zu einem hochperformanten und gegen Ausfall geschützten Speicher zusammenfassen lassen. Der Schlüssel zum Erfolg ist dabei das Netzwerk zwischen den Cluster-Knoten. Bevor Sie S2D produktiv einsetzen, sollten Sie umfangreiche Leistungs- und Ausfalltests durchführen, um die optimale Konfiguration Ihrer Speicher-Volumes zu bestimmen. Für die tägliche Überwachung und Verwaltung von S2D eignet sich das Windows Admin Center besonders gut. Das Beherrschen der PowerShell-Cmdlets zur Verwaltung von Storage Spaces und Failover Clustering ist dennoch von unschätzbarem Vorteil.