Um die aktuelle Storage-Spaces-Direct-Technologie (S2D) zu verstehen, lohnt sich ein Blick auf deren Werdegang in Windows Server. Windows Ser- ver 2012 erlaubte erstmals, einen Failover-Cluster zu erzeugen, der hochverfügbaren Speicher für Hyper-V bereitstellt. Hierbei werden an zwei oder mehr Server JBOD-Gehäuse per SAS angebunden, in denen sich drehende Festplatten oder Flashspeicher befinden. Diese Datenträger fasst das Betriebssystem zu einem logischen Verbund zusammen (Speicherpool). Auf dieser Basis lassen sich virtuelle Datenträger (vDisks) erstellen, für die Admins unter anderem die Größe und die gewünschte Redundanz festlegen.

Diese Redundanz ist vergleichbar mit RAID-0 beziehungsweise RAID-1, Microsoft verzichtet allerdings bewusst auf RAID-Controller und andere Hardwareintelligenz. Die Ablage und Absicherung der Daten erfolgt ausschließlich durch Software. Ergänzend steht als Redundanz-Option noch "Parity" zur Verfügung. Diese verteilt die Daten ähnlich einem RAID-5/6 über mehrere Datenträger und schreibt Paritätsinformationen. Beim Ausfall eines physischen Datenträgers ist immer noch der Zugriff möglich, allerdings bietet sich diese Art von Layout nur für Daten an, die keine hohen I/O-Anforderungen haben. Sollte ein Storage-Spaces-Cluster der Virtualisierung dienen, war ein Spiegel Pflicht.

Als Datenträger kamen drehende SAS-Festplatten, SAS-SSDs oder eine Kombination aus beidem zum Einsatz. Da sich die Datenträger über das JBOD-Gehäuse an zwei oder mehr Server verbanden, war die SAS-Schnittstelle erforderlich. Der Einsatz von SATA war aus technischen Gründen nicht umsetzbar. Flashspeicher war zu dieser Zeit noch deutlich teurer als heutzutage und bot bei weitem nicht die Kapazitäten, die aktuell möglich sind. Daher waren die meisten Storage-Spaces-Cluster im Hybrid-Modus aufgebaut – also Flashspeicher und Festplatten in einem gemeinsamen Speicherpool.

Im Hintergrund protokollierte dabei eine Heatmap, welche Speicherblöcke wie oft genutzt oder geändert wurden. In einem Abstand von vier Stunden lief auf dem Cluster ein Tiering-Job, der die Blöcke zwischen den SSDs und den HDDs verschob und aufteilte. Je häufiger ein Datenblock im Zugriff war, desto wahrscheinlicher wurde er in den SSD-Bereich verschoben. Dies erhöhte die Performance des Systems, allerdings konnte der Storage-Cluster erst mit einer gewissen Zeitverzögerung auf Änderungen reagieren. Entstanden als viele neue Datenblöcke, dauerte es eine gewisse Zeit, bis diese im SSD-Bereich und somit im schnellen Zugriff landeten.

Grundsätzlich war diese Technologie gut, wenn auch mit Grenzen: Storage Spaces war kein echtes SAN-System, hatte aber auch nicht dessen hohen Preis. Doch die Anforderungen an die genutzte Hardware waren nicht allzu hoch. Allerdings garantierten nur zertifizierte SAS-HBAs, JBODs und Datenträger einen reibungslosen Betrieb. Diese Abhängigkeiten und Voraussetzungen reduzierte Microsoft mit "Storage Spaces Direct" in Server 2016 weiter.

Eine der größten Herausforderungen und Kostentreiber bei Storage Spaces waren die Datenträger-JBODs und die SAS-Verkabelung. Bei vier Cluster-Knoten und einer Redundanz pro Knoten waren acht SAS-Verbindungen pro JBOD notwendig, bei drei JBODs schon 24 Kabel (Verbindungen). Wer schon einmal mit SAS-Kabeln in einer gewissen Länge gearbeitet hat, weiß, wie dick und sperrig diese sein können. Die Technik war nicht gut skalierbar und brauchte meist viel Platz im Rack.

Mit Storage Spaces Direct hat Microsoft – vereinfacht gesagt – die Datenträger aus den externen JBODs genommen und in die Server verfrachtet. Die Synchronisierung findet nicht mehr per SAS statt, sondern per Ethernet. Das spart nicht nur Platz im Rack, sondern auch Kosten für die Hardware. So sind keine JBOD-Gehäuse mehr notwendig und es lassen sich SATA-Datenträger verwenden, da der Server nur Zugriff auf den Datenträger benötigt, in dem die Disk steckt. Da eine Verbindung untereinander per Ethernet besteht, ist dies kein Problem.

Bevor wir in diesem Artikel zur Installation und Einrichtung eines solchen S2D-Cluster kommen, legen wir noch ein großes Augenmerk auf die Technik selbst sowie die Planung der Umgebung. Ein durchdachter Aufbau und eine gute Hardwarezusammenstellung sind essenziell für einen S2D-Cluster, um für den späteren Betrieb eine stabile und zuverlässige Infrastruktur zu etablieren.

Für den S2D-Betrieb sind mindestens zwei Server erforderlich, die maximale Anzahl pro Cluster liegt bei 16 Systemen. Jeder dieser Knoten sollte identisch ausgestattet sein in Sachen CPU-Modell, Anzahl der CPUs pro Knoten, Arbeitsspeicher und Art und Anzahl der Datenträger. Insbesondere Letztere müssen identisch sein, damit jedes System gleich schnell arbeiten kann und es nicht zu einem Verschnitt von Speicherplatz kommt. Bei den Datenträgern haben Sie die Wahl zwischen verschiedenen Typen und Modellen:

- Persistent Memory (PMem): Arbeitsspeicher, der in der Lage ist, Daten für eine gewisse Zeit auch im ausgeschalteten Zustand zu speichern. Er bietet die größte Performance bei der geringsten Latenz. Neben den Kosten ist eines der Probleme der relativ geringe Speicherplatz pro Modul. Da sich die Module die vorhandenen DIMM-Steckplätze auf dem Mainboard teilen, ist hier Skalierung schwierig.

- Non-Volatile Memory Express (NMVe): Flashspeicher, der direkt an einen PCIe-Bus angebunden wird. Diese Anbindung mit hoher Bandbreite nutzt das volle Potenzial von Flashspeicher aus. Häufig werden die Datenträger per 2.5-Zoll-U.3 in den Server eingebracht und sind somit Hot-Plug-fähig.

- Solid State Drives (SSDs): SSDs arbeiten per SAS oder SATA. Die Performance ist durch die Art der Anbindung nicht so hoch wie bei NVMe.

- Hard Disk Drives (HDDs): Drehende Festplatten, die ebenfalls über SAS oder SATA Daten transportieren. Hierbei handelt es sich um die langsamste, aber auch günstigste Form von Speicher für einen S2D-Failover-Cluster.

Es gibt unterschiedliche Möglichkeiten, die Datenträgertypen zu kombinieren. Nur die ausschließliche Nutzung von HDDs ist nicht möglich – dies wäre zu langsam für den Anwendungszweck, auf den ein S2D-Cluster zielt: Virtualisierung mit hoher I/O-Leistung und geringe Latenzen. Wenn wir PMem einmal außen vorlassen, erreichen Sie mit ausschließlich NVMe-Datenträgern die größtmögliche Performance. Die Datenträger müssen alle vom gleichen Typ und Modell sein, damit jeder Server eine annährend identische Performance liefert. Diese hängt zum einen von dem NVMe-Modell ab, zum anderen von der Anzahl aller Datenträger und der Art von Resilienz, die zum Einsatz kommt. Wir sprechen im weiteren Verlauf noch über die unterschiedlichen Resilienzen und darüber, für welche Anwendungszwecke welche Konfiguration Sinn ergibt. Die Mindestanzahl an Datenträgern pro Server in solch einem Szenario ist vier – mit weniger können Sie den Cluster nicht aufbauen und erhalten keinen Support.

Theoretisch sind in einem NVMe-Only-Cluster auch zwei unterschiedliche Datenträgermodelle nutzbar, dies ist allerdings manuell zu konfigurieren. Dabei sollte ein Modell im Lauf seiner Lebenszeit mehr Daten schreiben können als das andere. Dieses Merkmal wird oft mit "Drive Writes Per Day" (DWPD) oder "Total Bytes Written" (TBW) angegeben und bezieht sich auf die Menge an Daten, für die der Hersteller eine Garantie auspricht.

Microsoft spricht eine Empfehlung für drei DWPD oder mehr aus. Sämtliche eingehenden Daten werden initial auf die Datenträger geschrieben, die eine höhere Schreiblast vertragen. Das zweite Modell hingegen kann eine geringere Anforderung an die maximale Schreiblast haben, da das S2D-System hier weniger und seltener Daten ablegt. Dies wirkt sich auf den Preis aus, denn Modelle mit geringeren DWPD-Werten sind günstiger in der Anschaffung. Teilweise haben diese eine andere Art von Flashspeicher an Bord, der dann durch eine geringere Performance ebenfalls kostengünstiger ist. Die Konfiguration eines solchen "gemixten" Clusters ist aufwendiger als beim ausschließlichen Einsatz eines Modells. Doch bei sinkenden Preisen lohnt sich die erhöhte Komplexität selten. Beachten Sie außerdem, dass die schreibintensiveren Datenträger als Cache dienen und Sie diese nicht zur dauerhaften Speicherkapazität zählen dürfen.

Alternativ können Sie auch ausschließlich auf SSDs setzen. Die Kosten hierfür liegen etwas unter denen von NVMe-Systemen, allerdings ist die Performance geringer. Während bezahlbare und gut verfügbare NVMe-Datenträger mittlerweile annährend 7 GByte/s lesend und 6 GByte/s schreibend schaffen, sind SAS-SSDs auf etwas über 2 GByte/s beschränkt. Über SATA ist der Datentransfer noch deutlich langsamer, hier ist bei etwas über 500 MByte/s schreibend und lesend Ende.

Sie haben zudem die Option, SSD und NVMe in einem Cluster gemeinsam zu verwenden. Diese Art von Konfiguration ähnelt dem Betrieb von zwei unterschiedlichen NVMe- oder SSD-Modellen. Entscheiden Sie sich für zwei verschiedene Arten von Speichermedien, arbeiten die schnelleren Laufwerke als Cache, die langsameren als Kapazitätsspeicher. Das Betriebssystem geht immer davon aus, dass NVMe-Datenträger schneller und besser als die SSDs sind und wählt daher NVMe als Cache während der Installation. Cache-Laufwerke dürfen Sie nicht als nutzbaren Cluster-Storage rechnen, da die Daten nur zeitweise dort lagern. Ein Schreib- vorgang erfolgt grundsätzlich immer im Cache und niemals direkt auf die Kapazitätsdatenträger. Dies beschleunigt den Vorgang, da der Cache die Daten selbst bei Random-I/O schnell annimmt.

Sie benötigen grundsätzlich pro Server zwei oder mehr Datenträger als Cache. Ein einzelner funktioniert nicht. Dies hat damit zu tun, dass bei einem Ausfall dieses Mediums die Leistung des Servers enorm in die Knie gehen kann und damit das gesamte System langsam wird. Bei zwei oder mehr Cachedatenträgern können die verbleibenden Speicher im Problemfall übernehmen.

Jeder Datenblock im Cache wird nach seinem Zugriff bewertet: Je häufiger Änderungen, umso "heißer" wird er eingestuft ("Hot Data"). Findet hingegen ein einmaliger Schreibvorgang von nachfolgenden Änderungen statt, sprechen wir von "Cold Data. Auf diese Art und Weise entsteht die zuvor angesprochene Heatmap mit einer Bewertung aller Datenblöcke. Auf dieser Basis sortiert das System die Datenblöcke und je heißer ein solcher ist, desto wahrscheinlicher verbleibt er im Cache für schnelles Lesen/Schreiben. Kältere Blöcke wandern auf die dahinterliegenden Datenträger. Dieses Verfahren nennt sich "Tiering" und findet sich seit vielen Jahren in diversen Storage-Systemen, bei denen eine Sortierung der Daten über zwei oder mehr Bereiche ("Tiers") erfolgt.

Ein S2D-Cluster führt die Bewertung und Bewegung von Daten jederzeit im Hintergrund durch. Erreicht der Cache einen gewissen Füllstand, bewegen sich die kältesten Daten auf den dahinterliegenden Tier – in diesem Fall die SSDs. Dieser Prozess wird auch als "De-Staging" bezeichnet. Je mehr Änderungen Sie auf Ihrem Storage durchführen, desto häufiger und intensiver sind Datenverschiebungen notwendig. Sie sollten daher ein gutes Verhältnis zwischen Cache und Kapazität haben, eine generelle Empfehlung sind 20 Prozent Cache gegenüber 80 Prozent Kapazität. Je größer der Cache ist, desto seltener muss S2D Daten bewegen und desto schneller ist das System.

Dies führt allerdings dazu, dass es bei einer steigenden Größe und Anzahl der Cachedatenträger ab einem gewissen Punkt sinnvoll ist, komplett auf diese Datenträger zu setzen und somit nur mit einem Tier zu arbeiten. Denn insbesondere bei Setups, die ausschließlich mit Flashspeicher arbeiten, kann es Vorteile bringen, nur ein Datenträgermodell einzusetzen. Dadurch steht der gesamte Speicherplatz zur Ablage von Daten zur Verfügung und es ist nicht mehr notwendig, den Cache herauszurechnen. Eine Auslagerung der Daten zwischen den unterschiedlichen Tiers ist ebenfalls nicht erforderlich, dies erspart einiges an I/O auf dem gesamten System. Das vereinfacht Konfiguration, Planung und Wartung.

Im Laufe der Jahre haben sich die Systeme, die IT-Verantwortliche planen und installieren, immer weiter in Richtung "All-Flash" mit einem einzigen Typ Datenträger entwickelt. Manche Hersteller bieten mittlerweile gar keine SSD-basierten Cluster mehr an, es kann nur zwischen Full-NVMe oder einer hybriden Variante mit HDDs und NVMe gewählt werden. Dies liegt unter anderem daran, dass der Preisunterschied zwischen den beiden Typen an Datenträgern nicht mehr allzu groß ist, und dass jede mögliche Variante validiert und zertifiziert werden muss, was Zeit und Geld kostet.

Wir haben in den bisher beschriebenen Varianten ausschließlich über Full-Flash-Cluster gesprochen. Egal, ob Sie ausschließlich auf NVMe setzen, Ihnen SSDs grundsätzlich schnell genug sind oder eine Mischung aus beidem anstreben, all diese Ansätze bieten sehr gute Performance und eignen sich dadurch hervorragend für den Betrieb von VMs auf Basis von Hyper-V. I/O-Leistungen von mehreren Millionen und Datendurchsätze von 20 GByte pro Sekunde oder mehr sind kein Problem. Zudem skalieren die Cluster abhängig von der geplanten Hardware sehr gut.

Kommt es nicht unbedingt auf höchste Performance an, können Sie jedoch über eine hybride Konfiguration nachdenken. Diese kombiniert Flash mit traditionellen Festplatten und bietet mehrere Optionen. Eine davon sind NVMe-Datenträger und HDDs, wobei Flash als Cache dient. Dies sorgt für die Beschleunigung von Lese- und Schreibzugriffen. Alle Daten landen initial im NVMe-Cache und erst nach einer gewissen Zeit auf den HDDs. Der Auslagerungsprozess findet serialisiert statt, um die Schreibleistung der HDDs optimal auszureizen und zu maximieren. Gilt es, Daten von den HDDs zu lesen, erfolgt dies einmalig. Bei weiteren Zugriffen auf diese Daten springt dann der Cache ein. Der erste Zugriff auf die kalten Datenblöcke dauert zwangsläufig länger von der HDD als von einem Flashdatenträger, das macht diesen hybriden Storage etwas langsamer als ein Full-Flash-System. Die Kosten sind auf der anderen Seite dafür aber nicht so hoch und Sie bekommen deutlich mehr Speicherplatz für das gleiche oder sogar weniger Geld.

Statt einem NVMe-Cache können Sie natürlich auch SSDs verwenden. Der Aufbau und die Anforderungen sind identisch gegenüber dem NVMe-Cache-Setup. Auch hier sind minimal zwei SSDs pro Server als Cache sowie vier HDDs oder mehr für den Kapazitätsbereich erforderlich. Dabei gilt wieder, dass 20 Prozent Cache und 80 Prozent Kapazitätsspeicher einen guten Referenzwert darstellen. Größere Cache-Kapazitäten sorgen für mehr Leistung und Performance, da seltener ausgelagert werden muss. Microsoft selbst empfiehlt übrigens nur zehn Prozent Cache-Anteil – dies hat sich in vielen Fällen als zu gering erwiesen und das System musste zu häufig de-stagen.

Ein S2D-Cluster muss nicht zwingend für Virtualisierung mit großen I/O-Anforderungen zum Einsatz kommen, denkbar ist auch ein System zur Speicherung und Archivierung von großen Datenmengen, die keine allzu großen Anforderungen stellen. Im Grunde sprechen wir also von selten benötigten Daten. Je weniger Leistung Sie benötigen, desto geringer kann der Cache-Anteil sein. Sie müssen für diese Systeme trotzdem mindestens zwei Cachedatenträger einplanen, aber für die Kapazität stehen dann beispielsweise ein Dutzend HDDs mit 20 TByte oder mehr zur Verfügung.

Der Cache sorgt für eine schnelle Annahme und Speicherung von eingehenden Daten, die danach auf den HDD-Tier umziehen. So lässt sich beispielsweise ein hochverfügbarer Backupspeicher betreiben. Wichtig bei der Planung ist in diesem Fall, dass Sie den Cache so dimensionieren, dass die Größe der Änderungen zwischen den jeweiligen Backupjobs kleiner ist als der Cache. Damit ist gewährleistet, dass die Sicherung die neuen Daten schnell annimmt und speichert und erst nachträglich auf die HDDs auslagert.

Eine noch komplexere Art der Bereitstellung ist die Kombination von NVMe, SSD und HDD. Bei dieser Variante dienen die NVMe-Datenträger als Cache und SSDs sowie HDDs stehen für die dauerhafte Speicherung der Daten zur Verfügung. Mit Windows Server 2016 waren solche Konfigurationen häufiger zu sehen, da die NVMe-Technik noch recht teuer war. Neben dem reinen Datenträgerpreis müssen Sie hierbei auch die physische Anbindung berücksichtigen. Während Sie heute für einen relativ geringen Aufpreis einen Server mit bis zu 24 NVMe-Steckplätzen erhalten, war dies noch vor einigen Jahren nicht ganz so einfach. Server hatten zwei oder vier NVMe-Steckplätze, der Rest der Slots war nur für SAS- oder SATA-Datenträger ausgelegt.

Egal, welche Art von Hybrid-Storage Sie planen, achten Sie darauf, dass die Anzahl der Datenträger passt. Wir haben bereits angesprochen, dass Sie mindestens zwei Cachedatenträger pro Server benötigen. Mehr ist jederzeit möglich, beachten Sie aber auch die Anzahl der anderen Speichermedien. Ein S2D-System arbeitet immer dann optimal, wenn die Anzahl der Kapazitätsdatenträger das Mehrfache des Cachevolumens beträgt. So müssen Sie zum Beispiel bei zwei Cachedatenträgern mindestens vier Kapazitätsfestplatten vorhalten – oder das mehrfache von zwei. Dies hat den Hintergrund, dass jeder Cachedatenträger (in diesem Beispiel zwei) für die Hälfte aller Kapazitätsspeicher verantwortlich ist. Setzen Sie demnach beispielweise sieben HDDs ein, wäre eine NVMe für drei HDDs verantwortlich und die andere für vier. Das wirkt sich negativ auf die Leistung aus.

Beim Ausfall einer Cachedisk erfolgt auf diesem Server eine neue Zuweisung und der verbleibende Cachedatenträger übernimmt die Verantwortung für alle Kapazitätsdisks. Auch dies führt zu einer schlechteren Performance, allerdings ist dieser Zustand nicht von Dauer. Sobald der defekte Cache ersetzt ist, erfolgt eine erneute Zuweisung der Datenträger und jede Cachedisk kümmert sich wieder um die Hälfte aller Kapazitätsmedien.

Sie sollten bei der Planung eines S2D-Clusters weiterhin berücksichtigen, maximal 400 TByte an Bruttospeicherplatz pro Server einzuplanen. Technisch ist zwar mehr möglich, allerdings erhöht sich dadurch die Anzahl neuer Synchronisierungen nach einem Serverneustart oder einem ungeplanten Ausfall. Der gesamte Speicherplatz im Cluster, das heißt die Größe aller Datenträger aller Server, sollte 4 PByte nicht überschreiten. Hier stellt sich allerdings auch die Frage, ob Sie dann nicht besser zwei oder drei kleinere Systeme planen und betreiben. Dies reduziert die Abhängigkeit von einem Mega-Cluster, auch wenn Sie dadurch mehr Verwaltungsaufwand haben.

Kommen wir nun dazu, wie Sie sich vor einem Hardwareausfall schützen, wie Sie die Daten im Cluster verteilen und mit welchen Maßnahmen das System versucht, Synchronisierungen zu optimieren und Ausfälle möglichst schnell zu kompensieren. Beim Erstellen von Laufwerken – sogenannten virtuellen Datenträgern (vDisks) – im S2D-Cluster haben Sie die Wahl zwischen mehreren Layouts hinsichtlich der Ablage der Datenblöcke. Dabei unterscheiden wir grundsätzlich zwischen einer Spiegelung ("Mirror") und einer Parität ("Parity" beziehungswiese "Erasure Coding"). Die Nutzung einer vDisk ohne einen Ausfallschutz wäre auch denkbar. Da dies aber in produktiven Umgebungen nicht zu empfehlen ist, ignorieren wir dieses Szenario. Denn hierbei würden wie bei RAID-0 beim Ausfall eines einzelnen Datenträgers alle Daten unwiderruflich verloren gehen.

Die Spiegelung legt die Datenblöcke mehrfach ab. Das Prinzip ähnelt RAID-1, ist aber flexibler. Ein S2D-Cluster verteilt die gespiegelten Datenblöcke grundsätzlich über die Server, das bedeutet, dass zwei identische Blöcke niemals auf den Platten eines Servers landen. Sie haben hierbei die Wahl zwischen den Spiegel-Varianten "Two-Way-Mirror" und "Three-Way-Mirror". Die Zwei-Wege-Spiegelung schreibt und speichert jeweils zwei Kopien aller Daten. Dies führt dazu, dass die Hälfte des Speicherplatzes netto zur Verfügung steht, die andere Hälfte enthält die gespiegelten Daten. Voraussetzung für diese Konfiguration sind zwei oder mehr Server im Cluster.

Mit einem Drei-Wege-Spiegel legen Sie die Informationen drei Mal ab. Dies erhöht die Resilienz gegenüber Hardwareausfällen (und -wartungen), verringert den Nettospeicherplatz allerdings auch auf ein Drittel des gesamten Storage. Da die Daten in jeweils einem eigenen Server liegen müssen, sind für dieses Speicherlayout mindestens drei Server im Cluster notwendig.

In der Praxis vertreten IT-Verantwortliche oft die Auffassung, dass ein Drei-Wege-Spiegel nicht notwendig ist und sie präferieren deshalb einen Zwei-Wege-Spiegel. Hierbei gilt es allerdings einiges zu bedenken, da es sich bei einem S2D-Cluster um einen Verbund von Servern handelt, die regelmäßiger Wartung, Updates und Neustarts bedürfen. Und ein Reboot unterbricht das Spiegeln der Daten. Zwar ist das eine geplante Unterbrechung des Betriebs, beeinflusst aber dennoch die Ver- fügbarkeit des Speichers.

Wenn Sie bei einem Zwei-Wege-Spiegel (bestehend aus zwei Servern) einen der beiden Knoten geplant neustarten, arbeitet das andere System in diesem Moment zwar weiter, es gibt allerdings keinen Schutz vor dem Ausfall eines Datenträgers. Während dieser Wartung des ersten Systems darf kein einziger Datenträger im zweiten System wegbrechen, ansonsten kommt es zu einer ungeplanten Downtime und einem (temporären) Ausfalls des Speichers. Um dies zu umgehen, hat Microsoft den Drei-Wege-Spiegel geschaffen. Bei dieser Variante kann ein Server geplant in Wartung gehen, während die verbleibenden Systeme weiterhin die Daten spiegeln. Sollte es während dieser geplanten Wartung zu einem ungeplanten Ausfall von einem Datenträger in Server 2 oder 3 kommen, sind die Daten nicht sofort weg und bleiben ohne Unterbrechung oder Ausfall nutzbar.

Mit Windows Server 2019 hat Microsoft erstmals ein zusätzliches Spiegel-Layout namens geschachtelte Resilienz (Nested Resiliency) implementiert, das auch bei zwei Knoten eine hohe Ausfallsicherheit bietet. Dieses Setup bedient sich ebenfalls einer Spiegelung der Daten und sorgt für eine hohe Widerstandskraft gegenüber Hardwareausfällen. Wichtig für Ihre Planung ist, dass Nested Resiliency ausschließlich mit zwei Knoten möglich ist. Die Daten legt dieses Verfahren sowohl lokal redundant ab als auch parallel auf den zweiten Server via Synchronisierung. Das bedeutet, dass von jedem Block insgesamt vier Kopien vorhanden sind: zwei Kopien auf zwei unterschiedlichen Datenträgern auf Server A und zusätzlich auf zwei weiteren (unterschiedlichen) Datenträgern auf Server B. So ist gewährleistet, dass auch bei einer Downtime von einem der beiden Knoten mindestens ein weiteres Speichermedium im anderen System ausfallen kann, ohne dass es zu einem Datenverlust und einer Downtime kommt. Der Nachteil bei dieser Variante ist, dass nur 25 Prozent des gesamten Storage netto zur Verfügung stehen, da die Spiegel-Daten die restlichen 75 Prozent beanspruchen. Dennoch kann es, weil für einen dritten Server Hardware- und Lizenzkosten anfallen, trotzdem günstiger sein, Nested Resiliency zu nutzen anstelle eines dritten Servers.

Für welche Art von Spiegelung Sie sich letztendlich entscheiden, hängt von dem Einsatzzweck und den Kosten ab. Wenn Sie mit Virtualisierung arbeiten und VMs auf den Hosts laufen beziehungsweise der Speicher per SMB3 für andere Cluster freigegeben ist, sollte immer ein Spiegel verwendet werden, da dies die größtmögliche Performance aus den genutzten Datenträgern holt.

Als Alternative zur Spiegelung bietet Ihnen ein S2D-Cluster auch vDisks mit einer Parität. Diese kommt in den Geschmacksrichtungen "Einzelparität" und "Duale Parität" daher. Die Einzelparität (Single Parity) ähnelt RAID-5 und Sie benötigen hierbei mindestens drei Server, da die Daten über mindestens drei unterschiedliche Knoten zu verteilen sind. Dieses Setup schützt Sie vor dem Ausfall eines Servers – nicht mehr. Fällt gleichzeitig ein Server und ein weiterer Datenträger in einem der anderen Knoten aus, haben Sie einen Datenverlust und müssen ein Backup einspielen. Microsoft unterstützt dieses Szenario grundsätzlich, weist aber in der Dokumentation mehrere Male darauf hin, dass von einer Nutzung abgeraten wird, da das Risiko zu hoch ist. Wenn Sie mit drei Knoten arbeiten möchten, sollten Sie stattdessen die Anzahl beziehungsweise die Größe der Datenträger erhöhen und mit einem Drei-Wege-Spiegel arbeiten.

Die Dual Parity fordert mindestens vier Knoten, das Layout ist vergleichbar mit RAID-6. Rechnerisch stehen in RAID-6 von vier Festplatten zwei für die Speicherung von Daten zur Verfügung, die anderen beiden beherbergen die Paritätsinformationen. Dual Parity handhabt dies recht ähnlich, außer dass die Daten und Paritätsinformationen über die unterschiedlichen Server verteilt lagern. Bei den minimal vier Knoten haben Sie so eine nutzbare Kapazität von 50 Prozent. Erhöht sich die Anzahl der Knoten, steigt auch der nutzbare Storage (bis maximal 80 Prozent). Bedenken sollten Sie immer, dass jede Parität, egal ob "Single" oder "Dual", CPU-Zeit benötigt, was dieses Verfahren grundsätzlich langsamer macht als die Spiegelung. Bei einem Spiegel müssen die Daten stumpf zwei oder drei Mal kopiert werden. Daher sollten Sie genau abwägen, ob der etwas größere Nettospeicherplatz bei einem Parity-Layout es wert ist, dass die virtuelle Infrastruktur insgesamt langsamer läuft.

Neben den beiden Paritäts-Varianten gibt es noch eine Mischform von Spiegelung und Parität, den "Paritätsdatenträger mit einer Beschleunigung per Spiegelung" ("Mirror-accelerated parity"). Eingehende Daten landen, ähnlich dem Caching und Tiering, erst im Mirror-Bereich und wandern nachträglich in den Parity-Bereich. Für Dual Parity in Kombination mit einem Three-Way-Mirror benötigen Sie minimal vier Server. Die zu erwartende Performance hängt sehr davon ab, wie groß der jeweilige Anteil der unterschiedlichen Speicherbereiche ist. Je größer der Spiegel-Bereich ist, desto mehr Leistung können Sie erwarten. Andererseits wird Ihnen eine geringere Leistung aufgrund eines kleineren Spiegel-Bereichs mit der besseren Ausnutzung des gesamten Storage versüßt. Auch hier betont Microsoft in der Dokumentation erneut, dass Performance-intensive Workloads unbedingt auf ein Spiegel-Layout setzen sollten.

Spiegelung und Parität sorgen dafür, dass die darauf gespeicherten Daten auch bei einem Serverneustart weiterhin verfügbar sind. Neben einem geplanten Reboot kann jedoch ein Datenträger unerwartet kaputt gehen und muss ausgetauscht werden. Dies hat einen "degraded"-Zustand ("heruntergestuft") im Storage-Pool zur Folge. Die Redundanz über die Server hinweg sorgt zwar dafür, dass es nicht zu einem unmittelbaren Ausfall kommt, trotzdem fehlt dem Cluster jetzt ein Speichermedium.

Diesem Zustand treten RAID-Systeme häufig mit einem "Hot-Spare"-Datenträger entgegen, der nicht aktiv Daten speichert, aber grundsätzlich online ist. Bei einem Ausfall bindet das Storage den Hot-Spare-Datenträger aktiv ein und er übernimmt die Rolle des ausgefallenen Mediums. Die ausgefallenen Blöcke werden aus den Kopien auf den ehemaligen Hot-Spare-Datenträger kopiert und danach ist das RAID wieder voll funktionsfähig. Dieses Verfahren hat Microsoft etwas anders implementiert, da es ein paar Nachteile birgt. Denn dadurch, dass ein einzelner Datenträger leer als neues Gerät in das RAID kommt, müssen alle Daten auf diesen kopiert werden. Je nach Speichertyp dauert dies sehr lange und selbst bei einer Datentransferrate von 250 MByte/s braucht eine 12 TByte große Festplatte unter optimalen Bedingungen mehr als zwölf Stunden für diesen Vorgang. Ein anderes Problem, insbesondere bei drehenden Festplatten, ist, dass Hot-Spares teilweise über Jahre nicht genutzt werden. Fällt also eine Platte aus, muss der Hot-Spare-Datenträger innerhalb kurzer Zeit vom Idle- in den Volllast-Betrieb wechseln. Bei dieser Belastung fällt nicht selten die Hot-Spare-Platte ebenfalls aus.

Um dies zu verbessern, macht sich Microsoft die Eigenschaft von freiem Speicherplatz zu Nutze. Der S2D-Cluster nimmt alle Datenträger in einen Storage-Pool auf und danach entstehen die virtuellen Datenträger. Hier sollten Sie als Faustregel pro Knoten die Kapazität eines Datenträgers freilassen und nicht verwenden. Bei zum Beispiel vier Platten pro Server (und zwei Knoten) mit einer Kapazität von jeweils 3,84 TByte sollten Sie 7,68 TByte im Speicherpool ungenutzt lassen. Kommt es zum Ausfall eines Datenträgers, lassen sich die ausgefallenen Blöcke aus dem Partnersystem auf dem verbleibenden Speicherplatz wiederherstellen. Dies hat mehrere Vorteile:

- Die Spiegelung der vDisks lässt sich zeitnah vollständig reparieren, auch wenn der Ausfall in der Nacht oder am Wochenende passiert.

- Da das Recovery auf alle verbleibenden Datenträger im gleichen Server geschieht, ist dies deutlich schneller als ein Recovery auf eine einzelne Festplatte. Je mehr Speichermedien Sie verwenden, desto schneller ist die Reparatur.

- Die Reparatur findet grundsätzlich automatisch statt, Sie müssen hier nicht manuell eingreifen oder den Vorgang per Hand starten.

Die Größe des freien Speicherplatzes ist nicht beschränkt auf die Kapazität einer Disk pro Server, Sie können auch zwei oder mehr Platten ungenutzt lassen. Je mehr freien Speicherplatz Sie haben, desto mehr Ausfälle lassen sich kompensieren, ohne dass Sie zwingend Festplatten tauschen müssen. Dies kann beispielsweise dann interessant sein, wenn Sie einen S2D-Cluster an einem Standort betreiben, der nur sehr schwierig erreichbar ist oder an dem nur unregelmäßig Techniker vor Ort sind.

Mit dem Ende des ersten Workshopteils haben wir ein klares Bild der Storage-Optionen für S2D. Ist das geeignete Layout gewählt, folgt das ebenfalls anspruchsvolle Anbinden an das Netzwerk in der Oktober-Ausgabe.