Objektspeicher (Object Storage) V1.2 (c) Stor IT Back 2025
In einem objektbasierten Speicher werden die Daten als Objekte verwaltet. Dieser Speicher wird für die Aufbewahrung riesiger Mengen an
unstrukturierten Daten verwendet. So speichert zum Beispiel Facebook die Bilder, Spotify die Lieder und Dropbox Dateien in Object Storage Systemen.
In diesem Objektspeicher werden die unstrukturierten Daten in einer Einheit (dem Objekt) gespeichert. Dieses Objekt enthält die Daten, aber auch Metadaten und eine
eindeutige Kennung. Über die Metadaten kann der Speicher durchsucht werden und der Zugriff erfolgt dann über die eindeutige Kennung.
Die Suche in den Objektspeichern ist also unabhängig von den Dateiformaten und den dafür benötigen Anwendungen möglich. Egal ob ein Foto oder ein Video oder eine
Datensicherung, alles kann von den Metadaten direkt durchsucht werden.
Der Objektspeicher wird von nahezu jedem Cloud Provider angeboten, er kann aber auch On-Premise in eigenen Räumlichkeiten des Unternehmens installiert sein. Beide
Varianten lassen sich auch kombinieren, so kann der On-Premise Speicher auf den Cloud Speicher repliziert, oder als Overflow genutzt werden. Damit können die Kosten
minimiert und die Leistung bzw. Verfügbarkeit maximiert werden.
Die Daten werden zusammen mit den Metadaten und der Kennung in einem Objekt gespeichert. Diese Objekte liegen in einer flachen Umgebung. Es muss also nicht
spezifiziert werden und dann in einer Struktur gespeichert werden. Die Objekten werden einfach so in Speicherpools abgelegt. Die Speicherpools können auf verschiedenen
Speichersystemen (Objektspeichergeräte) liegen, eine Skalierung ist sowohl horizontal, wie auch vertikal möglich. Auch eine Verteilung über verschiedene
Standorte für Verfügbarkeit und Flexibilität ist vorgesehen.
Etwas genau beschrieben besteht der Storage aus Object Storage Namespaces. Dieser Namespace wird in Compartments unterteilt. In diesem Compartment liegen dann
die Buckets und in den Buckets dann die eigentlichen Objekte. Es ist aber nicht möglich, ein Bucket in einem Bucket anzulegen, es ist ja ein
flaches System. Mit diesen Unterteilungen lassen sich Mandanten in den Systemen sehr einfach verwalten, eine Anforderung gerade von
Cloud-Providern. So können pro Kunde zum Beispiel ein Compartment definiert werden und der Kunde legt sich dann selbst verschiedene Buckets für Anwendungen an.
Der Zugriff auf diese Pools erfolgt über RESTful APIs, HTTP bzw. HTTPS mit gängige HTTP-Befehle
wie PUT für den Upload, GET für die Abfragen und ein DELETE für das Entfernung von Objekten.
Sowie die Suche in den Metadaten und auch der spätere Zugriff auf die eigentlichen Daten.
Wegen dieser Vorteile nutzen viele große Cloud-Anbieter den Objektspeicher als primäres Speicherformat.
Was bietet der Objektspeicher noch an Vorteilen?
Die Skalierbarkeit ist sicherlich eine der größten Vorteile. Die Speichergröße ist an sich unbegrenzt und kann durch Hinzufügen von neuen Systemen skaliert werden.
Die Objektspeicher-Systeme können die Daten zwischen verschiedenen Geräten replizieren. Damit ist der Schutz vor Ausfällen sehr einfach zu realisieren, auch über
verschiedene Standorte.
Sogar Richtlinien für den Lebenszyklus der Objekte lassen sich realisieren. So kann zum Beispiel bei einer Rechnung vermerkt werden, das diese nach 10 Jahren gelöscht werden
kann. So lassen sich auch Datenschutzvorgaben zum Löschen erfüllen. Ist zum Beispiel der Name vermerkt, so können alle Objekte für diesen Namen gefunden und
evtl. gleich gelöscht werden.
Warum werden dann nicht nur noch Objektspeicher verwendet?
Für Anwendungen, die typischerweise eine Datenbank benötigen, ist der Objektspeicher zu langsam. Dafür benötigen wir immer noch einen Blockspeicher. Haben sich die
Anwender an eine Verzeichnisstruktur gewöhnt und dort alles abgelegt, dann wird dies auch kaum in einem Objektspeicher abbildbar sein.
Die Performance von Objektspeichern wird immer besser durch leistungsfähigere Metadaten-Datenbanken auf immer schnelleren Medien, wie NVMe. Damit wird dieser Speicher
aber auch teurer. Es muss also zur Anwendung passend ausgewählt werden.
In einem File-Storage werden die Daten in einer Verzeichnisstruktur abgelegt. Hierbei können nur sehr wenige Metadaten eingebunden werden. Im Prinzip eigentlich nur der
Name, ansonsten stehen Metadaten nur in bestimmten Formaten zur Verfügung. In einem Bild können zum Beispiel Aufnahmedaten und eine Beschreibung eingebunden werden, dies muss
dann aber von speziellen Programmen durchsucht werden, die erst einmal die Datei an sich finden müssen. Und wenn dann neben dem Bild oder Foto noch eine Textdatei im
Verzeichnis liegt, dann klappt es wieder nicht mit den Metadaten.
Auch bei der Skalierung haben File-Storage bzw. das Filesystem an sich immer eine Begrenzung für die Anzahl der Dateien, die Größe des Filesystems an sich und zum Beispiel
eine maximale Anzahl von Zeichen im Namen inklusive der Verzeichnisstruktur. Weiterhin haben die meisten Filesysteme Performance-Probleme, wenn die Anzahl der
Dateien in einem Verzeichnis steigt. Liegen zum Beispiel sehr viele Fotos in einem Verzeichnis, weil das nach Datum aufgeteilt werden soll, dann kann dort die Suche
sehr langwierig sein.
Bei den normalen Anwendungen von Fileservern müssen die Nutzer relativ genau wissen, wo die Dateien liegen und wie die Dateien heißen. Also welcher Name vergeben wurde. Hat man
zum Beispiel in einem Verzeichnis sehr viele Rechnungen liegen und alle haben nur eine Nummer, dann wird es schwierig die richtige Rechnung zu finden.
In einem Objektspeicher steht dann bei diesem Beispiel in den Metadaten der Rechnungsaussteller, das Datum, die Summe und evtl. sogar eine Zusammenfassung der Rechnung. Die Suche
wird also sehr einfach, egal ob man Rechnungen zu einem Datum sucht, oder von einem Aussteller.
Den Speicher für den User im Netzwerk bzw. im Unternehmen wird noch lange vom File-Storage dominiert. Die Strukturen sind meist gewachsen, eine Separierung in Abteilungen
ist sehr einfach möglich, eine vollständige User- und Berechtigungsstruktur ist meist auch schon vorhanden. Alles dies nutzt der File-Speicher und macht ihn zur Basis
für Office-Anwendungen im Unternehmen.
In einem Block-Speicher liegen die Daten auf einzelnen Blöcken (wie es der Name schon sagt). Die Organisation dieser Blöcke übernimmt dann zum Beispiel ein
Filesystem oder eine Datenbank (wenn sie im RAW-Format speichert). Es sind dort aber keine Metadaten vorhanden, sondern nur die Blockadressen. Das Filesystem schreibt
etwas auf einen bestimmten Block oder liest von diesem Block. Ohne das Filesystem wird eine Suche nach Daten nahezu zwecklos, da die Daten nicht immer zusammenhängend
gespeichert werden.
Der Block-Speicher ist sehr schnell, da der Zugriff direkt auf einen bestimmten Block erfolgt, ohne eine Suche über zum Beispiel Metadaten. Damit ist der Block-Speicher
sehr gut für Datenbanken und Transaktionen geeignet, die eine minimale Verzögerung benötigen. So würde zum Beispiel die Anzeige aller Rechnungen mit bestimmten Metadaten
im Objektspeicher deutlich länger dauern, als die Suche in einer Datenbank, die auch noch mit einem Index über die Suchspalte beschleunigt werden kann. Möchte man
die Summen aller Rechnungen von einem Jahr addieren, dann ist die Datenbank auf einem Blockspeicher im Vorteil. Wenn man aber extrem viele Rechnungen aufbewahren muss und
dann eine bestimmte Rechnung sucht, dann wird der Objektspeicher im Vorteil sein.
Auch bei der Skalierung des Blockspeichers sind Grenzen gesetzt. Ein Blockspeicher kann zum Beispiel mit einem RAID-Controller sehr große ausgelegt werden, aber auch dort
sind Grenzen vorhanden.
Wird aber ein schneller Speicher benötigt, dann ist der Block-Storage ganz vorne mit dabei.
Alle großen Cloud Provider bieten Objekt-Speicher an, meist auf Basis von S3 Speicher (siehe unten). Dieser Speicher kann dann von Kunden genutzt werden. Aber
woher bekommen die Cloud Provider den Speicher und wie kann man Object Storage selbst erstellen?
Ein einfaches Beispiel ist Ceph. Und Ceph kann über eine S3 API auch Objektspeicher zur Verfügung stellen. Ceph ist ja nicht nur in Proxmox enthalten, sondern auch
eine eigene Lösung für den globalen Speicher. Und wie dieses Beispiel zeigt, dann auch eine Speicherbasis, die auch für virtuellen Maschinen genutzt werden kann.
Natürlich bieten alle namhaften Hersteller auch eigene Systeme an. So zum Beispiel Dell mit ObjectScale, auf Basis von PowerEdge Servern mit HDD / NVMe
mit einer Kapazität von bis zu 20 PB pro Rack.
Oder HPE mit der Alletra Storage MP X10000, besonders optimiert auf KI-Anwendungen mit einem direkten Datenpfad zwischen
GPU-Speicher, Systemarbeitsspeicher und der X10000.
Bei NetApp ist das StorageGRID ein Objektspeicher, Software-Definied und mit den gängigen Schnittstellen, wie Amazon Simple Storage Services (Amazon S3). Dieser
einzelne Namespace kann über maximal 16 Data Centers aufgebaut werden. Die Basis-Systeme bieten kosteneffektive Festplattensysteme, wie auch performante Flash Lösungen.
Diese Lösungen bieten auf der einen Seite die Schnittstellen für Anwendungen, wie eben die Amazon S3 API, sowie auch S3 Object Lock, WORM Funktionen und Verschlüsselung. Und auf der
anderen Seite zum Beispiel CloudMirror, eine Replikation auf anderen Amazon S3 Speicher oder Google Cloud.
Fangen wir erst einmal etwas allgemeiner an: Wie können die Anwendungen auf den Objektspeicher zugreifen? Wie schon erwähnt über HTTP und REST API und dort
hat Amazon die "Simple Storage Services" oder kurz S3 entwickelt. Das API Interface ist zum Quasi-Standard beim Zugriff auf Objekt-Speicher geworden.
Damit konnten die Speicherentwickler Systeme mit S3 Schnittstelle anbieten und die Anwendungsentwickler hatten eine gemeinsame Schnittstelle.
Es gibt verschiedene Einsatzbereiche und damit verschiedene Lösungen:
Datensicherung
Hier bietet Veeam die "Direct to Object Storage Backups" an. Das Ziel kann hierbei ein Cloud-Provider, aber auch ein lokales Objektstorage sein. Damit kann die
Datensicherung im ersten Schritt zum Beispiel auf ein lokales System durchgeführt werden, welches dann in die Cloud gespiegelt wird. Damit wird die Spiegelung dann
vom Storage übernommen, Veeam bekommt davon nichts mit und es entstehen auf der Seite der Backup-Software auch keine weiteren Kosten für die Spiegelung.
Arcserve bietet das Arcserve Cloud Storage für die Speicherung von Daten an und die Sicherung an sich kann dann von Arcserve UDP durchgeführt werden. Also auch in diesem
Beispiel die Sicherung von Anwendungen oder virtuellen Maschinen direkt auf den Objektspeicher.
Archivierung und Dokumentenmanagement
Dies sind zwei grundsätzliche Anwendungen für den Objektspeicher. Die Vorteile liegen auf der Hand, große Datenmengen, aber die Performance ist nicht so wichtig,
die Metadaten um so mehr. Und auch der "Überschreibschutz" ist bei der Archivierung extrem wichtig. Der Lebenszyklus eines Objektes kann auch genau bestimmt werden, so
das neben dem Schutz der Daten auch eine gesetzeskonforme Löschung realisiert werden kann. Das alles ist mit einem NAS Speicher nur schwer und mit zusätzlichem Aufwand zu
realisieren.
Big Data
Wahrscheinlich der Auslöser für diese Technologie. Extrem viele Daten, die sehr lange aufbewahrt werden sollen, aber selten genutzt werden. Bekannte Software
in diesem Bereich sind Apache Hadoop und Apache Spark. Warum ist dort der Objektspeicher so interessant? Der eigentliche Nutzwert (= Geld) ist pro Gigabyte (oder eher Terabyte)
relativ gering, jedoch kann eine Analyse über große Datenbestände einen extremen Mehrwert (= Erkenntnisse, also auch Geld) erzielen.
Medien Speicher (Bilder, Videos)
Auch wieder ein klassischer Anwendungsfall für den Objektspeicher. Viele Daten, große Daten und meist nur selten genutzt, eine besondere Performance ist selten notwendig. Nutzer
sind quasi alle großen Anbieter von Daten, wie zum Beispiel Facebook und Spotify. Also extrem viele Daten, von denen die meisten aber nur sehr selten benötigt werden. Aber
auch dort kann die geringere Performance einfach durch einen Cache ausgeglichen werden.
Internet of Things (IoT)
In diesem Bereich fallen viele Daten an, die aber mehr oder weniger nur gesammelt werden sollen, um sie später einmal auswerten zu können. Wieder ein Beispiel aus
dem Open-Source Bereich ist OpenTelemetry. Hier werden Telemetrie-Daten von verschiedenen Quellen gesammelt und können zentral in einem Objekt-Speicher abgelegt werden.
Aber warum sammelt man gerade im IOT "alte" Daten? Nehmen wir als Beispiel die Produktion mit einer Maschine. Wenn Zustandsdaten dieser Maschine gesammelt werden, können daraus
Daten zur Abnutzung generiert werden, so dass die Maschine vor dem eigentlichen Ausfall ersetzt oder repariert werden kann. Dies schützt vor Produktionsausfällen.