Suchen

Funktionsweise objektorientierter Speicher Die „Wolke“ könnte zum Stauraum für Objekte werden

| Autor / Redakteur: Thomas Gerner/Rainer Graefen / Nico Litzel

Hierarchische Dateisysteme stoßen an ihre Leistungsgrenzen und haben ein grundsätzliches Problem mit Ort- und Metadaten. Objektspeicher bieten sich als Alternative an.

Firmen zum Thema

Das Prinzip von Software Defined Object Storage
Das Prinzip von Software Defined Object Storage
(Grafik: Georg Csajkas, iTernity)

Die „digitalisierende Welt“ produziert bekanntlich einen Riesenwust an Dokumenten. Am liebsten in unstrukturierter Form. Bislang ist der größte Teil in Dateisystemen wie ext4, GPFS, NTFS, Data Ontap oder ZFS untergebracht, die teilweise mehrere Hundert Millionen Dateien mit einer begrenzten Dateigröße aufnehmen können.

Dateien, die in einem solchen Verwaltungskonzept aus der aktiven Benutzung herausfallen, sind nur schwer wiederzufinden, da ihnen etwas Entscheidendes nicht mitgegeben werden kann: beschreibende Informationen, kurz Metadaten. Objekte verbinden den Inhalt einer Datei mit diesen Metadaten und werden dadurch selbstbeschreibend.

Mit dieser Fähigkeit entfällt die Notwendigkeit, Objekte in einer hierarchischen Dateistruktur unterzubringen. Diese wird für eine dem Dateiinhalt äußerliche Ordnung benutzt, die allerdings schon durch die Zeichenbeschränkung für Ordner- und Dateinamen schnell Grenzen findet.

Diese Strukturierung hat zudem den Nachteil, dass sie sich nur umständlich spiegeln oder mit Tricks auf ein anderes Speichersystem bewegen lässt. Auch dieses Problem haben Objekte nicht, da sie in einem flachen Namensraum gespeichert werden, selbstbeschreibend sind und sich deshalb an jeden beliebigen Platz in einem (weltweiten) Speichernetz verschieben lassen.

Ein einzigartiger Identifier

Interessant ist an dieser Stelle noch, wie das Objekt zu seinem Namen kommt, der eigentlich ein Identifier ist. André Braun, Germany Sales Director Storage für Public and Large Enterprise bei Dell, beschreibt das für den Dell-DX-Objektspeicher so: „Die jeweilige Applikation überreicht per API (Application Programming Interface) oder http die zu speichernden Daten an den Objektspeicher und bekommt einen 128-Bit-Hash-Code zurück. Identische Dateien, die eventuell von einer anderen Applikation bearbeitet wurden und nur mit zusätzlichen Metainformationen versehen wurden, bekommen ein zusätzliches Content Description File (CDF). Das CDF wird gespeichert und verweist mit einem Zeiger auf den eigentlichen Dateiinhalt. Gelöscht werden erst einmal nur die CDFs, solange bis kein CDF mehr mit dem Dateiinhalt verknüpft ist. Ist dieser Zustand erreicht, beispielsweise beim Erreichen der vorgesehenen Aufbewahrungszeit, dann löscht das System selbst auch die Ursprungsdatei.“

Wie kommt die Anwendung jetzt wieder an die Datei, wenn sie lokationsunabhängig gelagert werden kann? Per REST und Soap! Wird die Datei innerhalb des Speichersystems verschoben, so verändert sich der Hash-Code nicht. Braun: „Die Datei hat eine weltweit eineindeutige Cloud-Adresse. Man bekommt an jedem Ort der Welt mit dem Hash-Code immer dieselbe Datei zurück.“

(ID:42301751)