Laurent - stock.adobe.com
So verändert künstliche Intelligenz den Storage-Verbrauch
KI-Applikationen verbrauchen Daten anders als übliche Apps: Sie brauchen bis zu Milliarden von Datenpunkten, die zum Teil mehrfach verarbeitet werden, bis Ergebnisse vorliegen.
KI-Applikationen (künstliche Intelligenz, KI) unterscheiden sich dadurch von anderen, dass sie Storage anders konsumieren als andere Anwendungen. Bei KI-Applikationen werden Daten vom Storage zur KI-Verarbeitung oder zur Ein-/Ausgabe (I/O) geschickt. Außerdem bewegen sie sich beim Durchlaufen ihres Lebenszyklus zwischen verschiedenen Storage-Systemen und -Medien hin und her.
Die I/O-Leistung ist vor allem mit dem gewünschten Durchsatz verknüpft, unabhängig vom Storage-Typ oder den verwendeten Speichermedien. Die drei KI-Varianten Maschinenlernen, Deep Learning und neuronale Netze brauchen und verarbeiten Daten jeweils anderes und haben deshalb voneinander abweichende I/O-Anforderungen. Betrachtet man sie genauer, erkennt man wie die jeweiligen KI-Anwendungen im Detail den Storage-Verbrauch verändern.
Der Schlüssel zum Storage-Verbrauch: Geschwindigkeit
Maschinelles Lernen (Machine Learning) ist die verbreitetste KI-Form. Solche dem menschlichem Entscheidungsverhalten nachempfundenen Algorithmen können Millionen von Datenpunkten für Prognosen oder Entscheidungen verwenden. Die Genauigkeit der Ergebnisse, die eine solche KI-App erzeugt, ist abhängig von der Menge der Datenpunkte, die innerhalb eines bestimmten Zeitraums verarbeitet werden: je mehr Datenpunkte, desto genauer.
Begrenzender Faktor ist die Zeit: Wird innerhalb von „n“ Millisekunden eine Prognose oder Entscheidung benötigt, entscheidet die Geschwindigkeit, mit der ein ML-Algorithmus Daten verarbeitet, über die Qualität der Ergebnisse. GPUs und High Performance Computing (HPC) haben inzwischen die meisten Verarbeitungsengpässe beseitigt. Deshalb liegt es nun vor allem am Storage-I/O, wie schnell die ML-Algorithmen tatsächlich arbeiten.
Deep-Learning-Apps sind noch extremer: Sie nutzen Millionen oder gar Milliarden von Datenpunkten und verarbeiten diese auch noch mehrfach. Dadurch wirken sich I/O-Engpässe noch gravierender aus.
ML- und Deep-ML-Algorithmen laufen auf modernen Serverarchitekturen, neuronale Netze sind allerdings etwas anderes. Beim Rechnen ahmen neuronale Netze (auch künstliche neuronale Netze genannt) die neuronale Architektur des menschlichen Hirns nach.
Da sich Hirnzellen vertikal (hierarchisch) und horizontal verschalten, brauchen sie zahlreiche Scale-Out-GPUs und -CPUs – von Dutzenden bis zu Millionen Prozessoren. Entscheidend für das Storage neuronaler Netze ist daher, ein paralleles Hochleistungs-Filesystem mit extremem Durchsatz einzusetzen. Passende Beispiele sind IBM Spectrum Scale, das Open-Source-Produkt Lustre, Panasas PanFS und WekaIO.
Traditionelles Block Storage ist in der Regel nicht geeignet, den erforderlichen Lesedurchsatz von Hunderten Gigabytes oder gar Terabytes pro Sekunde zu liefern, die dafür nötig sind. Es gibt aber einige aktuelle Produkte mit hoher Leistung, die dennoch in Frage kommen: Dell EMC PowerMax, DirectData Network (DDN) Storage Fusion Architecture, Excelero NVMesh, Fungible, IBM FlashSystem, Oracle Exadata, Pavillion Hyperparallel Flash Array und StorCentric Vexata.
Ältere File-Storage-Systeme schaffen diese Anforderungen ebenfalls in der Regel nicht. Aber aktuelle Produkte mit parallelen Filesystemen und globalen Namensräumen (Global Namespace) können den nötigen Durchsatz liefern. Einige Beispiele für entsprechende Produkte sind DDN EXA5, IBM Spectrum Scale, Panasas ActiveStor und WekaIO.
Sicher Daten migrieren
Sowohl ML als auch Deep ML nutzen aktuelle und historische Daten für Analyse, Lernen, Prognosen und Entscheidungen. Die historischen Daten, die diese Apps verwenden, liegen meistens nicht auf superschnellen, teuren Storage-Systemen. Sie mögen zunächst dort gespeichert werden, wandern aber mit der Zeit auf langsameren, billigeren Speicher oder in die Cloud.
Darin liegt ein Problem. Denn solche Migrationen müssen einfach, automatisiert und für die KI-Anwendung transparent ablaufen. Mit anderen Worten: So weit es die KI-Applikationen angeht, sind die Daten noch da. Migrationsprobleme sind der häufigste Grund, dass viele KI-Projekte fehlschlagen. Es ist also erfolgskritisch, dieses Thema gut zu lösen. Dafür gibt es zwei Möglichkeiten.
Die erste besteht darin, die Datenmigration auf nachgelagerte Speicherebenen fest in das Storage-System einzubauen, so dass die Daten innerhalb des Systems oder in die Cloud verschoben werden. Das System weiß dann, wo die Daten jeweils liegen, kennt also das Storage, das verbraucht wird, und stellt die Daten dem KI-Prozess auf Nachfrage zur Verfügung. Diese Herangehensweise leidet unter begrenzten Systemkapazitäten. Doch aktuelle Scale-Out-Technologien können hier helfen. Einige Beispiele dafür sind Nimbus Data, Oracle Exadata X8M, StorOne und VastData.
Beispiele für Datenmigration auf nachgelagerte Storage-Layer im System
Oracle Exadata X8M verwendet in den primären Storage-Servern Hochleistungsmodule Intel Optane DC Persistent Memory (PMEM) im Application-Direkt-Modus mit NVMe-Flash und nachgelagert kostengünstige, hoch kapazitive Festplatten mit hoher Kapazität in XT Storage Servern.
Maximal 27 TByte PMEM pro Rack sind möglich, bis zu 18 Racks werden unterstützt. Das ist potentiell eine Menge teures Hochleistungs-Storage, zudem werden nicht alle Datenbanken oder Daten innerhalb einer Datenbank die PMEM-Leistung tatsächlich brauchen. Die Oracle-Datenbank verschiebt deshalb ältere, weniger häufig angefragte Daten von PMEM auf NVMe-Flash und dann auf noch leistungsschwächere und kostengünstigere Storage-Server wie eben die XT Storage-Server. Die Oracle-Datenbank weiß, wo die Daten sind und hat, wenn sie gebraucht werden, Zugriff darauf.
VastDatas All-Flash Array verwendet langlebige hochleistungsfähige Optane Storage Class Memory (SCM)-Laufwerke als Cache für die weniger leistungsfähigen, günstigeren und weniger haltbaren Quad-Level Cell (QLC)-Flash-SSDs. Intelligente Software schreibt vorwiegend auf SCM und begrenzt die Schreibvorgänge auf QLC-Flash. Unweigerlich landen die Daten irgendwann auf QLC, während das System weiter eine außerordentlich hohe KI-Leseleistung erbringt. Die Storage-Start-ups Nimbus Data und StorOne reklamieren ähnliche Fähigkeiten.
Daten im Hintergrund verschieben
Die zweite Herangehensweise besteht darin, die Daten im Hintergrund zu verschieben. Zurück bleibt nur ein sogenannter HSM-Stub (Hierarchical Storage Management), ein rückverweisender symbolischer Link (Symlink) oder die Middleware des globalen Namensraumes.
Traditionelles HSM ist problematisch, da die Daten vor dem Lesen auf das ursprüngliche Storage zurückverlagert werden müssen, was zu lange dauert. Stubs können zerbrechen und dann sind die Daten nicht mehr auffindbar. Für Symlinks gilt dasselbe, allerdings sind sie etwas robuster. Und bei einem globaler Namensraum braucht man zusätzliche Komponenten im Datenpfad, meist Middleware, die Latenz hinzufügen. Allerdings ist diese Latenz nominell und gilt nur für das erste gelesene Byte.
Symlinks und globale Namensräume versorgen die ML- oder Deep-ML-Algorithmen der KI mit den Daten und Datenpunkten aus unterschiedlichen Ressourcen, die sie zum Lernen brauchen. Es gibt mehrere Produkte, die diese Funktionen zur Verfügung stellen. Beispiele sind Datadobi, iRods, Komprise und StrongLink von Strong Box Data Solutions.
Daten müssen transparent verschoben werden, wenn man KI-, ML- und Deep Learning-Apps zu vertretbaren Kosten mit dem Datenvolumen versorgen will, das sie brauchen. Derartige Transparenz erhöht den Verbrauch von kostengünstigem und weniger leistungsfähige Speicher gegenüber teureren, leistungsfähigeren Varianten. Mit einer solchen Herangehensweise lassen sich die riesigen Datenmengen effektiv handhaben, die KI-Applikationen brauchen.
