Unstrukturierte Daten effizient speichern

Red Hat Gluster zieht eine Abstraktionsschicht zwischen dem physikalischen Speicher und dem Benutzer ein. Zur Ablage werden blockbasierte Dateisysteme genutzt. Die Software verteilt die Daten nicht auf Server-Knoten-, sondern auf Brick-Ebene; die Bricks enthalten die Pfadangaben zum physischen Speicherort. Bricks sind Linux-Rechner mit frei verfügbarem Plattenplatz, etwa Partitionen, Festplatten oder RAID-Arrays. Dabei ist es egal, wie viele Datenträger pro Brick tatsächlich zur Verfügung stehen oder wie viele Server eingebunden sind. Ein Gluster Volume entsteht aus den Bricks verschiedener Server. Aus Benutzersicht entsteht so ein Shared Storage Pool, auf den lesend und schreibend zugegriffen werden kann. Die zweite zentrale Komponente sind Translatoren, die Funktionen wie Posix-Schnittstelle, die Verteilung von Daten im Hintergrund oder den Aufbau eines verteilten RAID-Verbunds über mehrere Bricks bereitstellen.

Ein weiteres Kennzeichen ist die Metadatenverwaltung: Dateien werden auf Basis eines Algorithmus im gesamten Storage-Cluster verteilt, das heißt die Anwender können Kapazität und Performance im Gleichschritt steigern. Damit entsteht eine leistungsfähige SDS-In­frastruktur, um unstrukturierte Daten File-basiert auf Standard-x86er-Servern zu speichern.

Gluster Storage stellt seine Speicher-Pools üblicherweise über die File-basierten Standard-Netzwerkprotokolle NFS und SMB zur Verfügung, bietet aber auch ein eigenes, hoch optimiertes Netzwerkprotokoll (GlusterFuse) samt eigenem API (libGFAPI) für Linux-basierte Clients und ermöglicht zudem einen objektbasierten Zugriff auf Dateien über die Swift-Schnittstelle.

Object Stores speichern die Daten als binäre Objekte, die sich in viele Teile aufspalten lassen. Die einzelnen Teile des binären Objekts können verteilt – zum Beispiel über mehrere Festplatten – gespeichert werden. Damit umgehen Objektspeicher den größten Schwachpunkt klassischer Storage-Lösungen: die starre Einteilung in Blöcke.

Kernkomponente von Ceph ist der Objektspeicher, vormals Rados (Redundant Autonomic Distributed Object Store). Dieser besteht aus Object Storage Device (OSD) und Monitoring-Server. Ein OSD ist praktisch die einzelne Festplatte in einem Ceph-Verbund. Die OSDs speichern als Datensilos die binären Objekte. Um Daten in einen Cluster zu laden, kommunizieren Anwender mit diesen OSDs, die sich etwa auch um die Replikation kümmern. Über die Monitoring-Server können Clients und OSDs feststellen, welche OSDs zu einem Cluster gehören. Der Objektspeicher arbeitet mit dem Crush-Algorithmus (Controlled Replication Under Scalable Hashing) und verteilt die Daten über die verfügbaren Speichersysteme. Die Platzierung der Daten erfolgt über Regeln, in denen zum Beispiel auch definiert wird, wie viele Kopien aus Gründen der Ausfallsicherheit anzu­legen sind.

Ceph Storage stellt seine Speicher-Pools üblicherweise über objektbasierte Protokolle wie S3 oder Swift zur Verfügung. Weitere Integrationsmöglichkeiten bieten eigene APIs wie die objektbasierte Librados-Schnittstelle, die blockbasierte librbd/kRBD-Schnittstelle oder die direkte Anbindung an die OpenStack-Speicherschnitt­stellen Cinder und Glance.