Stor IT Back - Ihr Speicherspezialist

Objektspeicher (Object Storage) V1.2 (c) Stor IT Back 2025


Was ist ein Objektspeicher, eine Einführung

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.



 
 

Wie ist der Objektspeicher aufgebaut?

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.



 
 

Was ist der Unterschied zwischen Objektspeicher und File-Storage?

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.



 
 

Was ist der Unterschied zwischen Objektspeicher und Block-Storage?

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.



 
 

Hardwarelösungen und Systeme für Objektspeicher

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.



 
 

Welche Anwendungen nutzen Objektspeicher?

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.



 
 

Angebote der Stor IT Back zum Thema Object Storage

Proxmox VE auf Lenovo Server
Proxmox VE Ceph Cluster
QEMU/KVM und LXC (Linux Containers)

mit HA und Ceph Storage
3 Node Cluster als All Flash
ab 20.346,00 Euro
zzgl. MwSt.
Angebot Dell EMC Powerstore Serie
Dell EMC Powerstore 500 bis 9000 Serie
Unified Storage - NVMe System

Replikation, Storage Cluster, NVMe-FC, NVMe/TCP
inkl. Installation, Abnahme und Einweisung in DE
Preis
auf Anfrage
Schulungen für Storage und Backup
Schulungen und Workshops
Storage (SAN, NAS, iSCSI)
Backup (LANfree, SnapShot)
Storage- und Servervirtualisierung
Praxis-Schulungen
individuell / auch Inhouse
 
 
Zurück zur Übersicht
Object Storage
Übersicht der Angebote
Kontakt zur Stor IT Back
Suche auf der Webseite