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.“

Wie sieht nun ein Objektspeicher in der Praxis aus? Mario Vosschmidt, Systems Engineer bei Datadirect Networks, fasste auf der letzten Storage Networking World (SNW) die wichtigen Parameter ein wenig despektierlich so zusammen: „Als Primärspeicher sind Object Stores ungeeignet. Der Speicher selbst ist nur eine dumme riesige Festplatte, aber mit der geeigneten Software lässt sich ein hochverfügbarer Langzeitspeicher herstellen.“

Vosschmidt kann es aber auch detaillierter ausdrücken. Demnach besitzen die bei DDN auch als Web Object Scaler (WOS) bezeichneten Systeme eine Skalierungseffizienz von annähernd 95 Prozent, die bis zum Ausbau von 256 Knoten erreicht wurde. Das liegt vor allem am flachen Namensraum. In einem Dateisystem wären, wie Messungen gezeigt haben, sechs bis acht Dateizugriffe notwendig, um überhaupt den Speicherort zu erreichen.

Flach aber schnell

Die Performance der Objektspeicherung zeigt sich noch an anderer Stelle: Mittels der REST-Schnittstelle gelang es Web-basierten Anwendungen, die magere Performance von 100.000 Anfragen pro Tag im Jahr 1994 auf über 600 Millionen Anfragen pro Tag im Jahr 1999 hochzuschrauben. Beim Schreiben von Objekten werden Transfergeschwindigkeiten von 250 Megabyte pro Sekunde und beim Lesen von 500 Megabyte pro Sekunde erreicht. Über die gegenwärtig benutzten 1- und 10-Gbit-Ethernet-Netzwerke arbeitet man bei DDN an weiteren Schnittstellen, die Daten mit höheren Geschwindigkeiten transportieren können, und Infiniband als Netzwerkschicht ist ebenfalls in Planung.

Nach oben offene Objektspeichergrenze

Diese Netzwerk-Updates sind selbst für Laien mäßig beeindruckend. Beeindruckender ist die Fähigkeit des Systems, pro Knoten eine Milliarde Objekte zu verwalten. Insgesamt wurde in ersten Tests mit 256 Knoten eine vorläufige Obergrenze von 256 Milliarden Objekten erreicht. Diese Grenze ist jedoch nicht fix, sondern hängt von der Leistungsfähigkeit des einzelnen Knotens und der Gesamtzahl der Knoten ab.

Eine wichtige Funktion eines Objektspeichers sind die Verteilungsregeln. Jedes Objekt wird mindestens einmal repliziert. Auch hier merkt man schon den Unterschied zu den typischen RAID-Systemen, die ein Volume oder gleich das gesamte Speicherarray replizieren oder spiegeln.

Sicherheitspolitik

Mit Verteilungsregeln wird festgelegt, an welchem physischen Ort Replikate eines Objekts in welcher Zahl vorgehalten werden sollen. Nach einem Fehlerfall durch beispielsweise einen Netzwerkfehler erfolgt der Wiederanlauf der Replikationsmechanismen automatisch. Ist dieser Mechanismus trotzdem nicht arbeitsfähig, agiert jeder Knoten erst einmal für sich und legt Notfallkopien an, bis der normale Betriebszustand wiederhergestellt ist.

Migrationspfade

Obwohl Objektspeicher einen flachen Namensraum besitzen, ist es möglich, den Zugriff per NFS und CIFS abzuwickeln. DDN unterstützt High Performance und Multimedia-Anwendungen auch per IBM-Dateisystem GPFS (Global Parallel Filesystem).

Nicht fehlen sollte bei Objektspeichern die Möglichkeit der Datenauslagerung. Diese könnte mit einer LTFS- oder HSM-Schnittstelle erfolgen. So wäre es möglich, selten benutzte Daten in ein Archiv zu überführen, um Strom und Stellplatz zu sparen.

Dieser Artikel stammt aus dem Storage-Insider-Kompendium „Klassisches Backup, Cloud-Storage & Disaster Recovery“. Hier finden Sie weitere Kompendien von Storage Insider als PDF-Datei zum kostenlosen Download.

(ID:42301751)