Computational Storage bringt Rechenleistung zu den Daten

Das neue Marktsegment Computational Storage ist noch in einem frühen Stadium und sehr dynamisch. Neue Hersteller wie Eideticom, Scaleflux und NGD bestimmen derzeit das Bild.

Der Mikroprozessor hat Rechenleistung allgemein verfügbar gemacht. Immer mehr Geräte werden intelligent und programmierbar. Die Datenverarbeitung rückt in den meisten Geräten näher an die Datenquelle heran. Das gilt für PCs, Smartphones, Industriesensoren und Überwachungskameras. Doch es gibt eine Ausnahme: das Rechenzentrum.

Seit x86-Systeme das Mainframe-Monopol durchbrochen haben, hört die Applikationsverarbeitung am Server auf. Sicher, Hardware wie Netzwerk-Switches und Storage-Arrays haben rechenstarke CPUs. Aber bis auf wenige Ausnahmen arbeiten sie nur mit dem eingebetteten Code, andere Applikationen laufen dort nicht.

Die GPU (Graphic Processing Unit) änderte das. Sie beschleunigt Machine- und Deep-Learning-Algorithmen und fördert den Einsatz einer neuen Generation von KI-Applikationen. Nun stehen wir an der Schwelle einer weiteren großen Veränderung in Richtung stärker lokalisierter Rechenleistung mit datenintensiven Operationen. Bewirkt wird sie durch Computational Storage Drives (CSDs) und entsprechende Geräte.

Computational Storage bettet Prozessoren in Storage-Devices ein – typischerweise auf der Ebene der SSD oder des NVMe-Laufwerks, nicht bei den NAND-Flash-Speichermodulen. Im Folgenden geht es darum, wie Computational Storage in Speicherarchitekturen passt, um die Laufwerke selbst, um Codierungsanforderungen und verfügbare Produkte.

Architektonische Grundlagen

Trotz der scheinbar einfachen Idee ist die Technologie von Computational-Storage-Geräten relativ neu. Nur wenige Unternehmen arbeiten an Produkten. Der Markt befindet sich in einem frühen Stadium und ist dynamisch.

Dennoch arbeitet die SNIA (Storage Networking Industry Association) an Dokumentation und Standards für Computational-Storage-Technologie. Der aktuelle Entwurf des SNIA Computational Storage Architecture and Programming Model definiert Funktionen und Fähigkeiten für mehrere Kategorien von Computational Storage Devices (CXes):

  • Computational Storage Drive (CSD): CDSD-Laufwerke bieten persistentes Storage und diverse Rechendienste.
  • Computational Storage Processor (CSP): Er arbeitet als diskreter Storage-Prozessor mit lokalem Storage und ergänzt das Storage-Array um lokale Verarbeitungskapazitäten.
  • Computational Storage Array (CSA): Ein CSA aggregiert mehrere CSDs oder konventionelle Drives mit einem CSP.
  • Computational Storage Services (CSS): CSS bieten Zugriff auf Algorithmen und Funktionen, die auf einem Computational Storage Drive oder CSA laufen.

Ein CSS kann programmierbar sein und umfasst einen Image-Loader, ein eingebettetes Betriebssystem oder eine Container-Plattform. Der Host kann ihn mit kundenspezifischen Services wie Paketfiltern, Deep-Learning-Inferenzkalkulationen oder einem Hadoop-Cluster-Knoten konfigurieren. Der CSS kann auch mit fest eingebauten Funktionen angeboten werden. Beispiele dafür sind Datenkompression, Verschlüsselung, Redundanzberechnungen wie RAID und Erasure Coding, Datenbankbetrieb und die Verarbeitung regulärer mathematischer Ausdrücke.

Abbildung 1: So funktionieren die Drives und Schnittstellen für Computational Storage.
Abbildung 1: So funktionieren die Drives und Schnittstellen für Computational Storage.

Der Entwurf der SNIA beschreibt zwei Betriebsmodelle, die definieren, wie das Hostsystem auf den CSD zugreift:

  • Direktbetrieb: Hier nutzt das Hostsystem die Schnittstelle des Laufwerks, zum Beispiel PCIe, um auf den CSD oder den CSP zuzugreifen. Funktionen werden über das API der Computational-Komponente ausgeführt.
  • Transparenter Betrieb: Das Hostsystem greift über das Standard-Storage-API auf die Computational-Funktionen zu.

Die SNIA-Spezifikation beschreibt mehrere Aktionstypen, die ein CSX ausführen können soll. Einige Beispiele:

  • Managementfunktionen: Beispiele sind Service-Discovery und Gerätekonfiguration, Programmierung, Initialisierung und Monitoring.
  • Betriebsfunktionen: Datenspeicherung, Datenabruf, Austausch mit benachbarten CSDs.
  • Sicherheitsfunktionen: Authentisierung, Autorisierung, Verschlüsselung, Auditierung.

Die SNIA-Specs befassen sich auch mit dem logischen Betrieb der CSXe. Nicht abgedeckt ist die physische Schnittstelle zwischen Hosts und Devices. Allerdings verwenden die meisten Implementierungen NVMe mit Geräten, die direkt an eine NVMe-Schnittstelle, -Fabric oder den PCIe-Bus angeschlossen sind.

Die Technische Arbeitsgruppe Computational Storage der SNIA neigt zu NVMe und PCIe als Schnittstellenstandards. Das liegt laut Scott Shadley an Nutzungsszenarien und eingereichten Gestaltungsvorschlägen von Mitgliedern zu Computational Storage.

Shadley ist stellvertretender Vorsitzender der Computational-Storage-Arbeitsgruppe der SNIA und Vice President Marketing von NGD Systems. Mit der Weiterentwicklung der Technologie würden allerdings Computational-Storage-Laufwerke mit eingebetteten Betriebssystemen wahrscheinlich einen TCP/IP-Port besitzen, der die NVMe-PCIe-Schnittstelle ergänzt oder ersetzt.

Computational Storage Drives im Einsatz

Von den verfügbaren CSDs basieren heute alle auf NVMe Drives oder PCIe-Karten. Sie verwenden dasselbe Protokoll, um zwischen der Host-CPU und den Laufwerksprozessoren zu kommunizieren. Die Geräte nutzen entweder einen feldprogrammierbaren Logikbaustein (Field Programmable Gate Array, FPGA) oder ein ARM-System-on-Chip (SoC) für die lokale Verarbeitung. Sie unterscheiden sich in Funktionen und Flexibilität. Die FPGA-basierenden Produkte sind im Allgemeinen stärker begrenzt als Arm-Devices. Einige beliebte Implementierungen:

  • PCIe-Laufwerksbeschleunigungskarte,  U.2- oder M.2-NVMe-Laufwerk mit eingebettetem Flash-Speicher oder Memory mit hoher Bandbreite sowie einem FPGA, der mit Funktionen für das Daten- und Volume-Management vorprogrammiert wurde, etwa für Kompression, Erasure Coding, Verschlüsselung sowie Datei- und Datenbankoperationen.
  • PCIe-Laufwerksbeschleunigungskarte, U.2- oder M.2-NVMe-Laufwerk mit eingebetteten Memory, Controller und einem unprogrammierten FPGA. Mit diesen Produkten können Anwender CSDs um kundenspezifische Funktionen erweitern. Programmiert wird in einer Hochsprache wie Xilinx Vitis oder einer maschinennahen FPGA-Beschreibungssprache.
  • PCIe-Laufwerksbeschleunigungskarte, U.2- oder M.2-NVMe-Flash-Laufwerk mit eingebettetem Arm SoC, auf den entweder Funktionen für die Datentransformation vorgeladen wurden oder voll mittels kundenspezifischem Arm-Codes programmierbar ist. Soweit bekannt, ist NGD der einzige Hersteller, der Arm-Prozessoren in einem CSD verwendet. Sie kommen mit vorinstalliertem Embedded Linux als Betriebssystem.
Abbildung 2: Ein Überblick, wie Computational-Storage-Server bereitgestellt werden können.
Abbildung 2: Ein Überblick, wie Computational-Storage-Server bereitgestellt werden können.

Die Anbieter von CSDs bevorzugen die NVMe-Schnittstelle, weil jedes Serverbetriebssystem Treiber dafür mitbringt, um auf das Storage und andere Funktionen zuzugreifen. NGD zum Beispiel verwendet Linux auf Arm mit einem Standard-NVMe-Laufwerk. So können Anwender das Gerät über eine grafische Nutzerschnittstelle erreichen, über die Laufwerksschnittstelle des Hosts oder über einen SSH-Tunnel, der zur Netzwerkschnittstelle des CSD führt. Die Technische Arbeitsgruppe der SNIA definiert neue NVMe-Befehle und erzeugt Anwenderbibliotheken, die das Laden und Ausführen von CSD-Programmen vereinfachen sollen.

Obwohl mehrere CSDs parallel arbeiten können, können sie nicht unter ihresgleichen Daten versenden und Anfragen verarbeiten. Vielmehr brauchen sie einen Host-Prozess, um gleichzeitig Compute-Befehle an jedes Laufwerk zu schicken. Laut Shadley werden zukünftige Versionen auch die Peer-to-Peer-CSD-Kommunikation erlauben, zum Beispiel, um Ergebnisse von einem Gerät zum anderen zu schicken, die dort weiterverarbeitet werden. Ein solches Peer-to-Peer-System wäre in Deep-Learning-Netzwerken sinnvoll, wo die Ausgaben einer Modellschicht zur Eingabe einer anderen werden.

Codeentwicklung und Laden

Computational Storage Drives mit FPGAs müssen vor dem Einsatz programmiert werden. Obwohl FPGAs nach der Bereitstellung des Geräts, das sie enthält, programmiert werden können – das ist ja genau ihr Vorteil – ist dieser Prozess nicht so einfach wie ein Container Image oder eine Java-Archivdatei zu laden. Daher können die derzeitigen FPGA-basierten CSDs nicht im Betrieb mit Code ausgerüstet werden, sondern die Produkte kommen ausgestattet mit festen Funktionen. Sie müssen also nicht von Anwendern programmiert werden.

Im Fall der CSDs von NGD wird der Arm-Code von der Host-CPU über die NVMe-Schnittstelle auf das Laufwerk geladen. Um Code in unseren Arm-Cores laufen zu lassen, muss der x86-CPU-Prozess einen Crosscompiler durchlaufen, der ihn an Arm anpasst.

Das noch frühe Entwicklungsstadium von Computational Storage mit seinen herstellerspezifischen Produkten hat zur Folge, dass Hersteller keinen breiten Zugang zu technischer Dokumentation oder APIs bieten. Potentielle Kunden sollten sich die gesamte verfügbare technische und programmiertechnische Dokumentation ansehen und Hardware leihweise erwerben, um sie gründlich zu evaluieren, bevor sie eine strategische Kaufentscheidung treffen. Denn es gibt ein erhebliches Lock-in-Potential.

Hersteller von Computational Storage

Diverse Hersteller bieten Computational Storage an. Einige Beispiele:

  • Eideticom Communications: Zum Angebot gehören vorprogrammierte FPGAs mit diversen Funktionen entweder auf einer PCIe-Zusatzkarte oder in einem U.2-Laufwerk.
  • NGD Systems: Der Hersteller hat die Arm-basierte Newport-Plattform als PCIe-Zusatzkarte, EDSFF (Aufsatzkarte), U.2- oder M.2-Laufwerk im Angebot.
  • Samsung: Die SmartSSD ist ein FPGA, das mit der Entwicklungsumgebung Xilinx Vitis oder mit Xilinx HDL programmiert werden kann. Samsung hat Partnerschaften zu Unternehmen aufgebaut, die die Entwicklung von kundenspezifischen Funktionen übernehmen.
  • ScaleFlux: Das vorprogrammierte FPGA dieses Unternehmens bietet Algorithmen für Datenkompression und -dekompression, die die Ein-/Ausgabe beschleunigen, die Latenz verringern und die Kapazität für Datenbankapplikationen wie Aerospike, MySQL und PostgreSQL erhöhen soll. Das Produkt ist als PCIe-Karte oder U.2-Laufwerk erhältlich.

Erfahren Sie mehr über Storage Performance

ComputerWeekly.de
Close