Mehr als nur Kosmetik

von Ariane Rüdiger

Das Open Compute Project ist heute ein wichtiger Schrittmacher für zukunftsfähige Hard- und Software. Derzeit arbeitet das Projekt an mehreren wichtigen Innovationen, die helfen sollen, Speicher länger haltbar, besser verwaltbar und einfacher reparierbar zu machen. Aber auch anderswo entstehen zukunftsweisende offene Technologien rund um Storage, etwa die Datenspeicherung in Glas oder ein einheitliches Protokoll für das IoT-Zeitalter.

Storage gehört dank des unaufhörlichen Datenwachstums zu den derzeit spannendsten IT-Themen, und es braucht immer dichter beschreibbare Datenträger. Festplatten oder SSDs müssen etwa alle fünf Jahre ausgewechselt werden, was Berge von Elektroschrott verursacht. Die meisten dieser Komponenten landen aus Datenschutzgründen im Shredder. Microsoft etwa gibt an, jedes Jahr Millionen von Festplatten zu verschrotten. Das verträgt sich nicht mit den ehrgeizigen Umweltzielen des Unternehmens: Redmond möchte schon in einigen Jahren alle bislang angefallenen Kohlenstoffausstöße komplett kompensieren. Ohne verbesserten Storage wird das wohl kaum funktionieren.

Da macht Tape, obwohl erheblich langlebiger als Harddisks und SSDs/Flash, auch keinen wirklich großen Unterschied. Zumindest nicht bei einem Vergleich mit wirklich langfristigen Wissensspeichern wie Büchern, Mikrofiches oder – ins Extrem gewendet – Hieroglyphen, die sogar noch Jahrtausende lesbar sind, da in Stein oder andere dauerhafte Medien gemeißelt. Dazu kommt: Die physische Zerstörung von Festplatten garantiert inzwischen nicht mehr die Datenzerstörung. Tatsächlich ist es schon heute möglich, dass sich selbst aus minimalen Festplattenschnipseln Daten regenerieren lassen. Bessere Methoden oder sicherere Speichermedien sind also dringend nötig.

Ein weiteres Problem, diesmal auf der Protokollseite, sind die vielen teils voluminösen und umständlichen Anfragen und Datentransporte, die für Anwendungen wie Industrial IoT oder autonomen Verkehr nötig sind. Wegen der heutigen Protokollstrukturen muss das Gesamtsystem immer wissen, wo sich die Daten befinden, die es braucht. Liegen die woanders, reist die Anfrage zunächst über viele Router bis ans Ziel. Das erzeugt insgesamt einen massiven Overhead, insbesondere auch beim Energieverbrauch der Kommunikation. Und je verästelter das Netzwerk, desto größer gestaltet sich dieses Problem.

Kosmetik mit großen Wirkungen

Weitere Herausforderungen nehmen sich neben diesen Grundlagenfragen eher kosmetisch aus. Trotzdem könnten auch hier bessere Technologien die Situation erheblich verbessern. Dies betrifft beispielsweise die Verschwendung von Speicherraum und Energie sowie eine unnötige Verkürzung der Lebensdauer beim Schreiben auf SSDs: Wird ein MByte an eine SSD übergeben, so schreibt diese tatsächlich erheblich mehr Daten. Die Rede ist von der sogenannten Write Amplification (WA). Der Grund: SSDs löschen deutlich gröber als sie schreiben. Dadurch werden beim Wiederbeschreiben mehr Daten verschoben und neu geschrieben als eigentlich neu am Speicher eingehen (Garbage Collection).

Gemessen wird WA durch den Write Amplification Factor (WAF), dem Verhältnis der tatsächlich geschriebenen zu den an das Speichersystem übergebenen Daten. Soll 1 MByte an Daten auf eine SSD geschrieben werden und legt die SSD real 1,5 MByte ab, hat die SSD einen WAF-Wert von 1,5. Ideal wäre ein WAF von 1 bei null Overhead. Am Nächsten kommen hier sequenzielle Schreibvorgänge, weil dabei große, zusammenhängende Datenblöcke abgelegt werden. Am höchsten ist der WAF beim zufälligen Schreiben kleiner Datenstücke. Und gerade diese werden, beispielsweise durch immer mehr IoT-Umgebungen, immer häufiger.

Umständlich und langwierig sind auch Fehlerdiagnose und Tests für die Zertifizierung von Speichermedien für OCP-Umgebungen. Letztere sollte Nutzern möglichst transparent machen, wofür sich ein Speichermedium eignet und was von ihm zu erwarten ist. Allerdings verwendet jeder Hyperscaler zum Teil andere Tools, die gegebenenfalls herstellerspezifisch sind. So entstehen Testlücken. Außerdem sind bestehende Fehlerkorrekturen an SSDs bislang immer nur einem Hyperscaler zugänglich.

Längst nicht alle Verhaltensdaten, die beim Gebrauch des Mediums erzeugt werden, erreichen den Troubleshooter beim Anwender, Datenschutz sei Dank. So können Nutzer bei der Speichermedien-Fehlersuche bislang nicht auf menschenlesbare herstellerspezifische Test- oder Diagnosedaten zurückgreifen. Denn Binärdaten dürfen das RZ nicht verlassen. Also sind sie bislang auf die Reaktionen der Hersteller angewiesen. Zudem müssen sie, sofern ihre Umgebung heterogen ist, mit vielen unterschiedlichen Firm-ware-Versionen arbeiten.

Die meisten dieser Themen drücken wegen der Größe ihrer Installationen vor allem die Hyperscaler. Das Protokollproblem dagegen steht vor allem dem autonomen Verkehr und einem effektiven industriellen IoT im Weg. Daher ist es kein Wunder, dass viele neuartige Lösungsvorschläge entweder im Umfeld des von IT-Riesen gegründeten OCP ausgebrütet oder aber ins OCP eingebracht werden, sobald sie für einigermaßen praktisch umsetzbar gelten. Aber auch anderswo tut sich was.

Flexible Platzierung statt zu viel schreiben

Das WA-Problem ließ sich zuerst mit Überprovisionierung, seit 2007 mit Load-Balancing-Hinweisen des Hosts adressieren. Im Herbst 2023 hat das NVM-Express-Gremium ein neues Verfahren für die optimale Datenplatzierung auf Flash verabschiedet: FDP (Flexible Data Placement) [1]. Definiert ist es in NVMe TP4146, TP steht für Technical Proposal. Die Technologie soll in die Anforderungen an OCP-zertifizierten Storage einfließen.

Im Kern geht es bei FDP darum, dass der Host dem Speichermedium Hinweise dazu gibt, wo die in Frage kommenden Daten am besten zu speichern sind. Das geschieht durch einen virtuellen Zeiger. Dabei muss das Speichersystem lediglich in die Lage versetzt werden, einen solchen Hinweis, so vorhanden, zu verstehen und die Daten im gewünschten Superblock zu platzieren, statt selbst einen auszuwählen.

Ist kein solcher Hinweis vorhanden, kommen also die Daten von einem System, das nicht FDP-enabled ist oder das NVMe-System ist selbst nicht FDP-enabled, funktioniert alles wie gehabt: schreiben, lesen, TRIM – also die Benachrichtigung, dass bestimmte Daten auf der SSD nicht mehr benötigt werden und gelöscht werden dürfen – und alle weiteren Sicherheitsmechanismen. Das bedeutet, die Rückwärtskompatibilität zu früheren Speichersystemen oder Anwendungsversionen bleibt gewahrt. Applikationen profitieren, wenn sie das neue Verfahren beherrschen. Sie laufen aber auch, wenn sie es nicht tun. Und Geräte können FDP ein- oder ausschalten.

FDP findet sich bereits in Version 5.19 des Linux-Kerns, steckt in den plattformübergreifenden xNVMe-Tools ab Version 0.7, im freien Hardwaresimulator QEMU seit Version 8.0 und in der NVMe-Befehlszeile nvme-cli. Weitere Implementierungen laufen.

Das Verfahren wurde schon in einigen heterogenen Umgebungen getestet, wo die Daten über unterschiedliche "Schreiber" (Applikationen, Container, VMs, Namensräume, Mikroservices, Schreibmuster et cetera) auf die SSDs floßen. Die Ergebnisse präsentierte das OCP auf einer Storage-Tagung im vergangenen Jahr. Ergebnis: FDP halbiert bis drittelt den Verschleiß der Datenträger und verdoppelt oder verdreifacht deren Durchsatz. Der WAF ist durchwegs erheblich geringer, oft sogar 1 oder nahe daran. Laut OCP kommt die Implementierung des neuen Verfahrens schnell voran.

Mehr Transparenz bei Test- und Diagnosedaten

Auch gegen die Probleme mit Tests und Diagnosen unternimmt das OCP etwas. Denn die bisher verwendeten SMART-Logs oder herstellerspezifischen Logs, an die sie herankamen, brachten für den Nutzer nicht viel. Die Information darin war zu oberflächlich, um die Ursache eines Fehlers finden und beheben zu können.

Telemetrie-Logs sind bislang aus Datenschutzgründen nur für den Hersteller lesbar. Das OCP versucht die Situation durch mehrere Vorgaben zu verbessern, die ins OCP Datacenter NVMe-Spec eingehen. Erstens wurde ein für die Überwachung von Massen an SSD-Medien geeignetes Health Information Log mit SSD-Statistiken (Version 1.0) definiert. Zweitens gibt es jetzt einen Latenzmonitor, der aktuelle Leistungsspitzen isoliert und damit Echtzeit-Debugging ermöglicht (Version 2.0).

Drittens steht die formatierte Telemetrie in Version 2.5 kurz vor der Fertigstellung. Sie führt zu menschenlesbaren Telemetriedaten und macht die Anwender bei der Fehlersuche an Speichermedien dadurch unabhängig von den Herstellern ihrer Storage-Systeme.

Das OCP stellt eine einfache Schnittstelle in C++ und Python zur Verfügung. Darüber lässt sich die neue Telemetriesoftware mit bestehenden Testplattformen integrieren, die mit den herstellerübergreifend funktionierenden Schnittstellen OpenTAP, OpenTest, Fava oder CONTest arbeiten.

Weiter hat das OCP das neue Zertifizierungsverfahren Northstar entwickelt. Es soll die Hyperscaler-Qualifikation der NVMe-SSDs an die Hersteller oder von ihnen beauftragte Testinstitutionen auslagern. Davon könnten am Ende auch andere Nutzer profitieren. Bestandteile des Projekts sind ein Repository für offene Tests, die offene Testentwicklung und offen verfügbare Tools. Das Ganze wird zusammengehalten durch einen klar definierten Continuous-Integration/Continuous Delivery-Prozess.

Formatted Telemetry im Detail

Hier kommen die schon erwähnten menschenlesbaren Telemetriedaten ins Spiel. Die Arbeit des OCP ist diesbezüglich weit fortgeschritten. Bislang erfolgt die Fehlersuche anhand der NVMe-Telemetriedaten. Im Einzelnen werden die Bereiche 1 und 2 der Logseiten, die die Speichermedien mit Informationen füllen, von Version 2.5 der Telemetrie-Logseite (im Folgenden: Telemetrieseite) neu definiert. Hier stehen Daten in insgesamt vier getrennten Datenbereichen. Zudem ist eine übergreifende Seite, die OCP Strings Log Page (kurz: Strings-Seite), geplant. Sie ist eine Art Verzeichnis aller verschlüsselten Strings auf der Telemetrieseite samt ihren ASCII-Übersetzungen. Die Aufgabe, das entsprechende Format zu definieren, hat Samsung übernommen.

Was die technischen Details betrifft, folgt zunächst der Aufbau der Strings-Seite. Sie hat einen Header, der auf die Startadressen der übrigen Bereiche der Seite verweist, und vier Bereiche. Drei der Bereiche enthalten Identifikatoren (IDs), der vierte die ASCII-Strings, in die die IDs übersetzt werden.

Der erste Bereich umfasst die IDs für die herstellerspezifische Statistik samt Unterbereichen. Jeder ID-Eintrag besteht hier aus der ID, auf die er sich bezieht, einem Feld für eine Längenangabe und einer Information über den Abstand zum Anfang des jeweiligen Bereichs. Bereich 2 fasst herstellerspezifische Event-IDs. Die Event-Felder sind aufgebaut wie im Statistikbereich, nur ein Feld "Debug Type" kommt hinzu. Der dritte Bereich fasst weitere herstellerspezifische, aber vom OCP definierte Event-IDs. Die Einträge sind genauso strukturiert wie die im Vendor-spezifischen Event-ID-Bereich. Der vierte Bereich schließlich enthält die zu den jeweiligen IDs zugehörigen menschenlesbaren ASCII-Strings. Die Einträge in die ersten drei Bereiche werden so geordnet, dass der Eintrag mit der kürzesten ID den Zähler 0 erhält, je länger eine ID ist, desto höher der Zähler.

Die Telemetrieseiten greifen auf diese Strings-Seite zu. Eine Telemetrieseite gliedert sich in einen Header und vier Bereiche. Besonders wichtig für menschenlesbare Diagnosedaten sind die Bereiche 1 und 2, um die es hier vor allem gehen soll. Der Bereich 1 der Telemetrieseite hat eine feste Größe und soll beim Auslesen die I/O-Latenz nicht beeinflussen. Bereich 2 ist herstellerspezifisch definiert und darf die I/O-Latenz beeinflussen.

Die Daten in Bereich 1 sind weiter untergliedert. Jede Einheit enthält einen OCP-Header, Statistik und FIFO-Ereignisspeicher. Maximal 16 benamte FIFO-Ereignisspeicher sind erlaubt, ansonsten ist ihre Zahl herstellerdefiniert.

Der vom OCP definierte Header des gesamten Datenbereichs 1 enthält grundlegende Informationen zu Version, Profilen, Statistik (Zahl der Einträge, herstellerspezifisch), der Zahl der FIFO-Speicher und den Log Pages zur NVMe-SMART-/ Health Information sowie den erweiterten OCP SMART/Health-Informationen.

Die einzelnen Einträge im Statistikfeld umfassen jeweils eine ID, Informationen zur Persistenz, einen Bezugs-Namensraum, das Datenvolumen und die eigentlichen Daten. Das Format unterstützt mehrere Profile, die sich im Layout der Datenbereiche sowie in den gesammelten Statistiken, FIFOs und Ereignissen unterscheiden können. Die ID gibt an, ob die Statistik vom OCP oder vom Hersteller definiert wurde. Der Persistenz-Indikator meldet, ob die Daten beim Reset/Ausfall erhalten bleiben. Der älteste Eintrag erhält die Ordnungsnummer 0.

Jeder einzelne Eintrag in einer FIFO-Schlange enthält mehrere Felder: einen Debug-Typ (etwa NVMe, PCIe, Reset), eine dazu passende ID, das Datenvolumen, herstellerunabhängige Daten, die Herstelleridentifikation für die angegebene ID und letztlich herstellerspezifische Daten.

Die Daten in Datenbereich 2 sind strukturiert wie die in Feld 1, allerdings kommen sie ohne OCP-Header aus. Vielmehr werden die Adressen der Daten in Bereich 2 relativ zum Startfeld von Datenbereich 1 angegeben. Anhand der Identifikatoren können Nutzer nun die gesuchten Daten mithilfe der Strings-Seite aus dem System auslesen.

Dieses Format steht kurz vor der Verabschiedung und wird wahrscheinlich das Leben der Storage-Troubleshooter in Hyperscaler-Umgebungen erheblich vereinfachen. Es ist zu hoffen und sogar wahrscheinlich, dass sich diese Technologie später auch in anderen Speicherumgebungen durchsetzt.

Glas als neues Speicher-Basismaterial

Mit der Vergänglichkeit von Storage-Medien hat sich Microsoft intensiv auseinandergesetzt. Herausgekommen ist das weit gediehene Konzept eines Speichersystems, das auf Glasmedien basiert. "Project Silica" [2] wurde von Microsoft schon vor rund sechs Jahren an der Universität Cambridge aus der Taufe gehoben. 2022 präsentierte es erste Ergebnisse bei einer Wissenschaftstagung von Microsoft.

Das Material hat einige sehr attraktive Vorteile: Die Handhabung von Glas ist bestens bekannt. Es hält bei Bedarf sehr lange. Wird es nicht mehr benötigt, lässt es sich einschmelzen und zu neuem Glas herstellen – der Werkstoff gehört zu den wenigen, die durch Einschmelzen und Neufertigen kaum degradieren. Weiter lässt sich Glas gut transportieren, auch wenn etwas Vorsicht vonnöten ist, und in jede gewünschte Form bringen. Auch die Rohstoffe sind gut verfügbar und vergleichsweise billig.

Microsofts Idealvorstellung sind riesige Speicherbänke aus gläsernen Datenträgern in der Cloud, die dort so lange arbeiten können, wie das betreffende Rechenzentrum selbst erhalten bleibt. Werden mehr Daten eingespeichert, kommen neue Platten hinzu. Dazu ist Glas EMV-unempfindlich. Damit könnte also auch unser digitales Erbe endlich wirklich dauerhaft werden.

200 Schreibebenen in einer Glasplatte

Die Glas-Datenträger werden mit einem Femtosekunden-Pulslaser beschrieben. Eine Femtosekunde ist der 1e+15. Bruchteil einer Sekunde. Die Laserimpulse dringen beim Beschreiben ins Glas ein. Daher sind die Daten durch die Oberfläche des Glasmediums geschützt. Bis zu 200 separate Datenebenen schreibt Microsoft in ein quadratisches Glasmedium etwa von der Größe einer CD.

Der Laser erzeugt im Glas strichartige Markierungen, die Microsoft als Voxels bezeichnet. Je nach Ausrichtung der Polarisation lassen sich diese drehen. Damit kann ein Voxel mehr als ein Bit darstellen. Jede Ebene lässt sich separat mit Voxels beschreiben. Die geschriebenen Daten sind dank kryptographischer Verfahren erstens redundant und zweitens nicht ohne Dechiffrierung lesbar. Sie lassen sich auch nicht nachträglich manipulieren, was Technologien wie Blockchain partiell überflüssig machen würde.

Rund 1000 Voxels pro Ebene werden jeweils zu einem quadratischen Feld gebündelt. Ein solches Feld mit allen seinen Ebenen ist die Grundeinheit beim Auslesen des Datenträgers mittels eines Polarisations-sensitiven Mikroskops unter Tageslicht. Die unterschiedlich ausgerichteten Voxels polarisieren dabei das einfallende Licht, und diese Polarisation wird gemessen. Beim Lesen bewegt sich nicht das Medium, sondern das Leselicht (Beamstearing), um das Bruchrisiko gering zu halten.

Mit dem Verfahren lassen sich im Labor Lesegeschwindigkeiten wie bei den derzeit aktuellsten LTO-Standards erreichen. Microsoft will im Labor bereits quadratische Medien komplett von Ecke zu Ecke gelesen haben. Die Dekodierung der gelesenen Signale erfolgt jeweils für alles, was auf einem quadratischen 1000-Voxel-Feld des Datenträgers steht, mithilfe von KI und Maschinenlernen.

Hochmodulares Systemdesign

Weiter hat sich Microsoft schon Gedanken über das Systemdesign gemacht. Wichtige Komponenten sind das Medienregal nebst autonomen Handhabungsroboter, Lese- und Schreibsystemen. Alle drei arbeiten anders als bei heutigen Tape-Systemen vollständig unabhängig voneinander. Das heißt, dass ein hochmodulares System je nach Anforderungen des jeweiligen Nutzungsumfelds gestaltet werden kann.

Es ist beispielsweise denkbar, in einem Bereich ausschließlich schreibende Einheiten zu betreiben, die beschriebenen Medien dann in einen anderen Bereich zu transportieren, wo sie archivarisch bewahrt und bei Bedarf ausgelesen werden. Schreibgeräte sind dort nicht nötig. Das kommt der heterogenen Struktur von Archiven entgegen: Eine Vorstudie hatte ergeben, dass Datenarchive sich je nach ihrem Zweck stark hinsichtlich der geschriebenen und der ausgelesenen Datenmenge unterscheiden. Grundsätzlich nimmt die gelesene Datenmenge aber ab, je älter die Daten sind – ein Grund dafür, warum Archivmedien dauerhaft, aber günstig sein müssen.

Mit derartig modularen Systemen ließe sich jedes System bedarfsgerecht ausbauen. Die Regale bestehen aus kleineren Regaleinheiten, die hintereinander gekoppelt und auch parallel zueinander aufgestellt werden können. Nur beschriebene Medien landen dort und sind dann für den Datenabruf bereit. Jede Regalebene besitzt eine Schiene, an der sich ein Handhabungsroboter entlang bewegt. Dieser Roboter holt beschriebene Medien aus den Regalen, bringt sie zu den Lesesystemen und schiebt sie nach dem Lesevorgang wieder hinein.

Die Roboter können mittels eines Kippmechanismus von einer Schiene am Regal zu der darüber oder darunter wechseln. Das heißt: Fällt ein Roboter aus oder blockiert, ist deswegen nicht das gesamte Regalbrett außer Betrieb, sondern nur der Bereich unmittelbar unter diesem Roboter.

Auf dem diesjährigen OCP Summit stellte Microsoft seinen systembrechenden Vorschlag der Open-Source-Community vor. An die Entwickler in allen dem OCP angeschlossenen Unternehmen erging der Aufruf, schnellstmöglich die nötigen Komponenten zu entwickeln und einsatzreif zu machen. Zu den Zeiträumen, die dafür nötig wären, gab Microsoft keine Schätzungen ab.

Ein Protokoll fürs neue Zeitalter

Eine weitere Neuerung auf Basis von Open-Source, wenn auch (noch) außerhalb des OCP, wurde jüngst auf einer IT-Pressetour in Madrid der Öffentlichkeit vorgestellt: Das Datenprotokoll Zenoh [3]. Es soll für den Datentransport eine ähnlich wichtige Rolle übernehmen wie IP für den Aufbau des Internets oder Kafka heute fürs Echtzeit-Datenstreaming oder bestimmte Protokolle in der Robotik. Zenoh könnte in beiden Welten wichtige Protokolle ersetzen.

Urheber der Idee ist die italienische Protokollschmiede Zettascale. Dort beschäftigen sich rund ein Drittel der etwa sechzig Mitarbeiter mit Weiterentwicklung und Implementierung von Zenoh. Entwickelt wird in Frankreich und den Niederlanden. Historisch hat sich die Firma von Adlink abgespalten. Strategischer Partner ist TTTech Auto, ein österreichisches Unternehmen, das sich auf Automotive, Robotik und IoT spezialisiert hat.

Zenoh soll den Protokoll-Flickenteppich, der heute für Edge-to-Core-Implementierungen charakteristisch ist, beenden. Dieses Protokoll-Durcheinander ist der wichtigste Grund für verzögerte Implementierungen von IoT und Robotik im industriellen Bereich. Außerdem ist es der Grund für hohe Energieverbräuche, die durch Datentransport entstehen.

Zenoh ist im Gegensatz zu anderen Lösungen nicht host-, sondern datenzentrisch und konsequent dezentral aufgebaut. Es vereinigt die Handhabung von ruhenden, transportierten und gerade in Rechenvorgängen verwendeten Daten in allen Bereichen. Seine Abstraktionen sind ortsunabhängig. Abfragen lassen sich über heterogene Systeme verteilen. In der Struktur "Pub-Sub-Query" ähnelt es REST. Die Arbeit ist weit fortgeschritten: Das Protokoll steht vor der Zertifizierung gemäß ISO-26262 ASIL-D. Diese Norm beschreibt die Sicherheit autonomer Fahrzeuge. ASIL steht für Automative Security Integrity Level.

In der US-amerikanischen Indy Autonomous Challenge, einem Rennen für autonome Fahrzeuge, wurde Zenoh bereits eingesetzt, genauso in autonomen Fahrzeugen und in Zügen der Deutschen Bahn. Anwendungsfeld ist jeweils die autonome Kommunikation zwischen Fahrzeugen oder Robotern und ihrer Umgebung. Eine Evaluation von Open Robotics erbrachte, dass Zenoh von allen Protokollen am besten abschnitt. Gegenüber DDS, einem in diesem Umfeld gern eingesetzten Protokoll, verkleinert es die Zahl der Discovery-Pakete um Dimensionen und erhöht dadurch die Menge der in einer Zeiteinheit transportierten Datenpakete. Das gilt insbesondere in Multicast-Umgebungen.

Zenoh bietet native Bibliotheken für wichtige moderne Programmiersprachen wie Rust, C oder C++, Python, JS, REST und andere. Gemeinsam genutzter Speicher wird unterstützt. Das Protokoll setzt auf der Datenschicht auf, kann aber auch mit vorhandenen Netzwerk- oder Transportschichten arbeiten. Es funktioniert wegen seines winzigen Overheads von nur 5 Byte auch in den kleinsten Embedded- und sonstigen Umgebungen sowie auf Linux, macOS, Windows und – derzeit als Alpha-Version – auf QNX. Mögliche Plattformen sind Arduino, ESP32, mbed, Zephyr und andere sowie Automotive micro SAR von Autostar Classic.

Außerdem funktioniert das Protokoll in jeder Topologie: Peer-to-Peer, gerouted oder mit Broker. Durch die Mechanismen von Publish/Subscribe/Query wird eine Datennachfrage vom jeweils nächsten Knoten befriedigt, der die Daten zur Verfügung hat, Transportwege für Daten werden also minimiert. Anfragen können gleichzeitig von allen Knoten beantwortet werden, die entsprechende Daten bereithalten. Dafür müssen sie nicht mehr über eine zentrale Cloud laufen, sondern nur noch bis zu den Quellen der nötigen Daten.

Fährt also ein Auto über eine Kreuzung und es geschieht ein Unfall, der anschließend untersucht werden soll, könnten dem Untersuchungsteam die Daten aus jedem Fahrzeug und die aus Ampeln oder sonstigen am Unfallort befindlichen optischen Sensoren genau für den Unfallzeitpunkt automatisch bereitgestellt werden, ohne dass das Untersuchungsteam genau wissen müsste, in welchem Gerät am Unfallort sie sich befinden. Denn gerade bei Unfällen geben die Blackboxes in den Fahrzeugen möglicherweise wegen des Unfalls über den kritischen Moment keine Auskunft mehr.

Anfragbare Datenbestände (Queryables) können sich auch über Replikationen oder Partitionen erstrecken, werden aber bei der Beantwortung von Anfragen trotzdem erkannt. Anfragen an Storage werden durch eine Queryable und einen Subscriber, der von dort Daten bestellt, repräsentiert.

Die um Dimensionen gesteigerte Energieeffizienz von Zenoh speist sich aus erhöhter Prozesseffizienz, da nur wenig Energie in die Zusammenstellung eines versendeten Pakets und seine Verarbeitung gesteckt werden muss. Weiter werden nur die nötigen Bytes der Payload mit sehr wenig Overhead auf dem kürzest möglichen Weg versendet.

Zettascale bietet, ähnlich wie heute Confluent für Kafka, inzwischen auch eine Onlineplattform an, über die sich Cloud-to-Microcontroller-Infrastrukturen bereitstellen, verwalten und überwachen lassen.

Fazit

Ansätze wie Zettascales Zenoh oder gläserne Speichermedien zeigen: Storage und IT sind mit ihren Möglichkeiten, die Datenflut zu bändigen, noch längst nicht am Ende. Vielmehr brechen sie möglicherweise gerade zu völlig neuen Ufern auf, die den zu erwartenden Aufgaben angemessen sind. Doch auch denen, die sich in den Rechenzentren mit den heute üblichen Speicher- und Protokollwelten herumschlagen, kann geholfen werden, wie die derzeit vom OCP in die Praxisreife gedrängten Ansätze zeigen. Es lohnt sich also, die Augen offen zu halten und zuzugreifen, sobald die Schwelle zur Praxisreife überschritten ist.

Storage-Trends beim Open Compute Project