NVMe (Non-Volatile Memory Express) ist ein Flash-Storage-Protokoll, das viel vom Overhead traditioneller Protokolle wie SAS und SATA beseitigt. Das führt zu wesentlich geringerer Latenz und erhöht den Durchsatz für Solid-State-Disks und Storage Class Memory. Natives NVMe wird über den PCIe-Bus angebunden und in den Unternehmen inzwischen als Standard für lokalen persistenten Speicher betrachtet. Hersteller beginnen jetzt, Produkte wie NVMe over Fabrics (NVM-oF) zu entwickeln, mit denen NVMe auch über ein Netzwerk funktioniert.
Bisher wurde NVMe auf Fibre Channel (FC-NVMe), Ethernet (mit RoCE) und InfiniBand implementiert. FC-NVMe arbeitet über das vorhandene Fibre-Channel-Equipment. Allerdings braucht man dazu aktuelle Hardwarerevisionen mit neuer Firmware und entsprechenden Treibern.
Ethernet erfordert besondere Hardware-Adapter, die RDMA-over-Ethernet unterstützen. Allerdings gibt es inzwischen mit NVMe-over-TCP eine praktische Methode, NVMe auch über ein Standard-Ethernet und NICs einzusetzen.
Wie bei jeder Storage-Technologie hat mehr Geschwindigkeit ihren Preis. Die heutigen modernen Applikationen, beispielsweise aus dem Finanzbereich oder der Datenanalyse, benötigen skalierbares Storage mit niedriger Latenz.
Einige Start-ups bieten hier Lösungen an, die ihren Kunden einen echten geschäftlichen Vorteil bieten. Sie passen zu deren täglicher Herausforderung, Kosten zu senken und die Leistung der vorhandenen Applikationen zu erhöhen.
Die Vorteile von NVMe
Natürlich muss man bei der Einführung einer neuen Technologie einige der marktüblichen technischen Herausforderungen überwinden. Es wäre relative einfach, NVMe in bestehende Produkte einzubauen. Tatsächlich gibt es Hersteller, die das tun. Allerdings bietet sich NVMe geradezu dafür an, neue Lösungen damit zu entwickeln. Denn NVMe-Laufwerke können beispielsweise verglichen mit SCSI in SAS- und SATA-Drives die I/O besser parallelisieren.
Zudem adressiert NVMe zusammen mit SCM (Storage Class Memory) wie Intel Optane gespeicherte Daten in Bytes statt Blocks.
Die Herausforderungen von NVMe
Welche Herausforderungen ergeben sich in den existierenden Storage-Architekturen auf Basis von NVMe? Ganz vorn steht hier die Notwendigkeit, die gesamte I/Os durch gemeinsam genutzte Controller zu leiten.
Der Controller kann logische Storage-Zuweisungen wie ein LUN oder ein Dateisystem auf das physische Medium projizieren. Er speichert die Metadaten, mit denen Datendienste wie Deduplizierungs, Kompression und Snapshots implementiert werden.
Aber Controller erzeugen auch zusätzliche Verarbeitungszeit und werden zum Flaschenhals, weil sie die I/Os in beide Richtungen durch einen schmalen Durchlass kanalisieren müssen. Zudem müssen mehrere NVMe-Drives parallel adressiert werden. Klassische Storage-Architekturen verwenden normalerweise SAS als Anbindungsprotokoll für Backend-Storage. Das bedeutet hohe Skalierbarkeit, denn viele Laufwerke können in einem System gebündelt werden. Doch das Protokoll unterhält nur eine einzige Warteschlange pro Drive, die dann die Gesamtleistung des Systems limitiert.
In diesem Szenario ist es auch nicht besonders sinnvoll, viele NVMe-Laufwerke in einen einzigen Server zu integrieren. Denn alle NVMe-Drives verwenden den PCIe-Bus. Das bedeutet, dass sehr viel weniger Drives in einen einzelnen Server eingebaut werden können. Abhilfe versprechen hier NVMe-SSDs mit Multi-Terabyte-Volumen.
Wie haben sich nun die Architekturen weiterentwickelt, um optimal von NVMe zu profitieren? Es folgen einige Beispiele für entsprechende Technologien und ihre Umsetzung in Produkte.
NVMe-Option 1: Den Controller eliminieren
Weil der Controller ein Engpass ist, eliminieren ihn einige Hersteller. Ohne den engen Trichter für die I/Os können Server direkt auf das Laufwerk schreiben oder davon lesen und dabei die I/O-Kapazitäten des Laufwerks selbst optimal nutzen.
Disaggregierte Architekturen, die diesen technologischen Ansatz nutzen, stammen beispielsweise von Start-ups wie Apeiron und E8 Storage.
In deren Produkten spricht die Host-Applikationsserver direkt mit den Medien und braucht daher keine zentralen Controller. Der Nachteil: Der Controller erfüllt innerhalb von gemeinsam genutzten Storage-Systemen durchaus wertvolle Aufgaben, die hier anderweitig erledigt werden müssen.
E8 ist ein 2014 in Tel Aviv, Israel, gegründetes Unternehmen, dessen CEO aus IBMs XIV-Gruppe stammt. Die Produkte von E8 werden in Deutschland über Memory Solution und 2Stor vertrieben. Die Technologie des Startups speichert Metadaten auf einem speziellen Server, auf den alle Hosts zugreifen können. Etwas Rechenleistung wird auf jedem Host benötigt, um die Metadaten lokal zu verwalten. Sie könnte zukünftig durch SmartNICs mit integriertem Processing ersetzt werden, die das Metadaten-Management auf den RDMA-NIC verlagern.
Apeiron, ein 2013 gegründetes Startup aus Sacramento, hat die Storage-Appliance ADS1000 entwickelt. Sie ermöglicht Host-Servern mit Standard-NICs, Drives im 2U-Chassis direkt anzusprechen. Dadurch müssen Datendienste auf dem Host-Layer implementiert werden. Doch das führt nur zu einem zusätzlichen Zeitbedarf zwischen 2 und 3 µs.
NVMe-Option 2: Scale-Out-Architektur
Ein Scale-Out der Komponenten der Storage-Architektur und die Beseitigung jedes internen Engpasses ist eine zweite Methode, NVMe-SSDs gemeinsam zu nutzen. Dieses Technologie nutzen Vexata und Pavillion Data.
Vexata, gegründet 2013 in San Francisco, fokussiert sich auf geschäftskritische Tier-1-Applikationen wie Oracle oder MS-SQl und deren Datenbedürfnisse. Der CEO, Zahid Hussain, stammt von Dell EMC. 2017 kam Vexatas Active Data Fabric auf den Markt. Vexatas Architektur skaliert die Frontend-Connectivity und das Storage auf der hinteren Systemseite unabhängig voneinander. Die Frontend-I/O-Controller (IOCs) sind über eine Ethernet-Midplane mit den Enterprise Storage Modulen (ESM) verbunden. Die Metadaten über die Nutzung des Storage werden auf den ESMs und in DRAMs auf den IOCs gehalten. Die Verarbeitungskapazität kann durch Hinzufügen neuer ESMs oder IOCs nach Anforderung erweitert werden.
Welche Herausforderungen ergeben sich in den existierenden Storage-Architekturen auf Basis von NVMe? Ganz vorn steht hier die Notwendigkeit, die gesamte I/Os durch gemeinsam genutzte Controller zu leiten.
Pavillion Data, 2014 gegründet von Gurpreet Singh, vormals Pure Data, und ebenfalls im Bay Area ansässig, hat sein erstes Produkt, Pavillion Memory Array, das auf NVMe-oF basiert, auf den Markt. Ein 4U-Chassis fast zwischen zwei und 20 Controller und bis zu 72 NVMe-SSDs. Jeder Controller hat vier 100-GbE-Host-Connections Die Verbindungsleistung lässt sich durch das Hinzufügen weiterer Controller, die Speicherleistung durch mehr Drives erhöhen. Die Metadaten werden auf zwei redundanten Management-Karten verwaltet.
Für die Kunden ist es günstig, dass sie vorhandene NVMe-Medien zertifizierter Hersteller in dem System weiterverwenden können. Die Preise von Pavillion Data basieren auf einem Subskriptionsmodell, das Wartung, Support und Software bündelt und nicht auf Kapazitäten beruht.
NVMe, Option 3: Softwaredefinierte Lösung
Neben diesen neuen Hardwaredesigns gibt es auch einige Start-ups, die den Weg zu Software-definierten Lösungen beschritten haben und die damit Storage-Hardware ganz aus ihrem Produkt eliminieren. Beispiele sind Excelero und WekaIO.
Natürlich steckt auch in Architekturen auf Basis solcher Lösungen irgendwo Storage-Hardware. Der Vorteil einer softwaredefinierten Architektur ist, dass sie entweder auf hyperkonvergenter Infrastruktur (HCI), auf dediziertem Storage oder auf einer Public Cloud implementiert werden kann.
Exceleros Storage-Lösung heißt NVMesh. CEO und Mitgründer Lior Gal sammelte, bevor er 2014 Excelero gründete, unter anderem Erfahrungen bei EMC und war zuletzt bei Data Direct Networks tätig. Die Produkte des Start-ups werden in Deutschland beispielsweise von 2Stor angeboten.
NVMesh implementiert NVMe-oF mittels eines proprietären und patentierten Protokolls, RDDA (Remote Direct Drive Access). Anders als RDMA, das mehrere Server verbindet und so direkten Speicherzugriff ermöglicht, geht RDDA weiter: Hier sind NVMe-Storage-Devices über das Netz zugänglich. Das wird erreicht, ohne den Prozessor des Target-Servers zu benutzen. So entsteht eine hochskalierbare Lösung, die in verschiedenen Konfigurationen einschließlich HCI implementiert werden kann.
WekaIO Matrix ist ein Scale-Out-Filesystem, das über mehrere geclusterte Server bereitgestellt wird. Matrix kann auf Tausende Knoten skalieren und Milliarden Files beherbergen. Die Matrix-Architektur ermöglicht direkte Kommunikation mit NVMe-Medien und NICs. Dabei wird der Linux-I/O-Stack weitgehend umgangen.
Die Applikationen nehmen Matrix wie ein lokales Filesystem wahr, obwohl die Daten mittels eines prorpietären Erasure-Coding-Schemas namens DDP (Distributed Data Protection) über viele Knoten verteilt und dadurch geschützt werden.
Matrix läuft auch auf virtuellen Instanzen in der Public Cloud (derzeit in AWS), die lokale NVMe- oder SSD-Storage unterstützen.
Die beiden Gründer des 2014 aus der Taufe gehobenen Unternehmens arbeiteten schon vor der Übernahme durch IBM bei XIV.
Zukünftige Entwicklungen bei NVMe
Die bislang diskutierten Systeme und Technologien nutzen Ethernet/RDMA, InfiniBand oder Fibre Channel, um Storage und Applikationsserver zu vernetzen.
NVMe/TCP ist der nächste Entwicklungsschritt von NVMe-oF. Damit lässt sich schnelles Storage mit mehr Commodity-Hardware implementieren.
Wahrscheinlich wird man deshalb mehr Start-ups in diesem Bereich sehen. Denn die Technologie wird gebraucht, um breiter einsetzbare Lösungen zu bauen.
