luchschen_shutter - Fotolia
Disaggregierte Systeme setzen das Potential von NVMe frei
Disaggregierte Systeme umgehen den Engpass, den der I/O-Controller beim Einsatz von NVMe darstellt und leisten daher mehr, der Support wird aber komplexer.
Shared Storage-Arrays sind bis heute extrem erfolgreich und seit 30 Jahren eine Schlüsselkomponente der IT-Infrastruktur. Die Konsolidierung des Storages vieler Server auf einem Gerät bietet die Möglichkeit effizienterer Services, erhöht die Verfügbarkeit und senkt die Kosten.
Aber mit dem Aufkommen von Flash-NVMe zeigt sich, dass Shared Storage-Arrays technologisch veralten und in ihrer Leistung durch eine neue Welle disaggregierter Speicherprodukte übertroffen werden.
Um die grundlegende Ursache der Probleme mit Shared Storage zu verstehen, muss man die verwendeten Medien betrachten.
Erst vor kurzem haben schnellere Flash-Laufwerke (NAND) begonnen, Festplatten zu ersetzen. Doch bis dahin hat es viele Jahre gedauert.
Die Leistung einer einzelnen Festplatten sank nicht, wenn die I/O (Ein-/Ausgabe)-Anfragen auf einen oder mehrere Controller zentralisiert wurde, meist wurde sie sogar verbessert.
Mit anderen Worten: Die Hardware der Festplatten selbst bildete den I/O-Engpass. Die Controller stellten lediglich begehrte Funktionen zur Verfügung, die aber die Leistung zumindest nicht negativ beeinflussten.
Ein festplattenbasiertes Array hat Verzögerungszeiten zwischen fünf und zehn ms. Mit Flash ist es weniger als eine Millisekunde, und die Hersteller streben noch geringere Werte an. Die ersten All-Flash-Systeme basierten auf SAS/SATA-Laufwerken und entsprechenden Netzanbindungen.
Der nächste Medienwandel führt zu NVMe-Drives. Bei ihnen ist das I/O-Protokoll erheblich effektiver implementiert. Daher können traditionelle Array-Designs, die die I/O-Vorgänge durch einen oder mehrere zentrale Controller leiten, die aggregierte Leistung eines Shelfs mit NVMe-Medien nicht voll ausnutzen. Mit anderen Worten: Jetzt ist der Controller der Engpass im I/O-Pfad.
Den Controller-Engpass beseitigen
Um das volle Leistungspotential von NVMe zu entfalten, kann man diesen Engpass ganz einfach vollständig entfernen: Statt alle Ein- und Ausgaben durch einen zentralen Controller zu leiten, könnte das Client-System die Festplatten doch auch tatsächlich ansprechen.
Mit einem schnellen, verzögerungsarmen Netzwerk und direkter Anbindung an jedes Laufwerk eines Systems wird der Overhead, der durch die Passage gemeinsam genutzter Controller entsteht, beseitigt und der Wert von NVMe lässt sich vollständig nutzen.
Genau das streben einige neue Produkte an. Client-Server, auf denen Anwendungen laufen, sprechen direkt mit einem Shelf mit NVMe-Festplatten. Das Ergebnis: Die Verzögerung sinkt beträchtlich, und die Leistung erreicht sehr viel höhere Werte als bei traditionellen gemeinsam genutzten Systemen.
NVMe-Implementierung
Um ein disaggregiertes System aufzubauen, muss man den Daten- vom Kontrollpfad trennen. Bei zentralisierter Storage sind Steuerungs- und Datenpfad im Controller implementiert. Disaggregierte Systeme verlagern die Steuerung auf separate Infrastrukturelemente und/oder auf den Client selbst.
Diese Aufteilung der Funktionen hat den Vorteil, den Controller von I/O-Aufgaben zu entlasten. Allerdings leidet darunter das Management, da die Funktionen, die zentral ausgeführt wurden, immer noch erledigt werden müssen – nur woanders.
Der Client beschreibt die Blocks von Block 0 bis zur höchsten verfügbaren Blocknummer, je nach Blockgröße und Kapazität der LUN. Die Controller in Storage sind verantwortlich dafür, die logischen Adressen mit einer physischen Lokation auf dem Storage-Medium zu assoziieren.
Wenn dann Daten durch den gemeinsam genutzten Controller fließen, wird der Datenblock dedupliziert, komprimiert, geschützt (durch RAID oder Erasure Coding beispielsweise) und einer oder mehreren physischen Lokationen auf dem Storage zugewiesen. Fällt ein Laufwerk aus, stellt der Controller die verlorenen Daten wieder her. Wird eine neue LUN erstellt, reserviert der Controller den Raum in den Metadaten und mit der Nutzung der LUN physisch auf den Festplatten oder Flash.
In disaggregierten Systemen müssen diese Funktionen noch immer ausgeführt werden. Im Allgemeinen werden sie dafür an den Client delegiert. Die Client-Server müssen dafür die Metadaten und die Daten sehen und beide koordinieren, um einen glatten Ablauf sicherzustellen und Datenkorruption zu vermeiden.
Warum disaggregieren?
Die Einführung von NVMe verspricht große Leistungssteigerungen.
In bestimmten Applikationen ist eine geringe Verzögerung essentiell, aber ohne zu disaggregieren, kann man eine verzögerungsarme Applikation nur implementieren, indem man im Client-Server selbst Storage einbaut. NVMe- Flash-Laufwerke bieten eine sehr geringe Verzögerung, NVMe-Optane-Laufwerke von Intel leisten sogar noch mehr.
Unglücklicherweise ist es nicht kosteneffizient und skaliert auch nicht, Storage wieder in den Servern zu implementieren. Schließlich war das der Grund, warum überhaupt gemeinsam genutztes Storage entstand. Zu disaggregieren ist ein Mittelweg: Vorteilhaft daran ist, dass Medien konsolidiert werden und Storage (scheinbar) lokal bereitsteht, um die höchstmögliche Leistung aus den Medien herauszuholen.
Zu den Anwendungen, die geringe Verzögerungszeiten dringend brauchen, gehören Finanz- und Börsenhandel, Echtzeit-Datenanalyse und große Datenbanken, wo die Transaktionsleistung direkt von der Verzögerung der individuellen I/O-Vorgänge abhängt.
Hier gibt es eine Analogie zu den frühen Stadien der Flash-Implementierung: Damals wurden alle Flash-Arrays im Unternehmen für die Applikationen verwendet, die man nur mit viel finanziellem Aufwand neu hätte schreiben können oder die ganz einfach mit keinem anderen Mittel als geringeren Verzögerungszeiten zu beschleunigen waren.
Die ersten Implementierungen disaggregierter Systeme werden nur die Applikationen betreffen, die davon am meisten profitieren. Denn die Architektur hat auch einige Nachteile.
Kompromisse
Wie oben bereits dargestellt, haben je nach Applikation die Client-Server in disaggregierten Systemen viel mehr Arbeit zu leisten. Sie müssen die Metadaten auf aktuellem Stand halten und Kalkulationen wie die von RAID oder Erasure Coding durchführen, komprimieren und deduplizieren.
Der Support ist auf bestimmte Betriebssysteme begrenzt und kann auch verlangen, dass neue Kernel-Treiber oder anderer Code geschrieben wird, durch die wiederum Abhängigkeiten vom Betriebssystem und/oder der Applikation entstehen. Die meisten Systeme verwenden Hochleistungsnetzwerke wie InfiniBand oder 40Gb-Ethernet mit kundenspezifischen NICs (Network Interface Cards).
Das verteuert die Systeme und bedeutet Herausforderungen für den Support, so lange diese Technologie im Unternehmen noch neu ist. Wie bei jeder Technologie müssen Unternehmen entscheiden, ob die Vorteile disaggregierter Systeme schwerer wiegen als die Support- und Kostenfragen.
Zudem steht noch nicht endgültig fest, nach welchen Standards die Systeme arbeiten werden. NVMe über ein Netzwerk wie Ethernet oder Infiniband oder NVMe over Fabrics (NVMeF) wurden von der NVM-Express-Organisation bereits definiert. Dazu gehört der Einsatz physischer Transportmedien wie Ethernet oder Infiniband mit Zugangsprotokollen wie RDMA (Remote Direct Memory Access) over Converged Ethernet (RoCE) und Internet Wide-Area RDMA Protocol (iWarp). Sie alle bieten dem Client-Server direkten Storage-Zugriff auf einzelne Laufwerke aus dem Hintergrund.
Einige Anbieter in unserer zusammenfassenden Darstellung haben bereits ihre eigenen Implementierungen vor der Ratifizierung irgendwelcher Standards auf den Markt gebracht.
Einige NVMe-Systeme unterschiedlicher Hersteller
DVX ist ein disaggregiertes Storage-System von Datrium. Das Unternehmen beschreibt sein Angebot als „offen konvergent“ und nutzt ein Modell, bei dem gemeinsam genutztes Storage und DRAM oder Flash Cache in jedem Client-Server stecken. Das Unternehmen nennt einige beeindruckende Leistungszahlen. Danach erreichen 10 Datrium-Daten-Nodes und 60 Client-Server einen IOmark-VM-Score von 8.000. IOmark ist ein Set herstellerunabhängiger Storage-bezogener Workload- oder Applikations-Benchmarks für virtualisierte Serverumgebungen.
E8 Storage offeriert Modelle mit einem oder zwei Controllern. Das Modell E8-D24 mit zwei Controllern bietet RAID-6-Schutz über 24 Laufwerke, das Modell E8-S10 implementiert RAID-5 über zehn Laufwerke. Beide Systeme nutzen bis zu 100 GbE mit RoCE und erreichen bis zu 10 Millionen IOPS (Ein-/Ausgabeoperationen pro Sekunde) bei einem Durchsatz von 40 GBps. E8 hat auch reine Softwarelösungen im Programm. Sie eignen sich für Kunden, die ihre eigene Hardware verwenden wollen. Wichtig zu wissen ist, dass bei der Implementierung mit zwei Controllern die Metadaten redundant sind.
Aperion Data Systems bietet ein Scale-Out-System auf Basis eines NVMe-Laufwerks-Shelfs mit 24 Laufwerken. Client Servers werden mit 40 GbE angebunden. Apeiron nennt Leistungsdaten von 18 Millionen IOPS pro Shelf/Array und eine aggregierte Leistung von 142 Millionen IOPS mit acht Shelves. Die Verzögerungszeiten lieben mit MLC (Multilevel Cell)-Flash nur bei 100 µs und bei 12 µs mit Optane-Laufwerken.
Die Plattform von Excelero heißt NVMesh. Diese Software wird über mehrere Client-Server hinweg implementiert. Jeder Client-Server kann innerhalb einer vermaschten Architektur, die über Ethernet oder Infiniband und ein proprietäres Protokoll namens RDDA verbunden ist, Storage verbrauchen oder bereitstellen. Systeme lassen sich im disaggretiertem Modus mit dediziertem Storage oder als konvergentes System zur Verfügung stellen. Die Leistungsdaten: Die Verzögerung liegt bei nur 200 µs, die Lösung erreicht 5 Millionen IOPS und 24 GB/s Bandbreite.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
