pressmaster - stock.adobe.com

Das NVM-Programmiermodell der SNIA und wie es funktioniert

Die SNIA will die Verbreitung von nicht-flüchtigem Memory vorantreiben. Dazu hat sie ein Programmiermodell für NVM entwickelt, das Hersteller und Anwender unterstützen soll.

Die Storage Networking Industry Association (SNIA) hat ein Programmiermodell für NVM (Non-Volatile Memory) entwickelt, um die Verbreitung der Funktionen und Technologien von nicht-flüchtigem Arbeitsspeicher zu unterstützen.

Die Spezifikation stellt den Herstellern und Konsumenten von NVM einen auf Standards basierenden Ansatz zur Verfügung, um Architekturen für Storage- und Memory-Software zu erstellen. Zu diesem Zweck definiert die Spezifikation bestimmte Verhaltensweisen für Software, die mit NVM-Geräten verbunden ist.

Die jüngste Ausführung des NVM-Programmiermodells der SNIA in der Version 1.2 – veröffentlicht bereits im Jahr 2017 – beschreibt keine bestimmte API. Stattdessen empfiehlt die Spezifikation, wie die Prozesse zwischen der Anwenderseite und den Kernel-Komponenten des Betriebssystems, das NVM unterstützt, ausgeführt werden sollten. Das Ziel ist es, gemeinsame NVM-Prozesse über mehrere OS-Schnittstellen hinweg zu ermöglichen, die mit NVM-Geräten wie zum Beispiel SSDs, PCI-Cards und anderen nicht-flüchtigen Solid-State-Geräten inklusive jenen für Memory verbunden sind.

Die Spezifikation konzentriert sich auf Software-Elemente, die NVM als eine Hardwareabstraktion im OS-Kernel – wie zum Beispiel ein Volumen – oder eine Datenabstraktion von Applikationen auf der Anwenderseite – wie zum Beispiel eine Datei – darstellen. Die Spezifikation beschreibt, wie NVM-Medien entdeckt, angeschlossen und benutzt werden, einschließlich Softwareprozessen für den Zugang zu Daten und ihrer Wiederherstellung.

Programmier-Modi für NVM

Die SNIA hat bisher vier Programmier-Modi für NVM vorgelegt, die empfohlene Verhaltensweisen für NVM-Schnittstellen beschreiben. Die vier Betriebsweisen adressieren Block Storage, File Storage, Persistent Memory Volumes und PM (Perl Module) Files.

NVM.BLOCK. Der erste Programmiermodus, NVM.BLOCK, ist für Software bestimmt, die den Zugang zu NVM-Block-Storage-Geräten organisiert. Ein Gerät kann für ein oder mehrere Volumes bestimmt sein, wobei jedes Volume eine Reihe von logisch zusammenhängenden Blöcken liefert.

Komponenten von Betriebssystemen wie zum Beispiel Dateisysteme können den NVM.Block-Modus dazu nutzen, Block-Storage-Features zu entdecken und Zugang zu ihnen zu gewähren. Anwendungen, die in der Lage sind, direkt mit Block Storage zu interagieren, können auch diesen Modus verwenden. In jedem Fall erfordert das NVM-Gerät einen speziellen Treiber für NVM-Block, der die Kommandoschnittstelle für das Gerät zur Verfügung stellt.

NVM.FILE. Der zweite Programmiermodus, NVM.FILE, gilt ebenfalls für den Softwarezugang zu NVM-Block-Storage-Geräten oder zu ihren Volumes. Dieser Modus ist besonders für Anwendungen bestimmt, die sich nicht direkt mit Block Storage verbinden können und stattdessen auf ursprünglichem Verhalten von File-I/O beruhen, um über ein File-System Zugang zum Speicher zu bekommen.

Dieser Ansatz findet sich bei vielen Anwendungen. Das File-System verbindet sich mit dem Block-fähigen NVM-Treiber, indem es den NVM.Block-Modus verwendet, der wiederum Zugang zu dem NVM-Gerät gewährt.

Abbildung 1 beschreibt Beispiele für die NVM-Modi NVM.BLOCK und NVM.FILE.
Abbildung 1 beschreibt Beispiele für die NVM-Modi NVM.BLOCK und NVM.FILE.

NVM.PM.VOLUME. Der dritte Modus ist NVM.PM.VOLUME, der für Betriebssystemkomponenten bestimmt ist, die Zugang zu Persistent-Memory-Volumes haben. Diese Komponenten können File-Systeme oder Pseudo-Blockgeräte umfassen, deren Funktionen sich auf den PM-Zugang stützen. Dieser Modus dient als eine Software-Abstraktionsschicht für PM-Geräte, die Eigenschaften wie zum Beispiel die physikalischen Addressbereiche von jedem Volumen herausstellen. Ähnlich wie beim NVM.BLOCK-Modus erfordert der NVM.PM.VOLUME-Modus einen PM-fähigen Treiber.

NVM.PM.FILE. Der letzte Modus ist NVM.PM.FILE. Er ermöglicht es User-Anwendungen, direkten Zugang zu NVM-Geräten als Memory zu bekommen. Zum Beispiel könnte ein File-System, das für PM bereit ist, eine auf dem NVM.PM.FILE-Modus basierende API exportieren.

Die API kann dann von Anwender-Applikationen für den Zugang zum File System verwendet werden, das dann wiederum über einen NVM-PM-fähigen Treiber Zugang zu den PM-Geräten bekommt. Der NVM.PM.FILE-Modus definiert Aktionen wie zum Beispiel Mapping von PM-Files zu virtuellen Memory-Adressen oder Synchronisierung von Teilen der PM-Files mit der ständigen Domain (dem Ort, an dem sich Daten in einem dauerhaften Status befinden).

Abbildung 2: Die Modi NVM.PM.VOLUME und NVM.PM.FILE unterscheiden sich von den beiden oben erwähnten NVM-Modi.
Abbildung 2: Die Modi NVM.PM.VOLUME und NVM.PM.FILE unterscheiden sich von den beiden oben erwähnten NVM-Modi.

Verhalten von NVM

Für jeden Modus definiert die Spezifikation Handlungsweisen, Merkmale und Anwendungsfälle, die im Detail das Verhalten der verschiedenen Modi bestimmen. Jede Handlungsweise und jede Eigenschaft sind entweder als verbindlich oder optional eingestuft. Im Falle der Verbindlichkeit müssen sie in der Software verankert sein, damit sie als konform zum NVM-Programmiermodell betrachtet werden können.

Eine Handlungsweise bezieht sich auf einen Prozess, der ein NVM-Gerät darstellt oder mit ihm interagiert. Eine Handlung ist entweder spezifisch für einen Modus oder einen Teil der COMMON Domain, was bedeutet, dass sie sich auf mehrere Modi bezieht. Alle Handlungsweisen werden mit einem dreiteiligen Namen identifiziert:

<context>.<mode>.<verb>

Die Komponente <context> ist immer NVM, und die Komponente <mode> besteht aus dem Namen des jeweiligen Modus, außer es handelt sich um einen Teil der COMMON Domain – in diesem Fall wird das Schlüsselwort COMMON eingesetzt. Die Komponente <verb> bezieht sich auf die jeweilige Handlung.

Zum Beispiel umfasst der Modus NVM.BLOCK NVM.BLOCK.ATOMIC_WRITE, eine verbindliche Aktion zur Absicherung eines einheitlichen Verhaltens während eines Energieausfalls.

Merkmale liefern Informationen über die Eigenschaften und Fähigkeiten eines NVM-Geräts. Wie schon die Handlungsweisen werden Merkmale mit dreiteiligen Namen identifiziert:

<context>.<mode>.<noun<

Die Komponenten <context> und <mode> sind die gleichen wie bei Handlungsweisen. Die Komponente <noun> repräsentiert den Namen der Eigenschaft oder Fähigkeit. Zum Beispiel umfasst der Modus NVM.Block das verbindliche Merkmal NVM.BLOCK.EXISTS_CAPABLE, das anzeigt, ob das Gerät die Aktion NVM.BLOCK.EXISTS unterstützt.

Ein Anwendungsfall beschreibt einen Plan, um ein Ziel zu erreichen. Jeder Anwendungsfall legt seinen Zweck und den Kontext fest, zusammen mit Impulsen und Vorbedingungen, die erklären, ob der Anwendungsfall zutrifft. Der Anwendungsfall beschreibt auch In- und Outputs, Ereignisse und Aktionen und er liefert Hinweise für weitere Informationen.

Zum Beispiel umfasst der Modus NVM.BLOCK einen Anwendungsfall für die Implementierung von Flash-basiertem NVM als Daten-Cache. Der Anwendungsfall beschreibt, wie die schnelle, zufallsbedingte I/O-Performance von Flash und die Nicht-Flüchtigkeit aus ihm einen guten Kandidaten für einen Daten-Cache machen. Er erklärt außerdem, wie der Cache-Manager den Solid-State-Cache verwenden kann, um die Performance zu verbessern und die Beständigkeit zu erhalten.

Compliance mit den Standards

Um Compliance zu erreichen, muss ein NVM-Interface eine Dokumentation zur Verfügung stellen, die Aktionen des NVM Programming Model erfasst und ihren Pendants in der Implementierung zuschreibt. Die Integration des Standards sollte jedoch nicht andere Aspekte der Implementierung in Mitleidenschaft ziehen.

Das Ziel besteht darin, NVM-Medien so effektiv wie möglich einzusetzen, während die Interoperabilität zwischen den Speichersystemen verbessert wird. Zu diesem Zweck stellt das NVM-Programmiermodell empfohlene Rollen für NVM-Programmschnittstellen zur Verfügung, ohne eine bestimmte API zu beschreiben oder bestehende Modi des NVM-Zugangs zu missbilligen.

Erfahren Sie mehr über Storage Performance

ComputerWeekly.de

Close