Ceph

Entstehung und Beteiligte

Ceph wurde ab 2004 von Sage Weil an der University of California, Santa Cruz für seine Dissertation entwickelt. 2006 veröffentlichte er die Architektur. Später gründete er DreamHost-Ausgründungen; Red Hat übernahm Inktank 2014.

Welches Problem sollte gelöst werden?

Große Cluster benötigten Objekt-, Block- und Dateispeicher ohne zentrale Metadaten- oder Datenengpässe. Kapazität und Leistung sollten durch zusätzliche Standardserver wachsen.

Technische Hürden und Lösungen

CRUSH berechnet Datenplatzierung ohne zentrale Lookup-Tabelle. Replikation, Recovery und Rebalancing erzeugen dennoch hohe Last. Quorum, konsistente Zeit, Netzwerkdesign und gleichmäßige Hardware sind entscheidend.

Standardisierung und Einordnung

Speichersysteme müssen Daten trotz Defekten, Bedienfehlern und Ausfällen erhalten. Historisch verlagerte sich der Fokus von einzelnen Datenträgern zu Verbünden, Snapshots, Prüfsummen, Replikation und verteilten Objekten. Redundanz ist dennoch kein Backup: Sie schützt meist vor Hardwareausfall, nicht automatisch vor Löschen, Verschlüsselungstrojanern oder fehlerhaften Anwendungen.

Technik im praktischen Betrieb

Speicher muss anhand von Fehlerdomänen geplant werden: Datenträger, Controller, Host, Rack, Standort, Zugangsdaten und Verwaltungssoftware können jeweils gemeinsam ausfallen. Prüfsummen erkennen bestimmte Beschädigungen, Replikation erhält Verfügbarkeit und Snapshots ermöglichen schnelle Rücksprünge; keine dieser Funktionen ersetzt automatisch eine unabhängige Sicherung. Regelmäßige Scrubs, SMART- beziehungsweise Gerätezustände, Kapazitätsreserven und Restoretests gehören zum Betrieb. Besonders wichtig ist ein dokumentierter Weg, Daten auch dann wiederherzustellen, wenn die ursprüngliche Verwaltungsoberfläche nicht mehr startet.

Warum das Thema heute noch relevant ist

Die Bedeutung wächst mit der Datenmenge, aber auch mit gesetzlichen und betrieblichen Anforderungen. Historische Speicherfehler zeigen, dass „das Laufwerk funktioniert“ keine ausreichende Integritätsaussage ist. Prüfsummen, Versionen und unabhängige Kopien beantworten verschiedene Risiken. Ein belastbares Konzept definiert deshalb, welche Daten wie lange aufbewahrt werden, wie schnell sie zurückkehren müssen und wer eine Wiederherstellung auch unter Zeitdruck durchführen kann.

Daten und Meilensteine

• 2004 beginnt Sage Weil Ceph.
• CRUSH verteilt Objekte algorithmisch.
• RADOS ist die verteilte Objektbasis.
• RBD, CephFS und RGW liefern Block, Datei und Objektzugriff.

Bausteine eines Ceph-Clusters

OSD-Dienste speichern Daten, Monitore halten den Clusterzustand und Manager liefern Verwaltungsfunktionen. CRUSH berechnet die Datenplatzierung ohne zentrale Zuordnungstabelle. Clients greifen als RBD, CephFS oder über Object Gateway zu.

Redundanz und Selbstheilung

Fällt ein Datenträger oder Knoten aus, verteilt Ceph betroffene Daten neu. Diese Wiederherstellung erzeugt zusätzliche Last. Reservekapazität, getrennte schnelle Netze und passende Failure Domains entscheiden darüber, ob der Cluster einen Ausfall wirklich kontrolliert verkraftet.

Wann Ceph sinnvoll ist

Ceph spielt seine Stärken bei mehreren Hosts, vielen Laufwerken und hohen Verfügbarkeitsanforderungen aus. Für einen einzelnen kleinen Server ist ZFS meist einfacher und transparenter. Komplexität ist selbst ein Betriebsrisiko.