München, Starnberg, 03. Dez. 2024 - Paralleles Schreiben auf SCM und QLC-Flash, synchrone Replikation für Aktiv-Aktiv-Cluster, S3 Event Publishing, EBox-Cluster und u.v.m...
Zur Ankündigung: VAST Data, Anbieter einer Plattform für leistungs- und datenintensive KI- und Data Analytics-Anwendungen, hat die neue Version seiner VAST-Software v5.2 vorgestellt. Hintergrund: Die VAST Data Platform kombiniert Speicher-, Datenbank- und containerisierte Compute-Engine-Services innerhalb einer skalierbaren Softwareplattform und für den Einsatz von KI mit GPU-Beschleuniger und den entprechenden Tools innerhalb von Rechenzentren und Clouds entwickelt - dies gilt sowohl für strukturierte als auch unstrukturierte Datenformate. Die auffälligste Neuerung in VAST 5.2 ist jetzt die Unterstützung einer neuen Hardwarekonfiguration, die VAST EBox oder Everything Box nennt.
VAST für Hyperscale mit EBoxes
Auf jeder x86-EBox läuft ein CNode-Container, der Benutzeranfragen bedient und Daten wie ein dedizierter CNode verwaltet, sowie DNode-Container, die die SSDs der EBox mit dem NVMe-Fabric des Clusters verbinden. Genau wie in einem VAST-Cluster mit CBoxes und DBoxes bindet jeder CNode im Cluster jede SSD im Cluster ein. Die EBox-Architektur erlaubt es, die VAST Data Platform in Umgebungen zu betreiben, die bisher keine hochverfügbaren DBoxes nutzen wollten oder konnten.
Dazu gehören Hyperscaler, die Tausende einer sehr spezifischen Serverkonfiguration haben, und Cloud-Anbieter, die nur Instanzen virtueller Maschinen anbieten. Sie ermöglicht es VAST auch, mit Unternehmen wie Supermicro und Cisco zusammenzuarbeiten, um die VAST Data Platform für Kunden bereitzustellen, die Server dieser Anbieter verwenden.
EBox-Cluster verwenden das DBox-HA-Datenlayout und können laut Anbieter mit mindestens 11 EBoxes pro Cluster weiterhin EBox-Ausfälle verarbeiten. VAST bringt die EBox-Architektur nach vorliegenden Angaben auch in die Public Cloud in Version 5.2, mit voll funktionsfähigen VAST-Clustern auf der Google Cloud Platform. Weitere Details hierzu sollen in einem separaten Beitrag folgen.
Verdopplung der Schreibleistung
Bereits bei Version 5.1 haben die Entwickler die Spiegelung des Schreibpuffers in SCM auf doppelte Paritätslöschcodes umgestellt. Diese Änderung, zusammen mit einigen anderen Optimierungen, hat die Schreibleistung laut Entwickler nahezu verdoppelt.
Mit v.5.2 nutzt VAST die Tatsache, dass es viel mehr SSDs mit hoher Kapazität (QLC) als sehr schnellen Speicher mit geringer Kapazität (aka SCM) gibt, indem große Write Bursts, wie das Dumping von Checkpoints von KI-Modellen, an einen Abschnitt von QLC geleitet werden. (Quelle / externer link > https://www.vastdata.com/blog/a-checkpoint-on-checkpoints-in-llms ).
Durch paralleles Schreiben auf SCM und QLC wird laut VAST die Schreibleistung noch einmal ungefähr verdoppelt. Da nur große Write Bursts an einen kleinen Prozentsatz des QLC in einem Cluster gesendet werden, ist der Einfluss auf die Abnutzung des Flash-Speichers unbedeutend. Insgesamt soll VAST nach diesen Angaben eine vierfache Verbesserung der Schreibleistung erreichen können; da dies nur auf die Software zurückzuführen ist, soll jeder VAST-Kunde eine Leistungssteigerung erleben können, ohne auf die nächste Hardware-Version warten zu müssen.
Synchrone Replikation für Aktiv-Aktiv-Cluster
Für Anwendungen, bei denen Datenverluste nicht toleriert werden können, ist nur die synchronen Replikation geeignet. Sobald ein Paar VAST-Cluster für die synchrone Replikation eines S3-Buckets konfiguriert ist, werden alle Daten, die in diesen Bucket geschrieben werden, auf beiden Clustern auf den anderen Cluster des Paares repliziert und vom Remote-Cluster bestätigt, bevor sie dem Client bestätigt werden.
Cloud-Provider können ein synchron replizierendes Cluster-Paar verwenden, um für ihre Objektspeicherangebote eine regionale statt einer zonalen Verfügbarkeit bereitzustellen, während Unternehmenskunden eine 100-prozentige Verfügbarkeit ihrer Anwendungen erreichen können, selbst wenn ihre Rechenzentren nur 99,9999 Prozent bieten.
Datenbankreplikation
VAST 5.2 erweitert auch die native asynchrone Replikation von VAST zur Unterstützung der nativen Tabellen von VAST. Wenn ein VAST-Cluster so konfiguriert ist, dass er Ordner mit VAST-Tabellen repliziert, werden diese Tabellen zwischen den beiden Clustern mit vollständiger Transaktionskonsistenz repliziert.
Standard-Datenbanksysteme, die auf herkömmlichen Speichern ausgeführt werden, können Momentaufnahmen der Volumes oder Dateien erstellen, die die Tabellen einer Datenbank enthalten. Die Datenbanksoftware speichert Daten und Updates jedoch im Arbeitsspeicher zwischen, anstatt alle Änderungen der Reihe nach auf dem entsprechenden Speichermedium zu speichern.
Dies bedeutet, dass die Daten in diesen Dateien nicht intern konsistent sind, da nur einige Tabellenaktualisierungen im Speicher und andere nur im Arbeitsspeicher der Datenbank gespeichert wurden. VAST bezeichnet diese Datenbank-Snapshots euphemistisch als „absturzkonsistent“, da die Daten in diesen Snapshots nur so konsistent sind, wie sie es bei einem Absturz des Datenbankservers gewesen wären.
Um einen Snapshot einer herkömmlichen Datenbank in einem konsistenten Zustand zu erhalten, ist eine gewisse Koordination zwischen dem Datenbankserver und dem Speichersystem erforderlich. Ein Skript oder der Windows VSS (Volume Shadow Copy Service) setzt die Datenbank still, indem Aktualisierungen aus dem Speicher in den Speicher übertragen werden, bevor der Snapshot erstellt wird. Als einheitliche Datenplattform integriert VAST die Datenbankverwaltung sowie Snapshot- und Replikationsprozesse in ein kohärentes Ganzes.
Wenn ein VAST-Cluster einen Snapshot eines Ordners erstellt, der VAST-Tabellen enthält, enthält der Snapshot eine konsistente Ansicht dieser Tabellen. Alle Transaktionen, die zum Zeitpunkt des Snapshots abgeschlossen waren, werden in den Snapshot aufgenommen, während Aktualisierungen von Transaktionen, die zum Zeitpunkt der Snapshot-Erstellung noch nicht abgeschlossen waren, nicht an einen Remote-Standort übertragen oder repliziert werden.
S3 Event Publishing
Die VAST DataEngine stellt Benutzern Tools zur Verfügung, die sie zur Implementierung ereignisgesteuerter Workflows benötigen, die Funktionen automatisch auf der Grundlage von Ereignissen wie Änderungen am Inhalt eines Buckets oder Ordners ausführen. In 5.2 liefert VAST mit dem S3 Event Publishing laut Anbieter dazu den ersten Schritt für diese Workflow-Automatisierung.
Falls das Event Publishing für einen oder mehrerer Ordner konfiguriert werden soll, sendet das VAST-Cluster einen Eintrag an ein bestimmtes Kafka-Thema. In Version 5.2 muss sich dieses Thema in einem externen Kafka-Cluster befinden und die Funktionen müssen das Kafka-Thema abonnieren.
In den nächsten Quartalsversionen soll die VAST DataEngine einen mit der Kafka-API kompatiblen Event Broker und die Funktionalität zur Datenverarbeitung hinzufügen können.
Abb.: Universal Storage Flash Plattform (Bildquelle: VAST Data).
Globale Namespace-Cache-Steuerung
Mit VAST 5.1 existiert der globale VAST-Namespace, der es Kunden ermöglicht, globale Ordner über mehrere VAST-Cluster hinweg mit vollständigem Lese- und Schreibzugriff im Kern, am Rand und in der Cloud darzustellen – mit strikter Konsistenz, um sicherzustellen, dass Anwendungen auf der ganzen Welt die neuesten Daten erhalten. Für jeden globalen Ordner enthält der Ursprungscluster eine vollständige Kopie der Daten des Ordners, und Satellitencluster verwenden ihre lokale SSD-Kapazität, um die Daten beim Zugriff zwischenzuspeichern.
Durch das Zwischenspeichern von Daten beim Zugriff ist gewährleistet, dass nur die Daten übertragen werden, auf die Benutzer oder Anwendungen an diesem Satelliten zugreifen. Das ist zwar effizient, bedeutet aber auch, dass Anwendungen warten müssen, bis die Daten über die WAN-Verbindung zwischen den Clustern übertragen wurden.
VAST 5.2 bietet Kontrolle darüber, wie Satellitencluster Daten vom Ursprung abrufen. Ein VAST-Administrator kann einen Satelliten dazu zwingen, alle Metadatenänderungen oder alle Daten- und Metadatenänderungen in einem Ordner vorab abzurufen. Wenn ein VAST-Kunde einen Workflow mit einer Phase vor Ort und einer Folgestufe in der Cloud hat, kann er den Ordner in seinem Cloud-Cluster so einstellen, dass Daten vorab abgerufen werden, wodurch die Verzögerung durch das Aufwärmen des Cache vermieden wird.
Querverweis:
Unser Beitrag > VAST Catalog: vereinfachtes Datenmanagement von KI und Big-Data-Analytics Anwendungen
Unser Beitrag > NoSQL-Datenbanken in der Cloud: Hinweise zu Leistungsmerkmalen und Vorteilen im Betrieb
Unser Beitrag > Elastic Search AI Lake: Architektur skaliert Suchanwendungen im Bereich unstrukturierter Daten