Was nichtflüchtiger Speicher für Anwendungen bedeutet

Einfach direkt

Bernhard Homölle

Nichtflüchtiger Hauptspeicher bedeutet einen neuen Weg in der Konzeption von Servern und Rechenzentren. Es ist allerdings nicht damit getan, seine Rechner mit neuen Modulen zu bestücken. Passende Mainboards und Erweiterungen der Betriebs- und Dateisysteme sind ebenfalls nötig. Außerdem kann man so eine applikationszentrische Architektur erhalten.

Nichtflüchtiger Speicher kann die hohe Zuverlässigkeit und Geschwindigkeit von DRAM auch für Storage bieten.

Im Rahmen des EU-Projekt Horizon 2020 NEXTGenIO entwickeln die Teilnehmer Hardware, um NVRAM zu verwenden, und erarbeiten Methoden, wie sich der Speicher vom Betriebssystem, etwa beim Job-Scheduling, optimal einbinden lässt.

Am Barcelona Supercomputing Center entwickeln Forscher dataClay, einen In-Memory-Objektspeicher. Durch Instanziieren der Objekte direkt im Speicher fallen etliche Transformationen weg.

Gleichzeitig müssen die Konzepte für nichtflüchtigen Speicher auch verteilte Infrastrukturen berücksichtigen. In einem nächsten Schritt soll das für den CPU-Cache geschehen, sodass mehrere Recheneinheiten Cache-kohärent zusammenarbeiten können.

Hauptspeicher und Storage wachsen zusammen und rücken den Speicher in den Mittelpunkt. Neue Techniken und Architekturen erlauben, das Verhältnis von Rechner und Speicher zu überdenken. Nichtflüchtige Speichertechniken, die DRAM ergänzen und später ersetzen können, haben das Potenzial, den heute flüchtigen Hauptspeicher zum Storage zu transformieren. Darüber hinaus können Anwendungen die Beziehung zu ihren Daten neu festlegen. Es muss nicht immer Block-, File- oder Object-Storage sein, sondern Anwendungen können direkt die programmierten Daten und Objekte (zum Beispiel aus C++ oder Java) nichtflüchtig speichern. Mit In-Memory-Applikationen, vielen TByte großen Hauptspeichern und erweiterten Storage-Funktionen wird der mit kurzer Latenz angesprochene Hauptspeicher zur zentralen Komponente. Und er entscheidet, wie verlässlich und performant Anwendungen in Zukunft arbeiten und skalieren.

Schaut man sich die Historie der Computer an, stellt man fest, dass die Diskrepanz zwischen der Geschwindigkeit bei der Datenverarbeitung und der beim Speichern und Übertragen der Daten seit Jahrzehnten wächst. CPU-Entwickler steuern gegen mit ausgefeilteren Pipelines, Caches, Puffern und Architekturkonzepten wie Multithreading, Prefetching und Branch Prediction, die einen Leerlauf der vielen Kerne verhindern sollen. Das Betriebssystem hilft mit Hauptspeicher-Management, I/O-Buffer-Steuerung und Schedulern, den Strom von Daten und Code nicht abreißen zu lassen. Der flüchtige Hauptspeicher dient dem OS sozusagen als ein weiterer großer Cache/Puffer, um verhältnismäßig langsame I/O-Operationen zu vermeiden. Dafür muss die Wiederverwendung von Daten und Code durch optimiertes Prefetching und große Caches oder Puffer eine möglichst hohe Trefferwahrscheinlichkeit ergeben.

Unterschiedliche Storage-Klassen

Das größte Problem liegt in der Diskrepanz zwischen DRAM- und Storage-Latenz (SSD, HDD, Netzwerk): Fehlen noch Daten für ein Programm, ziehen CPUs und Betriebssysteme andere Threads, Tasks oder Jobs vor. Das ist gut für die Auslastung der Prozessoren, hilft allerdings der einzelnen Anwendung nicht. Neue Ansätze sollten mehr aus dem Blickwinkel der Anwendung beziehungsweise des Kunden, der eine Anwendung nutzt, entstehen. Gerade in modernen Umgebungen geht es immer weniger um die Performance des Servers insgesamt, sondern mehr um die Reaktionsgeschwindigkeit der individuellen Applikationen und wie verlässlich diese im Sinne von Quality-of-Service ist.

Bei alldem darf man nicht vergessen, dass die heute am Markt verfügbaren Storage-Systeme sich aus mehreren Gründen so entwickelt haben, wie sie sind. Das Kosten-Nutzen-Verhältnis ist ein wichtiger Aspekt, ebenso Kompatibilität mit vorhandenen Programmen und die verfügbare Technik. Mit der Einführung von SSDs sind neue Tiering- und Caching-Konzepte aufgekommen. Bei Software-defined Storage (SDS) wird Direct Attached Storage (DAS) genutzt – nicht zuletzt, um die Latenz für viele Zugriffe zu verringern. Mit dem weiteren Preisverfall von SSDs werden All-Flash-Appliances mit zuverlässiger und geringer Latenz über den gesamten für die Applikationen benötigten Storage interessanter und neue Protokolle wie NVMe verringern zusätzlich die große Lücke zwischen flüchtigem Hauptspeicher und Storage.

Nichts davon reicht allerdings an die niedrige Latenz und die hohe Zuverlässigkeit von Dynamic Random Access Memory (DRAM) heran. Der Zugriff ist zeitlich festgelegt (synchron) und deshalb zuverlässig. Außerdem ist das „Random Access“ von besonderer Bedeutung. Die Zugriffsmuster moderner Multi-Core-/Multi-Threading-CPUs brauchen eine niedrige Antwortzeit auf zufällige Speicheradressen, damit sie ihre Performance erreichen. Drehende Platten mit Blockzugriffen über das SCSI-Protokoll sind dafür nicht konzipiert. Moderne SSDs mit NVMe-Protokoll eignen sich dafür besser.

Direkter Zugriff auf die Daten

Daten aus dem Hauptspeicher dauerhaft zu speichern, läuft derzeit über die CPU und darin implementierte I/O-Operationen. Das involviert eine Reihe von Schnittstellen. Persistenter Speicher entlastet den Prozessor und übernimmt seine Verwaltung selbst (Abb. 1).

Bei beiden erfolgt der Zugriff allerdings über eine I/O-Operation. Das bedeutet einen erheblichen zeitlichen Aufwand. Die CPU muss Zehntausende von Instruktionen abarbeiten: Aufbauen von Scatter-Gather-Listen, Kommunikation mit dem I/O-Controller sowie das Bearbeiten von Rückmeldungen und Interrupts (siehe Abbildung 1). Für eine Bestätigung, dass die Daten sicher im Storage liegen, muss die Anwendung auf die Rückmeldung des eigentlichen Storage-Mediums HDD/SSD warten. Je nach Latenz des Mediums kann das dauern.

Während die Applikation auf die Rückmeldung wartet, verstreicht ungenutzte Zeit. I/O-Operationen sind außerdem nicht deterministisch (asynchron). Wenn der Schreib-Lese-Kopf falsch steht, die SSD gerade Wear-Leveling, Garbage Collection oder TRIM betreibt oder das Netz eine Peak-Belastung hat, kann sich die Latenz erheblich verschlechtern. Entsprechend ist eine Vorhersage der Performance einer Applikation schwierig. Optimierten Benchmarks ist da nicht unbedingt zu trauen.

Im Kontrast dazu können bei nichtflüchtigem Hauptspeicher (NVRAM) Daten zuverlässiger und dauerhaft mit annähernd DRAM-Latenz gespeichert werden – kein Kontext-Switch zwischen Applikation und OS, sondern simple CPU-Instruktionen wie Load/Store und Cacheline Flush, um die Daten aus den flüchtigen CPU-Caches in den nichtflüchtigen Bereich des Hauptspeichers zu schreiben. Die Anwendung kann nichtflüchtige Daten auch ohne weitere I/O-Operation wieder lesen und bearbeiten. Sie greift damit direkt auf den Storage zu und verfügt unmittelbar über ihre Daten.

Kurzer Dienstweg

Dateisysteme mit Direct-Access-Erweiterung können nichtflüchtigen Speicher bereits adressieren. Im Gegensatz zum klassischen Blockzugriff fällt die Kaskade von Anfragen und Zugriffen deutlich einfacher aus. Anwendungen erfragen einfach den Speicherort und greifen direkt auf die Adresse im NVDIMM zu (Abb. 2).

Linux und Windows können heute schon mit nichtflüchtigem Hauptspeicher umgehen. Das Betriebssystem unterscheidet dabei zwischen DRAM und NVRAM. DRAM steht jedem Programm wie gewohnt über die klassischen Speicherschnittstellen zur Verfügung, während NVRAM über die Direct-Access-Erweiterung (DAX) existierender Dateisysteme verwaltet wird. Der Zugriff erfolgt ähnlich wie beim Memory-Mapping von Dateien in den Hauptspeicher. Statt aber eine Datei per I/O-Operation vom Storage in den Hauptspeicher zu kopieren, fordern Programme Pointer auf den Speicherbereich mit den relevanten Daten an (siehe Abbildung 2).