Einsatz des SSD-Tiering bei den Storage Spaces bei Server 2012 R2

18. November 2013

Im Zuge des Windows Server 2012 Release 2 (R2) sind bei den Storage Spaces zwei Schlüsseltechnologien dazu gekommen: Das Tiering durch das Trennen von Festplatten- und SSD-Speicher (Solid State Disk) in einem Speicherpool und der „Write-Back Cache“. Für Anwender stellt sich die Frage, welche Option sie für ihre Anwendungen benutzen sollen.

Bild 2. Auch das Argument „Stromverbrauch pro 100.000 IOPS“ spricht eindeutig für SSD-Umgebungen. Quelle: OCZ Technology

Die Vorteile von Konsumenten-SSDs im Vergleich zu magnetischen Festplatten sind allgemein bekannt: SSDs steigern die Leistungs- und Reaktionsfähigkeit von Notebooks und PC-Systemen und erhöhen somit die Produktivität. Durch den geringeren Stromverbrauch von SSDs erhöht sich die Akkulaufzeit für mobile Geräte. Da SSDs ohne mechanische, bewegliche Bauteile auskommen, sind sie zuverlässiger und reduzieren damit auch die oft notwendige teure und zeitintensive Wartung.

Mit den Enterprise-Solid-State-Drives (Enterprise SSDs) kommen speziell für den Einsatz in Servern konzipierte SSD-Konfigurationen zum Einsatz. Neben den allgemein gültigen Vorteilen bezüglich Zuverlässigkeit und Wartung bieten Enterprise SSDs maximierte Bandbreite und IOPS (In/Output per Second). SSDs sind im Vergleich zu Festplatten energieeffizienter, benötigen weniger Kühlung  und senken damit die Betriebskosten (OPEX).

SSD-Technologien

Derzeit dominieren drei  Solid-State-Storage-Technologien den Markt: Single-Level-Cell (SLC), Multi-Level-Cell (MLC) und Enterprise Multi-Level-Cell (eMLC). Die Variante „Triple-Level-Cell“ (TLC) können wir derzeit noch vernachlässigen. Eine SLC-Speicherzelle speichert genau ein Bit, eine MLC mehr als ein Bit pro Zelle. Das Abspeichern von mehreren Bits pro Speicherzelle hat den Nachteil, dass die Lese- und Schreibgeschwindigkeit reduziert wird und sich bei einem Ausfall der Zelle die Bitfehlerrate erhöht. Der wesentliche Vorteil ist im Gegenzug die höhere Speicherdichte, da hier mehr als ein Bit pro Zelle abgespeichert wird.

So kann auf der gleichen Chipfläche die doppelte (oder noch höhere) Informationsmenge gespeichert werden als bei der Single-Level-Speicherung. Insbesondere bei Halbleiterspeichern bietet dies erhebliche Preisvorteile gegenüber SLC, da die benötigte Chipfläche bei der Herstellung ein wesentlicher Kostenfaktor ist. So sind SLC-Chips zwar kostenintensiver, benötigen jedoch weniger Strom, übertragen Daten etwas schneller und sind insgesamt langlebiger als MLCs.

Bei der Enterprise MLC handelt es sich um eine besondere Art der Multi-Level-Cell-SSD. Diese NAND-Speicherart dient im Enterprise-Segment als Kompromiss zwischen kostengünstigen MLC-SSDs und teuren, leistungsstarken SLC Solid State Drives. Sie wurde für Enterprise-Anwendungen konzipiert und unterscheidet sich von den Consumer-SSDs mit MLC-Technologie, indem sie mehr Schreibzyklen abarbeiten kann.

Eine herkömmliche MLC-SSD hat eine Lebensdauer von etwa 3.000 bis 10.000 Schreibzyklen, eMLC-SSDs können 20.000 bis 30.000 Schreibprozesse und SSDs mit SLC sogar bis zu 100.000 P/E-Zyklen verarbeiten. Dabei arbeitet eMLC mit nur 2 Bits, während normale MLC-Drives mit 3 oder 4 Bits operieren. Je weniger Bits verarbeitet werden, desto mehr Schreibzyklen schafft die SSD. Im Mainstream-Segment haben sich MLC-SSDs durchgesetzt. eMLC und SLC-Varianten sind dagegen ideal für Server oder Hochleistungsrechner.

Bild 2. Auch das Argument „Stromverbrauch pro 100.000 IOPS“ spricht eindeutig für SSD-Umgebungen. Quelle: OCZ Technology

SSD-Tiers bei den Storage Spaces

Werden zum Beispiel bei einem Windows Server 2012 R2 Speicherblöcke häufig benutzt, sollte man sie am besten auf SSD-Laufwerken – also auf dem „SSD Tier“ ablegen. Dieser Mechanismus wird als SSD-Tiering bezeichnet. Dabei lassen sich auf Dateien explizit auf der SSD-Ebene „verewigen“, sprich sie werden immer auf SSD-Laufwerken abgelegt. Das verspricht für die Anwendungen dann die größtmögliche Performance.

Um das SSD-Tiering nutzen zu können, muss mindestens so viel SSD-Speicherkapazität (eventuell auf mehreren SSD-Laufwerken verteilt) im Storage Pool vorliegen, um den gewünschten Speicherplatz für diesen Speichertyp unterstützen zu können. Das hört sich schwieriger an als es ist – wie das folgende Beispiel verdeutlichen soll: Soll ein Zweiweg-Spiegel erzeugt werden, müssen zumindest zwei SSD-Laufwerke mit der benötigten Kapazität im Einsatz sein. Bei einem Dreiwege-Spiegel müssen entsprechend drei SSD-Laufwerke mit der benötigten Kapazität vorliegen.

Beim Write-Back Cache handelt es sich um eine fest definierte Kapazität, die auf dem SSD-Speicher abgelegt ist, der im Storage Pool verfügbar ist. Der Write-Back Cache kommt zum Einsatz, wenn beim Schreibzugriff Lastspitzen auftreten und dann werden diese Daten nur im Write-Back Cache in der SSD Tier abgelegt. Damit vermeidet das System eine generelle Reduzierung der Performance, wenn derartige Lastspitzen auftreten.

Kombination der Technologien

Im Idealfall sollte man beide Technologien gemeinsam einsetzen und sich nicht auf einzelne Aspekte beschränken. Der Einsatz von SSD-Laufwerken im Tiering führt zu einer bestmöglichen Performance, wogegen der Write-Back Cache davor schützt, dass kurzfristige Lastspitzen auf die Performance durchschlagen.

Dieselben SSD-Laufwerke im Storage Pool lassen sich als Teil des SSD Tier und als Teil des Write-Back Cache  verwenden. Dazu darf man nur das Laufwerk nicht manuell als „Journal Drive“ konfigurieren.

Dateien in der SSD Tier der Storage Spaces festmachen

Um eine Datei in der SSD Tier bei den Storage Spaces ab Windows Server 2012 R2 festzuschreiben, kann der Administrator die Powershell von Windows verwenden. Im folgenden Beispielbefehl steht die Angabe $vd1 für eine virtuelle Disk in den Storage Spaces:

Set-FileStorageTier –FilePath -DesiredStorageStier ($vd1 | Get-StorageTier -MediaType SSD)

Nachdem die Datei derart behandelt wurde, wird eine Optimierung erzwungen: Die Datei wird sofort verschoben und es wird nicht darauf gewartet, wann die nächste Optimierung vom durch den Zeitplandienst angestoßen wird.

Aber Vorsicht bei dieser Aktion: Typischerweise werden die am häufigsten gebrauchten Blöcke sowieso auf die SSD Tier verschoben. Das gilt natürlich nur solange genügend Speicherbereich in der SSD Tier zur Verfügung steht. Daher muss man normalerweise kein manuelles Verschieben der Dateien in den SSD Tier vornehmen. Der Aufruf des Optimizers sieht wie folgt aus:

Optimize-Volume -DriveLetter E -TierOptimize

Setzen des Write-Back Cache bei den Storage Spaces

Wer darauf hofft, dass man den Write-Back Cache  bei den Storage Spaces über den Server Manager von Windows Server 2012 R2 konfigurieren kann, der wird enttäuscht sein: Standardmäßig kann man mit dem Server Manager zwar eine virtuelle Disk erzeugen, doch die bekommt immer nur eine Standardgröße von 1 GByte für den Write-Back Cache gespendet, sofern genügend Kapazität im SSD-Speicher-Pool existiert.

Wer seine eigenen Vorgaben für die Größe des Write-Back Caches durchsetzen möchte, der muss auf die Powershell-Cmdlets  für das Anlegen von virtuellen Festplatten zurückgreifen und dann über den Parameter „WriteCacheSize“ den passenden Wert angeben. Das sieht zum Beispiel wie folgt aus:

New-VirtualDisk -StoragePoolFriendlyName "My Storage Pool" -FriendlyName TieredSpace
-StorageTiers @($ssd_tier, $hdd_tier)
-StorageTierSizes @(50GB, 300GB)
-ResiliencySettingName Mirror
-WriteCacheSize 2GB

Allerdings darf man eines nicht vergessen: Nachdem eine virtuelle Disk erst einmal angelegt ist, kann man die Größe ihres Write-Back Cache nicht mehr ändern.

Rainer Huttenloher

Lesen Sie auch